Data Dictionary Objecten in administratieve toepassingen

Data Dictionary Objecten in administratieve toepassingen

Data Dictionary Objecten in administratieve toepassingen.

Afstudeeropdracht van:

Afstudeercommissie:

Ing. G.M.L. Dingemans Open Universiteit Nederland Studentnummer 833965850

Dr. A. Dayanayake (Voorzitter) Ir. J.J. Van der Hoek (Secretaris) Drs. G. Kuys (Lid)

1


Voorwoord Het ontwikkelen van applicaties is een werkterrein dat volop in beweging is. Één manier van softwareontwikkeling heeft al geruime tijd mijn interesse: data driven programmeren of programmeren met een data-dictionary. Dit verslag beschrijft het toepassen van data-dictionaries in administratieve software. Datadictionaries en data-driven programmeertechnieken bestaan reeds een aantal jaren. In 1997 heeft mijn interesse in data-dictionaries geresulteerd in de keuze van mijn afstudeeronderwerp voor de Open Universiteit in Heerlen. Met name de keuze en het toepassen van een objectgeoriënteerde analyse en ontwerpmethode heeft bijgedragen aan het eindproduct zoals dat voor u ligt. Dit eindproduct is tot stand gekomen door de hulp van een groot aantal mensen. Een aantal mensen kan niet onvermeld blijven. Allereerst Maarten van Eck van Tangram automatisering, die, in de beginperiode van de afstudeeropdracht, mij de kans heeft geboden te experimenteren met data-dictionaries in Visual Objects. Verder heeft hij mij geleerd hoe een onderzoek in fasen wordt opgezet. Verder wil ik Peter Los bedanken, mijn manager bij IMN. Reeds voor mijn dienstverband bij IMN heeft hij zich ingezet en gezocht naar een tweetal vakinhoudelijke begeleiders binnen IMN. Mijn vakinhoudelijke begeleiders Gerard Kuys en Olav de Kock hebben een positieve invloed gehad op mijn objectgeoriënteerde denken. Voor hun inhoudelijke bijdrage wil ik hen wil bedanken. Voor het testen van het DDO prototype heb ik Erik Visser en Janno Hordijk bereid gevonden. Zij hebben hun vrije tijd gebruikt om dit prototype te testen en te vergelijken met de traditionele werkwijze. Voor hun bijdragen, ingevulde vragenlijst en suggesties betreffende de toepassing wil ik hen bedanken. Ad van Ommen wil ik bedanken voor zijn opbouwende kritiek. Hij heeft het verslag doorgelezen vanuit het OU student gezichtveld. Als laatste wil ik mijn kinderen en mijn partner, in het bijzonder, bedanken. In de afgelopen periode ben ik veel avonden alleen fysiek aanwezig geweest, heb veel achter mijn PC gezeten of was humeurig na een nacht met weinig nachtrust. Ik kan mij voorstellen dat het maken van deze afstudeeropdracht ook voor hen in een aantal gevallen een opgave is geweest.

Ede, november 1999.

2


Inleiding In dit verslag staan de hulpmiddelen, ook wel ontwikkelomgevingen genoemd, van applicatieprogrammeurs centraal. Denk aan ontwikkelomgevingen als: Powerbuilder (Sybase), MS-Access (Microsoft), Delphi (Borland) en CA-Visual Objects (Computer Associates). In deze ontwikkelomgevingen worden entiteiten zoals formulieren, rapporten en tabeldefinities gerepresenteerd als objecten. Deze hulpmiddelen kennen een aantal nadelen, met name het gemak waarmee ongemerkt het objectmodel inconsistent wordt en het ontbreken van validatie is een probleem. De ontwikkelomgeving helpt de applicatieprogrammeurs bij het opmaken en aanpassen van onder andere formulieren, rapporten, besturingselementen en kolommen of velden in tabellen. Door deze objecten persistent (opslaan in bestanden) te maken kunnen deze problemen gereduceerd worden. In dit verslag wordt een beschrijving gegeven van het proces dat ten grondslag heeft gelegen aan de uitwerking waarbij objecten persistent gemaakt worden door het toepassen van een data-dictionary. Dit verslag is gemaakt in de context van Informatie Management Nederland (IMN). IMN is een middelgroot softwarehuis. De ontwikkeltrajecten worden veelal uitgevoerd bij financiële instellingen zoals banken, verzekeringsmaatschappijen en de overheid. De softwareontwikkelingsprojecten van IMN hebben vrijwel altijd de volgende kenmerken: • Beheersing van administratieve toepassingen in kantoorautomatisering. • Gericht op het registreren en beheren van gegevens. • Veelal opslag van gegevens in relationele databases. • Toepassingen waarbij de Mens Machine Interface belangrijk is. • Gebaseerd op de operating systemen MS-Windows 95/98 en MS-Windows NT. Bij softwareontwikkeling richt IMN zich, waar mogelijk, op twee aspecten, te weten de IMN Drie Lagen Architectuur en Object Oriëntatie. In deze opdracht wordt een knelpunt bij het toepassen van deze twee aspecten in een evolutionair ontwikkelmodel uitgewerkt: Het aanpassen van een business object model waarbij alle lagen in een architectuur betrokken zijn. Het beschreven probleem is algemeen geldend van aard. Echter waar nodig worden voorbeelden gebruikt uit een IMN project waarin de lagenarchitectuur en object oriëntatie worden toegepast. Dit project is de ontwikkeling van een administratief informatiesysteem ten behoeve van de FIOD. De FIOD richt zich op het bestrijden van belastingfraude. Het informatiesysteem richt zich onder andere op de ondersteuning van rechercheurs bij het doen van onderzoeken en het opmaken van processen verbaal. Vanwege vertrouwelijkheid worden fictieve voorbeelden gebruikt. Als naar dit voorbeeld wordt verwezen dan wordt dit project de “opsporingstoepassing” genoemd. In de volgende hoofdstukken vindt u de verslaglegging van de stappen welke ondernomen zijn om tot een prototype te komen van een toepassing waarbij de applicatieobjecten persistent zijn gemaakt. Als uitgangspunt wordt het procesmodel van softwareontwikkeling genomen.

3


Samenvatting Binnen softwareontwikkelingstrajecten nemen de werkzaamheden van applicatieprogrammeurs een belangrijke plaats in. Onder applicatieprogrammeur wordt verstaan een persoon die met behulp van geautomatiseerde hulpmiddelen de resultaten van een analyse- en ontwerptraject vertaalt naar (een deel van) een informatiesysteem. Echter het gereedschap van een applicatieprogrammeur, de ontwikkelomgeving, biedt te weinig ondersteuning om te komen tot een goed eindproduct. Met name kwaliteitsaspecten als robuustheid en juistheid komen onder druk te staan doordat ontwikkelomgevingen het toestaan dat een inconsistent object model van het eindproduct bestaat binnen deze ontwikkelomgeving. In deze opdracht wordt gezocht naar een oplossing waarbij consistentie van het object model gedurende het ontwikkeltraject gehandhaafd blijft. Hiertoe worden Data Dictionary Objecten (DDO) geïntroduceerd Dit zijn objecten die de structuur van de entiteiten in een applicatie omvatten. Deze DDO zorgen voor een consistent object model gedurende het gehele ontwikkeltraject. Het eindproduct van deze opdracht bestaat uit een werkend en getest prototype. Om te komen tot dit eindproduct zijn de volgende stappen genomen: • Keuze van de analyse en ontwerpmethode. Uit een vijftal object georiënteerde methoden is op basis van een checklist een keuze gemaakt voor de methode Object Modelling Technique (OMT). • Op basis van de stappen requirements, analyse, systeemontwerp, detailontwerp is een OMT object model opgesteld. Dit objectmodel bestaat uit vier producten: een statisch model, een functioneel model, een datadictionary en een systeembeschrijving. • Op basis van de eindproducten uit de voorgaande fasen is een prototype van een DDO applicatie. Dit prototype bestaat uit drie onderdelen: een klantapplicatie, een embedded module voor het laden van de DDO toestand in de klantapplicatie en een beheersmodule voor het aanpassen van de DDO toestand. • Op basis van de requirements is een testplan opgesteld. Vervolgens is het prototype getest door een aantal applicatieprogrammeurs. Deze applicatieprogrammeurs hebben het prototype vergeleken met een “traditionele” ontwikkelomgeving en hun bevindingen teruggekoppeld door middel van het invullen van een vragenlijst. • De gevolgde werkwijze, de eindproducten van iedere fase worden ten slotte geëvalueerd Uit het prototype en de tests kan geconcludeerd worden dat het toepassen van DDO in een ontwikkelomgeving voordelen biedt ten opzichte van de werkwijze met een “traditionele” ontwikkelomgeving. Het consistent houden van een object model gedurende een ontwikkeltraject levert een kwalitatief beter eindproduct op. Echter meer onderzoek is nodig naar de verschillende werkwijzen en wensen van applicatieprogrammeurs op het gebied van een consistent objectmodel.

4


1 Probleemstelling De ontwikkelomgevingen, zoals genoemd in de inleiding, voor applicatieprogrammeurs bieden onvoldoende ondersteuning bij het vervaardigen van een kwalitatief eindproduct. Met name consistentie van het object model is een knelpunt. Hierdoor staan onder andere de kwalitatieve aspecten robuustheid en juistheid onder druk. Toepassen van een modelgedreven applicatie ontwikkeling op basis van een data-dictionary kan bovenstaande kwalitatieve aspecten positief beïnvloeden.

1.1 Software ontwikkeling Voor softwareontwikkelingtrajecten past IMN de door haar ontwikkelde drie lagen architectuur (DLA) toe. De IMN drie lagen architectuur is opgebouwd uit de volgende lagen: • De bedrijfslaag, dit beschrijft de veelal stabiele onderdelen van de bedrijfsvoering. Bijvoorbeeld de structuur en het gedrag van de objecten verdachte en zaak in de opsporingstoepassing zijn onderdeel van het bedrijfsmodel. In deze laag zal veelal ook de persistentie van objecten geregeld worden. Hiermee wordt bedoeld de opslag van de Business Object Model (BOM) objecten in gegevensbestanden. • De gebruikerslaag, dit beschrijft de werkprocessen zoals verschillende gebruikers(groepen) kijken naar het bedrijfsmodel. De gebruikerslaag in DLA is de plaats waar de applicatielogica zich bevindt. Dit zijn dan ook de verschillende views overeenkomstig de functionaliteit van de desbetreffende applicatie op het domeinmodel. Een rechercheur heeft bijvoorbeeld een andere manier kijk op het object verdachte als een Officier van Justitie. • De presentatielaag, deze zorgt voor presentatie van de objecten uit de gebruikerslaag aan de gebruiker. Als voorbeeld zijn formulieren, rapporten en invoerschermen te noemen. Als voorbeeld kan het invoerscherm van een verdachte genoemd worden. Het invoerscherm dat gebruikt wordt door rechercheurs is veelal anders dan dat van een Officier van Justitie. Bij het ontwikkelen van software nemen de werkzaamheden van applicatieprogrammeurs een belangrijke plaats in. Met een applicatieprogrammeur wordt bedoeld een persoon werkzaam binnen een software ontwikkelproject die zich bezig houdt met het creëren formulieren, rapporten, menu’s en niet visuele objecten. De applicatieprogrammeur maakt de vertaling van ontwerp naar applicatie. Hierbij wordt met applicatieprogrammeur bedoeld dat het werkveld ligt op het ontwikkelen van applicaties voor eindgebruikers. Applicatie voldoet hierbij aan de kenmerken zoals genoemd in de inleiding. De werkzaamheden van een applicatieprogrammeur veranderen door onder andere de volgende aspecten: • Toepassen van nieuwe ontwikkelprocessen zoals Rapid Application Development (RAD) en ontwikkelstraten. • Toepassen van Object Oriëntatie in zowel analyse, ontwerp als realisatie • Kortere ontwikkelcyclus, waardoor analyse- en ontwerpactiviteiten naar de realisatiefase verplaatst worden. • Toepassen van lagenstructuren zoals de IMN drielagen architectuur De activiteiten van een applicatieprogrammeur kunnen beschouwd worden als het opbouwen en aanpassen van een objectmodel. Dit objectmodel bestaat onder andere uit: • Tabeldefinities en views • Formulieren en rapporten • Besturingselementen en controls • Menu’s en toolbars De momenteel gebruikte ontwikkelomgevingen bieden allen de mogelijkheid om op basis van een gelaagde architectuur een applicatie te bouwen gebaseerd op een objectmodel. Iteratief ontwikkelen, zoals vaak in RAD trajecten toegepast, wordt in deze ontwikkelomgevingen echter slecht ondersteund. In onderstaande voorbeelden worden ter illustratie twee voorbeelden waarom dit het geval is. Aanpassen objectmodel. In het eerste deelsysteem van de opsporingstoepassing is ervoor gekozen de postcode en de woonplaats van een verdachte te combineren tot één attribuut Postcode_plaats. Hiervoor is gekozen omdat dit eenvoudig is bij het opstellen van een proces-verbaal. In een proces-verbaal moet de adressering foutloos zijn. Voordeel van een gecombineerde postcode woonplaats is dat ook in het buitenland woonachtige verdachten juist geadresseerd kunnen worden.

5


In de volgende fase van het ontwikkeltraject wordt het deelsysteem bestuurlijke informatie ontwikkeld. Dit houdt in dat een aantal functionarissen frequenties berekenen ten behoeve van rapportages. Een van de rapportages heeft betrekking op de verdeling van verdachten op woonplaats. Hiertoe moet het gecombineerde attribuut postcode woonplaats gesplitst worden, omdat anders deze optie niet mogelijk is. De ontwikkelaar brengt deze wijziging aan in het bedrijfsmodel. Echter worden de wijzigingen niet aangebracht in het gebruikersmodel en het presentatiemodel van de IMN drie lagen architectuur dan houdt dit in een aantal objecten en associaties inconsistent zijn. In de presentatielaag wordt bijvoorbeeld in formulieren en rapporten verwezen naar het attribuut postcode_woonplaats, dit bestaat echter niet meer maar is gewijzigd in de attributen postcode en woonplaats bestaan immers niet meer. Echter tijdens het aanpassen met behulp van de huidige hulpmiddelen van de ontwikkelaar wordt deze niet geattendeerd op de deze inconsistentie tussen de verschillende objecten. Aanpassen van een attribuut Van iedere zaak geregistreerd in de opsporingstoepassing wordt een dossiercode opgenomen. Deze dossiercode wordt gebruikt voor het onderscheiden van de correspondentie die over deze zaak gevoerd wordt en voor het archiveren van de dossiers. In een eerdere fase is gekozen voor een numerieke dossiercode met een lengte van 5 posities. In de presentatielaag is hiertoe validatie opgenomen zodat de gebruiker ondersteund wordt bij het invoeren van dossiercodes. In een latere fase wordt een deelsysteem ontwikkeld dat gebruikt wordt door Officieren van Justitie. Echter de Officieren werken aan zaken voor meerdere overheidsinstanties. Hierdoor zijn ten eerste vijf posities te weinig voor registratie van de dossiers. Daarnaast is de opzet van een ander informatiesysteem van het ministerie gebaseerd op een code van 10 posities, de eerste twee is een lettercode voor de organisatie, gevolgd door een dossiernummer van 8 cijfers of letters. Gevolg is dat het attribuut aangepast moet worden in iedere laag van de drie lagen architectuur. De bovengenoemde voorbeelden tonen aan dat de actuele gereedschappen van applicatieprogrammeurs (ontwikkelomgevingen) uitstekende hulpmiddel zijn voor het snel ontwikkelen van kantoortoepassingen in één procesgang. Maar het aanbrengen van wijzigingen in een latere fase, wat voorkomt bij RAD trajecten of ontwikkelstraten, kan problemen veroorzaken. Dit ligt in het feit dat bij het aanpassen van het objectmodel geen rekening wordt gehouden met bestaande relaties en afhankelijkheden binnen en tussen objecten. De consistentie van verschillende objecten en hun associaties is hierdoor niet gewaarborgd. Objecten kunnen hierdoor in hun specificatie en implementatie verwijzen naar, door de ontwikkelaar, verwijderde of aangepaste klassen, objecten, associaties of attributen. Met andere woorden de ontwikkelomgeving ondersteunt de applicatieprogrammeur niet bij het behouden van een consistent objectmodel. Hierdoor is het mogelijk dat het eindproduct (de klanttoepassing) incorrect of onvolledig is.

1.2 Opdracht De opdracht kan geformuleerd worden met de volgende stelling: Zoek naar een objectmodel dat de werkzaamheden van een applicatieprogrammeur omvat waardoor de volgende tekortkomingen verminderd c.q. voorkomen kunnen worden: • Ontbreken van integriteit tussen de objecten in de verschillende lagen in het ontwikkelde informatiesysteem. • Onvoldoende bewaken van de consistentie van het objectmodel • Onvoldoende aanpasbaarheid, uitbreidbaarheid van de ontwikkelde informatiesystemen. Hiertoe worden de werkzaamheden geanalyseerd en objecten gemodelleerd en geïmplementeerd. Deze objecten zorgen ervoor dat de toestand van de objecten in een informatiesysteem hoofdzakelijk afkomstig zijn uit gegevensbestanden en niet uit programmacode of binair in de toepassing is opgeslagen. De objecten worden persistent gemaakt. Hierbij zijn met name de toepassingsobjecten belangrijk en de objecten in het Business Object Model (BOM) van de opsporingstoepassing minder. Deze toepassingsobjecten hebben betrekking op alle lagen van de IMN drie lagen architectuur. Het geheel van deze toepassingsobjecten wordt Data Dictionary Objecten (DDO) genoemd. Reden voor deze naam is dat het een data dictionary is van toepassingsobjecten. Het is hierbij van belang twee deelsystemen te onderkennen. Allereerst is er het systeem dat ervoor zorgt dat de opsporingstoepassing gegevensbestanden kan lezen ten behoeve van de objecten in de toepassing. Dit wordt de embedded module genoemd. Daarnaast is er het systeem dat de programmeur ondersteunt bij het aanmaken en aanpassen van de eigenschappen van de objecten in de toepassing. Dit is de beheersmodule. In figuur 1 worden Data Dictionary Objecten getoond in hun relatie met objecten in de toepassing. Voordeel van data dictionary objecten zijn:

6

Data Dictionary Objecten in administratieve toepassingen • • • •

Evolutionair ontwikkelen wordt beter ondersteund omdat de status van objecten aanpasbaar is gedurende het gehele ontwikkeltraject. Het objectmodel is uitbreidbaar, omdat eenvoudig eigenschappen en gedrag toegevoegd kunnen worden aan de gegevensbestanden van de data dictionary, waarbij validatie van de eigenschappen bij opslag mogelijk is. Hergebruik is mogelijk door (delen van) data dictionaries in meerdere applicaties of lagen kunnen worden toegepast. Voor ontwikkelomgevingen die de interne objectstructuur weergeven (reflexief) kunnen data dictionary objecten toegepast worden voor reversed engineering.

Figuur 1 DDO beheersmodule en embedded module in applicatie

1.3 Opzet opdracht De opdracht bestaat uit onderstaande stappen: • Uitvoeren van een literatuuronderzoek waarbij een aantal bestaande analyse- ontwerpmethoden met elkaar worden vergeleken. Op basis van op te stellen criteria wordt uit deze methoden een selectie gemaakt en wordt een raamwerk van het probleem gedefinieerd en hierin worden deze gekozen methoden geplaatst. • Opstellen van criteria waaraan de aangepaste ontwikkelomgeving voor applicatieprogrammeurs (DDO) moet voldoen. • Kiezen van een OO analyse en ontwikkelmethode en met deze methode een analyse maken van het probleemgebied van de werkzaamheden van applicatieprogrammeurs. • Vertalen van de analyse naar een ontwerp gebaseerd op de gekozen OO analyse en ontwerpmethode • Er wordt een kritiek onderdeel van de applicatie gekozen (denk bijvoorbeeld aan de schermgenerator). Hiervan wordt een prototype gebouwd. • Met het ontwikkelde prototype worden een tweetal testapplicaties gebouwd. Allereerst een kleine opsporingsapplicatie en een order invoer systeem. • Er wordt een testplan opgesteld en het prototype wordt voorgelegd aan een aantal applicatieprogrammeurs • Op basis van alle voorgaande stappen wordt de DDO toepassing geëvalueerd.

7


2 Keuze van de analyse- en ontwerp methode In het hoofdstuk probleemstelling is een beschrijving gegeven van de huidige ontwikkelomgevingen en de knelpunten die daarin voorkomen betreffende met name een inconsistent objectmodel. Hierbij kan men de werkzaamheden van een applicatieprogrammeur vanuit een object georiënteerd oogpunt beschouwen. Wordt dit gedaan dan kunnen we van de werkzaamheden en de gebruikte entiteiten of objecten een model op stellen. Wat zijn de objecten die binnen een toepassing worden aangemaakt, aangepast en verwijderd? Vanwege de complexiteit van deze objecten en het model hiervan is het toepassen van een analyse en ontwerp methode noodzakelijk. Hiervoor zijn meerdere methoden beschikbaar. Daarom wordt in deze rapportage een aantal analyse- en ontwerpmethode geëvalueerd en wordt uit de geëvalueerde methoden een keuze gemaakt. De evaluatie bestaat uit een literatuurstudie waarbij een aantal criteria is geformuleerd. Op basis van de beschrijving van de criteria per methode wordt een keuze gemaakt. Deze keuze bestaat uit één van de vijf analysemethoden Als uitgangspunt worden een vijftal methoden genomen. Redenen om deze methoden te kiezen zijn: • Er is voldoende toekomstperspectief voor de methode • Er is een gebruikerspopulatie en er zijn voorbeelden van toepassingen. • Er is voldoende documentatie beschikbaar over de methode •

In de literatuur zijn meerdere vergelijkingen van analysemethoden te vinden. De een is specifiek gericht op een bepaald probleem, de ander is meer generiek van aard. In dit verslag wordt uitgegaan van een vijftal vergelijkende onderzoeken. [2, 6,7,8,29]

In de tabel is een opsomming te vinden van de vijf te onderzoeken analyse- en ontwerpmethoden. Verder is een percentage weergegeven van gebruik van deze methoden in Nederland [27]. Analyse- en ontwerpmethode % gebruik 1998 Coad 11 ISAC 9 OMT (Rumbaugh) 10 OOADA (Booch) 6 OOSE (Jacobson) 5 Tabel 1 Procentueel gebruik van OO methoden in Nederland Omdat ISAC een methode is welke met name gericht is op functionele decompositie en niet gericht is op object oriëntatie wordt deze methode niet uitgewerkt. Daarvoor in de plaats wordt de Unified Modelling Language (UML) onderzocht[6]. Ondanks het feit dat UML is geen methode maar een ontwerptaal wordt de UML toch opgenomen. Reden om de UML op te nemen is de verwachting dat deze taal de komende jaren steeds belangrijker wordt. Op basis van de probleemstelling en het literatuuronderzoek zijn voor de DDO toepassing een aantal criteria te noemen welke een vergelijking tussen de verschillende ontwerpmethoden mogelijk maakt. Op basis van deze criteria worden de methoden in de bijlagen beschreven. Deze beschrijving wordt gebruikt om in de laatste paragraaf een score aan ieder selectiecriterium te geven. Op basis van deze score wordt een keuze gemaakt. De gekozen methode zal gebruikt worden in de volgende fasen van dit project.

8


2.1 Criteria methoden De methoden worden beschreven op basis van onderstaande criteria [2, 6,7,8,29]. Deze punten worden dan ook als paragraafindeling gebruikt voor de te beschrijven methoden. De punten zijn: 1. Historie en toekomstperspectief 2. Projectfasering en methodische werkwijze 3. Modellering 4. Vertaling naar gegevensbestanden 5. Interactie met gebruiker 6. Introductie van lagen en modulen 7. Toepasbaarheid van OO realisatie 1 Historie en toekomstperspectief Als inleiding van de methode wordt een korte beschrijving gegeven van de historie. Daarnaast wordt aangegeven wat het toekomstperspectief is van de methode. 2 Projectfasering en methodische werkwijze Ondersteunt de methode een projectmatige werkwijze. Is er een fasering van activiteiten te onderkennen, welke bijdraagt aan een methodische werkwijze voor de ontwerper. De werkwijze dient de ontwerper te ondersteunen bij het ontwikkelproces middels abstractie. Welke projectfasen worden ondersteund van onderstaande punten. Wat zijn de activiteiten en producten van de afzonderlijke fasen. • Definitie (vooronderzoek) • Analyse • Ontwerp • Realisatie • Testen • Onderhoud 3 Modellering Er kan vanuit meerdere gezichtspunten een model opgesteld worden van de toepassing. Ruwweg zijn deze modellen onder te verdelen in onderstaande gezichtspunten. Van ieder gezichtspunt wordt aangegeven welke onderdelen belangrijk zijn voor de toepassing en welke notatie en semantiek gebruikt wordt. Uitgaan van meerdere gezichtspunten biedt de mogelijkheid de complexiteit van het probleem te reduceren. Dit omdat in ieder model een deelaspect van het probleem beschreven wordt. Modelleren van eigenschappen Modelleren van de eigenschappen oftwel het statisch model. Dit model is belangrijk, omdat met name de eigenschappen van de entiteiten de basis of het uitgangspunt vormen van het te modelleren probleem. De volgende vragen over het statisch model zijn van belang: • Is het mogelijk een statisch model op te stellen en is de notatie eenduidig? • Kunnen eigenschappen of attributen van objecten gemodelleerd worden? • Welke relaties tussen objecten worden onderscheiden en is het mogelijk om details zoals multipliciteit en ordering van relaties aan te geven. Met multiplciteit wordt het minimum en maximum aantal instantiastie van een entiteit bedoeld. • Kunnen aan relaties eigenschappen toegewezen worden? • Kunnen objecten of klassen meerdere rollen vervullen in relaties, is het in het bijzonder mogelijk om aggregaties (whole-part) te definieren. • Is het mogelijk om overerving van eigenschappen en gedrag te modelleren? • Kunnen van eigenschappen meerdere gegevens geregistreerd worden zoals minimum en maximum multipliciteit en beginwaarde? Modelleren van functionaliteit Modelleren van functionaliteit noemen we het functioneel model. In dit model worden de functies of operaties welke de eigenschappen van de objecten bewerken en aanpassen gemodelleerd. De methode dient hier een notatie voor te bieden. De volgende eisen worden gesteld aan het functioneel model:

