Unit VI Behavior Modeling

Interactions
An interaction is a behavior that comprises a set of messages exchanged among a set of objects
within a context to accomplish a purpose.
A message is a specifcation of a communication between objects that conveys information with
the expectation that activity will ensue.
Context
We can use interactions to visualize, specify, construct, and document the semantics of a class
We may fnd an interaction wherever objects are linked to one another.
Well fnd interactions in the collaboration of objects that exist in the context of your system or
subsystem.
We will also fnd interactions in the context of an operation.
We might create interactions that show how the attributes of that class collaborate with one
another
!inally, youll fnd interactions in the context of a class.
Objects and Roles
"he objects that participate in an interaction are either concrete things or prototypical things.
As a concrete thing, an object represents something in the real world. !or example, p, an
instance of the class #erson, might denote a particular human
As a prototypical thing, p might represent any instance of #erson.
Although abstract classes and interfaces, by defnition, may not have any direct instances, you
may fnd instances of these things in an interaction
$uch instances do not represent direct instances of the abstract class or of the interface, but
may represent, respectively, indirect %or prototypical& instances of any concrete children of the
abstract class of some concrete class that realizes that interface.
Links
A link is a semantic connection among objects. 'n general, a link is an instance of an association
Wherever a class has an association to another class, there may be a link between the instances
of the two classes. Wherever there is a link between two objects, one object can send a
message to the other object
A link specifes a path along which one object can dispatch a message to another %or the same&
object.
Links and Associations
1
Unit VI Behavior Modeling
We can adorn the appropriate end of the link with any of the following standard stereotypes
association $pecifes that the corresponding object is visible by association
self $pecifes that the corresponding object is visible because it is the dispatcher of
the operation
global $pecifes that the corresponding object is visible because it is in an enclosing
scope
local $pecifes that the corresponding object is visible because it is in a local scope
parameter $pecifes that the corresponding object is visible because it is a parameter
Messages
A message is the specifcation of a communication among objects that conveys information with
the expectation that activity will ensue.
"he receipt of a message instance may be considered an instance of an event.
When you pass a message, the action that results is an executable statement that forms an
abstraction of a computational procedure. An action may result in a change in state.
'n the ()*, you can model several kinds of actions
+all 'nvokes an operation on an object, an object may send a message to itself, resulting in
the local invocation of an operation
-eturn -eturns a value to the caller
$end $ends a signal to an object
+reate +reates an object
.estroy .estroys an object, an object may commit suicide by destroying itself

"he ()* provides a visual distinction among these kinds of messages, as follows
Messages
When an object calls an operation or sends a signal to another object, you can provide actual
parameters to the message.
$imilarly, when an object returns control to another object, you can model the return value.
Seqencing
When an object passes a message to another object the receiving object might in turn send a
message to another object, which might send a message to yet a di/erent object, and so on.
"his stream of messages forms a se0uence
Any se0uence must have a beginning, the start of every se0uence is rooted in some process or
thread.
Any se0uence will continue as long as the process or thread that owns it lives.
2
Unit VI Behavior Modeling
)essages are ordered in se0uence by time. "o better visualize the se0uence of a message, you
can explicitly model the order of the message relative to the start of the se0uence by prefxing
the message with a se0uence number set apart by a colon separator
)ost commonly, you can specify a !rocedral or nested "o# o$ control, rendered using a
flled solid arrowhead
%rocedral Seqence
We can specify a 1at 1ow of control, rendered using a stick arrowhead, to model the
nonprocedural progression of control from step to step.
&lat Seqence
"ypically, youll use 1at se0uences only when modeling interactions in the context of use cases
that involve the system as a whole, together with actors outside the system.
$uch se0uences are often 1at because control simply progresses from step to step, without any
consideration for nested 1ows of control.
Well want to use procedural se0uences, because they represent ordinary, nested operation calls
of the type you fnd in most programming languages.
Creation' Modi(cation' and )estrction
)ost of the time, the objects you show participating in an interaction exist for the entire
duration of the interaction. 2owever, in some interactions, objects may be created %specifed by
a create message& and destroyed %specifed by a destroy message&.
"he same is true of links3 the relationships among objects may come and go. "o specify if an
object or link enters and4or leaves during an interaction, you can attach one of the following
constraints to the element3
new $pecifes that the instance or link is created during execution of the enclosing interaction
destroye
d
$pecifes that the instance or link is destroyed prior to completion of execution of the
enclosing interaction
transient $pecifes that the instance or link is created during execution of the enclosing interaction
but is destroyed before completion of execution

