Metode til Komponentbaseret arkitektur og design

Transkript

1 Projektrapport indleveret ved Københavns Universitet Datalogisk institut 10. april 2005 Metode til Komponentbaseret arkitektur og design Gruppe 2 Udarbejdet af: Thomas Mørup Helmudt, Jan Perticai, Lars Woetmann Pedersen og Chris Pedersen

2 Indholdsfortegnelse 1 INDLEDNING INTRODUKTION TIL PROJEKTET BAGGRUND FOR PROJEKTET LÆSEVEJLEDNING TEORI SOFTWAREARKITEKTUR DESIGNPRINCIPPER KATALYSE PROCESSEN ITERATIVT DESIGN PRE-PROCES DE ENKELTE TRIN I PROCESSEN TRIN 1 - IDENTIFIKATION AF KRAV TRIN 2 - IDENTIFICER ARKITEKTONISKE DRIVERE TRIN 3 - ARKITEKTURSTIL TRIN 4 - OPDELING AF FUNKTIONALITET TRIN 5 - FORSKELLIGE SYN PÅ MODELLEN TRIN 6 - VERIFIKATION AF MODELLEN TRIN 7 - INFRASTRUKTUR OG SERVICES TRIN 8 - GENTAG AFPRØVNING AF METODEN TRIN 1 - IDENTIFIKATION AF KRAV KVALITETSKRAV FUNKTIONELLE KRAV TRIN 2 - IDENTIFICER ARKITEKTONISKE DRIVERE TRIN 3 - ARKITEKTURSTIL TRIN 4 - OPDELING AF FUNKTIONALITET TRIN 5 - FORSKELLIGE SYN PÅ MODELLEN TRIN 6 - VERIFIKATION AF MODELLEN TRIN 7 - INFRASTRUKTUR OG SERVICES TRIN 8 GENTAG KONKLUSION PROTOTYPER PERSPEKTIVERING LITTERATURLISTE BILAG...0 B1 DEFINITIONER... 1

3 Indledning 1 Indledning 1.1 Introduktion til projektet Intentionen med dette projekt er at skabe en større forståelse for hvordan man griber komponentbaseret arkitektur og design an i et praktisk projekt hvor man ønsker at udvikle komponentbaseret software. Vi ønsker altså at sætte selve processen i fokus, og sammensætte en metode baseret på eksisterende teori indenfor området. Produktet af projektet bliver en metode, helst på punktform, som kan bruges til at tage hul på projekter hvor man ønsker at benytte sig af en komponentbaseret arkitektur. 1.2 Baggrund for projektet Baggrunden for dette projekt er et andet projekt hvor vi havde tænkt os at benytte komponentbasere arkitektur til en faktisk implementering af en given applikation. Men da vi gik i gang med at kortlægge arkitekturen, kom vores viden til kort, vi vidste simpelthen ikke hvordan vi skulle gribe opgaven an, og til vores store skuffelse kunne vi ikke finde nogen metode som kunne hjælpe os i litteraturen. Derfor besluttede vi at læse op på teorien på dette punkt, og nedfælde vores erfaringer i en metode som skulle kunne afhjælpe lignende problemer i fremtiden. 1.3 Læsevejledning Denne rapport henvender sig til et publikum der ønsker en forståelse for komponentbaseret arkitektur og design. Især hvordan man griber et reelt projekt an, og hvad en metode kan tilbyde arkitekturprocessen. Det forventes at læseren er bekendt med generelle koncepter indenfor komponentbaseret software. Desuden benytter vi dele af en metode kaldet Katalyse som læseren kan have fordel af at kende til, men det er dog ikke strengt nødvendigt. Rapporten er ud over indledning og konklusion opdelt i tre dele. Første del af rapporten indeholder en gennemgang af de teorier vi har brugt som udgangspunkt for vores proces. Baseret på disse teorier vil vi i den anden del af rapporten opstille en metode på punktform, for hvordan man kan gribe komponentbaseret arkitektur og design an. Efterfølgende vil vi i tredje del afprøve processen med et simpelt eksempel for (1) at vise hvordan vi mener de enkelte trin bør udføres, og (2) for at finde ud af om vores metode kan bidrage med noget til designprocessen. I konklusionen vil vi reflektere over metoden og dens afprøvning i del tre. Bilaget indeholder en kort liste med definitioner af begreber som vi bruger dem i denne rapport. Metode til Komponentbaseret arkitektur og design 1

4 Teori 2 Teori I vores søgen efter metoder til hvordan man kan gribe en komponentbaseret arkitektur an er vi blevet introduceret til en artikel Software Architecture Design Principles skrevet af Len Bass. Denne artikel beskriver overordnede nogle trin man bør gennemgå når man designer en komponentbasere arkitektur. Vi fandt at disse trin gav meget af det vi søgte, men artiklen indeholder forståeligt nok ikke detaljer om hvordan man udfører de enkelte trin. Disse detaljer har vi så fundet i en anden metode som hedder Katalyse beskrevet af Desmond D'Souza og Alan Will i bogen: Objects, Components and Frameworks with UML The Catalysis Approach. Katalyse metoden supplerer Bass metode godt i og med de beskriver to sider af samme sag, Bass fokuserer på kvalitetskrav mens Katalyse fokuserer på funktionelle krav, og heldigvis er begge kravtyper er en del af hele Bass proces. I denne del gennemgår vi overordnet Bass og D Souza & Wills teorier, hertil skal det dog siges at Katalyse er en meget omfattende metode og vi gennemgår den selvsagt kun overfladisk. Metode til Komponentbaseret arkitektur og design 2

