Lektion 8

1. Lektion 8 Arkitektur, lagdeling og pakker

2. Arkitektoniske view’s i UP(afspejles bl.a. Rational Rose’s mappestruktur) Softwarekonstruktion 8

3. Logicalview: Lagdeling/pakker - analyse Softwarekonstruktion 8

4. Arkitektonisk analyse • Hvilke pakker ? • Se fx på tætte strukturer i analysemodellen (arv og aggregeringer) • Associering er den løseste forbindelse • Se derefter på use cases ! Softwarekonstruktion 8

5. Eks. 1: Lagdelt arkitektur • Use case realisering indenfor en lagdelt arkitektur med grænsefladelag, managerlag, modellag og DBlag: • Grænsefladeklasser der håndterer interaktionen mellem aktøren og grænsefladen • Managerklasser der får ansvaret for at danne ”limen” mellem grænseflade- og domæneklasserne (medtages i et selvstændigt lag – eller i modellaget). Her fra styres use case afviklingen. • Modelklasser der findes ud fra domæne modellen af problemområdet. De modelklasser der understøtter use cases medtages • DBklasser der indpakker sql’en til databasen Softwarekonstruktion 8

6. Afprøvning af arkitektur • Lav interaktionsdiagrammet til den arkitekturbærende use case • Placer objekterne i de lag de hører til (der skal være objekter i alle lag) • Udarbejd koden • Afprøv! (baseline for elaboration) Softwarekonstruktion 8

7. Eks. 2: Arkitektur med lag og pakker Softwarekonstruktion 8

8. Eks 2 fortsat: Interaktion mellem lag/pakker Softwarekonstruktion 8

9. Design af subsystemer og interfaces • I design bliver • Analyse pakker til design subsystemer • Analyse klasser til designklasser og interfaces (jvf forrige lektion) • Design af subsystemer handler om at dele systemet op i så uafhængige dele som muligt • Der tages udgangspunkt i analysens pakker, som er designet ud fra principper om lav kobling og høj binding og • Som suppleres med interfaces, der er en separat specifikation (kontrakt), der adskiller funktionalitet fra dets implementering Softwarekonstruktion 8

10. Facade pattern Ved en ”front-end” eller facade der pakker subsystemet ind. Facade objektet repræsenterer et ens interface og er ansvarlig for samarbejdet til subsystemets komponenter Hvordan opfyldes krav om et fælles ens interface til helt forskelligartede implementeringer? Softwarekonstruktion 8

11. Anvendelse af facade • Facade mønstret simplificerer tilgangen til en samling af relaterede objekter ved at lave et objekt som alle objekter udefra bruger til at kommunikere med samlingen af objekter • Vil typisk kunne anvendes mellem de forskellige lag i den lagdelte arkitektur • Managerlaget er fx en facade, hvis acces sker gennem et objekt fx et ManagerInterface Softwarekonstruktion 8

12. Eks. 3. Interfaces og subsystemer - Design Softwarekonstruktion 8

13. Tilstandsdiagrammer

14. Tilstandsdiagrammer • Tilstandsdiagrammer kan bl.a. bruges til modellere dynamiske aspekter i et system • Er et objekts historie, livsforløb eller adfærdsmønster – eller systemtilstande i en use case. • Tilstand (state): • En tilstand eller situation i et objekts livsforløb, hvor visse betingelser er opfyldt, udfører noget aktivitet eller der ventes på nogle hændelser • Hændelse (event): • En øjeblikkelig begivenhed i tid og rum, som involverer en/flere objekter • Tilstandsovergang (transition): • Bevægelsen fra en tilstand til en anden som svar på en hændelse Softwarekonstruktion 8

15. Basis notation (State diagrams i Rose) Eksempel Reservation Softwarekonstruktion 8

16. Notation udvidet med handlinger og aktiviteter Tilstand Hændelse Softwarekonstruktion 8

17. Samlingspunkter Softwarekonstruktion 8

18. Beslutningspunkter Softwarekonstruktion 8

19. Call’s Softwarekonstruktion 8

20. Signaler Softwarekonstruktion 8

21. Anvendelse af tilstandsdiagrammer i analysen • Tilstandsdiagrammer over objekters livsforløb kan bruges til vurdering af: • Hvad skal der skal gemmes om livsforløbet? • Hvordan opdateres? • Livsforløb kan gemmes som kombinationer af: • Strukturer • Klasser • Attributter, eksempelvis statusattribut • Livsforløb opdateres gemmen use cases • For hver tilstand i tilstandsdiagrammet stilles følgende spørgsmål: • Skal tilstandes gemmes? • Kan tilstandene registreres i domænemodellen? • Er der defineret en use case til opdatering af tilstanden? • Især dynamiske klasser er interessante, fx ”aftale” klasser!!! Softwarekonstruktion 8

