Hoofdstuk: 1 Objectoriëntatie en systeemontwikkeling

vrg:

trefwoord

OOF

trefwrd onderverdeling

omschrijving aant Css: 2

Programmeren Hoofdstuk:

669

Objectoriëntatie en systeemontwikkeling -

blz 5

OO

1

1

Objectoriëntatie en systeemontwikkeling

OO staat voor object oriented of objectoriëntatie of objecttechnologie. Is de overkoepelende term die elke ontwikkelstijl omvat die op het concept van objecten is gerealiseerd. Hierbij worden de gegevens en de bijbehorende bewerkingen samen als één object opgeslagen. Een OBJECT is een zelfstandig geheel binnen een systeem waarvan de structuur wordt gevormd binnen een systeem waarvan de structuur wordt gevormd door met elkaar communicerende objecten. Ze kunnen worden gezien als een afspiegeling van dingen uit de werkelijkheid.

670

Verschillen OO en gestructureerd modelleren -

blz 6

GEGEVENSGERICHTE MODELLERING of DATAGEORIËNTEERDE ONTWIKKELING > structurering op basis van de gegevens die het IS moeten bevatten. Gaat uit van de gegevens van het systeem en de functionaliteit volgt daaruit. Bij gegevensgerichte modellering wordt ook domeinmodellering toegepast, maar deze vorm van weergeven belicht alleen de statische aspecten vh systeem. Het dynamische aspect (processen en functies) wordt ook toegevoegd maar op een ongestructureerde manier zodat achteraf aanpassen of uitbreiden heel lastig is.

1.1

PROCESGERICHTE MODELLERING > structurering van modellen op basis van de processen die het IS moeten uitvoeren (bewerken van gegevens). Gaat uit vd functionaliteit vh systeem en de gegevens die nodig zijn volgen hieruit. Er is hier meestal sprake van: **FUNCTIONELE DECOMPOSITIE **> Hierbij worden processen op hoog niveau geïnventariseerd. Deze processen worden opgedeeld in deelprocessen, deze deelprocessen worden ook weer opgedeeld en zo verder tot deze niet meer opgedeeld kunnen worden en we op het niveau van de functies zijn beland. Wijzigen is dan lastig en alle lager gelegen lagen moeten dan ook vaak aangepast worden.

671

Verschillen OO en gestructureerd modelleren -

blz 7

objectgeoriënteerde modellering -

1.1.1

DOMEIN > Is de werkelijkheid waarin het systeem gaat werken. DOMEINMODELLERING - als OO deze werkelijkheid/dit domein modelleert. DOMEINMODEL > geeft een weergave vd concepten in het domein met hun kenmerken, gedrag en onderlinge relaties, maar het bevat geen automatiseringsaspecten. Zulk systeem is HEEL FLEXIBEL omdat de functionaliteit vh systeem in objecten zit, het toevoegen is dan niets anders dan het in een bepaalde volgorde, in bepaalde omstandigheden gebruiken van bestaande operaties in nieuwe of bestaande objecten. OBJECTGEORIËNTEERDE modellering *** > houdt zich bezig met DYNAMISCHE én STATISCHE aspecten. STATISCHE ASPECTEN > gegevens DYNAMISCHE ASPECTEN > processen

672

Methoden van systeemontwikkeling -

blz 7 1.2

zaterdag 25 juli 2015

Bij OBJECTORIËNTATIE (OO) bestaat een object uit gegevens én functies. Ze zijn vooral geschikt voor het nabootsen, ontwerpen en simuleren van bedrijfsobjecten en bedrijfsprocessen. Met objecten kunnen we eenvoudiger levensechte gegevens over het gedrag van bedrijfsobjecten en bedrijfsprocessen vastleggen.

Pagina 1 van 36

vrg:

trefwoord


673


blz 7

watervalmethode -

1.2.1

omschrijving

Watervalmethode. Hier wordt het project in opeen volgende fases opgedeeld. Per fase wordt beschreven wat moet gebeuren en wat wordt opgeleverd. Output van bv fase 1 is de input van fase 2. Elke fase wordt afgesloten door het opleveren van eindproducten cq deliverables en heeft meetpunten cq mijpalen, aan de hand v mijlpalenrapportage wordt gekeken of het resultaat nog niet goed genoeg is óf goed is en door naar volgende fase én óf het nog aansluit. Sommige acitviteiten kunnen naar voren gehaald worden, zoals bv opleiden van medewerkers. Definitiestudie > analyse > ontwerp > implementatie > testen > e.d. deze lijkt veel op de liniaire werkwijze, echter bij watervalmethode kunnen correcties gemaakt worden, door terug naar de vorige fase te gaan om deze correctie/wijziging door te voeren. Overdracht van fase naar fase is een lastig punt. nadeel > is tijdrovend en bij voorschrijdend inzicht is het moeilijk om op stappen terug te keren. Dat inzicht komt vaak pas tevoorschijn bij testen en dit gebeurt laat in het project.

674


blz 7

incrementeel en iteratief ontwikkelen -

1.2.2

INCREMENTEEL ONTWIKKELEN > houdt in dat er iedere keer een klein deel van het totaal wordt opgebouwd, elk increment bouwt voort op hetgeen al bestaat. ITERATIEF ONTWIKKELEN > hierbij worden de traditionele fases steeds opnieuw doorlopen, op basis van de implemantatie en het testen worden de eisen aan het systeem bijgesteld en wordt de cyclus opnieuw doorlopen. TIMEBOX > alle incrementen/iteraties worden steeds in kleine tijdsspanne uitgevoerd. De kosten en de einddatum van een timebox liggen vast, maar wat een timebox opleverd, dat kan wel variëren! Elke timebox levert dus een groot of klein systeem, dan kunnen de gebruikers het testen en feedback geven en zo wordt de basis voor de volgende timebox weer geleverd. Dit is uitstekend geschikt om in combinatie met OO te gebruiken.

675


blz 7

agile ontwikkelen -

1.2.3

AGILE = soepele, beweeglijkheid. AGILE METHODEN > gaan ervan uit dat een systeem met zijn omgeving moet kunnen mee-evolueren en dat nieuwe inzichten die tijdens het ontwikkelproces worden opgedaan in de ontwikkeling kunnen worden meegenomen. Bijv: DSDM (Dynamic systems Development Method).

Hoofdstuk:


2

Objectgeoriënteerd denken

Pagina 2 van 36

vrg:

trefwoord


676

Objectoriëntatie (OO) -

blz 18

voordelen -

2.1

677

Objectoriëntatie (OO) -

blz 20

nadelen -

2.1.2


omschrijving

1. OBJECTORIËNTATIE IS NATUURLIJK > In OO kent men de termen array of variabele niet, in plaats daarvan gebruikt men natuurlijke taal die de terminologie van het domein gebruikt. Daardoor wordt OO op functioneel, conceptueel niveau ontworpen. Het gaat er niet om hoe maar om het WAT! 2. BETER INTEGRATIE VAN DATA EN PROCESSEN > Vanwege de inkapseling van attributen en operaties is in object is bij OO de onderlinge samenhang tussen gegevens en processen op een natuurlijke wijze geïntegreerd. Daardoor de kans op inconsistentie (tegenstrijdigheden) aanzienlijk verminderd. 3. BETROUWBARE SOFTWARE > Wijzigingen aanbrengen in het systeem wordt makkelijker omdat objecten relevante gegevens en operaties isoleren op de plek waar ze thuishoren. Op deze manier kun je ieder object ook apart testen. 4. ONDERSTEUNING VAN HERGEBRUIK > Dit is een van de grootste voordelen van OO. Vanwege inkapseling hoeft bij hergebruik van klasse geen rekening gehouden te worden met de implementatie van die klassen en vanwege de structuren die in OO kunnen bestaan tussen verschillende klassen, is het creëren van nieuwe klassen op basis van oude klassen eenvoudiger. 5. BETERE ONDERHOUDBAARHEID > (is een vd belangrijkste!) Een probleem hoeft maar op één plaats aangepast of gewijzigd te worden, door goede documentatie en de natuurlijke taal kan het systeem ook goed onderhouden, verbeterd of aangepast worden door andere ontwikkelaars. Men moet er wel voor zorgdragen dat de samenwerking tussenverschillende klassen goed blijft verlopen na een aanpassing. 6. BETERE UITBREIDBAARHEID > zie punt 5 7. TIJDIGE OPLEVERING > Ontwikkelingscycli kunnen door OO worden verkort, omdat dit betrouwbare, herbruikbare en uitbreidbare software oplevert. De natuurlijkheid v OO bevordert de snelheid vh modelleren en ontwerpen. Veranderingen in gebruikerswensen is ong 42% van alle wijzigingen en is het grootste deel vd onderhoudskosten.

