TENTAMEN INFORMATIESYS'TEMEN (21 201 0)

TENTAMEN INFORMATIESYS'TEMEN (21 201 0) 7 april 2005,9:00-12:30 uur BELANGRIJK Dit tentamen bestaat uit 3 opgaven. Voor het beantwoorden van opgave 1 en 2 neemt u het gebruikelijke tentamenpapier, maar U wordt verzocht iedere opgave op een apart blad te maken (ten behoeve van het nakijken wordt het irlgeleverde werk gesplitst). Voor opgave 3 zijn antwoordbladen aan deze opgave geniet. Het is toegestaan het nietje te verwijderen en de blaadjes die niet van toepassing zijn weg te gooien. Vul Uw naam in op alle antwoordbladen die U inlevert. Casusbeschrijving voor opgaven 1 en 2 Het oude familiehotel "Noordzee" is onlangs in andere handen overgegaan en wordt nu gemoderniseerd. De nieuwe eigenaar heeft behoefte aan een informatiesysteem ter ondersteuning van de administratie. Daarbij zijn de onderstaande punten van belang. De receptionist kan op ieder gewenst moment een overzicht opvragen van de beschikbare kamers. Als daar aanleiding toe is kan deze medewerker ook kamers uit het bestand verwijderen (bijvoorbeeld als een kamer vanwege onderhoud een tijd niet verhuurd wordt) of aan het bestand toevoegen. De prijs per kamer per nacht wordt bepaald door verschillende factoren. Eenpersoonskamers zijn goedkoper dan tweepersoonskamers. Kamers aan de voorkant hebben uitzicht op zee en een klein balkon, deze zijn duurder dan kamers aan de achterkant. Tenslotte is er verschil tussen kamers metlzonder eigen douche en toilet. In het hoogseizoen is het aan te raden om vantevoren te reserveren. Dit kan elektronisch via de website van het hotel, of telefonisch bij de receptie, die dan in het systeem opslaat welke periode en wat voor soort kamer gewenst wordt. In beide gevallen krijgt de klant meteen te horen of aan de wensen wel of niet voldaan kan worden. Zo ja, dan wordt een reservering voor de betreffende periode vastgelegd en de prijs bevestigd. Het is niet echter niet mogelijk om een bepaald kamernummer te reserveren; pas als de klant in het hotel aankomt wordt bepaald welke kamer hijlzij krijgt toegewezen. Soms komt het voor dat een reservering weer wordt afgezegd. Dit kan alleen telefonisch. Is dat langer dan een maand vantevoren, dan zijn daar geen kosten aan verbonden. Bij een kortere afzegtermijn dient de klant administratiekosten te betalen, de hoogte daarvan hangt af van de pijs van de kamer en hoe lang vantevoren afgezegd wordt. Komt iemand niet opdagen dan moet altijd één nacht betaald worden en vervalt de reservering. Bij aankomst meldt de gast, resp. het gastenpaar, zich aan de receptie. Was er een reservering gemaakt, dan krijgt men een kamer van het bestelde soort toegewezen. Komt een gast onaangekondigd, dan kan deze slechts een keus maken uit de soorten kamers die nog

