Onder aanvoering van de Object Modeling Group (OMG) werd UML een standaard op het gebied van objectgeoriënteerde modelleren

HOOFDSTUK

3

Module 7 – Schematechnieken en databases

Unified Modeling Language 3.1 Inleiding UML 3.1.1 Wat is UML? De Unified Modeling Language (UML) is een objectgeoriënteerde modelleertaal waarin je kunt communiceren over informatiesystemen. UML is geen systeemontwikkelingsmethode en in die zin zeker niet vergelijkbaar met bijvoorbeeld DSDM. Je kunt het min of meer op één lijn stellen met ERM, met dien verstande dat ERM niet geschikt is voor objectgeoriënteerde systeemontwikkeling.

Informatie UML is in 1996 ontstaan, na een fusie van drie bestaande objectgeoriënteerde methoden: • de Object Modeling Technique van James Rumbaugh • de methode OOSE van de Zweed Ivar Jacobson • de methode van Grady Booch. Onder aanvoering van de Object Modeling Group (OMG) werd UML een standaard op het gebied van objectgeoriënteerde modelleren.

UML:  is een visuele modelleertaal  kent een standaardnotatie; ieder UML-model gebruikt dus dezelfde symbolen  definieert de basisconcepten van objectgeoriënteerde analyse en ontwerp en omvat een aantal diagrammen voor de communicatie tussen deze concepten  is geen complete methode, maar het voegt tools, technieken en processen samen  standaardiseert geen werkwijze, maar een bepaalde schematechniek en terminologie. In UML spelen use-cases een centrale rol.

3.1.2 Use-case Een use-case is een beschrijving van de wijze waarop een systeem kan worden benut. Met use-cases laat je dus zien welke functionaliteit een systeem heeft. Een use-case wordt beschreven in ‘gewone’ taal en is daarom niet geformaliseerd.

175

Module 7 – Schematechnieken en databases Unified Modeling Language Hoofdstuk 3

Scenario Bij iedere use-case hoort een uitgewerkt scenario. Hierin beschrijf je stap voor stap de interactie van de actor met het systeem. Op die manier krijg je een reeks acties die plaatsvinden tussen de actor en het systeem.

gepast geld inwerpen

controle of er voldoende geld ingeworpen is aangeven dat het gewenste merk kan worden gekozen

aangeven dat het merk niet voorradig is

merk kiezen frisdrankkoper [merk niet voorradig]

Het scenario levert de systeemontwerpers de informatie die de eindgebruiker nodig heeft, en 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.

[merk voorradig]

blikje frisdrank uitnemen

Voorbeeld van een UML-diagram van de werking van een frisdrankautomaat.

3.1.3 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.

3.2 Voorbeeld: geldautomaat Aan de hand van het voorbeeld Geldautomaat verduidelijken we de theorie van UML. In hoofdstuk 3.3 van deze module vind je meer informatie over de belangrijkste schema’s van UML.

3.2.1 De use-cases Jan Snel loopt naar de geldautomaat om geld op te nemen. Jan is dus de gebruiker van de geldautomaat. Laten we eens kijken hoe de relaties zijn.

176


   

De gebruiker is de actor. De actor werkt samen met de geldautomaat. Achter deze automaat staat een heel banksysteem. Dit systeem zorgt voor de transactieafhandeling.

De use-case (rechts) van deze gebeurtenis (links) ziet er zo uit:

neemt geld op

klant geldautomaat

In bovenstaande figuur is het poppetje de actor: 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 een lijn aan de actor gekoppeld.

3.2.2 Het scenario Zo ziet het scenario eruit dat bij de use-case ‘geld-opnemen’ hoort: 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.

177


3.2.3 De actor In het ontwerp moet de actor een naam hebben. De specificaties van een actor lijken op die van een klasse. De interactie van de actor met het systeem is beschreven in het scenario. Het startpunt van een scenario is een actie van buitenaf, bijvoorbeeld de invoer via het toetsenbord door de gebruiker. De actor speelt een rol buiten het systeem en vertegenwoordigt een interactie met de buitenwereld. Uit de use-case kun je opmaken dat:  de actor samenwerkt met het systeem  de interactie tussen actor en systeem(objecten) wordt weergegeven in een sequencediagram (zie hieronder). Hierin wordt bepaald welke actie van een actor een bepaalde reeks operaties van de objecten in gang zet.

geldautomaat

klant

"voer pas in"

gebruiker voert pas in

"voer pincode in"

