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.

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:

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.

My history of IT

1971

I was accepted to study Natural Sciences at Turku University

1972

I started my studies of computer science ( Approbatur I)

http://en.wikipedia.org/wiki/IBM_1130

The computer that we worked with was IBM 1130 with card reader, line printer and one hard disk drive.

The address space was 15 bits, limiting the 1130 to 32K 16-bit words (64 Kbytes) of core memory. Botdirect and indirect addressing capabilities were implemented

The console of the IBM 1130 computer

IBM26 Card punch machine

and my firs programming langue was FORTRAN and pretty soon after that COBOL (which was quite exceptional in university circles). AT that time we used (of course) card punch machines and  we got 2 computer runs ( batch jobs) done a day. The student where not allowed to enter computer room at all. We hade to leave our jobs in a box in a corridor out side the computer room.

1975

We got a new “real” computer Digitals DEC 10

From Wikipedia again:

The KA10 had a maximum main memory capacity (both virtual and physical) of 256kilowords (equivalent to 1152 kilobytes).

with timesharing operating system: TOPS-10 System (Timesharing / Total OPerating System) was a computer operating system from Digital Equipment Corporation (DEC) for thePDP-10 (or DECsystem-10) mainframe computer launched in 1967.

At the same time we got rid of the card punch machines and got our first real terminals

This was really a cool new thing ( we didn’t call it cool in those days). The orange thing on the left side of the machine is a paper stripe punch/reader. One could direct the output from computer alternatively come to that stripe as holes instead as print on the paper. At this time the programming language had changed to Pascal. At later stage we got also display terminal, but this was about all that so computer technology during my university years in practise 1973 – 1977. Officially I graduate 1980, but actually I had been full time working a couple of year at that time.

1976-77

My first part time employment as a COBOL programmer. My office was just a couple of hundred meters from university, so it was quite convenient to mix work and studies this way. The project that I worked in was a nightmare!

1979

From the beginning of February I start my first fulltime job as a computer programmer at Yle (Finnish Broadcasting Company). My first assignment was maintaining a new payroll system. It was a huge batch program set. It calculated payrolls for Yle employees at that time 4000.

The system was running on IBM 360 mainframe.

Yle didn’t at the time have its own machine so we bought time from a local authority.

We worked mainly with punched cards but the department with 10 programmes had already 2 online terminals IBM 3270. Here are pictures of the device and a screenshot

Early 1980’s the time of APL

In 1980 I graduated master’s degree in Computer Science from Turku University. In early 1980’s I learned APL-programming language running on IBM mainframe. Yle used this thing for creating domestic result service of political elections ( like parliament and local authorities and presidential). APL was just the right tool in those days for that. It was highly effective to do rather small calculation intensive things. I attended my first international IT-conference on APL in San Francisco in 1981. We where show also Smalltalk, but I did not understand anything about it then.

In 1982 I changed my job and I became a APL-specialist. The company was a joint venture of local authorities. It was extremely bureaucratic organisation. The main thing of course was that I realised that APL is NOT a language for organisations.

1984 Systems engineer at HP

So I did a full U-turn and joined HP 24.10. 1983. I became a systems engineer of HP3000 commercial minicomputer.

HP3000

Code (reentrant) and data reside in separate variable-length segments, which are 32,768 “halfwords” (16-bit words) (or, 65,536 bytes). The operating system, known as MPE (for Multi-Programming Executive), loads code segments from program files and segmented Library (SL) files as needed, up to 256 segments in one process.

There could be as much as 64KB of memory in a code segment, but calling a routine was based on segment number and routine number within a segment, so a program could theoretically have about 32,385 routines. This was compared to most 16 bit computers that had 64KB of address space for everything. The bigger limitation was the data segment and stack segment, which were also 64KB.

I learned a lot of new things. Two of them were important. The first was the operating system MPE (a Unix like but perhaps even little bit better than Unix). The second thing was that contemporary ways of working with computer can have one or 2 magnitude effective differences ( 10 to 100 times different)!

HP3000

Pretty so our dummy terminals were changed to HP 150 micros. I started to use email system at HP in 1984. My last year in HP I was full time trainer teaching almost everything on HP3000.

HP150 PC

1988 Finnair

