Konstruksjon. Kap. 13 Konstruksjonsmodeller og prinsipper. Design Concepts and Principles

Transkript

1 Kap. 13 Konstruksjonsmodeller og prinsipper. Design Concepts and Principles Konstruksjon Def av design [TAY59]: Prosess med å anvende forskjellige teknikker og prinsipper for å definere et device (enhet), en prosess eller et system tilstrekkelig detaljert til å gjennomføre en fysisk realisering. Målet for konstruktøren er å lage en modell eller representasjon av en enhet som senere skal bygges. Systemutvikling Kap 13 Konstruksjon 1 Systemutvikling Kap 13 Konstruksjon Programvare konstruksjon og utvikling Software Design and Software Engineering Konstruksjon inngår i alle utviklingsmodeller. Den er den første av tre tekniske aktiviteter: 1. Konstruksjon 2. Koding 3. Testing Fig viser infoflyten i konstruksjonsfasen. Systemutvikling Kap 13 Konstruksjon 3 Systemutvikling Kap 13 Konstruksjon Programvare konstruksjon og utvikling -2 Konstruksjonen produserer: 1. Datakonstruksjon - datamodellering, datastrukturer 2. Arkitektur konstruksjon - Definerer forholdet mellom hovedkomponentene i programmet. 3. Grensesnitt konstruksjon - mellom moduler (internt), mot andre programmer og mot brukere (info-flyt: data/kontroll) 4. Prosedyrekonstruksjon - Overfører de strukturelle komponentene til prosedyrebeskrivelser Konstruksjonsprosessen Konstruksjon er en iterativ prosessen som skal overføre kravspesifikasjonen til en representasjon av programvaren. Konstruksjon er viktig for kvaliteten og vedlikeholdbarheten av programvaren. Konstruksjonen er grunnlaget for alle senere utviklingsaktiviteter. Systemutvikling Kap 13 Konstruksjon 5 Systemutvikling Kap 13 Konstruksjon 6

2 Konstruksjon og programvarekvalitet Gjennom konstruksjonsprosessen sikres kvaliteten med formelle tekniske presentasjoner (reviews) eller konstruksjonsgjennomganger (Walkthroughs) Vi kan bruke 3 kriterier for å evaluere god konstruksjon: Konstruksjonen må implementere alle eksplisitte krav i analysemodellen, og oppfylle kundens implisitte ønsker. Konstruksjonen må være en lesbar og forståelig veiledning for de som skriver kode, utfører tester og vedlikeholder programmet. Konstruksjonen må gi et komplett bilde av programvaren innenfor data-, funksjons- og virkeområdet Konstruksjon av programvarekvalitet-2 Vi kan sette opp følgende retningslinjer (kriterier) for god design kvalitet: 1. Hierarkisk organisering. Intelligent kontroll mellom programkomponentene. 2. Modulær oppbygging. Logiske komponenter som utfører spesifikke funksjoner/subfunksjoner. 3. Data- og prosedyreabstraksjoner. 4. Moduler som har uavhengig funksjonell karakteristikk. 5. Grensesnitt som reduserer kompleksiteten av forbindelsen mellom modulene og med eksterne omgivelser. 6. Utføres med repeterbare metoder som drives frem av info fra kravanalysen. Systemutvikling Kap 13 Konstruksjon 7 Systemutvikling Kap 13 Konstruksjon Evolusjon av programkonstruksjon Historie: Modullære programmer Top-down.. Strukturert programmering Dataflyt og datastrukturer Konstruksjon def.. Objektorientert konstruksjon Metodene har følgende fellestrekk: 1. En mekanisme for overføring fra representasjon av infodomene til konstruksjonsrepresentasjon. 2. En notasjon for å representere funksjonelle komponenter og deres grensesnitt. 3. Heuristikk (regler for) forbedring og oppdeling 4. Retningslinjer for kvalitetssikring Konstruksjonsprinsipper Vi kan sett opp en liste av konstruksjonsprinsipper: Konstruksjonsprosessen må ikke lide av tunnelsyn vi må vurdere flere alternativer i forhold til problemet, tilgjengelige ressurser og konstruksjonsmodell. Konstruksjonen må kunne spores tilbake til analysemodellen. Konstruksjonen skal ikke finne opp hjulet på nytt. (Gjenbruk) Konstruksjonen bør være slik at strukturen i programmet reflekterer strukturen i problemområdet. Konstruksjonen må være enhetlig og integrerende. Alle som utfører konstruksjonen må følge de samme reglene, og det må defineres grensesnitt mellom modulene. Systemutvikling Kap 13 Konstruksjon 9 Systemutvikling Kap 13 Konstruksjon Konstruksjonsprinsipper Konstruksjonen må struktureres slik at det er lett å utføre endringer. Konstruksjonen må struktureres slik at systemet stopper kontrollert, selv med unormale data, hendelser, eller feil bruk. (Robust program). Konstruksjon er ikke koding (programmering), programmering er ikke konstruksjon. Konstruksjon er på et høyere abstraksjonsnivå. Bare små detaljer i konstruksjonen kan utsettes til kodingen. Konstruksjonen må kvalitetssikres mens den utføres, ikke etter at den er laget. Konstruksjonen må gjennomgås (reviewed) for å minimalisere logiske feil. Hvis disse prinsippene anvendes, får vi en konstruksjon som har både ekstern og intern kvalitet Konstruksjonsprinsipper Eksterne kvalitetsfaktorer er egenskaper ved programvaren som observeres av brukerne (hastighet, pålitelighet, korrekt, brukervennlig). Interne kvalitetsfaktorer er viktige for systemutviklerne, og gir høy kvalitet på konstruksjonen, sett fra et teknisk perspektiv. Systemutvikling Kap 13 Konstruksjon 11 Systemutvikling Kap 13 Konstruksjon 12