gebruiker voert de code in

systeemgrens

3.2.4 Het sequencediagram In het sequencediagram van de geldautomaat (zie hieronder) staan de objecten van de geldautomaat naast elkaar. Op de naar beneden wijzende tijdslijn kunnen de activeringen van de methoden van een object worden geplaatst. De pijl geeft aan welke operatie op welk moment moet worden geactiveerd.

178


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

De objecten uit het sequencediagram van de geldautomaat kunnen de eigen taken (operaties) uitvoeren. Wanneer een taak moet worden uitgevoerd waarvoor een object geen verantwoordelijkheid heeft, wordt een bericht gestuurd naar een object dat daar wel over gaat. De controle of een pincode juist is ingevoerd, kan nooit door de geldautomaat alleen worden gedaan. Die verantwoordelijkheid ligt bij het object ‘Bankorganisatie’. De verantwoordelijkheid wordt doorgeschoven totdat een object de vraag kan beantwoorden. Het resultaat wordt via dezelfde route teruggestuurd. De vraag naar de controle van de pincode wordt door het object ‘Geldautomaat’ doorgegeven tot aan het object ‘Bankorganisatie’. Deze controleert de pincode en geeft toestemming terug aan het object dat erom vroeg: het object ‘Bankfiliaal’.

179


3.2.5 Het collaborationdiagram Omdat in het sequencediagram van de geldautomaat alle relaties tussen de objecten getoond zijn, kan de ontwerptool automatisch een volledig collaborationdiagram genereren. De vele verbindingslijnen in het sequencediagram zijn teruggebracht tot één lijn: 2: voer kaart in 4: voer pin in 10: voer bedrag in

klant

1: display bericht 3: vraag naar pin 9: bericht voer transactie in 16c: betaal geld uit

geldautomaat

8: pin ok 14: transactie gelukt

bankfiliaal 6: controleer pin 12: voer transactie uit 13: transactie gelukt 7: pin ok

bankorganisatie

3.2.6 Het statediagram Rusttoestand 15 seconden geen actie of Resetknop ingedrukt

Startknop ingedrukt E:display "Voer pas in" T:neem pas in

Wacht op pas Pas ingevoerd E:display "Geef uw PIN"

Wacht op PIN Correcte PIN ingevoerd E:display "Hoeveel geld wilt u?"

Foute PIN E:display "Geef juiste PIN"

Wacht op bedrag

Correct bedrag ingevoerd E:display "Uw geld wordt geteld"

Geld tellen Voldoende geld in machine E:display "Neem uw pas uit" T:voer pas uit

Pas uitgenomen E:display "Neem uw geld" T:voer geld uit T:print bon

Geld uitgenomen

180

Wacht op pasuitname

Wacht op gelduitname

Onvoldoende in machine E:display "Sorry zo veel heb ik niet"

Wanneer het geld in de geldautomaat op is, kan er geen geld meer worden opgenomen. De toestand van de automaat is veranderd en niet alle operaties kunnen op de normale manier worden afgehandeld. De toestand waarin een object zich bevindt, bepaalt dus de reactie van dat object wanneer een bepaalde actie moet worden uitgevoerd. In het statediagram 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. Bijvoorbeeld: pas wanneer een geldtransactie is gelukt, kan de bon worden geprint, niet eerder.


De figuur in deze paragraaf is een vereenvoudigde weergave van een geldautomaat. Je kunt de figuur uitbreiden met bijvoorbeeld controle op niet uitnemen van pas of van geld, of de situatie dat het banksaldo van de klant te laag is. Ook kun je het herhaaldelijk invoeren van een onjuiste PIN toevoegen.

3.3 Soorten diagrammen Hiervoorzijn al een paar schema’s van UML aan de orde gekomen. In dit hoofdstuk behandelen we de belangrijkste diagrammen binnen UML.

3.3.1 Het use-casediagram Het use-casediagram definieert use-cases. Hierin leg je de interactie van de gebruikers vast. In het diagram ga je na voor welke activiteiten een gebruiker het te bouwen systeem kan gaan gebruiken. Ook beschrijf je de mogelijke volgorde en interactie tussen een of meerdere actoren en het systeem. Tijdens het ontwikkelingsproces kun je de use-cases verder specificeren.

Stappen In het proces om use-cases te definiëren moet je een paar stappen doorlopen:      

