Monday, October 13, 2014


         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 . . .
     data structure details for objects
PACKAGE BODY program-component-name IS
     PROC operation.1 (interface description) IS
    PROC operation.n (interface description) IS
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
        PACKAGE BODY system IS
           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
      PACKAGE BODY system IS
           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.status: OUT);
         PROC set (alarm.characteristics, hardware.interface: IN)
         PROC test (, 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.status: OUT);
    raw.signal IS BIT STRING
    IF(hardware.interface.type="s"&alarm.characteristics.signal.type = "B“)
        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";
   ELSE {processing for other types of s interfaces would be specified}
  RETURN, sensor.status;
END read

No comments: