2 Objectgeoriënteerde systeemontwikkeling Objecttechnologie of objectoriëntatie is een bekende term in de automatisering. Regelmatig verschijnen artikelen over dit onderwerp in de bekende vaktijdschriften. Veel bedrijven zijn bezig om objectgeoriënteerde technieken toe te passen, andere beginnen met een voorzichtige verkenning van objectgeoriënteerde technieken. Toch zijn zeker de inhoudelijke kanten van objecttechnologie nog lang niet overal bekend. Men kent ongeveer het idee erachter en sommige van de meest in het oog springende kenmerken. Soms gaat de onbekendheid met het onderwerp zo ver dat objecttechnologie verward wordt met het programmeren in Java of C++. Zonder twijfel echter biedt het objectgeoriënteerde paradigma een veel bredere schakering van technieken en programmeertalen. De standaard visuele taal voor analyse en ontwerp UML (Unified Modeling Language) is een van die technieken. Voor in de volgende hoofdstukken nader ingegaan wordt op UML is het zinvol om in dit hoofdstuk in het kort de belangrijkste kenmerken van het objectgeoriënteerde paradigma toe te lichten. Ook zullen de claims die op de technologie gelegd worden, zoals betere onderhoudbaarheid en kwaliteit van de programmatuur, worden toegelicht. In hoofdstuk 5 worden allerlei specifieke termen uit de objecttechnologie als overerving, klasse, boodschap, objectmodel enz. beschreven. Dit hoofdstuk geeft een meer globaal overzicht van objecttechnologie en gaat in op de relatie en verschillen tussen objectgeoriënteerde en meer traditionele methoden. U als lezer zult daarna in staat zijn om de merites van UML in dit grotere kader te plaatsen.
3
4
OBJECTGEORIËNTEERDE SYSTEEMONTWIKKELING
2.1 H ET OBJECTTECHNOLOGIEPARADIGMA Zojuist noemden we objecttechnologie een paradigma. Wat wordt er precies met die term bedoeld? Van Dale [Dale92] omschrijft de term als volgt: ‘het geheel van wetenschappelijke prestaties van voorgangers dat door onderzoekers op een bepaald gebied op een bepaald moment in de ontwikkeling van een wetenschap als maatgevend wordt beschouwd.’ In het kader van dit boek is paradigma goed te omschrijven met het begrip ‘denkraam’, zoals dat gebruikt wordt in de bekende strip Olivier B. Bommel. Het objecttechnologieparadigma is een denkraam waarbinnen software wordt gestructureerd op basis van de combinatie van data en het gebruik daarvan. De manier waarop software gestructureerd wordt, met andere woorden de manier waarop programmatuur bekeken wordt, is in de loop der jaren zeer verschillend geweest. Het varieerde van structurering op basis van de functie van een bepaald (deel)programma en het functionele ontwerpen, tot structurering op basis van de benodigde data en het gegevensgerichte ontwerpen. Van aanhangers van beide kanten komt nu het protest: ja, maar we waren ook met de gegevens c.q. de functies bezig. Het antwoord hierop is: vanzelfsprekend waren aanhangers van het functioneel ontwerpen ook met data bezig en waren gegevensgerichte ontwerpers ook met de functie van de gegevens bezig. Die twee zijn nu eenmaal niet los te zien. Maar het uitgangspunt bij het structureren, het denkraam, was ofwel het een, ofwel het ander. Objecttechnologie gebruikt een ander denkraam, waarbij deze twee polen vanaf het eerste begin samen ‘gedacht’ worden.
2.2 K ENMERKEN VAN OBJECTTECHNOLOGIE Objecttechnologie is een nieuw paradigma op basis waarvan een bepaalde structuur aangebracht wordt in softwaresystemen. Het kenmerk van objecttechnologie is dat data en functies die deze data bewerken samengevoegd worden in een eenheid die object genoemd wordt. Elk object is een zelfstandige entiteit binnen het totale systeem. De structuur van het systeem bestaat uit objecten die met elkaar verbonden zijn en met elkaar communiceren.
KENMERKEN VAN OBJECTTECHNOLOGIE 5
2.2.1 Objecten en de wereld Tijdens de analysefase in de bouw van een softwaresysteem construeren we een structuur (of model) waarin die software gegoten gaat worden. Hiertoe zien we ieder object als afspiegeling van hetzij een fysiek ding uit de werkelijkheid, hetzij een concept dat gangbaar is in die werkelijkheid. Fysieke objecten zijn over het algemeen duidelijk te onderscheiden: tafel, stoel, auto, bal, enz. Concepten zijn vaak lastiger om te onderscheiden. Sommige ingeburgerde concepten zijn daarentegen weer heel duidelijk: bankrekening, window, vakantie, enz. Met behulp van objecten is het mogelijk om een model te maken van een deel van de werkelijkheid. Dit model is natuurlijk altijd een vereenvoudiging. Omdat de objecten in het model een directe afspiegeling van dingen en concepten uit de werkelijkheid zijn, is een dergelijk model beter te begrijpen door gebruikers en andere niet-automatiseerders.
2.2.2 Principes uit de software-engineering Bij de objectgeoriënteerde manier om software te structureren zijn essentiële pribncipes uit de software-engineering het uitgangspunt. Een object verbergt zijn binnenkant (hoe worden operaties uitgevoerd, wat wordt er precies opgeslagen en hoe, enzovoorts) voor alle andere objecten in het systeem. Dit principe van inkapseling (Eng. encapsulation) is een welhaast perfecte vorm van information hiding. Het belang van information hiding staat, los van de gebruikte technieken, buiten kijf. Ieder modern boek over software-engineering zal dat direct beamen. Traditioneel blijken aanpassingen in software zeer moeilijk. Zelfs kleine wijzigingen van functionaliteit veroorzaken vaak een domino-effect: één kleine wijziging op één plaats in de software heeft vele, vaak ongewenste en onverwachte neveneffecten op grote delen van het systeem. Door middel van inkapseling is het mogelijk om aanpassingen in de software in belangrijke mate te lokaliseren. Aanpassen betekent dus minder werk, maar vooral ook minder kans op het introduceren van fouten door ongewenste neveneffecten. Hierdoor blijft de kwaliteit van de software, ook na herhaaldelijk aanpassen, op een hoog peil. Een systeem dat eenvoudig en met minder moeite aan te passen is, zorgt voor flexibiliteit. Het kan snel genoeg meeveranderen met de behoeften van de organisatie en gebruikers.
6
OBJECTGEORIËNTEERDE SYSTEEMONTWIKKELING
2.2.3 Objecten en verantwoordelijkheden Belangrijk bij het structureren van software is ook een goede verdeling van alle activiteiten of taken binnen het systeem. De nadruk binnen objecttechnologie ligt daarom altijd op de verantwoordelijkheid (Eng. responsibility) van het object. Ieder object heeft een duidelijk afgebakende, meestal beperkte verantwoordelijkheid voor het uitvoeren van bepaalde activiteiten in het systeem. Deze verdeel-en-heerstactiek maakt het mogelijk om fouten (bugs) makkelijker te lokaliseren. Maar niet alleen fouten, ook veranderingen zijn makkelijker te plaatsen en de consequenties ervan makkelijker te doorgronden. In het algemeen is het gehele ontwerp eenvoudiger te begrijpen. De structuur van een objectgeoriënteerd systeem zou je kunnen vergelijken met de opbouw van het menselijk lichaam. Elke cel is een afzonderlijk geheel met een beperkte functionaliteit en verantwoordelijkheid. Samen vormen de cellen organen die ook elk hun eigen functie en verantwoordelijkheid hebben. De organen vormen gezamenlijk het gehele systeem: het lichaam. In het grote geheel van het menselijk lichaam is het zowel van belang dat elk element afzonderlijk goed functioneert als dat de elementen op de juiste wijze samenwerken en communiceren. Voor objecten geldt hetzelfde. Elk object dient zijn taak (verantwoordelijkheid) goed uit te voeren en elk object dient samen te werken met andere objecten, soms objecten van dezelfde soort, soms objecten van een andere soort. Ook objecten worden in een softwaresysteem samengevoegd tot een soort ‘orgaan’. In UML bestaat zowel het packagemechanisme als het begrip component. Beide vormen deelstructuren in het systeem bestaande uit objecten.
2.3 V ERSCHILLEN MET TRADITIONELE ONTWIKKELING 2.3.1 Functionele decompositie versus domeinmodellering De traditionele functioneel georiënteerde systeemontwikkeling begint bij de functionaliteit die het systeem moet gaan bieden. Uitgaande hiervan wordt een ontwikkeltraject gestart met als doel om de gevraagde functionaliteit te leveren. Dit leidt tot functionele decompositie tot op het niveau dat de functies eenvoudigweg geprogrammeerd kunnen worden.
VERSCHILLEN MET TRADITIONELE ONTWIKKELING 7
Deze methode zal een systeem opleveren dat voldoet aan de originele gevraagde functionaliteit. Aanpassingen en uitbreidingen zijn vaak moeilijk te realiseren en kosten véél werk. Omdat alle subfuncties in eerste instantie gemaakt zijn om de oorspronkelijke functies te ondersteunen betekent een kleine wijziging in een oorspronkelijke hoofdfunctie meestal aanpassingen in vele subfuncties tot op het laagste niveau. Het toevoegen van een geheel nieuwe functie betekent het geheel opnieuw maken van die functie en bijbehorende subfuncties. Er is weinig reden om aan te nemen dat een van de bestaande subfuncties binnen de context van de nieuwe functie ook zal werken. Objectgeoriënteerde ontwikkeling gaat uit van domeinmodellering. Hierbij wordt de werkelijkheid waarin het systeem een rol speelt (het domein) in kaart gebracht. Dit levert een domeinmodel op. Hierin staan de concepten uit het domein met hun kenmerken, gedrag en onderlinge relaties. Dit model kan via een aantal één-op-één transformaties geïmplementeerd worden. Toch is dit model nog volledig onafhankelijk van de gevraagde functies. Het toevoegen van de systeemfuncties is nu voornamelijk het in bepaalde volgorde, onder bepaalde omstandigheden gebruiken van de al gedefinieerde operaties van de objecten gedefinieerd in het model. Het toevoegen van nieuwe functies vergt op deze manier weinig wijzigingen en meestal weinig werk. De functionaliteit zit al in de objecten, maar moet slechts in de juiste combinatie ingezet worden. Dit levert bijzonder flexibele systemen op, waarbij op iedere verandering van de organisatie en/of de gebruiker direct gereageerd kan worden. Objecttechnologie maakt zo een flexibele bedrijfsondersteuning mogelijk.
2.3.2 Verschillen met datageoriënteerde ontwikkeling Binnen de traditionele datageoriënteerde systeemontwikkeling wordt wel vaak domeinmodellering toegepast. Wat dit betreft sluit datageoriënteerde ontwikkeling beter aan bij objectgeoriënteerde ontwikkeling, maar datageoriënteerde ontwikkeling legt de nadruk alleen op de statische aspecten van het systeem. Een voorbeeld daarvan is het feit dat 4GLs binnen deze stroming zo populair zijn. Een 4GL biedt de mogelijkheid om heel snel functies te koppelen aan een op zich goede datastructuur. Er wordt echter zo weinig aandacht besteed aan de structuur van de functies dat de onderhoudbaarheid van programmatuur geschreven in een 4GL ronduit slecht te noemen is. Overigens is het feit dat de meeste relationele databases op dit moment een vorm van stored procedures ondersteunen, een teken dat ook in die kringen de eenzijdige nadruk op statische aspecten als een nadeel gezien wordt.
8
OBJECTGEORIËNTEERDE SYSTEEMONTWIKKELING
In de objecttechnologie wordt voldoende aandacht besteed aan de dynamiek van een softwaresysteem. UML bevat vier diagrammen die verschillende aspecten van deze dynamiek belichten. Het op juiste wijze samenvoegen van functies van diverse objecten om zo te komen tot de realisatie van een systeemfunctie wordt in deze diagrammen beschreven.
2.4 D E SOFTWARE - LEVENSCYCLUS EN NAADLOZE ONTWIKKELING Het concept object speelt binnen de objecttechnologie een centrale rol in alle fasen van de systeemontwikkeling. Dit betekent dat objecten uit de werkelijkheid die in de analysefase zijn gemodelleerd, zoals auto of stoel, tot in de implementatie terug te vinden zijn als objecten. Dit in tegenstelling tot traditionele methoden, die in alle fasen verschillende concepten gebruiken. Bij deze traditionele methoden is bij iedere faseovergang een transformatie van het ene naar het andere concept nodig. Binnen de objecttechnologie zijn dit soort transformaties overbodig. Het resultaat van de ene fase is letterlijk het startpunt voor de volgende fase. In figuur 2-1 staat dit proces voor een eenvoudig geval van drie fasen weergegeven. In de traditionele methoden is de transformatie bij een faseovergang slechts gedefinieerd van boven naar beneden. Een transformatie terug, van objectgeoriënteerd
traditioneel (SA/SD) Analyse
DFD's
objecten
transformatie structure charts
Ontwerp
objecten
Implementatie
objecten
transformatie
COBOL
Figuur 2-1 Faseovergangen
DE SOFTWARE-LEVENSCYCLUS EN NAADLOZE ONTWIKKELING 9
een fase naar een voorgaande fase, is in het algemeen niet mogelijk. Omdat hier toch behoefte aan is, is een geheel nieuw vakgebied ontstaan: reverse engineering. Binnen het objecttechnologietraject is het teruggaan naar de voorgaande fase, vanwege de één-op-één afbeelding van de modellen, net zo makkelijk als de overgang naar een volgende fase. Dit heet reversability. Bij een verandering in een willekeurige fase is het gevolg voor alle andere fasen eenvoudig te traceren. Met name tijdens het onderhoud is dit een belangrijk voordeel. De term die diverse case-tools hanteren voor de mogelijkheid om veranderingen in een bepaalde fase ook in andere fasen door te voeren is round-trip-engineering. De directe overgang tussen de verschillende fasen wordt ook wel naadloze ontwikkeling (Eng. seamless development) genoemd. Iteratieve en incrementele werkwijzen waarbij meerdere malen door alle fasen gegaan wordt, zijn binnen objecttechnologie dan ook een natuurlijke manier van werken. Het gebruik van dergelijke werkwijzen betekent dat de manier waarop aangekeken wordt tegen de software-levenscyclus aangepast moet worden. Niet langer geldt dat een softwaresysteem gedurende zijn ‘levensloop’ achtereenvolgens de conceptualisatiefase (Eng. requirements phase), analysefase, ontwerpfase, implementatiefase, testfase, gebruiksfase doorloopt. Delen van het systeem kunnen in de testfase zijn, terwijl andere delen van het systeem in de analysefase zijn.
2.4.1 Veranderingen in projectmanagement Deze mogelijkheid om combinaties te maken van softwaredelen in verschillende fasen stelt hoge eisen aan het management van een iteratief en incrementeel softwareproject. Time-boxing is een manier om een dergelijk project te managen. Deze manier deelt het gehele traject op in een aantal time-boxes. De kosten en de einddatum van de time-box liggen altijd vast, wat kan variëren is hoeveel van het systeem binnen die tijd geïmplementeerd wordt. Elke time-box kan wel worden opgedeeld in een conceptualisatiefase, analysefase, ontwerpfase, enzovoorts. Aan het begin van het traject kan het gehele systeem in delen, zogeheten incrementen, worden opgedeeld, maar ook tijdens het traject kan gekozen worden voor een bepaalde opdeling. Elk increment wordt in een time-box geïmplementeerd. Vanaf het moment dat de eerste time-box is afgelopen is er dus een werkend systeem. Dit systeem kan heel erg klein zijn, met zeer beperkte functionaliteit. Van belang is echter dat het werkt en dat het compleet is, met alle documentatie enz. Elke volgende time-box werkt nu verder met de basis die in de eerste time-box gelegd is. Aan het eind van een time-
10
OBJECTGEORIËNTEERDE SYSTEEMONTWIKKELING
box wordt vaak een beslismoment ingelast. Op dit moment wordt het traject geëvalueerd en worden beslissingen genomen over de vervolgstappen. Ook is het mogelijk om niet verder te gaan met het project. Een bruikbaar, werkend systeem resulteert, onafhankelijk van deze beslissing.
2.5 S AMENVATTEND In dit hoofdstuk is beknopt aangegeven waarom objecttechnologie een positieve invloed kan hebben op begrijpelijkheid, kwaliteit, flexibiliteit en onderhoud. Natuurlijk is een degelijke methodische aanpak nodig om deze voordelen in de praktijk waar te kunnen maken. De rest van dit boek beschrijft de Unified Modeling Language (UML), een taal waarin de noodzakelijke structuur van een objectgeoriënteerd systeem vastgelegd kan worden. Het belang van UML ligt dan ook niet in de taal zelf, maar in de wijze waarop UML het bereiken van bovenstaande voordelen ondersteunt. De beschrijving van UML is dan ook vanuit dit praktische perspectief opgezet.
