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

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

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

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

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

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

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

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

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

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

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

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

UML. Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo.

UML. Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo. UML Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN-20520 Åbo, Finland e-mail: tczarnec@abo.fi url: www.abo.fi/~tczarnec Abstrakt The Unified Modeling Language, UML, är ett visuellt

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

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

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

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

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

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

PowerCell Sweden AB. Ren och effektiv energi överallt där den behövs

PowerCell Sweden AB. Ren och effektiv energi överallt där den behövs PowerCell Sweden AB Ren och effektiv energi överallt där den behövs Requirements of power electronics for fuel cells in electric vehicles Andreas Bodén (Rickard Nilsson) Förstudie: Kravställning på kraftelektronik

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

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

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

Exportmentorserbjudandet!

Exportmentorserbjudandet! Exportmentor - din personliga Mentor i utlandet Handelskamrarnas erbjudande till små och medelstora företag som vill utöka sin export Exportmentorserbjudandet! Du som företagare som redan har erfarenhet

Läs mer

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1 UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng Master Program in Educational Work 60 credits 1 Fastställd i Områdesnämnden 2015-XX-XX Gäller fr.o.m. HT 2015 1. PROGRAMMETS MÅL 1.1.

Läs mer

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon

Läs mer

Implementationsstrategier för PLCS

Implementationsstrategier för PLCS Implementationsstrategier för PLCS Dr Mattias Johansson Director Software Products Eurostep AB Typically complex systems environment Point to Point Integration Operational Objectives CM CM CM CM 5. Requirements

Läs mer

Hur man skyddar sig på internet

Hur man skyddar sig på internet Hur man skyddar sig på internet Säkerhet är obehagligt Men vi har ju virusskydd!! Webbläsare Webbläsare Vårt största hot idag Tydligare vid fel, phishing, flikar SSL Tunnlar och certifikat, brutna certifikat,

Läs mer

Förändrade förväntningar

Förändrade förväntningar Förändrade förväntningar Deloitte Ca 200 000 medarbetare 150 länder 700 kontor Omsättning cirka 31,3 Mdr USD Spetskompetens av världsklass och djup lokal expertis för att hjälpa klienter med de insikter

Läs mer

Boiler with heatpump / Värmepumpsberedare

Boiler with heatpump / Värmepumpsberedare Boiler with heatpump / Värmepumpsberedare QUICK START GUIDE / SNABBSTART GUIDE More information and instruction videos on our homepage www.indol.se Mer information och instruktionsvideos på vår hemsida

Läs mer

Testning som beslutsstöd

Testning som beslutsstöd Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten

Läs mer

Amir Rostami 2012-09-16 1

Amir Rostami 2012-09-16 1 Amir Rostami 2012-09-16 1 Översikt Begreppsförvirring Den svenska gängutvecklingen Stockholm Gang Intervention and Prevention Project Sveriges största polisiära EU projekt Alternativt brottsbekämpning

Läs mer

- den bredaste guiden om Mallorca på svenska! -

- den bredaste guiden om Mallorca på svenska! - - den bredaste guiden om Mallorca på svenska! - Driver du företag, har en affärsrörelse på Mallorca eller relaterad till Mallorca och vill nå ut till våra läsare? Då har du möjlighet att annonsera på Mallorcaguide.se

Läs mer

Unit testing methodology

Unit testing methodology Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är

Läs mer

Agenda. Plats och magkänsla. Presentation. - en pedagogisk fråga?

Agenda. Plats och magkänsla. Presentation. - en pedagogisk fråga? Plats och magkänsla - en pedagogisk fråga? Göran Lindahl Chalmers tekniska högskola 2011-09-28 Agenda Introduktion Helhet Användbarhet och effekter Cost and benefit Realitet, abstrakt, realitet Så här

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Authentication Context QC Statement. Stefan Santesson, 3xA Security AB stefan@aaa-sec.com

Authentication Context QC Statement. Stefan Santesson, 3xA Security AB stefan@aaa-sec.com Authentication Context QC Statement Stefan Santesson, 3xA Security AB stefan@aaa-sec.com The use case and problem User identities and user authentication is managed through SAML assertions. Some applications

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

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB Du fulländar mig! Om synergierna mellan agila metoder och UX Joakim Holm Adaptiv AB Erik Hammarström Antrop AB Vetenskapliga metoden 1. Observera verkligheten 4. Genomför experiment 2. Utforma hypotes

