Moderne object-georiënteerde case-tools bieden goede ondersteuning voor het opstellen, documenteren en beheren van oo-analyse- en oo-ontwerpmodellen in projecten met meerdere ontwikkelaars. Op dit moment bieden de tools echter nog weinig ondersteuning voor de denk- en werkwijze van object-georiënteerd ontwikkelen, zo concluderen twee medewerkers van Serc.
In het kader van het OO-Case Evaluatieproject onderzocht Serc (Software Engineering Research Centre) in samenwerking met Computable de stand van zaken op het gebied van oo-case-tools (‘object-oriented computer-aided software engineering tools’).
De onderzochte tools zijn sterk in het vastleggen en inzichtelijk maken van een oo-model. Ze bieden uitgebreide ondersteuning voor met name analyse en ontwerp van object-georiënteerde software. De mogelijkheid om uit een model skeletcode te genereren, motiveert een ontwikkelteam eerst een goed ontwerp te maken. Ontwikkelaars moeten de overige code zelf toevoegen, waarna de tools ondersteuning bieden voor het consistent houden van code en model. Daarnaast bieden de tools uitgebreide mogelijkheden om de gemaakte modellen te beheren en te verwerken tot ontwerpdocumentatie. De onderzochte tools maken een efficiëntere communicatie binnen ontwikkelteams mogelijk en mede daardoor is het uiteindelijke systeem eenvoudiger te onderhouden.
Alle tools ondersteunen inmiddels UML (Unified Modeling Language). Deze standaard biedt een notatiemethode, maar zegt niets over de te volgen denk- en werkwijze voor het opstellen van oo-modellen. Case-tools vullen dit gat niet op; de tools helpen ontwikkelaars niet actief om te bepalen wanneer zij welke stappen moeten nemen om tot een ontwerp te komen. Om te adviseren bij de vraag hoe je tot een goed ontwerp kunt komen, missen de tools actieve ondersteuning voor het vastleggen en hergebruiken van kennis en ervaring. Het blijkt dus noodzakelijk dat ontwikkelaars zich een beeld vormen van de stappen die nodig zijn om tot een goed oo-ontwerp te komen alvorens een case-tool in te zetten.
Evaluatieproject
Deze stand van zaken blijkt uit het OO-case Evaluatieproject. Het doel van het project was een overzicht te verkrijgen van de mogelijkheden en de ‘state of the art’ op het gebied van het geautomatiseerd object-georiënteerd modelleren en ontwikkelen.
De belangrijkste tool-leveranciers, geselecteerd op aandeel en vertegenwoordiging in de Nederlandse markt, ondersteuning van analyse en ontwerp, en beschikbaarheid voor verschillende talen, zijn Cayenne Software (Object Team), Platinum Technology (Paradigm Plus), Rational Software Corporation (Rose), Select Software Tools (Select Enterprise) en Popkin Software (System Architect). In het evaluatieproject zijn de tools van de eerste vier van deze leveranciers onder de loep genomen.
Deelnemers aan het evaluatieproject, geïnteresseerden uit bedrijfsleven en overheid, hebben in acht teams een casus uitgewerkt, ieder met één van de ontwikkeltools. De deelnemers hebben de evaluatie uitgevoerd aan de hand van een evaluatieraamwerk, waarin weergegeven is wat Serc in een oo-case-tool aan ondersteuning zou willen zien op het gebied van architectuur, patterns en frameworks, ontwikkeltraject en -methoden, roundtrip engineering, metrieken en gebruiksaspecten.
Architectuur, ‘patterns’ en ‘frameworks’
Het ontwikkelen van object-georiënteerde software is niet eenvoudig. Ook (of juist?) met UML blijft het lastig te bepalen wat zinnige objecten zijn, welke verantwoordelijkheden klassen hebben en hoe objecten samenwerken om bepaalde taken uit te voeren. Kortom: wat is een goed oo-model?
Kennis en ervaring blijft de enige waarborg voor kwaliteit. Hergebruik van kennis en ervaring, bijvoorbeeld vastgelegd in standaardoplossingen voor analyse-, ontwerp- of implementatieproblemen, kan helpen bij het oplossen van terugkerende problemen en op die manier de kwaliteit van de opgestelde modellen verhogen. In het ideale geval bieden case-tools actieve ondersteuning voor het werken met deze standaardoplossingen.
Standaardoplossingen als architecturen, ‘frameworks’ en ‘patterns’ bestaan uit een oplossingsstructuur en richtlijnen voor toepassing. Deze oplossingen kunnen op verschillende abstractieniveaus zijn vastgelegd. Een architectuur beschrijft de algemene structuur van een systeem. Standaardarchitecturen, zoals de bekende drie-lagen architectuur, bieden de ontwikkelaars een beproefde blauwdruk voor een systeem. Een dergelijke blauwdruk beschrijft een oplossing in termen van de componenten van een systeem, de rollen die deze componenten spelen en de onderlinge relaties. Aan de hand van de blauwdruk kunnen ontwikkelaars vervolgens een gedetailleerde bouwtekening voor een systeem maken.
Op een wat lager abstractieniveau beschrijven ‘patterns’ niet zozeer een systeem als geheel, maar delen van een systeem, en geven zo een aanzet voor specifieke onderdelen van de bouwtekening. Design patterns (‘micro-architecturen’) beschrijven bijvoorbeeld oplossingen voor veel voorkomende ontwerpproblemen in termen van rollen die klassen spelen, diensten die klassen moeten bieden en de samenhang tussen klassen.
Een framework tenslotte biedt een gedeeltelijke implementatie van een bouwtekening. Met dit applicatie-skelet kunnen software-ontwikkelaars concrete applicaties ontwikkelen door het op een aantal plaatsen aan te vullen met code of andere specifieke informatie.
Architectuur ontbreekt
Doordat zowel UML als case-tools abstracties zoals architecturen, ‘frameworks’ en ‘patterns’ niet als zodanig onderkennen, bieden de tools weinig ondersteuning voor het werken met deze abstracties. Ontwikkelaars kunnen standaardarchitecturen of oplossingen implementeren door UML-representaties van generieke oplossingen in case-tools vast te leggen en te hergebruiken. De tools missen echter de actieve ondersteuning, zoals het herkennen en consistent houden van abstracties. Die is hoognodig als hulp bij het ontwikkelen van kwalitatief hoogwaardige en flexibele oo-modellen.
Het begrip architectuur is in Rational Rose en Select Enterprise momenteel alleen grafisch terug te vinden als scheidingslijnen in een component- of klassendiagram, maar is puur cosmetisch van aard. In de andere geëvalueerde tools ontbreekt architectuur als abstractie volledig. Ook ‘pattern’-ondersteuning is in case-tools zeer beperkt. Voor Paradigm Plus en Rational Rose is weliswaar een pattern-catalogus beschikbaar waarin klassenmodellen voor een aantal bekende ‘design patterns’ zijn opgenomen, maar deze pattern-beschrijvingen dienen slechts als voorbeeld voor het opstellen van concrete klassenmodellen. Rational Rose ondersteunt middels een add-in van een derde partij het vastleggen en instantiëren van patterns. In Paradigm Plus komt het gebruiken van de patterns vooral neer op handwerk of scripting. Het herkennen en consistent houden van toegepaste patterns blijft in beide tools momenteel de verantwoordelijkheid van de ontwerper.
Voorzieningen voor het inzichtelijk maken van bestaande herbruikbare (deel)oplossingen ontbreken in de vier case-tools. De tools bieden de mogelijkheid een verzameling diagrammen herbruikbaar te maken door deze afzonderlijk van het te ontwikkelen model te archiveren. Er zijn echter geen speciale voorzieningen die hergebruik zouden bevorderen zoals voorzieningen voor catalogisering en het doorzoeken van de verzameling. Select Enterprise biedt een integratie met de Select Component Manager, een product dat dergelijke functionaliteit, op componentniveau, wel ondersteunt.
Verschillende gezichtspunten
Bij software-ontwikkeling, object-georiënteerd of niet, is een zestal activiteiten te onderscheiden: eisenanalyse, domeinanalyse, ontwerp, implementatie, testen en exploitatie. De resultaten uit de verschillende activiteiten van het ontwikkelproces worden vastgelegd in modellen. Tussen de verschillende soorten modellen bestaan logische verbanden. In feite zijn deze modellen verschillende views (gezichtspunten) op één en hetzelfde onderliggende model. Vanuit dit standpunt gezien biedt iedere view, van analysemodel tot en met code, de ontwikkelaar een ander gezichtspunt op dezelfde software.
UML biedt een standaardnotatie voor het vastleggen van de verschillende views. UML is echter slechts een notatiemethode en zegt niets over de te volgen procesgang bij software-ontwikkeling. Veel vragen blijven daardoor onbeantwoord: Met welke stap moet ik beginnen? Wat zijn de relevante concepten in deze stap en hoe ver moet ik deze uitwerken? En wat is de volgende stap?
Ook case-tools bieden hier weinig ondersteuning, hoogstens een hypertekstachtige helpdocumentatie over een mogelijk proces. Actieve ondersteuning binnen de tools, die assisteert in de procesgang, ontbreekt.
Hoewel views verschillende gezichtspunten bieden op eenzelfde model, is het waardevol de views die het resultaat zijn van een bepaalde processtap vast te leggen en te bevriezen. Object Team gaat het verst in de ondersteuning, doordat het tool expliciet verschillende fasen en de bijbehorende resultaten kan vastleggen en onderling vergelijken; in de andere case-tools kunnen ontwikkelaars views alleen representeren met tot view verheven diagrammen. De tools bieden geen mogelijkheden voor het leggen van relaties tussen views of het eenvoudig wisselen tussen views.
Ondersteuning van UML
Van eisenanalyse tot exploitatie richten de geëvalueerde case-tools zich duidelijk op analyse en ontwerp. Integratie met gespecialiseerde tools voor eisenanalyse maakt ondersteuning van deze eerdere fase van het ontwikkeltraject mogelijk. Door middel van generatie en reverse engineering van code en databasestructuren bieden de case-tools ook een koppeling met ontwikkelomgevingen en dus met volgende fasen uit het ontwikkeltraject.
Naast de activiteiten uit het ontwikkelproces is bij software-ontwikkeling nog een aantal gerelateerde activiteiten van belang, zoals gui-ontwerp en -implementatie, documentatie, versiebeheer, configuratiemanagement en projectmanagement. Case-tools lossen dit over het algemeen op met koppelingen naar gespecialiseerde tools, waarbij Paradigm Plus zich conformeert aan het standaard Cdif-formaat (Case Data Interchange Format).
Object Team biedt geïntegreerd versiebeheer, waarmee de ontwikkelaars ontwerpelementen tot op klassenniveau (en inclusief gegenereerde code) kunnen beheren. De oplossing van andere tools, integratie met versiebeheertools, heeft als nadeel dat versiebeheer alleen op grovere ontwerpelementen plaats kan vinden. Gui-ontwerp en -implementatie blijven in de case-tools buiten beschouwing.
Hoewel de case-tools, met uitzondering van Select Enterprise, verscheidene notatiemethoden ondersteunen (zoals OMT, Booch of UML), ligt de focus van alle leveranciers duidelijk bij UML: ondersteuning voor UML versie 1.1 is aanwezig of wordt zeer binnenkort verwacht. Hoewel UML een standaard is, valt het op dat leveranciers vaak een eigen visie op UML verwerken in de case-tools. Uit de overdadigheid van UML zijn naar eigen inzicht diagrammen of ontwerpelementen weggelaten, in plaats van de gebruiker te laten bepalen welke UML-onderdelen voor een bepaalde taak het meest geschikt zijn. Ook het omgekeerde is het geval: bijna alle tools bieden extra, niet op UML gebaseerde modellen om bijvoorbeeld bedrijfsprocessen of databasestructuren te kunnen vastleggen. Uitbreiding van het onderliggende meta-model is, in ieder geval binnen de tools zelf, niet mogelijk.
Bij het opstellen van oo-ontwerpen is het lastig om grip te krijgen op de dynamische relaties tussen objecten. Hoe werken objecten samen bij het uitvoeren van een bepaalde taak? UML biedt de mogelijkheid het dynamisch gedrag van systemen te modelleren in bijvoorbeeld volgorde- of groepswerk-diagrammen. Select Enterprise kan dit dynamische gedrag ook daadwerkelijk simuleren door animatie van het berichtenverkeer tussen objecten.
‘Roundtrip engineering’
Object-georiënteerde case-tools zouden kunnen assisteren bij het wisselen tussen en het afleiden van views. De enige views die de onderzochte tools kunnen afleiden zijn gedeelten van de implementatie: code en, al dan niet via een uitbreiding, database-schema’s. Codegeneratie levert een raamwerk met de declaraties van klassen, attributen en methoden waarin de ontwikkelaars alleen de inhoud van methoden nog hoeven in te vullen. De voor codegeneratie benodigde informatie komt uit klassendiagrammen. Sommige tools gebruiken bovendien informatie uit componentdiagrammen; de overige diagrammen spelen geen rol bij generatie.
Taalspecifieke eigenschappen van klassen, attributen en methoden introduceren een taalafhankelijkheid in het model. Verdere taalafhankelijkheid veroorzaken de voor generatie noodzakelijke attribuuttypen in klassendiagrammen, tenzij abstracte datatypen zijn gebruikt. In Paradigm Plus en Select Enterprise, die deze mogelijkheid bieden, moeten de ontwikkelaars de abstracte typen uiteindelijk nog afbeelden op taalspecifieke typen. Binnen een sessie met de tools is het mogelijk van implementatietaal te wisselen door de attribuuttypen of de afbeelding aan te passen aan de gekozen taal.
Het omgekeerde van generatie is reverse engineering, waarbij het tool bestaande software automatisch inleest in een model. De onderzochte tools kunnen klassendiagrammen afleiden uit broncode. Verder kunnen ze databasemodellen of klassendiagrammen afleiden uit bestaande databases. Zowel generatie als ‘reverse engineering’ is in de tools aanpasbaar.
De code van methoden is niet gerepresenteerd in de tools; implementatie is dus geen view op het model. Dit leidt tot consistentieproblemen tussen de diagrammen en de broncode wanneer een ontwikkelaar gegenereerde code opnieuw wil inlezen in de diagrammen of aangepaste diagrammen opnieuw wil genereren, het zogenaamde roundtrip engineering. Wanneer een ontwikkelaar bijvoorbeeld in een diagram de naam van een methode wijzigt en opnieuw genereert, genereren vrijwel alle tools een nieuwe methode waarin de eerder geschreven code ontbreekt. Rose omzeilt dit probleem door in het commentaar van een gegenereerde methode een identificerend nummer op te nemen. Select Enterprise maakt het probleem inzichtelijk door gelijktijdige visualisatie van model en code (Java Synchronizer).
Metrieken
Tijdens software-ontwikkeltrajecten kunnen meetgegevens uit het ontwikkelproces ontwikkelaars ondersteunen om kwalitatieve uitspraken en voorspellingen te doen over ontwerp en product. Ook bij het voorspelbaar en beheersbaar maken van oo-projecten – in termen van tijd en geld – kunnen deze meetgegevens behulpzaam zijn. Meten is weten: het doen van gefundeerde uitspraken ten aanzien van voorspelbaarheid, kwaliteit en productiviteit wordt pas mogelijk als projectgegevens stelselmatig zijn vastgelegd en geïnterpreteerd. Case-tools zijn potentieel ideale meetomgevingen doordat veel concrete project- en ontwerpgegevens zijn vastgelegd.
In de praktijk bieden de geëvalueerde case-tools slechts matige ondersteuning voor het bepalen van metrieken. Paradigm Plus en Rational Rose bieden wel de mogelijkheid tot het rapporteren van statistische informatie, maar het bepalen van daarvan afgeleide metriekwaarden ondersteunen deze tools niet. Select biedt als enige leverancier van case-tools meer intelligente ondersteuning middels het apart te verkrijgen product Estimator. Dit tool doet aan de hand van het model in Select Enterprise voorspellingen over de verwachte implementatietijd. Estimator maakt de onderliggende rekenmethode, gebaseerd op ervaringscijfers, echter niet inzichtelijk; het resultaat lijkt daarom enigszins op magie.
Actieve ondersteuning voor ontwikkelaars op basis van metrieken ontbreekt in alle case-tools. Er zijn bijvoorbeeld geen mechanismen die een ontwikkelaar waarschuwen als door het invullen of wijzigen van het model bepaalde metrieken kritieke waarden dreigen aan te nemen. Wanneer het aantal relaties tussen twee klassen hoog wordt -doorgaans een slecht teken – attenderen de tools de ontwikkelaar niet.
Gebruiksaspecten
De gebruikersinterfaces van de onderzochte tools zijn geschikt voor het omgaan met complexe modellen en grote diagrammen. Het is mogelijk informatie uit diagrammen, zoals de attributen en methoden van klassen, te verbergen. Bij ‘reverse engineering’ van grote hoeveelheden klassen kan de ontwikkelaar de inzichtelijkheid verhogen door al dan niet automatisch de klassen over een aantal diagrammen te verdelen. Verder is het vaak mogelijk verwijzingen naar andere (sub)diagrammen aan te brengen, waarmee grote diagrammen inzichtelijk blijven. In Paradigm Plus kan de ontwikkelaar snel en eenvoudig gelijksoortige bewerkingen uitvoeren op grote modellen door middel van een relationele weergave van willekeurige ontwerpelementen en relaties daartussen.
Behalve Rose beschikken alle tools over een repository, waar verschillende ontwikkelaars tegelijk op kunnen werken. De repositories zijn alle van buiten te benaderen middels een open interface of simpelweg omdat het tool een database gebruikt. Daarnaast werken alle leveranciers aan integratie met de Microsoft Repository.
Rose gebruikt bestanden om modelinformatie op te slaan. De ontwikkelaars kunnen modelinformatie delen door deze onder te brengen in pakketten (‘packages’), die de eenheid van hergebruik en autorisatie vormen. Daardoor kan in Rose maar één ontwikkelaar tegelijkertijd een pakket wijzigen. In de andere tools zijn de enige beperkingen dat maar één ontwikkelaar tegelijk de lay-out van een diagram kan veranderen en dat twee ontwikkelaars niet hetzelfde diagramelement kunnen wijzigen. In de andere tools zijn de ontwerpelementen (klassen, use cases, enzovoort) de eenheid van hergebruik en autorisatie.
De onderzochte tools zijn alle in hoge mate uitbreidbaar. Rose en Select Enterprise zijn uitbreidbaar middels een ole-interface en Rose is daarnaast ook aanpasbaar middels Rose script. Voor Rose is veel aanvullende functionaliteit al beschikbaar via add-ins. In Paradigm Plus is met behulp van scripting alle functionaliteit toegankelijk, van de repository tot diagrammen. In Object Team zijn zonder scripting de menu’s en eigenschappen van diagramelementen aanpasbaar. Door middel van ‘scripting’ in Tcl/Tk is de complete functionaliteit aanpasbaar, met uitzondering van de diagrammen.
De onderzochte tools zijn geschikt voor grotere projecten, te meer daar naast de besproken gebruiksaspecten de tools het mogelijk maken zowel clients als servers van verschillende platformen te mengen. Alleen Rose zal vanwege haar beperkte mogelijkheden voor samenwerking minder geschikt zijn voor grote teams.
Stand van zaken
Hoe ontwikkeld zijn ontwikkeltools? Afgezet tegen in het artikel met deze titel (Computable, 6 maart) geschetste ambitieuze raamwerk zijn de individuele oo-case-tools nog niet volgroeid. Vooral op het gebied van meer actieve en intelligente ondersteuning van de verschillende, moeilijke, facetten van oo-analyse en -ontwerp bestaan er voor case-toolleveranciers nog veel uitdagingen. Kennis en ervaring zijn nog steeds alleen in de hoofden van ontwikkelaars aanwezig, niet in tools.
De conclusie dat ontwikkeltools d�s niet ontwikkeld zijn is echter onjuist. Een dergelijk beeld doet geen recht aan de waarde die case-tools nu al kunnen hebben binnen ontwikkeltrajecten. Alle tools zijn volwassen omgevingen die uitgebreide ondersteuning bieden voor analyse en ontwerp van object-georiënteerde systemen en zijn bij uitstek geschikt voor het onderhouden en communiceren van ontwerpen, ook binnen grote ontwikkelteams.
Case-tools zijn volop in ontwikkeling, ook richting de meer ambitieuze onderdelen van het geschetste raamwerk. Op het gebied van bijvoorbeeld ‘patterns’, metrieken of ‘views’ bieden tools incidenteel al ondersteuning die verder gaat dan alleen een passieve vastlegging van modellen. Gecombineerd binnen één tool zouden deze onderscheidende eigenschappen een flinke stap voorwaarts betekenen voor de geautomatiseerde ondersteuning van object-georiënteerde software-ontwikkeling. Het ideale, actieve case-tool lijkt voorlopig echter nog ver weg.
Matthijs Maat en Rob Maijers, onderzoekers bij het Software Engineering Research Centre (Serc) te Utrecht.
Evaluatierapport OO-case-tools
Dit artikel beschrijft de belangrijkste conclusies van het OO-Case Evaluatieproject, dat Serc (Software Engineering Research Centre) in samenwerking met Computable van 11 tot en met 15 mei 1998 organiseerde. Van dit project is ook een gedetailleerd eindrapport verschenen. In het rapport is naast een algemene inleiding over oo-case-tools een gedetailleerde omschrijving van het tijdens de evaluatie gebruikte raamwerk opgenomen. De resultaten van de evaluatie zijn per case-tool uitgesplitst en geven samen met algemene beschrijvingen van de tools inzicht in de bruikbaarheid van tools in specifieke situaties. Het eindrapport wordt afgesloten met een samenvatting van de stand van zaken rond oo-case-tools.
Het eindrapport is voor f 95,- te bestellen bij:
Software Engineering Research Centre
Postbus 424
3500 AK Utrecht
Telefoon: 030 2545412
Telefax: 030 2545948
Email: info@serc.nl
Figuur 1. Huidige stand van zaken rond OO-case-tools.
Afwezig | Mogelijk | Vergaand ondersteund | |
Architectuur | |||
Ontwerpen met standaardoplossingen | o | ||
Hergebruik | o | ||
Ontwikkeltraject | |||
Verschillende views op model | o | ||
Procesondersteuning | o | ||
Integratie met andere tools | o | ||
UML-notatie | o | ||
Roundtrip | |||
Codegeneratie | o | ||
Reverse engineering | o | ||
Roundtrip | o | ||
Code als view op model | o | ||
Metrieken | |||
Verzamelen meetgegevens | o | ||
Actief gebruik meetgegevens | o | ||
Gebruik | |||
Teamontwikkeling | o | ||
Beheersen complexiteit model | o | ||
Uitbreidbaarheid van tool | o |
Figuur 2. Opvallende aspecten van OO case-tools. De haakjes geven aan dat ondersteuning is gerealiseerd met behulp van een apart aan te schaffen product.
Object Team (Cayenne) | Paradigm Plus (Platinum) | Rose (Rational) | Select Enterprise (Select) | |
Architectuur | ||||
Views | o | |||
Patterns | o | (o) | ||
Ontwikkeltraject | ||||
Model simulatie | o | |||
Integratie versiebeheer | o | |||
Roundtrip | ||||
Visualisatie synchronisatie | (o) | |||
Metrieken | ||||
Voorspellingen | (o) | |||
Gebruik | ||||
Kracht scripting | o | o | o | |
Aantal add-ins | (o) | |||
Relationele bewerking repository | o |