OO Analysis ModelSource: comp.object
Problem: What is the role of an OO analysis model? Does it become the system architecture or is it just a way to discover requirements?
Alistair Cockburn clarified:
[These qeustions] are dancing around two points.
First, what do you want out of this thing you call "analysis"? i.e., what is the meaning of the word and therefore the purpose of the exercise. I typically avoid that word entirely, because so many people attach different meanings and purposes to it, with the result that the discussion is entirely skewed.
Second, how much validity is there in any objects/classes nominated directly from a user's view or requirements description?
I'll skip the answer to the first, because I don't use the word analysis, and you get to say what you intend.
For the second, my experience is that the any number of interesting, valid, and possibly overlapping conceptual or OO models can be generated from that initial, functional description. It is not what is nominated first that is interesting. It is a later model, one that takes into account software design issues and system evolution issues, that is interesting.
It is hard (impossible) to predict, from looking at the initial description, which of the very many valid models will be selected for implementation. I am willing to assert that the final, coded model should be a valid model of the world, but I can't hope to guess which of the many valid ones that will be.
What then, could be the purpose of an "analysis" model?
I'll allow for the moment the existence of such a thing. Its purpose is to generate discussion about additional, refined requirements, and to be the first design model, in a long line of evolving design models, each a valid model of the world, but each a better fit to the software situation than the previous.
Since it is "just" a design model, I don't call it an "analysis" model, I call it the first iteration of the common object model. I don't mind if someone else calls it an "analysis" model, if they accept that the designers get to change it (as long as they keep producing new valid models).
Martin Fowler, Class Diagrams
Alistair Cockburn, Writing Effective Use Cases