1. IMAT5205 Systems Analysis and Design
Modelling Interaction and Collaboration

2. 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.

3. 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>>

4. 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

5. 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

6. 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™)

7. 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

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

9. 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;

10. 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.

11. 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.

12. 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

13. 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

14. Sequence Diagram: Example 2

15. Sequence Diagram: Example 3

16. Sequence Diagram: Example 4

17. 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

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

19. 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

20. 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

21. 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

22. 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.

23. 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