UNIT-IV Behavioral Diagrams (08 Hrs, 16 Marks) · 2017-02-27 · 1 By: Prof. Pankaj R. Patil | Subject: OOMD UNIT-IV Behavioral Diagrams (08 Hrs, 16 Marks) a. Use case Diagram Names,

1 By: Prof. Pankaj R. Patil | Subject: OOMD

UNIT-IV

Behavioral Diagrams (08 Hrs, 16 Marks)

a. Use case Diagram

Names, Use Cases and Actors, Use Cases and Flow of Events, Use Cases and Scenarios,

Use Cases and Collaborations, Organizing Use Cases, Common Properties, Contents,

Common Uses

b. Sequence Diagram

c. Communication Diagram

d. Timing Diagram

e. State chart Diagram:

Behavioral State Machines, States, Composite States, Submachine States, Transitions,

Activities, Protocol State Machines ,Pseudo States , Event Processing

f. Activity Diagram:

Common Properties, Contents, Action States and Activity States, Transitions,

Branching, Forking and Joining, Swimlanes, Object Flow, Common Uses

Use Case Diagrams

• Use case diagram shows a set of use cases and actors (a special kind of class) and their

relationships. Use case diagrams address the static use case view of a system.

• These diagrams are especially important in organizing and modeling the behaviors of a

system.

• Use case diagrams are one of the five diagrams in the UML for modeling the dynamic

aspects of systems (activity diagrams, statechart diagrams, sequence diagrams, and

collaboration diagrams are four other kinds of diagrams in the UML for modeling the

dynamic aspects of systems).

• Use case diagrams are central to modeling the behavior of a system, a subsystem, or a

class. Each one shows a set of use cases and actors and their relationships.

• You apply use case diagrams to model the use case view of a system.

• Use case diagrams are important for visualizing, specifying, and documenting the

behavior of an element.

• They make systems, subsystems, and classes approachable and understandable by

presenting an outside view of how those elements may be used in context.


• Use case diagrams are also important for testing executable systems through forward

engineering and for comprehending executable systems through reverse engineering.

• With the UML, you apply use case diagrams to visualize the behavior of a system,

subsystem, or class so that users can comprehend how to use that element, and so that

developers can implement that element.

• As Figure shows, you can provide a use case diagram to model the behavior of that box

which most people would call a cellular phone.

Terms and Concepts

• A use case diagram is a diagram that shows a set of use cases and actors and their

relationships.

• A use case is a description of a set of sequences of actions, including variants, that a

system performs to yield an observable result of value to an actor.

• Graphically, a use case is rendered as an ellipse.

Names

• A use case name must be unique within its enclosing package

• Every use case must have a name that distinguishes it from other use cases. A name is a

textual string. That name alone is known as a simple name; a path name is the use case

name prefixed by the name of the package in which that use case lives. A use case is

typically drawn showing only its name.


Use Cases and Actors

• An actor represents a coherent set of roles that users of use cases play when interacting

with these use cases.

• Typically, an actor represents a role that a human, a hardware device, or even another

system plays with a system. For example, if you work for a bank, you might be a

LoanOfficer.If you do your personal banking there, as well, you'll also play the role of

Customer.

• An instance of an actor, therefore, represents an individual interacting with the system in

a specific way. Although you'll use actors in your models, actors are not actually part of

the system. They live outside the system.

• actors are rendered as stick figures.

Use Cases and Flow of Events

• A use case describes what a system (or a subsystem, class, or interface) does but it does

not specify how it does it. When you model, it's important that you keep clear the

separation of concerns between this outside and inside view.

• Specify the behavior of a use case by describing a flow of events in text clearly enough

for an outsider to understand it easily.

• When you write this flow of events, you should include how and when the use case starts

and ends, when the use case interacts with the actors and what objects are exchanged, and

the basic flow and alternative flows of the behavior.


• For example, in the context of an ATM system, you might describe the use case

ValidateUser in the following way:

• Main flow of events:

The use case starts when the system prompts the Customer for a PIN number. The Customer

can now enter a PIN number via the keypad. The Customercommits the entry by pressing the

Enter button. The system then checks this PIN number to see if it is valid. If the PIN number

is valid, the system acknowledges the entry, thus ending the use case.

Exceptional flow of events:

The Customer can cancel a transaction at any time by pressing the Cancel button, thus

restarting the use case. No changes are made to the Customer's account.


The Customer can clear a PIN number anytime before committing it and reenter a new PIN

