There are a few very concrete entity classes: Person, Place and Building ( which can be a subclass of place). Then there is also a more abstract entity class Organization, which can be for instance a company in which one works at or a club where one belongs to. At first the class Place looks very innocent, but after consideration one find out that it is a tricky one. Basically it is a geographical spot or an area. How ever it must be able to handle well-defined distinct areas like an named city: Helsinki of a square: Trafalgar  square and on the other hand it must cope with more fuzzy are like southern Helsinki  of western Kent.

Then we have these most essential events around the person. This list start with simple things like where person is or is heading. At the other end of that spectrum are events like activity and participation.

Here is the class diagram:

The human social networks are all take care with event call relationship. I have added here also a classifying description type class Circle.

Here are an object diagram and a collaboration diagrams. The object diagram is a case with part of John’s social network. The other one have two short collaborations where Jim creates an activity and buyes a concert ticket.

Social network (object diagram)

Collaboration to create an activity and buying an ticket.

Thank You all for your interest in Object Oriented modeling and application development in the passed year 2011. I really appreciate it !

I wish you all prosperous New Year 2012!

Sincerely

  Jukka Tamminen 

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 8,300 times in 2011. If it were a concert at Sydney Opera House, it would take about 3 sold-out performances for that many people to see it.

Click here to see the complete report.

I must start once again from the very beginning. When we create an operational business application the domain model is the core of that. The business layer is typically only 10 – 20 % of the whole application code but the importance of it is in most cases 80 – 90 %. The implementation of this business layer is almost automatic generation of the OO domain model.

The domain object web is a many to one mapping from reality to the model. This means that the objects in the business layer has their corresponding objects in reality. This way ever real object and its corresponding model object has an identity and thus a life cycle. This means that all business object in the implementation are born and die according their counterparts in reality.

Let’s expand from object web to analysis and domain class model. Classes are classification instrument for real objects. Class gives a simplification of a category of real object. Is kind of minim commonality among objects that belong to this category. This way the classification gives an object a type.

Now when we have finalized our abstract analysis of reality and we have created the domain class model as an highest level abstraction and a few object level fragments (called collaboration diagrams), the implementation reverses the order and start from classes in the implementing code.

Sometimes when people come from strong programming background and the modelling and reality for application mapping is not that strongly emphasized, they loose this visibility. Somehow the techniques of language structure confuses these persons. This way the crucial fundamental of an identity gets lost. This way someone quite sincerely uses complex number as an example of an object. The fact is that it is NOT an object! In an OO- programming language we use class definition for two different purposes:

1) to describe object type (classification) or

2) to create “object like” structures that are NOT object!

The second choice is actually a misuse! It is quite convenient to use this structure in this way and it is quite OK, if the users understands these two aspects and don’t confuse them.

Day is a type for an event but it is not an object. Every technical event object requires at least one binding association to some real object to become a real object! We can of course technically create “an day-object”: myDay = new Day(); . But myDay is not an object because it doesn’t have an identity and there is no real thing that this artefact maps to. The only thing that can be said about this thing is that it is “an object-like structure”. This means that it has private attributes and public methods, but it still is not an object! The time semi object is transformed into a real object when it is associated with a real object. This gives the time object indirectly an identity. After this an event is not any more a template but a real event (in past, present or future). Then it is identifiable and unique in the universe.

A third way of misuse is to create a class and on object that has only behaviour. Here the confusion steams from something like sub function or a procedure. This is a fatal confusion and indicates that the designer has not cached up the object idea at all. Disconnecting a functionality from its context will definitely destroy the whole OO paradigm and its benefits.

Eric Evans in his book Domain-Driven Design in the chapter Services warn about this thing in the beginning of the chapter, but surprisingly he then accepts “Manager” or “Control” type of classes. My strong opinion has always been that this is a fatal mistake. Everywhere that I have seen this done it has lead to complete procedural programming with OO- language and this has always let to dome sort of disaster. One of the reason explaining Evans position is the week separation of implementation layers: application and domain. For instance value-objects belong to the realm application implementation. There are quite a lot of trick that we still have to do during implementation – sometimes for instance value-objects. The reason behind this is the extremely poor implementation platforms. Such problems should be take care of in the platform “operating system layer”, but this is not the case today far from it!

]]> http://jukkatamminen.wordpress.com/2011/12/13/difficult-oo-concepts-type-class-and-object/feed/ 0 jukkatamminen http://jukkatamminen.wordpress.com/2011/10/25/addd-is-future/ http://jukkatamminen.wordpress.com/2011/10/25/addd-is-future/#comments Tue, 25 Oct 2011 14:10:16 +0000 Jukka Tamminen http://jukkatamminen.wordpress.com/?p=471 ]]> Within at least 10 years I have not seen a slightest indication that there would be anything wrong with my ADDD approach on the contrary ever time it has been tried everything in the method has been proved to be working. Almost the opposite is true with many people and organizations!

