Innholdsfortegnelse. 1.1 Formålet med systemet Systemdefinisjon Problemområdet...4

Transkript

1 1

2 Innholdsfortegnelse 1. Prosjektbeskrivelse HuskerDu Formålet med systemet Systemdefinisjon Kontekst Problemområdet Interesseområdet Brukergrupper og funksjonalitet Juridiske rammer Interesseområdet Introduksjon til interesseområdet Kravspesifikasjon Overordnet systembeskrivelse Funksjonelle krav Kvalitetsmessige krav Rammer Bruk Brukere Aktører Bruksmønstermodell Bruksmønstre og spesifikasjoner Aktøren 'publikator's bruksmønstre Aktøren 'informasjonsmottaker's bruksmønstre Analyse av bruksmønstre Sekvensdiagram Kommentarer til sekvensdiagrammer for Normal Hendelsesflyt Kommentarer til Variasjon 2a.1: Brukeren har ingen meldinger å endre Kommentarer til Variasjon 5a: Publiseringsdato før endringsdato Kommentarer til Variasjoner 6a: Feil stopper endring en Trelagsarkitektur Klassediagram Klassediagrammet Problemområdet Introduksjon til problemområdet Struktur Beskrivelse av elementene i problemområdet Kommentarer til ugruppert klassediagram Ugruppert UML klassediagram Betraktninger av grupperingsprosessen Betraktninger om fasing ut av klasser Gruppert UML klassediagram Databasen Skranker Entydighets skranken Primary key og multiplisitetsskranker Foreign key og delmengdeskranker Databasediagrammet Tabellene Spørringer mot databasen, SQL Diskusjon om forskjeller i klassediagrammene Prototypen Presentasjon av prototypen Design av brukergrensesnitt Betrakninger om valg av design Brukerdokumentasjon Logg inn for administrasjonen Innloggingen var vellykket Opprette melding til emne Skriv melding Slette/endre melding

3 Endre melding Slette melding Oversikt over meldinger Alle egne publiserte meldinger Allepubliserte meldinger Abonnement siden Registrering for systemadministrator Registrer en ny bruker Vurdering av HuskerDu Oppnår HuskerDu de mål som ble satt? Enfringer foretatt etter avluering av systemet Evaluering av prosjekt Rimi vaktbyttesystem BlackBox-evaluering WhiteBox-evaluering Våre oppfatninger om og forventninger til systemet Validerende tester Empirisk brukertest Verifiserende tester Funksjonell, empirisk test Walkthrough Scenario i interesseområdet - innhenting av informasjon Vurdering av brukergrensesnittet Kvalitetsmessige krav Konklusjon Kommentarer til brukerdokumentasjon Empirisk inspeksjon Skallet og inn Bruksmønstrene til ansatte Bruksmønster til ledelse Sekvensdiagrammer Klassediagram Kjernen og ut Ugruppert klassediagram Gruppert klassediagram Databasediagram Oppsummering...42 Kilder...43 Vedlegg A Betrakninger om hvordan Personopplysningsloven berører systemet. Vedlegg B SQL-kode Vedlegg C - Hvorfor ATOM? Vedlegg D PHP-kode 3

4 1. Prosjektbeskrivelse HuskerDu 1.1 Formålet med systemet HuskerDu har som formål å forbedre og kvalitetssikre informasjonsdistribusjon og informasjonsflyt mellom de ulike aktørene på et universitet (se fig.1). 1.2 Systemdefinisjon En sentral utvikling i den senere tid er at internettbaserte tjenester, som eksempelvis nettaviser, publisererer såkalte newsfeeds, eller nyhetstrømmer. Disse nyhetsstrømmene er spesielt utformede XML-dokumenter1 som kan leses av spesielt utformet programvare, ofte kalt aggregatorer eller nyhetslesere. En slik nyhetsleser henter periodisk ned XML-dokumentene brukeren har abonnert på, og presenterer nye meldinger for brukeren etterhvert som disse kommer inn. HuskerDu er en løsning der de ansatte ved universitetet kan publisere slike nyhetsstrømmer ment for studentene, og studentene skal i sin ende kunne abonnere på disse nyhetsstrømmene. 1.3 Kontekst Universitetet i Oslo er en en utdanningsinstitusjon med åtte fakulteter og 47 institutter. Universitetet har studenter og ansatte (2002-tall), hvor omtrent halvparten av de ansatte er vitenskapelig personell som forelesere, forskere og så videre. Et universitetet er fra studentens side organisert slik at studenten deltar i ett eller flere fag. Fag undervises av en eller flere vitenskapelig ansatte, mens det finnes administrativt og teknisk ansatte på ulike vis betjener både studenten og de ulike vitenskapelig ansatte Problemområdet I en ideell verden ville alle studenter alltid motta all nyttig og relevant informasjon. Den virkelige verden er dessverre annerledes; studenter uteblir fra forelesninger, sjekker ikke de ulike fagenes hjemmesider, og epost går tapt. Det som kjennetegner dagens kommunikasjonsform er at den er spredt over flere ulike medier, og består av en miks av informasjon studentene aktivt må oppsøke (eksempelvis faghjemmesider), eller som de mottar passivt (eksempelvis epost). HuskerDu skal i størst mulig grad sikre at informasjonen alltid når frem, ved å tilby abonnement på all ønsket informasjon fra ett medie. Studenten trenger kun å gå aktivt inn og sette opp abonnementet for informasjonen én gang. Jobben blir enklere for de ulike gruppene av ansatte, som får én kanal å publisere informasjon i, der de også 1 Det finnes to utbredte formater for dette: Atom og RSS 4

5 vet at informasjonen kommer fram til studenten Interesseområdet HuskerDu vil benyttes primært av ansatte, og av studenter ved universitetet. Studenter melder seg på de forskjellige nyhetstrømmene til fag, og ansatte ved universitetet sender beskjeder vedrørende disse fagene. Dermed unngår man kommunikasjon i mange medier. HuskerDu blir et verktøy for å konsolidere informasjonen studentene vil motta inn i en kanal. Dette vil foregå enkelt og raskt. Tap av informasjon reduseres i forhold til kommunikasjonsverktøy som brukes i dag, da at studentene passivt kan motta relevant informasjon. 1.4 Brukergrupper og funksjonalitet For publikatoren (den ansatte) skal HuskerDu fungere som et enkelt enhetlig webbasert grensesnitt for å publisere informasjon ment for studenter og andre som abonnerer på informasjonen. Publikatoren skal kunne publisere nye meldinger, alternativt endre eller slette gamle meldinger, og det skal finnes en oversikt over meldinger denne brukeren tidligere har publisert. Publikatoren skal plassere meldingene i ulike kategorier når de opprettes, slik at informasjonen bare når de som trenger den. Studenten forblir passiv etter den har valgt hvilke fag den vil abonnere på. Etter hvert semester resirkuleres databasen, og man må igjen abonnere på kurs man ønsker informasjon fra. 1.5 Juridiske rammer Prosjektet vil behandle opplysninger som kommer inn under loven om behandling av personopplysninger, 2.1 Def Personopplysninger. Dette er opplysninger og vurderinger som kan knyttes til en enkeltperson. Prosjektet vil derfor måtte følge de rammer som er gitt av 'Lov om behandling av personopplysninger'. Hvordan disse krav får konsekvenser for prosjektet, er beskrevet i Vedlegg A2. Det er i hovedsak tre grunnkrav for alle informasjonssystemer der personopplysninger inngår: Det må være et rettslig grunnlag for behandling av personopplysningene. Vi bruker lov om samtykke som rettslig grunnlag3. Det må være et forhåndsdefinert formål med behandlingen. Formålet med behandlingen er å få distribuert all informasjon på Universitetet gjennom en kanal, ved hjelp av Newsfeeds (Atom standard)4. Personopplysningene må tilfredsstille visse grunnleggende krav til kvalitet5. Lovens 31 sier at alle systemer som kommer inn under 'Lov om personvernopplysninger' må sende inn en melding til Datatilsynet. Meldingen skal være skrevet i henhold til 32, som angir hva meldingen skal inneholde. Denne meldingen må sendes inn minst 30 dager før systemet taes i bruk. Et forslag til melding til Datatilsynet om behandling av personopplysninger i HuskerDu finner du på neste side. Som rettslig grunnlag kunne vi også brukt lovens 8.a, som sier en kan registrere og behandle personopplysninger i den intensjon å oppfylle en avtale gjort med den registerte. Paragrafen sier videre at en også kan behandle personopplysninger for å utføre gjøremål etter den registrertes ønske, selv før en slik avtale inngås. Da vi er litt usikre på tolkningen av denne og hvilke kotymer som eksisterer i bransjen, sikrer vi oss ved å inngå en avtale med brukeren. Avtalen må underskrives eller på en eller annen måte bekreftes før personen Vedlegg A pkt Vedlegg A pkt. 2.1 Ref pkt (Prosjektbeskrivelsen) Ref. Vedlegg A pkt

