CONCEPTUAL MODELS ARE THE ESSENTIAL ASPECT OF OBJECT-ORIENTED ANALYSIS

“An important principle in object oriented development is designing software so that its structure reflects that of the problem. One result of this principle is that the models produced from both analysis and design end up deliberately similar.”

These words are not mine, they have been written several years ago by Martin Fowler in is book [1]. Often the difference between analysis and design models are debatable. The novice modeler coming from structured methodologies is dismayed because he is used to exploit different notations for different types of models (here with “types” I mean analysis vs design/implementation). The uniformity of the notation is one of the cornerstones of the OO paradigm. Again, Martin precise:

“The difference between analysis and design still exists, but it is increasingly becoming one of emphasis. When doing analysis you are trying to understand the problem. This is not just listing requirements in use cases. Analysis involves looking behind the surface requirements to come up with a mental model of what is going on in the problem.”

The real essence of every analysis model is the conceptual model which realizes the mental model that best explain the problem under investigation. What does mean “best”? Again from [1]:

“A choice of model affects the flexibility and reusability of the resulting system. Building too much flexibility is dangerous because can make the system too complex to understand and manage; this is bad engineering. To build software that is fit for a purpose, you have to develop a conceptual model that is appropriate to your needs. You need the simplest model you can get away with.”

Here there is a link between the simplicity of a model and the essential complexity inherent in the problem space [2]. You need to deeply investigate the domain problem in order to embrace all the essential aspects that can forge the requirements of the system. If you ignore some aspects of this essential complexity, you miss important elements and your conceptual model will be too simple to fit for the purpose. One hint provided by Martin is to involve domain experts in conceptual modeling. A domain expert is not a developer. He is a full-time worker in the domain. Expert knowledge is essential to create a good analysis model. Missing that knowledge, you will not have a true object-oriented model. Missing the domain expert, you investigate for knowledge crunching in the wrong places.

I find this attention to conceptual models in OO analysis a path through domain-driven design. Eric Evans explain domain-driven design as an approach to build deep models, i.e. models that distill knowledge from the domain [3].

“The goal [of a deep model] is a design that makes the model obvious, a model that express the domain simply. A deep model distill the most essential aspects of a domain into simple elements that can be combined to solve the important problems of the application.”

The difference between analysis and design models in the OO paradigm is all around the presence of conceptual models. The only goal of the analysis model is to describe a deep (essential) model that fits for the purpose of functional requirements; the goal of the design model is to transform the analysis model in order to fit for the purpose of non functional requirements.