number.


If the Customer enters an invalid PIN number, the use case restarts. If this happens three

times in a row, the system cancels the entire transaction, preventing the Customer from

interacting with the ATM for 60 seconds.

Use Cases and Scenarios

• Describe the flow of events for a use case in text. As you refine your understanding of

your system's requirements, however, you'll want to also use interaction diagrams to

specify these flows graphically. Typically, you'll use one sequence diagram to specify a

use case's main flow, and variations of that diagram to specify a use case's exceptional

flows.

• It is desirable to separate main versus alternative flows because a use case describes a set

of sequences, not just a single sequence, and it would be impossible to express all the

details of an interesting use case in just one sequence. For example, in a human resources

system, you might find the use case Hire employee.

• This general business function might have many possible variations. You might hire a

person from another company (the most common scenario); you might transfer a person

from one division to another (common in international companies); or you might hire a

foreign national (which involves its own special rules). Each of these variants can be

expressed in a different sequence.


• Each sequence is called a scenario. A scenario is a specific sequence of actions that

illustrates behavior. Scenarios are to use cases as instances are to classes, meaning that a

scenario is basically one instance of a use case.

Use Cases and Collaborations

• Implement your use cases, by creating a society of classes and other elements that work

together to implement the behavior of use case. This society of elements, including both

its static and dynamic structure, is modeled in the UML as a collaboration.

• As shows, you can explicitly specify the realization of a use case by a collaboration.

• Most of the time, though, a given use case is realized by exactly one collaboration, so you

will not need to model this relationship explicitly.

Organizing Use Cases

• You can organize use cases by grouping them in packages in the same manner in which

you can organize classes.

• You can also organize use cases by specifying generalization, include, and extend

relationships among them.

• You apply these relationships in order to factor common behavior (by pulling such

behavior from other use cases that it includes) and in order to factor variants (by pushing

such behavior into other use cases that extend it).

For example, in a banking system, You might have the use case Validate User, which is

responsible for verifying the identity of the user. You might then have two specialized

children of this use case (Check password and Retinal scan), both of which behave just

like Validate User and may be applied anywhere Validate User appears, yet both of

which add their own behavior (the former by checking a textual password, the latter by

checking the unique retina patterns of the user).


• As shown in Figure , generalization among use cases is rendered as a solid directed line

with a large open arrowhead, just like generalization among classes

• You render an include relationship as a dependency, stereotyped as include.

• To specify the location in a flow of events in which the base use case includes the

behavior of another, you simply write include followed by the name of the use case you

want to include, as in the following flow for Track order.

• You use an extend relationship to model the part of a use case the user may see as

optional system behavior. In this way, you separate optional behavior from mandatory

behavior.

• You render an extend relationship as a dependency, stereotyped as extend. You may list

the extension points of the base use case in an extra compartment. These extension points

are just labels that may appear in the flow of the base use case

Common Properties

• A use case diagram is just a special kind of diagram and shares the same common

properties as do all other diagrams. a name and graphical contents that are a projection

into a model. What distinguishes a use case diagram from all other kinds of diagrams is

its particular content.

Contents

Use case diagrams commonly contain

• Use cases

• Actors


• Dependency, generalization, and association relationships

• Like all other diagrams, use case diagrams may contain notes and constraints.

• Use case diagrams may also contain packages, which are used to group elements of your

model into larger chunks. Occasionally, you'll want to place instances of use case in your

diagrams, as well, especially when you want to visualize a specific executing system.

Common Uses

• When you model the static use case view of a system, you'll typically apply use case

diagrams in one of two ways.

1. To model the context of a system

• Modeling the context of a system involves drawing a line around the whole system and

asserting which actors lie outside the system and interact with it. Here, you'll apply use

case diagrams to specify the actors and the meaning of their roles.

2. To model the requirements of a system

• Modeling the requirements of a system involves specifying what that system should do

(from a point of view of outside the system), independent of how that system should do

it. Here, you'll apply use case diagrams to specify the desired behavior of the system.

• In this manner, a use case diagram lets you view the whole system as a black box; you

can see what's outside the system and you can see how that system reacts to the things

outside, but you can't see how that system works on the inside.

Common Modeling Techniques

Modeling the Context of a System

• All those things on the outside that interact with the system constitute the system's

context. This context defines the environment in which that system lives.

• In the UML, you can model the context of a system with a use case diagram,

