Een onderzoek naar de toepasbaarheid van COSMIC functiepunten op gelaagde architecturen van conceptuele modellen.

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Een onderzoek naar de toepasbaarheid van COSMIC functiepunten op gelaagde architecturen van conceptuele modellen. Scriptie voorgedragen tot het bekomen van de graad van licentiaat in de toegepaste economische wetenschappen optie technische bedrijfskunde Simon Claeys Onder leiding van Prof. Geert Poels PERMISSION

2 II Woord vooraf Vooraleer het eigenlijke werk te beginnen, wou ik toch enkele mensen bedanken die geholpen hebben bij het tot stand komen van deze tekst: - professor Poels voor de begeleiding, de mogelijkheid om inhoudelijke discussies te voeren en de open deurpolitiek; - Elke voor de vele uren luisteren naar dingen die voor buitenstaanders toch niet interessant zijn; - de familie voor hun steun en het begrip voor de zenuwen die af en toe bij een thesis komen kijken; - Herman voor het nalezen van de tekst.

3 III Inhoud WOORD VOORAF... II INHOUD... III GEBRUIKTE AFKORTINGEN... V LIJST VAN DE TABELLEN...VI LIJST VAN DE FIGUREN... VII INLEIDING... 1 DEEL 1 : BEGRIPSOMSCHRIJVING, SITUERING IN DE LITERATUUR EN PROBLEEMSTELLING BEGRIPSOMSCHRIJVING Wat is functionele omvangmeting? Waarvoor wordt functionele omvangmeting gebruikt? Projectmanagement Voorspelling en prestatiemanagement SITUERING IN DE LITERATUUR PROBLEEMSTELLING... 8 DEEL 2 : VOORSTELLING VAN HET COSMIC-FFP-MODEL, HET MERODE- MODEL EN HET OOWS-MODEL HET COSMIC-FFP MODEL De mapping fase Het identificeren van lagen in de software (software layers) Het identificeren van grenzen (boundaries) Het identificeren van functionele processen (functional processes) Het identificeren van datagroepen (data groups) De measurement fase Het identificeren van databewegingen Het toepassen van de meetfunctie HET MERODE-MODEL EN HET OOWS-MODEL Conceptueel model Objecten De lagen binnen een MERODE architectuur Het bedrijfsmodel De functionaliteitslaag De navigatielaag DEEL 3 : MAPPING VOOR GELAAGDE CONCEPTUELE MODELLEN NAAR COSMIC-FFP INTERPRETATIE VAN HET BEGRIP SOFTWARE LAYER MAPPING VOOR HET ENTERPRISE MODEL Het enterprise model Partiële informatie MAPPING VOOR HET INFORMATION SYSTEM SERVICES MODEL MAPPING VOOR DE NAVIGATIELAAG... 55

4 IV 5 VOORBEELD: BIBLIOTHEEK Het bedrijfsmodel: partiële informatie Het bedrijfsmodel Opmerking bij de metingen van de bedrijfslaag Het functionaliteitsmodel Het navigatiemodel DEEL 4 : VAN CONCEPTUEEL MODEL NAAR ARCHITECTUURMODEL WEG UIT DE CONCEPTUELE MODELLERING NAAR EEN TECHNISCHE OMVANGSMAAT ARCHITECTUURMODEL VAN DE BEDRIJFSLAAG COSMIC-UITBREIDING VOOR HET ARCHITECTUURMODEL COSMIC-uitbreiding voor de interfacelaag COSMIC-uitbreiding voor de gebeurtenislaag COSMIC-uitbreiding voor de bedrijfslaag DEEL 5 : RAPPORTERING VAN DE MEETRESULTATEN EISEN AAN EEN METHODE VOOR FUNCTIONELE OMVANGMETING OVER COSMIC-UITBREIDINGEN RAPPORTERING VAN DE RESULTATEN DEEL 6 : OMTRENT HET TESTEN VAN DE MAPPINGREGELS DOEL VAN DE TEST Inleiding Het el van de test BESCHRIJVING VAN DE TEST INTERPRETATIE VAN DE RESULTATEN CONCLUSIE BIBLIOGRAFIE BIJLAGE 1 : FINITE STATE MACHINES EN KLASSEMETHODES VAN DE VERSCHILLENDE OBJECTEN (CASE) FINITE STATE MACHINES EN TOESTANDSOVERGANGSTABELLEN VOOR DE VERSCHILLENDE OBJECTEN KLASSEMETHODES BIJLAGE 2 : FIGUREN CASE...2-1

5 V Gebruikte afkortingen - BFC: base functional component of functionele basiscomponent - C: create : een type gebeurtenis in de levenscyclus van een object waarin dit object gecreëerd wordt - Cfsu: COSMIC functional size unit, de meeteenheid van COSMIC-FFP - Ctsu: COSMIC technical size unit, zelf ingevoerde eenheid voor de meting van het architectuurmodel - COSMIC-FFP: meetmethode voor functionele omvang o COSMIC: common software measurement international consortium o FFP: full function points - E: o : een type gebeurtenis waarmee de levenscyclus van een object beëindigd wordt (MERODE-model) o entry : een type databeweging in het COSMIC-FFP-model o exploratie : type navigatiecontext in het OOWS-model o Uit de context blijkt steeds in welke betekenis de afkorting gebruikt wordt. - EDG: existence depency graph of bestaansafhankelijkheidstabel - FPA: function point analysis, voorloper van het COSMIC-FFP-model - FSM: o functional size measurement of functionele omvangmeting o finite state machine (diagram waarin de levenscyclus van een object weergegeven wordt) o Uit de context zal steeds blijken welke in betekenis de afkorting gebruikt wordt. - H: home : type navigatiecontext in het OOWS-model - ISS(-layer): information system services -layer of de functionaliteitslaag - M: modify een type gebeurtenis in de levenscyclus van een object waarin dit object een verandering ondergaat - MERODE: Model-based Existence-depency Relationship Object-oriented DEvelopment, het conceptueel model dat in dit werk als voorbeeld gebruikt wordt - OET: object-event table of object-eventtabel - OOWS: object oriented web services, model dat als aanvulling bij het MERODEmodel gebruikt wordt (voor de navigatielaag) - R: read : type databeweging in het COSMIC-FFP-model - S: sequence : type navigatiecontext in het OOWS-model - SSD: service specification diagram, een diagram waarin input- en outputdiensten weergegeven worden - UML: unified modeling language - W: write : type databeweging in het COSMIC-FFP-model - X: exit : type databeweging in het COSMIC-FFP-model

6 VI Lijst van de tabellen Tabel 1: COSMIC-FFP en business main modeling Tabel 2: Telregels voor de bedrijfslaag van het conceptueel model Tabel 3: Telregels voor de bedrijfslaag van het conceptueel model bij partiële informatie Tabel 4: COSMIC-FFP en information systems modeling Tabel 5: Telregels voor de functionaliteitslaag van het conceptueel model Tabel 6: COSMIC-FFP en navigation modeling Tabel 7: Telregels voor de navigatielaag van het conceptueel model Tabel 8: Aantal Cfsu bij partiële informatie Tabel 9: Toestandsovergangstabel voor LENING_CD Tabel 10: Aantal Cfsu van het bedrijfsmodel Tabel 11: aantal Cfsu van het functionaliteitsmodel Tabel 12: COSMIC-FFP en de interfacelaag van het architectuurmodel Tabel 13: Telregels voor de interfacelaag van het architectuurmodel van de bedrijfslaag Tabel 14: COSMIC-FFP en de gebeurtenislaag van het architectuurmodel Tabel 15: Telregels voor de gebeurtenislaag van het architectuurmodel van de bedrijfslaag. 87 Tabel 16: COSMIC-FFP en de bedrijfslaag van het architectuurmodel Tabel 17: Telregels voor de bedrijfslaag van het architectuurmodel van de bedrijfslaag Tabel 18: Rapportering meetresultaten conceptueel model Tabel 19: Rapportering meetresultaten architectuurmodel Tabel 20: Toestandsovergangstabel voor LID Tabel 21: Toestandsovergangstabel voor BOEK Tabel 22: Toestandsovergangstabel voor KOPIJ_BOEK Tabel 23: Toestandsovergangstabel voor LENING_BOEK Tabel 24: Toestandsovergangstabel voor RESREVERING_BOEK Tabel 25: Toestandsovergangstabel voor CD Tabel 26: Toestandsovergangstabel voor KOPIJ_CD Tabel 27: Toestandsovergangstabel voor LENING_CD Tabel 28: Toestandsovergangstabel voor RESERVERING_CD...1-6

7 VII Lijst van de figuren Figuur 1: Het COSMIC-FFP meetproces Figuur 2: Het identificeren van de grenzen (zowel 'front ', 'back ' als tussen de verschille lagen) Figuur 3: De verschille soorten databewegingen Figuur 4: Gelaagde architectuur Figuur 5: Levenscycli onafhankelijke en afhankelijke objecten Figuur 6: Bestaansafhankelijkheidsdiagram voor bibliotheekvoorbeeld in de notatie van MERODE (links) en in UML-notatie (rechts) Figuur 7: Object-eventtabel bibliotheekvoorbeeld Figuur 8: Finite State Machine voor KOPIJ van het bibliotheekvoorbeeld Figuur 9: Service Specification Diagram voor een inputfunctie Figuur 10: User diagram voor navigatielaag Figuur 11: Navigatiediagram van een lid van de bibliotheek Figuur 12: Navigationele context 'Multimedia' voor het type gebruiker 'Lid' Figuur 13: Bestaansafhankelijkheidsdiagram voor de bibliotheekcase Figuur 14: Object-eventtabel voor de bibliotheekcase Figuur 15: FSM LENING_CD Figuur 16: SSD voor het ontlenen van boeken Figuur 17: SSD voor het afdrukken van overzichten van leningen Figuur 18: navigatiediagram voor een lid van de bibliotheek Figuur 19: Architectuurmodel van de bedrijfslaag Figuur 20: Het testprincipe Figuur 21: FSM LID Figuur 22: FSM BOEK Figuur 23: FSM KOPIJ_BOEK Figuur 24: FSM LENING_BOEK Figuur 25: FSM RESERVERING_BOEK Figuur 26: FSM CD Figuur 27: FSM KOPIJ_CD Figuur 28: FSM LENING_CD Figuur 29: FSM RESERVERING_BOEK Figuur 30: t1 Inschrijven nieuwe leden en bijhouden gegevens leden Figuur 31: t2 Uitschrijven leden Figuur 32: t3 Leningen boeken registreren Figuur 33: t4 Leningen cd s registreren Figuur 34: t5 Terugbrengen boeken registreren Figuur 35: t6 Terugbrengen cd s registreren Figuur 36: t7 Verliezen boeken registreren Figuur 37: t8 Verliezen cd s registreren Figuur 38: t9/t10 Reserveringen boeken verwerken Figuur 39: t11/t12 Reserveringen cd s verwerken Figuur 40: t13 Inbrengen nieuwe boeken Figuur 41: t14 Inbrengen nieuwe cd s Figuur 42: t15 Verwijderen boeken Figuur 43: t16 Verwijderen cd s Figuur 44: tr1 Leningen boeken, die een maand over tijd zijn, verwerken...2-8

8 VIII Figuur 45: t2 Leningen cd s, die een maand over tijd zijn, verwerken Figuur 46: tr3 Brieven sturen voor leningen van boeken die 1 of 2 weken over tijd zijn Figuur 47: tr4 Brieven sturen voor leningen van cd s die 1 of 2 weken over tijd zijn Figuur 48: r1 Afdrukken van de leningen van een bepaald lid Figuur 49: r2 Opstellen lijst boeken Figuur 50: r3 Opstellen lijst cd s Figuur 51: r4 Afdrukken rapport verloren boeken Figuur 52: r5 Afdrukken rapport verloren cd s

9 1 Inleiding Vooraleer aan te vangen met de eigenlijke tekst, is het wellicht handig eerst de structuur weer te geven. In het eerste deel vindt u een algemene begripsomschrijving: wat is functionele omvangmeting en waarvoor wordt het gebruikt, waar situeert COSMIC-FFP zich binnen de functionele omvangmeting en waar kadert dit werk binnen het onderzoek rond de toepassing van COSMIC-FFP. Het tweede deel biedt een overzicht van het COSMIC-model zelf en van het MERODE-model dat als voorbeeld van een gelaagd conceptueel model gebruikt wordt. Ook het OOWS-model wordt in deze sectie voorgesteld. Dit model wordt als aanvulling bij MERODE gebruikt aangezien MERODE zelf geen navigatiemodel heeft. Deel drie vormt het zwaartepunt van dit werk. Hierin worden de meetregels opgesteld waarmee de functionele omvang van een gelaagd systeem, ontwikkeld met MERODE, euidig bepaald moet kunnen worden. Deze regels worden hierin laag per laag opgesteld en nadien toegepast in een eenvoudig voorbeeld. Vervolgens wordt in deel vier het COSMIC-FFP-model toegepast op het architectuurmodel van de bedrijfslaag van MERODE. Dit model bevat reeds enkele technische keuzes, we verlaten dus de pure conceptuele modellering en de functionele omvangmeting. Aangezien deel vier verder gaat dan de pure toepassing van COSMIC op het gebied waarvoor het ontwikkeld is, moet nagedacht worden over een correcte rapportering van de bekomen resultaten. Deel vijf behandelt deze rapportering. Tenslotte vindt u in deel zes van dit werk een ontwerp van een test waarmee de regels ontwikkeld in deel drie getoetst kunnen worden.

10 2 DEEL 1: Begripsomschrijving, situering in de literatuur en probleemstelling 1 Begripsomschrijving 1.1 Wat is functionele omvangmeting? Organisaties betrokken bij het ontwikkelen van software hebben tijden gezocht naar degelijke methodes om bijvoorbeeld de efficiëntie van softwareontwikkeling te meten, naar methodes om de kost van ontwikkeling te schatten, (zie hieronder in punt 1.2) Het grote probleem hierbij was om de grootte, de omvang van de software als een getal uit te drukken. De eerste pogingen focusten op het aantal lijnen code of op andere technische aspecten. Het nadeel hiervan is echter dat deze benaderingen heel afhankelijk zijn van de gebruikte methode, van de programmeertaal, enz daarom is naar een nieuw concept gezocht. Het uiteindelijke resultaat van dit onderzoek was het concept functionele omvangmeting ( functional size measurement (FSM)). De maat die hierbij aan de software toegek wordt, is volledig onafhankelijk van technische aspecten. Als basis worden de functionele gebruikersvereisten ( functional user requirements (FUR)) gebruikt. Deze zijn een zuivere beschrijving van de taken die de software voor de eindgebruiker moet vervullen, zonder rekening te houden met de manier waarop deze taken uitgevoerd moeten worden, aan welke snelheid dit moet gebeuren, met welke andere programma s de software compatibel moet zijn, Deze taken moeten zorgvuldig beschreven worden, zodat men een duidelijk zicht krijgt op wat de software precies zal moeten kunnen. Wanneer het programma bijvoorbeeld voor een bibliotheek geschreven wordt, moet duidelijk gesteld worden of het programma alleen de leningen registreert of ook een catalogus bijhoudt. Is het reserveren van boeken mogelijk, drukt het programma een overzicht af van de ontlee items wanneer een lid een nieuwe lening registreert? Een omschrijving als: Het pakket is ontworpen om de taken binnen de bibliotheek te verwerken, volstaat niet. Bij elke taak die wel of niet or de software uitgevoerd moet worden, zal de functionele omvang veranderen.

11 3 Functionele omvangmeting kan niet alleen op basis van een tekstuele omschrijving van de gebruikersvereisten gebeuren, maar op basis van elke mogelijke specificatie van de gebruikersvereisten. Dit kunnen bijvoorbeeld cumenten zijn die opgesteld werden tijdens de analysefase van de ontwikkeling van een applicatie, een handleiding van het uiteindelijke programma of het programma zelf. Het volstaat dat duidelijk kan onderscheiden worden welke taken het programma moet uitvoeren. Vertrekk van de functionele vereisten wordt dan met de hulp van een meetmethode, de omvang van de software bepaald. Het resultaat van deze meting zal verschillen naargelang de meetmethode. Elke methode heeft immers een eigen visie op wat nu precies deze omvang bepaalt (zie ook verder (p. 7 en p. 15)). Het element dat de omvang bepaalt, is de functionele basiscomponent 1 ( base functional component (BFC)). Dit is de elementaire eenheid van de functionele vereisten die gedefinieerd en gebruikt wordt or een methode voor functionele omvangmeting voor meeteleinden. Aan deze BFC s wordt dan een numerieke waarde toegek. 1.2 Waarvoor wordt functionele omvangmeting gebruikt? Het concept functionele omvang wordt niet alleen op academisch niveau gehanteerd. In het bedrijfsleven vindt dit begrip een heel aantal toepassingen 2, die in twee categorieën onder te brengen zijn: projectmanagement enerzijds en voorspelling en prestatiemanagement anderzijds Projectmanagement De vooruitgang van een project nagaan In een vroege fase van de levenscyclus van een softwareontwikkelingsproject, kan een overzicht gemaakt worden van de BFC s, van de omvang, van het systeem dat men voor ogen 1 ISO/IEC :1998 Information technology Software measurement Functional size measurement Part 1: Definition of concepts, punt 3.1 p. 1 2 ISO/IEC :1998 Information technology Software measurement Functional size measurement Part 1: Definition of concepts, Appix A