I was fired by Tieto software house, because they did not find me any work. The reasons for this are
1. they don’t believe in object paradigm but processes and orchestrations.
2. they don’t want to work in lean and agile way, but they believe in detailed planning and waterfall.
3. they don’t believe in custom made but packages.
4. they don’t believe in professional teams but resource pools.
5. they don’t believe professional operating team (surgeon team) but distributed offshore development.

These differences drifted us apart. This is not just between me and one big software house. This is a global phenomena. The change here between the parties is a paradigm sift. Paradigm sifts are really big thing to do and to happen! Peter Coad in early 1990′s used as an example the wrist watch industry. When Japanese developed and electrical watch based on oscillating quarts crystal. Swiss had a flourishing watch industry base on old paradigm: mechanical machinery. These people from old paradigm were laughing at Japanese at their “toy” watches until their own industry collapsed totally! The same story repeats over and over again in our resent history: car production in UK or in US and Japan, home electronics in Germany and Japan, camera production in Germany and Japan, national flag carrier airlines and low cost airlines all over the world etc. Here the basic physics apply: the bigger the old paradigm activity is the more energy is required for the new paradigm activity to overthrow the old, but also the bigger the old is the faster the collapse will be after it has started.

The old paradigm will materialized in organizational structures. The bigger the organizations grow the more internal friction it will generate. This means that when a organization is created and its functional basic principles are set it is extremely difficult to change that fundamentally. The first big obstacles are the peoples’ skills. As the persons are selected by their their skills to suite the initial functions it is next to impossible to manage and carry out a process where the skill set is changed for most of the persons in the organization. This would require almost duple personnel if these people are to perform both their daily tasks and at the same time learn completely new skills. The next big question is do these people really learn required new skills at all! In short if this sometimes works it will be a miracle.

The most crucial part of this chain is of course the customer for whom the application is intended to. This current situation continues as long a the ability to secure their vital interests lacks almost totally from the client organizations. Of course this doesn’t change quickly. I have no idea how long this is actually going to take but anyhow it is required prerequisite for any progress! I can easily understand the responsible management when they are facing a situation, where they have a terrifying legacy backlog, ongoing critical production usage of the old system.

My prediction is that the change is going to start from medium size innovative modern companies. After the new far better production methods have been driven into at least some strong professional teams that has really internalize the fundamentals and the work processes thoroughly the last and then the customer that really wants the best and is not content when they only get something. This kind of customer must understand the underline principles at its high management, check the team’s quality and then trust it and fully commit to really work together to reach the results. A few such hits will finally start an avalanche.

In retail the key to the business is the material flow. When we consider contemporary retail like Amazon.com the modern trend is close to JOT ( Just On Time ) production. The point is to avoid any unnecessary storing of component. The implication of this is of course highly organized supply flow. Emphasis on the delivery mechanism is a must. In production it is actually more critical than in retail in average.

This demand is reflected in the domain model as well. The deepest essential event flow gos like this:

1. Provide the customers a comprehensive catalog of product descriptions.
2. Then the customer can order based on this catalog. When the order is received it is immediately replicated to the provider of the product.
3. In the worst case this will trigger a request to production. Then the customer is kept updated of the process.
4. In many cases and at least in more classical scenario the retail company is keeping and managing a stock of goods and maintaining order limits and quantities.

My model here includes all above aspects. The event-object purchase can thus be either and event between producer and the retail company or between the retailer and end customer.

I have of course also included the work-events and the worker role in the model as well.

Here is the object collaboration of a classical even chain, where the product is first ordered, received and placed on a shelf in the stock (or in the shop) and finally purchased by a customer.

This complexity can be divided into two aspects: domain model complexity and full application complexity of which the former is clearly a subset.

In this post I will analyze the object model complexity and I will return to other aspects in later posts.

When we have developed application for business needs for companies, they have always been aimed at operation automation and management.  This is the main trend still. The model in the core of the application has to be a model of the operational realty. In other words it has to reflect the reality that the business is part of.

The purpose of this model is to capture the deepest flow of the business events in that reality. Every reality can be modelled as set of objects , their relationships, their internal behaviour  and collaboration with other objects.

