EEN INLEIDING IN DE

UNIFIED MODELING LANGUAGE

Inleiding

Aannemer bouwt volgens bouwplannen

-> toont het ontwerp van het huis

Programmeurs, softwarearchitecten en analisten gebruiken

modelleertalen -> beschrijven het ontwerp van

software door middel van grafische

notaties

Modelleertaal

= een grafische notatie voor het beschrijven van softwareontwerpen

omvat regels waarmee juiste van onjuiste tekeningen kunnen worden onderscheiden het zijn deze regels die de UML tot een

modelleertaal maken, in plaats van alleen een verzameling symbolen voor het tekenen

Is verschillend van een methodologie

Methodologie

beschrijft een procedure voor het ontwerpen van software levert richtlijnen voor het analyseren en

ontwerpen van softwareomvat vaak een modelleertaal, die dan

dat ontwerp op grafische manier weergeeft de modelleertaal illustreert het ontwerp door

een methodologie te volgen.

UML

= een algemeen aanvaarde standaard modelleertaal nodig voor het modelleren van software zodat

anderen uw ontwerpdiagrammen snel en makkelijk kunnen begrijpen

Unified Modeling Language betekent letterlijk vereende modelleertaal UML is het resultaat van drie met elkaar

concurrerende modelleertalencursus is geen uitgebreide inleiding in de UML

UML

= taal= een betekenisvolle (grafische)

notatiewijze om de verschillende aspecten in een objectgeoriënteerd ontwerp weer te geven

bestaat uit een verzameling van min of meer onafhankelijke diagramtechnieken Klassediagram Objectdiagram Volgordediagram

Klassediagram

laat zien: welke klassen er zijn ontworpen welke attributen en bewerkingen of

methodes deze klassen hebben welke relaties tussen deze klassen bestaan

= een weergave van de statische structuur van een programma

Klassediagram

waarom een klassediagram: is codeonafhankelijk

code is de laagste vorm van documentatie van het ontwerp, alhoewel de meest volledige, maar nutteloos voor iemand die de implementatietaal niet kent

ontwerp is in één oogopslag te begrijpenu kan zich concentreren op de structuur

(hoofdklassen en inhoud van de klassen)van de klassen op een hoog niveau doordat de grafische notatie u afschermt van de details

De basisnotatie voor klassen

notatie:

«Naam van klasse»

«Eigenschappen»

«Bewerkingen»

De basisnotatie voor klassen

syntaxis voor attributen of eigenschappen naam: type = waarde

alles tussen de rechte haken mag worden weggelaten

= waarde : standaardwaarde die het attribuut krijgt bij de creatie van een instantie van de klasse

enkel de naam van een attribuut kan vermeld worden.

De basisnotatie voor klassen

syntaxis voor methode of bewerking naam(parameterlijst) : resultaattype

minimale aanduiding = de naam van de methode plus een paar haakjes

in UML : bewerking is verschillend van methode• bewerking = een service die u bij een willekeurig

object van een klasse kunt aanvragen• methode = een specifieke implementatie van die

bewerking

De basisnotatie voor klassen

zichtbaarheid: - : voor private + : voor public # : voor protected

opmerking helpt soms betekenis over te dragen die

anders verloren zou raken of over het hoofd zou worden gezien

= gele post-it briefjes

De basisnotatie voor klassen

voorbeeld van een opmerking :

Bank

+ addAccount( )+ totalHoldings( ) De Bank bevat een aantal+ totalAccounts( ) rekeningen en levert+ deposit( ) bewerkingen voor het werken+ balance( ) met deze rekeningen

Geavanceerde notatie voor klassenom meer beschrijvende of omschrijvende

modellen mogelijk te makenstereotype

= een UML-element om de vocabulaire van de taal UML zelf uit te breiden

bestaat uit een woord of een zinsnede tussen dubbele hoekige haakjes (« »)

wordt boven of naast een bestaand element geplaatst

Geavanceerde notatie voor klassen

stereotype voorbeeld:

BankAccount

«accessor» + getBalance( )+ depositFunds( )+ withdrawFunds( )

Geavanceerde notatie voor klassen

abstracte klasse en abstracte methode naam van de klasse en de methode :

