Professional Documents
Culture Documents
Lutz Winkler
Hochschule fr Technik und Wirtschaft Mittweida (FH)
Kommunikationssysteme werden durch Software dominiert. Fr Software kann man einen Lebenszyklus angeben.
Der vorliegende Beitrag beschftigt sich mit dem Lebenszyklus von Protokollsoftware und im speziellen mit formalen
Sprachen fr ausgewhlte Phasen. Folgende Sprachen werden besprochen:
Message Sequence Chart (MSC), (ITU-T-Recommendation Z.120),
Specification and Description Language (SDL), (ITU-T-Recommendation Z.100),
Tree and Tabular Combined Notation (TTCN), (ISO International Standard 9646).
Es wird jeweils ein kurzer berblick zu den Sprachen gegeben. Die Nutzung von MSC und SDL wird exemplarisch
anhand eines einfachen HDLC-basierten Schicht-2-Protokolls, SimpleDataLink genannt, gezeigt. TTCN wird an
einem fast realen Beispiel demonstriert. Der Beitrag ist wie folgt gegliedert:
bersicht,
MSC - Message Sequence Chart,
SDL - Specification and Description Language,
TTCN - und der Test von Protokollen,
Ausblick.
bersicht
Kommunikationssysteme bestehen aus konfektionierter Steuer- sowie Funktionalhardware und komplexer Software.
Am Beispiel der Hard-Softwarestruktur eines ISDN-Telefons kann man zeigen, da Kommunikationssoftware aus
drei Teilen besteht:
Funktionalsoftware (z.B. Call Control Agent, Benutzerinterface),
Protokollsoftware (z.B. Protokolle der Schichten 1 bis 3, Stackmanagement)
und Supportsoftware (Echtzeitbetriebssystem zur Prozekoordinierung und Prozekommunikation).
Anzeige,
Anzeige,
Tastatur,
Tastatur,
Wecker
Wecker
PCM-Codec,
PCM-Codec,
Filter,
Filter,
Freisprech
Freisprech
Takte
D-KanalD-KanalController
Controller
B-Kanal
Takte
Upstream
Downstream
SS-oder
oder UUController
Controller
Rechner
Rechner mit
mit RAM,
RAM, ROM,
ROM, Timer
Timer
FUNKTIONALSOFTWARE
Anzeige,
Anzeige,
Tastatur,
Tastatur,
Wecker
Wecker
Call
Call Control
Control Agent
Agent
B-Kanal
Network
PROTOKOLLSOFTWARE
SUPPORTSOFTWARE
Data Link
D-Kanal-Controller
D-Kanal-Controller
Physical
SS-oder
oder U-Controller
U-Controller
Echtzeitbetriebssystem
Echtzeitbetriebssystem
Rechnerhardware
Rechnerhardware
Funktionalhardware
Funktionalhardware
PCM-Codec,
PCM-Codec,
Filter,
Filter,
Freisprech
Freisprech
Takte
von/zur
Vermittlung
Funktionsdefinition
Funktionsdefinition
Protokollspezifikation
Protokollspezifikation
C, Pascal, CHILL
ImplementierungsImplementierungsspezifikation
spezifikation
Implementation
Implementation
TTCN
SDL
MSC
Dienstespezifikation
Dienstespezifikation
MSC
verbale Sprachen
Der Lebenszyklus von Protokollsoftware besteht aus mehreren Phasen. In jeder Phase werden spezielle Sprachen
und Werkzeuge benutzt. Der Zusammenhang wird in Abbildung 2 dargestellt.
Test
Test
Betrieb
Betrieb u.
u. Wartung
Wartung
Sprachen fr den
Lebenszyklus
Abb. 2: Der Lebenszyklus von Protokollsoftware und verwendete Sprachen
Kommunikationssoftware
Am Ende jeder Phase des Lebenszyklus sollte ein abgeschlossenes Dokument als Input fr die nchste Phase bereitgestellt werden. Eine kurze Definition der einzelnen Phasen soll nachfolgend gegeben werden:
Function definition, ist die verbale Beschreibung der beabsichtigten Funktionalitt. Diese Beschreibung wird
bisher nur durch einige Standardisierungsgremien bereitgestellt. Beispielsweise heien bei ECMA diese
Dokumente Technical Report (Beispiel: TR/52). Diese TRs sind Lesebcher aus denen die Absichten, Ziele
und das betrachtete Umfeld von Standards hervorgehen. Sie versetzen den spteren Leser von Standards in
die Lage, so einigermaen das nachvollziehen zu knnen, was in den Kpfen der Standardisierer vor sich ging.
Service specification, ist die verbale/formale Beschreibung der Dienste einer Schicht (Umfang, Qualitt), die
einem Nutzer bereitgestellt werden sollen (z.B. X.211, X.212 bis X.217, Q.920, Q.930).
Protocol specification, ist eine implementierungsunabhngige Beschreibung der Funktionalitt eines Schichtenprotokolls. Derzeit werden von ISO und CCITT verbale und formale Spezifikationen vorgenommen.
Beachte, die verbale Spezifikation dominiert, die formale Spezifikation dient der besseren Lesbarkeit
und als Basis fr einen computergesttzten Entwurf. Die formalen Sprachen sind aber mit Absicht
nicht mchtig genug, um Feinheiten zu beschreiben. Dann wrde eine Spezifikation eine Fast-Implementation werden.
Formale Spezifikationen sind mglich mit endlichen Zustandsmaschinen (Finite state machine - FSM),
Petri-Netzen, erweiterten endlichen Zustandsmaschinen (Extended FSM - EFSM) in Gestalt von beispielsweise SDL und ESTELLE.
Implementation specification, ist eine implementierungsabhngige Beschreibung der Funktionalitt eines
Protokolls. Bercksichtigung finden hier die Laufzeitumgebung (Art der Prozekommunikation, Prozekoordination, Prozesynchronisation) und die Zielsprache. Als Werkzeug fr die Implementierungsspezifikation wird
eine Spezifikationssprache oder ein Subset der Zielsprache verwendet.
Implementation, wird zunehmend durch spezielle Werkzeuge untersttzt. Ansonsten werden die Standardwerkzeuge fr die Programmierung benutzt.
Der Test ist Teil der Validierung und dient der abschlieenden Bewertung der erreichten Funktionalitt.
Viele Begriffe im Kontext Validierung werden verschieden verwendet. Unter Validierung soll hier die Gesamtheit
aller Manahmen zur Sicherung der beabsichtigten Funktionalitt eines Protokolls oder einer Software verstanden
werden. Die Validierung umfat alle Phasen des Lebenszyklus. Fr bestimmte Phasen bzw. Methoden haben sich
folgende Validierungsschritte herausgebildet:
Verifizierung, ist die berprfung der Korrektheit einer Spezifikation vor der Umsetzung in ein Protokoll. Wird z.B. ein Protokoll fehlerhaft spezifiziert und dann implementiert, schleppt man unntige
und schwer lokalisierbare Fehler mit.
Rapid Prototyping, ist eine Methode, bei der auf unterschiedlichem Niveau und mit unterschiedlichen
Mitteln, ein Gerst oder Teile einer Software zu dem Zwecke beschrieben werden (z.B. mit SDL oder
C), um dieses Gerst oder Teile zu Simulieren oder Ablaufen zu lassen. Durch Steuern der Inputs und
Beobachten des Outputverhaltens kann man die Funktionalitt berprfen. Im allgemeinen wird der
letzte Prototyp das Produkt.
Test, wird unterschieden in Konformittstest, Zusammenarbeitstest, Test der Leistungsgfhigkeit und
der Robustheit gegenber Fehlverhalten der Umgebung. Dazu werden geeignete Testfolgen entworfen,
Testlufe durchgefhrt und das Verhalten analysiert. Diese Testfolgen werden ebenfalls standardisiert
und bilden die Testbasis. Im ISO-Standard IS9646 werden sowohl Testmethoden, als auch die Mittel
standardisiert, unter anderem auch eine Sprache zur Verhaltensbeschreibung TTCN (Tree and Tabular
Combined Notation). Diese wird im Abschnitt 4 etwas nher betrachtet.
Insgesamt wird deutlich, da der Entwurf, die Implementation und der Test ein iterativer Vorgang ist. Dazu sind
entsprechende Methoden und Sprachen erforderlich, die nachfolgend betrachtet werden sollen.
Kommunikationssoftware
Beschreibung
textuelle Darstellung
Kommentare
<comment>::=
comment <character string>
<text definition>::=
text <character string>;
Text
grafische Darstellung
Paging
MSC Dokument
<msc document>::=
<msc document head> <msc document body>
<mscdocument head>::=
mscdocument<msc document name>;
<msc document body>::=
{<message sequence chart>| <msc diagramm}*
<message sequence chart>::=
msc <msc head><msc body> endmsc;
<msc head>::=<msc name>[<msc interface>]
<msc interface>::=inst<instance list>;
<instance list>::=<instance name>[:<instance
kind>][,<instance list>]
<instance kind>::=[<kind denominator>]<identifier>
<kind denominator>::=system|block|process|service
Ein Rahmen grenzt ein MSC ab. Auerhalb des Rahmens ist Environment env.
msc name
Beschreibung
textuelle Darstellung
Instance
<instance definition>::=
instance <instance head> <instance body> endinstance;
Message
Condition
grafische Darstellung
Instanzkopfsymbol
Ende der
Beschreibung
Instanzkopfsymbol
Ende der
Beschreibung
Instanzachse
Messagesymbol
Instanzachse
Conditionsymbol
A
Condition X gilt
fr A und C, aber
nicht fr B
Beschreibung
textuelle Darstellung
Timer
<timer statement>::=<set>|<reset>|<timeout>
grafische Darstellung
Set Timer Symbol
Action
Timeout Symbols
Action Symbol
Process creation
Process stop
Coregion
<create>::=
create <instance name>[(<parameter list>)];
<shared instance list>|::=<instance name>[,<shared instance
list>]
<stop>::= stop;
<coregion>::= concurrent {<coevent>}* endconcurrent;
<coevent>:=<message input>|<message output>
<action text>
Create Symbol
Stop Symbol
Coregion Start
Coevent area
Coregion Stop
Kommunikationssoftware
Service User
Service User
Abstract Service
Primitives (ASP)
Services
Services
ASPs
Parameter
dlEstablishRq
dlEstablishIn
dlEstablishCf
dlDataRq
dlDataIn
dlUnitDataRq
dlUnitDataIn
dlReleaseRq
dlReleaseIn
dlReleaseCf
keine
keine
keine
Daten
Daten
Daten
Daten
keine
keine
keine
Abb. 4: Szenario und Definition der Dienste sowie der abstrakten Dienstprimitive
Nach der verbalen Beschreibung erfolgt eine formale Beschreibung mittels MSC. In Abbildung 5 werden die
geforderten Dienste sowohl in MSC.GR als auch MSC.MR beschrieben.
msc ServicesSimpleDataLink
SimpleDataLink
dlEstablishRq
dlEstablishIn
dlEstablishCf
dlDataRq(data)
dlUnitDataRq(data)
dlReleaseRq
dlDataIn(data)
dlUnitDataIn(data)
dlReleaseIn
dlReleaseCf
instance SimpleDataLink;
in dlEstablishRq from env;
out dlEstablishIn to env;
out dlEstablishCf to env;
in dlDataRq(data) from env;
out dlDataIn(data) to env;
in dlUnitDataRq(data) from env;
out dlUnitDataIn(data) to env;
in dlReleaseRq from env;
out dlReleaseIn to env;
out dlReleaseCf to env;
endmsc;
Kommunikationssoftware
Nach der Dienstespezifikation erfolgt die Protokollspezifikation. In Abbildung 5 werden das Szenario der
Diensterbringung, die festgelegten Protocol data units (PDUs) und ihre Bedeutung dargestellt.
Service User
Service User
(User side)
(Netw side)
Abstract Service
Primitives (ASP)
Services
DLUser
Abstract Service
Primitives (ASP)
Services
DLNetw
Peer-to-peer-protocol
Zwischen den paaren Instanzen findet ein virtueller Austausch von Protocol data
units (PDUs) nach feststehenden Regeln statt. Die Definition von PDUs und
der Regeln des Austausches selbiger, bezeichnet man als Protokoll
PDU
SABME
DISC
UA
I
UI
RR
Bedeutung
Parameter
keine
keine
keine
Daten
Daten
keine
DlNetw
State4
dlEstablishRq
SABME
dlEstablishIn
T200
State5
UA
dlEstablishCf
State7
reset T200;
msc ProtocolSimpleDataLinkEstablish;
condition state7 shared all;
inst DLUser, DLNetw;
endinstance;
instance DLUser;
instance DLNetw;
condition state4 shared all;
condition state4 shared all;
in dlEstablishRq from env;
in SABME from DLUser;
out SABME to DLNetw;
out dlEstablishIn to env;
start T200;
out UA to DLUser;
condition state5;
endinstance;
in UA from DLNetw;
endmsc;
out dlEstablishCf to env;
Abb. 6: MSC-Beschreibung eines erfolgreichen Verbindungsaufbaus
Kommunikationssoftware
Block Blck_A
P1
C1
Blck_A
Prc_A1
C2
P2
C3
Prc_A2
Blck_B
Procedure Pro_2
Process Prc_A2
Pro_2
State1
a3
Pro_2
Kommunikationssoftware
xy34
In den folgenden Abbildungen wird die Spezifikation des Protokolls fr die SimpleDataLink gezeigt. Verwendet
wurde das Tool SDT3.0 der Firma Telelogic.
Kommunikationssoftware
10
Abb.9 b,c,d: SDL.GR-Darstellung der Blcke DLUser und DLNetw und des Prozesses DLNetw
Kommunikationssoftware
11
System SimpleDataLink;
Kommunikationssoftware
12
Block DLNetw;
with (ASPsFrUser);
signalroute P32 from env to DLUser
with (PDUsToUser);
process DLUser referenced;
endblock ;
Process DLUser;
DCL daten daten;
TIMER T200;
start ;
nextstate state4 ;
state state5 ;
input T200 ;
output dlReleaseIn ;
nextstate state4 ;
input UA ;
reset (T200) ;
output dlEstablishCf ;
nextstate state7 ;
state state4 ;
input dlEstablishRq ;
output SABME ;
Set(now+1,T200) ;
nextstate state5 ;
input dlUnitDataRq(daten) ;
output UI(daten)
via C3ToNetw ;
nextstate - ;
state state7 ;
input dlUnitDataRq(daten) ;
output UI(daten)
via C3ToNetw ;
nextstate - ;
input dlDataRq(daten) ;
output I(daten)
via C3ToNetw ;
set(now+1,T200) ;
nextstate state7 ;
input dlReleaseRq ;
output DISC ;
set(now+1,T200) ;
nextstate state6 ;
state state7 ;
input RR ;
reset (T200) ;
nextstate - ;
input T200 ;
grs0:output dlReleaseCf ;
nextstate state4 ;
state state6 ;
input UA ;
reset (T200) ;
join grs0;
input T200 ;
join grs0;
endprocess ;
Kommunikationssoftware
13
Upper Tester, UT
T
E
S
T
E
R
PCO
Abstract Service
Primitives, A S P ' s
Implementation
Under Test, I U T
PCO
Abstract Service
Primitives, A S P ' s,
Protocol Data
Unit's, P D U ' s
Lower Tester, LT
Am Beispiel des Protokollstacks eines ISDN-Telefons, soll die Lage mglicher PCOs gezeigt werden (Abb. 11):
Kommunikationssoftware
14
S0-Interface
TESTER
Call Control
ASP's
mgliche PCO's
fr Upper Tester
PCO
Network
ASP's
ASP's,
PDU's
ASP's
PCO
ASP's
Network
PCO
mgliche PCO's
fr Lower Tester
Data Link
PCO
Data Link
PCO
IUT
PCO
Physical
ASP's,
PDU's
Physical
PCO
PCO
ASP's,
PDU's
UT
(N t)-A S P ' s
Test Coordination
Procedures, TCP
LT
TCP
LT
PCO
IUT
PCO
SUT
Test Management
Protocol
IUT
PCO
SUT
UT
(Nb) bis (Nt)PDU's
PCO
(Nb-1)-ASP's
Service Provider
(Nb-1)-ASP's
Service Provider
TM-PDU's
LT
Test Coordination
Procedures
15
SUT
TCP
UT
LT
(Nb) bis (Nt)PDU's
IUT
PCO
(Nb-1)-ASP's
Service Provider
Kommunikationssoftware
PCO
S
U
T
Service Provider
(N t)-A S P ' s
UT
IUT
Jede der grundlegenden Methoden wird wieder danach unterschieden, ob das zu testende Protokoll einzeln
vorliegt (single layer) oder ob das zu testende Protokoll in einen Stack eingebettet ist (single-layer embedded). In
der Testsuite wird die Methode angegeben, z.B. RS fr Remote Single layer oder RSE fr Remote Single layer
Embedded.
Wenn man die Methoden bezglich Steuerbarkeit und Beobachtbarkeit der IUT bewertet, ist die entfernte
Testmethode die schlechteste und dennoch die derzeit dominierende. Dies hat, wie bereits erwhnt, praktische
Grnde. Wenn beispielsweise ein ISDN-Telefon entwickelt wurde, ist der D-Kanal-Stack bezglich der
Schichten 1 bis 3 zu testen. Der Test erfolgt schichtenweise, beginnend bei Physical. Ist dieses
Schichtenprotokoll normenkonform, wird die Schicht 2 und danach die Schicht 3 getestet. In Abbildung 13 wird
ein Testszenario, die Bildschirmanzeige eines Testfalles sowie auf die Realisierung der Koordinierungsfunktion
zwischen unteren und oberen Tester eingegangen.
Test
Coordination
Procedures
Tester mit LT
TCP
SUT
UT
LT
Network
(DataLink)-PDU's
PCO
D a ta L in k
IUT
Physical
Service Provider
TIME
SAPI
P/F
NR NS
45'247439
45'269639
45'295707
45'311413
45'333451
45'545666
45'700001
48'952160
48'963453
48'996933
49'025666
49'041785
49'075354
49'100889
49'126400
49'138465
49'168333
49'178656
49'187678
49'202009
50'034776
50'054106
50'088002
50'114666
Trace
Trace
Trace
Trace
Trace
Trace
Net
Trace
Net
Usr
Net
Usr
Net
Usr
Net
Usr
Trace
Trace
Trace
Trace
Usr
Ntw
Usr
Net
TEST GROUP
:A.2.2.1.0 Initialisation
96/7/4 15:27:45
50'134212
Trace
TEST CASE
TEST CASE
63 127 1 UI
P=0
TNOAC expired
0
127 1 UI
P=0
63 127 0 UI
P=0
63 127 1 UI
P=0
0
69 0 SABME P=1
0
69 0 UA
F=1
0
69 0 INFO P=0
0
69 1 DISC P=1
0
69 1 UA
F=1
=====================
*
body
*
=====================
Please initiate a call
0
69 0 SABME P=1
0
69 0 UA
F=1
0
69 0 INFO P=0
0
69 0 RR
F=0
identity remove
Orig Q.931 1 SETUP
identity request
identity assigned
0
:A.2.2.1.1
Abb. 13: Reales Testszenario (remote) mit kommentiertem Monitortext eines Testers
Kommunikationssoftware
16
Preamble:
die IUT wird in
einen definierten
Anfangszustand
gebracht
!!!
0
1
allgemeine
Angaben zum
Testfall
An diesem Beispiel wird sichtbar, da der obere Tester (UT) eigentlich nicht existiert, sondern durch die
Benutzeroberflche des Telefons gegeben ist. Die Testkoordinierungsprozeduren werden durch Anweisungen auf
dem Monitor des Testers angestoen, die dann durch einen Operator realisiert werden.
Jeder Testfall besteht aus drei wesentlichen Teilen:
Testvorbereitung (Preamble); die IUT wird durch geeignete Manahmen in einen definierten Anfangszustand
gebracht.
Testdurchfhrung; der Test wird entweder durch den LT oder UT angestoen und luft zeitberwacht ab.
Testauswertung; hier werden die beobachteten Ereignisse mit den erwarteten Ereignissen, die in der Testsuite
beschrieben wurden, verglichen. Die Auswertung kennt drei Prdikate (verdicts):
pass, der Test wurde vollstndig bestanden,
fail, der Test wurde nicht bestanden, weil mindestens ein Ereignis nicht der Erwartung entsprach,
inconclusive, der Test lieferte kein schlssiges Ergebnis.
EINZELTABELLE
Objektname:
Zweck:
Kommentar: dieser Teil kann entfallen
Spalte1
...
Komponente 1
Komponente 2
Spalte n
...
Kommentare
Komponente m
Erweiterte Kommentare: dieser Teil kann entfallen
Objektname
Objektbezeichner 1
Objektbezeichner 2
...
Tabellenkrper
Tabellenfu
MEHRFACHTABELLE
Spalte n
...
Kommentare
Objektbezeichner n
Erweiterte Kommentare: dieser Teil kann entfallen
Tabellenfu
Abb. 14: Die zwei Tabellengrundtypen fr die Beschreibung einer Testsuite in TTCN.GR
Eine Testsuite hat dem Inhalt nach vier Teile, die auch in der genannten Reihenfolge anzuordnen sind:
berblicksteil (Overview part): hier werden der Name der Testsuite, der Protokollstandard gegen den zu
testen ist, das Profil des Protokolls und die Testmethode angegeben. Danach erfolgt ein berblick ber alle
Testflle und Testschritte. Dieser Teil wird automatisch generiert. Der Entwurf einer Suite beginnt beim
Deklarationsteil.
Deklarationsteil (Declaration part): dieser enthlt Typdefinitionen von Datenobjekten
Konstantendefinitionen. Beispielsweise werden hier alle Timer definiert und mit Werten bzw.
Wertebereichen versehen. Es werden alle ASPs (dlEstRq, phActIn usw.) deklariert und alle zu
verwendenden PDUs (SETUP, ALERT, I-Frame, RR-Frame usw.) und ihre Struktur einschlielich
Informationselemente (bearer capability, called party number, sending complete usw.) formal beschrieben.
Kommunikationssoftware
17
Constraintsteil (Constraint part): hier werden, basierend auf den Konstanten- und Typdefinitionen des
vorhergehenden Teils, die zu verwendenden Objekte beschrieben. Zum Beispiel werden verschiedene
SETUP-PDUs oder ALERT-PDUs usw. definiert. Diese werden dann als Input fr die IUT verwendet oder
als Vergleichsobjekt fr einen Output. Die Beschreibung der Objekte erfolgt anhand vordefinierter Typen
(Integer, Boolean, Bitstring, Hexstring, Octettstring usw.) und/oder der ASN.1 (Abstract Syntax Notation No.
1, ITU-T-Recommendation X.218, ISO 8824).
Verhaltensteil (Dynamic part): hier erfolgt die Beschreibung der Inputfolgen und der dazu zulssigen
Outputs. Dieser Teil ist auch ein wertvoller Zusatz fr die Protokollbeschreibung. Erst hier erfhrt man oft,
welche Merkmale das Protokoll in speziellen Situationen aufweisen mu und WARUM bestimmte
Eigenschaften im Protokoll vorgesehen wurden. In der Protokollbeschreibung steht ja letztlich nur, WAS das
Protokoll zu machen hat, nicht WARUM!
Im Verhaltensteil werden alle Testflle (Test cases), abgeleitet aus dem Verhaltensbaum (Behavior tree),
beschrieben. Fr jeden Testfall wird eine Einzeltabelle angelegt (vgl. Abbildung 15). In dieser Tabelle wird das
Verhalten, die Bewertung des Verhaltens und die Kommentierung zeilenweise notiert.
Die horizontale bzw. vertikale Position eines Ereignisses wird als zeitliche Ordnung bzw. zur Angabe von
Alternativen benutzt. In Abbildung 15 sind zustzlich zwei Achsen eingezeichnet, die diese Ordnung
reprsentieren sollen.
Aus der TTCN-Sprachbeschreibung (ISO9646-3) werden nachfolgend die wesentlichsten TTCN-Anweisungen,
Timeroperationen und Ausdrcke dargestellt (Abbildung 15).
Ereignis
Senden eines ASPs oder einer PDU von einem bestimmten PCO aus
Syntax
[PCO_Id] ! (ASP_Id | PDU_Id)
Implizites Senden eines ASPs oder einer PDU vom UT als Teil der IUT
PCO
unerwartetes Ereignis, ist alles was nicht ausdrcklich im Testfall
[PCO_Id] ? OTHERWISE
beschrieben ist
Gehe zu Zeile mit dem Label (Marke) xyz
GOTO Label
+ TreeReference
CANCEL Timer_Id
READ Timer_Id
? TIMEOUT Timer_Id
Die Anwendung von TTCN soll an dem Beispiel erfolgen , welches in Abbildung 13 dargestellt wurde. Dabei ist
zu beachten, da die nachfolgende Verhaltensbeschreibung nicht ganz vollstndig ist, da dies den Rahmen des
Beitrages sprengen wrde.
Kommunikationssoftware
18
V Constraint
Reference
Comments
Zeit
1
L!UI_M (RC::=0) START TNOAC
2
L?UI_Mr (RC::=RC+1) CANCEL TNOAC
3
[RC<=RCMax] START TNOAC
4
GOTO L2
5
[RC>RCMax]
6
+POSTAMBLE
7
?TIMEOUT TNOAC
8
L!UI START TWAIT
9
L?UI_Mr
10
(CURRENT_TEI::=RANDOM(64,126)
11
L!UI_M START TAC
12
L?SABMEr CANCEL TAC
13
(NS::=0,NR::=0)
14
L!Uar START TAC
15
L?Ir CANCEL TAC
16
(NR::=(NR+1)MOD 128)
17
L!DISC START TAC
18
(NS::=0,NR::=0)
19
L?UAr CANCEL TAC
20
<IUT!SABME>
21
START TWAIT
22
L?SABME CANCEL TWAIT
23
(NS::=0,NR::=0)
24 AlterL!UA START TWL3
25 nativen
L?Icr
26
(NR::=(NR+1)MOD 128)
27
L!RR
28
+POSTAMBLE
29
?TIMEOUT TWL3
30
+POSTAMBLE
31
?TIMEOUt TWAIT
32
+POSTAMBLE
33
?TIMEOUT TAC
34
+POSTAMBLE
35
?TIMEOUT TAC
36
+POSTAMBLE
37
?TIMEOUT TAC
38
+POSTAMBLE
39
?TIMEOUT TWAIT
40
+POSTAMBLE
UM_T6
UM_T1
L2
UI3
UM(T1)
SA(P1)
UA(F1)
IN8
P
DI(P1)
UA(F1)
SA(P1)
SA(F1)
IN5
RRR
In dem gezeigten Testfall soll der Verbindungsaufbau von der IUT aus getestet werden. In der Pramble wird
zuerst der TEI-Wert zurckgezogen. Wenn die IUT eine automatische TEI-Zuweisung untersttzt, wird diese
versuchen, einen neuen TEI-Wert zu bekommen (Zeilen 2 bis 5). Der Lower Tester reagiert nicht darauf, zhlt
aber die Anzahl der Versuche (RCMax). Wird RCMax berschritten, ist der Testfall gescheitert.
Luft der Timer TNOAC ab, geht der Test weiter. Der LT schickt unnumeriert eine unvollstndige SETUPNachricht (Zeile 8). Die IUT mu daraufhin, wenn sie standardkonform ist, einen TEI-Wert anfordern (Zeile 9),
Kommunikationssoftware
19
eine Schicht-2-Verbindung aufbauen (Zeile 12) und numeriert die Schicht-3-Nachricht REL_COM (Zeile 15)
schicken. Dieser I-Rahmen wird nicht quittiert, sondern die Schicht-2-Verbindung wird vom Lower Tester aus
abgebaut (Zeilen 17 bis 19). Die Schicht 2 der IUT befindet sich jetzt im Zustand 4 (TEI assigned).
Auf dem Tester erscheint die Ausschrift Please initiate a call. Der Testoperator nimmt den Telefonhrer ab.
Der Call Control Agent (siehe Abbildung 1) beauftragt die Schicht 3 mit einem Verbindungsaufbau. Schicht 3
wird mit dem ASP dlEstablishRq den Aufbau der Schicht 2 veranlassen. Das erwartete Ergebnis ist in den Zeilen
22 bis 27 dargestellt. Treten alle erwarteten Ereignisse ein, wird in Zeile 28 die Postamble abgearbeitet. In der
Postamble werden Zustnde der IUT getestet, die IUT in einen definierten Zustand gebracht, alle Testaussagen
bewertet und das Ergebnis pass, fail oder inconclusive ausgegeben.
Ausblick
Der Entwurf, die Entwicklung und der Test von Kommunikationssoftware wird durch formale Sprachen und
darauf basierenden Tools untersttzt. Die drei besprochenen Sprachen: MSC, SDL und TTCN sind semantisch
relativ gut aufeinander abgestimmt, die Syntax ist aber sehr verschieden.
Bei der Weiterentwicklung der Sprachen ist eine Eigendynamik zu beobachten, d.h. die Sprachen werden immer
mchtiger und wachsen in die Rolle von Sprachen fr die nchste Phase des Lebenszyklus hinein. Beispielsweise
kann man mit SDL auch programmieren.
Um der sogenannten Softwarekrise besser begegnen zu knnen, mu in der Ingenieurausbildung die Software
einen greren Raum einnehmen. Basierend auf den Grundlagen der Informatik und der Automatentheorie sind
Fachsprachen fr den Softwarelebenszyklus und ausgewhlte Werkzeuge dafr, Echtzeitbetriebssysteme sowie
das Management groer Softwareprojekte umfnglicher zu lehren.
Literatur
[BAUMGIES]
Autor:
Prof. Dr.-Ing. habil. Lutz Winkler
Hochschule fr Technik und Wirtschaft Mittweida (FH), Fachbereich Elektrotechnik/Elektronik
Technikumplatz 17, 09482 Mittweida
03727 581290
FAX 03727 581420
win@htwm.de
Kommunikationssoftware
20