UNIVERSITETET I OSLO

Transkript

1 Løsninsforsla INF1050 vår2006 Bokmål UNIVERSITETET I OSLO Det matematisk-naturvitenskapelie fakultet Eksamen i: INF 1050 Systemutviklin Eksamensda: Freda 2. juni 2006 Tid for eksamen: Oppavesettet er på: 5 sider pluss vedle Vedle: UML-diarammer for kompletterin 2 sider Tillatte hjelpemidler: Alle trykte o skrevne Kontroller at oppavesettet er komplett før du beynner å svare på spørsmålene. Innlednin Det har i Nore den senere tid vært en del uheldie til dels traiske hendelser der bakterier har blitt spredd med matvarer o forårsaket alvorli sykdom o lidelse. Dette har ført til at myndihetene vil intensivere arbeidet med å utvikle systemer for sporin av matvarer fra der hvor råvarene produseres fram til forbruker. Hjemmel for dette finnes i 11 i LOV nr 124: Lov om matproduksjon o mattryhet mv. (matloven), der det heter Konen kan i forskrifter om sporbarhet for innsatsvarer, planter, dyr eller nærinsmidler, samt om sporbarhet for materialer o jenstander som er bestemt til å komme i kontakt med, eller kan ha innvirknin på innsatsvarer eller nærinsmidler. I de forskriftene som nå etter hvert blir jort jeldende i hele EU/EØS-området er hovedprinsippet at enhver virksomhet som innår i produksjonskjeden skal ha oversikt over se selv, hvilke virksomheter innsatsvarene (råvarene, inrediensene) kommer fra (bare det nærmest foreående ledd), hvordan produktene settes sammen (hvilke innsatsvarer som innår i hver enkelt sats ( batch )) o hvilke virksomheter produktene år til (bare det umiddelbart neste ledd). Det siste jelder do ikke for detaljister, som ikke har plikt til å reistrere hva sluttforbrukeren kjøper. Poenet med dette er selvsat at når alarmen år, kan enhver virksomhet lett finne ut hvilke virksomheter innsatsvarene kommer fra, disse virksomhetene ijen kan slå opp i sine informasjonssystemer o finne ut hvilke innsatsvarer de har brukt osv. slik at man fort får oversikt over mulie smittekilder. Ny merkinsteknoloi i form av RFID-brikker (små databrikker der laret informasjon kan avleses ved hjelp av radiobøler) vil jøre det enklere enn før å merke o føle innsatsvarene. Sentralt i dette oppleet står berepet sats ( batch, LOT ), som vi kan oppfatte som en identifiserbar porsjon av en blandin av ulike inredienser eller innsatsvarer. Hvis vi for eksempel baker brød, består satsen av selve brøddeien som etter hvert kan bli til flere brød. I kommersiell produksjon skal alle satser ha et unikt satsnummer, o man skal omhyeli reistrere satsnumrene på alle innsatsvarene som brukes i satsen. En brødbaker må altså tilordne et nytt satsnummer til hver ny brøddei, o han må reistrere satsnummeret på melsekken, på jærpakken osv. som brukes i akkurat denne brøddeien. I denne oppaven forutsetter vi at satsnummeret er satt sammen av Sensorveilednin - eksamen i INF1050 Side 1 av juni 2006

