BIJLAGE bij Functional Sizing op basis van FPA-principes in een SOA-gebaseerde omgeving. Versie 1.0

Transcriptie

1 BIJLAGE bij Functional Sizing op basis van FPA-principes in een SOA-gebaseerde omgeving Voorbeelduitwerkingen Versie PUBLICATIE VAN DE NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 1

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 Gebruikersgids: Functional Sizing toegepast bij een SOA-omgeving of daaraan gerelateerde NESMA-publicaties. Deze openbaarmaking geschiedt met toestemming van de NESMA. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 2

3 Inhoudsopgave Gebruikte afkortingen... 4 Referenties Inleiding Algemeen Minicasus MijnBankRekening Functionele Specificaties (verkort) Deelproject Voorkant (Servicevrager) Deelproject Bus Deelproject Achterkant (Serviceverlener) Berichtspecificaties (BS) Project MijnBankRekening Product MijnBankRekening Epiloog Minicasus MijnMailClient Functionele Specificaties (verkort) Deelproject Voorkant (Servicevrager) Deelproject Bus Deelproject Achterkant (Serviceverlener) Berichtspecificaties (BS) Project MijnMailClient Product MijnMailClient Epiloog Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 3

4 Gebruikte afkortingen GV SOA RFC SFP Gegevensverzameling Service Oriented Architecture Request for change (wijzigingsverzoek) SOA-FunctiePunten Referenties [1]: Definities en telrichtlijnen voor de toepassing van functiepunt analyse, versie 2.2. Handboek van de Nederlandse Software Metrieken gebruikers Associatie (Nesma). [2]: Gebruikersgids Functional Sizing op basis van FPA-principes in een SOA-gebaseerde omgeving, versie 0.9. Gebruikersgids van de Nederlandse Software Metrieken gebruikers Associatie (Nesma). Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 4

5 1 Inleiding In de SOA Gebruikersgids [2] hebben we uitgelegd dat SOA een architectuurprincipe is en hoe je de onderdelen of componenten daarvan telt. Die telling gaat op basis van de principes uit [1]. We tellen echter op grenzen die niet zijn zoals bedoeld in [1]: SOA-componenten hebben vaak grenzen die binnen die van een FPA-informatiesysteem vallen. Strikt volgens [1] overschrijden de datastromen tussen SOA-componenten geen systeemgrens en mogen ze niet worden geteld. We hebben echter wel met projecten te maken met deze SOA-componenten als onderwerp. Daarvan willen we de omvang weten. Gezien de argumentatie hiervoor, drukken we de omvang dus niet uit in FP, maar in SFP (SOA-functiepunten). In deze bijlage illustreren we de telmethode aan de hand van een tweetal voorbeelden. Deze voorbeelden kunnen, samen met [2], worden gebruikt als leidraad bij de praktijk. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 5

6 2 Algemeen Tellen vanuit SOA-perspectief impliceert gebruik van de omvangseenheid SFP. We maken globale tellingen op basis van de principes zoals aangegeven in [1: 3.2.2]. We volgen hierbij precies [2]. Dat doen we voor de volgende cases: MijnBankRekening: de servicevrager bevat geen ILGV s; MijnMailClient: de servicevrager bevat wel ILGV s. De tweede case maakt duidelijk dat een SOA-component zoals beschreven in [2] een informatiesysteem kan zijn zoals beschreven in [1]. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 6

7 3 Minicasus MijnBankRekening 3.1 Functionele Specificaties (verkort) Een gebruiker kan thuis (onder andere) informatie over zijn rekeningen opvragen, een rekening openen, eigenschappen daarvan wijzigen en een rekening beëindigen/opheffen. Om deze functionaliteit aan de Particuliere Markt aan te kunnen bieden, wordt nieuwe functionaliteit ontwikkeld en, waar nodig, bestaande functionaliteit aangepast. Architectuur-eis is, dat dit volgens de SOA-principes wordt gedaan. Zie de figuur hieronder. Browser: rekeninghouder Webserver Bank: rekeningsysteem Figuur 1 Architectuur "Internet Bankieren" Het systeem wordt gerealiseerd door de volgende deelprojecten onafhankelijk van elkaar uit te voeren: Voorkant : Servicevrager. Nieuw ontwikkelen van internet-pagina s voor de particuliere eindgebruikers; Achterkant : Serviceverlener. Aanpassen van het rekeningsysteem, zodat het via internet kan worden ontsloten; Bus : Aanpassen van de bus, zodat de voorkant en de achterkant efficiënt, snel en gestandaardiseerd met elkaar kunnen communiceren. We beschouwen het systeem vanuit het SOA-perspectief. We gaan eerst Projecttellingen maken en daarna een Producttelling van de Servicevrager en delta s daarvan van de Serviceverlener en de Bus. Van de laatste twee kunnen we geen producttellingen maken omdat we de totale (baseline) specificaties daarvan niet hebben. 3.2 Deelproject Voorkant (Servicevrager) Nadere specificaties Eigenschappen van een Servicevrager in het algemeen: 1. Dit is meestal een User Interface (verzameling samenhangende pagina s in een browser of op een andere manier gebundelde schermen en zaken die lokaal kunnen worden afgedrukt of opgeslagen); 2. Stuurt verzoeken (berichten) uit a. Om gegevens elders te muteren; b. Om gegevens elders op te halen; Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 7

8 c. Om processen elders te starten of te beïnvloeden. 3. Legt niets persistent vast binnen het component waarvandaan het verzoek is verstuurd. Het ontwerp van dit voorbeeld beschrijft bovenstaande eigenschappen, voor zover van toepassing. De scope van de telling is uitsluitend de Servicevrager, en de SOA-componentgrens is rond deze servicevrager getrokken. Zie [1: en 3.6.1] (m.n. nieuwbouwproject). Eigenschappen (architectuureisen): 1. Alle functionaliteiten worden gebruikt via internet of intranet; 2. Er worden geen gegevens lokaal persistent vastgelegd of onderhouden; 3. Er worden berichten uitgewisseld op basis waarvan gegevens elders worden gemuteerd of opgehaald. 4. De berichten zijn gespecificeerd in 3.5 Berichtspecificaties (BS). Het ontwerp bevat de volgende functionaliteiten (gebruikersfuncties): 1. Openen nieuwe rekening o Tonen: relatiegegevens; rekening(en) die de relatie eventueel al heeft, met het saldo daarop; Bericht uit: BS1 Bericht terug: BS2 o Optioneel invullen rekeningnaam Bericht uit: BS3 o Aanmaken nieuwe rekening na validatie. Bericht terug: BS4 2. Wijzigen rekeninggegevens o Tonen: relatiegegevens; rekening(en) die de relatie heeft, met het saldo daarop; Bericht uit BS1 Bericht terug: BS2 o Selecteren te wijzigen rekening, optioneel invullen/wijzigen rekeningnaam Bericht uit: BS5 o Vastleggen rekeninggegevens na validatie. Bericht terug: BS4 3. Opheffen rekening o Tonen: relatiegegevens; rekening(en) die de relatie heeft, met het saldo daarop; Bericht uit : BS1 Bericht terug: BS2 o Selecteren op te heffen rekening; Bericht uit: BS6 o Verwijderen rekening na validatie (o.a. saldo = 0). Bericht terug BS4 4. Opvragen gegevens rekeningen o Omvangbepaling o Tonen: relatiegegevens; rekening(en) die de relatie heeft; Bericht uit: BS1 Bericht terug: BS2 Selecteren te bekijken rekening; Bericht uit: BS5 o Tonen: rekeninggegevens (ook saldo) en transacties daarop van de afgelopen 6 maanden. Bericht terug: BS7. We maken een globale projecttelling van de Servicevrager. Functie KGV ILGV IF UF OF Opmerking Openen nieuwe rekening 4 Geen GV, verstuurt bericht aan Bus. [2: ] Wijzigen rekeninggegevens 4 Geen GV, verstuurt bericht aan Bus. [2: ] Opheffen rekening 4 Geen GV, verstuurt bericht Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 8

9 Functie KGV ILGV IF UF OF Opmerking aan Bus. [2: ] Opvragen gegevens algemeen 5 Relatiegegevens; Rekening(en) die de relatie heeft. Gevuld vanuit bericht van Opvragen gegevens details Totalen (SFP) Bus. [2: ] 5 Rekeninggegevens (ook saldo) en transacties daarop. Gevuld vanuit bericht van Bus. [2: ] Er worden geen ILGV s geteld omdat ze binnen deze componentgrens niet persistent aanwezig zijn. Er zijn ook geen KGV s omdat de architectuur directe koppelingen met andere systemen uitsluit. FPA-tabellen zijn (RET s van) GV s en worden dus evenmin geteld. Wanneer is er sprake van een ILGV? Als het te tellen informatiesysteem de regie heeft over de toegang tot, inhoud, actualiteit, structuur en het permanente karakter (alle vijf dus) van een logische groep gegevens, dan moet deze voor het te tellen informatiesysteem als een interne logische gegevensverzameling worden geteld. Wanneer is er sprake van een KGV? Als het te tellen informatiesysteem alleen de regie heeft over de toegang tot (en dus niet de andere vier aspecten van) een logische groep gegevens die in een ander informatiesysteem als interne logische gegevensverzameling onderkend is, dan moet deze voor het te tellen informatiesysteem als een koppelingsgegevensverzameling worden geteld. Eventuele keuzelijsten zijn niet afkomstig uit GV s, maar uit berichten of ze zijn hard coded. Het zijn daarom altijd eenvoudige OF s (zie [1: 4.16]). In dit voorbeeld is er geen keuzelijst gespecificeerd. De Servicevrager is geheel nieuw. Daardoor is de productomvang van dit component net als de projectomvang gelijk aan 22 SFP. Opmerking: de IF s voldoen niet aan de definitie in [1: 7.1]. Het is echter gebruikelijk om ze volgens [1] toch te tellen als IF. Dat doen we dus ook hier. 3.3 Deelproject Bus Nadere specificaties Eigenschappen van een Bus 1, 2 in het algemeen: 1. Voor eindgebruikers is deze onzichtbaar; 2. Stuurt berichten (verzoeken) uit a. Om op verzoek van een Servicevrager gegevens elders (bij een Serviceverlener) te muteren; b. Om op verzoek van een Servicevrager gegevens elders (bij een Serviceverlener) op te halen; c. Om processen elders te starten of te beïnvloeden. 3. Stuurt berichten uit met a. Mutatieresultaten aan de Servicevrager; b. Opgehaalde gegevens aan de Servicevrager. 4. Kan een User Interface hebben a. Om het correct functioneren van de Bus te waarborgen; b. Voor beheerders van de Bus. 5. Legt gegevens persistent vast voor het correct functioneren van de Bus Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 9

10 6. Legt geen gegevens persistent vast die content-specifiek zijn, dus niet van belang zijn voor het functioneren van de Bus. Het ontwerp van dit voorbeeld beschrijft bovenstaande eigenschappen, voor zover van toepassing. De scope van de telling is uitsluitend de functionaliteit van de Bus nodig om de Servicevrager en verlener te laten functioneren zoals bedoeld. De benodigde berichttypen zijn alle nieuw voor de Bus, die op zich al bestaat. De SOA-componentgrens is rond dit deel van de Bus getrokken. Eigenschappen (architectuureisen): 1. Alle functionaliteiten worden gebruikt via de operationele ESB; 2. Er worden geen gebruikersgegevens persistent in de Bus vastgelegd of daar onderhouden; 3. Er worden berichten uitgewisseld op basis waarvan gebruikersgegevens elders worden gemuteerd of opgehaald en die eventueel worden teruggeleverd aan de Servicevrager. 4. De berichten zijn gespecificeerd in 3.5 Berichtspecificaties (BS). Het ontwerp bevat de volgende functionaliteiten (gebruikersfuncties): 1. Ontvangen gegevens van de Servicevrager o Bericht BS1 o Bericht BS3 o Bericht BS5 o Bericht BS6 2. Doorsturen gegevens naar het rekeningsysteem van de bank, de Serviceverlener o Bericht BS3 o Bericht BS5 o Bericht BS6 3. Ontvangen mutatieresultaten van de Serviceverlener o Bericht BS4 4. Doorsturen mutatieresultaten naar de Servicevrager o Bericht BS4 5. Ontvangen verzoek om gegevens van de Servicevrager o Bericht BS8; o Bericht BS9 6. Doorsturen verzoek om gegevens naar het rekeningsysteem o Bericht BS8 o Bericht BS9 7. Ontvangen gebruikersgegevens van de Serviceverlener o Bericht BS10 o Bericht BS11 8. Terugsturen gebruikersgegevens naar de Servicevrager o Bericht BS2 o Bericht BS10 o Bericht BS11. De Bus hoeft geen logische transformaties, verrijkingen of validaties uit te voeren Omvangbepaling We maken een globale projecttelling van het relevante deel van de Bus. Functie KGV ILGV IF UF OF Opmerking Berichten nieuwe rekening 5 BS3. Berichttype aan Serviceverlener, envelop gelijk aan wijzigen en opheffen, structuur van inhoud niet. Berichten wijzigen rekening 5 BS5. Berichttype aan Serviceverlener, envelop gelijk aan nieuw en opheffen, structuur van inhoud niet. Berichten opheffen 5 BS6. Berichttype aan Service- Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 10

11 Functie KGV ILGV IF UF OF Opmerking rekening verlener, envelop gelijk aan nieuw en wijzigen, structuur van inhoud niet. Bericht mutatieresultaat 5 BS4. Berichttype aan Servicevrager Bericht rekeningen 5 BS8. Berichttype aan Serviceverlener Bericht transacties 5 BS9. Berichttype aan Serviceverlener Berichten rekeningenlijst 5 BS10. Berichttype aan Serviceverlener Berichten transactielijst 5 BS11. Berichttype aan Serviceverlener Totalen (SFP) Er worden geen ILGV s geteld omdat ze binnen deze componentgrens niet persistent aanwezig zijn. Er zijn ook geen KGV s omdat de architectuur directe koppelingen met andere systemen uitsluit. Zie het kader op blz. 9. De functionaliteiten 1, 3, 5 en 7 zijn niet elementair. Het zijn de invoerdelen van respectievelijk de functionaliteiten 2, 4, 6 en 8 (verzonden berichten). Dit zijn de doelen van deze combinaties. De Bus is gewijzigd (berichttypen toegevoegd). Daardoor is de delta 3 van de productomvang van dit component net als de projectomvang gelijk aan 40 SFP. 3.4 Deelproject Achterkant (Serviceverlener) Nadere specificaties Eigenschappen van een Serviceverlener in het algemeen: 1. Voor eindgebruikers is deze onzichtbaar; 2. Ontvangt berichten van de Bus a. Om gegevens hier te muteren; b. Om gegevens hier op te halen; c. Om processen hier te starten of te beïnvloeden. 3. Stuurt berichten uit aan de Bus met a. Mutatieresultaten van 2.a; b. Opvraagresultaten van 2.b. Het ontwerp van dit voorbeeld beschrijft bovenstaande eigenschappen, voor zover van toepassing. De scope van de telling is uitsluitend de Serviceverlener en de SOAcomponentgrens is rond deze serviceverlener getrokken. Eigenschappen (architectuureisen): 1. Alle functionaliteiten worden gebruikt via een Bus; 2. Er worden gebruikersgegevens hier vastgelegd en onderhouden; 3. Er worden berichten uitgewisseld op basis waarvan gebruikersgegevens hier worden gemuteerd of opgehaald. 4. De berichten zijn gespecificeerd in 3.5 Berichtspecificaties (BS). Het ontwerp bevat de volgende functionaliteiten (gebruikersfuncties): 1. Openen nieuwe rekening o Valideren berichtgegevens: relatie moet bestaan. Indien niet: bericht naar de Bus: BS4 Transactietype = N, Niet verwerkt: <reden>, einde verwerking. o Vastleggen nieuwe rekening: Rekening-ID, Rekeningnaam, Herkomst mutatie = Online o Bericht naar de Bus: BS4 Transactietype = N, OK. 3 Dit is de toe- of afname van de omvang. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 11

12 2. Wijzigen rekeninggegevens o Valideren berichtgegevens op basis van BS5: relatie en rekening moeten bestaan. o Wijzigen Rekeningnaam o.b.v. ontvangen bericht, Herkomst mutatie = Online; o Bericht naar de Bus: BS4 Transactietype = W, OK. 3. Opheffen rekening o Valideren berichtgegevens op basis van BS6: relatie en rekening moeten bestaan, saldo = 0, geen geagendeerde transacties, geen automatische incasso s. Indien validatie fout: bericht naar de Bus: BS4 Transactietype = O, Niet verwerkt: <reden>, einde verwerking o Verwijderen rekening Rekening-ID o Bericht naar de Bus: BS4 Transactietype = O, OK. 4. Opvragen gegevens rekeningen o Valideren berichtgegevens op basis van BS1: relatie en rekening moeten bestaan. Indien niet: bericht naar de Bus: BS4 Niet verwerkt: <reden>, einde verwerking o Bericht naar de Bus: BS10 5. Opvragen transactiegegevens rekeningen o Valideren berichtgegevens: Relatie en Rekening moeten bestaan. Indien niet: bericht naar de Bus: BS4 Niet verwerkt: <reden>, einde verwerking o Bericht naar de Bus: BS11 6. Bijwerken datamodel o Rekening: toevoegen attribuut Herkomst mutatie online/lokaal, standaardwaarde: Lokaal (hierdoor hoeven de rechtstreekse invoerfuncties niet te worden aangepast); o Overige entiteiten ongewijzigd 7. Conversie Rekening: off-scope Omvangbepaling We maken een globale projecttelling van de Serviceverlener. Functie KGV ILGV IF UF OF Opmerking Openen nieuwe rekening 4 Vastleggen in Rekening o.b.v. bericht BS3 Wijzigen rekeninggegevens 4 Wijzigen van Rekening o.b.v. bericht BS5 Opheffen rekening 4 Verwijderen van Rekening Opvragen gegevens algemeen Opvragen gegevens details o.b.v. bericht BS6 5 Relatiegegevens; Rekening(en) die de relatie heeft. Vullen bericht BS10 naar de Bus 5 Rekeninggegevens (ook saldo) en Transacties daarop. Vullen bericht BS11 naar de Bus Rekening 7 Attribuut toegevoegd Totalen (SFP) De retourberichten voor de invoerfuncties worden niet geteld, ze zijn niet elementair. De invoerberichten voor de uitvoerfuncties worden ook niet geteld. Deze zijn ook niet elementair. De transacties worden geteld op basis van [1: 7.2.d] (invoerfuncties) en [1: 8.2.b] (uitvoerfuncties). De Serviceverlener is gewijzigd: er is een ILGV gewijzigd en voor alle gebruikerstransacties is een variant met berichtafhandeling toegevoegd. Daardoor is de delta van productomvang van deze component 22 SFP. De ILGV is gewijzigd en telt dus niet mee in de delta. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 12

13 3.5 Berichtspecificaties (BS) 1. Vraag Rekeninghouder Gegevens : Relatie-ID 2. Toon Rekeninghouder Gegevens : Relatie-ID, Relatie-NAW, Rekeningenlijst : Rekening-ID, Rekeningnaam, Rekeningsaldo, <eventueel meer rekeningen> 3. Nieuwe rekening : Relatie-ID, Rekeningnaam 4. Mutatieresultaat : Relatie-ID, Transactietype (N/W/O), Resultaattekst ( OK / Niet verwerkt, <reden> ) 5. Wijzigen rekening : Relatie-ID, Rekening-ID, Rekeningnaam 6. Opheffen rekening : Relatie-ID, Rekening-ID 7. Transactielijst : Relatie-ID, Rekening-ID, Transactie-ID, Transactie-Datum, Transactie- Debet/credit, Transactie-Rekening van/naar, Transactie-Omschrijving, Transactie- Bedrag, <eventueel meer transacties> 8. Rekeningen : Relatie-ID 9. Transacties : Relatie-ID, Rekening-ID 10. Rekeningenlijst : Relatie-ID, Rekening-ID, Rekeningnaam, Rekeningsaldo, <eventueel meer rekeningen> 11. Transactielijst : Relatie-ID, Rekening-ID, Transactie-ID, Transactie-Datum, Transactie- Debet/credit, Transactie-Rekening van/naar, Transactie-Omschrijving, Transactie- Bedrag, <eventueel meer transacties> 3.6 Project MijnBankRekening De projecttellingen kunnen bij elkaar worden gezet. Functie KGV ILGV IF UF OF Opmerking Servicevrager (SFP) Bus (SFP) Serviceverlener (SFP) MijnBankRekening (SFP) Bij elkaar worden er dus 96 SFP geraakt. Let op: deze zijn geraakt in 3 verschillende projecten met elk hun eigen productiviteit. Wees dus voorzichtig met het optellen van projectomvangen! Vraag jezelf af waarom je dit wilt weten. 3.7 Product MijnBankRekening Het product dat is of wordt opgeleverd, ziet er voor de eindgebruiker als volgt uit: Figuur 2 SOA-product We beschouwen het systeem vanuit het Gebruiker-perspectief. Voor de gebruiker is het een wijziging op een monolithisch systeem: X1 toevoegen aan informatiesysteem X. Dit is dus gewoon FPA volgens [1]. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 13

14 Voor de volledigheid geven we deze telling hier. We tellen alleen de delta t.o.v. het oorspronkelijke systeem (zonder de internet-functionaliteit dus). Dat is de toegevoegde internet-functionaliteit (de Servicevrager), en de als gevolg hiervan toegevoegde of verwijderde ILGV s. Dat is het omkaderde deel X1. Pijl 1 representeert: 1. Openen nieuwe rekening (Nieuw); 2. Wijzigen rekeninggegevens (Nieuw); 3. Opheffen rekening (Nieuw). Pijl 2 representeert: 1. Opvragen gegevens algemeen (Nieuw); 2. Opvragen gegevens details (Nieuw). Onderdeel 3 representeert: 1. ILGV Rekening (Gewijzigd). De berichten van en naar de Bus overschrijden de systeemgrens niet (voor de gebruiker is dit een technische oplossing) en mogen dus niet worden geteld. Ook de ILGV wordt niet geteld omdat die niet nieuw of verwijderd is. Het telresultaat is als volgt: Functie KGV ILGV IF UF OF Opmerking Openen nieuwe rekening 4 Muteren inhoud van ILGV Rekening Wijzigen rekeninggegevens 4 Muteren inhoud van ILGV Rekening Opheffen rekening 4 Muteren inhoud van ILGV Opvragen gegevens algemeen Opvragen gegevens details MijnBankRekening (FP) Rekening 5 Relatiegegevens; Rekening(en) die de relatie heeft. Gevuld vanuit ILGV s Relatie en Rekening 5 Rekeninggegevens (ook saldo) en transacties daarop. Gevuld vanuit ILGV s Relatie, Rekening en Mutatie Dit zou het resultaat zijn van een producttelling vanaf schermen (het aangebouwde deel X1, zoals ervaren door de eindgebruiker). 3.8 Epiloog In de SOA-situatie zijn 3 deelprojecten geteld op basis van 3 van elkaar onafhankelijke ontwerpen. In totaal levert dat 91 project SFP op. Vanuit de applicatie is de delta voor het product geteld. Dat levert 22 product FP op. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 14

15 4 Minicasus MijnMailClient Deze minicasus beschrijft hybride SOA-componenten. Dit is de component Servicevrager die lokale ILGV s onderhoudt. 4.1 Functionele Specificaties (verkort) Een gebruiker kan thuis vanaf zijn PC berichten uitwisselen met personen en bedrijven. Berichten kunnen bestaan uit tekst, data en mediafragmenten, zoals documenten, beeld en geluid. Om deze functionaliteit aan de markt aan te kunnen bieden, wordt nieuwe functionaliteit ontwikkeld en, waar nodig, bestaande functionaliteit aangepast. Architectuur-eis is, dat dit volgens de SOA-principes wordt gedaan. Zie de figuur hieronder. Windows client Webserver Provider: server Figuur 3 Architectuur " systeem" Het systeem wordt gerealiseerd door het volgende deelprojecten onafhankelijk van elkaar uit te voeren: Voorkant : Servicevrager, client. Nieuwe applicatie door de eindgebruikers op hun PC te installeren; Bus : Aanpassen van de bus, zodat de voorkant en de achterkant efficiënt, snel en gestandaardiseerd met elkaar kunnen communiceren. Achterkant : Serviceverlener, server. Er zijn geen aanpassingen aan de server nodig. We beschouwen het systeem vanuit het Architectuurperspectief. We gaan eerst Projecttellingen maken en daarna een Producttelling van de Servicevrager en delta s daarvan van de Serviceverlener en de Bus. Van de laatste twee kunnen we geen volledige producttellingen maken omdat we de totale (baseline) specificaties daarvan niet hebben. 4.2 Deelproject Voorkant (Servicevrager) Nadere specificaties Deze wordt nieuw ontwikkeld. Eigenschappen van de Servicevrager ( client): Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 15

