Introduction

Our world consists of objects. These objects exist everywhere, in nature, in human’s artificial world, in our work place and in the products that we use. These objects can be created, destroyed, categorized, organized and manipulated. Perhaps, it is due to all pervasiveness of objects in our real world that an object-oriented view was proposed for the creation of computer software. This approach enables us to model our real world into the computer world in ways that helps us to understand and navigate it better than perhaps, other approaches.

Though this concept is very odd, an object-oriented approach to the development of software was first proposed in late 1960s. It took about twenty years to catch up and get popular with computer programmers. And in the decade of 1990, this approach gained new heights of popularity. Now more and more software product builders and a growing number of information systems and engineering professionals are resorting to this approach for programming.

An important question may arise in the reader’s mind that why is object–oriented approach being preferred over the classical approach. The answer lies in actually implementing this object-oriented concept and then the obvious advantages of object-oriented programming stand apart from that of the classical approach. The object-oriented systems are easier to adapt and to scale. This means that assembling reusable subsystems, instead of developing it from scratch can easily create larger systems.

In this chapter, we will analyze the various steps and methods associated with object-oriented analysis and design. We will discuss the various stages of object-oriented development. Then we will understand in detail, the intricacies of system and object design. After that we will study a brief overview of existing methodologies of object-oriented analysis and design.

The term object-oriented is generally used to denote a programming approach that uses a number of object-oriented programming languages (e.g. Ada95, C++, Java). But actually the object-oriented paradigm encompasses a complete view of software engineering process.

The object-oriented development process starts with a customer communication phase. In this phase the main emphasis is on developing the framework of object-oriented project plan. As the name of this stage suggests, this phase involves communicating with the customers (clients) and ascertaining the needs. These needs are molded into classes. It is in this phase that the problem domain is defined and the basic problem classes are identified.

Then follows the planning and risk analysis. These stages establish a foundation for the object-oriented project plan. These stages are very important as in these stages, the planning relating to object-oriented analysis and design is undertaken and the risk analysis is done to gauge the risk factors involved.

The actual technical work associated with object-oriented analysis and design follows the plan shown in shaded boxes. It is in this stage that the actual development of objects and its members is undertaken. The main stress, in object-oriented analysis and design is upon ‘reuse’. Instead of developing objects from scratch, they are looked up in the existing library of classes. The objects are also developed in such a way that promotes their reusability after completion of their development. First of all potential classes that define the needs of system are identified and these classes are called candidate classes. These classes are the framework or the raw material from which the whole system is developed.

Then the classes are looked up in library of existing object-oriented classes before they are built. If a class cannot be found in the library of existing classes, then through inheritance or polymorphism of object-oriented approach, classes are extracted. After that, the software engineer applies object-oriented analysis, object-oriented design, object-oriented programming and finally object-oriented testing to create the class and the objects derived from the class. These classes are put in the library so that they may be reused in future, whenever the need arises. This process is repeated until the system is completely developed.

The system design process develops the framework required to build a system or product. The system designed is an integral product of object-oriented analysis and design. It consists of designing the system or architecture of product.

The system design is comprised of following activities:

• To partition the analysis model into subsystems.
• To identify the concurrency and allocate subsystem to processors and tasks.
• To develop the design for user interface.
• To choose the strategy for implementation of data management.
• To identify the resources and development of control mechanism required to access the resources.
• To provide handles for inter subsystem communication

Now we shall discuss the design activities related to each of the steps mentioned above.

Partitioning the Analysis Model

In object-oriented system design, the analysis model is partitioned to define the binding collection of class behavior and relationship. These separate design elements are then assembled and packaged as a subsystem.

Subsystem has some properties such as; they are characterized by the responsibilities. Thus a subsystem can be identified by the services it provides. The service thus provided may be defined as a collection of operations (functions) that perform a specific function of objects.

Concurrency and Subsystem Allocation

