Arkitektur, lagdeling og pakker

Præsentationer af emnet: "Arkitektur, lagdeling og pakker"— Præsentationens transcript:

1 Arkitektur, lagdeling og pakker
Lektion 8 Arkitektur, lagdeling og pakker

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

3 Logical view: 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 Hvordan opfyldes krav om et fælles ens interface til helt forskelligartede implementeringer? 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 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
Ø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 Omfatter typer af test: 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 - eXtreme Programming (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