Overview Of Object Oriented Analysis And Design

Published Date: 02 Nov 2017

Introduction

In this lecture we describe the object-oriented analysis and design approach. The lecture presents the methodology and technique of using object-oriented principles in the requirements analysis and design phases of the life cycle of software system development.

Learning Outcomes

Be familiar with Object-Oriented Analysis and Design.

14.0 Introduction

We live in a world of objects. Therefore, an object-oriented is popular methodology for creation of software systems. Object-Oriented Analysis and Design (OOAD) means that object-oriented techniques be used during the analysis, design, and implementation of the system. Using this methodology requires the identification of the objects of the system, their behavior over time and/or in response to events, and the relationships between these objects and how they interact.

14.1 Overview of Object-Oriented Analysis & Design

An object-oriented approach to the development of software systems was proposed in late 1960s. Object-Oriented Analysis and Design (OOAD) is a method widely used in software engineering that represents a system as a collection of objects that interact with one another. Each object embodies a part of the system that is being modeled. Each object has a class and behavior characteristics associated with it.

14.1.1 Object-Oriented Analysis (OOA)

Object-Oriented Analysis (OOA) studies the problem scope and domain. The objectives of OOA are to produce a theoretical/abstract representation of the information in the system. Analysis models do not take into account any execution issues and constraints that might exist, such as parallelism, distribution, performance, or how the system will be ‘put together’. Implementation issues and constraints are dealt with during object-oriented design (OOD) phase.

OOA makes use of a requirements specification, the objectives of the system, information gathering from stakeholders through interviews, surveys, workshops, etc. as the sources for the analysis and produces an illustration of the system’s functionality, in the form of a ‘conceptual model’. The purpose of object oriented analysis (OOA) is to aid in the creation of a system that fulfills the agreed customer/user requirements. The resulting conceptual model of OOA will typically be illustrated using use-cases, UML class diagrams, and interaction diagrams.

Object Oriented Analysis starts by identifying candidate objects. Similar to structured analysis, object-oriented analysis benefits from the use of event analysis for system decomposition. It also requires conceptual, or semantic, modeling of the application domain. In both approaches it is important to maintain a clear distinction between essential and implementation models (logical and physical models) as well as to separate the analysis models, which specify requirements, from the design models, which define a software solution. Hence, OOA produces a conceptual model of the system. OOA applies object-modeling methods to analyze and evaluate the requirements that are needed to make the system work.

The goal of the analysis phase using object oriented methodology can be accomplished by the following three-steps:

Identify classes and objects that model and describe the system in an abstact form

Determine the purpose, and main responsibilities, of each class/class in the system. The responsibilities of a class have two parts: what an instance of the class must be able to do (methods/functions) and what it must know (data).

Determine the helper classes for each class. To help complete its responsibilities

Developing object models during requirements analysis leads to the next step which is object-oriented design and programming.

In object-oriented requirements analysis, the system analyst should model real-world entities of the system using object classes. He/she not include details of the individual objects (instantiations of the class) in the system. System analyst should specify and show how object classes are related to each other, how objects are aggregated to form other objects, how objects interact with other objects, etc.

Identifying objects and object classes in OOA is considered as one of the most difficult steps in object-oriented development phase.  Other approaches proposed to object identification include:

The use of a natural language to analyze and describe a system. Nouns as used to represent the objects and attributes; verbs are used to describe and represent the operations or services.

The use of tangible entities (things) in the application domain such as aircraft, roles such as manager, events such as request, interactions such as meetings, locations such as offices, organizational units such as companies and so on. The system analyst needs to define storage structures (abstract data structures) in the solution domain that might be required to support these objects.

The use of a behavioral approach to describe the system. The system analyst first understands the overall behavior of the system. The various behaviors are assigned to different parts of the system and an understanding is derived of who initiates and participates in these behaviors.

The use of a scenario-based analysis where several scenarios of system use are identified and analyzed. The system analyst must identify the required objects, attributes and operations in each scenario.

In practice, system analyst normally uses a mixture of all of the above approaches to identify the objects in a system under development.

14.1.2 Object-Oriented Design (OOD)

Object-oriented design (OOD) methodology solves the design problem in the context of a real-world problem.

Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis (OOA) and produces the physical model of the system taking into consideration the constraints imposed by the chosen architecture and any non-functional, technological or environmental constraints.

OOD maps the concepts in the analysis model onto implementation classes and interfaces, which as a result, produces a thorough depiction of how the system is built.

In the OOD phase, the software system model which was developed during requirements analysis becomes the top level of the architecture. This architecture is then refined, through considering how the model will be implemented. The architecture is developed through Object–Interaction Diagrams, Object–Class Diagrams, Object–Hierarchy Diagram, State charts, and Property Specification Forms and Tables. Design is about producing a solution that meets the requirements that have been specified during analysis. OOD uses the analysis models (developed during OOA) to produce implementation specifications.

Main focus of the analysis phase of software system development is on what needs to be done. During this phase system Objects are discovered . These objects serve as the framework for design phase. Class attributes, methods, and associations are identified during analysis must be designed as a data type expressed in the implementation language and then implemented using appropriate object oriented languages.

The difference between OOA and OOD is that OOA focuses on what the system does, while OOD focuses on how the system does it.

