Transcript Systems Analysis II OO Design use case realizations INFO 355 Glenn Booker INFO 355 Week #5

Systems Analysis II
OO Design use case realizations
INFO 355
Glenn Booker
INFO 355
Week #5
1
Use case realization


Use case realization is based on
developing detailed design for your
system to implement one complex
use case of interest
This is done via interaction
diagrams

INFO 355
Here we focus on a sequence or
communication diagram to develop
interaction between actor and system
Week #5
2
Use case realization


As use cases are defined in detail,
the classes and methods defined
feed back into the design class
diagram
Recall we had three major types of
classes – interface, control, and
data

INFO 355
A controller class is often used to
manage performing one use case
Week #5
3
Class names

Class names should use a suffix
to identify their type clearly



INFO 355
Interface classes might end with Form,
Screen, Window, or Menu
Controller classes end with Controller
or Handler
Data classes end with Data
Week #5
4
Interaction Diagrams

Interaction diagrams include



Either type describes ONE
USE CASE

INFO 355
Sequence diagrams
Collaboration (in UMLv1)(or
communication, UMLv2) diagrams
Unlike the class diagram, which
pertains to the whole system
Week #4
5
Interaction Diagrams


INFO 355
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 design class diagram
Week #4
6
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


INFO 355
Such as: get, set, create, calculate,
display, obtain, append, delete, etc.
And end with the noun (often the
type of data or object involved)
Week #4
7
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)


INFO 355
getQuantity would read the value of
some field Quantity
setQuantity would assign or set the
value of Quantity, ignoring its previous
value (if any)
Week #4
8
Returns from the System

In response to messages, the
system often provides some sort
of data in return



INFO 355
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
Week #4
9
Returns from the System

Return messages often fulfill a
system response identified in the
use case description (hint!!!)

INFO 355
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)
Week #4
10
Method versus Message

We often use ‘method’ and
‘message’ interchangeably


INFO 355
A method is code which belongs to
some object
A message is the command to execute
a method
Week #4
11
Identifying Objects


Interaction diagrams can identify
specific objects (not just classes)
Name objects and classes using
the format
object:Class

INFO 355
For example, employee:Person means
there is an object “employee” of the
Class “Person”
Week #4
12
Identifying Objects


Notice the Class name is capitalized,
but the object name is all lower
case, and the phrase is underlined
If you don’t need to specify the
object name, just use the format
:Class

INFO 355
Note the leading colon and underline
Week #4
13
Identifying Actors

Sequence diagrams do not have to
show the primary actor explicitly


INFO 355
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
Week #4
14
System Sequence Diagram

INFO 355
The System Sequence Diagram,
mentioned in my UML summary and
in the text, will not be covered here
to avoid confusion
Week #4
15
SEQUENCE DIAGRAM
INFO 355
Week #5
16
Sequence Diagram



INFO 355
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
Week #4
17
Generic Sequence Diagram
:ClassA
:ClassB
:ClassC
:ClassD
msg1()
msg2()
msg3()
msg4()
msg5()
msg6()
Clearly these are not meaningful class or method names.
No returns are shown. Notice that messages may go
right-left as well as left-right
INFO 355
Week #4
18
Notation for Sequence Diagram

Object2

Activation bar
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

X
INFO 355
This rectangle is an activation
bar; it shows the lifespan of
that object
Week #4
19
Sequence Diagram … Sequence


INFO 355
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.
Week #4
20
Where to begin?

To develop an interaction diagram,
use the use case documentation to



INFO 355
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
Week #4
21
Where to begin?


Consider also the
ProductSpecification pattern
A common result is for an artifact
to start with a document, such as
an invoice, which has


INFO 355
Line entries for each thing on that
invoice, and
Draws information about each line
from a ProductSpecification class
Week #4
22
Where to begin?

INFO 355
Where significant, add return
messages only to describe
important information obtained
as a result of the messages
Week #4
23
Self-called Messages


An object may call its own methods
The message line makes a U turn to
the line from which it started, and is
still labeled with the method name
Object1
Message2
INFO 355
Week #4
24
Object Creation and Deletion

A special notation is used for the
creation of an object during a use
case


When an object is no longer
needed, it is deleted (slide 19)

INFO 355
The message points to the new object,
and the message is labeled ‘new’ or
‘create’
Message is labeled ‘close’ or ‘delete’
Week #4
25
Decisions, Decisions