1. OO IS GEWOON EEN TAAL > Er zijn objectgeoriënteerde programmertalen en er is obejectoriëntatie, dit zijn twee aparte dingen en ze zijn niet identiek aan elkaar. OO is het denken in objecten en het denken in termen als polymorfie, insluiting en overerving. Zonder OO behaalt men geen voordeel met het werken met Objectgeoriënteerde programmeertalen. 2. OBJECTORIËNTATIE ALS WONDERMIDDEL VOOR ALLES > Dit is misschien wel de grootste valkuil, OO is echt géén wondermiddel. 3. HERGEBRUIK WORDT NIET GESTIMULEERD > Men moet vaak wennen aan het idee dat je klassen en programmeercode makkelijk kunt hergebruiken en ze niet iedere keer opnieuw hoeft te maken. 4. ER WORDT NIET GEDEELD > Men moet ook leren de klassen en programmacode voor hergebruik beschikbaar te stellen. Er moeten begrijpelijke interfaces gemaakt worden zodat andere het ook begrijpen en goed gedocumenteerd worden.

Pagina 3 van 36

vrg:

trefwoord


678

Basisbegrippen v OO en hun toepassing -

blz 21

object -

2.2.1

omschrijving

OBJECT > is de instantiatie ve klasse. OBJECT > is een software instructie die toestand en gedrag insluit en bestaat uit: 1. INTERNE DATA > deze beschrijven de toestand vh object voor het gedeelte dat onzichtbaar blijft voor de buitenwereld. 2. EXTERNE INTERFACE > wordt ook wel het gedrag ve object tov zijn omgeving genoemd en kan de data manipuleren en van toestand laten veranderen. Is het besturingspaneel ve object. OBJECT > is een inkapseling van attribuutwaarden en de bijbehorende exclusieve diensten. Belangrijk verschil tussen objecten in de conventionele datamodellering en in de objectoriëntatie is het feit dat objecten bij OO een identiteit hebben die onafhankelijk is vd waarde van hun attributen. OBJECTEN kunnen op verschillen manieren aan elkaar GERELATEERD zijn: 1. Objecten KUNNEN ONAFHANKELIJK van elkaar bestaan > geven onderling berichten door met verzoek tot het verlenen ve service. 2. Een Object kan OOK ANDERE Objecten BEVATTEN > objecten kunnen via aggregatie (of compositie) uit andere objecten zijn samengesteld. Attributen > zijn statisch Methodes > zijn dynamisch Een OBJECT is een INSTANTIE (instance) van een KLASSE. De KLASSE kan men zien als een bouwtekening. Er kunnen dus veel objecten gemaakt worden van één klasse. Objecten zijn onderdelen vh DOMEIN. Het DOMEIN is de werkelijkheid waarin het systeem gaat werken. Objecten uit een klasse kunnen onderling verschillen. Ze zijn van hetzelfde type, maar hebben onderling verschillende eigenschappen (bv klasse autos, hier kunnen cabrio's inzitten, maar ook vrachtauto's). **HEEFT-een (HAS-A)-RELATIE ** > een eigenschap kan zelf ook weer een object zijn (bv de auto en de motor die in de auto zit, de motor heeft zelf ook weer eigenschappen en methoden etc). Bv strijkbout: de temperatuurregelaar is hier de interface, de temperatuur is de toestand en de bout het object. Hier kan de temperatuur worden ingesteld zonder dat je kennis hoeft te hebben vh interne technologie en zonder dat de noodzaak is om deze te veranderen. ANALOGIE > is een overeenkomst tussen twee zaken die men als grondslag neemt voor een redenering. Het object van de analogie wordt analogon genoemd. In de biologie beschouwt men twee structuren als onderling analoog als die dezelfde of gelijkende functie dienen, maar evolutionair gezien afzonderlijk tot stand zijn gekomen. Er is dan sprake van convergente evolutie. ANALOGIE > object is een product, dat gemaakt wordt aan de hand ve tekening (oefenex.1vr2).

257


Pagina 4 van 36

vrg:

trefwoord


679


blz 22

klasse (class) -

2.2.1

omschrijving

is een beschrijving ve groep objecten met dezelfde eigenschappen, hetzelfde gedrag, dezelfde relaties en dezelfde semamtiek (betekenis). Het bevat een beschrijving vd wijze waarop nieuwe tot de klasse behorende objecten (cq instanties) kunnen worden gecreëerd. Een klasse is een abstratie of sjabloon voor bepaalde type objecten. Omgekeerd is een object een instantie (concreet voorkomen) ve klasse. De operaties definiëren de koppeling met de wereld buiten het object. De gegevens die door de operaties worden gebruikt zijn meestal voor de buitenwereld afgesloten. De variabelen ve een klasse worden dus objecten of instanties genoemd. Een klasse definieert alle kenmerken die gemeenschappelijk zijn voor een type object, maar ook alle eigenschappen en gedragingen die door het object ter beschikking worden gesteld. Het is een "blauwdruk" of "prototype" dat de definitie bepaald van instantievariabelen, methoden en interface van alle objecten van dezelfde klasse. Voordeel > herbruikbaarheid. Door gebruik van klassen wordt ruimte bespaard en heeft het programma minder omvang wat weer een korte downloadtijden tot gevolg heeft. Zie fig 2.3 Hier zien de de pseudocode voor de klassedefinitie "File", bij de klasse File is duidelijk verschil tussen implementatie (bevat de attributen) en de interface (bevat operaties) te zien. Fig. 2.5 geeft de pseudocode van hoe je een klasse opbouwt. Daarna kunnen objecten er gebruik van maken. Waar de inhoud van operaties en methoden moet komen te staan hangt af van de taal die gebruikt wordt. Bij C++ en Object Pascal komt buiten de klasse te staan en bij Java en C# wordt het in de klasse gezet. **Klasse en object zijn te vergelijken met een taartvorm en de taart. Voorbeeld ve klasse: - klasse > fiets standaardmodel - eigenschappen > frame, 2 wielen, stuur, bel ….etc - object > damesfiets, type 5128, geen stang, framhoogte 51 kleur donkergroen…etc

258

680


blz 25

associaties -

2.2.2


dit zijn relaties tussen klassen en worden weergegeven door een lijn tussen de klassen. We maken onderscheid in: - STATISCHE RELATIES > hiermee worden verbanden tussen de attributen van verschillende klassen gelegd. - DYNAMISCHE RELATIES > deze beschrijven de dynamische verbanden tussen klassen en geeft aan dat een instantie vd ene klasse gebruik mag maken vd diensten ve instantie vd andere klasse.

Pagina 5 van 36

vrg:

trefwoord


681


blz 24

attribuut -

2.2.3

omschrijving

is een benoemde eigenschap ve klasse die wordt gedeeld door alle objecten in die klasse en die door middel ve datawaarde wordt beschreven. Door inkapseling zijn deze atrributen niet voor de omgeving zichtbaar. De waarden vd attributen kunnen alleen met behulp vd bijbehorende operaties worden gelezen en veranderd. Bv de kleur ve auto, of die een spoiler heeft, welk soort velgen e.d. zijn allemaal properties/eigenschappen vd auto.

