Unified Modeling Language (UML) for OO domain analysis

CSE432 Prof Glenn Blank

Notation wars
Early 90s: 6-10 different notations 6

Bertrand Meyer: circles and arrows Meyer:

Distinguishes inheritance and client/supplier relationships

Grady Booch: clouds, lines and decorations Booch:

GardeningPlan Association- Environmental Controller AssociationHeater and Cooler Generalization/Specialization-> Actuator Generalization/SpecializationEnvironmental Controller -has a- Heater (Cooler, Light) aActuator o using Temperature (client/supplier) o Actuator is an abstract class (A in a triangle)

Peter Coad, Ed Yourdon & Jill Nicola: Nicola:

Rounded boxes and annotated lines Line bisected by semi-circle represents generalization (inheritance) semiLine 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 mid-

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? 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."

First person scenarios



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 objectSimilarly, Kent Beck talks about the need for anthropomorphism in responsibilityresponsibility-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") 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

Let the meaning of relations emerge from what they relate



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

Multiplicity: Multiplicity: numbers at connection ends

   

Role names at one connection end:

 

Five activities of OOA

Coad, Yourdon and Nicola:
1) Class-&-object: describe problem domain Classin 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 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

See example from Fowler



Aggregations and composition: composition:

  

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

An alternative notation for composition in boxes

Attributes and operations

A class box may have three parts


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

Attributes in middle section

 

[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. 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 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


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 objects lifeline


Represents an objects life during interaction Horizontal arrow is a message between two objects

Object deletion denoted by X, ending a lifeline



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?

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. e.g., prepare() Also spatial layout helps show flow

Messages are arrows between icons



Numbers on messages indicate sequence



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)

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. Fowler introduces CRC and end of chapter 4

CRC cards are now part of XP. XP.



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 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.

Each object is responsible for specific actions



Responsibility also implies independence:



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

Each card has three components



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 pronounceable names



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

Avoid obscure, ambiguous abbreviations



Try not to use digits within a name, such as CardReader2



Responsibilities section
Describes a classs behaviors


Describe what is to be done, not how! how! E.g.: reads card or look up words

Use short verb phrases



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 cut up the world in terms of categories of objects In object-oriented analysis, one discovers new categories relevant objectto 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 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

Execute a scenario by having each object, run at the right time

   

IMO, it really should be called responsibility-driven analysis, responsibilityrather than design. 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 Well examine state diagrams when we get to design

Addendum for your team project assignment

In addition to a class diagram for your projects 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