Chapter 2, Modeling with UML, Part 2

Transcription

1 Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 2, Modeling with UML, Part 2

2 Outline of this Class What is UML? A more detailed view on ü Use case diagrams ü Class diagrams ü Sequence diagrams ü Activity/Statecharts diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

3 UML Basic Notation: First Summary UML provides a wide variety of notations for modeling many aspects of software systems UML diagrams cover the three fundamental models for software design: Functional model: Use case diagrams Object model: Class diagrams Dynamic model: Sequence diagrams, statechart diagram Now we go into a little bit more detail Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

4 UML First Pass Use case diagrams Describe the functional behavior of the system as seen by the user Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams Describe the dynamic behavior between objects of the system Statechart diagrams Describe the dynamic behavior of an individual object Activity diagrams Describe the dynamic behavior of a system, in particular the workflow. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

5 UML Use Case Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5

6 UML first pass: Use case diagrams Classifier Use Case Actor. System boundary Use case diagrams represent the functionality of the system Bernd Bruegge & Allen H. Dutoit from Object-Oriented user s Software point Engineering: of Using view UML, Patterns, and Java 6

7 UML Use Case Diagrams Passenger Used during requirements elicitation and analysis to represent external behavior ( visible from the outside of the system ) An Actor represents a role, that is, a type of user of the system A use case represents a class of functionality provided by the system PurchaseTicket Use case model: The set of all use cases that completely describe the functionality of the system. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7

8 Actors Passenger Name An actor is a model for an external entity which interacts (communicates) with the system: User External system (Another system) Physical environment (e.g. Weather) An actor has a unique name and an optional description Examples: Passenger: A person in the train Optional Description GPS satellite: An external system that provides the system with GPS coordinates. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8

9 Use Case PurchaseTicket A use case represents a class of functionality provided by the system Use cases can be described textually, with a focus on the event flow between actor and system The textual use case description consists of 6 parts: 1. Unique name 2. Participating actors 3. Entry conditions 4. Exit conditions 5. Flow of events 6. Special requirements. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

10 Textual Use Case Description Example Passenger PurchaseTicket 1. Name: Purchase ticket 2. Participating actor: Passenger 3. Entry condition: (GOOD) Passenger selects an option from the display (WRONG) Passenger stands in front of ticket distributor (Very WRONG) Passenger has sufficient money to purchase ticket 4. Exit condition: Passenger has ticket (Better): System delivered ticket 5. Flow of events: 1. Passenger selects the number of zones to be traveled 2. Distributor displays the amount due 3. Passenger inserts money, at least the amount due 4. Ticket Distributor returns change 5. Ticket Distributor issues ticket 6. Special requirements: None. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10

11 Use Cases can be related Extends Relationship To represent seldom invoked use cases or exceptional functionality Includes Relationship To represent functional behavior common to more than one use case. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

12 The <<extends>> Relationship <<extends>> relationships model exceptional or seldom invoked cases <<extends>> Passenger PurchaseTicket <<extends>> The exceptional event flows are factored out of the main event flow for clarity The direction of an <<extends>> relationship is to the extended use case Use cases representing exceptional flows can extend more than one use case. <<extends>> OutOfOrder <<extends>> TimeOut Cancel NoChange Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

13 The <<includes>> Relationship Passenger PurchaseSingleTicket <<includes>> PurchaseMultiCard <<includes>> <<includes>> relationship represents common functionality needed in more than one use case <<includes>> behavior is factored out for reuse, not because it is an exception The direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship). <<extends>> CollectMoney <<extends>> <<extends>> NoChange Cancel TimeOut Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

14 Use Case Models can be packaged Classifier Use Case Actor. System boundary Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

15 Historical Remark: UML 1 used packages Package Course Instructor GiveLecture HoldExercise Student Teaching Assistent DoHomework Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

16 UML Class Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

