About understanding and communicating an object model

A model by definition is a simplification of reality. The main reason for model is always a simplification of existing or a design of something to be. Sometimes as an extreme a model can be one-to-one, but calling that a “model” is actually somewhat misleading.

The reason to have a simplification of something in most cases is the fact that the total amount of detail would be unmanageable and not understandable and for this most general reason we use models.

As we model concrete 3D things like houses we can have the model in 3D also, but the size of the model is far smaller than the size or the real thing. The downsizing evidently will disregard or destroy some amount of detail and simplify the model compared with reality . Another way of modelling these things is a mapping done from reality (current or future) to some kind of language. In the case of building this language consists of geometrical figures, which maps to realty. For instance a floor plan consists of together joined rectangles and a set of other graphical signs like door and windows.

To understand meaning of a model implies that the person in question is able to “see” the corresponding reality trough the model. If we use a mapping from reality to not self-evident language (like in case of house plans or maps), then the prerequisite for understanding the model is the knowledge of the discreption language.

Understanding is not a two-value function (on ; off) but a complex multi value thing. Thus it is very risky to say that a person doesn’t or a group do don’t understand the model. Rather we should consider to what extent someone understands the model.

It is obvious that the more complex the model is the more difficult it is to understand all aspects of the model. Even the “understanding” concept is difficult. The complexity of a model depends on two independent sources: 1) the domain in concern intrinsic complexity and 2) the chosen abstraction level of the model.

The complexity of the domain cannot directly be influenced. Indirectly this can be influenced by limiting size of reality to be modelled. The level of abstraction is completely in hands of the modellers. The semantic descriptiveness of a class and its level of abstraction has the following dependency with ease other:

This means that when chosen the level of abstraction of a class this with determine the semantic content or richness of the concept. So the lower the level of abstraction is the more semantic meaning the class name (&definition) will have. Of course it is good to have as much semantics as possible but the contradicting demand is to reduce the amount of less important details to promote understanding.

To balance the model between these demands the most effective choice is somewhere in between the extremes (the orange line in the figure). A very important aspect of OO-model creation is that towards the end of modelling a given domain the emphasis is on simplifying the model as much as possible without losing its semantic weight or value. This means that we approach a point where leaving something away will have a dramatic effect on the model collapsing it totally. Here the model has reached its complexity minim (at a given semantic level). If someone then demands to reduce the complexity of the model being too complex to understand this will mean no model at all!

The abstract object model consists of a class model and a set of collaboration diagrams. Class model contain all the classes ( concepts) found during the domain analysis and all the relationships between the classes. This class model can be represented in one or several class diagrams. Even if the model is represented in more than one class diagram the model itself is always one and connected. It is moderately ease to show that this model if it is correctly done is in the complexity minim of all models.

I will continue with understanding the model. First we have several different methods to model reality. Some of them are structurally simpler than OO-models like for instance use cases which have hardly any structure at all. Then we can move the whole model (ie. all classes) up and down the semantic-abstraction triangle. If we chose very high abstraction level we loosed a lot of detail and we will have a simple model. So simple models are far easier to understand than the models that have more structure, semantics and more fine grain behaviour defined.

The best OO-model in the middle of the triangle is most effective model. Thus it leads to most effective implementation as an application.

The model include also a set of collaboration diagrams describing a few cases with the deepest and most important sequences, which describes some instances of  creation of the most important event object of the business cycle. These diagrams consists of objects not classes. For this reason the are very concrete and far easier to understand. Sometime we can draw additional static object diagrams to explain complex structure without any messaging.

Associations are first class citizens – or even more than that

In our OO tradition, which is reflected and somewhat in UML-diagram, we neglect the value of the association. As we draw like this:

It leads us to think that the association is actually a handle or a reference to another object. In a simple case this is to large extent true. Actually a closer investigation into the association reveals that association can have attributes. Theoretically we can say that the meta-model behind our object model – the vocabulary of concepts – should include the following structure. Here association is a class-like structure but includes additional elements; the connecting arms the association ends.

UML includes also an associative class notation:

The first question raised by this is “Does this class represent the whole association”?  My answer here is yes. In this way we are able to give the association attributes and behavior. This association class is restricted to bilateral association. This means that the association is exactly between two objects. We can however think of multilateral association as well. I will return to this issue after introducing another concept.

Let’s take another way of looking at class diagram. Peter Coad proposed using color coding in class boxes (as I am using here). Coad’s meta-model for coloring is following: Here all classes are divided into four categories: entity, description, role and event-moment.

This categorization has proved to be very good and exceptionally practical. Of course four categories is very course grain and thus from time to time one comes across a situation where it is difficult to decide the category.

Let’s combine these viewpoints and analyze this structure a bit deeper. I think that both role and event categories are actually extended or specialized association types. Let’s take them one by one.

Event as association

An event object can be considered strictly speaking self-contained, but conceptually almost every event needs at least one participant to justify itself. So in practice event object are also kind of associative objects.  Here we meet a multilateral associative object. Event is an association in space-time continuum, that associates all objects that are connected by time and space.

Here is a modification of previous Person – Dog model.  I have added here an event that actually and conceptually is “behind” the association. To live together is the real association.

Emphasizing the time aspect here gives conceptual clarity and adds the duration aspect for free. Sometimes (perhaps in this case too) the time aspect increases anxiety in people but it definitely clarifies the situation.

Here we have another example. He person is going to have a meal. The meal is prepared by the recipe of that meal. He is the first variation of the class diagram. During the collaboration as it start person object needs a handle to the particularly meal to be able to sent it a message cook().

So here the association between Recipe and Person is purely to enable the message passing. Even if the earlier OO authorities suggested to have an association here I disagree. I think that association in  class diagram should reflect stabile and lasting structures in reality ie. they should have a meaning. In this example  there is no real stabile association between person and recipe. The association is momentary and temporary.

This is way I choose the next diagram instead. On collaboration diagrams also temporary association are seen as message pathways when needed.

Finally we can enhance this by adding an explicit event object class Cook here. Now the final comment here is then in this case the association between Meal and Person. This is more question of taste that right or wrong. I prefer rich association and would have myFood association even if this can be deducted indirectly trough objects from Cook – class.

Role as association

Role- class objects are not self-contained but dependent they will always need the actor association (the one who’s role is in question) and the action part where the role “is used”. Thus we can deduct that all role objects are actually special cases of an association object. The nature or role semantically is “participation in action” but it is quite common to shortcut this and put the role between to entity classes. The following is a typical example of this:

As noted actually this should be as follows:

Now the role type object is in between entity and event. In this special case as the cardinality of positions in employment is exactly one so the role object is in this case completely redundant. All its attributes can be moved to event itself.

On contrary when the even has more than one participant the role object has a true meaning and cannot be by bypassed. Technically the role attributes could be move to person, but conceptually it is more accurate to separate to attributes from person to role because one person could have several roles active simultaneously and in time sequence as well. In this way role object actually is a degenerated event within the even.

Proving OO to be the most effective application development paradigm

1.      Background

It has been intuitively completely clear for a long time that object-oriented 3- tier approach is close to complexity minim and therefore requires least work to implement a given functionality.

This was actually the most important reason to create OOP and OOA (look at:

Grady Booch: Object oriented design Second edition p: 16-23  and Peter Coat Object Oriented Analysis  chapter 1.3. Analysis Methods p: 18 -36)

2.      Complexity model from Start Kauffman

Originally a medical doctor, Dr. Kauffman’s primary work has been as a theoretical biologist studying the origin of life and molecular organization. Thirty-five years ago, he developed the Kauffman models, which are random networks exhibiting a kind of self-organization that he terms “order for free.” He borrowed his model from physics call spin-glass model. The following is a quotation from Kauffman’s book:  At Home in the Universe. (ISBN= 0–19–511130-3 )

http://www.amazon.com/At-Home-Universe-Self-Organization-Complexity/dp/0195111303/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1223150067&sr=1-1

The NK model I will introduce is a kind of genetic version of a physicist’s spin-glass model. The virtues of the NK model are that it specifically shows how different features of the genotype will result in landscapes with different degrees of ruggedness, and it allows us to study a family of landscapes in a controlled way.