682


blz 26

bericht (message) -

2.2.4

objecten communiceren met elkaar door berichten te sturen. We onderscheiden: - BERICHT AFGEVEN > heeft als doe de toestand vh object te veranderen of opdrachten te laten uitvoeren. - BERICHT TERUGGEVEN > heeft als doel het resultaat ve opdracht mede te delen. Het doorgeven ve bericht is hetzelfde als aan het aanroepen ve methode om de toestand ve object te wijzigen of een bepaald gedrag te vertonen. Het is dynamisch. Hierdoor kunnen objecten ook onafhankelijk van elkaar functioneren.

683


blz 26

operaties (operation) -

2.2.5

is een functie of transformatie, die toegepast mag worden op instanties van klassen (objecten). In de verzameling operaties ve object komt het gedrag van dat object tot uiting. Objecten die tot dezelfde klasse behoren vertonen hetzelfde gedrag en hebben dezelfde operaties. ALLES WAT ER ACHTER ZIT

684


blz 26

methode (method) -

2.2.6

is de implementatie ve operatie op de gegevens ve object. Een bericht is een verzoek om een bepaalde methode uit te voeren. HETGEEN WAT EEN OBJECT KAN DOEN De STATUS (STATE) ve object wordt bepaald door de waarde v zijn gegevens en kan gewijzigd worden door berichten naar het object te verzenden. Op fig 2.8 van het boek zien we hetvolgende: theFile open: "myfile.dat" . . theFile close het eerste statement zendt het bericht "open het myfile.dat" als argument naar het object "theFile". Het tweede statement stuurt het beicht "close" zonder verdere argumenten naar "theFile". STATISCHE METHODEN > zijn methoden die aangeroepen kunnen worden zonder dat er een instantie v die klasse bestaat. Dit kan handig zijn als er veel functies zijn die in een apart gedeelte vh programma moeten worden ondergebracht en die aangeroepen moeten kunnen worden zonder dat er een object is. De wijze waarop hangt van de taal af.


Pagina 6 van 36

vrg:

trefwoord


685

Basisprincipes v OO modellering -

blz 28

insluiting / inkapseling / encapsulation -

2.3.1

omschrijving

dit houdt in dat een onderdeel vh systeem zijn interne details voorzich zelf houdt. De rest vh systeem ziet het als een black box, ze kunnen ermee communiceren maar weten niet en hoeven ook niet te weten, hoe dat precies gebeurd, "men kan niet in de black box kijken". Dit verhoogd de overzichtelijkheid en stabiliteit ve systeem, Is dus een modellerings- en implementatietechniek die de externe aspecten van een object onderscheidt vd interne implementatiedetails. LOCALITEITSPRINCIPE > de mogelijkheid om een systeem op een aantal kleinere onafhankelijk van elkaar, onderdelen te verdelen. Elk onderdeel staat op zichzelf en doen zijn werk onafhankelijk van de andere onderdelen. Zie figuur voor de publieke en private interface. Verschil vd de taal Modula2 en obejectgörienteerde insluiting is dat bij Modula2 de insluiting beperkt blijft tot de functies en bij een object zowel de operaties als de attributen ingesloten worden. Door insluiting wordt de interface gescheiden van de implementatie. De implementatie bepaald hoe er met een bericht wordt omgegaan.

197


Pagina 7 van 36

vrg:

686

trefwoord


omschrijving


blz 29

kenmerken v INTERFACE > van een klasse toont de door de klasse te leveren service. Het is een contact met de effectieve insluiting buitenwereld, dat precies definieert wat de buitenwereld met het object kan doen. De voor 2.3.1.1 de buitenwereld beschikbare gedragingen staan bekend als de PUBLIEKE INTERFACE. IMPLEMENTATIE > Naast de interface staat nog de implementatie in de definitie vd klasse. Dit beschrijft de interne details vh object en definieert hoe het object feitelijk een service levert. De interface is het gezicht naar buiten en verbergt hoe het gebeurt > IMPLEMENTATION HIDING. De implementatie zelf kan van alles zijn, bv schrijven naar DB, beeldscherm etc). 260

687


blz 30

implementatie hiding is de techniek dat ervoor zorgt dat informatie verborgen blijft binnen het object en dat bepaalde 2.3.1.1 / information hiding eigenschappen niet toegankelijk zijn voor de buitenwereld het object. / data hiding Het zorgt ervoor dat bepaalde eigenschappen van de klasse niet verkeerd gebruikt kunnen worden. Er zijn 3 niveau's van toegang en deze zijn belangrijk voor het ontwerp (PBP): 1. PUBLIEK (public) > geeft alle objecten toegang, iedereen mag. 2. BEVEILIGD (protected) > geeft toegang aan objecten vd eigen klasse en alle eventuele subklassen. 3. PRIVÉ (private) > geeft alleen toegang aan objecten vd eigen klasse.


Pagina 8 van 36

vrg:

trefwoord


688


blz 30

abstractie -

omschrijving

is het proces om ingewikkelde problemen te vereenvoudigen.

2.3.1.1

DATA ABSTRACTIE > is een bericht naar een object sturen ipv het uitvoeren ve specifieke functie op specifieke data. Zelfs voordat er objecten zijn gedefinieerd, kunnen programma's gebruik maken van abstracte specificatie. Je kunt bij ontwikkelen al aangeven wat je met een DB wil doen voordat die er is. Een gouden regel bij data abstratie is om naar algemeenheden te zoeken als er verschillende problemen moeten worden opgelost. BLACK-BOX effect: elk object heeft zijn eigen verantwoordelijkheid hoe het de verzoeken van buitenaf afhandelt. Een goede verdeling van verantwoordelijkheid is hierbij noodzakelijk. De object samenhang moet dan goed zijn en de eigenschappen vh object moeten op een nauwe, conceptuele manier met elkaar verbonden zijn. Kenmerken v effectieve insluiting zijn (IIAV): - gebruik v Interfaces - verbergen vd Implementaties - toepassen van Abstractie - verdelen vd Verantwoordelijkheid 261


Pagina 9 van 36

vrg:

trefwoord


689


blz 31

overerving / inheritance -

2.3.2

omschrijving

uitgaande ve bestaande klasse kan een nieuwe klasse ontworpen worden die dezelfde eigenschappen en gedragingen heeft als de oorspronkelijke klasse, maar zich onderscheidt door een of meerdere toevoegingen. Subklassen zijn uitgebreider dan hun superklasse. **IS EEN-RELATIE (is a) **> de nieuwe klasse wordt gebaseerd op de oude. De nieuwe klasse (=subklasse, childklasse of specialisatie) krijgt dan alles wat in de oude klasse (superklasse, parentklasse of generalisatie) zat en heeft nog de toegevoegde functionaliteit. Zij kunnen in de oude en nieuwe klasses gebruikt worden. Als bij onderhoud ve OO systeem blijkt dat de implementatie ve parent een fout bevat, moeten de childs opnieuw bekeken worden. Een subklasse kan op zijn beurt ook weer een superklasse zijn voor zijn subklassen etc, zie fig 2.14. een voorbeeld v overerving is fig.2.15 Overerving kan op een aantal terreinen voordelen bieden, projecten kunnen: 1. sneller worden afgerond. 2. worden daardoor tegen lagere kosten gerealiseerd. 3. met een hoger kwaliteitsniveau worden afgewerkt.

198

690


blz 33

operation overriding - Als een subklasse de geërfde operatie ve superklasse anders implementeert. De operatie in de subklasse geniet prioriteit ten aanzien vd operatie in de superklasse.

2.3.2

Het vervangen ve methode wordt ook wel eens het herdefiniëren ve methode genoemd.

691


blz 34

polymorfie -