9


Kunnen operaties gedefinieerd worden en is het mogelijk om van een operatie aan te geven wat de parameters en de return waarde is? Is het mogelijk een functioneel model op te stellen en is de notatie eenduidig? Is het mogelijk de relatie tussen objecten, operaties en gebruikers te modeleren? Is het mogelijk om eigenschappen en of gegevens in het functioneel model te beschrijven?

Modelleren van gedrag Modelleren van gedrag oftewel het dynamisch model. Het dynamisch model is voor data dictionary objecten minder belangrijk,. Bij data dictionary objecten is gedrag nauwelijks te onderkennen. Alleen bij de presentatie is gedrag te onderkennen, zoals bijvoorbeeld gebruiker drukt op opdrachtknop. Echter dit gedrag is algemeen van aard, zoals het aanpassen van eigenschappen van objecten. Dit kan goed gemodelleerd worden in het functioneel model. Er worden de volgende globale eisen gesteld aan dit model. • Is het mogelijk een dynamisch model op te stellen en is de notatie eenduidig? • Is het mogelijk om de toestand van objecten te beschrijven • Is het mogelijk om gebeurtenissen die de toestand van objecten verandert te beschrijven • Biedt de methode de mogelijkheid om volgtijdelijkheid van gebeurtenissen te beschrijven Relatie tussen de modellen Omdat er vanuit meerdere views gekeken wordt naar de toepassing is het belangrijk dat de relatie tussen de views duidelijk is. Met name bij geautomatiseerd modelleren dient er cohesie te zijn tussen de verschillende modellen. De methode dient hiervoor mogelijkheden te bieden. 4 Vertalen naar gegevensbestanden De kern van de oplossing van het probleem is gebaseerd op de opslag van objecten in gegevensbestanden. De ontwerpmethode dient aandacht te besteden aan aspecten die hierbij een rol spelen. Daarom dient de methode de ontwerper te ondersteunen bij het opslaan van de objecten in gegevensbestanden middels een beschrijving van de relevante aspecten van deze actie. Op basis van het type opslag (OO database, relationele database) zal dit aspect meer of minder belangrijk zijn. In OO databases omvat de vertaling minder beslispunten ten opzichte van relationele bestanden. 5 Interactie met de gebruiker Naast interactie met gegevensbestanden is ook interactie met de gebruiker (applicatieprogrammeur) belangrijk. Bijvoorbeeld hoe wordt de toestand van een object en haar eigenschappen gepresenteerd aan de gebruiker, welke interface naar de gebruiker wordt toegepast. Wordt er in de methode een beschrijving gegeven van aspecten van Mens Machine Interface. 6 Introductie van lagen en modulen De DDO toepassing is complex van aard. Het aantal objecten, attributen en associaties is groot. De analyse- en ontwerp methode dient daarom te beschrijven welke stappen ondernomen kunnen worden om de toepassing te splitsen in lagen en modulen. Hierdoor kan worden aangesloten op de drie lagen architectuur van IMN. De complexiteit wordt hierdoor beter beheersbaar. 7 Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie Biedt de methode mogelijkheden om tijdens de realisatie met OO/RAD ontwikkelhulpmiddelen [29] te werken. Kunnen de opgestelde modellen op eenvoudige wijze vertaald worden naar object georiënteerde programma code? Is het verder mogelijk om met hulpmiddelen modellen en systeemdocumentatie te genereren? Zijn deze hulpmiddelen beschikbaar of kunnen de modellen met generieke hulpmiddelen ontwikkeld worden? 8 Toepassen deelmodel Ter verduidelijking van de methoden wordt een relevant deelsysteem van de te ontwikkelen toepassing als voorbeeld genomen. Dit voorbeeld wordt gebruikt om met name het statisch model van de analyse- en ontwerpmethode te testen voor het toepassingsgebied data dictionary objecten. Hiertoe wordt een beschrijving gegeven van de activiteit formulieren maken om de gegevens van een verdachte weer te geven.,Dit is een essentieel onderdeel van de opsporingstoepassing. Hierbij wordt uitgegaan van de drielagenarchitectuur zoals beschreven in de probleemstelling. In onderstaande paragraaf wordt een beschrijving gegeven in natuurlijke taal van deze activiteit.

10


Tijdens het ontwikkelen van een applicatie worden formulieren gebruikt voor weergave van een verdachte. Deze formulieren moeten aangemaakt, gewijzigd en verwijderd kunnen worden door de applicatieprogrammeur. Als de applicatieprogrammeur een nieuw formulier maakt dan is het uitgangspunt een leeg formulier. Allereerst wordt aan het formulier een naam en een titel gegeven. Vervolgens wordt een verdachte object gekoppeld aan het formulier. Van de verdachte worden een aantal attributen beschreven, zoals naam, bijnaam, adres en woonplaats. Attributen zijn van het type: datum, karakter, memo, numeriek of logisch. Verder heeft de inhoud van attributen een bepaalde lengte Bij het aanmaken van een formulier moet een keuze gemaakt worden tussen gegevensbladweergave en formulierweergave. Bij een formulierveld worden besturingselementen op het formulier geplaatst. Er zijn meerdere soorten besturingselementen zoals: Invoervak, Keuzelijst, Keuzelijst met invoervak, vaste tekst en diverse kaders. De laatste twee soorten zijn te beschouwen als opmaakelementen, de overige als invoerelementen. De invoerelementen worden gekoppeld aan een veld in de tabel en geeft de inhoud van dit veld weer. Bij het opmaken van formulieren wordt gebruikt gemaakt van een layoutfunctie. Deze functie ondersteunt de programmeur bij het plaatsen van de besturingselementen op het scherm. De besturingselemeneten hebben een positie op het formulier en zijn van een bepaalde grootte. Op basis van het type van een attribuut wordt een keuze gemaakt uit een van de invoerelementen. Als laatste is de tabvolgorde belangrijk van het formulier. Dit is de volgorde waarin de besturingselementen op het formulier op het scherm geplaatst zijn. Tenslotte test de programmeur het aangemaakt formulier. In de bijlagen worden de methoden volgens bovenstaande indeling beschreven. Dit is te vinden in de volgende bijlagen: • Booch OOAD (bijlage 1) • Rumbaugh OMT (bijlage 2) • Jacobson (OOSE) (bijlage 3) • Coad & Yourdon OOA/OOD (bijlage 4) • UML (bijlage 5)

2.2 Score van methoden Op basis van de bovenstaande beschrijvingen is het mogelijk een score te geven van de afzonderlijke methode. Omdat het aangeven van een wegingsfactor moeilijk is wordt gekozen voor de volgende indeling: + positief, +/- neutraal, - negatief OOA DA +/+ +/_ +

Historie en toekomstperspectief Projectfasering en methodische werkwijze Modellering Vertalen naar gegevensbestanden Interactie met de gebruiker Introductie van lagen en modulen Toepasbaarheid voor geautomatiseerde OO realisatie Tabel 2 Score van OO methoden

OMT +/+ + + +/+ +

OO SE +/+ + + +/+

Co ad + +/+ + + +

UML + +/+

Zoals blijkt uit de score ontlopen de methoden elkaar niet veel. De UML scoort in verhouding laag omdat de Unified Modelling Process (UMP) nog niet beschikbaar is. Op basis van de score tabel wordt gekozen voor OMT. We kunnen hierbij vermelden is dat OMT op basis van de aanpassingen van Blaha en Premerlani [3]wordt gebruikt. Belangrijkse redenen om te kiezen voor OMT zijn: • De notatiewijze van met name het statische model is uitgebreid en met name op het vlak van eigenschapmodellering compleet te noemen. • De methode bestaat uit een aantal duidelijk omschreven stappen hoe tot een object model gekomen kan worden • De methode biedt ondersteuning bij het vertalen naar gegevensbestanden in de vorm van een stappenplan, suggesties en voorbeelden. • De methode biedt ondersteuning bij het opstellen van een gebruikersinterface. In de volgende hoofdstukken wordt het DDO probleem uitgewerkt op basis van de methodische werkwijze van OMT. De hoofdstukindeling is gebaseerd op de stappen in deze methode. Voor het functionele model wordt

11


gebruik gemaakt van een toevoeging uit de methode OOSE [16], te weten de use cases. Daarnaast wordt gebruik gemaakt van het principe van sjablonen zoals die door OOADA [5] geintroduceerd zijn.

12


3 Requirements In de probleemstelling is een beschrijving gegeven van de problemen welke applicatieprogrammeurs kunnen verwachten indien zij werken volgens een evolutionaire ontwikkelmethode met de huidige ontwikkelomgevingen. Er wordt hierbij een scheiding aangebracht tussen twee onderdelen te weten: • Beheersmodule, voor het beheren en bewerken van de metagegevens. Het aangepaste gereedschap van de applicatieprogrammeur • Embedded module voor het lezen en koppelen van de metagegevens in een klantapplicatie, zoals de opsporingsapplicatie. Aan de hand van een vragenlijst wordt aangegeven welke aspecten belangrijk zijn [3]. Hierbij dient onderkend te worden dat onderstaande lijst iteratief is samengesteld. Na iedere fase in het ontwikkelproces is gekeken of er criteria ontbreken of aangepast dienen te worden. Dit geldt met name voor de kwantitatieve criteria. Deze zijn in een vroeg stadium gebaseerd op schattingen. In een later stadium is een aantal eenvoudige tests uitgevoerd. In dit hoofdstuk worden de embedded module en beheersmodule als aparte toepassingen beschreven. Voor achtergrondinformatie over het probleem en de te ontwikkelen toepassing wordt verwezen naar het hoofdstuk "Probleemstelling".

3.1 Requirements beheersmodule Voor wie is de beheersmodule? De beheersmodule wordt gebruikt door applicatieprogrammeurs betrokken bij de ontwikkeling van MS Windows programmatuur volgens een iteratieve werkwijze. Hierbij beperken we ons tot de automatisering van administratieve processen waarbij opslag van gegevens een belangrijke component is. Welk probleem zal de beheersmodule oplossen? De huidige werkwijze kent een aantal knelpunten, waardoor het ontwikkeltraject niet optimaal is. Dit geldt voor zowel ontwikkeltijd als kwaliteit van het geleverde eindproduct. De toepassing levert een bijdrage aan de optimalisatie van het ontwikkelproces waarbij het belangrijkste aspect is dat de visuele editors geïntegreerd worden. In onderstaande opsomming worden de belangrijkste eisen genoemd. Hierbij wordt een onderscheid tussen kwantitatieve- en kwalitatieve aspecten. • Ondersteunen van evolutionaire ontwerpmethode. • Ontwikkeltijd voor klantapplicaties dient 10% sneller te zijn ten opzichte van de huidige werkwijze • De opgeleverde klantapplicaties dienen 20% minder fouten te bevatten op het werkveld van applicatieprogrammeurs. Te denken valt aan formulierdefinitie, selecties en queries, tabeldefinitie en rapportage. • Hergebruik van gegevensbestanden dient eenvoudig mogelijk te zijn in 10% van de projecten. • Integriteit moet gehandhaafd blijven bij het verwijderen en toevoegen van eigenschappen van alle entiteiten. • De beheersmodule biedt een gebruikersinterface welke de werkzaamheden op een logische wijze concentreert, zodat de arbeidsproductiviteit stijgt. • De applicatieprogrammeur kan eenvoudiger zoeken en selecteren naar de diverse entiteiten. • Het aanmaken van formulieren voor klantapplicaties is verbeterd ten opzichte van de huidige werkwijze. Dit betekent dat de volgorde van besturingselementen door de programmeur in een procesgang bepaald wordt. • Het veranderen van het type besturingselement (bijvoorbeeld van invoervak naar keuzelijst) dient in een procesgang mogelijk te zijn. • Tijdens het opmaken van formulieren dient een de programmeur inzicht te hebben in de besturingselementen in gebruik • Voor complexe activiteiten dient de beheersmodule ondersteuning te bieden op het gebied van MMI. Waar wordt de beheersmodule gebruikt? De beheersmodule wordt gebruikt binnen automatiseringsafdelingen als onderdeel van de totale ontwikkelinfrastructuur. Daarnaast kan de toepassing bij klanten op locatie toegepast worden, zodat in sessies met de klant (expert) wijzigingen gemaakt kunnen worden aan de klantspecifieke programmatuur. Wanneer is de beheersmodule nodig? De beheersmodule is op korte termijn nodig. Op dit moment is de vraag naar MS Windows toepassingen erg groot waardoor de druk op het ontwikkelteam groot is. Als de ontwikkeltrajecten korter worden heeft dit een positief effect op de werkdruk.

13


Waarom is de beheersmodule nodig? De beheersmodule is nodig omdat met de huidige het opgeleverde eindproduct te veel fouten bevat. Hierdoor kan een ontwikkeltraject langer duren dan noodzakelijk is omdat fouten in een later stadium opgelost moeten worden. Hoe werkt de beheersmodule toepassing? In de DDO toepassing worden eigenschappen en operaties van de entiteiten zoals formulieren en tabeldefinities opgeslagen in gegevensbestanden. Door het werken met gegevensbestanden zijn de ontwikkelwerkzaamheden meer administratief van aard en is het valideren van eigenschappen eenvoudiger te realiseren.

3.2 Requirements embedded module Voor wie is de embedded module? De embedded module is ingebed in de applicaties geïnstalleerd bij klanten van de gebruikers van de beheersmodule. Dit houdt in dat het voor de klant een onzichtbaar onderdeel is van de toepassing. Welke problemen zal de embedded module oplossen? Door het toepassen van een evolutionaire werkwijze is het voortraject van applicaties, de analyse en het ontwerp relatief kort, met name als gebruik gemaakt wordt van RAD. Deze activiteiten zijn meer geïntegreerd in de realisatie van het prototype. Dit heeft tot gevolg dat het realisatietraject veelal langer is en meer geintegreerd met de voorgaande fasen. Tijdens dit realisatietraject worden regelmatig aanpassingen aangebracht aan de structuur van het object model. In onderstaande opsomming worden de belangrijkste eisen genoemd: • Opstarten van een applicatie dient even snel (of sneller) te zijn als in de huidige situatie • Omvang van een bestand met wijzigingen dient minstens 4 keer kleiner te worden. Hierbij kunnen we de 2080 regel toepassen. Hierbij wordt bedoeld dat slechts 20% van de eigenschappen aan veranderingen onderhevig is. • Wijzigingen aanbrengen op afstand dient mogelijk te zijn. • Fysieke bestandsstructuren moeten vergeleken kunnen worden met de structuren in de DDO of metagegevensbestanden. Als er een verschil is moet de fysieke structuur worden aangepast aan het model in de metagegevens. Waar wordt de embedded module gebruikt? De embedded module wordt gebruikt als onderdeel van de uiteindelijke toepassing bestemd voor eindgebruikers. Denk bijvoorbeeld aan de opsporingstoepassing zoals deze door rechercheurs gebruikt wordt. Wanneer is de embedded module nodig? De embedded module wordt geïmplementeerd op het moment dat het volledig gebouwd en getest is. Het is daarnaast afhankelijk van de ontwikkeling van de beheersmodule. Zonder beheersmodule zijn er vanzelfsprekende geen metabestanden beschikbaar en kan de embedded module niet uitgewerkt worden. Waarom is de embedded module nodig? Bij de huidige ontwikkelomgevingen is onvoldoende controle aanwezig waardoor het maken van fouten in klantapplicaties (opsporingsapplicatie) relatief eenvoudig is. Deze embedded module zorgt voor de koppeling tussen klantapplicatie en de bestanden aangemaakt met de hierboven beschreven beheersmodule. Hoe werkt de embedded module? De klantapplicatie is een framework opgebouwd uit generieke objecten en een aantal gegevensbestanden. In deze gegevensbestanden zijn de klantspecifieke toepassingseigenschappen opgeslagen. Bij het opstarten van de applicatie worden de gegevensbestanden geladen in een aantal containers. Een container bevat daarna de verschillende objecten van een klasse. Containers dienen met name voor de navigatie tussen verschillende objecten en toegang tot de eigenschappen van een klasse. Deze containers bepalen wat de structuur van de uiteindelijke productieklassen is [18]. Onder productieklassen wordt verstaan de klassen die het gedrag en de toestand van het Business Object Model van de klantapplicatie bepalen.

3.3 Toepassen requirements Door het uitwerken van de requirements op basis van een sjabloon van vragen is de uitwerking van de requirements belangrijk voor de volgende fasen in dit project. Onderstaande opsomming geeft aan hoe de requirements gebruikt kan worden in de vervolgfasen:

14


Analyse, de genoemde punten geeft aan wat de scheiding is tussen de twee toepassingen en welke eigenschappen belangrijk zijn. Ontwerp, de requirements biedt informatie voor het nemen van beslissingen over de verdeling van de functionaliteit over toepassingen. Realisatie, er wordt aangegeven welke punten van belang zijn tijdens de realisatie. Daarnaast wordt aangegeven wat de kwaliteitseisen van de te ontwikkelen toepassing zijn. Testen, omdat een aantal eisen in de requirements gekwantificeerd zijn kan tijdens het testen gecontroleerd worden of aan de opgestelde eisen voldaan is.

Samenvattend kan gesteld worden dat de requirements resulteert in een checklist voor de vervolgfasen In iedere fase wordt bepaald hoe de checklist er voor de volgende fasen uitziet. Deze bijgestelde checklist geldt vervolgens als uitgangspunt.

15


4 Analyse In de requirements fase is een lijst van eisen opgesteld voor de te ontwikkelen toepassing. In de analysefase van OMT worden een aantal stappen onderscheiden waarmee men tot een aantal modellen komt. Dit zijn in totaal 14 stappen [3]. De stappen zijn weergegeven als paragrafen, de substappen zijn met een kop in vet aangegeven. De iteratieve stappen om te komen tot een model zijn gecombineerd in deze verslaglegging. Daarnaast wordt van alle klassen een deel gerepresenteerd in de tabellen. Als voorbeeld zijn in alle tabellen de klassen veld en tabel uitgewerkt. Dit om de leesbaarheid te vergroten. In bijlage 8 met de data-dictionary is een gedetailleerde beschrijving van alle klassen gegeven.

4.1 Probleembeschrijving Met de probleembeschrijving wil ik een beeld geven welke activiteiten en aspecten de werkzaamheden van een RAD applicatieprogrammeur bepalen. Het werk van een applicatieprogrammeur is complex en veelomvattend, daarom wordt een samenvattende opsomming gegeven. Als uitgangspunt is de Getting started guide van Visual Objects gebruikt. Voor deze bron is gekozen omdat het een samenvattend en stapsgewijs beeld geeft van de ontwikkeling van toepassingen relevant voor deze opdracht. Daarnaast geeft het een compleet beeld van de werkzaamheden. Echter ook in andere ontwikkelomgevingen zullen deze activiteiten terug te vinden zijn, waarbij mogelijk de volgorde van stappen afwijkend is. • Vanuit de repository wordt een nieuwe applicatie gegenereerd met de applicatie wizard. Deze applicatie bestaat uit een applicatie object, een MDI shellwindow en een applicatie menu. • Er worden eventueel class libraries gekoppeld aan de gegenereerde applicatie en deze wordt gecompileerd. • Het Business Object Model van de klantapplicatie wordt vertaald in een gegevensstructuur. Deze gegevensstructuur bestaat uit een aantal tabeldefinities. • Tabeldefinities worden gemaakt met de DbServer- of SQLTable editor. Dit zijn visuele editors in de IDE. • Een tabeldefinitie bestaat uit de definitie van de eigenschappen van de velden of kolommen in de tabel. Met de fieldspec editor in de IDE worden deze beschrijvingen aangemaakt. • Eventueel worden er index definities aangemaakt in de DbServer editor. Deze indexdefinities bieden de eindgebruiker in de applicatie de mogelijk om gegevens op te zoeken. • Is de tabeldefinitie opgezet dan worden de formulieren welke de gegevens presenteren aangemaakt. Dit wordt vanuit de IDE gedaan met een formulier-painter. Deze painter bevat veelal mogelijkheden om de diverse entiteiten en eigenschappen via directe manipulatie aan te passen. • Formulieren bestaan uit een aantal standaard componenten zoals een titelbalk, een menu en eventueel een knoppenbalk. Een knoppenbalk wordt afgeleid van de opties aanwezig in het menu. Formulieren kunnen op twee manieren de gegevens weergeven in gegevensblad- en formulierweergave. • Op een formulier in formulierweergave worden besturingselementen geplaatst. Deze besturingselementen worden gekoppeld aan de veld- of kolomdefinities in de tabel. Besturingslementen zijn onder andere tekstvakken, labels, keuzelijsten, keuzelijsten met invoervak en keuzerondjes. In gegevensbladweergave zijn een aantal kolommen te onderscheiden. Een kolom kan de inhoud van een veld of een afgeleide of berekening van een aantal velden weergeven • Er worden specifieke eigenschappen voor de klanttoepassing gedefinieerd, bijvoorbeeld selectiemogelijkheden, filters of queries. Dit wordt gedaan door het intikken van programma code in de sourcecode editor van de IDE. • Met de IDE menueditor worden menu's aangemaakt. De entiteiten in een menu beschrijven veelal operaties in een formulier. Een menu is dan ook altijd gekoppeld aan een formulier • Aan het MDI shellwindow wordt een menu gekoppeld dat ervoor zorgt de verschillende formulieren geopend kunnen worden. • In een aantal iteratiestappen worden de bovengenoemde entiteiten aangepast en verbeterd totdat een resultaat bereikt wordt dat door de klant geaccepteerd wordt. Vanuit deze beschrijving en de gedetailleerde beschrijving in de getting started guide kunnen de modellen uitgewerkt worden. Dit is beschreven in onderstaande paragrafen.

4.2 Object Model Kiezen en verwijderen van klassen In deze stap wordt een lijst gemaakt van mogelijke klassen voor het te ontwikkelen informatiesysteem. Deze lijst is iteratief opgesteld. Echter in dit verslag is alleen het eindresultaat opgenomen. Deze activiteit resulteert in een lijst van klassen. In de eerste kolom ziet u deze lijst In de laatste kolom wordt aangegeven of de klasse relevant is voor het DDO project.

16


Klassenaam Repository Applicatie Tabel Besturingselement Formulier Statistiek Filter/Selectie Menu Menueditor Veld DbServer editor SQLtable editor Formulier painter Index Sourcecode editor Relatie Kolom Formulier painter Tabblad

DDO Nee Nee JA JA JA JA JA JA Nee JA JA JA JA JA Nee JA JA JA JA

Tabel 3 Klassen overzicht Kiezen en verwijderen van relaties In deze fase worden de associaties tussen de verschillende klassen in DDO weergegeven. In deze toepassing is naast de reguliere relaties met name aggregatie belangrijk. Als soort relatie wordt deze dan ook expliciet opgenomen soorten relaties belangrijk, te weten: Klassenaam Index Veld Relatie Selectiestap Statistiekstap Tabblad Veld Formulier Besturingselement Kolom (gegevensblad) Menu Menu Formulier Relatie Relatie Selectie Statistiek

Relatie met Tabel Tabel Tabel Tabel Tabel Formulier Tabel Tabel Veld Veld Formulier Knoppenbalk Besturingselement Index Veld Veld Veld

Soort relatie Aggregatie Aggregatie Aggregatie Aggregatie Aggregatie Geeft weer Aggregatie Toont inhoud van Toont Toont Toont functies van Verkort weergegeven op Aggregatie Sorteert kind Koppel ouder Bepaling op basis van Berekening op basis van

Tabel 4 Relatie tussen klassen Kiezen en verwijderen van attributen In deze stap wordt een lijst van attributen of eigenschappen gegeven van een aantal klassen. Deze lijst is in deze fase summier van opzet. Deze lijst is een uitgangspunt voor het objectmodel. De detaillering vindt plaats tijdens de ontwerpfase. Daarom wordt in deze tabel alleen de naam van de eigenschap gegeven. In deze lijst worden alleen de klassen beschreven die op basis van de relatie eigendom voorkomen. De klassen gerelateerd op basis van overerving zullen in een later stadium beschreven worden. Klassenaam Veld

Eigenschap Naam Titel Omschrijving Inhoudtype Inhoudlengte Inhouddecimalen Gekoppelde tabelnaam

Gekoppelde Keuzelijst Vereist Beginwaarde expressie Berekende waarde expressie Samenvoeg expressie Voorkeur besturingselement Invoermasker

Tabel 5 Eigenschappen van tussen klassen

17

Klassenaam Tabel

Eigenschap Naam Titel Omschrijving Extensie

Bestandstype Keuzelijst expressie Oudersleutel naam Primaire sleutel


Verifieer model In deze fase worden een aantal stappen beschreven van het OMT analyse proces. Op basis van de tabellen in bovenstaande paragrafen is een model op te stellen in de OMT notatie. Omdat het model omvangrijk is wordt hierbij een splitsing gemaakt in een aantal deelmodellen of sheets. (bijlage 6) Daarnaast worden de eigenschappen en operaties niet in de objectdiagrammen opgenomen. Dit allereerst vanwege de beperkte ruimte in de diagrammen. Ten tweede worden de eigenschappen van klassen in de datadictionary in detail uitgewerkt. Het model wordt geverifieerd met onderstaande tests. Bij codeselectie wordt een lijst van keuzes getoond Selectie gebaseerd op codes, bijvoorbeeld branchecode en omschrijving. Is dit mogelijk via de associaties? • Codeselectie overerft de eigenschappen van selectiestap • Selectiestap gebruikt veld • Veld gebruikt keuzeopties. Verwijderen van een veld

Als een veld wordt verwijderd dient vooraf gecontroleerd te worden of dit veld nog voorkomt in indexen, relaties en formulieren. • Veld wordt gebruikt door Tabel • Index wordt gebruikt door Tabel en heeft een eigenschap expressie met veldinformatie • Relatie wordt gebruikt door Tabel en heeft de eigenschap sleutelveld • Formulier wordt gebruikt door Tabel, Besturingselement wordt gebruikt door Formulier. Besturingselement gebruikt Veld.

Tabel 6 Verifieer model