12 4 heeft (dit kan zowel een nieuw te ontwikkelen als een aan te passen systeem zijn). Deze omvang kan ook apart bepaald worden voor delen van de software. Aan de hand van dit overzicht kan de projectmanager nagaan en communiceren hoe het project evolueert. Dit kan ten eerste or te bekijken waar veranderingen aangebracht zijn in de verzameling BFC s (welke BFC s zijn toegevoegd of verwijderd or veranderingen in het bereik van het takenpakket van de software). Ten tweede kan de projectmanager bekijken welke BFC s reeds ontwikkeld zijn en welke nog niet. Het aantal ontwikkelde BFC s kan uitgedrukt worden als percentage van het totale aantal om zo de vooruitgang van het project weer te geven. Het managen van wijzigingen in het bereik van het takenpakket van de software (de scope van de software) Vroeg in de levenscyclus van een ontwikkelproject, kan men een overzicht opstellen van BFC s als contract tussen de toekomstige gebruikers en de ontwikkelaar. Voor elke wijziging in de gebruikersvereisten, in het takenpakket dat de software moet kunnen uitvoeren, kan bepaald worden wat de impact zal zijn op de functionele omvang van het uiteindelijke systeem. De functionele omvang kan als basis gebruikt worden om de vereiste inspanning nodig om deze aanpassingen or te voeren, te berekenen en om de impact op de planning van het project na te gaan. Op basis hiervan kunnen onderhandelingen gevoerd worden over eventuele wijzigingen in dit projectplan. Meten in hoeverre een pakket aan de gevraagde functionaliteit beantwoordt Naast ontwikkeling van eigen applicaties of nieuwe applicaties, kan ook geopteerd worden voor het aankopen van een bestaand softwarepakket dat dan de taken uitvoert die men wil automatiseren. In dit geval berekent men enerzijds de functionele omvang van de gewenste gebruikersvereisten en anderzijds de functionele omvang van de taken die het pakket ook effectief uitvoert. Het percentage van de gewenste vereisten dat vervuld wordt kan zo gebruikt worden als één van de beslissingscriteria bij de keuze tussen verschille pakketten onderling en/of tussen een aan te kopen pakket en eigen ontwikkeling.

13 Voorspelling en prestatiemanagement In dit stuk wordt behandeld hoe functionele omvang gebruikt kan worden voor het maken van voorspellingen en het meten van prestaties. Functionele omvang wordt hier bekeken als een factor voor normalisering. Hierbij wordt de functionele omvang ingevoerd in een model dat dan het verband legt met de te voorspellen variabele. Deze modellen worden ontwikkeld op basis van grote datasets, waarin dan vaste oorzakelijke verbanden tussen de functionele omvang en de elvariabele gezocht worden met statistische technieken. Berekening van de waarde van software In veel bedrijven is software een vast actief, een werkingsmiddel dat vast verbonden is met het bedrijf, net zoals een gebouw of een machine. Dit moet dan ook gewaardeerd worden in de boekhouding, het moet op de balans voorkomen. De functionele omvang wordt hiervoor in een model ingevoerd dat ofwel de waarde van de software zelf geeft, ofwel de kost om deze te vervangen of opnieuw te ontwikkelen. Productiviteitsmanagement Functionele omvang kan helpen bij het managen van productiviteit bij ontwikkelings-, aanpassings- en onderhoudsprocessen van software. Voor deze toepassing stelt men productiviteitsindicatoren op (functionele omvang gedeeld or inspanning, tijd of kost). Deze bestudeert men samen met demografische factoren (de omgevingsfactoren, de projectfactoren en de karakteristieken van het betrokken personeel) die de processen kunnen beïnvloeden. Voorbeelden hiervan zijn: de ervaring van het ontwikkelingsteam, het gebruik van ontwikkelingstools, werkomstandigheden, de programmeertaal waarin de applicatie ontwikkeld wordt, Productiviteit kan gemanaged worden or deze factoren te manipuleren en na te gaan of het gewenste productiviteitseffect bereikt werd. Kwaliteitsmanagement Hierbij worden dezelfde demografische factoren bekeken als in het vorig punt, maar hier wordt hun invloed op een andere variabele bekeken. Deze variabele is de defectichtheid ( defect density ) of het aantal nieuw ontdekte defecten per functiepunt, gedure een

14 6 bepaalde periode. Ook hier kan men de demografische factoren wijzigen om het effect op de defectichtheid na te gaan. De nodige middelen voorspellen Voor projecten waarbij nieuwe software ontwikkeld wordt of bestaande software aangepast wordt, bestaan wiskundige modellen die als resultaat een schatting geven van de middelen nodig om een project binnen een bepaalde tijd af te werken of die een schatting geven van de tijd nodig om met bepaalde middelen een project te voltooien. Deze modellen gebruiken naast de functionele omvang ook de demografische karakteristieken, de technische vereisten en de kwaliteitsvereisten als input. Onderhoudsbudget opstellen De functionele omvang van bestaande systemen kan gemeten worden, net zoals de kosten voor het onderhoud van deze bestaande systemen. De vergelijking van deze historische gegevens, kan gebruikt worden voor het voorspellen van toekomstige onderhoudsbudgetten. Contractmanagement Functionele omvang kan gebruikt worden als basis voor contracten met softwareleveranciers. Er kunnen bijvoorbeeld voorwaarden gesteld worden aan de productiviteit van deze leverancier (aantal geleverde functionele omvangeenheden per tijdseenheid) of de prijs kan onderhandeld worden aan de hand van een vast bedrag per geleverde functionele omvangeenheid.

15 7 2 Situering in de literatuur Hoever staat het onderzoek in verband met functionele omvangmeting en waar vertrekt dit werk bijgevolg? De meest gebruikte methode voor functionele omvangmeting tot hiertoe is Function Point Analysis (FPA) [10]. Als basisconcepten binnen deze meetmethode worden data files (bestanden) en transactional functions (functies) onderscheiden. Deze benadering was zeer geschikt voor traditionele ontwikkelingsmethodes, maar zorgt voor problemen wanneer objectgeoriënteerde systemen gemeten moeten worden. Een wezenlijk kenmerk van objectgeoriënteerde ontwikkeling is immers dat een object zowel de data-elementen als de functies om deze data mee te onderhouden en te bewerken, omvat. Verder was FPA ook niet toepasbaar op alle types software, maar enkel op Management Information Systems (MIS). Dit heeft ervoor gezorgd dat een aantal afgeleide methodes ontstaan zijn, waarvan COSMIC Full Function Points (COSMIC-FFP) [4] de recentste is. Deze methode wordt beschouwd als de tweede generatie meetmethodes. Ze is toepasbaar op alle types software en ook op de huidige ontwikkelingstechnieken. COSMIC-FFP is bovien erk als internationale standaard (ISO/IEC 19761). Om toepasbaar te zijn op alle ontwikkelingsmethodes, zijn de meetregels opgesteld or COSMIC echter zeer algemeen. Voor specifieke ontwikkelingsmethodes zijn daarom mappings 3 nodig, die vertrekken vanuit deze algemene regels en aan de hand daarvan methodespecifieke regels ontwikkelen. Een eerste mapping werd ontworpen or Bévo et al. [5] voor UML (Unified Modeling Language [20]), meer bepaald voor UML class diagrams en use case diagrams. Gelijkaardig werk werd verricht or Jenner [16] voor UML sequence diagrams. Deze mappings focussen echter alleen op UML, zonder daarbij rekening te houden dat dit vooral een notatiewijze is die 3 Deze Engelstalige term werd behouden omdat hier geen valabel Nederlandstalig alternatief te vinden is. Een mapping uitwerken van een conceptueel model naar een methode voor functionele omvangmeting, is zoeken naar equivalente begrippen tussen deze twee methodes. Het is als het ware het in kaart brengen van equivalente begrippen.

16 8 gebruikt wordt or ontwikkelingsmethodes. De interacties die deze methodes met behulp van UML modelleren worden dus groteels verwaarloosd. Voor objectgeoriënteerde methodes zijn ondertussen ook enkele mappings ontwikkeld. Recent werd werk van Conri-Fernandez e.a. [6] gepubliceerd, waarin zij het OO-Method Requirements Model [11] op het algemene COSMIC-model mappen. Dit requirements model laat toe op een gestructureerde manier over te gaan van gebruikersvereisten naar het conceptueel model dat deze vereisten gestructureerd voorsteld. Dit werk levert dus een meting helemaal aan het begin van de ontwikkelingscyclus. Verder is or Diab e.a. een mapping ontwikkeld voor real-time systemen op basis van de Real-time Object Oriented Modeling (ROOM) methode [7]. Hierbij gaan de auteurs uit van zogenaamde ROOMcharts (een soort diagrammen om toestandsovergangen weer te geven) als basis voor hun meting. 3 Probleemstelling Zoals uit vorig overzicht blijkt, is COSMIC-FFP reeds op een aantal methodes toegepast. Wat echter geen van deze mappings bekeken heeft, is een gelaagde architectuur. Het concept layer van COSMIC wordt wel tweemaal aangehaald, maar nergens wordt het met een duidelijk voorbeeld geïllustreerd of wordt het concept grondig uitgewerkt. Jenner suggereert een equivalent voor het begrip software layer in de vorm van swimlanes in sequence diagrams, maar geeft hier geen voorbeeld van. In een latere publicatie [17] over het toepassen van COSMIC-FFP voor de meting van sequence diagrams wordt dit idee bovien niet verder uitgewerkt. Ook Diab e.a. gebruiken het concept software layer in het vervolg op hun mapping voor ROOM [8]. In dit werk gaan de auteurs niet slechts uit van een ROOM-model, maar van een volledig RRRT 4 -model (Rational Rose Real-Time). Hierin wordt het begrip softwarelaag geïnterpreteerd als een verzameling capsules (dit zijn actieve objecten) binnen een RRRT- 4 ROOM wordt ondersteund or de RRRT toolset

17 9 model. Er wordt echter niet vermeld hoe dergelijke verzamelingen in een model afgelijnd moeten worden. Een focus op gelaagde archtecturen vinden we wel terug bij Poels [19], die een mapping ontwikkelde voor de bedrijfslaag en de functionaliteitslaag van het MERODE-model [21]. Deze tekst werd echter opgesteld aan de hand van versie 2.1 van COSMIC-FFP. Het was echter pas de recentste versie van COSMIC (versie 2.2) die als ISO/IEC-standaard erk werd. Verder zou het ook interessant zijn om de omvang van een systeem te meten in een verdere fase dan de conceptuele modellering, net zoals dit bij Conri-Fernández bekeken werd net voor de conceptuele modellering. Dit werk zal dan ook een voortzetting zijn van het werk van Poels [19], waarin een mapping voor MERODE wordt opgemaakt naar versie 2.1 van COSMIC [3]. De elstellingen van dit werk zullen zijn: - nagaan in hoeverre de opgestelde regels volen aan COSMIC 2.2 [4] die als ISO/IEC-standaard geldt; - het uitbreiden van deze regels met bijkome regels voor een navigatiemodel (het OOWS-model [9]); - een duidelijk voorbeeld uitwerken om de meting van gelaagde conceptuele modellen te illustreren; - een uitbreiding van COSMIC uitwerken voor het architectuurmodel van de bedrijfslaag van MERODE-modellen.

18 10 DEEL 2: Voorstelling van het COSMIC-FFP-model, het MERODE-model en het OOWS-model 1 Het COSMIC-FFP model In dit deel vindt u een bespreking van de COSMIC-concepten die nodig zijn om dit werk te begrijpen. Een volledig overzicht van dit model vindt u terug in de COSMIC-FFP Measurement Manual (versie 2.2) 5. COSMIC Full Function Points is een methode om de functionele omvang van software te meten. Deze methode bestaat uit de logische opeenvolging van een aantal operaties. De functionele vereisten die aan de software gesteld worden, vormen het vertrekpunt. Uit deze functionele vereisten leidt men af welke functionele processen plaatsvinden. Hoe meer processen plaatsvinden, hoe groter de functionele omvang. Deze functionele vereisten kunnen onder vele vormen beschikbaar zijn. Bijvoorbeeld in de vorm van een conceptueel model. Net omdat deze functionele vereisten niet in een standaardvorm beschikbaar zijn, worden een aantal mappingregels toegepast, om ze in de vorm van het generieke COSMIC-FFP softwaremodel te brengen. In dit model zijn de relevante elementen (de verschille lagen en de databewegingen ertussen (zie verder)) euidig te onderscheiden, de overbodige elementen zijn geëlimineerd voor de meting. Door deze tussenstap zal het resultaat van de meting onafhankelijk zijn van de vorm waaronder de functionele vereisten beschikbaar zijn en van de methode die gebruikt werd om de software te ontwikkelen. Daarna wordt de eigenlijke meting toegepast, wat als resultaat de functionele omvang van het softwaresysteem geeft. 5 ABRAN A., DESHARNAIS J.-M., OLIGNY S., ST-PIERRE D. en SYMONS C., 2003, COSMIC-FFP Measurement Manual (The COSMIC Implementation Guide for ISO/IEC 19761:2003), Version 2.2, The Common Software Measurement International Consortium

19 11 Figuur 1: Het COSMIC-FFP meetproces 6 Vooraleer aan een meting begonnen wordt moeten voorafgaand volge zaken bepaald worden: - Het bereik van een meting (scope of measurement) bepaalt de software die gaat bemeten worden en scheidt deze software van haar omgeving. - Het standpunt (measurement viewpoint) dat bij de meting wordt ingenomen. Naargelang men de software als eindgebruiker of als ontwikkelaar bekijkt, zullen de resultaten duidelijk van elkaar verschillen. Wanneer men immers de software meet als eindgebruiker, zal de softwareapplicatie als geheel bekeken worden in de meting, zonder rekening te houden met substructuren. Voor de eindgebruiker is het immers niet relevant wat zich binnenin de applicatie afspeelt. Hij hecht enkel belang aan het eindresultaat. De ontwikkelaar daarentegen bekijkt de samenstelle lagen van de applicatie. Hij moet immers alle lagen afzonderlijk ontwerpen en programmeren. Naargelang er meer interacties zijn tussen de lagen, zal voor hem de ontwikkelinspanning zwaarder zijn. Hij telt dus niet alleen de databewegingen van en naar de applicatie, maar ook de databewegingen die intern, tussen de verschille lagen van de applicatie plaatsvinden. - Ook het el (purpose) van de meting moet vooraf afgelijnd worden. Het el van de meting helpt het bereik van de meting, de nodige informatie, het meetstandpunt, de vereiste nauwkeurigheid, te bepalen. Naargelang dit el zal dan ook ofwel de COSMIC-FFP meetmethode, ofwel een plaatselijk afgeleide benadering van deze methode gebruikt worden. De resultaten van de meting kunnen verschillen naargelang het el van de meting. Men kan bijvoorbeeld in het begin van de analysefase meten 6 COSMIC-FFP Measurement Manual v. 2.2, p16

20 12 om snel een idee te krijgen van de functionele omvang van het systeem en dus van de inspanning die het verder uitwerken zal vereisen. Deze meting zal minder nauwkeurig zijn dan wanneer men op het einde van de analyse, wanneer alle informatie beschikbaar is, of nog verder in de ontwikkeling, meet. 1.1 De mapping fase In deze fase van de omvangmeting wordt overgegaan van een verzameling van functionele vereisten, naar de standaardbegrippen van COSMIC-FFP. Deze mapping bevat vier essentiële fasen Het identificeren van lagen in de software (software layers) Binnen het bereik van de meting splitst men de software in delen op. Een applicatie kan ofwel uit één laag, ofwel uit meerdere lagen bestaan. In het eerste geval omvat de software enkel de applicatie zelf en valt al het overige (bvb. database, drivers voor hardware, ) buiten het bereik van de applicatie. In het andere geval worden ook de overige stukken mee ontwikkeld. Voor elk deel onderscheidt men een laag. COSMIC biedt de mogelijkheid om deze lagen apart te meten. De definitie van een software layer binnen COSMIC is de volge: Een softwarelaag is het resultaat van de onderverdeling op basis van functionaliteit van de softwareomgeving, zo dat alle opgenomen processen op een zelfde niveau van abstractie opereren. Ook binnenin een softwarelaag wordt de software in delen uitgesplitst. Deze stukken werken dan op eenzelfde niveau van abstractie. Men noemt ze evenwaardige items of peer items Het identificeren van grenzen (boundaries) Een grens (boundary) wordt gedefinieerd als de conceptuele scheiding tussen het deel van de software dat gaat gemeten worden en de omgeving waarin deze opereert, gezien vanuit het standpunt van de gebruikers.

21 13 Deze definitie van het concept grens is degene die we aantreffen in de COSMIC measurement manual. Wanneer men deze definitie leest met in het achterhoofd de definitie van measurement viewpoint, dan kan de vraag gesteld worden: En wat als het standpunt dat van de ontwikkelaar is? Het gebruik van het woord gebruiker in de definitie van het begrip grens zorgt voor de verwarring. Hier mag gebruiker niet noodzakelijk bekeken worden als de eindgebruiker van de software. Gebruiker dient te worden geïnterpreteerd in de betekenis die COSMIC eraan geeft: Elke persoon die of elk object dat, op het één of ander moment, communiceert of samenwerkt met de software (die gemeten wordt). Een gebruiker kan dus zowel een eindgebruiker zijn, als een softwarelaag. Wanneer vanuit het standpunt van de ontwikkelaar gemeten wordt, zal er een grens zijn tussen de eindgebruiker en de applicatie, een grens tussen de permanente opslag en de applicatie, en bovien zullen er zich tussen de verschille lagen van de software, die eerst apart gemeten worden en waarvan de resultaten nadien geaggregeerd worden ook grenzen bevinden. Bij een meting vanuit het standpunt van de eindgebruiker daarentegen worden enkel de grenzen die zich aan de front en aan de back bevinden bekeken. De grens aan de front is degene die de eindgebruiker scheidt van de applicatie, de back grens vormt de scheiding tussen de applicatie en de permanente opslag. Figuur 2: Het identificeren van de grenzen (zowel 'front ', 'back ' als tussen de verschille lagen) 7 7 COSMIC-FFP Measurement Manual v. 2.2, p20