2.3.3

is letterlijk veelvormigheid. Houdt in dat objecten op dezelfde boodschap verschillend kunnen reageren. Er wordt gebruik gemaakt van de kennis dat de klassen dezelfde methode(n) hebben. Verschillende implementaties gebruiken bij dezelfde boodschap maakt het mogelijk dat OOsystemen geschikt zijn voor allerlei uitzonderingen. Bij polymorfie erven subklassen bepaalde functionaliteiten, maar vullen deze op hun eigen wijze in (implementeren).

262

Hoofdstuk: zaterdag 25 juli 2015

3

Inleiding UML (Unified Modeling Language) Pagina 10 van 36

vrg:

trefwoord


692

Uniefied Modelling Language (UML) -

blz 49

verschil tussen UML en methode -

3

omschrijving

UML is de standaard modelleer taal voor objectgeoriënteerde modellen, maar is geen standaard. Uitgangspunt van UML is de case-use, dit is een beschrijving in natuurlijke taal van de manier waarop het systeem gebruikt moet gaan worden. UML is een bepaalde weergave vh systeemontwerp (WAT is het resultaat en niet hoe we daar komen). METHODE is een voorgeschreven manier van handelen om een bepaald resultaat te bereiken.

693


blz 50 3.1

deze taal biedt een aantal diagrammen die SAMEN het model vormt ve IS: 1. STATISCHE diagrammen (OK): 1a. KLASSEdiagram > toont statische structuur weergegeven als klasses en hun relaties (op typeniveau). Is een structuurdiagram en wordt vanaf de analyset/m implementatiefase gebruikt. 1b. OBJECT- of INSTANCEdiagram > toont statische structuur, weergegeven als objecten en hun relaties (op instanceniveau). Is een structuurdiagram en geven instanties weer. Bv Piet Janssen aan als de klasse Persoon is. Wordt gemaakt als het klassediagram zo ingewikkeld is, dat het met voorbeelden verduidelijkt moet worden. 2. REQUIREMENTS diagram = : 2a. USE CASEdiagram ***> toont hoe het IS door actoren gebruikt kan worden en is een gedragsmodel. Er wordt stap voor stap beschreven wat er moet gebeuren. Is een beschrijving in natuurlijke taal van een taak die het systeem moet kunnen uitvoeren. Worden vooral gebruikt in de eerste fase vh project. 3. DYNAMISCHE diagrammen (ITA): 3a. INTERACTIEdiagrammen > beschrijft een reeks gebeurtenissen, 2 soorten : 3a1. SEQUENCEdiagram (volgordediagram) > nadruk ligt op tijd en toont volgorde in tijd vd boodschappen die worden ontvangen en verstuurd tussen objecten. Is een gedragsmodel. 3a2. COLLABORATIE- of COMMUNICATIE- of SAMENWERKINGSdiagram> Nadruk ligt op hoe objecten samenwerken om een doel te bereiken en toont volgorde in tijd vd boodschappen die worden ontvangen en verstuurd tussen objecten. Is een gedragsmodel. 3b. TOESTANDSdiagram > toont toestanden waarin een object zich kan bevinden gedurende zijn levensloop. 3c. AVTIVITEITSdiagram > toont de activiteiten die voor een deel door het systeem worden uitgevoerd. 4. IMPLEMENTATIEdiagrammen *** (CD): 4a. COMPONENTdiagram > toont de verdeling vh gehele systeem in componenten en hun onderlinge relaties. 4b. DEPLOYMENTdiagram > toont hoe software componenten in een bepaalde systeemconfiguratie worden gebruikt. STRUCTUURMODEL > is een statische representatie van gegevens en functies in een systeem en geeft aan welke objecten er zijn en hoe deze aan elkaar gerelateerd zijn. De volgende diagrammen zijn structuurdiagrammen (DOCK-IS)***: - Deploymentdiagram > (valt onder Implementatie diagrammen) - Objectdiagram > (valt onder Statische diagrammen) - Componentdiagram > (valt onder Implementatie diagrammen) - Klassediagram > (valt onder Statische diagrammen) De rest zijn GEDRAGSMODELLEN > die richten zich op de dynamische aspecten vh systeem en laat zien wat de objecten doen en hoe ze zich gedragen. Waar actie is of zit, is een gedragsdiagram!


Pagina 11 van 36

vrg:

trefwoord


omschrijving

694


blz 50

toestandsdiagramme Geeft een overzicht van alle mogelijke toestanden waarin een object zich kan bevinden gedurende n of state chart zijn levensloop en wordt gebruikt in de ontwerpfase ve project. Binnen UML hoort een diagrams toestandsdiagram bij één klasse! De volgende begrippen worden gebruikt: - TOESTAND > is een stabiele situatie waarin een object zich enige tijd in bevindt en wordt weergegeven met een rechthoek met afgeronde hoeken. - TRANSITIE > is een toegangsovergang van de ene toestand naar een andere toestand of zelftransitie (is als een object van een toestand weer terugkeerd naar dezelfde toestand), wordt veroorzaakt door een event (= een gebeurtenis die geen tijd kost) en wordt weergegeven met een pijl met erboven de naam van het event dat de toegangsovergang in gang zet. - BEGINTOESTAND > is de toestand waarin het object zich bevindt aan het begin als het wordt gecreëerd, dit wordt weergegeven met een gevuld zwart rondje. - EINDTOESTAND > is de toestand waarin het object niet meer bestaat, dit wordt weergegeven met een gevuld zwart rondje met een cirkel er omheen. - ACTIVITEIT > een methode die moet worden uitgevoerd binnen de tijd dat het object zich in één toestand bevindt. Er is altijd maar één activiteit binnen één toestand mogelijk en wordt weergegeven binnen de toestand achter de label "do/".

3.1

200

695


blz 51

activiteitendiagramm laat zien welke activiteiten door een deel vh systeem moeten worden uitgevoerd en in welke en of volgorde dit gebeurd. Men kan ook parallelle activiteiten weergeven. Wordt ook gebruikt in de activitydiagram ontwerpfase vh project. Is een procesgerichte beschrijving ve deel vh systeem. Worden gebruikt om werkstromen of methoden te beschrijven en kunnen de activiteiten van meer dan één object beschrijven. Ze maken BPR (Business Process Redesign) mogelijk. Twee Begrippen: - ACTIVITEIT > een proces dat eventueel samengesteld kan zijn uit andere activiteiten. - ACTIE of AUTOMAIRE ACTIVITEIT > kan niet worden opgedeeld in meerdere activiteiten. - SAMENGESTELDE ACTIVITEIT > een activiteit die opgedeeld kan worden in subactiviteiten. Wordt weergegeven met een rechte boven en onderkant met ronde zijkanten. - CONTROL FLOW of FLOW of CONTROL > geeft de volgorde vd activiteiten aan, wordt weergegeven met een pijl vd ene naar de andere activiteit.

3.1

201


Pagina 12 van 36

vrg:

trefwoord


696


blz 51

componenten deploymentdiagram men -

3.1

omschrijving

Deze vormen samen de IMPLEMENTATIEdiagrammen binnen UML en danken hun groeiende belangstelling door de ontwikkeling v software voor plug en playcomponenten. COMPONENTENDIAGRAM > geeft een verdeling vh hele systeem in componenten en de relaties tussen die componenten. Het doel is het opsplitsen vh systeem in delen die onafhankelijk v elkaar functioneren. Dat splitsen kan in de analyse- en ontwerpfase gebeuren en de gebruikte werkwijze is helemaal vrij. DEPLOYMENTDIAGRAM > wordt alleen gebruikt bij de bouw ve gedistribueerd systeem. Het toont de configuratie vd nodes in het run-timesysteem en de componentinstanties en objecten die erop draaien. De nodes zijn met elkaar verbonden door communicatiepaden en worden weergegeven als een lijn tussen 2 nodes. Dit diagram laat zien welke componentinstanties op welke nodes draaien en hoe deze zich tot elkaar verhouden. Men kent de volgende begrippen: - COMPONENT > is een executeerbare eenheid, die deel uitmaakt ve applicatie met een of meer interfaces die binnen een componentensysteem kunnen worden bekend gemaakt en worden gebruikt. Wordt weergegeven als een rechthoek met 2 kleine rechthoekjes aan de linkerkant. - INTERFACE > is de verbinding tussen twee of meerdere componenten en wordt weergegeven als een lijn tussen die componenten. - NODE > is een fysiek object dat een computer resource representeert. Een node beschikt over het algemeen over een processor en geheugen, wordt weergegeven als een kubus en worden met elkaar verbonden door communicatiepaden en worden weergegeven als een lijn tussen 2 nodes

