Software EngineeringSoftware Engineering

OO Design

ObjectivesObjectives

Describe the Object Oriented design process

Detail the UML models produced during OO design

The Challenge of OO DesignThe Challenge of OO Design

To create re-usable OO software a designer must: Find pertinent objects

Factor them into classes of the right granularity

Define class interfaces and inheritance hierarchies

The design should be specific to the problem at hand but general enough to address future problems and requirements.

Difficult to achieve the first time around

All design methods strive for abstraction, information hiding, functional independence and modularity but only OOD can achieve all four without complexity or compromise.

OO DesignOO Design

Object-relationship

model

Object-BehaviorModel

CRCIndex Cards

Attributes, operations,collaborators

THE ANALYSIS MODEL

responsibilitiesdesign

messagedesign

Class and objectdesign

subsystemdesign

THE DESIGN MODEL

Use cases

OOA and OODOOA and OOD

classesclassesattributesattributesmethodsmethodsrelationshipsrelationshipsbehaviorbehavior

Analysis ModelAnalysis Model

objectsobjectsdata structuresdata structuresalgorithmsalgorithmsmessagingmessagingcontrolcontrol

Design ModelDesign Model

Design CriteriaDesign Criteria

decomposability—the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve

composability—the degree to which a design method ensures that program components (classes), once designed and built, can be reused to create other systems

understandability—the ease with which a program component can be understood without reference to other information or other modules

continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few classes

protection—an architectural characteristic that will reduce the propagation of side affects if an error does occur in a given class

Generic Components for OODGeneric Components for OOD

Problem domain component—the subsystems that are responsible for implementing customer requirements directly

Human interaction component —the subsystems that implement the user interface (this included reusable GUI subsystems)

Task Management Component—the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems

Data management component—the subsystem that is responsible for the storage and retrieval of persistent data

OOD ProcessOOD Process

System Design Object Design

Human Interface Design

Data Management

Design

Task Management

Design

[1] System Design Process[1] System Design Process

Represent the conceptual software architecture. Activities:

a) Partition the analysis model into subsystems

b) Identify concurrency that is dictated by the problem and allocate subsystems to processors and tasks

c) User Interface: Develop a design for the user interface

d) Data Management: Choose a basic strategy for implementing data management. Identify global resources and the control mechanisms required to access them

e) Task Management: Design an appropriate control mechanism for the system, including task management

f) Intersubsystem Communication: Define the collaborations that exist between subsystems

g) Consider how boundary conditions should be handled

h) Review and consider trade-offs.

[A] Partitioning the Analysis Model[A] Partitioning the Analysis Model

Define subsystems (cohesive collections of classes, relationships and behaviour)

Design Criteria:1. The subsystem should have a well-defined interface through which

all communication with the rest of the system occurs.

2. With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within the subsystem.

3. The number of subsystems should be kept small.

4. A subsystem can be partitioned internally to help reduce complexity.

Use UML Package notation

[B] Concurrency Allocation[B] Concurrency Allocation

Concurrency is required if subsystems (or classes) must act on events simultaneously and asynchronously

Determine by examining State and Interaction Diagrams for thread of control

Choices: Allocate each subsystem to an independent processor

Allocate subsystems to the same processor and provide OS concurrency support (e.g. threads)

Example: SafeHome sensor monitoring and dialing of the central station are independent

Concurrency complicates a system; try to avoid if possible

[C] User Interface Component[C] User Interface Component

Use-cases serve as input to user interface design.

Process: iteratively specify the command hierarchy (windows, menu bars, tool palettes) until all use-case scenarios are satisfied

Many of the classes necessary to implement a GUI are available in Visual SDE’s

Details to appear in the Human-Computer Interaction course

[D] Data Management Component[D] Data Management Component

Areas of concern: management of application-critical data an infrastructure for storage and retrieval of objects

Database management system often used as a common data store for all subsystems

Objects should know how to store and retrieve themselves

Example: flat file for “sensors”. Each record corresponding to a named instance of sensor with particular values for all attributes. Sensor objects would contain store and retrieve methods.

[E] Task Management Component[E] Task Management Component

The characteristics of the task are determined. How is the task initiated (event or clock driven)?

What is its priority (high priority tasks must have immediate access to system resources)?

How critical is the task (highly critical tasks must continue to operate under adverse circumstances)?

A coordinator task and associated objects are defined

The coordinator and other tasks are integrated

[F] Intersubsystem Communication[F] Intersubsystem Communication

Specify contracts (interaction spec) for subsystems: List each request that can be made by collaborators of

the subsystem For each contract note the operations (both inherited

and private) that are required to implement the responsibilities implied by the contract

Considering one contract at a time, create a collaboration table (not UML)

If the modes of interaction between subsystems are complex use a subsystem interaction (collaboration) diagram

Subsystem Collaboration TableSubsystem Collaboration Table

client/server or peer to peer

other subsystems party to the contract

subsystem classes (+ relevant methods and formats) to support contract services

Subsystem Collaboration Subsystem Collaboration TypesTypes

requestclientsubsystem

contract

contract contract

request

request

serversubsystem

peersubsystem

peersubsystem

Example: Subsystem Collaboration Example: Subsystem Collaboration DiagramDiagram

Control Panel

Subsystem

Sensor Subsystem

Central Communication

Subsystem

Request for Status Assign Zone Test Status

Request for alarm notification Periodic check-in

Request for system status Periodic status check

UML OutputsUML Outputs

The system design process refines models produced during analysis.

Package diagrams (high-level class diagrams containing only package references) are popular for large complex systems

More detail is added to the conceptual class diagrams to create specification class diagrams

UML Specification Class DiagramsUML Specification Class Diagrams

Attributes: Syntax: visibility name : type = default-value visibility is + (public) # (protected) or – (private) name is a string type language-dependent specification default-value the initial value of the attribute Example: # numberPlate : string = “CA 101 010”

Operations (Methods): Syntax: visibility name ( parameter-list ) : return-type-expression visibility and name are the same as for attribute syntax parameter-list contains optional arguments with the same syntax as

attributes return-type-expression is an optional language-dependent specification Example: + latestAmountOf (PhenomenonType value) : Quantity

[2] Object Design[2] Object Design

Component level design of individual classes A protocol description establishes the interface of an object by

defining each message that the object can receive and the related operation that the object performs

An implementation description shows implementation details for each operation implied by a message that is passed to an object. Contains: information about the object's private part

internal details about the data structures that describe the object’s attributes

procedural details that describe operations

Output: header files in the target language and message descriptions (e.g. MESSAGE (motion.sensor) read: RETURNS sensor.ID, sensor.status)

[3] Design Patterns[3] Design Patterns

Identifying and building reusable patterns

“... you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.”

Design Pattern AttributesDesign Pattern Attributes

The design pattern name is an abstraction that conveys significant meaning about it applicability and intent.

The problem description indicates the environment and conditions that must exist to make the design pattern applicable.

The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate into a variety of problems.

The consequences associated with the use of a design pattern provide an indication of the ramifications of design decisions.