Läs mer

Här kan du checka in. Check in here with a good conscience

Här kan du checka in. Check in here with a good conscience Här kan du checka in med rent samvete Check in here with a good conscience MÅNGA FRÅGAR SIG hur man kan göra en miljöinsats. Det är egentligen väldigt enkelt. Du som har checkat in på det här hotellet

Läs mer

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman Design och krav Henrik Artman >>Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av

Läs mer

Evaluation Ny Nordisk Mat II Appendix 1. Questionnaire evaluation Ny Nordisk Mat II

Evaluation Ny Nordisk Mat II Appendix 1. Questionnaire evaluation Ny Nordisk Mat II Evaluation Ny Nordisk Mat II Appendix 1. Questionnaire evaluation Ny Nordisk Mat II English version A. About the Program in General We will now ask some questions about your relationship to the program

Läs mer

William J. Clinton Foundation Insamlingsstiftelse REDOGÖRELSE FÖR EFTERLEVNAD STATEMENT OF COMPLIANCE

William J. Clinton Foundation Insamlingsstiftelse REDOGÖRELSE FÖR EFTERLEVNAD STATEMENT OF COMPLIANCE N.B. The English text is an in-house translation. William J. Clinton Foundation Insamlingsstiftelse (organisationsnummer 802426-5756) (Registration Number 802426-5756) lämnar härmed följande hereby submits

Läs mer

PM 01 En jämförelse av två analysmodeller för val av komponentteknik

PM 01 En jämförelse av två analysmodeller för val av komponentteknik MÄLARDALENS HÖGSKOLA Institutionen för Ekonomi och Informatik v PM 01 En jämförelse av två analysmodeller för val av komponentteknik Eskilstuna, 2002-12-12 EI0230 Komponentbaserad applikationsutveckling

Läs mer

Chapter 4: Writing Classes/ Att skriva egna klasser.

Chapter 4: Writing Classes/ Att skriva egna klasser. Chapter 4: Writing Classes/ Att skriva egna klasser. I dessa uppgifter kommer du att lära dig om hur man definierar egna objekt genom att skriva klasser. Detta är grunden för att förstå objekt orienterad

Läs mer

VAD SKULLE DU HA VALT PDF

VAD SKULLE DU HA VALT PDF VAD SKULLE DU HA VALT PDF ==> Download: VAD SKULLE DU HA VALT PDF VAD SKULLE DU HA VALT PDF - Are you searching for Vad Skulle Du Ha Valt Books? Now, you will be happy that at this time Vad Skulle Du Ha

Läs mer

Systemutveckling. Historiskt grundad introduktion

Systemutveckling. Historiskt grundad introduktion Systemutveckling Historiskt grundad introduktion Kvalitet som tema Dataområdet kännetecknas av ständig förändring - utveckling - expansion Varje "nyhet" en förbättring Anta att förbättringarna är, eller

Läs mer

EXTERNAL ASSESSMENT SAMPLE TASKS SWEDISH BREAKTHROUGH LSPSWEB/0Y09

EXTERNAL ASSESSMENT SAMPLE TASKS SWEDISH BREAKTHROUGH LSPSWEB/0Y09 EXTENAL ASSESSENT SAPLE TASKS SWEDISH BEAKTHOUGH LSPSWEB/0Y09 Asset Languages External Assessment Sample Tasks Breakthrough Stage Listening and eading Swedish Contents Page Introduction 2 Listening Sample

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

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Nya möjligheter med M3 Technology. Björn Svensson, Björn Torold

Nya möjligheter med M3 Technology. Björn Svensson, Björn Torold Nya möjligheter med Technology Björn Svensson, Björn Torold Vem är vi? 2 Copyright 2011 Lawson. All rights reserved. Nya möjligheter med Technology System Foundation Grid Förändrar basen i Installation

Läs mer

Lars Lindmark 28 juni 2015. Designstuga. ett designlabb för hållbar utveckling. Beskrivning designstuga, sida 1

