C:\documents and settings\student\desktop\swaroop uml
-
Upload
satyaiswaroop -
Category
Education
-
view
1.046 -
download
1
Transcript of C:\documents and settings\student\desktop\swaroop uml
Short Introduction into UML
Use Cases, State Charts and Activity Charts
2
Behavioral Elements
Model Management
Foundation
Use Cases State Machines Activity GraphsCollaborations
Common Behavior
UML Overview
3
Use Case Modeling
What is use case modeling? Core concepts Diagram tour When to model use cases Modeling tips Example: Online HR System
4
What is use case modeling?
use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
5
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
actor A coherent set of roles that users of use cases play when interacting with these use cases.
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
UseCaseNam e
ActorNam e
6
Construct Description Syntax
association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.
generalization A taxonomic relationship between a more general use case and a more specific use case.
extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.
Use Case Modeling: Core Relationships
<<extend>>
7
Construct Description Syntax
include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.
Use Case Modeling: Core Relationships (cont’d)
<<include>>
8
Shows use cases, actor and their relationships
Use case internals can be specified by text and/or interaction diagrams
Kinds use case diagram use case description
Use Case Diagram Tour
9
Fig. 3-53, UML Notation Guide
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
F ill orde rs
Shipping Clerk
status
order
Use Case Diagram
10
Fig. 3-54, UML Notation Guide
Use Case Relationships
additional requests :
OrderProduct
SupplyArrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
11
Fig. 3-55, UML Notation Guide
Actor Relationships
EstablishCredit
PlaceOrder
Salesperson
Supervisor
1 *
1 *
12
Use Case Description: Change Flight
Actors: traveler, client account db, airline reservation systemPreconditions:
Traveler has logged on to the system and selected ‘change flight itinerary’ option
Basic course System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary.
Alternative courses If no flights are available then …
13
When to model use cases Model user requirements with use
cases. Model test scenarios with use cases. If you are using a use-case driven
method start with use cases and derive your
structural and behavioral models from it.
If you are not using a use-case driven method make sure that your use cases are
consistent with your structural and behavioral models.
14
Use Case Modeling Tips
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams
Factor out common usages that are required by multiple use cases
If the usage is required use <<include>> If the base use case is complete and the usage may be
optional, consider use <<extend>> A use case diagram should
contain only use cases at the same level of abstraction include only actors who are required
Large numbers of use cases should be organized into packages
15
Example: Online HR System
Online HR System
LocateEm ployees
UpdateEm ployee
Profile
Update Benefits
Access TravelSystem
Access PayRecords
Em ployee
M anager
Healthcare Plan System
{if currentMonth = Oct.}
{readOnly}
Insurance P lan System
16
Online HR System: Use Case Relationships
Update M edicalP lan
Update DentalP lan
Update Benefits______________Extension pointsbenefit options:
after required enrollm ents
UpdateInsurance P lan
Em ployee
<<include>> <<include>> <<include>>
ElectReim bursem entfor Healthcare
Elect StockPurchase
<<extend>>em ployee requestsstock purchase option
<<extend>>em ployee requestsreim bursem ent option
extensioncondition
extension pointname andlocation
17
Online HR System: Update Benefits Use
Case
Actors: employee, employee account db, healthcare plan system, insurance plan systemPreconditions:
Employee has logged on to the system and selected ‘update benefits’ option
Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. …
Alternative courses If health plan is not available in the employee’s area the employee is informed and asked to select another plan...
18
State Machines Overview
Basic State Machine Concepts Statecharts and Objects Advanced Modeling Concepts Wrap Up
19
ONONONON
Automata
A machine whose output behavior is not only a direct consequence of the current input, but of some past history of its inputs
Characterized by an internal state which represents this past experience
ONONONONONONONON ONONONON
OFFOFFOFFOFF
20
off
on
State Machine (Automaton) Diagram
Graphical rendering of automata behavior
Lamp OnLamp OnLamp OnLamp On
Lamp OffLamp OffLamp OffLamp Off
off
on
21
Outputs and Actions
As the automaton changes state it can generate outputs:
on
off
Lamp OnLamp Onprint(”on”)print(”on”)Lamp OnLamp Onprint(”on”)print(”on”)
Lamp Lamp OffOff
Lamp Lamp OffOff
off
on
Moore automaton
on
off
Lamp Lamp OnOn
Lamp Lamp OnOn
Lamp Lamp OffOff
Lamp Lamp OffOff
off
on/print(”on”)print(”on”)
Mealy automaton
22
Extended State Machines
Addition of variables (“extended state”)
off
on
Lamp OnLamp OnLamp OnLamp On
Lamp OffLamp OffLamp OffLamp Off
off
on/ctr := ctr + 1
ctr : Integerctr : Integerctr : Integerctr : Integer
23
A Bit of Theory
An extended (Mealy) state machine is defined by: a set of input signals (input alphabet) a set of output signals (output alphabet) a set of states a set of transitions
triggering signal action
a set of extended state variables an initial state designation a set of final states (if terminating
automaton)
24
top
Basic UML Statechart Diagram
ReadyReadyReadyReady
stop
/ctr := 0stop
StateStateStateState
TriggerTriggerTriggerTrigger
ActionActionActionAction
Initial Initial pseudostatepseudostate
Initial Initial pseudostatepseudostate
TransitionTransitionTransitionTransition
Final Final statestateFinal Final statestate
DoneDoneDoneDone
““top” statetop” state““top” statetop” state
25
What Kind of Behavior?
In general, state machines are suitable for describing event-driven, discrete behavior inappropriate for modeling continuous
behavior
timetime
thresholdthreshold
26
Event-Driven Behavior
Event = a type of observable occurrence interactions:
synchronous object operation invocation (call event) asynchronous signal reception (signal event)
occurrence of time instants (time event) interval expiry calendar/clock time
change in value of some entity (change event) Event Instance = an instance of an event
(type) occurs at a particular time instant and has no
duration
27
The Behavior of What?
In principle, anything that manifests event-driven behavior NB: there is no support currently in
UML for modeling continuous behavior In practice:
the behavior of individual objects object interactions
The dynamic semantics of UML state machines are currently mainly specified for the case of active objects
28
Basic State Machine Concepts
Statecharts and Objects
Advanced Modeling Concepts
Wrap Up
29
Object Behavior - General Model
Simple server model:
HandleHandleRequestRequest
HandleHandleRequestRequest
InitializeInitializeObjectObject
InitializeInitializeObjectObject
TerminateTerminateObjectObject
TerminateTerminateObjectObject
Wait forWait forRequestRequest
Wait forWait forRequestRequest
void:offHook (); {busy = true; obj.reqDialtone(); … };
Handling depends on Handling depends on specific request typespecific request type
Handling depends on Handling depends on specific request typespecific request type
30
Object Behavior and State Machines
Direct mapping:
HandleHandleEventEvent
InitializeInitializeObjectObject
TerminateTerminateObjectObject
Wait forWait forEventEvent
on
off
Lamp Lamp OnOn
Lamp Lamp OnOn
Lamp Lamp OffOff
Lamp Lamp OffOff
off
on/print(”on”)
stop
31
HandleHandleRequestRequest
HandleHandleRequestRequest
InitializeInitializeObjectObject
InitializeInitializeObjectObject
TerminateTerminateObjectObject
TerminateTerminateObjectObject
Wait forWait forRequestRequest
Wait forWait forRequestRequest
HandleHandleRequestRequest
HandleHandleRequestRequest
InitializeInitializeObjectObject
InitializeInitializeObjectObject
TerminateTerminateObjectObject
TerminateTerminateObjectObject
Wait forWait forRequestRequest
Wait forWait forRequestRequest
Object and Threads
•Passive objects: depend on external power (thread of execution)•Active objects: self-powered (own thread of execution)
32
Passive Objects: Dynamic Semantics
•Encapsulation does not protect the object from concurrency conflicts!•Explicit synchronization is still required
HandleHandleRequestRequest
HandleHandleRequestRequest
InitializeInitializeObjectObject
InitializeInitializeObjectObject
TerminateTerminateObjectObject
TerminateTerminateObjectObject
Wait forWait forRequestRequest
Wait forWait forRequestRequest
33
anActiveObjectanActiveObject
#currentEvent : Event#currentEvent : Event
+ start ( )+ start ( )+ poll ( )+ poll ( )+ stop ( )+ stop ( )
Active Objects and State Machines
Objects that encapsulate own thread of execution
created
ready
start/^master.ready()
poll/^master.ack()
stop/
poll/defer
ready
created
start start/^master.ready() ready
34
Active Objects: Dynamic Semantics
Run-to-completion model: •serialized event handling •eliminates internal concurrency•minimal context switching overhead
ActiveObject:
35
Active1Active1Active1Active1 Active2Active2Active2Active2
The Run-to-Completion Model
A high priority event for (another) active object will preempt an active object that is handling a low-priority event
hi
hi
lo
36
Basic State Machine Concepts
Statecharts and Objects
Advanced Modeling Concepts
Wrap Up
37
State Entry and Exit Actions
A dynamic assertion mechanism
LampOnLampOnLampOnLampOn
entry/lamp.on();
exit/lamp.off();
e1e1
e2e2
38
Resulting action sequence:Resulting action sequence:printf(“exiting”);printf(“exiting”);printf(“to off”);printf(“to off”);lamp.off();lamp.off();
Resulting action sequence:Resulting action sequence:printf(“exiting”);printf(“exiting”);printf(“to off”);printf(“to off”);lamp.off();lamp.off();
Order of Actions: Simple Case
Exit actions prefix transition actions
Entry action postfix transition actions
printf(“exiting”);printf(“exiting”);printf(“needless”);printf(“needless”);lamp.off();lamp.off();
printf(“exiting”);printf(“exiting”);printf(“needless”);printf(“needless”);lamp.off();lamp.off();
off/printf(“needless”);off/printf(“needless”);
off/printf(“to off”);off/printf(“to off”);LampOffLampOffLampOffLampOff
entry/lamp.off();entry/lamp.off();
exit/printf(“exiting”);exit/printf(“exiting”);
LampOnLampOnLampOnLampOn
entry/lamp.on();entry/lamp.on();
exit/printf(“exiting”);exit/printf(“exiting”);
39
Internal Transitions
Self-transitions that bypass entry and exit actions
LampOffLampOffLampOffLampOff
entry/lamp.off();entry/lamp.off();
exit/printf(“exiting”);exit/printf(“exiting”);
off/null;
Internal transitionInternal transitiontriggered by triggered by an “off” eventan “off” event
Internal transitionInternal transitiontriggered by triggered by an “off” eventan “off” event
40
ErrorErrorErrorError
entry/printf(“error!”)entry/printf(“error!”)
State (“Do”) Activities
Forks a concurrent thread that executes until: the action completes or the state is exited through an
outgoing transition
do/while (true) alarm.ring();
““do” activitydo” activity““do” activitydo” activity
41
Guards
Conditional execution of transitions guards (Boolean predicates) must be side-effect free
SellingSellingSellingSelling
UnhappyUnhappyUnhappyUnhappy
HappyHappyHappyHappy
bid bid [(value >= 100) & (value < 200)] /sell /sell
bid bid [value >= 200] /sell /sell
bid bid [value < 100] /reject /reject
42
Static Conditional Branching
Merely a graphical shortcut for convenient rendering of decision trees
[(value >= 100) & (value < 200)] /sell /sell
[value >= 200] /sell /sell
[value < 100] /reject /reject
SellingSellingSellingSelling
UnhappyUnhappyUnhappyUnhappy
HappyHappyHappyHappy
bidbid
43
bid /gain := calculatePotentialGain(value)
SellingSellingSellingSelling
UnhappyUnhappyUnhappyUnhappy
HappyHappyHappyHappy
Dynamic Conditional Branching
Choice pseudostate: guards are evaluated at the instant when the decision point is reached
[(gain >= 100) & (gain < 200)] /sell /sell
[gain >= 200] /sell /sell
[gain < 100] /reject /reject
DynamicDynamicchoicepointchoicepointDynamicDynamic
choicepointchoicepoint
44
Hierarchical State Machines
Graduated attack on complexity states decomposed into state
machinesLampFlashingLampFlashingLampFlashingLampFlashingflash/flash/
1sec/1sec/1sec/1sec/
FlashOffFlashOffFlashOffFlashOff
entry/lamp.off()entry/lamp.off()
FlashOnFlashOnFlashOnFlashOn
entry/lamp.on()entry/lamp.on()off/off/
LampOffLampOffLampOffLampOff
entry/lamp.off()entry/lamp.off()
LampOnLampOnLampOnLampOn
entry/lamp.on()entry/lamp.on()
on/on/
on/on/on/on/
45
“Stub” Notation
Notational shortcut: no semantic significance
LampFlashingLampFlashingLampFlashingLampFlashingflash/flash/
on/on/
FlashOnFlashOn
FlashOffFlashOff
off/off/
LampOffLampOffLampOffLampOff
entry/lamp.off()entry/lamp.off()
LampOnLampOnLampOnLampOn
entry/lamp.on()entry/lamp.on()
on/on/ on/on/
46
LampFlashingLampFlashingLampFlashingLampFlashing
1sec/1sec/1sec/1sec/
FlashOffFlashOffFlashOffFlashOff
entry/lamp.off()entry/lamp.off()
FlashOnFlashOnFlashOnFlashOn
entry/lamp.on()entry/lamp.on()off/off/
LampOffLampOffLampOffLampOff
entry/lamp.off()entry/lamp.off()
LampOnLampOnLampOnLampOn
entry/lamp.on()entry/lamp.on()
on/on/
Group Transitions
Higher-level transitions
flash/flash/
on/on/
Default transition toDefault transition tothe initial pseudostatethe initial pseudostateDefault transition toDefault transition to
the initial pseudostatethe initial pseudostate
Group transitionGroup transitionGroup transitionGroup transition
47
Completion Transitions
Triggered by a completion event generated automatically when an
immediately nested state machine terminates
CommittingCommittingCommittingCommitting
Phase1Phase1Phase1Phase1
Phase2Phase2Phase2Phase2CommitDoneCommitDoneCommitDoneCommitDone
completion completion transition (no trigger)transition (no trigger)
completion completion transition (no trigger)transition (no trigger)
48
LampFlashingLampFlashingLampFlashingLampFlashing
off/off/
FlashOffFlashOffFlashOffFlashOff
FlashOnFlashOnFlashOnFlashOn
Triggering Rules
Two or more transitions may have the same event trigger innermost transition takes precedence event is discarded whether or not it triggers
a transition
on/
on/
49
Deferred Events
Events can be retained if they do not trigger a transition
off/off/
LampOnLampOnLampOnLampOn
entry/lamp.on()entry/lamp.on()
on/on/
LampOffLampOffLampOffLampOff
entry/lamp.off()entry/lamp.off()
off/deferoff/defer
Deferred eventDeferred eventDeferred eventDeferred event
50
Order of Actions: Complex Case
Same approach as for the simple case
S1S1exit/exS1exit/exS1
S1S1exit/exS1exit/exS1
S11S11exit/exS11exit/exS11
S11S11exit/exS11exit/exS11
S2S2entry/enS2entry/enS2
S2S2entry/enS2entry/enS2
S21S21entry/enS21entry/enS21
S21S21entry/enS21entry/enS21
initS2initS2E/actEE/actE
Actions execution sequence:
exS11 exS1 actE enS2 initS2 enS21
51
suspend/suspend/
History
Return to a previously visited hierarchical state deep and shallow history options
DiagnosingDiagnosingDiagnosingDiagnosing
Diagnostic1Diagnostic1Diagnostic1Diagnostic1
Step11Step11Step11Step11
Step12Step12Step12Step12
Diagnostic2Diagnostic2Diagnostic2Diagnostic2
Step21Step21Step21Step21
Step22Step22Step22Step22resume/resume/H*H*H*H*
52
Orthogonality
Multiple simultaneous perspectives on the same entity
ChildChild
AdultAdult
RetireeRetiree
ageage
PoorPoor
RichRich
financialStatusfinancialStatus
53
Orthogonal Regions
Combine multiple simultaneous descriptions
ChildChild
AdultAdult
RetireeRetiree
ageage
PoorPoor
RichRich
financialStatusfinancialStatus
PoorPoor
RichRich
financialStatusfinancialStatus
ChildChild
AdultAdult
RetireeRetiree
ageage
54
OutlawOutlawOutlawOutlaw
LawAbidingLawAbidingLawAbidingLawAbiding PoorPoorPoorPoor
RichRichRichRich
financialStatusfinancialStatuslegalStatuslegalStatus
Orthogonal Regions - Semantics
All mutually orthogonal regions detect the same events and respond to them “simultaneously” usually reduces to interleaving of some kind
robBank/robBank/ robBank/robBank/
55
Catch22Catch22Catch22Catch22
sanityStatussanityStatus flightStatusflightStatus
Interactions Between Regions
Typically through shared variables or awareness of other regions’ state changes
(flying)/(flying)/
CrazyCrazyentry/sane := false;entry/sane := false;
CrazyCrazyentry/sane := false;entry/sane := false;
SaneSaneentry/sane := true;entry/sane := true;
SaneSaneentry/sane := true;entry/sane := true;
requestrequestGrounding/Grounding/
FlyingFlyingentry/flying := true;entry/flying := true;
FlyingFlyingentry/flying := true;entry/flying := true;
GroundedGroundedentry/flying := false;entry/flying := false;
GroundedGroundedentry/flying := false;entry/flying := false;
(sane)/(sane)/
(~sane)/(~sane)/
sane : Booleansane : Booleansane : Booleansane : Boolean
flying : Booleanflying : Booleanflying : Booleanflying : Boolean
56
Transition Forks and Joins
For transitions into/out of orthogonal regions:
StaffStaffMemberMember
StaffStaffMemberMember
employeeemployee
ChildChildChildChild AdultAdultAdultAdult RetireeRetireeRetireeRetiree
ageage
ManagerManagerManagerManager
57
Common Misuse of Orthogonality
Using regions to model independent objects
ChildChild
AdultAdult
RetireeRetiree
ChildChild
AdultAdult
RetireeRetiree
Person1Person1 Person2Person2
Person1Person1 Person2Person2
58
Basic State Machine Concepts
Statecharts and Objects
Advanced Modeling Concepts
Wrap Up
59
Wrap Up: Statecharts
UML uses an object-oriented variant of Harel’s statecharts adjusted to software modeling needs
Used to model event-driven (reactive) behavior well-suited to the server model inherent in
the object paradigm Primary use for modeling the behavior
of active event-driven objects systems modeled as networks of
collaborating state machines run-to-completion paradigm significantly
simplifies concurrency management
60
Wrap Up: Statecharts (cont’d)
Includes a number of sophisticated features that realize common state-machine usage patterns: entry/exit actions state activities dynamic and static conditional branching
Also, provides hierarchical modeling for dealing with very complex systems hierarchical states hierarchical transitions orthogonality
61
Activity Diagram Applications
Intended for applications that need control flow or object/data flow models …
... rather than event-driven models like state machines.
For example: business process modeling and workflow.
The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs.
62
Activity Diagrams Based on State Machines
Currently activity graphs are modeled as a kind of state machine.
Modeler doesn't normally need to be aware of this sleight-of-hand ...
... but will notice that "state" is used in the element names.
Activity graphs will become independent of state machines in UML 2.0.
63
Just like their state machine counterparts (simple state and submachine state) except that ...
... transitions coming out of them are taken when the step is finished, rather than being triggered by a external event, ...
... and they support dynamic concurrency.
Kinds of Steps in Activity Diagrams
Action Action (State)
Subactivity Subactivity (State)
64
Action (State)
An action is used for anything that does not directly start another activity graph, like invoking an operation on an object, or running a user-specified action.
However, an action can invoke an operation that has another activity graph as a method (possible polymorphism).
Action
65
Subactivity (State)
A subactivity (state) starts another activity graph without using an operation.
Used for functional decomposition, non-polymorphic applications, like many workflow systems.
The invoked activity graph can be used by many subactivity states.
Subactivity
66
Example
POEmployee.sortMail Deliver Mail
POEmployee
sortMail() Check OutTruck
Put MailIn Boxes
Deliver Mail
67
POEmployee
sortMail()
Activity Graph as Method
Application is completely OO when all action states invoke operations
All activity graphs are methods for operations.
POEmployee.sortMail POEmployee.deliverMail
deliverMail()«realize»
Check OutTruck
Put MailIn Boxes
PO Employee Deliver Mail Method
68
Dynamic concurrency
Applies to actions and subactivities. Not inherited from state machines. Invokes an action or subactivity any number of times in
parallel, as determined by an expression evaluated at runtime. Expression also determines arguments.
Upper right-hand corner shows a multiplicity restricting the number of parallel invocations.
Outgoing transition triggered when all invocations are done.
Currently no standard notation for concurrency expression or how arguments are accessed by actions. Attach a note as workaround for expression. Issue for UML 2.0.
Action/Subactivity *
69
Object Flow (State)
A special sort of step (state) that represents the availability of a particular kind of object, perhaps in a particular state.
No action or subactivity is invoked and control passes immediately to the next step (state).
Places constraints on input and output parameters of steps before and after it.
Class[State]
70
Object Flow (State)
Take Order must have an output parameter giving an order, or one of its subtypes.
Fill Order must have an input parameter taking an order, or one of its supertypes.
Dashed lines used with object flow have the same semantics as any other state transition.
Order[Taken]
Take Order Fill Order
71
Coordinating Steps
Initial state
Final state
Fork and join
Inherited from state machines
72
Decision point and merge ( ) are inherited from state machines.
For modeling conventional flow chart decisions.
Coordinating Steps
CalculateCost
ChargeAccount
GetAuthorization
[cost < $50]
[cost >= $50]
73
Synch state ( ) is inherited from state machines but used mostly in activity graphs.
Provides communication capability between parallel processes.
Coordinating Steps
State machinenotation
InspectInstall
Foundation
BuildFrame
InstallElectricity
in Foundation
PutOn
Roof
InstallElectricityIn Frame
InstallElectricityOutside
InstallWalls
* *
74
Convenience Features (Synch State)
Forks and joins do not require composite states.
Synch states may be omitted for the common case (unlimited bound and one incoming and outgoing transition).
BuildFrame
InstallFoundation
InstallElectricity
in Foundation
PutOn
Roof
InstallElectricityIn Frame
InstallElectricityOutside
InstallWalls
Inspect
Activity diagramnotation
75
Convenience Features (Synch State)
Object flow states can be synch states
O bj[S2]
A11 A12 A13
A21 A22 A23
76
Convenience Features
Fork transitions can have guards.
RegisterBug
EvaluateImpact
FixBug
RevisePlan
ReleaseFix
TestFix
[ priority = 1]
RegisterBug
EvaluateImpact
FixBug
RevisePlan
ReleaseFix
TestFix
[ priority = 1]
[else]
Instead of doing this:
77
Convenience Features
Partitions are a grouping mechanism. Swimlanes are the notation for partitions. They do not provide domain-specific
semantics. Tools can generate swimlane presentation
from domain-specific information without partitions.
RegisterBug
EvaluateImpact
FixBug
RevisePlan
ReleaseFix
TestFix
[ priority = 1]
Management
Support
Engineering
78
Convenience Features
Signal send icon
Signal
CoffeePot
Wake Up
Get Cups
Turn on Coffee Pot
Coffee Done
Drink Coffee
Signal
… translates to a transition with a send action.
Signal receipt icon
… translates to a wait state (a state with no action and a signal trigger event).
79
Case
Stu
dy
partition
Submission Team Task Force Revision Task Force
Issue RFP
Evaluate initialsubmissions
Submitspecification
draft
Collaborate withcompetitivesubmitters
Developtechnology
specification
action state
RFP[issued]
[optional]
control flow
Finalizespecification
Specification[initial
proposal]
input value
Begin
object flow
initial state
join of control
conditionalfork
fork of control
Specification[final
proposal]
Ad
ap
ted
fro
mK
ob
ryn
, “U
ML
20
01
”C
om
mu
nic
atio
ns
of
the
AC
MO
cto
be
r 1
99
9
80
Case
Stu
dy
Ad
ap
ted
fro
mK
ob
ryn
, “U
ML
20
01
”C
om
mu
nic
atio
ns
of
the
AC
MO
cto
be
r 1
99
9
Evaluate initialsubmissions
Evaluate finalsubmissions
Vote torecommend
Enhancespecification
Implementspecification
Revisespecification
Finalizespecification
Specification[final
proposal]
Specification[adopted]
Recommendrevision
Specification[revised]
[NO][YES]
[else] [Enhanced]
decision
final state
guard
Collaborate withcompetitivesubmitters
81
When to Use Activity Diagrams
Use activity diagrams when the behavior you are modeling ... does not depend much on external
events. mostly has steps that run to completion,
rather than being interrupted by events. requires object/data flow between steps. is being constructed at a stage when
you are more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).
82
Activity Diagram Modeling Tips
Control flow and object flow are not separate. Both are modeled with state transitions.
Dashed object flow lines are also control flow.
You can mix state machine and control/object flow constructs on the same diagram (though you probably do not want to).
83
Activity Diagram Modeling Tips
RequestReturn
Get ReturnNumber
Ship Item
Item[returned]
ReceiveItem
RestockItem
CreditAccount
Item[available]
Customer Telesales WarehouseAccountingFrom UML User Guide:
84
Act
ivit
y M
odelin
g T
ips
RequestReturn
Get ReturnNumber
Ship Item
Item[returned]
ReceiveItem
RestockItem
CreditAccount Item
[available]
Customer Telesales WarehouseAccounting
85
Activity Diagram Modeling Tips Activity diagrams inherit from state machines
the requirement for well-structured nesting of composite states.
This means you should either model as if composite states were there by matching all forks/decisions with a correspond join/merges …
… or check that the diagram can be translated to one that is well-nested.
This insures that diagram is executable under state machine semantics.
86
Activity Diagram Modeling Tips
Well-nested:
87
Not well-nested:
Activity Diagram Modeling Tips
Apply structured coding principles. (Be careful with goto’s!)
88
Activity Diagram Modeling Tips
Can be translated to well-nesteddiagram on earlier slide:
89
Wrap Up: Activity Diagrams
Use Activity Diagrams for applications that are primarily control and data-driven, like business modeling …
… rather than event-driven applications like embedded systems.
Activity diagrams are a kind of state machine until UML 2.0 …
… so control and object/data flow do not have separate semantics.
UML 1.3 has new features for business modeling that increase power and convenience. Check it out and give feedback!