Analysis Modeling

set of models, is the first technical representation of a system. (What?)

Scenario based elements, Class-based elements

Behavioral elements, Flow oriented elements

Analysis model
Combination of text and diagrammatic forms to depict requirements for data, function, and behavior in a way that is relatively easy to understand, and more important, straightforward to review for correctness, completeness, and consistency.

Analysis model : Bridge between Specification and solution

System description Analysis model

Design Model

Analysis : Rules of thumb

The level of abstraction should be relatively high.

Each element of the analysis model should add to an overall

understanding of software requirements

Delay consideration of infrastructure and other nonfunctional models until design

Analysis : Rules of thumb

Minimize coupling throughout the system.

Be certain that the analysis model provides value to all stakeholders.

Keep the model as simple as it can be.

Domain analysis

Analysis : Approaches
Structured analysis

Object oriented analysis

Elements of analysis modeling

Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Flow-oriented elements

Analysis Model

Data-flow diagrams Control flow diagrams Processing narratives

Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams

Behavioral elements
State diagrams Sequence diagrams

Activity Diagram

Activity Diagram
An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or subactivities in the source states.

It represents a state machine of a computation itself.

Activity Diagram
The entire activity diagram is attached (through the model) to a classifier, such as a use case, or to a package, or to the implementation of an operation.

The purpose of this diagram is to focus on flows driven by

internal processing (as opposed to external events).

Activity diagram: Action state

An action state is a shorthand for a state with

an entry action and at least one outgoing

transition involving the implicit event of

completing the entry action (there may be

several such transitions if they have guard

conditions).
Action Expression

Activity diagram: Transition

Transitions leaving an action state should not
include an event signature.

The transitions may include guard conditions and actions. A common use of an action state is to model a step in the execution of a workflow process.

Activity diagram: Decision

To expresses a decision when guard conditions
are used to indicate different possible transitions

that depend on Boolean conditions of the owning

object.

UML provides a shorthand for showing decisions

and merging their separate paths back together.

Activity diagram: Decision

Each possible outcome should appear on one

of the outgoing transitions.

A predefined guard denoted else may be

defined for at most one outgoing transition. This transition is enabled if all the guards labelling the other transitions are false.

Ex: Decision and Merge

Swimlanes
Actions and subactivities may be organized into swimlanes.

Swimlanes are used to organize responsibility

for actions and subactivities. They often

correspond to organizational units in a business

model.

Access camera surveillance

Swimlane diagram

 A swimlane maps into a Partition of the States in the ActivityGraph. A state symbol in a swimlane causes the corresponding State to belong to the corresponding Partition.

Action-Object Flow Relationships

Actions operate by and on objects. These objects either have primary responsibility for initiating an action, or are used or determined by the action.
Actions usually specify calls sent between the object owning the activity graph, which initiates actions, and the objects that are the targets of the actions.

Object Flow
Objects that are input to or output from an action may be shown as object symbols. Notation:
A dashed arrow is drawn from an action state to an output object, and a dashed arrow is drawn from an input object to an action state. The same object may be (and usually is) the output of one action and the input of one or more subsequent actions.

Output from the action Request Service Input to the action Take order

Object

Actions and Object Flow

ATM: EXAMPLE

A Business Activity Diagram

[CARD valid]

Client arrives at ATM

[CARD valid]

Insert Card

Give PIN [PIN OK]

[PIN OK]

[Quit]
Select Service

[withdraw]
View Balance Withdraw Eject Card

Client Transaction

Client leaves ATM

Activity Diagram- Withdraw

Get Account Details [NoOfAccounts = 1] A Only Account [NoOfAccounts > 1] List an Account details [more]

[no more]
Get amount Get Users Choice (say A)

[amount >A . balance] Result FALSE

[amount < =A . balance]

A.balance A.balance-amount Result TRUE