202


Pagina 13 van 36

vrg:

trefwoord


697


blz 52

diagrammen tijdens systeem ontwikkelfase -

3.1.1

omschrijving

UML is een hulpmiddel bij systeemontwikkeling, waarin diargrammen naar eigen inzicht kunnen worden gebruikt. Op basis van wensen v gebruikers worden use-cases opgesteld en de volgorde van werken op twee manieren, van ….naar: 1. UseCase diagram > Sequence- (of comm)> Toestands- > Activiteiten- > Klassediagram (USTAK) 2. UseCase diagram > 1e versie klasse- > ..e versie klasse (meerdere) > (laaste) Klassediagram Bij grote complexe systemen wordt tijdens de analysefase ook gewerkt met componenten deployementdiagrammen om het systeem op te delen in v elkaar onafhankelijke componenten. De diagrammen zijn niet statisch, ze ontwikkelen mee tijdens systeemontwikkeling. Voorvoegsels die het ontwikkelstadium vh diagram aangeven (DAI): 1. DOMEINmodel of -diagram (domain- of conceptual-) > alleen concepten uit de werkelijkheid weergeven. In dit model worden alleen de aspecten uit de werkelijkheid (het domein) waarin het model moet gaan werken gemodelleerd. Er worden hier geen automatiseringsaspecten gemodelleerd. 2. APPLICATIEmodel of -diagram (aplication-) > ook opnemen hoe gebruikers er mee moeten omgaan, is een uitbreiding vh domeinmodel. Is een soort uitbreiding vh domeinmodel, het is een nieuw ontwikkelstadium in hetzelfde model. Hier komen de keuzes naar voren hoe de gebruiker met dit specifieke systeem om moet gaan. 3. IMPLEMENTATIEmodel of -diagram (implementation-) > beschrijft exact hoe de implementatie ve systeem er uit zal gaan zien. Het omvat alle aspecten die in de vorige 2 fases naar voren zijn gekomen aangevuld met aspecten die te maken hebben met de wijze van implementeren waarvoor gekozen is. Het is zo opgezet dat het direct kan worden omgezet naar programmacode. Het komt echter zelden voor dat deze diagrammen allemaal gemaakt worden.

203

161


Pagina 14 van 36

vrg:

trefwoord


698


blz 54

structuurmodel en gedragsmodel -

3.1.2

omschrijving

UML heeft aspecten van een structuurmodel (structural model) en van een gedragsmodel (behavioral model). STRUCTUURMODEL > is een statische representatie van gegevens en functies in een systeem en geeft aan welke objecten er zijn en hoe deze aan elkaar gerelateerd zijn. De volgende diagrammen zijn structuurdiagrammen (DOCK-IS)***: - Deploymentdiagram > (valt onder Implementatie diagrammen) - Objectdiagram > (valt onder Statische diagrammen) - Componentdiagram > (valt onder Implementatie diagrammen) - Klassediagram > (valt onder Statische diagrammen) GEDRAGSMODEL > richt zich op de dynamische aspecten vh systeem en laat zien wat de objecten doen en hoe ze zich gedragen. De volgende diagrammen zijn gedragsdiagrammen (STACU-RD)***: - Sequencediagram > valt onder de interactie- en die weer onder Dynamische driagrammen. - Toestandsdiagram > valt onder de Dynamische driagrammen. - Activiteitsdiagrammen > valt onder de Dynamische driagrammen. - Collaboratiediagram > valt onder de interactie- en die weer onder Dynamische driagrammen. - Use Case diagram > behoort bij de Requirementsdiagrammen


Pagina 15 van 36

vrg:

trefwoord


699

klasse en objectdiagrammen -

blz 55

klasse en object -

3.2.1

omschrijving

Een object wordt gekenmerkt door zijn toestand (data) en zijn gedrag (operations en methoden). Elk object heeft zijn eigen unieke object-identiteit en verleent diensten (services) aan andere objecten. Binnen UML wordt een object weergegeven als een rechthoek met daarin onderstreept in kleine letter de naam vh object, gevolgd door een dubbele punt en de naam vd klasse (fig 3.27). KLASSE > is een verzameling objecten met overeenkomstige eigenschappen. De klassebeschrijving geeft de naam vd klasse en de beschrijving vd eigenschappen, deze eigenschappen worden onderverdeeld in één of meer attribuuttypen en methoden, zie fig 3.28. Wordt weergegeven als een rechthoek die in 3 delen wordt opgesplitst. Boven in de naam vd klasse en die begint met een hoofdletter, dan de attribuuttypen en de methoden. ATTRIBUUTTYPE > zijn kenmerken of hoedanigheid van een klasse. ATTRIBUUT > is een kenmerk ve object en worden in het middelste vak ve klasse weergegeven, achter de dubbele punt staat hier het datatype. Een daadwerkelijk kenmerk ve object. IDENTITEIT > objecten hebben altijd een eigen identiteit en kennen geen sleutelattributen. Het kan dus voorkomen dat 2 objecten dezelfde waarden voor al hun attributen hebben, maar het blijven dan toch 2 objecten. CLASSIFICEREN > is het identificeren van objecten met overeenkomstige eigenschappen en overeenkomstig gedrag. METHODE of OPERATIE (operation) > is de service of dienst die een object levert. Een object kan meerder methoden hebben. Een methode staat in het onderste deel vd rechthoek ve klasse, met eerst de methode naam en dan tussen haakjes de parameters. Het datatype vd returnwaarde wordt weergegeven na de dubbele punt. Alle methoden binnen een klasse bepalen het gedrag ve object. Een methode kan argumenten hebben en resultaten opleveren, dat resultaat noemt men de RETURNWAARDE. Objecten wisselen onderling informatie uit voor de operaties die diensten (services) genoemd worden. Objecten communiceren met elkaar door het sturen v onderlinge boodschappen (messages).

. 174


Pagina 16 van 36

vrg:

trefwoord


omschrijving

205

700


blz 62

stereotypen -

3.2.10

Klassen kunnen dmv stereotypen worden getypeerd. Ze zijn nodig omdat objecten naar andere objecten boodschappen sturen, om dat te kunnen doen hebben ze een link nodig, deze links kunnen worden weergegeven met de volgende stereotype: <> -> een link als gevolg ve associatie in het klassediagram <<parameter>> -> tijdens uitvoeren ve operatie kan een link als parameter worden meegegeven <> --------> object heeft een locale referentie <<self>> ----------> object kent altijd zichzelf <> -------> het ander object kan globaal bekend zijn De naam wordt weergegeven tussen zgn guillements en boven de naam vd klasse gezet. Bijv. het stereotype <> geeft aan dat de klasse is ontworpen voor gebruik in een implementatie. <> geeft aan dat de klasse een concept uit het domein definiëert.

217


Pagina 17 van 36

vrg:

701

trefwoord


omschrijving


blz 63

constraint en xor3.2.11 constraint -