4.3 Data-dictionary Keuze van werkwijze De data-dictionary definieert alle te modelleren entiteiten zoals klassen, relaties, eigenschappen en operaties. [3]. Voor het opstellen van de data-dictionary zijn een aantal mogelijkheden beschikbaar. De belangrijkste zijn: Natuurlijke tekst met een standaardisatie van namen. Bijvoorbeeld eigenschappen met een datum waarde worden met date of datum aangeduid]. Een template of sjabloon zoals in de OOADA methode gebruikt wordt. In dit sjabloon worden de te modelleren entiteiten in het vooraf gedefinieerde sjabloon omschreven [5, 29]. Uitgaande van onderstaande punten wordt gekozen voor de werkwijze zoals in OOADA deze toepast: • Een sjabloon ondersteunt de gebruiker, het geeft een beeld van de compleetheid van het ontwerp. • Een sjabloon is dwingend, in vrije tekst is de omschrijving van een entiteit te vrij. • Een sjabloon kan eenvoudig geautomatiseerd worden. Daarnaast kan in de volgende fasen gebruik gemaakt worden van de reeds ingevulde sjablonen. Bijvoorbeeld in de realisatie van uitgewerkte klasse en eigenschap sjablonen. In de volgende fasen zal gebruik gemaakt worden van een geautomatiseerde data-dictionary. Deze datadictionary is opgesteld op basis van een aantal gerelateerde gegevensbestanden. Redenen zijn [29]: • De mogelijkheid om invoer te valideren • Het genereren van meerdere soorten van documentatie.

18

Data Dictionary Objecten in administratieve toepassingen •

Het genereren van programma code tijdens de realisatiefase.

Opstellen van de dictionary Op basis van de class templates zoals gebruikt door Booch is het volgende model opgesteld voor de datadictionary [29]. In bijlage 8 is een overzicht van de uitgewerkte klassen te vinden op basis van de datadictionary. Naam

Eigenschap

Toelichting

Klasse

Naam Inherit van

Naam van de klasse Erft alle eigenschappen en operaties van de klasse genoemd in deze eigenschap Omschrijving van de bestaansreden van de klasse Naam van de eigenschap Omschrijving van de eigenschap Initiële waarde als een nieuw object gecreëerd wordt van deze klasse Minimum aantal elementen van deze eigenschap in de klasse Maximum aantal elementen van deze eigenschap in de klasse Waarde van de inhoud van de eigenschap er zijn een aantal mogelijkheden te weten: Array, String, Object, Expressie, Datum, Integer, Logisch en Onbekend Hierbij zijn twee mogelijkheden te onderscheiden er wordt een lijst van vaste waarden opgegeven waarbij de lijst wordt weergegeven gescheiden door een komma. Met pseudo code wordt een dynamische lijst van gegevens omschreven Eigenschappen of attributen zijn op drie manieren zichtbaar: Verborgen De eigenschap is alleen zichtbaar in de klasse zelf, dus in de overervende klassen is de eigenschap niet zichtbaar Protectie. De eigenschap is alleen zichtbaar in de klasse en in alle overervende klassen, of via een methode welke een validatie mogelijk maakt Export De eigenschap is altijd zichtbaar, ook buiten de overervingboom om Naam van de operatie Komt voor in applicatie onderdeel: Beheersmodule / Embedded module

Eigenschap

Omschrijving Naam Omschrijving Beginwaarde Minimum cardinaliteit Maximum cardinaliteit Waarde van de inhoud

Mogelijke waarden

Zichtbaarheid

Operatie

Naam Onderdeel

19


Associatie

Pseudocode Parameters Returnwaarde Gekoppelde klasse Naam associatie Min. Cardinaliteit Klasse Max. cardinaliteit Klasse Min. Card. Gekoppelde Klasse Max. card. Gekoppelde Klasse

/Beiden Pseudo code van de bewerkingen in de operatie Lijst van inkomende parameters welke door de operatie gebruikt wordt Uitgaande parameters of return waarde van de operatie. Naam van de klasse waarmee een associatie bestaat Naam of omschrijving associatie Minimaal aantal elementen van de actieve klasse in de associatie Maximum aantal elementen van de actieve klasse in de associatie Minimaal aantal elementen van de geassocieerde klasse Maximum aantal elementen van de gerelateerde klasse in de relatie

Tabel 7 Toelichting op eigenschappen in Class diagram

4.3 Functioneel Model Specificeer "Use cases" In deze stap wordt een lijst van "use cases" opgesteld. Een Use case kan het beste vertaald worden met “een gebruikers situatie” [16]. Dit wordt gedaan om de verschillende vormen van interactie tussen het systeem en externe actoren weer te geven. In deze toepassing zijn twee externe actoren te onderscheiden, de applicatie programmeurs voor de beheersmodule en de klantapplicatie (opsporingstoepassing) voor de embedded module [19]. Embedded module • Opvragen van alle afzonderlijke klassen vanuit bestand • Opmaken formulieren op basis van DDO • Controleer fysieke bestandstructuur ten opzichte van DDO Beheersmodule • Toevoegen in alle klassen • Bewerken van alle klassen • Verwijderen in alle klassen • Afdrukken in alle klassen • Opmaken formulieren • Toevoegen van besturingselementen op formulieren • Verwijderen van besturingselementen op formulieren • Bewerken van besturingselementen op formulieren • Verplaatsen van besturingselementen op formulieren • Tabvolgorde aanpassen van besturingselementen • Testen van opgemaakte formulieren • Zoeken van gegevens in alle klassen • Selecteren of filteren van gegevens in alle klassen • Vervangen van gegevens in alle klassen Kiezen van functioneel paradigma In deze fase wordt een keuze gemaakt voor het functioneel paradigma. Hiermee wordt het gedrag van de diverse objecten beschreven [3]. Relevante paradigma's zijn: Data flow diagrammen Voordeel van deze diagrammen is dat ze veelvuldig toegepast worden, en daarom bekend zijn. Nadeel is dat het te dicht bij de realisatie van toepassingen zit. Het kan gebruikt worden als een specificatie en niet als analyse instrument. Beslissingstabellen Beslissingstabellen zijn goed toepasbaar bij keuzeprincipes zoals if-then constructies. Echter voor andere selectie principes en iteraties worden beslissingstabellen snel complex en onoverzichtelijk. Pseudocode Pseudocode heeft als voordeel dat het eenvoudig te gebruiken is en dat gebruikt kan worden in latere fase van het ontwikkeltraject. Groot gevaar (en nadeel) is echter dat te snel op implementatieniveau gewerkt gaat worden.

20


Specificeer operaties Ondanks de beperkingen van pseudocode wordt toch gekozen voor dit paradigma. Om de beperkingen te ondervangen wordt een programmeertaal onafhankelijke pseudocode gebruikt welke bestaat uit de onderdelen zoals genoemd in bijlage 9. In bijlage 8 is een overzicht van de data-dictionary gegeven welke eveneens het functioneel model beschrijft.

4.4 Dynamisch model Voor het beschrijven van het gedrag van de objecten op basis van events of gebeurtenissen met name vanuit de omgeving wordt een dynamisch model opgesteld. In de OMT methode wordt dit opgelost met Event trace diagrammen en State Transition Diagrammen Voor administratieve toepassingen wordt dit als minder belangrijk ervaren. Bijvoorbeeld in de beheersmodule is het mogelijk de gebruikers interface op een dynamische wijze te modelleren. Echter de bijdrage van een dynamisch model levert geen bijdrage aan het in kaart brengen van het probleemgebied. Het dynamische gedrag van de gebruikersinterface wordt in belangrijke mate bepaald door het standaard gedrag van de MS-Windows interface. Specifiek gedrag van bijvoorbeeld opdrachtknoppen is in het functioneel model uit te werken. Voor de embedded module kan het dynamisch model wel een bijdrage leveren aan de probleeminventarisatie. Hier is een aantal duidelijke events te onderscheiden welke voor de werking van de toepassing belangrijk zijn. Optimaliseren van deze events in gedrag en interactie kan de werking in consistentie en snelheid verbeteren. Daarom worden een tweetal interactie diagrammen opgesteld. Hierbij wordt gebruik gemaakt van de event trace diagrammen van de OMT methode. Voor deze diagrammen is gekozen om de volgende redenen: • Het geeft duidelijk weer wat de gebeurtenissen (events) zijn. • Het is mogelijk de volgorde in tijd aan te geven • Het is mogelijk objecten als vragende- en als biedende entiteiten te onderscheiden middels pijlen. In bijlage 7 worden modellen weergegeven voor het opvragen van de DDO gegevens en voor het openen van formulieren in de embedded module.

4.5 Tot slot In deze rapportage is de analyse weergegeven van de toepassing van data dictionary objecten. De rapportage bestaat uit een beschrijving van de ondernomen stappen om tot een viertal eindproducten te komen, te weten: • Object model • Functioneel model • Data-dictionary • Dynamisch model Deze modellen vormen het uitgangspunt voor de discussie over de data dictionary objecten. In deze discussie dienen een aantal vragen beantwoord te worden. De belangrijkste vragen zijn • Is het toepassen van data dictionary objecten een werkwijze welke een oplossing biedt voor het gestelde probleem • Kunnen data dictionary objecten in de huidige opzet gerealiseerd worden. Worden beide vragen positief beantwoord dan kan in de ontwerpfase een verdere detaillering plaatsvinden en kan begonnen worden met de realisatie van de toepassing. Is het niet mogelijk om de vragen positief te beantwoorden dan dient een beslissing genomen te worden over aanpassen van het model of beëindigen van dit project.

21


5 Systeemontwerp In het voorgaande hoofdstuk over de analyse fase, is beschreven wat gemaakt moet worden. In de systeemontwerpfase wordt een beschrijving gegeven hoe het gemaakt moet worden. Hierbij wordt uitgegaan van het OMT stappenplan. Voor dit project zijn een aantal van de OMT stappen gecombineerd, reden hiervoor is dat een aantal stappen minder relevant zijn voor dit project. Denk hierbij bijvoorbeeld aan het ontwikkelen in programmeerteams en het kiezen van een database paradigma. De volgende stappen worden onderkend in het systeemontwerp: • Selecteren van een architectuur • Omgevingsinteractie • Data management • Mogelijkheden voor hergebruik • Strategie voor data interactie • Aspecten voor detail ontwerp In het systeemontwerp is het tijdens een aantal stappen belangrijk de scheiding aan te brengen tussen de beheersmodule en de embedded module. Hiermee wordt bedoeld dat de beheersmodule een applicatie is welke de gegevens van de Data dictionary Objecten (DDO) beheerd en bewerkt. De embedded module zorgt ervoor dat de gegevens worden ingelezen vanuit de fysieke opslag en gekoppeld worden aan de klantspecifieke toepassing.

5.1 Selecteren van Beheersmodule architectuur In deze stap van het systeemontwerp worden een aantal beslissingen genomen welke van belang zijn voor de opzet van de toepassing. Het is daardoor mogelijk dat er een aantal uitbreidingen en aanpassingen voorkomen op het objectmodel van de OMT analyse. Waar dit het geval is wordt het vermeld. Het selecteren bestaat uit een aantal stappen die gelijk zijn aan de paragraafindeling Kiezen van de architectuur Bij databasetoepassingen onderscheiden we twee typen architectuur onderscheiden, te weten: • Operationele systemen, hiermee wordt bedoeld systemen die veelvuldig en kort worden geraadpleegd en/of bewerkt. Veelal is een interface met gebruikers het belangrijkst. Bijvoorbeeld administratie ondersteunende systemen • Beslissingsondersteunende systemen, dit zijn veelal systemen die minder veelvuldig geraadpleegd en bewerkt worden, maar aan het maken van,(door gebruikers gedefinieerde) selecties worden hoge eisen gesteld. Zoals systemen voor het zoeken in gegevensbestanden. De beheersmodule wordt op basis van bovenstaande beschrijving beschouwd als een operationeel systeem. Dit houdt in dat de volgende kenmerken belangrijk zijn: • Snelheid van benaderen van de gegevensbestanden • Goede beschikbaarheid van de gegevensbestanden • Gebruikersinterface welke snel werken mogelijk maakt Introductie van een lagenstructuur In deze stap wordt gezocht naar mogelijkheden om een scheiding aan te brengen in de functionaliteit van verschillende lagen. Voordelen van deze scheiding zijn [2]: • Ontwikkeling in verschillende lagen vermindert de complexiteit, ontwikkelen wordt overzichtelijker • Er kan gebruik gemaakt worden van overerving waardoor hergebruik beter mogelijk is • Een scheiding van gebruikers interface en datalogica, aanpassen van de logica zijn eenvoudig mogelijk. • Door het gebruik van lagen is het eenvoudig mogelijk een ander opslagmedium of –paradigma te kiezen als dit gewenst is. In dit project wordt een scheiding aangebracht tussen het benaderen van gegevensbestanden en de gebruikersinterface. Daarnaast wordt een scheiding aangebracht tussen de klasse structuur van de ontwikkelomgeving (Visual Objects) en de DDO. De DDO overeft hierbij gedrag van klassen uit de ontwikkelomgeving. In onderstaande tabel is de opbouw weergegeven

22


Naam klasse DataServer

DBServer/SQLTable

AbstractDbserver

DDOServer DataWindow DDOWindow

Werking Zorgt voor de afhandeling van events naar opdrachten t.b.v. fysieke gegevensbestanden. Introductie van een interface naar de clients van de gegevensbestanden zoals formulieren en rapporten Generieke functionaliteit voor DDO Tabellen, ook voor de embedded module toepassing Specifiek gedrag (business logic) voor de DDO toepassing Weergave van de inhoud van fysieke gegevensbestanden Weergave van de inhoud van DDO gegevensbestanden

In onderdeel Ontwikkelomgeving

Ontwikkelomgeving

DDO

DDO Ontwikkelomgeving DDO

Tabel 8 Lagenstructuur In de figuur is een uitbreiding in een OMT diagram te zien. Deze uitbreiding gaat uit van een aantal objecten zoals die in een ontwikkelomgeving aanwezig zijn. In deze afbeelding zijn dit Dataserver, DBServer en Datawindow (gearceed). Aan deze klassen wordt door overerving eigen functionaliteit toegevoegd.

Figuur 2 Lagenstructuur Introductie van een modulenstructuur Naast de lagenstructuur is het mogelijk een scheiding aan te brengen in verschillende modulen. Dit wordt bereikt door het instantieren van de klassen voor DDO logica en gebruikersinterface. De instantiatie van de modulen is gelijk aan het object model van de beheersmodule zoals weergegeven in de rapportage analyse. In de onderstaande tabel wordt van een aantal modulen weergegeven hoe de modulen- lagenscheiding wordt toegepast Module DDO logica (objectnaam) Tabel TabelDbServer Veld VeldDbServer Scherm/Formulier SchermDbServer Tabel 9 Modulen- en lagenstructuur

Gebruikersinterface (objectnaam) WndTabel WndVeld WndScherm

23


5.2 Selecteren van Embedded module architectuur Eisen aan de embedded module De DDO embedded module is een ingebed deel van een klantapplicatie. Het vervangt de resources en programmacode zoals deze in een traditioneel ontwikkelde applicatie aanwezig is. Dit houdt in dat er voor de embedded module geen interface nodig is met de gebruiker van de klantspecifieke applicatie. Voor deze eindgebruiker dient de DDO embedded module onzichtbaar te zijn. Voor het selecteren van de architectuur van de embedded module zijn de volgende punten van belang: • Snelheid: dient even snel of sneller dan programmacode te zijn. • Betrouwbaarheid: dit houdt in dat de embedded module altijd de juiste informatie moet aanleveren, en waar nodig controles dient uit te voeren. • Beschikbaarheid: de gegevens dienen altijd beschikbaar te zijn voor de klantspecifieke applicatie, met uitzondering van perioden van onderhoud. Uitgaande van bovenstaande punten wordt ervoor gekozen de embedded module zoveel mogelijk gebruik te laten maken van het werkgeheugen van de PC. In het geheugen worden de eigenschappen opgeslagen in array's. Dit vanwege de snelheidseis Daarnaast wordt vanwege de betrouwbaarheids- en beschikbaarheidseis gekozen voor een embedded module met alleen leesrechten voor de DDO gegevens. Hierdoor kan de DDO embedded module beschouwd worden als een data-dictionary [17]. De termen DDO embedded module en data-dictionary worden in deze rapportage door elkaar gebruikt en hebben dezelfde betekenis. Kiezen van architectuur Op basis van de bovengenoemde eisen kan de architectuur van de data-dictionary op een aantal manieren gerealiseerd worden. Hierbij wordt bedoeld hoe de data-dictionary services levert aan de productieklassen. Onder de productieklassen wordt verstaan de klassen welke de werking van het programma bevatten (de programmacode). Belangrijkste klassen zijn: • ClientDbServer is de klasse welke de structuur van de klantspecifieke gegevensbestanden beschrijft, belangrijke subklassen in deze klasse zijn velden, indexen, relaties selectie en statistiek • ClientWindow is de klasse welke de gegevens uit de ClientDbServer objecten weergeeft op het scherm. In deze structuur zijn drie architecturen mogelijk voor de data-dictionary [17]. Dit zijn: 1 Data-dictionary is verweven in produktieklassen Bij deze werkwijze is de data-dictionary niet te onderscheiden als entiteit. Het is verweven in de productieklassen. Dat houdt in dat zodra het object van de productieklasse bepaalde eigenschappen nodig heeft deze op dat moment vanuit de data-dictionary worden ingelezen. Voordeel van deze werkwijze is dat de werking naar verwachting snel is. Er wordt direct aanroep gedaan naar de data-dictionary gegevensbestanden. Daarnaast worden alleen die onderdelen aangeroepen en in het programma geladen die op dat moment daadwerkelijk nodig zijn. Deze opzet heeft als nadeel dat door de verwevenheid met de productieklassen de data-dictionary niet goed te onderscheiden is. Omdat inkapseling geheel ontbreekt houdt dit in dat de onderhoud en uitbreiding van de programmatuur moeilijker realiseerbaar is. [17] 2 Data-dictionary is een zelfstandig object dat services verleent Hierbij wordt het opstarten van de klantapplicatie de data-dictionary als een object geinstantieerd. Dit object is vervolgens vanuit alle productieobjecten te benaderen. De data-dictionary is dus globaal zichtbaar binnen de gehele applicatie. In de pseudocode wordt de methode fieldinfo als voorbeeld gebruikt. Het initialiseren van de Data-dictionary tijdens het opstarten van de applicatie wordt niet beschreven Voordeel van de methode is dat de onderhoudbaarheid en uitbreidbaarheid van de data-dictionary beter is. Inkapseling is goed te realiseren bij deze architectuur. Er vindt een methode aanroep plaats naar de datadictionary plaats. Hoe de data-dictionary dit intern afhandelt is niet zichtbaar. Nadeel is dat deze werkwijze de applicatiesnelheid negatief beïnvloedt. Er zal bijna altijd voor gekozen worden alle gegevens vanuit de data-dictionary bestanden in te lezen tijdens het opstarten. Dat betekent dat ook van productieklassen die tijdens de sessie niet gebruikt worden de gegevens geladen worden. Daarnaast moet binnen het object een administratie bijgehouden worden welke de gegevens en eigenschappen van de verschillende productieklassen van elkaar onderscheidt [17].

24


3 Data-dictionary is een attribuut van produktieklasssen Bij deze werkwijze wordt gezocht naar een tussenoplossing van bovenstaande architecturen. In plaats van een globale data-dictionary binnen de applicatie wordt binnen de ClientDbServer een eigenschap toegevoegd welke de data-dictionary voor de specifieke entiteit bevat. De data-dictionary bevat dus alleen de gegevens voor het object dat de data-dictionary als attribuut heeft. Tijdens het initialiseren van het object wordt de data-dictionary geladen. Belangrijk voordeel van deze architectuur is de inkapseling van de data-dictionary waardoor de onderhoudbaarheid en uitbreidbaarheid goed is. Daarnaast is het gunstig dat iedere ClientDbServer een eigen Data-dictionary heeft welke alleen de eigen gegevens bevat. Hierdoor is de administratie binnen de datadictionary minder complex. De snelheid van de applicatie wordt eveneens gunstig beïnvloed, allereerst doordat alleen van de geopende tabellen de data-dictionary geopend wordt, ten tweede vanwege de lagere complexiteit van de data-dictionary. Nadeel is dat andere productieklassen zoals bijvoorbeeld formulieren (ClientWindow) alleen via de ClientDbServer gegevens uit de data-dictionary kunnen opvragen. Dit brengt beperkingen mee bij de werking van de klantapplicatie [17].

Figuur 3 Architecturen van embedded module In de figuur wordt op basis van een OMT objectmodel een illustratie gegeven van de drie architecturen. Op basis van de beschrijving wordt gekozen voor de architectuur waarbij de data-dictionary een attribuut is van de ClientDbServer. Reden van deze keuze is dat deze werkwijze de eigenschappen van de andere architecturen zoveel mogelijk combineert zodat snelheid en betrouwbaarheid van de embedded module realiseerbaar zijn.

5.3 Omgevingsinteractie Onder omgevingsinteractie wordt verstaan hoe de toepassing wordt bestuurd en hoe de interactie plaatsvindt met andere toepassingen en gebruikers. Hierbij worden vier paradigma's onderscheiden • Procedureel (er wordt een opeenvolgend een aantal computer opdrachten uitgevoerd) • Event (Op basis van een gebeurtenis wordt een dispatcher opgestart, dit is de MS-Windows standaard) • Concurrent (een aantal autonome objecten reageren ieder afzonderlijk op gebeurtenissen) • Declaratief (Dit is de werkwijze die bij KI systemen gebruikt wordt

25


Embedded module Bij de embedded module vindt vrijwel geen omgevingsinteractie plaats. Zo is er nauwelijks interactie met gebruikers. De gebruikersinteractie vindt alleen plaats op het moment dat er een fout optreedt. In een standaard dialoogvenster wordt aangegeven wat het probleem is en welke stappen de eindgebruiker kan ondernemen om de problemen te verhelpen. Er vindt interactie plaats tussen de klantspecifieke applicatie en de DDO embedded module. Deze interactie bestaat er uit dat de klantapplicatie aan de DDO embedded module vraagt om de gegevens in de data-dictionary te laden. Dit vindt plaats op basis van een aantal leesopdrachten. Het paradigma is daarom procedureel te noemen Beheersmodule Bij de beheersmodule vindt geen interactie plaats met andere toepassingen. Echter de interactie met de programmeur is het bestaansrecht van de beheersmodule. Deze is belangrijk. Het interactieparadigma dient aan te sluiten op de MS-Windows standaard, er wordt daarom gekozen voor het event paradigma. In de OMT methode wordt nauwelijks ingegaan op dit aspect. Aan de gebruikersinterface zijn echter een aantal eisen te stellen. Op basis van deze eisen zijn een aantal gebruikersinterface paradigma's te kiezen • Dient aan te sluiten op de werkwijze van standaard MS-Windows toepassingen [20] • Moet de mogelijkheid bieden aan de programmeur om snel de relevante eigenschappen te vinden • Dienen op een logische wijze gegroepeerd te zijn, zodat de overgang van de ene visuele editor naar de andere uit zo min mogelijk stappen bestaat. • Moet de programmeur de mogelijkheid bieden snel gegevens op te zoeken en of te selecteren • Dient het aantal repeterende en/of eentonige handelingen te beperken • Dient fouten van de programmeur te signaleren c.q. te voorkomen. Op basis van bovenstaande eisen wordt voor een aantal paradigma's met betrekking tot de gebruikersinterface gekozen [10] in de beheersmodule. Deze paradigma's worden gebruikt in combinatie met de standaard MSWindows paradigma's zoals het gebruik van de muis en directe manipulatie. Gegevensblad Formulierweergave Formulieren waarin gegevens worden getoond kunnen op twee manieren de gegevens weergegeven. In de gegevensbladweergave worden de gegevens van een record op een regel getoond. Dit biedt de mogelijkheid om meerdere records in een formulier te tonen. In de formulierweergave wordt één record getoond in het formulier en worden de gegevens getoond in besturingselementen. Deze weergave wordt gebruikt om gegevens in detail te raadplegen en aan te passen. De combinatie van beide weergaven biedt de gebruiker de mogelijk om snel gegevens op te zoeken en te selecteren in de gegevensbladweergave en vervolgens deze gegevens aan te passen in de formulierweergave. Tabbladen Property sheets Om de gegevens te groeperen kunnen tabbladen gebruikt worden. Daarnaast dienen tabbladen als ruimtebesparing. Door tabs te gebruiken kunnen een groot aantal besturingselementen over verschillende tabbladen verdeeld worden. Dit wordt in de beheersmodule toegepast om te voorkomen dat de programmeur een aantal formulieren moet sluiten of iconiseren om naar een ander onderdeel te gaan. Het aantal stappen wordt hierdoor beperkt. Klembord In MS-Windows kan het klembord worden gebruikt om tekst en afbeeldingen tijdelijk op te slaan tussen twee bewerkingen. Echter bij programmeerwerkzaamheden kan het klembord gebruikt worden om redundant tikwerk te voorkomen. Daarom kan het klembord gebruikt te worden om records en besturingselementen tussen twee bewerkingen op te slaan. Drag en drop Drag en drop wordt met name gebruikt voor directe manipulatie. Daarom moet drag en drop toegepast worden in de schermpainter. Middels drag en drop kunnen nieuwe besturingselementen op het formulier geplaatst worden. Verder kan met drag een bestaand besturingselement verplaatst, vergroot of verkleind worden. Waar mogelijk worden deze paradigma's toegepast. Door zoveel mogelijk van dezelfde paradigma's uit te gaan wordt het (leren) werken met de toepassing eenvoudiger.

26


