FPA toegepast bij UML/Use Cases

Transcriptie

1 FPA toegepast bij UML/Use Cases Versie PUBLICATIE VAN DE NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE

2 ISBN: Copyright NESMA Alle rechten voorbehouden. NEderlandse Software Metrieken Gebruikers Associatie (NESMA). Niets uit deze uitgave mag worden verveelvoudigd of openbaar gemaakt, in enige vorm of op enige wijze, zonder voorafgaande schriftelijke toestemming van de NESMA. Na toestemming dient de titelpagina van het document waarin gedeelte(n) uit deze uitgave zijn overgenomen, de volgende bepaling te bevatten: Deze uitgave bevat materiaal dat afkomstig is uit - FPA toegepast bij UML/Use Cases. Deze openbaarmaking geschiedt met toestemming van de NESMA. 2

3 Inhoud 1 Inleiding Gevolgd proces Doelgroep Leeswijzer Disclaimer Gebruikte literatuur UML en de uitgangspunten voor FPA Inleiding Eisen aan een specificatie UML diagrammen en FPA Use Case model Inleiding Use Case diagrammen Use Case en Actor Use Case-beschrijving Granulariteit van Use Cases Relaties tussen Use Cases Include relaties Extend relaties Storyboards Toepassing FPA-richtlijnen Class-model Inleiding Class-model Association Aggregation Composition Generalization Voorbereidende stappen bij het tellen Gedrag en persistentie Stereotypes Toepassing FPA-richtlijnen Stel de FPA-tabellen vast Sleutel-sleutel entiteiten zonder attributen Sleutel-sleutel entiteiten met attributen Bestaanszelfstandigheid en afhankelijkheid bij instance-relaties Begrippenlijst

4 1 Inleiding FPA is opgezet en ontwikkeld onafhankelijk van ontwerpmethoden en het is iedere keer weer de uitdaging FPA toe te passen in nieuwe ontwerpomgevingen. Dit document wil hierbij helpen en een vertaalslag bieden voor de begrippen die gehanteerd worden bij informatiesystemen die met behulp van UML (Unified Modeling Language) zijn gemodelleerd en gedocumenteerd naar de begrippen die bij FPA gehanteerd worden. In de praktijk zal er voor een ervaren teller van functiepunten weinig verschil zijn tussen het tellen van de functies in een klassieke omgeving en van de functies bij UML. Het grootste verschil is de terminologie, opbouw en de samenhang van de documentatie. Deze gids volgt de FPA-richtlijnen van de door de ISO gecertificeerde FPA-methoden, zoals gedocumenteerd in [NESMA, IFPUG] en is bij beide methoden te gebruiken. De in deze gids vastgelegde richtlijn richt zich voornamelijk op het Class-model en het Use Case model en toepassing van de FPA telrichtlijnen hierbij. 1.1 Gevolgd proces De NESMA heeft een SIG (Special Interest Group) samengesteld met als opdracht: het samenstellen van een document op basis waarvan de vertaalslag van Use Case/UML documentatie en de daarin gebruikte terminologie naar FPA (conform NESMA versie 2.2) gemaakt kan worden. Er wordt uitgegaan van een globale functiepuntentelling. In deze richtlijn wordt met name ingegaan op het vaststellen van de gebruikersfuncties (gegevensverzamelingen en gebruikerstransacties) op basis waarvan eenvoudig een globale functiepuntentelling uitgevoerd kan worden. Dit laat onverlet dat op basis hiervan ook een indicatieve c.q. een gedetailleerde functiepuntentelling vastgesteld kan worden, mits de beschikbare documentatie dit detailniveau in zich heeft. De volgende personen hebben voor de totstandkoming van dit document gezorgd: Peter Bink, Capgemini Hans van den Brink, Centric Information Engineering Robert Louwers, ABN AMRO William Maas, Info Support Jolijn Onvlee, Onvlee Opleidingen & Advies Rogier Oudshoorn, Capgemini Richard Sweer, Finidy Wim Visser, Capgemini Concept versies zijn in een tweetal ronden gereviewd door het bestuur van de NESMA, de leden van de werkgroep Telrichtlijnen en daarnaast door FPA- en UML experts van de volgende bedrijven: Getronics Pink Roccade, Sogeti, Equens, ABN AMRO, QSM, Atos Origin en CapGemini. Een volgende opdracht zal het uitwerken van een case study zijn. 4

5 1.2 Doelgroep Bij het opstellen van dit document is er vanuit gegaan dat de lezer bekend is met zowel FPA en de daarbij behorende begrippen als met UML. Men hoeft geen expert op deze gebieden te zijn, maar enige basiskennis is wel een vereiste. Het document is bedoeld voor FP analisten die geconfronteerd worden met een ontwerp van een informatiesysteem dat gedocumenteerd is met behulp van UML. Daarom wordt uitgelegd op basis van welke modellen je FPA kunt uitvoeren en een korte uitleg gegeven met betrekking tot de UML begrippen. In dit document wordt geen uitleg van de FPA begrippen gegeven; hiervoor wordt verwezen naar de FPA-richtlijnen. 1.3 Leeswijzer Allereerst wordt in hoofdstuk 2 aangegeven welke UML producten gebruikt kunnen worden bij het vaststellen van het aantal functiepunten. Hoofdstuk 3 gaat in op het Use Case model en hoe men op basis hiervan de gebruikerstransacties kan vaststellen (paragraaf 3.8). In hoofdstuk 4 wordt eerst een uitleg van het Class-model gegeven en vervolgens hoe de richtlijnen voor gegevensverzamelingen hierop toepasbaar zijn (paragraaf 4.4). Hoofdstuk 5 geeft een begrippenlijst van de in dit document gehanteerde begrippen. In dit document hebben we er voor gekozen de Engelstalige UML begrippen (beginnend met een hoofdletter) te gebruiken, omdat deze meestal breder bekend zijn dan de Nederlandse vertalingen. In de begrippenlijst zijn de Nederlandse vertalingen opgenomen. 1.4 Disclaimer De toepassing van FPA beschreven in deze publicatie is bij diverse bedrijven en projecten in de praktijk gebracht. De NESMA kan niet claimen dat deze methode wetenschappelijk getoetst is. Aanvullend onderzoek en praktisch gebruik zijn nodig om de validiteit aan te tonen. Met deze gids FPA toegepast bij UML/Use Cases wil de NESMA de consistente toepassing van FPA in andere omgevingen bevorderen. De NESMA is niet verantwoordelijk voor het gebruik van deze richtlijn, noch voor de resultaten verkregen door de toepassing van de richtlijn. De NESMA stelt commentaar en aanvullingen voor verdere verbetering zeer op prijs. Dit kan aan de NESMA worden doorgegeven (office@nesma.nl). 1.5 Gebruikte literatuur Thomas Fetcke, Alain Abran, Tho Hau-Nguyen, Mapping the OO-Jacobson approach into Function Point Analysis, 1998 Alistair CockBurn, Writing Effective Use Cases, Addison-Wesley, M. Fowler, UML Distilled / A Brief Guide to the Standard Object Modeling Language, Philippe Kruchten, The Rational Unified Process - An Introduction,2nd Ed., Addison- Wesley, NESMA, Definities en telrichtlijnen voor de toepassing van Functiepuntanalyse, versie 2.2, 2004, [NESMA]. Oudshoorn, Rogier C.A., Application of Functional Size Measurement on Requirements in UML (afstudeerscriptie Universiteit Twente). Dit document is voor NESMA leden te downloaden via de NESMA website ( IFPUG, Function Point Counting Practices Manual, release 4.2, 2004 [IFPUG] NESMA, FPA i : Toepassing van functiepuntanalyse in de eerste fasen van systeemontwikkeling. Een handboek voor de praktijk, versie 2.0., 2003 UML 2.0 Superstructure 5

6 2 UML en de uitgangspunten voor FPA 2.1 Inleiding In dit hoofdstuk wordt, op basis van de eisen die aan de specificaties worden gesteld met betrekking tot een bepaalde telling, een match gemaakt met de binnen UML beschikbare diagrammen. Bij functiepuntanalyse wordt de hoeveelheid informatieverwerking die een informatiesysteem aan de gebruiker biedt gemeten en uitgedrukt in de eenheid functiepunt. De wijze waarop een informatiesysteem technisch gerealiseerd wordt of is, dient buiten beschouwing te blijven. Het gaat immers om het logische gezichtspunt. De gebruikte technologie mag geen invloed hebben op het vastgestelde aantal functiepunten van een informatiesysteem. Dat laatste geldt ook ten aanzien van de toegepaste ontwerpmethode en technieken. Ook de toepassing van UML als afbeeldingwijze heeft geen invloed op de te realiseren functionaliteit van het informatiesysteem, althans vanuit de gebruiker gezien. De huidige FPA-richtlijnen worden meestal geplaatst binnen het kader van een klassiek lineair waterval ontwikkelscenario (bijvoorbeeld SDM), maar zijn ook binnen moderne iteratieve methoden zoals RUP (Rational Unified Process) toepasbaar. Immers, ook in moderne iteratieve ontwikkelomgevingen zal men geïnteresseerd zijn in het bepalen van productiviteit en het vooraf kunnen schatten van de kosten en inspanning van projecten. Het verschil zit met name in het moment of de momenten in het ontwikkeltraject waarop het aantal functiepunten kan worden bepaald. In een klassiek traject kan het aantal functiepunten worden vastgesteld op basis van een goedgekeurd functioneel ontwerp. In een iteratief traject ligt dit anders. Een informatiesysteem wordt iteratief tot stand gebracht en dat betekent dat ook het bepalen van het aantal functiepunten iteratief zal gebeuren. Het is goed denkbaar dat ergens in het traject een deel van de functiepunten gedetailleerd kan worden vastgesteld en voor dat deel ook min of meer definitief is, terwijl voor andere (in de komende iteraties verder te specificeren en te ontwikkelen) delen van het informatiesysteem niet meer dan een globale of zelfs indicatieve telling haalbaar is. RUP valt overigens verder buiten de scope van deze richtlijn, die ingaat op de afbeeldingwijze UML. 2.2 Eisen aan een specificatie Volgens de FPA-richtlijnen moeten de volgende specificaties beschikbaar zijn voor een indicatieve telling: 1. Een model van de bedrijfsactiviteiten. 2. De basiseisen voor het te realiseren informatiesysteem. 3. Een specificatie van de omgevingseisen van het te realiseren informatiesysteem. 4. Eisen ten aanzien van de technische kenmerken. 5. Een globaal gegevensmodel. 6

7 En de volgende specificaties dienen beschikbaar te zijn voor een globale telling: 1. Een (structuur)model dat de betrokken logische gegevensverzamelingen en hun onderlinge relaties toont. 2. Een indicatie waar de onderscheiden logische gegevensverzamelingen worden onderhouden: door het te tellen informatiesysteem of door een ander informatiesysteem. 3. Een model dat de systeemfuncties laat zien met hun in- en uitgaande informatiestromen. 4. De informatiestromen die lopen tussen de functies van het te tellen informatiesysteem en zijn omgeving. De volgende specificaties moeten beschikbaar zijn voor een gedetailleerde telling: 1. Een model met alle logische gegevensverzamelingen en hun onderlinge relaties. 2. De recordtypen en de data-element-typen van de logische gegevensverzamelingen. 3. Een indicatie waar de onderscheiden logische gegevensverzamelingen worden onderhouden: door het te tellen informatiesysteem of door een ander informatiesysteem. 4. Een model dat de systeemfuncties laat zien met hun in- en uitgaande informatiestromen en de bij de functies betrokken logische gegevensverzamelingen, alsmede de ondersteunende functies (helpfuncties en dergelijke). 5. Een detaillering van de (in- en uitgaande) informatiestromen van het informatiesysteem tot op het niveau van data-element-typen. Deze eisen zijn in de onderstaande tabel uitgewerkt, toegespitst op het doel van deze eis in FPA. # Eis aan een specificatie FPA doel 1 Het (structuur)model Benoemen van de gegevensverzamelingen 2 De recordtypen en de data-element-typen Bepalen van de complexiteit van de onderscheiden in het datamodel gegevensverzamelingen 3 Een indicatie door welk informatiesysteem Vaststellen of een gegevensverzameling de gegevens worden onderhouden een ILGV of KGV is 4 Een model dat het gedrag van het Benoemen van de gebruikerstransacties informatiesysteem beschrijft. 5 Een gedetailleerde beschrijving van de Bepalen van de complexiteit van de gebruikerstransacties stroom van data-element-typen en de controles. Deze eisen zijn onder te verdelen in twee groepen: Structuur (eis 1, 2 & 3 ) Gedrag (eis 4 & 5) 2.3 UML diagrammen en FPA Een UML diagram visualiseert of gedrag, of structuur. Om een met UML beschreven ontwerp te tellen, is daarom simpelweg een diagram nodig dat structuur uitwerkt en een diagram nodig dat gedrag uitwerkt. Deze diagrammen zullen, om goed telbaar te zijn, bovenstaande eisen moeten uitwerken. Zoals het onderstaand overzicht van mogelijkheden laat zien kunnen meerdere combinaties van diagrammen gebruikt worden, zelfs door elkaar heen. FPA kan toegepast worden op elke combinatie van modellen die samen zowel structuur als gedrag beschrijven. Een belangrijk kenmerk van UML is granulariteit een UML diagram kan op meerdere detailniveaus toegepast worden. Alhoewel dit vanuit een engineering standpunt prettig is 7

8 (een model wordt verder uitgewerkt naarmate het project vordert het ondersteunt iteratief werken), is dit voor FPA onhandig. Het is oppervlakkig gezien niet meteen duidelijk hoe gedetailleerd een diagram is. In onderstaande tabel wordt daarom per detailniveau beschreven welke modellen voor kunnen komen in UML, hoe gedetailleerder het niveau hoe meer er mogelijk is. Detail-niveau Gedrag of Diagram Beschrijft FPA structuur? Indicatief Gedrag High-level Use Case Diagram Actoren, Systeem en hoog niveau functies Structuur High-level Class Diagram Globale informatiebehoefte Globaal Gedrag Expanded Use Case Diagram Use Case Description Activity Diagram Interaction Overview Diagram State Machine Diagram Actoren, Systeem en functies Stappen in een Use Case Stappen in een Use Case Stappen in een Use Case Stappen in een Use Case System-level Sequence Stappen in een Use Case Diagram System-level Stappen in een Use Case Collaboration Diagram Structuur Class Diagram Informatiebehoefte Gedetailleerd Gedrag Use Case Diagram Actoren, Systeem en functies Use Case Description Activity Diagram Interaction Overview Diagram Sequence Diagram Collaboration Diagram Acties in een Use Case Stappen in een Scenario Stappen in een Scenario Stappen in een Scenario Stappen in een Scenario Structuur Class Diagram Gedetailleerde informatiebehoefte De praktijk leert dat het Use Case model (zowel diagram als beschrijvingen) en een Classmodel vrijwel altijd voorhanden zijn. Deze combinatie is tevens zeer geschikt om FPA (zowel indicatief als globaal) uit te voeren. Voor een gedetailleerde telling is daarbij vooral het Sequence diagram van belang voor het vaststellen van de complexiteit van de gebruikerstransacties. In de volgende hoofdstukken wordt een verdere uitleg van het Use Case model en Classmodel gegeven en de toepassing van de FPA-richtlijnen daarbij. Hierbij wordt niet expliciet ingegaan op het vaststellen van de complexiteit van de gebruikersfuncties. Door de FPArichtlijnen toe te passen kan men natuurlijk wel tot een gedetailleerde telling komen. 8

9 3 Use Case model 3.1 Inleiding In dit hoofdstuk wordt beschreven hoe de FPA-richtlijnen voor het tellen van gebruikersfuncties kunnen worden toegepast op het Use Case model. Dit betreft dus zowel het Use Case diagram als de Use Case beschrijving. Zoals aangegeven in paragraaf 2.2 zijn de eisen waaraan specificaties moeten voldoen om een FPA telling te kunnen uitvoeren in twee groepen in te delen: structuur en gedrag. De Use Case diagrammen aangevuld met de Use Case beschrijvingen moeten voldoende inzicht geven in het gedrag van een informatiesysteem. Het belangrijkste onderdeel hiervan zijn de Use Case beschrijvingen, die noodzakelijk zijn voor het bepalen van het aantal gebruikersfuncties. Naast de Use Case diagrammen en de Use Case beschrijvingen wordt in dit hoofdstuk ook ingegaan op het nut van Storyboards. Alhoewel Storyboards geen officieel UML diagram zijn blijkt in de praktijk dat deze wel aanvullende informatie kunnen bevatten voor het bepalen van het aantal gebruikersfuncties. 3.2 Use Case diagrammen Een Use Case diagram visualiseert de afzonderlijke Use Cases, de actoren en de relaties tussen deze onderdelen. Een Use Case diagram is onderdeel van UML, maar net als de andere onderdelen van UML, niet verplicht. Dit diagram wordt in de praktijk wel vaak gemaakt en biedt voor FPA een goed overzicht van het informatiesysteem en de buitenwereld, met andere woorden de systeemgrenzen. In het volgende voorbeeld van een Use Case diagram zijn er drie actoren: Manager Kredieten, Verkoper en Klantensysteem. Klanten bijwerken Risico s analyseren «include Klanten Prijsovereenkomst «include Waardering kredieten Verkoper Overeenkomst vastleggen <<extend>> Kredieten instellen Klantgegevens opvragen Manager Figuur 3.1: Een voorbeeld van een Use Case diagram Een organisatie zal doorgaans een groot aantal Verkopers kennen. In de context van het informatiesysteem spelen ze echter allemaal dezelfde rol. 9

10 3.3 Use Case en Actor UML geeft de volgende definitie van het begrip Use Case: the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system. Use cases zijn een middel om de requirements van een informatiesysteem te beschrijven vanuit het gezichtspunt van de zgn. Actor. Een Actor wordt in UML omschreven als a role played by a user or any other system that interacts with the subject. Actors initiëren dus de Use Cases. Het is mogelijk dat één Actor verschillende Use Cases initieert. Andersom geldt ook dat een Use Case door verschillende Actors kan worden geïnitieerd. In veel gevallen is een Actor een natuurlijk persoon. Een Actor kan ook een informatiesysteem zijn. In zo n geval beschrijft een Use Case een interactie tussen twee of meer systemen. Bij FPA speelt het begrip gebruiker een essentiële rol bij het vast stellen van de gebruikersfuncties. Het begrip gebruiker wordt binnen de FPA-richtlijnen als volgt gedefinieerd: De personen en/of organisaties die het te meten informatiesysteem gebruiken of gaan gebruiken. Hierbij zijn inbegrepen: de eindgebruikers, de functioneel beheerders en de operators. De eigenaar en/of de functionaris(sen) die namens de eigenaar eisen en wensen bepalen die in de specificaties zijn opgenomen. Deze eisen en wensen worden vastgesteld op grond van de eisen van bijvoorbeeld de eindgebruiker(s), maar ook op grond van eisen die door de overheid of de wetgeving gesteld worden aan het informatiesysteem. Andere informatiesystemen die gegevens of functies van het te tellen informatiesysteem gebruiken. Het begrip Actor binnen UML valt derhalve binnen het begrip gebruiker in de FPA-richtlijnen. Use Cases representeren het voor de Actoren waarneembare gedrag van het informatiesysteem. In elke Use Case wordt een unit of functionality gespecificeerd die nut of toegevoegde waarde oplevert voor de betrokken Actoren. Kenmerkend voor een Use Case is derhalve dat hiermee de (gewenste) functionaliteit van een informatiesysteem wordt beschreven zoals die zich naar buiten toe manifesteert. Of zoals UML het zelf omschrijft: Use cases define the offered behavior of the subject without reference to its internal structure. 3.4 Use Case-beschrijving De beschrijving van een Use Case omvat doorgaans meerdere zgn. scenario s. Een scenario (ook wel flow genoemd) is een reeks stappen waarmee een interactie tussen een actor en een informatiesysteem wordt beschreven. Wanneer we als voorbeeld een online winkel op het web nemen, hebben we bijvoorbeeld een scenario Kopen product : De klant bladert door de catalogus en plaatst de gewenste artikelen in het boodschappenwagentje. Wanneer de klant wil gaan betalen, geeft hij of zij de informatie op die voor de verzending noodzakelijk is en voert de creditcardgegevens in. Het informatiesysteem controleert of het nummer van de creditcard in orde is. Het informatiesysteem bevestigt de koop onmiddellijk en daarnaast stuurt het informatiesysteem de bevestiging per naar de klant. Dit scenario beschrijft één van de mogelijke reeksen van interacties (flows) die kunnen worden uitgevoerd. In het bovenstaande scenario is het echter ook mogelijk dat de klant niet het juiste creditcardnummer heeft ingevoerd, wat tot gevolg heeft dat de koop niet wordt gesloten. Deze gebeurtenis wordt dan in een alternatief scenario beschreven. Deze scenario s hebben gemeen dat ze één en dezelfde doelstelling van een gebruiker ondersteunen. Doorgaans heeft een Use Case één Alles gaat goed scenario (basic flow) 10

11 en één of meer alternatieve reeksen (alternate flows) die beschrijven wat er mis kan gaan en hoe een gebruiker het doel op alternatieve wijzen kan realiseren. In een Use Case wordt het Alles gaat goed scenario beschreven als een reeks genummerde stappen (Use Case steps). De alternatieven worden vervolgens beschreven als variaties op deze stappen (zie onderstaande voorbeeldbeschrijving). Kopen product 1. De klant bladert door de catalogus en selecteert artikelen die hij/zij wil kopen 2. De klant gaat afrekenen 3. De klant vult de voor verzending benodigde informatie in (adres, snelle levering of gewone levering) 4. Het informatiesysteem geeft alle productinformatie weer, waaronder de prijs en verzendinformatie 5. De klant voert het nummer van zijn creditcard in 6. Het informatiesysteem valideert het creditcardnummer 7. Het informatiesysteem bevestigt de aankoop onmiddellijk 8. Het informatiesysteem bevestigt de aankoop door een bericht naar de klant te sturen Alternatief Mislukte validatie van creditcardnummer In stap 6 kan het informatiesysteem het creditcardnummer niet valideren. Het informatiesysteem biedt de klant opnieuw de mogelijkheid het creditcardnummer in te voeren. Alternatief Vaste klant 3a. Het informatiesysteem laat de huidige verzendinformatie zien, de prijs van het product en de laatste vier cijfers van het creditcardnummer. 3b. De klant accepteert deze standaardgegevens of wijzigt ze. Ga verder met stap 6 van het hoofdscenario In het bovenstaande voorbeeld is een interactieve manier van beschrijven toegepast. De gebruiker voert een handeling uit, het informatiesysteem reageert, de gebruiker doet vervolgens iets waarop het informatiesysteem weer reageert enz. enz. Deze manier van beschrijven, die inderdaad het van buitenaf waarneembare gedrag van het informatiesysteem weergeeft, wordt veel toegepast; Niettemin schrijft UML wat dit betreft geen standaard voor. Hoewel dus de inhoud van een Use Case beschrijving altijd (een deel van) de functionaliteit van de applicatie betreft kunnen Use Case-beschrijvingen qua vorm en diepgang onderling nogal verschillen. In de literatuur komen verschillende templates van Use Case-beschrijvingen voor waarbij tevens de verschillende elementen van een Use Case worden uitgelegd. Use Case-beschrijvingen kunnen tussen projecten en binnen een project gedurende de ontwikkelcyclus sterk verschillen in de mate van detail. Met name een iteratieve werkwijze brengt dat met zich mee. Zo kan het voorkomen dat de stappen zonder detail worden beschreven, bijvoorbeeld De baliemedewerker voert de klant gegevens in of zeer gedetailleerd zoals bijvoorbeeld De baliemedewerker voert voornaam, achternaam, adres, huisnummer in en selecteert de woonplaats. In de praktijk komt de minder gedetailleerde stijl het meest voor. Let met tellen dan goed op of alle functionaliteit beschreven is. Vraag bij twijfel de systeemanalist of hetgeen is opgeschreven volledig is. 3.5 Granulariteit van Use Cases Use Cases omvatten zoals gezegd, de gewenste functionaliteit van het informatiesysteem. Aangezien met FPA de functionele omvang van een informatiesysteem wordt bepaald zijn Use Cases in principe uitermate geschikt om functiepunten te tellen. Bij de toepassing van FPA bij Use Cases is echter vooral het uiteenlopende niveau waarop Use Cases worden onderkend (de granulariteit ) een lastig punt. De hiervoor aangehaalde definitie van UML geeft ook geen uitsluitsel over het niveau waarop Use Case moeten worden onderkend. In de praktijk ziet men dan ook dat Use Cases verschillen in granulariteit. Het is voor FPA een principieel punt omdat de systematiek van FPA is gebaseerd op het begrip elementaire functie. 11

12 Een functie is een elementaire functie voor FPA als aan twee voorwaarden wordt voldaan: De functie heeft voor de gebruiker een zelfstandige betekenis en voert een geheel afgeronde verwerking van informatie uit. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. Enkele voorbeelden kunnen dit verduidelijken: Een veel voorkomende manier waarop Use Cases worden onderscheiden is de Beheren object -stijl, bijvoorbeeld Beheren klant. De happy flow is dan bijvoorbeeld Raadplegen klant en de zgn. alternatieve flows in deze Use Case kunnen dan Toevoegen, wijzigen en Verwijderen van een klant zijn. In dit geval is er één Use Case maar volgens de telrichtlijnen moeten hier vier gebruikerstransacties worden geteld (1 opvraagfunctie en 3 invoerfuncties). Anders gezegd: de Use Case is onderscheiden op een hoger niveau dan dat van een elementaire functie volgens de FPA-richtlijnen. Het andere uiterste is een Use Case model waarin de gebruikerstransacties zijn gedecomponeerd in allerlei deeltransacties die elk in een aparte Use Case worden beschreven. Een voorbeeld is de gebruikerstransactie Registreren order (voor FPA in principe één invoerfunctie) die is opgedeeld in de volgende Use Cases: Valideren klant, Valideren artikel, Toevoegen orderregel, Bepalen leverdatum en Bevestigen transactie. Daartussenin bevindt zich de wijze waarbij de Use Cases goed zijn gemodelleerd volgens het OTOPOP principe (one time- one place - one person oftewel eenheid van tijd, plaats en handeling). Dit niveau komt het dichtst bij het begrip elementaire functie die de basis vormt voor de FPA gebruikerstransacties. Maar dit is geen garantie voor een één op één verhouding. In de praktijk kunnen ook combinaties van granulariteit voorkomen. Een andere indeling van niveaus waarop Use Cases kunnen worden onderkend is voorgesteld door Cockburn. Hij onderscheidt de volgende niveaus (levels): summary level. Use Cases op dit niveau zijn vooral bedoeld om de doelstellingen van het informatiesysteem voor de organisatie duidelijk te maken. Op dit niveau worden bedrijfsprocessen in termen van Use Case beschreven (Business Use Case) of groeperingen van bij elkaar horende Use Cases (lijkt op een indeling in subsystemen). Dit niveau is een te hoog niveau voor het tellen van gebruikerstransacties. Voorbeeld van een Use Case op dit niveau is Behandelen Schadeclaim bij een verzekeringsmaatschappij. user goals. Dit niveau correspondeert met het klassieke begrip elementaire bedrijfsactiviteit. Binnen de hiervoor genoemde Use Case Behandelen schadeclaim kunnen bijvoorbeeld als Use Case onderscheiden worden: Accepteren schadeclaim, Beoordelen schadeclaim, Fiatteren toekenning schadeclaim. subfunctions. Vaak zijn dit de hergebruikte delen van elementaire functies. Voorbeelden binnen de hiervoor genoemd Use Cases zouden kunnen zijn: Opzoeken schadeclaim, Opzoeken polisvoorwaarden, Opzoeken verzekeringnemer, Opvoeren toewijzing claim. Het onderkennen van de FPA gebruikerstransacties bij Use Cases komt derhalve in feite neer op het zorgvuldig hanteren van de definities uit de FPA-richtlijnen. De functiepuntanalist zal zich in eerste instantie ervan moeten vergewissen op welk niveau de verschillende Use Cases zijn beschreven. Pas daarna kunnen door analyse van de Use Case-beschrijvingen (evenals trouwens bij klassiek beschreven systemen) de gebruikerstransacties worden geïnventariseerd. 12

13 3.6 Relaties tussen Use Cases Naast de relaties tussen Actors en Use Cases kan men ook verschillende typen relaties tussen Use Cases onderling aangeven Include relaties Er is sprake van een relatie include wanneer een bepaald gedrag in verschillende Use Cases terugkeert en men ervoor gekozen heeft dit gedrag eenmalig te beschrijven. In figuur 3.1 wordt deze relatie gebruikt. Zowel Risico s analyseren als Prijsovereenkomst brengen een evaluatie van een overeenkomst met zich mee, namelijk Waardering kredieten. Aangezien bij beide Use Cases exact hetzelfde evaluatieproces uitgevoerd moet worden, wordt dit evaluatieproces in de afzonderlijke Use Case Waardering kredieten beschreven. Een included Use Case kan zowel een elementaire functie conform de FPA-richtlijnen op zich zijn als een onderdeel daarvan. Een voorbeeld is een zoeklijst die de inhoud van een gegevensverzameling (niet zijnde een FPA-tabel) toont om daaruit een selectie te doen. Die zal op grond van de richtlijnen als een uitvoerfunctie moeten worden geteld. Gaat het echter om een standaard validatie die op diverse plaatsen in het informatiesysteem wordt gebruikt, en om die reden als een aparte Use Case wordt beschreven, dan mag deze niet als een aparte gebruikerstransactie worden geteld Extend relaties Een ander type relatie wordt extend genoemd. Een extended Use Case breidt de functionaliteit van een bepaalde Use Case uit. In dit geval moeten in de basis Use Case wel bepaalde extensiepunten zijn gedeclareerd. De uitbreidende Use Case mag alleen extra gedrag toevoegen bij deze extensiepunten (zie figuur 3.2). Figuur 3.2: Relatie Extend Ook hier zal de functiepuntanalist van geval tot geval moeten beslissen of hier sprake is van een separate gebruikerstransactie of niet. In een bibliotheek zullen bijvoorbeeld de Use Case Uitlenen boek voorkomen, maar daarnaast ook een Use Case als Verlengen boek die een extend-relatie heeft met Uitlenen boek. Analyse van de Use Case-beschrijvingen zal dan moeten uitwijzen of hier al dan niet sprake is van meermalen gebruikte, echter maar eenmalig te tellen functionaliteit. 13

14 3.7 Storyboards Naast Use Cases worden ook vaak Storyboards gespecificeerd. Een Storyboard is een visuele presentatie van de menu s, de schermen en schermovergangen/aanroepen. Daarnaast worden Storyboards gebruikt voor schermontwerp en geven daarmee inzicht in welke attributen op welke schermen worden getoond en op welke manier. Vooral het feit of gegevens in lijsten of dropdown componenten getoond worden kan van belang zijn voor de telling. Storyboards zijn geen onderdeel van UML maar komen in de praktijk wel veel voor. 3.8 Toepassing FPA-richtlijnen Voor het toepassen van de FPA-richtlijnen volgen hieronder aandachtspunten voor het vaststellen van de gebruikerstransacties: Een elementaire functie is een voor de gebruiker afgeronde eenheid van werken. Use Cases zijn lang niet altijd op dit niveau onderkend en beschreven. De volgende situaties kunnen voorkomen: De Use Case beschrijft een deel van een elementaire functie. Dit komt met name voor bij zgn. include-use Cases. De Use Case beschrijft een elementaire functie, bijvoorbeeld Opvoeren klant. De Use case omvat meerdere elementaire functies, bijvoorbeeld Beheren klant die de invoerfuncties Invoeren, Wijzigen en Verwijderen klant omvat. De Use Case beschrijft een compleet bedrijfsproces met meerdere elementaire functies (deze Use Cases worden vaak Business Use Cases genoemd). Het Use Case diagram geeft inzicht in de grenzen van het informatiesysteem en is daarmee een hulpmiddel voor het bepalen van de scope en de systeemgrens. Lees naast de Alles gaat goed scenario s ook de alternatieve scenario s voor het bepalen van de gebruikerstransacties. Alternatieve scenario s kunnen twee verschijningsvormingen hebben: Enerzijds kan het gaan om niet meer dan een foutafhandeling. In deze gevallen zal er vaak geen sprake zijn van een (extra) gebruikersfunctie. Anderzijds kan het gaan om aanvullende stappen die de Actor doorloopt. In dit geval kan er wel sprake zijn van andere gebruikersfuncties indien er sprake is van een andere logische verwerking en er sprake is van een afgeronde eenheid van werken. Lees naast de basis Use Case ook de extend en include Use Case door; mogelijk worden daar aanvullende gebruikerstransacties beschreven. Hierbij dient gelet te worden op het vermijden van dubbeltellingen. Als een include Use Case ook zelfstandig is uit te voeren (door de gebruiker apart op te starten) dan worden de gebruikersfuncties los geteld. Indien de include Use Case niet zelfstandig is uit te voeren dan wordt deze geteld als onderdeel van de aanroepende Use Cases. Lees naast de Use Case ook de Storyboards of schermafdrukken. Storyboards kunnen inzichtelijk maken of binnen een Use Case nog aanvullende gebruikerstransacties worden beschreven, bijvoorbeeld het tonen en selecteren uit een lijst cq. dropdownlist. Deze aanvullende gebruikerstransactie moet worden meegeteld als een uitvoerfunctie. Let hierbij echter op of de betreffende lijst geen FPA-tabel betreft. Deze mag dan niet worden meegeteld. Use Cases kunnen ook vaak een zoekcomponent bevatten. De Use Case heeft dan meestal de structuur zoeken, selecteren en actie (bijvoorbeeld het wijzigen van de gegevens) uitvoeren. In dit voorbeeld betreft het dan een uitvoerfunctie en een invoerfunctie. Eventueel kan het zoekcomponent ook uit meerdere unieke zoekmogelijkheden bestaan, dus meerdere opvraagfuncties. 14

15 Let bij een Use Case op dat de Use Case niet het beheren van een FPA-tabel betreft. Deze mogen niet worden meegeteld. Indien de Actor een ander informatiesysteem is dan is er sprake van een interface. Let in deze situatie op of alle gebruikersfuncties zijn beschreven. Deze worden vaak in een ander document beschreven, bijvoorbeeld een interfacebeschrijving. 15

16 4 Class-model 4.1 Inleiding In deze paragraaf wordt beschreven hoe de FPA-richtlijnen voor het tellen van het gegevensmodel kunnen worden toegepast op een Class-model dat volgens OO-principes is opgezet 1. Het gaat hierbij in het bijzonder om de toepassing van de telrichtlijnen die betrekking hebben op het afleiden van de LGV s uit een genormaliseerd gegevensmodel. Het onderscheid tussen KGV s en ILGV s is in een OO-omgeving niet anders dan in een klassieke omgeving. Ook de specifieke richtlijnen betreffende de ILGV s en de KGV s zijn zonder meer van toepassing op een telling in een OO-omgeving. Het cruciale punt is: hoe kunnen op basis van het OO Class-model op verantwoorde wijze de LGV s worden afgeleid. Dit hoofdstuk is als volgt opgezet: in paragraaf 4.2 wordt een korte toelichting gegeven op het Class-model, vooral de verschillende relaties worden uitgelegd. In paragraaf 4.3 worden enkele voorbereidende stappen beschreven die moeten worden uitgevoerd voordat de werkelijke telrichtlijnen kunnen worden toegepast. In paragraaf 4.4 wordt de eigenlijke toepassing van de FPA-richtlijnen uitgewerkt. 4.2 Class-model De afbeeldingwijze van een Class-model is in UML het zgn. Class-diagram. In deze paragraaf wordt in het kort beschreven wat minimaal nodig is om een Class-diagram, opgezet conform UML-richtlijnen, te kunnen lezen en te interpreteren. De specificatie van UML betreffende Class-diagrammen is veel uitgebreider dan in dit korte bestek kan worden behandeld. Verwezen wordt naar de vele beschikbare literatuur op dit gebied. Een Class is de definitie (beschrijving) van de attributen en de bewerkingen (zgn. methods) van gelijksoortige objecten. Een object is de feitelijke verschijningsvorm van een Class (vgl. het onderscheid tussen entiteit en occurrence (of: entiteittype en entiteit)). Objecten worden ook wel aangeduid als instanties ('instances') en zijn een representatie van zowel concrete als abstracte dingen uit de werkelijkheid. Bijvoorbeeld de Class Bankrekening heeft de volgende instanties: Rabobankrekening ABN-AMRO-rekening Postbankrekening In objectgeoriënteerde modellen vormen Classes en objecten en hun relaties de basis elementen. Het Class-diagram visualiseert de relaties tussen Classes en objecten en maakt duidelijk hoe de samenhang is. Omvangrijke Class-diagrammen worden in packages verdeeld. Let hierbij op dat Classes niet dubbel worden geteld. In een Class-diagram wordt een doorgaans Class afgebeeld als een rechthoek verdeeld in drie delen (compartimenten), gescheiden door horizontale lijnen. Het bovenste deel bevat de naam van de Class, het middelste de lijst van attributen en het onderste compartiment een lijst van methods. Afhankelijk van hetgeen men wil modelleren en het perspectief van waaruit gemodelleerd wordt zal men de verschillende compartimenten tonen. Bij bedrijfsmodellering zal in een Class-diagram van een Class meestal alleen het naamcompartiment getoond worden. 1 Men treft vaak hybride situaties aan waarbij een klassiek opgezet gegevensmodel in de vorm van een Class-diagram wordt gedocumenteerd. 16

17 Bankrekening <id> rekeningnummer: Num <9> soort rekening: String <6> bedrag: Num<15> neembedragop(bedrag): schrijfbedragbij(bedrag): geefsaldo(): bedrag of: Bankrekening Het Class-diagram toont, zoals gezegd, ook de relaties tussen Classes. UML kent de volgende Class/object relaties: Association Aggregation Composition Generalization De eerste drie relatievormen worden objectrelaties genoemd. Deze relaties manifesteren zich op het niveau van de individuele objecten. Vandaar dat bij dergelijke relaties ook multipliciteiten (cardinaliteiten) worden aangegeven. Generalization-relaties zijn daarentegen Class-relaties. Het is dan ook niet mogelijk bij Class-relaties multipliciteiten aan te geven Association Een associatie is een structurele relatie tussen objecten. Een voorbeeld is de relatie tussen Klant en Order. De associatie is binnen een Class-diagram de eenvoudigste soort van relatie. Evenals in een klassiek Entiteit-Relatie-Diagram wordt bij de associaties ook de cardinaliteit en de optionaliteit aangegeven. Dit wordt in een Class-diagram met behulp van de zgn. multipliciteit aangegeven, in het onderstaande voorbeeld geval een 1 - op - meerrelatie. Dit is een voorbeeld van een wederzijds verplichte relatie. Klant 1 1..* Order Een multipliciteit die is aangegeven als: 1 op * komt dus overeen met 1 op meer-relatie met de optionaliteit aan de meer -kant. 17

18 4.2.2 Aggregation Een aggregationrelatie is een bijzondere vorm van een associationrelatie. Aggegration is een geheel-deel-relatie tussen samengestelde objecten en componentobjecten. Sleutelwoorden hierbij zijn: Bestaat uit, of Maakt deel uit van. Een voorbeeld van een dergelijke relatie staat hieronder afgebeeld. Team * Speler Deelobjecten (Spelers) kunnen worden verwijderd zonder dat het samengestelde object ophoudt te bestaan. Omgekeerd zal, als het samengestelde object (Team) wordt verwijderd, het deelobject blijven bestaan. Merk op dat in termen van cardinaliteit en optionaliteit de bovenstaande multipliciteit overeenkomt met een wederzijds optionele 1 op n relatie Composition Een composition relatie is een extremere vorm van een aggregation. Het is ook een geheeldeel-relatie maar: een deel kan maar bij ten hoogste één geheel behoren. De multipliciteit is in geval van een composition-relatie aan de geheel -kant altijd 1. een composition heeft duidelijke regels met betrekking tot het ontstaan en het verwijderen van het onderdanige object. Als het geheelobject wordt verwijderd dan vervallen daarmee ook de onderdanige objecten. Order 1 1..* Orderregel In bovenstaand voorbeeld maakt een orderregel-object altijd deel uit van hetzelfde orderobject, en is hier volledig van afhankelijk Generalization Generalization werkt anders dan de andere relaties; generalization is namelijk een relatie tussen Classes, niet tussen objecten. Via generalization erft een Class kenmerken van een andere bovenliggende zgn. superclass. Dat wil zeggen aan de hand van onderstaand 18

19 voorbeeld, dat een Personenauto ook een (soort) Auto is. Een personenauto heeft alle kenmerken (zowel attributen als methoden) van een auto. Generalization wordt in UML als volgt afgebeeld: Auto Personenauto Vrachtauto of: Auto Personenauto Vrachtauto Deze Classes erven van elkaar. Dit betekent dat een Personenauto (subclass) alle kenmerken van een Auto (superclass) erft, en hier zelf zijn eigen kenmerken aan toevoegt. Een Personenauto is dan een specialisatie van een Auto. De naam van de superclass Auto is cursief. Dit geeft aan dat deze Class abstract is, d.w.z. er bestaan geen objecten van de Class Auto; de werkelijke objecten zijn of van de Class Personenauto of van de Class Vrachtauto. 4.3 Voorbereidende stappen bij het tellen Gedrag en persistentie Een Class-model heeft een bredere betekenis en reikwijdte dan een klassiek gegevensmodel. Hoewel op het eerste gezicht een Class analoog aan een entiteit in een gegevensmodel lijkt, blijken bij nadere beschouwing in een Class-model ook gedragsaspecten te zijn gemodelleerd. Van een object worden in OO immers zowel gegevens als gedrag gemodelleerd. Alvorens de FPA-richtlijnen toe te passen dienen voor de telling eerst de classes zonder attributen te worden verwijderd, behalve ingeval van Class-relaties (Generalization). Classes zonder attributen bevatten alleen gedrag en geen permanent te bewaren (zgn. persistente) gegevens. Men zou deze voorbereidende stap dan ook kunnen formuleren als het verwijderen van de niet-persistente Classes. Het doel is immers hier alleen het onderkennen van de ILGV/KGV s en niet het onderkennen van de gebruikerstransacties. Voor de telling zijn alleen díe Classes relevant, die persistente, d.w.z. permanente ofwel te bewaren gegevens bevatten. De reden dat bij Class-relaties (dus bij generalization) niet meteen de Class zonder attributen wordt verwijderd, ligt in het feit dat subclasses die ogenschijnlijk geen attributen hebben, 19

20 deze wel kunnen erven van superclasses. De beoordeling of dergelijke classes buiten beschouwing moeten worden gelaten als logische gegevensverzamelingen wordt daarom nog even uitgesteld totdat de generalization-relaties onder de loep worden genomen. Toelichting: Deze regel vloeit voort uit de definitie van de NESMA: het gaat om permanente gegevens. Een voorbeeld van een Class die alleen gedrag beschrijft is een Class Catalogus van een handelsbedrijf. Deze Class heeft in het onderstaande voorbeeld geen attributen maar alleen methods. Catalogus geefprijslijstpercategorie() zoekproduct() Verder kunnen in een Class-model Classes zonder attributen voorkomen als subclasses die zijn gemodelleerd vanwege specifieke gedragsaspecten (methods). In feite zijn het geen Classes zonder attributen omdat ze uiteraard de attributen van de superclasses overerven. Hanteer de volgende richtlijnen: Classes die alleen gedrag beschrijven en alleen instance-relaties hebben met andere Classes (associatie, aggregation en composition) kunnen zonder meer worden verwijderd. Laat Classes die alleen gedrag beschrijven en Class-relaties met andere Classes (het gaat hier om generalization relaties) hebben, voorlopig zo staan. Deze Classes komen nog aan de orde bij de behandeling van generalization-relaties. Na de toepassing van deze regel resteert een Class-model dat: alleen permanente gegevens bevat alleen die Classes omvat die (ook) attributen bezitten Stereotypes In UML bestaat de mogelijkheid van modelelementen een zgn. stereotype aan te geven. Deze kan worden gebruikt om de betekenis van een UML-symbool (in dit geval het Classsymbool) nauwkeuriger aan te geven in verband met een specifieke toepassing van dat symbool. Een stereotype wordt aangeduid als : <<stereotype>> in het bovenste compartiment van het class-symbool. In deze context wordt het Class-symbool vooral toegepast als weergave van een gegevensverzameling. Anders gezegd: de voor FPA meest geëigende classes zijn de classes van het stereotype <<entity>>. In een Class-model kunnen ook andere stereotypes voorkomen zoals interface-classes en control-classes. Dit zijn met name technische constructies. Komen dergelijke andere stereotypes voor in een Class-model dan zijn voor de functiepuntanalist in principe alleen de entity-classes relevant. Als dergelijke stereotypes niet zijn aangegeven in het Class-diagram dan kan in het algemeen worden aangenomen dat het gaat om entity-classes, tenzij uit de naamgeving overduidelijk blijkt dat het technische implementaties betreft. 20

21 4.4 Toepassing FPA-richtlijnen In deze paragraaf wordt uiteengezet hoe de FPA-richtlijnen met betrekking tot het gegevensmodel worden toegepast. Hierbij worden de bekende vier stappen uit de richtlijnen toegepast te weten: 1. Bepaal welke entiteittypen een FPA-tabel zijn 2. Bepaal de sleutel-sleutel entiteiten zonder attributen 3. Bepaal de sleutel-sleutel entiteiten met attributen 4. Onderzoek de aard van de relaties Stel de FPA-tabellen vast In een Class diagram zijn (potentiële) FPA-tabellen vaak minder gemakkelijk herkenbaar. Hanteer de onderstaande richtlijnen. In een Class-model kunnen kandidaat-fpa-tabellen als enumeraties zijn gemodelleerd (conform karakter van referentietabellen ). Een voorbeeld van een enumeratie is de onderstaande Class van een bibliotheeksysteem waarbij de leden in categorieën zijn ingedeeld. <<enumeration>> SoortLid jeugdlid volwassenlid 65-plusser student scholier Let op: indien er geen onderhoud is gespecificeerd op deze tabellen dan dienen deze überhaupt niet geteld te worden. Indien FPA-tabellen niet in het Class-model zijn gemodelleerd, kijk dan naar: onderhoudbare waardebereiken van attribuutwaarden aanvullende documentatie zoals storyboards en schermen of daar misschien wel sprake is van FPA-tabellen. Voor het overige kunnen de gewone FPA-richtlijnen worden toegepast bijvoorbeeld bij: Land <<id>> code: String <3> naam: String <40> Sleutel-sleutel entiteiten zonder attributen De tegenhanger van sleutel-sleutel entiteiten in een klassiek genormaliseerd gegevensmodel zijn in een Class-model de zgn. Association-Classes. Deze komen in een zuivere vorm, dat wil zeggen zonder attributen, echter niet voor in een Class-model dat immers geen foreign keys kent. 21

22 4.4.3 Sleutel-sleutel entiteiten met attributen In een Class-model wordt een Association-Class alleen gemodelleerd als er ook attributen zijn. Dergelijke Classes worden dus op gelijke wijze als de andere Classes behandeld. Project ProjectNaam ProjectDatumBegin ProjectDatumEind Medewerker MedewerkerNaam MedewerkerAdres MedewerkerWoonplaats MedewerkerGeboortedatum ProjectDeelname DatumInProject DatumUitProject Bestaanszelfstandigheid en afhankelijkheid bij instance-relaties De volgende stap is het beoordelen van de instance-relaties op bestaanszelfstandigheid en bestaansafhankelijkheid. Een Class diagram kent de volgende instance-relaties: association aggregation composition generalization Deze relaties worden achtereenvolgens behandeld: Association Een associatie is een structurele relatie tussen objecten. Een voorbeeld is de relatie tussen Klant en Order. De associatie is binnen een Class diagram de eenvoudigste soort van relatie. Hanteer de volgende richtlijn: Komt bij de multipliciteit aan weerszijden een 1 voor (verplichte relatie), tel de twee Classes dan samen als 1 LGV. Komt bij de multipliciteit aan weerszijden een 0 voor, tel de twee Classes dan als 2 LGV s. Komt bij de multipliciteit aan een zijde een 0 voor, pas dan de zgn. delete-rule toe voor het bepalen van de bestaanszelfstandigheid en de bestaansafhankelijkheid. 22

23 Aggregation Het betreft hier een geheel-deel-relatie. Een voorbeeld van een dergelijke relatie staat hieronder afgebeeld. Team * Speler Beoordeel ook hier de multipliciteiten Komt bij de multipliciteit aan weerszijden een 1 voor (verplichte relatie), tel de twee Classes dan samen als 1 LGV. Komt bij de multipliciteit aan weerszijden een 0 voor, tel de twee Classes dan als 2 LGV s. Komt bij de multipliciteit aan een zijde een 0 voor, pas dan de zgn. delete-rule toe voor het bepalen van de bestaanszelfstandigheid en de bestaansafhankelijkheid. Composition Bij de composition ligt de situatie iets anders. Het is ook een geheel-deel-relatie maar: een deel kan maar bij één geheel behoren. De multipliciteit is in geval van een composition-relatie aan de geheel -kant altijd 1. een composition heeft duidelijke regels met betrekking tot de life-cycle zowel bij het ontstaan als bij het verwijderen. In termen van functiepuntanalyse: er is hier sprake van volledige bestaansafhankelijkheid. Order 1 1..* Orderregel Bij een composition dient altijd uitgegaan te worden van bestaansafhankelijkheid en derhalve moeten de twee Classes samen als 1 LGV worden geteld. 23

24 Generalization Met behulp van super- en subclasses worden generalizations gemodelleerd. Deze worden op de volgende wijze afgebeeld: Auto Personenauto Vrachtauto of: Auto Personenauto Vrachtauto Beoordeel deze relaties op dezelfde wijze als in een klassiek gegevensmodel de superen subclasses (specialisaties en generalisaties). Dus in het algemeen: Zijn er verschillen tussen de subclasses ga dan na of er sprake is van ander gedrag binnen het informatiesysteem (dus specifieke gebruikerstransacties voor de verschillende subclasses). Bepaal op basis hiervan of ze afzonderlijk geteld moeten worden. Ga na bij de gebruiker of de super- en subclasses voor hem levende begrippen zijn: soms zijn dergelijke constructies typische analyseconstructies. In dat geval dient 1 LGV geteld te worden. Tel 1 LGV indien: de gebruiker het als 1 Class ziet of de Class in de Use Case(s) als 1 Class wordt behandeld Tel meerdere LGV s indien: de gebruiker de subclasses als n verschillende Classes ziet de Classes in de Use Case(s) als verschillende Classes wordt behandeld (bijv. verschillende onderhouds-use Cases) 24

25 5 Begrippenlijst Actor Iemand of iets die een impuls ( trigger ) veroorzaakt voor het informatiesysteem. Een Actor staat buiten het informatiesysteem en wordt niet bestuurd door het informatiesysteem. Het begrip Actor binnen UML valt derhalve binnen het begrip gebruiker in de FPA-richtlijnen. Aggregation (relatie) [Aggregatie] Een relatie tussen objecten waarbij de één deel uitmaakt van de ander (geheel-deel relatie). Het deel kan echter zelfstandig bestaan en bij meerdere gehelen behoren. Association (relatie) [Associatie] Een structurele relatie tussen objecten. Class [Klasse] Een Class is een beschrijving van een groep objecten met gelijke eigenschappen en gemeenschappelijk gedrag, relaties en semantiek. Class diagram [Klassediagram] Geeft een beeld van een informatiesysteem door de Classes en relaties ertussen te tonen. Een Class diagram is statisch: er wordt aangegeven welke onderdelen interactie hebben maar niet wat er tijdens die interactie gebeurt. Composition (relatie) [Compositie] Een relatie tussen objecten waarbij de één intrinsiek deel uitmaakt van de ander (geheeldeel relatie), Maar waarbij het deel maar bij één geheel behoren en gelden specifieke regels bij het ontstaan en verwijderen, in tegenstelling tot Aggregation. Conceptueel gegevensmodel [Conceptual data model] Definieert welke gegevens in een informatiesysteem vastgelegd kunnen worden, hoe deze gegevens gestructureerd zijn en wat de verbanden zijn tussen die gegevens. Delete rule [Verwijder regel] Bij het bepalen of er sprake is van bestaansafhankelijkheid dan wel bestaanszelfstandigheid moet de volgende vraag gesteld worden: wat gebeurt er met de optionele kant van de relatie (in dit geval B) als we de niet-optionele kant van de relatie (in dit geval A) willen verwijderen, terwijl er B s aan gekoppeld zijn? Hierbij zijn twee essentieel verschillende mogelijkheden te onderscheiden: 1. Het verwijderen van de A is toegestaan en in dezelfde actie worden tevens alle gekoppelde B s verwijderd (zo nodig nadat bij de vraag om bevestiging van het verwijderen van A is meegedeeld dat ook alle B s automatisch verwijderd worden). 2. Het verwijderen van A is niet toegestaan, zolang er nog B s gekoppeld zijn. In situatie (1) hebben de B s voor het bedrijf kennelijk geen zinvolle betekenis buiten een gerelateerde A. In situatie (2) kennelijk wel. Voordat men daar de A mag verwijderen, zal men of bewust alle gerelateerde B s moeten verwijderen, of deze B s moeten koppelen aan een andere A. In situatie (1) noemen we B bestaansafhankelijk ten opzichte van A, in (2) bestaanszelfstandig. Elementaire functie Een functie is een elementaire functie als aan twee voorwaarden wordt voldaan: De functie heeft voor de gebruiker een zelfstandige betekenis en voert een geheel afgeronde verwerking van informatie uit. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. 25