Modellbaserad utveckling med UML 2.0 JOHAN SÄFSTRÖM

Storlek: px
Starta visningen från sidan:

Download "Modellbaserad utveckling med UML 2.0 JOHAN SÄFSTRÖM"

Transkript

1 Modellbaserad utveckling med UML 2.0 JOHAN SÄFSTRÖM Examensarbete Stockholm, Sverige 2010

2 Modellbaserad utveckling med UML 2.0 JOHAN SÄFSTRÖM Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2010 Handledare på CSC var Henrik Eriksson Examinator var Yngve Sundblad TRITA-CSC-E 2010:053 ISRN-KTH/CSC/E--10/053--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Model driven development with UML 2.0 Abstract Within the software industry there has always been a strive for a higher degree of abstraction. At the very beginning software development was about having ones and zeros in the right sequences which was quite time consuming to say the least. FORTRAN was first out to help developers in the 1950 s. Much has happened after that. Different paradigms have evolved and disappeared during the passing of time. With the appearance of UML (Unified Modeling Language) and MDA (Model Driven Architecture) we have now reached the next level. There have been models supporting the software industry for ages, but it is not until now with UML 2.0 that we have reached a level where we can use the models themselves as a programming language. UML as a programming language is a subset of UML and is generally called Executable UML (xuml). The compiler tied to it is called a model compiler. The model compiler can be compared to an ordinary compiler with the difference that it takes an abstract form (model) and creates executable code straight from it. This of course puts high demands on the software tools, used for programming UML, containing the model compiler. Examples of such tools are Rational Rose RT and Telelogic Tau (now Rational Tau). I have had the opportunity to try the model driven approach in a reality-based test within a big telecom company. I used Telelogic Tau to create new code in UML for an already existing program that was originally developed in a traditional way in C. The question at hand is if the software industry is ready to move to model driven development and if this new paradigm has more benefits than drawbacks.

4 Modellbaserad utveckling med UML 2.0 Sammanfattning Det har inom mjukvaruindustrin alltid funnits en strävan efter en högre abstraktionsnivå. I allra första början handlade det om att strukturera upp ettor och nollor i rätt sekvenser, vilket var oerhört tidskrävande. FORTRAN var först ut med att hjälpa utvecklare under 1950-talet. Sedan dess det har det hänt mycket. Olika paradigm har uppkommit och passerat under tidens gång. I samband med uppkomsten av UML (Unified Modeling Language) och MDA (Model Driven Architecture) har vi nu nått nästa nivå. Det har funnits modeller inom mjukvaruindustrin sedan långt tillbaka, men det är inte förrän med UML 2.0 som vi har nått en nivå där modellerna själva kan fungera som ett programmeringsspråk. UML som programmeringsspråk är en delmängd av UML och kallas generellt för Executable UML (xuml). Kompilatorn som är kopplad till en xuml-modell kallas för en Model Compiler. Denna kan jämföras med vanliga kompilatorer med den skillnaden att den tar en abstrakt form (modell) och skapar körbar kod direkt ifrån denna. Detta ställer självklart stora krav på de verktyg som används för att programmera UML. Exempel på sådana verktyg är Rational Rose RT och Telelogic Tau (numera Rational Tau). Jag har haft möjligheten att pröva modellbaserad utveckling i ett verklighetsbaserat test hos ett stort telekomföretag. Jag använde Telelogic Tau för att skapa ny kod i UML för ett redan existerande program som ursprungligen utvecklats på traditionellt sätt i C. Den stora frågan är om mjukvaruindustrin är redo att gå över till modellbaserad utveckling, och om detta nya paradigm har fler fördelar än nackdelar.

5 1. Bakgrund Vad är UML? Vilka olika sätt finns det att använda UML? Vad ingår i UML? Vad är skillnaderna mellan UML 1 och UML 2.0? Model Driven Architecture och Executable UML Model Driven Architecture Executable UML Kodgenerering Vad är kodgenerering? Vilka sorters generatorer finns det? Vilka är fördelarna med kodgenerering? Hur fungerar arbetsflödet vid kodgenerering? Vad kan man bygga med generatorerna? Vad finns det för baksidor med kodgenerering? Vilka typer av kodgeneratorer finns det? Hur är kodgenerering relaterat till computer-aided software engineering (CASE) och MDA? Är kodgenerering verkligen så effektivt? Prestandajämförelse Vilka verktyg finns det som använder UML och MDA? Metod prestandajämförelse Jämförelser Slutsats prestandajämförelse Praktiskt test Metod Tekniken Bakom Modellen i TAU Test i verklig miljö Omgivningen Sammanfattning av modellen Resultat Hur fungerar MDA/Executable UML jämfört med traditionell utveckling? Produktivitet Hur ser framtiden inom MDA och kodgenerering ut? Referensförteckning... 29

6

7 1. Bakgrund. Utveckling av stora program är kärnverksamheten i många stora företag. Det drar enorma kostnader och leder inte sällan till stora förluster när programsystem visar sig vara feltänkta (feldesignade). Programutvecklingsteknik och utvecklingsverktyg har därför blivit centrala frågor i företag. Denna rapport är ett bidrag till detta ständigt pågående arbete. Stora program modulariseras alltid för funktionalitet och flexibilitet. Modulerna kallas objekt och objekttyperna kallas klasser. För beskrivningen av klasser och deras samband finns standarden UML som ger en grafisk beskrivning med olika standardiserade diagramtyper. För att gå från UML-diagram till programkod och tvärtom finns flera avancerade och dyra verktyg. Min uppdragsgivare har nu ställt frågan om tiden är mogen för att gå över till UML2- baserade verktyg se om en introduktion av modellbaserad utveckling skulle kunna vara möjlig. Syftet med examensarbetet är att ta fram den information som behövs för att man skall kunna ta ett beslut angående om det finns UML2-verktyg som är tillräckligt bra och i så fall hur man skall gå tillväga för att skapa lättförståeliga och underhållbara modeller i detta verktyg. 1

8 2. Vad är UML? UML är en standard för design och modellering som har tagits fram av OMG (Object Modeling Group). Förutom UML är OMG mest kända för att ha tagit fram CORBA, standarden för kommunikation mellan distribuerade objekt. UML är en förkortning av Unified Modeling Language. Som namnet antyder är detta ett eget språk, som används för att beskriva och understödja allehanda mjukvarusystem, men särskilt de som är objektorienterade (OO). Enkelt uttryckt består det av en grafisk notation. Så här skriver OMG i UML Standard: The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software based systems as well as for modeling business and similar processes. - OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.2 Det ursprungliga UML kom till redan Den första versionen kallades förvirrande nog för UML 1.1 eftersom den redan reviderats en gång av alla berörda parter. Efter detta har det funnits flera versioner med mindre ändringar, samt det stora steget till UML 2.0 som har varit det största hittills. UML 2.2 är den senaste utgivna standarden vid tidpunkten för denna rapport. Uppkomsten av UML härrör från unifieringen av de många objektorienterade modelleringsspråk som frodades under sent 1980-tal och tidigt 1990-tal. Anledningen till detta är logisk. Ingenjörskonst i allmänhet förenklas genom arbete med modeller. Det gäller i samma utsträckning för en arkitekt som för en mjukvaruutvecklare. Det har funnits olika typer av modeller inom mjukvaruindustrin under en längre tid. Huvudanledningen till detta är helt enkelt att programmeringsspråk i sig själva inte har en tillräckligt hög abstraktionsgrad, och för att skapa sig en överskådlig bild behövs någon form av modell. Dessa modeller har varierat kraftigt beroende på vad 2

9 som har varit det viktigaste för berörda utvecklare. Modellerna möjliggör vad man enkelt brukar kalla för mjukvarudesign, och de mest vanliga modellerna har förenats i UML (UML Distilled 2004, s.1). Exakt vad som UML används bäst till beror mycket på vem man frågar. UML har många olika domäner och detta kommer sig till största delen av att det är många olika aktörer som under årens lopp har haft olika krav och önskemål om interoperabilitet mellan olika system. De olika aktörerna har deltagit till att bygga upp UML till vad det är idag, och detta är en process som lever i allra högsta grad. Att så många olika parter har varit med och skapat UML har gjort att det finns ett brett spektrum på användande av språket. Modellerna ger generella fördelar, men synen på vad som leder till en effektiv utveckling av programvara går brett isär bland utvecklare världen över. Trots att modellerna har funnits inom mjukvaruindustrin länge är deras roll fortfarande mycket omdiskuterad. Detta beror till hög grad på hur olika personer använder modellerna och uppfattar UMLs roll. Det är just detta fenomen som är väldigt betydelsefullt och som denna rapport kommer att lägga mycket fokus på Vilka olika sätt finns det att använda UML? Vi har konstaterat att UML är brett omfattande och att nyttjandet av UML ser väldigt olika ut. Funderar man lite mer noggrant över texten på föregående sida om OMGs idé för vad UML ska vara, inser man att det är en hel ocean av tänkbara användningsområden. För att få någon form av överblick krävs det att man förenklar bilden av UML och ger användandet lite struktur. Vi behöver med andra ord se mer ingående på UMLs olika användningsområden. Fowler kategoriserar, i sin bok UML Distilled, in användandet av UML i tre olika huvudkategorier: Sketch (Skiss) Blueprint (Ritning) Programming language (Programmeringsspråk) UML som skiss Fowler skriver vidare att UML till största delen används som sketch eller skiss på svenska. I denna grupp gör man helt enkelt bara enkla skisser över systemet, eller delar av detta, utan att gå närmare in på några detaljer. Innan vi går vidare kan det även vara bra att omnämna begreppen Forward/Reverse engineering. Med forward engineering avses här att man ritar UML-diagram innan man skriver koden. Reverse engineering är motsatsen, koden är redan skriven, men man bygger UML-diagram för att kunna förstå den bättre. 3

