De Unified Modeling Language (UML) is een objectgeoriënteerde modelleertaal waarin kan worden gecommuniceerd over informatiesystemen. UML is geen systeemontwikkelingsmethode en in die zin zeker niet vergelijkbaar met bijvoorbeeld SDM. Je kunt het min of meer op één lijn stellen met ERM of NIAM, met dien verstande dat die niet geschikt zijn voor OO systeemontwikkeling.

Enkele typeringen:

• UML is een visuele modelleertaal met een standaardnotatie, semantiek en een metamodel.

• UML definieert de basisconcepten van OO analyse en ontwerp en omvat een aantal diagrammen voor de ‘communicatie’ tussen deze concepten.

• UML is geen complete methode, maar het voegt tools, technieken en processen samen.

Ontstaan
UML is in 1996 ontstaan, na een ‘fusie’ van drie bestaande OO-methoden:

1. de Object Modeling Technique van James Rumbaugh
2. de methode OOSE van de Zweed Ivar Jacobson
3. de methode van Grady Booch

Use-case
In UML spelen use-cases een centrale rol. Een use-case is een beschrijving van de wijze waarop een systeem kan worden benut. Use-cases laten dus zien welke functionaliteit een systeem heeft. Een use-case wordt beschreven in ‘gewone’ taal en is daarom niet geformaliseerd.

De belangrijkste schema’s binnen UML zijn:

1. Het use-case-diagram
2. Het class-diagram
3. Het objectdiagram
4. Het sequence-diagram en collaboration-diagram
5. Het state-diagram
6. Het component-diagram
7. Het deployment-diagram

Dit dient om de interactie met de gebruiker vast te leggen. Er wordt nagegaan voor welke activiteiten een gebruiker het te bouwen systeem kan gaan gebruiken, en de mogelijke volgorde en interactie tussen één of meer actoren en het systeem wordt beschreven. Tijdens het ontwikkelingsproces kunnen use cases verder gespecificeerd worden.

Stappen
Het proces om use cases te definiëren bestaat uit een aantal stappen:

1. Bepaal de systeemgrenzen.
2. Definieer de zogeheten actoren.
3. Stel use-cases voor elke actor vast.
4. Definieer scenario’s voor elke use-case.
5. Beschrijf eenduidig wat er allemaal gebeurt binnen de use-cases.
6. Identificeer gemeenschappelijke subcases; sommige (sub)use-cases kunnen door de verschillende use-cases worden hergebruikt.

Dit diagram geeft de statische eigenschappen van klassen weer. Hierin worden eigenschappen (attributen) en methoden genoteerd.

Klassen kunnen op diverse manieren met elkaar samenhangen:

• met elkaar verbonden
• afhankelijk van elkaar
• de ene klasse als specialisatie van de andere
• gegroepeerd

Bij het ontwikkelen van systemen zijn er meerdere class-diagrammen nodig, waarbij een klasse in verschillende klassediagrammen kan voorkomen.

Dit diagram geeft een bepaalde situatie weer waarin een class-diagram kan verkeren. Het is een ‘momentopname’. In dit diagram geven we objecten, de waarden van hun attributen en hun links weer.

Objectdiagrammen worden meestal gebruikt om een bepaalde situatie te verduidelijken, in sommige gevallen om klassediagrammen te verduidelijken.

Dit zijn zogeheten interactiediagrammen. Ze laten de berichten zien die tussen objecten worden uitgewisseld. Hierdoor wordt een deel van het dynamische gedrag van het systeem zichtbaar.

Het state-diagram laat het toestandsafhankelijke gedrag van objecten zien. Hiermee kan een deel van het dynamische gedrag van subsystemen worden beschreven. Toestandsovergangen, events en eventueel parallelle verwerking passen binnen dit diagramtype.

Een toestandsovergang in het state-diagram heeft altijd betrekking op de toestand van een object. Dit in tegenstelling tot bij het State Transition Diagram, dat de toestanden van systemen of subsystemen beschrijft. De grenzen van een systeem waarvan een STD wordt gemaakt, liggen niet zo nauwkeurig vast als bij het state-diagram van een object.

Hierin wordt de samenhang tussen de afzonderlijke componenten van een systeem beschreven. Dit kunnen bijvoorbeeld zijn:

• het databasegedeelte
• de gebruikersinterface en/of
• het communicatiemechanisme

Dit diagram toont de verschillende processors, de devices en de verbindingen hiertussen. De complexiteit van het geheel kan worden beperkt door de verschillende systeemcomponenten in verschillende deelsystemen onder te brengen. Het geeft de ontwerper de mogelijkheid de technische infrastructuur vorm te geven en te documenteren.

Net als bij een ‘klassiek’ systeemontwikkelingstraject wordt het gehele OO-ontwikkelingstraject in fasen verdeeld. Tijdens deze fasen kunnen de UML-technieken gebruikt worden.