22 Het identificeren van functionele processen (functional processes) Een functioneel proces is volgens de measurement manual de elementaire component van de functionele vereisten. Zo n proces omvat een unieke, samenhange en onafhankelijk uitvoerbare verzameling databewegingen. Een proces wordt gestart or één of meerdere gebeurtenissen (triggering events) die buiten de grenzen van de software plaatsvinden. Het proces is beëindigd wanneer het alle taken heeft uitgevoerd die moeten volbracht worden voor die gebeurtenis. Elk functioneel proces bestaat dus uit databewegingen minstens uit twee databewegingen zelfs. Voor elk functioneel proces geldt immers dat er een gebeurtenis moet plaatsvinden waaror het proces wordt gestart, hiervoor wordt een bericht naar het proces gestuurd. Het proces moet bovien een nuttige taak vervullen (gegevens wegschrijven naar onderligge lagen of gegevens terugsturen naar de laag die erom vroeg), dit geeft zeker een tweede databeweging. COSMIC vertrekt van twee basisprincipes die gelden voor alle software die met de COSMICmethode kan gemeten worden. Het is vanuit deze twee principes dat COSMIC de databeweging als basis voor de metingen beschouwt. De twee basisprincipes zijn: 1) De software gedraagt zich als een systeem: er wordt input ingebracht en nuttige output voor de eindgebruiker geproduceerd. 2) De software manipuleert informatie waarin datagroepen kunnen onderscheiden worden die bestaan uit data-attributen. Deze basisprincipes impliceren databewegingen over de grenzen van de software heen, zowel tussen de lagen onderling als naar de front en de back. Er kunnen vier soorten databewegingen onderscheiden worden: entries, exits, reads en writes Het identificeren van datagroepen (data groups) In deze fase moeten alle datagroepen geïdentificeerd worden. Een datagroep is de eenheid die or een databeweging verplaatst wordt en wordt gedefinieerd als een specifieke, niet-ledige, niet-georde en niet-overbodige verzameling data-attributen, waarin elk opgenomen dataattribuut een complementair aspect van hetzelfde object of interest beschrijft.

23 15 Een datagroep heeft een bepaalde levensduur of persistentie ( persistence ). Drie persistentietypes worden onderscheiden: - Vluchtig ( transient ): deze datagroep bestaat enkel tijdens de uitvoering van het functioneel proces. - Kort ( short ): de levensduur van deze datagroep overschrijdt de levensduur van het functioneel proces, maar zodra de applicatie wordt uitgeschakeld gaat deze datagroep verloren. - Oneindig ( indefinite ): ook wanneer de applicatie uitgeschakeld wordt, blijft de inhoud van deze datagroep gevrijwaard. 1.2 De measurement fase Na de mapping bevinden de functionele gebruikersvereisten zich in de vorm van het COSMIC-FFP software model. Hierop wordt de procedure van de measurement fase uitgevoerd. Het resultaat van deze meting is een numerieke waarde voor de functionele omvang van de software die zich binnen het bereik van de meting bevindt Het identificeren van databewegingen Binnen elk functioneel proces, worden de subprocessen geïdentificeerd. Deze subprocessen zijn de databewegingen. Een databeweging verplaatst één of meerdere attributen die bij eenzelfde datagroep horen. Er zijn vier soorten databewegingen: - Een ENTRY (E) is een type databeweging dat een datagroep van de gebruiker naar het functioneel proces waar deze datagroep nodig is brengt, over de grens tussen de gebruiker (die dus zowel een eindgebruiker of een ander stuk software kan zijn) en de software heen. Een entry wordt verondersteld elk verzoek tot entry met zich mee te dragen. - Een EXIT (X) is een type databeweging dat een datagroep van een functioneel proces naar de gebruiker die deze datagroep nodig heeft, brengt, over de grens tussen de gebruiker en de software heen.

24 16 - Een READ (R) is een type databeweging dat een datagroep ophaalt uit de permanente opslag en deze datagroep binnen het bereik van het functioneel proces, dat deze datagroep nodig heeft, brengt. Een read wordt verondersteld elk verzoek tot read met zich mee te dragen. - Een WRITE (W) is een type databeweging dat een datagroep vanuit een functioneel proces wegschrijft naar de permanente opslag. Figuur 3: De verschille soorten databewegingen 8 COSMIC-FFP onderscheidt bij conventie enkel databewegingen, geen datamanipulaties. In de plaats daarvan stelt de methode dat alle types databewegingen alle elementen nodig voor de datamanipulaties in zich meedragen. Dit heeft tot gevolg dat COSMIC vooral geschikt is om de functionele omvang te meten van systemen die veel databewegingen uitvoert. Het meten van manipulatierijke systemen ligt moeilijker. Hiervoor kunnen wel lokale COSMICuitbreidingen gedefinieerd worden. In ISO-termen zijn de types databewegingen de types functionele basiscomponenten (BFC) gebruikt or COSMIC-FFP (zie hoger p. 2). Deze componenten geven de visie op functionele omvangmeting weer die or een bepaalde methode wordt ingenomen. Elke methode zoekt immers naar het element in de ontwikkeling van een applicatie dat het programmeerwerk veroorzaakt. Volgens COSMIC zal er meer inspanning nodig zijn om een toepassing te ontwikkelen naarmate er meer databewegingen plaatsvinden, volgens FPA daarentegen zal het aantal functionele processen de drijve factor achter de vereiste inspanning zijn. Zo heeft elke methode een specifiek idee rond functionele omvangmeting. 8 COSMIC-FFP Measurement Manual v. 2.2, p22

25 Het toepassen van de meetfunctie Een meetfunctie is een mathematische functie die een waarde toekent aan haar argument, gebaseerd op een meeteenheid. De COSMIC-FFP meeteenheid, 1 Cfsu (Cosmic functional size unit), is gelijk aan één databeweging. Het argument van de COSMIC meetfunctie is dus het subproces. Anders gesteld, wordt hier aan de functionele basiscomponent, de databeweging, een numerieke waarde gekoppeld: één BFC (van één van de vier types) is gelijk aan één Cfsu. Per databeweging wordt 1 Cfsu geteld binnen elke laag, zo bekomt men de functionele omvang van een laag. Het samentellen van de resultaten voor elke laag geeft de totale functionele omvang van het systeem. Bij het meten van verschille lagen, heeft COSMIC er zelf voor gezorgd dat databewegingen niet dubbel geteld worden. In de measurement manual is volge regel terug te vinden betreffe de databewegingen: Een databeweging van een bepaald type (E, X, R of W) die een bepaalde datagroep verplaatst (data over één bepaald object of interest ), wordt in het algemeen maar eenmaal geïdentificeerd in een functioneel proces. Bijvoorbeeld: Stel dat een READ databeweging nodig is in de functionele vereisten, die in praktijk een groot aantal READ s vraagt, zoals het orlopen van een lijst op zoek naar objecten die aan een bepaald criterium volen. Bij het meten tellen we echter slechts één READ databeweging. De reden hiervoor is dat we types databewegingen tellen en niet het afzonderlijk optreden van deze databewegingen.

26 18 2 Het MERODE-model en het OOWS-model Het MERODE-model is een objectgeoriënteerd, gelaagd conceptueel model, dat bovien event-driven (gebeurtenisgericht) is. Dit model wordt gebruikt bij de ontwikkeling van bedrijfssoftware, meer bepaald in de analysefase. In deze sectie volgt een overzicht van de nodige basisbegrippen. Wie een meer diepgaande bespreking van het MERODE-model wenst, kan deze vinden in het MERODE-handboek 9. Ook voor een meer gedetailleerde uitleg rond het OOWS-model verwijzen we naar de literatuur Conceptueel model Een model is de vereenvoudigde weergave van een deel van de werkelijkheid. In het kader van bedrijfsmodellering zal het deel van de realiteit waarin we geïnteresseerd zijn, een deel van de werking van de onderneming zijn. Meerbepaald zullen enkel de bedrijfsprocessen die geautomatiseerd worden or de te ontwikkelen applicatie, in het model opgenomen worden. Wanneer een programma geschreven wordt dat de bewegingen op de rekeningen van de klanten registreert voor een bank, zal de personeelsadministratie niet mee in het model worden opgenomen. Enkel de relevante objecten en hun interacties komen in aanmerking. Een conceptueel model biedt een set van regels om deze modellering op een systematische wijze te laten gebeuren. 9 SNOECK M., DEDENE G., VERHELST M. en DEPUYDT A.-M., 1999, Object-Oriented Enterprise Modelling with MERODE, Leuven University Press, Leuven, 227 blz. 10 FONS J., PELECHANO V., ALBERT M. en PASTOR O., 2003, Development of Web Applications from Web Enhanced Conceptual Schemas, in:conference on Conceptual Modeling (ER), Chicago, Illinois (EE.UU.), Springer-Verlag, Lecture notes in Computer science 2813, blz

27 Objecten Een systeem is een verzameling van met elkaar verbonden elementen die met elkaar interageren. Bij objectgeoriënteerde systemen heten deze elementen objecten. Een object kan gedefinieerd worden als een element van een systeem dat: 1) zich altijd in een bepaalde toestand (state) bevindt. De toestand van een object kan beschreven worden or een set van attributen (attributes). Samen vormen deze attributen de toestandsvector (state vector) van dit object. 2) een bepaald gedrag (behaviour) vertoont. Het gedrag van een object wordt gestuurd or boodschappen (messages) die or andere objecten of or de omgeving verzonden worden. Deze boodschappen geven aanleiding tot het uitvoeren van een bepaalde methode soms ook functie of routine genoemd - (method / function / routine). Elk van die methodes verzorgt een bepaalde dienst. 3) heeft een identiteit (identity). Elk object krijgt een bepaalde identiteit, die geen attribuut is. Deze identiteit wordt or het systeem gedefinieerd en zal normaal gezien niet zichtbaar zijn voor de gebruiker van dit systeem. Opmerking: Het concept identity is dus niet hetzelfde als het concept sleutel ( key ). Het sleutelconcept houdt immers in dat vereist wordt dat bepaalde attributen een unieke waarde hebben. (In een bank zal elk rekeningnummer bijvoorbeeld uniek zijn.) De mogelijkheid bestaat echter, dat dergelijke unieke velden gewijzigd moeten kunnen worden. Daarom kunnen attributen niet gebruikt worden om deze identiteit toe te wijzen. Een object is in feite een individu, een welbepaald element van een type objecten (object type). We kunnen bijvoorbeeld over het object klant 10 spreken tegenover het objecttype klant. Objecten van hetzelfde type hebben dezelfde attributen (elke klant heeft een naam, een adres, ) en dezelfde methodes (van elke bankrekening wordt het sal aangepast wanneer er geld wordt afgehaald, ). Er is evenwel een verschil tussen de attributen en de methodes bij eenzelfde objecttype. Waar alle objecten van eenzelfde objecttype exact dezelfde methodes bezitten, verschillen de waarden van de attributen wel voor elk object van hetzelfde type.

28 20 Bijvoorbeeld: Twee klanten van een bank zullen een verschill rekeningnummer krijgen, maar wanneer deze klanten geld afhalen van hun rekening, dan zal het informatiesysteem dezelfde bewerkingen moeten uitvoeren. Een verzameling individuele objecten van hetzelfde type heet een klasse objecten (object class). 2.3 De lagen binnen een MERODE architectuur Systemen ontwikkeld met MERODE hebben een natuurlijke gelaagde structuur. De lagen worden immers gestructureerd volgens herkomst. Sommige specificaties zijn eigen aan de bedrijfsomgeving deze elementen zouden ook aanwezig zijn zonder informatiesysteem en andere elementen ontstaan dan weer or het werken met een informatiesysteem. De specificaties van de eerste soort vormen samen het bedrijfsmodel (enterprise model of business main model) dat de relevante objecten en hun interacties bevat om het relevante deel van de werking van de onderneming te modelleren. Dit bedrijfsmodel vormt de onderste laag binnen een MERODE architectuur. Figuur 4: Gelaagde architectuur Een bovenligge laag wordt gevormd or de tweede soort specificaties. Deze geven de informatiemogelijkheden van de eindgebruikers weer or een verzameling input- en outputfuncties. Het geheel van deze functies vormt een tweede laag: het functionaliteitsmodel (functionality model of information system services model). Inputfuncties geven gebruikers de mogelijkheid gebeurtenissen die zich in de echte wereld hebben voorgedaan aan de onderligge enterprise layer or te geven (via dewelke deze gegevens in de database opgeslagen worden) of om oude gegevens te updaten. Outputfuncties zorgen dat

29 21 eindgebruikers de gewenste gegevens via het business main model uit de permanente opslag te kunnen ophalen. Boven deze twee lagen zorgt een derde laag, de presentatielaag (user interface layer of presentation layer) voor alles wat te maken heeft met de vorm waarin de informatie aan de gebruiker voorgesteld wordt. Voor deze presentatielaag zijn echter geen formele regels beschikbaar, er is (nog) geen concrete uitwerking van deze laag binnen MERODE. Op hetzelfde niveau als de presentatielaag vinden we bovien nog de navigatielaag. Deze is specifiek voor webapplicaties ontworpen. MERODE heeft geen model voor deze navigatielaag, daarom gebruiken we het navigatiemodel uit OO-Method, meer bepaald de OOWS-uitbreiding. OO-Method is net zoals MERODE een objectgeoriënteerd, gelaagd en event-driven conceptueel datamodel. Deze navigatielaag valt dan ook binnen het bereik van dit werk. Het onderscheid tussen de presentatielaag en de navigatielaag is soms moeilijk. De functionaliteit van de navigatielaag overlapt zelfs deels die van de presentatielaag. Bij het modelleren van navigatieaspecten moet immers steeds nagedacht worden over de wijze waarop deze navigatie op het scherm van de gebruiker zal voorgesteld worden, bijv. waar plaatst men de informatie en onder welke vorm; waar plaatst men de links die voor de navigatie zelf zorgen; waar duidt men aan in welke sectie van de webapplicatie men zich bevindt,? Door op deze manier te structureren komen de stabielste elementen in de onderste laag terecht. Hoe hoger men opklimt in de structuur, hoe onstabieler de elementen. In het algemeen is het zo dat essentiële bedrijfsprocessen stabieler zijn dan de informatiebehoeften van gebruikers en dat deze op hun beurt weer minder zullen variëren dan de manier waarop deze informatie gepresenteerd moet worden. Elke laag maakt enkel gebruik van de functionaliteit die wordt aangeboden or de onderligge lagen. Wanneer in een bepaalde laag veranderingen aangebracht worden, heeft dit dus geen invloed op de lagen die zich lager in de structuur bevinden, deze weten zelfs niets af van het bestaan van de lagen erboven. Dit bevordert de onderhoudbaarheid van het informatiesysteem aanzienlijk. Functies kunnen in en uit de functionaliteitslaag geplugd

30 22 worden, zonder dat aan het onderligge bedrijfsmodel moet geraakt worden, de bovenligge lagen zullen hier wel een invloed van ondervinden: deze extra functionaliteit zal immers op één of andere manier gepresenteerd moeten worden. Voor de navigatiepaden en de user interface faciliteiten geldt hetzelfde: deze maken gebruik van de aanwezige inputen outputfuncties om or de objecten van de bedrijfslaag te navigeren of om deze objecten op het scherm weer te geven. Wanneer een nieuw navigatiepad gecreëerd wordt of wanneer de interface van de applicatie gewijzigd wordt, zal dit niets wijzigen aan de onderligge lagen Het bedrijfsmodel Het enterprise model is een verzameling van drie schema s: - het bestaansafhankelijkheidsdiagram (existence depency graph (EDG)); - de object-eventtabel (object event table (OET)); - volgordediagrammen (sequence diagrams). Het bestaansafhankelijkheidsdiagram De EDG geeft weer welke soorten van objecten in de realiteit van het bedrijf onderscheiden worden en hoe deze objecten zich onderling relateren. Het classificatiemechanisme voor het opstellen van dit diagram is de bestaansafhankelijkheid. Een objecttype A is bestaansafhankelijk van een ander objecttype B, als en slechts als elk object van de klasse A voortdur verbonden is met minimum één, maximum één en altijd hetzelfde object van de klasse B. De levenscyclus van het object B zal dus altijd de levenscyclus van object A volledig omvatten. In onderstaande figuur wordt een vergelijking gemaakt tussen de levenscyclus van een onafhankelijk object (B) en de mogelijke levenscycli van het afhankelijke object (A).

31 23 Figuur 5: Levenscycli onafhankelijke en afhankelijke objecten 11 In een bibliotheek bijvoorbeeld kunnen we de objecttypes TITEL, KOPIJ, LID en LENING onderscheiden. Elke kopij zal precies één en altijd dezelfde titel hebben. De kopij is dus bestaansafhankelijk van de titel. Figuur 6: Bestaansafhankelijkheidsdiagram voor bibliotheekvoorbeeld in de notatie van MERODE (links) en in UML-notatie (rechts) SNOECK M., DEDENE G., VERHELST M. en DEPUYDT A., 1998, Object-oriented enterprise modeling with MERODE, Leuven University Press, p SNOECK M., DEDENE G., VERHELST M. en DEPUYDT A., 1998, Object-oriented enterprise modeling with MERODE, Leuven University Press, p 64

32 24 In de EDG staan de bestaansafhankelijke objecttypes (depent object) bij conventie onderaan, maar dit is geen dwinge regel De onafhankelijke types (master object) staan bovenaan. Ook de cardinaliteit van de relatie staat aangegeven. De cardinaliteit geeft aan hoeveel afhankelijke objecten een master object kan hebben. Er kunnen bijvoorbeeld meerdere kopijen van dezelfde titel in de bibliotheek aanwezig zijn, maar elke kopij kan slechts eenmaal uitgele worden. De cardinaliteit van de relatie tussen titel en kopij zal dus veel (many, vandaar de notatie M ) zijn, de cardinaliteit van de relatie tussen kopij en lening daarentegen zal één (one) zijn. In feite weerspiegelen deze cardinaliteiten specifieke bedrijfsregels waaraan op om het even welk moment voldaan moet zijn. Een kopij kan dus, over heel haar levenscyclus gezien, meerdere keren uitgele worden, maar op om het even welk tijdstip kan deze kopij tegelijk hoogstens éénmaal uitgele zijn. Achteraf worden deze cardinaliteiten/bedrijfsregels in de methodes van de objecten verwerkt als pre- en postcondities 13 (zie verder). Voor de notatie van dit diagram kan ofwel gebruik gemaakt worden van UML ofwel van de eigen notatie van MERODE. De object-eventtabel Een gebeurtenis die zich in de realiteit vooret noemt men een bedrijfsgebeurtenis ( business event ). Zo n bedrijfsgebeurtenis wordt ingebracht in het informatiesysteem en zorgt dat een methode van een object (of van meerdere objecten) wordt aangeroepen. Deze bedrijfsgebeurtenissen zijn enkel de gebeurtenissen die zich ook zouden vooren in een bedrijf zonder informatiesysteem. Het afdrukken van een overzichtslijst is dus geen bedrijfsgebeurtenis, maar een systeemgebeurtenis ( information system event ). 13 Dit zijn de voorwaarden die voldaan moeten zijn vooraleer of nadat een methode uitgevoerd wordt. Bijvoorbeeld wordt in een bibliotheek bij een nieuwe lening nagekeken of het lid het maximale aantal gelijktijdige leningen niet overschrijdt. (Dit is een voorbeeld waar de cardinaliteit nagekeken wordt.) In een bank wordt nagekeken of het sal van een rekening niet te laag zakt nadat er geld afgehaald wordt.