10 Forward engineering och reverse engineering är användbara både inom kategorierna sketch och blueprint. (UML Distilled 2004, s. 2). Att använda UML som skiss innebär att man är selektiv i sitt modellerande. Om man använder skissen för forward engineering så menas att man först skissar UMLdiagram och sedan programmerar utifrån detta. Det typiska användandet för skissen är som diskussionsunderlag inför en grupp inom utvecklingsteamet. Målet är att kunna måla upp och kommunicera idéer över det planerade arbetet. Diskussioner om koden kan uppstå, men rör då oftast bara de specifika delar som är särskilt viktiga eller svåra. (UML Distilled 2004, s. 2). I fallet med reverse engineering används skissen för att förklara hur delar av systemet fungerar. Man modellerar då endast de klasser som är mest intressanta och värda att diskutera innan man åter ger sig in i koden. Skissen är väldigt dynamisk och informell. Den är snabb och fungerar bra för samarbete. Det typiska mediet är en whiteboard, men skissen kan även vara en viktig faktor inom dokumentation, då den fokuserar mer på förståelse hos läsaren än att ge en komplett bild av verkligheten. Mycket av den UML som återfinns inom litteraturen är just i skissform (UML Distilled 2004, s. 2). En enkel sökning på Internet visar att det finns en uppsjö av enkla och bra verktyg för att skissa UML Blueprint Där skissen är enkel och dynamisk är blueprinten, eller ritningen, dess motsats. Den används för att beskriva systemet i sin kompletta form. Med denna ritning ska man enkelt kunna leverera sin kod, utan att stöta på några stora hinder. Vanligtvis är det en mer erfaren utvecklare som skapar ritningen, där utvecklingsteamet sedan får programmera utifrån denna. Vid reverse engineering skapas ritningen utifrån koden, och är en detaljerad förteckning av klasser och parametrar. Syftet är att få en bra och grafisk dokumentation som ska hjälpa utvecklare att förstå systemet (UML Distilled 2004, s. 3). Att skapa en ritning kan innebära att man inkluderar alla detaljer, eller så kan man nöja sig med att endast modellera en utvald del av systemet som en blueprint. En vanlig metod är att man skapar blueprints för sina subsystem, men när man kommer till mellanliggande gränssnitt överlåter man arbetet med att ta fram detaljerna i gränssnitten för utvecklarna (UML Distilled 2004, s. 3). Till skillnad mot sketch kräver blueprints mycket mer sofistikerade verktyg. Ursprungligen kallades dessa verktyg för CASE-tools (Computer Aided Software Engineering), men begreppet har under årens lopp fått negativa associationer och kallas därför sällan så numera. Verktyg som utför forward engineering skapar utförlig kod utifrån modellen. Reverse engineering sparar ut nödvändiga data ur koden och genererar diagram. Verktyg som klarar både forward/reverse engineering använder vad man kallar för roundtrip engineering och kallas för roundtrip tools (UML Distilled 2004, s. 3). 4

11 Gränsen mellan blueprint och sketch kan vara rätt suddig. Enkelt uttryckt är skissen avsiktligen ofullständig, och blueprinten är komplett. (UML Distilled 2004, s. 3) UML som programmeringsspråk Ju mer man arbetar med konstruktion i UML, desto mindre lämnas kvar till sedvanlig programmering. Det vanliga arbetet blir då mer och mer mekaniskt och man kan dra slutsatsen att detta arbete också skulle kunna automatiseras. Många CASE-verktyg har någon form av kodgenereringsegenskaper. När man når den punkten att UML specificerar hela systemet, har man också kommit till den punkten att UML kan fungera som ett programmeringsspråk. I detta läge ritar utvecklaren UML-diagram och genererar körbar kod direkt utifrån modellen. För att detta ska vara möjligt krävs förstås mycket kraftfulla verktyg. Med UML som programmeringsspråk uttrycker UML-diagrammen exakt samma sak som den utifrån diagrammen genererade koden. Därmed talar man egentligen inte längre om roundtrip engineering eftersom diagrammen och källkoden betyder samma sak. För att förtydliga de olika sätten att arbeta med modeller använder jag mig av bilden nedan. De två ytterligheterna i diagrammet är Code Only och Model Only. I dagsläget torde Code Only vara det mest ovanliga sättet att arbeta, men det existerar säkerligen. Att skriva kod helt utan modell är garanterat inget en UML-förespråkare skulle rekommendera, och de flesta utvecklare använder nog någon form av modell. Model Only motsvarar användandet av UML som skiss, till exempel vid en whiteboard för att strukturera upp systemet och överföra idéer inom utvecklingsteamet. Det är här som UML har sitt största användningsområde i dagsläget (UML Distilled 2004: s. 2). 5

12 Vid enbart reverse engineering använder man koden själv som källa, och därifrån skapar diagrammen som en grafisk vy av koden. Verktyg som stöder detta är oftast intimt sammankopplade med programmeringseditorn där själva koden skrivs. Detta motsvarar Code Visualization i bilden. Roundtrip engineering är ett mellansteg där arbetet kan ske från två håll och hamnar därmed i mitten av diagrammet. UML som programmeringsspråk kategoriseras som modellcentrerad (Model-centric i bilden) Vad ingår i UML? UML är väldigt omfattande och det går inte att beskriva dess innehåll i denna rapport. Jag hänvisar till OMGs hemsida för mer information om UML. Läsaren förutsätts känna till de vanligaste diagrammen (såsom Klassdiagram, Aktivitetsdiagram, Tillståndsmaskiner, Sekvensdiagram), och får läsa sig till mer information om de övriga. Jag kommer dock i nästa punkt ge en kort beskrivning av skillnaden mellan UML 1.x och UML 2 eftersom det har haft omfattande konsekvenser för innehållet i denna rapport Vad är skillnaderna mellan UML 1 och UML 2.0? Det finns ett problem i UML 1.x. Det är väldigt svårt att beskriva arkitektur och återanvändandet av komponenter, bara genom att använda själva standarden. Anledningen till detta är att klassdiagrammen beskriver egenskaper och samband för varje instans av en klass, och inte hur den används i en specifik applikation eller komponent. Detta medför att det är svårt att skapa plug-and-play arkitektur. I samband med UML for Real Time (UML-RT) som var en utbyggnad av UML så introducerades så kallade capsules. Dessa medförde återanvändbara arkitekturer i UML och är ett av fundamenten till ett annat viktigt OMG-initiativ, Model Driven Architecture (MDA), vilket jag beskriver i nästa kapitel. 6