6 blir akseptert som bruker av systemet6. I avtalen gjøres den registrerte oppmerksom på hvordan personopplysningene vil bli behandlet og hans/hennes rettigheter. Den registrerte må aktivt samtykke i at han/hun blir registrert i personregisteret og har forstått avtalen. En slik avtale gir oss i tillegg mulighet til å bruke dataene i statistisk øyemed. Når det gjelder opphavsrett er dette regulert av Åndsverkloven. Lovens generelle prinsipp er at de som har frembrakt verket får opphavsretten, mao. de respektive medlemmer av HuskerDu prosjektet. Hvorvidt UiO står som en slags arbeidsgiver som har gitt en anvisning, og dermed kunne ha krevd retten, går vi ikke videre inn på her. Heller ikke om databasen når tilstrekkelig verkshøyde til og være beskyttet av åndsverkloven drøftes i denne omgang. Datatilsynet Verste Oslo Øst 0000 OSLO HuskerDu Prosjektet 2004 v/prosjektleder Geir A Nilsen Informatikk UIO geirn@huskeru.no OSLO Melding til Datatilsynet om behandling av personopplysninger Lov om behandling av personopplysninger (personopplysningsloven) berører prosjektet Huskeru. Rettslig grunnlag er beskrevet i Vedlegg A1. Prosjektet går over i drift 1. juni og Miriam Nes vil oppfylle den behandlingsansvarliges plikter. Ingunn Rønningen vil være databehandler. Formålet med behandlingen er å få distribuert all informasjon på Universitetet gjennom en kanal ved hjelp av Neewsfeeds (Atom standard). Det rettslige grunnlaget for innsamlingen av data er avtale2 som gjøres med brukeren. De personopplysninger som skal behandles er navn, , institutt og kurs/emne. Kurs/emne er i utgangspunktet ikke i seg selv personopplysninger, men kombinert med de andre kan de knyttes til en enkeltperson. Alle personopplysningene som registreres, blir hentet inn via Webgrensesnittet. De registrerte taster selv inn all informasjon. Systemet og plattformen ligger trygt forvart bak brannmure, passordbelagte interface, og i universitetets eget drifts miljø. Personopplysningene internt vil ikke bli utlevert til noen utenfor Prosjektet. Det er umulig å kontrollere hvilket land som laster ned newsfeedene da mottakeren er anonym. Vi ber om unntak fra Personopplysningsloven 30, da brukere blir informert om dette. Behandlingsansvarlig underskrift Miriam Nes menes@huskerdu.no Databehandler(representant) underskrift Ingunn Rønningen ieronnin@huskerdu.no Med vennlig hilsen HuskerDu 2004 v/ Prosjektleder underskrift Geir A Nilsen 6 Vedlegg A pkt. II.X 1 Vedlegg A pkt. II.VII. 2 Vedlegg A kt II.XII 6

7 2. Interesseområdet «Interesseområdet» er en betegnelse den delen av verden informasjonssystemet skal dreie seg om. Å begynne utformingen av et system med kravspesifikasjon og analyse av hva slags brukere systemet skal ha, hva slags aktører systemet skal betjene, og hva disse aktørenes mål er, er en måte å bygge systemet på fra utsiden og inn. En tar da utgangspunkt i interessområdet. Det er denne fremgangsmåten som er beskrevet i del 2 av prosjektbeskrivelsen. 2.1 Introduksjon til interesseområdet Som studenter har vi god innsikt i studentenes eksisterende arbeidsprosesser. Gjennom samtaler med potensielle brukere medstudenter- og ved å diskutere innad i gruppen, som jo er en delmengde av brukergruppen studenter, skaptes en oppfatning av hvordan systemet skal fungere for studentgruppen. Systemet er ment å være enkelt og automatisert for studentene. Også til brukergruppen 'ansatte ved universitetet' har vi forsøkt å få innsikt i nåværende arbeidsprosesser ved informasjonsdistribusjon. Slik vi kjenner tilsvarende systemer, er det særlig gruppelæreresom mangler en enhetlig informasjonskanal. Informasjon til gruppebarn fra gruppelærer skjer hovedsakelig via , der bytting av grupper kan gjøre at informasjon kommer feil. Også hjemmesider er mye brukt, ofte i sammenheng med mail. Resultatet er rotete, blir gitt i ulike media og på ulike måter internt i gruppene, og tilfredstiller ikke krav til enhetlig informasjonsgiving. Det er heller ingen sikkerhet i at informasjonen kommer frem og dit den skal. Øvrige ansatte, administrasjon og forelesere, har i dag ved Universitetet i Oslo og Høyskolen i Oslo liknende informasjonsdistribusjonssystemer som HuskerDu. Disse publiseres enten på hjemmesider til fag, eller via mail til studenter, eller gjennom personlig tilpassede web-sider via innlogging i portaler, slik som UiO's 'Mine Sider'. Det siste alternativet likner det HuskerDu er ment å fremstå som, med tre viktige forskjeller: 1) Gjennom HuskerDu skal alle interessenter kunne abbonere nøyaktig den informasjon som er ønsket, slik at også andre enn studenter skal kunne få personlig tilpasset informasjon. 2) Istedet for at systemet genererer 'tilpassede' sider, kan abbonøren selv legger opp personlige nyhetsstrømmer. 3) Informasjonen lastes ned via en newsfeed-klient i abbonørens web-browser, og kommer slik delvis automatisk og direkte til abbonør. Målet med HuskerDu er å få all informasjon postet via systemet, slik at studentene kan forholde seg til en og bare en nyhetskanal. For å få erstattet informasjonsgiving gjennom mail og nettsider må HuskerDu være et enkelt og brukervennlig system også for brukergruppen ansatte. Vi har valgt å bruke newsfeeds da denne type informasjonskanal samler flere ressurser på ett sted og skaper informasjonsstrømmer. Det finnes to hovedtyper formater innenfor newsfeeds; ATOM og RSS. HuskerDu kan legge til rette for å bruke en eller begge disse. Vi har valgt å ta utgangspunkt i ATOM-standardene. Grunnen til dette er at vi mener ATOM er enklere å jobbe med7. Vi synes ATOM har et bedre datoformat enn RSS, har bedre definert og klarere spesifisert meldingsidentifikatorer, og har mer nøyaktig måte å beskrive alternative ressurser og formater på. Dessuten mangler RSS en entydig måte å publisere meldinger på. Dette har ATOM. Fordelen med RSS, er at det i dag er flere browsere som støtter RSS enn som støtter ATOM. Kravspesifikasjon ble utviklet supplert med inkrementell systemutvikling. Inkrementell utvikling vil si å utvikle stadig bedre systemversjoner gjennom analyse, prototyping, og reflektering. Vi har arbeidet inkrementelt gjennom å stadig skrive nye utkast til brukerinterface i HTML, til tankeprosessene om hvordan brukerinteraksjon skal foregå, og hva som er nødvendige funksjonaliteter. 2.2 Kravspesifikasjon De ytre kravene til systemet er her satt opp, uten å beskrive indre utforming av systemet Overordnet systembeskrivelse 7 Se Vedlegg C: Hvorfor ATOM? for mer informasjon. 7

