Post on 26-Sep-2015
description
Kommunikationssoftware 1
KommunikationssoftwareLutz 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 formalenSprachen 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 exemplarischanhand eines einfachen HDLC-basierten Schicht-2-Protokolls, SimpleDataLink genannt, gezeigt. TTCN wird aneinem 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.
bersichtKommunikationssysteme 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).
PCM-Codec,Filter,Freisprech
PCM-Codec,Filter,Freisprech
D-Kanal-ControllerD-Kanal-Controller
S- oder U-ControllerS- oder U-Controller
Rechner mit RAM, ROM, Timer Rechner mit RAM, ROM, Timer
Anzeige,Tastatur,Wecker
Anzeige,Tastatur,Wecker
Takte
B-Kanal
Takte
UpstreamDownstream
von/zur
Vermittlung
Anzeige,Tastatur,Wecker
Anzeige,Tastatur,WeckerCall Control AgentCall Control Agent
Network
Data Link
Physical S- oder U-ControllerS- oder U-Controller
D-Kanal-ControllerD-Kanal-Controller
PCM-Codec,Filter,Freisprech
PCM-Codec,Filter,Freisprech
B-Kanal Takte
RechnerhardwareRechnerhardware FunktionalhardwareFunktionalhardware
FUNKTIONAL-SOFTWARE
PROTOKOLL-SOFTWARE
SUPPORT-SOFTWARE
EchtzeitbetriebssystemEchtzeitbetriebssystem
Abb.1: Hard-Software-Struktur eines ISDN-Telefons
Kommunikationssoftware 2
Software fr Kommunikationssysteme ist besondere Software:
Sie mu sehr zuverlssig sein. Sie mu wartbar sein, denn Kommuniktionssysteme haben teilweise eine Lebensdauer von 10 Jahren und mehr
(z.B. Vermittlungen). Sie ist oft sehr komplex, mu daher von mehreren (vielen) Bearbeitern implementiert werden. Beispielsweise
werden fr das Vermittlungssystem EWSD 2000 Mannjahre fr die Softwareentwicklung angegeben. Protokollstandards und Anforderungen an die Funktionalsoftware sind nicht stabil. Damit mu diese Software
ber viele Jahre relativ hufig angepat werden. Protokollsoftware ist teure Software, sie sollte deshalb wiederverwendbar und portierbar sein.
Die Kosten fr die Softwareentwicklung machen in Produkten der Kommunikationstechnik teilweise bis zu 80%
der Gesamtentwicklungskosten aus. Aufgrund dieser Tatsache versucht man, die Technologie zu verbessern. In
[HALLMANN] wurden u.a. folgende Merkmale des gegenwrtigen Standes der Softwaretechnologie angegeben:
Strukturierte Methoden der Softwareentwicklung haben bisher nur etwa 10% des Marktes erreicht. Das Management von Softwareprojekten verluft zufllig. Nur 2-4% aller Entwickler benutzen CASE-Tools (Computer Aided Software Energineering). 80% aller Softwareprojekte bleiben nicht in geplantem Zeit- bzw. Aufwandrahmen. 60% aller festgestellter Fehler eines Softwareprodukts gehen auf die Spezifikation zurck. Die Beseitigung
dieser Spezifikationsfehler macht bis zu 75% der Gesamtentwicklungskosten aus. 70% der entwickelten Software werden nicht ausgeliefert bzw. nie richtig genutzt. 40% des Aufwandes zur Erstellung von Software werden zum Testen bentigt. Von den Gesamtkosten einer Software ber den Lebenszyklus entfallen 35% auf die Spezifikation, Be-
schreibung, Implementation und Test, aber 65% auf die Abnahme der Software sowie die Wartung und Pflege. Die Produktivitt wird in "Line of Code" gemessen. Derzeit (1990) betrgt sie 5 LOC/Std. Bezogen auf 1955
ergibt sich lediglich eine Produktivittssteigerung von 3% bis 4%.
Whrend viele Basistechnologien der Kommunikationstechnik (Mikroelektronik, Signalverarbeitung, bertra-
gungstechnik usw.) ein teilweise atemberaubenes Tempo vorlegen, steht die Softwareproduktivitt fast auf der
Stelle. Ein weiteres Hemmnis ist die Tatsache, da die Werkzeuge fr die einzelnen Lebensphasen nicht
hinreichend gut aufeinander abgestimmt sind, so da an den Schnittstellen oft Anpassungsprobleme entstehen.
Der Lebenszyklus von Protokollsoftware besteht aus mehreren Phasen. In jeder Phase werden spezielle Sprachen
und Werkzeuge benutzt. Der Zusammenhang wird in Abbildung 2 dargestellt.
FunktionsdefinitionFunktionsdefinition
DienstespezifikationDienstespezifikation
ProtokollspezifikationProtokollspezifikation
Implementierungs-spezifikation
Implementierungs-spezifikation
ImplementationImplementation
TestTest
Betrieb u. WartungBetrieb u. Wartung
MS
C
SD
L
C,
Pas
cal,
CH
ILL
TT
CN
verb
ale
Sp
rach
en
MS
C
Sprachen fr denLebenszyklus
durch Standards festgelegt
Abb. 2: Der Lebenszyklus von Protokollsoftware und verwendete Sprachen
Kommunikationssoftware 3
Am Ende jeder Phase des Lebenszyklus sollte ein abgeschlossenes Dokument als Input fr die nchste Phase be-
reitgestellt werden. Eine kurze Definition der einzelnen Phasen soll nachfolgend gegeben werden:
Function definition, ist die verbale Beschreibung der beabsichtigten Funktionalitt. Diese Beschreibung wirdbisher 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), dieeinem 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 Schich-tenprotokolls. 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-Imple-
mentation werden.
Formale Spezifikationen sind mglich mit endlichen Zustandsmaschinen (Finite state machine - FSM),
Petri-Netzen, erweiterten endlichen Zustandsmaschinen (Extended FSM - EFSM) in Gestalt von bei-
spielsweise SDL und ESTELLE.
Implementation specification, ist eine implementierungsabhngige Beschreibung der Funktionalitt einesProtokolls. Bercksichtigung finden hier die Laufzeitumgebung (Art der Prozekommunikation, Prozekoordi-
nation, 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 Standard-werkzeuge 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 Gesamtheitaller 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 Proto-koll. 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 unterschiedlichenMitteln, 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 undder 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 4
MSC - Message Sequence Chart
Eine kurze SprachbeschreibungMessage Sequence Chart (MSC) wird in der ITU-T-Recommendation Z.120 spezifiziert. Diese Sprache soll in Ver-
bindung mit SDL und TTCN den Entwurf, die Simulation, den Test und die Dokumentation von
Kommunikationssoftware untersttzen:
Mit Hilfe von MSC kann das beabsichtigte (Teil-) Verhalten eines Systems in Form desNachrichtenaustausches zwischen Systemkomponenten und ihrer Umgebung dargestellt werden.
Mit Hilfe von MSC kann bei der Simulation oder dem Test das tatschliche Verhalten dargestelltwerden.
Fr MSC gibt es zwei Darstellungsformen: eine textuelle (MSC.PR, phrase representation) und eine grafische
(MSC.GR, graphical representation). Die Syntax wird, da diese Sprache noch relativ wenig bekannt ist, verkrzt
dargestellt. Die folgende Sprachbeschreibung basiert auf [Z.12094]. Die Sprache wurde weiterentwickelt
[Z.12096], die Basiskonzepte sind aber identisch.
Beschreibung textuelle Darstellung
Kommentare ::=comment
Text ::=text ;
Paging
MSC Dokument ::= ::=mscdocument;::={|
Kommunikationssoftware 5
Beschreibung textuelle Darstellung
Instance ::=instance endinstance;
::= [[:]][decomposed];
::=[]
::={||||||}*
Message ::= in from ;::= out to ;
::=::=|env
Condition ::=condition [shared{|all}] ;
|::=[,]
Instanzachse
Instanzkopf-symbol
Ende derBeschreibung
Ende derBeschreibung
Instanzachse
Instanzkopf-symbol
Messagesymbol
Conditionsymbol
X
A B C
Condition X giltfr A und C, abernicht fr B
grafische Darstellung
Abb. 3b: MSC-Sprachbeschreibung
Eine Instanz kann, wie bei SDL, ein Proze, ein Block oder ein Service sein. Zustzlich zum Instanznamen, derber dem Instanzkopfsymbol steht, kann innerhalb des Instanzkopfsymbols ein Prozess-Name, ein Service-Name
oder das Schlsselwort decomposed stehen.
BEISPIEL: User: process DataLink. In diesem Falle heit die Instanz User, und es wird der Proze DataLink
beschrieben.
Steht im Instanzkopfsymbol das Schlsselwort decomposed, dann heit das, da die Instanzbeschreibung irgendwo
detallierter erfolgt, nmlich in einer Sub-MSC. Diese Sub-MSC hat den gleichen Namen wie die Instanz. Der
Instanzname wird damit zur Referenz zwischen einer MSC und Sub-MSC.
Das Instanzkopf- und Instanzende-Symbol einer Instanz bezieht sich nur auf den Beginn und das Ende der
Beschreibung, nicht auf die Existenz einer Instanz!
Messages werden in kommende (in) und gehende (out) unterschieden. Messages werden zwischen Instanzenuntereinander oder zwischen einer Instanz und der Umgebung (env) ausgetauscht. Messages knnen instaziiert
werden und parametrisiert sein.
BEISPIEL: in dlDataRq(daten) from env. Eine Instanz bekommt eine Nachricht dlDataRq mit dem Parameterdaten von der Instanz Environment.
Eine Condition beschreibt entweder einen globalen Sytemzustand oder nur den Zustand einer oder mehrerer (abernicht aller) Instanzen.
BEISPIEL: condition state4 shared all. Alle Instanzen einer MSC sind im Zustand state4.
BEISPIEL: condition state7 shared DLUser, DLNetw. Die Instanzen DLUser und DLNetw befinden sich im
Zustand state7.
Kommunikationssoftware 6
Beschreibung textuelle Darstellung
Timer ::=||
::= set[,][
Kommunikationssoftware 7
Die verwendeten Abkrzungen in den abstrakten Dienstprimitiven sind:
Rq Request (Anforderung eines Dienstes),
In Indication (Anzeige eines Dienstes),
Cf Confirmation (Besttigung der erfolgreichen Ausfhrung eines Dienstes).
Service User Service User
SimpleDataLink(Service Provider)
Abstract ServicePrimitives (ASP)Services Services
Service (Dienst) ASPs ParameterAnforderung zum Aufbau einer Verbindung dlEstablishRq keine
Anzeige, Verbindung, initiiert vom Partner, aufgebaut dlEstablishIn keine
Besttigung, Verbindung wurde aufgebaut dlEstablishCf keine
Anforderung zur quittierten Datenbertragung dlDataRq Daten
Anzeige von quittiert empfangenen Daten dlDataIn Daten
Anforderung zurunquittierten Datenbertragung dlUnitDataRq Daten
Anzeige von unquittiert empfangenen Daten dlUnitDataIn Daten
Anforderung zum Abbau einer Verbindung dlReleaseRq keine
Anzeige, Verbindung, initiiert vom Partner, abgebaut dlReleaseIn keine
Besttigung, Verbindung wurde abgebaut dlReleaseCf 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; instSimpleDataLink;
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;
Abb. 5: Formale Dienstebeschreibung der SimpleDataLink in MSC.GR und MSC.MR
msc ServicesSimpleDataLinkSimpleDataLink
dlEstablishRq dlEstablishIn
dlEstablishCf
dlDataRq(data) dlDataIn(data)
dlUnitDataRq(data) dlUnitDataIn(data)
dlReleaseRq dlReleaseIn
dlReleaseCf
Kommunikationssoftware 8
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(User side)
Service User(Netw side)
DLUser DLNetw
ServicesAbstract ServicePrimitives (ASP)
Abstract ServicePrimitives (ASP) Services
Peer-to-peer-protocol
Zwischen den paaren Instanzen findet ein virtueller Austausch von Protocol dataunits (PDUs) nach feststehenden Regeln statt. Die Definition von PDUs undder Regeln des Austausches selbiger, bezeichnet man als Protokoll
PDU Bedeutung ParameterSABME Gehe in den Zustand 7, damit quittierte Datenbertragung mglich ist keine
DISC Gehe in den Zustand 4 (nur noch unquittierte Datenbertragung mglich) keine
UA Positive Quittung als Antwort auf SABME oder DISC keine
I Informationsrahmen zur quittierte Datenbertragung Daten
UI Unnumerierter Informationsrahmen zur unquittierten Datenbertragung Daten
RR Quittierung eines empfangenen Informationsrahmens keine
Abb. 5: Szenario der OSI-Diensterbringung und Definition der PDUs
Jetzt knnen ausgewhlte Sequenzen des Protokollablaufes mit den Mitteln von MSC beschrieben werden.
msc ProtocolSimpleDataLinkEstablishDlUser
dlEstablishRq dlEstablishIn
dlEstablishCf
State4
SABME
DlNetw
State5
UA
State7
T200
msc ProtocolSimpleDataLinkEstablish;inst DLUser, DLNetw;instance DLUser;condition state4 shared all;in dlEstablishRq from env;out SABME to DLNetw;start T200;condition state5;in UA from DLNetw;out dlEstablishCf to env;
reset T200;condition state7 shared all;endinstance;instance DLNetw;condition state4 shared all;in SABME from DLUser;out dlEstablishIn to env;out UA to DLUser;endinstance;endmsc;
Abb. 6: MSC-Beschreibung eines erfolgreichen Verbindungsaufbaus
Kommunikationssoftware 9
SDL - Specification and Description Language
Die SDL-Sprachbeschreibung wurde erstmals 1972 in der ITU-T-Recommendation Z.100 als Standard
herausgegeben. Seit dieser Zeit wurde SDL, fr die es ebenfalls eine grafische (SDL.GR, graphical representation)
und textuelle (SDL.PR, phrase representation) Darstellungsform gibt, weiterentwickelt. Die Sprache ist in der
Zwischenzeit sehr mchtig geworden und relativ bekannt. Deshalb wird hier nur ein kurzer berblick gegeben.
SDL basiert auf einer erweiterten endlichen Zustandsmaschine (Extended finite state machine), d.h. neben den
Zustandsdaten bei einer nichterweiterten Maschine existieren zustzlich Operationsdaten. Diese Operationsdaten
knnen whrend eines Zustandsberganges manipuliert werden, und der Wert von Operationsdaten kann den
Folgezustand bestimmen. Alle Maschinen sind unabhngig voneinander, knnen parallel laufen und
kommunizieren ber Signale. Jeder aktive Proze kann Signale senden und empfangen. Fr den Empfang von
Signalen hat jeder Proze einen FIFO-Speicher (First in first out), damit erfolgt die Kommunikation asynchron.
Ein SDL-System besteht aus vier Teilen:
Seiner Architektur oder auch statische Beschreibung genannt. Die Architektur besteht aus den Elementen
System, Block, Process und Procedur (Abbildung 7).
Der Beschreibung der Kommunikation, realisiert durch Signals, die ber Channels bzw. Signal routes
transportiert werden.
Der Beschreibung des dynamischen Verhaltens durch Prozesse und Prozeduren.
Der Definition von Operationsdaten in abstrakter Form und der zulssigen Operationen auf ihnen.
System A1
B lck_A
Blck_B
C 1
C 3
C 2
Block B lck_A
P 1
P 2
Prc_A1
Prc_A2
Process Prc_A2
State1
xy34a3
Pro_2
Pro_2
Procedure Pro_2
Environment
Abb. 7: Statische Struktur oder Architektur eines SDL-Systems
Kommunikationssoftware 10
In den folgenden Abbildungen wird die Spezifikation des Protokolls fr die SimpleDataLink gezeigt. Verwendet
wurde das Tool SDT3.0 der Firma Telelogic.
Abb. 8: Organizer-Oberflche und Diagrammstruktur des Systems SimpleDataLink
Abb. 9 a: Systemstruktur SimpleDataLink
Kommunikationssoftware 11
Abb.9 b,c,d: SDL.GR-Darstellung der Blcke DLUser und DLNetw und des Prozesses DLNetw
Kommunikationssoftware 12
Abb.9 e: SDL.GR-Darstellung des Prozesses DLUser
System SimpleDataLink;
/*Das ist die Protokollspezifikation einer einfachen Sicherungsschicht"SimpleDataLink".SimpleDataLink nutzt keinen Serviceprovider, sondern die paarenInstanzen senden die PDU's direkt */
SYNTYPE daten=integer ENDSYNTYPE;SIGNAL dlEstablishRq, dlEstablishIn, dlEstablishCf,dlDataRq(daten), dlDataIn(daten);SIGNAL dlUnitDataRq(daten), dlUnitDataIn(daten), dlReleaseRq,dlReleaseIn, dlReleaseCf;SIGNAL SABME, DISC, UA, I(daten), UI(daten), RR;
SIGNALLIST ASPsToUser=dlEstablishRq, dlDataRq,dlUnitDataRq, dlReleaseRq;SIGNALLIST ASPsFrUser=dlEstablishIn, dlEstablishCf, dlDataIn,dlUnitDataIn, dlReleaseIn, dlReleaseCf;SIGNALLIST ASPsToNetw=dlUnitDataRq;SIGNALLIST ASPsFrNetw=dlEstablishIn, dlDataIn, dlUnitDataIn,dlReleaseIn;SIGNALLIST PDUsToNetw= SABME, DISC, I, UI;SIGNALLIST PDUsToUser= UA,UI,RR;
channel C1FrEnv from env to DLUserwith (ASPsToUser);endchannel C1FrEnv;channel C3ToNetw from DLUser to DLNetwwith (PDUsToNetw);endchannel C3ToNetw;channel C2ToEnv from DLNetw to envwith (ASPsFrNetw);endchannel C2ToEnv;channel C3ToUser from DLNetw to DLUserwith (PDUsToUser);endchannel C3ToUser;channel C1ToEnv from DLUser to envwith (ASPsFrUser);endchannel C1ToEnv;channel C2FrEnv from env to DLNetwwith (ASPsToNetw);endchannel C2FrEnv;
block DLUser referenced;block DLNetw referenced;endsystem ;
Kommunikationssoftware 13
Block DLNetw;
CONNECT C3ToNetw AND P34;CONNECT C3ToUser AND P33;CONNECT C2ToEnv AND P22;CONNECT C2FrEnv AND P21;
signalroute P21 from env to DLNetwwith (ASPsToNetw);signalroute P33 from DLNetw to envwith (PDUsToUser);signalroute P22 from DLNetw to envwith (ASPsFrNetw);signalroute P34 from env to DLNetwwith (PDUsToNetw);process DLNetw referenced;endblock ;
Process DLNetw;
DCL daten daten;start ;nextstate state4 ;state state4 ;input dlUnitDataRq(daten) ;output UI(daten)via C3ToUser ;nextstate - ;input SABME ;output UA ;output dlEstablishIn ;nextstate state7 ;state state7 ;input UI(daten) ;output dlUnitDataIn(daten) ;nextstate - ;input I(daten) ;output dlDataIn(daten) ;output RR ;nextstate - ;input DISC ;output dlReleaseIn ;output UA ;nextstate state4 ;endprocess ;
Block DLUser;CONNECT C1FrEnv AND P11;CONNECT C1ToEnv AND P12;CONNECT C3ToNetw AND P31;CONNECT C3ToUser AND P32;
signalroute P11 from env to DLUserwith (ASPsToUser);signalroute P31 from DLUser to envwith (PDUsToNetw);signalroute P12 from DLUser to env
with (ASPsFrUser);signalroute P32 from env to DLUserwith (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 ;
Abb.9 f: SDL.GR-Darstellung des Systems SimpleDataLink
Kommunikationssoftware 14
TTCN - und der Test von Protokollen
Standardisierung und grundlegende BegriffeSeit Anfang der achtziger Jahre beschftigt man sich bei ISO sehr intensiv mit den Problemen des Testes vonProtokollsoftware. Es entstand ein umfangreicher Standard mit der Bezeichnung ISO9646: Informationtechnology - Open Systems Interconnection - Conformance testing methodology and framework. Dieser Standardbesteht aus sieben Teilen:
ISO9646-1: General concepts; Definition und Beschreibung verwendeter Begriffe und Konzepte. ISO9646-2: Abstract test suite specification; dieser Teil spezifiziert Anforderungen an abstrakte
Testsuites (Abstract test suite, ATS) und definiert Grundstrukturen fr Testsuites. ISO9646-3: The Tree and Tabular Combined Notation; hier wird die Syntax der Testnotation
beschrieben. ISO9646-4: Test realisation; spezifiziert Anforderungen und gibt Anleitung fr die Realisierung der
Testmittel (Means of testing, MOT). ISO9646-5: Requirements on test laboratories and clients for the Conformance Assessment Process;
beschreibt die Schnittstelle zwischen Testlabor und dem Kunden. ISO9646-6: Protocol profile test specification; spezifiziert Anforderungen und gibt Anleitung fr die
Erzeugung von Profilen fr den Test eines Protokolls. ISO9646-7: Implementation Conformance Statement; dieser Teil spezifiziert Anforderungen an
Konformittserklrungen fr eine Protokollimplementation.Dieser Standard ist, wie andere auch, eine anstrengende Lektre. Anstrengungen vermeidet man, indem man dieUrsache als fr nicht relevant deklariert. Viele mit Kommunikationstechnik befate Ingenieure werden sich dieserAusrede nicht bedienen knnen, denn zahllose Firmen (kleine, mittlere, groe) entwickeln und produzierenheutzutage Kommunikationstechnik. Damit steht am Ende immer die Zertifizierung und damit ISO9646. Der Testist damit keine Spezialdisziplin, sondern wird enger Bestandteil jeder Entwicklung.
Bevor auf TTCN eingegangen werden kann, mssen einige Grundbegriffe eingefhrt werden. In ISO9646-1 wird
die in Abbildung 10 grundlegende Testarchitektur definiert. Die Implementation Under Test (IUT) wird dabei als
Black-Box betrachtet. Der Test erfolgt durch Manipulation von Inputs und Beobachtung der resultierenden
Outputs. Inputs knnen dabei sowohl vom oberen als auch vom unteren Tester gesteuert werden. Outputs sind
ebenfalls ober- und unterhalb der IUT beobachtbar. Die virtuellen Punkte, wo Inputs gesteuert und Outputs
beobachtbar sind, nennt man Point of Control and Observation, PCO.
Imp lemen ta t i onUnder Tes t , I U T
P C O
P C O Abstract ServicePrimit ives, A S P ' s
Abstract ServicePrimit ives, A S P ' s,Protocol DataUnit's, P D U ' s
TESTER
Upper Tester , UT
Lower Tester , LT
Abb. 10: Grundlegende Testarchitektur
Aus der Abbildung geht hervor, da an PCOs oberhalb derIUT nur ASPs aber an PCOs unterhalb der IUT sowohlASPs und PDUs sichtbar sind. Wre die IUT beispielsweiseSimpleDataLink, dann wrden oberhalb die PrimitivesdlEstablishRq, dlDataRq, dlUnitDataRq, und dlReleaseRqsteuerbar sein. Alle anderen Primitives (siehe Abbildung 4)wren beobachtbar. Unterhalb der IUT wrde Physical seineDienste anbieten. Wenn SimpleDataLink unter Benutzungvon Physical seinem Partner eine PDU schickt, realisiert erdie durch den Dienst Datenbertragung, der durch das ASPphDataRq angefordert wird. ASPs mit denenDatenbertragungsdienste angefordert bzw. angezeigt werden,sind parametrisiert. Ein Parameter sind die PDUs desDienstnutzers. Damit lassen sich an PCOs die unterhalb derSchicht liegen, die gestestet werden soll, auch die PDUs derIUT beobachten und steuern.
Am Beispiel des Protokollstacks eines ISDN-Telefons, soll die Lage mglicher PCOs gezeigt werden (Abb. 11):
Kommunikationssoftware 15
T E S T E R
Serv ice Prov ider fo r Data L ink
S0-Interface
Cal l Cont ro l Agent
P C O
P C O
P C O
Call Control
P C O
P C O
P C O
P C O
Sys tem Under Tes t , SUT
P C O
m g l i c h e P C O ' sf r Lower Tes te r
m g l i c h e P C O ' sf r Uppe r Tes te r
N e t w o r k
Data L ink
Phys ica l
N e t w o r k
Data L ink
Phys ica l
I U T
ASP's
ASP's
ASP's,PDU's
ASP's,PDU's
ASP's,PDU's
ASP's,PDU's
ASP's
ASP's
Abb. 11: Mgliche Lage von PCOs
Die genauesten Aussagen ber eine IUT erhlt man dann, wenn der obere Tester Dienstnutzer (Service user) derIUT ist und der untere Tester der Dienstbereitsteller (Service provider) fr die IUT. Dieser Fall ist eigentlich nur inder Implementierungsphase und durch zustzlichen Aufwand gegeben. In realen Protokollstacks sind die vertikalenInterfaces, also dort wo PCOs sitzen sollten, nicht zugnglich. Die Protokolle der einzelnen Schichten werdendeshalb oft eingebettet getestet.
In ISO9646-2 werdengrundlegende Testmethodendefiniert. Es werden Szenarienfr den Test von Endsystemenund den Test von Relaissystemenbeschrieben. Fr Endsystemewerden vier Testmethoden fest-gelegt, die sich durch die Lagedes oberen und unteren Testersunterscheiden und dadurch, wiedie Koordinierung der beidenTester erfolgt.Diese Methoden, die inAbbildung 12 dargestelltwerden, nennt man: lokal (local, L), verteilt (distributed, D), koordiniert (coordinated, C). entfernt (remote, R).Ein Tester kann ein Gert, einProze innerhalb einer IUT odereine Kombination aus beidemsein.
Service Provider
I U T
P C O
U T
L T
P C O
Test Coord ina t ionP rocedu res , T C P
SUT
(Nb) b is (N t ) -PDU 's
(N t ) -ASP 's
(Nb -1 ) -ASP 's
Service Provider
I U T
L T
TM-PDU 's
P C O
Test ManagementProtocol
S U T
(Nb) b is (N t ) -PDU 's
U T
(Nb-1 ) -ASP ' s
L
C
Service Provider
I U T
L T
P C O
T C P
S U T
(Nb) b is (N t ) -PDU 's
U T
P C O
(Nb-1 ) -ASP ' s
(N t ) -ASP 's
Service Provider
I U T
L T
T C P
P C O
Test Coordinat ionProcedures
S U T
(Nb) b is (N t ) -PDU 's
U T
(Nb-1 ) -ASP ' s
D
R
Abbildung 12: Die vier grundlegenden abstrakten Testmethoden
Kommunikationssoftware 16
Jede der grundlegenden Methoden wird wieder danach unterschieden, ob das zu testende Protokoll einzelnvorliegt (single layer) oder ob das zu testende Protokoll in einen Stack eingebettet ist (single-layer embedded). Inder Testsuite wird die Methode angegeben, z.B. RS fr Remote Single layer oder RSE fr Remote Single layerEmbedded.Wenn man die Methoden bezglich Steuerbarkeit und Beobachtbarkeit der IUT bewertet, ist die entfernteTestmethode die schlechteste und dennoch die derzeit dominierende. Dies hat, wie bereits erwhnt, praktischeGrnde. Wenn beispielsweise ein ISDN-Telefon entwickelt wurde, ist der D-Kanal-Stack bezglich derSchichten 1 bis 3 zu testen. Der Test erfolgt schichtenweise, beginnend bei Physical. Ist diesesSchichtenprotokoll normenkonform, wird die Schicht 2 und danach die Schicht 3 getestet. In Abbildung 13 wirdein Testszenario, die Bildschirmanzeige eines Testfalles sowie auf die Realisierung der Koordinierungsfunktionzwischen unteren und oberen Tester eingegangen.
Bas ic Access Modu l
U T
S e r v i c e P r o v i d e r
Data L ink
L T
T C P
P C O
TestCoordinat ionProcedures
S U T
(Da taL ink ) -PDU 's
Phys ica l -ASP 's m i t Da taL ink -PDU's
Phys ica l
N e t w o r k
I U T
T e s t e r m i t L T
TIME SAPI TEI C/R Frame P/F NR NS
45'24743945'26963945'29570745'31141345'33345145'545666
TraceTraceTraceTraceTraceTrace
TEST GROUP :A.2.2.1.0 Initialisation96/7/4 15:27:45
TEST CASE :A.2.2.1.1 Test link establish request
allgemeineAngaben zumTestfall
45'70000148'95216048'96345348'99693349'02566649'04178549'07535449'10088949'12640049'138465
NetTraceNetUsrNetUsrNetUsrNetUsr
63 127 1 UI P=0 identity removeTNOAC expired0 127 1 UI P=0 Orig Q.931 1 SETUP63 127 0 UI P=0 identity request63 127 1 UI P=0 identity assigned0 69 0 SABME P=10 69 0 UA F=10 69 0 INFO P=0 0 0 Dest Q.931 1 REL_COM0 69 1 DISC P=10 69 1 UA F=1
Preamble:die IUT wird ineinen definiertenAnfangszustandgebracht
49'16833349'17865649'18767849'20200950'03477650'05410650'08800250'114666
TraceTraceTraceTraceUsrNtwUsrNet
=====================* body *=====================Please initiate a call !!!0 69 0 SABME P=10 69 0 UA F=10 69 0 INFO P=0 0 0 Orig Q.931 1 SETUP0 69 0 RR F=0 1
Das ist derTestkrper. Indiesem Fall wirder durch dasAbnehmen desHrers gestartet.
50'134212 Trace TEST CASE :A.2.2.1.1 VERDICT: PASS Auswertung undErgebnis
Abb. 13: Reales Testszenario (remote) mit kommentiertem Monitortext eines Testers
Kommunikationssoftware 17
An diesem Beispiel wird sichtbar, da der obere Tester (UT) eigentlich nicht existiert, sondern durch dieBenutzeroberflche des Telefons gegeben ist. Die Testkoordinierungsprozeduren werden durch Anweisungen aufdem 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.
Tree and Tabular Combined NotationTTCN, standardisiert in ISO9646-3, besteht aus einer grafischen Darstellung (TTCN.GR, graphical) und einermaschinenverarbeitbaren Form (TTCN.MP, machine processable). Mittels TTCN wird in der Regel der Testeines Schichtenprotokolls beschrieben. Die Gesamtheit dieser Beschreibung heit Testsuite. Eine Testsuitebesteht aus einer Menge von Tabellen, die der Entwickler, untersttzt von speziellen Tools, ausfllen mu. Inder Syntax wurden zwei Tabellentypen spezifiziert, die sogenannte Einzeltabelle zur Definition eines Objektesund die Mehrfachtabelle zur Definition gleichartig strukturierter Typen (Abbildung 14).
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 alleTestflle und Testschritte. Dieser Teil wird automatisch generiert. Der Entwurf einer Suite beginnt beimDeklarationsteil.
Deklarationsteil (Declaration part): dieser enthlt Typdefinitionen von DatenobjektenKonstantendefinitionen. Beispielsweise werden hier alle Timer definiert und mit Werten bzw.Wertebereichen versehen. Es werden alle ASPs (dlEstRq, phActIn usw.) deklariert und alle zuverwendenden PDUs (SETUP, ALERT, I-Frame, RR-Frame usw.) und ihre Struktur einschlielichInformationselemente (bearer capability, called party number, sending complete usw.) formal beschrieben.
Titel der TabelleKopf der Tabelle
Tabellenkrper
Tabellenfu
EINZELTABELLEObjektname:Zweck:Kommentar: dieser Teil kann entfallen
Spalte1 ... Spalte n ... KommentareKomponente 1Komponente 2
Komponente mErweiterte Kommentare: dieser Teil kann entfallen
Titel der TabelleTabellenkrper
Tabellenfu
MEHRFACHTABELLEObjektname ... Spalte n ... Kommentare
Objektbezeichner 1Objektbezeichner 2
Objektbezeichner nErweiterte Kommentare: dieser Teil kann entfallen
Kommunikationssoftware 18
Constraintsteil (Constraint part): hier werden, basierend auf den Konstanten- und Typdefinitionen desvorhergehenden Teils, die zu verwendenden Objekte beschrieben. Zum Beispiel werden verschiedeneSETUP-PDUs oder ALERT-PDUs usw. definiert. Diese werden dann als Input fr die IUT verwendet oderals 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 zulssigenOutputs. 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 bestimmteEigenschaften im Protokoll vorgesehen wurden. In der Protokollbeschreibung steht ja letztlich nur, WAS dasProtokoll 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 dasVerhalten, die Bewertung des Verhaltens und die Kommentierung zeilenweise notiert.Die horizontale bzw. vertikale Position eines Ereignisses wird als zeitliche Ordnung bzw. zur Angabe vonAlternativen benutzt. In Abbildung 15 sind zustzlich zwei Achsen eingezeichnet, die diese Ordnungreprsentieren sollen.Aus der TTCN-Sprachbeschreibung (ISO9646-3) werden nachfolgend die wesentlichsten TTCN-Anweisungen,Timeroperationen und Ausdrcke dargestellt (Abbildung 15).
Ereignis SyntaxSenden eines ASPs oder einer PDU von einem bestimmten PCO aus [PCO_Id] ! (ASP_Id | PDU_Id)
Implizites Senden eines ASPs oder einer PDU vom UT als Teil der IUT
Empfangen (erwarten) eines ASPs bzw. einer PDU an einem bestimmten
PCO
[PCO_Id] ? (ASP_Id | PDU_Id)
unerwartetes Ereignis, ist alles was nicht ausdrcklich im Testfall
beschrieben ist
[PCO_Id] ? OTHERWISE
Gehe zu Zeile mit dem Label (Marke) xyz GOTO Label
Benutze folgenden Testfall oder Testschritt (wie ein Unterprogrammaufruf)+ TreeReference
Starten eines Timers START Timer_Id [TimerValue]
Stoppen eines Timers CANCEL Timer_Id
Abfragen eines Timers READ Timer_Id
Empfang der Mitteilung: Timer abgelaufen ? TIMEOUT Timer_Id
Einer Variablen wird ein Wert zugewiesen (Var_Id ::= Wert)
Vergleichsoperation mit Entscheidung ber weiteren Verlauf [Var_Id Operator Var_Id|Const_Id]
Abb. 15: Die wichtigsten TTCN-Anweisungen, Timereroperationen und Ausdrcke
Die Anwendung von TTCN soll an dem Beispiel erfolgen , welches in Abbildung 13 dargestellt wurde. Dabei istzu beachten, da die nachfolgende Verhaltensbeschreibung nicht ganz vollstndig ist, da dies den Rahmen desBeitrages sprengen wrde.
Kommunikationssoftware 19
Test Case Dynamic BehaviorReference:Identifier: A.2.2.1.1Objective: Test link establish requestBehavior Description L V Constraint
ReferenceComments
12345678910111213141516171819202122232425262728293031323334353637383940
L!UI_M (RC::=0) START TNOAC L?UI_Mr (RC::=RC+1) CANCEL TNOAC [RCRCMax] +POSTAMBLE ?TIMEOUT TNOAC L!UI START TWAIT L?UI_Mr (CURRENT_TEI::=RANDOM(64,126) L!UI_M START TAC L?SABMEr CANCEL TAC (NS::=0,NR::=0) L!Uar START TAC L?Ir CANCEL TAC (NR::=(NR+1)MOD 128) L!DISC START TAC (NS::=0,NR::=0) L?UAr CANCEL TAC START TWAIT L?SABME CANCEL TWAIT (NS::=0,NR::=0) L!UA START TWL3 L?Icr (NR::=(NR+1)MOD 128) L!RR +POSTAMBLE ?TIMEOUT TWL3 +POSTAMBLE ?TIMEOUt TWAIT +POSTAMBLE ?TIMEOUT TAC +POSTAMBLE ?TIMEOUT TAC +POSTAMBLE ?TIMEOUT TAC +POSTAMBLE ?TIMEOUT TWAIT +POSTAMBLE
L2
F
P
P
P
P
F
F
F
F
F
F
UM_T6UM_T1
UI3UM(T1)
SA(P1)
UA(F1)
IN8
DI (P1)
UA(F1)
SA(P1)
SA(F1)
IN5
RRR
Lower Tester an IUT: TEI-Werte sind ungltig
IUT fordert neuen TEI-Wert (identity request)
der Tester antwortet nicht
die IUT fordert fter als RCMax neuen TEI-Wert
der Timer TNOAC ist abgelaufen, jetzt geht es weiter
es wird eine unvollstndige SETUP-Message gesendet
es wird ein identity request von der IUT erwartet
hier wird der TEI-Wert erzeugt
der TEI-Wert wird zugewiesen (identity assigned)
jetzt wird ein SABME erwartet
die Variablen NS, NR werden auf Null gesetzt
Verbindungsaufbau wird besttigt
jetzt wird ein I-Frame erwartet
der I-Frame ist gekommen, NR wird ermittelt
DISC wird an IUT geschickt und Timer TAC gestartet
NS und NR werden auf Null gesetzt
wenn das DISC mit UA quittiert wird , wird TAC gelscht
die IUT soll ein SABME schicken (Please initiate a call !!!)
wenn SABME kommt, wird TWAIT gelscht
NS, NR werden auf Null gesetzt
UA wird als Besttigung fr SABME gesendet
es wird ein I-Frame mit SETUP etrwartet,
NR wird ermittelt
und der I-Frame mittels RR-Frame quittiert
IUT wird zurckgesetzt und der Testfall bewertet
Timer TWL3 abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Timer TAC abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Timer TAC abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Timer TAC abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten
IUT wird zurckgesetzt und der Testfall bewertet
Abb. 16:Prinzip einer Verhaltensbeschreibung mittels TTCN fr das Beispiel in Abbildung 13
In dem gezeigten Testfall soll der Verbindungsaufbau von der IUT aus getestet werden. In der Pramble wirdzuerst der TEI-Wert zurckgezogen. Wenn die IUT eine automatische TEI-Zuweisung untersttzt, wird dieseversuchen, einen neuen TEI-Wert zu bekommen (Zeilen 2 bis 5). Der Lower Tester reagiert nicht darauf, zhltaber 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 SETUP-Nachricht (Zeile 8). Die IUT mu daraufhin, wenn sie standardkonform ist, einen TEI-Wert anfordern (Zeile 9),
Alter-nativen
Zeit
Kommunikationssoftware 20
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 ausabgebaut (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 3wird mit dem ASP dlEstablishRq den Aufbau der Schicht 2 veranlassen. Das erwartete Ergebnis ist in den Zeilen22 bis 27 dargestellt. Treten alle erwarteten Ereignisse ein, wird in Zeile 28 die Postamble abgearbeitet. In derPostamble werden Zustnde der IUT getestet, die IUT in einen definierten Zustand gebracht, alle Testaussagenbewertet und das Ergebnis pass, fail oder inconclusive ausgegeben.
AusblickDer Entwurf, die Entwicklung und der Test von Kommunikationssoftware wird durch formale Sprachen unddarauf basierenden Tools untersttzt. Die drei besprochenen Sprachen: MSC, SDL und TTCN sind semantischrelativ gut aufeinander abgestimmt, die Syntax ist aber sehr verschieden.Bei der Weiterentwicklung der Sprachen ist eine Eigendynamik zu beobachten, d.h. die Sprachen werden immermchtiger und wachsen in die Rolle von Sprachen fr die nchste Phase des Lebenszyklus hinein. Beispielsweisekann man mit SDL auch programmieren.Um der sogenannten Softwarekrise besser begegnen zu knnen, mu in der Ingenieurausbildung die Softwareeinen greren Raum einnehmen. Basierend auf den Grundlagen der Informatik und der Automatentheorie sindFachsprachen fr den Softwarelebenszyklus und ausgewhlte Werkzeuge dafr, Echtzeitbetriebssysteme sowiedas Management groer Softwareprojekte umfnglicher zu lehren.
Literatur[BAUMGIES] Bernd Baumgartner, Alfred Giessler: OSI-Testmethodik und TTCN
Berichte der GMD Nr.202, ISBN 3-468-22419-0[HALLMANN] Matthias Hallmann,: Prototyping komplexer Softwaresysteme
Teubner 1990; ISBN 3-519-02497-5[I-ETS 300 313] Interim ETSI-Standard: ISDN-DSS1;
Abstract Test Suite (ATS) for data link layer protocol for general application (user), ETSI 1995[ISO9646] ISO: Information technology - Open Systems Interconnection -
Conformance testing methodology and framework.[Z.12094] ITU-T: Message Sequence Chart (MSC); ITU 1994[Z.12096] ITU-T: Message Sequence Chart (MSC); ITU 1996[Z.10093] ITU-T: Specification and Description Language (SDL); ITU 1993
Autor:Prof. Dr.-Ing. habil. Lutz WinklerHochschule fr Technik und Wirtschaft Mittweida (FH), Fachbereich Elektrotechnik/Elektronik Technikumplatz 17, 09482 Mittweida 03727 581290FAX 03727 581420 win@htwm.de