Inhoud leereenhed 1 Van nformatemodel naar nformatesysteem Introducte 15 Leerkern 16 1 Wat s model-drven development? 16 1.1 MDD voor gegevensntenseve toepassngen 16 1.2 Systeemgenerate 16 1.3 Informate, presentate en gedrag 17 1.4 Bedrjfsregels 18 1.5 MDD-modelarchtectuur 19 2 Het nformatemodel 20 2.1 Relevante wereld 20 2.2 Een nformatedagram 21 2.3 Klassen en objecten 22 2.4 Attrbuten 22 2.5 Identfcerende attrbuten en attrbuutcombnates 24 2.6 Optonele en verplchte attrbuten 24 2.7 Assocates en multplcteten 26 2.8 Een kp-eprobleem 27 2.9 Attrbuuttypen 28 2.10 Werkwjze 30 3 Bedrjfsregels en nterfacespecfcate 32 3.1 Een bedrjfsregel 32 3.2 Interfacespecfcate 32 3.3 Samenhang van de dre modelcomponenten 33 3.4 Stappenplan van een project 34 4 Genereren van database en applcate 34 4.1 Default nformatesysteem 35 4.2 Ouder en knd, master en detal 35 Terugkoppelng 37 Utwerkng van de opgaven 37 Bjlage 1: Cathedron nstallate en opstarten 38 Bjlage 2: Cathedron als applcateomgevng (practcum) 42 Bjlage 3: Cathedron als ontwkkelomgevng (practcum) 53 14
Leereenhed 1 Van nformatemodel naar nformatesysteem I N T R O D U C T I E Zolang er software s ontwkkeld, bestaan er softwaremodellen. Vaak hebben deze de vorm van plaatjes de fungeren als contract voor te schrjven programmacode. Als dt codeerwerk goed wordt gedaan, heeft de code preces de egenschappen de n het model zjn gespecfceerd, plus extra (technsche) egenschappen waarover het model helemaal geen utspraak doet, omdat ervan s geabstraheerd. Na het schrjven van de code bljft het model beschkbaar als documentate. Maar wanneer model en code los van elkaar kunnen worden gewjzgd, s er geen garante dat ze onderlng consstent bljven. Het gevolg s dat het model net meer als contract fungeert voor de geschreven code. Dt s een van de problemen waarvoor model-drven development (MDD) een oplossng bedt. MDD s een softwareontwkkeltechnologe waarbj een model strak gekoppeld bljft aan het te bouwen softwaresysteem. Vanut een MDD-model kan n elk stadum een werkend systeem worden gegenereerd. Zo kan het model snel en frequent worden gevaldeerd bj gebrukers en andere belanghebbenden. Deze cursus rcht zch op MDD voor gegevensntenseve toepassngen (nformatesystemen). Het voorbeeld n deze leereenhed s gebaseerd op een model voor het nformatesysteem van een cd-verzamelaar. In de bjlagen wordt dt model tot leven gewekt met behulp van de MDD-tool Cathedron n de vorm van een werkende toepassng. Herbj wordt ut hetzelfde model naar keuze een grafsche Wndows-nterface of een webnterface gegenereerd. In latere leereenheden wordt het model stap voor stap utgebred en omgebouwd, utendeljk tot het model voor een medawnkel, met naast cd s ook flms, boeken en games. LEERDOELEN Na het bestuderen van deze leereenhed wordt verwacht dat u een globaal dee hebt van een MDD-modelarchtectuur, n termen van nformatemodel, nterfacespecfcate en bedrjfsregels nzcht hebt n de volgende elementen van een nformatemodel: klassen, attrbuten, attrbuuttypen, assocates en multplcteten het verschl kent tussen een nformatemodel en een nformatedagram ervarng hebt opgedaan met het genereren van een nformatesysteem (database en applcate) ut een nformatemodel nzcht hebt n de relate tussen enerzjds elementen en structuur van een nformatemodel en anderzjds elementen en structuur van een herut gegenereerde (default) applcate. OU 15
Model-drven development De studelast bedraagt crca 7 uur (3 uur voor de theore en 4 uur voor de practca van de bjlagen). L E E R K E R N Model-drven development MDD 1 Wat s model-drven development? Model-drven development (MDD) s een technologe om software te ontwkkelen. Bjzonder aan MDD s dat het te ontwkkelen softwaresysteem automatsch wordt gegenereerd ut een model. 1.1 MDD VOOR GEGEVENSINTENSIEVE TOEPASSINGEN Database drven applcaton CRUD MDD s van orgne een ontwkkeltechnologe voor gegevensntenseve toepassngen. In de praktjk zjn dat vrjwel altjd nformatesystemen op bass van een relatonele database. De Engelse term database drven applcaton geeft goed weer waar het om gaat: de database staat centraal en de applcatefunctonaltet wordt voor een groot deel door de database geïmplceerd. Kernfunctes zjn de zogenaamde CRUD-operates: Create: aanmaken van neuw object (n relatonele termnologe: nsert ). Retreve: ophalen van gegevens (n relatonele termnologe: select ). Update: wjzgen van een object (relatoneel: een rj). Delete: verwjderen van een object (relatoneel: een rj). Ook zoekoperates behoren tot de (voorspelbare) kernfunctonaltet. Daarnaast kan zo n applcate ook net-standaardfunctonaltet bevatten zoals specfeke rapportages of het bewaken van allerle regels. Inmddels wordt MDD ook veelvuldg toegepast bj het ontwkkelen van objectgeorënteerde systemen (OO). In deze cursus rchten we ons echter geheel op gegevensntenseve systemen op bass van een relatonele database. Andere termen In plaats van MDD worden ook wel de termen MDE (model-drven engneerng) en MDSD (model-drven software development) gebrukt. Een oudere benamng s MAD: model-based applcaton development. 1.2 SYSTEEMGENERATIE Omdat bj MDD een systeem automatsch wordt gegenereerd ut een model, s een MDD-model meer dan documentate. Elke veranderng n het model ledt automatsch tot een veranderng n het systeem, zodang dat model en systeem n de pas bljven lopen (ze fguur 1.1). model generate applcate + database FIGUUR 1.1 Ut model wordt doelsysteem gegenereerd 16 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem 1.3 INFORMATIE, PRESENTATIE EN GEDRAG Aan nformatesystemen en ook aan modellen waarut de systemen worden gegenereerd, zjn dre aspecten te onderscheden: nformate, presentate en gedrag. Ze fguur 1.2. presentate gedrag nformate FIGUUR 1.2 Dre aspecten van een nformatesysteem Informate Presentate GUI GUI = graphc user nterface Informate Informate s de bass van elk nformatesysteem. Informate heeft verschllende gezchten. De endgebruker van een nformatesysteem zet nformate va schermformuleren of paperen rapportages. Als de endgebruker een ander computersysteem s, zet de gebruker de nformate msschen n de vorm van XML- of webservceberchten. Een databasebeheerder zet nformate als gegevens de zjn opgeslagen n een database en s net zozeer geïnteresseeerd n de gegevens zelf als wel n de databasestructuur en de snelhed van verwerkng. Een ontwkkelaar zet het nog weer anders: de s net n nformate geïnteresseerd, maar des te meer n de structuur ervan, los van databasekenmerken. Presentate Informate krjgt pas nut wanneer deze zchtbaar wordt gemaakt voor gebrukers. Hermee komen we aan het tweede aspect van systeem en model: presentate. We denken allereerst aan een grafsche gebrukersnterface (GUI), met menu s en schermformuleren. Fguur 1.3 toont een stukje van een klantformuler, onderdeel van zo n GUI. We merken herbj alvast op dat een GUI een acteve nterface s en daarom ook gedrag omvat. Naast GUI s zjn er ook andere maneren van presenteren. Zo zjn er spraaknterfaces voor blnden, paperen rapportages voor managers en XML- of webservce-nterfaces voor presentate van nformate aan andere computersystemen. We zullen ons n deze cursus voornameljk rchten op GUI s. Toch s de rumere context van belang, want de ontwkkelflosofe gaat ut van de gedachte dat specfcates zoveel mogeljk onafhankeljk van specfeke technologe moeten plaatsvnden. Veranderen van presentateplatform kan dan met relatef weng moete plaatsvnden. We noemen her n het bjzonder de overgang van een Wndows-GUI naar een webnterface. In het practcumopdrachten zullen we dt llustreren door vanut één specfcate twee soorten gebrukersnterfaces te genereren. OU 17
Model-drven development FIGUUR 1.3 GUI: presentate en gedrag Gedrag Gedrag Het derde aspect, gedrag, heeft betrekkng op nformate en presentate vanut een tjdsperspectef. Allereerst zjn dat veranderngen n de tjd bnnen de nformateverzamelng. Denk aan het toevoegen of verwjderen van een klant of het wjzgen van klantgegevens n een database. We kunnen dt zen als pure nformategebeurtenssen, geheel los van presentate. Maar de GUI kan daar een belangrjke rol bj spelen als de plek waar gedrag wordt geïnteerd. Bjvoorbeeld het klkken op een deleteknop (gebeurtens n de GUI) ledt tot het verwjderen van een klantrecord (gebeurtens n de nformateverzamelng). Of het klkken op een knop Kwartaaloverzcht ledt tot het afdrukken van een kwartaaloverzcht. Ook veranderngen n presentate vallen onder de noemer gedrag, bjvoorbeeld het rood worden van een rekenngveld zodra het saldo negatef wordt. 1.4 BEDRIJFSREGELS Het nformatemodel legt een nformatestructuur vast en de structuur bevat mplcet allerle regels. Bjvoorbeeld de regel dat een klantadres verplcht s. Wordt n het gegenereerde systeem gepoogd een klant n te voeren zonder adres, dan zal een foutmeldng volgen en wordt nvoer van de klant gewegerd. Dt s een vorm van gedrag. Dt gedrag zorgt ervoor dat de regel wordt gehandhaafd. Bedrjfsregel Busness rule Afledngsregel Een nformatesysteem moet n het algemeen nog een flnk aantal aanvullende regels bevatten, de net al n het nformatemodel vastlggen. Deze regels worden n eerste nstante veelal n natuurljke taal geformuleerd en later omgezet naar een formele specfcate, met het nformatemodel als context. We spreken van bedrjfsregels (busness rules). Er zjn verschllende typen bedrjfsregels, waaronder afledngsregels en constrants. Afledngsregels Een afledngsregel legt vast dat een waarde ut andere waarden moet worden afgeled en hoe dat moet gebeuren. Een voorbeeld s een btw- 18 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem bedrag, dat (automatsch) wordt berekend ut een brutoprjs en een btwpercentage, als het product daarvan. Constrant Workflow Handhavng van constrants Constrants Een constrant s een beperkngsregel, een regel de zegt dat ets net mag. Een voorbeeld, ut de bankwereld, s de regel dat men op een spaarrekenng net rood mag staan. Zo n constant s znloos, wanneer net ook wordt vastgelegd hoe de regel wordt gehandhaafd. Hertoe moet worden vastgelegd wat er moet gebeuren bj een overtredng of een dregende overtredng van de regel. In het algemeen kan het handhaven van constrants hard of zacht gebeuren. Een harde constrant wordt hard afgedwongen. Als net roodstaan een harde constrant s, moet elke transacte de tot roodstand zou leden, worden voorkomen. Het meest plausbele gedrag s n dt geval: wegeren van zo n transacte, onder afgfte van een meldng. Een zachte constrant wordt net door het systeem afgedwongen, maar kan wel leden tot een geautomatseerde waarschuwng en eventueel tot menseljke acte. Een voorbeeld vnden we bj een kwartaalkredet, met als constrant dat men eens n de dre maanden een postef saldo moet hebben. Dt kan natuurljk net door een nformatesysteem worden afgedwongen. Een klant de zch net aan de regel houdt, veroorzaakt wel een ongewenste toestand, waar wat aan moet gebeuren. Wát er moet gebeuren en n welke volgorde, geautomatseerd dan wel va menseljke acte, behoort tot het onderwerp workflow. We komen daar n leereenhed 9 op terug. De constrants n deze cursus zjn vrjwel allemaal harde constrants. De consequente s dat we een voorgestelde constrant op hardhed moeten toetsen. Een veelgemaakte fout s dat een constrant de egenljk een workflowregel s, hard wordt geïmplementeerd. Het systeem s dan te streng en de gebruker heeft daar last van. bedrjfsregels MDD-modelarchtectuur 1.5 MDD-MODELARCHITECTUUR De dre aspecten nformate, presentate en gedrag, vormen samen met bedrjfsregels de bass voor een MDD-modelarchtectuur: de opbouw van een MDD-model ut een nformatemodel, een nterfacespecfcate en bedrjfsregels (ze fguur 1.4). gedrag nterfacespecfcate gedrag nformatemodel FIGUUR 1.4 MDD-modelarchtectuur Informatemodel Het nformatemodel beschrjft de structuur van de nformate de n het systeem zal mogen (en kunnen) worden opgeslagen. Het bestaat onafhankeljk van de andere modelcomponenten en vormt de bass van het MDD-model. OU 19
Model-drven development Interfacespecfcate Bedrjfsregel De nterfacespecfcate beschrjft de structuur en het gedrag van de gebrukersnterface. Dt gebeurt op een zeker abstractenveau en s dealter onafhankeljk van het gebrukte platform. De nterfacespecfcate verwjst naar het nformatemodel en kan net op zchzelf bestaan. Bedrjfsregels zjn aanvullende regels de nog net zjn beschreven va het nformatemodel. Ze worden vaak n eerste nstante gespecfceerd n natuurljke taal (zoals Nederlands) en later vertaald naar een formele specfcate n een programmeertaal. Behalve de regel zelf moet ook het gedrag worden beschreven waarmee de regel wordt gehandhaafd. Bedrjfslogca Busness logc De programmacode voor het handhaven van bedrjfsregels en voor net-standaardgedrag van nterfacecomponenten wordt soms bedrjfslogca genoemd. Vaker nog wordt de Engelse term busness logc gebrukt. Logca n deze context moet worden onderscheden van logca als de fundamentele leer van redeneren en waarhed. Fguur 1.4 s het speelveld, n zjn meest grove vorm, van de hele cursus. Alle theore behelst verfjnngen of afgeleden ervan. In leereenhed 2 gaan we deper n op de MDD-modelarchtectuur. 2 Het nformatemodel In paragraaf 1.5 s een MDD-softwaremodel beschreven n termen van een nformatemodel, een nterfacespecfcate en bedrjfsregels. We zullen nu zen wat we ons her bj moeten voorstellen, te begnnen met het nformatemodel. Hertoe ntroduceren we eerst een relevante wereld voor onze voorbeelden. 2.1 RELEVANTE WERELD Muzekcollecte We zullen gebrukmaken van een voorbeeld: een model genaamd Muzekcollecte1. Dt wordt opgesteld ten behoeve van een eenvoudg nformatesysteem voor de persoonljke cd-verzamelng van een muzeklefhebber, ze fguur 1.5. We begnnen eenvoudg en maken het gaandeweg complexer. FIGUUR 1.5 Relevante wereld 20 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem Relevante wereld Usablty De muzekcollecte vormt de relevante wereld. Wanneer we deze term gebruken, bedoelen we net de fyseke wereld van cd s, hoesjes en dergeljke, maar een geabstraheerde verse ervan. De abstracte houdt n dat we alleen kjken naar nformate over de wereld, voor zover de relevant s vanut de optek van de muzeklefhebber. En dat zal vaak nog lastg bljken, want wat s relevant? De muzeklefhebber zal daar vooraf meestal maar een vaag dee van hebben, de nformatebehoefte zal pas tjdens het ontwkkelproces utkrstallseren. Er s nog ets n het spel: het compleet utmodelleren van de nformatebehoefte kan op gespannen voet komen te staan met de usablty (het gebruksgemak) van de applcate. Te ver utmodelleren van detals van de relevante wereld (bjvoorbeeld modelleren van alle nformate op de hoesjes) kan leden tot een onnodg ngewkkelde applcate. Zo kunnen we nu al zen aankomen dat de ontwkkelaar emand s de constant dngen tegen elkaar moet afwegen. Het model bestaat dan ook net. 2.2 EEN INFORMATIEDIAGRAM Informatedagram Het nformatemodel Muzekcollecte1 kunnen we net n één keer volledg weergeven. We kunnen wel de essente weergeven n een plaatje, een nformatedagram geheten. Later zullen we zen wat er nog ontbreekt om een nformatesysteem te kunnen genereren. Fguur 1.6 geeft een eenvoudg nformatedagram bj het nformatemodel van Muzekcollecte1. Het beschrjft een nformatestructuur de betrekkng heeft op albums en tracks. Het dagram s geschreven n de grafsche taal UML (unfed modelng language). nformatemodel Album nr ttel aantal tracks 1 * Track album volgnr ttel componst FIGUUR 1.6 Informatedagram bj nformatemodel Muzekcollecte1 We zullen nu de afzonderljke elementen van het nformatedagram van fguur 1.6 bespreken. 2.3 KLASSEN EN OBJECTEN Klasse Object Instante Het nformatedagram van fguur 1.6 geeft twee klassen weer, Album en Track. De klassen staan voor soorten van dngen : albums en tracks. Elke klasse kan worden gezen als een verzamelng van objecten. Deze objecten OU 21
Model-drven development staan voor dngen : concrete albums respecteveljk tracks. Een object heet een nstante ( voorkomen ) van een klasse. Klassen en concepten De correspondente tussen de klassen n een model en de concepten de we n de relevante wereld onderscheden en waar we n natuurljke taal over praten, s allermnst eendudg. Soms worden concepten als het ware ontdekt en van een klasse-equvalent voorzen. Maar het komt ook vaak voor dat concepten net tot een klasse leden of dat verschllende concepten opgaan n één klasse. Het s een kweste van ervarng en van tranng n het doordenken van de consequentes van een keuze. Andere termen In teksten over nformatemodellerng wordt vaak de term enttet gebrukt, voor wat wj UML-conform een klasse noemen. Men komt ook de term enttettype tegen; met enttet wordt dan een nstante (object) aangedud. 2.4 ATTRIBUTEN Attrbuut Attrbuten zjn egenschappen van de objecten de tot de klasse behoren. Klassen waarmee nformate wordt gemodelleerd, en dat zjn alle klassen n deze cursus, hebben vrjwel altjd één of meer attrbuten. De attrbuten van Album en Track De klasse Album heeft dre attrbuten: nr, een unek nummer (natuurljk getal) waarmee de muzeklefhebber zelf de albums va plakkertjes heeft geïdentfceerd ttel, voor de albumttel aantal tracks, voor het aantal tracks van een album. De klasse Track heeft ver attrbuten: album, met als waarde het albumobject waarop de track staat volgnr, ter onderschedng van de track bnnen het album ttel, voor de trackttel componst, voor componstnformate. Een volledge en ondubbelznnge attrbuutaandudng s van de vorm klassenaam.attrbuutnaam. Bjvoorbeeld: Album.ttel en Track.ttel. Namen mogen spates of bjzonders teken bevatten. Merk op dat de attrbuutnaam aantal tracks een spate bevat. Zowel klassenamen als attrbuutnamen mogen spates bevatten en daarnaast bjzondere tekens, zoals é. Assocateattrbuut Assocateattrbuut De onderstrepng van het attrbuut Track.album geeft aan dat dt een assocateattrbuut s, dat s een attrbuut waarvan de waarde een object s. De mogeljke waarden van Track.album zjn objecten van de klasse Album. Van elk object s de attrbuutwaarde het album waarop de track staat. Zodoende hoort bj elk Track-object één Album-object. Grafsch wordt dt nog eens benadrukt door het ljntje van Track naar Album. Ze fguur 1.7. 22 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem Album nr ttel aantal tracks album 1 * Track album volgnr ttel componst FIGUUR 1.7 Assocateattrbuut album In fguur 1.7 s de naam van het assocateattrbuut herhaald naast het corresponderende ljntje. In het algemeen zullen we zo n herhalng achterwege laten wanneer voor de menseljke lezer dudeljk s welke klasse bj het assocateattrbuut hoort. Later zullen we voorbeelden zen waarbj aan de naam van een assocateattrbuut net zo gemakkeljk s af te lezen welke klasse en welk ljntje erbj horen. Attrbuutvermeldng bj het ljntje kan dan verhelderend zjn. Bj nvoer van een model n een MDD-tool moet de klasse bj een assocateattrbuut altjd explcet worden opgegeven. Voor de menseljke lezer echter houden we de dagrammen lefst zo kaal en overzchteljk mogeljk. Cascadng delete Een Album-object kan net worden verwjderd, zolang er een Trackobject bestaat waarvan het assocateattrbuut album dat object als waarde heeft. Eerst moeten dan de corresponderende Track-objecten worden verwjderd. Echter, als de MDD-tool dt ondersteunt, kan een cascadng delete worden gespecfceerd voor het assocateattrbuut, ledend tot een cascadng delete voor de corresponderende verwjssleutel (foregn key) n de onderlggende relatonele database. In dat geval ledt een pogng tot verwjderng van een Album-object tot een pogng tot verwjderng van bjbehorende Track-objecten. Als dat lukt wordt het Album-object met tracks en al verwjderd. 2.5 IDENTIFICERENDE ATTRIBUTEN EN ATTRIBUUTCOMBINATIES Identfcerend attrbuut Identfcerende attrbuutcombnate Met de achter Album.nr wordt aangegeven dat dt nummer een unek nummer s, waardoor een album wordt geïdentfceerd en onderscheden van andere albums. Album.nr heet een dentfcerend attrbuut. Per album s het volgnummer van een track unek, zodat de combnate van de attrbuten Track.album en Track.volgnr dentfcerend s voor een track. Dt wordt aangegeven met twee s. De combnate Track.album, Track.volgnr heet een dentfcerende attrbuutcombnate. Ze fguur 1.8. OU 23
Model-drven development Album nr ttel aantal tracks 1 * Track album volgnr ttel componst FIGUUR 1.8 Identfcerend attrbuut en dentfcerende attrbuutcombnate Identfcateregel Verplchtewaarderegel Unctetsregel Het dentfcerend zjn van een attrbuut of attrbuutcombnate s n fete een regel, een dentfcateregel. Deze omvat twee deelregels: het attrbuut of de attrbuutcombnate moet een waarde hebben (verplchte-waarderegel) alle attrbuutwaarden of waardencombnates moeten verschllend zjn (unctetsregel). Per klasse zullen we altjd preces één dentfcateregel geven, de zoals we nog zullen zen medebepalend s voor de automatsche transformate van nformatemodel naar database. Het lgt voor de hand te veronderstellen dat een dentfcerend attrbuut of een dentfcerende attrbuutcombnate wordt getransformeerd naar een prmare sleutel van een databasetabel. In het algemeen s dt echter geen juste veronderstellng. Het kan bjvoorbeeld zjn dat voor de databases tabellen met aparte, kunstmatge prmare sleutels worden gegenereerd. Of dat dat alleen gebeurt voor klassen met een samengestelde dentfcateregel. 2.6 OPTIONELE EN VERPLICHTE ATTRIBUTEN Een verplcht attrbuut s een attrbuut waarvan de waarde door de gebruker verplcht moet worden ngevuld (verplchte-waarderegel). In een nformatedagram kunnen we dt explcet aangeven (het hoeft net!) met r (van requred ). In fguur 1.9 gebeurt dat voor de attrbuten Album.ttel en Track.ttel. Tegenover een verplcht attrbuut staat een optoneel attrbuut, daarvan mag de waarde net-ngevuld bljven (n databasetermen: null). Wanneer we n een nformatedagram optonaltet explcet wllen aangeven, doen we dat met o. In fguur 1.9 s Track.componst optoneel. Het dagram zegt dat er (behoudens andere regels) tracks zonder componstnformate mogen voorkomen. 24 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem Album nr ttel r aantal tracks 1 * Track album volgnr ttel r componst o FIGUUR 1.9 Optoneel, verplcht of buten beschouwng Let op: geen r of, dan geen concluse trekken dentfcerend attrbuut verplcht tenzj anders vermeld We vnden het belangrjk de dagrammen zo eenvoudg mogeljk te houden, daarom zullen we n de cursustekst r en alleen vermelden wanneer we erover hebben nagedacht en vermeldng toegevoegde communcatewaarde heeft. Staat er nets bj een attrbuut, dan mogen we geen concluse trekken over verplcht zjn of optonaltet. Het enge wat we mogen concluderen, s dat de opsteller van het dagram het net nodg vond herover ets op te nemen. Msschen wst de nog net of het een verplcht attrbuut moest worden. Of msschen wst de het wel, maar wlde de het n dt dagram net vermelden, om het eenvoudg te houden. In fguur 1.9 s Album.aantal tracks zo n attrbuut. Op het voorgaande maken we één utzonderng, maar ook dat s weer voor de eenvoud: een dentfcerend attrbuut () s verplcht, tenzj optonaltet explcet wordt aangegeven ( ). Dat laatste s alleen mogeljk voor een attrbuut dat deel utmaakt van een dentfcerende attrbuutcombnate. In fguur 1.9 zjn dus zowel het dentfcerende attrbuut van Album verplcht als de bede attrbuten van de dentfcerende attrbuutcombnate van Track. Later zullen we enkele voorbeelden tegenkomen van klassen met een dentfcate door twee attrbuten waarvan er één optoneel s. UML-profle Onze UML-notate s een profle met afwjkngen van standaard UML. Zo dudt onderstrepng n ons profle een assocateattrbuut aan. Standaard UML kent geen assocateattrbuten. Een tweede, belangrjke afwjkng van standaard UML s het gebruk van dentfcerende attrbuten. Identfcateregels en objectdentfcate n OO-systemen In objectgeorënteerde programmeeromgevngen kennen we het begrp objectdentfcate. Dt houdt n dat elk object, ongeacht zjn attrbuutwaarden een egen objectdenttet heeft. Twee verschllendeobjecten, met elk hun egen objectdenttet, kunnen dus dezelfde attrbuutwaarden hebben. Bj objectdentfcate door mddel van attrbuut-dentfcateregels s dat onmogeljk: verschllende objecten verschllen altjd n hun dentfcerende attrbuutwaarde(n). Dt heeft alles te maken met het fet dat we bj MDD modelleren voor gegevensntenseve, databasegeorënteerde systemen. OU 25
Model-drven development OPGAVE 1.1 Zullen n een nformatesysteem dat conform het model van fguur 1.9 wordt gebouwd, albumttels op een eendudge, gestandaardseerde maner worden opgeslagen? En de namen van componsten? 2.7 ASSOCIATIES EN MULTIPLICITEITEN Assocate Multplctet Cardnaltet Het assocateattrbuut Track.album legt een correspondente vast tussen de klasse Track en de klasse Album: bj een Track-object hoort één Album-object en bj een Album-object kunnen wllekeurg veel (nul of meer) Track-objecten horen. Deze correspondente draagt de naam assocate. In het nformatedagram wordt de assocate utgedrukt door het verbndngsljntje tussen de twee klassen. De aantalaandudngen preces één of nul of meer heten multplcteten of cardnalteten en worden grafsch aangegeven met de 1 respecteveljk * bj het verbndngsljntje (ze fguur 1.10). Album nr ttel r aantal tracks 1 * Track album volgnr ttel r componst bj één Track-object hoort preces één Album-object bj één Album-object horen wllekeurg veel Track-objecten FIGUUR 1.10 Multplcteten Let op de leesvolgorde: bj een Track-object hoort preces één (1) Albumobject. Lees de 1 aan de overkant van het ljntje. Evenzo: bj een Albumobject horen nul of meer, dat wl zeggen wllekeurg veel (*) Trackobjecten. Andere mogeljke multplcteten zjn: 0..1 (nul of één), 1..* (één of meer) of bjvoorbeeld 3..6 (mnmaal 3, maxmaal 6). Mnmum multplctet Maxmum multplctet De 1 s egenljk een verkorte notate voor 1..1 en * een verkorte notate voor 0..*. Vóór de punten staat steeds de mnmum multplctet en erachter de maxmum multplctet, waarbj * staat voor wllekeurg veel. Fguur 1.11 geeft een aantal voorbeelden van assocates tussen wllekeurge klassen A en B, met hun multplcteten. 26 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem a A b A c A d A e A 0..1 1 0..1 1 0..1 * B B * 1.. * B 1.. * B B 3..5 FIGUUR 1.11 Voorbeelden van 1-op-n-assocates 1-op-n-assocate n-op-1-assocate Ouderklasse Kndklasse Belangrjke tekenconvente In plaats van de * (de UML-notate) treft men vaak ook n aan. Alle assocates van de fguren a t/m e noemen we 1-op-n-assocates (vanut A gezen) of n-op-1-assocates (vanut B gezen). De klasse aan de 1-kant wordt ouderklasse of parent class genoemd en de klasse aan de n-kant kndklasse of chld class. We zen: bj een ouderobject horen n kndobjecten, bj een kndobject horen nul of één ouderobjecten. De ouderklasse tekenen we vrjwel altjd hoger dan de corresponderende kndklassen. Dt s een belangrjke tekenconvente. Later zullen we zen dat deze convente ons toestaat de multplcteten n veel gevallen weg te laten. Elke assocate tussen klassen A en B kunnen we opvatten als een verzamelng objectparen (a, b), waarbj a een A-object s en b een B- object. In leereenhed 3 ntroduceren we ook n-op-m-assocates. OPGAVE 1.2 Stel, er zjn 100 B-objecten. Geef voor elk van de fguren 1.12 a t/m e mnma en maxma voor: a het mogeljke aantal A-objecten b het mogeljke aantal A-objecten dat s geassoceerd met een B-object c het mogeljke aantal elementen (objectparen) van de assocate. 2.8 EEN KIP-EI-PROBLEEM Fguur 1.11d stelt ons voor een probleem: bj elk A-object hoort mnmaal één B-object en bj elk B-object hoort preces één A-object. Hoe krjgen we dat voor elkaar utgaande van een begnstuate zonder A- en B-objecten? Fguur 1.12a maakt de stuate wat concreter voor albums en tracks. De vraag s hoe we een eerste album met track geregstreerd krjgen, zonder een van de multplctetsregels te overtreden. Begnnen we met het album, dan overtreden we de regel 1 of meer tracks, begnnen we met de track dan overtreden we de regel 1 album. Het ljkt een kp-eprobleem: elke kp komt ut een e, maar om een e te krjgen heb je een kp nodg. Ze fguur 1.12b. OU 27
Model-drven development a Album nr ttel /aantal tracks 1 1..* Track album volgnr ttel componst b 1 1..* FIGUUR 1.12 Een kp-e-probleem Aangezen we een album en een track net tegeljkertjd kunnen nvoeren, s her alleen maar ut te komen wanneer één van de regels tjdeljk net hoeft te gelden. Dat s mogeljk, maar n de regel alleen wanneer we de 1- op-1..*-regel net va het nformatemodel afdwngen, maar op een andere maner, va de applcate. De detals zjn tool- en databaseafhankeljk. In blok 3 leert u her meer over. Wereld en relevante wereld Kp-e-problemen zjn allermnst trvaal, ook n omgevngen met geavanceerde transactemechansmen (zoals alle tegenwoordge relatonele databases). Dat s al reden genoeg om n het nformatemodel kp-e-multplcteten te vermjden. Maar los van een technsch probleem moeten we ons ook de vraag stellen of een 1-op-1..* assocate echt s wat we wllen. Net de wereld modelleren maar de nformatebehoefte Het s verledeljk om te poneren dat n werkeljkhed elk album mnstens één track heeft en dat dus de multplctet aan de n-kant 1..* moet zjn. Echter, bj nformatemodelleren gaat het er net om hoe de wereld n elkaar zt, maar wat de nformatebehoefte over de wereld s. Dat s preces wat met relevante wereld wordt utgedrukt. De vraag de we ons moeten stellen s dus net of elk album tracks heeft en ook net of tracknformate wenseljk s maar of we het onmogeljk wllen maken albumnformate op te slaan zonder tracknformate. We moeten ons realseren dat een verbod erg ver gaat en dat we daar msschen spjt van krjgen. (De tracknformate s wellcht net altjd drect beschkbaar of msschen wl de muzeklefhebber eerst alle albumnummers, -namen en -componsten kunnen nvoeren en pas later de tracks.) Als een verbod nderdaad te ver gaat, s ons probleem opgelost: we modelleren net 1-op-1..* maar 1-op-*. Desgewenst kunnen we n de applcate nog een waarschuwng nbouwen, wanneer een album wordt ngevoerd zonder tracks. Als we voor een verbod kezen, moeten we n het nformatemodel echter eveneens kezen voor 1-op-*. In dat geval s echter helder dat we dat alleen doen om een technsch probleem te omzelen, het kp-e - probleem. Dt betekent net dat we afzen van de beoogde multplctetsregel. Het betekent alleen dat de 1-op-1..*-regel net va het nformatemodel kan worden afgedwongen. 28 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem 2.9 ATTRIBUUTTYPEN Attrbuuttype Elk attrbuut n het model van Muzekcollecte1 heeft een verzamelng toegestane waarden. Deze verzamelng heet het attrbuuttype van het attrbuut. Zonder attrbuuttypen s het model onvolledg en s het onmogeljk er een database ut te genereren. Databasetabellen hebben mmers kolommen met een bepaald datatype (zoals Integer of Varchar) en de datatypen moeten afgeled kunnen worden ut het nformatemodel. In onze nformatedagrammen zullen we het attrbuuttype meestal weglaten, om rumte te besparen en omdat het attrbuuttype n eerste nstante mnder belangrjk s. Vooral bj grotere dagrammen bevordert dt het overzcht. Dt neemt net weg dat attrbuuttypen van groot belang zjn en zorgvuldg gekozen moeten worden. Voorbeeld: Muzekcollecte1 Als voorbeeld bekjken we opneuw het nformatedagram van Muzekcollecte1, maar nu utgebred met attrbuuttypen (ze fguur 1.13). Album nr ttel aantal tracks 1 album volgnr ttel componst * Albumnr Ttel Aantal Track Album Volgnr Ttel Componstnaam Attrbuuttype naam Albumnr Ttel Aantal Album Volgnr Componstnaam datatype Integer Varchar (100) Integer (klasse) Integer Varchar (50) FIGUUR 1.13 Informatedagram Muzekcollecte1, met attrbuuttypen De fguur toont elk attrbuut met de naam van het bjbehorende attrbuuttype. De namen van attrbuuttypen zullen we steeds met een hoofdletter schrjven. We zullen nu alle attrbuten met hun attrbuuttypen kort nalopen. Om te begnnen heeft attrbuut Album.nr een attrbuuttype met de naam Albumnr. In de attrbuuttypetabel s dt gedefneerd als een verzamelng van gehele getallen (datatype Integer). Eén attrbuuttype voor meerdere attrbuten Het attrbuut Album.ttel heeft een attrbuuttype genaamd Ttel, met als datatype tekst van varabele lengte (Varchar) tot een maxmum van 100. Dt attrbuuttype wordt ook gebrukt voor het attrbuut Track.ttel. Dat lgt wel voor de hand: een trackttel s net zo n soort waarde als een albumttel. Het attrbuut Album.aantal tracks heeft een attrbuuttype genaamd Aantal. Evenals Albumnr zjn de waarden hervan gehele getallen. Er s OU 29
Model-drven development voor een apart attrbuuttype gekozen, omdat een aantal tracks een ander soort getal s dan een albumnummer. Wanneer we attrbuut Track.album even overslaan, resten nog Track.volgnr en Track.componst. Track.volgnr krjgt een egen attrbuuttype Volgnr. Kenneljk wordt een tracknummer als een ander soort waarde gezen (met mogeljkerwjs andere egenschappen) dan een albumnummer. Ook Track.componst krjgt een egen attrbuuttype: Componstnaam. Het datatype hervan s weer Varchar, met een geschkte lengte. Attrbuuttype van een assocateattrbuut Het attrbuut Track.album heeft als assocateattrbuut een specaal attrbuuttype, nameljk de klasse Album. De waarden hervan zjn Album-objecten. Dt wordt ook utgedrukt door de onderstrepng, n combnate met het verbndngsljntje tussen Track en Album. In het algemeen geldt: het attrbuuttype van een assocateattrbuut s een klasse. Het attrbuuttype van andere attrbuten s een gewoon datatype. In het kader van een strakke, eenvoudge naamgevng geven we een assocateattrbuut vaak dezelfde naam als de klasse waarnaar wordt verwezen, maar met een klene letter. Regel voor attrbuuttypen Keuze van attrbuuttypen Voor semantsch verschllende attrbuten defnëren we verschllende attrbuuttypen. De reden hervoor s dat we dan ondersched kunnen maken tussen bjvoorbeeld een klantnummer en een ordernummer, door ze elk een egen attrbuuttype te geven. Semantsch hebben we het over totaal verschllende nummers maar een klantnummer kan de waarde 34 hebben en een ordernummer ook. Voor de applcate zjn deze verschllende attrbuuttypen ook gunstg: per attrbuuttype kunnen we een aantal egenschappen (propertes) nstellen zoals bjvoorbeeld de defaultwaarde en de dsplaylengte op een formuler. Als we klantnummer en ordernummer zouden baseren op één attrbuuttype Nummer, dan zou een nstellng voor dt attrbuuttype consequentes hebben voor bede attrbuten, wat n het algemeen onwenseljk s. Voor semantsch geljksoortge attrbuten kunnen we wel een gemeenschappeljk attrbuuttype gebruken, bjvoorbeeld een attrbuuttype Datum voor geboortedata en overljdensdata of een attrbuuttype Geldbedrag voor verkoopprjs, nkoopprjs of salars. OPGAVE 1.3 We zagen dat attrbuten (voor zover geen assocateattrbuten) een datatype hebben, bjvoorbeeld Varchar(100), va hun attrbuuttype. Wat s het voordeel hervan boven het rechtstreeks toekennen van zo n datatype aan elk attrbuut? 2.10 WERKWIJZE Het nformatemodel van fguur 1.13 bevat twee klassen met daartussen een 1-op-n-assocate. De klasse aan de 1-kant s de ouderklasse, de aan de n-kant s de kndklasse. Later zal bljken dat elk nformatemodel 30 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem geheel s opgebouwd ut dt soort bouwstenen. Wanneer we weten n welke volgorde de klassen, attrbuten en attrbuuttypen bj een 1-op-nassocate het beste kunnen worden ngevoerd, weten we dat ook voor grotere nformatemodellen. We kunnen dt probleem op twee maneren benaderen: vanut de structuur van het ontwerp en vanut de praktjk van het ontwerpen. Deze maneren leden tot lchteljk verschllende werkwjzen. Werkwjze vanut de structuur Stel we hebben een model met klassen, attrbuten en attrbuuttypen op paper geschetst, zoals het dagram van fguur 1.13. We zen: een attrbuut hoort tot een klasse en s van een of ander attrbuuttype. Vóór we een attrbuut nvoeren, moeten dus eerst zjn klasse en zjn attrbuuttype zjn gecreëerd. Specale aandacht verdenen de assocateattrbuten: hun attrbuuttype s zelf een klasse (Track.album heeft als type Album). In het algemeen zal daarom de ouderklasse moeten worden gecreëerd vóór de kndklasse. Van belang zjn ook de dentfcateregels. Zo n regel kan worden gecreëerd zodra het attrbuut of de attrbuutcombnate waarvoor de regel moet gelden s gecreëerd. Stappenplan create ouder- en kndklasse Dt ledt tot het volgende stappenplan voor de create van twee klassen met daartussen een 1-op-n-assocate. 1 Creëer de attrbuuttypen van de ouderklasse. 2 Creëer de ouderklasse met haar attrbuten en dentfcateregel. 3 Creëer de attrbuuttypen van de kndklasse (voor zover nog net gebeurd). 4 Creëer de kndklasse met haar attrbuten (waaronder het assocateattrbuut bj de ouder) en dentfcateregel. Omdat we consequent de ouderklasse boven de kndklasse tekenen, creëren we op deze maner de klassen van boven naar beneden. Deze werkwjze komt overeen met de maner waarop een endgebruker gegevens n de database nvoert: deze kan pas een track nvoeren als het bjbehorende album n de database zt. Werkwjze vanut de ontwerppraktjk We geven nog een tweede stappenplan dat ets meer recht doet aan de praktjk van het ontwerpen. De attrbuuttypen komen herbj pas zo laat mogeljk n beeld, nameljk bj nvoer van een getekende schets n de MDD-tool. 1 Schets en bedscusseer een klassenstructuur met de belangrjkste attrbuten (waaronder de assocateattrbuten). 2 Creëer voor elke ouder/kndcombnate eerst de ouder en dan het knd, als volgt: a Creëer de ouderklasse met haar attrbuten; kes voor elk attrbuut het attrbuuttype ut een keuzeljst of creëer een neuw attrbuuttype just n tme. b Creëer een dentfcateregel voor de ouderklasse. c Creëer analoog de kndklasse met haar attrbuten (waaronder het assocateattrbuut) en dentfcateregel. OU 31
Model-drven development Aangepast stappeplan ouder- en kndklasse Dt stappenplan maakt dus ondersched tussen een schetsfase (op paper of whteboard, waarbj attrbuuttypen nog geen rol spelen) en een createfase waarbj de schets wordt ngevoerd n de MDD-tool en de attrbuuttypen just n tme bekend moeten zjn. 3 Bedrjfsregels en nterfacespecfcate Het nformatemodel s het belangrjkste onderdeel van een MDD-model. Het s de bass ervan. We gaan nu kort n op de andere onderdelen: bedrjfsregels en de nterfacespecfcate. In blok 3 van deze cursus komen deze utgebred aan de orde. 3.1 EEN BEDRIJFSREGEL Bedrjfsregel Afledbaar attrbuut In fguur 1.14 s het nformatedagram utgebred met een bedrjfsregel n natuurljke taal (Nederlands). De bedrjfsregel s een afledngsregel, de zegt dat de waarde van aantal tracks afledbaar s en dat de berekende waarde s wat de naam belooft: het aantal Track-objecten van het betreffende album. Een afledbaar attrbuut wordt weergegeven door een slash (/). Bedrjfsregels vormen een aparte component van een MDD-model, naast het nformatemodel, zoals fguur 1.14 toont. bedrjfsregels nformatemodel Album nr ttel /aantal tracks 1 * Track album volgnr ttel componst Afledngsregel: aantal tracks = aantal Trackobjecten van 'dt' album FIGUUR 1.14 Informatedagram utgebred met afledngsregel Hoe het attrbuut afgeled moet worden, moeten we nader specfceren n de bedrjfsregelcomponent van het model. Het dagram van fguur 1.14 s hern dus nog onvolledg. Er zjn mnstens twee mogeljkheden: hertellng van het aantal Track-objecten na elke toevoegng van een neuw Track-object of na verwjderng van een Track-object begnnen met aantal tracks = 0 en met 1 ophogen na toevoegng van een Track-object en met 1 verlagen na verwjderng van een Track-object. Ongeacht de keuze moet natuurljk nog voorkomen worden dat een gebruker de waarde van aantal tracks zomaar kan wjzgen. Bedrjfsregels zullen we veelal op een nformele maner al meenemen bj het nformatemodel. Het bewaken ervan (de reacte van het systeem op een dregende overtredng) s echter een verhaal op zch. We zjn daar pas aan toe n de leereenheden 9 en 10. 32 OU
Leereenhed 1 Van nformatemodel naar nformatesysteem 3.2 INTERFACESPECIFICATIE Interfacespecfcate De nterfacespecfcate beschrjft de gebrukersnterface. Het specfceert de aanblk van het systeem voor de gebruker: menu s, formuleren, knoppen, enzovoort. Implcet wordt daarmee ook veel gedrag gespecfceerd, want het s een levende nterface de ut het model wordt gegenereerd (ze fguur 1.4). Default nterfacespecfcate Veel functonaltet van een nformatesysteem s voorspelbaar en lgt al mn of meer vast door het nformatemodel. Dat geldt bjvoorbeeld voor de CRUD-operates en zoekfunctes (ze paragraaf 1.1). Daarom beden MDD-tools de mogeljkhed om zonder explcete nterfacespecfcate een compleet nformatesysteem te genereren. Hervoor s slechts een nformatemodel met klassen, attrbuten en attrbuuttypen nodg. De MDD-tool genereert herut schermen op bass van een default nterfacespecfcate, ledend tot een standaard ( default ) nformatesysteem. Ze fguur 1.15. default nterfacespecfcate nformatemodel nr ttel aantal tracks Album Albumnr Ttel Aantal 1 generate album volgnr ttel componst * Track Album Volgnr Ttel Componstnaam FIGUUR 1.15 Default nformatesysteem gegenereerd op bass van nformatemodel en default nterfacespecfcate In paragraaf 4 gaan we her nader op n. De nterfacespecfcate s naar beleven aan te vullen met egen specfcates, ledend tot een nterface met alle gewenste formuleren, menu s, enzovoort, zoals we zullen zen n leereenhed 9. 3.3 SAMENHANG VAN DE DRIE MODELCOMPONENTEN Fguur 1.16 geeft de onderlnge samenhang aan van de dre modelcomponenten: nformatemodel, nterfacespecfcate en bedrjfsregels. Het nformatemodel bevat geen referentes naar nterfacespecfcate of bedrjfsregels; het bestaat geheel op zchzelf. Interfacespecfcate en bedrjfsregels staan net op zchzelf, ze bevatten referentes naar het nformatemodel. OU 33