emphasizing the actors that surround the system. Deciding what to include as an actor is

important because in doing so you specify a class of things that interact with the system.

• Deciding what not to include as an actor is equally, if not more, important because that

constrains the system's environment to include only those actors that are necessary in the

life of the system.

To model the context of a system,


- Identify the actors that surround the system by considering which groups require help

from the system to perform their tasks; which groups are needed to execute the system's

functions; which groups interact with external hardware or other software systems; and

which groups perform secondary functions for administration and maintenance.

- Organize actors that are similar to one another in generalization/specialization

hierarchy.

- Where it aids understandability, provide a stereotype for each such actor.

- Populate a use case diagram with these actors and specify the paths of communication

from each actor to the system's use cases.

• For example, Figure shows the context of a credit card validation system, with an

emphasis on the actors that surround the system.

• You'll find Customers, of which there are two kinds (Individual customer and Corporate

customer). These actors are the roles that humans play when interacting with the system.

• In this context, there are also actors that represent other institutions, such as Retail

institution (with which a Customer performs a card transaction to buy an item or a

service) and Sponsoring financial institution (which serves as the clearinghouse for the

credit card account).

• In the real world, these latter two actors are likely software-intensive systems themselves.


• Modeling the Requirements of a System

To model the requirements of a system,

• Establish the context of the system by identifying the actors that surround it.

• For each actor, consider the behavior that each expects or requires the system to

provide. Name these common behaviors as use cases.

• Factor common behavior into new use cases that are used by others; factor variant

behavior into new use cases that extend more main line flows.

• Model these use cases, actors, and their relationships in a use case diagram.

• Adorn these use cases with notes that assert nonfunctional requirements; you may have to

attach some of these to the whole system.

• Forward and Reverse Engineering

-Forward engineering is the process of transforming a model into code through a mapping to an

implementation language.

-A use case diagram can be forward engineered to form tests for the element to which it applies.

Each use case in a use case diagram specifies a flow of events (and variants of those flows), and

these flows specify how the element is expected to behave that's something worthy of testing.

- A well-structured use case will even specify pre- and postconditions that can be used to define

a test's initial state and its success criteria.


- For each use case in a use case diagram, you can create a test case that you can run every time

you release a new version of that element, thereby confirming that it works as required before

other elements rely on it.

To forward engineer a use case diagram,

• For each use case in the diagram, identify its flow of events and its exceptional flow of

events.

• Depending on how deeply you choose to test, generate a test script for each flow, using

the flow's preconditions as the test's initial state and its post conditions as its success

criteria.

• As necessary, generate test scaffolding to represent each actor that interacts with the use

case. Actors that push information to the element or are acted on by the element may

either be simulated or substituted by its real-world equivalent.

• Use tools to run these tests each time you release the element to which the use case

diagram applies.

A well-structured use case diagram

• Is focused on communicating one aspect of a system's static use case view.

• Contains only those use cases and actors that are essential to understanding that aspect.

• Provides detail consistent with its level of abstraction; you should expose only those

adornments (such as extension points) that are essential to understanding.

• Is not so minimalist as to misinform the reader about semantics that are important.

When you draw a use case diagram,

• Give it a name that communicates its purpose.

• Lay out its elements to minimize lines that cross.

• Organize its elements spatially so that behaviors and roles that are semantically close are

laid out physically close.

• Use notes and color as visual cues to draw attention to important features of your

diagram.

• Try not to show too many kinds of relationships. In general, if you have complicated

include and extend relationships, take these elements to another diagram.

Sequence Diagram :-


- Shows time ordering

- Formed by placing objects that participate in interaction at top of diagram

- Place object that initiate interaction at the left & increasingly more subordinate objects to

right

- Place message that these object send & receive along y-axis in order of increasing time

from top to bottom

- 2 feature that distinguish from collaboration

1. There is object life line:

- It is vertical dashed line that represent existence of an object over a period of time

- Object are aliened at top with their life line dawn from top to bottom

- 2. There is focus of control

- it is tall ,thin, rectangular that shows period of time in which an object perform an

action

- Top of rectangle is aliened with start of action ,bottom with completion


2. Collaboration Diagram

- It shows structural organization of object that participate in interaction

- It formed by placing object that participate in interaction as vertices in graph

- show link that connect these object as arc

- Show message that object send & receive


- 2 features

1. There is a path :-

- Indicate how one object linked to another

- path of link explicitly render for local (<<local >>),global ,self

2. There is sequence no.:-

