Document Sample
Hello Powered By Docstoc
					    Chapter 5
Finding The Objects
         Building The OO Model
 Historically two distinct activities are
  taking place simultaneously
     problem analysis
     product description
 In actuality we are building a model of
  reality that captures both aspects
                 The Results
 A Model that
     Organizes the data into objects and
      classes, and gives the data a structure
      via relationships of inheritance,
      aggregation, and association
     Specifies local functional behaviors and
      defines their external interfaces
     Captures control or global behavior
     Captures constraints (limits and rules)
        An example of a model
The toy fire truck is a model of real world
entity. The toy has attributes that are either
constants ( height, width, color) or variable
(battery level). It also has services such as
(move forward, move backward, turn on
siren). In addition, it has exception
conditions such as broken wheel.

siren means alarm or bell
Categories Of Objects (Coad and Yourdon)
 Structure        : “kind-of” and “part-of”
 Other systems    : External systems
 Devices
 Events           : A historical event that
                     must be recorded.
 Roles             : The different role(s) the
                      user play
 Locations
 Organizational units: Groups to which the
                        user belongs
   What do we mean be role name ?
 A role name identifies one end of a
  relationship and provides a vehicle for
  viewing a relationship as a traversal from
  one object to a set of associated objects
    Categories of objects (Shlaer and Mellor)
   Tangibles       ( i.e. car, sensors)
   Roles           ( i.e. teacher, mother)
   Incidents       ( i.e. landing, collision)
   Interactions    ( i.e. meeting, marriage)
   Specification   ( i.e. product specification)
          Object Categories (Ross)
   People
   Places
   Things
   Organizations
   Concepts
   Events
          Identification Of Objects
Many methodologists have their own
 favorite approaches

All techniques have short comings
  fail to identify all objects
  identifies false objects

Current and traditional methods are covered
  1- Using The Things To Be Modeled
 Basic Steps Are:
     Identify individual or group things, such as
      persons, roles, organizations, logs, reports,
      forms, etc. in the application domain
     Identify the corresponding objects and classes
 Requires significant experience with OO to
  apply successfully
   2- Using Definitions of Objects and
 This is a direct and effective approach in
  which the developer
     uses object abstraction,
     knowledge of the domain,
     and the definition of class to intuitively identify
 Requires significant training, practice,
  intuition, and experience.
       3- Using Object Decomposition
 Assumes most objects are composed of
  other objects
 Basic approach is
     Find the aggregate objects or class
     Use object decomposition to identify their
      component objects or classes
            4- Using Generalization
 Assumes objects are identified prior to their
  classes, that every object is an instance of
  some class, and that commonalties among
  objects can be used to generalize classes.
 Steps are:
     Identify all objects
     Look for two or more objects that share the
      same attributes and services
     Generalize the common aspects to form a class
     To continue, use the method “Using
              5- Using Subclasses
 The steps are:
     Identify classes that share common resources
     Factor out the common resources to form a
      super class, and then use inheritance for all
      classes that share these resources to form
      simpler subclasses
        6- Using OO Domain Analysis
 This technique assumes that an OO Domain
  Analysis has already been performed in the
  same problem domain.
 The steps are:
     Analyze the results of the given OODA
     Reuse objects or classes from the OODA
 7- Reusing an Application Framework
 This approach assumes that at least one
  OODA has been done to create an
  application framework of reusable classes
 Steps are:
     Identify one or more relevant application
      frameworks in the same application domain
     Reuse both objects and classes from previously
      developed frameworks.
         8- Reusing Class Hierarchies
 This technique assumes that a reuse repository
  with relevant reusable class hierarchies has been
 Steps are:
     Look for classes in the reuse repository that can be
     After identifying the classes, attempt to reuse the
      associated class hierarchies
     After modifying the classes, attempt to create new
      abstract classes by grouping common attributes and
     If the classes are parameterized, supply the generic
      formal parameters
         What is repository ?
A storage place for models, interfaces, and
implementation, part of an environment for
manipulating development artifacts.
 9- Reusing Individual Objects and Classes
 If a reuse repository with relevant reusable
  objects and classes has been developed, we
  can reuse specific objects and classes.
 Steps are:
     Look for relevant objects and classes in the
      reuse repository that can be applied to the
     If necessary, modify the objects and/or classes
     Supply generic, formal parameters to
      parameterized classes as necessary.
      10- Using Subassemblies
