Våra erfarenheter av Modellbaserad systemutveckling
2
Komplexa system kräver större överblick De system vi utvecklar idag tenderar att bli alltmer komplexa och programvaruintensiva. Att utveckla och underhålla dem kräver att ett stort antal människor samarbetar och har en gemensam bild av systemet. De behöver därför beskrivas på ett enkelt och tydligt sätt. När man förlorar överblicken under utvecklingsarbetet inträffar ofta otrevliga överraskningar. För att kunna handskas med detta behövs bra och effektiva metoder och verktyg. Modellbaserad utveckling MBSE är en metod för att hålla ihop ett system genom hela utvecklingen. Denna skrift ger en introduktion till MBSE och dess för- och nackdelar. Modellbaserad systemutveckling MBSE (Model Based Systems Engineering) är ett begrepp som förekommer i många varianter 1. En svensk översättning skulle kunna vara modellbaserad utveckling. Som metod tillhör MBSE nästa generation efter dagens objektorienterade programspråk, på samma sätt som dessa var generationen efter funktionella språk. Modellbaserad utveckling innebär att all konstruktionsinformation samlas i en uppsättning sammanhängande modeller av systemet. Modellerna beskrivs i ett mestadels grafiskt modelleringsspråk såsom UML 2. Kod och eventuella dokument genereras utifrån modellerna och är således endast temporär information som inte behöver sparas utan tas fram när den behövs för en granskning eller ett systembygge. 1 Till exempel Model-Driven Development (MDD) och Model-Driven Engineering (MDE). 2 Unifi ed Modeling Language 3
Fördelar med MBSE Modellbaserad utveckling erbjuder ett antal fördelar. Exempelvis slipper man skapa och underhålla många, delvis överlappande, informationsmängder i form av dokument, modeller och kod. Detta gör att man dels sparar tid i utvecklings- och underhållsarbetet och dels reducerar antalet felkällor i och med att man slipper många manuella transformationer mellan olika representationsformer t ex övergång från krav till design. Ett MBSE-verktyg kan ge stöd till att ständigt hålla informationen konsistent, såväl som till att beskriva flera abstraktionsnivåer. Möjligheten att med dagens MBSE-verktyg skapa exekverbara modeller ökar benägenheten att tidigt testa systemet flera gånger per dag, ibland flera gånger per timme. Detta gör att man har bra kontroll på statusen i utvecklingsarbetet. Fel kan upptäckas mycket tidigt, vilket minskar risken för förseningar eftersom tiden för att åtgärda ett fel ökar kraftigt ju senare det upptäcks. Det innebär också att all logik i systemet kan testas utan tillgång till systemets övriga delar. dimensionering analys modell Figur 1 dokument Modellen som huvudsaklig informationsbärare kod 4
Dokumentbaserad utveckling Modellbaserad utveckling konstruktion konstruktion konstruktion Utveckling transformation konstruktion konstruktion transformation konstruktion konstruktion ändring ändring Underhåll transformation transformation Figur 2 Förenklat arbetsfl öde med modellbaserad utveckling - modellen blir produkten 5
Ytterligare fördelar med modellbaserad utveckling är att: en visuell beskrivning av hela systemet främjar kommunikationen och förståelsen för systemet. Alla får en gemensam bild och det blir större fokus på arkitekturen. Exempel: eftersom notationen är grafisk och lätt att förstå kan även en icke SysML 3 - expert ändå ta till sig block- och sekvensdiagram och resonera kring kravbilden. Nej, jag hade tänkt mig att den här rutan skulle prata med den här rutan eller Oj, det där har jag inte tänkt på, låt mig rota fram vilka kraven faktiskt är här. utvecklingen blir snabbare och billigare då repetitiva och felbenägna manuella moment i programmeringsarbetet automatiseras. det blir lättare att hantera komplexitet genom att systemet kan ses från olika vyer. Det blir också lättare att analysera vilka konsekvenser ändringar i systemet får. det är enklare och effektivare att göra omkonstruktioner av systemet. spårbarhet enkelt kan skapas mellan krav, design, integration och test, eftersom dessa finns samlade i ett och samma verktyg. Utvecklingen leder slutligen till att modellen är systemet, dvs en ändring i modellen slår igenom både i dokumentation och realisering (tex kod). Jag har mycket bättre koll på vad mina projektkollegor håller på med nu. Elisabeth Strandberg, systemutvecklare på Saab Training Systems 3 System Modeling Language 6
Effektivitet / Kvalitet Förbättrad d ign Bättre överblick Lätt att kommunicera Förenklad granskning Ökad konsistens Förenklad dokumentation Förenklad implementation Minskad risk för regr ion Ökad säkerh vid ändringar Grafisk notation Integrerade t ter Kodgenerering Integrerad dokumentation Figur 3 7
Svårigheter med MBSE En aspekt som kan försvåra användandet av modellbaserad utveckling är när modellspråket har begränsningar som gör att det inte går att modellera alla relevanta egenskaper i tänkbara produkter. En annan aspekt är att verktygen ibland implementerar endast en delmängd av det totala modellspråket. Om t ex modellspråket är UML, så kanske verktyget endast implementerar nio av de tretton beskrivna diagramtyperna, med fattigare uttrycksmöjligheter som konsekvens. Vissa modellspråk och verktyg saknar helt eller delvis möjligheter att styra kodgenerering och därigenom optimera koden i tillräcklig utsträckning. Det är också viktigt att påminna sig om att det alltid finns kunskap i systemutvecklingsarbetet som aldrig kommer att kunna fångas i ett verktyg. 8
Vad krävs för att lyckas? Traditionella framgångsfaktorer för all systemutveckling gäller även för MBSE, men med skillnaden att arbetet kan utföras på ett effektivare sätt. Särskild uppmärksamhet krävs på följande områden: Metodik Goda kunskaper krävs i modellspråkets grundprinciper, t ex objektorienterad analys och design för UML. Gamla kunskaper om hur man gör en objektorienterad analys och design gäller därför, kanske i än högre grad, när modellen är systemet. Systemarkitektur Att ett system har en väl genomarbetad arkitektur har visat sig vara en av de viktigaste framgångsfaktorerna för ett system. Vi räknar med att öka effektiviteten i systemutvecklingen med 30 procent. Niclas Vilsek, chef för systemutvecklingsavdelningen på Saab Training Systems Utvecklingsprocess Modellbaserad utveckling innebär att dokument och kod försvinner (eller blir mellanprodukter) och att traditionella aktiviteter förändras eller försvinner. Detta innebär att utvecklingsprocessen måste definieras i termer av modellstatus i stället för i aktiviteter och dokument. Modellstruktur För att kunna styra och samordna utvecklingsarbetet krävs en tydligt definierad modellstruktur. Denna definierar vilka modeller som ska tas fram, vad dessa beskriver, vad de ska användas till, hur de ska modelleras och hur de är kopplade till varandra. Regler för diagramanvändning Eftersom modellerna beskrivs genom antal diagram av olika typer, och det är upp till användaren vad som visas av modellen i ett visst diagram, så krävs strikta regler för diagramanvändningen för att man ska kunna 9
läsa och förstå modellen. Ett delsystems gränssnitt utåt bör exempelvis modelleras i en uppsättning diagram och dess inre struktur i en annan. Dessa regler motsvarar programmeringens kodningsregler. Verktyg För effektiv modellbaserad utveckling krävs ett verktyg där man kan bygga, undersöka och helst exekvera modeller beskrivna i exempelvis UML. Verktyget bör med fördel kunna generera exekverbar kod till slutprodukten och vid behov även rapporter. Det räcker dock inte med att skaffa sig ett verktyg för att lyckas med MBSE. Hur inför man MBSE? Då man startar med modellbaserad utveckling i ett skarpt projekt behöver projektdeltagarna förberedas med grundläggande kunskaper i MBSE, modellspråket och den metodik som ska användas. Det är även viktigt att projektets milstolpar planeras i termer av modelleringsaktiviteter istället för producerade dokument. Projektet inleds lämpligen med att en mindre grupp MBSE-kunniga definierar systemets krav och arkitektur. När projektet sedan breddas utbildas deltagarna vid behov i specifika arbetsmoment allt eftersom dessa blir aktuella i projektet (JIT i figuren bredvid). Satsa på skarpa utvecklingsprojekt För att successivt sprida erfarenhetsbaserad kunskap och förfina arbetssättet så bör man införa modellbaserad utveckling i skarpa utvecklingsprojekt. I projekten tränas utvecklare och projektledare i metodik och 10
verktyg. Kurser ger den teoretiska grunden att stå på men sedan krävs tillämpning i verkliga projekt för att man ska bli kompetent nog att arbeta självständigt med MBSE. projektet en mentor som stödjer och leder utvecklarna. För att åstadkomma erfarenhetsöverföring mellan projekten bör utvecklare från tidigare projekt delta i projektet. Utse en mentor För att inte projektet ska riskera att hamna snett under denna träning så bör man tilldela UML för oerfarna Modelleringsverktyg Arkitektur Byggmiljö Just In Time seminarier, 2-4 timmar, synkroniseras med tunga pågående projektaktiviteter, ex. Arkitektur, Mönster, Test och teststrategier, CM, principer för baselines kurser JIT JIT JIT JIT utvecklingsarbete Mentorstöd (Arkitektur, Metodik, Utvecklingsmodell, Verktygskedja...) Figur 4 Strategi för lyckat införande 11
Vanliga fallgropar Att införa MBSE är en genomgripande förändring i de flesta organisationer och projekt. Beroende på hur man har arbetat tidigare kan de nya metoderna och principerna vara mer eller mindre främmande för utvecklare och projektledare. I den övergången har vi sett att det finns ett antal fallgropar att undvika: 1. Ett förändrat arbetssätt förankras inte Som allt förändringsarbete måste även MBSE säljas in på alla nivåer. Glöm inte de informella ledarna. Konsekvenserna kan annars bli ödesdigra. arbetsmetoder kommer det att dröja en tid innan produktiviteten når upp till den tidigare nivån. Missar man att genomföra denna utbildning kommer projektet att lida av det under onödigt lång tid in i utvecklingsfasen. En bristande utbildning kan även leda till missnöje hos utvecklarna som: Jag vet hur jag ska göra det i C++, men nu måste jag göra det i UML, det tar mycket längre tid. Denna typ av missnöje leder till frustration och allmänt sämre resultat. 2. Bristfällig utbildning MBSE inför ett antal nya principer för utvecklingen, samt metoder för att genomföra dessa. Dessutom tillförs ett flertal nya verktyg som utvecklarna måste bemästra. Allt detta tar viss tid att etablera och kräver en utbildningsinsats i samband med införandet. Som vid alla införanden av nya verktyg och
3. Dålig anpassning till nytt arbetssätt MBSE ger bra resultat om det stöds av utvecklingsprinciper som passar arbetssättet. Att inte anpassa utvecklingsprocesser så att de stödjer de nya verktygen och metoderna kan leda till att hela arbetet haltar. Vanliga fallgropar kan t ex vara att hålla fast vid en dokumentcentrerad utvecklingsprocess som tvingar fram skrivande av dokument som täcker samma information som redan finns i modeller. 4. Bristfällig support Ett bra recept på problem är att inte ta med i beräkningen att införandet av en ny metod kommer att kräva stöd. Man kommer att behöva support från verktygsleverantörer och från experter som har infört MBSE tidigare. Stödet behöver vara tillgängligt under projektets hela livscykel. 5. För få verktygslicenser De flesta kommersiella MBSE-verktyg har höga licenskostnader och det kan vara frestande att vara sparsam med de nödvändiga licenserna. Det är dock sällan en väg till tidsvinster och därför inte heller till några ekonomiska vinster i det långa loppet. 6. Bristande konstruktionsvägledning Alla projekt som använder MBSE måste bestämma vilka diagram som ska användas för att beskriva vissa situationer. Annars kan resultatet bli en spretig beskrivning av systemet. 13
Dessutom kan det med de nya möjligheter som ett MBSE-verktyg erbjuder vara frestande att använda alla mekanismer, även när man kanske inte är helt säker på deras funktion. Detta kan vara en väg mot problem. Underskatta alltså inte vikten av att styra användandet av ditt MBSE-verktyg. arbetsflöde där arkitekten ska granska alla konstruktionslösningar kan därför leda till en flaskhals när arkitekten inte hinner med. Liknande situationer kan t ex uppstå vid test. Man behöver helt enkelt vara beredd på att bemanningsfördelningen kan bli annorlunda i ett MBSE-projekt. 7. Överge text som beskrivningsform Det finns en risk att man tror sig kunna överge vanlig text när man modellerar, dvs tro att det räcker med att rita diagram. Diagrammen/modellelementen behöver kompletteras med beskrivningar i text. Utifrån dessa kan man sedan generera rapporter, om verktyget stöder det. Det går vanligtvis inte heller att fånga all dokumentation i de grafiska modelleringsverktygen, viss information behöver ofta skrivas som traditionella dokument (t ex kommunikationsprotokoll). 8. Nya flaskhalsar i bemanningen MBSE leder till att framför allt konstruktion och implementation blir mer effektiv, men även test- och underhållsfasen. Ett 9. Otydlig rollfördelning Även rollfördelningen mellan arkitekt och konstruktör kan bli annorlunda när alla arbetar med samma MBSE-metod och kanske även i samma modell. Man behöver då vara uppmärksam på hur rollerna fördelas och definieras. Det kan t ex vara frestande för arkitekten att lägga sig i mycket detaljerade konstruktionslösningar. 10. Verktyg skyddar inte mot missbruk Man blir inte automatiskt en bra designer bara för att man har ett kraftfullt MBSEverktyg. Inget verktyg förhindrar någon att utveckla spaghetti-liknande modeller. Det gäller som alltid att arbeta disciplinerat och strukturerat. 14
15
Kort om verktyg Verktygen kan delas in i huvudsakligen två grupper: strukturfokuserade och beräkningsfokuserade. Verktyg inriktade på struktur och beteende använder sig i regel av UML, SDL 4 eller liknande modelleringsspråk. Dessa är lämpade för att beskriva arkitektur, vilka systemdelar som finns och hur de är relaterade med varandra. Exempel på verktyg är: Artisan Realtime Studio, Bridgepoint, Enterprise Architect, MagicDraw, Rational Rose, Rhapsody, StateMate och Telelogic Tau. Verktyg inriktade på beräkningar är mer lämpade för att designa reglersystem och beräkna prestanda. De använder ofta ett verktygsspecifikt språk. Exempel på verktyg är: Dymola, MatLab/ Simulink, MatrixX/SystemBuild och SCA- DE. För att täcka båda områdena kan man alltså behöva integrera två verktyg med varandra. I vissa fall levereras denna integration med verktyget, t ex för Rhapsody, Simulink och SysML. Det är inte säkert att man klarar sig med endast ett verktyg för strukturfokuserad utveckling. Verktyg kan behöva kombineras med varandra, där ett verktyg kan vara starkt på grafisk modellering, ett annat på kodgenerering, ett tredje på felsökning på modellnivå (animering) och ytterligare ett för dokumentgenerering. Att integrera flera verktyg med varandra kan vara både svårt och kostsamt. 4 Specifi cation and Description Language 16
Verktygen har också varierande stöd för vilka målspråk de stöder, såsom C/C++/ Java/Ada. I vissa fall kan man styra reglerna för kodgenerering relativt fritt, i andra fall kan man bara göra begränsade ändringar. Ytterligare en parameter är vilka operativsystem verktygen stöder, om de går att anpassa till andra operativsystem eller om de går att köra helt utan. Viktiga frågor att ställa Verktyget använder i regel ett plattformsramverk (för tillståndsmaskiner, koppling till operativsystem etc) som blir en del av slutprodukten. Man bör försäkra sig om att ramverket uppfyller de krav man har med avseende på till exempel prestanda. Ett antal frågor bör därför ställas: Är det kvalificerat mot någon standard? Vad finns det för möjligheter att verifiera sin modell? Hur sker rapportgenerering ur modellen? Går det att felsöka modellen på grafisk nivå? Finns det inbyggda testverktyg? Finns det exempelvis testsviter för ramverket? Levereras ursprungsmodellen till ramverket (för inspektion, ändring eller omkompilering med annan kompilator)? 17
Att införa MBSE kräver ett nytt sätt att tänka och mycket hårt arbete, men vinsterna kommer att visa sig i form av effektivare systemutveckling. Göran Backlund, Combitech 18
Redaktion Göran Backlund Göran Carlzon Bodil Knuthammar Haider Shareef Skribenter Tobias Amnell Daniel Berggren Gert Johansson Anders Mattsson Björn Nilsson Andreas Rasmusson Stefan Romberg Magnus Skoog Remco Tissink Magnus Vesterlund Ulf Ärlig Produktion Erichs Communications och Negrete Marknadskommunikation Tryck Centraltryckeriet, Linköping 19
Combitech är ett obundet konsultföretag som med hög kompetens och kontinuitet skapar stor kundnytta genom att tillhandahålla värdefulla och innovativa lösningar som kombinerar teknik, miljö och säkerhet. Kunderna fi nns inom branscherna försvar, fl yg, telekom och säkerhet samt myndigheter med ansvar för skydd av fl öden i samhället. Närheten till våra kunder är viktig. Därför fi nns Combitech på ett 20-tal orter i Sverige och Europa. Vi är rut 800 medarbetare och ingår i Saabkoncernen - ett av världens ledande högteknologiska företag med huvudsaklig verksamhet inom försvar, fl yg och rymd. www.combitech.se