5 Softwarearkitektur designprincipper 2.1 Softwarearkitektur designprincipper Dette kapitel bygger på bogen Component-Based Software Engineering, kapitel 21 pp Det er medtaget for at give et indblik i Len Bass bud på hvordan man kan komme fra kvalitets- og funktionelle krav til en softwarearkitektur. Softwarearkitektur er en specifik softwarekomponentinfrastruktur med tilknyttede designregler. Softwarearkitekturen for et program er programmets struktur. Dette omfatter softwarekomponenter, de eksternt synlige egenskaber ved komponenterne og sammenhængen imellem disse. Fremgangsmåden der beskrives, bruges primært til at finde den arkitektoniske stil man vil benytte i infrastrukturen mellem komponenterne. Denne stil er især præget af kvalitetskrav. Der opstilles otte principper for designarkitektur. De otte principper er: 1. Identificer abstrakte og konkrete funktionelle og kvalitetskrav. 2. Identificer arkitektoniske drivere. 3. Vælg en arkitekturstil, som passer bedst muligt til de arkitektoniske drivere. 4. Del funktionalitet op på en måde der understøtter kvalitetskravene. 5. Brug samtidighed(concurrency) og Idriftsættelse(deployment) syn, til at identificere funktionalitet, som ikke tidligere har været overvejet. 6. Verificer, ved brug af konkrete kvalitets- og funktionelle krav. 7. Identificer en passende komponentmodel. 8. Gentag, for at forfine designelementerne. Her følger en nærmere beskrivelse af de otte designarkitekturprincipper. Trin 1 - Identifikation af krav Der skal være både abstrakte og konkrete funktionelle og kvalitetskrav. Funktionelle krav - Abstrakte krav identificeres og kategoriseres ud fra den basale anvendelse af komponentinfrastrukturen. - Use cases konkretiserer, verificerer og afdækker yderligere krav. - Pas på at funktionelle krav ikke bliver for konkrete. Kvalitetskrav - Pas på at kvalitetskravene ikke bliver for abstrakte. Den abstrakte form af kravene bruges til at bestemme de arkitektoniske drivere og til at opdele funktionaliteten. Den konkrete form af kravene bruges til at verificere at design beslutninger ikke umuliggør kravene ved mere detaljeret design. Trin 2 - Identifikation af drivers Det er de vigtigste krav der fungerer som drivers. Ved identifikation af drivere skal man kigge på funktionelle, kvalitets- og forretningskrav med henblik på formålet med systemet og kritiske forretningsbehov. Drivers er abstrakte, det vil sige de er ikke direkte knyttet til specifik funktionalitet. Eksempel på drivers baseret på formålet med systemet: Metode til Komponentbaseret arkitektur og design 3

6 Softwarearkitektur designprincipper - Formålet med en flysimulator er at træne piloter. - Dette kræver at simulatoren kan lave realtids simulationer. Eksempel på driver baseret på kritiske forretningsbehov: - Organisationen skal udvikle en produktlinie og dette kræver hensyn til generelitet, som muligvis ikke optræder i en enkelt produktlinie. Ved eksplicit at identificere disse drivers kan man prioritere kravene. Denne identificering assisterer også arkitekten i at vælge den rigtige arkitekturstil og med at lokalisere de krav som bliver meget svære at møde eller ændre. Trin 3 - Valg af arkitekturstil/stilart Et design skal kunne tilfredsstille drivers. Eksempel: Formålet med en flysimulator er at træne piloter - Dette kræver at simulatoren kan lave realtids simulationer. Stilarter er abstrakte (beskriver ikke specifik funktionalitet) og er udgangspunkt for den konkrete opdeling af komponentinfrastrukturen. Som regel er det ikke muligt at vælge en enkelt stilart der kan tilfredsstille alle de arkitektoniske drivere. Typisk vil den valgte stilart skulle redigeres, så den kan tilfredsstille de sidste. Trin 4 - Opdeling af funktionalitet Opdeling af komponentinfrastruktur skal gøres på en måde der understøtter kvalitetskravene. Det vil sige at delmængder af funktionalitet skal opdeles i komponenter der interagerer. Valget af arkitektonisk stilart hjælper med at lave denne opdeling og det er de arkitektoniske drivers der bestemmer valget af stilart. Eksempel: Realtids simulations- / Bus stilarten. Trin 5 - Brug multiple syn Når man resonerer om softwarearkitektur skal man undersøge arkitekturen fra forskellige perspektiver. De forskellige perspektiver giver arkitekten mulighed for at resonere over forskellige egenskaber for arkitekturen. - Logisk: Dette syn beskriver systemet i termer af ansvar og interfaces. - Samtidighed (concurrency): Dette syn beskriver systemet i termer af multiple brugere, ressource contention, start-up, og andre parallelle aktiviteter. - Implementering: Dette syn beskriver systemet i termer af forandringsmuligheder (Modifiability). - Idriftsættelse(deployment): Dette syn repræsenterer den fysiske struktur af systemet, der er idriftsat og netværket der bruges til at kommunikere mellem processer. Dette syn bruges kun til systemer der eksekverer på multiple processors. Metode til Komponentbaseret arkitektur og design 4

7 Softwarearkitektur designprincipper Trin 6 - Verificer kravene De konkrete kvalitetskrav kan bruges til at verificere et design, ved at gennemgå det med hvert scenarium og afgøre hvorvidt designet tilfredsstiller kravene indehold i scenariet. Trin 7 - Identificer softwarekomponentinfrastruktur services Services der krydser mange designelementer (designelement er en del af komponentinfrastruktur eller komponent) skal overvejes at inkorporere i softwarekomponentinfrastrukturen og registreret i softwaretemplaten. Templates - Beskriver fællestræk - Beskriver interaktion mellem komponenter og infrastruktur. - Identificerer placering af ansvar. - Er typebaserede. - Forfines igennem nedarvning. Ved design af infrastruktur skal alle komponenter og deres ansvar være identificeret. Dette gøres ved en iterativ proces, hvori identificeret ansvar løbende fordeles til elementer i templaten og ved at analysere kvalitetsegenskabers krav til hele systemet. Under hvert trin af forfiningsproces skal hvert softwareelement undersøges igen. Slutresultatet er et antal softwaretemplates der beskriver de interfaces der bruges i interaktion mellem komponentinfrastruktur og komponenter. Trin 8 - Gentag og forfin Det er vigtigt at iterere for at opnå et godt design. Metode til Komponentbaseret arkitektur og design 5

8 Katalyse 2.2 Katalyse Katalyse er en metode til komponentbaseret softwareudvikling, den er opfundet af Desmond D'Souza og Alan Will; metoden er beskrevet i Objects, Components and Frameworks with UML The Catalysis Approach. Vi bruger dele af metoden og gennemgår derfor hovedpunkterne i Katalyse metoden. Katalyse arbejder især med begreberne: Actions, Objekts, pre- og postconditions, invariants samt Type modeller, de vigtigste af dem er beskrevet i Bilag 1. I vores beskrivelse af metoden har vi valgt at dele den op i følgende trin: 1. Domænemodel 1 2. Systemspecifikation 3. Arkitektur design 4. Komponent design Typen og rammerne for den software der skal udvikles, har stor indflydelse på hvilke trin der indgår i processen, og hvor stor fokus der er på de enkelte trin, vi har prøvet at beskrive et standard forløb. Trin 1 Domænemodel Det første som der bliver lagt vægt på er en god domænemodel; i Katalyse processen består den af objekts og actions. Objekterne repræsenterer de virkelige objekter i domænet, og actions bliver udstyret med pre- og postconditions samt invariants. Der bliver også lavet scenarier, samt beskrivelse af de ikke funktionelle krav. Trin 2 Systemspecifikation Efter domænemodellen som beskriver hele den verden som softwaren skal leve i bliver der zoomet ind på selve systemet med en systemspecifikation, der via en type model med actions beskriver systemets interaktion med omverdenen. Denne specifikation vil ofte ligne domænemodellen i så stor grad, at domænemodellen kan bruges som første udgave af en type model til systemet. Snapshots af systemets tilstand ved hver action hjælper med til at dokumenterer actions. Trin 3 Arkitektur design Man bruger nu system specifikationen med type modellen til lave et arkitekturelt design, komponenter bliver identificeret og inddelt i collaborations og pakker, en specifikation af connectors bliver lavet. Trin 4 Komponent design Det der herefter mangler er design af interface og klasser til hver komponent. 1 D Souza og Wills taler om domæne- og forretningsmodeller, i deres proces bruges de til det samme, hvorfor vi har valgt at bruge domænemodel som fællesudtryk for denne modeltype i resten af rapporten; man skal altså være opmærksom på at domænemodel kan skiftes ud med forretningsmodel i denne rapport. Metode til Komponentbaseret arkitektur og design 6

9 Katalyse Et gennemgående tema i Katalyse metoden er at man skal kunne zoome ind og ud, det er meget vigtigt at det er muligt at kunne kikke på en model, der kun beskriver det der er vigtigt uden samtidig at miste præcision. Refinement er derfor vigtig igennem hele processen, refinement går generelt ud på at sikre sig at et design lag overholder det mere abstrakte over design, denne proces er vigtig at huske i alle led af udviklingsprocessen. Det anbefales også i Katalyse metoden at man er meget formel i specifikationen bl.a. af invariants, pre- og postconditions, en formel beskrivelse af abstrakte krav skulle sikre at de ikke forsvinder i processen, samt at der ikke opstår tvivl om deres betydning. Der er selvfølgelig en del mere til metoden og mange underpunkter, det er i det hele taget en meget omfattende metode, som i de fleste tilfælde vil forlænge analyse og design fasen, men det skulle så gerne medføre at implementering og vedligeholdelse bliver lettere. Metode til Komponentbaseret arkitektur og design 7

10 Processen 3 Processen Len Bass beskriver i sin artikel en metode til hvordan man kan fastsætte en softwarearkitektur, bestående af komponentinfrastruktur og tilhørende designregler; Bass beskriver den overordnede infrastruktur, men beskriver ikke hvordan man på det mere detaljerede plan designer de komponentinterfaces der bruges i infrastrukturen. D Souza og Wills beskriver derimod detaljeret hvordan Katalyse metoden kan bruges til at modellere frameworks opbygget af komponenter. Det vi savner, er en overordnet proces til hvordan man designer et komponentbaseret softwaresystem; som vi mener både består af en beskrivelse af den overordnede arkitektur, og specifikationer af de enkelte dele. Vi vil i denne del af rapporten argumentere for hvordan vi ser disse to designprocesser bidrager til én samlet proces for hvordan man kan løse en opgave med komponentbaseret design; dette vil munde ud i en skridtvis guide til hvordan man kan gribe et design af et komponentbaseret softwaresystem an. 3.1 Iterativt design Bass proces er iterativ, hvilket vi er enige i er en god måde at udvikle/modne ens design på, forudsat at man ved hver iteration bygger videre på den tidligere. Denne tilgang passer også godt overens med D Souza og Wills, der er af den overbevisning at man ikke kan overskue alle detaljerne i et softwaresystem på en gang, hvorfor de har valgt at designe på flere abstraktionsniveauer, hvor man på hvert niveau arbejder med dele af det endelige produkt. D Souza og Wills mener at selv et meget abstrakt billede af produktet er et korrekt billede; da det at man ikke ser alle detaljer ikke betyder at de ikke eksisterer, og ikke har mulighed for at få dem afbilledet hver for sig hvis man zoomer ind på de enkelte dele af designet. Den første iteration skal efter vores overbevisning give et overordnet abstrakt billede af det endelige produkt, men dog stadig et korrekt billede. Ved senere iterationer forfines modellen, flere detaljer bliver tilføjet og der bliver udluset eventuelle fejl undervejs; alt i alt giver disse iterationer en mere korrekt model. D Souza og Wills foreslår at man starter på et højt abstraktionsniveau og så bevæger sig nedefter i detaljeringsgrad. Dette passer fint ind i en iterations tankegang hvor hver iteration dækker over et nyt abstraktionsniveau. Bass beskriver at man kan iterere over dele af processen, dvs. springe et til flere punkter tilbage, for at gentage disse. Hvis dette skal passe sammen med D Souza og Wills kræver det at man holder sig indenfor det samme abstraktionsniveau som en given iteration beskæftiger sig med, da man eller vil miste de resterende punkter i processen på de andre abstraktionsniveauer som man bevæger sig ind på. 3.2 Pre-Proces Før processen starter antager vi at man har en idé om hvad det er man ønsker at modellere; om det så er meget abstrakt, har man dog en idé. Ud fra denne ide dannes Metode til Komponentbaseret arkitektur og design 8

11 Processen det første udkast til de krav produktet skal opfylde, og det er disse krav der bruges i det første skridt i første iteration af processen. 3.3 De enkelte trin i processen Vi har valgt som udgangspunkt at bruge trinene fra Bass metode, og så tilføje enkelte metoder fra Katalyse hvor de passer ind. Dette valg er som udgangspunkt truffet fordi Bass opstiller en let overskuelig sekvens af trin, hvorimod D Souza og Wills ikke lægger sig op ad en fast rækkefølge, som de mener, kan variere alt efter det enkelte projekt, og derudover lægger op til en meget mere kompleks proces, som udgangspunkt ikke understøtter vores projektets mål Trin 1 - Identifikation af krav Krav bliver enten indsamlet fra organisationen eller opstår som en del af processen under tidligere iterationer. De fundne funktions- og kvalitetskrav kan variere meget i hvor abstrakte eller konkrete de er, for at det passer ind i det abstraktionsniveau man er på i den pågældende del af processen, tilpasses kravenes niveau tilsvarende. Bass beskriver at man i denne del af processen skal dokumentere både kvalitetskrav og funktionelle krav, men ikke hvordan; her har D Souza og Wills en klar holdning til at man bruger UML og OCL til specificeringen af krav. Den meget formelle syntaks i UML og OCL kan dog ikke i alle tilfælde bruges til kvalitetskrav, som af natur er mere upræcise end funktionelle krav. Vi vælger derfor at dokumentere funktionelle krav efter D Souza og Wills metode; og kvalitetskrav dokumenteres i prosa. Det skal hertil siges at Bass i sin proces hovedsageligt fokuserer på kvalitetskrav, hvorimod D Souza og Wills fokuserer på funktionelle krav; en god pointe her er, at når man mikser de to modeller bliver der taget hensyn til begge former for krav. Vi mener at kvalitetskrav ved senere iterationer kan blive omskrevet til en eller flere reelle funktionelle krav; denne omskrivning baseres på den aktuelle arkitektur man arbejder hen imod, og en voksende detaljegrad af designet. Man skal dog være bevidst om at dette ikke er tilfældet for alle kvalitetskrav; ikke alt kan omskrives, f.eks. et krav som at systemet skal svare indenfor 1 sekund. Alle krav bør blive konkretiseret, da Bass bruger de konkrete kvalitetskrav til at verificere modellen i punkt 6; og D Souza og Wills bruger de konkrete funktionskrav som katalysator til et mere detaljeret design. D Souza og Wills specificere i denne del af processen den aktuelle domænemodel; modellen er ofte forskellig fra selve implementeringen, og kan som regel bruges over flere projekter. Modellen beskriver nu-og-her og/eller fremtidige domæne modeller. På basis af domæne modellen dannes en typemodel, som i de fleste tilfælde minder meget om domænemodellen. Sammen med den meget formelle typemodel, foreslår D Souza og Wills at man skriver en ordbog, der beskriver de enkelte typer i prosa; dette gøres for at kunne forstå modellen lettere og for at fjerne eventuelle tvetydigheder. Metode til Komponentbaseret arkitektur og design 9

12 Processen Trin 2 - Identificer arkitektoniske drivere D Souza og Wills mener at det ofte kan være en god idé at analysere nu-og-her domænemodellen, og ud fra essentielle krav danne den forestillede fremtidige domænemodel. D Souza og Wills skriver dog ikke hvordan de udvælger disse essentielle krav, hvorimod Bass har et punkt i sin metode der aktivt identificerer de arkitektoniske drivere. De arkitektoniske drivere bruges til at prioritere de krav der er blevet opstillet i trin 1, derefter bruges den prioriterede liste af krav til at vælge passende arkitekturstile. Identifikation af de arkitektoniske drivere er forankret dybt i projektets interessegrupper; heriblandt findes internt i organisationen: projekt ejer, ledelse, drift, brugere osv.; eksternt kunne man forestille sig samarbejdspartnere, lovgivning og des lige. Disse interessegrupper vil påvirke det specifikke projekt forskelligt alt efter projektets type og omfang; og man kunne forestille sig at de kunne prioriteres efter deres indflydelse på det enkelte projekt. Eksempelvis kunne man forestille sig at ledelsen har stor betydning, hvis deres budgettering ikke rækker til investering i en ny komponentmodel, da organisationen allerede har implementeret en J2EE server i et tidligere projekt. Ved identifikation af drivere, har man som udgangspunkt kravene fra trin 1, som er dannet i samarbejde med organisationen (projekt ejeren), derved fokuseres på selve systemet der skal implementeres. Organisationens overordnede behov og mål danner så grundlaget for de første drivere, der fastlægger de grænser organisationen opstiller. Dernæst skal interessegrupper i og udenfor organisationen høres, så yderligere drivere kan dannes ud fra deres ønsker, behov og evt. begrænsninger. Man har nu en liste af drivere der kan bruges i det videre forløb. Vi mener dog at Bass undlader at tale om en ikke uvæsentlig optimering, nemlig at prioritere driverne efter vigtighed for projektet. Vi mener at man burde iterere en enkelt gang over driverne, for at finde de vigtigste og måske fjerne de drivere med lavest prioritet, hvis de får ringe eller ingen indflydelse på den overordnede arkitektur. Man kunne godt forestille sig at visse drivere ikke kan prioriteres præcist før man har gennemgået senere trin, og at gennemgangen af de efterfølgende punkter vil komme med input til prioriteringen. Derfor kan dette trin tilpasses ved senere iterationer. Man skal dog være opmærksom på de konsekvenser eventuelle ændringer vil have på resten af arkitekturen, som godt kan være ret betydelige. Et sidste men bestemt ikke uvæsentligt input til ændring af drivere, og i det hele taget applikationen, kan være manglende ekspertise inden for en del af løsningsmodellen. En sådan usikkerhed kan vise sig at være ikke implementerbar, og må derfor udelades i en senere iteration. En løsning kunne være at lade disse usikkerheder være højt prioriterede drivere, derved bliver de adresseret før de når at blive et stort problem Trin 3 - Arkitekturstil I denne del skal der vælges en arkitekturstil, som passer bedst muligt til de arkitektoniske drivere. D Souza og Wills vil, som Bass, tidligt i processen (dvs. i de Metode til Komponentbaseret arkitektur og design 10

13 Processen første iterationer) prøve at identificere overordnede arkitektonisk stilarter som skal bruges i arkitekturmodellen, der beskriver infrastrukturen (trin 7). Man skal dog være bevidst om at disse stile kan ændre sig ved senere iterationer, alt efter hvordan arkitekturmodellen udvikler sig. D Souza og Wills differentierer mellem arkitektonisk model og applikationsarkitektur, som også har en påvirkning. Applikationsarkitektur beskriver den enkelte applikation, som en mængde samarbejdende komponenter; dette samarbejde er selvfølgelig påvirket af den arkitektoniske model, og kan derved også påvirke valget af arkitekturmodel, som igen påvirker de brugte arkitektoniske stile. Processen at vælge en arkitekturstil, minder meget om det at vælge et mønster (eng. pattern) i OOD (objekt orienteret design); da arkitekturstil er for CBD (komponentbaseret design) hvad mønstre er for OOD, ifølge Bass. Man ser altså på allerede kendte arkitekturstile, og vurderer om de kan bruges i den aktuelle situation, alt efter hvor godt den enkelte stil understøtter de arkitektoniske drivere. I den situation hvor der ikke er nogen kendte arkitekturstile der passer optimalt bliver man selvsagt nødt til selv at udvikle en. Problemet med valget af arkitekturstil er, at valget af den rigtige arkitekturstil, baserer sig på den enkelte arkitekts erfaring. Man kan sige at den uerfarne arkitekt kan se på hvordan man tidligere har løst problemer, og derved få et vist erfaringsgrundlag; men det vil nok aldrig blive helt det samme alligevel. Spørgsmålet er så om man kan sige at den erfarne arkitekt altid vælger rigtigt; og svaret må selvfølgelig være nej, ikke mindst fordi erfaring er skalerbart, men i høj grad også fordi man ikke kan være sikker på at man til dato har fundet den optimale løsning på et givent problem. Så konklusionen må være at enhver arkitekt kommer med en tilnærmet bedste løsning, baseret på sin nuværende erfaring Trin 4 - Opdeling af funktionalitet I dette trin skal funktionaliteten opdeles, og tildeles komponenttyper (dvs. interfaces) som understøtter den i trin 3 valgte arkitekturstilart. Bass pointerer at der kan være mange interne iterationer mellem funktionsopdeling, valg af arkitekturstil og inddeling i komponenttyper før man har en tilfredsstillende løsning. Opdelingen af funktionaliteten i dette trin kan ske på mange måder; Bass har ikke nogen formalisere proces for denne opdeling men foreslår at man tager udgangspunkt i kvalitetskravene. D Souza og Wills derimod har en punktvis guide til denne proces, hvor man tager udgangspunkt i de Use Cases man har identificeret i domæne modelleringen, samt type modellen, og derudfra opstiller nogle konkrete eksempler for hvordan man kunne forestille sig data vil se ud i modellen. Denne konkrete datarepræsentation bruges som katalysator til at identificere de enkelte sammenhænge, og derudfra opdele funktionalitet så man tager hensyn til disse. Resultatet af dette trin er en systemspecifikation som følge af en opdeling af funktionalitet og identifikation af komponenttyper/interfaces; denne overordnede systemspecifikation kræves for at kunne fortsætte med trin 5 hvor vi skal belyse den overordnede model fra forskellige vinkler. Metode til Komponentbaseret arkitektur og design 11

14 Processen Trin 5 - Forskellige syn på modellen Bass vil gerne betragte modellen med forskellige syn, for at identificere funktionalitet som ikke tidligere har været overvejet. Vi mener dette er yderst relevant, da man ellers kan komme til at undlade gængse design beslutninger, som er relevante for flertallet af applikationer der bliver udviklet. Vi mener dog at disse syn man skal betragte modellen med, afhænger meget af hvordan man udvikler applikationer i fremtiden; som igen afhænger af teknologisk modenhed. Som eksempel har Internettets udbredelse øget mulighederne for distribuerede applikationer, hvilket gør det mere attraktivt at implementere distribuerede løsninger nu end for ti år siden. Vi mener altså at den teknologiske udvikling vil ændre på hvilke syn man skal betragte sin model med; man skal dog være opmærksom på at denne udvikling er langsom, og derfor nok ikke ændrer sig mellem projekter (der ikke varer flere år). Når man antager et bestemt perspektiv fokuserer man på bestemte aspekter af modellen, og udelukker andre detaljer; hvilket passer godt overens med Katalyse metoden, hvor D Souza og Wills kalder dette forskellige arkitektoniske perspektiver. En model kan indeholde en til flere forskellige perspektiver; men som alt andet i Katalyse metoden skal det hele passe sammen, dvs. at forskellige perspektiver ikke må indeholde modstridende specifikationer. Det er altså ikke nok at se på modellen med forskellige syn, man skal også være bevidst om hvordan de forskellige perspektiver hænger sammen, dette er der ikke taget hensyn til i Bass model, men i Katalyse skal man altid holde den enkelte specifikation op mod dens mere abstrakte forælder; hvorved man automatisk sørger for at de forskellige perspektiver ikke er modstridende Trin 6 - Verifikation af modellen På dette stadie i processen skal modellen verificeres; Bass gør dette ved at bruge konkretiseringer af kvalitetskrav som test cases, dvs. han tester hele modellen som en blackbox ud fra konkretiserede kvalitetskrav. De scenarier der bliver defineret i trin 1 som konkretiserede kvalitetskrav, bruges til at verificere modellen ved at teste de enkelte scenarier op mod modellen. Herved finder man ud af om det aktuelle design opfylder de kvalitetskrav der er realiseret i det enkelte scenario. 3-1: Verifikation af modellen D Souza og Wills derimod vil gerne være fuldstendigt sikre på at de forskellige abstraktionsniveauer taler sandt, derfor holder de underliggende kravspecifikationer op mod mere abstrakte kravspecifikationer, og hvis begge specifikationer siger det samme er testen bestået (også selv om mere detaljerede specifikationer har mere at sige ). Med denne sammenligning tester man abstrakte funktionskrav op mod mere konkrete/detaljerede. Metode til Komponentbaseret arkitektur og design 12

15 Processen D Souza og Wills sammenligninger skal dog ikke udføres på et sted i modellen, men hver gang man afslutter en ny specifikation, hvilket sker flere steder i processen. Derfor er det reelt kun Bass s overordnede tests der skal udføres i dette trin Trin 7 - Infrastruktur og services Indtil videre har vi kun defineret de enkelte komponenter men ikke hvordan overordnede funktioner der spænder over flere komponenter bliver udført. Bass test i Trin 6 skulle gerne kaste lys over disse funktioner, og giver altså det input til dette trin, at vi nu ved hvilke overordnede funktioner der mangler og også hvilke komponenter de berører. I trin 7 dannes den overordnede infrastruktur, og man har en fuldendt arkitektur på et givent abstraktionsniveau. Bass kortlægger i dette trin den aktuelle infrastruktur, som bestemmer hvordan komponenterne interagerer; med de, i trin 3, definerede arkitekturstile in mente. Hvis der mangler nogle services for at kunne udføre en funktion vil de blive tilføjet her; det kan gøres i form af nye komponenter, eller som krav til en eventuel komponentmodel, der altså skal kunne tilbyde disse services. D Souza og Wills mener også at det er på dette tidspunkt i processen at man skal fastlægge infrastrukturen. Det realiseres via det de kalder delte handlinger (eng: Joint Actions), som de sidestiller med UML specifikationens Use Cases. En delt handling, er en handling der har specificeret en der starter den og evt. modtager resultatet; under handlingen vil to eller flere komponenter bliver berørt. Modstykket til en delt handling er en lokal handling; en delt handling kan omformes til en lokal handling ved at specificere hvem der starter handlingen og hvem der evt. modtager resultatet. Vi mener at identifikation af connectors falder godt ind i processen i dette trin; netop fordi man kortlægger infrastrukturen, er det et godt tidspunkt at se på hvordan komponenterne skal kommunikere. Connectors kan variere meget i kompleksitet, lige fra asynkrone beskeder til køer; D Souza og Wills beskriver i deres metode hvordan en connector type kan specificeres, og siden hen genbruges mellem alle komponenter der benytter sig af denne connector. En avanceret connector svarer til en af Bass delte services, og kan implementeres som en komponent hvis den ikke bliver stillet til rådighed af komponentmodellen Trin 8 - Gentag Der kan være flere årsager til at gentage processen, men man bør dog iterere en gang til hvis der i de foregående trin er fundet, ændret eller tilføjet krav, som følge af bedre indsigt i modellen. En anden grund kan være hvis man har en meget grovkornet model, hvorved en ekstra iteration vil forfine modellen yderligere. D Souza og Wills sætter processen ind i et større hele som vi ikke har taget hensyn til her, hvor de bl.a. også tager hensyn til implementering og planlægning. Når man ser på hele udviklingsprocessen kører mange af disse aktiviteter sideløbende og giver yderligere input til hinanden undervejs. De er dog rørende enige med Bass i, at en god arkitekturfase giver et bedre produkt i sidste ende. I næste kapitel vil vi med et simpelt eksempel vise hvordan arkitekturprocessen kan bruges i praksis. Metode til Komponentbaseret arkitektur og design 13

16 Afprøvning af metoden 4 Afprøvning af metoden I dette kapitel er der en skridtvis gennemgang af, hvordan vores metode, beskrevet i foregående kapitel, anvendes. Der vil for hvert trin være en beskrivelse af det resultat vi har fået ud af modelleringen samt en kort opsummering af, hvad udførelsen af dette trin forventes at give. Kapitlet er medtaget for at afprøve, hvordan vores model virker i praksis samt for at give læseren en bedre forståelse for hvorledes den skal anvendes. Det er ikke intension at lægge hovedvægten på det praktiske men mere på selve processen. Til at afprøve vores metode har vi valgt at modellere et kalenderframework. Vi har valgt et simpelt kalenderframework med følgende pre-proces kvalitets- og funktionelle krav: Kvalitetskrav - Applikationen skal: - Kunne bruges af flere brugere. - Være sikker og beskytte brugerne mod misbrug. - Kommunikere i realtid. Funktionelle krav - det skal være muligt at - Oprette, redigere og slette begivenheder. - Blive alarmeret inden en begivenhed indtræffer. - Udveksle begivenheder med andre bruger. - Få vist forskellige udsnit af kalenderen (år, måned, dag etc.) 4.1 Trin 1 - Identifikation af krav Kvalitetskrav Systemet skal kunne udvides til at bruge forskellige brugerhåndteringssystemer. Mia s barn er sygt og hun tænker på at tage en arbejde hjemmefra. For at se om hun går glip af nogle vigtige møder, starter hun sin kalender på PC en og skriver sit brugernavn og kodeord. Kodeord og password bliver verificeret mod firmaets Linux server, samtidig registrer kalenderserveren at Mia er logget på og kontrollere om der ligger nogle mødeindkaldelser til hende som hun endnu ikke har modtager. I en anden virksomhed er Klaus lige mødt på arbejde, og ved at starte sin kalender op, Klaus s virksomhed bruger det samme kalender system som Mia s virksomhed, her benytter de sig dog af Windows2003 server med ActiveDirectory, til bruger registrering. Applikationen skal håndtere events. Dvs. at kalenderen skal kunne oprette og tilmeldes nogle events samt modtage events. Hos Mia springer 2 dialog bokse frem, den ene er en indkaldelse til et møde om 2 uger, og den anden er en alarm som gør hende opmærksom på at hun skal samle nogle papirer til et status møde hun har med produktionschefen, Thomas, kl. 14 i dag. Mia klikker ok til mødet om 2 uger, og klikker alarmen væk. Applikationen skal være sikker og beskytte brugerne mod misbrug. Dvs. at hver bruger skal have sin egen kalender og skal være sikker på at andre ikke kan se eller redigere i den. Mia undersøger om hun kan flytte dagens aftale til en anden dag, men opdager så at hun ikke har adgang til Thomas kalender. Hun opretter derfor et nyt møde, 2 dage senere, og sender en indkaldelse til Thomas, kl. er nu 9:00 Metode til Komponentbaseret arkitektur og design 14

17 Afprøvning af metoden Applikationen skal kommunikere i realtid. Dvs. at aftaler skal være synlige med det samme de er oprettet. Thomas er mødt tidligt den morgen da der har været nogle problemer med nogle af produktions maskinerne, det tegner til at blive en hektisk dag. Han er lige kommet tilbage til sit kontor for at få en kop kaffe da Mia mødeindkaldelse popper op på hans skærm. Thomas checker sin kalender og se ganske rigtig at han har et møde med Mia i dag, han checker sit ur, kl. er 9:01, problemerne med produktionsmaskinerne kommer nemt til at tage det meste af dagen, så han aflyser dagens møde, og acceptere Mia nye forslag. Hjemme hos Mia kommer der en besked om at dagens møde er blevet aflyst, og kort efter en besked om at det nye møde er accepteret. Figur 4-1: Kvalitetskrav med tilhørende konkretiseringer Funktionelle krav De actions som vi har i vores domænemodel er dem som vi har fundet at det er relevant vores framework understøtter, vi har jo ikke kunnet gå ud og se på et eksisterende forretnings domæne for at finde actions. Af de 6 actions vi har, er de 5 nogle som bliver igangsat af en ekstern bruger, den sidste er en action som bliver sat i gang på et bestemt tidspunkt, denne action vil sandsynligvis ende ud med at være en intern action hæftet til Alarm. Figur 4-2: Domænemodel og Typespecifikation Metode til Komponentbaseret arkitektur og design 15

18 Afprøvning af metoden -- sluttid for begivenhed skal altid være senere end starttid inv Event.Date:: starttime <= stoptime -- en bruger er fri på en bestemt date hvis der ingen begivenheder som overlapper den date inv User:: free(d: Date) = self.events.overlaps(d) ->isempty -- en date overlapper hvis den er blokkende og har starttid før og stoptid efter d inv Event:: overlaps(d: Date) = if blocking then ( self.date.starttime <= d & self.date.stoptime >= d ) else null endif Figur 4-3: Invariants -- sletter begivenheden e fra kalender action Calendar::sletBegivenhed(e: Event) pre: -- forudsætter at begivenheden er i brugerens kalender e.user.events.includes(e) post: -- begivenheden er ikke længere i brugerens kalender not e.user.events.includes(e) -- opretter en begivenhed i kalender action Calendar::opretBegivenhed(u: User, d1: Date, d2: Date, title: string, notes: string, location: string, recurrance: time, blocking: bool) pre: -- dates skal være ordnet og hvis blokkende skal bruger være fri for andre blokkende events i tidsrummet d1 til d2 d1 < d2 & if blocking then {d1..d2}->forall( u.free( d ) ) else true endif post: -- resulterer i at der bliver oprettet en ny begivenhed result: Event.new[u, d1, d2, title, notes, location, recurrance, blocking] action Calendar::redigerBegivenhed(e: Event) pre: -- forudsætter at begivenheden er i brugerens kalender e.user.events.includes(e) post: -- dates skal være ordnet og hvis blokkende skal bruger være fri for andre blokkende events i tidsrummet e.d1 til e.d2 e.d1 < e.d2 & if blocking then {e.d1..e.d2}->forall( e.u.free( d ) ) else true endif action Calendar::udveksleBegivenheder( Set(e: Events), u2: User) pre: -- forudsætter at begivenhederne er i brugerens kalender e.user.events.includes(set(e)) post: -- resulterer i at begivenhederne også er i den anden brugers kalender u2.events.includes(set(e)) action Calendar::sendAlarm(e: Event) pre: -- eventet findes og alarmen er sat til og tidspunktet er rigtigt e.user.events.includes(e) & e.alarm!= null & now == e.date.starttime - e.alarm.timebefore post: --alarmen er fjernet e.alarm == null action Calendar::visUdsnit(d1: Date, d2: Date, u: User) pre: -- datoerne skal være ordnet d1 < d2 Figur 4-4: Actions Metode til Komponentbaseret arkitektur og design 16

19 Afprøvning af metoden 4.2 Trin 2 - Identificer arkitektoniske drivere Det vi gør i dette trin er at kigge på alle kravene, der er identificeret i trin 1 og ud fra disse finde driverne for kalendersystemet. Vi har identificeret følgende drivere for vores kalendersystem. Applikationen skal kunne bruges af flere bruger. Dvs. at kalenderen skal være distribueret. Applikationen skal kommunikere i realtid. Dvs. at aftaler skal være synlige med det samme de er oprettet. Applikationen skal håndtere events. Dvs. at kalenderen skal kunne oprette og tilmeldes nogle events samt modtage events. Applikationen skal være sikker og beskytte brugerne mod misbrug. Dvs. at hver bruger skal have sin egen kalender og skal være sikker på at andre ikke kan se eller redigere i den. Systemet skal kunne bruge forskellige brugerhåndteringssystemer. Dvs. at det skal være muligt at udskifte brugerhåndteringssystemet. Det at finde drivere for et/en system/applikation er meget væsentlig, da det kan have stor indflydelse på arkitekturstilen og designet. De fleste drivere er ofte forholdsvis nemme at identificere, men det er vigtigt at gennemgå alle kravene grundigt så alle driverne bliver identificeret. Man skal dog være opmærksom på at det videre forløb vil kunne bidrage til identificering af nye drivere, bl.a. derfor er det vigtigt at iterere så sådanne kan komme med i en ny iteration. 4.3 Trin 3 - Arkitekturstil Udgangspunktet til valg af arkitekturstil er de fire identificerede drivere. Driverne viser tydelig at der er brug for en kommunikationsarkitektur og hvor vigtigt det er at vælge den rette. De tre basale kommunikationsarkitekturer, at vælge mellem, er: punkt-til-punkt, klient-server og publish-subscribe. Punkt-til-punkt kommunikation er den simpleste form for kommunikation. Den giver mulighed for at der kan oprettes en kommunikationskanal mellem to enheder, hvor de to enheder kan have en tovejs kommunikationsdialog. Punkt-til-punkt er dog ikke særlig velegnet der skal kommunikeres med flere på en gang. Klient-server arkitekturer har en speciel servernode der samtidig kan forbinde til mange klientnoder. Dvs. klient-server arkitekturen er en mange til mange arkitektur. Klient-server arkitekturen er god når noder skal tilgå centraliseret information. Hvorimod hvis informationen bliver genereret af mange noder kræver det at al informationen bliver sendt til serveren før den bliver tilgængelig for klienten. Det er ineffektiv og giver også en ukendt forsinkelse til systemet. Publish-subscribe arkitekturer er velegnet til distribueret realtidskommunikation. Det bl.a. fordi der ikke er brug for at forespørge på data og fordi dataoverførsel er mellem publisher og subscriber. Det at data kan sendes fra publisher til subscriber, med det samme data bliver tilgængelig, gør at publishsubscribe arkitekturen har lav latenstid. Yderlig giver publish-subscribe arkitekturen Metode til Komponentbaseret arkitektur og design 17

20 Afprøvning af metoden god mulighed for at udnytte multicast mulighederne i kommunikationsnetværk. Faktisk kan publish-subscribe arkitekturen supportere alle dataoverførselskravene til et distribueret realtidssystem inklusiv gruppekommunikation ved tilstandsændring og pålidelige status opdateringer. En publish-subscribe arkitektur bruger netværksressourcerne meget bedre end klient-server arkitektur. Ud fra ovenstående kan vi se at publish-subscribe arkitekturen understøtter de tre første drivere: kalenderen skal være distribueret, den skal kommunikere i realtid og den skal håndtere events. Den fjerde driver der omhandler sikkerhed i form af at brugerne kan være sikre på at andre ikke kan se eller redigere i deres kalender kræver at arkitekturen giver mulighed for at anvende en brugerdatabase, så hver enkelt bruger kan identificeres entydigt. Den sidste driver angående muligheden for udskiftning af brugerhåndteringssystemer kræver at systemet bliver opbygget med meget klart definerede interfaces og denne funktionalitet bliver delt op i en selvstændig komponent. Det er ikke noget selve arkitekturen skal tage højde for, men det vil have indflydelse på det næste trin. Processen med at gennemgå sine drivere og basere sin arkitektur ud fra disse giver en god indsigt i hvordan systemet skal opbygges og giver derfor også et godt grundlag for at opdelefunktionaliteten. 4.4 Trin 4 - Opdeling af funktionalitet Med udgangspunkt i de fundne Driver og arkitekturstile vil vi i dette afsnit opdele den ønskede funktionalitet i nogle passende klumper som skal være vores frameworkes komponenter. Hver komponent vil blive beskrevet med et interface og handlinger. Handlinger som spænder over flere komponenter vil blive beskrevet vha. joint actions i OCL. Vores kalender framework fremstår som en komponent, men bag facaden har vi valgt at dele den ind i tre komponenter: 1. Events 2. Alarms 3. Users Ud fra typemodellen får vi begreberne Event, Alarm, Date og User, disse vil oplagt blive implementeret som selvstændige objekter I systemet. For at lette håndteringen af disse objekter vil frameworket stille en række komponenter til rådighed. Metode til Komponentbaseret arkitektur og design 18

