Att utforma och utvärdera ett komponentbaserat programmeringsgränssnitt

Fakulteten för Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå Att utforma och utvärdera ett komponentbaserat programmeringsgränssnitt To design and evaluate a component-based programming interface Nicklas Ahlgren Jimmy Kumpulainen Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Systemutvecklare Datum för slutseminarium: 2013-05-29 Examinator: Kristian Ekberg Handledare: Mia Persson Andrabedömare: Kristian Ekberg

Resumé Målet med det här arbetet är att presentera ett förslag på en komponentbaserad design som skall användas för att lösa ett problem som finns hos företag som jobbar med flera affärssystems API-komponenter. Lösningen som uppnås är ett komponentbaserat gränssnitt som låter sig anpassas, underhållas och utökas av användare. Vår lösning beskriver hur en design ser ut som låter utvecklarna hos dessa företag arbeta mot ett komponentbaserat gränssnitt som programmatiskt ser identiskt ut oberoende mot vilket API-system utvecklaren arbetar mot eller med. Resultatet når vi genom att använda en blandad metodik, d.v.s. en metodik där både kvalitativa och kvantitativa metoder används. Anledningen till valet av en blandad metodik baseras på att det genererar mer underlag som vi sedan kan använda för att analysera och komma fram till ett välgrundat resultat. Vi presenterar den bakgrundsteori som läsaren behöver sätta sig in i för att lättare kunna tolka och förstå vårt resultat. Resultatet beskrivs och analyserar utifrån den teori som vi tidigare har presenterats. Resultatet delas upp i tre kategorier: design, utvärdering av design och implementation. Dessa kategorier baseras på de metoder som vi har använt för att nå resultatet. Arbetet avslutas med en diskussion, metodutvärdering och sammanfattning som kort går igenom hela arbetet med uppsatsen, vad resultatet kan betyda och hur valet av metod har fungerat. Sist reflekterar vi kort över framtida forskning och hur det går att fortsätta med det här arbetet för att förstärka resultatet.

Abstract The aim of this thesis is to present a proposition of a component-based design which will be used to solve a problem for companies who works with several business systems API-components. The solution that is achieved is a component-base inteface that can be customized, maintained and expanded by the user. Our solution describes a design which let the developers at these companies to work against a component-based interface that, programatically, looks and works the same regardless of which business system API they work against. We will use a mixed methodology, that is, we will use both qualitative and quantitative methods to reach our result and conclusions. The choice to use a mixed methodology is based on that it generates more groundwork for us to reach a better result. We will present the background theory for the reader to better understand and interpret our result. We will present our result in three ways: a design, an evaluation of the design and a implementation. Each based on one of the methods we used to reach it. The thesis will be concluded with a discussion, method evaluation and a summary, where we will discuss the work with the thesis and what the result tells us. There will also be a short summary of our choice of methods have worked for us. At last we will reflect on future work, and what might be the next step to take to strengthen and improve our result.

Innehåll 1 Inledning 1 1.1 Bakgrund..................................... 1 1.2 Problemdiskussion och formulering....................... 1 2 Metod och avgränsningar 2 2.1 Metoddiskussion................................. 2 2.2 Avgränsningar................................... 3 3 Teknisk bakgrund 3 3.1 Mjukvaruarkitektur och design......................... 3 3.2 Komponenter................................... 4 3.2.1 Komponentbaserad utveckling, bakgrundshistoria........... 4 3.2.2 Vad är egentligen en komponent?.................... 4 3.2.3 Komponenters för- och nackdelar.................... 5 3.3 Kvalitetsattribut i design och arkitektur.................... 6 3.4 Att utforma en komponent............................ 6 3.4.1 Kvalitetsattribut i en komponent.................... 6 3.4.2 En komponents konsistens........................ 9 3.5 Mätmetoder för komponenter och moduler................... 10 3.5.1 Deng och Mercados evalueringmetod.................. 10 3.5.2 Mätmetoder................................ 10 3.5.3 Kvalitetsmodell.............................. 12 3.5.4 Formler.................................. 13 3.6 Mätmetoder på implementationsnivå...................... 14 4 Resultat och analys 15 4.1 Design....................................... 15 4.1.1 Klasser i komponenten.......................... 16 4.1.2 Analys av designen............................ 18 4.2 Utvärdering av design.............................. 19 4.3 Implementation.................................. 21 5 Diskussion och slutsats 24 5.1 Diskussion..................................... 25 5.1.1 Design................................... 25 5.1.2 Utvärdering................................ 26 5.1.3 Implementation.............................. 27 5.2 Metodutvärdering................................. 27 5.3 Slutsats...................................... 28 5.3.1 Sammanfattning av arbetet....................... 28 5.3.2 Vidare forskning............................. 28

Bilagor 31 A UML-diagram 31 B Uträkningar 34

1 Inledning 1.1 Bakgrund Idag är det vanligt att utveckla programvara som använder sig av tredepartsmjukvara via ett s.k. Application Programming Interface (API). Ett API kan kort beskrivas som ett gränssnitt som tillåter kommunikation mellan två applikationer. Det är inte ovanligt att tredjepartsmjukvaran kommer att uppdateras, ändras eller även bytas ut av olika anledningar, exempelvis säkerhet och ny eller förändrad funktionalitet. Detta kan vara ett stort problem då det kan ta lång tid att lära sig ett API, och att det är tidskrävande att utföra ändringar i källkod vid de fall där ett API uppdateras så mycket så att det inte går att använda tidigare källkod längre. En vanlig typ av system att arbeta mot på detta sätt är affärsystem som används av företag för bland annat hantering av kunder, ordrar, fakturor och resurshantering. Exempel på affärsystem som företag utvecklar lösningar för att arbeta mot är Visma 1 och Microsoft Dynamics CRM 2. Vid utveckling av lösningar som arbetar mot dessa typer av system är det en tidskrävande process att lära sig hantera och underhålla dessa gränssnitt [14]. Det kan också krävas att dessa lösningar behöver arbeta mot fler än ett affärssystem där själva arbetet mot affärsystemen är snarlikt medan affärsystemens API skiljer sig mer. För att utveckla en sådan lösning behövs det flera gränssnitt mot flera affärsystems API och utvecklare kommer behöva mycket tid till att underhålla, hantera och uppdatera dessa gränssnitt. Dessa problem är grunden till detta arbete. Lösningar på liknande problem har hittats [14], men inget som löser detta problem som beskrivs här. Ett lösningsförslag till detta är ett gränssnitt som gör det möjligt för utvecklare att hantera och anpassa ett eller flera APIer under samma gränssnitt. Detta skulle göra att gränssnittet mot olika affärsystem kan göras programmatisk lika, om inte identiska, vid snarlika åtgärder. Liknande system finns, ett exempel på ett sådant är musikspelaren Tomahawk 3, som i sitt standardutförande inte är mer än ett tomt skal. Det låter dock användare och utvecklare programmera insticksmoduler vilka arbetar mot olika musiktjänsters API-system. Det går t.ex. att lyssna på musik i Tomahawk som kommer från Youtube eller Soundcloud. Användaren ser inte någon skillnad på varifrån musiken kommer, utan det är något som sker på komponentnivå. 1.2 Problemdiskussion och formulering Två viktiga krav som ställs på ett sådant gränssnitt är att det skall vara lätt att utöka och att underhålla. Det skall vara möjligt att skapa nya gränssnitt för nya typer av affärssystem, det är viktig att befintlig källkod inte skall behöva ändras. Med dessa krav på gränssnittet passar det sig att detta gränssnitt skapas utefter komponentbaserad programvarudesign. 1 http://www.visma.se/ 2 http://www.microsoft.com/en-us/dynamics/crm.aspx 3 http://www.tomahawk-player.org/ 1

Det skall vara enkelt att utveckla nya komponenter för olika API-system, och dessa komponenter skall i sin tur vara portabla i den mening att de skall vara lätta att flytta och återanvända i olika system och lösningar vid behov. Komponenterna skall även vara självständiga i den betydelse att de skall fungera med hjälp av de olika affärssystemens API-komponenter, mer skall inte behövas för att komponenterna skall fungera och gå att använda. Frågorna som ställs är: Hur utformar vi ett komponentbaserat gränssnitt som uppfyller dessa krav på utökning och underhåll? Hur utvärderar vi de krav som är viktiga för designen? 2 Metod och avgränsningar I det här kapitlet presenteras den metod som har valts för arbetet. I diskussionen motiveras valet och en genomgång som beskriver hur metoderna kommer att användas presenteras. Sedan följer en diskussion som behandlar arbetets avgränsningar, där presenteras och motiveras avgränsningarna som valdes. 2.1 Metoddiskussion Vi har valt att använda oss av en blandad metod (mixed methods research) då det låter oss använda kvalitativa och kvantitativa undersökningsmetoder som passar bra för det här arbetets frågeställningar. Creswell [4] anger bland annat följande argument som anledningar där en blandad metodik passar bra: The insufficient argument (Otillräckliga bevis) Enbart en kvalitativ eller kvantitativ undersökning är inte tillräcklig för att svara på frågan. The more-evidence-the-better argument (Ju mer bevis desto bättre) Att kombinera en kvalitativ och en kvantitativ undersökning ger mer bevis. Community of practice argument (Miljö) En blandad metod kan vara att föredra i en vetenskaplig miljö. Genom att använda en blandad metodik i arbetet, d.v.s. genom att använda sig av både kvalitativa och kvantitativa metoder så kan vi nå ett bättre resultat. Det genererar mer bevis som man kan basera sitt resultat på än om man enbart skulle använda sig av antingen en kvalitativ eller kvantitativ metod. Den kvalitativa delen utgör litteraturinsamling och undersökning av de områden som är aktuella, d.v.s. komponentbaserad mjukvaruutveckling och utvärdering av systemarkitekturer. Detta för att skaffa en kunskapsgrund till att utforma och evaluera en komponentbaserad systemarkitektur. I den kvantitativa delen utformar vi ett komponentbaserat gränssnitt som vi skall utvärdera med hjälp av de metoder som Deng och Mercado presenterar i sitt arbete A Method for Metric-based Architecture Level Quality Evaluation [5]. Utvärderingen kommer att ske 2

genom att vi först kommer använda oss av Deng och Mercados kvalitetsmodell som byggs efter den design vi har skapat, sedan använder vi UML-diagram som beskriver designen för att få fram värden som används tillsammans med givna matematiska formler för att nå ett slutgiltigt resultat. Vi kommer även att implementera designen som ett skelett, d.v.s. en implementering i kod där fokus inte direkt ligger på funktionalitet via API-anrop, utan mer ett sätt att validera den design som vi har kommit fram till tidigare i arbetet. Med hjälp av den här typen av implementering kan vi lättare visa hur vi har tänkt att det skall fungera för slutanvändaren att använda vår komponent. 2.2 Avgränsningar Målet med det här arbetet är att ta fram ett möjligt förslag på en design för ett komponentbaserat gränssnitt i vilket användaren av komponenten själv skall kunna implementera den faktiska funktionalitet som önskas. Det kommer alltså inte att implementeras något som har med de olika affärssystemens API-anrop att göra, det ansvaret läggs på eventuell slutanvändare av designen. Vi kommer inte att titta på några ekonomiska aspekter av ett införande av ovan nämnda komponent, vår tanke är att se om det för det första är genomförbart. Det finns olika sätt att mäta och jämföra ett tidigare system med ett nytt [7], men det är inget som vi åtar oss att göra i det här arbetet. 3 Teknisk bakgrund Detta avsnitt presenterar den tekniska bakgrund och de koncept som läsaren behöver kunskap om för att kunna ta del och förstå resultat- och analysdelen senare i arbetet. Först behandlas komponenter och deras historia, följt av en presentation om kvalitetsattribut i design och arkitektur som definerar de kvalitetsattribut som är viktiga för designen som skall utformas. Sedan presenteras förslag på koncept som går att lägga till för bättre underhåll av komponenter. Avsnittet avslutas med ett underkapitel som behandlar metoder som går att använda för att utvärdera underhåll i komponenter. 3.1 Mjukvaruarkitektur och design För att skapa en klar bild av hur en mjukvara ska fungera används arkitektur och design [16]. Arkitekturen beskriver mjukvaran i ett större perspektiv medan design även ger mer detaljerade beskrivningar om delar eller komponenter i mjukvaran. Det finns olika verktyg som används för att modelera arkitektur och design på, vanligt är att modeleringsspråk används, exempelvis Unified Modeling Language [9] (UML). UML innehåller många olika diagram som används under modeleringsfasen för att skapa en klar överblick över vad som krävs av det system som håller på att konstrueras, men det ger även en mer detaljerad insyn i hur delar av systemet skall fungera och hur olika delar av systemet interagerar med varandra. 3