Met CONSTRAINTs worden elementen in het klassediagram beperkt in hun instanties. Er worden grenzen aan de mogelijkheden gesteld. Constraints worden aangegeven dmv OBJECT CONSTRAINT LANGUAGE (=OCL). XOR-CONSTRAINT > het een of ander maar niet samen. XOR staat voor "exclusive or" en betekent dat er (zie fig 3.21) slechts één klasse geinstantieerd kan zijn. Een constraint kan ook tussen accolades in een commentaarblok worden gezet.

218

702


blz 64

commentaar -

3.2.12

met een note-box voegt men commentaar toe, deze wordt mbv een stippellijn aan het element vh diagram gekoppeld waar de notitie bij hoort.

219

703


blz 64

applicatieklassen en

Nadat het domeinmodel is opgesteld moet dit nog worden uitgebreid naar applicatiemodel en van

3.2.13 implementatieklassen daaruit naar het implementatiemodel.

APLLICATIEKLASSEN > hiermee worden de gebruikersinterfaces gedefiniëerd. Er zijn 2 type: 1. VIEWS (presentatie) > Is een klasse die objecten ve domeinklasse op een voorgedefinieerde wijze aan de gebruiker presenteert. wordt vanuit interactiediagrammen BOTTOM-UP ontworpen. (VB…BV) 2. CONTROLLERS > Is een klasse die de manier bestuurt waarop de gebruiker met het systeem werkt. Hij verwerkt de invoer vd gebruiker en stuurt de views en domeinobjecten aan. Wordt van TOP-DOWN ontworpen. Per taak wordt bepaald of er een controller moet komen om die taak uit te voeren. De use-cases zijn normaliter hier het uitgangspunt. IMPLEMENTATIEKLASSEN > voorbeelden zijn UTILITY-klassen, dit zijn klassen voor opslag v objecten en klassen die als intermediair fungeren tussen domeinobjecten en de fysieke opslag in een lagenstructuur.


Pagina 18 van 36

vrg:

trefwoord


704


blz 65

objectdiagram -

3.2.14

omschrijving

toont statische structuur, weergegeven als objecten en hun relaties (op instanceniveau). Een objectdiagram geeft een instantie vh klassediagram weer, een momentopname vd eigenlijke objecten in het systeem. Ze worden voornamelijk gebruikt om een ingewikkeld klassegiagram te verduidelijken met voorbeelden.

221

220


Pagina 19 van 36

vrg:

trefwoord


705


blz 56

zichtbaarheid -

3.2.2

omschrijving

INKAPSELING of INSLUITING of INFORMATION HIDING > de interne details ve object zijn verborgen voor andere objecten en is een kenmerkend onderdeel v OO. In bepaalde talen, zoals Delphi en C++, is het mogelijk om zichtbaarheid te sturen, daar zijn 3 vormen in en worden als volgt in een klassediagram aangegeven *** (PBP): + Publiek (Public) # Beschermd (Protected) - Privé (Private)

Publiek - PUBLIC + > deze zijn voor iedereen zichtbaar. Beveiligd - PROTECTED # > zijn alleen voor objecten uit de eigen klasse zelf zichtbaar en door hun subklassen. Privé - PRIVATE - > zijn alleen voor objecten uit de eigen klasse. 206

706


blz 56

generalisatie, specialisatie en overerving -

3.2.3

GENERALISATIE of SUPERKLASSE > dwz dat een nieuwe klasse wordt gespecificeerd als er klassen zijn die bepaalde attribuuttypen en methoden gemeen hebben. SPECIALISATIE of SUBKLASSEN > de klassen waaruit de superklasse voorkomt. Subklassen kunnen ook nog eigen aanvullende attribuuttypen en methoden hebben. In UML wordt dit weergeven met een gesloten ("open" = midden wit) pijlpunt die naar de superklasse gericht is. OVERERVING > iedere subklasse erft alle eigenschappen v zijn superklasse. Alle toevoegingen aan de superklasse wordt ook automatisch toegevoegd aan alle subklassen. Elke instantie ve subklasse is ook een instantie v zijn superklasse.

208


Pagina 20 van 36

vrg:

trefwoord


707


blz 58

associatie -

3.2.4

omschrijving

dit is de structurele relatie tussen twee klassen en wordt weergegeven door een doorgetrokken lijn tussen deze twee klassen. De pijl geeft de leesrichting aan. De namen worden langs de lijn geschreven en van links naar rechts of van boven naar beneden gelezen. **Er zijn meerdere accosiaties tussen twee klassen mogelijk. ** Een ASSOCIATIE is op type niveau en een LINK is op instanceniveau. Een LINK is de instantiatie ve ASSOCIATIE. Een OBJECT is de instantiatie ve KLASSE.

209

708


blz 58

rol (role) -

3.2.5

Een ROL is context afhankelijk en een klasse kan in verschillende associaties verschillende rollen spelen. Als er geen rolnaam staat is deze identiek aan de naam vd klasse. Wordt gebruikt als de naam vd klasse niet duidelijk genoeg aangeeft welke rol de klasse in de associatie speelt. Het is verstandig om zoveel mogelijk rollen te vermelden om misverstanden te voorkomen. Er wordt voor de rol vaak een zelfstandig naamwoord of een werkwoord gebruikt.

210


Pagina 21 van 36

vrg:

trefwoord


709


blz 59

multipliciteit (multiplicity) -

3.2.6

omschrijving

Bij het uiteinde ve associatie kan worden aangegeven hoeveel instanties een object mag hebben in die associatie. Geeft het aantal instanties vd geassocieerde klasse aan waarmee 1 instantie vd klassen een link kan hebben. In UML wordt dit aangegeven met een sterretje of de expliciete cijfers. Er zijn de volgende mogelijkheden: - nul of meer --> * - precies één --> 1 - nul of één --> 0..1 - één of meer --> 1..* Als we bv weten dat bv een persoon nooit minder dan 3 en nooit meer dan 5 bestellingen gaat plaatsen, kunnen we dit ook met 3..5 aangeven.

211

710


blz 60

associatieklasse -

3.2.7

Associatieklasse is een klasse die gekoppeld is aan een associatie. Associatieklasse is een volwaardige klasse en heeft alle kenmerken (operaties, methoden associaties en attributen) ve klasse binnen UML. Wordt in UML weergegeven door het klassesymbool dat door een stippellijn wordt gekoppeld met de bijbehorende associatie. Een instantie vd associatieklasse onstaat zodra er een link v die klasse onstaat en verdwijnt zodra die link verdwijnt.

213


Pagina 22 van 36

vrg:

trefwoord


711


blz 61

aggregatie en compositie -

3.2.8

omschrijving

AGGREGATIE > is een speciaal soort associatie die aangeeft dat een of meer klassen een onderdeel zijn ve andere klasse. De onderdelen kunnen afzonderlijk bestaan. Dit wordt in UML weergegeven als een witte ruit aan de kant van het object. COMPOSITIE > is het tegenovergestelde van aggregatie en is een onderdeel van en maakt altijd deel uit van een geheel. De levensduur van dit onderdeel kan nooit langer zijn als de levensduur van het geheel. Het deelobject kan ook niet zelfstandig leven als het geheel niet meer bestaat. Dit wordt in UML weergegeven als een zwarte ruit aan de kant van het object.

180

712


blz 62

abstracte en concrete klasse -

3.2.9

ABSTRACTE KLASSE > is een klasse waarvoor bepaald gedrag (operaties) niet concreet is ingevuld. Van zo'n klasse kunnen nog geen objecten aangemaakt worden, een object van die klasse moet noodzakelijkerwijs tot een subklasse behoren. !! Het is dus een superklasse en de reden om deze te creëren is om een gezamelijke interface te specificeren voor de subklassen. Als er klassehiërarchie is, is de hoogste klasse meestal de abstracte klasse. Het wordt weergegeven door de naam van de klasse cursief te schrijven en er optioneel {abstract} achter de naam te zetten. CONCRETE KLASSE > een klasse waarvan wel objecten kunnen bestaan.

216


Pagina 23 van 36

