Event Management model

Here is small and quite practical domain model of organizing different kinds of events – like congresses, fairs or festivals. All these events can have several parallel tracks and each track consists of consequent sessions. Sessions have a subject or a tittle and from one to several performers. The members of listeners or audience are called participants. A sessions is event-moment type of object and all different roles are connected to the event trough participation-events. Each participant has exactly one participation event to connect the person to the event. Participation’s state attribute in the event reflects the life cycle of that event.

SomeTime14

I am trying to implement this model in an event management application. The application will provide means to register to the event and then the application will confirm the registration if there is available capacity left.

I am implementing this with Python and I am currently testing ZODB oo-db with this. I am still looking for a web framework. In my first tests I used tkinter GUI. I like the lightweight but oo structure of Python. It remains me a lot of Smalltalk with it’s dynamic oo variable binding.

Let me train your developers in Object-Oriented paradigm and modeling

There is a lot of undeniable evidence of the high productivity of Object-Oriented paradigm.
The core of the reasons behind this is the simplicity of two layer structure of all activity.
When all activity is divide in two parts: the things that each participant achieve individually and what is the result of two or more individuals collaborating together.

The paradigm sift from procedural to OO in early 1990’s was a total discontinuation point. It seems that the huge majority of “the old school” veterans that had not enough training and resources to understand the hard core of the new paradigm and the poor new tools together caused the whole computing community to deteriorate back to the “golden age of algorithms”. This way we mentally retreated at least 15 years in software development methodology.

Today my guts feeling is that most application development projects are conducted in an extremely inefficient way. Thus those cost many time more than would be necessary.

Agile development is one step forward and an attempt to do things better but it deals most with group dynamics only and it requires strong methodological support from the professional side. OO is that counterpart.

Software developers should be much better of if they were not taught any 3G procedural languages and databases at all. All this stuff belong ti the past. Instead the should be taught domain modeling, object behavior and collaborating sets of object, object life cycle and persistence.

When a person has learned to develop a Java application in modern IDEs then it is not a big effort to learn the OO paradigm if one is to learn it at all.

I think that the current development teams should give their member a fair chance at least to learn to know the cornerstones of the OO-paradigm and the development method to be able to compare the methods and to decide them selves.

It takes only 2 – 3 days of on-cite training to open peoples eyes if that will happen at all.
I am most willing to give that training.

How to learn object-oriented domain modeling?

I have taught quite many people their first steps on their path to domain modeling ( more that 1000 persons).

These students have had very many kinds of backgrounds. More that have have been IT-people and majority of them have had high education in computing. The rest of them have been the becoming users of those target organization developing their applications. The education and profession among these people varies a lot. So I have very wide spectrum of experiences trying to explain what an object-oriented mode is.

The fundamental requirement to start the journey is the basic understanding of OO. These are “the rules of the game” like the basic moves of the piece types in chess. If you don’t know these you just can not play!

In OO the most fundamental aspect is the concept of object. Object is a “whole” is has to sides structure and behavior. In OO there is no behavior without at least one object. There is no action or behavior outside objects! If one doesn’t get this then there is no hope. It seems that there is small part of people, for whom this is too much or too difficult!

When one has accepted this, then the journey can begin. The first and most fundamental feature of and object is that they all are unique in the whole timespan of the universe. This fact is reflected in the identity attribute of an object. We could agree, that the ID attributes are never shown in the model but every class have one. It is also important that the ID attribute is not combined with and other natural attribute. The second thing that I always teach to my student is that all object has a life span. So what all objects have in common are birth and death. Actually in OO the biggest issue is how and why objects are born and die. When one masters this then the rest is really easy.

When we start to create an OO- model it is easiest and most natural start from static features and start to create class model. It is always easiest to start from concrete sustainable things like house or person.

When we start to create a class model with class diagram before drawing the first class box just list a few names of the most obvious class candidates. The very first crucial thing is the name of the class! I should always be chosen with care.

At this point one should also name a few ( 2- 6) most relevant attributes to give shape for the class with a brief description of class. In most obvious cases the description in unnecessary – like class Person, but if there is any doubt or the usage is in any way restricted then write the description.

Almost immediately after you have a few class in your diagram you should add all necessary relation between classes. Most important of these is association. These give the world semantic shape.

Now it is time to open up our example model. This is the simples possible model and I have used this for modeling trainings as well as for Java-trainings.