2 virksomhetens ornr (oranisasjonsnummer) o en lokal nummererin (virksatsnr) innenfor virksomheten. Oppave 1 (20% 36 min.) Vi har fått i oppave å lae et sporinssystem som skal tilfredsstille kravene skissert i innledninen, tilpasset mindre produksjonsvirksomheter. For databasen i systemet er foreslått følende dataorienterte UML-klassediaram: Produsent ornr {id} kontaktperson 1 * «identifyin» Sats virksatsnr {id} produksjonsda Leverandør ornr {id} kontaktperson 1 * Inredienssats Produktsats Kunde * * * * ornr {id} kontaktperson En produsent er den virksomheten som har produsert en sats, men den kan å via en eller flere leverandører før den havner hos en virksomhet som bruker den som inrediens. a) Foreslå en relasjonsdatabasestruktur som byer på denne modellen, dvs. tabeller med attributter, primærnøkler o referanseinteriteter. Berunn val av løsnin for underbereps-konstruksjonen. Vi skal ha en tabell for hver klasse, samt en tabell for mane-til-maneassosiasjonene. Vi får følende tabeller (primærnøkkelattributter i fet skrift): Produsent: ornr kontaktperson Sats: produsent-ornr virksatsnr produksjonsda Leverandør: ornr kontaktperson Kunde: ornr kontaktperson Sal (eller et annet navn): eet-ornr virksatsnr kunde-ornr Inredienssats: produsent-ornr virksatsnr leverandør-ornr Produktsats: eet-ornr virksatsnr Blandinslinje (eller et annet navn): produsent-ornr produsent-virksatsnr eet-ornr virksatsnr Kommentar: Mesteparten av dette føler rent mekanisk, men det kan være lett å å surr i alle or-nr her. Det hadde vært enklere å ta utanspunkt i en eneralisert modell (jfr. deloppave b) med rolleanivelser. Her er de ulike rollene(forstavelsene til ornr) trukket litt ut av luften. Referanseinteriteter fra alle or-nr-fremmednøkler mot tilsvarende primærnøkler, o fra alle ornr-virksatsnr-fremmednøkler mot tilsvarende primærnøkler. Sensorveilednin - eksamen i INF1050 Side 2 av juni 2006

3 Skal det være helt perfekt, skal alle fremmednøkler oså være markert som "NOT NULL" Je har her valt separasjon for underbereps-konstruksjonen, siden de tre tabellene som da oppstår har ulike attributter. Je ønsker å unnå NULL fordi det kan bli mane forekomster i tabellene. Kommentar: Dette er en litt omfattende oppave, o kandidatene bør få full uttellin hvis de viser at de behersker prinsippene, o selv om relasjonsdatabasestrukturen ikke er helt komplett. Vikti er: Sammensatt primærnøkkel i Sats, forplantnin av denne sammensatte primærnøkkelen til de samsvarende fremmednøklene, ikke attributtnavnet ornr flere aner i samme tabell, tabeller oså for mane-til-mane-assosiasjonene, én korrekt referanseinteritet. b) Det finnes klasser i modellen som man kan vurdere å eneralisere til en felles klasse. Ten opp den modellen som kommer fram hvis man foretar denne eneraliserinen. Hvilke fordeler kan en slik eneraliserin ha? Av modellen o av svaret på a) ser man klart at klassene Produsent, Leverandør o Kunde har samme identifikator o samme attributt. De kan eneraliseres til den ene klassen Virksomhet. Da må det settes på roller på assosiasjonene, slik at det fremår om en virksomhet spiller rollen som produsent, leverandør eller kunde. Fordelen med eneraliserinen er at det blir formelt muli å sammenline Produsent med Leverandør osv. En annen fordel er at hvis vi rupperer rett fram som i a), vil vi få en tabell for virksomhetene istedenfor 3. En underbereps-konstruksjon er oså tenkbar, men ikke nærliende her. c) Hvis vi forutsetter at produkter ikke kan innå som inredienser innenfor den samme produksjonsvirksomheten, hvordan kan dette uttrykkes i modellen? (Husk at hver virksomhet er forutsatt å ha hver sin database.) Ved å sette skranken {disjunkt} mellom de to underberepene i underberepskonstruksjonen. d) Det unike satsnummeret vil være delvis informasjonsbærende. Hvordan kan vi se dette av modellen? Fordi assosiasjonen mellom Sats o Produsent er merket «identifyin». Berunn hvorfor satsnummeret tilfredsstiller kravet om at identifikatoren skal være stabil. Når en sats en an er produsert av en produsent, vil den aldri få en annen produsent. Dette kan eventuelt markeres med skranken {immutable} på assosiasjonen mellom Sal o Produsent. Sensorveilednin - eksamen i INF1050 Side 3 av juni 2006

