Het ontwikkelen van software is een lastige zaak, ondanks alle nieuwe gereedschappen die er op de markt zijn gekomen. ‘Zolang er geen aandacht wordt geschonken aan een goede architectuur, zal software-ontwikkeling altijd wel een moeilijke klus blijven.’ Interview met Grady Booch, de man achter de universele modelleertaal UML.
Grady Booch is één van de grondleggers van object-georiënteerd ontwikkelen. Hij is de drijvende kracht achter de Unified Modelling Language (UML) die eind vorig jaar door de OMG (Object Management Group) als norm is aanvaard, en de technische topman van Rational Software Corp.
Booch is een veelgevraagd spreker. Als geen ander weet hij zijn gehoor te boeien. Hij doorspekt zijn betoog met duidelijk herkenbare voorbeelden en veel humor. Een lezing van een van de oudste voorvechters van object-georiënteerd ontwikkelen en modelleren staat dan ook garant voor een volle zaal. Onlangs was Booch in Nederland. Zo’n 350 kenners waren naar de Rai gekomen om naar hem te luisteren. Zij hoorden over nieuwe technologie, de dingen die blijven en voorbij gaan.
Belang architectuur
Het zijn boeiende tijden voor programmeurs. Er is veel vraag naar hen en er zijn interessante banen te vergeven. Software maakt een snelle ontwikkeling door. Ondanks alle hype in de media hebben allerlei nieuwe programmeertalen echter weinig nieuws gebracht. De productiviteit van de software-ontwikkelaars is de afgelopen jaren nagenoeg constant gebleven. Hetzelfde geldt voor de foutenpercentages in de software. Het programmeren van computers blijft een moeilijke zaak, ondanks al het gereedschap. Wel neemt de complexiteit steeds meer toe. Niet alleen in de Nintendo-spelletjes, maar ook in pacemakers, die nu met 2 Mb geheugen en een 150 MHz Pentiumprocessor zijn uitgerust. Verder moet de software steeds sneller klaar zijn.
Om in software-ontwikkeling vooruitgang te boeken is volgens Booch meer aandacht nodig voor de architectuur. ‘Een schuur kun je bouwen met wat hout, spijkers en een vaag plan. Als je een huis wilt bouwen zijn er genoeg voorbeelden waarop je je kunt baseren. Maar als je een wolkenkrabber of theater wilt bouwen, zul je eerst fundamenteel moeten nadenken over de architectuur. Architecten werken daarbij met bepaalde tekeningen, die universeel leesbaar zijn. Wij hopen met UML iets dergelijks te bereiken voor de software-architectuur’, aldus Booch voor wie modelleren het ontwerpen van een systeemarchitectuur inhoudt in de vorm van een model, zoals architectuurtekeningen een ontwerpmodel van een gebouw vormen.
Booch vindt een goede architectuur van groot belang, aangezien het ontwerp van een zinvolle structuur een verschil van dag en nacht kan uitmaken bij het realiseren van software. ‘Een goede architectuur is een eenvoudige structuur met veel herhalingen. Een wolkenkrabber bouw je met veel mensen en bij software-ontwikkeling en -onderhoud is het niet anders. Dan moet iedereen goed begrijpen wat de bedoeling is, zodat er consistentie in de uitvoering komt.’ De meeste bedrijven volgen echter de Nike-benadering: geef me een opdracht, een compiler en een werkplek, dan kan ik de hele wereld aan. In vroeger tijd werd dit het Wisca-syndroom genoemd: Why Isn’t Sam Coding Anything. Volgens Booch heeft men in Europa meer begrip dan in de Verenigde Staten voor de tijd die nodig is om een structurele opzet te maken.
Zes trends
Op het gebied van software-ontwikkeling heeft Booch een zestal wezenlijke trends geanalyseerd. De eerste trend is dat op componenten gebaseerde systemen (component based systems) de overhand gaan krijgen. "Het is beter en eenvoudiger om software met behulp van losse componenten samen te stellen dan programma"s te schrijven. De componenten mogen niet te klein zijn, anders kun je ze beter en sneller zelf maken. Maar ze mogen ook niet te groot zijn, anders worden ze te specialistisch of te ingewikkeld. We staan nog maar aan het begin van de ontwikkeling. Componenten vormen de komende softwarerevolutie omdat ze op een hoger abstractieniveau gebruikt worden. Toch zullen ze geen panacee zijn voor alle problemen", meent Booch die als tweede trend signaleert dat steeds meer niet-programmeurs zullen gaan programmeren. Dankzij grafische gereedschappen komt het programmeren onder handbereik van iedereen. "Maar", zo waarschuwt Booch, "slechte programmeurs zullen nog steeds misbaksels maken. Dat wordt voor hen alleen maar eenvoudiger. Vandaar dat het belang van een goede architectuur en een zinvol ontwikkelproces blijft en zelfs toeneemt."
"Continu-evoluerende systemen worden de norm. Het wordt onacceptabel dat er elke achttien maanden een nieuwe release wordt opgeleverd", zo omschrijft Booch de derde trend. Om in te spelen op snelle veranderingen in de markt, is het noodzakelijk om veranderingen sneller aan te brengen. Dat hoeft geen probleem te zijn, aangezien in de meeste bedrijven de basis maar langzaam verandert. Door een goede architectuur moeten de veranderlijke delen geïsoleerd worden van de blijvende, zodat ze snel kunnen worden aangepast.
"Computersystemen krijgen steeds meer een gedistribueerd en realtime karakter. Vrijwel iedereen ziet het Web als de ultieme vorm hiervan. In zekere zin is dat ook wel zo, maar in veel opzichten gaan we met het Web twintig jaar terug in de tijd. Kijk maar eens naar de gebruikersinterface en responsetijden. Complexe software blijft moeilijk, en het gedistribueerde en realtime karakter maken die nog veel ingewikkelder. Maar dankzij Internet staat object-technologie nu wel in het brandpunt van de belangstelling", aldus Booch in zijn beschrijving van de vierde trend.
Als vijfde trend ziet hij de voortdurende veranderingen in de technologie. "Mensen blijven achter talen en besturingssystemen aan hollen. Ook Java (write once, debug everywhere) en Windows NT zullen worden opgevolgd door iets nieuws, dankzij de inventiviteit van informatici."
"Als zesde trend zie ik dat de best practices van architectuur, ontwikkelproces en modellering meer ingang zullen vinden. Voor de verschillende soorten software, waaraan allemaal andere eisen worden gesteld, zullen, net als in de architectuur, verschillende methodieken ingang vinden. Ik onderscheid daarbij besturingssystemen, militaire systemen, informatiesystemen, outsourced programmatuur, commerciële software en software die door eindgebruikers is ontwikkeld."
Problemen
"De grootste problemen worden nog steeds veroorzaakt door de gebrekkige definitie van de vereisten, slechte architecturen en te grote complexiteit. Er wordt weliswaar veel geëxperimenteerd met methoden om het proces van software-ontwikkeling te versnellen, maar in de praktijk wordt de watervalmethode, bijvoorbeeld Sdm, nog te vaak gebruikt. Door tijdsdruk ontstaan dan onherroepelijk problemen", aldus Booch die als illustratie van een andere, maar ook onjuiste benadering vertelt over de wijze waarop de nieuwe Word-versie bij Microsoft is ontwikkeld. Daar waren vierhonderd programmeurs mee bezig. Iedere programmeur had een buddy, die over zijn rug meekeek om fouten zo snel mogelijk te detecteren. Verder werd er elke dag een ‘rooktest’ gehouden, waarbij alle programma’s werden geïntegreerd om te zien of zij wel goed samenwerkten. Tenslotte werd degene die in een week de grootste problemen had veroorzaakt, benoemd tot integratiemanager voor de volgende week. Booch: "Het gevolg ligt voor de hand: iedereen probeerde problemen te vermijden in plaats van functies zo goed mogelijk te implementeren. En dan begrijp je meteen waarom programma’s elke release vijf keer zo groot worden."
"Met een dergelijke werkwijze creëert Microsoft voor zichzelf een groot legacy-probleem. Nog een stuk erger dan dat voor de mainframes. Helaas zijn er vandaag de dag nog maar weinig onontgonnen gebieden waar je een nieuwe start kunt maken. Vandaar dat het zo belangrijk is om met een goede architectuur te beginnen."
Booch stelt dat software-ontwikkeling vooral een kwestie is van het beheersen van het proces en de architectuur. Er zullen best practices ontstaan voor de verschillende vormen van software. Hij verwijst naar Software Program Managers Network (http://www.spmn.com) dat tracht zulke praktijken te documenteren voor het Amerikaanse ministerie van Defensie. In Nederland werkt Itil in eenzelfde richting voor overheid en bedrijven. Modellering is hierbij van cruciaal belang.
Modellering
"Modellering is nodig om een onbegrijpelijk complex systeem in begrijpelijke onderdelen te splitsen. Omdat onze systemen steeds complexer worden, moet je gaan modelleren om het geheel in begrijpelijke samenhangende brokken op te delen", aldus Booch die hierbij onderscheid maakt in element (de basisconcepten), notatie (de grafische weergave van de samenhang tussen elementen), proces (de stappen om een systeem te ontwikkelen) en patroon (de kneepjes van het vak). "Net zoals een architect met tekeningen werkt, moeten we een manier voor de software-architect vinden om zijn ontwerp op een voor iedereen duidelijke manier vast te leggen. Hoe beter iedere betrokkene die architectuur begrijpt, hoe beter het systeem zal worden."
Hiervoor heeft Booch samen met anderen UML (zie kader) ontwikkeld, een universele taal voor modelleren. November vorig jaar is UML 1.1 door het OMG als norm aanvaard. Booch: "Daarmee is het project beëindigd. Met uitzondering van het opschonen van schoonheidsfoutjes zullen wij ons hard opstellen tegen veranderingen of uitbreidingen. Laten we dit nu eerst maar eens op grote schaal gaan gebruiken. Vrijwel elk softwarebedrijf staat erachter. Zelfs IBM, Oracle en Microsoft, en die zijn het toch niet vaak met elkaar eens…"
Architectuur
Booch is de technische topman van Rational Software Corp. en tevens de architect van het modelleringsgereedschap Rational Rose, dat gebaseerd is op UML. Met Rational Rose maakt men UML-modellen van het softwaresysteem, waarna de totale structuur van de applicatie gegenereerd kan worden naar talen als C++, Java en Visual Basic. Tevens kan men van bestaande applicaties een UML-model laten genereren.
"Het gebruik van Rational Rose helpt bij het maken van een architectuur, maar biedt niet de garantie dat die architectuur optimaal is", erkent Booch. "Een optimale architectuur houdt in dat de kosten van veranderingen zo laag mogelijk zijn. Daarvoor moet je inzicht hebben in wat er kan veranderen en wat niet, in wat er nodig is aan functies, capaciteit en betrouwbaarheid, en welke economische en technische beperkingen een rol spelen. Dat vereist veel menselijke ervaring en inzicht. Een goede architect word je dan ook door jarenlange ervaring, door vaak je neus stoten en na te denken over hoe je het beter zou kunnen hebben gedaan. Helaas worden de beste informatici meestal veel te snel van het ene project naar het andere gestuurd en is er te weinig evaluatie achteraf. Een opleiding daarvoor bestaat niet, het vak moet in de praktijk geleerd worden."
Booch sprak al eerder over de uitzetvoegen die er tussen de delen van een architectuur moeten bestaan, zodat een deel kan worden veranderd zonder de andere delen aan te tasten. Zijn ervaring is dat in object-georiënteerde systemen vier plus één aspecten belangrijk zijn. De vier primaire aspecten zijn: het logisch ontwerp (de verzameling functies), de processen (het gebruik van de verzameling functies), de componenten (de softwarecomponenten die gekozen worden voor het realiseren van de functies en processen) en het platform (de gekozen systeemomgeving).
Het overkoepelende aspect betreft de zogenaamde Use Cases, die beschrijven hoe het geheel zich gedraagt of waarvoor het gebruikt wordt. Belangrijk hierbij is de verbinding tussen ontwerp en werkelijkheid, iets dat ontbreekt bij gestructureerde analyse en ontwerp.
Goed en slecht nieuws
Het goede nieuws, herhaalt Booch tot slot, is dat het een fantastische tijd is om programmeur te zijn. Overal worden computers gebruikt en zijn programma’s nodig. De wereld draait steeds meer om het programmeren. En er komen steeds meer interessante nieuwe voorzieningen voor programmeurs. Maar het slechte nieuws is dat het ontwikkelen van software een arbeidsintensief proces blijft. Er zijn geen doorbraken te verwachten vanwege nieuwe programmeertalen of nieuw gereedschap. Alle nieuwe technieken en gereedschappen hebben de productiviteit van programmeurs niet verbeterd. Ze hebben het alleen mogelijk gemaakt om meer complexe problemen aan te pakken. En slechte programmeurs blijven slechte programma’s maken. Dat is allemaal nog steeds zo.
Hein van Steenis, freelance medewerker
Unified Modelling Language (UML)
UML is een grafische metataal voor het modelleren van een architectuur, die specifiek object-georiënteerd gericht is. De UML-specificatie bestaat uit twee onderdelen: UML Semantics, die de abstracte syntax en semantiek van de gebruikte modelleringsconcepten beschrijft, en UML Notation, die de grafische notatiemethode beschrijft. In totaal worden acht soorten diagrammen gebruikt in UML 1.1:
Use Case diagram: een view op het Use Case Model. Het Use Case Model beschrijft hoe de gebruikers (‘actors’) het systeem gebruiken. Dat wil zeggen: het geeft de high-level functies (use cases) van het systeem weer.
Sequence diagram: een tijdvolgordelijk diagram dat (een deel van) de realisatie van een use case uit het Use Case Model weergeeft, uitgedrukt in objecten die met elkaar boodschappen uitwisselen.
Collaboration diagram: een context-diagram dat, net als het ‘sequence diagram’, (een deel van) de realisatie van een ‘use case’ uit het Use Case Model weergeeft, uitgedrukt in objecten die met elkaar boodschappen uitwisselen. Bij dit type diagram staat niet het tijdvolgordelijke aspect centraal, maar vooral het overzicht van de samenwerkende objecten.
Class diagram: een view op het hart van het systeem, de klassen en hun onderlinge relaties. Een ‘class diagram’ is het best te vergelijken met een ‘entity-relationship’ diagram uit de SA/SD school, alhoewel daar in het objectgeoriënteerde ontwerp natuurlijk veel aan toegevoegd is.
State diagram: een diagram dat het dynamische gedrag van een klasse weergeeft.
Component diagram: een view op het Component Model, waarin de afbeelding van klassen op componenten, c.q. bronbestanden, centraal staat. Tevens wordt hierin weergegeven hoe bijvoorbeeld een executable of een dynamic-link-library (dll) is opgebouwd uit componenten en bronbestanden.
Deployment diagram: een hardwarecontext diagram, waarin te zien is welke machines met elkaar verbonden zijn, en welke processen op welke machines draaien.
Activity diagram: een diagram dat een proces weergeeft. Zo’n proces kan onderverdeeld zijn in subprocessen, die sequentieel dan wel parallel uitgevoerd kunnen worden.
(NB: Omdat UML een consolidatie is van diverse modelleringstalen, afkomstig van verschillende auteurs, zijn in het verleden nogal wat verschillende termen voor vergelijkbare diagrammen gebruikt.)
