1. The Unified Modeling Language (UML)
A Standard Graphical Modeling Notation
Eddie Roache

2. Outline Why Use UML History UML Characteristics Diagram Types
Use Case Diagrams
Class Diagrams
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

3. Why Use UML? Help analyze complex domains Help design complex systems
Visualize analysis and design artifacts
Clearly document development artifacts
Is simple, yet expressive
Can be applied to different processes
Copyright © Eddie Roache. All rights reserved.
v1.2

4. Some UML Examples
Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003
Copyright © Eddie Roache. All rights reserved.
v1.2

5. Some UML Examples
Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003
Copyright © Eddie Roache. All rights reserved.
v1.2

6. Some UML Examples
Source: OMG, Unified Modeling Language Specification, version 1.5. March 2003
Copyright © Eddie Roache. All rights reserved.
v1.2

7. History OO takes a foothold New OO modeling notations spring up
Three amigos get together
Grady Booch
Ivar Jacobson
James Rumbaugh
UML 0.8 is born
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

8. UML Characteristics Unified Modeling Language
Standard graphical modeling notation
Supported by formal semantics
Current version: 2.0
Wide use and acceptance in the IT industry
Large tool support
Rational Rose, Together, Visio, Jude, …
… although no tool fully supports the standard
Is not a process
Process independent
Copyright © Eddie Roache. All rights reserved.
v1.2

9. Diagram Types Structure diagrams Behavior diagrams Class diagram
Object diagram
Component diagram
Deployment diagram
Package diagram
Composite Structure diagram
Behavior diagrams
Use Case diagram
Interaction diagrams
Sequence diagram
Interaction Overview diagram
Communications diagram
Timing diagram
State Machine diagram
Activity diagram
Copyright © Eddie Roache. All rights reserved.
v1.2

10. Diagram Types
Source: OMG, Unified Modeling Language: Superstructure Specification, version 2.0. August 2005
Copyright © Eddie Roache. All rights reserved.
v1.2

11. Use Case Diagrams Model user interaction with system
Capture functional requirements
Also used for
business modeling
component specification
UML Spec does not include Use Case Specs
Copyright © Eddie Roache. All rights reserved.
v1.2

12. Use Case Definition
“A use case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor.”
“The Unified Software Development Process”, Ivar Jacobsen*, Grady Booch, Jim Rumbaugh
What is a use case? Here’s the definition provided in the 3 amigo's book:
Use cases describe the services the system under development must provide
Services are the functional requirements for the system
Use cases are effective because they are based on the interaction of the system with it’s external actors
The system is treated as a black box - there is no visibility into how the system provides the services.
Use cases are a key unit of requirements
Presume “essential” requirements - presume infinite processing resources.
*Author of “Object-Oriented Software Engineering: A Use Case Driven Approach”
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

13. Use Case Specification
Name: Create AddressEntry
Description: This use case allows the actor to create a new entry for an Address Book.
Preconditions:
1. An Address Book is open.
Steps:
1. The actor requests to create a new AddressEntry.
2. The system creates a new AddressEntry and returns it to the actor.
Post Conditions:
1. An Address Book Entry is created.
Use Case specifications provide a detailed description of the steps in the use case.
Includes:
Pre-Conditions
Post Conditions
Description
Not shown, but part of a formal use case specification are:
Performance Requirements
Business Rules
Alternative courses - what happens if …(need an example…maybe introduce concept later).
Notice, Precondition calls for AddressBook being open, but we don’t have an “open” use case. Maybe it’s part of View. Let’s tentatively rename View as Open, and show the interrelationship between the new “Open” use case and Create AddressBookEntry.
See “Writing Effective Use Cases” and “
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

14. <<Actor>>
Use Case Diagrams
<<Actor>>
Actor
Use Case
Association
Dependency
extend
include
Generalization
Note (Comment)
Close AddressBook
<<extend>>
<<include>>
This is a note.
Copyright © Eddie Roache. All rights reserved.
v1.2

15. Address Book Example
The Address Book System provides distributed access to a set of address books.
An Address Book is made up of Address Book Entries
An Address Book Entry contains a name, street address, phone number, address
The Address Book System shall:
allow users to create, view, delete, and save address books
allow users to create, modify, and delete entries in an address book
The goal is to learn about use case modeling, and how this technique can be used to capture requirements for a system. Later, we will see how use cases can be used to derive the design and implementation for a system, and how tractability between requirements and design and implementation can be maintained.
Describe the sample system…Address Book System is similar to the address book that systems have.
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

16. Use Case Diagram AddressBook System Create AddressBook
View AddressBook
AddressBook User
Delete AddressBook
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

