CS616 – Software Engineering II

Lecture 2

Object-Oriented Design

Four layers of the OO design pyramid:

1. Subsystem layer contains a representation of each of the subsystems that:
1. enable the software to achieve its customer-defined requirements
2. implement the technical infrastructure that supports customer requirements.
2. Class and object layer contains:
1. class hierarchies that enable system to be created using generalizations
2. representations of each object.
3. Message layer :
1. contains the design details that enable each object to communicate with its collaborators
2. establishes the external and internal interfaces for the system.
4. Responsibilities layer contains the data structure and algorithmic design for all attributes and operations for each object.

· Hidden Underlying Layer -> Foundation layer:

o Focuses on the design of domain objects (called design patterns).

o Domain objects provide support for human/computer interface activities, task management, and data management.

o Domain objects can be used to flesh out the design of the application itself.

Conventional vs. OO Approaches

· Conventional approaches: apply a distinct notation and set of heuristics to map the analysis model into a design model.

· Each element of the conventional analysis model maps into one or more layers of the design model.

· OOD applies:

o data design when attributes are represented

o interface design when a messaging model is developed

o component-level (procedural) design for the design of operations.

· Architecture of an OO design has more to do with the collaborations among objects than with the flow of control between components of the system.

· Relationship between the OO analysis model and design model:

· Subsystem design is derived by:

o considering overall customer requirements (represented with use-cases)

o events and states that are externally observable (the object-behavior model)

· Class and object design :

o mapped from the description of attributes, operations, and collaborations contained in the CRC model.

· Message design driven by:

o the object-relationship model

o responsibilities design is derived using the attributes, operations, and collaborations described in the CRC model.

Design Issues

Five criteria for judging a design method's ability to achieve modularity:

• 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 (modules), 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 modules.
• Protection—an architectural characteristic that will reduce the propagation of side effects if an error does occur in a given module.

Five basic design principles that can be derived for modular architectures:

(1) linguistic modular units

· programming language used should be capable of supporting the modularity defined directly

(2) few interfaces

· to achieve low coupling - the number of interfaces between modules should be minimized

(3) small interfaces (weak coupling)

· to achieve low coupling - the amount of information that moves across an interface should be minimized

(4) explicit interfaces

· components should communicate in an obvious and direct way

(5) information hiding

· all information about a component is hidden from outside access

The OOD Landscape

Most important early OOD methods:

• The Booch method.
• encompasses both "micro development process" and "macro development process."
• design context
• macro development encompasses:
• architectural planning activity that:
• clusters similar objects in separate architectural partitions
• layers objects by level of abstraction
• identifies relevant scenarios
• creates a design prototype
• validates the design prototype by applying it to usage scenarios.
• micro development:
• defines a set of "rules" that govern:
• the use of operations and attributes and the domain-specific policies for memory management
• error handling and other infrastructure functions
• develops scenarios that describe the semantics of the rules and policies
• creates a prototype for each policy
• instruments and refines the prototype
• reviews each policy so that it "broadcasts its architectural vision"
• The Rumbaugh method.
• encompasses a design activity that encourages design to be conducted at two different levels of abstraction:
• System design -
• focuses on the layout of components that are needed to construct a complete product or system
• analysis model is partitioned into subsystems -> allocated to processors and tasks.
• strategy for implementing data management is defined
• global resources and the control mechanisms required to access them are identified
• Object design –
• emphasizes the detailed layout of an individual object.
• operations are selected from the analysis model and algorithms are defined for each operation.
• data structures appropriate to attributes and algorithms are represented.
• classes and class attributes are designed so they optimize data access and improve computational efficiency.
• a messaging model is created to implement the object relationships (associations).

• The Jacobson method.
• design model emphasizes traceability to the OOSE analysis model

1. idealized analysis model is adapted to fit the real world environment.

2. primary design objects, called blocks are created and categorized as interface blocks, entity blocks, and control blocks

3. communication between blocks during execution is defined

4. blocks are organized into subsystems.

• The Coad and Yourdon method.
• design approach addresses not only the application but also the infrastructure for the application
• focuses on the representation of four major system components:

1. problem domain component

2. human interaction component

3. task management component

4. data management component.

To perform object-oriented design, a software engineer should perform the following generic steps:

1. Describe each subsystem and allocate it to processors and tasks.
2. Choose a design strategy for implementing data management, interface support, and task management.
3. Design an appropriate control mechanism for the system.
4. Perform object design by creating a procedural representation for each operation and data structures for class attributes.
5. Perform message design using collaborations between objects and object relationships.
6. Create the messaging model.
7. Review the design model and iterate as required.

Note: design steps are iterative.

Unified Approach to OOD

Unified Modeling Language (UML)

§ During analysis modeling the user model and structural model views are represented