Lars Lindmark 28 juni 2015. Designstuga. ett designlabb för hållbar utveckling. Beskrivning designstuga, sida 1 Designstuga ett designlabb för hållbar utveckling Beskrivning designstuga, sida 1 Design Förmåga att lösa komplexa problem Designprocessen är en förmåga att samla och involvera aktörer för att tillsammans

Läs mer

Innehåll. Kravhantering. Kravhantering TDDD06 Introduktion till kravhantering. Vad är kravhantering?

Innehåll. Kravhantering. Kravhantering TDDD06 Introduktion till kravhantering. Vad är kravhantering? Innehåll Kravhantering TDDD06 Introduktion till kravhantering Institutionen för datavetenskap (IDA) Linköpings universitet Kravhantering Omfattning Grundläggande koncept Aktörer Aktiviteter Artefakter

Läs mer

JAG SKRIVER I BLINDO PDF

JAG SKRIVER I BLINDO PDF JAG SKRIVER I BLINDO PDF ==> Download: JAG SKRIVER I BLINDO PDF JAG SKRIVER I BLINDO PDF - Are you searching for Jag Skriver I Blindo Books? Now, you will be happy that at this time Jag Skriver I Blindo

Läs mer

TRENDERNA SOM FORMAR DIN VERKLIGHET 2014 ÅRETS IT AVDELNING 2014 2014-01-23

TRENDERNA SOM FORMAR DIN VERKLIGHET 2014 ÅRETS IT AVDELNING 2014 2014-01-23 TRENDERNA SOM FORMAR DIN VERKLIGHET 2014 ÅRETS IT AVDELNING 2014 2014-01-23 THE POWER OF INTEGRATION There will not exist hardware without services integrated, services without applications surrounding

Läs mer

Innovation in the health sector through public procurement and regulation

Innovation in the health sector through public procurement and regulation Innovation in the health sector through public procurement and regulation MONA TRUELSEN & ARVID LØKEN 1 14/11/2013 Copyright Nordic Innovation 2011. All rights reserved. Nordic Innovation An institution

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

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? Exempel Möjligheter,ll samarbete

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Författare Per Johansson, Henrik Wallinder Generellt Helhetsintrycket från genomläsning av uppsatsen

Läs mer

Kursplanering Objektorienterad programmering

Kursplanering Objektorienterad programmering Kursplanering Objektorienterad programmering Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-OOP Klass Systemutvecklare.NET 2 Syfte och koppling till yrkesrollen Syftet är att få en stabil grund

Läs mer

Schenker Privpak AB Telefon 033-178300 VAT Nr. SE556124398001 Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr 033-257475 Säte: Borås

Schenker Privpak AB Telefon 033-178300 VAT Nr. SE556124398001 Schenker ABs ansvarsbestämmelser, identiska med Box 905 Faxnr 033-257475 Säte: Borås Schenker Privpak AB Interface documentation for web service packageservices.asmx 2010-10-21 Version: 1.2.2 Doc. no.: I04304 Sida 2 av 14 Revision history Datum Version Sign. Kommentar 2010-02-18 1.0.0

Läs mer

Introduktion. Lagom är bäst. OO eller ej? TDP004 Objektorienterad Programmering Fö 7 Objektorienterad design, tips och råd

Introduktion. Lagom är bäst. OO eller ej? TDP004 Objektorienterad Programmering Fö 7 Objektorienterad design, tips och råd Introduktion TDP004 Objektorienterad Programmering Fö 7 Objektorienterad design, tips och råd Vi har diskuterat vilka möjligheter till OO som erbjuds i C++. Vilka vill vi använda och varför? Allt har användningsområden

Läs mer

Här kan du sova. Sleep here with a good conscience

Här kan du sova. Sleep here with a good conscience Här kan du sova med rent samvete Sleep here with a good conscience MÅNGA FRÅGAR SIG hur man kan göra en miljöinsats. Det är egentligen väldigt enkelt. Du som har checkat in på det här hotellet har gjort

Läs mer

IRAB Mottagare sida 2-5 Tele Radio AB Mottagare sida 6

IRAB Mottagare sida 2-5 Tele Radio AB Mottagare sida 6 IRAB Mottagare sida -5 Tele Radio AB Mottagare sida 6 Installation of receiver type smd 700 4 RELAY FUNCTIONS / -4 VAC/DC PCB TYPE NO: LWEG 4L Rev: 95-09 Installation: Install the receivers in a protected

Läs mer

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp

Läs mer

Meter to cash - og prosess effektivitet med toveiskommunikasjon.

Meter to cash - og prosess effektivitet med toveiskommunikasjon. Meter to cash - og prosess effektivitet med toveiskommunikasjon. EBL Toveiskommunikasjon i Norge 21.-22. mai 2008 Jesper Uhlin TietoEnator Corporation Energy/Utility Solution jesper.uhlin@tietoenator.com

Läs mer

We speak many languages

We speak many languages Våra medarbetare pratar över 40 språk. Många har själva gjort den resan du gör nu. We speak many languages Many of our employees come from other countries themselves and have followed the same path you

Läs mer

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan SGITD. IT-Designprogrammet. Study programme in IT-Design

Fakulteten för ekonomi, kommunikation och IT. Utbildningsplan SGITD. IT-Designprogrammet. Study programme in IT-Design Fakulteten för ekonomi, kommunikation och IT Utbildningsplan IT-Designprogrammet Programkod: Programmets benämning: Inriktningar: SGITD IT-Designprogrammet Study programme in IT-Design Affärssystem och

Läs mer

Föreläsning i webbdesign. Interak*onsdesign. Rune Körnefors. Medieteknik. 2012 Rune Körnefors rune.kornefors@lnu.se

Föreläsning i webbdesign. Interak*onsdesign. Rune Körnefors. Medieteknik. 2012 Rune Körnefors rune.kornefors@lnu.se Föreläsning i webbdesign Interak*onsdesign Rune Körnefors Medieteknik 1 2012 Rune Körnefors rune.kornefors@lnu.se Från föreläsning F1 Användarcentrerad design "Take the user into account every step of

Läs mer

Welcome. to the world of Jeeves. Copyright 2011 Jeeves Information Systems AB

Welcome. to the world of Jeeves. Copyright 2011 Jeeves Information Systems AB Welcome to the world of Jeeves Copyright 2011 Jeeves Information Systems AB Jeeves APPs & APPs Market Jeeves World 2011 Tomas Enblom, Chief Architect Innovation historiska ögonblick Ca 3500 f kr Ca 2000

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Till sökande för KRAV-certifiering av produkter från fiske. To applicants for KRAV certification of seafood products from capture fisheries

Till sökande för KRAV-certifiering av produkter från fiske. To applicants for KRAV certification of seafood products from capture fisheries Till sökande för KRAV-certifiering av produkter från fiske Välkommen med din ansökan om KRAV-godkännande av fiskbestånd. Ansökan skickas per mail till fiske@krav.se eller per post till KRAV Box 1037 751

Läs mer

PRODUCT MANAGEMENT. Klicka här för att ändra format. Klicka här för att ändra format på underrubrik i bakgrunden

PRODUCT MANAGEMENT. Klicka här för att ändra format. Klicka här för att ändra format på underrubrik i bakgrunden på From Requirements in Excel - to development of profitable products Strategic Technology PRODUCT PRODUCT Market PLANNING MARKETING på Operational Product planning = Define and Develop Product marketing

Läs mer

Kurskod D0010E Datum 2012-05-15 Skrivtid 5tim

Kurskod D0010E Datum 2012-05-15 Skrivtid 5tim LULEÅ TEKNISKA UNIVERSITET Tentamen i Objektorienterad programmering och design Totala antalet uppgifter: 5 Lärare: Håkan Jonsson, 491000, 073-820 1700 Resultatet o entliggörs senast: 2012-05-29. Tillåtna

Läs mer

Protokoll Föreningsutskottet 2013-10-22

Protokoll Föreningsutskottet 2013-10-22 Protokoll Föreningsutskottet 2013-10-22 Närvarande: Oliver Stenbom, Andreas Estmark, Henrik Almén, Ellinor Ugland, Oliver Jonstoij Berg. 1. Mötets öppnande. Ordförande Oliver Stenbom öppnade mötet. 2.

Läs mer

PDP som redskap för karriärutveckling i utbildning. Ola Tostrup

PDP som redskap för karriärutveckling i utbildning. Ola Tostrup PDP som redskap för karriärutveckling i utbildning Ola Tostrup - 16, 4, 47, 3 Dagens föreställning Vad innebär PDP och varför PDP Hur vi designat det inom utbildningen Kompetensbegreppet och vilka kompetenser