5.4 Data management Criteria De data dictionary objecten dienen op enigerlei wijze persistent te zijn. Dit betekent dat zodra de beheersmodule of embedded module toepassing afgesloten wordt, de bewerkte of gelezen gegevens op een opslagmedium terecht komen [2]. Voor de opslag van deze gegevens zijn de volgende criteria van belang: • Data persistentie, blijven de gegevens gehandhaafd als de applicatie wordt afgesloten. Is van belang voor data dictionary objecten • Aanschafkosten, wat zijn de aanschafkosten van het systeem, als de kosten hoog zijn dan dient dit doorberekend te worden aan de eindgebruikers van het systeem. • Onderhoudskosten, zijn hoog als er personeel vereist is voor om het systeem te onderhouden, dit is voor een groot aantal organisaties niet mogelijk. • Grote hoeveelheden data, is het mogelijk om grote hoeveelheden data op te slaan, is voor data dictionary objecten minder van belang • Performance, de snelheid van de toepassing tijdens het werk, is van belang voor zowel embedded module als beheersmodule • Uitbreidbaarheid, is het eenvoudig mogelijk het datamodel uit te breiden, is van groot belang voor de Data dictionary Objecten • Gemeenschappelijk gebruik van bestanden, voor de beheersmodule is dit een wens, geen eis, werken in teams aan één toepassing is gemakkelijk • Crash recovery, is het mogelijk om bij de gegevens te komen als er een crash heeft plaatsgevonden, is van groot belang bij de toepassing, zonder definitie objecten is er geen klantspecifieke toepassing meer • Integriteit heeft betrekking op null waarden in bestanden of verwijzingen naar niet (meer) bestaande objecten, dient een onderdeel te zijn van de beheersmodule • Transactieverwerking, is minder van belang voor de toepassingen • Gedistribueerd gebruik, is niet van belang • Query taal, is niet van belang • Veiligheid, is van belang voor zowel de beheersmodule als de embedded module. • Metadata, data dictionary objecten zijn metadata, zijn metadata van metadata zinvol? Wijze van opslag Het opslaan van de data dictionary objecten is op een groot aantal manieren mogelijk. Hierbij wordt uitgegaan van de mogelijkheden die onder MS-Windows geboden worden. In onderstaande opsomming worden de opties genoemd [18] In het werkgeheugen Voor de embedded module is dit noodzakelijk vanwege de performance eisen, echter de gegevens in het werkgeheugen moeten ingelezen worden uit bestanden. Speciale hardware zoals eproms en dergelijke zijn niet relevant voor dit systeem, vanwege de frequentie waarin veranderingen aangebracht worden in de definitie. DBMS via ODBC Via ODBC of native drivers is het mogelijk een RDBMS te benaderen. Voordeel van RDBMSen zijn de data integriteit en de uitbreidbaarheid. Echter het gebruik van een RDBMS vereist speciaal getraind personeel voor beheer en onderhoud. Daarnaast is een RDBMS gericht op de opslag van zeer grote hoeveelheden data. Dit is voor data dictionary objecten niet van toepassing. Ini of tekstfiles Deze files worden in MS-Windows veelvuldig toegepast voor het opslaan van systeeminstellingen. Voor data dictionary objecten zijn ze minder geschikt. Allereerst zijn ze minder geschikt voor de opslag van gegevens. Verder is de data integriteit van ini files moeilijk te handhaven. Ten derde is gemeenschappelijk gebruik slecht mogelijk. Als laatste is de beperkte beveiliging van ini files te noemen. Xbase relationeel Het Xbase protocol (Foxpro) wordt veel gebruikt voor toepassingen met een beperkte omvang. De record georiënteerde opzet biedt voordelen voor toepassing in data dictionary objecten. Daarnaast is het positief dat de gegevens eenvoudig te beschermen zijn, terwijl crash recovery goed mogelijk is. Nadeel is dat de vraag naar opslagcapaciteit op een harde schijf hoger is dan bij bijvoorbeeld ini files en Xbase array.

27


Xbase array Bij het Xbase protocol is het mogelijk om BLOBs (binary large object blocks) op te slaan in een database. Voordeel hiervan is dat het laden van de data dictionary objecten snel is. Nadeel is echter dat de uitbreidbaarheid van het gegevensmodel moeilijker te bewerkstelligen is. Daarnaast is crash recovery niet mogelijk. Repository Bij een repository worden alle data dictionary objecten in één fysiek bestand opgeslagen. Voordeel is de goede performance. Nadeel is de slechte crash recovery. Verder is de beperkte mogelijkheid van gemeenschappelijk gebruik een nadeel. Echter repository based toepassingen zijn volop in ontwikkeling. Daarom kan in de komende tijd deze werkwijze interessant worden. Keuze van wijze opslag In onderstaande tabel wordt een beschrijving gegeven van de bijdrage aan de criteria van de verschillende opslagmethoden. Op basis van de beschrijving wordt een score toegekend aan iedere methode. Bij de data dictionary objeten wordt gekozen voor Xbase relationeel voor de beheersmodule. Voor de embedded module wordt gekozen voor werkgeheugen waarbij tijdens het opstarten van de embedded module de gegevens vanuit de Xbase bestanden worden ingelezen. Werkgeheugen

DBMS

Ini tekstfiles ++ ++ ++ -+ --+ --

Xbase relationeel ++ ++ ++ ++ + ++ ++

Xbase array ++ ++ ++ -+ ++ ---

Data persistentie -++ Aanschafkosten ++ -Levenscycluskosten ++ -Grote hoeveelheden data -++ Performance ++ -Uitbreidbaarheid -++ Gemeenschappelijk gebruik van -++ bestanden Crash recovery -++ ++ ++ -Integriteit -++ ---Transactieverwerking / / / / / Gedistribueerd gebruik / / / / / Query taal / / / / / Veiligheid -++ -++ ++ Metadata / / / / / ++ positief voor deze eigenschap, -- negatief voor deze eigenschap, +- Neutraal, / niet relevant Tabel 10 Score van opslagmethoden per criterium

Repository ++ -++ ++ -+ ++ --+ -/ / / ++ /

5.5 Mogelijkheden voor hergebruik Hergebruik is één van de kenmerken van object georienteerd ontwikkelen. Daarom moet gezocht worden naar mogelijkheden voor hergebruik. De DDO toepassing is gericht op het toepassen van hergebruik. Er wordt een embedded module ontwikkeld waarin de methoden generiek zijn terwijl de eigenschappen van de objecten in gegevensbestanden opgeslagen zijn. Voor deze toepassing is hergebruik moeilijk te realiseren echter de volgende punten zijn relevant Hergebruik van modellen De eigenschappen van modellen worden opgeslagen in gegevensbestanden. Hergebruik kan gerealiseerd worden door een selectie te maken in deze gegevensbestanden en vervolgens deze eigenschappen in een nieuwe klanttoepassing opnemen. De DDO beheersmodule dient daarom te beschikken over de mogelijkheid om de DDO gegevensbestanden te kopiëren. Class library De DDO wordt gebruikt in combinatie met een classlibrary. In deze library is een aantal abstracte klassen opgenomen welke door de DDO toepassing worden uitgewerkt naar de specifieke wensen van de klant. In de beheersmodule en embedded module is het toepassen van een class library niet relevant omdat de toepassingen daar een te geringe omvang voor hebben.

28


Overerving Overerving kan een belangrijk middel zijn om hergebruik te introduceren in de embedded module en de beheersmodule. Tijdens de analysefase is de abstractDDO klasse toegevoegd waardoor hergebruik van bepaalde eigenschappen en operaties mogelijk wordt. In de vorige paragraaf is aangegeven dat een aantal operaties toegevoegd welke de klembordfuncties in Windows aanpassen. Deze operaties zijn relevant voor zowel de productie klassen als de DDO klassen. Daarom kan een extra klasse toegevoegd worden waar deze functionaliteit aan toegevoegd is. Hierdoor wordt hergebruik geïntroduceerd omdat functionaliteit van de abstracte klasse nu beschikbaar is in de lagerliggende klasseen In onderstaande figuur is te zien hoe het objectmodel uitgebreid kan worden om het hergebruik toe te passen. Hetzelfde geldt voor het DDOWindow dat voor de verschillende modulen in de DDOServer basisgedrag bevat.

Figuur 4 Hergebruik

5.6 Strategie voor data interactie Hiermee wordt bedoeld hoe de communicatie met de gegevensbestanden plaatsvindt. Deze toepassing wordt gebruikt om een metamodel op te slaan in gegevensbestanden. Hierbij wordt gekozen voor de werkwijze zoals de ontwikkelomgeving die biedt. Middels overerving wordt van deze klassen het basisgedrag en de basiseigenschappen gespecificeerd in de klassen/objecten voor de modulen in de toepassing.

5.7 Aspecten voor detail ontwerp Op basis van het systeemontwerp kan in het detailontwerp het model verder uitgewerkt worden. In onderstaande paragrafen worden een aantal aspecten genoemd welke van balang zijn als uitgangspunt voor detailontwerp en realisatie. Associaties Tijdens het detailontwerp zal het object model en de daarin opgenomen associaties omgezet worden naar een relationeel model op basis van Xbase. Het object model ontwikkeld tijdens de analyse fase kent geen complexe associatie structuur. Vertalen naar een relationeel model zal hierdoor geen problemen geven. Echter het is belangrijk rekening te houden met de attribuutnamen zoals beschreven in onderstaande paragraaf. Afwezigheid van multiple inheritance In de ontwikkelomgevingen voor databases, zoals genoemd in de inleiding, is alleen enkelvoudige overerving of geen overerving mogelijk. Hiermee dient in het detail ontwerp rekening gehouden te worden. Dit levert voor het DDO object model geen problemen op.

29


Null waarden Voor Null waarden dient een generieke oplossing gezocht te worden. Echter in het Xbase protocol komen geen null waarden voor. In de ontwikkelomgevingen komen wel Null waarden voor. Daarom moet op applicatieniveau rekening gehouden worden met het ontbreken van null waarden in de gegevensbestanden. Attribuutnamen Voor de attribuut- of eigenschapnamen wordt uitgegaan van de standaardisatie zoals beschreven in de analyse fase over de data-dictionary. Aan de eigenschapnaam dient men bij het detailontwerp en bij de realisatie te zien van welk type het is. Daarnaast wordt de volgende zichtbaarheid van variabelen gebruikt: • Globale variabelen zijn overal zichtbaar. • Behalve als er in een klasse een eigenschap is met dezelfde naam, dan is deze zichtbaar. • Behalve als er een lokale variabele is in een methode met dezelfde naam, dan is deze zichtbaar en zijn de globale en de instance variabele onzichtbaar. Rol namen Rolnamen komen in het ontwerp weinig aan de orde. Alleen in de klasse relatie komen tabellen in meerdere rollen voor. Hiervoor is in het detailontwerp geen speciale notatie vereist. Toegangsrechten In deze toepassing is het gebruik van een autorisatietabel niet aan de orde. De DDO embedded module is vanuit een klantapplicatie niet aan te passen en is ingebed in de klanttoepassing. Voor de klantapplicatie gelden natuurlijk wel de normale autorisatieniveaus. De beheersmodule dient toegankelijk te zijn voor programmeurs. Bij het opstarten kan om een wachtwoord gevraagd wordt. Mijn ervaring is dat programmeurs vaak iets verzinnen om het gebruik van wachtwoorden te omzeilen. Reden om bij de beheersmodule geen gebruik te maken van wachtwoorden. Worden de embedded module en beheersmodule gedeelte samengebracht in één toepassing in combinatie met de klantapplicatie dan is het gebruik van autorisaties noodzakeljk. Dit geldt met name voor de beheersmodule.

5.8 Tot slot In het systeemontwerp is een beschrijving gegeven hoe in het detailontwerp en de realisatie verder gegaan wordt. Op basis van de resultaten van de analyse fase zijn in de systeemontwerp fase beslissingen genomen over de te volgend werkwijze en punten waarmee rekening gehouden moet worden tijdens de volgende fase. Belangrijke punten hierin zijn: • Keuze van een architectuur • Wijze van gegevensopslag • Gebruikersinterface Tijdens het detail ontwerp zullen de gekozen paradigma's gebruikt worden om tot een model te komen wat in de realisatiefase vertaald kan worden naar een toepassing.

30


6 Detail ontwerp Zijn tijdens de fase systeemontwerp met name de strategische aspecten van het ontwerp aan de orde gekomen. In deze fase komen met name de individuele klassen en methoden aan de orde. In deze fase wordt nog niet ingegaan op aspecten die betrekking hebben op de wijze van opslag van de objecten. Dit wordt uitgewerkt in de volgende fase de realisatie.

6.1 Object model transformatie Het model dat tijdens de analyse fase is ontstaan dient vertaald te worden naar een vereenvoudigd of geoptimaliseerd model ten behoeve van de realisatie. In dit project wordt de toepassing ontworpen op basis van het principe intelligente formulieren en domme besturingselementen. Dit houdt in dat de functionaliteit zoveel mogelijk gekoppeld wordt aan die entiteiten die andere entiteiten bevatten. Hierdoor is het mogelijk het object model te vereenvoudigen. Met name de structuur van overerving vereenvoudigt hierdoor. In onderstaande opsomming wordt de transformaties beschreven: • Selectiestap overerving naar Codeselectie/Hooglaagselectie/Trefwoordselectie. De functionaliteit wordt overgebracht naar de selectiestap klasse. Daarnaast wordt aan de selectiestap de eigenschap "soort selectie" toegevoegd". Tijdens het uitvoeren van een selectie wordt op basis van deze eigenschap de bijbehorende actie aangeroepen. • Statistiekstap overerving naar Codestatistiek/Hooglaagstatistiek/Datumstatistiek. Ook hierbij wordt de functionaliteit overgebracht naar de bovenliggende klasse. Daarnaast wordt aan deze klasse de eigenschap "soort statistiek" toegevoegd". • Besturingselement met overerving naar opmaakelement en editelement. Aan de klasse wordt een eigenschap toegevoegd "soort besturingselement". Bij het laden van het formulier wordt vanuit een formulier methode het specifieke gedrag van het besturingselement toegevoegd. Bijvoorbeeld de keuzeopties voor een keuzelijst met invoervak wordt vanuit het formulier gekoppeld aan de keuzelijst. • Formulieren worden gesplitst in de klassen ontwerpformulier en cliëntformulier. In het ontwerpformulier is de functionaliteit toegevoegd voor het opmaken van een formulier met besturingselementen. Het clientformulier zorgt ervoor dat de gegevens in de juiste opmaak getoond worden en dat de gegevens uit de gegevensbestanden op de juiste wijze getoond worden.

6.2 Bewerken object model Tijdens de transformatie zijn een aantal aanpassingen aangebracht in het objectmodel. Na deze wijzigingen kan het objectmodel verder verfijnd worden. Omdat de beschrijving van het objectmodel gebaseerd is op een datadictionary kan hier in deze stap goed op aangesloten worden. De volgende aspecten zijn van belang: • Kiezen van sleutelvelden. In het objectmodel is reeds een sleutelveld voor iedere klasse aanwezig. Er is namelijk een klasse abstractddo toegevoegd waar een aantal sleutelvelden in aanwezig zijn, te weten titel, omschrijving en naam. Voor ieder veld wordt dit naamveld gekoppeld aan de naam van de klasse. Hierdoor ontstaat een sleutel voor het relationele model. • Toewijzen van domeinen. Voor iedere eigenschap wordt waar mogelijk het domein aangegeven. Het domein bestaat uit de gegevenstypen beschikbaar in de ontwikkelomgeving. Het domein kan verder verkleind worden als dit relevant is. Deze gegevens zijn in de data-dictionary in detail uitgewerkt. In bijlage 8 is het objectmodel opgenomen waarin een beschrijving van de domeinen te vinden is. • Null waarden voor eigenschappen zijn eveneens in de data-dictionary uitgewerkt. Door het gebruik van een minimum cardinaliteit is het mogelijk de null/niet null eigenschap eenvoudig te bepalen. Alle eigenschappen met een minimum cardinaliteit groter dan nul hebben een niet null eis. In bijlage 8 is de null/niet null eis opgenomen. • Berekening van de fysieke opslagcapaciteit is minder relevant, bij een data-dictionary is het aantal entiteiten in de gegevensbestanden gering van aantal. Met de huidige stand van zaken op het gebied van gegevensopslag zal dit geen probleem zijn.

6.3 Bewerken functioneel model Voor een gedetailleerde beschrijving wordt verwezen naar de data-dictionary. De onderstaande opsomming geeft een korte beschrijving van relevante aspecten:

31


Ontwerpen van methoden. Hierbij zijn drie soorten methoden te onderscheiden. • Allereerst zijn er de methoden die de basis vormen voor de werking van zowel de embedded – en beheersmodule. Deze methoden zijn als programma code opgenomen in de toepassing. Deze methoden zorgen voor de werking van de data dictionary objecten. Aanpassing van deze methoden is alleen toegestaan voor foutherstelling. • Generieke methoden van de applicatie die gebruik maken van de DDO. Deze is als programmacode opgenomen in de klant toepassing en kan eventueel aangepast worden. • Methoden opgeslagen in de DDO. Deze methoden zijn eventueel aanpasbaar voor de eindgebruiker. Om deze reden zijn ze ook opgenomen in een gegevensbestand. De programmacode bestaat uit een sub-set van de programmeertaal. Bij het ontwerpen van de methoden geldt als stelregel "Doe het generiek als dat kan". Deze stelregel wordt toegepast om de volgende redenen hergebruik en foutvermindering. Eigendom van methoden. Voor het eigendom van de methoden geldt de bovengenoemde stelling "Intelligente formulieren domme besturingselementen" Het eigendom van methoden vindt zoveel mogelijk plaats bij de entiteiten welke eigenaar zijn van kleinere entiteiten. Dit geldt voor formulieren, maar ook voor bijvoorbeeld het de tabel klasse als eigenaar van de velden indexklasse. Voor methoden wordt verder gezocht naar primitieve bewerkingen. Dit zijn bewerkingen die niet zijn op te splitsen in kleinere bewerkingen. Het eigendom van deze bewerkingen zal hierdoor eenvoudiger te bepalen zijn.

32


7 Realisatie Tijdens de analyse en het ontwerp is een object model opgesteld van de DDO. In de fase realisatie wordt een deel van de toepassing als prototype ontwikkeld. In dit verslag wordt een beschrijving gegeven van de beslissingen genomen tijdens de realisatie. In de voorgaande fasen is een data-dictionary opgebouwd waarin alle objecten in detail worden beschreven. Deze data-dictionary wordt in deze fase vertaald naaar een aantal gegevensbestanden en programmacode. In dit hoofdstuk wordt de procesbeschrijving van OMT gevolgd [3]. In deze opdracht wordt een deel van de totale toepassing uitgewerkt. Met name de onderdelen in gebruik door de formulierpainter worden uitgewerkt. Dit onderdeel wordt door applicatieprogrammeurs tijdens het ontwikkelen het meest gebruikt. Zijn onderdelen van belang voor deze formulierpainter dan worden deze eveneens uitgewerkt.

7.1 Keuze van de ontwikkelomgeving Tijdens de realisatie wordt een deelsysteem van de DDO ontwikkeld. Daartoe moet gekozen worden voor een ontwikkelomgeving. De DDO toepassing wordt in deze opdracht uitgewerkt in CA-Visual Objects. Redenen om voor deze ontwikkelomgeving zijn: • Product biedt goede mogelijkheden voor OO realisatie, zoals een uitgebreide klasse structuur, mogelijkheden voor inkapseling, koppeling van gedrag en eigenschappen en het toepassen van inheritance. • Product biedt mogelijkheden voor het benaderen van meerdere soorten gegevensbestanden, zoals files,Xbase bestanden (MS-Foxpro) en relationele databases. Waarbij wordt gekozen voor MS-Foxpro bestanden. • Het product is goedkoop.

7.2 Implementatie van identiteit Objecten hebben in OMT altijd een eigen identiteit. Echter in het relationele model van MS-Foxpro is dit niet het geval. Hier moet expliciet een sleutel gekozen of toegevoegd worden. Het toevoegen van een sleutel wordt veelal toegepast als er geen unieke sleutel te vinden is in de tabel, of wanneer een combinatie van een groot aantal velden de unieke sleutel vormt. In het geval van de DDO toepassing is dit niet het geval. Iedere entiteit heeft een naam. Deze naam moet uniek zijn. Daarom wordt gekozen voor dit veld als unieke sleutel. Hierbij moet opgemerkt worden dat het veld naam een toevoeging heeft. Bijvoorbeeld voor het object veld is de naam veldnaam, voor het object index indexnaam et cetera. In de toepassing zijn deze sleutelvelden altijd geindexeerd. Dit heeft tot voordeel dat snelheidswinst te bereiken is bij het zoeken, de objecten in overzichten altijd op alfabetische volgorde staan en er eventueel op uniciteit gecontroleerd kan worden.

7.3 Implementatie van domeinen Van ieder attribuut wordt aangegeven wat de domeinspecificatie is. De domeinspecificatie kan in drie delen worden opgesplitst. Allereerst kan aangegeven worden wat het type van het attribuut is. In MS-Foxpro kan men kiezen uit de volgende typen. CODE TYPE C Karakters tot een maximum van 255 posities D Datum heeft standaard 8 posities N Getallen zowel integers als reele getallen L Logische waarden waar of onwaar M Memo teksten met een variabele lengte tot maximaal 64 K aan karakters O BLOBs voor opslag van afbeeldingen, binaire documenten etc. Tabel 11 Veldtypen Foxpro In de data-dictionary is reeds een optie ingebouwd om het type van een attribuut te definieren. Hierbij kan opgemerkt worden dat een attribuut van het type expressie in de database wordt opgeslagen in een memoveld. Het tweede type domein geeft aan welke beperkingen er zijn binnen een bepaald gekozen type. Met name bij karaktervelden wil men beperkingen aan kunnen brengen. Bijvoorbeeld een veld gelacht van een persoon heeft een lengte van één karakter. Zonder beperkingen kunnen op deze plek minstens 35 karakters ingevuld worden.

33


Echter alleen de karakters M en V zijn relevant. Door de invoer opties te beperken tot deze twee opties kan voorkomen worden dat onzin waarden in een veld worden ingevoerd. In de data-dictionary is opgenomen wat de mogelijke waarden zijn voor ieder afzonderlijk attribuut. Deze keuzeopties hebben twee bronnen: allereerst kan een lijst van waarden opgegeven worden waaruit gekozen wordt. Deze lijst is niet aanpasbaar, omdat deze lijst in de programmacode wordt opgenomen. De tweede bron is een verwijzing naar een tabel. Omdat in de tabel gegevens gewijzigd kunnen worden is deze optielijst eveneens dynamisch. Met name het koppelen van verschillende tabellen wordt op een dergelijke wijze uitgewerkt. Het derde domein wordt de picture van een veld genoemd. Dit is het best met een voorbeeld te verduidelijken. Een veld postcode heeft zeven posities van het type karakter. Echter op de eerste vier posities mogen alleen cijfers ingevuld worden, gevolgd door een spatie en twee letters. Deze beperking kan opgenomen worden waardoor een postcode veld altijd deze opbouw heeft. In de DDO toepassing komen een aantal picture velden voor. Met name om ervoor te zorgen dat waarden altijd in hoofdletters worden opgeslagen. De data-dictionary is opgenomen als DDO toepassing. Voor een gedetailleerde beschrijving is deze te raadplegen. Daarnaast is een tabel en veld beschrijving opgenomen in de bijlagen.

7.4 Implementatie van het objectmodel in XBase Het object model wordt in deze stap vertaald naar een aantal tabellen. Voor deze tabellen geldt hetzelfde als in bovenstaande paragraaf genoemd is. Vermeldenswaardig is echter dat MS-Foxpro iedere tabel als een apart bestand opslaat. Dit wordt een gegevensbestand genoemd. De termen tabel en gegevensbestand worden dan ook door elkaar gebruikt en hebben betrekking op hetzelfde. Onderstaande kopjes geven aan welke deelstappen onderkend zijn. Implementatie van objecten De objecten kunnen vrijwel rechtstreeks vertaald worden naar tabellen. Hierbij wordt rekening gehouden met de domeinaspecten zoals beschreven in bovenstaande paragraaf. Daarnaast heeft Foxpro een beperking in de lengte van de veldnamen. Een veld kan niet langer zijn dan 10 karakters en mag geen spaties bevatten. Daarom zijn de namen van een aantal velden afgekort of aangepast aan de spatie eis. Voor de namen van de gegevensbestanden geldt deze beperking niet omdat lang veldnamen zijn toegestaan. Er wordt echter voor gekozen om deze tabellen met DD te laten beginnen gevolgd door drie karakters om het gegevensbestand te onderscheiden. Dit is gedaan om te voorkomen dat applicatieprogrammeurs in de DDO toepassing tabellen definieren met dezelfde naam als een DDO gegevensbestand. Implementatie van associaties De associaties tussen de verschillende objecten kunnen vertaald worden naar velden in de afzonderlijke tabellen of door het toevoeven van koppeltabellen. De volgende criteria zijn toegepast: • Bij een één op n relatie wordt de sleutel van de één tabel toegevoegd aan de n tabel. • Bij een één op één relatie wordt de sleutel van de ene tabel toegevoegd aan de andere tabel. Hierbij wordt de sleutel toegevoegd aan die tabel welke het minst geraadpleegd wordt. • Bij een N op M relatie wordt een koppeltabel toegevoegd die zowel de N als de M sleutel bevat • Bij een aggragatie wordt de sleutel van het “geheel” object toegevoegd aan het “deel” object In de bijlage met de tabeldefinities is aangegeven hoe de associaties zijn uitgewerkt in de vorm van een relationeel model. In de data-dictionery is een verdere detaillering te vinden van de relaties. Met name de minimumcardinaliteit van attributen en relaties is hierbij van belang. Als deze een andere waarde heeft dan 0 moet namelijk het veld in de tabel gedefinieerd worden als Not null. Helaas is dit niet definieerbaar in MSFoxpro. Daarom is dit uitgewerkt in de programmacode (zie de paragraaf over het functioneel model). Implementatie van overerving Overerving kan op meerdere manieren worden uitgewerkt in. Allereerst is het mogelijk om in de overervende tabel een sleutel op te nemen van de bovenliggende tabel. Voordeel hiervan is dat geen redundantie optreedt van gegevens en dat een aanpassing aan de bovenliggende tabel direct toepasbaar is voor de overervende tabel. Echter in Foxpro kent deze werkwijze een nadeel te weten performance verlies. Daarom wordt gekozen voor het opnemen van alle attributen als veld in de overervende tabellen. In de DDO wordt geen gebruik gemaakt van meervoudige overerving. Dit is met name gedaan om problemen bij de realisatie betreffende conflicterende naamgeving van methoden en eigenschappen te voorkomen.

7.5 Implementatie van het functioneel model Voor de implementatie van het functioneel model is eenvoudig gebruik te maken van de klasse opbouw van Visual Objects. In Visual Objects is een klasse opgenomen DbServer genaamd. Deze klasse zorgt ervoor dat een

34


