The state of OO -development in 2017

I have started this blog on OO application development in 2009 and posted the last post on this issue in 2014.

The core of my approach is centered on abstract domain OO – model. To created these models one needs deep understanding of the underling theoretical concept. This can not be achieved just following a set of rules. The divider is the abstraction level and thus the model size. If the abstraction level is too high the model has no value. It dos not promote the understanding of the domain. If the abstraction level is too low, it is even worse because too much detail prevent the possibility to separate important from unimportant and the just isn’t a way to return. So too detail model poisons the whole process.

A just right model create a great opportunity not just a good and flexible domain implementation but also for user interface part of the application, because early separation of concerns will dramatically reduce complexity of both sides.

I started to write the posts at late 2009. It has gathered 48 000 hits all together. I have posted my last OO article early 2014. The OO did not concur the world as I and Gready Booch predicted around 1995. For this reason I am gladly surprised the current hits at my blog currently. For most of the time my readers came from US, Canada and India, but almost the whole world was covered.

I have retired 3 years ago and I don’t have a hands on touch in the current development trends. My current surprise is the activity around my blog in 2015 and 2016 there were about 4300 views and 2000 visitor yearly and most visitor came from US, Canada and India. Even this year there has been about 1000 views and 580 visitor from the same countries. I am both happy and honored about this.

I would be curious to know the motives for these visits and the current state of OO development in the field.

Advertisements

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!

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/

Objects before behavior – the most fundamental OO concept.

There has been for some time now at least some debate about functional languages. These are declarative in nature. In these the actual processing is defined by describing the logical predicate that the result must fulfill. Thus this brings the computing near mathematics. I have seen many times attempt to declare that computing is mathematics. Most probably one can do mathematics with computers but computing (ie. programming of application) is very far from any mathematics.

My viewpoint to computing is business operation control. In other words the company’s application portfolio reflects the state on the reality within the company and gives to the worker of the company a possibility to monitor and manage the business actions. In this domain – that actually is the great majority of all IT of companies – the amount of complex computing is non-existent. There are also some complex calculation done somewhere but I am not familiar with these but here we are talking about complex calculators.

When I teach the basics of OOA, I will start with looking how we perceive the world. Well here is the core of that:

The reality, the whole world consist purely of material things that we can generally call “objects”. ( see. The first few page of Ludvig Wittgenstein: “Tractatus Logico-Philosoficus”). So everything is object and there are layer of objects within objects. This way the concept is highly abstracted and gives us the intersection of what is the smallest common denominator in the reality. What is the common thing in all objects? The answer is uniqueness of objects. We all are unique this is materialized by a common attribute: ID. To the uniqueness is loosely connected the fact that there is no object in the whole universe that is eternal. So every single object is bound by the time. The consequence of this is the every object shares two attributes: time of birth and time death. This way every object is created and destroyed in one way or an other. In an OO model these basic facts are reflected in class model. A life of on object is a continuum of state transitions – the states that are realized as values of that objects attributes.

Now we get to the issue. All action or behavior is always performed by someone or something. So every action has a subject – ie. someone behind the action – an actor.

OO- paradigm uses this fact very effectively. In OO there are no unbound action, function or other behavior. The realty is modeled by two types of behavior: internal and external. Internal is behavior that a single object produces and external behavior can be called collaboration. Well of course this requires that a fight of what ever type between objects is one kind of “collaboration”. Collaboration is objects internal action and messaging between objects.

SO when we try to mirror some part of local reality the minim complexity is achieved with this kind of one–to-one mapping (or homomorphism if you want to put it into mathematical terms). In this kind of implementation every function is implemented at most once. This is never the case if all the behavior is not bound in objects. Of course you can break this role also with object if you want, but it is easier to detect to be avoided. This yields absolute minim complexity solutions within von-Neumann machines.