13 3. Model Driven Architecture och Executable UML 3.1. Model Driven Architecture Som nämnts i föregående kapitel har en del mjukvarutillverkare valt att använda UML enligt en mer avancerad metod. Man har tagit steget bortom att vara ett enkelt modelleringsspråk till vad som kallas Model Driven Architecture (MDA). MDA är ett initiativ från OMG som betonar vikten av utveckling genom att transformera modeller (MDA Guide Version 1.0.1, 2004). I grund och botten är det ett standardiserat tillvägagångssätt för att använda UML som ett programmeringsspråk. Analys, design, implementation, byggande, färdigställning, debuggning och testning är allt gjort genom att skapa och definiera grafiska modeller, oftast men inte nödvändigtvis i UML. UML och MDA är tätt förknippade, men att man använder det ena betyder inte nödvändigtvis att man använder det andra och vice versa. Ett verktyg som implementerar MDA (Tex IBM Rational XDE) kan stödja multipla model-to-model-transformationer där modellen raffineras i varje steg. Ännu mer vanligt är verktyg som direkt transformerar en plattformsoberoende modell till en kvalitativ implementation. Exempel på detta är IBM Rational Rose RealTime, Pathfinder Solutions PathMATE och I-Logix Rhapsody. Enligt detta angreppssätt skapar utvecklaren en modell av systemet/applikationen och MDA-verktyget genererar en exekverbar fil eller ett bibliotek, till motsats från ett kodskelett. Delar av koden kommer ifrån tillstånd och transitioner i tillståndsmaskiner (state machines) samt klassoperationer, men den mesta delen av koden kommer direkt ifrån den grafiska modellen. Det kan vara så mycket som 90 % av koden, vilket i sig skvallrar om vilken fördel det blir att inte behöva skriva allt för hand. Det som krävs är att rita nödvändiga diagram och sedan generera koden. En annan fördel är att kvaliteten ökar. Detta kommer delvis från att den detaljerade koden som genereras implementerar begrepp som tillståndsmaskiner och objekthantering. Den genererade koden blir korrekt genom konstruktion ( En annan mycket viktig aspekt ur utvecklarens synvinkel är fokus på en hög nivå systemets beteende. Genom att arbeta med modellen får man en högre grad av abstraktion (MDA Distilled 2004, s.2). Istället för att tänka på hur man ska skriva ett uttryck rent kodmässigt kan man istället fokusera på vilka konsekvenser en implementation får genom att titta direkt i modellen. Fokus ligger alltså på funktionaliteten och inte på hur man uttrycker sig rent syntaxmässigt. MDA delar upp utveckling i två huvudkategorier. Den första handlar om att för varje enskild applikation skapa en så kallad Platform Independent Model (PIM). PIM är en UML-modell som inte är beroende av någon särskild teknologi eller programmeringsspråk. I den andra delen används verktyg för att omforma PIM till en Platform Specific Model (PSM). Denna har en bestämd miljö som den ska köras i. Det är från PSM:en som den exekverbara koden sedan genereras. (Executable UML 2002, s ) För att förtydliga kan det vara bra med ett exempel: 7

14 Ponera att man ska bygga ett flygbokningssystem med hjälp av MDA. Man börjar då modellera sin PIM i något UML-verktyg. Det är tänkbart att man skulle vilja kunna använda detta system för olika plattformar, tex Java och C++. Följaktligen skapar man då två PSM:er med hjälp av något verktyg kapabelt att omforma PIM till PSM för dessa plattformar. Därefter kan ytterligare verktyg användas för att generera koden för båda plattformarna Executable UML Metoden ovan kan låta lite väl snårig och det finns verktyg som automatiserar hela processen, dvs att man går direkt från PIM till exekverbar kod utan några (för användaren synliga) mellansteg. Det är i just detta fall som UML är ett eget programmeringsspråk. Krävs det manuella ändringar i något mellansteg är vi tillbaka vid blueprint. En variant av detta är Steve Mellors Executable UML, förkortat xuml (Mellor and Balcer). Executable UML och MDA har mycket gemensamt. Skillnaden ligger i att i Executable UML går man direkt från PIM till ett färdigt system i ett enda steg via en så kallad Model Compiler. Det behövs alltså ingen PSM. Det är Model Compilern som gör att processen blir helt automatisk. Model Compilers bygger på användandet av arketyper i UML. En arketyp beskriver vad som ska göras med en Executable UML-modell och omforma denna till en specifik plattform. I fallet med flygbokningssystemet behöver man alltså två arketyper, en för Java och en för C++. Beroende på vilken av dem du kör mot din UML-modell får du en version av systemet som stöder just den plattformen. Executable UML använder inte hela spektret av UML. Alla diagram och delar i UML är inte nödvändiga för skapandet av Executable UML. Av den anledningen kan man säga att Executable UML bara är en delmängd av UML. Bilden nedan visar enkelt uttryckt skillnaden (Model Driven Architecture with Executable UML 2002, s 12.). 8

15 4. Kodgenerering Nu har jag beskrivit UML och MDA och vi har fått en bra uppfattning om hur det kan användas för kodgenerering. MDA är dock bara en av många metoder som använder kodgenerering. Därför vill jag belysa kodgenerering som ett mer allmänt begrepp. Anledningen till detta är att det är intressant ur ett framgångsperspektiv. Hur kommer MDA och Executable UML utvecklas i framtiden och vilka andra metoder finns det som redan har testats. Detta kapitel beskriver kodgenerering i allmänhet, dess olika tekniker samt fördelar och nackdelar Vad är kodgenerering? Kodgenerering är en teknik som handlar om att bygga kod genom att använda ett verktyg. Sådana verktyg kan vara allt ifrån enkla hjälpskript till storartade kreationer där abstrakta modeller av affärslogik blir till kompletta applikationer (Code Generation in Action 2003, s.3, 251). Ett annat vanligt exempel på generatorer som används idag är kompilatorer (Code Generation in Action 2003, s.27). Det finns ingen allmänt gällande definition på vad kodgenerering är; det kan vara allt från att köra ett enkelt kommando från att använda ett omfattande GUI, man kan bygga för ett eller flera programmeringsspråk på samma gång, och man kan bygga koden endast en gång eller multipla gånger. Det finns en oändlig variation av inputs och outputs. Det som är den gemensamma nämnaren är att output från generatorn är kod som en programmerare annars hade behövt skriva manuellt Vilka sorters generatorer finns det? Som nämnts tidigare finns det en oerhörd variation av generatorer men det finns två tekniker som på ett enkelt sätt delar in generatorer i två kategorier, passiv eller aktiv. Passiv kodgenerator. Dessa kodgeneratorer körs bara en gång när man är säker på att man har rätt inparametrar. Efter genereringen modifierar utvecklaren den genererade koden och på så sätt blir det inte längre någon fördel att generera koden på nytt. Ett vanligt exempel inom denna kategori är så kallade wizards där syftet är att utvecklaren ska få en flygande start. Aktiv kodgenerator. Kodgeneratorer inom denna kategori producerar kod som kan regenereras vid behov, till exempel under ett projekts gång. Den genererade koden modifieras aldrig av utvecklare eftersom fördelarna med aktiv generering då försvinner. Koden genereras på nytt varje gång förutsättningarna ändras. (The Pragmatic Programmer 1999, s.102). 9

16 Jämförelse mellan aktiv/passiv generator: Huvudskillnaden mellan aktiv och passiv består alltså i hur koden underhålls under ett projekts gång. Om kodgeneratorn är del i byggprocessen och den genererar ny kod vid varje ombyggnad så är det en aktiv generator. Om koden från samma generator modifieras av en utvecklare så hamnar den i kategorin passiv generator. Båda teknikerna kan spara tid och pengar men användningsområdet skiljer mycket ( Aktiva generatorer bygger kod som man inte ska modifiera, eller endast modifierar specifikt valda sektioner av koden som inte berörs av generatorn under regenereringscykeln. Passiva generatorer bygger koden en gång och sedan får man förbättra och underhålla koden därifrån. Passiva generatorer ger en initial fördel i produktivitet, men fördelarna med aktiva generatorer, där koden underhålls och buggar i mallarna kan motverkas och ändras i hela kodbasen, förloras i den passiva modellen ( Vilka är fördelarna med kodgenerering? Kodgenerering är en mycket omdiskuterad metod inom mjukvaruutveckling. Det finns mycket som talar för kodgenerering, men även en del negativa aspekter. I stora drag kan man skriva ner fördelarna med kodgenerering i fyra punkter: Kvalitet: Kvaliteten hos koden som byggts av en generator är direkt relaterad till kvaliteten hos koden eller mallen som använts för att skapa målkoden. Om koden för generatorn eller dess mall förbättras och koden regenereras så kommer även målkoden förbättras (Code Generation in Action 2003, s.xvii,15). Konsistens: Målkoden som genererats av en kodgenerator är extremt konsistent. Namn på klasser, variabler och metoder byggs på samma sätt rakt igenom hela målkoden. Detta gör att målkoden är enkel att använda och gör det enklare att utöka funktionalitet (Code Generation in Action 2003, s.xvii,15). Produktivitet: Kodgeneratorer har potential att vara oerhört produktiva. Efter att man angivit de väsentliga inputparametrarna kan koden genereras på något ögonblick. Den riktiga fördelen med en kodgenerator kommer dock efter den initiala genereringen. Varje gång någonting i designen ändras så är det bara att generera om koden. Detta ger en stor fördel särskilt med tanke på att det är väldigt få projekt där kraven inte ändras under projektets gång (Code Generation in Action 2003, s.xvii,15). Abstraktion: Vissa generatorer bygger kod baserat på abstrakta modeller av målkoden. Till exempel kan man bygga ett SQL schema där definitioner av tabeller och fält med mera är representerade via XML. Inom MDA är denna höjning av abstraktion central 10

17 (MDA Distilled 2004, s2). Värdet av denna abstraktion är att till exempel att generatorn kan ställas om för att bygga kod för en annan plattform Code Generation in Action 2003, s.xvii,15) Hur fungerar arbetsflödet vid kodgenerering? Standardflödet inom mjukvaruutveckling är editering-kompilering-test. Vi editerar koden och kompilerar den. Därefter genomförs tester för att se att programmet beter sig som tänkt. Måste man ändra någonting så repeteras flödescykeln till dess att man uppnått ett tillräckligt bra resultat. Arbetsflödet vid kodgenerering beror först och främst på om man använder aktiv eller passiv generering. Aktiva generatorer bygger kod som man inte modifierar, eller att man modifierar endast utvalda delar som generatorn inte tillåts ändra. Passiv generering bygger kod som man sen editerar till den grad man själv finner lämpligt. Arbetsflödet för en passiv generator blir alltså att man kör generatorn och sedan följer man standardflödet editering-kompilering-test därefter. Med aktiv generator kör du först genereringen och sen kompilering och test precis som vanligt. Vid problem i den genererade koden ändrar man mallen eller inputen till generatorn och regenererar. Är problemet i en eventuellt handskriven del som reserverats från generatorn så följer man det vanliga standardflödet för den delen (Code Generation in Action 2003, s.34-35) Vad kan man bygga med generatorerna? Det finns generatorer för ett brett spektrum av system och applikationer. Generellt sett fungerar generatorer bra när man har stora problem som kräver stora volymer kod, exempelvis databasaccess och stored procedures, (Code Generation in Action 2003, s.25), men det går även att generera användargränssnitt och dokumentation (Code Generation in Action 2003, s ). Affärslogik är ett område som där kodgenerering kan vara mer svårtillämpat (Code Generation in Action 2003, s.251) Vad finns det för baksidor med kodgenerering? Liksom vilken annan teknik som helst finns det bra och dåliga sidor. Här följer ett par aspekter som man måste hantera för att det ska fungera effektivt: Rädsla för ny teknik: Introduktion av en kodgenereringsteknik möts ofta med rädsla och skepsis av de utvecklare som ska använda den. Det kan till exempel vara rädsla för att den nya tekniken ska göra ens jobb överflödigt eller motvilja mot förändring (Code Generation in Action 2003, s.23, 26, 35-36). Dokumentation: Kodgeneratorn behöver alltid dokumenteras, även om den är köpt från tredje part. Det behövs för att veta hur den fungerar i den existerande miljön och hur den ska underhållas (Code Generation in Action 2003, s.21). 11

18 Utbildning: För att utvecklare ska kunna använda den krävs också utbildning i det nya sättet att arbeta med generatorn och värdet av detta. (Code Generation in Action 2003, s.22-23). Underhåll: En kodgenerator innebär ännu ett verktyg i mängden av utvecklingsprogramvara. Det normala arbete med versionshantering och underhåll som brukar krävas gäller alltså även här (Code Generation in Action 2003, s.23). Komplexitet: Beroende på komplexiteten hos applikationen kan generatorn i sig bli komplex. Det gäller att försöka hålla generatorn användarvänlig för att användare ska nyttja den (Code Generation in Action 2003, s.26, 29), (Model Driven Architecture with Executable UML 2004, s33). Prestanda: För vissa kritiska sektioner av koden kan det behövas inlinekod för att få tillräckligt hög prestanda. (Executable UML 2002, s. 26),(Code Generation in Action 2003, s.79) Vilka typer av kodgeneratorer finns det? Att skapa olika kategorier för kodgeneratorer är svårt. En metod är att se på input/output på generatorn för att se skillnader. När man tittar på input så kan man antingen ha kod eller någon abstrakt form som representerar designen. För outputsidan kan det vara inputkoden med endast vissa tillägg eller helt ny kod som helt och hållet implementerar designen och som inte kräver någon utökning. Baserat på dessa skillnader I input och output kan vi definiera olika typer av generatorer (Code Generation in Action 2003, s.28-29): Code Munger: En Code Munger läser kod som input och bygger ny kod som output. Den nya koden kan antingen vara partiell eller helt färdig beroende på designen hos generatorn. XDoclet är ett exempel på en Code Munger. (Code Generation in Action 2003, s.29). Inline Code Expander: En Inline Code Expander läser kod som input och bygger ny kod som använder inputkoden som en bas, men expanderar delar av koden, baserat på designen hos ursprungskoden. Embedded SQL-språk som tex Pro*C är exempel på inline code expanders. SQL skrivs in i C-koden och generatorn bygger den slutgiltiga koden genom att lägga in SQL in i C-koden. (Code Generation in Action 2003, s.30). Mixed Code Generator: Denna modell använder kod som input och genererar sedan ny kod genom att använda inputkoden som bas men returnerar outputkoden tillbaka till inputfilen. Wizards är ofta implementerade som mixed code generators. Kommentarer för de stycken som generatorn har lagt till är ofta inlagda i koden. (Code Generation in Action 2003, s.30). 12

19 Partial Class Generator: En Partial Class Generator tar en abstrakt definition som input och bygger outputkod som är delvis färdig. Användaren får själv fylla i den fulla informationen för metoder och underklasser. (Code Generation in Action 2003, s.31). Tier Generator: Denna typ av generator tar en abstrakt definition och skapar komplett kod utifrån denna. Koden som har genererats modifieras inte av användaren (Code Generation in Action 2003, s.32) Hur är kodgenerering relaterat till computer-aided software engineering (CASE) och MDA? CASE-verktyg var vanliga i slutet av 80-talet och under tidigt 90-tal. Dessa verktyg påstods vara så kraftfulla att programmerarens roll skulle försvinna. Med hjälp av visuella verktyg och en generator skulle man enkelt bygga hela applikationer. Detta finns en klar parallell mellan gårdagens CASE-verktyg och dagens MDA-generatorer som kompilerar UML till exempelvis Java eller.net. Verktyg inom båda kategorierna använder en abstrakt beskrivning för att skapa kod med hjälp av en generator. För att knyta an till föregående kapitel bör nämnas att modellbaserad generering med UML är ett bra exempel på när man använder tier-generatorer (Code Generation in Action 2003, s.32). Inom MDA kallas som tidigare nämnts dessa generatorer för Model Compilers. Tekniken hos MDA/CASE-verktyg skiljer sig från övrig kodgenerering på så sätt att den fungerar ovanifrån-ner, och de flesta andra kodgenereringstekniker gör tvärtom, botten-upp. ( Är kodgenerering verkligen så effektivt? Som jag tidigare nämnt är det inte alls alla som anser att kodgenerering fungerar i praktiken. En fråga som ofta uppstår i de här sammanhangen är att om det är så fantastiskt effektivt att det bara är att trycka på en knapp för att generera körbar kod, varför gör då inte alla det. En som har reagerat på detta sätt är Paul Kimmel (UML Demystified 2005, s. 188): If somebody tells you that you are to model, model, model and flip a switch generating an executable, then flip that bozo bit. We are a decade or two away from the technology and education supporting generated applications. Min tolkning av detta är att modellering med kodgenerering sällan blir så enkelt som pro-anhängare säger. Det finns många hinder på vägen som gör att modellering med kodgenerering inte är så effektivt som en del vill få det att framstå som. 13

20 5. Prestandajämförelse Mitt arbete gick ut på att använda ett verktyg som var kapabelt att utifrån UML generera körbar kod. Därför gjorde jag en jämförelse mellan några MDA-baserade verktyg som jag hade tillgång till hos min uppdragsgivare Vilka verktyg finns det som använder UML och MDA? Idag översvämmas marknaden av verktyg som använder UML och MDA. Det finns dock en än så länge begränsad upplaga av verktyg som är kapabla att generera avancerad kod direkt ur UML-modellen. Några av de mest avancerade på området är Rational RSA, Rational Rose RT och Telelogic Tau (Numera Rational Tau). Det var även dessa tre som jag undersökte för möjlig tillämpning i mitt arbete Metod prestandajämförelse Mitt sätt att jämföra programmen är att skapa en lista med olika viktiga aspekter som programmet bör ha. Genom att sedan betygssätta varje aspekt och multiplicera med en viss vikt får man sedan ett värde för varje aspekt. Genom att sedan addera värdena kan man avläsa en slutsumma som man kan jämföra med de andra programmens slutsummor. Detta är en enkel metod som såklart kan missbrukas för att ge vinklade slutsatser och därför bör man också komplettera med en diskussion kring resultaten. De aspekter (med vikter) som är lämpliga för avdelningen att ta med har jag fått av min handledare på företaget och dennes chef. Se diagrammet nedan för att de olika aspekterna och deras individuella vikter. Prioritet Prioritet Utseende Snabbhet Pålitlighet Utvecklade kringsystem Kompabilitet yttre Kompabilitet inre Kodgenerering Figur 1. Som figuren visar har jag valt att sätta vikter ända upp till nivå 5. Detta har som följd att aspekter med värde 5 får väldigt stort utslag i det totala värdet som visas i figur tre 14

21 nedan. Det är dock helt avsiktligt då vissa aspekter är avgörande för hur möjligheterna till att arbeta med något av verktygen är. Viktigast är bra kodgenereringsegenskaper och näst viktigast är pålitlighet Jämförelser Det slutgiltiga resultatet fick jag fram genom att intervjua utvecklare som arbetar med de olika verktygen. Då antalet intervjuade personer inte var särskilt stort och själva användandet skilde sig mellan utvecklarna blev dock resultatet för litet för att ge en tillräckligt bra helhetsbild. Utifrån den information jag fick kunde gjorde jag ändå ett försök till sammanställning som syns i figur 2 nedan RSA 3 Rose RT 2 TAU 1 0 Utseende Snabbhet Pålitlighet Utvecklade kringsystem Kompabilitet yttre Kompabilitet inre Kodgenerering Figur 2. Den visar de olika verktygens individuella betyg i de olika aspekterna. Vad som är anmärkningsvärt här är skillnaden i kapacitet för kodgenerering. RSA klarar inte att generera kod på samma sätt som Rose RT och är inte i närheten av TAU. Rose RT är inte heller lika avancerat som TAU och det kommer till stor del av att Rose RT inte stöder UML 2.0. Konsekvensen består helt enkelt i att man arbetar på olika abstraktionsnivåer. Med TAU arbetar man helt i sin UML-modell och när man är klar gör man en kodgenerering som resulterar i en körbar kod. I RSA arbetar man fram en modell som man genererar ett kodskelett ur. Detta skelett är endast uppbyggt av klasser och funktioner och innehållet måste man fylla i själv. Rose RT fungerar som ett mellanting. Man kan arbeta på en hög nivå i modellen, men det krävs att man gör vissa delar i handskriven kod. Det uppstår då en skillnad i abstraktionsnivå och kan göra att man har svårare att avgöra var ett fel uppstår i modellen eller i den handskrivna koden (Code Generation in Action 2003, s.79). Slutresultatet visas här i figur 3. Oavsett betygsmodellen så hade TAU uppenbarligen varit det enda rimliga alternativet av dessa tre. 15

22 Utseende Snabbhet Pålitlighet Utvecklade kringsystem Kompabilitet yttre Kompabilitet inre Kodgenerering Summa RSA Rose RT TAU Figur 3. På det hela taget så är TAU klart bäst och detta beror till väldigt stor del på den avancerade kodgenereringen. Oavsett vad den här betygsmodellen säger så bör man föra en diskussion kring de olika verktygen. Det som gör den största skillnaden är som sagt kodgenereringen. Skillnaderna mellan programmen är så stora att vi egentligen hade klarat oss utan betygsdiagrammen. Det är nämligen en avsevärd skillnad i teknologi där det för användaren framförallt är graden av abstraktion som skiljer. I TAU kan användaren arbeta fullständigt i sin UML-modell och behöver därför inte lämna denna högre språknivå. Saker som automatisk felkorrigering, felsökning och debuggning underlättas därmed kraftigt Slutsats prestandajämförelse Efter genomgången med prioriteringsmodellen faller mitt val av verktyg på TAU. Det finns även andra aspekter som jag inte tidigare nämnt som till exempel möjligheten till val av programspråk. Avdelningen arbetar nästan helt i C och TAU är den enda av dessa tre som kan generera C-kod. Därför hade kanske valet fallit på TAU om man inte samtidigt tänker byta programmeringsspråk. Om man dock skulle vilja byta stöder alla tre verktygen både C++ och JAVA. Nackdelarna med TAU är att det än så länge inte stöder formatet EMF för utbyte av UML-modeller mellan olika program samt att det kräver mycket goda kunskaper i UML och i verktyget själv. 16

23 6. Praktiskt test 6.1. Metod Det kan vara svårt att avgöra hur bra ett verktyg för att generera kod är genom att bara göra enkla tester. Därför har jag valt en lite mer avancerad approach för att analysera detta problem. Tanken var att jag skulle utveckla programvara till ett redan befintligt och inte särskilt omfattande delsystem med hjälp av verktyget TAU. Detta för att kunna se hur resultatet blev (jämfört med redan befintlig programvara) med hjälp av denna alternativa utvecklingsmetod. Programvaran för systemet kallas IPSyncRegi och är ett enkelt interface med en server och klient och ett antal olika signaler däremellan. Fördelen med att välja IPSyncRegi är att det är ett högst aktuellt exempel på en programvara som utvecklats på avdelningen samt att det finns en tillhörande simulator för systemet vilket möjliggör testning av den genererade koden Tekniken Bakom Vad måste man ha med för att kunna göra en kodgenerering? I exemplet med IPSyncRegi som beskrivs mer detaljerat nedan får man svar på dessa frågor samt hur det fungerar att koppla den genererade koden mot OSE och avdelningens byggmiljö. IPSyncRegi IPSyncRegi är som nämnts ett enkelt interface som sitter mellan olika kort i en basstation. Det har en server och en eller flera klienter och mellan klienterna och servern går det en mängd olika signaler. Serverns respektive klienternas handlingsschema bygger på tillståndsmaskiner. Nedan följer en beskrivning av de viktigaste delarna för systemet i verktyget TAU Modellen i TAU UML-Modellen för IPSyncRegi i TAU är relativt enkel. Den har egentligen bara en aktiv klass och det är Server. I mitt exempel nedan ingår dock även en klass för Client eftersom jag ville kunna simulera även denna i modellen. Vid själva kodgenereringen hade jag dock bara Server-klassen och ett externt interface vilket beskrivs längre fram. Utöver klasserna för Server och Client har jag även en huvudklass för programmet som jag kallat IPSyncRegi som även den är aktiv, eftersom dess underklasser är aktiva. Notera de dubbla ramarna på klassernas lodräta sidor i exemplet nedan. Det är markeringen för aktiv klass i UML2. 17

24 Klasserna Server och Client är anslutna via var sitt interface IServer och IClient. Tillsammans bygger dessa upp ett protokoll. Jag har även in lagt in definitionen för denna koppling i klassdiagrammet. 18

25 Varje aktiv klass är också försedd med ett tillståndsdiagram (State machine) som beskriver systemets beteende i olika lägen. Här är tillståndsdiagrammet för Serverklassen Varje rektangel med rundade hörn i bilden nedan beskriver ett tillstånd: Tillstånden ändras via signaler. Vilken typ av signal det är beror på om pilen pekar inåt (insignal) eller utåt (utsignal). TAU har implementerat signalerna på det här sättet så att man enkelt ska kunna specificera vad som leder till ett nytt tillstånd direkt i tillståndsdiagrammet. 19

26 Motsvarande tillståndsdiagram för Client-klassen ser ut på följande vis: Flödet för klienten är självfallet annorlunda. I övrigt är det ingen större skillnad gentemot tillståndsdiagrammet för Server-klassen. Den enda uppenbara skillnaden är att insignaler med samma namn här är representerade som utsignaler och vice versa. Tillståndsdiagrammen når man enkelt genom att klicka fram dem under respektive klass i modellvyn. 20

27 Allting i diagrammen finns även representerat i modellvyn. Objekt är därför lätta att återanvända, och verktyget kopplar själv till rätt objekt om man återanvänder namn. Samma objekt kan förekomma på flera ställen, beroende på om de har många kopplingar till olika element. Ändrar man ett objekt någonstans ändras samma objekt i hela modellen. 21

28 Vilka signaler som finns tillgängliga har jag definierat i ett komponentdiagram. Detta innehåller information om vilka signaler som ska finnas tillgängliga i interfacet. package SyncRegi SyncRegi Component Diagram {2/4} <<interface>> IServer signal INITIATE_MEMORY () signal IPAC_IP_SYNC_REGI_SERVER_UP_IND ( IpacIpSyncRegiServerUpInd) signal IPAC_IP_SYNC_REGI_SERVER_DOWN_IND ( IpacIpSyncRegiServerDownInd) signal IPAC_IP_SYNC_REGI_UNPUBLISH_IND ( IpacIpSyncRegiUnpublishInd) signal IPAC_IP_SYNC_REGI_INITIATE_SERVICE_CFM ( IpacIpSyncRegiInitiateServiceCfm) signal IPAC_IP_SYNC_REGI_INITIATE_SERVICE_SUS ( IpacIpSyncRegiInitiateServiceSus) signal IPAC_IP_SYNC_REGI_INITIATE_SERVICE_REJ ( IpacIpSyncRegiInitiateServiceRej) signal IPAC_IP_SYNC_REGI_TERMINATE_SERVICE_CFM ( IpacIpSyncRegiTerminateService Cfm) signal IPAC_IP_SYNC_REGI_AUDIT_CFM ( IpacIpSyncRegiAuditCfm) <<interface>> IClient signal IPAC_IP_SYNC_REGI_INITIATE_SERVICE_REQ ( IpacIpSyncRegiInitiateServiceReq) signal IPAC_IP_SYNC_REGI_TERMINATE_SERVICE_REQ ( IpacIpSyncRegiTerminate ServiceReq) signal IPAC_IP_SYNC_REGI_AUDIT_REQ ( IpacIpSyncRegiAuditReq) signal IPAC_IP_SYNC_REGI_AUDIT_READY_IND ( IpacIpSyncRegiAuditReadyInd) Signalerna kan med fördel även beskrivas i ett sekvensdiagram om man vill få en överblick i vilken ordning de skickas. Jag har dock inte gjort det här Test i verklig miljö För att verkligen kunna testa systemet i den verkliga testmiljön där det redan existerade en textbaserad klientsimulator tog jag bort Client ur modellen och sparade bara Server. Serverklassen är här även försedd med ett externt interface. Detta är för att Serverklassen ska kunna kommunicera med omgivningen. Interfacet finns inbyggt i TAU och kallas ENV. Hur det fungerar beskrivs nedan. Kvar i klassdiagrammet fanns följande: Klassen Server med en port och det externa interfacet ENV. 22

29 6.5. Omgivningen Då utvecklingen av kod inte längre är lika ansträngande kan omgivningen och integrationen bli den del i utvecklingsprocessen som blir mer komplicerad. Detta beror till största del på att man vill kunna kommunicera med omgivningen på något sätt. Utan omgivning har inte systemet någon större mening. Som man kan se i modellen nedan måste man från modellen gå genom skiktet ENV för att kunna nå omgivningen. ENV är alltså ett slags lager som tar in signaler från modellen och översätter dessa till signaler som omgivningen kan förstå. 23

30 För att det här ska fungera måste man programmera den här översättningen själv vilket är naturligt då omgivningen kan variera och det i dagsläget vore omöjligt att göra en kodgenerator som stöder alla typer av omgivningar. Problemet kvarstår dock att man måste arbeta traditionellt i det här skiktet. Det behöver dock inte vara särskilt komplicerat. Det genereras så kallade environment-filer vid kodgenereringen som innehåller alla signaler från UML-modellen. Till dessa finns en annan väldigt viktig fil - env_defs.h. I denna överför man i en while-loop UML-signalerna till motsvarigheter i omgivningen. ENV är i mitt exempel ett interface mot realtidsoperativsystemet OSE ( Operating System Embedded ), men det skulle kunna vara något helt annat, till exempel ett databasinterface, eller någon annan omgivning som inte kan modelleras (Executable UML 2002, s.30) Sammanfattning av modellen Utöver de diagram som jag har beskrivit ovan behövs bara två saker för att kunna generera körbar kod. Den första är en tråd för servern men i det fallet att man endast har en aktiv klass så finns det alltid en implicit inlagd tråd i TAU. I min modell är den dock angiven för syns skull. Det andra som behövs är en artefakt. Denna är knuten till någon form av kompilator. I min modell har jag två artefakter. Den ena är kopplad till en AgileC-kompilator och den andra är knuten till Model-Verifier som är en inbyggd testsimulator. Artefakterna är angivna i ett Deployment Diagram på detta sätt: package SyncRegi SyncRegi Deployment Diagram {3/4} <<artifact,'agilec Code Generator'>> AgileC t1 <<artifact,thread>> mythread1 <<manifest>> IPSyncRegi <<manifest>> <<artifact,'model Verifier'>> ModelVerifier t2 <<artifact,thread>> mythread2 För att sammanfatta kort: De element som krävs för kodgenerering i TAU är: Klassdiagram med minst en aktiv klass, tillståndsmaskin till den aktiva klassen, tråd kopplad till den aktiva klassen 24

31 samt en artefakt kopplad till den aktiva klassen. Man kan direkt dra slutsatsen att man inte behöver hela UML för att kunna generera kod. Det räcker med en delmängd av UML. Exakt vilka delar som ingår för Executable UML är inte i dagsläget definierat (Executable UML 2002, s9.). Varje tillverkare bestämmer själv vilka element som måste ingå. Det som jag har räknat upp ovan är alltså det som gäller för TAU. Vill man ha flera aktiva klasser går det bra men man behöver då också ha flera trådar en för varje. Dessutom behövs även en tillståndsmaskin för varje aktiv klass. Denna kan dock vara väldigt enkel. Man kan också binda en artefakt till flera aktiva klasser. Givetvis finns det många andra användbara diagram och TAU stöder UML 2.0 fullt ut. Exempel på sådana andra diagram är: Use Case-diagram, Sekvensdiagram, Compostite Structure-diagram och Aktivitetsdiagram. Har man ett väldigt stort system kan det bli förvirrande att beskriva alla interface och kopplingar i ett klassdiagram. Då kan man med fördel använda ett Composite Structure-diagram Resultat Efter kompilering finns det ett fungerande IPSyncRegi. Servern svarar på de signaler man skickar och hanterar de nödvändiga parametrarna. Även om den nya genererade koden inte har någonting gemensamt med den ursprungliga, handskrivna koden är systemets funktioner likadana: Det har fungerat väl att modellera, generera, inkludera omgivningen, och att använda de genererade filerna i byggmiljön. 7. Hur fungerar MDA/Executable UML jämfört med traditionell utveckling? Det är inte det fungerande programmet i sig som är intressant utan det är vägen dit. Jag har utan några större förkunskaper använt en alternativ utvecklingsmetod genom att skapa en modell, gjort kopplingar mot OSE, samt byggt ihop med byggmiljön och den existerande simulatorn. Detta tyder på att modellbaserad utveckling och kodgenerering är ett effektivt sätt att arbeta. Det kan tyckas som att man tar väldigt god tid på sig i början men när väl modellen är klar så går allting väldigt fort. Min åsikt är att det antagligen hade tagit mig längre tid att utveckla IPSyncRegi på traditionellt sätt, och man skulle då också förlora den fördelaktiga översikt och dokumentation som modellen ger. Exemplet med IPSyncRegi visar att det är möjligt att redan idag att generera körbar kod direkt ur modellen. Trots detta har jag svårt att se att MDA /Executable UML kommer att få ett stort genombrott i den närmsta framtiden. 25

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

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik UML 1(5) Introduktion till Unified Modeling Language 1 Bakgrund och historik UML är ett objektorienterat modellspråk för att specificera och visualisera system. Det är framtaget i första hand för IT-orienterade

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

UML 2.0 och dess roll för modellbaserad utveckling

UML 2.0 och dess roll för modellbaserad utveckling UML 2.0 och dess roll för modellbaserad utveckling Morgan Björkander Senior Methods Engineer mbj@telelogic.com 1 Telelogic AB Agenda UML 2.0 översikt översikt nya språkkonstruktioner Modellbaserad utveckling

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

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

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

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

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document Programutvecklingsprojekt 2003-04-24 Projektgrupp Elvin Detailed Design Document Björn Engdahl Fredrik Dahlström Mats Eriksson Staffan Friberg Thomas Glod Tom Eriksson engdahl@kth.se fd@kth.se d94-mae@nada.kth.se

Läs mer

Objektorienterad programmering, allmänt

Objektorienterad programmering, allmänt Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 juni 2005 1 Vilka egenskaper vill vi att program ska ha? Förslag (en partiell lista): De ska... gå snabbt att skriva vara

Läs mer

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha?

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha? Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 mars 2005 1. Korrekthet 2. Robusthet 3. Utökbarhet 4. Återanvändbarhet 5. Kompatibilitet

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

Symptom på problemen vid programvaruutveckling

Symptom på problemen vid programvaruutveckling eller Varför är det bättre med halsbränna i början av ett projekt än i slutet? Eva Hådding ehadding@rational.com Symptom på problemen vid programvaruutveckling Användarnas och verksamhetens behov ej uppfyllda

Läs mer

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

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

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design RE SD PD I UT IT ST AT Mjukvarudesign System Requirement Specification Inkrementell och iterativ! Konceptuell design (VAD) Systemdesign (OOA) Arkitekturell (grovkornig, UML) Teknisk design (HUR) Programdesign

Läs mer

Designmönster, introduktion. Vad är det? Varför skall man använda mönster?

Designmönster, introduktion. Vad är det? Varför skall man använda mönster? Designmönster, introduktion. Vad är det? Varför skall man använda mönster? Kent Petersson EMW, Mölndal Datavetenskap, Chalmers epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.se/~kentp

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

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

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language Ett modelleringsspråk : Exempel Fönster Klassnamn Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar hur mjukvaror skapas, anpassas och utvecklas samt programmeringens roll i informationstekniska sammanhang som datorsimulering och praktisk datoriserad problemlösning.

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

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

SKOLFS. beslutade den XXX 2017.

SKOLFS. beslutade den XXX 2017. 1 (11) Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning

Läs mer

TDP005. Föreläsning 3 - UML. Filip Strömbäck

TDP005. Föreläsning 3 - UML. Filip Strömbäck TDP005 Föreläsning 3 - UML Filip Strömbäck 1 Introduktion 2 Diagram 3 Klassdiagram 4 Sekvensdiagram 5 SFML-demo TDP005 Filip Strömbäck 2 UML Unified Modeling Language Visuell notation för idéer Kommunicera

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

DD2385 Programutvecklingsteknik Några bilder till föreläsning 1 24/ Kursöversikt Javarepetition/Javaintroduktion

DD2385 Programutvecklingsteknik Några bilder till föreläsning 1 24/ Kursöversikt Javarepetition/Javaintroduktion DD2385 Programutvecklingsteknik Några bilder till föreläsning 1 24/3 2014 Innehåll Kursöversikt Javarepetition/Javaintroduktion UML - klassdiagram-introduktion i anslutning till Java-exemplen Kursmål,

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

Arkitektur Michael Åhs

Arkitektur Michael Åhs Arkitektur Michael Åhs Kalle & Hobbe: En utvecklares drömsystem 1. Vad är arkitektur? 2. Arkitektur i UML Innehåll 3. Utveckla en arkitektur 4. Arkitektur i projektet Del 1 - Vad är Arkitektur? Pattern-Oriented

Läs mer

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Datavetenskap Opponent(er): Jhonny Carvajal Johan Bjärneryd Respondent(er): Fredrik Häggbom Erik Olsson Haglund Scrumptious - A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Oppositionsrapport,

Läs mer

Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering...

Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering... Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering... 4 Bussen (projektförslag)... 5 Bakgrund... 5 Klassen Buss

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

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? TDDD78, TDDE30, jonas.kvarnstrom@liu.se 729A85 jonas.kvarnstrom@liu.se

Läs mer

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018

Static vs Dynamic binding Polymorfism. Objekt-orienterad programmering och design (DIT953) Niklas Broberg, 2018 Static vs Dynamic binding Polymorfism Objekt-orienterad programmering och design (DIT95) Niklas Broberg, 2018 Diagnostiskt prov Shape + overlaps(shape): int return 1; Shape shape = new Shape(); Polygon

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

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 17 juni 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Föreläsning 4 IS1300 Inbyggda system

Föreläsning 4 IS1300 Inbyggda system Föreläsning 4 IS1300 Inbyggda system Programutveckling Exempel PingPong Idé Tillståndsdiagram State machine Skapa projekt Testning av programvara Peripheral Library till STM32 Programmeringsuppgiften RS232

Läs mer

Universe Engine Rapport

Universe Engine Rapport 1 Universe Engine Rapport Alexander Mennborg 2017-05-08 2 Inledning I denna rapport diskuteras utvecklingsprocessen till projektet Universe Engine. Denna diskussion omfattar hela utveckling från starten

Läs mer

Användning av modeller för system/produktutveckling

Användning av modeller för system/produktutveckling Användning av modeller för system/produktutveckling Lars Wiktorin, IT plan lars.wiktorin@itplan.se 1 Disposition Modellbegreppet Användningsområden Att välja modeller Mottagare Krav För system/produktutveckling

Läs mer

RUP Rational Unified Process. 17 november 2004

RUP Rational Unified Process. 17 november 2004 RUP Rational Unified Process 17 november 2004 RUP Volvo Information Technology, Eva Hådding Volvo Information Technology Volvo IT ingår i Volvo-koncernen Volvo Lastvagnar Volvo Bussar Volvo Anläggningsmaskiner

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Arbeta med databas. Översikt. Lektion 1: Arbeta med Entity Data Models. Arbeta med Entity Data Models. LINQ (Language Integrated Query).

Arbeta med databas. Översikt. Lektion 1: Arbeta med Entity Data Models. Arbeta med Entity Data Models. LINQ (Language Integrated Query). Arbeta med databas Översikt Arbeta med Entity Data Models. LINQ (Language Integrated Query). Lektion 1: Arbeta med Entity Data Models Introduktion till ADO.NET Entity Framework. Stöd i ADO.NET Entity Framework.

Läs mer

Semantic and Physical Modeling and Simulation of Multi-Domain Energy Systems: Gas Turbines and Electrical Power Networks

Semantic and Physical Modeling and Simulation of Multi-Domain Energy Systems: Gas Turbines and Electrical Power Networks DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2017 Semantic and Physical Modeling and Simulation of Multi-Domain Energy Systems: Gas Turbines and Electrical Power

Läs mer

HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN)

HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN) Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061) HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN) Dagens agenda Admin Tentatid och plats Tillåtet på tentan EDAF10 Föreläsning inför XL-projektet

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