3 13.4 Konstruksjonsmodeller Vi skal her se på prinsipper og konsepter for konstruksjon. De skal hjelpe oss til å besvare følgende spørsmål: 1. Hvilke kriterier kan brukes til å dele opp programvaren i individuelle komponenter (moduler)? 2. Hvordan er funksjoner og datastruktur-detaljer adskilt fra en konseptuell representasjon av programvaren? 3. Er det ensartede kriterier som definerer teknisk kvalitet for programkonstruksjon? Abstraksjon Når vi skal lage en modulær løsning av et problem, må vi se problemet på flere abstraksjonsnivå: Høyeste nivå: Må beskrives i et brukerforståelig språk Laveste nivå: Problemorientert språk Problemorientert koples også med implementasjonsorientert, d.v.s. at vi på laveste nivå bruker en form som kan implementeres direkte. Hvert trinn (fase ) i utviklingsprosessen er en detaljering av abstraksjonsnivå. Tilsvarende når vi går mot detaljert konstruksjon reduseres abstraksjonsnivået. Det laveste nivå er koden. Systemutvikling Kap 13 Konstruksjon 13 Systemutvikling Kap 13 Konstruksjon Abstraksjon - 1 Prosedyremessig abstraksjon - navngitt prosedyre Dataabstraksjon - navngitt samling av data som beskriver et dataobjekt. Flere programmeringsspråk har mekanismer for å lage abstrakte datatyper (ADT). En ADT inneholder datastrukturer og operasjoner (prosedyrer) som opererer på data. Kontrollabstraksjon - omfatter en programkontrollmekanisme uten å spesifisere interne detaljer. Eksempel på en slik er semaforer for synkronisering som brukes i operativsystem Detaljering (Refinement) Stegvis forfining eller detaljering (stepwise refinement) er en topdown (fra høyeste til laveste nivå) kostruksjonsstategi (Nikolaus Wirth): Vi starter med en overordnet beskrivelse av funksjoner som dekomponeres til subfunksjoner osv. til vi har et detaljeringsnivå som tilsvarer setninger i programmeringsspråk. Data deles opp (detaljeres) på tilsvarende måte. Metoden innebærer også at vi starter på et abstrakt nivå og går nedover mot et mer og mer detaljert nivå og en konkret beskrivelse. Tilsvarende i programmering: Vi starter med å skrive hovedprogrammet og alle prosedyrehoder på øverste nivå (evt. med stubs som gjør at vi kan kalle prosedyrene og se at de kalles i riktig rekkefølge). Deretter skrives koden for Prosedyrene på øverste nivå og prosedyrehoder for nivået under osv... Systemutvikling Kap 13 Konstruksjon 15 Systemutvikling Kap 13 Konstruksjon Modularitet I arkitekturkonstruksjon deles systemet opp i separate, navngitte og adresserbare komponenter kalt moduler som integreres for å tilfredsstille problemkravene. Men hvor mange moduler skal vi dele systemet opp i? La C(x) - funksjon som definerer kompleksiteten til problem x E(x) - funksjon som definerer innsatsen (tidsforbruket) for å løse problem x For to problem p 1 og p 2 gjelder at (13-1 a,b) C(p 1 ) > C(p 2 ) => E (p 1 ) > E(p 2 ) Det tar altså mer tid å løse et komplisert problem! Modularitet - 2 En annen erfaring fra problemløsning er at: (13.2) C(p 1 + p 2 ) > C(p 1 ) + C(p 2 ) Kompleksiteten av et problem som inkluderer både p 1 og p 2 er større enn summen av kompleksiteten til hvert problem. Av (13.1) følger at (13.3) E (p 1 + p 2 ) > E(p 1 ) + E(p 2 ) Konklusjon: Det er lettere å løse et komplisert problem når det deles opp i mindre problem! Men: For et gitt problem vil oppdeling føre til mange små moduler som det kreves innsats for å lage grensesnitt mellom, og å integrere modulene. Systemutvikling Kap 13 Konstruksjon 17 Systemutvikling Kap 13 Konstruksjon 18

4 Modularitet Modularitet - 4 Innsatskostnad Minimum kostnad M Totale kostnader Kostnad grensesnitt Kostnad pr. modul Det er altså et tall M for antall moduler som gir minimale utviklingskostnader, men M kan ikke forutsies eksakt. Størrelsen på hver modul bestemmes av funksjonen og applikasjonen. Det kan være tilfeller der flere funksjoner må integreres i en modul av plass- og ytelseshensyn, men filosofien om modularitet må vises! Antall moduler Fig viser kurven for kostnad pr. modul, og for interfacing som til sammen gir totale kostnader. Systemutvikling Kap 13 Konstruksjon 19 Systemutvikling Kap 13 Konstruksjon Modularitet - 5 Hvordan lager vi en modul med en gitt størrelse? Dette avhenger av metoden som brukes. Vi har 5 kriterier som kan være til hjelp ved vurderingen av en konstruksjonsmetodes muligheter til å definere et effektivt modulært system: 1. Modulær nedbrytbarhet Hvis metoden har en systematisk mekanisme for dekomponering av problemet i delproblemer, vil kompleksiteten av hele problemet reduseres, og vi får en effektiv modulær løsning. 2. Modulær sammensettbarhet (oppbyggbarhet) Hvis metoden gjør det mulig å sette sammen (gjenbrukte) moduler til et nytt system, gir det en modulær løsning (ikke finn opp hulet på nytt!) Modularitet Modulær forståelighet Hvis en modul kan forstås som en selvstendig enhet (uten referanse til andre moduler), vil det være lettere å bygge og vedlikeholde modulen. 4. Modulær kontinuitet Hvis små endringer i systemkrav resulterer i endringer i individuelle moduler, og ikke spredt over hele systemet, vil virkningen av sideeffekter introdusert av endringene bli minimalisert. 5. Modulær beskyttelse Hvis en avvikende situasjon (feil) oppstår i en modul, og dens effekter er begrenset til denne modulen, vil virkningen av feilinduserte sideeffekter minimaliseres. Systemutvikling Kap 13 Konstruksjon 21 Systemutvikling Kap 13 Konstruksjon Programarkitektur Arkitekturen til et program viser den hierarkiske strukturen av programkomponentene (modulene), hvordan de kommuniserer og datastrukturene de bruker. Arkitekturen utvikles gjennom en oppdelingsprosess. Vi tar utgangspunkt i kravspesifikasjonen og ender opp med en oppdeling der hver funksjon vises. Forskjellige metoder gir forskjellige strukturer. Hvilken som er best kan ikke avgjøres, men vi skal senere se på karakteristikker for god kvalitet Programarkitektur -2 Følgende egenskaper bør spesifiseres som del av arkitekturkonstruksjonen: Strukturelle egenskaper definerer komponentene i systemet (moduler, objekter..), hvordan de er pakket (sammensatt), og hvordan de kommuniserer. For eksempel er objekter pakket slik at både data og prosedyrer som opererer på disse er innkapslet Ekstrafunksjonelle egenskaper viser hvordan arkitekturen oppfyller krav om ytelse, kapasitet, pålitelighet, sikkerhet, tilpasningsevne og andre systemkarakteristikker. Familie av relaterte (tilsvarende) systemer arkitekturkonstruksjonen skal dra nytte av konstruksjon av tilsvarende system (gjenbruk). Systemutvikling Kap 13 Konstruksjon 23 Systemutvikling Kap 13 Konstruksjon 24

