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-29Examinator: Kristian Ekberg Handledare: Mia Persson
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 af-fä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 utveck-laren 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
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 anled-ningar, 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 Visma1och Microsoft Dynamics CRM2.
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 Tomahawk3, som i sitt standardutförande inte är mer än ett tomt skal. Det låter dock användare och utveck-lare 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/
2http://www.microsoft.com/en-us/dynamics/crm.aspx 3
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ök-ning 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 mo-tiveras 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 ar-betets 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 systemarki-tekturer. Detta för att skaffa en kunskapsgrund till att utforma och evaluera en kompo-nentbaserad systemarkitektur.
I den kvantitativa delen utformar vi ett komponentbaserat gränssnitt som vi skall utvär-dera 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
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 kompo-nentbaserat 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 kun-skap 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 un-derhå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.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 program-merarna 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 Informations-gömning (Information hiding) myntades [3], vilka båda två bidrog till ännu mer självstän-dig 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 kontrakt-bundna gränssnit och explicita kontextuella beronden. En mjukvarukomponent kan drift-sä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
• 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 funktio-nalitet 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 hi-ding) 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 komponenter-na för att tilhandahålla en tjänst. I komponentmodellen följer komponenterkomponenter-nas gränssnitt en standard. Gränssnittet beskrivs av ett IDL (Interface Definition Language) som över-sä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ör-minskade 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 kom-ponent 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.
3.3 Kvalitetsattribut i design och arkitektur
Ett system definieras med två typer av krav, funktionella och icke-funktionella [16], funk-tionella krav definerar vad ett system skall göra medan icke-funkfunk-tionella 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 enhan-ce 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 komponent-baserade 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
kombinerar dessa med nya kvalitetsattribut som är anpassade och formade för komponent-baserad utveckling. De kvalitetsattribut som ingår i de tidigare nämnda kvalitetsmodeller-na, 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 kom-ponenten att se logiska samband i komkom-ponenten 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 Baliy-an ö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].
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, Specialanpassnings-barhet (en sammanslagning av modifikationsSpecialanpassnings-barhet 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ändbar-het 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änd-barheten, 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änd-barhet, 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
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årn-ing menar Sharma och Baliyan att det bör spåras när ändrkompatibilitetsspårn-ingar 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 kompo-nenter 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 komponent-baserad utveckling innefattar då attributen testbarhet, förståelighet, specialanpassningsbar-het, modularitet, koncisspecialanpassningsbar-het, återanvändbarspecialanpassningsbar-het, spårningsbarhet och skalbarhet . Dessa attri-but ä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 Modularitet
Förståelighet Koncishet
Specialanpassningsbarhet Återanvändbarhet Spårningsbarhet 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 placehol-der. Clearly, consistency is very important in the context of component-based software development: Will a component ”fit” or not?”
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.
Tabell 2: Beskrivning av mätmetoder
Kategori Förklaring
Metric Name Mätmetodens namn.
Description Beskrivning av mätmetoden.
Level Mätmetodens nivå dvs. systemnivå eller komponentnivå. Category Vad som mäts t ex. storlek eller sammankoppling.
Indicator Direction Om mätvärdet är positivt eller negativt, dvs. om ett högt eller lågt värde är önskvärt.
Related Artifact(s) 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:
Tabell 3: Coupling betwee components (CBCOM) Metric Name Coupling between components (CBCOM)
Description The metric counts the components which are coupled with a component under consideration regardless of the service direc-tion.
Level Component level metric
Category Coupling
Indicator Direction Reverse indicator (low value means low component coupling). Related Artifact(s) 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
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
Tabell 6: Coupling between classes (CBC) Metric Name Coupling between classes (CBC)
Description The metric counts the classes which are coupled with a class under consideration.
Level Component level metric
Category Coupling
Indicator Direction Reverse indicator (low value means low classes coupling). Related Artifact(s) Component diagram, class diagram
Tabell 7: Degree of class coupling (DCC) Metric Name Degree of class coupling (DCC)
Description The metric calculates the degree of the coupling of a class ac-cording to different types of class coupling.
Level Component level metric
Category Size
Indicator Direction Reverse indicator (low value means low component coupling). Related Artifact(s) Component diagram
3.5.3 Kvalitetsmodell
För att visualisera relationer mellan mätvärden, delkrav och kvalitetsattribut används kva-litetsmodellen 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 kvalitet-sattribut. 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.
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. Kvalitet-sattributet (QA) består av flera delkrav (QC) samt att systemets kvallitetsattribut(SysQA) påverkas av komponenternas kvalitetsattribut (ComQA), dock är denna relation inte rik-tad 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ör-stå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.
dmin och dmax representerar det lägsta resultatet av mätmetoden respektive det högsta. X = d−dmin
dmax−dmin : d 6= dminV dmax
1 : d = dmax
0 : d = dmin
(1)
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 W0 representerar de positiva respektive negativa vikterna. Formeln normaliserar vikterna så att summan av alla vikter blir ett.
i X n=1 Wn+ j X n=1 Wn0 = 1 (2)
Formel Nr.1 När mätvärderna och vikterna har normaliserats kan första formeln an-vä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 m0 och W0 representerar negativa mätvärden och deras vikter. Notera att i och j är antalet positiva respektive negativa mätattribut och att m, m0, W och W0 bara kan anta positiva värden.
QC = i X n=1 mnWn− j X n=1 m0nWn0 + j X n=1 Wn0 (3)
Formel Nr.2 Den andra formeln sammanfattar kvalitetsattributet på komponenten. I denna formel representerar QCQA alla delkrav för komponenten.
QAcom = |QCQA| X n=1 QCQAWn (4) 3.6 Mätmetoder på implementationsnivå
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, deve-lopers 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.”
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. Co-lor 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 main-tainable. 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
va-riables, 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 an-vändes flera delkomponenter i designen. En grundkomponent anan-vändes från vilken gräns-snittet har möjlighet att byggas ut med skräddarsydda delkomponenter som kommunicerar
med olika affärssystems API, på det viset uppnår gränssnittet en högre modularitet samti-digt 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 specialanpassnings-barheten ö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 SpecificEntity-klassen.
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 slu-tanvändaren skall kunna arbeta med internt, dessa modeller innehåller ingen funk-tionalitet 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 gene-rella databasåtgärder, t ex att hämta ut listor med information som inte är knuten till någon specifik entitet i affärssystemet.
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 modu-laritet, så skapades UML-diagram som beskrev designen. Det konstruerades komponent-och 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.
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 uppfyl-la i designen. Instaluppfyl-lationsbarhet ä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 kom-ponenterna 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.
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åen-de komponent med relationen mellan mätvärfriståen-den, friståen-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 del-kraven. 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.
Figur 3: Deng och Mercados kvalitetsmodell skapad utifrån designen av det komponentba-serade 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 Nm. Uträkningar för normalisering och
slutvärde presenteras i bilaga B.
Tabell 8: Normaliserade mätvärden för komponenter
Komopnenter CBCOM NCBCOM DCOMC NDCOM C NCPC NN CP 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 NDCC CBC NCBC 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
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 kom-ponentbaserade 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 Sun4 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 vi-sade att den resulterade i en fungerande implementation. Utvecklingsverktyget Microsoft Visual Studio 2012 användes, och programspråket som användes för att utveckla imple-mentationen var C#.
Resultatet var en minimal implementation av designen, där alla klasser, arv och rela-tioner 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. Anled-ningen 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 DLL-filer 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 funktionali-tet.
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.
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 im-plementerades den funktionalitet som låg i IConnectionManager som tomma metoder.
Figur 5: Genererat klassdiagram över ThesisComponent.CustomOne
Sen skapades ett nytt projekt, ThesisTestApplication, som skulle använda sig av grund-och 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 egenska-perna 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 utskrif-terna.
På det sättet gick det att se att det dels gick att skapa grundmodeller av de imple-menterade klasserna som pratar med ett API, samt att man kunde ändra informationen i
API-objekten för att sedan uppdatera basmodellen med dess nya information utan att det blev något fel på vägen.
Figur 7: Genererad Code Metrics-värden från ThesisComponent.Base och ThesisCompo-nent.CustomOne
Tittar man på Code metrics-resultatet så ser man under rubrikerna Depht of Inheri-tance (Depth ...) så går det att se att de värdena stämmer överens med designen. Klassen APIArticle har värdet 3 då den ärver från både AbstractEntity och AbstractAPIArticle, det är alltså den tredje klassen i det arvsledet. Förutom att man ser att arvslängder stämmer överens så ser man att Maintainability index (Maintai...) har värden nära 100, vilket är bra då 100 är det högsta resultatet som kan ges. Att det är så bra värden beror på att implementationen är tom, den har inte mycket implementerad funktionalitet.
5
Diskussion och slutsats
I det här kapitlet följer en diskussion där vi besvarar frågeställningarna som ställdes och reflekterar över resultatet och dess analys. Efter det följer en utvärdering av de metoder som vi har använt oss av. Slutligen ger vi en kort sammanfattning över arbetet i sin helhet, tillsammans med en reflektion över eventuell vidare forskning i ämnet.
Här kommer vi att ge våra svar på de frågor som vi ställde i början av arbetet. Frågorna var följande:
• Hur utformar man ett komponentbaserat gränssnitt som uppfyller dessa krav på utökning och underhåll?
Genom att göra en studie inom komponentbaserad mjukvaruutveckling och studera de krav för utökning och underhåll som fanns i problemformuleringen och bejakat dessa i en noggrann designprocess så har ett designförslag tagits fram som teoretiskt sett uppfyller dessa krav. Målet var att ta fram en design som skulle uppfylla dessa krav. Det går att använda den design som har tagits fram och implementera den som ett gränssnitt som går
att använda av utvecklare för att implementera funktionalitet ut mot många olika API-system. Genom den uppdelning av ansvar och de klasser som finns i designen har kraven på underhåll och utökning uppnåtts.
• Hur utvärderar man de kvalitetsattribut som är viktiga för designen?
Deng och Mercado har skapat ett test som mäter underhållbarhet i komponenter, det har vi använt för att nå ett resultat som går att använda i framtida arbete med den design som vi har tagit fram. Det är svårt att utvärdera kvalitetsattribut, det finns inte mycket att jämföra med och det närmaste värde att jämföra med gäller för en annan lösning. Det resultat som har uppnåtts säger inte så mycket om designen men antyder på hög underhållbarhet. Däremot går det att använda som en referenssiffra för framtida implementation av funktionalitet i designen. Det går också att använda som referensresultat vid jämförelser av delkomponenter.
5.1 Diskussion
5.1.1 Design
Genom att ha fokuserat mycket på de attribut som Sharma och Balian föreslog under vår designfas så anser vi att vi har uppnått en design som uppfyller både kravet på utökning men även det krav som ställdes på underhåll. Möjligheten att utöka vår baskomponent med många olika delkomponenter löser kravet på utökning, samtidigt som det även under-lättar underhållet och användingen av komponenten i ett senare skede då det är upp till användaren av komponenten att välja vilka delkomponenter som denne vill använda på ett enkelt sätt. Det är uppdelat på ett sådant sätt att varje API som användaren vill arbeta mot består av en egen delkomponent, denne behöver alltså inte använda en komponent som består av onödig funktionalitet, utan kan själv välja exakt de delkomponenter som behövs för uppgiften i fråga.
Genom den här lösningen så ger man användaren bättre möjlighet att skräddarsy sina lösningar där den design vi har kommit fram till kan användas. Det är även möjligt att dela delkomponenter mellan varandra, fungerar de på ett system så fungerar de även på ett annat. Det är inte heller någon skillnad mellan att använda delkomponenter för olika API-system, då alla metoder och egenskaper i dessa ser identiska ut för användaren av dessa, det är endast hur de fungerar mot API-systemet som skiljer sig åt, och det är något som är transparant för användaren.
Det gör det även enkelt för användaren att byta ut en delkomponent som arbetar mot en gammal version av ett API mot en ny delkomponent som arbetar mot en nyare API-version. Rent programmeringsmässigt så ser användaren ingen skillnad i hur komponenten fungerar. Man kan alltså väldigt enkelt uppgradera ett system som används med en ny delkomponent när t.ex. en ny API-version börjar använads utan att den påverkar resten av systemet eller på något sätt ser annorlunda ut än innan. Det skall inte krävas mer än att man byter ut en gammal delkomponent mot en ny för att uppgradera denne.
Man skulle även kunna anpassa designen till många andra olika problem och domäner, speciellt med tanke på att den är så “tom” i sitt utförande. Det går att anpassa delkompo-nenterna i designen till att arbeta mot egentligen vad som helst, och det finns inget tvång
att de tvunget ska arbeta mot ett API, de kan utföra all funktionalitet lokalt om så önskas. Det går alltså att applicera vår design på många olika problem, så länge man anpassar den till det problemområde där den skulle användas. Planerar man, och dokumenterar, ändringarna så är designen väldigt mångsidig.
Så som designen ser ut nu så går den att använda för att lösa det problem som fanns, och som vi i vårt arbete tog avstamp i, nämligen det där företag ville arbeta ut mot många olika affärssystems API-system. Vi har med vår design tagit fram en mall som utvecklare kan använda sig utav i utvecklingen av de delkomponenter som behövs för att implementera den faktiska funktionaliteten som behövs för att det rent praktiskt skall vara gångbart att använda den design som vi har tagit fram.
5.1.2 Utvärdering
Genom att använda Deng och Mercados system för att utvärdera vår design så nådde vi värdet 0.63 för komponentens underhållbarhet, vilket inte betyder så mycket i sig. Vid en jämförelse går det att tyda på att resultatet innbär hög underhållbarhet. Notera att resultatet i jämförelsen är ett mätresultat av en design för ett annat problem och detta är en faktor som bör hållas i åtanke. För att skaffa en mer bestämd betydelse av resultatet är vårt förslag att man använder det här resultatet som en referens vid senare implementationer av delkomponenter och senare eventuella nya versioner av vår design. Så länge man använder den kvalitetsmodell som vi tog fram tillsammans med de beräkningar som man baserar på den så kan man använda vårt resultat som ett referensvärde för att se om och hur stor skillnad det är mellan olika implementationer av exempelvis delkomponenter. Om två olika användare implementerar de metoder som behövs för att använda samma API-system så kan man jämföra dessa två komponenter med varandra för att se vilken som har det bättre värdet för underhåll.
Det är svårt att relatera resultatet till något, då värdet inte säger så mycket. Eftersom maxvärdet av evalueringen är 1 så ligger 0.63 över medel vilket får det i sig att anses som ett relativt bra resultat. I fallstudien i Deng och Mercados arbete evaluerades ett system där resultatet uppnådde värdet 0.65 på systemnivå och 0.6 på komponentnivå, vilket enligt de båda författarna till testsystemet är ett bra resultat. Dock går det inte att avgöra vad som är gränsen för ett optimalt eller ett undermåligt resultat. Är det möjligt att uppnå fullständig undehållbarhet eller är det ett mål att eftersträva? Om flera mätresultat hade funnits skulle det vara lättare att uppskatta vad ett bra eller dåligt resultat är. På så vis har denna studie bidragit med ytterligare resultat att relatera till.
Resultatet som vi fick från utvärderingen säger inte heller något om designen i sig, hur bra den är lämpad för att lösa det problem som vi ville att den skulle lösa. Det är lätt att tänka sig att flera olika designer som är tänkta att lösa samma problem kan få liknande resultat, eller väldigt olika resultat, men det säger nödvändigtvis inte något om hur bra designen i sig löser problemet. Vad det däremot kan säga något om är hur bra underhållbarhet man har uppnått i designen, och god underhållbarhet är något som man bör sträva efter om man vill utveckla något som skall vara hållbart i längden.
5.1.3 Implementation
Tittar man på implementationen så ser man att vår design fungerar, då de genererade klassdiagramen från koden följer det klassdiagram som vi tog fram i designfasen av ar-betet. Det illustrerar även hur vi har tänkt att komponenten är tänkt att byggas upp programmeringsmässigt. De värden som genererades via Visual Studios Code Metrics sä-ger nödvändigtvis inte så mycket för sig själva just nu, men precis som med värdet från utvärderingen så går dessa bra att använda som referensresultat vid framtida implementa-tioner och uppgraderingar. Det viktiga är att de som väljer att utveckla delkomponenter anväder sig av funktionen och på något sätt dokumenterar resultatet så att de går att använda vid jämförelser mellan delkomponenter.
Ser man till valet av programmeringsspråk så går det att se att det är lätt att åter-använda komponenten och delkomponenten i valfritt språk som ingår i .Net-familjen. Det finns även stöd för Python i form av IronPython, vilket är en Python-implementation som körs i .Net-miljö.
Valet av språk vid implementation är i stort sett upp till utvecklaren av komponenten eller delkomponenterna, det skulle till och med vara möjligt att skapa en grundkomponent i många olika språk så att utvecklare lättare skall kunna anpassa och skapa delkomponenter till just deras egna system. Det skulle då vara möjligt att dela på delkomponenter skrivna för flera olika språk, och på så sät få större spridning och användning av komponenten.
Det kan även vara en fördel vid migrering av system från ett programmeringsspråk till ett annat. Om det då är en möjlighet att använda samma komponent som innan, på ett sätt som ser likadant ut, så minimerar det migreringstiden, och även tiden det skulle ta att utveckla en komponent på nytt, eller tiden det skulle ta att hitta ett passande alternativ. Det viktigaste med implementationen som vi gjorde var att den visade att designen faktiskt fungerade, det gick att se att de klassdiagram som skapades i Visual Studio stämde överens med vår design fullt ut. På ett sätt kan man säga att implementationen styrkte designen i den mån att designen gick att implementera så som det var tänkt. Även om det inte implementerades någon funktionalitet ut mot ett API så gick det att se att designen gick att omsätta till något användbart som stämde överens med tanken bakom det.
5.2 Metodutvärdering
Vi tror att valet av metod för det här arbetet var ett bra val. Genom att kombinera teori med mer praktisk tillämning så kunde man få ett bättre resultat. Designfas, en utvär-deringsfas samt en implementationsfas så kunde vi förstärka varje tidigare fas resultat. Designfasen styrktes av både utvärderingsfasen och implementationsfasen, de komplette-rade varandra och det gick att se att den design som vi hade kommit fram till både gick att utvärdera men även implementera.
Det som var till störst besvär var att det slutliga värdet vi nådde i utvärderingsfasen inte sa så mycket om vår design. Men det fungerar mycket bra att använda som referensresultat vid implementation av nya delkomponenter och vid nya versioner av komponenten i stort.
5.3 Slutsats
5.3.1 Sammanfattning av arbetet
Syftet med detta arbete var att skapa ett lösningsförslag till ett komponentbaserat gräns-snitt som har höga krav på underhåll och utökning, och sedan att sedan validera att de två kraven uppfylldes i lösningsförslaget. Den design som tagits fram genom detta arbete löste problemen med utöking och underhåll.
Med hjälp av Deng och Mercados mätmetoder för komponenter gjordes det en värdening av designen, och på så sätt har en validering av kraven på underhåll och ut-ökning kunnat göras på lösningsförslaget. Utvärderingsresultatet som uppnåddes går och bör användas som referensresultat vid utvärderingar i ett senare skede av komponentens utveckling.
Genom att göra en implementation av designen så visade vi att den fungerade att omsätta från teori till praktik. Det visade även hur vi hade tänkt att en implementation skulle kunna se ut.
5.3.2 Vidare forskning
Det skulle ha varit intressant att se en implementation av delkomponenter mot ett faktiskt API, något som vi inte hade tid eller kunskap nog för att kunna genomföra. Det skulle även vara intressant att kunna jämföra resultat mellan delkomponenter för två olika API-system mot varandra för att se var och hur de skiljer sig åt.
![Tabell 1: Sharma och Baliyans kvalitetsmodell [15]](https://thumb-eu.123doks.com/thumbv2/5dokorg/4068343.84631/17.892.280.624.756.843/tabell-sharma-och-baliyans-kvalitetsmodell.webp)
