SSW. Beschreibung P30308-X5875-A SICAT Entwicklungsumgebung für SDL und MSC. Methodenhandbuch SIEMENS AKTIENGESELLSCHAFT

Transkript

1 SSW Beschreibung P30308-X5875-A DOCDB Status: Retrieval Date: DOCDB Title: Kein Änderungsdienst SICAT Entwicklungsumgebung für SDL und MSC Methodenhandbuch Herausgegeben vom Bereich ÖN, Telekommunikationsnetze Hofmannstraße 51, D München Copyright Siemens AG 1997 SIEMENS AKTIENGESELLSCHAFT VerfasserIn: Dr. Georg Zeis MTSE4 ÜbersetzerIn: Mitteilung: A M Alle Rechte vorbehalten.

2 Neben den auf dem Deckblatt angegebenen VerfasserInnen haben an dieser Unterlage noch die folgenden Personen mitgearbeitet: Birgit Storath Gerd Höfner Sabine Mittrach Dieter Kolb Das Dokument umfaßt insgesamt 143 Seiten. Alle Seiten haben den Zustand 06. Das Dokument basiert auf dem Skelett MANUALG.DOT, Sachnummer P30305-W5299-A Die vorliegende Ausgabe wurde am :16 erstellt. Das Dokument wurde mit MS WinWord Version 6.0c bearbeitet. Der Pfadname des Hauptdokuments war E:\DOCTRANS\GERMAN\SDLMHB.DOC. P30308-X5875-A

3 INHALTSVERZEICHNIS 0 GENERELLE INFORMATION Zustands-Nachweis Historie Referenzen Begriffe und Abkürzungen Übersetzungstabelle Schlagwort / Deskriptor Verzeichnis für Bilder und Tabellen EINFÜHRUNG Ziel und Inhalt des Handbuches Entwicklungsmodell Modellierungssichten Entwicklungsumgebung für ÖN Beschreibungsmittel SDL und MSC ALLGEMEINGÜLTIGE ENTWURFSPRINZIPIEN ±2 - Gesetz (Gesetz von Miller) Hohe Kohäsion (Bindung) Lose Kopplung Modularisierung Hierarchisierung Abstraktion Möglichst hohes FAN IN Angemessenes FAN OUT Information Hiding Lokalität Einheitlichkeit SDL- UND MSC-KONZEPTE System- und Kommunikationsstruktur Dynamische Prozeßerzeugung Message Sequence Charts MSC-Basiselemente Strukturierungskonzepte im MSC SICAT-Abweichungen und -Erweiterungen von Z Prozeßverhalten SDL-Prozeß als endlicher Zustandsautomat SDL-Prozeßdiagramm Prozeduren und Makros Eingabeverhalten von SDL-Prozessen Adressierung von SDL-Prozessen SDL-Timerkonzept Nichtdeterminismus in SDL SDL-Wildcards Datendefinition, -strukturierung und -modellierung mit SDL P30308-X5875-A

4 INHALTSVERZEICHNIS 3.6 Erstellungskriterien für SDL- und MSC-Modelle Entwurfskriterien für das Systemdiagramm Entwurfskriterien für Substructure-Diagramme (Blockinteraktionsdiagramme) Entwurfskriterien für Blockdiagramme (Prozeßinteraktionsdiagramme) Entwurfskriterien für Prozeßdiagramme Entwurfskriterien für MSCs Entwurfskriterien für Sub-MSCs EINSATZ VON SDL/SICAT WÄHREND DES ÖN TN- ENTWICKLUNGSPROZESSES Analyse Entwurf Erstellen der E-Spec und der Prozeßdiagramm-Gerüste Codierung der Subsystemschnittstellen Entwurfsvalidierung mit dem SICAT-Simulator Prinzipien und Methoden systematischen Testens Testspezifikation und Vorbereitung der Testläufe mit dem SICAT-Simulator Testdurchführung mit dem SICAT-Simulator Auswerten der Ergebnisse Implementierung Phasenübergänge / Konsistenz Zusammenfassung des Vorgehens mit SDL/MSC Beispiel Beschreibung eines Systems zur Verarbeitung von Metallplatten Allgemeine Anmerkungen zu den Komponenten der Produktionszellen Beschreibung der Produktionszelle SDL-Spezifikation des Sytems zur Verarbeitung von Metallplatten Analyse Entwurfsvalidierung mit den SICAT-Simulator CM UND PRODUKTION VON SDL-CM-SOURCEN ANHANG SDL-Blockdiagramm-Symbolvorrat SDL-Prozeßdiagramm-Symbolvorrat und Wildcards MSC-Symbolvorrat SICAT-Abweichungen von Z.100 und Z VISION O.N.E CLIENT-SERVER-PRINZIP VISION O.N.E - Schalenmodell VISION O.N.E - Architektureinheiten (Structure-Units) Design Time - Units Modul Prozeß Region SPU und PIF Designeinflüsse und Regeln bei der Erstellung von SPUs Recovery Suite Tabellen und Übersichten Glossar P30308-X5875-A

5 INHALTSVERZEICHNIS 0 GENERELLE INFORMATION 0.1 Zustands-Nachweis Das Dokument umfaßt insgesamt 143 Seiten. Alle haben den Zustand Historie Zustand Datum Begründung der Änderung Umstellung auf WinWord und Anpassung an SICAT V14 Tabelle 1: Historie 0.3 Referenzen [1] F. Belina et al. SDL with Applications from Protocol Specification. Prentice Hall,Hemel Hempstead, [2] H.E. Binder, B. Schaffer. VISION O.N.E-Optimized Network Evolution. An Architecture for the Evolution of public Communication Networks into the universal Broadband ISDN. In: telcom report international, Vol. XIV, 12-19, [3] B.W. Boehm. Software Engineering Economics. Englewood Cliffs, [4] R. Braek, O. Haugen. Engineering Real Time Systems. Prentice Hall, Hemel Hempstead, [5] CCITT. SDL Methodology Guidelines Appendix I to Recommendation Z.100: Specification and Description Language (SDL). Report to the Plenary Assembly, June, [6] CCITT. Recommendation Z.100: Specification and Description Language (SDL). 'Nov., [7] CCITT. Recommendation Z.120: Message Sequence Chart (MSC). Geneva, March, [8] T. DeMarco. Structured Analysis and System Specification. Yourdon Press, N.Y., [9] H. Eggers. Software Technology for a Distributed Telecommunication System. In: Software Engineering ESEC `93. Springer-Verlag, [10] O. Faergemand, A. Olsen. New Features in SDL-92. In: CCITT SDL Newsletter Nr. 16, May [11] Hardware-Entwicklungshandbuch A50100-A0002-X100-*-0035, Nov [12] D. Hogrefe. Estelle, LOTOS und SDL. Springer-Verlag, Berlin, Heidelberg, N.Y., [13] G.A. Miller. The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information. The Psychological Review, Vol.63, No.2, P30308-X5875-A

