Download præsentationen
Offentliggjort afSten Henningsen Redigeret for ca. et år siden
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
Lignende præsentationer
© 2024 SlidePlayer.dk Inc.
All rights reserved.