Although there is a well-defined academic foundation for object-oriented concepts, most developers are not aware of it or would not know what to make of it if they were. Most of the work of analysis is driven by the concepts we will cover in this module. The diagramming notation will lend precision to diagrams, but the meaning and content must be assessed against the principles of good object-oriented modeling.
Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modelling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.

Question: What is analysis? If you read through the software literature and textbooks, you will find that there are as many definitions of analysis, as there are authors. Ironically, analysis is something we know we must do; and yet have no real definition for.
One of the most common ways to differentiate analysis from design is to say that analysis is "what" and design is "how". This sounds compelling at first. Clearly if we can first define "what" we want the system to do, then it will be easier to define "how" the system should do it. Indeed, vast quantities of man-hours have been spent attempting to separate the "what" from the "how". It is not uncommon for a conference room full of people to descend into the endless argument regarding whether what we are currently doing is analysis or design.
Arguments like this are common because of the peculiar fact that every what is also a how", and every "how" is also a "what". The arguments cannot be decided, because both sides are actually correct. If we use the "what" vs. "how" definition of analysis and design, then every concept that is an analysis concept is also a design concept and vice versa.
What and how are associated by an equivalence relationship that leads to a recursive descent into detail. Every "how" becomes the "what" at the next level of recursion. Every "what" is just the "how" of the level above it. The number of levels is very large, and probably infinite. This means that "what" and "how" are separated by only a small amount and are virtually identical.
If we view analysis as "what" and design as "how" then they are equivalent operations that cannot be separated from each other. All analysis is design, and all design is analysis.