$pecifes that the instance or link is created during execution of the enclosing interaction but is
destroyed before completion of execution
$pecifes that the instance or link is created during execution of the enclosing interaction but is
destroyed before completion of execution
Re!resentation
When you model an interaction, you typically include both objects and messages
We can visualize those objects and messages involved in an interaction in two ways
o 5y emphasizing the time ordering of its messages
o by emphasizing the structural organization of the objects that send and receive
messages.
'n the ()*, the frst kind of representation is called a se0uence diagram
3
Unit VI Behavior Modeling
"he second kind of representation is called a collaboration diagram
5oth se0uence diagrams and collaboration diagrams are kinds of interaction diagrams
$e0uence diagrams and collaboration diagrams are largely isomorphic
$e0uence diagrams permit you to model the lifeline of an object.
+ollaboration diagrams permit you to model the structural links that may exist among the
objects in an interaction.
Co**on Modeling +echniqes
Modeling a &lo# o$ Control
"he most common purpose for which youll use interactions is to model the 1ow of control that
characterizes the behavior of a system as a whole, including use cases, patterns, mechanisms,
and frameworks, or the behavior of a class or an individual operation.
classes, interfaces, components, nodes, and their relationships model the static aspects of your
system
'nteractions model its dynamic aspects of your system.
"o model a 1ow of control
o $et the context for the interaction, whether it is the system as a whole, a class, or an
individual operation.
o $et the stage for the interaction by identifying which objects play a role, set their initial
properties, including their attribute values, state, and role.
o 'f your model emphasizes the structural organization of these objects, identify the links
that connect them, relevant to the paths of communication that take place in this
interaction. $pecify the nature of the links using the ()*s standard stereotypes and
constraints, as necessary.
o 'n time order, specify the messages that pass from object to object. As necessary,
distinguish the di/erent kinds of messages, include parameters and return values to
convey the necessary detail of this interaction.
o Also to convey the necessary detail of this interaction, adorn each object at every
moment in time with its state and role.
"his fgure is an example of a se0uence diagram, which emphasizes the time order of messages.
&lo# o$ Control b, +i*e
"his fgure is semantically e0uivalent to the previous one, but it is drawn as a collaboration
diagram, which emphasizes the structural organization of the objects.
4
Unit VI Behavior Modeling
&lo# o$ Control b, Organi-ation
Use Cases
A use case is a description of a set of se0uences of actions, including variants, that a system
performs to yield an observable result of value to an actor.
6raphically, a use case is rendered as an ellipse.
.a*es
7very use case must have a name that distinguishes it from other use cases. A name is a textual
string.
"hat name alone is known as a si*!le na*e, a !ath na*e is the use case name prefxed by
the name of the package in which that use case lives.
A use case is typically drawn showing only its name
Si*!le and %ath .a*es
Use Cases and Actors
An actor represents a coherent set of roles that users of use cases play when interacting with
these
use cases.
"ypically, an actor represents a role that a human, a hardware device, or another system plays
with a system.
An instance of an actor, therefore, represents an individual interacting with the system in a
specifc way
Actors may be connected to use cases only by association
An association between an actor and a use case indicates that the actor and the use case
communicate with one another, each one possibly sending and receiving messages.