- for indicating time order of message ,you prefix message with number incrementing for

each new message in flow of control

- To show nesting use decimal no. (1.1,1.2..)

• Common uses of interaction diagram :-


- Model dynamic aspect of system

1. To model flow of control of time ordering

- Use sequence diag.

2. to model flow of control of organization

- Use collaboration diag.

Communication Diagrams

• In UML 2.0 communication diag. is a simplified version of UML 1.x collaboration diag.

• 4 –type of interaction diag.:

- Sequence diagram

- Communication diagram

- interaction overview diagram

- timing diagram

• model interaction between object

• Communication diag. represents combination of info. Taken from class, sequence ,use

case diag. describing both static & dynamic behavior of system.

• It is an interaction diagram that emphasizes the structural organization of the objects that

send and receive messages

• it shows message flow between objects in OO application & also imply basic association

between classes


Timing diagrams

• It is special representation of interaction that focus on specific timing of messages send

between objects

• Show detail timing constraints on message or show when change occur within lifeline

w.r.t. time

• It used with real time or embedded systems

• Read left to right rather than top to bottom

• Show lifeline name along left edge of diag.

• X-axis displays elapsed time in whatever units are chosen while the Y-axis is labeled

with a given list of states.


• UML provides a variation on timeline notation that simplifies diag. by showing state

name between two horizontal line that crosses when state changes

• It make simple to show multiple object along simple time line but don’t show message

that triggers transition

• It is possible to stack several life lines of different objects in the same timing diagram.

One life line above the other.

• Messages sent from one object to another can be depicted using simple arrows. The start

and the end points of each arrow indicate when each message was sent... and when it was

received.


State Lifeline

• A state lifeline shows the change of state of an item over time. The X-axis displays

elapsed time in whatever units are chosen, while the Y-axis is labeled with a given list of

states.

• A state lifeline is shown below.

Value Lifeline

• Shows the change of value of an item over time. The X-axis displays elapsed time in

whatever units are chosen, the same as for the state lifeline.

• The value is shown between the pair of horizontal lines which crosses over at each

change in value.

• A value lifeline is shown below.


Putting it all together

• State and value lifelines can be stacked one on top of another in any combination.

• They must have the same X-axis. Messages can be passed from one lifeline to another.

• Each state or value transition can have a defined event, a time constraint which indicates

when an event must occur, and a duration constraint which indicates how long a state or

value must be in effect for.

• Once these have all been applied, a timing diagram may look like the following.

State chart diagram

Model dynamic aspect of system, represent state machine

Activity diag. is a special case of state chart diag.

Activity diagram shows flow of control from activity to activity, a statechart diagram

shows flow of control from state to state.

Model the dynamic aspects of a system.

involves modeling the behavior of reactive objects.

A reactive object is one whose behavior is best characterized by its response to events

dispatched from outside its context.

A reactive object has a clear lifetime whose current behavior is affected by its past.

State chart diagrams may be attached to classes, use cases, or entire systems in order to

visualize, specify, construct, and document the dynamics of an individual object.

• In the UML, you model the event-ordered behavior of an object by using statechart

diagrams.


• As Figure shows, a statechart diagram is simply a presentation of a state machine,

emphasizing the flow of control from state to state.

• Terms and Concepts

A statechart diagram shows a state machine, emphasizing the flow of control from state

to state.

A state machine is a behavior that specifies the sequences of states an object goes

through during its lifetime in response to events, together with its responses to those

events.

A state is a condition or situation in the life of an object during which it satisfies some

condition, performs some activity, or waits for some event.

An event is the specification of a significant occurrence that has a location in time and

space. In the context of state machines, an event is an occurrence of a stimulus that can

trigger a state transition.

A transition is a relationship between two states indicating that an object in the first state

will perform certain actions and enter the second state when a specified event occurs and

specified conditions are satisfied.

An activity is ongoing nonatomic execution within a state machine. An action is an

executable atomic computation that results in a change in state of the model or the return

of a value.

Graphically, a statechart diagram is a collection of vertices and arcs.

Common Properties

• A statechart diagram is just a special kind of diagram and shares the same common

properties as do all other diagrams that is, a name and graphical contents that are a

projection into a model.


What distinguishes a statechart diagram from all other kinds of diagrams is its

content.

Contents

• Statechart diagrams commonly contain

Simple states and composite states

Transitions, including events and actions

Notes and constraints

Common Uses

