CHAPTER 2 Object-Oriented Modeling Using UML (Continued) Overview User Case Diagrams Activity Diagrams Class Diagrams Interaction Diagrams State Diagrams Package Diagrams

2.5.1. Overview Interaction diagrams describe exemplary how groups of objects collaborate in some behavior. An interaction diagram typically captures the behavior of a single use case. Interaction diagrams do not capture the complete behavior, only typical scenarios. There are two types of interaction diagrams: Sequence diagrams emphasize the order or concurrency of the interactions. Collaboration diagrams emphasize the interacting objects.

2.5.2. Interaction Diagrams and Use Cases Behavior of the “order” use case: A customer orders several products. The (sub-)orders (“order lines”) for each product are prepared separately. For each product check the stock. • If the product is in stock, remove requested amount from stock. • If the product stock falls below a predefined level, reorder it. Note: The class diagram is prepared in parallel or before the interaction diagram!

2.5.3. Sequence Diagrams

2.5.3. Sequence Diagrams

2.5.3. Sequence Diagrams

2.5.3. Sequence Diagrams

2.5.4. Concurrent Processes and Activations UML offers diagram elements to show concurrent processes explicitly within sequence and collaboration diagrams. Activation: indicates whenever a method is active, shows methods which are waiting for returns. Asynchronous message: allows the creation of new threads or objects, communicates with already running threads or objects. Deletion: occurs by self destruction of threads or objects, can be initiated by external messages.

2.5.4. Concurrent Processes and Activations Example: A bank transaction transfers $100 from bank account #123 to #456. • Withdraw $100 from bank account #123. • Deposit $100 at bank account #456. Withdraw and deposit may be executed in parallel (concurrently). The transaction is only successful if both sub-transactions (withdraw and deposit) are successful. Therefore a transaction coordinator checks the successful completion of the concurrent sub-transactions. • Each time a sub-transaction completes successfully it checks if all other sub-transactions have been completed successfully. If this is the case, it reports success to its client. • If any sub-transaction fails, it cancels the other sub-transactions and reports failure to its client.

2.5.4. Concurrent Processes and Activations

A Successful Bank Transaction

A Failing Bank Transaction

2.6. Collaboration Diagrams Dynamic behavior of objects can, in addition to sequence diagrams, also be represented by collaboration diagrams. The transformation from a sequence diagram into a collaboration diagram is a bidirectional function. The difference between sequence diagrams and collaboration diagrams is that collaboration diagrams emphasize more the structure than the sequence of interactions. Within sequence diagrams the order of interactions is established by vertical positioning whereas in collaboration diagrams the sequence is given by numbering the interactions.

2.6. Collaboration Diagrams

When to Use Interaction Diagrams When catching user requirements: • Describe the behavior of several objects within a single use case. • Show collaborations among objects. After having described the object behavior completely with state and activity diagrams: • Test the state and activity diagrams against the scenarios. Do not Use Interaction Diagrams For precise definition of a single class behavior (use state diagrams). If you want to describe the behavior across many use cases or many threads (consider an activity diagram).

2.7. State Diagram Subject/Topic/Focus: Summary: Intraclass behavior States and transitions Events, guards, actions and activities Abstraction, nesting and concurrency

2.7.1. Motivation Object-orientation = Structure + Behavior. Class diagrams capture structure (attributes and associations) and behavior interfaces (method signatures). How do we catch the dynamic behavior and life cycle of an object? Creation and deletion. Attribute and association changes. How does the object interact with other objects? Reacting to events and to messages received by the object. Triggering actions and sending messages to other objects. Handling of sequences of events accepted and actions triggered.

2.7.2. State Diagrams State diagrams are a technique to describe the behavior, i.e., state changes of a single class according to events and messages which the class sends and receives.

2.7.3. State A state for a certain period of time; abstracts from attribute values and associations of an object; represents the internal condition/state of an object for a certain period of time; corresponds to an interval of time between two events. The response to events may depend on the state of an object. Object creation comes together with an initial object state. Object deletion may be related with (one of many) final states.

2.7.4. Events An event is something worth noticing at a point of time; a signal from one object to another, e.g., “delivered”, a message received by an object, e.g., “check item”, a certain date/time, e.g., “after 10 seconds” (being in a certain state) or “at 31-dec-2000, 00:00”. Events may take arguments, e.g., “deliver to (receiver : Customer)”. Events may be declared in a class diagram with arguments shown as attributes.

2.7.4. Transitions A transition represents a change of the internal condition/state of an object. A transition is usually triggered (“fired”) by an event. Transitions without event label (“lambda transitions”) fire immediately. Transitions fire instantly from exactly one state to another state or to itself (self-transition) and are not interruptible.

2.7.5. Guards A guard is a logical condition (value “true” or “false”). A guarded transition fires only if the guard resolves to “true”. Since only one transition can be fired in a given state, guards are intended to be mutually exclusive for any event. Events may be guarded.

2.7.5. Actions An action is a short software process that executes immediately. A transition may trigger an action. Actions may be triggered on entry or exit of states (instead of labeling each incoming (entry) and outgoing (exit) transition with these actions). An event may trigger an action without leaving the state, i.e., without triggering exit and entry actions as a self-transition would do. An action may trigger events, usually in other objects. Actions may take arguments.

2.7.6. Sending Message Sending messages are special actions. Messages address an object or a set of objects. Messages occur after other actions. Messages trigger an event/transition in the receiving object.

2.7.7. Activities Activities can take “longer”, i.e., they are processes which last as long as an object is in a certain state. Activities are interruptible, i.e., an event causing a state transition may abort an activity. Activities may be constructed from a start and a final action.

2.7.8. Nested Sate Example: A state Cancelled is added to which transitions from all existing states exist.

2.7.8. Nested Sates Instead of drawing all the transitions from each state to the Cancelled state, it is easier to “wrap” the states Checking, Waiting and Dispatching in one superstate from which only one cancelled transition to the Cancelled state is necessary. Superstates contain state diagrams or other superstates. Superstates allow to simplify multiple transitions from probably many source states to a single target state by introducing a (superstate) name for a (nested) state diagram and substituting each of the transitions between source states and the target state by a single transition between superstate and target state.

2.7.8. Nested Sates

2.7.8. Nested Sates

2.7.9. Concurrency in State Diagrams Concurrent state diagrams are useful when a given object has sets of independent behaviors. The concurrent sections of a state diagram are places in which, at any time, the given object is in a composite state defined by the given subsections.

Concurrency: Alternative Notation

Biểu đồ trạng thái Đăng ký học tập

When to Use State Diagrams State diagrams are good at describing the behavior of an object across several use cases. Draw state diagrams especially for classes, which are not well understood and which need detailed description. If you have to describe several objects, which are involved in a single use case, use interaction diagrams. To show the general sequence for multiple use cases and multiple objects, use activity diagrams. State diagrams are not very good at describing behavior that involves a number of objects collaborating together.

2.8. Package Diagrams Subject/Topic/Focus: Summary: Packaging, Decomposition Summary: Dependency Package, Sub-Package Package Generalization

2.8.1. Motivation How do I control the complexity? A class diagram should fit on a sheet of paper (A4). A developer may grasp 7(+/-2) classes at a glance. How do I restrict scope (name space) and control change propagation? How do I build nested hierarchies of classes? How do I build layered architectures of classes? How do I show dependencies between classes at a higher abstraction level? How do I slice development work within a team? How do I specify interfaces between groups of classes, i.e., distinguish public from implementation-dependent classes? Typical systems grow complex, i.e., hundreds of classes. Typical systems grow complex, i.e., hundreds of classes.

2.8.2. Packaging One of the oldest question arising in software development is:

2.8.2. Packaging class A sends a message to class B; Package diagrams and package dependencies result from class diagrams. Class A depends on class B, if changes to the definition of class B may cause an effect on class A. Examples: class A sends a message to class B; class A has class B as part of its data; class A mentions class B as parameter to an operation. In an ideal oo-world, modifications which don’t change a class interface should not affect any other classes. The art of large scale design involves minimizing dependencies.

2.8.3. Dependencies If any dependency exists between any two classes in two packages this implies a dependency between the two packages.

2.8.3. Dependencies There is a vital difference between package dependencies and compilation dependencies:

2.8.3. Dependencies Example:

2.8.4. Nested Packages Instead of drawing many separate dependencies, the technique of sub-packages reduces redundant dependency information. Draw dependencies to and from the overall package, instead of many separate dependencies.

2.8.4. Nested Packages An overall package can contain: • classes • class diagrams • package diagrams Dependencies on an overall package represent dependencies on all members of the package. Separate dependencies on single members of the overall package can still occur

2.8.5. Dependencies: Visibility What does it mean to draw a dependency to a package that contains subpackages? Make clear, which convention you use in your project (by use of <<transparent>> or <<opaque>> stereotypes).

2.8.7. Package Generalization Generalization between packages means that the specific package must conform to the interface of the general package. To emphasize the role of a general interface, the package can be marked as {abstract}. Example: An abstract database interface consisting of several classes is implemented either for Oracle or for Sybase.

When to Use Package Diagrams Use package diagrams for distributing and balancing work between development groups. Package diagrams are helpful to explore the possibilities of partitioning tasks in the development process. Package diagrams are extremely useful for testing purposes: rather apply tests on packages (i.e., several interdependent classes) than on single routines.