17 UML first pass: Class diagrams Association Class Multiplicity 2 PushButton SimpleWatch Display Battery Time Class diagrams represent the structure of the system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

18 UML first pass: Class diagrams Class diagrams represent the structure of the system Association Class Multiplicity 2 PushButton state push() release() Attribute 1 1 LCDDisplay blinkidx blinkseconds() blinkminutes() blinkhours() stopblinking() referesh() Watch Battery Load 1 Time Now Operations Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

19 Class Diagrams Class diagrams represent the structure of the system Used during requirements analysis to model application domain concepts during system design to model subsystems during object design to specify the detailed behavior and attributes of classes. TarifSchedule Table zone2price Enumeration getzones() Price getprice(zone) * * Trip zone:zone Price: Price Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

20 Classes Type TarifSchedule zone2price getzones() getprice() Name Attributes Operations TarifSchedule Table zone2price Enumeration getzones() Price getprice(zone) Signature TarifSchedule A class represents a concept A class encapsulates state (attributes) and behavior (operations) Each attribute has a type Each operation has a signature The class name is the only mandatory information Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

21 Actor vs Class vs Object Actor An entity outside the system to be modeled, interacting with the system ( Passenger ) Class An abstraction modeling an entity in the application or solution domain The class is part of the system model ( User, Ticket distributor, Server ) Object A specific instance of a class ( Joe, the passenger who is purchasing a ticket from the ticket distributor ). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

22 Instances tarif2006:tarifschedule zone2price = { { 1, 0.20}, { 2, 0.40}, { 3, 0.60}} :TarifSchedule zone2price = { { 1, 0.20}, { 2, 0.40}, { 3, 0.60}} An instance represents a phenomenon The attributes are represented with their values The name of an instance is underlined The name can contain only the class name of the instance (anonymous instance) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22

23 Associations TarifSchedule Enumeration getzones() Price getprice(zone) * * TripLeg Price Zone Associations denote relationships between classes The multiplicity of an association end denotes how many objects the instance of a class can legitimately reference. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23

24 1-to-1 and 1-to-many Associations Country 1 1 City name:string name:string 1-to-1 association Polygon draw() * Point x: Integer y: Integer 1-to-many association Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24

25 Many-to-many Associations StockExchange * Lists * Company tickersymbol A stock exchange lists many companies. Each company is identified by a ticker symbol Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

26 From Problem Statement To Object Model Problem Statement: A stock exchange lists many companies. Each company is uniquely identified by a ticker symbol Class Diagram: StockExchange * Lists * Company tickersymbol Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

27 From Problem Statement to Code Problem Statement : A stock exchange lists many companies. Each company is identified by a ticker symbol Class Diagram: StockExchange * Lists * Company tickersymbol Java Code public class StockExchange { private Vector m_company = new Vector(); }; public class Company { private int m_tickersymbol; private Vector m_stockexchange = new Vector(); }; Associations are mapped to Attributes! Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

28 Qualifiers Without qualification Directory 1 * File filename With qualification Directory filename File Qualifiers can be used to reduce the multiplicity of an association Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

29 Qualification: Another Example Company StockExchange * Lists * tickersymbol StockExchange * tickersymbol Lists 1 * Company Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

30 Aggregation An aggregation is a special case of association denoting a consists-of hierarchy The aggregate is the parent class, the components are the children classes Exhaust system Muffler diameter Tailpipe diameter A solid diamond denotes composition: A strong form of aggregation where the life time of the component instances is controlled by the aggregate. That is, the parts don t exist on their won ( the whole controls/destroys the parts ) TicketMachine 3 ZoneButton Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

31 Inheritance Button CancelButton ZoneButton Inheritance is another special case of an association denoting a kind-of hierarchy Inheritance simplifies the analysis model by introducing a taxonomy The children classes inherit the attributes and operations of the parent class. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

32 Association class Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32

33 Ternary associations Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33

34 Packages Packages help you to organize UML models to increase their readability We can use the UML package mechanism to organize classes into subsystems Account Bank Customer Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34