Introduktion till programmering. Programspråk och paradigmer

Introduktion till programmering. Programspråk och paradigmer Introduktion till programmering Programspråk och paradigmer Vad är ett programspråk? Aprogramming languageis a formal constructedlanguagedesigned to communicate instructions to a machine, particularly

Läs mer

Programmerbar logik (PLD) Programmeringsspråket VHDL Kombinatoriska funktioner i VHDL för PLD Sekvensfunktioner i VHDL för PLD

Programmerbar logik (PLD) Programmeringsspråket VHDL Kombinatoriska funktioner i VHDL för PLD Sekvensfunktioner i VHDL för PLD UMEÅ UNIVERSITET Tillämpad fysik och elektronik Digitalteknik Håkan Joëlson 2003-09-15 v 2.1 DIGITALTEKNIK Laboration D163 Programmerbar logik (PLD) Programmeringsspråket VHDL Kombinatoriska funktioner

Läs mer

Programmering i C++ Kompilering från kommandoraden

Programmering i C++ Kompilering från kommandoraden Programmering i C++ Kompilering från kommandoraden Sven Gestegård Robertz Datavetenskap, LTH 9 november 2015 Sammanfattning Ibland vill man, av olika anledningar, inte använda en stor integrerad utvecklingsmiljö

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