I will briefly sum up Kauffman’s concepts findings and conclusions. The idea of the proof is that there is a fruitful area between chaos and order where development using random search is both possible and probable. This is ruled by how big part of independent features is tightly or loosely associated.

Then we create a scale from bad to good and we assign for each feature and a random value to this feature. This is a starting point. Now we start our evolution scenario by randomly introducing mutation within the features. Then we interpret the total change as organisms as fitness of the organism in the ecosystem.

Kauffman talks about ruggedness of fitness landscape. The interpretation of N/K in genetics is that N is the total number of genies in an individual. K is the number of genes that are closely related. Changing K from 0 to N reveals that when K is relatively small compared to N the group has best possibilities to evolve and adapt along time and when K is close to N here are practically no chances to develop. Then he extends this pattern to things he call “patches” and the results repeat themselves but this time the close attached subset is topologically defined.

(See Stuart Kauffman: At home in the universe pages: 164-180)

The conclusion is that adaption that can also be called learning is interplay between the structure and the basic dynamics. Here the combinatorial exploration is bounded by the organisation or structure and this way enabling that dynamic search to continue. This applies to patching s well.

3.     Complexity in modelling behaviour

Now I am applying his interpretation and conclusions into the application development domain.

The two different approaches separates from each other in the way the behavior is modeled. Here is an illustration of them both.  The functional decomposition sees the functionality just time sliced actions as OO explain it as collaborative functions of individual object. The next diagram illustrates this comparison

Figure 1.                          Function decomposition and  object collaboration

First remark. I pretty often come across a claim that OO analysis is more abstract than functional decomposition. This is false. Actually for the following comparison it must be the same. This level of abstraction is reflected by the number of attributes in system.

The thing that separates these is the amount of organization or structure. In the object view the first layer of structure is given when the domain is divided into classes. This leads to distribute activity into the object. This is done in a way where locality is maximized. First this means than object itself is the only one to see it’s attributes so all manipulation on those are strictly isolated within the object. The next layer of functionality of this model is the collaborations of a given set of objects.

The application of Kauffman’s N/K landscapes starts mapping gene’s to OO case to attribute – atomic base element.When we consider this difference in terms of N/K, then we can say that N is the number of attributes in system.

a.  Value of K in functional decomposition is N-1 since there is no structural restriction to use any attribute in the system.

b.  A simple estimation of the value of K in object collaboration is N/C, where C is the number of classes in the system. N/C is the average of the attributes in a class.

Now when we consider the two approaches to behavioral abstraction, they are :

functional decomposition and OO collaboration. In our interpretation the first division into closely related subset of attributes comes from class encapsulation. So in this case the number K is the average number of attributes within a class. If we have 100 classes in the domain layer then K = N/100. Classes encapsulate much of the behavior within each class. The coherence between the attributes inside of a class is much higher than to attributes in other classes.

So if N =800, then for functional decomposition K = 799 and for object collaboration it is near 8. This has a tremendous impact on the ruggedness of the landscape. (see above).

The second layer of organizational management of complexity is what Kauffman call patching. The equivalent in OO is the consequence of class structure topology.

Figure 2.  A few (3) patches for example shown in airline class diagram

Objects forms clusters with other objects from directly associated classes. These object cluster form the patches and the coherence is much higher between object in the cluster than outside the cluster. As you can see from my illustration we can think that these patches are overlapping or fuzzy or we can do just simple partitioning of the class diagram.

4.     Abstraction

Lets return to abstraction.  First definition:

Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.

So abstraction equal simplification and it is done to address a certain viewpoint. The downsize of this is that we lose part of information. This loosing is the price of the clarification. On one hand abstraction has direction – you can think it as a vector in n –dimensional reality. When we have chosen the direction then abstraction is linear.

When we are think to model  a company operation it often includes some abstraction direction that have same starting point. The size of this point witch normally is a ball over these dimensions that is spanned by the set of vectors. The whole model the union over these spanning vectors.

Along each vector abstraction is linear. So each class is on some level of abstraction and has semantic content.. The level of abstraction is always connected to a reverse value of semantic. Following diagram describes this relationship

Figure 4. Dependency between level of abstraction a class  and semantic value of a class.

