Toelichting op dit erratum

Transcriptie

1 Toelichting op dit erratum Exameninstantie EXIN heeft de eindtermen van Object Oriented Analysis Advanced (OOAA) op een paar punten wat aangepast, waardoor de studiewijzer van de LOI niet meer 100% aansloot bij het examen. Het materiaal is inmiddels op een aantal punten herzien. In dit erratum vindt u deze aanpassingen. Als u de aanvullingen ook bestudeerd, bent u volledig voorbereid op het examen.

2 Inleiding Geen aanvullingen nodig.

3 Hoofdstuk 1 Analyse Basis diagrammen In het stuk tekst onder de inleiding, over de basis diagrammen, moet de opsomming van basis diagrammen als volgt zijn: Uiteindelijk werd er gekozen voor negen basis diagrammen: Use case, klassendiagram, objectdiagram, sequence- en communicatie diagram, activiteiten- en toestandsdiagram, componenten- en deployment-diagram. FURPS+ De tekst over FURPS+ moet als volgt zijn: Een vaak gebruikt geheugensteuntje om na te gaan of we aan alle categorieën van vereisten hebben gedacht, is FURPS+. FURPS staat voor Functionality, Usability, Relability, Performance en Supportability. Vrij vertaald komt dit neer op het volgende: hebben we wél aan alle functionele en bruikbaarheids vereisten (ergonomie) gedacht? Is het systeem voldoende betrouwbaar? Moet het systeem een bepaalde verwerkingssnelheid hebben, en hoe fout tolerant dient het systeem te zijn? De + staat voor Implementation, Interface, Operations, Packaging en Legal. Dus nog wat aanvullende eisen. Use case model De tekst voor afbeelding 3 moet als volgt zijn: In onderstaande tekening (het use case model) wordt het systeem afgebeeld als rechthoek, met daarin een ellips (de use case) die de functionaliteit van het systeem aanduidt. In dit voorbeeld bestaat het systeem slechts uit één use case. Dat kunnen er meerdere zijn. Een videotheek systeem zal niet alleen videocassettes uitlenen maar bijvoorbeeld ook moeten innemen, en inkopen. De lijnen geven aan wélke actor de geboden functionaliteit (direct of indirect) gebruikt. Deze lijnen worden associaties genoemd. De primaire actoren worden meestal aan de linkerkant in het diagram geplaatst, de secundaire aan de rechterkant. De actoren mogen meerdere keren in het diagram worden opgenomen. Dit geldt bijvoorbeeld voor actoren die zowel primair als secundair zijn. Als deze actor slechts eenmaal wordt opgenomen is de echter ook goed omdat de associaties bidirectioneel zijn. De tekst over de Blackbox moet als volgt zijn: Use cases gebruiken een black box-aanpak, dat wil zeggen: ze beschrijven de functionaliteit van een systeem, niet hoe deze functionaliteit technisch gerealiseerd wordt. Wat doet het systeem en niet hoe doet het systeem dat. De interne werking wordt niet beschreven.

4 Patterns De tekst voor de opsomming over enkele gekende analyse patterns moet als volgt zijn: Elk object krijgt een portie van het werk toebedeeld, en de objecten werken samen op een duidelijk gedefinieerde manier. In veel systemen zijn dezelfde soorten verantwoordelijkheden te vinden. Om niet telkens opnieuw daarvoor een oplossing te zoeken zijn deze oplossingen vastgelegd in zogenaamde patterns. Een pattern is een combinatie van een veel voorkomend probleem met een bijhorende standaardoplossing. Artefact De tekst onder de opmerking moet als volgt zijn: Tijdens analyse worden de volgende artefacten gebruikt: Use case diagram, Sequence diagram, Domeinmodel, Activiteitendiagram, Klassendiagram en Toestandsdiagram. Elk van deze diagrammen wordt hieronder kort toegelicht. Frame De tekst Frame moet als volgt zijn: Frame Zoals u uit de tekening kunt opmaken, zijn de system events (die van de actoren naar het systeem gaan) als volle pijl getekend, en de system responses worden als stippellijn pijlen weergegeven. Een klant kan meerdere cassettes uitlenen, en dit betekent dat het system event met de naam registercassette meerdere malen zal worden verstuurd naar het systeem. Er is dus sprake van herhaling. Om een lus te bouwen in een sequence diagram gebruikt u een interaction frame. Er zijn verschillende frames. In afbeelding 10 is het frame voor herhaling opgenomen. Links boven in de label (operator genoemd) staat dat het een herhaling is (loop). Dit frame dient ook een loop (lus) conditie te bevatten, die bepaalt hoe vaak de lus precies wordt uitgevoerd. De conditie (guard) staat tussen vierkante haken vermeld. Andere frames zijn: opt: als de conditie waar is dan wordt de inhoud van het frame uitgevoerd alt: als de conditie waar is dan wordt de inhoud van het eerste deel van het frame uitgevoerd, zoniet dan wordt gekeken of de conditie van het tweede deel van het frame mag worden uitgevoerd par: de verschillende delen van het frame (gescheiden door stippellijn) mogen parallel worden uitgevoerd ref en sd: deze twee frames horen bij elkaar. Zij kunnen diagrammen vereenvoudigen door verwijzingen te maken. sd wordt gezet om een geheel diagram met operator sd <naam>. In een ander diagram kan dit diagram worden gebruikt door een frame op te nemen met operator ref en een vermelding van <naam> in het frame zelf. Frames mogen worden genest, dat wil zeggen dat binnen een frame een ander frame mag worden opgenomen.