to model the dynamic aspects of a system. These dynamic aspects may involve the

event-ordered behavior of any kind of object in any view of a system's architecture,

including classes (which includes active classes), interfaces, components, and nodes.

use statechart diagrams in the context of the system as a whole, a subsystem, or a class.

attach statechart diagrams to use cases (to model a scenario).

Common Modeling Technique

Modeling Reactive Objects

When you model the behavior of a reactive object, you essentially specify three things:

1. the stable states in which that object may live,

2. the events that trigger a transition from state to state, and

3. the actions that occur on each state change.

• Modeling the behavior of a reactive object also involves modeling the lifetime of an

object, starting at the time of the object's creation and continuing until its destruction,

highlighting the stable states in which the object may be found.

• A stable state represents a condition in which an object may exist for some identifiable

period of time. When an event occurs, the object may transition from state to state

- To model a reactive object:

• Choose the context for the state machine, whether it is a class, a use case, or the system

as a whole.

• Choose the initial and final states for the object.

• Decide on the stable states of the object by considering the conditions in which the object

may exist for some identifiable period of time. Start with the high-level states of the

object and only then consider its possible substates.

• Decide on the meaningful partial ordering of stable states over the lifetime of the object.

• Decide on the events that may trigger a transition from state to state.

• Model these events as triggers to transitions that move from one legal ordering of states

to another.

• Attach actions to these transitions (as in a Mealy machine) and/or to these states Consider

ways to simplify your machine by using substates, branches, forks, joins, and history

states.


• Check that all states are reachable under some combination of events.

• Check that no state is a dead end from which no combination of events will transition the

object out of that state.

• Trace through the state machine, either manually or by using tools, to check it against

expected sequences of events and their responses.

Substates:

• substate is a state that's nested inside another one.

• For example, a Heater might be in the Heating state, but also while in the Heating state,

there might be a nested state called

Activating.

• Nested states is called a composite state.

• A composite state may contain either concurrent (orthogonal) or sequential (disjoint)

substates.

Sequential Substates

• modeling the behavior of an ATM. There are three basic states in which this system

might be: Idle (waiting for customer interaction), Active (handling a customer's

transaction), and Maintenance (perhaps having its cash store replenished). While Active:

Validate the customer, select a transaction, process the transaction, and then print a

receipt.

• problem here is that, at any stage in this behavior, the customer might decide to cancel

the transaction, returning the ATM to its Idle state

• Using sequential substates, there's a simpler way to model this problem, as Figure shows.

Here, the Active state has a substructure, containing the substates Validating, Selecting,

Processing, and Printing.


History States

• A state machine describes the dynamic aspects of an object whose current behavior

depends on its past

• A history state allows a composite state that contains sequential substates to remember

the last substate that was active in it prior to the transition from the composite state. As

Figure shows, you represent a shallow history state as a small circle containing the

symbol H.

Concurrent Substates

• These substates let you specify two or more state machines that execute in parallel in the

context of the enclosing object.

• Execution of these two concurrent substates continues in parallel. Eventually, each nested

state machine reaches its final state


Pseudo States

1.Choice Pseudo-State

A choice pseudo-state is shown as a diamond with one transition is arriving and two or more

transitions leaving. The following diagram shows that whichever state arrived at, after the choice

pseudo-state, is dependent on the message format selected during execution of the previous state.

2. Junction Pseudo-State

• Junction pseudo-states are used to chain together multiple transitions.

• A single junction can have one or more incoming, and one or more outgoing,

transitions; a guard can be applied to each transition. Junctions are semantic-free; a

junction that splits an incoming transition into multiple outgoing transitions

realizes a static conditional branch, as opposed to a choice pseudo-state which

realizes a dynamic conditional branch.

Terminate Pseudo-State

• Entering a terminate pseudo-state indicates that the lifeline of the state machine has

ended.

• A terminate pseudo-state is notated as a cross.


Activity diagrams

• one of the five diagrams in the UML for modeling the dynamic aspects of systems.

• It is essentially a flowchart, showing flow of control from activity to activity.

• show the workflow from a start point to the finish point detailing the many decision

paths that exist in the progression of events contained in the activity.

• They may be used to detail situations where parallel processing may occur in the

execution of some activities.

• Activity diagrams are useful for business modeling where they are

used for detailing the processes involved in business activities.

• An activity is an ongoing nonatomic execution within a state machine.

• Activities ultimately result in some action, which is made up of executable atomic

