Att utforma och utvärdera ett komponentbaserat programmeringsgränssnitt

Storlek: px
Starta visningen från sidan:

Download "Att utforma och utvärdera ett komponentbaserat programmeringsgränssnitt"

Transkript

1 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: Examinator: Kristian Ekberg Handledare: Mia Persson Andrabedömare: Kristian Ekberg

2

3 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.

4

5 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.

6

7 Innehåll 1 Inledning Bakgrund Problemdiskussion och formulering Metod och avgränsningar Metoddiskussion Avgränsningar Teknisk bakgrund Mjukvaruarkitektur och design Komponenter Komponentbaserad utveckling, bakgrundshistoria Vad är egentligen en komponent? Komponenters för- och nackdelar Kvalitetsattribut i design och arkitektur Att utforma en komponent Kvalitetsattribut i en komponent En komponents konsistens Mätmetoder för komponenter och moduler Deng och Mercados evalueringmetod Mätmetoder Kvalitetsmodell Formler Mätmetoder på implementationsnivå Resultat och analys Design Klasser i komponenten Analys av designen Utvärdering av design Implementation Diskussion och slutsats Diskussion Design Utvärdering Implementation Metodutvärdering Slutsats Sammanfattning av arbetet Vidare forskning

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

9 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

10 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

11 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

12 3.2 Komponenter 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å 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

13 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 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

14 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 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 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

15 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

16 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

17 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 Sharma och Baliyans arbete publicerades två månader efer att ISO 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 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

18 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 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 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

19 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

20 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 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

21 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] 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

22 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

23 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

24 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 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

25 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

26 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

27 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

28 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 Grundkomponent Tabell 9: Normaliserade mätvärden för klasser Komponenter Klasser DCC N DCC CBC N CBC Delkomponent ConnectionManager APIEntity Grundkomponent IConnectionManager SpecificEntity BaseEntity Models

29 Tabell 10: Underhållbarhet på komponentnivå Komponent Förståelighet Modularitet Testbarhet Underhållbarhet Delkomponent Geundkomponent Medel 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

30 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

31 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

Inkapsling (encapsulation)

Inkapsling (encapsulation) UML UML är en standard för att dokumentera och visualisera sina tankar och beslut under analys och design. Att lära sig allt om UML får inte plats i den här kursen, men vi kommer lära oss vissa delar.

Läs mer

Examensarbete Introduk)on - Slutsatser Anne Håkansson annehak@kth.se Studierektor Examensarbeten ICT-skolan, KTH

Examensarbete Introduk)on - Slutsatser Anne Håkansson annehak@kth.se Studierektor Examensarbeten ICT-skolan, KTH Examensarbete Introduk)on - Slutsatser Anne Håkansson annehak@kth.se Studierektor Examensarbeten ICT-skolan, KTH 2016 Anne Håkansson All rights reserved. Svårt Harmonisera -> Introduktion, delar: Fråga/

Läs mer

Ett hållbart boende A sustainable living. Mikael Hassel. Handledare/ Supervisor. Examiner. Katarina Lundeberg/Fredric Benesch

Ett hållbart boende A sustainable living. Mikael Hassel. Handledare/ Supervisor. Examiner. Katarina Lundeberg/Fredric Benesch Ett hållbart boende A sustainable living Mikael Hassel Handledare/ Supervisor Examinator/ Examiner atarina Lundeberg/redric Benesch Jes us Azpeitia Examensarbete inom arkitektur, grundnivå 15 hp Degree

Läs mer

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML Målet Mer OOP Mer om klasser Några exempel UML Modularitet Språkligt modulära enheter Få gränssnitt Små gränssnitt Tydliga gränssnitt Dold information Återanvändbarhet Variation i typer Variation i datastrukturer

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Aletta Nylén http://user.it.uu.se/~aletta Epost: aletta.nylen@it.uu.se Rum: 1216 Kursinfo Lärare: Aletta Nylén Jesper Wilhelmsson Litteratur: Object-Oriented Software Development

Läs mer

Ökat personligt engagemang En studie om coachande förhållningssätt

Ökat personligt engagemang En studie om coachande förhållningssätt Lärarutbildningen Fakulteten för lärande och samhälle Individ och samhälle Uppsats 7,5 högskolepoäng Ökat personligt engagemang En studie om coachande förhållningssätt Increased personal involvement A

Läs mer

QC i en organisation SAST 2008-09-16

QC i en organisation SAST 2008-09-16 QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har

Läs mer

Designmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.

Designmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers. Designmönster - EMW Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.se/~kentp arbetar på Inst. för Datavetenskap, Cth & Gu, 50% och Software

Läs mer

Tentamen ID1004 Objektorienterad programmering October 29, 2013

Tentamen ID1004 Objektorienterad programmering October 29, 2013 Tentamen för ID1004 Objektorienterad programmering (vilande kurs), 29 oktober 2013, 9-13 Denna tentamen examinerar 3.5 högskolepoäng av kursen. Inga hjälpmedel är tillåtna. Tentamen består av tre sektioner.

Läs mer

RUP är en omfattande process, ett processramverk. RUP bör införas stegvis. RUP måste anpassas. till organisationen till projektet

RUP är en omfattande process, ett processramverk. RUP bör införas stegvis. RUP måste anpassas. till organisationen till projektet RUP är en omfattande process, ett processramverk RUP bör införas stegvis RUP måste anpassas till organisationen till projektet Volvo Information Technology 1 Även RUP har sina brister... Dåligt stöd för

Läs mer

http://marvel.com/games/play/31/create_your_own_superhero http://www.heromachine.com/

http://marvel.com/games/play/31/create_your_own_superhero http://www.heromachine.com/ Name: Year 9 w. 4-7 The leading comic book publisher, Marvel Comics, is starting a new comic, which it hopes will become as popular as its classics Spiderman, Superman and The Incredible Hulk. Your job

Läs mer

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR Kontrollera vilka kurser du vill söka under utbytet. Fyll i Basis for nomination for exchange studies i samråd med din lärare. För att läraren ska kunna göra en korrekt

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Emil Ahlqvist (c10eat@cs.umu.se) Didrik Püschel (dv11dpl@cs.umu.se) Johan Hammarström (c08jhm@cs.umu.se) Hannes Frimmel Moström (c10hml@cs.umu.se) 1 1. Introduktion 1.1 Objektorienterad

Läs mer

Kursplan. AB1029 Introduktion till Professionell kommunikation - mer än bara samtal. 7,5 högskolepoäng, Grundnivå 1

Kursplan. AB1029 Introduktion till Professionell kommunikation - mer än bara samtal. 7,5 högskolepoäng, Grundnivå 1 Kursplan AB1029 Introduktion till Professionell kommunikation - mer än bara samtal 7,5 högskolepoäng, Grundnivå 1 Introduction to Professional Communication - more than just conversation 7.5 Higher Education

Läs mer

Abstrakta Klasser 2. Kodning är bara en liten del i programvaruutvecklingen 6% 1% 6% Abstrakta Klasser - deklaration. Programutveckling sker i faser

Abstrakta Klasser 2. Kodning är bara en liten del i programvaruutvecklingen 6% 1% 6% Abstrakta Klasser - deklaration. Programutveckling sker i faser Abstrakta Klasser 1 God klassdesign placerar gemensamma attribut och metoder så högt som möjligt i hierarkin men ibland kan dessa egenskaper inte definieras fullständigt Abstrakta klasser innehåller ofta

Läs mer

Separation of Concern. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017

Separation of Concern. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017 Separation of Concern Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Johannes Åman Pohjola, 2017 Modulär design Ett programsystem är för stort för att kunna förstås i sin helhet.

Läs mer

Creo Customization. Lars Björs 2014-10-16

Creo Customization. Lars Björs 2014-10-16 Creo Customization Lars Björs 2014-10-16 Norra Europas största partner och återförsäljare av PTC relaterad programvara (Windchill, Creo, Arbortext, MathCad, Relex) 70 anställda Egen utvecklingsavdelning

Läs mer

Beijer Electronics AB 2000, MA00336A, 2000-12

Beijer Electronics AB 2000, MA00336A, 2000-12 Demonstration driver English Svenska Beijer Electronics AB 2000, MA00336A, 2000-12 Beijer Electronics AB reserves the right to change information in this manual without prior notice. All examples in this

Läs mer

Erfarenheter från Hazop användning på programvara i Arte740. Presentation för SESAM 2003-02-04 Claes Norelöv 4Real AB

Erfarenheter från Hazop användning på programvara i Arte740. Presentation för SESAM 2003-02-04 Claes Norelöv 4Real AB Erfarenheter från Hazop användning på programvara i Arte740 Presentation för SESAM 2003-02-04 Claes Norelöv 4Real AB 1 Innehåll 1. Bakgrund 2. Hazops plats i systemsäkerhetsarbetet 3. Vad-Hur gör man.

Läs mer

Isolda Purchase - EDI

Isolda Purchase - EDI Isolda Purchase - EDI Document v 1.0 1 Table of Contents Table of Contents... 2 1 Introduction... 3 1.1 What is EDI?... 4 1.2 Sending and receiving documents... 4 1.3 File format... 4 1.3.1 XML (language

Läs mer

Generics och polymorfism. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Generics och polymorfism. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Generics och polymorfism Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Live code Pair public class Pair { private A a; private B b; public A getfirst() { return a; public

Läs mer

LARS. Ett e-bokningssystem för skoldatorer.

LARS. Ett e-bokningssystem för skoldatorer. LARS Ett e-bokningssystem för skoldatorer. Därför behöver vi LARS Boka dator i förväg. Underlätta för studenter att hitta ledig dator. Rapportera datorer som är sönder. Samordna med schemaläggarnas system,

Läs mer

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Föreläsning 8. Designmönster

Föreläsning 8. Designmönster Föreläsning 8 Designmönster Designmönster När man designar program kan det vara viktigt att förstå hur man tidigare gått till väga när man konstruerat program. Kännedom om dessa tillvägagångssätt kan snabba

Läs mer

Inför projektuppgiften. Markus Buschle, markusb@ics.kth.se

Inför projektuppgiften. Markus Buschle, markusb@ics.kth.se Inför projektuppgiften Markus Buschle, markusb@ics.kth.se Agenda Möjligheter,ll samarbete Enterprise Architecture för beslutsfa8ande Modell Analys Resultat Projektuppgi? Möjligheter -ll samarbete Examensarbeten

Läs mer

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys?

Läs mer

Arv. Fundamental objekt-orienterad teknik. arv i Java modifieraren protected Lägga till och modifiera metoder med hjälp av arv Klass hierarkier

Arv. Fundamental objekt-orienterad teknik. arv i Java modifieraren protected Lägga till och modifiera metoder med hjälp av arv Klass hierarkier Arv Fundamental objekt-orienterad teknik arv i Java modifieraren protected Lägga till och modifiera metoder med hjälp av arv Klass hierarkier Programmeringsmetodik -Java 165 Grafisk respresentation: Arv

Läs mer

Enterprise App Store. Sammi Khayer. Igor Stevstedt. Konsultchef mobila lösningar. Teknisk Lead mobila lösningar

Enterprise App Store. Sammi Khayer. Igor Stevstedt. Konsultchef mobila lösningar. Teknisk Lead mobila lösningar Enterprise App Store KC TL Sammi Khayer Konsultchef mobila lösningar Familjen håller mig jordnära. Arbetar med ledarskap, mobila strategier och kreativitet. Fotbollen ger energi och fokus. Apple fanboy

Läs mer

Föreläsning 15: Repetition DVGA02

Föreläsning 15: Repetition DVGA02 Föreläsning 15: Repetition DVGA02 Vad handlar kursen om? Kursen kan i grova drag delas upp i tre delar: 1. Objekt-orienterad programmering 2. Grafiska användargränssnitt 3. Datastrukturer Dessutom genomsyras

Läs mer

Investeringsbedömning

Investeringsbedömning Investeringsbedömning 27/2 2013 Martin Abrahamson Doktorand UU Föreläsningen avhandlar Genomgång av Grundläggande begrepp och metoder NPV och jämförbara tekniker Payback Internränta/Internal Rate of Return

Läs mer

Kanban är inte din process. (låt mig berätta varför) #DevLin2012 15 Mars 2012

Kanban är inte din process. (låt mig berätta varför) #DevLin2012 15 Mars 2012 Kanban är inte din process (låt mig berätta varför) #DevLin2012 15 Mars 2012 Torbjörn Tobbe Gyllebring @drunkcod tobbe@cint.com Är du eller känner du en Kanban hipster? Förut körde vi X nu kör vi Kanban

Läs mer

Objektorienterad Programkonstruktion. Föreläsning 6 23 nov 2015

Objektorienterad Programkonstruktion. Föreläsning 6 23 nov 2015 Objektorienterad Programkonstruktion Föreläsning 6 23 nov 2015 Designmönster Färdiga "recept" för att lösa (del-)problem i struktureringen av ens program Mönster kan beskriva små komponenter eller stora

Läs mer

Mönster. Ulf Cederling Växjö University Ulf.Cederling@msi.vxu.se http://www.msi.vxu.se/~ulfce. Slide 1

Mönster. Ulf Cederling Växjö University Ulf.Cederling@msi.vxu.se http://www.msi.vxu.se/~ulfce. Slide 1 Mönster Ulf Cederling Växjö University UlfCederling@msivxuse http://wwwmsivxuse/~ulfce Slide 1 Beskrivningsmall Beskrivningsmallen är inspirerad av den som användes på AG Communication Systems (AGCS) Linda

Läs mer

Innehåll. dynamisk bindning. och programmering CRC) u Arv, polymorfi och

Innehåll. dynamisk bindning. och programmering CRC) u Arv, polymorfi och Innehåll u OOP snabbintroduktion u Datatyper u Uttryck u Satser u Arv (intro) u Programvaruutveckling och programmering u Klassdesign och metodik (UML, CRC) u Arv, polymorfi och dynamisk bindning u Fält

Läs mer

Objektsamlingar i Java

Objektsamlingar i Java 1 (6) Objektsamlingar i Java Objektorienterad programmering 3 Syfte Att ge träning i att använda objektsamlingar i Java. Mål Efter övningen skall du kunna använda objektsamlingsklasserna ArrayList och

Läs mer

Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program.

Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program. Föreläsning 2 Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program. Vår process Kravbeskrivning (3 dagar). Enkel form av användningsfall (use cases). Analys

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Objektorienterad analys och design 1 Dagens föreläsning Första delen, innan rasten: Motivation och bakgrund Analys Funktioner Andra delen, efter rasten: Objektorienterade

Läs mer

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design Alex Gerdes, 2016 Static vs Dynamic binding Polymorfism Objekt-orienterad programmering och design Alex Gerdes, 2016 Diagnostiskt prov Shape + overlaps(shape): int return 1; Shape shape = new Shape(); Polygon tripoly =

Läs mer

Från osäkerhet till säkerhet ISO 27004 för mätning

Från osäkerhet till säkerhet ISO 27004 för mätning Från osäkerhet till säkerhet ISO 27004 för mätning Lars Gunnerholm LGY Konsult AB Ordförande i AG3 Mätning lars.gunnerholm@telia.com 070 671 66 89 Lite om innehållet i presentationen, syftet är att ge

Läs mer

Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot. Självstyrda bilar. Datum: 2015-03-09

Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot. Självstyrda bilar. Datum: 2015-03-09 Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot Självstyrda bilar Datum: 2015-03-09 Abstract This report is about when you could buy a self-driving car and what they would look like. I also mention

Läs mer

1. Compute the following matrix: (2 p) 2. Compute the determinant of the following matrix: (2 p)

1. Compute the following matrix: (2 p) 2. Compute the determinant of the following matrix: (2 p) UMEÅ UNIVERSITY Department of Mathematics and Mathematical Statistics Pre-exam in mathematics Linear algebra 2012-02-07 1. Compute the following matrix: (2 p 3 1 2 3 2 2 7 ( 4 3 5 2 2. Compute the determinant

Läs mer

COPENHAGEN Environmentally Committed Accountants

COPENHAGEN Environmentally Committed Accountants THERE ARE SO MANY REASONS FOR WORKING WITH THE ENVIRONMENT! It s obviously important that all industries do what they can to contribute to environmental efforts. The MER project provides us with a unique

Läs mer

CMS, optimerade för programmerare Eller hur kan ett sådan skapas.

CMS, optimerade för programmerare Eller hur kan ett sådan skapas. Examensarbete CMS, optimerade för programmerare Eller hur kan ett sådan skapas. David Strömbom 2011-05-20 Ämne: Datavetenskap Nivå: B Kurskod: 1DV40E Abstrakt Denna rapport fokuserar på att undersöka några

Läs mer

Alias 1.0 Rollbaserad inloggning

Alias 1.0 Rollbaserad inloggning Alias 1.0 Rollbaserad inloggning Alias 1.0 Rollbaserad inloggning Magnus Bergqvist Tekniskt Säljstöd Magnus.Bergqvist@msb.se 072-502 09 56 Alias 1.0 Rollbaserad inloggning Funktionen Förutsättningar Funktionen

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

UML. Översikt UML. Relationer mellan klasser. A är ett aggregerat av B:n. Kontor aggregat av Enheter. 12 olika diagramtyper, bl.a.

UML. Översikt UML. Relationer mellan klasser. A är ett aggregerat av B:n. Kontor aggregat av Enheter. 12 olika diagramtyper, bl.a. Översikt UML Sekvensdiagram (dynamic structure) Informationsflöde genom programmet Användningsfall (use cases) Aktörers interaktion med systemet Paketdiagram Beroenden mellan paket abstrakta klasser Multipel

Läs mer

Kurskod: TAIU06 MATEMATISK STATISTIK Provkod: TENA 15 August 2016, 8:00-12:00. English Version

Kurskod: TAIU06 MATEMATISK STATISTIK Provkod: TENA 15 August 2016, 8:00-12:00. English Version Kurskod: TAIU06 MATEMATISK STATISTIK Provkod: TENA 15 August 2016, 8:00-12:00 Examiner: Xiangfeng Yang (Tel: 070 0896661). Please answer in ENGLISH if you can. a. Allowed to use: a calculator, Formelsamling

Läs mer

Schenker Privpak AB Telefon VAT Nr. SE Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr Säte: Borås

Schenker Privpak AB Telefon VAT Nr. SE Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr Säte: Borås Schenker Privpak AB Interface documentation for web service packageservices.asmx 2012-09-01 Version: 1.0.0 Doc. no.: I04304b Sida 2 av 7 Revision history Datum Version Sign. Kommentar 2012-09-01 1.0.0

Läs mer

Designmönster/Design patterns

Designmönster/Design patterns Johan Eliasson Design patterns Designmönster/Design patterns Vad är det? Beprövade lösningar till återkommande programmeringsproblem Plattformsoberoende Beskrivs ofta med hjälp av UML Baseras på en bok

Läs mer

Programmering B med Visual C++ 2008

Programmering B med Visual C++ 2008 Programmering B med Visual C++ 2008 Innehållsförteckning 1 Repetition och lite nytt...5 I detta kapitel... 5 Programexekvering... 5 Loop... 5 Källkod... 6 Verktyg... 6 Säkerhetskopiera... 6 Öppna, kompilera,

Läs mer

Mer om metoder och abstraktioner

Mer om metoder och abstraktioner Mer om metoder och abstraktioner Föreläsning 5 TDA540 - Objektorienterad Programmering Sammanfattning Abstraktion, top-down design Gränsnitt av en metod Parameteröverföring För- och eftervilkor (kompilera

Läs mer

Objektorienterad Programmering (OOP) Murach s: kap 12-16

Objektorienterad Programmering (OOP) Murach s: kap 12-16 Objektorienterad Programmering (OOP) Murach s: kap 12-16 2013-01-28 1 Winstrand Development Objektorienterad Programmering Förkortas OOP Objektorientering innebär att man delar in koden i olika block,

Läs mer

Understanding Innovation as an Approach to Increasing Customer Value in the Context of the Public Sector

Understanding Innovation as an Approach to Increasing Customer Value in the Context of the Public Sector Thesis for the degree of Licentiate of Philosophy, Östersund 2014 Understanding Innovation as an Approach to Increasing Customer Value in the Context of the Public Sector Klas Palm Supervisors: Håkan Wiklund

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 1 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/

Läs mer

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar Klassbegreppet och C++ OOP UML Klasser och objekt i C++ Uppdelning i filer Attribut och metoder Inkappsling - åtkomst Klassattribut - objektattribut Objekt-orienterad programmering Att använda ett objektorienterat

Läs mer

Rastercell. Digital Rastrering. AM & FM Raster. Rastercell. AM & FM Raster. Sasan Gooran (VT 2007) Rastrering. Rastercell. Konventionellt, AM

Rastercell. Digital Rastrering. AM & FM Raster. Rastercell. AM & FM Raster. Sasan Gooran (VT 2007) Rastrering. Rastercell. Konventionellt, AM Rastercell Digital Rastrering Hybridraster, Rastervinkel, Rotation av digitala bilder, AM/FM rastrering Sasan Gooran (VT 2007) Önskat mått * 2* rastertätheten = inläsningsupplösning originalets mått 2

Läs mer

PORTSECURITY IN SÖLVESBORG

PORTSECURITY IN SÖLVESBORG PORTSECURITY IN SÖLVESBORG Kontaktlista i skyddsfrågor / List of contacts in security matters Skyddschef/PFSO Tord Berg Phone: +46 456 422 44. Mobile: +46 705 82 32 11 Fax: +46 456 104 37. E-mail: tord.berg@sbgport.com

Läs mer

Testramverk och Model based testing med java i praktiken

Testramverk och Model based testing med java i praktiken WHITE PAPER MODEL BASED TESTING Testramverk och Model based testing med java i praktiken Prolore AB Page 1 (6) Web: www.prolore.se Målet med artikeln Den här artikeln syftar till att praktiskt visa hur

Läs mer

Cacheminne Intel Core i7

Cacheminne Intel Core i7 EDT621 Datorarkitekturer med operativsystem 7,5 hp 2015-12-07 Cacheminne i Intel Core i7 Författare: Adnan Karahmetovic Handledare: Erik Larsson Innehåll 1. Inledning... 1 1.1 Syfte... 1 1.2 Frågeställning...

Läs mer

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten?

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? Introduktion till objektorientering Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? jonas.kvarnstrom@liu.se 2014 2017 jonas.kvarnstrom@liu.se

Läs mer

Objektorienterad Programkonstruktion. Föreläsning 2 2 nov 2016

Objektorienterad Programkonstruktion. Föreläsning 2 2 nov 2016 Objektorienterad Programkonstruktion Föreläsning 2 2 nov 2016 Objekt - klass Namn Fält1 Fält2 Fält3 Metod1 Metod2 Metod3 Metod4 Objekt - klass Objekt - klass Objekt - klass + Objekt - klass public class

Läs mer

Isometries of the plane

Isometries of the plane Isometries of the plane Mikael Forsberg August 23, 2011 Abstract Här följer del av ett dokument om Tesselering som jag skrivit för en annan kurs. Denna del handlar om isometrier och innehåller bevis för

Läs mer

ISTQB Testarens ledstjärna

ISTQB Testarens ledstjärna ISTQB Testarens ledstjärna SSTB SAST-möte 2012-02-23 Vilka är vi? Mångårig erfarenhet från testarbete, testare, testledare, testchef. Utveckling av test metoder och processer. Test kurser. Jobbar som Systemarkitekt

Läs mer

Support for Artist Residencies

Support for Artist Residencies 1. Basic information 1.1. Name of the Artist-in-Residence centre 0/100 1.2. Name of the Residency Programme (if any) 0/100 1.3. Give a short description in English of the activities that the support is

Läs mer

725G61 - Laboration 7 Implementation av ett API. Johan Falkenjack

725G61 - Laboration 7 Implementation av ett API. Johan Falkenjack 725G61 - Laboration 7 Implementation av ett API Johan Falkenjack December 13, 2013 1 Inledning Hittills i kursen har vi tittat på grundläggande programmering och grundläggande objektorientering. I den

Läs mer

En skola på vetenskaplig grund gränsöverskridande mellan akademi, lärarutbildning och skolpraktik

En skola på vetenskaplig grund gränsöverskridande mellan akademi, lärarutbildning och skolpraktik En skola på vetenskaplig grund gränsöverskridande mellan akademi, lärarutbildning och skolpraktik Stephan Rapp Högskolan för lärande och kommunikation Gränsöverskridande 3. Skolpraktik 1. Lärarutbildning

Läs mer

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning ning på 3 föreläsningar Första föreläsningen Översikt PV7180 Verifiering och Validering Föreläsning 3 ning del 1 Andra föreläsningen Coverage ing, OO-ing, Utvärdering av tekniker Tredje föreläsningen Automatiserad

Läs mer

Objekt, klasser. Tillstånd Signatur Kommunikation Typ. Fält, parametrar och lokala variabler. Konstruktorer Metoder DAVA15

Objekt, klasser. Tillstånd Signatur Kommunikation Typ. Fält, parametrar och lokala variabler. Konstruktorer Metoder DAVA15 DAVA15 Objekt, klasser Vad är det? Vad är sambandet mellan dem? Vad är skillnaden mellan dem? Tillstånd Signatur Kommunikation Typ Fält, parametrar och lokala variabler Likheter och skillnader Räckvidd

Läs mer

Imperativ programmering. Föreläsning 4

Imperativ programmering. Föreläsning 4 Imperativ programmering 1DL126 3p Föreläsning 4 Imperativa paradigmer Ostrukturerad programmering Strukturerad programmering Procedurell programmering Objektorienterad programmering Klassbaserad programmering

Läs mer

Objektorienterade programmeringsspråk. Objektorienterade språk. Den objekt-orienterade modellen. Jämför med icke-oo

Objektorienterade programmeringsspråk. Objektorienterade språk. Den objekt-orienterade modellen. Jämför med icke-oo Objektorienterade språk Historik Simula 67 Smalltalk 80 Procedurorienterad programmering Subprogram Programbibliotek Dataorienterad programmering Abstrakta datatyper Objektbaserade språk, föregångare till

Läs mer

Session: Historieundervisning i högskolan

Session: Historieundervisning i högskolan Session: Historieundervisning i högskolan Ansvarig: David Ludvigsson, Uppsala universitet Kommentator: Henrik Ågren, Högskolan i Gävle Övriga medverkande: Lena Berggren, Umeå universitet Peter Ericsson,

Läs mer

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU TDDC30 Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Designmönster Adapter, Factory, Iterator,

Läs mer

Custom-made software solutions for increased transport quality and creation of cargo specific lashing protocols.

Custom-made software solutions for increased transport quality and creation of cargo specific lashing protocols. Custom-made software solutions for increased transport quality and creation of cargo specific lashing protocols. ExcelLoad simulates the maximum forces that may appear during a transport no matter if the

Läs mer

Styrteknik 7.5 hp distans: E-1000 och E-Designer

Styrteknik 7.5 hp distans: E-1000 och E-Designer PLC8A:1 E1000 operatörsterminaler En operatörsterminal ger ett gränssnitt mellan männinska-maskin, (MMI människa-maskininteraktion, HMI Human Machine Interface) Alla terminalerna i E1000-serien är utvecklade

Läs mer

Självkörande bilar. Alvin Karlsson TE14A 9/3-2015

Självkörande bilar. Alvin Karlsson TE14A 9/3-2015 Självkörande bilar Alvin Karlsson TE14A 9/3-2015 Abstract This report is about driverless cars and if they would make the traffic safer in the future. Google is currently working on their driverless car

Läs mer

Final Course Marks will be combined from the examination and the project:

Final Course Marks will be combined from the examination and the project: Examination CD5360 Software Engineering Course, 10P (Examination 4 Points) Datum: 2001-06-12, 8:30-13:30 Responsible: Ivica Crnkovic Max points: 40 Approved: Minimum 20 points Final Course Marks will be

Läs mer

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14 Design Vad är design? Vad är arkitektur? Architectural Pa:erns Designprinciper Design Pa:erns UML Domain Driven Design Domänmodell Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering

Läs mer

Mathematical Cryptology (6hp)

Mathematical Cryptology (6hp) Time to sign up for the continuation course Mathematical Cryptology (6hp) 12 lectures (2 hours) + 2 small projects Exercises are done on your own and discussed in class (6*2 hours). Contents: Elliptic

Läs mer

Samlingar, Gränssitt och Programkonstruktion! Förelasning 11!! TDA540 Objektorienterad Programmering!

Samlingar, Gränssitt och Programkonstruktion! Förelasning 11!! TDA540 Objektorienterad Programmering! Samlingar, Gränssitt och Programkonstruktion! Förelasning 11!! TDA540 Objektorienterad Programmering! Samlingar Vi kommer att behöva hantera samlingar av objekt - Har oftast använd Array (fält) - Bra om

Läs mer

Observationshotellet. The observation hotel. Fanny Vallo !!! Ersätt bilden med en egen bild. Emma Karlsson Martin Hedenström Ljung.

Observationshotellet. The observation hotel. Fanny Vallo !!! Ersätt bilden med en egen bild. Emma Karlsson Martin Hedenström Ljung. Observationshotellet The observation hotel Fanny Vallo Handledare/ Supervisor B Bojan Boric Emma Karlsson Martin Hedenström Ljung Examinator/ Examiner Erik Wingquist Examensarbete inom arkitektur, grundnivå

Läs mer

Användarhandbok. MHL to HDMI Adapter IM750

Användarhandbok. MHL to HDMI Adapter IM750 Användarhandbok MHL to HDMI Adapter IM750 Innehåll Inledning...3 MHL to HDMI Adapter-översikt...3 Komma igång...4 Smart Connect...4 Uppgradera Smart Connect...4 Använda MHL to HDMI Adapter...5 Ansluta

Läs mer

Kursplan. JP1040 Japanska III: Språkfärdighet. 15 högskolepoäng, Grundnivå 1. Japanese III: Language Proficiency

Kursplan. JP1040 Japanska III: Språkfärdighet. 15 högskolepoäng, Grundnivå 1. Japanese III: Language Proficiency Kursplan JP1040 Japanska III: Språkfärdighet 15 högskolepoäng, Grundnivå 1 Japanese III: Language Proficiency 15 Higher Education Credits *), First Cycle Level 1 Mål Efter avslutad kurs ska de studerande

Läs mer

Regressionstestning teori och praktik

Regressionstestning teori och praktik Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification

Läs mer

Objekt-orienterad Programmering och Design. TDA551 Alex Gerdes, HT-2016

Objekt-orienterad Programmering och Design. TDA551 Alex Gerdes, HT-2016 Objekt-orienterad Programmering och Design TDA551 Alex Gerdes, HT-2016 Kursteamet Dr. Alex Gerdes kursansvarig, föreläsare Dr. Niklas Broberg examinator, (föreläsare) Fredrik Sjöholm handledare Johan Andersson

Läs mer

RUP - Rational Unified Process

RUP - Rational Unified Process IBM Software Group RUP - Rational Unified Process Eva Hådding eva.hadding@se.ibm.com 1 Projektkaos. Chaos-rapporten 28% av projekten avslutades i tid och enligt budget. 49% av projekten drog över de ursprungliga

Läs mer

Styrteknik: Binära tal, talsystem och koder D3:1

Styrteknik: Binära tal, talsystem och koder D3:1 Styrteknik: Binära tal, talsystem och koder D3:1 Digitala kursmoment D1 Boolesk algebra D2 Grundläggande logiska funktioner D3 Binära tal, talsystem och koder Styrteknik :Binära tal, talsystem och koder

Läs mer

UML use cases. Mikael Söderström Institutionen för informatik Umeå universitet micke@informatik.umu.se

UML use cases. Mikael Söderström Institutionen för informatik Umeå universitet micke@informatik.umu.se UML use cases micke@informatik.umu.se Use case (användningsfall) En modelleringsteknik som hjälper utvecklare att bestämma vilka funktioner som ska implementeras i ett system/applikation Finns olika typer

Läs mer

Kundfokus Kunden och kundens behov är centrala i alla våra projekt

Kundfokus Kunden och kundens behov är centrala i alla våra projekt D-Miljö AB bidrar till en renare miljö genom projekt där vi hjälper våra kunder att undersöka och sanera förorenad mark och förorenat grundvatten. Vi bistår dig som kund från projektets start till dess

Läs mer

Sammanfattning hydraulik

Sammanfattning hydraulik Sammanfattning hydraulik Bernoullis ekvation Rörelsemängdsekvationen Energiekvation applikationer Rörströmning Friktionskoefficient, Moody s diagram Pumpsystem BERNOULLI S EQUATION 2 p V z H const. Quantity

Läs mer

Informationssystem och databasteknik, 2I-1100

Informationssystem och databasteknik, 2I-1100 Informationssystem och databasteknik, 2I-1100 Introduktion till informationssystem - användning, teknik och utveckling Vad är ett informationssystem? Informationssystem: datoriserat system som stödjer

Läs mer

Page 1. Aktuella utmaningar för ekonomistyrare. Tema: Aktuella utmaningar för ekonomistyrare. Vad är ekonomistyrning? Vilka är utmaningarna?

Page 1. Aktuella utmaningar för ekonomistyrare. Tema: Aktuella utmaningar för ekonomistyrare. Vad är ekonomistyrning? Vilka är utmaningarna? Aktuella utmaningar för ekonomistyrare Professor Fredrik Nilsson Uppsala 2010-02-12 Föreläsningens inriktning Tema: Aktuella utmaningar för ekonomistyrare Vad är ekonomistyrning? Vilka är utmaningarna?

Läs mer

DVG C01 TENTAMEN I PROGRAMSPRÅK PROGRAMMING LANGUAGES EXAMINATION :15-13: 15

DVG C01 TENTAMEN I PROGRAMSPRÅK PROGRAMMING LANGUAGES EXAMINATION :15-13: 15 DVG C01 TENTAMEN I PROGRAMSPRÅK PROGRAMMING LANGUAGES EXAMINATION 120607 08:15-13: 15 Ansvarig Lärare: Donald F. Ross Hjälpmedel: Bilaga A: BNF-definition En ordbok: studentenshemspråk engelska Betygsgräns:

Läs mer

Att utveckla och skapa en effektiv och dynamisk process för konsolidering och rapportering

Att utveckla och skapa en effektiv och dynamisk process för konsolidering och rapportering Ulla-Britt Fagerström - Senior lösningsspecialist, IBM Business Analytics 22 maj 2013 Att utveckla och skapa en effektiv och dynamisk process för konsolidering och rapportering Då kan drömmar gå i uppfyllelse

Läs mer

MUSIK OCH SPRÅK. !Musik!och!inkludering!!fält!för!musikterapeuter!och!forskning! !!!! !!!2016?04?09! !FMS!rikskonferens!!!Karlstad!universitet!

MUSIK OCH SPRÅK. !Musik!och!inkludering!!fält!för!musikterapeuter!och!forskning! !!!! !!!2016?04?09! !FMS!rikskonferens!!!Karlstad!universitet! FMSrikskonferens Karlstaduniversitet Liber MUSIK OCH SPRÅK Ett vidgat perspektiv på barns språkutveckling och lärande ULF JEDERLUND Musikochinkludering fältförmusikterapeuterochforskning 2016?04?09 UlfJederlund

Läs mer

Webservice & ERP-Integration Rapport

Webservice & ERP-Integration Rapport Webservice & ERP-Integration Rapport Hardwood AB Mustafa Lazem 930916-9713 Jonas Ahrne 920325-0379 Hasan Nerjovaj 940130-7195 Stefan Liden 920628-0639 2014-05-18 Innehåll Bakgrund... 2 Syfte... 2 Projektbeskrivning...

Läs mer

Domänspecifika språk. TDP007 Konstruktion av datorspråk Föreläsning 5. Peter Dalenius Institutionen för datavetenskap 2013-02-11

Domänspecifika språk. TDP007 Konstruktion av datorspråk Föreläsning 5. Peter Dalenius Institutionen för datavetenskap 2013-02-11 Domänspecifika språk TDP007 Konstruktion av datorspråk Föreläsning 5 Peter Dalenius Institutionen för datavetenskap 2013-02-11 Domänspecifika språk Ett domänspecifikt språk (eng. domain specific language,

Läs mer

Statistik över heltal

Statistik över heltal Övningsuppgift Statistik över heltal Steg 2 Författare: Mats Loock Kurs: Inledande programmering med C# Kurskod:1DV402 Upphovsrätt för detta verk Detta verk är framtaget i anslutning till kursen Inledande

Läs mer

Introduktion. Byggstenar TDBA63 2005-11-22

Introduktion. Byggstenar TDBA63 2005-11-22 Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet

Läs mer