In het nu volgende geven we een voorbeeld van een gefaseerde aanpak van een OO-systeemontwikkelingstraject en beschrijven we welke rol de diverse diagrammen daarbij (kunnen) spelen.

Achtereenvolgens komen aan de orde:

1. De strategische planning voor de systeembouw
2. De systeemeisen
3. De analyse
4. De architectuur
5. De ontwerpfase
6. De constructiefase
7. De testfase
8. De fase van ingebruikname

In deze fase formuleer je:

• de doelstellingen
• de totaalvisie

De niet-functionele eisen worden beschreven. Hieronder vallen:

• prestatieniveau
• betrouwbaarheid
• hergebruik
• bruikbaarheid
• kwaliteit van het te bouwen systeem

Voor iedere functionele eis worden dan de use-cases beschreven. Elke use-case definieer je in samenhang met de sequence of collaboration-diagrammen.

In deze fase ontwikkel je dus de use-case-diagrammen en bepaal je de relaties tussen de use-cases.

Je documenteert de concepten van het probleemdomein door class-diagrammen te maken. Voor elk deelsysteem dat dynamisch gedrag vertoont ontwikkel je het gedragsmodel, daarbij gebruikmakend van state-, collaboration- en sequence-diagrammen. In deze fase wordt ook het ontwikkelen van de use-case specificaties vervolgd.

Verder ontwikkel je de formulier- en schermdefinities en de navigatievolgorde tussen de ontworpen schermen. Op basis van use-cases wordt een begin gemaakt met het ontwikkelen van de gebruikersinterface.

Ook kan begonnen worden met het ontwikkelen van een geïntegreerd testplan voor het systeem, rekening houdend met de gedefinieerde use-cases.

De deployment-diagrammen gebruik je om het concept en de fysieke opdeling van het systeem te laten zien. Dit betreft bijvoorbeeld:

• de GUI
• de applicatieservice
• de opslagstructuur

Voor iedere component maak je een class-diagram en de bijbehorende relaties; dit documenteer je vervolgens eveneens.

Hierin worden de class-diagrammen uit de eerdere fasen verfijnd of verbeterd. Ook wordt het dynamisch gedrag van de classes beschreven.

De gebruikersinterface wordt voltooid en getest met hulp van toekomstige gebruikers.

Indien nodig kan de werkelijke database (of delen daarvan) worden gemaakt.

In deze fase wordt het programma als het ware geassembleerd. Je zorgt ervoor dat de objecten gemaakt worden en ziet toe op een juiste samenwerking tussen de objecten.

De databaseschema’s worden gemaakt en er wordt gestreefd naar een juiste werking van het gehele systeem.

In deze fase wordt de werking van het gehele systeem getest. Alle methoden worden geïmplementeerd aan de hand van het beschreven gedragsmodel.

In deze fase wordt beschreven hoe de ontwikkelde software in de organisatie kan worden ingevoerd.

Aan de hand van een voorbeeld verduidelijken we de theorie: de geldautomaat.

Voor het opnemen van geld is de gebruiker een actor die samenwerkt met de geldautomaat. Achter deze automaat staat natuurlijk een heel banksysteem dat uiteindelijk zorgt voor de transactieafhandeling.

Figuur 1

In bovenstaande figuur is het ‘poppetje’ de actor. In dit geval staat het voor de gebruiker die bij een geldautomaat geld wil opnemen. Voor de use-case ‘neem geld op’ wordt de naam van de interactie in de ovaal geplaatst en met behulp van een pijl aan de actor gekoppeld.

Bij iedere use-case hoort een uitgewerkt scenario, dat stap voor stap de interactie van de actor met het systeem beschrijft.

Scenario ‘neem geld op’
Voorbeeld geldautomaat, uitwerking scenario.
De geldautomaat meldt op de display ‘voer pinpas in’.
De gebruiker voert de pinpas in.
Het systeem meldt ‘voer pincode in’.
De gebruiker voert de bij de pinpas behorende pincode in.
Het systeem meldt ‘welk bedrag wilt u opnemen?’.
De gebruiker voert het gewenste bedrag in.
Het systeem geeft de pinpas terug.
Het systeem vraagt of er een transactiebon moet worden afgedrukt.
De gebruiker meldt ja of nee.
Het systeem geeft het gewenste bedrag af.
Het systeem drukt eventueel een transactiebon af.

Het beschreven scenario is een nauwkeurige uitwerking van de use-case; het beschrijft stap voor stap de interactie tussen het computersysteem en de gebruiker.

Het bijbehorende scenario levert de systeemontwerpers de informatie die de eindgebruiker nodig heeft, en daarnaast de gegevens die het systeem nodig heeft om te kunnen functioneren. Het eindproduct is dan voor de systeemontwerpers een opsomming van alle voor het systeem noodzakelijke gegevens en gebeurtenissen om het systeem te kunnen sturen.