16 1. Dit is een User Interface (verzameling schermen waarmee zaken lokaal kunnen worden afgedrukt, opgevraagd of opgeslagen); 2. Stuurt verzoeken (berichten) uit a. Om gegevens elders te muteren; b. Om gegevens elders op te halen; c. Om processen elders te starten of te beïnvloeden. 3. Legt (ook) gegevens persistent vast binnen de client. Het ontwerp van dit voorbeeld beschrijft bovenstaande eigenschappen, voor zover van toepassing. De scope van de telling is uitsluitend de client en de SOA-componentgrens is rond deze client getrokken. Zie [1: en 3.6.1] (m.n. nieuwbouwproject). Eigenschappen (architectuureisen): 1. Alle functionaliteiten worden gebruikt lokaal en via internet of intranet; 2. Er worden gegevens lokaal persistent vastgelegd of onderhouden; 3. Er worden berichten uitgewisseld op basis waarvan gegevens elders worden gemuteerd of opgehaald. 4. De berichten zijn gespecificeerd in 4.5 Berichtspecificaties (BS). Het ontwerp bevat de volgende functionaliteiten (gebruikersfuncties): 1. Samenstellen nieuw bericht o Invoeren bericht: berichttekst; o Selecteren en koppelen bijlagen o.b.v. bestandssysteem; o Selecteren en koppelen geadresseerden o.b.v. lokale lijst; o Lokaal opslaan; o Verzenden met biometrie: vingerafdruk (optioneel). Bericht aan de Bus: BS1. 2. Wijzigen opgeslagen bericht o Tonen: opgeslagen berichten, per bericht ontvanger, datum, onderwerp; o Selecteren te wijzigen bericht; o Wijzigen bericht: tekst, bijlage(n), geadresseerde(n); o Lokaal opslaan; o Verzenden met biometrie: vingerafdruk (optioneel). Bericht aan de Bus: BS1. 3. Verwijderen opgeslagen bericht o Tonen: opgeslagen berichten; o Selecteren te verwijderen bericht; o Verwijderen inclusief gekoppelde bijlagen als die er zijn. 4. Tonen ontvangen en verzonden berichten o Ontvangen is opgehaald en lokaal opgeslagen; o Tonen: per bericht afzender, ontvanger, datum, onderwerp; o Selecteren te bekijken bericht; o Tonen: volledig bericht. 5. Tonen te ontvangen berichten o Te ontvangen bericht is nog niet opgehaald; o Tonen: per bericht afzender, datum, onderwerp, bijlagen j/n; o Selecteren te ontvangen bericht; o Ophalen met biometrie: vingerafdruk en lokaal opslaan bericht na virus- en spam-controle (optioneel). Ophalen is een bericht van de Bus: BS2. 6. Werken met contacten o Tonen contacten; o Aanmaken nieuw contact; o Wijzigen contactgegevens; o Verwijderen contact; o Lokaal opgeslagen lijst. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 16

17 4.2.2 Omvangbepaling We maken een projecttelling van de client. Functie KGV ILGV IF UF OF Opmerking 1. Samenstellen nieuw bericht Samenstellen nieuw 7 4 ILGV Bericht bericht Selecteren en koppelen bijlagen Selecteren en koppelen geadresseerden Verzenden 2. Wijzigen opgeslagen bericht Tonen opgeslagen berichten Gekoppelde bijlagen wordt bijgewerkt (Is RET van Bericht). Lijst van mogelijke bijlagen, getoond m.b.v. lokaal bestandssysteem. Koppelen zelf is het doel Gekoppelde geadresseerden wordt bijgewerkt (Is RET van Bericht). ILGV Contacten. Lijst van mogelijke geadresseerden. Koppelen zelf is he doel. Niet elementair. Onderdeel van Samenstellen nieuw bericht. 0 5 ILGV s al geteld. Lijst van opgeslagen berichten (bericht-headers). Selecteren te wijzigen bericht Niet elementair. Onderdeel van Wijzigen bericht. Wijzigen bericht 0 4 ILGV s al geteld. Opslaan of verzenden Niet elementair. Onderdeel van Wijzigen bericht. 3. Verwijderen opgeslagen bericht Tonen opgeslagen berichten Al eerder geteld onder Wijzigen opgeslagen berichten. Selecteren te verwijderen bericht Verwijderen 0 4 ILGV s al geteld. 4. Tonen ontvangen en verzonden berichten Tonen ontvangen en verzonden berichten Niet elementair. Onderdeel van Verwijderen bericht. 5 Anders dan Tonen opgeslagen berichten: extra attribuut (Afzender). Selecteren te bekijken bericht Tonen volledig bericht 0 5 ILGV s al geteld. 5. Tonen te ontvangen berichten Niet elementair. Onderdeel van Tonen: volledig bericht. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 17

18 Functie KGV ILGV IF UF OF Opmerking Tonen te ontvangen berichten 5 Gegevens extern ophalen, niet afkomstig uit ILGV s. Selecteren te ontvangen bericht Niet elementair. Onderdeel van Ophalen en lokaal Ophalen en lokaal opslaan bericht opslaan bericht. 0 4 ILGV s al geteld. Virus- en spam-controle zijn niet elementair. 6. Werken met contacten Tonen contacten 0 Al geteld bij Selecteren en koppelen geadresseerden Aanmaken nieuw contact 0 4 ILGV al geteld. Wijzigen contactgegevens Verwijderen contactgegevens 0 4 ILGV al geteld. 0 4 ILGV al geteld. Totalen (SFP) Er worden ILGV s geteld omdat ze binnen deze componentgrens persistent aanwezig zijn. Er zijn geen KGV s omdat de architectuur directe koppelingen met andere systemen uitsluit. De client is geheel nieuw. Daardoor is de productomvang van dit component, net als de projectomvang, 80 SFP. Dit ontwerp bevat geen elementaire functies die niet volledig voldoen aan de definities in [1]. Het kan dus ook volledig met [1] worden geteld. Die telling zal hetzelfde aantal FP opleveren. 4.3 Deelproject Bus Nadere specificaties Deze bestaat en wordt aangepast. Eigenschappen van de Bus: 1. Voor eindgebruikers is deze onzichtbaar; 2. Stuurt berichten (verzoeken) uit a. Om op verzoek van de client gegevens elders (bij de server) te muteren; b. Om op verzoek van de client gegevens elders (bij de server) op te halen; c. Om processen elders te starten of te beïnvloeden. 3. Stuurt berichten uit met a. Mutatieresultaten aan de client; b. Opgehaalde gegevens aan de client. 4. Kan een User Interface hebben a. Om het correct functioneren van de Bus te waarborgen; b. Voor beheerders van de Bus. 5. Legt gegevens persistent vast voor het correct functioneren van de Bus. 6. Legt geen gegevens persistent vast die content-specifiek zijn, dus niet van belang zijn voor het functioneren van de Bus. Het ontwerp van dit voorbeeld beschrijft bovenstaande eigenschappen, voor zover van toepassing. De scope van de telling is uitsluitend de functionaliteit van de Bus nodig om de e- mail client en server te laten functioneren zoals bedoeld. De benodigde berichttypen zijn alle nieuw voor de Bus die op zich al bestaat. De SOA-Componentgrens is rond dit deel van de Bus getrokken. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 18

19 Het ontwerp bevat de volgende functionaliteiten (gebruikersfuncties): 1. Ontvangen gegevens van de client (nieuw) o Bericht BS1 (nieuw: biometrie). 2. Doorsturen gegevens naar de server (ongewijzigd) o Bericht Verzonden bericht (ongewijzigd). 3. Ontvangen mutatieresultaten van de server (ongewijzigd) a. Bericht Mutatieresultaat : Niet afgeleverd, <reden>, Gelezen, Geopend ). 4. Doorsturen mutatieresultaten naar de client (ongewijzigd) o Bericht Mutatieresultaat : Niet afgeleverd, <reden>, Gelezen, Geopend ). 5. Ontvangen verzoek om gegevens van de client (nieuw) o Bericht BS2 (nieuw: biometrie). 6. Doorsturen verzoek om gegevens naar de server (ongewijzigd) o Bericht Verzoek Te ontvangen berichten. 7. Ontvangen gebruikersgegevens van de server (ongewijzigd) o Bericht Berichtdetails : per bericht afzender, datum, onderwerp, berichttekst, bijlagen, andere ontvangers. 8. Terugsturen gebruikersgegevens naar de client (ongewijzigd) o Bericht Berichtdetails : per bericht afzender, datum, onderwerp, berichttekst, bijlagen, andere ontvangers. De Bus haalt het biometrie-attribuut uit de berichten van de client, zodat het standaardbericht naar de server kan worden gestuurd. Eigenschappen (architectuureisen): 1. Alle functionaliteiten worden gebruikt via de operationele Bus; 2. Er worden geen gebruikersgegevens persistent in de Bus vastgelegd of daar onderhouden; 3. Er worden berichten uitgewisseld op basis waarvan gebruikersgegevens elders worden gemuteerd of opgehaald en die eventueel worden terug geleverd aan de Servicevrager. 4. De berichten zijn gespecificeerd in 4.5 Berichtspecificaties (BS) Omvangbepaling We maken een telling van het relevante deel van de Bus. Functie KGV ILGV IF UF OF Opmerking 2. Doorsturen gegevens 5 Invoerdeel hiervan (1. naar de server Ontvangen gegevens van 6. Doorsturen verzoek om gegevens naar de e- mail server Totalen (SFP) de client) gewijzigd. 5 Invoerdeel hiervan (5. Ontvangen verzoek om gegevens van de client) gewijzigd. Er worden geen ILGV s geteld omdat ze binnen deze componentgrens niet persistent aanwezig zijn. Er zijn ook geen KGV s omdat de architectuur directe koppelingen met andere systemen uitsluit. Zie het kader op blz. 9. De functionaliteiten 1 en 5 zijn niet elementair. Het zijn de invoerdelen van respectievelijk de functionaliteiten 2 en 6 (verzonden berichten). Dit zijn de doelen van deze combinaties. De Bus is gewijzigd (berichtverwerkingen gewijzigd). Daardoor is de delta 4 van productomvang van deze component 0 SFP. 4.4 Deelproject Achterkant (Serviceverlener) Nadere specificaties 4 Dit is de toe- of afname van de omvang. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 19

