Komponentbaseret softwareudvikling Acme ADL

Transkript

1 Komponentbaseret softwareudvikling Acme ADL Jonathan Christian Jørgensen Ture R. Nielsen og Peter Drewsen 9. april

2 INDHOLD INDHOLD Indhold 1 Indledning 3 2 Acme Grundlæggende elementer Yderligere elementer Egenskaber Begrænsninger Type system Acme Studio Systemer Familier Use-case Eksempel Modellering i Acme Studio Det overordnede system Server repræsentation Applikations repræsentation Evaluering af Acme Studio Analyse Forventninger til ADL'er Acme som ADL Kompleks system understøttelse Tidlig system analyse Samling af interessenter System forståelse Cost-benet Forbedringsforslag til Acme og Acme Studio Konklusion 18 Figurliste 19 Litteratur 20 Kildekode 21 2

3 1 INDLEDNING 1 Indledning I følgende rapport har vi i sinde at kigge nærmere på Acme, som er et architecture description language (ADL). Vi har indhentet information om Acme fra deres hjemmeside [5], samt ere artikler vedrørende Acme og ADL'er generelt [3][4]. Acme er både et ADL og et interchange language, som kan konvertere mellem ADL'er. Vi vil i denne rapport fokusere på Acme som et selvstændigt ADL. Vi vil i den anledning tage fat på værktøjet Acme Studio [6] som er et grask værktøj udviklet til Acme. For at vise brugen af dette værktøj vil vi modellere en hypotetisk use-case. Vi vil til sidst i rapporten analysere Acme og Acme Studio, samt belyse deres anvendelighed. Det antages at læseren er bekendt med komponentbaseret systemudvikling og har en forståelse for ADL'er på niveau med kurset Komponentbaseret Softwareudvikling. 3

4 2 ACME 2 Acme Acme er et andet generations generisk ADL. Da sproget er et andet generations sprog har det i forbindelse med udviklingen i stor grad været muligt at tage højde for tidligere erfaringer. Dette har bl.a. været medvirkende til at Acme er et generisk ADL, der kan tilpasse sig udviklingen af arkitekturer. Acme understøtter denition af 4 forskellige arkitekturdele. Struktur: Sammensætning af elementer til et system. Egenskaber: Information om systemet og dets dele, hvorudfra systemets funktionelle og ekstra funktionelle opførsel kan behandles. Begrænsninger: Retningslinjer for hvordan arkitekturen kan udvikle sig over tid. Typer og stilarter: Denition af standard arkitekturdele. I det følgende vil disse dele af Acme blive behandlet nærmere. 2.1 Grundlæggende elementer Komponenter: Beskriver de grundlæggende computationelle enheder eller datalagere. Disse bruges for eksempel til at symbolisere klienter, servere, objekter mv. Forbindelser: Beskriver kommunikation mellem komponenter. Dette kan indbefatte metoder så som fjernkald af objekter, broadcast af events, eller endda komplicerede protokoller. Systemer: Beskriver i denne sammenhæng kongurationer af komponenter og forbindelser (se g 1). Der kan både være tale om mængder eller delmængder af komponenter og forbindelser. 2.2 Yderligere elementer Porte: Komponent interfaces speciferes som porte på komponenter (se g. 1). Porte repræsenterer kommunikationsind- og udgange, som illlustrerer hvilke muligheder en given komponent har for at udveksle data med andre komponenter. En komponent kan understøtte ere interfaces ved at have en port til hvert. En port der enten være en simpel dataoverførelse eller implementere en større kommunikationsprotokol. Roller: Ligesom komponenter har porte, har forbindelser roller (se g. 1). Disse denerer deltagere i interaktioner mellem komponenter, og som sådan har en forbindelse altid mindst to roller. Dermed kan man beskrive fx sender og modtager eller mere komplicerede interaktioner som broadcasts. 4

5 2.2 Yderligere elementer 2 ACME System Forbindelse Komponent Komponent Rolle Port Figur 1: Systemelementer Repræsentationer: Hver komponent og forbindelse kan beskrives på et lavere abstraktionsniveau. Disse beskrivelser kaldes for repræsentationer i Acme. Fx kan man have en komponent som beskriver en server, som igen kan have en lavere liggende repræsentation af dens indre systemer (fx databaser eller ltre). Dette gør det muligt at lave hierarkiske beskrivelser af systemer. Det er også muligt for en komponent at have ere repræsentationer som beskriver forskellige perspektiver (se g 2). Komponent Repræsentationer Figur 2: Komponentrepræsentationer 5

