Wanneer de bedrijfsprocessen direct worden afgebeeld op de programmeertaal ontstaat een grote kloof tussen eindgebruiker en programmeur. De gebruiker kan de specificaties niet meer begrijpen, controleren en bijsturen. De kloof is te overbruggen door de gebruiker de bedrijfsobjecten in zijn eigen woorden te laten specificeren. Vervolgens zijn de specificaties om te zetten naar de programmeerprincipes van een object-georiënteerde programmeertaal.
Een begrip dat de laatste tijd een grote populariteit geniet is ‘bedrijfsobject’. Een bedrijfsobject wordt te pas en te onpas gebruikt bij vragen rondom de specificatie, het ontwerp en de implementatie van informatiesystemen. De pleitbezorgers voor bedrijfsobjecten zeggen dat ze eenvoudiger te begrijpen zijn voor de eindgebruiker, dat ze sneller leiden tot realisatie van informatiesystemen en dat deze eenvoudiger zijn uit te breiden en te onderhouden.
Nader onderzoek leert dat bedrijfsobjecten niet zo eenduidig gedefinieerd zijn. Er zijn globaal twee stromingen te onderkennen. De eerste stroming gaat uit van de mogelijkheden van object-georiënteerde (oo) programmeertalen. De tweede stroming beschrijft de bedrijfsobjecten vanuit het perspectief van de organisatie.
De twee stromingen voor het beschrijven van objecten leiden tot totaal verschillende resultaten. Het verschil tussen beide stromingen wordt toegelicht aan de hand van een behandeling van de concepten van object-georiënteerde programmeertalen.
De waargenomen voordelen van object-oriëntatie ontspruiten vaak aan de technische mogelijkheden van object-georiënteerde programmeertalen. De voordelen van het oo-programmeerparadigma zijn de grotere zelfstandigheid van objecten en de mogelijkheid van hergebruik door overerving. Echter, het feit dat een objectgeoriënteerde programmeertaal deze mogelijkheden heeft, betekent niet dat we er automatisch goede programma’s mee maken. Hiervoor is meer nodig dan kennis van de syntax van C++ of Smalltalk. Ongeacht het kennisniveau van de programmeertaal moeten we het probleem op een juiste wijze beschrijven en omzetten in specificaties. Juist hier treden de meeste problemen op bij object-oriëntatie. Veel problemen ontstaan wanneer we een bedrijfsobject gelijkstellen aan een implementatie-object van een objectgeoriënteerde programmeertaal.
Om een idee te krijgen hoe een specificatie eruit ziet die geschreven is volgens het paradigma van een objectgeoriënteerde programmeertaal, volgt hier een ‘objectgeoriënteerd sprookje’.
De koffiekan en het kopje
Een koning heerst over een groot rijk in de Oriënt.
Zijn onderdanen zijn ‘objecten’. De koning leeft reeds vele jaren gelukkig in zijn kasteel met zijn meest dierbare objecten: de koffiekan en het kopje. De koffiekan en het kopje voorzien de koning dagelijks van verse koffie. De koffiekan zet koffie. Wanneer die daarmee klaar is, vraagt hij aan het kopje tot hoever het gevuld wil worden. Het kopje geeft antwoord aan de koffiekan. Deze vult het kopje, waarna de koning kan genieten van zijn koffie.
Na vele jaren van regeren wordt de koning, evenals zijn objecten, ouder. Het kopje vertoont barsten en de koffiekan is al een aantal keren gelijmd door de lijmpot. In gesprekken met de koffiekan en het kopje komt de koning tot de conclusie dat het koninkrijk alleen kan voortbestaan wanneer er een nieuwe generatie aantreedt. Het kopje komt op het geniale idee om met overerving (inheritance) nieuwe kinderobjecten te creëren die de eigenschappen overerven van de bestaande objecten. De koning vindt dit een prima idee en stelt voor om ‘prinsjes’ te creëren die de taken van de koning overerven wanneer de koning overlijdt.
Zo gezegd, zo gedaan. Het kopje en de koffiekan gaan aan het werk en creëren drie prinsjes en een veel groter aantal nieuwe kopjes en koffiekannen. Het lijkt erop dat het koninkrijk lang en gelukkig zal voortbestaan, maar op het moment dat de koning overlijdt, verdwijnen ook de prinsjes. Er is niemand meer die de heerschappij van de koning kan overnemen. Dit komt omdat de prinsjes de eigenschappen van de koning overgeërfd hebben, en daarmee afhankelijk zijn van het bestaan van de koning. Het koninkrijk hult zich in diepe duisternis.
Communicatie
Het sprookje beschrijft dat de koffiekan en het kopje met elkaar communiceren en acties uitvoeren. Het kopje en de koffiekan voldoen aan de kenmerken van een object in C++ en Smalltalk. Toch hebben wij gevoelsmatig grote problemen om de koffiekan en het kopje te beschouwen als intelligente, zelfregelende objecten die met elkaar communiceren. In werkelijkheid zijn ze noch intelligent noch in staat om acties uit te voeren. Grammaticale analyse van het sprookje leert dat de koffiekan en het kopje veelvuldig het grammaticale ‘onderwerp’ zijn. Het onderwerp in een actieve zin duidt op een regelend subject dat acties aanstuurt en uitvoert.
Meestal is het onderwerp een persoon en niet kopje of koffiekan. De koffiekan en het kopje zijn veelal het lijdend en meewerkend voorwerp. In het Engels duiden we het onderwerp aan met subject, het lijdend voorwerp met active object en het meewerkend voorwerp met passive object. Grammaticale analyse toont aan dat subjecten met elkaar communiceren over bedrijfsobjecten. De bedrijfsobjecten zelf communiceren niet met elkaar. De subjecten moeten intelligent zijn voor het aansturen van de acties op de bedrijfsobjecten. We poneren nu een aantal stellingen.
Stelling 1: Subjecten communiceren met elkaar. Objecten niet!
Toch zien we dat de koffiekan en het kopje veranderen doordat we koffie in het kopje inschenken. Het kopje wordt voller en de koffiekan leger. Het inschenken is de actie die leidt tot een interactie tussen de koffiekan en het kopje.
Stelling 2: Bedrijfsobjecten communiceren niet met elkaar maar interacteren met elkaar.
Met het voorbeeld hebben we de belangrijkste basisprincipes van de Kiss-methode besproken. Deze gaat uit van de grammaticale concepten van de natuurlijke taal. Modellen stellen we op met de grammaticale regels uit onze natuurlijke taal. De modellen zijn eenvoudig terug te brengen tot begrijpelijke zinnen in natuurlijke taal, waardoor ze snel valideerbaar zijn door de eindgebruiker. Het Kiss-paradigma stelt dat subjecten met elkaar communiceren en dat objecten met elkaar interacteren door gemeenschappelijke acties
Overerving van lijken
Het sprookje eindigt ongelukkig doordat het geniale idee van het kopje over overerving niet werkte. Alle kinderobjecten verdwijnen wanneer het ouderobject verdwijnt. De oplossing is het ouderobject, in dit geval de koning, na zijn overlijden te laten voortbestaan als een abstract object. Het abstracte object leeft dan niet echt meer, maar de kinderen kunnen zijn eigenschappen wel overerven. In lijn met het sprookje denken we aan het bouwen van een piramide waarin de mummie van de koning wordt bijgezet. De mummies zijn de abstracte objecten.
Stelling 3: Overerving leidt tot mummificatie van objecten in een systeem.
Objectgeoriënteerde programmeurs passen de bovenstaande werkwijze veelvuldig toe. Wanneer de subklassen steeds meer informatie gaan bevatten, neemt het belang van de superklassen af. Ze worden omgezet in abstracte superklassen. In het objectgeoriënteerde systeem ontstaat een hiërarchische, piramide-achtige structuur met een groot aantal gemummificeerde lijken. Het voortbestaan van de objectgeoriënteerde programmatuur hangt af van de overgeërfde eigenschappen van de dode voorouders die als een soort vloek regeren over het systeem. Het is voor schatzoekers dan ook een moeizame taak om de juiste weg te vinden door de objectgeoriënteerde catacomben. Zo is menig pad versperd door het overrulen van overerving door lokale instructies. Het overervingsprincipe dat in het begin veel voordelen bracht door een snelle realisatie, heeft in de loop van de tijd geleid tot een grote mate van onveranderbaarheid en steeds beperkter hergebruik. De structuur van een objectgeoriënteerd programma wordt met overerving beïnvloed door een initiële situatie in een ver verleden. Je kunt stellen dat de dode koningen met overerving over hun graf heen regeren.
Stelling 4: Ongecontroleerd toepassen van overerving leidt tot niet-onderhoudbare programmatuur.
De eenvoudigste oplossing is om geen overerving te gebruiken. Microsoft verwerpt overerving categorisch. Het voordeel is dat de structuur eenvoudiger te veranderen is; er moet echter veel programmeerwerk verricht worden.
Onder welke criteria kiezen we voor overerving? De Kiss-methode biedt ondersteuning bij deze vraag, doordat de abstractie-mechanismen voor implementatie met overerving reeds in de modellering zijn opgenomen.
In de realiteit onderkennen we geen overerving. In het bedrijfsproces is er namelijk geen run time-overerving van superklassen naar subklassen. Dit is wel het geval in de oo-programmeertaal. Wanneer we een getrouwe specificatie van de bedrijfsobjecten opstellen, zal overerving geen enkele rol mogen spelen.
Stelling 5: Bedrijfsobjecten worden gespecificeerd en gemodelleerd zonder overerving.
Aan de hand van het sprookje zien we dat objectgeoriënteerde programmeertalen semantisch te zwak zijn om bedrijfsobjecten te specificeren. Smalltalk- en C++-concepten zijn semantisch te beperkt om te gebruiken in de onderlinge communicatie tussen systeemontwikkelaars en eindgebruikers.
Veel beter is het om de bedrijfsobjecten en -activiteiten te beschrijven in natuurlijke taal. We hebben geleerd om te communiceren in Nederlands. De natuurlijke taal is het instrument waarmee de eindgebruikers de specificaties verduidelijken. Met natuurlijke taal toetsen we de kwaliteit en juistheid van de specificaties van de bedrijfsobjecten en -activiteiten.
De Kiss-methode beschrijft de bedrijfsobjecten in de grammatica van de natuurlijke taal. Het voordeel van natuurlijke taal is dat deze de bedrijfsobjecten en -activiteiten reeds impliciet beschrijft. De grammatica is bekend bij iedereen die gebruik maakt van spreek- en schrijftaal. De meesten van ons maken reeds vanaf hun vierde jaar gebruik van de taalgrammatica. Het duurt jaren om jezelf juist leren uit te drukken; de omgeving corrigeert je daarbij constant. Juist dit potentieel gebruikt de Kiss-methode voor het verbeteren van de communicatie tussen systeemontwikkelaars en eindgebruikers. Het maakt specificaties begrijpelijk voor zowel ontwikkelaars als eindgebruikers, waardoor het inzicht in de probleemomgeving en de oplossingen aanzienlijk toeneemt.
Stelling 6: De kwaliteit van de communicatie bepaalt de mate waarin men elkaar begrijpt.
Instantiatie en classificatie
Een groot voordeel van objectgeoriënteerde programmeertalen is dat systemen sneller zijn te realiseren. Wanneer men de structuur van een objectgeoriënteerd systeem echter slecht doordenkt en met een minimale documentatie realiseert, zijn de voordelen van object-oriëntatie op het gebied van hergebruik van objecten niet waar te maken. Een objectgeoriënteerde programmeertaal ontslaat een programmeur dan ook niet van het maken van een goede probleemanalyse.
Hieronder wordt een aantal additionele beperkingen van objectgeoriënteerde programmeertalen behandeld aan de hand van het Indiase kastensysteem.
Exotische Classificatie. Op een reis door India waarin ik een aantal seminars over de Kiss-methode gaf, kwam ik een zeer sterke analogie tegen met het paradigma van objectgeoriënteerde programmeertalen.
Hindoes geloven dat zij een serie van wedergeboorten (reïncarnaties) doorlopen die uitmondt in de geestelijke zegening en de bevrijding van de cyclus van wedergeboorten. Met elke wedergeboorte kom je dichterbij of verder af van een geestelijke zegening. De bepalende factor is het karma. Slechte acties resulteren in een slecht karma, wat leidt tot reïncarnatie op een lager niveau. Goede acties laten het karma toenemen. Je reïncarneert op een hoger niveau dat je ook dichter bij bevrijding van reïncarnatie brengt.
Reïncarnatie is nauw verweven met het kaste-systeem van de Hindoe-maatschappij. Het Hindoeïsme onderkent vier hoofdkasten: de Brahmanen of priesterkaste; de Kshatriya’s of soldaten en leiders; de Vaisya’s of handelaren en boeren, en de Sudra’s of handwerkslieden. De hoofdkasten zijn onderverdeeld in een groot aantal subkasten. Onder alle kasten staan de Harijans, of onaanraakbaren, zijnde de laagste kasteloze klasse met de slechtste baantjes.
De Hindoeïstische maatschappij classificeert personen in vijf klassen. De klassen zijn zelf ook weer onderverdeeld in veel subklassen. Het is in het Hindoeïsme niet mogelijk dat een persoon gedurende zijn leven van sociale klasse verandert. Om te stijgen moet je eerst een goed karma opbouwen. Vervolgens dien je te overlijden en op de brandstapel gecremeerd te worden alvorens je kunt reïncarneren in een hogere sociale klasse.
Objectgeoriënteerde programmeertalen ondersteunen deze benadering. Objecten zijn namelijk altijd instanties van een klasse doordat een klasse ze instantieert. De klasse beheert het gehele leven van het object. Aan het eind van zijn leven belandt een object in de prullenbak (garbage collector) om ruimte te maken voor nieuw geïnstantieerde objecten. De objecten zijn analoog aan de personen en de klasse is analoog aan de kaste.
Wanneer we bedrijfsobjecten uit de organisatie implementeren als subklassen die de kenmerken van de superklasse ‘persoon’ erven, treedt een aantal problemen op. Dit komt duidelijk naar voren wanneer een persoon van de subklasse ‘prospect’ naar de subklasse ‘cliënt’ overgaat. In een objectgeoriënteerde taal is dit niet mogelijk. Immers, het object moet zijn leven beëindigen in de ene subklasse en opnieuw geïnstantieerd worden in een andere subklasse. Voor het oplossen van de gecreëerde problemen zijn technieken voorgesteld als ‘multiple overerving’ van de subklassen naar een nieuwe subklasse. Dit leidt weer tot nieuwe problemen. In het algemeen leidt het toepassen van overerving tot rigiditeit en een beperktere aanpasbaarheid voor nieuwe situaties in de reële wereld.
De classificatie-principes van objectgeoriënteerde talen zijn in werking gelijk aan die van het Indiase kastensysteem. In de Hindoe- maatschappij heeft het toepassen van het kastensysteem geleid tot zeer rigide sociale structuren.
Stelling 7: De klasse creëert problemen omdat instantiatie en classificatie hier identiek zijn.
Het probleem met het ‘klasse’-concept van programmeertalen is dat het objecten zowel instantieert als ook classificeert met hetzelfde concept. De Kiss-methode onderscheidt het instantiëren van het classificeren. In deze methode worden de objecten geïnstantieerd met het objecttype. Er is een aparte classificatie van objecten naar objectklassen. Dit is noodzakelijk omdat in de reële wereld objectclassificatie onafhankelijk is van objectinstantiatie.
Eigen woorden
De concepten van objectgeoriënteerde programmeertalen bieden te weinig semantiek voor het specificeren van bedrijfsobjecten en -activiteiten. Objectgeoriënteerde methods die uitgaan van de programmeerconcepten vangen dit niet op. Het specificeren en modelleren van bedrijfsobjecten vindt op een natuurlijke wijze plaats wanneer we uitgaan van onze spreek- en schrijftaal. Een tekstuele beschrijving van de organisatorische werkwijze is het uitgangspunt. Met een grammaticale analyse van teksten hebben we in de hier beschreven methode een natuurlijke specificatiewijze voor bedrijfsobjecten. De grammatica van de natuurlijke taal geeft namelijk direct inzicht in de betekenis van woorden. Vervolgens is men in staat om de specificaties te verbeteren doordat de tekstuele beschrijvingen op eenvoudige wijze overdraagbaar zijn tussen de betrokken partijen.
De algemene aanbeveling is dan ook om de bedrijfsobjecten en -activiteiten eerst te specificeren in modelleringsconcepten die de natuurlijke taal ondersteunen. Vervolgens zijn de specificaties om te zetten naar de programmeerprincipes van een objectgeoriënteerde programmeertaal. Wanneer de bedrijfsprocessen direct worden afgebeeld op de programmeertaal ontstaat een grote kloof tussen de eindgebruiker en de programmeur. Als gevolg hiervan is de gebruiker niet meer in staat om de specificaties te begrijpen, te controleren en bij te sturen. Deze kloof is te overbruggen door de gebruiker de bedrijfsobjecten in zijn eigen woorden te laten specificeren. Het resultaat is dat we enerzijds betere specificaties krijgen en anderzijds het proces versnellen doordat we sneller een goed systeem opleveren.
Ir. G.J.H.M. Kristen is algemeen directeur Kristen Informatie & Software Services
Kirsten, G.J.H.M. Kiss-Methode voor Object Oriëntatie, van Informatie Architectuur naar Informatie Systeem, Academic Service, Schoonhoven, 1993.
Object-oriëntatie
De sleutelwoorden voor een objectgeoriënteerde programmeertaal zijn: modelleren met objecten; object-identificatie; inkapseling; communicatie tussen objecten; methods; overerving; instantiëren van objecten door een klasse (class), en polymorfisme.
Objecten zijn de instanties van een klasse. De klasse staat centraal bij een objectgeoriënteerde programmeertaal. Objecten zijn zelfstandige eenheden met een eigen identificator. Het gedrag van objecten in een klasse is te beschrijven met methods. De methods beschrijven de operaties die het object kan ondergaan of uitvoeren. De klasse kapselt het gedrag en de eigenschappen van de objecten in, zodat de buitenwereld de details van objecten niet te zien krijgt.
In een objectgeoriënteerd programma communiceren de objecten met elkaar door boodschappen te versturen. Objecten ontvangen boodschappen door middel van methods die weten welk gedrag het object moet vertonen. Wanneer we een boodschap naar een object sturen, geeft het object een gedefinieerde reactie.
Polymorfisme duidt aan dat een groep objecten verschillend reageert op één en dezelfde boodschap die we naar de groep objecten verzenden.
Naast de eigenschap dat objecten met elkaar communiceren, bestaat er tussen de objecten ook een structurele samenhang. Deze ontstaat doordat we kenmerken in een generieke superklasse (superclass) onderbrengen en deze kenmerken door overerving hergebruiken bij de objecten van subklassen (subclasses).
We spreken van enkelvoudige overerving wanneer er slechts één generieke superklasse is, en van meervoudige overerving wanneer we de kenmerken van twee of meer superklassen hergebruiken. Door overerven hoeft minder geprogrammeerd te worden, omdat er een structurele afhankelijkheid tussen klassen is gecreëerd.
