Overview of Object-Oriented Design - PowerPoint PPT Presentation

About This Presentation

Overview of Object-Oriented Design


Overview of Object-Oriented Design Highlights of OOD Concepts, Components, and Process – PowerPoint PPT presentation

Number of Views:81
Avg rating:3.0/5.0
Slides: 31
Provided by: Hish48


Transcript and Presenter's Notes

Title: Overview of Object-Oriented Design

  • Overview of Object-Oriented Design
  • Highlights of OOD Concepts,
  • Components, and Process

  • SD vs. OOD - 1

  • SD vs. OOD - 2
  • - With OO development, think objects (data and
    operations) rather than functional procedures
    (during analysis and design).
  • - OOD focuses more on the collaboration among
    objects than data flow between components of the
  • - OOD exhibits different levels of modularity
    (subsystem modules to method).
  • - With OOD, system architecture has more to do
    with object collaboration than with control flow
    (as in SD).
  • - OOD methods provide better support for
    essential design concepts - abstraction,
    modularity, functional independence, information
    hiding, and reuse.

  • OOA and OOD

  • Mapping OOA and OOD

  • OOA and OOD Terminology
  • Another mapping view

  • OOD Layers - 1
  • - Design Patterns Deals with reusable designs
    (domain objects).
  • (repeated (reusable) classes and objects that
    found to solve specific design problems, e.g.,
    user login and authentication, integrated
    circuit, car air-condition system, shopping cart,
  • - Subsystem Design Deals with subsystems that
    form the overall system architecture.
  • (detailed design of self-contained and
    highly-independent groups of classes that define
    specific requirements (major functions of the

  • OOD Layers - 2
  • - Class/Object Design Deals with relationships
    among classes that define each subsystem.
  • (detailed design of inheritance hierarchies
    for subsystems)
  • - Message Design Deals with internal and
    external interface design.
  • (detailed design of messages exchanged among
    objects and interactions between system objects
    and external entities)
  • - Responsibilities Design Deals with data
    structures and algorithm design.
  • (internal detailed design of each class - its
    attributes and operations)

  • OOD Methods
  • OOD methods vary in their processes, presentation
  • (diagrams), notations, and terminologies.
    However, they all
  • produce similar results.
  • A design method must support building modular
    architectures with fewer interfaces, small
    interfaces (less data passed around), and
    explicit interfaces (well-defined interfaces),
    and information hiding.
  • Examples - Booch method
  • - Rumbaugh method
  • - Jacobson method
  • - Coad/Yourdon method
  • - Wirfs/Brock method

  • Generic Steps of OOD
  • 1. Identify subsystems and allocate to
    processors and tasks
  • 2. Design data management, interface support,
    and task
  • management
  • 3. Design system control mechanism
  • 4. Perform object design (operations and data
  • 5. Perform message design (collaboration among
  • 6. Create message model (behavior modeling)
  • 7. Review the design and refine as needed
    (iterative process)

  • Unified Approach to OOD

  • System Design Process
  • Activities of system design process
  • Step 1. Partition the analysis model into
  • Step 2. Identify concurrency (dictated by the
    problem) and
  • allocate subsystems to processors
    and tasks.
  • Step 3. Design an appropriate control mechanism
    for task
  • management.
  • Step 4. Develop a design for the user interface.
  • Step 5. Choose a basic strategy for implementing
  • management.
  • Step 6. Identify global resources and the
    control mechanisms
  • required to access them.
  • Step 7. Consider how boundary conditions should
    be handled
  • (intersubsystem communications).
  • Step 8. Review the design and consider

  • Step 1 Partition the Analysis Model - 1
  • Identify potential subsystems (self-contained and
    highly independent groups of classes that define
    specific functions)
  • How?
  • A subsystem
  • - has a well-define interface (check
  • - has reasonable number of classes
  • - has classes that communicate with each
    others only (not
  • with outside classes) (check object
    behaviour diagram)
  • - may include internal subsystems (check
  • Note Layering design of subsystems may be
    required (e.g., GUI layer, computing
    subsystems(s) layer, data management layer).

  • Step 1 Partition the Analysis Model - 2
  • UML Class Diagram
  • During OOA, create conceptual class diagrams
  • - focus on classes that are apparent in the
    problem statement and of interest to the
  • - dont worry about classes needed to implement
    the system
  • During OOD, create specification class diagrams
  • - add classes and relationships needed for
    modeling the solution (classes of interest to the
  • - add more details into individual classes
    (attributes and operations)
  • - identify subsystems and use package notation.

  • Step 1 Partition the Analysis Model - 3
  • Class diagrams
  • - used to document classes and show static
    structure of classes/subsystems.
  • - dont show how classes interact (messages).
    Collaboration and sequence diagrams show that
    (dynamic view).
  • - describe association, generalization, and
    aggregation relationships among classes.
  • - show class details (attributes and
  • - show class interface.
  • - show individual object instances within the
    class structure.
  • - used throughout the development cycle.

  • Step 2 Identify Concurrency Tasks
  • Class (subsystems) that are active at the same
    time (act on the same events synchronously) are
    considered concurrent.
  • How?
  • - check object behavior diagram (state machine
    or activity diagram) for parallel threads of
    control (i.e., an object sends a message to
    another and continues processing)
  • - consider each control thread as a task
  • - allocate tasks to HW processors considering
    performance requirements (or same processor using
    OS mutli-threading capability)

  • Step 3 Task Management Objects
  • Task initiation and management are modeled by
    control objects.
  • How?
  • - determine task characteristics such as its
    initiation (event- or clock-driven), priority for
    resources, and criticality (should continue to
    operate with low resources).
  • - define control object (attributes/operations)
    required to coordinate the task with others.
  • (Task name, description, priority, services
    (object operations), coordinated by (invoked by),
  • - show task control object on the object
    collaboration (behavior) diagrams.

  • Step 4 User Interface Design
  • User interface is often modeled as a subsystem.
  • How?
  • - check use-cases to identify system users
  • - from use-cases, derive command hierarchy to
    define menu components for each actor and its
    usage scenario.
  • - Refine the command hierarchy until all
    uses-cases can be navigated via the command
  • - Note that most interface classes are reused
    from libraries or system environment.

  • Step 5 Data Management
  • Data management is accomplished by attributes and
    operations defined to manipulate, store, and
    retrieve data objects (from system database)
  • How?
  • - include such attributes and operations within
    classes that manipulate data objects.
  • - or, design special class(es) to host such
    attributes and operations (i.e., to save and load
    data objects as needed by the system).

  • Step 6 Resource Management
  • Subsystems may compete for resources (HW and data
    resources). Resource allocation control may be a
    required part of the design.
  • Often, resource management is performed by the OS
    and DBMS.
  • How?
  • - If resources are part of the application, the
    designer my define an object (guardian or
    gatekeeper object) for each resource to
    coordinate access to that resource.

  • Step 7 Intersubsystem Communications
  • Collaboration between subsystems is define by
    contracts or subsystem interfaces and is
    implemented by message(s) among the subsystems.
  • How?
  • - for each contract (interaction), define its
    type, collaborating subsystems(s), classes(s)
    within the subsystem(s), operation(s) within the
    class(es), and the message format.
  • - show collaborations (messages) on subsystem
    collaboration diagrams.

  • Object Design Process
  • Object design process is focused on providing
    detailed design of the objects (attributes and
    methods) and their messages.
  • Component-level design principles (Ch-11,
    textbook) are application to object design.
  • Activities of object design process
  • 1 - Object description (message design)
  • 2 - Algorithm design
  • 3 - Data structure design
  • Program Design Language (PDL) is used to express
    object design (PDLs come in different flavors).

  • Step 1 Object Description
  • Object description includes protocol (interface)
    description and implementation description.
  • Protocol description is a listing all message
    that the object can respond to (services it
    provides). This is important for clients (users)
    of the object.
  • Implementation description provides internal
    (hidden) details of operations that implement the
  • PDL is used to express object description
    (protocol and implementation).
  • Messages may be organized in categories (e.g.,
    for SafeHome system configuration, event,

  • Step 2 Algorithm Design
  • Each operations of the class is expressed as an
    algorithm and is implemented as a self-contained
  • A complex operation may be divided into separate
    operations, such that each operation performs a
    well-defined task.
  • Stepwise refinement may be applied
  • - define operation interfaces (list of
    parameters if any)
  • - fill-in operation body sections
  • - refine body details as needed
  • Key Points
  • The level of details should be sufficient
    enough so that it can be translated to target PL
    syntax without additional help from the designer
    (designers knowledge of the PL is essential!)

  • Step 3 Data Structure Design
  • Defining data structures is done in conjunctions
    with operation design since operation design may
    require knowledge of data structures that
    implement object attributes.
  • Optimization of objects design (algorithmic and
    data design) should be conducted to ensure
    efficient processing, ease of implementation, and
    efficient utilization of resources.

  • Software Design Documentation
  • For structured design, IEEE 1016-1993 standard
    (next slide) sections 1 through 5 describe the
    software architecture and section 6 describes
    detailed design.
  • For OOD, section 6 can be replaced with detailed
    description of classes (see the following 29)
  • RUP templates are more appropriate for capturing
    and expressing OOD details. Note section names
    and order may vary among documents.

  • IEEE 1016-1987 Standard for SDD

  • RUP Major Sections of OO SDD
  • Other sections and subsections may be added as

  • Useful Links
  • RUP Templates (complete set)
  • http//jdbv.sourceforge.net/RUP.html
  • Software Architecture document sample
  • http//atlas-connect-forum.web.cern.ch/Atlas-conne
  • Software Architecture template sample
  • http//atlas-connect-forum.web.cern.ch/Atlas-conne
  • ArchitectureDesignTemplate_Word.dot
  • Useful Links
  • http//atlas-connect-forum.web.cern.ch/Atlas-conne
  • SDD example
  • http//auss.abez.ca/SDD.html

  • End of Overview
Write a Comment
User Comments (0)
About PowerShow.com