5 Multipliciteit De tekst bij Multipliciteit moet als volgt zijn: De notatie van een domeinmodel is in wezen identiek aan deze van een klassendiagram, met uitzondering van enkele aandachtspunten: methodes ontbreken in de concepten, en ook pijlpunten ontbreken op de associaties tussen de concepten. Inderdaad, in een domeinmodel zijn alle associaties bidirectioneel. Het is immers nog véél te vroeg om reeds een duidelijke richting aanwijzing op de associaties te plaatsten, want daar hebben we de methodes voor nodig. Methodes kunnen we slechts later (tijdens het maken van de communicatie diagrammen) ontdekken.

6 Tekst onder afbeelding 12 Onder afbeelding 12 (Activity- diagram voor Uitlenen van cassette ) dient de volgende tekst worden toegevoegd: Het model bestaat uit rechthoeken met afgeronde hoeken, de activiteiten genoemd, en de pijlen, de flow of control. Deze laatste geven de volgorde van de activiteiten aan. De volgorde kan worden bepaald door keuzes en door parallel uitvoerbare activiteiten. Zie onderstaande afbeelding. Elk diagram heeft een start- en eindpunt. De symbolen hiervoor worden ook in andere diagrammen gebruikt. Een extra toevoeging aan het diagram zijn de partities (in het verleden swimlanes genoemd). Dit zijn de verticale vlakken (Shop Mgr, System, Customer) in afbeelding 12. Deze geven aan welke rol welke activiteit uitvoert. Deze vlakken mogen ook horizontaal zijn, naar eigen voorkeur voorkeur. Statediagram Het begrip statediagram moet overal worden vervangen door toestandsdiagram. GOF De tekst bij GOF moet als volgt zijn: GOF patterns (Gang of Four) zijn nét iets technischer dan hun GRASP tegenhangers, en worden later in de design-fase ingezet door de designers, die het klassendiagram opstellen. In de familie van de GOF patterns vinden we een totaal van 23 patterns terug. Eén daarvan is de Composite. Dit pattern geeft een oplossing als het geheel en de delen daarvan op dezelfde wijze worden behandeld. Bijvoorbeeld een product bestaat uit een of meerdere andere subproducten. Elke subproduct wordt echter ook gezien als een product. Naast GRASP en GOF zijn er nog wel meer patterns gedefinieerd. Er wordt namelijk vanuit verschillende hoeken enthousiast gezocht naar patterns die het werk van de analist kunnen vergemakkelijken. Met succes overigens, want regelmatig worden nieuwe patterns ontdekt én voorgesteld op het internet. Dankzij dit medium kan iedereen die dat wenst feedback geven op de plausibiliteit van de patterns, en na grondige studie duiken de patterns dan vaak op in de technische literatuur. Quantity en Business entity zijn voorbeelden van patterns die recentelijk werden voorgesteld, maar die nog niet gecatalogiseerd zijn onder één enkele waaier zoals GRASP en GOF. Quantity. Dit pattern geeft een oplossing voor het problem van het vastleggen van eenheden. Bijvoorbeeld het vastleggen van het gewicht van een persoon kan bij die persoon, maar daarbij is niet duidelijk welke eenheid dat is. Is dat in kilogrammen, grammen of ponden? Problemen die hiermee samenhangen worden voorkomen door het gebruik van het Quantity pattern. Het Business entity pattern heeft als doel het scheiden van het concept business entiteit zoals een persoon of een bedrijf van de rol die zij vervullen. Bijvoorbeeld een persoon Piet kan zowel werknemer zijn als een klant. De persoon blijft hetzelfde maar de rol kan veranderen in de tijd.

