CS 8532: Advanced Software Engineering Dr. Hisham Haddad Overview of Object-Oriented Design...

CS 8532: Advanced Software EngineeringDr. Hisham Haddad

Overview of Object-Oriented Design

Highlights of OOD Concepts,Components, and Process


SD vs. OOD - 1

Design Patterns (domain Objects)

ResponsibilitiesDesign

Subsystem Design

Class/Object Design

MessageDesign

interfacedesign

architecturaldesign

datadesign

Component design


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 system.

- 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

OO AnalysisOO DesignImplementationOO TestingDeployment

ObjectRelationship

Modeling

ClassModeling

ObjectBehaviorModeling

OO AnalysisOO DesignImplementationOO TestingDeployment

Class Design

Sub-SystemDesign

MessageDesign



Mapping OOA and OOD

Design Patterns(domain Objects)


Subsystem Design

Class/Object Design

MessageDesign

UseCases

Object Behavior

Model

Class Model

Object Relatio-nships

AttributesOperations

Collaborators


OOA and OOD Terminology

Another mapping view:

Classes

Attributes

Methods

Relationships

Behavior

Analysis Model

Objects

Data Structures

Algorithms

Messaging

Control

Design Model


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, etc…)

- 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 system))


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 forms(diagrams), notations, and terminologies. However, they allproduce 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 structures)

5. Perform message design (collaboration among objects)

6. Create message model (behavior modeling)

7. Review the design and refine as needed (iterative process)


Unified Approach to OOD


Subsystem Design

Class/Object Design

MessageDesign

OOD Process

Object Design

System Design


System Design ProcessActivities of system design process:

Step 1. Partition the analysis model into subsystems.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 data 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 trade-offs.


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 use-cases) - 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 use-cases)

Note: Layering design of subsystems may be required (e.g., GUI layer, computing subsystems(s) layer, data management layer).



UML Class Diagram:

During OOA, create conceptual class diagrams - focus on classes that are apparent in the problem statement

and of interest to the customer. - don’t 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 developer) - add more details into individual classes (attributes and

operations) - identify subsystems and use package notation.



Class diagrams: - used to document classes and show static structure of

classes/subsystems. - don’t 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 operations). - 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), input/output).

- 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 (actors)

- 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 hierarchy.

- 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 design3 - 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 protocol.

PDL is used to express object description (protocol and implementation).

Messages may be organized in categories (e.g., for SafeHome system: configuration, event, monitoring).


Step 2: Algorithm DesignEach operations of the class is expressed as an algorithm and is

implemented as a self-contained module.

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 (designer’s 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

Table of Contents1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations2. References3. Decomposition description 3.1 Module decomposition 3.1.1 Module 1 description 3.1.2 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.2.1 Data entry 1 description 3.2.2 data entry 2 description

4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 details 6.1.2 Module 2 details6.2 Module detailed design 6.2.1 Data entry 1 details 6.2.2 Data entry 2 details


RUP Major Sections of OO SDDOther sections and subsections may be added as needed.

Table of Contents1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References2. Glossary3. Use Cases4. Design Overview 4.1 Introduction 4.2 System Architecture 4.3 System Interfaces 4.4 Constraints and Assumptions5. System Object Model (System Design) 5.1 Introduction 5.2 Subsystems 5.3 Subsystem Interfaces

6. Object Descriptions (Object Design) 6.1 Objects in Subsystem 1 6.2 Objects in Subsystem 2 . . . . 6.n Sequence Diagrams

7. Object collaboration (Process View) 7.1 Objects in Subsystem 1 7.2 Objects in Subsystem 28. Data design9. Dynamic Model 9.1 State Diagrams 9.1.1 State Diagram 1 9.1.2 State Diagram 210. Non-functional requirements11. Supplementary Documentation


Useful Links

RUP Templates (complete set):http://jdbv.sourceforge.net/RUP.html

Software Architecture document sample:http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/SDP/

Architecture_guidelines.htm

Software Architecture template sample: http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/documents/ArchitectureDesignTemplate_Word.dot

Useful Links:http://atlas-connect-forum.web.cern.ch/Atlas-connect-forum/

documents_page.htm

SDD example:http://auss.abez.ca/SDD.html


End of Overview

CS 8532: Advanced Software Engineering Dr. Hisham Haddad Overview of Object-Oriented Design...

Documents

Transcript of CS 8532: Advanced Software Engineering Dr. Hisham Haddad Overview of Object-Oriented Design...