8 Denne kravspesifikasjonen gjelder et informasjonssystem som skal formidle informasjon fra ansatte på et universitetet til studentene ved universitetet, og eventuelt andre interesserte. Formålet er å få all informasjon kanalisert gjennom en nyhetsstrøm, for slik å lette informasjonsflyten og minske tap av informasjon Funksjonelle krav Systemet skal kunne autentisere brukere Systemet skal kunne opprette og poste en meldingen Systemet skal kunne endre en melding Systemet skal kunne slette en melding Systemet skal kunne gi en bruker oversikt over hans/hennes meldinger Systemet skal kunne gi en oversikt over alle meldinger som er gitt Kvalitetsmessige krav Systemet skal være så brukervennlig og intuitivt at en person som allerede er vant til å bruke datamaskin, umiddelbart eller etter få minutter skal kunne bruke systemet. Om det oppstår feil skal brukeren alltid få feilmelding. Systemet skal ha minimalisert nedetid når oppdateringer foretas av systemadministrator/drift. Systemet skal være enkelt å vedlikeholde for systemadministrator Rammer Systemet skal være plattform-uavhengig. Brukerinterfacet bør være web-basert, også for publikatorene. Systemet bør legge til rette for at standarder i newsfeed kan følges, for eksempel følge rss-newsfeed eller atom-newsfeed standarder, avhengig av hvilke newsfeed-klienter systemet legger opp til at abonnementet skal bruke. Systemet rammes av Personopplysningsloven, og må følge lovmessige rammer som beskrevet i vedlegg A i denne prosjektbeskrivelsen. Implementering av systemet ved Universitetet, derunder opplæring av driftansvarlige, bør kunne fullføres i løpet av to måneder. Systemet må informere publikatorer om bruk og oppbevaring av informasjonen som blir lagt inn i systemet. Utviklingen av systemet skal ikke koste mer enn kr Bruk De funksjonelle kravene som kommer frem av kravsspesifikasjonen kan beskrives på ulike måter. I moderne systemutvikling er det vanlig å bruke UML-bruksmønstermodeller, og det er det som er brukt i denne prosjektbeskrivelsen. For å komme frem til bruksmønstermodellene må vi først se på hvilke brukere og aktører systemet skal ha Brukere Hvem som utvikler systemet og deres motivasjon vil ha betydning for hvilke brukergrupper som kommer i fokus. Fra studentenes synspunkt er det studenter som vil være primærbrukere av systemet. Systemet er til for dem, for å sikre at de får all den nødvendige informasjon fra ulike instanser ved universitetet på en samordnet og personlig tilpasset måte. De ansatte ved universitetet, både gruppelærere, forelesere, administrasjonen og øvrige, blir således sekundær-brukere, som legger til rette for primærbrukerne. Fra de ansatte ved universitetet, er systemet derimot like mye til for dem som for studentene. De vil derfor kanskje hevde at systemet bør legges til rette spesielt for dem, mens det for studenter/øvrige brukere mer generelt skal være nyttig. Det er de ansatte det spesifikt kan legges til rette for ved å ta hensyn til rutiner ved universitet, og arbeidsprosseser i hverdagen. 8

9 Hvem av brukergruppene som er primærgruppe, og hvem det skal taes mest hensyn til under utformingenav systemet, er likevel en diskusjon litt på siden av problemområdet vårt. Fra utviklers synspunkt bør de hensyn taes som kan taes, nemlig spesielle hensyn til publikatorene og generelle hensyn mot abbonørene. Uten å gi publikatorene et system som fungerer opp mot det optimale av deres forventninger, vil ikke systemet bli brukt, så da spiller det liten rolle hvor brukervennlig systemet er for abbonentene. Begrenset finansiering er uansett en stopper for å utvikle et spesielt tilpasset system. Det vil være naturlig at det er universitetet som betaler utviklingen av systemet. Da må det også være en indre motivasjon fra universitetets ledelse og ansatte om å bruke penger på dette. Bedret hverdag for de ansatte vil kunne være en slik motivasjon, og da må de ansattes bruk av systemet komme fokus. Det kan også tenkes at ledelse og politikere kan få motivasjon til å utvikle et slikt system grunnet klager fra studentene på mangelfull/rotete informasjonsdistribusjon. Da er det mer naturlig om de vil ha studentene i fokus under utviklingen. Det vil også tilfellet om systemutviklingen er et uttrykk for ønske om å bedre studiekvalitet. Hvilke brukergrupper som er de viktigste å tilpasse systemet til kommer altså an på motivasjonen bak utviklingen av systemet. For at systemet skal fungere må det taes visse grunnleggende hensyn til alle brukergrupper, både drift, puiblikatorer og abonnører. Hva slags type brukere som er ment å ta i bruk systemet er også viktig, informatikk- og kunststudenter har ulike forutsetninger for å kunne forstå hvordan et datasystem skal brukes. Hvilken grad av datakjennskap forelesere og gruppelærere har vil tilsvarende spille inn på nødvendighet for tilpasning Aktører En aktør beskriver en, og kun en, rolle som en bruker har i forhold til systemet. I dette systemet vil vi ha to typer primære aktører; ansatte og abonnenter. Aktørene avgrenser systemets bruksområder, da vi ikke er interessert i å lage et system som gjør annet enn å tilfredsstille aktørenes behov. Hvilke mål aktørene har dikterer hvilke tjenester systemet skal tilby. Administratorene av systemet kunne blitt ansett som sekundære aktører. En system-administrators oppgaver i systemet er likevel implisitte, det må alltid være noen i bakgrunnen som vedlikeholder og drifter et system. Vi har derfor valgt å se bort fra driftansvarlige i denne sammenheng, men kommer tilbake til denne gruppen under beskrivelse av prototypen. Aktørene og deres tjenester blir beskrevet i en bruksmønstermodell Bruksmønstermodell Bruksmønstermodellen (til høyre) beskriver på et overordnet nivå samhandlingen mellom aktør og system Bruksmønstre og spesifikasjoner Aktørenes mål er utgangspunktet for bruksmønstrene. Et bruksmønster beskriver en komplett sekvens av interaksjoner mellom aktør og system for å oppnå et bestemt mål. Målene som ønskes oppnådd representeres i bruksmønstrene ved triggere. Navn på bruksmønstrene beskriver en brukssituasjon hvor alt går bra. Et bruksmønster består av et bruksmønsterdiagram og en tekstlig spesifikasjon. Spesifikasjoner er: normalt hendelsesforløp og variasjoner av dette. Variasjonene til et bruksmønster er det som skjer dersom det oppstår et problem under interaksjonen, slik at målet ikke automatisk blir nådd. Systemet har så langt fem bruksmønstre for ansatte, der aktøren publikator kan logge inn for deretter å 9

10 opprette, endre og få oversikter over meldinger. Det er kun ett bruksmønster for informasjonsmottakere, nemlig abonnements-opprettelse på informasjonsstrømmer Aktøren 'publikator's bruksmønstre Bruksmønster 1: innlogging Navn: Aktør: Pre-betingelse: Post-betingelse: Trigger: Logg inn Ansatt Aktør må være lagt inn som bruker i databasen. Aktør er logget inn. Aktør vil bruke systemet. Normal hendelsesflyt: 1. Aktør logger inn med brukernavn og passord 2. Aktør får bekreftelse på vellykket innlogging, og får opp meny Variasjoner: 1a. Aktøren er ikke lagt inn som bruker. 1. Systemet gir feilmelding om feil brukernavn/passord 1b. Aktøren skriver inn feil brukernavn eller passord 1. Systemet gir feilmelding om feil brukernavn/passord 2a. Systemet er nede/noe går galt ved innlogging 1. Aktør får feilmelding om innlogging Relatert informasjon: Aktør velger videre handlingsmønster ved å klikke på linker i menyen til alle handlingsalternativer i systemet. Hver link fører til ny web-side. Hvert handlingsalternativ har egne bruksmønstre med spesifikasjoner. Bruksmønster 2: Opprettelse av melding Navn: Aktør: Pre-betingelse: Opprett melding Ansatt Aktør er logget inn og har valgt "opprett melding fra menyen. Post-betingelse: Trigger: Ny melding er opprettet. Aktør ønsker å poste melding. Normal hendelsesflyt: 1. Systemet får inn data om meldingen: 1. Aktør velger fag meldingen skal postes til 2. Aktør skriver inn tittel 3. Aktør skriver beskjed (innhold) 4. Aktør skriver inn publiseringsdato 2. Aktør sender data: 1.Systemet henter opp timestamp-dato til SistEndretdato 3. Systemet bekrefter at melding er postet Variasjoner: 1a. Aktør har ikke rettighet til å poste melding til faget 1. Systemet gir feilmelding om manglende rettigheter 10

11 1b. Aktør har ikke valgt fag å poste til 1.Systemet gir feilmelding om manglende opplysninger 1c. Aktør har ikke tastet inn tittel 1.Systemet gir feilmelding om manglende opplysninger 1d. Aktør har ikke tastet inn publiseringsdato 1.Systemet gir feilmelding om manglende opplysninger 2a. Timestamp-dato er mindre enn publiseringsdato. 1. Aktør får beskjed om at publiseringsdato blir satt til timestamp-dato (sistendret). 2b. Aktør tømmer alle felter og starter på nytt 3a. Systemet er nede/noe går galt ved posting 1. Aktør får feilmelding om postingen Relatert informasjon: Systemet setter automatisk opprettet- og sistendretdato til timestamp-datoen (øyeblikkets dato). Bruksmønster 3: Endre melding Navn: Aktør: Pre-betingelse: Post-betingelse: Trigger: Endre/Slett melding Ansatt Aktør er logget inn og har valgt endre/slette melding fra menyen. Melding må være opprettet av aktøren. Melding kan ikke være publisert, eller bli publisert under en fastsatt tid, her: 1 time, frem i tid. En meldings tilstand er forandret. Aktør ønsker å endre tidligere opprettet melding. Normal hendelsesflyt: 1. Aktør søker på egne meldinger til et fag 2. Systemet viser frem alle upubliserte meldinger til faget, med meldingstittel og id, der id'ene er linker 3. Aktør trykker på meldingsid til melding som ønskes endret 4. Systemet viser alle opplysninger om meldingen, der de som ikke kan endres er grået ut 5. Aktør gjør endringer 6. Systemet bekrefter at endringer er gjort Variasjoner: 2a. Aktøren har ingen meldinger som kan endres 1. Feilmelding skrives ut: Det ligger ingen upubliserte meldinger fra deg knyttet til dette faget 5a Ny publiseringsdato er mindre enn timestamp-dato, og feilmelding skrives ut 6a Meldingen lot seg av ukjent grunn ikke endre, og feilmelding skrives ut Relatert informasjon: Endringer i meldingenes tilstand er et tre-trinns brukerinteraktivt mønster. Først velger aktør å endre, og systemet viser meldingene det er mulig å endre. Så velger aktør en spesifikk melding, og systemet returnerer 11