Läs mer

Collaborative Product Development:

Collaborative Product Development: Collaborative Product Development: a Purchasing Strategy for Small Industrialized House-building Companies Opponent: Erik Sandberg, LiU Institutionen för ekonomisk och industriell utveckling Vad är egentligen

Läs mer

Tomas Stålnacke Huvudprojektledare Project Manager Stadsomvandlingen City in transformation Kirunabostäder AB tomas.stalnacke@kirunabostader.

Tomas Stålnacke Huvudprojektledare Project Manager Stadsomvandlingen City in transformation Kirunabostäder AB tomas.stalnacke@kirunabostader. Tomas Stålnacke Huvudprojektledare Project Manager Stadsomvandlingen City in transformation Kirunabostäder AB tomas.stalnacke@kirunabostader.se 9 1 Upphandling Procurement Alla projekt kommer att upphandlas

Läs mer

CLAES HÖGSTRÖM ETABLERA SNOWPARKS

CLAES HÖGSTRÖM ETABLERA SNOWPARKS CLAES HÖGSTRÖM ETABLERA SNOWPARKS ALLT BÖRJAR MED. RÅVAROR UTVINNS SAMLAS IN FÖRVANDLAS TILL PRODUKTER OCH MARKNADSFÖRS MED FOKUS PÅ SPECIFIKATIONER PROBLEM? Allt som produceras men inte är materiell hårdvara

Läs mer

VÄRLDENS MÖJLIGHETER

VÄRLDENS MÖJLIGHETER VÄRLDENS MÖJLIGHETER Hjälp till små och medelstora företag med att utveckla möjligheterna och överkomma hindren på krångliga marknader En presentation av Exportrådet Vi gör det enklare för svenska företag

Läs mer

Gösta Thorell 9 September 2014. Skogsnäringens IT-framtid. enligt EVRY

Gösta Thorell 9 September 2014. Skogsnäringens IT-framtid. enligt EVRY Gösta Thorell 9 September 2014 Skogsnäringens IT-framtid enligt EVRY Det handlar inte bara om teknik Vi arbetar med ett paradigmskifte Det handlar om att göra skillnad. Teknik kommer alltid att vara en

Läs mer

Inledande programmering med C# (1DV402) Introduktion till C#

Inledande programmering med C# (1DV402) Introduktion till C# Introduktion till C# Upphovsrätt för detta verk Detta verk är framtaget i anslutning till kursen Inledande programmering med C# vid Linnéuniversitetet. Du får använda detta verk så här: Allt innehåll i

Läs mer

Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB

Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB Varför ISO/IEC 27005 Information Security Management?? Riskanalys och riskhantering är centrala aktiviteter

Läs mer

Flytta din affär till molnet

Flytta din affär till molnet Flytta din affär till molnet Låt oss prata moln 2 Låt oss prata moln 3 Marknadsförare var först i molnet. Vi skulle inte bli förvånade om du redan använder molnet för: CRM Marketing automation Social media-platformar

Läs mer

+Överskådlighet Normalt sätt blir ett program skrivet i det procedurella paradigmet överskådligt. Modifikationer på delproblem kan ske med lätthet.

+Överskådlighet Normalt sätt blir ett program skrivet i det procedurella paradigmet överskådligt. Modifikationer på delproblem kan ske med lätthet. Uppgift 1 Ett programmeringsparadigm är i grund och botten ett sätt att arbeta, ett sätt att möta problem. Det finns flera olika paradigm där varje paradigm har sina egna styrkor och svagheter. Det som

Läs mer

Installation av F13 Bråvalla

Installation av F13 Bråvalla Website: http://www.rbdesign.se Installation av F13 Bråvalla RBDESIGN FREEWARE - ESCK Norrköping-Bråvalla 1. Ladda ner och packa upp filerna i en mapp som du har skapat på ett lättöverskådligt ställe utanför

Läs mer

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client

Läs mer

PROV. 12 Egenskaper (provavsnitt)

PROV. 12 Egenskaper (provavsnitt) 12 Egenskaper (provavsnitt) 12.1 Egenskaper 12.2 Deklaration av egenskaper 12.3 Åtkomsttjänster för egenskaper 12.4 Åtkomsttjänster med genererade instansvariabler 12.5 Åtkomsttjänster med egna instansvariabelnamn

