What is OOAD

To facilitate software development, the practice of object-oriented analysis and design (OOAD) has developed in tandem with object-oriented technology.

OOAD focuses on analyzing the requirements of a system and designing a model of the system before any code is developed.

OOAD is done to ensure that the purpose and requirements of a system are thoroughly captured and documented before the system is built.

Although it sounds obvious, it is very important that the proposed system will be useful to its intended users and will fulfill their requirements.

OOAD allows a detailed model of the system to be developed, based on the documentation of the users' requirements.

The model provides abstraction from the underlying complexity of the system and allows the system to be viewed as a whole.

It also provides a way for users, analysts, designers, and implementers to study different, but compatible, aspects of the system.

As OOAD takes place, different views of a system should be abstracted to form a model of the system as a whole.

Once this is done, it is easier for developers to see how the components of the system should interact and users can verify that their requirements are met.

Then detail can be added to transform the model into one that can be used for implementation.

Frequently during early analysis and design, different solutions to the problem are modeled and the results are compared to find the best system.

OOAD divides into two phases - object-oriented analysis (OOA) and object-oriented design (OOD).

OOA involves creating a model of a system based on what the users require from that system.

OOD adds detail and design decisions to the model.

The analysis phase takes a "black box" approach to the system, ignoring its inner workings.

The design phase takes a "white box" approach and makes decisions on how the model will be implemented in code.

So analysis takes place from a user's perspective and design takes place from a developer's perspective.

During analysis, a concise, accurate model of what the desired system should do is created.

This model should not consider how the system will perform its functions.

Analysis focuses on abstracting from the problem domain - that is, the real world that the system will function in.

This is done to discover the primary classes and objects in the system.

The objects in the analysis model should be problem domain concepts only - they should not be implementation concepts.

During analysis, the environment the system will be implemented in should not be considered.

However, at the design stage it must be ascertained whether the analysis model will work in the intended implementation environment.

During design, the analysis model is expanded into a technical blueprint for implementing a system.

New classes are added to provide the mechanisms that enable the system to work - for example, mechanisms to handle persistence or interprocess communication.

And the classes discovered during analysis are fleshed out to take account of the implementation environment.

In practice, many portions of the analysis model may be implemented without change, so there is often overlap between analysis and design.

Analysis is some times refined during design, or after key design decisions are made.

Quite often, analysis and design are parallel activities on a large project, so it is difficult to draw a line between where analysis ends and design starts.

At the end of the OOAD process, the analysis and design models combine to provide an overview of the system.

This overview can be used throughout the development process.

During the OOAD process, it is important to be aware of the goals of the software system being developed.

The main goal of a successful software system is that the user should be able to use it effectively.

Other goals of successful systems are that
• it should be easily maintainable

• it should be scalable

• it should be portable between platforms

• its code should be reusable

It is important for the success of a project that its result is delivered in time and within budget.

There are several tactics that facilitate the development of a successful software system that can be taken into account during analysis and design.

The system should be split into modules based on logical functionality.

The modules should be separately compilable so that if changes need to be made to one of them, the whole system won't be affected.

The modules should communicate with each other through small, well-defined interfaces, which act as wrappers to hide the implementation.

And there should be as few of these interfaces as possible.

The use of interfaces allows modules to be very portable, and standard interfaces such as COM interfaces can be used to further increase portability.

Models are usually represented visually by some type of notation.

The notation often takes the form of graphical symbols and connections.

A graphical notation facilitates portraying the structure of a complex system.

It also provides consistency throughout the development process, as models produced using it are standard and are retained for the lifetime of the project.

This means they can be read and understood by everyone involved with the project.

A good notation should allow an accurate description of the system it represents.

It should be as simple as possible, without being oversimplified.

And it should be easy to update and to communicate to others.

The Unified Modeling Language (UML) is a robust notation that you can use to build OOAD models.

It consists of a series of diagrams that represent the different views of a software system in analysis and design.

For example, there are diagrams to chart the interaction between a user and the application.

When you attempt to develop a system, it is not enough to have a notation for modeling - you also need to know how to use the notation.

This means you need a process to guide you through a software development project and through using the notation.

The combination of a notation and a process is known as a method.

Analysis of all but the smallest systems will generate a large number of diagrams, so it is important to record these accurately to ensure consistency in the model.

In order to record the diagrams that you create using a process and notation, you need a tool.