33 25 De OET is een tabel waar in de cellen aangeduid wordt of objecten van het type dat beschouwd wordt in de kolom kunnen deelnemen aan gebeurtenissen van het type beschouwd in de rij. (Enkel bedrijfsgebeurtenissen worden in de tabel opgenomen.) Ook het soort deelname wordt in de tabel aangeduid. Een C (Creatie - Create) wijst erop dat een nieuw object van dit type gecreëerd zal worden, een M (Modificatie - Modify) duidt aan dat de informatie over een object zal gewijzigd worden en een E (Einde - End) tenslotte geeft aan dat deze gebeurtenis de levenscyclus van dit object zal beëindigen. Figuur 7: Object-eventtabel bibliotheekvoorbeeld 14 Aangezien zowel het bestaansafhankelijkheidsdiagram als de object-eventtabel duale weergaven zijn van hetzelfde deel van de werkelijkheid, moeten deze in overeenstemming zijn met elkaar. Om hiervoor te zorgen, heeft MERODE enkele regels ontwikkeld: - Voor elk object in het EDG moet een kolom aanwezig zijn in de OET (en vice versa). - Een master object moet deelnemen aan alle gebeurtenissen waaraan één van zijn afhankelijke objecten deelneemt ( propagation rule (verspreidingsregel)). Wanneer een bestaansafhankelijk object betrokken is in een gebeurtenis, heeft dit immers 14 SNOECK M., DEDENE G., VERHELST M. en DEPUYDT A., 1998, Object-oriented enterprise modeling with MERODE, Leuven University Press, p 34

34 26 automatisch een effect op het master object. Het alfabet 15 van een bestaansafhankelijk object is dus altijd een deelverzameling van het alfabet van het master object. Bijvoorbeeld: wanneer een LENING beëindigd wordt, heeft dit automatisch een effect op zowel LID als KOPIJ. Het lid kan nu immers een item extra ontlenen (in de veronderstelling dat er maximaal een bepaald aantal items tegelijk kan gele worden) en de kopij bevindt zich weer in het rek, klaar om opnieuw ontle te worden. - Wanneer zich in de kolom van een bestaansafhankelijk object een C bevindt bij een bepaalde gebeurtenis, moet zich in de kolom van het master object een C of een M bevinden. Staat er een M bij het bestaansafhankelijk object, dan moet dit bij het master object eveneens het geval zijn. Bevindt er zich tenslotte een E in de kolom van het bestaansafhankelijke object, dan moet er zich bij de master een M of een E bevinden. Deze drieledige regel heet de type of involvement rule (de soort-betrokkenheidregel). Samen met de propagation rule zorgt deze ervoor dat de levenscyclus van het bestaansafhankelijke object een omvat is or de levenscyclus van het master object (cfr. Figuur 5 (p 23)). - Wanneer twee objecten twee of meer gebeurtenissen delen, moeten deze gemeenschappelijke gebeurtenissen tot het alfabet van een derde object behoren, dat bestaansafhankelijk is van deze twee objecten ( contract rule (contractregel)). Wanneer objecten immers twee of meer gebeurtenissen delen, waarvan er minstens één een Creatie inhoudt en minstens één een Einde, wijst er immers op dat er een relatie bestaat tussen deze objecten. Deze relatie wordt dan gemodelleerd or een nieuw bestaansafhankelijk object. Bijvoorbeeld: in de bovenstaande object-eventtabel delen de objecten LID en KOPIJ de gebeurtenissen ontlenen, verlengen, terugbrengen en verliezen. Deze gebeurtenissen werden ondergebracht bij het object LENING. 15 Het alfabet van een object is de verzameling bedrijfsgebeurtenissen waaraan dit object deel kan nemen.

35 27 De volgordediagrammen Elk volgordediagram geeft de mogelijke levenscycli van een type object uit de EDG. Voor elk type object is er dus zo n volgordediagram. Om deze diagrammen te modelleren, kunnen verschille notatiemethodes worden toegepast: JSD-diagrams, wiskundige uitdrukkingen ontle aan een procesalgebra en finite state machines. Figuur 8: Finite State Machine voor KOPIJ van het bibliotheekvoorbeeld Net zoals de cardinaliteiten (in het EDG), geven de levenscycli bedrijfsregels weer, ze bepalen de beperkingen die aan de deelnames van objecten in gebeurtenissen worden opgelegd. Gebeurtenissen mogen zich immers niet zomaar in om het even welke volgorde afspelen. (Merk op dat de eerste volgordebeperking al in de OET wordt opgelegd: vooraleer een Modificatie of een einde kan optreden moet eerst een Creatie plaatsvinden en een Einde zal steeds de laatste gebeurtenis zijn die zich kan vooren.) Aan de volge regels moet voldaan zijn voor volgordediagrammen, opdat ze consistent zouden zijn met de EDG en de OET: - De levenscyclus van een object moet alle en enkel die gebeurtenissen bevatten, waarvoor zich in de kolom van dit object in de OET een C, M of E bevindt. Elke gebeurtenis die zich dus in het alfabet van dit object bevindt, moeten we dus terugvinden in de levenscyclus. ( alphabet rule (alfabetregel)) - Elk object heeft minstens een standaard levenscyclus die bestaat uit een Creatie, eventuele Modificaties en een Einde. Deze standaardvolgorde moet gerespecteerd blijven. ( default lifecycle rule standaard levenscyclusregel)

36 28 - De levenscyclus van een bestaansafhankelijk object moet altijd extra beperkingen opleggen aan de levenscyclus van zijn master object. ( restriction rule (beperkingenregel)) Ook hier worden de hoger opgelegde beperkingen naderhand verwerkt in de methodes van de verschille objecten aan de hand van pre- en postcondities De functionaliteitslaag Informatieobjecten Eerst en vooral moet opgemerkt worden dat het niet noodzakelijk zo is dat alle informatie, nodig om de gewenste functionaliteit aan te bieden, aanwezig is in de enterprise objects. Het kan nodig zijn om zogenaamde informatieobjecten (information objects) te definiëren. Deze objecten slaan de informatie die specifiek nodig is voor de functionality layer op. Ze zijn bovien altijd bestaansafhankelijk van de objecten uit de enterprise layer. Verder worden ze volkomen gelijk behandeld: ze worden ook opgenomen in de OET, ze hebben een levenscyclus met create, eventueel modify events en events, Er is één uitzondering: de types informatieobjecten die business events registreren hebben geen events of modify events. Ze worden gecreëerd bij het optreden van een bepaalde business event, maar deze objecten ondergaan verder geen wijzigingen meer. De types informatieobjecten die information system events registreren hebben dus wel een gewone levenscyclus. Een voorbeeld verduidelijkt wellicht veel. Beschouwen we het voorbeeld van een bank. De informatiemogelijkheid om uittreksels af te drukken kan niet zomaar uitgewerkt worden zonder extra gegevens op te slaan. Hiervoor hebben we twee informatieobjecten nodig: enerzijds het type BEWEGING, dat alle bewegingen op de rekening registreert (dit is niet vervat in het objecttype REKENING, hier wordt enkel het sal bijgehouden, niet de bewegingen), en anderzijds het type UITTREKSEL. In dit laatste type worden het tijdstip waarop het vorige uittreksel werd afgedrukt, het sal van de rekening op dit tijdstip en het moment waarop het volge uittreksel werd afgedrukt opgeslagen. Het objecttype BEWEGING is een voorbeeld van een type informatieobject dat business events registreert. Wanneer de klant geld stort op zijn rekening of geld afhaalt, wordt telkens

37 29 een object BEWEGING gecreëerd waarin het tijdstip en het bedrag (positief of negatief) opgeslagen worden. Eens dit object gecreëerd is, zal het nooit meer gewijzigd worden. De levenscyclus eindigt als het ware op hetzelfde moment als hij begon. Het type UITTREKSEL daarentegen registreert information system events, meerbepaald het afdrukken van uittreksels. Dit is een gebeurtenis die enkel plaatsvindt omdat met een computersysteem gewerkt wordt. Bij het afdrukken van een uittreksel wordt de levenscyclus van het vorige uittreksel beëindigd en wordt een nieuw object UITTREKSEL gecreëerd. Dergelijke objecten hebben dus een normale levenscyclus. Input en output subsysteem Voor elke functie wordt een service specification diagram getek. Hierin wordt aangeduid wat het triggering event is, waar toestandsvectoren geïnspecteerd worden, welke events naar de enterprise layer zullen uitgezonden worden en waar inputfuncties gebruik maken van outputfuncties. Om dit laatste te verduidelijken is een voorbeeld waarschijnlijk handig. Veronderstel het geval van een bank die gewaarschuwd wil worden van zodra het sal op de rekening van haar klanten onder een bepaald bedrag zakt. In dit geval zal een inputfunctie nodig zijn die gebruik maakt van een outputfunctie. Het afhalen van geld van een rekening zal via een inputfunctie geregistreerd worden, het nieuwe sal zal berek worden en dit sal zal vergeleken worden met de limiet die or het management is bepaald. Wanneer het bedrag op de rekening onder deze limiet zakt, zal een bericht gestuurd worden naar een outputfunctie die dan een boodschap stuurt naar het management. In deze diagrammen wordt enkel opgenomen waar inspecties nodig zijn en waar events zullen gestuurd worden. Voor outputfuncties kan het immers variëren welke inspecties nodig zijn, voor inputfuncties is het mogelijk dat hetzelfde event naar verschille enterprise objects tegelijk gestuurd moet worden. Bovien wordt waar state vector inspecties nodig zijn enkel het beginpunt van het opzoekingwerk weergegeven. Het kan in het voorbeeld van een bibliotheek bijvoorbeeld handig zijn een lijst af te drukken van een bepaald lid met zijn huidige ontleningen. Hiervoor moeten zowel de toestandsvectoren van LID (opzoeken van de naam die bij het lidnummer hoort), LENING en BOEK geconsulteerd worden. Hier wordt in het diagram maar één toestandsinspectie weergegeven. De reden hiervoor is tweeledig. Ten eerste zou het aangeven

38 30 van alle toestandsinspecties de figuur overladen. Ten tweede hangt het uiteindelijke aantal inspecties sterk af van de methode van implementeren. Wanneer in een autoverhuurbedrijf een klant bij elke vijfde auto die hij huurt een brief met een kortingsbon toegestuurd krijgt, kan dit aantal gehuurde wagens op verschille manieren bijgehouden worden. Dit kan bijvoorbeeld rechtstreeks bijgehouden worden or een tellerattribuut in het object KLANT of het kan telkens opnieuw geteld worden aan de hand van het aantal objecten van het type CONTRACT waarin de betreffe klant betrokken is. Figuur 9: Service Specification Diagram voor een inputfunctie De visie van MERODE is dat objecten niet weten waar de boodschappen die ze uitsturen terechtkomen. Bij de implementatie kan dit bijvoorbeeld opgelost worden or het introduceren van een event handler. Dit is een object waarin opgeslagen is welke objecten in welke events participeren. Bovien bekijkt deze event handler de pre- en postcondities waaraan moet voldaan zijn vooraleer de methode mag uitgevoerd worden De navigatielaag Zoals hoger vermeld bestaat er binnen MERODE geen formele uitwerking voor de navigatielaag van het conceptuele model. Voor deze sectie maken we gebruik van OOWS (Object Oriented Web Solutions), een uitbreiding van OO-Method, speciaal gecreëerd voor webapplicaties.

39 31 Net zoals MERODE gaat OO-Method uit van een drieledig model. - Een structureel model dat de klassen (plus de operaties op deze klassen en de attributen) en hun relaties bevat. Dit structureel model is gelijkaardig aan het geheel van de EDG en de OET. - Een dynamisch model dat de geldige levenscycli van de bedrijfsobjecten modelleert. - Een functioneel model dat vergelijkbaar is met de ISS-laag van MERODE. De basisstructuur van OO-Method is dus gelijkaardig aan deze van MERODE, het gebruik van OOWS zal dus geen problemen opleveren. Hoe deze OO-Methodmodellen opgesteld worden valt echter buiten het bereik van dit werk. Enkel het opstellen van een navigatiemodel met OOWS is relevant. Bij het uitwerken van een navigatiemodel zijn drie zaken van belang. Eerst worden de verschille klassen van gebruikers opgesteld, daarna wordt het eigenlijke navigatiemodel uitgewerkt en tenslotte kunnen er geavanceerde zoekmechanismen gebruikt worden. Naast de pure navigatie, wordt in OOWS ook aandacht besteedt aan specifieke presentatieaspecten. Op deze laatste aspecten gaan we niet dieper in, ch waar het nuttig is wordt de manier van presenteren wel vermeld. Identificatie van de verschille categorieën gebruikers Vooraleer de navigatie gemodelleerd wordt, is het nodig te bekijken welke verschille soorten gebruikers met het systeem kunnen interageren. Elk van deze soorten gebruikers zal eigen privileges of beperkingen toegewezen krijgen. De toegang tot bepaalde attributen en bewerkingen zal verschillen naargelang het soort gebruiker. Men stelt deze soorten gebruikers voor in een user diagram waarbij het principe van specialisatie wordt gehanteerd: de gebruikers die zich aan de staart van de pijl bevinden hebben dezelfde eigenschappen van de gebruikers aan de pijlpunt plus enkele extra eigenschappen.

40 32 Figuur 10: User diagram voor navigatielaag In deze figuur wordt een mogelijk user diagram voor een bibliotheek voorgesteld. Hierin kan een gewone gast bijvoorbeeld wel de catalogus bekijken, maar krijgt hij niet het privilege om een boek te reserveren. Dit kan een lid dan weer wel, maar die kan op zijn beurt geen nieuw boek in de database toevoegen, daar waar een beheerder dit wel kan. De verschille types gebruikers worden in OOWS toegevoegd aan het klassediagram (het structureel model), ze worden dus ook als objecttypes beschouwd. De navigatiediagrammen Het opstellen van de navigatiediagrammen gebeurt in twee stappen. Eerst wordt de algemene structuur van de webapplicatie vastgelegd, daarna de inhoud van de verschille pagina s. De eerste stap is dus het vastleggen van de algemene structuur ( authoring-in-the-large ). Hierbij wordt een navigatiediagram opgesteld waarin duidelijk wordt hoe de structuur van de webapplicatie er zal uitzien en hoe de verschille types gebruikers kunnen navigeren. In dit diagram stelt een knoop een navigatiecontext voor; een pijl staat voor een navigatielink. Een navigatiecontext stelt een interactie-eenheid voor die een samenhange verzameling data en bewerkingen aanbiedt. In de webapplicatie zullen deze contexten de webpagina s zijn. Naargelang de manier waarop een context bereikt kan worden, worden deze omgevingen ingedeeld in twee klassen: - Verkenne navigatiecontexten ( E voor Exploration) kunnen impliciet vanuit elk knooppunt bereikt worden (via de menustructuur van de webapplicatie) en expliciet

41 33 vanuit de basis van het diagram, voorgesteld or de gebruiker. Eén van deze contexten kan als de standaardcontext ( default context ) gedefinieerd worden. Deze context wordt dan aangeduid met een H (voor Home ) in plaats van met een E. - Sequentiële navigatiecontexten ( S voor Sequence ) kunnen enkel via vooraf bepaalde navigatiepaden bereikt worden via sequentiële of contextuele links. Net zoals de omgevingen verdeeld worden in twee klassen, vinden we twee soorten links terug: - Verkenne links of niet-contextuele links (de streepjespijlen) modelleren de beslissing van een gebruiker om met een andere taak te starten. Er wordt bij het klikken op een dergelijke link geen informatie overgedragen, de gebruiker verandert enkel van context. - Sequentiële of contextuele links dragen informatie met zich mee. Ze brengen de gebruiker naar een omgeving die gerelateerd is met de omgeving vanwaar hij komt. Om dit te verduidelijken grijpen we terug naar het bibliotheekvoorbeeld. Stel dat de bibliotheek een online catalogus heeft via dewelke reservaties mogelijk zijn. In deze bibliotheek kunnen naast boeken ook cd s en cd-rom s gele worden. De gebruiker kan een overzicht van de auteurs bekijken met hun bio- en bibliografie, hij kan de boeken en de multimedia-items die zich in de bibliotheek bevinden bekijken en hij kan deze reserveren. Dit geeft een navigatiediagram dat er als volgt uitziet: Figuur 11: Navigatiediagram van een lid van de bibliotheek

42 34 Wanneer de gebruiker naar de website van de bibliotheek surft, komt hij terecht op de homepage waar niet-contextuele links naar de drie verkenne contexten aangebracht zijn. Via het menu kan hij daarna switchen tussen deze contexten, dit gebeurt ook via verkenne links. Verder kan hij vanuit de context Boeken informatie opzoeken over de auteur van een bepaald werk. Hiervoor klikt hij op een contextuele link die hem rechtstreeks naar de biografie van de auteur brengt. De reservatie van een boek of een cd verloopt ook via een sequentiële link. Er kan bijvoorbeeld een knop reserveer aangebracht zijn op de pagina van de boeken en wanneer deze geactiveerd wordt, worden de gegevens van dit boek ingevuld in een reservatieformulier op een aparte pagina (die enkel via een dergelijke knop kan bereikt worden). Voor de andere gebruikerstypes zullen gelijkaardige diagrammen opgesteld worden. Een gast zal bijvoorbeeld de sequentiële context Reservatie niet kunnen bereiken. De verdere gedetailleerde uitwerking ( authoring-in-the-small ) beschrijft hoe de webpagina s van de verschille navigatiecontexten er zullen uitzien. Hierin wordt meerbepaald nagedacht over de invulling van de subpagina s van de verschille secties. Voor elke navigatiecontext wordt uit de verzameling navigatieklassen (die in feite bestaan uit de bedrijfsobjecten) een eigenaarklasse ( manager class ) gedefinieerd: een objectklasse die als basis gebruikt wordt binnen deze context. Deze eigenaarklasse heeft dan nog complementaire klassen. Tussen deze eigenaarklasse en haar complementaire klasse liggen contextuele en niet-contextuele relaties. Een niet-contextuele relatie (gestreepte pijl) geeft geen aanleiding tot navigatie. Een dergelijke relatie betekent enkel dat er informatie wordt afgebeeld op het scherm. Een contextuele relatie (pijl met een volle lijn) daarentegen zal een sequentiële link voorstellen. Verder wordt ook vermeld welke geavanceerde zoekmogelijkheden (zie hieronder) in deze navigatiecontext opgenomen worden. Deze zoekmechanismen staan omcirkeld in onderstaande figuur.