Läs mer

Fallstudie Den svenska Försvarsmakten Meddelandeinfrastruktur redo för det nya nätverksbaserade försvaret

Fallstudie Den svenska Försvarsmakten Meddelandeinfrastruktur redo för det nya nätverksbaserade försvaret Fallstudie Den svenska Försvarsmakten Meddelandeinfrastruktur redo för det nya nätverksbaserade försvaret Copyright 2002 - Xware AB. All rights reserved. xtrade is a registered trademark of Xware AB. Version

Läs mer

GÖRA SKILLNAD. om vikten av hållbar produktion och om hur den kan skapas. Bengt Savén Södertälje Science Park, 2014-11-07

GÖRA SKILLNAD. om vikten av hållbar produktion och om hur den kan skapas. Bengt Savén Södertälje Science Park, 2014-11-07 GÖRA SKILLNAD om vikten av hållbar produktion och om hur den kan skapas Bengt Savén Södertälje Science Park, 2014-11-07 KORT OM MITT YRKESLIV ABB (trainee Melbourne, chef NC-programmering, produktionsteknisk

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

LUNDS UNIVERSITET KURSPLAN INFC50 Ekonomihögskolan Institutionen för Informatik INFC50

LUNDS UNIVERSITET KURSPLAN INFC50 Ekonomihögskolan Institutionen för Informatik INFC50 Kurskod / Course code Huvudområde/ Main field of study INFC50 Informatik; Informationssystem / Informatics; Information Systems Kursbenämning / Course title Content Management Systems / Content Management

Läs mer

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap A Human-Centered Design Process (ISO 9241-210, 2010) Prototypningsverktyg 1. Plan the humancentred process 2. Understand the context of use Mattias Arvola Meets the requirements 5. Evaluate against requirements

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Rapport elbilar Framtidens fordon

Rapport elbilar Framtidens fordon Teknikprogrammet Klass TE14. Rapport elbilar Framtidens fordon Namn: Joel Evertsson Datum: 2015-03-09 Abstract This report is about electric car. We have worked with future vehicles and with this report

Läs mer

Photometric Diagnosis of Road Lighting

Photometric Diagnosis of Road Lighting Photometric Diagnosis of Road Lighting Do You know if Your Road Lighting fullfill the EUnorms according to CEN/TR 13201? -We can check it! Why Photometric diagnosis? Our principles in 4 steps Preparation

Läs mer

Beslut om bolaget skall gå i likvidation eller driva verksamheten vidare.

Beslut om bolaget skall gå i likvidation eller driva verksamheten vidare. ÅRSSTÄMMA REINHOLD POLSKA AB 7 MARS 2014 STYRELSENS FÖRSLAG TILL BESLUT I 17 Beslut om bolaget skall gå i likvidation eller driva verksamheten vidare. Styrelsen i bolaget har upprättat en kontrollbalansräkning

Läs mer

HR i en internationell organisation, några tankar av P-O Nyquist. Göteborg 2011-11-10

HR i en internationell organisation, några tankar av P-O Nyquist. Göteborg 2011-11-10 HR i en internationell organisation, några tankar av P-O Nyquist Göteborg 2011-11-10 1 P-O Nyquist UTBILDNING Bergsingenjör från KTH Executive MBA från Uppsala ERICSSON (18 år) SW design System design

Läs mer

Revidering av ISO 9001. 2013-11-05 Peter Allvén SIS TK-304/PostNord

Revidering av ISO 9001. 2013-11-05 Peter Allvén SIS TK-304/PostNord Revidering av ISO 9001 Förändringar i ny version av ISO 9001 Det är inte bara ISO 9001 (kraven) som är under översyn utan även ISO 9000 som omfattar Concepts and Terminology. Viktigt att notera är att

Läs mer

Svensk presentation. 2012-12-28 Anita Lennerstad 1

Svensk presentation. 2012-12-28 Anita Lennerstad 1 Svensk presentation 2012-12-28 Anita Lennerstad 1 Trailereffekter AB Bild Specialisten på delar till trailers och släpvagnar 2012-12-28 Anita Lennerstad 2 Utveckling bild bild Axel Johnson AB BRIAB bild

Läs mer