Object Oriented Analysis and Design in Software Engineering

Using object-oriented programming, object-oriented analysis and design (OOAD) is a technical way for evaluating and organising an application, system, or business. It also uses visual modelling to direct stakeholder interaction and product quality throughout the software development process.

OOAD is often carried out iteratively and incrementally in contemporary software engineering. Analysis models and design models, correspondingly, are the results of OOAD operations for OOA and OOD. With the help of important considerations like risks and business value, these are intended to be continuously improved upon and developed.


Before the mid-1990s, there were a variety of competing techniques for object-oriented modelling and software development. Many of them were linked to particular Computer Aided Software Engineering (CASE) tool manufacturers. The main issues at the time were the lack of standardised notations, uniform terminology, and process guidelines, which reduced communication effectiveness and prolonged learning curves.

Grady Booch, James Rumbaugh, Ivar Jacobson (the Three Amigos), Robert Martin, Peter Coad, Sally Shlaer, Stephen Mellor, and Rebecca Wirfs-Brock were just a few of the object-oriented masterminds who served as the inspiration for some of the well-known early methods.

The Unified Modeling Language was created in 1994 by the Three Amigos of Rational Software (UML). The Rational Unified Process (RUP), a thorough iterative and incremental process guide and framework for learning the best practises of the software development and project management industries, was later developed after they successfully led a mission to combine their own methodologies, OMT, OOSE, and Booch, with various insights and experiences from other industry leaders. Philippe Kruchten and Walker Royce joined them in this endeavour (the eldest son of Winston Royce). Since then, it's likely that the Unified Process family has become the strategy and reference model that people use the most frequently for object-oriented analysis and design.

The phases of the software life cycle are typically created to move from conceptual descriptions of the problem to designs, then to coding and testing, and finally to deployment. This process' initial phases are analysis and design. The phrase "requirements acquisition" is another name for the analysis phase.

The borders between each step are intended to be fairly tight and sequential in some methods of software development, which are collectively referred to as waterfall models. The term "waterfall" was developed for these methodologies to indicate that progress only occurred sequentially in one direction, i.e., once analysis was finished, only then did design begin. When a coding issue required a change in design or when a design issue required a change in analysis model, it was uncommon (and viewed as a source of error).

Iterative models are an alternative to waterfall models. In a highly significant publication on his Spiral Model for iterative software development, Barry Boehm made this distinction widely known. It is feasible to work on several model stages concurrently with iterative models. So, for instance, working on analysis, design, and even coding all on the same day is feasible and is not viewed as a cause of error. This allows for concerns from one stage to influence issues from another.Iterative models place a strong emphasis on the fact that software development is a knowledge-intensive process and that, among other things, analysis cannot be fully understood without understanding design issues, coding problems can have an impact on design, testing can provide information about how the code or even the design should be changed, etc.

While object-oriented development can be carried out using a waterfall paradigm, in reality most object-oriented systems are created utilising an iterative process. As a result, "analysis and design" are frequently taken into account at the same time in object-oriented procedures.

The object-oriented paradigm places a strong emphasis on modularity and reuse. The "open-closed principle" is what an object-oriented strategy aims to achieve. If a module supports extensions or offers standardised ways to add new behaviours or describe new states, it is said to be open. This is frequently done in the object-oriented paradigm by adding a new subclass to an already existing class.The term "closed module" refers to a module with a clearly defined, reliable interface that all other modules must use, limiting the amount of interaction and potential issues that can be introduced into one module by changes in another. This is performed in the object-oriented paradigm by defining methods that call services on objects. Methods can be either public or private, meaning that only other objects with the same object-specific behaviour are allowed to use them. This eliminates a major contributor to many typical programming problems.

The steps of the software life cycle are often broken down into abstract explanations of the problem, designs, code, testing, and deployment. This method' initial phases are analysis and design. The phrase "what vs. how" is frequently used to explain the difference between analysis and design. To describe what the system is expected to do, developers collaborate with users and subject-matter experts throughout analysis. Depending on the specific method, implementation details are intended to be primarily (if not entirely) disregarded at this stage.Making a working model of the system is the aim of the analysis phase, despite limitations like the right technology. This is often done in object-oriented analysis using use cases and abstract definitions of the most crucial objects. The analysis model is improved throughout the succeeding design process, which also determines the required technology and other implementation factors. The focus of object-oriented design is on describing the different objects, as well as their data, behaviour, and interactions. All the information needed for programmers to implement the design in code should be included in the design model.

Object-Oriented Analysis

Any analytic activity in the software life cycle has the goal of modelling the functional needs of the system without regard to implementation limitations.

The fundamental distinction between object-oriented analysis and other types of analysis is that with the object-oriented method, requirements are organised around objects, which combine states (data) and actions (processes) modelled after actual items the system interacts with in the real world. The two components, processes and data, are taken into account individually in other or traditional analysis approaches.For instance, ER diagrams can be used to represent data, and flow charts or structure diagrams can be used to model behaviours.