4 e) Marker rafisk i modellen en skranke som uttrykker at en kunde som kjøper en produktsats ikke er produsent av den. Tre momenter er viktie her: - det dreier se om en {unequal}-skranke - den omfatter to roller på hver side (sats o virksomhet) - den år mellom assosiasjonene Sats-Produsent o Kunde Produktsats Løsninen forutsetter eentli enetraliserinen fra b) Oppave 2 (20% 36 min.) Produksjonsvirksomheter benytter se av oppskrifter (resepter) som forteller hvilke inredienser o hvor mye av dem som skal innå i hver enkelt sats. I den følende tabelldatabasen er det som eksempel lat inn to oppskrifter på bakeprodukter. Produkt Resept produktnr produktnavn produktnr inrediens mende enhet bolle rubrød mararin melk jær dl salt 0,5 ts sukker 1 dl kardemomme, malt 2 ts hvetemel 750 e 1 stk mararin 50 melk 6 dl jær 50 sirup 2 ss salt 2 ts rumel 400 hvetemel 350 a) I tabellen Resept manler det en entydihetsskranke. Over hvilke attributter vil du sette den? produktnr inrediens b) Er hver enkelt av disse tabellene på Boyce-Codd normalform? Hvis ikke, hva må jøres for å få dem over på denne formen? Produkt er åpenbart på BCNF. I Resept kommer det an på om enhet er funksjonelt avheni av bare inrediens. Måles for eksempel mararin alltid i ram? I så fall skal inrediens o enhet skilles ut i een tabell. Hvis enhet er funksjonelt avheni av både produktnr o inrediens (mararin kan for eksempel bli anitt i k i forbindelse med andre produktnr), er tabellen allerede på BCNF. Sensorveilednin - eksamen i INF1050 Side 4 av juni 2006

5 c) Hvilken referanseinteritet er det nærliende å etablere mellom de to tabellene? Fra Resept.produktnr mot Produkt.produktnr. Gjør rede for de to ulike måtene denne referanseinteriteten kan bli brutt på, o hva som bør skje i hvert av de to tilfellene. - Forsøk på å lee inn et produkt i resept som ikke allerede finnes i produkt. Enten stopp av oppdaterinen med feilmeldin, eller (bedre) å inn i en underdialo der en ny forekomst i Produkt kan lees inn. - Forsøk på å fjerne et produkt fra Produkt som finnes i Resept. Enten stopp av oppdaterinen med feilmeldin, eller en kaskaderende delete etter spørsmålet ønsker du virkeli å fjerne dette produktet med tilhørende resept (oppskrift)? d) Sett opp en SQL-kommando som enererer tabellen Produkt (uten forekomster). CREATE TABLE Produkt (produktnr CHAR(10), produktnavn CHAR(30), CONSTRAINT Entydiproduktnr PRIMARY KEY (produktnr) ); e) Sett opp en SQL-kommando som enererer en virtuell tabell (et "view") som inneholder en tabell med de produktnr som har inrediensen sukker. CREATE VIEW Sukkerprodukter AS SELECT produktnr FROM Resept WHERE inrediens = sukker ; (evt. med DISTINCT) f) Sett opp en SQL-kommando som ir en tabell over alle produktnr som har både sukker o jær som inredienser. Litt vanskeli oppave vi må joine Resept-tabellen med se selv: SELECT R1.produktnr FROM Resept R1, Resept R2 WHERE R1.produktnr = R2.produktnr AND R1.inrediens='sukker' AND R2.inrediens='jær'; Alternativt kan vi bruke den virtuelle tabellen fra forrie deloppave: SELECT produktnr FROM Resept Sukkerprodukter WHERE Resept.produktnr = Sukkerprodukter.produktnr AND inrediens = jær ; ) Sett opp en SQL-kommando som ir en tabell over hvor mane produktnr som inneholder sukker. SELECT COUNT(produktnr) FROM Resept WHERE inrediens = sukker ; h) Sett opp en SQL-kommando som ir en tabell over hvor mane inredienser hvert av produktene identifisert ved produktnr inneholder. SELECT produktnr, COUNT(*) FROM Resept GROUP BY produktnr; Sensorveilednin - eksamen i INF1050 Side 5 av juni 2006