The number of ways that we can limit or hide complexity is very limited. Our only tools are abstraction, which can only hideaway chosen amount of detail and identification of natural structures that limit the possible combinatorial explosion of behaviour.   As we have many times seen abstraction is a double-edged sword. Having an overdose of it will definitively kill.

Atomic objects (even as  this is a relative concept) are always simple. The complexity of the world is mostly manifested by the relationships between the objects.

By indentifying and understanding the structures of the reality we can limit the combinatorial explosion in the abstraction of behaviour. This requires distribution of the behaviour into the structure. This is the most effective way to minimise the behavioural description. This is way we need objects. Optimal domain model complexity yields to least complex system.

Complexity and 3-tier architecture

We can still decrease the overall complexity of an application by applying structure of “second order” . This means isolating all business structures and behaviour in one separated business domain layer and connecting that as loosely as possible to other layers of the application. Here the clue is that there are no references out from this business domain layer. This means that the whole layer “doesn’t know anything of its surrounding” or how, where from and why it is used.  This principle was clearly realized already in the introduction of MVC-pattern by Smalltalk developers somewhere late 1980’s.

I have call this extension of MVC to 3-tier architecture (MVC)^^2 pattern.

Business domain model complexity

This deals actually with object model complexity but fulfils our needs as domain models are a genuine subset of object models.

I have written this at least 5 years ago, but it seems to me as valid now as at the time of its writing:

The complexity of object model

Background

The complexity of domain model is very important. As we all intuitively know the complexity grows non-linearly with the increase of classes in the model. It could be that the growth rate is > n² . To have some practical use -a real measure of complexity we need something more precise.

It is evident that the things that constitute the complexity are at least:

• number of classes
• number of association between classes
• number of attributes
• number of services

NK-complexity and the biological derivations from that made by

Stuart Kauffmann: At Home in the Universe: The Search for the Laws of Self-Organization and Complexity (Paperback)

(at Amazone

http://www.amazon.com/exec/obidos/tg/detail/-/0195111303/103-2499940-3404643

http://www.amazon.com/exec/obidos/ASIN/0195079515/qid=1059554173/sr=2-2/ref=sr_2_2/103-2499940-3404643

)

inspirited the idea that the base line of complexity comes from the product of the number of classes and associations.

On the other hand it has been long and well know fact that a even distribution of both attributes and services is a sign of good design. According to my intuition and experience this is valid for the distribution of connections between classes as well.

The measure

The source of complexity is two fold. The primary and genuine source is the selected domain itself. The other is in the creation of the model itself. The former cannot be influenced but the latter we can try to minimize.

The complexity measure is following:

