3.2 Analysis Models

Analysis Models   

An analysis model is a model of how the world will interact with the software system that we envision. As such, it is our statement of just what the system will do when it is working.

There is a real temptation to simply assume that the automated system will simply squat in the middle of the world, interacting with all the real world objects, sort of like this:

Or if you prefer,...

It’s Magic!   

Poof! We have an analysis model!

Not wrong, per se, but it’s certainly not helpful.

Such an approach is fundamentally at odds with the OO philosophy

• We should look to the real world to suggest how to decompose our system.
• In this case, we have not decomposed it at all – just wrapped it up into a single black box.
  • All the hard decisions still need to be made.

In essence we have not done any analysis at all here. This "model" isn’t wrong, per se, but it’s certainly not helpful. We’ve basically thrown away everything we’ve learned in the domain model about how objects really interact. We’re treating the new program as a simple box, with no knowledge of its internal structure, Essentially, we’ve just deferred all the hard questions to the upcoming design.

Evolving the Analysis Model   

What we really hope for is an evolution from our domain model to our analysis model. The OO philosophy tells us that the classes and interactions of our domain model…

…should carry over into our analysis.

In essence, we hope to retain these classes, add more detail to our understanding of them, and to establish a boundary that tells us which of these classes and behaviors will be automated, which will remain entirely unautomated, and which will have some portion automated while other parts remain external.

The Boundary   

…establish a boundary that tells us which of these classes and behaviors will

∙ be automated

∙ remain external

∙ be a mixture of the two

The system, then, remains a collection of interacting objects rather than an unstructured black box.

There’s a definite overlap in the purpose of a requirements document and of an analysis model. Some will regard the analysis model as a kind of requirements specification. In some projects, though, a requirements document will still be required as something for customers or management to sign off on. But the analysis model is the basis from which the eventual requirements document is derived.