6 INHALTSVERZEICHNIS [14] G. Myers. Composite/Structured Design. Van Nostrand Reinhold, N.Y., [15] M. Page-Jones. The Practical Guide to Structured Systems Design. 2nd Ed. Prentice Hall. N. J., [16] R. Saracco et al. Telecommunications Systems Engineering using SDL. North-Holland, Amsterdam, N.Y., Oxford, Tokyo, [17] SDL Toolset SICAT-Beschreibung. P30308-A0700-A , [18] Software Entwicklung mit SDL und zentraler Produktion. CASE Verfahren und Tools. P30308-A5858-A , 1994 [19] K. J. Turner (Hrsg.). Using Formal Description Techniques. An Introduction to ESTELLE, LOTOS and SDL. John Wiley & Sons, Chichester [20] Software-Entwicklungshandbuch EWSD (SW-EHB). P30305-X185-X , [21] Software-Entwicklungsprozeßplan (SEPP). P30305-X185-A1-9-35, [22] The Tree and Tabular Combined Notation. Interim Version of ISO DP 9646/3 [23] VISION O.N.E V9C System Architecture. P30308-A0243-B , [24] VISION O.N.E System Overall Concept Paper. P30308-A3019-A , [25] VISION O.N.E Software Structure Design Guidelines. P30308-X2837-A , [26] VISION O.N.E Published Interface Description. P30308-X2982-A , [27] A. I. Wasserman. Extending State Transition Diagrams for the Specification of Human- Computer Interaction. IEEE Trans. of Softw. Eng. 11, 8 (Aug.),1985. [28] E. Yourdon, L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and System Design. Prentice Hall. N.J., [29] V9C, CHILL Language and Compiler. P30308-A2737-A000-* Begriffe und Abkürzungen ADT ASN.1 CCITT EHB ERM E-Spec EWSD Abstrakter Datentyp Abstract Syntax Notation One Commite Consultatif International Telegraphique et Telephonique Entwicklungshandbuch Entity-Relationship-Modeling Entwurfsspezifikation Elektronisches Wählsystem Digital P30308-X5875-A

7 INHALTSVERZEICHNIS FA Functional Area FG Functional Group F-Spec Funktionsspezifikation FU Functional Unit HW Hardware IM Information Modeling ITU International Telecommunication LM Leistungsmerkmal MD Modular Design MSC Message Sequence Charts PIF Published Interface PF3 Productivity Facility 3 R-Spec Requirement Specification SA Structured Analysis SA/RT Structured Analysis/Real Time SD Structured Design SDL Specification and Description Language SDL-BD SDL-Blockdiagramm SDL-PD SDL-Prozeßdiagramm SEM State Event Matrix SP Structured Programming SPU Service Provision Unit STD State Transition Diagram SW Software VISION O.N.E VISION Optimized Network Evolution 0.5 Übersetzungstabelle Behaviour Cohesion Coupling Data Event Functional Area Functional Group Functional Unit Information Hiding Message Process Service Provision Unit State Overview Diagram Structure Verhalten Bindung, Zusammenhalt Kopplung Daten Ereignis Funktionsbereich Funktionsgruppe Funktionseinheit Geheimnisprinzip Botschaft, Nachricht Prozeß Dienstbereitstellende Komponente Zustandsübersichts-Diagramm Struktur P30308-X5875-A

8 INHALTSVERZEICHNIS 0.6 Schlagwort / Deskriptor entfällt 0.7 Verzeichnis für Bilder und Tabellen Abbildung 1-1: Die Säulen der Systementwicklung Abbildung 1-2: SW-Lifecycle nach Boehm [3] Abbildung 1-3: Ausschnitt des ÖV TN Software-Entwicklungsprozeßplans [20] Abbildung 1-4: Vollständige Systemsichten Abbildung 3-1: Typische SDL- und MSC-Hierarchie eines Systems Abbildung 3-2: SDL-Systemdiagramm Abbildung 3-3: SDL-Substructure-Diagramm Abbildung 3-4: Baumstruktur einer SDL-Systemspezifikation Abbildung 3-5: SDL-Prozeßinteraktionsdiagramm Abbildung 3-6: Beispiel für Instanzenbildung Abbildung 3-7: MSC-Basiselemente Abbildung 3-8: Dynamisches Erzeugen von Instanzen innerhalb eines MSC Abbildung 3-9: Verwendung von Timern Abbildung 3-10: Kommentare im MSC Abbildung 3-11: Conditions Abbildung 3-12: Coregion Abbildung 3-13: Sub-MSC (vgl. Abbildung 4.3) Abbildung 3-14: Komposition und Dekomposition von MSCs an "globalen Conditions" Abbildung 3-15: Komposition und Dekomposition von MSCs an "lokalen Conditions" Abbildung 3-16: SICAT-Meldungstypen Abbildung 3-17: Beispiel für ordered Connection Abbildung 3-18: Beispiel für unordered Connection Abbildung 3-19: Zustandsübersichtsdiagramm Abbildung 3-20: SDL-Prozeßdiagramm für den Zustandsautomaten in Abb Abbildung 3-21: Prozeßdiagramm von Prozeß P_1 aus Abb. 3.5 bzw. Abb Abbildung 3-22: SDL-Blockdiagramm (Prozeßinteraktionsdiagramm) Abbildung 3-23: Definition und Aufruf von konventionellen Prozeduren (SDL 88 und SDL 92) Abbildung 3-24: Definition und Aufruf von Value Returning-Prozeduren (SDL 92) Abbildung 3-25: Makrodefinition, Makroaufruf und Makroexpandierung Abbildung 3-26: Verwendung von Input- und Save-Symbolen Abbildung 3-27: Continuous Signal und Enabling Condition Abbildung 3-28: Input, Enabling Condition, Continuous Signal und Save Abbildung 3-29: Adressierungsmöglichkeiten in SDL Abbildung 3-30: Indirekte Adressierung: Abbildung 3-31: Adressierung mit TO Abbildung 3-32: Adressierung mit VIA Abbildung 3-33: Adressierung mit VIA ALL Abbildung 3-34: Zielangaben im Output-Symbol [4] Abbildung 3-35: Timer mit MSC und SDL Abbildung 3-36: Timer als endlicher Automat Abbildung 3-37: Nichtdeterminismus in SDL Abbildung 3-38: Verwendung von Wildcards Abbildung 3-39: SDL-Signale, -Nachrichten und -Datentypen Abbildung 3-40: Variablen- und Timerdefinition Abbildung 3-41: SDL-ADT "Warteschlange mit endlicher Länge" Abbildung 3-42: Verwendung von Synonym, Syntype und Array-Generator Abbildung 3-43: Komplexität und Anzahl der Prozesse Abbildung 3-44: Externe Zustände in Zustands- und nicht in Entscheidungssymbole! Abbildung 3-45: Wichtige Entscheidungen sollen von Signalen und nicht von Parametern abhängen! 3-40 Abbildung 3-46: Darstellungskonvention in Prozeßdiagrammen Abbildung 3-47: Erhöhung der Übersichtlichkeit durch Wildcards Abbildung 4-1: Entwurf mit SDL-und MSC-Diagrammen P30308-X5875-A

9 INHALTSVERZEICHNIS Abbildung 4-2: Die EHB-Phasen "Analyse", "Entwurf" und "Implementierung" Abbildung 4-3: Hierarchisierung von Systemen in Functional Areas, Functional Groups und Functional Units Abbildung 4-4: Systemebenen und -sichten, die innerhalb der F-Specs behandelt werden Abbildung 4-5: E-Spec-SDL-Blockdiagramm (Prozeßinteraktionsdiagramm) Abbildung 4-6: "Funktionale" Prozeßdiagramme oder Prozeßdiagramm-Gerüste Abbildung 4-7: Entwurfsvalidierung mit SICAT [17] Abbildung 4-8: Zusammenfassung -F-Spec Level 0, Level 1, Level 2, E-Spec u. Impl Abbildung 4-9: SDL- Einsatz in Analyse, Entwurf und Implementierung Abbildung 4-10: Vertikale und horizontale Integrität Abbildung 4-11: SDL-Engineering Strategie: Top down - Vorgehen Abbildung 4-12: SDL/MSC-Methodik im EHB Abbildung 4-13: Überblick über das System zur Verarbeitung von Metalllplatten Abbildung 4-14: Vollständiger Zyklus in der Produktionszelle Abbildung 4-15: Systemdiagramm des Systems "Produktionszelle" Abbildung 4-16: MSC der Signalisierung zwischen den Functional Areas des Gesamtsystems Abbildung 4-17: Substructure-Diagramm der Zelle1 - Unterteilung in Functional Groups Abbildung 4-18: MSC eines Verarbeitungszyklus der Functional Groups in Zelle Abbildung 4-19: Gemeinsame Aktionseinheiten der Functional Groups in Zelle Abbildung 4-20: Blockdiagramm der FG "Roboter" - Unterteilung in Functional Units Entwurf Abbildung 4-21: Prozeßinteraktions-Diagramm der FU "RO_MANAG" Abbildung 4-22: Prozeßinteraktions-Diagramm der FU "RO_UNIT" Abbildung 4-23: Meldungsablauf zwischen den Prozessen der FU "RO_UNIT" Abbildung 4-24: Prozeßdiagramm von Prozeß RO_MAN Abbildung 4-25: Prozeßdiagramm von Prozeß "ARM_UN" Abbildung 4-26: Prozeßdiagramm von Prozeß "ZB_GEN" Abbildung 4-27: Prozeßdiagramm von Prozeß "PR_MAN" Abbildung 4-28: State-Event-Table von Prozeß "ARM_UN" Abbildung 6-1: Client-Server-Modell Abbildung 6-2: SPU mit einem Service und SPU mit mehreren Services Abbildung 6-3: Schalenmodell der VISION O.N.E-Systemarchitektur Abbildung 6-4: VISION O.N.E: Lifecycle-Ausschnitt Abbildung 6-5: Abbildung eines Elementarmoduls auf SDL Abbildung 6-6: Modellierungsaspekte eines Moduls Abbildung 6-7: Abbildung der Prozeßstruktur auf SDL Abbildung 6-8: Modellierungsaspekte eines Prozesses Abbildung 6-9: Abbildung der Region-Struktur auf SDL Abbildung 6-10: Modellierungsaspekte einer Region Abbildung 6-11: SPU als Sichtbarkeitsgrenze (Visibility Border) [25] Abbildung 6-12: Unterschiedliche Views beim SPU-Entwurf Abbildung 6-13: SDL/MSC-Modellierung von SPU und PIF Abbildung 6-14: Modellierungsapekte von SPU und PIF Abbildung 6-15: Vision O.N.E - Architekturhierarchie Abbildung 6-16: Klassifizierung der VISION O.N.E - Architektureinheiten Abbildung 6-17: Quickreferenz-Guide "Konventionelle Vermittlungs-Software" Abbildung 6-18: Quickreferenz-Guide "VISION O.N.E. Software" Abbildung 6-19: Quickreference-Guide "SDL/MSC-Methodik" Tabelle 1: Historie P30308-X5875-A

10 Einführung 1 Einführung Das MHB basiert auf den CCITT Z.100 Recommendations aus dem Jahr 1992 für SDL (ohne die objektorientierten Konzepte) und auf den Z.120 Recommendations aus dem Jahre 1993 für MSC. ITU/TS ist die neue Bezeichnung für das CCITT (Comitee Consultativ International Telegraphique et Telephonique). SDL (Specification and Description Language) hat für die Telekommunikation eine lange Tradition. Seit 1976 wird von der ITU (vormals CCITT) alle vier Jahre eine genormte Sprachbeschreibung von SDL herausgegeben. Die jüngste SDL-Norm (Z.100 Recommendations) stammt aus dem Jahr 1992 ("SDL 92") und berücksichtigt auch Paradigmen der Objektorientierung. Die ursprüngliche Intention des CCITT war es, eine grafische Entwurfssprache für rechnergestützte Vermittlungssysteme zu definieren. Deshalb ist SDL besonders auf verteilte und nebenläufige Systeme zugeschnitten. SDL kann aber für die Beschreibung beliebiger ereignisorientierter und auf Nachrichtenaustausch basierender Systeme eingesetzt werden. Z.B. für die Modellierung von Fertigungs- und Automatisierungssystemen, aber auch für den Entwurf von Dialogschnittstellen. Sehr eng mit SDL verbunden sind Message Sequence Charts (MSC). Sie ermöglichen es dynamische Ablauf- und Kommunikationsszenarien zu modellieren. Der Einsatz einer Methode beinhaltet aber mehr als nur eine Verwendung als (grafisches) Beschreibungsmittel. Eine Methode ist vielmehr eine begründete Vorgehensweise zur Erreichung eines Zieles. Ein Entwickler, der eine Methode "händisch" einsetzt, erreicht niemals die Effizienz eines Entwicklers, der eine Methode mit einem geeigneten (Case-)Werkzeug verwendet. Den vollen Nutzen von Methoden erhält eine Institution, die Systeme entwickelt, aber nur, wenn neben geeigneten Werkzeugen ein definiertes Vorgehensmodell existiert, das genau regelt, welche Methode zu welcher Phase des Systemerstellungsprozesses eingesetzt werden soll (s. Abbildung 1-1). Systementwicklungsprozeß unterstützt durch... Methoden und ingenieurmäßiges Vorgehen unterstützt durch... Werkzeuge und automatisierte Abläufe Abbildung 1-1: Die Säulen der Systementwicklung P30308-X5875-A