Copyright Syntell AB 1

Copyright Syntell AB 1 Systemmodellering med SysML SESAM seminarium 2006-05-31 Erik Herzog Ansats Presentation av SysML från två perspektiv Akademiskt Industriellt Bakgrund Översikt Utvärdering Copyright Syntell AB 1 SysML SysML

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

DIGITALTEKNIK. Laboration D172

DIGITALTEKNIK. Laboration D172 UMEÅ UNIVERSITET Tillämpad fysik och elektronik Digitalteknik Håkan Joëlson 2006-02-24 v 1.2 DIGITALTEKNIK Laboration D172 Programmerbar logik (PLD) Programmeringsspråket VHDL Kombinatoriska funktioner

Läs mer

Läs detta! Uppgifterna är inte avsiktligt ordnade efter svårighetsgrad. Skriv ditt idnummer på varje blad (så att vi inte slarvar bort dem).

Läs detta! Uppgifterna är inte avsiktligt ordnade efter svårighetsgrad. Skriv ditt idnummer på varje blad (så att vi inte slarvar bort dem). 1 (11) TENTAMEN: Objektorienterade applikationer Läs detta! Uppgifterna är inte avsiktligt ordnade efter svårighetsgrad. Börja varje uppgift på ett nytt blad. Skriv ditt idnummer på varje blad (så att

Läs mer

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

UML. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 UML Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 UML Unified Modelling Language Grafiskt modelleringsspråk för att beskriva olika aspekter av objektorienterade system. Vi kommer

Läs mer

729G75: Programmering och algoritmiskt tänkande. Tema 1. Föreläsning 1 Jody Foo

729G75: Programmering och algoritmiskt tänkande. Tema 1. Föreläsning 1 Jody Foo 729G75: Programmering och algoritmiskt tänkande Tema 1. Föreläsning 1 Jody Foo Föreläsningsöversikt Kursinfo / Om kursen Algoritmer Objektorienterad programmering i praktiken terminologi använda objekt

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

729G75: Programmering och algoritmiskt tänkande. Tema 1, föreläsning 1 Jody Foo

729G75: Programmering och algoritmiskt tänkande. Tema 1, föreläsning 1 Jody Foo 729G75: Programmering och algoritmiskt tänkande Tema 1, föreläsning 1 Jody Foo Föreläsningsöversikt Kursinfo / Om kursen Algoritmer Objektorienterad programmering i praktiken terminologi använda objekt

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

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

+5V. start. Styrsystem. stopp. Tillståndsmaskiner

+5V. start. Styrsystem. stopp. Tillståndsmaskiner Tillståndsmaskiner Beteendet hos en stor klass av tekniska system kan beskrivas, modelleras, med tillståndsmaskiner. En tillståndsmaskin är en sekvens av tillstånd som beror av händelser och som ger olika

Läs mer

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram Analys och design med hjälp av CRC 83 Klassdiagram Objekt Ett objekt är en individuellt identifierbar entitet som kan vara konkret eller abstrakt. Ett objekt har tillstånd, beteende och identitet. Reellt,

Läs mer

UML. Klassdiagr. Abstraktion. Relationer. Överskugg. Överlagr. Aktivitetsdiagram Typomv. Typomv. Klassdiagr. Abstraktion. Relationer.

UML. Klassdiagr. Abstraktion. Relationer. Överskugg. Överlagr. Aktivitetsdiagram Typomv. Typomv. Klassdiagr. Abstraktion. Relationer. Översikt Klasshierarkier UML klassdiagram Relation mellan klasser mellan klasser och objekt Association ning ing andling Programmering tillämpningar och datastrukturer 2 UML UML Unified Modeling Language

Läs mer

Fyra i rad Javaprojekt inom TDDC32

Fyra i rad Javaprojekt inom TDDC32 Fyra i rad Javaprojekt inom TDDC32 Analys och design-dokument Version 2.0 Datum 2008-05-19 Dokumentnummer 20080303 Sammanfattning Detta är analys och design-dokumentet för programmet Fyra i rad. Fyra i

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

Datavetenskapligt program, N1COS

Datavetenskapligt program, N1COS Ansökan om fortsatta studier inom program, våren 2015 Datavetenskapligt program, N1COS Inför varje termin måste du söka till de kurser du vill gå. Sista datum för ansökan till höstens kurser är den 15

Läs mer

Kursplan. MT1051 3D CAD Grundläggande. 7,5 högskolepoäng, Grundnivå 1. 3D-CAD Basic Course

Kursplan. MT1051 3D CAD Grundläggande. 7,5 högskolepoäng, Grundnivå 1. 3D-CAD Basic Course Kursplan MT1051 3D CAD Grundläggande 7,5 högskolepoäng, Grundnivå 1 3D-CAD Basic Course 7.5 Higher Education Credits *), First Cycle Level 1 Mål Studenten ska efter avslutad kurs ha inhämtat grunderna

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

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