43 35 Figuur 12: Navigationele context 'Multimedia' voor het type gebruiker 'Lid' Wat vinden we nu concreet terug in het bibliotheekvoorbeeld in de context van de multimedia-items? Voor elke CD of CD-ROM zal een pagina te bereiken zijn met daarop de informatie die hiervoor beschikbaar is: titel, jaartal van uitgifte, beschrijving, catalogusnummer en naargelang het type ook de artiest, het genre en een overzicht van de nummers ofwel de uitgever en het onderwerp. Verder is er de mogelijkheid om een index te bekijken van alle multimedia-items en om te zoeken op titel. Bij elk item zal ook de mogelijkheid bestaan om het te reserveren. Dit gebeurt or middel van een sequentiële link die verbonden wordt aan het catalogusnummer. Het activeren van deze link, brengt de gebruiker naar de context Reservaties en het catalogusnummer wordt als attribuut met deze link meegestuurd. Geavanceerde zoekmechanismen Naast de gewone navigatie via links, is het ook mogelijk specifieke informatie op te zoeken via enkele meer gevorderde mechanismen: indexen en zoekmechanismen (filters). - Een index is een lijst van de populatie van een bepaalde objectklasse. In zo n lijst komt samengevatte informatie over deze objecten, waaruit de gebruiker dan kan

44 36 kiezen over welk object hij meer informatie wenst. Twee soorten indexen worden onderscheiden: o Attribuutindexen gebruiken een deelverzameling van de attributen van de manager class (de basisklasse van een bepaalde navigatiecontext). Van de klasse BOEK kan bijvoorbeeld een index gemaakt worden van alle titels samen met hun jaar van uitgifte. o Relationele indexen gebruiken een deelverzameling van de attributen van een klasse gerelateerd met de manager class. Wanneer we in dit geval een index van de boeken in de bibliotheek zouden willen maken kunnen we dit bijvoorbeeld en via de klasse AUTEUR met de attributen voornaam en de familienaam van deze klasse. Bij de activering van een index, wordt een lijst met de attribuutwaarden van de betrokken objecten opgebouwd. Minstens één van deze attributen fungeert als link. - Ook via een filter kan een populatie orzocht worden. Eén attribuut van de manager class wordt hiervoor geselecteerd en aan de hand van de waarde die voor dit attribuut opgegeven wordt, worden de objecten uit de manager class opgehaald die aan dit criterium volen. Drie soorten filters worden onderscheiden: o Exacte filters waarbij enkel instanties van de manager class worden opgehaald die exact overeenkomen met deze waarde. o Benadere ( approximate ) filters halen de instanties op waar de zoekwaarde als een deel van de attribuutwaarde. o Filters die een bereik ( range ) definiëren. Hier wordt een minimum- en een maximumwaarde voor de gezochte attribuutwaarde opgegeven.

45 37 DEEL 3: Mapping voor gelaagde conceptuele modellen naar COSMIC-FFP Dit deel behandelt de eerste stap in de functionele omvangmeting met de COSMIC-methode: de mapping naar het generieke COSMIC softwaremodel. Eens deze stap voltooid is, is het zeker dat COSMIC kan gebruikt worden. Dan moet immers enkel nog de meetfunctie toegepast worden. Om de mapping echter consequent te laten verlopen zijn een aantal regels nodig. Als voorbeeld van een gelaagd conceptueel model wordt zoveel mogelijk MERODE gebruikt. Wanneer dit niet mogelijk is (MERODE heeft bijvoorbeeld geen navigatielaag), worden elementen uit andere modellen gebruikt. Als basis voor dit deel werd vertrokken van het werk van Poels 16. Hier worden echter verschille wijzigingen en aanvullingen voorgesteld. De belangrijkste wijzigingen zijn de aanpassing aan de recentste versie van de COSMIC Measurement Manual [4], en het verschill standpunt ten opzichte van het begrip software layer. De aanvulling op conceptueel niveau betreft enerzijds de situatie van partiële informatie en anderzijds de navigatielaag, waarvoor gebruik wordt gemaakt van het OOWS-model. 16 POELS G., 2003, Functional Size Measurement of Multi-Layer Object-Oriented Conceptual Models, Working paper, Universiteit Gent

46 38 1 Interpretatie van het begrip software layer Aangezien de interpretaties van het begrip software layer nogal verschillen in COSMIC-FFP en MERODE is het aangewezen deze verschille interpretaties vooraf toe te lichten. COSMIC definieert een softwarelaag als het resultaat van de functionele onderverdeling van de softwareomgeving zo, dat alle opgenomen functionele procestypes op een zelfde niveau van abstractie opereren. De interpretatie die aan deze definitie gegeven wordt leidt er echter toe dat de lagen binnen MERODE niet als lagen binnen COSMIC beschouwd mogen worden. De interpretatie die COSMIC geeft aan deze definitie wordt duidelijk in het voorbeeld dat gegeven wordt in de measurement manual 17 (de bijhore figuur uit deze manual werd hoger reeds ingevoerd (Figuur 2, p13)). In deze case gaat men uit van een applicatie (die op zich een laag vormt) die bestaat uit drie componenten: - graphical user interface - business rules - data services Deze drie componenten werken op hetzelfde niveau van abstractie stelt men, dus behoren ze tot dezelfde laag. Aangezien ze tot dezelfde laag de applicatielaag behoren, moeten we deze componenten dus als peer items zien. MERODE daarentegen hanteert een ander principe voor de indeling in lagen. Niet het niveau van abstractie is hier van belang, wel de mate van stabiliteit (zie hoger). De business rules zijn hierin de meest stabiele, de onderste laag; de data services vormen de ISS laag en de user interface de presentatielaag. MERODE onderscheidt dus wel een gelaagde structuur, ondanks het feit dat het niveau van abstractie hetzelfde is. Binnen MERODE worden deze componenten dus niet als peer items gezien. 17 ABRAN A., DESHARNAIS J.-M., OLIGNY S., ST-PIERRE D. en SYMONS C., 2003, COSMIC-FFP Measurement Manual (The COSMIC Implementation Guide for ISO/IEC 19761:2003), Version 2.2, The Common Software Measurement International Consortium, p 19-20

47 39 Stellen dat de visie van COSMIC incorrect is, zou te verregaand zijn, want deze visie komt overeen met hun definitie. Het is echter jammer dat er geen mogelijkheden in de measurement manual zijn opgenomen om andere modelleringmethodes te ondersteunen. Concreet zou het probleem opgelost zijn als COSMIC het concept sublagen zou toevoegen. In de rest van deze tekst wordt de definitie van COSMIC gevolgd. Lagen binnen MERODE worden dus peer items binnen COSMIC. Het resultaat van de meting zal echter licht verschill zijn. In de COSMIC-FFP Measurement Manual vinden we immers regel R-O7 ( Correspondence of Data Movements across Boundaries ) 18 terug. Deze stelt dat: a) Een entry gestuurd naar een item vanuit een peer item in dezelfde laag, stemt overeen met een exit in dit peer item. b) Een exit die vanuit een item een peer item in dezelfde laag binnenkomt, komt overeen met een entry in dit peer item. c) Een write is een databeweging naar permanente opslag. Deze overschrijdt de grens van het functioneel proces waartoe het behoort niet. Als de write gedelegeerd wordt naar een software-item in een lagere laag, dan komt deze write overeen met een entry aan de andere kant van de grens met de lagere laag. d) Een read is een databeweging vanuit de permanente opslag die de grens van het functioneel proces niet overschrijdt. Als de read echter gedelegeerd wordt naar de lagere laag, dan komt die overeen met een entry/exit-paar in de lagere laag. e) In elk van voorgaande gevallen moeten de databewegingen aan elke kant van de grens meegeteld worden voor het bepalen van de omvang van de verschille componenten. Deze regel houdt in dat elke entry een overeenkome exit moet bezitten tussen peer items, waar een read overeenstemt met een entry én een exit. Een read met een entry/exit-paar wordt dus vervangen or twee entry s en twee exits, dit geeft vier databewegingen in plaats van drie. Voor de onderste laag in de meting zal dit geen verschil uitmaken, voor de hogere lagen wel. 18 ABRAN A., DESHARNAIS J.-M., OLIGNY S., ST-PIERRE D. en SYMONS C., 2003, COSMIC-FFP Measurement Manual (The COSMIC Implementation Guide for ISO/IEC 19761:2003), Version 2.2, The Common Software Measurement International Consortium, p 46

