Lektion 8

Lektion 8Lektion 8Arkitektur, lagdeling og pakker

Arkitektoniske view’s i UPArkitektoniske view’s i UP(afspejles bl.a. Rational Rose’s (afspejles bl.a. Rational Rose’s mappestruktur)mappestruktur)

19-04-23 2Softwarekonstruktion 8

Logical view: Logical view: Lagdeling/pakker - analyseLagdeling/pakker - analyse

«komponent»Lag i+1

• • • •«komponent»

Deli,n

«komponent»Lag i

«komponent»Deli,2

«komponent»Deli,1

• • • •«komponent»

Deli-1,m

«komponent»Lag i-1

«komponent»Deli-1,2

«komponent»Deli-1,1

Lag: beskriver enkomponents ansvar vedhvilke operation, dertilbydes opad og hvilkeder udnyttes nedefra

Del: Ingen væsentliginteraktion med andre delei samme lag

Lukket arkitektur: kunanvende operationer pådet umiddelbart under-liggende lag

Åben arkitektur: anvendealle underliggende lag


Arkitektonisk analyseArkitektonisk 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 !


Eks. 1: Lagdelt arkitektur 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


Afprøvning af arkitekturAfprøvning af arkitekturLav interaktionsdiagrammet til

den arkitekturbærende use casePlacer objekterne i de lag de

hører til (der skal være objekter i alle lag)

Udarbejd kodenAfprøv! (baseline for elaboration)


Eks. 2: Arkitektur med lag Eks. 2: Arkitektur med lag og pakkerog pakker

Log4J

Technical Services

Domain

UI

Persistence

DBFacade

Sales

Register Sale

Swing

ProcessSaleFrame

Jess SOAP

for applications with only a few system operations, perhaps only one object acts as the facade into the layer

The Technical Services layer typically exposes many interfaces--at least one per subsystem


Eks 2 fortsat: Interaktion Eks 2 fortsat: Interaktion mellem lag/pakker mellem lag/pakker

: Domain::Sales::

Register

:Cashier

: UI::Swing::Process

SaleJFrame

enterItem(id, qty)

1: Tech-

Services::Persistence::Persistence-

Facade

desc = getProductDesc(id)

x = isInvalid(lineItem, sale)

desc = getObject(...,id)

1: Domain::POSRule-Engine::

POSRule-EngineFacade

enterItem(id, qty)

s : Domain::Sales::Sale

: Domain::Products::ProductCatalog

makeLineItem(desc, qty)

«subsystem»: Tech-

Services::Jess

someJessCalls(lineItem, sale)

Points of crossing interesting boundaries or layers. These are especially noteworthy for people who need to understand the system, and thus are highlighted in this diagram. This diagram supports communicating the logical view of the architecture (a UP term) because it emphasizes architecturally significant information.

UML notation: Note that a subsytem can be modeled as an object in the UML.

This is useful in this case where I don't know or want to describe the details of how the Jess rule engine works, but just want to show collaboration with it.

UML notation: UML path name to indicate packaging

onPropertyEvent(s, "sale.total", total)


Design af subsystemer og Design af subsystemer og interfacesinterfacesI 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


Facade patternFacade 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


Anvendelse af facadeAnvendelse af facadeFacade 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


Eks. 3. Interfaces og Eks. 3. Interfaces og subsystemer - Designsubsystemer - Design


TilstandsdiagrammerTilstandsdiagrammer

TilstandsdiagrammerTilstandsdiagrammer 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


Basis notation (State Basis notation (State diagrams i Rose)diagrams i Rose)

Tilstand1

Tilstand2

hændelse( attributter )[ betingelse ]

Start

Tilstand

Slut

Tilstandsovergang

Hændelse

Vent

Klar

Reservation registreres

Reservation afsluttes( dato )

Reservation bekræftes( dato )

[ Svarfrist overskrides ]

Eksempel Reservation


Notation udvidet med Notation udvidet med handlinger og aktiviteterhandlinger og aktiviteter

Tilstand