beschikbaar zijn. Bij een tweetal gasten wordt één van beide in de administratie als "klant" opgenomen, deze dient bij vertrek af te rekenen. Als de klant per creditcard wil betalen (maar dat is niet verplicht) wordt bij aankomst alvast het nummer van de creditcard genoteerd. Van de tweede gast worden alleen de naam- en adresgegevens genoteerd. Heeft de receptionist alle benodigde gegevens ingevoerd, dan krijgt de klant te horen wat het kamernummer is en wordt de sleutel overhandigd. Tijdens het verblijf in het hotel kunnen de gasten gebruik maken van vei-schillende services die extra betaald moeten worden. In de toekomst ligt het in de bedoeling verschillende eletronische dienster? (bijv. gebruik van Internet) met het administratiesysteem te koppelen en ook de minibar rechtstreeks door te laten geven wanneer er een consumptie uitgehaald wordt. Maar in het nu te ontwerpen systeem mag er vooralsnog van worden uitgegaan dat iedere service handmatig in het systeem wordt ingevoerd. Bij een service dient opgegeven te worden; de aard van de service, de prijs, de datum, het tijdstip, de uitvoerder (die ook de gegevens invoert) en een nadere specificatie van de geleverde diensten. Er wordt geen verschil gemaakt tussen services verleend aan de klant en services verleend aan een eventuele tweede bewoner van een kamer, services worden altijd aan de klant in rekening gebracht. Bij vertrek uit het hotel levert de klant de sleutel weer in bij de receptie en krijgt hijlzij de rekening. In principe betaalt de klant de rekening direct, per creditcard of contant. In bijzondere gevallen (bijv. bij vaste klanten, of bij vervallen reserveringen waarvoor administratiekosten betaald moeten worden) is het mogelijk dat de rekening op een later tijdstip betaald wordt. Hoe de verschillende betalingen precies verricht worden hoeft niet in dit model te worden opgenomen. Opgave 1 Maak een class diagram voor de hierboven beschreven casustekst [75 punten] Opgave 2 Begin deze opgave op een nieuul vel papier (a) Maak een use case diagram voor het hierboven omschreven informatiesysteem [25 punten] (b) Maak BCE-diagrammen voor alle use cases 1.50 punten] N.B.: Het staat u vrij een eventlist edof use case list te makeli, maar deze wordt niet beoordeeld en ho42ft niet te worden ingeleverd. SCHRIJF DUIDELIJK!

