Object-oriented analysis and design

Object-oriented analysis and design (OOAD) is an approach to analyzing and designing a computer-based system by applying an object-oriented mindset and using visual modeling throughout the software development process. It consists of object-oriented analysis (OOA) and object-oriented design (OOD) – each producing a model of the system via object-oriented modeling (OOM). Proponents contend that the models should be continuously refined and evolved, in an iterative process, driven by key factors like risk and business value.

OOAD is a method of analysis and design that leverages object-oriented principals of decomposition and of notations for depicting logical, physical, state-based and dynamic models of a system. As part of the software development life cycle OOAD pertains to two early stages: often called requirement analysis and design.

Although OOAD could be employed in a waterfall methodology where the life cycle stages as sequential with rigid boundaries between them, OOAD often involves more iterative approaches. Iterative methodologies were devised to add flexibility to the development process. Instead of working on each life cycle stage at a time, with an iterative approach, work can progress on analysis, design and coding at the same time. And unlike a waterfall mentality that a change to an earlier life cycle stage is a failure, an iterative approach admits that such changes are normal in the course of a knowledge-intensive process – that things like analysis can't really be completely understood without understanding design issues, that coding issues can affect design, that testing can yield information about how the code or even the design should be modified, etc. Although it is possible to do object-oriented development in a waterfall methodology, most OOAD follows an iterative approach.

The object-oriented paradigm emphasizes modularity and re-usability. The goal of an object-oriented approach is to satisfy the "open–closed principle". A module is open if it supports extension, or if the module provides standardized ways to add new behaviors or describe new states. In the object-oriented paradigm this is often accomplished by creating a new subclass of an existing class. A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another. In the object-oriented paradigm this is accomplished by defining methods that invoke services on objects. Methods can be either public or private, i.e., certain behaviors that are unique to the object are not exposed to other objects. This reduces a source of many common errors in computer programming.

Common models used in OOA are the use case and the object model. A use case describes a scenario for standard domain functions that the system must accomplish. An object model describes the names, class relations, operations, and properties of the main objects. User-interface mockups or prototypes can also be created to help understanding.

Unlike with OOA that organizes requirements around objects that integrate processes and data, with other analysis methods, processes and data are considered separately. For example, data may be modeled by entity–relationship diagrams, and behaviors by flowcharts or structure charts.

Outputs of OOA are inputs to OOD. In an iterative approach, and an output artifact does not need to be completely developed to serve as input to OOD. Both OOA and OOD can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot. OOA artifacts include:

OOD, a form of software design, is the process of planning a system of interacting objects to solve a software problem. A designer applies implementation constraints to the conceptual model produced in OOA. Such constraints could include the hardware and software platforms, the performance requirements, persistent storage and transaction, usability of the system, and limitations imposed by budgets and time. Concepts in the analysis model which is technology independent, are mapped onto implementing classes and interfaces resulting in a model of the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.