Inleiding

Een veelgehoord misverstand over object-oriëntatie (OO) is dat het een methode voor systeemontwikkeling van computersystemen is. Ik merk dat het steeds weer nodig is dat idee omver te halen.

OO is niet een methode voor systeemontwikkeling. Het is een taal om complexiteit hanteerbaar te maken. In essentie zou ik willen zeggen: het is een taal die gemaakt is voor complexiteit.

Complexiteit is een begrip dat betekenis heeft gekregen door twee ontwikkelingen in de wetenschap:

1. Chaos theorie
2. Complexiteitstheorie

Chaos theorie is verantwoordelijk voor de ontdekking dat werkelijke chaos in natuurlijke systemen niet bestaat, maar dat interne cohesie verantwoordelijk is voor orde op een hoger niveau. Eén van de verhalen uit de chaos theorie is dat het slaan van de vleugels van een vlinder in China een minuscule variatie is in de set van condities die uiteindelijk leiden tot een orkaan in Florida.

De complexiteitstheorie, ontstaan met name vanuit het Santa Fé instituut, maar waarvan de wortels teruggaan tot Gregory Bateson en de cybernetica (de oorsprong van de computerwetenschap ligt in de cybernetica, de wetenschap van terugkoppeling en sturing, tot mijn grote verdriet een link die bij de meeste van mijn collega's in dit vakgebied totaal onbekend is), is verantwoordelijk voor een theoretische onderbouwing van systemen die analytisch niet meer te beschrijven zijn.

Het begrijpen van deze systemen heeft behoefte aan andere metaforen dan de wiskundige, en zeker andere dan de werktuigbouwkundige. We hebben het over de invloed van metaforen op het denken van de mensen die met deze zaken willen werken. Die invloed is aanzienlijk. Verouderde metaforen bepalen nog teveel de manier waarop we tegen de wereld aankijken. Wat studenten leren op de universiteit is afkomstig van een wereldbeeld uit de tijd van de stoommachine.

De bekende Von Neumann architectuur is gebaseerd op deze visie op de computer als een soort stoommachine. We zien computers als stoommachines! Alleen al de term automatisering maakt het moeilijk de verregaande effecten te kunnen realiseren die de computer mogelijk maakt. Het zijn de bekende handelingen die we al jaren en soms zelfs eeuwen doen die we gaan uitbesteden aan machines: we automatiseren datgene wat we al deden. Het is dan heel moeilijk om te zien wat er voor dingen mogelijk zijn die we nog niet deden.

De meest ingrijpende veranderingen die de ontwikkelingen in de IT zullen bewerkstelligen in de moderne maatschappij, en de wijze waarop organisaties en markten functioneren, beginnen zich nu af te tekenen. De oude specialisaties van customer intimacy, time-to-market, cost-effectiveness beginnen in elkaar over te lopen in een nieuw begrip: the one-person market. De directe relatie die klanten nu kunnen hebben met leveranciers door het web, zal alle gangbare relaties tussen bedrijven en hun markten omver gaan gooien.

Nieuwe metaforen zijn dus nodig om ons te helpen met deze nieuwe ontwikkelingen om te gaan. Ook zaken als de ethiek van vernieuwingen door deze metaforen. Waar moeten deze metaforen vandaan komen? Wie leveren ons deze metaforen? Hoe om te gaan met (onverwachte) zij-effecten (lees: Waarom Software terugbijt)?

De metaforen voor het beschrijven van complexe systemen kunnen we het beste halen uit de biologie en de filosofie.

De biologische metafoor

Waarom de biologische metafoor?

Een waarneming die we kunnen doen is dat biologische systemen van een ontzagwekkende complexiteit kunnen zijn zonder dat iemand achter de helpdesk zit om problemen op te lossen.

In 1964 is een boek verschenen van James Watson, de co-ontdekker (samen met James Crick) van het DNA. Dit boek was een monografie over een cel, een coli bacterie van een soort waarvan er miljoenen in onze darmen voorkomen. Als we deze cel bekijken in termen van complexiteit, dan kunnen we een aantal waarnemingen doen.

Ten eerste bestaat de cel voor het grootste gedeelte uit water — informatietechnisch lijkt dit weinig interessant. De interessante aspecten bevinden zich met name in de eiwitmoleculen in de cel. Als we deze zouden uitdrukken in termen van computerkracht kunnen we de informatie in deze ene cel uitschrijven in 10 zware werkstations (2014). De snelheid echter waarmee deze informatiehoeveelheid wordt gemanipuleerd binnen een cel is ontzagwekkend. Ter vergelijking: zouden we de eiwitmoleculen opschalen tot de grootte van een Volkswagen, dan verplaatsen ze zich voortdurend met een snelheid van 4 maal die van het licht. De chemische interacties vinden plaats met een heftigheid die we ons niet kunnen voorstellen. De complexiteit is ook nauwelijks te meten — de enige manier waarop we de cel kunnen onderzoeken is door het dood te maken. Waarmee veel chemische activiteit stopt …

Biologische systemen in het klein (zoals cellen) en in het groot (zoals ecologische systemen) hebben een groot aantal eigenschappen die beschreven zijn en waar we binnen de IT ons voordeel mee kunnen doen. Een belangrijk vakgebied doet onderzoek naar complexe adaptieve systemen, dat zijn systemen die zijn ontworpen aan de hand van deze metaforen. Veel van deze systemen zijn niet OO. Het is mijn overtuiging dat het huwelijk van OO met complexe adaptieve systemen en kunstmatige intelligentie (intelligent agents bijvoorbeeld) kan leiden tot een nieuwe golf van veranderingen in de IT.

De computer revolutie

Een tweede overweging die ik graag mee wil geven is het feit dat de computerrevolutie nog niet heeft plaatsgevonden, zoals Alan Kay, de uitvinder van OO, regelmatig verkondigd heeft.

Wat dit inhoudt kunnen we bijna dagelijks ondervinden: veranderingen gaan zo snel dat we niet meer in staat zijn erin mee te gaan. Dat is een zeer begrijpelijke situatie. Geld en mankracht zijn niet voldoende om een vakgebied of een uitvinding tot wasdom te brengen. Daar is ook tijd voor nodig. Die tijd is nodig om heuristieken te ontwikkelen, om de consequenties (in positieve en negatieve zin — in maatschappelijke, psychologische, technische enz. zin evenzeer) te leren kennen. Dit is trouwens ook begrijpelijk vanuit de complexiteitstheorie zelf: nieuwe technologische ontwikkelingen veranderen de omgeving, die weer terugkoppelende effecten heeft op de technologische ontwikkelingen zélf.

De computerrevolutie heeft die tijd nog niet gehad. We zitten nu nog in een tijd waarin veranderingen zich zo snel voltrekken, dat het weinig zin heeft te investeren in technologische oplossingen op een wat langere termijn. Deze zullen immers binnen enkele jaren alweer verouderd zijn!

CBD en SOA

Momenteel is er veel belangstelling voor CBD (Component-Based-Development) en SOA (Service Oriented Architecture, in het Nederlands SGA: Service Gerichte Architectuur). Met name bij het management is het eenvoudig hiervoor de belangstelling te wekken, omdat het inspeelt op vraagstukken die al jaren spelen. Alweer heel wat jaren geleden verscheen Byte magazine met een slogan op de omslag: “Why Object Orientation has failed”.

De teneur van het artikel was zeer begrijpelijk en kan mede verklaren waarom deze belangstelling zo groot is. Er werd gesteld dat OO al jaren beweert de techniek te zijn om herbruikbare componenten te ontwikkelen, maar dat een markt voor deze componenten maar niet van de grond komt. Dit in tegenstelling tot een grote en sterk groeiende markt van herbruikbare (en gebruikte!) componenten die niet volgens het gedachtegoed van OO zijn ontwikkeld, namelijk de Visual Basic componenten. Talloze kleine en middelgrote bedrijven floreerden in deze markt van VBX’en, OCX’en, ActiveX’en en later Java Applets. Deze componenten waren niet of nauwelijks OO ontwikkeld.

Het artikel verscheen op een opportuun moment, want de situatie was drastisch aan het veranderen. Een jaar later had het artikel niet meer geschreven kunnen worden, want een sterk groeiende markt van niet alleen kleine en middelgrote, maar nu ook grote en zeer grote bedrijven waren zich aan het positioneren op de markt als componentleveranciers van OO componenten.

Toch is de kritiek niet terzijde te vegen.

De volgende stap in Responsibility-Driven Design

Ik ben een cola blikje. Het doel in mijn leven is simpel: mezelf verkopen. Om dit voor elkaar te krijgen kijk ik om mij heen en ik zie een aantal elementen.

Ten eerste heb ik een gevoel van eigenwaarde. Dat wordt enigszins tegengewerkt door een element in mijn omgeving dat zijn eigen doelen heeft waar ik geen weet van heb, en dat mij af en toe onder druk zet om mijn waarde te verlagen. Ik heb geen idee waar die noodzaak vandaan komt, maar dat element (laten we het “marktaandeel” noemen) weet mij aardig onder druk te zetten!

Gelukkig heb ik heel wat wapens om in de strijd te werpen. Zo heb ik bijvoorbeeld een gezicht. Geen gezicht denk je misschien, een cola blikje met een gezicht, maar dat is heel nuttig, een gezicht. Een gezicht kun je vragen om er sexy uit te zien, en dat heeft weer positieve invloed op de verkoop.

Om mijn doel in mijn leven te bereiken maak ik gebruik van welk element in mijn omgeving dan ook om het voor elkaar te krijgen. Zo gaat er wel eens iets fout: een element waarvan ik dacht dat het zonder haperen functioneerde blijkt plotseling niet beschikbaar te zijn. Laatst nog, een klant wilde betalen met een chipcard. Blijkt dat de kaartlezer kapot was.

Vervelend natuurlijk. Ik stelde nog voor om cash te betalen maar dat wilde de klant niet. Een klant stel je niet teleur. Het was ook nog een warme dag, en bovendien (dat kon ik op de chipcard zien) was de klant een lid van mijn primaire doelgroep, een jongeman van 18 jaar. Ik besloot dus om mijzelf gratis weg te geven. Goede reclame. De investering werd ook door “marktaandeel” goedgekeurd dus ik had ook nog enige back-up. Daarna werden nieuwe klanten natuurlijk gewaarschuwd voor de kapotte chipkaartlezer (door de chipkaartlezer zelf, die ook via Internet het onderhoudsteam had gewaarschuwd, maar dat zijn zaken die buiten mijn scope vallen natuurlijk).

In bovenstaand sprookje probeer ik aan te geven op welke wijze een model dat gemodelleerd is rond verantwoordelijkheden in staat is te reageren op zijn omgeving. Dergelijke modellen zijn een stuk simpeler in onderhoud, en eigenlijk is een verder doortrekken van dit model een model dat “zichzelf onderhoudt”. Maar dat is een onderwerp voor een later hoofdstuk.

Een dergelijk model is ten eerste niet use-case driven ontstaan. De structuur is een resultaat van responsibility-driven-design.

Handvatten

Om het voor elkaar te krijgen in deze veranderende wereld overeind te blijven, zijn er enkele handvatten waarvan we gebruik kunnen maken.

Gebruik OO als een taal. Gelukkig is deze aan het standaardiseren: UML bevat voldoende syntax en semantiek om als expressiemedium te dienen voor OO. Extensies voor de taal komen voort uit de frameworks, de daarin gebruikte patterns etc. Het is deze taal die als communicatiemedium dient, niet de code of de executable!

Gebruik OO niet als een taal. Een veel voorkomend probleem ontstaat wanneer ontwikkelaars met gebruikers, opdrachtgevers of klanten denken in OO taal te kunnen praten. Dit werkt niet. Class diagrammen, sequence diagrammen en dergelijke zijn niet begrijpelijk voor niet geschoolde mensen. De truc is veeleer dat de ontwikkelaar deze diagrammen gebruikt terwijl hij/zij met de klant praat. Voor een domein deskundige is dan de illusie compleet dat hij op een inhoudelijk niveau een gesprek heeft. De ontwikkelaar heeft het OO model als een referentiemodel dat hem daartoe in staat stelt. Wij gebruiken een zeer effectieve techniek die helpt om business mensen aan te laten haken, genaamd eXploratory Modelling Explained. Zie ook: The Need for Clarity.

Leg de nadruk op domein modellen. Als we zien waar veranderingen zich het meest voltrekken, is dat in zaken als persistentie, communicatiemedium, GUI. Het domein model blijft relatief het meest stabiel. Investeringen hierin kunnen gezien worden als van strategische betekenis voor het bedrijf. Tools die het clean-room ontwikkelen van domain modellen bemoeilijken of teveel beïnvloeden moeten dan ook niet gebruikt worden.

Goede modellen zijn niet use-case driven. Een domein model is een model dat dient als onderliggend stratum voor een verscheidenheid aan toepassingen:

1. Business modeling en (re-) engineering
2. Systeemontwikkeling
3. Strategische scenario sessies
4. Business simulaties

Om deze modellen herbruikbaar te maken in deze verscheidenheid aan contexten is er geen enkele motivatie om use cases te gebruiken. Deze zijn teveel toegespitst op systeemontwikkeling, en de vraag van gebruikers en klanten in een tijdelijke context. De onderliggende modellen moeten aan veel zwaardere eisen voldoen wat betreft scope.

Goede modellen zijn use-case resistant. Een model dat overeind blijft onder de "aanvallen" van use-cases, bijvoorbeeld use-cases die zijn opgesteld in het kader van een requirements analyse, is een volwassen model.

Bronvermeldingen

Voetnoten

Zie MITCH. Dit boek is een uitstekende inleiding in de complexiteitstheorie.

Zie BATES1. Hij is de uitvinder van de cybernetica. Bateson’s betekenis voor de moderne IT wordt ernstig onderschat. Hij heeft in zijn artikelen handvatten gegeven om het aloude probleem van de dichotomie tussen vorm en proces op te lossen (nl. synthese op een hoger abstractieniveau). Dit probleem speelt in de IT voortdurend, bijvoorbeeld in de discussie over use-case driven vs. responsibility-driven design. Zie ook Waarom Software terugbijt.

Zie NEUM. Geeft een goed inzicht in de overwegingen die hebben geleidt tot deze computerstructuur.

Zie KAY1. Deze speech fungeerde tevens als podium voor de presentatie van Squeak, het nieuwe project van Alan Kay en consorten waarin een nieuwe vernieuwingsgolf in de IT werd vormgegeven. De laatste incarnatie van dit project is Pharo (zie www.pharo.org)

Zie BYTE1

Zie KORSO.

//ws-na.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&OneJS=1&Operation=GetAdHtml&MarketPlace=US&source=ss&ref=ss_til&ad_type=product_link&tracking_id=httpwwwsepher-20&marketplace=amazon&region=US&placement=0226039056&asins=0226039056&linkId=SOZ37QAZBKC7ONJO&show_border=false&link_opens_in_new_window=true//ws-na.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&OneJS=1&Operation=GetAdHtml&MarketPlace=US&source=ss&ref=ss_til&ad_type=product_link&tracking_id=httpwwwsepher-20&marketplace=amazon&region=US&placement=1572734345&asins=1572734345&linkId=3XN74Y2YRSW5BIOY&show_border=false&link_opens_in_new_window=true//ws-na.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&OneJS=1&Operation=GetAdHtml&MarketPlace=US&source=ss&ref=ss_til&ad_type=product_link&tracking_id=httpwwwsepher-20&marketplace=amazon&region=US&placement=0553345818&asins=0553345818&linkId=HXC2QRG3QD3QVE4L&show_border=false&link_opens_in_new_window=true//ws-na.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&OneJS=1&Operation=GetAdHtml&MarketPlace=US&source=ss&ref=ss_til&ad_type=product_link&tracking_id=httpwwwsepher-20&marketplace=amazon&region=US&placement=0671872346&asins=0671872346&linkId=D34VQ6LGGU2G6OAI&show_border=false&link_opens_in_new_window=true

This question was asked on Stackoverflow and ModelingLanguages and prompted me to attempt to make some persistent preconceptions about UML clearer. First of all: UML is not about modelling object-oriented software.

Origin of object-orientation

But maybe we should go back to what object-orientation is. OO (shorthand for object-orientation) is invented around 1970. Xerox had a group called the Software Research Group which was part of a think tank created to do research into the possible threats of the modern computer for Xerox's prime business: copying machines. This group invented in a short period of years almost everything around what we now call the modern computer: displays with bit-mapped overlapping windows, a keyboard with a mouse to manipulate the objects on the display, icons to represent various types of information, and even the network to link all those computers together called ethernet.

To create the complex software that was needed to run those personal computers, an object-oriented programming language, as well as by the way an object-oriented operating system, was deemed necessary. Alan Kay originally coined the term "object-orientation" although he later stressed that a better term would have been "message-oriented" since he envisioned a complex system of interacting elements creating complex behaviour by sending messages to each other.
For more info on this original vision please read the august 1981 Byte magazine devoted to Smalltalk.

The assumption was that we needed a powerful new way of thinking about problems, to enable creating multiple orders of magnitude more complex software. But you see, this was not just about software. It was about a paradigm that helps in managing complexity. OO was just that, and it still is.

Origin of UML

When the UML effort started it only tried to merge a multitude of approaches that helped in visually representing those OO programs. So UML is not so different from OO. It is just a view on the same thing: a complex system.

UML introduced something new, however, and that was the meta model. Mainly for the tool developers, this meta model helps in designing the power of the OO modelling paradigm itself. It defines classes and metaclasses, properties and associations (as access paths for message passing).

The metamodel of UML is extensible. You can extend the metamodel with Profiles, effectively creating a specific set of language elements with a tightly defined semantics for a specific problem domain. This should not be confused with Domain Specific Languages (DSL's), because a DSL specifies a set of elements or building blocks in the domain, for example the financial domain. A UML Profile contains the semantic definitions of the syntax used to describe those domains. For example you might create a Profile for Entity Relationship modelling. And you might define a Profile for functional languages.

Object-oriented mathematics

One of my first endeavours when I learned object-oriented programming was to create a planetarium. This has been a hobby of mine all my life. To simulate the movements of bodies in the solar system a mathematical model is used. The orbit of, say, the moon can be described with an equation with a lot of variables (to approximate the orbit, since there is no analytical solution of the many body problem in physics, that is until recently). My first thought was, well this is mathematics, I probably will have a hard time moulding the mathematical equations into objects and methods and messages. But to my delight I found this was not the case at all. Once I realised that my problem domain was mathematics, and specifically equations, the follow-up was easy and everything fell into place perfectly. I had Equation objects, CelestialBody objects using those to tell their location, and time nicely proceeding helping the celestial bodies to move.

To summarise: object orientation, and UML as a domain-independent language, can be used to describe any problem domain efficiently, and help with the complexities in those domains. And you are free to implement your solution in an object-oriented language like Smalltalk, or a functional language like Haskell. OO is domain-agnostic, and implementation-agnostic.

A recurring discussion is about the intuitiveness of object-orientation and its perceived complexity. Articles in authoritative magazines like the ACM Communications are also wrestling with this "intuitiveness".

This article struck me as especially interesting because it involved a multidisciplinary approach involving cognitive psychology, in particular the Dual-Process Theory, to research the thinking processes of object oriented modellers.

First a little about the Dual Process Theory. I found it quite interesting to see it mentioned here in this article, because it relates to several researches I have done in the past, in particular the theories of Gurdjieff which influenced me heavily. I got in touch with Gurdjieff's ideas, like most people, by reading a book by his best known pupil, P. D. Ouspensky, In Search of the Miraculous, in which Ouspensky describes in an autobiographical style his encounter with Gurdjieff.

Another book by a Dutch psychologist, Peter Warnaar's Psycho-Analysis of Altered Consciousness (Psycho-analyse van de bewustzijnsverandering) based on this his theory of three "kinds" of thinking:

1. Mental
2. Emotional
3. Physical

As Gurdjieff explained it, these three kinds of thinking have completely different "speeds", with mental, rational thought being the slowest, and emotional and physical each an order of magnitude faster. In the context of dual-process theory my interpretation is that mental thinking would be analogous to System 2 or S2 thinking, and emotional to System 1 or S1 thinking.

Now back to the subject of this article. The research reported several examples of hasty, almost automatic, design decisions done by the S1 thinking processes in designers (the group researched consisted of designers with 2-12 years of experience in OO). The first example in the article is about Confusing the direction of inheritance. The second, a little more revealing in my opinion, was about Difficulties in identifying objects. A small class diagram was provided:

This is a very elementary class diagram, but already it is revealing interesting thought processes.

The client logs in, the server validates the user. This is completely "intuitive", almost a transcription of our natural language way of describing the process.

There is a discussion between two participants working on this model. Both exhibit S1 thinking, but each has a different approach.

One, called Ron, is convinced Login and Register should be modelled as objects.
The other, called Sharon, has problems with his proposal, because it "feels not good".
Both have considerable difficulty expressing their reasoning.

Ron assures Sharon: "don't worry, it will be okay". And Sharon complains about how it feels to her.

However it creates complexity where it does not need to be. The Active-Passive pattern has not been applied. What would be the result of applying this pattern?

The method ValidateUser would have been placed in the Client class: the client is responsible for validating himself – this would make the server simpler (almost only a container of users).

I assume this would feel ok to both Sharon (it is a method) and Ron (it is a cohesive set of responsibilities).

The validation process itself would be a candidate for delegation: create a Validation class that is private to the Client to do this. This is a reasoning process which is seldom taught at schools and universities, or on courses in OO. However it is extremely simple and would help in providing both Ron and Sharon with a firm foundation for both S1 and S2 thinking – because I am convinced only the seamless cooperation between the two (or as I see it, three) modes of thinking result in high quality models that reap the benefits of the power of object-orientation. Benefits that I fear I must conclude, are hardly never reaped because of fundamental misconceptions about the nature of OO, and a widespread ignorance about what OO actually is.

To conclude, I think that being aware of the different modes of thinking can be very valuable in learning OO or for that matter any method or theory. Also I have argued elsewhere that there may be "tricks" or mnemonics that can help in bridging the gap between these modes of thinking. Finally, the fact still remains that internalising knowledge (which is the path to wisdom, or in the case of modelling, mastery) is a lot of work and requires time, effort and talent.

The essence of OO can be summarised in two statements:

1. Active/passive rule
2. Demand-chain cooperation

This article introduces these two important and undervalued patterns.

The Active/Passive rule

This rule can be summarised as follows:

This is only a trick. Many modellers have stated that the object-oriented model is a representation of the real world. This is true, but not entirely. And the model differs from the real world in exactly these two essential characteristics. The active/passive rule turns behaviour around.

There is a strong synergy between this rule and the next, because the way we should couple objects (or services for that matter) is based on first modelling objects active/passive, and then thinking about which responsibilities we would like to delegate to them. This way service interfaces are created that realise exactly what we want: loosely coupled, maximally cohesive systems.

An important rule is that "external" objects, usually modelled as actors, are modelled inside the system as normal (but passive) objects. This way it is clear and unambiguous what entry points there are for the external world into the software replica of this world. Modelling these objects as passive avoids the pitfall of modelling complex objects that are hard to understand and even harder to modify. All aspects of these complex objects in the real world are externalised into active objects. An example: a person uses a pencil. In the real world the person is active, the pencil is passive. In the software replica model we turn things around: the person becomes passive, and almost void of complexity. The pencil becomes active, and all behaviour corresponding to writing is delegated out of the person into the pencil. And even then, if the pencil becomes too complex, we use the rule of delegating responsibilities to make each of the active objects so simple that only one responsibility remains - all else is delegated away into other active objects. The resulting network of cooperating objects is complex as a whole, but simple when zooming in. The net result is a network of objects that is easy to manage.

The demand-chain cooperation

This rule can be summarised as follows:

Again, this is only a trick. There is no other way to reach the goal of loosely coupled objects, which cooperate to accomplish complex tasks, which can scale in time to become more and more complex. Objects perform tasks as a result of the responsibility delegated to them. When the task has been designed following a supply-chain process, this task is too tightly coupled to the requestor or delegator. The process cannot change in time to adapt to the changing business, but has been used as the criterion on which to base the objects’ responsibilities and behaviour. The process has been cemented in tightly coupled objects. The demand-chain rule turns time around.

The way messages are used to request objects to perform a service is widely misunderstood. As an article Service Oriented Architectures vs. Distributed Object Technologies (not available anymore, sorry) tried to argue, many people have understood message between objects as something more or less similar to function calls: an invocation of a method on an object. As Dan Ingalls already in 1981 in the famous August 1981 issue of Byte Magazine tried to explain¹, objects sending messages do something quite different: they politely request the receiver to perform a service. The receiver then decides if, how, what and when to do that. Messages as they should be modeled in object-oriented languages do not differ from the way messages are to be modeled in service oriented architectures. The argument, often repeated, that service invocation is "completely different" from object-oriented message passing, is false for properly modeled object-oriented models.

Modern developments in supply chain management clearly emphasize the advantages of demand chain processes for just-in-time inventories, flexible processes etc. This is exactly what we are talking about here.

Both rules are deceptively simple, and both rules are usually completely overlooked in publications about object orientation.

There are many more rules to good object-oriented modelling, to name a few:

1. Objects are simple. Their purpose and behaviour should be understandable within minutes.
2. Objects abhor responsibilities. Designers wishing to place a responsibility with an object, are met with strong refusal, especially if the object already has one responsibility.
3. Objects represent behaviour, in particular responsibilities delegated to them. They do not represent data or business rules.
4. Business rules exist. In object-oriented models they are contained and managed by objects in a way that effectively encapsulates them.

In future articles I expect to come back to many of them and many new ones. These rules are just a few, as an example. In fact there are many more, even several hundreds. No experienced modeller has all these rules in his or her consciousness, but on the subconscious level they work without pause to help create good object-oriented models. However the two rules comprise the essence of OO show examples in models that are created with, and without the application of these rules, is something we need to do a lot to help in developing better and more complex systems.

Future articles mentioned above:

• Active-Passive Pattern
• Time Inversion Pattern

We find it so hard to cope with complexity in IT, that every time an evolving standard, like UML, is becoming too complex, we tend to drop it in favour of something new. The new being, because it is new, simple and understandable. While it lasts …

We see this with the rising popularity of Ruby. Developers are flocking to this new thing as if mesmerized, disillusioned by the complexity of delivering value with the Java frameworks.

Now there are two reasons something can be complex. In fact I propose there are two classes of complexity.

1. Flawed complexity. It is handicapped by nature, and all the add-ons that make it complex are added in a vain and ever more frantic attempt to make it manageable.
2. Living complexity. It is growing in a natural way, and complexity is a derived attribute of its growth, but the essence in the local structures remains simple and effective.

UML is, I would like to propose, simple in its essence, being of the second class. The basis axioms remain easy to understand. Java EE on the other hand (to name a rather random other standard) is not simple, not in its building blocks, and not in the way it has to be used. It belongs to the first class of complexity.

Naturally complex solutions still remain complex, and require mastership in using them. It is counterintuitive in some aspects, one being that it is useless to attempt to understand it in its entire structure. Human beings, especially engineers I am afraid, have this urge to get an overview, to understand the global picture. With any class of complexity this is useless. However the second class of complexity offers help in the essential characteristic of being simple in its local structures. When you zoom in into the complex weave, any place you find yourself in is easy to understand, easy to do things in. When you zoom out, the structure quickly becomes unintelligible. With the first class of complexity zooming in will never offer solace, every local structure is still so intertwined with transitive dependencies that changing any local aspect can break something several degrees of separation apart.

The fact that UML in the essential building blocks is so simple, is as far as I am concerned the reason it should not be thrown away just because the standard as a whole is becoming so complex. The attribute of local simplicity is what we should judge standards with, not the attribute of global complexity.

Solutions we create are complex by nature. This is not something to avoid, but instead something we should deal with. Making a distinction between these two kinds of complexity can help.

(This article has originally been published in the Spring '96 ING Component Architecture newsletter - ICA)

Back ten years or so, when I started dabbling in object technology, I could afford to be some kind of a “software hippie”. I’m sure you know the kind. They pop up every now and then, even in respected software companies (I didn’t name one, did I?). They radiated the unrelenting optimistic attitude that melted the software crisis, budget restrictions and management dedicated to the old ways like an overheated nuclear reactor. They seem to become however, at least from my point of view, rarer. But then my point of view has changed of course. What was a new, untested, and indeed overly optimistic and enthusiastic “new wave”, has now become a respected and accepted technique. I have less and less difficulty in advocating this “new way” to the decision makers. Instead of bright and curious technical persons, often working as programmers in the larger companies, it is more and more middle and higher management acting as object oriented evangelists. So I started wearing ties, stopped trying to convince and put my efforts in the “how” instead of the “if”.

What is OMT?

Don’t be afraid that I am going to give a full synopsis of OMT here. I will give a short introduction in general terms to lay the groundwork for my arguments later in this article. I am not assuming you have any previous knowledge of object-oriented methods.

Origins of OMT

OMT, short for Object Modeling Technique, was one of those that survived the years to become a de-facto standard in software engineering. Developed at General Electrics as a an in-house modeling technique, it quickly grew after its introduction into the world with the book as the most popular analysis method (or, as the Americans say: methodology, which seems to be semantically incorrect).

OMT growing pains

The first publication did arrive in a vacuum that filled up very quickly with numerous analysis and design methods. On a conference last year one of those methodologists reported to have counted 34 of those methods. Which was for him reason enough to announce the demise of his own method.

Of course this proliferation of methods only reflected the uncertainty that companies faced in working with the new object-oriented tools and languages. Frantically looking for solutions they seemed prepared to try anything. For some of us this created a feeling of déja-vu. Didn’t we see this same sequence of events with the rise of structured methods?

For the chief methodologists this created some kind of a dilemma, which was reflected in the main publications where they started efforts towards some kind of unification and warnings against a “methods war”. The success however of some methods was undeniable. Especially OMT was more easy to adopt because of the many similarities with structured analysis and design, and its close pictographic similarity to Entity-Relationship modeling.

Merging of methods

It became obvious that most of these methods concentrated on some of the phases in software engineering. OMT was strong in analysis, weak in the design, and in fact completely lacked tools for requirements analysis. Another player in the methods field, Grady Booch, who had also published a book on object-oriented design, took up the glove and did the obvious thing: he employed the main methodologists of two of the most popular methods, James Rumbaugh who had become the main spokesman of the OMT method, and Ivar Jacobson who had created a method called Objectory.

Objectory

The power of Objectory came from a surprising direction: process modeling. Its main concept was use-cases, which described in a more or less formal way the interactions of external agents (called actors) with the proposed system. This approach has the advantage that is becomes much easier to communicate requirements of the future system with its (potential) users.

Unified Method

The merging of these three methods promises to have a synergistic result. Together they cover the whole process of software development in a more or less complete way. The method resulting from this merger however, has taken a long time in maturing and is still not yet completely published. A white paper exists on the Internet (www.rational.com), but concentrates mainly on the notational aspects. Only incidental publications have appeared in the main object-oriented magazine .  It is understandable therefore that most organizations are deferring the use of this method and continue to work with more or less adapted versions of their old method.

Applications of methods

Before I continue it is perhaps good to emphasize that although there may be many methods, there are more similarities than differences. They all contain a central repository which is called the Object Model. They all emphasize that modeling the problem domain may not be the largest portion of the work to be done (this is usually the user interface) but it is the most important portion.

This is where I will come to the main argument of my article: the emphasis on modeling. Some of you may have encountered the old-style computer analyst. It used to be a person with a computer science degree or something similar. He or she was invited in your organization and quickly assumed to know more and better of your problem domain (say: banking) than you. This arrogance is one of the main disadvantages for object-oriented analysts today: they have to cope with the mistakes of their colleagues in the past. In object-oriented modeling several things are happening at the same time:

• tools are provided that lay emphasis on abstraction and problem domain modeling
• the role of the user in creating these models is central, that of the analyst is more of an enabler
• the evolution of these models is much more controllable from a user’s point of view because of the continuous and consistent feedback with the user or domain expert (for example with prototypes)

So actually users of an object-oriented application are in a much more empowered position than before. This has a heavy impact on the whole development process, which might be the subject of another article.

This empowerment of the user has unexpected results though: it leads to a more involved interest in modeling of the users themselves. And here is where object-orientation is beginning to prove its power of abstraction. Whether they are astronomers, biologists, economists or carpenters, it appears that object-oriented domain knowledge capturing is easier and more effective than other techniques. Object-oriented models capture domain knowledge. So it is easy to understand why there is such an interest in business objects: these object-oriented business models are becoming repositories of critical business concepts. Perhaps we will see that industrial espionage of the (near) future will concentrate on business models. And maybe we will see underground vaults guarding the most valuable assets of businesses: object models.