Sinds zijn introductie is UML als notatie voor softwareontwerpen steeds verder ingeburgerd geraakt. De praktische toepassing is echter vaak nog mijlen verwijderd van de doelstellingen die de bedenkers van de taal voor ogen hadden. Zijn deze doelen te ambitieus geweest of ligt de oorzaak bij de gebruikers en hun omgeving?
’In de praktijk is UML een contraproductief hulpmiddel bij software- en sys-teemontwerp‘, poneert Gerrit Muller van het ESI in een van de stellingen bij zijn proefschrift. Een prikkelende uitspraak die hij ongetwijfeld niet alleen maar als opvullertje heeft opgenomen. De oorzaak van de vermeende contraproductiviteit ligt namelijk niet in de eerste plaats bij de Unified Modeling Language zelf, maar bij de gebruikers en de manier waarop zij met de taal omgaan.
UML is een technisch hulpmiddel voor software- en systeemontwerpers. Zoals voor alle gereedschappen geldt ook hier dat gebruikers voor een succesvolle en productieve toepassing ervan aandacht moeten besteden aan een aantal technische, organisatorische en procesmatige factoren (zie ook het kader ’TOP‘). Een aantal daarvan, misschien wel de belangrijkste, neem ik in dit artikel onder de loep.
Technisch
Zoals de naam al aangeeft, is UML een modelleertaal. Het formalisme heeft zijn wortels liggen in objectgeoriënteerde softwareontwikkeling, maar is ook heel goed toepasbaar voor functioneel ontwerp en zelfs voor het ontwerp van niet-softwaresystemen. Het blijft echter een taal, een notatiewijze, en geen ontwikkelmethode. Gebruikers, zoals developmentmanagers die een procesverbetertraject op poten zetten, zien dat regelmatig over het hoofd.
Niet heel lang geleden hoorde ik iemand zeggen dat de op functionele decompositie gebaseerde Hatley-Pirbhai-methode nu toch echt uit de tijd is. Dat kan echter nooit een reden zijn om over te gaan op UML. Hatley-Pirbhai is een combinatie van een werkwijze en een notatie. UML is alleen het laatste en overstappen zonder zorgvuldig na te denken over het eerste is vragen om problemen. Overigens is het heel goed mogelijk om de Hatley-Pirbhai-werkwijze te combineren met UML. In 2000 heeft Derek Hatley de methodiek samen met Peter Hruschka verder uitgewerkt en de notatie gedeeltelijk vervangen door UML. De werkwijze hebben ze echter overeind gehouden en verder verfijnd.
Dat UML een ontzettend rijke (en uitbreidbare) taal is, maakt dit soort redeneringen nog gevaarlijker. Afhankelijk van hun achtergrond, leergierigheid en manier van denken gaan ontwikkelaars er op verschillende manieren mee om. De een volgt strikt de semantiek beschreven in de UML-standaard, de ander probeert de symbolen te gebruiken als vervanging van een functionele notatie. De beoogde unificatie van taal en werkwijze gaat zo verloren in een soort van Babylonische spraakverwarring op modelniveau. Het is heel belangrijk om UML als een taal te beschouwen en de grammaticale regels van die taal te respecteren.
Onderdeel van de keuze voor UML en een werkwijze is ook de keuze van ondersteunend gereedschap. De belangrijkste vraag die organisaties zich dan moeten stellen is waarvoor ze UML gaan gebruiken in de context van de gekozen methode. Maken ze architectuurmodellen die ze met stakeholders bespreken, willen ze code uit de diagrammen genereren of kalken ze alleen diagrammen op een whiteboard tijdens brainstormsessies? In de praktijk komt het regelmatig voor dat bedrijven een duur UML-ontwerppakket kiezen, terwijl architecten en ontwikkelaars uiteindelijk het grootste deel van het werk in de brainstormkamer doen. Vervelend, want daar komen plaatjes op het bord die soms niets met UML te maken hebben. Vertaald naar UML en ingevoerd in het pakket blijken ze vaak net niet te kloppen met wat tijdens de brainstorm is bedacht. Zonde van de tijd, zonde van het geld.
In het geval dat organisaties er voor kiezen om alle modellen in een ontwerppakket op te maken, en er mogelijk zelfs de code uit te genereren, is het zaak om uit alle software die UML-modellering mogelijk maakt het juiste product te kiezen. Sommige pakketten richten zich op zo volledig mogelijke UML-ondersteuning, andere leggen de nadruk op codegeneratie. De combinatie van de twee is nog zeldzaam, al werken leveranciers als Borland, IBM/Rational en Sparx Systems daar hard aan. Een extra complicatie bij de keuze voor een softwarepakket is de lijst van ondersteunde UML-onderdelen. Sprekers van een taal benutten nooit de volledige woordenschat en hetzelfde geldt voor UML. Bij de pakketkeuze moeten organisaties voor ogen hebben welke van de dertien UML 2.0-diagrammen ze gaan gebruiken en welke constructies daarin wel of niet belangrijk zijn.
Bij de toepassing van een ontwerppakket hangt de mate van succes ook af van het wel of niet maken en nakomen van afspraken over het gebruik van UML-notaties en het afspreken en controleren van designregels. De kunst is om zodanig veel van UML te adopteren dat het model eenduidig wordt, en zodanig weinig dat het voor alle betrokken ontwikkelaars begrijpbaar blijft. Overigens is het ook bij deze werkwijze nog steeds zo dat de beste ideeën vaak uit de brainstormkamer komen.
Organisatorisch
De organisatorische aspecten spelen al een rol bij de invoering van UML. Die introductie is in de praktijk vanuit meerdere richtingen te initiëren. Zo kan er een UML-ontwerppakket beschikbaar zijn, dat pas wordt gebruikt als er een nieuwe medewerker arriveert met (enige) UML-kennis. Dit steekt andere ontwikkelaars aan en informeel en ongecontroleerd groeit het gebruik van UML, tot het moment dat een architect of manager dit oppikt en er structuur in gaat aanbrengen. Een moeizaam proces, dat veel tijd kost en aanvankelijk weinig oplevert omdat nog te veel bij individuen blijft hangen. Bovendien bestaat er een risico van kwaliteitsverlies (zowel wat runtime gedrag betreft als qua onderhoudbaarheid) op de grenzen van subsystemen waarvan het beheer in handen is van ontwikkelaars met verschillende inzichten en werkwijzen.
Een andere reden om UML te introduceren is vaak de ontwikkeling van een nieuw product, waarbij architecten en ontwikkelaars de mogelijkheid aangrijpen om meer state-of-the-art te werk te gaan. Hier kan de kwaliteit van het ontwikkeltraject en het uiteindelijke product sterk verbeteren ten opzichte van oude producten door vergrote betrokkenheid van medewerkers. Een risico is het onderhoud van de vorige generatie, omdat iedereen mee zal willen doen met de nieuwe hype en het oude zo snel mogelijk wil vergeten.
Een derde aanleiding kan zijn dat het management UML en een beschikbaar gereedschap (bijvoorbeeld door een package deal) op een groep ontwikkelaars dumpt met de boodschap dat dit voortaan de manier van werken is. In deze situatie is vaak geen besef van de technische basis achter UML aanwezig en duurt het een behoorlijke tijd voor het management daarvan is doordrongen en budgetten voor opleiding en herstructurering van activiteiten beschikbaar komen. Bij de ontwikkelaars ontstaat dan al snel een grote weerstand tegen het gebruik van de opgelegde gereedschappen.
Wat belangrijk is bij de invoering van UML is directe betrokkenheid van architecten en ontwikkelaars bij het moment en de wijze van invoeren. Rechtstreeks gevolg daarvan moet zijn dat organisaties de juiste pakketten en cursussen selecteren, en de juiste processen definiëren, door (of in ieder geval in overleg met) de mensen die er uiteindelijk ook mee moeten gaan werken. Na de invoering van UML als hulpmiddel en het zonodig doorvoeren van veranderingen in de manier van werken is het zaak om de continuïteit te waarborgen, enerzijds door bewaking van de werkwijze in de vorm van ’sociale controle‘, anderzijds door ondersteuning vanuit processen en procedures. Daarnaast moet de ontwikkelafdeling ook voortdurend ondersteuning krijgen in de vorm van training en bijscholing en nieuwe versies van ontwerppakketten.
Let wel, dit alles heeft geen zin als het niet voor iedereen in de organisatie duidelijk is waarom er met UML wordt gemodelleerd. Het belang van modellen in softwareontwikkeling is gelijk aan het belang van de bouwtekening in de bouwwereld. Als niet iedereen, ontwikkelaars én management, dat in het achterhoofd houdt, is UML een leuk hulpmiddel voor individuen en geen productief onderdeel van softwareontwikkeling.
Procesmatig
Processen richten zich op het beheersen van activiteiten die onderdeel uitmaken van softwareontwikkeling. Een procesbeschrijving bestaat in de meeste organisaties uit een set van procedures. Elke procedure beschrijft hoe binnen die organisatie een bepaalde ’deliverable‘ (bijvoorbeeld een ontwerp) totstandkomt of wordt geverifieerd en gecorrigeerd. Een deel van die procedures zal afhankelijk zijn van de gekozen softwareontwikkelmethode. Omdat UML enkel een modelleertaal is, hebben de gekozen procedures slechts indirect invloed op het gebruik ervan – de invloed van procedures op de gevolgde werkwijze is veel groter.
Dit geldt voor de meeste gangbare ontwikkelmethodieken waarin UML een rol speelt. Een uitzondering is Model Driven Development. Bij deze op de Model Driven Architecture gebaseerde aanpak draait het ontwikkelproces om modellen van software waaruit na een aantal transformaties uiteindelijk code wordt gegenereerd. Hier positioneert de Object Management Group (OMG) UML als de voorkeurstaal. De modellen vormen echter het hart van de aanpak en zijn daarmee veel belangrijker dan de UML-plaatjes, die vaak louter als illustratie in een specificatie worden geplakt. De nadruk in procedures zal in dit geval dus veel directer op de UML-modellen liggen, met name waar het activiteiten als reviews betreft.
Geen doel maar een middel
Het nut van een bouwtekening is al eeuwen geleden aangetoond, evenals het nut van standaard notaties. In het nog onvolwassen domein van software-engineering is dit echter nog lang niet overal doorgedrongen. Het waanidee dat software schrijven eenvoudig is en dat ontwerpen alleen maar tijd kost, is helaas nog te wijdverbreid. UML als modelleertaal kan een deel van dit probleem oplossen, zonder dat dit ten koste gaat van productiviteit. Vaak neemt die zelfs toe. Waarschijnlijk refereert Gerrit Muller in zijn stellingen dan ook niet aan de contraproductiviteit van UML, maar aan die van de werkwijze rondom de toepassing van de taal.
Doelmatig gebruik van UML is alleen mogelijk als organisaties vooraf een aantal afwegingen maken. Op technisch gebied moeten gebruikers UML zien als wat het echt is: een modelleertaal, met een vastgestelde syntaxis en semantiek – een hulpmiddel voor ontwikkeling, geen doel op zich. Verder is het zaak om een manier van werken te definiëren waarin UML als modelleertaal past, liefst gebaseerd op een geaccepteerde ontwikkelmethode. Een effectieve invulling hiervan vraagt bovendien om de keuze voor passende gereedschappen, die zowel taal als werkwijze ondersteunen. Op het organisatorische vlak speelt betrokkenheid van ontwikkelaars en management een belangrijke rol, in de vorm van bewustzijn en verantwoordelijkheid bij de invoering en het gebruik van UML en de gekozen methodiek. Hierbij dient ook een continu beleid ten aanzien van (bij)scholing en onderhoud van gereedschappen te worden ingevoerd. Ten slotte moeten organisaties hun processen afstemmen op de manier van ontwikkelen.
Alleen als aan deze voorwaarden is voldaan, is er voldoende balans tussen de technische, organisatorische en procesmatige aspecten om UML succesvol en productief in te zetten. De taal zelf heeft daar weinig invloed op, de gebruikers des te meer.