The Rational Software Corporation has devised the Rational Objectory Process to guide developers through a software project.

And it has created a tool called Rational Rose for creating UML diagrams.

The UML has its origins in several competing OOAD methods that were developed separately in the late 1980s and early 1990s in response to the software crisis.

One of the main methods was the Object Modeling Technique (OMT), which was devised by James Rumbaugh and others at General Electric.

It consists of a series of models - use case, object, dynamic, and functional - that combine to give a full view of a system.

The Booch method was devised by Grady Booch and developed the practice of analyzing a system as a series of views.

It emphasizes analyzing the system from both a macro development view and micro development view.

And it was accompanied by a very detailed notation.

The Object-Oriented Software Engineering (OOSE) method was devised by Ivar Jacobson and focused on the analysis of system behavior.

It advocated that at each stage of the process there should be a check to see that the requirements of the user were being met.

Each of these methods had their strong points and their weak points.

Each had their own notation and their own tool.

This made it very difficult for developers to choose the method and notation that suited them and to use it successfully.

This period is often referred to as the time of the "method wars".

New versions of some of the methods were created, each drawing on strengths of the others to augment their weaker aspects.

This led to a growing similarity between the methods.

In 1994 Rumbaugh joined Booch at Rational Software Corporation in order to create a new method.

It was called the Unified Method and its aim was to unite the Booch and OMT methods.

In 1995 Booch and Rumbaugh were joined by Jacobson and the emphasis on the project changed.

It became clear that the focus of their work was on creating a single, standard notation rather than a method, so they renamed their work the Unified Modeling Language.

In January 1997 version 1.0 of the UML was released.

And in September 1997 the Object Management Group (OMG) accepted the notation as a formal standard.

Although main parts of the UML are based on the Booch, OMT, and OOSE methods, the UML also includes elements from other methods.

For example, state charts, devised by David Harrel, have been incorporated into UML state diagrams, and the work of Erich Gamma and his colleagues on patterns has influenced the UML.

The UML is an attempt to standardize the notation used for analysis and design.

The standardization includes diagrams, syntactic notation, and semantic models.

The aims of the UML that its designers have set are
• to model systems using object-oriented concepts

• to accurately describe conceptual and executable artifacts

• to support both small-scale and large-scale analysis and design

• to provide a notation that can be used by both people and machines

The UML is an object-oriented modeling language and its diagrams and semantics are based on object-oriented concepts.

It is designed to describe many types of system in object-oriented terms.

However, the UML is not limited to modeling object-oriented systems.

An example of the type of system the UML can model is an information system based on large databases.

These databases store data in complex relationships and make large amounts of data available to users.

The UML can model both relational and object databases.

Object-oriented technology facilitates the implementation of embedded and real-time systems.

And it facilitates the development of systems that are distributed across a number of machines and require synchronized communication mechanisms.

The UML can be used to model both of these types of system.

The UML can be used to model system software such as operating systems and networking systems.

And it can be used to model technical systems that control equipment such as industrial machines, military hardware, or telecommunications systems.

In addition to software systems, the UML can be used to model business processes, such as the flow of work within and between departments in a company.

The UML is composed of three different parts:
• model elements

• diagrams

• views

The model elements represent basic object-oriented concepts such as classes, objects, and relationships.

Each model element has a corresponding graphical symbol to represent it in the diagrams.

For example, the symbol for a class is shown here.

Model elements are defined semantically in formal statements describing what they are or what they represent.

Each model element can be used in several different diagrams but it always retains the same symbol and meaning.

And there are rules governing the diagrams that each model element can appear in.

Diagrams portray different combinations of model elements.

For example, the class diagram represents a group of classes and the relationships, such as association and inheritance, between them.

The UML provides nine types of diagram - use case, class, object, state, sequence, collaboration, activity, component, and deployment.

Views provide the highest level of abstraction for analyzing the system.

Each view is an aspect of the system that is abstracted to a number of related UML diagrams.

Taken together, the views of a system provide a picture of the system in its entirety.

In the UML, the five main views of the system are
• use case

• logical

• component

• concurrency

• deployment

It is necessary to break the model of a system down into several views with related diagrams.

This is because it would be impossible for one diagram to represent an entire system accurately and clearly.

In addition to model elements, diagrams, and views, the UML provides mechanisms for adding comments, information, or semantics to diagrams.

And it provides mechanisms to adapt or extend itself to a particular method, software system, or organization.