B3: Systematisch bouwen van eenvoudige informatiesystemen Algemene Bijlagen

B3: Systematisch bouwen van eenvoudige informatiesystemen

VIII

Algemene Bijlagen

ALGEMENE BIJLAGEN

Inhoud: 1. bijlage VIII.A 2. bijlage VIII.B 3. bijlage VIII.C

Entity-Relationship-diagrammen Soms toegepast: normalisatie-proces Enkele (andere) systeemontwikkelmodellen, methoden en technieken

Bijlage VIII.A Entity-Relationship-diagrammen In onze cursus maken we voor het opstellen van een gegevensmodel gebruik (van een variant) van de in Nederland en een aantal andere landen bekende Nijssen's Informatie-Analyse Methode (NIAM). Al doende hebben we van die methode een aantal voor- èn nadelen leren kennen. Om je kennis te laten maken met de internationaal gezien meer bekende ER- (Entity-Relationship-) methode, geven we in deze bijlage een kleine inleiding bij de ER-methode. De ER-methode werd door Chen geïntroduceerd in 1976. Daarna hebben vele auteurs allerlei aanvullingen aan het model toegevoegd. Een groot probleem is echter, dat door die aanvullingen van de ER-diagram-techniek tientallen varianten bestaan, die soms tegenovergestelde notatie-conventies (lijken te) gebruiken. De basisbegrippen 'Entity' en 'Relationship' komen min of meer overeen met de 'objecten' en 'relaties' zoals wij die bij NIAM hebben gebruikt. De bij deze basisbegrippen behorende symbolen zijn bij alle varianten: - een rechthoek voor 'entiteiten' - een ruit voor 'relationships'. Als voorbeeld geven we hier een globaal ER-diagram om de relatie af te beelden tussen de entiteiten 'docent' en de door haar/hem verzorgde 'vakken':

docent

geeft gegeven

vak

geeft

vak

door

Een variant op dit diagram is:

docent

In de praktijk wordt het ruit-symbool vaak achterwege gelaten, hetgeen in dit geval leidt tot:

docent

geeft

vak

In hun globale vorm worden ER-diagrammen ook gebruikt voor het weergeven van het 'bedrijfsmodel' van een organisatie. Een voorbeeld daarvan (uit: 'Bestuurlijke Informatiekunde'; Bots [et al.], 1990) is:

© NIII / School voor Informatica

AlgBijl. 1

KU-Nijmegen


bestaat uit

Algemene Bijlagen

verbonden aan

ZIEKENHUIS

AFDELING

ligt op

DOKTER

in behandeling bij

PATIËNT

De verschillen tussen de diverse ER-diagram-varianten komen pas duidelijk naar voren bij het aangeven van beperkingsregels zoals uniciteitsregels en ' totale rollen' . Als voorbeeld nemen we een situatie, waarin een docent meerdere vakken kàn geven en waarbij een vak maar door één docent mag èn moet worden gegeven. A) Voor het (bij 'uniciteitsregels' ) aangeven van1: N -relaties komen we vaak de twee volgende varianten tegen: 1) de variant waarbij de aanduidingen ' 1'

docent

1

en ' N' bij de verbindingslijn(en) aangegeven worden: N

geeft

vak

2) een tweede veel gebruikte variant werkt met ' kraaienpootjes' van de kant van de meervoudige' '

docent

relatie:

vak

geeft

Op dezelfde manieren zijn natuurlijk 1:1- en N:M-relaties aan te geven.

B) Voor het aangeven van totale rollen zijn er onder andere de volgende drie mogelijkheden: 1) met een vette stip aangeven welke entiteit(en) verplicht met een ' relationship' is/zijn verbonden, zoals in:

docent

geeft

vak

2) net het a.h.w. tegenovergestelde, door met een 'O' aan te geven dat een bepaalde roloptioneel is, zoals via:

docent

geeft

vak

De nìet als optioneel aangeduide rollen zijn dan uiteraard verplicht.


AlgBijl. 2

KU-Nijmegen


Algemene Bijlagen