6 i) Sett opp en SQL-kommando som ir en tabell med oppskriften på bolle, der produktnr ( ) er erstattet med produktnavn ( bolle ). SELECT Produkt.produktnavn, inrediens, mende, enhet FROM Produkt Resept WHERE Produkt.produktnr = Resept.produktnr AND Produkt.produktnr = ; j) Utvid datamodellen fra oppave 1 slik at den oså kan brukes som utanspunkt for å enerere denne tabelldatabasen. Vi må i alle fall ha klassene Produkt o Inrediens med en mane-til-maneassosiasjon mellom. På denne assosiasjonen hener vi en assosiasjonsklasse med attributtene mende o enhet (hvis enhet hører hjemme her, jfr. deloppave b). Til slutt kan Produkt o Inrediens knyttes til henholdsvis Produktsats o Inredienssats med en-til-mane-assosiasjoner. k) Hvis det er vikti å få ut inrediensene i en bestemt rekkeføle hva må jøres med tabelldatabasen da? Da må vi ha et sorterinskriterium. Hvis inrediensene skal listes alfabetisk, er modellen allerede OK. Hvis ikke, kan de fleste krav til sorterin løses ved å lee til et attributt inrediensnummer. l) Mane resepter/oppskrifter har variasjoner for eksempel får man rosinbolle ved å føye til inrediensen rosin til runnoppskriften for bolle. Foreslå en løsnin for hvordan slike variasjoner kan inkluderes i tabelldatabasen. Det enkleste er å i slipp på skranken om at produkter o produktsatser ikke kan brukes som inredienser o inredienssatser i een virksomhet. Da er en rosinbolle sammensatt av inrediensene bolle o rosin. m) Data fra tabelldatabasen skal kunne vises fram i en nettleser. Nevn de etter din personlie menin to viktiste eenskapene ved prorammerinsspråket PHP som jør det spesielt velenet for dette formålet. Her kan nevnes: - PHP kan intereres i XHTML-kode - PHP er sterkt på tenstrenbehandlin - PHP har et bibliotek med rensesnittrutiner mot jense databasehåndterinssystemer. Oppave 3 (20% 36 min.) I denne oppaven skal du lae en objektorientert utformin (desin) av et bruksmønster som heter Oppdater kunde. Du skal her anta at en kunde er beskrevet i en klasse med et ornr o kontaktperson. Bruksmønsteret skal helt enkelt i aktøren (som er produsent for kunden) mulihet til å oppdatere kontaktpersonen til en itt kunde. Du skal anta at aktøren allerede vet ornr for kunden o at aktøren oppir dette ved oppstart av bruksmønsteret. Systemet skal deretter vise det amle kontaktnavnet til aktøren o i aktøren mulihet til å endre det. Til slutt skal systemet bekrefte Sensorveilednin - eksamen i INF1050 Side 6 av juni 2006

7 overfor aktøren at oppdaterinen ble utført. Dersom det ikke finnes en kunde med det oppitte ornr, skal bruksmønsteret i en feilmeldin o avslutte handlinsforløpet. I følende tre deloppaver (3a, 3b o 3c) skal du fullføre henholdsvis tekstli spesifikasjon av bruksmønsteret, sekvensdiaram for normal hendelsesflyt o klassediarammet som tilsvarer sekvensdiarammet for normal hendelsesflyt. NB! Les hele oppaveteksten før du starter o sør for at den tekstlie spesifikasjonen tilsvarer (er konsistent med) sekvensdiarammet, som i sin tur tilsvarer (er konsistent med) klassediarammet. a) Spesifiser bruksmønsteret med normal hendelsesflyt o variasjoner ved å fullføre vedleet til oppave 3a: Navn: Oppdater kunde Aktør: Produsent Trier: En kunde har fått ny kontaktperson Normal Hendelsesflyt: 1. Produsenten oppir kundens ornr 2. Systemet finner kunden o viser navn på kontaktperson 3. Produsenten ir nytt navn på kontaktpersonen 4. Systemet bekrefter at reistrerinen er utført Variasjoner: 2a. ornr finnes ikke i systemet: 2a1. Systemet ir feilmeldin o avslutter b) La et sekvensdiaram for normal hendelsesflyt (som du spesifiserte i oppave 3a) ved å fullføre vedleet til oppave 3b. Sensorveilednin - eksamen i INF1050 Side 7 av juni 2006