The domain is is a classical bookstore. The model will be quite abstract to keep it simple. Let’s start with very concrete classes. The fist one is a class that I have had in almost every model that I have done. It is Person- class. In this class belongs about 7 billion individuals on this planet. The other completely obvious class in this domain is Book. If we want to lift the level of abstraction we could have chosen the name Publication for this class also. I will use Peter Coad’s color notation in my UML- diagrams.

bookshopEnt

I have left the ID attributes out from this model.

When my students have worked with this model the Book class has proved to be somewhat confusing. The type of objects that belongs to my Book class here are the contents of the books. In concrete terms one could think that my book is actually the original manuscript of the book or the copyright of that book and not a single print or other kind of representative of that content. This is why I have an attribute inStock, which is the number of copies of that particular book in my shop.

The next thing to consider is perhaps the most challenging aspect of OO- modeling. Jim Rumbaugh described it: “objectified events”. This means that when OO model consists only objects and to enable us to include event also in the model, we have to change event to objects. Well there is no magic in this. Event/moment object is an object which is an abstraction of time slot. This means that every event-class has two attributes: start time and end time (sometimes this can degenerate to time). The color for moment/event is pink. More advance is to model behavior for this events.

bookstoreEvent

When we consider what are relevant events in our domain considering the business in this context. When I have asked this question from my students almost always the answer is purchase. Well this is really the most prominent event and right answer, but here is also an other not so oblivious but from the sale point of view more interesting event is Walk. This is an event that enclose the customer’s visit to the shop from the event of entrance until he arrives to the cash. Here are the two events:

The behaviors of a Walk object are for instance pickup a book, end the walk, return a book that has earlier been picked up. A purchase is responsible to carry out the transaction.

The last step with class model (and diagram as well) is to add all the relation between classes. In this case we don’t have any inheritance so all the relations are associations. The digest category of association between entity classes and collections. For this reason this type has a graphical notation (a diamond). An association between a entity object and an event object is almost always participation. So the associations in our model between entity objects and event object are participations and then there is an association between two events. The type of that is creation or “mother”. Here the walk object creates the purchase object. So our full class diagram is following:

BookShopClass

Now we move deeper into the dynamic of the model. The tool that we use is collaboration diagram. The name here is important because the diagram presents the process the sequence of action where a set of these objects in collaboration with each other achieve some important goal. Here the key process start from entering the shop and end at the payments of book bought. So this is the process that we have to cover and describe with objects. The steps in this process briefly: 1) entering the shop: the person object creates new walk object. When the person finds an interesting book and takes it with him: person object sends a message pickUp( the book) to the walk object. When the person decides to end the walk: The person object sends end() message to walk. This will create the purchase object and finalize the purchase.

bookstoreColl

Now our abstract object model for our bookstore is ready to launch the next step. These model are never finished but they are ready for advance. Modeling is both incremental and iterative process.

This process cannot be automated and there is no set of rules that would change this process routine or trivial.

This all means that it is quite easy to create some OO model representing reality, but the quality of the model can vary dramatically. To archive a meaningful abstraction that really help understanding the reality requires very high skill and experienced modeler.

The walk objects are actually the strongest tool for sales promotion. They can also give weak indications very early where the market is going. When I am giving my two day training after going though bookstore I will give the first exercise for my student. That is following: Create a model of library, so that it cover lending a book and returning it. The first question here is what is the most important event in this domain. In many cases the students quite well learn from the webstore and bring in walk event. But in the library model (at least if we think it is a public and free service like in Finland) the walk is a possible event in the model but of course the loan event is actually the most interesting one(and actually the only necessary event).

High productivity in software development

It is relatively easy to show that abstract domain model driven agile application development is at the absolute complexity minim within all know application development methods for von Neumann computers.

This means of cause that this is most productive way to do it.

This method starts with creating an abstract domain model for the organization from scratch. This activity can takes up to 15 working days from analyzing group but in average is less than 10 working days. The result is something that I call object-oriented abstract domain model. It consists of one class model (named classes, a few essential attribute, core business methods and all class relations: associations and inheritance trees).

This abstract model states the essential business process requirements in a very rigid object-oriented languages. This is actually the most compact and coherent presentation for these requirement.

The next step is to design the necessary work flows into GU-conversation that are based and supports the earlier created domain model.

The implementation follow the three-tier architecture, where the domain layer is completely separated from the rest of the code. The implementation start from selection the hardware and software platforms for this implementation. The next step is to generate the domain layer skeleton from the domain model. After this the implementation proceeds incrementally adding both application and domain behavior simultaneously. This all happens in close direction of product owner and the becoming user community.

