Casus GreenWheels
In4029 Information Systems Engineering Delft, december 2001 Remco Groeneweg Mark Dumay Joost van Evert
2
Voorwoord Dit rapport is gemaakt in het kader van het vierdejaarscollege Information Systems Engineering dat deel uit maakt van het keuzeprogramma van de studie Technische Informatica. Dit vak, dat gegeven wordt in twee blokken van elk 7 colleges, gaat in op de huidige ontwikkelingen op het gebied van het ontwerpen en implementeren van informatiesystemen. In dit rapport wordt de casus GreenWheels behandeld. Doel van deze casus is het opleveren van een volledig functioneel ontwerp van de gedistribueerde systemen van GreenWheels. Dit functionele ontwerp moet als basis dienen voor een technisch ontwerp. Mark Dumay Joost van Evert Remco Groeneweg Delft, december 2001.
3
4
Inhoudsopgave 1
INLEIDING............................................................................................................... 7 1.1 1.2 1.3
2
OPDRACHTGEVER ................................................................................................ 7 AANLEIDING ........................................................................................................ 7 WERKWIJZE ......................................................................................................... 7
PROBLEEMANALYSE........................................................................................... 9 2.1 GLOBALE PROBLEEMDEFINITIE ............................................................................ 9 2.1.1 Doel............................................................................................................. 9 2.1.2 Scope ........................................................................................................... 9 2.2 BEDRIJFSANALYSE ............................................................................................... 9 2.2.1 Inleiding tot DEMO .................................................................................... 9 2.2.2 DEMO transactiemodel ............................................................................ 10 2.2.3 Afbakening ................................................................................................ 11 2.2.4 Analyse van de transacties........................................................................ 11 2.3 HUIDIGE SITUATIE .............................................................................................. 13
3
SYSTEEMDEFINITIE........................................................................................... 15 3.1 FUNCTIONELE EISEN .......................................................................................... 15 3.2 NIET-FUNCTIONELE EISEN .................................................................................. 19 3.2.1 Prestatie .................................................................................................... 20 3.2.2 Kwaliteit.................................................................................................... 20 3.2.3 Kosten ....................................................................................................... 20 3.2.4 Onderhoud ................................................................................................ 21 3.2.5 Gebruikers................................................................................................. 21
4
SYSTEEM ONTWERP.......................................................................................... 23 4.1 GLOBALE ARCHITECTUUR ................................................................................. 23 4.2 GEGEVENSARCHITECTUUR ................................................................................. 24 4.2.1 Inleiding .................................................................................................... 24 4.2.2 Datamodel................................................................................................. 24 4.2.3 Business rules............................................................................................ 28 4.3 APPLICATIEARCHITECTUUR ............................................................................... 29 4.3.1 Communicatiepatronen............................................................................. 30 4.3.2 Componenten ............................................................................................ 34
5
CONCLUSIE........................................................................................................... 37
5
6
1
Inleiding
Dit rapport beschrijft alle stappen in het ontwerpproces van een gedistribueerd informatiesysteem voor GreenWheels. Het rapport werkt toe naar een functioneel ontwerp, dat als basis zal dienen voor een technisch ontwerp. In dit eerste hoofdstuk zullen eerst de opdrachtgever, aanleiding en manier van werken uiteengezet worden.
1.1
Opdrachtgever
De opdrachtgever is de firma GreenWheels. GreenWheels is een landelijk opererende organisatie die bedrijven en gezinnen de mogelijkheid biedt om op basis van lidmaatschap een auto op afroep te gebruiken. De auto staat in de directe omgeving van de gebruiker en kan telefonisch gereserveerd worden. Het hoofdkantoor van GreenWheels staat in Amsterdam, alwaar de administratie wordt gedaan. GreenWheels is op internet te vinden op het adres: http://www.greenwheels.nl.
1.2
Aanleiding
De aanwezige systemen bij GreenWheels zijn niet of nauwelijks geïntegreerd waardoor vele administratieve zaken nog met de hand moeten worden gedaan. Dit brengt onnodige kosten met zich mee. Door te investeren in een geïntegreerd geautomatiseerd systeem wil GreenWheels deze kosten terugdringen.
1.3
Werkwijze
Om tot het gewenste systeem te komen is globaal het volgende traject gekozen: 1. Probleemanalyse: In deze fase wordt de organisatie in kaart gebracht. Hiervoor zal de methodiek DEMO gebruikt worden. Toelichting op de keuze voor deze methodiek is te vinden in het betreffende hoofdstuk. Met behulp van DEMO zullen de bedrijfsprocessen van GreenWheels worden geanalyseerd. 2. Systeemdefinitie: In deze fase zal de functionaliteit van het te bouwen systeem formeel vastgelegd worden. Dit zal worden gedaan aan de hand van UML Use Case modellen. Deze systeemdefinitie vormt de basis voor de volgende fase. 3. Systeemontwerp: De invulling van de systeemdefinitie zal worden gedaan in de vorm van een systeemontwerp. Er zal een datamodel worden gemaakt, een architectuurspecficatie, etc. Voor de modellen wordt wederom UML gebruikt. De uitwerking van dit traject is in de volgende hoofdstukken terug te vinden.
7
8
2
Probleemanalyse
In dit hoofdstuk zal het probleemdomein geanalyseerd worden. Dit gebeurt door de bedrijfsprocessen van de organisatie in kaart te brengen. Aangezien informatiesystemen dienen om de bedrijfsprocessen van een organisatie te ondersteunen is het van belang een helder beeld te hebben van deze bedrijfsprocessen.
2.1
Globale probleemdefinitie
In deze paragraaf wordt een globale schets van het probleemdomein gegeven. Dit gebeurt door eerst het doel van het project toe te lichten, waarna vervolgens de scope, zoals overeengekomen met de opdrachtgever, uiteen wordt gezet. 2.1.1 Doel Doel van het project is een gedistribueerd systeem dat het auto op afroep concept economisch rendabel maakt. Hiervoor dient de autouitgifte volledig geautomatiseerd te worden en gekoppeld te worden aan de reeds aanwezige systemen. Het systeem moet voor de klanten van GreenWheels zo eenvoudig mogelijk in het gebruik zijn. 2.1.2 Scope Het project beperkt zich tot de integratie van de interne systemen van GreenWheels. Deze interne systemen dienen ter ondersteuning van de primaire bedrijfsprocessen van GreenWheels. Er zullen geen systemen gebouwd worden die GreenWheels toegang geeft tot externe systemen van gerelateerde organisaties.
2.2
Bedrijfsanalyse
In deze paragraaf wordt de organisatie GreenWheels in kaart gebracht met behulp van de methodiek DEMO. Het resultaat vormt de basis voor verdere analyse. Er zal eerst een korte inleiding gegeven worden tot DEMO, voor verdere informatie verwijzen wij naar de relevante literatuur [2]. Na het in kaart brengen van de verschillende bedrijfsprocessen binnen GreenWheels zal bepaald worden welke bedrijfsprocessen door een door ons te bouwen informatiesysteem zullen worden ondersteund. 2.2.1 Inleiding tot DEMO De eerste stap in het bouwen van een informatiesysteem is het in kaart brengen van de bedrijfsprocessen. Het te bouwen informatiesysteem dient immers ter ondersteuning van de bedrijfsprocessen van de betreffende organisatie. Zo’n blauwdruk van de bedrijfsprocessen dient als basis voor de communicatie tussen opdrachtgever en uitvoerder. Tevens is het voor de uitvoerder van groot belang om tot een goed begrip te komen van de organisatie waarvoor een informatiesysteem gebouwd gaat worden.
9
Er zijn voor het modelleren van organisaties vele methodieken op de markt. Bekendste zijn de op DFD ofwel Data Flow Diagrams gebaseerde methoden zoals IDEF0. Groot nadeel van deze methodieken is dat ze vaak geen sluitende definities hebben over wat wel en wat niet in het model weergegeven dient te worden. Derhalve zal voor GreenWheels een geheel andere methodiek gebruikt gaan worden: DEMO. Deze methodiek is erg geschikt om relatief snel de kern van een organisatie ofwel de essentiële bedrijfsprocessen zichtbaar te maken. DEMO staat voor Dynamic Essential Modelling of Organizations. Ze is gebaseerd op het principe dat een organisatie een keten van afspraken tussen mensen is. Een transactie is de cyclus van het maken van een afspraak, het uitvoeren van de gemaakte afspraak en het accepteren van het resultaat. DEMO brengt een organisatie in kaart in termen van deze transacties. Een belangrijk DEMO gedachtengoed is dat de wereld te onderscheiden is in 3 verschillende niveaus, namelijk het essentiële (of B- van Business) niveau, het informationele (I-) niveau en het documentele (D-) niveau. Het essentiële niveau is hierboven al besproken: dit is de wereld van de afspraken en de feiten. Het I-niveau is het niveau van de informatie over afspraken en feiten. Het documentele niveau tot slot houdt zich bezig met de forma, ofwel de manier waarop de informatie uit het I-niveau wordt opgeslagen. Het belangrijkste diagram in DEMO is het interactiemodel. In dit model zijn de essentiële bedrijfsprocessen weergegeven als transacties, inclusief de betrokken actoren. Een actor is een persoon die een bepaalde rol vervult. Het interactiemodel laat de interactie tussen de organisatie en de externe actoren zien. Het gedetailleerde interactiemodel maakt daarbij ook nog de betrokken interne actoren zichtbaar. 2.2.2 DEMO transactiemodel In figuur 2-1 is een gedetailleerd interactiemodel van GreenWheels te zien. Bij GreenWheels zijn acht transacties te onderscheiden zoals vermeld in tabel 2-1. Transactie T1 Inschrijven T2 Reserveren
Initiator S1 S1
Executor A1 A2
T3 UitgevenAuto
A6
S1
T4 BetalenGebruik
A3
S1
T5 Schadeafhandeling
A4
S1
T6 Tankafhandeling
S2
A5
T7 Uitschrijven S1 T8 Verwerken- A4 Betalingsopdracht
A1 S3
10
Resultaat Klant <S1> is ingeschreven. Klant <S1> heeft auto C gereserveerd. AutoUitgever
heeft aan klant <S1> auto C uitgegeven. Klant <S1> heeft het gebruik van auto C betaald. Klant <S1> heeft de schade aan auto C betaald. Tank Afhandelaar heeft brandstof aan Pomphouder <S2> betaald. Klant <S1> is uitgeschreven. BetalingsOpdracht B is verwerkt.
tabel 2-1 Transactie tabel
figuur 2-1 Gedetailleerd Interactie model van GreenWheels
2.2.3 Afbakening In paragraaf 2.1.2 is reeds opgemerkt dat het project zich beperkt tot de interne systemen van GreenWheels. Concreet betekent dit dat het te bouwen informatiesysteem de transacties T1(Inschrijven), T7 (Uitschrijven), T2 (Reserveren), T3 (Uitgeven Auto) en T4(Betalen Gebruik) zal ondersteunen. Het betreft in alle gevallen transacties tussen GreenWheels en de klant. In het volgende hoofdstuk zijn de UML use case modellen ter ondersteuning van deze transacties te vinden. 2.2.4 Analyse van de transacties Om de functionaliteit van het te bouwen informatiesysteem te kunnen beschrijven moeten de verschillende transacties nader geanalyseerd worden. Vanuit het oogpunt dat informatiesystemen dienen ter ondersteuning van een transactie (met de informatiesystemen op het I-niveau en een gedeelte van het D-niveau), is het van belang een goed begrip te krijgen van wat er bij elke transactie op de verschillende niveaus
11
gebeurt. In de volgende tabellen is dit beknopt weergegeven: de bovenste cel correspondeert met het essentiële (B-) niveau, de middelste cel met het informationele (I) niveau en tot slot de onderste cel met het documentele (D-) niveau. T1 Inschrijven Initiator: Klant <S1> Executor: Registrar Resultaat: Klant <S1> is ingeschreven als abonnee. Klant <S1>: volledige naam, volledige adres, geslacht, telefoon (privé, werk, mobiel), email, leeftijd, soort abonnement (Bel&Rij/Bel&RijPlus) Registrar : 4-cijferig nummer Paspartoe, pincode. Paspartoe 1-malige machtiging Kopie geldig rijbewijs Kopie geldig paspoort Kopie reductiepas Borg Klantenregister tabel 2-2 Transactieanalyse T1 Inschrijven
T7 Uitschrijven Initiator: Klant <S1> Executor: Registrar Resultaat: Klant <S1> is uitgeschreven als abonnee. Klant <S1>: Registrar : Borg Klantenregister tabel 2-3 Transactieanalyse T7 Uitschrijven
T2 Reserveren Initiator: Klant <S1> Executor: Reserveerder Resultaat: Klant <S1> heeft auto C gereserveerd. Klant <S1>: Gewenst tijdvak Reserveerder : Beschikbare tijdvakken Telefoon Planning rooster in een relationele database tabel 2-4 Transactieanalyse T2 Reserveren
T3 Uitgeven Auto Initiator: AutoUitgever Executor: Klant <S1> Resultaat: AutoUitgever heeft aan klant <S1> auto C uitgegeven. 12
AutoUitgever : deblokkeer signaal Klant <S1>: start tijd Boordcomputer auto C tabel 2-5 Transactieanalyse T3 Uitgeven Auto
T4 Betalen Gebruik Initiator: Financiële administratie Executor: Klant <S1> Resultaat: Klant <S1> heeft het gebruik van auto C betaald. Klant <S1>: rekeningnummer Financiële administratie : Kosten voor autogebruik Betalingsdiskette tabel 2-6 Transactieanalyse T4 Betalen Gebruik
2.3
Huidige situatie
In de huidige situatie zijn de volgende systemen aanwezig: • Een website om (potentiële) klanten te voorzien van informatie; • De boordcomputers in de auto’s van de GreenWheels vloot; • Het planningsrooster in een relationele database. Bij het ontwerptraject zal gekeken worden naar de mogelijke integratie van bovenstaande systemen.
13
14
3
Systeemdefinitie
In dit hoofdstuk zal de functionaliteit van het te bouwen systeem vastgelegd worden. Allereerst worden de functionele eisen gedefinieerd middels UML uses cases. Vervolgende worden de niet-functionele eisen, ofwel randvoorwaarden, toegelicht.
3.1
Functionele eisen
In deze paragraaf wordt het UML use case model van het systeem besproken. Dit model is weergegeven in figuur 3-1. In totaal zijn er vijf verschillende actoren weergegeven, waaarbij een actor een rol van een systeemgebruiker weergeeft. De verschillende use cases zijn uitwerkingen van de DEMO transacties uit paragraaf 2.2.2. De vijf packages corresponderen met het overeenkomende transactienummer.
figuur 3-1 UML use case diagram GreenWheels
In de tabellen 3.2 tot en met 3.9 worden de diverse use cases nader toegelicht. In tabel 3-1 staat een uitleg van deze tabellen. Onderdeel ID
Naam
Omschrijving Identificerende naam, waarmee in andere modellen aan deze Use Case gerefereerd kan worden. De naamgevingsconventie is dat de ID van een Use Case begint met UC, waaraan een zelfstandig naamwoord of werkwoord wordt toegevoegd. Een naam voor de Use Case, waarin in de vorm van een actief 15
Doel Samenvatting Voorwaarde(n) Resulta(a)t(en) bij succes Resulta(a)t(en) bij falen Performance Actor(en) Trigger Scenario
werkwoord duidelijk wordt omschreven, welke taak met deze Use Case wordt gemodelleerd. Welk doel moet worden bereikt met deze Use Case in relatie tot het totale probleemdomein? Een korte omschrijving van de functionaliteit die door deze Use Case wordt gemodelleerd. In dit onderdeel worden de voorwaarden omschreven die moeten gelden voordat gebruik wordt gemaakt van de in deze Use Case beschreven functionaliteit. Wat is er veranderd nadat de in deze Use Case beschreven taak is uitgevoerd? De in een Use Case beschreven taak wordt niet altijd succesvol afgerond. In dit blok wordt beschreven wat er is veranderd aan het einde van de Use Case, als de beschreven taak vanwege een uitzondering niet succesvol wordt afgerond. Als performance eisen worden gesteld aan de reactie van het systeem of een actor, dan kan dat hier worden beschreven. Een korte omschrijving van het subject dat de beschreven taak uitvoert. Wat veroorzaakt het starten van de beschreven taak? In het basisscenario wordt omschreven hoe actor en systeem met elkaar communiceren om een taak uit te voeren. Het systeem blijft dus een black box: er wordt niet beschreven hoe het systeem een taak uitvoert. Stap Sequentieel genummerde stappen Actor Degene die de beschreven stap uitvoert (Als actor kan in dit geval ook het systeem zelf optreden). Beschrijving Wat doet de actor (of het systeem) in deze stap?
tabel 3-1 Uitleg bij de verschillende onderdelen van de use case tabel ID Naam Doel Samenvatting
UC_Inschrijven Inschrijven nieuwe klant Klanten inschrijven De gegevens van het inschrijfformulier van de aankomende klant worden ingevoerd in de computer, vervolgens wordt de borg geïnd
Voorwaarden Resulta(a)t(en) Klantgegevens van de nieuwe abonnee zijn ingevoerd bij succes Machtiging is geschied Borg is geïnd Resulta(a)t(en) bij falen Performance Actor(en) Administrateur Trigger Klant
16
Scenario tabel 3-2 Use case UC_Inschrijven ID Naam Doel Samenvatting
UC_WijzigenKlant Wijzigen klantgegevens Het wijzigen of invoeren van klantgegevens systeem De volgende gegevens kunnen verwerkt worden: -gegevens klant -gegevens informatieaanvrager
in
het
op
een
Voorwaarden Resulta(a)t(en) bij succes Resulta(a)t(en) bij falen Performance Actor(en) Administrateur Trigger Klant Scenario tabel 3-3 Use case UC_WijzigenKlant ID Naam Doel Samenvatting Voorwaarde
UC_NieuweReservering Nieuwe reservering Het reserveren van een bepaald tijdstip
auto
voor
een
klant
Er is een auto beschikbaar is voor gegeven tijdspanne en uitgave punt Resulta(a)t(en) De reservering is toegevoegd aan de database die het bij succes rooster bevat. Resulta(a)t(en) bij falen Performance Actor(en) Reserveerder Trigger Klant Scenario tabel 3-4 Use case UC_ NieuweReservering ID Naam Doel
UC_WijzigReservering Wijzig reservering Een bestaande reservering worden.
dient
gewijzigd
te
kunnen
Samenvatting Voorwaarde De auto is beschikbaar gedurende de nieuwe tijdspanne Resulta(a)t(en) bij succes Resulta(a)t(en) bij falen Performance Actor(en) Reserveerder Trigger Klant Scenario
17
tabel 3-5 Use case UC_ WijzigReservering ID Naam Doel Samenvatting Voorwaarden
UC_OphalenAuto Ophalen auto De auto ter beschikking stellen aan de klant
Het voorgehouden paspartoe komt overeen met het paspartoe waarvoor een reservering in het planningsrooster voor deze auto op dit moment staat. De auto is geblokkeerd. Resulta(a)t(en) De autodeuren en de sleutelkluis zijn open. bij succes De startonderbreking is gedeactiveerd. De beginkilometerstand is naar het systeem verzonden. Resulta(a)t(en) Als de GSM verbinding onderbroken wordt, zal de bij falen transactie afgebroken worden. De auto gaat niet open en de beginkilometerstand wordt niet doorgegeven. Performance 1 tot 10 seconden Actor(en) Klant Trigger Paspartoe onder scanner bij geblokkeerde auto Scenario 1. De klant houdt zijn paspartoe voor de scanner. 2. De auto vraagt of hij nu voor dit paspartoe gereserveerd is aan de roosterdatabase. 3. Indien de auto voor deze klant gereserveerd is: wordt de beginkilometerstand naar het systeem verzonden, zendt het systeem de pincode van de gebruiker naar de auto en gaan tenslotte de deuren open. 4. De klant toetst zijn pincode in. 5. Wanneer de pincode correct is wordt de startblokkering gedeactiveerd en de sleutelkluis geopend. tabel 3-6: Use case UC_OphalenAuto ID Naam Doel Samenvatting Voorwaarden
UC_TerugbrengenAuto Terugbrengen auto Auto blokkeren en roosterdatabase Ritkosten rapporteren.
weer
beschikbaar
maken
in
Het paspartoe van de laatste klant van deze auto wordt voorgehouden. De laatste klant zijn reservering hoeft nog niet afgelopen te zijn. Resulta(a)t(en) De startonderbreking is geactiveerd. bij succes De sleutelkluis en de autodeuren zijn dicht. De eindkilometerstand is verzonden naar het systeem. De auto is weer beschikbaar in de roosterdatabase. Resulta(a)t(en) bij falen Performance Actor(en) Klant Trigger Paspartoe onder scanner bij gedeblokkeerde auto Scenario 1. De klant houdt zijn paspartoe voor de scanner 2. De boordcomputer verstuurd dit nummer naar het
18
systeem. 3. Het systeem kijkt bij welke reservering dit paspartoenummer hoort. 4. Het systeem maakt een factuur aan op basis van de gegevens uit de reservering en de kilometerstand. tabel 3-7 Use case UC_ TerugbrengenAuto ID Naam Doel
UC_VersturenBetalingsopdrachten Verstuur betalingsopdrachten Het afschrijven van de kosten van het autogebruik van de rekening van een klant
Samenvatting Voorwaarden Resulta(a)t(en) Betalingsopdrachten voor kilometers en abonnementen zijn bij succes verzonden aan de bank. Resulta(a)t(en) bij falen Performance Actor(en) Medewerker Trigger Maandelijks Scenario tabel 3-8 Use case UC_ VersturenBetalingsopdrachten
Deze use case (tabel 3-8) zal verder niet uitgewerkt worden, slechts het factureren zal ondersteund worden in het te bouwen systeem. Dit factureren vindt plaats na UC_TerugbrengenAuto. Naam UC_SchrijfKlantUit Doel Beëindiging lidmaatschap Samenvatting Voorwaarden De klant is abonnee Resulta(a)t(en) Klant is uitgeschreven. bij succes De borg is geretourneert geïncasseerd is. Paspartoe is gedeactiveerd. Resulta(a)t(en) bij falen Performance Actor(en) Administrateur Trigger Klant Scenario
indien
deze
niet
reeds
tabel 3-9 Use case UC_ SchrijfKlantUit
3.2
Niet-functionele eisen
De niet-functionele eisen worden opgedeeld in vijf verschillende groepen: prestatie, beschikbaarheid, kosten, onderhouds en gebruikers eisen. Elk wordt hieronder nader toegelicht.
19
3.2.1 Prestatie De prestatie-eisen die aan het Greenwheels systeem gesteld worden, verschillen binnen het systeem. De responstijd voor interactie met het systeem dient onder de twee seconden te blijven. Uitzondering op deze regel is het openen en afhalen van de auto, hiervoor is tien seconden responstijd de limiet. Deze langere responstijd voor het openen en afhalen van de auto wordt veroorzaakt door de GSM verbinding tussen de auto en de centrale server.De doorvoer van het systeem wordt uitgedrukt in transacties per minuut. Aangezien er een centraal systeem bestaat voor geheel Nederland, is dit gesteld op een aantal van 20. Responstijd Doorvoer
2 seconden (globaal systeem) 10 seconden (auto) 20 communicatieberichten per minuut tussen auto en systeem. 3 medewerkers kunnen simultaan aan het systeem werken.
3.2.2 Kwaliteit Het systeem dient robuust, betrouwbaar, bijna altijd beschikbaar, foutbestendig, beveiligd en veilig te zijn. Robuustheid houdt in dat het systeem bestendig is tegen ongeldige gebruikers invoer. Betrouwbaarheid betekent dat er geen waarneembaar verschil is tussen het gespecificeerde en het waargenomen gedrag van het systeem. Betrouwbaarheid Het systeem dient betrouwbaar te zijn, er mogen geen waarneembare verschillen zijn tussen het gespecificeerde en waargenomen gedrag. Fout tolerantie Het systeem dient bestand te zijn tegen verlies van de GSM verbinding tussen auto en roosterdatabase. Beschikbaarheid Het systeem mag hooguit 2 dagen per jaar onbeschikbaar zijn. Een onderbreking mag niet langer dan 1 dag duren. Beschikbaarheid Het systeem mag hooguit 2 dagen per jaar niet beschikbaar zijn. De onderbreking mag niet langer dan 1 dag duren. Beveiliging Het systeem dient bestendig te zijn tegen vijandige aanvallen. Onderbrekingen veroorzaakt door deze aanvallen vallen onder de eis aan de beschikbaarheid. Veiligheid Het systeem mag geen levens in gevaar brengen, zelfs niet onder extreme condities. 3.2.3 Kosten Eisen aan de kosten van het systeem zijn momenteelnog niet beschikbaar. De kosteneisen zullen opgesplitst worden in de volgende categorieën: ontwikkelkosten, installatiekosten,
20
opwaardeerkosten, onderhoudskosten, kosten nodig voor het oplossen van bugs en verbetering aan het systeem, en de administratiekosten. 3.2.4 Onderhoud Een eerste eis aan de onderhoudbaarheid is dat het systeem eenvoudig uit te breiden dient te zijn, deze eis zal vervult worden door objectgeoriënteerd te ontwerpen en te programmeren. Het objectgeoriënteerde ontwerp maakt het ook mogelijk de functionaliteit van het systeem relatief eenvoudig te wijzigen. Tevens biedt een conceptuele scheiding in meerdere lagen en het aanbieden van subsystemen met facades meer inzicht in de interne werking van het systeem. Porteerbaarheid naar andere platforms is de tweede eis aan de onderhoudbaarheid van het systeem. Deze eis kan vervult worden door geen platform specifieke bibliotheken te gebruiken of een programmeertaal met virtuele machines voor verschillende platforms te gebruiken (bijvoorbeeld Java). Als derde eis aan de onderhoudbaarheid van het systeem wordt de leesbaarheid van de code aangedragen. Iemand moet het systeem kunnen begrijpen door de code en aanwezige documentatie te lezen. 3.2.5 Gebruikers Het systeem dient zowel bruikbaar als nuttig te zijn voor de gebruikers. Ook oudere mensen moeten de auto’s kunnen bedienen en de medewerkers moeten het systeem zonder noemenswaardige computeropleiding kunnen gebruiken. De gebruikersinterface in de auto bestaat uit een lcd display, een pincode toetsenbord en een paspartoe-scanner. De pincode en het display zullen ongeveer werken als de pin automaat, een metafoor waarmee de klanten al vertrouwd zijn. Hierdoor zullen zij snel begrijpen hoe het ophalen en inleveren van de auto werkt. De gebruikersinterface voor de medewerkers zal verzorgd worden voor de web browsers Internet Explorer en Netscape. Documentatie over het reserveren ophalen en terugbrengen van Greenwheels auto’s zal aan de klanten verschaft worden wanneer zij zich bij GreenWheels abonneren. Ook zal op de voorruit een sticker zitten die kort beschrijft hoe de auto gedeblokkeerd kan worden. Het systeem voor de medewerkers zal documentatie bevatten binnen het programma. Deze documentatie is tijdens het werken met het systeem beschikbaar en vervangt papieren documentatie. Voor de communicatie tussen auto en het systeem zal een GSM verbinding gebruikt worden. Verder zijn er geen speciale eisen aan de hardware voor het systeem.
21
22
4
Systeemontwerp
Dit hoofdstuk beschrijft het globale ontwerp van het uiteindelijk op te leveren systeem. Allereerst wordt de globale architectuur beschreven. Vervolgens wordt gegevensmodel toegelicht. Uiteindelijk vindt de koppeling tussen functionele eisen, gegevensmodel en applicatie plaats bij de beschrijving van de applicatiearchitectuur.
4.1
Globale Architectuur
Het totale systeem is ontworpen met de gedachte van een 3-lagen architectuur. Dit houdt in dat het systeem wordt onderverdeeld in drie verschillende delen, ofwel lagen: • Data; • Applicatie; • Presentatie. Laag1: Presentatie
Laag 2: Applicatie logica
Laag 3: Dataopslag figuur 4-1 3-lagen architectuur
De datalaag bevat de benodigde gegevens van het systeem en wordt typische gerepresenteerd in één of meerdere databases. De laag is verantwoordelijk is voor het persistent maken en het afdwingen van contraints op de gegevens. De applicatielaag, ook wel business laag geheten, representeert in feite de logica van het systeem. Dit omvat eveneens de interne workflow, ofwel de voorschriften welke stappen in welke volgorde het systeem of een gebruiker doorloopt bij het uitvoeren van een opdracht. De presentatielaag is de interface voor de systeemgebruikers. Veelal is dit een grafische omgeving en kan bijvoorbeeld worden weergegeven door een webbrowser. De laag handelt de communicatie met de gebruiker af, en geeft dit door aan de applicatielaag, en geeft zonodig de respons van het systeem weer. Naast de conceptuele scheiding van de diverse lagen, biedt de 3-lagen architectuur een groot voordeel bij de technische realisatie. Een opgeleverd systeem is zeer schaalbaar, doordat het mogelijk is de lagen te distribueren over meerdere machines. Er zijn dit
23
diverse omgevingen en tools beschikbaar, ook wel aangeduid als middleware, die dit mogelijk maken.
4.2
Gegevensarchitectuur
In deze paragraaf wordt de gegevensarchitectuur toegelicht. Het uiteindelijke model is in een UML klassediagram weergegeven, waarna elke entiteit afzonderlijk wordt toegelicht in een aparte tabel. 4.2.1 Inleiding Om het gegevensmodel te verkrijgen, is een werkwijze gevolgd die aan de hand van de diverse use cases (zie paragraaf 3.1) entiteiten achterhaald. Per entiteit worden de benodigde attributen gedefinieerd aan de hand van de beschikbare gegevens in de casus, of worden aangenomen. Het uiteindelijke model is uitgedrukt in een UML klassediagram, wat een metamodel vormt van het uiteindelijke databasemodel. Per klasse worden primaire en verwijzende sleutels impliciet aangenomen. Elke klasse krijgt in het uiteindelijke datamodel, wat onderdeel uitmaakt van het technisch ontwerp, een betekenisloze primaire sleutel toegewezen. Relaties worden vertaald in verwijzende sleutels en/of tussentabellen. Eigenschappen van een relatie, gedefinieerd middels een klasse gekoppeld aan een relatie. Het UML datamodel is dus een conceptueel model, maar kan vrij eenvoudig worden geconverteerd naar bijvoorbeeld een SQL tabellenstructuur. 4.2.2 Datamodel In figuur 4-2 is het UML datamodel weergegeven. Per klasse staan de benodigde attributen met hun globale type weergegeven. Tussen de klassen onderling zijn diverse relaties gedefinieerd, waarbij eventueel een rolnaam is opgegeven indien er meerdere relaties tussen twee dezelfde klassen bestaan.
24
figuur 4-2 GreenWheels datamodel
De diverse klassen worden toegelicht in de onderstaande tabellen. Per tabel is een globale omschrijving van de klassen opgenomen, waarna per attribuut (ofwel kolomnaam) is opgeven welke gegevens het representeert. Een ‘→’ teken in de beschrijving geeft aan dat er verwijzing naar of relatie bestaat met een andere klasse in het model. Klant Een klant is de primaire houder van een →abonnement. Een abonnement kan worden gewijzigd met een bepaalde →ingangsdatum. De benodigde gegevens om contact te onderhouden en facturen op te stellen wordt bijgehouden. Een klant wordt altijd vertegenwoordigd door één →paspartoehouder, de registreerder. Een extra paspartoehouder is mogelijk. In →factuur worden één of meerdere facturen voor de klant vastgelegd. In →reservering zijn één of meerdere reserveringen voor een auto gedefinieerd. Kolomnaam Type Omschrijving Adres String Het postadres van de klant. Postcode String De postcode behorende bij het postadres. Plaats String De plaats waar het postadres zich bevindt. TelefoonPrive String Telefoonnummer buiten kantooruren. 25
TelefoonWerk TelefoonMobiel EmailAdres RekeningNummer
String String String String
IsBedrijfsmatig HeeftKorting
Boolean Boolean
Telefoonnummer tijdens kantooruren. Direct mobiel nummer. Email adres volgens RFC standaard. Het bank- of gironummer waar de facturen via automatische incasso van worden geïnd. Geeft aan of het een zakelijke klant betreft. Geeft aan of de klant reductie verkrijgt op geldende abonnementsprijzen.
tabel 4-1 Klant tabelomschrijving
Paspartoehouder Een parpartoehouder is een persoon in bezit van een pas behorende bij een bepaalde →klant. Deze kan zowel de registreerder zijn als een extra pashouder. Kolomnaam Type Omschrijving Titel String De eventuele titel van de houder. Roepnaam String De roepnaam van de houder. Initialen String De initialen, gescheiden door een punt, van de houder. Tussenvoegsels String De eventuele tussenvoegsels bij de achternaam. Achternaam String De achternaam van de houder. Geslacht String Het geslacht van de houder, aangeduid met ‘M’ voor mannelijk of ‘V’ voor vrouwelijk. Paspartoecode Integer De viercijferige, unieke code van de pas. Pincode String De viercijferige pincode behorende bij de paspartoecode. Elk getal kan een waarde van ‘0’..’1’ aannemen. tabel 4-2 Paspartoehouder tabelomschrijving
Abonnement Een abonnement vertegenwoordigd het contract tussen GreenWheels en →klant. De verschillende soorten abonnementen hebben betrekking tot de geleverde diensten voor een bepaalde prijs. Maandelijks wordt de abonnementsprijs verrekend middels een →betaalopdracht. De prijs wordt jaarlijks aangepast middels een →abonnementstarief. Kolomnaam Type Omschrijving Omschrijving String De omschrijving van het abonnement. Dit kan zowel ‘Bel&Rij’ als Bel&Rij Plus’ zijn. Prijs Currency De uitgangsprijs van het abonnement, in guldens per maand, zonder eventuele kortingen. tabel 4-3 Abonnement tabelomschrijving
AbonnementsTarief Een abonnementstarief specificeert de prijs van een →abonnement. Kolomnaam Type Omschrijving
26
Prijs
Currency
IngangsDatum
DateTime
De uitgangsprijs van het abonnement, in guldens per maand, zonder eventuele kortingen. De datum waarop het tarief ingaat.
tabel 4-4 AbonnementsTarief tabelomschrijving
Factuur Een factuur is een verzameling van één of meerdere →betaalopdrachten. Elke afzonderlijke betaalopdracht is nog niet voldaan. Na betaling van de factuur wordt dit voor zowel de factuur zelf als de bijbehorende betaalopdrachten vastgelegd. Kolomnaam Type Omschrijving Opstellingsdatum DateTime De datum en tijd waarop de factuur is opgesteld. Afrondingsdatum DateTime De datum en tijd waarop de factuur is betaald. Deze blijft leeg als dit nog niet gebeurd is. tabel 4-5 Factuur tabelomschrijving
BetaalOpdracht Een betaalopdracht wordt opgesteld aan de hand van de geregistreerde kosten van een →reservering, of aan de hand van een maandelijkse prijs voor een →abonnement. Kolomnaam Type Omschrijving Bedrag Currency Het bedrag dat met de betaalopdacht is gemoeid. IsVoldaan Boolean Geeft aan op de betaalopdracht is voldaan. tabel 4-6 BetaalOpdracht tabelomschrijving
Reservering Een reservering is de registratie van een →klant van een →auto op een bepaalde tijdstermijn. Na afloop van de reserveringstermijn, dan wel terugkomst van de auto, wordt een →betaalopdracht opgesteld. Kolomnaam Type Omschrijving StartTijdstip DateTime De datum en tijd van waaraf de reservering start. Tijdsduur Integer De gewenste tijdsduur van de reservering, uitgedrukt in eenheden van 15minuten. GemetenAfstand Integer De gemeten afstand, vastgesteld aan de hand van de kilometerstand, uitgedrukt in kilometers. GemetenTijdsduur Integer De gemeten tijdsduur van de reservering, uitgedrukt in eenheden van 15minuten. tabel 4-7 Reservering tabelomschrijving
BrandstofTarief Een abonnement vertegenwoordigd het contract tussen GreenWheels en →klant. De verschillende soorten abonnementen hebben betrekking tot de geleverde diensten voor een bepaalde prijs. Maandelijks wordt de abonnementsprijs verrekend middels een →betaalopdracht.
27
Kolomnaam Prijs
Type Currency
IngangsDatum
DateTime
Omschrijving De uitgangsprijs van het abonnement, in guldens per maand, zonder eventuele kortingen. De datum waarop het tarief ingaat.
tabel 4-8 BrandstofTarief tabelomschrijving
Auto Een auto heeft meerdere kenmerken die met name verzekeringstechnisch van belang kunnen zijn. Een auto is altijd verbonden aan één →uitgiftepunt, en kan op een willekeurige tijdstermijn ten hoogste door één →reservering worden vastgelegd. Kolomnaam Type Omschrijving Merk String Het merk, oftewel de fabrikant, van de auto. Type String De opgegeven typeaanduiding van de auto. Bouwjaar Integer Het bouwjaar van de auto. Kleur String De opgegeven kleur van de auto. Kenteken String Het Nederlandse kenteken van de auto, een combinatie van 6 karakters gescheiden door meerdere streepjes. Chassisnummer String Het chassisnummer van de auto. tabel 4-9 Auto tabelomschrijving
Uitgiftepunt Een uitgiftepunt is een locatie in een stad waar een →auto uitgegeven en weer ingenomen wordt. Kolomnaam Type Omschrijving Adres String Het fysieke adres van het uitgiftepunt. Postcode String De postcode behorende bij het adres. Plaats String De plaats waar het adres zich bevindt. tabel 4-10 Uitgiftepunt tabelomschrijving
4.2.3 Business rules Aan de hand van het datamodel besproken in paragraaf 4.2.2 worden hier de bijbehorende business rules gedefinieerd. Deze vormen een uitbreiding op het UML klassediagram, aangezien niet alles in UML uitgedrukt kan worden. Deze regels zijn hieronder uitgewerkt in natuurlijke taal, daaronder staan er enkele uitgewerkt middels de taal OCL [3]. Klant: • Een klant die korting krijgt betaalt f25.- minder voor een abonnement; • De registreerder is ongelijk aan de extra paspartoehouder. Reservering: • Een klant kan geen reservering doen die een andere reservering van dezelfde klant overlapt;
28
•
Een auto kan niet door meerdere overlappende reserveringen aangewezen worden.
Betaalopdracht: • Een betaalopdracht hoort òf bij een abonnement òf bij een reservering. Factuur: • De afrondingsdatum is gelijk of later aan de opstellingsdatum; • Een factuur voor een klant bevat alleen maar betalingsopdrachten van deze klant. Hieronder staan enkele van bovenstaande regels formeel uitgedrukt in de taal OCL. Klant self.HeeftKorting implies self.Abonnement.BetaalOpdracht.Bedrag = self.Abonnement.BetaalOpdracht.Prijs – 25 self.ExtraHouder->notEmpty implies not self.ExtraHouder = self.Registreerder BetaalOpdracht (self.Abonnement->notEmpty and self.Reservering.isEmpty) or (self.Abonnement->isEmpty and self.Reservering.notEmpty) Factuur self.Afrondingsdatum->notEmpty implies self.Afrondingsdatum >= Opstellingsdatum
4.3
Applicatiearchitectuur
In deze paragraaf is de applicatielaag van het te bouwen systeem gedefinieerd. De applicatielaag bevat de programmalogica, vanuit een bedrijfsperspectief wordt ook wel gezegd dat hier de business rules zijn opgeslagen. Deze laag specificeert de operaties die op de data uitgevoerd mogen worden. De klassen van objecten die gebruikt gaan worden zijn onder te verdelen in drie soorten: Entity objects, Boundary objects, en Controller objects. Vertaald naar het Nederlands houdt dit in dat elk subsysteem een Facadeobject, een Beheerderobject en één of meer Entiteitsobjecten bevat. De communicatie tussen de subsystemen verloopt via deze facade objecten: zij vormen de interface van subsysteem naar de buitenwereld. In de facade zijn de operaties vastgelegd die op het subsysteem kunnen worden uitgevoerd. In paragraaf 4.3.1 is de communicatie tussen de verschillende subsystemen gespecificeerd in UML volgorde diagrammen. In paragraaf 4.3.2 is een subsysteemdecompositie gemaakt. Deze decompositie is gebaseerd op een functionele scheiding van elk van de subsystemen. Vervolgens is van elk subsysteem een UML klassendiagram gemaakt. Dit klassendiagram bevat een gedetailleerde beschrijving van de objecten in het te bouwen systeem. 29
4.3.1 Communicatiepatronen De applicatielaag werkt in grote lijnen als volgt: De globale communicatie verloopt via facades / facade objecten. De facadeobjecten hebben twee functies: • Ze definieren de operaties die op het subsysteem mogen worden uitgevoerd; • Ze leggen vast welke entiteitsobjecten beschikbaar zijn voor de gebruiker, ze geven toegang tot deze entiteitsobjecten. Het voordeel van deze aanpak is dat de interne werking van het subsysteem voor de gebruiker verborgen blijft. De entiteitsobjecten worden beheerd door de beheerder-objecten. De beheerder-objecten halen de entiteitsobjecten uit de database wanneer zij nodig zijn of opgevraagd worden. De beheerder is tevens verantwoordelijk voor het opslaan van de entiteitsobjecten. De entiteitsobjecten hebben twee functies: • Ze definieren de operaties die op de data mogen worden uitgevoerd. In de database zijn slechts de attributen van het object vastgelegd, in deze laag worden de operaties gedefinieerd; • Ze worden gebruikt voor de communicatie tussen de subsystemen. De velden waarover gecommuniceerd wordt, worden tijdelijk opgeslagen in een entiteitsobject. Als de gebruiker klaar is met het bewerken van een bepaalde record wordt het overeenkomstige object naar de beheerder gestuurd, die het object opslaat in de database. De communicatie tussen de verschillende objecten in de subsystemen is vastgelegd in UML volgordediagrammen. Elke use case uit het vorige hoofdstuk is hier uitgewerkt in een volgorde diagram.
30
4.3.1.1
UC_Inschrijven & UC_Wijzigen
Bij het inschrijven van een nieuwe klant wordt een nieuw object Klant aangemaakt (Klant k). De attributen/velden van k worden gevuld met de parameters in de constructor aanroep, danwel met de set-methoden/operaties van het Klant object. Als alle benodigde velden gevuld zijn wordt het klant object naar de KlantenFacade gestuurd. De KlantenFacade zorgt ervoor dat het object in de database wordt opgeslagen. Het wijzigen van klantgegevens geschiedt door het betreffende klant object uit de database te halen, de benodigde velden te wijzigen met de betreffende set-operaties en vervolgens het object weer terug te sturen naar de KlantenFacade.
31
4.3.1.2
UC_Reserveren & UC_Wijzigen
Het aanmaken van een reservering gebeurt op dezelfde manier als het aanmaken van een nieuwe klant. Zie paragraaf 4.3.1.1
32
4.3.1.3
UC_OphalenAuto & UC_TerugbrengenAuto
De implementatie van deze use cases is iets complexer, aangezien er meerdere gegevens(typen) bij betrokken zijn. De communicatie verloopt globaal van de boordcomputer naar de vlootbeheersfacade, waarna de vlootbeheersfacade de andere subsystemen raadpleegt. 4.3.1.4
UC_UitschrijvenKlant
Het uitschrijven van een klant vind plaats door aanroep van de operatie uitschrijvenKlant(klantID: int). Hierop wordt in de database de klant inactief gemaakt en gearchiveerd.
33
4.3.2 Componenten De in het vorige hoofdstuk gevonden use cases zijn qua functionaliteit onderverdeeld in 4 groepen op basis waarvan de subsystemen zijn gedefinieerd. De volgende subsystemen zijn te onderscheiden: • Vlootbeheersysteem • Reserveringssysteem • Klantenbeheersysteem • Factureersysteem Elk subsysteem is in paragraaf 4.4.1.1. t/m 4.4.1.4 uitgewerkt in een klassendiagram met toelichting. 4.3.2.1 Vlootbeheerssysteem Het Vlootbeheersysteem is verantwoordelijk voor de uitgifte van Auto’s. Verder is het mogelijk om via dit subsysteem allerlei informatie op te vragen over elke Auto In figuur 4-3 is het klasse diagram van het vlootbeheerssysteem te zien. Elk Auto object correspondeert met een fysieke auto, waarbij in het auto-object een referentie naar de boordcomputer van de eigenlijke auto is opgeslagen. Via de methode verbindMetBoordcomputer() wordt een boordcomputer object teruggegeven dat direct kan worden aangeroepen.
figuur 4-3 Subsysteem Vlootbeheerssysteem
4.3.2.2 Reserveringssysteem Het Reserveringssysteem houdt bij welke auto’s op welk moment beschikbaar zijn. Een klant kan een Reservering maken Het slaat deze informatie op in het Planningsrooster. In figuur 4-4 is het klasse diagram van het reserveringssysteem getekend. De
34
ReserveringBeheerder is verantwoordelijk voor het persistent maken van de Reservering objecten.
figuur 4-4 Subsysteem Reserveringssysteem
4.3.2.3 Klantenbeheersysteem Het Klantenbeheersysteem is verantwoordelijk voor het beschikbaar maken en opslaan van alle klantgegevens. Het houdt tevens bij welke Paspartoes er uitgegeven zijn aan welke Paspartoehouders, welke Abonnementen er zijn. In figuur 4-5 is het klantenbeheersysteem weergegeven. De KlantBeheerder is verantwoordelijk voor het persistent maken van de Klant en Paspartoehouder objecten.
35
figuur 4-5 Subsysteem Klantenbeheersysteem
4.3.2.4 Factureersysteem Het Factureersysteem is verantwoordelijk voor het opmaken van een Factuur op basis van een Reservering en de gereden kilometers uit de Boordcomputer. In figuur 4-6 het factureersysteem te zien.
figuur 4-6 Subsysteem Factureersysteem
36
5
Conclusie
Doel van dit rapport is een functioneel ontwerp voor een gedistribueerd systeem dat de bedrijfsprocessen van GreenWheels ondersteund. Hiervoor dient de autouitgifte volledig geautomatiseerd te worden en gekoppeld te worden aan de reeds aanwezige systemen. Dit rapport dient als basis voor het technische ontwerp. Eerst zijn met behulp van een DEMO interactiemodel de te ondersteunen bedrijfsprocessen geselecteerd. Voor de geselecteerde bedrijfsprocessen zijn UML usecases bepaald die deze mogelijk maken. Nadat de functionaliteit van het te bouwen systeem is vastgelegd is het datamodel ontworpen, dat naast de use-case specificatie als houvast diende bij het ontwerp van de klassen- en volgordemodellen. Het ontwerp gaat uit van een drielagen architectuur, waarbij het datamodel in de datalaag terechtkomt en de vier subsystemen: Vlootbeheer-, Reservering-, Klantenbeheer- en Factureer-systeem in de applicatielaag komen. Een ontwerp voor de presentatielaag ontbreekt nog, maar is eenvoudig toe tevoegen nu de onderliggende lagen al ontworpen zijn.
37
38
Referenties [1] BRUEGGE, B. AND DUTOIT, A. H., 2000, Object-oriented software engineering – Conquering Complex and Changing Systems, Prentice-Hall International, Inc., New Jersey. [2] DIETZ, J.L.G., 1996, Introductie tot DEMO, Samson. [3] OCL specification, zie [http://www.klasse.nl]. [4] POOLEY, R. AND STEVENS, P., 1999, Using UML - Software Engineering with Objects and Components, Addison Wesley Longman Ltd, Edinburgh
39