3) met een dubbele lijn tussen een entiteit(srechthoek) en een relationship(sruit) aangeven, dat bij het voorkomen van een bepaalde entiteit (ook) de zo aangeduide rol beslist moet voorkomen:

vak

geeft

docent

(Dit kan natuurlijk alleen bij de notatie waarbij de relationshipsruiten expliciet aangeven zijn!) Zeker bij gebruik van de ER-diagram-techniek voor het opbouwen van een gegevensmodel is het nodig om aan de voorkomende entiteiten ook ' attributen' (=beschrijvende kenmerken van de entiteittypen) toe te kennen. Een dergelijk gedetailleerd entity-relationship-model wordt ook wel entity-relationship-attribute-model (ERAmodel) genoemd. De attributen worden daarbij meestal als cirkels weergegeven. Een mogelijk uitwerking voor het gegevensmodel bij het docent-vak-voorbeeld is: vaknaam

naam

docent

geeft

aantal studiept

telefoon


vak

AlgBijl. 3

KU-Nijmegen


Algemene Bijlagen

Bijlage VIII.B Soms toegepast: normalisatie-proces Ofschoon dat wel mogelijk is, wordt bij het werken met ER-diagrammen over het algemeen géén gebruik gemaakt van een (handmatig òf geautomatiseerd uit te voeren) algoritme voor het bepalen van de ONFgegevenstabelstructuur (ONF = Optimal Normalized Form : het minimum aantal gegevenstabellen waarbij de tabelstructuur dusdanig is, dat er géén gegevensredundantie aanwezig is; zie ons 3-stappen-plan zoals we dat bij SDM activiteit 3.10 hebben toegepast). Een dergelijke ONF-structuur levert een relationele gegevensbankopbouw, waarmee het snelst de verbanden (/koppelingen) tussen de verschillende aan elkaar gerelateerde gegevens te leggen zijn. Ofschoon we zo' n algoritme uiteraard zelf kunnen ontwikkelen, wordt in de praktijk vaak een nogal moeizaam normalisatie-proces doorgevoerd, waarbij gegevens in de eerste (1NF), daarna de tweede (2NF) en vervolgens derde (3NF) (en eventueel nog hogere: 4NF of 5NF) normaalvorm worden geplaatst. Bij dit normalisatie-proces plaatst men eerst alle gegevens bij elkaar en gaat daarna op zoek naar steeds een nieuw, specifiek soort redundantie en een bijbehorende manier van tabel-opsplitsing om dat specifiek soort redundantie weg te werken. Een vrij eenvoudige beschrijving voor de uitvoering van een normalisatie-proces tot en met 3NF treffen we aan in [Bemelmans; Bestuurlijke informatiesystemen en automatisering; zesde druk blz. 261]. Daar vinden we: De drie meest genoemde en toegepaste normalisatiestappen zijn: Stap 1: Verwijder uit een gegevensverzameling de repeterende groepen. Resultaat zijn dan gegevensverzamelingen in de eerste normaalvorm. Stap 2: Verwijder die beschrijvende attributen (lees: kolommen van een gegevenstabel) die slechts van een deel van de identificerende attributen afhankelijk zijn. Resultaat van deze stap zijn gegevensverzamelingen in de tweede normaalvorm. Stap 3: Verwijder beschrijvende attributen, die gedetermineerd worden door andere beschrijvende attributen. Resultaat van deze stap zijn gegevensverzamelingen in de derde normaalvorm. Uitvoerigere beschrijvingen (+ voorbeelden) van het normalisatie-proces (desgewenst tot en met 5NF) kun je aantreffen in vele boeken over database-ontwerp. Zie bijvoorbeeld [Date; An Introduction to Database Systems] of [Vandenbulcke; Databasesystemen voor de praktijk]. Gelukkig hebben wij met dit normalisatieproces weinig te maken; de via onze drie-stappen-algoritme uit het NIAM-schema verkregen tabelstructuur is minimaal van de 3NF-vorm.


AlgBijl. 4

KU-Nijmegen


Bijlage VIII.C

Algemene Bijlagen

Enkele (andere) systeemontwikkelmodellen, methoden en technieken