12 et skjema for å endre denne meldingen. Til sist velger aktør hva slags endringer som skal gjøres, og systemet utfører disse endringene. Sletting av meldinger anses som en variasjon av å endre melding. Selv om aktøren velger å slette meldingen, har vi fremdeles et happy day senario. Meldinger som skal publiseres under en time frem i tid fra aktøren velger "Endre/Slett melding", og starter søk på egne, upubliserte meldinger, regnes som publiserte. Aktøren får dermed ikke adgang til å endre disse. Dette for å unngå en konflikt i systemet, for eksempel at en versjon av en melding publiseres mens samme meldingsid er under endring, en melding publiseres samtidig som den slettes osv Vi antar at det ikke er ønskelig å endre faget meldingen skal publiseres til. Dersom en melding er postet feil, må meldingen slettes ved faget den er postet til og postes på nytt til nytt fag. Når meldingene endres oppdateres automatisk sistendretdato med timestamp. Bruksmønster 4: Oversikt over egne meldinger Navn: Aktør: Pre-betingelse: Trigger: Få oversikt over alle egne meldinger Ansatt Aktøren er logget inn og har valgt "Oversikt over meldinger". Aktør ønsker oversikt over egne postede meldinger. Normal hendelsesflyt: 1. Aktøren velger å få vist alle meldinger aktøren har postet til alle fag. 2. Meldings-id'er, -titler og -innhold til valgte meldinger vises på skjerm. Variasjoner: 1b. Aktøren har ikke postet noen meldinger til valgt(e) fag 1. Systemet skriver ut feilmelding Relatert informasjon: Alle meldinger aktøren har postet blir vist, både publiserte og upubliserte. Bruksmønster 5: Oversikt over alle meldinger Navn: Aktør: Pre-betingelse: Trigger: Få oversikt over alle publiserte meldinger Ansatt Aktøren er logget inn og har valgt "Oversikt over meldinger". Aktør ønsker oversikt over alle publiserte meldinger. Normal hendelsesflyt: 1. Aktøren velger å få vist alle meldinger alle aktører har postet til alle fag, og som er blitt publisert. 2. Meldings-id'er, -titler og -innhold til valgte meldinger vises på skjerm. Variasjoner: 1b. Ingen aktører har publisert noen meldinger til valgt(e) fag 1. Systemet skriver ut feilmelding Relatert informasjon: Aktøren kun vist de publiserte, ikke upubliserte, dette gjelder også aktørens egne meldinger. 12

13 Aktøren 'informasjonsmottaker's bruksmønstre Bruksmønster 6: Abonnements opprettelse Navn: Aktør: Pre-betingelse: Post-betingelse: Trigger: Opprett abonnement Student Aktør har newsfeed-klient. Newsfeed-forbindelse er opprettet. Aktør vil bruke systemet, ved å abonnere på informasjon via newsfeed om emne. Normal hendelsesflyt: 1. Aktør velger emne å abonnere på 2. Systemet returnerer adresse til emnet til newsfeed-klienten 3. Aktør får bekreftelse på vellykket abonnementsopprettelse Variasjoner: 1a. Aktør har ikke newsfeed-klient innstallert 1. Systemet gir mulighet for å laste ned atom-newsfeed-klient 2a. Systemet klarer ikke å returnere adresse til newsfeed-klient/aktørens nettleser. 1. Aktør får feilmelding om adresse-returnering 3a. Systemet er nede/noe går galt ved abonnementsopprettelsen 1. Aktør får feilmelding om abonnementet Relatert informasjon: Aktør velger emne å abonnere på fra drop-down-boks, slik at valgt emne må eksistere. Aktøren får opplysninger om hvordan newsfeed-klient fungerer/hvor informasjon om atom-newsfeed-klient finnes via linker fra abonnementsiden. 2.4 Analyse av bruksmønstre Etter å ha kommet frem til bruksmønstre, kan disse videre ved en objektorientert innfallsvinkel danne grunnlag for sekvensdiagrammer. Til hvert bruksmønster kan det lages et sekvensdiagram, som beskriver hva slags objekter og klasser systemet må ha for å utføre de ønskede handlingene. I en objektorientert arkitektur oppnås systemets totale funksjonalitet ved et samvirke mellom selvstendige objekter. Hvert enkelt objekt har en tilstand det vet noe om seg selv og en oppførsel som gjør at de kan reagere på meldinger utenfra på bestemte måter. I realisering av et objektorientert system ved hjelp av et objektorientert språk, er tilstanden gitt gjennom verdiene lagret i objektets attributter, og oppførselen gitt gjennom metoder. Et viktig prinsipp i objektorienterte systemer er innkapslingsprinsippet. Det sier at omgivelsene ikke skal vite noe om hvordan objekter ser ut inni deres attributter bare hvilke meldinger de reagerer på hvilke metoder objektene har. I noen sammenhenger kan det likevel være nødvendig at et objekts attributter er synlige utenfra, og private metoder i objektet, som aldri skal kalles på fra omgivelsene, trenger ikke være synlige utenfra. Dette fører oss over til to andre prinsipper: Lav kopling-prinsippet og Høy kohesjons-prinsippet. Disse uttrykker at hvert objekt skal samhandle med relativt få andre objekter, og at et objekt ikke skal ha ansvar for mange urelaterte ting. Objektene må med andre ord ha klart avgrensede oppgaver med klart definerte metodekall. Det skal ikke skje at andre objekter endrer et objekts interne attributter uten bruk av metoder. Det er også andre sentrale prinsipper som veileder i utforming av et godt objektorientert system: Kontrollobjekt-prinsippet gir at hvert bruksmønster bør ha et objekt som styrer gjennomføringen. Et resultat av Høy kohesjons-prinsippet er blant annet at det bør opprettes nytt kontrollobjekt for hvert bruksmønster. 13

14 Videre har vi skaperprinsippet, som gir oss føringen at kun det objektet som må vite om nye objekter, skal opprette disse. Dette kommer til uttrykk i våre sekvensdiagrammer ved at kantobjektet er den som oppretter kontrollobjektet. Prinsipp om å isolere mot forandringer tipser oss om at objekter en kan forvente endringer i bør isoleres bak et stabilt grensesnitt. Ifølge ekspertprinsippet skal det objekt som har kunnskap om variable også behandle disse. Objektorienterte systemer bygges også etter flere andre prinsipper enn nevnt her, men disse er det lagt vekt på i utformingen av HuskerDu. For å komme frem til hvilke ansvar hvert objekt skal ha (ansvarsdrevet utforming) for at bruksmønstrene skal kunne gjennomføres, kan man bruke CRC-kort. Det er denne metoden som her har vært brukt for å komme frem til fungerende sekvensdiagrammer Sekvensdiagram UML-sekvensdiagrammer er en mer formell måte å vise samarbeidet mellom objektene på. Det illustrerer handlingsforløpet som følger av at en aktør tar initiativ til å starte opp et bruksmønster. Et av de mest kompliserte brukermønstrene er endre melding. Endre melding er derfor valgt til å vise eksempel på utforming av et sekvensdiagram. Under "endre melding" kan aktørens egne meldinger endre tilstand, enten helt slettes, eller få endrede dataer. Kun brukerens egne meldinger, som ikke allerede er publisert eller skal publiseres innen en time, kan endres eller slettes. Grunnen er at en melding ikke skal kunne endres samtidig som den skal publiseres. Brukeren velger først å endre melding, deretter hvilken melding som skal endres, og til slutt hva slags endringer som skal foretas eventuelt om meldingen skal slettes helt. Sletting av meldinger anses som en variasjon av å endre melding. Det trengs andre metoder for å slette emne enn for å endre melding, og vi har derfor valgt å tenke på slette og endre som to ulike happydays - der alt går bra. For å unngå at sekvensdiagrammet blir for komplisert, beskrives normal hendelsesforløp og variasjoner hver for seg. Det er derfor laget sekvens-diagrammer både for normalflyt og for variasjoner. I alt er det seks sekvens-diagrammer: 14

