OBJECT DESIGN PROCESS :-
•
The OO system design might be viewed as the floor plan of a
house.The floor plan specifies the purpose of each room and the architectural
features that connect the rooms to one another and to the outside environment.
•
It is now time to provide the details that are required to build
each room.In the context of OOD, object design focuses on the “rooms”.
•
Object design is concerned with the detailed design of the objects
and their interactions.It is completed within the overall architecture defined
during system design and according to agreed design guidelines and protocols.
Object design is particularly concerned with the specification of attribute
types, how operations function, and how objects are linked to other objects.
•
Local data structures are defined(for attributes) and
algorithms(for operations) are designed.
1) Object Descriptions :-
•
A design description of an object (an instance of a class or
subclass) can take one of two forms.
(1) a protocol description that establishes the interface of an object
by defining each message that the object can receive and the related operation
that the object performs when it receives the message.
(2) an implementation description that shows
implementation details for each operation implied by a message that is passed
to an object.
• Implementation details include
information about the object's private part; that is, internal details about
the data structures that describe the object’s attributes and procedural
details that describe operations.
• The protocol description is nothing more than a set of messages and a corresponding
comment for each message. For example protocol description for the object motion sensor might be
o MESSAGE (motion.sensor) --> read: RETURNS sensor.ID, sensor.status;
• This describes the message required to
read the sensor
o MESSAGE
(motion.sensor) --> set: SENDS sensor.ID, sensor.status;
• sets or resets the status of the
sensor.
• For a large system with many messages,
it is often possible to create message categories.
• For example, message categories for
the SafeHome system object might include system configuration
messages, monitoring messages, event messages, and so forth.
• An implementation description
of an object provides the internal ("hidden") details that are
required for implementation but are not necessary for invocation. That is the
designer of the object must provide an implementation description and must
therefore create the internal details of the object. However, another designer
or implementer who uses the object or other instances of the object requires
only the protocol description but not the implementation description.
• An implementation description is
composed of the following information:
• (1) a specification of the object's
name and reference to class;
• (2) a specification of private data
structure with indication of data items and types;
• (3) a procedural description of each
operation or, alternatively, pointers to such procedural descriptions. The
implementation description must contain sufficient information to prod ling of
all messages described in the protocol description.
• the difference between the information
contained in the protocol description and that contained in the implementation
description in terms of "users" and "suppliers" of
services.
• A user of the service provided
by an object must be familiar with the protocol for invoking the service; that
is, for specifying what is desired.
• The supplier of the service
(the object itself) must be concerned with how the service is to be supplied to
the user; that is, with implementation details.
2) Designing Algorithms and Data Structures :-
•
A variety of representations contained in the analysis model and
the system design provide a specification for all operations and attributes.
•
An algorithm is created to implement the specification for each
operation. In many cases, the algorithm is a simple computational or procedural
sequence that can be implemented as a self-contained software module. However,
if the specification of the operation is complex, it may be necessary to
modularize the operation. Conventional component-level design techniques can be
used to accomplish this.
•
Data structures are designed concurrently with algorithms. Since
operations invariably manipulate the attributes of a class, the design of the
data structures that best reflect the attributes will have a strong bearing on
the algorithmic design of the corresponding operations.
•
Although many different types of operations exist, they can
generally be divided into three broad categories:
•
(1) operations that manipulate data in some way (e.g., adding,
deleting, reformatting, selecting),
•
(2) operations that perform a computation, and
•
(3) operations that monitor an object for the occurrence of a
controlling event.
•
For example, the SafeHome processing description contains the
sentence fragments:
•
"sensor is assigned a number and type" and "a
master password is programmed for arming and disarming the system." These
two phrases indicate a number of things:
•
That an assign operation is relevant for the sensor
object.
•
That a program operation will be applied to the system
object.
•
That arm and disarm are operations that apply to system
status may ultimately be defined using data dictionary notation as system
status = [armed | disarmed].
•
The operation program is allocated during OOA, but during object
design it will be refined into a number of more specific operations that are
required to configure the system.
•
For example, after discussions with product engineering, the
designer might elaborate the original processing narrative and write the
following for program (potential operations—verbs—are underlined):
•
Program enables the SafeHome user to configure the system once it
has been installed. The user can
•
(1) install phone numbers;
•
(2) define delay times for alarms;
•
(3) build a sensor table that contains each sensor ID, its
type, and location;
•
(4) load a master password.
•
Therefore, the designer has refined the single operation program
and replaced it with the operations: install, define, build, and load
•
Each of these new operations becomes part of the system object,
has knowledge of the internal data structures that implement the object's
attributes, and is invoked by sending the object messages of the form.
•
MESSAGE (system) --> install: SENDS telephone.number;
•
This implies that, to provide the system with an emergency phone
number, an install message will be sent to system.
• Once the basic object model is
created, optimization should occur. three major power for OOD design
optimization:
• Review the object-relationship model
to ensure that the implemented design leads to efficient use of resources and
ease of implementation. Add redundancy where necessary.
• Revise attribute data structures and
corresponding operation algorithms to develop efficient processing.
• Create new attributes to save derived
information, thereby avoiding recomputation.
3) Program Components and Interfaces :-
•
An important aspect of software design quality is modularity; that
is, the specification of program components (modules) that are combined to form
a complete program.
•
But defining objects and operations is not enough. During design,
we must also identify the interfaces between objects and the overall
structure of the objects.
•
Although a program component is a design concept, it should be
represented in the context of the programming language used for implementation.
•
To hold OOD, the programming language to be used for
implementation should be capable of creating the following program component.
PACKAGE program-component-name IS
TYPE specification of data objects
•
PROC
specification of related operations . . .
PRIVATE
data structure details for objects
PACKAGE BODY program-component-name IS
PROC operation.1 (interface description) IS
•
END
PROC
operation.n (interface description) IS
•
•
END
END program-component-name
•
The first program component to be identified should be the
highest-level module from which all processing originates and all data
structures evolve.
•
For SafeHome ,we can define the highest-level program component as
•
PROCEDURE SafeHome software
•
The SafeHome software component can be coupled with a preliminary
design for the following packages (objects):
o PACKAGE system IS
TYPE system data
PROC install, define, build, load
PROC display, reset, query, modify, call
PRIVATE
PACKAGE BODY system IS
PRIVATE
system.id IS STRING LENGTH (8);
verification phone.number, telephone.number, ...
IS STRING LENGTH (8);
sensor.table DEFINED
sensor.type IS STRING LENGTH (2),
sensor.number, alarm.threshold IS NUMERIC;
PROC install RECEIVES (telephone.number)
{design detail for operation install}
•••
END system
o PACKAGE system IS
TYPE system data
PROC install, define, build, load
PROC display, reset, query, modify, call
PRIVATE
PACKAGE BODY system IS
PRIVATE
system.id IS STRING LENGTH (8);
verification phone.number, telephone.number, ...
IS STRING LENGTH (8);
sensor.table DEFINED
sensor.type IS STRING LENGTH (2),
sensor.number, alarm.threshold IS NUMERIC;
PROC
install RECEIVES (telephone.number)
{design detail for operation install}
•••
END system
•
Data objects and corresponding operations are specified for each
of the program components for SafeHome software.
•
The final step in the object design process completes all
information required to fully implement data structure and types contained in
PRIVATE portion of the package and all procedural detail contained in the
PACKAGE BODY.
•
the first step is to define the interfaces for each of the
operations attached to sensor:
•
PROC read (sensor.id, sensor.status: OUT);
•
PROC set (alarm.characteristics, hardware.interface: IN)
•
PROC test (sensor.id, sensor.status, alarm.characteristics: OUT);
•
The next step requires stepwise refinement of each operation
associated with the sensor package.
•
To demonstrate the refinement,we develop a processing description
(an easy strategy) for read:
o PROC read (sensor.id, sensor.status:
OUT);
raw.signal IS BIT STRING
IF(hardware.interface.type="s"&alarm.characteristics.signal.type
= "B“)
THEN
GET (sensor, exception: sensor.status := error) raw.signal;
CONVERT raw.signal TO internal.signal.level;
IF internal.signal.level > threshold
THEN sensor.status := "event";
ELSE sensor.status := "no event";
ENDIF
ELSE
{processing for other types of s interfaces would be specified}
ENDIF
RETURN
sensor.id, sensor.status;
END read
No comments:
Post a Comment