Wij hebben in onze cursus de SDM-systeemontwikkelmethode toegepast. Zoals eerder gesteld is SDM een in Nederland veel toegepaste methode, maar verder te betitelen als ' een van de vele' . Algemene voordelen van het toepassen van een systeemontwikkelmethode zijn: - je dwingt jezelf tot een gedisciplineerde eerst-denken-en-dan-pas-doen-aanpak - je maakt daarbij gebruik van de gebundelde ervaring van tientallen, honderden of misschien wel (tien)duizenden ontwikkelaars die bij elkaar (vaak in multidisciplinaire teams) enorm veel systemen hebben ontwikkeld. Ga niet zelf met veel schade en schande zèlf voor de zoveelste keer het wiel uitvinden, maar maak gebruik van die ervaring van anderen.

I) Methoden en technieken bij systeemontwikkeling We geven hier een veel gebruikte indeling voor systeemontwikkelmethoden is: -

projectgerichte benadering (vooral voor het beheersen van het ontwikkeltraject) Het standaardvoorbeeld hierbij zou SDM kunnen zijn.

-

gegevensgerichte benadering (waarbij men er vaak al dan niet expliciet van uitgaat, dat de (samenhang tussen de) gegevens binnen een organisatie veel stabieler is dan de wijze waarop men met (veranderende) processen binnen een organisatie die gegevens verwerkt). Voorbeelden hiervan zijn (uitgebreid) NIAM en de Entity-Relationship-methode (zie de vorige bijlage).

-

procesgerichte benadering, waarbij men zich net sterk richt op de processen waarmee binnen een organisatie de gegevens verwerkt worden. Het bekendste voorbeeld van een procesgerichte systeemontwikkelingsmethode is waarschijnlijk ISAC (Information Systems work and Analysis of Changes). Bij deze in Zweden (in ± 1970 aan de universiteit van Stockholm) ontwikkelde methode, gaat men uit van de denkwijze dat de gebruikersorganisatie zèlf de aard en de omvang van de te onderzoeken problematiek bepaalt (deels als (positief) antwoord op deze aanpak is in SDM versie II de fase 0 ingevoerd!). Net als bij SDM is de werkwijze bij ISAC ' top down' (van globaal naar details). Zeer bekend uit ISAC is de specifieke schrijfwijze/notatie met zijn A-, I-, C-, D- en P-schema' s (zie voor de A-schematechniek bijlage IP-k van het B3-collegedictaat bij het hoofdstuk over SDM-fase 0). Als sterke kant van de ISAC-methode moet beslist genoemd worden de participatie van de gebruikers. Als zwakke kanten van ISAC worden vaak genoemd: - weinig expliciete aandacht voor gegevensstructuur; - (mede daardoor) beperkt tot voorstudie en ontwerp; - het onderhoud van de diverse soorten ISAC-schema' s is erg arbeidsintensief.

II) Mogelijke algemene invalshoeken voor systeemontwikkeling Een andere indeling voor algemene modellen voor systeemontwikkeling is: - de waterval-benadering bij deze aanpak, wordt in een volgende stap voortgebouwd op de resultaten van vorige stappen, waardoor het totale ontwerp (en de tijd en de omvang van de rapporten) steeds verder aangroeit. Een sterk voorbeeld van deze aanpak levert natuurlijk SDM. - 'exploratory programming' deze aanpak wordt toegepast als het moeilijk is om op een gestructureerde manier een gedetailleerde specificatie op te stellen van waar het systeem uiteindelijk aan moet voldoen. Deze aanpak wordt vooral gebruikt bij het ontwikkelen van systemen met zogenaamde kunstmatige intelligentie , waarbij het vaak in de beginfase niet duidelijk is wat het precies voor systeem moet gaan worden. - 'proto typing'


AlgBijl. 5

KU-Nijmegen


Algemene Bijlagen

