IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler for Kravspesifikasjonsdokumentet Pensumlitteratur : Artikkelsamling Stumpf & Teague : kap 5. Domain Models Maler som er lagt ut under Ressurser på hjemmesiden Klassediagrammet Etter å ha skissert Use Case (diagram og beskrivelser) og Systemsekvensdiagrammer, er neste steg innen OOA å komme frem til / avdekke / utarbeide et konseptuelt klassediagram for systemet. Oppgaven er å finne klassene og relasjonene som samlet danner en god modell av den virkelige verden. Modellen skal gi en statisk fremstilling av sentrale elementer (klasser) som finnes i det problemområdet som det nye IT-systemet skal være en speiling av. Modellen skal også vise sammenhengene mellom disse elementene (assosiasjoner). Klassediagrammet man utarbeider innen OOA viser kun : Klassenavn Klassens attributter Assosiasjoner mellom klassene Klasse En klasse er en beskrivelse av en type objekter Det enkelte objekt er en forekomst av en klasse Klassen beskriver felles egenskaper og oppførsel som alle objekter av klassen har Problemområdet, og kundens fokusering avgjør modelleringen av klassene i det nye systemet I OOA fokusere business classes (de klassene som finnes i det domenet systemet skal dekke). Den modellen vi kommer frem til kalles et Konseptuelt Klassediagram IMT2243 : Systemutvikling 1
Generalisering (Gen-Spec) : Klasse-strukturer Abstrahering - overordnede klasser detaljeres i underliggende klasser. Attributter og operasjoner som er felles defineres på høyt nivå og arves av alle sub-klasser Assosieringsstruktur : Viser viktige forbindelser mellom ulike klasser. Det er ingen arv mellom assosierte klassene Det angis multiplisitet på og settes navn på assosiasjonene Aggregering ( Whole-Part ) : En struktur der en klasse består_av en sammensetning av andre klasser. Her har vi ingen arv, men klassene er sterkt relatert normal aggregering (objektene er ikke uløselig knyttet til hverandre) composition aggregation - et eierforhold der delene lever inne i helheten. Domenemodellering Tommelfingerregler når du arbeider med domenemodell: Bruk sjekklister (se etter roller, steder, ting, objekter, beholdere, organisasjonsenheter, kataloger/beskrivelser ) Foreta språkanalyser av bl.a. Use Casene (substantiver som sier noe om virkeligheten ) Ta med konsepter fra virkeligheten som det nye systemet må holde på informasjon om for å yte tjenester senere Ikke omsett alle aktører fra UseCase til klasser Vurder om noe du avdekker skal modelleres som en klasse eller som et attributt (er du i tvil gjør det til en klasse) Ikke modeller statistikker og informasjonslister som klasser Kravspesifikasjonen Kravspesifiseringsarbeidet går ut på å kartlegge og dokumentere HVA som skal inngå i det nye systemet. Kategorier av krav : Funksjonelle krav Ikke-funksjonelle krav (operasjonelle) Avgrensninger Under Ressurser på hjemmesiden finnes to maler for kravspekdokumentet samt refreanser til viktige RUPartefakter. Dette er pensum, men husk at om alltid er dette Knaggrekker og huskelister fremfor Tvangstrøyer. Bruk dem deretter! IMT2243 : Systemutvikling 2
Kravspekmal hentet fra R.Pressman (www.rspa.com/docs/reqmspec.html) 1.0 Introduksjon 1.1. Målsetning (Effektmål og Resultatmål) 1.2. Oppgavebeskrivelse/avgrensning 1.3. Systemets omgivelser (kontekst) 1.4. Begrensninger / rammer 2.0 Bruker beskrivelser (Usage scenario) 2.1. Bruker profiler (beskriv alle kategorier brukere) 2.2. Brukstilfeller (Use-cases) 2.3. Spesielle brukshensyn 3.0 Datamodell og data beskrivelse 3.1. Beskrivelse av sentrale dataobjekter 3.1.1. Dataobjekter og deres attributter 3.1.2. Relasjoner mellom dataobjektene 3.1.3. Fullstendig datamodell 3.1.4. Datakatalog 4.0 Funksjonell modell og beskrivelse 4.1. Beskrivelse av funksjon n 4.1.1. Prosessbeskrivelse 4.1.2. Informasjonsflyt diagram 4.1.3. Funksjonsgrensesnitt beskrivelse 4.1.4. Detaljbeskrivelse av alle transformasjoner 4.1.5. Ytelseskrav 4.1.6. Design begrensninger IMT2243 : Systemutvikling 3
4.2. Systemets eksterne grensesnitt 4.2.1. Eksterne maskingrensesnitt 4.2.2. Eksterne systemgrensesnitt 4.2.3. Brukergrensesnitt 4.2.4. Kontrollflyt beskrivelse 5.0. Operasjonell modell og beskrivelse 5.1. Detaljert operasjonell beskrivelse 5.1.1. Hendelser av betydning for det operasjonelle 5.1.2. Systemets tilstander 5.2. Tilstandsdiagrammer 5.3. Kontrollspesifikasjon 6.0. Restriksjoner og begrensninger 7.0. Testkriterier Beskrive strategien for hvordan validering og verifisering skal foregå 7.1. Beskrivelse av testtyper 7.2. Beskrivelse av forventede resultater 7.3. Ytelseskrav 8.0. Appendix / Vedlegg IMT2243 : Systemutvikling 4
Sjekking av kravene Validitet : Har vi satt opp de riktige kravene? Konsistens : Har vi satt opp motstridende krav? Komplett : Er kravspesifikasjonen dekkende? Realisme : Er det realistisk at vi klarer å oppfylle kravene? Verifiserbarhet : Kan man teste om kravene er oppnådd? En alternativ Kravspekmal : (ofte benyttet i stud.prosj. ved HiG) DEL 1. INTRODUKSJON (OVERORDNET KRAVSPESIFIKAJON) Lages ofte i et forprosjekt, og er et av flere beslutningsdokument. Skal gi oversikt over systemet Målgruppe : ledere og brukere Noe overlapp mot prosjektplan Innhold : DEL 1. INTRODUKSJON 1.1 BAKGRUNN 1.2 KORT OM KRAV TIL SYSTEMET 1.3 KORT OM SYSTEMETS OMGIVELSER 1.4 DOKUMENTETS STRUKTUR 1.5 DEFINISJONER 1.6 REFERANSER IMT2243 : Systemutvikling 5
DEL 2. BRUKER BESKRIVELSE Brukerorientert beskrivelse av hva man skal ha. Slik denne malen er, inneholder den også aspekter om den totale løsningen, ikke bare programvaredelen Målgruppe : Brukere, analytikere, leverandører Langt mer detaljert enn Del 1 Innhold : DEL 2. Bruker Beskrivelse 2.1 OMGIVELSER 2.2 SYSTEMETS BRUKERE 2.3 FUNKSJON 2.4 OPERASJON 2.5 ASPEKTER OMKRING LIVSSYKLUS 2.6 YTELSE 2.7. BEGRENSNINGER 2.8. ANTAGELSER DEL 3. Detaljert kravspek Settes opp av brukere og analytikere med evt. bistand fra leverandør. Kan være en del av kontrakt mellom kunde og leverandør Skal være detaljert nok til å bygge et design av løsningen på Målgruppe : Utviklere, Leverandør 3. Funksjonell spesifikasjon 3.1. Funksjonell struktur 3.2. Dataspesifikasjon og dataordlister 3.3. Operasjonelle systemkrav 3.4. Funksjonelle krav pr modul i detalj IMT2243 : Systemutvikling 6
DEL 3. Detaljert kravspek (2) 4. Begrensninger (SW og HW) 5. Aspekter omkring livssyklus 6. Aspekter omkring installasjon 7. Utgivelser underveis 8. Akseptansekrav 9. Prosjektstyring og kvalitetssikringskrav IMT2243 : Systemutvikling 7