UML--definition

1
UML--definition
UML stands for "unified modeling
language unifies methods of Booch, Rumbaugh
(OMT or Object Modeling Technique), and Jacobson
(OOSE or Object-Oriented Software
Engineering) mainly a modeling language, not a
complete development method Early versions --
second half of the 90's Not all methods we will
use are officially part of the UML description
2
UML--references
Most of the examples below, plus more on UML,
issues can be found in 1. Booch, Rumbaugh, and
Jacobson, The Unified Modeling Language User
Guide 2. Fowler and Scott, UML Distilled 3.
Horstmann, Practical Object-Oriented Development
in C and Java 4. Pressman, Software
Engineering, A Practitioner's Approach
3
Tools for analysis, specification, and design

• We can use the following tools
• Analysis and specification
• Use cases
• Dataflow diagrams
• Analysis, specification, and design
• Entity-relationship (ER) diagrams
• Class-Responsibility-Collaborator (CRC) cards
• Object message diagrams
• State diagrams
• Sequence diagrams

4
Requirements analysis and specification
Requirements Analysis and Specification Requirem
ents / Specification ----What is
needed? ----If there is a current
implementation, what are the problems with
it? ----How can we translate customer needs and
wants into a usable
specification for the design stage? Initially,
requirements may be fuzzy and poorly
stated--analysis stage sharpens and focuses the
(customer) requirements Some tools for
requirements analysis specification ----use
cases ----data flow diagrams ----user
stories (XP)
5
Use cases
USE CASES a part of the Unified Modeling
Language" (UML) which we will also use for
design each identifies a way the system will be
used and the "actors" (people or devices) that
will use it (an interaction between the user and
the system) each use case should capture some
user-visible function and achieve some discrete
goal for the user an actual user can have many
actor roles in these use cases an instance of a
use case is usually called a "scenario"
6
Example use case
Example (based on Booch, Rumbaugh, and Jacobson,
The Unified Modeling Language User Guide)
Should also be supplemented with written
requirements
7
Data flow diagrams (1)
Data flow diagram (DFD) ----graphical
technique to show information flow and transforms
applied as data move from input to
output ----each function or information
transformer is represented by a circle or
"bubble" ----data labels are placed on arrows
showing information flow ----external entities
(data "producers" or "consumers") are shown as
square boxes
8
Data flow diagrams (2)
The data flow diagram does not describe the
processing sequence it is not a flowchart. But
it can be very useful during requirements
analysis for a system being developed. A DFD
can be used to provide a functional model for the
system being developed, thus supplementing the
class relationship, object message, and state
diagram models of UML. Functional models
based on DFD's were part of the Object Modeling
Technique (OMT) developed by Rumbaugh, one of the
three main designers of UML.
9
Data flow diagrams--example
Example (based on examples in Pressman, Software
Engineering, A Practitioner's Approach)
10
Requirements document
Requirements document must be as clear as
possible, consistent, complete Important parts
of a requirements document (Berezin, 1999) 1.
Application Overview -- objectives --
(business processhow application fits) --
user roles and responsibilities -- interactions
with other systems -- (replacement of legacy
systems) -- (production rollout
considerations) -- terminology
11
Requirements document--continued
Important parts of a requirements document
(continued) 2. Functional requirements --
functionality precise, detailed, for each user
class address security, auditing, reporting,
ability of users to modify application --
(scope (for a multiphase project) ) --
performance -- usability -- concurrency
12
Specification
Specification must be as complete as
possible, consistent, clear
13
Principles of specification
Principles of specification 1. functionality
should be separate from implementation 2. model
of system behavior must include both data and
functional responses to external stimuli 3.
interaction with other components must be
specified 4. environment of operation must be
defined 5. "cognitive model" should describe
the system as seen by the user community do not
create a design or implementation model 6. must
be tolerant of incompleteness and allow for
additions 7. must allow for change
14
Software requirements specification
Result of specification step Software
Requirements Specification must
include --complete information
description --detailed functional
description --representation of system
behavior --performance requirements --design
constraints --appropriate validation criteria
(for example, acceptance tests) --.
15
Specification format
example candidate formats for specification IEE
E 830-1984 Department of Defense at the end
of this process, customer and developer must
conduct a Specification Review
16
ER diagrams

• Entity-relationship diagrams / class diagrams
• These diagrams represent the relationships
  between the classes in the system.
• There are three basic types of relationship
• inheritance ("is-a")
• aggregation ("has-a)
• association ("uses")
• These are commonly diagrammed as follows

17
ER diagram is-a
is-a draw an arrow from the derived to the base
class
18
ER diagram--has-a
has-a draw a line with a diamond on the end at
the "container" class. Cardinalities may also be
shown (11, 1n, 10m 1, i.e., any number gt
0, 11, i.e., any number gt 1)
19
ER diagram--uses
uses or association there are many ways to
represent this relationship, e.g.,
employs
works for
20
CRC cards
CRC cards class--responsibilities--collaborators
cards "responsibilities" operators,
methods "collaborators" related classes (for
a particular operator or method)
Make one actual card for each discovered class,
with responsibilities and collaborators on the
front, data fields on the back. CRC cards are
not really part of UML, but are often used in
conjunction with it.
21
CRC card--example
Example (based on Horstmann, Practical
Object-Oriented Development in C and Java)
front back
Class Mailbox
Queue of new messages Queue of kept
messages Greeting Extension number Passcode
22
Common classes

• Common types of classes which the developer can
  look for include
• tangible things, e.g., Mailbox, Document
• system interfaces and devices, e.g.,
  DisplayWindow, Input Reader
• agents, e.g., Paginator, which computes document
  page breaks, or InputReader
• events and transactions, e.g., MouseEvent,Customer
  Arrival
• users and roles, e.g., Administrator, User
• systems, e.g., mailsystem (overall),
  InitializationSystem (initializes)
• containers, e.g., Mailbox, Invoice, Event
• foundation classes, e.g., String, Date, Vector,
  etc.

23
Examplebank simulation (Horstmann)
Horstmann, Mastering Object-Oriented Design in
C, Wiley, 1995
Teller 1
Teller 2
Customer 1
Customer 3
Customer 2
Teller 3
Teller 4
24
Examplebank simulation (Horstmann), cont.
An initial solution (Horstmann, p. 388)
Bank Statistics
Customer
Bank
Application
Arrival
Departure
EventQueue
Event
25
Examplebank simulation (Horstmann), cont.
An improved solution (Horstmann, p. 391)
Bank Statistics
Customer
Bank
Simulation
Arrival
Departure
EventQueue
Event
26
UML Constructs to Be Covered

• UML language contains many methods which will not
  be covered here.
• (And some of the methods we are covering are not
  officially part of UML, although they are often
  used with UML, e.g., CRC cards).
• What we have covered so far
• use cases, data flow diagrams--for requirements
  analysis, design specification
• ER diagrams, CRC cards--for initial design
• To be covered
• collaboration or object-message diagrams, state
  diagrams, sequence diagrams--for more detailed
  design and dynamic aspects

27
Additional UML Tools We Will Use

• Additional UML tools we will use
• Collaboration or Object message diagrams
• State diagrams
• Sequence diagrams
• These allow us to further refine the design, in
  preparation for coding.

28
Object Message Diagrams
Collaboration or Object message diagrams Each
responsibility on a CRC card will be
implemented as one or more functions, with
information being shared by the collaborators as
needed. The collaboration or object message
diagram makes each information-sharing event
explicit, by showing the flow of function calls
or messages related to that event, and gives a
more precise way to check on the design being
constructed. (Not ALL functions need to be
diagrammed this way, if the information-sharing
mechanism is simple and obvious.)
29
Information Sharing Options
Information Sharing options In a collaboration
or object message diagram we use a rectangle to
represent each participating object (labeled by
object name or by class name object name) and we
denote each function call by a labeled line or
arrow from the calling object to the object
responsible for carrying out the function. These
calls can be sequentially numbered. These
connecting lines can also be labeled to show the
status of the objects carrying out the functions
in question. Labels used are S--the object
itself F--data field of the object
itself P--procedure parameter G--global
variable L--local variable
30
Information Sharing--Example--Part 1 of 3
Example A contrived but instructive example in
Practical Object-Oriented Development in C and
Java by Cay Horstmann (Wiley 1997) considers the
case where an object of class Car must carry out
the operation add_gas by accessing an object from
class GasStation. This can give examples of the
cases above, as follows
31
Information Sharing--Example--Part 2 of 3
buy_gas
void Caradd_gas(GasStation
station)

station.buy_gas()

//add_gas has procedure
parameter of type //GasStation
buy_gas
void Caradd_gas( )

the_gas_station.buy_gas()

//there
is ONE global gas station buy_gas
void Caradd_gas( )

_my_gas_station -gt
buy_gas()

//car has ptr to its "own" station, a field
in //the car object
32
Information Sharing Example--Part 3 of 3
buy_gas
void Caradd_gas( )

GasStation station new GasStation( )

station -gt buy_gas()
delete
station //"build and
destroy a station (local variable)
2. buy_gas void
Caradd_gas( )
GasStation
station find_gas_station()

station -gt buy_gas()
//Car class has a
find_gas_station
1.find_gas_station //operation which it must
ask itself to //carry out the return
value, of type //GasStation, is a local
variable
Car
GasStation station
L
S
33
Information Sharing--Another Example--Part 1 of 2
Here is another example, also taken from
Horstmann, which is more realistic. This diagram
shows the messages necessary to execute the
"process_dialing" operation in a mail system.
Note that "receive_message" can be carried out in
two ways, depending on whether the message is for
the administrator or for a general reader. The
steps to be carried out are 1. Read input 2a.
If input is 9999, have administrator mailbox
receive message. 2b1. If input is another
extension, find the mailbox for that
extension. 2b2. Have that mailbox receive a
message.
34
Information Sharing--Another Example--Part 2 of 2
InputReader
process_dialing 1. read_input
MailSystem
G
S
2a. receive message
2b1. locate mailbox
AdminMailbox
F
2b2. receive message
L
Mailbox
Steps 1. read_input 2. receive message (case a
or case b)
35
State Diagram
State Diagram another way of adding detail to
the design--models dynamic behavior describes
all the possible states a particular object can
be in and how that object's state changes as a
result of events that affect that object usually
drawn for a single class to show behavior of a
single object used to clarify dynamic behavior
within the system, as needed
36
State Diagram--Properties
A state diagram contains a "start" point, states,
and transitions from one state to another. Each
state is labeled by its name and by the
activities which occur when in that state.
Transitions can have three optional labels
Event Guard / Action. A transition is
triggered by an Event. If there is no Event,
then the transition is triggered as soon as the
state activities are completed. A Guard can be
true or false. If the Guard is false, the
transition is not taken. An Action is completed
during the transition.
37
State Diagram--Example
Example this state diagram example for an
"order" in an order-processing system is from
Fowler and Scott, UML Distilled (Addison-Wesley,
1997)
start
/get first item
not all items checked /get next item
all items checked all items available
Dispatching
Checking
initiate delivery
check item
all items checked some items not in stock
delivered
item received all items in stock
Delivered
Waiting
item received some items not in stock
38
Sequence Diagram
Sequence Diagram a sequence diagram also
models dynamic behavior typically a sequence
diagram shows how objects act together to
implement a single use case messages passed
between the objects are also shown sequence
diagrams help to show the overall flow of control
in the part of the program being modeled they
can also be used to show concurrent
processes asynchronous behavior
39
Sequence Diagram--Syntax
Objects in the sequence diagram are shown as
boxes at the top below each object is a dashed
vertical line--the objects lifeline an arrow
between two lifelines represents each
message arrows are labeled with message names
and can also include information on arguments and
control information two types of
control condition, e.g., is greaterthan
zero iteration, e.g., for all array
items return arrows can also be included
40
Sequence Diagram--Example
Example from Fowler and Scott, UML Distilled
(note dashed horizontal line denotes
return)
an Order Entry window
an Order
an Order Line
a Stock Item
prepare()
for all order lines
prepare()
hasStockcheck()
hasStock
remove()
needsReorder needsToReorder()
needsReorder new
a Reorder Item
a Delivery Item
hasStock new