deze aanpak wordt vooral gebruikt om systeemeisen boven water te krijgen (dit kan bijvoorbeeld ook toegepast worden in de SDM-definitiestudiefase). - formele transformatie de bedoeling van deze aanpak is om via ' formele uitwerking ' van systeemeisen (ooit in de toekomst??) volautomatisch code te kunnen genereren. - systeem-assemblage met behulp van herbruikbare componenten op meerdere gebieden wordt gehamerd op de mogelijkheid om te proberen om onderdelen van reeds bestaande informatiesystemen te gebruiken voor het ontwikkelen van nieuwe systemen. Ook in dit opzicht verwacht men veel heil van de Object Oriented aanpak (OOAnalysis, OODesign en OOProgramming). Uiteraard is het ook mogelijk om meerdere van deze aanpakken met elkaar te combineren, zoals b.v. (rapid) prototyping gecombineerd met exploratory programming , waarbij het prototype dienst doet als referentiepunt voor kennisverwerving. Zie voor een uitvoerigere behandeling van deze verschillende aanpakken bijvoorbeeld: Ian Sommerville: . ' Software Engineering'

III

Als ‘moderne’ voorbeelden: RAD en MAD

Uit: ' Nieuwe ontwikkelingsmethoden zijn zuiniger met tijd en geld .' ; Th. van Grieken en C. v/d Blom; Automatiseringsgids 26-1-' 96; halen we (samengevat): Moderne ontwikkelingsmethoden als RAD (Rapid Application Development) en MAD (Modelbased Application Development) en diverse evolutionaire benaderingswijzen zijn vanaf pakweg 1991/' 92 sterk in opkomst. Kenmerkend voor de moderne aanpak is dat een systeem tot stand komt door er telkens nieuwe stukjes aan toe te voegen. Iedere nieuwe versie ontstaat door steeds opnieuw een relatief klein project uit te voeren. Het nieuwe systeem wordt dus niet in zijn geheel ontwikkeld en op een bepaald moment in één keer ingevoerd in de organisatie (als een Big Bang). Het idee achter deze evolutionaire ontwikkelingsstrategie is, dat een systeem per definitie nooit af is. De ervaring wijst uit dat bij een systeem met een omvang van 800 à 1000 functiepunten de Big Bangbenadering vaak niet goed meer werkt. In zo' n geval kan het systeem beter in meer versies, dus evolutionair ontwikkeld worden. Bij de ontwikkeling van de eerste versie richt men zich op de hoofdzaken, de kern van het systeem. Er moet wel een beeld gevormd worden van de eindsituatie, te bereiken na een periode van twee à drie jaar. De producten van de voorbereidende fase zijn een (globaal) proces- en datamodel. Met een volgende versie wordt pas gestart wanneer de gebruikers 2 à 3 maanden met het systeem hebben gewerkt. Een (ander) kenmerk van deze moderne systeemontwikkelmethoden is, dat time driven wordt ontwikkeld. Dus niet langer wordt eerst de totale functionaliteit bepaald, waarna de vereiste hoeveelheid tijd en geld (lees: het aantal ontwikkelaars) wordt vastgesteld. Bij de moderne aanpak wordt eerst de doorlooptijd (timebox) en het beschikbare budget bepaald door de sponsor; daarna bepalen de ontwikkelaars de maximale hoeveelheid functionaliteit (en passen die hoeveelheid in het kader van time box management zonodig aan). De maximale lengte van zo' ntimebox is bepaald op zes maanden (door James Martin; van wie al in 1991 een publicatie over de RAD-methode verscheen). Als voordelen van deze moderne aanpak worden o.a. genoemd: • de achtereenvolgende projecten zijn kleiner en dus beter beheersbaar en beter begrootbaar; • de kans op ontwikkeling van verkeerde functionaliteit vermindert, omdat de gebruikers al spoedig met het systeem aan de slag gaan en dan kunnen zien of het aan hun verwachtingen en eisen voldoet; • de gebruiker ' groeit mee met het systeem' ; • het (deel)systeem is sneller beschikbaar, hetgeen naar gebruikers en sponsors toe vertrouwen wekt; • als tóch de geldkraan dichtgedraaid wordt, dan heeft het geïnvesteerde geld in ieder geval een of meer bruikbare versies opgeleverd, terwijl bij een watervalmethode in zo' n geval slechts een stapel onbruikbare tussenproducten (ontwerpdocumenten, onafgemaakte, ongeteste programma' s) resteren. De praktijk van de eerste drie jaren leerde, dat een productiviteitswinst van 20 à 25 procent haalbaar is, met name door winst in de ontwerpfase. Vooral het houden van workshops in plaats van interviews