I moved to Finnair to assist their Videotex system to be moved from MP1000 to HP9000 equipment. Soon I created a group Methods and Tools with me boss. Finnair was (and still is ) a IBM customer, so I a way this meant me a return to my roots. Now my main environment was to be Windows 3.11 on IBM AT Pc.

Do you still remember these?

1989 my OO time starts

I attended late October 1989 a OOA –seminar by Peter Coad. His book Object-Oriented Analysis was not out yet but he had a blueprint with him. This changed my thinking completely. Something irreversible had happened.

In summer 1992 after I hade attended ObjectExpo in London I got my first Smalltalk: Digitalk’s Smalltalk V. This was a horrible experience of completely unfinished poor product. In Jannuary 1994 I got change to get a real (and only) thing: ParcPlace’s VisualWorks Smalltalk.

ParcPlace sold VisualWorks to CinCom and the product is still today alive and called Cincom Smalltalk VisualWorks (see: http://www.cincom.com/us/eng/solutions/application-development/object-oriented/index.jsp?loc=usa )

Timo Salo gave me and Jyrki Niekkamaa a few days training and then we started to experiment and create applications. Finnair’s car leasing application was the first one to try out. That was a total failure, because we had only one user and he was too incompetent to use a computer application at all!

The first real OO-application development from January 1995

The visioning of an Smalltalk application started in October 1994. Our domain model of Finnair domestic sales was ready at the beginning of February 1995. The started the implementation of legendary Finnair SalePlus. The period from 1995 until 1998 as I resigned from Finnair was the most productive and inspiriting in my career. In 1996 we acquired GemStone – a Smalltalk database. This environment boosted up considerable our Smalltalk application development. The product is still sold and in use (see: http://www.gemstone.com/products/smalltalk/)

The software was very sound and reliable. In 1997 we sadly switched to Java. It was at that time about 5 years behind Smalltalk.

1998 to 2002 Aware and Entra

Java had been developing and the first EJB implementation was released. Though it was terrible and ruined all OO aspects from application development and filled it with all kind of tricks it was a step towards real distributed server Java. It offered and RMI solution which was a read distributed OO with elegant proxy structures in client side. Sad thing was that people with very little OO-skills didn’t understand how to use it the right way and spoiled its reputation.

Another very sad thing was the sift to HTML-client in distributed computing. HTML was (and is not even today) design for application development and was the lousiest possible choice for technology.

My contribution to ADDD.

The start of OO

The classical OO- analysis and design is the cornerstone of OO application development. From those early days of 90’s come the fundamental ideas: domain classes with private attributes and private and public methods placing business behavior into domain layer and splitting the implementation into logical 3-tier architecture. This is all extremely vital also today. Actually almost nothing has changed in these respects that would affect their importance or value.

Popularity and expansion

Along 1990’s when OO gathered popularity and more people where involved things started to screw up. Bigger projects where started with less trained people. To ease the confusion Ivar Jacobsson introduced use cases. The result turned out to be almost the opposite. Many people were confused about use case’s meaning and role. The difficulty with those was (and still is) that they are not actually part of OO neither notation nor concept. Actually wrongly use they can be completely overlapping with the real OO notation. The heart of the problem is very fundamental. When people tried to do more complex things with OO they run into the problem of abstraction levels.  (there are more detailed posts on both previous subject in this blog). The consequences of this all was that people started the development  at too low abstraction level and they were hit badly by the combinatorial explosion and as always when a team starts to use a new method or discipline and they are not enough trained the method get the blame (of course not the people)!

My findings are:

First I studied the relationships between the layers in the logical 3-tier architecture. It was evident (and often told allowed) that the responsibilities of the layers got mixed in the real implementations and the more inexperienced implementer were the fuzzier the layers became. In the early days all the gurus advised to start from application requirements and work through application controls to domain layer. In most cases this ended to a catastrophe due to rabbit complexity growth.

My analysis came about with the following corrections:

1) Tight couplings:

Domain itself is always tightly coupled within itself. This actually is the pure meaning of the domain. Theoretically (and in practice too) is forms a transitive closure.

Both outer tiers are tightly but at the same time asymmetrically coupled with a subset of domain. Asymmetry means that the outer tier is tightly coupled with domain but the reverse is not true. The domain is not at all coupled with application tier and each domain class has exactly one hook to the persistence tier. The domain doesn’t know anything of the rest of the world. See the next diagram:

2) Timing

