object oriented design n.
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented Design PowerPoint Presentation
Download Presentation
Object-Oriented Design

Loading in 2 Seconds...

play fullscreen
1 / 31

Object-Oriented Design - PowerPoint PPT Presentation

  • Uploaded on

Object-Oriented Design. CIS 375 Bruce R. Maxim UM-Dearborn. OOA and OOD. OO Design Layers. Responsibility layer (highest layer) contains data structure detail and algorithmic detail for each object's attributes and operations Message layer defines system interfaces (internal and external)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Object-Oriented Design' - kahlilia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
object oriented design

Object-Oriented Design

CIS 375

Bruce R. Maxim


oo design layers
OO Design Layers
  • Responsibility layer (highest layer)
    • contains data structure detail and algorithmic detail for each object's attributes and operations
  • Message layer
    • defines system interfaces (internal and external)
    • includes the collaborator communication details
  • Class and object layer
    • class hierarchy including object representations
  • Subsystem layer (lowest level)
    • contains representations of each subsystem and needed infrastructure to achieve customer's requirements
ood issues 1
OOD Issues - 1
  • Decomposability
    • part of design method that allows the designer to decompose the problem into subproblems
  • Composability
    • design method ensures that modules built for one project can reused in other projects
  • Understandability
    • component can be understood without having to examine other components
ood issues 2
OOD Issues - 2
  • Continuity
    • possible to isolate changes made in one module and restrict their propagation to other modules
  • Protection
    • architectural characteristic that reduces the propagation of side effects when errors occur
ood generic steps 1
OOD Generic Steps - 1
  • Describe each subsystem and allocate its functions to processors and tasks
  • Choose a design strategy for implementing
    • data management
    • interface support
    • task management
  • Design an appropriate system control mechanism
ood generic steps 2
OOD Generic Steps - 2
  • Perform object design by creating a procedural representation for each method and data structures for each attribute
  • Perform message design based on the collaborations between objects and object-relationships
  • Create a messaging model
  • Review the design model and iterate as required
alternate generic ood
Alternate Generic OOD
  • Identify the data abstraction for each sub-system.
  • Identify attributes for each data abstraction.
  • Identify operations for each data abstraction.
  • Identify communication between objects.
  • Apply inheritance where appropriate.
ood booch abbot 1
OOD (Booch-Abbot) - 1
  • Define problem.
  • Develop process narrative for software realization of problem domain.
  • Formalize strategy.
    • Identify object & attributes.
    • Identify operations which can be applied to objects.
    • Establish interfaces by showing relationships between objects and operations.
    • Resolve design details to allow implementation.
ood booch abbot 2
OOD (Booch-Abbot) - 2
  • Recursively apply (2) & (3).
  • Refine work done during OOA
  • Represent data structures associated with object attributes.
  • Represent procedural detail for each operation (method).
component level design guidelines 1
Component Level Design Guidelines - 1
  • Components
    • Establish naming conventions in during architectural modeling
    • Architectural component names should have meaning to stakeholders
    • Infrastructure component names should reflect implementation specific meanings
    • Use of stereotypes may help identify the nature of components
component level design guidelines 2
Component Level Design Guidelines - 2
  • Interfaces
    • Use lollipop representation rather than formal UML box and arrow notation
    • For consistency interfaces should flow from the left-hand side of the component box
    • Show only the interfaces relevant to the component under construction
component level design guidelines 3
Component Level Design Guidelines - 3
  • Dependencies
    • For improved readability model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes)
    • Component interdependencies should be represented by interfaces rather that component to component dependencies
oo component design principles 1
OO Component Design Principles - 1
  • Open-Closed Principle (OCP)
    • class should be open for extension but closed for modification
  • Liskov Substitution Principle (LSP)
    • subclasses should be substitutable for their base classes
  • Dependency Inversion Principle (DIP)
    • depend on abstractions, do not depend on concretions
oo component design principles 2
OO Component Design Principles - 2
  • Interface Segregation Principle (ISP)
    • many client specific interfaces are better than one general purpose interface
  • Release Reuse Equivalency Principle (REP)
    • the granule of reuse is the granule of release
  • Common Closure Principle (CCP)
    • classes that change together belong together
  • Common Reuse Principle (CRP)
    • Classes that can’t be used together should not be grouped together
object oriented component design
Object-Oriented Component Design
  • Focuses on the elaboration of domain specific analysis classes and the definition of infrastructure classes
  • Detailed description of class attributes, operations, and interfaces is required prior to beginning construction activities
oo component design
OO Component Design
  • Undertake object oriented system requirements specification.
  • Identify objects and their services.
  • Establish interactions between objects
    • services required & rendered
  • Identify reusable components from previous designs.
  • Implementation of low level objects.
  • Introduce inheritance relationships
    • superclass & subclass
  • Class combination and generalization.
unified modeling approach to ood
Unified Modeling Approach to OOD
  • System design
    • UML (unified modeling language) design activity that focuses on software architecture and definition of subsystems
  • Object design
    • UML design activity that focuses on describing object and their interactions at a level of detail that will allow them to be implemented in some programming language
oo system design 1
OO System Design - 1
  • Partition the analysis model into subsystems
    • subsystems should have well defined communication interfaces
    • with few exceptions classes should collaborate within their subsystem
    • keep number of subsystems small
    • partition subsystem internally to reduce complexity
  • Identify concurrency dictated by the problem
  • Allocate subsystems to processors and tasks
    • allocate each subsystem to an independent processor


    • allocate subsystems to same processor and provide concurrency support through operating system features
oo system design 2
OO System Design - 2
  • Develop user interface design
  • Choose basic strategy for implementing data management
    • management of data critical to the application itself
    • creation of infrastructure for storage and retrieval of objects
  • Identify global resources and control mechanisms to access them
  • Design control mechanism for system (including task management)
oo system design 3
OO System Design - 3
  • Consider how subsystem boundary conditions should be handled
    • list each request (contract) that can be made by subsystem collaborators
    • for each contract and note the operations required to implement the responsibilities implied by the contract
    • for each contract create a table with these entries: type, collaborators, class, operation, message format
    • if subsystem interaction modes are complex create a subsystem-collaboration diagram
  • Review and consider trade-offs
object design process 1
Object Design Process - 1
  • Object descriptions
    • protocol description
      • object interface specified by defining each message an object can receive and the operation triggered by message (or)
    • implementation description
      • shows implementation details for each operation implied a message passed to the object
  • Designing algorithms and data structures
    • algorithm categories: data manipulation, computation, monitors
    • refinement of operations defined during OOA
object design process 2
Object Design Process - 2
  • Design optimization
    • review object-relationship model to ensure design leads to efficient resource utilization
    • add redundancy where necessary
    • revise attribute data structures and related operations to improve processing efficiency
    • create attributes to save derived information and avoid recomputation
  • Modularity is important aspect of object-oriented design quality (the PDL should support object definition)
modular design principles
Modular Design Principles
  • Linguistic modular units.
    • (ADT’s should be supported)
  • Few interfaces.
  • Small interfaces (weak coupling).
  • Explicit interfaces
    • (use parameters – not common coupling).
  • Information hiding.
object specification
Attribute description:

Attribute name.

Attribute content.

Attribute data (type/structure).

External input to object.

External output from object.

Instance connections:

(0:1, 1:1, 0:many, 1:many)

Operation description:

Operation name.

Operation interface description.

Operation processing description.

Performance issues.

Restriction and limitations.

Message connections.

Object Specification
common ood errors
Common OOD Errors
  • Classes that make direct modifications to other classes.
  • Classes with too much responsibility.
  • Classes with no responsibility.
  • Classes with unused responsibility .
  • Misleading class names.
  • Classes with unconnected responsibility.
  • Inappropriate inheritance.
  • Classes with repeated functionality.
design pattern specification
Design Pattern Specification
  • Name
  • Intent
  • Design forces motivating the pattern
  • Solution that mitigates these design forces
  • Classes required to implement the solution
  • Responsibilities and collaborations among the solution classes
  • Implementation suggestions
  • Source code examples or templates
  • Cross-references to related design patterns
design patterns in ood
Design Patterns in OOD
  • Inheritance
    • makes use of an existing design pattern to create a template for a new subclass
  • Composition
    • assembling complex objects or subsystems out of selected design patterns using only interface information