Samenvatting OOPF
1. Objectoriëntatie en systeemontwikkeling
1.1 De kandidaat heeft inzicht in de historische achtergrond van objectoriëntatie.
Traditionele programmeermethoden: eigenschappen en gegevens wordden gescheiden van de bewerkingen die op die gegevens worden uitgevoer.
Object orientatie: gegevens en bijbehorende bewerkingen worden opgeslagen in één object. Een object is een zelfstandig geheel binnen een systeem waarvan de structuur wordt gevormd door met elkaar communicerende objecten.
Traditionele methoden varieren van procesgerichte modellering (gaat uit van de functionaliteit van het systeem) tot gegevensgerichte modellering (gaat uit van de gegevens in een systeem en de functionaliteit volgt daaruit)
Procesgerichte modellering:
- functionele decompositie
- processen op hoog niveau inventariseren en opdelen in deelprocessen, deze ook weer opdelen totdat niet verder opdeelbaar
- dan op niveau van elementaire functies uitwerken
- Nadeel: niet flexibel, achteraf moeilijk bij te stellen
Objectgeorienteerde modellering:
- domein modellering: modelleerd de werkelijkheid (domein) waarin het systeem gaat werken
- Het domein model geeft een weergave van de concepten in het domein met hun kenmerken, gedrag en onderlinge relaties en bevat geen automatiseringsaspecten.
- Via een aantal vertaalslagen wordt van dit model een systeem gemaakt.
- De functionalteit zit in de objecten
Gegevensgeorienteerde modellering:
- ook hier wordt meestal domeinmodellering toegepast, maar deze vorm belicht allen de statische aspecten van het systeem.
- het dynamische deel wordt later (in de vorm van processen en functies) toegevoegd, maar ongestructureerd en daardoor lastig aan te passen/uit te breiden.
OO besteed zowel aandacht aan de statische als de dynamische aspecten (gegevens en processen) en de vormgeving daarvan geschied in diagramtechnieken in UML.
OO heeft grote gevolgen voor de gehele systeemontwikkeling:
- methoden en manier van werken aanpassen
- ontwikkelplatformen, daatabases, programmeertaken en besturingsystemen dienen geschikt te zijn voor OO
Objecten zijn vooral geschikt voor het nabootsen, ontwerpen en simuleren van bedrijfsobjecten en bedrijfsprocessen.
Verschillende methoden van systeemontwikkeling:
1) Watervalmethode (traditionele methode)
Verschillende fasen volgen elkaar op, er is geen weg terug: definitiefase, analyse, ontwerp, implementatie, testen.
2) Incrementeel en iteratief ontwerpen (OO)
Telkens een klein deel (increment) maken en verder bouwen op wat er al is, of iteratief (herhalend) de traditionele fasen doorlopen.
Op basis van implementatie en testen opnieuw de fase doorlopen.
Timeboxen: elke iteratie of increment levert een werkend systeem op dat getest kan worden.
3) Agile ontwikkelen
Agile = soepel, beweeglijk
Een systeem moet kunnen mee-evolueren met zijn omgeving. Nieuwe inzichten moeten worden meegenomen tijdens de ontwikkeling. Voorbeeld Dynamic Systems Development Methode (DSDM).
2. Objectgeoriënteerd denken
2.1 De kandidaat kent de voordelen en valkuilen van objectoriëntatie (OO).
OO is een hulpmiddel om tot betere systemen en software te komen, maar geen garantie
Voordelen OO:
1) Objectorientatie is natuurlijk
- Objecten vormen de basis, die een afbeelding vormen van in het domein voorkomende abstracte en concrete begrippen (zowel gegevens als functies)
- Deze ontstane modellen sluiten beter aan op de manier waarop de gebruikers het domein zien.
- Er wordt op functioneel, conceptueel niveau gemodelleerd (geen IT jargon)
2) Betere integratie van data en processen
- Hierdoor wordt de kans op inconsistenties tussen datamodellen en procesmodellen verkleind.
3) Betrouwbare software
- Makkelijk te wijzigen zonder dat het hele systeem beinvloed wordt
- Elk onderdeel is apart te testen
4) Ondersteuning van hergebruik
- Hergebruik van klassen, maar ook van producten uit de analyse en ontwerpfase
- Vanwege inkapseling hoeft bij hergebruik geen rekening gehouden worden met de implementatie van die klassen.
Een object communiceert met zijn omgeving uitsluitend via en extern interface.
5) Betere onderhoudbaarheid
6) Betere uitbreidbaarheid
7) Tijdige oplevering
- Verkorten ontwikkelcycli door herbruikbare en uitbreidbare software
- Natuurlijkheid beinvloed ontwikkelsnelheid
- Parallele ontwikkeling mogelijk
Valkuilen en misvattingen OO:
1) Objectorientatie is gewoon een taal
- Objectorientatie houdt meer in dan het gebruik van een objectgeorienteerde porgrammeertaal
- Objectorientatie is het denken in objecten, het denken in termen van polymorfie, insluiting en overerving.
"A fool with a tool is still a fool"
2) Objectorientatie als panacee voor alles
- Gebruik van OO garandeerd niet dat het project zal slagen.
Betrokkenen moeten nog steeds gezond verstand en beroepsmatige kennis gebruiken
3) Hergebruik wordt niet gestimuleerd
- en dat is net nodig voor optimaal gebruik van OO
4) Er wordt niet gedeeld
- Eigen klassen en programmeercode beschikbaar stellen
- Begrijpelijke interfaces en goede documentatie om hergebruik te vergemakkelijken
2.2 De kandidaat kent de basisbegrippen van OO en hun toepassing.
Basisbegrippen:
1) Object
Object is een software constructie die bestaat uit:
- interne data (toestand object beschrijven en onzichtbaar voor de buitenwereld)
- extern interfaces (gedrag van een object ten opzichte van zijn omgeving)
Object = instantie (gemaakt van blauwdruk "klasse")
Domein = de werkelijkheid waarin het systeem gaat werken
Objecten van dezelfde klasse verschillen van elkaar (invulling attributen)
Eigenschappen van een object kunnen zelf ook weer een object zijn, met eigen interne data en extern interface.
Bij objectorientatie hebben objecten een identiteit die onafhankelijk is van de waarde van hun attributen.
Relatie tussen objecten:
- objecten kunnen onafhankelijk van elkaar bestaan. Ze communiceren d.m.v. berichten; die geven een object opdracht om iets te doen.
- Een object kan ook een ander object bevatten. Objecten kunnen via aggregatie uit andere objecten zijn samengesteld.
2) Klasse (Class)
Een klasse is een beschrijving van een groep objecten met dezelfde eigenschappen, hetzelfde gedrag, dezelfde relaties en dezelfde semantiek.
Een klasse is een abstractie of sjabloon voor een bepaald type objecten.
Klassen bieden het voordeel van herbruikbaarheid
In een klassedefinitie wordt duidelijk onderscheid gemaakt tussen het implementatie gedeelte en het interface gedeelte.
Zodra functies en/of procedures tot een klasse behoren noemen we ze "methoden" of "operaties".
In pseudocode plaats je de inhoud van methodes in de klasse. (In C++ erbuiten, in Java of C# er binnen).
3) Instantie (Instance)
Een instantie is dus een object. Een afdruk van de template, het sjabloon, de klasse.
4) Associatie (Association)
Associaties zijn relaties tussen klassen (trek een lijn tussen klassen)
- statische relaties: verbanden tussen verschillende attributen van verschillende klassen
- dynamische relaties: dynamische verbanden tussen klassen: een instantie van de ene klasse mag gebruik maken van de diensten van een instantie van een andere klasse.
5) Attribuut (Attribute)
Een attribuut is een benoemde eigenschap van een klasse, die wordt gedeeld door alle objecten in die klasse en die door middel van een datawaarde wordt beschreven.
Door inkapseling zijn attributen niet voor de omgeving zichtbaar, ze kunnen alleen m.b.v. de bijbehorende operaties worden gelezen en veranderd.
6) Bericht (Message)
Objecten communiceren met elkaar door middel van berichten die via de externe interface:
- aan een object worden afgegeven met het doel de toestand van het object te veranderen of bepaalde opdrachten uit te laten voeren
- door een object worden teruggegeven om het resultaat van een opdracht mede te delen.
Berichten maken het mogelijk om onafhankelijk te blijven functioneren.
Doorgeven van berichten wordt als dynamisch beschouwd.
7) Operatie (Operation)
Een operatie is een functie of transformatie die mag woden toegepast op instanties van een klasse (op objecten dus).
Objecten van dezelfde klasse vertonen hetzelfde gedrag en hebben dus dezelfde operaties.
Via operaties worden diensten geleverd, een object dat een boodschap ontvangt, voert als gevolg daarvan en operatie uit.
8) Methode (Method)
Methode is de implementatie van een operatie op de gegevens van een object (definitie van de functies)
Een bericht is een verzoek om een bepaalde taak (methode) uit te voeren (door gebruik te maken van functienamen).
Status van een object wordt mede bepaald door de waarde van zijn gegevens en kan gewijzigd worden door berichten naar het object te zenden.
Statische methoden zijn methoden die aangeroepen kunnen worden zonder dat er een instantie van die klasse bestaat.
Dit kan handig zijn als er veel functies zijn di in een apart gedeelte van het programma moeten worden ondergebracht en die aangeroepen moeten kunnen worden zonder dat er een object is.
2.3 De kandidaat kent de basisprincipes van het Objectgeoriënteerd modelleren.
Drie basisbegrippen/steunpilaren van OO zijn:
1) Insluiting (encapsulation)
Insluiting houdt in dat een onderdeel van het systeem zijn interne details voor zichzelf houdt en door de rest van het systeem als een "black box" kan worden beschouwd; je kan er mee communiceren, maar je weet niet wat er vanbinnen gebeurd.
Insluiting verhoogt de overzichtelijkheid en stabiliteit omdat het overal in het systeem hetzelfde reageert en functioneert.
Localiteitsprincipe: het systeem is te verdelen in kleinere, van elkaar onafhankelijke delen, die op zichzelf staan en hun werk onafhankelijk van de andere onderdelen doen.
Insluiting is niet nieuw in de informatica wereld. Bijvoorbeeld Modula2 doet aan insluiting van functies. Nieuw is dat zowel attributen als operaties in objecten worden ingesloten.
Het interface van een klasse toont de door de klasse opgeleverde services: dat is het contact met de buitenwereld, het publice interface.
"Implementatie" beschrijft de interne details van het object en defineert hoe het object feitelijk een service levert, dus hoe iets gedaan wordt en hoe op een bericht gereageerd wordt.
"Implementation hiding": De interface is het gezicht naar buiten toe en verbergt het "hoe".
"Information hiding":
- informatie blijft verborgen binnen het object en is niet toegankelijk buiten het object.
- zorgt erovor dat bepaalde eigenschappen van de klasse niet verkeerd kunnen worden gebruikt.
Meeste OO talen onderscheiden 3 niveau's van toegang:
a) Publiek (public): iedereen mag benaderen
b) Beveiligd (protected): toegang aan objecten van eigen klasse of subklasse
c) Privé (private): alleen objecten van de eigen klasse hebben toegang.
Kenmerken van effectieve insluiting:
- abstractie
- verbergen van implementatie
- verdelen van de verantwoordelijkheden (responsibilities). Dat houdt in dat het object samenhangend moet zijn, er zitten geen zaken in die er niet thuishoren. De eigenschappen van het object moeten op een nauwe conceptuele manier met elkaar verbonden zijn en elk object heeft zijn eigen verantwoordelijkheid hoe met de verzoeken van de buitenwereld om te gaan.
2) Overerving (inheritance)
Uitgaande van een bestaande klasse kan een nieuwe klasse worden ontworpen die dezelfde eigenschappen en gedragingen als de oorspronkelijke klasse bezit, maar zich van deze onderscheidt door één of meerdere toevoegingen.
Overervingshierarchie:
- Nieuwe klasse: subklasse, childklasse of specialisatie
- Oude klasse: superklasse, parentklasse of generalisatie
Een childklasse heeft een "is een" ("is a") relatie met een parentklasse.
Door overerving kan je klassen voor algemene doeleinden definieeren terwijl daarvan afgeleide specialisaties worden gedefinieerd voor specifieke zaken.
"Operation overriding": een subklasse implementeert een ge-erfde operatie van een superklasse anders.
De operatie van de subklasse geniet prioriteit t.a.v. de operatie van de superklassen.
Wordt ook wel herdefinieren van een methode genoemd.
Mogelijke voordelen overerving:
1) Projecten kunnen sneller worden afgerond: gedeelten van het systeem bestaan al en kunnen worden verwerkt in het nieuwe systeem.
2) Door bovengenoemde tijdwinst ook lagere kosten voor de ontwikkeling van het project
3) Kans op hoog kwaliteitsniveau omdat het nieuwe systeem voor een deel is opgebouwd vanuit bestaande, in de praktijk gebruikte, componenten (die hun waarde al bewezen hebben).
3) Polymorfie (polymorphism)
Objecten kunnen op dezelfde boodschap verschillend reageren.
Je maakt gebruik van de kennis dat meerdere klassen dezelfde methoden hebben.
Je kunt deze methode al op hoog niveau (superklasse) vast leggen en dan in subklassen (verschillend) uitwerken/herdefinieren.
(denk aan python's print object methode, of het kunnen optellen van zowel getallen als strings.
3. Inleiding Unified Modeling Language (UML)
3.1 De kandidaat kent de belangrijkste begrippen en basisnotaties van UML.
UML is een gestandaardiseerde modelleertaal voor objectorientatie
Sinds 1996 is het de standaardtaal voor OO die door OMG (Object Management Group) is ingesteld.
UML is geen methode, maar een taal; een weergave van het systeemontwerp.
Doordat UML een standaard is die voorschrijft hoe begrippen en diagrammen moeten worden weergegeven, ontstaat er voor alle partijen (eindgebruikers, ontwikkelaars, programmeurs en projectmanagers) duidelijkheid over wat er bedoeld wordt.
UML kent 9 soorten diagrammen:
1) Klassediagram (class diagram) [gebruik van analyse t/m implementatiefase]
- geeft een beschrijving van de structuur van het systeem.
- alle klassen en relaties tussen klassen worden weergegeven.
- van klassen worden o.a. attributen, operaties en eventuele beperkingen vermeld
2) Objectdiagram of instantiediagram (object diagram)
- is opgebouwd als een klassediagram, maar geeft in plaats van klassen instanties weer (daarwerkelijke voorkomens)
3) Use-case diagram of requirementsdiagram (use-case diagram) [gebruik vooral eerste fase v.e. project]
- geeft een beschrijving van het systeem zoals dit gebruikt gaat worden door de eindgebruiker
- beschrijving in natuurlijke taal van een taak die een systeem moet kunnen uitvoeren
- gebruik vooral in de eerste fase van een project om duidelijk te krijgen wat de wensen van de gebruiker precies zijn.
4) Sequentiediagram (sequence diagram) [gebruik vooral analysefase]
- geeft een beschrijving van de tijdsvolgorde waarin objecten boodschappen naar elkaar sturen.
- meestal beschrijft één sequencediagram één use-case
- gebruik vooral in de analysefase, als elementen uit de werkelijkheid omgezet moeten worden in een model
5) Communicatiediagram (communication diagram) of samenwerkingsdiagram (collaboration diagram)
- geeft aan hoe de diverse objecten in een systeem met elkaar samenwerken om een bepaald doel te kunnen bereiken.
- meestal één use-case per diagram
6) Toestandsdiagram (state chart diagram) [gebruik tijdens ontwerpfase van een project]
- geeft een overzicht van alle mogelijke toestanden waarin een object zich kan bevinden gedurende zijn levensloop.
(Zie tekening 1: toestandsdiagram klasse "Brood")
7) Activiteitsdiagram (activity diagram) [gebruik tijdens ontwerpfase v.e. project]
- laat zien welke activiteiten door een deel van het systeem worden uitgevoerd en in welke volgorde dit gebeurd (je kunt ook parallele activiteiten weergeven)
(Zie tekening 2: activiteitsdiagram activiteit Informatie aanvraag)
8) Component diagram (component diagram) [gebruik analyse en ontwerpfase v.e. project]
- geeft een verdeling weer van het hele systeem in componenten (onderdelen van het systeem) en relaties tussen deze onderdelen
- een systeem wordt in componenten opgesplits om de componenten zoveel mogelijk onafhankelijk van elkaar te laten functioneren (daardoor ook elders herbruikbaar)
(Zie tekening 3: componentdiagram met afnemers, producten en bestellingen)
9) Deployent diagram (deployment diagram)
- laat zien welke component instanties op welke nodes (hardware) draaien en hoe deze zicht tot elkaar verhouden.
(zie tekening 4: deployment diagram)
Logische volgorde van het gebruik van UML diagrammen:
| | |
|INFORMATIE ANALYSE | ONTWERP | REALISATIE
|__________________ _______________________ | _________________ ____________________|
| | | | | | | | |
| Use-case-diagram |=======>| Sequentie- of |===|===>|Toestandsdiagram |=======>| Activiteitsdiagram |
| | | communicatiediagram | | | | | |
|__________________| |_______________________| | |_________________| |____________________|
| \\ | // |
|________\\__________________ ___________________|________ _____________________//__________|
| * | | | | | * |
| Eerste versie classdiagram |=====>| Tussenversies classdiagram |========>| Definitieve versie classdiagram |
|____________________________| |___________________|________| |_________________________________|
| | |
| | |
| | |
- Use-case diagrammen worden op basis van de wensen van de gebruikers gemaakt
- Omdat Sequentie en communicatiediagrammen zoveel op elkaar lijken wordt bijna altijd maar één van beide gemaakt (sequentie als volgorde belangrijk is, communicatie als belangrijk is duidelijk te maken hoe de objecten met elkaar in verbinding staan.)
- Het definitieve klassemodel kan in de realisatiefase van het project (als het goed is) letterlijk vertaald worden naar programmacode.
- Bij grote, gecompliceerde systemen wordt er tijdens de ananlysefase ook gewerkt met met component en deployment modellen.
De diagrammen zijn niet statisch, ze ontwikkelen mee tijdens de systeemontwikkeling.
verduidelijking kunnen voorvoegsels worden gebruikt die het ontwikkelingsstadium van het diagram aangeven:
1) domeinmodel of domeindiagram (domain/conceptual model):
- alleen concepten uit de werkelijkheid, geen automatiseringsaspecten
2) applicatie model of applicatiediagram (application model):
- naast domein aspecten ook zaken die betrekking hebben op hoe de gebruikers met het systeem gaan werken.
3) implementatiemodel of implementatiediagram (implementation model):
- beschrijft de implementatie van het systeem.
- is een uitbreiding van het applicatiemodel met implementatieaspecten zoals opslagstructuren.
-> deze aspecten worden zodanig uitgewerkt dat ze direct kunnen worden getransformeerd naar programmacode
Het komt zelden voor dat van elk diagram deze drie ontwikkelingsversies worden gemaakt.
UML heeft zowel kenmerken van een structuurmodel (structural model, statisch) als van een gedragsmodel (behavioral model, dynamisch) in zich.
Je kunt de verschillende diagrammen indelen:
Structuur model:
- klassediagrammen
- object diagrammen
- component diagrammen
- deploymentdiagrammen
Gedragsmodel:
- toestandsdiagrammen
- use-case diagrammen
- sequence diagrammen
- communicatie diagrammen
- activiteitsdiagrammen
3.2 De kandidaat heeft inzicht in klasse- (class) en objectdiagrammen.
Klasse is een verzameling van objecten met overeenkomstige eigenschappen.
Klassen kunnen naast attributen één of meer operaties; de processen die een object van die klasse kan uitvoeren.
Object is een ding uit de werkelijkheid dat een zelfstandig bestaan leidt.
Objecten hebben altijd een eigen identiteit; ze kennen geen sleutelattributen
Objecten wisselen onderling informatie uit door de operaties, die daarom ook wel services genoemd worden, deze communicatie geschiedt door het sturen van boodschappen naar elkaar (message)
UML notatie van een klasse:
Rechthoek in drie delen:
- bovenste deel: Naam van de klasse
- middelste deel: attributen van de klasse
- onderste deel: operaties van de klasse
Afhankelijk van de detaillering kunnen attributen en/of operaties worden weggelaten uit het diagram.
Zichtbaarheid:
- de interne details van een klasse zijn verborgen voor andere objecten; een object kan alleen benaderd worden via de interface.
- drie niveaus van information hiding:
-> privé: aangegeven door een + voor het attibuut of de operatie
-> publiek: aangegeven door een - voor het attribuut of de operatie
-> beschermd: aangegeven door een # voor het attribuut of de operatie (dat kan alleen in bepaalde programmeertalen zoals DELPHI en C++)
Generalisatie, specialisatie en overerving
Hoe ga je te werk:
a) Maak een eerste versie van het klasse diagram.\
b) Kijk dan of er klassen zijn die identieke attributen of operaties hebben
c) zo ja, specificeer een nieuwe klasse die deza gezamelijke kenmerken bevat: generalisatie => superklasse
d) de klassen waar die gezamelijke kenmerken uit gehaald worden heten subklassen; door overerving krijgen ze de gezamelijke kenmerken ook.
Notatie: De subklassen zijn met hun superklasse verbonden met een lijn met een pijlpunt (wijst van subklasse naar superklasse)
Associatie: relatie tussen klassen
Notatie van een associatie:
- Een lijn trekken tussen de klassen die een associatie met elkaar hebben.
- De naam van de associatie wordt bij de lijn geschreven.
- Lees de associatie van links naar rechts en van boven naar beneden tenzij met een pijl ernaast anders aangegeven wordt.
- Het is ook mogelijk dat er meerdere associaties tussen klassen zijn.
Link: instantie van een associatie
- Bijvoorbeeld als de associatie is "werkt voor" tussen werknemer en afdeling, dan kan de bijbehorende link zijn: "Max Halen werkt voor de afdeling Marketing".
Rol: soms maakt de naam van de klasse niet duidelijk genoeg welke rol een klasse in de associatie speelt.
- Dan plaats je de naam van de rol naast de klasse
- soms wordt voor rol i.p.v. een zelfstandig naamwoord ook wel een werkwoord gebruikt.
Multipliciteit: hoeveel instanties kan een object hebben in die associatie
- Bij het uiteinde van een associatie kan dit aantal worden aangegeven
- voorbeeld: een medewerker kan maar onder één afdeling vallen, maar de afdeling kan meerder werknemers hebben, dan een "1" bij de associatie aan de afdeling kant en "1..*" (één of meer) bij de associatie aan de werknemerskant.
- notatie multipliciteit:
* = nul of meer
1 = exact één (mag ook weggelaten worden, dan wordt 1 verondersteld)
0..1 = nul of één
1..* = één of meer
2..8 = twee t/m acht
Associatieklasse (association class):
- aan een associatie kan een klasse worden gekoppeld, als er nadere informatie over die associatie moet worden vastgelegd, anders dan tussen welke klassen en met welke multipliciteit die associatie bestaat.
- een instantie van die associatieklasse ontstaat zodra er een link van die klasse ontstaat en verdwijnt zodra de link verdwijnt.
- bijvoorbeeld als je van een associatie tussen werknemer en project een uren registratie wil bijhouden.
Compositie (composition)
- een object bestaat uit andere objecten
- aangegeven met een lijn met een zwarte (dichte) ruit bij de compositie
- onderdeel van een compositierelatie mag allen tot die compositierelatie behoren.
- Ook mag het deelobject zonder het gehele object kunnen bestaan.
Aggregatie (aggregation)
- een aantal onderdelen vormen samen een geheel
- aangegeven door een lijn met een witte (open) ruit bij de aggregatie
- Of iets een aggregatie of een compositie relatie heeft hangt af van je gezichtspunt.
Abstracte klasse (abstract class)
- een klasse waarvoor een bepaald gedrag (operaties) niet concreet is ingevuld, wordt een abstracte klasse genoemd.
- hiervan kunnen geen objecten worden gemaakt
- notatie: klassenaam schuin schrijven en (optioneel) "{abstract}" achter de naam zetten.
Concrete klasse (concrete class)
- een klasse waar je wel een object van kan maken heet een concrete klasse.
Stereotype
- Klassen kunnen worden getypeerd door middel van een stereotype
- mogelijke stereotypen en wat ze uitbeelden:
1) implementatieklasse: de klasse is ontworpen voor gebruik in een implementatie
2) type: de klasse definiëert een concept uit het domein
3) domein: de klasse is een domeinklasse (ontwikkelingsfase domein)
4) applicatie: de klasse is een applicatieklasse (ontwikkelingsfase applicatie)
5) implementatie: de klasse is een implementatieklasse (ontwikkelingsfase implementatie)
- notatie: naam van het type tussen guillemets: <<type>> of <<domein>>
Constraint
- elementen in het klassediagram worden beperkt in (de combinatie van) hun instanties.
- Object Constraint Language (OCL)
- voorbeeld: einddatum van een project moet NA begindatum liggen.
- notatie: gestippelde pijl tussen associatie met tussen accolades de contraint in OCL
- voorbeeld: Xor-constraint ("exclusive or" constraint): van de twee of meer klassen waarbij deze contraint is aangegeven, kan maar één klasse geinstantieerd zijn.
-> bijvoorbeeld om aan te geven dat bij een muziekopname deze of van een band kan zijn, of van een solozangeres, maar niet beide.
- notatie alternatief: constraint kan ook in commentaarblok tussen accolades gezet worden.
Commentaar (note box)
- opmerking in een rechthoek zetten en deze met een stippellijn verbinden met het element of de associatie(s) waar de opmerking op slaat.
Domeinklasse
- eerst wordt het domeinmodel opgesteld.
- alleen concepten uit de werkelijkheid, geen automatiseringsaspecten worden opgenomen
Nadat het domeinmodel is opgesteld, moet dit worden uitgebreid worden zodat we tot een applicatiemodel of implementatiemodel komen.
Dat wil zeggen een herhaling van stappen die tot het domeinmodel geleidt hebben, maar nu met de aandacht op applicatieaspecten (objecten specificeren waar de gebruiker directe interactie mee heeft) of implementatieaspecten (klassen toevoegen die de implementatie van het systeem ondersteunen).
Applicatieklasse
- gebruikersinterface
- Twee type klassen in een gebruiksinterface:
-> views (presentaties): objecten worden op een voorgedefinieerde aan de gebruiker gepresenteerd.
bottom-up ontworpen vanuit de interactiediagrammen
-> controllers: klasse die de manier bestuurt waarop de gebruiker met het systeem werkt: hij verwerkt de invoer, en stuurt de views en domeinobjecten aan.
top-down ontworpen vanuit de use-cases
Implementatieklasse
- voorbeelden zijn utility klassen (hulpklassen?), klassen vor de opslag van objecten en klassen die als intermediair fungeren tussen domeinobjecten en de fysieke opslag in een lagen structuur (3-tier architectuur)
Klasse en object diagram:
- zijn in UML twee manieren om het te ontwerpen systeem op een statische manier te beschrijven. Objectdiagrammen worden voornamelijk gebruikt om een ingewikkeld klassediagram te verduidelijken met voorbeelden.
3.3 De kandidaat heeft inzicht in use-case-diagrammen.
In het begin van het project moetje systeemeisen bepalen:
- functionele eisen: de te bouwen functionaliteit van het systeem
- niet-functionele eisen: de voorwaarden waaraan die functionaliteit moet voldoen (bijv. hardware en software omgeving, standaard user-interfaces, hergebruik systeemcomponenten, responsesnelheid etc) -hier wordt verder niet op in gegaan...
Use-case: beschrijving in natuurlijke taal van de manier waarop (een deel van) het syteem gebruikt kan worden.
Voor elke systeemfunctionaliteit één use-case voor een compleet beeld van de mogelijkheden van het systeem en wie de actoren zijn (actoren zijn GEEN deel van het systeem)
Andere componenten zijn:
- aannamen
- beschrijving (stappenplan) van de interactiestappen
- alternatieven of uitzonderingen
- resultaat (toestand van het systeem na afloop v.d. use-case)
Er is in UML geen standaardnotatie van Use-cases, maar vaak wel volgens bepaalde template (sjabloon), echter de opsteller van de use-case bepaalt de elementen.
Algemene richtlijn is: naarmate het risico van een use-case groter wordt, wordt deze gedetailleerder beschreven.
Voorbeeld template van een use-case:
1) Naam v.d. use-case
2) Doel
3) Actoren
4) Begintoestand
5) Aannamen
6) Beschrijving (v.d. interactiestappen tussen actoren en systeem)
7) Alternatieven
8) (Eind)resultaat
De deelstappen die bij 6) Beschrijving staan beschreven, vormen de basis voor het sequentie of communicatie/collaboratie diagram.
Werkwijze use-cases en use-case diagrammen:
1) Bepaal de systeemgrenzen (verantwoordelijkheden van het systeem, welke functies moet het systeem globaal kunnen uitvoeren) en de actoren (welke actoren zijn er en welke rollen /taken hebben zij).
2) Bepaal de use-cases: voor elke actor beschrijven welke taken hij met behulp van het systeem moet kunnen uitvoeren (één use-case per taak)
3) Bepaal de aannamen: per use-case bekijken onder welke voorwaarden de use-case kan worden uitgevoerd (bijv. bepaalde gegevens moeten bekend zijn)
4) Bepaal de interactie: in gebruikerstaal omschrijven via welke stappen de use-case normaal gesproken wordt uitgevoerd (wat gebeurd er?)
5) Bepaal de alternatieven en uitzonderingen.. en welk effect een alternatief op de use-case heeft.
6) Splits veel voorkomende subcases uit: als er bij verschillende use-cases een gezamelijke component zit, kan je die eruit halen en in een subcase zetten.
Deze subcase kan je dan in alle betreffende use-cases aanroepen: Include - relatie: gestippelde pijl die wijst van de use-case naar de subcase
Het is ook mogelijk dat een use-case gebruik maakt van een andere use-case: extends-relatie: gestippelde pijl die wijst van de nieuwe use-case naar de oorspronkelijke.
De keuze tussen use-case of subcase is afhankelijk van het feit of de actor deze case alleen uitvoert als onderdeel van de oorspronkelijke use-case (dan kies je voor subcase) of ook afzonderlijk (dan kies je voor nieuwe use-case).
In de oorspronkelijke use-case worden een of meer uitbreidingspunten (expansion points) gedefinieerd.
Uitbreidingspunt: een naam die een punt in de beschrijving van de use-case markeert en wordt bij de extends-relatie genoteeerd om aan te geven waar in de uitvoering van de use-case de tweede use-case wordt ingevoegd.
Er kan ook een voorwaarde (condition) aan de uitvoering van de tweede use-case verbonden worden.
7) Maak het use-case diagram:
- als alle use-cases helemaal zijn uitgewerkt, probeer je deze in een use-case diagram te verzamelen om op een grafische manier duidelijk overzicht te krijgen van de functionaliteit van het te ontwerpen systeem en de bijbehorende actoren. Verdere detaillering haal je daarna uit de use-cases.
- notatie: actor = poppetje of klasse met bovenin de vermelding "<<actor>>".
use-case = ellips met de naam van de use-case erin.
alle use-cases in een rechthoek plaatsen (het systeem) en alle actoren buiten het systeem zetten. Door middel van doorgetrokken lijn de actoren met de use-cases verbinden (of de use-cases met elkaar).
3.4 De kandidaat heeft inzicht in de toepassing van interactiediagrammen.
Interactiediagram: welke interactie is tussen objecten nodig om het gewenst systeemgedrag te bewerkstelligen.
Sequentie en communicatie diagrammen worden onder de noemer van interactiediagrammen geschaard.
Beide soorten diagrammen geven dezelfde informatie weer, alleen de notatie (en het accent) verschilt
Sequentiediagrammen: tijdsvolgorde van de interacties
Communicatiediagrammen: welke objecten moeten met elkaar samenwerken
Basis voor beide soorten diagrammen is altijd een use-case diagram.
Interactie diagrammen laten op een eenvoudige, visuele manier zien hoe objecten in een systeem met elkaar samenwerken.
Relevante concepten:
1) Interactie
- reeks gebeurtenissen die beschreven staan in één use-case
- in interactie diagrammen meer gedetailleerd beschreven en vertaald van actor en systeem naar objecten die input krijgen van actoren en boodschappen sturen naar andere objecten in het systeem.
2) Klasse
- in een sequentie of communicatiediagram worden klassen ook als rechthoeken getekent, maar zonder attributen en operaties.
- Actoren worden ook als rechthoeken zoals klassen genoteerd, met bovenin de klasse "<<actor>>" vermeld of of als poppetje.
3) Levenslijn (life line)
- in sequentiediagrammen (niet communicatie) wordt aan elke rechthoek, behalve aan actoren een zogenaamde levenslijn (life line) gekoppeld.
- langs deze lijn ontwikkelt zich de levensloop van het object gedurende de interactie.
- notatie: levenslijn begint als vertikale stippellijn en als object geactiveerd wordt, wordt dit een smalle vertikale balk.
4) Boodschap
- een boodschap is een bericht dat van het ene object naar het andere gestuurd wordt.
- een interactie bestaat uit een serie van boodschappen.
- een boodschap is een pijl tussen de levenslijnen van de objecten en de naam van de boodschap erbij
- in een sequentiediagram is de volgorde van boven naar beneden en in een communicatiediagram krijgen de boodschappen een volgnummer.
5) Frames en verwijzingen (ref frame)
- alleen mogelijk in sequentiediagrammen
- zet ineractie diagram in een frame, met linksboven de naam van het interactiediagram voorafgegaan door "sd" (sequentiediagram)
- bij verwijzing gebruik je de naam van het interactiediagram en zet je "ref" en de naam van het diagram waarnaar wordt doorverwezen. Een ref in een interactiediagram is een horizontale balk door beide actieve levenslijnen.
6) Tijd constraint
- alleen in sequentiediagrammen
- beperking op het tijdsverloop tussen twee boodschappen
- notatie: aantekening in de kantlijn van het diagram
7) Asynchrone boodschap
- een boodschap die op het moment van verzending niet direct verwerkt hoeft te worden (dus de zender wacht niet totdat de ontvanger klaar is met het verwerken van de boodschap)
- notatie synchrone boodschap: dichte pijlpunt
asynchrone boodschap: open pijlpunt
8) Conditionele boodschap
- notatie: frame dat doormidden wordt gesplits door een stippellijn. Linkboven zet je "alt" en tussen vierkante haken de voorwaarden, daarachter de naam van de boodschap
9) Iteratie van boodschappen
- een serie boodschappen herhaald zich
- notatie: frame met linksboven "loop", in het frame tussen vierkante haken de iteratie expressie met voor de vierkante haak een "*" ( *[...] )
10) Actieve objecten
- de meeste objecten zijn passief en reageren alleen als er een boodschap binnenkomt
- sommige objecten echter kunnen zelf boodschappen versturen.
- notatie in interactiediagrammen: een rechthoek met een extra lijn aan beide zijkanten van de rechthoek.
11) Recursie (recursion)
- een object kan een operatie van zichzelf aanroepen.
- notatie in sequentiediagrammen: een pijl die van de oorspronkelijke levenslijn van de klasse van het object naar een nieuwe levenslijn (die gedeeltelijk over de oorspronkelijke ligt) wijst.
- notatie in communicatiediagram: een pijl langs een lijn die naar de klasse zelf gaat. Bij het eindpunt wordt "<<self>>" gezet
Linksboven in diagram: sd voor sequentie diagram, cd voor communicatiediagram
Algemene werkwijze om tot een klassediagram te komen:
Alhoewel UML een modelleertaal is en geen methode of werkwijze, wordt toch een algemene werkwijze besproken om tot een klassediagram te komen:
1) De klassen identificeren (classificeren)
Maak een zolang mogelijke lijst met alle zelfstandige naamwoorden die in de use-cases naar voren komen.
Deze lijst bij voorkeur nog uitbreiden d.m.v. brainstorm sessies waarbij gebruikers en ontwikkelaars zo veel mogelijk potentiele klassen benoemen.
2) Selectie van klassen die in het klassediagram (dus informatiesysteem) moeten worden opgenoemen.
-> Dat doe je door de lijst van stap 1) te toetsen aan de volgende criteria:
a) Relevant: Is de klasse relevant? (valt deze duidelijk binnen use-cases of probleemomschrijving)
b) Zelfstandige rol: Heeft de klasse een zelfstandige rol in use-cases of probleemomschrijving?
c) Verantwoordelijkheid: Heeft de klasse een duidelijke verantwoordelijkheid in het systeem?
d) Niet redundant: Heeft de klasse niet dezelfde info en verantwoordelijkheden als een andere klasse?
e) Duidelijke betekenis: Is er makkelijk een definitie van de klasse te maken?
f) Kwantificeerbaar
g) geen attribuut of operatie
h) geen rol: een rol is tijdelijk en kan veranderen tijdens de levensloop van een object. Een object kan tijdens de levensloop niet van klasse veranderen.
Bij twijfelgevallen noteer je de voor en tegens.
Als twijfelt of iets een attribuut of een klasse is, is een handige tip: "als je informatie wil opnemen over het "woord" dan is het een klasse, anders eerder een attribuut.
Eventueel als het moeilijk is een keuze te maken tussen attribuut of klasse, kan je er een hulpklasse van maken.
3) Zoek associaties tussen klassen
- bijvoorbeeld door alle klassen één voor één met elkaar te vergelijken en te kijken of er associaties zijn. (op die manier vindt je echter vaak niet de associaties tussen meer dan twee klassen)
En vervolgens per paar (per associatie) nagaan of:
-> de associatie relevant is (valt ie duidelijk binnen use-cases of probleemomschrijving)
-> de associatie structureel is (eenmalige relaties zijn geen associaties)
-> de associatie niet redundant is (kan niet afgeleid worden uit andere associaties)
4) Identificeer attributen en operaties
5) Bepaal eventuele generalisaties
6) Leg eventuele beperkingen (constraints) vast
7) Tot slot: stel het klassediagram op: kijk of het klassediagram voorziet in de belangrijkste informatiebehoeften van het systeem.