35 Object Modeling in Practice Foo Amount CustomerId Deposit() Withdraw() GetBalance() Class Identification: Name of Class, Attributes and Methods Is Foo the right name? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35

36 Object Modeling in Practice: Brainstorming Dada Amount CustomerId Deposit() Withdraw() GetBalance() Foo Amount CustomerId Deposit() Withdraw() GetBalance() Account Amount CustomerId Is Foo the right name? Deposit() Withdraw() GetBalance() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36

37 Object Modeling in Practice: More classes Account Bank Name Amount CustomerId AccountId Deposit() Withdraw() GetBalance() Customer Name CustomerId 1) Find New Classes 2) Review Names, Attributes and Methods Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37

38 Object Modeling in Practice: Associations Account Bank Name? has * Amount CustomerId AccountId AccountId Deposit() Withdraw() GetBalance() * owns 2 Customer Name CustomerId 1) Find New Classes 2) Review Names, Attributes and Methods 3) Find Associations between Classes 4) Label the generic assocations 5) Determine the multiplicity of the assocations 6) Review associations Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38

39 Practice Object Modeling: Find Taxonomies Bank Name * Account Amount CustomerId AccountId AccountId * Has Customer Name Deposit() Withdraw() GetBalance() CustomerId() Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39

40 Practice Object Modeling: Simplify, Organize Account Amount CustomerId AccountId AccountId Deposit() Withdraw() GetBalance() Show Taxonomies separately Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40

41 Practice Object Modeling: Simplify, Organize Bank Name * Account Amount CustomerId AccountId AccountId * Has Customer Name Deposit() Withdraw() GetBalance() CustomerId() Use the 7+-2 heuristics or better 5+-2! Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41

42 UML Sequence Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42

43 UML first pass: Sequence diagram Actor Message Object Lifeline :WatchUser pressbutton1() pressbutton1() pressbutton2() Activation :Watch blinkhours() blinkminutes() :LCDDisplay incrementminutes() pressbutton1and2() commitnewtime() stopblinking() refresh() :Time Sequence diagrams represent the behavior of a system as messages ( interactions ) between different objects Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43

44 Sequence Diagrams Focus on Controlflow Passenger selectzone() insertcoins() pickupchange() pickupticket() TicketMachine Used during analysis To refine use case descriptions to find additional objects ( participating objects ) Used during system design TicketMachine to refine subsystem interfaces zone2price Instances are represented Messages -> by selectzone() rectangles. Actors Operations by sticky on insertcoins() figures participating Object pickupchange() Lifelines are represented by pickupticket() dashed lines Messages are represented by arrows Activations are represented by narrow rectangles. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44

45 Scenarios, use case and sequence diagrams A scenario is an instance of a use case describing a concrete set of actions (no alternative paths are in it) A use case is an abstraction that describes all possible scenarios involving the described functionality. Scenarios are used as examples for illustrating common cases; their focus is on understandability. Use cases are used to describe all possible cases; their focus is on completeness. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45

46 How to describe scenarios We describe a scenario using a template with three fields: The name of the scenario enables us to refer to it unambiguously. The name of a scenario is underlined to indicate that it is an instance. The participating actor instances field indicates which actor instances are involved in this scenario. Actor instances also have underlined names. The flow of events of a scenario describes the sequence of events step by step. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46

47 Scenario: an example Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47

48 Sequence Diagrams can also model the Flow of Data Passenger ZoneButton TarifSchedule Display selectzone() lookupprice(selection) price Dataflow displayprice(price) continued on next slide... The source of an arrow indicates the activation which sent the message Horizontal dashed arrows indicate data flow, for example return results from a message Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48

