Unified Modeling Language
(UML)
for OO domain analysis
CSE432
Prof Glenn Blank
Notation wars
Early 90’s: 6-10 different notations

Bertrand Meyer: circles and arrows
Distinguishes inheritance and client/supplier relationships

Grady Booch: clouds, lines and decorations
GardeningPlan – Association- Environmental Controller
Heater and Cooler – Generalization/Specialization-> Actuator
Environmental Controller ●-“has a”- Heater (Cooler, Light)
Actuator o– “using” – Temperature (client/supplier)
Actuator is an abstract class (‘A’ in a triangle)

Peter Coad, Ed Yourdon & Jill Nicola:
Rounded boxes and annotated lines
Line bisected by semi-circle represents generalization (inheritance)
Line bisected by triangle represents whole/part

So, what’s your reaction to all these (and more) notations?
“Can’t we all get along?” Hence three amigos create UML in mid-90’s
Closer look at Coad & Nicola
Two different boxes grouping classes:



HIC (Human Interaction Component)
PDC (Problem Domain Components)
Why is “Separation of Concerns principle” a good idea?
First person scenarios

Coad & Nicola call this the "I'm alive principle":
Objects can be better understood by thinking about them and talking
about them in the first person:
"I know my own ____ and I can ___ myself."

What goes in the blanks?
Attributes and behaviors

Why is putting these scenarios in the first person a good idea?
Promotes “object-think”: objects are autonomous, performing behaviors
Similarly, Kent Beck talks about the need for anthropomorphism in
responsibility-driven design
Class diagrams in UML
Classes are boxes, lines are associations


Add decorations to lines to refine them
But before we study the decorations….
A heuristic for class diagram design
Don't put any decorations on the associations at first
Semantics of relations tends to be vague








“Is a" relationship can mean SUBTYPE ("a square is a polygon")
or INSTANCE-OF ("George is a square")
or IDENTICAL-TO ("The morning star is the evening star")
or PROPERTY-OF ("A circle is a round object")
or ROLE-OF ("George is a President")
or MADE-OF ("My house is a brick one")
or simply EXISTS (“To be or not to be…").
In many languages, there is no verb "is" at all, or it’s rarely used.
Let the meaning of relations emerge from what they relate

Vagueness is natural: start off vague, get more specific gradually
UML supports this heuristic by starting with simple
undirected lines (associations)
Later, add detail to your relationship structures
Two basic relationships of O-O
OOA typically distinguishes two relations: is-a and has-a
Why two?
That’s what O-O programming languages implement:


Smalltalk and Java: instance variables and inheritance
C++: data members and class derivation
Meyer calls these inheritance and client/supplier
Booch: generalization/specialization and
association or aggregation or composition
Coad and Yourdon: gen/spec and whole/part
UML calls these generalization
and association or aggregation or composition
Generalizations
(inheritance)
Extract commonality among specializations
UML uses arrow
Generalizations form a hierarchy
Multiple inheritance forms a lattice
Associations
Client-supplier/association/whole-part

Typically parts or members of a class
Multiplicity: numbers at connection ends




Manager -1――* -> Employee
Denotes 1 to many (*) relationships
0 to many, 1 to 1 relationships also common
From Extended Entity-Relation models (EER)
Role names at one connection end:


Manager ―― sales rep -> Employee
Employee's role is sales rep
Five activities of OOA
Coad, Yourdon and Nicola:
1) Class-&-object: describe problem domain
in terms of classes of objects
2) Structure: describe relationships between classes
3) Subject: organize classes into clusters or packages
4) Attributes: describe data held by objects
5) Services: describe behaviors that objects can perform
Which of these five activities are analysis
and which are design?
Class & Object analysis
Another look at Coad & Nicola notation



Why do all the classes except Count
have extra grey boxes?
An abstract class has one or more operations
that must be implemented by subclasses
UML represents an abstract class
by italicizing the class name
or adding the constraint label {abstract}
Structure (association) analysis
Lines connecting classes
In UML, simple line is an association