15 Kommentarer til sekvensdiagrammer for Normal Hendelsesflyt 1.2.2: Testen på om brukeren virkelig finnes, er strengt tatt ikke nødvendig. Brukeren må jo allerede ha blitt verifisert gjennom innloggingen. Testen burde derfor aldri slå til, men er tatt med for å øke systemets robusthet. Siden vi antar at testen ikke vil slå til, er det ikke laget en variasjon til. Timestamp-datoen som sendes med i metodekallet, er timestamp til det nåværende tidspunkt. Upubliserte og endrbare meldinger blir returnert i forhold til dette tidspunktet og meldingenes publiseringsdato. HashMap som returneres til dette kallet, lagres gjennom hele levetiden til kontrollobjektet. 2.1: Meldingsid'en til den valgte meldingen lagres også i kontrollobjektet, gjennom hele dennes levetid : For eksempel syntaktiske feil kan her føre til en variasjon, der endr blir false. Variasjon 5a er et eksempel på en slik feil (publiseringsdatoen har allerede passert). Det er en ekstra metode i bruker for å slette en melding. Det er i normalflyt kun tre avhengighetstester, derav om brukeren finnes, som beskrevet ovenfor ikke har egen variasjon. De to siste avhengighetstestene, utføres en i 1.2.3, og gir variasjon 2a.1, mens den siste skjer rett før funksjonen avsluttes, og resulterer i de resterende variasjonene. Siden denne siste testen skjer rett før funskjonen er ferdig, blir sekvensdiagrammene til variasjonene like som diagrammene til normalflyt frem til siste test. 15

16 Kommentarer til Variasjon 2a.1: Brukeren har ingen meldinger å endre 1.2.3: Dersom HashMap som returneres til 1.2 er tom, vil det si at ingen meldinger oppfylte krav til å kunne endres; det kan være brukeren aldri har distribuert meldinger, at meldingene allerede er publisert, eller at de straks blir publisert Kommentarer til Variasjon 5a: Publiseringsdato før endringsdato Denne variasjonen er tatt med som en spesiell feil ved metoden endreattributter, da det er lagt inn en constraint i systemet på at publiseringsdato må være større (lenger frem i tid) enn endringsdato (som er dagens 16

17 dato). Vær oppmerksom på at også andre feilkilder kan gi endr == false i I så tilfelle vil vi få variasjon 6a, med nøyaktig samme sekvensdiagram, men den boolske verdien endr vil bli falsk av andre grunner Kommentarer til Variasjoner 6a: Feil stopper endring en Av en vilkårlig grunn blir ikke meldingen slettet, det kan være en systemfeil, eller at en annen bruker med skrivetilgang leser eller endrer meldingen, eller andre grunner. Alle slike variasjoner der en melding ikke lot seg slette likevel, vil få identiske sekvensdiagrammer, og gi feilmelding til brukeren (metoden ikkeslettet). Dersom det under testing oppdages typiske gjentatte årsaker til at meldinger ikke kan slettes, kan hendelsesflyten enkelt bygges ut med nye tester i på hva som gikk galt, og mer presis informasjon kan gis brukeren Trelagsarkitektur I en objektorientert utforming fordeles objektene seg i tre lag: Brukergrensesnittlaget: Her ligger grensesnittobjektene som aktiveres av aktøren. Vi har kalt objektet i dette laget kantobjektet fra klassen Kant. Applikasjonslaget: Her ligger kontrollobjektet, dom opprettes av kantobjektet. Kontrollobjektet lagres ikke når bruksmønsteret det inngår i er avsluttet. Vårt kontrollobjekt heter endremelding og opprettes av klassen Endre. Virkelighetsmodellen: I det siste laget ligger de objektene som gjenspeiler interesseområdet. Disse kalles forretningsobjekter. Grensen mellom applikasjonslaget og virkelighetsmodellen kan være noe diffus. I et objektorientert system er virkelighetsmodellen bygget opp av objekter med «oppførsel», som her. I et dataorientert system derimot, inneholder virkelighetsmodellen kun data, og all oppdatering må skje utenfra. Målet er å få objekter som best mulig følger de krav og prinsipper til et objektorientert system som nevnt ovenfor. Bruksmønsteret endre melding har derfor fått tre forretningsobjekter: oversikt av klassen Brukerregister, bruker av klassen Bruker og melding av klassen Melding. De fire klassenes attributter og metoder er beskrevet i et klassediagram. 17

18 18

19 2.4.2 Klassediagram Det er laget UML-klassediagram ut fra de seks sekvensdiagrammene. Klassediagrammet beskriver kun en del av programmet, nemlig bruksmønsteret endre melding med variasjoner. Diagrammet er en modell for klassene som trengs til dette bruksmønsteret, med attributter og metoder til objekter fra klassene. Som i sekvensdiagrammene har klassediagrammet fire klasser, der hvert objekt av klassene vil ha private (usynlige utenfra) attributter, og public (synlige utenfra) metoder. Det var ikke behov for å ha åpne variable, heller ingen private metoder. Forhold mellom klassene er også beskrevet i klassediagrammet Klassediagrammet 19

20 3. Problemområdet En annen måte å utvikle et system på er å først definere problemområdet innenfor interesseområdet, altså danne seg en meget presis oppfatning av interessområdet. Deretter er fokus på hvordan å utvikle et system som modellerer problemområdet. Slik systemutvikling kalles ofte fra kjernen og ut, og er det «motsatte» av hvordan man gikk fram i del 2 av prosjektrapporten. Det er en slik utvikling fra innsiden og utover til brukergrensesnittet vi nå skal ta for oss. Framgangsmåten i del 2 beskrev en objektorientert utvikling, mens det her i del 3 i rapporten vil bli beskrevet en dataorientert utvikling. 3.1 Introduksjon til problemområdet Problemet vi ønsker at systemet skal løse er: studenter ved et universitet skal på en enkel og sikker måte kunne få publisert personlig tilpasset informasjon fra alle instanser ved universitetet gjennom en og samme nyhetskanal. Men hvordan må systemet se ut innvendig for at dette skal kunne virkeliggjøres? I en dataorientert vinkling starter man gjerne med å se på hvordan data bør bli representert innad i systemet. Disse dataene vil da utgjøre systemets virkelighetsmodell. I motsetning til modellen i et objektorientert system, vil modellen i en dataorientert virkelighet være uten metoder. Dataene lagres i tabeller i en database. All endring av dataene skjer ved direkte påvirkning utenfra. 3.2 Struktur For å komme frem til hva slags opplysninger databasen bør inneholde og hvilke datatyper de best vil representeres ved, kan vi strukturere våre oppfatninger om virkeligheten i en datamodell. En slik datamodell kan være et UML-klassediagram over databasen. Et slikt klassediagram kommer man frem til ved å konseptualisere den virkelige verden, det vil si å fange opp det essentielle i interesseområdet. Deretter finner en egnede begreper for å beskrive den virkeligheten en ønsker å avbilde, og forsøker å konkretisere forholdet mellom disse begrepene Beskrivelse av elementene i problemområdet Gjennom å beskrive elementene i problemområdet får man tak i hvordan begrepene opptrer i forhold til hverandre. Visuelt beskrives dette gjennom et ugruppert UML-klassediagram. En kan videre optimalisere hva slags forhold det bør være mellom attributter og tabeller i en datastruktur, ved å gruppere elementene Kommentarer til ugruppert klassediagram Det ugrupperte klassediagrammet kommer etter kommentarene. I systemet er bruker definert som de personene som skal legge inn data, eller endre systemet. Dette tilsvarer i vårt informasjonssystem de ansatte ved et tenkt universitet; administrasjon, forelesere, gruppelærere etc. Studentene, som er tenkte kunder av systemet, skal ikke representeres internt. Begrepet bruker er entydig definert ved brukernavn. Til dette brukernavnet knyttes også i modellen et personnavn, fulltnavn, og et passord. «Fulltnavn» er her en String som dekket både fornavn, mellomnavn og etternavn til en person. Flere brukere kan ha både identisk personnavn og passord, men må ha både et navn og passord. Brukers navn og passord må være NOT NULL i henhold til krav om validasjon av meldinger i atom-standard. 8 En slik standard vil bli benyttet til distribusjon av i meldinger som blir lagt inn i systemet, og bør derfor følges. Standarden forklares senere i rapporten, under...? Forholdet mellom brukere og passord er * til 1 brukeren har kun ett passord, men flere brukere kan ha identisk passord. Det samme gjelder for fulltnavn: en bruker har kun ett navn, mens et navn kan tilhøre flere. 8 Atom spesifikasjon URL: atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section

