Mjukvaruverktyg för analys av satser i satslogiken inbäddade i XML ...
Click here to load reader
Transcript of Mjukvaruverktyg för analys av satser i satslogiken inbäddade i XML ...
Mjukvaruverktyg för analys av satser i satslogiken inbäddade i XML-filer
G O V A N M A R O U N S I
Examensarbete Stockholm, Sverige 2012
Mjukvaruverktyg för analys av satser i satslogiken inbäddade i XML-filer
G O V A N M A R O U N S I
DD245X, Examensarbete i datalogi om 30 högskolepoäng vid Magisterprogram, programvaruutveckling 60 högskolepoäng Kungliga Tekniska Högskolan år 2012 Handledare på CSC var Alexander Baltatzis Examinator var Olle Bälter TRITA-CSC-E 2012:076 ISRN-KTH/CSC/E--12/076--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc
Arbetet tillägnas till min far,
som har rest bakom evigheterna
Mjukvaruverktyg för analys av satser i
satslogiken inbäddade i XML-filer
Elektronikens intåg i fordonsindustri har lett till fordon med mer funktionalitet som även är mer
komplexa att felsöka. Därför erbjuder olika fordonstillverkare mjukvaruverktyg som hjälper
mekanikerna vid felsökning. Scania som är en pionjär i buss- och lastbilstillverkning har
utvecklat ett eget verktyg som kallas för SDP3 (Scania Diagnose & Programmer). Guidade
metoder är de underlag som utformas av metodingenjörerna på Scania och används vid
felsökning av mekanikerna genom SDP3. Guidade metoder utformas i form av XML-filer och
innehåller villkor som styr flödet i metoden och interaktionen med både mekaniker och fordon.
Guidade metoder och annan information transformeras med hjälp av ett internt verktyg (SDP3
Production Tool) till den databas som används i SDP3.
Villkoren i guidade metoder skapas genom jämförelser mellan olika variabler eller mellan
variabler och konstanta värden. Dessa jämförelser utförs med hjälp av relationsoperatorer.
Jämförelser kan kombineras med varandra med hjälp av logiska operatorer i satslogiken och det
är dessa jämförelser eller deras kombinationer som är villkoren i guidade metoder. Guidade
metoder kan vara relativt stora och villkoren kan vara för komplexa för att hanteras av
människor. Därför behövs ett verktyg för att möjliggöra test och analys av guidade metoder
innan de ska tas i bruk. Detta var examensarbetets mål.
I detta arbete har ett användargränssnitt med hjälp av HTML och XSLT utvecklats. Via detta
användargränssnitt kan metodingenjörerna mata in variablernas värde. Sedan evalueras
villkoren baserat på inmatade värde i ett ramverk som har skrivits i Java och resultatet av
evalueringen visas till metodingenjörerna. Kopplingen mellan användargränssnittet och
evalueringsramverket implementeras via ”Java-plugin Technology” även känt med namnet
Applet. Med hjälp av detta verktyg kan metodingenjörerna testa och analysera villkoren.
Software tool for test and analysis of predicates
in propositional logic, embedded within XML
files
Modern vehicles have been changed totally by the Electronic. They are being developed with
more and more functionality and the result is more difficult troubleshooting. Actually in most of
the cases troubleshooting cannot be performed without help of software tools. Scania as one of
the pioneers in producing buses and trucks uses its own software tool which is called SDP3
(Scania Diagnose & Programmer) for troubleshooting. Guided methods are the XML files being
designed by the method engineers on the Scania which describes the structure of
troubleshooting. They contain different conditions which control the flow of the guided method
and the interaction between the mechanics and the vehicle. The guided methods and other
information transforms to the SDP3’s database by an internal tool called SDP3 PT (SDP3
Production Tools).
The conditions within the guided methods look like propositions in the propositional logic. The
predicates are made by comparing different variables with each other or comparing a variable
with a constant value. Comparisons are performed by relational operators and they can combine
with each other using the logical operators. The guided methods can be large in size and the
conditions can be too complex to be managed by a human. Because of this a software tool is
needed to help testing and analyzing the conditions. This is the purpose of this work.
In this work a graphical user interface has been developed using HTML and XSLT which
method engineers (Guided method’s designers) can input the variables values by using it. After
that the conditions will be evaluated by an evaluation framework developed in Java. The
evaluation’s result will be displayed for the method engineers. To connect the graphical user
interface to the evaluation framework Java Plug-in Technology has been used (Known also as
Applet). In this way the method engineers can analyze and test the structure and correctness of
the conditions.
Förord
Det bästa med att skriva är det unika tillfället som man får för att tacka högt och tydligt dem
som betyder i ens liv. Jag tar detta tillfälle i akt för att tacka de mest viktiga personerna i mitt
liv: min mor och mina syskon som har varit med hela vägen. Jag tackar också dem som har
hjälpt till med detta arbete.
Min handlare på KTH, Alexander Baltatzis, och på Scania YSET, Mohammad Khaledi, för
deras tålamod, stöd och tid tackar jag.
Utvecklare av SDP 3 PT på YSET Jakob Palmheden, Kerstin Simonsson, Anders Stefansson,
Göran Öberg som hjälpte mig på alla möjliga sätt och var så generösa att dela med sig sina
värdefulla kunskaper.
Ett speciellt tack till Stefan Östergaard inte bara för att han korrekturläste rapporten utan även
för all tid han ägande åt mig senaste året.
Emma Leeb-Lundberg på YSEA-avdelningen på Scania som svarade alltid vänligt och
tålmodigt på mina språkliga frågor.
SDP3-utvecklarna på YSEI-avdelningen: Ove Bergmark och Marko Kurtto som gav mig
chansen att intervjua dem och få information som gynnade arbetet
Farzad Kamrani för hans råd och förklaringar angående simulering.
Shahab Mokarizadeh för den information och rådgivning som han gav om regelbaserad
programmering.
Studenterna vid grupphandledning för deras åsikter som hjälpte att förbättra arbetet: Niclas
Andersson, Mark Bartish, Jonatan Petersson och André Strindby.
Innehållsförteckning
1. Inledning ............................................................................................................................... 1
1.1. Fordon och elektronik ................................................................................................... 2
1.1.1. Elektroniska styrenheter ........................................................................................ 2
1.1.2. Controller Area Network ....................................................................................... 3
1.2. Felsökning, mjukvaruverktyg och guidade metoder ..................................................... 5
1.2.1. Mjukvaruverktyg ................................................................................................... 5
1.2.1.1. Scania Diagnose & Programmer 3 ................................................................ 6
1.2.1.2. SDP3 Production Tool .................................................................................. 8
1.2.2. Guidade metoder ................................................................................................. 10
1.3. Problembeskrivning och mål ....................................................................................... 11
2. Förkunskaper ....................................................................................................................... 16
2.1. XML-världen .............................................................................................................. 16
2.1.1. XML-parsning ..................................................................................................... 18
2.1.2. XSLT ................................................................................................................... 19
2.1.3. XPath ................................................................................................................... 21
3. Mjukvaruverktyg för villkorsanalys .................................................................................... 25
3.1. Avgränsningar ............................................................................................................. 26
3.2. Användargränssnitt för inmatning av variablernas värde............................................ 26
3.2.1. Logiken i skapandet av användargränssnittet ...................................................... 27
3.2.2. Utvärdering ......................................................................................................... 28
3.2.3. Implementering ................................................................................................... 29
3.2.3.1. Gruppering i XSLT ..................................................................................... 32
3.2.3.2. Användande av olika XSLT-processor ....................................................... 34
3.3. Evalueringsramverket ................................................................................................. 34
3.3.1. Utvärdering ......................................................................................................... 34
3.3.1.1. Villkorsramverket i SDP3 ........................................................................... 35
3.3.1.2. Regelbaserad programmering ..................................................................... 35
3.3.1.3. Evalueringsramverket implementerat i Java ............................................... 36
3.3.2. TDD (Test Driven Development) ....................................................................... 36
3.3.3. Implementering ................................................................................................... 37
3.3.3.1. Datastrukturer .............................................................................................. 38
3.3.3.2. Evalueringsalgoritmen ................................................................................ 41
3.4. Kopplingen mellan användargränssnittet och evalueringsramverket .......................... 42
4. Avslutning ........................................................................................................................... 47
4.1. Fortsatt arbete .............................................................................................................. 48
Litteraturlista ............................................................................................................................... 51
Scania Internal ................................................................................................................. 52
Bilaga A: Uppvisning av en guidad metod i SDP3 ..................................................................... 53
Bilaga B: Exempel på villkor i ett steg ....................................................................................... 55
Bilaga C: Utvärdering av olika typer av Datastrukturer för villkoren ........................................ 59
Bilaga D: Testfall i JUnit ............................................................................................................ 61
1- Testfall för test av funktionen ”equals” i villkors datastruktur .............................. 61
2- Testfall för test av evaluering av villkor ................................................................. 63
Bilaga E: Förkortningar .............................................................................................................. 71
Inledning
1
1. Inledning I inledningen kommer först en allmän bakgrund. Därefter presenteras de viktigaste
begreppen inom fordon som relaterar till examensarbetet. I nästa del ges en överblick
över felsökning och mjukvaruverktyg för den på Scania. Sista delen beskriver
examensarbetets syfte.
Det är inte lätt för någon att bedöma den tid han eller hon lever i. Okunskapen om framtiden
begränsar ens omdöme och gör det omöjligt att ha en överblick över tiden som man befinner sig
i eller att kunna jämföra den med framtiden. Trots det kan kanske de som levt under de sista
åren av nittonhundratalet eller i början av detta sekel hävda att de har upplevt de snabbaste
förändringarna i människans livsstil någonsin. Utvecklingen av elektronik och relaterad
vetenskap är utan tvekan en av de största anledningarna till de här förändringarna. Denna
utveckling har tills nu påverkat fordonsindustrin radikalt och det är kanske bara början.
Ett bra exempel som visar de snabba förändringarna inom fordonsindustrin är antalet bilar som
har tillverkats av Scania fram tills nyårsafton 1990. ”Det tog drygt 88 år att tillverka hälften av
de 620 000 fordon som levererats fram tills det. Medan andra hälften alltså gick på mindre än
tolv år” [Scania 100 år 1991, s.7]. Inte bara fordonens tillverkningssätt har ändrats utan även
själva fordonen har förändrats mycket. Moderna fordon innehar många nya funktioner som
implementerats med hjälp av elektronisk utrustning. Elektronik har också hjälpt till att förbättra
många av fordonens gamla funktioner.
Mer funktionalitet medför mer komplexitet. Att felsöka och laga moderna fordon har blivit allt
svårare. Dels för att de har fler funktioner och därför är underhållet svårare, dels för att
reparation av elektroniska instrument är svår. I många fall är det billigare och lättare att köpa ett
nytt instrument istället för att laga det gamla instrumentet. Därför behöver mekaniker och de
som felsöker fordonen moderna verktyg och hjälpmedel för sitt arbete. Verktyg som kan avläsa
eller skriva om information från elektroniska enheter. Behov av sådana verktyg är viktigare när
det handlar om lastbilar och bussar som är mer komplexa än personbilar.
Scania är en av världens äldsta biltillverkare som redan efter första världskriget koncentrerade
sig på lastbilar och bussar. ”Efter andra världskriget inleddes en exportoffensiv som gjort Scania
till en av världens största tillverkare av tunga lastbilar och bussar” [Lindh 1992]. En sådan lång
historia inom fordonsindustrin kräver att företaget ständigt är uppdaterat med dagens teknologi.
I detta sammanhang lanserade Scania lastbilar och bilar med elektroniska styrenheter och
datorstyrda enheter redan under 80 talet. ”1983 hade Scania som första lastbilstillverkare
presenterat sin epokgörande datorstyrda växellåda […]. Den datorstyrda växellåda CAG
(Computer Aided Gearchanging) inledde elektronikens intåg i lastbilstekniken” [Scania 100 år
1991, s. 206].
Innan jag börjar beskriva examensarbetets problem kommer jag att presentera de begrepp som
är viktiga för att förstå problemet. Först presenterar jag de begrepp som är relaterade till
fordonens hårdvara och sedan går jag igenom begrepp länkade till mjukvaruverktyg för
felsökning av fordon på Scania.
Inledning
2
1.1. Fordon och elektronik
Som nämndes tidigare använder sig moderna fordon av ett elektroniskt system. ”Hjärnan i ett
elektroniskt system är ECU” (Electronic Control Unit) [HILLIER 1996, s.111]. ECU har
översatts till svenska som ”elektroniska styrenheter”. I fortsättningen kommer jag att använda
ordet ”styrenheter” istället för ECU eller elektroniska styrenheter.
1.1.1. Elektroniska styrenheter
Styrenheter används i olika elektroniska system. I den här rapporten kommer de bara att
presenteras i samband med fordon. En styrenhet är en dator som kontrollerar olika funktioner i
fordonets olika subsystem med hjälp av mottagna signaler från några givare. Utöver en dator
består en styrenhet av flera mjukvarukomponenter som interagerar med generatorer, givare och
aktuatorer 1 [Sun Her 2007, s.358]. Styrenheters mjukvara kan sparas i flashminne. På så sätt
kan man uppgradera mjukvaran och sådana styrenheter kallas för programmerbara styrenheter
[Khaledi 2008, s.3]. Mjukvaran som finns på ett modernt fordon kan hantera upp till 80
styrenheter och hundratals givare och aktuatorer. En sådan mjukvara kan nå upp till tio miljoner
rader av programkod [Sun Her 2007, s.358].
Styrenheterna kan klassificeras efter det subsystem av fordon som de hanterar. Några exempel
av de vanliga styrenhetskategorier eller styrenhetsfamiljer är: ABS (Anti-lock Braking System),
EMS (Engine Management System) och ACC (Automatic Climate Control). Bild 1.1 visar
några styrenhetsfamiljer i en lastbil [Karlbäck 2010, s.6].
Figur 1.1 Styrenheter i en lastbil. Varje tillverkare kategoriserar dem på olika sätt.
1 Ställdon
Inledning
3
1.1.2. Controller Area Network
Styrenheterna kan skicka vidare de signalerna som de får från olika givare, generator och
aktuatorer till andra styrenheter eller till externa datorprogram. Några exempel på sådana
signaler är: Hjulhastighet, olja- och vattentemperatur, motors r/min, växelval, gaspedalens läge,
klimatkontrollinställningar och felkoder.[Davis 2007, s.242]
Många av dessa signaler måste behandlas snabbt och i realtid. T.ex. en styrenhet avläser
bromspedalens läge och skickar därefter vidare en signal om att bromsen har trampats ner till
den styrenhet som är ansvarig för bakre belysningen. Den styrenhet som tar emot signalen
tänder i sin tur bromsljusen. Tabell 1.1 visar olika signaler i en BMW-personbil och kraven för
kommunikation mellan olika styrenheter [Davis 2007, s.242].
Position i bil Antal styrenheter Bandbredd Antal signaler Gångtid
Karosseri 14‒30 100 Kbits/s 300 50 ms - 2 s
Chassi 6‒10 500 Kbits/s 180 10 ms -1 s
Drivlina (Powertrain)2 3‒6 500 Kbits/s 36 10 ms- 10 s
Tabell 1.1 BMW 7 Seriens krav för kommunikation mellan styrenheter
Enligt [Davis 2007, s.242] kan det finnas mer än 2500 åtskilda signaler. För att hantera dessa
signaler och samordna kommunikationen mellan styrenheter eller mellan styrenheter och
externa datorer är det nödvändigt att bygga ett nätverk. CAN (Controller Area Network) är ett
nätverk som har konstruerats i det syftet. CAN är en kommunikations seriebuss som är till för
att tillhandahålla enkel, effektiv och robust kommunikation för fordonets nätverk. CAN har
utvecklats av Robert Bosch GmbH i början av 1983. Intel och Philips släppte ut första CAN:s
kontrollerchips 1987. Mercedes var den första som 1991 använde CAN3 i ett fordon. [Davis
2007, s.240]
CAN är även protokollnamnet som används i fordonets nätverk. Styrenhetssignaler utformas i
informationspaket som överförs mellan enheter. Bild 1.2 visar ett standardpaket enligt CAN-
protokollet [Davis 2007, s.245]. DLC står för ”Data Length Code” och visar längden av data
(mellan 0 till 8 byte). CRC står för ”Cyclic Redundancy Check” och används för att kontrollera
om något fel hänt under överföringen.
Bild 1.2. Paketformat i CAN-protokoll
2 Drivlina är den samling av delar i fordonet som driver det. Den består av motor, koppling, växellåda,
kardanaxel och bakaxel.
3 Många skriver CAN-nätverk, men eftersom bokstaven ”N” i CAN står för nätverk undvek jag det. Jag
använder CAN när jag syftar på nätverket.
Inledning
4
Tabell 1.1 visar att olika delar av fordonet använder databussar med olika hastighet. Styrenheter
som ligger i karosserien använder sig av en databuss med hastigheten 100 Kbits/s. Medan de
som finns i chassi eller drivlina är relativt snabba och ansluter sig via en databuss med
hastigheten 500 Kbits/s. För att få ett nätverk med databussar med olika hastighet använder man
en förmedlingsnod (Gateway) som styrs av en speciell styrenhet. På Scania används tre olika
databussar i CAN som namngetts grön, gul och röd. Den styrenheten som fungerar som en
förmedlingsnod mellan de tre databussarna och samordnar anslutningen mellan dem är COO
(COOrdinator). Bild 1.3 framställer CAN och styrenheters anslutning i Scania [Khaledi 2008,
s.4].
Bild 1.3 CAN och styrenheters anslutning
CAN och styrenheter är de viktigaste elektroniska anordningar som används i moderna fordon.
En viktig del av elektroniska anordningar är mjukvara. Mjukvara är gränssnittet mellan
människa och elektroniska instrument. Med hjälp av mjukvara ger man nya instruktioner till
Inledning
5
instrumentet eller läser av de information som instrumentet producerar. I nästa del presenteras
de mjukvaror som används i samband med felsökning av fordon på Scania.
1.2. Felsökning, mjukvaruverktyg och guidade
metoder
Den snabba elektroniska utvecklingen har genom ökad funktionalitet och avancerade
teknologier gjort fordonen mer felbenägna samtidigt som felsökning av fordon har blivit allt
svårare. Traditionellt kunde mekaniker via egen erfarenhet lista ut vilken funktionalitet som
fanns på ett fordon. Han kunde med hjälp av erfarenhet förstå vilka komponenter som berördes
av vilka fel och för det mesta felsökte han endast med hjälp av egna sinnen.
När en stor del av fordonet styrs av styrenheter och mjukvara, är det omöjligt att felsöka bara
med hjälp av okulära inspektioner. Ett annat problem är att mjukvaran ofta är konfigurerbar. Det
innebär att två identiskt utrustade fordon kan ha olika konfigurationer och därmed uppföra sig
olika. Därför kan en mekanikers erfarenhet av ett visst fordon inte återanvändas på ett likadant
fordon utan vidare. På grund av detta behöver mekaniker speciella verktyg som hjälper dem
med felsökning och konfiguration av styrenhetsmjukvara.
En av felsökningsmjukvarans funktioner är att visa upp instruktioner och information till
användare som leder honom/henne under felsökningen. Dessa instruktioner och information
utformas och tecknas av experter inom respektive område. På Scania är det metodingenjörer
som har uppgiften att utforma dessa felsökningsinstruktioner där kallas de för ”guidade
metoder”.
I de två följande avsnitten presenteras de verktyg som används på Scania vid felsökning och
styrenhetsmjukvarukonfiguration och beskrivs guidade metoder mer utförligt.
1.2.1. Mjukvaruverktyg
SDP3 (Scania Diagnose & Programmer 3) är den mjukvara som Scania har tillverkat för
felsökning och konfiguration av styrenheter. SDP3 PT (Scania Diagnose & Programmer 3
Production Tool) är ett internt mjukvaruverktyg som används för att integrera och skapa olika
typer av information som SDP3 behöver.
Utöver dessa två mjukvaror finns det en mängd av program och applikationer som berör
fordonets elsystem. Många har ett direkt samband med SDP3 eller SDP3 PT. Men eftersom det
är dessa två som är relaterade till examensarbetet beskrivs inte de andra i rapporten. Nedan görs
en närmare genomgång av SDP3 och SDP3 PT.
Inledning
6
1.2.1.1. Scania Diagnose & Programmer 3
Scania Diagnose & Programmer 3 lanserades december 2003. Innan dess fanns två separata
program för felsökning av elsystemet (Scania Diagnose) respektive konfiguration av det (Scania
Programmer). En utredning på Scania som föreslog de förändringarna som utmynnade i SDP3,
betonar vikten av de två programmen [Ivendal, 1997, s.6]:
”Fordonen är i dag datoriserade och så tekniskt komplicerade, att en verkstad i princip
inte klarar av att reparera fel i datorstyrda system utan att använda Scania Diagnos.
Scania Diagnos och Scania Programmer betraktas därför av företaget som strategiska produkter, vilka ska ha en hög tillgänglighet på marknaden”.
Enligt utredningen stödde SD felsökning av en styrenhet i taget. Diagnosprogrammet kunde läsa
ut felkoder, läsa ingångar och aktivera utgångar. Mekaniker fick tillgång till målinriktad
information i form av elscheman, placeringsbilder, felkodtexter och komponentinformation.
Men programmet styrde inte i vilken ordning mekanikern skulle arbeta. Med andra ord fick
mekanikern ingen hjälp av programmet för att kunna utvärdera felkoderna, sett i ett helhets-
perspektiv. När programmet inte var anslutet till någon styrenhet kunde det användas i
demoläge för utbildning. Utredningen beskrev Scania Programmer som ett separat program som
användes för att konfigurera fordonet. Konfigurationen utfördes genom att ange ett antal
parametrar som sedan matades in och lagrades i styrenheten. Parametrarna var begripliga för
mekaniker men det krävdes ändå stort stöd i form av hjälpinformation.
SD2 som lanserades 1994 var sista versionen av Scania Diagnos innan SD omvandlades till
SDP3. I ett dokument på Scania [Ivendal 1998] (där namnet SDP3 används för första gången
formellt) ges kompatibilitet med Scanias nya elsystem (SESAMM) som största anledningen för
att gå över till SDP3.
Utöver kompatibilitet med elsystemet tas några andra problem som fanns i SD2 upp i [Ivendal
1997, Ivendal 1998] för att förklara behovet av SDP3. Bland annat att felsökningstänkandet i
SD2 fokuserade på styrenheter och system. Men felsökningstänkande borde utgå från förarens
och mekanikerns perspektiv på fordonets funktioner och egenskaper i framtida generationer av
programmet. Med andra ord stödde SD inte felsökning på flera styrenheter samtidigt och
mekanikern kunde inte få den helhetssyn som behövdes för felsökning. Ett annat problem med
SD2 var att tillgång till kompletterande information som funktionsbeskrivning,
arbetsbeskrivning för komponentbyte och handhavandeinstruktioner saknades. Det ansågs också
att det borde finnas mer information om de fel som uppstod i fordonet. SD2 producerade en
mängd felkoder på för låg nivå och då fick mekanikern svårt att avgöra i vilken ände
felsökningen skulle börjas. [Ivendal 1997] föreslår en annan förändring i SD” och SP:
”I de allra flesta fall är det olyckligt att Scania Programmer är ett separat program.
Flertalet användare ser det som en fördel om programmering hade kunnat utföras inne i
diagnosprogrammet.”
På grund av dessa problem och några andra som inte tas upp här inleddes arbetet med projektet
SDP3. Huvudsyftet med SDP3 beskrivs i [Ivendal 2000, s.4]:
Inledning
7
”Syftet med SDP3 är att i första hand stödja mekaniker på Scanias serviceverkstäder i
reparationsprocessen. SDP3 stödjer också anpassning av fordonets gränssnitt mot
produkter från andra leverantörer t.ex. anpassning av påbyggarnod.”
SDP3 implementerades med ett antal delmål, bland annat [Ivendal 2000, s.4]:
Att kunna leda mekanikern rätt vid felsökning utifrån vad kunden klagar på (d.v.s. ur
fordonets funktionella aspekter)
Att kunna utföra guidad fordonsfunktionskontroll och komponentkontroll inklusive
prestationskontroll
Att kunna aktivera och avläsa signalvärden på givare och aktuatorer
Att kunna hantera behörighet för olika användarkategorier på Scanias service verkstäder
Att programmet skulle kunna dynamiskt konfigurera sig efter fordonets funktionalitet
vid uppkoppling
Att programmet ska kunna kommunicera via internet mot Scanias ”Help Desk” och dess
funktioner samtidigt som kommunikation sker mot fordon
Att elscheman, luftscheman, logikscheman och bilder ska kunna visas och skrivas ut för
de delar som mekaniker för tillfället arbetar med
Att programmet ska förses med generell utskriftsfunktionalitet
Att utförda kontroller ska kunna loggas och lagras och skrivas ut så att de kan fungera
som verifikation för utfört arbete
Att programmet skulle kunna kommunicera med fordonet enligt föreskriven standard
Att olika språk skulle stödjas i programmet (Engelska, Svenska, Tyska, Franska,
Italienska, Spanska, …)
Att den tekniska informationen i programmet skulle kunna uppdateras regelbundet via
internet mot Scania
Att programmet skulle tillåta att man lägger till och tar bort funktionalitet
Att programmet skulle tillåta att anpassningar görs på fordonets funktionalitet, t.ex.
anpassning av maxhastighets begränsning
Att ombyggnation av fordon med nya styrenheter och komponenter skulle vara möjlig
Att kunna återställa det fordonsfunktionalitet som fordonet hade vid leveransdatum
SDP3 används av ca 1500 verkstäder och varje år ges fyra utgåvor av det ut.4 SPD3 skapas och
distribueras av YS-organisationen (Vehicle Service Information) på Scania. YS har som uppgift
att leverera verktyg, information och IT-stöd för att kunna utföra5:
Service/underhåll
Felsökning
Reparationer
Ombyggnationer
4 Påståendet är hämtat från en av Scania:s interna presentationer.
5 YS-uppgifter har tagits från Scania:s intranät, YS-sidor.
Inledning
8
Kampanjer
Reservdelsförsäljning
Information till föraren
1.2.1.2. SDP3 Production Tool
Som nämndes tidigare är SDP3 PT ett internt mjukvaruverktyg som har som uppgift att
integrera information och instruktioner som tillverkas av andra applikationer eller produceras av
olika användare t.ex. metodingenjörer med SDP3. SDP3 PT fungerar som ett gränssnitt mellan
olika applikationer och användare på Scania i ena sidan och SDP3 å andra sidan. Bild 1.4 6 visar
relationen mellan SDP3 och SDP3 PT.
Bild 1.4 Relationen mellan SDP3, SDP3 PT och olika användare och andra applikationer
På Scania finns flera applikationer som innehåller information om fordonet, använder
styrenheter eller påverkar fordonets elsystem. Utdata (ofta i XML-format) av några av dem
används i SDP3. SDP3 Production Tool övervakar integrationen mellan deras utdata och SDP3.
Exempel på andra applikationer är CDAPP (Construction Data APPlication). Konstruktionsdata
kommer från flera källsystem och i form av HTML, text, XML och övrigt överförs till CDAPP.
CDAPP sparar data i en relationsdatabas. Sedan exporteras data vidare i givna intervaller i form
av XML till SDP3 PT. CDAPP har implementerats i Java2EE och använder SQL Server 2000
som databas [Dubois 2010, s.3]. Exempel på källsystem för CDAPP är CHIN (CHassis
INformation system). CHIN är Scanias chassidatabas och behandlar specifikationer av samtliga
chassier som är beställda eller byggda. En annan applikation som deltar i processen att skapa
data för SDP3 kallas för WINGS (Workshop Information Next Generation Scania). I WINGS
arbetar teknikinformatörer med att skriva teknisk information för olika eftermarknadsprodukter,
såsom SDP3, verkstadshandbok, förarhandbok mm.” [WEILAND 2005, S.3]. Det är
6 Bilden är hämtad från Scania:s interna presentationer med lite förändring.
Inledning
9
teknikinformatörens uppgift att skriva information om olika sorters produkter t.ex. en viss
motor, en magnetventil eller en felsökningsmetod och de använder WINGS för detta syfte.
SDP3 PT var resultatet av projektet SDP3 PM (Scania Diagnose & Programmer 3 Produktions-
Miljö) som började augusti 2004. Innan dess användes SDP3 IPM (Scania Diagnose &
Programmer 3 Interimistisk Produktionsmiljö) för att integrera och skapa information för SDP3.
För att producera varje SDP3-utgåva krävdes en mängd underlag (data). IPM hade som uppgift
att skapa detta underlag. Ulf Weiland i sin rapport [Weiland 2005, s.2] delar in underlagen i två
delar:
”Metodunderlag. Underlag som specificeras av metodingenjör och som
beskriver metoder för felsökning i fordon. Detta kan t.ex. vara en metod för
motortest av en lastbil.
Konstruktionsunderlag. Underlag som levereras av konstruktionsavdelningarna
på Scania. Underlagen levereras i varierande format. Det kan vara allt från
manuellt skrivna Excel-dokument till XML-exporter från externa system.
Konstruktionsunderlagen refereras ofta från metodunderlagen. Exempel på
konstruktionsunderlag är komponentbiblioteket som definierar komponenter som
t.ex. lampor etc.”
IPM utvecklades inte med ett långsiktigt fokus. Det var ett medvetet val på grund av tids- och
resursbrist. Därför var IPM en komplex, svåranvänd och svårförvaltad, kostnads- och
resurskrävande miljö för de inblandade aktörerna [Gugala 2009, s.8]. Dessutom med tiden blev
nya aktörer inblandade i processen att skapa underlag till SDP3. T.ex. redaktörer som skrev
hjälptexter. IPM var ursprungligen inte avsett för detta och verktygen i IPM gav inte tillräckligt
effektivt stöd för dessa aktörer [Gugala 2009, s.8]. Det fanns en rad andra problem också. T.ex.
fyllde användargränssnittet inte kraven på användbarhet, för många fel uppstod vid ifyllning av
XML-mallar och vid import av texter till programmet, det saknades en gemensam
informationsmodell m.m. [Johansson 2006, s.4]. På grund av dessa brister i SDP3 IPM
utvecklades SDP3 PT.
SDP3 PT:s främsta uppgift är att importera nödvändiga data, kontrollera konsistensen och
transformera data till det format som kan användas i SDP3. Ett verktyg som kallas för DBTool
skapar SDP3:s databas baserat på SDP3 PT:s filer. Bild 1.5 7 visar detta förlopp.
Bild 1.5 Förloppet av databasbygge för SDP3
7 Bilden är hämtad från Scania:s interna presentationer.
Inledning
10
1.2.2. Guidade metoder
Guidade metoder är de underlag som definieras av metodingenjörer och beskriver felsökningen
i fordon. Eftersom examensarbetet handlar om dessa metoder inom SDP3 PT är det nödvändigt
att de som läser rapporten känner till deras struktur.
Guidade metoder tillhandahålls i XML-format. Varje guidad metod innehåller ett eller flera
steg. Varje steg visar upp information eller instruktioner till användaren som ofta är
mekanikern. Informationen och instruktionerna kallas för stegets innehåll (Step content). Det
steg vars innehåll visas för användaren under SDP3:s körning kommer att kallas det aktuella
steget i fortsättningen. Stegen kopplas till varandra genom XML-elementet ”NästaSteg”. Varje
steg kan ha noll till många ”NästaSteg”-element. Ett ”NästaSteg”-element refererar till ett steg i
samma guidade metod som det hänvisande steget finns i. Detta steg kan bli det aktuella steget
efter det steg som refererar till det. Vilket av de ”NästaSteg”-element som refereras av det
aktuella steget kommer att bli aktuellt bestäms av ett villkor. Med andra ord innehåller varje
”NästaSteg”-element ett ”Villkor”-element. Fast det är möjligt att ett ”NästaSteg”-element inte
har något villkor. I sådant fall visas det steget direkt för användaren när han trycker på knappen
”nästa” i användargränssnittet utan att något villkor evalueras.
Villkor i varje steg består av jämförelser av variabler med varandra eller mellan variabler och
konstanta värde. Jämförelserna utförs med hjälp av relationsoperatorer (Lika med, större än,
mindre än m.fl.). Dessa jämförelser kan betraktas som logiska satser 8. Dessa satser kombineras
med hjälp av logiska operationer (and, or, not, exklusive or). I varje sats finns minst en variabel
(högst två) som kan vara av olika typer. Ett variabel anges av ett namn och dess värde kommer
att läsas från styrenheterna eller matas in av användaren eller produceras av programmet SDP3
under programmets körning. Typen kan visa om variabeln har lästs av en styrenhet eller har
lagrats i system som ett värde eller är en variabel som indikerar en felkod m.m. Variabeln
jämförs med ett konstant värde (eller med en annan variabel). Konstanten är ett värde som kan
vara av typen heltal, flyttal, boolesk, teckensträng eller kombinerad.
Ett vanligt scenario i SDP3 kan beskrivas enligt följande: Ett steg som innehåller många
”NästaSteg” visas för användaren i SDP3:s användargränssnitt. Programmet kontrollerar om
villkoret för ”NästaSteg” gäller och visar i så fall upp innehållet av steget. I bilaga A visas några
steg av en guidad metod i SDP3. En guidad metod kan innehålla information och instruktioner
relaterade till en styrenhet (ECU Guided Method) eller vara ett funktionsprov eller
funktionsjustering (User Function Guided Method). Funktionsprov kan hantera flera styrenheter
under ett prov. Med funktionsjustering menas också en utökad variant av en guidad metod som
medger samtidig justering av flera styrenheter för distribuerad funktionalitet.
8 Logic Propositions. Logiken är satslogik.
Inledning
11
1.3. Problembeskrivning och mål
“Abstraction is the key to managing complexity.”
Andrew S. Tanenbaum
Guidade metoder kan betraktas som hjälpmedel för felsökning av fordonen. Metodingenjörerna
på Scania har till uppgift att utforma, formulera och implementera lämpliga guidade metoder
som sedan ska användas av mekaniker via SDP3.
Guidade metoder kan vara stora och komplexa. Med andra ord kan de vara oöverskådliga om
man vill hantera dem som vanliga XML-filer.9 Därför behöver metodingenjörerna ett mjukvaru-
verktyg som hjälper dem i samband med design och implementering av guidade metoder.
Utvecklarna i ”SDP3 Production Tool-teamet” på Scania har utvecklat en grafisk editor som gör
det möjligt att se guidade metoder grafiskt (Bild 1.6). Rektanglarna i bilden visar olika steg i en
guidad metod och romber föreställer villkor.
Bild 1.6 En enkel guidad metod visad grafiskt i SDP3 Production Tool. Rektanglarna i bilden
visar olika steg i en guidad metod och romber föreställer villkor.
Om man väljer ett steg eller ett villkor kan man se utförligare information om dem på en panel i
den grafiska editorn. Den grafiska editorn förser metodingenjörerna med ett verktyg för att se en
grafisk modell över en guidad metod. Med hjälp av det verktyget kan metodingenjörerna
analysera guidade metoder lättare. Verktyget skapar även gynnsamma förutsättningar för att
utforma nya guidade metoder. Men den uppfyller inte metodingenjörernas alla krav. Bland
annat kan metodingenjörerna inte testa om stegen är kopplade på rätt sätt. Som tidigare nämnts
är villkoren i guidade metoderna logiska satser. Ett annat problem som metodingenjörerna stöter
9 Guidade metoder kan överstiga en storlek på ett hundra kilobyte.
Inledning
12
på är att villkoren i guidade metoder kan vara komplexa och svåra att verifiera. Bild 1.7 visar
upp en komplex guidad metod i SDP3 PT:s grafiska editor. Som bilden visar består den här
guidade metoden av många steg och villkor och det är svårt att behärska guidade metodens
struktur eller att bedöma om villkoren är korrekta.
Bild 1.7 Guidade metoders komplexitet
Examensarbetets mål är att implementera ett mjukvaruverktyg med vars hjälp
metodingenjörerna kan analysera och testa villkoren i guidade metoder. Detta verktyg bör
integreras med den grafiska editorn i SDP3 PT för att komplettera de möjligheter som redan
finns. För att testa ett system bör man återskapa de parametrar och omständigheter som systemet
råkar ut för när det tas i bruk. De parametrar som spelar roll i villkoren och villkorsanalys är
variablerna i villkoren. Med andra ord bör variablernas värde produceras på något sätt för att
kunna testa villkoren i guidade metoder.
Inledning
13
Bild 1.8 visar olika sätt att studera och testa ett system (Bilden har hämtats från [Law 2000,
s.4]). Som framgår av bilden kan man tänka sig att testa guidade metoder mot det faktiska
systemet som i det här fallet är ett fordon. På det sättet kan man producera variablernas värde.
Ett hinder för att testa guidade metoder mot fordonet är att metodingenjörer inte alltid har
tillgång till det fordon som den guidade metoden är till för. Även om fordonet är tillgängligt kan
kostnaden för att testa guidade metoden mot det vara avsevärd.10
Ett annt problem som kan
uppstå är när metodingenjörerna utformar guidade metoder för ett fordon som ännu inte har
tillverkats. Med andra ord finns inget fordon för att testa guidade metoden mot. Av dessa skäl är
det inte lämpligt att använda fordonet för att testa och studera guidade metoder.
Bild 1.8 Olika sätt att testa ett system
Man kan undersöka och testa ett system med hjälp av en modell av det faktiska systemet.
Modellen kan vara fysisk eller matematisk.11
För att testa SDP3 använder man sig av testriggar
som fysiska modeller i Scania. Man kan sätta ihop ett antal styrenheter på varje testrigg.
Därefter kan man testa styrenheters värde och kontrollera om kommunikationen fungerar.
Frågan är om man kan använda sig av dessa testriggar i SDP3 Production Tool för att testa om
guidade metodernas struktur är korrekt och rätt steg i en guidad metod visas för användaren
under ett villkor.
10
Det kan vara så att metodingenjören behöver resa till fordonet eller att fordonet måste stå stilla och inte
användas medan guidade metoder testas.
11 I [Law 2000, s.4] har ordet matematisk använts som motsatsen till fysisk. Dock passar ordet virtuell
kanske bättre än matematisk. I många fall kan modellen vara ett program. Även om man kan påstå att alla
program är matematiska modeller kan det vara så att grafiken eller I/O:n spelar mer roll än matematiken i
vissa program.
Inledning
14
Att använda testriggar för test av villkor i guidade metoder medför samma problem som finns
om man använder det faktiska systemet för test av villkor. Det händer att metodingenjörerna
utformar en guidad metod för ett fordon som inte har tillverkats än och därmed finns ingen
testrigg för. Utöver det finns andra nackdelar med att använda testriggar för test av villkor. En
nackdel är att man inte kan genomföra alla tester som behövs. T.ex. om en guidad metod är
beroende av motorns varvtal eller bromssystemet kan testriggarna inte erbjuda användbara tester
för den. Ett annat problem är att man måste överföra en stor del av SDP3-programkoden till
SDP3 Production Tool. Nämligen den delen av programkoden som används för kommunikation
med CAN och anslutning mot styrenheter. Att överföra koden kräver mycket arbete och utöver
det kommer SDP3 Production Tool i så fall att få mycket mer programkod och därmed blir
underhållet allt svårare. Nackdelarna med att använda testriggarna gör att fysiska modeller inte
är lämpliga till test av guidade metoder i SDP3 Production Tool.
Bortsett från att använda fysiska modeller kan man använda virtuella modeller för att
möjliggöra test av guidade metoder. Simulering är ett ord som har ett starkt samband med
virtuella (eller matematiska) modeller. [BANKS 2009, s.3] definierar simulering som
imitationen av ett system eller en process av faktiska världen med tiden. Simulering kan ske
manuellt eller med hjälp av dator. Oavsett hur simulering sker omfattar den framställning av
systemets konstlade historik. Sedan med iakttagelse på den konstlade historiken kan man dra
slutsatser om det faktiska systemets egenskaper. Systemets beteende med tiden studeras med
hjälp av en simuleringsmodell. Modellen är ofta baserad på en mängd antaganden om hur
systemet fungerar. Dessa antaganden uttrycks i matematiska, logiska och symboliska relationer
([BANKS 2009, s.3]). Simulering används för att studera komplexa system. När modellen är
enklare, så att man kan använda papper och penna eller enklare datorprogram, kan man kalla det
en analytisk lösning [Law 2000, s.5].
Att utveckla ett program som simulerar fordonets beteende för ändamålet att testa guidade
metoder är inte prisvärt. I ett fordon finns runt 30 olika styrenheter och som sagt är det inte bara
parametrar i styrenheter som är viktiga i guidade metoder. Ett simuleringsprogram som kan
imitera alla styrenheter och andra blandade parametrar i ett fordon (såsom motor och
bromssystem) är ett stort projekt och tar kanske några år att utveckla. Law och Kelton i [Law
2000, s.5] skriver att om det finns en analytisk lösning för en matematisk modell och om den är
effektiv är det bättre att studera modellen med hjälp av den istället för simulering. Ett likartat
resonemang kommer i [BANKS 2009, s.3]. Där under rubriken ”När simulering inte är lämplig”
står det att som första regel bör man undvika simulering när man kan lösa problemet med sunt
förnuft. Därför kommer inte ett simuleringsprogram att tas upp som ett alternativ i rapporten
och det som strävas efter är att framställa en analytisk lösning.12
I SDP3 har man möjligheten att spara fordonets status som ögonblicksbilder i textfiler som
kallas för demofiler (För att sedan köra SDP3 i demoläge). Ett tänkbart alternativ är att testa
guidade metoder mot dessa demofiler. Ett problem som dyker upp i det här fallet är att man inte
kan testa parameterförändringarna i guidade metoder. Med andra ord behöver man
implementera ett sätt att testa guidade metoder som är beroende av variabler eller parametrar
vars värde ändras under körningen. T.ex. i ögonblicksbilden som man testar en guidad metod
mot står att motorns varvtal är normalt men man vill även testa vad som kan hända vid
12
Simulering är ett uttryck som använts med bred betydelse och man kan diskutera om det som har
kallats simulering inte är en analytisk lösning i själva verket eller tvärtom. Jag föredrog att undvika att
använda ordet simulering i rapportens titel samt att kalla den lösning som framförs för simulering.
Anledningen var att inte missleda de som letar efter de kända simuleringsmetoder som ”Disceret Event
Simulation” och så vidare.
Inledning
15
maximalt varvtal. Det är klart att det inte är möjligt att skapa ögonblicksbilder för alla
situationer och växla mellan olika ögonblicksbilder när man testar en guidad metod. Utöver det
har användandet av demofiler samma problem som användandet av testriggar. Man måste
överföra en stor del av SDP3-programkoden till SDP3 Production Tool. Programmet förhåller
sig till fordon, testrigg eller demofil på samma sätt och man måste implementera programkod
för kommunikation med CAN och anslutning till styrenheter hursomhelst. Detta är dyrt, kräver
mycket arbete och strider mot att SDP3 Production Tool var tänkt som ett verktyg som skapar
underlag för SDP3-utgåvor och inte som en del av det eller ett separat program med liknande
funktionalitet.
Mot den bakgrunden vill man ha en lämpligare och enklare analytisk lösning för att kunna testa
guidade metoders korrekthet under olika omständigheter. Den grafiska editorn i SDP3 PT kan
räknas som en analytisk lösning men som sagt ger den ingen möjlighet för att testa villkoren. På
grund av detta behöver metodingenjörerna en utvecklad version av den grafiska editorn som ger
möjligheten att testa och analysera villkoren i guidade metoder. Denna uppgift kan delas upp i
två delar. För det första behöver metodingenjörerna kunna mata in värden av de variabler som
finns inom villkoren under ett steg som de vill granska och för det andra måste de kunna se
resultatet av villkorsevalueringen. På så sätt kan de analysera villkoren.
Examensarbetets ändamål har varit att hitta en lösning för att uppfylla kraven till villkorsanalys.
I denna rapport ska jag presentera en analytisk lösning via ett mjukvaruverktyg efter en kort
genomgång av nödvändiga förkunskaper. Med hjälp av detta verktyg kan metodingenjörerna
mata in värden av de variabler som finns inom villkoren under ett steg och sedan baserat på
inmatningen kommer villkoren att evalueras och till slut visas resultatet av evalueringen för
användaren.
Förkunskaper
16
2. Förkunskaper För att förstå hur data och information behandlas behöver man känna till XML och
XSLT. En kort presentation av dessa kommer inom det här kapitlet.
Programmeringsspråket som används är Java och utvecklingsmiljön är Eclipse.
För att förstå utvecklingsprocessen för examensarbetet måste man vara bekant med en del
tekniker och kunskaper. Man kan betrakta varje datorprogram som en mängd instruktioner som
ges till datorn. Dessa instruktioner kommer att tillämpas på en mängd information. För att dessa
förverkligas bör:
informationen kunna anges i programmet i ett lämpligt format,
man ha ett språk för att skriva instruktioner med,
en miljö eller ett verktyg finnas som instruktionsskrivande sker i och även ger
möjligheter för att förenkla skrivförloppet.
Med detta synsätt kan man dela in de kunskaper som behövs för att utveckla ett datorprogram i
tre delar. Nämligen databehandling, programmeringsspråk och utvecklingsmiljö. I SDP3 PT är
guidade metoder en del av programmets datamängd. Guidade metoder används även som data i
examensarbetet. Det format som Guidade metoder skapas enligt det är XML (Extensible
Markup Language). Därför bör man känna till XML och relaterade kunskaper i samband med
examensarbetet. I nästa avsnitt presenteras XML och några relaterade begrepp kortfattat.
SDP3 PT har implementerats med Java programmeringsspråk och Java används även i
examensarbetet. SDP3 PT har implementerats som ett Eclipse-tillägg. Eclipse är ett program
som utvecklats av IBM och kategoriseras som IDE (Integrated Development Environment). Ett
IDE är i princip en miljö som man kan utveckla och skriva program i med ett eller flera olika
programmeringsspråk. Vanligen utvidgar ett IDE de möjligheter som finns i en vanlig
ordbehandlare (Program som används för att skriva texter) och anpassar dem för
programmering. En av de möjligheter som Eclipse ger är att utveckla tillägg (Plugin). Det
innebär att man kan skriva program som är baserat på Eclipse-miljö men med önskad tillagd
funktionalitet. SDP3 PT har använt denna möjlighet. Bekantskap med Eclipse är inte nödvändig
för någon som läser denna rapport och därför kommer inte i rapporten.
2.1. XML-världen
Inom datordiskursen kallas den information som används i ett datorprogram för data. Data har
en väsentlig roll i datorprogram och därför har många tekniker och teorier, specificerade för
datahantering, utvecklats. En av de mest kända är databas. Databaser införde en metod för att
spara och återvinna data effektivt. Databaser använder sig av speciella strukturer för att lagra
data. Den gängse datastrukturen är tabeller med rader och kolumner. Varje rad har ett unikt fält
som raden kan identifieras med vars hjälp och kallas för radnyckel. Man kan komma åt data
lagrade i en viss tabellcell genom cellens kolumnnamn och radnyckeln.
Förkunskaper
17
Med ökningen av antalet program förekom alltmer att man behövde använda data producerade
av ett program i ett annat program. Med Internets tillblivelse finns ett mer lättarbetat sätt för
olika program att interagera med varandra. Dataöverföring mellan olika program är en komplex
operation och medför många problem. En av orsakerna till dessa problem är att olika program
tolkar data på olika sätt och använder olika format. XML (eXtensible Markup Language) är ett
märkspråk med vars märkord (taggar) i ett datadokument (textdokument) olika program kan
tolka dokumentet på ett enhälligt sätt. På så sätt sker dataöverföringen mellan olika program
enklare och tillförlitligare. Kort sagt är XML ett standardformat för representation och utväxling
av textdata.
XML härstammar från SGML (Standard Generalized Markup Language). SGML uppfanns på
IBM under 1970-talet och utvecklades i flera år av utvecklare runt världen tills det
presenterades som ISO-standard (International Organization for Standardization) 1986. SGML:s
största succé var HTML (HyperText Markup Language) vilket används som ett standardformat
för framställning av hemsidor på internet. Problemet med SGML är att det är mycket
komplicerat. SGML-specifikationen är mer än 150 sidor och omfattar många speciella fall. Det
är så komplicerat att inget program har implementerat det fullkomligt. År 1996 började Jon
Bosak, Tim Bray, Michael Sperberg-McQueen, James Clark och några andra samarbeta för att
skapa ett ”litet” SGML som behöll de befintliga möjligheter samtidigt som det skar bort de
överflödiga funktioner som fanns. Resultatet var XML 1.00 vilket presenterades i februari 1998
och fick genombrott omedelbart. [Harold 2004, s.8,9].
Om ett dokument inte använder någon form av gränstecken eller etikett kan ett program inte
skilja en del av text från andra delar. XML:s markeringar delar in ett textdokument i separata
informationsbehållare som kallas nod. Noder förseglar information, etiketterar det och formar
ett paket som sedan kan bearbetas av datorprogram. En nod som innehåller andra noder kallas
för element. Ett element kan placeras inuti ett annat element precis som paketen som kan
innehålla andra paket. Ett sådant element kallas för barnelement och det elementet som
innehåller det kallas för förälderelement. Ett element kan innehålla många andra element som i
sin tur innehåller andra element och så vidare tills man kommer åt rådata (texten)13
. Detta skapar
en hierarkisk struktur som bevarar en del stödinformation utöver själva rådata. Stödinformation
som sekvens, ägande, position, beskrivning och förbindelse. Varje XML-dokument består av ett
yttersta element som kallas rotelement och omfattar alla andra element. [Ray 2003, s.2]
Man kan säga att ett element är data omslutet av märkord. Man skiljer märkord från data med
hjälp av vinkelparenteser ”< >” och en sådan symbol tillsammans med respektive märkord heter
tagg. T.ex. märker man ut en adress i texten med att lägga till taggen <adress> i början av data.
För att utmärka slutet av ett element, använder man samma tagg som man började elementet
med. Skillnaden är att man använder snedstreck innan märkordet. T.ex. </adress>.
Nedan kan man se ett exempel på adresselementet:
<adress> Norra Bantorget 14
<trappa/>
<postkod>17321 </postkod>
<postort> Stockholm </postort>
</adress>
13
Text i XML räknas också som XML-noder. Text som ligger inuti ett XML-element kallas för en
textnod.
Förkunskaper
18
Som framgår av exemplet innehåller elementet ”adress” andra element som ”trappa”, ”postkod”
och ”postort”. Ett element kan innehålla text, andra noder av olika typer som element,
kommentarer, texter eller det kan vara tomt. Ett tomt element innehåller inga data och märks ut
endast med en tagg. Man måste lägga till ett snedstreck efter märkordet för att ange att
elementet är tomt. T.ex. <trappa /> i exemplet ovanför. Man kan lägga till extra information till
varje element med hjälp av attribut. Ett attribut definierar en egenskap hos ett element genom att
förknippa ett värde till ett namn efter märkordet i starttaggen. T.ex. <adress typ = ”företag”>. På
så sätt kan man specificera att adressen tillhör ett företag. Attributnamnet kommer först.
Därefter kommer likhetstecken ”=” och till slut kommer värdet omringat av citattecken.
XML accepterades som gängse standard inom datorvärlden snabbt och många applikationer och
tekniker utvecklades för att kunna arbeta effektivt med XML-dokument. I fortsättning av detta
avsnitt kommer en kort presentation av de som är mest relaterade till examensarbetet, Nämligen
XML-parsning, XSLT och XPath.
2.1.1. XML-parsning
XML betraktas först och främst som ett dokumentformat. Syftet med XML-dokument är oftast
att ett datorprogram ska bearbeta dem men de bör även vara välformade och tydliga så att de
kan förstås av en människa. Man kan skapa ett XML-dokument i ett vanligt ordbehandlar-
program. Men program som vill läsa och använda XML-dokument behandlar dem sällan som
vanliga textfiler. Ett sådant datorprogram behöver kunna tolka olika XML-taggar och element
som finns i ett XML-dokument. Därför använder sådana program sig ofta av ett externt eller
inbyggt mjukvaruverktyg som kallas för XML-parser. XML-parsern är ansvarig för att dela in
ett XML-dokument i olika enskilda element, attribut och andra delar. Med andra ord levererar
en XML-parser XML-dokumenten till datorprogram styckvis. [Harold 2004, s.7]. Processen att
dela in XML-filer i enskilda, hanterbara delar som utförs av XML-parser kallas för parsning.
Som sagt är det inte ovanligt att XML-filerna skapas av människor i vanliga ordbehandlar-
program. Användaren definierar också sina egna element och taggar. Dessa kan orsaka många
fel som påverkar parsningen. T.ex. om användaren glömmer att stänga en starttagg med en
sluttagg. Därför har en mängd regler och restriktioner definierats för hur man skriver XML-filer.
Man säger att XML-dokument måste vara välformade och med det menas att de måste vara
skrivna enligt dessa regler och restriktioner. En av XML-parserns uppgifter är att kontrollera om
XML-dokumenten är välformade. Om parsern märker att gällande regler och restriktioner inte
har följts i dokumentet generar den ett felmeddelande och avslutar parsningen.
Utöver de restriktioner som finns för välformade dokument kan användaren definiera egna
restriktioner och regler. Dessa restriktioner används för att bestämma en syntax för hur man
skriver taggar och element och hur olika element förhåller sig till varandra. Det finns två sätt att
bestämma en sådan syntax: via DTD (Document Type Definition) eller via XML-Schema. DTD
är ett äldre sätt att skriva regler för XML-filer. Numera används ofta XML-Schema som
erbjuder mer möjligheter. Ett exempel för en regel i DTD eller XML-Schema kan vara det att ett
element måste obligatoriskt innehålla ett annat element. T.ex. vill man att alla ”datum”-element
ska innehålla ett ”år”-element.
I början av varje XML-fil kan man lägga till en speciell tagg för att utmärka syntaxen (XML-
schema eller DTD) som dokumentet har skrivits enligt. Denna tagg tillhör de taggar som kallas
Förkunskaper
19
”Processing instruction” och är endast till för att ge information till XML-parser eller andra
program som läser XML-filen. Processen att kontrollera om ett XML-dokument är rättskriven
enligt ett XML-Schema eller DTD kallas för validering. Nu för tiden har många av de XML-
parser som finns även för uppgift att validera XML-dokument. Man kan validera XML-
dokumenten med hjälp av vanliga webbläsare nuförtiden.
2.1.2. XSLT
Ett område där XML-filer används flitigt är då man vill överföra data mellan två olika
datorprogram. Man lagrar utdata från ena av datorprogrammet i en XML-fil och anger det som
indata i det andra programmet. Det kan hända att man inte kan använda utdata som lagrats i
XML-filer direkt och utdata måste justeras först eller anpassas för det program som tar emot det
som indata. T.ex. bearbetar man information om företagets produkter i en databas som ett lokalt
datorprogram tillhandahåller. Man vill se en del av informationen på företagets hemsida via
webbläsare. Det program som hanterar databasen antas kunna exportera databasen i XML-filer
med taggar för varje produkt, produktnummer, beskrivning, pris och så vidare. För att kunna
visa dessa XML-filer i en webbläsare bör de skrivas i HTML- eller XHTML-format (eXtensible
HyperText Markup Language).
Behovet att överföra XML-dokument till andra XML-dokument eller till andra dataformat ledde
till XSLT (eXtensible Stylesheet Language Transformations). XSLT är ett verktyg som
möjliggör att överföra XML-dokument till andra format. XSLT har utvecklats av W3C (World
Wide Web Consortium) och är en av dess rekommendationer [Tidwell 2008, s.1].
För att överföra ett XML-dokument med hjälp av XSLT till ett annat format definieras ett antal
regler som tillämpas på source-dokumentet för att kunna få ett dokument i det format som
önskas. Dessa regler lagras vanligen i ett separat dokument som kallas XSLT:s stilmall
(Stylesheet). XSLT-processor är ett verktyg som applicerar reglerna i en XSLT-stilmall på en
XML-fil och genererar data enligt det önskade formatet. Figur 2.1 visar hur dataöverföringen
med hjälp av XSLT sker. Numera har alla vanligt förekommande programmeringsspråk tillgång
till kodbibliotek som implementerar XSLT-processorer och man kan utföra överföringen via
programmering. Det finns dock XSLT-processor som kan installeras som ett ensamstående
program och man kan utföra överföringen utan att behöva skriva kod. Några av de mest kända
XSLT-processorer är Xalan, Saxon, Microsoft XSLT Processor, Altova XSLT Engine [Tidwell
2008, s20-23].
Figur 2.1- Dataöverföring för XML-filer med XSLT
XSLT-stilmallar är själva i XML-format. Med det menas att XSL är en uppsättning av XML-
element som med hjälp av dem transformerar XSLT-processorn ett XML-dokument till ett
annat format. Man kan tänka sig att varje regel i transformationen tillämpas som en
programmeringsfunktion på en nod eller en nodmängd som föreställer funktionsparametrar.
Dessa funktioner i XSL kallas för mallar (Templates) och man skriver dem med hjälp av XML-
elementet <xsl:template >. Noden <xsl:template > använder attributet ”match” för att verifiera
XML-fil
XSLT
Stylesheet
XSLT
Processor
Transformerad
XML-fil
i nytt format
Förkunskaper
20
vilka noder i källdokumentet mallen tillämpas på. Vanligen börjar man med en mall som
tillämpas på källdokumentets rotelement. Om man tilldelar ”match”-attributet ett snedstreck
påvisar man att mallen tillämpas på rotelementet:
<xsl:template match=”/”>
</xsl:template>
I varje mall kan man skriva text som kommer att publiceras direkt i transformerade dokumentet.
Man kan använda olika XSL-instruktioner i form av XML-element som utgör olika funktioner.
Inuti varje mall kan man välja andra mallar som måste tillämpas i ett speciellt läge. Med andra
ord kan en mall tillämpa andra mallar. Detta sker med hjälp av XML-elementet <xsl:apply-
templates />
För att förtydliga hur mallar fungerar i XSLT anta att XML-elementet nedan ska skrivas i vanlig
text med hjälp av en XSLT-processor.
<adress> Norra Bantorget 14
<trappa/>
<postkod>17321 </postkod>
<postort> Stockholm </postort>
</adress>
Anta att elementet <adress> ligger direkt under rotelementet av källdokumentet. Stilmallar som
kommer nedan kan lagras i ett XSL-dokument för att transformera elementet <adress> till
vanlig text.
<xsl:template match = ”/”>
<xsl:apply-templates select=”adress”/>
</ xsl:template >
<xsl:template match = ”adress”>
<xsl:value-of select=”.”/>
<xsl:text > </xsl:text >
<xsl:value-of select=”trappa”/>,
<xsl:text >
</xsl:text >
<xsl:value-of select=”postkod”/>
<xsl:text >
</xsl:text >
<xsl:value-of select=”postort”/>
</ xsl:template >
I exemplet finns två mallar. XSLT-processorn tillämpar den första mallen när den parsar
rotelementet i källdokumentet. Denna mall gör ingenting annat än att tillämpa mallen som
matchar elementet <adress> i källdokumentet. XSLT-processorn väljer alla adresselement i
källdokumentet och tillämpar den andra mallen, vilken tar elementet <adress> som parameter,
på dem. I vårt fall finns bara ett adresselement som innehåller texten ”Norra Bantorget 14”.
Förkunskaper
21
Första raden av andra mallen innehåller XSL-instruktionen <xsl:value-of >. När XSLT-
processorn påträffar elementet <xsl:value-of> väljs den eller de XML-noder som påpekats i
attributet ”select” och returnerar deras text. Punkten som tilldelats attributet ”select” i första
raden av andra mallen syftar på den nod som just nu mallen tillämpas på. En sådan nod
benämns för kontextnod. Med andra ord talar första raden av andra mallen om för XSLT-
processorn att den ska välja texten av den nod som mallen tillämpas på. XSLT-processorn
kommer att publicera texten ”Norra Bantorget 14” i resultatet.
Nästa rad av mallen innehåller XML-elementet <xsl:text>. När XSLT-processorn når fram till
det elementet i en mall kommer den att skriva texten inuti elementet direkt ut i resultatet. I andra
raden av mallen finns det bara ett mellanslag som text i elementet <xslt:text>. Om man inte
skriver denna rad i mallen kommer text som skrivs ut efteråt direkt efter ”Norra Bantorget 14”
utan mellanslag.
Tredje raden av mallen ger instruktionen till XSLT-processorn att texten av ”trappa”-elementet
måste skrivas ut. Eftersom ”trappa”-elementet är ett tomt element händer inget. Efter elementet
<trappa /> finns ett kommatecken. Kommatecknet räknas som text i XSL-mallen och all text
som finns i en mall kommer att skrivas ut i resultatet utan inga förändringar. Nästa rad i mallen
innehåller igen elementet <xsl:text> och leder till att XSLT-processorn lämnar nuvarande raden
i resultatdokumentet och allt skrivande i fortsättningen sker i en ny rad. Detta händer på grund
av att <xsl:text> innehåller ett nyradtecken. Resten av mallen kommer först att skriva ut texten
av ”postkod”-elementet. Sedan kommer XSLT-processorn att välja en ny rad för skrivande på
grund av det andra <xsl:text> i mallen. Till slut skrivs ut texten av ”postort”-elementet.
Resultatet av transformationen är ett dokument som innehåller texten:
Norra Bantorget 14
17321
Stockholm
XSLT kan klara av de mest invecklade transformationerna. XSLT version 2 som är den
nuvarande aktuella versionen har många möjligheter och kan betraktas som ett fullkomligt
programmeringsspråk. De noder som en mall i XSLT ska tillämpas på väljs med hjälp av ett
särskilt språk som kallas för XPath. Med andra ord måste allt som tilldelas attributen i XSL-
elementen skrivas i XPath-format. Därför introduceras XPath kort i nästa avsnitt.
2.1.3. XPath
XPath kan betraktas som kärndelen i XSLT. Det har uppgetts att XPath är den bäst kända
modallogikstillämpningen hittills [Marx 2009, s.112]. Modallogik är samma som första
ordningens logik som har berikats med två operatorer:
att visa möjlighet. Fast moderna implementeringar av modallogik har fått ännu fler operatorer.
PDL (Propositional Dynamic Logic) är en av de nya versioner av modallogik som utvidgar den
traditionella modallogiken med nya operationer. Enligt [Marx 2009, s.114] är XPath 1.0 nästan
Förkunskaper
22
identisk med PDL.14
Hur som helst betraktas modallogik som ett språk för att beskriva
grafliknande datastrukturer och XPath beskriver syskonordnade träd (Sibling Ordered Trees)
[Marx 2009, s.112].
Som sagt är XPath 1.0 ett språk för att adressera olika noder i ett XML-dokument. XPath har
inspirerats av Unix sökvägar (Paths). XPath-instruktioner beskriver vägar att resa via ett XML-
dokument. Med XPath-instruktioner kan man välja första eller sista eller tionde "adress"-noden
som finns i ett XML-dokument. Det går att välja ett ”företag”-element vars ”namn”-attributet är
lika med Scania från ett XML-dokument som innehåller information om företag. Man måste
komma ihåg att XPath används i de XML-dokument som har parsats. Det innebär att man inte
har tillgång till alla detaljer på samma sätt som de finns i det ursprungliga XML-dokumentet.
XPath betraktar XML-dokumentet som ett träd av noder. Det finns olika typer av noder i XPath
[Tidwell 2008, s.46], nämligen:
Dokumentnod (Varje XML-dokument har bara en dokumentnod)
Elementnoder
Attributnoder
Textnoder
Kommentarnoder
”Processing-instruction”-noder
Namnrymdnoder
Dokumentnod är samma som rotelement som påpekades i början av detta avsnitt (se sidan 18).
Det är en nod som omfattar alla andra noder och i XPath beskrivs den med hjälp av ett
snedstreck ”/”. Varje element i XML-dokumentet representeras med en XPath-elementnod. En
elementnod räknas som förälder av sina attributnoder. Varje textnod innehåller texten av
respektive elementnod. Kommentarer är de noder som bara har värde men inget namn och
beskriver de kommentarer som finns i XML-dokumentet. För mer information om
namnrymdnoder och ”Processing-instruction”-noder kan de intresserade titta på de oräkneliga
olika referenser som finns i området bland annat: [Harold 2004], [Ray 2003] och [Tidwell
2008].
För att bläddra igenom de olika noder som finns i ett XML-dokument har några axlar definierats
i XPath. Samma exempel som har använts i avsnittet XML och avsnittet XSLT används här för
att få en snabb överblick över olika navigerings axlar i XPath. (Beskrivning av de olika axlarna
har gjorts med hjälp av [Tidwell 2008, 62-65])
<adress> Norra Bantorget 14
<trappa/>
<postkod>17321 </postkod>
<postort> Stockholm </postort>
14
Maarten Marx i [Marx 2009, s.114] skriver att om man abstraherar bort datainnehållet av XML-
dokumenten och håller sig till skelettet, det som är kvar är den navigerbara kärnan som kallas för core
XPath 1.0 och det är core XPath 1.0 som han tycker det är identiskt med PDL.
Förkunskaper
23
</adress>
Första axeln är barnaxeln som används för att bläddra genom barnnoder av kontextnoden. För
att välja en barnnod räcker det att skriva dennes namn direkt. I exemplet ovan ”postkod ”-noden
är barnet av adress. I ett XPath-uttryck där kontextnoden är en ”adress”-nod räcker det att skriva
”postkod”. Ett annat sätt att nå fram barnet är att skriva "child::postkod". På det sättet anges
konkret att barnet postkod bör väljas från barnaxeln som innehar alla barnen av kontextnoden.
Den andra axeln är förälderaxeln. För att ha tillgång till föräldernoden till den aktuella
kontextnoden kan man använda sig av två punkter och ett snedstreck ”../” eller man kan skriva
”parent::adress”. Nästa axel är den axeln som påpekar på själva kontextnoden. Som sagt (Se
sidan 20, andra stycket) kan man använda sig av en punkt som angetts i exemplet för XSLT
(<xsl:value-of select=”.”/>) eller man kan skriva "self::node()" eller "self::*".
Attributaxeln är den axeln med vilken man kan nå en nods attribut. I XPath visar man detta med
hjälp av ”snabel-a” som följs av attributnamnet ("@attributnamn") eller med hjälp av
”attribute::” följt av attributnamnet. Två andra axlar som finns används för att nå kontextnodens
följande noder eller föregående noder. I XPath anges de två axlarna som nodnamn med prefixen
"following::" eller "preceding::". Kontextnodens följande och föregående noder kan
specificeras mer via axlarna menade för följande syskon eller föregående syskon (preceding-
sibling:: och following-sibling::). Kontextnodens syskonnoder är de noder som har samma
förälder som kontextnoden. I exemplet ovan är <trappa>, <postkod> och <postort> syskon. Man
kan nå kontextnodens barnbarnnoder eller förfadernoder med hjälp av "descendant::" och
"ancestor::”. XPath har ytterligare axlar som inte har kommit med i den här korta
presentationen.
Utöver XPath-axlar kan man ange villkor för att välja noder i XPath. Villkor skrivs inuti
hakparenteser. Till exempel om man skriver child::adress[10] innebär det att man vill komma
fram till tionde ”adress”-noden som är kontextnodens barn. XPath innehåller olika operatorer
såsom relationsoperatorer och logiska operatorer. Det finns en del funktioner också som hjälper
utvecklaren. Funktioner som bestämmer nodernas typ, namn och position eller de funktioner
som utför olika operationer på textsträngar är några exempel. W3C har en utförlig specifikation
för XPath 15
där man kan bekanta sig mer med de möjligheterna som XPath erbjuder.
15
http://www.w3.org/TR/xpath/
Mjukvaruverktyg för villkorsanalys
25
3. Mjukvaruverktyg för
villkorsanalys
Detta kapitel beskriver det mjukvaruverktyg som jag har utvecklat under
examensarbetet. Denna mjukvara har skapats med hjälp av Java, HTML, XSLT, Java
Plugin Technology (Applets) och JavaScript. Uppgiften har delats in i två delar: att
skapa det användargränssnitt som möjliggör att evaluera villkoren i guidade metoder
baserat på inmatade parametrar. De två delarna kommer att presenteras i olika avsnitt
av detta kapitel. Sista avsnittet beskriver hur användargränssnittet har kopplats till
evalueringsramverket.
Som nämndes tidigare innehåller SDP3 PT en grafisk editor för att hjälpa metodingenjörerna
med att analysera guidade metoder (se avsnitt 1.3.). Det som metodingenjörer kräver är ett
verktyg med vars hjälp man kan analysera villkoren i guidade metoder. Detta verktyg bör
kopplas till den ovannämnda grafiska editorn. Att skapa ett fungerande verktyg som har
integrerats med SDP3 PT skulle säkert ta mer arbete och tid än ett normalt examensarbete.
Därför har jag avgränsat uppgiften. Avgränsningarna kommer att introduceras i första avsnittet
av detta kapitel.
I avsnitt 1.3. har påpekats att de villkor som finns i en guidad metod kan betraktas som satser i
satslogik. Dessa satser har byggts på olika typer av variabler som med hjälp av
relationsoperatorer jämförs med konstanta värden eller med andra variabler. När en guidad
metod tas i bruk i den verkliga miljön (d.v.s. när en guidad metod visas upp i SDP3) kan dessa
variablers värde läsas av en styrenhet eller flera styrenheter eller matas in av användaren.
Variablerna kan även användas för att spara felkoder skickade av olika fordonsdelar.
Eftersom SDP3 PT körs utan att datorn kopplas till bilen kan variablerna inte läsas av
styrenheter eller fordonet i SDP3 PT. Å andra sidan om man vill testa villkoren bör variablernas
värde genereras på något sätt. Ett alternativ är att skapa ett användargränssnitt som
metodingenjörerna matar in variablernas värde manuellt i och sedan analyserar resultatet av
villkorsevalueringen baserat på de inmatade värdena. Ett sådant användargränssnitt är
dynamiskt, och förändras med varje steg i en guidad metod. Därför har jag delat upp uppgiften i
två delar. Första delen presenterar en lösning för att skapa ett dynamiskt användargränssnitt som
möjliggör parameterförändringen16
. Andra delen handlar om hur man kan evaluera villkoren. De
två delarna kommer att beskrivas utförligare i det här kapitlet. Sista avsnittet av det här kapitlet
visar hur användargränssnittet kan kopplas till evalueringsramverket.
16
Jag har använt orden parameter och variabel växelvis. Därför att variabler i villkoren i en guidad metod
kan betraktas som parametrar i ett villkor som deras värde måste matas in.
Mjukvaruverktyg för villkorsanalys
26
3.1. Avgränsningar
Jag har valt två huvudsakliga avgränsningsområden som beskrivs nedan:
1- Jag valde att utveckla ett separat verktyg för att testa villkoren i guidade metoder. Alltså
utförs evalueringen inte i SDP3 PT utan den görs oberoende med hjälp av vilken
webbläsare som helst. Tidskostnaden skulle vara hög om man skulle bekanta sig med
SDP3 PT-koden och om man skulle välja rätt sätt att integrera evalueringsverktyget
med grafiska editorn i SDP3 PT. Fast jag har försökt välja de tekniker som kan
implementeras i SDP3 PT i framtiden.
2- Guidade metoder innehåller olika typer av villkor i olika delar av XML-filen (Under
olika XML-element). Som påpekats tidigare i avsnitt 1.2.2. kan guidade metoderna
innehålla ett eller flera ”steg”-element. Varje ”steg” kan kopplas till andra ”steg”. För
att koppla ett steg till andra steg använder man sig av XML-elementet ”NästaSteg”.
Varje steg kan innehålla inget eller flera ”NästaSteg”-element. Varje ”NästaSteg”-
element innehåller inget eller högst ett ”villkor”-element. Villkor-element används i
andra delar av en guidad metod och inte bara under ”NästaSteg”-elementen.
Metodingenjörer vill kunna testa de villkoren också. Men för att hinna presentera ett
färdigt, fungerande verktyg valde jag att bortse från villkor som inte finns under
”NästaSteg ”-elementen. Fast samma kod med lite förändring bör även fungera för
andra villkor i guidade metoder.
3.2. Användargränssnitt för inmatning av
variablernas värde
Ett möjligt användargränssnitt för inmatning av variablernas värde bör vara dynamiskt. Med det
menas att samma användargränssnitt inte kan användas för alla guidade metoder eller för alla
steg inom en guidad metod. Beroende på den guidade metoden och det steg som
metodingenjörerna vill granska bör man skapa ett nytt användargränssnitt. Detta beror på att ett
sådant användargränssnitt är knutet till variabler definierade i villkoren. Tre fakta gällande
variabler gör användargränssnittet dynamiskt:
Olika steg och olika guidade metoder kan innehålla olika variabler
Beroende på hur variabler används har de uppdelats i olika typer. T.ex. de kan bekräfta
att ett fel har uppstått eller de kan innehålla en signal mottagen av en styrenhet eller de
kan spara resultatet av en operation i steget.
Variablers värde kan ha olika datatyper. En del kan bestå av numeriska värden som i sin
tur kan delas till heltal och flyttal, en del kan innehålla textsträngar och det finns
variabler som kan ta booleska värden (sann eller falsk).
Att hantera användargränssnittet dynamiskt är svårare än att skapa ett statisk användar-
gränssnitt. Om man antar att man bör ha en textbox för en variabel i ett steg av en guidad metod
och i ett annat steg bör man ha tio textboxar eller fem kryssrutor eller tre alternativknappar för
variablerna förstår man problematiken med att skapa användargränssnittet dynamiskt. I första
avsnittet av det här kapitlet beskriver jag hur användargränssnittet har skapats. Sedan kommer
en snabb utvärdering av implementeringsmetoden och till sist presenteras implementeringen
mer detaljerad.
Mjukvaruverktyg för villkorsanalys
27
3.2.1. Logiken i skapandet av användargränssnittet
Variablerna i villkoren i guidade metoderna har en viktig roll i ett användargränssnitt som ska
hjälpa till att evaluera guidade metoder. Man kan förknippa varje variabel som uppstår i ett steg
i en guidad metod med ett element i användargränssnittet. Den enklaste lösningen som kan
tänkas är att skapa en textbox för varje variabel med vars hjälp kan metodingenjörerna mata in
önskat värde för variabeln sedan. Detta värde kommer att användas vid evalueringen av
villkoren i steget.
En tänkbar förbättring på denna lösning är att förhindra upprepningar av en
användargränssnittskomponent förknippad med en variabel i villkoren i ett steg av en guidad
metod. T.ex. anta att det finns en guidad metod som innehåller ett steg med namnet ”step0”.
Detta steg kan kopplas till tio olika steg som var och en kan bli det aktuella steget under olika
villkor. Med andra ord tillsluter detta steg tio ”NästaSteg”-element. Anta att varje av de tio
”NästaSteg”-elementen omfattar ett villkor som i sin tur innehåller variabeln ”x”. Baserat på
olika värde som ”x” får kan något av dessa steg som är kopplade till ”step0” bli aktuellt. T.ex.
om x har värdet 1 blir steget med namnet ”step1” aktuellt, om x har värdet 2 blir steget med
namnet ”step5” aktuellt och så vidare. Anta nu att man skapar ett användargränssnitt för steget
”step0” för att värdesätta parametrarna i villkoren i de olika ” NästaSteg”-elementen.
Användargränssnittet skapas så att för varje variabel i ett villkor skapar man en textbox med
namnet av variabeln som etikett17
. Enligt det här exemplet kommer tio textboxar med etiketten x
att finnas i användargränssnittet. Dessa olika textboxar kan representeras med en enda textbox
istället för tio. På det sättet blir användargränssnittet mer tydligt och mindre otydlig.
En annan förbättring som kan göras på en lösning med endast textboxar i användargränssnittet
är att visa de möjliga värden som en variabel kan få, och påverkar resultatet av evalueringen av
villkoren, för användaren i användargränssnittet. I exemplet, som nämndes i förra stycket,
antogs att variabeln ”x” upprepades i villkoren under olika ”NästaSteg”-elementen som tillhörde
steget med namnet ”step0”. Om man visar variabeln ”x” som en textbox på användar-
gränssnittet kan användaren inte gissa vilket värde av ”x” leder till att ett villkor under ett
”NästaSteg”-element blir sant och därmed vilket steg aktuellt. Användaren kommer att vara
tvungen att kontrollera om och om guidade metoden och villkoren för att se de värden som
spelar in. För att underlätta test av villkoren kan man visa de konstanta värden som jämförs med
en variabel upp framför användargränssnittkomponenten som är förknippad till variabeln. Man
kan visa dem som en lista, eller det som kallas ”Combobox” i programmerares jargong, i fall att
variabelns datatyp är textsträng. I fall av numeriska datatyper kan dessa konstanta värden
skrivas upp direkt framför användargränssnittkomponenten.
Som påpekades tidigare finns det olika typer av variabler i villkoren i guidade metoder. En
variabel själv kommer i form av ett XML-element i en guidad metod. Variabelns typ anges av
ett annat XML-element som ligger under variabelns element. Med närmare undersökning kan
man märka att några av dessa variabeltyper kan visas i användargränssnittet med lämpligare
komponenter än textboxar. T.ex. det finns variabler som innehåller resultatet av en operation
som kan vara lyckat eller misslyckat (OK/FAIL). Ett alternativknapp kan vara en bättre
komponent för att presentera sådana variabler i användargränssnittet i jämförelse med en
textbox. Ett annat exempel är de variabler som innehåller en felkod och är tecken på om ett fel
17
Label
Mjukvaruverktyg för villkorsanalys
28
har uppstått eller inte. Sådana variabler kan presenteras bättre med hjälp av kryssrutor än
textboxar. Därför att det är onödigt att tvinga användarna att skriva en text som beskriver ett fel
när man kan välja det endast med att kryssa en ruta.
Med dessa antagande har jag försökt hitta rätt mjukvaruteknik för att skapa det dynamiska
användargränssnittet. I nästa avsnitt argumenteras för de tekniker som har använts.
3.2.2. Utvärdering
För att implementera ett dynamiskt användargränssnitt granskades två huvudsakliga alternativ.
De är:
Eftersom SDP3 PT är ett Eclipse-plugin skrivet i Java var det självklara alternativet att
skapa användargränssnittet med hjälp av programmeringsspråket Java. Man kan parsa
guidade metoderna, som är i form av XML-filer, med en av de olika kodbibliotek som
finns för XML-parsning i Java. Sedan skulle man kunna välja unika variabler i varje
steg (Upprepningarna av variablerna i villkoren behöver inte vara med). Baserat på
typen av dessa unika variabler skulle en komponent i användargränssnittet skrivet med
Java-kodbibliotek skapas.
HTML används som standard språk för att visa information i olika webbläsare. HTML
har stöd för olika användargränssnittkomponenter som med hjälp av dem matar
användarna in information i en webbapplikation. Man använder HTML-formulär för att
skapa sådana användargränssnittkomponenter. Varje Eclipse-plugin kan använda en
intern webbläsare som finns i Eclipse för att visa lokala HTML-filer eller de som finns
på en server (En annan dator tillägnad att utföra tjänster för andra datorer). Det innebär
att om man skapar användargränssnittet i form av HTML är det möjligt att även visa det
med hjälp av den interna webbläsaren som finns i SDP3 PT utöver de externa
webbläsarna. För att skapa användargränssnitt i form av HTML kan man göra en XSL-
transformation. Användandet av XSLT för att transformera olika XML-filer till HTML
är vanligt. Ett enkelt exempel är att skriva en mall i XSL med vars hjälp förvandlar man
varje variabel befunnen i ett villkor till en textbox i en HTML-form.
Olika alternativ har ofta båda nackdelar och fördelar samtidigt. Nedan jämförs de två
alternativen:
Användargränssnitt i form av HTML kan visas i olika färdiga webbläsare och är inte
beroende av miljön. Medan användargränssnitt i form av Java måste visas upp i ett
Java-program med ”Java Virtual Machine” installerad på datorn. Med andra ord måste
man skriva ett program för att visa användargränssnittet.
XSLT-stilmallar kräver mindre kod i jämförelse med parsning av XML-filer i Java. För
att utföra det som ett XPath-uttryck med några få ord gör behöver man ofta skriva några
rader kod i Java.
Att skapa användargränssnitt med Java kräver extra operationer. T.ex. måste man skapa
och öppna en fil i Java-kod för att läsa en guidad metod, man måste använda sig av ett
kodbibliotek för att parsa XML-filen, man måst skapa ett fönster i användargränssnittet
som är en Java-klass. Man behöver inte tänka på sådana detaljer som är orelaterade till
användargränssnittet om man använder HTML. Man kan säga att man kan ha ett mer
abstrakt och förfinat MVC (Modell View Controller)-mönster om man använder XSLT
och HTML.
Mjukvaruverktyg för villkorsanalys
29
Som nämndes i förra punkten att skapa användargränssnitt i Java behöver fler
operationer utföras än att skapa användargränssnitt i HTML-format. Fler operationer
medför mer potential för felinträffande.
Det finns starkare verktyg för att felsöka och avlusa Javakod än de verktyg som finns för
att avlusa XSLT-kod.
Ramverk som evaluerar villkor bör skrivas i Java, eftersom SDP3 PT är skrivet i Java.
Användargränssnitt som är skrivet i Java är självklart kompatibelt med ett sådant
ramverk och kan användas direkt, medan man behöver använda sig av speciella tekniker
för att koppla ett användargränssnitt i HTML till ett Java-ramverk. Detta är svårare och
mer invecklat.
Jag valde att skapa användargränssnittet i form av HTML. Tanken var att kunna utföra ett
verktyg i ramen av examensarbetet och användandet av XSLT bedömde jag kräva mindre
programkod.
3.2.3. Implementering
Utöver det som nämns i avsnitt 3.2.1 ”Logiken i skapandet av användargränssnittet” lade jag till
andra möjligheter i de XSLT-stilmallar som jag skrev för att skapa användargränssnittet i
HTML-format. Att användaren med en snabb blick kan se att steg som ska granskas är kopplade
till vilka andra steg och under vilket villkor blir de steg aktuella är det något som kan underlätta
analys av villkoren. Därför implementerade jag användargränssnittet så att namnet av de steg
som kommer efter det aktuella steget och dess respektive villkor (skriven i form av logiska
satser) visas för användaren. Utöver det finns två knappar i användargränssnittet för varje steg i
en guidad metod, den första för att återställa användar-gränssnittet till det första läget, innan
eventuella inmatningar av användare. Den andra knappen används för att användaren ska kunna
evaluera villkoren. Denna knapp måste kopplas till evalueringsramverket. När användaren
trycker på denna knapp evalueras olika villkor beroende på de värden som har angetts för
variablerna och resultatet av evalueringen visas för användaren.
En annan möjlighet som lades till är länkad till en special variabeltyp. En av de variabeltyper
som finns i guidade metoder är fördefinierade variabler. Sådana variabler har ett startvärde
vilket definieras utanför ”steg”-element i guidade metoden. Dessa variabler kan användas i
villkoren precis som andra variabler. Med möjligheten att se deras startvärde i
användargränssnittet kan behovet att kontrollera den guidade metoden efter startvärdet upphöra.
Figur 3.1 indikerar de olika processer som utförs med hjälp av XSLT-stilmallar som jag har
skrivit för att skapa användargränssnittet i form av HTML. Ordningen av ovaler i figuren är inte
exakt och processerna sker inte stegvis.
Mjukvaruverktyg för villkorsanalys
30
Figur 3.1. olika processer som utförs för att skapa användargränssnittet i HTML-format med
hjälp av XSL-transformationer. Ordningen är inte exakt som bilden och processerna sker inte
stegvis.
Bilaga B visar ett artificiellt exempelsteg ”TestSteg” av en guidad metod i form av ett möjligt
XML-element. Steget kopplas till fyra andra steg via ”NästaSteg”-elementen. För att förstå hur
användargränssnittet för parameterförändringen kan se ut används påhittade steg. Resultatet av
XSL-transformationen med de stilmallar jag har skrivit som tillämpas på detta steg ser ut som
figur 3.2.
Välj ett Steg
Skriv namnet av alla
steg som är Kopplade
till detta steg -----
Skriv ut villkoren
efter namnet
För varje variabel i villkoren
skapa ett
Användargränssnittkomponent
Om variabeln jämförs med
konstanta värde skriv de
konstanta värden direkt ut eller
visa dem i en ”comboBox”
Om variabeltypen tillhör
den fördefinierade typen
visa upp dess startvärde
Skapa knappar för
evaluering av villkor och
återställning av gränssnittet
Mjukvaruverktyg för villkorsanalys
31
Figur 3.2. Användargränssnitt för parameterförändring för det påhittade steget i bilaga B i
HTML-format skapat av XSL-transformation.
Som framgår av figuren kommer under stegets namn ”TestSteg” namnen av de fyra steg som
steget är kopplade till. Under namnet av varje steg kommer respektive villkor i en form liknande
satslogik. Som man kan se i bilaga B är villkoren i form av XML-elementen och XSL-
transformationen förändrar dem till dessa logiska satser. Efter sista steget kommer
användargränssnittkomponenter förknippade till variabler som spelar in i villkoren. I det här
fallet finns tre variabler i de befintliga villkoren i steget ”TestSteg”, nämligen motorTemperatur,
motorVarv och oljeNivå. Framför namnet av varje variabel finns en parentes där variabeltypen
står. Som märks på figuren förekommer variabeln motorTemperatur fyra gånger i villkoren
under steget men det finns bara en unik användargränssnittkomponent förknippad med
”motorTemperatur”.
Efter användargränssnittkomponenten för varje variabel (I det här fallet en textbox för varje
variabel) skrivs de konstanta värde som variabeln jämförs med. Om variablerna hade textsträng
som datatypen (oljeNivå i exemplet) kommer en ”Combobox” med olika möjliga värde för
variabeln att finnas framför textboxen. En annan punkt som bör uppmärksammas är det att
variabeln ”motorVarv” har två gånger jämförts med värdet ”2000”. Men värdet ”2000” har
skrivits endast en gång framför textboxen. Med andra ord upprepas redundanta konstanta värde
inte i användargränssnittet.
Mjukvaruverktyg för villkorsanalys
32
För att implementera transformationen har jag skrivit en XSL-fil runt 450 rader XSL-kod. Jag
använde XSLT version 1.0 eftersom den version av Java-kodbibliotek som används i SDP3 PT
stöder det. Utöver det har jag skrivit en CSS-fil för att hantera HTML:s olika stillar. I
fortsättningen tillkommer två vanliga fall som man måste ha hänsyn i samband med XSL-
transformationer: gruppering i XSLT och användande av olika XSLT-processor.
3.2.3.1. Gruppering i XSLT
När man skriver XSLT-stilmallar väljs den nod eller de noder som mallen måste tillämpas på
genom attributet ”match”. Ett XPath-uttryck tilldelas attributet. Ofta vill man gruppera de noder
som en stilmall tillämpas på efter en egenskap hos dem. I början av detta avsnitt (3.2.3.) ses att
variabeln x förekommer fyra gånger i villkoren men man vill ha att det ska finnas bara en
användargränssnittkomponent för de olika upprepningarna av x. Med andra ord är det bara de
unika värde av x som spelar roll. Med andra ord måste variablerna i villkoren grupperas efter
variablers namn. Detta är ett exempel av gruppering i XSLT.18
Gruppering i XSLT version 2.0 görs enkelt och det finns särskilda instruktioner för det [Tidwell
2008]. Gruppering i XSLT version 1.0 kan göras men det är inte självklart, med konkreta
instruktioner. Det finn några metoder för att utföra gruppering i XSLT 1.0 [Tidwell 2008, s221-
228]. Problemet med att använda de metoderna för mig var det att de exemplen som beskrev de
metoderna har använts i samband med XML-element som låg i samma nivå av XML-filens
hierarki. Men jag behövde gruppera de XML-noder som inte var syskon (De låg inte på samma
nivå av XML-filen). Därför utvecklade jag en annan lösning med hjälp av rekursiva mallar och
<xsl:variable>. Nedan sammanfattas den lösningen.
Som påpekades i avsnittet 2.1.2 när man definierar en XSL-mall bestämmer man med attributet
”match” de noderna som mallen tillämpas på. I XSLT 1.0 finns även möjligheten att definiera
egna stilmallar utan att de behöver matcha ett eller flera XML-element i XML-källdokumentet.
Man kan definiera en mall som inte har attributet ”match” utan attributet ”name”. Sedan kan
man tillämpa mallen inom en annan mall genom XSL-elementet <xsl:call-template name=””>.
Koden nedan visar ett exempel på hur man skriver sådana mallar:
<xsl:template match =”Steg”>
<xsl:value-of select=”./Namn”>
<xsl:text>
</xsl:text>
<xsl:call-template name= ”variabelhantering” />
</xsl:template>
<xsl:template name= ”variabelhantering”>
/* Kommentar: Här behövs bekantskap med xsl:param innan mer förklaring.*/
</xsl:template>
18
De som känner till relationsdatabaser vet att gruppering är viktig i databaser och det utförs i SQL med
hjälp av ”group by” uttrycket.
Mjukvaruverktyg för villkorsanalys
33
I exemplet finns två mallar: första tillämpas på XML-elementen ”Steg” i källdokumentet, den
andra har inget ”match”-attribut utan ett ”name”-attribut. Det vill säga att den mallen måste
anropas inom en annan mall. I det här fallet anropas den inom första mallen. Anropet sker via
<xsl:call-template>. Man kan skicka vidare en del information eller ett nodset till dessa
egendefinierade mallar med hjälp av XSL-elementen <xsl:param> och <xsl:with-param>.
Lösningen är baserad på att använda en mall liknande den. Denna mall ska få det nodset som
bör bearbetas som parameter. Inom mallen ska de nödvändiga operationerna utföras på det
första elementet i nodsetet. Sedan anropar mallen sig själv fast inte med samma nodset som
parameter. Man tar bort de noderna som är gemensamma med första noden i nodsetet och
använder resten som parameter igen. Detta är exakt som att skriva rekursiva funktioner i ett
vanligt programmeringsspråk. Rekursionens basfall händer när parametersnodsetet är tomt.
Nedan finns koden som kan användas för att skriva namnet på unika variabler inom ett steg.
<xsl:template match =”Steg”>
<xsl:value-of select=”./Namn”>
<xsl:text>
</xsl:text>
<xsl:call-template name= ”variabelhantering” >
<xsl:with-param name= ”variabler” select= ”.//variabel” >
</xsl:call-template >
</xsl:template>
<xsl:template name= ”variabelhantering”>
<xsl:param name= ”variabler” />
<xsl:if test = ”$ variabler[1]/node()” >
<xsl:variable name=”currentVariable” >
<xsl:value-of select = ”$ variabler[1]/namn” >
<xsl:variable>
<xsl:value-of select = ”$ currentVariable” >
<xsl:text>, </xsl:text>
<xsl:call-template name= ”variabelhantering” >
<xsl:with-param name= ”variabler” select= ”$variabler[namn != $currentVariable]” >
</xsl:call-template >
</xsl:if >
</xsl:template>
Första mallen anropar mallen ”variabelhantering”. Mallen ”variabelhantering” tar emot en
parameter med namnet ”variabler”. Anropet i första mallen sker medan man skickar alla
”variabel”-noder under nuvarande steg som parameter till mallen ”variabelhantering”. Mallen
”variabelhantering” kontrollerar rekursionens basfall genom att testa om första ”variabel”-noden
i parametern är en nod. Om svaret är nej då händer ingenting och mallen lämnas. I annat fall
definieras först en XSL-variabel som lagrar namnet av första ”variabel”-noden. Sedan skrivs
detta namn i resultatet. Därefter kommer ett kommatecken och till slut anropas själva mallen
”variabelhantering” men bara med de noder som inte har samma namn som första ”variabel”-
noden. Det är anmärkningsvärt att när man refererar till en variabel eller en parameter i XSLT
Mjukvaruverktyg för villkorsanalys
34
använder man tecknet ”$” innan parameterns/variabelns namn. Om man tillämpar de två
ovannämnda mallarna på det steg som finns i bilaga B, kommer resultatet att se ut som nedan.
TestSteg
motorTemperatur, motorVarv, oljeNivå,
3.2.3.2. Användande av olika XSLT-processor
Som nämndes i avsnitt 2.1.2. finns det många XSLT-processorer. Resultatet av en
transformation med två olika XSLT-processorer kan vara olika. Det kan vara så att en XSLT-
transformation fungerar i en XSLT-processor, men inte i en annan. Därför är det viktigt att
använda exakt den XSLT-processorn som slutanvändaren har tillgång till. Ett annat förslag är
att testa mallarna med hjälp av några XSLT-processorer. Jag använde XSLT-processorn Xalan
för att skriva XSLT-stilmallar. När jag försökte ansluta användargränssnittet till
evalueringsramverket använde jag mig av Java:s standard kodbibliotek för att utföra
transformationen. Den versionen av Java (Jre 1.6.0_1) använde JAXPSAXProcessor som den
förinställde XSLT-processorn.
Transformationen fungerade med Xalan men inte med JAXPSAXProcessor. Det fanns ett
felmeddelande i två stilmallar som var avsedda att matcha XML-elementen <and> och <or>. De
två stilmallarnas första rad var <xsl:template match =”and” > och <xsl:template match=”or” >.
Som ses skrev jag namnet av XML-elementen <and> och <or> direkt som XPath-uttryck.
XPath har logiska operatorer som används för att skriva XPath-villkor. Orden ”and” och ”or” är
två av dessa operatorer som används i XPath. XPath-villkor bör stå inom hakparenteser och en
XSLT-processor bör inte ”and” och ”or” som logiska operatorer utanför hakparenteser. Xalan
fungerade så att den tolkade ”and”/”or” som reserverat ord i XPath när de var inom
hakparenteser men JAXPSAXProcessor tolkade de som ”and”/”or”-operatorer var som helst i
ett XPath-uttryck. För att kringgå problemet ändrade jag malldefinitionen på det här sättet:
<xsl:template match =”*[name()= ’and’]” >, respektive <xsl:template match =”*[name()=
’or’]” >.
3.3. Evalueringsramverket
Evalueringsramverket är den delen av arbetet som har för uppgift att evaluera villkoren i
guidade metoder. Tre olika sätt för att implementera ett sådant ramverk har granskats under
arbetet. I avsnittet ”Utvärdering” kommer de tre sätt att presenteras och utvärderas. Sedan
kommer i avsnittet TDD (Test Driven Development) sättet som ramverket har testats med att
presenteras. Till slut kommer mer detaljer om implementeringen i sista avsnittet av
evalueringsramverket.
3.3.1. Utvärdering
Tre olika sätt för att implementera ett evalueringsramverk kunde tänkas. Första att använda ett
befintligt ramverk som finns i SDP3, andra genom regelbaserad programmering och till slut via
Mjukvaruverktyg för villkorsanalys
35
utvecklingen av ett nytt ramverk i Java. Jag valde den sista för att evaluera villkoren i guidade
metoder. Nedan kommer en kort presentation och utvärdering av de tre metoderna.
3.3.1.1. Villkorsramverket i SDP3
Det är SDP3:s uppgift att visa guidade metoderna för mekanikern vid felsökning. Även om
guidade metoder under körning av SDP3 lagrats i databasen [Mattsson 2009], och därför behövs
ingen XML-parsning, bör villkoren evalueras för att bestämma det aktuella steget. SDP3 har ett
eget ramverk för hantering och evaluering av villkoren. Villkorsramverket i SDP3 har skrivits i
programmeringsspråket Visual C++ medan SDP3 PT är skrivet i programmeringsspråket Java.
Villkorsramverket i SDP3 finns som ett DLL (”Dynamic-Link Library”). Ett DLL är en
uppsättning av små program som kan anropas av ett annat program medan det körs på datorn.
För mer information om DLL se [Puntambekar 2008, s.(4‒5)].
Eftersom ett DLL anropas under körning av ett program och systemet betraktar DLL:et som
maskinkod kan man använda ett DLL via olika programmeringsspråk. Java stöder DLL-anrop
genom JNI (Java Native Interface). JNI är själv ett ramverk i Java som har utformats så att Java
kan använda programkod som har skrivits i andra språk än Java. Med hjälp av JNI och
villkorsramverkets DLL i SDP3 kan man utföra villkorsevalueringen i SDP3 PT. Den mest
påtagliga fördelen med att använda villkorsramverket i SDP3 för evalueringen av villkoren i
guidade metoder i SDP3 PT är lättare underhåll. Men det finns en anledning som säger emot att
använda evalueringsramverket i SDP3 för att evaluera villkoren i SDP3 PT. Först har
kodbiblioteket som använts i SDP3 för evaluering (villkorsramverket) inte skrivits med hänsyn
till att det ska användas i externa program som SDP3 PT. Det leder till att villkorsramverket i
SDP3 är beroende av andra delar av SDP3 och om man vill använda det bör man använda andra
kodbibliotek i SDP3. Kort sagt att använda villkorsramverket i SDP3 i sin befintliga form för att
evaluera villkoren medför onödigt komplexitet och extra operationer. Därför valde jag att inte
använda detta alternativ för evalueringen.
3.3.1.2. Regelbaserad programmering
Regelbaserade system är närvarande i vetenskap, teknik och vardagliga livet ofta utan att någon
märker deras design eller tänker på deras djupare teori och det händer att man använder dem
utan att ens tänka på det [LIGÊZA 2006, S.V]. Ett regelbaserat system är en sort av ett
kunskapsbaserat system (KBS: Knowledge-Based System) i form av regler. En regel är ett
syntaktiskt begrepp som uppger att påföljden P är ansluten till antagandet A. Regelbaserade
system användes ursprungligen i expertsystemsutveckling med användande av språk med högre
grad av uttrycksfullhet än satslogik och predikatlogik. [SOTTARA, 2010].
Huvuddelen av ett regelbaserat system är en regelmotor som evaluerar reglerna. Regelmotorn
fungerar med hjälp av en del regler som är skrivna i en specifik syntax. Reglerna tillämpas
sedan på inputdata. Med andra ord tar regelmotorn emot inputdata och en del regler skrivna i en
syntax förståeligt för regelmotorn och generar baserad på de båda resultatet. En av de mest
kända regelmotorerna som kan användas i Java är Jess19
(Java Expert System Shell). Jess är
skrivet i Java och det är lätt för applikationer skrivna i Java att Använda det [LIGÊZA 2006,
S.286]. Det finns många Java ramverk och API (Application Programming Interface) för att
19
För mer information om Jess: http://www.jessrules.com/
Mjukvaruverktyg för villkorsanalys
36
möjliggöra regelbaserade programmering. En av de mest kända är ”Java Rule Engine API” (JSR
94) 20
. JSR 94 använder Jess som regelmotor och om man vill få i gång det måste man installera
Jess på datorn. Utöver Jess och JSR 94 finns det många andra regelmotorer och Java-API som
möjliggör regelbaserad programmering i Java.
De flesta regelmotorer accepterar att reglerna skrivs i form av XML-filer. Fast de har sitt
specifikt format. Med hjälp av XSLT är det möjligt att transformera villkoren i guidade metoder
till reglerna enligt en regelmotors syntax. Med andra ord kan man med hjälp av en regelmotor,
ett kodbibliotek i Java som ansluter sig till denna regelmotor och två XSL-transformationer, ena
för att skapa användargränssnittet för parameterförändring och den andra för att skapa reglerna
för regelmotorn, utveckla ett verktyg för test och analys av villkoren i guidade metoder. Ett
hinder för att använda regelbaserad programmering som ett alternativ för villkorsevaluering i
SDP3 PT var behovet till regelmotor. Om man använder regelbaserad programmering bör man
använda och installera en regelmotor. Jess som är en av de mest kända regelmotorer för Java får
användas i akademiskt syfte men är licensierad som kommersiell mjukvara och fick användas i
SDP3 PT endast för en kort period. De andra regelmotorer i Java behövde mycket forskning
forskas först om hur säkra och pålitliga de var.
Ett annat problem med att använda regelbaserad programmering är att det inte finns någon
gemensam standardsyntax för att skriva regler enligt. Några av dessa syntaxer är mer
begränsade och några kan vara mer kompatibla med villkoren i guidade metoder. Det krävdes
mycket tid för att utforska olika regelmotorer som finns och välja den som passar bäst. På grund
av detta valde jag att utveckla ett eget evalueringsramverk i java istället för att utföra det med
hjälp av regelbaserad programmering.
3.3.1.3. Evalueringsramverket implementerat i Java
Eftersom SDP3 PT är skrivet i Java var den självklara lösningen för att evaluera villkoren i
guidade metoder det att skriva programkod som hanterar evalueringen i Java. En sådan kod
måste parsa guidade metoder och läsa villkoren, få variablernas värde inmatat i
användargränssnittet av användaren och baserade på dem genomföra operationer förknippade
till relationsoperatorer och logiska operatorer. Jag tänkte skriva ett sådant program i Java inte
var så komplicerat och tidskrävande i jämförelse med de två andra metoderna (Att använda
villkorsramverket i SDP3 och att använda regelbaserad programmering). Denna lösning som jag
har implementerat presenteras ytterligare i avsnittet Implementering (3.3.3).
3.3.2. TDD (Test Driven Development)
”Program testing can be a very effective way to show the
presence of bugs, but it is hopelessly inadequate for showing
their absence!” Edsger W. Dijkstra
Test av mjukvara är en av de väsentliga delarna i mjukvarutillverkningsprocessen. TDD (Test
Driven Development) är en av de gängse metoderna nuförtiden och det är även den metod som
jag har försökt att använda för test av evalueringsramverket i Java.
20
För mer information om JSR 94: http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html
Mjukvaruverktyg för villkorsanalys
37
Grundidén i TDD är att man skriver först en enkel och lättförståelig programkod kallad testfall
som testar en del av mjukvaran som man vill utveckla och sedan skriver man själva
programkoden för den mjukvarudelen. På det sättet tvingas man att designa smådelar (enheter)
av programkoden. [Steinberg 2004, s.52] beskriver detta:
”By writing the test before the code, you are forcing yourself into a simple, bottom-up
design. In maintaining that order (test then code) you cannot get ahead of yourself on
design. ”
En annan fördel med att skriva tester för små enheter av kod är det att de kan betraktas som en
förklaring om hur programkoden bör användas. Om man skriver enkla tester kan de till och med
ersätta en del av programkodkommentarer.
En annan fördel med TDD är att testfallen kan fungera som en garanti att programmet fungerar
korrekt. När ett testfall skrivs och programkoden klarar testfallet tilläggs testfallet till de tidigare
testfallen och tillsammans kan de köras om efter ändringar i koden eller efter nya kodleveranser
av utvecklare för att kontrollera systemets status. För att effektivisera dessa testfall behöver man
ett verktyg som hjälper till att skriva testfall så att: de ska vara automatiserade (Alla testfallen
kan köras bara med att trycka på en knapp); resultatet ska vara som en visuell respons med
beskrivande felmeddelande och till sist måste testfallen köras snabbt. [Steinberg 2004, s.56].
JUnit är ett verktyg som har utvecklats av Kent Beck och Erich Gamma för att verkliggöra
dessa behov.
För att testa evalueringsramverket har JUnit använts. I bilaga D finns två av de testfall som har
utvecklats för test av programkod i evalueringsramverket. En av dessa fall är att kontrollera om
två villkor är likadana. Som sagt innehåller villkoren logiska operatorer. Logiska operatorer är
kommutativa. Det innebär att operandernas ordning inte spelar någon roll i evaluerings resultat.
T.ex. (a and b) är lika med (b and a). Villkoren innehåller även relationsoperatorer. Utöver ”=”
(Lika med) är relationsoperatorer inte kommutativa. Men de är speciella när det handlar om
satser med relationsoperatorer är lika. T.ex. är (x < 1) samma jämförelse som (1 > x). Därför om
man vill jämföra olika villkor med varandra bör man ta hänsyn till dessa speciella fall. I den
utvecklade koden finns en funktion med namnet ”equals” som utför jämförelsen mellan olika
villkor. Första testfall i bilaga D har skrivits för att testa denna funktion. Andra testfall är menat
för själva villkorsevaluering. Testfallet testar olika konstruktörer och två funktioner båda med
namnet ”evaluate” med skillnaden att ena tar emot villkoren i form av XML-noder som
parameter och den andra tar emot villkoren i form av en egendefinierad datastruktur
3.3.3. Implementering
För att kunna ge en överblick över hur evalueringsramverket har implementerats kommer i detta
avsnitt först en presentation av datastrukturer som har använts i programmet och sedan beskrivs
den algoritm som jag har utvecklat för att evaluera villkoren enligt den.
Mjukvaruverktyg för villkorsanalys
38
3.3.3.1. Datastrukturer
Ett datorprogram kan betraktas som en mängd instruktioner som tillämpas på en mängd
inputdata och producerar ett resultat i någon önskad form. Ofta lagras inputdata i en intern
datastruktur för att kunna komma åt data under körningen av programmet snabbt och effektivt.
Datastrukturers design är en väsentlig del av mjukvarudesignen. Efter objektorienterad
programmerings tillblivelse kombineras ofta sådana datastrukturer med de operationer som
utförs på dem i moduler som utformar en enhet (namngetts klass) för programkod.
Eftersom villkoren i guidade metoder är lagrade i XML-filer bör programmet först parsa XML-
filerna. Det finns två allmänt accepterade sätt för parsningen av XML-filer. I ena kan man
komma åt informationen med hjälp av en sekvens av händelser som skickas från parsern till
programmet. Denna typ av parsning används med hjälp av SAX (Simple API for XML). SAX är
interaktiv. Det innebär att när en SAX-parser parsar ett XML-dokument och kommer till starten
av dokumentet, start av ett element, viss text, slutet av ett element och dylikt meddelar SAX-
parsern programmet genom att skicka en händelse till det. I SAX-parsning bör man skapa egen
datastruktur och spara resultatet av händelser skickat av parsern i den om man vill behålla
informationen. [Tidwell 2008, s.15].
Den andra sorten av parsning är en rekommendation av W3C och använder sig av DOM (Data
Object Model). DOM-parser parsar hela dokumentet och returnerar parsningens resultatet som
träddatastrukturer21
. Med andra ord DOM skapar en datastruktur för hela dokumentet som sedan
kan man gå igenom för att komma åt de delarna som behövs. De kända XML-parsarna
tillhandahåller de båda metoderna. Eftersom guidade metoderna är inte så pass stora att
effektivitet blir en aktuell fråga använde jag DOM-strukturen tillsammans med Java:s standard
API för XML-bearbetning (javax.xml).22
Med andra ord kommer resultatet av parsningen av
guidade metoder i evalueringsramverket att lagras i DOM-strukturen.
Evalueringsramverket bör ta emot två sorters av inputdata. De första är villkoren i guidade
metoderna och de andra är värden av variablerna i villkoren i guidade metoder som inmatas av
användaren. En möjlig datastruktur för att lagra de båda typerna av inputdata är att ha separata
datastrukturer, ena för variablernas värde och den andra för villkoren. En annan möjlig lösning
är att spara båda i samma datastruktur. T.ex. programmet parsar en guidad metod och skapar en
DOM-struktur. Sedan lagras villkoren i det steg av guidad metoden som användaren vill
granska i en egendefinierad datastruktur. När användaren matar in värden av variablerna i
samma steg lagras de i samma datastruktur som villkoren har sparats tidigare. Eftersom
variabelnamnen finns redan i villkoren är den enda information som bör lagras är variablernas
värde. Så i designen av datastrukturen kan man lägga till ett fält (lagringsplats) för varje
variabel i datastrukturen för att lagra variabelns värde som inmatas av användaren.
Att använda en lösning med två separata datastrukturer istället för en datastruktur för båda
typerna av inputdata är mer effektivt. I bilaga C utvärderas varför att använda två separata
datastrukturer ena för villkor och den andra för variablernas värde är mer effektivt än att
använda en gemensam datastruktur för båda villkoren och variablernas värde.
21
Det finns olika typer av datastruktur som beroende på inputdata används i olika program. En viktig
fråga i val av datastrukturer är sortering och sökningens effektivitet. Några typer av de mest kända typer
av datastrukturer är träd, graf, kö, länkade listor m.m.
22 Detta API använder en parser via Java-konfigurationen och det är inte säkert om den använder en SAX-
parser eller en DOM-parser för att skapa en DOM-struktur. Det kan skilja sig från dator till dator.
Mjukvaruverktyg för villkorsanalys
39
Datastrukturen som innehåller variablernas värde behöver inte omfatta all information om
variablerna. Det räcker med att den har ett fält för variabelnamn och ett fält för variabelns värde.
Variabelnamnet föreställer en nyckel (Key) för variablernas identifiering och därför bör
variablernas namn vara unika inom villkoren i ett steg. En känd datastruktur för att lagra ”key-
value”-information kallas Map och en speciell typ av den kallas HashMap som har använts i
evalueringsramverket för att lagra variablernas inmatade värde.
Egentligen behövs ingen datastruktur för att lagra villkoren i ett steg för att utföra
villkorsevaluering. Anledningen är att villkoren är sparade i XML-filer och för att evaluera
villkoren bör man parsa dessa XML-filer. Om man använder DOM-strukturen för att lagra
resultatet av parsningen kan denna struktur användas även för villkorsevalueringen. Jag valde
att utveckla evalueringsramverket så att den kan hantera båda fallen: Att använda DOM-
strukturen för att hämta ut villkoren under evalueringen, och att utveckla en egendefinierad
datastruktur för att lagra villkoren innan de evalueras. Anledning var att med en egendefinierad
datastruktur kunde andra eventuella krav för villkorshantering uppfyllas enklare. Exempel på
sådana krav som har implementerats i evalueringsramverket är att skriva villkoren som logiska
satser istället för XML-elementen.
Ett annat exempel är att kontrollera om olika villkor är lika med varandra med tanke på
kommutativa operationer. Med kommutativ menas att operandernas ordning inte spelar någon
roll i resultatet av operationen förknippad med en operator. Logiska operatorer är kommutativa.
T.ex. (x<1 and y> 2) = (y>2 and x<1). Relationsoperatorer förutom lika med (=) är inte
kommutativa men det finns ett speciellt fall i de villkoren som innehar relationsoperatorer som
man måste vara uppmärksam på när man kontrollerar om två sådana villkor är lika med
varandra. T.ex. (x < 1) = (1 > x).
Figur 3.3 kan användas för att förstå designen av den egendefinierade datastrukturen. Designen
har gjorts enligt objektorienterad programmering. Figur 3.3 föreställer ett diagram som är känd
som klassdiagram. Klassdiagram är en av de diagram som en standard för design och
modellering av mjukvara föreslår. Standarden kallas för UML (Unified Modeling Language).
Det hör inte till rapportens syfte att presentera konventioner i UML. Men några punkter om
strukturen själv tas upp här för att strukturen kan förstås lättare:
Villkoren skapas med hjälp av logiska operatorer och relationsoperatorer. Operanderna i
de villkor som innehåller logiska operatorer kan innehålla igen logiska operatorer eller
relationsoperatorer. Det leder till att när ett villkor innehåller en logisk operator kan
operanderna till den logiska operatorn betraktas själva som nya villkor. Därför kan man
dela upp villkoren i två delar: De villkor som själv består av nya villkor och de som inte
har andra villkor som operander.
Som sagt kan varje villkor innehålla logiska operationer. Sådana villkor har kallats för
”CompoundCondition” i strukturen. Eftersom sådana villkor består själva av andra
villkor (Varje Operand i villkoren kan vara en annan logisk operator). Logiska
operatorer kan innehålla en operand (”not” operatorn) eller de kan behöva två
operander. I första fallet har de kallats ”CompoundCondition” och i andra fallet har de
kallats för ”BinaryOpCondirion”.
Villkoren kan innehålla relationsoperatorer eller innehålla inga operatorer alls. Om de
inte innehåller någon relationsoperator måste de innehålla en variabel med boolesk
datatyp som dess värde endast kan vara sant eller falskt. Om den booleska variabeln har
värdet sant är villkoret sant och om den har värdet falskt evalueras villkoret till falskt.
För att förkorta villkoren skriver man variabel-noden med boolesk datatyp utan inga
Mjukvaruverktyg för villkorsanalys
40
jämförelser med värdet sant eller falskt. Om en variabel-nod med boolesk datatyp finns
direkt under en villkor-element utan ingen jämförelse kan man tolka det att den noden
jämförs med värdet sant. Sådana villkor (utan inga operatorer) har kallats för
”SimpleUnaryConditions”. Eftersom de bara består av en variabel-nod. Villkoren som
innehåller en relationsoperator behöver två operander och har kallats för
”SimpleCondition”.
Operander i villkoren som innehåller logiska operationer kan betraktas själva som nya
villkor. Men operander för villkoren som innehåller relationsoperatorer kan endast vara
variabler eller konstanta värde. När villkoren inte innehar någon operator alls finns
endast en variabel inom villkoren som kan betraktas som en operand. Operander för
relationsoperator eller i villkor av typen ”SimpleUnaryConditions” har kallats för
”AtomicOperand”. Sådana operander kan vara en variabel eller ett konstant värde.
ConditionFactory är den delen av kod som är ansvarig för att ta emot villkoren i form av
XML-element och skapa ”Condition”-datastrukturen.
ConditionEvaluator är den delen av kod som är ansvarig för att evaluera villkoren. Den
kan evaluera villkoren både i form av XML-element och i form av ”Condition”-
datastrukturen.
Den datastrukturen som innehåller variablernas värde har skapats som en del av
ConditionEvaluator och kallats för ”variableSet”.
ConditionNodeParser är den delen av kod som är ansvarig för att bläddra genom
villkoren i form av XML-element för att komma åt olika barn-element såsom variabler,
konstanta värde eller operationer.
Mjukvaruverktyg för villkorsanalys
41
Figur 3.3. Klassdiagram för evalueringsramverket
3.3.3.2. Evalueringsalgoritmen
Evalueringsalgoritmen som jag har för att evaluera villkoren är en rekursiv algoritm. Den kan
förklaras i de stegen som kommer nedan:
1) Bestäm typen av första operatorn i villkoren.
class ConditionFramwork
Condition
+ toString() : String
+ getOperator() : Operator
+ setOperator(Operator) : void
CompoundCondition
# CompoundCondition()
+ toString() : String
BinaryOpCondition
# BinaryOpCondition()
+ toString() : String
SimpleCondition
# SimpleCondition()
+ toString() : String
AtomicOperand
- dataType: string
«property get»
+ getdataType() : string
«property set»
+ setdataType(string) : void
Constant
- value: String
+ toString() : String
«property get»
+ getvalue() : String
«property set»
+ setvalue(String) : void
Variable
- name: string
+ toString() : String
«property get»
+ getname() : string
«property set»
+ setname(string) : void
«enumeration»
VariableType
Attributes
- StoredVariable
- DTCVariable
- ECU_IO
- Product_IO
- Step_Result
- ReadMode
- Variant
«enumeration»
Operator
not
and
or
xor
eq
neq
gt
lt
geq
leq
empty
ConditionEv aluator
- variableSet: Map <String, String>
ConditionFactory
- factoryInstance: ConditionFactory
+ getInstance() : ConditionFactory
+ createConditions(NodeList) : ArrayList<Condition>A
SimpleUnaryCondition
# SimpleUnaryCondition()
+ toString() : String
ConditionNodeParser
createAtomicOperands(Node node)
1
rightOperand
1
evaluate(Condition cond)
createConditon(Node node)
11
1 1
1leftOperand
1
1
leftOperand
1
1
rightOperand
1
equals
equals
getElementChild(Node conditionNode, int childPos)
Mjukvaruverktyg för villkorsanalys
42
2) Om det finns ingen operator och istället finns en ensamstående variabel hämta ut
variabelns värde från datastrukturen ”variableSet” och returnera resultatet av
evalueringen baserat på detta värde.
3) Om operatorn är en relationsoperator hämta ut operandernas värde och jämför dem med
varandra baserad på relationsoperatorn. Resultatet av jämförelsen returneras som
evalueringens resultat.
4) Om operatorn är en logisk operator betrakta operand eller operanderna som nya villkor
och utför evalueringen för den eller dem och sedan tillämpa den logiska operatorn på
resultatet av operandernas evaluering. Resultatet av tillämpningen kommer att
returneras som evaluerings resultat.
3.4. Kopplingen mellan användargränssnittet
och evalueringsramverket
Eftersom användargränssnittet i detta projekt har skapats i form av HTML medan
programkoden är skriven i Java behövs speciella tekniker för att kunna använda de värden
användaren matar in i användargränssnittet som parametrar i Javas programmeringsspråk. Java
har försetts med några tekniker för att hantera sådana fall. Egentligen har en hel separat version
av Java-språket utvecklats för att utveckla webbapplikationer med. Denna version av Java kallas
för JavaEE (Java Enterprise Edition). I JavaEE finns några olika sätt för att använda
programkod skriven i vanligt Java i webbsidor. Ett hinder för att inte använda tekniker baserade
på JavaEE var att SDP3 PT är skrivet i vanligt Java vilket är känt som JavaSE (Java Standard
Edition) och kompatibiliteten mellan JavaEE och JavaSE ska göra SDP3 PT invecklat. Ett annat
hinder var att för att kunna använda JavaEE bör man installera en speciell applikation på datorn
som kallas för webbserver. Konfiguration och anslutning till detta serverprogram skulle
medföra onödig komplexitet, extra arbete och svårare underhåll i SDP3 PT. Därför förkastades
denna lösning.
Det finns två andra kända tekniker för att ansluta hemsidor till Java-programkod. Ena kallas för
”Java Web Start” och den andra kallas för ”Java Plug-in Technology”. ”Java Plug-in
Technology” använder Java-klasser kallade för Applet därför är det även känt med namnet
applet. [Oracle 2006] beskriver skillnaderna mellan de två teknikerna:
”The two approaches are very similar. The key difference is in the user experience. If
the Java application/applet needs to interact with a web page and be tightly bound to a
web browser, then applets may be the solution. On the other hand, if browser
independence is important, then Java Web Start is the deployment platform of choice.
There are a number of other differences, but this is the fundamental difference. Java
Plug-in technology enables users to run Java applets inside a browser. Java Web Start
enables users to download full-featured applications with any browser. Once they have
downloaded and launched an application, the browser can be closed, while the
application continues working. The application does not depend on an open browser to
function. The browser can be shut down or you can go to a different web page and the
application will continue running.”
Mjukvaruverktyg för villkorsanalys
43
Som framgår av texten används ”Web Start” för att ladda ner applikationer som ska köras
fristående av webbläsaren som innehåller den länk vilken via den har ”Web Start” påbörjats.
Medan ”Plug-in Technology” ska användas när Java-programmet kommer att interagera med
webbläsaren ständigt.
Användargränssnittet för evalueringsramverket är i HTML-format och kan visas i vilken
webbläsare som helst. När användaren matar in variablernas värde kommer han/hon att välja se
resultatet av evalueringen för villkoren i samma steg som variablerna står i. Evaluerings begäran
kan genomföras via t.ex. en knapp. Efteråt måste variablernas värde skickas vidare till
evalueringsramverket vilket kommer att utföra evalueringen. Efter evalueringen måste resultatet
av evalueringen visas för användaren på något sätt. Eftersom hela operationen har börjats från
webbläsaren är det logiskt att visa även resultatet i samma webbläsare. Detta innebär att
evalueringsramverket måste interagera med webbläsaren aktivt. Därför valde jag att använda
Java-appletar (Java Plug-in Technology) för kopplingen mellan användargränssnittet och
evalueringsramverket.
Java-appletar kan definieras inom en HTML-sida med hjälp av HTML-elementet <applet>. Man
bör använda JavaScript dock om man vill använda en av appletens metoder eller
medlemsvariabler. JavaScript är ett programmeringsspråk som hjälper till att skapa hemsidor
som innehar komplexa användargränssnitt och/eller är dynamiska. Dynamiska hemsidor är de
hemsidor vars ingående information förändras med tiden. T.ex. om man vill visa tidpunkt på en
hemsida, måste den uppdateras ständigt.
I examensarbetet har JavaScript även använts för att skapa resultatet av evalueringen i HTML-
format och visa det för användaren. Figur 3.4 visar hur arbetsflödet ser ut då evalueringen sker.
Diagrammet har ritats enligt sekvensdiagrams principer. Sekvensdiagram är ett annat diagram
som UML definierar. Figuren kan förklaras med hjälp av de steg som kommer nedan:
Metodingenjören (användaren) matar in variablernas värde för ett steg i en guidad metod
som har visats för honom/henne i webbläsaren och sedan anger han eller hon
kommandon för att evaluera villkoren i detta steg.
JavaScript anropas med variablernas värde och stegets namn som parametrar till
anropets parametrar.
Appleten anropas med variablernas värde, stegets namn och guidade metodens filnamn
som parametrar.
Appleten parsar den begärde guidade metoden (XML-filen) och hämtar ut de villkor
som tillhör det steg som användaren vill granska.
Uthämtade villkoren tillsammans med variablernas värde skickas vidare till
evalueringsramverket för att villkorsevalueringen ska utföras.
Evalueringsramverket returnerar evalueringsresultatet till appleten.
Appleten skickar namnen av de steg vars respektive villkor har evaluerats till sanna till
JavaScript.
JavaScript skapar en ny HTML-sida som innehar resultatet av evalueringen och visar
den till användaren.
Användaren vill granska villkoren för ett av de steg vars namn har visats som resultatet
av evalueringen.
En användargränssnittkomponent t.ex. en knapp tar emot användarens begäran om
granskning.
Mjukvaruverktyg för villkorsanalys
44
Användarens begäran tillsammans med stegets namn skickas vidare till JavaScript.
JavaScript anropar appleten med stegets namn och namnet på guidade metoden som
parametrar.
Appleten anropar Java:s interna XSLT-processor för att skapa användargränssnittet för
det steg som användaren har valt.
XSLT-processorn utför transformationen och ett nytt användargränssnitt i HTML-
format skapas.
Figur 3.4. Sekvensdiagram för arbetsflödet under villkorsevaluering
Eftersom några olika tekniker har använts under hela processen är arbetsflödet relativt
komplicerat och medförde svårigheter i programmeringen. En av de svårigheterna var det att
olika webbläsare inte implementerar JavaScript på samma sätt. T.ex. skrev jag en funktion i
JavaScript med namnet ”evaluate”. Koden fungerade i Microsoft:s webbläsare (Internet
Explorer) men inte i Google Chrome och Mozilla Firefox. Till slut förstod jag att det inte går att
definiera en funktion med namnet ”evaluate” i de webbläsarna. Det fanns ingen dokumentation
sd Arbetsflöde
MethodIngineer JavaScript JavaApplet
GUI in
HTML-format
XSLT
EvaluationFramework
in Java
testStep
(variablsValues)
call(stepName, values)
call(stepName, fi leName, values)
selectStepConditions(fi leName,
stepName)
evaluate(conditions,
values
EvaluationResult()stepNamesforTrueConditions()
stepNamesforTrueConditions()
chooseAnotherStep
(stepName)
call(stepName)
call(fi leName, stepName)
createGUI (fi leName,
stepName)
createdGUI()
Mjukvaruverktyg för villkorsanalys
45
om det och jag hittade inga referenser som pekar på det.23
En gissning är att en funktion som
finns med samma namn och tillhör en av JavScript:s egna objekt (”document”) gjorde så att en
kollision i namnrymden hände och därmed fungerade programkoden inte.
En annan svårighet som jag råkade för var att av säkerhets skäl Java-appletar inte får komma åt
lokala filer som lagras på datorn. Därför kunde XSL-transformationen som gjordes via appleten
inte utföras. I sådana fall kan man använda en speciell sort av appletar som kalls för ”Trusted
Applet”. En annan lösning för att kringgå detta problem är att ändra Javas
säkerhetspolicykonfiguration. Eftersom Jag upptäckte detta problem när arbetet var nära sitt slut
använde jag denna lösning som kunde utföras snabbare.
23
Det finns dokumentation om de reserverade ord i Firefox
(https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words) men ”evaluate” var inte med i
listan.
Avslutning
47
4. Avslutning Detta kapitel ger först en sammanfattning av rapporten. Sedan kommer en överblick
över fortsatt arbete.
Denna rapport beskriver en analytisk lösning för test av villkoren i form av en kombination av
relationsoperationen och satser i satslogiken. Dessa villkor används inom guidade metoder.
Guidade metoder är de underlag som utformas på Scania för att hjälpa mekanikerna vid
fordonens felsökning. Guidade metoder definieras i XML-format. Moderna fordon innehåller
många elektroniska styrenheter som kräver speciella mjukvaruverktyg för att felsöka dem.
Elektroniska styrenheter är de elektroniska delsystem som används i olika delar av fordon och
utför olika uppgifter. En elektronisk styrenhet består av en dator, flera mjukvarukomponenter
som interagerar med generatorer, givare och ställdon.
Det mjukvaruverktyg som används på Scania för felsökning av fordon heter SDP3. Guidade
metoder och annan information som används vid felsökningen med SDP3 lagras i databaser.
SDP3 PT är ett internt verktyg på Scania som tar emot guidade metoder och/eller annan
information och förbereder dem för att de ska lagras i SDP3:s databas. En av SDP3 PT:s
användare är metodingenjörer. En av metodingenjörernas uppgift är design av guidade metoder.
Guidade metoder innehåller villkor vilka styr flödet i metoden och interaktionen med både
mekaniker och fordon. Guidade metoder kan vara komplexa och innehålla många villkor.
Villkoren kan också bestå av komplexa logiska satser. Därför vill metodingenjörerna testa
villkorens korrekthet innan metoderna ska tas i bruk.
Att testa villkoren i guidade metoder under samma omständigheter som mekanikern utför (i
SDP3 kopplat till fordonet) är inte genomförbart, eftersom det händer att metodingenjörerna
utformar guidade metoder för fordonsmodeller som inte har tillverkats än. Därför behövs en
lösning så att man kan testa guidade metoder med hjälp av SDP3 PT medan man skapar dem.
Examensarbetets syfte är att presentera ett mjukvaruverktyg för test och evaluering av villkoren
i guidade metoder.
För att Examensarbetet skulle kunna utföras i ramen för ett magisterprogram avgränsades det till
ett oberoende mjukvaruverktyg och implementerades inte som en del av SDP3 PT. En annan
avgränsning var att examensarbetet inte omfattar alla typer av villkor. Villkoren i guidade
metoderna innehåller variabler. En variabel är ett namn som representerar ett värde som kan
läsas från olika styrenheter eller matas in av användaren eller produceras i själva SDP3
programmet. Dessa variabler jämförs med andra variabler eller med konstanta värden med hjälp
av relationsoperatorer. Dessa jämförelser kombineras med hjälp av logiska operatorer och på så
sätt utformas villkoren.
Ett mjukvaruverktyg som är menat att testa villkoren i guidade metoderna bör evaluera dessa
satser. För att evaluera dessa satser bör man generera variablernas värde på något sätt. Ett sätt
att återskapa variablernas värde för villkorsevaluering är att användaren matar in dem manuellt
genom ett användargränssnitt. Det innebär att det måste finnas komponenter på
användargränssnittet som motsvarar variablerna i villkoren. När metodingenjörer vill testa
villkoren i en guidad metod anger de det stegnamn som de vill testa till mjukvaruverktyget.
Baserat på de variabler som finns i villkoren i det steget skapar verktyget ett användargränssnitt
och visar det för användaren. Användaren matar in variablernas värde och väljer att evaluera
Avslutning
48
villkoren. Evalueringen sker och resultatet visas för användaren och därefter kan användaren
analysera om villkoren har utformats korrekt eller inte.
I detta sammanhang kan ett mjukvaruverktyg för villkorsanalys uppdelas i tre olika delar. Första
delen är skapandet av det användargränssnitt som användaren matar in variablernas värde
genom det, andra delen är ett evalueringsramverk som evaluerar villkoren i det steg som dess
variablers värde har inmatats och sista delen är det att hur detta användargränssnitt kan kopplas
till evalueringsramverket.
Ett användargränssnitt för inmatning av variablernas värde är att det är dynamiskt. Det innebär
att användargränssnittet inte ser likadant ut när man granskar olika guidade metoder eller när
man granskar olika steg i en guidad metod. I rapporten har två sätt för att skapa ett sådant
användargränssnitt tagits upp och har jämförts med varandra. Första sättet är att använda de
kända kodbiblioteken i Java-programmeringsspråk som används normalt i Java-program för att
utveckla användargränssnitt. Det andra sättet är att skapa användargränssnittet med hjälp av
XSL-transformationer. Till slut har det andra sättet implementerats och presenterats i rapporten.
Evalueringsramverket kunde också implementeras på olika sätt. Tre olika sätt har presenterats i
rapporten. I rapporten har de olika sätten utvärderats och baserat på utvärderingen har ett sätt
valts för att implementeras.
En av de huvudsakliga delarna i varje mjukvara är de datastrukturer som används i den. De
datastrukturer som har använts för att implementera evalueringsramverket och deras design har
presenterats i rapporten.
Eftersom användargränssnittet var i HTML-format och evalueringsramverket implementerades i
Java behövdes speciella tekniker för att ansluta de båda till varandra. Den teknik som har
använts i examensarbetet kallas för ”Java Plug-in Technology”. I denna teknik använder man
Java-klasser som kallas för appletar. För att kunna använda appletar fullständigt behövdes
programmeringsspråket JavaScript också. Arbetsflödet och kopplingen mellan
användargränssnittet och evalueringsramverket har beskrivits mer utförlig i rapporten.
I fortsättningen kommer några förslag för fortsatt arbete.
4.1. Fortsatt arbete
Som nämndes tidigare har examensarbetet avgränsats till ett oberoende verktyg som kan
användas via en webbläsare. Men metodingenjörerna använder SDP3 PT och därför bör denna
mjukvara integreras med SDP3 PT. Integrationen med SDP3 PT är den viktigaste delen av
fortsatt arbete. Som nämndes tidigare har mjukvaruverktyget beskrivits i tre delar:
användargränssnittet, evalueringsramverket och kopplingen mellan de två. SDP3 PT är skrivet i
Java och det gör evalueringsramverket det också. Därför kan evalueringsramverket användas i
SDP3 PT utan vidare. Men för att integrera användargränssnittet med SDP3 och därigenom
kopplingen mellan användargränssnittet och evalueringsramverket bör man ta ytterligare
Avslutning
49
åtgärder. Nedan presenteras fyra olika sätt som kan väljas för att integrera användargränssnittet
med SDP3 PT.
1- SDP3 PT har implementerats som Eclipse-tillägg. En av de möjligheterna som Eclipse
erbjuder är en intern webbläsare. Det innebär att webbsidor kan öppnas direkt inom ett
Eclipse-tillägg. Eftersom SDP3 PT är ett Eclipse-tillägg har det också tillgång till denna
interna webbläsare och man bör kunna använda denna interna webbläsare för att visa
evalueringsramverkets användargränssnitt i HTML-format. På det sättet kan man
använda mjukvaruverktyget direkt i SDP3 PT. Men den interna webbläsaren i Eclipse är
begränsad och ger inte alla möjligheter som de andra webbläsarna erbjuder. T.ex. ”Java
plug-in Technology” (appletar) inte stöds av Eclipse:s interna webbläsare. Detta leder
till att man inte kan koppla användargränssnittet i HTML-format med
evalueringsramverket. Därför försökte jag hitta en lösning som utesluter appletar och
använder bara JavaScript. Men det visade sig att den interna webbläsaren inte stöder
JavaScript fullständigt heller. Därför kan den interna webbläsaren inte användas för att
integrera mjukvaruverktyget med SDP3 PT.
En annan möjlighet som Eclipse erbjuder är att anropa externa mjukvara och verktyg
inuti Eclipse-miljö. Denna möjlighet kallas för ”External tools”. Det enklaste sättet för
att använda resultatet av examensarbetet direkt i SDP3 PT utan inga förändringar är
genom denna möjlighet. Man kan koppla en redan installerad webbläsare som ett
externt verktyg i SDP3 PT. Sedan kan man visa det användargränssnittet som skapas i
HTML-format av XSLT-processorn via anrop till detta externa verktyg. Fördelen med
detta sätt är enkel implementering. Nackdelen är att användaren växlas ständigt mellan
olika program och det kan kännas obehaglig.
2- Det finns ett annat sätt att ha användargränssnittet i HTML-format och ändå kan
använda det mjukvaruverktyg som jag har utvecklat under examensarbetet för
villkorsanalys. Detta kan göras genom att utveckla en egen webbläsare och koppla den
till en del av användargränssnittet i SDP3 PT. Denna webbläsare kan sedan användas
för att visa användargränssnittet för inmatning av variablernas värde i HTML-format. I
Java finns två mer kända kodbibliotek för att utveckla användargränssnitt. Det första
som var Java:s ursprungliga kodbibliotek för användargränssnittsutveckling kallas för
AWT (Abstract Window Toolkit) som uppgraderades till en förfinad version som
namngetts Swing. Swing och AWT var båda utvecklade av Sun Microsystems. Den
andra gängse tekniken för användargränssnitsutveckling i Java-program kallas SWT
(Standard Widget Toolkit). SWT utvecklades ursprungligen av IBM (International
Business Machines) men sedan adopterades av Eclipse Foundation. JFace är en
utveckling av SWT som utökar SWT med ett känt designmönster kallat MVC (Model
View Controller) till SWT.
Med de möjligheterna som Swing erbjuder kan man skapa en webbläsare ganska enkelt.
Detta är ännu enklare med SWT som erbjuder ett speciellt kodbibliotek för
utvecklingen av webbläsare som även har stöd för appletar. Eftersom Eclipse själv och
därmed Eclipse-tilläggen har skapats med SWT och JFace kan SWT användas för att
skapa en webbläsare och integrera den som en del av SDP3 PT för att visa
användargränssnittet för villkorsanalysverktyget i HTML-format.
3- Denna lösning är baserad på att använda användargränssnitt som skapas av Java:s
kodbibliotek (T.ex. Swing eller JFace) istället för HTML. Fast för att skapa detta
användargränssnitt kan man fortfarande använda XSL-transformationer. Ett sätt är att
försöka skriva transformationers resultat direkt som Java-kod. Ett annat sätt är att skapa
Avslutning
50
XML-kod istället för Java-kod och sedan via de möjligheter som Java-kodbibliotek ger
kan XML-koden förvandlas till Java-kod. I Java-kodbibliotek finns två klasser för att
översätta Java-kod till ett speciellt XML-format och vice versa. Dessa klasser heter
XMLEncoder och XMLDecoder. XMLEncoder kan användas för att transformera Java-
kod till det XML-format som definieras enligt strukturen ”Java Bean Persistance XML
Schema”. XMLDecoder kan användas för att transformera XML-filer i denna format till
Java-kod. Man kan använda XSLT för att skapa användargränssnittet för villkorsanalys
i den XML-format som bestäms av ”Java Bean Persistance XML Schema”. Sedan kan
man använda XMLDecoder för att förvandla resultatet av XSL-transformationer till
Java-kod som kan kompileras som en del av SDP3 PT.
4- Den sista lösningen är baserad på att inte använda XSL-transformationen för att skapa
användargränssnittet utan att försöka skapa användargränssnittet i Java. Med andra ord
kommer stilmallarna i XSLT att skrivas som Java-instruktioner i form av loopar,
funktioner, kontroll-satser och dylikt. Fast det går fortfarande att använda samma logik
som finns i XSL-transformationer för att skapa det användargränssnitt som har använts i
examensarbetets genomföring. Denna lösning kan vara mer tidskrävande i jämförelse
med de andra men den är simpel att implementera och därför rekommenderas.
En annan avgränsning i examensarbetet handlade om typen av villkoren. Examensarbetet har
utförts med avseende på de villkor som ligger under ”NästaSteg”-elementet under ett steg i
guidade metoderna. Men guidade metoderna innehåller andra typer av villkor och i andra
sammanhang också. Även dessa villkor bör kunna analyseras med ett verktyg som möjliggör
villkorsanalys. En typ av villkor som måste tas hänsyn till är stadigvarande villkor som ligger
direkt under ett steg och inte under ”NästaSteg”-elementet. En annan typ av villkor kallas för
globala villkor. Dessa villkor kan refereras i många olika guidade metoder och därför lagras i
separata filer och inte inuti själva guidade metoder. I en guidad metod kan man referera på ett
sådant villkor. I framtiden måste villkorsanalysverktyget kunna hantera dessa villkor också.
Som nämndes i rapporten har en grafisk editor utvecklats i SDP3 PT för att visa guidade
metoderna visuellt. Resultatet av villkorsevaluering kan visas för användaren
(metodingenjörerna) med hjälp av denna editor. Just nu visas detta resultat i HTML-format och i
form av namnen av de steg som deras respektive villkor har evaluerats till sanna. Istället för det
kan man skicka stegets namn till grafiska editorns programkod för att till exempel ändra färgen
av de steg som deras villkor har evaluerats till sanna.
Litteraturlista
51
Litteraturlista
1991. Scania 100 år. Saab-Scania AB, Scaniadivisionen, Södertälje. ISBN 91-7886-065-2
BANKS, JERRY & CARSON, JOHN & NELSON, BARRY L. & NICOL, DAVID .2009. Discrete-Event
System Simulation. Prentice Hall, 5th Edition, ISBN 0136062121.
DAVIES, GUY & EKENBERG, LOVE & THORBIÖRNSON JOHAN. 2008. Logic-Basics & Beyond.
Universitetsservice US-AB, Stockholm, First edition, ISBN 91-89278-10-0.
DAVIS, ROBERT I. & BURNS, ALAN & BRIL REINDER J., LUKKIEN JOHAN J. 2007. CONTROLLER
AREA NETWORK (CAN) SCHEDULABILITYANALYSIS: REFUTED, REVISITED AND REVISED.
REAL-TIME SYSTEMS, Volume 35, Number 3, 239-272.
HAROLD, ELLIOTTE RUSTY & MEANS W. SCOTT. 2004. XML in a Nutshell. O'Reilly Media.
Third Edition. ISBN 0-596-00764-7
HILLIER V.A.W. 1996. Hillier's fundamentals of automotive electronics. Stanley Thornes.
Cheltenham. Second Edition. ISBN 0748726950.
KARLBÄCK, MIKAEL. 2010. Signal validation in an automotive vehicle using Neural
Networks. ROYAL INSTITUTE OF TECHNOLOGY. STOCKHOLM.
KHALEDI, MOHAMMAD. 2008. Development of PC-Tools for Powertrain Control System
Development. Royal Institute of Technology, School of Computer Science and Communication.
Stockholm. ISSN 16535715.
LAW, AVERILL M. & KELTON DAVID W. 2000. Simulation modeling and analysis. McGraw-Hill,
Third Edition, ISBN 0070592926.
LIGÊZA, ANTONI . 2006. Logical Foundations for Rule-Based Systems.Springer, 2nd Edition,
3540291172.
LINDH, BJÖRN-ERIC. 1992. Scania FORDONSHISTORIA 1891-1991.Streiffert & Co, Örebro,
ISBN 91-78860741.
MARX, MAARTEN. 2009. Logical Foundations of XML and XQuery. REASONING WEB.
SEMANTIC TECHNOLOGIES FOR INFORMATION SYSTEMS. Lecture Notes in Computer
Science. Volume 5689/2009. Sidor 111–157.
ORACLE. 2006. JavaTM Web Start version 1.5.0 - Frequently Asked Questions (FAQ). General
Questions. Fråga sjutton: How does Java Web Start relate to Java Plug-in Technology (applets)?
[www]. Hämtat från:
http://download.oracle.com/javase/1.5.0/docs/guide/javaws/developersguide/faq.html
Uppdaterad: March 2006. Hämtat: Feb 2011.
PUNTAMBEKAR, A.A. & DHOTRE, I.A. 2008. Systems programming. Technical Publications
Pune. ISBN 9788184313925.
RAY, ERIK T. 2003. Learning XML. O'Reilly Media. Second Edition. ISBN 0-596-00420-6.
SOTTARA, DAVIDE & MELLO, PAOLA & PROCTOR, MARK. 2010. A Configurable Rete-OO
Engine for Reasoning with Different Types of Imperfect Information. IEEE
TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING. VOL. 22, NO. 11,
NOVEMBER.
Litteraturlista
52
STEINBERG, DANIEL H. & PALMER, DANIEL W. 2004. Extreme Software Engineering A Hands-
On Approach. Pearson Education, Inc. First edition. ISBN 0-13-047381-2.
SUN HER, JIN & WON CHOI, SI & WAN CHENUN, DU & SEOPE BAE, JEONG & DONG KIM SOO.
2007. A Component-Based Process for Developing Automotive ECU Software. Lecture Notes
in Computer Science, Product-Focused Software Process Improvement. Springer Berlin /
Heidelberg.
TALLIS, MARCELO & BALZER, ROBERT M. 2010. A Deductive Spreadsheet System for End
Users. IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING. VOL. 22, NO.
11, NOVEMBER 2010.
TIDWELL, DOUG. 2008. Mastering XML Transformations XSLT. O'Reilly Media. Second
Edition. ISBN 987-0-596-52721-1.
Scania Internal
DUBIAS, ÅSA. 2010. Product release information CDAPP. Dokumentnamn: PRI_CDAPP.
Utgåva: 2.2.
GUGALA, LISA. 2009. Projektdefinition SDP3:s Produktionsmiljö (SDP3 PM). Dokumentnamn:
ProjektDefinition_SDP3_PM. Antal sidor: 28.
IVENDAL, HANS. 1997. Utredning. Dokumentnamn: UtredningDiagnosTillSESAMM. Utgåva: 1.
Reg-nr: REPMET97001. Antal sidor: 26.
IVENDAL, HANS. 1998. Scania diagnos programmer 3 (SDP3). Dokumentnamn: SD3_Direktiv.
Utgåva: 1. Reg-nr: REPMET-1998-7. Antal sidor: 7.
IVENDAL, HANS. 2000. Project definition SDP3Scania Diagnos Programmer 3. Dokumentnamn:
PDF_SDP3. Utgåva: P1L. Reg-nr: REPMET-1999-1. Antal sidor: 21.
JOHANSSON, GÖRAN. 2006. Projektdirektiv, produktionsmiljö SDP3. Dokumentnamn:
Projektdirektiv PM. Utgåva: 1. Antal Sidor: 8.
MATTSSON, JAN. 2009. Detaljbeskrivning av komponent ConditionFramework. Dokumentnamn:
ConditionFrameworkDescription. Utgåva: P3A. Antal Sidor: 7.
WEILAND, ULF. 2005. Uppgiftsbeskrivning Förstudie: hantering av konstruktionsunderlag.
Dokumentnamn: uppgift_konstruktionsunderlag. Utgåva: 1. Antal sidor: 7.
Bilaga A: Uppvisning av en guidad metod i SDP3
53
Bilaga A: Uppvisning av en
guidad metod i SDP3
Bilderna nedan föreställer de tre första stegen i en guidad metod. Metoden är av typen ”user
function” för att kontrollera motorn (Engine Control). Första steget kopplas direkt till andra
steget och inga villkor finns för att komma fram till andra steget.
Bilaga A: Uppvisning av en guidad metod i SDP3
54
Bilaga B: Exempel på villkor i ett steg
55
Bilaga B: Exempel på villkor i
ett steg
<Setg> <Namn>TestSteg</Namn> <NästaSteg> <SetgNamn>StopSteg</SetgNamn> <villkor> <StörreÄnLikaMed> <variabel> <namn>motorTemperatur</namn> <typ>typ1</typ> <datatyp>heltal</datatyp> </variabel> <konstant> <värde>120</värde> <datatyp>heltal</datatyp> </konstant> </StörreÄnLikaMed> </villkor> </NästaSteg> <NästaSteg> <SetgNamn>gulVarningsSteg</SetgNamn> <villkor> <and> <StörreÄn> <variabel> <namn>motorVarv</namn> <typ>typ1</typ> <datatyp>heltal</datatyp> </variabel> <konstant> <värde>2000</värde> <datatyp>heltal</datatyp> </konstant> </StörreÄn> <StörreÄnLikaMed> <variabel> <namn>motorTemperatur</namn> <typ>typ1</typ> <datatyp>flyttal</datatyp> </variabel> <konstant> <värde>80</värde> <datatyp>flyttal</datatyp> </konstant> </StörreÄnLikaMed> </and> </villkor> </NästaSteg> <NästaSteg> <SetgNamn>rödVarningSteg</SetgNamn> <villkor> <or> <and> <StörreÄn> <variabel> <namn>motorVarv</namn> <typ>typ1</typ> <datatyp>heltal</datatyp>
Bilaga B: Exempel på villkor i ett steg
56
</variabel> <konstant> <värde>3000</värde> <datatyp>heltal</datatyp> </konstant> </StörreÄn> <StörreÄnLikaMed> <variabel> <namn>motorTemperatur</namn> <typ>typ1</typ> <datatyp>flyttal</datatyp> </variabel> <konstant> <värde>90</värde> <datatyp>flyttal</datatyp> </konstant> </StörreÄnLikaMed> </and> <LikaMed> <konstant> <värde>låg </värde> <datatyp>text</datatyp> </konstant> <variabel> <namn>oljeNivå</namn> <typ>typ2</typ> <datatyp>text</datatyp> </variabel> </LikaMed> </or> </villkor> </NästaSteg> <NästaSteg> <SetgNamn>normalLägeSteg</SetgNamn> <villkor> <or> <LikaMed> <konstant> <värde>normal </värde> <datatyp>text</datatyp> </konstant> <variabel> <namn>oljeNivå</namn> <typ>typ2</typ> <datatyp>text</datatyp> </variabel> </LikaMed> <xor> <StörreÄn> <konstant> <värde>2000</värde> <datatyp>heltal</datatyp> </konstant> <variabel> <namn>motorVarv</namn> <typ>typ1</typ> <datatyp>heltal</datatyp> </variabel> </StörreÄn> <StörreÄnLikaMed> <konstant> <värde>70</värde> <datatyp>flyttal</datatyp> </konstant> <variabel> <namn>motorTemperatur</namn>
Bilaga B: Exempel på villkor i ett steg
57
<typ>typ1</typ> <datatyp>flyttal</datatyp> </variabel> </StörreÄnLikaMed> </xor> </or> </villkor> </NästaSteg> </Setg>
Bilaga C: Utvärdering av olika typer av datastrukturer för villkoren
59
Bilaga C: Utvärdering av olika
typer av Datastrukturer för
villkoren Evalueringsramverket bör ta emot två sorters av inputdata. De första är villkoren i guidade
metoderna och de andra är värden av variablerna i villkoren i guidade metoder som inmatas av
användaren. En möjlig datastruktur för att lagra de båda typerna av inputdata är att ha separata
datastrukturer, ena för variablernas värde och den andra för villkoren. En annan möjlig lösning
är att spara båda i samma datastruktur. T.ex. programmet parsar en guidad metod och skapar en
DOM-struktur. Sedan lagras villkoren i det steg av guidad metoden som användaren vill
granska i en egendefinierad datastruktur. När användaren matar in värden av variablerna i
samma steg lagras de i samma datastruktur som villkoren har sparats tidigare. Eftersom
variabelnamnen finns redan i villkoren är variablernas värde den enda information som bör
lagras. I designen av datastrukturen kan man lägga till ett fält (lagringsplats) för varje variabel i
datastrukturen för att lagra variabelns värde som inmatas av användaren.
Att använda två separata datastrukturer istället för en datastruktur för båda villkoren och
variablernas värde är mer effektivt. För att detta förklaras bättre anta att datastrukturen som
skapats för att spara båda villkoren och variablernas värde för ett steg i en guidad metod består
av ”n” noder och i det steget finns ”m” olika variabler. Man kan mäta tidseffektivitetet med
hjälp av antalet sökningar i datastrukturen. I det här fallet:
Antalet sökningar i datastrukturen = Antalet sökningar när variablerna värdesättas + antalet
sökningar när villkoren evalueras
Om man använder bara en datastruktur behöver ingen sökning ske under villkorsevaluering
eftersom variablernas värde sparas i samma nod av datastruktur som deras namn finns. Det
innebär att:
Antalet sökningar i lösning med en datastruktur = Antalet sökningar när variablerna
värdesättas
Varje gång en variabel värdesättas måste alla ”n” noderna kontrolleras om de innehåller den
variabeln som dess värde har inmatats. Det bör uppmärksammas att ”m” är antalet unika
variabler och upprepningarna av variabler har ignorerats. T.ex. om variabeln ”X” har upprepats
i ett villkor två gånger har det antagits att ”X” värdesättas i båda fält under en sökning. Eftersom
det finns ”m” variabler är antalet sökningar under variablernas värdesättning lika med (m × n).
Det innebär att:
Antalet sökningar i lösning med en datastruktur = nm
n = Antalet noder i den gemensamma datastrukturen för båda villkoren och variablernas värde
m= antalet variabler i villkoren i steget
Bilaga C: Utvärdering av olika typer av datastrukturer för villkoren
60
Nu anta att vi ska använda två separata datastrukturer för att spara variablernas värde respektive
villkoren för att evaluera villkoren i samma steg som exemplet ovan. Eftersom det finns en
separat datastruktur för att lagra variablernas värde i behövs ingen sökning när variablerna
värdesättas. Om man använder en HashMap som datastruktur för variablernas värde
(Variabelnamn som ”Key” och variabelns värde som ”Value”) lägger man bara en nod till
mappen. Det innebär att:
Antalet sökningar i lösning med två separata datastrukturer= antalet sökningar under
villkorens evaluering
Datastrukturen som innehåller variablernas värde har ”m” noder (lika med antalet variablerna).
Datastrukturen som innehåller villkoren kan i värsta fall ha ”n” noder lika som den datastruktur
som kan innehålla båda variablernas värde och villkoren i förra lösningen. I själva verket är den
lite mindre på grund av att det inte finns någon lagringsplats för variablernas värde (De lagras ju
i en annan datastruktur). När evalueringen sker bör programmet leta efter värdet av en variabel
varje gång det kommer åt namnet av en variabel i ett villkor. Anta att:
1k = Antalet gånger som första variabeln har upprepats i villkoren
2k = Antalet gånger som andra variabeln har upprepats i villkoren
…
mk = Antalet gånger som andra variabeln har upprepats i villkoren
Och
mkkkk ...21
Varje gång som ett variabelnamn dyker upp i ett villkor måste en sökning i datastrukturen för
variablernas värde ske för att hämta ut variabelns värde. Därför gäller ekvationen nedan:
Antalet sökningar i lösning med två separata datastrukturer = mk
m= antalet variabler i villkoren i steget
k = Antalet gånger alla m variablerna har upprepats i villkoren
Som sagt den datastrukturen som används för att lagra villkoren i kan ha i värsta fall ”n” noder
lika som lösningen med en datastruktur. Därför att denna datastruktur är samma som används i
första lösningen för att lagra villkoren och variablernas värde båda med enda skillnaden att den
utesluter variablernas värde. Eftersom villkoren vanligen innehåller olika noder som konstanta
värde och noder för olika typer av operatorer (relationsoperatorer och logiska operatorer) utöver
variabel-noderna (Sådana noder måste innehålla variabelns namn, variabelns typ m.m.) kan man
påstå att antalet gånger som variablerna upprepas i villkoren är mindre eller lika med antalet alla
noder som finns för att spara villkoren. Det innebär att:
nk
Som resulterar i: )()( mnmk
n = Antalet noder i den gemensamma datastrukturen för båda villkoren och variablernas värde
m= antalet variabel i villkoren i steget
k = Antalet gånger alla m variablerna har upprepats i villkoren
Som innebär:
Antalet sökningar i lösning med en datastruktur Antalet sökningar i lösning med två separata
datastrukturer
Bilaga D: Testfall i JUnit
61
Bilaga D: Testfall i JUnit
1- Testfall för test av funktionen ”equals” i villkors datastruktur
package testcondition;
import static org.junit.Assert.*;
import java.io.InputStream;
import java.util.ArrayList;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import com.scania.condition.ConditionFactory;
import com.scania.condition.Condition;
/**
*
* @author Govan Marounsi
*
*@description This Class is developed to test the Condition data
structure.
* Condition is designed as a Java bean and it has just one important
method
* that should be tested:
* boolean equals (Object)
* The equals has been overridden to can manage special cases of
conditions:
* 1- commutation in relational operation : (x > 1) = (x < 1)
* 2- When variables are of different types but have same name
* 3- commutative logical operations:
* (x == 1)&& (Y > 2) = (Y > 2)&& (x == 1)
*
*/
public class ConditionTest {
//The name of inputed Guided method (XML file)
private String inputFileName = "ConditionEqualTest.xml";
//The name of Condition-element in guided methods
private final String condition = "Condition";
//To hold a guided method's conditions
private ArrayList<Condition> conds;
@Before
/**
* setUp () have been used to prepare data structure before testing
Bilaga D: Testfall i JUnit
62
* equals-function. For this purpose it should parse a guided method
* named ConditionEqualTestxml. This Guided method contains a step
* named step0 connected to other steps as below:
* 1 - Step1
* ( x >= 1 )
* 2 - Step2
* ( x >= 1 )
* 3 - Step3 (x in this step is not the same x used in step1 because it
* has different type)
* ( 1 <= x )
* 4 - Step4
* ( ( y < 1 ) and ( x >= 1 ) )
* 5 - Step5
* ( ( x >= 1 ) and ( y < 1 ) )
* 6 - Step6
* ( ( 1 > y ) and ( 1 <= x ) )
* 7 - Step7
* ( ( ( 1 > y ) and ( 1 <= x ) ) or ( 1 = z ) )
* 8 - Step8
* ( ( 1 = z ) or ( ( 1 > y ) and ( 1 <= x ) ) )
* 9 - Step9
* ( ( 1 = z ) xor ( ( 1 > y ) and ( 1 <= x ) ) )
*
* setUp transformer all of these conditions from XML-elements in
* guided method to the condition data structures with the aid of
* ConditionFactory.createConditions method. the result will be saved
* in the conds ArrayList.
*/
public void setUp() throws Exception {
DocumentBuilderFactory docFactory =
DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = null;
Document doc = null;
NodeList conditionNodes = null;
ConditionFactory condFactory;
this.conds= new ArrayList<Condition>();
try {
docBuilder = docFactory.newDocumentBuilder();
} catch (ParserConfigurationException e1) {
System.exit(1);
}
/* changing destination file to a DOM Document for adding extra
header
tags*/
InputStream inputGuide =
ConditionTest.class.getResourceAsStream(this.inputFileName);
try {
if (docBuilder != null )
doc = docBuilder.parse(inputGuide);
} catch (Exception e) {
throw e;
}
if (doc!= null)
conditionNodes = doc.getElementsByTagName(this.condition);
condFactory = ConditionFactory.getInstance();
if (conditionNodes != null) {
this.conds = condFactory.createConditions(conditionNodes);
Bilaga D: Testfall i JUnit
63
}
}
@After
/**
* clearing conds ArrayList after running test
*/
public void tearDown() throws Exception {
this.conds.clear();
}
@Test
public void testEquals() {
/*Test equality for (x >=1) and (x >= 1) when
the second x has another variable type or data type
The answer should be false*/
assertTrue("Equality test for (x >=1) and (x >= 1) with " +
"diffrent variable types doesn't pass!",
!this.conds.get(0).equals(this.conds.get(1)));
/*Test equality for ((x >=1) && (y<1)) and
* ((1 > y ) && (1< = x))
* the answer should be true*/
assertTrue("Equality test for ((y<1) && (x >=1)) and " +
"((x >=1) && (y<1)) doesn't pass!",
this.conds.get(4).equals(this.conds.get(5)));
}
}
2- Testfall för test av evaluering av villkor
package testcondition;
import static org.junit.Assert.*;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import com.scania.condition.Condition;
import com.scania.condition.ConditionEvaluator;
import com.scania.condition.ConditionFactory;
import com.scania.condition.Messages;
/**
*
* @author Govan Marounsi
Bilaga D: Testfall i JUnit
64
*
*@description This Class is developed to test the ConditionEvaluator.
*ConditionEvaluator has four different constructors which works with
*different parameters. they have been tested. ConditionEvalutor
*contains two method for evaluating conditions: The first one uses
*a condition data structure as a parameter and the second one is
*working on condition as parsed XML-nodes.
*/
public class ConditionEvaluatorTest {
//to save Variables name and theirs value
private String x, y, z, xValue, yValue, zValue;
// To save all the steps in a guided method with their conditions
private Map<String, Condition> steps;
// the name of inputed guided method
private String inputFileName = "ConditionEqualTest.xml";
// Array to save the condition as XML-nodes
ArrayList <Node> conditionNodes;
@Before
/**
* setUp () have been used to prepare data structure before testing.
* First it will define three variables defined in conditions
* in a guided method. After that it should parse a guided
* method named ConditionEqualTestxml. This Guided method contains
* a step named step0 connected to other steps as below:
* 1 - Step1
* ( x >= 1 )
* 2 - Step2
* ( x >= 1 )
* 3 - Step3 (x in this step is not the same x used in step1 because
* it has different type)
* ( 1 <= x )
* 4 - Step4
* ( ( y < 1 ) and ( x >= 1 ) )
* 5 - Step5
* ( ( x >= 1 ) and ( y < 1 ) )
* 6 - Step6
* ( ( 1 > y ) and ( 1 <= x ) )
* 7 - Step7
* ( ( ( 1 > y ) and ( 1 <= x ) ) or ( 1 = z ) )
* 8 - Step8
* ( ( 1 = z ) or ( ( 1 > y ) and ( 1 <= x ) ) )
* 9 - Step9
* ( ( 1 = z ) xor ( ( 1 > y ) and ( 1 <= x ) ) )
*
* setUp transformer all of these conditions from XML-elements in
* guided method to a map data structure, the step name will be
* the key and a condition nodes will be value.
* conditionNodes will hold the condition as a XML-nodes.
*/
public void setUp() throws Exception {
this.x="x";
this.y="y";
this.z="z";
this.xValue = "1";
this.yValue = "2";
this.zValue = "3";
Bilaga D: Testfall i JUnit
65
String stepName;
Condition stepCondition;
this.steps = new HashMap<String, Condition>();
DocumentBuilderFactory docFactory =
DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = null;
Document doc = null;
NodeList nextStepNodes = null;
ConditionFactory condFactory;
try {
docBuilder = docFactory.newDocumentBuilder();
} catch (ParserConfigurationException e1) {
System.exit(1);
}
// changing destination file to a DOM Document
//for adding extra header tags
InputStream inputGuide =
ConditionTest.class.getResourceAsStream(this.inputFileName);
try {
if (docBuilder != null )
doc = docBuilder.parse(inputGuide);
} catch (Exception e) {
throw e;
}
if (doc!= null) {
nextStepNodes = doc.getElementsByTagName("NextStep");
}
condFactory = ConditionFactory.getInstance();
if (nextStepNodes != null) {
this.conditionNodes = new ArrayList<Node>(nextStepNodes.
getLength());
for (int i = 0; i < nextStepNodes .getLength(); i++)
{
stepName =
((Element) nextStepNodes.item(i)).
getElementsByTagName("Step").item(0).
getTextContent();
stepCondition = condFactory.createCondition
(((Element)nextStepNodes.item(i)).
getElementsByTagName("Condition").item(0));
this.conditionNodes.add(((Element)nextStepNodes.item(i))
.getElementsByTagName(Messages.Condition).
item(0));
this.steps.put( stepName, stepCondition);
}
}
}
@After
/**
* clearing conds ArrayList after running test
*/
public void tearDown() throws Exception {
this.conditionNodes.clear();
this.steps.clear();
}
Bilaga D: Testfall i JUnit
66
@Test
/**
* test ConditionEvaluator constructor with Map <String, String>
*/
public void testConditionEvaluatorMapOfStringString() {
Map<String, String> tmpMap = new HashMap<String, String>();
tmpMap.put(this.x, this.xValue);
tmpMap.put(this.y, this.yValue);
tmpMap.put(this.z, this.zValue);
ConditionEvaluator ce = new ConditionEvaluator(tmpMap);
assert ce.getVariableSet().toString().equals("{z=3, y=2, x=1}")
: "Fault: The Constructor With a map as param";
tmpMap.put(this.x, this.zValue);
ce = null;
ce = new ConditionEvaluator(tmpMap);
assertTrue ( "Fault: The Constructor With a map as param",
ce.getVariableSet().toString().
equals("{z=3, y=2, x=3}")) ;
}
@Test
/**
* test ConditionEvaluator constructor with String []
*/
public void testConditionEvaluatorStringArray() {
String [] tmpArr = new String[11];
tmpArr[0] = this.x;
tmpArr[1] = this.xValue;
tmpArr[2] = this.y;
tmpArr[3] = this.yValue;
tmpArr[4] = this.z;
tmpArr[5] = this.zValue;
tmpArr[6] = this.z;
tmpArr[7] = this.xValue;
tmpArr[8] = this.y;
tmpArr[9] = "3"; //$NON-NLS-1$
ConditionEvaluator ce;
try {
ce = new ConditionEvaluator(tmpArr);
assertTrue("Fault: The Constructor with an array of String",
ce.getVariableSet().toString().
equals("{z=1, y=3, x=1}") );
} catch (Exception e) {
System.out.println("Can not Create Evaluator. " +
"Check the values in the input Array");
}
}
@Test
/**
* test ConditionEvaluator constructor with String [][]
*/
public void testConditionEvaluatorStringArrayArray() {
String [][] tmpArr = new String[5][2];
tmpArr[0][0] = this.x;
Bilaga D: Testfall i JUnit
67
tmpArr[0][1] = this.xValue;
tmpArr[1][0] = this.y;
tmpArr[1][1] = this.yValue;
tmpArr[2][0] = this.z;
tmpArr[2][1] = this.zValue;
tmpArr[3][0] = this.z;
tmpArr[3][1] = this.xValue;
tmpArr[4][0] = this.y;
tmpArr[4][1] = this.xValue;
ConditionEvaluator ce;
try {
ce = new ConditionEvaluator(tmpArr);
assertTrue ("Fault: The Constructor with an array of array",
ce.getVariableSet().toString().
equals("{z=1, y=1, x=1}"));
} catch (Exception e) {
System.out.println("Can not Create Evaluator. " +
"Possibly Wrong Array Dimension");
}
}
@Test
/**
* test ConditionEvaluator constructor with the string
* "x=xVlue, y=yValue,z=zValue"
*/
public void testConditionEvaluatorPropertyString() {
String equal = Messages.operatorEQ;
String comma = ","; //$NON-NLS-1$
String tmpStr= this.x + equal + this.xValue + comma +
this.y + equal + this.yValue + comma +
this.z + equal + this.zValue + comma +
this.y + equal + "4" ; //$NON-NLS-1$
ConditionEvaluator ce;
try {
ce = new ConditionEvaluator(tmpStr, comma);
assertTrue ( "Fault: The Constructor with an array of array"
,ce.getVariableSet().toString().
equals("{z=3, y=4, x=1}") );
} catch (Exception e) {
System.out.println("Can not Create Evaluator. " +
"the String is not properly constructed " +
"(variable=value) ");
}
}
@Test
/**
* test evaluate(Condition c), Condition data structure as parameter
*/
public void testEvaluateCondition() {
Map<String, String> tmpMap = new HashMap<String, String>();
tmpMap.put(this.x, this.xValue); // x = 1
tmpMap.put(this.y, this.yValue); // y = 2
Bilaga D: Testfall i JUnit
68
tmpMap.put(this.z, this.zValue); // z = 3
ConditionEvaluator ce = new ConditionEvaluator(tmpMap);
try
{
assertTrue("Step1: x= 1, Condition (x >=1) Should be true"
,ce.evaluate(this.steps.get("Step1")) );
assertTrue ("Step3:x= 1, Condition (1 <= x ) Should be true"
, ce.evaluate(this.steps.get("Step3")) );
assertTrue( "Step4:x=1, y =2: Condition ((y<1) && (x >=1))"+
"Should be false",
!ce.evaluate(this.steps.get("Step4")));
assertTrue ( "Step5: x=1, y =2: Condition " +
"((x >=1) && (y<1)) Should be false",
!ce.evaluate(this.steps.get("Step5")) );
assertTrue ( "Step7: x=1, y =2, z= 3 :Condition " +
"(((y<1) && (x >=1)) || (z=1)) Should be false",
!ce.evaluate(this.steps.get("Step7")) );
assertTrue( "Step9: x=1, y =2, z= 3 :Condition (((y<1) && "+
"(x >=1)) ^ (z=1)) Should be false",
!ce.evaluate(this.steps.get("Step9")) );
ce.addVariable(this.z, this.xValue); // z = 1
assertTrue("Step7: x=1, y =2, z= 3 y = 4: Condition " +
"(((y<1) && (x >=1)) || (z=1)) Should be true ",
ce.evaluate(this.steps.get("Step7"))) ;
assertTrue( "Step9: x=1, y =2, z= 3 :Condition " +
"(((y<1) && (x >=1)) ^ (z=1)) Should be true",
ce.evaluate(this.steps.get("Step9")) );
}catch (Exception e){
fail("Wrong considitions!");
}
}
@Test
/**
* test evaluate(Node c), XML node as parameter
*/
public void testEvaluateNode() {
Map<String, String> tmpMap = new HashMap<String, String>();
tmpMap.put(this.x, this.xValue); // x = 1
tmpMap.put(this.y, this.yValue); // y = 2
tmpMap.put(this.z, this.zValue); // z = 3
ConditionEvaluator ce = new ConditionEvaluator(tmpMap);
try
{
assertTrue("Step1: x= 1, Condition (x >=1) Should be true",
ce.evaluate(this.conditionNodes.get(0)));
assertTrue("Step3:x= 1, Condition (1 <= x ) Should be true",
Bilaga D: Testfall i JUnit
69
ce.evaluate(this.conditionNodes.get(2)));
assertTrue("Step4: x=1, y =2: Condition " +
"((y<1) && (x >=1)) Should be false",
!ce.evaluate(this.conditionNodes.get(3)));
assertTrue( "Step5: x=1, y =2: Condition " +
"((x >=1) && (y<1)) Should be false",
!ce.evaluate(this.conditionNodes.get(4)) );
assertTrue("Step7: x=1, y =2, z= 3 :Condition " +
"(((y<1) && (x >=1)) || (z=1)) Should be false",
!ce.evaluate(this.conditionNodes.get(6)));
assertTrue("Step9: x=1, y =2, z= 3 :Condition " +
"(((y<1) && (x >=1)) ^ (z=1)) Should be false",
!ce.evaluate(this.conditionNodes.get(8))) ;
ce.addVariable(this.z, this.xValue); // z = 1
assertTrue( "Step7: x=1, y =2, z= 3 y = 4: Condition" +
" (((y<1) && (x >=1)) || (z=1)) Should be true ",
ce.evaluate(this.conditionNodes.get(6)));
assertTrue ( "Step9: x=1, y =2, z= 3 :Condition " +
"(((y<1) && (x >=1)) ^ (z=1)) Should be true",
ce.evaluate(this.conditionNodes.get(8)));
}catch (Exception e){
fail("Wrong considitions!");
}
}
}
Bilaga E: Förkortningar
71
Bilaga E: Förkortningar ABS Anti-lock Braking System
ACC Automatic Climate Control
AWT Abstract Window Toolkit
CAG Computer Aided Gearchanging
CAN Controller Area Network
CDAPP Construction Data APPlication
CHIN CHassis INformation system
COO COOrdinator
CRC Cyclic Redundancy Check
DLC Data Length Code
DLL Dynamic-Link Library
DOM Data Object Model
DTD Document Type Definition
ECU Electronic Control Unit
EMS Engine Management System
HTML HyperText Markup Language
IBM International Business Machines
IDE Integrated Development Environment
JESS Java Expert System Shell
MVC Modell View Controller
OWL Web Ontology Language
PDL Propositional Dynamic Logic
SD (SD 2) Scania Diagnose
SDP3 Scania Diagnose & Programmer 3
SDP3 IPM Scania Diagnose & Programmer 3 Interimistisk ProduktionsMiljö
SDP3 PM Scania Diagnose & Programmer 3 ProduktionsMiljö
SDP3 PT Scania Diagnose & Programmer 3 Production Tools
SGML Standard Generalized Markup Language
SP Scania Programmer
SWRL Semantic Web Rule Language
SWT Standard Widget Toolkit
UML Unified Modeling Language
W3C World Wide Web Consortium
WINGS Workshop Information Next Generation Scania
XML eXtensible Markup Language
XSLT eXtensible Stylesheet Language Transformations
TRITA-CSC-E 2012:076 ISRN-KTH/CSC/E--12/076-SE
ISSN-1653-5715
www.kth.se