cursief voorbeeld: BankAccount

- balance :double

+ depositFunds(amount : double) : void+ getBalance( ) : double# setBalance( ) : void+ withdrawFunds(amount : double) : void

Uw klassen modelleren om aan uw doeleinden te voldoen

verschillende keuzemogelijkheden om klassen te modelleren -> welke notatie nu gebruiken?

situatie-afhankelijk: • niet-technisch persoon <-> collega• aangepaste vocabulair

Tips voor het effectief modelleren Wat probeer ik over te dragen? Aan wie probeer ik die informatie over te dragen? Zo een eenvoudig mogelijk model maken om een zo

effectief mogelijk ontwerp over te dragen.

doel : de publieke interface van de klasse Bank over te dragen

Uw klassen modelleren om aan uw doeleinden te voldoen

Bank

addAccount( )totalHoldings( )totalAccounts( )deposit( )balance( )

Uw klassen modelleren om aan uw doeleinden te voldoen

Tips voor het effectief modelleren Verzand niet in de modelleertaal.

niet al te veel van de semantiek afwijken, maar model hoeft niet helemaal perfect zijn

• Maak u alleen zorgen als uw model het ontwerp niet goed overdraagt

de UML = hulpmiddel doel -> ontwerp over te dragen.UML is geen doel op zichzelf -> nog steeds

code moet geschreven worden

Relaties tussen klassen modelleren

Klassen hebben ingewikkelde relaties tot elkaar relatie

-> beschrijft hoe klassen samenwerken -> wordt in de UML aangegeven met een verbinding tussen twee of meer elementen in de notatie

in UML : 3 soorten relaties Afhankelijkheid Associatie generalisatie

eigen notaties maar UML-onafhankelijk

= object is afhankelijk van de specificatie (interface of gedrag) van een ander object wijziging in specificatie -> bijwerking van

het afhankelijke object voorbeeld:

Afhankelijkheid

PsychiatristObject MoodyObject

+ examine( ) + queryMood( ) : String

2 x afhankelijkafhankelijkheidsmodel bevat enkel de

kenmerken die van belang zijn voor de afhankelijkheidsrelatie

• doel van UML is informatie over te dragen

Afhankelijkheid

PsychiatristObject MoodyObject

+ examine( ) + queryMood( ) : String

afhankelijkheden zoveel mogelijk beperkensoms onmogelijk : niet alle

afhankelijkheden zijn gelijk: Afhankelijkheid van een interface = acceptabel Afhankelijkheid van de implementatie = nooit

acceptabelWanneer moet u afhankelijkheden

modelleren? als het ene object een ander object gebruikt.

Voorbeeld : in argumenten van methoden

Afhankelijkheid

dieper dan afhankelijkheidsrelaties= structurele relatie

associatie geeft aan dat een object een ander object bevat of dat de objecten met elkaar verbonden zijnvoorbeeld :

naam van de associatie = naam die de relatie beschrijft in casu: naam = Leent van

Associatie

Leent vanPersoon Bank

de rol van een object in de associatie

meervoudigheid geeft aan hoeveel objecten er aan de associatie deelnemen meervoudigheid wordt weergegeven door

enkel getal : exact dat aantal objecteneen asterisk : * = willekeurig aantaleen lijst :

• 1..4 = minimum 1, maximum 4• 3..* = 3 of meer

Associatie

lener uitlenerPersoon Bank

voorbeeld van meervoudigheid:

Wanneer moet u associaties modelleren? als het ene object een ander object bevat -

de ‘bevat een’-relatieof als een object een ander object gebruikt

Een associatie maakt het u mogelijk te modelleren wie wat doet in een relatie.

Associatie

Persoon Bank1..* *

twee subtypen om modellen verder te verfijnen aggregatie compositie

beiden zijn deel/geheel-relaties of ‘bevat een’-relaties beschrijven de relatie tussen objecten

waarbij het ene object een ander object bevat

Associatie

= deel/geheel-relatie tussen gelijken gelijken = het ene object is niet

belangrijker is dan het andere in de relatiebelangrijk = de objecten kunnen

onafhankelijk van elkaar bestaan

