HS.1 HS.1 1000 blz 5 1 Informatieanalyse en modellering Systeemontwikkeling - Informatieanalyse en Modelleren - Hoofdstuk: 1 Samenhang informatieanalyse, systeem modellen en SQL INFORMATIEANALYSE > is de activiteit vh verkrijgen en analyseren vd informatie die nodig is om het informatiesysteem te kunnen realiseren. MODELLEREN > is de activiteit waarbij in de analyse verkregen informatie wordt vastgelegd in modellen (bouwtekening). 1001 blz 6 1.1 Projectmanagement en systeemontwikkeling - SYSTEEMONTWIKKELAAR > zijn activiteiten zijn specialistisch van aard en leveren een direct bijdrage aan het te realiseren resultaat, de aan eenschakeling van deze activiteiten leiden tot het IS. PROJECTLEIDER > zijn activiteiten richten zich op de besturing met als doel het zo efficiënt en effectief mogelijk behalen van het resultaat. Het zijn geen inhoudelijke activiteiten, maar activiteiten die zich richten op de onderlinge afstemming vd uitvoerende activiteiten, de beheersing vd planning en beschikbare financiële middelen. 323 PRODUCT v projectmanegement > is het proces v systeemontwikkeling. PRODUCT v systeemontwikkeling > is het informatiesysteem maandag 19 oktober 2015 Pagina 1 van 61
1002 blz 7 1.1.1a Projectmanagement - 324 Een organisatie heeft primair tot doel de producten of diensten voort te brengen waarmee zij haar bestaansrecht kan geranderen, dit hoort tot de reguliere activiteiten vd organisatie en wordt uitgevoerd door de lijn. PROJECTORGANISATIE > Zijn ALLE mensen binnen het project die gericht samenwerken. Is de aangewezen vorm om verbeteringen, veranderingen en vernieuwingen te realiseren naast de reguliere activiteiten. Is verantwoordelijk voor de realisatie en invoering vd gewenste resultaten. Hierbij is van belang dat (petec): - PROCEDURES moeten goed ingericht zijn - de organistructuur EFFICIËNT is - de verdeling van TAKEN, VERANTWOORDELIJKHEDEN en BEVOEGDHEDEN zijn helder - de organistructuur EFFECTIEF is - COMMUNICATIESTRUCTUUR moet goed ingericht zijn SELECTIEMECHANISME > hanteren om te bepalen welke ideeën en wensen worden omgezet in een project. BUSINESS CASE > is een rapport waarin de noodzaak, kosten en baten worden beschreven, op basis daarvan kan worden bepaald of het idee geprioriteerd wordt om als project te worden uitgevoerd. 325 maandag 19 oktober 2015 Pagina 2 van 61
1003 blz 8 1.1.1b Projectmanagement - Project - Een PROJECT is een tijdelijk, multidisciplinair samenwerkingsverband gericht op het realiseren ve afgesproken resultaat. Meestal wil men meer functionaliteit implementeren en een hogere kwaliteit leveren, echter dat kost geld. Achteraf duurder uit zijn is nooit goed. Er is sprake ve project als het resultaat: - van TIJDELIJKe aard is - EENMALIG karakter heeft - AFDELINGSOVERSCHRIJDEND is - OMVANGRIJK en COMPLEX is DOEL en KENMERKEN ve project > het realiseren vh afgesproken resultaat op (fkbt) - FUNCTIONALITEIT - KWALITEIT - binnen beschikbaar BUDGET - binnen beschikbaar TIJDSBESTEK PROJECTMANAGER > is verantwoordelijk voor de besturing vh informatiesysteemontwikkelingtraject, hij stuurt op het te bereiken resultaat en beheerst de bovenstaande aspecten (FKBT). 326 maandag 19 oktober 2015 Pagina 3 van 61
1004 Projectmanagement - ** blz 9 1.1.1c projectmanagement methode - PRINCE2-327 belangrijkste kenmerken: - toetsen vd tussenresultaten (mijlpalen) - toepassen van fasering PRINCE2 > is een algemene projectmanagementmethode en is bruikbaar voor uitvoering van allerlei soorten projecten. Is algemeen toepasbaar en hanteerbaar op elke ontwikkelmethode. Toepassen ve methode of aanpak dient de volgende doelen: - CHECKLIST > niet alle stappen hoeven altijd doorlopen te worden - FASERING > hierdoor complexiteitsreductie en tijd positionering - STANDAARDISATIE - BESTUURBAARHEID FASEN zijn: 1. Vooronderzoek 2. Definitiestudie 3. opstellen Functioneel ontwerp 4. opstellen Technische ontwerp 5. Bouw/realisatie 6. Uitvoeren Acceptatietest 7. Invoering informatiesysteem 8. Gebruik en beheer (buiten het traject) blz 12: Belang v projectmangementaanpak en de systeemontwikkelaanpak optimaal op elkaar afstemmen > daardoor kan optimaal resultaat worden bereikt. SYSTEEMONTWIKKELAANPAK > Een systeemontwikkelaanpak is het productieproces waarin ICT-deskundigen en materiedeskundigen (de bedrijfsvoering) gericht samenwerken met als doel: de realisatie van een informatiesysteem. 1005 blz 11 1.1.1d Projectmanagement - projectmanagementmethode - PRINCE2-1. vooronderzoek - is een globaal organisatieonderzoek en heeft als doel de huidige situatie in kaart te brengen, werkwijze te achterhalen en knelpunten te inventariseren. Op basis hiervan wordt een advies uitgebracht met mogelijke oplossingsrichtingen en samenhangende kosten. maandag 19 oktober 2015 Pagina 4 van 61
1006 Projectmanagement - projectmanagementmethode - PRINCE2 - *** blz 11 1.1.1e 2. definitiestudie - Richt zich op het bepalen vd verschillende oplossingsrichtingen uit het vooronderzoek, activiteiten zijn: - opstellen plan van aanpak / alternatieven bekijken *** - analyse huidige informatievoorziening - bedrijfsprocessen, gegevens, problemen en gewenste veranderingen - evaluatie veranderingsbehoeften en specificatie systeemeisen - systeemconcept bepalen - opstellen eindrapportage vd definitiestudie, waaronder: - beschrijving systeemoplossing - 1e opzet raamwerk acceptatietest - kosten/baten overzicht - systeemontwikkelplan 1007 blz 11 1.1.1f Projectmanagement - projectmanagementmethode - PRINCE2-3. functioneel ontwerp (FO) - Dit bestaat uit een conceptuele beschrijving van het te realiseren informatiesysteem, activiteiten zijn hier: - opstellen plan van aanpak - analyse en ontwerp v gewenst functionaliteit en kwaliteit vh IS - opstellen eindrapport FO 1008 Projectmanagement - projectmanagementmethode - PRINCE2 - *** blz 11 1.1.1g 4. technisch ontwerp (TO) - het functioneel ontwerp wordt hier vertaald naar technische consequenties zodat aan de gestelde prestatie-eisen wordt voldaan, activiteiten zijn hier: - opstellen plan van aanpak - opstellen programmaspecs - ontwerpen opslagstructuur - uitwerken beeldschermspecificaties *** - opstellen specs voor systeemtest - opstellen eindrapport TO 1009 blz 11 1.1.1h Projectmanagement - projectmanagementmethode - PRINCE2-5.bouw/realisatie - programma's worden geschreven en de DB gerealiseerd, activiteiten zijn hier: - opstellen plan van aanpak - programmeren, bouw DB, uitwerken procedures en handleidingen - uitvoeren systeemtest - opstellen rapportage 1010 blz 11 1.1.1i Projectmanagement - projectmanagementmethode - PRINCE2-6. acceptatietest - deze wordt door klant/opdrachtgever uitgevoerd met als doel controleren of het systeem aan de gevraagde specs voldoet, het richt zich op de gestelde functionele eisen en de gestelde prestatie eisen, activiteiten zijn hier: - opstellen plan van aanpak/tekstplanning - uitvoeren acceptatietest - opstellen rapportage testbevindingen 1011 blz 12 1.1.1j Projectmanagement - projectmanagementmethode - PRINCE2-7. invoering - in gebruik nemen van het IS, activiteiten zijn hier: - opstellen plan van aanpak - inrichten (beheer)organisatie - verzorgen opleidingen - installatie systeem - uitvoeren dataconversie (indien nodig) - invoering - overdracht systeem aan eigenaar maandag 19 oktober 2015 Pagina 5 van 61
1012 blz 12 1.1.1k Projectmanagement - projectmanagementmethode - PRINCE2-8. gebruik en beheer - Dit valt buiten het project en is nodig zolang het systeem in gebruik is. Het IS wordt hier doorlopen aangepast aan gestelde functionele en prestatie eisen, de belangrijkste soorten onderhoud zijn: - CORRECTIEF onderhoud > herstellen van fouten - PERFECTIEF onderhoud > perfectioneren - ADAPTIEF onderhoud > aanpassen, uitbreiden 1013 blz 12 1.1.1l Projectmanagement - projectmanagementmethode - Dynamic Systems Development Method (DSDM) - DSDM is een methode voor incrementele en iteratieve applicatieontwikkeling, waarbij een Is vooral geschikt voor systemen die: - interactief zijn, met een goed zichtbare functionaliteit in userinterface - goed gedefinieerde gebruikersgroep hebben - als complex > decomponeerbare complexiteit bezitten - als groot > opdeelbaar zijn in kleine functionele eenheden - prioteerbare requirements hebben - onduidelijke of veranderlijke requirements hebben DSDM minder geschikt voor: - procesbesturings- en real-time applicaties - systemen waarbij op voorhand de eisen volledig vast moeten liggen - safety-critical applicaties - projecten waarbij ook herbruikbare componenten moeten worden geleverd. Uit ISYF > DSDM > applicatie niet in één keer in zijn geheel ontwikkeld wordt, maar in kleine stukjes wordt opgeleverd. Incrementen = kleine stukjes. Het kent de volgende fase: 1. Toepasbaarheidsonderzoek > nagaan of de start vh ontwikkelproces zin heeft en of DSDM juiste methode is 2. Bedrijfsanalyse > beter inzicht krijgen in de te automatiseren bedrijfsprocessen en informatiebehoeften (voor het project) 3. Functioneel model - iteratie > is gericht op verfijnen vd bedrijfsprocessen, de basis voor de protypes 4. Ontwerp & Bouw - iteratie > systeem wordt steeds verder getest en verfijnd en kan overgedragen worden aan gebruikers, op dat moment voldoet het systeem aan een aantal minimaal gestelde eisen nog niet aan alle. 5. Implementatie > het gerealiseerde systeem wordt overgedragen aan gebruikers. Hierbij hoort ook opleiding, voorlichting en trainingen en het maken vd gebruikershandleiding. Voor de priotering vd eisen is het acroniem MoSCoW bedacht: - Must have > eisen zijn essentieel > alleen deze v belang voor oplevering deelsysteem!! - Should have > eisen zijn belangrijk, maar niet noodzakelijk en als we tijd hebben doen we deze - Could have > eisen die weg gelaten zouden kunnen worden - Want to but not now > Want to have but will not have this time around > eisen voor het volgende traject Als bij deelsysteem een nieuwe must have eis ontstaat, alle andere weer even nakijken of deze nog allemaal must have zijn. Speling inbouwen. 113 maandag 19 oktober 2015 Pagina 6 van 61
1014 blz 13 1.1.2a Systeemontwikkeling - architectuurbenaderi ng - 241 wordt gebruik van gemaakt om toenemende noodzaak tot uitbreiden en migreren vd bestaand informatievoorziening te kanaliseren. Elke architectuurlaag heeft de volgende aspecten: - CRITERIA > omvat uitgangspunten, principes, voorschriften en richtlijnen - GRAFISCH > omvat modellen, structuren en ontwerpen Op elk niveau worden de criteria en grafische aspecten vh BOVENliggende niveau uitgediept. BEDRIJFSARCHITECTUUR > is het startpunt voor informatievoorzienings-architectuur. Is een gestructureerde omschrijving v alleen die zaken die voor de informatievoorzienings-architectuur relevant zijn. Het bevat een schematische blauwdruk vd totale gewenste indeling in gebieden die elk een specifiek doel hebben en bevatten soms complete architecturen op zichzelf. INFORMATIEVOORZIENINGSARCHITECTUUR > Schetst een beeld vd (toekomstige) informatievoorziening. Interpreteert de bedrijfsarchitectuur en stelt de consequenties voor de informatievoorziening vast. De principes beschrijven de eisen die aan de individuele informatiesystemen worden gesteld. Gevolg is dat de reorganisatie de voor haar best passende pakketten selecteren of systemen ontwikkelen, terwijl toch de samenhang bewaakt blijft. Belangrijke onderdelen zijn: - functionaliteitsmodel > - WELKE toepassingen verwerken gegevens / WAAR vindt dat plaats / WAAR zijn de gegevens opgeslagen INFORMATIESYSTEEMARCHITECTUUR > vertaalt de informatievoorzienings-architectuur naar de werkende informatievoorziening en bevat op basis v principes en modellen richtlijnen en ontwerpen. De richtlijnen zijn constructie eisen die rechtstreeks zijn afgeleid uit de principes vd informatievoorzienings-architectuur. Deelarchitecturen zijn hier: - applicatiearchitectuur > hoe worden applicaties gebouwd - gegevensarchitectuur > welke eisen voor fysieke gegevensverzamelingen INFRASTRUCTUUR > bevat voorschriften die afgeleid zijn vd principes uit de informatievoorzienings-architectuur en bevatten eisen ten aanzien v beveiliging en beheersbaarheid. 328 maandag 19 oktober 2015 Pagina 7 van 61
1015 Systeemontwikkeling - *** blz 16 1.1.2b architectuurbenaderi ng - INFRASTRUCTUUR > fysieke wereld waarbinnen het informatiesysteem geïmplementeerd is. APLLICATIESTRUCTUUR > is de inwendige structuur van een IS. Een IS bevat de volgende componenten > - invoerfaciliteiten - verwerkingsfaciliteiten - opslagfaciliteiten - uitvoerfaciliteiten Informatieanalisten, systeemontwerpers en toekomstige gebruikers zullen de specificaties vaststellen en daarna gaan de programmeurs en ontwikkelaars overgaan tot realisatie. SYSTEEMONTWIKKELINGSAANPAK : is het productieproces waarin ICT/deskundigen en materiedeskundigen (de bedrijfsvoering) gericht samenwerken met als doel de realisatie ve informatiesysteem. DOEL > via een zo effieciënt en effectieve mogelijke aaneenschakeling v stappen komen tot het gewenste IS dat optimaal is afgestemd op de eisen en wensen vd opdrachtgever. STRATEGIËN om gewenst resultaat te bereiken zijn afhankelijk vd aard en complexiteit > - invulling vd ontwikkelcyclus - benaderingswijze - denkwijze Ontwikkelcycli kunnen toegepast worden - LIE > *** - LINEAIR > alle stappen sequentieel doorlopen en compleet afleveren. Werkt bij kleine projecten of projecten waarbij op voorhand DUIDELIJK is hoe het moet worden. - INCREMENTEEL * > voor ieder volwaardig onderdeel stappen iteratief doorlopen, prioriteiten leggen op deelsystemen, waar onzekerheid is later doen. - EVOLUTIONAIR * > voor ieder onderdeel stappen iteratief doorlopen en het hele systeem in een aantal iteraties opgeleverd waarbij iedere functionaliteit wordt toegevoegd. Deze aanpak kiezen als er onzekerheid is over de volledige functionaliteit van het op te leveren systeem. Rudimentair prototyping. GEHEEL ONDUIDELIJK. Benaderingswijzen > TOP-DOWN > processen als uitgangspunt, organisatie gericht, voordeel > meer samenhang tussen strategisch en operationeel niveau. BOTTOM-UP > Benodigde data als uitgangspunt, mensgericht, voordeel > betere fit vh IS met belevingswereld eindgebruikers. TESTEN, regels zijn o.a. > - uitgangspunt is FO - resultaten vd test vooraf vaststellen - testgegevens moeten representatief zijn TESTEN, aspecten > - functioneren volgens de functionele specificaties op gebied van: - volledigheid / juistheid / betrouwbaarheid / tijdigheid / gebruiksvriendelijkheid - functioneren overeenkomstig de prestatie eisen - POF: - performance / onderhoudbaarheid / flexibiliteit Gebruikers organisatie is verantwoordelijk voor de acceptatietesten. ICT-deskundigen zijn verantwoordelijk voor technische testen (bv systeem- en DB-testen). Het is belangrijk om onderscheid te maken tussen besturing en inhoudelijke activiteiten bij realisatie van een IS. Systeemontwikkelaars zijn samen met gebruikersorganisatie verantwoordelijk voor inhoudelijk resultaat en voor het daadwerkelijk realiseren vd functionaliteit volgens gewenste kwaliteit. 329 maandag 19 oktober 2015 Pagina 8 van 61
1016 blz 21 1.2.1 Systeemontwikkeling volgens MAD (Modelbased Application Development) - overzicht vd methode - 330 MAD aanpak bevat handvatten voor projectmangement en systeemontwikkeling. MAD is een vorm v RAD (Rapid Application Devolement), waarbij de nadruk ligt op modelleren. Bij MAD wordt ook gebruikgemaakt van JAD (Joint Application Design) om gebruikersparticipatie optimaal te waarborgen. Scope vd projectaanpak is breder dan de scope vd ontwikkelingsaanpak. De overkoepelende fase beheerden de MAD-ontwikkelcyclus heeft de fasering > 1. definieer project 2. definieer increment 3. realisatie 4. installatie Ontwikkelactiviteiten binnen MAD zijn > - opstellen bedrijfsmodellen bevat > - bedrijfsactiviteitenmodel, - informatiemodel en - afbakening systeemgrenzen - opstellen systeemmodellen bevat > - definitie vd gegevensstructuur - gedrag - userinterface vh increment - ontwikkel increment - installeer increment maandag 19 oktober 2015 Pagina 9 van 61
1017 blz 22 1.2.2a Systeemontwikkeling volgens MAD (Modelbased Application Development) - kenmerken - 331 Ontwikkelfilosofie van MAD > - hanteren v modelmatige specificaties en hergebruik v modellen - toepassen v iteratieve en incrementele systeemontwikkeling - actieve betrokkenheid v toekomstige gebruikers - optimaal gebruik maken v prototypes - effectief gebruik van tools (applicatiegenerators) MAD onderscheidt zich doordat de methode het documenteren (modelleren) verankert in de methode. Modellen zijn het uitgangspunt en worden gebruikt als specificatie voor het geneneren van het systeem, hierdoor blijven ze actueel. Men begint altijd met het opstellen ve bedrijfsactiviteitenmodel > doel > inzicht krijgen in de eisen vanuit het bedrijfsproces. INCREMENTELE ontwikkeling > het systeem wordt opgedeeld in deelsystemen nadat de bedrijfsactiviteiten en de informatiebehoefte voor de volle breedte zijn bepaald en vastgelegd. DEELSYSTEEM > is een logische geïsoleerde eenheid vd functionaliteit die los ontwikkeld en geïmplemeerd kan worden, hierdoor is parallele systeemontwikkeling mogelijk. Volgorde van ontwikkelen is afhankelijk van de afhankelijkheden tussen incrementen en gestelde prioriteiten door de opdrachtgever. JAD (Joint Application Design) > gebruiker actief laten participeren, de volgende deelnemers zijn bij een JAD sessie aanwezig: - Sessie-leider > taak > sessie faciliteren - Opdrachtgever > taak > beslissen over beschikbaarheid en budget - Gebruikersvertegenwoodigers > taak > verwoorden vd functionele eisen en wensen - Informatie-analisten > taak > opstellen vd bedrijfs- en systeemmodellen - Secretaresse> taak > notuleren - Specialisten (eventueel) > taak > beantwoorden v specifieke vragen Voorwaarden ve goede JAD-sessie > - juiste personen met juiste kennis - deelnemers moeten gedurende hele project beschikbaar zijn - deelnemers moeten beslissingsbevoegd zijn bij keuzes voor functies vh IS maandag 19 oktober 2015 Pagina 10 van 61
1018 blz 24 1.2.2b Systeemontwikkeling volgens MAD (Modelbased Application Development) - prototyping - is een methode om op iteratieve wijze in nauwe samenwerking met gebruikers in korte tijd een prototype te ontwikkelen met als doel de kwaliteit vh te ontwikkelen IS te verhogen, doordat met behulp van prototyping betere functionele specificaties worden verkregen. De protoype-cyclus is een iteratie vd onderstaande activiteiten > - specificatie en ontwerp vh prototype - bouwen protoype - het protypen met gebruiker - evalueren vh prototype om vervolgens de specificatie en het ontwerp te kunnen aanpassen Applicatiegenerator > ontwikkeltool ter ondersteuning voor systeemontwikkelaars. 1019 blz 25 1.2.3a Systeemontwikkeling volgens MAD (Modelbased Application Development) - MADprojectinrichting - 332 Op basis ve businesscases kan beoordeeld worden of nieuwe ideeën en/of wensen aan de doelstelling vd organisatie voldoen. Het informatieplan vertaalt het beleid naar een planning in de tijd. Het omschrijft de volgende onderwerpen: 1. informatiesysteemarchitectuurplan 2. programma (= overzicht vd uit te voeren projecten) 3. plan voor gebruik van tools 4. plan voor technische infrastructuur 5. middelenplan 6. sociaal plan 7. organisatieplan maandag 19 oktober 2015 Pagina 11 van 61
1020 blz 26 1.2.3b Systeemontwikkeling volgens MAD (Modelbased Application Development) - MAD projectinrichting - MAD heeft veel overeenkomsten met PRINCE2 en bestaat uit de volgende fase: 1. OPSTARTEN en INITIEREN project Voorbereidingen starten en randvoorwaarden invullen, plan van aanpak maken. Projectorganisatie bepalen, verantwoordelijkheden en bevoegdheden verdelen. Overzicht v op te leveren producten maken, diverse planningen Risico-analyse uitvoeren. 2. BEHEERSEN vd MAD-ontwikkelcyclus > subfasen: a. DEFINIEER PROJECT b. DEFINIEER INCREMENT c. REALISATIE d. INSTALLATIE 3. IMPLEMENTATIE informatiesysteem Oplevering vd incrementen, opleiden en nazorg 4. BEHEER en ONDERHOUD Projectmanager moet beheer en onderhoud regelen, maakt SLA. Beheer en onderhoud zelf valt buiten het project. 5. AFSLUITING project 1. Projectmanager stelt eindrapportage op, legt verantwoording af en geeft resultaat. 2. Opdrachtgever verleent decharge. 3. Projectmanger draagt project over aan de lijnorganisatie. VERANTWOORDELIJKHEDEN: PROJECTMANAGER/leider > besturing en beheersing. ICT deskundigen > realiseren vh IS volgens functionele eisen en prestatie eisen die door gebruikers zijn bepaald. 333 maandag 19 oktober 2015 Pagina 12 van 61
1021 Systeemontwikkeling volgens MAD (Modelbased Application Development) - *** blz 28 1.2.3c MAD projectinrichting - beheersen vd MADontwikkelcyclus - 2. BEHEERSEN vd MAD-ontwikkelcyclus > subfasen: a. ***DEFINIEER PROJECT ***> 1. opstellen bedrijfsactiviteitenmodel > doel > bedrijfsprocessen en informatiebehoefte in kaart brengen 2. maak globaal informatiemodel 3. ***afbakening systeemgrenzen *** > *** DOEL > benoemen welke informatieverwerking daadwerkelijk gerealiseerd wordt binnen het informatiesysteem. Wat binnen de systeemgrens valt en wordt gerealiseerd. Hiermee wordt de scope vh systeem bekend (bepaal zelfstandignaamwoorden, dan werkwoorden en daarna de scope = grenzen). b. DEFINIEER INCREMENT > 4. definitie van de incrementen > In logische eenheden indelen die zelfstandig ontwikkeld en geïnstalleerd kunnen worden. Kernsysteem eerst ontwikkelen. Logische samenhang tussen incrementen is ook bekend.!!activiteiten 1 t/m 4 worden voor het hele systeem doorlopen!!!!activiteiten 5 t/m 9 worden per increment doorgelopen!! c. REALISATIE > 5. definieer gegevensstructuur per increment 6. definieer het gedrag van increment > uitwerken van > - domeinen voor de verschillende attributen - afhankelijkheidsregels voor de verschillende attributen - statusovergangen voor de verschillende attributen - updaten & delete regels voor de attributen - onderlinge samenhang tussen associaties - procesgegevens - autorisaties 7. definieer user-interface voor increment > - GUI = grafische userinterface - welke output en in welke vorm (bv rapportages) 8. ontwikkel increment > - genereren vd basisfunctionaliteit vh increment - toevoegen event-getriggerde regels - bouw GUI/menustructuren - bouw rapportages - integratie met andere reeds ontwikkelde incrementen - systeemtest d. INSTALLATIE > 9. installeer increment Testen is hier vaak lastig > aandachtspunten > - ontwikkel testbare software (kleine componenten) - wissel bouw en test voordurend af - (her)gebruik eerder geteste componenten - gebruik ondersteunende test-tools 334 maandag 19 oktober 2015 Pagina 13 van 61
1022 Systeemontwikkeling volgens MAD (Modelbased Application Development) - --- blz 31 1.2.3d MAD projectinrichting - beheersen vd MADontwikkelcyclus - MOSQUITO = GROKIT (Geld - Risico - Organisatie - Kwaliteit - Informatie - Tijd/planning) - Money / safety (risico) / QUality / Information / Time and resources / Organization > ad Organisatie > belangrijk voor slagen is> kleine projectteams / brede inzetbaarheid vd projectleden / flexibiliteit vd projectleden / leden moeten kunnen anticiperen op wijzigingen Voor de priotering vd eisen en TIME is het acroniem MoSCoW bedacht: - Must have > eisen zijn essentieel > alleen deze v belang voor oplevering deelsysteem!! - Should have > eisen zijn belangrijk, maar niet noodzakelijk en als we tijd hebben doen we die - Could have > eisen die weg gelaten zouden kunnen worden - Want to but not now > Want to have but will not have this time around > eisen voor het volgende traject 1023 blz 35 1.2.4a MAD-systeemontwikkelingsaanpak - uitgangspunten - - modelmatige specificaties en hergebruik van modellen - iteratieve en incrementele systeemontwikkeling - specificaties bepalen in samenspraak gebruikers én ontwikkelaars - prototype gebruiken - (grotendeels) generen met applicatiegeneratoren. Zie figuur 343 voor de ontwikkelingsfase en bijbehorende activiteiten, modellen en producten. - bedrijfsanalyse > in kaart brengen probleemgebied - systeemspecificatie > systeemafbakening, scope en opstellen incrementen - systeembouw > daadwerkelijke realisatie 343 336 maandag 19 oktober 2015 Pagina 14 van 61
1024 MAD-systeemontwikkelingsaanpak - uitgangspunten - *** blz 36 1.2.4b bedrijfsactiviteiten model - 337 heeft de volgende functies: - verkrijgen v inzicht in bedrijfsproces - Uitgangspunt voor het vaststellen van de systeemgrenzen - Uitgangspunt voor het opstellen van een globaal informatiemodel - Uitgangspunt voor het vaststellen van de informatieregels - Uitgangspunt voor het opstellen en vaststellen van de userviews - Communicatiemiddel Voor het modelleren van het bedrijfsactiviteitenmodel wordt hier gebruik gemaakt van zgn A-schema's van de ontwikkelmethode van ISAC of DFD's diagrammen van de ontwikkelmethode Yourdon. GEGEVENSSTROMEN > de pijlen > zelfstandige naamwoorden in de tekst. - INPUT STROOM > gaat in de activiteitblok, is invoer - CONTROLE STROOM > pijl van boven af, die info geeft, alleen raadplegen - OUTPUT STROOM > komt uit de activiteiten blok, is uitvoer Een informatiestroom heeft een naam. Deze naam is een zelfstandig naamwoord en geeft de inhoud van de informatiestroom weer. ACTIVITEITEN > de blokken > werkwoorden uit de tekst. Activiteiten hebben een naam en een nummer. De naam wordt altijd uitvoergericht gekozen en bestaat uit een werkwoord eventueel gevolgd door een zelfstandig naamwoord. De naam duidt de verwerking aan die door de activiteit wordt uitgevoerd. Iedere activiteit heeft minimaal één invoerstroom en één uitvoerstroom. maandag 19 oktober 2015 Pagina 15 van 61
1025 MAD-systeemontwikkelingsaanpak - uitgangspunten - *** blz 37 1.2.4c informatiemodel - 338 is een semantisch model > er wordt nog geen rekening gehouden met implementatie beperkingen. DOEL > informatiebehoefte inventariseren en vastleggen. De figuren 1.19 en 1.20 vormen SAMEN het informatiemodel en bestaat dus uit: 1. INFORMATIESTRUCTUURMODEL >ERD >entiteiten, attributen en hun onderlinge samenhang 2. INFORMATIEREGELS > - identificatieregels > primairy key, uniek gegeven - verplichte attributen > moeten minimaal bekend zijn - validatieregels > toegestane waarden - afhankelijkheidsregels > geeft relatie tussen attributen v verschillende entiteiten weer - ***afleidingsregels > *** op welke wijze de waarde ve attribuut afgeleid of berekend kan worden (21C). - transitieregels > beschrijven toegestane statuswijzigingen ve attribuut. Bv patient van "in behandeling" naar "onder controle". ***Dus het informatiemodel bestaat uit het informatiestructuurmodel én de informatieregels!! 1026 blz 39 1.2.4d MAD-systeemontwikkelingsaanpak - uitgangspunten - afbakening systeemgrenzen - DOEL > bepalen welke bedrijfsactiviteiten voor automatisering in aanmerking komen en daadwerkelijk gerealiseerd worden. De scope vh te realiseren systeem wordt gemodelleerd mbv een contextdiagram, dit is een afbeelding vh te automatiseren systeem in relatie met haar omgeving. Het systeem wordt in dit diagram beschouwd als een black box. Is bedoel om de grenzen af te bakenen en de relatie met de omgeving te tonen. Dit context-diagram is ook gelijk het A-0 schema 340 maandag 19 oktober 2015 Pagina 16 van 61
1027 blz 40 1.2.4e MAD-systeemontwikkelingsaanpak - uitgangspunten - definieer de incrementen - 365 DOEL > identificeren en vast stellen van incrementen. Incrementen zijn als het ware logische eenheden die zelfstandig ontwikkeld en geinstalleerd kunnen worden. Deze opdeling vindt plaats aan de hand vh informatiemodel. Opsplitsen gebeurd daar waar er zoweinig mogelijk informatiestromen lopen. Ontwikkel principes van coupling en binding worden hier gebruikt. BINDING (intern+max) > een maximale interne samenhang > sterke > dan hebben ze een eigen afgebakende verantwoordelijkheid. COUPLING (extern-min) > een minimale externe afhankelijkheid > beschrijft de mate waarop incrementen van elkaar afhankelijk zijn, deze moet zo klein mogelijk zijn. Doet uitspraken over de communicatie tussen incrementen. Sterke binding en zwakke coupling** 341 maandag 19 oktober 2015 Pagina 17 van 61
1028 MAD-systeemontwikkelingsaanpak - uitgangspunten - --- blz 41 1.2.4f definieer de gegevensstructuur - is een systeemgerichte activiteit. Is per increment vastleggen welke gegevens in welke vorm worden opgeslagen. Hiervoor wordt het conceptuele informatiemodel (ERD) omgezet naar een fysiek model. Dit gaat gepaard met de vertaalslag die men normaliseren noemt. Relationele model bestaat uit: - tabellen; - attributen; - primaire en vreemde sleutels. MAD hanteer principe van gecontroleerde redundantie > men kan afwijken van het volledig uit normaliseren vd gegevensverzameling. Twee doelen > - ervoor te zorgen dat de juiste schermen worden gegenereerd - uit performance overwegingen 1029 MAD-systeemontwikkelingsaanpak - uitgangspunten - --- blz 42 1.2.4g definieer het gedrag - gebeurt om de gewenste functionaliteit te specificeren. De volgende specs uitwerken > - domeinen voor attributen - verplichte attributen - internal events (afhankelijkheidsregels en statusovergangen) - update en delete regels - afleidingsregels - autorisaties - aanvullende programma's 1031 MAD-systeemontwikkelingsaanpak - uitgangspunten - --- blz 43 1.2.4h definieer de user interface - dit beïnvloedt in sterke mate de kwaliteit vd software en bepaalt o.a. > - snelheid waarmee men de software leert kennen - bedieningsgemak - kans op bedieningsfouten - visuele aantrekkingskracht Bij ontwerpen is van belang > - gebruikerstaak - frequentie van de taak - duur van de taak - mogelijkheden tot taakonderbreking en schakelen tussen verschillende taken 1031 MAD-systeemontwikkelingsaanpak - uitgangspunten - --- blz 43 1.2.4i ontwikkel het increment - Doel > realiseren vh increment. Activiteiten > - genereer basisfunctionaliteit - event getriggerde regels toevoegen - bouw user interface - bouw rapportages - test - integreer met reeds ontwikkelde incrementen - systeemtest Daarna wordt het geinstalleerd. maandag 19 oktober 2015 Pagina 18 van 61
1032 MAD-systeemontwikkelingsaanpak - --- blz 44 1.2.5 beheer en onderhoud - Wijzigingen aan informatiesystemen zijn in een vijftal categorieen te plaatsen (PAPAC): - CORRECTIEF onderhoud > verbeteren van fouten die ontdekt zijn. - PREVENTIEF onderhoud > voorkomen van mogelijke fouten. - ADAPTIEF onderhoud > veranderen als gevolg van externe ontwikkelingen. - PERFECTIEF onderhoud > vernieuwen vanwege technische ontwikkelingen. - ADDITIEF onderhoud > veranderen als gevolg van nieuwe wensen en eisen, het toevoegen van nieuwe functionaliteiten, veranderingen als gevolg van functionele eisen. 190 1033 Modelmatige aanpak - --- blz 45 1.3 model - Een MODEL is een beperkte vereenvoudigde afbeelding van de werkelijkheid vanuit een bepaald gezichtspunt voor een bepaalde doelgroep. MODELLEREN > is het geheel van activiteiten om een aspect uit de werkelijkheid te transformeren tot een model. Richtlijnen > vanuit een bepaald gezichtspunt of voor een bepaalde doelgroep. Er moet bij modellering altijd een doorgaande resultaatlijn en een doorgaande communicatielijn gehanteerd worden. Per model maar één gezichtspunt visualiseren. Mogelijke systeemonderdelen (zie figuur) 1. verwerking > hart vh systeem 2. user interface > manier voor gebruiker en verwerking om gegevens uit te wisselen 3. via data toegangslaag krijgt gegevens de data van de data opslag 4. data toegang zorgt voor communicatie met de data opslag laag 342 maandag 19 oktober 2015 Pagina 19 van 61
1034 Samenhang tussen MAD-modellen - *** blz 49 1.4a 344 ANALYSEMODEL > is het samenstel v modellen die gericht zijn op het afbeelden vd bedrijfsgerichte specificaties. SPECIFICATIEMODEL > is het samenstel v modellen die gericht zijn op het afbeelden vd systeemgerichte specificaties. AFBAKENING > richt zich op het modelleren vd bedrijfsgerichte specificaties. BEDRIJFSACTIVITEITENMODEL > vormt het startpunt vd modellencyclus binnen MAD. INFORMATIEMODEL *** > de binnen het bedrijfsactiviteitenmodel opgestelde A-schema's bevatten activiteiten en de verbindende informatiestromen, deze worden geanalyseerd om de entiteiten af te leiden om zodoende een globaal informatie-structuurmodel (ERD) op te stellen. Dit informatiestructuurmodel wordt door interviews en workshops via een aantal iteraties steeds verder gedetaillieerd > gevolg totaal overzicht van alle atributen per entiteit > daaruit kunnen weer de informatieregels worden opgesteld e.d. De in A-schema's gemodelleerde activiteiten bieden vooral inzicht in de aard van de informatieregels. maandag 19 oktober 2015 Pagina 20 van 61
1035 blz 51 1.4b Samenhang tussen MAD-modellen - 345 CONTEXTDIAGRAM > wordt vh bedrijfsactiviteitenmodel afgeleid, de basis activiteiten uit het basismodel (A-0 schema) worden tot één activiteit geaggregeerd. Geeft ook inzicht in de begrenzing vh IS en kan er worden overgegaan in opdelen naar incrementen. SPECIFICATIEMODEL > zodra incrementen zijn gedefinieerd worden op iteratieve wijze per increment het gegevensmodel, functiemodel en userinterfacemodel opgesteld. Daarna kun je gaan protoypen. Zie figuur. GEGEVENSMODEL > is de kern vh systeem, hier worden tabellen, gegevens, sleutels en domeinen gespecificeerd. FUNCTIEMODEL > omvat specificaties vd update & delete regels, event getriggerde regels, afleidingsregels en overige functionaliteitsregels. USER INTERFACE MODEL > welke gegevens op welk scherm, hoe worden ze benaderd, welke functionaliteit is mogelijk en wie is waarvoor geautororiseerd. PROTOTYPING > inzicht krijgen in de eisen en de wensen vd gebruikers ten aanzien vh specificatiemodel. maandag 19 oktober 2015 Pagina 21 van 61
1036 Templates en applicatiegeneratie - *** blz 53 1.5a template - 331 Over *** Systeemspecificatie *** deel komt een examen vraag. Dit is de kern. (Y) Bij MAD aanpak. TEMPLATE of rompsysteem of cassosysteem of designware > is een bedrijfsmodel dat is opgeslagen in de repository vd applicatiegenerator, ze kunnen hergebruikt worden. REFERENTIEMODEL > is een template die algemeen toepasbaar is voor een bepaald toepassingsgebeid. SPECIFICATIEMODEL > componenten zijn > - relationeel gegevensmodel - programmadelen - schermdefinities - menustructuur definities SPECIFICATIEMODEL > onderdelen zijn > *** - gegevens - gedrag - kern *** - userinterface maandag 19 oktober 2015 Pagina 22 van 61
1037 blz 54 1.5b Templates en applicatiegeneratie - applicatiegenerator - 346 maakt deel uit van een casetool. CASETOOL > is een samenhangende set ontwikkeltools voor analyse, ontwerp, modellering, prototyping en generatie van informatiesystemen. Focus ligt op het functioneel ontwikkelen en ze bieden de volgende faciliteiten > - grafische ondersteuning - onderhoudsfaciliteiten voor de modellen en specs - mogelijkheden tot prototyping - integratie met SQL - hergebruik mogelijk - voor gedefinieerde events beschikbaar op conceptueel en extern niveau - mogelijkheden om business rules te definieren - automatische generen van programmacode voor diverse platforms UPPERCASE TOOLS > vooral geschikt voor opstellen vd bedrijfsmodellen LOWERCASE TOOLS > zijn voornamelijk voor specificatiesmodellen en geschikt voor applicatiegeneratoren. Modellen uit de uppercase > worden getransformeerd naar > modellen vd lowercase tools. Minimale input voor een applicatiegenerator bestaat uit een relationeel model. De TRIVIALE functionaliteit bestaat uit > - de DB structuur; - menustructuur; - onderhoudsfunctionaliteit voor tabellen; - navigatiepaden tussen tabellen; - zoek funcionaliteit in tabellen; - bewaken referentiele integriteit; - bewaking update- en delete regels; - basisschermen voor de gebruiker. HS.1 Hoofdstuk: 2 Bedrijfsactiviteitenmodel maandag 19 oktober 2015 Pagina 23 van 61
1038 blz 66 2 Business Proces Redisign (BPR) - DOEL > processen beter op klant af stemmen OF de processen efficiënter laten verlopen. Bedrijfsprocessen worden rond klantwaarden georganiseerd. BPR is het opnieuw inrichten vh bedrijfsproces, waarbij infomatietechnologie als bij het ontwerp vh bedrijfsproces wordt meegenomen, met als doel snel en flexibel op veranderende behoeften ingespeeld kan worden en concurrentieposities verbeterd kunnen worden. Succesfactoren > - bedrijfsstrategie wordt heroverwogen; - bedrijfsprocessen herontwerpen; - ict optimaal wordt ingezet ter ondersteuning vd bedrijfsprocessen. Valkuilen > - te laat toepassen van ICT en niet alle ICT mogelijkheden benutten; - teveel aandacht schenken aan kostenbesparingen. 1039 blz 68 2.1a Begrippen en toepassing - Integration DEFinition = IDEF - bestaat uit 3 technieken > - IDEF0 > voor modelleren van activiteitenschema's - IDEF1 > voor modelleren van gegevensschema's - IDEF2 > voor modelleren van gedrag Hebben een top-down structuur. maandag 19 oktober 2015 Pagina 24 van 61
1040 Begrippen en toepassing - *** blz 68 2.1b A-schema en Actimod - 349 moet eenduidigheid scheppen over alle modellen, dit kan door volgende aspecten in beschouwing te nemen > - CONTEXT > is de omgeving waarbinnen het model wordt opgesteld; - DOEL - GEZICHTPUNT > standpunt van waaruit het model wordt opgesteld; - CONTENT > onderwerp vd modellering. Binnen een A-schema is het HOE een activiteit cq verwerkingsproces (werkwoord) dat invoer en uitvoer oplevert. De invoer wordt getransformeerd tot uitvoer. Ook vastleggen met welke hulpmiddelen WAARMEE en wie of wat WAARDOOR de activiteit gestuurd wordt. A-schema bestaat uit de volgende componenten >; - ACTIVITEIT > is een functie waarbinnen een verwerking plaats vindt; - INPUT STROOM > is informatie-/materiestroom die de input levert voor een activiteit; - CONTROL STROOM > is een informatiestroom voor alleen te raadplegen; - OUTPUT STROOM > is de informatiestroom de activiteit levert/resultaat vd verwerking; - MECHANISM STROOM > is een stroom die op meerdere manier kan worden toegepast. Deze bestaat niet in Actimod en wordt alleen in IDEF gebruikt. *** Volgorde ve A-schema is: A-0 > A0 > A1 > A2..etc *** De bedrijfsanalyse begint met het A0 schema. *** Volgorde v opstellen ve A-schema is: A0 dan terug naar A-0 en dan verder met A1 > A2 etc A-0 > toont de applicatie als een activiteit (contextdiagram) A0 > toont diagram met de hoofdactiviteit 348 maandag 19 oktober 2015 Pagina 25 van 61
1041 blz 70 2.1c Begrippen en toepassing - horizontal balancing - bij opstellen van A-schema's is het belangrijk dat de activiteiten binnen een schema ten opzicht van elkaar een gelijkwaardige omvang hebben. 1042 blz 70 2.1d Begrippen en toepassing - level balancing - Bij decompositie is het v belang dat de consistentie met de bovenliggende modellen wordt bewaakt. 1043 blz 71 2.2a Notatiewijze en conventies - Activiteiten hebben een naam en nummer. Iedere activiteit heeft minimaal één invoer en minimaal één uitvoerstroom! Vuistregel > binnen een A-schema bij voorkeur 3 tot maximaal 6 activiteiten opnemen, deze moeten kwa niveau van gelijke zwaarte zijn (horizontal balancing). Informatiestroom = zelfstandignaamwoord > geeft de inhoud vd informatiestroom weer. BRANCHING/SPLITTING > het splitsen ve hoofdstroom in meerdere deelstromen. JOINING > samenvoegen van meerdere deelstromen tot een deelstroom. REALTIME STROOM > geeft ten allen tijde de actuele informatie aan, pijl met 2 punten. TUNNELING > op een lager abstractie niveau een stroom introduceren die op een hoger niveau niet relevant is. Wordt toegepast bij invoer-, control-, en uitvoerstromen, en wordt tussen haakjes gemodelleerd. 353 350 maandag 19 oktober 2015 Pagina 26 van 61
1044 blz 74 2.2.3a Notatiewijze en conventies - feedback - 355 feedback > vanuit een latere activiteit terug gaan naar een eerdere. figuur 355 links > INVOER FEEDBACK (bv bij maken en beoordelen v rontgenfoto's) figuur 355 rechts > CONTROLE FEEDBACK figuur 354 links > voorwaarlijke stroom uit activiteit 1 die als controlestroom geldt voor activiteit 3 figuur 354 rechts > parallele verwerking van activiteit 2 en 3, ze kunnen tegelijkertijd gestart worden. 354 maandag 19 oktober 2015 Pagina 27 van 61
1045 Analyse en modellering - *** blz 79 2.3a opstellen A schema's - topdown - 356 bedrijfsactiviteitenmodel opstellen > stappen > 1. verzamel de benodigde informatie 2. bepaal het doel vh model 3. bepaal het gezichtspunt vh model 4. *** maak een A0-diagram > is basisdiagram met hoofdactiviteiten. Horizontal balancing is belangrijk. Activiteiten van linksboven naar rechtsonder modelleren en verbinden met informatiestromen. 5. *** maak een A-0 diagram > toont één activiteit met de relevante invoer-, controle en uitvoerstromen. Kan worden afgebeeld als een groot blok om het A0-schema te zetten en dan te beschouwen als een activiteit, daarna moeten de invoer-, uitvoeren controle stromen nog geplaatst worden. 6. *** maak uitgaande vh A0-diagram de benodigde decomposities > per activiteit vaststellen uit welke deelactiviteiten het bestaat, bijvoorbeeld: Deelactiviteit 1 van activiteit 1 > in A1 diagram, > dan weer in A11 diagram Deelactiviteit 2 van activiteit 1 > in A1 diagram, > dan weer in A12 diagram Deelactiviteit 1 van activiteit 2 > in A2 diagram, > dan weer in A21 diagram Deelactiviteit 2 van activiteit 2 > in A2 diagram, > dan weer in A22 diagram etc Level balancing niet uit het oog verliezen, zie figuur 213 7. review en controle 357 maandag 19 oktober 2015 Pagina 28 van 61
1046 blz 83 2.3.2a Opstellen ve A-schema - top-down - 358 Benoem maximaal 4 activiteiten die samen een representatief beeld vormen vd activiteiten. Voeg eerst de externe en interne invoer- en uitvoerstromen toe en bepaal daarna de interne hoofdstroom. Deze stromen vormen samen de workflow of rode draad. 1047 blz 84 2.3.2a Opstellen ve A-schema - bottom up - 359 stappen > 1. maak een datalijst > invetariseer de informatiestromen (de zelfstandige naamwoorden) 2. maak een activiteitenlijst > (de werkwoorden) 3. leg associaties tussen de datalijst en activiteitenlijst 4. transformeer de datalijst en activiteitenlijst naar een 1e concept A-schema 5. verfijn het A-schema 6. controleer het A-schema HS.1 Hoofdstuk: 3 Informatiemodel maandag 19 oktober 2015 Pagina 29 van 61
1048 Informatiemodel - *** blz 101 3a 364 DOEL > is om de informatiebehoefte voor het toepassingsgebied te inventariseren en vast te leggen. Het informatiemodel is een semantisch model, dwz dat er nog geen rekening wordt gehouden met implementatiebeperkingen. Het informatiemodel brengt de informatiebehoefte in kaart en bestaat uit > - informatiestructuurmodel én - informatieregels Het informatiestructuurmodel is een ERD (Entity Relationship Diagram). Entiteiten, attributen en hun onderlinge samenhang is vastgelegd. Functies van het informatiemodel zijn > - inzicht verkrijgen - communicatiemiddel - uitgangspunt voor identificeren en afbakenen v incrementen - uitgangspunt voor afleiden specificatiemodel Informatiemodel kent de volgende informatieregels > - identificatieregels - verplichte en optionele attributen - validatieregels (domeinen) - afhankelijkheidsregels (beschrijving relaties) - afleidingsregels (procesgegevens) - transitieregels (bv statusovergangen) maandag 19 oktober 2015 Pagina 30 van 61
1049 Begrippen en toepassing - blz 103 onderdelen ERD - 3.1a ENTITEITTYPE > is het concrete object waarover informatie wordt vastgelegd. De entiteit is de instantie ve entitiettype. ATTRIBUUTTYPE > is een soort kenmerk of de eigenschap vh eintiteitype (veldnaam). Attribuut of attribuutwaarde is een instantie ve attribuuttype. RELATIONSHIPTYPE > is het element waarmee de samenhang tussen entiteittypen wordt gemodelleerd. Geeft de relatie tussen de verschillende objecten weer. 366 1050 blz 104 3.1.1a Begrippen en toepassingen - entiteittype - ZWAK entiteittype > is een entiteittype dat niet zelfstandig beschikt over een uniek identificerend attribuut, het is daarvoor afhankelijk v een andere entiteit. Als er in de primaire sleutel ook een of meerdere vreemde sleutels zitten. SUPERTYPE > is de moeder entiteit met de gemeenschappelijke basisattributen. SUBTYPE > bevat de specifieke attribuuttype die alleen van toepassing zijn op het subtype en via het principe van overerving zijn daarnaast de gemeenschappelijke basis attribuuttypen voor ieder subtype van toepassing. 1051 Begrippen en toepassing - *** blz 104 3.1.2a attribuuttypen - SINGLE VALUED attribuuttype > is een attribuuttype dat voor een entiteit maximaal één attribuutwaarde vertegenwoordigt, bv woonplaats. MULTIEVALUED attribuuttype ***> is een attribuuttype dat voor een entiteit op moment x meerdere attribuutwaarden kan bevatten, bv gevolgde opleiding bij student. Dit kan dus ook een samengesteld attribuuttype zijn en vise versa. SAMENGESTELD attribuuttype > WORDT NIET MEER TOEGESTAAN. Is een attribuuttype dat een samenstelling van attribuutwaarden bevat, bv adres is straat+huisnr+toevoeging. ENKELVOUDIG attribuuttype > is een attribuuttype dat voor de entiteit een atomische attribuut waarde bevat, het kan dus niet verder worden opgesplitst, bv huisnummer. SLEUTELattribuut > is het identificerende attribuuttype van de entiteit. Dit is de kleinst mogelijke samenstelling van attribuuttypen die een entiteit uniek identificeert. maandag 19 oktober 2015 Pagina 31 van 61
1052 Begrippen en toepassing - *** blz 105 3.1.3a relationshiptypen of relatie - geeft de associatie aan tussen entiteittypen. We onderscheiden > - CONNECTIVITEIT of FUNCTIONALITEIT > geeft weer of er sprake is van respectivelijk een 1:1, een 1:n of een n:m relatie tussen de geassocieerde entitteiten gelden. Mogelijkheden zijn > 1:1 > één entiteittype hoort bij één ander entiteittype; 1:n > één entiteittype hoort bij meerdere andere entiteittypen; n:m > meerdere entiteittypen horen bij meerdere andere entiteittypen. *** n > noemt men hier de maximale kardinaliteit - AARD > hiermee kan worden aangegeven of een relatie tussen entiteittype optioneel/partioneel of verplicht/totaal is. - GRAAD of DIMENSIE > geeft aan hoeveel entiteittypen aan een relatie deelnemen. De graad kan maximaal N-air zijn. De volgende graden zijn o.a. mogelijk > - uniair > er paticipeert één entiteittype in de relatie; - binair > er paticipeert twee entiteittypen in de relatie; - tertiar > er paticipeert drie entiteittype in de relatie; - N-air > er paticipeert een onbeperkt aantal entiteittypen in de relatie. De connectiviteit/functionaliteit en de aard worden gemodelleerd voor het vastleggen vd kardinaliteiten (hiermee wordt aangegeven hoeveel relaties er mogelijk zijn tussen relaties). 1053 Begrippen en toepassing - *** blz 106 3.1.4a informatieregels - de volgende worden onderkend > - IDENTIFICATIEREGELS > geeft het attirbuut of de combinatie v attributen weer die de entiteit uniek identificeren. - VERPLICHTE en OPTIONELE attributen > geven aan welke attributen van een entiteit minimaal bekend moeten zijn cq minimaal ingevuld moeten zijn. - VALIDATIE (domeinen) > geven een opsomming vd toegestane waarden weer die voor dat attribuut geldig zijn. - AFHANKELIJKHEIDSREGELS > geven de relaties weer tussen attributen van verschillende entiteiten. - ***AFLEIDINGSREGELS (procesgegevens)*** > beschrijven op welke wijze de waarden ve attribuut kan worden afgeleid of berekend op basis van andere attributen. - TRANSITIEREGELS > beschrijven de toegestane statuswijzigingen voor een attirbuut. 1054 blz 107 3.1.5a Begrippen en toepassing - occurence en population - OCCURENCE > is de fysieke instantie van een bepaald entiteittype, bv patiënt Janssen. POPULATION > is de verzameling fysieke entiteiten op een willekeurig moment, bv de verzameling van alle patiënten op 12 mei. maandag 19 oktober 2015 Pagina 32 van 61
1055 blz 108 syntax - 3.2.1a Notatiewijzen en conventies - 367 ENTITEIT RELATIE DIAGRAM = ERD (Entity relation ship diagram) > is een schematische weergave vd samenhang tussen entiteittypen. Hierin kunnen de entiteittypen en relatietype worden weergegeven. Hier wordt de notatiewijze zoals in ISO-rapport omschreven, toegepast. Omdat in de praktijk er teveel entiteiten voorkomen worden attributen tekstueel toegevoegd, het model zou anders veel te groot worden. Zie figuur 3.3 voor de notatiewijze. 1056 blz 109 3.2.2a Notatiewijzen en conventies - conventies voor het modelleren v entiteittypen - ENTITEITTYPE > is een rechthoek met een naam Bij SUBTYPE en SUPERTYPEN wordt het volgende onderscheid gemaakt: - DISJUNT of EXCLUSIEF > bv een patiënt mag alleen maar bij OF een kaakchirug OF een dermatoloog geregistreerd staan maar niet bij beide. - NIET-DISJUNCT > Bv een patiënt mag bij een dermatoloog en bij een kaakchirurg geregistreerd zijn. Bij een VOLLEDIGE VERZAMELING wordt dit weergegeven met een gevulde zwarte pijl. 235 maandag 19 oktober 2015 Pagina 33 van 61
1057 Notatiewijzen en conventies - *** blz 110 3.2.3 conventies voor modelleren v relationshiptypen - 229 Een RELATIONSHIPTYPE wordt weergegeven dmv een ovaal met een naam erin. Hier in x zitten altijd de sleutels in van A en B (zie figuur 3.9). De aard en de connectiviteit/functionaliteit worden gemodelleerd aan de hand van kardinaliteiten. De minimum kardinaliteit bepaalt de aard en de maximum kardinaliteit bepaalt de connectiviteit/functionaliteit. De notatie wijze is (min, max). De MINIMUM KARDINALITEIT kan waarde 0 of 1 hebben en betekent dat dit entiteittype optioneel of partieel deelneemt in de relatie. Als de minimum kardinaliteit 1 is > het entiteittype neemt altijd deel in de relatie en dan is de aard verplicht/totaal. De MAXIMUM KARDINALITEIT kan een waarde van 1 of n hebben. *** Als de maximum kardinaliteit = 1 > dit entitteittype neemt maximaal één maal deel in de relatie. Als de maximum kardinaliteit = n > dit entitteittype neemt maximaal n keer deel in de relatie. De GRAAD of DIMENSIE betreft het aantal deelnemende entiteiten in een relatie, maximum is N-air. De volgende graden zijn o.a. mogelijk > - UNIAIR > er paticipeert één entiteittype in de relatie; - BINAIR > er paticipeert twee entiteittypen in de relatie; - TERTIAIR > er paticipeert drie entiteittype in de relatie (T-structuur); *** - N-AIR > er paticipeert een onbeperkt aantal entiteittypen in de relatie. AGGREGATIE > is een abstractie waarbij een relatie met zijn entiteittypen als een entiteit op een hoger niveau wordt weergegeven. Zie figuur 3.11. *** Fig 3.7, 3.8 en 3.9 *** Hier komen enkele examenvragen over. 237 maandag 19 oktober 2015 Pagina 34 van 61