OO domain modeling

with UML class diagrams

and CRC cards
CSE432
Prof Glenn Blank
What is a Domain Model?
Illustrates meaningful conceptual classes
in problem domain
Represents real-world concepts,
not software components
Software-oriented class diagrams will
be developed later, during design
A Domain Model is Conceptual,
not a Software Artifact
Sale
amt
item
SalesDatabase
Sale
Double amt;
Item item;
void print()
Conceptual Class:
Software Artifacts:
vs.
Whats the
difference?
Domain Model Relationships
Domain Model
Use Case Model
Interaction Diagrams
Glossary
Dynamic Behavior
Functional Requirements
Conceptual Class Diagram
Classes, attributes, associations
Domain
objects
Define terms
What do you learn about when and how to create these models?
Identify conceptual classes
from noun phrases
Vision and Scope, Glossary and Use Cases
are good for this type of linguistic analysis
However:
Words may be ambiguous or synonymous
Noun phrases may also be attributes or
parameters rather than classes:
If it stores state information or it has multiple behaviors,
then its a class
If its just a number or a string, then its probably
an attribute
From NPs to classes or attributes
The ATM verifies whether the customer's card number and PIN are correct.
S V O O O
If it is, then the customer can check the account balance, deposit cash, and withdraw cash.
S V O V O V O
Checking the balance simply displays the account balance.
S O V O
Depositing asks the customer to enter the amount, then updates the account balance.
S V O V O V O
Withdraw cash asks the customer for the amount to withdraw; if the account has enough cash,
S O V O O V S V O
the account balance is updated. The ATM prints the customers account balance on a receipt.
O V S V O O
Analyze each subject and object as follows:
Does it represent a person performing an action? Then its an actor, R.
Is it also a verb (such as deposit)? Then it may be a method, M.
Is it a simple value, such as color (string) or money (number)?
Then it is probably an attribute, A.
Which NPs are unmarked? Make it C for class.
Verbs can also be classes, for example:
Deposit is a class if it retains state information


R
R
M
M
A A
A
A
A A
A
A A
A A
A A
A
C
C
R
M
R
Consider the following problem description, analyzed for Subjects, Verbs, Objects:
C
Steps to create a
Domain Model
Identify candidate conceptual classes
Draw them in a UML domain model
Add associations necessary to record
the relationships that must be retained
Add attributes necessary for information
to be preserved
Use existing names for things,
the vocabulary of the domain

8
Monopoly Game domain model
(first identify concepts as classes)
Monopoly Game
Player
Piece
Die Board
Square
Monopoly Game domain model
Larman, Figure 9.28

Discovering the Domain Model with CRC cards
(See multimedia from The Universal Machine on CRC cards:
umwords)
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 (XP)
CRC cards are now part of XP
Low-tech
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

Responsibilities
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.
Class names
Class Name creates the vocabulary of our analysis
Use nouns as class names, think of them as simple agents
Verbs can also be made into nouns, if they are maintain state
E.g., reads card suggests CardReader, managing bank cards
Use pronounceable names:
If you cannot read aloud, it is not a good name
Use capitalization to initialize Class names and
demarcate multi-word names
E.g., 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 classs 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
analysis?
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?
Collaborators
Lists important suppliers and possibly clients of a class
Why are classes that supply services more important here?
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 perceive the world as 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
After developing a set of CRC cards, run simulations
AKA 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 of classes performing responsibilities:
Start a simulation with the construction of an object of a class,
then perform one of its responsibilities (a behavior)
A responsibility may pass control to a collaborator -- another class
Simulation becomes visible as a sharing of responsibilities
You may discover missing or incompletely described responsibilities
See football example in multimedia
IMO, it really should be called responsibility-driven analysis,
rather than responsibility-driven design.
Why? When is responsibility driven activity most useful?
Class Diagram Notation Wars
Early 90s: 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
Line bisected by triangle represents whole/part
So, whats your reaction to all these (and more) notations?
Cant we all get along?
Hence three amigos create UML in mid-90s



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?
Object-think: objects are autonomous, perform 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 its 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?
Thats 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
Associations
A link between two classes (has a)
Typically modeled as a member reference
Notation from Extended Entity Relation (EER) models
A Person works for a Company