koppeling met een Foxpro bestand ingekapseld is door de klasse. Overerving van deze klassen maakt het mogelijk eenvoudig eigenschappen van de objecten te controleren op domein waarden en null niet null waarden. Veel belangrijker is dat aan de objecten functionaliteit kan worden toegevoegd. Hierbij kan een onderscheid gemaakt worden tussen generieke operaties en specifieke operaties voor een bepaald object. In de data-dictionary is daarom een klasse opgenomen abstractDDO. Deze is uitgewerkt als het AbstractDbServer object tijdens de realisatie. In dit AbstractDbServer object bevinden zich de generieke methoden zoals cut, copy en paste. Daarnaast is de controle tussen fysiek bestand en objectdefinitie in dit object opgenomen. Van de AbstractDbServer klasse vindt overerving plaats van zowel de Dbserver in de embedded module als in de beheersmodule toepassing. In de data-dictionary zijn de operaties in pseudocode uitgewerkt. Deze pseudo code is overgebracht naar de DDO toepassing en aangepast naar Visual Objects syntax. Het is spijtig dat deze vertaalslag nog niet geautomatiseerd kan plaatsvinden. Dan zou het onderhoud van de applicatie eenvoudiger zijn. Op dit moment moeten aanpassingen hierdoor op twee plaatsen worden doorgevoerd. Een aantal operaties moet aangepast kunnen worden door een applicatieprogrammeur. Echter Visual Objects maakt gebruik van gecompileerde programmacode. Deze is niet aanpasbaar als met de applicatie gewerkt wordt. Dit probleem is opgelost door een extra library aan te schaffen welke scripting mogelijk maakt. Scripting is het toevoegen van programmacode aan een applicatie, waarbij de applicatie ervoor zorgt dat het script vertaald en uitgevoerd wordt. Deze library. VO Script genaamd, bevat een subset van de functionaliteit van Visual Objects in het geheel. Echter de subset is zodanig omvangrijk dat vrijwel iedere gebruikerswens vertaald kan worden in een werkend script.

7.6 Implementatie van het dynamisch model Het dynamisch model van de DDO toepassing sluit nauw aan op het dynamisch model van MS-Windows. In het hoofdstuk systeemontwerp is aangegeven hoe de presentatie van de objecten dient plaats te vinden. In onderstaande kopjes worden de belangrijkste aspecten uitgewerkt Tabelweergave en Formulierweergave In het dynamisch gedrag van de beheersmodule is het belangrijk dat een object zich in twee modi kan bevinden. Allereerst kan het door de applicatieprogrammeur worden geraadpleegd. De gegevens van één entiteit wordt getoond in een rij. Er worden meerdere entiteiten in de vorm van rijen getoond op het scherm. Dit is de tabelweergave. In onderstaande figuur ziet u een voorbeeld van deze tabelweergave.

Figuur 5 Tabelweergave DDO Beheersmodule

35


Dubbelklikt de applicatieprogrammeur op een rij dan opent deze rij zich in formulierweergave. In deze weergave kunnen de eigenchappen en eventuele operaties van deze entiteit bewerkt worden. Een voorbeeld is te zien in figuur 6. Op het moment dat van een weergave naar de andere weergave geschakeld wordt dienen een aantal opdrachtknoppen op het formulier geactiveerd of gedeactiveerd te worden. Op het moment dat geraadpleegd wordt is een bewaren opdrachtknop niet actief, er valt tenslotte niets te bewaren. In beide figuren is de activering van de verschillende knoppen te zien. Een gedeactiveerde knop is grijs.

Figuur 6 Formulierweergave DDO Beheersmodule In beide figuren is verder te zien hoe gebruik gemaakt wordt van tabbladen om de gegevens te groeperen en de hoeveelheid van zichtbare gegevens te reduceren. Formulier ontwerp Een belangrijk onderdeel van de beheersmodule is het formulierontwerp. In het formulier ontwerp kunnen besturingselementen op een formulier geplaatst worden. Dit is onderdeel voor de applicatieprogrammeur het belangrijkste onderdeel. Een groot deel van de werkzaamheden bestaat uit het aanpassen en bewerken van de formulieropmaak. Belangrijke eisen zoals genoemd in het systeemontwerp waren directe manipulatie en drag en drop mogelijkheden. Beide zijn uitwerkt in het formulierontwerp. Een besturingselement kan door direct manipulatie vergroot, verkleind of verplaatst worden. Hierbij onderscheidt men twee modi. Allereerst kan het besturingselement geactiveerd zijn. Als dit het geval is kan een besturingselement verplaatst worden. Is het gedeactiveerd dan kan het vergroot of verkleind worden. Bij het formulier ontwerp is een toolbox zichtbaar. In deze toolbox zijn de verschillende besturingselementen zichtbaar. De applicatie programmeur kan nu met drag en drop het actieve besturingselement verplaatsen van de toolbox naar het formulier. Vanuit het menu is het mogelijk om de eigenschappen van besturingselementen aan te passen. De belangrijkste opties zijn: • Uitlijnen van een aantal besturingselementen naar links, rechts, top of bodem. • Besturingselementen met knippen, kopieren en plakken van en naar een klembord verplaatsen. Dit klembord kan besturingselementen verplaatsen van het ene naar het andere formulier. • Eigenschappen als lengte en hoogte van besturingselementen aanpassen. Dit kan bij één besturingselement of bij een groep geselecteerde elementen. • Het type besturingselement of het gekoppelde veld kan in het formulierontwerp aangepast worden. • Instellen van de tabvolgorde van alle besturingselementen. • Tonen van een van de formulieropmaak. • Tussentijds opslaan of laden van de besturingselementen

36


Figuur 7 Formulierontwerp DDO Beheersmodule Naast de hierboven genoemde aspecten zijn de overige criteria uitgewerkt in het prototype. Beide bovengenoemde aspecten zijn genoemd, enerzijds vanwege de relevantie, anderzijds als voorbeeld hoe het ontwerp in de realisatie is uitgewerkt.

37


8 Testen In de voorgaande hoofdstukken is een beschrijving gegeven van het ontwikkeltraject van Data Dictionary Objecten. Hierbij is voorbij gegaan aan de vraag of deze applicatie zich kan handhaven in een gebruikerspopulatie. In dit hoofdstuk zal op dit aspect worden ingegaan.

8.1 Doel van de test Het doen van tests in software ontwikkeling is onder te verdelen in twee groepen [16]: • Tests om te controleren of de software correct werkt, zoals de unit test en de integratie test. • Tests door de opdrachtgever of eindgebruiker, waarbij gekeken wordt of de software aan de eisen voldoet, veelal acceptatietest genoemd. Tijdens de realisatie is de eerste vorm van testen uitgevoerd. In een evolutionair ontwikkelproces zijn deze tests een integraal onderdeel van de realisatie fase. Daarom wordt in dit hoofdstuk met testen hoofdzakelijk de acceptatietest bedoeld. De acceptatietest heeft tot doel het ontwikkelde prototype voor te leggen aan een groep ervaren Visual Objects gebruikers. Deze gebruikers moeten een vergelijking kunnen maken en dienen aan te geven of het prototype een verbetering is ten opzichte van de traditionele werkwijze. De vergelijking dient gericht te zijn op de volgende aspecten: • Kwaliteit van het eindproduct (aantal fouten in de software) • Ontwikkelsnelheid • Mogelijkheden van hergebruik • Ondersteuning evolutionair ontwikkelproces. • Verbeterde gebruikers interface voor ontwikkelaars. Naast deze aspecten zijn de overige aspecten te vinden in het hoofdstuk Requirements. De aandachtspunten zoals beschreven tijdens de requirements zijn tijdens het gehele traject gebruikt als checklist. Ook in latere fasen is de lijst van punten regelmatig aangepast en aangevuld. Daarom kan de beschrijving van de requirements tijdens het testen gebruikt worden als uitgangspunt

8.2 Keuze van teststrategie Omdat de toepassing niet ontwikkeld is voor een opdrachtgever of voor IMN intern moet voor het testen een andere strategie gezocht worden. Het is hierbij vanzelfsprekend van belang dat de testresultaten een betrouwbar beeld geven van de vergelijking tussen traditionele werkwijze en de DDO toepassing. Er zijn vele strategieen denkbaar. In onderstaande paragrafen worden een aantal strategieen met elkaar vergeleken en wordt er één gekozen die wordt toegepast. Introductie als shareware De toepassing kan als shareware product aangeboden worden aan geinteresseerden. Een shareware versie is een applicatie welke eerst getest kan worden en al het product bevalt wordt een bedrag betaald aan de maker. Meestal is een beperking in de shareware versie opgenomen waardoor de gebruiker gestimuleerd wordt het verschuldigde bedrag te betalen. Het ontwikkelde prototype biedt mogelijkheden voor deze opzet. Mede door het gebruik van de engelse taal in de toepassing. Deze strategie heeft de volgende voor- en nadelen: Voordelen • De toepassing wordt door een groot aantal gebruikers getest, waardoor het mogelijk is veel onvolkomenheden te registreren • Door het gebruik van de shareware werkwijze wordt een lijst van geregistreerde gebruikers opgebouwd. Dit geeft een goede indicatie van het gebruik van de toepassing. • De opzet van de test is eenvoudig. Een gebruiker accepteert of verwerpt het product Nadelen • Een shareware product dient verder uitontwikkeld te zijn dan een prototype. Naast een complete toepassing zijn aspecten als helpfiles, support en marketing van belangrijk. • Door de opzet van de test is het moeilijk meetbaar op welk aspect een gebruiker de toepassing acccepteert of verwerpt.

38


Communicatie met de geregistreerde gebruikers is mogelijk. Echter het zal in veel gevallen moeilijk zijn een reactie te ontvangen van deze gebruikers.

Acceptatietest via compuserve/Internet Op internet en compuserve is een actieve groep Visual Objects gebruikers te vinden. Deze groep wisselt regelmatig kennis en ervaring uit over verschillende aspecten van de programmeertaal. Regelmatig zijn dan ook product evaluaties en beta tests te vinden op bijvoorbeeld compuserve. Voordelen • De Visual Objects gebruikers die op compuserve actief zijn zijn veelal enthousiast en bereid om tests uit te voeren. • Het is mogelijk om een grote groep gebruikers als steekproef te kiezen. Hierdoor is het mogelijk een betrouwbare resultaten te krijgen van de acceptatietest. • Er ontstaat veelal discussie en er worden extra wensen geformuleerd door de gebruikersgroep. Deze wensen kunnen eenvoudig gebruikt worden als input voor verbeteringen van het prototype. Nadelen • De testers zullen veelal vanuit de eigen werksituatie naar het product kijken. Veel reacties zullen dan ook gebaseerd zijn op wensen om aanpassingen in de eigen werksituatie te bewerkstelligen. • De gebruikersgroep kan erg groot worden, hierdoor kan de werklast om de gebruikersgroep te groot wordt voor degene die het product geintroduceerd heeft. • Bereiken van de gebruikers kan een probleem vormen. Met name voor evaluatie van aspecten minder van belang voor de testers. Selectieve groep van testers In Nederland is een kleine, maar actieve, groep Visual Objects gebruikers. Deze groep kan benaderd worden met het verzoek dit product te testen op basis van de criteria zoals geformuleerd in de requirements. In deze groep kunnen een aantal ervaren ontwikkelaars benaderd worden. Deze ontwikkelaars kunnen via directe communicatie betrokken worden bij de acceptatietest an de DDO toepassing. Voordelen • Een mogelijk grote betrokkenheid van de testers bij het uitvoeren van de testers. • Het gebruik van een prototype is goed mogelijk. Door de korte communicatielijnen is het mogelijk om de toepassing in detail te testen op de relevante aspecten. • De gebruikersgroep is eenvoudig te bereiken en het krijgen van een response is relatief eenvoudig. • Het is mogelijk om kwalitatieve aspecten van de toepassing te onderzoeken, bijvoorbeeld door het gebruik van interviews. • De testers moeten intensief worden begeleidt wat eenvoudiger mogelijk is bij een kleine groep gebruikers. Nadelen • De gebruikersgroep is klein waardoor de resultaten mogelijk minder betrouwbaar zijn omdat mensen met elkaar kunnen overleggen.. • De testers moeten bereid zijn om een inspanning te leveren zonder dat daar direct iets tegenover staat. Op basis van bovenstaande punten wordt gekozen voor de laatste optie: de groep van testers. Ondanks het bezwaar van de kleine steekproef in deze strategie is het voordeel van de betrokkenheid belangrijk. Omdat de DDO toepassing een prototype betreft. Daarnaast wordt van de testers een relatief grote inspanning gevraagd. Een grote steekproef is hierdoor moeilijk realiseerbaar.

8.3 Opzet van de test De opzet van de test dient zodanig te zijn dat met name de kwalitatieve aspecten van de DDO toepassing onderzocht kunnen worden. Keuze van deelnemers aan de testgroep De deelnemers aan de test worden gezocht onder de Nederlandse Visual Objects gebruikers. Reden hiervoor is dat er een vergelijking gemaakt wordt tussen de traditionele en de DDO werkwijze. Omdat andere ontwikkelomgevingen veelal op een andere manier zijn opgezet, kan het vergelijken moeilijk zijn.

39


In de Nederlandse gebruikersgroep van Visual Objects dient gezocht te worden naar ontwikkelaar met de volgende eigenschappen: • Ervaren in het gebruik van Visual Objects. Deze ontwikkelomgeving is het dagelijks gereedschap van de ontwikkelaar. • Beschikken over tijd om de tests uit te voeren • Betrokkenheid bij het probleem of bij de ontwikkelomgeving. Introductie van het prototype bij de testgroep Het DDO prototype wordt geïntroduceerd bij de testers middels een bijeenkomst. In deze bijeenkomst wordt de probleemstelling toegelicht. Daarnaast wordt het prototype getoond en worden de belangrijkste onderdelen gedemonstreerd. Verder wordt uitgelegd hoe het testtraject is opgebouwd en wat van de testers verwacht wordt. Het prototype dat getest wordt bestaat uit een executable met een DDO voorbeeld. Als voorbeeld is een Besteladministratie genomen welke ook als voorbeeld bij Visual Objects te vinden is. De DDO toepassing bevat geen beperkingen. Hierdoor kunnen de testers eventueel andere toepassingen ontwikkelen. Ondersteuning tijdens de test De testers krijgen ongeveer zes weken de tijd om de toepassing te testen. Tijdens deze periode hebben zij de beschikking over het product. Hierbij wordt ervan uitgegaan dat zij de beschikking hebben over een versie van Visual Objects zodat een vergelijking mogelijk is. Gedurende de testperiode kunnen de testers via email contact zoeken voor vragen en of opmerkingen. De coördinator draagt er zorg voor dat dagelijks zijn email gecontroleerd wordt en dat op korte termijn antwoord gereageerd wordt. Opzet van de vragenlijst Aan het einde van de test ontvangen de testers een vragenlijst. De vragenlijst is uitgewerkt op basis van de punten van de requirements. Hierbij is de embedded module – beheersmodule indeling overgenomen. De vragenlijst bestaat uit een aantal open vragen. Bij deze open vragen wordt van de testers gevraagd redenen te geven waarom zij bepaalde onderdelen een verbetering of verslechtering vinden. Naast de gestelde vragen kunnen de testers eigen aandachtspunten aangeven. In bijlage 10 is een vragenlijst te vinden. In bijlage 11 vindt u de antwoorden van de geënquêteerden.

8.4 Resultaten van de test In onderstaande tabel vindt u de score van de terugontvangen vragenlijsten. In de bijlage 11 zijn de antwoorden op de vragen integraal opgenomen. Beheersmodule A B Totaal 1.1 Is het ten opzicht van Visual Objects beter mogelijk om met de data-dictionary evolutionair te ontwikkelen.? 1.2 Is het mogelijk om de ontwikkeltijd van een applicatie te verkorten?

+

+

+

+

+

+

1.3 Denkt u dat het ontwikkelen met een data-dictionary het aantal fouten in een opgeleverde applicatie kleiner is

+

+

+

1.4 Ziet u mogelijkheden om data-dictionary bestanden te hergebruiken in uw projecten. 1.5 Wordt de Integriteit voldoende gehandhaafd het verwijderen en toevoegen van eigenschappen en of objecten in de data-dictionary? 1.6 Biedt de data-dictionary een gebruikersinterface welke de werkzaamheden voor de applicatieprogrammeur op een logische wijze concentreert, zodat de arbeidsproductiviteit stijgt 1.7 Kan de applicatieprogrammeur eenvoudiger zoeken en selecteren naar de diverse entiteiten in de data-dictionary? 1.8 Is het aanmaken van formulieren voor klantapplicaties verbeterd ten opzichte van de werkwijze in Visual Objects 1.9 Biedt de data-dictionary voldoende ondersteuning voor complexe werkzaamheden?

+/- +/-

-

+/- +/-

+/-

+

+

+

+/- +/-

+/-

+

+

+

+

+

+

Embedded module 2.1 Ervaart u dat het opstarten van de DDO applicatie sneller is ten opzichte van een normale VO applicatie.

40


2.2 Ervaart u het als een voordeel dat de eigenschappen van objecten in gegevensbestanden opgeslagen worden. 2.3 Is het mogelijk om wijzigingen op afstand aan te brengen aan een klantapplicatie?

+

+/-

+

+

+

+

2.4 Kunnen fysieke bestandsstructuren vergeleken worden met de structuren in de datadictionary gegevensbestanden? Tabel 12 Testresultaten

+

+

+

Uit de resultaten blijkt dat de testers de DDO toepassing ten opzichte van de traditionele werkwijze positief waarderen. Met name op het gebied van opbouw en concept van de toepassing zijn beide testers positief. Over het handhaven van de integriteit zijn de testers minder positief. Volgens de testers is het principe niet ver genoeg uitgewerkt en is het nog steeds mogelijk entiteiten te verwijderen waardoor een inconsistent objectmodel ontstaat. Daarnaast wordt de validatie in een aantal situaties als hinderlijk ervaren. De embedded module wordt over het algemeen positief beoordeeld. De testfase in het algemeen laat zien dat de opbouw van het testplan belangrijk is. Er zijn drie programmeurs geselecteerd voor het testen van het programma. Vanwege tijdgebrek is één programmeur niet bij de introductie van de applicatie geweest. Hierdoor ging het testen van de toepassing moeizaam, hij rapporteerde een groot aantal bugs en deed suggesties voor verbeteringen, maar kwam onvoldoende aan het testen van het concept DDO toe. Hij is gestaakt met het uitvoeren van de tests en heeft de vragenlijst niet teruggestuurd. Naast de introductiebijeenkomst is het belangrijk geweest dat er ondersteuning was tijdens de tests. Regelmatig ontstonden er vragen en uit de resultaten blijkt dat een aantal opties niet getest zijn omdat de programmeurs onbekend waren met de mogelijkheden. Uit bovenstaand punt blijkt dat deze vorm van testen goede resultaten te behalen zijn, maar dat het product niet als prototype, maar als verkoopbaar product (dus inclusief handleiding, helpfiles en helpdesk) getest moet worden. Veel vragen tijdens de ondersteuning hadden betrekking op het gebruik en minder op het concept. Daarnaast werden veel suggesties gedaan hoe de gebruikersinterface verbeterd kon worden terwijl dit voor het prototype minder relevant is. Mogelijk dat in een toekomstige versie van het prototype het testplan meer geïntegreerd dient te worden. Bijvoorbeeld door de vragenlijst in de vorm van een DDO toepassing op te bouwen, en de verschillen tussen de DDO versie en de traditionele werkwijze expliciet te maken.

41


9 Evaluatie Aan het einde van dit project waarin Data Dictionary Objecten zijn geanalyseerd, ontworpen, gebouwd en getest is een moment van bezinning op zijn plaats. Met bezinning wordt bedoeld een moment van terugkijken én van vooruit kijken. Dat moment wordt verwoord in dit hoofdstuk. De volgorde in dit hoofdstuk is gebaseerd op de gevolgde werkwijze in de opdracht. Hierdoor is de volgorde veelal gelijk aan de hoofdstukindeling van dit verslag.

9.1 Consistentie van het objectmodel De consistentie van een objectmodel is een probleem in veel ontwikkeltrajecten. In dit verslag is een beeld gegeven van ontwikkeltrajecten waar middels RAD administratieve toepassingen ontwikkeld worden. In deze situatie veroorzaakt inconsistentie dat er eindproducten worden aangeleverd welke niet aan alle kwaliteitseisen kunnen voldoen. Met name robuustheid en correctheid van het eindproduct staan onder druk. DDO kan hier een bijdrage aan leveren. Deze opdracht behandelt slechts een klein gedeelte van het werkgebied. Voor andere werkgebieden zal onderzocht moeten worden in welke mate inconsistentie van het objectmodel een probleem vormt. Ik vermoed dat ook in andere werkvelden van software ontwikkeling dit probleem voorkomt. In onderstaande opsomming wil ik een aantal voorbeelden noemen welke mijn vermoeden staven: • Relationele databases voor Mobile en Embedded Computing. Dit zijn databases geschikt voor kleine toepassingen zoals handheld computers en databases ingebouwd in allerhande apparaten (bijvoorbeeld koffieautomaten). Deze databases hebben veelal geen interface met gebruikers, ze zijn onder andere opgebouwd uit tabellen, kolommen, indexen, triggers en stored procedures. Hierin kunnen dezelfde inconsistenties voorkomen als genoemd in de probleemstelling. In de stored procedures en triggers kan verwezen worden naar kolommen die in de actuele database niet meer bestaan. Een oplossing voor dit probleem kan liggen in het aanpassen van de Data Definition Language van deze databases. • Het ontwikkelen van inter- en intranettoepassingen is momenteel een belangrijke tak in de automatisering. Kijken we naar de eenvoudigste manier van internettoepassingen, de statische HTML pagina’s, dan zien we dat deze pagina’s bestaan uit tekst en afbeeldingen en hyperlinks. Met deze hyperlinks is het mogelijk om naar andere internetpagina’s te bladeren (browsen). Helaas zijn de huidige hulpmiddelen voor het ontwikkelen van internetpagina’s niet in staat om consistentie van de hyperlinks te bewaken. Een hyperlink kan hierdoor verwijzen naar een internet pagina welke niet bestaat. • Momenteel staat Component Based Development (CBD) volop in de belangstelling. CBD wordt gezien als de opvolger van OO. Bij CBD wordt gekeken of een object applicatiespecifiek is of generiek toepasbaar is. Is het laatste het geval dan wordt het object een zelfstandige entiteit: een component. Componenten zijn er in alle soorten en maten. Kleine componenten die een stukje functionaliteit bieden, zoals een Kalender besturingselement en grote componenten zoals bijvoorbeeld voor de berekening van pensioenen. Consistentie tussen applicaties en componenten en componenten onderling is niet gewaarborgd. Omdat een component een op zich staande entiteit is, kan deze eenvoudig aangepast of verwijderd worden zonder dat de gebruikende entiteiten geattendeerd worden op de wijziging. Er ontstaat eenvoudig inconsistentie van het object model. Uit bovenstaande punten blijkt dat het probleem van inconsistente objectmodel in meerdere werkvelden voorkomt en door nieuwe ontwikkelingen eerder vergroot dan verkleind wordt. Onderzoek naar RDO, HDO en CDO kan hierover duidelijkheid brengen. De afkortingen staan voor: Relationele Dictionary Objecten, HTML Dictionary Objecten en Component Dictionary Objecten.

9.2 OO analyse- en ontwerpmethoden. In deze opdracht is veel tijd besteed aan het methodisch kiezen van een analyse- en ontwerpmethode. Het vooraf kiezen van de te gebruiken ontwerpmethode is belangrijk geweest. Door een aantal ontwerpmethoden voor de daadwerkelijke ontwerpopdracht onderling te vergelijken krijgt men een beeld welke activiteiten tijdens het analyseren en ontwerpen van de DDO belangrijk zijn. Door de te verwachten werkzaamheden te matchen met de ontwerpmethode is het mogelijk voor een te ontwikkelen systeem de juiste methode te kiezen. Voor deze keuze zou een beslissingstabel of vragenlijst een handig hulpmiddel zijn. Op basis van deze beslissingstabel kan dan voor ieder ontwikkeltraject de juiste ontwerpmethode gekozen worden. In toekomstige opdrachten is waarschijnlijk het beeld van de te onderzoeken OO methoden duidelijk gewijzigd. Het blijkt dat OO methoden snel verouderen in de ontwikkeling. Op dit moment zijn andere methoden duidelijk in opkomst. Bijvoorbeeld Unified Modeling Process van Rational en Catalasys van Desmond D’Souza. In een actuele opdracht zouden deze methoden zeker opgenomen moeten worden in het onderzoek.

42


In deze opdracht is gekozen voor OMT als ontwerpmethode. Voor deze opdracht is dat een terechte keuze geweest. OMT biedt voldoende ondersteuning middels notatie en fasen en stappen. Echter ieder ontwikkeltraject heeft andere aspecten waarbij de keuze voor een andere ontwerpmethode te rechtvaardigen is.

9.3 Analyse en Ontwerp De stappen welke in de OMT methode gevolgd moeten worden zijn voor deze opdracht veelal relevant. Een aantal stappen is minder essentieel, of kunnen gecombineerd worden. Echter deze stappen kunnen op eenvoudige wijze overgeslagen worden, zonder dat dit negatieve gevolgen heeft voor de andere stappen. Met name de mogelijkheid om iteratief te werken is voor deze opdracht positief geweest. Het objectmodel is begonnen met een aantal klassen en later in een aantal stappen verder uitgebreid. De OMT methode, evenals de andere geëvalueerde methoden, schoot te kort op het terrein van Mens Machine Interface (MMI). In deze opdracht is in de beheersmodule de MMI belangrijk. De opzet is dat de applicatieontwikkelaar de gehele dag met de DDO toepassing werkt. Naast de statische, functionele en dynamische view zou een presentatie view voor de objecten erg belangrijk zijn. In de methodische stappen zouden een aantal MMI fasen handig zijn. Een aantal mogelijk stappen zijn: • Groepeer de attributen van een object • Geef aan of een associatie in de MMI zichtbaar is • Kies een presentatiestijl (een template) voor klassen, attributen, methoden en associaties. • Kies de presentatie (het besturingselement) behorend bij de entiteit • Maak een scherm- of rapportontwerp. Naast een beschrijving van de stappen kan de notatie uitgebreid worden met een MMI notatie. Hierbij kan gedacht worden aan een notatie voor de presentatie van objecten en attributen, maar ook aan een notatie die generiek is voor de diverse MMI media. Echter uitwerking van deze presentatieview valt buiten het bestek van deze opdracht. Hierbij kan een onderzoek naar de verschillende OO frameworks voor presentatie uitgevoerd worden, zoals bijvoorbeeld de MVC (Model View Controller) of de EventDispatcher. In de opdracht is een klein gedeelte van het objectmodel waar applicatieprogrammeurs mee werken uitgewerkt. De keuze voor een deel van het objectmodel is bewust gemaakt. In deze opdracht is het principe van Data Dictionaries onderzocht. Echter het objectmodel dient uitgebreid te worden met onder andere de volgende klassen om echt bruikbaar te zijn als hulpmiddel: • Rapporten en etiketten • Menu’s en taakbalken • Listview en treeviews • Subformulieren en subrapporten. Waarschijnlijk leidt de uitbreiding van het objectmodel niet tot andere inzichten betreffende DDO, maar zeker is dit niet. Bij uitbreiding is het aan te bevelen gebruik te maken van Design Patterns (DP). In het ontwerp kunnen een aantal DP herkend worden. Door deze toe te passen wordt het ontwerp mogelijk eenvoudiger te realiseren en kan meer gebruik worden gemaakt van hergebruik.

9.4 Realisatie In de realisatie is het ontwerp gebouwd. Daar zou ik een apart hoofdstuk aan kunnen wijden. De realisatie is geen sinecure geweest. Hiervoor zijn een aantal oorzaken te noemen: • De complexiteit van de materie, met name het tijdens runtime creëren van formulieren uit de DDO. • Het MS-Foxpro databaseformaat dit maakt gebruik van externe indexbestanden wat inconsistentie kan veroorzaken. • De ontwikkelomgeving Visual Objects, met name in combinatie met bovengenoemde punten ontstaan regelmatig systeem- en toepassingsfouten. Naast de negatieve punten zijn ook een aantal positieve aspecten te noemen. Belangrijkste positieve punt is vanzelfsprekend het feit dat er een werkend prototype opgeleverd is dat getest en gebruikt kan worden. Daarnaast is de performance van de toepassing goed te noemen. De verwachting aan het begin van het traject was dat dit een essentieel knelpunt zou zijn. In toekomstige opdrachten waarbij DDO ingezet worden is het mogelijk een aantal wegen in te slaan. De belangrijkste zijn:

43


• •

Toepassen van DDO in niet administratieve toepassingen. Bijvoorbeeld in ingebedde software en componenten zijn DDO goed toepasbaar. Zo kan een component met DDO haar toestand ontlenen op basis van de informatie uit de DDO. Een component is hiermee persistent te maken, zoals bijvoorbeeld entity beans in Java. DDO zijn in deze opdracht toegepast in de Visual Objects ontwikkelomgeving. Echter ook andere omgevingen zoals Java, Smalltalk, Delphi en Powerbuilder lenen zich voor het gebruik van DDO. Het DBMS (MS-Foxpro) zoals toegepast kan vervangen worden door een andere. Hierbij kan gedacht worden aan op SQL gebaseerde relationele databases of OO databases.

9.5 Werken met een DDO toepassing In deze paragraaf wordt een beeld gegeven van de ervaringen bij het werken met een DDO toepassing. Deze beschrijving is gebaseerd op de ervaringen van de testers en van de ontwikkelaar. Het werken met een DDO toepassing heeft een aantal voordelen ten opzichte van de traditionele werkwijze. De belangrijkste positieve punten zijn: • De applicatieprogrammeur wordt geattendeerd op het maken van fouten, waardoor het objectmodel consistent blijft. Tijdens het werken is dit als positief ervaren. In veel gevallen kwamen de inconsistentie meldingen op onverwachte momenten. • De mogelijkheid om met meerdere ontwikkelaars tegelijkertijd aan een toepassing te werken zonder extra handelingen, zoals in- en uitchecken, te hoeven verrichten is positief. • De screen painter ondersteunt de gebruiker beter in het bouwen van schermen ten opzichte van de Visual Objects screen painter. • Iteratief werken worden beter ondersteund. Met name de optie dat de structuur en opbouw van de tabellen al bekeken kunnen worden zonder dat er een schermen ontworpen zijn is positief voor een RAD werkwijze. De DDO applicatie is goed geschikt om samen met een eindgebruiker een ontwerp van de te ontwikkelen toepassing te maken. Werken met de DDO toepassing kent ook nadelen. In onderstaande opsomming een aantal punten: • De consistentie controle werkt in een aantal gevallen nadelig. Soms weet de applicatieprogrammeur dat het object model tijdelijk inconsistent is. Echter de controle verbiedt dan de wijziging door te voeren. Hierdoor wordt de vrijheid van werken voor de ontwikkelaar in een aantal gevallen beperkt. • De opbouw van de Data Dictionary is statisch. Bij het ontwikkelen van toepassingen is in een aantal gevallen behoefte aan andere attributen en methoden voor de data dictionary objecten. Een DDDO (dynamische DDO) is mogelijk de oplossing. • De testers vinden dat in de DDO applicatie een aantal opties ontbreken. De belangrijkste zijn: een mogelijkheid om de consistentie controle aan en uit te kunnen zetten en aan het einde middels een Consistancy opdracht deze controle in batch uit te voeren. En de mogelijkheid om aan het einde van een ontwikkeltraject alsnog programmacode te genereren op basis van de DDO inhoud. Op basis van bovenstaande punten kan geconcludeerd worden dat de DDO toepassing op een aantal punten beter is dan de traditionele werkwijze. Echter uit de tests blijkt dat er op het vlak van model consistentie meerdere wensen bestaan. Twee aspecten kunnen hiertoe een bijdrage leveren. Allereerst het genereren van programma code op basis van de inhoud van de datadictionary. Ten tweede kan een gradatie van de consistentie controle toegevoegd worden. Hierbij kan in de DDO toepassing ingesteld worden wanneer er gecontroleerd wordt en in welke mate er consistentie controle plaatsvindt, bijvoorbeeld: • Geen controle • Geen controle en loggen van inconsistenties • Waarschuwen zonder aanpassen • Waarschuwen met aanpassen • Aanpassen zonder waarschuwen

9.6 Tot slot Concluderend kan gesteld worden dat DDO in administratieve toepassingen een aantal voordelen heeft ten opzichte van de traditionele werkwijze. Met name de mogelijkheid een object model consistent te houden gedurende de het ontwikkeltraject is gunstig voor kwalitatief betere (minder fouten) software. Daarnaast is het aspect van hergebruik goed mogelijk in een DDO toepassing. Echter de DDO dient verder uitgewerkt te worden en eventueel toegepast te worden in andere werkvelden om zich verder te bewijzen.

44


Literatuurlijst 1.

Bertenshaw, M. Datadriven programming under VO, SDGN, Winterswijk, In Conference to the Max 1997, 1997.

2.

Bigs, P., A Survey of Object-Oriented Methods, Univerity of Durham, (Internet Site).

3.

Blaha, M. & W. Premerlani, Object-oriented modeling and design for database applications, Prentice Hall, Englewood Cliffs, 1997.

4.

Boersma, T., Bedrijfsobjecten implementeren met behulp van VO, SDGN, Winterswijk, In: Conference to the Max 1996, 1996.

5.

Booch, Grady, Object oriented analysis and design with applications second edition, Cumming publishing, Redwood, 1994.

6.

Booch, Grady, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language Use Guide, Unified Modeling Language Reference Manual, and The Objectory Software Development Process, , In: The Addison-Wesley Object Technology, Wokingham.

7.

Brinkkemper, S. et al, Method Engineering Encyclopedia, TU Twente, (internet site).

8.

Carmichael, Andy, Object Development Methods, SIGS Books, New York, 1994.

9.

Computer Associates, CA-Visual Objects getting started guide, Computer Associates, Islandia, 1996.

10. Cooper, A., About face: The essentials of user interface design, IDG Books, Foster City, 1995. 11. Fowler, Martin, Analysis patterns: Reusable Object Models, Addison Wesley, Reading, 1997. 12. Gamma, Eric et al, Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, Reading, 1995. 13. Ghezzi, C. M. Jazayeri & D. Mandrioli, Fundamentals of software engineering, Prentice Hall, Englewood Cliffs, 1991. 14. Hacquebard, E.N., et al, Informatiesystemen, inleiding in het ontwerpen, Open Universiteit, Heerlen, 1983. 15. Informatie Management Nederland, IMN’s drielagen architectuur, Informatie Management Nederland, z.p., z.j.. 16. Jacobson, I & M. Christerson, P. Jonsson, G Overgaard, Object Oriented Software engineering, a user case driven approach, Addison Wesley, Wokingham, 1992. 17. Kilburn, J., Data-Driven programming in CA-Visual Objects, Computer Associates, Islandia, In: CA Technicon 1997, 1997. 18. Lazzaratto, P., Implementing Data-Driven Classes with CA-Visual Objects 2.0, Computer Associates, Islandia, In: CA Technicon 1997, 1997. 19. Lemmen, K.A.M. et al, Methodologie van informatiesysteemontwikkeling, Open universiteit, Heerlen, 1993. 20. Microsoft Press, The windows interface guidelines for software design, Redmond, 1995. 21. Power, J., Datadriven programming, SDGN, Winterswijk, In: Conference to the Max 1996, 1996. 22. Quatrani, Terry, & Michael Chonoles, Succeeding with the Booch and OMT Methods: A Practical Approach, In: The Addison-Wesley Series in Object-Oriented Software Engineering, Wokingham.

45


23. Rumbaugh, J, M. Blaha , W. Premerlani, F. Eddy & W. Lorensen, Object oriented modeling and design, Englewood cliffs,1991. 24. Straley, S.J. CA-Visual Objects Encyclopedia, Sirius Press, San Francisco ,1997. 25. Straley, S.J. CA-Visual Objects for Clipper and xBase programmers, Addison Wesley, Reading, 1995. 26. Spence, R. CA-Visual Objects, Sybex, San Francisco, 1995. 27. Verhoef, D., Toolvision 1998, Array publications, Alphen aan de Rijn, 1997. 28. Wijnen, G., W. Renes & P. Storm, Projectmatig werken, Open Universiteit, Heerlen, 1993. 29. Williams, J., What every software manager must know to succeed with object technology, Sigs books, New York, 1995. 30. Wynn, E. Advanced Data Server handling in CA Visual Objects, Computer Associates, Islandia, In: CA Technicon 1997, 1997.

46


Verklarende woordenlijst Besturingselement BOM (Business Object Model) Embedded module Container Data Dictionary Data-Driven DDO (Data-Dictionary Objecten) DLA (drie lagen architectuur)

Een entiteit op een formulier of rapport in een applicatie dat gegevens uit de applicatie weergeeft. Denk hierbij aan invoervakken, labels en keuzelijsten. Object model dat een beschrijving geeft van het werkveld waarop een applicatie betrekking heeft. Onderdeel van de DDO toepassing dat de persistente objecten leest ten behoeve van de klantapplicatie Een object dat een groep gelijksoortige objecten bevat waardoor het mogelijk is te zoeken en te navigeren in een groep objecten. Een data-dictionary bestaat uit gegevensbestanden waarin een deel van de applicatielogica is opgeslagen Werkwijze waarbij een deel van de applicatielogica vanuit gegevensbestanden afkomstig is Een DDO zijn objecten welke toegang bieden tot een data-dictionary.

Architectuur waarbij de objecten worden ingedeeld in de drie lagen bedrijfsdomeinlaag, gebruikerslaag en presentatielaag. IDE (Integrated Developers Combinatie van editors welke het gereedschap vormen van de Environment) applicatieprogrammeurs Klantapplicatie of Applicatie bestaande uit een framework van objecten waarbij de toestand van opsporingsapplicatie deze objecten afkomstig is uit DDO gegevensbestanden. MDI (Multiple Document MS-Windows standaard waarbij het mogelijk is meerdere formulieren te openen Interface) in een applicatie. Bijvoorbeeld MS-Word waarin meerdere documenten bewerkt kunnen worden Metadata Data welke de structuur van andere data beschrijft. Zoals bijvoorbeeld een catalogus van een bibliotheek de boeken in de bibliotheek beschrijft MMI (Mens Machine Weergave van de gegevens uit een applicatie aan de gebruiker van de Interface) desbetreffende applicatie. Met name de eisen die gesteld worden aan deze weergave hebben betrekking op de MMI. Object model Model waarin een beschrijving wordt gegeven van een aantal objecten met hun eigenschappen, gedrag, associaties en functionaliteit. OMT Object Modeling Technique zie bijlage 1 Persistente objecten Objecten waarbij de toestand opgeslagen kan worden in gegevensbestanden. RAD (Rapid Application Werkwijze waarbij in nauwe samenspraak met eindgebruikers een applicatie in Development) een aantal iteraties wordt ontwikkeld. RDBMS (Relational DataBase Opslag van gegevens in aan elkaar gekoppelde tabellen. Waarbij de redundantie Management System) van gegevens door normalisatie verminderd kunnen worden. Hieraan is functionaliteit als handhaven van integriteit toegevoegd Voorbeelden zijn Sybase en Oracle. Repository Een repository is een bestand dat definitie informatie bevat over een applicatie zoals requirements, specificaties, ontwerpen en on line documentatie. Beheersmodule applicatie Onderdeel van de DDO toepassing dat het DDO objectmodel beheert of aanpast Visual Objects Object georiënteerde programmeertaal en ontwikkelomgeving toegepast in deze opdracht Xbase Opslagprotocol voor gegevens welke op relationele wijze behandeld kunnen worden. Kenmerkend is dat iedere tabel in een afzonderlijk bestand is opgeslagen

47


Bijlagen Bijlage 1 OOADA (Booch) Historie en toekomstperspectief De Booch methode is ontstaan aan het begin van de jaren 90. De eerste publicatie is verschenen in 1991 en heeft als titel: "Object Oriented Design with Applications". Vervolgens heeft Booch een aantal werkwijzen van James Rumbaugh overgenomen. Dit resulteerde in 1994 tot de publicatie van het boek " Object Oriented Analysis and Design with Applications. De methode van Booch is opgenomen in de Unified Modelling Language (UML), naast OOSE en OMT. Verwacht wordt dat de UML als standaard modelleer taal gaat gelden. De notatie van de UML lijkt sterk op de notatie van OOADA. Projectfasering en methodische werkwijze De fasering van Booch is sterk iteratief. Kenmerkend is dat er sprake is van een macro- en een microproces. Hierbij moet het macroproces gezien worden als het framework. In dit framework wordt tijdens iedere fase een microproces doorlopen. Het macroproces bestaat uit de volgende fasen: Macroproces Conceptualisatie. Het doel van deze fase is de behoeften in kaart te brengen van het probleemgebied. Dit wordt bereikt door een lijst samen te stellen van mogelijk klassen en objecten. Deze lijst, welke ook het eindproduct is van deze fase, wordt in de volgende fasen verder verfijnd. Opstellen model van gewenst gedrag. Doel van deze fase is het gedrag van het systeem modeleren in een domeinmodel en een scenario plan opstellen. In het gedragmodel worden klassen en objecten voor dit domein opgezocht. In scenario planning wordt aangegeven wat de functiepunten in het domein zijn. Is de levenscyclus van objecten bekend dan kunnen state diagrammen opgesteld worden. In het algemeen kunnen scenario's gedrag presenteren en daarom is het mogelijk deze te testen. Eindproduct is een gedetailleerde- en, door een domein expert, gevalideerde beschrijving van het systeem middels modellen en een datadictionary. Architectuur ontwerpen. De voorgaande fasen hebben geleid tot een beeld van de afzonderlijke elementen in het domein In deze fase wordt het ontwerp uitgewerkt in twee richtingen architectuur planning en tactische planning. In de architectuurplanning wordt een domein specifiek applicatie framework opgesteld dat in volgende stappen verfijnd kan worden. Hierbij wordt geprobeerd het systeem op te splitsen in deelsystemen en waar mogelijk in lagen. In de tactische planning worden beslissingen genomen over het vervolgtraject. Eindproduct van deze fase is een prototype of een gedetailleerde beschrijving van de architectuur. Evolutie. Doel van de evolutie is door verfijningen het ontwerp te laten uitgroeien tot een productie systeem. Evolutie komt dus overeen met het eigenlijke productieproces. Iteratieve ontwikkeling is de duidelijke eigenschap van deze fase. Twee activiteiten zijn belangrijk in deze fase te weten: • Toepassen van het microproces • Toepassen van changemanagement Eindproduct van deze fase is een eerste productieversie van het informatiesysteem. Onderhoud Deze fase is eigenlijk een doorloop van voorgaande fase. Uitzondering is dat veranderingen in de architectuur in deze fase niet meer voorkomen. De belangrijkste activiteiten zijn het verwijderen van fouten uit het systeem en het aanbrengen van functionaliteitveranderingen. Eindproduct van deze fase is een aangepaste versie van het informatiesysteem.

48


Microproces Het microproces wordt in iedere fase van het bovengenoemde macroproces toegepast. Het is met name gericht op ondersteuning van een evolutionaire ontwikkeling. Het geeft richtlijnen voor het nemen van tactische beslissingen en het biedt een framework voor het kiezen uit ontwerp alternatieven. De stappen zijn: • Het identificeren van klassen op het momentele niveau van abstractie. • Identificeren van de klasse semantiek • Identificeren van de relaties tussen klassen. • Implementatie van de klassen De fasering biedt mogelijkheden voor een methodische ontwikkeling. Alle fasen vanuit projectmanagement zijn uitgewerkt, waarbij de testfase niet duidelijk herkenbaar zichtbaar is, maar verweven is in de evolutie fase. De fasering is sterk gericht op software ontwikkeling. Modellering Bij de modellering wordt gebruik gemaakt van de volgende modellen welke eigenschappen, functionaliteit en gedrag modelleren: • Class diagram, toont klassen en de relaties tussen klassen. • Object diagram, toont objecten en de toestand van deze objecten in de tijd • Module diagram, voor de verklaring van de opbouw van een systeem • Proces diagram, voor het toewijzen van processen aan processoren toe te wijzen De diagrammen kunnen bestaan uit een diagram met een uniforme notatiewijze of uit een aantal verschillende notatiewijzen. Modelleren van eigenschappen De eigenschappen van klassen en objecten worden getoond in de class diagrams. De notatie voor het statische model is rijk. In onderstaande opsomming zijn de belangrijkste kenmerken weergegeven: • Klassen notatie is eenduidig waarbij het mogelijk is soorten klasse te onderscheiden zoals abstract en concreet of metaklassen. • Het is mogelijk om zowel attributen en eigenschappen van klassen op te nemen in het diagram. Van eigenschappen kunnen multipliciteit en initiële waarde niet genoteerd worden. Vermeldenswaardig is de mogelijkheid om de zichtbaarheid van eigenschappen te noteren. Verder kunnen beperkingen of constraints van klassen worden opgenomen. • In het kiezen van de relaties is de gebruiker vrij. Aan een relatie kan een eigen naam gegeven worden. Daarnaast zijn een aantal standaard relatietypen gegeven zoals: heeft, gebruikt, instantiatie en metaklasse. De multipliciteit van een relatie is te noteren met alle bestaande variaties. Ordening kan niet gemodelleerd worden in de notatie. • Objecten en klassen kunnen meerdere rollen vervullen. Dit wordt gedaan in het modelleren van de relaties, waarbij een relatie dan een eigen naam krijgt. Ook kunnen beperkingen opgenomen worden in relaties welke een verdere verfijning mogelijk maakt. • Naast relaties is het mogelijk om overerving tussen de verschillende klassen te modelleren Modelleren van functionaliteit Modelleren van functionaliteit is minder uitgewerkt in deze methode. Het is mogelijk om in het class diagram op te geven welke berichten en operaties er tussen de klassen verzonden worden. Van deze berichten wordt door een nummer de volgtijdelijkheid de volgtijdelijkheid beschreven. Echter return waarde of type van een operatie kan niet worden omschreven. Daarnaast ontbreekt de mogelijkheid om parameters van operaties in de notatie. Modelleren van gedrag Voor het modelleren van gedrag biedt de methode een tweetal notatiewijzen: het state transition diagram en het interaction diagram. Met het state transition diagram kunnen de veranderingen van klassen op gebeurtenissen worden genoteerd. Interactie diagrammen geven aan hoe gebeurtenissen en operaties in de tijd tussen objecten verlopen.

49


Relatie tussen de modellen Voor het aanbrengen van relaties tussen de verschillende modellen wordt in de methode gebruik gemaakt van een datadictionary. Deze datadictionary doet dienst als een centrale repository waarin alle gegevens worden bijgehouden van de afzonderlijke entiteiten en modellen. Voor deze datadictionary beschrijft de methode voor een aantal entiteiten een template of stramien. Vertalen naar gegevensbestanden In de methode is geen beschrijving gegeven hoe een vertaling kan plaatsvinden naar een database structuur. Daarnaast komen andere aspecten van belang voor het werken met gegevensbestanden niet aan bod. Er wordt enkel melding gemaakt dat bij het werken met databases rekening gehouden moet worden met speciale eigenschappen van deze toepassingen. Interactie met de gebruiker Interactie met de gebruiker komt in de methode niet aan bod. Er wordt geen beschrijving gegeven aan de aspecten van een user interface. Er worden geen richtlijnen gegeven welke ondersteuning kunnen bieden bij het toepassen van de methode op aspecten van Human Computer Interaction. Introductie van lagen en modulen Opsplitsen van modulen is goed ondersteund in de methode. Er is een aparte notatie voor: het module diagram welke aangeeft hoe modulen worden toepast. In deze notatie kunnen verschillende typen modulen worden weergegeven en de relaties tussen de modulen is aan te geven. Het toepassen van lagen wordt genoemd in de methode maar wordt verder niet uitgewerkt of beschreven. Er wordt alleen gemeld dat verschillende klassen in een model op dezelfde laag (niveau) kunnen liggen. Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie De Booch methode is in haar opzet zeer iteratief en gericht op evolutionair ontwikkelen. Hierbij wordt voor deelsystemen het hele traject doorlopen. Van behoefte analyse tot aan implementatie en onderhoud. De modellering van de klassen is duidelijk en sluit aan bij een object georiënteerde realisatie. Er vindt een duidelijke scheiding plaats tussen eigenschappen en operaties. Beperking hierbij is wel dat de operaties niet in detail uitgewerkt kunnen worden. Het opgeven van multipliciteit van de relaties is mogelijk. Er zijn meerdere soorten relaties mogelijk die verder gaan dan gewenst in onze toepassing. De nadruk op de procesmodellering duidt op toepassing van de methode in een ander soort van informatiesysteemontwikkeling. Denk hierbij aan automatentoepassingen en dergelijke, vandaar waarschijnlijk de verwantschap met C++. Het ontbreken van enige verwantschap met persistente objecten is een minpunt voor deze methode.

50


Toepassen deelmodel

Toelichting op het schema • • • • •

Klasse wordt weergegeven door een stervormig vlak Associaties worden weergegeven door lijnen tussen de klassen Uses associatie wordt weergegeven door een lijn met open rondje Contains associatie (aggregatie) wordt weergegeven met een dubbele lijn met gesloten rondje Inheritance wordt weergegeven met een enkele lijn met pijlpunt.

51


Bijlage 2 OMT (Rumbaugh) Historie en toekomstperspectief De OMT methode is ontstaan in 1987. Het is ontwikkeld door James Rumbaugh en Mary Loomis. Uitgangspunt was het ontwikkelen van een notatie om programmaontwerp en databasemodellering te combineren. De methode is voor het eerst gepresenteerd op OOPSLA 87. In 1991 is de methode gepubliceerd in het boek Object Oriented Modeling and Design. In dezelfde periode zijn Blaha en Premerlani begonnen met OMT toepassen op relationele databasetoepassingen. Deze toepassing heeft geleid tot een aantal aanpassingen. Hier wordt uitgegaan van de werkwijze van Blaha en Premerlani. Momenteel is de methode van Rumbaugh opgenomen in de Unified Modeling Language (UML) De UML is ruwweg een combinatie van OMT, OOSE en Booch. De UML is een taal die ondersteund wordt door Rational Software Corporation. De methode is niet commercieel, echter de hulpmiddelen zijn dat wel. Projectfasering en methodische werkwijze De methode OMT is iteratief waarbij het mogelijk is de volgende fasering te onderscheiden: Conceptualisatie. In deze fase wordt aangegeven wat de grenzen van het informatiesysteem zijn. Daarnaast wordt een behoefte analyse uitgevoerd. Daartoe dienen een aantal vragen beantwoord te worden: • Voor wie is de applicatie? • Welk probleem lost het op? • Waar wordt het gebruikt? • Wanneer is het nodig? • Waarom is het nodig? • Hoe gaat het werken? Het eindresultaat van deze fase is een uitspraak over de vereisten van de applicatie. Analyse. Tijdens de analyse wordt beschreven wat gedaan moet worden, niet hoe het gedaan moet worden. De modellen die ontstaan worden tijdens de ontwerpfasen en de realisatie verder verfijnd en in detail uitgewerkt. Het resultaat van de analyse zijn vier modellen te weten: • Objectmodel voor het beschrijven van de statische samenhang van de objecten. • Dynamisch model voor het weergeven van interacties tussen objecten en hun reacties hierop. • Functioneel model geeft weer wat de operaties zijn van de objecten en welke restricties er gelden voor deze operaties. • Datadictionary is een beschrijving van alle te modelleren entiteiten zoals klassen, relaties, attributen en operaties Het eindresultaat van deze fase is een aantal modellen en de beschrijving van de entiteiten van deze modellen. Systeemontwerp. Tijdens de analysefase is uitgewerkt wat gedaan moet worden. In systeemontwerp wordt begonnen met te beantwoorden hoe het gedaan moet worden. Hierbij is het aangeven van te volgen strategie belangrijk. Ruwweg bestaat deze fase uit de volgende stappen: • Kies een applicatiearchitectuur • Kies de wijze van interactie of gebruik • Welke vorm van gegevensbeheer en -opslag wordt gebruikt en kies de daarbijbehorende DBMS • Zoek naar mogelijkheden voor hergebruik • Kies een representatie van objecten in bij fysieke opslag in bestanden. • Maak keuzen voor de uitwerking van het detailontwerp. Eindresultaat van deze fase zijn de drie modellen van de analyse fase in verder detail uitgewerkt. Daarnaast wordt in verslaglegging en tabellen aangegeven wat de te volgen strategie wordt. Detailontwerp. Tijdens systeemontwerp zijn de strategische aspecten aan de orde gekomen. Tijdens deze fase worden de specifieke beslissingen genomen over de afzonderlijke klassen en methoden. Details op DBMSniveau worden echter uitgesteld tot de implementatiefase.