11 Einführung Bei ÖN liegen für die Software- und für die Hardware-Entwicklung ausgereifte Vorgehensmodelle mit definierten Meilensteinen und Phasenergebnissen vor, die für die Entwickler verbindlich sind. Für die Software-Entwicklung gilt das Software-Entwicklungshandbuch (SW-EHB) [20], für Hardware-Entwicklungen das Hardware-Entwicklungshandbuch (HW-EHB) [11]. Die Verwendung von SDL und MSC wird bei ÖN durch das Werkzeug SICAT unterstützt. SICAT ist eine ÖN-Eigenentwicklung. Das vorliegende Methoden-Handbuch ergänzt das bei TN EP gültige SW-EHB und soll einem SDL- und MSC-Anwender helfen, qualitativ hochwertige Telekommunikationssysteme zu entwickeln. Beispielhaft wird auf VISION O.N.E im Anhang eingegangen. 1.1 Ziel und Inhalt des Handbuches Trotz der Nähe zum Anwendungsgebiet Telekommunikation zeigt das Handbuch, wie SDL und MSC allgemein, d.h. auch für andere Anwendungsgebiete, eingesetzt werden können. Nichtsdestoweniger sind aber die Ersteller von Telekommunikations-Software die Zielgruppe dieses Handbuches. Hier sind zum einen die Entwickler zu nennen, aber auch die Systems- Engineering-Abteilung, die für die Entwicklung den Grobentwurf von Vermittlungssystemen bereitstellt. Das Handbuch bietet eine methodische Unterstützung für den Gebrauch des Werkzeuges SICAT, ersetzt aber nicht die Bedienungsanleitung des Werkzeugs. Intention des Methoden-Handbuches ist es zu beschreiben, wie SDL für die Modellierung von Telekommunikationssystemen verwendet werden kann. In Kapitel 2 des MHB werden allgemeingültige Entwurfsprinzipien angegeben, die für jeden Typ von Systemen relevant sind. In Kapitel 3 werden SDL- und MSC-Konzepte vorgestellt. Kapitel 3 ermöglicht einem Leser einen Überblick über die Darstellungs- und Sprachmittel von SDL bzw. MSC zu erhalten. Es werden nicht alle vorgestellten SDL-Konstrukte von SICAT unterstützt. Grundlage für den Einsatz von SICAT und SDL bei ÖN ist das Software-Entwicklungshandbuch (SW-EHB). Die mit SICAT erzeugten SDL-Dokumente müssen konform dem EHB sein. D.h. es muß festgelegt sein an welchen Stellen im Konzeptpapier, in der Requirement Specification (R- Spec), in der Funktionsspezifikation (F-Spec) und in der Entwurfsspezifikation (E-Spec) SDLund MSC-Dokumente verwendet werden können. In Kapitel 4 wird beschrieben, an welchen Stellen im EHB SDL- und MSC-Diagramme eingesetzt werden können. Weiterhin wird in Kapitel 4 das methodische Vorgehen bei der Systemmodellierung mit SDL und MSC an einem Beispiel schrittweise erläutert. Kapitel 5 enthält einen Verwies auf eine ÖN-Richtlinie, die das Einbringen von SDL- Dokumenten in den CM-Pool und Produktonsverfahren von SDL-CM-Sourcen beschreibt. Der Anhang (Kapitel 6) enthält neben zusammenfassenden Übersichten der SDL- und MSC- Symbolvorräten ein Unterkapitel, das diverse Abweichungen innerhalb von SICAT gegenüber den Normen Z.100 und Z.120 beschreibt. Weiterhin wird im Anhang gezeigt, wie VISION O.N.E-Architektureinheiten mit den Sprachmitteln von SDL modelliert werden können. Darüberhinaus enthält der Anhang Tabellen und Diagramme, die als Quickreferenceguide für Entwickler gedacht sind. Der Anhang endet mit einem Glossar. P30308-X5875-A

12 Einführung Das Handbuch beschreibt in einer ersten Version den Einsatz von SICAT und SDL für die EHB- Phasen Analyse, Entwurf und Implementierung. In nachfolgenden Versionen des Handbuchs werden die Phasen Integrations- und Systemtest behandelt, sowie Ergänzungen vorgenommen. Grundlage für das Handbuch sind für SDL die Z.100 Recommendations aus dem Jahr 1992 (SDL 92) [6], allerdings ohne die objektorientierten Konzepte, und für MSC die Z.120 Recommendations von 1993 [7]. 1.2 Entwicklungsmodell Das SW-EHB unterteilt die Softwareentwicklung in Entwicklungsphasen, die voneinander durch sogenannte Baselines abgetrennt sind. Im EHB ist festgelegt welche Ergebnisse am Ende jeder Phase vorliegen müssen und welche Tätigkeiten innerhalb einer Phase notwendig sind, um diese Ergebnisse zu erhalten. Meilensteine, die innerhalb einer Phase eingebettet sind, ermöglichen eine effektive Projektverfolgung. Z.B. bedeutet in der Analysephase der Meilenstein M110, daß die R-Spec (Pflichtenheft) vorliegt, und der Meilenstein M140, daß die LM-Blätter und die F-Spec erstellt wurden. Eines der ersten Phasenmodelle, das den Lebenszyklus (engl. "Lifecycle") eines Softwareprojektes darstellt, ist das Wasserfallmodell von Barry Boehm [3]. Dieses auch heute noch aktuelle Modell teilt den Entwicklungsprozeß in die Hauptphasen Analyse, Entwurf und Implementierung (s. Abbildung 1-2 ). informelle Problembeschreibung Analyse Anforderungsdefinition Entwurf formale Spezifikation Implementierung ablauffähiges Programm Test getestetes Programm Installation, Wartung Abbildung 1-2: SW-Lifecycle nach Boehm [3] In der Analyse werden die Anforderungen (Requirements) an das zu erstellende System oder zu entwickelnde Produkt bestimmt. Im Entwurf werden die Teilkomponenten des zu erstellenden Systems, die Kommunikationsstruktur zwischen den Teilkomponenten, sowie ihr funktionales Profil festgelegt. In der Implementierung erfolgt die Realisierung der Teilkomponenten und ihre Integration in das Gesamtsystem. Im Laufe der Jahre entstanden neue Phasenmodelle wie das Prototypingmodell und das Spiralmodell. Aber nahezu alle Phasenmodelle haben ihren Ursprung im klassischen Wasserfall- P30308-X5875-A

13 Einführung modell. Auch das EHB basiert auf dem Wasserfallmodell. Das EHB sieht folgende sechs Entwicklungsphasen vor: 1. Analyse 2. Entwurf 3. Implementierung 4. Integrationstest 5. Systemtest 6. Einsatz Im vorliegenden Methodenhandbuch wird die Verwendung von SDL und MSC für die Phasen Analyse, Entwurf und Implementierung beschrieben. Abbildung 1-3 zeigt einen Ausschnitt des Software-Entwicklungsprozeßes für ÖN mit Baselines (definierte Phasenendpunkte) und den Entwicklungsdokumenten, die die Schnittstellen zwischen den Phasen darstellen. Nach Beendigung der Analysephase ist z.b. die Baseline B200 erreicht. Die Dokumente Konzeptpapier, Requirement-Specification und Functionsspecification sind Output der Analyse und Input für den Entwurf. Die einzelnen Entwicklungsdokumente sind innerhalb einer Phase Ergebnisse entsprechender Meilensteine. In Abbildung 1-3 sind nur solche Entwicklungsdokumente aufgeführt, die SDL- und MSC-Dokumente enthalten können. Entwicklungsanstoß Leistungsmerkmalanforderungen Analyse B200 "Entwicklungsauftrag" Konzeptpapier Requirement Spezifikation Funktionsspezifikation Entwurf B300 "Entwurfsvollständigkeit" Entwurfsspezifikation Bei Phasenende erreichte Baselinei Implementierung B400 "Implementierungsvollständigkeit" Testspezifikation Testfälle Abbildung 1-3: Ausschnitt des ÖV TN Software-Entwicklungsprozeßplans [20] 1.3 Modellierungssichten Eine vollständige Beschreibung eines Systems umfaßt mehrere Gesichtspunkte (s. Abbildung 1-4 ). Nicht nur die Funktion, die Daten und das Verhalten bestimmen ein System. Ein System muß auch auf seine Struktur (Modularisierung und Hierarchisierung), auf kommunikative Gesichtspunkte (Datenaustausch zwischen Systemkomponenten und zwischen Systemkomponenten mit der Systemumgebung) sowie auf die Erscheinungsform des Systems einem Benutzer gegenüber untersucht werden (Benutzerschnittstelle). Die Funktionssicht betrachtet die funktionalen Anforderungen die an ein System gestellt werden, d.h. sein funktionales Profil. P30308-X5875-A