20 Niet nodig, er zijn geen wijzigingen bij de server Omvangbepaling Er is geen globale telling nodig van de server. 4.5 Berichtspecificaties (BS) 1. Verzonden bericht : Afzender_ , Geadresseerde_ , DatumTijd, Onderwerp, Berichttekst, Bijlage(n), Biometrie 2. Te ontvangen berichten : Afzender_ , DatumTijd, Onderwerp, bijlagen j/n 4.6 Project MijnMailClient De tellingen kunnen bij elkaar worden gezet. Functie KGV ILGV IF UF OF Opmerking client (SFP) Bus (SFP) server (SFP) 0 MijnMailClient (SFP) Bij elkaar worden er dus 90 SFP geraakt. Let op: deze zijn geraakt in 2 verschillende projecten met elk hun eigen productiviteit. Wees dus voorzichtig met het optellen van projectomvangen! Vraag jezelf af waarom je dit wilt weten. 4.7 Product MijnMailClient Het product dat is of wordt opgeleverd, ziet er voor de eindgebruiker als volgt uit: Figuur 4 SOA-product We beschouwen het systeem vanuit het Gebruiker-perspectief. Voor de gebruiker is het een nieuw monolithisch systeem. Dit is dus gewoon FPA volgens [1]. Voor de volledigheid geven we deze telling hier. We tellen alleen de nieuwe client (de Servicevrager), en de als gevolg hiervan toegevoegde of verwijderde ILGV s. Pijl 1 representeert: 1. Samenstellen nieuw bericht (Nieuw); Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 20

21 2. Wijzigen opgeslagen bericht (Nieuw); 3. Verwijderen opgeslagen bericht (Nieuw); 4. Werken met contacten (Nieuw). Pijl 2 representeert: 1. Tonen ontvangen en verzonden berichten (Nieuw); 2. Tonen te ontvangen berichten (Nieuw). Onderdeel 3 representeert: 1. ILGV s Bericht, Contact (alle Nieuw). De berichten van en naar de Bus overschrijden de systeemgrens niet (voor de gebruiker is dit een technische oplossing) en mogen dus niet worden geteld. De ILGV s worden geteld omdat die nieuw zijn. Het telresultaat is als volgt: Functie KGV ILGV IF UF OF Opmerking 1. Samenstellen nieuw bericht Samenstellen nieuw bericht 7 4 ILGV Bericht Selecteren en koppelen bijlagen Gekoppelde bijlagen wordt bijgewerkt (Is RET van Bericht). Lijst van mogelijke bijlagen, getoond m.b.v. lokaal bestandssysteem. Koppelen zelf is het doel. Selecteren en koppelen geadresseerden Verzenden Gekoppelde geadresseerden wordt bijgewerkt (Is RET van Bericht). ILGV Contacten. Lijst van mogelijke geadresseerden. Koppelen zelf is he doel. Niet elementair. Onderdeel van Samenstellen nieuw bericht. 2. Wijzigen opgeslagen bericht Tonen opgeslagen berichten 0 5 ILGV s al geteld. Lijst van opgeslagen berichten (berichtheaders). Selecteren te wijzigen bericht Niet elementair. Onderdeel van Wijzigen bericht. Wijzigen bericht 0 4 ILGV s al geteld. Opslaan of verzenden 3. Verwijderen opgeslagen bericht Tonen opgeslagen berichten Selecteren te verwijderen bericht Niet elementair. Onderdeel van Wijzigen bericht. Al eerder geteld onder Wijzigen opgeslagen berichten. Niet elementair. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 21

22 Functie KGV ILGV IF UF OF Opmerking Onderdeel van Verwijderen bericht. Verwijderen 0 4 ILGV s al geteld. 4. Tonen ontvangen en verzonden berichten Tonen ontvangen en verzonden berichten Selecteren te bekijken bericht 5 Anders dan Tonen opgeslagen berichten: extra attribuut (Afzender). Niet elementair. Onderdeel van Tonen: volledig bericht. Tonen volledig bericht 0 5 ILGV s al geteld. 5. Tonen te ontvangen berichten Tonen te ontvangen berichten 5 Gegevens extern ophalen, niet afkomstig uit ILGV s. Selecteren te ontvangen bericht Niet elementair. Onderdeel van Ophalen en lokaal opslaan bericht. Ophalen en lokaal opslaan bericht 0 4 ILGV s al geteld. Virus- en spamcontrole zijn niet elementair. 6. Werken met contacten Tonen contacten 0 Al geteld bij Selecteren en koppelen geadresseerden Aanmaken nieuw contact 0 4 ILGV al geteld. Wijzigen contactgegevens 0 4 ILGV al geteld. Verwijderen contactgegevens 0 4 ILGV al geteld. Totalen (FP) Dit is het resultaat van een telling vanaf schermen (de applicatie, zoals ervaren door de eindgebruiker). 4.8 Epiloog In de SOA-situatie zijn 2 deelprojecten geteld op basis van 2 van elkaar onafhankelijke ontwerpen. In totaal levert dat 90 project SFP op. Vanuit de applicatie (het perspectief van de gebruiker) is het product geteld. Dat levert 80 product FP op. Functional Sizing in een SOA-omgeving - voorbeelduitwerkingen Pagina 22