Class Model and Responsibility Driven Design

1
Class Model and Responsibility Driven Design

• Learning Object Think

2
Classes, Attributes, and Operations

• A class is a general template that we use to
  create specific instances, or objects, in the
  application domain
• All objects of a given class are identical in
  structure and behavior but contain different data
  in their attributes

3
Class Diagrams

• A CLASS
• Represents a kind of person, place , or thing
  about which the system will need to capture and
  store information
• Has a name typed in bold and centered in its top
  compartment
• Has a list of attributes in its middle
  compartment
• Has a list of operations in its bottom
  compartment
• Does not explicitly show operations that
  available to all classes

Class1
-attribute1
operation1()
4
Classes, Attributes, and Operations

• An attribute of an analysis class represents a
  piece of information that is relevant to the
  description of the class

5
Class Diagrams

• AN ATTRIBUTE
• Represents properties that describe the state of
  an object
• Can be derived from other attributes, shown by
  placing a slash before the attributes name
• The visibility of an attribute can be public (),
  protected (), or private (-)

attribute name/ derived attribute name
6
Classes, Attributes, and Operations

• An operation, is where the behavior of the class
  will be defined.
• In later phase, the operations will be converted
  to methods. However, since methods are more
  related to implementation, at this point in the
  development we use the term operation

7
Class Diagrams

• AN OPERATION
• Represents the actions or functions that a class
  can perform
• Can be classified as a constructor, query, or
  update operation
• Includes parentheses that may contain parameters
  or information needed to perform the operation
• The operations that are available to all classes
  (e.g., create a new instance, return a value for
  a particular attribute, or delete an instance)
  are not explicitly shown within the class
  rectangle

operation name ()
8
Relationships

• Generalization
• AKO as in An hourly employee is a kind of
  employee
• Superclass - Subclass
• Classification
• Aggregation
• A-part-of
• Association
• Verb
• Should make semantic sense

9
ako
10
A Part Of
Health Team
Doctor
Nurse
11
Verb
Patient
Appointment
Schedules
Text, page 194
12
Object Thinking

• Objects are more than simple bundles of data and
  logic
• They are
• Service providers
• Information-holders
• Structurers
• Coordinators
• Controllers
• Interfacers
• Thinking in these terms enables you to build
  powerful, flexible applications

13
Responsibility-Driven Design

• Other design methods tend to focus on logic and
  data alone. They leave out the big picture and
  miss the point of objects
• Responsibility-Driven Design enables you to think
  clearly about object design

14
Responsibility-Driven Design

• Objects play specific roles and occupy well-known
  positions in the application architecture.
• It is a smoothly-running community of objects.
• Each object is accountable for a specific portion
  of the work.
• They collaborate in clearly-defined ways,
  contracting with each other to fulfill the larger
  goals of the application

15
Responsibility-Driven Design

• The shift from thinking about objects as data
  algorithms, to thinking about objects as roles
  responsibilities can be a profound one
• During analysis we think about what the system is
  responsible for
• During design we map system responsibilities to
  appropriate object roles and responsibilities
• During coding we use responsibilities to define
  the interfaces of our classes and their test plans

16
CRC cards responsibilities

• Knowing responsibilities
• An instance typically knows the values of its
  attributes and its relationships
• An instance may be responsible for knowing other
  things as well
• Doing responsibilities
• Those things that an instance of class must be
  capable of doing

17
CRC cards collaborations

• Most use cases involve a set of several classes,
  not just one class.
• This set of classes forms a collaboration
• A collaboration is the set of classes involved a
  use case
• There is one for each use case

18
CRC cards collaborations

• Collaborations allow us to think in terms of
  clients, servers, and contracts
• A client object is an instance of a class that
  sends a request to an instance of another class
  for an operation to be executed
• A server object is instance that receives the
  request from a client object
• A contract formalizes the interactions between
  the client and server objects.

19
Anthropomorphism

• Pretending that the classes have human
  characteristics
• Also called The Animation Principle
• The idea is to use the CRC framework plus
  play-acting to help identify
• The classes
• Their attributes
• Their operations
• Their relationships

20
Elements of a CRC Card

• One per class
• Class name (a noun), ID, Type, description, list
  of associated use cases
• Lists the responsibilities (knowing and doing)
• Lists the collaborators (classes involved in the
  associated use cases)
• Lists the attributes (in back)
• Lists the relationships (in back)

21
Elements of a CRC Card
22
Elements of a CRC Card
23
Class Diagrams

• AN ASSOCIATION
• Represents a relationship between multiple
  classes, or a class and itself
• Is labeled using a verb phrase or a role name,
  whichever better represents the relationship
• Can exist between one or more classes
• Contain multiplicity symbols, which represent the
  minimum and maximum times a class instances can
  be associated with the related class instance

1.. verb phrase 0..1
24
Creating CRC Cards and Class Diagrams

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

25
Creating CRC Cards and Class Diagrams

• Textual Analysis
• Nouns classes
• Adjectives attributes
• Verbs operations and associations
• Common Object List
• Tangible things
• Incidents
• Interactions
• Patterns
• Collection of classes that solve recurring
  problems

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

26
Creating CRC Cards and Class Diagrams

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• Perform Textual Analysis on the Use Cases and
  other writings to identify candidate classes
• Each Use Case defines a collaboration, which is
  the collection of classes that interact in the
  use case
• Work on one collaboration at a time
• A class may belong to more than one collaboration

27
Creating CRC Cards and Class Diagrams

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• What are the tangible things associated with the
  problem?
• What incidents and interactions take place in
  the problem domain?
• It is possible to uncover additional roles
  outside the use cases and other writings

28
Creating CRC Cards and Class Diagrams

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• Each CRC card should be assigned to an
  individual, who will perform the operations for
  the class on the CRC card
• As the performers play out their roles, the
  system will tend to break down.

29
Creating CRC Cards and the Class Diagram

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• Transfer from the CRC cards the responsibilities
  as operations, and the attributes as attributes,
  and draw the relationships as generalization,
  aggregation, or association
• Add the visibility of the attributes and
  operations
• Examine the model for additional opportunities
  to use aggregation or generalization relationships

30
Creating CRC Cards and the Class Diagram

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• Review the class diagram for missing and/or
  unnecessary classes, attributes, operations, and
  relationships
• Some analysts normalize the class diagram

31
Creating CRC Cards and the Class Diagram

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• See if a pattern applies

32
Creating CRC Cards and the Class Diagram

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

• A walk-through a formal presentation to another
  group of analysts to go over the CRC cards and
  the Class Diagram

33
Creating CRC Cards and the Class Diagram

• Object Identification
• Create CRC Cards
• Examine Common Object Lists
• Role-Play the CRC Cards
• Create the Class Diagram
• Review the Class Diagram
• Incorporate Patterns
• Review the Model

In each of these steps be sure to record new
information on the CRC cards as it is discovered.
This may require creating new CRC cards and
modifying the Class Diagram.
34
Sources

• K. Beck and W. Cunningham, A Laboratory for
  Teaching Object-Oriented Thinking, Proceedings
  of OOPSLA, SIGPLAN Notices 24, no. 10 (1989)
• Kent Beck, Ward Cunningham, together with Ron
  Jeffries, created Extreme Programming XP
• C. Larman, Applying UML and Patterns An
  Introduction to Object-Oriented Analysis and
  Design (Englewood Cliffs, NJ Prentice Hall,
  1998)
• Craig Larmans book, a classic, introduces domain
  modeling, iterative design, and the use of
  patterns to solve architectural problems
• R. Wirfs-Brock, B. Wilkerson, and L. Wiener,
  Designing Object-Oriented Software (Englewood
  Cliffs, NJ Prentice Hall, 1990)
• This is the book that put CRC cards on the map