Deutsch (DE-CH-AT)English (United Kingdom)

OTX - Basiskonzepte

(0 Bewertungen)

In OTX wur­den ver­schie­de­ne Basis­kon­zep­te umge­setzt. Die­se Kon­zep­te wider­spie­geln den Ent­wick­lungs­pro­zess von Prüfab­läu­fen beim Auto­mo­bil­her­stel­ler und des­sen Zulie­fe­rern. Sie ent­hal­ten die jah­re­lang gewach­se­nen prak­ti­schen Erfah­run­gen mit Prüfab­läu­fen und bil­den neben den Erwei­te­rungs­bi­blio­the­ken den Domä­nen spe­zi­fi­schen Teil des Stan­dards ab.

Ziel der Basiskonzepte: Reduzierung und Beherrschung der KomplexitätZiel der Basis­kon­zep­te: Redu­zie­rung und Beherr­schung der Kom­ple­xi­tät

Im nach­fol­gen­den Abschnitt wer­den die­se Kon­zep­te auf­ge­lis­tet und beschrie­ben:

Spe­ci­fi­ca­tion/Rea­li­sa­tion Kon­zept

OTX unter­stützt für die ver­teil­te Ent­wick­lung von Test­se­quen­zen einen 3 stu­fi­gen Ent­wick­lungs­pro­zess. Begin­nend mit einer abstrak­ten, all­ge­mei­nen Stu­fe wer­den die Abläu­fe immer wei­ter her­un­ter gebro­chen und detail­lier­ter. In jeder Pha­se kön­nen die Abläu­fe mit Hil­fe geeig­ne­ter Soft­wa­re­werk­zeu­ge vali­diert, aus­ge­tauscht und aus­ge­führt wer­den. 

  1. Stu­fe: Spe­zi­fi­ka­tion (Spe­zi­fi­ka­ti­ons­pha­se)

    Die Spe­zi­fi­ka­ti­ons­pha­se dient der Beschrei­bung der Sequen­zen (Spe­zi­fi­ka­tion) in einer frü­hen Pha­se des Ent­wick­lungs­pro­zes­ses. Hier ist die all­ge­mei­ne Ablauf­lo­gik zwar bekannt, jedoch die Details für eine ablauf­fä­hi­ge Sequenz sind noch unklar, kön­nen aber in Pro­sa beschrie­ben wer­den. Der Ablauf wird aus ein­zel­nen Akti­vi­tä­ten zusam­men­ge­setzt, wel­che noch kei­ne Rea­li­sie­rung haben. Das heißt, die Akti­vi­tä­ten wer­den kei­ner kon­kre­ten Funk­tion zuge­ord­net. Ihnen wird ledig­lich ein Name und eine Beschrei­bung zuge­ord­net. Der Ablauf ist aus­führ­bar. Da die Rea­li­sie­rung der Akti­vi­tä­ten fehlt, wer­den sie mit Hil­fe geeig­ne­ter Dia­lo­ge simu­liert.

  2. Stu­fe: Zwi­schen­stu­fe (Rea­li­sie­rungs­pha­se)

    In der Rea­li­sie­rungs­pha­se imple­men­tiert ein Autor aus den Spe­zi­fi­ka­tio­nen der Akti­vi­tä­ten die ein­zel­nen Rea­li­sie­run­gen. Das heißt, er ord­net den Akti­vi­tä­ten ohne Rea­li­sie­rung eine Funk­tion (Rea­li­sie­rung) zu und kon­fi­gu­riert die­se. Natur­ge­mäß besteht der Ablauf in die­ser Pha­se aus einer Mischung von Akti­vi­tä­ten mit und ohne Rea­li­sie­rung. Auch hier ist der Ablauf aus­führ­bar. Das Ablauf­sys­tem führt die rea­li­sier­ten Akti­vi­tä­ten aus. Es kann hier bei­spiels­wei­se bereits eine Kom­mu­ni­ka­tion mit einem Steu­er­ge­rät statt­fin­den. Feh­len­de Rea­li­sie­run­gen wer­den durch geeig­ne­te Dia­lo­ge „simu­liert".

  3. Stu­fe: Rea­li­sie­rung

    In der letz­ten Stu­fe gibt es für jede Spe­zi­fi­ka­tion eine Rea­li­sie­rung. Die Sequenz ist voll ablauf­fä­hig. Es muss kei­ne Akti­vi­tät simu­liert wer­den.