52


Het objectmodel uit de analyse fase wordt getransformeerd van een model naar een gegevenstoepassing. Verder wordt het functionele model vertaald. Dit is veelal naar methoden behorend bij de specifieke klassen. De datadictionary zoals ontwikkeld tijdens de analyse levert hierbij een belangrijke bijdrage Implementatie Tijdens de implementatie worden de producten van de voorgaande fasen vertaald in een bestandsstructuur en programmacode. De implementatie wordt beschreven in de vorm van een aantal goed uitgewerkte voorbeelden. Echter van een methodische beschrijving van deze fase is geen fase De fasen testen en onderhoud worden in de methode niet uitgewerkt. Modellering Modelleren van eigenschappen In de OMT methode is met name het statisch model in detail uitgewerkt. In de class- en object diagrammen is het mogelijk om objecten en relaties uit te werken. Er zijn meerdere relaties te noteren. Allereerst de aggregatie relatie binaire, en tertiaire relaties, waarbij de rol van iedere klasse kan worden beschreven. De multipliciteit van de relaties varieert van 0 tot oneindig, waarbij alle variaties mogelijk zijn. Bij een meervoudige relatie is het daarnaast mogelijk om een ordening op te geven. Vermeldenswaardig is de mogelijkheid om "exclusive or" relaties op te geven. Vanzelfsprekend is het mogelijk om overerving in het model op te nemen. Als laatste is de qualifier van een relatie te noemen welke een relatie beperkt in mogelijkheden Attributen of eigenschappen kunnen gedetailleerd worden beschreven. De attributen zijn overzichtelijk opgenomen in het klasse symbool. Van attributen kan de multipliciteit, de beginwaarde, het type en het domein worden beschreven. Ook operaties worden in het klasse symbool opgenomen. Indien gewenst kunnen van een operatie de parameters en de return waarde beschreven worden. Daarnaast is het mogelijk om abstracte operaties op te nemen in het diagram. Modelleren van functionaliteit Voor het modelleren van functionaliteit kan gebruik gemaakt worden van een aantal notatiewijzen. Onder andere zijn beslissingstabellen, Data flow diagrammen en pseudo code te noemen. Daarnaast is er een notatie uitgewerkt de Object Navigation Notation (ONN) welke restricties en stromen in een statisch model beschrijven. Modelleren van gedrag Modelleren van gedrag kan in een tweetal modellen worden uitgewerkt. De event trace diagrammen die weergeven hoe events en operaties volgtijdelijk tussen objecten plaatsvinden. Daarnaast is het mogelijk om state transition diagrammen te gebruiken voor het beschrijven van gerdragswijzigingen van objecten op basis van gebeurtenissen. Relatie tussen de modellen In OMT wordt het toepassen van een datadictionary in detail beschreven. Alhoewel de uitwerking veel vrijheid biedt voor het toepassen van deze data dictionary kan deze toch gebruikt worden voor het leggen van relaties tussen de verschillende modellen. Met name bij het toepassen van ONN is de relatie tussen functionaliteit en eigenschappen duidelijk omdat de ONN in het object model is opgenomen. Vertalen naar gegevensbestanden Voor het vertalen naar gegevensbestanden is in de systeem ontwerp fase een gedetailleerde beschrijving uitgewerkt. Met behulp van een checklist wordt men ondersteund om te komen tot een goede keuze van het databaseplatform. Daarnaast wordt in de voorbeelden een beschrijving gegeven van meerdere soorten toepassingen gebaseerd op een aantal platformen waaronder object databases.

53


Interactie met de gebruiker De interactie met gebruikers wordt beschreven in de systeem ontwerp fase. Hierbij kan gekozen worden uit een aantal vormen van externe controle. Daarnaast wordt de gebruikers interface in de detail ontwerp fase genoemd. Daarnaast worden in een voorbeeld richtlijnen gegeven voor het opzetten van de gebruikersinterface. Waarom deze richtlijnen niet zijn opgenomen in een van de ontwerpfasen is onduidelijk. Introductie van lagen en modulen In de systeem ontwerp fase wordt aangegeven hoe de architectuur moet worden opgezet. Een van de stappen die hier wordt beschreven is het aanbrengen van lagen en partities. Het aanbrengen van deze partities en lagen wordt echter niet ondersteund met een notatie in de vorm van block modellen of module diagrammen. Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie OMT is een iteratieve methode, dit is gunstig voor een object-georiënteerde realisatie. Objecten worden als uitgangspunt genomen voor alle fasen van modellering De mogelijkheden om de multipliciteit en typen van de relaties tussen klassen weer te geven is duidelijk. Bij een goede keuze van een datadictionary is tijdens de realisatie besparing door hergebruik mogelijk. Veel werk is dan reeds tijdens het ontwerp gedaan. Als beperking is te noemen dat het testen van de gerealiseerde toepassing door OMT niet ondersteund wordt.

54


Toepassen deelmodel

Toelichting op het schema • • • • • • • • •

Klasse wordt weergegeven met een rechthoek verdeeld in drie vlakken, bovenste vlak geeft de naam van de klasse, tweede vlak geeft een lijst van eigenschappen, derde vlak een lijst van operaties Multipliciteit van eigenschappen wordt weergegeven met [..] Beginwaarde wordt weergegeven met een = Associaties worden weergegeven met een lijn tussen klassen Ruitvorm in associaitie geeft aan dat het een aggregatie is Driehoek vorm geeft overerving weer Gesloten rondje is een 0..N multipliciteit als de minimum multipliciteit hoger is wordt dit aangegeven op de associatielijn Open rondje is een 1 multipliciteit Extra multipliciteit wordt op de associatie aangegeven met X..Y.

55


Bijlage 3 OOSE (Jacobson) Historie en toekomstperspectief Object Oriented Software Engineering is waarschijnlijk de oudste object-georiënteerde analyse methode. Het eerste ontwerp is in 1967 ontstaan voor het ontwerpen van telecommunicatie systemen. In 1985 is dit uitgewerkt in een methode Objectory genaamd. Vervolgens is de werkwijze verder verfijnd en is het resultaat in 1992 weergegeven in een publicatie, met de titel Object-Oriented Software Engineering, a Use Case Driven Approach. De methode ontwikkelt zich verder. Momenteel wordt de methode gebruikt in combinatie met OMT en Booch in de UML. Projectfasering en methodische werkwijze De methode bestaat uit een aantal duidelijke fasen. In onderstaande opsomming worden de fasen beschreven. In de iedere fase wordt een aantal afzonderlijke modellen uitgewerkt. Analyse. In de analyse fase worden twee modellen opgesteld, het behoeftemodel en het analysemodel. Het behoeftemodel beschrijft de functionele behoefte van uit een gebruikersperspectief en hoe het systeem gebruikt moet worden door eindgebruikers. Het behoeftemodel kan gestructureerd worden in een analysemodel. Hierbij vindt een fasering plaats van een logisch perspectief naar een robuust (robuustheid analyse) en onderhoudbaar systeem. OOSE beschrijft niet met welke stappen deze modellen bereikt kunnen worden. Constructie. De constructiefase bestaat uit twee stappen, ontwerp en implementatie. Ontwerp is onderverdeeld in drie fasen Allereerst wordt de implementatie omgeving geïdentificeerd. Waarbij aangegeven wordt wat de consequenties zijn voor de te kiezen implementatie omgeving. Deze identificatie resulteert in strategische implementatie beslissingen. Vervolgens wordt een eerste ontwerpmodel opgesteld. Hierbij worden objecten uit het analysemodel vertaald in ontwerpobjecten die passen in de implementatie omgeving. Vervolgens wordt een interactiemodel opgesteld waarin uitgaande van "use cases" een beschrijving wordt gegeven van de interactie tussen de ontwerp objecten. Tijdens de implementatie worden de objecten gebouwd in de ontwikkelomgeving of programmeertaal. Dit wordt gemodelleerd in het implementatiemodel. Testen. Het testen begint met het opstellen van een testplan of testmodel. Hierbij worden bestaande tests gebruikt of worden nieuwe test opgesteld. Waar mogelijk wordt gebruikt gemaakt van standaardisatie. Van de resultaten van de tests worden logboeken opgesteld. Vervolgens wordt een beschrijving gemaakt van de uitvoer van de tests en er wordt een keuze gemaakt en er wordt een procedure opgesteld hoe de tests worden uitgevoerd. Daarnaast worden beslissingstabellen opgesteld voor de te ondernemen acties als een test slaagt of mislukt. De logboeken kunnen na het uitvoeren van de test opnieuw gebruikt worden als de tests zijn uitgevoerd. Zoals blijkt is OOSE een methode die bijna elke fase in het ontwikkeltraject uitwerkt. Alleen de onderhoudsfase wordt niet behandeld in de methode. Het gebruik van voorgaande methoden in de latere fasen wordt goed ondersteund. Modellering Modelleren van eigenschappen Voor het statisch model is met name het object model in OOSE belangrijk. In dit model kunnen objecten en hun onderlinge relaties worden genoteerd. Opmerkelijk is dat er drie soorten objecten worden onderscheiden, control, interface en entity objecten. Er zijn meerdere relaties te definiëren zoals bestaat uit (consist of), breidt uit (extends) en relaties die een eigen rolnaam gegeven kunnen worden. Daarnaast kan een object overerven van andere objecten. Als laatste relatie is de message te noemen die apart genoteerd kan worden. Aan relaties kunnen geen eigenschappen gekoppeld worden. Attributen worden in de diagrammen in een apart symbool opgenomen. Op de pijl tussen attribuut en object kan de naam en de minimum en maximum multipliciteit weergegeven worden. Als laatste is van een attribuut het type aan te geven. Een beginwaarde kan niet worden aangegeven.

56


Modelleren van functionaliteit Voor het modelleren van functionaliteit wordt gebruik gemaakt van use case diagrammen welke weergeven hoe gebruikers van buiten af de functionaliteit van het te modelleren systeem gebruiken. Hierbij worden actoren (externe gebruikers) en transacties onderscheiden. Daarnaast kunnen operaties in het object model als messages worden gemodelleerd. Modelleren van gedrag Voor het modelleren van gedrag zijn twee notatiewijzen beschikbaar. Allereerst is dat het interactie diagram, ten tweede het state transition diagram. De notatie in de state transition diagrammen is rijk te noemen, ruim voldoende voor de DDO toepassing. Relatie tussen de modellen De relatie tussen de modellen van de fasen is duidelijk beschreven. Echter het verband tussen de verschillende modellen van gedrag en eigenschappen is niet duidelijk uitgewerkt. De use case diagrammen vormen een belangrijk uitgangspunt in de methode en kunnen als verbindend schema tussen de andere modellen gezien worden. Vertalen naar gegevensbestanden Voor gegevenstoepassingen is deze methode minder geschikt vanwege de beperkte mogelijkheden om functies te beschrijven en de beperkte beschrijving van eigenschappen. Daarnaast is er in de methode geen beschrijving gegeven hoe een vertaling van de modellen naar databases dient plaats te vinden. Er wordt in een hoofdstuk aandacht besteed aan het toepassen van de methode in een database omgeving, maar dit is geen beschrijving van een methodische werkwijze. Interactie met de gebruiker Het is duidelijk dat deze methode zich sterk richt op applicaties waarbij de gebruikersinterface belangrijk is. Hiertoe heeft de methode goede modellen tot haar beschikking. Met name het object type interface is kenmerkend voor de detaillering van de interactie met de gebruiker. Introductie van lagen en modulen Voor het introduceren van modulen biedt de methode een goede ondersteuning. In de constructie fase is zelfs een model beschikbaar. Het block model. Een block heeft een public en een private part wat de mogelijkheid van inkapseling mogelijk maakt. Introductie van lagen wordt niet uitgewerkt maar is vanzelfsprekend middels een block model uit te werken. Er worden echter geen richtlijnen voor het uitwerken in lagen aangegeven. Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie De methode is iteratief. Doordat de methode ook de implementatie en testfase beschrijft is de methode goed te gebruiken voor object-georiënteerde realisatie. Negatief is dat de eigenschappen niet in detail beschreven kunnen worden en dat de attributen in een aparte notatie wordt aangegeven waardoor object diagrammen snel onoverzichtelijk worden. Er wordt de mogelijkheid geboden verschillende objecten te modelleren, daarnaast is het mogelijk om alle belangrijke type relaties tussen objecten aan te geven. Nadeel is dat niet alle relaties voorzien zijn van multipliciteit.

57


Toepassen deelmodel


Klasse wordt weergegeven als een ovaal met de naam van de klasse. Er zijn drie soorten klassen: interface, control en standaard Attribuut wordt weergegeven met een afgeronde rechthoek Relaties worden weergegeven als een pijl tussen twee klassen Gestippelde pijl is overerving Multipliciteit wordt opgegeven met een onder- en bovengrens tussen [ .. ].

58


Bijlage 4 OOA/OOD (Coad/Yourdon) Historie en toekomstperspectief De methode van Coad en Yourdon is in twee fasen ontstaan. Allereerst is de methode beschreven door Peter Coad en Ed Yourdon. Dit is gepubliceerd in 1991 in twee publicaties Object Oriented Design en Object Oriented Analysis. In 1993 is de methode aangepast en meer geschikt gemaakt voor programmeren door Peter Coad en Jill Nicola. Gezien de ontwikkelingen in de UML is het toekomstperspectief van deze methode twijfelachtig. Projectfasering en methodische werkwijze In deze methode is het belangrijk om naar voorgaande OOA analyses te kijken. Dit is belangrijk omdat hergebruik een belangrijk aspect is van de methode. Verder is het belangrijk dat de volgorde van de fasen niet vast staat. Fasen kunnen in willekeurige volgorde worden uitgevoerd, waarbij fasen overgeslagen kunnen worden. Analyse. Bestaat uit een aantal deelstappen. Allereerst wordt een lijst van mogelijke klassen of objecten opgesteld. Dit kan worden bereikt door te kijken naar de volgende entiteiten, structuren, andere systemen, gebeurtenissen, operationele procedures en organisatorische eenheden. Is een lijst van deze klassen opgesteld dan worden deze de volgende eigenschappen beschreven: • Gewenste opslag • Gewenst gedrag • Meervoudige en toepasbare eigenschappen • Meervoudigheid van objecten van een klasse • Toepasbase operaties • Behoeften op domeinniveau Vervolgens wordt gezocht naar identificeerbare structuren. Hier bij wordt gezocht naar Gen-Spec structuren voor het toepassen van overerving. Verder wordt gezocht naar Whole part structuren wat te vergelijken is met aggregatie. Dit wordt gedaan om te zoeken naar zelfstandige klassen. Vervolgens worden subjecten en attributen geïdentificeerd. Ook hierbij worden een aantal vragen gesteld die de ontwerper ondersteunen in het vinden van subjecten (subsystemen) en attributen. Van de attributen wordt gekeken welke waarde deze aan kunnen nemen en wat de multipliciteit is van deze attributen. De volgende stap is de identificatie van operaties. Dit wordt afgebeeld in het Object State Diagram. De laatste stap van de analyse fase bestaat uit het samenstellen van de OOA documentatie. Deze documentatie bestaat uit: • OOA diagrammen • Specificatie van Klassen en Objecten • Overige documentatie Ontwerp begint met het kiezen van een probleem domein op basis van de OOA. Vervolgens wordt gekeken of hergebruik toegepast kan worden met voorgaande OODs. Coad spreekt hierbij over "van de plank" klassen. Vervolgens worden de klassen gegroepeerd. Hierbij wordt gezocht naar gezamenlijkheid van klassen of operaties. Hierdoor is het mogelijk een overervingsstructuur samen te stellen. Op basis van de te gebruiken programmeertaal wordt gekeken in hoeverre overerving toegepast kan worden. Denk bijvoorbeeld aan het ontbreken van meervoudige overerving in veel talen. De volgende stap is het zoeken naar data opslag mogelijkheden tijdens de implementatie. Hierbij wordt op basis van een checklist gekeken hoe de objecten opgeslagen dienen te worden. In de volgende stap wordt gekeken naar de Interactie met de gebruiker. Hiertoe wordt een Human Interaction Component opgesteld. Hierbij wordt gekeken wie de gebruikers zijn van het systeem. Dit wordt wederom gedaan op. Er worden verder criteria gegeven over de volgorde en het aantal operaties. De laatste stap van het ontwerpen is het opstellen van richtlijnen voor de kwaliteit van het ontwerp. Belangrijke aandachtspunten zijn onder andere cohesie, hergebruik, koppelingen en overerving.

59


Modellering Modelleren van eigenschappen De modellering van klassen en objecten wordt goed ondersteund door OOA/OOD. In de notatie van het statische model is een onderscheid gemaakt tussen concrete en abstracte klassen. Binnen het object model kunnen van een klasse zowel eigenschappen als operaties genoteerd worden. Echter detaillering van eigenschappen is niet mogelijk. Dus initiële waarde, multipliciteit en domein van eigenschappen kunnen niet opgenomen worden. Daarnaast ontbreekt de detaillering voor operaties. Relaties kunnen in het statisch model opgenomen worden, er worden twee soorten onderscheiden, allereerst de Gen-Spec welke te vergelijken is met overerving en de whole-part (aggregatie). Tevens kan de multipliciteit van relaties worden weergegeven op een wijze die sterk lijkt op de ER notatie. Vermeldenswaardig is verder dat instantiatie in de notatie is opgenomen en dat het mogelijk is om berichten (messages) in het statisch model op te nemen. Modelleren van functionaliteit Modelleren van functionaliteit is mogelijk in OOA/OOD maar is summier van opzet. De notatie bestaat uit een service chart. In de service chart zijn drie symbolen te onderkennen te weten: loop, conditie en text. Hoe de service charts worden toegepast wordt in de methode beschrijving nauwelijks toegelicht. Modelleren van gedrag Voor het modelleren van gedrag beschikt de methode over een Object State Diagram. Dit is een subset van de State Transition diagrammen zoals deze in andere methoden voorkomen. Er worden twee symbolen toegepast: state en transition. Relatie tussen de modellen De relatie tussen de verschillende modellen is niet duidelijk. Met name door de summiere uitwerking van het gedrag en de functionaliteit is dit verklaarbaar. De opname van messages in het statische model zijn in deze een goede aanvulling op deze beperking. Vertalen naar gegevensbestanden Voor het vertalen naar gegevensbestanden is in de ontwerp fase een gedetailleerde beschrijving uitgewerkt. Met behulp van een checklist wordt men ondersteund om te komen tot een goede keuze van het databaseplatform. Interactie met de gebruiker OOA/OOD is de enige methode welke de interactie met de gebruiker in detail uitwerkt. In de ontwerpfase is een goed beschreven stap opgenomen welke beschrijft wie de gebruiker is en hoe het systeem aangepast kan worden aan de werkwijze en ervaring van deze gebruiker. Introductie van lagen en modulen De methode is van zichzelf sterk gelaagd van opzet. Echter de introductie van lagen en modulen wordt op een afwijkende manier uitgewerkt. In de ontwerpfase wordt een stap opgenomen om taken (tasks) te definiëren. Deze tasks kunnen toegewezen worden aan subsystemen, gebruikers of processoren. Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie De methode is iteratief van opzet en biedt de mogelijkheid het geheel in deelsystemen op te splitsen. De toegepaste notatie geeft een duidelijk beeld van de statische structuur van het systeem. Het biedt ruime mogelijkheden om verschillende objecten te definiëren. Waarbij een duidelijke scheiding plaatsvindt tussen eigenschappen en operaties. Ook de relaties zijn te benoemen met de type inherit en aggregatie. Belangrijk punt is verder dat de multipliciteit van de relaties weer te geven is. Functionele aspecten komen beperkt aan de orde. Het is mogelijk om de operaties te benoemen, maar wat de functionaliteit is dient buiten de methode benoemd te worden. Ook de beslisregels zijn te beperkt van opzet.

60


Voor kleine projecten is dit een geschikte methode, wordt de toepassing complex, dan is deze methode onvoldoende rijk aan semantiek. Toepassen deelmodel


Klasse wordt beschreven door een vierkant verdeeld in drie vakken, eerste vak is de naam, tweede vak zijn de attributen, derde vak zijn de operaties. Een abstracte klasse heeft een enkel buitenkader een concrete klasse heeft een dubbel buitenkader Overerving- of Gen-Spec relatie wordt weergegen met een halvemaan vorm in een lijn. Gebruikt of Whole-Part relatie wordt weergegeven met een Pijlvorm in de lijn. Multipliciteit wordt weergegeven met aantal lijnen op verbinding van klasse en relatie.

61


Bijlage 5 Unified Modeling Language (Rational) Historie en toekomstperspectief De UML is ontstaan doordat Booch, Jacobson en Rumbaugh de handen ineen hebben geslagen en een notatie hebben ontwikkeld gebaseerd op een combinatie van de notatie van de drie methoden OOSE, OMT en OOADA. Deze samenvoeging heeft ertoe geleid dat deze notatie gezien kan worden als een defacto standaard op het gebied van Object modellering. Gezien het aantal grote organisaties (Microsoft, Oracle, IBM) dat UML gebruikt en de hoeveelheid literatuur die beschikbaar is over de taal is de toekomst van de UML rooskleuring. Projectfasering en methodische werkwijze De UML is afwijkend van de andere beschrijvingen in dit hoofstuk. De UML is namelijk geen methode maar een taal. Een taal om op object georiënteerde wijze een model te vervaardigen. Dit model hoeft niet gebaseerd te zijn op informatietoepassingen, maar kan ook in andere probleemgebieden worden toegepast. De makers van UML hebben echter ook een methode ontwikkeld het Unified Modeling Process (UMP). Een gedetailleerde beschrijving van de methode is op het moment van schrijven (Januari 1999) nog niet beschikbaar. Modellering Modelleren van eigenschappen Het statisch model is in de UML goed te beschrijven. De notatie is rijk aan symbolen en biedt ruime mogelijkheden tot het maken van keuzes. Misschien is de notatie te rijk, waardoor het maken van keuzen een probleem kan worden voor een ontwerper. Vanzelfsprekend kunnen objecten en klassen in de notatie worden opgenomen. De notatie is vergelijkbaar met de OMT notatie. Naast concrete klassen kan middels het trefwoord {abstract} aangegeven worden dat een klasse abstract is. De eigenschappen kunnen goed worden beschreven. Kenmerken als type, domein en initiële waarde kunnen genoteerd worden. Daarnaast is de zichtbaarheid van een eigenschap op te nemen. De zichtbaarheid heeft betrekking op het type klasse of object dat een eigenschap ziet. Zo is er een zichtbaarheid voor alle klassen, de klasse zelf en de klasse en de overervende klassen. Als laatste kan genoemd worden dat de multipliciteit van een eigenschap opgenomen kan worden. Operaties zijn in de UML in detail te modelleren. Naast de parameters en het type van de return waarde van een operatie kan hier eveneens de zichtbaarheid beschreven worden. Associaties zijn goed te modelleren. Binaire en tertiaire associaties kunnen opgenomen worden. Tevens kan de multipliciteit worden beschreven op elke gewenste wijze. Rollen van objecten in een associatie zijn mogelijk. Verder kan overerving, uses (gebruikt) en aggregatie met een symbool genoteerd worden. Vermeldenswaardig is verder dat het mogelijk is een booleaanse or relatie op te nemen in het diagram. Modelleren van functionaliteit Voor het functioneel model zijn in de Uml een tweetal modellen gebruikt worden. Allereerst het Use case diagram (afkomstig van OOSE) waarmee de functionaliteit voor de gebruiker van het systeem gemodelleerd kan worden. Daarnaast is het activity diagram te gebruiken voor de detail modellering van operaties. Het activity diagram kan gezien worden als een uitbreiding van de data flow diagrammen zoals toegepast in OMT. Modelleren van gedrag Het gedrag kan eveneens in een aantal diagrammen worden genoteerd. Allereerst is er het sequence diagram dat vergelijkbaar is met de event trace van andere methoden. Verder kunnen de toestandsveranderingen van klassen besschreven worden met statechart diagrams. Deze zijn te vergelijken met de State Transition diagrammen van OMT.

62


Relatie tussen de modellen Is niet uitgewerkt in de taal. Toevoegen van deze notatie zou de complexiteit van de taal kunnen reduceren. In de notatie is een collaboration diagram opgenomen dat mogelijk hiervoor gebruikt kan worden. Mits er aanpassingen gemaakt worden aan de notatie. Zoals bijvoorbeeld het opnemen van geneste notatie met verwijzingen naar andere diagrammen. Vertalen naar gegevensbestanden Ontbreekt in de taal omdat het betrekking heeft op de methode. Interactie met de gebruiker Aspecten van human computer interaction kunnen eventueel gemodelleerd worden met het use-case diagram. Echter een beschrijving van relevante aspecten ontbreekt, aangezien dat betrekking heeft op een methode Introductie van lagen en modulen In de notatie is een diagram opgenomen om het opdelen in lagen en modulen het implementation diagram. Dit diagram biedt een notatie voor het modelleren van componenten en subsystemen. Hoe deze modellen opgesteld moeten worden is niet beschreven omdat dat betrekking heeft op een methodische werkwijze. Toepasbaarheid voor geautomatiseerde object georiënteerde realisatie De notatie is goed toe te passen voor geautomatiseerde realisatie. Hiervan zijn een aantal voorbeelden bekend. Belangrijkste is Rational Rose, welke de UML ondersteunt. In deze toepassing is het mogelijk op basis van de diagrammen programma code (bijvoorbeeld Visual Basic) te genereren. Echter het ontbreken van de methode component biedt de ontwerper niet de structuur welke bij de realisatie belangrijk is.

63


Toepassen deelmodel

Toelichting op het schema • • • • • • • •

Klasse wordt weergegeven met een rechthoek verdeeld in drie vlakken, bovenste vlak geeft de naam van de klasse, tweede vlak geeft een lijst van eigenschappen, derde vlak een lijst van operaties Multipliciteit van eigenschappen wordt weergegeven met [..] Beginwaarde wordt weergegeven met een = Waarde van een attribuut wordt weergegeven met : en het type Zichtbaarheid van een attribuut wordt weergegeven met een + (export), # voor protectie en - voor verborgen voor de attribuutnaam. Relaties worden weergegeven met een lijn tussen klassen Ruitvorm in relatie geeft aan dat het een aggregatie is Driehoek vorm geeft overerving weer.

