06 Uml
06 Uml
06 Uml
Notation wars
Early 90s: 6-10 different notations 6
HIC (Human Interaction Component) PDC (Problem Domain Components) Why is Separation of Concerns principle a good idea? Coad & Nicola call this the "I'm alive principle": "I'm
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."
Add decorations to lines to refine them But before we study the decorations.
Is a" relationship can mean SUBTYPE ("a square is a polygon") or INSTANCE-OF ("George is a square") INSTANCEor IDENTICAL-TO ("The morning star is the evening star") IDENTICALor PROPERTY-OF ("A circle is a round object") PROPERTYor ROLE-OF ("George is a President") ROLEor MADE-OF ("My house is a brick one") MADEor simply EXISTS (To be or not to be"). In many languages, there is no verb "is" at all, or its rarely used. 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 OOOA typically distinguishes two relations: is-a and has-a ishasWhy two? two? Thats what O-O programming languages implement: O
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/wholeClient-supplier/association/whole-part
Typically parts or members of a class Manager -1 * -> Employee Denotes 1 to many (*) relationships 0 to many, 1 to 1 relationships also common From Extended Entity-Relation models (EER) EntityManager sales rep -> Employee Employee's role is sales rep
Which of these five activities are analysis and which are design?
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}
Decorations for multiplicity, role names, constraints What does {ordered} constraint mean? Arrow denotes navigability e.g., Polygon and Circle refer to Point but not vice versa A black-filled diamond denotes a composition blacka part, unique to this whole
A white-empty diamond denotes an aggregation whitea 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
Class name, attributes and operations Typically attributes are built-in types builtUML lets you include information about default values and visibility (+,-,#) (+,E.g., - name: String
private
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 plugOpen Source IDE for O-O and Java O
PlugPlug-ins add more features DrJava plug-in provides Java interpreter plugOmondo plug-in adds UML class diagrams plugAvailable on campus by running eclips http://www.lehigh.edu/~sgh2/ (version 2.1) or http://www.lehigh.edu/stem/teams/dieruff (3.0) http://www.lehigh.edu/stem/teams/dieruff
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
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 objects lifeline
Represents an objects life during interaction 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: 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?
Collaboration diagrams
Objects are rectangular icons
e.g., Order Entry Window, Order, etc. e.g., prepare() Also spatial layout helps show flow
Which do you prefer: sequence or collaboration diagrams? Fowler now admits he doesnt 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 isnt impressed
CRC cards
(See multimedia from The Universal Machine on CRC cards)
See http://c2.com/doc/oopsla89/paper.html This is the same Kent Beck that later wrote the book pioneering Extreme Programming. Fowler introduces CRC and end of chapter 4
Responsibilities
Key idea: objects have responsibilities
Anthropomorphism of class responsibilities gets away from thinking about classes as just data holders
Object think focuses on their active behaviors Client can expect predictable behaviors 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.
LowLow-tech
Ordinary index cards
Each card represents a class of objects. 3x5 is preferable to 4x6 at least early on Why? 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) CardReader, that manages bank cards 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 multi
such as CardReader rather than CARDREADER or card_reader. Why do most OO developers prefer this convention? E.g., is TermProcess something that terminates or something that runs on a terminal? Better for instances than classes of objects
Responsibilities section
Describes a classs behaviors
Describe what is to be done, not how! how! E.g.: reads card or look up words
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?
As you write down responsibilities for a class, add any suppliers needed for them
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 objectto a problem domain
An analyst can prototype a system by running a simulation of objects and their behaviors
Once youve developed a set of CRC cards, you're ready to run simulations 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 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, responsibilityrather than design. design.
State diagrams show the behavior of a single object across many use cases Well examine state diagrams when we get to design