The issue of concurrency depends upon whether classes are acting on events in a synchronous or asynchronous fashion. If classes do not become active at the same time, there is no requirement of concurrent processing. On the other hand, if classes act on events at the same time, asynchronously, then they are viewed as concurrent. In such situations, some adjustments have to be made to the design process. When the subsystems are concurrent, then two allocations can be made:

1.     Each subsystem may be allocated to an independent process.

2.     All the subsystems are allocated to the same processor and concurrency support is provided through operating systems features.

Through the examination of state diagram for each object; concurrent tasks are defined. If the flow of events and their transitions indicate non-concurrency, a thread of control has been established. Even after one object sends a message to another object, the thread of control continues. This happens as long as the first object waits for a response. If, on the contrary, the first object continues processing even after sending a message, in that case the thread of control splits.

The Task Management Component

A specific strategy must be followed for the design of the objects that manage concurrent tasks. First of all, the characteristics of the task are determined. Finally the coordinator and other tasks are integrated.

The high priority tasks must have an immediate access to system resources. The tasks that are highly critical should continue to operate even when the system has degraded to a lower state or availability of resources is reduced.

After the determination of characteristics of the tasks, object attributes and operations that are required to coordinate and communicate with other tasks are defined.

After determining the tasks of object and their characteristics, the object attributes and operations are defined. These are required to achieve coordination and to communicate with other tasks.

The User Interface Component

The user interface design process requires certain inputs such as the usage scenarios and a description of the roles that these play as they interact with the system. After this, a command hierarchy containing the major menu categories and all sub-functions are defined.

The design of GUI (Graphical User Interface) elements is not necessary, as a wide variety of user interface environment already exists. The GUI classes such as classes for windows, icons, mouse applications and other user interface features already exist in the library of existing classes. The system designer needs to only instantiate object having appropriate characteristics for the problem domain.

The Data Management Component

The data management is designed in a layered fashion. It is specifically required to isolate the low level requirements for manipulating data structures from the higher- level requirements for handling system attributes. It encompasses two areas of concern, i.e. the management of data that is critical to the application and the creation of infrastructure for the retrieval of objects.

The database management system is used as a common data stored for all subsystems. Thus it facilitates the data handling and the management of the databases. The attributes and operations required for the management of objects are also designed. After this, the relevant attributes and operations are simply appended to the objects in the problem domain.

The Resource Management Component

Different resources are available to an object-oriented system or product and generally subsystems when undergoing designing and development compete for these resources. Now these resources can be either abstractions or generalizations such as an object or as database or it can be external entity such as processor, communication or hard drive’s memory space. Regardless of the nature of the resource, a control mechanism for the management of resources has to be designed by the software engineer. A supervising object can be designed for the control of the resources that control and supervise the access to the resources.

Object Design

The object design is concerned with the actual designing of objects. The intricacies of the objects are analyzed and developed in this process.

This whole object-oriented analysis and design can be compared with the drawing of a cat. First of all the wire-frame of cat is drawn on a plain paper. This is analogous to the system design; as in the system design the basic framework of OOAD is developed. After that, various colors are filled in the body and various patterns of shading are applied inside the framework. This can be compared to object design as the actual implementation and the details are taken care of.

Benett and his colleagues discussed object design in the following words:

Object design is concerned with the detailed design of the objects and their instructions. 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 operation functions, and how objects are linked to other objects.

In this process, the attributes and operations are defined. For this purpose, data structures (for attributes) and algorithms (for operations) are designed.

Object Description

The description of an object for the design can take two of the following forms:

• A protocol description: It establishes the interface of an object by defining each message and developing it. The objects can receive these messages.
• An implementation description: It shows the implementation details for each message’s implication for each operation that passes on to an object. It also contains the information about the internal details of data structures describing the object’s attributes and the functional details that define and explains the operations.
• Though for the designing of the object, the implementation description has to be provided and the internal details of the object must be created; but for only the protocol, description is required, thus obviating the need of implementation description.

Designing Algorithms and Data Structures

An algorithm is developed for the implementation of each operation. The algorithm itself can be defined as a simple, computational or procedural sequence that can be implemented as a self-contained software module. But if the complexity of specifications of operations is high, then the operation may be modularized.

Data structures are designed simultaneously with the algorithms. The design of data structures largely affects the algorithmic design of corresponding operation. The reason is that the operations invariably manipulate the attributes of a class.

Entity-Relationship Model

The Entity-Relationship (ER) helps in implementing the real world by conceptualizing it in the form of entities, relationships (and attributes with each of them). This approach is the most common approach to information modeling..  ER diagrams are readily converted into a database implementation.  .  The ERD is especially useful for application in which data and relationships, that govern data, are complex. The ER model consists of the data, object and the relationship that connect data object to one another. A data object is a representation of any composite information that must be understood by software.  Attributes define the properties of data object and are used to name  instances of data object, describe the instance, make reference to another instance in another table and act as “key” to identify a data object.  For example, car ID. The relationships show how data objects are connected to each other.For e.e. a company hires employees.

The entity-relationship diagrams have been discussed in detail in the chapter “SEMANTIC AND ENTITY-RELATIONSHIP MODELING”.

Overview of Existing Methodologies

A wide variety of object oriented analysis and design methods were proposed and used during the 1980s and 1990s. These methods established the foundation for modern OOD notation, design heuristics, and models. A brief overview of the most important early OOD methods are: -

The Booch Method

The Booch method includes both a micro as well as macro development process. In the design context, macro development consists an architectural planning activity that clusters similar objects in partitions, layers objects by level of abstraction, identifies relevant scenarios, creates a design prototype, and validates the design prototype by applying it to usage scenario. Micro development defines a set of rules that govern the use of operations and attributes and the policies for memory management, error handling and other infrastructure functions. It develops scenarios that describe the semantics of the rules and policies; creates a prototype for each policy; instruments and refines the prototype; and reviews each policy.

The Rumbaugh Method

The Object modeling technique includes a design activity that encourages design to be conducted at two different levels of abstraction. System design focuses on the layout for the components that are needed to construct a complete product or system. The analysis model is partitioned into subsystems, which are then allocated to processors and tasks. A strategy for implementing data management is defined, global resources and the control mechanisms 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 that are appropriate for attributes and algorithms are represented. Classes and class attributes are designed in a manner that optimizes access to data and improves computational efficiency. A messaging model is created to implement the object relationship (associations)

The Jacobson Method

The design activity for OOSE (Object oriented software engineering) is a simplified version of the proprietary objectory method, developed by Jacobson. The design model emphasizes trace-ability to the OOSE analysis model. First, the idealized analysis model is adapted to fit the real world environment. Then primary design objects, called blocks, are created and categorized as interface blocks, entity blocks, and control blocks. Communication between blocks during execution is defined and the blocks are organized into subsystems.

The Coad and Yourdon Method

The Coad and Yourdon method for OOD was developed by studying how effective object-oriented designers do their design work. The design approach addresses not only the application but also the infrastructure for the application and focuses on the representation of four major systems components: the problem domain components, the human interaction component, the task management component and the data management component.

The Wirgs-Brock Method

Wirgs-Brock, Wilkerson and Weiner defines a continuum of technical tasks in which analysis leads seamlessly into design. Protocols for each class are constructed by refining contracts between objects. Each operation and protocol is designed at a level of detail that will guide implementation. Specifications for each class and each subsystem are developed in this approach.

Though the terminology and the process steps for each of the mentioned methods differ, the overall OOD processes are reasonably consistent. To perform object oriented design , a software engineer should perform the following generic steps:

1.     Describe each subsystem and allocate it to processors and subtasks.

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 each attribute.

5.     Perform message design using collaborations between objects and object relationships.

6.     Create the messaging model.

7.     Review the design models and iterate as required.