6 2.3 Egenskaber 2 ACME 2.3 Egenskaber Som tillæg til de beskrevne designelementer giver Acme mulighed for at tilknytte dem egenskaber. Egenskaberne tilknyttes i form af lister, hvor hver egenskab angives ved et navn, en type og en værdi. Følgende er et eksempel på en liste med 2 egenskaber, der angiver at der max kan anvendes 20 klienter af gangen og der ikke anvendes multitråde. properties = { maxconcurrentclients : integer = 20; multithreaded : boolean = false;} Fra Acmes egen synsvinkel har egenskaber ingen funktion, de behandles ikke men er blot en uddybende beskrivelse af designelementerne. Brugbarheden af egenskaber ligger i forbindelse med værktøjer, der kan anvende dem til analyse, oversættelse mm. 2.4 Begrænsninger Begrænsninger på arkitekturer er specielle egenskaber, der udstikker arkitekturens grænser for udvikling over tid. Da dette er meget vigtige egenskaber, stiller Acme et specielt sprog til rådighed til beskrivelse af dette. Følgende er et eksempel på en begrænsning der angiver at alle komponenter i systemet maximalt kan have 5 forbindelser. forall comp : component in size(comp.connectors) <= 5; Et andet eksempel kunne være connected(client,server); der siger at komponenterne givet ved client og server er forbundet. Begrænsninger kan tilknyttes designelementer som 2 forskellige typer; invariant og heuristic. Hvis begrænsingen tilknyttes som invariant er det ikke tilladt at bryde reglen (brud medfører fejl), men hvis den derimod tilknyttes som heuristic er det tilladt under særlige omstændigheder (brud medfører advarsel). 2.5 Type system En vigtig egenskab for et ADL er muligheden for at kunne opbygge brugerdenerede typer til arkitekturer. Dette muliggøres i Acme i form af et type system. Type systemet giver mulighed for at denere typer indenfor 3 forskellige grupper: egenskabstyper, strukturtyper og stilarttyper. Egenskabstyper har vi allerede set anvendt i afsnit 2.3, hvor der i eksemplet 6

7 3 ACME STUDIO bliver anvendt typerne integer og boolean. Disse typer er en del af en gruppe af simple indbyggede typer, hvorudfra andre typer kan deneres. Strukturtyper giver muligheden for at denere specielle typer af komponenter, forbindelser, porte og roller ud fra standardelementerne af disse ved at tilføje egenskaber og begrænsninger til dem. Stilarttyper i Acme betegnes familier og denerer en mængde af strukturer med tilhørende egenskaber og begrænsninger. Familier bruges til at angive forskellige typer af repræsentationer. 3 Acme Studio Acme Studio er et værktøj, som understøtter ADL'et Acme. Ved hjælp af en grask brugerade leverer Acme Studio en visualisering af de elementer, som sproget tilbyder. Meningen med brugeraden er, at brugeren på en mere intuitiv måde kan tegne og redigere i arkitekturen, hvorudfra programmet genererer den tilsvarende Acme kode. Acme Studio anvender AcmeLib, som er et generelt bibliotek til understøttelse af Acme. AcmeLib eksistere både i en Java og en C++ version, for at sproget bedre kan anvendes i forskellige værktøjer. Anvendelsen af bibliotektet giver også bedre mulighed for at dele data mellem forskellige værktøjer. Acme Studio tillader brugeren for hvert projekt at oprette et antal overordnede familier og systemer, som før er blevet beskrevet. Vi vil i det næste belyse dem ift. det konkrete værktøj. 3.1 Systemer Som nævnt beskriver systemer sammenhængen mellem komponenter og forbindelser. I Acme Studio er systemer en overordnet visualisering eller graf over komponenter og deres sammenhæng. Foruden det simple billede af komponenter og deres sammenhæng, understøtter Acme Studio også Acmes hierarkiske struktur i form af delsystemer indeholdt i en samlende komponent (repræsentationer). Dette giver mulighed for at repræsentere meget komplicerede arkitekturer ved nogle overordnede komponenter med mulighed for at vise yderligere information om delsysterme. Placeringen af elementerne er ikke en del af sproget Acme, men er op til værktøjet selv at håndtere. Forskellige arkitektoniske stilarter, dvs. her en skabelon over mulige elementer, 7