14 Einführung Die Struktur eines Systems (Aufteilung in Komponenten und Hierarchieebenen) legt die statische Systemarchitektur fest. Die stabilsten Elemente im Lebenscyclus eines Systems sind die Daten. Sie dürfen daher nicht vernachlässigt werden. Systeme besitzen nicht nur statische, sondern auch dynamische Aspekte. Zu den dynamischen Aspekten zählen das Systemverhalten und die Reihenfolge des Datenflusses innerhalb eines Systems und zwischen System und Umgebung (dynamische Kommunikation). Die statische Kommunikationssicht beschreibt nur die Schnittstellen von Systemkomponenten. Sie macht im Gegensatz zur dynamischen Kommunikationssicht keine Aussage über dynamische Meldungsabläufe. Ergonomische Untersuchungsergebnisse und Regeln für ergonomisch gestaltete Benutzerschnittstellen existieren zwar schon seit einigen Jahren, aber leistungsfähige Userinterface- Builder, die es erlauben Benutzeroberflächen sehr schnell zu erstellen, machen die Gestaltung der Benutzerschnittstelle immer mehr zu einem eigenen Aspekt im System Engineering [27]. In Abbildung 1-4 ist angedeutet, mit welchen Methoden bzw. Beschreibungsmitteln die einzelnen Systemaspekte modelliert werden können. Einsatzmöglichkeiten von SDL- und MSC- Dokumenten sind grafisch hervorgehoben. SDL- Blockdiagramm Message Sequence Charts SDL- Blockdiagramm Message Sequence Charts SDL- Prozeßdiagramm Benutzerschnittstelle 4.3 Kommunikation 3.3, 4.1, 4.3 Structured Analysis / Realtime Funktion 3.2, 4.4.2, System 4.4, 4.6.3, Verhalten SDL- Prozeßdiagramm Structured Analysis SDL- Blockdiagramm Message Sequence Charts Struktur 3, 4.6.1, 4.6.2, Daten 4.5 SDL- Blockdiagramm Modular Design Structured Design Information Modeling Entity Relationship Modeling SDL-Abtract Data Type Abstract Syntax Notation One Abbildung 1-4: Vollständige Systemsichten 1.4 Entwicklungsumgebung für ÖN Das Methoden-Handbuch soll den Gebrauch des SDL-Werkzeuges SICAT unterstützen. SICAT gehört zur Softwareausstattung des SAP/3 (Softwarearbeitsplatz/3). Der SAP/3 umfaßt einen PC mit dem Betriebssystem OS/2. Zur Dokumentation steht im SAP/3 das Werkzeug PF3 (Productivity Facility 3) zur Verfügung. Alle in SICAT erzeugten SDL-Diagramme müssen sich in PF3-Dokumente integrieren lassen. P30308-X5875-A

15 Einführung 1.5 Beschreibungsmittel SDL und MSC SDL (Specification and Description Language) ist eine Entwurfsmethode [5] und eine Spezifikationssprache [6], die sich hervorragend zur Beschreibung von ereignisorientierten bzw. auf Nachrichtenaustausch basierenden Systemen eignet. SDL ist von ITU genormt (Z.100 Recommendations) [6] und hat sich als die Standardentwurfsmethode im Bereich der Telekommunikation etabliert. Auch die Sprachbeschreibung für MSC (Message Sequence Charts) ist von ITU genormt (Z.120 Recommendations) [7]. Mit MSCs läßt sich der zeitliche Kommunikationsablauf zwischen Systemkomponenten untereinander bzw. zwischen Systemkomponenten und der Umgebung darstellen. In einem Message Sequence Chart wird i.a. nicht das vollständige Kommunikationsverhalten eines Prozesses bzw. eines Systems dargestellt, sondern jeweils nur ein bestimmtes Kommunikationszenario. Ein SDL-Prozeßdiagramm beschreibt dagegen immer das vollständige Verhalten eines Prozesses. Neben der grafischen Darstellungsweise existiert für SDL und MSC auch eine äquivalente textuelle Darstellungsform in einer programmiersprachenähnlichen Notation. Aus Verständnisgründen wird im Handbuch die grafische Form der textuellen vorgezogen. Die textuelle Form wird hauptsächlich als Ausgabeformat und als Basis für die elektronische Weiterverarbeitung verwendet. P30308-X5875-A

16 Allgemeingültige Entwurfsprinzipien 2 Allgemeingültige Entwurfsprinzipien In der Systementwicklung haben sich eine Reihe von Prinzipien und Richtlinien etabliert, die einem Systementwickler helfen sollen zuverlässige, verständliche und wartungsfreundliche Systeme zu erstellen. Die in diesem Kapitel vorgestellten Prinzipien basieren hauptsächlich auf den Gedanken von Structured Design [14, 15, 28] ±2 - Gesetz (Gesetz von Miller) Nach dem Gesetz von Miller [13] steigt die Fehlerrate beim Menschen beträchtlich an, wenn er sich mit mehr als 7±2 Dingen gleichzeitig beschäftigt. Für den Softwareentwurf ergibt sich daraus die Forderung, daß modulare und hierarchische Zerlegungen diesen Bereich nicht überschreiten sollen. 2.2 Hohe Kohäsion (Bindung) Der Inhalt eines Teilsystems, Moduls oder Prozesses darf nicht zufällig sein, sondern muß eine gewisse innere Festigkeit aufweisen [14, 15, 27]. Diese Modulfestigkeit wird durch den Begriff Kohäsion ausgedrückt und soll möglichst hoch sein. Dem Lokalitätsprinzip entsprechend, müssen sich Elemente, die in einem Problembereich zusammen gehören, auch im Modell im gleichen Modul wiederfinden lassen. Kohäsion ist der Zustand, der die Elemente eines Moduls zusammenhält. Es gibt eine Reihe von Kohäsionsausprägungen, die sich in ihrer Qualität unterscheiden. Die funktionale Festigkeit ist die höchste Form von Kohäsion. Ein Modul mit funktionaler Kohäsion führt eine einzige genau spezifizierte Funktion aus, die sich kurz und prägnant beschreiben läßt. Mit Funktion ist nicht die Funktion aus mathematischer Sicht gemeint, die eine Zuordnungsvorschrift von einem Wertebereich in einen anderen Wertebereich definiert, sondern Funktion bedeutet im Sprachgebrauch des MHB eine Aufgabe oder Operation, die nicht unbedingt einen Rückgabewert liefert. Unter Modul wird eine softwaretechnische Strukturierungseinheit verstanden, die lokale Daten und Funktionen enthält. Die schlechteste Form von Kohäsion ist die zufällige Kohäsion. Bei ihr lassen die Elemente eines Moduls keinen sinnvollen Zusammenhang erkennen. Die funktionale Kohäsion ist zwar die höchste Stufe der Kohäsion, aber bei ihrer konsequenten Beibehaltung würde ein System aus einer Unmenge von Modulen bestehen, die alle jeweils nur für eine Funktionen verantwortlich sind. Bei der Bildung von Modulen ist deshalb die informative Kohäsion anzustreben. Die informative Kohäsion faßt die Funktionen, die auf der gleichen Datenstruktur arbeiten, in einem Modul zusammen. Die informative Kohäsion ist ein wichtiges Entwurfskriterium bei der Bildung von abstrakten Datentypen (ADTn) und ein wesentlicher Aspekt der Objektorientierung. 2.3 Lose Kopplung Während sich die Kohäsion mit dem Innenleben eines Teilsystems, Moduls oder Prozesses beschäftigt, bezieht sich die Kopplung auf die Beziehungen zwischen zwei Teilsystemen, Modulen oder Prozessen. Die intramodularen Zusammenhänge sollen möglichst hoch, die intermodularen Zusammenhänge so gering wie nötig sein. Lose Kopplung ist ein Hinweis auf ein gut strukturiertes System. P30308-X5875-A