Decorations for multiplicity, role names, constraints
See example from Fowler

What does {ordered} constraint mean?
Aggregations and composition:



Arrow denotes navigability
e.g., Polygon and Circle refer to Point but not vice versa
A black-filled diamond denotes a composition
a part, unique to this whole

A white-empty diamond denotes an aggregation
a part, but not unique to this whole

E.g., A Point may appear in only one Polygon or Circle
but a Style could appear in both
An alternative notation for composition in boxes
Attributes and operations
A class box may have three parts

Class name, attributes and operations
Attributes in middle section


Typically attributes are built-in types
UML lets you include information about default values
and visibility (+,-,#)
E.g., - name: String
private
[1] = “Untitled” {readonly}
: type multiplicity default {property} (unmodifiable)
I recommend you hold off on these details until design
Operations in bottom section of class box


Represent services, functions or methods
Again, UML has a bit more notation,
for information about parameters, default values and visibility
E.g., + balanceOn(date:Date): Money
Again, I recommend you hold off on these details until design
Your next assignments
http://www.cse.lehigh.edu/~glennb/oose/afruit.htm
Note that there are two problems: fruit and undo
Due Sunday, February 19
Project analysis due Monday, February 27
Eclipse with plug-ins
Open Source IDE for O-O and Java





Plug-ins add more features
DrJava plug-in provides Java interpreter
Omondo plug-in adds UML class diagrams
Available on campus by running “eclips”
http://www.lehigh.edu/~sgh2/ (version 2.1)
or http://www.lehigh.edu/stem/teams/dieruff (3.0)
Dynamic behaviors
Class diagrams represent static relationships. Why?
What about modeling dynamic behavior?
Interaction diagrams model how groups of object
collaborate to perform some behavior

Typically captures the behavior of a single use case
Use Case: Order Entry
1) An Order Entry window sends a “prepare” message to an Order
2) The Order sends “prepare” to each Order Line on the Order
3) Each Order Line checks the given Stock Item
4) Remove appropriate quantity of Stock Item from stock
5) Create a deliver item
Alternative: Insufficient Stock
3a) if Stock Item falls below reorder level
then Stock Item requests reorder
Sequence diagram
Vertical line is called an object’s lifeline

Represents an object’s life during interaction
Object deletion denoted by X, ending a lifeline

Horizontal arrow is a message between two objects
Order of messages sequences top to bottom
Messages labeled with message name,
optionally arguments and control information
Control information, in brackets, may express conditions,
such as [hasStock], or iteration
Returns (dashed lines) are optional; use them to add clarity
Sequence diagrams can also represent concurrent processes:



UML 1 models asynchronous messages as horizontal lines with half arrow heads
UML 2 makes this distinction by not filling an arrowhead
Fowler prefers older notation. Why? Which do you prefer?
After setting up Transaction Coordinator,
invoke concurrent Transaction Checkers

If a check fails, kill all the Transaction Checker processes
Note use of comments in margin – When is this a good idea?
Collaboration diagrams
Objects are rectangular icons

e.g., Order Entry Window, Order, etc.
Messages are arrows between icons

e.g., prepare()
Numbers on messages indicate sequence

Also spatial layout helps show flow
Which do you prefer: sequence or collaboration diagrams?
Fowler now admits he doesn’t use collaboration diagrams

Interaction diagrams show flow clearly,
but are awkward when modeling alternatives
UML notation for control logic has changed in UML 2
but Fowler isn’t impressed
From CRC cards
to Interaction diagrams
Fowler recommends first using CRC cards
to begin modeling scenarios
Then document with UML sequence
(or collaboration) diagrams
Why might this be a good approach?
Sequence diagrams show collaborations
among many objects in a single use case


State diagrams show the behavior of a single object
across many use cases
We’ll examine state diagrams when we get to design