Systems Analysis II Interaction Diagrams

1
Systems Analysis IIInteraction Diagrams

• INFO 355
• Glenn Booker

2
Interaction Diagrams

• Interaction diagrams primarily consist of two
  types
• Sequence diagrams
• Collaboration (or communication) diagrams
• Either type describes ONE USE CASE
• Unlike the class diagram, which pertains to the
  whole system

3
Interaction Diagrams

• Interaction diagrams describe how one or more
  actors interact with the system to perform a use
  case
• The development of interaction diagrams motivates
  the development of methods (i.e. making them up),
  which later become part of the class diagram

4
Making up Methods???

• Yes, as part of object oriented design, you need
  to specify the methods which will be associated
  with each class
• Method names start with a verb
• Such as get, set, create, calculate, display,
  obtain, append, delete, etc.
• And end with the noun (often the type of data or
  object involved)

5
Getters and Setters

• Two of the most common methods are to read the
  value of a variable (get), or assign the value of
  a variable (set)
• getQuantity would read the value of some field
  Quantity
• setQuantity would assign or set the value of
  Quantity, ignoring its previous value (if any)

6
Returns from the System

• In response to messages, the system often
  provides some sort of data in return
• This can be explicitly shown by a dashed line
• The line is labeled with the type of data
  provided by the system, such as totalPrice or
  discountedValue
• Returns generally point to an interface object,
  so an actor can see the data

7
Returns from the System

• Return messages often fulfill a system response
  identified in the use case description (hint!!!)
• If the use case states system displays the total
  amount due, then some return message will
  probably need to contain totalAmountDue (or
  something like that)

8
Method versus Message

• We often use method and message
  interchangeably
• A method is code which belongs to some object
• A message is the command to execute a method

9
Identifying Objects

• Interaction diagrams can identify specific
  objects (not just classes)
• Name objects and classes using the
  format objectClass
• For example, employeePerson means there is an
  object employee of the Class Person

10
Identifying Objects

• Notice the Class name is capitalized, but the
  object name is all lower case, and the phrase is
  underlined
• If you dont need to specify the object name,
  just use the format Class
• Note the leading colon and underline

11
Identifying Actors

• Sequence diagrams do not show the primary actor
  explicitly
• Earlier UML (versions 1.x) showed the primary
  actor in the form of the stick figure we saw in
  the use case diagram
• Often, the first message in an interaction
  diagram is a direct result of some action by the
  primary actor

12
System Sequence Diagram

• The System Sequence Diagram, mentioned in my UML
  summary, will not be covered here to avoid
  confusion

13
Sequence Diagram
14
Sequence Diagram

• A sequence diagram shows the messages needed to
  perform a use case, in chronological order
• Time is assumed to advance as you move down the
  page (top to bottom)
• Steps in a sequence diagram often (not always)
  correspond to the steps in a scenario for that
  use case

15
Generic Sequence Diagram
No returns are shown Notice that messages may go
right-left as well as left-right
16
Notation for Sequence Diagram

• Each class or object is identified in a box, with
  a dashed line extending below it
• When an object is in use, a narrow rectangle can
  be added over the dashed line
• This rectangle is an activation bar it shows the
  lifespan of that object

17
Sequence Diagram Sequence

• The sequence of actors and objects from left to
  right on a sequence diagram is generally the
  order in which they are used
• Typically this results in the primary actor on
  the far left, then an interface object, etc.

18
Where to begin?

• To develop an interaction diagram, use the use
  case documentation to
• Identify the primary actor
• Use the MVC (or interface, control, and data
  objects) pattern to make up the objects which
  will be used to follow the main success scenario
• Label messages appropriately to read, move, and
  analyze data as needed

19
Where to begin?

• Consider also the ProductSpecification pattern
  mentioned last week
• A common result is for an artifact to start with
  a document, such as an invoice, which has
• Line entries for each thing on that invoice, and
• Draws information about each line from a
  ProductSpecification class

20
Where to begin?

• Where significant, add return messages to
  describe important information obtained as a
  result of the messages

21
Self-called Messages

• An object may call its own methods
• See also p. 54, Fig. 4.1
• The message line makes a U turn to the line from
  which it started, and is still labeled with the
  name of the method name

22
Object Creation and Deletion

• A special notation is used for the creation of an
  object during a use case
• The message points to the new object, and the
  message is labeled new or create
• When an object is no longer needed, it is deleted
  (slide 16)
• Message is labeled close or delete

23
Decisions, Decisions

• Conditional statements (If) are shown in brackets
  xlt10 or before a colon leading to the message

24
Loops!

• Loops (repeat activity until some condition is
  met) are shown on a sequence diagram by placing a
  box around the set of repeated messages
• The looping condition is in brackets
• for each line item
• See Fig 4.4, p. 58

25
Collaboration (or Communication) Diagram
UML v2 will call them communication diagrams,
but collaboration is still used in Visio and
the current UML standard
26
Collaboration Diagram

• A Collaboration Diagram looks like a class
  diagram, since it has boxes (with class or object
  names) connected by lines
• But here, the lines correspond to message paths,
  not associations
• It shows what messages are passed between objects

27
Collaboration Diagram

• To show the chronological order of messages, a
  collaboration diagram MUST NUMBER MESSAGES
• The first object dictates the start of each
  numbering series
• Its first message is number 1., the second
  2., etc.
• Messages which follow as a result of the first
  message get 0.1 added for each message, i.e. 1.1,
  1.2, 1.3, etc.

28
Collaboration Diagram

• Then the messages which follow message 2. do
  likewise, 2.1, 2.2, 2.3, etc.
• This establishes threads of messages
• Some people just number the messages sequentially
  (1, 2, 3, ), but this is not compliant with any
  UML standard

29
Collaboration Diagram

• The other critical thing is to determine where
  messages live (what object is responsible for
  implementing them)
• The object to which a message points (its target)
  is responsible for implementing that message
• This also applies for sequence diagrams

30
Generic Collaboration Diagram
This matches the sequence diagram on slide 15
31
Collaboration Diagram

• Notice that lines between classes have no
  arrowheads, but each message is labeled with an
  arrow
• The next slide shows the implied class
  characteristics from this case
• Notice that the ability to pass messages implies
  visibility between classes

32
Class Diagram for slide 15
Same case shown as slide 15