The ratio of the code sizes between three layer are typically following. The domain layer including all business logic is between 10 – 20 % of the code. The size of persistence layer varies the most depending on selected db solution. This depend heavily on the environment. If one has several old databases behind the new solution, this will require substantially code between domain objects and databases. If one can use one new relational db, then one can use JPA framework and reduce this work. My favorite is object database, which end up with least work. So this layer can be from a few percentage up to max perhaps 40 %. The application will then fill up the 100%.

The model generation will create in average 50 – 90 % of the final domain layer code. So if your ready application consists of 100 000 lines of Java then the business layer take 20 000 lines and all business logic methods about 4000 lines.

I have published here business line abstract domain model. Still I insist on doing it “ from scratch”. The model I have provided here should be used to guideline the modeling and they can be used for jump start for a novice modeling group to avoid very drastic mistakes. The model is after all the hart of the system and its design. Its influence to the whole system is many time more important than its ratio in code lines.

In may next post I will tell my experiences on how to learn to analyze reality and create these models. When I start doing this 20 years ago I thought that this is very easy for all of us but I proved bitterly to be wrong in this!

Profile of my 2012 blogreaders and review

I will thank all my readers for yet an other year of your interest to my views and ideas on OO -paradigm and agile domain-driven application development.

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 11,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 18 years to get that many views.

Click here to see the complete report.

The Company – Innovation and paradigm change

These days it is very trendy to talk about innovation. Japanese agile development team based on their own judgment, and minor repairs. What happens if you really are innovative and offer a breakthrough?

My answer to this question is that your innovations is unequivocally thrown to trash bin if possible.

Let us look at this issue in more detail.

The first assertion is: Organization and their behavior is very much linked to the paradigm (the idea and model of the world), around which the company is once formed. The larger the size of the organization the more the paradigm defines the structure and behavior of the entire organization.

To understand this all of the concept of paradigm is completely essential.

Let’s begin with the concept of parsing form the Wikipedia’s description:

Kuhn was at pains to point out that the rationale for the choice of exemplars is a specific way of viewing reality: that view and the status of “exemplar” are mutually reinforcing. For well-integrated members of a particular discipline, its paradigm is so convincing that it normally renders even the possibility of alternatives unconvincing and counter-intuitive. Such a paradigm is opaque, appearing to be a direct view of the bedrock of reality itself, and obscuring the possibility that there might be other, alternative imageries hidden behind it. The conviction that the current paradigm is reality tends to disqualify evidence that might undermine the paradigm itself; this in turn leads to a build-up of unreconciled anomalies. It is the latter that is responsible for the eventual revolutionary overthrow of the incumbent paradigm, and its replacement by a new one. Kuhn used the expression paradigm shift (see below) for this process, and likened it to the perceptual change that occurs when our interpretation of an ambiguous image “flips-over” from one state to another.[4] (The rabbit-duck illusion is an example: it is not possible to see both the rabbit and the duck simultaneously.) This is significant in relation to the issue of incommensurability

I came across the concept of paradigm for the first time, when Peter Coad taught the very brand new object-oriented analysis in 1989 in Stockholm . He said that there is a paradigm shift from procedural analysis to object-oriented analysis

As an example of a paradigm shift and its impact on the business he used was the wrist watch industry. When the watches were built on fine mechanics based on cogwheel and metal spring, the Swiss watch industry was globally the sovereign leader of the industry. Then, the Japanese developed wrist watch based on quarts crystals electrical vibration. the Swiss watch industry just laughed at these “toy watches”. After ten years had passed, not chuckling anymore, when almost the entire Swiss watch industry was dead and quarts wrist watches dominated totally the global market.

It can be said that the ultimate paradigm is crystallized in a very simple point of view, or the finish line, and all the rest of the company structure and behavior can be easily concluded from this principle. Swiss watchmaking, this principle was a “cog wheel and the spring.” Another significant feature of the paradigm is that it is the outermost or overall pattern. This leads to the fact that the paradigms may be valid for only one at a time. Thus, if the paradigm is changed, then the new pushes the old away.

Other examples of paradigm shift and their effects. Like I said the new paradigm is usually overwhelming, so there is the old obsolete. When the steam engine was invented, and it was learned to use marine propulsion, this invention was replaced sailing ships in freight and passenger traffic, but the transition was long and with both “generation” of ships went side by side for a long time.

The current era of electronics is then created a phenomenon in which a company that is a leader in the world, launching an innovation process that leads to the paradigm shift, with the result that the transformation produced that was initiated by the company will die as a result of this. Impressive recent example of this is Eastman Kodak which was the leading developer and producer photographing techniques. Its core competence were the films and photographic paper and chemicals. Kodak Chrome was a concept that can be easily compared to the iPhone or iPad. Kodak Company began to develop a digital photography and digital storing of photos. It succeed to developed an electronic photocell-based digital camera. At that point, the company have had to literally turn their backs on all that knew and to continue aggressively forward with what the developer had created, the company management decided to continue with the world of old films and papers. Last year, this top successful company went bankrupt.

This is an example of this category is not the exception but the rule. I’ll try to describe it in the following logic, which is of such a chain of events behind. I am writing a separate story paradigm shifts within software industry and their consequences. These are mostly operating system changes and the are connect to the computer hardware industry. The computer paradigm shift is yet to come but it is looming behind a corner.

Let us continue our journey now with effects of the paradigm shift innovation in a company. I will create an illusory company to explain my line of thought. Let this be a local shipping agency called the PacketRocket.

The company operates in an area with a port and an airport (like London). The company’s operational idea (paradigm) is to carry packages on wheels from airports and ports to recipients and vice versa. This activity requires a number of company vans and / or trucks and drivers for these. These in turn require, as well as stables and service facilities. Maintenance facilities require a number of skilled car mechanics, to keep the equipment in running order. Function may also be required have company’s own storage space for intermediate storage. If the storage has been decided to maintain, this requires a personnel responsible for this. The management and coordination functionality needs an office and staff, which will market the service and actually carry goods from order to invoicing.

Now, let us make a paradigm shift in our company. The company’s operations does not work, and management has decided to take airplanes to carry stuff instead of cars. This is a clear paradigm shift. As a result, all acquired auto transport infrastructure is unusable. The same thing happens to most operational staff. Vehicle maintenance staff, and the drivers are unnecessary. These persons can not in practice be able to be retrain for new tasks. It remains to be asked what is left of the original company or is it really about stopping one company and starting an another?

Summary.

The company when created actually creates a ecosystem around core paradigm it. This is how all operational processes, infrastructure, job roles and competencies consist of from this paradigm and support it. Now, a radical innovation, which often means simply paradigm shift set completely new standards for all the above, and this is how it practically kills the company acting. For this reason why any company naturally rejects any attempt – perhaps largely unconsciously – to a change especially those “dissidents” whose ideas begin to sound to be viability.

Objects before behavior … continued

Now I have to define or limit the scope of application. I am here talking about enterprise operation management applications. The application that the companies support or run their businesses.

 

The hard core of programming is complex management. When one must keep track of business processes then OO is at least one magnitude more effective that any functional or procedural of course with the assumption that the coding is correctly produced!

 

The overall complexity can be divided in two subparts. Local complexity and its global aspect. A given domain functionality has a given intrinsic complexity. Here the local complexity is inversely proportional to its global part. This means that when one decreases local complexity at the same time one does increase global one. I have used APL programming language. It is an executable matrix algebra syntax. It was locally extremely complex – compact. The difficult with that was that only 10 % of Cobol programmer had any chance understanding it, but in hands of a master it was frighteningly powerful and productive.

 

Local complexity is easy to recognize because it can be seen in one o two pages of code but global complexity is insidious because it is really difficult to detect. This complexity steams from purely from number of combinations. The procedural languages gives too much freedom for programmer which ends up a mess.

 

This is why object with their association gives an almost isomorphic mapping from reality and thus enables to implement each behavior at most once. Their blessing is the restriction the put to a programmer. As I earlier said the prerequisite of this is that the development is done model driven and the implementation is strictly 3-tier. This meas that the application layer ( GUI , GUI- interactions, work flow control) is strictly separated from domain layer and business functionality.

 

I actually deeply understood this after reading Stuart Kauffman’s: Home at the universe. (http://www.amazon.com/At-Home-Universe-Self-Organization-Complexity/dp/0195111303/ref=sr_1_1?s=books&ie=UTF8&qid=1349817326&sr=1-1&keywords=at+home+in+the+universe+by+stuart+kauffman )

 

I warmly recommend this to all that truly.

Then when we consider really complex processes from reality, not only mathematics then the von Neumann architecture is not enough. For this reason big player have already for some time been developing new computing machine architectures that are simulating neurons and brain. ( see: http://www2.dac.com/events/videoarchive.aspx?confid=122&filter=keynote&id=122-120–0&#video )

 

Finally here is little bit more on complexity: https://jukkatamminen.wordpress.com/2011/08/01/managing-complexity/