Bepaal de systeemgrenzen. Definieer de actoren, de spelers in het te bouwen systeem. Stel use-cases voor elke actor vast. Definieer scenario’s voor elke use-case. Beschrijf eenduidig wat er allemaal gebeurt binnen de use-cases. Identificeer gemeenschappelijke subcases; sommige (sub)use-cases kunnen door de verschillende use-cases worden hergebruikt.

Een use-casediagram.

3.3.2 Het classdiagram Het classdiagram geeft de statische eigenschappen van klassen weer. In het classdiagram noteer je de eigenschappen (attributen) en methoden.

181


Klassen kunnen op diverse manieren met elkaar samenhangen:  met elkaar verbonden  afhankelijk van elkaar  de ene klasse als specialisatie van de andere gegroepeerd. Al deze relaties, én de attributen en methoden, laat je tot uitdrukking komen in een classdiagram. Bij het ontwikkelen van systemen heb je meerdere classdiagrammen nodig. Daarbij kan een klasse in verschillende classdiagrammen voorkomen. Person Name Phone Number Email Address

0..1

lives at

Purchase Parking Pass

Address Street 1 City State Postal Code Country Validate Output As Label

Student

Professor Salary

Student Number Average Mark Is Eligible To Enroll Get Seminars Taken

Een classdiagram.

3.3.3 Het objectdiagram Het objectdiagram geeft een bepaalde situatie weer waarin een classdiagram kan verkeren. Het is een momentopname. In dit diagram geef je het volgende weer:  objecten  de waarden van hun attributen  hun links.

:Computer

:Server

checkEmail

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

sendUnsentEmail

newEmail response (newEmail) downloadEmail

deleteOldEmail

182

Een objectdiagram.


3.3.4 Het sequencediagram en collaborationdiagram Het sequencediagram en het collaborationdiagram zijn interactiediagrammen. Hierin laat je de berichten zien die tussen objecten worden uitgewisseld. Met zo’n diagram maak je een deel van het dynamische gedrag van het systeem zichtbaar. In het sequencediagram plaats je de objecten met een tijdslijn, die van boven naar onderen loopt, naast elkaar. Het collaborationdiagram geeft vooral aan welke objecten met elkaar samenwerken. Het collaborationdiagram en het sequencediagram zijn twee verschillende weergaven van de objectinteracties in een systeem.  Het collaborationdiagram laat de koppelingen en de berichten tussen de objecten zien.  Het sequencediagram toont ook de afhandelingsvolgorde. Zie ook paragraaf 3.2.4 over het sequencediagram en paragraaf 3.2.5 over het collaborationdiagram.

Verbindingslijn De verbindingslijn in het collaborationdiagram tussen twee objecten (klassen) laat de structurele relatie tussen deze twee objecten zien.

Operatie van een ander object activeren 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. Met de naam van de pijl geef je aan welke operatie van het doelobject moet worden uitgevoerd. Iedere pijl heeft een volgnummer. Dit nummer geeft de volgorde van de aanroepen in het sequencediagram aan. Als de tijdsduur van een operatie belangrijk is voor het systeem, kan deze tijd in het diagram worden opgenomen.

3.3.5 Het statediagram Het statediagram laat het toestandsafhankelijke gedrag van objecten zien. Met dit diagram kun je een deel van het dynamische gedrag van subsystemen beschrijven. Toestandsovergangen, events en eventueel parallelle verwerking passen binnen dit diagramtype.

183


Verschillende toestanden 1 Opened

state

E: open door

transition

close_door

Dit object kan in verschillende toestanden verkeren, die worden bepaald door de waarden van de attributen van het object. De toestand van een object kan bovendien veranderen. Dit wordt veroorzaakt door de operaties die op het object worden uitgevoerd. Kijk maar naar het praktijkvoorbeeld.

open_door

transition condition

1 Closed E: closedoor

entry action

Een statediagram.

Statediagram versus State Transition Diagram Een statediagram is iets anders dan een State Transition Diagram (STD). Een toestandsovergang in het statediagram heeft altijd betrekking op de toestand van een object, terwijl het STD 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 statediagram van een object.

3.3.6 Het componentdiagram In het componentdiagram beschrijf je de samenhang tussen de afzonderlijke componenten van een systeem. Dit kunnen bijvoorbeeld zijn:  het databasegedeelte  de gebruikersinterface  het communicatiemechanisme. Met het componentdiagram geef je de grote samenhang van het systeem weer.