Webbserverprogrammering

Webbserverprogrammering Webbserverprogrammering WES Webbserverprogrammering Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets

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

Programmering = modellering

Programmering = modellering Programmering = modellering Ett datorprogram är en modell av en verklig eller tänkt värld. Ofta är det komplexa system som skall modelleras I objektorienterad programmering består denna värld av ett antal

Läs mer

Översikt. Programmering tillämpningar och datastrukturer. Vad kursen täcker. Lärare. Rekommenderad litteratur. Kursmål 729G58 (HKGBB7)

Översikt. Programmering tillämpningar och datastrukturer. Vad kursen täcker. Lärare. Rekommenderad litteratur. Kursmål 729G58 (HKGBB7) Översikt Programmering tillämpningar och datastrukturer 729G58 (HKGBB7) Kursinformation Objektorienterad programmering: Klasser och objekt Arv Polymorfism Metoder Programexempel Programmering tillämpningar

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

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

TUTORIAL: KLASSER & OBJEKT

TUTORIAL: KLASSER & OBJEKT TUTORIAL: KLASSER & OBJEKT I denna tutorial lär vi oss att använda klasser och objekt samt hur vi bygger en enkel applikation kring dessa. I tutorialen kommer det finnas en mängd kod som du antingen kan

Läs mer