AlgBijl. 6

KU-Nijmegen


Algemene Bijlagen

scheelt zeeën van tijd voor gebruikers èn ontwikkelaars en levert tegelijkertijd meer resultaat en overeenstemming op. Aan de andere kant betekent een evolutionaire aanpak, dat er meer geld wordt besteed aan tussentijdse conversies van programmatuur en data. Dit als gevolg van de achtereenvolgende versies. Er zijn nog geen cijfers bekend over een langere periode, maar het is goed mogelijk dat, gerekend over de volledige levenscyclus van een systeem, een evolutionair ontwikkeld systeem méér kost dan een systeem dat is gerealiseerd met de waterval-methode. Tot op heden zijn de resultaten van de moderne aanpak echter positief; de gebruikers zijn tevreden en er zijn geen tot weinig budgetoverschrijdingen. In 1998/99 verscheen het boek: ‘Cyclisch succes of incrementele ellende – “een goed gesprek over RAD” ’, Peter Coesmans c.s., ISBN 90-267-2911-1 ; geschreven door een door het bestuur van de NGGO (Nederlandse Gebruikersorganisatie voor Gestructureerde Ontwikkelmethoden) opgerichte werkgroep, die een antwoord zou moeten geven op veel gestelde vragen als: wat is RAD nu precies, aan welke criteria moet een moderne (RAD-) systeemontwikkelmethode voldoen, kunnen we bestaande RADbeheersmethoden hieraan toetsen, zijn er projectmanagementtools beschikbaar? De werkgroep heeft als ‘middeleeuws’ uitgangspunt genomen, dat het een (leesbaar) boek moest worden ‘ter leeringh ende vermaeck’. Aan de hand van een zestiental praktijkverhalen vertellen ze hoe het wel of niet kan en formuleren ze een aantal best-practices. In het boek worden kort doelen van de RAD-methoden, bereiken van de RADdoelen en een overzicht van zeven -in Nederland gangbare- RAD-methoden (RAD, MAD, EVO, IAD, USoft Approach, CDM Fast Track en DSDM) gegeven. Voor een volledigere beschrijving van deze methoden: zie bijlage A van het boek. Een aantal van deze methoden zijn zwaar gebaseerd op bepaalde tools (USoft Approach en CDM Fast Track) en zijn zonder die specifieke tools ‘veel moeilijker’ toe te passen. Van de onderzochte zestien projecten worden per project ook ‘conclusies’ gegeven (soms onder een kopje als ‘Waarom zo succesvol?’, of ‘Wat ging er mis?’ e.d.). Die ‘conclusies’ dragen hopelijk eraan bij om een beter gefundeerde eigen mening te vormen in de discussie: “Is het wel/niet de methode die het hem doet?” We vermelden hier in datzelfde kader nog uit de laatste paragraaf (3.9) van hoofdstuk 3 van het genoemde boek: “Wat hebben we geleerd?” een aantal door de auteurs getrokken conclusies: • RAD-methoden zijn met name goed toepasbaar wanneer de functionaliteit duidelijk te zien is aan de gebruikersinterface. • RAD is als methode minder geschikt wanneer applicaties moeten worden opgeleverd, waarvan de requirements, de systeemeisen, op voorhand volledig vastliggen (als bijv. veiligheidsaspecten een kritieke rol spelen -denk aan spoorwegovergangen, kerncentrales e.d.) • De auteurs adviseren om in geval van grote problemen in het project, de methode niet heilig te verklaren maar als mogelijke mede-oorzaak te zien. Zelfs wanneer RAD niet de oorzaak van problemen is, maar de aanleiding, kan het verstandig zijn de aanpak te laten schieten.


AlgBijl. 7

KU-Nijmegen

B3: Systematisch bouwen van eenvoudige informatiesystemen Algemene Bijlagen

Recommend Documents