Hændelse


SamlingspunkterSamlingspunkter


BeslutningspunkterBeslutningspunkter


Call’sCall’s


SignalerSignaler


Anvendelse af Anvendelse af tilstandsdiagrammer i tilstandsdiagrammer i analysenanalysen 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!!!


Øvelse 1: Lav Øvelse 1: Lav tilstandsdiagrammer for Nør tilstandsdiagrammer for Nør Halne bibliotekHalne 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)


Øvelse 2: Hvad skal Øvelse 2: Hvad skal registereres? Hvordan? (registereres? Hvordan? (se se domænemodellen næste slide)domænemodellen næste slide)

Tilstandsdiagram for Reservation

Genstand registreret

Klar

Reservation registreres

Reservation bekræftes( dato, frist )

[ Svarfrist overskrides ]

[ Reservationsfrist overskrides ]

Reservation annulleres( dato )

Genstand afhentet

Besked sendes( dato, frist )

Genstand udlånt

Genstand udlånes( dato, frist )

Genstand hjemkaldes

Genstand afleveres( dato )

Afleveringsfrist overskrides( dato )

Rykker udskrives( dato, frist )

Genstand aflevers( dato, bøde )

Erstatning opkræves( dato, beløb )

Tilstandsdiagram for Udlån


1. version af domæne 1. version af domæne modelmodel

BogCD

genre

FremmedBog

udlånsBibliotekreturDato

Låner

navnadressepostnummerbynavntelefonnremailbrugerIdkodeOrd

Reservation

reservationsDato

0..*

1

0..*

1

Udlån

udlånsDatoafleveringsDato

0..*

1

0..*

1

Genstand

titeludgivelsesÅrkunstner/forfatterforlag/selskabisbnNr/idNr

0..* 10..* 1

Eksemplar

eksemplarNrreolPlads10..* 10..*

0..*

11

0..*


Løsning: Justeret Løsning: Justeret domænemodeldomænemodel

0..*

BogCD

genre

FremmedBog

udlånsBibliotekreturDato

Låner

navnadressepostnummerbynavntelefonnremailbrugerIdkodeOrd

Reservation

reservationsDatobeskedDatoafhentDatostatus

0..*

1

0..*

1

Genstand

titeludgivelsesÅrkunstner/forfatterforlag/selskabisbnNr/idNr

0..* 10..* 1

Eksemplar

eksemplarNrreolPlads

0..*

11

0..*Udlån

udlånsDatoafleveringsDatostatus

0..*

1

0..*

1

10..* 10..*

Hjemkaldelse

nrdato

0..*

11

Værdimængde: reserveret, hjemkommet,

afhentet, annulleret

Værdimængde:udlånt, hjemkaldt,

afleveret


Opgave 1: Arkitektur for Opgave 1: Arkitektur for ”Camplet””Camplet”Kom med forslag til en

overordnet arkitekturOvervej opdeling af manager lag

og model lag i logiske pakker Overvej interfaces og

subsystemer


Opgave 2: Opgave 2: Tilstandsdiagrammer for Tilstandsdiagrammer for Camplet”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


KvalitetssikringKvalitetssikringTestReview

Om testOm testTest 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!!


TestmodelTestmodel

En samling af◦test-cases◦test-procedurer◦eksekverbare komponenter, som

tester

Omfatter typer af test:◦ modultest eller unit-test

(klasseniveau)◦integrationstest◦systemtest


Modultest (unit-test)Modultest (unit-test)Alle en klasses metoder skal

testesBlack-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


Integrations- og Integrations- og systemtestsystemtestIntegrationstest 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


Test casesTest casesTest cases findes ud fra use case

modellenHver test case tester et

scenarium for en use caseEn test case skal specificere

input, forventet output og evt. betingelser for testen

Husk også belastningstest!!!


Test procedurer og Test procedurer og komponenterkomponenterTest 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


Nyt syn på test/XP - Nyt syn på test/XP - eXtreme eXtreme Programming (Kent Beck)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.


Documents

Lektion 8