Inhoud leereenhed 1 Van nformatemodel naar nformatesysteem Introducte 3 Leerkern 4 1 Wat s model-drven development? 4 1.1 MDD voor gegevensntenseve toepassngen 4 1.2 Systeemgenerate 4 1.3 Informate, presentate en gedrag 5 1.4 Interface en bedrjfsregels 6 1.5 MDD-modelarchtectuur 7 2 Het nformatemodel 8 2.1 Relevante wereld 8 2.2 Een nformatedagram 9 2.3 Klassen en objecten 10 2.4 Attrbuten 10 2.5 Identfcerende attrbuten en attrbuutcombnates 12 2.6 Optonele en verplchte attrbuten 12 2.7 Assocates en multplcteten 14 2.8 Een kp-eprobleem 15 2.9 Attrbuuttypen 16 2.10 Werkwjze 18 3 Bedrjfsregels en nterfacespecfcate 20 3.1 Een bedrjfsregel 20 3.2 Interfacespecfcate 20 3.3 Samenhang van de dre modelcomponenten 21 3.4 Workflow van een project 22 4 Genereren van database en applcate 22 4.1 Default nformatesysteem 23 4.2 Ouder en knd, master en detal 23 Terugkoppelng 25 Utwerkng van de opgaven 25 Bjlage 1: Cathedron: nstallate en opstarten 26 Bjlage 2: Practcum: Cathedron als applcateomgevng 30 Bjlage 3: Practcum: Cathedron als ontwkkelomgevng 41 1
2 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem 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. OUN 3
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 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: het toevoegen (c=create) van gegevensrecords, het ophalen van gegevens (r=retreve), het wjzgen (u=update) en verwjderen ervan (d=delete). 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). 4 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem model generate + applcate FIGUUR 1.1 Ut model wordt doelsysteem gegenereerd 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. Informate Informate Informate s de bass van elk nformatesysteem. In fguur 1.2 s het ook letterljk als bass getekend. Informate heeft verschllende gezchten. De endgebruker van een nformatesysteem zet nformate va schermformuleren of msschen rapportages. Als de endgebruker een ander computersysteem s, zet de gebruker de nformate msschen n de vorm van XML-berchten of webservceberchten. Een databasebeheerder zet nformate als gegevens de zjn opgeslagen n een database. De beheerder s net zozeer geïnteresseeerd n de gegevens zelf als wel n de structuur van de database en de snelhed van verwerkng. Een ontwkkelaar zet het nog weer anders: de s net zozeer n nformate geïnteresseerd als wel n de structuur ervan, los van databasekenmerken. database presentate gedrag nformate FIGUUR 1.2 Dre aspecten van een nformatesysteem Presentate GUI Presentate Informate krjgt pas nut wanneer deze zchtbaar wordt gemaakt voor gebrukers. Hermee komen we aan het tweede aspect van systeem en model: presentate. Herbj denken we allereerst aan een grafsche gebrukersnterface (Engels: graphc user nterface GUI), met menu s en schermformuleren. Fguur 1.3 toont een stukje van een klantformuler, onderdeel van zo n GUI. We merken herbj drect op dat een GUI een acteve nterface s en daarom ook gedrag omvat. Naast GUI s zjn er ook andere maneren van presenteren, we stpten dt al even aan. Zo zjn er spraaknterfaces voor blnden, paperen rapportages voor managers en XML- of webservce-nterfaces voor presentate van nformate aan andere computersystemen. OUN 5
FIGUUR 1.3 GUI: presentate en gedrag 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. 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). Ook veranderngen n presentate vallen onder de noemer gedrag, bjvoorbeeld het rood worden van een rekenngveld zodra het bedrag negatef wordt. 1.4 INTERFACE EN BEDRIJFSREGELS Interface Interface = gebrukersnterface Bj moderne MDD-tools worden vsuele componenten op een zo hoog mogeljk abstractenveau gespecfceerd en dat s zoveel mogeljk met gedrag en al. Dt dwngt ons op een neuwe maner naar presentate en gedrag te kjken. We stellen daarbj vast dat presentate op zchzelf voor het modelleren net zo nteressant s, omdat we acteve componenten modelleren, met gedrag en al. De presentatecomponenten met het eraan gekoppelde gedrag vormen samen de gebrukersnterface (of user nterface, kortweg nterface). Ze fguur 1.4 en vergeljk deze met fguur 1.2. 6 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem GUI = graphc user nterface We beperken ons voorlopg tot GUI s, al s het goed n het achterhoofd te houden dat de specfcates herbrukbaar moeten zjn voor bjvoorbeeld webnterfaces en dealter zelfs voor spraaknterfaces. presentate nterface gedrag gedrag nformate FIGUUR 1.4 Informate, usernterface en regels Bedrjfsregel Wat er nu nog overbljft aan te modelleren gedrag, zjn specfeke bedrjfsregels (busness rules, ze fguur 1.4). Dt zjn regels de net n het nformatemodel of n de nterface besloten lggen en worden geformuleerd als aanvullng daarop. Ze kunnen betrekkng hebben op de nformateverzamelng of op de nterface of op bede. Het bewaken van bedrjfsregels kan hard of zacht gebeuren. Een harde regel wordt kehard afgedwongen, utzonderngen zjn net mogeljk. Een voorbeeld, ut de bankwereld, s de regel dat men op een spaarrekenng net rood mag staan. Elke pogng om meer op te nemen dan het saldo, wordt dan verjdeld. Een zachte regel wordt net door het systeem afgedwongen, maar kan wel leden tot een geautomatseerde waarschuwng en eventueel menseljke acte. Een voorbeeld vnden we bj een kwartaalkredet: de regel de hervoor geldt, s dat men eens n de dre maanden een postef saldo moet hebben. Dt kan natuurljk noot 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 regels n deze cursus zjn vrjwel allemaal harde regels. De consequente s dat we een voorgestelde regel altjd op hardhed moeten toetsen. Een veel gemaakte fout s dat een regel de egenljk een workflowregel s, hard wordt geïmplementeerd. Het systeem s dan te streng en de gebruker heeft daar last van. 1.5 MDD-MODELARCHITECTUUR bedrjfsregels MDD-modelarchtectuur De dredelng nformate, nterface, bedrjfsregels s de bass voor een MDD-modelarchtectuur: de opbouw van een MDD-model ut een nformatemodel, een nterfacespecfcate en bedrjfsregels (ze fguur 1.5). OUN 7
nterface bedrjfsregels nformate FIGUUR 1.5 MDD-modelarchtectuur Informatemodel Interfacespecfcate Bedrjfsregel Bedrjfslogca Busness logc 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. De nterfacespecfcate beschrjft de gebrukersnterface, zowel het uterljk ervan als het gedrag. Het verwjst naar het nformatemodel en kan net op zchzelf bestaan. Bedrjfsregels zjn aanvullende regels de nog net zjn beschreven va het nformatemodel. Bjvoorbeeld: er mogen net meer artkelen worden besteld dan er n voorraad zjn. Bedrjfsregels worden n eerste nstante n natuurljke taal (zoals Nederlands) gespecfceerd. Vervolgens moeten ze vertaald worden naar een formele specfcate n een programmeertaal. De programmacode voor het bewaken van bedrjfsregels wordt veelal 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.5 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.6. We begnnen eenvoudg en maken het gaandeweg complexer. 8 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem FIGUUR 1.6 Relevante wereld 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 (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 echter 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.7 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). OUN 9
nformatemodel Album nr ttel aantal tracks 1 * Track album volgnr ttel componst FIGUUR 1.7 Informatedagram bj nformatemodel Muzekcollecte We zullen nu de afzonderljke elementen van het nformatedagram van fguur 1.7 bespreken. 2.3 KLASSEN EN OBJECTEN Klasse Object Instante Het nformatedagram van fguur 1.7 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 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: 10 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem 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.8. Album nr ttel aantal tracks album 1 * Track album volgnr ttel componst FIGUUR 1.8 Assocateattrbuut album In fguur 1.8 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 tabel bj het assocateattrbuut hoort. Later zullen we voorbeelden zen waarbj aan de naam van een assocateattrbuut net zo gemakkeljk s af te lezen welke tabel en welk ljntje erbj horen. Attrbuutvermeldng bj het ljntje kan dan verhelderend zjn. Bj nvoer van een model n een MDD-tool moet de tabel 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, nden 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 OUN 11
van bjbehorende Track-objecten. Als dat lukt wordt het Album-object met tracks en al verwjderd. 2.5 IDENTIFICERENDE ATTRIBUTEN EN ATTRIBUUTCOMBINATIES Identfcerend attrbuut 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.9. Album nr ttel aantal tracks 1 * Track album volgnr ttel componst FIGUUR 1.9 Identfcerend attrbuut en dentfcerende attrbuutcombnate Identfcateregel Identfcerende attrbuutcombnate 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.10 gebeurt dat voor de attrbuten Album.ttel en Track.ttel. 12 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem 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.10 s Track.componst optoneel. Het dagram zegt dat er (behoudens andere regels) tracks zonder componstnformate mogen voorkomen. Album nr ttel r aantal tracks 1 * Track album volgnr ttel r componst o FIGUUR 1.10 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 houden. In fguur 1.10 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.10 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 OUN 13
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. OPGAVE 1.1 Zullen n een nformatesysteem dat conform het model van fguur 1.10 wordt gebouwd, albumttels op een eendudge, gestandaardseerde maner worden opgeslagen? En de namen van componsten? 2.7 ASSOCIATIES EN MULTIPLICITEITEN Assocate Multplcteten 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.11). Album nr ttel r aantal tracks 1 bj één Track-object hoort preces één Album-object * Track album volgnr ttel r componst o bj één Album-object horen wllekeurg veel Track-objecten FIGUUR 1.11 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.12 geeft een aantal voorbeelden van assocates tussen wllekeurge klassen A en B, met hun multplcteten. 14 OUN
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.12 Voorbeelden van 1-op-n-assocates 1-op-n-assocates 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.12d 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.13a 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.13b. OUN 15
a Album nr ttel aantal tracks 1 1..* Track album volgnr ttel componst o b 1 1..* FIGUUR 1.13 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 track-nformate 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 track-nformate 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. 16 OUN
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.14). nr ttel aantal tracks album volgnr ttel componst o Album Albumnr Ttel Aantal 1 * Track Album Volgnr Ttel Componstnaam Attrbuuttype naam Albumnr Ttel Aantal Album Volgnr Componstnaam datatype Integer Varchar (100) Integer - Integer Varchar (50) FIGUUR 1.14 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 OUN 17
voor een apart attrbuuttype gekozen, omdat een aantal tracks een ander soort getal s als 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 attrbuuuttype 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, hetgeen 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.14 bevat twee klassen met daartussen een 1-op-n-assocate. De klasse aan de 1-kant s de ouderklasse, de aan 18 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem de n-kant s de kndklasse. Later zal bljken dat elk nformatemodel 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.14. 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. Aangepast stappenplan ouder- en kndklasse 1 Schets en bedscusseer een klassenstructuur met de belangrjkste attrbuten (waaronder de assocateattrbuten). 2 Creër 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. OUN 19
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.15 s het nformatedagram utgebred met een bedrjfsregel n natuurljke taal (Nederlands). De bedrjfsregel zegt dat de waarde van aantal tracks afledbaar s en geljk moet zjn aan 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.15 toont. bedrjfsregels nformatemodel Bedrjfsregel: aantaltracks s afledbaar. aantaltracks = aantal Track-objecten van 'dt' album Album nr ttel /aantal tracks 1 * Track album volgnr ttel componst o FIGUUR 1.15 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.15 s hern dus nog onvolledg. Er zjn tenmnste 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 ophogen na toevoegng van een Track-object en verlagen na verwjderng van een Track-object. Ongeacht de keuze moet natuurljk nog voorkomen worden dat een gebruker de waarde van aantal tracks rechtstreeks 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 zullen nog zen dat de smpele afledngsregel van deze paragraaf nog heel wat 20 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem programmeerwerk verest. We zjn daar pas aan toe n de leereenheden 9 en 10. 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.16. default nterfacespecfcate nformatemodel nr ttel aantal tracks Album Albumnr Ttel Aantal 1 generate album volgnr ttel componst * Track Album Volgnr Ttel Componstnaam FIGUUR 1.16 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.17 geeft de onderlnge samenhang aan van de dre modelcomponenten: nformatemodel, nterfacespecfcate en logca. 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. OUN 21
nterfacespecfcate bedrjfsregels nformatemodel = 'kent' FIGUUR 1.17 Samenhang: welk onderdeel kent welk ander onderdeel? Merk op dat nterfacespecfcate en bedrjfsregels onafhankeljk van elkaar zjn (detals zoals schermpjes voor foutmeldngen bj overtredng van een bedrjfsregel, buten beschouwng gelaten). 3.4 WORKFLOW VAN EEN PROJECT Fguur 1.17 mplceert dat het nformatemodel tenmnste voor een deel gereed moet zjn, voordat de corresponderende delen van de nterfacespecfcate en van de set bedrjfsregels kunnen worden opgesteld. In de workflow van een project, dat wl zeggen de door de ontwkkelaar te verrchten taken met hun volgorde, gaat het opstellen van het nformatemodel dus vooraf aan de andere taken. De workflow, geïdealseerd, zet er aldus ut: 1 schetsfase: schets van nformatemodel 2 bouwfase: bouw van nformatemodel aanmaken van een neuw project create van klassen en hun attrbuten en daarvan de attrbuuttypen generate van database en (default) applcate 3 toevoegen van bedrjfsregels: specfcate n natuurljke taal mplementate (busness logc) 4 utbouwen van de gebrukersnterface: specfcate gebrukers(groepen), menustructuren en bjbehorende formuleren. In de praktjk worden deze stappen ncrementeel (n stapjes, van klen naar groot) en teratef doorlopen. Stappenplan bj assocate Voor twee klassen waartussen een assocate bestaat kunnen we deze workflow detalleren met een van de stappenplannen van paragraaf 2.7. 4 Genereren van database en applcate In fguur 1.1 werd geschetst hoe ut een MDD-model een werkend systeem ( doelsysteem ) kan worden gegenereerd. Inmddels weten we dat een MDD-model dre componenten kan omvatten : een nformatemodel, een nterfacespecfcate en bedrjfsregels. Dt ledt tot een nadere nvullng van de fguur 1.1, zoals gegeven n fguur 1.18. 22 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem nformatemodel generate applcate + nterfacespecfcate bedrjfsregels database FIGUUR 1.18 Generate van doelsysteem ut dre-componentenmodel De nterface kan zowel een Wndows GUI als een webnterface zjn, naar keuze van de ontwkkelaar. 4.1 DEFAULT INFORMATIESYSTEEM Wanneer de bedrjfsregelcomponent leeg s en de nterfacespecfcate beperkt s tot de default nterfacespecfcate, reduceert fguur 1.18 tot fguur 1.16. De default applcate s een moo tussenstaton waarmee een endgebruker kan expermenteren en waarmee het nformatemodel kan worden gevaldeerd. 4.2 OUDER EN KIND, MASTER EN DETAIL Masterdetalformuler Welke MDD-tool ook wordt gebrukt, de gegenereerde applcates zullen altjd n essente op hetzelfde neerkomen. Zo zal bj een klasse altjd een formuler worden gegenereerd voor het onderhoud van de betreffende gegevens. En er zal een menu worden gegenereerd om formuleren te kunnen kezen. Soms kunnen met gernge toevoegngen aan het nformatemodel (de feteljk op het gebed van de nterfacespecfcate lggen) de mogeljkheden van de applcate aanzenljk worden verrumd en dat met een mnmum aan moete. Bj een 1-op-n-assocate zal het default formuler van de ouderklasse vrjwel altjd de vorm hebben van een master-detalformuler, met een subformuler voor de kndklasse. Het formuler zchtbaar n fguur 1.16 s zo n master-detalformuler, voor de klasse Album. In fguur 1.19 s het nog wat dudeljker weergegeven, ook n correspondente met het nformatedagram. Het formuler bestaat ut twee frames, één voor albums (het masterframe) en één voor de bjbehorende tracks (het detalframe). Het Track-frame s gesynchronseerd met het Album-frame. Daarom wordt het eerste Trackattrbuut (assocateattrbuut album) net getoond n het Track-frame. Het s mmers al zchtbaar n het Album-frame. In bjlage 3 van deze leereenhed (ze ook opdracht 1.2) wordt aangegeven hoe u de default-applcate bj Muzekcollecte1 realseert n Cathedron, de MDD-tool bj deze cursus. Daarbj worden de stappenplannen van paragraaf 2.7 gebrukt voor de nvoer van klassen, attrbuten en attrbuuttypen n de juste volgorde. OUN 23
Album nr ttel aantal tracks 1 1..* Track album volgnr ttel componst o FIGUUR 1.19 Master-detalformuler voor albums-met-tracks n default applcate MDD-tools Model-drven development s een technologe om snel en flexbel software te ontwkkelen. Veel hangt af van de kracht van de gebrukte MDD-tool. Maar wat s kracht? We zouden kunnen zeggen: hoe mnder de ontwkkelaar hoeft te doen om een bepaald resultaat te bereken, des te krachtger s de tool. Een krachtge MDD-tool werkt met modellen van een hoog abstractenveau, met zo mn mogeljk technologespecfeke detals. Alles wat specfek s voor een technologe (platform of archtectuur), wordt dealter door de tool gegenereerd. Dt deaal wordt echter door geen enkele MDD-tool berekt. Daarvoor s de complextet van databases (Oracle, SQL Server, MySQL, Frebrd, ), applcates (Java, C+, C++, ) en de wsselwerkng daartussen te groot. Cathedron Ze www. cathedron.com. In deze cursus werken we met de MDD-tool Cathedron. Deze s ontwkkeld vanut de praktjk én de behoeften van het onderwjs, n samenwerkng met de Open Unverstet. De tool leent zch goed voor snel prototypen en s daarmee een utstekende tool voor valdate van nformatemodellen en ondersteunng van het leren modelleren. OPDRACHT 1.4 Installeer Cathedron, start op en log n. Verdep u n de menustructuur voor de ontwkkelaar en de (default) menustructuur voor de endgebruker. Neem hertoe bjlage 1 bj deze leereenhed door. OPDRACHT 1.5 Neem bjlage 2 door om de default applcate Muzekcollecte1 te verkennen n de rol van endgebruker. OPDRACHT 1.6 Neem bjlage 2 door om het project Muzekcollecte1 te verkennen n de rol van ontwkkelaar. U zult herbj vanaf nul begnnen, het nformatemodel van Muzekcollecte1 nvoeren, on the fly nog enkele nterfacespecfcates meegeven en ut het geheel een database met default applcate genereren. 24 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem T E R U G K O P P E L I N G Utwerkng van de opgaven 1.1 Albumttels worden op één plaats opgeslagen, bj het uneke albumnummer. Ze lggen op de maner eendudg vast. Voor de componstnamen lgt dt anders. Deze wjzen net naar een klasse; ze zjn slechts een tekstwaarde bj een track. Zodra een componst vaker voorkomt, wordt deze meervoudg opgeslagen, zonder garante op eendudghed. Van standaardsate s daardoor geen sprake. 1.2 a Bj de fguren 1.12b en d s er mnmaal één A-object. In dt uterste geval zjn alle 100 B-objecten met dt ene A-object geassoceerd. Bj de fguren a, c en e kan het mnmum ook 0 zjn. In de gevallen a en b s er geen maxmum voor het aantal A-objecten. In de gevallen c en d zjn er maxmaal 100 A-objecten. In geval e s het maxmum 33. b Mnma-maxma: 0-100, 1-100, 0-100, 1-100, 0-33. c Mnma-maxma: 0-100, 100, 0-100, 100, 0-100. 1.3 De attrbuten Album.ttel en Track.ttel llustreren het nut. Bede hebben het attrbuuttype Ttel met datatype Varchar(100). De ontwkkelaar heeft hermee utgedrukt dat het om dezelfde soort ttels gaat. Bljkt op zeker moment dat Varchar(100) een te klen datatype s, dan wordt dt op één plaats n het model veranderd, waarna langere ttels voor zowel tracks als albums beschkbaar zjn. Inden de ontwkkelaar tot de concluse komt dat albumttels en trackttels verschllend behandeld moeten worden, dan moet worden gekozen voor verschllende attrbuuttypen. OUN 25
Bjlage 1 Cathedron: nstallate en opstarten Installate Cathedron en MDD-voorbeelden Va de cursusste kunt u twee nstallateprogramma s downloaden en utvoeren: nstallateprogramma van Cathedron nstallateprogramma van de MDD-voorbeelden van de cursus. Voor bede neemt een wzard u bj de hand. Herbj zjn enkele punten om even bj stl te staan. Lcenteovereenkomst Locate Cathedron en projecten Projectmap Installate Cathedron Allereerst de lcenteovereenkomsten. Lees deze goed door. Het belangrjkste punt s dat het gebruk van Cathedron voor onderwjsdoelenden vrj s, maar voor commercële doelenden net. Een volgend punt betreft de locate waar Cathedron geïnstalleerd zal worden. Hervoor kunt u de defaultkeuze volgen, de Program Fles-map. Verder s er een vraag naar de map waar de projecten komen te staan. De cursus gaat ut van nstallate n C:\Cathedron, omdat dt een eenvoudg en kort pad s. Wlt u dt pad gebruken of een ander eenvoudg pad nstellen, kes dan voor de opte Specfy the folder (ze fguur 1) en geef de gewenste locate op. Kes u voor één van de standaardlocates, zorg er dan voor dat u deze locate later terug kunt vnden n de Verkenner. FIGUUR 1 Locate voor database fles (projecten). 26 OUN
Leereenhed 1 Van nformatemodel naar nformatesysteem Selecte componenten Het verde punt om even bj stl te staan, s de selecte van componenten, ze fguur 2. Kes voor Full nstall, nden u Cathedron voor het eerst nstalleert. Wanneer u echter een neuwere verse van Cathedron over een oudere heen wlt nstalleren, s het zaak te kezen voor Update only Cathedron executables. In dat geval bljven al uw Cathedron-projecten ongewjzgd. FIGUUR 2 Te nstalleren onderdelen Installate met of zonder embedded database Het laatste punt betreft het onderlggende databaseprogramma, Frebrd. Mocht u al ervarng hebben met Frebrd, dan kunt u er ook voor kezen om Frebrd apart te nstalleren. In dat geval kunt u tjdens de nstallate van Cathedron kezen voor Install wthout embedded Frebrd. Zorg er n dat geval wel voor dat u n Frebrd een gebruker DEV met wachtwoord dev aanmaakt. Installate MDD-voorbeelden Wanneer u de MDD-voorbeelden nstalleert, worden deze geïnstalleerd n de map C:\Cathedron\Projects\Examples, nden u ten mnste bj nstallate van Cathedron hebt gekozen voor C:\Cathedron als projectmap. Opstart en logn Interactve query utlty Cathedron starten we op door mddel van de Cathedron (project)manager va Start Programma s Cathedron. Voor de voorbeelden ut de cursus gebrukt u de opte met voorbeelden, voor egen projecten de eerste opte, ze fguur 3. De menuopte IQU n deze fguur staat voor Interactve query utlty, de SQL-edtor van Cathedron. FIGUUR 3 Cathedron opstartoptes OUN 27