64


65


66


67


68


69


70


Bijlage 8 Data Dictionary in detail

De datadictionary is als DDO toepassing opgenomen op de CD-Rom. U kunt de DDO toepassing als volgt opstarten: • Plaats de CD in uw CD-Rom speler • Start de toepassing DDO prototype vanaf de CD-Rom. • Bij het opstarten kunt u aangeven wat de instellingen van de applicatie zijn. Geef in ieder geval bij de Database directory de CD drive op (bijvoorbeeld D:\) • De gegevens zijn nu te raadplegen onder het menu file vindt u de gegevens • In de directory voorbeeld en opsporing op de CD-Rom vindt u een aantal voorbeelden van test cases.

71


Bijlage 9 Pseudocode functioneel model

Sequentie De expressie worden als opeenvolgende regels beschreven gescheiden door een harde return Condities Worden weergegeven middels IF conditie THEN Expressie ELSE IF conditie Expressie ELSE Expressie END IF Iteratie Conditionele iteratie is als volgt weergegeven: DO WHILE Conditie Expressie END DO Iteratie door een collectie of array FOR Teller := Minimum TO Maximum [STEP Aantal] Expressie END FOR De incrementie is impliciet 1 tenzij anders weergegeven met STEP Aantal in het FOR statement Variabele instantiatie Er kunnen alleen lokale variabelen geinstantieerd worden middels LOCAL xVariabele AS Variabeletype Waarbij de volgende typen variabelen gedeclareerd worden. Hierbij wordt uitgegaan van de Hongaarse notatie [Straley]. Tabel 1 Hongaarse notatie Soort variabele Array String Object Integer Logisch Expressie Datum Onbekend

Prefix Hongaarse notatie A C O N L E D X`

Voorbeeld AVelden CVeldnaam OFormulier NTeller LVereist EConditie DVandaag XElement

Operatie of methode aanroep Wordt als volgt omschreven: KlasseNaam:Operatie(Paramater1, Parameter2) Waarbij de Parameters als [xParameter AS Variabeletype] beschreven worden Methode return

72


RETURN Returnwaarde Waarbij de returnwaarde als [xReturnwaarde AS Variabeletype] beschreven wordt. Is geen return gegeven dat is standaard het object de returnwaarde. Verwijzing naar operaties of eigenschappen Verwijzing naar het object vindt plaats door drie trefwoorden: SELF voor het actieve object SUPER voor het object waarvan overerving plaatsvindt SELF:OWNER naar de ouder of eigenaar van het object Operaties en eigenschappen worden aangeroepen met een dubbele punt als verbinding dus: SELF:Toevoegen() als operatie SELF:Naam := "Naam" als eigenschap

73


Bijlage 10 Vragenlijst testers De vragenlijst is opgedeeld in drie gedeelten. Onder de beheersmodule wordt verstaan het deel in de applicatie waar de datadictionary wort bewerkt en beheerd. De embedded module is de rest van de applicatie. Met name die delen die gebruik maken van de datadictionary voor het weergeven en/of bewerken van de gegevens in de produktiedatabases. Zoals bijvoorbeeld de order administratie in het bijgeleverde voorbeeld. In het derde gedeelte kunt u uw eigen ervaringen met het product weergeven. Graag verzoek ik u de vragenlijst zo gedetailleerd mogelijk in te vullen. Op basis van uw suggesties is het voor mij mogelijk de applicatie aan te passen cq te verbeteren. Beheersmodule 1.1 Is het ten opzicht van Visual Objects beter mogelijk om met de datadictionary evolutionair te ontwikkelen.? 1.2 Is het mogelijk om de ontwikkeltijd van een applicatie te verkorten. Zo ja kunt u aangeven hoeveel tijdsbesparing er volgens u mogelijk is. Zo nee kunt u aangeven waarom de ontwikkeltijd langer geworden is? 1.3 Denkt u dat het ontwikkelen met een datadictionary het aantal fouten in een opgeleverde applicatie kleiner of groter is. Kuht u aangeven wat de redenen van uw keuze zijn? 1.4 Ziet u mogelijkheden om datadictionary bestanden te hergebruiken in uw projecten. Sluit dit hergebruik aan bij de werkwijze in uw organisatie. Kunt u redenen aangeven? 1.5 Wordt de Integriteit voldoende gehandhaafd het verwijderen en toevoegen van eigenschappen en of objecten in de data dictionary. Vindt u handhaving van integriteit van objecten belangrijk. Kunt u redenen aangeven warom wel of niet? 1.6 Biedt de datadictionary een gebruikersinterface welke de werkzaamheden voor de applicatieprogrammeur op een logische wijze concentreert, zodat de arbeidsproductiviteit stijgt? Kunt u aangeven hoeveel de arbeidsproductiviteit kan stijgen of dalen? 1.7 Kan de applicatieprogrammeur kan eenvoudiger zoeken en selecteren naar de diverse entiteiten in de datadictionary? 1.8 Is het aanmaken van formulieren voor klantapplicaties verbeterd ten opzichte van de werkwijze in Visual Objects. Kunt u aangeven wat volgens u voor- en/of nadelen zijn van de schermpainter zoals uitgewerkt in de datadictionary? 1.9 Biedt de datadictionary voldoende ondersteuning voor complexe activiteiten in de vorm van wizards of andere hulpmiddelen? Kunt u aangeven wat de sterke en zwakke kanten van de datadictionary zijn? Embedded module 2.1 Ervaart u dat het opstarten van de DDO applicatie sneller of trager is ten opzicht van een normale VO applicatie. Kunt u uw ervaring toelichten? 2.2 Ervaart u het als een voordeel of nadeel dat de eigenschappen van objecten in gegevensbestanden opgeslagen worden. Bijvoorbeeld op het gebied van updates, upgrades maatwerkapplicaties en het gebruik van internet voor deze aspecten. Kunt u aangeven welke aspecten u belangrijk vindt? 2.3 Is het mogelijk om wijzigingen op afstand aan te brengen aan een klantapplicatie? 2.4 Kunnen fysieke bestandsstructuren vergeleken worden met de structuren in de datadictionary gevensbestanden? Sluit dit wel of niet aan bij de werkwijze in uw projecten? Toelichting op de applicatie Hieronder kunt u aangeven wat uw ervaringen zijn met de geteste applicatie. U kunt hier suggesties doen voor verbeteringen, bugs rapporteren of andere zaken aan de orde stellen

74


Bijlage 11 Resultaten vragenlijst Beheersmodule A

B

1.1 Is het ten opzicht van Visual Objects beter mogelijk om met de datadictionary evolutionair te ontwikkelen.?

Ja, het is zeer zeker mogelijk om hiermee evolutionair te ontwikkelen. Doordat je begint te bouwen juist om je data heen kan je al vrij snel de resultaten bekijken. Voor prototypen is dit dan ook het ideale gereedschap.

Eenvoudig:ja. Ik vind een datadictionary een gemis binnen VO en binnen de ontwikkeltrajecten van door mij geschreven programmatuur maak ik dankbaar gebruik van een eenvoudige, zelf ontwikkelde datadictionary

1.2 Is het mogelijk om de ontwikkeltijd van een applicatie te verkorten?

De ontwikkeltijd van een applicatie wordt drastisch bekort omdat de hele opzet je dwingt eerst na te denken over de structuur van de data en de applicatie. Het gebeurt me nog wel eens dat ik een bepaald idee over een applicatie in mijn hoofd heb en dan ook denk dat ik het allemaal in een oogopslag kan overzien. Voor kleine projecten is dat geen probleem maar voor de grotere kunnen er toch ontwerpfouten insluipen die pas veel te laat naar voren komen. Dan blijkt het herstellen van die fouten nog veel meer tijd te kosten dan de kleine investering in tijd aan het begin van het traject.

Ten opzichte van VO ‘kaal’, zonder het gebruik van een andere datadictionary is denk ik naar schatting een besparing van 15-25% mogelijk. Hierbij ga ik uit van mijn eigen werkwijze, zonder het explicite gebruik van een vastomlijnde methode

Het is erg moeilijk om in te schatten hoe groot de tijdsbesparing precies is omdat ik nog niet een heel project met deze ontwerptool heb gemaakt, dus ik heb geen referentiekader. Als ik het zou moeten schatten dan zou ik 20% zeggen. 1.3 Denkt u dat het ontwikkelen met een datadictionary het aantal fouten in een opgeleverde applicatie kleiner of groter is

Het aantal fouten in een met DDO ontwikkelde applicatie ligt per definitie lager dan in een applicatie die op de gebruikelijke manier is ontwikkeld. Doordat DDO zelf alle broncode genereert voor de op te leveren applicatie kunnen afwijkingen in de codering niet voorkomen. En fouten die worden gegenereerd door DDO zelf zijn eenvoudig door middel van testen op te sporen en moeten ook in DDO zelf opgelost worden. Daarna is het eenvoudig de doelapplicatie stabiel te krijgen doordat je DDO de broncode opnieuw laat genereren.

Het aantal fouten in een afgeleverde applicatie is denk ik met namel afhankelijke van een goed ontwerp en een solide testfase, niet zozeer van de gebruikte ontwikkeltools. Wel denk ik dat het gebruik van een programma als DDO het aantal fouten tijdens de ontwikkelfase verkleint en een hulpmiddel is bij de ontwerpfase

1.4 Ziet u mogelijkheden om datadictionary bestanden te hergebruiken in uw projecten.

Naar het hergebruiken van business logic, databasedefinities en de gebruikersinterface is tegenwoordig een grote vraag ontstaan. Zodra je de mogelijkheid hebt tot hergebruik neemt de productiviteit enorm toe. Dit effect is helemaal meetbaar bij systeemhuizen die bijvoorbeeld administratieve software leveren voor hun klanten. Elk zo’n soort pakket heeft een klantenbestand, verkoopregistratie, facturering etc. Als op een correcte manier de DDO objecten zijn gedefinieerd dan behoeft het systeemhuis alleen nog maar de klantspecifieke wijzigingen door te voeren en kan al vrij snel tot levering overgaan.

Ik kies er zelf voor om een project aan te vangen met een gegevensanalyse. Hergebruik van bestanden dragen het risico de gegevensanalyse minder grondig te doen.

Dit hergebruik sluit echter niet zo aan in

75


1.5 Wordt de Integriteit voldoende gehandhaafd het verwijderen en toevoegen van eigenschappen en of objecten in de data dictionary?

onze organisatie. Doordat de verscheidenheid aan problemen zo divers is, is hergebruik vaak niet eens mogelijk. Op kleinere schaal komt het echter wel voor. Denk maar aan het ‘gebruikersbestand’ of ‘medewerkersbestand’ of ‘gemachtigde’ etc. Vaak zie je dat er voor al deze (dezelfde) bestanden verschillende definities worden opgezet terwijl ze altijd te vangen zijn in een enkele, uitgebreidere definitie. De integriteit wordt niet voldoende gehandhaafd. Het systeem waarschuwt wel dat er een bestand is verwijderd terwijl er nog relaties bestaan van andere bestanden naar dit bestand maar de verwijdering is dan al uitgevoerd. Beter is een waarschuwing te geven en de gebruiker te dwingen deze referenties op te heffen alvorens er tot verwijdering overgegaan mag worden.

Ik zie het DDO vooral als een overigens uitstekend, uitgewerkt idee. Binnen de afwerking zitten wat kleinere fouten en onvolkomenheden die op zich geen afbruik doen aan het idee. Maar als de vraag is of ik nu met deze versie binnen de softwareproductie aan de slag zou kunnen, is het antwoord op de eerste vraag matig tot voldoende. Ik mis met name een exportmogelijkheid van broncode en/of een integratie met de IDE van VO..

De handhaving van de integriteit is uiteraard heel belangrijk. Dat is juist de kracht van DDO. Niets is zo irritant als het werken met een correct opgezette definitie die, door mogelijke fouten in de integriteitafhandeling, corrupte uitvoer zal gaan geven. Hetzelfde verschijnsel zien we soms terug in Visual Objects. De gebruiker is niet de schuldige want alles wordt eerst gevalideerd door de repository. Toch blijken er soms entiteiten te verdwijnen of onterecht verwijzingen te ontbreken. Aan de andere kant is het waarschijnlijk onmogelijk om tot 100% zekerheid te komen want een stroomuitval of hardware problemen zijn nooit uit te sluiten. De enige manier om dit te omzeilen is een andere database te gebruiken die werkt met transactions etc. 1.6 Biedt de datadictionary een gebruikersinterface welke de werkzaamheden voor de applicatieprogrammeur op een logische wijze concentreert, zodat de arbeidsproductiviteit stijgt

De GUI van de datadictionaire is logisch van opzet en na het enige tijd werken met de diverse schermen wordt de routine al gauw verkregen. Heel prettig is het werken met de tabcontrols. Door te kiezen voor deze oplossing blijft alles overzichtelijk terwijl toch alles tot in detail bekeken kan worden. Het enige wat soms vreemd overkomt is de mix tussen Nederlandse en Engelse schermen. Wellicht wordt er op dit moment een meertalige versie ontwikkeld?

Het interface biedt zeker mogelijkheden voor productiviteitsverbetering, in de huidige vorm schat ik 15-25%. Wel denk ik dat het interface op onderdelen verbeterd kan worden zodat een 25-30% haarbaar is. Ik denk dan aan het verwijderen van een storende waarschuwing bij het toevoegen van objecten, eenvoudiger toevoegen van meerdere velden, (wilt u nog een veld toevoegen?…)

De productiviteit zal, zeker na de verkregen routine, behoorlijk kunnen toenemen. Wat in Visual Objects allemaal met de hand gecodeerd moet worden, zoals relaties etc, is hier allemaal direct voorhanden. Dus zeker op de langere termijn verwacht ik een drastische stijging waar te nemen. 1.7 Kan de applicatieprogrammeur eenvoudiger zoeken en selecteren naar de diverse entiteiten in de datadictionary?

Doordat er gebruik gemaakt kan worden van Ja. Zelf maak ik bijv. dankbaar gebruik van de een dynamisch filter, wat de gebruiker zelf filter-op-objectnaam optie helemaal kan samenstellen, is het terugvinden van de diverse entiteiten geen enkel probleem. Ik wou dat dit soort technieken in Visual Objects waren gebruikt!

76


1.8 Is het aanmaken van formulieren voor klantapplicaties verbeterd ten opzichte van de werkwijze in Visual Objects

1.9 Biedt de datadictionary voldoende ondersteuning voor complexe werkzaamheden?

Het enige nadeel van de screenpainter van DDO vind ik dat het niet mogelijk is om de controls naar de juiste plaats te slepen. Alleen door middel van de rechtermuisknop en het handmatig ingeven van de coördinaten bereikte ik mijn doel. Misschien dat het op een andere manier ook mogelijk is maar ik had me voorgenomen bij deze test verder niets te vragen over de werking en alles zelf uit te proberen. Op deze manier kan ook de gebruikersvriendelijkheid beter worden getest.

Het is duidelijk anders. Een voordeel vind ik de mogelijk om direct aan te geven waarmee een list/combobox gevuld dient te worden.Knippen en plakken wordt beter ondersteund en de eigenschappen van een control zijn wat overzichtelijker. Nadelen zijn de onmogelijkheid om controls te verslepen, en geen broncode van forms te kunnen genereren/exporteren. Je kunt snel wat forms in elkaar zetten en de klant voorschotelen. Toch werk ik liever met hard-coded forms. Je bent dan sneller en flexibeler

Het grote voordeel van deze painter is dat er een directe koppeling is naar alle entiteiten die bij het scherm horen. Dit werkt op dezelfde manier als de fieldspecs die kunnen worden gekoppeld aan controls in Visual Objects. De autolayout ken ik en die vind ik beter dan die van VO. Ook het feit dat die bijvoorbeeld een MLE ipv een SLE toont vind ik mooi gevonden van je. In VO worden bijvoorbeeld Memo velden altijd als een SLE met 10 tekens gelayout. Verschrikkelijk ;-)

Ja. Sterk: sleutelveld definiëren, overzichtelijkheid, mogelijkheid om relaties te leggen. Zwakke kant vind ik vooralsnog de stabiliteit van met name de databrowsers op de tabpagina’s. Verder vind zou ik liever niet met een embedded module hoeven werken maar met gegenereerde broncode en een library. Dit vanwege snelheid en flexibiliteit.

Embedded module Het heeft me eerlijk gezegd verbaasd dat er zo weinig verschil zit tussen een ‘normale’ applicatie en een met behulp van DDO gegenereerde applicatie met betrekking tot de opstarttijd. Oftewel, ik heb geen verschil bemerkt. Wellicht dat dit pas bij zeer grote projecten een issue zou kunnen worden maar dat is niet mijn verwachting. Ik ben altijd al voorstander geweest van het 2.2 Ervaart u het als een opslaan van dit soort informatie in databases. voordeel of nadeel dat de eigenschappen van objecten Het is veel gemakkelijker in onderhoud om een database even aan te passen dan een in gegevensbestanden programma. Ook met betrekking tot updates opgeslagen worden. en upgrades lijkt het me eerder een voordeel dan een nadeel. Gegevensbestanden zijn veel gemakkelijker te manipuleren dan executables. Zodoende is het ook veel eenvoudiger om versiebeheer te kunnen doen. 2.3 Is het mogelijk om Volgens mij wel, hiervoor geldt dezelfde wijzigingen op afstand aan motivatie als bij vraag 2.2: Het is te brengen aan een eenvoudiger om een nieuwe database door te klantapplicatie? sturen dan een nieuwe versie van een applicatie. 2.1 Ervaart u dat het opstarten van de DDO applicatie sneller of trager is ten opzicht van een normale VO applicatie.

77

Op zich oogt een en ander vlot. Niet getest hoe een hard-coded equivalent presteert. Ik schat in dat de laad-tijd kleiner is, maar de overall—performance iets afneemt.

Lijken verschillende kanten aan te zitten. Ik zit niet erg diep in de materie en heb dit niet uitvoerig kunnen testen, maar er zitten zeker voordelen aan. Ik zie wel mogelijkheden in bijv. Kleine objecten welke middels DCOM met elkaar en/of met een clientapplicatie communiceren. Aan de andere kant stelt het hoge eisen aan de stabiliteit en integriteit van de gegevensbestanden. Lijkt mij meer risico in zitten dan aan lokaal geïnstalleerde DLL’s

Ja


2.4 Kunnen fysieke bestandsstructuren vergeleken worden met de structuren in de datadictionary gegevensbestanden?

Uiteraard. Je kijkt gewoon in de Data Definer en daarin staat de structuur van de bestanden beschreven. De fysieke bestanden zelf zijn ook qua structuur te bekijken met behulp van DBU of andere database utilities en zo is een vergelijk dus mogelijk. Op zich maakt het trouwens nog niet eens zo uit of de fysieke opbouw van de bestanden identiek is als de datadictionaire definitie. Toelichting op de applicatie De applicatie ziet er heel mooi uit en is ondanks de datadriven eigenschappen toch behoorlijk snel. Er zitten hier en daar nog wel schoonheidsfoutjes zoals het feit dat de datadictionaire toch regelmatig klaagt dat er een probleem is gevonden. Ook heb ik diverse crashes gehad met foutcode 4660 dus er zijn nog wat codeer problemen op te lossen. Als laatste minpuntje kreeg ik de grafieken niet gestart. MicroSoft Graph wordt wel opgestart maar klaagt dan dat het tussenbestand (grafiek.txt) niet geopend kan worden. Wellicht een probleem met paden?

78

Ja, ja

Begonnen met een nieuw object aanmaken. Hier kan ik niet direct een nieuw sleutelveld invoeren, omdat het comboboxen betreft. Dan velden invoeren, gelukkig kan ik een filter plaatsen op mijn nieuwe dbf-naam. Handig dat mijn nieuwe veld dan meteen de juiste bestandsnaam krijgt toegewezen. Mijn eerste veld wordt de primairy key. Hier zou ik graag aan willen geven dat in dit veld automatisch een uniek nummer wordt toegekend. Elke keer de waarschuwing dat changing view mijn changes discard vind ik irritant. Andere kritische noot is deze, als ik van tabblad wissel, krijg ik soms een lege tabel. Ook is de eerste keer dat ik in het iodex tabblad kies, is mijn nieuw aangemaalte object nog niet te selecteren. Nu ga ik terug naar het eerste tabblad:lege tabel objecten. Ik druk op pb-relation en daar is alles weer. Al met al peanuts hoor, maar helemaal stabiel is het (nog) niet.. Nog een leuke: als ik in de data-definer de tabbladen stuk voor stuk naar voren haal, bij de laatste, de option list modify of append en deze cancel, vervogens terugga naar het tabblad property, krijg ik een GPF, 4660. Vanuit de painter lukt het mij niet om relaties te (ver)leggen. Verder zou ik een graag de objecten kunnen verslepen ipv van de workaround van rezisen. Ik ben maar opgehouden om bugs te rapporteren, ben me verder gegaan de hoofdlijnen van het programma te doorgronden.


Inhoudsopgave VOORWOORD .............................................................................................................................................. 1 INLEIDING.................................................................................................................................................... 3 SAMENVATTING ......................................................................................................................................... 4 1 PROBLEEMSTELLING............................................................................................................................. 5 1.1 SOFTWARE ONTWIKKELING ...................................................................................................................... 5 1.2 OPDRACHT .............................................................................................................................................. 6 1.3 OPZET OPDRACHT .................................................................................................................................... 7 2 KEUZE VAN DE ANALYSE- EN ONTWERP METHODE ..................................................................... 8 2.1 CRITERIA METHODEN ............................................................................................................................... 9 2.2 SCORE VAN METHODEN .......................................................................................................................... 11 3 REQUIREMENTS .................................................................................................................................... 13 3.1 REQUIREMENTS BEHEERSMODULE .......................................................................................................... 13 3.2 REQUIREMENTS EMBEDDED MODULE ...................................................................................................... 14 3.3 TOEPASSEN REQUIREMENTS ................................................................................................................... 14 4 ANALYSE.................................................................................................................................................. 16 4.1 PROBLEEMBESCHRIJVING ....................................................................................................................... 16 4.2 OBJECT MODEL ..................................................................................................................................... 16 4.3 FUNCTIONEEL MODEL............................................................................................................................ 20 4.4 DYNAMISCH MODEL ............................................................................................................................... 21 4.5 TOT SLOT .............................................................................................................................................. 21 5 SYSTEEMONTWERP .............................................................................................................................. 22 5.1 SELECTEREN VAN BEHEERSMODULE ARCHITECTUUR............................................................................... 22 5.2 SELECTEREN VAN EMBEDDED MODULE ARCHITECTUUR .......................................................................... 24 5.3 OMGEVINGSINTERACTIE......................................................................................................................... 25 5.4 DATA MANAGEMENT ............................................................................................................................. 27 5.5 MOGELIJKHEDEN VOOR HERGEBRUIK ..................................................................................................... 28 5.6 STRATEGIE VOOR DATA INTERACTIE ....................................................................................................... 29 5.7 ASPECTEN VOOR DETAIL ONTWERP ......................................................................................................... 29 5.8 TOT SLOT .............................................................................................................................................. 30 6 DETAIL ONTWERP................................................................................................................................. 31 6.1 OBJECT MODEL TRANSFORMATIE ............................................................................................................ 31 6.2 BEWERKEN OBJECT MODEL .................................................................................................................... 31 6.3 BEWERKEN FUNCTIONEEL MODEL........................................................................................................... 31 7 REALISATIE ............................................................................................................................................ 33 7.1 KEUZE VAN DE ONTWIKKELOMGEVING ................................................................................................... 33 7.2 IMPLEMENTATIE VAN IDENTITEIT ........................................................................................................... 33 7.3 IMPLEMENTATIE VAN DOMEINEN ............................................................................................................ 33 7.4 IMPLEMENTATIE VAN HET OBJECTMODEL IN XBASE ................................................................................ 34 7.5 IMPLEMENTATIE VAN HET FUNCTIONEEL MODEL ..................................................................................... 34 7.6 IMPLEMENTATIE VAN HET DYNAMISCH MODEL ........................................................................................ 35 8 TESTEN..................................................................................................................................................... 38 8.1 DOEL VAN DE TEST ................................................................................................................................ 38 8.2 KEUZE VAN TESTSTRATEGIE ................................................................................................................... 38 8.3 OPZET VAN DE TEST ............................................................................................................................... 39 8.4 RESULTATEN VAN DE TEST ..................................................................................................................... 40

79


9 EVALUATIE ............................................................................................................................................. 42 9.1 CONSISTENTIE VAN HET OBJECTMODEL................................................................................................... 42 9.2 OO ANALYSE- EN ONTWERPMETHODEN. ................................................................................................. 42 9.3 ANALYSE EN ONTWERP .......................................................................................................................... 43 9.4 REALISATIE ........................................................................................................................................... 43 9.5 WERKEN MET EEN DDO TOEPASSING ..................................................................................................... 44 9.6 TOT SLOT .............................................................................................................................................. 44 LITERATUURLIJST................................................................................................................................... 45 VERKLARENDE WOORDENLIJST ......................................................................................................... 47 BIJLAGEN ................................................................................................................................................... 48 BIJLAGE 1 OOADA (BOOCH) ...................................................................................................................... 48 BIJLAGE 2 OMT (RUMBAUGH) ................................................................................................................... 52 BIJLAGE 3 OOSE (JACOBSON) ..................................................................................................................... 56 BIJLAGE 4 OOA/OOD (COAD/YOURDON).................................................................................................... 59 BIJLAGE 5 UNIFIED MODELING LANGUAGE (RATIONAL)............................................................................... 62 BIJLAGE 6 OBJECT MODEL........................................................................................................................... 62 BIJLAGE 7 EVENT TRACE ............................................................................................................................. 67 BIJLAGE 8 DATA DICTIONARY IN DETAIL ...................................................................................................... 71 BIJLAGE 10 VRAGENLIJST TESTERS .............................................................................................................. 74 BIJLAGE 11 RESULTATEN VRAGENLIJST ....................................................................................................... 75 INHOUDSOPGAVE..................................................................................................................................... 79

80

Data Dictionary Objecten in administratieve toepassingen

Recommend Documents