5 Programarkitektur -3 Arkitekturkonstruksjonen kan representeres av en eller flere modeller: Strukturelle modeller representerer arkitekturen som en organisert samling av programkomponenter. Rammeverk modeller øker abstraksjonsnivået ved å identifisere fellestrekk i konstruksjon for tilsvarende applikasjoner. Dynamiske modeller viser hvordan programmet virker, og hvordan strukturen eller systemkonfigurering kan forandre seg som følge av eksterne hendelser (events). Prosessmodeller fokuserer på konstruksjon av forretnings eller tekniske prosesser som systemet må oppfylle. Funksjonelle modeller kan brukes til å representere det funksjonelle hierarkiet til systemet Kontrollhierarki - Control Hierarchy Fig viser trestruktur for programhierarki for programstrukturen. Vi kan også bruke såkalt Warnier-Orr eller Jackson diagram Mål og terminologi: Dybde og bredde gir en indikasjon på antall kontrollnivå og det totale kontrollspenn. Dybde - antall kontrollnivå. Bredde - totalt kontrollspenn. Fan-out (vifte ut) - er et mål på antall moduler som er direkte kontrollert av en annen modul. Fan-in (vifte inn) - indikerer hvor mange moduler som kontrollerer en gitt modul. Systemutvikling Kap 13 Konstruksjon 25 Systemutvikling Kap 13 Konstruksjon Kontrollhierarki -2 En modul som kontrollerer en annen er overordnet (superordinate) til denne. En modul som kontrolleres av en annen er underordnet (subordinate) til kontrollmodulen. Eks. fig 13.3 Modul M M Fan-out er overordnet til a, b og Dybde c, og modul h er underordnet e (og a b c M). d e k l m Systemutvikling Kap 13 Konstruksjon 27 f g i h j Bredde n Fan-in o r p q Kontrollhierarki -3 Breddeorienterte relasjoner har ingen spesiell terminologi. Synlighet (visability) indikerer mengden av programkomponenter som kan startes/kalles eller bli brukt som data av en gitt komponent (selv om dette skjer indirekte). I objektorienterte systemer er dette alle dataobjekter som en modul har arvet, men den bruker (aksesserer) nødvendigvis ikke alle. Alle objekter er synlige for modulen. Binding (connectivity) indikerer mengden av komponenter som kalles/startes direkte eller brukes som data av en gitt komponent. F.eks. En modul som direkte får en annen modul til å starte eksekvering er bundet til den. Systemutvikling Kap 13 Konstruksjon Strukturell oppdeling Programstrukturen må deles opp både horisontalt og vertikalt. Fig. 13.4a viser horisontal oppdeling, der det er ei hovedgrein for hver funksjon. Kontrollmoduler (øverst, mørkere) koordinerer kommunikasjonen mellom, og utføring av funksjonene. Den enkleste form for horisontal oppdeling definerer tre (under)moduler: Input, prosessering og output. Fordeler ved horisontal oppdeling: Lettere å teste programmene Lettere å vedlikeholde programmene. Færre og mindre spredning av sideeffekter. Lettere å utvide programmene. Systemutvikling Kap 13 Konstruksjon 29 Systemutvikling Kap 13 Konstruksjon 30

6 Strukturell oppdeling -2 En ulempe ved horisontal oppdeling er at det ofte fører til at store mengder data overføres (gjennom grensesnittene) mellom modulene, og dette kompliserer kontrollen av programflyten. Vertikal oppdeling (Fig 13.4b), også kalt faktorisering deler kontroll (beslutninger) og arbeid top-down: Topp-nivå moduler utfører kontrollfunksjoner. Moduler på lavere nivå er arbeidere som utfører all input, beregninger og outputoppgaver. Endringer i arkitekturen gjør at vertikal dekomponering er fordelaktig Datastrukturer Datastrukturer er representasjon av de logiske forhold mellom de individuelle dataelementer. Datastrukturene styrer organisering, aksessmetoder, assosiativitet (kopling) og prosesseringsalternativ for informasjonen. Data bør organiseres i et informasjonshierarki. Den enkleste datastrukturen er et skalart felt (item) som er et enkelt informasjonselement som kan adresseres gjennom en identifikator (variabelnavn) Systemutvikling Kap 13 Konstruksjon 31 Systemutvikling Kap 13 Konstruksjon Datastrukturer -2 Matriser (n-dimmensjonale rom) implementeres som flerdimmensjonale array. Lenkede lister organiserer ikke-kontinuerlige skalare felt, vektorer eller rom på en måte som tillater at de behandles som lister. Hver node har pekere som indikerer adressen i lagret til neste node. Nye noder kan legges til dynamisk (new..). Andre datastrukturer inneholder eller er konstruert ved å bruke de fundamentale datastrukturene, f.eks: Hierarkiske datastrukturer kan implementeres som multilenkede lister som inneholder skalare elementer, vektorer, og eventuelt n-dimmensjonale rom. (array) Datastrukturer -3 Hierarkiske strukturer der det er nødvendig å kategorisere og assosiere informasjon. Kategorisering er gruppering av informasjon etter generelle kategorier (sortering). Assosiativitet gir mulighet til å assosiere (kople) informasjon fra forskjellige kategorier. Datastrukturer (akkurat som program) kan ha forskjellig abstraksjonsnivå. Systemutvikling Kap 13 Konstruksjon 33 Systemutvikling Kap 13 Konstruksjon Prosedyrer Software Procedure Prosedyrer fokuserer på prosesseringsdetaljer til hver individuelle modul. Dokumentasjonen må vise presis spesifikasjon av prosessering, inkludert sekvensen av hendelser, beslutningspunkt, repeterte operasjoner og dataorganisering og -strukturer. Programbeskrivelsen for hver modul må inkludere referanser til alle underordnede moduler. Fig viser at prosedyrerepresentasjonen av programvare er lagdelt. Systemutvikling Kap 13 Konstruksjon 35 Systemutvikling Kap 13 Konstruksjon 36

7 Informasjonsskjuling Information hiding Information hiding (abstrakte datatyper, ADT innkapsling i OOP). Informasjon i en modul kan ikke aksesseres av andre moduler enn de som har behov for denne informasjonen. Innkapsling medfører at effektiv modularitet kan oppnås ved å definere et sett moduler som kommuniserer med hverandre. Bare den informasjon som er nødvendig for å utføre funksjonene utveksles. Den største fordelen med innkapsling er når en modul skal endres, og senere under vedlikehold. Feil som introduseres under endring sprer seg ikke til andre moduler Effektiv modulær konstruksjon Modularitet er anerkjent i alle ingeniørdisipliner. Fordeler med modulær konstruksjon: Reduserer kompleksiteten Lettere å gjøre endringer (viktig for vedlikehold) Lettere implementasjon ved at forskjellige systemdeler kan implementeres parallelt. Systemutvikling Kap 13 Konstruksjon 37 Systemutvikling Kap 13 Konstruksjon Funksjonell uavhengighet Funksjonell uavhengighet oppnås ved å utvikle funksjoner med enkel (en eneste) funksjon, og unngå overdreven interaksjon (kommunikasjon) med andre moduler. Hver modul utfører en spesifikk subfunksjon i kravspesifikasjonen, og har et enkelt grensesnitt når den ses fra andre deler av programstrukturen. Hvorfor er uavhengighet viktig? Svar: Lettere utvikling Enklere grensesnitt Parallell utvikling i grupper Lettere å vedlikeholde fordi sideeffekter ved endringer reduseres, feilforplantning (spredning) reduseres. Gjenbrukbare moduler Funksjonell uavhengighet -2 Til å måle uavhengighet brukes to kvalitative kriterier: 1. Sammenheng (cohesion) er et mål for relativ funksjonell styrke til en modul. 2. Kobling (coupling) er et mål for den relative uavhengighet mellom modulene. Vi skal se nærmere på de to kriteriene i de to følgende avsnitt. Systemutvikling Kap 13 Konstruksjon 39 Systemutvikling Kap 13 Konstruksjon Sammenheng (Cohesion) En sammenhengende modul utfører en enkelt oppgave. Skalaen er ikke lineær. Lav sammenheng er mye verre enn middels, mens middels er nesten like godt som høy sammenheng. Tilfeldig - Flere oppgaver som har liten sammenheng i samme modul Logisk - Oppgavene har logisk sammenheng, f.eks. all output. Temporær - Flere oppgaver som utføres i samme tidsperiode. Prosedyremessig (prosedural) - Oppgavene har forbindelse med hverandre og må utføres i en bestemt rekkefølge. Kommunikasjonsmessig - Alle prosesseringselementer behandler et område av en datastruktur. Funksjonell (høy) - Modulen utfører en oppgave. Vi trenger ikke bestemme presist hvilken sammenheng vi har, men vi må gjenkjenne lav sammenheng slik at konstruksjonen kan endres for å oppnå større funksjonell uavhengighet Kopling Kopling er et mål for forbindelsen mellom moduler i en programstruktur. Kopling avhenger av kompleksiteten til grensesnittet mellom modulene, entrypunkt (inngangspunkt) eller referanse til modulen, og hvilke data som passerer gjennom grensesnittet. Vi vil ha lavest mulig kopling! Lav kopling gjør at programmene er lettere å forstå, og mindre muligheter for at feil i en modul skal spre seg til andre. Kontrollkopling (moderat kopling) - Kontroll utveksles mellom modulene som den andre modulen (over eller under) brukes til å ta beslutninger. I enkleste tilfelle er det et flagg. Ekstern kopling (høy kopling) - En modul er koplet til eksterne enheter, f.eks. I/O-enheter, protokoller osv. Dette bør isoleres til noen få moduler. Systemutvikling Kap 13 Konstruksjon 41 Systemutvikling Kap 13 Konstruksjon 42

8 Kopling -2 Common kopling - Flere moduler bruker globale data. På fig 13.7 aksesserer modulene c, g og h felles data. Globale data må brukes med forsiktighet! Innholdsmessig (content) kopling - En modul bruker data eller kontroll informasjon som vedlikeholdes inni en annen modul, eller har forgreining inn i en annen modul (bruker kode). Dette bør unngås! Men under utvikling vil vi alltid ha ekstern kopling, f.eks. i operativsystem: Drivere, kommunikasjon, protokoller osv Konstruksjonsregler for effektiv modularisering De følgende regler brukes til å forbedre konstruksjonen når den første versjonen er laget: 1. Evaluer første versjon av programstrukturen slik at kopling reduseres og sammenheng (cohesion) økes. 2. Forsøk å minimalisere strukturer med høy ut-vifte (fan-out), og arbeid for innsnevring når dybden øker. 3. Hold virkeområde (scope of effect) innenfor kontrollområdet (scope of control) for modulen. 4. Vurder modulgrensesnittene for å redusere kompleksitet og redundans, og forbedre konsistensen. 5. Definer moduler hvis funksjon er forutsigbar (svart boks), men unngå moduler som er altfor innskrenkende. 6. Streb etter kontrollerte innganger i moduler, og unngå innhopp i moduler (mulig i assembler og enkelte språk). 7. Pakk programvaren ut fra rammebetingelsene fra konstruksjon og portabilitetskrav. Systemutvikling Kap 13 Konstruksjon 43 Systemutvikling Kap 13 Konstruksjon Konstruksjonsmodell Pyramidemodellen i fig skal symbolisere at god konstruksjon er stabil. Detaljer om konstruksjonsmodeller i kap. 14 og 21 (objektorientert konstruksjon) Konstruksjonsdokumentasjon (fra 4. utgave) I. Scope A. System objectives B. Major software requirements C. Design constraints, limitations II. Data Design A. Data objects and resultant data structures B. File and database structures 1. external file structure a. logical structure b. logical record description c. access method 2. global data 3. file and data cross reference III. Architectural Design A. Review of data and control flow B. Derived program structure Systemutvikling Kap 13 Konstruksjon 45 Systemutvikling Kap 13 Konstruksjon 46 IV.Interface Design A. Human-machine interface specification B. Human-machine interface design rules C. External interface design 1. Interfaces to external data 2. Interfaces to external systems or devices D. Internal interface design rules (' V. Procedural Design For each module: A. Processing narrative B. Interface description C. Design language (or other) description D. Modules used E. Internal data structures F. Comments/restrictions/limitations VI. Requirements Cross-Reference VII. Test Provisions 1. Test guidelines 2. Integration strategy 3. Special considerations VIII. Special Notes IX. Appendices Systemutvikling Kap 13 Konstruksjon 47