Unified Modeling Language (UML) for OO domain analysis

1
Unified Modeling Language (UML)for OO domain
analysis

• CSE432
• Prof Glenn Blank

2
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
  -gt 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, whats your reaction to all these (and more)
  notations?
• Cant we all get along? Hence three amigos
  create UML in mid-90s

3
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

4
Class diagrams in UML

• Classes are boxes, lines are associations
• Add decorations to lines to refine them
• But before we study the decorations.

5
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

6
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

7
Generalizations (inheritance)

• Extract commonality among specializations
• UML uses arrow
• Generalizations form a hierarchy
• Multiple inheritance forms a lattice

8
Associations

• Client-supplier/association/whole-part
• Typically parts or members of a class
• Multiplicity numbers at connection ends
• Manager -1?? -gt 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 -gt Employee
• Employee's role is sales rep

9
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?

10
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

11
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

12
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(dateDate) Money
• Again, I recommend you hold off on these details
  until design

13
Your next assignments

• 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

14
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)

15
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
•  

16
Sequence diagram

• Vertical line is called an objects lifeline
• Represents an objects 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?

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

18
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

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

20
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

21
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

22
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?

23
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 to a problem domain

24
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
• 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?

25
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

26
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