49 Sequence Diagrams: Iteration & Condition continued from previous slide... ChangeProcessor CoinIdentifier Display CoinDrop Passenger * insertchange(coin) lookupcoin(coin) Iteration price displayprice(owedamount) Condition [owedamount<0] returnchange(-owedamount) continued on next slide... Iteration is denoted by a * preceding the message name Condition is denoted by boolean expression in [ ] before the message name Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49

50 Creation and destruction continued from previous slide... Passenger ChangeProcessor Creation of Ticket createticket(selection) print() Ticket free() Destruction of Ticket Creation is denoted by a message arrow pointing to the object Destruction is denoted by an X mark at the end of the destruction activation In garbage collection environments, destruction can be used to denote the end of the useful life of an object. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50

51 Message Types Asynchronous Synchronous Call and Object creation Reply Lost Found Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51

52 Sequence Diagram Properties UML sequence diagram represent behavior in terms of interactions Useful to identify or find missing objects Time consuming to build, but worth the investment Complement the class diagrams (which represent structure). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52

53 Interaction Diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53

54 Interaction Diagrams UML 2.0: New concept of interaction fragments Before we go into detail with interaction fragments, let s cover the concept of an interaction. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54

55 Interaction Diagrams Four types of interaction diagrams: Sequence diagrams We will not study the following (by now at least): Communication diagrams Interaction overview diagrams Timing diagrams The basic building block of an interaction diagram is the interaction An interaction is a unit of behavior that focuses on the observable exchange of information between connectable elements Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55

56 Example of an Interaction: Sequence Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56

57 Interaction Fragment Interaction Fragment Is a piece of an interaction Acts like an interaction itself Combined Fragment Is a subtype of interaction fragment defines an expression of interaction fragments An expression of interaction fragments is defined by an interaction operator and interaction operands. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 57

58 Example of a Combined Fragment using the alt operator The interaction operator alt indicates a choice of behavior between interaction fragments Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 58

59 Alt Operator The interaction operator alt indicates a choice of behavior between interaction fragments At most one interaction fragment (that is, an InteractionOperand) is chosen The chosen interaction fragment must have an explicit or implicit guard expression that evaluates to true at this point in the interaction A guard can be a boolean expression (called InteractionConstraint) else (a reserved word) If the fragment has no guard expression, true is implied. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 59

60 Interaction Operators The following operators are allowed in the combination of interaction fragments: alt opt par loop critical neg assert strict seq Ignore consider Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 60

61 Opt and Break Operators option: The interaction operator opt designates a choice of behavior where either the (sole) operand happens or nothing happens. break: The interaction operator break represents a breaking scenario: The operand is a scenario that is performed instead of the remainder of the enclosing interaction fragment. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 61

62 Parallel and Critical Operator par The interaction operator par designates a parallel merge between the behaviors of the operands of a combined fragment. critical The interaction operator critical designates that the combined fragment represents a critical region. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 62

63 Example of a Critical Region Problem statement: The telephone Operator must make sure to forward a 911-call from a Caller to the Emergency system before doing anything else. Normal calls can be freely interleaved. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 63

64 UML Statechart Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 64

65 State diagrams and states State diagrams are used to give an abstract description of the behaviour of a system. This behaviour is analysed and represented as a series of events that can occur in one or more possible states. A state represents a step in the behaviour pattern of an object It is a configuration of the set of state-attributes of the behaving object Transition from one state to another is triggered by events An event may be either internal or external to the object Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 65

66 UML first pass: Statechart diagrams Event button1&2pressed Transition Blink Hours Initial state button2pressed button1pressed displayrefreshed Increment Hours Wrong state, It s an action!! State button1&2pressed Blink Minutes button2pressed displayrefreshed Increment Minutes button1pressed Stop Blinking Blink Seconds Final state button2pressed displayrefreshed Increment Seconds Represent behavior of a single object with interesting dynamic behavior. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 66

67 Transition notation: event [guard][/action] Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 67

68 Statechart for the Incident class Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 68

69 State machine diagram for 2Bwatch Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 69

70 Internal transitions in 2BWatch statechart Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 70