21 Hver bruker kan ha null eller en epostadresse. Dersom brukeren har en epostadresse, vil denne adressen bli knyttet til alle meldinger sendt av denne brukeren. Således kan det enkelt sendes tilbakemeldinger på beskjeder via mail. Det bør også være lovlig å sende ut beskjeder uten å ha adresse; eksempelvis generelle meldinger fra fakulteter, der man ikke ønsker tilbakemeldinger fra studenter. Vi tenker oss også at hver adresse ikke er unik, men at flere brukere kan operere med samme responsmail. Dette kan for eksempel gjelde der to eller flere forelesere samarbeider om undervisning i ett fag, og ønsker alle tilbakemeldinger fra studenter på meldinger gitt i dette faget til en felles mail. Det er nødt til å være kontroll på hvilke brukere som får lov til å publisere meldinger til hvilke fag. For eksempel kan ikke en gruppelærer i et fag poste meldinger til selve faget, men kun sin gruppe elever. Samtidig må en bruker kunne ha rett til å poste meldinger til flere fag, gjerne på tvers av institutter, og flere brukere må kunne poste til samme fag. Vi tenkte først å løse dette mange-til-mange-forholdet med et nytt begrep Brukergruppe, der hver bruker var medlem i en gruppe, og hver medling ble knyttet til en gruppe. En slik gruppe kunne for eksempel vært et institutt. Da ville for det første ikke sikkerheten blitt 100% ivaretatt. Alle brukere innenfor en gruppe ville hatt muligehet til å poste til ALLE fag innen den gruppen. For det andre løses ikke problemet med at en del brukere trenger 'medlemsskap' i flere av gruppene. Vi landet derfor på en adgangskontroll som baserer seg på at de entydige attributtene brukernavn og emnekode går sammen og danner en lang primærnøkkel i begrepet skrivetilgang. Slike skrivetilganger vil entydig binde brukeren sammen med emnet han/hun skal ha publiseringsrett til, og løser derfor opp mange-tilmange forholdet mellom bruker og emne. Hver bruker kan ha mange skrivetilganger, og hvert emne kan tilhøre flere skrivetilganger. En skrivetilgang kan kun tilhøre ett bestemt emne og en bestemt bruker. Hvert emne inneholder en identifiserende emnekode, og en unik emnetittel. Hvert emne har én beskrivende emnetittel og hver emnetittel står i ett emne. Her har vi altså et 1-1-forhold. En emnekode kan ha mange meldinger knyttet til seg. Studentgrupper kan også registreres som emner, med egne emnekoder og tilhørende skrivetilgang knyttet til gruppelærerne i faget. En melding har en identifiserende meldings id og knyttes kun til en emnekode. Dette er bygget på en antakelse om at det ikke er interessant å publisere samme melding i flere emner. Skulle det allikevel komme en melding fra eksempelvis Institutt for Informatikk, som skal ut til alle informatikkemner, må denne beskjeden sendes til hvert enkeltemne. Dette vil ikke være noe problem for systemet, meldingen sendes ganske enkelt ut til alle INF emner. Det vil oppstå en del redundans i systemet dersom det blir mange slike fellesmeldinger. Den samme meldingen vil da lagres separat knyttet til hvert sitt enkeltfag. For å unngå slik redundans vedrørende lagring av meldinger som skal til flere fag, må systemet endres. Et alternativ er å bruke hjelptabeller mellom emne og melding. En hjelpetabell meldingsgruppe kunne for eksempel inneholdt emner som tilhører samme brukergruppe, og en melding kunne enten blitt publisert til en slik meldingsgruppe eller til en enkelt emnekode. Her er det blitt gjort en avveiing i forholdet mellom mulig redundans og begrensing av systemet. På grunnlag av vår antakelse om at det ikke er interessant å publisere samme melding i flere emner, har vi besluttet at redundansen vil bli minimal, og at begrensning er viktigere. Hvilken informasjon en melding bør inneholde, har i stor grad blitt bestemt av den etablerte standarden satt av det anerkjente metadatasystemet DublinCore. De opererer med tre datoer som knyttes til hver melding: publiseringsdato, endringsdato og opprettet-dato. En melding trenger ikke ha en opprettet dato, men må ha en endret dato og en publiseringsdato. Disse egenskapene er gitt av atom-standarden for meldinger, som vi ønsker å følge. Dersom meldingen har dato for oppretting må den komme før datoene for endret og publisert. Tilsvarende må endret datoen alltid komme før datoen da meldingen skal publiseres (dette er lagt inn som tilleggsskranker på datoene). En melding kan endres frem til den er publisert, deretter har den allerede blitt distibuert, og dersom ny versjon skal sendes ut må ny melding opprettes. Vi har valgt å kalle endringsdatoen 'sistendret', slik at det kommer tydelig frem hva dette attributtet står for. 21

22 Vi bruker timestamp til å generere datoer, det vil si at datoene angir både dato og klokkeslett ned til sekund. Publisert, sistendret og opprettet datoene kan derfor aldri bli identiske, selv om de refererer til samme dag, fordi brukeren blir nødt til å legge dem inn etter hverandre. Derimot kan det skje at to brukere genererer datoer til sine meldinger i nøyaktig samme sekund. Sannsynligheten for at dette vil skje, øker etterhvert som antall meldinger publisert i løpet av et tidsintervall øker. Vi har valgt å ta høyde for dette i systemet, ved å legge til rette for at en og samme dato kan stå i vilkårlig mange meldinger. Siden det stilles ulike kriterier til de tre datoene, har vi valgt å la hver av dem bli representert ved et eget begrep. For at de skal kunne sammenliknes må likevel de tre datoene bli representert på samme måte internt, hos oss ved typen 'timestamp'. De kunne derfor også blitt representeret som typer av en generell begrepsklasse/typeklasse dato. I tillegg kommer selve innholdet i meldingen, og en tittel på meldingen. En melding må alltid ha en tittel, da meldingen publiseres med denne tittelen, men tillates å ha tomt innhold. Vi har skilt begrepene innhold og tittel, da de to kan representere ulike datatyper. Mens en tittel må være en String og begrenset til et bestemt antall tegn, kan innholdet være både ren tekst, URL-linker, bilder og så videre. En bruker kan bare aksessere en av sine egne meldinger. Meldinger fra andre brukere kan kun leses. Også dette forenkler systemet Ugruppert UML klassediagram Betraktninger av grupperingsprosessen. Den ugrupperte modellen har først blitt gruppert ved å føre på fremmednøkler. Modifikatoren 'unique' er også ført på der denne gjelder; på den unike attributt emnetittel i begrepet emnetittel. 22

23 Betraktninger om fasing ut av klasser Etter gruppering er overflødige begreper fjernet: Ved en-til-en-relasjoner mellom begreper, lot vi begrepet med flest mange-til-èn relasjoner bestå. Andre begreper grupperes inn i de bestående som attributter. I vårt ugrupperte UML-diagram har vi kun én 1-1 relasjon, mellom emnetittel og emne. Emnetittel leggs inn som attributt i emne, og begrepet emnetittel kan strykes. Endret, publisert, oprettet, innhold og tittel finnes som fremmednøkler i begrepet melding. Vi har ingen bruk for separate tabeller med mer eller mindre tilfeldige tall og tekster. Vi har heller ikke behov for å etablere brukerdefinerte datatyper av disse begrepene. begrepene kan derfor strykes, og sistendret, publisert, opprettet, tittel og innhold blir attributter i begrepet melding. Begrepene navn, passord og epost legges tilsvarende inn som attributter i bruker, gjennom grupperingsprosess som beskrevet i første avsnitt. Vi står da igjen med fire begreper som blir til fire klasser: bruker, brukergruppe, emne og melding. I klassediagrammet representerer hver av de fire bestående klassene en tabell, og attributter til disse tabellene blir kolonnene i tabellen. Emne: Emnekode som identifikator, en unik emnetittel, og fremmednøkkel gruppe fra klasser brukergruppe. Skrivetilgang: Lang identifikator samensatt av emne og bruker. Bruker: Brukernavn som identifikator, fremmednøkkel gruppe fra klassen brukergruppe, attributtene passord, epost og fulltnavn. Melding: Meld.id. som identifikator, fremmednøklene emnekode fra emne og brukernavn fra bruker, attributtene sistendret, publisert, opprettet, innhold og tittel Gruppert UML klassediagram Databasen Databaseprogrammet som ligger i bunnen av systemet er ORACLE v og kjøres på en UNIX 23

