Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

C:\documents and settings\student\desktop\swaroop uml


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

C:\documents and settings\student\desktop\swaroop uml

  1. 1. Short Introduction into UML Use Cases, State Charts and Activity Charts
  2. 2. UML Overview Behavioral Elements Model Management Foundation Use Cases State Machines Activity Graphs Collaborations Common Behavior
  3. 3. Use Case Modeling <ul><li>What is use case modeling? </li></ul><ul><li>Core concepts </li></ul><ul><li>Diagram tour </li></ul><ul><li>When to model use cases </li></ul><ul><li>Modeling tips </li></ul><ul><li>Example: Online HR System </li></ul>
  4. 4. What is use case modeling? <ul><li>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’). </li></ul>
  5. 5. Use Case Modeling: Core Elements
  6. 6. Use Case Modeling: Core Relationships << extend >>
  7. 7. Use Case Modeling: Core Relationships (cont’d) << include >>
  8. 8. <ul><li>Shows use cases, actor and their relationships </li></ul><ul><li>Use case internals can be specified by text and/or interaction diagrams </li></ul><ul><li>Kinds </li></ul><ul><ul><li>use case diagram </li></ul></ul><ul><ul><li>use case description </li></ul></ul>Use Case Diagram Tour
  9. 9. Use Case Diagram Fig. 3-53, UML Notation Guide
  10. 10. Use Case Relationships Fig. 3-54, UML Notation Guide
  11. 11. Actor Relationships Fig. 3-55, UML Notation Guide
  12. 12. Use Case Description: Change Flight <ul><li>Actors: traveler, client account db, airline reservation system </li></ul><ul><li>Preconditions: </li></ul><ul><ul><li>Traveler has logged on to the system and selected ‘change flight itinerary’ option </li></ul></ul><ul><li>Basic course </li></ul><ul><ul><li>System retrieves traveler’s account and flight itinerary from client account database </li></ul></ul><ul><ul><li>System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. </li></ul></ul><ul><ul><li>System asks traveler for new departure and destination information; traveler provides information. </li></ul></ul><ul><ul><li>If flights are available then </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><ul><li>System displays transaction summary. </li></ul></ul><ul><li>Alternative courses </li></ul><ul><ul><li>If no flights are available then … </li></ul></ul>
  13. 13. When to model use cases <ul><li>Model user requirements with use cases. </li></ul><ul><li>Model test scenarios with use cases. </li></ul><ul><li>If you are using a use-case driven method </li></ul><ul><ul><li>start with use cases and derive your structural and behavioral models from it. </li></ul></ul><ul><li>If you are not using a use-case driven method </li></ul><ul><ul><li>make sure that your use cases are consistent with your structural and behavioral models. </li></ul></ul>
  14. 14. Use Case Modeling Tips <ul><li>Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers </li></ul><ul><li>When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams </li></ul><ul><li>Factor out common usages that are required by multiple use cases </li></ul><ul><ul><li>If the usage is required use <<include>> </li></ul></ul><ul><ul><li>If the base use case is complete and the usage may be optional, consider use <<extend>> </li></ul></ul><ul><li>A use case diagram should </li></ul><ul><ul><li>contain only use cases at the same level of abstraction </li></ul></ul><ul><ul><li>include only actors who are required </li></ul></ul><ul><li>Large numbers of use cases should be organized into packages </li></ul>
  15. 15. Example: Online HR System
  16. 16. Online HR System: Use Case Relationships
  17. 17. Online HR System: Update Benefits Use Case <ul><li>Actors : employee, employee account db, healthcare plan system, insurance plan system </li></ul><ul><li>Preconditions: </li></ul><ul><ul><li>Employee has logged on to the system and selected ‘update benefits’ option </li></ul></ul><ul><li>Basic course </li></ul><ul><ul><li>System retrieves employee account from employee account db </li></ul></ul><ul><ul><li>System asks employee to select medical plan type; include Update Medical Plan. </li></ul></ul><ul><ul><li>System asks employee to select dental plan type; include Update Dental Plan. </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Alternative courses </li></ul><ul><ul><li>If health plan is not available in the employee’s area the employee is informed and asked to select another plan... </li></ul></ul>
  18. 18. State Machines Overview <ul><li>Basic State Machine Concepts </li></ul><ul><li>Statecharts and Objects </li></ul><ul><li>Advanced Modeling Concepts </li></ul><ul><li>Wrap Up </li></ul>
  19. 19. Automata <ul><li>A machine whose output behavior is not only a direct consequence of the current input, but of some past history of its inputs </li></ul><ul><li>Characterized by an internal state which represents this past experience </li></ul>ON ON ON ON OFF
  20. 20. State Machine (Automaton) Diagram <ul><li>Graphical rendering of automata behavior </li></ul>Lamp On Lamp Off off on off on
  21. 21. Outputs and Actions <ul><li>As the automaton changes state it can generate outputs: </li></ul>on off Lamp On print(”on”) Lamp Off off on Moore automaton on off Lamp On Lamp Off off on/ print(”on”) Mealy automaton
  22. 22. Extended State Machines <ul><li>Addition of variables (“extended state”) </li></ul>ctr : Integer off on Lamp On Lamp Off off on/ ctr := ctr + 1
  23. 23. A Bit of Theory <ul><li>An extended (Mealy) state machine is defined by: </li></ul><ul><ul><li>a set of input signals (input alphabet) </li></ul></ul><ul><ul><li>a set of output signals (output alphabet) </li></ul></ul><ul><ul><li>a set of states </li></ul></ul><ul><ul><li>a set of transitions </li></ul></ul><ul><ul><ul><li>triggering signal </li></ul></ul></ul><ul><ul><ul><li>action </li></ul></ul></ul><ul><ul><li>a set of extended state variables </li></ul></ul><ul><ul><li>an initial state designation </li></ul></ul><ul><ul><li>a set of final states (if terminating automaton) </li></ul></ul>
  24. 24. Basic UML Statechart Diagram Ready /ctr := 0 stop State Trigger Action Initial pseudostate Transition Final state Done “ top” state top stop
  25. 25. What Kind of Behavior? <ul><li>In general, state machines are suitable for describing event-driven, discrete behavior </li></ul><ul><ul><li>inappropriate for modeling continuous behavior </li></ul></ul>time threshold
  26. 26. Event-Driven Behavior <ul><li>Event = a type of observable occurrence </li></ul><ul><ul><li>interactions: </li></ul></ul><ul><ul><ul><li>synchronous object operation invocation (call event) </li></ul></ul></ul><ul><ul><ul><li>asynchronous signal reception (signal event) </li></ul></ul></ul><ul><ul><li>occurrence of time instants (time event) </li></ul></ul><ul><ul><ul><li>interval expiry </li></ul></ul></ul><ul><ul><ul><li>calendar/clock time </li></ul></ul></ul><ul><ul><li>change in value of some entity (change event) </li></ul></ul><ul><li>Event Instance = an instance of an event (type) </li></ul><ul><ul><li>occurs at a particular time instant and has no duration </li></ul></ul>
  27. 27. The Behavior of What? <ul><li>In principle, anything that manifests event-driven behavior </li></ul><ul><ul><li>NB: there is no support currently in UML for modeling continuous behavior </li></ul></ul><ul><li>In practice: </li></ul><ul><ul><li>the behavior of individual objects </li></ul></ul><ul><ul><li>object interactions </li></ul></ul><ul><li>The dynamic semantics of UML state machines are currently mainly specified for the case of active objects </li></ul>
  28. 28. Basic State Machine Concepts Statecharts and Objects Advanced Modeling Concepts Wrap Up
  29. 29. Object Behavior - General Model <ul><li>Simple server model: </li></ul>Handle Request Initialize Object Terminate Object Wait for Request Handling depends on specific request type void:offHook (); {busy = true; obj.reqDialtone(); … };
  30. 30. Object Behavior and State Machines <ul><li>Direct mapping: </li></ul>Handle Event Initialize Object Terminate Object Wait for Event on off Lamp On Lamp Off off on/print(”on”) stop
  31. 31. Object and Threads <ul><li>Passive objects: depend on external power (thread of execution) </li></ul><ul><li>Active objects: self-powered (own thread of execution) </li></ul>Handle Request Initialize Object Terminate Object Wait for Request Handle Request Initialize Object Terminate Object Wait for Request
  32. 32. Passive Objects: Dynamic Semantics <ul><li>Encapsulation does not protect the object from concurrency conflicts! </li></ul><ul><li>Explicit synchronization is still required </li></ul>Handle Request Initialize Object Terminate Object Wait for Request
  33. 33. Active Objects and State Machines <ul><li>Objects that encapsulate own thread of execution </li></ul>start/^master.ready() anActiveObject #currentEvent : Event + start ( ) + poll ( ) + stop ( ) created ready start/^master.ready() poll/^master.ack() stop/ poll/defer ready created start ready
  34. 34. Active Objects: Dynamic Semantics <ul><li>Run-to-completion model: </li></ul><ul><ul><li>serialized event handling </li></ul></ul><ul><ul><li>eliminates internal concurrency </li></ul></ul><ul><ul><li>minimal context switching overhead </li></ul></ul>ActiveObject:
  35. 35. The Run-to-Completion Model <ul><li>A high priority event for (another) active object will preempt an active object that is handling a low-priority event </li></ul>Active1 Active2 hi hi lo
  36. 36. Basic State Machine Concepts Statecharts and Objects Advanced Modeling Concepts Wrap Up
  37. 37. State Entry and Exit Actions <ul><li>A dynamic assertion mechanism </li></ul>entry/lamp.on(); exit/; LampOn e1 e2
  38. 38. Order of Actions: Simple Case <ul><li>Exit actions prefix transition actions </li></ul><ul><li>Entry action postfix transition actions </li></ul>Resulting action sequence: printf(“exiting”); printf(“to off”);; printf(“exiting”); printf(“needless”);; off/printf(“needless”); off/printf(“to off”); LampOff entry/; exit/printf(“exiting”); LampOn entry/lamp.on(); exit/printf(“exiting”);
  39. 39. Internal Transitions <ul><li>Self-transitions that bypass entry and exit actions </li></ul>off/null; Internal transition triggered by an “off” event LampOff entry/; exit/printf(“exiting”);
  40. 40. State (“Do”) Activities <ul><li>Forks a concurrent thread that executes until: </li></ul><ul><ul><li>the action completes or </li></ul></ul><ul><ul><li>the state is exited through an outgoing transition </li></ul></ul>do/while (true) alarm.ring(); “ do” activity Error entry/printf(“error!”)
  41. 41. Guards <ul><li>Conditional execution of transitions </li></ul><ul><ul><li>guards (Boolean predicates) must be side-effect free </li></ul></ul>Selling Unhappy Happy bid [(value >= 100) & (value < 200)] /sell bid [value >= 200] /sell bid [value < 100] /reject
  42. 42. Static Conditional Branching <ul><li>Merely a graphical shortcut for convenient rendering of decision trees </li></ul>[(value >= 100) & (value < 200)] /sell [value >= 200] /sell [value < 100] /reject Selling Unhappy Happy bid
  43. 43. Dynamic Conditional Branching <ul><li>Choice pseudostate: guards are evaluated at the instant when the decision point is reached </li></ul>bid / gain := calculatePotentialGain(value) [(gain >= 100) & (gain < 200)] /sell [gain >= 200] /sell [gain < 100] /reject Dynamic choicepoint Selling Unhappy Happy
  44. 44. Hierarchical State Machines <ul><li>Graduated attack on complexity </li></ul><ul><ul><li>states decomposed into state machines </li></ul></ul>LampFlashing flash/ 1sec/ 1sec/ FlashOff entry/ FlashOn entry/lamp.on() off/ LampOff entry/ LampOn entry/lamp.on() on/ on/ on/
  45. 45. “ Stub” Notation <ul><li>Notational shortcut: no semantic significance </li></ul>LampFlashing flash/ on/ FlashOn FlashOff off/ LampOff entry/ LampOn entry/lamp.on() on/ on/
  46. 46. Group Transitions <ul><li>Higher-level transitions </li></ul>LampFlashing Default transition to the initial pseudostate Group transition 1sec/ 1sec/ FlashOff entry/ FlashOn entry/lamp.on() off/ LampOff entry/ LampOn entry/lamp.on() on/ flash/ on/
  47. 47. Completion Transitions <ul><li>Triggered by a completion event </li></ul><ul><ul><li>generated automatically when an immediately nested state machine terminates </li></ul></ul>completion transition (no trigger) Committing Phase1 Phase2 CommitDone
  48. 48. Triggering Rules <ul><li>Two or more transitions may have the same event trigger </li></ul><ul><ul><li>innermost transition takes precedence </li></ul></ul><ul><ul><li>event is discarded whether or not it triggers a transition </li></ul></ul>LampFlashing off/ FlashOff FlashOn on/ on/
  49. 49. Deferred Events <ul><li>Events can be retained if they do not trigger a transition </li></ul>off/ on/ LampOff entry/ off/defer Deferred event LampOn entry/lamp.on()
  50. 50. Order of Actions: Complex Case <ul><li>Same approach as for the simple case </li></ul>initS2 E/actE Actions execution sequence: exS11  exS1  actE  enS2  initS2  enS21 S1 exit/exS1 S11 exit/exS11 S2 entry/enS2 S21 entry/enS21
  51. 51. History <ul><li>Return to a previously visited hierarchical state </li></ul><ul><ul><li>deep and shallow history options </li></ul></ul>Diagnosing Diagnostic1 Diagnostic2 suspend/ Step11 Step12 Step21 Step22 resume/ H*
  52. 52. Orthogonality <ul><li>Multiple simultaneous perspectives on the same entity </li></ul>Child Adult Retiree age Poor Rich financialStatus
  53. 53. Orthogonal Regions <ul><li>Combine multiple simultaneous descriptions </li></ul>Child Adult Retiree age Poor Rich financialStatus Poor Rich financialStatus Child Adult Retiree age
  54. 54. Orthogonal Regions - Semantics <ul><li>All mutually orthogonal regions detect the same events and respond to them “simultaneously” </li></ul><ul><ul><li>usually reduces to interleaving of some kind </li></ul></ul>Outlaw LawAbiding Poor Rich financialStatus legalStatus robBank/ robBank/
  55. 55. Interactions Between Regions <ul><li>Typically through shared variables or awareness of other regions’ state changes </li></ul>sane : Boolean flying : Boolean Catch22 sanityStatus flightStatus (flying)/ Crazy entry/sane := false; Sane entry/sane := true; request Grounding/ Flying entry/flying := true; Grounded entry/flying := false; (sane)/ (~sane)/
  56. 56. Transition Forks and Joins <ul><li>For transitions into/out of orthogonal regions: </li></ul>Staff Member employee Child Adult Retiree age Manager
  57. 57. Common Misuse of Orthogonality <ul><li>Using regions to model independent objects </li></ul>Child Adult Retiree Child Adult Retiree Person1 Person2 Person1 Person2
  58. 58. Basic State Machine Concepts Statecharts and Objects Advanced Modeling Concepts Wrap Up
  59. 59. Wrap Up: Statecharts <ul><li>UML uses an object-oriented variant of Harel’s statecharts </li></ul><ul><ul><li>adjusted to software modeling needs </li></ul></ul><ul><li>Used to model event-driven (reactive) behavior </li></ul><ul><ul><li>well-suited to the server model inherent in the object paradigm </li></ul></ul><ul><li>Primary use for modeling the behavior of active event-driven objects </li></ul><ul><ul><li>systems modeled as networks of collaborating state machines </li></ul></ul><ul><ul><li>run-to-completion paradigm significantly simplifies concurrency management </li></ul></ul>
  60. 60. Wrap Up: Statecharts (cont’d) <ul><li>Includes a number of sophisticated features that realize common state-machine usage patterns: </li></ul><ul><ul><li>entry/exit actions </li></ul></ul><ul><ul><li>state activities </li></ul></ul><ul><ul><li>dynamic and static conditional branching </li></ul></ul><ul><li>Also, provides hierarchical modeling for dealing with very complex systems </li></ul><ul><ul><li>hierarchical states </li></ul></ul><ul><ul><li>hierarchical transitions </li></ul></ul><ul><ul><li>orthogonality </li></ul></ul>
  61. 61. Activity Diagram Applications <ul><li>Intended for applications that need control flow or object/data flow models … </li></ul><ul><li>... rather than event-driven models like state machines. </li></ul><ul><li>For example: business process modeling and workflow. </li></ul><ul><li>The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs. </li></ul>
  62. 62. Activity Diagrams Based on State Machines <ul><li>Currently activity graphs are modeled as a kind of state machine. </li></ul><ul><li>Modeler doesn't normally need to be aware of this sleight-of-hand ... </li></ul><ul><li>... but will notice that &quot;state&quot; is used in the element names. </li></ul><ul><li>Activity graphs will become independent of state machines in UML 2.0. </li></ul>
  63. 63. <ul><li>Just like their state machine counterparts (simple state and submachine state) except that ... </li></ul><ul><li>... transitions coming out of them are taken when the step is finished, rather than being triggered by a external event, ... </li></ul><ul><li>... and they support dynamic concurrency. </li></ul>Kinds of Steps in Activity Diagrams Action <ul><li>Action (State) </li></ul>Subactivity <ul><li>Subactivity (State) </li></ul>
  64. 64. Action (State) <ul><li>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. </li></ul><ul><li>However, an action can invoke an operation that has another activity graph as a method (possible polymorphism). </li></ul>Action
  65. 65. Subactivity (State) <ul><li>A subactivity (state) starts another activity graph without using an operation. </li></ul><ul><li>Used for functional decomposition, non-polymorphic applications, like many workflow systems. </li></ul><ul><li>The invoked activity graph can be used by many subactivity states. </li></ul>Subactivity
  66. 66. Example POEmployee.sortMail Deliver Mail POEmployee sortMail() Check Out Truck Put Mail In Boxes Deliver Mail
  67. 67. Activity Graph as Method <ul><li>Application is completely OO when all action states invoke operations </li></ul><ul><li>All activity graphs are methods for operations. </li></ul>POEmployee sortMail() POEmployee.sortMail POEmployee.deliverMail deliverMail() «realize» Check Out Truck Put Mail In Boxes PO Employee Deliver Mail Method
  68. 68. Dynamic concurrency <ul><li>Applies to actions and subactivities. </li></ul><ul><li>Not inherited from state machines. </li></ul><ul><li>Invokes an action or subactivity any number of times in parallel, as determined by an expression evaluated at runtime. Expression also determines arguments. </li></ul><ul><li>Upper right-hand corner shows a multiplicity restricting the number of parallel invocations. </li></ul><ul><li>Outgoing transition triggered when all invocations are done. </li></ul><ul><li>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. </li></ul>Action/Subactivity *
  69. 69. Object Flow (State) <ul><li>A special sort of step (state) that represents the availability of a particular kind of object, perhaps in a particular state. </li></ul><ul><li>No action or subactivity is invoked and control passes immediately to the next step (state). </li></ul><ul><li>Places constraints on input and output parameters of steps before and after it. </li></ul>Class [State]
  70. 70. Object Flow (State) <ul><li>Take Order must have an output parameter giving an order, or one of its subtypes. </li></ul><ul><li>Fill Order must have an input parameter taking an order, or one of its supertypes. </li></ul><ul><li>Dashed lines used with object flow have the same semantics as any other state transition. </li></ul>Order [Taken] Take Order Fill Order
  71. 71. Coordinating Steps <ul><li>Inherited from state machines </li></ul><ul><li>Initial state </li></ul><ul><li>Final state </li></ul><ul><li>Fork and join </li></ul>
  72. 72. <ul><li>Decision point and merge ( ) are inherited from state machines. </li></ul><ul><li>For modeling conventional flow chart decisions. </li></ul>Coordinating Steps Calculate Cost Charge Account Get Authorization [cost < $50] [cost >= $50]
  73. 73. <ul><li>Synch state ( ) is inherited from state machines but used mostly in activity graphs. </li></ul><ul><li>Provides communication capability between parallel processes. </li></ul>Coordinating Steps State machine notation Inspect Install Foundation Build Frame Install Electricity in Foundation Put On Roof Install Electricity In Frame Install Electricity Outside Install Walls * *
  74. 74. Convenience Features (Synch State) <ul><li>Forks and joins do not require composite states. </li></ul><ul><li>Synch states may be omitted for the common case (unlimited bound and one incoming and outgoing transition). </li></ul>Activity diagram notation Build Frame Install Foundation Install Electricity in Foundation Put On Roof Install Electricity In Frame Install Electricity Outside Install Walls Inspect
  75. 75. Convenience Features (Synch State) <ul><li>Object flow states can be synch states </li></ul>
  76. 76. Convenience Features <ul><li>Fork transitions can have guards. </li></ul><ul><li>Instead of doing this: </li></ul>Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] [else]
  77. 77. Convenience Features <ul><li>Partitions are a grouping mechanism. </li></ul><ul><li>Swimlanes are the notation for partitions. </li></ul><ul><li>They do not provide domain-specific semantics. </li></ul><ul><li>Tools can generate swimlane presentation from domain-specific information without partitions. </li></ul>Register Bug Evaluate Impact Fix Bug Revise Plan Release Fix Test Fix [ priority = 1] Management Support Engineering
  78. 78. Convenience Features <ul><li>Signal send icon </li></ul>Signal <ul><li>… translates to a transition with a send action. </li></ul><ul><li>Signal receipt icon </li></ul><ul><li>… translates to a wait state (a state with no action and a signal trigger event). </li></ul>Coffee Pot Wake Up Get Cups Turn on Coffee Pot Coffee Done Drink Coffee Signal
  79. 79. Case Study Adapted from Kobryn, “UML 2001” Communications of the ACM October 1999 partition Submission Team Task Force Revision Task Force Issue RFP Evaluate initial submissions Submit specification draft Collaborate with competitive submitters Develop technology specification action state RFP [issued] [optional] control flow Finalize specification Specification [initial proposal] input value Begin object flow initial state join of control conditional fork fork of control Specification [final proposal]
  80. 80. Case Study Adapted from Kobryn, “UML 2001” Communications of the ACM October 1999 Evaluate initial submissions Evaluate final submissions Vote to recommend Enhance specification Implement specification Revise specification Finalize specification Specification [final proposal] Specification [adopted] Recommend revision Specification [revised] [NO] [YES] [else] [Enhanced] decision final state guard Collaborate with competitive submitters
  81. 81. When to Use Activity Diagrams <ul><li>Use activity diagrams when the behavior you are modeling ... </li></ul><ul><ul><li>does not depend much on external events. </li></ul></ul><ul><ul><li>mostly has steps that run to completion, rather than being interrupted by events. </li></ul></ul><ul><ul><li>requires object/data flow between steps. </li></ul></ul><ul><ul><li>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). </li></ul></ul>
  82. 82. Activity Diagram Modeling Tips <ul><li>Control flow and object flow are not separate. Both are modeled with state transitions. </li></ul><ul><li>Dashed object flow lines are also control flow. </li></ul><ul><li>You can mix state machine and control/object flow constructs on the same diagram (though you probably do not want to). </li></ul>
  83. 83. Activity Diagram Modeling Tips From UML User Guide: Request Return Get Return Number Ship Item Item [returned] Receive Item Restock Item Credit Account Item [available] Customer Telesales Warehouse Accounting
  84. 84. Activity Modeling Tips Request Return Get Return Number Ship Item Item [returned] Receive Item Restock Item Credit Account Item [available] Customer Telesales Warehouse Accounting
  85. 85. Activity Diagram Modeling Tips <ul><li>Activity diagrams inherit from state machines the requirement for well-structured nesting of composite states. </li></ul><ul><li>This means you should either model as if composite states were there by matching all forks/decisions with a correspond join/merges … </li></ul><ul><li>… or check that the diagram can be translated to one that is well-nested. </li></ul><ul><li>This insures that diagram is executable under state machine semantics. </li></ul>
  86. 86. Activity Diagram Modeling Tips Well-nested:
  87. 87. Activity Diagram Modeling Tips Not well-nested: Apply structured coding principles. (Be careful with goto’s!)
  88. 88. Activity Diagram Modeling Tips Can be translated to well-nested diagram on earlier slide:
  89. 89. Wrap Up: Activity Diagrams <ul><li>Use Activity Diagrams for applications that are primarily control and data-driven, like business modeling … </li></ul><ul><li>… rather than event-driven applications like embedded systems. </li></ul><ul><li>Activity diagrams are a kind of state machine until UML 2.0 … </li></ul><ul><li>… so control and object/data flow do not have separate semantics. </li></ul><ul><li>UML 1.3 has new features for business modeling that increase power and convenience. Check it out and give feedback! </li></ul>