Design II oktober 2009 gtj SAD design II.

Præsentationer af emnet: "Design II oktober 2009 gtj SAD design II."— Præsentationens transcript:

1 Design II oktober 2009 gtj SAD design II

2 Dagsplan Design processen – Arkitektoniske krav
Arkitektur og overordnet design Detail design (klassediagrammer og sekvens diagrammer) 12.00 – Frokost Design af model komponenten Design af en use-case Komponenter, lav kobling og høj samhørighed Test Design standarder og produktreviews oktober 2009 gtj SAD design II

3 Systemanalyse og design
Arkitektur Et godt system er et system uden væsentlige mangler oktober 2009 gtj SAD design II

4 Eksempler på helhedsbeskrivelser af systemet
Delsys 1 Delsys 2 Model Funktion BGF SGF Desuden: Design klasse diagrammer, samt System Architecture Document oktober 2009 gtj SAD design II

5 Faktor tabel For at kunne lave en arkitektur uden ”væsentlige svagheder” ved at skaffe sig overblik at undgå at glemme noget at undgå at undervurdere noget bevidst at kunne afveje alle faktorer Faktor Mål og kvalitets- scenario Fleksibilitet Virkning Vigtighed Risiko/ sværhedsgrad oktober 2009 gtj SAD design II

6 Arkitektoniske krav /faktorer
Kravspecifikationen fra analysen Funktionelle (nogle) og IKKE-funktionelle krav (stort set alle) Design kriterier … fra OOA&D Tekniske muligheder for produktet Udstyr (eksisterende og nyt, genbrugbare indkøbte eller freeware komponenter) Udviklingsforhold Folk (kompetencer og erfaring) kram (adgang til passende værktøjer) Organisatorisk (kontrakter, planer for videreudvikling) Samles i en FAKTOR-tabel (over faktorer der kan påvirke arkitekturen), beskrives, vurderes og prioriteres Udfra disse søges løsnings muligheder. oktober 2009 gtj SAD design II

7 Videnskab og kunst Løsninger beskrives i tekniske memo’er:
Videnskaben er at finde og beskrive Kunsten er at finde passende løsninger Løsninger beskrives i tekniske memo’er: Afvej hensyn Afhængigheder (U-) Alternativer oktober 2009 gtj SAD design II

8 Øvelse: faktortabel og teknisk memo
oktober 2009 gtj SAD design II

9 Pause inden komponent arkitektur
oktober 2009 gtj SAD design II

10 Holdbarhedsanalyse oktober 2009 gtj SAD design II

11 oktober 2009 gtj SAD design II

12 Læg planer for HELHEDEN
Arkitektur processen Læg planer for HELHEDEN KRAV Arkitektur produkter Undervejs Faktortabel Tekniske memo’er Kørende dele af systemet Design beskrivelser af dele af systemet (seq-diag., kl-diag.) Resultat – en række views /beskrivelser Logisk Process Deployment Data Use case Implementering Flere? Prøve, undersøge, etc. Test på DELE VALG oktober 2009 gtj SAD design II

13 Arkitektoniske krav/ faktorer og faktor tabel
oktober 2009 gtj SAD design II

14 Foreslå, undersøg og beskriv alternative løsninger
oktober 2009 gtj SAD design II

15 Pick your battles – don’t goldpate
Afvej hensyn, evaluer løsninger, afprøv arkitekturen, evaluer arkitekturen Evaluer del-løsninger tekniske eksperimenter Ekspertråd reviews etc. Afvej hensyn Uafvigelige krav og betingelser Forretningshensyn alle andre hensyn Afprøv arkitekturen vælg de dele af systemet som ”spænder arkitekturen ud” Lav dem Evaluer arkitekturen mhp. dem Evaluer arkitekturen Pick your battles – don’t goldpate oktober 2009 gtj SAD design II

16 Beskriv, så du selv kan huske og andre forstå
oktober 2009 gtj SAD design II