Role names and multiplicity at association ends
Direction arrow to aid reading of association name
Person
Company
employee
employer
works for
Association Name
Role
0..* 1
Generalization / Specialization
Classes may be subclasses of other classes
a kind of or is a
Cars are a kind of vehicle (Or a car is a vehicle)
Chairs are a kind of furniture
People are a kind of mammal
Generalization captures commonality:
What do cars have in common with vehicles?
Same properties and behaviors
UML: generalization/specialization relationship
Drawn as a line with an arrow head on one end
Inheritance in OO programming languages

Generalization Example
Mammal
Puma Tiger
Feline
Quadruped
Lion
Lizard
Advantages of Inheritance?
GrainStore
grainType : String
grainGrade : String
capacity : int
quantity : int
add( amount : int, type : String, grade : String )
remove( amount : int )
getType() : String
getGrade() : String
getCapacity() : int
getQuantity() : int
RailCar Silo Truck
OOP = Data abstraction
+ inheritance
+ dynamic binding (polymorphism)
Polymorphism: a function can do different behaviors at runtime
Dynamic binding: delay function binding to a subtype until runtime
Suppose we want to draw a heterogeneous collection of shapes?
class Point { ... }; //a Point has x and y coordinates
class Shape {
protected: //accessible to subclasses but otherwise private
Point center; //all Shapes have a center Point
public:
Point where() { return center; } //early binding by default
virtual void move(Point to) //can override virtual function
{ center = to; draw(); } // by derived classes
virtual void draw()=0; //=0 is a "pure" virtual function
//draw() must be implemented by derived classes
//...
};
//Why do we say Shape is an abstract class?
Subclasses override
virtual functions
class Triangle: public Shape {
Point sw, se, top; //Three points define triangle
public:
Triangle(Point a, Point b, Point c) : sw(a), se(b), top(c) {}
draw() //implementing pure virtual function
{ put_line(sw,top); //draw line from sw to top
put_line(top,se); //draw line from top to se
put_line(se,sw); //draw line from se to sw
}
};
class Circle : public Shape {
int radius;
public:
Circle(Point a, int r) : center(a), radius(r) {}
draw(); //draw a circle using center and radius
};
Calling a virtual function
{ //Construct some shapes
Shape aShape; //illegal--why?
Circle c(Point(20,30),7); //legal--what does it do?

//Create an array of various shapes
Shape* shapes[10]; //Why is this legal?
shapes[0] = new Circle(Point(20,30),7); //assign a Circle
shapes[1] = new Triangle(Point(50,50),Point(30,30),Point(40,40));
//... maybe assign other shapes, Rectangles, Squares, etc.

for (int i=0; i < 10; i++) //draw all the shapes
shapes[i]->draw(); //each shape draws itself!
}
Why do we say that elements of shapes array are polymorphic?
Polymorphic design supports B. Meyers Open-Closed principle:
A module should be open to extension but closed to modification
So important that its built into most OO programming languages
Why dynamic binding?
What kind of code does dynamic binding avoid?
Avoids lots of switch statements, e.g.:
switch (shapes[i]->isa)
//each Shape derived class has an isa data member
{ case(triangle) Triangle::draw(); //test enumeration
case(circle) Circle::draw(); //run specific draw()
// ...
}
Why is the dynamic binding version better for
big, growing programs?

Many design patterns build on polymorphism
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?
Concrete and abstract classes
Identifying classes is 1st activity of domain
analysis
Remember the linguistic analysis technique
Can ignore inheritance and polymorphism for
first draft, then factor out commonality as
superclasses
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}
private : 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
Eclipse with plug-ins
Open Source IDE for O-O and Java
Plug-ins add more features
DrJava plug-in provides Java interpreter
Plug-in adds UML class diagrams
Available on campus by running eclips
Also available for download:
http://www.lehigh.edu/stem/teams/dieruff (3.0)