Tuesday, January 20, 2009

Views on a Cat

Suppose, you're going to design a new software system for a specific domain. One of the first steps is to introduce a domain object model which comprises the core entities in the domain as well as their relationships. That's easy, you might say. If it is that simple, why do so many  projects fail in establishing the right domain object model? And, of course, this challenge inevitably appears in all kinds of modeling activities.

But now for something completely different - as Monty Python would say. I got two nice cats at home. In order to model a cat, there are different possibilities:

  • (ATOM) We could consider a cat as a mere collection of molecules.
  • (GENE) Obviously, a cat can be uniquely identified using its DNA.
  • (BODY) Another approach is modeling a cat as an aggregation of subsystems such as legs, joints, muscles, intestines.

Does it make sense to apply the first model (ATOM) in order to understand how a cat moves? No, because the detail level is overwhelming.

Is it useful to use the third model for understanding all chemical activities within a cat? Definitely not!

With other words, we can model the same physical concepts in different ways, each of these views strongly depending on the purpose of the model. Don't let yourself be confused. It is not as simple as having only one model for one purpose. For example, to understand the physical appearance of a cat, you could apply model ATOM as well as model BODY.

What are the implications of this observation?

  • First of all, you might require different models (views) in order to define and understand a software system.
  • Secondly, each model should be motivated by a concrete and useful purpose.
  • Thirdly, all participants should agree on syntax and semantics of the model.
  • And last but not least, all models should be documented.

Mind the word "useful" in the second bullet point. As organization drives architecture, the organization often directly maps to entities in the model. If your organization is badly structured, your architecture will reveal the same problem. Think about this in the context of your own organization.

As another consequence I'd like to emphasize that it is not sufficient just inventing a couple of sophisticated models. The set of models should also be simple, complete and consistent. All of the models should complement each other in a meaningful and appropriate way. That's the reason why we got view sets such as the UML 4+1 view.

Unfortunately, I often sit in project meetings where people strongly believe they are all sharing the same view of their domain, while in fact they are not. Endless discussions might be an indicator for this problem. Thus, it is essential to explicitly come up with a common domain model that is agreed among all participants. Basically, the design of such a model should be one of the early steps  in a development project (directly after scoping but before architecture design). Needless to say that software engineers are surrounded by models: they have specific views of the problem domain and the solution domain, use tools such as compilers or database systems that themselves are built on top of models.

If a software developer's life is about models and model transformations (e.g., the mapping from the problem domain to the solution domain) we should consider models as first class citizens and invest sufficient time for choosing the right viewpoints and establishing the right models.

Interestingly, even our view of the physical world such as the way we understand a cat is determined by models. But this is a different story.

5 comments:

Anonymous said...

Da liegt der Hund begragen.
Das war des Pudels Kern.
Genau das ist der Kasus Knaktus.
Das ist der Schlüssel zur Findung des richtigen Weges zur Lösung der Softwarekrise. Die Bedeutung des von Ihnen angesprochenen Punktes kann man gar nicht genug unterstreichen. Ich glaube jetzt ist klar geworden, wie sehr ich diesen Beitrag begrüße. Begrüßenswert fände ich wenn sich auch andere Persöhnlichkeiten der SE in Deutschland gerne auch in Deutsch dazu äußern würden.

Anonymous said...

Wieso können wir die Begriffe und Konzepte der Informatik nicht in ähnliche langlebige Kategorien wie Physik, Chemie oder Bilogie einteilen?

Anonymous said...

Wieso können wir die Begriffe und Konzepte der Informatik oder richtiger der Softwareentwicklung nicht in ähnliche langlebige Kategorien wie Physik, Chemie oder Bilogie einteilen?

SBL Software Solutions said...

As a software development firm, we appreciate your article

Regards
SBL Software Development Solutions
http://www.sblsoftware.com

Anonymous said...

Hello.
Design Levels is something I've been blogging about (the concept here).

Although not exactly the same idea, the design level dictates the view level and language level (model) you should use to design.

Basically, the strategy level would be that of architecture, the tactical is the common class design. The operational level would be the one where you do micro-design, just at the time of writing code.

That said, it is clear there is no single view level for development, but it is a multi-level view work.

William.