On other finding after creating a few of these is that the business method within the business object are almost without an exception stupidly simple. If one is looking for really complex behavior it includes learning and it can not be ever achieved with von-Neumann machines but needs a neuron based architecture ( see:

http://www2.dac.com/events/videoarchive.aspx?confid=122&filter=keynote&id=122-120–0&#video )

Art of programming – the ultimate design expression of an application

The programming languages that I myself have programmed with are in chronological order: Fortran, Cobol, Pascal, APL, Smalltalk and Java. The one that I have been write real production code are: Cobol, APL, Smalltalk and Java.

 I don’t know how many languages there actually exists. There was a presentation at JAOO- conference in Århus Denmark 2008 named “50 in 50” by Righard p. Gabriel and Guy L. Steele Jr .They went trough 50 programming languages in 50 minutes.

 Thus the only common thing over all these languages is that they can be either compiled or interpreted to executable machine code.

 Then there are two categories of programming languages: procedural and object-oriented. The categories also form both chronological and evolutionary layers. Most procedural languages have been created before 1980. The transition is not sharp but gradual but ParcPlaces Smalltalk-80 is a watershed or marker. This was also a fundamental paradigm change.

 Procedural languages are primitive syntaxes to facilitate expressing of algorithms. The thinking behind OO- languages are fundamentally different. In these the behavior is design as a seen with actor call “objects” and the total behavior is a mixture of various objects internal activity as well as their external activity: collaboration with each other by messaging. I like to emphasize here the concept “collaboration”. This is substantially more that the term “communication”.

When I after doing about half a year OOA got my first Smalltalk environment at first it was really hard to overcome the procedural thinking even as I was very aware the theoretical OO concept.

My production Smalltalk was ParcPlace’s VisualWorks. It was actually an Smalltalk programming environment not just an interpreter and how we learned to love it. It was just fantastic compared to anything I have worked with earlier. This was around 1995. Then came along Java, which was in its infancy. I was furious. When we finally had to switch over we almost concretely stepped back 5 years! Todays Java IDEs like Eclipse are fairly at the same level where Smalltalk was 1997.

When I consider OO -languages they are fro me just dialects of Smalltalk. The core language syntaxes have only some cosmetic differences and actually the real differences come from class libraries. These are not part of language but part of environment. So I would say that Java,C+,Objective C and Eiffel is a dialect of Smalltalk. Scala, Rubi and C# are dialects f Java.

The sad thing is that too big portion of the people programming with OO- languages does know too little or no the underlying OO- theory and thus uses it very poorly. When we were using Smalltalk, at first I thought that the language itself prohibits programming procedurally. The I attended a Smalltalk conference where a Smalltalk guru told us that he has come across first procedural Smalltalk program. It actually had a call with name MainProgram! I was both terrified and furious!

The three gems of software development

Buddhists talk about Three Gems:

  • Buddha: the enlighten one
  • Dhamma: teaching
  • Sangha: literally means ‘community’ or ‘assembly.’

Here are similar thing for Object- Orientation. The difference is the later are strictly non religious, but there in spite of this some similarity and that is the belief in one’s own case. These are:

  • The paradigm
  • The abstract business model
  • The agile incremental 3-tier application development

The paradigm: To know and understand the OO- principles and also to understand it paradigmatic nature. This means that the world is perceived abstractly as a set of objects such that:
* all of them have two aspects: structure ans behavior

* they can collaborate with ease other

* there is no other kind of action possible in the world

The abstract business model: The development has to be started with creating an abstract domain model from scratch. Of cause one can use for this something like the business line models as I have presented here as a starting point. But even then every class have to be evaluated and checked that it is defined to this company and describes the current reality correctly. The model have to have all essential business behavior embedded in the model. The most important aspects in the model are objectified events, there behavior and object associations.

The agile incremental 3-tier application development: To succeed in this phase is crucial.

To continue this line of simplicity the architectural structure is the final cornerstone of this application. The maxim simplicity is achieved when the implementation keeps the three aspect: 1) application functionality, 2) domain functionality and 3) object persistence as separate as possible. Here a must is that domain objects have no functional references anywhere outside the domain itself. There are minimal references from application layer to into the domain. And the domain objects should have one references each to outside service that provide the persistence. The optimal solution would be such that the object virtual machine provides that service automatically into an object database.

This is the final phase to really deliver the concrete application. Next important aspect is to create the application incrementally and iteratively. One mustunderstand that the abstract domain model from previous steps is more of a starting point than end result which will grow in size during the development. On the other hand it is vitally important the first model is relatively small and thus will clearly describe the most important structures and behavior. This means that this model should have most of the structures present ie. most classes and associations are present but major part of attributes can still be lacking.

Done this way yield to minim solution thus minim amount of work and this enables indirectly maxim quality through simplicity.

The most is achieved when the model covers all activities of the company and the application layer is a comprehensive operation management and control of the company ( like ERPs today)