Software developpement with SDL

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


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


Takte

B-Kanal

Takte

UpstreamDownstream

von/zur

Vermittlung


Anzeige,Tastatur,WeckerCall Control AgentCall Control Agent

Network

Data Link

Physical S- oder U-ControllerS- oder U-Controller

D-Kanal-ControllerD-Kanal-Controller



B-Kanal Takte

RechnerhardwareRechnerhardware FunktionalhardwareFunktionalhardware

FUNKTIONAL-SOFTWARE

PROTOKOLL-SOFTWARE

SUPPORT-SOFTWARE

EchtzeitbetriebssystemEchtzeitbetriebssystem

Abb.1: Hard-Software-Struktur eines ISDN-Telefons


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


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.


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;::={|



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.



Timer ::=||

::= set[,][


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


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


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


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


Abb.9 b,c,d: SDL.GR-Darstellung der Blcke DLUser und DLNetw und des Prozesses DLNetw


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 ;


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


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


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


U T

(Nb-1 ) -ASP ' s

L

C

Service Provider

I U T

L T

P C O

T C P

S U T


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


U T

(Nb-1 ) -ASP ' s

D

R

Abbildung 12: Die vier grundlegenden abstrakten Testmethoden


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


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


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.


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


Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten


Timer TAC abgelaufen, damit fehlerhaftes Verhalten






Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten


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


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 [email protected]

Software developpement with SDL

Documents

Transcript of Software developpement with SDL