8 Produsent : Kant kundere: KundeReister k: Kunde ok:=oppdaterenkunde(ornr) <<create>> oppdaterkunde(ornr) :OppdaterKunde k:=finnkunde(ornr) ammeltnavn := ikontaktperson() viser ammeltnavn oppir nyttnavn nyttnavn := beomnyttnavn(ammeltnavn) oppdaterkontaktperson(nyttnavn) oppdaterin OK bekreftoppdatertkunde(true) c) La et klassediaram for sekvensdiarammet (som du spesifiserte i oppave 3b) ved å fullføre vedleet til oppave 3c. OppdaterKunde oppdaterkunde(ornr: Strin) Kant KundeReister oppdaterenkunde(ornr: Strin) beomnytt(ammeltnavn: Strin) : Strin bekreftoppdatertkunde(ok: Boolean) finnkunde(ornr): Kunde 1 Kunde ornr: Strin kontaktperson: Strin ikontaktperson() : Strin oppdaterkontaktperson(nyttnavn : Strin) * Sensorveilednin - eksamen i INF1050 Side 8 av juni 2006

9 Oppave 4 (10% 18 min.) Hva Hva Hvordan Hvordan Refleksjon Analyse Utformin Vurderin Planlein Forandrin Realiserin Reulerin Produkt Styrin Ovenstående fiur viser hovedaktivitetene i systemutviklinsprosessen. a) Hvilken av disse hovedaktivitetene omfatter slike aktiviteter som evaluerin av et produsert informasjonssystem? I føle læreboka er evalueriner en styrinsaktivitet o innår i hovedaktiviteten Vurderin. Det kan imidlertid være like rikti å se det som en aktivitet som innår i Realiserin. b) Anta at et informasjonssystem skal utvikles i samsvar med en inkrementell metode. La en kopi av fiuren (det er tilstrekkeli å tene opp de seks hovedaktivitets-rektanlene tekst er ikke nødvendi så lene de er plassert på samme måte) o vis med en sammenhenende strek med pil i spissen i hvilken rekkeføle hovedaktivitetene jennomløpes. Løsninen består anske enkelt i en omtenin av lærebokas fiur 2-6, omtrent som vist nedenfor. Eventuelt kan det bemerkes at det er muli å å litt fram o tilbake i Vurderin, Planlein o Reulerin (derfor er dobbeltpilene markert svarte.) Hva Hva Hvordan Hvordan Refleksjon Analyse Utformin Vurderin Planlein Forandrin Realiserin Reulerin Produkt Styrin Oppave 5 (10% 18 min.) Vi antar at informasjonssystemet som skissert i innledninen, med en database som tilsvarer datamodellen i oppave 1, faller inn under Personopplysninsloven. Sensorveilednin - eksamen i INF1050 Side 9 av juni 2006

