Object-Oriented Architecture &
Design – Lecture 2 (of 3)
UML in Depth
David Woollard
University of Southern California
Computer Science Department
Software Architecture Group
California Institute of Technology
NASA Jet Propulsion Laboratory
Data Management Group
Story Arc
• Storyline in episodic form
• Goal for OOA&D:
Move from requirements to design, reified by a
model
• OOA&D will be split across 3 lectures
– Lecture 1: Problem Decomposition (9/15)
– Lecture 2: UML in Depth (9/29)
– Lecture 3: Advanced Topics – NFP, Incomplete
Specification, Relationship to Frameworks, etc. (10/1)
• OOA&D Workshop (10/11)
– Interactive session to review your designs
2
From Last Time
• OO is a useful design construct
• OO has a place in Architecture, but Architecture is a lot
larger than OO
• Design is an iterative process
– Requirements imply other missing requirements
– Requirements conflict with other requirements
– Requirements can be non-functional and imply levels-of-service
• Would an Internet bookstore designed to service 100 customers have
a different architecture from an Internet Bookstore designed to
support 100 Million?
• Domain Modeling is a useful activity to flesh out
requirements and design concerns as well as standardize on
language
3
Outline for Today
• Now that I have some designs in mind, how do
I capture them?
– Use Case Diagrams
– Sequence Diagrams
– Class Diagrams
– Deployment Diagrams
• Assignment Specifics
4
Why UML
• Started in 1994, led by Rational Software
Corporation, fused a number of modeling
approaches
– Booch Technique
– Object Modeling Technique
– Object-Oriented Software Engineering
• Extensive industry adoption
• Significant tool support
• Not the only ADL, but usually a decent choice
5
Example – Internet Bookstore
• Online retail outlet for purchasing books
• Provide basic user capabilities for:
– Searching for books
– Reviews & rating of books
– Purchase of books
• Interfaces to
shipping and
inventory
management
6
Internet Bookstore Requirements (1/2)
• The bookstore shall accept orders over the internet
• The bookstore shall maintain a list of accounts for up to
1,000,000 customers
• The bookstore shall provide password protection for all
accounts
• The bookstore shall provide the ability to search the master
book catalog
• The bookstore shall provide a number of search methods on
that catalog, including search by author, search by title, search
by ISBN number, and search by keyword
• The bookstore shall provide a secure means of allowing
customers to pay by credit card
7
Internet Bookstore Requirements (2/2)
•The bookstore shall provide a secure means of allowing
Customers to pay via purchase order
•The bookstore shall provide a special kind of account that
is pre-authorized to pay via purchase order
•The bookstore shall provide electronic links between the
Web and the book information database (BID) and the
shipping fulfillment center
•The bookstore shall maintain reviews of books and should
allow anyone to upload review comments
•The bookstore shall maintain ratings on books based on
customer inputs
8
Log-in Use Case
1. The Customer clicks the Login button on the
Home Page.
2. The system displays the Login Page.
3. The Customer enters his or her user ID and
password and then clicks the Login button.
4. The system validates the login information
against the persistent Account data and then
returns the Customer to the Home Page.
9
Use Case Basics
• The purpose of Use-Case Design is to discover the
necessary:
– Interface Objects & their classes
• e.g. pages, dialog boxes, representations of entities
– Entity Objects & their classes
• Both temporary & persistent,
• e.g., data structures, DB tables, etc
– Control Objects & their classes
• We’ll see examples on later slides
– You know what an Interface Class is & what an Entity Class is, so
don’t worry if you don’t yet know what a Control Class is (you’ll
find out soon)
– The messages they exchange
10
UML Use-Case Symbols
• Interface Classes are labeled with:
– These objects interact with actors in the use-case
• Entity Classes are labeled with:
– These are data classes
• Control Classes are labeled with:
– These can be thought of as activity or control flow
classes
• Actors in the use-case are labeled with:
NOTE: Don’t get caught up on diagram specifics
11
Use-Case: Step 1
• Step 1: The Customer clicks the Login button
on the Home Page
Q. Why did we not explicitly model
the login button?
Short Answer: Judgment call
Longer Answer: “Click log In” is a
simple behavior, the whole of which
can be conveyed simply.
12
Use-Case: Step 2
• The system displays the Login Page.
A good intuitive understanding of
Control Objects is that they will
ultimately become methods
13
Use-Case: Step 3
• The Customer enters his or her user ID and
password and then clicks the Login button.
14
Use-Case: Step 4
• The system validates the login information
against the persistent Account data and then
returns the Customer to the Home Page.
15
But what about off-nominal cases?
16
Log-in Use Case Alternatives
• If the Customer clicks the New Account button on the Login Page, the
system invokes the Open Account Use-Case.
• If the Customer clicks the Password Reminder button on the Login Page,
the system displays the reminder word stored for that Customer, in a
separate dialog box. When the Customer clicks the OK button, the system
returns the Customer to the Login Page.
• If the Customer enters a user ID that the system does not recognize, the
system displays a message to that effect and prompts the Customer to
either enter a different ID or click the New Account button.
• If the Customer enters an incorrect password, the system displays a
message to that effect and prompts the Customer to reenter his or her
password.
• If the Customer enters an incorrect password three times, the system
displays a page telling the Customer that he or she should contact
customer service, and also freezes the Login Page.
17
Use-Case: Alternative 1
• If the Customer clicks the New Account button
on the Login Page, the system invokes the
Open Account Use-Case.
Illustration of hierarchical
Use-case composition.
18
Use-Case: Alternative 2
• If the Customer clicks the Password Reminder
button on the Login Page, the system displays the
reminder word stored for that Customer, in a
separate dialog box.
I’ll leave the rest of the
alternatives to you as an
exercise.
19
Search by Author Use Case
• The Customer types the name of an Author on the Search Page and
then presses the Search button. The system ensures that the
Customer typed a valid search phrase, and then searches the
Catalog and retrieves all of the Books with which that Author is
associated. Then the system retrieves the important details about
each Book, and creates a Search Results object with that
information. Then the system displays the list of Books on the
Search Results Page, with the Books listed in reverse chronological
order by publication date.
• Each entry has a thumbnail of the Book's cover, the Book's title and
authors, the average Rating, and an Add to Shopping Cart button.
The Customer presses the Add to Shopping Cart button for a
particular Book. The system passes control to the Add Item to
Shopping Cart Use-Case.
20
Search by Author Alternatives
• If the Customer did not type a search phrase before
pressing the Search button, the system displays an
error message to that effect and prompts the Customer
to type a search phrase.
• If the system was unable to find any Books associated
with the Author that the Customer specified, the
system displays a message to that effect and prompts
the Customer to perform a different search.
• If the Customer leaves the page in a way other than by
pressing an Add to Shopping Cart button, the system
returns control to the Use-Case from which this UseCase received control.
21
Search by Author Use-Case Diagram
22
Sequence Diagram Basics
• Top Elements – Classes in the eventual design
– Actors, Interface Classes, Entity Classes
• Left Elements – Use Case Description
• Arrows indicate Messages
– What the methods should be
– Which object each method
should belong to
– Which object(s) calls which
method, and at exactly what
point during the course of
Use Case
the Use-Case
Description
23
Log In Sequence Diagram
24
Class Diagrams
• Some of your objects will be implemented as classes
• Each class consists of three elements:
– name
– attributes
– Operations
• Relationships between classes:
25
Class Relationships
•
Association
–
–
–
–
–
–
•
Aggregation
–
–
–
–
•
Basic aggregation
Multiple aggregation
Self-aggregation
Composition
Generalization
–
–
•
Binary association
N-ary association
One-way navigation
Named association
Association by roles
Association multiplicity
Basic generalization
Multiple generalization (Powertype)
Dependency
–
–
–
–
–
–
–
–
–
–
–
Basic dependency
Usage dependency
Creation dependency
Instantiation dependency
Abstraction dependency
Derivation dependency
Realization dependency
Refinement dependency
Trace dependency
Permission dependency
Substitution dependency
Some Advice: For the purposes of your
assignments in this class, stick to the basics:
- Binary, N-ary associations w/ multiplicity
- Basic aggregation/composition
- Basic dependencies
Remember, it’s a model of your system…
26
Deployment Diagrams
• Deployment diagrams show the relationship
between the hardware and software
components in the system
Typically not very useful for
577 projects, but useful to
Understand for more complex,
Distributed systems.
27
Context Diagrams
• Show a system’s external interfaces.
From Agile Modeling: Effective Practices for Extreme Programming
and the Unified Process by Scott Ambler.
28
ARB Specifics
• In the first ARB (10/18-10/22), you will need
to generate the following:
– System Analysis
• Artifacts and Information Model
• Use-Case Model
• System Context Model
– Design Model
• Initial Design
• At the very least, a deployment diagram
29
Artifacts and Information Model
•
•
•
•
Primary documentation of Entity Classes
Use Class Diagrams to model the Entity classes
Similar to E-R diagram
Ultimately, we will use these diagrams to
develop the persistence layers in the system
30
Use Case Models
•
•
•
•
Capture all nominal cases
Keep the specification to a high level
Alternatives for primary use-cases
Show hierarchical relationships
31
Context Diagram
• Basically just as advertised
• Show the hierarchy of the user classes and
how they interact with the system
32
Rationale Tutorial & Workshop
• Tip will be holding tutorials on using Rational
software in the next week
– Please attend if you are unfamiliar
• On 10/11, we will be holding a design workshop
– Bring in your designs prior to ARB
– We can provide feedback on:
• Scope
• Detail
• Modeling nomenclature
33
Conclusions
• UML is an industry standard for documenting
software system design
• UML is a LARGE standard (I’m being polite), so
this lecture is intended to be an introduction, not
a comprehensive guide
• Use-cases help designers to:
– Create sequence diagrams
– Tease out objects that will be implemented as classes
– Understand class methods
• Rationale tutorial and the design workshop will
help to flesh out your designs prior to the ARB
34