24 plattform. Vi valgte å bruke ORACLE fordi et slikt system er lett tilgjengelig her på UIO og inneholder all funksjonalitet vi har bruk for. Når en lager et system fra kjernen og ut vil man håndtere en modell av verden i et databasehåndteringssystem. Modellen kan tilpasses etter hva slags databesehåndteringssystem det dreier seg om. I vårt prosjekt er det fastlagt av oppgaven at relasjonsdatabase skal benyttes. En relasjonsdatabase vil hovedsaklig bestå av tabeller og ett sett med regler for hvordan opplysningene i tabellene skal relatere/forholde seg til hverandre. Disse reglene kalles skranker og omfatter primærnøkler, fremmednøkler, definerte egnede representasjoner av attributtene og multipleksiteter som null og not null Skranker Tabellene og skrankene i Databasediagrammet danner grunnlaget for realiseringen av databasen og kan utledes av klassediagrammet. Skrankene skal gjenspeile de regler som gjelder i det interesseområdet vi modellerer og danner grunnlaget for å komme fram til en hensiktsmessig strukturering av dataene. I dette tilfellet, tabeller i en relasjonsdatabase. Ved å identifisere skranker i klassediagrammet kan vi lage en modell for databasen; databasediagrammet (fig.3.3.1). Under beskrives hvordan vi har realisert databasediagrammet til en relasjonsdatabase. Vi tar her utgangspunkt i klassen Melding, og forklarer metodikken bak realiseringen av databasen for tabellen melding. Videre beskrives ikke hvordan hver enkelt tabell blir til Entydighets skranken Primary key og multiplisitetsskranker Ut ifra klassediagrammet ser vi at klassen melding som blir tabellen melding har ett attributt, meldingsid{id}. Denne {id} notasjonen sier at attributtet har en etydighetsskranke( uniqueness constraint). Dette betyr at attributtet er en kandidatnøkkel. Dette er den eneste kandidat nøkkelen i denne tabellen og blir Primary Key (pk) i tabellen melding. Det kan kun finnes en og bare en forekomst av hver meldingsid. Dette kalles også for en multiplisitetsskranke og representeres som en strek over atributtet i skrankediagrammet Foreign key og delmengdeskranker I tabellen meldingsid har vi attributtet brukernavn, i likhet med tabellen bruker hvor den er en primary key. Dette gir en delmengde-skranke i tabellen melding. Altså alle forekomster av attributtet brukernavn i tabellen melding må eksistere i tabellen bruker. Vi sier at brukernavn fra tabellen melding får en Foreign Key (fk) fra tabellen Databasediagrammet 24

25 Skrankediagrammet/databasediagrammet er en fremstilling av datbasestrukturen med tabellene, attributtene, entydighetsskranker, delmengdeskranker og integritetsregler som NULL og NOT NULL. Diagrammet egner seg godt som grunnlag for realisering av databasen. Datoskranken: Det hadde vært naturlig med en skranke på datoene slik at opprettet dato < endret dato < publisert dato. Vi valgte å ikke implementere dette i denne versjonen. For å forenkle systemet gir vi alle datoene i meldingstabellen samme verdi Tabellene Når modelleringen av databasen er klar, kan man ta i bruk spørrespråket SQL for å realisere databasen. Hvert begrep i databasediagrammet ble en tabell i relasjonsdatabasen. Hver attributt tilhørende et begrep, ble kolonner i tabellen av dette begrepet. Relevant metadata ble så lagt inn i tabellene. Sql har 3 hovedkommandoer: Datadefinisjonsspråket: der man setter opp en tom datastruktur, der man deklarerer datatyper, inegritetsregler og der man genererer tabeller. I vår prosess tok vi i bruk disse kommandoene fra datadefinisjonsspråket: Create table, Alter table, og Add constraint. Datamanipuleringsspråket: der man setter inn, der man endrer, og der man foretar spørringer mot databasen. I vår prosess tok vi i bruk select-setninger, insert-setninger, delete from table-setninger og update tablesetninger, ettersom hva oppgaven påkrevde. Datakontrollspråket: Brukeren som hadde relasjonsdatabasen under sitt brukernavn, foretok en kommando fra datakontrollspråket for å gjøre relasjonsdatabasen tilgjengelig for resten av gruppa. Kommandoene for å opprette relasjonsdatabasen tok tilhørende variabeltyper, som for eksempel varchar(11), og attributtverdiene null og not null. Ved not null må attributtet ha en verdi, ved null trenger den ikke dette. Alle kommandoene ble lagt i en fil som ble kjørt når databasen skulle opprettes. Endringer kan da legges inn i filen, og databasen kan enkelt bli opprettet på nytt, modifisert. Disse sql kommandoene finner du i vedlegg B Spørringer mot databasen, SQL Alle kommersielle produkter tilbyr en variant av spørrespråket SQL ("Structured query language") i en eller annen form. Det er standardisert av det internasjonale standardiseringsorganet ISO. Dette språket brukte vi for å opprette og kommunisere med relasjonsdatabasen vår. De kommandoene i SQL som ble påkrevd i oppgaveteksten, og resultatene av disse, finnes i vedlegg B. 3.4 Diskusjon om forskjeller i klassediagrammene Klassediagrammet som er kommet fram ved dataorientert systemutvikling, beskriver hvordan en virkelighetsmodell for problemområdet bør se ut. Denne modellen vil gjengis av en relasjonsdatabase. Systemet skal kunne hente ut nødvendig informasjon fra databasen, for å utføre oppgavene som beskrevet i prosjektbeskrivelsen. Hovedfokuset under databaseutviklingen har ikke vært å tilrettelegge for at oppgavene i prosjektbeskrivelsen skal løses. Fokuset har vært å få modellen til å gjenspeile den delen av verden vi er interessert i så korrekt som mulig. Det betyr at også nye, relevante oppgaver bør kunne baseres på samme database, og dermed relativt enkelt implementeres i systemet. Dersom databasen er en god modell av problemområdet, bør de fleste bruksmønstre innenfor problemområdet finne tilstrekkelig informasjon i databasen. Modellen av verden man får når en går fra 'skallet og inn', passer bedre for kun å oppfylle systemets funksjonelle krav som beskrevet i prosjektbeskrivelse. Det gir kunden den ønskelige funksjonaliteten nøyaktig, enkelt og relativt raskt. Å jobbe fra skallet og innover er lurt dersom en skal lage et meget brukertungt system, der funksjonalitet er det vesentlige ved systemet, mens systemet kun skal modellere en svært begrenset virkelighet. Klassediagrammet fra del 2 av oppgaven beskriver kun en del av et objektorienterte program, der kun et bruksmønster med variasjoner er implementert. Klassediagrammet representerer attributter og oppførsel til objekter fra de nødvendige klassene for bruksmønsteret. 25

26 Disse to klassediagrammene beskriver derfor svært forskjellige ting, og det er helt naturlig at de blir forskjellige. Ofte kan man komme inn i en ensidig måte å se virkeligheten på når man jobber med å utvikle et system på en av disse måtene. Ved å bruke begge arbeidsformene i systemutviklingen, får man et bredere og mer nyansert syn på problem-og interesseområdet. 4. Prototypen 4.1 Presentasjon av prototypen HuskerDu er en løsning der de ansatte ved universitet kan publisere nyhetsstrømmer ment for studentene, og studentene skal i sin ende kunne abonnere på dem. For publikatoren(den ansatte) fungerer HuskerDu som et enkelt enhetlig web-basert grensesnitt for å publisere informasjon ment for studenter og andre som abonnerer på informasjonen. Publikatoren kan publisere nye meldinger, endre opprettede meldinger, og det skal finnes en oversikt over meldinger denne brukeren tidligere har publisert, og en oversikt over alle meldinger. Meldingen publikatoren oppretter, knyttes til ett fag, slik at informasjonen kun kommer frem til den som abonnerer på faget. Abonnenten forblir passiv etter å ha valgt hvilke(t) fag den vil abonnere på. Etter hvert semester resirkuleres databasen, og man må igjen abonnere på kurs man ønsker informasjon fra. Det å ha et brukervennlig og plattform uavhengig system, er viktig rammer for systemet HuskerDu. Nettbasert brukerinteraksjon gjør systemet både brukervennlig og kompatibelt med andre plattformer.ved å legge brukerinteraksjonen til webforms kan man lettere visualisere brukerinteraksjonen. Dette igjen gjør det enklere å tilpasse de interaktive websidene til hver bruker og dennes data. Systemet HuskerDu har Php-script som behandler de inntastet data på nettsidene, og sender/henter informasjon fra databasen basert på disse dataene. Det ble utarbeidet ulike grensesnitt for de ulike brukergruppene. Systemadministrator til systemet regnes ikke som en bruker av systemet, men siden et kvalitetskrav til systemet er at det skal være enkelt å vedlikeholde, viser prototypen et brukergrensesnitt mot systemadministratoren også. I dette grensesnittet er det vist hvordan administratoren kan legge inn en ny bruker. Grensesnittet kan enkelt utvides slik at systemadministratoren også kan slette gamle brukere som ikke er ansatt lenger, og utføre andre ønskede handlinger. I prototyen er det implementert begrensing på skrivetilgang, slik at brukere kun kan publisere meldinger til emner brukeren har skrivetilgang til. Skrivetilganger opprettes av systemadministrator samtidig som brukeren opprettes. Vil man på et senere tidspunkt ha skrivetilgang i flere fag, må man i prototypen opprette en ny bruker. I det ferdige systemet vil systemadministrator kunne oppdatere skrivetilgangen til en bruker. Systemadministratoren har til enhver tid full kontroll over brukerne, slik det ville fungert i det ferdige systemet. Prototypen gir dermed et godt inntrykk av hvordan systemet ville fungert på et universitet. Det er også lagt inn en test, slik at om man taster inn URL til for eksempel 'opprett melding', vil man få beskjed om at man ikke er innlogget. Dette vil skje på alle sidene, med mindre en session er igang. Vi har også beskyttet systemet mot SQL-injection, ved å tilføye en metode i innloggingssekvensene våre som heter preg_match, der man ikke har mulighet til å bruke andre tegn enn bokstaver og tall. Systemet HuskerDu tar i bruk tre forskjellige grensesnitt: 1. Publikatorers innlogging og publiseringsvalg. 2. Abonnementsiden, der abbonnenten kan velge fag å abonnere på. 3. Siden der systemadministrator logger seg inn og oppretter brukere/gjør endringer. Innlogging for publikatorene: brukernavn: Freddy passord: blades URL: Abonnementsiden har URL: 26