48 40 Het strikt volgen van COSMIC geeft echter een verder interpretatieprobleem dat niet or een keuze te maken opgelost kan worden: een entry wordt verondersteld elk verzoek tot entry met zich mee te dragen. Een exit veronderstelt echter niet dat elk verzoek tot exit meegedragen wordt. Dit zal aanleiding geven tot volge situatie: een MERODE-laag, een peer item volgens COSMIC vraagt gegevens op aan een andere laag. Dit is een verzoek tot entry gezien vanuit de aanvrager en een verzoek tot exit gezien vanuit de ontvanger. Dit verzoek tot exit moet apart gerek worden (dus als een entry), maar het verzoek tot entry niet. We krijgen een situatie waarin in het aanvrage peer item één entry wordt gerek en in het ontvange peer item zowel een entry als een exit. Dit is in tegenstrijd met bovenstaande regel. In het onderstaande werk wordt dus ook het verzoek tot entry als een exit gerek bij het peer item dat dit verzoek stuurt om zo deze exits als entry s in het ontvange item te zien terugkeren. Hier moeten we dus een keuze maken tussen twee conflictere regels binnen COSMIC. Tenslotte moet nog opgemerkt worden dat MERODE toelaat dat objecten binnen éénzelfde laag communiceren (bijvoorbeeld: inputobjecten kunnen berichten sturen naar outputobjecten (zie hoger p 29). Deze input- en outputobjecten zijn ook peer items, maar dan binnen éénzelfde laag (MERODE) of binnen éénzelfde peer item (COSMIC). Dit kan spraakverwarring opleveren. De bewegingen tussen deze input- en outputobjecten zullen ook entries en exits zijn. De interpretatie van het concept layer in dit werk verschilt met het eerdere werk van Poels [19]. In dit werk werden de lagen van MERODE ook lagen binnen COSMIC. Hier is ervoor geopteerd om de opvatting van COSMIC-FFP zo strikt mogelijk te volgen.

49 41 2 Mapping voor het enterprise model In deze sectie wordt nagegaan welke regels opgesteld kunnen worden voor de meting van de enterprise layer van het MERODE-model. Eerst wordt het model in zijn geheel beschouwd, daarna wordt nagegaan welke conclusies al getrokken kunnen worden indien slechts partiële informatie beschikbaar is. 2.1 Het enterprise model Het hele enterprise model bevat zoals al eerder vermeld zowel de EDG, de OET als de sequence diagrams. Tabel 1 geeft een vergelijking tussen de COSMIC-FFP concepten en de concepten die binnen het enterprise model van MERODE terug te vinden zijn. We beschouwen dit model als een apart te bemeten peer item binnen de applicatielaag van het COSMIC model. De gevonden regels komen overeen met degene die we vinden bij Poels [19] (zoals gezegd blijft de meting van de onderste laag dezelfde), behalve de regel die betrekking heeft op de exit data movements. Tabel 1: COSMIC-FFP en business main modeling COSMIC-FFP Scope of measurement Users Persistent storage Functional process Entry Exit Read Write Enterprise-laag MERODE De enterprise-laag van het conceptuele model Objecten van de information system services layer DBMS Verzameling van class methods die opgeroepen worden or het optreden van een business event Oproepen van een class method or een business event message Sturen van de eigen identiteit van een afhankelijk object naar het master object, bij de creatie van het afhankelijke object Ophalen van enterprise object state vectors Wegschrijven van object state vectors

50 42 Enkele verduidelijkingen: - Wanneer de meting het hele conceptuele model omvat, dan mag de enterprise layer als peer item beschouwd worden binnen de applicatielaag van het COSMIC-model. - Zoals de measurement manual beschrijft, gebruiken peer items elkaar. In dit geval is de information system services layer de gebruiker van de enterprise layer. (Omgekeerd gebruikt de enterprise layer de ISS layer NIET or de specifieke visie van MERODE: zie hoger.) - Een functioneel proces wordt geactiveerd or een event (type) en eindigt wanneer het alle taken uitgevoerd heeft die vereist waren voor het betreffe event (type). We onderscheiden dus voor elk business event type een functioneel proces dat alle class methods omvat die moeten uitgevoerd worden voor dat business event. - De objects of interest waar data over verplaatst worden in de functionele processen, zijn de bedrijfsgebeurtenissen (business events) en de bedrijfsobjecten (enterprise objects). - Business event message argumenten voeren data mee van input objecten naar enterprise objecten. Deze boodschap-argumenten komen overeen met de parameters in de signatuur van de class methods die or het event aangeroepen worden. Vandaar identificeren we een entry data movement voor elke class method die or een event kan aangeroepen worden. - Hoewel, conceptueel gezien, state vector inspecties data van het software-item onder beschouwing (hier het enterprise model) naar de user (hier de service objects) voeren, onderscheiden we hiervoor toch geen exit movements. De reden hiervoor is dat deze functionaliteit pas wordt gemodelleerd in de information system services layer. Deze boodschappen worden dan ook later pas toegevoegd. Bovien is het nog niet mogelijk duidelijk te onderscheiden hoeveel exits nodig zouden zijn. Wordt een query vanuit de functionaliteitslaag bijvoorbeeld intern in de bedrijfslaag verwerkt of sturen de objecten afzonderlijk een antwoord naar deze laag en wordt daar de informatie gedestilleerd uit de verkregen gegevens? We treffen wél exits aan bij de creatie van afhankelijke objecten. Deze sturen hun identiteit naar hun master objects, zodat deze een referentie naar de afhankelijke objecten in hun toestandsvector kunnen opnemen. We tellen dus een exit data movement per master object van een afhankelijk object. Merk op dat enkel naar het rechtstreekse master object een bericht gestuurd wordt. In de method body is dit

51 43 bericht te herkennen aan de vorm ref_master.ref_depent.insert(self). Dit wil zeggen dat via de methode insert, de eigen identiteit (self) van het afhankelijk object (depent), aan de master wordt orgegeven om er als referentie ingevoegd te worden. o Opmerking: In feite maakt MERODE hier een implementatiekeuze. In een conceptueel model mag dit eigenlijk nog niet. Hoe deze identiteit orgegeven wordt of hoe de relatie tussen deze beide objecten uiteindelijk tot stand gebracht zal worden, speelt voor de modellering geen rol. MERODE voegt hier evenwel toch een specificatie in, dus wordt deze hier, om de methode getrouw te volgen, meegemeten. Ook hier wijken we af van de visie van Poels [19] en volgen we consequent het MERODE-model, ook al maakt dit model hier een implementatiekeuze. - Het ophalen van een object state vector, komt in aanmerking als read movement. Zo n read movement vindt plaats telkens wanneer of de method body of de precondities van een method, de waarde van minstens één object attribuut moeten weten. Het aantal read movements is dan ook gelijk aan het aantal object state vectors die moeten geraadpleegd worden. Aangezien elke read het verzoek tot read met zich meedraagt, moet voor dit verzoek geen databeweging gerek worden. o Opmerking: wanneer het nodig is om verschille malen dezelfde object state vector te raadplegen, wordt telkens een read movement geteld. - Telkens wanneer minstens één van de attributen van een object state vector is gewijzigd, moet deze laatste opgeslagen worden. Vandaar tellen we een write movement telkens wanneer een method body een updateopdracht bevat. o Opmerking: wanneer een methode verschille updateopdrachten bevat, wordt voor elke update een write onderscheiden.

52 44 Samenvatt geven we nog een overzicht van de regels opgesteld in deze sectie: Tabel 2: Telregels voor de bedrijfslaag van het conceptueel model Naam regel Regel C1. Regel C2. Regel C3. Regel C4. Beschrijving We tellen één entry data movement per class method die or een event kan aangeroepen worden. Bij elke methode die een afhankelijk object creëert, tellen we een exit data movement per master object. Per raadpleging van een toestandsvector van een object in de method body, tellen we een read data movement. Voor elke updateopdracht in de method body tellen we een write data movement. 2.2 Partiële informatie In de normale ontwikkelingscyclus van het conceptuele model, begint men eerst met de ontwikkeling van de EDG en de OET. Deze ontwikkeling gebeurt gelijktijdig. Nadien voegt men de sequence constraints toe. In een volge stap gaat men dan over naar het schrijven van klassediagrammen. Het is misschien nuttig eens na te gaan wat we al kunnen concluderen wanneer enkel de informatie uit de eerste stap beschikbaar is: de EDG en de OET. De functionele omvangmeting wordt immers gebruikt voor o.a. effort estimation (zie hoger p 3 e.v.). Wanneer men in een eerste fase al een min of meer betrouwbare schatting kan maken van de functionele omvang, kan men dit ook voor de latere kost voor de klant. Zo kan men reeds vroeg in de ontwikkelingscyclus bekijken of er al dan niet een trade-off nodig is tussen functionaliteit en kost. In de EDG zien we - welke business objects onderscheiden worden - welke de master objects en welke de depent objects zijn

53 45 In de OET vinden we terug - welke business events kunnen plaatsvinden - welke business objects in welke gebeurtenissen kunnen deelnemen Verder weten we ook dat elk object zeker een standaard levenscyclus bezit: eerst vindt een create event ( C ) plaats, vervolgens kan het voorvallen dat er zich modify events ( M ) vooren en tenslotte wordt de levenscyclus van een object zeker beëindigd met een event ( E ). Dit is de enige informatie die beschikbaar is. Op dit ogenblik zijn de attributen van de bedrijfsobjecten nog niet bepaald, de class methods zijn nog niet geschreven en de volgordebeperkingen, buiten deze inherent aan de standaard levenscyclus, zijn evenmin gek. De besluiten uit de vorige paragraaf moeten dus zeker aangepast worden. We kunnen immers nog niet alle read en write movements identificeren. Hiervoor zouden we de class methods nodig hebben. Toch kunnen al enkele besluiten getrokken worden op basis van de EDG en de OET alleen: - De entry movements blijven ongewijzigd. We identificeren een entry data movement voor elke class method die or een event aangeroepen kan worden. Dit is al mogelijk omdat we weten welke klassen bij welk event betrokken zijn. - Hier worden geen exit movements naar de functionaliteitslaag geïdentificeerd om dezelfde reden als in de situatie van volledige informatie. Bovien zijn op dit ogenblik de klassemethodes nog niet beschikbaar op basis waarvan we de mappingregels voor volledige informatie hebben opgesteld. De implementatiekeuze van MERODE bij de creatie van bestaansafhankelijke objecten is hier nog niet zichtbaar, dus volgen we de implementatieonafhankelijke weg or hier geen exit data movements te tellen. - Als regel voor de write data movements kunnen we het volge voorstellen: voor elke C, E of M in de OET tellen we een write data movement. Het aantal writes zal nog niet overeenkomen met het uiteindelijke aantal write movements, maar het is wel zeker dat gegevens naar het geheugen zullen geschreven worden. De reden dat we

54 46 het aantal writes nog niet exact kunnen bepalen ligt bij het feit dat de class methods nog niet gedefinieerd zijn. Daaror weten we nog niet hoeveel updates er per methode aanwezig zullen zijn. We mogen dit stellen aangezien MERODE altijd de toestand van een object als attribuut (als deel van de object state vector) opslaat. Deze toestand geeft weer in welke fase van zijn levenscyclus een object zich bevindt. (Zie ook verder p 67.) o Opmerking: Deze regel is zeker geldig binnen MERODE. Voor andere conceptuele modellen is dit niet noodzakelijk het geval. Het is immers niet noodzakelijk zo dat de toestand van een object als attribuut opgeslagen wordt. Als dit niet het geval is, mag deze regel niet toegepast worden. Het resultaat van de functionele omvangmeting zou een te hoge waarde geven. - Het onderscheiden van read data movements is in deze fase van de ontwikkeling nog iets moeilijker, maar toch zijn al enkele conclusies mogelijk. Hiervoor gaan we uit van de vraag waarom read movements nodig zijn. Dit is nodig overal waar het risico op fouten bestaat, waar regels moeten nageleefd worden. Er zijn vijf soorten regels, vijf soorten beperkingen: o Sequence constraints of volgordebeperkingen: de beperkingen die aan de deelnames van objecten in gebeurtenissen worden opgelegd. o Referentiële integriteitregels: als objecten gewijzigd worden, moeten de bestaansafhankelijke objecten eveneens aangepast worden. o Het sleutelconcept: elk object moet voor één of meerdere attributen een unieke waarde bezitten. o Attribuutbeperkingen: het sal van een rekening moet bijvoorbeeld steeds een getal zijn, een Belgische postcode heeft steeds vier cijfers, o Specifieke bedrijfsregels: de lening van een boek in een bibliotheek kan bijvoorbeeld niet meer vernieuwd worden wanneer een ander lid van de bibliotheek dat boek ondertussen heeft gereserveerd. Om te zorgen dat deze regels worden nageleefd, zijn read data movements nodig. We zien onmiddellijk dat we over de laatste drie beperkingen nog geen conclusies kunnen trekken. De object state vectors zijn nog niet opgesteld, we weten dus nog niet welke attributen er zijn, laat staan welke uniek zouden moeten zijn. De specifieke bedrijfsregels zijn op dit ogenblik evenmin gek.

55 47 De volgordebeperkingen zijn ook nog niet gespecificeerd, maar hier weten we wel dat elk object minstens een standaard levenscyclus heeft. We weten ook dat een object niet zomaar van de ene toestand naar de andere kan overgaan. Om van toestand te mogen veranderen moet het object zich in de juiste begintoestand bevinden. Dit kan nagegaan worden or een read data movement. Als eerste regel mogen we stellen dat we één read data movement tellen voor elke M en elke E in de OET. De C s in de tabel geven geen aanleiding tot read data movements aangezien zij het object in een begintoestand brengen. Er is dus geen vorige toestand. Ook de referentiële integriteitsvereiste geeft aanleiding tot een besluit rond de read data movements. Wanneer de levenscyclus van een master object beëindigd wordt, moet nagegaan worden of er geen depent objects meer met deze master verbonden zijn. Een E van een master object geeft dus bovien aanleiding tot een read data movement per bestaansafhankelijk object. Hierbij merken we op dat het vole is om enkel de directe afhankelijkheden na te kijken. Veronderstellen we een object C dat afhankelijk is van een object B en dit op zijn beurt afhankelijk is van een object A. Wanneer we de levenscyclus van A wensen te beëindigen, moeten we nakijken of de levenscycli van alle afhankelijke objecten B reeds beëindigd zijn. Is dit het geval, dan zullen de objecten C zich automatisch ook allemaal in de eindtoestand bevinden. Dit is immers nagekeken bij het beëindigen van de levenscycli van de objecten B. Bovenstaande regel moet dus enigszins geherformuleerd worden tot: Een E van een master object geeft dus bovien aanleiding tot een read data movement per rechtstreeks bestaansafhankelijk object. (Als concreet voorbeeld kunnen we Figuur 6 (p 23) nemen: TITEL is hierin object A, KOPIJ is object B en LENING object C. Wanneer we een titel uit de cataloog willen schrappen omdat de laatste kopij verkocht is, zullen er geen lope leningen meer overschieten, alle kopijen zijn immers verkocht.) Samenvatt kunnen we stellen dat we een read data movement tellen voor elke M en E in de OET, plus een read movement extra bij een E van een master object voor elk rechtstreeks bestaansafhankelijk object dat bij deze master hoort.

56 48 Tabel 3: Telregels voor de bedrijfslaag van het conceptueel model bij partiële informatie Naam regel Regel C5. Regel C6. Regel C7. Regel C8. Beschrijving We identificeren een entry data movement voor elke class method die or een event aangeroepen kan worden, dit is voor elke C, M en E die zich in de OET bevindt. Er worden nog geen exit data movements onderscheiden. Voor elke C, M en E die zich in de OET bevindt, tellen we één write data movement. We tellen een read data movement voor elke M en E in de OET, plus een read movement extra bij een E van een master object voor elk rechtstreeks bestaansafhankelijk object dat bij deze master hoort.

57 49 3 Mapping voor het information system services model Zoals hoger reeds vermeld, worden de MERODE-lagen binnen COSMIC niet als lagen, maar als peer items beschouwd. Dit zorgt ervoor dat er geen read of write data movements onderscheiden worden, maar enkel entry en exit data movements. Daarom wordt telkens de richting van de databeweging vermeld. Door deze verschille interpretatie van het begrip softwarelaag, onderscheiden we hier in tegenstelling tot Poels [19] bovien alle databewegingen. Dit is nodig ordat we hier de MERODE-lagen als gelijkwaardige items beschouwen. Daaror moet elke exit een overeenkomstige entry hebben en omgekeerd (zie hoger p38). Vooraf is het misschien nuttig om nogmaals de aandacht te vestigen op het feit dat inputobjecten en outputobjecten peer items zijn binnen deze laag. Naast de entry en exit data movements tussen de lagen, vinden hier ook binnenin de functionaliteitslaag entries en exits plaats. Tabel 4: COSMIC-FFP en information systems modeling COSMIC-FFP Information system services-laag MERODE Scope of measurement Information system services laag van het conceptuele model Users Objecten van de user interface layer Objecten van de navigatielaag Objecten van de enterprise layer Functional process Een vluchtig service object, opgeroepen or een input of output service request message, of or het optreden van een business event. Entry Input object - Oproepen van service method or een service request message vanuit hogere lagen - Confirmation/error messages vanuit de bedrijfslaag - Resultaat van state vector inspecties vanuit de bedrijfslaag

58 50 Output object Exit - Oproepen van service method or een service request message (vanuit hogere lagen) of or een business event message (gestuurd or een inputobject) - State vector inspectie van de persistente objecten in de enterprise layer Input objects - Confirmation/error message (naar user interface of navigatielaag) - Sturen van een business event message (naar bedrijfslaag en soms ook naar outputobjecten) Output objects Read - Write - - Bericht met de gevraagde informatie (naar user interface of navigatielaag) - Sturen van een information system event message (naar bedrijfslaag Enkele verduidelijkingen en Cfsu telregels staan hieronder opgesomd: - De information system services layer van MERODE is een tweede peer item binnen de applicatielaag van het COSMIC model. De visie van COSMIC is evenwel zoals reeds eerder gesteld verschill van deze van MERODE. Zo gebruikt de ISS laag de enterprise laag wel, maar omgekeerd is dit niet het geval. - De input en output objecten kunnen gezien worden als peer items binnen de ISS laag. Zo kan het orsturen van een business event message van een inputobject naar een outputobject gezien worden als een data movement. o Opmerking: Vroeger maakte MERODE expliciet onderscheid tussen inputobjecten en controleobjecten. Aangezien er geen verschil is in de functionaliteit van deze twee soorten objecten, maar enkel een verschil in het el waartoe ze gebruikt worden (een controle object wordt gebruikt or het

59 51 management), worden controleobjecten bij het modelleren in praktijk niet meer gebruikt. Ook hier maken we dus geen onderscheid. - Aangezien service objecten niet persistent zijn (deze objecten zijn vluchtig), kunnen ze geen business of information system data opslaan buiten hun levensduur. Hiervoor gebruiken ze, conceptueel gezien, de faciliteiten aangeboden or de enterprise objects. Deze benadering laat toe entry en exit data movements te identificeren naar en vanuit het enterprise model. Door de classificatie van MERODE-lagen als peer items binnen COSMIC, moeten hier echter de vroegere verzoeken tot read die niet geteld hoefden te worden, nu wel meegeteld worden als exits. Anders zouden in de bedrijfslaag entry s binnenkomen (de verzoeken tot entry vanuit de functionaliteitslaag) die geen overeenkomstige exit zouden hebben in de functionaliteitslaag. (zie hoger p38) - Wegens hun niet-persistente natuur, bieden service objects hun input- / outputfunctionaliteit or middel van meestal één enkele methode. Deze wordt opgeroepen or een service request message of (voor sommige outputobjecten) or een business event message. Om het eenvoudig te houden, maken we verder geen onderscheid tussen service objects en service methods. Zij zijn de functionele processen binnen het information system services model. - De objects of interest waarover data worden verplaatst in de functionele processen, omvatten business transactions, business events, enterprise objects, information requests, information products en information system events. - Binnen de inputobjecten kunnen we de volge data movements onderscheiden: o Vanuit en naar de user interface: Input service requests brengen data over business transactions of user information system tasks binnen de information system services laag. Vandaar tellen we een entry data movement voor elk inputobject. Eventueel worden ook confirmation/error messages gestuurd als antwoord op service requests. We volgen de COSMIC conventie en tellen één exit movement per input object dat confirmation/error messages kan sturen. (dit ongeacht hoeveel verschille boodschappen ook kunnen verzonden worden.) o Vanuit en naar de enterprise layer (ook naar de outputobjecten): Voor elk inputobject geldt dat elke state vector inspectie van de persistente objecten in de enterprise layer als één entry data movement

60 52 en als één exit data movement telt. (En niet als een read data movement, want de information system services layer en de enterprise layer zijn peer items.) Het aanvragen van gegevens betekent immers een bericht naar de bedrijfslaag, het ontvangen van deze gegevens is een bericht in de omgekeerde richting. Wanneer een query geen resultaat oplevert, zal een leeg bericht terugkeren, hiervoor moet dus geen foutmelding gerek worden. Elke business event message die or een inputobject gegenereerd wordt, wordt beschouwd als een exit data movement. (En niet als een write data movement.) Merk op dat de gebeurtenissen niet alleen or de bedrijfsobjecten verwerkt worden, maar dat het voorvallen van sommige gebeurtenissen bovien geregistreerd wordt or de informatieobjecten. Opmerking: Vanwege het event broadcasting mechanisme, wordt elke boodschap maar eenmaal geteld, om het even hoeveel objecten de boodschap ontvangen. Waar inputobjecten gebruik maken van outputobjecten, worden deze berichten dus bovien ontvangen or de outputobjecten. Toch blijft dit maar één exit data movement. Bovien kan het voorvallen dat een gebeurtenis niet verwerkt kan worden. Voor elke gebeurtenis die or een inputobject geactiveerd kan worden zal dus ofwel een foutmelding ofwel een bevestiging terugkeren. De verschille soorten bevestigingen en foutmeldingen zullen hier steeds op dezelfde manier verwerkt worden. De functionaliteitslaag fungeert hier als orgeefluik. De berichten uit de bedrijfslaag worden gewoon orgegeven aan de hogere lagen en zo aan de gebruiker. Er kunnen dus twee entry data movements gerek worden per inputobject. Eén entry voor de bevestigingen en één voor de foutmeldingen. - Binnen de output objecten kunnen we de volge data movements onderscheiden: o Vanuit en naar de user interface: Voor elk outputobject is er een entry data movement, ofwel als gevolg van een output service request message (vanuit de user interface) of als gevolg van een business event message (van een inputobject). In elk

61 53 van beide gevallen worden data van een ander software-item binnenin het functioneel outputproces gebracht. Hier tellen we geen exit data movements voor confirmation/error messages. De outputobjecten inspecteren immers louter de objecten in de bedrijfslaag en vormen de bekomen gegevens om tot nuttige output voor de gebruiker. Hier zullen geen gebeurtenissen plaatsvinden die verworpen kunnen worpen. Wél is er één exit data movement voor elk outputobject dat het orsturen van de gevraagde informatie naar de user interface voorstelt. Hierbij worden vaak de informatieobjecten gebruikt. Om na te gaan welke gegevens opgevraagd worden, is soms informatie nodig die hierin opgeslagen werd. o Vanuit en naar de enterprise layer: Binnen elk outputobject telt elke object state vector inspectie van een persistent object in de enterprise layer als een exit data movement en als één entry data movement. (En niet als een read movement.) Elke information system event message die or een output object gegenereerd wordt, telt als een exit data movement. Ook deze gebeurtenissen (hier systeemgebeurtenissen) worden vaak in informatieobjecten opgeslagen.

62 54 Tabel 5: Telregels voor de functionaliteitslaag van het conceptueel model Naam regel Regel C9. Regel C10. Regel C11. Regel C12. Regel C13. Regel C14. Regel C15. Beschrijving Voor elk input- en outputobject tellen we één entry data movement. Per inputobject dat zelf confirmation/error messages kan sturen, tellen we één exit data movement. Elke state vector inspectie or een input- of outputfunctie geldt als één entry data movement én als één exit data movement. Elke bedrijfsgebeurtenis die or een inputfunctie geactiveerd wordt, telt als één exit data movement. Voor elk inputobject tellen we twee entry data movements voor het verwerken van binnenkome bevestigingen/foutmeldingen. Elke information system event message die or een outputobject gegenereerd wordt, telt als een exit data movement. Het orgeven van de gevraagde informatie aan de user interface (output message) or een outputobject telt als één exit data movement.

63 55 4 Mapping voor de navigatielaag Tabel 6: COSMIC-FFP en navigation modeling COSMIC-FFP Navigatielaag OOWS Scope of measurement De navigatielaag van het conceptueel datamodel Users Eindgebruikers van de software (die via het internet gebruik maken van de applicatie). Objecten van de information system services-laag of objecten van de presentatielaag Functional processes Het opvullen van een webpagina, na het aanklikken van een link or de gebruiker, met de gegevens die aan de ISS-laag worden opgevraagd. Entry Vanuit de eindgebruiker Navigation request message Vanuit de ISS-laag of presentatielaag Exit - Confirmation/Error messages - Bericht met de gevraagde informatie Naar eindgebruiker - Confirmation/error message - Overzicht van de gevraagde informatie Naar ISS-laag of presentatielaag Service request message Read - Write - Elke databeweging zal veroorzaakt worden ordat een user orheen de webapplicatie wil navigeren. Dit et de gebruiker or de verschille links aan te klikken. Dan pas zal de functionaliteit van de navigatielaag ingeroepen worden. Het aanklikken van een link zal een boodschap sturen (een navigation request message ). Dit is een vluchtig object dat soms data

64 56 met zich meedraagt, maar zeker altijd de specificatie waarnaar genavigeerd moet worden. Zoals eerder gesteld worden bij een contextuele link attributen meegegeven, met een nietcontextuele link daarentegen niet. Volge regels kunnen voorgesteld worden (de term link wordt hier, tenzij anders vermeld, gebruikt voor elke vorm van navigatie: contextuele links, verkenne (niet-contextuele) links, indexen en filters.): - Databewegingen van en naar de eindgebruiker: o Het activeren van een link or een gebruiker zal telkens een entry data movement betekenen. Elke link draagt immers minstens de identiteit mee van het object waarnaar genavigeerd wordt. o Enerzijds brengt elke link output met zich mee voor de gebruiker. Dit levert een exit data movement voor elke link op. Anderzijds kan het voorvallen dat, wanneer opdrachten via de functionaliteitslaag aan de bedrijfslaag orgegeven worden, een foutmelding gegenereerd zal worden. Dit zal enkel zo zijn bij sommige contextuele links. Bij dit soort links, bijvoorbeeld voor het orgeven van een reservering van een boek met de online cataloog op de website van de bibliotheek, kan het voorvallen dat de gebeurtenis die hieror gegenereerd wordt in de diepere lagen, niet verwerkt kan worden. In dit geval moet een binnenkome foutmelding orgegeven worden aan de gebruiker. Dit geeft één exit data movement extra per contextuele link. (Niet alle contextuele links zullen foutberichten kunnen genereren, het opvragen van specifieke informatie gebeurt immers ook via contextuele links, maar als benadering lijkt dit de beste oplossing.) - Databewegingen van en naar de ISS-laag of de presentatielaag: o Een entry zal plaatsvinden telkens wanneer specifieke informatie nodig is, die (via de presentatielaag of rechtstreeks) aan de ISS-laag moet gevraagd worden. Dit zal het geval zijn voor alle soorten links. Bij al deze vormen van navigatie moeten immers data uit onderligge lagen aan de surfer gepresenteerd worden. Net zoals hoger kunnen sommige contextuele links gebeurtenissen activeren die or de bedrijfslaag niet verwerkt kunnen worden. In dit geval zal vanuit de ISS-laag een foutmelding de navigatielaag binnenkomen. Dit betekent één entry data movement per contextuele link.

65 57 Als regel kunnen we dus stellen: één entry data movement per link, plus één extra data movement per contextuele link. o Voor de exit data movements is de toepassing analoog. Elke link laat specifieke informatie uit het geheugen ophalen. De aanvraag van deze informatie, die op de één of andere manier gespecifieerd moet worden, is een exit data movement. Vandaar wordt er één exit data movement per link. Ook hier verwijzen we naar de interpretatie van het begrip software layer p38. Deze exits zijn ook weer verzoeken tot entry die geteld worden omdat de entry s in de functionaliteitslaag overeenkomstige exits in de navigatielaag moeten hebben. Tabel 7: Telregels voor de navigatielaag van het conceptueel model Naam regel Beschrijving Regel C16. Het activeren van een link or een gebruiker zal één entry data movement per link met zich meebrengen. Regel C17. Elke link zorgt voor output voor de gebruiker, dit is één exit data movement per link. Regel C18. Contextuele links kunnen te verwerpen bedrijfsgebeurtenissen veroorzaken, dit geeft één entry data movement en één exit data movement per contextuele link voor binnenkome en uitgaande foutmeldingen. Regel C19. Het aanklikken van een link genereert een vraag naar gegevens die aan de ISS-laag wordt orgegeven, dit is één exit data movement per link. Regel C20. Vanuit de ISS-laag komen de gevraagde gegevens terug, dit is één entry data movement per link. Opmerking: De term link wordt gebruikt voor elke vorm van navigatie, dus voor verkenne links, voor contextuele links, voor indexen en voor filters! (Tenzij gespecificeerd wordt.)

66 58 5 Voorbeeld: bibliotheek Deze sectie werkt een voorbeeldmapping uit. Zo wordt met concrete cijfers geïllustreerd welk resultaat een functionele omvangmeting oplevert. Als voorbeeld nemen we een eenvoudige bibliotheek. Eerst beschrijven we de functionele vereisten van het bibliotheeksysteem. Vervolgens modelleren we deze systeemvereisten met MERODE en OOWS. In de bibliotheek kunnen zowel boeken als cd s gele worden. Het lenen van boeken is gratis, voor cd s dient een halve euro betaald te worden. Van boeken mogen maximaal vijf exemplaren tegelijk gele worden. Voor cd s bedraagt dit aantal slechts drie. Een lid mag een gele item drie weken in zijn bezit houden. De mogelijkheid een lening te verlengen bestaat. Voor een verlenging van een lening van een cd hoeft niet nogmaals betaald te worden. De lening van een item kan enkel verlengd worden wanneer dit item niet gereserveerd is. De werkwijze van de bibliotheek is de volge: een lid komt binnen en passeert eerst langs een loket waar hij de items die hij in zijn bezit had teruggeeft of zijn lening vernieuwt. Vervolgens gaat hij de bibliotheek binnen, maakt zijn keuze en gaat langs een ander loket bij het buitengaan waar hij zijn nieuwe leningen laat registreren. Wanneer een lid een item, dat or een ander lid gereserveerd is, terugbrengt of probeert te verlengen, dan krijgt de loketbedie een bericht dat dit item gereserveerd is. Na de registratie van de leningen wordt een ticket afgedrukt met een overzicht van alle items die het lid op dat moment in zijn bezit heeft. Het afdrukken van zo n overzicht kan ook op verzoek van het lid gebeuren. De registratie van leningen van boeken en cd s gebeurt aan het loket op afzonderlijke schermen. Ook de catalogus van boeken is gescheiden van die van de cd s. Elke avond, voor de bibliotheek sluit, wordt automatisch de status van de leningen bekeken. Wanneer een lid een week te laat is met het terugbrengen van een item, wordt automatisch een brief afgedrukt met een verzoek dit item terug te bezorgen. Nog een week later gebeurt dit opnieuw. Een maand nadat het item teruggebracht had moeten zijn, wordt het als verloren beschouwd. De bibliotheek biedt zijn leden een catalogus aan op het internet via dewelke het mogelijk is items te reserveren. Deze reservatie is uiteraard ook mogelijk in de

67 59 bibliotheek zelf. Reservering zorgt ervoor dat het gereserveerde item voorlopig niet meer or andere leden kan gele worden. In de online catalogus kan gezocht worden op titel en op auteur artiest voor cd s. Om lange wachtlijsten te voorkomen, is het niet mogelijk om een item te reserveren dat reeds or een ander lid werd gereserveerd. Vanuit deze hoger vermelde functionele vereisten wordt het MERODE/OOWS-model opgesteld. Aan de hand van dit model kunnen we dan de functionele omvangmeting uitvoeren. Voor deze meting volgen we dezelfde stappen als in het voorgaande: eerst gaan we uit van partiële informatie, vervolgens meten we het bedrijfsmodel in zijn geheel, we breiden dit uit met het functionaliteitsmodel en tenslotte houden we ook rekening met het navigatiemodel. 5.1 Het bedrijfsmodel: partiële informatie Zoals reeds gesteld, worden eerst het bestaansafhankelijkheidsdiagram en de objecteventtabel opgesteld. Voorafgaandelijk wensen we op te merken dat voor het bestaansafhankelijkheidsdiagram andere elegantere modelleerwijzen en notaties bestaan (vb. gebruik make van de Unified Modeling Language (UML)). Het opnemen van geavanceerde modelleertechnieken zoals generalisatie en specialisatie valt echter buiten het bereik van dit werk. Figuur 13 toont het bestaansafhankelijkheidsdiagram. De objecttypes BOEK en CD bevatten de titels zoals die in de catalogus zullen voorkomen, waar de types KOPIJ_BOEK en KOPIJ_CD de fysieke exemplaren zijn die effectief in het bezit van de bibliotheek zijn. Van elke titel kunnen immers meerdere fysieke exemplaren voorkomen.

68 60 Figuur 13: Bestaansafhankelijkheidsdiagram voor de bibliotheekcase Figuur 14 geeft de object-eventtabel. In de cellen vinden we terug welke objecttypes (kolom) kunnen deelnemen aan welke gebeurtenissen (rijen). Het gebeurtenistype creëren_boek slaat op het inbrengen van een nieuwe titel in de database, daar waar de gebeurtenis aankopen_boek duidt op het exemplaar dat in het rek zal belanden. Hetzelfde geldt voor de types creëren_cd en aankopen_cd. Voor het verwijderen van boeken of CD s uit de database geldt net hetzelfde: verkopen_boek verwijdert het exemplaar dat in het rek te vinden was en wanneer geen enkel fysiek exemplaar meer aanwezig is, wordt de titel uit de catalogus geschrapt or de gebeurtenis einde_boek. Een analoog scenario geldt voor CD s. BOEK KOPIJ_BOEK LENING_BOEK RESERVERING_BOEK CD KOPIJ_CD LENING_CD RESERVERING_CD LID creëren_boek C einde_boek E aankopen_boek M C verkopen_boek M E reserveren_boek M M C M

69 61 annuleren_boek M M E M ophalen_boek M M C E M lenen_boek M M C M vernieuwen_boek M M M M terugbrengen_boek M M E M verliezen_boek M E E M creëren_cd C einde_cd E aankopen_cd M C verkopen_cd M E reserveren_cd M M C M annuleren_cd M M E M ophalen_cd M M C E M lenen_cd M M C M betalen_cd M M M M vernieuwen_cd M M M M terugbrengen_cd M M E M verliezen_cd M E E M inschrijven C veranderen_gegevens M uitschrijven E Figuur 14: Object-eventtabel voor de bibliotheekcase Wat levert een vroege meting op in verband met de functionele omvang van het systeem? - Het aantal mogelijke entry data movements was gelijk aan het aantal klassemethodes dat aangeroepen kan worden (Regel C5). Dit komt overeen met het aantal ingevulde cellen uit de tabel tellen. Dit levert ons 77 entry data movements op. - In deze vroege fase worden nog geen exit data movements onderscheiden (Regel C6), aangezien deze functionaliteit pas later met het functionaliteitsmodel wordt toegevoegd.

70 62 - Aangezien MERODE bij elke bewerking minstens de toestand van een object wegschrijft, mochten we een write data movement tellen voor elke C, M en E in de tabel (Regel C7). Dit geeft 77 write data movements. - Wat de read data movements betreft, liggen de zaken iets anders: een read data movement werd geteld voor elke M en elke E in de tabel, plus een extra read data movement bij een E van een master object voor elk rechtstreeks bestaansafhankelijk object dat bij dit master object hoort (Regel C8). We tellen 51 modify events en 15 events. De master object types zijn: BOEK, CD, KOPIJ_BOEK, KOPIJ_CD en LID. BOEK en CD hebben elk drie afhankelijke objecttypes (waarvan elk slechts één rechtstreeks afhankelijk type), KOPIJ_BOEK en KOPIJ_CD hebben elk twee rechtstreeks afhankelijke objecttypes, LID heeft er zelfs vier. De levenscyclus van een object van het type BOEK of CD kan slechts op één manier eindigen, dus één E in de tabel voor deze master objects en één rechtstreeks bestaansafhankelijk objecttype; dit geeft 2 (1 + 1) extra read data movements. De types KOPIJ_BOEK en KOPIJ_CD kunnen elk op twee manieren aan hun einde komen en ze bezitten elk twee rechtstreeks bestaansafhankelijke objecttypes. Dit levert nog eens 8 extra read data movements op. Het type LID, tenslotte, heeft één event en vier rechtstreeks bestaansafhankelijke objecttypes, dus komen hier nog 4 extra read data movements bij. Wanneer we dit optellen komen we tot een totaal van: 51 ( M ) + 15 ( E ) + 14 (extra) = 80 read data movements. In het begin van de ontwikkeling kunnen we dus reeds volge conclusie trekken in verband met de functionele omvang van het systeem: Tabel 8: Aantal Cfsu bij partiële informatie Entry data movements 77 Exit data movements 0 Read data movements 80 Write data movements 77 Totaal aantal Cfsu 234

71 Het bedrijfsmodel Na de ontwikkeling van het bestaansafhankelijkheidsdiagram en de object-eventtabel, worden de volgordebeperkingen en de klassemethodes opgesteld. Daaror zijn ook alle specifieke bedrijfsregels gespecificeerd in het model. Voor elk type object worden eerst de mogelijke levenscycli gemodelleerd. Eens deze levenscycli gek zijn, kunnen de klassemethodes gegenereerd worden. Hierin zitten alle bedrijfsregels in de vorm van pre- en postcondities verwerkt. In MERODE kunnen deze klassemethodes automatisch gegenereerd worden. Dit levert enerzijds een substantieel voordeel wat de programmeerinspanning betreft (de enige code die manueel moet toegevoegd worden, is in het grijs gemarkeerd), maar anderzijds wordt zo ook een pak overbodige code gegenereerd. Hieronder is als voorbeeld de levenscyclus opgenomen van een object LENING_CD, samen met een tabel waarin de overgangen tussen de verschille toestanden nog eens expliciet worden weergegeven. Ook de klassemethoden voor dit object zijn hieronder te vinden. De finite state machines van de andere objecten evenals hun klassemethodes zijn opgenomen als bijlage, zodat de meting van de functionele omvang hiervan gecontroleerd kan worden. Voorbeeld: het object LENING_CD Tabel 9: Toestandsovergangstabel voor LENING_CD Figuur 15: FSM LENING_CD Gebeurtenis Begintoestand Eindtoestand lenen_cd - 1 ophalen_cd - 1 betalen_cd 1 2 verlengen_cd 2 2 terugbrengen_cd 2 3 (E) verliezen_cd 2 4 (E)

72 64 Class LENING_CD Inherit -- list of ancestors Attributes -- references to master object types ref_kopij_cd: KOPIJ_CD ref_lid: LID -- references to depent object types -- state indicators state: INTEGER -- additional attributes datum_lening: DATE datum_terugbrengen: DATE Methods -- methods for atomic event types lenen_cd (Input_lid: LID, Input_kopij_CD: KOPIJ_CD) is state:=1 ref_lid:=input_lid ref_kopij_cd:=input_kopij_cd datum_lening:=today datum_terugbrengen:=datum_lening + drie_weken ref_lid.ref_lening_cd.insert(self) ref_kopij_cd.ref_lening_cd.insert(self) ophalen_cd (Input_lid: LID, Input_kopij_CD: KOPIJ_CD) is state:=1 ref_lid:=input_lid ref_kopij_cd:=input_kopij_cd datum_lening:=today datum_terugbrengen:=datum_lening + drie_weken ref_lid.ref_lening_cd.insert(self) ref_kopij_cd.ref_lening_cd.insert(self) betalen_cd is require

73 65 state=1 state:=2 vernieuwen_cd is require state=2 state:=2 datum_terugbrengen:=datum_terugbrengen + drie_weken terugbrengen_cd require state=2 state:=3 verliezen_cd is require state=2 state:=4 Op basis van deze klassemethodes kunnen we nu de meting uitvoeren. Als illustratie wordt in detail de meting op het object LENING_CD uitgewerkt, daarna worden de cijfers voor de andere objecten vermeld. Volgens Regel C1 moet een entry movement gerek worden per klassemethode die or een event kan aangeroepen worden. Bij het object LENING_CD vinden we volge methodes terug: lenen_cd, ophalen_cd, betalen_cd, vernieuwen_cd, terugbrengen_cd en verliezen_cd. Dit geeft dus 6 entry movements. Bij zijn creatie stuurt een bestaansafhankelijk object een bericht naar zijn rechtstreekse master objects om een wederzijdse relatie met deze objecten tot stand te brengen. Deze MERODEspecifieke - en zoals gezegd, niet-conceptuele opvatting, levert één exit movement op per master object, per create event van het bestaansafhankelijk object. (Regel C2) LENING_CD

74 66 is rechtstreeks afhankelijk van zowel KOPIJ_CD als van LID. Bovien heeft LENING_CD twee create events. Dit geeft 2 x 2 = 4 exit data movements. Bij de read data movements vermeldt Regel C3 dat per raadpleging van een object state vector een read data movement geteld moet worden. Deze raadplegingen vinden we in de klassemethodes terug onder de require -opdracht. Hier worden waarden van bepaalde attributen opgevraagd. Het kan zowel het opvragen van eigen attributen betreffen (herkenbaar aan de vorm attribuut=waarde ), als het opvragen van attributen van andere objecten (herkenbaar aan de vorm: ref_naam_object.attribuut=waarde ). In de klassemethode van het object LENING_CD worden echter alleen eigen attributen geraadpleegd. Dit gebeurt viermaal (de toestand (state) wordt viermaal nagekeken). Naast 6 entries, vinden we dus 4 reads terug. Wat de write data movements tenslotte betreft, vermeldt Regel C4 dat per updateopdracht een write data movement gerek wordt. In de klassemethodes vinden we de updateopdrachten terug onder Telkens wordt minstens de toestand weggeschreven. Dit geeft een totaal van 6 write data movements. Totale meting: In de volge tabel worden de totale resultaten weergegeven: Tabel 10: Aantal Cfsu van het bedrijfsmodel Object Regel C1 Regel C2 Regel C3 Regel C4 Totaal Entry Exit Read Write LID BOEK KOPIJ_BOEK LENING_BOEK RESERVERING_BOEK CD KOPIJ_CD LENING_CD RESERVERING_CD Totalen

75 Opmerking bij de metingen van de bedrijfslaag Wanneer we de resultaten van voorgaande metingen bekijken, dan valt het hoge aantal CFSU s voor een eenvoudig systeem op. (238 bij partiële informatie, 264 bij volledige informatie.) Het is nuttig om hiervoor terug te kijken naar de definitie van de objecteventtabel die hoger werd gegeven: De OET is een tabel waar in de cellen aangeduid wordt of objecten van het type dat beschouwd wordt in de kolom kunnen deelnemen aan gebeurtenissen van het type beschouwd in de rij. In deze definitie staat het woord kunnen. Dit wil zeggen dat het niet noodzakelijk is dat een object, waarbij in de OET een mogelijke deelname aan een gebeurtenis aangeduid staat, ook effectief deelneemt aan deze gebeurtenis. Concreet wil dit zeggen dat voor sommige modify events in de OET, de overeenkomstige methode leeg zal zijn. Dit zien we in de klassemethodes ettelijke keren terugkomen. Bij de klasse LID bijvoorbeeld treffen we volge methode aan voor het vernieuwen van een lening van een CD: vernieuwen_cd is require state=1 state:=1 Het valt op dat hierin niets gebeurt. Een ingeschreven lid bevindt zich altijd in toestand 1. In totaal zijn er 40 klassemethodes in dit eenvoudige voorbeeld leeg (enkel de toestand wordt gecontroleerd en enkel de eventueel nieuwe - toestand wordt weggeschreven. (Door meer details toe te voegen in de bedrijfsregels zou dit aantal wel dalen.) Dit geeft een overschatting van de functionele omvang van 120 Cfsu (elke methode moet geactiveerd kunnen worden (entry), elke keer wordt de toestand gecontroleerd (read) en opnieuw weggeschreven (write), dus drie Cfsu voor elke lege methode), of ongeveer de helft van het totale aantal Cfsu. Het is belangrijk zich te realiseren dat hier een afruil moet gemaakt worden tussen het uiteindelijke aantal lijnen code en de inspanning nodig om dit aantal lijnen code te programmeren. Doordat MERODE voorziet dat de code automatisch gegenereerd kan worden, zal het aantal Cfsu s in de meting een stuk hoger liggen or lijnen overbodige code, de inspanning nodig om de applicatie te ontwikkelen zal echter een pak lager liggen.

76 Het functionaliteitsmodel Om de dagelijkse werking van de bibliotheek te verzekeren, moeten een aantal taken uitgevoerd kunnen worden. Om de verwijzingen makkelijk te maken, worden deze taken ( t ) genummerd. - t1: Beheer klantengegevens (invoeren nieuwe klanten en wijzigen adresgegevens) - t2: Uitschrijven klanten - t3: Registratie leningen boeken (deze taak verwerkt zowel nieuwe leningen, verlengingen van leningen, als het ophalen van gereserveerde items) - t4: Registratie leningen cd s (idem als bij boeken) - t5: Verwerking terugbrengen boeken - t6: Verwerking terugbrengen cd s - t7: Verwerking verlies boeken - t8: Verwerking verlies cd s - t9: Reserveren boeken - t10: Annuleren reserveringen boeken - t11: Reserveren cd s - t12: Annuleren reserveringen cd s - t13: Inbrengen nieuwe boeken (zowel volledig nieuwe titels als nieuwe kopijen) - t14: Inbrengen nieuwe cd s (idem als bij boeken) - t15: Verwijderen boeken (zowel verwijderen van een kopij als het verwijderen van een titel uit de catalogus wanneer de laatste kopij verwijderd is) - t16: Verwijderen cd s (idem als bij boeken) Verder zijn er nog specifieke informatiebehoeften die verwerkt moeten worden. Om aan deze behoeften te volen, wordt een verzoek (request, vandaar de afkorting r (dit zijn de service request messages uit Tabel 4)) gestuurd naar een outputfunctie (soms via een inputfunctie). Sommige verzoeken worden automatisch gestuurd or een timer. Hiervoor wordt de afkorting tr gebruikt. - r1: Bekijken welke items een lid in zijn bezit heeft - r2: Lijst opstellen van alle boeken in de bibliotheek - r3: Lijst opstellen van alle cd s in de bibliotheek - r4: Rapport afdrukken van verloren boeken (voor bibliothecaris) - r5: Rapport afdrukken van verloren cd s

77 69 - tr1: Nakijken welke boeken 1 maand te laat zijn (hierna worden automatisch de boeken die na een maand nog niet binnengebracht zijn als verloren beschouwd) - tr2: Nakijken welke cd s 1 maand te laat zijn - tr3: Brieven afdrukken voor boeken die 1 week/2 weken te laat zijn - tr4: Brieven afdrukken voor cd s die 1 week/2 weken te laat zijn Voor elk van deze taken wordt een schema opgesteld met input- en outputfuncties om duidelijk te maken hoe alles verloopt. Net zoals met de klassemethodes uit de bedrijfslaag, zullen ook hier enkele voorbeelden behandeld worden. De andere figuren worden in bijlage opgenomen, zodat de meting gecontroleerd kan worden (Bijlage 2, p.1 e.v.). Voorbeeld 1: t3 Ontlenen van boeken Figuur 16: SSD voor het ontlenen van boeken Met de taak t3, wordt een inputfunctie F3 geactiveerd. Bij de taak t3 worden lidnummer en volgnummer van het boek ingegeven. De functie F3 kijkt eerst of het boek gereserveerd was or het lid. Dit gebeurt or een state vector inspectie. In de toestandsvector van het lid is immers een verwijzing aangebracht naar de reserveringen van dit lid met het attribuut ref_reservering_boek. Is dit het geval, dan zal de gebeurtenis ophalen_boek geactiveerd worden. Is dit niet het geval, dan wordt nagekeken of het gaat om een verlenging van de lening. In de toestandsvector van het lid is ook een verwijzing naar de leningen aanwezig. Was het boek voordien al or het lid ontle, dan wordt de gebeurtenis vernieuwen_boek geactiveerd. Gaat het om een volledig nieuwe lening, dan activeert de functie F3 de

78 70 gebeurtenis lenen_boek. We vermelden hierbij nogmaals dat slechts één state vector inspectie onderscheiden wordt omdat het nog niet bepaald is hoe deze inspecties geïmplementeerd zullen worden (en om de figuur niet te overladen). Opmerking: De betekenis van de symbolen in dit schema staat aangegeven in figuur 8 (bij de bespreking van de ISS-laag). Wat levert het op als we de afhandeling van deze taak t3 meten? Taak t3 activeert functie F3, een inputfunctie. - Regel C9 stelt dat per inputfunctie een entry data movement moet geteld worden, we hebben dus één entry. - Volgens Regel C10 moet een exit data movement geteld worden wanneer een inputfunctie confirmation/error messages kan sturen. Dit is het geval: ofwel zal deze functie de correcte verwerking van de lening signaleren, ofwel zal ze een foutmelding genereren (bijvoorbeeld wanneer het lid probeert de lening van het boek te verlengen, maar het boek gereserveerd is or een ander lid). Eén exit data movement wordt geteld. - Regel C11 betreft de state vector inspecties. Door de functie F3 wordt één toestandsvector geïnspecteerd, dit levert één entry data movement op en één exit data movement. - Tenslotte bekijkt Regel C12 de bedrijfsgebeurtenissen die or een inputfunctie geactiveerd worden or business event messages. Drie verschille boodschappen kunnen or deze functie gestuurd worden, dit levert drie exit data movements op. - Naast de uitgaande bevestigingen/foutmeldingen die met regel C10 geteld werden, moeten ook de inkome bevestigingen/foutmeldingen meegerek worden. Regel C13 stelt dat voor een inputfunctie twee entry data movements gerek moeten worden. Eén voor inkome bevestigingen, één voor binnenkome foutmeldingen. Alles samen hebben we voor de functie F3 dus 4 entry data movements en 5 exit data movements.

79 71 Voorbeeld 2: request 1 Welke items heeft een lid in zijn bezit? Figuur 17: SSD voor het afdrukken van overzichten van leningen Telkens wanneer een lening geregistreerd wordt het kan zowel een nieuwe lening als een verlenging betreffen sturen de functies F3 en F4 business event messages die ook bij functie F17 terechtkomen. Deze outputfunctie gaat via een state vector inspectie na welke items het lid op dat moment in zijn bezit heeft. Ook hier wordt enkel het beginpunt van de inspectie van de toestandsvectoren gegeven. Behalve or de genoemde bedrijfsgebeurtenissen, kan F17 ook or een gewoon verzoek geactiveerd worden. Hoeveel Cfsu levert het uitvoeren van deze taak op? - Regel C9 leert, dat per outputfunctie een entry data movement moet gerek worden. Dit levert onmiddellijk één entry data movement op. Merk op dat, hoewel F17 or zes verschille gebeurtenissen en één verzoek geactiveerd kan worden, er toch maar één entry gerek wordt. Deze berichten zijn immers allemaal van hetzelfde type voor de outputfunctie, ze worden op dezelfde manier verwerkt. - Bij regel C11 worden de inspecties van toestandsvectoren behandeld. Functie F17 onderzoekt de status van de leningen, dit is zo n inspectie en betekent dus één entry data movement en één exit data movement. - Information system event messages (regel C14) worden or outputfunctie F17 niet gestuurd. Aangezien elke avond de huidige datum vergeleken wordt met de datum waarop de lening afloopt, moet niet bijgehouden worden wanneer de laatste controle was. Er wordt puur een verschil gemaakt tussen twee data.

80 72 - Als laatste bekijken we regel C15. Dit levert nog één exit data movement op voor het bericht dat functie F17 stuurt naar de user interface, namelijk voor het afdrukken van de brieven. In totaal levert de meting van deze taak 2 entry data movements en 2 exit data movements op. Totale meting: De resultaten staan, om overzichtelijk te zijn, geord per taak en per telregel, zodat de meting makkelijk na te rekenen is. Om eenvormig te tellen, gaan we uit van de veronderstelling dat elke inputfunctie een bevestiging stuurt wanneer de inbreng/aanpassing van gegevens succesvol verlopen is. Welke functies foutmeldingen kunnen veroorzaken, is op dit moment minder duidelijk, maar wanneer we de bevestigingen tellen, heeft dit geen invloed op de meting. Tabel 11: aantal Cfsu van het functionaliteitsmodel Taak Regel C9 Regel C10 Regel C11 Regel C12 Regel C13 Regel C14 Regel (E) (X) (E) (X) (X) (E) (X) (X) C15 Totaal entries Totaal exits Totaal Cfsu t t t t t t t t t t t t t

81 73 t t t r r r r r tr tr tr tr Totaal Het navigatiemodel Tenslotte beschikt de bibliotheek ook over een website via dewelke de catalogus kan bekeken worden. Online kunnen de leden bovien reserveringen orgeven, zodat ze zeker zijn dat hun trip naar de bibliotheek niet voor niets is. Niet-leden kunnen enkel de catalogus bekijken. Het navigatiediagram ziet er als volgt uit: Figuur 18: navigatiediagram voor een lid van de bibliotheek Een lid kan dus de vier navigatiecontexten bereiken, voor een niet-lid zullen de sequentiële contexten (de reserveringen) onbereikbaar zijn.

82 74 De catalogus kan zowel orzocht worden op titel als op auteur of artiest. Dit gebeurt met benadere filters. Hoeveel functionaliteit biedt deze laag nu in termen van Cfsu? - De inkome berichten die de links activeren, geven volgens regel C16 elk één entry data movement. In dit voorbeeld treffen we twee verkenne links aan, twee contextuele links en vier benadere filters. Deze eerste regel levert dus 8 entry data movements op. - Regel C17 stelt dat elke link ook output voor de gebruiker biedt, we mogen dus 8 exit data movements tellen. - Contextuele links kunnen verworpen bedrijfsgebeurtenissen veroorzaken (hier kan het concreet voorvallen dat een lid een item probeert te reserveren, maar dat dit item al or iemand anders gereserveerd is). Volgens regel C18 levert dit één entry en één exit data movement op per contextuele link. Dit geeft twee entry data movements en twee exit data movements. - De navigatielaag stuurt een vraag naar gegevens naar de functionaliteitslaag. Deze verschilt naargelang de geactiveerde link. Volgens regel C19 moeten we één entry data movement tellen per link voor deze berichten. Dit geeft nog eens 8 exit data movements. - Tenslotte krijgt de navigatielaag gegevens terug vanuit de functionaliteitslaag. Regel C20 stelt dat we nog één entry data movement per link moeten rekenen. Dit geeft nog eens 8 entry data movements. Voor de navigatielaag geeft dit een totaal van 20 entry movements en evenveel exit movements, dit is dus 40 Cfsu.

83 75 DEEL 4: Van conceptueel model naar architectuurmodel 1 Weg uit de conceptuele modellering Naar een technische omvangsmaat In deze sectie verlaten we het mein van de pure conceptuele modellering. De overgang naar een architectuurmodel betekent dat er een keuze wordt gemaakt voor de implementatie. Hier kiezen we voor het werken met een event dispatcher, een object dat de verwerking van gebeurtenissen op een gecoördineerde manier et verlopen. Ook wordt bepaald welk systeemtype men voor ogen heeft: een alleenstaand systeem, of een gedistribueerd systeem dat op zijn beurt sterk of zwak gekoppeld kan zijn. Dit nieuwe model het architectuurmodel - blijft evenwel onafhankelijk van de technologie die later zal gebruikt worden om het te implementeren. Bij een alleenstaand ( standalone ) systeem staat heel de applicatie op één welbepaalde computer geïnstalleerd. Een gedistribueerd systeem laat echter toe om op meerdere machines de applicatie te gebruiken bijvoorbeeld op een netwerk of op het internet. Wanneer het systeem sterk gekoppeld of strak geïntegreerd is, is de bedrijfslaag gemeenschappelijk tussen de verschille computers, bij een zwak gekoppeld systeem is ook de bedrijfslaag gedistribueerd. Het architectuurmodel heeft dus het conceptueel model als basis. Het maakt een begin met de technische uitwerking van dit model. In de rest van dit deel zal bijgevolg nergens meer gesproken worden over functionele vereisten. Deze zijn immers volledig verwerkt in het conceptueel model. Dit et de vraag rijzen of we nog te maken hebben met functionele omvangmeting.

84 76 Wanneer we de ISO/IEC-norm voor functionele omvang bekijken, lezen we daar het volge 19 : A FSM Method should be as indepent as possible of particular software development methods or technologies. Het architectuurmodel volet duidelijk niet aan deze vereiste. Er worden immers duidelijk keuzes gemaakt richting technologie (bijv.: een alleenstaand of een gedistribueerd systeem?). Wanneer we bijgevolg de omvang van het architectuurmodel willen meten, in dit geval met COSMIC, zal dit niet langer een maat zijn voor de functionele omvang van dit systeem (waar de meting van het conceptuele MERODE-model dit wel was). Dit wil niet zeggen dat we COSMIC niet langer mogen toepassen, maar wel dat we hier te maken hebben met een uitbreiding van COSMIC-FFP. Dit zal dan ook tot uiting moeten komen in de rapportering van de meting. Een meer diepgaande bespreking hierover vindt u in het deel over de rapportering (DEEL 5 p. 93 e.v.). 2 Architectuurmodel van de bedrijfslaag In deze sectie maken we dus de overgang van het conceptueel model naar het architectuurmodel. Het model dat hier besproken wordt, is de technische uitwerking van de bedrijfslaag uit het conceptueel model. De uitleg rond dit model kan gevonden worden in Een Modelgedreven Gelaagde Architectuur voor Web-service Ontwikkeling 20. Waar in het conceptueel model nog geen interacties van de bedrijfslaag met hogere lagen verondersteld werden, is dat hier wel het geval. Daarom wordt een interface ingevoerd tussen de bedrijfslaag en de gebruikers (in een alleenstaand systeem zal dit enkel de ISS-laag zijn, in een gedistribueerd systeem komen daar afgelegen bedrijfslagen bij (zie hieronder)) van deze 19 ISO/IEC :1998 p2 20 LEMAHIEU W., SNOECK M., MICHIELS C., GOETHALS F., DEDENE G. en VANDENBULCKE J., 2003, Een Modelgedreven Gelaagde Architectuur voor Web-service Ontwikkeling, in: Beleidsinformatica Tijdschrift, 01/2003 (volume 29)

85 77 laag. Om na te gaan hoe deze interface eruit ziet, bekijken we eerst de soorten interacties die tussen de bedrijfslaag en hogere lagen kunnen optreden. In een gebeurtenis- of eventgerichte omgeving vinden we twee types interacties tussen de objecten in de bedrijfslaag en componenten uit hogere lagen (de ISS-laag, de navigatielaag, ) terug: - Attribuutinspecties: objecten uit hogere lagen lezen informatie uit de bedrijfsobjecten. - Event broadcasting: bedrijfsgebeurtenissen dienen verwerkt te worden en dus eerst vanuit hogere lagen aan de bedrijfsobjecten meegedeeld te worden. Hierbij zal zeker naar de bedrijfsobjecten geschreven worden. Om dit gecoördineerd te laten verlopen wordt gebruik gemaakt van een event dispatcher. Om tot een architectuurmodel voor de bedrijfslaag te komen wordt de oorspronkelijke bedrijfslaag aangevuld, verrijkt, met twee nieuwe lagen zodat het architectuurmodel drie lagen bevat: - De bedrijfslaag, de onderste laag, bevat zowel de lokale bedrijfsobjecten als strookobjecten (zie verder) voor de afgelegen bedrijfsobjecten. - De gebeurtenislaag, de tweede laag, bevat de event dispatcher die zorgt voor de gecoördineerde afhandeling van bedrijfsgebeurtenissen. Dit object weet welke objecten deelnemen in welke gebeurtenissen. Het stuurt een event notificatie naar elk object dat bij een gebeurtenis betrokken is. In deze notificatie zijn de gegevens opgenomen die het object nodig heeft om de gebeurtenis te kunnen afhandelen. - De interfacelaag, de bovenste laag, bevat twee elementen: de query interface en de event notificatie interface. De eerste staat in voor de attribuutinspecties, het lezen van de verschille bedrijfsobjecten, het verwerken van de gegevens die de bedrijfsobjecten terugsturen tot een samenhang queryresultaat, De tweede verzorgt dan weer het orsturen van de gebeurtenissen (event broadcasting).

86 78 Figuur 19: Architectuurmodel van de bedrijfslaag 21 Zoals reeds hoger werd vermeld, is het voor zwak gekoppelde systemen nodig dat strookobjecten aan de lokale bedrijfslaag toegevoegd worden. Het is immers zo dat een applicatie enkel de interface van een andere applicatie kan onderscheiden, ch niet de implementatiedetails. De event dispatcher implementeert immers enkel de lokale OET. Een strookobject lost dit probleem op, dit object vertegenwoordigt de afgelegen dienst. Wanneer er zich een bedrijfsgebeurtenis vooret waarin een afgelegen dienst betrokken is, wordt de methode van het strookobject geactiveerd or de event dispatcher en op zijn beurt stuurt het strookobject een bericht naar de afgelegen dienst. Daar wordt de gebeurtenis verder verwerkt. Om de werking van de strookobjecten te verduidelijken volgt hierna een concreet voorbeeld. Veronderstel de situatie van een kleinhandelszaak die een webservice aanbiedt aan haar klanten om online te bestellen. Wanneer een klant een bestelling plaatst, kan deze bestelling rechtstreeks orgegeven worden aan de leverancier(s) van de kleinhandel en ook bij de klant kan deze bestelling geregistreerd worden. In de bedrijfslaag van de handelaar worden dus strookobjecten toegevoegd voor elke leverancier en voor de klanten. Het strookobject van de leveranciers stuurt dan de bestelling bijvoorbeeld or naar het bestellingsysteem van deze 21 LEMAHIEU W., SNOECK M., MICHIELS C., GOETHALS F., DEDENE G. en VANDENBULCKE J., 2003, Een Modelgedreven Gelaagde Architectuur voor Web-service Ontwikkeling, in: Beleidsinformatica Tijdschrift, 01/2003 (volume 29), blz. 12