Unified Modeling Language
for OO domain analysis
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
Extract commonality among specializations
UML uses arrow
Generalizations form a hierarchy
Multiple inheritance forms a lattice
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
[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
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
CRC cards
(See multimedia from The Universal Machine on CRC cards)
Developed by Beck and Cunningham at Tektronix
See http://c2.com/doc/oopsla89/paper.html
This is the same Kent Beck that later wrote the book
pioneering Extreme Programming.
CRC cards are now part of XP.
Fowler introduces CRC and end of chapter 4
Key idea: objects have responsibilities
As if they were simple agents (or actors in scenarios)
Anthropomorphism of class responsibilities gets away
from thinking about classes as just data holders
“Object think” focuses on their active behaviors
Each object is responsible for specific actions
Client can expect predictable behaviors
Responsibility also implies independence:
To trust an object to behave as expected is to rely upon its
autonomy and modularity
Harder to trust objects easily caught up in dependencies caused
by global variables and side effects.
Ordinary index cards
Each card represents a class of objects.
3x5 is preferable to 4x6 at least early on – Why?
Each card has three components
Name, Responsibilities, Collaborators
Class names
Class Name creates the vocabulary of our analysis
Use nouns as class names, think of them as simple agents
Even classes that you think of verbs or actions can be made into nouns
E.g., “reading a card” becomes CardReader, a class of object (agent)
that manages bank cards
Use pronounceable names
If you cannot read aloud, it is not a good name
Use capitalization (or underscores) to initialize class names and to
demarcate multi-word names
such as CardReader rather than CARDREADER or card_reader.
Why do most OO developers prefer this convention?
Avoid obscure, ambiguous abbreviations
E.g., is TermProcess something that terminates
or something that runs on a terminal?
Try not to use digits within a name, such as CardReader2
Better for instances than classes of objects
Responsibilities section
Describes a class’s behaviors
Describe what is to be done, not how!
Use short verb phrases
E.g.: “reads card” or “look up words”
How do constraints of index cards guide class
A good measure of appropriate complexity
If you cannot fit enough tasks on a card,
maybe you need to divide tasks between classes,
on different cards?
Lists important suppliers and possibly clients of a class
Why are classes that supply services more important
Suppliers are necessary for the description of responsibilities
As you write down responsibilities for a class, add any
suppliers needed for them
For example “read dictionary” obviously implies that a “dictionary”
as a collaborator
Developing CRC cards is first a process of discovering
classes and their responsibilities
People naturally cut up the world in terms of categories of objects
In object-oriented analysis, one discovers new categories relevant
to a problem domain
CRC card simulations
Designing for responsibility involves simulation
Objects model a world interacting behaviors
An analyst can prototype a system by running a simulation of objects
and their behaviors
Once you’ve developed a set of CRC cards, you're ready to run
or structured walkthrough scenarios -Play “what if” to simulate scenarios that illustrate use of a system
Let each person be responsible for simulating one or more classes
“Execute” a scenario by having each object, run at the right time
Start a simulation with the construction of an object of a class,
then run one of its behaviors (a responsibility of that class)
This behavior may pass control to some collaborator -- another class
Simulation becomes visible as an exchange of behavior and control from
one card to another
You may discover missing or incompletely described responsibilities
IMO, it really should be called responsibility-driven analysis,
rather than design.
Why? When is activity most useful?
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
Addendum for your
team project assignment
In addition to a class diagram
for your project’s problem domain,
Create one or more interaction (either sequence or
collaboration) diagrams showing dynamic behavior
of your classes
Use a UML tool such as Eclipse with Omondo
or Rational Rose or google for a free one
CRC cards are optional though recommended
Project analysis due Monday, February 27

Unified Modeling Language (UML) for OO domain analysis