All the old gurus suggested to start from application requirements. I think this is wrong! Thus my first modification is on timing: Start from abstract domain OO model without even touching the application part. This means that the business behavior (rules) must be modeled with object collaborations. This will imply that the domain OO model is modeling a subset of reality of which the organization is interested and where it operates.  Here the emphasis is on by whom not how. Of course the where also includes how, but the point of view is that the organization is not acting alone but rather where and how it interacts with others. So this model is actually a subset of reality not organization. Starting here actually implies that the domain modeling is about understanding complex reality and is the least interested in any current or future IT system what so ever.

Start from a “clean table” and first do your analyze on concepts and bring about your initial class structure. By the way UML class diagrams are end results but their versioning is an instrument. Without drawing things wrong you cannot draw those right.

3) Control over the level of abstraction

The second thing is to control continuously and knowingly the level of abstraction. This is very important as well. The main goal of the initial domain model is to understand and to get a grip of the target reality. Thus here the most important task of  the modeler role is to keep the amount of detail as low as possible and still get as much structure and semantic as possible. These goals are evidently contradicting so you have to try to balance between them.  In the initial abstract domain modeling phase the amount of classes increase rabidly close to implementation phase level but the number of attributes should say quite low during the whole abstract analysis. An average amount is around 5 % – 25%. It should never (even in very small models) exceed 65 %. The final set of attributes should be discovered though application (UI) designs.

4) Abstract analyze phase

The responsibility to create abstract domain model belongs always to people with best operational knowledge of the business. If the group includes also top management decision power this will ease and speed up development but this is not in any way necessary. This is always group activity. It is extremely important that most of the important interest groups are presented. The starting phase is conceptual clarification and language calibration. Actually this gives the language of the business. Of course there has been a language before this, but this is excellent opportunity to create crisp sharp edged concepts and their relationships. The name of this all is an abstract OO domain model. This phase takes typically 3 – 10 working days of the group. It should be intensive enough an optimal timing is 3 * 6 h session a week for a couple of weeks. This should ever exceed 15 working days. During this process will be created 3 – 10 versions of the domain model.

5) Application design & implementation

I am convinced that agile methods are the best way to implement application. But before the development SCUM with its sprint cycles I think that it is wise to have this abstract analyze phase before it. The iteration starts from analysis domain model that is generated into some OO -programming language for instance into Java. The development of different use cases of the application can happen almost independently. Of course there are common parts (GUIs and control) that can be shared but even this is not necessary. Each iteration will add new attributes into domain. The need for these rises from GUI and workflow control.

Considerations

Is this difficult? This subject divides people. Some of us think this is difficult others don’t. I have considered this (all my live) easy. The basic think is to grasp the world as a stage for individual actors to collaborate. If one see the word in this way: collaborations of autonomous agents, then there should be no obstacle to consider OO-models easy. I actually get support to this view, when I create object diagram to illustrate some important or complex single case instead of class diagram.

One or the professional skills here is the ability to read class diagrams. All professional OO-modeler have to be able to “see” though a given class diagram all the possible cases that yields from this.

*ADDD ( Abstract Domian Dirven Development)

Why use cases are evil?

The previous post about databases and OO wiht headline saying …also eval actually refered to this text – so their order is wrong. Anyhow here it is now for you.

Well this is not the whole truth and first this is not only use cases but all procedural abstractions of behavior. These come with many names in addition to use cases: activity models, process models, rule models etc. Another fact is that they are not intrinsically mean. Actually they are just one way of abstracting behavior. The reason which makes then mean in context of modeling for application development is that they yield ten times worse solution.

All the way from the early days of OOA (late 80’s and early 90’s ) it was crystal clear that the description of procedural and object behavior are strikingly different.  There is no right or wrong here. They just are the same thing from completely different viewpoints. They are orthogonal abstraction of the same thing.

The most significant thing that created object paradigm was just this difference. This is a paradigm issue and thus the difference has a strong antagonistic nature. This means that you must choose and there is now way of mixing these together.

