HOOFDSTUK 3 Hoofdstuk 3 3.1 Inleiding UML 3.1.1 Wat is UML? (UML) is een objectgeoriënteerde modelleertaal waarin je de technische werking van informatiesystemen in kaart kunt brengen. UML is vergelijkbaar met ERM, met het verschil dat ERM niet geschikt is voor objectgeoriënteerde systeemontwikkeling. 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. UML: ffis een visuele modelleertaal; ffkent een standaardnotatie; ieder UML-model gebruikt dus dezelfde symbolen; ffdefinieert de basisconcepten van objectgeoriënteerde analyse en ontwerp en omvat een aantal diagrammen voor de communicatie tussen deze concepten; ffis geen complete methode, maar het voegt tools, technieken en processen samen; ffstandaardiseert geen werkwijze, maar een bepaalde schematechniek en terminologie. In UML spelen use cases een centrale rol. Voorbeeld van een UML-diagram van de werking van een frisdrankautomaat. 3.1.2 Use case 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. 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. over de tool Rational Rose vind je op: www-03.ibm.com/software/ products/nl/ratirosefami over de tool Astah vind je op astah.net/ editions/community. Scenario 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. 3.2 Voorbeeld: geldautomaat Aan de hand van het voorbeeld Geldautomaat verduidelijken we de theorie van UML. In paragraaf 3.3 van deze module vind je meer informatie over de belangrijkste schema s van UML. 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. 196 197
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. ffde gebruiker is de actor. ffde actor werkt samen met de geldautomaat. ffachter deze automaat staat een heel banksysteem. ffdit systeem zorgt voor de transactieafhandeling. De use case (rechts) van deze gebeurtenis (links) ziet er zo uit: 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: ffde actor samenwerkt met het systeem; ffde 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. Het poppetje is 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. 3.2.4 Het sequencediagram In het sequencediagram van de geldautomaat (op de volgende bladzijde) 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. 198 199
Objecten Klant Geldautomaat Bankorganisatie Bankfiliaal Operaties Voer kaart in, voer pin in Display menu, vraag naar pin, display transactiebericht Voer transactie uit, controleer pin, pin OK, transactie geslaagd Voer transactie uit, controleer pin, pin OK, transactie geslaagd 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: 3.2.6 Het statediagram 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 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'. 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. 200 201
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 Hiervoor zijn 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 case diagram 3.3.2 Het classdiagram Het classdiagram geeft de statische eigenschappen van klassen weer. In het classdiagram noteer je de eigenschappen (attributen) en methoden. Klassen kunnen op diverse manieren met elkaar samenhangen: ffmet elkaar verbonden; ffafhankelijk van elkaar; ffde 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. Het use case diagram 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: ffbepaal de systeemgrenzen. ffdefinieer de actoren, de spelers in het te bouwen systeem. ffstel use cases voor elke actor vast. ffdefinieer scenario's voor elke use case. ffbeschrijf eenduidig wat er allemaal gebeurt binnen de use cases. ffidentificeer gemeenschappelijke subcases; sommige (sub)use cases kunnen door de verschillende use cases worden hergebruikt. 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: ffobjecten ffde waarden van hun attributen ffhun links. Een use case diagram. Objectdiagrammen worden meestal gebruikt om een bepaalde situatie te verduidelijken, in sommige gevallen om classdiagrammen te verduidelijken. 202 Een objectdiagram. 203
3.3.4 Het sequencediagram en collaborationdiagram Een sequencediagram. 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. ffhet collaborationdiagram laat de koppelingen en de berichten tussen de objecten zien. ffhet sequencediagram toont ook de afhandelingsvolgorde. Zie ook paragraaf 3.2.4 over het sequencediagram en paragraaf 3.2.5 over het collaborationdiagram. 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. Verschillende toestanden 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 op pagina 207. Verbindingslijn De verbindingslijn in het collaborationdiagram tussen twee objecten (klassen) laat de structurele relatie tussen deze twee objecten zien. 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. Een collaborationdiagram. 204 205
3.3.6 Het componentdiagram In het componentdiagram beschrijf je de samenhang tussen de afzonderlijke componenten van een systeem. Dit kunnen bijvoorbeeld zijn: ffhet databasegedeelte ffde gebruikersinterface ffhet 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. 3.4 De fasen in het ontwikkelingstraject Een deploymentdiagram. 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 de volgende paragraaf 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: ffde doelstellingen voor het systeem; ffde totaalvisie voor het systeem. Daarna doorloop je de volgende stappen: ffje legt het bedrijfsmodel vast zoals dat op dat moment bestaat. ffje beschrijft hoe het bedrijfsmodel moet gaan worden. ffje specificeert de functionele eisen die aan het systeem worden gesteld. ffje bepaalt welke onderdelen geautomatiseerd kunnen of moeten worden. ffvoor 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 case diagrammen Systeemeisen Scenario In deze fase ontwikkel je use case diagrammen en bepaal je de relaties tussen de use cases. Hiervoor is het nodig dat je de niet-functionele eisen beschrijft. Systeemeisen gaan over bijvoorbeeld: ffprestatieniveau ffbetrouwbaarheid ffhergebruik ffbruikbaarheid ffkwaliteit 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. 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. 206 207
3.4.3 Fase 3: analyse Als je de use case diagrammen 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 case specificaties door. Op basis van use cases wordt een begin gemaakt met het ontwikkelen van de gebruikersinterface. Verder stel je de formulier- en schermdefinities op en bepaal je 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. 3.4.5 Fase 5: ontwerpfase In deze fase 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. 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. 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: ffde gebruikersinterface; ffde manier waarop het programma aangeboden wordt (online, stand-alone); ffde 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. 3.4.6 Fase 6: constructiefase In deze fase wordt het programma als het ware geassembleerd (in elkaar gezet). 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. 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. 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. 208 209
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? 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 6. Bekijk onderstaand diagram. 4. UML kent verschillende diagrammen. Noem vijf van deze diagrammen. 5. Wat is een actor? 6. In welk diagram worden de objecten met een naar onder 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 Dit is een: a. sequencediagram b. collaborationdiagram c. statediagram d. componentdiagram 4. Wat wordt niet weergegeven in een deploymentdiagram? a. software b. processoren c. devices d. technische infrastructuur 210 211
Hoofdstuk 3 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 verkoopautomaat van anonieme OV-chipkaarten op een treinstation uit in de besproken UML-diagrammen. 3.6 Samenvatting ffuml is een visuele modelleertaal met een standaardnotatie. Ieder UML-model gebruikt dus dezelfde symbolen. ffuml definieert de basisconcepten van objectgeoriënteerde analyse en ontwerp en omvat diagrammen voor de communicatie tussen deze concepten. ffuml is geen complete methode, maar het voegt tools, technieken en processen samen. ffuml is in 1996 ontstaan, na een 'fusie' van drie bestaande objectgeoriënteerde methoden. ffin UML spelen use cases een centrale rol. Een use case is een beschrijving van de wijze waarop een systeem kan worden benut. ffin de meeste UML-schema's bevindt zich een actor. Een actor is een schematische voorstelling van een toekomstige gebruiker van het systeem. ffde belangrijkste schema's binnen UML zijn: yhet use case diagram yhet classdiagram yhet objectdiagram yhet sequencediagram yhet collaborationdiagram yhet statediagram yhet componentdiagram yhet deploymentdiagram. 212