UML is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a
softwareintensive system.
UML is established by the Object Management Group
(OMG) as the standard notation for distributed object
systems.
UML is just a notation. It is not, nor does it specify:
Processes
Tools
Programming languages
Using UML aids in communication among analysts,
designers, and programmers.
3
A brief history of UML
In the early to mid-1990s, three modeling languages were popular
Each was developed by a leader in the world of OO:
James Rumbaugh – object-modeling technique (OMT)
Grady Booch – Booch method
Ivar Jacobson – Object-oriented software engineering
All three joined Rational in 1994 and 1995
Became known as “The Three Amigos”
Combined their methodologies to creating the non-proprietary Unified
Modeling Language (UML) in 1996
UML is officially defined by the Object Management Group (OMG)
UML 1 – Submitted in 1996
UML 2 – Submitted to OMG in 2003
4
Some important UML artifacts
Use case diagrams and descriptions capture the
requirements of the system.
Class diagrams capture the classes, attributes,
methods for classes and the relationships between
classes.
Object diagrams
are a variant of class diagrams that show
specific objects to give an example or snapshot of running
system.
Activity diagrams show flow of activities in a
process.
5
Some important UML artifacts
State machines show change of state and events
that cause change of state for specific objects.
Interaction diagrams show interactions between
objects.
There
are several types of interaction diagrams.
Sequence diagrams
show sequence of messages among
objects in an execution scenario.
UML also defines:
Component diagrams show physical structure of software components.
Deployment diagrams show the architecture of a system in terms of
physical nodes (hardware) and distribution of software components.
6
Use case diagram
How users interact with a system
7
Class diagram
Class diagrams show the classes involved in a
system and relationships between them.
8
Class and object diagrams
A class diagram is used to show classes, their attributes,
their methods and their relationship to other classes.
An object diagram is used to show specific instances
individual objects and the values of their attributes at one
point in time.
9
Activity diagram
Procedural and parallel behavior
10
State machine
How events change state of an object over its life
11
Sequence diagram
Interaction between objects; emphasis on sequence
12
Communications diagram
Interaction between objects; emphasis on links
13
Summary of UML symbols
14
Drawing UML diagrams
Products from Rational that create UML
Rational Software
Modeler
Rational Software
Architect
Rational RequisitePro
Rational Method
Composer
Rational Unified
Process
Open source tools are also available, including
plug-ins for Eclipse
http://www.eclipse.org
15
Using UML in the software development process
The main purpose of UML is to facilitate
communication among all people involved in the
development process
UML is a visual language that is made up of
diagrams
Often
textual documents accompany the UML, especially
in larger scale projects that require a more formal process
UML should be modified as design decisions are
refined
16
Using UML in the software development process
UML is used on all stages of software development
Requirements gathering
Use cases describe system functionality
Analysis
Class and interaction diagrams model the business domain
Design
of the business problem
of the code
Class and interaction diagrams help design the code
Implementation
State, activity, and sequence show how scenarios unfold
Testing
Should verify all scenarios describes by use cases
17
Topics
18
UML
From Problem to Code
The Object and Class Concepts
Identifying Classes
Identifying Responsibilities
Relationships Between Classes
Use Cases
CRC Cards
UML Class Diagrams
Sequence Diagrams
State Diagrams
Using javadoc for Design Documentation
Case Study: A Voice Mail System
From Problem to Code
Three Phases:
Analysis
Design
Implementation
19
Analysis Phase
Establish the functions, services, and constraints
of the software to be developed.
The developers
and the software users work together to
produce a requirements specification, which will be the
input to the design phase.
Functional Specification which is a part of
requirements specification, has the following
characteristics:
Completely defines
tasks to be solved
Free from internal contradictions
Readable both by domain experts and software developers
Reviewable by diverse interested parties
Testable against reality
20
Design Phase
Goals
Identify classes
Identify behavior
of classes
Identify relationships among
Artifacts
Textual description of
classes and key methods
Diagrams
of class relationships
Diagrams
of important usage scenarios
State diagrams
21
classes
for objects with rich state
Implementation Phase
Implementation is the realization of the software
design in a specific programming language. Each
unit (a single class) is implemented separately.
Unit testing is done to ensure that each unit
functions properly with respect to its specification
before the units are integrated.
The individual units are integrated and tested as a
whole to ensure that the entire software system
works properly conforming to its specification.
22
Case Study: Voice Mail System
Use text for voice, phone keys, hangup
1 2 ... 0 # on a single line means key
H on a single line means "hang up"
All other inputs mean voice
In GUI program, will use buttons for keys
23
Identifying Classes
Rule of thumb: Look for nouns in problem
description
Mailbox
Message
User
Passcode
Extension
Menu
Focus on concepts, not implementation
MessageQueue stores
24
Don't
messages
worry yet how the queue is implemented
Categories of Classes
Tangible Things
Agents
Events and Transactions
Users and Roles
Systems
System interfaces and devices
Foundational Classes
25
Identifying Responsibilities
Rule of thumb: Look for verbs in problem
description
An example: Behavior of MessageQueue:
Add
message to tail
Remove
Test
message from head
whether queue is empty
OO Principle: Every operation is the
responsibility of a single class
Example:
Add message to mailbox
Who is responsible: Message or Mailbox?
26
Class Relationships
The following relationships can exist among classes:
Dependency ("uses")
Association, including aggregation and
composition
Generalization, including inheritance and
implementation
Among them, inheritance ("is-a"), aggregation
("has"), and dependency ("use") are the most
basic relationships
27
Dependency Relationship
Class A depends on class B: method of A manipulates objects of B in
the parameters, local variables, or return types
Minimize dependency: reduce coupling
Example: Removes dependence on System and Message
Replace
public class Message{
void print() { System.out.println(text); }
with
public class Message{
String getText() { // can print anywhere }
28
An example and UML notation for dependency
Association
Association represents general binary relationships
between classes
Association can have roles
Implemented through instance fields
An example and UML notation for association
relationship
29
Aggregation
A special form of association
30
Represents the has-a or part-whole relationship.
Simply a structural relationship that distinguishes the whole, that is, the
aggregate class, from the parts, that is, the component class.
Implemented through instance fields
e.g. MessageQueue aggregates Messages
e.g. Mailbox aggregates MessageQueue
An example and UML notation for aggregation
Composition
31
A stronger form of aggregation
The aggregate class exclusively owns the component class.
The lifetime of the components is entirely included in the lifetime of
the aggregate.
Contained objects don't exist outside container
An example and UML notation for composition: message
queues permanently contained in mail box
Association Direction
Some associations are bidirectional
Can
navigate from either class to the other
e.g.
Course has set of students, student has set of courses
Some associations are directed
Navigation is
e.g.
it
32
unidirectional
Message doesn't know about message queue containing
Multiplicities
any number (0 or more): *
one or more: 1..*
zero or one: 0..1
exactly one: 1
Implementation:
1, 0..1 relationship:
public class Mailbox{
...
private MessageQueue queue;
}
1:n relationship:
public class MessageQueue{
...
private ArrayList<Message> elements;
}
33
Generalization - Inheritance relationship
Inheritance relationship is formed when a class (or an
interface) extends another class (or interface).
UML notation for generalization
34
Generalization - implementation relation
The implementation relation between a class and an
interface
Interface type describes a set of methods. No
implementation, no state
Class implements interface if it implements its methods
UML notation for implementation relation
35
Use Cases
Analysis technique
Each use case focuses on a specific scenario
Use case = sequence of actions
Action = interaction between actor and computer
system
Each action yields a result
Each result has a value to one of the actors
Use variations for exceptional situations
36
Sample Use Case
Leave a Message
1.
Caller dials main number of voice mail system
2.
System speaks prompt
Enter mailbox number followed by #
3.
User types extension number
4.
System speaks
You have reached mailbox xxxx. Please leave a
message now
5.
Caller speaks message
6.
Caller hangs up
7.
System places message in mailbox
37
Sample Use Case -- Variations
Variation #1
1.1. In step 3, user enters invalid extension number
1.2. Voice mail system speaks
You have typed an invalid mailbox number.
1.3. Continue with step 2.
Variation #2
2.1. After step 4, caller hangs up instead of speaking message
2.3. Voice mail system discards empty message
38
CRC Cards
CRC = Classes, Responsibilities, Collaborators
a
very effective design tool in identifying classes, their
responsibilities, and relationships to other classes
Developed by Beck and Cunningham
Use an index card for each class
Class name on top of card
Responsibilities on left
Collaborators on right
39
CRC Cards
40
CRC Cards
Responsibilities should be high level without
concerning implementation details
Between 1 - 3 responsibilities per card is ideal
Collaborators are for the class, not for each
responsibility
41
How do you create CRC models
A CRC model is created iteratively performing the
following steps:
Find classes
One card per class
Walk through scenario of use cases, to find
responsibilities, define collaborators to fill in cards
42
Walkthroughs
Use case: "Leave a message"
Caller connects
Caller dials
to voice mail system
extension number
"Someone" must locate mailbox
Neither Mailbox nor Message can do this
New class: MailSystem
Responsibility: manage mailboxes
43
Walkthroughs
44
Other UML Diagrams
Many UML diagram types
We'll use three types:
Class
Diagrams
Sequence
Diagrams
State Diagrams
45
Sequence Diagrams
Each diagram shows dynamics of scenario
Object diagram: class name underlined
46
Sequence Diagrams
Self call
47
Object Construction
State Diagram
48
Use for classes whose objects have interesting states
Design Documentation
Recommendation: Use Javadoc comments
Leave methods blank
/**
Adds a message to the end of the new
messages.
@param aMessage a message
*/
public void addMessage(Message aMessage)
{
}
Don't compile file, just run Javadoc
Makes a good starting point for code later
49
Case Study: Voice Mail System
Use text for voice, phone keys, hangup
1 2 ... 0 # on a single line means key
H on a single line means "hang up"
All other inputs mean voice
In GUI program, will use buttons for keys
50
Use Case: Reach an Extension
1.
User dials main number of system
2.
System speaks prompt
Enter mailbox number followed by #
3.
User types extension number
4.
System speaks
You have reached mailbox xxxx. Please
leave a message now
51
Use Case: Leave a Message
1.
Caller carries out Reach an Extension
2.
Caller speaks message
3.
Caller hangs up
4.
System places message in mailbox
52
Use Case: Log in
1.
Mailbox owner carries out Reach an Extension
2.
Mailbox owner types password and #
Default password = mailbox number. To change,
see Change the Passcode
3.
System plays mailbox menu:
Enter 1 to retrieve your messages.
Enter 2 to change your passcode.
Enter 3 to change your greeting.
53
Use Case: Retrieve Messages
1.
Mailbox owner carries out Log in
2.
Mailbox owner selects "retrieve messages" menu option
3.
System plays message menu:
Press
Press
Press
Press
1
2
3
4
to
to
to
to
listen to the current message
delete the current message
save the current message
return to the mailbox menu
4.
Mailbox owner selects "listen to current message"
5.
System plays current new message, or, if no more new messages,
current old message.
Note: Message is played, not removed from queue
6.
System plays message menu
7.
User selects "delete current message". Message is removed.
8.
Continue with step 3.
54
Use Case: Retrieve Messages
Variation #1
1.1. Start at Step 6
1.2. User selects "save current message".
Message is removed from new queue and appended to
old queue
1.3. Continue with step 3.
55
Use Case: Change the Greeting
1.
Mailbox owner carries out Log in
2.
Mailbox owner selects "change greeting" menu option
3.
Mailbox owner speaks new greeting
4.
Mailbox owner presses #
5.
System sets new greeting
Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.
1.3. System keeps old greeting.
56
Use Case: Change the Passcode
1.
Mailbox owner carries out Log in
2.
Mailbox owner selects "change passcode" menu option
3.
Mailbox owner dials new passcode
4.
Mailbox owner presses #
5.
System sets new passcode
Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.
1.3. System keeps old passcode.
57
CRC Cards for Voice Mail System
Some obvious classes
Mailbox
Message
MailSystem
58
Initial CRC Cards
59
Telephone
Who interacts with user?
Telephone takes button presses, voice input
Telephone speaks output to user
60
Connection
With whom does Telephone communicate
With MailSystem?
What if there are multiple telephones?
Each connection can be in different state (dialing,
recording, retrieving messages,...)
Should mail system keep track of all connection states?
Better to give this responsibility to a new class
61
Analyze Use Case: Leave a message
1.
User dials extension. Telephone sends number to Connection
Add collaborator Connection to Telephone
2.
Connection asks MailSystem to find matching Mailbox
3.
Connection asks Mailbox for greeting
Add responsibility "manage greeting" to Mailbox, add collaborator
Mailbox to Connection
4.
Connection asks Telephone to play greeting
5.
User speaks message. Telephone asks Connection to record it.
Add responsibility "record voice input" to Connection)
6.
User hangs up. Telephone notifies Connection.
7.
Connection constructs Message
8.
62
Add card for Message class, add collaborator Message to Connection
Connection adds Message to Mailbox
Result of Use Case Analysis
63
Result of Use Case Analysis
64
Analyse Use Case: Retrieve messages
1.
User types in passcode. Telephone notifies Connection
2.
Connection asks Mailbox to check passcode.
Add responsibility "manage passcode" to Mailbox
3.
Connection sets current mailbox and asks Telephone to speak menu
4.
User selects "retrieve messages". Telephone passes key to Connection
5.
Connection asks Telephone to speak menu
6.
User selects "listen to current message". Telephone passes key to Connection
7.
Connection gets first message from current mailbox.
Add "retrieve messages" to responsibility of Mailbox.
Connection asks Telephone to speak message
8.
Connection asks Telephone to speak menu
9.
User selects "save current message". Telephone passes key to Connection
10.
Connection tells Mailbox to save message
11.
65
Modify responsibility of Mailbox to "retrieve, save, delete messages"
Connection asks Telephone to speak menu
Result of Use Case Analysis
66
CRC Summary
One card per class
Responsibilities at high level
Use scenario walkthroughs to fill in cards
Usually, the first design isn't perfect.
(You just saw the author's third design of the mail
system)
67
UML Class Diagram for Mail System
CRC collaborators yield dependencies
Mailbox depends on MessageQueue
Message doesn't depends on Mailbox
Connection depends on Telephone,
MailSystem, Message, Mailbox
Telephone depends on Connection
68
Dependency Relationships
69
Aggregation Relationships
A mail system has mailboxes
A mailbox has two message queues
A message queue has some number of messages
A connection has a current mailbox.
A connection has references to a mailsystem and a
telephone
70
UML Class Diagram for Voice Mail System
71
Sequence Diagram for Use Case: Leave a message
72
Interpreting a Sequence Diagram
Each key press results in separate call to dial, but only one
is shown
Connection wants to get greeting to play
Each mailbox knows its greeting
Connection must find mailbox object:
Call findMailbox on MailSystem object
Parameters are not displayed (e.g. mailbox number)
Return values are not displayed (e.g. found mailbox)
Note that connection holds on to that mailbox over
multiple call