Objektorientering Användning

Objektorientering Användning Objektorientering Användning Samt repetition av klasser Suzana Ramadani 1 Repetition Objektorientering bygger på Abstraktion Hierarkisk strukturering Inkapsling Klassificering Generalisering specialisering

Läs mer

+5V. start. Styrsystem. stopp. Tillståndsmaskiner

+5V. start. Styrsystem. stopp. Tillståndsmaskiner Tillståndsmaskiner Beteendet hos en stor klass av tekniska system kan beskrivas, modelleras, med tillståndsmaskiner. En tillståndsmaskin är en sekvens av tillstånd som beror av händelser och som ger olika

Läs mer

Web Services. Cognitude 1

Web Services. Cognitude 1 Web Services 1 Web Services Hur ska tillämpningar integreras? Hur ska tillämpningar integreras (via nätet ) för att erbjuda tjänster åtkomliga på nätet? SVAR: Web Services (Enligt Microsoft, Sun, IBM etc.)

Läs mer

Tjoho. Applikationsutvecklarens handledning. Maj 2003

Tjoho. Applikationsutvecklarens handledning. Maj 2003 Tjoho Applikationsutvecklarens handledning Maj 2003 Uppdragsgivare: Ylva Dalén, KI Starthus Projektmedlemmar: Sophia Demnert, Elina Eriksson, Kamilla Johansson Per-Jonny Käck, Ingela Linered, Åsa Moum,

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