Here the most effective representation lies somewhere near the center. The same result can be deducted from Kauffman’s patching. From his book we know that the evolutionary power is related to the size of the patch. This indicates that complex minim is achieved in the middle of extremes. This is quite obvious too. If our classes are very abstract then there are very few classes and the size and complexity within such class is very high. In the other extreme we have very small classes with high semantic value but the number of these classes exceed the limit of manageable number of elements.

1.     Three loosely connected aspects three logical layer of implementation

The third layer of patching is achieved  by early separating the three aspects: application, domain and persistence. The logical 3 layer implementation where application, domain and persistence is separated and the coupling to domain layer is asymmetric from both side. This way domain lives in complete isolation and doesn’t know anything of the rest of the world.

Figure 5.             3-layer architecture and isolated domain layer

The static structure (classes and there association) and he dynamics ( methods, distribution of responsibilities and  collaboration) gives us a narrow isthmus between chaos and strict order. This is the same area of phase change where for instance life on earth have created such a vast complexity.

It is extremely important to remember, that this isthmus is narrow and that we don’t really have much freedom to move in either direction.

2.     Final conclusions

In paragraph 3 we found a narrow isthmus. Now this abstraction semantics akseli actually cut our isthmus and we are left with a tiny island in the sea of complexity which gives us minim. At the same time we have exhausted all our reassures. This means that we have reached our highs peek in our ruggedness landscape of effectiveness. I read this so that our theoretical knowledge in search of solution in application development in deterministic Turing machines has came to fulfillment; to its end.

On one hand the fundamental restriction of current system is of course the determinism of behavior on  the other hand this has been and is our aim in the first place. We all want truly want that a given transaction from one bank account to other bank result always to same end state.

When we extend our aim to nondeterministic Turing- machines then we come across with learning. This is then equivalent with Kauffman’s self-organizing  sets. The difference here between the previous and current if self with translates to learning. This is the cause of non-determinism. From our systems perspective this means the fundamental change in our method structure. All methods have to became mutable and their mutation is learning.

The technical solution from the hardware point of view shall be something like our brain: neuronets. The theoretical researches has been going on for some while all ready but I seems that we don’t know yet quite enough about the subject to be able to copy the hardware to perform the desired function.

Unambiguous language and DDD

The real purpose of OO-modeling is  - as modeling as whole – to create abstract simulation of the world. The closer the model follows the structures of reality and the corresponding behavior of the associated parts the better the model simulates reality.

For this reason it is vitally important that all the concepts are clearly define and unambiguous.

I have been developing Smalltalk and Java application since 1994. All of these have been built starting from scratch an abstract domain model and finally implementing this as the middle tier of and application. In my experience the most crucial thing here is right model of the world itself. This means that the business understanding is crystallized in the model. This means that the understanding, the language it is expressed is equivalent with the model. These are the same thing. Thus you don’t actually need a separate glossary because your class and attribute definitions is that glossary!

Yes! This is the most crucial thing of all. When this is right everything else goes smoothly if this is wrong there is very little to be done to correct the situation. More of this at my web-site and of course in Grady Booch excellent book:  Object Solutions ISBN:

Finally a quote from that book:

 The center of gravity of an object-oriented information system should be its domain model.

·         Get this model right, and your task will be much easier.

·         Get this model wrong, and abandon all hope.

 

Rehabilitation of Object-Oriented Paradigm

The foundation I have sadly followed the slow corrosion of the OO-knowledge in general. What I want to achieve is the full rehabilitation on OO-technology. I am utterly convinced that Object Paradigm is the highest achievement in the theory of application development. My long working experience support completely this convictions. I am now referring to the great work from ParkPlace Smalltalk though the dawn of OOA by Grady Booch, Jim Rumbaugh, Perter Coad, Rebecca Wirfs-Brock …and many many other. The core of the great invention is crystallized in Grady Booch’s Object-Oriented Design (1991) (pages 15 and 16) says:

