Characteristics of a good design

Transkript

1 Characteristics of a good design (PPT. side 1) Innledning Høykvalitetsdesign bør ha visse karakteristikker for å oppnå kvalitetsprodukter, dvs.: enkelt å forstå enkelt å implementere enkelt å teste enkelt å modifisere riktig oversettelse fra kravspesifikasjonen

2 (PPT. side 2) Vi skal se nærmere på noen forhold som påvirker designkvaliteten (el kvalitetsdesign?) Komponent uavhengighet Unntaksbehandling Feiltoleranse Vi begynner med å se på komponent uavhengighet

3 (PPT. side 3) Komponent uavhengighet I de fleste designtyper streber vi etter størst mulig komponentuavhengighet. Årsaker til dette er blant annet: lettere å vite hvordan en komponent virker hvis den ikke er (intricately: vrien - floket) bundet opp til andre lettere å modifisere en uavhengig komponent uavhengige komponenter hjelper oss til å isolere og rette feil hvis systemfeil spores tilbake gjennom koden

4 (PPT. side 4) For å oppdage og måle graden av komponentuavhengighet i design, har vi tatt for oss to konsepter: Kobling (coupling) Samhørighet (cohesion)

5 (PPT. side 5) Kobling Her er det snakk om koblingen mellom komponenter. Graden av kobling kan deles i flere nivåer: Ukoplet Ingen avhengigheter mellom komponentene Lett kobling Noe avhengighet, men forbindelsen mellom komponentene er svak Høy kobling Dette vi si mange avhengigheter mellom komponentene I praksis vil som regel en total komponentuavhengighet være så å si umulig. Målet er derfor ikke nødvendigvis total uavhengighet, men heller å holde graden av kobling så lav som mulig. Hvorfor lav kobling? Tillater oss å forandre en del av system designet med minst mulig grad av forstyrrelse Lettere å bytte ut komponenter Færre komponenter påvirkes eller må forandres ved forandring/modifikasjon av en annen komponent

6 (PPT. side 6) Koblingen kan måles på en skala av avhengighet som strekker seg fra total uavhengighet til total avhengighet. Content coupling Høy Common coupling Control coupling Stamp coupling Lett Data coupling Uncoupled Lav Typer kobling: Content coupling Den minst ønskelige koblingen. Her modifiserer en komponent en annen. Den modifiserte komponenten blir totalt avhengig av den andre. Common coupling Dette er organisert slik at data er tilgjengelig fra en felles datakilde. Avhengighet eksisterer fortsatt. Det kan være vanskelig å oppdage hvilken komponent som er ansvarlig for å ha gitt en variabel en spesiell verdi. Control coupling Her sender en komponent parametrere for å kontrollere aktiviteten til en annen komponent. Den kontrollerte komponenten kan ikke fungere uten hjelp av den andre. Stamp coupling Her brukes en datastruktur for å sende informasjon fra en komponent til en annen. Det er selve datastrukturen som sendes, og dataverdier, format og organisering må stemme mellom de samarbeidende komponenter. Data coupling Her sendes bare data mellom komponentene. Denne er enklere og gir mindre rom for feil fordi det er lettere å spore data samt å gjøre forandringer. Uncoupled Ingen kobling mellom komponentene. I praksis umulig?

7 (PPT. side 7) Samhørighet (cohesion) Det er slik at mens kobling tar for seg avhengigheten mellom komponenter, så tar samhørigheten for seg den interne måten en komponent er konstruert på. En komponent er samhørende hvis alle elementene i den er rettet mot, og essensielle for, utfører samme gjøremål. Det finnes flere nivåer av samhørighet: Functional (funksjonell) Høy Sequential (sekvensiell) Communicational Procedural Temporal (temporær) Logical (logisk) Coincidental (tilfeldig) Lav Beskrivelse av typene: Coincidental (tilfeldig) Dette er den verste graden, og finnes i en komponent der delene er urelatert til hverandre. Urelaterte funksjoner, prosesser eller data finnes i samme komponent fordi dette tilfeldigvis gjør arbeidet lettere for utvikler. (eks. en komponent som både sjekker en brukers sikkerhetsklassifisering og skriver ut denne ukes lønningsliste) Logical (logisk) Her er flere logisk relaterte funksjoner eller dataelementer plassert i samme komponent. De er ikke funksjonelt relatert til hverandre. (eks. komponent som leser inn alle typer input (fra bånd, disker el. kom. porter) uavhengig av formålet med dataene) Temporal (temporær) Noen ganger brukes en komponent for å initialize et system eller ett sett av variabler. En slik komponent utfører flere funksjoner i sekvens, men funksjonene er kun relatert av involvert timing.?

8 Procedural (rekkefølge) Funksjoner som blir gruppert i en komponent bare for å sikre en bestemt rekkefølgen. (eks. tar imot data dataene sjekkes dataene blir manipulert) Communicational (kommunikasjon) Funksjoner som samles i en komponent fordi de opererer på, eller produserer, det samme datasettet. (eks. har kun en disk- eller tapetilgang: urelaterte data hentes sammen) (Dårlig forklaring) Sequential (sekvensiell) I en slik komponent er output fra en del input til neste del. (Ikke konstruert basert på funksjonell relasjon. Er derfor mulig at komponenten ikke vil constrain tvinge/legge bånd på all prosessering relatert til en funksjon.? Functional (funksjonell) Idealet! Alle funksjoner i komponenten er essensielle for utførelsen av en enkelt funksjon. Komponenten utfører bare funksjonen den er konstruert for å utføre og ingenting annet.

9 (PPT. side 8) Exception handling Når vi driver med design bør vi forsøke å forutse situasjoner som kan føre til problemer med systemet. Dette er ikke lett fordi kravspesifikasjonen, som gjør det klart hva systemet skal gjøre, ikke nødvendigvis forteller hva det ikke skal gjøre. Derfor er det viktig å inkludere exception handling i våres design. Typiske exceptions inkluderer: Klarer ikke å utføre tjeneste Skaffer feil data eller tjeneste Ødelagte data Virkelige eksempler: - harddisken har ikke mer lagringsplass - systemets minne er fult For hver identifisert exception kan vi handle på en av tre måter: Forsøke på nytt Gjenoppretter systemets tilstand slik det var før unntaket inntraff, og forsøker å utføre tjenesten på nytt ved bruk av en annen strategii Rette Gjenoppretter systemet, retter noen aspekter ved det og forsøker igjen å utføre tjenesten ved bruk av samme strategi Rapportere Gjenoppretter systemet, rapporterer problemet og utfører ikke tjenesten. Definisjoner: En exception En uvanlig hendelse som forstyrrer et programs normale flyt Exception handling Prosessen som går ut på å oppdage og handle på exceptions på en konsistent og pålitelig måte Exception vs feil Uttrykket exception brukes istedenfor feil fordi exceptions representerer unormale eller uvanlige forhold som nødvendigvis ikke er feil.

10 (PPT. side 9) DERFOR: For hver tjeneste vi ønsker at vårt system skal utføre må vi identifisere måter det kan feile finne måter å redde det fra feil Her finnes det teknikker som brukes for å hjelpe oss å identifisere disse unntaksforholdene. Dette vil bli gjennomgått i senere presentasjoner. o fault tree analysis (neste kapittel/gruppe) o failure mode analysis (kapittel 9) Det finnes flere teknikker som kan brukes i design for å fange exceptions mens koden kjøres: Checksums og sjekk av tall For å dobbeltsjekke riktigheten til og utregninger Timere

11 (PPT. side 10) Fault Tolerance Systemets evne til å reagere fornuftig på uventede hardware- eller softwarefeil Design skal forsøke å forutse feil og behandle dem på måter som minimaliserer forstyrrelse og maksimerer sikkerhet. Målet er å lage koden så feilfri som mulig ved å legge feilforebygging og feilbehandling inn i designet. En karakteristikk på god design er måten den forhindrer eller tolererer feil. I stedet for å vente på at systemet skal feile og så fikse problemet kan designerne: forutse hva som kan skje og konstruere systemet slik at det reagerer på en akseptabel måte. Det vil si at man inntar en aktiv rolle for å oppdage feil. (Fault correction (Rette feil)) Når feil oppdages må de rettes. Normalt skal feilretting: fikse skadene som feilen førte til forandre produktet slik at feilen fjernes Vår design må inkludere en strategi for behandle feil. To forskjellige strategier er: stoppe systemet når en feil affiserer systemet registrere feilen og systemets status når feilen oppsto, slik at man kan gå tilbake og rette skaden senere Hvor kritisk systemet er avgjørende for valg av strategi. Innenfor områder i luftfart vil for eksempel den første strategien passe svært dårlig. Fault tolerance (Feil toleranse) Mange ganger vil retting av feil bli for dyrt, risikabelt eller upassende. Forsøk har også vist at det praktisk talt er umulig å produsere 100 % feilfri software. Derfor trengs noe for å: hindre at feil i software forårsaker systemkatastrofe maskere softwarefeil hvis mulig Vår design må minimalisere skaden som feilen førte til og så fortsette med liten forstyrrelse for brukerne. Et eksempel kan være et banksystem som svitsjer over til en backup-prosessor, eller lager dobbelt kopi av data og transaksjoner, hvis en prosessor feiler.

12 (PPT. side 11) Det finnes flere strategier for feiltoleranse. Eksempler kan være: Strategier som avhenger av evnen til å forutse hvor feil vil oppstå og når de vil kunne inntreffe. Designerne må være i stand gjette hva som kan gå galt. Strategier som isolerer områder hvor det er sannsynlig at feil kan inntreffe. Neste gruppe vil se på teknikker som skal hjelpe til å lage designet feiltolerant uten å tilføye risiko.

13 (PPT. side 12) Webside Takk for oss J