3.3.7 Het deploymentdiagram Het deploymentdiagram toont de verschillende processors, de devices en de verbindingen hiertussen. Je kunt de complexiteit van het geheel beperken door de verschillende systeemcomponenten in verschillende deelsystemen onder te brengen. Hierdoor kun je de technische infrastructuur beter vormgeven en documenteren.

184


3.4 De fasen in het ontwikkelingstraject Net als bij een ‘klassiek’ systeemontwikkelingstraject wordt het gehele objectgeoriënteerde-ontwikkelingstraject in fasen verdeeld. Tijdens deze fasen kun je de UML-technieken gebruiken. In het nu volgende geven we een voorbeeld van een gefaseerde aanpak van een objectgeoriënteerde-systeemontwikkelingstraject en beschrijven we welke rol de diverse diagrammen daarbij (kunnen) spelen.

3.4.1 Fase 1: strategieplanning Als je een systeem wilt bouwen, begin je met het bepalen van de strategie. Hiervoor formuleer je:  de doelstellingen voor het systeem  de totaalvisie voor het systeem. Daarna doorloop je de volgende stappen:     

Je legt het bedrijfsmodel vast zoals dat op dat moment bestaat. Je beschrijft hoe het bedrijfsmodel moet gaan worden. Je specificeert de functionele eisen die aan het systeem worden gesteld. Je bepaalt welke onderdelen geautomatiseerd kunnen of moeten worden. Voor al deze onderdelen beschrijf je een beginprobleem, zodat je een uitgangspunt hebt voor het formuleren van de systeemeisen.

3.4.2 Fase 2: ontwikkeling use-casediagrammen In deze fase ontwikkel je use-casediagrammen en bepaal je de relaties tussen de use-cases. Hiervoor is het nodig dat je de niet-functionele eisen beschrijft.

Systeemeisen Systeemeisen zijn onder meer:     

prestatieniveau betrouwbaarheid hergebruik bruikbaarheid kwaliteit van het te bouwen systeem.

Voor elk bedrijfsproces benoem je de belangrijkste functionaliteit en die breng je onder in categorieën. Voor iedere functionele eis beschrijf je dan de use-cases. Elke use-case definieer je in samenhang met de sequence- of collaborationdiagrammen.

185


Scenario Zorg vervolgens voor een uitgewerkt scenario. Beschrijf hierin stapsgewijs de interactie van de actor met het systeem. In het praktijkvoorbeeld zie je hoe het scenario van een geldopname bij een geldautomaat is.

3.4.3 Fase 3: analyse Als je de use-casediagrammen gemaakt hebt, kun je de concepten van het te ontwikkelen systeem documenteren. Je gebruikt hiervoor classdiagrammen. Voor elk deelsysteem dat dynamisch gedrag vertoont ontwikkel je het gedragsmodel. Daarbij maak je gebruik van statediagrammen, collaborationdiagrammen en sequencediagrammen. In deze fase ontwikkel je ook de use-casespecificaties door. Op basis van use-cases wordt een begin gemaakt met het ontwikkelen van de gebruikersinterface. Verder ontwikkel je de formulier- en schermdefinities en de navigatievolgorde tussen de ontworpen schermen. Ook kun je beginnen met het ontwikkelen van een geïntegreerd testplan voor het systeem. Hierbij houd je rekening met de use-cases die je gedefinieerd hebt.

Informatie Voor deze fase geldt: beoordeel of het model nog voldoet aan de eisen en herhaal zonodig delen van de fasen die je al uitgevoerd hebt.

3.4.4 Fase 4: beschrijving architectuur Vervolgens ga je het concept en de fysieke opdeling van het systeem laten zien. Hiervoor gebruik je deploymentdiagrammen. De fysieke opdeling heeft onder meer betrekking op:  de gebruikersinterface  de manier waarop het programma aangeboden wordt (online, stand-alone)  de manier waarop de gegevens worden opgeslagen. Daarna beschrijf je met componentdiagrammen het technisch ontwerp. Maak daarbij eventueel keuzen voor een componentmodel. Hierin documenteer je de gehele architectuur en alle systeemeisen. Voor iedere component maak je een classdiagram en de bijbehorende relaties. Ook dit documenteer je.

Informatie Ook voor deze fase geldt dat je moet beoordelen of het model nog voldoet aan de eisen. Herhaal zonodig delen van de fasen die je al uitgevoerd hebt.

186


3.4.5 Fase 5: ontwerpfase Hierin verfijn of verbeter je de classdiagrammen uit de eerdere fasen. Ook beschrijf je het dynamische gedrag van de klassen. Je voltooit de gebruikersinterface en laat deze door toekomstige gebruikers testen. Indien nodig kun je de werkelijke database (of delen daarvan) maken.

