Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon <1.0>
Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter <dd/mmm/yy> <x.x> <beskrivelse> <navn>
Innhold 1. Innledning 4 1.1 Dokumentets hensikt 4 1.2 Avgrensning 4 1.3 Definisjoner og forkortelser 4 1.4 Referanser 4 1.5 Oversikt over innholdet 4 2. Bakgrunn og oversikt 4 2.1 Use Case modellen 4 2.2 Ikkefunksjonelle krav 4 2.3 Forutsetninger og avhengigheter 4 3. Designet 4 3.1 Valg av kontroller 5 3.2 Use Case 1 5 3.2.1 Systemmelding 1.1 5 3.2.2 Systemmelding 1.2 5 3.3 Use case 2 5 3.3.1 Systemmelding 2.1 5 3.3.2 Sysemmelding 2.2 5 4. Designklassemodellen 5 4.1 Overordnet klassemodell 5 4.2 Detaljert beskrivelse av klasse A 5 4.3 Detaljert beskrivelse av klasse B 6 4.4 Detaljert beskrivelse av interface I1 6 4.5 Detaljert beskrivelse av interface I2 6 5. Tilleggsinformasjon 6
1. Innledning Beskrivelse av design Innledningen til dokumentet skal fortelle leseren hva som er hensikten med dokumentet og hva det inneholder. Han skal også forstå i hvilken forbindelse dette dokumentet er skrevet. Innledningen har følgende underpunkter: 1.1 Dokumentets hensikt Hensikten med dette dokumentet er å beskrive designet til systemet som er utviklet. 1.2 Avgrensning Her finner vi en kortfattet beskrivelse av det aktuelle prosjektet slik at det går klart frem hva dette dokumentet dekker. Hvis dokumentet dekker deler av systemet må det gå klart frem. Eventuelle relasjoner til andre systemer eller delsystemer beskrives. 1.3 Definisjoner og forkortelser Alle begreper og forkortelser må defineres når dette er nødvendig for å forstå innholdet i dokumentet. NB! Husk at dette dokumentet skal leses også av brukerne. Hvis det er laget en ordbok i prosjektet, kan det refereres her. 1.4 Referanser Alle dokumenter som refereres andre steder i dette dokumentet skal listes opp her. 1.5 Oversikt over innholdet Her forteller vi leserne hva dette dokumentet inneholder og hvordan det er organisert (hva han finner hvor) 2. Bakgrunn og oversikt Design vil si å realisere Use Case og tilhørende ikke-funksjonelle krav. Design er også en detaljering av arkitekturen til systemet. Henvis til aktuelt analysedokument og eventuell beskrivelse av arkitekturen. Vis i et diagram det logiske perspektivet for arkitekturen. Underpunktene som følger viser hvilke Use Case som er realisert. 2.1 Use Case modellen Her viser vi det utsnittet av Use Case modellen som er realisert. Det kan gjøres ved hjelp av et diagram. Dette må suppleres med en beskrivelse av hvilke løp, hovedløp og eventuelle sideløp (relaterte løp) og unntak, som er realisert, og hva som gjenstår for senere iterasjoner eller versjoner av programvaren. 2.2 Ikkefunksjonelle krav Her listes opp de ikkefunksjonelle kravene som er tilfredsstilt i designet. List også opp krav som ikke er tilfredsstilt. Ikkefunksjonelle krav er dokumentert i Tilleggsspesifikasjonen som det kan henvises til. 2.3 Forutsetninger og avhengigheter Her beskriver vi så nøyaktig som mulig de forutsetningene som beskrivelsene i dette dokumentet bygger på. Videre beskriver vi så nøyaktig som mulig hvilke avhengigheter vi har, f.eks. til andre systemer. 3. Designet Her skal det følge en detaljert beskrivelse av designet som er utført. Her tar man for seg Use Case for Use Case og for hver Use Case, systemmelding for systemmelding. Designet illustreres med
interaksjonsdiagrammer (sekvensdiagrammer). Diskuter tekstlig problemene knyttet til designet, hvilke beslutninger som ligger til grunn for designet og eventuell bruk av designmønstre 1. 3.1 Valg av kontroller 2 Diskuter valg av kontroller. Hvis det brukes egne kontrollere for hvert Use Case, henvises det til diskusjon i tilknytning til hvert Use Case. 3.2 Use Case 1 Henvis til aktuelt Use Case i krav-/arkitekturdokumentet. Beskriv hvilke løp som er realisert. Vis tilhørende system sekvensdiagram. Diskuter valg av kontroller. 3.2.1 Systemmelding 1.1 Beskriv designet som er gjort for denne systemmeldingen. Diskuter problemene knyttet til designet av denne systemmeldingen, hvilke vurderinger som er gjort, hvilke objekter som er hentet fra domenemodellen og eventuell bruk av designmønstre for å finne en løsning på problemet. Illustrer designet med interaksjonsdiagrammer (sekvensdiagram eller kommunikasjonsdiagram 3 ). 3.2.2 Systemmelding 1.2 3.3 Use case 2 3.3.1 Systemmelding 2.1 3.3.2 Sysemmelding 2.2 4. Designklassemodellen Etter at alle Use Case er designet vil man ha kommet frem til de objektene som skal realisere Use Caseene. Disse må samles i en designklassemodell som illustreres i et overordnet klassediagram. For store systemer kan det bli nødvendig å dele opp i flere diagrammer for ikke å miste oversikten. På overordnet nivå kan dette illustreres med pakkediagrammer. Hver klasse og interface må dokumenteres med sitt navn, attributter og operasjoner og plass i et eventuelt klassehierarki. 4.1 Overordnet klassemodell Vis den overordnede designklassemodellen i et UML klassediagram. For store systemer kan det være aktuelt med diagrammer på flere nivå for å vise subsystemer og grupperinger i pakker. 4.2 Detaljert beskrivelse av klasse A Vis den Type klasse (abstrakt, aktiv, konkret) Pakke klassen tilhører Plass i arvhierarki, superklasser, interface som realiseres Relasjoner, roller i assosiasjoner, multiplisitet Attributter Operasjoner 1 Ikke pensum 2 Se Larman s. 302, Kap. 17.13 3 Ikke pensum
Spesielle ting Visualiser med egnede UML-diagrammer. 4.3 Detaljert beskrivelse av klasse B 4.4 Detaljert beskrivelse av interface I1 4 Pakke interfacet tilhører Plass i arvhierarki Konstanter Operasjoner Spesielle ting 4.5 Detaljert beskrivelse av interface I2... 5. Tilleggsinformasjon Evt. annen informasjon som vi ønsker å ta med for å øke forståeligheten og tilgjengeligheten av det som er dokumentert. 4 Se Larman s. 263, Kap. 16.12