10 a) Gi en berunnelse for dette (ev. at systemet ikke faller inn under loven) Systemet vil inneholde informasjon som direkte eller indirekte kan knyttes til fysiske personer. Dette jelder både produsenter av råvarer (bønder) eller produsenter som slakter o baker som kan være en-manns-firma (selv om dette ikke er så vanli lener). b) På hvilket rettsli runnla kan virksomhetene som vil benytte systemet, troli få hjemmel til å behandle personopplysninene? Loven sier: 8. Vilkår for å behandle personopplysniner Personopplysniner (jf. 2 nr. 1) kan bare behandles dersom den reistrerte har samtykket, eller det er fastsatt i lov at det er adan til slik behandlin, eller behandlinen er nødvendi for a) å oppfylle en avtale med den reisterte, eller for å utføre jøremål etter den reistrertes ønske før en slik avtale innås, b) at den behandlinsansvarlie skal kunne oppfylle en rettsli forpliktelse, c) å vareta den reistrertes vitale interesser, d) å utføre en oppave av allmenn interesse, e) å utøve offentli myndihet, eller f) at den behandlinsansvarlie eller tredjepersoner som opplysninene utleveres til kan vareta en berettiet interesse, o hensynet til den reistrertes personvern ikke overstier denne interessen. Det beste korte svaret er at reistrerinen av dataene er nødvendi - særli pa. d) o e). En annet odt svar er at behandlinen kan være hjemlet jennom en forskrift til Matloven. c) Må virksomhetene søke om konsesjon for å behandle personopplysninene? Berunn svaret! Nei, konsesjon er ikke nødvendi fordi sensitive opplysniner (helse,..) ikke vil bli laret. Datatilsynet kan do pålee konsesjonsbehandlin, men terskelen for å jøre det er høy. Oppave 6 (20% 36 min.) Ansvarli departement har besluttet at et informasjonssystemet som skissert i innledninen skal tas i bruk. Departementet er imidlertid i tvil om hvilken overordnet løsnin som er best, o vurderer to ulike alternativer. Den ene løsninen er basert på det syn at dette informasjonssystemet er et offentli anliende. Det offentlie beviler nødvendie midler o ir Mattilsynet ansvaret for at en sentralisert løsnin blir utviklet der alle aktuelle virksomheter skal reistrere sine data. Den alternative løsninen er basert på det syn at sikrin av tilstrekkelie data for å oppnå sporbarhet er noe alle involverte har et ansvar for. Hver virksomhet vil da bli pålat å reistrere nødvendie data i et system de selv må anskaffe o drifte. Mattilsynet vil da spesifisere krav til systemet i form av nødvendi minimumsfunksjonalitet, o hvilke data som må reistreres. Basert på slike spesifikasjoner (som vi kan kalle en standard) kan så ulike private datafirmaer utvikle sine ene løsniner o konkurrere om å få Sensorveilednin - eksamen i INF1050 Side 10 av juni 2006

11 solt disse til de aktuelle virksomhetene. a) Anta at du er ansatt i et firma som skal i et anbud eller tilbud på en sentralisert løsnin. Beskriv en systemutviklinsstratei for dette alternativet. Vurder styrker o svakheter ved denne løsninen o den systemutviklinsstrateien du har beskrevet. Du bør spesielt vurdere i hvilken rad reler for offentlie innkjøp setter rammer for utviklinen av denne løsninen o hvilken innvirknin dette vil ha. b) Anta at du er ansatt i et firma som vil utvikle en prorampakke for sal i samsvar med det andre alternativet. Beskriv en systemutviklinsstratei for dette alternativet. Vurder styrker o svakheter ved denne løsninen o den systemutviklinsstrateien du har beskrevet. c) Gi en anbefalin til ansvarli departement anående hvilken løsnin o hvilken systemutviklinsstratei som bør pålees leverandørene. Du må her jerne anbefale en annen løsnin enn de to som er beskrevet ovenfor. Berunn svaret. Det er hovedsakli to strateier man kan vele mellom 1) En top-down, spesifikasjonsdrevet, fossefallsorientert stratei, eller 2) En variant av en mer bottom-up, evolusjonær, eller inkrementell stratei. De viktiste parametrene for val av stratei er kompleksitet o usikkerhet. Det er ijen to hovedtyper av ukjenthet: ustabile omivelser o manel på kunnskap (om hva brukerne behøver eller hvordan aktuell teknoloi virker) Det systemet som er beskrevet her er av moderat kompleksitet o usikkerheten er relativt lav. Do kan krav utover det som er oppitt i oppaven endre dette. Det kan for eksempel komme ønsker om å interere systemet på ulike nivå med andre systemer innen det offentlie, eller ønske om bruk av ulike typer ny o fancy teknoloi (for eksempel. Web services, ) der man er usikker på for eksempel teknoloiens kapasitet. Kombinasjon av moderat kompleksitet o usikkerhet jør at nær sat en hvilken som helst stratei bør funere. Derfor er det i liten rad et fasitsvar på denne oppaven. Deloppave a) inviterer imidlertid mer til en brukerdrevet, evolusjonær prosess (smidi eller lett metode) fordi vi kan forutsette tilan til brukermiljøene, do vil reler om offentli innkjøp (punkt a) være en ramme som kan framtvine en anbudseller tilbudsprosess o dermed en spesifikasjonsdrevet prosess. Under deloppave b) må man ta utanspunkt i Mattilsynets "standard" som er beskrevet i innledninen til oppaven dette inviterer til en mer fossefallsorientert prosess. Sensorveilednin - eksamen i INF1050 Side 11 av juni 2006