17 Arkitektur OOA&D Principper at udarbejde en arkitektur:
Fastlæg og prioriter kriterier /faktorer Byg bro mellem kriterier/faktorer og teknisk platform Afprøv designet så tidligt som muligt Principper for et godt design Et godt design har ingen væsentlige svagheder Et godt design balancerer flere kriterier (ønskede egenskaber ved en arkitektur) Et godt design er brugbart, fleksibelt og forståeligt oktober 2009 gtj SAD design II

18 Arkitektur og komponent design
Komponent: en samling programdele, som udgør en helhed og har et veldefineret ansvar S.198: Modelkomponenten: model af problemområdet FunktionskomponentenFunktionalitet på modellen Grænsefladekomponenten: Interaktion mellem funktion og og brugere Beskrives i klassediagram Delsys 1 Delsys 2 Model Funktion BGF SGF oktober 2009 gtj SAD design II

19 Afhængigheder mellem komponenter: Forbind klasser
Komponent: En samling af programdele, der udgør en helhed og har et veldefineret ansvar Forbindelse: Realisering af en afhængighed mellem komponenter. Aggregering Specialisering Kald oktober 2009 gtj SAD design II

20 Tilstræb lav Kobling Ideal: lav kobling
To klasser/komponenter har høj kobling, hvis ændring i den ene kræver ændring i den anden Faldende koblingsgrad: Kobling fra siden (ikke Java) Kobling nedefra Kobling indefra Kobling udefra (side 267) oktober 2009 gtj SAD design II

21 Tilstræb høj Samhørighed
Ideal: høj samhørighed Egenskaber ved høj samhørighed: Delene er begrebsmæssigt beslægtede Delene udgør funktionelle helheder Delene beskriver velafgrænsede tilstande Operationer bruger hinanden Opdeling af klasser eller komponenter med høj samhørighed fører til høj kobling oktober 2009 gtj SAD design II

22 Pause inden detail design
oktober 2009 gtj SAD design II

23 Fra arkitektur til komponenter
Principper: Respektér komponentarkitekturen Tilpas komponenterne til de tekniske muligheder oktober 2009 gtj SAD design II

24 Fra helhed til del Komponent: En samling af programdele, der udgør en helhed og har et veldefineret ansvar Modelkomponentens ansvar: Vedligeholde en opdateret repræsentation af problemområdet. oktober 2009 gtj SAD design II

25 Analysemodel for banksystem
Klassediagram Hændelsestabel oktober 2009 gtj SAD design II

26 Repræsenter private hændelser
Sekvens og selektion Repræsenter disse hændelser som en tilstandsattribut i den klasse, som beskrives ved tilstandsdiagrammet. Hver gang en af hændelserne forekommer, skal systemet tilordne en ny værdi til tilstandsattributten. Integrer hændelsernes attributter i klassen. Iteration Repræsenter disse hændelser som en ny klasse, der med en aggregeringsstruktur knyttes til den klasse, som beskrives ved tilstandsdiagrammet. Hver gang hændelsen forekommer, skal systemet generere et nyt objekt af den nye klasse. Integrer hændelsens attributter i den nye klasse. oktober 2009 gtj SAD design II

27 Repræsentation af private hændelser
Hændelsen ‘adresse ændret’ er privat for klassen Kunde og indgår som en iteration i klassens tilstandsdiagram Repræsenteres som en ny klasse Hændelsen ‘kreditgodkendt’ er privat for klassen Kunde og indgår som en sekvens Repræsenteres som en attribut oktober 2009 gtj SAD design II

28 Repræsenter fælles hændelser
Hvis hændelsen indgår i tilstandsdiagrammerne på forskellig måde, repræsenteres den i tilknytning til den klasse, som giver den enkleste repræsentation. Hvis hændelsen indgår i tilstandsdiagrammerne på samme måde, må du afveje de mulige repræsentationer i forhold til hinanden. oktober 2009 gtj SAD design II

29 Repræsentation af fælles hændelser: Løsning A
Hændelserne ‘indsat’ og ‘hævet’ indgår som iteration i to klasser. Hændelserne kan repræsenteres som nye klasser under Konto oktober 2009 gtj SAD design II

30 Repræsentation af fælles hændelser: Løsning B
Alternativt kan hændelserne repræsenteres som nye klasser under Kunde Giver en kompleks struktur (to associeringer på tværs) Derfor vælges løsning A oktober 2009 gtj SAD design II

31 Omstrukturer klasser (1)
Det reviderede klassediagram kan repræsentere den information, som findes i tilstandsdiagrammerne. Klassediagrammet kan ofte forenkles uden tab af information oktober 2009 gtj SAD design II

32 Øvelse: Design af modelkomponent
oktober 2009 gtj SAD design II

33 Frokost oktober 2009 gtj SAD design II

34 Dette er et design klassediagram
oktober 2009 gtj SAD design II

35 Dette er Fowler’s eksempel (fokuseret på modellaget)
attributter Operationer Generaliseringer Noter Associationer oktober 2009 gtj SAD design II

36 Objekters samarbejde for at løse en opgave
loop Objekters samarbejde for at løse en opgave oktober 2009 gtj SAD design II

37 oktober 2009 gtj SAD design II

38 oktober 2009 gtj SAD design II

39 C(lass)R(esponsibility)C(ollaboration)-kort
Rolle spil om fordeling af ansvar og opgaver En gruppe designere Hver spiller en klasse Fordeler ansvaret for en opgave, som stilles (en henvendelse fra “skærmen” – stillet af en usecase) oktober 2009 gtj SAD design II

40 CRC eksempel oktober 2009 gtj SAD design II

41 Øvelse: CRC- spil oktober 2009 gtj SAD design II

42 Øvelse: Tegn sekvens diagram og klassediagram update
oktober 2009 gtj SAD design II

43 Pause inden test oktober 2009 gtj SAD design II

44 At teste er ... Man afprøver programmer for at finde flest mulige fejl? Man tester for at sikre sig at programmer fungerer fejlfrit? Et program er fejlfrit - indtil det modsatte er bevist. En test er vellykket, når - ingen fejl blev afsløret! Et program er altid fejlbehæftet - og den sidste fejl er ikke fundet endnu! En test er vellykket, når - der er afsløret flest mulige fejl! oktober 2009 gtj SAD design II

45 Hvad er fejl? Programmet gør ikke hvad det skal
Programmet gør noget, det IKKE skal Programmet gør hvad det skal, men det, det skal gøre, er forkert specificeret eller designet oktober 2009 gtj SAD design II

46 BlackBox Testning Black Box Output Input
Udtømmende inddata-testning med kontrol af resulterende output og af programmets reaktion oktober 2009 gtj SAD design II

47 Korrekt /fuldstændig Blackbox testning forudsætter:
Uendelige datamængder: formelt valide formelt invalide logisk valide logisk invalide relevante irrelevante i varierende volumen i legal sekvens i illegal sekvens oktober 2009 gtj SAD design II

48 Logisk, styret afprøvning af alle programmets knudepunkter og ruter
WhiteBox-testning Output Input Trace- list Logisk, styret afprøvning af alle programmets knudepunkter og ruter oktober 2009 gtj SAD design II

49 Korrekt / Fuldstændig WhiteBox testning:
Alle logiske veje afprøves Alle knudepunkter afprøves Alle programinstruktioner afprøves Alle berørte programvariables værdi kontrolleres før og efter hver enkelt instruktions udførelse Ulempe: antallet af kombinationsmulig-heder bliver hurtigt astronomisk stort! oktober 2009 gtj SAD design II

50 Test i projekter Testplanlægning Accept test
Modultest: Unit test, brugsmønster test Integrationstest oktober 2009 gtj SAD design II

51 V - modellen Brugsmønstre og funktioner
Udfør brugsmønstre og funktioner Planlæg Sammenhængende dele designet (komponenter, lag, algoritmer mm) Planlæg Integrationstest dele testes i sammenhæng Planlæg Planlæg Modul test Moduler designet Moduler kodet Dokumenter ALLE typer test!!! oktober 2009 gtj SAD design II

52 Modul test Dokumentation (eksempel) Unit test primært Modul Testdato
Udv. Tester Fejl nr. Fejl beskr. Rettet dato oktober 2009 gtj SAD design II

53 Integrationstest Moduler samles til komponenter og testes
Checklister kan udarbejdes og benyttes White and black Dokumenteres mindst som for unit test Komponent Testdato Udv. Tester Fejl nr. Fejl beskr. Rettet dato oktober 2009 gtj SAD design II

54 På vej til accept ? Vi tester hvad brugeren vil teste – blot først
Lager test Præstations test Konfigurations test Genopretnings test Dokumentations test Funktionalitets test (Brugsmønstre) Volumen test Stress test Brugbarheds test Sikkerheds test - afhængigt at designkriterier, ik? oktober 2009 gtj SAD design II

55 Brugsmønster test Brugsmønstre der dækker den funktionalitet som skal testes udvælges. En række test scenarier (brugsmønster med udvalgte data) beskrives – forventet resultat “gættes” Brugsmønsterne gennemføres og fejl dokumenteres Fejlrettelser gennemføres og test gennemføres igen … oktober 2009 gtj SAD design II

56 Brugsmønster test dokumentation
BM Test sce narie Test dato Udv. Tester Fejl nr. Fejl beskr. Ret tet dato Henvis til krav spec. Et antal test data sæt (bilag Den an- svar- lige + scenarie nr. oktober 2009 gtj SAD design II

57 Økonomi i test Fuldstændigtest er svær eller ikke mulig hverken tidsmæssigt elle økonomisk (automatiseret test bidrager dog godt) Test særligt de programdele, der erfaringsmæssigt bevirker flest fejl Brug velafprøvede test principper oktober 2009 gtj SAD design II

58 Test-principper - planlægning
Planlæg altid test grundigt Checklister, dokumentationsformer / skabeloner test dele (hvad er et modul?) inddata/testcases Test tids- og ansvarsplan Beregn gode inddata /testcases der ”kommer rundt” oktober 2009 gtj SAD design II

59 Test-principper - udførsel
Vælg både korrekte testdata og invalide og endda irrelevante testdata Test for at fremkalde både korrekt og forkert program opførsel (elefanttest) Lad altid en anden programmør teste dit program! Test data kan også genbruges oktober 2009 gtj SAD design II

60 Test-principper - resultatet
Check altid resultatet af hver enkel test omhyggeligt! Jo flere fejl I har fundet – jo flere er der rent statistisk Hver gang I retter en fejl er der stor risiko for at I introducerer mindst en ny (eller flere) – pas på! Det er endnu mere udfordrende at teste godt end at kode godt – vær vågen… oktober 2009 gtj SAD design II

61 Hvornår er vi færdige med at teste?
Det ved vi aldrig Når tid eller penge udløber Når der ikke findes flere fejl Hvornår er I færdige? Når I har vist os, I kan unit teste, integrationetest og funktionalitetsteste ++ oktober 2009 gtj SAD design II

62 Test arbejdet i projektet
Testplaner for Systemtest - Brugsmønstre gennemføres med på forhånd passende udvalgte test data. Integrationstest – test at delene virker I sammenhæng (Moduler er sat sammen og virker sammen) Modul test – moduler virker hver for sig ~ unit-test For en sammenhængende del af systemet Test - udfør de planlagte test’s Dokumenter test gennemførelse og resultater oktober 2009 gtj SAD design II