17. Use Case Diagram View AddressBook Save AddressBook Delete Address
<<extend>>
View AddressBook
Save AddressBook
<<extend>>
<<extend>>
Address Book User
Delete Address
Update Address
<<extend>>
<<extend>>
Add New Address
<<include>>
Add AddressEntry
Close AddressBook
<<include>>
Create AddressEntry
Create PersonAddressEntry
Create OrgAddressEntry
Copyright © Eddie Roache. All rights reserved.
v1.2

18. Use Case Diagram View AddressBook Save AddressBook Delete AddressEntry
Address Book User
Delete AddressEntry
Update Address
Add New Address
<<include>>
Add AddressEntry
Close AddressBook
<<include>>
Create AddressEntry
All dependencies are extend unless stereotyped otherwise
Create PersonAddressEntry
Create OrgAddressEntry
Copyright © Eddie Roache. All rights reserved.
v1.2

19. Class Diagrams
Model system classes, interfaces, and class relationships
Capture structural (vs. behavioral) info
Used for
business domain modeling
logical design
implementation design
Copyright © Eddie Roache. All rights reserved.
v1.2

20. Class Diagrams Class Abstract Class Class with Attributes and
Operations
AddressBook
AddressBook
AddressBook
-id
+name
+phone
+getName()
+getPhone()
Copyright © Eddie Roache. All rights reserved.
v1.2

21. Class Diagrams Dependency Association Navigability Aggregation
Composition
Generalization
Copyright © Eddie Roache. All rights reserved.
v1.2

22. Class Diagrams Multiplicity Constraint Role Name Directionality
1..2 *
Multiplicity
Constraint
Role
Name
Directionality
Nesting *
{ordered}
+entry
has
displays
Copyright © Eddie Roache. All rights reserved.
v1.2

23. Class Diagrams Stereotype Realization Derived Assoc. Association Class
<<Entity>>
Stereotype
Realization
Derived Assoc.
Association Class
Note (Comment)
<<Interface>>
/entry
This is a note.
Copyright © Eddie Roache. All rights reserved.
v1.2

24. Class Model Element
Source: OMG Unified Modeling Language Specification, version 1.5. March 2003
Copyright © Eddie Roache. All rights reserved.
v1.2

25. Class Model Element
Source: OMG Unified Modeling Language Specification, version 1.5. March 2003
Copyright © Eddie Roache. All rights reserved.
v1.2

26. Address Book Domain AddressBook AddressEntry Party Person Organization* 1 1
AddressEntry
Party
In writing out the specification, the entities begin to emerge. Develop a type model that describes the vocabulary of the domain the system operates in...
Person
Organization
Copyright © Eddie Roache. All rights reserved.
v1.2
Copyright © 2003 Eddie Roache. All rights reserved.

27. AddressBookController
Logical Design
AddressBookView
AddressBookController
AddressBook
Copyright © Eddie Roache. All rights reserved.
v1.2

28. Implementation Design1 1
AddressBookController
AddressBookView
-addrBookFrame: JFrame
-addrList: JList
-entryNames: String[]
+getEntryNames(): String[]
+createNewEntry(): AddressBookEntry
~removeEntry()
+findEntry(name: String): AddressBookEntry
+show()
+update()
#createAddrBookFrame(): JFrame 1 * * 1
AddressBookEntry
AddressBook
#name: String
#streetAddress: String
#city: String
#State: String
#Zip: String
#phoneNumber: String
# Address: String
-name: String
+load()
+getEntryNames(): String[]
+addEntry()
+removeEntry()
+findEntry(name: String): AddressBookEntry
+toString(): String
Copyright © Eddie Roache. All rights reserved.
v1.2

29. More UML Characteristics
Supported by formal semantics (meta-model)
Meta-Object Facility Specification
UML Model Interchange using XML Metadata Interchange (XMI)
Object Constraint Language (OCL)
Action Semantics UML Extensions
Standard profiles
Copyright © Eddie Roache. All rights reserved.
v1.2

30. Tools Paper and Pencil Any drawing program (preferably vector-based)
Rational Rose (and XDE)
Together
Jude
Poseidon
ArgoUML
StarUML
Many others . . .
Copyright © Eddie Roache. All rights reserved.
v1.2

31. References www.omg.org www.uml.org www.rational.com
The Unified Modeling Language User Guide
The Unified Modeling Language Reference Manual
Copyright © Eddie Roache. All rights reserved.
v1.2

32. Questions
???

33. Class Diagram Fruit Seed Apple Orange Pear Granny Smith Red Delicious*
Apple
Orange
Pear
Granny Smith
Red Delicious
Rome
Copyright © Eddie Roache. All rights reserved.
v1.2

34. Class Diagram Copyright © 2003-2006 Eddie Roache. All rights reserved.
Source: OMG, Unified Modeling Language: Superstructure Specification, version 2.0. August 2005
Copyright © Eddie Roache. All rights reserved.
v1.2