5
Unit VI Behavior Modeling
Actors
Use Cases and &lo# o$ /vents
A use case describes what a system does but it does not specify how it does it.
8ou can specify the behavior of a use case by describing a 1ow of events in text clearly enough
for an outsider to understand it easily
When you write this 1ow 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 1ow
and alternative 1ows of the behavior.
!or example, in the context of an A") system, you might describe the use case 9alidate(ser in the
following way3
Main "o# o$ events0
"he use case starts when the system prompts the +ustomer for a #': number. "he +ustomer can
now enter a #': number via the keypad. "he +ustomer commits the entry by pressing the 7nter
button. "he system then checks this #': number to see if it is valid. 'f the #': number is valid, the
system acknowledges the entry, thus ending the use case.
/xce!tional "o# o$ events0
"he +ustomer can cancel a transaction at any time by pressing the +ancel button, thus restarting
the use case. :o changes are made to the +ustomers account.
/xce!tional "o# o$ events0
"he +ustomer can clear a #': number anytime before committing it and reenter a new #': number.
/xce!tional "o# o$ events0
'f the +ustomer enters an invalid #': number, the use case restarts. 'f this happens three times in a
row, the system cancels the entire transaction, preventing the +ustomer from interacting with the
A") for ;< seconds
Use Cases and Scenarios
"ypically, well frst describe the 1ow of events for a use case in text.
"ypically, well use one se0uence diagram to specify a use cases main 1ow, and variations of
that diagram to specify a use cases exceptional 1ows.
(se case describes a set of se0uences, not just a single se0uence, and it would be impossible to
express all the details of an interesting use case in just one se0uence.
7ach se0uence is called a scenario. A scenario is a specifc se0uence of actions that illustrates
behavior. $cenarios 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
A use case captures the intended behavior of the system you are developing, without having to
specify how that behavior is implemented.
however, you have to implement your use cases, and you do so by creating a society of classes
and other elements that work together to implement the behavior of this use case
"his society of elements, including both its static and dynamic structure, is modeled in the ()*
as a collaboration1
you can explicitly specify the realization of a use case by a collaboration
Use Cases and Collaborations
Organi-ing Use Cases
6
Unit VI Behavior Modeling
We can organize use cases by grouping them in packages in the same manner in which you can
organize classes.
8ou can also organize use cases by specifying generalization, include, and extend relationships
among them.
generalization among use cases is rendered as a solid directed line with a large open arrowhead,
just like generalization among classes.
An inclde relationshi! between use cases means that the base use case explicitly
incorporates the behavior of another use case at a location specifed in the base.
8ou use an include relationship to avoid describing the same 1ow of events several times, by
putting the common behavior in a use case of its own
"he include relationship is essentially an example of delegation=you take a set of
responsibilities of the system and capture it in one place %the included use case&, then let all
other parts of the system %other use cases& include the new aggregation of responsibilities
whenever they need to use that functionality.
include followed by the name of the use case you want to include
8ou render an include relationship as a dependency, stereotyped as include.
An extend relationshi! between use cases means that the base use case implicitly
incorporates the behavior of another use case at a location specifed indirectly by the extending
use case.
"his base use case may be extended only at certain points called, not surprisingly, its extension
points
We use an extend relationship to model the part of a use case the user may see as optional
system behavior.
We may also use an extend relationship to model a separate sub1ow that is executed only under
given conditions.
!inally, we may use an extend relationship to model several 1ows that may be inserted at a
certain point, governed by explicit interaction with an actor.
We render an extend relationship as a dependency, stereotyped as extend.
Other &eatres
(se cases are classifers, so they may have attributes and operations that you may render just
as for classes.
8ou can think of these attributes as the objects inside the use case that you need to describe its
outside behavior. $imilarly, you can think of these operations as the actions of the system you
need to describe a 1ow of events.
"hese objects and operations may be used in your interaction diagrams to specify the behavior
of the use case
As classifers, you can also attach state machines to use cases
We can use state machines as yet another way to describe the behavior represented by a use
case.
Co**on Modeling +echniqes
Modeling the Behavior o$ an /le*ent
"he most common thing for which youll apply use cases is to model the behavior of an element,
whether it is the system as a whole, a subsystem, or a class.
"o model the behavior of an element
'dentify the actors that interact with the element. +andidate actors include groups that
re0uire certain behavior to perform their tasks or that are needed directly or indirectly to
perform the elements functions.
>rganize actors by identifying general and more specialized roles.
!or each actor, consider the primary ways in which that actor interacts with the element.
+onsider also interactions that change the state of the element or its environment or that
involve a response to some event.
+onsider also the exceptional ways in which each actor interacts with the element.
>rganize these behaviors as use cases, applying include and extend relationships to factor
common behavior and distinguish exceptional behavior.
7
Unit VI Behavior Modeling
Modeling the Behavior o$ an /le*ent
Use Case )iagra*
A use case diagram is a diagram that shows a set of use cases and actors and their
relationships.
Contents
(se case diagrams commonly contain
(se cases
Actors
.ependency, generalization, and association relationships
*ike all other diagrams, use case diagrams may contain notes and constraints.
(se case diagrams may also contain packages
>ccasionally, youll want to place instances of use cases in your diagrams, as well, especially
when you want to visualize a specifc executing system.
Co**on Uses
We apply use case diagrams to model the static use case view of a system. "his view primarily
supports the behavior of a system
When you model the static use case view of a system, youll typically apply use case diagrams
in one of two ways.
o "o model the context of a system
o "o model the re0uirements of a system
Modeling the context o$ a s,ste* involves drawing a line around the whole system and
asserting which actors lie outside the system and interact with it.2ere, youll apply use case
diagrams to specify the actors and the meaning of their roles.
Modeling the reqire*ents o$ a s,ste* involves specifying what that system should do %from a
point of view of outside the system&, independent of how that system should do it. 2ere, youll apply
use case diagrams to specify the desired behavior of the system.
8
Unit VI Behavior Modeling
Co**on Modeling +echniqes
Modeling the Context o$ a S,ste*
6iven a system=any system=some things will live inside the system, some things will live outside
it. !or example, in a credit card validation system, youll fnd such things as accounts, transactions,
and fraud detection agents inside the system. $imilarly, youll fnd such things as credit card
customers and retail institutions outside the system. "he things that live inside the system are
responsible for carrying out the behavior that those on the outside expect the system to provide. All
those things on the outside that interact with the system constitute the systems context. "his
context defnes the environment in which that system lives.
o 'n the ()*, you can model the context of a system with a use case diagram, emphasizing the
actors that surround the system.
o "o model the context of a system
o 'dentify the actors that surround the system by considering which groups re0uire help from
the system to perform their tasks, which groups are needed to execute the systems
functions, which groups interact with external hardware or other software systems, and
which groups perform secondary functions for administration and maintenance.
o >rganize actors that are similar to one another in a generalization4specialization hierarchy.
o Where it aids understandability, provide a stereotype for each such actor.
o #opulate a use case diagram with these actors and specify the paths of communication from
each actor to the systems use cases.
o "his same techni0ue applies to modeling the context of a subsystem. A system at one level of
abstraction is often a subsystem of a larger system at a higher level of abstraction. )odeling the
context of a subsystem is therefore useful when you are building systems of interconnected
systems.
Modeling the Context o$ a S,ste*
Modeling the Reqire*ents o$ a S,ste*
o A re0uirement is a design feature, property, or behavior of a system. When you state a systems
re0uirements, you are asserting a contract, established between those things that lie outside
the system and the system itself, which declares what you expect that system to do.
o -e0uirements can be expressed in various forms, from unstructured text to expressions in a
formal language, and everything in between.
o )ost, if not all, of a systems functional re0uirements can be expressed as use cases, and the
()*s use case diagrams are essential for managing these re0uirements.
o "o model the re0uirements of a system,
o 7stablish the context of the system by identifying the actors that surround it.
o !or each actor, consider the behavior that each expects or re0uires the system to provide.
o :ame these common behaviors as use cases.
9
Unit VI Behavior Modeling
o !actor common behavior into new use cases that are used by others, factor variant behavior
into new use cases that extend more main line 1ows.
o )odel these use cases, actors, and their relationships in a use case diagram.
o Adorn these use cases with notes that assert nonfunctional re0uirements, you may have to
attach some of these to the whole system.
o "his same techni0ue applies to modeling the re0uirements of a subsystem
Modeling the Reqire*ents o$ a S,ste*
&or#ard and Reverse /ngineering
o &or#ard engineering is the process of transforming a model into code through a mapping to
an implementation language.
o A use case diagram can be forward engineered to form tests for the element to which it applies.
o 7ach use case in a use case diagram specifes a 1ow of events and these 1ows specify how the
element is expected to behave
o "o forward engineer a use case diagram,
o !or each use case in the diagram, identify its 1ow of events and its exceptional 1ow of
events.
o .epending on how deeply you choose to test, generate a test script for each 1ow, using the
1ows preconditions as the tests initial state and its postconditions as its success criteria.
o As necessary, generate test sca/olding 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 e0uivalent.
o (se tools to run these tests each time you release the element to which the use case
diagram applies.
o Reverse engineering is the process of transforming code into a model through a mapping
from a specifc implementation language.
o "he ()*s use case diagrams simply give you a standard and expressive language in which to
state what you discover.
o "o reverse engineer a use case diagram
o 'dentify each actor that interacts with the system.
o !or each actor, consider the manner in which that actor interacts with the system, changes
the state of the system or its environment, or responds to some event.
o "race the 1ow of events in the executable system relative to each actor. $tart with primary
1ows and only later consider alternative paths.
10
Unit VI Behavior Modeling
o +luster related 1ows by declaring a corresponding use case. +onsider modeling variants
using extend relationships, and consider modeling common 1ows by applying include
relationships.
o -ender these actors and use cases in a use case diagram, and establish their relationships.
Activit, )iagra*s
o An activity diagram shows the 1ow from activity to activity. An is an ongoing nonatomic
execution within a state machine.
o 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.
o Actions encompass calling another operation, sending a signal, creating or destroying an object,
or some pure computation, such as evaluating an expression.
o 6raphically, an activity diagram is a collection of vertices and arcs.
Contents
o Activity diagrams commonly contain
o Activity states and action states
o "ransitions
o >bjects
o *ike all other diagrams, activity diagrams may contain notes and constraints.
Action States and Activit, States
o 7xecutable, atomic computations are called action states because they are states of the
system, each representing the execution of an action.
o We represent an action state using a lozenge shape %a symbol with horizontal top and bottom
and convex sides&. 'nside that shape, you may write any expression.
o Action states cant be decomposed. !urthermore, action states are atomic, meaning that events
may occur, but the work of the action state is not interrupted.
o !inally, the work of an action state is generally considered to take insignifcant execution time.
11
Unit VI Behavior Modeling
Action States
o activit, states can be further decomposed, their activity being represented by other activity
diagrams
o !urthermore, activity states are not atomic, meaning that they may be interrupted and, in
general, are considered to take some duration to complete.
o An action state is an activity state that cannot be further decomposed.
o We can think of an activity state as a composite, whose 1ow of control is made up of other
activity states and action states.
Activit, States
+ransitions
o When the action or activity of a state completes, 1ow of control passes immediately to the next
action or activity state.
o We specify this 1ow by using transitions to show the path from one action or activity state to the
next action or activity state.
o 'n the ()*, you represent a transition as a simple directed line
+riggerless +ransitions
Branching
o As in a 1owchart, you can include a branch, which specifes alternate paths taken based on
some 5oolean expression.
o We represent a branch as a diamond. A branch may have one incoming transition and two or
more outgoing ones.
o >n each outgoing transition, you place a 5oolean expression, which is evaluated only once on
entering the branch.
o >n each outgoing transition, you place a 5oolean expression, which is evaluated only once on
entering the branch. Across all these outgoing transitions, guards should not overlap %otherwise,
the 1ow of control would be ambiguous&, but they should cover all possibilities %otherwise, the
1ow of control would freeze&.
o As a convenience, you can use the keyword else to mark one outgoing transition, representing
the path taken if no other guard expression evaluates to true.
Branching
&orking and 2oining
o When we are modeling work1ows of business processes=we might encounter 1ows that are
concurrent.
o 'n the ()*, you use a synchronization bar to specify the forking and joining of these parallel
1ows of control. A synchronization bar is rendered as a thick horizontal or vertical line.
o &ork represents the splitting of a single 1ow of control into two or more concurrent 1ows of
control
o A fork may have one incoming transition and two or more outgoing transitions, each of which
represents an independent 1ow of control.
12
Unit VI Behavior Modeling
o 5elow the fork, the activities associated with each of these paths continues in parallel.
o +onceptually, the activities of each of these 1ows are truly concurrent, although, in a running
system, these 1ows may be either truly concurrent or se0uential yet interleaved, thus giving
only the illusion of true concurrency.
&orking and 2oining
o A 2oin represents the synchronization of two or more concurrent 1ows of control.
o A join may have two or more incoming transitions and one outgoing transition.
o Above the join, the activities associated with each of these paths continues in parallel.
o At the join, the concurrent 1ows synchronize, meaning that each waits until all incoming
1ows have reached the join, at which point one 1ow of control continues on below the join.
S#i*lanes
o Well fnd it useful, especially when you are modeling work1ows of business processes, to
partition the activity states on an activity diagram into groups, each group representing the
business organization responsible for those activities.
o 'n the ()*, each group is called a swimlane because, visually, each group is divided from its
neighbor by a vertical solid line
o A swimlane specifes a locus of activities
o 7ach swimlane has a name uni0ue within its diagram.
o 7ach swimlane represents a high?level responsibility for part of the overall activity of an activity
diagram, and each swimlane may eventually be implemented by one or more classes.
o 'n an activity diagram partitioned into swimlanes, every activity belongs to exactly one
swimlane, but transitions may cross lanes.
S#i*lanes
Object &lo#
o >bjects may be involved in the 1ow of control associated with an activity diagram.
o We 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
modifes them.
13
Unit VI Behavior Modeling
o "his use of dependency relationships and objects is called an object 1ow because it represents
the participation of an object in a 1ow of control.
o We can also show how its role, state and attribute values change.
o We represent the state of an object by naming its state in brackets below the objects name.
o $imilarly, We can represent the value of an objects attributes by rendering them in a
compartment below the objects name.
Object &lo#
Co**on Uses
We use activity diagrams to model the dynamic aspects of a system
"hese dynamic aspects may involve the activity of any kind of abstraction in any view of a
systems architecture, including classes, interfaces, components, and nodes.
When you model the dynamic aspects of a system, well typically use activity diagrams in two
ways.
"o model a work1ow
"o model an operation
Co**on Modeling +echniqes
Modeling a 3ork"o#
:o software?intensive system exists in isolation, theres always some context in which a system
lives, and that context always encompasses actors that interact with the system.
7specially for mission critical, enterprise software, youll fnd automated systems working in the
context of higher?level business processes.
"hese business processes are kinds of work1ows because they represent the 1ow of work and
objects through the business.
"o model a work1ow,
o 7stablish a focus for the work1ow. !or nontrivial systems, its impossible to show all
interesting work1ows in one diagram.
o $elect the business objects that have the high?level responsibilities for parts of the
overall work1ow. "hese may be real things from the vocabulary of the system, or they
may be more abstract. 'n either case, create a swimlane for each important business
object.
14
Unit VI Behavior Modeling
o 'dentify the preconditions of the work1ows initial state and the postconditions of the
work1ows fnal state. "his is important in helping you model the boundaries of the
work1ow.
o 5eginning at the work1ows initial state, specify the activities and actions that take
place over time and render them in the activity diagram as either activity states or
action states.
o !or complicated actions, or for sets of actions that appear multiple times, collapse these
into activity states, and provide a separate activity diagram that expands on each.
o -ender the transitions that connect these activity and action states. $tart with the
se0uential 1ows in the work1ow frst, next consider branching, and only then consider
forking and joining.
o 'f there are important objects that are involved in the work1ow, render them in the
activity diagram, as well. $how their changing values and state as necessary to
communicate the intent of the object 1ow.

Modeling a 3ork"o#
Modeling an O!eration
An activity diagram can be attached to any modeling element for the purpose of visualizing,
specifying, constructing, and documenting that elements behavior.
8ou can attach activity diagrams to classes, interfaces, components, nodes, use cases, and
collaborations.
"he most common element to which youll attach an activity diagram is an operation.
An activity diagram is simply a 1owchart of an operations actions.
An activity diagrams primary advantage is that all the elements in the diagram are semantically
tied to a rich underlying model.
"o model an operation,
o +ollect the abstractions that are involved in this operation. "his includes the operations
parameters %including its return type, if any&, the attributes of the enclosing class, and
certain neighboring classes.
o 'dentify the preconditions at the operations initial state and the postconditions at the
operations fnal state. Also identify any invariants of the enclosing class that must hold
during the execution of the operation.
o 5eginning at the operations initial state, specify the activities and actions that take
place over time and render them in the activity diagram as either activity states or
action states.
o (se branching as necessary to specify conditional paths and iteration.
o >nly if this operation is owned by an active class, use forking and joining as necessary
to specify parallel 1ows of control.
15
Unit VI Behavior Modeling
Modeling an O!eration
&or#ard and Reverse /ngineering
&or#ard engineering %the creation of code from a model& is possible for activity diagrams,
especially if the context of the diagram is an operation.
!or example, using the previous activity diagram, a forward engineering tool could generate the
following +@@ code for the operation intersection.
#oint *ine33intersection %l 3 *ine& A
if %slope BB l.slope& return #oint%<,<&,
int x B %l.delta ? delta& 4 %slope ? l.slope&,
int y B %slope C x& @ delta,
return #oint%x, y&,
D
Reverse engineering %the creation of a model from code& is also possible for activity diagrams,
especially if the context of the code is the body of an operation.
'n particular, the previous diagram could have been generated from the implementation of the
class *ine.
www.jntuworld.com
16