8 3.2 Familier 3 ACME STUDIO deneres i familier, hvor hvert system eller repræsentation typisk tilhører en enkelt familie. 3.2 Familier Acme Studio leveres med en række familier, som hver denerer tilgængelige elementer, så som samlinger af komponent- og forbindelsestyper. Foruden de prædenerede familier, kan brugere også selv denere familier, med tilgængelige komponent-, forbindelse-, port- og rolletyper. Hver af disse kan have en brugerdeneret visualisering samt egenskaber og regler, som arkitekturen skal påkræve. Hvis en eller ere regler ikke er opfyldt kan Acme Studio give en fejlmeddelelse, der rapporterer hvilken regel, der ikke er opfyldt. Hverken denne parser eller visualisering er en del af sproget Acme. De medfølgende familier dækker navnligt de overordnede arkitektoniske stilarter i [1], som er Pipe and Filter, Shared Repository, Bus og Layered Abstract Machines, men også yderligere stilarter. Som sagt giver Acme Studio mulighed for at kombinere de forskellige stilarter enten i samme system eller ved at gruppere elementer tilhørende hver stilart i samlende komponenter. Komponenter, porte og forbindelser (og deres roller) er overordnede elementer, som altid er tilgængelige men ikke har særlige egenskaber eller regler, foruden selve sprogets regler/begrænsninger (f.eks. kan porte ganske naturligt kun placeres på komponenter). Nedenfor vil vi beskrive nogle af de medfølgende familier. ClientAndServer: Klient og server familien har to slags komponenter: klienter og servere. De overordnede regler er, at klienter har mindst en klient-port og servere mindst en server-port, enhver forbindelse skal gå mellem en klient og en server, og alle porte skal have en forbindelse. Layered: I den lagdelte familie er alle komponenter et lag med et heltalligt niveau, og kan have både sende- og modtage porte eller generelle lag-porte. Forbindelserne kan ligeledes være forbindelser til øvre lag, nedre lag eller blot en generel forbindelse mellem lag. Desuden kan lagene være multitrådet eller ej, hvilket afgør om forbindelserne skal være synkroniserede. PipesAndFilters: Denne familie har foruden ltre også datakilder og aøb som komponenttyper. De lovlige porte er oplagt in- og output porte. PubSub: Denne familie giver en skabelon for et netværk med deltagere. Forbindelsen mellem deltagerne foregår gennem en bus, som kan forbinde et ubegrænset antal deltagere. Ud fra sådanne familier, kan brugeren uden videre behov for selv at sidde med komplicerede denitioner, designe en arkitektur med grundlæggende regler. Enhver avanceret bruger vil dog nok selv oprette familier, der passer bedre til den pågældende arkitektur og inkludere ere systemspecikke regler og egenskaber. 8

9 4 USE-CASE 4 Use-case For at belyse styrker og svagheder ved sproget Acme, har vi valgt at lave en konkret use-case, som vi vil implementere i Acme ved hjælp af værktøjet Acme Studio [6]. Vi ønsker dermed især at analysere værktøjets praktiske anvendelsesområde. Desuden ønsker vi også at afprøve Acme Studios evne til at illustrere Acme kode, som den ikke selv har genereret. Vi har her støttet os til bl.a. [7]. 4.1 Eksempel Et rma vil starte et nyt klient-server baseret IT-system. Det skal køre over et lokalnetværk og der kræves at brugere logger ind med personligt kodeord af sikkerhedsmæssige årsager. Pga. de mange services som skal tilbydes brugere kan man ikke nøjes med en enkelt server, og det bestemmes at logon-serveren skal generere service tickets til hver bruger som ønsker at benytte en service fra netværket. Disse skal nødvendigvis krypteres for at bevare integriteten. Desuden vil den kommende administrator gerne have at logon-serveren registrerer brugere som er online, samt hvilke services de har adgang til. Der nås frem til at der kan bruges en TCP/IP protokol men der skal dog laves nogle mindre ændringer i den for at den er kompatibel med det eksisterende system. 4.2 Modellering i Acme Studio Det besluttes at systemet skal modelleres i Acme. Det iagttages at der er tre arkitektoniske stilarter som kan benyttes. Et lokalnetværk er en bus-stilart, hvor maskinerne kaster data ud og lytter på svar Ėn TCP/IP protokol benytter en abstrakt lagdelt stilart. En lettere modiceret TCP/IP protokol kan da benytte samme stilart. At kontrollere en brugers autencitet, registrere denne med en database, derefter generere en service ticket og til sidst kryptere denne, kan beskrives med Pipe and Filter stilarten. Disse tre stilarter kan knyttes sammen i et hierarki som vist på g. 3: Det overordnede system Det overordnede system er her i familien PubSub (se g. 4), og viser to klienter og en server forbundet til en bus med hhv. announce og receive interfaces. Ikonet øverst til højre på serverkomponenten viser, at den har en repræsentation. Desuden ses det, at komponenten bryder en eller ere regler for den pågældende familie, idet den har et rødt udråbstegn i venstre hjørne. Dette skyldes en konikt mellem det overordnede system og repræsentationen, fordi repræsenta- 9

10 4.2 Modellering i Acme Studio 4 USE-CASE Klient Klient Server Klient Abstrakt lagdelt Pipe and Filter Figur 3: Use-case model tionen tilhører en anden famile, og derfor ikke overholder PubSubs regel om at alle elementer skal tilhører denne familie. Det er med denne familie, og de andre medfølgende familier, ikke muligt at blande stilarter i arkitekturen. Vi vælger dog at se bort fra denne fejl for at kunne opbygge det ønskede system og belyse ere stilarter. En måde at forhindre denne type fejl kunne være selv at denere de ønskede stilarter og yderligere levere interfaces mellem disse Server repræsentation Serveren er her repræsenteret af tre lag, som tilhører familien Layered (se g. 5). Lagene repræsenterer de øverste lag i en TCP/IP protokol, med kommunikation mellem lagene via hhv. send og receive interfaces. Desuden er lagene nummereret hvilket ikke fremgår af den genererede graf. Det ses, at netværkslagets porte er direkte forbundet til de ydre porte (serverens receive og announce porte). Dette er gjort via bindings frem for attachments i Acme, og har derfor ingen tilknyttet rolle. Idet typen på de to porte her er forskellige burde man måske erklære særlige interfaces til kommunikation mellem de forskellige stilarter, som nævnt ovenfor. Igen ses det at applikationslaget har en yderligere repræsentation, med en fejl, der skyldes præcis det samme som ovenfor. 10

11 4.3 Evaluering af Acme Studio 4 USE-CASE Figur 4: Use-case netværk Applikations repræsentation Dette system viser hvordan serveren skal behandle den indkommende data og hvad den skal sende tilbage som svar (se g. 6). Dette inkluderer både ltre til kryptering, dekryptering samt brugerverikation. Det ses at input/output portene er direkte forbundet til lagets sende og modtage anmodninger. Igen burde der nok oprettes et særligt interface mellem disse. 4.3 Evaluering af Acme Studio Det lykkedes os til en vis grad at modellere vores use-case i Acme ved hjælp af Acme Studio, efter en del besværligheder. Den genererede acme-kode ndes sidst i rapporten. Overordnet kan vi sige, at Acme Studio let og hurtigt kan generere et simpelt skelet til en arkitektur specikation i Acme. Her er de medfølgende stilarter med til at muliggøre mere komplicerede arkitekturer med generelle regler og begrænsninger, uden selv at skulle implementere stilarterne. Problemet med værktøjet er dog, at det ikke lader til at understøtte Acme fuldt ud, idet ere af de funktionaliteter, som man kunne ønske sig ikke virker ordenligt. Endnu en overordnet ting, som begrænser værktøjets anvenlighed er, at det viser tydelige tegn på ikke at være færdigudviklet. Versionen i Eclipse er ikke helt stabil, og der er også mange grundlæggende fejl, især i visualiseringen og oprettelse af forbindelsr. Under implementationen af vores use-case i Acme Studio, har vi benyttet ere 11

12 4.3 Evaluering af Acme Studio 4 USE-CASE Figur 5: Use-case server repræsentation af de stilarter eller familier som værktøjet tilbyder, hvor vi syntes de passede ind i arkitekturen. På den positive side gav disse familier en del regler og begrænsninger til arkitekturen, hvorved man på et tidligt stadie ville have fundet ere designfejl i systemet. Et problem med de inkluderede familier, er at de ikke var designet til at snakke sammen, hvorved vores oprindelige antagelse, om at kunne implementere de forskellige repræsentationer i forskellige stilarter faldt til jorden. Dette er naturligvis ikke en svaghed ved selve sproget, men kunne blive et problem, hvis man ville holde sig inden for de inkluderede familier i Acme Studio. For ethvert større system vil vi derfor konkludere nødvendigheden for selv at denere stilarter/familier, som evt. har interfaces mellem hinanden. Meninger med at bruge familier er, som nævnt, at kunne stille en række krav og begrænsninger til systemet. Det er derfor også vigtigt at værktøjet er i stand til at se om disse regler er overholdt, og i modsat tilfælde kunne rapportere hvad og hvor der er et problem. Denne form for analyse er inkluderet i værktøjet, og kører automatisk. Generelt virker det meget godt, men en svaghed er dog fejlrapporteringen. I stedet for på en brugervenlig måde at påpege fejlen, bestod rapporteringen blot af markering af den eller de linier i Acme koden, hvori der var modstrid. Dette kan naturligvis være utroligt rart for udvikleren af den pågældende familie, men gør ikke brugen af værktøjet lettilgængeligt for de resterende udviklere, som blot bruger præ-denerede familier. Til sidst kan det nævnes, at selvom værktøjet leverer en grask grænseade hvorudfra man manipulere med Acme koden, er det også muligt at rette direkte i koden. Dette er en absolut nødvendighed for et værktøj, der i sig selv ikke 12

13 5 ANALYSE Figur 6: Use-case applikations repræsentaion understøtter al funktionalitet, som sproget leverer. Efter rettelser genskabes den graske repræsentation, svarende til koden, hvilket er forventeligt. Problemet opstår hvis parseren nder fejl i rettelserne. I stedet for komme med fejlmeddelser, lukkes hele visualiseringen blot ned, indtil fejlen er rettet. Dette virker absolut ikke hensigtsmæssigt, og er absolut endnu et område, som bør forbedres, hvis det skal være praktisk at bruge værktøjet sideløbende med egen Acme kode. 5 Analyse Efter at have kigget nærmere på ADL'et Acme og gennemført en use-case, vil vi nu foretage en analyse af mulighederne med ADL'et. Analysen vil både tage udgangspunkt i de aspekter som ADL'er forventes at kunne forbedre og de erfaringer vi har opnået i forbindelse med vores arbejde med Acme. I afsnit 5.1 vil vi foretage en opsamling af de vigtigste arkitektur aspekter i ADL'er. I det efterfølgende afsnit 5.2 vil Acme blive vurderet i forhold til de identicerede aspekter. I afsnit 5.3 vil vi kigge på cost-benet forholdet ved anvendelse af Acme og afslutningsvis vil vi foretage et kort kig på fremtiden for 13

14 5.1 Forventninger til ADL'er 5 ANALYSE Acme i afsnit Forventninger til ADL'er Den nok mest anvendte metode til at beskrive arkitekturer i dag, er brugen af kasse-pile diagrammer eksempelvis lavet i et almindeligt tegneprogram. Dette er en acceptabel metode for små systemer, men er ikke fuldstændig og meget uoverskuelig for store systemer. Det er her ADL'er kommer ind og giver mulighed for mere præcise beskrivelser af arkitekturer. Som beskrevet i afsnit 2 indgår der udover strukturen af systemet forskellige andre dele som egenskaber og begrænsninger i et ADL. Disse ekstra dele medfører at der kan opnås fordele ved anvendelsen af et ADL. Følgende er vigtige arkitektur aspekter identiceret ud fra [2] og [1]. Det er bl.a. disse aspekter anvendelsen af ADL'er skal være med til at forbedre. I næste afsnit vil vi kigge nærmere på aspekterne i forhold til Acme. Kompleks system understøttelse: I form af sin abstraktion, hvor der kun fokuseres på hoveddelene i systemet, er arkitekturer i stand til at præsentere selv store komplekse systemer. Tidlig system analyse: Des før et system kan analyseres des bedre. Hvis fejl og uhensigtsmæssigheder identiceres tidligt i udviklingsprocessen er prisen for at foretage rettelser meget mindre end sent i processen. Da arkitekturen er det første sted et systems struktur vises vil rettelser i forbindelse med analyse på dette tidspunkt være det billigste. Samling af interessenter: Der er typisk mange interessenter med forskellige interesseniveauer i et system. For at disse interessenter kan snakke sammen er der brug for et samlingspunkt. En arkitektur er et godt samlingspunkt da det er en abstraktion af systemet som de este interessenter kan relatere til. System forståelse Da arkitekturer kun fokusere på hoveddelene af et system, er det meget lettere at få et overblik over systemet. Desuden kan arkitekturer anvendes som dokumentation til fx at få et overblik i forbindelse med fremtidige ændringer af systemet. 5.2 Acme som ADL Det er tydeligt at idéen med Acme er at lave et generelt ADL, der kan anvendes i forbindelse med beskrivelse af de este former for systemer. Dette har også medført at Acme er meget stringent og kodenært. Sproget er desuden meget værktøjsafhængigt, dels på grund af at det er kodenært, men også fordi sproget i sig selv ingen relation har til egenskaber og begrænsninger beskrevet i det. Sproget giver blot mulighed for at beskrive egenskaberne og begrænsningerne, anvendelsen er op til værktøjerne, der behandler sproget. 14

15 5.2 Acme som ADL 5 ANALYSE Da Acme er meget værktøjsafhængigt er det meget vigtigt at der er den nødvendige mængde af værktøjer til rådighed af en god kvalitet Kompleks system understøttelse Selvom en arkitekturs abstraktion medfører at større systemer bliver mulige at overskue, er der grænser for hvor store systemerne kan være. Acmes anvendelse af repræsentationer gør at der kan laves overskuelige arkitekturer for selv meget store systemer. Dette skyldes at anvendelsen af repræsentationer giver mulighed for at zoome ind og ud på dele af arkitekturen. Acmes typesystem beskrevet i afsnit 2.5 er også medvirkende til at forbedre understøttelsen af store og komplekse systemer. Dette kommer af at der opnås en mere standardiseret opbygning af systemer ved anvendelsen af typer for de indgående elementer Tidlig system analyse Acme tilbyder ikke analyse af systemer tidligere end med simple repræsentationer af arkitekturer, men det giver mulighed for at forbedre analysen. Forbedringen består i at der kan udvikles værktøjer, der kan foretage automatisk analyse af arkitekturer. Et eksempel på en automatisk analyse der kunne være interessant og meget besværlig at foretage manuelt er en performance analyse. Denne ville kunne laves ved at estimere performance for de mindre dele af systemet, hvilket ofte er muligt at gøre rimelig præcist. Ud fra disse estimater ville der så fx kunne laves en køteori analyse Samling af interessenter Acmes repræsentation af arkitekturer er ikke i sig selv et godt samlingspunkt for et systems interessenter. Dette skyldes igen at sproget er meget kodenært og ikke let forståeligt for folk der ikke har med programmering at gøre. At Acme er stringent og kodenært har dog også sin fordel i forhold til samling af interessenter, idet der relativt simpelt kan udvikles forskellige præsentationsværktøjer. Disse anvender samme arkitektur beskrivelse, men er tilpasset de enkelte interessent grupper System forståelse Igen på grund af Acmes meget kodelignende repræsentation øger det ikke system forståelsen at kigge på denne. Her er det igen op til værktøjerne at opnå bedre system forståelse, fx i form af visualiseringer, præsentation af egenskaber og valideringer af begrænsninger. 15

16 5.3 Cost-benet 5 ANALYSE Som beskrevet i afsnit kan anvendelsen af repræsentationer også være medvirkende til at forbedre system forståelsen. Der kan zoomes ind på den del af systemet, der skal arbejdes med og forståelsen af denne kan opnås isoleret fra resten af systemet. 5.3 Cost-benet Det store spørgsmål man bør stille sig er: Kan det betale sig at bruge Acme ift. den mængde arbejde man skal lægge i det for at nå et brugbart resultat? Ville man opnå det samme ved at lave en illustration af modellen i et kasse-pile diagram? Dette afhænger meget af hvilke yderligere værktøjer man har. Uden nogen værktøj ville det være et kæmpe arbejde med at lære sproget, og det eneste man umiddelbart kunne vinde, ville være en form for strukturering. Hvis vi derfor antager at man har Acme Studio til rådighed, har man for det første et værktøj til generering af Acme kode, og for det andet en visualisering af koden. Dette i sig selv giver ingen fordel over et kasse-pile diagram. Det eneste yderligere som Acme Studio leverer er en parser, der kan undersøge om semantikken er overholdt. Vi kan derfor sige, at Acme Studio leverer en nyttig feature, men da det er besværligt at rode med og ikke særlig gennemarbejdet, vil det nok ikke give det store udbytte i forhold til besværet. Hvis der derimod blev udviklet ere værktøjer til Acme, ville benet måske i højere grad opveje cost. 5.4 Forbedringsforslag til Acme og Acme Studio Sproget Acme virker gennemtænkt og har mange applikationsmuligheder. Ud fra de få elementer i Acme er det teoretisk muligt at modellere mange forskellige og store systemer. Værktøjet Acme Studio fungerer derimod ikke særlig godt og er tydeligvis stadig i en meget tidlig fase. Det indeholder fejl og er meget mere kompliceret end sproget giver udtryk for. Der er grundlag for mange gode features, men der mangler stadig meget arbejde på stabiliteten af Acme Studio. Desuden er der stor mangel på værktøjer, enten selvstændige, eller som udvidelse til Acme Studio, til at arbejde på den model man får udviklet. Brugbarheden af Acme afhænger meget af hvor mange yderligere værktøjer der er til rådighed. Det ville for eksempel være umådeligt praktisk med interaktive visualiseringsværktøjer for at skabe en god forståelse af et system, og evt. kunne fremhæve dele som er relevante for forskellige interessenter. 16

17 5.4 Forbedringsforslag til Acme og Acme Studio 5 ANALYSE Derudover kunne man lave et værktøj til, ud fra arkitekturen, at danne programskeletter til komponenter mm. Evt. kunne man gå den anden vej, og automatisere opdatering af arkitekturen ud fra ændringer i programkode og derved forhindre eller reducere fx driv. 17

18 6 Konklusion 6 KONKLUSION Vores analyse af sproget Acme har vist, at det kan anvendes til skabe et godt fundament for en fyldestgørende beskrivelse af en bred vifte af arkitekturer, men er afhængigt af gode værktøjer til reelt at kunne analysere og bearbejde arkitekturen. Analysen af værktøjet Acme Studio har vist at det er et meget centalt værktøj for anvendelsen af sproget Acme. Det er dog stadig i et tidligt udviklingsstadie og leverer endnu ikke tilstrækkelig funktionalitet til at gøre brugen af Acme fordelagtig i større stil. Hvis man skulle arbejde videre med sproget Acme som ADL kunne man kigge nærmere på udvikling af værktøjer, og i hvor høj grad arkitekturen kan anvendes til afhjælpning af implementeringen af det endelige system. 18

19 FIGURER FIGURER Figurer 1 Systemelementer Komponentrepræsentationer Use-case model Use-case netværk Use-case server repræsentation Use-case applikations repræsentaion

20 LITTERATUR LITTERATUR Litteratur [1] Component-Based Software Engineering, Putting the Pieces Together, Heineman et al, Addison-Wesley, 2001 [2] Volume II. Technical Concepts of Component-Based Software Engineering, Bachmann, 2000 [3] A Case Study in Software Architecture Interchang, David Garlan and Zhenyu Wang, 1999 [4] Acme: Architectural Description of Component-Based Systems, David Garlan and Robert T. Monroe and David Wile, 2000, pages [5] Website of The Acme Architectural Description Language, acme/ [6] Website of AcmeStudio, acme/acmestudio/acmestudio.html [7] AcmeStudio 2.2 User Manual, acme/manual/acmestudio-2.2.html 20

21 usecase.acme KILDEKODE Kildekode import $AS_GLOBAL_PATH\families\PipesAndFiltersFam.acme; import $AS_GLOBAL_PATH\families\LayeredFam.acme; import $AS_GLOBAL_PATH\families\PubSubFam.acme; System Network : PipesAndFiltersFam, LayeredFam, PubSubFam = Connector Ethernet : EventBusT = new EventBusT extended with { Role r : r_publisher = new r_publisher; new PipesAndFiltersFam, LayeredFam, PubSubFam extended with { Role r0 : r_subscriber = Role r1 : r_publisher = Role r2 : r_subscriber = Role r3 : r_publisher = Role r4 : r_subscriber = new r_subscriber; new r_publisher; new r_subscriber; new r_publisher; new r_subscriber; Component Klient1 : ParticipantT = new ParticipantT extended with { Port p : p_announce = new p_announce; Port p0 : p_receive = new p_receive; Component Klient2 : ParticipantT = new ParticipantT extended with { Port p : p_announce = new p_announce; Port p0 : p_receive = new p_receive; Attachment Klient1.p to Ethernet.r; Attachment Klient1.p0 to Ethernet.r0; Attachment Klient2.p to Ethernet.r1; Attachment Klient2.p0 to Ethernet.r2; Component Server : ParticipantT = new ParticipantT extended with { Representation rep = { System rep : PipesAndFiltersFam, LayeredFam, PubSubFam = new PipesAndFiltersFam, LayeredFam, PubSubFam extended with { Component Transport_Layer : layert = new layert extended with { Port lowerport : sendrequestt = new sendrequestt extended with { Port receiverequestt0 : receiverequestt = new receiverequestt extended with { Port sendrequestt0 : sendrequestt = new sendrequestt extended with { Port upperport : receiverequestt = new receiverequestt extended with { 21

22 usecase.acme KILDEKODE Property handlesasynchrequests : boolean = false << default : boolean = false; >>; Property layerlevel : int = 2 << default : int = 10; >>; Property multithreaded : boolean = true << default : boolean = false; >>; Component Application_Layer : layert = new layert extended with { Port lowerport : sendrequestt = new sendrequestt extended with { Port receiverequestt0 : receiverequestt = new receiverequestt extended with { Port sendrequestt0 : sendrequestt = new sendrequestt extended with { Port upperport : receiverequestt = new receiverequestt extended with { Property handlesasynchrequests : boolean = false << default : boolean = false; >>; Property layerlevel : int = 3 << default : int = 10; >>; Property multithreaded : boolean = true << default : boolean = false; >>; Connector conn1 = { Role r; Role r0; Connector conn = { Role r; Role r0; Connector conn2 = { Role r; Role r0; Component User_verification : layert = new layert extended with { Port lowerport : sendrequestt = new sendrequestt extended with { Port upperport : receiverequestt = new receiverequestt extended with { Property handlesasynchrequests : boolean = false << default : boolean = false; >>; 22

23 usecase.acme KILDEKODE Property layerlevel : int = 4 << default : int = 10; >>; Property multithreaded : boolean = true << default : boolean = false; >>; Representation rep = { System rep : PipesAndFiltersFam, LayeredFam, PubSubFam = new PipesAndFiltersFam, LayeredFam, PubSubFam extended with { Component Encrypt : Filter = new Filter extended with { Port output : outputt = new outputt extended with { Property protocol : string = "char output"; Port input : inputt = new inputt extended with { Property protocol : string = "char input"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ]} << default : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ] >>; Property function : string; Component Register_user : Filter = new Filter extended with { Port output : outputt = new outputt extended with { Property protocol : string = "char output"; Port input : inputt = new inputt extended with { Property protocol : string = "char input"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ]} << default : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ] >>; Property function : string; Component Generate_Ticket : Filter = new Filter extended with { Port output : outputt = new outputt extended with { Property protocol : string = "char output"; Port input : inputt = new inputt extended with { Property protocol : string = "char input"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ]} << default : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ] >>; Property function : string; Component Verify_User : Filter = new Filter extended with { Port output : outputt = new outputt extended with { Property protocol : string = "char output"; Port input : inputt = new inputt extended with { Property protocol : string = "char input"; 23

24 usecase.acme KILDEKODE Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ]} << default : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ] >>; Property function : string; Component Decrypt : Filter = new Filter extended with { Port output : outputt = new outputt extended with { Property protocol : string = "char output"; Port input : inputt = new inputt extended with { Property protocol : string = "char input"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ]} << default : Set{flowpathRecT} = {[ frompt : string = "input"; topt : string = "output" ] >>; Property function : string; Connector conn0 : Pipe = new Pipe extended with { Role source : sourcet = new sourcet extended with { Property protocol : string = "char source"; Role sink : sinkt = new sinkt extended with { Property protocol : string = "char sink"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "source"; topt : string = "sink" ] Property buffersize : int = 0 << default : int = 0; >>; Connector conn : Pipe = new Pipe extended with { Role source : sourcet = new sourcet extended with { Property protocol : string = "char source"; Role sink : sinkt = new sinkt extended with { Property protocol : string = "char sink"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "source"; topt : string = "sink" ] Property buffersize : int = 0 << default : int = 0; >>; Connector conn6 : Pipe = new Pipe extended with { Role source : sourcet = new sourcet extended with { Property protocol : string = "char source"; Role sink : sinkt = new sinkt extended with { Property protocol : string = "char sink"; Property flowpaths : Set{flowpathRecT} = {[ 24

25 usecase.acme KILDEKODE frompt : string = "source"; topt : string = "sink" ] Property buffersize : int = 0 << default : int = 0; >>; Connector conn5 : Pipe = new Pipe extended with { Role source : sourcet = new sourcet extended with { Property protocol : string = "char source"; Role sink : sinkt = new sinkt extended with { Property protocol : string = "char sink"; Property flowpaths : Set{flowpathRecT} = {[ frompt : string = "source"; topt : string = "sink" ] Property buffersize : int = 0 << default : int = 0; >>; Attachment Register_user.output to conn5.sink; Attachment Verify_User.input to conn.source; Attachment Decrypt.output to conn.sink; Attachment Register_user.input to conn0.source; Attachment Verify_User.output to conn0.sink; Attachment Generate_Ticket.input to conn5.source; Attachment Generate_Ticket.output to conn6.sink; Attachment Encrypt.input to conn6.source; Bindings { Decrypt.input to User_verification.upperPort; Encrypt.output to User_verification.lowerPort; } Connector conn0 = { Role r; Role r0; Component Network_Layer : layert = new layert extended with { Port lowerport : sendrequestt = new sendrequestt extended with { Port receiverequestt0 : receiverequestt = new receiverequestt extended with { Port sendrequestt0 : sendrequestt = new sendrequestt extended with { Port upperport : receiverequestt = new receiverequestt extended with { 25

26 usecase.acme KILDEKODE Property handlesasynchrequests : boolean = false << default : boolean = false; >>; Property layerlevel : int = 1 << default : int = 10; >>; Property multithreaded : boolean = true << default : boolean = false; >>; Connector conn3 = { Role r; Role r0; Connector conn4 = { Role r; Role r0; Attachment User_verification.upperPort to conn.r0; Attachment Transport_Layer.receiveRequestT0 to conn3.r; Attachment Network_Layer.receiveRequestT0 to conn4.r0; Attachment Transport_Layer.sendRequestT0 to conn4.r; Attachment Application_Layer.upperPort to conn1.r; Attachment Transport_Layer.lowerPort to conn1.r0; Attachment User_verification.lowerPort to conn0.r0; Attachment Application_Layer.lowerPort to conn2.r; Attachment Network_Layer.sendRequestT0 to conn3.r0; Attachment Transport_Layer.upperPort to conn2.r0; Attachment Application_Layer.receiveRequestT0 to conn0.r; Attachment Application_Layer.sendRequestT0 to conn.r; Bindings { Network_Layer.upperPort to Server.p0; Network_Layer.lowerPort to Server.p; } Port p : p_announce = new p_announce; Port p0 : p_receive = new p_receive; Attachment Server.p to Ethernet.r3; Attachment Server.p0 to Ethernet.r4; 26