Conditional statements (If) are
shown in brackets [x<10] or before
a colon leading to the message
:A
:B
:C
Message1()
x<10: calculate()
x>15: findNext()
INFO 355
Week #4
26
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


INFO 355
[for each line item]
[input data is not valid]
Week #4
27
Note: UML v2 calls them
‘communication’ diagrams, but
‘collaboration’ is still used in Visio
and the current UML standard
COLLABORATION (OR
COMMUNICATION) DIAGRAM
INFO 355
Week #5
28
Collaboration Diagram



INFO 355
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
Week #4
29
Collaboration Diagram

To show the chronological order of
messages, a collaboration diagram
MUST NUMBER MESSAGES



INFO 355
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.
Week #4
30
Collaboration Diagram



INFO 355
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
Week #4
31
Collaboration Diagram

The other critical thing is to
determine where messages ‘live’
(what object is responsible for
implementing them):


INFO 355
The object to which a message
points (its target) is responsible
for implementing that message
This also applies for sequence diagrams
Week #4
32
Generic Collaboration Diagram
1. msg1
1.1 msg2
:ClassA
3
1.
m
sg
4
1.4 m
1.2 m sg5
sg 3
:ClassB
1.5 msg6
:ClassD
:ClassC
This matches the sequence diagram on slide 18
INFO 355
Week #4
33
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

INFO 355
Notice that the ability to pass
messages implies association
between classes
Week #4
34
Class Diagram for slide 18
ClassC
ClassA
+msg3()
+msg4()
+msg1()
ClassB
ClassD
+msg2()
+msg5()
+msg6()
Same case shown in slide 18
Attributes, labels and multiplicity not shown
INFO 355
Week #4
35
PACKAGE DIAGRAM
INFO 355
Week #5
36
Packages



INFO 355
Classes are the most basic logical
element in an OO system
We need a way to group related
classes into larger structures
A Package can contain classes,
other packages, or a combination
of the two
Week #6
37
Packages


Packages can therefore have a large
scope (e.g. entire subsystems)
In writing, a double colon separates
a package name from its contents

Package::otherpackage::classname
Package
otherpackage
classname
INFO 355
Week #6
38
Package Diagram

The Package Diagram can be very
helpful in understanding the
architecture of a system


INFO 355
What are the big pieces of this system?
Defining connections among
packages also helps encourage
higher modularity for each package
Week #6
39
Packages

In a diagram, a package may be
just a tabbed folder
Staff

Or a package can list its contents
(classes and/or packages)
Staff
Employee
Manager
Person
SSN
(this was done
manually in Visio)
INFO 355
Week #6
40
Packages

The smallest packages can be
drawn large enough to include
the class diagram they contain
Staff
Person
SSN
Employee
Manager
(also done
manually)
INFO 355
Week #6
41
Packages

If showing a class diagram within a
package, can show connection to
other packages by using the fully
qualified name of the class in
another package

See also the <<system>> stereotype
Shipping::Shipment
INFO 355
Week #6
Person
42
Package Diagram


Packages can contain both packages
and classes
Dashed lines show direction of
dependency Shipping
Container
Dock
Shipment
INFO 355
Week #6
43
Package Dependencies

For additional refinement,
dependencies can be labeled with
various stereotypes, such as






INFO 355
Call
Instance
Copy
Derived
Send
Import
Week #6
44
Package Generalization

Generalization can be shown with
packages, not just classes

INFO 355
Might be used in implementation to
distinguish among different kinds of
similar interfaces, for example
Week #6
45
Packages

It is possible to have classes
with identical names in
different packages



INFO 355
Customer::Person
Client::Person
You might want this to reuse
non-primitive data type classes
Week #6
46
Package Stereotypes

Packages can specify stereotypes
to indicate their purpose


<<façade>> to indicate the façade
pattern is being implemented with
this package
<<system>> to indicate the package
represents an external system
«facade»
HR Interface
INFO 355
Week #6
«system»
HR System
47
Package Stereotypes


<<stub>> could represent a package
which isn’t going to be implemented
yet, but is a placeholder
<<framework>> represents a
commercial development framework
«stub»
Third Iteration
Features
INFO 355
Week #6
«framework»
Visual Studio
48
Package Visibility

Packages can have the same
visibility characteristics as any
class, method, or attribute




INFO 355
Public
Private
Protected
This doesn’t show on its symbol
Week #6
49