Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Transkript

1 Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Innholdsfortegnelse: 1. DESIGN (UTFORMING) MÅL FOR DESIGN TRINN I DESIGNPROSESSEN PROGRAMVAREARKITEKTTUR MODULDEKOMPONERING MODULSTYRKE (KOHESJON) MODULKOBLING SYSTEMARKITEKTUR AVSLUTNING PROGRAMMERINGSFASEN DOKUMENTASJON DRIFTSDOKUMENTASJON BRUKERDOKUMENTASJON AVSLUTNING... 9

2 1. Design (Utforming) Det å kunne forstå betydningen av designfasen på et rimelig nivå, krever at en har lært og praktisert programmering. Siden det ikke forutsettes at en skal kunne programmere for å ta dette kurset, vil designfasen bli behandlet i veldig grove trekk slik at dere kan se sammenhengen i hele systemutviklingsprosessen. Systemdesign er vurdering av alternative løsninger og spesifisering av en detaljert databasert løsning. Analogien til husbygging er at det må utformes detaljerte tegninger før en begynner selve byggingen. System design bygger på det som er kommet frem fra systemanalysen. I denne fasen må en få med fysisk design f.eks. en detaljert databasert løsning Mål for design Vi har følgende mål for design: Finne en løsning som tilfredsstiller kravene som er spesifisert i kravspesifikasjonen Å definere denne løsningen i tilstrekkelig detalj slik at det er mulig å gjennomføre en implementasjon (koding) i et egnet programmeringsspråk Trinn i designprosessen Designprosessen er meget omfattende når store systemer skal utvikles. De viktigste trinnene er: 1. Problemforståelse Det er viktig å settes seg grundig inn i kravspesifikasjonen, særlig gjelder dette for nye medlemmer av utviklingsteamet som er kommet til i denne fasen. 2. Identifisering av en eller flere løsninger Her vurderes de mulige alternative løsninger som er beskrevet tidligere og en velger den en anser som den beste ut fra gitte kriterier slik som økonomi, eksisterende datautstyr, nettverksløsning, utviklers erfaring med tilsvarende løsning, gjenbruk av komponenter osv. 3. Beskrive løsningen på et overordnet og abstrakt nivå Her benyttes det som er utarbeidet i analysefasen, men en går igjennom dette grundigere for å avdekke feil og utelatelser. Den overordnede løsningene dekomponeres i mindre moduler på et lavere nivå. side 2 av 10

3 Etter hvert som denne dekomponeringen fortsetter vil en kunne tilføye flere detaljer til spesifikasjonen. I denne prosessen der spesifikasjonen blir mer og mer detaljert, kan en oppdage forhold som gjør at en må revidere kravspesifikasjonen. Det er viktig å være oppmerksom på dette da kravspesifikasjonen kan være et kontraktsgrunnlag overfor oppdragsgiver. 4. Detaljspesifisere den enkelte modul i løsningen Her skal den enkelte modul være spesifisert i detalj slik at den er direkte programmerbar. Hva som er en modul vil avhenge av hvilken metode vi bruker når vi designer. Er utgangspunket strukturt analyse med dataflytdiagrammer blir modulen gjerne en funksjonell enhet som bearbeider en strøm av data. Utvikler vi objektorientert blir modulene objekter med funksjoner som opererer på data innkapslet i objektene Programvarearkitekttur Å etablere en programvarearkitekttur er første aktivitet i designfasen. Et stort datasystem deles opp i flere subsystemer som igjen dekomponeres i moduler. Arbeidet går ut på å identifisere sub-systemer og moduler i de fremtidige løsninger, og definere et rammeverk for kommunikasjonen mellom disse. Programvarearkitektur har flere perspektiver. Grovt kan vi dele det i logisk arkitektur og fysisk arkitektur. Den logiske arkitekturen viser hvordan programvaren er strukturert uten tanke på om den skal kjøre på en enkelt maskin eller i et nettverk hvor programvaren er fordelt på flere maskiner. Arbeider man med dataflytskjema vil man lage en logisk arkitektur, ved omforme dataflytdiagram til strukturkart. De ulike prosesser i dataflytdiagrammene blir gjort om til moduler i strukturkart. Vi kan ikke gå nærmere inn detaljene i denne leksjonen for det krever mer kunnskap enn det som er gitt her. Vi skal vise et eksempel på et slikt strukturkart: System level Sub-system level side 3 av 10