Informatie Net als in de vorige twee fasen moet je in deze fase beoordelen of het model nog voldoet aan de eisen. Je kunt zonodig delen herhalen van de fasen die je al uitgevoerd hebt.

3.4.6 Fase 6: constructiefase In deze fase wordt het programma als het ware geassembleerd (omgezet). Je zorgt ervoor dat de objecten gemaakt worden en ziet toe op een juiste samenwerking tussen de objecten. Maak vervolgens de databaseschema’s. Streef naar een juiste werking van het gehele systeem.

3.4.7 Fase 7: testfase In deze fase test je de werking van het gehele systeem. En als alles goed is, implementeer je alle methoden aan de hand van het beschreven gedragsmodel.

3.4.8 Fase 8: ingebruikname En dan nu de laatste fase: de beschrijving van de ingebruikname. Beschrijf hoe de ontwikkelde software in de organisatie kan worden ingevoerd.

3.4.9 Wat als de plannen wijzigen? Het stappenplan van dit ontwikkeltraject heeft betrekking op een omvangrijk project. Kijk er niet van op als de opdrachtgever halverwege het traject bedenkt dat het beter is als het systeem er toch iets anders uitziet. Mochten de plannen inderdaad wijzigen, dan kun je, vanuit elke fase, heel goed teruggaan naar een eerdere fase, als dit nodig is. Dankzij het objectgeoriënteerde ontwerp kun je altijd heel nauwkeurig aangeven in welk deel van een systeem de veranderingen plaats moeten vinden.

187


3.5 Vragen en opdrachten 3.5.1 Open vragen 1. UML is een ‘fusie’ van drie bestaande objectgeoriënteerde methoden. Welke? 2. Wat is een use-case? 3. Welke stappen zijn nodig om een use-case te definiëren? 4. UML kent verschillende schema’s. Noem vijf van deze schema’s. 5. Wat is een actor? 6. In welk diagram worden de objecten met een naar onderen lopende tijdslijn naast elkaar geplaatst? 7. Met welk diagram wordt de interactie tussen een systeem en de gebruiker weergegeven?

3.5.2 Meerkeuzevragen 1. UML is geen complete systeemontwikkelmethode, maar het voegt een aantal zaken samen. Welke? a. tools, technieken en processen b. technieken, tools en mensen c. hardware, tools en processen d. software, resources en technieken 2. Welk van de volgende diagrammen is geen UML-diagram? a. objectdiagram b. statediagram c. deploymentdiagram d. resourcediagram 3. Klassen kunnen op diverse manieren met elkaar samenhangen. Welke samenhang tussen klassen is niet mogelijk? a. met elkaar verbonden b. afhankelijk van elkaar c. overlappend d. gegroepeerd 4. Welk van onderstaande zaken wordt niet weergegeven in een deploymentdiagram? a. software b. processoren c. devices d. technische infrastructuur

188


5. Waarbij horen de volgende kenmerken? I. prestatieniveau II. betrouwbaarheid III. hergebruik IV. bruikbaarheid V. kwaliteit van het te bouwen systeem a. functionele eisen b. niet-functionele eisen c. systeemeisen d. software eisen

3.5.3 Korte opdrachten Voer deze opdracht uit in tweetallen. 1. In de tekst komt 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. Werk de kaartautomaat van de NS als voorbeeld uit.

3.6 Samenvatting  UML is een visuele modelleertaal met een standaardnotatie. Ieder UML-model gebruikt dus dezelfde symbolen.  UML definieert de basisconcepten van objectgeoriënteerde 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.  UML is in 1996 ontstaan, na een ‘fusie’ van drie bestaande objectgeoriënteerde methoden.  In UML spelen use-cases een centrale rol. Een use-case is een beschrijving van de wijze waarop een systeem kan worden benut.  In de meeste UML-schema’s bevindt zich een actor. Een actor is een schematische voorstelling van een toekomstige gebruiker van het systeem.  De belangrijkste schema’s binnen UML zijn:  het use-casediagram  het classdiagram  het objectdiagram  het sequencediagram en collaborationdiagram  het statediagram  het componentdiagram  het deploymentdiagram.

189

Onder aanvoering van de Object Modeling Group (OMG) werd UML een standaard op het gebied van objectgeoriënteerde modelleren

Recommend Documents