C_m = c * avgr( r_i )*( stdev (r_i ) +1)*((avgr( a_i ) * (stdev ( a_i )+1) + avgr( m_i ) * (stdev ( m_i )+1))

c = number of classes in the model

r_i =  number of relations in the class i

avgr( r_i  ) = average relation in class

stdev ( r_i ) = standard deviation of relation over classes

a_i = number of attributes in class i

m_i = number of methods in class i

avgr( a_i ) = average attributes in class

avgr( m_i ) = average methods in class

stdev ( a_i ) = standard deviation of attributes over classes

stdev ( m_i ) = standard deviation of methods over classes

(Here relation means any kind of connection to a class (association or inheritance)

Theoretical basis

Let’s start with a given set of behaviour within a given domain.

This can always be modelled with an object model. In this object model the required and sufficient artefact are:

Class diagram with class descriptions

A set of collaboration diagrams.

A set of state diagrams (optional)

This is indeed all we need (actually without state diagram). This is a precise simulation model of the reality within the domain scope.  All rest is explaining, redundant or in worst case conflicting. Even state diagrams are overlapping, but they give neat additional view of time within one object –object’s essential life cycle. This is described in indirect way in collaboration diagrams too.

Within an object model the total behaviour is reached always with a set of services that will have the predefined behaviour. One service is composed of object’s own actions and a set of messages that it send to initiate services on other object. So each service is own actions combined with collaboration with set of other object that contributes to fulfil the initial service request.

The objects own actions are described with algorithms that operate on objects attributes.

The total business behaviour is the transitive closure of these services. This way we can create an abstract model of any total behaviour. This model has a homomorphic mapping to any object-oriented programming language. We call this mapping implementation of the model.

Now the degrees of freedom here are in the structure of the model and the distribution and placement of the behaviour (namely services) across the web of classes. All the classes (the name space) can bee freely chosen. Thus the whole static structure is completely in hands of the modeller.

    Considerations

1. 1.    finding: Number of classes in the model

The number of classes can be freely chosen. We can always start with one class. This structure is isomorphic with on-object programmed implementation.

We can expand the class structure by adding a new of classes. At first I thought that there is an upper limit for this, but at the moment I am not quite sure. We can of course think that ( at least in most of our cases) there is absolutely finite collection of actions in the domain scope and thus this would be the upper limit of the classes too, but the fact (that I can not prove though) is that to be able to add the behaviour to the classes as well we need increasing amount of control or managing classes and this can be the source of class explosion.

There is a correlation between number of classes and complexity minimum.

1. 2.     finding: Ruggedness of the fitness landscape of the class structure

From NK-complexity Kauffman (see Stuart Kauffman; At home in the universe ) has developed dependent complexity. He studies show that when K indicates the number of dependent objects on an object and when K is increased the ruggedness of the fitness landscape increases. This will effectively disable the possibility to reach highest peek ( actually in this case it is the lowest valley of complexity). This urges the need for loos coupling between objects. This can of course conflicting demand with the required behaviour.

The best way to achieve most of this is to follow next 2 simple rules:

1. Create the service to any class of the web that ‘knows’ the most of the matter at hand (e.g. has the most attributes associated to the action).
2. If one object can not complete the task it should delegate the responsibility for those parts completely to other objects and to collaborate with them.

1. 3.    finding: Patching of the class structure

Kauffman also finds that the whole is wise to divide into subgroups to increase adaptively.  The analogy here in domain model context could be Packaging. This is could true (see. Grady Booch Object Solution) but I have not seen it and I doubt it..

One kind of patching of course is the divisions of aspects: domain and application.

1. 4.    finding: Number of services

Here the arguments including the number of services in a class into the complexity measure are somewhat conflicting. We all know by experience and recommendations that the number of methods behaves in the same way as the number of classes. The optimum of complexity is somewhere between t1 and t2, where t1 is the number of attributes  –and t2 is perhaps around 10 – but at least bigger than t1. Currently the formula does not treat the count of methods quite correctly. When we consider the implementation (not actually know yet in the analyses phase) we know that there is an other correlation between the size of a method and the number of methods in a class (or at lest in the model).

1. 5.    finding: Counting the collaboration complexity as well

Actually it is most evident that some knowledge of the total complexity of the model is also in the collaboration diagrams, but this knowledge is not utilized in any way –at lest yet!

In most cases my recommendation is to combine these two events. This means theoretically that we interpret that the participation event is created before it actually happens. This participation will now housing also the attributes of reservation. This is a very effective simplification with no drawbacks. This way we can save one class and three associations and that is a lot!

This solution can be applied to variety of participation events like participations to a flight, a concert, a play, a party and it can be extended to cover even a stay in a hotel.

There is also a other issue that want to take up with you. This is more of a fragment of almost every business domain model. I will call this “person- organisation” pattern. In my very first implemented domain model in Finnair 1994 I was so inexperienced and at the beginning of my OO learning curve that I created the following class model:

and it proved to be inadequate  as soon as the application was taken to production and almost first user came and asked how do I put Nokia here!

of course the far more correct model is the following:

Here a bit more elements than just the role organisation.

So pattern is something that is nothing precise but something vague that one can identify.

When we consider Gang Of Four Design Pattern there is actually no domain area pattern at all!

I have tried to find domain model pattern but I have found only a few. Actually I think so that all my business line models are close to patterns.

Here is quite genuine domain pattern. One leading idea on pattern is that one cannot use pattern as such but one have to modify it to suite the current usage of pattern.

As I did already mentioned in previous post I call this “plan – implement” pattern.

The pattern concerns a design and implementation process of designing of repeating events. The idea is to design a repeating base time period like week, month or day as a template and for some period the actual even are created according to this template.

Examples of areas where this ably are for instance: all route transports like buss lines, railway connections, airline route flight, route transfer business on track and ships and also training organization or broadcasting companies.

The basic pattern is the follow ( at least I think so).

Some of the classes like Week and Day can be omitted, but this will give best give you the idea.

Thanks for all the comments to previous post and Tim Lethbridgefor the reference to his book.

Here is the class diagram:

Here is also one variation of “ plan – implementation” domain pattern. This is also an issue that I will return in future posts.

There are also some class name that I am not very happy with. I don’t actually know what I should call the event that I here call Run ??

Anyone have any constructive proposals ?

This post tries to answer those questions – at least partially.

There is no doubt about the fact, that model driven information systems are theoretically simpler to design and implement than their procedural counterpart. There is also enough evidence to prove that this is also the case in practical implementation and it works. But why then it is not used  in the mainstream yet?

I don’t really know the full answer myself, but I know different aspects that are at least part of the explanation.  This is most complex issue. If it was a simple and strait foreword one it would have been solved ages a go.

The key issue here is the understanding of the 3-tier architecture and especially the role and importance of the domain layer. When we go backwards in time then all the earlier application implementation were design as single applications. In this case the viewpoint and focus is strongly in the workflow and the usage of application. In this case it is extremely hard to force the separation of domain and application layer and the developers for good reason haven’t seen any value in doing so.

The complexities of the developed applications during long period of time have gradually increased. This has meant exponential increase in number of attributes and especially association. This rapidly grown complexity has not been and is not very visible and for this reason it is dramatically neglected! This means that the impact and the consequences of this have not been generally understood at all. To get forward from this we need at least two things. First one must realized the full meaning of the complexity growth and secondly one must understand that to meet the challenge of that complexity one needs a paradigm shift from procedural to object oriented world vision.  The two paradigms are orthogonal and they see the world from two different perspectives. There is nothing wrong with either paradigm as such. So the trigger for changing the paradigm must come from understanding how to manage complexity. The path to here has been rocky and difficult. It took over 30 years and a enormous hardware development from the IT-community to gradually understand this. This understanding did not reach critical mass before the late 90’s web bubble almost totally washed away this knowledge.

In the early days of OO during the booming phase the OO-applications where poorly designed due to lack of understanding OO thoroughly. This in average led to too low level of abstraction and at the same time also no separation of domain and application concepts and their implementations. This led to huge numbers of implementation classes with very little structure. Here the complexity exploded and the outcome was totally unmanageable. The most ambiguous and therefore the saddest expression that I know of this type was IBM’s San Francisco project. This was in the last years of last millennium and if I remember the figures right at some time there were 3500 classes and about 25 000 methods in it !!

SOA, talk about services and process modelling took the development backward at least 10 – 15 years and is still taking it share. I don’t know from which source the whole SOA came from but I think that it started from application server vendor and at least Web Logic was one of the early promoters. Today it can be found from major database vendors such as IB and Oracle.

Now I have a guts feeling that the tide have change again. With strengthening demands of lean and agile development the focus is moving to domain modelling again.

The best solution

The ADDD- approach in ideal case in an organisation leads to one single domain implementation that contains all the business functionality to mirror the organisations reality. Then there are a set of application that share the one and only domain core and build up from it to implements different workflows of organisation. This means that there is no separate integration layer but only one aspect of the domain implementation acts as an natural integration point.  This is theoretically the same approach the ERP-systems (like SAP) have. The drawbacks of current ERPs are that the implementations are quite old and they don’t have object solution.

The obstacles to achieve this:

1. Abstract domain modelling seems to be more difficult for many people than I anticipated. This means in many cases that the skills to create good abstract domain OO- models with proper domain behaviour.

1. Skilful people who can design and implement this are very rear today(well at least in Finland). Currently these people don’t form effective teams to really deliver what I have promised here.

1. Packet software vendors’ and a general attitude is of course that packet solutions are without an exception GOOD. Packet software is indeed very good if or when the user is 100% ready to adjust to use the software as it has been implemented. The more the user requires changes into the product the worse the situation grows. Clearly to worst case is a company trying to cover their application needs by requiring many independent software packages.  As we in the early days of IT (somewhere mid 80’s) hade silo application and gradually this caused multiple occurrences of same entity in different silos. This led to growing demand of integration. In the given situation and environment this is at last very complex and in most cases mission impossible. Now a collection of unrelated (and un-integrated) packages is actually worse silo effect than the old department silos. In spite of that there is still a stubborn belief that packet solutions are far better than tailor-made ones. In tailored solution without skilful OO-implementation this belief might be valid. Of course all packet vendors promote this attitude.

1. Actually the current ERP package solutions (like SAP) are implemented from the same domain model root ideas, but they are very old and they lack the OO-domain model. All this has resulted in a situation where the initial package has far too much detail and thus right from the start has a overwhelming load (in many cases completely unnecessary) detail.
2. When ADDD is adopted it means dramatically decreased amount of work compared to current situation. The industry doesn’t like to reduce the amount of work and really be far more productive. This will have a huge and even cumulating impact on the whole IT-industry. The industry would like to see more work not less!