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.