NTNU Norges teknisk-naturvitenskapelige universitet
  Fakultet for informasjonsteknologi, matematikk og elektroteknikk > Institutt for datateknikk og informasjonsvitenskap

M3

Snarveier
  • Hjem
  • Forelesninger
  • Pensumliste

  • Studentliste
  • Øvinger

  • Individuell modellering, Innlevering 3 (siste)
    Frist: Torsdag (NB) 24. april

     


    Til denne innleveringen skal dere levere siste utgave av rapporten deres. Siste utgave av rapporten skal inneholde de oppdateringer av modellene som dere mener er nødvendige pluss at dere til denne innleveringen skal skrive 3 tekstlige "use-case".

     

    Oppgave:

    Modellene dere har laget så langt i øvingen gir en god oversikt systemet. En god kravspek er imidlertid meget omfattende dokument (jfr. kapittel 1 "introduction"i pensumartikkel P11). Dere skal nå "begynne" å skrive krav til systemet, gjennom å fylle ut 3 tekstlige Use cases (hvis man vil, kan man også lage grafiske (UML-stil) use case diagrammer for å gi oversikt). Dere skal selv bestemme hvilke 3 use-case dere vil skrive utfra caset og/eller modellene dere har laget, men konsentrer gjerne de valgte use casene om en del av systemet, slik at dere får en del av caset som blir mest mulig presist spesifisert. Henvis til modellene deres for å gjøre det klart for leseren hvilke deler av systemet dere har laget use cases for.

    Hver use case skal ha et unikt navn, og innholdet skal tilsvare det som kalles "filled iteration" (P12, kap 5), dvs at både sammendrag, basis-sti, evt alternativ sti og unntaksstier skal være med (jfr use case eksemplene 5.1 og 5.2 i P12).

    Tips: Om koplingen mellom modellene og Use-cases

    Prosessmodellen kan gi mye inspirasjon til å finne fram til fornuftige use cases. For det første inneholder prosessmodellen gjerne aktører, og disse vil være sentrale også i use cases (jfr pensums P12, kap 4.2, hvor nettopp det å finne aktørene er noe som må gjøres før man skisserer selve use casene). Dere har laget 2 ulike prosessmodeller APM og DFD - begge kan være nyttige utgangspunkt for å bestemme use-cases. Dere velger selv hvem av disse modelleme dere synes er best/mest egnet til å lage use-case av. Aktivitetene i prosessmodellen kan i noen tilfeller gi enda mer konkret input til å lage use cases. Hvis man har laget en svært detaljert prosessmodell, kan det være at 1 aktivitet i prosessmodellen tilsvarer 1 use case, men det er mer sannsynlig at man får flere mulige use cases per aktivitet. Husk at en use case er en slags minste tjeneste som systemet tilbyr og som gir nytte for brukeren, mens en aktivitet i en prosessmodell kan være temmelig omfattende og inneholde diverse subaktiviteter. Hvis f.eks. aktiviteten mottar inn-data fra ulike brukere, vil det gjerne bli minst en use case for hver av disse brukerne (siden en use case normalt bare har en utførende "aktør"). Selv et forhold som at en aktivitet mottar flere ulike inn-flyter fra samme bruker, kan innebære at det blir flere use cases, såframt info fra de ulike flytene kan registreres separat og hver for seg representerer en nyttig og verdifull handling for brukeren. På den annen side kan det også være at det fins aktiviteter i prosessmodellen som ikke resulterer i use cases i kravspek'en det hele tatt. Dette vil for det første gjelde aktiviteter som ligger utenfor automatiseringsgrensen – disse skal ikke detaljeres videre i denne kravspek'en. Et annet tilfelle vil være aktiviteter som er fullstendig system-interne, dvs i den forstand at de overhodet ikke har direkte kommunikasjon med noe (eller noen) utenfor automatiseringsgrensen.

    Informasjonsmodeller (RML i deres tilfelle) kan også gi ideer til use cases, disse viser jo hva slags info systemet skal behandle, og en del av use casene i et system er gjerne være av typen "Registrer X", "Oppdater X", "Slett X", der X kan være kunder, bøker, kontrakter eller hva systemet nå skal handle om. Hvis man har bra samsvar mellom prosessmodell og informasjonsmodell, har man gjerne fått ideer til slike use cases allerede fra prosessmodellen, men ellers kan informasjonsmodellen gi hint til ytterligere use cases som bør med.

     

     



    RedaktÝr: Kontorsjef: Eivind Voldhagen  Kontaktadresse: IS grunnkurs  Sist oppdatert: 01.01.1970