SKOLFS. beslutade den -- maj 2015.

SKOLFS. beslutade den -- maj 2015. SKOLFS Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan och inom kommunal vuxenutbildning på gymnasial nivå; beslutade den -- maj

Läs mer

Grafiska användargränssnitt i Java

Grafiska användargränssnitt i Java jonas.kvarnstrom@liu.se 2017 Grafiska användargränssnitt i Java En genomgång av de viktigaste begreppen Alternativ 2 Från början fanns AWT, Abstract Window Toolkit Till stor del ersatt av Swing: Mer omfattande,

Läs mer

Verktyg och Utvecklingsmiljö. Föreläsning 2 Eclipse

Verktyg och Utvecklingsmiljö. Föreläsning 2 Eclipse Verktyg och Utvecklingsmiljö Föreläsning 2 Eclipse Verktyg Modern programutveckling innebär att man måste behärska ett antal verktyg. Editorer Kompilatorer Avlusare(debugger) Versionshantering(kommer i

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

emopluppen Användning av "Ant" Niklas Backlund Version: 1.4 ( 2002/04/26 07:27:52 UTC)

emopluppen Användning av Ant Niklas Backlund Version: 1.4 ( 2002/04/26 07:27:52 UTC) emopluppen Användning av "Ant" Version: 1.4 ( 2002/04/26 07:27:52 UTC) Niklas Backlund Sammanfattning Det här dokumentet handlar om programmet Ant, som är en byggmiljö för programutvecklingsprojekt. Dess

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

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

Verktyg och Utvecklingsmiljö. Jochim von Hacht

Verktyg och Utvecklingsmiljö. Jochim von Hacht Verktyg och Utvecklingsmiljö Jochim von Hacht Verktyg Modern programutveckling innebär att man måste behärska ett antal verktyg Editorer Kompilatorer Avlusare (debugger) Versionhantering (kommer i projektkurs)

Läs mer

Vad kännetecknar en god klass. Vad kännetecknar en god klass. F12 Nested & Inner Classes

Vad kännetecknar en god klass. Vad kännetecknar en god klass. F12 Nested & Inner Classes Vad kännetecknar en god klass F12 Nested & En odelad, väldefinierad abstraktion Uppgiften kan beskrivas kort och tydlig Namnet är en substantiv eller adjektiv som beskriver abstraktionen på ett adekvat

Läs mer

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg Programmering Seminarier i datavetenskap, datorteknik och informationsteknik Niklas Broberg niklas.broberg@chalmers.se 2018-09-27 Hur många från Datavetenskap? Datateknik? Informationsteknik? Översikt

Läs mer

Föreläsning 2. Operativsystem och programmering

Föreläsning 2. Operativsystem och programmering Föreläsning 2 Operativsystem och programmering Behov av operativsystem En dator så som beskriven i förra föreläsningen är nästan oanvändbar. Processorn kan bara ges enkla instruktioner såsom hämta data

Läs mer

Arv och polymorfism i Java

Arv och polymorfism i Java 1 (5) Arv och polymorfism i Java Objektorienterad programmering 5 Syfte Att ge en introduktion till arvsmekanismen i Java. Mål Efter övningen skall du kunna definiera klasser med arv i Java. förstå hur

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

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 June 22, 2006 en systematisk metod för att gå från problembeskrivning till färdigt

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

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg Programmering Seminarier i datavetenskap, datorteknik och informationsteknik Niklas Broberg niklas.broberg@chalmers.se 2017-09-21 Hur många från Datavetenskap? Datateknik? Informationsteknik? Översikt

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

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Software Technology. Josef Svenningsson

Software Technology. Josef Svenningsson Software Technology Josef Svenningsson Software Technology Software Technology Området Software Technology handlar i mångt och mycket om följande frågeställning: Hur designar man programmeringsspråk för

Läs mer

Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic

Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic Inledning Starta Microsoft Visual Studio 2005. Välj create Project Välj VB + Vindows Application och välj ett nytt

Läs mer