Na een periode van betrekkelijke rust maken case-tools, gestimuleerd door de belangstelling voor object-oriëntatie, opnieuw hun opwachting. Oo-case-tools hebben tot doel het ontwikkelen van object-georiënteerde software zo goed mogelijk te ondersteunen. Om een beeld te krijgen van de stand van zaken op het gebied van deze hulpmiddelen organiseren Computable en het Software Engineering Research Centre (SERC) een evaluatieproject.
In het OO-Case Evaluatieproject worden de tools op basis van een aantal criteria geëvalueerd. De belangrijkste criteria komen hier punt voor punt aan bod.
Rol in het ontwikkeltraject. Een oo-case-tool kan op verschillende manieren en tijdens verschillende fasen worden ingezet. Sommige ontwikkelaars zien het tool als het ‘hart’ van het ontwikkeltraject, andere zien het bijvoorbeeld alleen als hulpmiddel om documentatie te maken. Als het tool een leidende rol in het proces inneemt, is het belangrijk dat de consistentie tussen de verschillende modellen gewaarborgd is. Een tool kan de gehele software-levenscyclus ondersteunen of slechts delen daarvan. In het laatste geval is mogelijke integratie met andere tools van belang.
Software-architectuur. Tools kunnen ondersteuning bieden bij het toepassen van een standaard architectuur of bij het ontwikkelen binnen een framework. Ook kan het tool het opstellen van eigen architecturen en frameworks ondersteunen.
Ontwikkelmethoden. Tools kunnen de notatie en het ontwikkelproces van bekende objectgeoriënteerde ontwikkelmethoden ondersteunen, zoals OMT, Booch en Objectory. Daarnaast kan het mogelijk zijn een eigen ontwikkelmethode te gebruiken. Een keuze voor een bepaalde methode is eventueel later te veranderen.
Generatie. Oo-case-tools zouden de mogelijkheid kunnen bieden om de vertaalslagen tussen de verschillende modellen automatisch uit te voeren. Voorbeelden zijn het automatisch genereren van code en rapporten. Hierbij is het van belang te weten voor welke programmeertalen (bijvoorbeeld Java en C++), welke platformen (bijvoorbeeld Windows95) en welke omgevingen (bijvoorbeeld Corba en DCom) het tool kan genereren en welke modellen nodig zijn om te kunnen genereren.
Reverse engineering. Het is van belang bestaande software te kunnen hergebruiken door ‘reverse engineering’ toe te passen. Daarbij zet het tool bestaande software (bijvoorbeeld code) automatisch om naar één of meer modellen. Hierbij is het van belang te weten welke modellen de ontwikkelaar kan verkrijgen uit de bestaande software. Ook kan het tool ondersteuning bieden bij het inbedden van bestaande software in de nieuwe software, bijvoorbeeld middels ‘wrapping’.
Gebruik van het tool. De eenvoud en gebruiksvriendelijkheid van het gebruikersinterface is een belangrijk criterium. Omdat het tool mogelijk veel verschillende soorten modellen ondersteunt, waartussen veel afhankelijkheden kunnen bestaan, is het belangrijk dat de gebruiker de complexiteit kan beheersen. Deze complexiteit kan ook ontstaan door ‘reverse engineering’. Tools kunnen samenwerking tussen verschillende ontwikkelaars ondersteunen. Dit kan bijvoorbeeld door een vorm van versie- en configuratiebeheer of mogelijkheden tot autorisatie te bieden.
Verbetering productiviteit. Om de productiviteit te verhogen kunnen tools hergebruik faciliteren en zelfs stimuleren. Hergebruik is alleen goed mogelijk als het weinig inspanning van de ontwikkelaars vraagt. Een andere manier om productiviteit te verbeteren, is het instellen van tools naar specifieke eigen wensen. Tools zouden de mogelijkheid kunnen bieden om nieuwe ‘intelligentie’ toe te voegen; ze kunnen dan op maat gemaakt worden.
Verbetering kwaliteit. Het tool kan de kwaliteit van de modellen en het uiteindelijke softwareproduct verbeteren door automatische controle van consistentie. Ook kan het analyseren van modellen, bijvoorbeeld door simulatie of metrieken, een goed hulpmiddel zijn voor kwaliteitsverbetering.
Hernieuwde belangstelling
Aanleiding voor het OO-Case Evaluatieproject is het feit dat zowel de opkomst van de object-oriëntatie (oo) als ook de technologische ontwikkelingen de laatste jaren voor een hernieuwde belangstelling voor case-tools hebben gezorgd. In de nieuwe generatie hulpmiddelen gebruikt de ontwikkelaar objectgeoriënteerde modellen voor het documenteren, ontwerpen en ontwikkelen van software. De introductie van UML (Unified Modeling Language) als de facto standaard notatietechniek heeft een extra impuls gegeven aan de toenemende interesse voor deze tools. Daarnaast heeft ook de explosief groeiende toepassing van Java de belangstelling vergroot.
In tegenstelling tot ’traditionele’ software-ontwikkeling, waar processen en de daarbij gebruikte gegevens strikt gescheiden zijn, deelt een objectgeoriënteerde aanpak het systeem op in zelfstandige componenten. Deze componenten, beter bekend als ‘objecten’, bevatten zowel functionaliteit (gedrag) als gegevens (toestand). Ieder object heeft een interface, een lijst van diensten die het object aanbiedt.
Alle communicatie tussen objecten gaat via de in de interface aangeboden diensten. Dit betekent dat de ‘binnenkant’, de implementatie, van een object verborgen blijft voor de buitenwereld zolang het object de diensten maar kan waarmaken. Het verbergen van implementatiedetails door middel van een interface wordt ‘encapsulatie’ genoemd. De interface waar een object aan moet voldoen, wordt gedefinieerd in een ‘klasse’; elk object behoort tot een bepaalde klasse. De klassen zijn als het ware een blauwdruk voor de objecten.
Een softwaresysteem dat op objectgeoriënteerde wijze is ontwikkeld bestaat uit samenwerkende objecten die elk specifieke verantwoordelijkheden hebben. Als deze opdeling van het systeem goed gebeurt, neemt de onderhoudbaarheid en de herbruikbaarheid van de onderdelen aanzienlijk toe.
Software-architectuur
Door het systeem te beschrijven in termen van zelfstandige en geëncapsuleerde componenten levert object-oriëntatie de middelen om herbruikbare en flexibele software te ontwikkelen. Echter, zolang de software-ontwikkeling primair op programmeerniveau plaatsvindt, is het moeilijk van die voordelen te profiteren.
Een mogelijkheid om de kwaliteit van software-ontwikkeling te verbeteren, is de aandacht te verschuiven van de implementatie van systemen naar specificatie op architectuurniveau. De architectuur beschrijft de onderdelen van een systeem en hoe deze onderdelen samenwerken. Bekende voorbeelden van architecturen zijn de client/server-architectuur en de lagenarchitectuur (drie-lagenarchitectuur, OSI-netwerkmodel). Het gebruik van een architectuur maakt het mogelijk de systemen op een hoog niveau van abstractie te beschrijven en te analyseren zonder te verzanden in (technische) details van de implementatie. Dit stelt ontwikkelaars in staat om te werken aan steeds groter en complexer wordende softwaresystemen.
Door het verschuiven van de aandacht naar specificatie wordt het modelleren van de software belangrijker dan het coderen en vormt de architectuurbeschrijving de basis van de software-ontwikkeling. Tijdens de eerste fasen van het ontwikkeltraject stellen de ontwikkelaars gewoonlijk specificaties en een domeinmodel op. De specificaties beschrijven aan welke voorwaarden het uiteindelijke systeem moet voldoen; het domeinmodel is een objectmodel waarin de relevante begrippen uit het probleemdomein zijn gemodelleerd.
Na het opstellen van de eisen en het domeinmodel kiezen de ontwikkelaars een architectuur voor de oplossing of stellen er één op. Bij deze stap kunnen de ontwikkelaars gebruik maken van standaardarchitecturen en standaardcomponenten. Na deze architectuurfase volgen onder andere het ontwerpen van de te bouwen software en de implementatie. Tijdens beide fasen nemen de ontwikkelaars vele technische ontwerpbeslissingen die onder andere te maken hebben met het gewenste systeemgedrag en de gewenste infrastructuur. Software-ontwikkeling vindt in het ideale geval plaats door een ‘fit’ te vinden tussen het op te lossen probleem, een te gebruiken standaardarchitectuur en de gewenste infrastructuur. Als de ontwikkelaars daarbij technische beslissingen zo lang mogelijk kunnen uitstellen, komt dat ten goede aan de aanpasbaarheid en herbruikbaarheid van het systeem.
Het gebruiken van standaardarchitecturen, componenten en automatische vertaalslagen (bijvoorbeeld codegeneratie) kan het ontwikkelproces niet alleen verbeteren, maar ook versnellen.
Ondersteuning ontwikkelaars
Om optimaal objectgeoriënteerde software te kunnen bouwen heeft de ontwikkelaar ondersteuning nodig. Deze ondersteuning bieden objectgeoriënteerde case-tools; case-hulpmiddelen waarbij de ontwikkelaars object-oriëntatie gebruiken om modellen te maken. De tools kunnen onder andere hulp bieden bij de verschillende vertaalslagen die nodig zijn tussen de fasen van het ontwikkelproces, zoals bijvoorbeeld codegeneratie.
Een oo-case-tool zou de modellen die resultaat zijn van de ontwikkelstappen automatisch consistent kunnen houden. Bovendien nodigen de verschillende modellen, die tijdens het traject ontstaan, uit tot hergebruik indien het tool dat expliciet ondersteunt. Andere activiteiten waarbij dergelijk gereedschap ondersteuning kan bieden, is het opstellen van modellen, het analyseren van ontwerpen, het verzamelen van metrieken en het samenstellen van rapporten.
Deze schets van objectgeoriënteerd case-gereedschap roept een aantal vragen op: In hoeverre is het geschetste beeld van de mogelijkheden van oo-case-tools en hun rol in het ontwikkeltraject werkelijkheid? In hoeverre ondersteunen ze het geschetste software-ontwikkelproces? Kortom, wat is de stand van zaken? Het door Computable en SERC georganiseerde evaluatieproject probeert een antwoord te vinden op deze vragen.
Mark van Elswijk en Rob Maijers,
onderzoekers bij het Software Engineering Research Centre (Serc) te Utrecht.