vrg:

713

trefwoord


omschrijving

Use-Case diagrammen -

blz 67

USE-CASEDIAGRAM > geeft een beschrijving vd functionaliteit ve informatiesysteem, hierbij wordt uitgegaan vd gebruiker vh informatiesysteem. Men beschrijft dus hoe de gebruiker met het systeem wil omgaan, het is minder formeel dan een klassediagram en kunnen parallel aan het klassediagram ontwikkeld worden.

3.3

ACTOR > is een entiteit (mens of ander systeem) buiten het systeem dat direct communiceert met het systeem. Het wordt meestal weergegeven door een poppetje met de naam vd actor eronder of als een klasse met de toevoeging <>. USE-CASE > is een beschrijving ve reeks interacties tussen een of meerdere actoren en het systeem. Uitgangspunt is het gezichtpunt vd gebruiker en beschrijft maar één (van de vele) manier over hoe het systeem gebruikt kan worden. Wordt beschreven in natuurlijke taal en wordt gebruikt als communicatiemiddel voor de gebruiker. Voor het maken hiervan maakt men vaak gebruik ve template waarin de volgende gegevens zijn opgenomen: - NAAM > vd use-case - SAMENVATTING > korte omschrijving vh doel vd use-case - ACTOREN > alle actoren die een rol spelen - AANNAMEN > toestand vh systeem bij start vd use-case, zijn voorwaarden waar aan voldaan moet worden voordat de use case gestart wordt. - BESCHRIJVING > complete beschrijving v interactie tussen systeem en actoren. Geeft de INTERACTIESTAPPEN tussen actoren en het systeem, het doel vd use case wordt zo bereikt, de beschrijving is dus een soort stappenplan. *** - ALTERNATIEVE of UITZONDERINGEN > Dit zijn variaties op de interactiestappen die vermeldt staan bij "Beschrijving", voorziene uitzonderingsgevallen die optreden bij use-case (alle). Zoveel mogelijk bij bedenken. - RESULTAAT > toestand vh systeem na afloop vd use-case. *** EX.vraag kan zijn: Waar worden de interactiestappen in de use-case omschreven > antwoord: in de Beschrijving. *** INTERACTIESTAPPEN uit de BESCHRIJVING > vormen weer de basis voor het sequence en het comminucatiediagram. In UML is er geen standaardnotatie v use-case, maar ze worden wel vaak volgens een bepaalde template vastgelegd. De opsteller vd use-case bepaald welke elementen uit de use caser hij wil beschrijven en op welke manier hij dit doet. Algeme richtlijn > hoe groter het risico is dat een usecase met zich meebrengt, hoe gedetaillieerder de use-case omschreven moet worden. 223

222 zaterdag 25 juli 2015

Pagina 24 van 36

vrg:

trefwoord 222


714


blz 67

funtionele en nietfunctionele systeemeisen -

3.3

omschrijving

FUNCTIONELE SYSTEEMEISEN > geven de te bouwen functionaliteit vh systeem weer. Op basis hiervan worden Use Cases opgesteld. NIET-FUNCTIONELE SYSTEEMEISEN> beschrijven de voorwaarden waar die functionaliteit aan moet voldoen. Denk hierbij aan de bestaande hard- en software omgeving waarbinnen het systeem moet draaien, aan standaard gebruikersinterfaces, hergebruik v bestaande componenten, gewenste responsetijden e.d.

715


blz 68

include en exclude relatie -

3.3

INCLUDE RELATIE > als de use-case direct betrokken zijn bij een andere use-case (bijv. invullen van velden en de controle met de DB hierop) EXCLUDE RELATIE > als use-case niet direct betrekking heeft op een andere use-case (bv de controle ve licentienummer)


Pagina 25 van 36

vrg:

trefwoord


716

USE-Case diagrammen -

blz 69

werkwijze bij opstellen ve usecasediagram -

3.3.1

omschrijving

De werkwijze bij het opstellen ve use-case-diagram is als volgt (SUAIASU): 1. bepaal de SYSTEEMGRENZEN en de ACTOREN 2. bepaal de USE-CASES 3. bepaal de AANNAMEN 4. bepaal de INTERACTIE 5. bepaal de ALTERNATIEVEN en UITZONDERINGEN 6. splits veel voorkomende SUB-CASES uit 7. maak het USE-CASE-DIAGRAM

AD 1. bepaal de SYSTEEMGRENZEN en de ACTOREN > vastellen wat de systeemgrenzen zijn, maw wat zijn de verantwoordelijkheden vh systeem, welke functies moet het globaal uitvoeren. Daarna kijken welke actoren en zijn en welke taken (rollen) zijn hebben. AD 2. bepaal de USE-CASES > voor elke actor moet bekeken worden welke taken hij met behulp vh systeem moet kunnen uitvoeren. Elke taak moet apart beschreven worden in een use-case. AD 3. bepaal de AANNAMEN > voor alle use-casen uit stap 2, bekijken onder welke voorwaarden deze kan worden uitgevoerd. AD 4. bepaal de INTERACTIE > Hier beschrijf je WAT er moet gebeuren. Dit doe je door de interactiestappen te bepalen en in normale taal beschrijven tussen actor en systeem. AD 5. bepaal de ALTERNATIEVEN en UITZONDERINGEN > hier worden alternatieven en uitzonderingen op de "normale" gang v zaken beschreven en welke effecten de alternatieven hebben op de use-case. AD 6. splits veel voorkomende SUB-CASES uit > Identieke onderdelen uit use-cases halen en in één aparte SUB-CASE zetten. Alle use-cases kunnen deze sub-case aanroepen voor de betreffende interactie =INCLUDE-RELATIE. Deze include relatie wordt in het diagram aangegeven als een gestippelde pijl die wijst vd use-case naar de sub-case. De relatie vd oorspronkelijk use-case naar de andere use-case heeft een EXCLUDE-RELATIE, heeft ook een gestippelde pijl met van naar. Bij de eerste use-case die uitgebreidt wordt, worden een of meer UITBREIDINGSPUNTEN gedefinieerd. AD 7. maak het USE-CASE-DIAGRAM > Als alle use-cases helemaal zijn uitgewerkt, worden ze verzameld in één use-case diagram en heeft men een duidelijk grafisch overzicht vd functionaliteit vh te ontwerpen syteem en bijbehorende actoren.

Alle use-cases worden in een rechthoek gezet (dit is het systeem) en dmv een doorgetrokken lijn met elkaar en/of met de actoren verbonden . Actoren staan buiten de rechthoek. UITBREIDINGSPUNTEN> is een naam die een punt in de beschrijving vd use-case markeert en wordt bij de extend-relatie genoteerd om aan te geven waar in de uitvoering vd use-case de tweede usecase ingevoegd wordt. Er kan ook een VOORWAARDE (condition) aan het uitvoeren vd tweede usecase worden verbonden.


Pagina 26 van 36

vrg:

trefwoord


omschrijving

Zoz 225

224


Pagina 27 van 36

vrg:

717

trefwoord


omschrijving

Interactiediagrammen (sequentie- en collaboratiediagrammen) -

blz 73

deze worden samen de INTERACTIEDIAGRAMMEN genoemd. SEQUENTIE- of VOLGORDEDIAGRAM > hier worden de exacte boodschappen tussen objecten aangegeven inclusief hun parameters en waarbij de nadruk op het TIJDsaspect vd interactie ligt. Veel vd boodschappen zullen later gemodelleerd worden als methoden bij de ontvangende objecten. COLLABORATIE- of COMMUNICATIEDIAGRAM > hier worden de exacte boodschappen tussen objecten aangegeven inclusief hun parameters en waarbij de nadruk ligt op de wisselwerking tussen de objecten.

3.4

188

183

718


blz 73

interactie -

3.4


