Design II oktober 2009 gtj SAD 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 Design standarder og produktreviews oktober 2009 gtj SAD design II

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

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

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

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

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

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

Pause inden komponent arkitektur oktober 2009 gtj SAD design II

Holdbarhedsanalyse oktober 2009 gtj SAD design II

oktober 2009 gtj SAD design II

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

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

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

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

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

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

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

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

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

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

Pause inden detail design oktober 2009 gtj SAD design II

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

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

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

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

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

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

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

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

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

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

Frokost oktober 2009 gtj SAD design II

Dette er et design klassediagram oktober 2009 gtj SAD design II

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

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

oktober 2009 gtj SAD design II

oktober 2009 gtj SAD design II

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

CRC eksempel oktober 2009 gtj SAD design II

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

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

Pause inden test oktober 2009 gtj SAD design II

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

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

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

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

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

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

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

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

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

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

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

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

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

Ø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

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

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

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

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

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