computations that result in a change in state of the system or the return of a value.

• Important for modeling the dynamic aspects of a system, but also for constructing

executable systems through forward and reverse engineering.

• Actions encompass calling another operation, sending a signal, creating or destroying an

object, or some pure computation, such as evaluating an expression. Graphically, an

activity diagram is a collection of vertices and arcs.


Common Properties

• Name and graphical contents that are a projection into a model. What distinguishes an

interaction diagram from all other kinds of diagrams is its content.

Contents

- Activity diagrams commonly contain

• Activity states and action states

• Transitions

• Objects

• Notes & constraints

- Activity diagram is a kind of state machine, all the characteristics of state machines

apply. That means that activity diagrams may contain simple and composite states,

branches, forks, and joins.

Action States and Activity States

• flow of control modeled by an activity diagram

• Executable, atomic computations are called action states because they are states of the

system, each representing the execution of an action.

• As Figure shows, you represent an action state using a lozenge shape (a symbol with

horizontal top and bottom and convex sides). Inside that shape, you may write any

expression.


Transitions

• When the action or activity of a state completes, flow of control passes immediately to

the next action or activity state.

• You specify this flow by using transitions to show the path from one action or activity

state to the next action or activity state. In the UML, you represent a transition as a

simple directed line, as Figure shows.

• Triggerless transitions may have guard conditions, meaning that such a transition will

fire only if that condition is met;

Branching

• you can include a branch, which specifies alternate paths taken based on some Boolean

expression.

• As Figure shows, you represent a branch as a diamond. A branch may have one incoming

transition and two or more outgoing ones.

• On each outgoing transition, you place a Boolean expression, which is evaluated only

once on entering the branch

Forking and Joining


• when you are modeling workflows of business processes ,you might encounter flows that

are concurrent.

• In the UML, you use a synchronization bar to specify the forking and joining of these

parallel flows of control.

• A synchronization bar is rendered as a thick horizontal or vertical line.

• For example, consider the concurrent flows involved in controlling an audio-animatronic

device that mimics human speech and gestures.

• As Figure shows, a fork represents the splitting of a single flow of control into two or

more concurrent flows of control. A fork may have one incoming transition and two or

more outgoing transitions, each of which represents an independent flow of control.

• join represents the synchronization of two or more concurrent flows of control.

• A join may have two or more incoming transitions and one outgoing transition

Swimlanes

• useful, especially when you are modeling workflows of business processes, to partition

the activity states on an activity diagram into groups

• each group representing the business organization responsible for those activities.

• In the UML, each group is called a swimlane because, visually, each group is divided

from its neighbor by a vertical solid line, as shown in Figure.

• A swimlane specifies a locus of activities.

• Each swimlane has a name unique within its diagram


Object Flow

• Objects may be involved in the flow of control associated with an activity diagram

• As Figure shows, you can specify the things that are involved in an activity diagram by

placing these objects in the diagram, connected using a dependency to the activity or

transition that creates, destroys, or modifies them.

• This use of dependency relationships and objects is called an object flow because it

represents the participation of an object in a flow of control.

• In addition to showing the flow of an object through an activity diagram, you can also

show how its role, state and attribute values change.

• As shown in the figure, you represent the state of an object by naming its state in

brackets below the object's name.

• Similarly, you can represent the value of an object's attributes by rendering them in a

compartment below the object's name.


Common Uses

• Use activity diagrams to model the dynamic aspects of a system.

• These dynamic aspects may involve the activity of any kind of abstraction in any view of

a system's architecture, including classes (which include active classes), interfaces,

components, and nodes.

• When model the dynamic aspects of a system, you'll typically use activity diagrams in

two ways.

1. To model a workflow

• Focus on activities as viewed by the actors that collaborate with the system.

• Workflows used to visualize, specify, construct, and document business processes that

involve the system you are developing.

• In this use of activity diagrams, modeling object flow is particularly important.

2. To model an operation

• use activity diagrams as flowcharts, to model the details of a computation

• In this use of activity diagrams, the modeling of branch, fork, and join states is

particularly important.

• The context of an activity diagram used in this way involves the parameters of the

operation and its local objects.

Documents

UNIT-IV Behavioral Diagrams (08 Hrs, 16 Marks) · 2017-02-27 · 1 By: Prof. Pankaj R. Patil | Subject: OOMD UNIT-IV Behavioral Diagrams (08 Hrs, 16 Marks) a. Use case Diagram Names,