INTERACTIE > Is een reeks gebeurtenissen die beschreven staan in de beschrijving van één use-case. Iedere input ve actor in een use case is de input voor een specifiek object binnen het systeem en de objecten kunnen weer boodschappen doorsturen naar andere objecten in datzelfde systeem. De vertaling van actor en systeem naar objecten, die input krijgen en boodschappen sturen, vindt hier plaats.

Pagina 28 van 36

vrg:

trefwoord


omschrijving

719


blz 73

klasse -

3.4

KLASSE > worden hier als een rechthoek getekend zonder attributen en operaties, actoren worden ook genoteerd als poppetje of ook als rechthooek met bovenin <> erbij

226

720


blz 73

levenslijn (life line) -

3.4

heeft in een sequence diagram dezelfde notatie als in een klassediagram en aan iedere rechthoek wordt een levenslijn gekoppeld. Deze levenslijn symboliseert dezelfde instantie als de rechthoek. In een Collaboratiediagrammen zijn geen levenslijnen. <> actors worden in beide gemodelleerd

227

721


blz 74

boodschap -

3.4

is een stimulus die vh ene naar het andere object wordt verstuurd. Een interactie is een serie boodschappen. Deze boodschap kan een methode oproepen of een signaal versturen. Wordt in het sequencydiagram weergegeven als een pijl tussen 2 levenslijnen met de naam vd boodschap erbij. De volgorde is van boven naar beneden. In een collaboratiediagram wordt dit weergegeven met een klein pijlpuntje met de naam vd boodschap erbij. De volgorde wordt aangegeven met een nummer.

228


Pagina 29 van 36

vrg:

trefwoord


omschrijving

722


blz 75

frames en verwijzingen -

3.4

Een interactie diagram kan in een frame geplaatst worden, Linksboven in het frame staat de naam vh interactiediagram, voorafgegaan door "SD" (v SequenceDiagram). Als een ander interactiediagram (a) naar dit interactiediagram (b) wil verwijzen, kan dit dmv deze naam. In interactiediagram (a) staat dan een frame met het woord "REF" van referentie en de naam van interactiediagram (b). Zo creëren we SUBDIAGRAMMEN. Deze verwijzingen zijn alleen mogelijk in een sequencediagram !!

230

723


blz 76

tijdconstraint -

3.4

is een beperking op het tijdsverloop tussen twee boodschappen in een sequencediagram, deze wordt in de kantlijn genoteerd, bij {t2-t1<5msec}.

231


Pagina 30 van 36

vrg:

trefwoord


omschrijving

724


blz 77

synchrone en asynchrone boodschap -

3.4

SYNCHRONE boodschap > is een boodschap waarbij de zender wacht totdat de ontvanger klaar is met de verwerking. Wordt weergegeven met een gesloten zwarte pijlpunt (wachten). ASYNCHRONE boodschap > is een boodschap die op moment van verzending niet hoeft te worden verwerkt. Wordt weergegeven met een open pijlpunt (niet wachten).

184

725


blz 78

conditionele boodschap -

3.4

kan alleen voorkomen onder bepaalde condities en worden weergegeven in beide diagrammen als een Boolean-expressie tussen rechte haken.

234


Pagina 31 van 36

vrg:

trefwoord


omschrijving

726


blz 79

iteratie van boodschappen -

3.4

is het herhaald versturen ve boodschap naar een object. Wordt in beide diagrammen weergegeven met een sterretje en dan tussen 2 rechte haken de iteratiewaarden, bv *[i:=1…10] leesData ITERATIE-EXPRESSIE > is datgene dat tussen de rechte haken staat. De "v" geeft hierbij aan dat er wordt geitereerd over de variabele "v", die loopt over de verzameling binnenkomende orders.

236

727


blz 80

actieve objecten -

3.4

In een Sequensediagram kan de tijdsduur ve operatie worden getoond door de levenslijn te laten zien als een witte balk. Sommige objecten zijn actief en zelf in staat om boodschappen te versturen.

238


Pagina 32 van 36

vrg:

trefwoord


omschrijving

728


blz 80

recursie of zelfaanroep -

3.4

als een object een eigen methode van zichzelf aanroept, dit wordt weergegeven door een pijl naar zichzelf. In een sequencediagram (zie afbeelding) > een pijl naar zichzelf die naar een nieuw stukje witte balk gaat die al op de eigen witte balk ligt. In een collaboratiediagram > een pijl die langs een lijn staat die naar het object zelf heen gaat, met aan het einde van de lijn het woord met haken <<self>> grote figuur zijn voorbeelden van complete diagrammen.

239

240


Pagina 33 van 36

vrg:

trefwoord


omschrijving

729

werkwijze om tot een klassediagram te komen -

blz 83

de stappen en stap 1 - STAP 1. CLASSIFICEREN STAP 2. SELECTEREN vd KLASSEN STAP 3. ASSOCIATIES TUSSEN KLASSEN BEPALEN STAP 4. OPERATIES IDENTIFICEREN, GENERALISEREN en CONSTRAINTS

3.5

STAP 1. CLASSIFICEREN > eerst moeten klassen geïdentificeerd worden, dit kan door eerst een lijst met alle gebruikte zelfstandige naamwoorden te maken die in usecases gebruikt zijn, daarna nog een brainstormsessie waar nog meer potentiële klasse uit kunnen komen, houden. Zie fig. 3.47. 242


Pagina 34 van 36

vrg:

trefwoord


730


blz 86

stap 2 en 3 -

3.5

omschrijving

STAP 2. SELECTEREN vd KLASSEN fig. 3.48 > selectie maken vd klassen die moeten worden opgenomen in het klassediagram. Dat kan door ze te toetsen aan de volgende criteria, DE KLASSE: 2a. is RELEVANT > moet vallen binnen beschrijving use-case. 2b. moet een ZELFSTANDIGE ROL spelen 2c. heeft een duidelijke VERANTWOORDELIJKHEID 2d. is NIET REDUNDANT 2e. heeft een duidelijk BETEKENIS 2f. is KWANTIFICEERBAAR 2g. is GEEN ATTRIBUUT OF OPERATIE 2h. is GEEN ROL Bij twijfelgevallen maakt men een opstelling van alle voors en tegens. In sommige gevallen is het afhankelijk van welk standpunt je het bekijkt of iets een klasse of attribuut is. Bv voor een spuiter is een kleur een klassen (ivm mengvoorschriften e.d.), dan is het een klasse, maar voor een auto hoeft dat niet zo te zijn, dat geeft de kleur bv alleen rood en niet meer, in dat laatste geval is dan een attribuut. Men kan ook nog kiezen voor het maken van een HULPKLASSE, dit is een niet belangrijke klasse. STAP 3. ASSOCIATIES TUSSEN KLASSEN BEPALEN fig. 3.49 > vaak worden deze per paar vergeleken, echter dan loop je de kans dat als er meerdere associaties tussen meer dan 2 klassen bestaan , deze moeilijk of helemaal niet gevonden worden. Hier gebruikt men weer de volgende criteria: 3a. De associatie is RELEVANT > moet vallen binnen beschrijving use-case. 3b. De associatie is STRUCTUREEL > eenmalige relaties zijn geen associatie. 3c. De associatie is NIET REDUNDANT > mag niet uit andere associaties kunnen worden afgeleid.

243

244


Pagina 35 van 36

vrg:

trefwoord


731


blz 87

stap 4 -

3.5

omschrijving

zie fig. 3.50 STAP 4. OPERATIES IDENTIFICEREN, GENERALISEREN en CONSTRAINTS > Tot slot moeten attributen en operaties worden geidentificeerd, er moeten eventuele generalisaties bepaald worden, beperkingen worden vastgelegd en moet het klassediagram worden opgesteld, daarbij moet men kijken of dit voorziet in de belangrijkste informatiebehoeften vh systeem.

245


Pagina 36 van 36

Hoofdstuk: 1 Objectoriëntatie en systeemontwikkeling

Recommend Documents