OO domain modeling with UML class diagrams and CRC cards - PowerPoint PPT Presentation

About This Presentation
Title:

OO domain modeling with UML class diagrams and CRC cards

Description:

with UML class diagrams. and CRC cards. CSE432. Prof Glenn Blank ... This is the same Kent Beck that later wrote the book pioneering Extreme Programming (XP) ... – PowerPoint PPT presentation

Number of Views:1271
Avg rating:3.0/5.0
Slides: 35
Provided by: GlennD
Category:

less

Transcript and Presenter's Notes

Title: OO domain modeling with UML class diagrams and CRC cards


1
OO domain modelingwith UML class diagramsand
CRC cards
  • CSE432
  • Prof Glenn Blank

2
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

3
A Domain Model is Conceptual,not a Software
Artifact
Software Artifacts
  • Conceptual Class

SalesDatabase

Sale
amt item
vs.
Sale
Double amt Item item
void print()
Whats the difference?
4
Domain Model Relationships
Domain Model
Conceptual Class Diagram
Classes, attributes, associations
Define terms
Domain objects
Use Case Model
Glossary
Functional Requirements
Interaction Diagrams
Dynamic Behavior
What do you learn about when and how to create
these models?
5
Identify conceptual classesfrom 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

6
From NPs to classes or attributes
Consider the following problem description,
analyzed for Subjects, Verbs, Objects
  • The ATM verifies whether the customer's card
    number and PIN are correct.
  • S V
    O O OIf 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

A
C
A
R
A
A
R
A
M
A
A
A
A
M
R
R
A
A
A
M
C
A
A
C
7
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
Die
Board
Piece
Square
Player
9
Monopoly Game domain modelLarman, Figure 9.28
10
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

11
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

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

13
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

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

15
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

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

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

18
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

19
Class diagrams in UML
  • Classes are boxes, lines are associations
  • Add decorations to lines to refine them
  • But before we study the decorations.

20
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

21
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

22
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

employee
employer
Person
Company
0..
1
works for
23
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

24
Generalization Example
25
Advantages of Inheritance?
26
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?
27
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

28
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 shapes10 //Why is this legal?
  • shapes0 new Circle(Point(20,30),7)
    //assign a Circle
  • shapes1 new Triangle(Point(50,50),Point(30,30
    ),Point(40,40))
  • //... maybe assign other shapes, Rectangles,
    Squares, etc.
  • for (int i0 i lt 10 i) //draw all the
    shapes
  • shapesi-gtdraw() //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

29
Why dynamic binding?
  • What kind of code does dynamic binding avoid?
  • Avoids lots of switch statements, e.g.
  • switch (shapesi-gtisa)
  • //each Shape derived class has an isa data
    member
  • case(triangle) Triangledraw() //test
    enumeration
  • case(circle) Circledraw() //run
    specific draw()
  • // ...
  • Why is the dynamic binding version better for
    big, growing programs?
  • Many design patterns build on polymorphism

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

31
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

32
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

33
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

34
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)
Write a Comment
User Comments (0)
About PowerShow.com