Remarks on abstract OO domain model: inheritance

There are some issues that I think needs clarification and discussion. The thing that I start with is perhaps not the most important, but important enough. This is inheritance in abstract domain models. As everyone who has programmed any OO-language very well knows inheritance is very prominent difference between 3G and OO languages. This feature shortens a lot the size of the code in OO. However when the model is trying to describe (ie. help to understand) complex domain reality then things get more tricky.

A first purpose of an abstract domain model is to create a simplified picture of reality. This picture contains both structure and behavior of the world. In this context some feature becomes very important. First of all the model should catch as much semantics from reality as possible. On the other hand we have a conflicting demand and that is to limit the size of a model into something comprehensible. My experience is that we are able to manage in our minds 1 – at most about 150 classes’ network. From the current point of view the low end is no problem but the high end is.

I have to say that first symptoms of high number of classes (or at least the fear of it) can be seen indirectly.  Novice modeler tends to draw several (rather) small class diagrams of their model. Ideal number of class diagram is of course one! Then people around the model have possibility to see, feel and understand the complexity of the domain at hand. I have been quite comfortable with 60 -80 classes. Using Peter Coad’s four color categories makes it still easier to read and understand.

So the richness of semantics would enforce as much details as possible. On the other hand we really want simplification to “see the wood out of trees”. These two conflicting forces drives the analysis. This means that all classes included must be very carefully thought. This has two consequences. First the naming of each class is very important. All class names should come out of the language of the business domain. This means than every class will have some directly and intuitively some content for any business person even if the person doesn’t know the model and it hasn’t been explained to that person. There is a tendency to choose selling names that are very general or loosely used.  For example Customer and as a class name is most typical of those which semantic meaning is far too vague. Event, Thing and Role ( these are Peter Coad’s color categories) are far too general (ie. abstract) and thus have not enough semantic substance. By the way using color coding in diagrams every class can be in addition to its name tagged into one of these types.

But let’s return to inheritance. This seems to be quite difficult for beginner, but this is exceptional difficulty because it is mostly overused! This means that our tendency to classify thing is actually misinterpreted to mean a lot of inheritance in OO models. So the advice is never use inheritance just for enumerating classes object along some attribute values.  So the minimum requirement for a specialization class to be added to an abstract model is that it has behavior that cannot be in the general class objects or that the behavior is so remarkably different that it requires own class. Another point is that we actually need several classes ( typically from 2 to few – less than 10) which all have many association to many other classes. Then if the modeler is able to bring in a generalization class that collect the association to be drawn only once.

So instead of this:

perintäAssos2

perintäAssos1

It is better to draw this:

In most domain models the maximum inheritance structures in the whole domain is 2 to 4. If there are significantly more of these then it is either a very exceptional domain or there has been a very novice modeler coaching the team.

Finally adding a class in abstract OO domain model is expensive decision. That is why this move has to carefully considered before taking this step. On the other hand the model should not be too general. Very general models are neat but as they lack the necessary semantics they are good for nothing. If you take the class names from a model and give the list to a domain expert and he or she don’t know where the terms are from then your model is polutions.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: