1. Design II SAD design II

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

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

4. Delsys 1 Delsys 2 BGF SGF SGF BGF Funktion Funktion Model Model Eksempler på helhedsbeskrivelser af systemet Desuden: Design klasse diagrammer, samt System Architecture Document 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 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. SAD design II

7. Videnskab og kunst • 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 SAD design II

8. Øvelse: faktortabel og teknisk memo SAD design II

9. Pause inden komponent arkitektur SAD design II

10. Holdbarhedsanalyse SAD design II

11. SAD design II

12. 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 SAD design II

13. Arkitektoniske krav/ faktorer og faktor tabel SAD design II

14. Foreslå, undersøg og beskriv alternative løsninger SAD design II

15. Afvej hensyn, evaluer løsninger, afprøv arkitekturen, evaluer arkitekturen Afvejhensyn Uafvigelige krav og betingelser Forretningshensyn alle andre hensyn Evaluer del-løsninger • tekniske eksperimenter • Ekspertråd • reviews etc. 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 SAD design II

16. Beskriv, så du selv kan huske og andre forstå 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 SAD design II

18. Delsys 1 Delsys 2 BGF SGF SGF BGF Funktion Funktion Model Model 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 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 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) 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 SAD design II

22. Pause inden detail design SAD design II

23. Fra arkitektur til komponenter • Principper: • Respektér komponentarkitekturen • Tilpas komponenterne til de tekniske muligheder SAD design II

24. 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. Fra helhed til del SAD design II

25. Analysemodel for banksystem • Klassediagram • Hændelsestabel 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. 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 SAD design II

28. Repræsenter fælles hændelser • 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. 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 SAD design II

30. 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 Repræsentation af fælles hændelser: Løsning B 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 SAD design II

32. Øvelse: Design af modelkomponent SAD design II

33. Frokost SAD design II

34. Dette er et design klassediagram SAD design II

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

36. loop Objekters samarbejde for at løse en opgave SAD design II

37. SAD design II

38. 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) SAD design II

40. CRC eksempel SAD design II

41. Øvelse: CRC- spil SAD design II

42. Øvelse: Tegn sekvens diagram og klassediagram update SAD design II

43. Pause inden test 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! 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 SAD design II

46. BlackBox Testning Black Box Output Input Udtømmende inddata-testning med kontrol af resulterende output og af programmets reaktion 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 SAD design II

48. WhiteBox-testning Output Input Trace- list Logisk, styret afprøvning af alle programmets knudepunkter og ruter 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! SAD design II

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