Actually, this is a trick question, because the right answer is that both views are important: the algorithmic view highlights the ordering of events, and the object-oriented view emphasizes the agents that either cause action or are the subjects upon which these operations act.` However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views. We must start decomposing a system either by algorithms or by objects, and then use the resulting structure as the framework for expressing the other perspective. Our experience leads us to apply the object-oriented view first because this approach is better at helping us organize the inherent complexity of software systems, just as it helped us to describe the organized complexity of complex systems Object-oriented decomposition yields smaller systems through the reuse of common mechanisms, thus providing an important economy of expression. Object-oriented systems are also more resilient to change and thus better able to evolve over time, because their design is based upon stable intermediate forms. Indeed, object-oriented decomposition greatly reduces the risk of building complex software systems, because they are designed to evolve incrementally from smaller systems in which we already have confidence. Furthermore, object-oriented decomposition directly addresses the inherent complexity of software by helping us make intelligent decisions regarding the separation of concerns in a large state space.

The following illustration is a picture of these two views that Booch talks:

Functional decomposition Agents’ collaboration The fundamental reason, why the model becomes so much simpler even it is containing the same semantic, is the close similarity to reality. We humans understand reality as massive collection of 3D functional entities – I will use here a term agent for those entities. These are autonomous things that interact with their neighbours. As we analyze world this way the functionality and thus also the responsibilities of these agents will naturally remain quite small and compact as long as the model is humble and honours the reality. In fact this is the only way -that at least I know- where every function of a big collaborative community of agent becomes defined exactly ones. This is actually the essence of the goal of all “reuse” even it is often badly formulated.

OO Application development process

If we try to model this way a big and complex application implementation, which of course finally have to be very detailed, we will end up to unmanageable complex models. This was just the mistake we did in early day of OO. But this growth of complexity can be restricted and finally managed with clever organisation of artefacts. To start to solve this problem the first thing to notice is the separation of concerns:

1. Business logic.
2. User interaction and the user’s workflow.

These aspects are naturally quite orthogonal (they are from the same world but at the same time they are rather independent from each other). The solution to this problem has two equally important parts: •

Logical 3-tier architecture to separate the concerns 

Start the design with first creating the abstract domain model representing the business logic and all times keep this completely unaware of the rest of the world. If you look at the literature mentioned above, you find that they are not doing either or if they have the first point they start with application requirements. This is an error that leads into exponential complexity growth. According to my experience only very small minority of people deeply understand the contents and true meaning of the concepts “abstract” and “abstraction”. Very briefly abstraction is reduction of details of a concept. This reduction is not however an easy one, because we should remove less important aspects from the concept. The tricky question however is which elements are less important. The selecting criterion here is the context on which we are considering the concept. When we limit the search strictly into domain, the important concepts will emerge relatively easily. Much more difficult it is to decide the abstract responsibilities of these concepts. Here the stress is on word abstract. The aim is to get the behaviour as equally distributed into the network of concept as possible. Here we have two guidelines as well. We have to try to reflect the reality and at the same time lift the level of abstraction by placing the behaviour in objects that have most resources available in them selves or very near to reduce unnecessary communication between object. After this the reality and the model are not one-to-one. The end result of this is a object model (class diagram and a set of collaboration diagrams), that describes the whole business behaviour on chosen level of abstraction and thus give us a simulation model of the business core. Now we have reached a point we the middle tier analysis is done:

As I already emphasised, the dependences here are asymmetric. A very important point is that the middle layer is completely independent from the outer layer, but these are heavily dependent on middle layer. The business logic tier contains only the assimilated aspect of business rules derived from business objectives. This leaves a lot room for the application layer to implement this abstraction. All dependencies to user interface or environment technologies are handled in application layer. The third layer is purely technical isolation of the persistence and could be argued to be left out of this picture completely.

Development process

 

The sequence of the application development is following: In the second phase we will implement the abstract domain model to required detail. In most cases this means adding all the required attributes and the persistence which in a case of new database is quite strait forward. In the third phase we start to look the whole from user’s point of view. We define the processes and the use cases and finally implement them utilising now the services from our domain. The iterative and incremental (in one word agile ) nature of the implementation of the application layer is illustrated in the follow diagram: Each use case can be considered as one cycle here. First we have to design the work process. This starts from designing the use cases. Then each use case can then be developed as part of the application very independently from the others. The implementation uses the domain model from previous phase as it is. When the work proceeds additions, refinements and correction will be made into the implementation domain model. It will mature during the application development. It is necessary to question and doubt its content and structure and change as often as a new aspect appears.