Assumes developers are incrementally
developing subassemblies using a recursive
development process. This technique is
similar to function decomposition; instead
of a function, take an object and decompose
it into other objects ( subassemblies).
Continue the decomposition until there are
only terminal objects at the leaves of the
           10- Using Subassemblies
 The steps are:
     Identify all of the objects (classes) at the current
      level that must remain temporarily complex
      because they depend on one or more as yet
      unidentified objects and classes
     Develop a skeleton specification/design for the
      methods of the temporarily incomplete object.
     Create the appropriate child subassemblies at
      the next lower level to handle the messages for
      the incomplete object at the higher level
     Repeat all steps at the current level that has
      new subassemblies
       11- Using Personal Experience
 This assumes that the developer has
  already performed an analysis and can use
  that experience for this analysis
 Steps are:
     Find the objects and classes that correspond to
      ones found in previous models that are in the
      same application domain.
     Modify the classes as necessary to support the
      present project
Traditional Techniques
                    1- Using Nouns
 This assumes that written documents about the
  domain exist
 Steps are:
     Obtain or author a narrative English text that represents
      an informal description of the problem to be solved.
     Use the nouns, pronouns, and noun phrases to identify
      objects and classes
     Verbs and predicate phrases are used to identify
   2- Using Traditional Data Flow Diagrams
 This technique exploits existing DFD to identify objects
  and classes
 Steps are:
      Map each terminator on the Context Diagram to an object to
       encapsulate the interface
      Identify one class to encapsulate the interface of each set of
       similar or identical terminator objects
      Map each data store on the DFD to an object
      Map data stores that contain more than one data field to an
       aggregate object
      Map all or part of the data transformation associated with the data
       store to a service of the object and thus of the class
      Map complex data flows to an object
      Identify subtransformations associated with the parts of the data
       flow and map these subtransformations to services of the object.
3- Using Class-Responsibility-Collaboration (CRC)
 Based on the observations that identifying objects
  and classes is a human activity that can be
  stimulated by use of small pieces of paper to
  represent objects/classes.
 Steps are:
     One a CRC card, document the name of the class and
      list both the responsibilities and collaborators.
     Identify missing objects and/or classes that should be
      added to the existing set of CRC.
CRC Cards
• CRC Card = Class Responsibility Collaborator
CRC Cards

  •   Help explore objects
  •   Provide an ’easy' introduction
  •   Starting point of many methodologies
  •   Used in industry
  •   Widely used in teaching
        class name:
        responsibilities:         collaborators:


        class role/description:



 1. Read specification
 2. Work through requirements, highlighting
   nouns and noun phrases to give candidate
 3. Work through candidates, deciding likely
   classes and rejecting unlikely.

  • If you don't have one, WRITE your own.
  • The specification should:
    – describe the goals of the design
    – discuss the things the system should do
  • i.e. desired responses to expected
• convert plurals to singulars
• discard obvious nonsense classes (but keep all rest)
• remove synonyms (but keep BEST descriptor)
• beware adjectives (they can be irrelevant, but can
  mean a whole new class exists)
• beware hidden nouns e.g. passive voice "the thing
  is activated" = "SOMETHING activates the thing"

  • physical objects e.g. printer, switch
  • cohesive entities e.g. file, window
  • categories of classes (may become
    abstract superclasses)
  • interfaces both to user and to other
  • attribute values (NOT attributes) e.g.
    "circle has radius in real numbers" :
    circle and real are classes; radius is not.

  • The process of identifying classes is
    iterative - some will be missed, others
    will be amalgamated Likely classes:
    – any physical objects
    – any 'cohesive abstractions' e.g. a file
    – any interfaces to outside world
    – any categories of class e.g. "there are
      various types of whatsits"
    – values of attributes of objects

  • Warnings
    – adjectives
    – passive voice e.g. they travelled to the
  • Reject:
    – attributes
    – nouns that are really verbs e.g. the chance
      of throwing a six is 1/6
    – objects outside system

  • Responsibilities are concerned with:
    – the maintenance of knowledge
    – the actions the object can perform
  • Technique:
    1. Highlight verbs/phrases in requirements
    2. Do walkthroughs
    3. Spread intelligence
    4. Keep behaviour and knowledge close
What are Responsibilities?

  • They contain two key items:
    – the knowledge that the object maintains
    – the actions the object can perform
  • They say WHAT gets done, not HOW
    its done
Identifying Responsibilities
• Read requirements & highlight:
  – verbs
  – information (which some object must maintain)
• Check these are actions that a system object
  must perform
• Try a walkthrough
  – try anthropomorphism/personification
• Check all your classes are doing something
Assigning Responsibilities
• evenly distribute system intelligence
• state responsibilities as generally as possible
• keep behaviour with related information (if
• keep information about one thing in one place
• share responsibilities among related objects
Look at Relationships between Classes
Taking classes from within your system, see if
  there are examples of:
• is-kind-of
  – maybe superclass should have responsibility?
• is-analogous-to
  – if have similar responsibilities, perhaps should be
    common superclass with it?
• is-part-of
  – therefore clarify responsibilities between parts of an
    aggregate class

  • Missing classes
    – perhaps worth encapsulating unassigned
      responsibilities to a new class?
  • Uncertain Assignment of
    – i.e. maybe one responsibility could go to
      two different classes
    – solve by walkthrough?
• A collaboration is where one class (a client)
  needs another one (a server) in order to
  perform its own responsibilities.
• Each responsibility may have:
  – no collaborations
  – one collaboration
  – many collaborations
• Using CRC cards, work through ALL
  responsibilities identifying collaborators;.
• Therefore, for each responsibility ask:
  – can the class do it alone?
  – if not:
     • what knowledge does it need?
     • what processing does it need?
     • which classes have what it needs?

  • For each CRC card class ask:
    – what does it do or know?
    – what classes need this service or
    – are those classes collaborating with this
  • Confirm by looking at classes and
    ensure if a class does/knows
    something, it is being used
Examine Relationships (1):
• Collaboration is strongly indicated by:
  – has-knowledge-of e.g. a car needs to know the
    speed limit, which it gets from the sign on the side of
    the road or ...
  – depends-on (changes-with) e.g. pressing
    accelerator increases speed of wheels and decreases
    petrol level (but beware INDIRECT collaborations)
  – (composite) is-part-of e.g. to turn a car, the car will
    need to send messages to its steering wheel, wheels
Examine Relationships (2):
• Collaboration is not necessarily indicated by
  container (is-part-of ) aggregation
• For example an array holds a group of
  elements but doesn’t usually collaborate with
  them as it doesn’t need to know their values
  or use any of their methods.
CRC Terms versus UML Terms

  • CRC are similar to classes, but are
    treated like objects
  • attributes are the same in both CRC
    and UML
  • “responsibilities” are “operations”
  • Superclass and subclass describe
    inheritance relations
  • Collaborators are “associations”
                 CRC Cards
   Class - Responsibility - Collaboration cards
   not part of UML but should be used with UML to
    produce high quality systems
   Cunningham and Beck 1989
   good points:
         they help you to think in an object-oriented way

         they emphasise responsibilities

         they uncover generalisation and aggregation

         they don’t use complex notation
       Example of a CRC Card
        class name

                        Project Leader
add new software engineer to supervise     software engineer
remove software engineer                   software engineer
display software engineers’ names          software engineer

       responsibilities,                 collaborators, other
       services provided by              classes needed to
       the class                         work with
         Using CRC Cards

   set of index cards is created for each class identified
   one card created for a particular scenario
   cards shared around developers
   scenarios are acted out
   cards are modified where problems occur
   4” x 6” cards used so only high level responsibilities
CRC cards
• One common way of checking for a good
  design and guiding its refinement is to use
  CRC cards.
• CRC stands for Classes, Responsibilities,
• Although CRC is not part of UML, they add
  some very useful insights throughout a
 Creating CRC card
• The name of a class, at the top
• The responsibilities of the class, on the left-
  hand side
• The collaborators of the class, which help to
  carry out each responsibility, on the right-hand
  side of the card.

 The responsibilities of the class describe at a
 high level the purpose of the class’s existence :
  – They are connected with the operations the class
    provides, but are more general than that might imply
CRC card example
 Most novices find that a mixture of
  approaches helps
     using nouns to identify objects and classes
     using crc cards to promote discussion
     using the “using things to be modeled” to elicit
      more potential objects
We have a family of a father, Khaled, a
mother Khaledah, two sons, Ali, and Yousef,
and two daughters, Fatima and Asma.
Khaled is an actor and Khaledah is a dentist.
All the children are students and the family
dog is Lassie. Their family physician is
Alice. This family owns a house in the
suburbs of Irbid city and though mowing the
family lawn is normally a chore for the
father, it can also be a paid chore for any
one of the children. However, working within
the neighborhood is Jack, a professional
lawn mower
We have a family of a father, Khaled, a
mother Khaledah, two sons, Ali, and Yousef,
and two daughters, Fatima and Asma.
Khaled is an actor and Khaledah is a dentist.
All the children are students and the family
dog is Lassie. Their family physician is
Alice. This family owns a house in the
suburbs of Irbid and though mowing the
family lawn is normally a chore for the
father, it can also be a paid chore for any
one of the children. However, working within
the neighborhood is Jack, a professional
lawn mower
 Draw the class diagram of the previous
 Find all the services in the previous text?
 Find all the relationships in the previous
         How to break a system into
           smaller subsystems?
• Roman principle: Divide & conquer
  – Split up a large system into manageable parts
• In structured methods: functional decomposition
• In OO: Group classes into higher level units

                         (conceptual; at development time)

                        (physical; at run time)
 General purpose mechanism for organizing
  elements into groups
 Package forms a namespace
     Names are unique within ONE package
     UML assumes an anonymous root package

             Package vs. Component
 Packages
     Conceptual structuring of system model
     Source code structure
 Components
     “Physical and replaceable part of the system that
      conforms to and provides the realization of a set of
       • COM+ components, Java Beans, …
       • source code files
       • Documents

Shared By: