ATiSA H3: Beer Web Store Gruppe: Hotel Christer Vindberg, Anders Kabell Kristensen, Bo Sunesen og Anders Viskum 20011271, 20041248, 20041083 og 20043103 {chrisv10, dalko, sunesen, anden} @ cs.au.dk december 2008
Indholdsfortegnelse 1 Software Architecture Beer Web Store...3 2 Architectural Description - Beer Web Store...6 3 Quality Attributes Beer Web Store...8 4 Architectural Design Beer Web Store...11 Performance tactics...11 Availability tactics...11 Layered architectural style...12 Major elements in component and connector structure...12 Connector types...14 5 Architectural Prototyping Beer Web Store...15 Types of architectural prototyping...15 Choosing programming language/framework...15 Architectural prototype for testability...15 Benefits and liabilities of using ArchJava...16 Service-Oriented Architecture...17 6 Architectural Evaluation Beer Web Store...18 Beskrivelse af ATAM-processen...18 Identificering af sensitivity points, tradeoff points og risks...20 Fordele og svagheder ved ATAM i forbindelse med Beer Web Store...20 At bruge DiscoTect til evaluering af Beer Web Store...20 Sammenligning af ATAM og architectural prototyping...21
1 Software Architecture Beer Web Store Outline how you would approach the tasks of creating the architecture for the BeerWeb Store. Consider, e.g., which steps would you takes and in which order? I den meget simplificerede udviklingsproces som er vist på nedenstående figur undersøges de ønsket krav til systemet. Udviklingsprocessen undersøger både kvalitet og funktionelle krav. Ud fra disse opbygger man så systemets arkitektur krav, som så ledere os til software arkitektur kravene. Hvor ud fra vi kan gå i gang med at implementere et system. Figur 1 : The (Very) Simplified Development Process For at designe vores arkitektur har vi valgt at gøre brug af følgende punkter: Quality attributes: Her vil vi definere både kvalitets og funktionelle krav, og vi vil finde frem til de attributter der er vigtig for vores system, avalibility, security, usability er f. eks nok nogen vi vil fokusere meget på i vores Beer Web Store (BWS), men andre attributter som performance og modifiability vil nok også spille væsentlig rolle. Architectural Description: I dette punkt vil vi beskrive systemets arkitektur, vi vil også definere nogle viewpoints og forkellige views for dem. Efter som systemet kan være kompleks kan det være nødvendigt at have flere forskellige views. Vi vil nok også lave nogle tegninger over de forskellige views for at øge forståelsen. Architectural Design: Her vil vi designe de forskellige elementer og relationerne mellem disse, dette design skal opfylde de fundne kvalitets attributter. Vi kan her evt. også ligge os fast på et eller flere patterns som vi ønsker at gøre brug af. Architectural Evaluation: Her vil vi evaluere den fundne software arkitektur. Vi kunne f. eks vælge at strukturere vores evaluering som en Quality Assurance Workshop (QAW) som beskrevet i [Bass et. al. 2003] eller bruge ATAM [Kazman et al. 2000]. I begge disse scenarier vil vi nok ikke udføre alle skridt men tilpasse dem til vores ønsker og interesser. Vi vil nok udføre punkterne i den listet orden, men det kan meget vel være nødvendigt at besøge nogen af dem igen. Så en iterativ proces over punkterne er nok den bedste løsning.
Relate the definition of software architecture in [Bass et al., 2003] to the elements of your design as outlined above. Give concrete examples of elements, relations, and structures. Strukturen er vores lagdelte Client - Server arkitektur, som består af elementerne Client, Server og Database. Relationen mellem Client og Server er et web-baseret request/response pattern mens relationen mellem Server og Databasen følger Facade pattern et. De eksterne synlige egenskaber for Databasen er dem der er synlige gennem Facaden. Som en konsekvens af den lag delte struktur er klientens egenskaber ikke synlige for serveren, og serverens egenskaber kan heller ikke tilgås fra databasen. Apply [Perry and Wolf, 1992] s model of software architecture as Software Architecture = {Elements, Form, Rationale} to the Beer Web System I artiklen deler de elementerne op i 3 kategorier: processsing, data og connecting. Processing er transformationer af data, data er information der kan blive ændret på og connecting er den måde vi forbinder de forskellige elementer i arkitekturen på. Vi definere Client, Server, Database, Client - Server relationen og Facade relationen til at være elementer i systemet. Databasen er et Data element da det eneste den skal er at send og modtag data. Server, Client og Facade er Processing elementer da de har til opgave at processer den information de modtager også at sende den videre. Forbindelsen mellem Client og Server er vores Connection element som bruger en form for internet kommunikation til at kommunikere over. Form beskriver de relationer der binder systemet sammen, i BWS s tilfælde er det vores Client Server relationen der tydeligvis er en rationale for systemet, da det er et krav at vores BWS system fungere på tværs af internettet. Da facade pattern et abstrahere den konkrete database kunne det meget vel tyde på at abstraktion af databasen også er et rationale for systemet. Discuss how the intentionality/locality thesis relates to the example Den givne specifikation for vores BWS er bevidst, da den ikke beskriver en specifik implementering, men bare en general arkitektur. Denne arkitektur kan man implementere på mange forskellige måder. Lokaliteten for arkitekturen er non-local, da vi sagtens kan tilføje elementer til den nuværende struktur der vil bryde strukturen. Vi kan f. eks tilføje et element der muliggøre kommunikation op i gennem vores lag og derved bryde den lag delte struktur vi har i vores BWS system. Reflect on what happens if the words software and computing are removed from the definition of software architecture in [Bass et al., 2003] Hvis vi fjerne de to ord bliver definitionen meget mere general. Den kan nu bruges på et hvert system, hvilket gør definitionen meget bred. Det er nu mere en general beskrivelse af at der kan identificeres som elementer og egenskaber. Selvom man nok kan beskrive et hvilket som helst system på denne måde, er det ikke sikkert at det er ønskværdigt. Der er situationer i den rigtige verden og sikkert også nogen i den digital, hvor man sikker godt kan beskrive den på denne måde. Men det vil nok være mere praktiske og hensigtsmæssigt at gøre det på en anden.
The architect decides to create a full architecture description before embarking on any implementation of the system. Discuss pros and cons of taking that approach I software arkitektur er tid ofte en af de vigtigste ting for stakeholders, ofte vil stakeholders gerne have produktet/systemet ud på markedet så hurtigt som muligt, et for at sikrere at andre ikke frigiver et lignende produkt og for det andet for at de kan begynde at promovere produktet og potentielt tjene penge på det. Så selvom man nok for et bedre og mere stabilt produkt ved at finpudse arkitekturen, så koster det flere penge og kan gøre udviklingsprocessen længere. Modsat er der også problemer med at frigiver et ufærdig eller ikke ordentlig gennemtænkt produkt, da det meget vel kan øge maintenance, ikke ordentligt supportere modifiability, produktet kan have problemer med performance, og hvis der er bugs kan det påvirke avalibility. Valget af hvad man gør, afhænger af hvad stakeholders krav til systemet er. Der er dog vigtigt at man ittrere hen over processen og ikke bare løser den slavisk trinvis. Det er f. eks vigtigt at man bliver klar over om de valgte kvalitets attributter er mulig at implementere, enten teoretisk eller inden for den givne tidsramme.
2 Architectural Description - Beer Web Store Which structures does a system such as the above exhibit? Give examples of elements and relations pertaining to each structure Ifølge [Bass et al., 2003] er en arkitektur-struktur en samling af elementer og deres forbindelser. Et view er en repræsentation af en sådan struktur. Artiklen beskriver også hvordan systemer ofte er alt for komplekse til at beskrive og forstå på en gang. En beskrivelse af et system består derfor af flere views, der hver repræsenterer en bestemt struktur i systemet. Som vist på tegningen i opgaven består Beer Web Store systemet af et antal brugere, en webserver og en database. Der er ikke specificeret noget viewpoint, og vi ved derfor ikke præcist hvordan tegningen skal analyseres. Et viewpoint er en generel måde at lave et view på og specificerer altså hvilken struktur man har valgt at beskrive et view med. [Bass et al., 2003] har lavet tre inddelinger af disse strukturer: Module: Fokuserer på implementationdelen af systemet. Et system kan være delt op i et antal moduler, der logisk adskiller forskellige dele af systemet. Disse moduler kan deles om i mindre komponenter/moduler. Der er altså tale om en beskrivelse af de statiske dele af systemet. Component and Connector: Fokuserer på de elementer der eksisterer når systemet afvikles. Allocation: Fokuserer forskellige software elementer i forhold til det environment det afvikles i. I Beer Web Shop kan man vælge at tolke systemet sådan at der findes tre hoved elementer; brugere, webserver og databasen. Her vil webserveren og databasen være modulopbygget. Hvert af disse moduler definerer en afgrænset rolle/opgave. Webserveren er i dette tilfælde delt op i tre undermoduler (decomposition), der hver afgrænser bestemte opgaver indenfor webserverens opgaver. Brugerene kan ses som værende en del af environmentet. Dvs. at de ville høre en under strukturen Allocation. Which viewpoints are relevant when describing the example? Give examples of partials views for each viewpoint For at gøre tegningen i opgaven mere sigende, kunne man vælge at bruge viewpoints. Her ville et sekvensdiagram eksempelvis kunne illustrere hvordan brugerne interagere med systemet og hvordan kommunikationen mellem webserveren og databasen foregår. Her ville et deploymentdiagram (allocation viewpoint) hjælpe med til at beskrive de konkrete valg af database og webserver. For at beskrive skrukturen af webserveren yderligere, kunne module viewpointet bruges. Her kunne der gives en uddybning af hvordan webserveren er delt op (udover "overview", "basket" og "data") i forskellige moduler og klasser. Dette ville give et større indblik i hvordan den statiske struktur af systemet ville se ud. Til sidt ville et C&C viewpoint kunne føre til forskellige views, der beskrev flowet i systemet.
Argue for benefits and liabilities of describing software architecture via a boxand-line drawing such as the above Tegningen i opgaven er en såkaldt box-and-line tegning. Her er fokus ikke nogen dybere indsigt i systemet eller strukturen, men derimod at give overblik. Der bliver ikke fulgt nogen fast standard i udarbejdelsen af en sådan tegning. Fordelen er at der ikke kræves nogen særlig (computer-) forståelse når en sådan tegning skal diskuteres mellem flere parter. Her vil alle kunne være med til at diskutere. Dette ville højst sandsynligt ikke være tilfældet hvis man diskuterede views ud fra eksempelvis allocation viewpoint. Ulempen er selvfølgelig at en sådan tegning ikke er ret konkret og specielt sigende når man kommer udover en generel diskussion af systemet. Discuss how architectural reflection could be used on the final running system Når et system er færdigudviklet er det selvfølgelig interessant at se på om den oprindelige arkitekturbeskrivelse stemmer overens med det færdige system. Ved at bruge refleksion kan man danne en arkitekturbeskrivelse ud fra et færdigudviklet system. Her vil den statiske del kunne genereres via UML-programmer direkte ud fra source-koden. Hvis man ønsker sekvens diagrammer skal man selvfølgelig analysere programmet mens det kører. Det samme gør sig gældende med views lavet ud fra C&C viewpointet. Til sidst vil man så kunne sammenholde de to arkitekturbeskrivelser og se om de er ens. Discuss what architectural description would be needed if the system was to be written using ArchJava Her ville man skulle opdele systemet i component and connectors, dvs. ud fra C&C viewpointet. Samtidig skal alt kommunikation der sker mellem de forskellige connectors beskrives. Når dette er gjort kan man begynde implementationen i ArchJava.
3 Quality Attributes Beer Web Store Describe technique(s) for architectural requirements capture that are applicable to the above case I dette kursus har vi anvendt Bass et al. måde at beskrive kvalitet på. Her anvendes betegnelsen kvalitetsattributter, der beskriver kvalitative egenskaber ved et system. Bass et al. mener at følgende seks kvalitetsattributter er de vigtigste. Availability Modifiability Performance Security Testability Usability For at kunne anvende ovenstående attributter giver Bass et al. en måde at beskrive disse på; Kvalitetsscenarier. Disse anvendes til at repræsentere de forskellige krav. Give feasible architectural requirements for availability and performance for the Beer Web Store using such techniques (at least one for each quality attribute) Til Beer Web Store har vi lavet følgende scenarier: Performance Source Stimulus Artifact Enviroment Response Response Measure Databasen får 100 forespørgsler på et sekund. Internt Webserver kommer med dataforespørgsel System Normal Databasen returnerer de ønskede oplysninger En forespørgsel svares på 1/100 sekund
Performance Source Stimulus Artifact Enviroment Response Response Measure 1.000.000 brugere tilgår webserveren i timen Eksterne brugere Sidernes indhold sendes tilbage til brugerne System Normal Siderne sendes/vises til brugerne En bruger skal have vist sin side indenfor 2 sekunder Avalibility Source Stimulus Artifact Enviroment Response Response Measure Databasen er blevet utilgængelig Intern Databasen har ikke svaret indenfor en fastlagt tidsperiode System Normal Ansvarshavene underrettes Backupserver tilsluttes indenfor 2 min. Argue how tactics and/or styles may be used to resolve the requirements Tactics beskriver hvordan bestemte kvaliteter opnås. Ved performance er målet at give svar på en forespørgsel inden for en given tid. Der er flere faktorere der spiller ind når man snakker om performance. Eksempelvis vil resourceforbruget have indvirkning. Resourcer kunne være CPU, hukommelse, plads på disk, båndbredde mm. Herudover er blokkeringer af resourcer også en faktor der spiller ind. Man vil f.eks. kunne komme ud for at vente på en ressource hvis en anden forspørgsel er i gang med at skrive til den. Sandsynligheden for at sådanne situationer opstår stiger i takt med at der kommer forespørgsler til ressourcen og tiden det tager at behandle en sådan forespørgsel. Dvs. problemet kan reduceres ved at gøre behandlingstiden mere effektiv. Dette kan gøres ved f.eks. benytte bedre algoritmer. I Availability er målet at undgå at fejl opstår og i tilfælde af at de gør, få dem rettet. Her deles taktikkerne op i forskellige kategorier; Fault Detection, Fault Recovery og Fault Prevention. I Fault Detection taktikken har man metoder til at se om der er noget galt. Dette kan f.eks. ske ved jævnligt at sende heartbeat signaler ud, der indikerer at serveren er i live. På samme
måde kunne der også kommunikeres ved ping/echo i faste tidsintervaller for at holde øje med om serveren var i live. Disse to taktikker opererer i forskellige processer. Hvis der er tale om komponenter i én proces, kan man bruge exceptions til at fange fejl. Ved Fault Recovery prøver man at forberede/lave et repair af systemet. Bass et al. beskriver flere måder at gøre dette på. Ved Voting-taktikken stemmer flere processer om hvad outputtet fra en algoritme er. Denne information sendes til en voter. De processer der ikke er enige med de andre markeres som fejlbehæftet. I Shadow Operation kan en proces der tidligere have fejlet køres i skygge. Her prøver processen at efterligne en normal proces før den igen selv bliver en aktiv service. Fault Prevention. Her kan man igen bruge forskellige taktikker. Removal from Service fjerner komponenten fra systemet for at undgå at den forventede fejl opstår. I Process Monitor kan man have en proces der overvåger andre processer. Hvis en fejl opstår slås processen ihjel og et nyt instans oprettes. Discuss where Service-Oriented Architecture can play a role with respect to the Beer Web Store? Consider the quality implications Nogle funktioner i Beer Web Store vil sagtens kunne flyttes ud af huset. F.eks. vil betalingsdelen af Beer Web Store godt kunne flyttes til et eksternt sted. Her skal man selvfølgelig være sikker på at det ikke går ud over ens kvalitetsattributter. På den anden side vil visse funktioner i Beer Web Store også kunne bruges af andre. Man kunne igen forestille sig betalingsdelen og f.eks. Basket delen af webserveren. Begge kunne være self contained og samtidig opfylde de to krav om at være Stateless og Context Independent. Reflect upon what the role of quality attributes in software architecture is Forskellige deltagere i en udviklingsproces har ofte mange forskellige holdninger til hvad kvalitet er. Det er da også rimelig klart at en udvikler ikke altid vil definere kvaliteten af noget software på samme måde som eksempelvis en grafiker. De kvalitetsattributter vi har kigget på, forsøger at lave en standard for hvordan kvalitet i software skal opfattes. Ved at have en sådan standard skulle det være muligt at træffe fælles beslutninger og konklusioner i forhold til hvilke kvaliteter der er vigtige i det konkrete system.
4 Architectural Design Beer Web Store Performance tactics Der er ifølge [Bass et al., 2003] tre kategorier af performance taktikker: Resource Demand Til det givne scenarie giver det mest mening at bruge taktikkerne increase computational efficiency og reduce computational overhead. Alternativt kan man prøve at reducere antallet af events der skal processeres, men da det er brugeren der styrer hvor mange events der kommer til systemet, ville det resulterer i at nogle events blev ignoreret, hvilket ville være meget uheldigt. Taktikken er altså at forbedre de algoritmer man bruger til at håndtere brugerens input, der består af betalingsoplysninger i det konkrete scenarie, samt minimere overhead i forbindelse med processeringen af disse input. Man skal dog være opmærksom på at hvis man reducerer overhead ved at fjerne abstraktionslag, hvilket medfører tab i modifiability. Resource Management Den nemmeste taktik at bruge her er increase available resources, men denne taktik har en klar ulempe; det koster penge. Desuden tilføjer den ikke nogen skaleringsmuligheder, hvis der kommer for mange samtidige brugere af systemet må man i ud og investere i endnu dyrere hardware. Det vil formegentlig være billigere at bruge de to andre nævnte teknikker til resource management: Introduce concurrency og maintain multiple copies of either data or computations. Det er dog vigtigt at man holder styr på sine kritiske regioner, og sikrer at man ikke for eksempel sælger en vare som lagervare hvis den i virkeligheden er udsoglt. Resource Arbitration Denne kategori omhandler scheduling, og der kan være fordele at hente ved at prioritere requests forskelligt, hvis krav til processeringstid ikke er proportional med den forventede processeringstid. Man kan for eksempel have et andet request end det i scenariet hvor den forventede processeringstid er lavere end det der er givet i scenariet, men kravet til processeringstiden af dette request er længere end de 10 sekunder fra scenariet; i dette tilfælde vil man kunne prioritere scenariets request højere, og på den måde tilfredsstille de ønskede krav. Availability tactics Der er ifølge [Bass et al. 2003] tre kategorier af availability taktikker: Fault detection Man kan gøre brug af alle tre taktikker fra [Bass et al., 2003] (ping/echo, heartbeat, exceptions) på følgende måde: Betalingsservicen kommunikerer med webserveren jævnligt; enten fordi den rent faktisk sender et heartbeat eller fordi den sender en log over aktivitet eller lignende, der så anvendes som heartbeat. Hvis webserveren opdager at der er gået for lang tid siden sidste heartbeat, kalder den en intern metode i webserverens fault detection system, der så sender et ping til servicen. Hvis servicen ikke returnerer et echo til det afsendte ping indenfor rimelig tid, kaster fault detection systemet en exception.
Fault recovery Den taktik der er lagt op til er at en administrator kontaktes og retter fejlen. Hvilket ikke har så meget med de taktikker der er angivet i [Bass et al., 2003] at gøre. Alle de taktikker der er angivet i [Bass et al., 2003] er forskellige grader af redundancy, på nær checkpoint/rollback. Checkpoint/rollback taktikken ville være meget passende til et betalingssystem, idet at hvis der går noget galt under en bataling, skal man sikrer sig at når betalingsservicen reintroduceres til systemet, så er der foretaget rollback til før eventuelle igangværende/ufærdige transaktioner. Fault prevention Der er i scenariet lag op til at anvende taktikken removal from service; hvis betalingsservicen går ned, kan man altså ikke fortaget et checkout af de varer man har tilføjet sin indkøbskurv, før betalingsservicen er reintroduceret, dette gøres for at undgå at yderligere fejl opstår i interaktionen med en defekt eller ikke-eksisterende betalingsservice. Taktikken transactions kan også anbefales, af samme grunde som checkpoint/rollback taktikken. Layered architectural style En layered architectural style medfører modifiability, idet et lag kun kommunikerer med det over-/under-liggende lag. Den modifiability taktik der bruges kaldes i [Bass et al., 2003] restrict communication paths. Desuden vil det i implementationen af den lagdelte arkitektur være oplagt at anvende flere modifiability taktikker som maintain semantic coherence, hide information, maintain existing interfaces og use an intermediary. Generelt set går en lagdelt arkitektur imod performance taktikken reduce computational overhead, da man ved at afgrænse kommunikationen vil komme til at forlænge den. Major elements in component and connector structure
Components og deres ansvar Database Persistent lagring af information omkring varer, for eksempel: antal, pris, URL til billede, beskrivelse Persistent lagring af ordrer Lagerstyring Varernes repræsentation på webserveren Holde styr på reserverede varer Opdatering af produktkataloger i tilfælde af reserverede eller solgte varer Opdatering af database i tilfælde af nye ordrer Produktkatalog Indkøbskurv Startpunkt for interaktion med brugeren Præsentation af de tilgængelige varer Udvælgelse af varer til indkøbskurv Holde styr på de varer kunden vil købe Præsentation af de varer kunden vil købe Fjerne varer fra indkøbskurv Betalingsservice Indsamle betalingsoplysninger Gennemføre betaling af ordre Annullere ordren hvis brugeren fortryder Connectors Når webserveren starter indhenter lagerstyringen information fra databasen via SQL query Et nyoprettet produktkatalog indhenter oplysninger omkring varer fra lagerstyring i XML Produktkataloget sender forespørgsler til lagerstyringen om at reservere en vare som kunden vil købe Lagerstyring er subject og produktkataloger er observer i et observer pattern, hvor der observeres på antalet af de enkelte varer Produktkataloget er producer og indkøbskurven er consumer af varer som kunden vil købe Produktkataloget og indkøbskurven kan overføre kontrol af brugergrænseflade til hinanden Indkøbskurven er subject og betalingssystemet er observer i et observer pattern, hvor der observeres på prisen af den aktuelle ordre Indkøbskurven og betalingssystemet kan overføre kontrol af brugergrænseflade til hinanden
-------------------------------------------------------------------------------------------------- Betalingsservice informerer indkøbskurven om at betalingen er gennemført Betalingsservice informerer indkøbskurven om at ordren er fortrudt Indkøbskurven er producer og produktkataloget er consumer af varer der er fortrudt Indkøbskurven er producer og produktkataloget er consumer af ordrer der er betalt Produktkataloget er producer og lagerstyringen er consumer af varer der er fortrudt Produktkataloget er producer og lagerstyringen er consumer af ordrer der er betalt Lagerstyringen sender databaseopdatering til databasen via SQL update Connector types Ved at brug connector types kan man opnå større modifiability, idet koden bliver delt op i mindre bider med semantic coherence. Prisen for denne modifiability er, som det ofte er tilfældet, performance på grund af computational overhead.
5 Architectural Prototyping Beer Web Store Types of architectural prototyping I [Christensen and Hansen, 2008] er architectural prototypes delt op i tre kategorier: Exploratory Denne type af prototyper er beregnet til at finde frem til forskellige arkitektoniske løsninger, da der allerede er fastsatte rammer (deployment strukturen) for arkitekturen er denne type mindre relevant, men kan stadig bruges til at udforske forskellige arkitektoniske valg indenfor de fastsatte rammer; for eksempel om man kan bruge et observer pattern til at holde browseren opdateret i tilfælde af ændringer så som en udsolgt vare. Experimental Denne type af prototyper er beregnet til at at måle og evaluere en arkitektur. Det ville være oplagt at anvende en experimental prototype til at vurdere om den angivne deployment arkitektur er fornuftig. Evolutionary En evolutionary prototype er en prototype som man iterativt modificerer, i håb om at forbedre den. Et prototype forløb kunne for eksempel være at have bygget exploratory prototyper, og kommet frem til en fornuftig arkitektur indenfor de rammer deployment strukturen angiver. Herefter har man udviklet en lidt tungere experimental prototype. Efter at have målt på denne og vurderet at arkitekturen lever op til de kvalitetsattributter der er stillet op har man iterativt videreudviklet denne experimental prototype via evolutionary prototyper, og kommet frem til en endelig arkitektur. Choosing programming language/framework Man kan bygge en ekperimental prototype i begge sprog og måle på prototypens kvalitetsattributter. Disse måldte kvalitetsattributter sammenholdes med de ønskede kvalitetsattributter for systemet, og ud udfra denne sammenholdning kan man så vælge programmeringssprog. Architectural prototype for testability I [Bass et al.] er der nævnt fire taktikker til testability: Record/playback Via en arkitektonisk prototype kan man undersøge muligheden for at bygge arkitekturen op så den understøtter at man kan optage den information der under kørsel bliver sendt fra en component over connector(s) til et andet component. Hvis man kan: Optage information der kommer som input til en komponent Optage den information der efterfølgende kommer som output Afspille optaget input til komponenten Så kan man skifte implementationen af en komponent ud, og sikre at den information der bliver optaget som output ikke er uhænsigtsmæssigt ændret siden det sidst optagede output.
Seperate interface from implementation Ved at lave en arkitektonisk prototype der helt konkret specificerer de interfacesc som implementationen skal opfylde sikrer man at man kan skifte implementationen af komponenter ud, og komponenten vil stadig kunne tale med andre komponenter, uden at skulle modificere disse. Dette gør også at man kan udskifte komponenter med stubløsninger, for at have fuld kontrol over komponentens handlinger. Specialize access routes/interfaces Specialized access routes/interfaces specificeres i den arkitektoniske prototype, så de ikke bliver glemt under implementationen. Build-in monitors Build-in monitors er ikke så egnet til at blive udforsket i en arkitektonisk prototype, da det handler om at aflæse tilstande internt i en komponent. Disse tilstande vil ofte ikke være til stede i de stub implementationer man benytter sig af i en arkitektonisk prototype. Benefits and liabilities of using ArchJava Benefits I ArchJava vil det være muligt at specificere opførelsen af connectors mere præcist, så man ved præcis hvilken type information der kan komme over en connector, or dermed sikre at alle disse typer kan testes jævnfør en eller flere af taktikkerne overnfor. I exploratory prototyping vil det være muligt at skifte connectors ud, for at afprøve hvilken effekt det har på de ønskede kvalitetsattributter; testability i denne case. Liabilities Der er ummiddelbart tre ulemper ved at bruge ArchJava: Det tager længere tid at udvikle Det medfører et computational overhead, og dermed performance tab og usikkerheder, hvilket medfører at man ikke kan regne med sine performance test. Hvis ikke implementationen skal være i ArchJava, skal de connectors der er specificeret i prototypens connectors oversættes til et andet programmeringssprog hvilket kan medføre nye fejlkilder.
Service-Oriented Architecture På slidesne fra forelæsningen om SOA er følgende guidelines for services beskrevet: Self-contained Service should have coarse-grained functionality Context-independence Service should not depend on other services Stateless Aka loose coupling Service should not retain client state between invocations Ved at benytte en service-oriented architecture opnår man et meget højt niveau af modifiability, idet man opfylder modifiability taktikker som maintain semantic coherence, generalize the module, hide information, maintain existing interfaces og ikke mindst runtime registration. Desuden vil det medfører at man kan samarbejde med andre webservices hvis det skulle være ønsket, også kaldet interoperability. Ulemper Som så ofte, er ulempen ved modifiability en risiko for at computational overhead bliver stort, hvilket vil medføre et performance tab.
6 Architectural Evaluation Beer Web Store Beskrivelse af ATAM-processen Architecture Tradeoff Analysis Method (ATAM), er et værktøj til at evaluere en arkitektur. Først og fremmest er ATAM et middel til at få indsigt i, hvorvidt den pågældende arkitektur opfylder forskellige kvalitetsmål, men den giver desuden et billede af, hvilke sammenhænge der er, disse kvaliteter imellem. Vi vil her antage, at læseren har kendskab til ATAM og blot opridse hvert trin i processen, som beskrevet i [Kazman et al., 2000]. På samme tid vil vi løbende forsøge at påpege, hvordan den kan benyttes til at evaluere Beer Web Store-systemet (BWS). Vi ved ikke meget om denne, men i og med at ATAM benyttes til at evaluere en arkitektur, bliver vi nødt til at antage, at der allerede eksisterer et forslag til én. Step 1 Present the ATAM Her klargøres selve metoden for alle de deltagende parter, ved en orientering fra de folk der leder processens afvikling, samt mulighed for at deltagerne kan stille spørgsmål. Dette indebærer både en præsentation af de ni forskellige trin i processen, en beskrivelse af de teknikker der benyttes (f.eks. utility tree generation), samt en beskrivelse af det forventede resultat af processen (f.eks. de tradeoffs, der identificeres). For Beer Web Store, kunne man forestille sig, at deltagerne ville bestå af en arkitekter (som typisk afvikler ATAM), projektledere, forretningsfolk, udviklere, driftstab og kommende kunder/brugere. Step 2 Present Business Drivers Målet med dette trin er at sikre, at alle deltagere har en ordentlig forståelse for det overordnede mål med systemet. Dette foregår igennem en beskrivelse, der foretages af projektlederen. Denne beskrivelse har en forretningsorienteret vinkel og kan blandt andet klargøre ting som; hvordan ser markedet ud, hvem er interessehavere i projektet, hvad er tidsbegrænsningerne, hvad er kundernes behov, hvad er budgettet, hvad er det tekniske fundament og begrænsninger, hvilke kvalitetsattributter skal der tages hensyn til og hvorfor. Her kunne projektlederen udover de ovennævnte ting f.eks. præsentere allerede eksisterende alternativer på markedet. Desuden ville de kvalitetsattributter der er nævnt i opgaveformuleringe, nemlig performance og modifiability, blive bragt på bane. Her ville main use case også blive fremlagt. Step 3 Present Architecture Her vil softwarearkitekten give en præsentation af arkitekturen. Denne er selvfølgelig direkte afhængig af, hvilke beslutninger der hidtil er taget om systemets arkitektur. Som en del af dette trin bidrager deltagerne desuden, ved at definere yderligere arkitektonisk information om systemet, som skal tages op til overvejelse i analysen. De dele af arkitekturen der dækkes, omfatter; tekniske begrænsninger helt ned til hardware-niveau, andre systemer som det pågældende system skal gøre brug af, samt de arkitektoniske tiltag der allerede er blevet overvejet til at imødekomme de opstillede kvalitetsmål. Vi ved ikke meget om arkitekturen for Beer Web Store, men i dette trin ville arkitekten præsentere sin deployment structure. Da web-serveren er en helt central komponent, ville det være naturligt, at diskutere den arkitektoniske struktur for denne og samspillet med de andre komponenter. Browser og database ville ikke kræve så meget tid, da de er temmelig veldefinerede, men man ville også diskutere valget af payment service man kunne forestille sig at dette ville være et eksternt system,
som BWS skal kommunikere med. Step 4 Identify Architectural Approaches Her identificeres de Architectural Approaches og Architectural Styles, der definerer de vigtige strukturer i systemet. Dette er vigtigt, fordi det er dem, der skal sikre at de krav og forventninger der er til systemet overholdes. For BWS-systemet ved vi som sagt ikke så meget konkret, men det ville f.eks. blive identificeret, at vi bruger client-server arkitektur og ikke eksempelvis en layered arkitektur. Step 5 Generate Quality Attribute Utility Tree I dette trin benytter man et Utility Tree til at finde ud af, hvilke kvalitetsattributter der ligger til grund for de væsentligste kvalitetsmål. Når de er blevet identificeret, prioriteres og forfines de og der genereres kvalitetsscenarier til at repræsentere de højest prioriterede. På denne måde indskrænkes antallet af områder, hvor resten af processen skal fokusere, til de vigtigste. Dette er essentielt, fordi det hjælper alle deltagerne til at opnå en form for konsensus, så de kan arbejde sammen, i stedet for at fokusere på deres personligt højest prioriterede områder. Dette handler altså udelukkende om at fastslå indsatsområder og ikke om at analysere systemet for at finde de arkitektoniske løsninger på problemstillingerne. Det utility tree der ville blive genereret her, ville give os nogle højt prioriterede scenarier, der ville afspejle de nævnte quality attributes, performance og modifiability. Ikke nødvendigvis de eneste, men vi ved fra opgaveformuleringen at de er vigtige, så man må antage, at i hvert fald nogle scenarier ville indfange disse. Step 6 Analyze Architectural Approaches Her benyttes kvalitetsscenarierne fra trin 5 til, igennem en dybdegående analyse, at finde frem til mulige Architectural Approaches og Styles for systemet. Resultatet er altid en liste af disse vigtige arkitektoniske beslutninger, men man sørger også for, på samme tid, at identificere en række risks (og non-risks), sensitivity points og tradeoff points. Samtidig sørger man for, på en struktureret måde, at dokumentere resultaterne igennem Architectural Approach Descriptions. Resultatet af dette vil blive præsenteret senere i afsnittet om Identificering af sensitivity points, tradeoff points og risks. Step 7 Brainstorm and Prioritize Scenarios I dette trin af ATAM-processen genereres der en række nye scenarier, igennem en brainstorming, foretaget af alle deltagere. Der søges to typer af scenarier, nemlig use case scenarios og change scenarios. Change scenarios kan opdeles i to kategorier; growth scenarios, som benyttes til at forudsige systemets styrker og svagheder i situationer hvor det udsættes for moderate ændringer, som f.eks. ændring af den underliggende platform, og exploratory scenarios, som benyttes til at beskrive situationer hvor systemet udsættes for drastiske ændringer, som f.eks. en omstrukturering af infrastrukturen. De forskellige scenarier prioriteres igennem en afstemning blandt deltagerne. For BWS ville man kunne finde begge typer af scenarier. Use case scenarier ville nok hovedsagligt beskæftige sig med brugerens oplevelse og have kvalitetsattributter som performance og (mindre arkitektonisk) usability i højsædet, mens change scenarier f.eks. kunne omhandle udvidelse af server delen, således at systemet ville kunne håndtere mange flere brugere, måske ved at lade flere servere dele arbejdet, i stedet for som deployment diagrammet antyder kun at have én.
Step 8 - Analyze Architectural Approaches Her foretages, i bedste fald, endnu en iteration af trin 6 og altså en knytning imellem hvert scenarie og en af de Architectural Approaches, som tidligere er blevet identificeret i systemet. Hvis det er tilfældet, at der ikke kan findes et arkitektonisk tiltag, som varetager det givne scenarie - hvilket betyder at vi i trin 7 har fundet et scenarie, som ingen af vores Architectural Approach Descriptions indfanger - så skal vi helt tilbage til trin 4 og gennemgå proceduren endnu en gang, indtil vi når til trin 8, uden at afsløre nogen problematiske brist i den samling af arkitektoniske tilgangsvinkler vi har samlet sammen. Her ville man, som sagt, i bedste fald ikke opdage noget nyt. Step 9 Present Results Her foretages en grundig rapportering af resultaterne fra hele processen. Identificering af sensitivity points, tradeoff points og risks Sensivity points Sensitivity points gør det klart, hvor der skal lægges særlig fokus, for at opnå et kvalitetsmål. Et eksempel kunne være, kommunikationen mellem serveren og de andre komponenter. Dette er et sensitivity point, der er væsentligt for at nå målet om modifiability og performance. At gøre det nemt at udvide (modify) systemet til at benytte mange servere, for at opnå bedre responstider (performance). Tradeoff points Et tradeoff point er et punkt, hvor man ved at varetage ét kvalitetsmål, tilsidesætter et andet. Lad os sige at man lavede en meget specifik implementering af kommunikationen mellem server og database, som er spredt rundt i hele server-implenteringen, med det mål at gøre kommunikationen hurtig, så tilgodeser man performance, men på samme tid tilsidesætter man modifiability, fordi det bliver meget sværere at skifte til en anden database. Havde man i stedet lavet et lag / interface imellem disse to komponenter, ville man situationen være omvendt. Fordele og svagheder ved ATAM i forbindelse med Beer Web Store Fordelen ved at bruge ATAM til at evaluere arkitekturen af Beer Web Store er begrænsede. ATAM er en langsommelig process, der kræver mange involverede, men kan til gengæld identificere nogle vigtige indsatsområder. Dog er BWS et forholdsvist simpelt system og måske ville tiden være givet bedre ud med andre evalueringsmetoder. At bruge DiscoTect til evaluering af Beer Web Store DiscoTect benyttes jo til at overvåge systemets runtime adfærd. I forbindelse med BWS-systemet, kunne man f.eks. benytte DiscoTect til at sikre, at tilgangen til databasen kun sker fra nogle bestemte software-komponenter i web-server-delen.
Sammenligning af ATAM og architectural prototyping ATAM er en mere teoretisk analyse, hvor man finder potentielle risici og beslutter hvilke arkitektoniske metoder, der er passende til det givne system. Derimod kan man med prototyping lave faktiske tests på systemet og finde ud af om der virkelig er tale om en risiko eller hvornår man når en grænse for hvad systemets arkitektur kan klare. Det idelle er kombinationen af de to metoder, hvor man først kunne lave en ATAM til at finde sensitivity points osv., for dernæst at lave prototypen til at teste dem. Når man tager Beer Web Store-systemets størrelse i betragtning, er det ikke sikkert at det vil være tiden og pengene værd at benytte en ATAM, men i stedet få nogle hurtige prototyper op i stedet. BWS er et forholdsvist simpelt system, der ideelt skal kunne håndtere mange brugere. Derfor ville de stress-tests som prototyping giver mulighed for være meget værdifulde.