UML

Sinds april van dit jaar is binnen Synobsys een zogenaamd BSM-team actief. De afkorting staat voor Business & Systems Modeling. Dit team houdt zich bezig met modellering van softwareapplicaties waarbij UML gebruikt wordt als basis. Onderzocht wordt hoe UML op de meest optimale wijze kan worden toegepast. Hierbij wordt ook de de kennis en ervaring gebruikt die Synobsys de afgelopen twee jaar bij haar klanten heeft opgedaan. Uiteindelijk leidt dit o.a. tot een standaard aanpak (best practices) voor het maken van UML-modellen binnen Synobsys en zal deze standaard het vertrekpunt zijn voor implementatie bij klanten.

 UML staat voor Unified Modeling Language en is een door de OMG (http://www.omg.org/UML/) opgestelde, internationaal geaccepteerde en toegepaste notatiewijze voor het beschrijven (modelleren) van softwaresystemen. Het is dus geen programmeertaal zoals de afkorting doet vermoeden. Het is ook geen methode voor systeemontwikkeling. Daarom wordt UML vaak in één adem genoemd met RUP (Rational Unified Process). RUP is een agile methode en gebruikt UML als notatiewijze voor het beschrijven van de gewenste artefacts. UML toepassen los van een softwaretool, is mogelijk maar niet aan te raden. Vooral bij omvangrijke, complexe softwareapplicaties is een tool onontbeerlijk. Goede tools slaan de gebruikte UML-elementen op in een repository waardoor hergebruik mogelijk wordt en de consistentie van de modellen wordt gewaarborgd. Dit maakt het onderhoud van modellen eenvoudiger. Binnen Synobsys wordt IBM Rational Software Modeler gebruikt

Waarom modelleren? Modellen zijn een vereenvoudiging van de werkelijkheid. Omvangrijke softwareapplicaties zijn te complex voor de menselijke geest om te kunnen bevatten. Door dergelijke applicaties te abstraheren in modellen ontstaat overzicht en inzicht. Dit inzicht kan uiteindelijk leiden tot betere applicaties en tot betere onderhoudbaarheid en beheersbaarheid van deze applicaties. Daarnaast zijn modellen een manier om zowel met de business als met ontwikkelaars en programmeurs te communiceren. Van eenzelfde applicatie worden dan ook meerdere modellen gemaakt, afhankelijk van de scope. Uiteraard gebruiken we in deze modellen steeds dezelfde elementen maar we combineren ze in andere diagrammen met een wisselende invalshoek. In een model en tussen modellen worden onderling relaties gelegd tussen de elementen zodat samenhang ontstaat. Immers, als we een Use Case “Artikelen inkopen” hebben op business niveau, dan zal er in een ander model een Technisch Ontwerp genaamd “Artikelen inkopen” zijn. De laatste implementeert de eerste en dus moet er een relatie tussen beide zijn. We leggen deze relaties op verschillende abstractieniveaus (modellen) zodat we van boven naar beneden en terug kunnen herleiden wat de mogelijkheden en impact van te plegen aanpassingen zijn. UML-modellen bevatten een belangrijk deel van de documentatie van een softwareapplicatie. Bij nieuwbouw bevatten ze de contracten voor de programmeurs en na realisatie en implementatie bevatten ze kennis van de gebouwde applicatie en zijn ze het uitgangspunt voor regulier onderhoud. Dit vereist commitment van alle betrokken partijen. Als een bedrijf prachtige UML-modellen heeft, maar programmeurs ze negeren en zelfstandig een ontwerp op een paar A4-tjes maken omdat ze dat al jaren zo gewend zijn, dan is het als water naar de zee dragen. UML moet daarom worden gebruikt door rollen die variëren van businessanalist tot programmeur, in samenwerking met elkaar, waarbij zij het eens moeten zijn over zaken als standaardisatie, architectuur en werkwijze. Immers, een goed fundament is het halve werk.

UML is niet de heilige graal. Het is een middel om op een efficiënte wijze tot applicatiebouw, herontwerp en –onderhoud te komen. Maar UML is slechts een notatiewijze en geen methode. Het vergt dus keuzes, afspraken vooraf en discipline in het toepassen. Mits goed toegepast en opgenomen in de repository van een tool biedt het voordelen boven een rij ordners met Word-documenten en geprinte Visio-schema’s

Ron Putting
rputting@synobsys.nl