Mjukvaruverktyg fr analys av satser i satslogiken inbddade i XML ...

  • Published on
    10-Jan-2017

  • View
    218

  • Download
    0

Transcript

  • Mjukvaruverktyg fr analys av satser i satslogiken inbddade i XML-filer

    G O V A N M A R O U N S I

    Examensarbete Stockholm, Sverige 2012

  • Mjukvaruverktyg fr analys av satser i satslogiken inbddade i XML-filer

    G O V A N M A R O U N S I

    DD245X, Examensarbete i datalogi om 30 hgskolepong vid Magisterprogram, programvaruutveckling 60 hgskolepong Kungliga Tekniska Hgskolan r 2012 Handledare p CSC var Alexander Baltatzis Examinator var Olle Blter TRITA-CSC-E 2012:076 ISRN-KTH/CSC/E--12/076--SE ISSN-1653-5715 Kungliga tekniska hgskolan Skolan fr datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

  • Arbetet tillgnas till min far,

    som har rest bakom evigheterna

  • Mjukvaruverktyg fr analys av satser i

    satslogiken inbddade i XML-filer

    Elektronikens intg i fordonsindustri har lett till fordon med mer funktionalitet som ven r mer

    komplexa att felska. Drfr erbjuder olika fordonstillverkare mjukvaruverktyg som hjlper

    mekanikerna vid felskning. Scania som r en pionjr i buss- och lastbilstillverkning har

    utvecklat ett eget verktyg som kallas fr SDP3 (Scania Diagnose & Programmer). Guidade

    metoder r de underlag som utformas av metodingenjrerna p Scania och anvnds vid

    felskning av mekanikerna genom SDP3. Guidade metoder utformas i form av XML-filer och

    innehller villkor som styr fldet i metoden och interaktionen med bde mekaniker och fordon.

    Guidade metoder och annan information transformeras med hjlp av ett internt verktyg (SDP3

    Production Tool) till den databas som anvnds i SDP3.

    Villkoren i guidade metoder skapas genom jmfrelser mellan olika variabler eller mellan

    variabler och konstanta vrden. Dessa jmfrelser utfrs med hjlp av relationsoperatorer.

    Jmfrelser kan kombineras med varandra med hjlp av logiska operatorer i satslogiken och det

    r dessa jmfrelser eller deras kombinationer som r villkoren i guidade metoder. Guidade

    metoder kan vara relativt stora och villkoren kan vara fr komplexa fr att hanteras av

    mnniskor. Drfr behvs ett verktyg fr att mjliggra test och analys av guidade metoder

    innan de ska tas i bruk. Detta var examensarbetets ml.

    I detta arbete har ett anvndargrnssnitt med hjlp av HTML och XSLT utvecklats. Via detta

    anvndargrnssnitt kan metodingenjrerna mata in variablernas vrde. Sedan evalueras

    villkoren baserat p inmatade vrde i ett ramverk som har skrivits i Java och resultatet av

    evalueringen visas till metodingenjrerna. Kopplingen mellan anvndargrnssnittet och

    evalueringsramverket implementeras via Java-plugin Technology ven knt med namnet

    Applet. Med hjlp av detta verktyg kan metodingenjrerna 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 SDP3s 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 methods designers) can input the variables values by using it. After

    that the conditions will be evaluated by an evaluation framework developed in Java. The

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

  • Frord

    Det bsta med att skriva r det unika tillfllet som man fr fr att tacka hgt och tydligt dem

    som betyder i ens liv. Jag tar detta tillflle i akt fr att tacka de mest viktiga personerna i mitt

    liv: min mor och mina syskon som har varit med hela vgen. Jag tackar ocks dem som har

    hjlpt till med detta arbete.

    Min handlare p KTH, Alexander Baltatzis, och p Scania YSET, Mohammad Khaledi, fr

    deras tlamod, std och tid tackar jag.

    Utvecklare av SDP 3 PT p YSET Jakob Palmheden, Kerstin Simonsson, Anders Stefansson,

    Gran berg som hjlpte mig p alla mjliga stt och var s genersa att dela med sig sina

    vrdefulla kunskaper.

    Ett speciellt tack till Stefan stergaard inte bara fr att han korrekturlste rapporten utan ven

    fr all tid han gande t mig senaste ret.

    Emma Leeb-Lundberg p YSEA-avdelningen p Scania som svarade alltid vnligt och

    tlmodigt p mina sprkliga frgor.

    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 fr hans rd och frklaringar angende simulering.

    Shahab Mokarizadeh fr den information och rdgivning som han gav om regelbaserad

    programmering.

    Studenterna vid grupphandledning fr deras sikter som hjlpte att frbttra arbetet: Niclas

    Andersson, Mark Bartish, Jonatan Petersson och Andr Strindby.

  • Innehllsfrteckning

    1. Inledning ............................................................................................................................... 1

    1.1. Fordon och elektronik ................................................................................................... 2

    1.1.1. Elektroniska styrenheter ........................................................................................ 2

    1.1.2. Controller Area Network ....................................................................................... 3

    1.2. Felskning, 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 ml ....................................................................................... 11

    2. Frkunskaper ....................................................................................................................... 16

    2.1. XML-vrlden .............................................................................................................. 16

    2.1.1. XML-parsning ..................................................................................................... 18

    2.1.2. XSLT ................................................................................................................... 19

    2.1.3. XPath ................................................................................................................... 21

    3. Mjukvaruverktyg fr villkorsanalys .................................................................................... 25

    3.1. Avgrnsningar ............................................................................................................. 26

    3.2. Anvndargrnssnitt fr inmatning av variablernas vrde............................................ 26

    3.2.1. Logiken i skapandet av anvndargrnssnittet ...................................................... 27

    3.2.2. Utvrdering ......................................................................................................... 28

    3.2.3. Implementering ................................................................................................... 29

    3.2.3.1. Gruppering i XSLT ..................................................................................... 32

    3.2.3.2. Anvndande av olika XSLT-processor ....................................................... 34

    3.3. Evalueringsramverket ................................................................................................. 34

    3.3.1. Utvrdering ......................................................................................................... 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 anvndargrnssnittet 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: Utvrdering av olika typer av Datastrukturer fr villkoren ........................................ 59

    Bilaga D: Testfall i JUnit ............................................................................................................ 61

    1- Testfall fr test av funktionen equals i villkors datastruktur .............................. 61

    2- Testfall fr test av evaluering av villkor ................................................................. 63

    Bilaga E: Frkortningar .............................................................................................................. 71

  • Inledning

    1

    1. Inledning I inledningen kommer frst en allmn bakgrund. Drefter presenteras de viktigaste

    begreppen inom fordon som relaterar till examensarbetet. I nsta del ges en verblick

    ver felskning och mjukvaruverktyg fr den p Scania. Sista delen beskriver

    examensarbetets syfte.

    Det r inte ltt fr ngon att bedma den tid han eller hon lever i. Okunskapen om framtiden

    begrnsar ens omdme och gr det omjligt att ha en verblick ver tiden som man befinner sig

    i eller att kunna jmfra den med framtiden. Trots det kan kanske de som levt under de sista

    ren av nittonhundratalet eller i brjan av detta sekel hvda att de har upplevt de snabbaste

    frndringarna i mnniskans livsstil ngonsin. Utvecklingen av elektronik och relaterad

    vetenskap r utan tvekan en av de strsta anledningarna till de hr frndringarna. Denna

    utveckling har tills nu pverkat fordonsindustrin radikalt och det r kanske bara brjan.

    Ett bra exempel som visar de snabba frndringarna inom fordonsindustrin r antalet bilar som

    har tillverkats av Scania fram tills nyrsafton 1990. Det tog drygt 88 r att tillverka hlften av

    de 620 000 fordon som levererats fram tills det. Medan andra hlften allts gick p mindre n

    tolv r [Scania 100 r 1991, s.7]. Inte bara fordonens tillverkningsstt har ndrats utan ven

    sjlva fordonen har frndrats mycket. Moderna fordon innehar mnga nya funktioner som

    implementerats med hjlp av elektronisk utrustning. Elektronik har ocks hjlpt till att frbttra

    mnga av fordonens gamla funktioner.

    Mer funktionalitet medfr mer komplexitet. Att felska och laga moderna fordon har blivit allt

    svrare. Dels fr att de har fler funktioner och drfr r underhllet svrare, dels fr att

    reparation av elektroniska instrument r svr. I mnga fall r det billigare och lttare att kpa ett

    nytt instrument istllet fr att laga det gamla instrumentet. Drfr behver mekaniker och de

    som felsker fordonen moderna verktyg och hjlpmedel fr sitt arbete. Verktyg som kan avlsa

    eller skriva om information frn elektroniska enheter. Behov av sdana verktyg r viktigare nr

    det handlar om lastbilar och bussar som r mer komplexa n personbilar.

    Scania r en av vrldens ldsta biltillverkare som redan efter frsta vrldskriget koncentrerade

    sig p lastbilar och bussar. Efter andra vrldskriget inleddes en exportoffensiv som gjort Scania

    till en av vrldens strsta tillverkare av tunga lastbilar och bussar [Lindh 1992]. En sdan lng

    historia inom fordonsindustrin krver att fretaget stndigt 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 frsta lastbilstillverkare

    presenterat sin epokgrande datorstyrda vxellda []. Den datorstyrda vxellda CAG

    (Computer Aided Gearchanging) inledde elektronikens intg i lastbilstekniken [Scania 100 r

    1991, s. 206].

    Innan jag brjar beskriva examensarbetets problem kommer jag att presentera de begrepp som

    r viktiga fr att frst problemet. Frst presenterar jag de begrepp som r relaterade till

    fordonens hrdvara och sedan gr jag igenom begrepp lnkade till mjukvaruverktyg fr

    felskning av fordon p Scania.

  • Inledning

    2

    1.1. Fordon och elektronik

    Som nmndes tidigare anvnder sig moderna fordon av ett elektroniskt system. Hjrnan i ett

    elektroniskt system r ECU (Electronic Control Unit) [HILLIER 1996, s.111]. ECU har

    versatts till svenska som elektroniska styrenheter. I fortsttningen kommer jag att anvnda

    ordet styrenheter istllet fr ECU eller elektroniska styrenheter.

    1.1.1. Elektroniska styrenheter

    Styrenheter anvnds i olika elektroniska system. I den hr rapporten kommer de bara att

    presenteras i samband med fordon. En styrenhet r en dator som kontrollerar olika funktioner i

    fordonets olika subsystem med hjlp av mottagna signaler frn ngra givare. Utver en dator

    bestr 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 stt

    kan man uppgradera mjukvaran och sdana styrenheter kallas fr 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 sdan 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. Ngra 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

    ngra styrenhetsfamiljer i en lastbil [Karlbck 2010, s.6].

    Figur 1.1 Styrenheter i en lastbil. Varje tillverkare kategoriserar dem p olika stt.

    1 Stlldon

  • Inledning

    3

    1.1.2. Controller Area Network

    Styrenheterna kan skicka vidare de signalerna som de fr frn olika givare, generator och

    aktuatorer till andra styrenheter eller till externa datorprogram. Ngra exempel p sdana

    signaler r: Hjulhastighet, olja- och vattentemperatur, motors r/min, vxelval, gaspedalens lge,

    klimatkontrollinstllningar och felkoder.[Davis 2007, s.242]

    Mnga av dessa signaler mste behandlas snabbt och i realtid. T.ex. en styrenhet avlser

    bromspedalens lge och skickar drefter vidare en signal om att bromsen har trampats ner till

    den styrenhet som r ansvarig fr bakre belysningen. Den styrenhet som tar emot signalen

    tnder i sin tur bromsljusen. Tabell 1.1 visar olika signaler i en BMW-personbil och kraven fr

    kommunikation mellan olika styrenheter [Davis 2007, s.242].

    Position i bil Antal styrenheter Bandbredd Antal signaler Gngtid

    Karosseri 1430 100 Kbits/s 300 50 ms - 2 s

    Chassi 610 500 Kbits/s 180 10 ms -1 s

    Drivlina (Powertrain)2 36 500 Kbits/s 36 10 ms- 10 s

    Tabell 1.1 BMW 7 Seriens krav fr kommunikation mellan styrenheter

    Enligt [Davis 2007, s.242] kan det finnas mer n 2500 tskilda signaler. Fr att hantera dessa

    signaler och samordna kommunikationen mellan styrenheter eller mellan styrenheter och

    externa datorer r det ndvndigt att bygga ett ntverk. CAN (Controller Area Network) r ett

    ntverk som har konstruerats i det syftet. CAN r en kommunikations seriebuss som r till fr

    att tillhandahlla enkel, effektiv och robust kommunikation fr fordonets ntverk. CAN har

    utvecklats av Robert Bosch GmbH i brjan av 1983. Intel och Philips slppte ut frsta CAN:s

    kontrollerchips 1987. Mercedes var den frsta som 1991 anvnde CAN3 i ett fordon. [Davis

    2007, s.240]

    CAN r ven protokollnamnet som anvnds i fordonets ntverk. Styrenhetssignaler utformas i

    informationspaket som verfrs mellan enheter. Bild 1.2 visar ett standardpaket enligt CAN-

    protokollet [Davis 2007, s.245]. DLC str fr Data Length Code och visar lngden av data

    (mellan 0 till 8 byte). CRC str fr Cyclic Redundancy Check och anvnds fr att kontrollera

    om ngot fel hnt under verfringen.

    Bild 1.2. Paketformat i CAN-protokoll

    2 Drivlina r den samling av delar i fordonet som driver det. Den bestr av motor, koppling, vxellda,

    kardanaxel och bakaxel.

    3 Mnga skriver CAN-ntverk, men eftersom bokstaven N i CAN str fr ntverk undvek jag det. Jag

    anvnder CAN nr jag syftar p ntverket.

  • Inledning

    4

    Tabell 1.1 visar att olika delar av fordonet anvnder databussar med olika hastighet. Styrenheter

    som ligger i karosserien anvnder 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. Fr att f ett ntverk med databussar med olika hastighet anvnder man

    en frmedlingsnod (Gateway) som styrs av en speciell styrenhet. P Scania anvnds tre olika

    databussar i CAN som namngetts grn, gul och rd. Den styrenheten som fungerar som en

    frmedlingsnod mellan de tre databussarna och samordnar anslutningen mellan dem r COO

    (COOrdinator). Bild 1.3 framstller 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 anvnds i moderna fordon.

    En viktig del av elektroniska anordningar r mjukvara. Mjukvara r grnssnittet mellan

    mnniska och elektroniska instrument. Med hjlp av mjukvara ger man nya instruktioner till

  • Inledning

    5

    instrumentet eller lser av de information som instrumentet producerar. I nsta del presenteras

    de mjukvaror som anvnds i samband med felskning av fordon p Scania.

    1.2. Felskning, mjukvaruverktyg och guidade

    metoder

    Den snabba elektroniska utvecklingen har genom kad funktionalitet och avancerade

    teknologier gjort fordonen mer felbengna samtidigt som felskning av fordon har blivit allt

    svrare. Traditionellt kunde mekaniker via egen erfarenhet lista ut vilken funktionalitet som

    fanns p ett fordon. Han kunde med hjlp av erfarenhet frst vilka komponenter som berrdes

    av vilka fel och fr det mesta felskte han endast med hjlp av egna sinnen.

    Nr en stor del av fordonet styrs av styrenheter och mjukvara, r det omjligt att felska bara

    med hjlp av okulra inspektioner. Ett annat problem r att mjukvaran ofta r konfigurerbar. Det

    innebr att tv identiskt utrustade fordon kan ha olika konfigurationer och drmed uppfra sig

    olika. Drfr kan en mekanikers erfarenhet av ett visst fordon inte teranvndas p ett likadant

    fordon utan vidare. P grund av detta behver mekaniker speciella verktyg som hjlper dem

    med felskning och konfiguration av styrenhetsmjukvara.

    En av felskningsmjukvarans funktioner r att visa upp instruktioner och information till

    anvndare som leder honom/henne under felskningen. Dessa instruktioner och information

    utformas och tecknas av experter inom respektive omrde. P Scania r det metodingenjrer

    som har uppgiften att utforma dessa felskningsinstruktioner dr kallas de fr guidade

    metoder.

    I de tv fljande avsnitten presenteras de verktyg som anvnds p Scania vid felskning och

    styrenhetsmjukvarukonfiguration och beskrivs guidade metoder mer utfrligt.

    1.2.1. Mjukvaruverktyg

    SDP3 (Scania Diagnose & Programmer 3) r den mjukvara som Scania har tillverkat fr

    felskning och konfiguration av styrenheter. SDP3 PT (Scania Diagnose & Programmer 3

    Production Tool) r ett internt mjukvaruverktyg som anvnds fr att integrera och skapa olika

    typer av information som SDP3 behver.

    Utver dessa tv mjukvaror finns det en mngd av program och applikationer som berr

    fordonets elsystem. Mnga 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 grs

    en nrmare genomgng 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 fr felskning av elsystemet (Scania Diagnose) respektive konfiguration av det (Scania

    Programmer). En utredning p Scania som freslog de frndringarna 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 anvnda Scania Diagnos.

    Scania Diagnos och Scania Programmer betraktas drfr av fretaget som strategiska produkter, vilka ska ha en hg tillgnglighet p marknaden.

    Enligt utredningen stdde SD felskning av en styrenhet i taget. Diagnosprogrammet kunde lsa

    ut felkoder, lsa ingngar och aktivera utgngar. Mekaniker fick tillgng till mlinriktad

    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 hjlp av programmet fr att kunna utvrdera felkoderna, sett i ett helhets-

    perspektiv. Nr programmet inte var anslutet till ngon styrenhet kunde det anvndas i

    demolge fr utbildning. Utredningen beskrev Scania Programmer som ett separat program som

    anvndes fr att konfigurera fordonet. Konfigurationen utfrdes genom att ange ett antal

    parametrar som sedan matades in och lagrades i styrenheten. Parametrarna var begripliga fr

    mekaniker men det krvdes nd stort std i form av hjlpinformation.

    SD2 som lanserades 1994 var sista versionen av Scania Diagnos innan SD omvandlades till

    SDP3. I ett dokument p Scania [Ivendal 1998] (dr namnet SDP3 anvnds fr frsta gngen

    formellt) ges kompatibilitet med Scanias nya elsystem (SESAMM) som strsta anledningen fr

    att g ver till SDP3.

    Utver kompatibilitet med elsystemet tas ngra andra problem som fanns i SD2 upp i [Ivendal

    1997, Ivendal 1998] fr att frklara behovet av SDP3. Bland annat att felskningstnkandet i

    SD2 fokuserade p styrenheter och system. Men felskningstnkande borde utg frn frarens

    och mekanikerns perspektiv p fordonets funktioner och egenskaper i framtida generationer av

    programmet. Med andra ord stdde SD inte felskning p flera styrenheter samtidigt och

    mekanikern kunde inte f den helhetssyn som behvdes fr felskning. Ett annat problem med

    SD2 var att tillgng till kompletterande information som funktionsbeskrivning,

    arbetsbeskrivning fr komponentbyte och handhavandeinstruktioner saknades. Det ansgs ocks

    att det borde finnas mer information om de fel som uppstod i fordonet. SD2 producerade en

    mngd felkoder p fr lg niv och d fick mekanikern svrt att avgra i vilken nde

    felskningen skulle brjas. [Ivendal 1997] freslr en annan frndring i SD och SP:

    I de allra flesta fall r det olyckligt att Scania Programmer r ett separat program. Flertalet anvndare ser det som en frdel om programmering hade kunnat utfras inne i

    diagnosprogrammet.

    P grund av dessa problem och ngra andra som inte tas upp hr inleddes arbetet med projektet

    SDP3. Huvudsyftet med SDP3 beskrivs i [Ivendal 2000, s.4]:

  • Inledning

    7

    Syftet med SDP3 r att i frsta hand stdja mekaniker p Scanias serviceverkstder i

    reparationsprocessen. SDP3 stdjer ocks anpassning av fordonets grnssnitt mot

    produkter frn andra leverantrer t.ex. anpassning av pbyggarnod.

    SDP3 implementerades med ett antal delml, bland annat [Ivendal 2000, s.4]:

    Att kunna leda mekanikern rtt vid felskning utifrn vad kunden klagar p (d.v.s. ur fordonets funktionella aspekter)

    Att kunna utfra guidad fordonsfunktionskontroll och komponentkontroll inklusive prestationskontroll

    Att kunna aktivera och avlsa signalvrden p givare och aktuatorer

    Att kunna hantera behrighet fr olika anvndarkategorier p Scanias service verkstder

    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 fr de delar som mekaniker fr tillfllet arbetar med

    Att programmet ska frses med generell utskriftsfunktionalitet

    Att utfrda kontroller ska kunna loggas och lagras och skrivas ut s att de kan fungera som verifikation fr utfrt arbete

    Att programmet skulle kunna kommunicera med fordonet enligt freskriven standard

    Att olika sprk skulle stdjas 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 tillta att man lgger till och tar bort funktionalitet

    Att programmet skulle tillta att anpassningar grs p fordonets funktionalitet, t.ex. anpassning av maxhastighets begrnsning

    Att ombyggnation av fordon med nya styrenheter och komponenter skulle vara mjlig

    Att kunna terstlla det fordonsfunktionalitet som fordonet hade vid leveransdatum

    SDP3 anvnds av ca 1500 verkstder och varje r ges fyra utgvor 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-std fr att kunna utfra5:

    Service/underhll

    Felskning

    Reparationer

    Ombyggnationer

    4 Pstendet r hmtat frn en av Scania:s interna presentationer.

    5 YS-uppgifter har tagits frn Scania:s intrant, YS-sidor.

  • Inledning

    8

    Kampanjer

    Reservdelsfrsljning

    Information till fraren

    1.2.1.2. SDP3 Production Tool

    Som nmndes 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 anvndare t.ex. metodingenjrer med SDP3. SDP3 PT fungerar som ett grnssnitt mellan

    olika applikationer och anvndare 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 anvndare och andra applikationer

    P Scania finns flera applikationer som innehller information om fordonet, anvnder

    styrenheter eller pverkar fordonets elsystem. Utdata (ofta i XML-format) av ngra av dem

    anvnds i SDP3. SDP3 Production Tool vervakar integrationen mellan deras utdata och SDP3.

    Exempel p andra applikationer r CDAPP (Construction Data APPlication). Konstruktionsdata

    kommer frn flera kllsystem och i form av HTML, text, XML och vrigt verfrs 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 anvnder SQL Server 2000

    som databas [Dubois 2010, s.3]. Exempel p kllsystem fr CDAPP r CHIN (CHassis

    INformation system). CHIN r Scanias chassidatabas och behandlar specifikationer av samtliga

    chassier som r bestllda eller byggda. En annan applikation som deltar i processen att skapa

    data fr SDP3 kallas fr WINGS (Workshop Information Next Generation Scania). I WINGS

    arbetar teknikinformatrer med att skriva teknisk information fr olika eftermarknadsprodukter,

    ssom SDP3, verkstadshandbok, frarhandbok mm. [WEILAND 2005, S.3]. Det r

    6 Bilden r hmtad frn Scania:s interna presentationer med lite frndring.

  • Inledning

    9

    teknikinformatrens uppgift att skriva information om olika sorters produkter t.ex. en viss

    motor, en magnetventil eller en felskningsmetod och de anvnder WINGS fr detta syfte.

    SDP3 PT var resultatet av projektet SDP3 PM (Scania Diagnose & Programmer 3 Produktions-

    Milj) som brjade augusti 2004. Innan dess anvndes SDP3 IPM (Scania Diagnose &

    Programmer 3 Interimistisk Produktionsmilj) fr att integrera och skapa information fr SDP3.

    Fr att producera varje SDP3-utgva krvdes en mngd 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 metodingenjr och som beskriver metoder fr felskning i fordon. Detta kan t.ex. vara en metod fr

    motortest av en lastbil.

    Konstruktionsunderlag. Underlag som levereras av konstruktionsavdelningarna p Scania. Underlagen levereras i varierande format. Det kan vara allt frn

    manuellt skrivna Excel-dokument till XML-exporter frn externa system.

    Konstruktionsunderlagen refereras ofta frn metodunderlagen. Exempel p

    konstruktionsunderlag r komponentbiblioteket som definierar komponenter som

    t.ex. lampor etc.

    IPM utvecklades inte med ett lngsiktigt fokus. Det var ett medvetet val p grund av tids- och

    resursbrist. Drfr var IPM en komplex, svranvnd och svrfrvaltad, kostnads- och

    resurskrvande milj fr de inblandade aktrerna [Gugala 2009, s.8]. Dessutom med tiden blev

    nya aktrer inblandade i processen att skapa underlag till SDP3. T.ex. redaktrer som skrev

    hjlptexter. IPM var ursprungligen inte avsett fr detta och verktygen i IPM gav inte tillrckligt

    effektivt std fr dessa aktrer [Gugala 2009, s.8]. Det fanns en rad andra problem ocks. T.ex.

    fyllde anvndargrnssnittet inte kraven p anvndbarhet, fr mnga 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 frmsta uppgift r att importera ndvndiga data, kontrollera konsistensen och

    transformera data till det format som kan anvndas i SDP3. Ett verktyg som kallas fr DBTool

    skapar SDP3:s databas baserat p SDP3 PT:s filer. Bild 1.5 7 visar detta frlopp.

    Bild 1.5 Frloppet av databasbygge fr SDP3

    7 Bilden r hmtad frn Scania:s interna presentationer.

  • Inledning

    10

    1.2.2. Guidade metoder

    Guidade metoder r de underlag som definieras av metodingenjrer och beskriver felskningen

    i fordon. Eftersom examensarbetet handlar om dessa metoder inom SDP3 PT r det ndvndigt

    att de som lser rapporten knner till deras struktur.

    Guidade metoder tillhandahlls i XML-format. Varje guidad metod innehller ett eller flera

    steg. Varje steg visar upp information eller instruktioner till anvndaren som ofta r

    mekanikern. Informationen och instruktionerna kallas fr stegets innehll (Step content). Det

    steg vars innehll visas fr anvndaren under SDP3:s krning kommer att kallas det aktuella

    steget i fortsttningen. Stegen kopplas till varandra genom XML-elementet NstaSteg. Varje

    steg kan ha noll till mnga NstaSteg-element. Ett NstaSteg-element refererar till ett steg i

    samma guidade metod som det hnvisande steget finns i. Detta steg kan bli det aktuella steget

    efter det steg som refererar till det. Vilket av de NstaSteg-element som refereras av det

    aktuella steget kommer att bli aktuellt bestms av ett villkor. Med andra ord innehller varje

    NstaSteg-element ett Villkor-element. Fast det r mjligt att ett NstaSteg-element inte

    har ngot villkor. I sdant fall visas det steget direkt fr anvndaren nr han trycker p knappen

    nsta i anvndargrnssnittet utan att ngot villkor evalueras.

    Villkor i varje steg bestr av jmfrelser av variabler med varandra eller mellan variabler och

    konstanta vrde. Jmfrelserna utfrs med hjlp av relationsoperatorer (Lika med, strre n,

    mindre n m.fl.). Dessa jmfrelser kan betraktas som logiska satser 8. Dessa satser kombineras

    med hjlp av logiska operationer (and, or, not, exklusive or). I varje sats finns minst en variabel

    (hgst tv) som kan vara av olika typer. Ett variabel anges av ett namn och dess vrde kommer

    att lsas frn styrenheterna eller matas in av anvndaren eller produceras av programmet SDP3

    under programmets krning. Typen kan visa om variabeln har lsts av en styrenhet eller har

    lagrats i system som ett vrde eller r en variabel som indikerar en felkod m.m. Variabeln

    jmfrs med ett konstant vrde (eller med en annan variabel). Konstanten r ett vrde som kan

    vara av typen heltal, flyttal, boolesk, teckenstrng eller kombinerad.

    Ett vanligt scenario i SDP3 kan beskrivas enligt fljande: Ett steg som innehller mnga

    NstaSteg visas fr anvndaren i SDP3:s anvndargrnssnitt. Programmet kontrollerar om

    villkoret fr NstaSteg gller och visar i s fall upp innehllet av steget. I bilaga A visas ngra

    steg av en guidad metod i SDP3. En guidad metod kan innehlla 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 utkad variant av en guidad metod som

    medger samtidig justering av flera styrenheter fr distribuerad funktionalitet.

    8 Logic Propositions. Logiken r satslogik.

  • Inledning

    11

    1.3. Problembeskrivning och ml

    Abstraction is the key to managing complexity.

    Andrew S. Tanenbaum

    Guidade metoder kan betraktas som hjlpmedel fr felskning av fordonen. Metodingenjrerna

    p Scania har till uppgift att utforma, formulera och implementera lmpliga guidade metoder

    som sedan ska anvndas av mekaniker via SDP3.

    Guidade metoder kan vara stora och komplexa. Med andra ord kan de vara overskdliga om

    man vill hantera dem som vanliga XML-filer.9 Drfr behver metodingenjrerna ett mjukvaru-

    verktyg som hjlper dem i samband med design och implementering av guidade metoder.

    Utvecklarna i SDP3 Production Tool-teamet p Scania har utvecklat en grafisk editor som gr

    det mjligt att se guidade metoder grafiskt (Bild 1.6). Rektanglarna i bilden visar olika steg i en

    guidad metod och romber frestller 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 frestller villkor.

    Om man vljer ett steg eller ett villkor kan man se utfrligare information om dem p en panel i

    den grafiska editorn. Den grafiska editorn frser metodingenjrerna med ett verktyg fr att se en

    grafisk modell ver en guidad metod. Med hjlp av det verktyget kan metodingenjrerna

    analysera guidade metoder lttare. Verktyget skapar ven gynnsamma frutsttningar fr att

    utforma nya guidade metoder. Men den uppfyller inte metodingenjrernas alla krav. Bland

    annat kan metodingenjrerna inte testa om stegen r kopplade p rtt stt. Som tidigare nmnts

    r villkoren i guidade metoderna logiska satser. Ett annat problem som metodingenjrerna stter

    9 Guidade metoder kan verstiga en storlek p ett hundra kilobyte.

  • Inledning

    12

    p r att villkoren i guidade metoder kan vara komplexa och svra att verifiera. Bild 1.7 visar

    upp en komplex guidad metod i SDP3 PT:s grafiska editor. Som bilden visar bestr den hr

    guidade metoden av mnga steg och villkor och det r svrt att behrska guidade metodens

    struktur eller att bedma om villkoren r korrekta.

    Bild 1.7 Guidade metoders komplexitet

    Examensarbetets ml r att implementera ett mjukvaruverktyg med vars hjlp

    metodingenjrerna kan analysera och testa villkoren i guidade metoder. Detta verktyg br

    integreras med den grafiska editorn i SDP3 PT fr att komplettera de mjligheter som redan

    finns. Fr att testa ett system br man terskapa de parametrar och omstndigheter som systemet

    rkar ut fr nr det tas i bruk. De parametrar som spelar roll i villkoren och villkorsanalys r

    variablerna i villkoren. Med andra ord br variablernas vrde produceras p ngot stt fr att

    kunna testa villkoren i guidade metoder.

  • Inledning

    13

    Bild 1.8 visar olika stt att studera och testa ett system (Bilden har hmtats frn [Law 2000,

    s.4]). Som framgr av bilden kan man tnka sig att testa guidade metoder mot det faktiska

    systemet som i det hr fallet r ett fordon. P det sttet kan man producera variablernas vrde.

    Ett hinder fr att testa guidade metoder mot fordonet r att metodingenjrer inte alltid har

    tillgng till det fordon som den guidade metoden r till fr. ven om fordonet r tillgngligt kan

    kostnaden fr att testa guidade metoden mot det vara avsevrd.10

    Ett annt problem som kan

    uppst r nr metodingenjrerna utformar guidade metoder fr ett fordon som nnu inte har

    tillverkats. Med andra ord finns inget fordon fr att testa guidade metoden mot. Av dessa skl r

    det inte lmpligt att anvnda fordonet fr att testa och studera guidade metoder.

    Bild 1.8 Olika stt att testa ett system

    Man kan underska och testa ett system med hjlp av en modell av det faktiska systemet.

    Modellen kan vara fysisk eller matematisk.11

    Fr att testa SDP3 anvnder man sig av testriggar

    som fysiska modeller i Scania. Man kan stta ihop ett antal styrenheter p varje testrigg.

    Drefter kan man testa styrenheters vrde och kontrollera om kommunikationen fungerar.

    Frgan r om man kan anvnda sig av dessa testriggar i SDP3 Production Tool fr att testa om

    guidade metodernas struktur r korrekt och rtt steg i en guidad metod visas fr anvndaren

    under ett villkor.

    10

    Det kan vara s att metodingenjren behver resa till fordonet eller att fordonet mste st stilla och inte

    anvndas medan guidade metoder testas.

    11 I [Law 2000, s.4] har ordet matematisk anvnts som motsatsen till fysisk. Dock passar ordet virtuell

    kanske bttre n matematisk. I mnga fall kan modellen vara ett program. ven om man kan pst 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 anvnda testriggar fr test av villkor i guidade metoder medfr samma problem som finns

    om man anvnder det faktiska systemet fr test av villkor. Det hnder att metodingenjrerna

    utformar en guidad metod fr ett fordon som inte har tillverkats n och drmed finns ingen

    testrigg fr. Utver det finns andra nackdelar med att anvnda testriggar fr test av villkor. En

    nackdel r att man inte kan genomfra alla tester som behvs. T.ex. om en guidad metod r

    beroende av motorns varvtal eller bromssystemet kan testriggarna inte erbjuda anvndbara tester

    fr den. Ett annat problem r att man mste verfra en stor del av SDP3-programkoden till

    SDP3 Production Tool. Nmligen den delen av programkoden som anvnds fr kommunikation

    med CAN och anslutning mot styrenheter. Att verfra koden krver mycket arbete och utver

    det kommer SDP3 Production Tool i s fall att f mycket mer programkod och drmed blir

    underhllet allt svrare. Nackdelarna med att anvnda testriggarna gr att fysiska modeller inte

    r lmpliga till test av guidade metoder i SDP3 Production Tool.

    Bortsett frn att anvnda fysiska modeller kan man anvnda virtuella modeller fr att

    mjliggra 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 vrlden med tiden. Simulering kan ske

    manuellt eller med hjlp av dator. Oavsett hur simulering sker omfattar den framstllning 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

    hjlp av en simuleringsmodell. Modellen r ofta baserad p en mngd antaganden om hur

    systemet fungerar. Dessa antaganden uttrycks i matematiska, logiska och symboliska relationer

    ([BANKS 2009, s.3]). Simulering anvnds fr att studera komplexa system. Nr modellen r

    enklare, s att man kan anvnda papper och penna eller enklare datorprogram, kan man kalla det

    en analytisk lsning [Law 2000, s.5].

    Att utveckla ett program som simulerar fordonets beteende fr ndamlet att testa guidade

    metoder r inte prisvrt. 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 (ssom motor och

    bromssystem) r ett stort projekt och tar kanske ngra r att utveckla. Law och Kelton i [Law

    2000, s.5] skriver att om det finns en analytisk lsning fr en matematisk modell och om den r

    effektiv r det bttre att studera modellen med hjlp av den istllet fr simulering. Ett likartat

    resonemang kommer i [BANKS 2009, s.3]. Dr under rubriken Nr simulering inte r lmplig

    str det att som frsta regel br man undvika simulering nr man kan lsa problemet med sunt

    frnuft. Drfr kommer inte ett simuleringsprogram att tas upp som ett alternativ i rapporten

    och det som strvas efter r att framstlla en analytisk lsning.12

    I SDP3 har man mjligheten att spara fordonets status som gonblicksbilder i textfiler som

    kallas fr demofiler (Fr att sedan kra SDP3 i demolge). Ett tnkbart alternativ r att testa

    guidade metoder mot dessa demofiler. Ett problem som dyker upp i det hr fallet r att man inte

    kan testa parameterfrndringarna i guidade metoder. Med andra ord behver man

    implementera ett stt att testa guidade metoder som r beroende av variabler eller parametrar

    vars vrde ndras under krningen. T.ex. i gonblicksbilden som man testar en guidad metod

    mot str att motorns varvtal r normalt men man vill ven testa vad som kan hnda vid

    12

    Simulering r ett uttryck som anvnts med bred betydelse och man kan diskutera om det som har

    kallats simulering inte r en analytisk lsning i sjlva verket eller tvrtom. Jag fredrog att undvika att

    anvnda ordet simulering i rapportens titel samt att kalla den lsning som framfrs fr simulering.

    Anledningen var att inte missleda de som letar efter de knda simuleringsmetoder som Disceret Event

    Simulation och s vidare.

  • Inledning

    15

    maximalt varvtal. Det r klart att det inte r mjligt att skapa gonblicksbilder fr alla

    situationer och vxla mellan olika gonblicksbilder nr man testar en guidad metod. Utver det

    har anvndandet av demofiler samma problem som anvndandet av testriggar. Man mste

    verfra en stor del av SDP3-programkoden till SDP3 Production Tool. Programmet frhller

    sig till fordon, testrigg eller demofil p samma stt och man mste implementera programkod

    fr kommunikation med CAN och anslutning till styrenheter hursomhelst. Detta r dyrt, krver

    mycket arbete och strider mot att SDP3 Production Tool var tnkt som ett verktyg som skapar

    underlag fr SDP3-utgvor och inte som en del av det eller ett separat program med liknande

    funktionalitet.

    Mot den bakgrunden vill man ha en lmpligare och enklare analytisk lsning fr att kunna testa

    guidade metoders korrekthet under olika omstndigheter. Den grafiska editorn i SDP3 PT kan

    rknas som en analytisk lsning men som sagt ger den ingen mjlighet fr att testa villkoren. P

    grund av detta behver metodingenjrerna en utvecklad version av den grafiska editorn som ger

    mjligheten att testa och analysera villkoren i guidade metoder. Denna uppgift kan delas upp i

    tv delar. Fr det frsta behver metodingenjrerna kunna mata in vrden av de variabler som

    finns inom villkoren under ett steg som de vill granska och fr det andra mste de kunna se

    resultatet av villkorsevalueringen. P s stt kan de analysera villkoren.

    Examensarbetets ndaml har varit att hitta en lsning fr att uppfylla kraven till villkorsanalys.

    I denna rapport ska jag presentera en analytisk lsning via ett mjukvaruverktyg efter en kort

    genomgng av ndvndiga frkunskaper. Med hjlp av detta verktyg kan metodingenjrerna

    mata in vrden 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 fr

    anvndaren.

  • Frkunskaper

    16

    2. Frkunskaper Fr att frst hur data och information behandlas behver man knna till XML och

    XSLT. En kort presentation av dessa kommer inom det hr kapitlet.

    Programmeringssprket som anvnds r Java och utvecklingsmiljn r Eclipse.

    Fr att frst utvecklingsprocessen fr examensarbetet mste man vara bekant med en del

    tekniker och kunskaper. Man kan betrakta varje datorprogram som en mngd instruktioner som

    ges till datorn. Dessa instruktioner kommer att tillmpas p en mngd information. Fr att dessa

    frverkligas br:

    informationen kunna anges i programmet i ett lmpligt format,

    man ha ett sprk fr att skriva instruktioner med,

    en milj eller ett verktyg finnas som instruktionsskrivande sker i och ven ger mjligheter fr att frenkla skrivfrloppet.

    Med detta synstt kan man dela in de kunskaper som behvs fr att utveckla ett datorprogram i

    tre delar. Nmligen databehandling, programmeringssprk och utvecklingsmilj. I SDP3 PT r

    guidade metoder en del av programmets datamngd. Guidade metoder anvnds ven som data i

    examensarbetet. Det format som Guidade metoder skapas enligt det r XML (Extensible

    Markup Language). Drfr br man knna till XML och relaterade kunskaper i samband med

    examensarbetet. I nsta avsnitt presenteras XML och ngra relaterade begrepp kortfattat.

    SDP3 PT har implementerats med Java programmeringssprk och Java anvnds ven i

    examensarbetet. SDP3 PT har implementerats som ett Eclipse-tillgg. 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

    programmeringssprk. Vanligen utvidgar ett IDE de mjligheter som finns i en vanlig

    ordbehandlare (Program som anvnds fr att skriva texter) och anpassar dem fr

    programmering. En av de mjligheter som Eclipse ger r att utveckla tillgg (Plugin). Det

    innebr att man kan skriva program som r baserat p Eclipse-milj men med nskad tillagd

    funktionalitet. SDP3 PT har anvnt denna mjlighet. Bekantskap med Eclipse r inte ndvndig

    fr ngon som lser denna rapport och drfr kommer inte i rapporten.

    2.1. XML-vrlden

    Inom datordiskursen kallas den information som anvnds i ett datorprogram fr data. Data har

    en vsentlig roll i datorprogram och drfr har mnga tekniker och teorier, specificerade fr

    datahantering, utvecklats. En av de mest knda r databas. Databaser infrde en metod fr att

    spara och tervinna data effektivt. Databaser anvnder sig av speciella strukturer fr att lagra

    data. Den gngse datastrukturen r tabeller med rader och kolumner. Varje rad har ett unikt flt

    som raden kan identifieras med vars hjlp och kallas fr radnyckel. Man kan komma t data

    lagrade i en viss tabellcell genom cellens kolumnnamn och radnyckeln.

  • Frkunskaper

    17

    Med kningen av antalet program frekom alltmer att man behvde anvnda data producerade

    av ett program i ett annat program. Med Internets tillblivelse finns ett mer lttarbetat stt fr

    olika program att interagera med varandra. Dataverfring mellan olika program r en komplex

    operation och medfr mnga problem. En av orsakerna till dessa problem r att olika program

    tolkar data p olika stt och anvnder olika format. XML (eXtensible Markup Language) r ett

    mrksprk med vars mrkord (taggar) i ett datadokument (textdokument) olika program kan

    tolka dokumentet p ett enhlligt stt. P s stt sker dataverfringen mellan olika program

    enklare och tillfrlitligare. Kort sagt r XML ett standardformat fr representation och utvxling

    av textdata.

    XML hrstammar frn SGML (Standard Generalized Markup Language). SGML uppfanns p

    IBM under 1970-talet och utvecklades i flera r av utvecklare runt vrlden tills det

    presenterades som ISO-standard (International Organization for Standardization) 1986. SGML:s

    strsta succ var HTML (HyperText Markup Language) vilket anvnds som ett standardformat

    fr framstllning av hemsidor p internet. Problemet med SGML r att det r mycket

    komplicerat. SGML-specifikationen r mer n 150 sidor och omfattar mnga speciella fall. Det

    r s komplicerat att inget program har implementerat det fullkomligt. r 1996 brjade Jon

    Bosak, Tim Bray, Michael Sperberg-McQueen, James Clark och ngra andra samarbeta fr att

    skapa ett litet SGML som behll de befintliga mjligheter samtidigt som det skar bort de

    verfldiga 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 anvnder ngon form av grnstecken eller etikett kan ett program inte

    skilja en del av text frn andra delar. XML:s markeringar delar in ett textdokument i separata

    informationsbehllare som kallas nod. Noder frseglar information, etiketterar det och formar

    ett paket som sedan kan bearbetas av datorprogram. En nod som innehller andra noder kallas

    fr element. Ett element kan placeras inuti ett annat element precis som paketen som kan

    innehlla andra paket. Ett sdant element kallas fr barnelement och det elementet som

    innehller det kallas fr frlderelement. Ett element kan innehlla mnga andra element som i

    sin tur innehller andra element och s vidare tills man kommer t rdata (texten)13

    . Detta skapar

    en hierarkisk struktur som bevarar en del stdinformation utver sjlva rdata. Stdinformation

    som sekvens, gande, position, beskrivning och frbindelse. Varje XML-dokument bestr av ett

    yttersta element som kallas rotelement och omfattar alla andra element. [Ray 2003, s.2]

    Man kan sga att ett element r data omslutet av mrkord. Man skiljer mrkord frn data med

    hjlp av vinkelparenteser < > och en sdan symbol tillsammans med respektive mrkord heter

    tagg. T.ex. mrker man ut en adress i texten med att lgga till taggen i brjan av data.

    Fr att utmrka slutet av ett element, anvnder man samma tagg som man brjade elementet

    med. Skillnaden r att man anvnder snedstreck innan mrkordet. T.ex. .

    Nedan kan man se ett exempel p adresselementet:

    Norra Bantorget 14

    17321

    Stockholm

    13

    Text i XML rknas ocks som XML-noder. Text som ligger inuti ett XML-element kallas fr en

    textnod.

  • Frkunskaper

    18

    Som framgr av exemplet innehller elementet adress andra element som trappa, postkod

    och postort. Ett element kan innehlla text, andra noder av olika typer som element,

    kommentarer, texter eller det kan vara tomt. Ett tomt element innehller inga data och mrks ut

    endast med en tagg. Man mste lgga till ett snedstreck efter mrkordet fr att ange att

    elementet r tomt. T.ex. i exemplet ovanfr. Man kan lgga till extra information till

    varje element med hjlp av attribut. Ett attribut definierar en egenskap hos ett element genom att

    frknippa ett vrde till ett namn efter mrkordet i starttaggen. T.ex. . P

    s stt kan man specificera att adressen tillhr ett fretag. Attributnamnet kommer frst.

    Drefter kommer likhetstecken = och till slut kommer vrdet omringat av citattecken.

    XML accepterades som gngse standard inom datorvrlden snabbt och mnga applikationer och

    tekniker utvecklades fr att kunna arbeta effektivt med XML-dokument. I fortsttning av detta

    avsnitt kommer en kort presentation av de som r mest relaterade till examensarbetet, Nmligen

    XML-parsning, XSLT och XPath.

    2.1.1. XML-parsning

    XML betraktas frst och frmst som ett dokumentformat. Syftet med XML-dokument r oftast

    att ett datorprogram ska bearbeta dem men de br ven vara vlformade och tydliga s att de

    kan frsts av en mnniska. Man kan skapa ett XML-dokument i ett vanligt ordbehandlar-

    program. Men program som vill lsa och anvnda XML-dokument behandlar dem sllan som

    vanliga textfiler. Ett sdant datorprogram behver kunna tolka olika XML-taggar och element

    som finns i ett XML-dokument. Drfr anvnder sdana program sig ofta av ett externt eller

    inbyggt mjukvaruverktyg som kallas fr XML-parser. XML-parsern r ansvarig fr 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 utfrs av XML-parser kallas fr parsning.

    Som sagt r det inte ovanligt att XML-filerna skapas av mnniskor i vanliga ordbehandlar-

    program. Anvndaren definierar ocks sina egna element och taggar. Dessa kan orsaka mnga

    fel som pverkar parsningen. T.ex. om anvndaren glmmer att stnga en starttagg med en

    sluttagg. Drfr har en mngd regler och restriktioner definierats fr hur man skriver XML-filer.

    Man sger att XML-dokument mste vara vlformade och med det menas att de mste vara

    skrivna enligt dessa regler och restriktioner. En av XML-parserns uppgifter r att kontrollera om

    XML-dokumenten r vlformade. Om parsern mrker att gllande regler och restriktioner inte

    har fljts i dokumentet generar den ett felmeddelande och avslutar parsningen.

    Utver de restriktioner som finns fr vlformade dokument kan anvndaren definiera egna

    restriktioner och regler. Dessa restriktioner anvnds fr att bestmma en syntax fr hur man

    skriver taggar och element och hur olika element frhller sig till varandra. Det finns tv stt att

    bestmma en sdan syntax: via DTD (Document Type Definition) eller via XML-Schema. DTD

    r ett ldre stt att skriva regler fr XML-filer. Numera anvnds ofta XML-Schema som

    erbjuder mer mjligheter. Ett exempel fr en regel i DTD eller XML-Schema kan vara det att ett

    element mste obligatoriskt innehlla ett annat element. T.ex. vill man att alla datum-element

    ska innehlla ett r-element.

    I brjan av varje XML-fil kan man lgga till en speciell tagg fr att utmrka syntaxen (XML-

    schema eller DTD) som dokumentet har skrivits enligt. Denna tagg tillhr de taggar som kallas

  • Frkunskaper

    19

    Processing instruction och r endast till fr att ge information till XML-parser eller andra

    program som lser XML-filen. Processen att kontrollera om ett XML-dokument r rttskriven

    enligt ett XML-Schema eller DTD kallas fr validering. Nu fr tiden har mnga av de XML-

    parser som finns ven fr uppgift att validera XML-dokument. Man kan validera XML-

    dokumenten med hjlp av vanliga webblsare nufrtiden.

    2.1.2. XSLT

    Ett omrde dr XML-filer anvnds flitigt r d man vill verfra data mellan tv olika

    datorprogram. Man lagrar utdata frn ena av datorprogrammet i en XML-fil och anger det som

    indata i det andra programmet. Det kan hnda att man inte kan anvnda utdata som lagrats i

    XML-filer direkt och utdata mste justeras frst eller anpassas fr det program som tar emot det

    som indata. T.ex. bearbetar man information om fretagets produkter i en databas som ett lokalt

    datorprogram tillhandahller. Man vill se en del av informationen p fretagets hemsida via

    webblsare. Det program som hanterar databasen antas kunna exportera databasen i XML-filer

    med taggar fr varje produkt, produktnummer, beskrivning, pris och s vidare. Fr att kunna

    visa dessa XML-filer i en webblsare br de skrivas i HTML- eller XHTML-format (eXtensible

    HyperText Markup Language).

    Behovet att verfra XML-dokument till andra XML-dokument eller till andra dataformat ledde

    till XSLT (eXtensible Stylesheet Language Transformations). XSLT r ett verktyg som

    mjliggr att verfra XML-dokument till andra format. XSLT har utvecklats av W3C (World

    Wide Web Consortium) och r en av dess rekommendationer [Tidwell 2008, s.1].

    Fr att verfra ett XML-dokument med hjlp av XSLT till ett annat format definieras ett antal

    regler som tillmpas p source-dokumentet fr 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 dataverfringen

    med hjlp av XSLT sker. Numera har alla vanligt frekommande programmeringssprk tillgng

    till kodbibliotek som implementerar XSLT-processorer och man kan utfra verfringen via

    programmering. Det finns dock XSLT-processor som kan installeras som ett ensamstende

    program och man kan utfra verfringen utan att behva skriva kod. Ngra av de mest knda

    XSLT-processorer r Xalan, Saxon, Microsoft XSLT Processor, Altova XSLT Engine [Tidwell

    2008, s20-23].

    Figur 2.1- Dataverfring fr XML-filer med XSLT

    XSLT-stilmallar r sjlva i XML-format. Med det menas att XSL r en uppsttning av XML-

    element som med hjlp av dem transformerar XSLT-processorn ett XML-dokument till ett

    annat format. Man kan tnka sig att varje regel i transformationen tillmpas som en

    programmeringsfunktion p en nod eller en nodmngd som frestller funktionsparametrar.

    Dessa funktioner i XSL kallas fr mallar (Templates) och man skriver dem med hjlp av XML-

    elementet . Noden anvnder attributet match fr att verifiera

    XML-fil

    XSLT

    Stylesheet

    XSLT

    Processor

    Transformerad

    XML-fil

    i nytt format

  • Frkunskaper

    20

    vilka noder i klldokumentet mallen tillmpas p. Vanligen brjar man med en mall som

    tillmpas p klldokumentets rotelement. Om man tilldelar match-attributet ett snedstreck

    pvisar man att mallen tillmpas p rotelementet:

    I varje mall kan man skriva text som kommer att publiceras direkt i transformerade dokumentet.

    Man kan anvnda olika XSL-instruktioner i form av XML-element som utgr olika funktioner.

    Inuti varje mall kan man vlja andra mallar som mste tillmpas i ett speciellt lge. Med andra

    ord kan en mall tillmpa andra mallar. Detta sker med hjlp av XML-elementet

    Fr att frtydliga hur mallar fungerar i XSLT anta att XML-elementet nedan ska skrivas i vanlig

    text med hjlp av en XSLT-processor.

    Norra Bantorget 14

    17321

    Stockholm

    Anta att elementet ligger direkt under rotelementet av klldokumentet. Stilmallar som

    kommer nedan kan lagras i ett XSL-dokument fr att transformera elementet till

    vanlig text.

    ,

    I exemplet finns tv mallar. XSLT-processorn tillmpar den frsta mallen nr den parsar

    rotelementet i klldokumentet. Denna mall gr ingenting annat n att tillmpa mallen som

    matchar elementet i klldokumentet. XSLT-processorn vljer alla adresselement i

    klldokumentet och tillmpar den andra mallen, vilken tar elementet som parameter,

    p dem. I vrt fall finns bara ett adresselement som innehller texten Norra Bantorget 14.

  • Frkunskaper

    21

    Frsta raden av andra mallen innehller XSL-instruktionen . Nr XSLT-

    processorn ptrffar elementet vljs den eller de XML-noder som ppekats i

    attributet select och returnerar deras text. Punkten som tilldelats attributet select i frsta

    raden av andra mallen syftar p den nod som just nu mallen tillmpas p. En sdan nod

    benmns fr kontextnod. Med andra ord talar frsta raden av andra mallen om fr XSLT-

    processorn att den ska vlja texten av den nod som mallen tillmpas p. XSLT-processorn

    kommer att publicera texten Norra Bantorget 14 i resultatet.

    Nsta rad av mallen innehller XML-elementet . Nr XSLT-processorn nr 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 . Om man inte

    skriver denna rad i mallen kommer text som skrivs ut eftert direkt efter Norra Bantorget 14

    utan mellanslag.

    Tredje raden av mallen ger instruktionen till XSLT-processorn att texten av trappa-elementet

    mste skrivas ut. Eftersom trappa-elementet r ett tomt element hnder inget. Efter elementet

    finns ett kommatecken. Kommatecknet rknas som text i XSL-mallen och all text

    som finns i en mall kommer att skrivas ut i resultatet utan inga frndringar. Nsta rad i mallen

    innehller igen elementet och leder till att XSLT-processorn lmnar nuvarande raden

    i resultatdokumentet och allt skrivande i fortsttningen sker i en ny rad. Detta hnder p grund

    av att innehller ett nyradtecken. Resten av mallen kommer frst att skriva ut texten

    av postkod-elementet. Sedan kommer XSLT-processorn att vlja en ny rad fr skrivande p

    grund av det andra i mallen. Till slut skrivs ut texten av postort-elementet.

    Resultatet av transformationen r ett dokument som innehller texten:

    Norra Bantorget 14

    17321

    Stockholm

    XSLT kan klara av de mest invecklade transformationerna. XSLT version 2 som r den

    nuvarande aktuella versionen har mnga mjligheter och kan betraktas som ett fullkomligt

    programmeringssprk. De noder som en mall i XSLT ska tillmpas p vljs med hjlp av ett

    srskilt sprk som kallas fr XPath. Med andra ord mste allt som tilldelas attributen i XSL-

    elementen skrivas i XPath-format. Drfr introduceras XPath kort i nsta avsnitt.

    2.1.3. XPath

    XPath kan betraktas som krndelen i XSLT. Det har uppgetts att XPath r den bst knda

    modallogikstillmpningen hittills [Marx 2009, s.112]. Modallogik r samma som frsta

    ordningens logik som har berikats med tv operatorer:

    att visa mjlighet. Fast moderna implementeringar av modallogik har ftt 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 nstan

  • Frkunskaper

    22

    identisk med PDL.14

    Hur som helst betraktas modallogik som ett sprk fr att beskriva

    grafliknande datastrukturer och XPath beskriver syskonordnade trd (Sibling Ordered Trees)

    [Marx 2009, s.112].

    Som sagt r XPath 1.0 ett sprk fr att adressera olika noder i ett XML-dokument. XPath har

    inspirerats av Unix skvgar (Paths). XPath-instruktioner beskriver vgar att resa via ett XML-

    dokument. Med XPath-instruktioner kan man vlja frsta eller sista eller tionde "adress"-noden

    som finns i ett XML-dokument. Det gr att vlja ett fretag-element vars namn-attributet r

    lika med Scania frn ett XML-dokument som innehller information om fretag. Man mste

    komma ihg att XPath anvnds i de XML-dokument som har parsats. Det innebr att man inte

    har tillgng till alla detaljer p samma stt som de finns i det ursprungliga XML-dokumentet.

    XPath betraktar XML-dokumentet som ett trd av noder. Det finns olika typer av noder i XPath

    [Tidwell 2008, s.46], nmligen:

    Dokumentnod (Varje XML-dokument har bara en dokumentnod)

    Elementnoder

    Attributnoder

    Textnoder

    Kommentarnoder

    Processing-instruction-noder

    Namnrymdnoder

    Dokumentnod r samma som rotelement som ppekades i brjan av detta avsnitt (se sidan 18).

    Det r en nod som omfattar alla andra noder och i XPath beskrivs den med hjlp av ett

    snedstreck /. Varje element i XML-dokumentet representeras med en XPath-elementnod. En

    elementnod rknas som frlder av sina attributnoder. Varje textnod innehller texten av

    respektive elementnod. Kommentarer r de noder som bara har vrde men inget namn och

    beskriver de kommentarer som finns i XML-dokumentet. Fr mer information om

    namnrymdnoder och Processing-instruction-noder kan de intresserade titta p de orkneliga

    olika referenser som finns i omrdet bland annat: [Harold 2004], [Ray 2003] och [Tidwell

    2008].

    Fr att blddra igenom de olika noder som finns i ett XML-dokument har ngra axlar definierats

    i XPath. Samma exempel som har anvnts i avsnittet XML och avsnittet XSLT anvnds hr fr

    att f en snabb verblick ver olika navigerings axlar i XPath. (Beskrivning av de olika axlarna

    har gjorts med hjlp av [Tidwell 2008, 62-65])

    Norra Bantorget 14

    17321

    Stockholm

    14

    Maarten Marx i [Marx 2009, s.114] skriver att om man abstraherar bort datainnehllet av XML-

    dokumenten och hller sig till skelettet, det som r kvar r den navigerbara krnan som kallas fr core

    XPath 1.0 och det r core XPath 1.0 som han tycker det r identiskt med PDL.

  • Frkunskaper

    23

    Frsta axeln r barnaxeln som anvnds fr att blddra genom barnnoder av kontextnoden. Fr

    att vlja en barnnod rcker det att skriva dennes namn direkt. I exemplet ovan postkod -noden

    r barnet av adress. I ett XPath-uttryck dr kontextnoden r en adress-nod rcker det att skriva

    postkod. Ett annat stt att n fram barnet r att skriva "child::postkod". P det sttet anges

    konkret att barnet postkod br vljas frn barnaxeln som innehar alla barnen av kontextnoden.

    Den andra axeln r frlderaxeln. Fr att ha tillgng till frldernoden till den aktuella

    kontextnoden kan man anvnda sig av tv punkter och ett snedstreck ../ eller man kan skriva

    parent::adress. Nsta axel r den axeln som ppekar p sjlva kontextnoden. Som sagt (Se

    sidan 20, andra stycket) kan man anvnda sig av en punkt som angetts i exemplet fr XSLT

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

    hjlp av snabel-a som fljs av attributnamnet ("@attributnamn") eller med hjlp av

    attribute:: fljt av attributnamnet. Tv andra axlar som finns anvnds fr att n kontextnodens

    fljande noder eller fregende noder. I XPath anges de tv axlarna som nodnamn med prefixen

    "following::" eller "preceding::". Kontextnodens fljande och fregende noder kan

    specificeras mer via axlarna menade fr fljande syskon eller fregende syskon (preceding-

    sibling:: och following-sibling::). Kontextnodens syskonnoder r de noder som har samma

    frlder som kontextnoden. I exemplet ovan r , och syskon. Man

    kan n kontextnodens barnbarnnoder eller frfadernoder med hjlp av "descendant::" och

    "ancestor::. XPath har ytterligare axlar som inte har kommit med i den hr korta

    presentationen.

    Utver XPath-axlar kan man ange villkor fr att vlja noder i XPath. Villkor skrivs inuti

    hakparenteser. Till exempel om man skriver child::adress[10] innebr det att man vill komma

    fram till tionde adress-noden som r kontextnodens barn. XPath innehller olika operatorer

    ssom relationsoperatorer och logiska operatorer. Det finns en del funktioner ocks som hjlper

    utvecklaren. Funktioner som bestmmer nodernas typ, namn och position eller de funktioner

    som utfr olika operationer p textstrngar r ngra exempel. W3C har en utfrlig specifikation

    fr XPath 15

    dr man kan bekanta sig mer med de mjligheterna som XPath erbjuder.

    15

    http://www.w3.org/TR/xpath/

    http://www.w3.org/TR/xpath/

  • Mjukvaruverktyg fr villkorsanalys

    25

    3. Mjukvaruverktyg fr

    villkorsanalys

    Detta kapitel beskriver det mjukvaruverktyg som jag har utvecklat under

    examensarbetet. Denna mjukvara har skapats med hjlp av Java, HTML, XSLT, Java

    Plugin Technology (Applets) och JavaScript. Uppgiften har delats in i tv delar: att

    skapa det anvndargrnssnitt som mjliggr 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 anvndargrnssnittet har kopplats till

    evalueringsramverket.

    Som nmndes tidigare innehller SDP3 PT en grafisk editor fr att hjlpa metodingenjrerna

    med att analysera guidade metoder (se avsnitt 1.3.). Det som metodingenjrer krver r ett

    verktyg med vars hjlp man kan analysera villkoren i guidade metoder. Detta verktyg br

    kopplas till den ovannmnda grafiska editorn. Att skapa ett fungerande verktyg som har

    integrerats med SDP3 PT skulle skert ta mer arbete och tid n ett normalt examensarbete.

    Drfr har jag avgrnsat uppgiften. Avgrnsningarna kommer att introduceras i frsta avsnittet

    av detta kapitel.

    I avsnitt 1.3. har ppekats 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 hjlp av

    relationsoperatorer jmfrs med konstanta vrden eller med andra variabler. Nr en guidad

    metod tas i bruk i den verkliga miljn (d.v.s. nr en guidad metod visas upp i SDP3) kan dessa

    variablers vrde lsas av en styrenhet eller flera styrenheter eller matas in av anvndaren.

    Variablerna kan ven anvndas fr att spara felkoder skickade av olika fordonsdelar.

    Eftersom SDP3 PT krs utan att datorn kopplas till bilen kan variablerna inte lsas av

    styrenheter eller fordonet i SDP3 PT. andra sidan om man vill testa villkoren br variablernas

    vrde genereras p ngot stt. Ett alternativ r att skapa ett anvndargrnssnitt som

    metodingenjrerna matar in variablernas vrde manuellt i och sedan analyserar resultatet av

    villkorsevalueringen baserat p de inmatade vrdena. Ett sdant anvndargrnssnitt r

    dynamiskt, och frndras med varje steg i en guidad metod. Drfr har jag delat upp uppgiften i

    tv delar. Frsta delen presenterar en lsning fr att skapa ett dynamiskt anvndargrnssnitt som

    mjliggr parameterfrndringen16

    . Andra delen handlar om hur man kan evaluera villkoren. De

    tv delarna kommer att beskrivas utfrligare i det hr kapitlet. Sista avsnittet av det hr kapitlet

    visar hur anvndargrnssnittet kan kopplas till evalueringsramverket.

    16

    Jag har anvnt orden parameter och variabel vxelvis. Drfr att variabler i villkoren i en guidad metod

    kan betraktas som parametrar i ett villkor som deras vrde mste matas in.

  • Mjukvaruverktyg fr villkorsanalys

    26

    3.1. Avgrnsningar

    Jag har valt tv huvudsakliga avgrnsningsomrden som beskrivs nedan:

    1- Jag valde att utveckla ett separat verktyg fr att testa villkoren i guidade metoder. Allts utfrs evalueringen inte i SDP3 PT utan den grs oberoende med hjlp av vilken

    webblsare som helst. Tidskostnaden skulle vara hg om man skulle bekanta sig med

    SDP3 PT-koden och om man skulle vlja rtt stt att integrera evalueringsverktyget

    med grafiska editorn i SDP3 PT. Fast jag har frskt vlja de tekniker som kan

    implementeras i SDP3 PT i framtiden.

    2- Guidade metoder innehller olika typer av villkor i olika delar av XML-filen (Under olika XML-element). Som ppekats tidigare i avsnitt 1.2.2. kan guidade metoderna

    innehlla ett eller flera steg-element. Varje steg kan kopplas till andra steg. Fr

    att koppla ett steg till andra steg anvnder man sig av XML-elementet NstaSteg.

    Varje steg kan innehlla inget eller flera NstaSteg-element. Varje NstaSteg-

    element innehller inget eller hgst ett villkor-element. Villkor-element anvnds i

    andra delar av en guidad metod och inte bara under NstaSteg-elementen.

    Metodingenjrer vill kunna testa de villkoren ocks. Men fr att hinna presentera ett

    frdigt, fungerande verktyg valde jag att bortse frn villkor som inte finns under

    NstaSteg -elementen. Fast samma kod med lite frndring br ven fungera fr

    andra villkor i guidade metoder.

    3.2. Anvndargrnssnitt fr inmatning av

    variablernas vrde

    Ett mjligt anvndargrnssnitt fr inmatning av variablernas vrde br vara dynamiskt. Med det

    menas att samma anvndargrnssnitt inte kan anvndas fr alla guidade metoder eller fr alla

    steg inom en guidad metod. Beroende p den guidade metoden och det steg som

    metodingenjrerna vill granska br man skapa ett nytt anvndargrnssnitt. Detta beror p att ett

    sdant anvndargrnssnitt r knutet till variabler definierade i villkoren. Tre fakta gllande

    variabler gr anvndargrnssnittet dynamiskt:

    Olika steg och olika guidade metoder kan innehlla olika variabler

    Beroende p hur variabler anvnds har de uppdelats i olika typer. T.ex. de kan bekrfta att ett fel har uppsttt eller de kan innehlla en signal mottagen av en styrenhet eller de

    kan spara resultatet av en operation i steget.

    Variablers vrde kan ha olika datatyper. En del kan best av numeriska vrden som i sin tur kan delas till heltal och flyttal, en del kan innehlla textstrngar och det finns

    variabler som kan ta booleska vrden (sann eller falsk).

    Att hantera anvndargrnssnittet dynamiskt r svrare n att skapa ett statisk anvndar-

    grnssnitt. Om man antar att man br ha en textbox fr en variabel i ett steg av en guidad metod

    och i ett annat steg br man ha tio textboxar eller fem kryssrutor eller tre alternativknappar fr

    variablerna frstr man problematiken med att skapa anvndargrnssnittet dynamiskt. I frsta

    avsnittet av det hr kapitlet beskriver jag hur anvndargrnssnittet har skapats. Sedan kommer

    en snabb utvrdering av implementeringsmetoden och till sist presenteras implementeringen

    mer detaljerad.

  • Mjukvaruverktyg fr villkorsanalys

    27

    3.2.1. Logiken i skapandet av anvndargrnssnittet

    Variablerna i villkoren i guidade metoderna har en viktig roll i ett anvndargrnssnitt som ska

    hjlpa till att evaluera guidade metoder. Man kan frknippa varje variabel som uppstr i ett steg

    i en guidad metod med ett element i anvndargrnssnittet. Den enklaste lsningen som kan

    tnkas r att skapa en textbox fr varje variabel med vars hjlp kan metodingenjrerna mata in

    nskat vrde fr variabeln sedan. Detta vrde kommer att anvndas vid evalueringen av

    villkoren i steget.

    En tnkbar frbttring p denna lsning r att frhindra upprepningar av en

    anvndargrnssnittskomponent frknippad med en variabel i villkoren i ett steg av en guidad

    metod. T.ex. anta att det finns en guidad metod som innehller 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 NstaSteg-element. Anta att varje av de tio

    NstaSteg-elementen omfattar ett villkor som i sin tur innehller variabeln x. Baserat p

    olika vrde som x fr kan ngot av dessa steg som r kopplade till step0 bli aktuellt. T.ex.

    om x har vrdet 1 blir steget med namnet step1 aktuellt, om x har vrdet 2 blir steget med

    namnet step5 aktuellt och s vidare. Anta nu att man skapar ett anvndargrnssnitt fr steget

    step0 fr att vrdestta parametrarna i villkoren i de olika NstaSteg-elementen.

    Anvndargrnssnittet skapas s att fr varje variabel i ett villkor skapar man en textbox med

    namnet av variabeln som etikett17

    . Enligt det hr exemplet kommer tio textboxar med etiketten x

    att finnas i anvndargrnssnittet. Dessa olika textboxar kan representeras med en enda textbox

    istllet fr tio. P det sttet blir anvndargrnssnittet mer tydligt och mindre otydlig.

    En annan frbttring som kan gras p en lsning med endast textboxar i anvndargrnssnittet

    r att visa de mjliga vrden som en variabel kan f, och pverkar resultatet av evalueringen av

    villkoren, fr anvndaren i anvndargrnssnittet. I exemplet, som nmndes i frra stycket,

    antogs att variabeln x upprepades i villkoren under olika NstaSteg-elementen som tillhrde

    steget med namnet step0. Om man visar variabeln x som en textbox p anvndar-

    grnssnittet kan anvndaren inte gissa vilket vrde av x leder till att ett villkor under ett

    NstaSteg-element blir sant och drmed vilket steg aktuellt. Anvndaren kommer att vara

    tvungen att kontrollera om och om guidade metoden och villkoren fr att se de vrden som

    spelar in. Fr att underltta test av villkoren kan man visa de konstanta vrden som jmfrs med

    en variabel upp framfr anvndargrnssnittkomponenten som r frknippad till variabeln. Man

    kan visa dem som en lista, eller det som kallas Combobox i programmerares jargong, i fall att

    variabelns datatyp r textstrng. I fall av numeriska datatyper kan dessa konstanta vrden

    skrivas upp direkt framfr anvndargrnssnittkomponenten.

    Som ppekades tidigare finns det olika typer av variabler i villkoren i guidade metoder. En

    variabel sjlv 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 nrmare underskning kan

    man mrka att ngra av dessa variabeltyper kan visas i anvndargrnssnittet med lmpligare

    komponenter n textboxar. T.ex. det finns variabler som innehller resultatet av en operation

    som kan vara lyckat eller misslyckat (OK/FAIL). Ett alternativknapp kan vara en bttre

    komponent fr att presentera sdana variabler i anvndargrnssnittet i jmfrelse med en

    textbox. Ett annat exempel r de variabler som innehller en felkod och r tecken p om ett fel

    17

    Label

  • Mjukvaruverktyg fr villkorsanalys

    28

    har uppsttt eller inte. Sdana variabler kan presenteras bttre med hjlp av kryssrutor n

    textboxar. Drfr att det r ondigt att tvinga anvndarna att skriva en text som beskriver ett fel

    nr man kan vlja det endast med att kryssa en ruta.

    Med dessa antagande har jag frskt hitta rtt mjukvaruteknik fr att skapa det dynamiska

    anvndargrnssnittet. I nsta avsnitt argumenteras fr de tekniker som har anvnts.

    3.2.2. Utvrdering

    Fr att implementera ett dynamiskt anvndargrnssnitt granskades tv huvudsakliga alternativ.

    De r:

    Eftersom SDP3 PT r ett Eclipse-plugin skrivet i Java var det sjlvklara alternativet att skapa anvndargrnssnittet med hjlp av programmeringssprket Java. Man kan parsa

    guidade metoderna, som r i form av XML-filer, med en av de olika kodbibliotek som

    finns fr XML-parsning i Java. Sedan skulle man kunna vlja unika variabler i varje

    steg (Upprepningarna av variablerna i villkoren behver inte vara med). Baserat p

    typen av dessa unika variabler skulle en komponent i anvndargrnssnittet skrivet med

    Java-kodbibliotek skapas.

    HTML anvnds som standard sprk fr att visa information i olika webblsare. HTML har std fr olika anvndargrnssnittkomponenter som med hjlp av dem matar

    anvndarna in information i en webbapplikation. Man anvnder HTML-formulr fr att

    skapa sdana anvndargrnssnittkomponenter. Varje Eclipse-plugin kan anvnda en

    intern webblsare som finns i Eclipse fr att visa lokala HTML-filer eller de som finns

    p en server (En annan dator tillgnad att utfra tjnster fr andra datorer). Det innebr

    att om man skapar anvndargrnssnittet i form av HTML r det mjligt att ven visa det

    med hjlp av den interna webblsaren som finns i SDP3 PT utver de externa

    webblsarna. Fr att skapa anvndargrnssnitt i form av HTML kan man gra en XSL-

    transformation. Anvndandet av XSLT fr att transformera olika XML-filer till HTML

    r vanligt. Ett enkelt exempel r att skriva en mall i XSL med vars hjlp frvandlar man

    varje variabel befunnen i ett villkor till en textbox i en HTML-form.

    Olika alternativ har ofta bda nackdelar och frdelar samtidigt. Nedan jmfrs de tv

    alternativen:

    Anvndargrnssnitt i form av HTML kan visas i olika frdiga webblsare och r inte beroende av miljn. Medan anvndargrnssnitt i form av Java mste visas upp i ett

    Java-program med Java Virtual Machine installerad p datorn. Med andra ord mste

    man skriva ett program fr att visa anvndargrnssnittet.

    XSLT-stilmallar krver mindre kod i jmfrelse med parsning av XML-filer i Java. Fr att utfra det som ett XPath-uttryck med ngra f ord gr behver man ofta skriva ngra

    rader kod i Java.

    Att skapa anvndargrnssnitt med Java krver extra operationer. T.ex. mste man skapa och ppna en fil i Java-kod fr att lsa en guidad metod, man mste anvnda sig av ett

    kodbibliotek fr att parsa XML-filen, man mst skapa ett fnster i anvndargrnssnittet

    som r en Java-klass. Man behver inte tnka p sdana detaljer som r orelaterade till

    anvndargrnssnittet om man anvnder HTML. Man kan sga att man kan ha ett mer

    abstrakt och frfinat MVC (Modell View Controller)-mnster om man anvnder XSLT

    och HTML.

  • Mjukvaruverktyg fr villkorsanalys

    29

    Som nmndes i frra punkten att skapa anvndargrnssnitt i Java behver fler operationer utfras n att skapa anvndargrnssnitt i HTML-format. Fler operationer

    medfr mer potential fr felintrffande.

    Det finns starkare verktyg fr att felska och avlusa Javakod n de verktyg som finns fr att avlusa XSLT-kod.

    Ramverk som evaluerar villkor br skrivas i Java, eftersom SDP3 PT r skrivet i Java. Anvndargrnssnitt som r skrivet i Java r sjlvklart kompatibelt med ett sdant

    ramverk och kan anvndas direkt, medan man behver anvnda sig av speciella tekniker

    fr att koppla ett anvndargrnssnitt i HTML till ett Java-ramverk. Detta r svrare och

    mer invecklat.

    Jag valde att skapa anvndargrnssnittet i form av HTML. Tanken var att kunna utfra ett

    verktyg i ramen av examensarbetet och anvndandet av XSLT bedmde jag krva mindre

    programkod.

    3.2.3. Implementering

    Utver det som nmns i avsnitt 3.2.1 Logiken i skapandet av anvndargrnssnittet lade jag till

    andra mjligheter i de XSLT-stilmallar som jag skrev fr att skapa anvndargrnssnittet i

    HTML-format. Att anvndaren 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 ngot som kan underltta

    analys av villkoren. Drfr implementerade jag anvndargrnssnittet s att namnet av de steg

    som kommer efter det aktuella steget och dess respektive villkor (skriven i form av logiska

    satser) visas fr anvndaren. Utver det finns tv knappar i anvndargrnssnittet fr varje steg i

    en guidad metod, den frsta fr att terstlla anvndar-grnssnittet till det frsta lget, innan

    eventuella inmatningar av anvndare. Den andra knappen anvnds fr att anvndaren ska kunna

    evaluera villkoren. Denna knapp mste kopplas till evalueringsramverket. Nr anvndaren

    trycker p denna knapp evalueras olika villkor beroende p de vrden som har angetts fr

    variablerna och resultatet av evalueringen visas fr anvndaren.

    En annan mjlighet som lades till r lnkad till en special variabeltyp. En av de variabeltyper

    som finns i guidade metoder r frdefinierade variabler. Sdana variabler har ett startvrde

    vilket definieras utanfr steg-element i guidade metoden. Dessa variabler kan anvndas i

    villkoren precis som andra variabler. Med mjligheten att se deras startvrde i

    anvndargrnssnittet kan behovet att kontrollera den guidade metoden efter startvrdet upphra.

    Figur 3.1 indikerar de olika processer som utfrs med hjlp av XSLT-stilmallar som jag har

    skrivit fr att skapa anvndargrnssnittet i form av HTML. Ordningen av ovaler i figuren r inte

    exakt och processerna sker inte stegvis.

  • Mjukvaruverktyg fr villkorsanalys

    30

    Figur 3.1. olika processer som utfrs fr att skapa anvndargrnssnittet i HTML-format med

    hjlp 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 mjligt

    XML-element. Steget kopplas till fyra andra steg via NstaSteg-elementen. Fr att frst hur

    anvndargrnssnittet fr parameterfrndringen kan se ut anvnds phittade steg. Resultatet av

    XSL-transformationen med de stilmallar jag har skrivit som tillmpas p detta steg ser ut som

    figur 3.2.

    Vlj ett Steg

    Skriv namnet av alla

    steg som r Kopplade

    till detta steg -----

    Skriv ut villkoren

    efter namnet

    Fr varje variabel i villkoren

    skapa ett

    Anvndargrnssnittkomponent

    Om variabeln jmfrs med

    konstanta vrde skriv de

    konstanta vrden direkt ut eller

    visa dem i en comboBox

    Om variabeltypen tillhr

    den frdefinierade typen

    visa upp dess startvrde

    Skapa knappar fr

    evaluering av villkor och

    terstllning av grnssnittet

  • Mjukvaruverktyg fr villkorsanalys

    31

    Figur 3.2. Anvndargrnssnitt fr parameterfrndring fr det phittade steget i bilaga B i

    HTML-format skapat av XSL-transformation.

    Som framgr 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 frndrar dem till dessa logiska satser. Efter sista steget kommer

    anvndargrnssnittkomponenter frknippade till variabler som spelar in i villkoren. I det hr

    fallet finns tre variabler i de befintliga villkoren i steget TestSteg, nmligen motorTemperatur,

    motorVarv och oljeNiv. Framfr namnet av varje variabel finns en parentes dr variabeltypen

    str. Som mrks p figuren frekommer variabeln motorTemperatur fyra gnger i villkoren

    under steget men det finns bara en unik anvndargrnssnittkomponent frknippad med

    motorTemperatur.

    Efter anvndargrnssnittkomponenten fr varje variabel (I det hr fallet en textbox fr varje

    variabel) skrivs de konstanta vrde som variabeln jmfrs med. Om variablerna hade textstrng

    som datatypen (oljeNiv i exemplet) kommer en Combobox med olika mjliga vrde fr

    variabeln att finnas framfr textboxen. En annan punkt som br uppmrksammas r det att

    variabeln motorVarv har tv gnger jmfrts med vrdet 2000. Men vrdet 2000 har

    skrivits endast en gng framfr textboxen. Med andra ord upprepas redundanta konstanta vrde

    inte i anvndargrnssnittet.

  • Mjukvaruverktyg fr villkorsanalys

    32

    Fr att implementera transformationen har jag skrivit en XSL-fil runt 450 rader XSL-kod. Jag

    anvnde XSLT version 1.0 eftersom den version av Java-kodbibliotek som anvnds i SDP3 PT

    stder det. Utver det har jag skrivit en CSS-fil fr att hantera HTML:s olika stillar. I

    fortsttningen tillkommer tv vanliga fall som man mste ha hnsyn i samband med XSL-

    transformationer: gruppering i XSLT och anvndande av olika XSLT-processor.

    3.2.3.1. Gruppering i XSLT

    Nr man skriver XSLT-stilmallar vljs den nod eller de noder som mallen mste tillmpas p

    genom attributet match. Ett XPath-uttryck tilldelas attributet. Ofta vill man gruppera de noder

    som en stilmall tillmpas p efter en egenskap hos dem. I brjan av detta avsnitt (3.2.3.) ses att

    variabeln x frekommer fyra gnger i villkoren men man vill ha att det ska finnas bara en

    anvndargrnssnittkomponent fr de olika upprepningarna av x. Med andra ord r det bara de

    unika vrde av x som spelar roll. Med andra ord mste variablerna i villkoren grupperas efter

    variablers namn. Detta r ett exempel av gruppering i XSLT.18

    Gruppering i XSLT version 2.0 grs enkelt och det finns srskilda instruktioner fr det [Tidwell

    2008]. Gruppering i XSLT version 1.0 kan gras men det r inte sjlvklart, med konkreta

    instruktioner. Det finn ngra metoder fr att utfra gruppering i XSLT 1.0 [Tidwell 2008, s221-

    228]. Problemet med att anvnda de metoderna fr mig var det att de exemplen som beskrev de

    metoderna har anvnts i samband med XML-element som lg i samma niv av XML-filens

    hierarki. Men jag behvde gruppera de XML-noder som inte var syskon (De lg inte p samma

    niv av XML-filen). Drfr utvecklade jag en annan lsning med hjlp av rekursiva mallar och

    . Nedan sammanfattas den lsningen.

    Som ppekades i avsnittet 2.1.2 nr man definierar en XSL-mall bestmmer man med attributet

    match de noderna som mallen tillmpas p. I XSLT 1.0 finns ven mjligheten att definiera

    egna stilmallar utan att de behver matcha ett eller flera XML-element i XML-klldokumentet.

    Man kan definiera en mall som inte har attributet match utan attributet name. Sedan kan

    man tillmpa mallen inom en annan mall genom XSL-elementet .

    Koden nedan visar ett exempel p hur man skriver sdana mallar:

    /* Kommentar: Hr behvs bekantskap med xsl:param innan mer frklaring.*/

    18

    De som knner till relationsdatabaser vet att gruppering r viktig i databaser och det utfrs i SQL med

    hjlp av group by uttrycket.

  • Mjukvaruverktyg fr villkorsanalys

    33

    I exemplet finns tv mallar: frsta tillmpas p XML-elementen Steg i klldokumentet, den

    andra har inget match-attribut utan ett name-attribut. Det vill sga att den mallen mste

    anropas inom en annan mall. I det hr fallet anropas den inom frsta mallen. Anropet sker via

    . Man kan skicka vidare en del information eller ett nodset till dessa

    egendefinierade mallar med hjlp av XSL-elementen och .

    Lsningen r baserad p att anvnda en mall liknande den. Denna mall ska f det nodset som

    br bearbetas som parameter. Inom mallen ska de ndvndiga operationerna utfras p det

    frsta elementet i nodsetet. Sedan anropar mallen sig sjlv fast inte med samma nodset som

    parameter. Man tar bort de noderna som r gemensamma med frsta noden i nodsetet och

    anvnder resten som parameter igen. Detta r exakt som att skriva rekursiva funktioner i ett

    vanligt programmeringssprk. Rekursionens basfall hnder nr parametersnodsetet r tomt.

    Nedan finns koden som kan anvndas fr att skriva namnet p unika variabler inom ett steg.

    ,

    Frsta mallen anropar mallen variabelhantering. Mallen variabelhantering tar emot en

    parameter med namnet variabler. Anropet i frsta 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 frsta variabel-noden

    i parametern r en nod. Om svaret r nej d hnder ingenting och mallen lmnas. I annat fall

    definieras frst en XSL-variabel som lagrar namnet av frsta variabel-noden. Sedan skrivs

    detta namn i resultatet. Drefter kommer ett kommatecken och till slut anropas sjlva mallen

    variabelhantering men bara med de noder som inte har samma namn som frsta variabel-

    noden. Det r anmrkningsvrt att nr man refererar till en variabel eller en parameter i XSLT

  • Mjukvaruverktyg fr villkorsanalys

    34

    anvnder man tecknet $ innan parameterns/variabelns namn. Om man tillmpar de tv

    ovannmnda mallarna p det steg som finns i bilaga B, kommer resultatet att se ut som nedan.

    TestSteg

    motorTemperatur, motorVarv, oljeNiv,

    3.2.3.2. Anvndande av olika XSLT-processor

    Som nmndes i avsnitt 2.1.2. finns det mnga 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. Drfr r det viktigt att

    anvnda exakt den XSLT-processorn som slutanvndaren har tillgng till. Ett annat frslag r

    att testa mallarna med hjlp av ngra XSLT-processorer. Jag anvnde XSLT-processorn Xalan

    fr att skriva XSLT-stilmallar. Nr jag frskte ansluta anvndargrnssnittet till

    evalueringsramverket anvnde jag mig av Java:s standard kodbibliotek fr att utfra

    transformationen. Den versionen av Java (Jre 1.6.0_1) anvnde JAXPSAXProcessor som den

    frinstllde XSLT-processorn.

    Transformationen fungerade med Xalan men inte med JAXPSAXProcessor. Det fanns ett

    felmeddelande i tv stilmallar som var avsedda att matcha XML-elementen och . De

    tv stilmallarnas frsta rad var och .

    Som ses skrev jag namnet av XML-elementen och direkt som XPath-uttryck.

    XPath har logiska operatorer som anvnds fr att skriva XPath-villkor. Orden and och or r

    tv av dessa operatorer som anvnds i XPath. XPath-villkor br st inom hakparenteser och en

    XSLT-processor br inte and och or som logiska operatorer utanfr hakparenteser. Xalan

    fungerade s att den tolkade and/or som reserverat ord i XPath nr de var inom

    hakparenteser men JAXPSAXProcessor tolkade de som and/or-operatorer var som helst i

    ett XPath-uttryck. Fr att kringg problemet ndrade jag malldefinitionen p det hr sttet:

    , respektive .

    3.3. Evalueringsramverket

    Evalueringsramverket r den delen av arbetet som har fr uppgift att evaluera villkoren i

    guidade metoder. Tre olika stt fr att implementera ett sdant ramverk har granskats under

    arbetet. I avsnittet Utvrdering kommer de tre stt att presenteras och utvrderas. Sedan

    kommer i avsnittet TDD (Test Driven Development) sttet som ramverket har testats med att

    presenteras. Till slut kommer mer detaljer om implementeringen i sista avsnittet av

    evalueringsramverket.

    3.3.1. Utvrdering

    Tre olika stt fr att implementera ett evalueringsramverk kunde tnkas. Frsta att anvnda ett

    befintligt ramverk som finns i SDP3, andra genom regelbaserad programmering och till slut via

  • Mjukvaruverktyg fr villkorsanalys

    35

    utvecklingen av ett nytt ramverk i Java. Jag valde den sista fr att evaluera villkoren i guidade

    metoder. Nedan kommer en kort presentation och utvrdering av de tre metoderna.

    3.3.1.1. Villkorsramverket i SDP3

    Det r SDP3:s uppgift att visa guidade metoderna fr mekanikern vid felskning. ven om

    guidade metoder under krning av SDP3 lagrats i databasen [Mattsson 2009], och drfr behvs

    ingen XML-parsning, br villkoren evalueras fr att bestmma det aktuella steget. SDP3 har ett

    eget ramverk fr hantering och evaluering av villkoren. Villkorsramverket i SDP3 har skrivits i

    programmeringssprket Visual C++ medan SDP3 PT r skrivet i programmeringssprket Java.

    Villkorsramverket i SDP3 finns som ett DLL (Dynamic-Link Library). Ett DLL r en

    uppsttning av sm program som kan anropas av ett annat program medan det krs p datorn.

    Fr mer information om DLL se [Puntambekar 2008, s.(45)].

    Eftersom ett DLL anropas under krning av ett program och systemet betraktar DLL:et som

    maskinkod kan man anvnda ett DLL via olika programmeringssprk. Java stder DLL-anrop

    genom JNI (Java Native Interface). JNI r sjlv ett ramverk i Java som har utformats s att Java

    kan anvnda programkod som har skrivits i andra sprk n Java. Med hjlp av JNI och

    villkorsramverkets DLL i SDP3 kan man utfra villkorsevalueringen i SDP3 PT. Den mest

    ptagliga frdelen med att anvnda villkorsramverket i SDP3 fr evalueringen av villkoren i

    guidade metoder i SDP3 PT r lttare underhll. Men det finns en anledning som sger emot att

    anvnda evalueringsramverket i SDP3 fr att evaluera villkoren i SDP3 PT. Frst har

    kodbiblioteket som anvnts i SDP3 fr evaluering (villkorsramverket) inte skrivits med hnsyn

    till att det ska anvndas i externa program som SDP3 PT. Det leder till att villkorsramverket i

    SDP3 r beroende av andra delar av SDP3 och om man vill anvnda det br man anvnda andra

    kodbibliotek i SDP3. Kort sagt att anvnda villkorsramverket i SDP3 i sin befintliga form fr att

    evaluera villkoren medfr ondigt komplexitet och extra operationer. Drfr valde jag att inte

    anvnda detta alternativ fr evalueringen.

    3.3.1.2. Regelbaserad programmering

    Regelbaserade system r nrvarande i vetenskap, teknik och vardagliga livet ofta utan att ngon

    mrker deras design eller tnker p deras djupare teori och det hnder att man anvnder dem

    utan att ens tnka p det [LIGZA 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 pfljden P r ansluten till antagandet A. Regelbaserade

    system anvndes ursprungligen i expertsystemsutveckling med anvndande av sprk med hgre

    grad av uttrycksfullhet n satslogik och predikatlogik. [SOTTARA, 2010].

    Huvuddelen av ett regelbaserat system r en regelmotor som evaluerar reglerna. Regelmotorn

    fungerar med hjlp av en del regler som r skrivna i en specifik syntax. Reglerna tillmpas

    sedan p inputdata. Med andra ord tar regelmotorn emot inputdata och en del regler skrivna i en

    syntax frsteligt fr regelmotorn och generar baserad p de bda resultatet. En av de mest

    knda regelmotorerna som kan anvndas i Java r Jess19

    (Java Expert System Shell). Jess r

    skrivet i Java och det r ltt fr applikationer skrivna i Java att Anvnda det [LIGZA 2006,

    S.286]. Det finns mnga Java ramverk och API (Application Programming Interface) fr att

    19

    Fr mer information om Jess: http://www.jessrules.com/

    http://www.jessrules.com/

  • Mjukvaruverktyg fr villkorsanalys

    36

    mjliggra regelbaserade programmering. En av de mest knda r Java Rule Engine API (JSR

    94) 20

    . JSR 94 anvnder Jess som regelmotor och om man vill f i gng det mste man installera

    Jess p datorn. Utver Jess och JSR 94 finns det mnga andra regelmotorer och Java-API som

    mjliggr regelbaserad programmering i Java.

    De flesta regelmotorer accepterar att reglerna skrivs i form av XML-filer. Fast de har sitt

    specifikt format. Med hjlp av XSLT r det mjligt att transformera villkoren i guidade metoder

    till reglerna enligt en regelmotors syntax. Med andra ord kan man med hjlp av en regelmotor,

    ett kodbibliotek i Java som ansluter sig till denna regelmotor och tv XSL-transformationer, ena

    fr att skapa anvndargrnssnittet fr parameterfrndring och den andra fr att skapa reglerna

    fr regelmotorn, utveckla ett verktyg fr test och analys av villkoren i guidade metoder. Ett

    hinder fr att anvnda regelbaserad programmering som ett alternativ fr villkorsevaluering i

    SDP3 PT var behovet till regelmotor. Om man anvnder regelbaserad programmering br man

    anvnda och installera en regelmotor. Jess som r en av de mest knda regelmotorer fr Java fr

    anvndas i akademiskt syfte men r licensierad som kommersiell mjukvara och fick anvndas i

    SDP3 PT endast fr en kort period. De andra regelmotorer i Java behvde mycket forskning

    forskas frst om hur skra och plitliga de var.

    Ett annat problem med att anvnda regelbaserad programmering r att det inte finns ngon

    gemensam standardsyntax fr att skriva regler enligt. Ngra av dessa syntaxer r mer

    begrnsade och ngra kan vara mer kompatibla med villkoren i guidade metoder. Det krvdes

    mycket tid fr att utforska olika regelmotorer som finns och vlja den som passar bst. P grund

    av detta valde jag att utveckla ett eget evalueringsramverk i java istllet fr att utfra det med

    hjlp av regelbaserad programmering.

    3.3.1.3. Evalueringsramverket implementerat i Java

    Eftersom SDP3 PT r skrivet i Java var den sjlvklara lsningen fr att evaluera villkoren i

    guidade metoder det att skriva programkod som hanterar evalueringen i Java. En sdan kod

    mste parsa guidade metoder och lsa villkoren, f variablernas vrde inmatat i

    anvndargrnssnittet av anvndaren och baserade p dem genomfra operationer frknippade

    till relationsoperatorer och logiska operatorer. Jag tnkte skriva ett sdant program i Java inte

    var s komplicerat och tidskrvande i jmfrelse med de tv andra metoderna (Att anvnda

    villkorsramverket i SDP3 och att anvnda regelbaserad programmering). Denna lsning 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 vsentliga delarna i mjukvarutillverkningsprocessen. TDD (Test

    Driven Development) r en av de gngse metoderna nufrtiden och det r ven den metod som

    jag har frskt att anvnda fr test av evalueringsramverket i Java.

    20

    Fr mer information om JSR 94: http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html

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

  • Mjukvaruverktyg fr villkorsanalys

    37

    Grundidn i TDD r att man skriver frst en enkel och lttfrstelig programkod kallad testfall

    som testar en del av mjukvaran som man vill utveckla och sedan skriver man sjlva

    programkoden fr den mjukvarudelen. P det sttet tvingas man att designa smdelar (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 frdel med att skriva tester fr sm enheter av kod r det att de kan betraktas som en

    frklaring om hur programkoden br anvndas. Om man skriver enkla tester kan de till och med

    erstta en del av programkodkommentarer.

    En annan frdel med TDD r att testfallen kan fungera som en garanti att programmet fungerar

    korrekt. Nr ett testfall skrivs och programkoden klarar testfallet tillggs testfallet till de tidigare

    testfallen och tillsammans kan de kras om efter ndringar i koden eller efter nya kodleveranser

    av utvecklare fr att kontrollera systemets status. Fr att effektivisera dessa testfall behver man

    ett verktyg som hjlper till att skriva testfall s att: de ska vara automatiserade (Alla testfallen

    kan kras bara med att trycka p en knapp); resultatet ska vara som en visuell respons med

    beskrivande felmeddelande och till sist mste testfallen kras snabbt. [Steinberg 2004, s.56].

    JUnit r ett verktyg som har utvecklats av Kent Beck och Erich Gamma fr att verkliggra

    dessa behov.

    Fr att testa evalueringsramverket har JUnit anvnts. I bilaga D finns tv av de testfall som har

    utvecklats fr test av programkod i evalueringsramverket. En av dessa fall r att kontrollera om

    tv villkor r likadana. Som sagt innehller villkoren logiska operatorer. Logiska operatorer r

    kommutativa. Det innebr att operandernas ordning inte spelar ngon roll i evaluerings resultat.

    T.ex. (a and b) r lika med (b and a). Villkoren innehller ven relationsoperatorer. Utver =

    (Lika med) r relationsoperatorer inte kommutativa. Men de r speciella nr det handlar om

    satser med relationsoperatorer r lika. T.ex. r (x < 1) samma jmfrelse som (1 > x). Drfr om

    man vill jmfra olika villkor med varandra br man ta hnsyn till dessa speciella fall. I den

    utvecklade koden finns en funktion med namnet equals som utfr jmfrelsen mellan olika

    villkor. Frsta testfall i bilaga D har skrivits fr att testa denna funktion. Andra testfall r menat

    fr sjlva villkorsevaluering. Testfallet testar olika konstruktrer och tv funktioner bda 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

    Fr att kunna ge en verblick ver hur evalueringsramverket har implementerats kommer i detta

    avsnitt frst en presentation av datastrukturer som har anvnts i programmet och sedan beskrivs

    den algoritm som jag har utvecklat fr att evaluera villkoren enligt den.

  • Mjukvaruverktyg fr villkorsanalys

    38

    3.3.3.1. Datastrukturer

    Ett datorprogram kan betraktas som en mngd instruktioner som tillmpas p en mngd

    inputdata och producerar ett resultat i ngon nskad form. Ofta lagras inputdata i en intern

    datastruktur fr att kunna komma t data under krningen av programmet snabbt och effektivt.

    Datastrukturers design r en vsentlig del av mjukvarudesignen. Efter objektorienterad

    programmerings tillblivelse kombineras ofta sdana datastrukturer med de operationer som

    utfrs p dem i moduler som utformar en enhet (namngetts klass) fr programkod.

    Eftersom villkoren i guidade metoder r lagrade i XML-filer br programmet frst parsa XML-

    filerna. Det finns tv allmnt accepterade stt fr parsningen av XML-filer. I ena kan man

    komma t informationen med hjlp av en sekvens av hndelser som skickas frn parsern till

    programmet. Denna typ av parsning anvnds med hjlp av SAX (Simple API for XML). SAX r

    interaktiv. Det innebr att nr 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 hndelse till det. I SAX-parsning br man skapa egen

    datastruktur och spara resultatet av hndelser skickat av parsern i den om man vill behlla

    informationen. [Tidwell 2008, s.15].

    Den andra sorten av parsning r en rekommendation av W3C och anvnder sig av DOM (Data

    Object Model). DOM-parser parsar hela dokumentet och returnerar parsningens resultatet som

    trddatastrukturer21

    . Med andra ord DOM skapar en datastruktur fr hela dokumentet som sedan

    kan man g igenom fr att komma t de delarna som behvs. De knda XML-parsarna

    tillhandahller de bda metoderna. Eftersom guidade metoderna r inte s pass stora att

    effektivitet blir en aktuell frga anvnde jag DOM-strukturen tillsammans med Java:s standard

    API fr XML-bearbetning (javax.xml).22

    Med andra ord kommer resultatet av parsningen av

    guidade metoder i evalueringsramverket att lagras i DOM-strukturen.

    Evalueringsramverket br ta emot tv sorters av inputdata. De frsta r villkoren i guidade

    metoderna och de andra r vrden av variablerna i villkoren i guidade metoder som inmatas av

    anvndaren. En mjlig datastruktur fr att lagra de bda typerna av inputdata r att ha separata

    datastrukturer, ena fr variablernas vrde och den andra fr villkoren. En annan mjlig lsning

    r att spara bda 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 anvndaren vill

    granska i en egendefinierad datastruktur. Nr anvndaren matar in vrden 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 br lagras r variablernas

    vrde. S i designen av datastrukturen kan man lgga till ett flt (lagringsplats) fr varje

    variabel i datastrukturen fr att lagra variabelns vrde som inmatas av anvndaren.

    Att anvnda en lsning med tv separata datastrukturer istllet fr en datastruktur fr bda

    typerna av inputdata r mer effektivt. I bilaga C utvrderas varfr att anvnda tv separata

    datastrukturer ena fr villkor och den andra fr variablernas vrde r mer effektivt n att

    anvnda en gemensam datastruktur fr bda villkoren och variablernas vrde.

    21

    Det finns olika typer av datastruktur som beroende p inputdata anvnds i olika program. En viktig

    frga i val av datastrukturer r sortering och skningens effektivitet. Ngra typer av de mest knda typer

    av datastrukturer r trd, graf, k, lnkade listor m.m.

    22 Detta API anvnder en parser via Java-konfigurationen och det r inte skert om den anvnder en SAX-

    parser eller en DOM-parser fr att skapa en DOM-struktur. Det kan skilja sig frn dator till dator.

  • Mjukvaruverktyg fr villkorsanalys

    39

    Datastrukturen som innehller variablernas vrde behver inte omfatta all information om

    variablerna. Det rcker med att den har ett flt fr variabelnamn och ett flt fr variabelns vrde.

    Variabelnamnet frestller en nyckel (Key) fr variablernas identifiering och drfr br

    variablernas namn vara unika inom villkoren i ett steg. En knd datastruktur fr att lagra key-

    value-information kallas Map och en speciell typ av den kallas HashMap som har anvnts i

    evalueringsramverket fr att lagra variablernas inmatade vrde.

    Egentligen behvs ingen datastruktur fr att lagra villkoren i ett steg fr att utfra

    villkorsevaluering. Anledningen r att villkoren r sparade i XML-filer och fr att evaluera

    villkoren br man parsa dessa XML-filer. Om man anvnder DOM-strukturen fr att lagra

    resultatet av parsningen kan denna struktur anvndas ven fr villkorsevalueringen. Jag valde

    att utveckla evalueringsramverket s att den kan hantera bda fallen: Att anvnda DOM-

    strukturen fr att hmta ut villkoren under evalueringen, och att utveckla en egendefinierad

    datastruktur fr att lagra villkoren innan de evalueras. Anledning var att med en egendefinierad

    datastruktur kunde andra eventuella krav fr villkorshantering uppfyllas enklare. Exempel p

    sdana krav som har implementerats i evalueringsramverket r att skriva villkoren som logiska

    satser istllet fr 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 ngon

    roll i resultatet av operationen frknippad med en operator. Logiska operatorer r kommutativa.

    T.ex. (x 2) = (y>2 and x x).

    Figur 3.3 kan anvndas fr att frst designen av den egendefinierade datastrukturen. Designen

    har gjorts enligt objektorienterad programmering. Figur 3.3 frestller ett diagram som r knd

    som klassdiagram. Klassdiagram r en av de diagram som en standard fr design och

    modellering av mjukvara freslr. Standarden kallas fr UML (Unified Modeling Language).

    Det hr inte till rapportens syfte att presentera konventioner i UML. Men ngra punkter om

    strukturen sjlv tas upp hr fr att strukturen kan frsts lttare:

    Villkoren skapas med hjlp av logiska operatorer och relationsoperatorer. Operanderna i de villkor som innehller logiska operatorer kan innehlla igen logiska operatorer eller

    relationsoperatorer. Det leder till att nr ett villkor innehller en logisk operator kan

    operanderna till den logiska operatorn betraktas sjlva som nya villkor. Drfr kan man

    dela upp villkoren i tv delar: De villkor som sjlv bestr av nya villkor och de som inte

    har andra villkor som operander.

    Som sagt kan varje villkor innehlla logiska operationer. Sdana villkor har kallats fr CompoundCondition i strukturen. Eftersom sdana villkor bestr sjlva av andra

    villkor (Varje Operand i villkoren kan vara en annan logisk operator). Logiska

    operatorer kan innehlla en operand (not operatorn) eller de kan behva tv

    operander. I frsta fallet har de kallats CompoundCondition och i andra fallet har de

    kallats fr BinaryOpCondirion.

    Villkoren kan innehlla relationsoperatorer eller innehlla inga operatorer alls. Om de inte innehller ngon relationsoperator mste de innehlla en variabel med boolesk

    datatyp som dess vrde endast kan vara sant eller falskt. Om den booleska variabeln har

    vrdet sant r villkoret sant och om den har vrdet falskt evalueras villkoret till falskt.

    Fr att frkorta villkoren skriver man variabel-noden med boolesk datatyp utan inga

  • Mjukvaruverktyg fr villkorsanalys

    40

    jmfrelser med vrdet sant eller falskt. Om en variabel-nod med boolesk datatyp finns

    direkt under en villkor-element utan ingen jmfrelse kan man tolka det att den noden

    jmfrs med vrdet sant. Sdana villkor (utan inga operatorer) har kallats fr

    SimpleUnaryConditions. Eftersom de bara bestr av en variabel-nod. Villkoren som

    innehller en relationsoperator behver tv operander och har kallats fr

    SimpleCondition.

    Operander i villkoren som innehller logiska operationer kan betraktas sjlva som nya villkor. Men operander fr villkoren som innehller relationsoperatorer kan endast vara

    variabler eller konstanta vrde. Nr villkoren inte innehar ngon operator alls finns

    endast en variabel inom villkoren som kan betraktas som en operand. Operander fr

    relationsoperator eller i villkor av typen SimpleUnaryConditions har kallats fr

    AtomicOperand. Sdana operander kan vara en variabel eller ett konstant vrde.

    ConditionFactory r den delen av kod som r ansvarig fr att ta emot villkoren i form av XML-element och skapa Condition-datastrukturen.

    ConditionEvaluator r den delen av kod som r ansvarig fr att evaluera villkoren. Den kan evaluera villkoren bde i form av XML-element och i form av Condition-

    datastrukturen.

    Den datastrukturen som innehller variablernas vrde har skapats som en del av ConditionEvaluator och kallats fr variableSet.

    ConditionNodeParser r den delen av kod som r ansvarig fr att blddra genom villkoren i form av XML-element fr att komma t olika barn-element ssom variabler,

    konstanta vrde eller operationer.

  • Mjukvaruverktyg fr villkorsanalys

    41

    Figur 3.3. Klassdiagram fr evalueringsramverket

    3.3.3.2. Evalueringsalgoritmen

    Evalueringsalgoritmen som jag har fr att evaluera villkoren r en rekursiv algoritm. Den kan

    frklaras i de stegen som kommer nedan:

    1) Bestm typen av frsta operatorn i villkoren.

    class ConditionFramwork

    Condition

    + toString() : String

    + getOperator() : Operator

    + setOperator(Operator) : void

    CompoundCondition

    # CompoundCondition()

    + toString() : String

    BinaryOpCondition

    # BinaryOpCondition()

    + toString() : String

    SimpleCondition

    # SimpleCondition()

    + toString() : String

    AtomicOperand

    - dataType: string

    property get

    + getdataType() : string

    property set

    + setdataType(string) : void

    Constant

    - value: String

    + toString() : String

    property get

    + getvalue() : String

    property set

    + setvalue(String) : void

    Variable

    - name: string

    + toString() : String

    property get

    + getname() : string

    property set

    + setname(string) : void

    enumeration

    VariableType

    Attributes

    - StoredVariable

    - DTCVariable

    - ECU_IO

    - Product_IO

    - Step_Result

    - ReadMode

    - Variant

    enumeration

    Operator

    not

    and

    or

    xor

    eq

    neq

    gt

    lt

    geq

    leq

    empty

    ConditionEv aluator

    - variableSet: Map

    ConditionFactory

    - factoryInstance: ConditionFactory

    + getInstance() : ConditionFactory

    + createConditions(NodeList) : ArrayListA

    SimpleUnaryCondition

    # SimpleUnaryCondition()

    + toString() : String

    ConditionNodeParser

    createAtomicOperands(Node node)

    1

    rightOperand

    1

    evaluate(Condition cond)

    createConditon(Node node)

    11

    1 1

    1leftOperand

    1

    1

    leftOperand

    1

    1

    rightOperand

    1

    equals

    equals

    getElementChild(Node conditionNode, int childPos)

  • Mjukvaruverktyg fr villkorsanalys

    42

    2) Om det finns ingen operator och istllet finns en ensamstende variabel hmta ut variabelns vrde frn datastrukturen variableSet och returnera resultatet av

    evalueringen baserat p detta vrde.

    3) Om operatorn r en relationsoperator hmta ut operandernas vrde och jmfr dem med varandra baserad p relationsoperatorn. Resultatet av jmfrelsen returneras som

    evalueringens resultat.

    4) Om operatorn r en logisk operator betrakta operand eller operanderna som nya villkor och utfr evalueringen fr den eller dem och sedan tillmpa den logiska operatorn p

    resultatet av operandernas evaluering. Resultatet av tillmpningen kommer att

    returneras som evaluerings resultat.

    3.4. Kopplingen mellan anvndargrnssnittet

    och evalueringsramverket

    Eftersom anvndargrnssnittet i detta projekt har skapats i form av HTML medan

    programkoden r skriven i Java behvs speciella tekniker fr att kunna anvnda de vrden

    anvndaren matar in i anvndargrnssnittet som parametrar i Javas programmeringssprk. Java

    har frsetts med ngra tekniker fr att hantera sdana fall. Egentligen har en hel separat version

    av Java-sprket utvecklats fr att utveckla webbapplikationer med. Denna version av Java kallas

    fr JavaEE (Java Enterprise Edition). I JavaEE finns ngra olika stt fr att anvnda

    programkod skriven i vanligt Java i webbsidor. Ett hinder fr att inte anvnda tekniker baserade

    p JavaEE var att SDP3 PT r skrivet i vanligt Java vilket r knt som JavaSE (Java Standard

    Edition) och kompatibiliteten mellan JavaEE och JavaSE ska gra SDP3 PT invecklat. Ett annat

    hinder var att fr att kunna anvnda JavaEE br man installera en speciell applikation p datorn

    som kallas fr webbserver. Konfiguration och anslutning till detta serverprogram skulle

    medfra ondig komplexitet, extra arbete och svrare underhll i SDP3 PT. Drfr frkastades

    denna lsning.

    Det finns tv andra knda tekniker fr att ansluta hemsidor till Java-programkod. Ena kallas fr

    Java Web Start och den andra kallas fr Java Plug-in Technology. Java Plug-in

    Technology anvnder Java-klasser kallade fr Applet drfr r det ven knt med namnet

    applet. [Oracle 2006] beskriver skillnaderna mellan de tv teknikerna:

    The two approaches are very similar. The key difference is in the user experience. If

    the Java application/applet needs to interact with a web page and be tightly bound to a

    web browser, then applets may be the solution. On the other hand, if browser

    independence is important, then Java Web Start is the deployment platform of choice.

    There are a number of other differences, but this is the fundamental difference. Java

    Plug-in technology enables users to run Java applets inside a browser. Java Web Start

    enables users to download full-featured applications with any browser. Once they have

    downloaded and launched an application, the browser can be closed, while the

    application continues working. The application does not depend on an open browser to

    function. The browser can be shut down or you can go to a different web page and the

    application will continue running.

  • Mjukvaruverktyg fr villkorsanalys

    43

    Som framgr av texten anvnds Web Start fr att ladda ner applikationer som ska kras

    fristende av webblsaren som innehller den lnk vilken via den har Web Start pbrjats.

    Medan Plug-in Technology ska anvndas nr Java-programmet kommer att interagera med

    webblsaren stndigt.

    Anvndargrnssnittet fr evalueringsramverket r i HTML-format och kan visas i vilken

    webblsare som helst. Nr anvndaren matar in variablernas vrde kommer han/hon att vlja se

    resultatet av evalueringen fr villkoren i samma steg som variablerna str i. Evaluerings begran

    kan genomfras via t.ex. en knapp. Eftert mste variablernas vrde skickas vidare till

    evalueringsramverket vilket kommer att utfra evalueringen. Efter evalueringen mste resultatet

    av evalueringen visas fr anvndaren p ngot stt. Eftersom hela operationen har brjats frn

    webblsaren r det logiskt att visa ven resultatet i samma webblsare. Detta innebr att

    evalueringsramverket mste interagera med webblsaren aktivt. Drfr valde jag att anvnda

    Java-appletar (Java Plug-in Technology) fr kopplingen mellan anvndargrnssnittet och

    evalueringsramverket.

    Java-appletar kan definieras inom en HTML-sida med hjlp av HTML-elementet . Man

    br anvnda JavaScript dock om man vill anvnda en av appletens metoder eller

    medlemsvariabler. JavaScript r ett programmeringssprk som hjlper till att skapa hemsidor

    som innehar komplexa anvndargrnssnitt och/eller r dynamiska. Dynamiska hemsidor r de

    hemsidor vars ingende information frndras med tiden. T.ex. om man vill visa tidpunkt p en

    hemsida, mste den uppdateras stndigt.

    I examensarbetet har JavaScript ven anvnts fr att skapa resultatet av evalueringen i HTML-

    format och visa det fr anvndaren. Figur 3.4 visar hur arbetsfldet ser ut d evalueringen sker.

    Diagrammet har ritats enligt sekvensdiagrams principer. Sekvensdiagram r ett annat diagram

    som UML definierar. Figuren kan frklaras med hjlp av de steg som kommer nedan:

    Metodingenjren (anvndaren) matar in variablernas vrde fr ett steg i en guidad metod som har visats fr honom/henne i webblsaren och sedan anger han eller hon

    kommandon fr att evaluera villkoren i detta steg.

    JavaScript anropas med variablernas vrde och stegets namn som parametrar till anropets parametrar.

    Appleten anropas med variablernas vrde, stegets namn och guidade metodens filnamn som parametrar.

    Appleten parsar den begrde guidade metoden (XML-filen) och hmtar ut de villkor som tillhr det steg som anvndaren vill granska.

    Uthmtade villkoren tillsammans med variablernas vrde skickas vidare till evalueringsramverket fr att villkorsevalueringen ska utfras.

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

    Anvndaren vill granska villkoren fr ett av de steg vars namn har visats som resultatet av evalueringen.

    En anvndargrnssnittkomponent t.ex. en knapp tar emot anvndarens begran om granskning.

  • Mjukvaruverktyg fr villkorsanalys

    44

    Anvndarens begran 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 fr att skapa anvndargrnssnittet fr det steg som anvndaren har valt.

    XSLT-processorn utfr transformationen och ett nytt anvndargrnssnitt i HTML-format skapas.

    Figur 3.4. Sekvensdiagram fr arbetsfldet under villkorsevaluering

    Eftersom ngra olika tekniker har anvnts under hela processen r arbetsfldet relativt

    komplicerat och medfrde svrigheter i programmeringen. En av de svrigheterna var det att

    olika webblsare inte implementerar JavaScript p samma stt. T.ex. skrev jag en funktion i

    JavaScript med namnet evaluate. Koden fungerade i Microsoft:s webblsare (Internet

    Explorer) men inte i Google Chrome och Mozilla Firefox. Till slut frstod jag att det inte gr att

    definiera en funktion med namnet evaluate i de webblsarna. Det fanns ingen dokumentation

    sd Arbetsflde

    MethodIngineer JavaScript JavaApplet

    GUI in

    HTML-format

    XSLT

    EvaluationFramework

    in Java

    testStep

    (variablsValues)

    call(stepName, values)

    call(stepName, fi leName, values)

    selectStepConditions(fi leName,

    stepName)

    evaluate(conditions,

    values

    EvaluationResult()stepNamesforTrueConditions()

    stepNamesforTrueConditions()

    chooseAnotherStep

    (stepName)

    call(stepName)

    call(fi leName, stepName)

    createGUI (fi leName,

    stepName)

    createdGUI()

  • Mjukvaruverktyg fr villkorsanalys

    45

    om det och jag hittade inga referenser som pekar p det.23

    En gissning r att en funktion som

    finns med samma namn och tillhr en av JavScript:s egna objekt (document) gjorde s att en

    kollision i namnrymden hnde och drmed fungerade programkoden inte.

    En annan svrighet som jag rkade fr var att av skerhets skl Java-appletar inte fr komma t

    lokala filer som lagras p datorn. Drfr kunde XSL-transformationen som gjordes via appleten

    inte utfras. I sdana fall kan man anvnda en speciell sort av appletar som kalls fr Trusted

    Applet. En annan lsning fr att kringg detta problem r att ndra Javas

    skerhetspolicykonfiguration. Eftersom Jag upptckte detta problem nr arbetet var nra sitt slut

    anvnde jag denna lsning som kunde utfras 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 frst en sammanfattning av rapporten. Sedan kommer en verblick

    ver fortsatt arbete.

    Denna rapport beskriver en analytisk lsning fr test av villkoren i form av en kombination av

    relationsoperationen och satser i satslogiken. Dessa villkor anvnds inom guidade metoder.

    Guidade metoder r de underlag som utformas p Scania fr att hjlpa mekanikerna vid

    fordonens felskning. Guidade metoder definieras i XML-format. Moderna fordon innehller

    mnga elektroniska styrenheter som krver speciella mjukvaruverktyg fr att felska dem.

    Elektroniska styrenheter r de elektroniska delsystem som anvnds i olika delar av fordon och

    utfr olika uppgifter. En elektronisk styrenhet bestr av en dator, flera mjukvarukomponenter

    som interagerar med generatorer, givare och stlldon.

    Det mjukvaruverktyg som anvnds p Scania fr felskning av fordon heter SDP3. Guidade

    metoder och annan information som anvnds vid felskningen med SDP3 lagras i databaser.

    SDP3 PT r ett internt verktyg p Scania som tar emot guidade metoder och/eller annan

    information och frbereder dem fr att de ska lagras i SDP3:s databas. En av SDP3 PT:s

    anvndare r metodingenjrer. En av metodingenjrernas uppgift r design av guidade metoder.

    Guidade metoder innehller villkor vilka styr fldet i metoden och interaktionen med bde

    mekaniker och fordon. Guidade metoder kan vara komplexa och innehlla mnga villkor.

    Villkoren kan ocks best av komplexa logiska satser. Drfr vill metodingenjrerna testa

    villkorens korrekthet innan metoderna ska tas i bruk.

    Att testa villkoren i guidade metoder under samma omstndigheter som mekanikern utfr (i

    SDP3 kopplat till fordonet) r inte genomfrbart, eftersom det hnder att metodingenjrerna

    utformar guidade metoder fr fordonsmodeller som inte har tillverkats n. Drfr behvs en

    lsning s att man kan testa guidade metoder med hjlp av SDP3 PT medan man skapar dem.

    Examensarbetets syfte r att presentera ett mjukvaruverktyg fr test och evaluering av villkoren

    i guidade metoder.

    Fr att Examensarbetet skulle kunna utfras i ramen fr ett magisterprogram avgrnsades det till

    ett oberoende mjukvaruverktyg och implementerades inte som en del av SDP3 PT. En annan

    avgrnsning var att examensarbetet inte omfattar alla typer av villkor. Villkoren i guidade

    metoderna innehller variabler. En variabel r ett namn som representerar ett vrde som kan

    lsas frn olika styrenheter eller matas in av anvndaren eller produceras i sjlva SDP3

    programmet. Dessa variabler jmfrs med andra variabler eller med konstanta vrden med hjlp

    av relationsoperatorer. Dessa jmfrelser kombineras med hjlp av logiska operatorer och p s

    stt utformas villkoren.

    Ett mjukvaruverktyg som r menat att testa villkoren i guidade metoderna br evaluera dessa

    satser. Fr att evaluera dessa satser br man generera variablernas vrde p ngot stt. Ett stt

    att terskapa variablernas vrde fr villkorsevaluering r att anvndaren matar in dem manuellt

    genom ett anvndargrnssnitt. Det innebr att det mste finnas komponenter p

    anvndargrnssnittet som motsvarar variablerna i villkoren. Nr metodingenjrer 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 anvndargrnssnitt

    och visar det fr anvndaren. Anvndaren matar in variablernas vrde och vljer att evaluera

  • Avslutning

    48

    villkoren. Evalueringen sker och resultatet visas fr anvndaren och drefter kan anvndaren

    analysera om villkoren har utformats korrekt eller inte.

    I detta sammanhang kan ett mjukvaruverktyg fr villkorsanalys uppdelas i tre olika delar. Frsta

    delen r skapandet av det anvndargrnssnitt som anvndaren matar in variablernas vrde

    genom det, andra delen r ett evalueringsramverk som evaluerar villkoren i det steg som dess

    variablers vrde har inmatats och sista delen r det att hur detta anvndargrnssnitt kan kopplas

    till evalueringsramverket.

    Ett anvndargrnssnitt fr inmatning av variablernas vrde r att det r dynamiskt. Det innebr

    att anvndargrnssnittet inte ser likadant ut nr man granskar olika guidade metoder eller nr

    man granskar olika steg i en guidad metod. I rapporten har tv stt fr att skapa ett sdant

    anvndargrnssnitt tagits upp och har jmfrts med varandra. Frsta sttet r att anvnda de

    knda kodbiblioteken i Java-programmeringssprk som anvnds normalt i Java-program fr att

    utveckla anvndargrnssnitt. Det andra sttet r att skapa anvndargrnssnittet med hjlp av

    XSL-transformationer. Till slut har det andra sttet implementerats och presenterats i rapporten.

    Evalueringsramverket kunde ocks implementeras p olika stt. Tre olika stt har presenterats i

    rapporten. I rapporten har de olika stten utvrderats och baserat p utvrderingen har ett stt

    valts fr att implementeras.

    En av de huvudsakliga delarna i varje mjukvara r de datastrukturer som anvnds i den. De

    datastrukturer som har anvnts fr att implementera evalueringsramverket och deras design har

    presenterats i rapporten.

    Eftersom anvndargrnssnittet var i HTML-format och evalueringsramverket implementerades i

    Java behvdes speciella tekniker fr att ansluta de bda till varandra. Den teknik som har

    anvnts i examensarbetet kallas fr Java Plug-in Technology. I denna teknik anvnder man

    Java-klasser som kallas fr appletar. Fr att kunna anvnda appletar fullstndigt behvdes

    programmeringssprket JavaScript ocks. Arbetsfldet och kopplingen mellan

    anvndargrnssnittet och evalueringsramverket har beskrivits mer utfrlig i rapporten.

    I fortsttningen kommer ngra frslag fr fortsatt arbete.

    4.1. Fortsatt arbete

    Som nmndes tidigare har examensarbetet avgrnsats till ett oberoende verktyg som kan

    anvndas via en webblsare. Men metodingenjrerna anvnder SDP3 PT och drfr br denna

    mjukvara integreras med SDP3 PT. Integrationen med SDP3 PT r den viktigaste delen av

    fortsatt arbete. Som nmndes tidigare har mjukvaruverktyget beskrivits i tre delar:

    anvndargrnssnittet, evalueringsramverket och kopplingen mellan de tv. SDP3 PT r skrivet i

    Java och det gr evalueringsramverket det ocks. Drfr kan evalueringsramverket anvndas i

    SDP3 PT utan vidare. Men fr att integrera anvndargrnssnittet med SDP3 och drigenom

    kopplingen mellan anvndargrnssnittet och evalueringsramverket br man ta ytterligare

  • Avslutning

    49

    tgrder. Nedan presenteras fyra olika stt som kan vljas fr att integrera anvndargrnssnittet

    med SDP3 PT.

    1- SDP3 PT har implementerats som Eclipse-tillgg. En av de mjligheterna som Eclipse erbjuder r en intern webblsare. Det innebr att webbsidor kan ppnas direkt inom ett

    Eclipse-tillgg. Eftersom SDP3 PT r ett Eclipse-tillgg har det ocks tillgng till denna

    interna webblsare och man br kunna anvnda denna interna webblsare fr att visa

    evalueringsramverkets anvndargrnssnitt i HTML-format. P det sttet kan man

    anvnda mjukvaruverktyget direkt i SDP3 PT. Men den interna webblsaren i Eclipse r

    begrnsad och ger inte alla mjligheter som de andra webblsarna erbjuder. T.ex. Java

    plug-in Technology (appletar) inte stds av Eclipse:s interna webblsare. Detta leder

    till att man inte kan koppla anvndargrnssnittet i HTML-format med

    evalueringsramverket. Drfr frskte jag hitta en lsning som utesluter appletar och

    anvnder bara JavaScript. Men det visade sig att den interna webblsaren inte stder

    JavaScript fullstndigt heller. Drfr kan den interna webblsaren inte anvndas fr att

    integrera mjukvaruverktyget med SDP3 PT.

    En annan mjlighet som Eclipse erbjuder r att anropa externa mjukvara och verktyg

    inuti Eclipse-milj. Denna mjlighet kallas fr External tools. Det enklaste sttet fr

    att anvnda resultatet av examensarbetet direkt i SDP3 PT utan inga frndringar r

    genom denna mjlighet. Man kan koppla en redan installerad webblsare som ett

    externt verktyg i SDP3 PT. Sedan kan man visa det anvndargrnssnittet som skapas i

    HTML-format av XSLT-processorn via anrop till detta externa verktyg. Frdelen med

    detta stt r enkel implementering. Nackdelen r att anvndaren vxlas stndigt mellan

    olika program och det kan knnas obehaglig.

    2- Det finns ett annat stt att ha anvndargrnssnittet i HTML-format och nd kan anvnda det mjukvaruverktyg som jag har utvecklat under examensarbetet fr

    villkorsanalys. Detta kan gras genom att utveckla en egen webblsare och koppla den

    till en del av anvndargrnssnittet i SDP3 PT. Denna webblsare kan sedan anvndas

    fr att visa anvndargrnssnittet fr inmatning av variablernas vrde i HTML-format. I

    Java finns tv mer knda kodbibliotek fr att utveckla anvndargrnssnitt. Det frsta

    som var Java:s ursprungliga kodbibliotek fr anvndargrnssnittsutveckling kallas fr

    AWT (Abstract Window Toolkit) som uppgraderades till en frfinad version som

    namngetts Swing. Swing och AWT var bda utvecklade av Sun Microsystems. Den

    andra gngse tekniken fr anvndargrnssnitsutveckling 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 utkar SWT med ett knt designmnster kallat MVC (Model

    View Controller) till SWT.

    Med de mjligheterna som Swing erbjuder kan man skapa en webblsare ganska enkelt.

    Detta r nnu enklare med SWT som erbjuder ett speciellt kodbibliotek fr

    utvecklingen av webblsare som ven har std fr appletar. Eftersom Eclipse sjlv och

    drmed Eclipse-tillggen har skapats med SWT och JFace kan SWT anvndas fr att

    skapa en webblsare och integrera den som en del av SDP3 PT fr att visa

    anvndargrnssnittet fr villkorsanalysverktyget i HTML-format.

    3- Denna lsning r baserad p att anvnda anvndargrnssnitt som skapas av Java:s kodbibliotek (T.ex. Swing eller JFace) istllet fr HTML. Fast fr att skapa detta

    anvndargrnssnitt kan man fortfarande anvnda XSL-transformationer. Ett stt r att

    frska skriva transformationers resultat direkt som Java-kod. Ett annat stt r att skapa

  • Avslutning

    50

    XML-kod istllet fr Java-kod och sedan via de mjligheter som Java-kodbibliotek ger

    kan XML-koden frvandlas till Java-kod. I Java-kodbibliotek finns tv klasser fr att

    verstta Java-kod till ett speciellt XML-format och vice versa. Dessa klasser heter

    XMLEncoder och XMLDecoder. XMLEncoder kan anvndas fr att transformera Java-

    kod till det XML-format som definieras enligt strukturen Java Bean Persistance XML

    Schema. XMLDecoder kan anvndas fr att transformera XML-filer i denna format till

    Java-kod. Man kan anvnda XSLT fr att skapa anvndargrnssnittet fr villkorsanalys

    i den XML-format som bestms av Java Bean Persistance XML Schema. Sedan kan

    man anvnda XMLDecoder fr att frvandla resultatet av XSL-transformationer till

    Java-kod som kan kompileras som en del av SDP3 PT.

    4- Den sista lsningen r baserad p att inte anvnda XSL-transformationen fr att skapa anvndargrnssnittet utan att frska skapa anvndargrnssnittet 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 gr fortfarande att anvnda samma logik

    som finns i XSL-transformationer fr att skapa det anvndargrnssnitt som har anvnts i

    examensarbetets genomfring. Denna lsning kan vara mer tidskrvande i jmfrelse

    med de andra men den r simpel att implementera och drfr rekommenderas.

    En annan avgrnsning i examensarbetet handlade om typen av villkoren. Examensarbetet har

    utfrts med avseende p de villkor som ligger under NstaSteg-elementet under ett steg i

    guidade metoderna. Men guidade metoderna innehller andra typer av villkor och i andra

    sammanhang ocks. ven dessa villkor br kunna analyseras med ett verktyg som mjliggr

    villkorsanalys. En typ av villkor som mste tas hnsyn till r stadigvarande villkor som ligger

    direkt under ett steg och inte under NstaSteg-elementet. En annan typ av villkor kallas fr

    globala villkor. Dessa villkor kan refereras i mnga olika guidade metoder och drfr lagras i

    separata filer och inte inuti sjlva guidade metoder. I en guidad metod kan man referera p ett

    sdant villkor. I framtiden mste villkorsanalysverktyget kunna hantera dessa villkor ocks.

    Som nmndes i rapporten har en grafisk editor utvecklats i SDP3 PT fr att visa guidade

    metoderna visuellt. Resultatet av villkorsevaluering kan visas fr anvndaren

    (metodingenjrerna) med hjlp 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. Istllet fr det

    kan man skicka stegets namn till grafiska editorns programkod fr att till exempel ndra frgen

    av de steg som deras villkor har evaluerats till sanna.

  • Litteraturlista

    51

    Litteraturlista

    1991. Scania 100 r. Saab-Scania AB, Scaniadivisionen, Sdertlje. 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 & THORBIRNSON 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.

    KARLBCK, 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.

    LIGZA, ANTONI . 2006. Logical Foundations for Rule-Based Systems.Springer, 2nd Edition,

    3540291172.

    LINDH, BJRN-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 111157.

    ORACLE. 2006. JavaTM Web Start version 1.5.0 - Frequently Asked Questions (FAQ). General

    Questions. Frga sjutton: How does Java Web Start relate to Java Plug-in Technology (applets)?

    [www]. Hmtat frn:

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

    Uppdaterad: March 2006. Hmtat: 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.

    Utgva: 2.2.

    GUGALA, LISA. 2009. Projektdefinition SDP3:s Produktionsmilj (SDP3 PM). Dokumentnamn:

    ProjektDefinition_SDP3_PM. Antal sidor: 28.

    IVENDAL, HANS. 1997. Utredning. Dokumentnamn: UtredningDiagnosTillSESAMM. Utgva: 1.

    Reg-nr: REPMET97001. Antal sidor: 26.

    IVENDAL, HANS. 1998. Scania diagnos programmer 3 (SDP3). Dokumentnamn: SD3_Direktiv.

    Utgva: 1. Reg-nr: REPMET-1998-7. Antal sidor: 7.

    IVENDAL, HANS. 2000. Project definition SDP3Scania Diagnos Programmer 3. Dokumentnamn:

    PDF_SDP3. Utgva: P1L. Reg-nr: REPMET-1999-1. Antal sidor: 21.

    JOHANSSON, GRAN. 2006. Projektdirektiv, produktionsmilj SDP3. Dokumentnamn:

    Projektdirektiv PM. Utgva: 1. Antal Sidor: 8.

    MATTSSON, JAN. 2009. Detaljbeskrivning av komponent ConditionFramework. Dokumentnamn:

    ConditionFrameworkDescription. Utgva: P3A. Antal Sidor: 7.

    WEILAND, ULF. 2005. Uppgiftsbeskrivning Frstudie: hantering av konstruktionsunderlag.

    Dokumentnamn: uppgift_konstruktionsunderlag. Utgva: 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 frestller de tre frsta stegen i en guidad metod. Metoden r av typen user

    function fr att kontrollera motorn (Engine Control). Frsta steget kopplas direkt till andra

    steget och inga villkor finns fr 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

    TestSteg StopSteg motorTemperatur typ1 heltal 120 heltal gulVarningsSteg motorVarv typ1 heltal 2000 heltal motorTemperatur typ1 flyttal 80 flyttal rdVarningSteg motorVarv typ1 heltal

  • Bilaga B: Exempel p villkor i ett steg

    56

    3000 heltal motorTemperatur typ1 flyttal 90 flyttal lg text oljeNiv typ2 text normalLgeSteg normal text oljeNiv typ2 text 2000 heltal motorVarv typ1 heltal 70 flyttal motorTemperatur

  • Bilaga B: Exempel p villkor i ett steg

    57

    typ1 flyttal

  • Bilaga C: Utvrdering av olika typer av datastrukturer fr villkoren

    59

    Bilaga C: Utvrdering av olika

    typer av Datastrukturer fr

    villkoren Evalueringsramverket br ta emot tv sorters av inputdata. De frsta r villkoren i guidade

    metoderna och de andra r vrden av variablerna i villkoren i guidade metoder som inmatas av

    anvndaren. En mjlig datastruktur fr att lagra de bda typerna av inputdata r att ha separata

    datastrukturer, ena fr variablernas vrde och den andra fr villkoren. En annan mjlig lsning

    r att spara bda 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 anvndaren vill

    granska i en egendefinierad datastruktur. Nr anvndaren matar in vrden av variablerna i

    samma steg lagras de i samma datastruktur som villkoren har sparats tidigare. Eftersom

    variabelnamnen finns redan i villkoren r variablernas vrde den enda information som br

    lagras. I designen av datastrukturen kan man lgga till ett flt (lagringsplats) fr varje variabel i

    datastrukturen fr att lagra variabelns vrde som inmatas av anvndaren.

    Att anvnda tv separata datastrukturer istllet fr en datastruktur fr bda villkoren och

    variablernas vrde r mer effektivt. Fr att detta frklaras bttre anta att datastrukturen som

    skapats fr att spara bda villkoren och variablernas vrde fr ett steg i en guidad metod bestr

    av n noder och i det steget finns m olika variabler. Man kan mta tidseffektivitetet med

    hjlp av antalet skningar i datastrukturen. I det hr fallet:

    Antalet skningar i datastrukturen = Antalet skningar nr variablerna vrdesttas + antalet

    skningar nr villkoren evalueras

    Om man anvnder bara en datastruktur behver ingen skning ske under villkorsevaluering

    eftersom variablernas vrde sparas i samma nod av datastruktur som deras namn finns. Det

    innebr att:

    Antalet skningar i lsning med en datastruktur = Antalet skningar nr variablerna

    vrdesttas

    Varje gng en variabel vrdesttas mste alla n noderna kontrolleras om de innehller den

    variabeln som dess vrde har inmatats. Det br uppmrksammas att m r antalet unika

    variabler och upprepningarna av variabler har ignorerats. T.ex. om variabeln X har upprepats

    i ett villkor tv gnger har det antagits att X vrdesttas i bda flt under en skning. Eftersom

    det finns m variabler r antalet skningar under variablernas vrdesttning lika med (m n).

    Det innebr att:

    Antalet skningar i lsning med en datastruktur = nm

    n = Antalet noder i den gemensamma datastrukturen fr bda villkoren och variablernas vrde

    m= antalet variabler i villkoren i steget

  • Bilaga C: Utvrdering av olika typer av datastrukturer fr villkoren

    60

    Nu anta att vi ska anvnda tv separata datastrukturer fr att spara variablernas vrde respektive

    villkoren fr att evaluera villkoren i samma steg som exemplet ovan. Eftersom det finns en

    separat datastruktur fr att lagra variablernas vrde i behvs ingen skning nr variablerna

    vrdesttas. Om man anvnder en HashMap som datastruktur fr variablernas vrde

    (Variabelnamn som Key och variabelns vrde som Value) lgger man bara en nod till

    mappen. Det innebr att:

    Antalet skningar i lsning med tv separata datastrukturer= antalet skningar under

    villkorens evaluering

    Datastrukturen som innehller variablernas vrde har m noder (lika med antalet variablerna).

    Datastrukturen som innehller villkoren kan i vrsta fall ha n noder lika som den datastruktur

    som kan innehlla bda variablernas vrde och villkoren i frra lsningen. I sjlva verket r den

    lite mindre p grund av att det inte finns ngon lagringsplats fr variablernas vrde (De lagras ju

    i en annan datastruktur). Nr evalueringen sker br programmet leta efter vrdet av en variabel

    varje gng det kommer t namnet av en variabel i ett villkor. Anta att:

    1k = Antalet gnger som frsta variabeln har upprepats i villkoren

    2k = Antalet gnger som andra variabeln har upprepats i villkoren

    mk = Antalet gnger som andra variabeln har upprepats i villkoren

    Och

    mkkkk ...21

    Varje gng som ett variabelnamn dyker upp i ett villkor mste en skning i datastrukturen fr

    variablernas vrde ske fr att hmta ut variabelns vrde. Drfr gller ekvationen nedan:

    Antalet skningar i lsning med tv separata datastrukturer = mk

    m= antalet variabler i villkoren i steget

    k = Antalet gnger alla m variablerna har upprepats i villkoren

    Som sagt den datastrukturen som anvnds fr att lagra villkoren i kan ha i vrsta fall n noder

    lika som lsningen med en datastruktur. Drfr att denna datastruktur r samma som anvnds i

    frsta lsningen fr att lagra villkoren och variablernas vrde bda med enda skillnaden att den

    utesluter variablernas vrde. Eftersom villkoren vanligen innehller olika noder som konstanta

    vrde och noder fr olika typer av operatorer (relationsoperatorer och logiska operatorer) utver

    variabel-noderna (Sdana noder mste innehlla variabelns namn, variabelns typ m.m.) kan man

    pst att antalet gnger som variablerna upprepas i villkoren r mindre eller lika med antalet alla

    noder som finns fr att spara villkoren. Det innebr att:

    nk

    Som resulterar i: )()( mnmk

    n = Antalet noder i den gemensamma datastrukturen fr bda villkoren och variablernas vrde

    m= antalet variabel i villkoren i steget

    k = Antalet gnger alla m variablerna har upprepats i villkoren

    Som innebr:

    Antalet skningar i lsning med en datastruktur Antalet skningar i lsning med tv separata datastrukturer

  • Bilaga D: Testfall i JUnit

    61

    Bilaga D: Testfall i JUnit

    1- Testfall fr 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 conds;

    @Before

    /**

    * setUp () have been used to prepare data structure before testing

  • Bilaga D: Testfall i JUnit

    62

    * equals-function. For this purpose it should parse a guided method

    * named ConditionEqualTestxml. This Guided method contains a step

    * named step0 connected to other steps as below:

    * 1 - Step1

    * ( x >= 1 )

    * 2 - Step2

    * ( x >= 1 )

    * 3 - Step3 (x in this step is not the same x used in step1 because it

    * has different type)

    * ( 1 = 1 ) )

    * 5 - Step5

    * ( ( x >= 1 ) and ( y < 1 ) )

    * 6 - Step6

    * ( ( 1 > y ) and ( 1 y ) and ( 1 y ) and ( 1 y ) and ( 1

  • Bilaga D: Testfall i JUnit

    63

    }

    }

    @After

    /**

    * clearing conds ArrayList after running test

    */

    public void tearDown() throws Exception {

    this.conds.clear();

    }

    @Test

    public void testEquals() {

    /*Test equality for (x >=1) and (x >= 1) when

    the second x has another variable type or data type

    The answer should be false*/

    assertTrue("Equality test for (x >=1) and (x >= 1) with " +

    "diffrent variable types doesn't pass!",

    !this.conds.get(0).equals(this.conds.get(1)));

    /*Test equality for ((x >=1) && (y y ) && (1< = x))

    * the answer should be true*/

    assertTrue("Equality test for ((y=1)) and " +

    "((x >=1) && (y

  • Bilaga D: Testfall i JUnit

    64

    *

    *@description This Class is developed to test the ConditionEvaluator.

    *ConditionEvaluator has four different constructors which works with

    *different parameters. they have been tested. ConditionEvalutor

    *contains two method for evaluating conditions: The first one uses

    *a condition data structure as a parameter and the second one is

    *working on condition as parsed XML-nodes.

    */

    public class ConditionEvaluatorTest {

    //to save Variables name and theirs value

    private String x, y, z, xValue, yValue, zValue;

    // To save all the steps in a guided method with their conditions

    private Map steps;

    // the name of inputed guided method

    private String inputFileName = "ConditionEqualTest.xml";

    // Array to save the condition as XML-nodes

    ArrayList 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 = 1 ) )

    * 5 - Step5

    * ( ( x >= 1 ) and ( y < 1 ) )

    * 6 - Step6

    * ( ( 1 > y ) and ( 1 y ) and ( 1 y ) and ( 1 y ) and ( 1

  • Bilaga D: Testfall i JUnit

    65

    String stepName;

    Condition stepCondition;

    this.steps = new HashMap();

    DocumentBuilderFactory docFactory =

    DocumentBuilderFactory.newInstance();

    DocumentBuilder docBuilder = null;

    Document doc = null;

    NodeList nextStepNodes = null;

    ConditionFactory condFactory;

    try {

    docBuilder = docFactory.newDocumentBuilder();

    } catch (ParserConfigurationException e1) {

    System.exit(1);

    }

    // changing destination file to a DOM Document

    //for adding extra header tags

    InputStream inputGuide =

    ConditionTest.class.getResourceAsStream(this.inputFileName);

    try {

    if (docBuilder != null )

    doc = docBuilder.parse(inputGuide);

    } catch (Exception e) {

    throw e;

    }

    if (doc!= null) {

    nextStepNodes = doc.getElementsByTagName("NextStep");

    }

    condFactory = ConditionFactory.getInstance();

    if (nextStepNodes != null) {

    this.conditionNodes = new ArrayList(nextStepNodes.

    getLength());

    for (int i = 0; i < nextStepNodes .getLength(); i++)

    {

    stepName =

    ((Element) nextStepNodes.item(i)).

    getElementsByTagName("Step").item(0).

    getTextContent();

    stepCondition = condFactory.createCondition

    (((Element)nextStepNodes.item(i)).

    getElementsByTagName("Condition").item(0));

    this.conditionNodes.add(((Element)nextStepNodes.item(i))

    .getElementsByTagName(Messages.Condition).

    item(0));

    this.steps.put( stepName, stepCondition);

    }

    }

    }

    @After

    /**

    * clearing conds ArrayList after running test

    */

    public void tearDown() throws Exception {

    this.conditionNodes.clear();

    this.steps.clear();

    }

  • Bilaga D: Testfall i JUnit

    66

    @Test

    /**

    * test ConditionEvaluator constructor with Map

    */

    public void testConditionEvaluatorMapOfStringString() {

    Map tmpMap = new HashMap();

    tmpMap.put(this.x, this.xValue);

    tmpMap.put(this.y, this.yValue);

    tmpMap.put(this.z, this.zValue);

    ConditionEvaluator ce = new ConditionEvaluator(tmpMap);

    assert ce.getVariableSet().toString().equals("{z=3, y=2, x=1}")

    : "Fault: The Constructor With a map as param";

    tmpMap.put(this.x, this.zValue);

    ce = null;

    ce = new ConditionEvaluator(tmpMap);

    assertTrue ( "Fault: The Constructor With a map as param",

    ce.getVariableSet().toString().

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

    }

    @Test

    /**

    * test ConditionEvaluator constructor with String []

    */

    public void testConditionEvaluatorStringArray() {

    String [] tmpArr = new String[11];

    tmpArr[0] = this.x;

    tmpArr[1] = this.xValue;

    tmpArr[2] = this.y;

    tmpArr[3] = this.yValue;

    tmpArr[4] = this.z;

    tmpArr[5] = this.zValue;

    tmpArr[6] = this.z;

    tmpArr[7] = this.xValue;

    tmpArr[8] = this.y;

    tmpArr[9] = "3"; //$NON-NLS-1$

    ConditionEvaluator ce;

    try {

    ce = new ConditionEvaluator(tmpArr);

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

    ce.getVariableSet().toString().

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

    } catch (Exception e) {

    System.out.println("Can not Create Evaluator. " +

    "Check the values in the input Array");

    }

    }

    @Test

    /**

    * test ConditionEvaluator constructor with String [][]

    */

    public void testConditionEvaluatorStringArrayArray() {

    String [][] tmpArr = new String[5][2];

    tmpArr[0][0] = this.x;

  • Bilaga D: Testfall i JUnit

    67

    tmpArr[0][1] = this.xValue;

    tmpArr[1][0] = this.y;

    tmpArr[1][1] = this.yValue;

    tmpArr[2][0] = this.z;

    tmpArr[2][1] = this.zValue;

    tmpArr[3][0] = this.z;

    tmpArr[3][1] = this.xValue;

    tmpArr[4][0] = this.y;

    tmpArr[4][1] = this.xValue;

    ConditionEvaluator ce;

    try {

    ce = new ConditionEvaluator(tmpArr);

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

    ce.getVariableSet().toString().

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

    } catch (Exception e) {

    System.out.println("Can not Create Evaluator. " +

    "Possibly Wrong Array Dimension");

    }

    }

    @Test

    /**

    * test ConditionEvaluator constructor with the string

    * "x=xVlue, y=yValue,z=zValue"

    */

    public void testConditionEvaluatorPropertyString() {

    String equal = Messages.operatorEQ;

    String comma = ","; //$NON-NLS-1$

    String tmpStr= this.x + equal + this.xValue + comma +

    this.y + equal + this.yValue + comma +

    this.z + equal + this.zValue + comma +

    this.y + equal + "4" ; //$NON-NLS-1$

    ConditionEvaluator ce;

    try {

    ce = new ConditionEvaluator(tmpStr, comma);

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

    ,ce.getVariableSet().toString().

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

    } catch (Exception e) {

    System.out.println("Can not Create Evaluator. " +

    "the String is not properly constructed " +

    "(variable=value) ");

    }

    }

    @Test

    /**

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

    */

    public void testEvaluateCondition() {

    Map tmpMap = new HashMap();

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

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

  • Bilaga D: Testfall i JUnit

    68

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

    ConditionEvaluator ce = new ConditionEvaluator(tmpMap);

    try

    {

    assertTrue("Step1: x= 1, Condition (x >=1) Should be true"

    ,ce.evaluate(this.steps.get("Step1")) );

    assertTrue ("Step3:x= 1, Condition (1 =1) && (y=1)) ^ (z=1)) Should be false",

    !ce.evaluate(this.steps.get("Step9")) );

    ce.addVariable(this.z, this.xValue); // z = 1

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

    "(((y=1)) || (z=1)) Should be true ",

    ce.evaluate(this.steps.get("Step7"))) ;

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

    "(((y=1)) ^ (z=1)) Should be true",

    ce.evaluate(this.steps.get("Step9")) );

    }catch (Exception e){

    fail("Wrong considitions!");

    }

    }

    @Test

    /**

    * test evaluate(Node c), XML node as parameter

    */

    public void testEvaluateNode() {

    Map tmpMap = new HashMap();

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

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

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

    ConditionEvaluator ce = new ConditionEvaluator(tmpMap);

    try

    {

    assertTrue("Step1: x= 1, Condition (x >=1) Should be true",

    ce.evaluate(this.conditionNodes.get(0)));

    assertTrue("Step3:x= 1, Condition (1

  • Bilaga D: Testfall i JUnit

    69

    ce.evaluate(this.conditionNodes.get(2)));

    assertTrue("Step4: x=1, y =2: Condition " +

    "((y=1)) Should be false",

    !ce.evaluate(this.conditionNodes.get(3)));

    assertTrue( "Step5: x=1, y =2: Condition " +

    "((x >=1) && (y

  • Bilaga E: Frkortningar

    71

    Bilaga E: Frkortningar 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

Recommended

View more >