7 Hoofdstuk 2 Statisch modelleren Common category list Het begrip common category list moet overal vervangen worden door Conceptual Class Category List. Verder worden de volgende regels toegevoegd aan de laatste alinea boven afbeelding 5: De moeilijkheid bij het verzamelen van al deze klassen van de stakeholders (belanghebbenden) is dat ieder zijn eisen, visie en prioriteiten heeft. Aan de tekst onder afbeelding 7 de volgende zinnen toevoegen: Deze laatste notatie is niet meer toegestaan in UML 2.1, maar omdat u deze toch nog vaak tegen kunt komen wordt deze toch nog even vermeld (ook in het proefexamen komt u deze notatie nog tegen). Bouwen van een domeinmodel Onder de opsomming deze tekst toevoegen: Description klasse Een description klasse en een klasse die informatie bevat over een andere klasse. Bijvoorbeeld een productbeschrijving is een description klasse van een aantal producten. De gegevens van een bepaalde verzameling producten is hetzelfde, het zijn allemaal dezelfde blauwe pennen met dezelfde verkoopprijs, gewicht etc. Als de pen wordt weggegooid blijven de gegevens over die pen bestaan, de pen zelf niet. Collaboratiediagram Het begrip collaboratiediagram in de hele tekst vervangen door het begrip communicatiediagram. UML objectdiagram Aan de tekst onder de kop UML objectdiagram moet de volgende tekst met bijbehorende afbeelding worden toegevoegd: Het objectdiagram is een weergave van objecten die gecreëerd zijn volgens de structuur in het klassadiagram. Een voorbeeld is hieronder te vinden. De videotheek Acht heeft 3 Klanten waaraan het leent.

8