4 Strukturert Design er å utarbeide en hierarkisk systemløsning med de samme komponenter og relasjoner mellom dem som det problemet som skal løses. Løsningen må ha samme form som problemet. Dette er en top-down design som starter med det øverste nivå og dekomponerer nedover nivå for nivå. Strukturen på dataflytdiagrammene avgjør hvordan strukturkartet blir. Hver modul må være liten og håndterbar og den enkelte modul skal kunne endres uten bieffekter i andre moduler. I designfasen må en også identifisere nødvendige produkter og vurdere om en skal kjøpe ferdige system helt eller delvis. I figuren over er noen av modulene i strukturkartet skravert. Det er moduler som en allerede har laget tidligere og som en kan bruke på, nytt. Hvis man utvikler objektorientert er utgangspunktet for design først og fremst bruksmønster, problemdomenemodell og system sekvensdiagrammer. Man arbeider systematisk med disse modellene for å ende opp med en designklassemodell. Denne viser klasser og sammenhenger mellom klasser. Er denne jobben gjort grundig, kan et verktøy som for eksempel Rational Rose, automatisk genere mye av koden for programmet. Det er naturlig at mange av klassene fra problemdomenemodellen finnes igjen som programvareklasser etter design. Et av poengene med objektorientering er nettopp å arbeide med de samme begreper både når man analyserer problemet og finner frem til krav og når man realiserer systemet. Det gjør overgangen fra problem til løsning enklere (håper man). Vi skal belyse de to tilnærmingene til design med et enkelt eksempel. Det skal lages et program som beregner personskatt. Et dataflytdiagram for problemet kan se ut som vist i denne figuren. side 4 av 10

5 skatte- Skatteklasse Beregn inntekts Inntektsskatt Skriv inntekts Inntekt Skatteklasse inntekt Beregn formue- Formuesskatt Formue Skriv formue- formue De stiplete linjene markerer skiller mellom dataflyt inn i systemet, bearbeiding av data i midten og dataflyt ut av systemet. Hovedideen er at dette diagrammet skal avbildes i en hierarkisk struktur ved at man tar tak i bearbeidingsdelen og plasserer den på toppen i hierarkiet og lar boblene bli moduler. Dette er vist neste figur. side 5 av 10

6 Beregn skatt data Beregn Beregn Skriv ut inntektsskatt formueskatt skatt skatteklass inntekt formue Skriv inntektsskatt Skriv formueskatt Med objektorientert design ville vi endt opp med dette logiske designet: Presentasjonslag Brukergrensesnitt Domenelag Kontroller Skatt Skatteyter Formue Inntekt Skatteklasse Datalag Data 1.4. Moduldekomponering Man deler her det enkelte subsystem opp i mindre komponenter. For å kunne gjøre dette må en, som nevnt i forrige avsnitt ta utgangspunkt i modellene fra analysefasen (for eksempel side 6 av 10

7 DFD-diagram) og definerer så en modulstruktur for systemet. Ved å dekomponere oppnår en følgende: kompleksiteten reduseres ved at det er enklere å ha oversikt over enkle moduler med en eller svært få funksjoner bevarer oversikten over totaliteten og detaljer gir mulighet ved parallell utviklingsarbeid ved at flere kan begynne å programmere på hver sine moduler som deretter integreres i en helhetlig løsning bedre endrings- og gjenbruksmuligheter 1.5. Modulstyrke (Kohesjon). Modulstyrken er et mål på de interne forholdene i en modul og det helt ideelle er å komme frem til moduler som er enfoldige. En enfoldig modul er en modul som ideelt sett bare gjør en ting eller er sammensatt av enkle, tett sammenknyttede og veldefinerte funksjoner. Kun de elementene som trengs for å utføre den enkle funksjonen inngår i modulen. Det er liten eller ingen avhengighetsforhold mellom de enkelte moduler i systemet. Fordeler og ulemper med å tilstrebe høy modulstyrke: Høy styrke gir god vedlikeholdbarhet Overdreven dekomponering for å oppnå enfoldige moduler kan føre til for mange små moduler 1.6. Modulkobling Hvis modulene er designet slik at de blir avhengig av hverandre for eksempel at hvis en funksjon i en modul må kalle en funksjon i en annen modul for å kunne utføre beregningen, så er det en kobling mellom disse modulene. For at et program skal fungere må det være en kobling mellom moduler. Men det er et godt designprinsipp å gjøre det slik at moduler koples få andre moduler. Da oppnår man at endringer i en modul ikke får konskvenser for mange andre moduler og modulene kan lettere gjenbrukes i andre programmer. Det er de samme hensynene som ligger bak prinsippet om kohesive moduler. Sammen fører de bruken av de to prrinsippene til lettere vedlikehold av programsystemet og øker muligheten for gjenbruk. Og det er det økonomi i. Det ideelle er altså å komme frem til moduler med lav kobling og høy kohesjon. Dette er prinsipper som skal følges uavhengig av designmetode. Man har følgende arbeidsprinsipper for utvikling av moduler: Sterk modulkobling vanskeliggjør vedlikehold Lav kobling tilsier at datautvekslingen er minimal og dermed vil endringer og feilsøking bli enklere Ved å holde datastrukturene internt i den enkelte modul oppnår man en lavere koblingsgrad Globale data er et skrekk-eksempel på høy kobling side 7 av 10

8 1.7. Systemarkitektur En skal kort si noe om systemarkitektur. Det totale datasystem deles opp i subsystem. En grov inndeling av en systemarkitekturen kan være: Repository modell en sentralisert database som holder på informasjonen og sub-systemene aksesserer denne Klient-tjener modell definerer hvordan man skal distribuere data og prosessering i systemet Lagdeling vise grensesnittene mellom subsystemene Alle disse kan ses fra et logisk eller fysisk perspektiv. I et fysisk perskektiv viser vi hvordan delene fra det logiske designet er fordelt på forskjellige datamaskiner (stormaskin, mobiltelefon, PDA) Avslutning Som en fort kan skjønne så vil en detaljert beskriving av alle forhold i en designfase være omfattende og tidkrevende. Det er ikke noe en kan lære ved å bare lese en eller flere bøker. Det er mange veier som fører til målet og det er bare erfaring og utveksling av kunnskap med kolleger som kan bidra til at en blir god på design. 2. Programmeringsfasen Denne fasen kan være langvarig og kompleks. Ofte begynner programmeringsfasen før en er ferdig med designfasen og det hender at det gjøres oppdagelser i denne fasen som medfører endringer av gjeldende design. Derfor har en ofte en iterativ prosess mellom designfasen og programmeringsfasen Dokumentasjon Det viktigste i denne fasen er kanskje dokumentasjonen av programvaren. Det er vanlig å legge inn kommentarer i kildekoden slik at andre som senere skal vedlikeholde og endre programmet, på en grei og enkel måte kan forstå hva programmet gjør i de ulike sekvenser. Videre må en ha en dokumentasjon av de enkelte programmoduler. Denne bør inneholde følgende: identifikasjon av programmodulen hensikt med programmodulen hvordan programmodulen skal brukes (inkludert inndata, utdata, grensesnitt etc.) programmodulens funksjonalitet kommentarer gjennom hele kildekoden side 8 av 10

9 Det må også være en oversikt over alle programmodulene samt at liste med kryssreferanser der det går frem hvilke programmoduler som kalles fra en gitt programmodul Driftsdokumentasjon Et system som blir innført i en organisasjon må driftes og vedlikeholdes. Derfor er det viktig at det i denne fasen utarbeides en driftsdokumentasjon som bør inneholde følgende punkter: oversikt over systemet fra et driftssynspunkt identifikasjon av driftsansvar driftsdokumentasjon i henhold til gjeldende standard identifikasjon av nøkkelpersoner eller organisasjonsenheter beskrivelse av prosess-sykluser, kjøringer og grensesnitt identifikasjon av alle ansvarsforhold for sikkerhet og revisjon som berører driftspersonell 2.3. Brukerdokumentasjon Selv om en alltid etterstreber å gjøre et dataprogram så selvforklarende som mulig, er det nødvendig med en brukerdokumentasjon. Dette kan være en papirutgave eller en online hjelpefunksjon. Det siste er ofte hendigere hvis den er gjort kontekstavhengig i tillegg til en indeksert hjelpefil. Med kontekstavhengig menes at du får hjelp akkurat der du befinner deg i programmet når du søker hjelpefunksjonen. En brukerdokumentasjon bør inneholde: 1. Generelt orienteringsmateriale, inkludert: informasjonsbrosjyrer presentasjonsmateriell demonstrasjonsoppsett 2. Brukerhåndbøker inkludert: beskrivelse av systemets virkemåte (funksjoner) bruk av systemet i organisasjonen (manuelle rutiner) 3. Avslutning I denne leksjonen har en bare så vidt berørt overflaten på design- og programmeringsfasen. Hensikten er å gi leseren et kort innblikk i en viktig fase som er en del av selve livssyklusmodellen. side 9 av 10

10 side 10 av 10