Et lite kompendium i Systemutvikling

Transkript

1 Et lite kmpendium i Systemutvikling Kapittel Utviklingsprsesser kapittel Fssefall... 4 Prttyping... 5 Inkrementell utvikling... 5 RAD... 5 Spiralmdellen Kapittel Nye algritmiske mdeller... 6 Walstne g Felix... 6 COCOMO... 7 Funksjnspunkter... 7 COCOMO II... 8 Kst / nytte analyse Eksempel Kalendertid Eksempel Kapittel Risikstyring Prsjektplanlegging Fwler kapittel Inceptin Elabratin Kravrisik Klassediagram Aktivitetsdiagram Interaksjnsdiagram Mer m kravrisik Pakker Tilstandsdiagrammer Mer m kravrisik Teknlgisk risik Kunnskapsrisik Plitisk risik Når er Elabratin ferdig Knstruksjnsfasen Planlegging Knstruksjn Transisjn Kapittel Partisjnstesting Testing g utvikling Manuelle testteknikker Dekningsbaserte testteknikker Feilbasert testing Nen egenskaper ved testkriterier Tp-Dwn vs. Bttm-Up kapittel Finne/ekstrahere/ppdage krav Teknikker fr å finne krav Intervju Taskanalyse Use case analyse Dmeneanalyse Prttyping Dkumentasjn av krav KS dkumentet Naturlig språk... 29

2 ER diagrammer Tilstandsdiagrammer SADT diagrammer Ikke-funksjnelle krav Rammeverk Fwler kapittel Fri frmat tekst Diagram Strukturert tekst kapitel O-O analyse g design Ntasjn Klassediagram Tilstandsdiagram Sekvensdiagram Samarbeidsdiagrammer O-O analyse g design Metder Bch metden OMT metden Fusjnsmetden Nen generelle kmmentarer Fwler kapittel Asssiasjner Attributter Operasjner Generalisering Oppsummering Fwler kapittel Sekvensdiagrammer Samarbeidsdiagrammer CRC krt Fwler kapittel Pakker Samarbeid i pakker Nen gde råd Fwler kapittel Guard g aktivitet Supertilstander Genererte hendelser Parallelle tilstandsdiagrammer Nen gde råd kapittel Evaluering av en arkitektur Endringer i data Endringer i algritmer Endringer i funksjnalitet Separat utvikling av mduler Frstålighet Ytelse Gjenbruk Beskrivelse av arkitekturer Designmønster pattern Kapittel Hva er en gd design Abstraksjn Mdularitet Infrmasjnsskjuling Kmpleksitet Systemstruktur Designmetder Funksjnsdekmpsisjn... 52

3 Dataflytbasert design Design basert på datastrukturer JSP Valg av designmetde Ntasjner Dkumentasjn av design Kapittel Reverse engineering Ledelsens rlle Vedlikehld sm en tjeneste Kntrll med vedlikehld Kapittel Perspektiver på kvalitet Kvalitetssystemer Kvalitetsystemer fr prgramvare Kapittel Bibliteker Maler Design Arkitektur Gjenbruk g livssyklus Utvikling med gjenbruk Utvikling fr gjenbruk Beskrivelsesspråk Utvikling av gjenbruk Ikke-tekniske prblemer Ledelse Øknmi Prsjektregnskap Kapittel Feiltleranse Pålitelighet Basis mdell - BM Lgaritmisk Pissn mdell LPM Bruk av mdellene Til diskusjn Kapittel Grunnleggende begreper Knfigurasjnsplan Diskusjnstema Kapittel Ledelsesstil Prsjektrganisering Hierarkisk rganisasjn Matriserganisasjn Chief prgrammer rganisasjn SWAT Åpen struktur Nen gde råd Kapittel Verktøysett - Unix Språkavhengig mgivelser Verktøybenk Prsessentrerte mgivelser Sluttkmmentarer... 82

4 01-14 Kapittel 2 Nen viktige årsaker til fr sein levering: Prgrammerer ga feilaktig status fr egen kdeutvikling Arbeidet var underestimert blir frelest Dårlig eller ufullstendig planlegging blir frelest Ingen versikt ver prsjektstatus Lavere prduktivitet enn frventet / planlagt Kunden visste ikke hva han ønsket blir frelest Viktig å være klar ver at prgramvare ikke blir utviklet alene det er alltid mer rundt sm fr eksempel brukere, prsedyrer fr bruk, maskinvare g dkumentasjn. Alt dette må være på plass fr å få gjrt de ppgavene sm systemet er tiltenkt. Husk. Ingen kjøper et datasystem frdi de gjerne vil ha et datasystem. De kjøper et datasystem frdi de ønsker å få løst et prblem eller utført en ppgave. Mister vi det av synet blir resultatet misfrnøyde kunder. Vis fig 2.1. Vi må starte med planlegging. Når prsjekter går galt g det gjør de inne imellm så ligger mye av årsaken i dårlig planlegging. Hva bør være med i planleggingen: Prsessmdell hvrdan skal vi utvikle. Dette skal vi se på senere Prsjektrganisasjn. Standarder, retningslinjer g prsedyrer. Vi skal se på ne av dette senere Ledelsesaktiviteter Risikanalyse. Dette skal vi se på senere Persnell Metder g teknikker. Vi skal se på mye av dette senere. Kvalitetssikring. Vi kmmer ikke til å si så mye m dette. Det er et eget kurs sm behandler mrådet. Arbeidspakker. Skal snakke m dette under prsjektplanlegging Budsjett g tidsplan. Blir behandlet under planlegging Endringer g endringsplanlegging Leveranse Utviklingsprsesser kapittel 3 Fr å kntrllere prsjekter deler vi de pp i faser g aktiviteter. Skal se på flere mdeller: Fssefall Prttyping Inkrementell utvikling RAD Spiralmdellen Fssefall Fig 3.1. hvedfrmålet er eventuelt var å unngå å kaste brt arbeid. Dette skulle ppnåes ved å fkusere på å ha en slid ( frsset ) kravspesifikasjn. Mdellen legger vekt på at hver fase blir avslutta med et dkumentert resultat kravspesifikasjn, verrdnet design dkument sv. Hvedprblemene sm gjør at mdellen i sin rendyrkede frm sjelden blir brukt - er at: Stre prblemer hvis kunden har tatt feil, gitt ufullstendig infrmasjn eller bare frandrer mening. Det er vanskelig å gjøre ferdig fr eksempel all design før man begynner å kde. Prsessen detaljert design kde er i seg selv iterativ. Vi ser fr eksempel at ca. 34% av design blir gjrt i kdingsfasen g ca. 10% blir gjrt under integrasjnstesting. Tegn tabellen i fig. 3.2 på tavla g kmmenter.

5 Prttyping Dette er løsningen på prblemet med ufullstendig eller misfrstått kravspesifikasjn g kunder sm frandrer mening fte sm knsekvens av at de får mer kunnskap eller erfaring med systemet. Vi kan bruke prttyper på flere måter: Fr å frstå kundens krav vis fig 3.3 Fr å eksperimentere med en algritme eller løsning Prttyping kan gjøres billig ved å gjenbruke kmpnenter man allerede har, fr eksempel Excel g Access pluss litt lim fr å lage et enkelt lagerstyringssystem. Man kan gså bruke deler av systemer man har laget før fr å lage deler av den funksjnaliteten kunden etterspør. Vanligvis vil en prttyp ha dårligere ytelse g være vanskeligere å vedlikehlde pga. at kdekvaliteten jamt ver er dårligere mer uryddig kde. Dette kan avhjelpes med streng kvalitetskntrll, men dette vil gjøre hele prsessen tyngre g langt på vei gjøre prttypingen m til inkrementell utvikling eller til xp extreme prgramming, sm bka dessverre ikke behandler. De frdelene frfatteren beskriver med evlusjnær prttyping er gså relatert til xp. Ved å bare implementere det kunden ser han har behv fr vil man i nen tilfeller lage et system med mindre, men mer brukerretta funksjnalitet. Prttyping setter vanligvis større krav til utviklerne det er en jbb sm krever en gd del erfaring hvis det ikke skal bli fullstendig skjærereir, gså kalt write nly kde. Prsjekter sm bruker prttyping må huske på at dette ikke er en unnskyldning fr å kaste alle planer ver brd. Slike prsjekter må gså planlegges g styres. Inkrementell utvikling I denne utviklingsmetden er kravene kjent ved starten av prsjektet. Når systemet likevel leveres i inkrementer er det frdi kundene erfaringsmessig: Ikke helt vet hva de vil. I nen tilfeller leder dette til at systemet får fr mye funksjnalitet. Dette gjør systemene dyre g vanskelige å vedlikehlde. Endrer ppfatning etter sm tiden går de får mer erfaring de får erfaring med de delene av systemet de har fått levert ser nye muligheter Inkrementell utvikling vil vanligvis gjøres slik at man implementerer de viktigste funksjnene først. Etter hvert legger man til ny funksjnalitet g lar kundene prøve denne fr å se m den er nyttig. Dette setter grenser fr hvr lite et inkrement kan være det må gi kunden ny funksjnalitet. RAD RAD Rapid Applicaitn Develpment - har mye til felles med evlusjnær prttyping g inkrementell utvikling. I tillegg kmmer time bxing, sm ikke finnes i de andre metdene. En metde sm bruker time bxing har følgende egenskaper: Lengden på tidsbksen blir bestemt først dermed ligger leveringstiden fast. Hvis vi ppdager at vi ikke kan bli ferdige med det vi hadde planlagt innenfr tidsbksen fjerner vi ne funksjnalitet. Denne blir da verført til en annen tidsbks. RAD har fire faser i følgende rekkefølge: 1. Kravplanlegging 2. Brukerdesign 3. Knstruksjn 4. Idriftsetting Kravplanlegging g brukerdesign blir gjrt i samarbeid ned kunden. Til det bruker vi wrkshp er. Kravplanlegging JRP (Jint Requirement Planning). Her prøver man å bli enige m så mange sm mulig av kravene slik at de ikke må endres senere. I tillegg blir krava priritert.

6 Brukerdesign JAD (Jint Applicatin Design). Det er vanlig å ha t slike wrkshper. Første JAD første, initiell design av systemet, sm er basis fr en prttyp. Brukerne får denne fr å eksperimentere med. Andre JAD brukernes evaluering av prttypen fra første JAD. Ut fra dette lager vi den endelige designbeskrivelsen. Utviklingen av systemet skjer i en sekvens av tidsbkser sm lager evlusjnære prttyper. Disse blir evaluert av brukerne g utviklerne i felleskap ved slutten av hver tidsbks. Spiralmdellen Hvedideen i spiralmdellen er å utvikle prsjektet ved å: Identifisere de prblemene i prsjektet sm fr øyeblikket har den største tilhørende risik Finne løsninger på disse prblemene. Mdellen er derfr prblem / risik-drevet. Se fig 3.6. Selve prgramvareutviklingen fregår ved å lage et sett av prttyper sm brukes til å identifisere prblemer g kartlegge risik Kapittel 7 All kstnadsestimering kan sees fra t sider: Utviklerne g prsjektleder hva vil det kst ss. Selgerne hva skal vi ta sm utgangspunkt fr salget Det er uansett viktig å vite hva det kmmer til å kste g hvr lang tid det vil ta. Hvis vi ikke vet det så blir det vanskelig å planlegge prsjektet. Lærebka mener at det har katastrfale følger å bruke plitiske beslutninger når man estimerer. Hverdagen fr mange firmaer er nk fte annerledes. Det er flere hensyn enn de reint datafaglige sm spiller inn. Det etterfølgende er nen eksempler: Hva må vi by hvis vi skal få prsjektet. Hvis vi ikke får det, hva er alternativet? Har vi ne annet prduktivt arbeid å sette flk til eller må vi si pp flk g hvilke knsekvenser har det? Hvis vi får dette prsjektet, hvilke nye muligheter gir det ss g hva er de verdt? Vi må kmme på markedet med ne før knkurrenten ellers vil han ta en str del av markedet. Eller tilsvarende vi må ha ne å demnstrere på Hannvermessa. Selv m disse punktene er viktige må vi skille skarpt mellm t ting: Det vi vil selge prduktet fr Det sm det kster å utvikle det. Tilsvarende: Hva vil det kste å lage all funksjnaliteten vi har planlagt Hva vil det kste å få til en første versjn med nk funksjnalitet til at det er interessant fr kundene Generelt gjelder at de fleste kanskje alle estimeringsmdeller er det vi kan kalle bruttmdeller. Dette innebærer at selv m de tar utgangspunkt i linjer kde, antall skjermbilder eller liknende, så er alt det andre dkumentasjn, design, testing sv inkludert i sluttestimatet. Nye algritmiske mdeller Walstne g Felix Vis generell frm E = (a + b*kloc c )*(f(x 1, X 2, X n ). Frklar parameterne g hvrdan man kan kmme fram til tallverdier fr disse lineær regresjn fra tidligere prsjekter. De enkleste frmlene er den første versjnen av Walstne g Felix frmel: E = 5.2*KLOC På denne frmen vil første knstanten vise prduktiviteten i frm av månedsverk / 1000 linjer kde. b = 5.2 betyr derfr at vi har en prduktivitet på 0.19 * 1000 linjer = 190 linjer kde pr. månedsverk eller 9 10 linjer pr. dagsverk. De fleste av dere vet at dere skriver mye mer kde enn det på en dag gjerne nen hundre linjer, fr eksempel linjer kde pr. dagsverk. I et industrielt prsjekt vil imidlertid mesteparten av tida ikke gå med til

7 kding, men til interaksjn med kunder, design, dkumentasjn, dkumentgransking sv. 250 linjer kde pr dagsverk tilsvarer 5000 linjer kde - altså 5 KSLOC - pr månedsverk. Dette gir en knstant på 0.2 i stedet fr 5.2 sm Walstne g Felix bruker. Hvedprblemet med disse metdene er å finne brukbare estimater fr KLOC tidlig i prsessen.. Det vanligste er å bryte det planlagte systemet ned i prsedyrer / mduler g bruke erfaring fra tidligere systemer til å anslå KLOC fr hver prsedyre. Denne måten å estimere på tar ikke hensyn til at frskjellige prsedyrer eller subsystemer har ulik kmpleksitet g derfr vil kreve ulike mengder ressurser. Fr å ta hensyn til dette fant Walstne g Felix et sett med faktrer sm de mente hadde str påvirkning på prduktiviteten se fig Vis g kmmenter. De definerte en prduktivitetsindeks PC definert sm Abs(maks min) g derfra en vekt W = 0.5*lg(PC). Videre innførte de en X, gitt sm X = +1 fr mindre enn nrmalt, 0 fr nrmalt g -1 fr mer enn nrmalt. På den måten gir mer enn nrmalt lavere prduktivitetsindeks, mens nrmalt (0) gir ufrandret prduktivitet. Prduktivitetsindeksen er gitt sm I = Sum(X i W i ). Eksempel: Vi har anslått at vi trenger ca linjer kde. Den enkle mdellen gir ss da E = 5.2* sm gir E lik ca. 10 månedsverk. COCOMO Tar utgangspunkt i same frmen sm Walstne g Felix, men pererer med tre typer prsjekter: Organisk lite team med mye erfaring i kjente mgivelser. Vanligvis små prsjekter, b = 2.4, c = 1.05 Embedded stre beskrankninger gitt av mgivelsene, fr eksempel maskinvare, b = 3.6, c = 1.20 Semidetached mellmfrm mellm de t frgående, b = 3.0, c = 1.12 Selv m de alle bruker samme frmel vil knstantene a g c variere. Fr å ta hensyn til frskjeller i krav g kmpleksitet fr de enkelte mdulene innfører COCOMO et sett av kstnadsdrivere Xi. Den kmplette frmelen blir E = b*kloc c * Prd(X i ). Denne tabellen har ne til felles med den vi så tidligere. Vis tabellen fra COCOMO I. Kmmenter g regn gjennm et eksempel Funksjnspunkter Basere seg på et vlummål sm kan finnes ut fra brukergrensesnittet. De bruker følgende egenskaper: Antall input typer (I) gjelder bare input sm endrer data i en datastruktur, ikke input sm bare styrer prgrammets ppførsel. Hver type sm har et nytt frmat eller blir behandlet ulikt blir regnet med. Antall utput typer (O) samme frbehld sm ver. Antall spørsmålstyper (E) frespørsler til systemet m infrmasjn. Dette er spørsmål sm ikke frandrer data i prgrammet, fr eksempel valg i menyer. Antall interne lgiske filer (L). Vi bryr ss ikke m hvrdan filene er fysisk rganisert, men bare m antall lgiske filer. Antall grensesnitt mt andre applikasjner (F) bruk eller utveksling. Ujusterte funksjnspunkter UFP = 4I + 5O + 4E + 10L + 7F. De vektene vi har brukt her er nrmalverdier. Det er mulig å i stedet bruke ulike verdier fr m fr eksempel en inputtype er enkel, nrmal (gjennmsnittlig) eller kmpleks. Se fig 7.9 g eksemplet fr input type g antall dataelementer i fig Fr å ta hensyn til en del faktrer sm påvirker prsjektet fr eksempel data kmmunikasjn, distribuert funksjnalitet g krav til ytelse blir det beregnet en justeringsfaktr. Hver påvirkningsfaktr skal graderes på en skala fra 0 til 5. Summen av disse faktrene kalles DI (Degree f Influence) g vi finner en ttal justeringsfaktr gitt sm TCF = *DI. Derfra finner vi justerte funksjnspunkter sm UP = UFP*TCF. Det finns en tilsvarende estimeringsmetde sm bygger på use case punkter. Her teller man use case enheter i stedet fr funksjnspunkter. Metden er ny g det finnes lite erfaring med å bruke den. Vi vil derfr ikke gå inn på denne metden her. Eksempel: Antall input typer (I) - 5. Alle er enkle (3)

8 Antall utput typer (O) 5. T enkle (4) g t nrmale (5) Antall spørsmålstyper (E) 12. Tre enkle (3), t nrmale (4) g fem kmplekse (6) Antall interne lgiske filer (L) 8. Alle nrmale (10) Antall grensesnitt mt andre applikasjner (F) - 0 Dette gir UFP = 5*3 + (2*4 + 2*5) + (3*3 + 2*4 + 5*6) + 8*10 = 160 Data kmmunikasjn - 3 Distribuerte funksjner - 3 Ytelse - 0 Mye brukt - 1 Transaksjnsrate - 0 Online data input - 5 Sluttbruker effektivitet - 0 On-line ppdatering - 0 Kmpleks prsessering - 0 Gjenbruk - 0 Lett å installere - 4 Lett å drive / perere - 3 Flere installasjner - 1 Lett å endre 0 DI = 20 g TCF = * 20 = 0.85 FP = 160 * 0.85 = 136 Prduktivitet 0.1 FP pr dagsverk => E = 136 / 0.1 = 1360 dagsverk = 68 månedsverk eller 6.2 årsverk COCOMO II COCOMO II er en videreutvikling av COCOMO I. Den pererer med tre detaljeringsnivåer: Applicaitn cmpsitin mdell (APM), sm hvedsakelig er beregna fr prttyping. Tidlig design mdell, sm kan brukes når vi har en arkitektur design Pst arkitektur mdell, sm brukes fr utviklingen av prgramsystemet. Det er dette sm er den mdellen sm er en videreutvikling av COCOMO I. Fr APM går vi fram sm følger: 1. Finn antall skjermbilder, rapprter g 3GL kmpnenter i systemet. 2. Fr skjermbilder g rapprter må vi bestemme kmpleksitetsgraden sm enkel, middels eller vanskelig. Fr rapprter finnes det en tabell fr å anslå kmpleksiteten. 3. Bruk tabellen i fig 7.13 fr å finnes bjektpunktene fr hvert enkelt bjekt (ikke bjekt i OO betydning) 4. Summer bjektpunktene sm gir ss OP 5. Estimer gjenbruksprsenten g finn nye bjektpunkter sm: NOP = OP*(1 gjenbruksandelen) 6. Finn prduktiviteten fr bedriften: PROD = NOP / antall månedsverk. PROD vil avhenge av erfaring, verktøy sv g kan variere fra 4 til 50. Hver bedrift må finne sin PROD verdi. 7. Nødvendig kstnad er E = NOP / PROD Tidlig designmdell bruke UFP. Deretter blir UFP knvertert til SLOC (antall kildekdelinjer). Knverteringsfaktren vil avhenge av språk, mgivelser, måten man legger ut kden på etc. Nen typiske verdier er 128 linjer C g 29 linjer C++ per funksjnspunkt. Hver bedrift må finne sin egen knverteringsfaktr. Fr å finne det endelige estimatet bruker COCOMO II sju kstnadsdrivere:

9 En kmbinasjn av kravene til pålitelighet, databasestørrelse, prduktkmpleksitet g dkumentasjnsbehv. Gjenbruk samme sm fr pst arkitektur mdellen Plattfrm sm er en kmbinasjn av krav til eksekveringstid, lagerplass g erfaring med utviklingsverktøy Utviklernes erfaring med applikasjn, plattfrm g utviklingsverktøy Utviklernes dyktighet sm systemanalytikere, prgrammerere g hvr lenge de har vært i bedriften Utviklingsverktøy g gegrafisk spredning av prsjektet. Kravene til kalendertid Hver av disse sju kstnadsdriverne graders på en sjupunkts skala fra Ekstra lav til ekstra høy. Ut fra dette finner man er verdi fr hver kstnadsdriver sm multipliseres sammen fr å justere estimatet. Pst arkitektur mdellen er den samme sm COCOMO I brtsett fra t ting: Nen av kstnadsdriverne er frandret. Isteden fr å ha tre typer utvikling har den en krreksjnsfaktr sm bygger på et sett av skaleringsfaktrer sm kan ha verdier fra 0 (svært høy) til 5 (svært lav). Kstnadsdriverne er sm vist i fig Krreksjnsfaktren b blir beregnet ut fra følgende fem skaleringsfaktrer: 1. Graden av ukjent nytt arbeid, applikasjnsmråde etc. Alt nytt = 5, ingenting nytt = 0 2. Behvet fr å være knfrm med tidligere systemer. Bundet pp av gamle systemer = 5, helt fritt = I hvr str grad vi eliminert i bende risik i utviklingen g hvr mye av arkitekturen er spesifisert. Lite (20% eller mindre) = 5, alt = I hvr str grad fungerer prsjektteamet. Dårlig kmmunikasjn g samarbeid = 5, meget gdt samarbeid = Hvr mden er rganisasjnene når det gjelder planlegging, estimering g utvikling. Helt umden = 5, meget mden = 0. COCOMO II bruker CMM her, men har gså ei egen sjekkliste til dette bruket. VI finner da b = *Sum(W i ) g E = a*ksloc b *Prd(kstdrivere). Antall kdelinjer er her det tallet vi får ved å knvertere funksjnspunkter til kdelinjer. Vi kan ta hensyn til gjenbruk ved å justere anslaget fr antall linjer kde. I COCOMO antar man at man har følgende frdeling: Design. 40% - DM Kding (utvikling) 30% - CM Integrasjn av kmpnentene 30% - IM Man må så anslå hvr mye av systemet sm må designes, kdes g integreres på nytt. Ut fra dette får,man en ny krreksjnsfaktr AAF = 0.4DM + 0.3CM + 0.3IM. I COCOMO I nøyde man seg med dette. I COCOMO II ser man i tillegg på t andre frhld. SU sm tar hensyn til graden av mdularitet i kden. Dette er et tall varierer fra 0.10 til 0.50 fr meget ustrukturert, tett kblet kde. AA sm tar hensyn til innsatsen vi trenger fr å vurdere m kmpnenten er brukbar fr det planlagte systemet.

10 Vi kan nå finne et justert antall kdelinjer gitt sm AKLOC = KLOC * (AAF + SU + AA). Vi kan nå bruke ALOC i stedet fr KLOC i de frmlene vi har sett på tidligere. Kst / nytte analyse Når man har en kstnadsmdell sm fungerer gir frnuftige svar kan den brukes til å se på nytten av endringer i prsjekt, metder eller pplæring. Fra tabellen ver kstnadsdrivere i COCOMO II ser vi at faktren fr prgrammerernes kunnskap varierer fra 1.37 (dårligst kunnskap) til 0.74 (best kunnskap). Dette vil utgjøre en faktr 1.85 fra dårligste til beste prgrammerer. Har vi fr eksempel et prsjekt på 100 årsverk med dårlige prgrammerer kan vi redusere det til 54 årsverk ved å bruke de beste prgrammererne. Ett årsverk kster ca. 1 millin krner slik at besparelsen er på 46 milliner. Tilsvarende betraktninger kan gjøre fr andre faktrer fr eksempel kstnader ved en ekstra fil eller et ekstra skjermbilde. Eksempel Vi har et system med kstnadsdrivere sm vist i fig. Ut fra de vurderingene sm er gjrt finner vi at Prd(kstnadsdrivere) = 1 * 0.93 * 1 * 0.91 * 0.95 * 1.11 * 1 * 0.87 * 1.22 * 1 * 1.10 * 1 * 1.12 * 1 * 1.12 * 1.25 * 1 = 1.63 Fr å bestemme b ser vi på skaleringsfaktrene: 1. Graden av ukjent nytt arbeid, applikasjnsmråde etc. Alt nytt = 5, ingenting nytt = Behvet fr å være knfrm med tidligere systemer. Bundet pp av gamle systemer = 5, helt fritt = I hvr str grad vi eliminert i bende risik i utviklingen g hvr mye av arkitekturen er spesifisert. Lite (20% eller mindre) = 5, alt = I hvr str grad fungerer prsjektteamet. Dårlig kmmunikasjn g samarbeid = 5, meget gdt samarbeid = Hvr mden er rganisasjnene når det gjelder planlegging, estimering g utvikling. Helt umden = 5, meget mden = 0. COCOMO II bruker CMM her, men har gså ei egen sjekkliste til dette bruket. 5 b = *( ) = 1.15 I det frrige eksemplet fant vi UFP = 160. Hvis vi skal utvikle prduktet i C finner vi at dette tilsvarer kdelinjer g KSLOC = E = a * KSLOC b * Prd(kstnadsdrivere) gir ss 3* *1.63 = månedsverk eller 14 årsverk. Hvis vi bruker a = 0.2 sm eksempel på et studentprsjekt med studentkvalitet finner vi i stedet E = 10.5 månedsverk. Kalendertid De fleste estimeringsmdeller har en frmel sm gjør at man kan utlede kalendertid fra utviklingskstnader. Det er ikke slik at prsjektet må ta denne tiden det kan gdt ta lengre tid hvis vi vil det. Det er imidlertid vanskelig å få gjennmført prsjektet på krtere tid. Walstne g Felix: T = 2.5*E 0.35 COCOMO I rgansikk prsjekt T = 2.5*E *(b 1.01) COCOMO II nminell tid T = 3.0*E

11 Det er t hvedgrunner til at vi ikke kan krte ned på tida på et pågående prsjekt ved å sette inn flere flk: Mengden av nødvendig kmmunikasjn g krdinering øker. Dette krever tid. Når vi tar inn nye flk et prsjekt må de ha pplæring. Dette betyr at de ikke er spesielt prduktive den første tiden. I tillegg tar de ressurser fra prsjektet ved at de sm kjenner prsjektet må fungere sm veiledere fr de nyansatte. Data sm er samlet inn tyder på at prduktiviteten L antall linjer pr. månedsverk er avhengig av temastørrelsen P på følgende måte: L = 777*P Mange synes nk 777 linjer per månedsverk er lite. Dette tallet inkluderer imidlertid ikke bare kding, men gså verrdna design, detaljert design, integrasjn, alle typer dkumentasjn, prsjektmøter interne g med kunde g så videre. Mange bedrifter bruker lavere tall fr eksempel 200 linjer kde pr. månedsverk ttalt ver hele prsjektet. Eksempel I frrige eksempel fant vi at det prsjektet vi så på ville kreve 158 månedsverk. Fr COCOMO II vil dette gi en gjennmføringstid på T = 3.0* *( ). Dette gir ss T = 18.4 måneder. Dette tilsvarer en bemanning på fr eksempel 8 persner på full tid g en persn på deltid. Å sette på flere persner vil antakelig ikke være effektivt. Men bare føre til større kstnader. Studentprsjektet hadde 10.5 månedsverk g den samme frmelen gir i dette tilfellet T = 7 måneder Kapittel 8 Prsjektkntrll behandler tre elementer: Det vi skal kntrllere selve prsjektet Det sm kntrllerer prsjekt prsjektleder, den rganisasjnen han har bak seg g de reglene g metdene han bruker Den infrmasjnen han bruker til å styre sine beslutninger g dermed prsjektprsessen. Denne infrmasjnen kmmer fra t kilder: Fra prsjektet fr eksempel et ntat m et prblem sm har ppstått Fra prsjektets mgivelser fr eksempel rdre m å fjerne funksjnalitet, kutte kstnader eller levere tidligere. Fr å kunne kntrllere et prsjekt effektivt er det viktig å kjenne prsjektets mål. De fleste prsjekter har flere mål. Typiske prsjektmål kan være: Krtest mulig utviklingstid Mest mulig frnøyde kunder Mest mulig frnøyde sluttbrukere Mest mulig gjenbruk Mest mulig gjenbrukbar kde Størst mulig frtjeneste Det er ikke alltid mulig å ppfylle all prsjektets mål i like str grad. Nen ganger vil t eller flere mål til g med kunne være mtstridende fr eksempel gd vedlikehldbarhet g str tidseffektivitet. Nen ganger vil ledelsen være i stand til å priritere, andre ganger er det umulig å få til Alt er like viktig. Fr å få effektiv prsjektledelse må følgende betingelser være ppfylt. vi må Kjenne målene til prsjektet Ha tilstrekkelige virkemidler sm vi kan bruke slik vi mener det er nødvendig Kjenne prsjektets tilstand ressursfrbruk, hva er gjrt. Vite hvrdan en endring i prsjektets parametere påvirker resultatene g målene. Hvis vi hadde visst alt dette kunne prsjektledelse vært en enkel, rasjnell prsess. Antakelig kunne den vært helt eller delvis autmatisert. Dessverre er de fire betingelsene ver bare delvis ppfylt. Mulige prblemer er at vi ikke: Kjenner alle målene eller hvrdan de egentlig er priritert

12 Har tilstrekkelig med virkemidler. Vi er begrenset av lver (interne g eksterne), vi har de flkene vi har g kan ikke få nen andre, det er bare 24 timer i døgnet, flk kan bli syke eller tatt av prsjektet fr å gjøre ne sm haster mer brannslukking. Kjenner prsjektets tilstand. Det er vanskelig å vite hvr langt har X kmmet med mdul Y når vi får svaret at han er snart ferdig eller er 90% ferdig med kdingen. Vet hva sm vil skje når vi endrer en grensebetingelse fr eksempel pålegger alle i prsjektet 2 timer vertid pr. dag. Nen vil prdusere fr t timeverk ekstra, nen vil jbbe langsmmere, nen vil bli småsyke sv. Mennesker er ikke maskiner selv m prsjektleder gjerne vil tr det. Tre viktige faktrer: Prduktvisshet Hvr klart er kravene spesifisert vet vi hva vi skal lage Hvr stabile er kravene har kunden bestemt seg fr hva han vil ha Prsessvisshet Kan vi endre prsessen. Dette er viktig fr våre muligheter til å styre / påvirke prsjektet Er det mulig å måle viktige parametere i prsessen. Dette er viktig fr å kjenne prsjektstatus. Hvr gdt frstå vi effekten av endringer i en eller flere prsessparametere. Dette er viktig fr våre muligheter til å påvirke prsessen i den retningen vi ønsker. Ressursvisshet Hvr gdt kjenne vi tilgangen på ressursene i prsjektet. Dette gjelder primært persnell, men i mindre grad gså maskinvare særlig viss prsjektet er avhengig av spesiell maskinvare. Hvrdan vi vil estimere avhenger av graden av ressursvisshet g prsessvisshet. Når denne er lav vil det være gunstig å gjøre en følsmhetsanalyse. Dette skjer sm følger: En hver estimering bygger på et sett av frutsetninger. Disse må identifiseres g dkumenteres. Eksempler er kvalifikasjnene til persnellet, antall utviklere, kundens krav til fr eksempel pålitelighet eller tilgjengelige verktøy. Hva skjer med estimatet hvis en av disse frutsetningene må frandres? De frutsetningene sm fører til stre endringer i estimatet er kritiske. De må derfr vurderes ekstra nøye g vervåkes under hele prsjektet slik at vi kan passe på at de hlder stikk eller freta nødvendig replanlegging av (deler av) prsjektet hvis de svikter. Fire viktige typer av prsjektsituasjner avhengig av de tre faktrene ver g hvrvidt de tre typene visshet er høy eller lav: Realisering Allkering Design Eksplrering Prduktvisshet Høy Høy Høy Lav Prsessvisshet Høy Høy Lav Lav Ressursvisshet Høy Lav Lav Lav Ved å kmbinere rimelige situasjner får vi fram fire prblemsituasjner med hvert sitt fkus: Realisering hvrdan ppnå måla på den mest effektive måten. Dette er et ønskeprsjekt g frekmmer dessverre sjelden. Vi kan bruke en enkel, lineær prsessmdell. Prsess g nødvendig kunnskap kan fastsettes på frhånd. Jbben kan deles pp i et sett av arbeidsppgaver sm kan styres g kntrllers. En av de frslåtte metdene fr kstnadsestimering kan brukes direkte. Allkering usikkerhet med hensyn til ressurser. Hvedprblemet er tilgjengelighet av persnell. Hvem vil jbbe på prsjektet, hvr mye vil de jbbe, når kan de gjøre det? Viktige mmenter her er å standardisere så mye sm mulig. Dette vil gjøre det lettere å bytte flk. Vi kan stadig bruke en enkel utviklingsmdell g en av de estimeringsmetdene vi har snakka m tidligere, men når vi ikke vet hvem sm skal gjøre jbben vil det være flere parametere sm er ukjente eller vil variere ver tid. Fr eksempel COCOMO kstnadsdrivere g hvrdan de avhenger av bemanningen til prsjektet. Design. Design refererer her til design av prsjektet ikke til design av prduktet / systemet. Krava er fastlagt, men vi har ikke bestem ss fr hvrdan vi vil realisere systemet lav visshet på prsess g ressurser. Viktige spørsmål er valg av milepæler, valg av dkumenter sm skal lages, valg av persnell g frdeling av ansvar. Vi trenger standardiserte løsninger, dkumenter g prsedyrer. Dermed er utput gitt g vi kan styre gjennm valg av prsess g ressurstilgang. Vi trenger generell verkapasitet siden det kan bli mye skifte av persner g dårlig tilgang i nen perider. Siden vi ikke kan regne med verkapasitet i persner, må vi prøve å få ekstra resurser i frm av mer tid timeverk g kalendertid.

13 Vi kan ikke bruke nen av de beskrevne estimeringsmdellene. I stedet må vi bruke det vi har av erfaringer g data fra tidligere, liknende prsjekter. Viktig med følsmhetsanalyse. Dette vil frtelle hva sm er kritisk g hvilke muligheter man har fr å endre prsjektet. Eksplrering lite kunnskap m krav, ressurser g prsess. Dette er en vanskelig, men slett ikke uvanlig situasjn. Innenfr enkelte markedssegmenter er dette nesten den mest vanlige måten å jbbe på. Dette gjelder fr eksempel SME i deler av internettmarkedet. Styring g prsess vil være ad hc. Den kritiske suksessfaktren er i hvr str grad deltakerne er engasjert i å få til et gdt prdukt. Prttyping g tett kbling mellm utviklere g kunder er abslutt nødvendig. Estimering vil strt sett måtte skje via ekspertvurderinger. Eksperter er flk sm har deltatt i slike prsjekter før. Viser til fig 8.2, sm ppsummer hele prblemstillingen. Risikstyring Risikanalyse g risikkntrll er viktig i all prsjektstyring. Det har vært en tendens i mange prgramvareprsjekter til å ignrere risik vi vil bekymre ss m det viss det hender er en vanlig respns. Praktisk erfaring viser imidlertid at det da fte er fr seint. Vanligvis vil en risikanalyse fregå sm følger: 1. Identifiser mulige risikfaktrer. Dette skjer via en eller annen frm fr idemyldring alt fra helt ufrmelt til det å følge en eller annen dkumentert prsess. Dersm det er mulig bør vi gså prøve å identifisere risikindikatrer altså ting vi kan bservere når risiken er på vei til å inntreffe. Dette vil gi ss en tidlig advarsel g gi ss bedre tid til å finne g iverksette tiltak. 2. Finn effekt (K fr kstnad) g sannsynlighet (p). Risiken (R) er da gitt sm R = K*p. I prinsippet kunne man tenke seg å finne tallverdier fr eksempel tapet er NOK g sannsyneligheten er 0.01 men dette er vanligvis vanskelig. Derfr pererer de fleste med en eller annen skåringsmekanisme, fr eksempel bruke H, M g L (høy, middels g lav) eller tallverdier, fr eksempel 10, 5 g 1. Tallverdiene gjør det lettere å beregne et risiktall. Dette gjør at man ikke kan finne nen absluttverdi fr hver risikfaktr, men må nøye seg med å gradere g rangere de. Dette er nk fr å lage ei priritert liste ver risiker g tiltak. 3. Fr alle viktige risiker må vi definere tiltak. Disse vil tilhøre en av følgende kategrier: Unngå innføre tiltak fr å fjerne risiken. Er det en spesiell funksjn vi trr det blir vanskelig å implementere kan vi ha et frprsjekt fr å frstå den bedre eller vi kan prøve å frhandle den brt med kunden. Er det prblemer med å bruke et spesielt verktøy kan vi gjøre en rådgiving g veiledningsavtale med en knsulent eller et firma sv. Overfør flytt risiken ut av prsjektet, fr eksempel til et frprsjekt vanlig måte å behandle ustabile krav på - eller et parallelt frskningsprsjekt. Aksepter dette er ne vi ikke kan gjøre ne med nå. Det må lages en plan fr hva vi skal gjøre hvis det inntreffer g sørge fr at en persn er ansvarlig fr å sette den i verk hvis risiken skulle gå ver til å bli et prblem. 4. Håndter risiken. Overvåk de viktige risiker g eventuelt deres indikatrer. Siden et prsjekt ikke er en statisk enhet er det viktig å gjenta prsessens trinn 1 3 med jevne mellmrm. Det kan dukke pp nye risiker, nen risiker vil kunne frsvinne eller deres sannsynlighet eller knsekvens vil frandre seg. Resultatet bør dkumenteres i en risiktabell sm minimum bør innehlde følgende infrmasjn: Aktivitet Kstnad (K) Sannsynlighet (P) Risik (R = K * P) Tiltak Ansvarlig Bruk et regneark. Da er det lett å ppdatere g srtere. Dersm det er mulig bør man gså ta med indikatrer fr hver enkelt risik. Prsjektplanlegging Prsjektet består av mange aktiviteter. Det er viktig å få versikt ver aktivitetene før vi begynner å planlegge. En måte å få versikt ver disse på er å lage en WBS Wrk Breakdwn Structure.

14 Det er viktig at alle i prsjektet er med på denne prsessen. Aktiviteter sm blir glemt må legges inn i prsjektet seinere fte med stre ekstrakstnader. Det kan være lurt å lage WBS i flere mganger etter at man har laget det øverste nivået hvedaktivitetene. Viktig input er: Den erfaringa hver enkelt deltaker har Resultater WBSer - fra tidligere prsjekter. Den utviklingsmdellen / prsessen vi har valgt T tmmelfingerregler fr å lage en WBS: Ingen arbeidspakke bør være større enn timeverk Bryt alltid ned til et nivå der du frstår hva sm skal gjøres, enten frdi det er pplagt eller frdi den sm skal gjøre jbben kjenner den igjen. I henhld til disse reglene vil et prsjekt på ett årsverk (1600 tv) bestå av 16 til 40 arbeidspakker. Når vi har identifisert alle arbeidspakkene må vi: Finne ut hvr mye ressurser (Dagsverk - Dv)vi trenger fr å lage hver enkelt pakke. Deretter må vi bestemme hvr mange persner (n) vi sette på jbben. Dette vil definere varigheten (T) på aktiviteten ved at T = Dv / n. Her må vi passe på t ting: Det er ikke alle Dv / n sm er meningsfylte. Fr eksempel vil det være urimelig å tr at vi kan få gjrt unna en 100 Dv jbb på en dag ved å sette på 100 persner. I tillegg er det en del aktiviteter sm er avhengige av en mdningsprsess. Slike aktiviteter er det vanskelig å gjennmføre på krt tid. Vi har gjrt en del frutsetninger under estimeringa m kvalifikasjnene til de sm skal gjøre jbbene. Disse frutsetningene må respekteres, eller må vi estimere m igjen. Fr hver arbeidspakke, bestemme hvilke andre arbeidspakker sm må være ferdige før vi kan starte arbeidet med denne pakka avhengigheter. Denne prsessen kan føre til at vi må endre WBS eller estimatene. Dette er en frdel, ikke et prblem: Eksempel på et tilfelle der vi må endre WBS er hvis vi finner ut at pakke B må starte etter pakke A, men ikke hele pakke A må være ferdig, bare nen deler. Da er det lurt å dele pakke A pp i t pakker A1 g A2 g si at B kan starte når pakke A1 er ferdig. Endring av estimatene kan være aktuelt i flere tilfeller. Vi vil se på t slike: Vi har en ferdig WBS g har kstnadssatt alle pakkene slik at summen blir lik det ttale estimatet. Det viser seg imidlertid at flere av pakkene ser ut sm de er svært mye underestimert. Løsningen på dette er å identifisere de underestimerte pakkene, gi de et realistisk estimat g summere på nytt. Vi har en frdelingsnøkkel, fr eksempel at design tar 40% - 10% på verrdna design g 30% på detaljert design - g kding g testing tar 30% hver. Da kan vi benytte samme strategi sm ver, men mer detaljert. Resultatet skal ppsummeres i en tabell med følgende frmat: Arbeidspakke Før-jbber Dagsverk (Dv) Antall persner (n) Varighet (T = Dv / n) Ut fra denne tabellen kan vi nå lage PERT diagram g Gantt diagram sm er de vanligste diagrammene fr å planlegge et prsjekt. Sm eksempel kan vi se på følgende tabell: Arbeidspakke Før-jbber Dagsverk (Dv) Antall persner (n) Varighet (T = Dv / n) Design Test plan Design Kde A Design Kde B Design 5 1 5

15 Testing Test plan Kde A Kde B Dette gir følgende PERT diagram., Se fig Dette gir ss en kritisk vei sm er 30 dager lang. Dette må sees sammen med den varigheten vi estimerte eller lvet kunden tidligere. Hvis kritisk vei er krtere enn den estimerte / lvede tiden er alt OK. Dersm dette ikke er tilfelle må vi prøve å fikse det ved å: Prøve å krte ned på varigheten til en eller flere aktiviteter på den kritiske veien ved å sette på flere flk. Prøve å fjerne avhengigheter sm gjør at vi kan ppnå en større grad av parallellitet i prsjektet. Dele pp aktiviteter slik at vi får redusert aktivitetene på den kritiske veien. De aktivitetene sm ligger på den kritiske veien i PERT diagrammet må vervåkes ekstra nøye. En hver frsinkelse på en av disse vil frsinke hele prsjektet. De andre aktivitetene har det vi kaller en slakk. Dette medfører at frsinkelser i disse aktivitetene ikke er kritiske siden de ikke påvirker den ttale varigheten av prsjektet. De kan imidlertid raskt bli så mye frsinka at vi må redefinere den kritiske veien g sluttidspunktet. Ut fra PERT diagrammet kan vi lage et Gantt-diagram se fig Ut fra Gantt-diagrammet kan vi lage ss en bemanningsprfil ved å summere antall planlagte dagsverk pr. dag eller måned. Denne prfilen er viktig frdi den kan hjelpe ss med å fretelle når vi: Trenger ekstra flk Kan avgi flk til andre prsjekter Fr det eksemplet vi så på i fig. 8.7 finner vi følgende bemanningsprfil. Aktivitet Design 1 1 Testplan 1 Kde A 1 1 Kde B Test Sum Vi ser at vi bare trenger en persn unntatt i dag 10 15, der vi trenger tre persner. Da er det viktig at det virkelig er tre persner tilgjengelig på det planlagte starttidspunktet altså etter 10 dager. Dersm de ikke er tilgjengelig vil det medføre frsinkelser i hele prsjektet en dag fr hver dag de ikke er tilgjengelig. Nen trr at det går an å ta igjen dette, men erfaring viser at det skjer bare i nen få tilfeller. WBSen, PERT diagrammet g Gantt-diagrammet bør ppdateres med jamne mellmrm. Det er derfr viktig med verktøystøtte i disse aktivitetene. Diagrammene gir ss en gd mulighet til å følge pp prsjektet. Dette kan skje på flere måter: Når nen aktiviteter er ferdige kan vi sammenlikne medgåtte resurser mt estimerte ressurser. Dersm det er en systematisk frskjell bør vi vurdere å justere resten av estimatene gså. Denne justeringa vil gi en gd pekepinn på hvrdan vi ligger an i frhld til planen. Vi kan la det estimerte ressursfrbruket fr hver pakke representere verdien av pakka. Dette er rimelig viss vi har slgt prsjektet fr den estimerte verdien. Hvis vi er ferdige med arbeidspakker sm representerer X % av estimatet vil det være rimelig å si at prsjektet er X % ferdig. Hvis det er aktiviteter på kritske vei sm ikke er ferdige når de skulle være det, bør man vurdere å flytte flk fra ikke-kritiske til kritiske aktiviteter. Pass på at de virkelig kan gjøre nytte fr seg i denne aktiviteten ellers går det bare fra galt til verre. Trenger de fr eksempel pplæring? Fwler kapittel 2 UML er et mdelleringsspråk, ikke en utviklingsmetde. RUP Ratinal Unified Prcess er en metde sm er spesielt utviklet fr å gå sammen med UML. Man kan imidlertid bruke UML uansett hva slags prsess g utviklingsmetde man velger. Fwler har definert en liten, enkel, iterativ prsess sm passer gdt fr mange små g middels stre prsjekter. Grvt sett består denne prsessen av følgende:

16 Inceptin finner ut m det freslåtte prsjektet er nyttig g mulig å realisere innenfr rimelig tid g ressursfrbruk Elabratin samle inn krav g lage en verrdnet analyse g design Knstruksjn en serie av iterasjner fr å realisere systemet Transisjn vi slipper ut første versjn betaversjnen Vi vil se på hver av disse fasene i mer detalj. Inceptin Det er mange måter å gjennmføre dette på, måten avhenger av hvem kundene er g hvr strt prsjektet er. Viktige ting å få på plass på et verrdnet nivå er: Hva skal vi lage Hvem skal ha det Hva skal det kste Trr vi at vi kan få det til Hvis det ser ut til at det er la-seg-gjørlig så går vi ver til neste fase, ellers er det bare å glemme hele greia. Elabratin Dette er primært en risikdrevet fase. Vi trenger versikt ver de risiki sm ligger i prsjektet. Det kan være praktisk å perere med fire risikkategrier: Kravrisiki analysen av kravrisiki begynner med use-case. Teknlgiske risiki Ferdighetsrisiki Plitiske risiki Kravrisik hva er krava til systemet, bygger vi det riktige systemet Teknlgisk risik har vi den riktige teknlgien fr denne jbben Kunnskapsrisik har vi den kunnskapen vi trenger tilgjengelig fr dette prsjektet Plitisk risik finnes det plitiske (her i betydningen intern bedriftsplitikk) krefter sm kan kmme i veien fr prsjektet. Vurdering g handtering av disse risiki kan gjøres slik vi har snakket m før. Kategriene g det vi sier m de her, kan brukes sm ei sjekkliste fr å øke sannsynligheten fr at vi har fått med ss alle de viktige risikfaktrene. Vi skal se litt på hver av disse kategriene. Kravrisik Før vi kan se på kravrisik må vi raskt definere et use case. Et use case er en funksjn sm brukeren trenger, sm har verdi fr han g sm er beskrevet på en måte sm han frestår. Use case er i UML den viktigste måten å kmmunisere med kundene på. På dette tidspunktet behøver ikke use casene å være detaljert nen avsnitt med tekst er nk. Det frteller hva funksjnen skal hete g hva kunden ønsker å ppnå med funksjnen. I tillegg til et sett av - de viktigste use case, trenger vi en knseptuel mdell av dmenet (fagmrådet). En av ppgavene til denne mdellen er å beskrive g definere hvrdan dette fagmrådet bruker en del viktige termer. Dette er viktig fr å frstå den verden systemet skal fungere i. Tre teknikker er viktige. Vi skal se på de i mer detalj senere. Klassediagram, tegnet fra et knseptuelt perspektiv. Aktivitetsdiagram, fr å identifisere hva sm skal gjøres. Interaksjnsdiagram, fr å identifisere hva sm skal gjøres. Fr alle disse diagrammene gjelder at man på dette stadiet i prsjektet kan g bør være svært ufrmell. I tillegg til diagrammene g den tilhørende ntasjnen kan det være lurt å ha en del frklarende, ufrmell ntasjn. Hvedpenget er å få versikt ver dmenet, ikke å lage en krrekt, rigrøs mdell. Mdellen skal være et skjellet, ikke en verrdna mdell. En verrdna mdell er en høynivå beskrivelse av systemet g innehlder derfr ingen detaljer. Et skjellett kan gdt innehlde detaljer, men bare de vi synes er viktige fr øyeblikket.

17 Fr å få til en brukbar dmenemdell er det viktig å lage mdellen sammen med kunden. Dette er nk en viktig grunn til å hlde ntasjnen enkel g ufrmell. Klassediagram Klassediagrammer beskriver typer av bjekter i systemet g de statiske relasjnene sm kan være mellm de. Det finnes t typer av relasjner: Asssiasjner, fr eksempel en kunde leier en vide Subtyper, fr eksempel und-ass er en subtype av student. Vis fig. 4-1 fra Fwler. Nen kmmentarer på en del egenskaper, i det minste generalisering, klassebetegnelse med navn, attributter g perasjner g relasjner g multiplisitet. Aktivitetsdiagram Aktivitetsdiagrammer består ikke uventa av et sett av aktiviteter g hvrdan de er kbla sammen. Aktivitetsdiagrammer kan i nen tilfeller være et gdt alternativ til interaksjnsdiagrammer. Hver aktivitet er enten en prsess nen gjør ne - eller en eksekvering av et prgram. Diagrammet viser sekvenseringen av aktivitetene. Vis fig. 9-1 fra Fwler. Kmmenter sentrale begreper sm Frk, Branch g Jin. Aktivitetsdiagrammer blir ikke behandla i kurset ut ver dette. Interaksjnsdiagram Av samarbeidsdiagrammer er det interaksjnsdiagrammer sm blir priritert i dette kurset. Disse diagrammene viser hvrdan klassene arbeider sammen g utveksler meldinger. Klassediagrammer g interaksjnsdiagrammer blir utvikla i en iterativ prsess. Vis fig 5-1 i Fwler. Kmmenter sentrale begreper sm Objekt, Message g Creatin. Mer m kravrisik - 1 Kmbinasjnen av dmenemdell g use case gir en gd kmbinasjn fr å frstå kravrisiken i prsjektet. Husk at frmålet er å frstå risik g gjøre ne med den, ikke å lage et systemdesign. Dette impliserer at vi bruker mye ufrmell ntasjn g ekstra kmmentarer i tillegg til de diagrammene vi har nevnt tidligere. Når vi har en gd dmenefrståelse kan vi ta en runde til på use casene g til slutt ta en freløpig siste runde på dmenemdellen. I dette arbeidet må vi inkludere en eller t dmeneeksperter. Dersm dmenemdellen er str kan vi prøve å dele den pp i pakker g gjerne begynne å se på tilstandsdiagrammene til klasser sm har særlig interessant eller vanskelig ppførsel. Pakker Et pakkediagram er et klassediagram sm viser bare pakker av klasser g avhengigheter mellm de. Vi har en avhengighet mellm t klasser viss endringer i definisjnen i den ene medfører endringer i den andre. Avhengighetene kan være at den ene sender en melding til den andre, en klasse bruker deler av en annen klasse sm parametere i en perasjn eller ved at den ene bruker den andres grensesnitt. Vis fig 7-1 i Fwler. Vi har avhengigheter mellm pakker viss vi har avhengigheter mellm en klasse i den ene pakka g en klasse i den andre. Tilstandsdiagrammer Et tilstandsdiagram viser alle tilstandene til et bjekt g hvrdan tilstanden til bjektet endrer seg sm resultat av hendelser. Tilstandsdiagrammet berører altså bjekter instansinerte klasser g ikke de definerte klassene. Vis fig 8-1 fra Fwler g kmmenter. Overgangene er merket med Hendelse [Betingelse] / Handling. Handling er det samme sm en tilstandsendring transisjn. Mer m kravrisik 2 Pass hele tiden på at vi lager et skjellett, ikke en verrdna høyere rdens mdell. Viss vi prøver å ta med alle detaljer ver alt på dette tidspunktet vil det ta alt fr lang tid g vi kan lett glemme hensikten, nemlig å få en versikt ver kravrisiken. Vi må passe på å hele tiden jbbe videre med use casene fr å se m de intrduserer elementer sm gjør at vi må endre nen av de andre diagrammene i skjellettet.

18 Viss vi føler ss usikre på hvrdan vi skal realisere en del av dmenemdellen, er det lurt å lage en prttyp. Ikke lag prttyper av alt, men bruk dmenemdellen til å ppdage ting sm dere føler dere usikre på. Den kritiske delen av arbeidet med kravrisik g dmenemdellen, er tilgang på dmeneekspertise. Vanligvis betyr dette tilgang på eksperter / brukere fra kunden. Vi må altså jbbe tett sammen med kunden i denne periden. Teknlgisk risik Det viktigste vi kan gjøre her er å lage en eller flere prttyper fr å prøve ut den teknlgien vi skal bruke senere i prsjektet. Eksempler på slik teknlgi kan være databaser, kmmunikasjnspakker g brukergrensesnittpakker. Den største risiken er ikke hvrdan hver pakke fungerer eller er designet, men hvrdan pakkene passer sammen med hverandre g med det du skal lage selv. Dette må derfr prøves ut så tidlig sm mulig. Vi må gså vurdere arkitekturbeslutningene på dette trinnet. Dette er særlig viktig viss vi skal lage et distribuert system. Det er viktig å se på de beslutningene sm det er vanskelige å gjøre m seinere. Tre viktige spørsmål: Hva vil skje viss en del av teknlgien ikke fungerer Hva må vi gjøre viss t dele av teknlgien ikke fungerer sammen Hvr sannsynlig er det at ne går galt her g hva kan vi gjøre viss det inntreffer. I denne prsessen er det igjen viktig å se på use case, klassediagrammene g pakkediagrammene fr å se m det er ne du har versett. Kunnskapsrisik At vi mangler ekspertise er en vanlig grunn til at prsjekter går galt. Vanligvis er årsaken at man ikke vil bruke penger på kurs rett g slett frdi det kster penger. På den andre siden ser det ikke ut til at de bryr seg m at verskridelsene vanligvis kster langt mer. Kursing av prsjektdeltakerne g av ansatte generelt er en gd investering. Prblemet er imidlertid fte at mange prsjektrienterte bedrifter mangler et investeringsbegrep g investeringspplegg. Det beste er å ha et pplegg med krte, målretta kurs etterfulgt av eget arbeid med hjelp av en mentr. I begynnelsen vil mentren være en del av prsjektet fr så seinere å trekke seg tilbake g fungere sm rakel g rådgiver. Viss man ikke kan skaffe en mentr så pass på å hld hyppige gjennmganger av det sm blir gjrt slik at man kan gi hverandre råd, diskutere prblemer g lære av hverandres tabber g suksesser. Vær på utkikk etter mråder i prsjektet der du mangler kunnskap selv. Dette er mråder der vi trenger kurs, en eller flere mentrer eller å leie inn en erfaren knsulent. Plitisk risik Dette angår risik sm ppstår internt i bedriften g i frhldet mellm bedriften g kundene. De mest vanlige knfliktene g dermed risikfaktrer er: Allkering av persnell. Vi har blitt lvet fire persner, men får bare tre, eller vi får persner med lavere eller annen kmpetanse enn den vi hadde regnet med. Tilgang til persnell. Vi må avgi flk før vi hadde tenkt pga. at et annet prsjekt blir priritert høyere av ledelsen eller frdi det brenner i et annet prsjekt eller frdi en viktig kunde har rapprtert en feil. Andre risiki sm hører til her er at vi blir lvet kurs sm så blir kutta pga. kstnader eller viss vi skal lage prdukter til et generelt marked bedriften bytter markedsstrategi. Endring i pririteter pga. at vi blir ppkjøpt er gså ne sm har blitt vanlig gså i nrsk industri. Dette er prblemer sm må løses av ledelsen, ikke av de sm jbber i prsjektene. Det kan imidlertid være lurt å vurdere de g bestemme seg fr hva man skal gjøre på et tidlig tidspunkt. Det kan være nyttig å infrmere ledelsen på et tidlig tidspunkt m at disse risiki finnes g hva sm kan bli knsekvensen viss de inntreffer. Når er Elabratin ferdig Tmmelfingerregel: Denne fasen tar ca. en femtedel av det ttale prsjektet. Det finnes t indikatrer sm sier at vi er ferdige:

19 Utviklerne synes det er OK å prøve å estimere hvert use case kstnader g kalendertid til nærmeste ukeverk. Alle signifikante risiki har blitt identifisert g vurdert så gdt at du føler at du kan handtere de uten å se stre prblemer. Knstruksjnsfasen Planlegging Knstruksjnsfasen består ev en serie av iterasjner. Det kan være lurt å lage mange små use case g realisere et use case pr. iterasjn. Igjen må vi passe på å invlvere kundene. Begynn med å kategrisere use casene. Dette gjøres sm følger: 1. Kunden deler pp use casene i henhld til deres verdi fr bedriften bruk kategriene høy, middels g lav 2. Utviklerne deler pp de samme use casene i henhld til risik samme kategriene. 3. Utviklerne estimerer hvert use case kstnad g ledetid. Dette er nett tid full tid på prduktivt arbeid. Etter sm vi får erfaring f.eks. etter første iterasjn må vi justere fr verhead. 4. Bestem hvr lang du vil ha hver iterasjn dette må være nk til å gjennmføre 3 6 use caser. Uansett bør en iterasjn ikke være mye lenger enn en til halvannen måned. 5. Bestem prsjektets hastighet. Dette gjøres på følgende måte: N = antall utviklere L = lengde på en iterasjn se punkt 4. F = last faktr se punkt 3. Viss vi f.eks. bruker fire ukeverk på å få gjrt det sm er estimert til å ta tre ukeverk er lad faktren 4/3 = 1.3 Dette gir hastigheten V = N * L / F. Viss vi har fem utviklere g t ukers iterasjner med en lastfaktr på 1.3 finner vi V = 5 * 2 / 1.3 = 7.7, sm er innsats pr. iterasjn. 6. Når vi har prsjekthastigheten V kan vi finne antall iterasjner IT sm følger: IT = 1 + Sum(Ukeverk pr. use case) / V. Viss vi har funnet at vi ttalt trenger 77 ukeverk fr å realisere alle use casene finner vi IT = / 7.7 = 11 iterasjner. Ut fra kundens g utviklernes vurderinger kan vi nå lage følgende tabell ver use casene Utviklernes vurdering av risik H M L Kundens vurdering av verdi fr kunden H M L De use casene sm havner i høy risik g / eller str verdi må taes tidlig i prsjektet. Sett av tid fr integrasjn g levering av betaversjn. Sett av 10% viss du har gjrt det (mange ganger) før g 35% viss dette er nytt fr deg. Til slutt bør du legge til 10 20% sm reserveressurser. Lag en releaseplan når kan vi demnstrere hvert inkrement g hvilke use case vil det innehlde. Knstruksjn Hver iterasjn kan sees sm et miniprsjekt med analyse, design g kding etterfulgt av testing g integrasjn. Når iterasjnen er realisert kan du demnstrere det nye systemet fr kunden. Iterasjnene er både inkrementelle g iterative. Inkrementell frdi den legger til ne ny funksjnalitet hver gang. Iterativ frdi vi hver gang må skrive m ne av den kden vi allerede har fr å tilpasse nye inkrementer. Tre aktiviteter sm må gå kntinuerlig: Refaktring. Når vi jbber med inkrementer må vi vanligvis endre ne kde fr hvert inkrement vi legger til. Refaktring er endringer sm ikke påvirker funksjnaliteten, men i stedet rydder pp i kden, fte ved å endre klasser, gjøre enkel redesign sv. Det finns nen regler de tre viktigste kmmer her: 1. Ikke gjør refaktring g implementasjn samtidig eller m hverandre. Ha er klart skille mellm disse t aktivitetene

20 2. Pass på å ha et kmplett sett tester før du begynner refaktring slik at du kan validere at det sm var OK før stadig er OK. 3. Ta krte steg sm bare innehlder nen få endringer i kden. Test etter hvert steg. Integrering. Integrer ny kde så snart den er tilgjengelig. Kjør alle tester etter hver integrasjn. Testing. Lag tester kntinuerlig slik at du til en hver tid kan teste det du har implementert pluss all tidligere funksjnalitet. Lag et pplegg fr autmatisk testing slik at du slipper å sjekke alt fr hånd. Knstruksjn begynner med design. Første skritt i design er å gå gjennm alle klassene sm er beskrevet tidligere g se hvrdan de bidrar til å realisere den funksjnaliteten sm er beskrevet i use casene. Fwler anbefaler CRC krt. Vis fig 5-6 i Fwler g frklar. Ut fra CRC krta finner vi ansvar g perasjner sm skal inkluderes i et eller flere klassediagram. Diskuter klassediagrammene videre utarbeidet fra de skjelettene vi laget tidligere med klleger. Nå er vi klare til å kde. Kding g etterfølgende testing vil vanligvis føre til endringer i design. Lag ikke kmplett designdkumentasjn i det minste ikke nå. De vil sikkert bli endra seinere. Bruk heller Javadc eller likende fr eksempel BlueJ - til å generere designdkumentasjn ut fra den kden sm finnes. Da blir det enkelt å ppdatere dkumentasjnen g den vil alltid være riktig - så lenge vi ikke får feil i Javadc. Pakkediagrammene viser hvrdan systemet er satt sammen g hvilke lgiske deler det har. Dette diagrammet er vanligvis mer stabilt enn de mer detaljerte klassediagrammene. I tillegg vil det være praktisk / nyttig å ppdatere de viktigste, mest kmpliserte tilstandsdiagrammene. I slike tilfeller bør man gså vurdere m man trenger aktivitetsdiagrammene. Transisjn I denne fasen skal det ikke legges til funksjnalitet, unntatt viss endingene er små g abslutt nødvendige. I tillegg må vi rette feil. Det kan være aktuelt å gjøre ptimalisering viss systemet er fr tregt så tregt at det irriterer kunden. Husk at ptimalisering både fr tid g plassfrbruk har en tendens til å gjøre kden vanskeligere å frstå, g dermed å endre(fr eksempel fr å rette feil eller legge til ny funksjnalitet senere) Kapittel 13 På et verrdnet nivå finnes det bare t typer testing: Testing fr å se m vi har feil i kden, fr å hjelpe til med å finne de g sørge fr at feilene blir rettet. Dette er den testingen sm bedriften gjør under utvikling. Hele pplegget er internt g under bedriftens kntrll. Testing fr å bygge tillit til at prduktet gjør jbben sin eller tilfredsstiller kundens krav. Ofte vil kunden si at Vi gdkjenner systemet når følgende tester er kjørt uten feil. Det finnes mange måter å test på. Alle har sm frmål å gi et best mulig utbytte av testingen. Nen interessante varianter er: Dekningsbasert testing. Det finnes mange måter å definere dekningsgraden på, fr eksempel kdedekningsgrad alle kdesetninger er kjørt minst en gang. stidekningsgrad alle mulige veier er kjørt minst en gang. Stidekning g kdedekning er ikke det samme. Vis g kmmenter fig Linje 7 har en if-setning. Hva skjer hvis betingelsen ikke er sann? løkkedekning fr eksempel alle løkker skal kjøres null, en g N ganger definisjn bruk dekningsgrad alle par av tilrdninger g bruk av en variable skal utføres. kravdekningsgrad alle krav skal dekkes. Hva vi må gjøre avhenger av hvr detaljerte vi er med hensyn på hvert krav. Feilbasert testing. Vi setter inn en del feil i kden i tillegg til de sm allerede er der. Vi sier at kden er gdt nk testet når vi har funnet en gitt andel fr eksempel 99% - av alle innsatte feil. Prblembasert testing. Vi bruker den kunnskapen vi har m hva sm er vanskelig dvs. fte feiler g setter inn mesteparten av innsatsen der. Risikbasert testing. Vi ser på hva sm medfører de alvrligste knsekvensene fr kunden hvis det feiler g tester mest der. Dette vil fr eksempel bli gjrt fr sikkerhetskritiske systemer. Det kriteriet vi velger vil bestemme når vi er ferdige med å teste. Vi behøver ikke å kreve 100% dekning. I mange tilfeller vil det ikke engang være realistisk. Dette gjelder bla. fr stidekning siden antall mulige veier gjennm et prgram frt blir strt.

21 Det er gså vanlig å dele pp testing i t strategier: Black bx testing. All testing input g utput tar utgangspunkt i kravene til systemet, mdulen eller pakka. White bx testing. All testing tar utgangspunkt i strukturen til kden. Dette passer gdt fr de fleste dekningsgradsmål. Testing sammenfattes fte under tittelen V&V Verifisering g Validering. Disse t begrepene dekker t viktige sider: Validering har vi laget det systemet vi skulle lage, dvs. riktig funksjnalitet Verifisering har vi laget systemet på en riktig måte, dvs. har vi tilfredsstilt krav til pålitelighet, vedlikehldbarhet sv i tillegg til kundekrav. I tillegg vil vi vite m vi har brukt den prsessen vi skulle har vi fr eksempel gjrt gransking av alle mduler? Det er ikke uten videre enkelt å definere hva en feil er. Tegn diagrammet med mulig input g hva slags input sm aktiverer feil g hvilken sm ikke gjør det. Si ne m kblingen mellm brukerprfil bruksmåte g hvr feil ligger i systemet. Vis g kmmenter fig 13.2 Si ne m prblemene med å finne et autmatisk rakel. Dette medfører at vi nesten alltid må ha et menneske sm rakel. Partisjnstesting Partisjnstesting går ut på å dele pp inputrmmet i ekvivalensklasser, der data i hver klasse vil aktivere samme del av kden. Enkle eksempler: IF (a > 5) P1( ) ELSE P2( ) deler inputrmmet i t deler. Fr å teste dette trenger vi minst å ha a større enn 5 g a mindre eller lik 5. IF (a > 5) { IF (b < a) P1( ).ELSE.} deler inputrmmet i tre deler. Fr å teste denne biten trenger vi å ha a større enn 5 g a mindre eller lik 5 g b mindre enn a g b større eller lik a. Simulering har vist at ved å velge et strt antall tilfeldige inputverdier vil man vanligvis få et like gdt resultat sm ved partisjnstesting. Når strukturen til inputrmmet blir kmpleks vil vi uansett ikke kunne lage et ryddig sett med partisjner g generering av tilfeldige verdier vil være et gdt alternativ. Testing g utvikling Det er fr seint å begynne å teste fr å finne g rette feil når systemet er ferdig. I den grad det er mulig må testing fregå under alle aktiviteter i et utviklingsprsjekt. Vi vil krt se på nen av aktivitetene g hva vi skal gjøre der: Krav finnes fte bare sm naturlig språk eller i en eller annen ufrmell ntasjn fr eksempel use case. Det er fire ting sm er viktige med krav til et prgramvaresystem. Det skal være: Kmplett alle elementer av kravet skal være på plass Knsistent ingen av kravene skal stride mt nen av de andre Gjørlig kravene skal kunne realiseres med kjent teknlgi. I tillegg mener nen av det i dette gså ligger at kravene gir et system sm er kstnadseffektivt det kster mindre å lage systemet enn det man sparer ved å ta det i bruk. Testbare vi skal kunne teste m kravet er ppfylt. Fr å teste krav er det ingen annen teknikk sm kan brukes enn en eller annen leseteknikk dkumentgranskning, inspeksjn eller liknende. Design. De samme kravene sm vi hadde til kravspesifikasjn er gså viktige her. I tillegg er det viktig å ha sprbarhet. Dette impliserer at det må være mulig å se hvr hvert enkelt krav er realisert. Teknikkene fr å teste er vanligvis de samme inspeksjn g granskning. I tillegg vil det være mulig å implementere deler av systemet i det minste klasseskjelletter g tmme prsedyrer. Implementering. Det er her vi gjør rdentlig testing siden det er her vi har kde vi kan eksekvere. Sprbarhet er stadig viktig g gjelder begge veier: Fra krav til test denne testen er her fr å teste følgende krav Fra test til krav dette kravet blir testet av følgende test

22 Bare på den måten kan vi være sikker på at vi ikke har mistet krav underveis i prsessen fram til nå. Vedlikehld. En str del av utgiftene med å ha et prgramvaresystem kmmer etter at systemet er ferdig kanskje så mye sm 2/3. Dette er vedlikehld, sm har t årsaker: Feil ca. 30% Endringer ca 70% - frdi kundens behv eller mverdenen har endra seg. Når vi gjør en endring uansett årsak er det tre ting det er viktig å teste: Har vi ppnådd den effekten vi ønsket Fungerer alt annet sm før Er kden stadig like lett å frstå g å finne fram i. Manuelle testteknikker Den mest brukte manuelle testteknikken er å lese dkumenter krav, design, kde g tester. Det mest effektive er å få t tre andre persner til å gå systematisk gjennm det du har skrevet, men hvis det er vanskelig så vil det gså hjelpe m du får en kllega til å se på det eller bare leser gjennm det selv etter å ha latt det ligge urørt en dag eller t. Vi vil se krt på nen teknikker: Walkthrugh. Dette begrepet brukes på t måter: Frmell teknikk fr å gå gjennm kde, ved å håndeksekvere den ved hjelp av enkle testdata. Hensikten er ikke å teste kden, men å bruke testdata til å frstå hvrdan kden fungerer g bruke det sm utgangspunktet fr en diskusjn m kdekvaliteten. Det er denne betydningen sm står i lærebka. Ufrmell teknikk fr å presentere et løsningsfrslag / knsept fr andre utviklere fr å samle ideer til å frbedre løsningen. I denne frmen brukes teknikken før man har skrevet ferdig kden, men etter at man har kmmet fram til hvrdan man vil løse prblemet.. Det er denne betydningen sm blir mest bruk, i det minste i Eurpa. Jeg vil anbefale at dere hlder dere til denne måten å gjøre en walkthrugh på. Inspeksjn. En frmell prsess fr å gdkjenne et dkument. Den kan brukes på alle typer dkumenter selv m den nk blir brukt mest på kde. Det er imidlertid viktig å gså inspisere kravdkumenter, designdkumenter, testplaner sv. En gruppe av vanligvis fire persner går gjennm dkumentet g ser etter inknsistenser g feil. Fagan-inspeksjn slik den er presentert her legger lite vekt på frberedelsene, mens andre mener at dette er den viktigste aktiviteten. Andre ting sm varierer fra bedrift til bedrift er hvrvidt frfatteren skal være til stede. T. Gilb, sm gså har arbeidet mye med inspeksjner, har et pplegg det man alltid har et walkthrugh tidlig i utviklingsprsessen. Nyere frskning synes å vise at de fleste feil finnes under de individuelle frberedelsene g at nytten av selve møtet er marginal. Jeg mener dere bør bruke følgende pplegg: 1. Skisser en relativt detaljert løsning. Det må være ne mer knkret g frpliktende enn bare nen løse tanker. 2. Når dette er ferdig så bør det presenteres fr ei gruppe av medarbeidere minst tre fire stykker. Hensikten er å ppnå knsensus dette er en frnuftig måte å løse prblemet på g å få innspill ut fra de erfaringene de andre har. Hva man får avhenger av hvem man trekker inn i prsessen. 3. Ta med den infrmasjnen du samlet under det fregående møtet g gjør ferdig dkumentet. 4. Lever dkumentet til den sm er ansvarlig fr inspeksjner. Han vil gjøre følgende: Går gjennm dkumentet fr å se m det har en reell sjanse fr å bli gdkjent eventuelt med nen endringer. Hvis han ikke trr det så må han levere dkumentet tilbake til frfatteren med beskjed m å frbedre det. Sette sammen et inspeksjnsteam. Deltakerne velges ut fra applikasjnskunnskap g kunnskap m prsess g metde sm er brukt i det aktuelle prsjektet. Alle deltakerne fr utlevert dkumentet g bakgrunnsmateriale sm fr eksempel kravspesifikasjn hvilket prblem skal vi løse, hvem er kunden, hva er kundens krav, relevante standarder Deltakerne får en viss tid på å gå gjennm dkumentet g lage ei liste ver ting de mener er feil, ting sm kan være feil g ting de ikke frstår. Etter at frberedelsestida er ver vil lederen fr inspeksjnen kalle inn til et møte der man går gjennm hver enkelt persns prblemlgg g lager en felleslgg fr inspeksjnen. I nen tilfeller vil fellesgjennmgangen føre til at man ppdager nye prblemer, men dette er dessverre sjelden. Etter at man er ferdige med lggen må man bli enige m hvrvidt man vil Gdkjenne dkumentet sm det er ne sm skjer svært sjelden

23 Gdkjenne dkumentet med endringer. Dette er OK hvis vi trr at det er en liten jbb å rette pp prblemene fr eksempel en til t dagsverk Større endringer ny inspeksjn etter at alle endringene er utført. Dette kan gså bli resultatet hvis det er stre mengder småfeil. Frkastet dette dkumentet er hinsides hjelp. Behld erfaringene g start prsessen på nytt. 5. Når endringene er utført i henhld til den beskjeden man har fått fra inspeksjnen er dkumentet gdkjent g vi kan gå videre i prsessen. Dette pplegget er altså frskjellig fra det sm står i lærebka. Dere finner et sett med filer til denne måten å gjøre det på i dagens innslag i frelesningsplanen på fagets hjemmeside. Scenaribasert evaluering. Dette er en manuell testing fte kalt desk checking av kde ut fra et use case eller et scenari situasjnsbeskrivelse. Bka beskriver SAAM Sftware Arkitektur Analyse Metde - prsessen sm er tilpasset arkitekturevaluering. Metden kan gså brukes i vanlig testing. Siden arkitekturen i str grad vil bestemme hva vi kan g ikke kan gjøre seinere er det viktig å gjøre en gd jbb her. I tillegg til selve evalueringa har metden gså andre frdeler, fr eksempel den å tjene sm et utgangspunkt fr diskusjner m hva systemet skal gjøre. Dermed vil det tjene til å lage frståelse g knsensus i prsjektet g mellm prsjektet g kunden. Selve SAAM prsessen er sm følger: 1. lag scenarier. Disse kan innehlde scenarier både fra kravspesifikasjnen g fra situasjner sm vi trr vil kunne dukke pp senere. 2. beskriv de arkitekturene vi vil evaluere. 3. klassifiser scenariene i relasjn til hver av arkitekturene sm direkte (fullt støttet) g indirekte (delvis støttet) 4. beskriv alle nødvendige endringer i arkitekturen sm er nødvendige fr å støtte de indirekte scenariene. 5. vurder interaksjnene mellm de indirekte scenariene. Hvis flere indirekte scenarier krever endringer i samme kmpnent kan dette være en indikasjn på at vi har frdelt funksjnaliteten på en uheldig måte i arkitekturdesignet. 6. ppsummering. Gi en vekt til hvert scenari etter hvr viktig det er. På den måten kan vi finne den arkitekturen sm støtter de fleste g viktigste scenariene.. Dekningsbaserte testteknikker Dette er en enkel g viktig måten å vurdere tester på. Vi vil se på nen varianter: Kntrllflytbasert dekning. Kravet går ut på at man skal teste alle veier gjennm prgrammet. Tatt bkstavelig er dette kravet vanskelig å ppfylle hvis vi har løkker. Det er derfr definert t varianter av dette kriteriet sm er ne enklere å frhlde seg til: Setningsdekning. Alle prgramsetninger blir utført minst en gang Stidekning. Alle stier blir gjennmført minst en gang. Utvidet stidekning. Alle mulige kmbinasjner av predikater blir eksekvert. Hvis vi fr eksempel har betingelsen (a > b && x = 10) må vi ha fire datasett siden vi har t relasjner sm da kan være henhldsvis FF (a < b, x =7), FT ( a < b, x= 10), TF (a > b, x = 7) g TT (a > b, x = 10). Vis fig g diskuter nen tilfeller. Vi kan ppnå full setningsdekning ved følgende parametervalg: n = 2, a[1] = 5, a[2] = 3. Det gjør imidlertid ikke nen frskjell fr resultatet m betingelsen på linje 9 endres fra > til =. Vi får heller ikke eksekvert THEN grena i linje 6 eller den implisitte ELSE greina i linje 9. Hvis vi legger til datasettet n = 2, a[1] = 3, a[2] = 5, får vi gså eksekvert THEN greina i linje 6. Dataflytbasert dekning. Ser her på dekning av alle par av tilrdninger bruk fr alle definerte variable. Det er vanlig å skille mellm t typer bruk P-bruk når den variable brukes i et predikat så sm j > 5 g C bruk sm er all annen bruk. Et annet sentralt begrep i dataflytbasert testing er at en sti kan være definitin clear med hensyn til en gitt variable. Dette betyr at den variable ikke endrer verdi når vi beveger ss langs denne stien. Vi skiller mellm t strategier: All Bruk dekning. Dette kravet går ut på å lage testdata slik at vi får gjennmløpt alle definitin clear tilrdninger bruk stier pluss den setningen sm kmmer etter bruken. Det siste er nødvendig fr at vi skal være sikre på å få med begge grenene i en IF-setning.

24 Alle DU stier (Define Use). Dette er det samme sm All bruk kravet, men har sm en tilleggsbetingelse av alle definitin clear stier er uten repeterbare løkker (FOR- eller WHILEløkker). I tillegg finnes det mange varianter av dette. Se i lærebka side 452. Kravspesifikasjnsbasert dekning. Her mfrmer vi systemkravene til en rettet graf. Tekstlige use case g UML aktivitetsdiagrammer er et gdt utgangspunkt fr slike grafer. Vi kan definere dekningsgradsmål på slik grafer sm på alle andre grafer fr eksempel alle mulige stier. Feilbasert testing Frmålet med feilbasert testing er å teste slik at vi har et mål fr hvr gdt testen dekker systemet hvr str sannsyneligheten er fr at vi har funnet all eller de fleste feil når testingen er ferdig. Vi vil se på et utvalg av teknikker: Feilsåing går ut på å legge inn et sett av feil i systemet g deretter teste systemet. Kvaliteten på metden avhenger av m vi setter inn realistiske feil eller ikke. La ss anta at vi har N1 feil i systemet g legger inn N2 nye feil. Tegn figur på tavla. Vi kjører et sett av tester g finner n1 feil vi ikke har lagt inn g n2 av de feilene vi har lagt inn. Under frutsetning av at alle feilene både de virkelige g de sm er lagt inn etterpå er like lette å finne kam vi nå sette at n1/n1 = n2/n2 g dermed N1 = N2*n1/n2. I stedet fr å lage nye feil kan vi utnytte de feila vi finner i systemet. La t grupper teste prgramvaren uavhengig av hverandre, men slik at gruppe 1 tester først g gruppe 2 etterpå. Tegn pp den vedlagte skissa. Feilene blir ikke fjerna før gruppe 2 er ferdige med å teste. La n1 g n2 være antall feil funnet av henhldsvis gruppe 1 g gruppe 2. Antall feil sm frekmmer hs både gruppe 1 g gruppe 2 vil bli betegna med c. Da gjelder n1/n1 = c/n2 g dermed N1 = n1*n2/c. Alternativt kan vi bruke metden med feilsåing, men sette inn feil sm tidligere er fjerna fra systemet under annen testing, fr eksempel enhetstesting. Uansett valg av metde vil det være slik at vi kan ha tillit til testingen hvis vi finner alle eller de fleste av de feilene sm er sådd, g få andre. Mutasjnstesting. Denne testfrmen har mye tilfelles med feilsåing, men bygger på t hypteser: 1. Hyptesen m kmpetente utviklere sier at den prgramvaren sm blir utvikla er svært nær den riktige. Avvik fra prgramvaren vil derfr være feil. 2. Hyptesen m kbling mellm feiltyper sier at de tester sm finner små feil gså finner stre her i betydningen alvrlige feil. Mutasjnstesting fregår derfr ved at vi lager små variasjner av den kden vi har utviklet. Disse nye versjnene av kden innehlder feil (hyptese 1) g kalles mutanter. Hvis en test avdekker denne feilen er mutanten fjernet død. Vi må altså frtsette å lage nye tester helt til vi har funnet mutanten. Nen egenskaper ved testkriterier Det stre spørsmålet fr testing er: Når har vi testet nk. Bka lister pp 11 kriterier av varierende nytte g interesse. Vi har valgt ut nen av kriteriene sm vi finner nyttige: T prgrammer sm er semantisk like gjør samme jbben kan ikke nødvendigvis testes like gdt med samme datasett. T prgrammer sm er syntaktisk nær hverandre samme struktur g dataflyt kan ikke nødvendigvis testes like gdt av samme datasett. Det at et prgram er testet tilstrekkelig fr en brukergruppe eller et bruksmråde betyr ikke at det er testet tilstrekkelig fr et annet brukesmråde. Det at kmpnenter er testet hver fr seg g funnet feilfrie er ingen garanti fr at de fungerer sammen Minstekravet fr et sett av testprgrammer er alle setninger i prgrammet blir eksekvert minst en gang. Det sm er gjrt av eksperimenter synes å vise at det ikke finnes en beste testmetde. Det er enighet m at:

25 Inspeksjn er mer effektivt til å finne feil enn testing. I tillegg har inspeksjner den frdelen at det kan brukes mye tidligere enn testing allerede ved verrdnet design. J tidligere i utviklingsprsessen man begynner med inspeksjner j bedre er det. Fr tradisjnell prgramvareutvikling blir det mer kstbart å rette feil, j senere i prsessen man gjør det. Det ser imidlertid ut til at dette ikke gjelder fr utvikling der man begynner å eksekvere / simulere allerede i designfasen ne sm er mulig med SDL g Java / BlueJ. Det er imidlertid ikke sikkert at man får mer pålitelig prgramvare av dette. Prblemet er at inspeksjn finne feil jevnt spedt utver i kden mens vi - når systemet er i bruk vil eksekvere frskjellige deler av kden med svært frskjellig intensitet. De fleste feilhendelsene blir frårsaket av et lite antall feil i prgrammet kanskje så lite sm 5%. Det er derfr viktigere å finne de få, men kritiske feilene enn å kvitte seg med feil generelt. Av den grunn er det utviklingsteknikker sm fraråder å bruke enhetstesting g bare teste med brukerspesifikke data. Dette gjelder fr eksempel fr Cleanrm. Tp-Dwn vs. Bttm-Up Tp-dwn g Bttm-up er t ppulære teststrategier begge med sine frdeler g ulemper. Vi skal raskt se på hva de innebærer: Tp-Dwn: Vi begynner med hvedprgrammet g legger til mduler etter hvert sm de blir ferdige. Der vi mangler ferdige mduler setter vi inn tm kde gså kalt stubber. Bttm-Up: Her begynner vi med enkeltmduler så snart de er ferdige g legger til mduler etter hvert. Fr å teste mduler der nivået ver i kallhierarkiet ennå ikke er ferdige må vi lage ekstra kde gså kalt drivere. I begge tilfeller må man altså skrive kde sm senere skal kastes henhldsvis stubber g drivere. Dette kster penger g i tillegg kan vi få prblemer pga. feil i denne ekstrakden.hvis man lager et systemskjelett først kan man sette inn mduler etter hvert sm de blir ferdige. Dette er antakelig en bedre løsning g kan gjøres blant annet ved hjelp av BlueJ kapittel 9 Ifølge IEEE er et krav en betingelse eller evne sm trengs av en bruker fr å løse et prblem eller nå et mål. Vi vil bruke begrepet Krav Engineering i stedet fr kravanalyse fr å få fram at dette er en iterativ samarbeidsprsess sm inkluderer: Prblemanalyse Dkumentering av freløpige resultater Sjekke vår frståelse Gjenta trinnene hvis nødvendig. Selv m kravhåndtering g design strengt tatt er separate aktiviteter, er det neppe mulig å skille de helt. Lista verfr vil derfr fte bli utvida med preliminær design. Lærebka pererer med tre prsesser i kravfasen. Vis fig Disse er: Finne/ekstrahere/ppdage krav. Her er det viktig å frstå fagmrådet. Hvis det er flere fagmråder invlvert, må man frstå dem alle. I det minste på et nivå der det er mulig å kmmunisere. Det er viktige frskjeller på å utvikle prgrammer fr en kunde g utvikle prgramvare fr et marked. Spesifisere krav. Beskrive kravene slik at de kan implementeres. Vi må fkusere på prduktet, prsessen må kmme senere. Det finnes mange måter å beskrive krav på: fra naturlig språk - brukt mer eller mindre frmelt til frmelle ntasjner sm Z g VDM. Vi skal se på en av disse teknikkene tilpasset OO senere, i kapittel 12.

26 Verifisering g validering av krav. Vi må sjekke m vi har de rette kravene (validering) g m vi har frmulert disse kravene på en riktig måte (verifisering). Finne/ekstrahere/ppdage krav Strengt tatt går dette ut på å mdellere en liten del av verden. Den mdellen vi lager blir kalt en eksplisitt, knseptuel mdell. En slik mdell innehlder den bakgrunnskunnskapen sm alle de sm arbeider med det aktuelle dmenet har. All denne kunnskapen er implisitt fr de sm arbeider i dmenet g vår ppgave er å gjøre denne kunnskapen eksplisitt, slik at den blir tilgjengelig fr andre. Viktige prblemer sm vi må takle i denne prsessen er: Mange persner er ikke bevisst den kunnskapen de har dvs. de er ikke vant til å uttrykke den, det er bare ne alle vet. Kunnskapen frandrer seg ver tid Systemutviklerne g kundene/brukerne snakker frskjellige språk. Det er ikke sikkert de brukerne vi snakker med skjønner hva en fil er, eller at vi vet hva FAS-data er. Det er ikke sikkert at brukerne er i stand til å gi en knkret, eksplisitt beskrivelse av all den kunnskapen de sitter inne med. Det vil være nyanser mellm persner når det gjelder måten å beskrive kunnskap på, enten frdi de er uenige eller frdi de representerer ulike grupper av persnell. I tillegg til disse prblemene har vi andre, mer ulne prblemer. Nen viktige av disse er: Flk flest har en svært begrenset krttidshukmmelse. Dette betyr at de alltid vil huske best det sm skjedde sist g vil la dette dminere fr eksempel en samtale m hva de gjør, hva slags prblemer de har g hva de trenger av datastøtte i sitt daglige arbeid. Mennesker er svært selektive i hva de husker enten ting sm har gått svært bra eller ting sm har gått svært dårlig. Det sm er vanelig er det ikke alltid like lett å huske. Vi skal ikke vervurdere menneskers evne til rasjnell tenking. Ofte bruker de frenklede eller direkte gale mdeller når de skal frklare ting. Alt dette til sammen gjør at vi ikke kan satse på å bare få infrmasjn fra brukere g andre kunder. Vi må i tillegg ha tilgang på skriftlig infrmasjn g bruke kundens erfaring g kunnskap til å tlke/frstå det skriftelige materialet. Vi kan ikke frvente at kundene alltid vet hva de vil ha nen ganger er det bare på jakt etter en eller annen løsning på et prblem. Man risikerer fr eksempel at mens kunden vil ha et prgram sm løser prblemet, så er det egentlige prblemet ikke løsbart ved hjelp av et datasystem. Det kan fr eksempel være et menneskelig prblem, et administrativt prblem eller et kmpetanseprblem. Første fase i kravarbeidet må derfr være å frstå prblemet eller sammen med kunden å kmme fram til en felles frståelse av prblemet. Det finnes grvt sett t typer prblemer vi kan kmme ut fr når det gjelder kravarbeid: Tekniske prblemer implementer ei algritme sm finner verdien til et ikke-kmplett Gammaintegral. Dette er strt sett enkle prblemer. Alt arbeidet ligger i å finne en eller flere matematiske frmler g implementere de. Organisatriske prblemer lag et nytt system fr prsjektstyring. Dette er vanskelige prblemer i g med at de Griper inn i måten rganisasjnen arbeider på Angår mennesker Teknikker fr å finne krav Vis fig 9.3 g gå raskt gjennm teknikkene. Vi har valgt ut nen få sm vi vil si mer m: nemlig intervju, sammen med idémyldring, task analyse, use case analyse, dmeneanalyse g prttyping. Det kan være greit å tenke tilbake på den prsessen sm ble freslått av Fwler, kapittel 2, sm freslår å kmbinere use case g klassediagram/aktivitetsdiagram (dmeneanalyse) sammen med brukeren/kunden. Intervju Begynn med å spørre hva brukerne frventer fra systemet. Uansett hva vi leverer hvis det er ne annet enn det de frventer ligger vi i utgangspunkter dårlig an. Vi kan bruke gruppeprsesser, spørreskjema eller snakke med hver enkelt bruker. I grupperprsesser må vi passe på at ikke en eller nen få dminerer prsessen, mens mange

27 andre ikke kmmer til rdet eller ikke tør å si ne. Det finns flere metder fr å drive annyme gruppeprsesser. Vi skal se krt på en av de: 1. Førstemann skriver en ide, et behv eller et krav på et ark g sender det til neste mann. 2. Nestemann kan da: Gi ytterligere bidrag til den ideen sm allerede er skrevet ned Bare sender arket videre hvis han ikke har ne nytt å bidra med Starte en ny ide. Deretter sender han arket/arkene videre til neste mann i ringen. 3. En ide/et ark er ferdig når den persn sm startet arket ser at det ikke har kmmet på ne nytt i den siste runden. På denne måten kan man raskt samle mange ideer g flere innspill til hver ide, samtidig sm alle er sikret en viss grad av annymitet. En lik prsess kan gså lett implementeres i et nett av datamaskiner, fr eksempel på tppen av Netmeeting. Taskanalyse Vi lager en liste av jbbene brukerne skal utføre. Deretter blir hver enkelt jbb brutt ned i stadig mer detaljerte beskrivelser ne av det samme sm vi gjør når vi lager en WBS. Use case analyse Dette likner på taskanalyse, men i stedet fr å gå systematisk gjennm alle mulige g umulige arbeidsppgaver, ser vi her på et sett av scenarier. Scenariene kan være virkelige eller teretiske. Virkelig vi bserverer brukeren mens han gjør en jbb sm vi senere skal implementere. Ved å la brukeren frklare hva han gjør g hvrfr, kan vi følge med i prsessen g finne de kravene sm prsessen må tilfredsstille. Teretisk- vi sier til brukeren: Tenk deg at du skal. Hva ville du gjøre da? De viktigste utfrdringene ved bruk av denne metden er å finne ut når vi har nk use case g hvr detaljerte de skal være. Vi skal se mer mye mer på use case i UML litt senere. Dmeneanalyse Dmeneanalyse går ut på å frstå det mrådet dmenet systemet skal fungere i. Ofte vil denne analysen ta sm utgangspunkt allerede eksisterende systemer innenfr det samme mrådet. Man kan se på dette sm et frsøk på å finne eller utvikle en referansemdell fr mrådet hvrdan løser man prblemer av type X innefr dette mrådet. Dmeneanalyse vil vi behandle videre i UML, der vi bruker klassediagrammer i denne prsessen. Prttyping En prttyp tar utgangspunkt i de første kravene man kan få samlet inn på en eller annen måte. Deretter viser vi prttypen til brukerne g spør: Var det dette dere trengte? Svarene vil bestemme den videre utviklingen av en blanding av nye prttyper, diskusjner g demnstasjner. Dkumentasjn av krav Det sm kmmer ut av denne prsessen er en kravspesifikasjn, sm er utgangspunktet fr høynivå design. En måte å dkumentere den på, er å bruke IEEE Std 830. Dere finner den i vedlegg C i lærebka side 663 g utver. Det er nen viktige krav sm en kravspesifikasjn må ppfylle. Krrekt. Vi kan ikke garantere dette, men vi må sjekke så gdt vi kan mt kunden g mt andre relevante dkumenter. Feil i KS er kstbare å rette. Hvis vi ppdager de seint kan vi risikere å måtte gjøre m på alt fra g med verrdnet design. Entydig. Dette betyr at de sm har skrevet den g de sm skal lese den får samme ppfatning av hva sm skal gjøres. Vis diagram med kmmunikasjn mellm t grupper g avhengigheten av valgt, implisitt mdell. Ofte er prblemet her at det finnes ting sm kunden eller utvikleren anser fr å være pplagt, men sm ikke er det fr den andre gruppa. Kmplett. Alt sm er viktig fr kunden eller fr å realisere systemet må stå her. Dette gjelder fr eksempel sånt sm respns på feil data eller ulvlige kmmander eller kmbinasjner. All erfaring viser at det er vanskelig å få en kmplett KS tidlig, rett g slett frdi kunden lærer etter hvert. Internt knsistent. Dette betyr at ingen del av KS må stride mt en annen del. Dette kan bare sjekkes ved hjelp av inspeksjn. Ryddig ppstilling av alle krav fr eksempel ved å gi alle krav nummer g

28 undernummer g sette de pp i tabeller - vil hjelpe gdt. I tillegg må vi passe på å alltid bruke samme rd fr samme ting. Indikasjn g rangering ut fra viktighet g stabilitet. Begge deler er viktige å vite. Viktighet hva skal vi begynne med, hvr er det kritisk hvis det går feil Stabilitet hvr sannsynlig er det at kravet endrer seg. Høy sannsynlighet betyr at vi ikke bør begynne å implementere dette, men det vil være lurt å begynne med en liten, enkel prttyp fr å kmme videre. Den jbben det er å få på plass disse indikatrene vil gså være nyttige fr kunden slik at han kan bedre frstå sine egne pririteringer g hvr han har behv fr å undersøke videre. Verifiserbare. Det må altså være mulig å teste at vi har ppfylt kravene. Dette sette betingelser til hvrdan vi kan beskrive et krav. Det vil være gunstig å tenke Hvrdan kan vi teste dette? når vi skriver kravene. Dette er kblinga i V-mdellen mellm KS g FAT/SAT. Nen krav er vanskeligere å beskrive på en testbar måte enn andre. Hva betyr fr eksempel systemet skal være lett å bruke eller systemet skal gi rask respns? Mdifiserbart. Siden kunden med str sannsynelighet vil frandre mening underveis er det viktig at det er mulig å endre krav uten stre katastrfer det vil si vi må kunne behlde alle de egenskapene vi har listet pp så langt. Felles begrepsapparat, gd struktur på kravene g fravær av redundans er viktige faktrer her. Sprbarhet. På dette nivået betyr sprbarhet av det er mulig å finne ut hvrfr et krav finnes. T spørsmål er viktige: Hvr kmmer kravet fra? Er det et riginalt krav, er det utledet av - en knsekvens av ett eller flere andre krav eller er det ikke et krav i det hele tatt bare det hadde vært fint hvis? Hva er årsakene til kravet, hvrfr trenger vi dette g hva er målet med dette kravet? En måte å rganisere kravene på er vist i fig 9.6. g fig Krav kan bli rganisert langs flere akser: System mde: ulike mdi kan ha ulike krav trening, drift, avansert bruk, enkel bruk. Brukergruppe: ulike brukergrupper kan ha frskjellige behv g derfr frskjellige krav til systemet. Respnstype: fr eksempel data inn, data ut, spørre etter data Hvis vi ikke har ne annen måte å rganisere på, vil vi vanligvis bruke et eller annet funksjnshierarki. I fig. 9.7 har vi brukt brukerklasser fr å rganisere funksjnelle krav. Hvert funksjnelt krav kan beskrives sm gitt i standarden i vedlegg C. Har freslår de følgende beskrivelse: Innledning: hva er hensikten med denne funksjnaliteten, hva ønsker brukerne å ppnå? Input: hva slags input frventer denne funksjnen? Hva gjør funksjnen med dataene? Dette kan fr eksempel være en beskrivelse av algritmene sm blir brukt, hva slags sjekking sm blir gjrt med dataene g hva slags tilstand systemet er i etterpå. Output: hva gir funksjnen ss? Viktig å beskrive reaksjnen både ved riktige g ved feil data. Hva slags feilmeldinger vi skal gi, sv KS dkumentet Det er mange måter å skrive en KS på fra et dkument i naturlig språk, fr eksempel nrsk eller engelsk - til svært frmelle metder sm fr eksempel VDM (Vienna Develpment Methd). Vi skal i det etterfølgende se på følgende metder: Naturlig språk vanligvis nrsk eller engelsk ER diagrammer brukt mye i applikasjner med databaser Tilstandsdiagrammer SADT diagrammer Strukturert Analyse g Design Teknikk Vanligvis vil det ikke være ne enten eller. De fleste KS dkumenter vil innehlde innslag av flere metder, rett g slett frdi det er ting sm er enklest å si ett språk g andre ting det er lettest å si i et annet. Legg merke til at use case diagrammer alene ikke er KS de er bare et middel til å lage en KS. Uansett teknikk er det viktig at KS er på en slik frm at de kan leses av kunden. Dette legger begrensninger på hva slags språk g frmalismer vi kan bruke. Det er viktig at kundene kan lese KS fr å kntrllere at:

29 Vi har en felles frståelse av det systemet vi skal lage Alle krav er frmulert slik sm kunden vil ha de Kunden - alene eller sammen med uviklerne - kan inspisere KS dkumentet g gdkjenne det. Naturlig språk Dette er den naturlige måten å beskrive KS på. Dette gjelder fte fr kundene g svært fte gså fr utviklerne. De frmelle språkene sm finnes er strt sett kjent hs nen få spesialister fr eksempel spesialister på frmelle metder. Uansett er det bare unntaksvis at kundene kjenner de. Vi må passe på en del prblemer sm er knyttet til bruk av naturlig språk i en KS: Støy. Naturlig språk er svært fleksibelt. Det er derfr lett å beskrive samme tingen på mange frskjellige måter. I tillegg er det lett å fylle på med ting sm ikke har ne med KS å gjøre. Taushet. Det er lett å glemme å skrive ting sm er selvsagt fr den sm skriver det, selv m det ikke nødvendigvis vil være selvsagt fr den sm skal lese det. I en frmell ntasjn er man nødt til å gså ha med det selvsagte fr eksempel definisjner av alle parametere eller alle betingelser på en variabel. Mtsigelser. Hvis vi skal beskrive samme tingen mer enn en gang, er det lett å bruke nye rd g begreper. Dette kan føre til subtile selvmtsigelser, ne sm er vanskelig å ppdage senere. Fr eksempel x skal være større enn fire ett sted g x skal være større eller lik fire et annet sted. Det kan være greit å huske at det gjelder frskjellige regler fr det å skrive en rman g det å skrive en KS. Flertydighet. Naturlig språk særlig den muntlige varianten er av natur flertydig. Knteksten vil vanligvis gi den infrmasjnen man trenger fr å kunne tyde setningen. Slik er det imidlertid ikke alltid i skriftlig materiale. Frver referanser. Dette er særlig alvrlig i stre dkumenter. Ofte er det en måte å utsette en beslutning eller en beskrivelse på g det er ikke sjelden at man glemmer å ta beslutningen eller skrive det siden. Ofte er det et strukturprblem i dkumentet sm frårsaker slike prblemer. Frhåpninger. Nen ganger er en KS bygd mer på håp g tr enn på realiteter. Det hadde vært fint m er ppulært. I andre tilfeller er det beskrevet løsninger sm er så avanserte at det vil være vanskelig å realisere dem med dagens teknlgi i hvert fall til en verkmmelig pris g innenfr realistiske tidsrammer. Det er imidlertid viktig å huske at naturlig språk er den representasjnen det er lettest å utveksle mellm mennesker eller rganisasjner g den sm flest behersker. Nen har eksperimentert med følgende løsning på prblemet: 1. Beskriv g analyser prblemet i et frmelt språk fr eksempel VDM, Z eller OBJ. 2. Skriv dkumentet m til naturlig språk g vis det til kunden. 3. Alle endringer tas ver til det frmelle dkumentet slik at vi er sikker på at KS er knsistent, entydig sv. 4. Gjenta fra punkt 2 viss nødvendig. Det er neppe praktisk å gjøre dette manuelt fr større dkumenter eller systemer. Et verktøy ville hjelpe mye, men vi vil kunne få prblemer sm er vanskelig å ppdage hvis det er feil i verktøyet. Et mer praktisk alternativ er å støtte/utfylle beskrivelsen i naturligspråk med diagrammer av frskjellig type fr eksempel ER diagrammer, tilstandsdiagrammer eller SADT diagrammer. Vi vil krt se på disse tre diagramteknikkene. ER diagrammer Et ER diagram er en semantisk struktur. Det finnes fem mdellbegreper: Entitet et bjekt. Dette kan være både abstrakte g knkrete bjekter. Entitetstype type fr en entitet/bjekt Attributtverdi innfrmasjn sm helt eller delvis beskriver en entitet. Attributt type fr et sett av attributtverdier Relasjn en asssiasjn mellm t eller flere entiteter Vis eksempel i fig g kmmenter hva vi har av entitetstyper fr eksempel member relasjn fr eksempel brrw g attributter fr eksempel name g identificatin. ER diagrammer ble pprinelig laget fr databasemdellering, men er nå en del av flere teknikker sm bruker strukturert analyse. Det er en grei måte å frstå hvrdan begreper henger sammen, men man kan like gjerne bruke klassediagrammer fr dette frmålet.

30 Tilstandsdiagrammer Tilstandsdiagrammer viser: Hvilke tilstander en enhet har Hva slags input sm er lvelig i en gitt tilstand Hvilken tilstand input fører til Tilstandsdiagrammer har et bredt bruksmråde innenfr mange fagfelt g er en effektiv måte fr å beskrive frandringer i et element frårsaket av stimuli. Diagrammene kan brukes til å beskrive mennesker, maskiner, øknmi g alt annet innimellm. Vis fig g kmmenter. Fr å lage et tilstandsdiagram begynner man med det man skal studere tilstanden til g stiller t spørsmål: Hva slags input/stimuli kan denne enheten få nå? Hvilken tilstand får den hva skjer med enheten - fr denne inputen? Svaret på det andre spørsmålet er en ny tilstand g man kan da gjenta spørsmålene fr den nye tilstanden. Prsessen vil gi gd versikt g frståelse fr det bjektet vi studerer. SADT diagrammer SADT står fr Strukturert Analyse g Design Teknikker. Dette er primært en diagramteknikk. Hvert enkelt diagramsymbl har en presis mening det har altså en streng syntaks g semantikk. Vi skal ikke hlde ne SADT kurs, men krt se på de viktigste ntasjnselementene. Vis fig 9.13 g fig Ikke-funksjnelle krav Ikke-funksjnelle krav er krav sm angår hvrdan et system løser en ppgave. Eksempler på slike krav er krav til pålitelighet, respnstid g brukervennlighet. Utfrdringen ligger i å frmulere disse kravene slik at de er testbare g hvis mulig sprbare. Mange ikke-funksjnelle krav er ikke sprbare ned i prduktet de er bare sprbare ned i prsessen. Selv m vi ikke kan identifisere hvr i prduktet de er realisert, kan vi peke på hvr i prsessen vi har tatt hensyn til kravene. Det finnes en enkel prsess definert av Tm Gilb sm heter Management by Objective. Denne prsessen vil hjelpe til med å definere ikke-funksjnelle krav på en testbar måte. 1. Start med et ikke-funksjnelt krav A 2. Spør Hva mener du med A? 3. Dette vil gi en ny tlking av A eller en dekmpnering av A i kmpnentene a1, a2, 4. Hvis den nye tlkinga av A eller kmpnentene a1, a2, er målbare, så er vi ferdig. Ellers gjentar vi prsessen fra tinn 2 med den nye tlkinga av A eller med hver av kmpnentene a1, a2, Vi vil se på et eksempel brukervennlighet. Hva mener du med brukervennlig Lett å lære Lett å bruke Hva mener du med lett å lære Skal kunne gjøre de vanligste jbbene mine etter et tdagers kurs. Hva er de vanligste jbbene dine Oppgavene X, Y g Z Hva mener du med lett å bruke Skal kunne gjøre de vanligste jbbene mine like raskt sm jeg gjør de nå Hvr mye tid bruker du nå Vet ikke, men det kan vi vel finne ut. Videre arbeid nå vil starte med å samle data m hvr lang tid persnene nå bruker på de tre ppgavene X, Y g Z. Dette kan vi gjøre ved å vervåke persner i bedriften g se hvr lang tid de bruker hver gang de gjør jbben. Vi kan bruke største g minste tid et intervall eller vi kan beregne middelverdi g standardavvik Når vi har dette klart kan vi definere testen fr brukervennlighet på følgende måte:

31 1. Få kunden til å velge ut fr eksempel tre brukere. Disse vil få et tdagers kurs i å bruke systemet 2. Disse brukerne skal deretter gjøre jbbene X, Y g Z i hver sin rekkefølge. Fr eksempel kan bruker 1 gjøre X, Y, Z, X, Y, Z, bruker 2 gjøre Z, Y, X, Z, X, Y g bruker 3 gjøre Z, Z, Y, Y, X, X. Registrer tida hver bruker trenger på ppgaven. 3. Hvis alle jbbtidene faller i det tidligere målte intervallet fr hver jbb, er brukervennligheten gdkjent. Ellers må vi identifisere årsakene til prblemet, rette det g deretter gjenta testen med tre nye hvis mulig brukere. Legg merke til at dette ikke er en test av datasystemet alene. Testen inkluderer gså pplæringsmaterialet g selve kurset. Dersm vi vil unngå det, kunne vi fr eksempel erstatte kurset med at hver bruker får en fmle- g prøvefase av en gitt lengde før vi begynner å teste samle data. Rammeverk Det finnes fire perspektiver sm vi kan bruke på et datasystem: Fretningsperspektiv. Hvrdan driver vi frretning? Hvis man ikke kan knytte prsjektet g prduktet til frretningsdriften i firmaet, vil vi før eller siden få prblemer med priritet g ppmerksmhet. Dessuten gir dette innsikt i en gd del underfrståtte implisitte krav g/eller frventninger. Infrmasjnsperspektiv. Her ser vi på den infrmasjnen sm flyter inn i g ut av systemet g sm er nødvendig fr frretningsdriften. Her må vi gså se på hva sm skal være med i datasystemet g hva vi vil realisere utenfr i frm av manuelle rutiner. Vi trekker altså systemgrensene her. Dette er viktig fr senere brukerdeltakelse g kmmunikasjn. Funksjnsperspektiv. Hva skal systemet gjøre? Dette er det eksterne synet systemet sett utenfra. Her må vi invlvere de sm skal bruke systemet sluttbrukerne, ikke deres sjefer. Legg merke til at det gdt kan g fte vil være frskjell på kunde g sluttbrukere. Vi har t typer av brukere: De sm bruker datasystemet - primærbrukere De sm bruker de dataene sm kmmer ut av datasystemet sekundærbrukere Begge parter må invlveres, frdi de ser på systemet fra hvert sitt ståsted g vil kunne ha ulike behv. Implementeringsperspektiv. Dette er det interne systemet systemet sett innenfra. Hvedprblemet her er å realisere den funksjnaliteten sm er identifisert i funksjnsperspektivet. De sm er invlvert er prgramvare eksperter systemanalytikere, designere, kdere, testere g prsjektledere. Disse perspektivene vil kreve ulike teknikker g kunnskap. Det er neppe mulig å gjøre dette alene g ved å bruke bare en metde eller teknikk. Vi kan ikke lære dere alt dere trenger i dette faget, men nøyer ss med den EDBfaglige biten. Det dere imidlertid må lære er at det finnes flere typer prblemer med å lage et effektivt system fr en bruker ikke bare det å prgrammere en ferdig tygget løsning Fwler kapittel 3 Et use case er et ufrmelt scenari beskrevet i en ufrmell ntasjn. Når man tenker på all den frmalismen sm er utviklet fr å dkumentere kundekrav, er det nærmest underlig at use case fungerer så gdt sm de egentlig gjør. Siden use case er en type scenari, vil vi først se på hva et scenari er: Et scenari er i denne frbindelsen - en sekvens av trinn / handlige sm beskriver en interaksjn mellm en bruker g et system. Tilsvarende kan vi si at: Et use case er et sett av scenarier sm er bundet sammen av et felles brukermål.

32 Ofte vil et use case ha en hvedversjn hvedscenari der alt går sm planlagt i det enkle tilfelle. I tillegg vil det ha alternative sekvenser hvis ett eller annet går galt. I tillegg til slike spesielle sekvenser kan du, hvis du vil legge til tekst sm sier ne m betingelsene fr at dette use caset er relevant. Pass på å ikke verbelaste use case med ntasjn. Det er bare det sm er viktig fr kmmunikasjn med brukerne g det sm er viktig fr å frstå brukernes behv sm skal være med. Mengden av detaljer i et use case avhenger av risiken. J større risiken er dest mer detaljer trenger du. Den risiken vi ser på her er bestemt av knsekvensene hvis vi misfrstår dette spesielle brukerkravet. Det finns flere måter å dkumentere et use case på g vi skal se litt på hver av disse: Vanlig, fri frmat tekst beskrive en histrie med fkus på hva sm skjer. Strukturert tekst fast, tabularisk ppsett Diagram Fri frmat tekst Dette er en prsabeskrivelse muligens med ne struktur m hva sm skal skje når man ønsker å bruke systemet til å utføre en beskrevet ppgave. Ofte vil den ha karakter av en spørsmål g svar sesjn der brukeren svarer på spørsmål fra den sm skal lage use caset. Diagram Ta utgangspunkt i fig 3-2 hs Fwler. Viktige elementer i diagrammet er: Aktør en sm gjør ne eller initierer en handling. Det vil fte, men ikke alltid, være en persn. UML skiller imidlertid ikke mellm persner g andre aktører, sm fr eksempel et annet datasystem. I fig 3-2 er fr eksempel Accunting System en aktør sm ikke er et menneske. Det kan være lurt å starte med å identifisere alle aktørene g deretter se på hva enkelt aktør gjør. En viktig kilde til å identifisere alle use case er å se etter hvilke eksterne hendelser sm skjer g hvrdan systemet skal reagere på de. Include relasjner, sm viser aktiviteter sm blir brukt flere steder, men sm vi vil slippe å beskrive flere ganger. Vi skiller ut disse aktivitetene i en egen use case g inkluderer det i de use casene der vi trenger den. I fig. 3-2 er Valuatin et eksempel på dette. Generalisering sm viser at et use case likner på et annet, men gjør litt mer. Dette er en måte å beskrive alternative scenarier på. I fig 3-2 har vi denne situasjnen i Capture deal. Dersm kredittgrensene er verskredet vil vi få en spesialbehandling. Dette er stadig Capture deal use caset, men i en annen frm. Et slikt use case skal altså stadig angå samme ppgave. I fig 3-3 hs Fwler ser vi et nytt diagramelement extend eller utvid.. Dette likner på generalisering, men use caset sm skal ha en utvidelse må ha et utvidelsespunkt. Dette må være erklært på frhånd. Det er fullt mulig å ha flere utvidelsespunkter. Følgende tmmelfingerregler kan være greie å bruke: Bruk include når man begynner å gjenta ting i t eller flere use case. Bruk generalisering når du beskriver en variant av den nrmale ppførselen. Bruk extend når du beskriver en variant g ønsker å ha mer kntrll ver den. Det er dette vi ppnår ved å ha definerte utvidelsespunkter Det er mulig å utvikle use case i mer detaljer etter hvert sm vi får bedre frståelse. Det er gså mulig å splitte pp et use case hvis vi synes det blir fr strt g uhåndterlig. Nen ganger kan det være praktisk å gjøre dette ved å rganisere flere samhørende use case i pakker. I tillegg er det ingenting i veien fr å legge på frklarende tekst i den grad det er nødvendig. Uansett er det viktig å huske på at use case er et hjelpemiddel i kmmunikasjn med brukerne det er ikke en metde fr (verrdna) design.

33 Strukturert tekst Mange særlig flk sm kjenner et dmene gdt g sm har mye erfaring i systemutvikling synes at use case diagrammer er litt fr upresise. Særlig er det alvrlig at det ikke er mulig å vise sekvenser av hendelser, bare selve handlingene. Av den grunn er det mange sm fretrekker tekstlige use case. Det finnes ikke ne i UML sm definerer maler eller strukturerte tekst use case. Det kan være lurt å starte med use case diagrammene fr deretter å lage strukturerte tekstlige use case sm innehlder med detaljer, sekvenser, triggere sv kapitel 12 Vi kan se bjektrientering fra flere sider. De viktigste fr ss er: Mdellering. Viktige egenskaper er at hvert bjekt har En identitet sm skiller det fra andre bjekter Egenskaper sm kan finnes ved å se på / studere bjektet. Frskjellige bjekter ligger på frskjellige steder i hukmmelsen. Et bjekt kan betraktes sm en abstrakt datatype (ADT) sm består av et sett med data g perasjner fr å manipulere de. Det skal i prinsippet bare være mulig å endre disse dataene via de definerte perasjnene. Med dette perspektivet kan vi sette: bjekt = identitet + data + perasjner. eller bjekt = identitet + tilstand + ppførsel Mdelleringen blir da å finne g beskrive de enkelte delene av likninga. Utviklerne bruker O-O: Et bjekt er en abstraksjn g en innkapsling av data g deres perasjner. Imidlertid vil ikke alle O-O språk kreve abstrakte datatyper g et bjekt behøver ikke være en abstrakt datatype. Et eksempel på en abstrakt datatype kan være en kø. Den innehlder et array fr køen g t eksternt tilgjengelige perasjner sett inn i køen g ta ut av køen. I tillegg vil den ha interne perasjner sm fr eksempel sjekk fr full eller tm kø. Et bjekt kan egentlig være hva sm helst. Data abstraksjner g bjekter er på mange måter rtgnale uavhengige begreper. Mange vil kalle språk sm bare har abstrakte datatyper fr bjektbaserte språk, men de vil reserver O-O fr språk sm har arving. Implementering lage O-O. Her er et bjekt en sammenhengende struktur i hukmmelsen en samling av data g kde. Objekter kan ha mindre bjekter inne i seg det er en rekursiv struktur. Det laveste nivået består av heltall, blske variable sv. Det finnes mange interessante prblemer med å realisere O-O, men vi går ikke inn på de her. Frmelt sett: Et bjekt er en tilstandsmaskin med et sett av tilstandsvariable g et sett av funksjner sm manipulerer disse tilstandsvariablene. Oppførsel hs bjekter er knyttet til endringer i tilstanden til bjektet dvs. til endring i verdien til en eller flere variable. Disse variable er attributter til bjektet. En dør kan fr eksempel være et bjekt. Den kan være i flere tilstander sm fr eksempel åpen / lukket, låst / ulåst. Legg merke til at ikke alle kmbinasjner er realistiske. Lukket g ulåst er OK, mens åpen g låst ikke nødvendigvis er like greit. I tillegg vil vi ha betingelser fr hvilke verganger sm er lvelige. Fr eksempel vil kan det bare være lv å gå fra lukket til åpen viss vi allerede er i tilstanden ulåst. Dette dkumenteres best i et enkelt tilstandsdiagram. Vi vil nesten alltid realisere et system med flere klasser. Derfr er frbindelsene mellm klassene viktig. Viktige frbindelser er: Spesialisering. Fr eksempel vil brd g stl være spesialiseringer av klassen møbler. I ER diagrammer vil vi tilsvarende ha en is-a relasjn: A table is-a piece f furniture. Det inverse av spesialisering er generalisering. Møbler er en generalisering av stl, brd, sfa sv. Vis fig 12.2 sm viser et spesialisering / generalisering hierarki. Dette er et diagram sin viser enkel arving g det er derfr et tre. Hvis vi har multippel arving vil vi i stedet få en rettet, asyklisk graf (DAG). Objekthierarkiet kan gså betraktes sm et typehierarki.

34 O-O analyse g design Ntasjn Vi trenger tre typer diagrammer fr å gjøre O-O analyse g design: Klassediagrammer fr å vise dekmpneringen av systemet. Klassediagrammene har nder klasser g kanter relasjner mellm klassene. Vi kan få fram mer infrmasjn ved å legge til tekst på en eller flere nder g kanter. Tilstandsdiagrammer fr å vise dynamisk ppførsel. Her bruker de fleste O-O metder en eller annen frm fr tilstandsmaskin. Ndene i diagrammet viser lvelige / mulige tilstander, mens kantene viser lvelige verganger fra en tilstand til en annen. Interaksjnsdiagram fr å vise sekvensen av meldinger mellm bjekter. Vi har t typer: Sekvensdiagrammer, sm legger vekt på rekkefølge / tidsaspekter Samarbeidsdiagrammer, sm legger vekt på bjektene g deres relasjner fr å implementere en gitt interaksjn Klassediagram Klassediagrammene viser den statiske strukturen til systemet. En klasse trenger tre typer inf: Navn på klassen En liste av attributter En liste av tjenester sm klassen tilbyr Vi tenger ikke ha med alle attributtene eller tjenestene i starten av fasen bare de vi synes er viktige her g nå. Før vi kan begynne å implementere ne må de imidlertid være på plass. I tillegg til generalisering g spesialisering sm vi allerede har sett, er følgende relasjner viktige: Asssiasjner med g uten asssiasjnsklasser. Vis fig I UML vil en asssiasjn frbinde t eller flere klasser. Dette vises med ei heltrukket linje. Vi kan viss vi vil sette navn på asssiasjnen. I tillegg kna vi legge på retning (Fylt trekant) g multiplisitet. Fr eksempel står det her at en klient kan tilhøre ett eller flere bibliteker g at et biblitek kan ha null eller flere klienter. Når vi trenger mer inf kan vi legge til en asssiasjnsklasse. Dette er en vanlig klasse med attributter g perasjner. I eksemplet i fig 12.5 vil det være praktisk å ha attributt medlem-id g perasjn bli medlem. Aggregater. Må skilles fra sammensetning cmpsitin. Aggregater vises med ikke-fylte ruter symbler. Aggregater er is-part-f relasjner. Hver klasse sm deltar i et aggregat kan tilhøre flere helheter. Sammensetning cmpsitin er gså is-part-f relasjner, men det sm er mdellert kan bare tilhøre ett hele. Sammensetning vises med en fylt ruter symbl. Når dette hele frsvinner gså delene mens dette ikke er tilfelle fr aggregater. Sånn setter sammen setning et sterkere begrep enn aggregater. Vis fig 12.6 i bka. Fr å frklare frskjellen vil vi se på følgende figur vis fig. 6-6 hs Fwler. Denne figuren viser at i denne mdellen kan et punkt kan bare tilhøre en sirkel eller et plygn av gangen. Beskrivelsesstile style kan imidlertid høre til flere sirkler g plygner g kan leve sitt eget liv selv m vi fjerner alle sirkler g plygner. Tilstandsdiagram Et bjekt vil ha et livsløp det blir skapt, det blir ppdatert en del ganger (muligens null ganger) g tilslutt dør det. Et tilstandsdiagram er en gd metde fr å dkumentere et slikt livsløp. UML legger en del ekstra inf til de tradisjnelle tilstandsdiagrammene fr at de skal være enkle å bruke i mdellering. Vi vil se på følgende mekanismer: Tilstander har lkale variable. Dette gjør diagrammet enklere enn m vi hadde all inf i sele tilstandsbeskrivelsen. Et eksempel kan være en persn sm låner bøker på et biblitek. Etter sm han tar ut bøker kunne vi tenke ss at han gikk fra tilstand ikke lånt bøker til tilstanden lånt en bk, deretter til tilstanden lånt t bøker sv. Dette vil kunne bli et strt - g ikke spesielt interessant diagram. Vis hvrdan dette ville bli

35 seende ut på tavla. Alternativet er fig i bka, sm er mye enklere, uten å gi slipp på ne inf. Sm fr alle andre tilstandsmaskiner vil det gså i UML være slik at input vil kunne frårsake vergang fra en tilstand til en annen. I frbindelse med vergangen vil man kunne ha handlinger f.eks. å ppdatere en variabel eller å gi utput. Tilstandsdiagrammer kan frt bli stre g vanskelige å lese. Derfr er det innført en metde / ntasjn fr å lage litt struktur i de. Tilstander tegnes sm rektangler, men med runde hjørner. I tillegg til alle de virkelige tilstandene finnes det t pseudtilstander start g stpp. Et bjekt kan ikke være i nen av disse tilstandene. I starttilstanden er ikke bjektet instansiert g i sluttilstanden er det brte. Overgangene mellm tilstander er markert med: Hendelsen sm frårsaker vergangen Lån bk. Denne må alltid være tilstede. Aksjner N = N + 1. Aksjnen er skilt fra hendelsen med en /. Fr eksempel kan vi sette lån bk / N = N+1 Betingelser fr at vergangen skal være lvelig med ntasjnen <vergang> [N = 0] Output sm følger av vergangen Fr å lettere bevare versikten kan det være lurt å ikke ha med alle detaljer hele tiden, men bare de detaljene vi trenger fr øyeblikket. Fig 12.8 viser hvrdan vi kan rganisere tilstandsdiagrammet med trinnvis frfining. Dette gjør det enklere å lage tilstandsdiagrammet i flere trinn etter hvert sm vi får mer inf, bedre frståelse eller trenger en mer kmplett beskrivelse av endringene i tilstand. Sekvensdiagram Objekter kmmuniserer ved å sende meldinger til hverandre. Dette blir i UML viset med sekvensdiagrammer. Disse er mtrent det samme sm MSCer i telekm-verdenen. Objekter blir lagt hrisntalt, vanligvis slik at de sm ligger lengst til venstre blir aktivert først. Meldinger fra et bjekt til et annet vises sm hrisntale linjer med piler - fra det bjektet sm sendte dem, til det bjektet sm mttar dem. Tiden vises langs den vertikale aksen slik at en hendelse sm ligger høyre i diagrammet hender før den sm ligger lavere. Vis fig g kmmenter. Nummereringa sm er vist i figuren er ikke nødvendig. Det finnes mange andre mekanismer i sekvensdiagrammer i UML enn de sm vises her. F.eks. kan vi skille mellm synkrne g asynkrne meldinger, vi kna vise hvrdan bjekter starter g dør g vi kan vise iterasjner. Se kapitel 5 i Fwler fr mer inf. Uansett er hensikten å vise hvrdan bjekter utveksler inf. Erfaring viser at de fleste frstår sekvensdiagrammer etter litt enkelt frklaring g de er derfr effektive når vi skal diskutere med brukere g kunder. Det er mulig å gjøre sekvensdiagrammer kmplekse, særlig ved å legge på mange betingelser g betinga hendelser. Dette ødelegger imidlertid hensikten med diagrammet sm hjelpemiddel fr kmmunikasjn. Det er bedre / enklere å se på hvert diagram sm en beskrivelse av et scenari g heller lage ett diagram fr hvert scenari. Siden use case gså er scenarier vil det være mulig å gå fra use case til sekvensdiagrammer g bruke dette sm en metde til å identifisere bjekter / klasser g de meldingene vi trenger fr ar klassene skal samarbeide. Samarbeidsdiagrammer På samme måter sm sekvensdiagrammer er gså samarbeidsdiagrammer en metde fr å vise hvrdan en gruppe bjekter samarbeider fr å realisere et scenari. Slike diagrammer kalles fte gså bjektdiagrammer. Et samarbeidsdiagram består av:

36 Nder sm er enheter fte bjekter Kanter mellm ndene. Disse kantene er nummerert fr å vise rekkefølgen til hendelsene. Man trenger ikke begge deler g hva man velger av samarbeidsdiagram g sekvensdiagram er fte et spørsmål m smak g behag. O-O analyse g design Metder Viktige kmpnenter i analyse g design er: Identifiser bjektene Bestem de attributtene g tjenestene bjektene skal tilby Bestem relasjnene mellm de Dette er ikke sen sekvens av ppgaver de må løses iterativt. Resultatet er en statisk struktur av bjekter g relasjner mellm disse bjektene. Livsløpet til et bjekt kan beskrives i et tilstandsdiagram g hvrdan de samarbeider, kan vises i et sekvensdiagram. De fleste måter å finne den nødvendige infrmasjnen bygger på lingvistiske begreper f. eks at substantiver blir bjekter g verb blir tjenester. Vi skal se litt på tre metder. Alle tre har hvert sitt sett av retningslinjer det er ikke algritmer fr prblemløsning. Hver metde er definert ved et sett av aktiviteter g et prsessdiagram sm viser hvrdan aktivitetene er relatert til hverandre. Alle har en iterativ analysefase, men de t siste metdene har ikke en iterativ designfase. At analysefasen er iterativ henger sammen med at det er her vi bygger pp vår frståelse av systemet både hva det er g hva det skal gjøre. Bch metden Vis fig i bka. Det første gjennmløpet i mdellen er analyserientert mens de senere vil være designrienterte. Vi vil kmmentere hver aktivitet krt: Identifiser klasser g bjekter. Her skal vi avgrense prblemet hva er innefr datasystemet g hva er utenfr g lage en første dekmpnering. Ved analyse: finn gde abstraksjner, basert på vår frståelse av applikasjnsdmenet. Ved design. Legg til klasser fra løsningsdmenet. Her vil vi gså lage en frtegnelse ver alle abstraksjnen (data dictinary) med kmplette definisjner, slik at vi er enige m hva de begrepa vi bruker betyr. Identifiser semantikken g attributtene til hver enkelt abstraksjn hva gjør den med hva? Denne infrmasjnene kmmer fra scenarier f.eks. use case. Ut fra denne prsessen får vi en knsistent g kmplett lite av ansvar / perasjner fr hver enkelt abstraksjn. Denne infrmasjnen blir gså satt inn i data dictinary. Vår frståelse av use case blir videreutviklet g kblet sammen med abstraksjnene i sekvensdiagrammer eller samarbeidsdiagrammer. Identifiser relasjner mellm bjektene. Her må vi igjen skille mellm analyse g design. Analyse: finn relasjner mellm abstraksjnene. Design. Vi tar taktiske beslutninger m arv mellm klassene g instanser fr bjektene. Dette gir ss klassediagrammer, samarbeidsdiagrammer g mduldiagrammer. Mduldiagrammene viser mdulstrukturen til systemet. Identifiser grensesnitt g implementasjn. Her velger vi algritmer g eventuelle nye klasser sm vi trenger av løsningsmessige årsaker. OMT metden Vis fig i bka. Denne metden har et klart skille mellm analyse g design sm Bch metde mangler. Metden er implementasjnsrientert i langt sterkere grad enn Bch metde. Skrittet fra analyse til design er strt g ikke enkelt. Analysefasen er iterativ, mens designfasen i prinsippet - ikke skal være det. Analyse Finn bjektmdell. Dette er den statiske strukturen i systemet. Identifiser bjekter, deres relasjner g attributter. Lag klassediagram g data dictinary. Finn dynamisk mdell. Dette er ppførselen til systemet. Lag sekvensdiagrammer. Finn en funksjnell mdell. Denne beskrives med et data flyt diagram. Vis fig fra bka. Disse tre trinna mp gjentaes det er en iterativ prsess. Design

37 System design. Her lager eller velger vi en arkitektur fr systemet. Dette inkluderer ppdeling i subsystemer, plassering i prsessr (viss flere) sv. Objekt design. Her lager vi de algritmene vi trenger fr hvert enkelt bjekt. Fusjnsmetden Vis fig i bka. Sm fr OMT er det skilt klart mellm analyse g design, men i mtsetning til OMT er designdelen her langt mer detaljert. Sm fr OMT er analysefasen iterativ. Analysefase Finn bjektmdell klassediagrammene. Sm før blir dette dkumentert i data dictinary. Finn grensesnittmdell. Dette viser den dynamiske ppførselen. Den innhlder en livssyklusmdell fr hver klasse i tillegg til regulære (analytiske) uttrykk fr tilstandsmaskinen. I tillegg er det en spesifikasjn av semantikken fr hver perasjn ved hjelp av pre- g pstbetingelser. Prebetingelse hva er sant før perasjnen blir utført g pstbetingelse hva er sant etter at perasjnen er utført. Designfase Lag bjektsinteraksjnsdiagram. Dette er mtrent det samme sm samarbeidsdiagrammer. Lag synlighetsgraf. Denne beskriver hvrdan kmmunikasjnen mellm bjekter blir realisert. Vi finner ut hvilke andre bjekter hvert enkelt bjekt må kmmunisere med. Synlighetsgrafen beskriver hvrdan dette blir gjrt. Utvikl klassebeskrivelser. Denne bygger på det vi laget i de t fregående aktivitetene bjektinteraksjnsdiagrammer g synlighetsgraf. Lag arvingsgraf. Arvingsgrafen lages ut fra klassebeskrivelsene vi allerede har laget. Fusjnsmetden legger mye mer vekt på designfasen enn de t andre metdene. At analysemetden er så enkelt g krt betyr at metden er avhengig av en ferdig, kmplett kravspesifikasjn. Nen generelle kmmentarer Vi ser det er strt spenn i graden av frmalisme fra Bch metde sm er meget ufrmell til Fusjnsmetden sm er svært frmell g matematisk. OMT metden ligger litt midt i mellm. Det er en svakhet g en styrke fr O-O metdikken at det er liten frskjell mellm analyse g design. Ikke alle er imidlertid enige i dette. Det er helt klart at analyse g design har frskjellige hensikter: Analysen er prblemrientert g skal gi en frståelse av dmenet g prblemet vi skal løse Design er løsningsrientert g skal dekmpnere løsningen i mduler delløsninger g bestemme hvrdan disse skal samarbeide. Imidlertid vil det alltid være behv fr å revurdere eller ppdatere vår frståelse av prblemet etter sm vi lager en design g blir tvunget til å ta flere g flere beslutninger. Det kna være nyttig å tenke på veien fra prblem til løsning sm ei rett linje, der O-O analyse strt sett er nær prblemet mens design strt sett er nær løsningen. I de fleste tilfeller vil det kunne være en str grad av verlapp på midten. Erfaringene med O-O er ne blandet. Det er ikke urimelig å hevde at O-O er en riktigere måte å se prblemer på. Tilsvarende er det heller ikke urimelig å hevde at verden består av, eller kan mdelleres sm, bjekter. Det viser seg imidlertid at de fleste mennesker tenker lettere ved hjelp av handlinger eller ppgaver. Derfr er erfaringene med O-O metder blandede g resultatene av de få kntrllerte eksperimentene sm er utført er langt fra entydige Fwler kapittel 4 Frfatteren skiller mellm tre perspektiver på klassediagrammer: Knseptuelt syn: klassediagrammet viser knsepter fra det dmene vi ser på. Vi behøver ikke / skal ikke tenke ne særlig på hvrdan vi skal implementere dette. Det er derfr gså uanhengig av utviklingsspråk. Dette hører primært hjemme i analysefasen.

38 Spesifikasjnssynet: fkus er på klassens grensesnittet mt mverdenen. Nøkkelen til gd O-O prgrammering ligger i å prgrammere mt klassenes grensesnitt, ikke mt deres innmat implementasjnen. Dette er viktig i designfasen. Implementasjnssynet: dette angår siste fase implementasjn - g er det eneste der vi tenker realisering av innmaten i klassen. Grensa mellm perspektivene er ikke skarp. Skille mellm knsept g spesifikasjnen er ikke alltid like viktig. Det er mest viktig å hlde implementasjnsperspektivet adskilt fra de t andre. Vi vil se på en del egenskaper ved klasser i de tre perspektivene. Asssiasjner Knseptuelt. Knseptuelle relasjner mellm klassene. Dette inkluderer navn g multiplisitet. Her pleier vi ikke å legge på navigeringsinf retninger på asssiasjnene. Spesifikasjn. Her representerer asssiasjnene ansvarsfrdeling mellm klassene. Ansvar viser f.eks. hva en klasse er i stand til å gi fra seg av infrmasjn g hvem sm ppdaterer hvilken inf. Det ligger imidlertid ingen implementasjnsbeslutninger i dette. Hvrdan det gjøres, må bestemmes seinere. Vi legger på piler fr å vise hvem sm har ansvar fr hva. I fig. 4.2 vil Order ha en peker til Kunde, mens det mtsatte ikke vil være tilfelle. Fwler anbefaler at vi lar ingen pil betyr at vi ikke har bestem ss ennå. Implementasjn. Her vil vi legge til pekere i de nødvendige retninger avhengig av pilene - g erklæringer av pekere g metder til å bearbeide relevante data. Asssiasjner kan ha navn. De øker imidlertid mengden av inf i klassediagrammet. Det er derfr lurt å bare gi navn til de asssiasjnene der dette øker frståeligheten av diagrammet. Asssiasjner er permanente frbindelser mellm t bjekter. Attributter Knseptuelt. Her markerer vi bare at attributtet finnes ikke hva det er eller hvrdan vi vil realisere det. Spesifikasjn. Når vi går ver til spesifikasjnsnivået så sier attributtet at klassen har et ansvar fr å gi deg sin verdi. Implementasjn. Nå er dette et felt i klassen sm må ha type, synlighet l. Det er ingen frskjell mellm attributter g asssiasjner på knseptuelt nivå. Frskjellene er bare viktige på spesifikasjns- g implementasjnsnivå. Attributter er gjerne variable med en enkelt verdi. Operasjner Knseptuelt. På dette nivået bør man bare bruke perasjner til å vise de viktigste ansvarsmrådene til en klasse. Spesifikasjn. Public metder i klassen. Det er vanligvis ikke nødvendig å vise metder sm bare manipulerer attributter, siden de er underfrstått. Implementasjn. Her må man ta med alle metder siden de nå skal realiseres. Full UML-syntaks fr en perasjn er <synlighet> <navn> ( <parameterliste> ): <returtyper> { <streng av egenskaper> } Synlighet: + sm betyr åpen / public, # sm betyr beskyttet g - sm betyr privat. Navn er en tekststreng Parameterliste er ei liste av parametere, adskilt med kmma. Hver parameter har syntaksen <retning> <navn> : <type> = <default verdi>. <retningsnavn> er in input - ut - utput - eller inut både input g utput. Default verdi er in. Returtype - type på resultatet. Strengt tatt er det lv med flere typer, men det vil vanligvis bare være en. Egenskaper liste av egenskaper, adskilt med kmma,sm definerer egenskaper ved resultatet.

39 Eksempel - + balansepaa (dat: Dat): Penger. Denne perasjnen er synlig public, har navnet balansepaa g parameterliste sm bare består av en parameter Dat sm er en in parameter g har type dat g ingen defaultverdi. Generalisering Knseptuelt. Her vil vi si at A er en subtype av B viss alle instanser av A gså er instanser av B. Sånn sett er A en spesiell type av B. Alt vi kan si m A asssiasjner, atributter g perasjner er gså sant fr B. Spesifikasjn. Her er vi hvedsakelig interessert i grensesnitt. Generaliseringen sier hvis A er en subtype av B så vil alle grensesnitt sm finnes i B gså vil finnes i A- grensesnittet i subtypen må være knfrmt med grensesnittet i supertypen. Sagt på en annen måte: Viss jeg har laget kde fr B så kan jeg i stedet sette inn kde fr en vilkårlig subtype av B, f.eks. A. Implementasjn. På dette nivået er vi pptatt av arving. Hvis A er en subklasse av B så arver A alle Bs egenskaper. Oppsummering Hvrdan skal vi bruke klassediagrammer? Ett av prblemene er at det er en svært rik ntasjn. Fwler har nen viktige tips: Ikke prøv å bruke all den ntasjnen sm er tilgjengelig. Bruk de avanserte knseptene bare hvis du virkelig trenger dem. Bruk riktig nivå knseptuelt nivå i analysefasen hva er prblemet - spesifikasjnsnivået når du begynner å tenke prgramvare g implementasjnsnivået når du begynner å tenke på en spesiell måte å implementere løsningen på. Ikke prøv å mdellere alt med en gang hld deg til det sm er viktig. Pass på å ikke kjøre deg fast i detaljer sm bare angår implementasjnen fr tidlig i prsessen Fwler kapittel 5 Sekvensdiagrammer Viser til fig 5-1 i Fwler. Den ntasjnen vi ikke har sett tidligere er: Meldinger g parametere, eventuelt med et iterasjnssymbl knyttet til seg. Iterasjner har syntaksen * [ <årsak til iterasjnen> ] <melding> Betingelser på meldingene. Dette har frmatet [ <betingelse> ] <melding> Start nye bjekter Kall til seg selv return sm viser retur av kntrll, men uten at en melding blir sendt. De kan fr så vidt være med hver gang, men det er frnuftig å la være å tegne de inn hvis de ikke gir ekstra inf eller gjør diagrammet lettere å lese. Sende en melding til seg selv self call. Sekvensdiagrammer er gså viktige fr parallell prgrammering / parallelle prsesser (se fig 5-2 i Fwler). Legg merke til det nye symblet en pil med bare halvt hde. Dette er sekvensdiagrammets ntasjn fr å sende en asynkrn melding. Her ser vi hvrdan en transaksjnskrdinatr starter t kntrllrutiner. Disse kan starte pp g kjøre i parallell. I tillegg sender transaksjnskrdinatren spørsmål / meldinger til seg selv med frespørsel m alle kntrllsprsessene er ferdige all dne? Når det siste sjekk-bjektet er ferdig sender den en stadig asynkrn beskjed m at transaksjnen er OK meldingen bevalid. En asynkrn melding venter ikke på svar g blkkerer derfr ikke det bjektet sm sender den. Generelt kan en asynkrn melding gjøre ett av tre: Starte en ny tråd (thread) Skape et nytt bjekt - en ny instans Kmmunisere med en tråd sm allerede kjører.

40 Tråder (threads) kan være, men behøver ikke være egne prsesser. Dette avhenger av kjøresystemet g perativsystemet. F.eks. vil Linux lage en prsess fr hver tråd, mens Slaris ikke vil gjøre det. Hvis det lages prsesser vil disse avhengig av frhldet mellm antall tråder g antall tilgjengelige CPU er kjøre i parallell eller i kvasiparallell. I fig 5-2 i Fwler ser vi gså bruk av det å stppe / drepe et bjekt. Dette markers med et strt kryss ved enden av livslinja til bjektet. Vi ser at når sjekk-prsessen er ferdige så avslutter de seg selv. I fig. 5-2 i Fwler avslutter de t sjekkprsessene seg selv etter å ha returnert inf m at resultatet av sjekken var OK. I fig 5-3 i Fwler slutter en av sjekkene med at det er ne galt melding Fail g krdineringsprsessen avslutter da den andre sjekkeprsessen uten å vente på resultatet fra den. I fig 5-3 hs Fwler er det gså vist en nyttig detalj tekst på siden av sekvensdiagrammet sm i naturlig språk, beskriver hva sm fregår. Brukt med måte kmmentarer kun til viktige ting vil dette øke lesbarheten til diagrammet. Samarbeidsdiagrammer Vi har sett på samarbeidsdiagram før. Her skal vi bare se på t ting: En frbedret sekvensnummerering Anntering i tillegg til sekvensnummereringen. Vi kan bruke alle de samme ntasjnene sm i sekvensdiagrammene. Iterasjn markeres ved å sette: * [ <årsak til iterasjnen> ] <melding>, mens meldinger sm det er knyttet betingelser til skrives sm: [ <betingelse> ] <melding>. (Se eksempler på dette i fig. 5-4 i Fwler.) I fig 5-4 er det brukt den samme nummereringsmetden sm den vi har sett tidligere. UML har imidlertid innført desimalnummerering fr å kunne vise hvilken perasjn sm aktiverer hvilken annen perasjn (se fig 5-5 fra Fwler). Regelen fr nummerering er sm følger: Hver gang vi går ut fra et bjekt går vi ett nivå ned i nummerering. Hvis vi går ut fra bjekt N vil første melding få nummer N.1, neste få nummer N.2 sv. Vi kan finne kildemeldingen g dermed gså kildebjektet - ved å suksessivt fjerne siste nivå i sekvensnummeret. F.eks. vil melding kmme fra melding sm igjen kmmer fra melding 1.1. All ntasjn sm vi kan sette på et sekvensdiagram settes etter sekvensnummeret i samarbeidsdiagrammet. CRC krt Hensikten med både sekvensdiagrammer g samarbeidsdiagrammer er å vise hvrdan klasser / bjekter samarbeider fr å realisere løsningen på en del av det identifiserte prblemet. Husk at begge diagrammene vanligvis vil være scenarier det blir fr kmplisert på vise alle alternativene i ett diagram. Hensikten med begge diagrammene er å realisere et scenari, beskrevet i et use case. Dersm vi ser på en enkelt klasse må vi i stedet bruke et tilstandsdiagram. Ulempen med både sekvensdiagrammer g samarbeidsdiagram er at de er vanskelige å bruke fr å diskutere alternative løsninger. Vi skal ikke ha diskutert lenge før diagrammet blir uleselig sm følge av endringer, radering / utvisking g alternative streker g symbler. Vi kan frbedre denne situasjnen ne ved å bruke et dataverktøy, men det er vanligvis vanskelig fr mer enn en til t persner å se på en dataskjerm samtidig i hvert fall når vi er avhengig av at alle skal delta aktivt samtidig. CRC-krtet ble innført fr å kunne diskutere løsninger på en enkel g inkluderende måte. At den er inkluderende er viktig hvis vi skal få fatt i all relevant infrmasjn. Ansvar 1 Ansvar 2 Ansvar 3 Ansvar 4 Klassenavn Samarbeider med - a Samarbeider med b Samarbeider med c Hva det betyr: Ansvar: Dette er en høynivå beskrivelse av hva klassen gjør eller hensikten med klassen.

41 Samarbeider med: Dette er andre klasser sm denne klassen må samarbeide med få utført tjenester hs. Legg merke til at et ansvarsmråde kan samarbeide med flere andre klasser. Den videre prsessen består av følgende trinn: 1. Velg ut et use case 2. Definer / navngi klasser sm vi trenger fr å realisere det scenariet sm use caset beskriver. Navn på klassene kan f.eks. hentes fra substantiver i use caset. 3. Se etter hvilke klasser du trenger å samarbeide med. Hvis de allerede finnes så må navnet på din klasse inn sm en samarbeidspartner ikke finnes så må vi definere en eller flere nye klasser 4. Se etter ansvar sm denne klassen må ivareta. Slike mmenter vil kmme fra under veis. Dette kan realiers med en kmbinasjn av: Metder Attributter Fkuser på ansvar på øverste nivå. Det er ikke lurt å fylle på med alle mulige lavnivå ansvar på dette stadium i prsessen. Husk at vi er på knsept eller spesifikasjnsnivå. 5. Frtsett med trinn 2 4 til vi har et sett av klasser sm tilfredsstiller use caset. Det vil / bør bli færre g færre nye klasser g ansvar etter hvert. Hvis ikke det er tilfelle bør vi tenke nøye gjennm det vi hlder på med en gang til ne er antakelig helt galt. 6. Gjenta prsessen fra trinn 1 nytt use case / scenari Når vi har gått gjennm alle use casene g funnet fram til den kmbinasjn av klasser g ansvarsfrhld sm vi trenger, kan vi dkumentere det hele i et interaksjnsdiagram Fwler kapittel 7 Pakker Pakker brukes til å gruppere elementer sm hører sammen hvedsakelig klasser. Det beste / viktigste hører sammen begrepet er avhengigheter. Et pakkediagram innehlder: Pakker / samlinger av klasser Avhengigheter mellm pakkene Avhengigheter har vi sett før. Vi har en avhengighet mellm t klasser dersm en endring i den ene klassen kan føre til endringer i den andre. Eksempler på slike avhengigheter er: Et grensesnitt blir endra Sende meldinger til en annen klasse Bruke en annen klasse sm en del av sine data Bruke en annen klasse sm parameter i en perasjn Vis Fwler fig. 7-1 g kmmenter. Avhengigheter er markert sm før med stipla piler. Vi har avhengighet mellm t pakker hvis vi har avhengighet mellm en klasse i den ene pakka g en klasse i den andre. Legg merke til at pakkeavhengigheter ikke nødvendigvis er transitive. Vi ser at hvis fr eksempel pakke Order endres så behøver vi ikke nødvendig å endre pakka Order Capture UI. Vi må imidlertid sjekke m det er nødvendig å endre Order Capture Applicatin. Denne pakka beskytter Order Capture UI. Det er lurt å ha så få avhengigheter sm mulig mellm pakker. Nyttige råd fra Fwler: La alle klasser ha synlighet privat. Da kan de bare sees av andre klasser i samme pakke. Lag egne klasser sm er public fr det sm skal synes ut av pakka. Disse ekstra klassene kalles en fasade. Det å bruke pakker er ikke løsningen på avhengigheter i systemet. Det er imidlertid en hjelp i å se hvr avhengighetene er. Mange avhengigheter er dårlig nytt fr en del sentrale egenskaper til et prgramvaresystem. Dette gjelder særlig:

42 Vedlikehldbarhet. Endringer blir verre g verre j flere avhengigheter sm finnes. Testbarhet. Mange avhengigheter gjør at det blir vanskeligere å finne ut hver feil kmmer fra. I tillegg vil endringene bli vanskeligere pga lav vedlikehldbarhet. På den andre siden må det åpenbart finnes avhengigheter mellm pakkene, ellers er det ikke et system, bare en masse uavhengig pakker. Vi kan få et mål på graden av avhengigheter ved å se på t tall: Fan-in: antall andre klasser / pakker sm kaller / bruker denne klassen / pakka Fan-ut: antall klasser / pakker denne klassen / pakka kaller / bruker Vi kan sette en grense på tallet Fan-in * Fan-ut sm det ikke er lv å verskride uten en nærmere begrunnelse. På den måten kan man ha en viss kntrll på strukturen. Tallet vil avhenge av hvr gde prsjektdeltakerne er særlig hva slags kmpleksitet de kan handtere. Det er viktig å gså ta hensyn til kmpleksiteten slik at det tallet vi må frhlde ss til er (Fan-in * Fan-ut) 2 * Kmpleksitet. Fr kmpleksitet kan vi bruke enkle ting sm antall linjer eller mer kmpliserte ting sm McCabes kmpleksitetstall. Vanligvis vil lenge være gdt nk. Hvis vi sier at vi maksimalt kan handtere fire kall inn g fire kall ut, når vi har 100 linjer kde finner vi ei øvre grense på Viss vi velger å øke lengden til 500 linjer finner vi at Fan-in * Fan-ut må være mindre enn sju ne sm gjør at vi fr eksempel må redusere Fan-ut til t. Dette gir strengt tatt et ne større tall enn , nemlig Slike tall må brukes med varsmhet g er bare ett av flere hensyn vi må ta når vi tar beslutninger. Fwler, fig 7-2 viser en del nye muligheter. Først g fremst har vi samla Orders g Custmer i ei ny pakke, kalt Dmain. I det generelle tilfellet kan vi beskrive ei pakke på tre måter - Sett navnet i ruta øverst til venstre g innhldet inne i hvedbksen. Dette kan være Ei liste av klasser, sm fr Cmmn Et nytt sett av pakker, sm fr Dmain Et sett av klasser. Vi kan vise avhengigheter på flere detaljeringsnivåer. I Fwler fig 7-2, ser vi at Order Capture Applicatin bare er avhengig av pakka Dmain, mens vi er mer eksplisitte fr pakka Mailing List Applicatin sm bare er avhengig av Custmer. Viss vi setter en avhengighet til ei pakke sm har underpakker sm fr eksempel Dmain så sier vi egentlig at vi har avhengighet til en eller flere av underpakkene. Vi viser imidlertid ikke dette i dette diagrammet. Man må et nivå ned i detaljering fr å se mer pressist hva sm er avhengig av hva. Vi har bruket steretypen <<glbal>>, nederst i fig 7-2. Dette betyr at all pakker i systemet har en avhengighet til denne pakka. Bruk dette med varsmhet. Vi kan bruke generalisering fr pakker sm vist nederst i fig 7-2. Vi har ei abstrakt pakke leg merke til begrensningen {abstrakt} - Database Grensesnitt. Denne viser at vi kan ha enten et Oracle eller et Sybase grensesnitt. Denne ntasjnen impliserer en avhengighet fra subtypene til den abstrakte supertypen. Vi har altså nå ei abstrakt pakke med grensesnitt g andre pakker sm implementerer hvert enkelt grensesnitt. Database grensesnittet er ansvarlig fr å lese g skrive Dmain bjekter til databasen. Unngå løkker i avhengighetsgrafen. Ikke skriv m fr enhver pris det kan være gde grunner til å ha løkker. Det er imidlertid lurt å ha så få sm mulig. Samarbeid i pakker På samme måte sm pakker kan ha klasser kan de gså ha samarbeid. Et samarbeid er en interaksjn mellm t eller flere klasser. Et slikt samarbeid ka vise en perasjn eller realisering av et use case. Se Fwler fig Dette viser et samarbeid mellm tre instanser av klassen Party, kalt henhldsvis Selger g Kjøper 1 / Kjøper 2. Vi kan fte trenge et klassediagram sm viser hvilke klasser sm deltar i et samarbeid. Se Fwler fig Vi ser at salg invlverer tre klasser, nemlig Party, Tilbud g Varemengde. Et samarbeid kan frekmme flere ganger i samme system, men med frskjellige klasser invlvert. Dette kan vi dra nytte av ved å lage et parametrisert samarbeid. UML kaller dette fr et mønster pattern. De sm arbeider med mønster i andre miljøer er ikke uten videre enige i denne rdbruken. Rllebasert mdellering ligger gså i dette mrådet. Trygve Reenskau er en av guruene på dette mrådet med metden OORAM. Se Fwler fig. 7-5.

43 Legg merke til at dette er et rllediagram, ikke et klassediagram. De rllene sm er invlvert står i firkanten øverst til høyre. Det tilsvarende klassediagrammet er vist i Fwler fig 7-6. Nen gde råd Det er lurt å innføre pakker hver gang klassediagrammet blir fr strt. Fwlers definisjn av fr strt er ne sm ikke går inn på et A4 ark. Pakker er et bra nivå fr testing. Det er mulig å teste en g en klasse, men erfaring viser at det er mer effektivt å teste ei pakke av gangen. Det kan værte praktisk å ha en testklasse pr. pakke Fwler kapittel 8 Vi har allerede sett på tilstandsdiagram i nen detalj. Dette er siste strøk g innføring av nen nye elementer: Guard, sm er en betingelse g aktivitet, sm er en aktivitet ms blir utført når vi går ver til tilstanden. Supertilstand, sm er en måte å samle tilstander på. Generering av hendelser event. Parallelle tilstandsdiagrammer. Guard g aktivitet Fwler fig. 8-1 viser flere eksempler på denne knstriksjnen. En guard har følgende syntaks: <hendelse> [<betingelse>] / <aksjn>. Vi kan utelate både hendelse g betingelsen g skriver da / <aksjn>. Alternativt kan vi utelate aksjnen g skriver da [<betingelse>]. Når vi går ver til en ny tilstand kan vi utføre en ny aktivitet. Dette er betegnet med syntaksen d / <aktivitet>. Viss man har en hendelse sm gir en vergang g dette skal føre til en aksjn så kan man vise dette med ntasjnen <hendelse> / <aksjn>. Legg merke til at de tilstandene sm ikke har nen aktivitet, bare har tilstandsnavnet inne i tilstandssymblet. I Fwler fig. 8-2 har vi tatt med en ny tilstand kansellert. Vi har ingen betingelse eller aksjn her, bare hendelsen kansellert. Supertilstander Fwler fig 8-2 ser allerede ne uversiktlig ut selv m det bare er fem tilstander der. Vi skal ikke legge til mange flere før det blir vanskelig å lese diagrammet. Fr å bevare lesbarheten slik at diagrammet virkelig kan fungere sm et kmmunikasjnsmiddel i systemutviklinga er det mulig å innføre supertilstander nærmest et pakkebegrep fr tilstander. Dette er vist i Fwler fig Supertilstander har navn sm står i en egen bks. Det fins t typer verganger ut av en supertilstand: De sm kmmer fra en spesiell tilstand inne i supertilstanden. De blir tegnet på nrmal måte fra den tilstanden de kmmer fra. I Fwler fig 8-3 gjelder dette vergangen til Levert. De sm kmmer fra alle tilstander inne i supertilstanden. De blir tegnet fra supertilstanden. I Fwler fig. 8-3 gjelder dette Kansellert. Genererte hendelser Generell står hendelsene på den kanten sm markerer vergangen til den nye tilstanden. En hendelse i et tilstandsdiagram vergang til ny tilstand - kan bli generert på følgende måter: Etter en spesifisert ventetid. Dette blir markert med knstruksjnen after (<tid>). Dette kan være praktisk fr eksempel fr å frhindre at systemet henger ved at det venter på input. Vi kan bli enige m å vente i maksimalt 10 sekunder før vi går til sluttilstand. Det vil da være en kant fra den tilstand vi er i til sluttilstanden sm er markert med after(10 sekunder). Når en betingelse blir ppfylt. Dette er fr eksempel nyttig i kntrllsystemer g blir markert ved hjelp av knstruksjnen when ( <betingelse>). Viss vi vil gå ver i en ny tilstand når en rbt har aktivert en gitt sensr kan vi fr eksempel skrive when (signal fra sensr 4). De genererte hendelsene kan gså ha en betingelse g en aksjn knyttet til seg. Det kmplette ntasjnen er derfr <nøkkelrd> ( <parameter>) [betingelse>] / <aksjn>.

44 Det finnes t spesielle hendelser entry g exit sm er knyttet til henhldsvis inngang til g utgang fra en tilstand. Viss vi har en transisjn sm går tilbake til samme tilstand vil vi få eksekvert følgende aksjner: 1. aksjner knyttet til exit 2. aksjner knyttet til vergangen 3. aksjner knyttet til entry 4. aksjner knyttet til tilstanden selv, fr eksempel d/<aksjn> Parallelle tilstandsdiagrammer Tar utgangspunkt i Fwler fig Vi starter med å sjekke betaling i den første tilstanden. Dette er indikert med d / sjekk betaling. Dette kan gi t resultater OK eller ikke OK med sine respektive verganger. I Fwler fig. 8-5 har vi kmbinert Fwler 8-1 sm innehlder sjekk, pakk g lever med Fwler fig. 8-4 sm viser betalingsautriseringen. Når vi starter diagrammet vil vi begynne samtidig med å sjekke m vi har varen g m betalinga er OK. Sm før kan betalingssjekken ende med at transaksjnen blir frkasta. Varedelen kan stadig når sm helst bli kansellert. Den av de t tilstandsmaskinene sm er ferdig først vil vente på den andre. Hvis begge når sin sluttilstand vil vi gå ver i tilstanden levert. Nen gde råd Tilstandsdiagrammer er nyttige fr å beskrive ppførselen til et bjekt ver flere use case. Det er ikke så velegna til å beskrive ppførselen til flere samarbeidende bjekter. Det er derfr lurt å kmbiner tilstandsdiagrammer g fr eksempel sekvensdiagrammer. Ikke lag tilstandsdiagrammer fr alle klasser bare fr de klassene der det gir ekstra innsikt eller infrmasjn. Vanligvis er det lurt å lage tilstandsdiagrammer fr brukergrensesnitt g kntrllbjekter kapittel 10 Definisjn: Prgramvarearkitektur er den strukturen sm innbefatter prgramvarekmpnenter, de egenskapene ved kmpnentene sm er eksternt synlige g relasjnene mellm disse kmpnentene. Arkitekturen i et prgramvaresystem har tre ppgaver: Den er et kmmunikasjnsmiddel mellm alle interessenter. Ofte er den på diagramfrm g lett å lese g lett å frstå gså fr brukere. Den dkumenterer mange tidlige designbeslutninger. De tidlige designbeslutningene er viktige frdi de legger mange føringer på hva vi kan gjøre g ikke gjøre seinere i prsjektet. I tillegg vil det påvirke strukturen av prsjektet - fr eksempel WBSen. Siden arkitekturen dkumenterer all viktig funksjnalitet i frm av subsystemer eller funksjner er den en viktig basis fr å utvikle ei prduktlinje en serie av prdukter, basert på den samme arkitekturen, men med variasjner sm avhenger av marked / brukergruppe eller applikasjnsmråde. Når vi skal velge arkitektur er det flere frhld sm spiller inn. De viktigste er: Systemets funksjnelle krav g de datastrukturene systemet skal jbbe med. Dette er frmalisert i metden sm heter JSP Jacksns Structured Prgramming. Utviklingsrganisasjnen vil kunne ha spesielle ønsker ut fra tidligere erfaring, hva sm er vanlig i denne typen rganisasjner etc. Arkitektens tidligere erfaringer med hva sm fungerer g hva sm ikke fungerer. Det er ikke lett å gi pp ne sm har fungert før. Det mrådet systemet skal fungere i. Fr nen mråder kan fr eksempel ffentlige bestemmelser gi føringen på hva sm er lv g ikke lv. I tillegg vil den maskinvaren sm skal brukes ha en del innflytelse, rett g slett frdi nen måter å gjøre ting på vil være enklere / mer effektive. Det er lett å se at de frhldene sm påvirker arkitekturen vil kunne frsterke hverandre. Viss vi har gd erfaring med en spesielle måte å dele pp systemet på vil vi etter hvert kunne få avdelinger sm er spesialister på hvert enkelt subsystem. Da har vi sementert denne arkitekturen g det blir vanskelig å endre den det vil frt kunne kreve en mrganisering av bedriften.

45 Det finnes flere perspektiver på en prgramvarearkitektur. Nen av de vil vi kjenne igjen fra Fwlers bk. Knseptuelt eller lgisk syn. Her ser vi bare på hvedkmpnentene g deres interaksjner. Implementasjnssynet. Her ser vi på mduler eller pakker g lag fr eksempel datalag, beregningslag g lag fr brukerkmmunikasjn. Prsessyn. Her ser vi på systemets dynamiske ppførsel aktiviteter, prsesser, kmmunikasjn mellm prsessene g allkering av prsessene. Dette synet er bare viktig viss vi har mye parallellprsessering. Deplyment synet. Her ser vi på allkering av aktiviteter til fysiske nder, fr eksempel i et nettverk. Dette er bare viktig viss vi har et distribuert system. I tillegg vil det finnes andre, applikasjnsspesifikke syn sm er viktige. Fr eksempel vil det være viktig å ha et sikkerhetsperspektiv viss vi lager et e-handel system. Evaluering av en arkitektur Det er mange faktrer sm spiller inn. Nen viktige er hvr gdt arkitekturen understøtter: Endringer i datarepresentasjnen Endringer i algritmer Endringer i funksjnalitet Separat utvikling av hver enkelt mdul. Frstålighet Ytelse Gjenbruk Når man skal vurdere en arkitektur må man ta hensyn til alle disse faktrene. Alle vil imidlertid ikke være like viktige. Det er derfr nødvendig at man blir enige m hvr viktig hver enkelt faktr er før man begynner med vurderingene. Man kan fr eksempel bruke en skala fra 1 til 10 fr å gi både viktighet g subjektiv vurdering g summere prduktene av de t tallene. Vi vil se på hvert av disse mmentene under. Endringer i data Viktige mmenter er datavlum g datarepresentasjn. Det er ikke sikkert at det er de samme valga sm er frnuftige ved små datamengder sm ved stre datamengder. Ved stre datamengder vil det fr eksempel være aktuelt å ha egne mduler sm henter data, mellmlagrer dem g sjekker dem før man begynner å behandle dem. Det kan gså være lurt å buffre data i dette tilfelle. Datarepresentasjnene vil antakelig endre seg flere ganger i et prdukts levetid. Det kan gjelde både frmat g innhld. Det kan kmme til ekstra datafelt g det kan være endringer fr eksempel fra tall til bkstaver slik det var fr NTNUs karaktersystem. Endringer i datamenge vil fte frplante seg til endringer i algritmer. Det er andre algritmer sm blir effektive fr stre datasett enn fr små datasett. Et eksempel er matriseperasjner. Viss vi skal perere med spredte matriser (stre) matriser der bare nen få elementer er frskjellige fra null er det ikke lurt å bruke de vanlige matrisealgritmene fr multiplikasjn, addisjn sv. Endringer i algritmer Prblemet med å endre algritmer kmmer vanligvis ikke fra algritmen sm sådan, men fra de krava algritmene setter til datarepresentasjn eller den datamengden algritmen er velegnet fr. I sanntidssystemer vil endringer i algritmer kunne være vanskelige frdi det endrer tidsfrbruk i en eller flere mduler. Viss man fr eksempel har 10ms på å gjøre en ppgave g må bruke ei ny algritme sm bruker 12ms så har man i utgangspunktet et prblem. Løsningen kan sette stre krav til hvr lett det er å endre systemet.

46 Endringer i funksjnalitet Det er rimelig sikkert at funksjnaliteten til systemet vil måtte endre mange ganger i løpet av levetiden til systemet. Bare systemer sm er ubrukerlige vil være stabile ver lang tid. Årsakene til endringene er at: Brukernes behv endrer seg etter sm de får mer erfaring med systemet Brukernes krav endrer seg ettersm de ser flere g flere ppgaver sm kan løses ved hjelp av datasystemer Omgivelsene endrer seg bedriftens kunder, lver g regler, hva sm er vanlig i bransjen. Alt dette fører til endringer i funksjnalitet. Siden funksjnaliteten er en av de viktige parametrene når vi skal velge arkitektur vil mange funksjnsfrandringer bli vanskelige. Dette gjelder særlig funksjner sm er spredt ver mange mduler eller subsystemer. Det finnes t måter å resnere på: 1. Vi må frberede arkitekturen på så mange endringer sm mulig slik at endringene blir lette å inkludere. Dette kan vi gjøre fr eksempel ved å parametrisere funksjner. 2. Vi vet ikke på frhånd hvr endringene kmmer. Parametrisering av kde gjør kden mer kmpleks g fører derfr til flere feil. Det er derfr ikke lurt å frberede systemet fr endringer i funksjnalitet. Dere må selv velge hvilken strategi dere vil bruke. Det ser imidlertid ut til at den mest brukte strategien fr øyeblikket er strategi nummer 2. Separat utvikling av mduler Tid til market TTM er blitt en stadig viktigere parameter fr prgramvarebedrifter. Innenfr utvikling av websystemer har kravene blitt ekstreme. En måte å ppnå lav TTM på er å gjøre så mye sm mulig av utvikling g testing i parallell. Dette krever at alle grensesnitt g frdeling av funksjnalitet - hvilken mdul gjør hvilken ppgave - blir klarlagt på et tidlig tidspunkt. Arkitekturen kmmer inn her ved at den bestemmer hvrdan systemet blir delt pp g dermed bestemmer hvilke grensesnitt sm må finnes g hva slags infrmasjn sm skal utveksles. Feil frdeling av funksjnalitet hvilken mdul skal gjøre hvilken jbb vil kunne få katastrfale knsekvenser når kravene til parallell utvikling blir stre. Dersm mange mduler skal bruke de samme dataene må gså datastrukturer defineres tidlig, ne sm igjen vil kunne påvirke valg av algritmene. Frstålighet En arkitektur må være lett å lese g lett å frstå. Dette er viktig fr at alle invlvert skal frstå knsekvensene av all beslutningene sm taes i denne aktiviteten. Dette er spesielt viktig når vi senere skal gjøre frandringer. Det er gså viktig når man skal definere grensesnitt særlig viktig at man her har en felles frståelse av hvrdan funksjnaliteten er frdelt ver systemet hvem har ansvar fr hva. Ytelse Med ytelse kan vi mene tid rask respns eller str lagringskapasitet. Ytelse i betydningen respnstid har i str grad med flytting g tlking av data å gjøre. Alt sm har med bergning å gjøre har utviklet seg mye raskere enn aksess til lagringsmedier sm disk g lignende. Systemer med stre krav til ytelse må rdne seg slik at data når de først er lest blir brukt i alle nødvendige beregninger. Det er uheldig å først laste dataene ned på disk g deretter behandle dem får så å lagre dem m igjen. Ytelse i betydningen behandle stre datamengder setter krav til lagringsmedier g til algritmer frdi vi likevel ønsker rask respns. Gjenbruk Gjenbruk kmmer inn ved valg av arkitektur på t måter: Utvikling med gjenbruk Utvikling fr gjenbruk.

47 Utvikling fr gjenbruk: Det viktigste vi må spørre ss selv m før vi lager ne fr gjenbruk er: Hvr sannsynelig er det at vi kan gjenbruke denne mdulen. Siden det kster ekstra å lage ne gjenbrukbart er dette en investering g må behandles sm det. Det betyr blant annet at vi må ha en idé m når vi får igjen de pengene vi har investert. Valg av mduler vil påvirke arkitekturen g visa versa gjennm ppdelingen i mduler. Utvikling med gjenbruk: Fr at gjenbruk skal fungere kan man ikke først lage arkitektur g verrdna design g så begynne å lete etter passende kmpnenter. Den eneste måten å få dette til å fungere på er å ta utgangspunkt i kundens krav hva skal systemet gjøre fr meg fr så prøve å finne kmpnenter sm gjøre hele eller deler av jbben. Når man har funnet et sett med kmpnenter man vil bruke har man lagt sterke føringer på hva slags arkitektur man kan ha. Beskrivelse av arkitekturer Bka freslår å beskrive arkitekturer på et verrdna plan ut fra følgende faktrer: Prblem hva slags prblem vil vi løse med denne arkitekturen? En krt prblembeskrivelse. Kntekst i hva slags mgivelser skal det systemet sm er lagt på basis av denne arkitekturen fungere i. Dette kan angå både maskinmgivelser maskinvare, databasesystem g perativsystem. Løsning hvrdan ser løsninga ut på et verrdna plan. Arkitekturen kan strt sett beskrives ut fra t elementer: Kmpnenter systemets byggesteiner. Knnektrer hvrdan kmpnentene skal utveksle infrmasjn. Disse t valgene er vanligvis ikke uavhengige. Valg av kmpnenter vil legge begrensninger på valg av knnektrer g mvendt. Varianter av arkitekturen fr å ta vare på spesialtilfeller. Eksempler ett eller t fr å gjøre ideene klarere fr leseren. Bka har flere eksempler sm vi vil gå gjennm, men først må vi se på t kategriseringer av henhldsvis kmpnenter g knnektrer. Mulig kategrisering av kmpnenter: Beregningskmpnenter. Vanligvis enkel input g utput. Vanligvis er de hukmmelsesløse de ppbevarer ikke tilstander, men transfrmerer hver input til en utput etter et sett av frmelle regler. Eksempler er matematiske funksjner. Hukmmelseskmpnenter. Lagring av persistente data sm skal brukes av en eller flere kmpnenter. Eksempler er databaser, filsystemer g symbltabeller. Administrasjnskmpnenter. Dette er kmpnenter sm har et sett av tilstander med tilhørende perasjner. Vanligvis vil de velge perasjner ut fra tilstand hva har hendt før g fra input hva hender nå til å velge ut den riktige perasjnen. Alle systemer har minst en slik fr å velge ut g utføre ppgaver. Kntrllkmpnenter. Disse styrer sekvensen av hendelser i et system. Det er en glidende vergang mellm administrative g kntrllerende kmpnenter, men kntrllere styrer sekvenser, mens administrative kmpnenter strt sett velg ut funksjner. Mulig kategrisering av knnektrer: Prsedyrekall. Dette er en enkelt kntrlltråd mellm t kmpnenter. Kntrllen blir verført til en prsedyre sm gjør en jbb g før eller siden gir kntrllen tilbake. Dataflyt. Hver enkelt kmpnent er styrt av datatilgang. Når en kmpnent ser at det er datadelen skal behandle blir den aktivert, gjør jbben sin g går ver i ventemdus igjen. Jbben vil vanligvis medføre at data endres eller legges til i nye datastrømmer. Implisitt aktivering. En aktivitet blir startet når en definert hendelse inntreffer. Den sm initierer hendelsen vet ikke hvem sm kmmer til å reagere g den sm reagerer vet ikke hvem sm har initiert hendelsen. Meldinger. Et element sender en melding til et annet element med beskjed m å handtere meldinga. Dette kna være synkrnt sender er blkkert til den får svar eller asynkrnt sender frtsetter uten å vente på svar.

48 Delte datamråder. Flere mduler / kmpnenter deler det samme datamrådet g utvekseler infrmasjn ved å lese / skrive data. Vi trenger en mekanisme fr å hindre at t eller flere kmpnenter bruker de sammen dataene samtidig. Instansiering. En kmpnent den sm instansierer skaffer plass fr tilstanden til en annen kmpnent den sm blir instansiert. Bka har flere eksempler på bruk av dette skjemaet vis fig 10.7 til fig Vi vil gå krt gjennm hver enkelt: Hvedprgram med et sett av subrutiner fig Passer best fr utvikling i språk sm Pascal, Mdula II sv. Arkitekturne er et strengt eller svakt hierarki frklar frskjellen. Tegn figur Abstrakte datatyper fig Hver datatype er innkapslet g kmmuniserer med mverdene gjennm et grensesnitt. Hver kmpnent er et bjekt eller en tjener sm tilbyr tjenester. Kntrllen er desentralisert hver pakke kan aktivere andre pakker gjennm prsedyrekall eller meldinger. Implisitt aktivering fig Systemet blir realisert gjennm et sett av prsesser. Prsessene er uanhengige g reagerer på eksterne hendelser. Det må finnes en felles hendelse handteringsmekanisme. Tegn figur. Legg merke til frskjellen fra Abstrakte datatyper. Her er det ingen meldinger fra et bjekt, men en felles handteringsmekanisme sm sier fra når en spesiell prsess skal gjøre ne systemet er hendelsesdrevet. Pipes g filter fig Systemet er realisert gjennm en serie av bergninger / transfrmasjner. Dette er filter sm er realisert sm uavhengige prsesser. Filtrene kmmuniserer ved hjelp av pipes, der man kan sende inn g hente ut infrmasjn. En pipe er en FIFO kø. Avhengig av perativsystemet vi har må vi nen ganger selv passe på å ha eksplisitte sjekker fr tmme g fulle pipes. Felles datalager fig Datalageret er hvedsaken her. Vi ønsker å vedlikehlde et datalager slik at det alltid er ppdatert gir et riktig bilde av nå-situasjnen. Dette er viktig fr lagersystemer i butikker, banksystemer g lignende. Tegn figur. Det vil vanligvis være mange systemer sm pererer uavhengig mt ett datalager. Ofte vil det være transaksjnsrienterte systemer. Lagdeling fig Vi har identifisert et sett av tjenester sm an arrangeres i et hierarki. Hvert lag bruker tjenester på laget under g gir tjenester til laget ver. Akkurat sm fr hierarkiske systemer finnes det en sterk kan bare kalle på nivået direkte under g en svak kan kalle alle tjenester sm ligger under versjn. Tegn figur. En fire lags struktur blir fte brukt: Operativsystemlaget. Her finnes alle rutiner sm gir infrmasjn m maskinens tjenester. Utstyrslaget. Her finnes rutiner fr I/O kntrllere sv. Lgisk ressursstyring. Her finnes abstraksjner av maskinvarebjekter fr eksempel disker g skrivere g prgramvarebjekter. Tjenestelaget. Her finnes applikasjnsfunksjnaliteten. Mange systemer særlig i en klient-tjener arkitektur bruker en trelags mdell. Vi har følgende lag: Datalagring fte en eller annen frm fr database. Datahandtering algritmer fr bergning, transfrmasjner g lignende. Brukerkmmunikasjn alle typer brukergrensesnitt. Avhengig av hvrdan man deler disse lagene på klient g tjener får vi systemer med tykke eller tynne klienter. Tegn figur. En dmenespesifikk arkitektur består av: Referansearkitektur - et spesielt valg av arkitekturstil, men uten det semantiske innhldet i kmpnentene altså hva hver kmpnent gjør. Kmpnentbiblitek gjenbrukbare biter av dmenekunnskap. Disse er resultatet av en eller flere dmeneanalyser. En knfigurasjnsmetde fr å velge ut g knfigurere tilpasse- kmpnenter til arkitekturen slik at det endelige systemet kan tilfredsstille kraven til applikasjnen. Designmønster pattern Et designmønster er en gjentatt struktur av kmmuniserende kmpnenter sm løser et generelt designprblem i en spesifisert kntekst. Først g fremst må vi se på hva et designmønster er g hvrfr det er lurt å ha det. Et gdt designmønster må: Angå et designprblem sm vil frekmme flere ganger.

49 Balansere et sett av mtstridende eller knkurrerende krav. Dette er alltid et prblem i design g et mønster må gjøre dette på en gd måte fr å være interessant. Dkumentere eksisterende, velprøvd designerfaring. Et mønster blir ikke ppfunnet, det utvikler seg etter hvert, basert på praksis i utviklingsprsjekter. Slik sett er det dkumentasjn av beste løsning. Berøre flere kmpnenter g hvrdan de samarbeider. Gi en felles plattfrm ideer, knsepter g begreper å samarbeide ut fra. Slik sett er et mønster en del av et språk fr å snakke m arkitektur g design. Være en måte å dkumentere på. Det må fr eksempel være mulig å dkumentere arkitekturdesignet ved å referere til mønsternavn. Dette frutsetter igjen en generell g felles kunnskap m hva sm ligger i begrepet. Gi et system eller en systemarkitektur sm har definerte egenskaper. Dette gjelder primært funksjnalitet, men ikke-funksjnelle egneskaper vil gså kunne være invlvert. Dette gjelder særlig ting sm fleksibilitet g endring av brukergrensesnitt. Det er vanlig å beskrive et mønster med tre sett av infrmasjn: Kntekst hva skal vi lage g fr hvem? Prblem hva slags prblemer løser dette mønsteret? Løsning beskrivelse av hvrdan mønsteret løser prblemet Andre bruker større, mer avanserte beskrivelser, fr eksempel: Navn hva heter mønsteret Synpsis krt beskrivelse av mønsteret en til tre setninger Kntekst sm før Histrie ( Frces ) hva var det sm ledet fram til å definere den løsningen sm er beskrevet i dette mønsteret. Løsning sm før Knsekvenser hvilke knsekvenser (psitive g negative) får det viss man velger en løsning i henhld til dette mønsteret Implementering ting man må passe på når man skal realisere dette mønsteret Java API bruk viss det finnes eksempler på kde i Javas API kjerne så står de her Kde eksempel innehlder et kdeeksempel fr dette mønsteret Beslekta mønster henvisninger til mønster sm fr eksempel takler beslekta / nærliggende prblemer Det mest kjente designmønsteret sm er laget er MVC Mdell View Cntrler. Dette er ikke frdi det er det beste mønsteret, men frdi det har gått igjen i mange lærebøker. Essensen i dette mønsteret er at det er en gd idé å skille data ( mdel ), måten de presenteres på ( view ) g den nødvendige lgikken ( cntrller ). Vis filer med diagram, beskrivelsen g sekvensdiagram av MVC. Et annet mønster sm er blitt mye bruket er prxy mønsteret. Vis fil. Hensikten her er å kunne bruke et bjekt på en server sm m det lå lkalt gjennm et stedfrtredende bjekt en prxy Kapittel 11 Hvedprblemene med å designe prgramvare er at: Det finnes ikke en endelig frmulering av prblemet. Det er vanskelig å skille design fra Krav sm kmmer før designprsessen Implementering sm kmmer etter. Derfr vil krav design implementering i de fleste tilfeller være en iterativ prsess. Dette har man tatt hensyn til i utviklingsmdeller sm XP g inkrementell utvikling. Siden det ikke finnes en endelig prblemdefinisjn er det heller ikke nen måte fr å finne ut man er ferdig. Det finnes mange kvalitetskrav man kan sette til en design fr eksempel vedlikehldbarhet, testbarhet, frståelighet men det er ikke uten videre gitt at man kan tilfresstille alle. Designer er ikke riktige eller gale. De kan imidlertid være mer eller mindre velegna fr det prblemet vi hlder på med eller mer eller mindre lette å implementere. Endringer i krav eller i implementasjn vil kunne ha stre knsekvenser fr design selv m endringen i utgangspunktet ser liten ut. Vi kan frmulere designprblemet på følgende måte: Hvrdan kan vi dekmpnere et system i deler slik at: Hver del har en lavere kmpleksitet enn det systemet vi startet med

50 Delene løser prblemet når vi setter de sammen. Vi ikke flytter kmpleksiteten fra systemet g delene til måten de er kblet sammen på. Hva er en gd design En gd design kan bedømmes ut fra flere kriterier. Vi vil se på følgende: Abstraksjn Mdularitet Infrmasjnsskjuling Kmpleksitet Systemstruktur Abstraksjn Å abstrahere betyr å knsentrer seg m de viktigste mmentene g ignrere det sm ikke er relevant på dette nivået. I systemdesign perere vi med t frmer fr abstraksjn dataabstraksjn g prsedyreabstraksjn. Vi ser krt på begge: Prsedyreabstraksjn vi kan bryte prblemet ned i prsedyretrinn sm igjen kan brytes ned i nye trinn sv. Eventuelt kna vi bryte prblemet ned i subprblemer sm så igjen brytes ned på nytt til vi enten kmmer til ne vi kjenner igjen eller til ne vi mener det er mulig å løse ved å skrive kde. Denne måten å jbbe på gir en hierarkisk struktur sm vist tidligere. Dataabstraksjn gså kalt bjektrientert design. Dette har vi sett på før. Istedet fr å fkusere på aksjner prsedyrer fkuserer vi på data g deres tilstander. Dette gir andre systemstrukturer med sine frdeler g ulemper. Mdularitet Dette sier ne m sammenhengen mellm kmpnentene inne i en mdul khesjn - g sammenhengen kblingen mellm mdulene. Vi bruker t de t strukturkriteriene khesjn g kbling fr å beskrive dette. Vanligvis vil man tilstrebe sterk khesjn g svak kbling. Dette styrer mange designbeslutninger g gså viktige beslutninger i en arkitektur. Khesjn limet sm hlder kmpnentene sammen i en mdul sammen. Det finnes mange frmer fr khesjn. Vi kan liste de pp etter økende styrke 1 lavest g 7 høyest - på følgende måte: 1. Tilfeldig khesjn kmpnentene i mdulene er gruppert på en eller annen tilfeldig måte. 2. Lgisk khesjn kmpnentene i mdulene er gruppert sammen frdi de lgisk hører sammen f.eks. alle mdulene sm handterer data input. 3. Temprær khesjn kmpnentene i mduler er gruppert sammen frdi de er aktive i same tidsmråde f.eks. alle mdulene sm deltar i initialisering. 4. Prsedural khesjn kmpnentene i mduler sm er gruppert sammen frdi de skal gjennmføres i en gitt rekkefølge fr å realisere en bestemt funksjn f.eks. lese data, ppdatere data g skrive data ned på en fil. 5. Kmmunikasjnskhesjn kmpnentene i mdulen pererer på samme data. Det er imidlertid ikke nødvendig at det frgår i en gitt rekkefølge. 6. Sekvensiell khesjn utput fra en kmpnentene i mdulen er input til den neste sv. 7. Funksjnell khesjn gruppering av alle kmpnentene sm sammen realiserer en funksjn i en mdul. 8. Datakhesjn kmpnentene sm kbler sammen prsedyrer g de data de pererer på abstrakte datatyper er samlet i en mdul. Fr å finne ut hva slags khesjn man har kan man gjøre følgende enkle test. Skriv ned en setning sm beskriver funksjnaliteten eller hensikten med strukturen. Ut fra dette kan man gjøre følgende bservasjner. Viss setningen innehlder: Kmma, g eller mer enn ett verb, har det mest sannsynelig en sekvensiell eller kmmunikasjnsmessig khesjn. Ord sm før, etter sv, så er det mest sannsynelig sekvensiell eller tempral khesjn. Ord sm initialiser l så er det mest sannsynelig en tempral khesjn. Denne testen gjelder bare fr prsedyrer / mduler. Kbling graden av sammenheng mellm mdulene. Akkurat sm fr khesjn finns det mange frmer fr kbling. Vi kan beskrive de fra sterkest 1 til svakest 6 - på følgende måte:

51 1. Innhldskbling en mdul har direkte innvirkning på en annen mdul. Dette kan f.eks. skje viss en mdul direkte kan manipulere data i en annen mdul sm ved bruk av public eller glbale data. 2. Felles kbling cmmn er brukt i FORTRAN fr å definere et felles datamråde. I denne type kbling har flere mduler adgang til et felles datamråde der de kan manipulere et sett av data. Tegn en figur sm viser frskjellen på kbling av type 1 g type Ekstern kbling mduler kmmuniserer gjennm et eksternt medium sm f.eks. en fil. Dette har mye til felles med type 2 kbling( cmmn ). 4. Kntrllkbling en mdul styrer eksekveringen av en annen mdul gjennm kntrllinfrmasjn. Dette gjøres fte ved å sette kntrllparametere i den ene mdulen g bruke de til å styre utføringa i en annen mdul. 5. Stempelkbling data er stemplet med infrmasjn m et felles, kjent frmat. Dette er f.eks. den kblingen vi har mellm mduler sm utveksler pakka data f.eks. i et datanett. 6. Datakbling bare enkle data blir utvekslet mellm mdulene, f.eks. i frm av parametere. Kbling er ikke kmmutativ / gjensidig. A kan være datakblet til B (f.eks. gjennm parameterverføring av ett eller flere heltall) mens B kan verføre kntrllinfrmasjn til A g er dermed kntrllkblet til A. Husk - det er ønskelig å ha str khesjn inne i mdulen g løs kbling mellm mdulene. Tegn aksekrs med navn på nen viktige kblinger g khesjner g vis hvr det er gunstig å være. Sterk khesjn mellm kmpnentene inne i en mdul gjør at det er mulig å frstå kmpnentene g dermed mdulen sm et hele. Sterk kbling mellm mduler betyr at mdulene at det er vanskelig å endre en av de uten å måtte endre mange andre. Dette kalles rippel eller bølgeeffekten. Svak kbling betyr at det er lettere å endre i en mdul uten å måtte endre i mange andre. I tillegg blir det enklere å gjenbruke mdulen. Infrmasjnsskjuling Infrmasjnsskjulig påvirker både kbling g khesjn. Infrmasjnsskjuling fjerner mange av mulighetene fr felleskbling, eksternkbling g kntrllkbling g ppmuntrer til datakbling. Dette skjer frdi den nødvendige infrmasjnen ikke er tilgjengelig den er skjult. På samme måte ppfrdrer infrmasjnsskjuling til å la de kmpnentene sm skal jbbe på samme data ligge i samme mdul datakhesjn eller abstrakte datatyper. Kmpleksitet Bka påstår at kmpleksitet er egenskaper sm bare angår prgramvaren. Det jeg sitter inne med av erfaring tilsier imidlertid at den enkelt utviklers kunnskap g erfaring gså må spille inn. Det sm er vanskelig / kmplekst fr en nybegynner behøver ikke være vanskelig fr en sm har lang erfaring. Det er rimelig å bruke flere frmer fr kmpleksitet: Ekstern kmpleksitet knyttet til kstnadene ved å løse prblemet. Intern kmpleksitet. Sett fra et designsynspunkt vil vi la alle faktrer sm påvirker kstnadene antall timeverk sm er nødvendige fr å lage eller endre en prgramvarekmpnent. Tids- eller plasskmpleksitet den tiden eller plassen kmpnenten bruker på eksekvere. Det er vanlig å snakke m t deler av kmpleksiteten intramdul kmpleksitet sm beskriver egenskaper ved en enkelt mdul g intermdul kmpleksitet sm beskriver frhldet mellm et sett av mduler i et system. Det er grvt sett t sett med parametere sm kan brukes til å estimere kmpleksitet henhldsvis størrelsesbaserte g strukturbaserte egenskaper. Størrelsesbasert metrikker er mål knyttet til mdulens størrelse. Dette er greit definerbare mål. Eksempler på mål sm har vært eller er brukt er: Antall kdelinjer eller kdesetninger. Det siste har den frdelen at det ikke er avhengig av frskjeller i måten å skrive kden på. Antall funksjnspunkter, bjektpunkter (COCOMO II) eller use case punkter. Antall genererte instruksjner

52 Strukturbaserte metrikker er mål knyttet til strukturen av mdulen. Nen eksempler er McCabes syklmatiske tall. Dette er det sm er mest kjent g nest (mis)brukt. Fan-in / Fan-ut Antall knuter i grafen. Kmpleksitetsmål er mstridte både i akademia g industrien. Det finnes ingen generell enighet m at ett mål er bedre enn et annet g deres verdi er tvilsm. Praktisk kna de brukes sm en av flere indikatrer på at en kmpnent eller en mdul begynner å bli kmplisert. Systemstruktur Systemstrukturen består av relasjner mellm mduler. Disse relasjnene kna ta mange frmer, f.eks.: Mdul A innehlder mdul B. Mdul A kmmer etter mdul B etter er her brukt i tempral betydning. Mdul A leverer data til mdul B. Mdul A bruker mdul B. Generelt sett må den infrmasjnen en mdul trenger m en annen mdul i systemet hldes på et minimum. Det er derfr viktig å vite fr hver mdul hvilke andre mduler den bruker. Dette vises i en kallgraf. Vis fig i bka. Det er mulig å måle mange aspekter / egenskaper ved en kallgraf. Nen eksempler er: Størrelsen - antall nder, antall kanter eller summen av begge disse talla. Dybde lengste sti fra rtnde til løvnde. Dette frutsetter at grafen ikke har løkker. Bredde det maksimale antall nder på et gitt nivå. Det blir vanligvis antatt at j nærmere en graf er et tre, dest bedre er det. Viss grafen ikke er et tre finnes det minst en kant sm kan fjernes uten av grafen slutter å være sammenhengende. Vi kan frstsette å fjerne kanter helt til vi får en graf. Resultatet når vi ikke kan fjerne nen kan mer uten av grafen slutter å være samehengende kalles en grafen vi da har fr en spenntre. Antall kanter vi har måttet fjerne er et mål fr hvr langt den pprinnelige grafen var fra å være et tre. Et vanlig mål fr dette avviket er følgende: En kmplett graf med n nder har n (n 1) / 2 kanter. Et tre med n nder har (n 1) kanter. Viss vi har en graf G med n nder g e kanter, vil vi definere urenhetsmålet på følgende måte: m(g) = 2 (e n + 1) / (n 1) (n 2). Fr utledning, se vedlagt lapp. Legg merke til at det ikke alltid er et verrdna mål å få en graf sm er så nær et tre sm mulig. Sm fører dette bare en av mange input i prblemet med å velge en gd designstruktur. Et mye brukt kmpleksitetsmål fr en mdul M er Henry g Kafuras mål: (Fan-in(M) * Fan-ut(M)) 2 sm et mål på kmpleksitet. Vi har sett på dette tidligere. Designmetder Det finnesen str mengde designmetder. Vi skal bare se på tre av de i nen detalj. Dette er: Funksjnsdekmpsisjn Dataflytbasert design Design basert på datastruktur JSP Funksjnsdekmpsisjn I denne metden deler vi systemet pp i funksjner sm skal ppfylle systemets krav. Hver funksjn kan deles pp i nye funksjner sv, helt ned til kde. Dette ligger nær til det vi kaller trinnvis frfining eller detaljering, men fregår på et høyere nivå. Det er vanlig å skille mellm tp-dwn g bttm-up design. Tp-dwn - Vi starter på tppen av systemet g bryter det ned i stadig mindre funksjnsbiter. Fr at vi kan gjennmføre dette helt rigid må vi kjenne all funksjnaliteten på frhånd. Det hadde naturligvis vært kjekt, men inntreffer dessverre sjelden. Bttm-up - Her begynner vi med de funskjnsbitene vi kjenner. frstår eller har tilgjengelig. Deretter bygger vi på tppen av disse fr tilslutt å realisere all den funksjnaliteten sm skal være i systemet. Ingen av disse strategiene kna vanligvis brukes på en rigid måte. Det er flere grunner til dette, bl.a.:

53 Kundene vet fte ikke hel hva de vil ha g selv m de visste det er de ikke alltid i stand til å frklare det på en slik måte at det kan tjene sm grunnlag fr en design I tillegg til kundekravene er det mange andre krav et prgramvaresystem må møte. Dessverre blir disse bare klare etter hvert sm vi jbber med prblemene. De fleste prsjekter vil gjennmgå en eller flere endringer i løpet av sitt liv. Disse endringene er ufrutsigbare. Flk gjør feil I design bruker flk den kunnskapen de har, erfaringer fra det de har gjrt før g lignende. Mange prsjekter bygger på det sm er gjrt før vi lager fte ikke system fra grunnen av, men bygger på / utvider systemer sm eksistere fra før. Systemdesign vil måtte fregå etter y-y prinsippet. Det finnes nen få regler de sm kmmer her er hentet fra David Parnas: Begynn med å identifisere subsystemer. Start med det minst mulige subsystem g utvid etter hvert, inkrementelt Bruk prinsippet m infrmasjnsskjuling bjektbasert utvikling. Legg på utvidelser trinn fr trinn. Bygg systemet lagvis slik at funksjnalitet på ett lag understøtter det sm leggs ver. Bruk uses / includes relasjnen fra UML. Dette gitr et sett av avhengigheter. Prøv å bygge et hierarki ut fra dette. Sm alltid - dette er ikke en sekvensiell kkeppskrift. I stedet må vi se på det sm et sett av trinn sm vi kan gå gjennm en eller flere ganger fr å lage en systemstruktur. Ofte vil systemene få en blanding av lagstruktur g hierarki sm den sm er vist i fig Parnas ide m det minimale subsett sm så senere kan utvides har fått str innflytelse på arbeidet med prduktfamilier. Dataflytbasert design På tppnivå er dataflytbasert design det samme sm funksjnell dekmpsisjn, bare at fkus er på data i stedet fr funksjner. Vi fkuserer på dataflyten. Kmpnentene er i utgangspunktet svarte bkser sm transfrmerer data. Selve designprsessen består av t trinn: Lgisk design ut fra dataflyt. Dette kalles strukturert analyse SA. Det å klarlegge dataflyten er på mange måter en kravanalyse. Siden vi etter hvert legger på mer detaljer i dataflytdiagrammet fretar vi en implisitt tp-dwn funksjnell dekmpnering av systemet. Hvedresultatet av denne aktiviteten er et sett av dataflyt diagrammer. Diagrammene har fire typer av kmpnenter: Eksterne elementer / entiteter. Dette er kilder eller sluk fr en transaksjn. De blir markert med firkanter. Prsesser sm mfrmer data. Disse blir tegnet sm sirkler i diagrammet. Dataflyt mellm t elementer eksterne enheter, prsesser eller datalager. Disse blir tegnet sm linjer med piler sm viser retningen. Datalager sm ligger mellm t prsesser. Dette blir markert med t parallelle linjer med navnet på datalageret mellm linjene. På øverste nivå har vi et kntekstdiagram. Vis fig 11.7 g kmmenter. Deretter kan vi bryte systemet videre ned. Starten på dette er vist i fig Videre nedbryting stpper når prsessene blir så enkle at vi ser hvrdan vi kan realisere de. Erfaring spiller en str rlle her. En slik prsess kalles en minispek. Se fig Resultatet av denne fasen er et sett av dataflytdiagrammer g minispeks. Den lgiske designen blir mfrmet til en prgramstruktur i ett eller flere strukturdiagrammer. Dette kalles strukturert design SD. Siden frrige fase har generert et sett av minispeker sm er prsesser, så vil vi nå kunne beskrive hvrdan vi kan gjøre

54 m en eller flere prsesser til kde. Metden hadde pprinnelig få retningslinjer fr dette, men nen har kmmet til etter hvert basert på erfaring. Se gså fig Metden gir en arkitektur sm klassifiseres sm prdusent knsumer mdellen. Prsesser prduserer data sm neste prsess knsumerer. Slike arkitekturer kan blir ganske kmpliserte. Får å kunne rydde pp prøver man å redusere kbling g øke khesjn mellm grupper av prsesser. Design basert på datastrukturer JSP Hvedmmentet i JSP / JSD er at en gd design gjenspeiler datastrukturen. Siden datastrukturen er mer rbust enn de funksjnelle kravene får man en struktur sm er både lgisk g rbust. JSP bygger på tre basisstrukturer sekvens, iterasjn g valg seleksjn. Se fig Kmmenter hvrdan de tre datastrukturene kan se ut g hvrdan kden passer til å handtere dette. JSP sm metde består av følgende sekvens av aktiviteter: 1. Bruk strukturdiagrammer til å mdellere input g utput. 2. Sett sammen strukturdiagrammene fr input g utput fr å få en helhetlig struktur. Denne strukturen vil autmatisk bli hierarkisk. 3. Løs pp i det Jacksn kaller strukturkllisjner. Dette er tilfeller der vi ønsker å kble sammen t ulike syn i trinn 2 altså input g utput strukturene. 4. Optimaliser kden. I de t metdene vi har sett på tidligere går vi fra prblemstruktur til funksjnsstruktur g deretter til en prgramstruktur. I JSP går vi fra prblemstruktur til datastruktur g så til en prgramstruktur. JSP har hatt fkus på den siste vergangen datastruktur til prgramstruktur. Fr å få en ryddig vergang fra prblemstruktur til datastruktur innførte Jacksn JSD Jacksn Strukturert Design. Denne prsessen består av tre trinn: 1. Mdellering. Dette er en mdell av den delen av verden vi er interessert i - det samme sm en dmenemdell. Se fig Legg merke til symblene fr iterasjn * g seleksjn. Disse diagrammene er tilstandsmaskiner g kalles prsess-struktur diagrammer. Mdellen tar utgangspunkt i elementer i den delen av verden vi er interessert i. Hvert element i diagrammet er en aksjn f.eks. Lån eller Lever tilbake. I tillegg vil hvert av elementene ha attributter. F.eks. vil Lån ha attributter sm beskriver hvilken bk han låner. 2. Nettverk. Her setter vi systemet sammen til et nett av kmmuniserende, parallelle prsesser. Nettverket er et system spesifikasjnsdiagram. JSD har t metder fr kmmunikasjn mellm prsesser: En enhet kan se på tilstanden til en annen enhet. En enhet kan sende en asynkrn melding til en annen enhet via en datastrøm. Disse t kmmunikasjnsmetden har ulike ntasjner. Se på tilstand en ruter med SV inne i g datastrøm - en sirkel med SD inne i. 3. implementasjn. Her gjør vi m nettverket fra trinn 2 til en sekvensiell design. Valg av designmetde Ingen designsmetde gir ss en garanti fr et fantastisk resultat. Det sm teller er kmbinasjnen av metde g våre erfaringer. En gd metde skal hjelpe ss med å gjøre det beste ut av de erfaringene g den infrmasjnen vi har. Det at en metde er beskrevet på en algritmeliknende måte gjør at den er lett å ta i bruk viss den passer fr det vi skal bruke den til. Metder sm er mer deskriptive vil være vanskeligere å ta i bruk, men vil være lettere å tilpasse til det prblemet vi har tenkt å løse. Nen erfaringer: JSP / JSD egner seg best der datadefinisjnene er gitt g statiske. Dataflyt teknikker vil gi ss ekstra hjelp viss dataene er dynamiske. Den passer best der vi skal erstatte et manuelt system med et datasystem. Fig viser en enkel måte å klassifisere designmetder på. Den har t dimensjner: 1. Prblemrientert vs. prduktsrientert. Prblemrienterte metder fkuserer på det prblemet sm skal løses g er menneskerientert. Man kan beskrive, kmmunisere g dkumentere designbeslutninger. Disse metdene vil fte ha aspekter av kravanalyse. Prduktrienterte metder fkusere på en krrekt transfrmering av krav til implementasjn. 2. Knseptuel vs. frmell. Knseptuelle metder er deskriptive g tar utgangspunkt i den verden vi skal mdellere g realisere. Frmelle metder er preskriptive de viser en beskrivelse av det systemet sm skal

55 realiseres. Viss vi har en frmell beskrivelse kan vi gså bevise designet men bare at det er et design av det systemet vi har beskrevet, ikke at det tilfredsstiller kundens krav. De fire kvadrantene har følgende tlking eller hvedfkus: 1. Frstå prblemet få fram en løsning på en frm sm gjør at løsningen kan kmmuniseres, frståes g diskuteres av andre. 2. Transfrmer til implementasjn fra beskrivelse av applikasjnsdmenet til kjørbar kde. 3. Representer egenskaper metder fr å diskutere et prblem g mulige løsninger. 4. Lage implementasjnsenheter er beregnet fr å lage f.eks. kdemduler. Det venstående angår det prblemet sm skal løses hva vi ønsker å ppnå. Det er mange andre faktrer sm gså påvirker designbeslutningene: Dmenekunnskap viss vi har mye dmenekunnskap vil en tp-dwn teknikk basert på datastrukturene være effektiv. Viss vi er i en eksperimentell fase prttyping vil det likevel lønne seg å bruke en bttmup metde. Designernes erfaringer hva har de brukt før. De fleste er mest effektive når de kan bruke en metde de har mye erfaring med fra før. Tilgjengelige verktøy en metde med verktøystøtte vil være å fretrekke viss alt annet er likt. Ttal utviklingsfilsfi hvrdan lager vi system: fra de første brukerintervjuene til drift g vedlikehld. En designmetde sm passer inn i denne ttaliteten vil være å fretrekke. Ntasjner Det er viktig å dkumentere designet man til slutt velger. Det er imidlertid gså viktig å huske p at kden vil bli endra ne sm vil kunne føre til at deler av designet gså blir endra. Dersm vi ikke passer på å ppdatere designet vil kart g terreng snart være frskjellige. Kstnaden med å ppdatere design etter hver kdeendring er en vesentlig kstnad i vedlikehld av prgramvare. T ting kan gjøre dette enklere: autmatisks ppdatering av design når kden ppdateres g autmatisk kdegenerering fra design - vedlikehld av design, ikke av kde. En design vil vanligvis være kmpleks g en enkel diagramteknikk er fte ikke nk. Dessuten er diagramteknikkene ikke rigide vanligvis kan vi tegne det vi vil, uten nen frm fr frmell sjekking. I tillegg trenger vi en gd del beskrivende tekst. Denne kan være krt, lesbar g flertydig eller lang, vanskelig å lese, men rimelig presis. Dkumentasjn av design En design skal ppfylle flere rller i et prsjekt. De viktigste er: Prsjektledelse trenger inf fr å planlegge g kntrllere prsjektet. Knfigurasjnsansvarlig finne ut hvilke kmpnenter sm skal inngå hvr i systemet. Designer funksjnaliteten til hver kmpnent g hva slags grensesnitt hver enkelt kmpnent har. Utviklerne hva skal hver kmpnent gjøre (algritmene) g hvrdan skal den utveksle inf med andre kmpnenter (grensesnitt). De sm utfører enhetstester hvrdan skal kmpnenten ppføre seg fr hver enkelt inputklasse. De sm gjør integrasjnstest hvrdan skal kmpnentene i systemet jbbe sammen fr å realisere kravene til subsystemer g system. De sm gjør vedlikehld hvilke brukerkrav g hvilken funksjnalitet er realisert i hvilke kmpnenter. I IEEE standard 1016 er det spesifisert ti attributter sm hver designenhet kmpnent trenger. Disse er sm følger: Identifikasjn et navn slik at vi kan henvise til den. Type f.eks. m det er et subsystem, en prsedyre eller en fil. Hensikt hvrfr trenger vi denne enheten, f.eks. gjennm å referere til kravspesifikasjnen. Funksjn hva gjør kmpnenten rent knkret, i frm av ppgaver, tjenester. Igjen er det viktig å referer tilbake til kravspesifikasjnen. Deler hva er denne enheten satt sammen av. Avhengigheter dette er både funksjnelle avhengigheter hva må gjøres før / etter denne enheten g definisjnsmessige avhengigheter hva deler denne enheten med andre av data, grensesnittdefinisjner sv. Grensesnitt hva er grensesnittet til denne enheten. Vi må gså si hvrdan den kmmuniserer prsedyrekall, meldinger, sftware bus etc. Ressurser - hva trenger vi av maskinvare, drivere, bibliteksprsedyrer etc.

56 Prsessering hva slags algritme bruker vi fr å få gjrt jbben. Det er viktig å skille mellm dette g funksjn. Data hva trenger denne enheten av data fr å gjøre jbben sin med den valgte algritmen. Her må vi gså ha med datafrmat g interne data. Fr å gjøre det lettere tilgjengelig deler IEEE 1016 denne infrmasjnen pp i tre grupper dekmpsisjn, avhengigheter, grensesnitt g detaljert beskrivelse. Se beskrivelsen i tabell Kmmenter Kapittel 14 Det er vanlig å perere med fire typer vedlikehld: Krrektivt vedlikehld feilretting Adaptivt vedlikehld tilpasninger til endringer i maskinvare, perativsystem, andre systemer dette systemet må kmmunisere med, bedriftens interne rganisasjn g bedriftens mverden. Perfektivt vedlikehld frbedring av kden med hensyn til brukergrensesnitt g tidsfrbruk Preventivt vedlikehld pprydding fr å frbedre vedlikehldbarheten. Se fig 14.1 Vedlikehldbarhetene til systemet / kden er vesentlig fr alle systemer sm skal leve mer enn ett år. Det er mange måter å frbedre den på, både når det gjelder kde, struktur g brukeregenskaper. Dette er nen mmenter: Gd - i betydningen enkel - kde, gd dkumentasjn, kdestandard En endringsvennlig arkitektur. Oppmerksmhet mt kundens behv i alle utviklingsaktiviteter. Hld vlumet av nyutviklet kde nede mindre kde å endre / vedlikehlde. Manny Lehman har frmulert et sett av lver fr prgramvare. De t sm interesserer ss her er sm følger: Kntinuerlig endring et hvert system vil gjennmgå hyppige endringer. Dette vil pågå helt til det er så vanskelig å endre systemet at endringene stpper av seg selv. Deretter vil systemet leve en peride uten å bli endret, fr så å bli erstattet av et nytt system. Økende kmpleksitet etter hvert sm et system blir endret blir det mer g mer kmplekst. Dette fører til at hver ny endring blir mer kstbar g før eller siden vil det ikke bli mulig å frtsette. Disse t lvene sier begge t at det er en grense fr hvr lenge et system kan leve før det ikke lenger kan tilpasse seg en verden i stadig endring. Det er imidlertid flere årsaker til at man nøler med å erstatte dette systemet med et nytt: Fr administrative systemer er det mye frretningslgikk i de eksisterende systemene sm ikke lenger eksisterer i eksplisitt frm andre steder. Det er vanskelig å skaffe prgrammerere med tilstrekkelig applikasjnskunnskap Nyutvikling er kstbart Nye systemer vil innehlde flere feil enn det gamle systemet. I tillegg bytter man feil man kjenner g dermed kan ta hensyn til mt nye feil sm man ikke kjenner g dermed ikke kan passe seg fr. Det kan være vanskelig å lage et nytt system med samme funksjnalitet frdi vi ikke kjenner den ttale funksjnaliteten. Ofte er den heller ikke dkumentert.

57 Ne kan gjøres med enkle midler: Vi kan øke kdens lesbarhet ved å strukturere den bedre prettyprinters. Vi kan få versikt ver strukturen ved hjelp av verktøy sm er spesielt beregnet fr dette frmålet. I tillegg til alt det andre er vedlikehld fte blitt sett på sm en lavstatus jbb, sammen med testing. Dette gjør at utviklere skyr vedlikehld sm pesten g mange vil slutte hvis de får fr mange vedlikehldsppgaver. De fleste føler det sm en karrieremessig blindvei. T løsninger har vært brukt med ne hell: Høyere lønn fr vedlikehldsavdelingen f.eks. 25% i snitt. Dette vil man imidlertid neppe få gjennmslag fr i Nrge. Andre løsninger sm ligner på dette er å la vedlikehldsflk få adgang til ledelsens lunsjrm ne sm har fungert gdt i nen engelske bedrifter Vedlikehld sm en plikt alle i utvikling må være i vedlikehldsavdelingen t måneder i året. Har i det minste den effekten at flk blir mer ppsatt på å lage vedlikehldbar kde siden de vet at de snart må endre i den selv. Reverse engineering Reverse engineering ble på et tidspunkt sett på sm medisinen sm skulle redde ss ut av prblemene med vedlikehld av stre, gamle systemer. Det har dessverre ikke blitt den suksessen sm man trdde. Det er flere grunner til det, men den viktigste er at det er fr vanskelig å finne igjen det sm egentlig var hensikten med kden. Uten den innsikten kan vi bare gjøre ksmetiske frandringer. Disse hjelper, men de løser ikke prblemet. Det vi kan gjøre er å: Bytte ut dårlige navn sm X1 g AB med mer meningsfylte navn sm angår den ppgaven denne variable virkelig har. Gi kden en layut sm gjør den lettere å lese. Dette er en av de tingene vi kan gjøre autmatisk. Sørge fr at de sm endrer ne i kden samtidig rydder pp i det mrådet de er inne i g dkumenterer rdentlig, bla. ved å sette inn kmmentarer. Dette er effektivt, men berører bare små deler av kden av gangen. Generelt sett er endringer farlige frdi de kan innføre nye feil. Det finnes nen typer av verktøy sm vil være til ne nytte i dette arbeidet: Pretty-printers, sm vi har snakka m et par ganger før. Verktøy sm hjelper ss å få versikt ver strukturen til prgrammet. Dette kan være: Enkle verktøy sm tegner kallgrafene eller lager kryssreferanselister Avanserte, hypertekstbaserte verktøy sm hjelper ss å vandre rundt i kden på en effektiv måte. Verktøy sm beregner en del metrikker sm Fan-in / Fan-ut eller McCabes syklmatiske tall. Dette kan hjelpe til med å finne ptensielle prblemmråder i systemet Verktøy fr å måle testdekningsgrad f.eks. kdedekningsgrad eller stidekningsgrad. Selv m disse verktøyene ikke direkte hjelper ss med å strukturere kden, hjelper de ss ved å vise hva salgs knsekvenser endringer har g de viser gså hvrdan dele ar systemet henger sammen. Dynamiske debuggere, gjerne med et grafisk grensesnitt. Ledelsens rlle Bka innfører en typlgi fr prgramvarerganisasjner. Dette er bare relevant fr stre bedrifter. Fr de fleste nrske bedrifter er ikke dett så viktig. Vi vil derfr bare berøre det ganske krt. W bedrifter delt pp etter type arbeidsppgaver, f.eks. en analysedel g en prgrammeringsdel. Vi får flinke spesialister på hver enkelt ppgave, men det er vanskelig å krdinere. Over the wall engineerng er et hyppig prblem.

58 A bedrifter delt pp etter applikasjnsmråde. Igjen får vi dyktige spesialister, men må betale fr det med krdineringskstnader når flere applikasjnsdmener må samarbeide. L bedrifter delt pp etter livssyklus fr systemet. Eksempler er analyse, utvikling, vedlikehld g drift. Prblemene er de samme sm før. Uansett mdell er den viktigste årsaken til prblemene dårlig kmmunikasjn særlig mellm utvikling g vedlikehld. Det å skille utvikling g vedlikehld har både frdeler g ulemper. Frdeler: Greie ansvarsfrhld. Vi får gd versikt ver hvr mye vi bruker til utvikling g hvr mye vi bruker til vedlikehld. Dette hjelper til med å frstå kstnadsbildet bedriften har g hva høy vedlikehldbarhet er verdt. Et alvrlig prblem i all prsjektplanlegging er at flk blir tatt ut av prsjektet fr å gjøre endringer eller rettinger i andre systemer. Ved å ha t avdelinger med hvert sitt ansvarsmråde blir dette prblemet kraftig redusert. Vedlikehldsavdelingen blir sterkt mtivert til å ha gde tester før et prdukt sendes til en kunde. De feilene de finner her kan sendes tilbake til utviklingsavdelingen sm stadig eier prdukter. Hvis det er mye feil i det sm blir levert til kunden blir det vedlikehldsavdelingen sm får alt ekstraarbeidet. Ved å ha vedlikehldsspesialiteter vil det vanligvis bli et bedre g mer effektivt vedlikehld. Ulemper: Siden vedlikehld tradisjnelt er en lavstatus jbb kan man risikere å få bare flk uten ambisjner eller med dårlig kunnskap g erfaring i denne avdelingen. Dette gjør alle vedlikehldsprblemer gradvis verre ver tid. Når ansvaret fr systemet flyttes fra en avdeling til en annen vil vi miste mye erfaring. Selve systemet g dets dkumentasjn er enkel å verføre, men vesentlig inf sm hvrfr vi valgte en spesiell løsning frsvinner i prsessen. Frmell verføring av ansvar fra en avdeling til en annen kster tid g penger. Bedrifter sm har dette skillet har pplevd lange tider med frhandlinger frdi utvikling g vedlikehld ikke kan bli enige m status fr prduktet, hva slags inf sm skal verføres, sv. Kunder sm kjenner utviklingsbedriften har en tendens til å hppe ver vedlikehldsavdelingen de vet j aldri ne likevel g går rett på utviklerne fr å få fikset feil. Dette gir uklare ansvarsfrhld g prblemer med fakturering hvem skal betal hvem fr hva. Eksemplet fra NOVIT. Vedlikehld sm en tjeneste Vedlikehld er en tjeneste g mange kunder ser på leverandørens service - kvalitet g innstilling - sm viktige faktrer når man skal velge leverandør. Fr nen kunder blir det bedømt sm mer psitivt å ha prblemer g få gd behandling enn ikke å ha prblemer i det hele tatt. Når vi selger så selger vi altså både et prdukt g en tjeneste. Hvr mye sm er en tjeneste g hvr mye sm er et prdukt varierer. Fig viser hvrdan dette blandingsfrhldet varierer fr prgramvare. Et viktig hjelpemiddel i analyse av tjenester er gapanalyse gapet mellm det vi yter g det kunden frventer. Fig identifiserer fem viktige, mulige gap sm vi skal kmmentere. Gap 1 gapet mellm hva leverandøren synes er rimelig bra nk g det kunden frventer. Det er viktig fr leverandørene å vite hva kundene frventer. Fr å frstå kundene bedre trenger vi å gjøre markedsanalyser. Gap 2 gapet mellm hva bedriften ønsker å vise fram / yte g interne standarder i bedriften hva de ansatte synes er viktig g riktig. Gap 3 gapet mellm hva vi ønsker å gjøre g hva den enkelte ansatte gjør. Gapet kan kmme av faktrer sm str arbeidsbelastning, lite kunnskap eller generell mangel på interesse. Sm en så vakkert sa det Jeg er utvikler. Jeg utvikler prgrammer. Hva kunden synes m det er ttalt irrelevant. Gap 4 gapet mellm det vi lver i kntrakter, brsjyrer g i kmmunikasjn med kundene g det vi egentlig leverer. Erfaring viser at det er lettere å lve enn å hlde her sm veralt ellers. Dette blir særlig tydelig når bedriftens øknmi begynner å bli trang. Gap 5 dette er den samla effekten av de fire andre gapene.

59 Det er viktig å finne ut hvr frnøyde kundene er med vedlikehldstjenestene vi gir. Dersm de ikke er så frnøyde sm vi ønsker må vi gjøre ne med det. Gapmdellen er en måte å finne ut hva vi skal gjøre g hvr vi skal sette inn innsatsen. Kntrll med vedlikehld Vedlikehld består av minst tre aktiviteter sm må kntrlleres nøye. Her er de listet sammen med nen minimumstiltak fr å klare å hlde hdet ver vannet. Identifiser g klassifiser endringsønsker. Tre ting er viktig. Alle endringsønsker må få en: Id slik at de kan refereres til. Analyse sm knkluderer med at endringen aksepteres vi gjør ne med dette, frkastes dette vil vi ikke gjøre ne med, eller at vi trenger mer inf. Det siste er aktuelt hvis vi ikke frstår hensikten (eller bare ønsker å utsette hele greia). Priritet ut fra en første analyse av viktigheten. Analyse av endringen. Hensikten er å se på knsekvensene av å utfører endringen. Dette gjelder gså knsekvenser fr resten av systemet. Aksepten fra frrige fase er bare midlertidig. Det er viktig å se på mulige løsninger, hva de vil kste g hvr lang tid det tar å implementere den. Implementering. Det sm er viktig her er å passe på at: Endringen får den effekten sm var planlagt. Ikke får andre effekter fr eksempel at det sm fungerte før ikke fungerer lenger. Fr å få til dette er det viktig å ha et gdt testbiblitek g gd sprbarhet mellm tester, kde g krav. Det er nå vi får glede av den innsatsen vi la ned tidligere i prsjektet med å få til gd sprbarhet. Dette pplegget er det samme sm man ser i iterativ utvidelse. Det er rimelig siden skille mellm vedlikehld g utvidelse / videreutvikling er mildt sagt utydelig. Mange bedrifter både leverandører g kunder ser ingen hensikt i å skille mellm de t aktivitetene uansett. Nen bruker spørsmålet m nytte fr å avgjøre prblemet. Nøkkelspørsmålet er: Vil jeg stadig ha nytte av systemet hvis denne endringen ikke gjøres? Ja dette er videreutvikling. Jeg legger på ny funksjnalitet fr å få mer nytte ut av systemet Nei dette er vedlikehld. Endringen er en reparasjn g blir den ikke gjrt kan jeg ikke bruke systemet mer. Dette er ikke en endelig beslutningsmekanisme. Det finnes antakelig mange unntak g / eller tvilstilfeller. I tillegg til dette finnes det en glidende vergang fra videreutvikling til gjenbruk. Det er ikke uten videre lett å avgjøre når man går ver fra å videreutvikle et system til å gjenbruke deler av det fr å lage et nytt system. Det er derfr naturlig å se på vedlikehld videreutvikling gjenbruk, ikke sm tre kategrier, men sm delvis verlappende mråder i et kntinuum. Se fig g fig I tillegg til den relativt rdnede prsessen vi så på, finnes det dessverre gså en annen prsess fte kalt quick fix prsessen. Å kalle den lurvete er antakelig en underdrivelse. Mange av de prblemene man etter hvert får med stre prgramvaresystemer skriver seg fra denne g liknende vedlikehldsprsesser. Når man har gjrt et sett av endringer til et prgramvaresystem er det vanlig å freta en ny leveranse. Denne må tilfredsstille følgende krav: Den funksjnaliteten sm fungerte før må stadig være på plass. De feilene man har ment å rette må være brte Den nye funksjnaliteten må fungere sm planlagt.

60 Det er ikke nk å ppdatere prgramvaren. Hvis det er gjrt endringer, altså ikke rettinger, må man gså ppdatere den dkumentasjnen (fr eksempel brukerveiledningen) sm gjenspeiler endringene. Det er flere måter å planlegge leveranser på. Måten vi gjør det på vil gså avhenge m vi har en - eller nen få - kunder eller m vi leverer et system på det åpne marked: Fast stab g variabel plan. Man har en fast vedlikehldsstab g faste leveranse intervaller fr eksempel hver sjette måned. Man implementerer endringene etter hvert sm de kmmer g tar med så mange sm man rekker fram til neste leveranse. Vi leverer altså alltid i tide, men med varierende innhld. Løsningen er fleksibel, men kundene vet ikke hva de får på frhånd. Variabel stab g fast plan. Man starter med å se på hva man vil gjøre før neste leveranse. Her er det viktig at vi har en klar priritering. Deretter estimerer man nødvendig innsats g setter inn de nødvendige ressursene fr å hlde planen. Kunden får de N viktigste endringene, men han har ingen kntrll ver N. Variabel stab g variable planer. Dette er den mest fleksible måten å drive vedlikehld på. Sm ventet blir den gså den mest kstbare pga. mye planlegging g estimering. Hvilke endringer sm skal gjøres blir avtalt med kunden ut fra dens behv. Ut fra dette blir det laget en plan med tid g kstnader, ne sm igjen vil bestemme antall utviklere vi trenger. Dette pplegget vil gi kunden best muligheter til å påvirke vedlikehldspplegget. Den løsningen vi velger vil avhenge av flere ting, sånn sm: Vår generelle ressurssituasjn. Har vi lite flk å sette på vedlikehld vil den første løsningen være den eneste farbare. Vedlikehldskntrakten. Vi kan ha en kntrakt sm frplikter ss til å ha et visst antall persner engasjert i vedlikehld eller sm frplikter ss til å løse alle prblemer av priritet A innefr et gitt tidsrm sv. Det generelle frhldet til kunden. Fr stre, viktige kunder vil vi vanligvis være innstilt på å yte best mulig service gså når det gjelder vedlikehld. Dette kan tvinge ss til å velge det siste alternativet. Når et system er vedlikehldt ver lang tid vil strukturen gradvis bli dårligere g dårligere. De t viktigste årsakene til dette er at: Vi har ikke tid / råd til å rydde etter ss pga. av press på ressursene. Mange utvidelser går på tvers av den pprinnelige strukturen g burde strengt tatt ført til en restrukturering av systemet sm vi ikke har tid til. Alt dette fører til en ppmagasinering av behv fr å rydde i systemet med jevne mellmrm. Det er flere strategier fr å planlegge dette. Det etterfølgende er bare nen av mange muligheter: Se på khesjn g kbling. Prøv å beveg hver enkelt mdul mt løsere kbling g sterkere khesjn. De beskrivelsene vi så på sist kan være gde retningslinjer. Vurder hvrdan mdulene ligger an i henhld til verdiene på fan-in / fan-ut. Vurder først de mdulene med de største verdiene. Se på endringstrafikken. De mdulene der det er endret mest enten i antall ganger eller i prsent av antall linjer endret er de mest ppulære kandidatene fr pprydding. Vær imidlertid klar ver at det fte er frskjell på hvr vi endrer g hvr vi burde ha endret. Dette avhenger bla. av hvr enkelt det er å endre den eksiterende kden. Det finnes altfr mange eksempler på at kde sm burde vært endret ikke blir det frdi ingen tør. I stedet endrer man i andre mduler fr å få fram den ønskede effekten.

61 Det er neppe lurt å bruke disse reglene slavisk. Se på de sm en måte å styre ppmerksmheten på. Før man endelig bestemmer seg fr hva man skal gjøre bør det nk en mer detaljert analyse til Kapittel 6 Det er t sider ved kvalitet prdukt g prsess. Hvedsaken er prduktet, men det ligger underfrstått i mye av kvalitetsarbeidet at vi får gd kvalitet på prdukter ved å ha en gd prsess. Før vi ser mer på dette må vi definere kvalitet. ISO har definert kvalitet på følgende måte: Helheten av egenskaper en enhet har g sm vedrører dens evne til å tilfredsstille uttalte g underfrståtte behv Det finnes gså andre definisjner på kvalitet, fr eksempel: Egnethet fitness fr use. Denne definisjnen er i slekt med ISO definisjnen. Overensstemmelse med kravspesifikasjn ingeniørdefinisjnen. Den har den frdelen at den til en viss grad er bjektiv. Ne fltt. Dette er ppulærdefinisjnen. Etter denne definisjn vil fr eksempel en BMW ha høyere kvalitet enn en Vlv, mens dette ikke behøver å være tilfelle med de andre definisjnen Det er t ting vi må legge merke til: Målet er å tilfredstille kundens behv. Uten kunde er det fåfengt å snakke m kvalitet. Kvalitetsvurderingen er derfr avhengig av hvilken kunde vi har med å gjøre er sm sådan rent subjektiv. Definisjnen inkluderer både eksplisitte uttalte g implisitte underfrståtte behv. De eksplisitte behvene kmmer fra krav, men de implisitte behvene strt sett kmmer fra kunnskap g frventninger knyttet til dmenet. Ut fra det faktum at kvalitet er en subjektiv ppfattelse følger at mange av de viktige kvalitetsmålene gså må være subjektive. Det er likevel et behv fr å kunne måle / vurdere kvalitet, både når vi lager kravspesifikasjn g når vi skal gdkjenne / akseptere et nytt system. Vi kan ikke frstå det vi ikke kan måle sa lrd Kelvin. På en annen side Vi kan ikke måle det vi ikke frstår sm en eller annen frustrert utvikler frmulerte det. Derfr frståelse g måling må skapes ver tid g i en iterativ prsess. Fr å kunne snakke m prduktkvalitet på en ryddig måte trenger man en nedbryting av begrepet i et sett av underbegreper. Den vanligste måten å gjøre dette på er å lage en faktr kriterier metrikker mdell. En av de eldste, men stadig mye brukte, slike mdeller skriver seg fra McCall. ISO har definert g standardisert et sett med kvalitetsattributter. De fleste faktrene er de samme sm hs McCall, men de er rganisert på en annen måte. ISOs måte å gjøre dette på er samlet i standarden ISO Vi vil se på hvert enkelt attributt, hva det betyr g hvrdan man kan vurdere eller måle nen av de. Vis fig fra ISO den lista vi ser på er ne frskjellig fra den lærebka bruker, men den er i det minste knfrm med ISO Funksjnalitet systemets evne til å gi funksjnalitet sm tilfredsstiller eksplisitte g implisitte behv Pålitelighet systemets evne til å ppretthlde sin ytelse Brukbarhet hvr lett er det å lære å frstå hva systemet gjør g hvr gdt liker brukerne systemet Effektivitet hvr gdt ppretthlder systemet sin ytelse fr en gitt tilgang på ressurser. Vedlikehldbarhet hvr lett er det å endre systemet Bærbarhet - hvr lett er det å flytte systemet fra en mgivelse til en annen Dette kalles kvalitetsfaktrer. Hver enkelt faktr er definert av et sett av kriterier. Disse er sm følger: Funksjnalitet Nøyaktighet resultat sm er riktig eller i henhld til en avtale. Egnethet et sett av funksjner sm er egnet til å kunne brukes fr å løse brukerens prblemer / ppgaver.

62 Overensstemmelse verensstemmelse med gitte standarder, regler g knvensjner i det gitte applikasjnsmrådet. Sikkerhet (i betydningen security) hindre uautrisert tilgang til å se eller endre data. Dette gjelder både tilgang sm følge av angrep g sm følge av uhell. Pålitelighet Mdenhet ikke feile pga. feil i kden. Feiltleranse fungere sm planlagt selv m den får feil input eller blir brukt på feil måte. Recverability kmme raskt pp igjen g miste få / ingen data eller transaksjner. Reparasjn. Tilgjengelighet være tilgjengelig når vi trenger systemet. En funksjn av feilrate g reparasjnsrate (MTTF g MTTR). Brukbarhet Frståelighet hvrdan kna systemet hjelpe meg med å få gjrt mine ppgaver. Lett å lære lett å lære seg å bruke systemet til å få gjrt sine arbeidsppgaver. Lett å bruke lett å få gjrt det man ønsker, lett å kntrllere systemets ppførsel. Ingen negative verraskelser. Effektivitet Tidseffektivitet rask respnstid Ressurseffektivitet - bruke de tilgjengelige ressursene (plass, sekundær lagring, etc) på en effektiv måte Vedlikehldbarhet Analyserbarhet lett å finne ut hvr en feil er eller hvr vi må endre fr å få til en gitt effekt. Dette er i str grad en funksjn av sprbarhet, khesjn g enkel kde. Endringsvennlighet hvr lett er det å endre i kden. Stabilitet lett å endre ett sted uten å få en masse uventa effekter rundt mkring. Dette er i str grad avhengig av sterk khesjn g svak kbling. Testbarhet hvr lett er det å sjekke at vi har ppnådd det vi ville med endringene uten å ødelegge det sm fungerte før. Bærbarhet Tilpassningsdyktighet kan enkelt tilpasses til nye mgivelser, så sm nye perativsystemer, nye nettverksløsninger sv. Installerbarhet lett å installere, både i det planlagte miljøet g i et nytt miljø Sameksistens kunne eksisytere / fungere sammen med andre systemer uten å lage prblemer. Knfrmitet verensstemmelse med standarder g knvensjner (gd prgrammeringsskikk) sm angår bærbarhet Erstattbarhet kan erstatte (bli brukt i stedet fr) annen prgramvare med samme funksjnalitet sm allerede finnes i systemet. ISO hadde sm mål å gså definere et sett av metrikker sm gjrde at man på en entydig måte kunne gi tallverdier til hvert enkelt kriterium, men det viste seg at det var umulig å bli enige m et slikt sett av metrikker Ved å rangere hver enkelt faktr kan vi kmme fram til en verdi sm sier ne m kvaliteten på prduktet. Dette kan brukes til å sette krav til prduktkvaliteten. Vi kan fr eksempel gjøre følgende: Hvert kriterium i gies en vekt W i. Vi definerer en evalueringsprsess test eller annet sm kan gi kriteriet en verdi mellm 0 ikke til stede i det hele tatt til 1 kravene er helt ppfylt. Dette er kriterieverdien C i. Eventuelt kan vi ha flere mål sm kmbineres - metrikkene M ij. Kvalitetstallet blir da gitt sm Sum(W i * C i ) Et alternativ er å stille spesifikke krav til hver enkelt kvalitetsfaktr. Dette er vanligvis enklere, både fr kunde g utviklere. Et eksempel er sm følger: Funksjnalitet systemets evne til å gi funksjnalitet sm tilfredsstiller kundes behv Velg ut 5 brukere. Disse skal bruke systemet i tre dager g deretter gradere funksjnaliteten på en skalla fra til 5. Minst 3 skal gi en karakter på 4 eller 5 g ingen skal gi det en karakter dårligere enn 3. Pålitelighet systemets evne til å ppretthlde sin ytelse Ingen feil skal inntreffe i løpet av tredagersperiden der vi tester funksjnaliteten. Brukbarhet hvr lett er det å lære å frstå hva systemet gjør g hvr gdt liker brukerne systemet Brukerne i funksjnalitetstesten skal få et en dags kurs i å bruke systemet. Deretter skal de fylle ut et spørreskjema sm sjekker deres frståelse. Ingen skal få mindre enn 75% riktig på denne undersøkelsen.

63 Effektivitet hvr gdt ppretthlder systemet sin ytelse fr en gitt tilgang på ressurser. Respnstiden på den avtalte knfigurasjnen skalregistreres autmatisk under hele testperiden. Midlere respnstid skal være 0.1 sekund. Ingen transaksjn skal ta mer enn 2 sekunder. Vedlikehldbarhet hvr lett er det å endre systemet. Leverandøren vil få tilsendt t endringsønsker angående layut av skjermbilde etter en dag av testperiden. Etter at leverandøren har akseptert endringene skal endringen være tilgjengelig fr brukerne etter en dag. Bærbarhet - hvr lett er det å flytte systemet fra en mgivelse til en annen Ingen spesielle krav. Uansett hvilken måte vi velger å spesifisere kvalitetskravene på er det viktig å huske at det sm vi ikke setter testbare krav til, det frå vi ikke ppfylt. Flere av de definerte kvalitetsfaktrene er generelt i mtsetning til hverandre det er vanskelig å ppnå alle samtidig. Skal man få høy skår på det ene er det ikke nødvendigvis slik at man kan få høy skår på alle andre. Vis fig. 6.7 g kmmenter. Dette er riktignk McCalls mdell, men ideen er generell. Perspektiver på kvalitet Vi har allerede sett ISOs definisjn g så vidt berørt et par andre definisjner. Her skal vi prøve å være litt mer systematiske. Bka snakker m fem perspektiver vi kan ha på kvalitet: Transcendental det uutsigelige. Jeg vet hva kvalitet er, men jeg kan ikke frklare det. Jeg kjenner det igjen når jeg ser det. Brukerbasert egnethet fr bruk. Hvr gdt tilfredsstiller prduktet mine behv. Prduktbasert fr eksempel lav kbling g høy khesjn, lett lesbar kde, laget i henhld til gd utviklingsskikk. Prduksjnsbasert her heller utviklingsbasert i verensstemmelse med de beskrevne krav. Ofte kalt ingeniørdefinisjnen. Verdibasert - lønner det seg å ta dette i bruk, tjener jeg mer enn det sm det kster meg å kjøpe g drive systemet. ISO prøver å ta pp i seg alle disse perspektivene unntatt det første. Det siste perspektivet verdibasert er imidlertid ikke så altfr gdt ivaretatt. Den verdien vi får ut det å ta i bruk et nytt system kan være flere ting. Det etterfølgende er nen eksempler: Økt effektivitet spare penger Økt effekt bedre infrmasjn g bedre grunnlag fr å ta gde beslutninger, bedre resultater generelt. Ekstra verdi vi kan gjøre ting vi ikke kunne gjøre før. Nytt prdukt vi kan lage / selg ne vi ikke kunne lage / selg før. Dekker både prdukter g tjenester. Bedre struktur på inf. Vi kan få mer ut av de andre systemene i bedriften sm bruker eller gir inf sm vi trenger idet daglige arbeidet. Kvalitetssystemer Hvedhensikten med et kvalitetsystem er å Ha ryddige kntraktsfrhld. Dette inkluderer en ryddig spesifikasjn av hva sm skal gjøres. Dette impliserer ikke at all funksjnaliteten må være bestemt på frhånd. Det er fr eksempel fult mulig å ha en kntrakt sm bestemmer at man skal ha et frprsjekt der man definerer kravene til systemet eller en kntrakt sm sier at man skal bruke XP, sm er en ekstremt iterativ g inkrementell utviklingsmdell. Gi trygghet fr at kunden får det han er lvet både når det gjelder prdukt (det han får til slutt) g prsess (måten vi lager det på). Tilliten kmmer primært fra prsessen. Vi kan ikke velge en leverandør ut fra detaljkunnskap m de flka han setter til å gjøre jbben. Vi kan imidlertid velge ut fra graden av ryddighet i prsessen. Standarden skal sørge fr at vi har en prsess sm gjør at vi fkuserer på å ppfylle kundens krav både de funksjnelle hva systemet skal gjøre g de ikkefunksjnelle kravene hvrdan systemet skal gjøre det. Fig 6.10 viser innhldsfrtegnelsen fr standarden ISO Se gså vedlegg A i bka. Denne standarden er imidlertid laget fr all prduksjn av varer g tjenester. Prblemet vårt er at prgramvare ikke blir prdusert på

64 samme måten sm jagerfly eller lenestler den blir utviklet. Når det gjelder prduksjn sm strt sett går ut på å brenne CD-er er prgramvarebransjen verdens beste g mest effektive bransje. Kvalitetsystemer fr prgramvare ISO 9001 er en generell standard. Fr å få den mer tilpassa til prgramvare er det laget en veiviser fr bruk av ISO 9001 i prgramvare. Denne heter ISO bka har imidlertid valgt i stedet å se på IEEE Std 730. denne finnes i appendiks B i lærebka. Innhldsfrtegnelsen fr denne standarden er vist i fig Vi skal gå krt gjennm de viktigste punkta i denne standarden. Hensikt hvilket prdukt angår denne planen. Frskjellige prdukter vil ha frskjellige planer, bla. frdi knsekvensen ved å feile er frskjellige, kundens krav er frskjellige sv. Refererte dkumenter hvilke dkumenter refererer denne planen til. Ledelse hvem er ansvarlige fr hva i prsjektet. Her finner vi ledelsesstruktur, kmmandstruktur, hvem sm kan ta hvilke beslutninger, hvem sm kan gdkjenne hva sv. Dette inkluderer gså hvem sm kan beslutte at vi skal kunne ta snarveier gjennm systemet. Dkumentasjn hvilke dkumenter skal lages, hvrdan skal de se ut, hvrdan skal de gdkjennes. Følgende er minimum: Kravspesifikasjn Designbeskrivelse Testplan Testrapprt Brukerdkumentasjn Knfigurasjnsstyring Standarder, praksis, knvensjner g mål hvilke standarder skal gjelde, regler fr gd praksis g knvensjner. Dette kan inkludere alt fra kdestandarder til navneknvensjner fr dkumenter. Det må være med en beskrivelse av hvrdan vi skal sjekke at reglene / standardene blir fulgt. Gransking g revisjner hvrdan skal granskinger g revisjner utføres. Dette gjelder både fr dkumenter (inklusive kde) g fr QA planen. Testing hvrdan skal vi teste mduler, subsystemer g systemet. Ofte kan vi klare ss med en henvisning til testplanen. Rapprtering g retting krrektive tiltak. Prsedyrer fr å rapprtere feil g sørge fr at de blir behandla på en riktig måte analysert, priritert g retta. Verktøy teknikker g metder hvilke skal vi bruke i dette prsjektet. Alle verktøy, metder g teknikker må være beskrevet. Fr verktøy må det gså være med versjn, slik at alle bruker det samme. Kdekntrll hvrdan vi tar vare på kde, sørger fr at det sm er gdkjent ikke blir endra uten at de sm skal bruke den får beskjed, hvem sm er ansvarlig fr dette. Mediekntrll hvrdan beskytter vi de fysiske mediene så sm disker, disketter, CD-er g taper Kntrll ver underleverandører hvrdan sikrer vi kvaliteten til de sm utvikler deler av systemet fr ss. Det blir mer g mer vanlig at bedrifter gjør det de er gde til g så setter de brt resten til andre bedrifter. Det er flere måter å gjøre det på, fr eksempel Stille krav til underleverandørens QA-plan Stille krav til underleverandørens testprsedyrer Ha en persn utplassert der fr å sjekke at de jbber rdentlig i henhld til avtalte prsedyrer g metder Data innsamling g lagring hvrdan blir QA aktivitetene dkumentert g kntrllert basert på innsamla data Opplæring hvilken pplæring er nødvendig fr at denne QA-planen skal virke. Ofte er dt nødvendig å lære utviklerne teknikker ms dkumentgransking, innsamling av testdata sv. Dette må planlegges på frhånd, bla. fr å sikre at det blir satt av ressurser til det. Risikstyring hvrdan blir risik handtert i QA. Legg merke til at risikanalysen er gjrt i prsjektplanen. Her er det snakk m hvrdan vi aktivt bruker resultatet av risikanalysen i løpet av prsjektet. Det å ha en QA-plan garanterer ikke et gdt resultat. Det er ingen erstatning fr kmpetente utviklere, et gdt prgrammeringsspråk g gde utviklingsmgivelser. Det kmmer i tillegg til at dette fr at hver enkelt i prsjektet skal kunne bidra til et gdt sluttresultat på den mest mulig effektive måten. I det øyeblikket vi begynner å gjøre ting bare frdi det står i QA-planen er vi på ville veier. Hensikten er å gi kunden et best mulig prdukt til avtalt tid g kstnad. Det sm kmmer i tillegg bør man se svært nøye på. Nyttige ting sm kmmer i tillegg kan fr eksempel være at:

65 Bedriften / utviklerne skal lære av erfaringene på en systematisk måte Vi ønsker å frbedre prsessen Vi ønsker å lage kmpnenter 7 subsystemer sm vi skal gjenbruke i senere prsjekter Alt dette må imidlertid være planlagt. Det er dumt å gjøre en masse ekstraarbeid frdi det muligens kan kmme til nytte Kapittel 17 Fr å få til gjenbruk må vi se på tre viktige faktrer: Gjenbruk av kmpnenter Gjenbruk av design Lim fr å sette sammen kmpnenter. Alternativt kan vi se på det bka kaller dimensjnene til gjenbruk. Frfatteren pererer med seks dimensjner: Substans det man gjenbruker. Dette er kmpnenter i en eller annen frm. Kmpnentene kan angå prdukt eller prsess: Prduktkmpnenter kan være alt fra subsystemer til små kdesnutter. Kmpnentene kan være generiske fr eksempel en praktisk datastruktur eller spesialiserte ting. Prsesskmpnentene kan være beskrivelser av hvrdan man gjør deler av en jbb, fr eksempel hvrdan man bør gå fram når man skal gjøre kdegranskning. Scpe vi skiller mellm hrisntal g vertikal gjenbruk. Vi ser at j smalere dmener vi pererer med, dest bedre sjanser får vi fr at det vi lager kan gjenbrukes i nye systemer i dette dmenet. Derimt vil så spesialiserte kmpnenter ha liten sjanse fr gjenbruk utenfr dmenet. Hrisntal gjenbruk er gjenbruk av generelle kmpnenter fr eksempel et matematisk biblitek. Vertikal gjenbruk er gjenbruk av dmenespesifikke kmpnenter, fr eksempel gjenbruk av en lageradministrasjnsrutine når vi lager et nytt lagersystem. Tilnærming vi pererer med t frmer fr gjenbruk: Planlagt, systematisk her identifiserer vi kmpnenter sm skal lages gjenbrukbare g legger ekstra innsats ned i dkumentasjn g testing. Dette må sees på sm en investering g behandles deretter. Opprtunistsk, ad hc flk gjenbruker det de måtte ha liggende av kde. Det de gjenbruker er ting man gjør i løpet av mange prsjekter, så sm I/O rutiner. Unix filsfi med pipes g filter passer gdt inn her. Teknikk igjen har vi t metder: Kmpsisjn vi setter sammen eksisterende kmpnenter til et nytt system. Hvedprblemet er å finne passende kmpnenter, enten frdi de er vanskelige å identifisere eller frdi vi ikke har de. Generativ. Her gererer vi nye kmpnenter ut fra fr eksempel patterns. Bruk. Her skiller vi mellm. White bx gjenbruk. Her endrer vi deler av kmpnenten. Dette skal gjøres med frsiktighet. Data indikerer at viss vi endrer mer enn 25% avkden er det like billig å lage kmpnenten på nytt. Black bx gjenbruk. Kmpnentene brukes sm den er. Ofte er dette COTS kmpnenter, der vi ikke en gang kjenner innhldet bare grensesnitt g (deler av) funksjnalitet Prdukt hva gjenbruker vi. Mulighetene er mange kildekde, design, arkitektur, klasser sv. Det er imidlertid mest vanlig å gjenbruke kde. Imidlertid er det en økende trend mt å bruke design patters etter sm disse blir gjrt kjent. Vi vil se på gjenbruk av frskjellige typer av artefakter. Dette inkluderer: Bibliteker. Maler Design Arkitektur

66 Bibliteker Den største suksessen her er gjenbruk av matematiske bibliteker. Viss vi sjekker hvrfr dette er vellykka finner vi følgende mmenter: Standardisert terminlgi. Dette skyldes at fagfeltet er veletablert med et felles vkabular. Lite, veldefinert grensesnitt fr de fleste funksjner. Det er almen enighet m hva slags inf sm skal inn g hva vi får ut igjen. Det enste sm skiller er inf m feilhendelser, udefinert input sv. Standardisert datafrmat vi trenger srt sett heltall g reelle tall g de har begrensa variasjnsmuligheter. I de tilfellene de mmentene sm er nevnt ver ikke er tilstede, blir det mer vanskelig. Generelt har man identifisert fire viktige mmenter: Søking etter kmpnenter det å finne riktig kmpnent er kritisk. Vi kan ha enkel søking sm setter krav til valg av riktige søkerd, eller vi kan ha en avansert søkemekanisme, sm vil sette stre krav til metden fr å legge inn nye kmpnenter. Frstå kmpnenter fr å gjenbruke en kmpnent vil vi gjerne frstå hva den gjør. Dette gir tillit g uten tillit til kmpnentene tør vi ikke gjenbruke de. Tilpassing av kmpnenter viss ikke kmpnenten er direktegjenbrukbar må vi mdifisere den dette stiller stre krav til vedlikehldbarhet viss det skal lønne seg. Sammenstilling hvrdan skal vi lime sammen kmpnentene. Når man lagrer kmpnenter i en database bruker man fte metder fra bibliteker særlig frskjellige frmer fr indeksering. Fig viser et eksempel. Begrepene har følgende betydning: Ukntrllerte indekser vi kan velge de termene vi har lyst til. Kntrllerte indekser kan være: Ei liste av lvlige rd nøkkelrd. Et klassifikasjnsskjema definert sm en trestruktur. Selv m det begynner sm en trestruktur går det vanligvis raskt ver til å bli et nettverk pga. multippel klassifikasjn. Det viser seg vanskelig å få til et pplegg sm både er effektivt å søke i g lett å legge inn nye kmpnenter i. Et nett med fasetter gjerne med frskjellige vekter avhengig av hvr nær hverandre begrepene er gir en effektiv søk, men kstnadene ved å legge inn nye kmpnenter er høy g øker fr hver ny kmpnent sm legges inn. Når vi skal velge m vi vil gjenbruke en kmpnent eller ikke er det mange ting sm er viktige i tillegg til hva kmpnenten gjør. Dette gjelder bla. Kvalitet hvr lett er kmpnenten å endre, hvr rbust er den mt feil input sv. Administrativ inf hvem har laget denne kmpnenten, hvr / til hva har den vært brukt før, hva slags erfaringer har andre med denne kmpnenten, sv. Dette er innfr sm gir tillit til kmpnenten. Dkumentasjn vanlig prgramvaredkumentasjn, særlig viktig fr vedlikehld / endringer. Beskrivelse av grensesnitt hva slags parametere, hva slags datafrmat sv. Testinf. Dette kan både være testlgger fra tidligere tester, nyttige tester å kjøre sv. Generelt sett vil det være mer å tjene på gjenbruk dess større kmpnenten er. På den andre siden er det vanskeligere å finne stre, gjenbrukbare kmpnenter, særlig frdi vi ikke ønsker å ta med ss en masse funksjnalitet sm vi ikke trenger. Stre kmpnenter er fte spesialiserte g derfr vanskelig å gjenbruke. Fr å kmme i gang med gjenbruk må nen fylle bibliteket med gjenbrukbare kmpnenter. Dette er en kritisk suksessfaktr. Når flk søker i bibliteket g ikke finner ne de kan bruke vil de snart slutte å bruke det. Vss de derimt finner ne nyttig vil de bli mtivert til å søke flere ganger g bli mtivert tikl å legge inn nye kmpnenter. På den måten kan vi få en gd sirkel. Maler Maler faller i t kategrier: Dkumentskjeletter fr rapprter, prgramvaredkumentasjn, brukerdkumentasjn sv. IEEE standardene faller i denne kategrien. Kdeskjeletter ufullstendig kde sm er knyttet til spesielle applikasjnstyper. Dette er kde sm er halvferdig utvikleren må fylle inn resten. Fr eksempel kdeskjelett får å lese ei pakke fra en fil, velge aksjn ut fra et typefelt i pakka g skrive ny inf ut på ei ny fil.

67 Design Det er en flytende vergang mellm gjenbruk v8a kdeskjeletter g gjenbruk av en design. Mange bruker til g med kdeskjeletter til å dkumentere design. Ofte vil man ha ferdige prsedyreskjeletter eller klassestrukturer sm definerer de verrdna designet. Utviklerne må fylle inn kde selv. Vi kan gså gjenbruke design i frm av sekvensdiagrammer, gjerne kmbinert med klassediagrammer. Arkitektur Vi har stadig de samme basisideene sm ved maler g design, men har flyttet ss et trinn ppver i abstraksjn. Det finnes få vellykka eksempler på gjenbruk på dette nivået. Gjenbruk g livssyklus Det finnes t viktige aktiviteter her. Begge pererer strt sett på kmpnentnivå. Utvikling med gjenbruk. Vi finner gjenbrukbare kmpnenter i en skuff eller i en database. Vanligvis er dette ne vi eller nen andre har laget før, men ikke nødvendigvis fr at nen skal gjenbruke det. Utvikling fr gjenbruk. Vi lager kmpnenter fr at nen andre skal kunne gjenbruke de. Utvikling med gjenbruk Gjenbruket skjer på kmpnentnivå. Vi kan imidlertid ikke vente til kdefasen med å tenke gjenbruk. Vi må tenke gjenbruk helt fra vi begynner å se på arkitekturen. Vis fig g kmmenter. Det å ppnå en str gjenbruksandel vil være et internt krav til utviklingsprsjektet. Dette kan / vil medføre at vi i str grad må bygge pp systemet rundt de kmpnentene vi velger å gjenbruke. Sm en knsekvens av dette får vi en iterativ prsess sm innehlder søking i databasen, arkitektur g verrdna design. Utvikling fr gjenbruk Utvikling fr gjenbruk må kmme først,ellers er det j ingen ting å gjenbruke. Fig viser en mulig prsess fr dette. Legg merke til at det ikke er nødvendig å ha mer enn ett planlagt prsjekt i dmeneanalysen. Det er tilstrekkelig å vite / anta at man skal lage senere prsjekter der man kan få til utvikling med gjenbruk. Beskrivelsesspråk Det er definert flere språk sm understøtter gjenbruk. Mange har prøvd å innføre skille mellm prgramming in the large systemprgrammering g prgramming in the small kmpnentprgrammering. Et eksempel på hva sm har kmmet ut av dette er språket MIL Mdule Intercnnectin Language. Et eksempel er vist i fig kmmenter bruken av nøkkelrda prvide, require g implentatin. Her beskriver vi et abstrakt system sm består av flere mduler. De tre første mdulene blir kalt henhldsvis cntrl_md, input_md g stre_md. Hver av mdulene har et sett av prsedyrer g / eller pakker. Selv m vi ikke har nen frm fr kmpilatr sm kan handtere dette så kan beskrivelsen være nyttig frdi den viser strukturen i systemet på en måte sm utviklere vil ppfatte sm enkel. Utvikling av gjenbruk Vi har tidligere sett at matematikkpakker er ett av de mrådene der gjenbruk har vært svært vellykka. Mange ser ikke på dette sm gjenbruk det er bare funksjner sm er tilgjengelige, akkurat sm I/O rutiner er tilgjengelig i de fleste språk. Dette har fått bka til å identifisere fire faser i gjenbruk: 1. All prgramvare blir skrevet fra bunn av. Dmenet er lite utfrsket g ppdeling i pakker, klasser eller prsedyrer er ad hc. Det er lite eller ikke ne gjenbruk. 2. Vi begynner å se de samme prblemene med de samme løsningene dukke pp i flere sammenhenger innefr dmenet. Vi går gjennm en prøving g feilingsfase fr å finne praktiske, abstrakte knsepter. All gjenbruk er ad hc. 3. I denne fasen vil vi begynne med gjenbruk. Terminlgien i dmenet her begynt å stabilisere seg. Dette øker kmmunikasjn g sannsynligheten fr at nen lager kmpnenter sm er relatert til denne terminlgien. Vi har begynt å gjenbruke eksisterende kmpnenter på en systematisk måte fra prsjekt til prsjekt.

68 4. Sluttfasen. Dmenet er gjennmarbeidet g frstått helt g fult. Utvikleren lager ikke prgramvare fr dette dmenet g vi tenker ikke engang på dette sm gjenbruk. I stedet har vi et sett av standardkmpnenter sm alle bruker. Det ser ut til at det ikke er lurt å prøve å hppe fra fase 1 til fase 3 uten å ha vært innm fase 2. Vi trenger denne fasen fr å samle erfaring nk til å bygge pp det beste, mest brukbare settet av abstraksjner fr terminlgien. Det ser altså ut til at vi må ha et evlusjnært syn på gjenbruk i det minste fr bransjen sm helhet. Situasjnen vil antakelig være ne annerledes innefr en bedrift. Ikke-tekniske prblemer Sm innefr mange andre mråder i systemutvikling er det gså mange prblemer innenfr gjenbruk sm ikke er rent tekniske g derfr ikke kna ha rent tekniske løsninger. Vi skal se på tre mråder ledelse, øknmi g prsjektregnskap. Ledelse Fr at gjenbruk skal fungere i en bedrift er det nødvendig at: Ledelsen støtter innføring av gjenbruk. Sm vi senere skal se vil effektivt gjenbruk medføre investeringer både i frm av kde g pplæring g dette er det vanskelig å få til uten ledelsens gdkjenning. Man ppmuntrer til gjenbruk eller frlanger en gd begrunnelse fr å lage en kmpnent selv viss det allerede finnes en kmpnent sm kan gjøre jbben. Bka påstår at utviklere lider av NIH Nt Invented Here syndrmet, men det er lite sm tyder på det når man prøver å finne ut hva sm fremmer gjenbruk. NIH syndrmet fungere nk mer sm en unnskyldning når man ikke får til gjenbruk. Den største hindringen fr gjenbruk ser ut til å være manglende tillit til kmpnenter. Man utfører en dmene analyse slik at man vet hva det er teknisk gunstig å lage av gjenbrukbare kmpnenter. Man tenker gjenbruk fra starten av prsjektet. Gjenbruk er ikke ne sm kan vente til slutt. Ut fra dette er inkrementell utvikling antakelig mest effektivt viss man vil ppnå høy gjenbruksgrad. Øknmi Fr at gjenbruk skal kunne lønne seg kreves det investeringer. Det er et prblem at mange prgramvarebedrifter ttalt mangler et investeringsbegrep g en internrente. Uten dette kna de ikke handle øknmikk rasjnelt g det gjør de da fte ikke heller. Når vi utvikler gjenbrukbare kmpnenter finnes det tre kstnader vi ikke kmmer unna, nemlig kstnadene frbundet til: Utvikling av kmpnenten. Dette er kstnader sm blir absrbert av det enkelt prsjekt g derfr blir dekket av kundene. Å gjøre kmpnenten gjenbrukbar. Dette er kstnader til mer dkumentasjn slik at andre kna frstå hva kmpnenten gjør g hvrdan den gjør det, ekstra testing fr å gi mer tillit g ekstra kstnader i kvalitetssikringen fr å få en høy kvalitet på kmpnenten. Dette er den største kstnaden. Drift g vedlikehld av et kmpnentbiblitek. Denne kstnaden vil i de fleste tilfeller være liten. Når vi skal gjenbruke ne kmmer det til t nye kstnader: Søke i bibliteket fr å finne gjenbrukbare kmpnenter. Dette er vanligvis en liten kstnad, men den medfører at det er liten vits i å gjenbruke små kmpnenter viss vi må bruke mye tid på å finne. Gjøre eventuelle mdifikasjner fr tilpassning. Dette kan frt bli dyrt g enkelte hevder at det bare er gjenbruk med meget små endringer sm egentlig lønner seg. Det er nen kritske spørsmål sm må besvares før man tar beslutningen m å lage en kmpnent gjenbrukbar: Hva er sannsyneligheten fr at vi kmmer til å gjenbruke denne kmpnenten? Hvr mange ganger kmmer vi til å gjenbruke denne kmpnenten? Når kmmer vi til å gjenbruke denne kmpnenten? Den infrmasjnen man får fram kan man bruke på flere måter. Vi skal se på t en enkel, men kanskje bra nk g en sm bruker ideer fra investeringsanalysen. Enkel tilnærming: Vi bestemmer vår planleggingshrisnt. Dette kan være hva sm helst fra 12 måneder til 4 5 år. Det vil antakelig ikke lønne seg viss:

69 Sannsynligheten fr gjenbruk er vurdert sm lav Første gjenbruk ligger mer enn ett til t år fram i tid Det neppe blir mer enn ett til t gjenbruk av kmpnenten. Avansert tilnærming. Innfører følgende ntasjn: Utviklingskstnader i år i er U i. Legg merke til at kstnadene ved å lage en kmpnent vil endre seg den vil antakelig synke ver tid. Internrente er r. Første utvikling kster U, med et tillegg U g fr å gjøre kmpnenten gjenbrukbar. Antall gjenbruk er N Hvert gjenbruk gjør at vi sparer ca. U i krner. Redusert til nåverdi blir dette U i / (1 + r) i. Tiden til gjenbruk g intern-renten påvirker altså resultatet. Viss vi sumerer dette fr alle år der vi gjør gjenbruk finner vi ut hva vi har spart: Spart = SUM( U i / (1 + r) i ). Dette må være større enn investeringen sm er U g. L ss se på et enkelt eksempel. En mdul kster 200 timeverk å utvikle. Internt blir dette vurdert til 500 * 200 = krner. Fr å få den gjenbrukbar må vi legge på 100 timeverk til altså krner sm er en investering. Bedriften bruker ei internrente på 5%. Vi regner med å kunne gjenbruke denne mdulen tre ganger en gang i hvert av de tre neste åra. Vi ser ikke fr ss at det blir ne særlig enklere å lage slike mduler i planperiden. Det vi sparer, redusert til nåverdi (NPV) er * ( 1 / / / ) sm er mtrent lik 2.7 * eller krner. Vi ser at dette lønner seg. Viss vi bare får ett gjenbruk g det skjer m tre år så er NPV av innsparinga bare * 1 / , sm er mtrent lik krner m stadig er en grei investering. Endringer i utviklingskstnader g internrente vil kunne frandre bildet. Igjen dette bør ikke være den eneste input i beslutningsprsessen, men det vil være nyttig å være klar ver. Ellers kan det være greit å se på frhlda sm illustreres i fig fr å frstå hvrfr mange bedrifter ikke kmmer i gang med gjenbruk i str skala. Prsjektregnskap Gjenbruk behøver ikke nødvendigvis å være et gdt valg fr et utviklingsprsjekt. La ss se på et dessverre fte frekmmende frhld. Prsjekt A finner ut at en av deres kmpnenter passer svært gdt fr gjenbruk g ønsker derfr å lage kmpnenten gjenbrukbar selv m dette ikke var planlagt på frhånd. I stedet fr å kste X krner så vil nå denne kmpnenten kste et sted mellm 1.5 * X g 2.0 * X. Dette kmmer fram sm en verskridelse på prsjekt A g prsjektleder får kjeft. Mengden varierer fra bedrift til bedrift. Prsjekt B får en gjenbrukbar kmpnent g trenger bare å bruker 0.1 * X i stedet fr X sm planlagt. Dette prsjektet kmmer derfr ut med en kstnad lavere enn planlagt g får masse skryt av ledelsen kanskje til g med et lønnspålegg. Slike pplevelser gjør ikke at de sm deltk i prsjekt A får lyst til å lage gjenbrukbare kmpnenter. Det er flere måter vi kan bøte på dette på. De t sm kmmer her blir begge brukt i bedrifter sm satser seriøst på gjenbruk: Det å lage en gjenbrukbar kmpnent er et eget, separatfinansiert prsjekt fr de sm lager gjenbrukbare kmpnenter. Etter at hvert prsjekt er ferdig går en egen gruppe gjennm det de har laget g velger ut kmpnenter sm skal lages gjenbrukbare. Selve jbben gjøre at Gjenbruksgruppa i bedriften. Begge disse pplegga har den frdelen at de synliggjør gjenbruk sm en investering. Et siste prblem er at det er mye mrsmmere å lage ting selv enn å skru sammen ting andre har laga. Det er t effekter sm mtvirker dette: Gjenbruke der man ikke er ekspert slik at man kan bruke tida si på det man er gd til ne sm gir bedre kde. Dette krever litt planlegging av både gjenbruk g bemanning før man starter prsjektet. Man slipper å vedlikehlde de delene sm er gjenbrukt. Det er det andre sm er ansvarlig fr. Dermed blir det mindre å gjenbruke g mer tid til å lage nye ting.

70 Det man må passe seg fr er å lage et A-lag sm har det mrsmt med å lage nye ting g et B-lag sm bare får gjenbruke g lime sammen det andre har laget. Ingen liker å tilhøre et ffisielt eller uffisielt B-lag Kapittel 18 Vi skal se på t viktige frhld: Feiltleranse kunne bli utsatt fr feil uten å krasje eller frårsake andre alvrlige knsekvenser, fr eksempel ødeleggelse av viktige data. Pålitelighet gi riktige / frhandsdefinerte svar eller ppføre seg riktig i henhld til innhldet i en kravspesifikasjn. I tilelegg vil vi bruke ne tid på å diskutere t viktige spørsmål innefr pålitelighet i prgramvare. Dere skal gjøre diskusjnen jeg skal bare ppsummere på tavla. Feiltleranse Det er enklest å ta utgangspunkt i et eksempel. Bka ser på et eksempel med en feiltlerant disk. Vi vil unngå t typer feil: En eller flere blkker blir umulig å lese. Hyppigheten av dette prblemet er kjent fra en analyse av maskinvaren disk pluss kntrller. Prsessren sm styrer dette krasjer. Det er i dette eksemplet bare krasj under skriving til disk sm frårsaker uleselige blkker. En rbust løsning finnes i fig Gå gjennm kden på figuren. Vi bruker en lese / skrivesetning med følgende frmat: Parameter 1 disken vi leser fra. Her er dette disk1 eller disk2. Parameter 2 blkk adresse på disken Parameter 3 resultat av lesningen, altså innhldet i blkka. All inf blir skrevet til begge diskene. Når vi leser, leser vi først fra disk1. Viss denne lesinga feiler leser vi fra disk2. Årsaken til at dette er frnuftig er sm følger: Vi antar at maskinvaren feiler uavhengig. Dette behøver ikke alltid være sant vi kan tenke ss flere grunner til at de feiler samtidig, fr eksempel at de er prdusert i samme bedrift, til samme tid, er installert samtidig g er brukt like mye. Viss feilsannsyneligheten er p vil sannsyneligheten fr at begge feiler samtidig gitt at de feiler uavhengig være lik p* p. Dette vil altså være feilsannsyneligheten fr saferead under de gitte frutsetningene. Fr å få litt bedre versikt ver systemet kan vi tegne et tilstandsdiagram se fig Tegn gså pp denne figuren slik at det blir klart hvrdan vi lager den. Parametrene r, s g R er ikke sannsyneligheter de er rater g har dimensjn 1/t. Diagrammet / mdellen gir en full versikt ver tilstander g verganger i systemet. I tillegg til feilratene fr de t diskene s- har de gså en reparasjnsraten r, fr recver. Det er altså ikke en fysisk reparasjn vi ser på. Vi ser videre at vi kan få en dbbeltfeil viss den andre disken krasjer mens vi hlder på med reparasjn / recvery. I dette tilfellet må vi gjøre reparasjn fra et eller annet reservemedium fr eksempel magnetbånd eller en disk sm er fysisk tatt ut g lagret et annet sted. Hendelsen at begge diskene feiler samtidig er så usannsynlig at den ikke er tatt med i tilstandsdiagrammet. Vi kan nå sette pp likevektslikningene fr dette systemet. Dette gjøre ut fra prinsippet at i likevekt må trafikken inn g ut av en nde være like stre. Viss vi frutsetter knstant feilsannsynlighet får vi følgende mdell: 2 * s *p(1,1) = r * p(0,1) + r * p(1,0) + R * p(0,0) s * p(1,1) = s * p(0,1) + r * p(0,1) s * p(1,1) = s * p(1,0) + r * p(1,0) s * p(0,1) + s * p(1,0) = R * p(0,0)

71 I tilegg må summen av alle sannsynelighetene være 1 ett sted må vi j være. Derfr har vi gså at: p(1,1) + p(1,0) + p(0,1) + p(0,0) = 1. Ut fra symmetri ser vi at p(0,1) = p(1,0) viss diskene er fysisk like. Derfr mister vi en av de fire likningene venfr, men har stadig fire likninger g fire ukjente de fire tilstandssannsynlighetene. Det nye linkningssettet blir: 2 * s * p(1,1) = 2 * r * p(0,1) + R * p(0,0) s * p(1,1) = (s + r) * p(0,1) 2 * s * p(0,1) = R * p(0,0) p(1,1) + 2 * p(0,1) + p(0,0) = 1 en enkel måte å løse dette systemet på er å bruke de t midterste likningene til å erstatte p(0,0) g p(1,1) i den siste likninga. Etter litt enkel manipulasjn finner vi at: p(0,1) = p(1,0) = (R * s) / (2 * s * s + R * r + 3 * R * s) p(1,1) = (R * (s + r)) / (2 * s * s + R * r + 3 * R * s) p(0,0) = (2 * s * s) / (2 * s * s + R * r + 3 * R * s) I de fleste tilfeller vil feilraten ( antall feil pr. time) være vesentlig lavere enn raten fr reparasjn, enten det er recvery eller rll back altså har vi at r, R >> s. Detter gjør at vi kan frenkle likningen ver vesentlig. Pass på at vi ikke lenger har at summen av sannsynlighetene er lik 1: p(0,1) = p(1,0) = s / (r + 3 * s) p(1,1) = r / (r + 3 *s) p(0,0) = 2 * s * s / (R * (r + 3 * s)). Viss vi ønsker å bevare summen lik en kan vi i stedet sette p(0,0) = 2 * s / (r + 3 * s) Strengt tatt kunne vi brukt bare r under brøkstreken, men dette ville gitt p(1,1) = 1, sm er ne uheldig. Dessuten er vanligvis r > s, men ikke nødvendigvis mye større. La ss se på nen typiske tall fr en 40 GB disk: Det tar ca sekunder, sm tilsvarer 5.5 timer, å gjøre en full rll back. Dette gir R = 1 /5.5 = Reparasjn full les / skriv av hele disken - tar ca 8000 sekunder, sm tilsvarer 2.2 timer. Dette gir ss en verdi på r = 1 / 2.2 = En disk feiler i gjennmsnitt en gang pr. en millin timer. Dette gir s = Vi ser at allerede her er s svært liten i frhld til R. Med disse tallene finner vi p(0,1) = p(1,0) = 5.9*10-5, p(1,1) = Da har vi sannsynligheten fr at vi må kjøre rll back på 1 2*p(1,0) p(1,1) = etter sm r øker i frhld til s vil p(1,1) gå mt 1.0. Pålitelighet Mdeller fr prgramvare pålitelighet blir brukt på t måter. Stille krav dette systemet må ha en feilrate på mindre enn en feil pr. måned. Under testing vi må teste til sannsyneligheten fr mer enn en feil pr. måned er mindre enn 5%. Fr å få til dette må vi ha en statistisk mdell. Det finnes mange mdeller fr prgramvarepålitelighet antakelig mye mer enn 100. vi skal nøye ss med å se på t. Ingen av de er spesielt avanserte, men derfr er de enkle å frstå. I tillegg viser de mange av de

72 prblemene vi støter på når vi skal lage g bruke slike mdeller. De t mdellene vi skal se på er: Basis eksekveringstidsmdell Lgaritmisk Pissn eksekveringstidsmdell Før vi begynner må vi se på nen viktige mmenter: Vi bekymrer ss ikke primært m antall feil, men m antall feilhendelser. Vi vil bruke eksekveringstid ikke klkketid. Hvedårsaken til dette er at eksekveringstid bedre gjenspeiler bruken av prgrammet enn klkketid gjør. Persnlig mener jeg at brukstid er mer relevant enn eksekveringstid, men eksekveringstid er tettere relatert til eksekveringstid enn til klkketid så det er vel egentlig OK. Vi vil estimere pålitelighet ut fra tidligere erfaringer fr eksempel testing. Den parametriserte mdellen vi kmmer fram til frutsetter strengt tatt at framtida likner på frtida. Derfr viss framtidig bruk skiller seg mye fra måten vi har testa på er den mdellen vi lager helt uinteressant. Prgramvare er deterministisk. Det sm var OK i går vil være OK i mrgen. Prgramvare kan derfr bare feile under følgende frutsetninger: Ne har endra systemet eller dets mgivelser Systemet får ny input input det ikke har pplevd før Systemet får input det har pplevd før, men er i en ny tilstand. Estimering av et prgrams pålitelighet kan derfr ikke skilles fra estimering av brukernes ppførsel. Vi kan beskrive systemets ppførsel på t måter: Antall feil funnet i en bestem peride Tid mellm feil i en bestemt peride. Valget vil bestemme hva slags mdeller sm er realistiske. Under testing vil feil bli fjernet etter hvert sm de blir funnet. Vi vil derfr anta at prgrammet blir mer g mer pålitelig etter hvert. En tilsvarende prsess vil ikke uten videre være på plass når systemet er i drift. Litt ntasjn: Gjennmsnittlig antall feil i intervallet [0, t] µ(t) Feilintensitet λ(t). Dette er gjennmsnittlig antall feil pr. tidsenhet. Derfr har vi gså at λ(t) = d[µ(t)] /dt Frhldet mellm disse parametrene er vist i fig Basis mdell - BM Her antar vi at reduksjn i feilintensitet - gitt sm funksjn av antall feil fjernet er knstant. Lar vi µ være det gjennmsnittelige antall bserverte feil, kan vi sette λ(µ) = λ0(1 µ / N0), der N0 er det ukjente ttale antall feil i systemet. Av dette følger at dµ/dt = λ0(1 µ / N0). Denne differensiallikninga kan vi løse enkelt ved hjelp ved å bruke differensialperatren g tilpasse et knstantledd. Vi finner direkte at µ(t) = N0[1 exp(-t * λ0 / N0)] g derfra direkte at λ(t) = λ0*exp(-t * λ0 / N0). Denne mdellen skriver seg fra Jelinski g Mranda g er en av de eldste g enkleste mdellen fr prgramvarepålitelighet. Ofte skrives den på frmen: µ(t) = N0[1 exp(-t * Φ)], λ(t) = ΦΝ0*exp(-t * Φ).

73 Lgaritmisk Pissn mdell LPM Her antar vi at feilintensiteten avtar ekspnentielt, altså at vi har λ(µ) = λ0 * exp(-θ*µ). Vi kan mfrme dette til følgende differensiallikning: dµ/dt = λ0 * exp(-θ*µ) sm er direkte integrerbar med grensebetingelsen µ = 0 fr t = 0. Vi får da exp(θµ) = θλ0*t + 1 sm igjen gir ss at µ = ln(θλ0*t + 1) / θ. Herfra finner vi direkte at λ = λ0 / (θλ0*t + 1). Bruk av mdellene Når vi slutter å rette eter hvert sm feilene dukker pp etter levering til kunde vil feilraten etter disse t mdellene være knstant. Vi erstatter da t med T den tiden vi har brukt til testing. Vi får da en hmgen Pissn prsess med feilrate λ(t) g sannsynligheten fr n feil i løpet av tidsrmmet t blir P n (t) = (λt) n * exp(-λt) / n! Vi ser direkte at P 0 (t) = exp(-λt). Vi kan estimere mdellparametrene ut fra vanlige statistiske metder fr eksempel MLE (Maximum Likelihd Estimatin) eller LSE (Least Square Errr). Alternativt kan vi bruke en grafisk estimering kurvetilpassning. Se fig i bka. Vi skal ikke se mer på dette her. Det er viktigere å se på hvrdan mdellen kan brukes i praktisk arbeid. La ss anta at vi fr øyeblikket har en feilrate på λ P mens kravet er ei feilrate mindre eller lik λ F. Vi er interessert i å vite hvr mye lenger vi må teste fr å ppfylle kravet til feilrate. Vi går fram på følgende måte: Basismdellen: λ P = ΦΝ0*exp(-t P * Φ), λ F = ΦΝ0*exp(-t F * Φ). Ved å dividere den ene likningen på den andre finner vi direkte at t = ln(λ P / λ F ) / Φ. Fr den lgaritmiske mdellen løser vi dette lettest ved å skrive m likningen fr λ til uttrykket (λ0 / λ p 1) = θλ0*t P g tilsvarende fr λ F. Ved å finne utrykk fr t P g t F g subtrahere finner vi t = (1/λ F 1/λ p ) /θ. Alternativt kunne v ta utgangspunkt i µ(t) g finne ut hvr mange flere feil vi må finne fr å tilfredsstille kundens krav til pålitelighet. Det kan være greit å huske på at disse g andre mdeller innfr prgramvarepålitelighet bare er tilnærminger. De viktigste prblemene med å mdellere prgramvarepålitelighet er at: Hvrdan g hvr fte et system feiler avhenger av hvrdan det blir brukt. Mdellering av feilfrekmster medfører derfr at vi må mdellere bruksmåten. Siden prgramvare er deterministisk kan systemet under testing - bare feile fr ny input eller fr gammel input i en ny tilstand. En mdell sm gir gde resultater fr en måte å bruke systemet på, vil kunne feile fr andre bruksmåter. Vi bør derfr ikke bygge beslutningene bare på resultater fra de frmlene sm kmmer ut av pålitelighetsmdellene. Bka freslår å ha en biblitek av pålitelighetsmdeller g deretter velge den mdellen sm passer best til hvert enkelt prsjekt. Dette vil sikkert fungere i mange tilfeller, men det blir litt fr ugjennmsiktig til at vi skal ha tillit til resultatene. Vi savner j svar på Hvrfr passer denne mdellen g ikke de andre? Til diskusjn En løsning på prblemet med å lage høypålitelig prgramvare var lenge g er stadig i nen miljøer å innføre N-versjn prgrammering. Ideen er sm følger: Skriv en kravspesifikasjn g distribuer den til N utviklingsmiljøer fr eksempel tre stykker. Hvert miljø lager sin versjn av systemet. Det er viktig at disse tre miljøene ikke utvekseler infrmasjn, diskuterer prblemer g løsninger eller samrdner seg på nen måte. Hensikten er å hindre felles feil i systemet feil sm finnes i t eller flere av systemene.

74 Bruk alle systemene sammen. De får samme input, men leverer hver sin utput. Resultatene blir sammenliknet. Vi kan nå velge mellm flere strategier: OK bare viss alle systemene gir samme resultat. Ellers rapprterer vi en feil OK viss flertallet fr eksempel 2 av 3 gir samme resultat. Feil bare viss det ikke er mulig å finne et resultat sm har flertall Dette ble imidlertid ikke den suksessen mange hadde håpet på. Diskuter hva sm kan være mulige årsaker til dette Kapittel 4 Vi har behv fr knfigurasjnsstyring / knfigurasjnskntrll av t grunner: I løpet av et prsjekt blir det prdusert en gd del dkumenter design, kde, tester sv. I løpet av prsjektet må de fleste av disse endres en eller flere ganger pga. feil, inknsistens, nen fr eksempel kunden - har frandret mening, ting passer ikke sammen sv. Lista med årsaker kan gjøres lang. Etter at vi har levert første versjn fr første plattfrm må vi endre systemet selv m det ikke er feil i det. Sm før er årsakene mange. Eksempler er: selge prduktet på ny plattfrm, lage spesialversjn fr en viktig kunde, kmme med nye, frbedra versjner ny funksjnalitet, nye muligheter. Utfrdringene i de t tilfellene er litt frskjellig: I løpet av prsjektet passe på at alle bruker nyeste gdkjente versjn av alle dkumenter g at det samtidig er mulig å gå tilbake til en tidligere versjn viss det viste seg at vi gjrde ne dumt. Etter at vi har levert sørge fr at vi kan gjenskape de versjnene sm hver enkelt kunde har. Dette kna bli kmplisert når vi begynner å få inn feilrapprter sm bare angår systemene til nen kunder. Grunnleggende begreper Vi vil starte med å anta at det finnes bare en ffisiell versjn av systemet. Dette kalles en baseline. Alt sm tilhører en baseline er frmelt gdkjent ved hjelp av tester, granskning, inspeksjner g lignende. Den første ppgaven til knfigurasjnskntrll er å sørge fr at ikke uffisielle dkumenter kmmer å frurenser baseline. Dette kan fr eksempel være dkumenter ms ennå ikke er granska eller mduler sm ikke har en gdkjent test. Baseline innehlder alt sm beskriver / dkumenterer systemet. Dette inkluderer: Kildekde g bjektkde (kde sm er kmpilert g klar fr lenking) Kravspesifikasjn g designdkumenter både verrdna g detaljert design. Testplan g testresultater - testlgg Brukermanual Det er lett å se fr seg at de fleste av disse dkumentene vil bli endra en eller flere ganger i løpet av et prsjekt g at det kna være en utfrdring å hlde de ppdatert g knsistente. Fr å få til dette vil de fleste bedrifter velge å ha en dkumentert prsess. Det er interessant å se at mange bedrifter sm ellers ikke har nen utviklingsprsess i det hele tatt g kanskje til g med synes det er dum ide likevel har en meget streng kntrll ver hva sm ligger i baseline. En slik prsess er vist i bka fig Vis g kmmenter. Legg merke til følgende: Når vi skal vurdere effekten av å tillate en endring må vi ta hensyn til både prduktet, det dkumentet det gjelder g selve utviklingsprsessen / prsjektet. Vi må velge m vi vil: Frkaste dette vil vi ikke gjøre ne med Sette på venting dette vil vi ikke gjøre ne med nå Akseptere endringa. I dette tilfellet må vi gså gi endringa en priritet. Pass på at baseline er knsistent etter endringa. Dette kan føre til at vi i tillegg til endringa gså må initialisere andre endringer. Viss vi fr eksempel endrer funksjnalitet må vi i tillegg endre brukerdkumentasjn g en del systemtester. Det er den siste jbben sm er vanskelig. Intensiv bruk av spring hjelper nen, men generelt sett er det så mange mulige sammenhenger i et system at det er vanskelig å hlde styr på alle.

75 Siden det kan være flere sm ønsker å endre en kmpnent mer eller mindre samtidig er det viktig å ha en mekanisme sm sørger fr at bare en persn ad gangen kan andre ne. En vanlig teknikk er kjent sm check-in / check-ut der alle baseline dkumentene ligger i en database. Frklar dette knseptet krt. Det er vanligvis CCB Change Cntrl Bard sm kntrllerer når en kmpnenten er ferdig g dermed kna legges inn i databasen. Kmpnenten er da under knfigurasjnskntrll / versjnskntrll. Fig. 4.2 i bka viser hvrdan dette blir ivaretatt. Fr å hlde styr på utviklingen av hver enkelt kmpnent er det vanlig å innføre en faset nummerering. En mulig å måte å gjøre dette på er å bruke nummer sm er bygd pp sm X.Y.Z sv. Dette har følgende tlking: Første siffer identifiserer hvedversjnen. Det er vanlig å bruke 0 fr den pprinnelige utviklingen, 1 fr første release g deretter 2, 3, sv. fr nye hvedreleaser. Hvedreleaser innehlder en knslidering av de endringene sm er gjrt til nå pluss eventuell ny funksjnalitet. Andre siffer viser midlertidige endringer små feilrettinger sv. Det er vanlig å perere med X.1, X.2 sv så lenge man retter g deretter samle alle endringene i en ny release sm da får nummer (X+1).0. Vis g kmmenter fig Legg merke til at vi legger til ny funksjnalitet i den ene greina X.2 -> X.3 mens vi bare gjør små endringer i den andre X2.1 -> X2.2 -> X2.3. Når vi har laget ett system g ønsker å lage nye versjner fr eksempel fr en ny plattfrm får vi flere parallelle utviklingsspr greiner. Erfaring har vist at når vi først har laget flere greiner i utviklinga av et prdukt er det vanskelig å få slått de sammen igjen. Ofte lager man ikke fysisk kmpnentene X2.1, X2.2 sv. I stedet lagrer man basisversjnen i dette tilfelle X.2 g deretter bare endringene, gså kalt deltaer. Versjn X.3 består derfr av versjn X.2 pluss alle deltaer sm tilhører X.2. Først når vi går til en ny hvedversjn blir alle deltaene fysisk inkludert i mdulene. Frdelen med dette er at vi kan lage hele pplegget mer fleksibelt g brukervennlig: Deltaene kan gies navn etter hvilken effekt de har rett prblem med stre tabeller, feil R.12. Vi kan enkelte ta med bare nen av rettingene i stedet fr å måtte ta med alt sm er gjrt til nå. Slike systemer er best kjent under akrnymet SCCS Surce Cde Cntrl Systems. Prblemet med dette g alle liknende pplegg er at vi får prblemer så snart vi begynner å endre i den kden sm allerede er endra før vi lager en ny release. Det finnes verktøy sm autmatisk lager ppdaterte versjner av kden, kmpilerer de nye versjnene g lenker det hele sammen til et nytt system. Input til slike verktøy er en knfigurasjnsbeskrivelse sm består av: En liste ver baseline kmpnentene sm skal være med En liste av deltaer fr hver baseline kmpnent Knfigurasjnsplan Sm mye annet i et større prgramvareprsjekt er det gså kjekt å ha en plan fr knfigurasjnsstyringen. Fig. 4.4 viser innhldet i en slik plan i henhld til IEEE Std Opplegget kan se verveldende g vel byråkratisk ut, men erfaring viser at man trenger dette fr å kmme i mål med prsjektet på en ryddig måte. De viktigste delene er: Ledelse det viktige her er hvrdan ansvaret er frdelt innad i prsjektet. Hvrdan blir en fase avslutta, hvem bestemmer når en enhet er ferdig sv. I tillegg blir samarbeidet mellm CM, QA g utvikling fastlagt her. Aktiviteter her sider vi ne m hvrdan vi vil hlde styr på enhetene. I tillegg må vi si ne m selve gdkjenningsprsessen g hvrdan vi hlder versikt ver status hva skal endres, av hvem g hvrfr. Hva har vi av utestående endringsfrslag, deres priritet sv. Diskusjnstema CM ble laget g definert sm ppgave g prblem den gangen man hadde en tradisjnell fssefallsmdell. Må våre ideer, verktøy g rutiner endres når vi går ver til inkrementell utvikling eller er de metdene g standardene vi har stadig tilstrekkelige. Diskuter. Diskusjnen ppsummeres på tavla.

76 Kapittel 5 Dette handler primært m menneskene i prsjektet. På mange måter er det den viktigste delen, men gså den delen sm er vanskeligst tilgjengelig. Dette er ikke ment sm en pplæring i det å lede mennesker i et prsjekt. Det er mer en liste ver mmenter dere må passe på når / viss dere skal lede et prsjekt. Selve pplæringa i å takle de situasjnene sm ppstår er ikke en del av systemutvikling sm fag, det hører til psyklgi g ssilgi. Dette er et sett av regler ting det kan være lurt å passe på: Et prsjekt bestå av individer hver med sine egne mål. Det er prsjektleders ppgave å sørge fr at alle jbber sammen mt det felles mål sm er prsjektets mål. En vesentlig del av dette er at prsjektleder gjør det klart fr prsjektdeltakerne hva han frventer av dem hva er hver enkelts ppgaver i prsjektet. Erfaring viser av viss ikke dette er klart fra start, vil deltakerne snart definere sine egne mål g jbbe fr å ppnå disse uansett hva de måtte være g uansett m det angår prsjektets mål eller ikke. Når man først er blitt enige m målene g hvem sm skal gjøre hva er det viktig å følge pp at hver enkelt gjør jbben sin innefr de tids g kstnadsrammene sm er definert. Dersm det viser seg at det ikke er mulig å gjøre jbben innefr disse rammene må prsjektleder sørge fr å: Gi utvikleren nye rammer. Selv m det er prsjektleder sm gir rammene så må utvikleren være med å bestemme hvr mye ekstra ressurser sm trengs fr å fullføre jbben. Replanlegge prsjektet. Dette består både av å replanlegge de aktivitetene sm har fått nye ressurser g de aktivitetene sm ikke er påbegynt ennå. At de sm jbber i prsjektet gjør jbben sin at det er framdrift i prsjektet. Den mest effektive måten å følge pp et prsjekt på er så se på ressurser brukt g verdi skapt. Dette måles ved å se på: Antall timeverk brukt i en aktivitet ressurser brukt Antall arbeidspakker ferdige verdi skapt. Verdien til en arbeidspakke er lik det vi har estimert at den skal kst. Det er dette kunden betaler g det er det enste verdimålet det er mulig å bli enige m. Man kunne i stedet se på antall kdelinjer prdusert. Frfatteren av lærebka er engstelig fr at dette vil føre til at flk skriver kde bare fr å skrive kde. Dette vil gjøre målet ubrukelig, men de enste utviklerne egentlig lurer er seg selv. Viss man bruker dette målet kna det være lurt å telle linjer skrevet, endra eller sletta fr å få et best mulig bilde av utviklinga. Det å jbbe i et prsjekt betyr samarbeid. Et prsjekt er ikke en egtripp. Ideelt sett er det ikke ne sm heter min kde i et prsjekt i det minste ikke før den skal vedlikehldes. Samarbeide i et prsjekt kan ta mange frmer fra det helt ufrmelle buddy systemet til frmaliserte kdegranskninger. At kmmunikasjnen fungerer i prsjektet. Det er flere måter å få til dette på nen frmelle g nen ufrmelle. Det etterfølgende er nen eksempler Prsjektmøte. Disse bør være på en fast tid, fr eksempel hver mandag kl 10:00. bruk de bare til å gjøre ting sm alle må være med på ellers kaster vi brt verdifull tid. Dette betyr at prsjektet må se på framdrift hvr er vi - eventuelle prblemer hvrdan kmmer vi videre g viktig innfr sm alle trenger. Ufrmelle kntakter, fr eksempel rund kaffemaskinen eller Claautmaten. Felles kaffe-, lunsj- g tidsskriftareal er gså nyttig. Generelt er det viktig å skape mange muligheter / anledninger til ufrmell kntakt. At dette er viktig er en av årsakene til at gegrafisk distribuerte prsjekter fte får prblemer. Hvrdan vi krdinerer arbeidet vårt vil avhenge av flere faktrer. De viktigste er: Type arbeidsppgave fr eksempel kmplett definert vs. løst definert. Hva slags flk har vi fr eksempel nyansatte uten erfaring vs. kmpetente ansatte med lang g erfaring g spesialister vs. flk med svært diversiv bakgrunn. Organisasjn sentralstyrt firma vs. firma der hver enkelt del har en str grad av selvstyre. Dette bestemmer f.eks. hvilke muligheter vi har til selv å velge hvrdan vi skal jbbe. Nen erketyper av krdineringsmekanismer: Enkel struktur. Krdinering skjer gjennm direkte kntrll. Det finnes nen få ledere g mange utviklere. Det finnes lite spesialisering, pplæring eller frmelle rutiner. Dette fungerer bare i små rganisasjner med få g små prsjekter. Maskinbyråkrati. Arbeidet er spesifisert helt g fullt g arbeidet fregår etter spesifiserte instrukser. Spesialiserting er viktig mens pplæring blir hldt på et minimum. Avdelinger / divisjner. Avdelingene er her prsjekter sm har en str av selvstyre. Målene blir satt utenfra, men prsjektene har str grad av frihet til å bestemme hvrdan de vil nå målene. Krdinering mellm prsjekter skjer gjennm standardisering av resultater hva skal prsjektet levere g på hvilken frm. Krdinering innefr prsjektet skjer gjennm prsjektmøter.

77 Prfesjnelt byråkrati. Når det ikke er mulig å spesifisere verken sluttresultat eller innhld kan man ppnå krdinering gjennm standardisering av hva den enkelte utvikler skap kunne. Fkus er altså på dyktige medarbeider sm vet hva sm trengs å gjøre. Ad-hc-krati. I prsjekter med en str grad av innvasjn er det vanskelig å definere knkrete, avgrensa arbeidsppgaver. Vi trenger mennesker sm er i stand til å nå vage mål på en krdinert måte. Krdineringen skjer gjennm gjensidige justeringer. Det er ikke slik at hele bedriften behøver å ha de samme krdineringsmekanismene. Særlig i stre bedrifter vil man finne mange måter å krdinere på, avhengig av hva avdelingen lager, hva slags mgivelser de fungere i sv. I tillegg vil det ikke nødvendigvis være lurt å ha samme måten å lede et prsjekt på gjennm hele levetiden til prsjektet. Fr eksempel vil analyse g designaktiviteter fte være innvative, mens selve kdingen må være strengt kntrllert. Det er bra med kreativitet i prblemløsning, men kanskje ikke fullt så bra når vi skal lage kde i henhld til en kdingsstandard. Ledelsesstil Det er t akser vi kan bruke fr å beskrive / vurdere en ledelsesstil: Relasjnsppmerksmhet graden av fkus på hver enkelt persns relasjner til andre persner i prsjektet. Oppgaveppmerksmhet graden av fkus på hva vi skal ppnå g hvrdan vi skal ppnå det. Dette kna illustreres med følgende diagram. Vis fig 5.1 i bka. De fire ledelsesstilene er sm følger: Separasjn passer best fr rutinearbeid. Byråkratisk, hierarkisk pplegg med rutiner g prsedyrer. Vi får en stabil g effektiv prsjektrganisasjn, men det er vanskelig å få til nen virkelig innvasjn. Relasjner flk trenger å bli mtivert, krdinert g tenger pplæring. Hver enkelt ppgave vil være gitt til en persn. Jbbene er kmplekse, spesialiserte g innvative. Beslutninger skjer gjennm møter g knsensus. Den viktigste suksessfaktren er en prsjektleder sm får dette til å funger i stedet fr at det skal degenerer til en evigvarende serie av møter g diskusjner. Engasjement mest effektivt når vi må jbbe under press fr eksempel tidspress. Denne ledelsesfrmen avhenger i str grad av en dyktig leder. Beslutninger blir ikke gjrt i møter, men er i str grad implisitt ved at deltakerne deler en felles visjn m ha de skal lage. Integrasjn. Fungere best når målet er uklart. Arbeidet vi i str grad være eksplrativt vi prøver ss fram, fr eksempel ved hjelp av prttyper g andre frmer fr eksperimenter. Prsjektleders ppgave er å stimulere g mtivere. Beslutningene blir tatt bttm-up på en ufrmell måte. Ledelsen må passe på at vi ikke mister målet av syne i all denne kreativiteten g eksperimenteringen. Prsjektrganisering Vi trenger en prsjektrganisasjn fr å få flk til å samarbeide mest mulig effektivt fr å nå et felles mål. Det er mange måter å gjøre dette på g vi skal bare krt vise nen av de prsjektrganisasjnene sm finnes i prgramvareindustrien. Hierarkisk rganisasjn Hierarkiske prsjekter er fte mdellert etter prsjektstrukturen g prduktstrukturen. Det finnes ett subprsjekt fr hvert delsystem, ett fr integrasjn, ett fr testing sv. Vis fig 5.2. De øverste lagene i prsjektstrukturen krdinerer arbeidet ved hjelp av standardisering g ved hjelp av regler g prsedyrer. Lenger ned i strukturen vil det kunne være andre måter å krdinere arbeidet på avhengig av hva slags arbeid det er. Nen av subprsjektene kan være svært standardiserte, mens andre kna være meget innvative. Dette er både styrken g svakheten i denne måten å jbbe på: Styrke delprsjektene kan rganiseres på den måten sm er mest effektiv fr den jbben de skal gjøre akkurat nå. Svakhet flere delprsjekter med hver sin rganisasjnsfrm vil kunne lede til kraftige kulturkllisjner sm kan bli et prblem i prsjektet.

78 I tillegg har vi det prblemet sm alle hierarkiske strukturer har: rdre går venfra g ned gjennm frsterkere alle legger på litt ekstra trøkk - g nedenfra g pp gjennm filter ingen har nensinne blitt belønna fr å kmme med dårlige nyheter. Matriserganisasjn Dette blir brukt i rganisasjner sm egentlig er rganisert i henhld til kmpetanse. Det finnes grupper fr databaser, grafikk, nettverk sv. hvert prsjekt settes sammen av flk fra de enkelte faggruppene g flk går tilbake dit når prsjektet er ferdig. Sammenhengen i prsjektet må ivaretaes av prsjektleder. Viss vi igjen ser på fig 5.1 vil denne måten å rganisere prsjektet på kreve en prsjektleder med høy ppgaveppmerksmhet mens den sm leder hver faggruppe må ha høy relasjnsppmerksmhet. Chief prgrammer rganisasjn En slik rganisasjn består i utgangspunktet av tre persner chief prgrammer, en assistent g en biblitekar. Disse har hver sine ppgaver: Chief prgrammer. Han gjør all design g implementerer de viktigste / vanskeligste delene av systemet. Assistent. Han er vikar fr chief prgrammer g vil fte ta seg av resten av implementeringa. Biblitekar. Tar seg av alt administrativt arbeid g dkumentasjn. Ekspertgruppe. Dette er bare en del av CPT viss jbben er fr str fr chief prgrammer eller viss man trenger ekspertise sm chief prgrammer ikke har. Det finns en del gde resultater fra å ha brukt CPT. Det første prblemet sm melder seg er Finnes det nk flk med så høy kmpetanse at dette er generelt gjennmførbart? Det ser ut til at svaret er Nei. Den stre frdelen med CPT ligger i det at det er lettere å få et lite antall mennesker til å jbbe effektivt sammen. På den andre side det er begrenset hva en liten gruppe mennesker kan får gjrt på rimelig tid. En variant av CPT har innført ei lita gruppe av likeverdige persner i stedet fr chief prgrammer g hans assistent. I tillegg har man innført en ny persn tester. Det er gså mulig å ta med et par nybegynnere i pplæringsstillinger. Nen ganger kan man la en av disse være biblitekar. SWAT SWAT er en frkrtelse fr Skilled With Advanced Tls g beskriver en rganisasjn sm strt sett bare passer i RAD Rapid Applicatin Develpment. Et prsjekt rganisert etter SWAT består av maks fire persner - generalister, sm helst skal jbbe i samme rm. Dette skaper effektiv kmmunikasjn i prsjektet. SWAT prsjekter pererer med et minimum av dkumentasjn fte bare nen slisser på en whitebard. Hvedideen i SWAT er å drive inkrementell utvikling basert på utstrakt gjenbruk, svært høynivå prgrammeringsspråk g utstrakt bruk av prgramgeneratrer fr eksempel 4GL.lederen i et SWAT prsjekt fungerer mtrent sm en frman på et bygg. Fr at et SWAT prsjekt skal lykkes, må deltakeren være svært mtivert. Åpen struktur Prsjekter sm er rganisert etter denne mdellen prøver å kmbinere t viktige faktrer: En åpen ledelsesstil med fkus på samarbeid. Prsjektet må ha en leder med teknisk kmpetanse sm kan ta avgjørelser når deltakeren ikke klarer å arbeide seg fram til et knsensus. Det er viktig å ha engasjenent i prsjektet slik at alle jbber mt et felles mål uten at man skal måtte ty til detaljppfølging. En ryddig / streng prsjektstruktur sm sørger fr at prsjektet ppfører seg på en frutsibar måte, fr eksempel i frhldet til planer g kstnader. Nen gde råd Pririter kvalitet framfr kvantitet. Små prsjektgrupper fungerer best, blant annet pga. at kmmunikasjn er en kritisk suksessfaktr. Ta hensyn til den kmpetansen, mtivasjnen g interessen sm finnes i prsjekt når ppgaven blir delt pp i mindre ppgaver g distribuert til deltakerne.

79 Pass på at alle i bedriften får anledning til å: Lære ny ting Delta på mråder de har lyst til ikke bare der de er best fr øyeblikket. Dette er særlig viktig å ta med i betraktning når vi ser det sammen med fregående punkt. Pass på å ha ei prsjektgruppe sm er velbalansert man trenger fr eksempel både eksperter på enkeltmråder g nen sm kan sørge fr at ekspertenes bidrag blir sydd sammen til et brukbart hele. Flk sm ikke passer inn i prsjektgruppa bør flyttes til et annet sted j før j heller dersm dette er mulig. Det er dessverre mange eksempler på prsjekter m har blitt ødelagt av interne knflikter. J mer et prsjekt er avhengig av samarbeid, entusiasme g mtivasjn, j farligere er interne knflikter Kapittel 19 Bruk av verktøy i utvikling av prgramvare blir fte referert til sm CASE Cmputer Aided Sftware Engineering. På et tidspunkt var det mange sm trdde at innføringen av CASE verktøy skulle løse alle eller de fleste prblemer. Dette har vist seg å være alt fr ptimistisk. Denne frlesningen har ikke til hensikt å gi nen innføring i bruk av CASE verktøy eller gi en kmplett versikt. I stedet er det nen smakebiter på hva sm finnes g hva det kan g ikke kan hjelp til med. Slik det ser ut nå vil nk prgramvareutvikling være mye mer menneskeintensivt enn verktøyintensivt i all verskuelig framtid. Det finnes flere typer CASE verktøy. Vis fig Legg merke til at vi deler CASE inn i t hveddeler verktøy g utviklingsmgivelser. Her kmmer nen få kmmentarer m hvert verktøy: Verktøy støtter en avgrensa aktivitet i utviklingsprsessen, fr eksempel testing eller verrdna design Verktøybenk en samling av (t eller flere) integrerte verktøy sm understøtter et avgrensa sett av aktiviteter, fr eksempel analyse g design. Utviklingsmgivelser skal i det minste i prinsippet understøtte hele utviklingsprsessen, fra kravanalyse til systemtest g vedlikehld. Utviklingsmgivelser kan videre deles pp i: Verktøysett - en samling av verktøy, vanligvis ikke fullstendig integrert. Språkmgivelser et sett av verktøy tilpasset utvikling i et gitt prgrammeringsspråk, fr eksempel Java. Slike verktøysett kan dra nytte av egenskaper ved språket g dermed gjøre en gd del sjekking autmatisk. Integrerte utviklingsmgivelser integrasjn av infrmasjn. Alle verktøyene jbber mt en felles database. All infrmasjn m systemet g dets kmpnenter ligger her. Prsessrienterte utviklingsmgivelser er mtrent det samme sm integrerte systemmgivelser, men er tilpasse den utviklingsprsessen vi bruker. Dette kan fr eksempel innebære at det ikke er lv å levere en kmpnent til CM-delen av databasen uten at det finns inf m at det kan gjennmgått enhetstesting g kdegransking. Ofte finner det sted en kntinuerlig utvikling av CASE verktøyene. Det kna begynne med ett eller flere frittstående verktøy sm så samles til en verktøybenk. Etter sm man lager flere g flere verktøy vil man sette de sammen til en utviklingsmgivelse sm man så senere integrerer. Når man har fått g erfaring med dette vil man kanskje til slutt legge på prsessinf fr å få en fullstendig utviklingsmgivelse. Fr å kunne karakterisere CASE verktøy er det frslått en flerfasettert mdell, sm vist i bka fig Dette er primært en måte å beskrive eller diskutere CASE verktøy på. Det etterfølgende er nen krte kmmentarer til hver: Supprtbredde hvilken av de fire kategriene ver hører verktøyet til Prblemtype sier ne m hva slags systemer / prblemer verktøyet passer fr Størrelse på systemet her delt pp i tre kategrier etter hva slags systemutvikling det passer til: stre systemer, middels stre systemer eller bare til utvikling av små systemer. Brukerskala sier ne m frhldet mellm CASE verktøyet g antall persner i prsjektet. En enkelt bruker. Dette er strt sett verktøy sm editrer, debuggere g kmpilatrer Grupper av brukere. Her må man i det minste i tillegg til det vi har ver inkludere CM verktøy g verktøy sm bygger systemer. Stre grupper av brukere. Nå blir det nødvendig å legge på en gd del regler fr hvrdan samarbeid skal skje, ansvar fr aktiviteter g lignende. Organisasjner. Her trenger vi i tilegg dkumentmaler, standarder, regler g støtte fr gjenbruk på alle plan sv. Prsesskala. Understøtter verktøyet prdukt, flk eller begge deler. Eksempler på disse t aspektene er:

80 Prdukt skrive kde, teste, knfigurere Flk planlegging av granskingsmøter, hlde styr på tidsfirster, ressursfrbruk sv. Prsesstøtte. Verktøy sm støter prsessen hjelper eller tvinger utvikleren til å følge en definert prsess, bruke de riktige dkumentene sv. nen verktøy støtter ingen prsesser, nen støtter en fast definert hardkda prsess, mens det gså finnes verktøy der man selv kan definere prsessen. Eksempel er Prcess Weaver. Eksekveringsparadigme. Dette går gså under betegnelsen enactment g frteller i hvilken grad verktøyet, ut fra et sett av regler, gjør ting på egen hånd. Dette kna gjøre på flere måter: Tilstandsmaskin når verktøyet er i en gitt tilstand utfører det et sett av definerte aksjner. Eksempel: Når en mdul er i tilstand ferdig gransket blir det lagt inn i CM databasen Petrinett når all nødvendig input til en aksjn freligger, blir aksjnen utført. Eksempel: når alle mdulene sm tilhører et subsystem er i tilstand Ferdig blir de lenket sammen til et subsystem Prduksjnsregler bruker ideer fra både tilstandsmaskiner g Petrinett. Er vanligvis på frmen Vi kan bygge X når a, b g c freligger. Vi vil se på nen eksempler på verktøy. Verktøysett - Unix Unix er det fremste eksempel på et verktøysett sm blir mye brukt. Det har en del egenskaper sm gjør at det er enkelt g fleksibelt, på trss av et brukergrensesnitt sm ser nærmest ufrståelig ut. De viktige egenskapene er: Filsystemet har en trestruktur. Alle filer har et eget, definert stinavn. Filkatalger er gså filer. Filstrukturen er enkel. Alle Unix filer er sekvenser av bytes g det finnes ingen filtyper. All systemprgrammer g de fleste brukerprgrammer tar input fra terminalen g gir utput til den samme terminalen. Dette kna imidlertid enkelt endres ved å definere ny inputkanal < input navn g > utput navn. Unix har en str mengde små, enkle g praktiske prgrammer fr de fleste ting en utvikler har behv fr. Ppulære eksempler er wc teller rd, tegn g linjer lpr skriver ut ei fil, grep finner tegnmønster, ls lister pp alle filer i stående katalg.. Lett å skjøte sammen prgrammer ved hjelp av en pipe symbl. Enkelt eksempel. ls lpr lager en liste av alle filer i stående katalg g printer den ut. Unix er ppulær hs en gruppe utviklere sm nærmest har laget seg sin egen stamme med språk, ritualer sv. nen ganger kna man få inntrykk av at det at Unix har en kryptisk brukergrensesnitt er et gde i seg selv det hlder fremmede ute. På den annen side er det enkelt å lage et brukervennlig språk på tppen av Unix g bruke alle de gde ideene sm finnes der. Språkavhengig mgivelser Omgivelser sm er språkavhengige bruker egenskaper ved det valgte språket til å hjelpe g støtte utviklerne. Viktig hjelp er fr eksempel: Mer effektiv editering når man taster inn et reservert rd så kmmer resten av strukturen på plass g er bare å fylle inn. Dette sikrer syntaktisk krrekt kde. Hjelp til debugging når prgrammet eksekveres kan systemet vise fram variabelnavn med verdier, hvilken gren av en IF..THEN sm blir valgt sv. det vil gså være mulig å definee at vi skal ha tilbake kntrllen på et gitt sted i kden breakpint. Her kan vi se på variable, endre verdier g så frtsette eksekveringen. Brwser dette er et hjelpemiddel fr å se på prgramverdier. Dette gjelder bjekter, attributter, meldingskøer sv. Referanse skjer via de navna vi har gitt når vi skrev kden. Prettyprinter et gdt hjelpemiddel når vi skal lese kden, fr eksempel i en kdegransking. Dette prgrammet gir innrykk i kde på definerte steder, fr eksempel etter hver IF-setning, etter hver { sv g tilsvarende når vi kmmer til fr eksempel }. Eksekvering av delvis kmplette prgrammer. Dette gjør at du kam skrive et prgram delvis ferdig. Når eksekveringen når deen uferdige biten fr utvikleren kntrllen tilbake g kan fr eksempel Skrive inn manglende kde, kmpilere g frtsette eksekveringen Sette inn nødvendige dataverdier g frsette på et valgt sted i prgrammet Slike løsninger krever vanligvis rask respnstid g et gdt grafisk brukergrensesnitt fr å være effektive.

81 Verktøybenk Det finnes flere slags verktøybenker. Det etterfølgende er bare eksempler. Se gså fig AWB Analyst Wrk Bench, fr de sm gjør systemanalyse PWB Prgrammer Wrk Bench, fr utviklere, de sm implementerer MWB Manger Wrk Bench, fr prsjektledelsen IPSE Integrated Prject Supprt Envirnment. Det etterfølgende er nen få kmmentarer til hver av disse verktøybenkene: AWB: kravanalyse g verrdna design. Dette skjer fte ved hjelp av diagrammer g en gde grafiske verktøy er viktige. Resultatene lagres i en database. I tilegg er det viktig å kunne: Oppdater g endre diagrammer Analysere krav g designbeslutninger med hensyn til kmpletthet g knsistens. Generere rapprter Lage enkel prttyper fr å kunne utfrske designalternativer PWB: implementasjn - editering g kmpilering - g testing. Verktøy fr kntrll med kildekde er viktig. Et eksempel på et slikt verktøy er SCCS Surce Cde Cntrl System. Se fig Ofte vil slike verktøy gså innehlde muligheter fr generering av testsdata g fr simulering. MWB: dette inkluderer verktøy fr knfigurasjnsstyring, kstnadsestimering, planlegging hvem gjør hva når. I tillegg kna det være aktuelt med verktøy fr pålitelighetsestimering, statusvurdering prsjektframdrift, ppnådd testdekningsgrad g lignende. IPSE: Dette er en samling / integrasjn av AWB, PWB g MWB. Mye av arbeidet sm er gjrt på dette mrådet har hatt sm mål å få til en gd infrastruktur sm gjør det lett å få alle verktøyene til å samarbeide. Ett eksempel på en slik infrastruktur er PCTE Prtable Cmmn Tl Envirnment. PCTE innehlder fire klasser av tjenester: Basismekanismer, fr å sette sammen, eksekvere g kmmunisere med de enkelte verktøyene. Det er viktig å kunne starte g stppe prsesser, I/O, filesystemer, meldingsutveksling mellm prsesser sv. Mekanismer fr å kunne kjøre systemet på en distribuert maskinvareplattfrm. Brukergrensesnitt unifrmt fr alle verktøy. Dette er viktig slik at man ikke skal behøve å hlde styr på like mange brukergrensesnitt sm det er verktøy. Verktøy fr å manipulere de bjektene sm finnes i databasen. Dette er det nye i IPSE, g kan best ppfattes sm et generalisert filsystem. De viktigste egenskapene er et sett med attributter sm beskriver hvert enkelt bjekt g lenker mellm bjektene. Eksempel på et mdulelement i en IPSE database. Mdulen har en Id g en status fr eksempel under implementasjn Den kan være lenket til det subsystemet den tilhører g til den persnen sm er ansvarlig fr å implementere den Det finnes mange IPSE systemer, men ingen av de har tatt helt av. De fleste er ne i bruk. Prsessentrerte mgivelser I en prsessentrert mgivelse er en IPSE eller en eller flere verktøybenker kblet sammen med en prsessbeskrivelse. Ofte inkluderer dette et verktøy fr prsessmdellering. Det finnes spesialverktøy sm Prcess Weaver, men det er gså mulig å bruke enkel, generelle ntasjner sm Petrinett. Vis fig 19.7 g frklar de viktigste mmentene i en Petrinett mdell. Frmelle mdeller av utviklingsprsesser må rimeligvis bli rigide. Det at det stadig finnes unntak fra de definerte reglene, gjør at disse verktøyene blir tungvinte å bruke. Viss vi ser på mdellen i fig 19.7 kan vi tenke ss følgende unntak sm eventuelt gså må mdelleres inn: Nen rter brt et møtereferat Ledelsen bestemmer at et planlagt review ikke er nødvendig fr eksempel på grunn av tidspress Møte må utsettes på grunn av sykdm Alt dette kna mdellers inn, men vil rakst føre til en svært kmplisert mdell. Det å utvikle, definere, debugge g vedlikehlde mdellen kan bli en str ppgave, sm vil kunne stjele tid fra den egentlige utviklingen. På den måten går de prsessentrerte utviklingsmgivelsene ver fra å være en hjelp til å bli et ekstra prblem.

82 Sluttkmmentarer Mange trdde på et eller annet tidspunkt av CASE verktøyene skulle løse mange av de prblemene prgramvareutviklerne st verfr g dermed gi ss bedre prgrammer bedre kvalitet raskere g billigere. Dette har imidlertid ikke hendt. Det kna være mange grunner til dette g det sm kmmer her er bare nen av mulighetene, men det er de jeg trr er viktigst: Hvedprblemene i prgramvareutvikling er ikke primært prgramvarerientert de skriver seg fra prblemer med å frstå kundens behv g prblemer. Det vi skulle trenge er verktøystøtte til å frstå g løse prblemer. Dette er imidlertid langt fra enkelt. Vi kan bare gi verktøystøte til det sm kan frmaliseres. Prgramvareutvikling er primært en innvativ, kreativ prsess g dermed vanskelig å frmalisere. De delene vi frstå fr eksempel språkdefinisjner er allerede frmalisert g autmatisert gjennm kmpilatrer. Stre frmaliserte systemer er tunge å bruke g krever str maskinkapasitet. Det kan føre til at vi får prblemer ved at verktøyet blir en flaskehals i utviklingen vanskelig å ppdater eller legg inn nye verktøy. Dette fører lett til at de snart gjør at vi må bruke gårsdagens løsninger på mrgendagens prblem en ikke altfr lystig tanke.