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.


<trappa/>



</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])


<trappa/>



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/

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.


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.


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


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.


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.


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


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.


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.


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


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


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


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/

http://www.jessrules.com/


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

http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html


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.


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.


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


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.


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()


BinaryOpCondition

# BinaryOpCondition()


SimpleCondition

# SimpleCondition()


AtomicOperand

- dataType: string

«property get»

+ getdataType() : string

«property set»

+ setdataType(string) : void

Constant

- value: String


«property get»

+ getvalue() : String

«property set»

+ setvalue(String) : void

Variable

- name: 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()


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)


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


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


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.


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()


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.

https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words

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.

http://download.oracle.com/javase/1.5.0/docs/guide/javaws/developersguide/faq.html

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>


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>


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


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


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);


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


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";


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);


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();

}


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",


equals("{z=1, y=3, x=1}") );


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;


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[4][0] = this.y;



try {

ce = new ConditionEvaluator(tmpArr);

assertTrue ("Fault: The Constructor with an array of array",


equals("{z=1, y=1, x=1}"));



"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$


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}") );



"the String is not properly constructed " +

"(variable=value) ");

}

}

@Test

/**

* test evaluate(Condition c), Condition data structure as parameter

*/

public void testEvaluateCondition() {


tmpMap.put(this.x, this.xValue); // x = 1

tmpMap.put(this.y, this.yValue); // y = 2


68

tmpMap.put(this.z, this.zValue); // z = 3


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",


assertTrue( "Step9: x=1, y =2, z= 3 :Condition (((y<1) && "+

"(x >=1)) ^ (z=1)) Should be false",


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() {


tmpMap.put(this.x, this.xValue); // x = 1

tmpMap.put(this.y, this.yValue); // y = 2

tmpMap.put(this.z, this.zValue); // z = 3


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",


69


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 ",


assertTrue ( "Step9: x=1, y =2, z= 3 :Condition " +

"(((y<1) && (x >=1)) ^ (z=1)) Should be true",


}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

mjukvaruverktyg för analys av satser i satslogiken inbäddade i xml

Documents