71 Review: UML Statechart Diagram Notation Event with parameters attr Action Name of State State1 do/activity entry /action exit/action Event Event(attr) [condition]/action Guard condition State2 Note: Events are italics Conditions are enclosed with brackets: [] Actions are prefixed with a slash / Actions and Activities in State Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 71

72 Example of Concurrency within an Object Nested states Splitting control Synchronization Emitting do/dispense Cash Cash taken Setting Up Ready Ready to reset do/eject Card Card taken Nested diagrams: a portion of behavior is specified by a statechart within an higher level state Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 72

73 State diagram Exit??? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 73

74 UML Activity Diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 74

75 UML Activity Diagrams An activity diagram consists of nodes and edges Nodes describe activities and objects Control nodes Executable nodes Most prominent: Action Object nodes E.g. a document Edge is a directed connection between nodes There are two types of edges Control flow edges Object flow edges Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 75

76 Activity diagrams In activity diagrams transitions from node to node happen automatically upon completion of activities Transitions do not depend upon the arrival of events as it happens in statecharts Activity diagrams represent the UML notation for the well known flowchart Each node in a flowchart represents an action to be executed. So it is not a state, but when applied to the program's state, it results in a transition to another state. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 76

77 State vs Activity diagram action1 E2[test=1]/action2 E2[test=0]/action4 action2 test=1 test=0 action4 s4 action3 Statechart Activity diagram (flowchart) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 77

78 Activity Diagrams: Grouping of Activities Activities may be grouped into swimlanes to denote the object or subsystem that implements the activities. Allocate Resources Dispatcher Open Incident Coordinate Resources Archive Incident Document Incident FieldOfficer Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 78

79 Activity diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 79

80 State Chart Diagrams vs Activity Diagrams An activity diagram that contains only activities can be seen as a special case of a state chart diagram Such an activity diagram is useful to describe the overall workflow of a system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 80

81 Statechart Diagram vs Activity Diagram Statechart Diagram for Incident Focus on the set of attributes of a single abstraction (object, system) Event causes state transition Active Inactive Closed Archived Incident- Incident- Incident- Handled Documented Archived Activity Diagram for Incident (Focus on actions performed and dataflow in a system) Completion of activity causes state transition Triggerless transition Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 81

82 Example: Structure of the Text Book Problem Statement Object Node Requirements elicitation ( Ch.4) An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state nonfunctional requirements functional model use case diagram Analysis (Ch.5) class diagram System design ( Ch.6 & 7 ) analysis object model dynamic model statechart diagram sequence diagram Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 82

83 Example: Structure of the Text Book (2) System design (Ch. 6 & 7) subsystem decomposition design goals Object design (Ch. 8 & 9) class diagram object design model source code Implementation (Ch. 10) Test (Ch. 11) deliverable system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 83

84 Summary: Activity Diagram Example Initial node [order rejected] Decision node Fork node Join node Merge node Receive Order Control flow edge Fill Order [order accepted] Ship Order Close Order Send Invoice Make Payment Accept Payment Final node Object node Invoice Object flow edge Action Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 84

85 Object flow (Details on new notation) Recent versions of UML adopt a solid line for object flow An alternative notation includes OutputPins/ InputPins (they represent the objects delivered as output or consumed as input by activities) OutputPin InputPin Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 85

86 Additional References OMG Unified Modeling Language (OMG UML) Version Martin Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley, 2003 Grady Booch,James Rumbaugh,Ivar Jacobson The Unified Modeling Language User Guide, Addison Wesley Open Source UML tools Astah Community: Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 86

87 UML Summary UML provides a wide variety of notations for representing many aspects of software development Powerful, but complex UML is a programming language Can be misused to generate unreadable models Can be misunderstood when using too many exotic features We concentrated on a few notations: Functional model: Use case diagram Object model: class diagram Dynamic model: sequence diagrams, statechart and activity diagrams. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 87