27 Innlogging for systemadministrator: brukernavn: ieronnin passord: ieronnin URL: Design av brukergrensesnitt Betrakninger om valg av design Systemet HuskerDu har lagt vekt på et brukervennlig grensesnitt som er mest mulig innbyrdes konsistent, det vil si at grensesnittet er pent, ryddig og gjennomført med samme stil (i samme utviklingsmiljø). Det ble her brukt prototyp utforming gjennom eksprementering av brukergrensesnittet for å finne ut om bruksmønstrene fungerer slik man hadde tenkt, og samtidig se hvor samspilte bruker og system var. Vi har ingen synlig redundant informasjon, og minimalistisk utsyn. Grensesnittet forteller brukeren til en hver tid hva som skjer, og hva man har av «fluktmuligheter». Dette medfører at brukeren vil føle at han/hun har full kontroll over systemet, og ikke blir sittende igjen med en usikkerhet om at man kan gjøre noe galt. Det er her heller ikke mulig for brukeren å slette hele databasen eller gjøre andre drastiske feil ved et uhell. Hvis brukeren ikke kommer inn eller har tastet noe feil, vil man alltid få tilbakemelding om hva som er feil, og en link tilbake til utgangspunktet. Utviklerne av systemet HuskerDu ville ha grensesnittet slik at enhver bruker ikke behøver å huske noe fra skjermbilde til skjermbilde, og at det ikke blir for mye informasjon på en gang. Man valgte derfor å gruppere de forskjellige valgmulighetene med dropdown bokser. Gjennom grupperings-prinsippet blir det mindre å holde orden på for en bruker, og enklere å eventuelt senere utvide av systemet. Grensesnittet i HuskerDu er intuitiv, det vil si at det er selvforklarende, og det er en rød tråd gjennom hele grensesnittet. Dette gjør at det er enkelt å ta i bruk, selv uten brukerveiledning. Systemutviklerne så for seg en budbringer som fikk med seg en melding, og leverte denne videre til de som abonnerte. Denne budbringeren ble til HuskerDu's ikon på alle skjermbildene til systemet. 4.3 Brukerdokumentasjon Logg inn for administrasjonen Dersom meldinger skal publiseres, er det nødvendig å verifisere brukerne før de kan aksessere systemet. Administrasjonen/forelesere/gruppelærere skriver inn brukernavn og passord, på logginn-siden, og trykker Logg inn. Dersom brukernavn og passord valideres, fører denne linken til en webside der man får bekreftelse på innlogging og en meny med følgende valgmuligheter: opprette-/slette-/endre-/få oversikt over meldinger. Dersom brukernavn og/eller passord ikke valideres, fører dette til at brukeren får opp en feilmelding og en link prøv igjen, som fører brukeren tilbake til logginn-siden. Brukeren har også mulighetene gå «tilbake» eller «logg ut» som linker på siden Innloggingen var vellykket Dersom innlogging er vellykket, kommer man inn på menysiden som beskrevet ovenfor. Der velger brukeren videre handlingsmønster ved å klikke på valg i meny. Hvert av valgene er en link til ønsket side. Man har også mulighet til å velge knappene «tilbake» og «logg ut». 27

28 4.3.3 Opprette melding til emne Brukeren må være innlogget og ha valgt «opprett melding» fra menyen for å komme til siden der en kan opprette melding. Denne funksjonen består egentlig av to sider, der verifisering av rettigheter blir tatt hånd om av den første siden brukeren kommer til: Brukeren velger emne han/hun ønsker å sende melding til fra en liste over emner den brukeren har skrivetilgang til. Brukeren skriver inn riktig emnekode fra listen og trykker på «Send forespørsel». Hvis brukeren skriver inn feil emnekode, vil han/hun komme til side med feilmelding om at en har tastet feil emnekode, og linker «tilbake» og «logg ut». Brukerne får samme feilmelding dersom han skriver inn koden til et emne han ikke har skrivetilgang på. Hvis brukeren glemmer å taste inn emnekode, får brukeren feilmelding som forteller at man må taste inn emnekode. Ved riktig kode blir brukeren sendt videre til neste side i funksjonen Skriv melding Ønsket tittel, publiseringsdato og beskjed skrives inn i tekstfeltene på denne siden, og informasjonen sendes ved å trykke på linken send data. Denne knappen setter igang et php-script som ved vellykket eksekvering fører til en webside som bekrefter ovenfor brukeren at meldingen er opprettet, med en link «tilbake» til 'opprett melding' og link «tilbake til meny» til menysiden. Publiseringsdatoen er satt default til 24 timer etter nåtid.skriver ikke brukeren inn en gyldig publiseringsdato, vil brukeren så feilmelding om dette, med referanse til eksempelet over publiseringsdatoboksen. Skriver ikke brukeren inn tittel, vil bruker få en feilmelding om at han/hun har glemt å fylle ut tittel. Brukeren har lov til å publisere en melding uten innhold.vil man tømme tekstfeltene, trykker man på tøm blankett.alle feilmeldingssiden har en link tilbake og en link tilbake til meny til menysiden. På begge 'opprett-melding-sidene' har man valg logg ut, hvis brukeren er ferdig med det han/hun skulle gjøre, eller brukeren kan gå tilbake til meny Endre/slette melding Her kan man ut fra en dropdown boks velge om man vil slette eller endre meldinger, så sender man ønsket valg med linken Send data. Man har også valgene tilbake til meny og logg ut Endre melding Her kommer alle meldingene til brukeren opp, med meldingid, tittel, innhold, og publiseringsdato. Brukeren skriver inn meldingid på den meldingen han/hun ønsker å forandre med en ny publiseringsdato, ny tittel og nytt innhold, deretter trykker brukeren Send data og får 28

29 beskjed om at meldingen er endret. Man har også her knappene Tilbake og Logg ut og en link som fører en tilbake til meny Slette melding Man har her også en link Tilbake en Logg ut -knapp og en link som fører en tilbake til meny. Brukeren får en liste over sine meldinger, finner ønsket melding han/hun ønsker og slette, og skriver inn meldingid til ønsket melding. Deretter trykker man på Send data, og ved vellykket eksekvering av php-scriptet får man melding om at meldingen er slettet. Her er det også mulighet til å komme seg ut av systemet med Logg ut. Eller man kan trykke Tilbake hvis det er flere meldinger brukeren vil endre eller slette. Brukeren kan også trykke Tilbake til meny hvis det er ønsket Meldingsoversikt Meldingsoversikt er navnet på siden der brukeren kan få aksess til å lese sine egne publiserte meldinger eller alle meldinger som er publisert. Brukeren må være innlogget og ha valgt «oversikt over meldinger» fra menyen. Brukeren velger fra dropdown-meny 'se alle meldinger'/'se egne meldinger' og trykker «gå videre». Da vil det øverst i venstre hjørne komme opp meldinger fra ønskede spørring. Nederst på siden er link logg ut, hvis bruker ønsker å avslutte. Hvis han/hun vil utføre en ny handling trykker brukeren på linken tilbake til meny Alle egne publiserte meldinger Her ser brukeren en oversikt over egne meldinger, med attributtene emnekode, tittel og innhold. Man har igjen muligheten til å trykke på knappene «tilbake» og «logg ut», og en link til menyen Alle publiserte meldinger Her ser brukeren en oversikt over alle publiserte meldinger i systemet, men attributtene emnekode, tittel, innhold, og brukernavn. Her har man også muligheten til å trykke på knappene tilbake og logg ut, og en link til menyen. Dersom brukeren valgte 'Se oversikt over egne meldinger' og ikke har postet noen meldinger, får brukeren feilmelding. Det samme skjer hvis brukeren valgte 'Se oversikt over alle meldinger' og ingen meldinger har blitt publisert ennå. 29