In het ontwerp moet de actor een naam hebben. De specificaties van een actor lijken op die van een klasse. De actor speelt echter een rol buiten het systeem en vertegenwoordigt een interactie met de buitenwereld.

Een korte samenvatting van de betekenis en de stappen van de use-case:

• Een actor werkt samen met het systeem.
• De interactie van de actor met het systeem wordt beschreven in het scenario dat bij deze use-case hoort.
• Het scenario wordt gevormd door een reeks acties die plaatsvinden tussen de actor en het systeem. Het startpunt van een scenario is een actie van buitenaf, bijvoorbeeld de invoer van het toetsenbord door de gebruiker.
• De interactie tussen actor en systeem(objecten) wordt weergegeven in een sequence-diagram (zie figuur 2). Hierin wordt bepaald welke actie van een actor een bepaalde reeks operaties van de objecten in gang zet.

Figuur 2

In een UML-programmaontwerp wordt de volgorde van afhandeling van operaties van de objecten dus weergegeven door middel van een sequence-diagram. Hierin wordt vastgelegd welke objecten elkaar berichten sturen. In zo’n diagram worden de objecten met een naar onderen lopende tijdslijn naast elkaar geplaatst.

Objecten kunnen een operatie van een ander object activeren door een bericht naar het doelobject te sturen. Dit wordt in het diagram aangegeven door een pijl tussen de twee tijdslijnen van het ene naar het andere object.

De naam van de pijl vermeldt welke operatie van het doelobject moet worden uitgevoerd. Iedere pijl heeft een volgnummer, dat de volgorde van de aanroepen in het sequence-diagram aangeeft. Als de tijdsduur van een operatie belangrijk is voor het systeem, kan deze tijd in het diagram worden opgenomen.

Objecten	Operaties
Klant	Voer kaart in, voer pin in
Geldautomaat	Display menu, vraag naar pin, display transactiebericht
Bankorganisatie	Voer transactie uit, controleer pin, pin OK, transactie geslaagd
Bankfiliaal	Voer transactie uit, controleer pin, pin OK, transactie geslaagd

Figuur 3

De objecten uit het sequence-diagram van de geldautomaat kunnen de eigen taken (operaties) uitvoeren. Wanneer een taak moet worden uitgevoerd waarvoor een object geen verantwoordelijkheid heeft, wordt een message gestuurd naar een object dat daar wel over gaat.

De verantwoordelijkheid wordt doorgeschoven totdat een object de vraag kan beantwoorden. Het resultaat wordt via dezelfde route teruggestuurd.

Het collaboration-diagram geeft vooral aan welke objecten met elkaar samenwerken. Het collaboration-diagram en het sequence-diagram zijn twee verschillende weergaven van de objectinteracties in een systeem.

• Het collaboration-diagram laat de koppelingen en de berichten tussen de objecten zien.
• Het sequence-diagram toont ook de afhandelingsvolgorde.

De verbindingslijn in het collaboration-diagram tussen twee objecten (klassen) laat de structurele relatie tussen deze twee objecten zien.

Nadat het sequence-diagram door de ontwerper is gemaakt, kan de ontwerp-tool automatisch uit een sequence-diagram een volledig collaboration-diagram genereren. Dit is mogelijk omdat alle relaties tussen de objecten ook al in het sequence-diagram worden getoond. Meerdere verbindingslijnen in het sequence-diagram worden teruggebracht tot één lijn in het collaboration-diagram; zie de figuur hierna.

Figuur 4

Een object kan in verschillende toestanden verkeren, die worden bepaald door de waarden van de attributen van het object. De mogelijke toestanden van een object worden beschreven in het state-diagram. Een toestand van een object kan veranderen door de operaties die op het object worden uitgevoerd.

De toestand waarin een object zich bevindt, bepaalt dus de reactie van dat object wanneer een bepaalde actie moet worden uitgevoerd. In figuur 5 worden de toestanden en de mogelijke overgangen van de geldautomaat beschreven. De condities van een object waaronder een toestandsovergang kan plaatsvinden, worden bij iedere overgang getoond.

Figuur 5

Tools
Voor het maken van UML-diagrammen bestaan diverse tools. Deze kennen de regels waaraan de schema’s gebonden zijn en helpen bij het maken van correcte diagrammen. Geavanceerde tools kunnen zelfs code genereren op basis van de diagrammen.

Voer deze opdracht uit in tweetallen.

1. In de tekst komen een aantal diagrammen ter sprake. Zoek op het internet of je voorbeelden van deze diagrammen kunt vinden en neem die op in je verslag.

2. Sommige onderwerpen van UML komen ook bij SDM ter sprake. Geef een overzicht van deze onderwerpen. Geef ook aan waar ze passen binnen SDM en UML.

3. Werk de kaartautomaat van de NS als voorbeeld uit.