8. The UML is a standard
graphical notation for
describing object-oriented
software systems
9. Use UML to visualize,
communicate, and
emphasize your choices
10. 1 Library
checkout 1 Membership
return start : Date
renewal : Date
* due : Date
LendRecord
Lendable
1 returned : Boolean
id
newArrival : Boolean * LendRecord(lendable, member, date)
calcDueDate(member): Date isDue() : Boolean
renew(Date)
*
Book CD 1
*
Member
DVD
Goal: Understand this
11. : Library aMember aLendable
checkout(lendable, member)
canBorrow(lendable)
numOut(member)
opt calcDueDate(member)
{ canBorrow == true }
dueDate
record
new
aLendRecord
And this
18. left
BinaryTree 1 0..1
0..1 1
add(obj: Obect)
remove(obj) root TreeNode Object
contains(obj):bool 0..1
right
<<interface>>
TreeIterator
hasNext : bool
next : Object
PrefixTreeIterator PostfixTreeIterator InfixTreeIterator
Example: Binary tree
19. 1 Library
checkout 1 Membership
return start : Date
renewal : Date
* due : Date
LendRecord
Lendable
1 returned : Boolean
id
newArrival : Boolean * LendRecord(lendable, member, date)
calcDueDate(member): Date isDue() : Boolean
renew(Date)
*
Book CD 1
*
Member
DVD
Example: Library Classes
34. Resources
• UML Distilled by Martin Fowler
• http://bdn.borland.com/article/
0,1410,31863,00.html
• http://www.uml.org
• http://www.agilemodeling.com
35. (cc) 2006 Lou Franco
Released under the following creative commons license
Attribution-NonCommercial-ShareAlike 2.0
http://creativecommons.org/licenses/by-nc-sa/2.0
Each photograph used has a URL for attribution. Please
see the original site for the photo’s license.
Notes de l'éditeur
UML is used to model OO design, but what is design?
First there are problems, and problems have many solutions. Each solution has its own trade-offs between benefits and drawbacks.
Design is choosing the combination of tradeoffs that best solves our problem
1. Faster to model than to implement
2. Helps us choose
3. Try different approaches (to compare)
4. Finish the most promising ones
1. Communicate to yourself
2. Communicate to implementors
3. Communicate to domain experts
1. Models show the important choices
2. Leave out details to emphasize
3. Several different views on same structure
UNIFIED MODELING LANGUAGE
Unifies: Booch, Rumbaugh, Jacobson
Language: Can be used to implement a software system -- equivalent to code
omg (uml.org) &#x201C;A specification defining a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems.&#xA0;&#x201C;
Unifies 50+ OO modeling systems
Main point
Class name could be just the Name or Package::Name
attribute spec is
attribute:Type[multiplicity] = default value
operation spec is
operation : (arg: ArgType, arg2: Arg2Type=default) : Type
1. Everything is optional (name could be class name)
2. Multiplicity
3. Bidirectional
Top is an association class, where each pairing of Library and Member is represented in a Membership class
Bottom is a qualified association where Library has a map of id to Lendable. The Multiplicity is per id.
Don&#x2019;t show datastructures, unless ...
call, create, permit (friend), use
The word generalization emphasizes the role of the base class. Don&#x2019;t think is-a -- think substitutability.
Top one emphasizes that Clipboard uses an interface and DataObject is just one of those
Bottom one emphasizes that DataObject provides an interface and Clipboard is a class that would use it
Only time to show datastructures is if that&#x2019;s specifically what you&#x2019;re monitoring
Objects are underlined, either the object name or the class name is optional. If just showing class, keep the colon. The lifeline is the lifetime of the object -- sequence diagrams are read top-down with time passing as we go down.
messages are shown with arrows, returns are dashed arrows. Line arrow heads are asynch calls (but you will see half arrows used instead -- old convention).
During the bar, the class is active (the message is in the stack frame)
m calls m.1, m.2, etc. m.n calls m.n.1, m.n.2, etc.
Order is 1, 1.1, 1.1.1, 1.2, 1.3, 1.3.1
All classes in each package need to follow this dependency, classes in view can depend on classes in model, but not vice versa.
each swim lane has an actor (who is doing the activity)
diamond is a branch
There are also symbols for sending and receiving signals