Use cases and object models are typical OOA models. Use cases outline the situations for typical domain tasks that the system must carry out. The names, class relationships (e.g., Circle is a subclass of Shape), operations, and properties of the primary objects are all described in object models. Prototypes of the user interface can also be made to aid comprehension.

Object-Oriented Design

A developer adds implementation restrictions to the conceptual model created by object-oriented analysis during object-oriented design (OOD). The platforms used by the hardware and software, the performance standards, the needs for permanent storage and transactions, the system's usability, and time and money limits are only a few examples of such restrictions. Concepts from the technology-neutral analytical model are translated onto implementing classes and interfaces to create a model of the solution domain, or a thorough description of how the system will be implemented using specific technologies.

Object-Oriented Modelling

Modelling applications, systems, and business domains using the object-oriented paradigm across the course of the whole development life cycle is known as object-oriented modelling (OOM). In contemporary software engineering, OOM is a key approach that is heavily utilised by both OOD and OOA activities.

The main two components of object-oriented modelling are the modelling of static structures, such as the classes and the components, and the modelling of dynamic behaviours, such as the business processes and the use cases. The two distinct abstract levels during OOM are OOA and OOD, or the analysis level and the design level, respectively. The two most well-known worldwide standard languages used for object-oriented modelling are the Unified Modelling Language (UML) and SysML.

Advantages of OOM

Effective and efficient communication

In-depth papers and programming language codes are often difficult for users to comprehend. Users and stakeholders can provide feedback to developers on the proper requirements and system structure using visual model diagrams, which can also make them easier to grasp. The "semantic gap" between the system and the outside world must be closed, and the system must be built using vocabulary that is nearly identical to that used by stakeholders in normal business operations. This is one of the primary objectives of the object-oriented approach. The key tool for facilitating this is object-oriented modelling.

Useful and stable abstraction

Coding is aided by modelling. The majority of modern software methodologies aim to provide "what" answers before providing "how" answers, i.e., first determine the functionality the system will provide without taking implementation constraints into account, then consider how to make specific solutions to these abstract requirements, and refine them into detailed designs and codes by limitations like technology and budget.This is made possible by object-oriented modelling, which generates abstract and understandable descriptions of both system requirements and designs. Models that define a system's fundamental structures and behaviours, such as processes and objects, are significant and valuable development assets with higher abstraction levels than concrete and difficult source code.

Advantages of Object-Oriented Analysis (OOA)

The first technical task which should be carried out as part of object-oriented software engineering is Object-Oriented Analysis (OOA). OOA uses the fresh ideas to solve this kind of a situation. It is founded on a few fundamental ideas, including the following:

  • Models exist for the information domain.
  • The behaviour is depicted.
  • The role is explained.
  • To reveal more information, functional, behavioural, and data models are separated.
  • While later models offer implementation details, earlier models capture the core of the issue.
  • The OOA technique is built on the tenets mentioned above.

Advantages of Object-Oriented Design (OOD)

OOD mainly focuses on converting an analysis model produced by the object-oriented analysis into a design model which will serve as a blueprint for software development. The key system components are divided into subsystems (a system-level "modular") as a result of OOD, and data manipulation processes are contained within objects. This results in a design with many layers of modularity (a modular form that is the building block of an OO system.). Additionally, OOD is required to provide a procedural explanation of each operation as well as some data organisation of attribute data. It has the four layers listed below.

  1. The Subsystem Layer: It is a representation of the supporting subsystem that enables software to construct technical frameworks that satisfy user requirements and fulfil user requirements.
  2. The Layer of Classes and Objects: The class hierarchies that allow the system to evolve through specialisation and generalisation are represented by this. Each object is also represented by this layer.
  3. Layer of the message: It is an illustration of the design elements that allow each thing to interact with its partners. It creates the system's internal and external interfaces.
  4. The Layer of Responsibilities: It displays the algorithmic design and data structure for each object's properties and operations.

The object-oriented design pyramid places a strong emphasis on particular system or product design. However, we should note that the pyramid's base is made by another design layer. It mainly focuses on the core layer, the design of the domain object, which is very important in creating the framework for an object-oriented system by supporting tasks related to the task management and human-computer interaction.

Terms Used in Object-Oriented Concepts

  1. Attributes: A group of data values that characterise a class.
  2. Class: Contains the information and logical constructs necessary to describe the nature and behaviour of some real-world entity. To put it another way, a class is a generic description of a group of related things.
  3. Objects: Examples of a particular class. The properties and methods of a class are inherited by objects.
  4. Operations: Also known as methods and services, offer a representation of certain class behaviour.
  5. Subclass: A hyperclass that has been specialised. Both attributes and methods can be inherited by a subclass from a super class.
  6. Superclass: A generalisation of a group of classes that are related to it is known as a base class.