IMAT5205 Systems Analysis and Design Modelling Interaction and Collaboration

Lecture Objectives Recap of the differences between the Analysis & Design Models. Give an overview of Use Case Realizations – Design. Moving from Analysis to Design Introduce the role of Sequence Diagrams and provide an overview of their notation. Examine the relationship between Sequence Diagrams and other UML diagrams.

Comparing the Analysis and Design Models Analysis Model - Conceptual model An abstraction of the system that avoids implementation issues Design-generic Three conceptual stereotypes <<control>>, <<entity>>, <<boundary>> Design Model Physical model Blueprint of the implementation Specific to a particular implementation As many stereotypes as needed for the target language e.g., <<interface>> in Java, <<form>> in VB (Types of <<boundary>>

Use Case Realizations - Design A Use-Case Realization-Design is a collaboration (classes) that describes how a use case is realized and performed by design classes and their objects It provides a straightforward <<trace>> to a use-case realization-analysis – tracing back It is a physical realization of the Analysis Model Also deals with non-functional requirements Contains A set of design classes Showing detailed, physical structure N.B. In total you can expect FIVE times more classes in the Design Model compared to the Analysis Model A set of interaction diagrams Showing detailed, physical inter-communication between objects

Identifying Participating Classes Study the analysis classes in corresponding use- case realizations- analysis Identify design classes that trace to the analysis classes Study the special requirements of the use-case realization-analysis (Non-Functional) For persistence, concurrency, usability Identify any additionally required classes Find any other ‘missing’ design classes Perhaps needed as a ‘home’ for orphan responsibilities Draw the updated design Class Diagrams

Interaction Diagrams In design Sequence Diagrams are often preferred to Communication Diagrams Primary focus is on finding detailed, chronological sequences of actions Communication Diagrams, in contrast, focus on the existence of objects and links These diagrams are isomorphic i.e., the underlying information is the same Visual emphasis is different Often a menu press in CASE tools to generate one from the other (not in Enterprise Architect™)

Sequence Diagrams Sequence Diagrams illustrate object interaction Often start from converted Communication Diagrams in Use-Case Realization - Analysis Therefore start with an actor instance Each Design Class identified in the previous step should have at least one design object in the Sequence Diagram Messages are shown between object lifelines to realize the use case Temporary names for message may be used initially Until the operations being invoked on the receiving objects are determined

Sequence Diagram: Example 1 <<control>> <<entity>> <<boundary>>

Sequence Diagrams: Notation A message is shown with a horizontal solid line from the lifeline of one object to the lifeline of another object. The arrow is labelled with the name of the message (operation or signal), argument values and optionally a sequence number. The vertical axis indicates the passage of time The labels on arrows reflect the corresponding names on messages The full syntax is eventName(args)[condition]/action ^send clause If the event occurs and all the specified conditions are true, then do the specified action/send message;

Sequence Diagrams: Notation A procedure call is shown by a full arrowhead. Sending objects are blocked. A return (optional) is shown by a dashed arrow. Timings may be shown on the diagram for messages or operations. These can be used to specify constraints.

Sequence Diagrams: Notation Asynchronous messages are shown with open- arrowheads and imply no yielding of the thread of control (i.e. no-wait semantics, sender is not blocked). A message may be labelled with a guard condition e.g. [hasStock] If False the message will not be sent Branching may be shown by multiple messages leaving the same point.

Sequence Diagrams: UML This procedure call (operation) is creating an instance of class A createObj() objA:A objB:B doit() These return arrows are optional in a procedural flow of control

Sequence Diagrams An X at the bottom of the lifeline of an object indicates its destruction The creation of an object can be shown by positioning its icon on the timeline where it is created

Sequence Diagram: Example 2

Sequence Diagram: Example 3

Sequence Diagram: Example 4

Sequence Diagram: Example 5 Creates Object Note the use of a loop – this indicates repeated processing Here, there are many instructors to include in the report and each instructor can have more than one qualification The loop ensures we include all instructors and all their qualifications, in the report Destroys Object

Sequence Diagram Exercise Using the communication diagram below, convert it into a sequence diagram

Interactions Reveal Structure At design level we are modelling the fact that messages require objectIDs in order to be sent ‘A message needs an address’ This was ignored in the Analysis Model Consideration of where an ObjectID was found often leads to the discovery of ‘new’ classes e.g., Collection classes

Relationship to Other Diagrams 1 All objects on the Sequence Diagram must have a corresponding Class on the Class Diagram The space between incoming messages represent potential states on the class’ state machine diagram Since a ‘stable condition’ is implied Design state mahines can be partly derived from Sequence Diagrams

Relationship to Other Diagrams 2 All messages shown on sequence diagrams must be present in the destination classes on the class diagram ‘incoming’ messages are calls on public operations ‘recursive’ messages are calls on private operations However, not all implied ‘links’ will become associations Usually reserved in design for when an object of one class has an attribute for the objectID of another However navigability on associations can now be found Where the ObjectID is received through a message parameter this is often modelled as a dependency

Summary Recapped the differences between the Analysis & Design Models. Gave an overview of Use Case Realizations – Design. Introduced the role of Sequence Diagrams and provided an overview of their notation. Examine the relationship between Sequence Diagrams and other UML diagrams.

References Bennett, S., McRobb, S., & Farmer, R., (2010) “Object-Oriented Systems Analysis & Design using UML” 4th Ed McGrawHill Fowler, M., (2004) UML Distilled, 3rd Ed., Addison Wesley Page-Jones, M. (2000) “Fundamentals of Object- Oriented Design in UML” Addison Wesley