9 Hoofdstuk 3 - Statisch Modelleren Detailleringen Associaties en Attributen De zin over de attributen moet als volgt worden aangepast: Verder is het ook aangewezen om de visibiliteit van elk attribuut duidelijk te noteren met een minusteken ( ) voor private, een plusteken (+) voor public, een een sharp (#) voor protected. Derived attributes Na de tekst over OCL de volgende tekst toevoegen: Identificatie In de traditionele systeemontwikkeling (relationele modellen) is het gebruikelijk dat elke entiteit een eigen unieke sleutelwaarde krijgt. In objectoriëntatie is dit niet nodig. Objecten krijgen geen identifier mee in de vorm van bijvoorbeeld een uniek nummer of code. Ieder object heeft per definitie al een unieke identiteit. Dit neemt niet weg dat het gebruik van de oude identificatie voor gebruikers makkelijk is als zoekcriterium (net zoals de naam van een klant) en dat je ze vaak zult tegenkomen, maar ze zijn dus niet noodzakelijk (en als ze gebruikt worden zijn zij geen identificatie van objecten)! Association class De alinea onder de eerste opmerking moet als volgt worden aangevuld: U mag dus A met C verbinden door middel van een associatieconcept dat de naam B draagt. Voorwaarde is wel dat B ontstaat zodra de link tussen A en C ontstaat en dat B verdwijnt zodra deze link verdwijnt. Toepassen van Inheritance De tekst Super and Sub classes moet als volgt zijn: Super and Sub classes De basisklasse of het basisconcept waar men van overerft noemen we de superclass. De overervende klasse wordt subclass genoemd. Indien we deze subclass opnieuw als basis nemen om van over te erven, dan wordt deze subclass een superclass in de context van de overervende subclass. De subclass erft alle attributen, methoden en associaties van de superclass. Dit betekent dat deze slechts in de superclass vermeld hoeven worden. Is de definitie, implementatie van een of meer van deze eigenschappen anders in de subclass, dan wordt deze eigenschap opnieuw vermeld in deze subclass. Dit wordt overriden genoemd. Daarnaast kan elke subclass eigen attributen, methoden en associaties hebben. Deze worden dan alleen in de subclass vermeld. Op deze manier kunnen we dus een complexe hiërarchie van klassen of concepten bouwen.

10 Ook spreken we over specialisatie en generalisatie -afhankelijk van de manier waarop we het diagram interpreteren. In het volgende voorbeeld staat een basisklasse die we Voertuig hebben genoemd, en waarvan een klasse Auto overerft. De tekst onder afbeelding 5 moet als volgt luiden: In dit voorbeeld is de Auto een specialisatie van Voertuig. Een Auto kan via overerving de eigenschappen en gedragingen van een Voertuig gebruiken, maar kan hier zelf ook dingen aan toevoegen. We denken dan aan specifieke eigenschappen (attributen) en methodes (verantwoordelijkheden) van een auto, die niet terugkomen in Voertuig. Het Voertuig noemen we een generalisatie van de klasse Auto. De Auto erft het attribuut kleur en de methode start() van Voertuig en daarnaast heeft het de eigen attributen pk en type en de methode accelereer() en stop(). Merk op dat overerving géén verplichting inhoudt tot het gebruik van de attributen en methodes van de superclass, het is slechts de mogelijkheid tót het gebruik die geboden wordt. Inheritance and Analysis Patterns Bij de oplossing in de opsomming Statusdiagram vervangen door Toestandsdiagram. Extend De tekst onder afbeelding 13 als volgt aanpassen: De extend-pijl loopt van Use case B náár Use case A. Men stelt dat Use case A uitgebreid wordt door Use case B. Dit gedrag is optioneel, de functionaliteit van B wordt dus niet bij élke uitvoering van A aangeroepen. Het is mogelijk om in use case A aan te geven bij welke stap use case B wordt gebruikt. Dit kan door een horizontale lijn in use case A te tekenen en daaronder die stap te noemen. Dit is dan ook meteen de reden waarom we de call naar Use case B niet in de happy flow (main scenario) terugvinden. Het is immers uitzonderlijk, dan wel alternatief gedrag. In de Videotheek kan een klant bijvoorbeeld tijdens het registratieproces van de mediadragers plots beslissen dat hij die dvd s eigenlijk toch niet wil. Het annuleren van de registratie zou men dan als extend (het is immers een optioneel gedrag) van Uitlenen van Media dienen op te nemen in het Use case diagram. In het cross-references deel van de Use case template geeft men opnieuw aan dat er een relatie bestaat tussen Use case A en Use case B.

11 Hoofdstuk 4 Dynamisch modelleren Ook in dit hoofdstuk overal de volgende termen vervangen: - collaboratiediagram: communicatiediagram - statusdiagram: toestandsdiagram SSD-Notatie tips Na de alinea onder afbeelding 4 de volgende tekst en bijbehorende afbeelding toevoegen: lifeline Een lifeline ontstaat op het moment dat een object wordt gecreëerd (create) en verdwijnt op het moment dat deze wordt beëindigd (destroy). Dit is terug te vinden in het diagram door de verticale positie van het object en de lifeline die daarbij hoort. Het object hoeft dus niet bovenaan in het diagram te staan maar kan bijvoorbeeld halverwege staan en de lifeline kan halverwege het diagram eindigen. De tekst onder het voorbeeld, beginnend met parate kennisvraag 8, en eindigend bij de kop De essentie van SSD, moet vervangen worden door de volgende tekst: [P8]Eventuele parameters worden tussen haakjes, achteraan de naam van het system event toegevoegd (met eventueel het type: message (parameter : parametertype) ). Ook al zijn er geen parameters, toch moeten de haakjes geplaatst worden. Het systeem kan op elk system event reageren met een system response (antwoord van het systeem). System responses zijn gemakkelijk herkenbaar: ze worden steeds in stippellijn weergegeven. Het is wel even opletten bij

12 een antwoord naar een menselijke actor, deze kan immers nooit parameters bevatten! Een alternatief is om niet de response te tekenen maar de response in het system event op te nemen: return = message (parameter : parametertype) : returntype. Return is de variabele waarin de response komt. Optioneel is met returntype aan te geven van welke type dat antwoord is bijvoorbeeld datum. Er wordt niet altijd (direct) een antwoord (response) verwacht van het systeem. Indien er niet op een antwoord wordt gewacht spreekt men van een asynchroon event, indien dit wel het geval is een synchroon event. De notatiewijze verschilt. De pijlkop is bij een synchroon event dicht (zie afbeelding 4), bij een asynchroon event open ( ). De herhaling (lus) en beslissingen in een sequence-diagram is al eerder besproken. Zie hiervoor hoofdstuk 3. De analyse van de Use case-tekst kan uitwijzen dat het systeem, als reactie op een system event, autonoom processen gaat opstarten. Dit moeten we ook in het sequence-diagram opnemen, en wel in de vorm van events naar self of this. Deze system events worden getekend als pijl van systeem naar systeem. In de SSD-afbeelding staan meerdere voorbeelden die dit gedrag uitbeelden. Delegation Om een bepaalde verantwoordelijkheid te kunnen uitvoeren moet een object samenwerken met andere objecten. Als een object zijn verantwoordelijkheid naar een ander object verplaatst/doorgestuurd dan wordt dat delegation genoemd. Dus het verzoek zelf wordt doorgezet naar een ander object. UML-Communicatiediagram De eerste twee zinnen vervallen. Iteration Onder de tekst over Iteration de volgende extra tekst toevoegen: Condition Condities kunnen in het diagram worden opgenomen door de conditie tussen vierkante haken [] op te nemen bij de message. Bijvoorbeeld 1 [kleur = rood] : berekentotaal(). Als er meerdere mogelijkheden, één van de condities is waar, dan wordt er gebruik gemaakt van letters om deze alternatieven aan te geven. Er wordt altijd begonnen met a. Bijvoorbeeld 1a [kleur = rood] : berekentotaal() 1b [kleur = blauw] : berekensubtotaal() Als er als gevolg van bericht 1 een aantal andere berichten moeten worden uitgewisseld voordat bericht 2 mag worden verstuurd, dan worden die subberichten met subnummering uitgerust. Dat wil zeggen achter het nummer van bericht 1 wordt een nieuwe nummering gestart: bijvoorbeeld 1.1 en 1.2. Dit kan ook in combinatie met de alternatieven. Dit zou dan bijvoorbeeld 1a.1 en 1a.2 kunnen worden.

13 UML State Machine Diagram De tekst van de paragraaf UML State Machine Diagram in zijn geheel vervangen door de volgende tekst: UML state machine diagrammen (in het Nederlands ook wel toestandsdiagram genoemd) tonen de diverse toestanden waarin een UML-artefact zich kan bevinden, en de overgangen (transities) tussen die toestanden. Het toestandsdiagram (vroeger genoemd state diagram) kan gemaakt worden om de status van een Use case, een object of ander UML-artefact te tonen. Een toestand vertegenwoordigt een stadium in het gedragspatroon van een object. Een eerste toestand, ook een creation state genoemd, is de status waarin het object zich bevindt wanneer het eerst wordt gecreëerd. Een definitieve toestand of end state is er één van waaruit men geen transities meer kan afleiden. Elke transitie in het toestandsdiagram duidt op de overgang van een state naar een andere, en zal worden teweeggebracht door een event. States worden voorgesteld als rond gemaakte rechthoeken en een object start in een initiële state en eindigt in een state. Voor start en eind worden dezelfde symbolen gebruikt als bij het activity diagram. Onderstaande afbeelding toont een eenvoudige toestandsdiagram. Als het Lichtobject aangemaakt wordt, is het in de status Licht Uit. Zodra er een event on wordt gedetecteerd, verandert de status naar Licht Aan. Omgekeerd zal een off event de status opnieuw laten overgaan naar Licht Uit. Indien het licht uit is, en men detecteert een off event, dan blijft de lichtschakelaar in de status Licht Uit (gaat van Licht Uit naar Licht Uit ). In het model is dat weergegeven door de self transitie. Eigenlijk heeft dit geen betekenis in het voorbeeld zolang er niets gebeurt (action).

14 Transities [P19]Transities of overgangen worden voorgesteld door pijlen tussen de states. De notatie van de labels op de transities is als volgt: event naam van het event dat de transitie triggert [guard condition] een conditie die bepaalt of de transitie ja dan neen wordt uitgevoerd /action aanroepen van een methode van het object waarvan de state wordt voorgesteld. Merk op dat slechts het aangeven van een event verplicht is, guard conditie en actie zijn optioneel. Guard condities kunnen op om het even welke manier, met inbegrip van zowel vrije vormteksten als formele taal worden beschreven. Een voorbeeld van het toevoegen van een action voor de transitie van Licht uit naar Licht aan zou kunnen zijn: on / hogepiep(). Dit zou bijvoorbeeld handig kunnen zijn bij blinden die dan de boodschap krijgen dat het licht is aangegaan. Er kan echter nog meer worden weergegeven in het model. Het is mogelijk om in de status aan te geven wat er gebeurt als deze status wordt bereikt, wat er moet gebeuren zolang deze status actief is en wat er gebeurt als deze status wordt verlaten. Hiervoor worden respectievelijk de termen entry / <operatie>, do/ <operatie> en exit / <operatie> gebruikt. Dit wordt opgenomen in de status zelf onder de naam van de status. Ook in dit diagram is het mogelijk om zaken parallel uit te voeren en/of te synchroniseren. Een object kan zich dan in meerdere verschillende substatussen tegelijkertijd bevinden (nesting) en naar een andere status gaan afhankelijk van de event en/of guard. Een voorbeeld is hieronder te vinden.

15 In dit diagram A wordt begonnen in toestand A en wordt bij event 1 overgegaan naar toestand B. Meer specifiek naar subtoestand1 want het startsymbool gaat direct naar subtoestand1. Op het moment dat event 2 plaatsvindt wordt de overgang naar toestand C gemaakt. Vindt event 3 plaats dan de overgang naar subtoestand2. Het bijzondere in dit voorbeeld is dat van de contour ook een statusovergang is aangegeven, event 5. Dit betekent dat als toestand B geldt (ongeacht dus of dit subtoestand1 of 2 is) dat de overgang bij event 5 gemaakt wordt naar subtoestand 2. Een ander voorbeeld daarvan is dat als event 4 plaatsvindt en de status is toestand B dat wordt overgegaan naar toestand D. In diagram B en C staat aangegeven hoe parallel (stippellijn tussen de parallelle statussen) en synchronisatie (verticale/horizontale balken) wordt weergegeven.

16 Essentie van het toestandsdiagram Het gebruik van toestandsdiagrammen is optioneel. Er moet een duidelijke toegevoegde waarde zijn bij het maken van dit diagram. Analyseer het aantal mogelijke states van een artefact, en ga na of het artefact op een andere manier reageert afhankelijk van zijn status. Alle dynamische artefacten kunnen baat hebben bij dit type diagram, maar in de praktijk zal het vooral gebruikt worden om de toestanden van objecten uit te beelden. UML Timing-Diagram Aan de paragraaf over het UML Timing-Diagram moet de volgende zin en bijbehorende afbeelding toegevoegd worden: Een andere weergave van het Timing-Diagram is de volgende: OCL De tekst van de paragraaf OCL vervangen door de volgende tekst: De Object Constraint Language is een geformaliseerde taal, die we kunnen gebruiken om de beperkingen op niveau van de attributen en methodes in uit te drukken. Er zijn een viertal constraints in OCL uit te drukken: Invariant inv: Preconditie pre: Postconditie post: Guard zie de state machine diagram. Wordt hier verder niet meer behandeld. Constraints worden aan de UML diagrammen toegevoegd als stukjes tekst in een note, die dan wordt gelinkt aan een bepaald artefact. De naam van de class die de OCL dient te respecteren wordt de context genoemd. Invariants OCL maakt gebruik van zogenaamde invariants die dienen gerespecteerd door alle objecten van de klasse waarvoor de OCL gedefinieerd is. Het testen van een OCL kan dus alleen gebeuren door de klasse te instantiëren: klassen zijn immers statisch en vertonen geen gedrag. Invariants worden gebruikt om de waarden van attributen te controleren, en deze laatste krijgen een waarde toegekend in de objecten. De term invariant slaat op het feit dat de beperking steeds geldig moet zijn, ongeacht de toestand van het object. De volgende afbeelding bevat een aantal constraints.

17 In de tekening zien we een associatie tussen een klasse Vlucht en Vliegtuig. Dankzij de constraints kunnen we uitdrukken dat een Vlucht van type cargo enkel vracht mag bevatten, en een Vlucht van type passagier enkel passagiers. Hieronder wat meer gedetailleerde uitleg bij het voorbeeld: Context Vlucht we plaatsen ons in de context van de klasse vlucht. inv: type=cargo implies Vliegtuig.type=cargo de eerste invariant drukt uit dat indien het attribuut type (van de Vlucht) gelijk is aan cargo, het attribuut type (van Vliegtuig) ook de waarde cargo dient te hebben. Het keyword implies is gestandaardiseerde OCL, en betekent het volgende: indien de vermelding links van implies naar true evalueert, dient wat rechts van implies staat eveneens naar true te evalueren, zoniet wordt de invariant niet gerespecteerd. inv: type=passagier implies Vliegtuig.type=passagier de tweede invariant doet precies hetzelfde als de eerste, maar dit keer controleren we of het type van de Vlucht en Vliegtuig gelijk is aan passagier. We hebben de UML-tekening dus preciezer gemaakt door het toevoegen van beperkingen. Deze beperkingen kunnen bovendien door bepaalde case tools worden geïnterpreteerd, en komen dan uiteindelijk ook in de code terecht. Uitgangspunt in de expressie is dus de context, het object waar vanuit wordt gekeken. Het woord self wordt gebruikt in de expressie om naar dit object te refereren, maar mag ook worden weggelaten als dit geen verwarring kan geven. Bijvoorbeeld Context Klant Inv: self.leeftijd > 0 is hetzelfde als Context Klant Inv: leeftijd > 0. Wat ook mag ik het object een naam geven en deze naam gebruiken om te verwijzen naar dat object. Dus Context Klant : K Inv: K.leeftijd > 0. K is dus naam waarmee verwezen wordt naar het object Klant. Indien er tussen het object Vliegtuig en Klant twee associaties bijv met rolnamen passagier en betaler bestaan kan het zo zijn dat je die Klant wilt die passagier is. Je kunt die Klant gebruiken die passagier is vanuit de context van Vliegtuig door die in het pad te benoemen door de rolnamen te gebruiken. In dit geval Context Vliegtuig inv: self.passagier.. Op deze wijze kun je van object naar object lopen in het model om de constraints te definiëren (door telkens een punt te plaatsen). Dit moet natuurlijk wel kloppen met het model.

18 De constraint zelf mag ook een naam gegeven worden. Die naam wordt dan gezet voor de invariant zelf (dus na de inv:). Bijvoorbeeld Context Passagier Inv controleleeftijd : leeftijd > 0. Om attributen of operaties aan te duiden van een object wordt eerst het object genoemd, gevolgd door een punt en dan gevolgd door de naam van het attribuut of operatie. Zie in het voorbeeld Vliegtuig.type. De gebruikelijke operatoren mogen worden gebruikt in de expressie zoals +, -, *, /, >, <, =, <>, <=, >=. Daarnaast mag ook gebruik gemaakt worden if, else en endif, and, or, xor, not. En nog veel meer. Er zijn ook operaties voor verzamelingen (multiobjecten) maar deze worden hier verder niet besproken. Pre- en postconditie Voor de controle van operaties gebruikt men ook constraints, maar dan vaak in de vorm van pre - en postcondities. De context wordt in het geval van operaties Context <object>:: <operatie>. Bijvoorbeeld Context Bestelling :: verstuur() heeft betrekking op de operatie verstuur van object Bestelling. We kunnen dan vervolgens een preconditie en/of een postconditie hierbij beschrijven. Een voorbeeld: Context Bestelling::voegToeArikel() Post: self.totaal = self.totaal@pre + Artikel.prijs

19 Hoofdstuk 5 - Modelmanagement Ook in dit hoofdstuk overal de volgende termen vervangen: - collaboratiediagram: communicatiediagram - statusdiagram: toestandsdiagram Dependency pijl Onder de tekst na de kantkop dependency pijl, voor de de tekst over de namespace, moet de volgende tekst worden toegevoegd: Een element is eigendom van de package waarin het is gedefinieerd. Dus A is eigendom van de package Sales, maar er kan aan worden gerefereerd in een ander package. Dus A kan worden opgenomen in package Products door eraan te refereren. Dit gebeurt door het element A op te nemen in package Products met als label Sales::A. Dus notatie PackageName::ElementName. Dan kan de associatie tussen A en Z worden opgenomen, maar wel binnen de package. Inzendopgaven In opgave 5 en 7 dient u bij antwoord A respectievelijk antwoord D collaboratiediagram te vervangen door communicatiediagram.