OOD identifies the objects in a system, understands the structural and behavioral modularity and properties of each object, and recognizes objects which are members of a common class and so share modularity, behavior, and properties, in a single consistent abstract model. During OOA, a logical model of the system is built which identifies what are the required objects, classes, functions, behavior, and properties of the problem. Then, OOD determines how the logical model is refined into an architecture for software components with a smooth transition to code. The model is developed and viewed through graphic and textual representations which provide ready communication.

OOD formally defines the properties of objects, describing the system as an object. The system is then refined into its component objects. Classes are methodically identified by generating them from objects in the system.

Preliminary design performs the same essential activities in analysis and detailed design builds an unusually consistent model which closely follows the real world. This model can then be tested, modified and reused.

The results that are gained from object-oriented analysis are used as the starting point or input for the object-oriented design. The output of object-oriented analysis does not need to be completely defined in order for it to be used for object-oriented design. Object-oriented analysis and design may be carried out at the same time, and the results of one task can be used by the other in a feedback cycle through an iterative process.

By integrating object–oriented requirements analysis with object–oriented design, the Object–Oriented Software Development Method (OOSD) focuses on the objects of the intended system.

OOSD requirements analysis represents system requirements and leads to its design, creating a single consistent system architecture, which is easy to maintain, and closely follows the real world.

OO design process is shown in Figure 1.

Continue testing

Design classes, methods, attributes, & associations

Refine UML class diagrams

Apply design axioms

Design view /access layers & prototype

User satisfaction & usability tests based on use-cases

Figure 1: Object-oriented design

Some typical input for object-oriented design may include the following:

Conceptual model: A conceptual model identifies ideas and perceptions and is produced as part of object-oriented analysis.

Use-cases: Use-cases illustrate how the system and the user interact with one another (also called a "scenario"), which as a result, produces an output (system doing something). The users are identified as ‘Actors’ which interact in some way with the system.

System Sequence Diagram: A System Sequence Diagrams (SSD) portrays the outcome of the interactions between the external user (actor) and the system.

User Interface Documents: User interface documents show the ‘look and feel’ of the end product’s user interface. It gives the end user a chance to familiarize themselves with the interface. This is however not a compulsory feature.

Relational Data Model: A data model is a theoretical model that explains how data is shown and used.

Some typical outputs of object-oriented may include the following:

Sequence Diagrams: A sequence diagram is a collection of lines that represent the processes/objects (shown as parallel vertical lines) and the data (shown as horizontal arrows) flow between them.

Class Diagrams: A class diagram is a UML diagram that illustrates how the system is structured in terms of its classes, attributes and how the various classes interact. These classes and attributes can then be used as input for an overall class diagram for the entire system.

14.2 Object-Oriented Design & Analysis Concepts

The basic concepts of object-oriented design are transferred into and represented in the programming language that is used. They are represented using the following names:

Object/class: An object has data that has been summarized and ‘put in a nutshell’ to fully represent an entity. A class is more concerned with the data in the object as it illustrates the linkages between the data and the methods manipulating the data. The creation of an object is based on the class that is related to it. Each object has a certain defined function that it carried out and has its own properties that distinguish it from rest of the objects. Objects have responsibilities, as if they were simple agents.. Each object is responsible for specific actions, this will make its class definition very clear and simple as well as it will increase the modularity and autonomy of this object.

Information hiding: Information hiding is the ability to conceal some parts of the object from other, external objects. This is achieved by the ‘settings’ of the object that are decided by the programmer. A ‘private’ or ‘protected’ access modifiers in object indicate the presence of information hiding.

Inheritance: Inheritance involves a ‘superclass’ and a ‘subclass’ where the subclass inherits the features and functionality of the superclass.

Interface: An interface defines a group of fields and behaviors that do not have an execution flow. This can be seen as a prototype or a contract for other classes, whereas each class that implements (signs) this contract (the interface) will be enforced to implement those prototypes.

Polymorphism: The ability to replace an object with other objects, called ‘subobjects’ and retain the objects full functionality.

Design concepts in Object-Oriented Design and Analysis include:

Defining objects, creating class diagram from conceptual diagram through mapping entity to class.

Identifying attributes of the objects

Use design patterns when possible. A design pattern is a nearly-finished design that illustrates a solution to a problem that has a high frequency rate. The advantage of using a design pattern lies in the fact that it can be used for more than one system/application as in most cases, the same problems occur in various systems.

Define application framework when possible. An application framework can be thought of as a ‘library’ that contains a set of classes that are used frequently for multiple applications. This saves programmers a lot of time and effort as they do not need to constantly re-write the same sections of code for several applications due to the code being in the ‘library’.

Requirements analysis precedes design. It focuses on understanding what the customer wants. The difference between traditional or structured analysis and object oriented analysis is that the result of OO analysis is a representation of the classes of a system domain without defining the system functions.

Summary

In this lecture we describe the object-oriented analysis and design approach. The lecture presents the methodology and technique of using object-oriented principles in the requirements analysis and design phases of the life cycle of software system development.

Exercises

What is UML? What type of modeling is it used for?

What is the difference between a use case description and an activity diagram?

What is a system sequence diagram?

What are the steps required to develop a system sequence diagram?