o provide insight into the usage scenarios for the system (providing guidance for behavioral modeling

o establish a foundation for the implementation and environment model views by identifying and describing the static structural elements of the system.

§ UML is organized into two major design activities:

o system design:

§ Primary objective of UML system design is to represent the software architecture

· conceptual architecture is concerned with the structure of the static class model and the connections between components of the model

· module architecture describes the way the system is divided into subsystems or modules and how they communicate by exporting and importing data

· code architecture defines how the program code is organized into files and directories and grouped into libraries.

· execution architecture focuses on the dynamic aspects of the system and the communication between components as tasks and operations execute.

o object design

o UML object design focuses on a description of objects and their interactions with one another.

o detailed specification of attribute data structures and a procedural design of all operations are created.

o visibility for all class attributes is defined and interfaces between objects are elaborated to define the details of a complete messaging model

§ System and object design are extended to consider:

o design of user interfaces

§ user model view drives the user interface design process

§ provides a scenario that is elaborated iteratively to become a set of interface classes

o data management with the system to be built

§ establishes a set of classes and collaborations that allow the system (product) to manage persistent data (e.g., files and databases)

o task management for the subsystems that have been specified.

§ establishes the infrastructure that organizes subsystems into tasks and then manages task concurrency.

§ Process flow for OOD

The System Design Process

§ System design develops the architectural detail required to build a system or product.

§ System design encompasses the following activities:

1. Partition the analysis model into subsystems.

2. Identify concurrency that is dictated by the problem.

3. Allocate subsystems to processors and tasks.

4. Develop a design for the user interface.

5. Choose a basic strategy for implementing data management.

6. Identify global resources and the control mechanisms required to access them.

7. Design an appropriate control mechanism for the system, including task management.

8. Consider how boundary conditions should be handled.

9. Review and consider trade-offs.

1. Partition the Analysis Model

§ Partition the analysis model to define cohesive collections of classes, relationships, and behavior -> subsytems

§ These design elements are packaged as a subsystem.

§ all of the elements of a subsystem share some property in common

§ all may be involved in accomplishing the same function

§ they may reside within the same product hardware, or they may manage the same class of resources

§ Subsystems are characterized by their responsibilities -> identified by the services that they provide

§ a service is a collection of operations that perform a specific function (e.g., managing word-processor files, producing a three-dimensional rendering, translating an analog video signal into a compressed digital image)

§ Subsystems should conform to the following design criteria:

§ Subsystem should have a well-defined interface through which all communication with the rest of the system occurs.

§ classes within a subsystem should collaborate only with other classes within the subsystem.

§ The number of subsystems should be kept low.

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

§ When two subsystems communicate with one another, they can establish a client/server link or a peer-to-peer link

§ client/server link –

1. each subsystem takes on one of the roles implied by client and server.

2. service flows from server to client in only one direction.

§ peer-to-peer link –

3. services may flow in either direction.

§ layering occurs when a system is partitioned into subsystems.

§ each layer of an OO system contains one or more subsystems and represents a different level of abstraction of the functionality required to accomplish system functions.

§ levels of abstraction are determined by the degree to which the processing associated with a subsystem is visible to an end-user.

§ e.g. four-layer architecture might might include

(1) presentation layer (the subsystems associated with the user interface)

(2) application layer (the subsystems that perform the processing associated with the application)

(3) data formatting layer (the subsystems that prepare the data for processing)

(4) database layer (the subsystems associated with data management).

§ Each layer moves deeper into the system, representing increasingly more environment-specific processing.

1. Design approach for layering:

1. Establish layering criteria. That is, decide how subsystems will be grouped in a layered architecture.

2. Determine the number of layers. Too many introduce unnecessary complexity; too few may harm functional independence.

3. Name the layers and allocate subsystems (with their encapsulated classes) to a layer. Be certain that communication between subsystems (classes) on one layer and other subsystems (classes) at another layer follow the design philosophy for the architecture

4. Design interfaces for each layer.

5. Refine the subsystems to establish the class structure for each layer.

6. Define the messaging model for communication between layers.

7. Review the layer design to ensure that coupling between layers is minimized (a client/server protocol can help accomplish this).

8. Iterate to refine the layered design.

2 Concurrency and Subsystem Allocation

· Dynamic aspect of the object-behavior model provides an indication of concurrency among classes (or subsystems)

· If classes (or subsystems) are not active at the same time:

§ no need for concurrent processing

§ classes (or subsystems) can be implemented on the same processor hardware.

· If classes (or subsystems) must act on events asynchronously and at the same time, they are viewed as concurrent.

· When subsystems are concurrent, two allocation options exist:

1. allocate each subsystem to an independent processor

2. allocate the subsystems to the same processor and provide concurrency support through operating system features.

· Concurrent tasks are defined by examining the state diagram for each object

§ If the flow of events and transitions indicates that only a single object is active at any one time a thread of control has been established.

§ The thread of control continues even when one object sends a message to another object, as long as the first object waits for a response.

§ If the first object continues processing after sending a message, the thread of control splits.

§ Tasks in an OO system are designed by isolating threads of control

§ e.g. while the SafeHome security system is monitoring its sensors, it can also be dialing the central monitoring station for verification of connection.

· Since the objects involved in both of these behaviors are active at the same time, each represents a separate thread of control and each can be defined as a separate task.

· If the monitoring and dialing activities occur sequentially, a single task could be implemented.

1. To determine which of the processor allocation options is appropriate, the designer must consider performance requirements, costs, and the overhead imposed by interprocessor communication.

3 The Task Management Component

· Strategy for the design of the objects that manage concurrent tasks:

o The characteristics of the task are determined

§ by understanding how the task is initiated

§ Event-driven and clock-driven tasks are most common

§ Both activated by an interrupts

o A coordinator task and associated objects are defined.

o The coordinator and other tasks are integrated.

· Priority and criticality of the task must also be determined.

o High-priority tasks must have immediate access to system resources.

o High-criticality tasks must continue to operate even if resource availability is reduced or the system is operating in a degraded state.

· Once the characteristics of the task have been determined, object attributes and operations required to achieve coordination and communication with other tasks are defined.

The basic task template (for a task object) takes the form

Task name—the name of the object

Description—a narrative describing the purpose of the object

Priority—task priority (e.g., low, medium, high)

Services—a list of operations that are responsibilities of the object

Coordinates by—the manner in which object behavior is invoked

Communicates via—input and output data values relevant to the task

4 The User Interface Component