17 Allgemeingültige Entwurfsprinzipien Durch lose Kopplung wird die Wartbarkeit der Module erleichtert, da keine internen Details von anderen Modulen dafür benötigt werden. Weiterhin wird durch lose Kopplung der "Ripple"-Effekt unterdrückt, nämlich, daß ein Fehler in einem Modul als Symptom eines anderen Moduls erscheint. Die Kopplung wird durch die Art und durch die Anzahl der Übergabeparameter bestimmt. Die Parameteranzahl soll die 7±2-Grenze nicht überschreiten. Werden einzelne Übergabeparameter zu einer Datenstruktur zusammengefaßt, müssen die Parameter einen sinnvollen Zusammenhalt erkennen lassen. Durch zufälliges Zusammenfassen von einzelnen Übergabeparametern zu Übergabestrukturen, wird zwar die offizielle Anzahl der Übergabeparameter verkleinert, die Kopplung aber in Wirklichkeit verschlechtert. Durch das Zusammenfassen von Parametern zu Strukturen wird die Gefahr des Einschleichens von "Trampdaten" gesteigert. Trampdaten sind Daten, die durch ein System gereicht werden, ohne gebraucht zu werden. Trampdaten verschlechtern die Wartbarkeit und vergrößern die Fehleranfälligkeit. Genauso wie bei der Kohäsion existieren unterschiedliche Kopplungsarten, die sich in ihrer Qualität unterscheiden. Datenkopplung (Data Coupling) ist die beste Bindungsform. Zwei Module sind durch Datenkopplung miteinander verbunden, wenn sie direkt miteinander kommunizieren, d.h. wenn sie sich gegenseitig explizit aufrufen und ihre Übergabeparameter homogene Datenstrukturen sind. Homogene Datenstrukturen sind elementare Datentypen oder Felder von elementaren Datentypen. Die schlechteste Kopplungsart ist das Inhaltskopplung (Content Coupling). Bei der Inhaltskopllung nimmt ein Modul direkt auf das "Innenleben" eines anderen Moduls Bezug oder manipuliert es. Kopplung und Kohäsion hängen eng zusammen. Je größer die Kohäsion der einzelnen Module, desto geringer ist das die Kopplung zwischen ihnen. Die Erfassung intramodularer Zusammenhänge ist aber weniger aufwendig, als die Untersuchung der Beziehungen zwischen Moduln. Daher soll man sich beim Entwurfsprozeß primär auf die Kohäsion konzentrieren [28]. 2.4 Modularisierung Zerlegung eines Systems in Teilsysteme, um die Komplexität des Gesamtsystems zu verringern. Wenn die Beziehungen zwischen Teilsystemen aber stärker sind, als die Beziehungen zwischen Komponenten innerhalb eines Teilsystems, wird die Komplexität des Gesamtsystems nicht vermindert, sondern noch vergrößert. Um diesen Effekt zu verhindern, muß eine Modularisierung nach gewissen Kriterien erfolgen. So soll jedes Teilsystem (jedes Modul) eine in sich abgeschlossene Aufgabe beinhalten. In sich abgeschlossene Aufgaben und getroffene Entwurfsentscheidungen dürfen nicht auf mehrere Module verteilt werden. Änderungen in einem Modul sollen möglichst keine Änderungen in anderen Modulen nach sich ziehen (Prinzip der gegenseitigen Nichtbeeinflussung). 2.5 Hierarchisierung Hierarchische Zerlegungen erleichtern wesentlich die Überschaubarkeit von Systemen. Die Hierarchisierung (vertikale Aufteilung eines Systems in Ebenen) soll genauso wie die Modularisierung (horizontale Zerlegung in Teilsysteme) dem begrenzten menschlichen Auffassungsvermögen entgegen kommen. Durch Hierarchisierungen müssen Abstrak- tionsebenen geschaffen werden, deren Elemente durch ihren jeweiligen Abstraktionsgrad bestimmten Benutzeranforderungen genügen. Genauso wie die Modularisierung muß auch die Hierarchisierung nach gewissen Regeln erfolgen. So ist es z.b. nicht sinnvoll 100 Module so zu strukturieren, daß 99 von ihnen direkt unterhalb eines "Chef-Moduls" angeordnet sind. Eine solche "short and fat"- Hierarchie, bei der ein Übergeordnetes Modul alle restlichen direkt koordinieren und integrieren muß, ist genauso zu verwerfen wie eine "tall and lean"-hierarchie, bei der die Module so angeordnet sind, daß jedes höchstens eines direkt unter sich hat. Die Tiefe (Anzahl der Hierarchieebenen) einer hierarchischen Zerlegung muß genauso wie ihre Breite (durchschnittliche Anzahl P30308-X5875-A

18 Allgemeingültige Entwurfsprinzipien der Elemente pro Schicht) übersichtlich bleiben. In der Literatur wird vorgeschlagen, daß die Tiefe und die Breite den Bereich 7±2 nicht überschreiten sollen[15, 27]. Die oberen Schichten einer Hierarchie sollen für Kontroll- und Koordinierungsaufgaben verantwortlich sein, während die unteren Schichten Berechnungs- und Ausführungsaufgaben übernehmen sollen. Dementsprechend sollen Elemente höherer Ebenen mit logischen Daten arbeiten und Elemente tieferer Ebenen mit physikalischen Daten. Diese Regel wird im Zusammenhang mit Structured Design als Balancing bezeichnet (in der strukturierten Analyse (SA) hat Balancing eine andere Bedeutung). Entscheidend für eine strukturierte und konsistente Hierarchisierung ist die konsequente Beibehaltung der Beziehung zwischen den Elementen unterschiedlicher Hierarchieebenen. Für die Softwaretechnologie typische Hierarchiebeziehungen sind die "besteht aus"-relation und die "ruft auf"-relation. In der Vermittlungstechnik übliche Hierarchiebeziehungen sind die "besteht aus"-relation und die "beauftragt mit"-relation. 2.6 Abstraktion Unter Abstraktion versteht man die Reduktion auf das Wesentliche und das Verallgemeinern vom Konkreten. Der Abstraktionsprozeß soll die markanten und wichtigen Eigenschaften von Systemen, Teilsystemen und Vorgängen liefern. Dies ist Voraussetzung für die Zerlegung eines umfangreichen, komplexen Problemes in einfache, separate Einheiten. Abstraktion ist somit die Voraussetzung für Modularisierung und Hierarchisierung. Es gibt unterschiedliche Arten von Abstraktion. Von funktionaler Abstraktion spricht man, wenn von der Arbeitsweise eines Algorithmus oder eines Vorgangs abstrahiert wird. Bei der funktionalen Abstraktion interessiert nur die Wirkung (das Was) eines Operationsaufrufs und nicht seine Realisierung (das Wie). Wenn neben den Algorithmen der Operationen noch zusätzlich von der konkreten Darstellung der Daten abstrahiert wird, auf denen die Operationen arbeiten, spricht man von Datenabstraktion. Die abstrakten Datentypen von SDL genügen der Datenabstraktion. SDL unterstützt die funktionale Abstraktion durch Blockdiagramme und Prozeduren. Blockdiagramme enthalten Prozeßreferenzsymbole. Die Arbeitsweise eines Prozesses wird aber durch die jeweiligen Prozeßdiagramme beschrieben. Die Prozeduren, die in den Prozeßdiagrammen verwendet werden, verursachen bei ihrer Ausführung eine Wirkung. Ein Anwender, der eine Prozedur verwendet, ist nur an der Wirkung der Prozedur interessiert und abstrahiert von ihrer Realisierung. Die Realisierung einer Prozedur erfolgt im zugehörigen Prozedurdiagramm. Auch Systemdiagramm, Substructure-Diagramme und Makros unterstützen in SDL Abstraktionen. MSCs unterstützen Hierarchisierung und Abstraktion durch die Möglichkeit Sub-MSCs zu erstellen. 2.7 Möglichst hohes FAN IN Das FAN IN eines Moduls ist die Anzahl der Module, die dieses für ihre Realisierung benötigen. Ein hohes durchschnittliches Modul-FAN IN eines Systems läßt auf einen guten Entwurf schließen [14]. Das FAN IN eines Moduls ist sozusagen ein Maß für seine Wiederverwendbarkeit. Hohes FAN IN deutet auf eine gute Abstraktion und auf sinnvolle Verallgemeinerungen. Maximales FAN IN darf aber nicht um jeden Preis erreicht werden. Module mit zufälliger, d.h. niedrigster Kohäsion neigen nämlich zu einem hohen FAN IN. Module mit hohem FAN IN müssen auch eine hohe Kohäsion besitzen. P30308-X5875-A

19 Allgemeingültige Entwurfsprinzipien 2.8 Angemessenes FAN OUT Das FAN OUT ist die Anzahl der für die Realisierung eines Moduls unmittelbar benötigten untergeordneten Module [28]. Sehr großes und sehr niedriges FAN OUT deuten im allgemeinen auf eine schlechte Modularisierung. Ein Maß für ein vernünftiges FAN OUT liegt im Bereich 7±2 [28]. Die Elemente der oberen Hierarchieschichten eines Systementwurfs haben im allgemeinen ein höheres FAN OUT, die Elemente der tieferen Ebenen ein höheres FAN IN. 2.9 Information Hiding Geheimnis- oder Black-Box-Prinzip. Von Parnas vorgeschlagenes Kriterium für die Modulbildung. Die Realisierung eines Moduls muß einem Benutzer verborgen bleiben. Es interessiert nur WAS ein Modul leistet, nicht WIE die Leistung erbracht wird. Die Kommunikation zwischen Modulen darf nur über wohldefinierte, d.h. vollständig und eindeutig spezifizierte Schnittstellen erfolgen. Das Information Hiding ist sehr stark mit dem Prinzip der Abstraktion verwandt Lokalität Alle Informationen über ein Objekt (Modul), wie z.b. Kommentare sollen sich in unmittelbarer Nähe des Objekts befinden. Nach DeMarco [8] ist die Verständlichkeit eines Moduls umgekehrt proportional zu der Anzahl der Finger, die man benötigt, um ein Modul zu lesen. Beim Programmieren wird die Lokalität durch die Verwendung von strukturierten Kontrollelementen (while, repeat etc.) und durch das Vermeiden von Goto's gefördert. Die Einhaltung des Lokalitätsprinzips ist Voraussetzung für eine hohe Kohäsion Einheitlichkeit Ein einheitlicher Aufbau von Modulen (Teilsystemen, Prozessen, Prozeduren) und eine einheitliche Nomenklatur sind Voraussetzung für Teamarbeit, Wiederverwendbarkeit und Verständlichkeit. Beim Erstellen von SDL-Diagrammen sollen daher einheitliche Konventionen eingehalten werden (Anordnung von Textsymbolen, Positionieren des Prozeß- startsymbols etc.). Einheitlichkeit kann nur durch Disziplin erreicht werden. P30308-X5875-A

20 SDL- und MSC-Konzepte 3 SDL- und MSC-Konzepte Kapitel 3 enthält eine Beschreibung der SDL- und MSC-Konzepte und der dazugehörigen Sprachmittel gemäß der ITU-Normen Z.100 bzw. Z.120. Innerhalb der momentan vorliegenden Version von SICAT (V1101) wird nicht der volle Sprachumfang von Z.100 und Z.120 abgedeckt. Folgende SDL-Sprachmittel werden von SICAT nicht unterstützt: Nichtverzögernde Kanäle, Continuous Signals, Enabling Conditions, dynamische Prozeßinstanziierung, Optionen. Folgende MSC-Sprachmittel werden von SICAT nicht unterstützt: Komposition/Dekomposition, Sub-MSCs und Coregions. Durch die Zerlegung eines Systems in Blöcke (Teilsysteme) ermöglicht SDL die Modellierung einer "groben" statischen Systemstruktur. Den Blöcken werden SDL-Prozesse zugeordnet. SDL betrachtet ein System als eine Menge von parallel und asynchron ablaufenden Prozessen. Ein SDL-Prozeß ist ein erweiterter endlicher Automat (vgl. Abbildung 3-19), der mit anderen Systemprozessen oder mit der Systemumgebung über Verbindungswege (Kanäle und Signalrouten) kommuniziert. Alle Prozesse innerhalb eines SDL-Systems existieren vollkommen gleichberechtigt nebeneinander, obwohl sie unterschiedlichen Blöcken zugeordnet sein können. Die Dynamik eines SDL-Systems wird durch das Verhalten der in ihm enthaltenen Prozesse und durch etwaige Eingaben aus der Umgebung bestimmt. Message Sequence Charts erlauben es, den zeitlichen Informationsaustausch und -ablauf zwischen Systemkomponenten untereinander und mit der Umgebung darzustellen. Da sich mit MSCs nur bestimmte Kommunikationsszenarien eines Systems darstellen lassen, repräsentieren MSCs i.a. keine vollständige Systemspezifikation. Innerhalb des Entwicklungsprozesses lassen sich MSCs in der Analyse- und Entwurfsphase einsetzen. Aber auch zur Darstellung von Testfällen für das implementierte System und für eine grafische Animation des Verhaltens von Komponenten können MSCs eingesetzt werden. SDL sieht ein System prinzipiell in einer Client-Server-Architektur. Blöcke und Prozesse können untereinander Dienste anfordern und Dienste erbringen. Benötigt ein Server Dienste eines anderen Servers, ist er gleichzeitig Client. Durch die implizite Verwendung des Client-Server-Prinzip bei der Systemspezifikation mit SDL lassen sich mit SDL natürlich leicht Client-Server-Architekturen beschreiben. SDL und MSC unterstützen eine top down-mäßige Vorgehensweise bei der Systemmodellierung (s. Abbildung 3-1). Ausgehend vom Systemdiagramm, das eine sehr abstrakte Systemsicht darstellt, werden die einzelnen Systemkomponenten mit Hilfe von Sub- structure- Diagrammen solange weiter in Teil- bzw. Untersysteme (Blöcke im SDL-Sprachgebrauch) zerlegt, bis ein Block nur noch Prozesse beinhaltet. Die Dekomposition in Blöcke beschreibt nur die Statik eines Systems. Die Prozesse dagegen beschreiben das Systemverhalten. Sie können durch Prozeduren weiter strukturiert werden. Auf allen Dekompositionsebenen können Message Sequence Charts eingesetzt werden, um das jeweilige Kommunikationsverhalten zu beschreiben. Mit MSC können das globale Kommunikationsverhalten von Systemkomponenten (externe Kommunikation mit der Umgebung) und das interne Kommunikationsverhalten ihrer Teilkomponenten beschrieben werden (s. Abbildung 3-1). P30308-X5875-A

21 SDL- und MSC-Konzepte system Gesamtsystem msc Sys_ext msc Sys_int signal Teilsystem_B TS_B GSys TS_A TS_C Teilsystem_A Teilsystem_C substructure TS_A msc TSA_ext TS_A msc US_1 TSA_int US_2 signal Untersystem_ Untersystem_ block US_2 msc US2ext msc signal US_2 P_1 US2ext P_2 P_1 P_2 process procedure proc_a decl Zustand_1 dcl i, u, v, z; proc_a Zustand_2 input task 1 u = y + z input proc_a n i < 10? j task output task 2 v = x - z Zustand_x Zustand_x Abbildung 3-1: Typische SDL- und MSC-Hierarchie eines Systems Im folgenden wird dargestellt, wie sich mit Hilfe von SDL und MSC statische und dynamische Systemmerkmale beschreiben lassen. 3.1 System- und Kommunikationsstruktur Ausgangspunkt einer SDL-Systemmodellierung ist das Systemdiagramm. Das Systemdiagramm stellt ein SDL-Modell in seiner abstraktesten Form dar und grenzt es gegen seine Umgebung ab. Alles innerhalb des Systemdiagramms gehört zum System und muß weiter modelliert werden, alles außerhalb des Systemdiagramms gehört zur Umgebung und wird als Black Box betrachtet. Das Systemdiagramm ist die oberste Ebene einer SDL-Spezifikation. Aus ihm ist ersichtlich aus welchen Teilsystemen ein System besteht und auf welchen Kanälen die Teilsysteme untereinander bzw. mit der Umgebung Nachrichten austauschen. P30308-X5875-A

22 SDL- und MSC-Konzepte Umgebung system signal s1,s2,s3,s s5,s6,s7,s Textsymbol C1 [s2] Kanalnamen Ges_Sys Teilsystem_A Kanal mit Verzögerung [s3] [s4] Kanal ohne Verzögerung C2 C3 [s1] [s1] Block Teilsystem_B [s7] C6 [s8] Teilsystem_C C4 C5 [s5] [s6] Abbildung 3-2: SDL-Systemdiagramm Das System Ges_Sys aus Abbildung 3-2 besteht aus den drei Teilsystemen A, B und C. Die Kanäle, die die Teilsysteme untereinander oder mit der Umgebung verbinden, müssen eine Bezeichnung (Namen) besitzen. Kanäle können unidirektional (z.b. Kanal C1) oder bidirektional (z.b. Kanal C2) sein und verzögernd (C3) oder nicht verzögernd (C2). Verzögernde Kanäle haben ihre Pfeilköpfe (für die Richtungsanzeige) in der Kanalmitte, nicht verzögernde Kanäle an den Kanalenden. Die Ankunft von Signalen, die auf verzögernden Kanälen laufen, werden um eine nichtdeterministische Zeitspanne verzögert. Alle in einem System verwendeten Signale müssen definiert sein. Die Signale werden entweder an der Stelle, wo sie verwendet werden, definiert oder weiter oben in der Hierarchie. Die Definition von Signalen und von Datentypen wird in Kap. 3.5 (Datendefinition, -strukturierung und - modellierung mit SDL) genauer erläutert. Signale, die Nutzdaten tragen, werden als Nachrichten bezeichnet. Die Blöcke des Systemdiagramms können weiter verfeinert werden. Blöcke, die wiederum Blöcke enthalten, werden in einem Substructure-Diagramm dargestellt. C2 C6 [s4] substructure Teilsystem_C [s7] [s4] K1 K4 K5 [s1] [s1] [s8] signal [u] [v] u,v; Untersystem 1 Untersystem 2 K2 [s6] K3 C5 Abbildung 3-3: SDL-Substructure-Diagramm Abbildung 3-3 zeigt das Substructure-Diagramm des Blocks Teilsystem_C. Es muß eindeutig festgelegt sein, mit welchen Kanälen des übergeordneten Diagramms die Kanäle eines Substructure-Diagramms verbunden sind. Z.B. ist in Abbildung 3-3 der Substructure-Kanal K3 mit dem Kanal C5 des Systemdiagramms verbunden. Auch die Blöcke eines Substructure-Diagrammes können wieder Blöcke enthalten. Daraus ergibt sich eine baumartige Systemstruktur. Blöcke, die nicht wieder durch Blöcke verfeinert werden, enthalten Prozesse (s. Abbildung 3-4). Blöcke, die aus Prozessen bestehen, werden in sogenannten Blockdiagrammen beschrieben. Blockdiagramme können -im Gegensatz zu Systemund Substructure-Diagrammen- durch die Möglichkeit dynamisch Prozesse zu erzeugen, auch dynamische Aspekte ausdrücken. Sie werden darum im nächsten Kapitel genauer behandelt. P30308-X5875-A

23 SDL- und MSC-Konzepte Ein Prozeßinteraktionsdiagramm, als Verfeinerung eines "Blatt-Blockes", enthält normalerweise nur Prozesse. SDL erlaubt es aber innerhalb eines Blockdiagramms neben den Prozessen zusätzlich auch ein Substructure-Diagramm zu erstellen (sogenannte "combined block specifications") [1]. Dadurch ermöglicht es SDL einen Block mit zwei unterschiedlichen Sichten zu betrachten. Die Prozesse beschreiben das Verhalten, das Substructure-Diagramm die Implementierungsstruktur. Braek und Haugen empfehlen aber diese Möglichkeit nicht zu verwenden, da dadurch Spezifikationen schwerer zu verstehen sind [4]. Abbildung 3-4 zeigt die hierarchische Anordnung der Bestandteile einer SDL-Spezifikation. Solche Baumdiagramme sind in der SDL-Sprachbeschreibung nicht enthalten. System S Block B1 Block B2 Block B3 Block B11 Block B12 Prozeß P21 Prozeß P22 Prozeß P31 Prozeß P32 Prozeß P111 Prozeß P112 Prozeß P113 Prozeß P121 Prozeß P122 Abbildung 3-4: Baumstruktur einer SDL-Systemspezifikation Um das Verständnis der SDL-Diagrammtypen Systemdiagramm, Substructure-Diagramm und Blockdiagramm zu erleichtern, führt Hogrefe näherliegendere Bezeichnungen ein [12]. Hogrefe bezeichnet Diagramme, in denen Blöcke miteinander kommunizieren als Blockinteraktionsdiagramme und solche, in denen Prozesse miteinander kommunizieren als Prozeßinteraktionsdiagramme. Blockinteraktionsdiagramme entsprechen somit den SDL-Substructure-Diagrammen und Prozeßinteraktionsdiagramme den SDL-Blockdiagrammen. Das SDL-Systemdiagramm ist somit ein spezielles Blockinteraktionsdiagramm. Das Verhalten der Prozesse wird in Prozeßdiagrammen beschrieben (s. Kap. 3.4). Im weiteren Methodenhandbuch werden bei eventuellen Mehrdeutigkeiten für die Bezeichnung der jeweiligen Diagrammtypen die Begriffe Blockinteraktions- und Prozeßinteraktiondiagramm verwendet. 3.2 Dynamische Prozeßerzeugung Blockinteraktionsdiagramme ermöglichen eine Beschreibung der statischen Struktur eines Systems und des statischen Nachrichtenaustausches zwischen Systemkomponenten. Dynamische Aspekte wie Erzeugung und Terminierung von Prozessen zur Laufzeit oder die Darstellung des P30308-X5875-A