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

Arkitektoniske view’s i UP (afspejles bl. a Arkitektoniske view’s i UP (afspejles bl.a. Rational Rose’s mappestruktur) 03-04-2017 Softwarekonstruktion 8

Logical view: Lagdeling/pakker - analyse 03-04-2017 Softwarekonstruktion 8

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 ! 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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) 03-04-2017 Softwarekonstruktion 8

Eks. 2: Arkitektur med lag og pakker 03-04-2017 Softwarekonstruktion 8

Eks 2 fortsat: Interaktion mellem lag/pakker 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

Eks. 3. Interfaces og subsystemer - Design 03-04-2017 Softwarekonstruktion 8

Tilstandsdiagrammer

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 03-04-2017 Softwarekonstruktion 8

Basis notation (State diagrams i Rose) Eksempel Reservation 03-04-2017 Softwarekonstruktion 8

Notation udvidet med handlinger og aktiviteter Tilstand Hændelse 03-04-2017 Softwarekonstruktion 8

Samlingspunkter 03-04-2017 Softwarekonstruktion 8

Beslutningspunkter 03-04-2017 Softwarekonstruktion 8

Call’s 03-04-2017 Softwarekonstruktion 8

Signaler 03-04-2017 Softwarekonstruktion 8

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!!! 03-04-2017 Softwarekonstruktion 8

Ø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) 03-04-2017 Softwarekonstruktion 8

Ø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 03-04-2017 Softwarekonstruktion 8

1. version af domæne model 03-04-2017 Softwarekonstruktion 8

Løsning: Justeret domænemodel Værdimængde: reserveret, hjemkommet, afhentet, annulleret Værdimængde: udlånt, hjemkaldt, afleveret 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

Kvalitetssikring Test Review

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!! 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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!!! 03-04-2017 Softwarekonstruktion 8

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 03-04-2017 Softwarekonstruktion 8

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. 03-04-2017 Softwarekonstruktion 8