3.2 Komponenter 3.2.1 Komponentbaserad utveckling, bakgrundshistoria Tanken bakom komponentbaserad mjukvaruutveckling är egentligen bara en modernare iteration av tidigare system där subrutiner, eller funktioner, sparades undan för att kunna anropas flera gånger utan att behöva kopieras och klistras in där behovet av det fanns. Det här var tidigt i datorernas tid, då det var en fråga om att spara på mekaniska resurser. Det var helt enkelt mycket effektivare och resurssparande att anropa befintlig kod istället för att behöva dubblera koden på varje ställe där den behövde anropas [3]. Det här ledde till att bibliotek av metoder och funktioner skapades, vilka lät programmerarna att både återanvända sin egen, men även andra programmerares kod, vilket ledde till att programmerarna kunde fokusera mer på problemet de stod inför istället för att behöva skriva kod till delproblem som redan var lösta. När sedan begreppen uppgiftsseparering (Separation of Concerns) och Informationsgömning (Information hiding) myntades [3], vilka båda två bidrog till ännu mer självständig kod, så var det som i dag kallas för objektorienterad programmering ett faktum. Det gick nu att skriva kod som kunde stå på egna ben, självständig från annan kod i systemet, och tack vare väldefinerade specifikationer gick den här koden att återanvända i fler system och i fler sammanhang. Man kan tänka på dessa kod-komponenter som legobitar som man kan bygga med så att det passar det projekt man för tillfället jobbar med. Tidigare var det möjligt för programmerare att använda varandras kod för att lösa delproblem, nu är det möjligt att komponera hela system med hjälp av komponenter. Tanken med komponentbaserad mjukvaruutveckling är att man skall kunna lösa de problem man står inför genom att använda passande redan existerande komponenter, men även ge möjligheten att återanvända tidigare utvecklade komponenter. Man kan på det här sättet lägga större fokus på det övergripande målet istället för att lägga ner all kraft på att lösa alla delproblem på vägen dit från grunden. Det behövs alltså bara en övergripande förståelse av problemet man står inför för att kunna skapa ett informationssystem med hjälp av komponenter, man behöver inte ha kunskap över hur dessa komponenter löser problemen på detaljnivå. 3.2.2 Vad är egentligen en komponent? Det har rått delade uppfattningar om hur en komponent skall defineras. En av de mer vedertagna beskrivningarna av en komponent kommer från C. Szyperski [17]: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties. En komponent är alltså en sammansättning av en enhet där det bara finns kontraktbundna gränssnit och explicita kontextuella beronden. En mjukvarukomponent kan driftsättas oberoende och driftsätts av tredjepart. Enligt Sommerville [16] har en komponent tre egenskaper, dessa egenskaper är följande: En komponent skall kunna köras oberoende av sin omgivning 4

En komponent skall kunna användas av en annan komponent som inte känner till hur komponenten fungerar En komponent har inget tillstånd För att kunna köras helt oberoende av sin omgivning behöver komponentens funktionalitet vara helt inkapslad och om den skall kunna användas i en omgivning som inte vet hur den fungerar måste den ha ett väl definierat gränssnitt. Inkapsling (Information hiding) syftar på att funktionalitet kapslas in i kodblock i metoder på ett sätt som gör att användaren av funktionerna inte har någon insyn i hur de fungerar, de har bara tillgång till metodernas gränssnitt. Det gör att metoderna kan modifieras utan att det påverkar användaren, så länge de uppfyller samma krav som tidigare. Även om en komponent är oberoende av sin omgivning så kan den ha beroenden. Dessa beroenden är explicita och defineras i gränssnittet. En komponent har på så sätt två gränssnitt, ett gränssnitt som specifierar vilka tjänster komponenten erbjuder, och ett gränssnitt som specifierar vad för tjänster komponenten behöver. Komponenter kopplas samman i en infrastruktur eller en komponentmodell som det mer specifikt heter. Komponentmodellen hanterar kommunikationen mellan komponenterna för att tilhandahålla en tjänst. I komponentmodellen följer komponenternas gränssnitt en standard. Gränssnittet beskrivs av ett IDL (Interface Definition Language) som översätter den funktionalitet som gränssnittet erbjuder till interna anrop i komponenten. Det finns flera olika implementationer av IDL-språk, ett exempel är Microsofts version MIDL [13]. Detta medför att hur komponenten utför sin service ytterligare separeras från vad den erbjuder för service och att komponenter som är skrivna i olika språk kan interagera med varandra. Det finns flera olika komponentmodeller och standarder för kommunikation mellan komponenter. 3.2.3 Komponenters för- och nackdelar Fördelar med en komponentbaserad utvecklingsmetod [3] är att det tillför i bästa fall förminskade utvecklingstider då det tar mindre tid att använda en existerande komponent än att utveckla en ny från grunden, det tillför ökad tillförlitlighet då en existerande komponent med stor sannolikhet redan tidigare har använts i andra system, och det tillför en ökad flexibilitet då det finns stor frihet att välja en komponent, så länge en komponent uppfyller de krav som ställs så går den att använda. Men det finns även negativa aspekter av att använda komponenter [3], vad händer till exempel om det företag eller de personer som utvecklar en komponent som man använder slutar att utveckla den? Eller om företaget som utvecklar en komponent man använder går i konkurs? Det kan även vara så att en ny version av en komponent utvecklas som inte är kompatibel med den gamla versionen, vilket kan ställa till med problem. Det är inte heller säkert att en komponent uppfyller de krav på tillförlitlighet och tillgänglighet som ställs på den. 5

3.3 Kvalitetsattribut i design och arkitektur Ett system definieras med två typer av krav, funktionella och icke-funktionella [16], funktionella krav definerar vad ett system skall göra medan icke-funktionella krav definerar hur ett system skall fungera. Icke-funktionella krav kallas även för kvalitetsattribut, alltså systemets olika egenskaper. De kvalitetsattribut som det kommer att fokuseras på är: Underhållbarhet (Maintainability) - Hur lätt systemet är att underhålla och utöka. Återanvändbarhet (Reusability) - Återanvändbarhet av källkod och delkomponenter. Anledningen till att de här två attributen får fokus i arbetet är av anledningen att de är de som av oss anses viktigast för att uppnå de krav på underhåll och utökning som finns med i problemformuleringen. För ett komponentbaserat system kan dessa kvalitetsattribut ha en något annan innebörd [19]: Maintainability Reduced maintenance costs is seen as a major benefit of CBD. Ideally, defect-free components are available and are distributed by vendors that enhance functionality as needed. In a distributed component-based system the system and software maintenance process changes because of the involvement of the component vendor. So will some other processes such as configuration management. Reusability Increased reuse has long been seen as a major business goal as is reflected by the reuse process in ISO 15504. CBD elevates reuse to new heights. This will change activities in all process categories for example acquisition and requirement elicitation in the customer-supplier process category, analysis and design in the engineering process category in the supporting life cycle process category, and risk management in the organizational life cycle process category. Att kunna göra en evaluering av ett systems egenskaper så tidigt som möjligt är alltid en stor fördel då det blir mer tidskrävande och kostsamt att rätta fel eller oönskat beteende av systemet i ett senare skede [1, 10]. Att kunna evaluera sitt system redan i designprocessen är därför högst önskvärt. 3.4 Att utforma en komponent 3.4.1 Kvalitetsattribut i en komponent Sharma och Baliyan tar i sitt arbete Maintainability Analysis of Component Based Systems [15] upp flera saker som man måste tänka på när man utforma komponeter och komponentbaserade system som har ett högt krav på underhåll. Författarna tar ut de kvalitetsattribut som ingår i kvalitetsmodeller definerade av Boehm, McCall och ISO-9126 [2, 11, 8], och 6

kombinerar dessa med nya kvalitetsattribut som är anpassade och formade för komponentbaserad utveckling. De kvalitetsattribut som ingår i de tidigare nämnda kvalitetsmodellerna, när de anpassas för komponentbaserad utveckling, är följande: Testbarhet (Testability) Eftersom att en komponent ofta är en s.k. svart låda (black box), d.v.s. att de som betalar och använder en komponent oftast inte har tillgång till källkoden och kan därför inte se hur komponentens interna funktionalitet ser ut eller fungerar, så är det viktigt att utföra grundliga tester på komponenter för att hitta eventuella buggar och fel. Genom att testa grundligt och leta efter buggar och andra fel i komponenterna som används ökar man systemets användbarhet. Förståelighet (Understandability) Det här syftar på förmågan för användare av komponenten att se logiska samband i komponenten och hur den fungerar. Det syftar även på användarens förmåga att förstå var en komponent passar in i ett system. Dokumentation är ett bra sätt att öka en komponent eller ett systems förståelighet. Modifikationsbarhet (Modifiability) Den här punkten, tillsammans med punkten föränderlighet ersätts med punkten Specialanpassningsbarhet (tailorability, mer om det nedan i texten), då de är väldigt snarlika. Föränderlighet (Changeability) Se punkten ovan. Stabilitet (Stability) Den här punkten syftar till en mjukvaras förmåga att undvika oavsiktliga effekter vid modifikation av mjukvaran. Sharma och Baliyan anser att den här punkten inte bör gälla på komponentnivå, utan snarare bör den gälla för de system som använder sig av komponenter. Analysbarhet (Analyzability) Den här punkten behövs inte heller enligt Sharma och Baliyan, en komponent är oftast utvecklad för att utföra en sak, och behöver därför inte analyseras på samma sätt som ett helt system. Koncishet (Conciseness) Genom att kapsla in så mycket som möjligt, samtidigt som man återanvänder kod i utvecklingen av komponenter där det finns en möjlighet, så uppfyller man den här punkten. Ingen överflödig information skall visas eller göras tillgänglig för användaren av en komponent, utan det är bara det publika gränssnittet som skall agera kontaktyta mellan användare, system och komponent. Självbeskrivbarhet (Self descriptiveness) Den här puntken anser Sharma och Baliyan överflödig, då den istället borde ingå under punkten förståelighet. Modularitet (Modularity) Genom att öka en komponents modularitet så ökar man ett systems underhållbarhet, det då det blir lättare att skräddarsy användandet av komponenten i systemet. Modularitet beskrivs som ett sätt att separera funktionalitet i programkod i mindre moduler, där dessa moduler tillgängliggör ett publikt gränssnitt via vilket modulerna kan kommunicera med varandra. Modulerna kan innehålla privat data för intern funktionalitet, funktionalitet som inte går att nå utanför modulen [6]. 7

Uppfyllelse (Compliance) Vid tidpunkten för Sharma och Baliyans publicering av sitt arbete fanns det inte någon satt standard för den här punkten, så den utelämnades av det skälet. Tydlighet (Simplicity) Sharma och Baliyan menar att ju tydligare en komponent är, ju högre förståelighet når den. Den här punkten utelämnas då de anser att den implicit ingår i punkten förståelighet. Av dessa anser Sharma och Baliyan att testbarhet, förståelighet, Specialanpassningsbarhet (en sammanslagning av modifikationsbarhet och föränderlighet, då dessa närmast är synonyma med varandra), modularitet och koncishet bör ingå i en kvalitetsmodell för komponentbaserad utveckling. Sedan beskriver Sharma och Baliyan nya kvalitetsattribut som de anser bör uppfyllas för att nå god underhållbarhet i komponentbaserad utveckling, de nya attributen är följande: Återanvändbarhet (Reusability) Det här anses vara av stor vikt då en komponent behöver vara återanvändningsbar och portabel. Återanvändbarhet föreslås som ett attribut som bör finnas med i vad som krävs för underhållbarhet. Återanvändbarhet främjar underhåll då det bidrar med lägre utvecklingskostnader. Under den här punkten ingår följande underpunkter: Installationsbarhet (Installability) Det här sätts som ett delkrav för återanvändbarheten, det krävs att en komponent är lätt att hantera och installera för användaren av den. Anpassningsbarhet (Adaptability) En komponent bör vara anspassningsbar för olika platformar, på det sättet går den att använda i fler system. Utbytbarhet (Replaceability) Även det här sätts som ett delkrav för återanvändbarhet, det syftar på att komponenten bör vara så kompatibel med tidigare versioner som möjligt, det leder till en lättare övergång vid nya versioner. Specialanpassningsbarhet (Tailorability) Det här syftar på att det skall vara lätt att förbättra tjänsten mot slutanvändaren, genom att konfigurera komponenter och komponentbaserade system på ett bra sätt. Det här syftar på hela system. Man skall kunna skräddarsy funktionaliteten enligt de krav som slutanvändaren ställer. Under den här punkten ingår följande underpunkter: Ändringsbarhet (Customizability) Det här delkravet syftar på möjligheten att modifiera en komponent genom dess begränsade information, som gränssnitt och funktionsparametrar. Utbyggbarhet (Extensibility) Det här syftar på ett systems förmåga att hantera nya komponenter. Spårningsbarhet (Trackability) Det här syftar på möjligheten att spåra olika versioner av komponenter, deras konfigurationer samt kompatibilitet med olika mjukvara. Den här punkten gäller till största del för hela system, inte enskilda komponenter. Sharma 8

och Baliyan menar att det i underhållbarhet för komponentbaserade system måste ingå en spårningsmetod eller ett spårningssystem för att hålla reda på ett systems olika komponenter. Under den här punkten ingår följande underpunkter: Prestandaspårning (Performance tracking) Sharma och Baliyan anser att man måste spåra prestandan i system efter varje ändring. Det som bör undersökas är sådant som resurshantering och min/max-värden i systemet. Kompatibilitetsspårning (Compatibility tracking) Med kompatibilitetsspårning menar Sharma och Baliyan att det bör spåras när ändringar i komponenten sker, ändringar som kan påverka hur de fungerar i det system där de används. Sådana ändringar kan vara att ändra programmeringsspråk, ändrade gränssnitt eller ändrad funktionalitet. Skalbarhet faller in under den här punkten, vilket de säger inte bara syftar på datavolym, utan även med hur många andra komponenter en komponent kan kommunicera med innan det blir reducerad prestanda i systemet. Den nya kvalitetsmodellen som Sharma och Baliyan anser bör användas för komponentbaserad utveckling innefattar då attributen testbarhet, förståelighet, specialanpassningsbarhet, modularitet, koncishet, återanvändbarhet, spårningsbarhet och skalbarhet. Dessa attribut är de som Sharma och Baliyan har identiferat som nödvändiga för hög underhållbarhet i komponentbaserad utveckling. Tabell 1: Sharma och Baliyans kvalitetsmodell [15] Testbarhet Förståelighet Specialanpassningsbarhet Spårningsbarhet Modularitet Koncishet Återanvändbarhet Skalbarhet Värt att notera är att ISO-9126 har utgått och ersatts med ISO-25010. Sharma och Baliyans arbete publicerades två månader efer att ISO-25010 ersatte ISO-9126, och använde därför den gamla ISO-9126-standarden i sitt arbete då det var den aktuella standarden vid den tidpunkten. 3.4.2 En komponents konsistens För att en komponent ska uppnå en hög återanvändbarhet så är det viktigt att tänka på komponentens konsistens (consistency) [18]: A component is consistent if, assuming the correct operation of the components that are used, its architecture actually provides the functionality specified in the component specification. A system architecture is consistent if its components are consistent and every component placeholder is mapped onto a component which actually provides the functionality specified in the component placeholder. Clearly, consistency is very important in the context of component-based software development: Will a component fit or not? 9

Det är alltså viktigt att utforma komponenter som håller sig till den specifikation som de tidigare har tilldelats. Om alla komponenter i ett system passar, och anses vara konsistenta, så är hela systemet konsistent. 3.5 Mätmetoder för komponenter och moduler I det här avsnitten presenteras den metod som Deng och Mercado har tagit fram för att mäta underhållbarhet på komponenter [5], denna presentation av de olika delar som ingår i deras metod för att läsaren lättare skall kunna förstå och tolka kvalitetsmodellen som byggs utifrån deras exempel och det resultat som uppnås med hjälp av deras mätmetod. Syftet med genomgången av deras framtagna metod är att underlätta och göra det lättare för läsaren att relatera till resultatet som presenteras senare i arbetet. 3.5.1 Deng och Mercados evalueringmetod Deng och Mercados metod består av tre delar [5]. Den första delen består av utvalda mätmetoder som, med hjälp av UML-diagram, ger olika värden på en design. Den andra delen består av en kvalitetsmodell som byggs upp av mätvärdena som räknas ut med hjälp av UML-diagramen, samt s.k. weight values, vilka utdelas av metodens användare efter hur mycket mätvärdena anses påverka systemet och komponenterna som skall mätas. Den delen består av tre matematiska formler som används för att nå ett slutvärde. Alla dessa delar kommer att beskrivas mer utförligt i kommande delar. 3.5.2 Mätmetoder Hao Deng och Camilo Mercado [5] har tagit fram metoder för att evaluera och mäta modulariteten i komponenter och system med hjälp av UML-diagram, där UML-diagram av olika typer då fungerar som indata. Vad dessa metoder mäter är bland annat graden av sammankoppling (coupling) och sammanhang (cohesion) i systemet och dess komponenter, vilket är av stor vikt för mätningen av vår komponent. Sammankoppling (Coupling) Är ett mått på hur mycket beroende det finns mellan två objekt. Kräver en ändring i ena objektet att det andra objektekt också ändras? Då har objekten hög sammankoppling. Man vill ha låg sammankopling för lättare underhåll, då det är enklare att utföra eventuella ändringar och förbättringar om så lite som möjligt i systemet påverkas av det. Sammanhang (Cohesion) Är det mått som mäter hur moduler (subrutiner, klasser, etc.) följer principen att varje modul skall ha enbart ett ansvar. Man vill att klasser skall vara uppdelade i den mån att metoderna i klassen utför en sak, inte mer. Klasserna skall ha en uppgift och utföra den väl, man vill inte att en klass skall ha många olika ansvar, det leder till att det blir svårare att underhålla klassen. Mätmetoderna har olika utmärkande egenskaper som visar vad som mäts och på vilken nivå etc. Dessa förklaras nedan. 10

Kategori Metric Name Description Level Category Indicator Direction Related Artifact(s) Tabell 2: Beskrivning av mätmetoder Förklaring Mätmetodens namn. Beskrivning av mätmetoden. Mätmetodens nivå dvs. systemnivå eller komponentnivå. Vad som mäts t ex. storlek eller sammankoppling. Om mätvärdet är positivt eller negativt, dvs. om ett högt eller lågt värde är önskvärt. Vad för UML-diagram som behövs för att använda mätmetoden. Vilka mätmetoder som kan användas är enligt Deng och Mercado flexibelt [5], det beror till stor del på vilka UML-diagram som finns tillgängliga att använda sig av, och det skall även vara lätt att konstruera nya mätmetoder som kan användas i kvalitetsmodellen. Följande mätmetoder passar för mätningar på komponentnivå och kommer att användas i denna studie: Metric Name Description Level Category Indicator Direction Related Artifact(s) Tabell 3: Coupling betwee components (CBCOM) Coupling between components (CBCOM) The metric counts the components which are coupled with a component under consideration regardless of the service direction. Component level metric Coupling Reverse indicator (low value means low component coupling). Component diagram Tabell 4: Degree of component couplings (DCOMC) Metric Name Degree of component couplings (DCOMC) Description The metric calculates the degree of the coupling of a component according to different types of couplings. Level Component level metric Category Coupling Indicator Direction Reverse indicator (low value means low component coupling). Related Artifact(s) Component diagram 11

Tabell 5: Number of classes per component (NCPC) Metric Name Number of classes per component (NCPC) Description The metric counts the number of classes of a component under consideration. Level Component level metric Category Size Indicator Direction Reverse indicator (low value means the component is relatively easy to maintain). Related Artifact(s) Component diagram, class diagram Metric Name Description Level Category Indicator Direction Related Artifact(s) Tabell 6: Coupling between classes (CBC) Coupling between classes (CBC) The metric counts the classes which are coupled with a class under consideration. Component level metric Coupling Reverse indicator (low value means low classes coupling). Component diagram, class diagram Metric Name Description Level Category Indicator Direction Related Artifact(s) Tabell 7: Degree of class coupling (DCC) Degree of class coupling (DCC) The metric calculates the degree of the coupling of a class according to different types of class coupling. Component level metric Size Reverse indicator (low value means low component coupling). Component diagram 3.5.3 Kvalitetsmodell För att visualisera relationer mellan mätvärden, delkrav och kvalitetsattribut används kvalitetsmodellen som Deng och Mercado har tagit fram till denna mätmetod [5]. Den visar hur ett eller flera mätvärdern relaterar till delkrav som i sin tur relaterar till ett kvalitetsattribut. Vikter och riktningar tilldelas mellan mätvärden och delkrav efter hur mycket mätvärdet påverkar delkravet och ifall mätvärderna är positiva eller negativa dvs. om deras värden har positiv eller negativ påverkan på delkravet. 12

Figur 1: Exempel på Deng och Mercados Kvalitetsmodell Figur 1 ovan visar hur kvalitetsmodellen för ett system ser ut. Här syns tydligt hur mätvärdena (m) relaterar till delkraven (QC). Pilarna visar om mätvärdena har en negativ eller positiv påverkan på delkraven, pekar pilen mot mätvärdena betyder det att mätvärdet är negativt och ett lägre mätvärde innebär ett bättre resultat. Pekar pilen från mätvärdet innebär det att mätvärdet är positivt och ett högre värde innebär bättre resultat. Kvalitetsattributet (QA) består av flera delkrav (QC) samt att systemets kvallitetsattribut(sysqa) påverkas av komponenternas kvalitetsattribut (ComQA), dock är denna relation inte riktad eller är tilldelad vikt. På komponentnivå har Deng och Mercado identifierat tre viktiga delkrav för en komponents underhållbarhet. Delkraven är testbarhet, modularitet och förståelighet [5]. 3.5.4 Formler Normalisering av mätvärden När mätvärderna har tagits fram skall de normailseras till värden mellan noll och ett. Detta görs med hjälp av följande min/max-formel. Där X är det normaliserade mätvärdet och d representerar mätvärdet innan det har normaliserats. 13

d min och d max representerar det lägsta resultatet av mätmetoden respektive det högsta. d d min d max d min : d d min dmax X = 1 : d = d max (1) 0 : d = d min Normalisering av vikter Även vikterna skall normaliseras för att resultatet inte skall skilja sig allt för mycket på grund av detaljer. Normaliseringen sker enligt följande formel där i och j representerar antalet positiva respektive negativa mätvärden relaterade till ett delkrav. W och W representerar de positiva respektive negativa vikterna. Formeln normaliserar vikterna så att summan av alla vikter blir ett. i j W n + W n = 1 (2) n=1 n=1 Formel Nr.1 När mätvärderna och vikterna har normaliserats kan första formeln användas för sätta värden på delkraven. I denna formel representerar m och W mätvärden som är positiva och deras vikter medan m och W representerar negativa mätvärden och deras vikter. Notera att i och j är antalet positiva respektive negativa mätattribut och att m, m, W och W bara kan anta positiva värden. QC = i m n W n n=1 j m nw n + n=1 j W n (3) Formel Nr.2 Den andra formeln sammanfattar kvalitetsattributet på komponenten. I denna formel representerar QC QA alla delkrav för komponenten. QA com = QC QA n=1 3.6 Mätmetoder på implementationsnivå n=1 QC QA W n (4) Genom att använda Microsoft Visual Studio för att implementera designen så kommer man åt funktionalitet vilken låter en generera klassdiagram som går att använda för att jämföra med den framtagna designen. På så sätt kan man se om implementationen stämmer överens med designen, vilket på ett sätt verifierar att designen går att omsätta till körbar kod. Man kan även använda sig av en funktion som genererar kodmätdata (code metrics) som visar olika värden baserade på den kod som ingår i det aktuella projektet. Så här skriver Microsoft själva om Code Metrics Values [12]: Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developers can understand which types and/or methods should be reworked or more thoroughly tested. Development teams can identify potential risks, understand the current state of a project, and track progress during software development. 14

De värden som mäts är följande: Maintainability Index Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability. Cyclomatic Complexity Measures the structural complexity of the code. It is created by calculating the number of different code paths in the flow of the program. A program that has complex control flow will require more tests to achieve good code coverage and will be less maintainable. Depth of Inheritance Indicates the number of class definitions that extend to the root of the class hierarchy. The deeper the hierarchy the more difficult it might be to understand where particular methods and fields are defined or/and redefined. Class Coupling Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. Tittar man på dessa värden så ser man att de är bra att använda sig av för att få en överblick av ett projekts status rent kodmässigt, samtidigt som man kan se sådant som koppling mellan klasser och hur många steg av arv det finns. Det kan man sen använda mot den design som man baserar sin kod på och se om resultaten stämmer överens med designen. 4 Resultat och analys I det här kapitlet beskrivs och analyseras resultaten som har uppnåtts. Vårt resultat kan delas upp i tre delar, nämligen design, utvärderingsresultat och slutligen implementation av designen. 4.1 Design Efter litteraturstudien utformades en design av ett komponentbaserat gränssnitt [5, 7, 15, 19]. De kvalitetsattribut som vi valt att fokusera på är återanvändbarhet och utbytbarhet, då dessa attribut ansågs vara viktigast för att uppnå en hög nivå av underhållbarhet i designen. För att det komponentbaserade gränssnittet skall uppfylla kraven på utbyggbarhet användes flera delkomponenter i designen. En grundkomponent användes från vilken gränssnittet har möjlighet att byggas ut med skräddarsydda delkomponenter som kommunicerar 15

med olika affärssystems API, på det viset uppnår gränssnittet en högre modularitet samtidigt som det blir lätt för slutanvändaren att välja vilka delkomponenter som skall användas. Med denna design behöver inte slutanvändaren arbeta med ett stöd för alla affärssystem, utan kan själv välja vilka delkomponenter för olika affärssystem som önskas arbeta mot. Med denna lösning uppfylls de två punkter som Sharma och Baliyan [15] föreslog som nya punkter, återanvändbarhet (reusability) och specialanpassningsbarhet (tailorability), under underhållbarhet för komponenter. Både återanvändbarheten och specialanpassningsbarheten ökade då denna lösning tillåter användaren att enkelt skräddarsy och återanvända olika delkomponenter i slutanvändarens system där det komponentbaserade gränssnittet skulle kunna användas. 4.1.1 Klasser i komponenten Här presenterar vi de klasser som vi identifierade och använde i designen. Först presenterars de klasser som ingick i designens grundkomponent och sedan går vi igenom de klasser som ingick i de delkomponenter som använder sig av API-funktioner mot affärssystemen. I grundkomponenten skapades följande klasser: BaseEntity Den här klassen är ett gränssnitt (interface) som deklarerar metodnamnen på den funktionalitet som behövs implementeras högre upp i designen. Metodnamnen är Add, Delete, Retrieve, Update och Find. Den här klassen ärvs av SpecificEntityklassen. SpecificEntity Det här är en abstrakt klass som ärver BaseEntity, men lägger till en funktion för att skapa en ren modell av sig själv som kan användas i ett system, t.ex. om man vill visa information om de olika objekten som ingår i ett system för användaren. Med en ren modell syftar vi på en klass som bara innehåller information om objektet i fråga, helt fritt från metoder och funktionalitet. Genom att kunna skapa en modell där endast ett få antal fält finns med, exempelvis för namn, id, pris m.m. så slipper användaren använda de rena objekten från affärssystemen för representation av dess data. Den här klassen är en abstraktion av sådana entiteter som finns i affärssystemen, exempelvis fakturor och kunder. Anledningen till att använda sig av den här klassen istället för att lägga in samma funktionalitet i BaseEntity-klassen beror på att de innehåller olika data, en kund och en faktura ser inte ut på samma sätt, och det gör att den funktionalitet som behövs implementeras för att skapa en simpel modell av sig själv ser olika ut. Models Detta är objekt som representerar entiteter som existerar i affärssystem som slutanvändaren skall kunna arbeta med internt, dessa modeller innehåller ingen funktionalitet utan representerar bara information om olika entiteter i systemet. Dessa klasser är fristående och varken ärver eller ärvs av andra klasser i systemet. IConnectionManager Det här är ett interface som deklarerar metodnamnen för generella databasåtgärder, t ex att hämta ut listor med information som inte är knuten till någon specifik entitet i affärssystemet. 16

I delkomponenterna skapades följande klasser: APIentity Det här är den konkreta implementationen av BaseEntity och SpecificEntity som arbetar direkt mot affärssystemets API. ConnectionManager Den här klassen ärver IConnectionManager och det är här dess funktionalitet implementeras. Det är i dessa delkomponenter som den faktiska funktionaliteten implementeras, det är först här som komponenten börjar prata med de olika affärssystemens API. På det sättet har man den kod som behövs för att prata med affärssystemen på ett ställe, klart separerat från andra komponenter. För att visualisera designen, och samtidigt få underlag för att kunna mäta dess modularitet, så skapades UML-diagram som beskrev designen. Det konstruerades komponentoch klassdiagram, tillsammans med use case-diagram. Genom att skapa designbeskrivande UML-diagram så skapades en bättre överblick av hela designen. Den mest kritiska delen som kommer att stöta på ändring i denna komponent är den delen som kommer att kommunicera direkt mot affärssystemens API då det skall vara möjligt att använda denna lösning mot flera olika affärssystem samt att de kommer ändras. I designen är det tänkt att den funktionaliteten skall ligga i delkomponenterna, det gör att utvecklare kan skapa nya delkomponenter för varje system de arbetar mot. Genom att dela upp delkomponenten i två klasser, APIentity och ConnectionManager, så höjs sammanhanget (coupling) i delkomponenten. Funktionaliteten delas upp på ett sätt som låter utvecklarna separera på entiteter och generella metoder. Figur 2: Klassdiagram för designen 17

4.1.2 Analys av designen Ser man till de förslag på underpunkter för underhållbarhet som Sharma och Balian föreslår i sin kvalitetsmodell, så ser man att designen uppfyller flera av de krav som de definerar i kvalitetsmodellen. Vår design uppfyller punkten återanvändbarhet då varje delkomponent som man utvecklar för systemet går att återanvända i alla projekt och system som använder sig av grundkomponenten. Underpunkterna installationsbarhet och anpassningsbarhet är inte lika lätta att uppfylla i designen. Installationsbarhet är en punkt som ligger utanför designen, den blir lättare att uppfylla när det finns en implementation som faktiskt går att installera någonstans. Anpassningsbarhet ligger inte heller helt under designen, vårt förslag är att implementera designen i programmeringsspråket C#, vilket är utvecklat av Microsoft och ingår i deras utvecklingsramverk.net. Genom att använda programmeringsspråket C# så görs komponenterna tillgängliga för utvecklare som utvecklar för.net-ramverket, det betyder att komponenten går att använda i alla projekt utvecklade i språk som ingår i.net-familjen. Utbytbarhet är en punkt som designen försöker uppfylla, följs de regler som finns i grundkomponentens gränssnitt och abstrakta klasser så går det att byta ut en tidigare delkomponent version med en ny version av samma komponent. Det viktiga är att följa de givna regler som finns vad gäller namn på metoder, variabler och så vidare. Designen gör det möjligt för användaren att skapa egna och använda flera APIentity och delkomponenter. På så sätt uppfyller designen kravet på punkten specialanpassningsbareht. Komponenten är utformad på ett sådant sätt att den skall vara enkel att bygga ut och förbättra. Det går även att lägga in mer funktionalitet som en eventuell slutanvändare skulle önska. Med hjälp av designen och de diagram som beskriver den går det att se hur den går att bygga ut, samt var den önskade funktionaliteten ska implementeras. Ändringsbarhet är inte lika enkel att uppfylla, då det är tänkt att komponenten skall göra en sak, nämligen att agera mellanhand mellan en utvecklare och ett affärssystems API. Man skall inte kunna modifiera så mycket i komponenten i sig, men det skall finnas stöd för de funktioner som man önskar använda ut mot affärsystemen. Den funktionaliteten i sig kan variera från slutanvändare till slutanvändare, och det finns full möjlighet att implementera just den funktionalitet som man själv önskar använda i sitt system. Utbyggbarhet är något som har varit viktigt att nå i designen, och genom att titta på designen så går det att se att den är väldigt utbyggbar. Att kunna utveckla, uppdatera och använda delkomponenter som är utformade att arbeta ut mot flera olika affärssystem har varit en viktig punkt under hela arbetet. Skalbarhet och spårningsbarhet är punkter som ligger på systemnivå, de är alltså inte något som har haft fokus i designen. Skulle designen gällt ett komplett system så hade dessa puntker varit högt prioriterade, detta då dessa punkter är viktiga för säkra prestandan och driftsäkerheten i ett system. Punkten förståelighet är en punkt som är svår att säga något om i designen, det mycket då det inte finns någon implementation som går att testa mot ett API. Det som finns att tillgå är UML-diagram och dokumentation i form av det här arbetet. Det är viktigt att vid eventuella framtida implementationer dokumentera implementationen väl för att underlätta användandet av den eventuella komponenten i framtida system. Modularitet är något som designen försöker uppfylla på ett bra sätt, den här punktet 18

faller lite in under Specialanpassningsbarhet, då designen tillåter utvecklare att utveckla och modifiera komponenter, samtidigt som det är fritt för användaren av komponenten att skräddarsy sitt system med de delkomponenter som anses vara de som behövs. Det man kan säga om testbarhet i designen är att det inte har haft hög prioritet, det är också en punkt som är svår att uppfylla så här tidigt i designens liv. I takt med att delkomponenter utvecklas så blir det viktigare att uppfylla punkten testbarhet, det då det är viktigt för användaren av en delkomponent att kunna testa och se att det fungerar på ett önskat sätt i deras system. Ser man till komponentens konsistens (consistency) så är det något som mer eller mindre kommer av sig själv. Det har utformats en komponent som går att använda i större system och komponenten bara är tänkt att göra en sak, nämligen arbeta mot olika affärssystems API. 4.2 Utvärdering av design Deng och Mercados modell kan delas upp i två nivåer, systemnivå och komponentnivå [5]. Systemnivå syftar på ett komplett system, d.v.s. ett körbart system. Komponentnivå syftar endast på en enskild komponent, i eller utanför ett system. Eftersom denna lösning är en komponent som skall vara en del av ett system så valdes det att utvärdera lösningen som en komponent och inte ett system. En kvalitetsmodell har genererats som visar en fristående komponent med relationen mellan mätvärden, delkrav och kvalitetsattribut. Vikter är utdelade efter hur mycket vi anser att mätmetoderna påverkar delkraven. Kvalitetsmodellen i figur 3 nedan visar att mätmetoderna ger ett värde på de olika delkraven. För att öka läsbarheten av kvalitetsmodellen har relationerna mellan mätmetoder och delkraven blivit färgade. Delkraven i sin tur ger till slut ett värde på komponenten. 19

Figur 3: Deng och Mercados kvalitetsmodell skapad utifrån designen av det komponentbaserade gränssnittet. Resultatet av mätvärdena normaliseras till värden mellan noll där de normaliserade mätvärderna visas i kolumnerna till höger som N m. Uträkningar för normalisering och slutvärde presenteras i bilaga B. Tabell 8: Normaliserade mätvärden för komponenter Komopnenter CBCOM N CBCOM DCOMC N DCOMC NCPC N NCP C Delkomponent 1 0 4 1 2 0 Grundkomponent 1 0 2 0 4 1 Tabell 9: Normaliserade mätvärden för klasser Komponenter Klasser DCC N DCC CBC N CBC Delkomponent ConnectionManager 1.96 0.26 1 0.5 APIEntity 1.96 0.26 2 1 Grundkomponent IConnectionManager 2.56 0.39 1 0.5 SpecificEntity 5.32 1 2 1 BaseEntity 2.56 0.39 1 0.5 Models 0.8 0 0 0 20

Tabell 10: Underhållbarhet på komponentnivå Komponent Förståelighet Modularitet Testbarhet Underhållbarhet Delkomponent 0.66 0.6 0.6 0.62 Geundkomponent 0.5 0.81 0.61 0.64 Medel 0.58 0.7 0.61 0.63 Tabellen ovan visar resultaten av delkraven samt kvalitetsattributet maintainability (underhållbarhet) för delkomponenterna. Medelvärdet för dessa ger slutvärdet för det komponentbaserade gränssnittet vilket är 0,63. Detta värde säger inte så mycket i sig och det är svårt att jämföra då det inte finns något mätvärde på en liknande lösning. Deng och Mercado evaluerar ett system i fallstudien av deras arbete [5] vilket ger resultatet 0,6 på komponentnivå och 0.65 på systemnivå. Detta resultat är ett bra resultat enligt Deng och Mercado då systemet som evalueras är utformat av Sun 4 som ett programexempel i en programmeringsguide och förväntas ge ett bra resultat. Mätvärdet vi fick från evalueringen är på komponentnivå och då är 0,6 det närmaste värdet att relatera till vilket tyder på att 0,63 är ett högt värde. Ytterligare möjligheter för detta slutvärde kommer vi att reflektera över i diskussionsdelen. 4.3 Implementation Implementation av designen resulterade i ett körbart program som följde designen och visade att den resulterade i en fungerande implementation. Utvecklingsverktyget Microsoft Visual Studio 2012 användes, och programspråket som användes för att utveckla implementationen var C#. Resultatet var en minimal implementation av designen, där alla klasser, arv och relationer som fanns med i designen implementerades som tomma klasser. Ingen funktionalitet förutom metoder för att skapa en modell-klass från en API-klass implementerades. Anledningen till att den funktionaliteten implementerades berodde på att den dels låg utanför ett API, det var alltså något som gick att implementera utan att ha tillgång till ett API, dels för att visa att det var möjligt att realisera vår design rent praktiskt. Det skapades två komponenter, en grundkomponent och en delkomponent, som DLLfiler eller klassbibliotek. Dessa klassbibliotek kunde sedan användas i en applikation för att komma åt och använda dess komponenter, och dessa komponenters minimala funktionalitet. Först skapades ett projekt i Visual Studio, ThesisComponent.Base, som skulle ha rollen som grundkomponent. I den skapades en AbstractEntity-klass med abstrakta metoder som skulle implementeras i en delkomponent. Vidare skapades en abstrakt klass för en tänkt artikel i en databas, AbstractAPIArticle. I den lades egenskaper (properties) för id, titel, artikelnummer och pris in. En referens till en basmodell, Article, lades till, tillsammans med metoder för att skapa en sådan basmodell samt uppdatera den från den abstrakta artikel-klassen. 4 http://www.oracle.com/us/sun/index.html 21

Ett gränssnitt (interface) skapades, IConnectionManager, i vilken ett metodnamn för att hämta en lista över artiklar lades in. Det var för att visa att det var i den här klassens barn som funktionalitet som låg utanför API-objekten skulle implementeras. Figur 4: Genererat klassdiagram över ThesisComponent.Base Vidare skapades ett nytt projekt, ThesisComponent.CustomOne, som skulle fungera som en delkomponent i vår design. En referens till grundkomponenten lades till så att de klasser som fanns i den gick att nå från delkomponenten. En artikel-klass skapades, API- Article, vilken hade ett arv från klassen AbstractAPIArticle i grundkomponenten. Själva metoderna lades till i APIArticle, men ingen funktionalitet implementerades i dessa. En implementation av IConnectionManager skapades, ConnectionManager. I den implementerades den funktionalitet som låg i IConnectionManager som tomma metoder. 22

Figur 5: Genererat klassdiagram över ThesisComponent.CustomOne Sen skapades ett nytt projekt, ThesisTestApplication, som skulle använda sig av grundoch delkomponenten för att skapa ett objekt av APIArticle-klassen, sätta värden på den, skapa en grundmodell, Article, med dess värden och skriva ut dessa. Sedan skulle egenskaperna i objektet skapat från APIArticle-klassen ändras, referensen till dess grundmodell skulle uppdateras med ny information för att sedan skrivas ut. Figur 6: Implementationen vid körning, notera att det är samma objekt vid båda utskrifterna. På det sättet gick det att se att det dels gick att skapa grundmodeller av de implementerade klasserna som pratar med ett API, samt att man kunde ändra informationen i 23