Specification/Realisation-KonzeptSpe­ci­fi­ca­tion/Rea­li­sa­tion-Kon­zept

Kon­text Kon­zept

Das Kon­text Kon­zept ist prak­tisch ein Map­ping-Mecha­nis­mus für Umge­bungs­pa­ra­me­ter auf Ebe­ne des OTX-Lauf­zeit­sys­tems.

Die Lauf­zeit­um­ge­bung für OTX Abläu­fe ist in der Pra­xis sehr hete­ro­gen. Ver­schie­de­ne inner­halb der OTX-Abläu­fe benö­tig­te Infor­ma­tio­nen, die nicht aus den Steu­er­ge­rä­ten aus­ge­le­sen wer­den kön­nen, müs­sen durch die Dia­gno­se­an­wen­dung bereit­ge­stellt wer­den. Dies sind unter ande­rem: 

  • Fahr­zeug­da­ten

    Fahr­zeug­mo­dell, Ver­käu­fer, Iden­ti­fi­ka­ti­ons­num­mer, Moto­ri­sie­rung oder Son­deraus­stat­tungs­da­ten etc.

  • Daten der Dia­gno­se­appli­ka­tion (Tes­ter)

    Name, Ver­sion, Ver­wen­de­tes VCI, Anwen­dungs­ein­stel­lun­gen etc.
  • Benut­zer­da­ten

    Benut­zer­na­me, Benut­zer­rech­te, Idle-Time etc.
  • Umge­bungs­da­ten

    Stand­ort (z.B. Ent­wick­lung, Pro­duk­tion oder Ser­vice), Ver­sion des Betriebs­sys­tems etc.

OTX bie­tet dafür so genann­te Kon­text­va­ria­blen. Die Kon­text­va­ria­blen wer­den durch den Autor einer OTX Sequenz defi­niert. Er kann sie dann inner­halb der Abläu­fe wie glo­ba­le Kon­stan­ten ver­wen­den. Die Varia­blen kön­nen nur gele­sen und nicht geschrie­ben wer­den. Die OTX-Lauf­zeit­um­ge­bung (OTX Run­ti­me) erkennt die­se spe­zi­el­len Varia­blen und for­dert die Wer­te der Varia­blen von der Dia­gno­se­appli­ka­tion an. Das Ablauf­sys­tem unter­stützt dazu ein Map­ping-Inter­fa­ce, an wel­ches sich die dar­über lie­gen­de Anwen­dung ein­klin­ken kann.

OTX Kontextvariablen zum Zugriff auf UmgebungsdatenOTX - Kon­text­va­ria­blen zum Zugriff auf Umge­bungs­da­ten

Vor­tei­le:

  • Das Arbei­ten mit Kon­text­va­ria­blen ist gleich dem Arbei­ten mit glo­ba­len Kon­stan­ten
  • Für die Inte­gra­tion von OTX in beste­hen­de Sys­te­me kann die vor­han­de­ne Struk­tur wei­ter­ver­wen­det wer­den
  • Beim Aus­tausch der OTX Sequen­zen mit ande­ren Lauf­zeit­um­ge­bun­gen, die ähn­li­che Infor­ma­tion in ähn­li­cher Wei­se bereit­stel­len, muss nur der Map­ping-Layer ange­passt wer­den.
  • Kon­text­va­ria­blen kön­nen über eine spe­zi­el­le Anwen­dung von extern simu­liert wer­den.

Vali­di­ty Kon­zept

Auf­bau­end auf dem zuvor beschrie­be­nen Kon­text Kon­zept unter­stützt OTX ein so genann­te Vali­di­ty Kon­zept. Damit ist es mög­lich, Test­se­quen­zen für unter­schied­li­che Umge­bungs­be­din­gun­gen zu kon­fi­gu­rie­ren. Inner­halb der Test­se­quenz kann über Vali­di­ties ent­spre­chend der jewei­li­gen Umge­bung Tei­le der Sequenz aus- und ein­blen­den.

Vali­di­ties müs­sen auf Ebe­ne eines OTX-Doku­ments defi­niert wer­den. Sie beste­hen ent­we­der aus einer boo­le­schen Kon­text­va­ria­blen oder aus einem zusam­men­ge­setz­ten logi­schen Aus­druck (Vali­di­ty-Term) vom Typ Boo­lean. Es kön­nen so meh­re­re Kon­text­va­ria­blen ver­knüpft oder auch glo­ba­le Kon­stan­ten ver­wen­det wer­den. Akti­vi­tä­ten, Sequen­zen und Pro­ze­du­rauf­ru­fe wer­den über die Valid­For-Eigen­schaft an eine Vali­di­ty gebun­den. Zur Lauf­zeit wer­den sie nur dann aus­ge­führt, wenn die Vali­di­ty True ergibt. Sie sind somit nur im jewei­li­gen Umge­bungs­kon­text gül­tig.

Vor­tei­le:

  • Kla­re Abgren­zung zwi­schen Ent­schei­dun­gen, die auf sta­ti­schen, zur Ent­wick­lungs­zeit bekann­ten Umge­bungs­da­ten beru­hen und Ent­schei­dun­gen auf Basis dyna­mi­scher Wer­te.
  • Vali­di­ties steu­ern den Ablauf impli­zit über die Umge­bungs­da­ten und nicht expli­zit über Ver­zwei­gun­gen (IfEl­se-Bran­ch). Dadurch wird die Anzahl der Ver­zwei­gun­gen deut­lich ver­rin­gert und der Ablauf kom­pak­ter und leich­ter les­bar. Die eigent­li­che Test­lo­gik wird bes­ser sicht­bar.
  • Es ist mög­lich einen Satz häu­fig ver­wen­de­ter Vali­di­ties in einem sepa­ra­ten Doku­ment zu spei­chern und dies an einem zen­tra­len Ort allen Auto­ren zugäng­lich zu machen. Damit wer­den Red­un­dan­zen ver­mie­den und die Wart­bar­keit wird erhöht.
  • Eine OTX Auto­re­num­ge­bung ist u.U. in der Lage, ver­schie­de­ne Umge­bungs­sze­na­ri­en dar­zu­stel­len, indem es nicht ver­wen­de­te Zwei­ge aus­blen­det (Fil­te­rung).
  • Ist die Basis für das Signa­tur-Kon­zept, sie­he nächs­ter Abschnitt.

Validity-KonzeptVali­di­ty-Kon­zept

Signa­tur Kon­zept

Das Signa­tur Kon­zept basiert auf dem Vali­di­ty Kon­zept und ist die­sem ähn­lich. Vali­di­ties beschrei­ben die Gül­tig­keit ein­zel­ner Akti­vi­tä­ten. Über Signa­tu­ren kann die Gül­tig­keit einer Pro­ze­dur beschrie­ben wer­den. Eine Signa­tur beschreibt ein Inter­fa­ce oder Pro­to­typ für eine Pro­ze­dur. Eine Signa­tur ist somit wie eine Pro­ze­dur ohne Imple­men­tie­rung. Signa­tu­ren besteht aus Namen, Ein- und Aus­ga­be­pa­ra­me­tern sowie einer Beschrei­bung. Pro­ze­du­ren kön­nen über Signa­tu­ren indi­rekt auf­ge­ru­fen wer­den. Der Auf­ru­fer muss nur die Para­me­ter und die Spe­zi­fi­ka­tion aber kei­ne Imple­men­tie­rungs­de­tails der Pro­ze­dur ken­nen. Signa­tu­ren erlau­ben das Erzeu­gen von gene­ri­schen Sequen­zen, die sich den jewei­li­gen Umge­bungs­be­din­gun­gen zur Lauf­zeit anpas­sen kön­nen.

Signatur-KonzeptSigna­tur-Kon­zept

Vor­tei­le:

  • Sequen­zen müs­sen nicht geän­dert müs­sen, wenn ein neu­er Kon­text hin­zu­ge­fügt wird.
  • Erhöht die Wart­bar­keit bei der Lang­zeit­ver­füg­bar­keit von Test­se­quen­zen.
  • Ermög­licht die ver­teil­te Ent­wick­lung von Test­se­quen­zen. Die Signa­tur dient dabei als for­ma­le Defi­ni­tion der Schnitt­stel­len zwi­schen den ein­zel­nen Part­nern.

Basiskonzepte für das Variantenmanagement im VergleichBasis­kon­zep­te für das Vari­an­ten­ma­na­ge­ment im Ver­gleich

Siehe auch

  • Erstellt
    12. Januar 2011
  • Version
    38
  • Geändert
    18. Oktober 2011
  • Zugriffe
    52395