Casusbeschrijving voor opgave 3 "Dertig procent van de treinreizigers gaat op de fiets naar het station. Na de treinreis gaat negen procent met de fiets verder. Het initiatief de OV-fiets (een samenwerking van onder meer NS Railinfrabeheer en de Fietsersbond,...) moet het zogenaamde 'na-transport' verbeteren, met een speciale huurfiets. Deze OV-fiets is een herkenbare Spartafiets die klaarstaat in de stationsfietsenstalling, of in een fietskluis. De huurder heeft een pasje, betaalt per keer 2150 Euro en kan meteen wegfietsen. Borg en legitimatie zijn niet nodig." (Trouw, 7-9-2002). Voor dit tentamen wordt U gevraagd een informatiesysteem (IS) te modelleren ter ondersteuning van de activiteiten van OV-Fiets. Voor dit systeem zijn de volgende feiten van belang. OV-fiets beschikt op dit moment (juli 2003) over 33 verhuurlocaties (allemaal bij NS-stations). De namen van deze locaties worden in het IS bijgehouden. Medewerkers van OV-fiets kunnen locatiegegevens toevoegen, verwijderen en wijzigen. Er zijn twee soorten verhuurlocaties: automatische fietskluizen (zonder personeel, op dit moment bij twee stations in Nederland), en locaties met personeel (de overige 3 1 op dit moment). OV-fiets beschikt over honderden fietsen die elk voorzien zijn van een uniek nummer op een barcode of chip. Het informatiesysteem houdt deze nummers bij, en houdt van elke fiets bij op welke verhuurlocatie deze het laatst is terugbezorgd. Personeel van OV-fiets kan fietsgegevens wijzigen, toevoegen en verwijderen. Via de website van OV-fiets kunnen geïnteresseerden zich aanmelden voor OV-fiets door naam, adres, woonplaats en banugirorekeningnummer via een formulier door te geven. Het informatiesysteem legt deze gegevens vast, kent een lidmaatschapsnummer toe, stuurt de OVfietspas (een chipkaart) op, en geeft de bank van OV-fiets opdracht tot automatische incasso van de borg ( 10,-). Het systeem legt vast dat de borg betaald is. Geïnteresseerden die houders zijn van een NS-kaart (zoals de OV-jaarkaart) hebben geen aparte OV-fietspas nodig. Zij vullen op de website een ander formulier in, waarbij ze behalve naam, adres, woonplaats en banugirorekeningnummer ook het nummer van hun NS-kaart doorgeven (dat wordt dan hun lidmaatschapsnummer bij OV-Fiets). Het systeem legt deze gegevens vast en verstuurt een bevestigingsbrief. Houders van een NS-kaart betalen geen borg; het IS legt simpelweg vast dat het borgbedrag 0,- bedraagt en als betaald beschouwd kan worden. Een NS-kaart is geen chipkaart, daarom kan deze kaart niet gebruikt worden in de automatische fietskluizen. Een lid van OV-fiets kan als volgt een fiets huren. Hijlzij gaat naar de verhuurlocatie en laat zijnlhaar OV-fietspas of NS-kaart zien (of stopt 'm in de automatische fietskluis) en neemt een fiets. D.m.v. een barcodescanner of chipkaartlezer worden het lidmaatschapsnummer op de paslkaart en het nummer van de fiets gelezen. Het informatiesysteem legt vervolgens het tijdstip vast waarop de verhuur is begonnen. Per OV-fietspas mag slechts één OV-fiets tegelijkertijd gehuurd worden. De pas is bovendien persoonlijk. Bij terugkomst worden opnieuw d.m.v. een barcodescanner of chipkaartlezer het lidmaatschapsnummer en het nummer van de fiets gelezen en wordt het tijdstip vastgelegd waarop de verhuur beëindigd is. Het is toegestaan de fiets meerdere dagen achtereen te huren. Het is ook toegestaan de fiets terug te bezorgen bij een andere verhuurlocatie dan waar deze gehuurd was. Het IS legt telkens wanneer een fiets wordt terugbezorgd de verhuurlocatie vast waar de fiets zich bevindt. Pashouders kunnen een fiets voor een bepaalde dag reserveren door te bellen met een voiceresponsesysteem. De pashouder toetst dan zijnlhaar pasnummer en een code van de locatie in, alsmede de datum waarop hijlzij een fiets wil huren. Het is alleen mogelijk een fiets te reserveren bij bemande verhuurlocaties, dus niet bij automatische fietskluizen. Personeel van een verhuurlocatie kan met hun barcodescanner het aantal reserveringen voor een dag opvragen.

Reserveren is niet mogelijk voor een langere periode dan één dag, vandaar dat maar één datum gegeven hoeft te worden. Elke maand stuurt het IS elk lid een overzicht van de kosten en geeft de bank opdracht tot automatische incasso van het verschuldigde bedrag. OV-fiets brengt f: 2,50 per periode van 20 uur in rekening, met een maximum van 25,- per maand. Casus gebaseerd op: \v\vw.o\,-tïets.ni, stand juli 2003. Na een geslaagde proefperiode zijn er enigc aanpassingen gedaan. dus de werking van OV-fiets anno 2005 wijkt op detailpunten af van deze casusbeschnjving Opgave 3: Completeren van de modellen Bij deze opgave moeten de tabellen worden ingevuld die U aantreft op de laatste bladzijden van dit opgavenpakket. Maak de opgave op deze bladzijden (en vergeet niet Uw naam op ieder blad te vermelden). Het is niet de bedoeling dat U de gegeven onvolledige diagrammen weer inlevert. Beschouw de (mogelijk) incomplete gebeurtenissenlijst (Tabel l), incompleet state transition diagram (Figuur l), incompleet class diagram (Figuur 2), incompleet use case diagram (Figuur 3), en incomplete BCE diagrammen (Figuur 4-6) op de volgende pagina's, die gebaseerd zijn op de casusbeschrijving. Voer vervolgens de onderstaande controles uit. [50 punten] N.B. bij iedere corztrole gebruikt u de genoenzde diagmmmen in de vornz waarin ze stoor7 ufgedrukt. Bent u op grorld van andere controles tot de conclusie gekomen dat een diagrum uitgebreid zou kii~znerz worden, dan hoeft u de iloorgestelde uitbreiding niet in de gevraagde controle te betrekken. Geef aan op grond van welke actor enlof use case van het use case diagram aan het BCE diagram een actor, een boundary class, een control class, enlof een entity class moet worden toegevoegd. Geef aan op grond van welke actor, een boundary class, een control class, enlof een entity class van het BCE diagram aan het use case diagram een actor enlof use case moet worden toegevoegd. Geef aan op grond van welke gebeurtenis van de eventlist aan het BCE diagram een actor, een boundary class, een control class, enlof een entity class moet worden toegevoegd. Geef aan op grond van welke actor, een boundary class, een control class, enlof een entity class van het BCE diagram aan de eventlist een gebeurtenis moet worden toegevoegd. Geef aan op grond van welke gebeurtenis van de eventlist aan het state transition diagram een state enlof transition moet worden toegevoegd. Geef aan op grond van welke state en/of transition van het state transition diagram aan de eventlist een gebeurtenis moet worden toegevoegd. Geef aan op grond van welke class, relationship en/of attribuut van een class in het class diagram, aan het BCE diagram een actor, een boundary class, een control class, enlof een entity class moet worden toegevoegd. Geef aan op grond van welke actor, een boundary class, een control class, enlof een entity class van het BCE diagram, aan het class diagram een class, een relationship, enlof een attribuut van een class moet worden toegevoegd. Geef aan op grond van welke class, een relationship, enlof een attribuut van een class van het class diagram, aan het state transition diagram een state enlof transitie moet worden toegevoegd. Geef aan op grond van welke state enlof transition van het state transition diagram aan het class diagram een class, een relationship, en/of een attribuut van een class moet worden toegevoegd. SCHRIJF DUIDELIJK!

Gebeurtenis Input Actie Directe uitv. Indir. uitvoer Medewerker OV-fiets Nieuwe gegevens Vastleggen muteert gegevens verhuurlocatie mutaties verhuurlocaties verhuurlocatie Geïnteresseerde Gegevens Vastleggen Pas, incasso- Rekeningen, vraagt pas aan geïnteresseerde gegevens opdracht, brief incassogeïnteresseerde opdrachten Geïnteresseerde Gegevens betaling Vastleggen betaalt borg betaling borg Pashouder brengt Pasnummer en Vastleggen fiets terug fietsnummer eindtijdstip verhuur en locatie Rekeningen, incassoopdrachten Rekeningen, incassoopdrachten Pashouder Pasnummer, datum Vastleggen Lijst reserveert een fiets en verhuurlocatie reservering reserveringen Tabel 1: Incomplete eventlist voor casus 'OV-Fiets'. pashouder huurt fiets Gereserveerd medewerker verhuurlocatie vraagt lijst reserveringen op m eens per maand: afdrukken rekeningen Huur in rekening gebracht Figuur 1: Incompeet state transition diagram voor de afhandeling van verhuur van een fiets

(deze pagina is leeg)

1 Verhuurlocalie I 1 stationsnaam: String is-kluis: Boolean is-kluis <<dynamic>> C voor * l ' 1 Reservering 1 heeff dag: Date l t Pashouder I pasnummer: Integer naam: String adres: String 1 woonpiaats: String I rekeningnummer: Integer borg: Money Figuur 2: Incompleet class diagram voor casus 'OV-Fiets' A Medewerker OV-Fiets Vastleggen mutaties locatie- en fietsgegevens Verwerken aanmelding pashouder Vastleggen verhuur Bank Pashouder Figuur 3: Incompleet use case diagram voor casus 'OV-Fiets'

(deze pagina is leeg)

R Aedewerker OV-fiets nieuwe gegevens fiets. F cccreate>> (onbekend) Vastleggen Fiets mutaties locatieen fietsgegevens Figuur 4: Incompleet BCE diagram voor een use case in Figuur 3 Pashouder chipkaartlezer Vastleggen Pashoudei rekening Vervaardigen rekeningen en incasso-opdrachten / \ Bank Figuur 5: Incompleet BCE diagram voor twee use cases in Figuur 3 X/ datum, locatie (onbekend) Aedewerker 'rhuurlocatie lijst reserveringen Opstellen Reserverin! lijst reserveringen Figuur 6: Incompleet BCE diagram voor een use case in Figuur 3

(deze pagina is leeg)

De tabellen die bij opgave 3 horen bevinden zich niet in deze scan omdat ze ingeleverd moesten worden tijdens het tentamen. De opdracht beschrijft echter duidelijk de bedoeling, de tabellen bevatten niet meer informatie dan al in de opdracht staat waardoor deze prima gemaakt kan worden zonder de tabellen.