Objectoriëntatie voldoet nog altijd niet aan de hooggespannen verwachtingen met betrekking tot hergebruik en onderhoud. Omdat objecttechnologie de automatiseringspraktijk desondanks geleidelijk doordringt is het belangrijk om snel orde op zaken te stellen. Het belangrijkste knelpunt zit in de beginfase: de domeinanalyse. Frens Vonken en Frank Peeters laten zien hoe de kwaliteit en beheersbaarheid van de domeinanalyse te verbeteren is met een door hen ontwikkelde methode.
Binnen de hedendaagse software-engineering heeft objectoriëntatie (oo) en op componenten gebaseerde ontwikkeling (‘component based development’, cbd) een prominente rol verkregen. Bij traditionele software worden de softwaregegevens en de softwareprocessen los van elkaar ontworpen en geïmplementeerd. Deze scheiding is gekunsteld en gaat gepaard met grote nadelen. De grootste nadelen betreffen het onderhoud en het hergebruik.
Zodra traditionele software een of andere vorm van onderhoud moet ondergaan, blijkt keer op keer dat aanpassingen vrijwel nooit lokaal zijn. Te vaak gaat een aanpassing met een domino-effect gepaard. Elke aanpassing impliceert een zorgvuldige controle op de rest van de software. Bij deze controle is vaak niet duidelijk waar men op moet letten. Meestal volstaat men met lokale testen in plaats van zorgvuldig te verifiëren of het hele ontwerp (nog) correct is. Niet voor niets worden de gebruikers van deze prijzige software veel te vaak geconfronteerd met fouten, die ook in nieuwe versies niet verdwijnen.
Het andere nadeel betreft de beperkte herbruikbaarheid. Traditionele software is te monolithisch van structuur. Het is moeilijk om delen van bestaande software voor andere software in te zetten. De onderdelen blijken teveel al of niet bekende afhankelijkheidsrelaties met de andere delen van de software te vertonen. De traditionele software biedt daarom te weinig mogelijkheden tot hergebruik. Het wiel moet iedere keer opnieuw worden uitgevonden.
Bij objectgeoriënteerde software is de scheiding tussen gegevens en processen opgeheven. Binnen oo-software communiceren objecten met elkaar. Een object beschikt intern over al zijn gegevens en al zijn toegestane processen. Deze opzet biedt de mogelijkheid om te denken in componenten. Het wordt mogelijk om nieuwe software te assembleren uit bestaande componenten. Onderhoud van software komt dan neer op onderhoud van componenten; het domino-effect blijft achterwege. De beloften van objectoriëntatie zijn daarmee groot.
Systematiek ontbreekt
Objectgeoriënteerde programmeertalen zijn inmiddels volwassen en er zijn professionele programmeeromgevingen beschikbaar. We mogen verder blij zijn dat er een wereldwijde standaard is ontstaan: UML. Deze standaard beperkt zich voorlopig vooral tot de taal. Een systematische methodiek om zich correct en gedegen in deze grafisch georiënteerde taal uit te drukken is op dit moment de Achilleshiel van de ontwikkeling van objectgeoriënteerde systemen. In de literatuur over domeinanalyse voor oo-software vindt u alleen tips en vage heuristieken. Er bestaat geen systematische methode om een oo-analyse voor een zeker domein uit te voeren. Dit is te vergelijken met de beschikbaarheid van een fantastisch cad-systeem bij het ontwerpen van een nieuw vliegtuig terwijl er geen gedegen kennis van de stromingsleer en de mechanica aanwezig is. In het geval van oo-analyse weten alleen ervaren analisten met enig kunst en vliegwerk een bevredigend model van het domein in kaart te brengen. Ze laten zich leiden door standaardpatronen. In de hedendaagse praktijk van oo-analyse worden we echter te vaak met modellen geconfronteerd waarin de analist zich teveel door de traditionele opsplitsing van functionaliteit (stapsgewijze verfijning) laat leiden. Menig analist is op die manier opgevoed. Het afleren van ingesleten gewoontes is echter niet eenvoudig.
Ook heeft menig analist teveel de neiging om gedurende de domeinanalyse te ver vooruit te kijken. Allerlei implementatiedetails (persistentie, ‘pointers’, gui-aspecten, en dergelijke) vervuilen zodoende het model. Dit komt de herbruikbaarheid en het onderhoudsgemak van oo-software niet ten goede.
Met een door de auteurs van dit artikel ontworpen analysemethode is op systematische en gecontroleerde wijze een goed ontwerp van het domein voor oo-software te realiseren. De methode kenmerkt zich door een gedetailleerd stappenplan waarbij voortdurend in wisselwerking met de opdrachtgever en toekomstige gebruikers verificaties worden uitgevoerd. De kenmerken en het gedrag van objecten komen op een systematische manier op de goede plaats terecht.
Relaties uitgangspunt
Kenmerken en gedrag zijn met elkaar verbonden. Gedrag zonder kenmerken is vergelijkbaar met ademen terwijl er geen zuurstof in de lucht is. Een voorbeeld: een diskdrive kan gegevens van een disk lezen. Het leesgedrag van het diskdrive-object maakt gebruik van de kenmerken van een diskobject en een geheugenobject. Het gedrag van een object is altijd te herleiden tot een of andere vorm van manipulatie van kenmerken van objecten. Voordat we gedrag kunnen definiëren moeten de kenmerken vaststaan. De kenmerken zijn het fundament van het gedrag. Het gedrag ligt als het ware boven op de kenmerken. De ontwikkelde methode laat zich leiden door deze gelaagdheid.
Typerend voor de methode is het feit dat de domeinanalyse start met een inventarisatie van aanwezige relaties in het verkozen domein. Relaties zijn op te vatten als kenmerken over en tussen de objecten in het domein. Door de relaties en niet de klassen als uitgangspunt te nemen verkrijgt de analist vanaf het allereerste begin vat op de structuur tussen de objecten. Zowel de verbanden tussen de objecten als de objecten zelf komen tegelijk aan het licht. Een (tussen)resultaat van de analyse is vanaf het allereerste begin samenhangend.
Het resultaat van de analyse is een klassendiagram, voorzien van alle attributen, associaties, overerfrelaties en basisgedrag. UML sluit daar naadloos op aan. De verfijningen en het verdere ontwerp kan daarmee volgens de gangbare methoden worden voortgezet. Hierbij is te denken aan technieken als het opstellen van ‘volgorde-diagrammen’, ‘samenwerkingsdiagrammen’, ‘statusovergangdiagrammen’, en dergelijke. Deze technieken dienen ervoor om een gegeven klassendiagram nader te detailleren. Meestal gaat de analist dan na of elk gebruiksscenario met het gegeven klassendiagram correct kan worden afgehandeld. Er wordt dan nagegaan of er voldoende (en geen overbodige) communicatiekanalen zijn en of het gedrag van een klasse verfijnd genoeg is. Hierna kan een formele specificatie van alle gedragscomponenten en bijzondere klasse-eigenschappen volgen. Het domeinmodel ligt dan vast.
Verifieerbaarheid van tussenresultaten van de analyse behoren hoog in het vaandel te staan. Binnen deze analysemethode geschiedt de verificatie op basis van expressies in een taal die gebruikers begrijpen. Doordat de expressies aan een – zij het beperkt – aantal welgevormdheidsregels moeten voldoen, is deze verificatie voldoende exact. De naam van de methode EXPO, Expression Based ‘Object Modeling, is hiervan afgeleid.
Klassendiagram
Om een idee te geven hoe de EXPO-methode in haar werk gaat, wordt een deel ervan toegelicht aan de hand van een concrete casus. Het betreft de kwalificatie voor een willekeurig voetbalkampioenschap voor landenteams. Gedurende zo’n kwalificatie worden landenteams in groepen ingedeeld. Per groep spelen de teams een volledige competitie met uit- en thuiswedstrijden. De informatie over kampioenschappen in het verleden, maar ook die van lopende kwalificaties, wordt via het World Wide Web aan publiek, verslaggevers en officials aangeboden. De aangeboden informatie moet zo actueel mogelijk zijn. Officials kunnen ervoor zorgen dat het scoreverloop, invalbeurten, en dergelijk, van lopende wedstrijden meteen wordt verwerkt.
De EXPO-methode schrijft voor relaties in concrete voorbeeldinformatie op te sporen.
Een voorbeeld:
Nederland speelt zijn kwalificatie in groep 2 voor WK-2002.
Hierin wordt een relatie tussen een landenteam en een kwalificatiegroep gelegd. Andere voorbeeldrelaties zijn:
De wedstrijd tussen Nederland en Portugal voor WK-2002 vindt plaats op 18-9-2000.
Ronald de Boer speelt mee gedurende de 54e t/m de 90e minuut in de wedstrijd tussen Ierland en Nederland voor WK-2002.
Jordi Cruijff is speelgerechtigd voor Nederland voor EK-1996. (aanname: spelers met een tweede nationaliteit mogen voor een ander toernooi voor het andere land kiezen)
Deze informatie wordt vervolgens op een systematische manier geanalyseerd. Een van de tussenresultaten van de analyse zijn de relaties op typeniveau (zie figuur 1 onderaan).
De eerste relatie brengt twee soorten van objecten (klassen) aan het licht: landenteam en groep. Naarmate de analyse vordert, wordt er keer op keer een relatie toegevoegd. Al doende groeit het aantal gerelateerde(!) klassen. Het klassendiagram groeit daarom als een samenhangend geheel. De andere relaties voegen daar in eerste instantie naast het minder spectaculaire text, getal en datum klassen als wedstrijd, speler, doelpunt en toernooi aan toe. Een strikte analyse wijst verder uit dat opstelling en speelmachtiging ook als volwaardige klassen moeten worden beschouwd (zie figuur 2 onderaan). Om het model niet nodeloos gecompliceerd te maken is de klasse tijdstip tot een attribuut gereduceerd.
Klassen
Elke klasse kan nu van zogenaamd basaal gedrag worden voorzien. Dat wil zeggen: over welke gedragscomponenten behoort elke klasse minimaal te beschikken?
We lichten de wedstrijd-klasse er apart uit. Deze klasse moet, naast een geschikte wijze van constructie, over inspectiemethoden beschikken waarmee het thuisland, het uitland, het toernooi, de datum, de selectie, de opgestelde spelers en de gemaakte doelpunten bij een wedstrijd kan worden opgevraagd. We worden hierbij volledig door het gegeven klassendiagram getriggerd. De vereiste functionaliteit wordt zodoende bij de meest voor de hand liggende klasse ondergebracht. Omdat gegevens over wedstrijden online moeten worden vrijgegeven zal de wedstrijd-klasse ook over een methode beschikken om de toestand van een wedstrijd-object on-line te wijzigen. De klasse moet daarom methodes aanbieden om een doelpunt, een inval- en uitvalbeurt en een oproep voor een wedstrijd te registreren. Elke klasse wordt op deze manier systematisch van basaal gedrag voorzien. Het klassendiagram met basaal gedrag kan vervolgens verder worden verfijnd aan de hand van de gangbare UML-interactieschema’s.
Samenhang
We zijn met zevenmijlslaarzen door de methode gelopen. Een moment van reflectie is op zijn plaats. Een van de grote voordelen van de gepropageerde aanpak is de samenhang in het klassendiagram. Het groeit zoals een spin zijn spinnenweb aanmaakt. Alle draden worden met voorbedachten rade met de juiste knooppunten verbonden. Er is geen onzekerheid meer over ontbrekende klassen of over de aanwezigheid van klassen zonder bestaansgrond. De vereiste associaties en attributen staan meteen op de goede plaats. Het gedrag is op vanzelfsprekende wijze aan de juiste klasse toegewezen. Er komen geen ‘God’- of andere overbodige manager-klassen in het model voor. Ook al maakt de voorbeeldcasus dat niet duidelijk, de overerfrelaties worden eveneens op natuurlijke wijze aan het klassendiagram toegevoegd.
Gedurende de domeinanalyse moet er op gepaste wijze met de mate van detaillering worden omgesprongen. Als de analist op een object van de klasse datum, adres, geld, tijdstip of klant stoot, moet er worden afgewogen of de waardebepalende kenmerken van zo’n object al dan niet een detailanalyse vereisen. Kan men deze detailanalyse uitstellen of kan men profiteren van bouwstenen uit voorgaande domeinanalyses? Hergebruik van beproefde klassen vormt een wezenlijk onderdeel bij het uitvoeren van een gedegen domeinanalyse.
Aan de andere kant zal een domeinanalist zich moeten afvragen of de klassen voor het betreffende domein voldoende generiek zijn. Zijn ze niet teveel op de toevallige kenmerken van dit probleemdomein toegesneden? Hier zal een afweging tussen korte termijn- en lange termijnbelangen plaatsvinden. Een automatiseerder die voortdurend voor de korte termijn kiest, zal het op de lange termijn gaan afleggen tegen de automatiseerder die investeert in cumulatieve, beproefde en voldoende generieke kennisopbouw. Een case-tool moet de analist stimuleren tot hergebruik van bibliotheekklassen. De bouw van zo’n case-tool, gebaseerd op de EXPO-methode, is inmiddels in een vergevorderd stadium.
Beheersbaar
De schade die een matig ontwerp met zich meebrengt, zodra men de fase van het systeemontwerp en implementatie betreedt, is enorm. Een goed ontwerp van het domeinmodel zal het correctief onderhoud ingrijpend doen verminderen. Het klassendiagram kenmerkt zich verder door een lage koppeling en hoge cohesie. Daardoor kunnen de oo-beloften van hergebruik gemakkelijker worden gerealiseerd. Een verminderd correctief onderhoud en een verbeterd hergebruik gaan gepaard met een ingrijpende kostenbesparing. Maar ook op de korte termijn zullen de kosten, verbonden aan het uitvoeren van een grondige domeinanalyse, krimpen. Experimenten hebben aangetoond dat naast de verbeterde kwaliteit de doorlooptijd voor de domeinanalyse ingrijpend wordt verkort, tot zelfs 20 procent van de tijd! Daarnaast bestaat het voordeel dat het analyseproces beheersbaarder wordt. De stappen die moeten worden uitgevoerd voor een domeinanalyse zijn expliciet en kwantificeerbaar, wat mankracht betreft. Dit moet een account-manager als muziek in de oren klinken.
Frens Vonken Frank Peters Docenten Fontys Hogeschool Informatica
IndelingKwalificatie: | |
Groep: | groep
|
Tournooi: | |
WedstrijdDatum: | |
Wedstrijd: | de wedstrijd tussen |
Speelmachtiging: | |
Selectie: | |
OpstellingVanaf: | |
Tijdstip: | de |
OpstellingT/M: | |
Doelpunt: | In |
MakerDoelpunt: | |
EigenDoelpunt: |
Figuur 1. Relaties op type-niveau bij een voetbalkampioenschap.
Figuur 2. Relaties tussen de klassen. |