voorbeeld:

Aggregatie

Bank

1..*

*

Klant

wordt aangegeven met een open ruitje object dat ruitje raakt = het geheel van de

relatie; de klasse die naar de andere klasse verwijst of bevat

de andere klasse(n) is het deel of delen in voorbeeld:

Bank : geheelKlant : deelze zijn onafhankelijk van elkaar; dus elkaars

gelijken• als de Bank verdwijnt, verdwijnen de klanten niet en

omgekeerd

Aggregatie

Wanneer moet u aggregatie modelleren? als het model tot doel heeft de structuur

van een deel/geheel-relatie tussen gelijken te beschrijven.

Mocht u er echter meer in geïnteresseerd zijn te modelleren wie wat doet in een relatie, dan kunt u beter een gewone associatie gebruiken: een relatie zonder het ruitje.

Aggregatie

strenger dan aggregatiedeel/geheel-relatie maar niet tussen gelijken wordt aangegeven met een zwart ruitje (aan

de kant van het geheel)

in voorbeeld: Filialen kunnen niet onafhankelijk van de Bank bestaan alle filialen worden gesloten als de bank

wordt gesloten omgekeerd : de bank kan open blijven als

een filiaal wordt gesloten

Compositie

Bank Filiaal1 *

Wanneer moet u compositie modelleren? als het model tot doel heeft de structuur

van een deel/geheel-relatie maar niet tussen gelijken te beschrijvenHet onderdeel is dus afhankelijk van het

geheelin voorbeeld: alle filialen zullen gesloten

worden, als de bank wordt gesloten.in termen van programmeren betekent dit

dat alle Filialen vernietigd zullen worden als de Bank wordt vernietigd

Compositie

Wanneer moet u compositie modelleren? Mocht u er echter meer in geïnteresseerd

zijn te modelleren wie wat doet in een relatie, dus de rollen van de objecten in de associatie, dan kunt u beter een gewone associatie gebruiken: een relatie zonder het ruitje

Compositie

Een object kan tegelijkertijd aan een aggregatierelatie en een compositierelatie deelnemen:

Aggregatie en Compositie

Bank Filiaal

1..*

*

Klant

1 *

= relatie tussen het algemene en het specifieke

= voorstelling van de ‘is een’-relatie voor vervanging geschikte relaties

definiëren:afstammelingen worden gebruikt in plaats

van hun voorouders of children in plaats van hun parents

Generalisatie

Generalisatie

we weten hoe basisklassen en relaties te modelleren -> nu beginnen met redelijk veelzeggende modellen te vormen

2 modellen : hebben gemeen:

Elk model bevat net voldoende informatie en net genoeg notatie om het idee over te dragen.

Deze modellen hebben niet tot doel elke beschikbare notatie te gebruiken.

combineren verschillende elementen van de UML. U kunt zeer informatieve modellen maken door de

diverse elementen te combineren.

Alles bij elkaar

Alles bij elkaar

Alles bij elkaar

Toepassing 1:Modelleer een bij/ bijenkorf compositierelatie.

Toepassing 2:Modelleer de associatie tussen een winkelbezoeker en een winkelier. Specificeer de rollen, de meervoudigheid en de associatienaam.

Toepassingen

Toepassingen

Toepassing 1:

Toepassingen

Toepassing 2:

Toepassing 3:Gegeven een klasse Cirkel, met een attribuut straal met standaardwaarde 1. De klasse heeft methoden om de omtrek en het oppervlak van de cirkel te berekenen, alsmede een methode om de cirkel in een vlak te plaatsen met het middelpunt op gegeven coördinaten. Teken een klassediagram waarin deze informatie over attributen en methoden is opgenomen.

Toepassingen

Toepassingen

Toepassing 3:

Toepassing 4:Maak een klasse Artikel. Hiermee wordt een artikel bedoeld die bijvoorbeeld in een winkel verkocht wordt. Deze klasse heeft attributen artikelnummer, prijs, naam en voorraad. De klasse beschikt eveneens over een methode getPrijs( ). Teken een klassediagram waarin deze informatie over attributen en de methode is opgenomen.

Toepassingen

Toepassingen

Toepassing 4: