1. THE OBJECT-ORIENTED DESIGN WORKFLOW UML2 Sequence Diagrams

2. Behavioral Models l Behavior models describe the internal dynamic aspects of an information system that supports the business processes in an organization. l Behavioral models describe what the internal logic of the processes is without specifying how the processes are to be implemented. l One of the primary purposes of behavioral models is to show how the underlying objects of the problem domain will collaborate to support each of the use cases.

3. The Sequence Diagram l Illustrates the objects that participate in a use case and the messages that pass between them over time for one use case. l Is a dynamic model that shows the explicit sequence of messages that are passes between objects in a defined interaction. l Since sequence diagrams emphasize the time- based ordering of the activity that takes place among a set of objects, they are very helpful for understanding real-time specifications and complex use cases.

4. The Sequence Diagram

8. Guidelines for Building Sequence Diagrams l Determine the context of the sequence diagram. –The context of a diagram can be a system, a use case, a scenario of a use case, or an operation of a class. –The context of the diagram is depicted as a labeled frame around the diagram. –Most commonly, it is one use case scenario. l Identify the objects that participate in the sequence being modeled – that is, the objects that interact with each other during the use case scenario. –The objects are identified during the development of the structural model (class diagram). –These are the classes on which the objects of the sequence diagram for this scenario will be based. Set the lifeline for each object. To do this, you need to draw a vertical dotted line below each class to represent the class’s existence during the sequence. An “X” should be placed below the object at the point on the lifeline where the object goes out of existence.

9. Guidelines for Building Sequence Diagrams l Add messages to the diagram. –The arrows should be placed in order from the first message (at the top) to the last (at the bottom) to show time sequence. –Any parameters passed along with the messages should be placed in parentheses next to the message’s name. –If a message is expected to be returned as a response to a message, then the return message either can be or not be shown on the diagram. l Place the execution occurrence of each object’s lifeline by drawing a narrow rectangle box over the top of the lifelines to represent when the classes are sending and receiving messages.

10. Guidelines for Building Sequence Diagrams l Finally, validate the sequence diagram. –The purpose of this step is to guarantee that the sequence diagram completely represents the underlying processes. –This is done by guaranteeing that the diagram depicts all the steps in the process. –You should refer back to the scenario’s use case details and your static class diagram. –NOTE: All methods on the class diagram should be shown as messages on the sequence diagram.

11. More Guidelines – Sequence Diagrams l Strive for Left-To-Right ordering of messages l Name actors consistently with your use case diagrams l Name classes consistently with your class diagrams l An actor can have the same name as a class l Place human and organizational actors on the left- most side of your diagram l Place reactive system actors on the right-most side of your diagram

12. Guidelines for Messages l Justify message names beside the arrowhead l Create objects directly l Use prose for messages involving human and organization actors l Prefer names over types for parameters l Indicate types as parameter placeholders l Apply the > stereotype for use case invocations

13. Guidelines for Return Values l Do NOT model a return value when it is obvious what is being returned l Model a return value only when you need to refer to it elsewhere l Justify return values beside the arrowhead l Indicate types as return value placeholders l Explicitly indicate the actual value for simple values

14. Loops

15. Nested Activity (Includes)

16. Branching or Alternatives

17. Sequence Diagram Resources l IBM: –http://www- 128.ibm.com/developerworks/rational/library/3101.htmlhttp://www- 128.ibm.com/developerworks/rational/library/3101.html l Agile Modeling: –http://www.agilemodeling.com/artifacts/sequenceDiagram. htmhttp://www.agilemodeling.com/artifacts/sequenceDiagram. htm –http://www.agilemodeling.com/style/sequenceDiagram.ht mhttp://www.agilemodeling.com/style/sequenceDiagram.ht m