22. Øvelse 1: Lav tilstandsdiagrammer for Nør Halne bibliotek • Følgende hændelser er fundet vedr. objekter i klassen: Reservation • Reserveret (dato) • Annulleret (dato) • Besked sendt (dato, frist) • Afhentningsfrist overskredet (dato) • Udlånt (dato) • Følgende hændelser er fundet vedr. objekter i klassen: Udlån • Udlånt (dato, frist) • Afleveret (dato) • Afleveringsfrist overskredet (dato) • Rykker sendt (dato, frist) • Afleveret (dato, bøde) • Erstatning(dato, beløb) Softwarekonstruktion 8

23. Øvelse 2: Hvad skal registereres? Hvordan? (se domænemodellen næste slide) Tilstandsdiagram for Reservation Tilstandsdiagram for Udlån Softwarekonstruktion 8

24. 1. version af domæne model Softwarekonstruktion 8

25. Løsning: Justeret domænemodel Værdimængde: reserveret, hjemkommet, afhentet, annulleret Værdimængde: udlånt, hjemkaldt, afleveret Softwarekonstruktion 8

26. Opgave 1: Arkitektur for ”Camplet” • Kom med forslag til en overordnet arkitektur • Overvej opdeling af manager lag og model lag i logiske pakker • Overvej interfaces og subsystemer Softwarekonstruktion 8

27. Opgave 2: Tilstandsdiagrammer for Camplet” • Overvej vigtige hændelser på jeres aftaleklasse(r) • Lav et tilstandsdiagram for aftaleklassen(erne) • For hver tilstand i tilstandsdiagrammet stilles følgende spørgsmål: • Skal tilstandes gemmes? • Kan tilstandene registreres i domænemodellen? • Er der defineret en use case til opdatering af tilstanden? • Juster jeres domænemodel og use case diagram Softwarekonstruktion 8

28. Kvalitetssikring Test Review

29. Om test • Test udføres altid i henhold til specifikationer. • En test kan aldrig påvise korrekthed - kun tilstedeværelse af fejl! • En succesfuld test finder fejl!!! • Udvikleren skal ikke teste sig selv. • Et system er færdigtestet, når hyppigheden af fejl er reduceret til et forretningsmæssigt acceptabelt niveau!! Softwarekonstruktion 8

30. Testmodel En samling af • test-cases • test-procedurer • eksekverbare komponenter, som tester Omfatter typer af test: • modultest eller unit-test (klasseniveau) • integrationstest • systemtest Softwarekonstruktion 8

31. Modultest (unit-test) • Alle en klasses metoder skal testes • Black-box test ud fra specifikation (pre- og post-betingelser) • White-box test ud fra kendskab til intern struktur: • test grænsetilfælde og normaltilfælde Softwarekonstruktion 8

32. Integrations- og systemtest • Integrationstest skal finde fejl i måden moduler spiller sammen på og udføres efter hvert build. (Design by Contract er vigtigt.) • Systemtest skal finde fejl i systemet som helhed og udføres i slutningen af hvert gennemløb af implementations processen Softwarekonstruktion 8

33. Test cases • Test cases findes ud fra use case modellen • Hver test case tester et scenarium for en use case • En test case skal specificere input, forventet output og evt. betingelser for testen • Husk også belastningstest!!! Softwarekonstruktion 8

34. Test procedurer og komponenter • Test procedurer specificerer, hvordan en test gennemføres • kan være manuelle • eller - bedre - automatiske • Test komponenter - eller drivere • automatisering af test procedurer • Tilstræb design af test procedurer og -komponenter, så der er så meget genbrug som muligt Softwarekonstruktion 8

35. Nyt syn på test/XP - eXtremeProgramming (Kent Beck) • unit-test skrives før unit i en rytme, der siger: • ”skriv en test - skriv unitten - test den - skriv den næste test...” • dette har angiveligt følgende fordele: • unit-test bliver faktisk udført! • det giver en programmør tilfredshed at skrive en test, skrive noget kode og så se sin kode bestå testen • klassedesign bliver mere klart: man tvinges til at være helt præcis vedr. interface (metode-signaturer, specifikationer mv.) • programverifikation bliver bedre dokumenteret • større lyst til at ændre eksisterende kode (refactoring), da test-driverne er klare og lige til at køre. Softwarekonstruktion 8