Slide 16B.51 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering

Slide 16B.52 © The McGraw-Hill Companies, 2005 CHAPTER 16 — Unit B MORE ON UML

Slide 16B.53 © The McGraw-Hill Companies, 2005 Continued from Unit 16B

Slide 16B.54 © The McGraw-Hill Companies, Statecharts l Statechart with guards Figure 16.16

Slide 16B.55 © The McGraw-Hill Companies, 2005 Statecharts (contd) l An event also causes transitions between states l Example: The receipt of a message Figure 16.17

Slide 16B.56 © The McGraw-Hill Companies, 2005 Statecharts (contd) l The elevator is in state Elevator Moving  It performs operation »Move up one floor while guard [no message received yet] remains true, until it receives the message »Elevator has arrived at floor

Slide 16B.57 © The McGraw-Hill Companies, 2005 Statecharts (contd) l Receipt of this message [event] causes the guard to be false l It also enables a transition to state Stopped at Floor  In this state, activity »Open the elevator doors is performed

Slide 16B.58 © The McGraw-Hill Companies, 2005 Statecharts (contd) l The most general form of a transition label is »event [guard] / action  If »event has taken place and »[guard] is true, the transition occurs, and, while it is occurring, »action is performed

Slide 16B.59 © The McGraw-Hill Companies, 2005 Statecharts (contd) l Equivalent statement with the most general transition Figure 16.18

Slide 16B.60 © The McGraw-Hill Companies, 2005 Statecharts (contd) l The transition label is  Elevator has arrived at floor [a message has been received] / Open the elevator doors l The guard  [a message has been received] is true when the event  Elevator has arrived at floor has occurred and the message has been sent l The action to be taken is  Open the elevator doors

Slide 16B.61 © The McGraw-Hill Companies, 2005 Statecharts (contd) l There are two places where an action can be performed in a statechart  When a state is entered »Activity  As part of a transition »Action l Technical difference:  An activity can take several seconds  An action takes places essentially instantaneously

Slide 16B.62 © The McGraw-Hill Companies, 2005 Statecharts (contd) l An event can be specified in terms of words like “when” or “after” l Example:  when (cost > 1000) or after (2.5 seconds)

Slide 16B.63 © The McGraw-Hill Companies, 2005 Statecharts (contd) l Superstates combine related states Figure 16.19

Slide 16B.64 © The McGraw-Hill Companies, 2005 Statecharts (contd) l States A, B, C, and D all have transitions to Next State l Combine them into superstate ABCD Combined  Now there is only one transition  The number of arrows is reduced from four to only one l States A, B, C, and D all still exist in their own right

Slide 16B.65 © The McGraw-Hill Companies, 2005 l Example: Four states are unified into Osbert Combined Statecharts (contd) Figure 16.20

Slide 16B.66 © The McGraw-Hill Companies, Activity Diagrams l Activity diagrams show how various events are coordinated  Used when activities are carried on in parallel l Example:  One diner orders chicken, the other fish  The waiter writes down their order, and hands it to the chef  The meal is served only when both dishes have been prepared

Slide 16B.67 © The McGraw-Hill Companies, 2005 Activity Diagrams (contd) l Example: Figure 16.21

Slide 16B.68 © The McGraw-Hill Companies, 2005 Activity Diagrams (contd) l A fork has  One incoming transition, and  Many outgoing transitions, each of which starts an activity to be executed in parallel with the other activities l A join has  Many incoming transitions, each of which lead from an activity executed in parallel with the other activities, and  One outgoing transition that is started when all the parallel activities have been completed

Slide 16B.69 © The McGraw-Hill Companies, 2005 Activity Diagrams (contd) l Example:  A company that assembles computers as specified by the customer Figure 16.22

Slide 16B.70 © The McGraw-Hill Companies, 2005 Activity Diagrams (contd) l The three departments involved  Assembly Department  Order Department  Accounts Receivable Department are each in their own swimlane

Slide 16B.71 © The McGraw-Hill Companies, Packages l A large information system is decomposed into relatively independent packages  UML notation for a package Figure 16.23

Slide 16B.72 © The McGraw-Hill Companies, 2005 Packages (contd) l Example showing the contents of My Package Figure 16.24

Slide 16B.73 © The McGraw-Hill Companies, Component Diagrams l A component diagram shows dependencies among software components, including  Source code (represented by a note)  Compiled code  Executable load images

Slide 16B.74 © The McGraw-Hill Companies, 2005 Component Diagrams (contd) l Example: Figure 16.25

Slide 16B.75 © The McGraw-Hill Companies, Deployment Diagrams l A deployment diagram shows on which hardware component each software component is installed (or deployed) l It also shows the communication links between the hardware components

Slide 16B.76 © The McGraw-Hill Companies, 2005 Deployment Diagrams (contd) l Example: Figure 16.26

Slide 16B.77 © The McGraw-Hill Companies, Review of UML Diagrams l Some diagrams that could be confused include:  A use case models the interaction between actors and the information system  A use-case diagram is a single diagram that incorporates a number of use cases  A class diagram is a model of the classes showing the static relationships between them »Including association and generalization

Slide 16B.78 © The McGraw-Hill Companies, 2005 Review of UML Diagrams l A statechart shows  States (specific values of attributes of objects),  Events that cause transitions between states (subject to guards), and  Actions taken by objects l An interaction diagram (sequence diagram or collaboration diagram) shows how objects interact as messages are passed between them l An activity diagram shows how events that occur at the same time are coordinated

Slide 16B.79 © The McGraw-Hill Companies, UML and Iteration l Every UML diagram consists of a small required part plus any number of options  Not every feature of UML is applicable to every information system  To perform iteration and incrementation, features have to be added stepwise to diagrams l This is one of the many reasons why UML is so well suited to the Unified Process