21 Afprøvning af metoden Figur 4-5: Systemspecifikation -- retunerer alle events inden for et bestemt tidsrum action Events::getEvents(d1: Date, d2: Date) pre: -- datoerne skal være ordnet d1 < d2 -- retunerer alle brugere i systemet action Users::getUsers() -- opretter en alarm ud fra det givne event action Alarms::addAlarm(e: Event) post: -- resulterer i at der bliver oprettet en ny alarm result: Alarm.new[e] -- fjerner en alarm fra et event action Alarms::removeAlarm(e: Event) pre: -- der er en alarm på eventet e.alarm!= null post: --alarmen er fjernet e.alarm == null -- opretter en bruger i systemet action Users::addUser(name: string, string) post: -- resulterer i at der bliver oprettet en ny bruger result: User.new[name, ] -- fjerner en bruger fra systemet action Users::removeUser(u: User) post: --brugeren er fjernet u == null Figur 4-6: Joint Actions (Use Cases) Metode til Komponentbaseret arkitektur og design 19

22 Afprøvning af metoden Mange handlinger I et kalenderframework vil opererer på en eller flere events objekter, f.eks. vil en typisk forespørgsel gå på hvilke event der ligger I et givent tidsinterval, eller om et givent event overlapper et andet event. For at undgå at applikationsprogrammørerne selv skal holde styr på alle de selvstændige event objekter, kobles denne funktionalitet ind i et Events komponent. De handlinger der bliver udført på alarmer er i høj grad identiske med dem der bliver udført på events, f.eks. hvilke alarmer der findes i et givent interval, hvornår er den næste alarm osv. Desuden skal der være et system på plads der holde øje med tiden for den næste alarm og sammenligner dette med den faktiske tid. Denne logik samt logik til at annoncere til evt. andre enheder samles i et Alarms komponent. Som nævnt tidligere optræder date mange gange i typemodellen, men vi har ikke fundet at det berettiger til en selvstændig komponent, da der mere er tale om en type betegnelse og de operationer der typisk opererer på dates allerede er implementeret i de fleste programmeringssprog/miljøer. Derfor ser vi ingen grund til at frameworket skal håndtere dates som et komponent, det kan dog give mening at lave en wrapper class om dates således at de har et konsistensinterface uafhængig af implementerings miljø. En af systemets drivere er at frameworket skal kunne kommunikere med flere forskellige brugersystemer, for at gøre det nemt for applikationsprogrammørerne at håndtere disse forskellige systemer og deres forskellige tilgange til bruger udstiller systemet et Users komponent, som en grænseflade for andre systemer, Users systemet kan evt. også implementere alt brugerlogikken selv, så der ikke er behov for andre services. Kigger vi på kvalitetskravene bliver det klart at vores framework skal gøre det muligt at udveksle events mellem forskellige bruger på forskellige maskiner, derfor indføre vi en Publish/subsribe kordinater som tager sig af at distribuere events fra en bruger til andre bruger som abonnomere på dem. 4.5 Trin 5 - Forskellige syn på modellen Vi har her prøvet at kigge på modellen med de fire syn der er nævn i afsnit 2.1 punkt 5. Det logiske syn. For at undgå at alle de forskellige komponenter implementere hver deres persistensmetode vil det være smat at al logik omkring fast lagring bliver lagt i et persistenskomponent. Komponentens primære opgave vil være at gemme objekter til et fastmedie samt evt. geninstansiere igen. Udover ovenstående har ikke været muligt at finde evt. fejl eller mangler i ansvarsfordelingen, eller interfaces. Metode til Komponentbaseret arkitektur og design 20

23 Afprøvning af metoden Samtidighedssynet. Vores specifikationer indtil nu beskriver ikke hvordan systemet skal forholde sig til situationer hvor to brugere deler aftaler, og den ene ændre dem mens den anden er offline. Følgende scenario beskriver denne situation og skal med i vores scenario test pulje, beskrevet i afsnit Mia har taget sin bærbare med på en forlænget weekend fordi hun havde nogle småting hun ikke var nået at blive færdig med på kontoret. Efter nærmere gennemgang af et af de projekter hun har taget med, kan hun se at det bliver nødvendig at holde et møde med de andre projektdeltager i næste uge. Mia åbner sin kalender og booker et møde torsdag eftermiddag, da hun ikke er online har hun ikke mulighed for at se om de andre har tid på det tidspunkt. Da Mia møder på kontoret mandag morgen og slutter sin computer til netværket, begynder den automatisk at synkronisere med de andres kalendere. Der kommer en dialogboks op der fortæller at mødet torsdag kollidere med et andet møde som hendes chef har indkaldt. Mia læser hurtigt mødebeskrivelsen og ser at det nye møde har samme agenda som det hun selv ville havde indkaldt til. Mia sletter derfor det møde hun havde oprette. Implementeringssynet Systemet er designet rundt om komponenter og det skulle derfor være nemt at modificere i senere. Da der ikke er foretaget nogle implementeringer på nuværende tidspunkt er der heller ikke blevet lavet noget valg med hensyn til kode stil og dokumentation, som også kan havde indflydelse på hvor nemt koden er at vedligeholde senere. Idriftsættelse synet Frameworker gør brug af en Publish/subsribe server, denne skal installeres før end det programmel der benytter sig af den. Der er dog ikke nogle krav om at serveren skal ligge på en selvstændig maskine, hvorfor hele frameworket vil kunne fungere ligeså godt på en enkeltstående maskine uden netværksforbindelse, som i et netværks miljø med deddikeret Publish/subsribe server. Ofte har man under hele processen forskellige briller på, så man har prøvet at se systemet fra forskellige perspektiver. Dette trin er med til, at sikre, at man får kigget på systemet med alle de relevante syn og får udtrykt det eksplicit. Dermed er dette trin med til at sikre at relevante informationer ikke går tabt. Vi har som nævnt kun valgt at tage de fire syn som Len Bass næver som de væsentligste, man skal altid huske at se om der andre syn man bør kigge på systemet med. I vores lille kalenderframework eksempel er der kommet en enkelt væsentlig information til ved dette trin. Igen kan vi om dette trin sige at det er meget væsentlig, så man ikke over ser nogle vigtige aspekter. Metode til Komponentbaseret arkitektur og design 21