ObjectOrientedAnalysis

The investigation of a problem by breaking it down using classes, objects and relationships between them

Definition

There are many definitions for Object-Oriented Analysis (OOA). Different definitions suit different purposes and lead to different advantages and different problems. All have in common the investigation of a problem by breaking it down using classes, objects and relationships between them. Rather than providing one single definition, several are sketched out.

• Defining the problem without introducing aspects of the solution.
• Making discoveries without making decisions.
• Breaking apart the requirements without building up mechanisms.
• Saying what to do without saying how to do it.

Source

Discussion

There are two particular problems when doing OOA that have been debated regularly among the experts; when does analysis become design, and when should one stop doing analysis. There are, of course, different answers to these questions depending on the different goals one may perceive for analysis. In most cases it doesn’t really matter, because when one takes analysis too far, one starts design. Yet if one were to say analysis was complete, then one would start design. It is important to note that this argument does not refer, when it talks about being ‘complete’, to the whole analysis of the whole problem, but to any chunk of the problem that is a suitable size for progressing through a particular development methodology.

The favoured definition of the author refers to making discoveries without making decisions. The goal is to provide an analysis that goes as far as it can without making any decisions that could potentially be rolled back. Thus the requirements are investigated to the stage where all effects of each functional requirement on any domain entity are recorded in an analysis model that includes an object representing that domain entity. The analyst is not permitted to introduce any objects that do not represent real entities in the domain of business, or record any effect that does not need to happen.

Note also that modern approaches advocate doing just enough modelling to enable the process to proceed, see AgileModeling.