design ii n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Design II PowerPoint Presentation
Download Presentation
Design II

Loading in 2 Seconds...

play fullscreen
1 / 62

Design II - PowerPoint PPT Presentation


  • 295 Views
  • Uploaded on

Design II. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Design II


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  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