ObjectOriented Design

1
Object-Oriented Design

• COSC 2P90

2
Object-Oriented Design

• Object-oriented isnt just a programming style
• Its a way of thinking
• Knowing how to create a class is one thing
• Need to know which objects to create
• Purpose
• Roles
• Need to know how those objects can interact
• Driven by the problem you are trying to solve
• Would you build a house without blueprints?
• Modelling allows for high-level abstraction
• Allows for dealing with complexity
• No single model is sufficient, a set of models
  from different views is necessary to understand
  architecture

3
Object-Oriented Design

• Goals of a design
• decomposition into classes
• definition of functionality
• Early-on Booch methodology
• Software development methodology that involves an
  iterative design that results in state diagrams
• The state diagrams
• identify classes
• identify functionality
• identify relationships
• Booch methodology was integrated into the Unified
  Modelling Language

4
Responsibility-Driven Design

• Wirfs-Brock and Wilkerson c.1990
• A shift from thinking from data algorithms to a
  design driven by specification and delegation of
  responsibilities
• Responsibilities delegated to classes
• class responsible for its operations
• Characterize desired behaviour
• of system
• of components
• Can deal with incomplete or ambiguous
  specifications
• Integrates with existing software development

5
Analysis

• Identify desired behaviour of the system
• What is supposed to happen, not how it is
  supposed to do it
• Try to characterize the application by behaviour.
  
• First the behaviour of the whole system
• Refined each subsystem into behaviour
  descriptions
• Behaviours are translated into code
• Use cases
• Discovery of the intended behaviours of the
  system through the analysis of typical or
  expected usages
• Shows the major functionalities of the system
• Uses a set of related scenarios
• Actors
• Something outside the system that can interact
  with the system
• Example credit-card validation system
• actors customer, store, bank
• use cases
• perform card transaction (customer, store)
• manage account (customer, bank)

6
Design

• The design is the process of identifying
  components that make up the system
• Classes, Functions, Module, etc...
• Components are an abstract entity to which we can
  associate responsibility
• Associate behaviour with components
• Responsibilities
• Cohesion
• Coupling
• Identify relationships between components
• Association (uses)
• Aggregation (has a)
• Inheritance (is a)

7
Assignment of Responsibilities

• Start with walk through use-case scenarios
• Identify the activities within the system
• These activities become responsibilities
• CRC cards
• Technique for brainstorming the components of a
  system
• Typically index cards are used, and from the
  use-case scenarios the following are identified
• Component
• Name of the component in the system
• Responsibility
• What the component is responsible for
• Collaborator
• What other components this one must interact with
  to accomplish its responsibilities
• Who/what cycle
• As we identify what needs to be done, we identify
  who needs to do it

8
Example The Interactive Kitchen Helper

• Suppose you are asked to create software for a
  revolutionary new device that will replace the
  recipe box
• Its purpose is to manage individual recipes, and
  then help in the planning of meals using those
  recipes.
• Your first step is to walk through a variety of
  use-case scenarios (pretend the system exists)
• The user enters a new recipe
• The user edits an existing recipe
• The user views upcoming meals
• The user creates new meal plans
• Etc

9
Example The Interactive Kitchen Helper

• Engineers sit down and create CRC cards for the
  components that are required to create the system
• Components should be created so
• They have a minimal set of responsibilities
• They have a minimal set of collaborations
• The engineers come up with a bunch of components,
  including
• Greeter the interaction with the user
• Recipe
• Recipe database
• Meal
• Date
• more

10
Example The Interactive Kitchen Helper

• Greeter component - offers user 5 choices
• 1. Browse the database of existing recipes,
  without reference to any particular meal plan
• 2. Add a new recipe to the database
• 3. Edit or annotate an existing recipe
• 4. Review an existing plan for several meals
• 5. Create a new plan of meals

Greeter Collaborators Display informative
initial message Database Manager Offer user
choice of options Plan Manager Pass control to
either Recipe Database Manager Plan Manager for
processing
11
Recognizing Relationships Between Components

• Association
• uses
• CRC collaborators
• 1-way or 2-way use
• Components are at a same structural level
• Example Greeter component and database manager
• Aggregation
• has a
• one class contains or manages objects of another
  class
• Example A house component has wall components
• Inheritance
• is a
• every object of one class conforms to another
  with additional properties

12
Coupling and Cohesion

• A measurement to determine the quality of
  software (from a design viewpoint)
• Cohesion
• how closely related are the responsibilities of a
  unit?
• i.e. Are the components focused in what they do?
• Coupling
• How dependent are units on each other?
• This is measurable by the number of associations
• When designing, aim for highly cohesive, loosely
  coupled systems
• Achieving one tends to achieve the other
• Advantages
• Easier maintainability
• Easier development
• Easier testing

13
Information Hiding

• Implementation hidden behind simple interface
• Interface what
• Implementation how
• Parnass principles
• all required information and no more
• user for use of a component
• developer to carry out responsibilities of a
  component