The big step in deeper understanding simulation modeling was that object collaboration yield to a magnitude simpler model than the corresponding procedural one. What is the cause of this difference? The root of explanation comes from microbiologist Stuart Kauffman. It is question of how to manage complexity. His findings were that the most complex organisms (and organism are always both structure and behavior at the same time) are in the middle ground or gray area between chaos and rigid order.  The conclusion was that you need both ingredients to accomplish.

In case of our models (and also programs) “wild” or “free” behavior (in programming a method or equivalent) represents the flexible chaotic side and class definition, class boundary with behavioral encapsulation and objet collaborations represent the order ingredient. This mixture is actually the trigger that collects the jackpot. This way we are able model 10 times more complex simulation than in the realm of pure chaos. The fundamental aim to avoid the repetition of the same behavior in the model over and over again is gained by the classes definition -or concept- that ultimately limits the objects possible behaviors. In other words the number or trick that a single object can is limited and this of course reflects to implementation so that the number of methods (if designed right) is limited. Thus the object model is the  only way (that at least I know) that can achieve this.

We can ( and actually have several times) come across a subset of reality that we would like to reflect  with application but which is too complex for us. There is of course a limit what we can do with this. The real limitation at the bottom of this all is our computer. Currently it is an implementation of deterministic Turing machine. We know the limitation of this from mathematics.

When we want to exceed these limitations and we would like to create learning applications we must go to nondeterministic Turing machines. The fist difficulty here is that we don’t have the hardware yet. We human stars to understand enough of brain structure and behavior then we can copy this to a machine. On other consequence from this is of course the fact that these system cannot be programmed. They must be taught! The final inevitable consequence is these application can do mistakes like humans!

Why the term: ”database” in object context is also evil

1 .  Impedance mismatch
In the early days of objects there was much talk about “impedance mismatch”. The phrase comes from physics. The intention here was to tell that objects and relation databases have a crucial difference in the point of views used and they can even at concept level been naturally integrated.
2 .The fundamental difference in the core of concepts
The idea of “data” doesn’t exist in the world of objects at all! What does this mean? Well “data” is organic an inseparable part of an object. Compare this with car. The body of a car is so essential part of a car that there is actually no sense to talk about “car without a body” – this just doesn’t make any sense at all. This partial analysis led finally to concepts like “data”warehouse and “data”mining . These revel the absurdness of such separation.
So the “data” is inseparable part of object. This means that a concept of object-database is actually a total misinterpretation. The right term would be closer to object community or society or tribe or similar. Why even object base (without the data) be misleading. Now any collection of unrelated arbitrary object is worthless waist -next to pollution. Objects make sense only in association with other objects! These are not drawbacks of our viewpoint but in the contrary these are the restriction that we want to impose on our model to make our lives easier in the future!

3. Association is a first class citizen

To give for this a bit more organized or formal presentation let’s start by creating the model (metamodel) of our OO-analysis domain. The object model of a class model is the following:

When our class diagram look like following:

and a corresponding object diagram can look for instance like this:

Now when I would like to get rid of my Renault and I will sell it to Bill then the association between me and that car is removed. The point here is that both ends of the association leaves exactly at the same time. The result looks like this:

What we really mean ie. try to say exactly is that there exists an object typed association: the ownership which is connected to two distinct different type of entity objects ( person & car). Now from this we can easily see that association is not two mutually independent collections of object as they in most cases are implemented but is one thing with two aspects. When you remove the association object both ends are removed simultaneously and it is logically impossible just to remove one end because such association has now meaning.

4.  Object societies shouldn’t have query-languages
Query languages are a side effect of this data aspect. Technically SQL query feature gives one an illusion of combining almost anything with everything. In reality this is of course not true. In contrary the structure of realty restrict heavily a meaningful use of such feature. Another sad thing is that those current relational database implementations don’t check structural validity of a query. This means that one can join tables though columns and the semantic (ie. meaning) validity is not checked at all.
The right way to do this would be to restrict the navigational possibility only to structurally established associations. In object network (not in database) the navigation though the network can only be done trough established association and this traversing should happen using the corresponding objects get-methods. In every object network an object is heavily dependent of its direct associative neighbors. The dependencies beyond this get rapidly weaker and weaker. In this way for each class there have fuzzy sets of dependencies to other classes. One fundamental principle of a domain class model is that all classes are connected. This means that for every class of each other class is reachable and thus has an associative weight is > 0. In other worlds the network in connected and when one picks up an object from any class one can (at least in best circumstances) reach and an object in every other class of the graph.
The point here is that strictly speaking every class knows only its directly associated classes. To navigate longer than one leg route through the network the navigator is responsible of knowing the route through the network. There is this way a strikingly exact analogy to a street network in a city. The streets don’t know all the routes through the city but the corners know what next corners can be reached from them through their “association” namely street parts connecting two corners.
The only thing to add here to complete the required “query language” is to allow a multi attribute filters for the enable easy filtering of collections. When class A has a association to collection of Bs then A should have getBs() which returns the whole collection. To be effective A should have a selectBs() method with optionally all free attribute types of B. For example when our Person has one to many association to cars so Person class should have as a standard feature a method selectCars() with optionally color and production year (and all other free attributes that car happens to have). So I could get a subset of the whole car collection with the following method call: selectCars(“blue”, 2003).

Confusions about abstraction

What the concept abstract really means ?

The term abstract is widely used, but the meaning in many cases is vague or fuzzy. To calibrate the term let’s try to define what we exactly mean with the concept (the word)

The next is a quote from English Wikipedia.  The definition of the word abstraction:

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. For example, abstracting a leather soccer ball to a ball retains only the information on general ball attributes and behavior.

Abstraction uses a strategy of simplification, wherein formerly concrete details are left ambiguous, vague, or undefined; thus effective communication about things in the abstract requires an intuitive or common experience between the communicator and the communication recipient.

Abstraction is reducing the information content

So here the point is simplification by reducing the amount of details.  The purpose if this is to emphasize the important aspects from the chosen point of view.

To say that abstraction is simplification is true, but this expression could be interpreted too strongly. The simplification is in most cases achieved be reduction of details. So there is still room to move within the simplification. The amount and nature of simplification depends on the situation and change case by case.

From pure theoretical (mathematical)point of view we can say that abstraction is a mapping  f ( L) -> R, where L is the source set (in our case a subset of reality)and R is the result set (the model of reality). The mapping  f will abstract (simplified ) the complexity of L if the result set is more simple than the source set. In most general form this means reduction of the number of detail. This implies that the mapping f is homomorphism but is not isomorphism. Otherwise the reduction would be 0-reduction. Homomorphism means that many source points should map to one result point. This way a reverse mapping is not possible. This implies that the mapping genuinely destroys information. This lost information cannot be returned in any way just from the model.

A terrain and a map of this terrain is a good example of this kind of modeling.

Simplification is a double-edged sword. When the point of view and usage is strait forward and simple normally there are no problems. When we consider my geographical map example if we need direction with car in southern Finland or street map for waking in Helsinki city center, then the scaling of  the map is no big issue. The situation changes a lot when the “map” (model) is used in several different points of view and interests.

Common confusions of “abstract”- concept

Non-concrete is abstract
Abstract-concept is often used fuzzily as synonym for non-concrete and/or difficult. Sometimes people say that mathematic or geometry are “abstract” as such. This does not however conform to the previous definition. In other words there happens neither simplification nor reduction of detail. Both of these mainstream fields of mathematic are axiomatic system with rules of manipulation.   Completely other story is then the fact that mathematic and geometry can be used as instruments in abstraction but in such a situation the mathematic is only vehicle or tool to create the mapping between sets. In the same way we can say that chess game is abstract. This is false again. The game is most concrete thing in the world with it’s board and chess pieces and game rules. Following the same deduction also the programming languages are not abstract but well defined games in their own world.

Programming is abstract

The world of computer programming is defined by the physical structure of von Neuman machine. The next question is then do programming languages form layers of abstraction above each other? Many people say that Cobol is more abstract than assembler. My opinion is NO in my strict use of the concept abstract. My argumentation is following. As our current programming languages are all deterministic the code cannot truly simplify anything that effects the decisions made in the path of execution. This implies that all deterministic programs are isomorphic with each other. This means that when we have a function f from programming language a to b which gives the mapping then there always exists e reverse function f-1 which gives the reverse mapping from program in b back to original program in a. The real thing that some call abstraction is only compression! Here is a small simple example of that compression.

Example:  for-loop java 4 ja 5

void cancelAll(Collection<TimerTask> c) {
    for (Iterator<TimerTask> i = c.iterator(); i.hasNext(); )
        i.next().cancel();
}

and

void cancelAll(Collection<TimerTask> c) {
    for (TimerTask t : c)
        t.cancel();
}

Simplification always boils down reducing the number elements – the less important ones.  When the program is deterministic all those elements (attributes and their values) that control the flow of execution control must be present regardless the chosen programming language.  So in every equivalent program exactly the same if- statement must be present in one form or an other

UML is  abstract

UML is one-to-one mapping between a well defined set of concept and their corresponding graphical signs. This mapping is isomorphic between the graph and the garpth “verbal structure” which can be any programming language. This way UML is a transformation algoritm between a diagram  and a description (which can use for instance Java language).

About real simplification

Let’s return real simplification. When we model the reality we face all the time the question of how much do we simplify. When we are doing the mapping between the realty and the model we have to choose the scale. The following diagram illustrates the two sides of the decision. The y-axis is the amount of abstraction (or simplification) and x-axis describes the amount of semantics within a concept. When you pick up a point in y-axis and decide the level of abstraction the at the same time you get the amount of semantic value, which is the width of the triangle at the point. So the higher we are the smaller amount of semantic the concept gives.

There is a shaded  area in the center of the y-axis.  This shows optimal (read the best possible) level of abstraction and the read thread indicates that different individual concepts (read classes) can be at different levels of abstraction. This actually means that the benefit that we get from abstraction increases to maxim somewhere in the middle from 0-abstrction to total abstraction, which is single point with no content.  See the next diagram:

A common myth is that the higher the level of abstraction is the better. As this discussion shown this is not the case in contrary. As we can see from the parable at first there is a clear increase of clarity will follow but then at some point the raising of the level will reach a point where the simplification starts to corrupt the most essential parts of the information and finally the mapping will collapse to zero.  So both ends of this graph are area of danger.

First example of big crumpling at the left end of the graph was IBM ambitious attempt with objects. The project was called San Francisco (3200 classes, 24600 methods)  at the end of previous millennium.  The attempt was more or less to produce a model that would cover all possible businesses. As you can see from the figures above the level of abstraction was far too low. The model was finally constructed with huge effort. The trouble saw that it saw totally useless with that amount of information.  I am still quite frequently running into attitude where really big (read detailed) models are bolt and to be proud of but sadly the trough is almost the opposite.

The second extreme is of course at the other end of the function. These are models with very general concepts and only a few needed. Usually these models are technically correct but semantically completely empty. So they look nice but don’t contain any real value to develop applications.

This is the point where I can return to Grady Booch, when he asked his audience: “When is a domain model ready?” His answer to this question was that it not ready when all the possible classes have been added to the model but it is ready when you cannot remove a single class from the model without totally collapsing it!

My experience is that such a model typically consists of 30 – 60 classes. So even here the famous rule of Albert Einstein: “Everything should be made as simple as possible, but not simpler.”  is completely valid!

By the way the modeler can decide the number of classes in the model even without knowing anything about the target reality. This is of course done by either lifting or lowering the level of abstraction of several classes of the model.

Abstraction within programming

The level of abstraction of the classes is not directly reflected in the absolute number of classes but rather in the relative number of classes and methods together. This means that the higher the level of abstraction in the model is the more complicated are the implemented methods and vise verse.

This way the logical 3-tier architecture can lift the abstraction level for the GUI programmer by encapsulating the lower level details inside the object boundary into the method implementation.

Aged not outdated remarks on the meaning and importance of behaviour

About the difference: Yes I meant what I wrote. This is the root cause of the birth of Object-Oriented Analysis (OOA).

Here are the references:

Grady Booch: Object oriented design Second edition p: 16-20

http://www.amazon.com/Object-Oriented-Analysis-Applications-Addison-Wesley-Technology/dp/020189551X/ref=sr_1_7?ie=UTF8&s=books&qid=1241502775&sr=1-7

Here is the summary from Booch’s book:

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.

 and

Peter Coad: Object Oriented Analysis  chapter 1.3. Analysis Methods (p: 18 -36) 

http://www.amazon.com/Object-Oriented-Analysis-Yourdon-Computing/dp/0136299814/ref=sr_1_1?ie=UTF8&s=books&qid=1241502828&sr=1-1

If all this is completely new for you, I suggest to you to read Coad’s book completely and first half of  Booch’s book.

As Peter Coad in his book strongly emphazises here we face a paradigm change. The glue in paradigm is that you cannot mix to paradigms. In his class training Peter Coad used as an example of two paradigms digital and mechanical watch. The point is that you have to choose -in good and bad. You cannot have both or even a mix.

To conclude this I enclose a short email from Peter Coad from 1995:

   Issue 34

Category: Use-Case

Title: “Use-Cases Considered Harmful When…

Date: Tuesday, December 3, 1996

Dear Friend,

A “use-case” describes how an actor interacts with other people and with automated systems, to achieve some business purpose. Use-cases are a helpful way of specifying functional requirements (use simple statements; state requirements from a user’s perspective; establish system context; define who is interacting with whom) For each use-case, one works out dynamics with scenarios. Each scenario is a time-ordered sequence of object interactions, showing what it takes to carry out a use-case (or a variation within a use-case).

How do object models fit into all of this? Object models provide a stable organizational framework (that is to say, problem-domain classes), so changes in use-cases or features can be more graciously accommodated.

It’s very important to make this point:

Use-Cases Considered Harmful … when used to drive an object model’s shape.

Perhaps it’s even a bit silly to write that. After all, if I made the statement:

Functional Specs Considered Harmful … when used to drive an object model’s shape

Nearly everyone would agree (with the exception of die-hard data-flow diagrammers and hard-core functional-spec writers .

Allowing use-cases to be the driving force in shaping effective object models is a major mistake [1,2]. Far too often the resulting object models look like data flow diagrams, dressed in object notation. (When you see an object model and can classify its classes into controllers, function blobs, and data blobs, you know you are in trouble!)

A Better Way

A better way? Here’s a recommended approach:

1. With your client, develop a list of features (desired outcomes, things your client will “vote with his wallet” to get).
2. With your client, prioritize your features into three major categories: A (must have), B (nice to have), C (next time).
3. With your client, group related features together. These groupings are use-cases, defined at an appropriate level of abstraction.
4. With your client, create an initial object model, from classes named in the use-cases and features.
5. With your client, proceed feature-by-feature and:
   1. Work out dynamics with scenarios.
   2. Establish responsibilities, along the way.
   3. And, at times, discover additional classes of objects, ones you had not previously considered.

When someone hands me a book of use-cases, do I use them? Definitely. When someone hands me a book of functional requirements, do I use them? Definitely. How? In both cases, I use such sources of content, not for insights on how to shape an effective object model.

Pete

Stubborn confusion with behavior

All the way from the early days of OOA (late 80’s and early 90’s ) it was crystal clear the description of procedural  and object behavior are strikingly different.  There is no right or wrong, they just are the same thing from completely different viewpoints. They are orthogonal abstraction of the same thing.

The most significant thing that created object paradigm was just this difference. This is a paradigm issue and thus the difference has a strong antagonistic nature. This means that you must choose and there is now way of mixing these together.

The big step in deeper understanding simulation modeling was that object collaboration yield to a magnitude simpler model than the corresponding procedural one.

This is a simple fact of reality and it can never change. This means that it is logically impossible that ever anywhere could come any new information that could change this.

Somehow most of IT community lost this crown gemstone of OO. First came use cases as Ivar Jacobsson introduced them. He had actually good intentions but he was misinterpreted and his idea was turned upside down. Then came components and after this activity diagrams. Now the newest names for procedural description are processes and SOA!

I saw somewhere an article where the writer praised “the blessing” of the fact that we “get rid of spreading the behavior and we can collect that all in one place”. This very thing was just the reason or drawback which was cured be bringing the structure and behavior together and distribute responsibilities between object. In this way we got two layers of behavior with first layer encapsulated within the objects. Then the second layer is the collaborations between objects.

We can actually prove this reduction of complexity today with the huge help from microbiologist Stuart Kauffman. Our practical experience tells us that the simplification ratio in average case is 1: 10.      

My motto.: The Use Cases (by whatever name) are evil so retreat  to collaboration.