Technische Universität München Fakultät für Informatik. Diplomarbeit. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML

Transkript

1 Technische Universität München Fakultät für Informatik Diplomarbeit Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML Bearbeiter: Martin Reiland Aufgabensteller: Prof. Dr. Schlichter Betreuer: Dr. Wolfgang Wörndl Externer Betreuer: Dietrich Sauter Abgabedatum: 15. Juli 2004

2 Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 15.Juli Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 1

3 Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 2

4 Kurzfassung Diese Arbeit entstand im Rahmen einer Kooperation der TU München mit dem Institut für Rundfunktechnik (IRT). Das IRT ist das Forschungsinstitut der öffentlich-rechtlichen Rundfunkanstalten in Deutschland, Österreich und der Schweiz. Ein aktueller Forschungsschwerpunkt des IRT ist die Entwicklung einer IT-gestützten Produktionsumgebung. Die Software dafür soll in Zukunft verstärkt mit Hilfe von Modellierung und Codegenerierung entwickelt werden. Für die Modellierung soll dabei die Unified Modeling Language (UML) verwendet werden. Für die Codegenerierung sollen die Konzepte der Model Driven Architecture eingesetzt werden. In dieser Arbeit wurde eine solche Modellierung und Codegenerierung exemplarisch für eine Komponente im Bereich des Video-Filetransfers durchgeführt. Für die Modellierung und Codegenerierung wurde das MDA-Werkzeug ArcStyler von Interactive Objects Software verwendet. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 3

5 INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Einleitung Das Projektumfeld Die Aufgabenstellung Die methodische Vorgehensweise Überblick über die Arbeit Grundlagen UML und deren Anwendung im Projekt Statische Modellierung mit UML Dynamische Modellierung mit UML Model Driven Architecture Anforderungsanalyse für den Video-Filetransfer Allgemeine Beschreibung Funktionale Anforderungen Pseudoanforderungen Anforderungsmodellierung Grobmodellierung des Video-Filetransfer Statische Modellierung Identifizierung von Komponenten Unterteilung des Transfersystems in Komponenten Feinmodellierung der Sendertransfereinheit Anforderungsanalyse - Aufgaben der Transfereinheiten Sendertransfereinheit Empfängertransfereinheit Systemanalyse Schnittstellen der Sendertransfereinheit Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 4

6 INHALTSVERZEICHNIS Verwendete Schnittstellen der Sendertransfereinheit Platform Independent Model Statische Modellierung Dynamische Modellierung Praktische Umsetzung der Modellierung ArcStyler eine kurze Einführung Modellierung und Generierung der Komponente mit ArcStyler Bewertung von ArcStyler Fazit Zusammenfassung und Ausblick 65 Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 5

7 1 Einleitung 1.1 Das Projektumfeld Diese Arbeit entstand im Rahmen einer Kooperation der TU München mit dem Institut für Rundfunktechnik (IRT). Das IRT ist das Forschungsinstitut der öffentlich-rechtlichen Rundfunkanstalten in Deutschland, Österreich und der Schweiz. Da die Informationstechnologie einen immer wichtiger werdenden Faktor bei der Produktion von Fernsehprogrammen darstellt, ist dieses Thema auch ein Forschungsbereich des IRT (siehe [HW03]). Das Ziel ist die Schaffung eines einheitlichen digitalen Gesamtsystems, das alle Arbeitsabläufe von Aufnahme bis zur Archivierung von Videomaterial integriert. Auf diese Weise sollen Beiträge schneller erstellt werden und auch eine bessere Nutzung der Archive realisiert werden. Die Einführung eines solchen digitalen Gesamtsystems stellt jedoch eine große Herausforderung dar, da bestehende Strukturen und Arbeitsabläufe in der Fernsehproduktion überarbeitet werden müssen. Auch die Anforderungen an die zu entwickelnde Software sind hoch, da viele verteilte Systeme über noch zu definierende Schnittstellen miteinander kooperieren müssen. Das IRT arbeitet bei der Lösung dieser Probleme auch mit anderen europäischen Forschungsinstituten und Universitäten in gemeinsamen Projekten zusammen. Ein Beispiel dafür ist das Projekt Asset (siehe [M.C]), das sich zum Ziel gesetzt hat, die Probleme bei der Zusammenarbeit der Systeme verschiedener Hersteller zu überwinden. Hier werden die Probleme meist durch nicht aufeinander abgestimmte Schnittstellen verursacht. Nun zurück zum digitalen Gesamtsystem. Ein Teil eines solchen Systems ist der Transfer von Videomaterial zwischen Rundfunkanstalten über Netzwerke. Ein solcher Transfer soll den Transport von Videomaterial mit Hilfe von MAZ-Bändern ersetzen. Dadurch könnte man viel Zeit und Kosten einsparen. Mit dem Bereich des Video-Filetransfers beschäftigt sich nun auch diese Arbeit, wobei die genaue Aufgabenstellung im nächsten Kapitel beschrieben wird. 1.2 Die Aufgabenstellung Es soll zunächst eine Beschreibung der Anforderungen an den Video-Filetransfer gegeben werden. Aus diesen Anforderungen sollen benötigte Komponenten identifiziert und beschrieben werden. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 6

8 1.3 Die methodische Vorgehensweise Für eine dieser Komponenten soll eine genaue Spezifikation der Aufgaben und Schnittstellen durchgeführt werden. Anschließend soll die Komponente mit Hilfe der Unified Modeling Language (UML) modelliert werden. Diese Modellierung soll mit dem Werkzeug ArcStyler von Interactive Objects Software durchgeführt werden. Es soll anschließend für dieses Modell exemplarisch die Codegenerierung mit ArcStyler untersucht werden. Die Komponente, die in dieser Arbeit modelliert wird, ist die sogenannte Sendertransfereinheit. Diese Komponente ist für den Transfer eines einzelnen Files zuständig. Sie muss dabei einen vorher definierten Quality of Service einhalten. Eine detailliertere Beschreibung wird an späterer Stelle in dieser Arbeit gegeben. 1.3 Die methodische Vorgehensweise Es wird ein Top Down Ansatz gewählt. Es wird zunächst ein Überblick über das gesamte System gegeben. Hierbei wird auf die Anforderungen an das System eingegangen und daraus ein grober Architekturvorschlag erarbeitet. Es erfolgt eine Aufgabenbeschreibung der beteiligten Komponenten. Anschließend wird eine Komponente, in diesem Fall die Sendertransfereinheit, beispielhaft genauer untersucht und modelliert. Für diese Komponente wird ein plattformunabhängiges Modell (PIM) mit Hilfe des Tools ArcStyler modelliert. Aus diesem Modell wird anschließend Code generiert. Diese methodische Vorgehensweise entspricht dem Konzept der Model Driven Architecture (MDA). 1.4 Überblick über die Arbeit In diesem Kapitel wird nun ein Überblick über die Arbeit gegeben. Im Kapitel 2 werden Grundlagen beschrieben, die für ein besseres Verständnis der späteren Modellierung sorgen sollen. Es wird hier auf die verwendeten Diagramme der UML eingegangen, sowie eine Einführung in die Konzepte der Model Driven Architecture (MDA) gegeben. Im Kapitel 3 wird darauf eine Anforderungsanalyse für den Video-Filetransfer im Rundfunk durchgeführt. Auf diesen Anforderungen aufbauend, wird schließlich in Kapitel 4 eine Identifizierung der für einen Video-Filetransfer benötigten Komponenten vorgenommen. Für eine dieser Komponenten, die Sendertransfereinheit, wird nun in Kapitel 5 mit Hilfe der UML ein plattformunabhängiges Modell entwickelt. Die praktische Umsetzung der Modellierung mit dem MDA-Entwicklungswerkzeug ArcStyler und die Möglichkeiten der Codegenerierung werden darauf in Kapitel 6 beschrieben. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 7

9 1.4 Überblick über die Arbeit Im letzten Kapitel erfolgt schließlich eine Zusammenfassung dieser Arbeit. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 8

10 2 Grundlagen Ein Ziel dieser Arbeit ist die Modellierung einer Komponente in UML. Um die Modellierung der Komponente besser verständlich zu machen, wird in dieser Arbeit eine Beschreibung der verwendeten Diagrammarten der UML gegeben. Ein weiteres Ziel dieser Arbeit besteht darin, die Codegenerierung für diese Komponente durchzuführen. An dieser Stelle werden Konzepte der Model Driven Architecture (MDA) verwendet. Aus diesem Grund wird im folgenden Kapitel eine kurze Einführung in die MDA gegeben. 2.1 UML und deren Anwendung im Projekt Die Unified Modeling Language (UML) ist eine grafische Modellierungssprache für die objektorientierte Modellierung. Entstanden ist diese Sprache aus den Arbeiten von Grady Booch, Ivar Jacobson und James Rumbaugh, welche den Beinamen Amigos tragen. Aus drei konkurrierenden Notationen (Booch, OMT und OOSE) entwickelten die drei Amigos die UML 0.9, die im Jahr 1996 fertiggestellt wurde. Im Jahr 1997 wurde die UML 1.0 bei der Object Management Group (OMG), einem Standardisierungsgremium, eingereicht. Im Jahr 2004 ist die UML nun aus der objektorientierten Modellierung nicht mehr wegzudenken und die OMG steht kurz vor der Verabschiedung der UML 2.0. In dieser Arbeit wird die Version UML 1.4 verwendet, aufgrund des eingesetzten Werkzeugs. Eine detaillierte Beschreibung der UML ist aufgrund des Umfangs an dieser Stelle kaum möglich. Für eine solche Beschreibung wird auf die zahlreiche Fachliteratur verwiesen. Als sehr gute und angenehm zu lesende Einführung in die UML kann etwa UML konzentriert von Martin Fowler (siehe [FS00]) empfohlen werden. Wer sich sehr intensiv mit der UML beschäftigen will, der sei auf The Unified Modeling Language Reference Manual von James Rumbaugh, Ivar Jacobson und Grady Booch (siehe [RJB]) verwiesen. In den folgenden Kapiteln soll nun ein Überblick über die in dieser Arbeit verwendeten UML- Diagramme gegeben werden Statische Modellierung mit UML In diesem Abschnitt wird nun ein Überblick über die statischen Diagrammtypen der UML gegeben, die in dieser Arbeit verwendet wurden. Dafür wird eine kurze Beschreibung jedes Diagrammtyps gegeben. Es wird weiterhin jeweils beschrieben, in welchen Projektbereichen ein Diagrammtyp eingesetzt werden kann, sowie der Einsatzbereich in dieser Arbeit. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 9

11 2.1 UML und deren Anwendung im Projekt Klassendiagramm (Abbildung 8) Beschreibung Das Klassendiagramm ist wohl das bekannteste und wichtigste Diagramm der UML. Mit einem Klassendiagramm kann die statische Struktur eines Systems beschrieben werden. Nach [FS00] beschreibt ein Klassendiagramm die Typen von Objekten im System und die verschiedenen Arten von statischen Beziehungen zwischen ihnen. Mit einem Klassendiagramm kann ein System auf verschiedenen Abstraktionsebenen modelliert werden. Klassendiagramme auf verschiedenen Abstraktionsebenen spielen auch bei der Model Driven Architecture (siehe Kapitel 2.2) eine entscheidende Rolle. Einsatzbereiche Das Klassendiagramm kann bei der Analyse, beim Design sowie bei der Implementierung von Softwareprojekten eingesetzt werden. In der Analysephase wird das Klassendiagramm zur konzeptionellen Modellierung des Problembereichs verwendet. In der Designphase wird das Klassendiagramm verwendet, um Softwareteile zu modellieren, aber ohne auf technische Details einzugehen. In der Implementierungsphase bilden schließlich die Klassendiagramme konkrete Klassen im Code ab. In diesem Projekt In diesem Projekt werden Klassendiagramme verwendet, um plattformunabhängige Modelle (Definition siehe Kapitel 2.2) zu entwickeln. Dies entspricht der Designphase. Die Modelle sollen die Software beschreiben, aber nicht auf technischen Details eingehen. Komponentendiagramm (Abbildungen 3, 6 und 7) Beschreibung Dieses Diagramm gehört zusammen mit dem Verteilungsdiagramm zu den Implementierungsdiagrammen 1. Dieses Diagramm soll die Komponenten eines Systems und ihre Beziehungen verdeutlichen. Nach [Oes01] ist eine Komponente dabei ein ausführbares Stück Software mit eigener Identität und definierten Schnittstellen. Eine sehr ausführliche Diskussion zu Komponenten und zur komponentenbasierten Entwicklung wird in [And03] gegeben. Einsatzbereiche In [Oes01] wird die Verwendung von UML-Komponenten zur Beschreibung größerer 1 Englische Bezeichnung: physical diagram. Es wird auch die Übersetzung Technikdiagramm verwendet. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 10

12 2.1 UML und deren Anwendung im Projekt Mengen fachlich zusammenhängender Klassen empfohlen. Dies bietet auch die Möglichkeit, eine Menge von Klassen durch eine oder mehrere Schnittstellen zu kapseln. Bei den Einsatzbereichen überschneidet sich das Komponentendiagramm gelegentlich mit dem Paketdiagramm, das eine ähnliche Aufgabe hat. Der Unterschied zwischen diesen soll kurz erklärt werden. Paketdiagramme können verwendet werden, um beliebige Modellelemente zu strukturieren, während bei Komponentendiagrammen ein System in ausführbare Softwareteile zerlegt werden soll. Bei den Komponentendiagrammen spielen also Implementierungsaspekte eine größere Rolle. In diesem Projekt In diesem Projekt werden Komponentendiagramme verwendet, um das Gesamtsystem zu unterteilen und so einzelne Komponenten zu identifizieren. Auf diese Weise können Komponenten, deren Aufgabe sowie deren bereitgestellte und benötigte Schnittstellen spezifiziert sind, unabhängig vom System entwickelt werden. In dieser Arbeit wird die Komponente Sendertransfereinheit identifiziert und schließlich modelliert. Verteilungsdiagramm (Abbildung 4) Beschreibung Das Verteilungsdiagramm dient dazu, die Verteilung der Komponenten auf sogenannte Knoten zu beschreiben. Ein Knoten stellt hierbei im Allgemeinen ein physisches Objekt, wie etwa einen Computer dar. Das Verteilungsdiagramm beschreibt also im Prinzip die Verteilung der Software auf Hardware. Einsatzbereiche Dieses Diagramm kann bei der Beschreibung von verteilten Anwendungen eingesetzt werden. In diesem Projekt In diesem Projekt soll mit dem Diagramm die Verteilung und die Zusammenarbeit der wichtigsten Komponenten beim Video-Filetransfer beschrieben werden. Paketdiagramm (Abbildung 12) Beschreibung Paketdiagramme dienen dazu, Modellelemente zu gruppieren und die Abhängigkeiten zwischen ihnen zu beschreiben. Mit ihnen kann die Struktur eines Systems besser beschrieben werden. Es spielt hier allerdings der Laufzeitgedanke keine so wichtige Rolle Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 11

13 2.1 UML und deren Anwendung im Projekt wie bei den Komponentendiagrammen. Es geht nur um die logische Struktur eines Systems. Einsatzbereiche Paketdiagramme können bei der Analyse und Design und schließlich auch bei der Implementierung von Systemen verwendet werden. In diesem Projekt In diesem Projekt wurde das Paketdiagramm verwendet, um die im Entwicklungstool ArcStyler entworfenen Modelle zu strukturieren Dynamische Modellierung mit UML In diesem Abschnitt soll ein Überblick über die in diesem Projekt verwendeten dynamischen Diagrammtypen der UML gegeben werden. Es werden wiederum die typischen Einsatzgebiete der Diagrammtypen beschrieben, sowie ihre Verwendung in diesem Projekt. Use-Case-Diagramm (Abbildungen 2 und 5) Beschreibung Ein Anwendungsfalldiagramm beschreibt ein System aus der Sicht eines Benutzers. Ein Anwendungsfalldiagramm beinhaltet dabei ein oder mehrere Akteure, ein oder mehrere Anwendungsfälle und eventuell eine Systemgrenze. Ein Akteur entspricht hier einer vom Anwender eingenommenen Rolle, z.b. einem Operator (siehe Abbildung 2). Ein Akteur kann aber auch ein anderes Softwaresystem darstellen. Ein Anwendungsfall stellt dabei eine typische Interaktion zwischen dem Akteur und dem System dar. Eine Systemgrenze verdeutlicht in einem Anwendungsfalldiagramm die Trennung zwischen dem System und den Akteuren. Einsatzbereiche Das Anwendungsfalldiagramm wird meist dazu verwendet, mit Anwendern des späteren Systems die Anforderungen an dieses zu erarbeiten. In diesem Projekt In diesem Projekt wird das Anwendungsfalldiagramm verwendet, um die Anforderungen an ein Video-Filetransfersystem aus der Sicht eines Benutzers zu beschreiben, sowie um die Anforderungen an die Komponente Sendertransfereinheit zu beschreiben. Sequenzdiagramm (Abbildung 9) Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 12

14 2.2 Model Driven Architecture Beschreibung Ein Sequenzdiagramme beschreibt den Ablauf eines Nachrichtenaustausches zwischen den Objekten eines Systems. Im allgemeinen wird durch ein Sequenzdiagramm ein möglicher Ablauf beschrieben, das Diagramm zeigt also keine Alternativen auf. In der UML 2.0 sind nun allerdings auch Konstrukte vorgesehen, um mit Sequenzdiagrammen Alternative und Schleifen darzustellen. Einsatzbereiche Sequenzdiagramme können in verschiedenen Phasen der Entwicklung eingesetzt werden. Mit Sequenzdiagrammen kann etwa in der Frühphase der Entwicklung der Ablauf der Kommunikation eines Anwenders mit einem System spezifiziert werden. Es kann aber auch der exakte Nachrichtenaustausch zwischen Objekten eines Systems modelliert werden. In diesem Projekt In diesem Projekt wird das Sequenzdiagramm verwendet, um die Kommunikation zwischen den Objekten eines plattformunabhängigen Modells (Definition siehe Kapitel 2.2) zu beschreiben. Es wird dabei ein möglicher Ablauf dargestellt. 2.2 Model Driven Architecture Die Modellierung und Codegenerierung einer Komponente wird in dieser Arbeit mit dem MDA-Werkzeug ArcStyler durchgeführt. Das Kürzel MDA bedeutet Model Driven Architecture und ist ein neuer Standard der Object Management Group (OMG). Die Konzepte der MDA sollen in diesem Kapitel nun beschrieben werden. Im Mittelpunkt der Softwareentwicklung mit der MDA steht die Verwendung von Modellen und zwar die Verwendung von Modellen auf verschiedenen Abstraktionsebenen. Das Ziel dabei ist eine Trennung der fachlichen Spezifikation von technischen Details in den Modellen. Das Vorgehen gemäß den MDA Konzepten ist nun folgendes (siehe auch [KWBpW03]): Zunächst wird ein sogenanntes Platform Independent Model (PIM) entwickelt. Dieses Modell enthält fachliche Konzepte, aber keine technischen Details der verwendeten Plattform, wie z.b. einer verwendeten Middleware. Durch eine Transformation entsteht nun aus dem PIM ein Platform Specific Model (PSM), das die technischen Details der verwendeten Plattform enthält. Durch die Plattformunabhängigkeit des PIMs ist eine Abbildung auf verschiedene PSMs möglich. Aus den PSMs kann darauf folgend eine Transformation in Code durchgeführt werden. Dieser Code muss schließlich vom Entwickler noch vervollständigt werden. In Abbildung 1 wird dieser Ansatz grafisch verdeutlicht. Das Arbeiten mit Modellen verschiedener Abstraktionsebenen ist prinzipiell nichts neues, entscheidend ist bei dem Konzept der MDA eine automatisierte Transformation zwischen den Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 13

15 2.2 Model Driven Architecture verschiedenen Abstraktionsebenen. Folgende Vorteile verspricht man sich durch die Konzepte der MDA (siehe [PR03]): Steigerung der Entwicklungsgeschwindigkeit Steigerung der Softwarequalität (Fehler werden zentral in der Transformation entfernt) Eine bessere Verständlichkeit der Modelle aufgrund der Trennung der fachlichen und technischen Aspekte Erleichterung des Technologiewechsels aufgrund der Trennung der fachlichen und technischen Aspekte Abbildung 1: MDA Ansatz Nach Beschreibung der Vorteile soll an dieser Stelle nun noch auf den Begriff der Plattform eingegangen werden. Die OMG definiert in ihrem MDA Guide (siehe [OMG03]) eine Plattform folgendermaßen: Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 14

16 2.2 Model Driven Architecture A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented. Diese Definition ist bewusst sehr offen gehalten und läßt viel Spielraum für Interpretation. Unter diese Definition fällt etwa ein Betriebssystem, eine verwendete Programmiersprache oder auch eine Komponententechnologie. Als konkrete, aktuelle Beispiele für Plattformen nennt die OMG unter anderem etwa CORBA oder auch J2EE. In dieser Arbeit wird bei der exemplarischen Codegenerierung aus dem PIM Java als Plattform verwendet. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 15

17 3 Anforderungsanalyse für den Video-Filetransfer In diesem Kapitel werden die Anforderungen an den Video-Filetransfer beschrieben. Dafür wird zunächst die Funktion und der Zweck des Video-Filetransfers erläutert. Anschließend folgt ein Überblick über die benötigten Funktionalitäten eines Systems, das einen solchen Video-Filetransfer realisiert. Nach diesem Überblick werden die funktionalen Anforderungen eines solchen Systems detaillierter beschrieben. Darauf folgt die Erläuterung der Pseudoanforderungen. Den Abschluss dieses Kapitels bildet schließlich die Modellierung von Anwendungsfällen mit UML. 3.1 Allgemeine Beschreibung Es wird nun zunächst beschrieben, was unter Video-Filetransfer zu verstehen ist, und welche Vorteile dadurch entstehen. Prinzipiell verstehen wir unter Video-Filetransfer die Übertragung von digitalem Videomaterial zwischen Rundfunkanstalten über ein Netzwerk. Dieses Verfahren soll in Zukunft den Transport von Programmmaterial über MAZ-Bänder ablösen. Es ist offensichtlich, dass der Transport von Videomaterial über ein Netzwerk gegenüber dem Transport von Videomaterial mit Hilfe etwa von Lastwägen einen beträchtlichen Zeitgewinn ermöglicht. Auf diese Weise wird es in Zukunft möglich sein, Beiträge schneller und kostengünstiger zu produzieren. Viele Vorteile des Video-Filetransfer kommen jedoch erst zum Tragen, wenn die ganze Fernsehproduktion als ein einheitliches digitales Gesamtsystem realisiert ist. Dann ist etwa eine bessere Nutzung der Archive möglich, die verteilte Zusammenarbeit an Beiträgen wird erleichtert, Beiträge könnten noch sehr kurzfristig überspielt werden und vieles mehr. In einem solchen Szenario stellt der Video-Filetransfer eine zentrale Komponente des Produktionsablaufs dar. Nun soll ein Überblick über die benötigten Funktionalitäten eines Video-Filetransfersystems gegeben werden. Daraus wird auch ersichtlich werden, warum bestehende Filetransferapplikationen für diesen Bereich nicht ausreichend sind. Ein Video-Filetransfersystem soll den Transfer von Inhalten zwischen Rundfunkanstalten mit höchstmöglicher Geschwindigkeit und einem definierten Quality of Service ermöglichen. Was verstehen wir hier unter Quality of Service? Es soll möglich sein, eine Deadline für die Übertragung festzulegen. Das System hat dann die Aufgabe die Übertragung vor einem definierten Zeitpunkt abzuschließen. Ein Beispiel für ein solches Szenario wäre etwa ein kurzfristig erstellter Beitrag für eine Nachrichtensendung. Eine pünktliche Übertragung ist hier zwingend erforderlich. Eine Unterstützung von unterschiedlichen Diensteklassen ist in diesem Zusammenhang auch sinnvoll. Der kurzfristige Beitrag für eine Nachrichtensendung sollte bei der Übertragung gegenüber anderen Transfers bevorzugt werden. Eine weitere Forderung ist die Unterstützung von Point to Point sowie von Point to Multipoint Transfer. Desweiteren soll Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 16

18 3.2 Funktionale Anforderungen ein Transfer sowohl vom Sender als auch vom Empfänger initiiert werden können (Push bzw. Pull Prinzip). Das Video-Filetransfersystem sollte auch über Funktionen verfügen, die eine möglichst verlustfreie Wiederaufnahme des Transfers nach einem Fehlerfall bzw. Abbruch des Transfers realisieren. Diese Beschreibung sollte genügen, um einen ersten Eindruck von der geforderten Funktionalität zu gewinnen. Eine detailliertere Erläuterung folgt nun im nächsten Kapitel. 3.2 Funktionale Anforderungen Das Thema dieses Kapitels ist die Beschreibung der funktionalen Anforderungen an ein Video- Filetransfersystem. Die Anforderungen sind in Kategorien aufgeteilt. Basisanforderungen 1. Point to Point Übertragung sowie Point to Multipoint Übertragung von Daten. Für eine Point to Multipoint Übertragung muss die Bildung von Adressgruppen möglich sein. 2. Push oder Pull Übertragung. Die Übertragung von Daten soll vom Sender als auch Empfänger initiiert werden können. 3. Zugriff auf Daten soll auch während des Transfers möglich sein. 4. Transfer soll bereits während des Einspielens von Daten möglich sein. Diese Anforderung betrifft die Einspielung von Videomaterial über das Serial Digital Interface (SDI). Über diese Schnittstelle kann Material eingespielt werden, das nicht im Fileformat vorliegt. 5. Filetransfer soll im Material Exchange Format (MXF) stattfinden. MXF ist ein offenes Fileformat, das für den Austausch von Audio- bzw. Videomaterial mit dazugehörigen Metadaten konzipiert wurde. Metadaten sind Informationen, die das Audio- bzw. Videomaterial näher beschreiben (auf die Thematik der Metadaten wird weiter unter näher eingegangen). 6. Weiterleitung des Materials innerhalb der Rundfunkanstalt. Nachdem eine Datei zwischen den Rundfunkanstalten übertragen wurde, muss es möglich sein, die Datei innerhalb der Rundfunkanstalt in das gewünschte System weiterzuleiten. 7. Fortsetzung des Transfers nach Unterbrechung oder Absturz des Systems muss gewährleistet sein. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 17

19 3.2 Funktionale Anforderungen Da zum einen die Übertragung von sehr grossen Dateien geplant ist, und zum anderen gewisse Ablieferungszeitpunkte einzuhalten sind, ist eine komplette Wiederholung eines Transfers nach einem Fehlerfall zu vermeiden. Es sollte also, wenn immer möglich, der unterbrochene Transfer mit möglichst wenig Verlust wiederaufgenommen werden. 8. Logging von ausgeführten Aktionen und Systemzuständen. Ressourcenabhängige Anforderungen In diesem Abschnitt werden Anforderungen beschrieben, die von der Zuteilung entsprechender Ressourcen abhängig sind. 1. Schnellstmögliche Übertragung ist anzustreben. Dies bedeutet zum einen, dass der Start eines Transfer möglichst früh durchgeführt werden soll und zum anderen, dass die Übertragungsgeschwindigkeit möglichst hoch sein soll. 2. Der Zeitpunkt der Verfügbarkeit der zu übertragenden Datei beim Empfänger muss definierbar sein und eingehalten werden. Es soll also für einen Transfer ein Ablieferungszeitpunkt definiert werden können. Nach diesem Zeitpunkt muss die Datei übertragen worden sein. Um einen solchen Zeitpunkt einzuhalten, muss eine Überprüfung und eventuell eine Reservierung der benötigten Ressourcen stattfinden (z.b. Netzauslastung) Desweiteren soll der Benutzer über den voraussichtlichen Ablieferungszeitpunkt informiert werden. Unterstützung von Diensteklassen Da die Ressourcen, wie etwa die verfügbare Bandbreite, begrenzt sind, ist eine Festlegung von verschiedenen Diensteklassen sinnvoll. Auf diese Weise kann die unterschiedliche Priorität bei der Vergabe von Ressourcen berücksichtigt werden. Ein Beitrag für eine Nachrichtensendung sollte auch noch kurz vor der Sendung übertragen werden können und bei der Vergabe von Ressourcen bevorzugt werden. Folgende drei Diensteklassen wurden nun vom Institut für Rundfunktechnik definiert: 1. Aktualität/Nachrichten (a) Clip-Dauer < 5 Minuten (b) Point to Point sowie Point to Multipoint Übertragung muss möglich sein (c) Vorlauf: Mehrere Minuten vor der Sendung (d) Ziel: Schnellere und einfachere Verfügbarkeit der Beiträge beim Empfänger Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 18

20 3.2 Funktionale Anforderungen (e) Übertragungszeit kleiner gleich Realzeit 2. Magazine/Werbung (a) Clip-Dauer < 15 min (b) Point to Point sowie Point to Multipoint Übertragung muss möglich sein (c) Vorlauf/Vereinbarte Überspielung: Mehrere Tage bis eine Stunde vor Sendung (d) Ziel: Schnellere und einfachere Verfügbarkeit der Beiträge beim Empfänger (e) Übertragung kann langsamer als in Realzeit erfolgen 3. Archive (a) Clip Dauer < 30 Minuten (b) Point to Point Übertragung (c) Vorlauf Mehrere Tage bis mehrere Stunden (d) Ziel: Einfache Übertragung des Materials (e) Übertragung kann langsamer als in Realzeit erfolgen Unterstützung von Metadaten Metadaten sind dem Begriff nach Daten über Daten. In unserem Fall stellen Metadaten Informationen über Video- bzw. Audiomaterial dar. Beispiele für Metadaten sind etwa der Haupttitel, die Sprache oder auch das Bildformat eines Beitrages. Alle Pflichtmetadaten sowie optionale Metadaten sind in [aarf02] beschrieben. In Bezug auf ein Video-Filetransfersystem ergeben sich nun folgende Anforderungen in Zusammenhang mit Metadaten. 1. Übertragung von Metadaten Zusätzlich zur Übertragung des Videomaterials wird eine Übertragung der Metadaten gefordert. Diese Übertragung soll sowohl über das Austauschformat MXF stattfinden, als auch getrennt von dem Videomaterial mittels XML stattfinden. Die Verbindung zwischen Videomaterial und den Metadaten soll dabei über eindeutige Identifikatoren realisiert werden. 2. Für den Zugriff auf Metadaten wird ein API benötigt. Ein Zugriff ist beispielsweise notwendig zur Darstellung der Metadaten durch eine GUI. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 19

21 3.3 Pseudoanforderungen 3.3 Pseudoanforderungen Der Begriff Pseudoanforderungen (siehe auch [BD00]) bezeichnet Anforderungen, die die Implementierung eines Systems betreffen. Im Gegensatz zu den funktionalen Anforderungen haben diese Anforderungen keinen Einfluss auf die Benutzersicht eines Systems. Die zentralen Pseudoanforderungen werden im Folgenden beschrieben. Interoperabilität In einem Bereich, in dem der sehr viele heterogene Systeme existieren, ist die effektive Zusammenarbeit zwischen den Systemen eine zentrale Herausforderung. Die Fähigkeit unabhängiger Systeme effektiv zusammenzuarbeiten, wird als Interoperabilität bezeichnet. Nur durch Interoperabilität ist eine Erweiterbarkeit des Systems mit vertretbarem Aufwand zu erreichen. Um eine solche Interoperabilität zu erreichen ist der Einsatz von offenen Standards, wie z.b. CORBA, vorgesehen. Hoher Grad von Codegenerierung Es soll bei der Systemrealisierung ein möglichst hoher Grad von Codegenerierung erreicht werden. Das Ziel dieser Anforderung ist ein System mit einer geringeren Fehlerquote und besserer Wartbarkeit. Die Codegenerierung aus Modellen soll außerdem zu einer gewissen Unabhängigkeit von Plattformen führen. Plattformunabhängigkeit Um etwa nicht an ein Betriebssystem gebunden zu sein, ist Plattformunabhängigkeit anzustreben. Als Implementierungssprache bietet sich aus diesen Grund Java an. Die Abhängigkeit von einem bestimmten Middleware Standard soll durch die Verwendung der Model Driven Architecture verhindert werden. 3.4 Anforderungsmodellierung In Abbildung 2 werden die Anwendungsfälle eines Video-Filetransfersystems aus Operatorsicht dargestellt. Welche Möglichkeiten soll also ein Anwender des Systems haben, einen Transfer zu initiieren, zu steuern und welche Informationen soll das System dem Anwender liefern. Im Folgenden werden nun die verschiedenen Anwendungsfälle beschrieben. 1. Transferauftrag erstellen Der wichtigste Anwendungsfall ist die Erstellung eines Transferauftrages. Dafür muss zunächst die zu übertragenden Datei angegeben werden. Diese Datei muss eventuell Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 20

22 3.4 Anforderungsmodellierung vom Operator manuell über SDI eingespielt werden. Falls sich das Material im Contentmanagementsystem der Rundfunkanstalt befindet, muss eine automatische Überspielung möglich sein. Die Recherche nach Material von Material ist jedoch nicht Teil dieses Anwendungsfall. Bei Push Betrieb ist zudem die Zielrundfunkanstalt oder auch mehrere Zielrundfunkanstalten anzugeben. Ist für den Transfer ein Ablieferungszeitpunkt einzuhalten, so muss dieser angegeben werden. Schließlich muss noch die Dienstklasse des Transfers spezifiziert werden. 2. Transfer abbrechen Ein Transfer muss sowohl durch den Operator der sendenden als auch vom Operator der empfangenden Rundfunkanstalt abgebrochen werden können. 3. Transfer pausieren Es muss für einen Operator möglich sein, einen gestarteten Transfer pausieren zu lassen. 4. Transfer wiederaufnehmen Ein pausierter Transfer muss durch einen Operator wiederaufgenommen werden können. 5. Status abfragen Ein Operator muss den Status des Transfers abfragen können. Dies beinhaltet die Fragen, ob der Transfer schon gestartet ist, viele Bytes schon übertragen worden sind oder ob der Transfer schon beendet ist. 6. Ablieferungszeit abfragen Ein Operator muss den vom System prognostizierten Ablieferungszeitpunkt abfragen können. 7. Metadaten abfragen Operatoren sollen die Metadaten des zu übertragenen Materials abfragen können. Eine Abfrage sollte auf der Empfängerseite auch schon vor dem Ende der Übertragung möglich sein. 8. Empfangenen Beitrag weiterleiten Nach Beendigung eines Transfers muss es auf der Empfängerseite möglich sein, einen Beitrag innerhalb der Rundfunkanstalt weiterzuleiten. 9. Loggingdaten abfragen Vom System geloggte Daten wie etwa Systemzustände, Zugriffe von Benutzern, Fehlerfälle, usw. müssen durch Benutzer und Administratoren abgefragt werden können. 10. Einspielen eines bestellten Beitrages Damit das System einen Transferauftrag ausführen kann, muss es Zugriff auf die zu Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 21

23 3.4 Anforderungsmodellierung übertragende Datei haben. Eine Einspielung von Material kann sowohl automatisch über das Contentmanagementsystem erfolgen, als auch manuell durch den Operator über SDI. 11. Eingabe von Metadaten Bei Einspielung von Material über SDI muss die manuelle Eingabe von Metadaten durch den Operator möglich sein. Abbildung 2: Anforderungsmodell aus Operatorsicht Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 22

24 4 Grobmodellierung des Video-Filetransfer In diesem Kapitel wird eine Grobmodellierung für den Video-Filetransfer durchgeführt. Es werden im Kapitel 4.1 für den Video-Filetransfer benötigte Komponenten identifiziert. Anschließend werden die Aufgaben dieser Komponenten beschrieben und die Abhängigkeiten zwischen ihnen erläutert. 4.1 Statische Modellierung Die Beschreibung der statischen Modellierung ist in zwei Unterkapitel aufgeteilt. Zunächst findet den Anforderungen entsprechend eine Unterteilung des Gesamtsystems in Komponenten statt. Anschließend wird die zentrale Komponente, das Transfersystem, weiter in Subkomponenten zerlegt Identifizierung von Komponenten Es folgt eine Beschreibung der am Transfer beteiligten Komponenten: Transfersystem Dies ist die zentrale Komponente des Video-Filetransfers. In dieser Komponente wird die Übertragung von Content zwischen den Rundfunkanstalten realisiert. Eine Clientapplikation kann bei dieser Komponente Transferaufträge anmelden. Um die zeitliche Reihenfolge der Transfers zu steuern, kommuniziert diese Komponente mit dem Transferdispositionssystem (siehe unten) der Rundfunkanstalt. Eine Zerlegung des Transfersystems in Subkomponenten findet weiter unten statt. Contentmanagementsystem/Archiv Aus dem Contentmanagementsystem bzw. Archiv muss das Material in die Transfersysteme transportiert werden, damit der Transfer in eine andere Rundfunkanstalt durchgeführt werden kann. Konverterkomponente Mit dieser Komponente lassen sich Dateien in das gewünschte Übertragungsformat konvertieren. Mit einer Konverterkomponente könnte etwa ein Beitrag über SDI eingespielt werden und in das Übertragungsformat MXF konvertiert werden. Diese Komponente sollte nicht Teil des Transfersystems sein, da Konvertierungsaufgaben meist sehr rechenintensiv sind, und deswegen eine Auslagerung auf einen anderen Rechner sinnvoll ist. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 23

25 4.1 Statische Modellierung Transferdispositionssystem Jede Rundfunkanstalt besitzt ein Transferdispositionssystem, in dem die zeitliche Abfolge der Transfers festgelegt wird. Das Transfersystem kommuniziert mit dem Transferdispositionssystem, um die Zeitpunkte der geplanten Transfers zu erfragen. Das Transferdispositionssystem kann über das Transfersystem den aktuellen Zustand der Transfers abfragen. Der Start der Transfers sollte so gesteuert werden, dass die vom Benutzer definierten Ablieferungszeitpunkte eingehalten werden können. Eine Diskussion über die Problematik der Ablieferungszeitpunkte und die daraus folgenden Aufgaben der Komponenten wird im Anschluss an die Beschreibung der Komponenten gegeben. Zentrales Dispositionssystem In einem zentralen Dispositionssystem können die Bandbreitenanforderungen der verschiedenen Rundfunkanstalten koordiniert werden. Clientapplikation Über eine Clientapplikation muss für einen Anwender die Möglichkeit bestehen, einen Transfer zu beantragen, zu steuern und Informationen über einen Transfer abzufragen. Um einen Transferauftrag zu erstellen, muss ein zu übertragender Beitrag ausgewählt werden. Die Auswahl des Beitrages sollte über ein getrenntes Browsingsystem erfolgen, mit dem im Contentmanagementsystem der eigenen bzw. anderer Rundfunkanstalten recherchiert werden kann. Es muss die Möglichkeit bestehen, einen Beitrag inklusive seiner Metadaten aus dem Contentmanagementsystem in das Transfersystem zu überspielen. Ein Beitrag muss auch manuell über SDI in das Transfersystem eingespielt werden können. Dafür muss zusätzlich eine Konverterkomponente verwendet werden. Ist der zu übertragende Beitrag für das Transfersystem verfügbar, so muss über die Clientapplikation ein Transferauftrag gestellt werden können. Dafür muss die Clientapplikation mit dem Transfersystem kommunizieren, auf dem sich der zu übertragende Beitrag befindet Auf welche Weise dies stattfindet wird hier nicht näher spezifiziert. Es muss über die Clientapplikation weiterhin die Möglichkeit bestehen, Informationen über aktuelle Transfers des Transfersystems anzuzeigen. Es muss auch die Darstellung der Metadaten eines zu übertragenden Beitrages möglich sein. Schließlich sollte die Darstellung von Loggingdaten des Transfersystems durch die Clientapplikation realisiert werden. Bandwidth Broker Die Transfersysteme beantragen bei dieser Komponente Bandbreite für ihre aktuell durchgeführten Transfers. Der Bandwidth Broker entscheidet über die Bandbreitenverteilung. Den Transfers kann bei der Bandbreitenanforderung eine Priorität zugewiesen werden, Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 24

26 4.1 Statische Modellierung mit der die Bandbreitenverteilung beeinflusst werden kann. Zum Beispiel könnten den oben beschriebenen Diensteklassen verschiedene Prioritäten zugeteilt werden. Mit welcher Strategie die Prioritäten ansonsten gesetzt oder auch während des Transfers verändert werden, soll hier jedoch nicht diskutiert werden. Die beschriebenen Komponenten und ihre Verteilung ist in dieser Arbeit durch ein UML- Verteilungsdiagramm dargestellt (siehe Abbildung 4). Es wurde bei den Anforderungen an den Video-Filetransfer beschrieben, dass für bestimmte Transfers Ablieferungszeitpunkte eingehalten werden müssen. Wie mit Hilfe der beschriebenen Komponenten Ablieferungszeitpunkte eingehalten werden können, soll im Folgenden kurz diskutiert werden. Der Startzeitpunkt der verschiedenen Transfers einer Rundfunkanstalt soll durch das Transferdispositionssystem vorgegeben werden. Für eine zeitgesteuerte Übertragung ist es notwendig, dass zum geplanten Zeitpunkt die benötigten Ressourcen für die Übertragung vorhanden sind. Welcher Art sind nun diese Ressourcen? Zum einen müssen der sendende sowie der empfangende Server genügend CPU-Leistung und Speicherplatz zur Verfügung haben, zum anderen muss im Netz genügend Bandbreite vorhanden sein. Doch was heißt genügend Bandbreite? Es muss auf jeden Fall soviel Bandbreite geliefert werden, dass die vom Operator definierte Deadline eingehalten wird. Sinnvoll wäre aber auch, wenn das Transferdispositionssystem für die einzelnen Transfer Zeitspannen vorgibt. Mit dieser Zeitspanne ist sogleich die benötigte Bandbreite festgelegt. Damit diese Bandbreite zum richtigen Zeitpunkt auch vorhanden ist, muss das Transferdispositionssystem die Bandbreite für Transfers reservieren. Da mehrere Rundfunkanstalten um die begrenzte Ressource Netz konkurrieren, muss die Reservierung koordiniert werden. Bei einer Netztopologie in der jede Rundfunkanstalt mit jeder anderen verbunden ist, müsste die Reservierung der Bandbreite jeweils nur zwischen der sendenden und der empfangenden Rundfunkanstalt koordiniert werden. Eine solche Vernetzung ist aber eher untypisch, da sie natürlich sehr kostspielig ist. Werden also in einer gewöhnlichen Topologie Netzabschnitte von mehreren Rundfunkanstalten gleichzeitig verwendet, so ist hier eine Koordinierung der Transferaufträge zu realisieren. Welche Möglichkeiten sind hier vorstellbar? Sinnvoll erscheint hier ein zentrale Dispositionssystem, bei dem jede Rundfunkanstalt ihre Bandbreitenwünsche mit Zeitpunkt und Zeitraum beantragen kann. Durch die Kommunikation zwischen den Transferdispositionssystemen der Rundfunkanstalten und dem zentralen Dispositionssystem ist eine effektive Zeitplanung der Transferaufträge möglich. Vorstellbar erscheint auch ein Szenario, in dem die Transferdispositionssysteme die Zeitplanung der Transferaufträge ohne eine zentrale Komponente realisieren. Allerdings dürfte die Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 25

27 4.1 Statische Modellierung Realisierung der Koordination zwischen den Transferdispositionssystemen relativ komplex sein. Aus diesem Grund erscheint ein zentrales Dispositionssystem sinnvoll. Die aktuelle Bandbreitenverteilung wird dann durch den Bandwidth Broker durchgeführt. Bei diesem beantragen die Transfersysteme jeweils für ihre laufenden Transfers Bandbreite. Dieser sorgt dafür, dass die Vorgaben der Transferdispositionssysteme so gut wie möglich erfüllt werden. Da eine zentrale Koordination der Aufträge stattgefunden hat, kann der Bandwidth Broker den verschiedenen Transfers genügend Bandbreite zuteilen, so dass die Zeitvorgaben erfüllt werden können. Das Transferdispositionssystem initiiert über das Transfersystem den Start der einzelnen Transfers und erhält über das Transfersystem Feedback über den Zustand der Übertragungen. Gibt es etwa Verzögerungen oder Fehler so kann das Transferdispositionssystem seine Zeitplanung anpassen. Bei der in dieser Arbeit durchgeführten Modellierung der Sendertransfereinheit wird nur der Bandwidth Broker betrachtet. Bei diesem soll keine Bandbreitenreservierung möglich sein. Der Bandwidth Broker führt die Bandbreitenverteilung aktueller konkurrierender Transfers durch. Eine Bandbreitenanforderung bei diesem Bandwidth Broker besteht aus der geforderten Bandbreite und einer Priorität. Für die Verwirklichung eines solchen Bandwidth Broker wäre eine Aufteilung des Gesamtnetzes in Segmente sinnvoll, wobei für jedes Segment ein Bandwidth Broker zuständig ist. Ein Bandwidth Broker muss dann die Topologie seines Segments und die benachbarten Bandwidth Broker kennen. Alle Bandbreitenanforderungen in einem Segment müssen bei dem jeweiligen Bandwidth Broker angefordert werden. Auf diese Weise kann er die Bandbreite innerhalb des Segments verteilen. Bei Verbindungen zwischen Segmenten ist eine Koordination zwischen den verantwortlichen Bandwidth Brokern notwendig. Eine genaue Realisierung eines solchen Bandwidth Broker wird in dieser Arbeit jedoch nicht näher diskutiert Unterteilung des Transfersystems in Komponenten Das Transfersystem ist die zentrale Komponente des Video-Filetransfers. Diese Komponente wird in diesem Kapitel nun in Subkomponenten aufgeteilt. Für eine der Subkomponenten, die Sendertransfereinheit, wird schließlich im Kapitel 5 eine detaillierte Modellierung vorgenommen. Die im Folgenden beschriebene Unterteilung in Subkomponenten wird auch durch ein UML-Komponentendiagramm verdeutlicht (siehe Abbildung 3). Auf die Aufgabe des Loggings wird in der Modellierung nicht weiter eingegangen. Über ein geeignetes Framework dürfte das Loggen von Informationen durch die Komponenten jedoch leicht zu realisieren sein. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 26

28 4.1 Statische Modellierung Transfermanagementsystem Das Transfermanagementsystem regelt die zeitgesteuerte Abspielung von Transfers. Dafür kommuniziert es mit dem Transferdispositionssystem. Das Transfermanagementsystem steuert das Einspielen, Weiterleiten des Materials, Initiieren des Transfers. Das Transfermanagementsystem regelt die getrennte Übertragung von Metadaten. Aus Abbildung 3 ist ersichtlich, das die Komponente Transfermanagementsystem für mehrere Sendertransfereinheiten bzw. Empfängertransfereinheiten zuständig sein kann. Sendertransfereinheit Diese Komponente ist für den Transfer einer einzelnen Datei zuständig. Mit dieser Komponente beschäftigt sich Kapitel 5. Empfängertransfereinheit Diese Komponente ist für das Empfangen einer Datei zuständig (siehe auch Kapitel 5). Netzwerkadapter Diese Komponente ermöglicht es Verbindungen zu anderen Transfersystemen aufzubauen mit einer vorher definierten Bandbreite. In der Komponente wird die Anpassung auf die verwendete Netzwerktechnologie vorgenommen. Repository Connector Diese Komponente realisiert den Zugriff auf das Contentmanagementsystem/Archiv. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 27

29 4.1 Statische Modellierung Abbildung 3: Komponenten des Transfersystems Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 28

30 4.1 Statische Modellierung Abbildung 4: Verteilung der Komponenten Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 29

31 5 Feinmodellierung der Sendertransfereinheit Nachdem nun eine Grobmodellierung des Systems durchgeführt wurde, wird in diesem Kapitel eine Komponente des Systems, die sogenannte Sendertransfereinheit feiner modelliert. Bevor mit der Modellierung begonnen wird, ist es natürlich notwendig eine genaue Beschreibung der Aufgaben der Komponente zu geben. Dies stellt den ersten Teil dieses Kapitels dar. Nachdem die Aufgaben der Komponente klar beschrieben sind, ist es möglich, die Schnittstelle der Komponente zu entwickeln. Die Realisierung dieser Schnittstelle spielt in diesem Entwicklungsstadium keine Rolle, es soll allein eine Sicht von außen auf die Komponente gegeben werden. Die Sendertransfereinheit benötigt zur Realisierung ihrer Aufgaben wiederum andere Komponenten, beispielsweise den Bandwidth Broker. Für eine Klassenmodellierung der Sendertransfereinheit ist es auch notwendig, die von der Sendertransfereinheit benötigten Schnittstellen festzulegen. Nach dieser Vorarbeit werden anschließend die Klassen der Sendertransfereinheit modelliert. Um die Verständlichkeit der Modellierung zu erhöhen, wird darauf eine dynamische Modellierung der Sendertransfereinheit durchgeführt. Eine Verwendung des dabei entwickelten UML- Sequenzdiagramms zur Codegenerierung ist jedoch mit dem Tool Arcstyler nicht möglich. Den Abschluss dieses Kapitels bildet schließlich eine Bewertung der durchgeführten Modellierung. 5.1 Anforderungsanalyse - Aufgaben der Transfereinheiten In diesem Kapitel werden nun die Aufgaben der Transfereinheiten näher beschrieben. Es wird also auch eine klare Abgrenzung zu den am Transfer beteiligten Komponenten stattfinden. Es existiert eine sendende und eine empfangende Transfereinheit. Das Transfermanagementsystem der sendenden Transfereinheit initiiert den Transfer. Die sendende Transfereinheit kontrolliert den Transfer. Wir nennen sie die Sendertransfereinheit. Die empfangende Transfereinheit nennen wir Empfängertransfereinheit. Die Aufgaben der beiden Transfereinheiten werden in den folgenden Unterkapiteln untersucht. Der Schwerpunkt der Modellierung in dieser Arbeit liegt bei der Sendertransfereinheit. Die Aufgaben der Empfängertransfereinheit werden beschrieben, um daraus eine geeignete Kommunikation zwischen den Transfereinheiten zu entwickeln. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 30

32 5.1 Anforderungsanalyse - Aufgaben der Transfereinheiten Sendertransfereinheit Zu Beginn dieses Kapitels wird ein kurzer Überblick über die prinzipiellen Aufgaben der Sendertransfereinheit gegeben. Darauf folgt eine detailliertere Beschreibung der funktionalen Anforderungen an die Transfereinheit. Die Anforderungen werden numeriert, damit in späteren Kapiteln darauf Bezug genommen werden kann. Am Ende des Kapitels wird ein Überblick über die nicht-funktionalen Anforderungen gegeben. Zunächst der Überblick über die Aufgaben der Sendertransfereinheit: die Sendertransfereinheit ist eine Softwarekomponente, die das Senden eines Files von einem Server A zu einem Server B realisiert. Sie ist immer nur für den Transfer eines Files zuständig. Sie kommuniziert dafür mit der Empfängertransfereinheit, zu der das File übertragen wird. Der Zeitpunkt des Transfers wird der Sendertransfereinheit vorgegeben. Der Transfer soll prinzipiell schnellstmöglich erfolgen. Für einen Transfer kann zusätzlich ein Ablieferungszeitpunkt definiert sein. Bis zu diesem Zeitpunkt muss das File übertragen worden sein. Wir bezeichnen diesen Ablieferungszeitpunkt als definierten Ablieferungszeitpunkt. Mit dieser Bezeichnung treffen wir eine Unterscheidung zu dem erwarteten Ablieferungszeitpunkt. Dieser Zeitpunkt ist der von der Sendertransfereinheit prognostizierte Ablieferungszeitpunkt. Wenn also beispielsweise der erwartete Ablieferungszeitpunkt hinter dem definierten Ablieferungszeitpunkt liegt, so ist dies kein erwünschter Zustand. Die Sendertransfereinheit ist dafür zuständig, die benötigte Bandbreite bei einem Bandwidth Broker anzufordern, so dass der definierte Ablieferungszeitpunkt eingehalten werden kann. Die strategische Entscheidung, ob die geforderte Bandbreite zugeteilt wird oder sogar mehr wird durch den Bandwidth Broker getroffen. Die Sendertransfereinheit reagiert auf die Zuweisung dementsprechend (z.b. mit einer Warnung an das Transfermanagementsystem, dass der definierte Ablieferungszeitpunkt nicht eingehalten werden kann). Mit der zugewiesenen Bandbreite wird schließlich das File übertragen. Welcher Protokollstack unterhalb der Transportschicht für die Übertragung verwendet wird und auf welche Weise die Verbindung aufgebaut wird, betrifft die Sendertransfereinheit nicht. Es wird davon ausgegangen, dass entsprechende Schnittstellen dafür zur Verfügung stehen. Über die Sendertransfereinheit muss außerdem der Transfer gesteuert werden können und es müssen Informationen über den Transfer abgefragt werden können. Im folgenden werden nun die Anforderungen numeriert aufgelistet. Funktionale Anforderungen der Sendertransfereinheit: A1 Schnellstmöglicher Transfer eines Files vom Transfersystem A in das Transfersystem B A1.1 Eine Sendertransfereinheit ist immer nur für einen Transfer zuständig A1.2 Start des Transfers wird durch das Transfermanagementsystem vorgenommen A1.3 Sendende Transfereinheit muss mit der entsprechenden empfangenden Transfereinheit Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 31

33 5.1 Anforderungsanalyse - Aufgaben der Transfereinheiten kommunizieren A2 Ein Ablieferungszeitpunkt muss definierbar sein und eingehalten werden A2.1 Bandbreitenmanagement muss unterstützt werden A2.1.1 Berechnung der benötigten Bandbreite vor dem Transfer A2.1.2 Berechnung der benötigten Bandbreite während des Transfers Anmerkung: Es muss während des Transfers eine ständige Kontrolle stattfinden, ob mit der vorhandenen Bandbreite die Einhaltung des definierten Ablieferungszeitpunktes gewährleistet ist. A2.1.3 Anpassung der Bandbreite während des Transfers (etwa nach einer Aufforderung zur Reduzierung der Bandbreite, oder Erhöhung der Übertragungsrate bei hohem Zellverlust) Anmerkung: Die Realisierung der Bandbreitenzuweisung ist nicht Teil der Sendertransfereinheit. Wir betrachten die Problematik nur oberhalb der ISO-OSI Schicht 4. Das heisst, wir gehen davon aus, wir können eine Verbindung zu einer anderen Transfereinheit aufbauen, bei der die Bandbreite nach Wunsch eingestellt werden kann. A2.2 Um Bandbreite anzufordern ist die Kommunikation mit einem Bandwidth Broker erforderlich A2.3 Der erwartete Ablieferungszeitpunkt soll berechnet werden können A3 Es sollen Transfers mit verschiedener Priorität möglich sein Anmerkung: Die Priorität eines Transfers hat Einfluss auf die Zuweisung von Bandbreite durch den Bandwidth Broker. Auf die Sendertransfereinheit hat die Priorität eines Transfers keinen Einfluss. A4 Die Sendertransfereinheit muss über folgende Steuerungsmöglichkeiten von außen verfügen: A4.1 Abbruch des Transfers A4.2 Pausieren des Transfers A4.3 Wiederaufnahme des Transfers A4.4 Änderung der Priorität des Transfers A4.5 Änderung des definierten Ablieferungszeitpunktes A5 Über die Sendertransfereinheit müssen folgende Informationen verfügbar sein A5.1 Der erwartete Ablieferungszeitpunkt A5.2 Es soll festgestellt werden können, ob der Transfer beendet ist A5.3 Die Priorität des Transfers A5.4 Der Status des Transfers (übertragene Bytes) Anmerkung: Hier wären sicher noch mehr Eigenschaften möglich, etwa ob eine Verbindung besteht, mit welcher Bandbreite gesendet wird, usw.. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 32

34 5.1 Anforderungsanalyse - Aufgaben der Transfereinheiten A6 Die Sendertransfereinheit muss auf mögliche Fehler entsprechend reagieren A6.1 Verbindungsfehler A6.1.1 Die Verbindung bricht ab A6.2 Fehler im Empfängertransfersystem A6.2.1 Im Empfängertransfersystem ist zuwenig Speicher verfügbar A6.2.3 Das Empfängertransfersystem stürzt ab A6.2.5 Die Empfängertransfereinheit sendet fehlerhafte Kommandos A6.3 Fehler im Sendertransfersystem A6.3.1 Das Sendertransfersystem stürzt ab A7 Die Sendertransfereinheit soll Logging über Zugriffe, Fehler durchführen. Pseudoanforderungen: B1 Die Sendertransfereinheit soll auf allen Plattform laufen B2 Als Modellierungstechnik soll UML verwendet werden B3 Es soll ein möglichst hoher Grad von Codegenerierung erreicht werden Die Anforderungen an die Sendertransfereinheit sind auch in Abbildung 5 dargestellt Empfängertransfereinheit In diesem Kapitel wird beschrieben, worin sich die Aufgaben der Empfängertransfereinheit von den Aufgaben der Sendertransfereinheit unterscheiden. Ein Unterschied besteht natürlich darin, wie der Name schon sagt, dass die Sendertransfereinheit das zu übertragende File sendet und die Empfängertransfereinheit das File empfängt. In der vorgestellten Modellierung gibt es jedoch noch weitere wichtige Unterschiede. Die Sendertransfereinheit stellt in dieser Modellierung die kontrollierende Transfereinheit dar. Über sie wird der Transfer initiiert. Weiterhin berechnet sie die benötigte Bandbreite und kommuniziert mit dem Bandwidth Broker. Nun werden die wichtigsten Unterschiede bei der Empfängertransfereinheit aufgelistet: Kein initiieren des Transfers Kein Bandbreitenmanagement notwendig Keine Kommunikation mit dem Bandwidth Broker Keine Berechnung des erwarteten Ablieferungszeitpunktes Dieser kann bei der Sendertransfereinheit erfragt werden. Zugriff auf den schon übertragenen Teil eines Files Die Möglichkeit auf Informationen über den Transfer zuzugreifen, sowie die Steuerungsmöglichkeiten von außen (z.b. Abbruch des Transfers) soll bei beiden Transfereinheiten identisch sein. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 33

35 5.1 Anforderungsanalyse - Aufgaben der Transfereinheiten Abbildung 5: Use Case für die Sendertransfereinheit Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 34

36 5.2 Systemanalyse 5.2 Systemanalyse Schnittstellen der Sendertransfereinheit In diesem Kapitel wird eine Sicht von außen auf die Sendertransfereinheit geboten. Die Frage ist also, welche Schnittstellen muss die Sendertransfereinheit anbieten, damit die oben beschriebenen Aufgaben erfüllt werden können. Es lassen sich aus den obigen Anforderungen drei Schnittstellen herausarbeiten (siehe auch Abbildung 6) : 1. Schnittstelle für das Transfermanagementsystem Diese Schnittstelle ist notwendig, um eine Steuerung des Transfers von außen durch das Transfermanagementsystem zu gewährleisten. Weiterhin soll das Transfermanagementsystem die Möglichkeit haben, über diese Schnittstelle Informationen über den Transfer abzufragen. 2. Schnittstelle für den Bandwidth Broker Der Bandwidth Broker muss auch die Möglichkeit haben, Nachrichten an die Sendertransfereinheit zu senden. Tritt etwa der Fall ein, dass auf der benutzten Verbindung ein höher priorisierte Transfer mehr Bandbreite benötigt, so muss der Bandwidth Broker die Möglichkeit haben, die Bandbreite anderer Transfers zu verringern. 3. Schnittstelle für die Empfängertransfereinheit Diese Schnittstelle ist notwendig, damit auch die Empfängertransfereinheit den Transfer steuern bzw. Informationen über den Transfer abfragen kann. Auch Fehlermeldungen können so zur Sendertransfereinheit übertragen werden. Im folgenden werden nun die Operationen der einzelnen Schnittstellen beschrieben und begründet. Davor noch ein Satz zur Namenswahl: in den Methodennamen wird nun der Begriff DeadlineTime für den definierten Ablieferungszeitpunkt und DeliveryTime für den erwarteten Ablieferungszeitpunkt verwendet (Begriffsdefinition siehe5.1.1). Schnittstelle für das Transfermanagementsystem starttransfer(atmaddress destination, int priority, time deadlinetime, file file) return transferid Das Transfermanagementsystem entscheidet zu welchem Zeitpunkt der Transfer gestartet wird. Dies wird mit dieser Methode realisiert (siehe Anforderung A1.2, A3, A2). canceltransfer() Das Transfermanagementsystem muss die Möglichkeit haben, einen gestarteten Transfer abzubrechen (siehe Anforderung A4.1). Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 35

37 5.2 Systemanalyse suspendtransfer() Mit dieser Methode kann ein Transfer pausiert werden (siehe Anforderung A4.2). resumetransfer() Mit dieser Methode kann ein pausierter Transfer wieder gestartet werden (siehe Anforderung A4.3). getdeliverytime() return time Über diese Methode kann der erwartete Ablieferungszeitpunkt abgefragt werden (siehe Anforderung A5.1). setpriority(int priority) Die Priorität eines Transfers kann über diese Methode im nachhinein verändert werden (siehe Anforderung A4.4). getpriority() return int Mit dieser Methode kann die Priorität abgefragt werden (siehe Anforderung A5.3). gettransferstatus() return long Mit dieser Methode kann der Status eines Transfers abgefragt werden (übertragene Bytes) (siehe Anforderung A5.4). isfinished() return boolean Mit dieser Methode kann das Transfermanagementsystem feststellen, ob ein Transfer beendet ist (siehe Anforderung A5.2). getdeadlinetime() return time Über diese Methode kann der definierte Ablieferungszeitpunkt abgefragt werden. setdeadlinetime(time time) Mit dieser Methode kann das Transfermanagementsystem den definierten Ablieferungszeitpunkt eines Transfers verändern (siehe Anforderung A4.5). getbandwidth() return int Mit dieser Methode kann die vom BandwidthBroker zugewiesene Bandbreite abgefragt werden. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 36

38 5.2 Systemanalyse geterrorcode() return int Falls ein Fehler aufgetreten ist, kann mit dieser Methode der Fehlercode abgefragt werden. Dafür muss für die möglichen Fehler jeweils ein Fehlercode definiert sein. getfilesize() return long Mit dieser Methode kann die Grösse der Datei abgefragt werden. Schnittstelle für den Bandwidth Broker modifybandwidth(int connectionid, int newbandwidth) Mit dieser Methode kann der Bandwidth Broker eine Sendertransfereinheit dazu auffordern, die Bandbreite anzupassen (siehe Anforderung A2.1.3). getminbandwidth() return int Mit dieser Methode kann der Bandwidth Broker die minimale Bandbreitenanforderung der Sendertransfereinheit abfragen. Dies kann hilfreich sein, falls zunächst mehreren Transfers eine höhere als benötigte Bandbreite zugewiesen wurde. Besteht nun durch weitere Transfers Bandbreitenknappheit, so kann der Bandwidth Broker von den Sendertransfereinheiten die minimale Bandbreitenanforderung abfragen und so schließlich deren Bandbreite reduzieren, so dass der definierte Ablieferungszeitpunkt noch eingehalten werden kann. Schnittstelle für die Empfängertransfereinheit canceltransfer() Falls über die Empfängertransfereinheit der Transfer abgebrochen wird, wird dies mit dieser Methode der Sendertransfereinheit mitgeteilt (siehe Anforderung A1.3). getdeliverytime() return time Über diese Methode kann die Empfängertransfereinheit den erwarteten Ablieferungszeitpunkt abfragen. restarttransfer(int marker) Mit dieser Methode wird die Sendertransfereinheit aufgefordert, den Transfer ab einer gewissen Marke wiederaufzunehmen. Dies kann verwendet werden, falls bei der Verbindung oder in einem der beiden Transfersysteme Probleme aufgetreten sind. Ist schon Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 37

39 5.2 Systemanalyse ein Teil der Datei übertragen worden, so muss die Übertragung nicht vollständig wiederholt werden, sondern der Transfer kann ab einer bestimmten Marke wiederaufgenommen werden. Voraussetzung dafür ist natürlich, dass die zu übertragende Datei mit Restart Marker versehen wurde. Das Konzept der Restart Marker wird in der Spezifikation zum File Transfer Protocol (FTP) beschrieben (siehe [PR85]). Diese Methode soll jedoch keinen Ersatz für die Fehlerkontrolle bei der Übertragung von Bits darstellen. Diese Aufgaben müssen von der Transportschicht übernommen werden. Diese Methode ist nur für schwerere Fehler gedacht, also falls beispielsweise die Verbindung komplett abbricht und wieder neu aufgebaut werden muss (siehe Anforderung A6). senderrorcode(int errorcode) Mit dieser Methode kann die Empfängertransfereinheit der Sendertransfereinheit Fehlermeldungen senden. (siehe Anforderung A6.2) addobserver(object observer) Mit dieser Methode kann die Empfängertransfereinheit Objekte als Beobachter des Transfers anmelden. Ändern sich Parameter (z.b. erwarteter Ablieferungszeitpunkt) des Transfers, so werden diese Objekte informiert. removeobserver(object observer) Mit dieser Methode werden angemeldete Objekte aus der Beobachterliste entfernt. Abbildung 6: Schnittstellen der Sendertransfereinheit Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 38

40 5.2 Systemanalyse Verwendete Schnittstellen der Sendertransfereinheit Es soll nun untersucht werden, welche Schnittstellen die Sendertransfereinheit verwendet, um die oben beschriebenen Aufgaben zu erfüllen. Diese Schnittstellen sollen im folgenden beschrieben werden und die Entscheidung dieser Wahl begründet werden. Es lassen sich hier vier benötigte Schnittstellen herausarbeiten (siehe auch Abbildung 7). 1. Schnittstelle des Transfermanagementsystem Über diese Schnittstelle soll das Transfermanagementsystem über wichtige Ereignisse der Sendertransfereinheit informiert werden. Etwa die Beendigung des Transfers oder Fehlermeldungen. 2. Schnittstelle des Bandwidth Broker Über diese Schnittstelle soll die Sendertransfereinheit zu Beginn des Transfers die benötigte Bandbreite beim Bandwidth Broker anfordern können. Auch während des Transfers soll es möglich sein, Anfragen an den Bandwidth Broker zu stellen, falls sich die Anforderungen ändern. 3. Schnittstelle der Empfängertransfereinheit Über diese Schnittstelle soll die Empfängertransfereinheit über Zustandsänderungen informiert werden (z.b. Transfer pausiert) und es sollen Informationen der Empfängertransfereinheit abgefragt werden können (z.b. Anzahl übertragene Bytes) 4. Schnittstelle des Netzwerkadapters Die Realisierung des Verbindungsaufbaus und die Realisierung der Bandbreitenanpassung ist nicht Aufgabe der Sendertransfereinheit. Aus diesem Grund muss diese Funktionalität ausgegliedert werden. Da zum derzeitigen Zeitpunkt nicht bekannt ist, wie diese Funktionalität realisiert wird, ist die Definition einer Adapter Klasse sinnvoll, die die benötigten Schnittstellen anbietet. Mit diesem Design Pattern ist eine spätere Anpassung auf neu implementierte Schnittstellen möglich. Im folgenden sollen nun die Operationen der einzelnen Schnittstellen beschrieben und begründet werden. Schnittstelle des Transfermanagementsystem update(int transferid, int eventid) Mit dieser Methode wird dem Transfermanagementsystem signalisiert, dass sich ein Parameter des Transfers geändert hat. Darauf kann das Transfermanagementsystem den Parameter abfragen. Beispielsweise könnte sich der erwartete Ablieferungszeitpunkt geändert haben (siehe Anforderung A5). Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 39

41 5.2 Systemanalyse Schnittstelle des Bandwidth Broker getbandwidth(int priority, int minbandwidth, int connectionid) Über diese Schnittstelle kann die Sendertransfereinheit Bandbreite beim Bandwidth Broker anfordern. Mit welcher Strategie die Bandbreite verteilt wird, ist Aufgabe des Bandwidth Broker. Damit dieser sinnvolle Entscheidungen treffen kann, erscheinen zwei Parameter sinnvoll. Zum einen die Mindestbandbreite, die ein Transfer benötigt, zum anderen die Priorität des Transfers. Die Mindestbandbreite ist sinnvoll, da auf diese Weise der Bandwidth Broker die Bandbreitenverteilung so auslegen kann, dass möglichst viele Transfers ihre definierten Ablieferungszeitpunkte einhalten können. Der Parameter Priorität ist notwendig, falls z.b. nicht genügend Bandbreite für alle Transfers zur Verfügung steht und der Bandwidth Broker deswegen nur bestimmten Transfers ausreichend Bandbreite zur Verfügung stellen kann (siehe Anforderung A2.2). releasebandwidth(int connectionid) Wird die Bandbreite von der Sendertransfereinheit nicht mehr benötigt, so wird dies dem Bandwidth Broker über diese Schnittstelle mitgeteilt (siehe Anforderung A2.2). Schnittstelle der Empfängertransfereinheit starttransfer() Über diese Schnittstelle wird die Empfängertransfereinheit informiert, dass der Transfer gestartet wird (siehe Anforderung A1.3). canceltransfer() Über diese Schnittstelle wird die Empfängertransfereinheit informiert, dass der Transfer abgebrochen wird (siehe Anforderung A1.3). suspendtransfer() Über diese Schnittstelle wird die Empfängertransfereinheit informiert, dass der Transfer pausiert wird (siehe Anforderung A1.3). resumetransfer() Über diese Schnittstelle wird die Empfängertransfereinheit informiert, dass ein pausierter Transfer wiederaufgenommen wird (siehe Anforderung A1.3). gettransferstatus() return long Mit dieser Methode kann der Status eines Transfers abgefragt werden (übertragene Bytes) (siehe Anforderung A1.3). Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 40

42 5.3 Platform Independent Model update() Mit dieser Methode wird der Empfängertransfereinheit signalisiert, dass sich ein Parameter des Transfers (z.b. erwarteter Ablieferungszeitpunkt) geändert hat. Darauf kann die Empfängertransfereinheit den Parameter abfragen (siehe Anforderung A1.3). Schnittstelle des Netzwerkadapters setupconnection(atmaddress destination, atmaddress source, int bandwidth) Mit dieser Methode kann eine Verbindung zum empfangenden Transfersystem mit einer gewissen Bandbreite aufgebaut werden. closeconnection() Mit dieser Methode wird eine bestehende Verbindung geschlossen. getbandwidth() return int Über diese Methode kann die Bandbreite einer bestehenden Verbindung abgefragt werden. setbandwidth(int bandwidth) Mit dieser Methode kann die Bandbreite einer bestehenden Verbindung geändert werden (siehe Anforderung A2.1.3). write(file file, int marker) Mit dieser Methode, wird ein File mit der festgelegten Bandbreite über die Netzwerkverbindung übertragen (siehe Anforderung A1). Das File kann auch ab einer bestimmten Marke übertragen werden. Diese Funktion ist sinnvoll, falls etwa der Transfer unterbrochen wurde und wieder fortgesetzt wird. 5.3 Platform Independent Model In diesem Kapitel soll nun ein Platform Independent Model der Sendertransfereinheit entwickelt werden. Die OMG definiert in ihrem MDA Guide ein Platform Independent Model folgendermaßen (siehe [OMG03]) : A platform independent model is a view of a system from the platform independent viewpoint. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 41

43 5.3 Platform Independent Model In dieser Definition wird jedoch noch keine Aussage über die Beschaffenheit einer Plattform gemacht. David Frankel bezeichnet Plattformunabhängigkeit in [Fra03] als einen relativen Term. Er stellt fest, dass es notwendig ist eine Plattform zu spezifizieren, um ein bestimmtes Modell als plattformunabhängig zu bezeichnen. Plattformunabhängigkeit wird nun in dieser Arbeit als Unabhängigkeit von verwendeter Implementierungssprache und Unabhängigkeit von Komponenten- sowie Messaging Middleware verstanden. Die Modellierung des Platform Independent Model ist in dieser Arbeit in eine statische und eine dynamische Modellierung unterteilt. Diese Modellierung wird in den folgenden Unterkapiteln beschrieben. Eine exemplarische Transformation des entwickelten PIMs wird in Kapitel 6.2 beschrieben. Diese Transformation wird mit dem MDA-Tool Arcstyler durchgeführt. Diese Transformation stellt eine direkte Umwandlung des PIMs in Code dar. Es wird kein UML-Modell erzeugt, das das Platform Specific Model repräsentiert. Abbildung 7: Benötigte Schnittstellen Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 42

44 5.3 Platform Independent Model Statische Modellierung In diesem Kapitel soll nun die statische Struktur des PIMs beschrieben werden. Für diese Beschreibung wird das wichtigste UML Konstrukt, das UML Klassendiagramm, verwendet (siehe Abbildung 8). Dieses Klassenmodell soll keine technischen Details enthalten, die etwa von verwendeter Middleware und Komponentenmodellen abhängig sind. Es werden nun aus den Aufgaben und den oben beschriebenen Schnittstellen die Klassen der Sendertransfereinheit entwickelt. Es werden zunächst die Aufgaben der Klassen kurz beschrieben. Anschließend folgt eine Beschreibung der Schnittstellen der Klassen. Die Aufgabe des Loggings wird in der folgenden Modellierung nicht beschrieben. Über ein geeignetes Loggingframework dürfte es nicht allzu schwierig sein, die Zugriffe bzw. Parameter des Transfers zu protokollieren. Da diese Aufgabe für den Ablauf bzw. die prinzipielle Funktion des Transfers jedoch nicht entscheidend ist, wird darauf hier nicht eingegangen. Aus den im vorigen Kapitel entwickelten Schnittstellen, lassen sich die ersten Klassen ableiten. Sowohl das Transfermanagementsystem, als auch der Bandwidth Broker, als auch die Empfängertransfereinheit benötigen eine Schnittstelle in der Sendertransfereinheit. Jeder dieser Schnittstellen wird eine Klasse zugewiesen. Das Transfermanagementsystem kann über die Klasse TransferManagementSystemRI auf die Sendertransfereinheit zugreifen, der Bandwidth Broker über die Klasse BandwidthBrokerRI und die Empfängertransfereinheit über die Klasse ReceiverTransferUnitRI. Die Methoden der Klassen entsprechen den oben beschrieben Schnittstellen. Es wurde oben beschrieben, dass für einen Transfer ein bestimmter Ablieferungszeitpunkt definiert werden kann. Dieser Zeitpunkt muss eingehalten werden. Um den definierten Ablieferungszeitpunkt einzuhalten, ist es notwendig, die benötigte Bandbreite zu berechnen, die es ermöglicht ein File innerhalb der Frist zu übertragen. Diese Aufgabe wird der Klasse Calculator zugewiesen. Aus der Anzahl der noch zu übertragenen Bytes und der verbliebenen Zeit wird die benötigte Bandbreite berechnet. Eine weitere Aufgabe der Klasse Calculator ist die Berechnung des erwarteten Ablieferungszeitpunktes. Da einem Transfer je nach Netzauslastung entweder mehr als die benötigte Bandbreite aber auch weniger vom Bandwidth Broker zugewiesen werden kann, können der erwartete Ablieferungszeitpunkt und der definierte Ablieferungszeitpunkt unterschiedlich sein. Die Klasse Transfer enthält Informationen, also Attribute über den Transfer. In dieser Klasse werden etwa die Priorität des Transfers, der erwartete Ablieferungszeitpunkt oder Fehlermeldungen gespeichert. Die anderen Klassen der Sendertransfereinheit sollen diese Attribute abfragen bzw. verändern können. Über diese Klasse soll es weiterhin möglich sein, Interessenten (auch ausserhalb der Sender- Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 43

45 5.3 Platform Independent Model transfereinheit) über Zustandsänderungen zu informieren. Ein Beispiel wäre etwa, die Änderung des erwarteten Ablieferungszeitpunktes. Über eine solche Änderung, müsste etwa das Transfermanagementsystem informiert werden. Eine weitere Zustandsänderung wäre etwa die Beendigung des Transfers, auch in diesem Fall sollte das Transfermanagementsystem benachrichtigt werden. Für eine solche Aufgabe bietet sich das Observer Pattern an (beschrieben in [GHJV95]). Eine zentrale Aufgabe der Sendertransfereinheit ist die Ablaufsteuerung des Transfers. Es sind etwa Bandbreitenanforderung beim Bandwidth Broker, Aufbau der Netzwerkverbindung zur Empfängertransfereinheit, zyklische Abfrage der schon übertragenen Bytes, zyklische Überprüfung des erwarteten Ablieferungszeitpunktes, usw. zu koordinieren. Der Ablauf dieser Aktionen wird durch die Klasse TransferControl gesteuert. Auch falls etwa der Transfer abgebrochen wird, ist die Klasse TransferControl für die Koordinierung der benötigten Aktionen zuständig. Nachdem nun die Aufgaben der einzelnen Klassen beschrieben worden sind, folgt eine Beschreibung der entwickelten Schnittstellen der Klassen. TransferManagementSystemRI Diese Klasse dient dazu, dem Transfermanagementsystem Zugriff auf die Sendertransfereinheit zu bieten. Die Methoden dieser Klasse wurden in Kapitel beschrieben. ReceiverTransferUnitRI Diese Klasse dient dazu, der Empfängertransfereinheit Zugriff auf die Transfereinheit zu bieten. Die Methoden dieser Klasse wurden ebenfalls in Kapitel beschrieben. BandwidthBrokerRI Diese Klasse dient dazu, dem Bandwidth Broker Zugriff auf die Transfereinheit zu bieten. Die Methoden dieser Klasse wurden ebenfalls in Kapitel beschrieben. Calculator calculatedeliverytime() return time Mit dieser Methode wird der erwartete Ablieferungszeitpunkt des Files berechnet. Grundlage für die Berechnung sind die Anzahl der noch zu übertragenden Bytes, sowie die aktuelle Bandbreite, mit der übertragen wird. calculaterequiredbandwidth() return int Mit dieser Methode wird die benötigte Bandbreite berechnet, mit der übertragen werden muss, um den definierten Ablieferungszeitpunkt einzuhalten. Grundlage Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 44

46 5.3 Platform Independent Model für die Berechnung sind die Anzahl der zu übertragenen Bytes, sowie die noch zu Verfügung stehende Zeit (siehe Anforderung A2.1.1, A2.1.2). Transfer Diese Klasse enthält Informationen über den Transfer. Um Interessenten, etwa das Transfermanagementsystem über Änderungen zu informieren, wird für diese Klasse das Observer Pattern verwendet. Um das UML-Klassendiagramm nicht unübersichtlich zu machen wird ist nicht das komplette Pattern in das Diagramm (siehe Abbildung 8) eingetragen. addobserver(object observer) Mit dieser Methode können Objekte als Beobachter des Objektes Transfer angemeldet werden. removeobserver(object observer) Mit dieser Methode werden angemeldete Objekte aus der Beobachterliste entfernt. addremoteobserver(object observer) Mit dieser Methode können Objekte, die nicht Teil der Sendertransfereinheit sind, als Beobachter des Objektes Transfer angemeldet werden. Die Unterscheidung zu der addobserver Methode ist sinnvoll, da für entfernte Objekte meist ein anderer Kommunikationsmechanismus verwendet wird. removeobserver(object observer) Mit dieser Methode werden angemeldete Remoteobjekte aus der Beobachterliste entfernt. notifyobservers() Der Zweck dieser Methode ist es, die angemeldeten Beobachter über einen Zustandswechsel zu informieren. Es könnte sich beispielsweise der erwartete Ablieferungszeitpunkt geändert haben. Dafür wird in den Beobachterobjekten die update() Methode aufgerufen. In unserem Fall wäre es die update Methode des Transfermanagementsystems. getdeliverytime() return time Mit dieser Methode kann der erwartete Ablieferungszeitpunkt abgefragt werden. setdeliverytime(time time) Mit dieser Methode kann der erwartete Ablieferungszeitpunkt gesetzt werden. geterrorcode() return int Mit dieser Methode können Fehlerzustände abgefragt werden. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 45

47 5.3 Platform Independent Model seterrorcode(int errorcode) Mit dieser Methode können bestimmte Fehlerzustände gesetzt werden. Ein Beispiel wäre etwa eine abgebrochene Verbindung. Über das Observer Pattern können Beobachter somit über Fehlerzustände informiert werden. getpriority() return int Mit dieser Methode kann die Priorität abgefragt werden. setpriority(int priority) Mit dieser Methode kann die Priorität gesetzt werden. isfinished() return boolean Mit dieser Methode kann abgefragt werden, ob der Transfer beendet ist. setfinished(boolean b) Mit dieser Methode wird das Ende des Transfers gesetzt. gettransferstatus() return long Mit dieser Methode kann die Anzahl der übertragenen Bytes abgefragt werden. settransferstatus(long status) Mit dieser Methode kann die Anzahl der übertragenen Bytes gesetzt werden. getfilesize() return long Mit dieser Methode kann die Grösse der zu übertragenen Datei abgefragt werden. getbandwidth() return int Mit dieser Methode kann die zugewiesene Bandbreite abgefragt werden. setbandwidth(int bandwidth) Mit dieser Methode kann die zugewiesene Bandbreite gesetzt werden. TransferControl Diese Klasse ist für die Ablaufsteuerung des Transfers zuständig. starttransfer(destination, priority, deadlinetime, file) In dieser Methode wird der Transfer gestartet. Es muss die benötigte Bandbreite angefordert werden, es muss eine Netzwerkverbindung aufgebaut werden und schließlich die Übertragung gestartet werden. Während des Transfers muss eine zyklische Überprüfung des erwarteten Ablieferungszeitpunktes stattfinden, sowie eventuelle erneute Anforderungen von Bandbreite beim Bandwidth Broker. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 46

48 5.3 Platform Independent Model suspendtransfer() In dieser Methode wird der Transfer pausiert. Es ist eine Benachrichtigung der Empfängertransfereinheit und des Bandwidth Brokers notwendig. resumetransfer() In dieser Methode wird der Transfer wiederaufgenommen. canceltransfer() In dieser Methode werden die benötigten Schritte realisiert, um den Transfer abzubrechen. Etwa Benachrichtigung der Empfängertransfereinheit, Benachrichtigung des Bandwidth Brokers, Trennen der Netzwerkverbindung. Abbildung 8: Klassenmodellierung Dynamische Modellierung Das Thema dieses Kapitels ist die dynamische Modellierung des Platform Independent Models der Sendertransfereinheit. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 47

49 5.3 Platform Independent Model Sequenzdiagramm In diesem Abschnitt soll mit einem Sequenzdiagramm ein möglicher Ablauf eines Transfers verdeutlicht werden (siehe Abbildung 9). Durch Sequenzdiagramme werden im Normalfall bestimmte häufige Abläufe eines Systems beschrieben. Dieses Diagramm eignet sich weniger dafür ein komplettes System zu spezifizieren. Es existieren zwar Modellkonstrukte mit denen auch Fallunterscheidungen oder auch Schleifen in Sequenzdiagrammen beschrieben werden können, aber dadurch werden Diagramme sehr schnell unübersichtlich und schwer zu lesen. Aus diesem Grund wird auch hier ein bestimmter, gewünschter Ablauf, der keine größeren Ausnahmesituationen enthält, beschrieben. Dieser Ablauf beinhaltet den Start des Transfers, die Überprüfung der Bandbreite während des Transfers und eine Veränderung der Bandbreite des Transfers. Im folgenden werden die einzelnen Schritte des Sequenzdiagramms näher erläutert. 1. starttransfer() Als erstes gibt das Transfermanagementsystem der Sendertransfereinheit das Signal, dass ein Transfer gestartet werden muss. 2. starttransfer() Die Nachricht starttransfer wird an das Objekt TransferControl weitergeleitet. Dieses Objekt übernimmt die Ablaufsteuerung des Transfers. 3. setdeadlinetime() In dem Objekt Transfer werden nun die Parameter des Transfers gespeichert. Damit das Sequenzdiagramm nicht zu unübersichtlich wird, wird hier stellvertretend nur der definierte Ablieferungszeitpunkt gespeichert. 4. addremoteobserver() Mit dieser Methode wird das Transfermanagementsystem als Beobachter des Objektes Transfer registriert. Dafür ist es allerdings notwendig, dass zuvor, etwa in der starttransfer Methode, eine Referenz auf ein Beobachterobjekt des Transfermanagementsystems mitgesendet wird. 5. addobserver() Das Objekt TransferControl registriert sich als Beobachter des Objektes Transfers. Auf diese Weise wird es über Zustandsänderungen informiert werden. Ein Beispiel wäre etwa eine neue Bandbreitenzuweisung vom Bandwidth Broker. 6. calculaterequiredbandwidth() Das Objekt Calculator berechnet die benötigte Bandbreite für den Transfer. Die Bandbreite wird so berechnet, dass der Transfer vor dem definierten Ablieferungszeitpunkt beendet ist. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 48

50 5.3 Platform Independent Model Abbildung 9: Sequenzdiagramm des Transfers Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 49

51 5.3 Platform Independent Model 7. getbandwidth() Nun wird vom Bandwidth Broker die berechnete Bandbreite angefordert. 8. modifybandwidth() Der Bandwidth Broker trifft die strategische Entscheidung, wieviel Bandbreite dem Transfer zugeteilt wird und benachrichtigt schließlich die Sendertransfereinheit mit dieser Methode. 9. setbandwidth() Im Objekt Transfer wird die zugewiesene Bandbreite gespeichert. 10. update() Nun wird das Objekt TransferControl über die zugewiesene Bandbreite informiert. 11. calculatedeliverytime() Nachdem die zugewiesene Bandbreite bekannt ist, kann der erwartete Ablieferungszeitpunkt berechnet werden. 12. setdeliverytime() Im Objekt Transfer wird der berechnete Ablieferungszeitpunkt gespeichert. 13. update() Gemäß dem Observer Pattern werden nun die Beobachter informiert, dass ein Zustandswechsel stattgefunden hat. Es können über die update Methode auch Information über die Art des Zustandswechsel mitgesendet werden. 14. getdeliverytime() Das Transfermanagementsystem kann nun über seine Schnittstelle den gesetzten Parameter abfragen. 15. getdeliverytime() Die Methode wird zum Objekt Transfer weitergeleitet. 16. return() Der erwartete Ablieferungszeitpunkt wird zurückgeliefert. 17. starttransfer() Die Empfängertransfereinheit wird kontaktiert. Diese führt nun Initialisierungsaufgaben durch. 18. addobserver() Die Empfängertransfereinheit registriert sich als Beobachter des Objektes Transfers. Hier könnte auch das Transfermanagementsystem der Empfängerrundfunkanstalt den Transfer beobachten. Die Registrierung erfolgt über die Schnittstelle der Empfängertransfereinheit. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 50

52 5.3 Platform Independent Model 19. addremoteobserver() Die Registrierung wird zum Objekt Transfer weitergeleitet. 20. setupconnection() Nun wird mit Hilfe des Network Adapters einen Datenverbindung mit der zugewiesenen Bandbreite aufgebaut. 21. setupconnection() Aufbauen der Verbindung. 22. write() Nun wird die Datei in die Empfängertransfereinheit übertragen. 23. gettransferstatus() Während der Übertragung findet eine zyklische Überprüfung der Anzahl der übertragenen Bytes statt. Daraus wird dann jeweils der erwartete Ablieferungszeitpunkt berechnet. 24. settransferstatus() Die Anzahl der übertragenen Bytes werden gespeichert. 25. calculatedeliverytime() Der erwartete Ablieferungszeitpunkt wird berechnet. 26. setdeliverytime() Der erwartete Ablieferungszeitpunkt wird gespeichert. 27. update() Das Transfermanagementsystem wird informiert. 28. update() Die Empfängertransfereinheit wird informiert. 29. gettransferstatus() Es findet wiederum die zyklische Überprüfung der Anzahl der übertragenen Bytes statt. Diese Prüfung findet in regelmäßigen Abständen statt, bis die Datei vollständig übertragen ist. 30. settransferstatus() Die Anzahl der übertragenen Bytes werden wieder gespeichert. 31. calculatedeliverytime() Der erwartete Ablieferungszeitpunkt wird wieder berechnet. Diesmal liegt der erwartete Ablieferungszeitpunkt hinter dem definierten Ablieferungszeitpunkt. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 51

53 5.3 Platform Independent Model 32. setdeliverytime() Der erwartete Ablieferungszeitpunkt wird gespeichert. 33. update() Das Transfermanagementsystem wird informiert. Eine Alternative wäre, das Transfermanagementsystem erst nach einer erneuten Bandbreitenanforderung zu informieren. 34. calculaterequiredbandwidth() Da die derzeitige Bandbreite nicht ausreicht, um den definierten Ablieferungszeitpunkt einzuhalten, muss die benötigte Bandbreite berechnet werden. 35. getbandwidth() Diese neue Bandbreitenanforderung wird nun dem Bandwidth Broker mitgeteilt. 36. modifybandwidth() Der Bandwidth Broker entscheidet über die neue Bandbreitenzuweisung und teilt sie der Sendertransfereinheit mit. 37. setbandwidth() Im Objekt Transfer wird wieder die zugewiesene Bandbreite gespeichert. 38. update() Nun wird das Objekt TransferControl informiert, dass eine Änderung stattgefunden hat. 39. getbandwidth() Das Objekt TransferControl fragt die zugewiesene Bandbreite ab. 40. setbandwidth() Nun wird die Bandbreite der bestehenden Datenverbindung dementsprechend angepasst. 41. calculatedeliverytime() Darauf wird wieder der erwartete Ablieferungszeitpunkt berechnet. 42. setdeliverytime() Der erwartete Ablieferungszeitpunkt wird im Objekt Transfer gespeichert. 43. update() Die Empfängertransfereinheit wird über die Zustandsänderung informiert. 44. update() Die Transfermanagementsystem wird über die Zustandsänderung informiert. Falls der neue erwartete Ablieferungszeitpunkt immer noch hinter dem definierten Ablieferungszeitpunkt liegt, so hat das Transfermanagementsystem die Möglichkeit die Priorität des Transfers erhöhen. Diese Priorität hätte einen Einfluss auf die Bandbreitenzuteilung des Bandwidth Broker. Auf welche Weise die Prioritäten vergeben werden, soll hier jedoch nicht diskutiert werden. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 52

54 5.3 Platform Independent Model 45. setfinished() Sobald die Datei vollständig übertragen ist, sendet der NetworkAdapter eine Nachricht an das Objekt Transfer. 46. update() Das Objekt TransferControl wird über die Beendigung des Transfers informiert. 47. update() Das Transfermanagementsystem wird über die Beendigung des Transfers informiert. 48. closeconnection() Nun wird die Datenverbindung geschlossen. 49. releasebandwidth() Abschließend wird dem Bandwidth Broker das Ende das Transfers signalisiert, damit dieser die Bandbreite wieder verteilen kann. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 53

55 6 Praktische Umsetzung der Modellierung Nachdem in den vorigen Kapiteln die Problematik des Video-Filetransfers untersucht wurde und darauf aufbauend eine Sendertransfereinheit modelliert wurde, soll in diesem Kapitel nun die praktische Umsetzung der Modellierung und die Möglichkeiten der Codegenerierung beschrieben werden. Die Modellierung wurde mit dem MDA-Tool ArcStyler 4.0 von Interactive Objects Software GmbH (siehe [Sofa]) durchgeführt. Um den Leser einen Überblick über die Fähigkeiten dieses Tools zu geben, wird in diesem Kapitel eine kurze Einführung für ArcStyler gegeben. Nach dieser Einführung folgt die Beschreibung der Modellierung und der Codegenerierung der Sendertransfereinheit mit ArcStyler. Abschließend wird ein kurze Bewertung des MDA-Tools ArcStyler gegeben. 6.1 ArcStyler eine kurze Einführung In diesem Kapitel soll eine kurze Einführung in das MDA-Tool ArcStyler gegeben werden. Zunächst wird ein Überblick über die Funktionalitäten von ArcStyler gegeben. Anschließend folgt eine Beschreibung der grafischen Benutzerschnittstelle. Lassen wir für die Beschreibung zunächst den Hersteller zu Worte kommen. Auf folgende Weise beschreibt io-software sein Produkt ArcStyler (siehe [Sofb]): ArcStyler ist eine ausgereifte und vielfach bewährte Software- Entwicklungsumgebung für Model Driven Architecture (MDA). Als plattformunabhängige, reine Java-Anwendung ist Arc- Styler ein komplett standardkonformes und nahtlos integriertes Entwicklungssystem für Entwurf, Modellierung, Generierung, Deployment und Management von Anwendungen beliebiger Größe sowohl für Standardarchitekturen wie Java/J2EE und.net als auch für kundenspezifische Infrastrukturen und jede Art von Legacy-Plattform. Arcstyler ist also eine Entwicklungsumgebung, die Modelle in den Mittelpunkt stellt, um aus diesen Modellen unter anderem Code, Buildskripte, Deploymentdeskriptoren und Projektdateien für IDEs (z.b. Eclipse und JBuilder) zu generieren. Die Modelle in ArcStyler können mit der integrierten UML-Engine Magic Draw (siehe [Inc]) entwickelt werden, es können aber auch andere UML-Werkzeuge über die Tool Adapter Standard (TAS) API verwendet werden. Für die Abbildung der Modelle auf Standardarchitekturen, wie J2EE oder.net, können verschiedene Cartridges ausgewählt werden, in welchen die Transformationsregeln definiert sind. Es sind Standard-Cartridges vorhanden, etwa für Java2 oder EJB2.0, die auch vom Anwender angepasst werden können. Desweiteren können eigene Cartridges entwickelt werden. Über Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 54

56 6.1 ArcStyler eine kurze Einführung eine Open-Source Community (siehe [Com]) sind weitere Cartridges erhältlich. Zum Beispiel findet sich hier eine Cartridge zur Generierung von Benutzeroberflächen. Es besteht auch die Möglichkeit, bestehenden Java/EJB Code nach ArcStyler zu importieren. Diese Technik wird als Harvesting bezeichnet und im ArcStyler Platform Guide (siehe [Sof03b]) näher beschrieben. Diese Möglichkeit ist sinnvoll, falls etwa schon Code vorhanden ist und man trotzdem die Vorteile der MDA nutzen will. Da eine Aufzählung aller Funktionalitäten den Rahmen sprengen würde, wird für weitere Informationen auf die Dokumentation zu ArcStyler verwiesen. Nach dieser Beschreibung wollen wir die GUI von ArcStyler näher betrachten. Entscheidend ist hier das Konzept der Perspektiven. Die Werkzeuge von ArcStyler können in verschiedenen Perspektiven gruppiert werden. Diese Perspektiven entsprechen den Rollen, die ein Benutzer des Programmes einnimmt. Es existiert etwa die Rolle des Cartridge-Anwenders, der plattformunabhängige Modelle entwickelt und es existiert die Rolle des Cartridge-Entwicklers, der neue Transformationsregeln entwickelt. In der Oberfläche werden diese Perspektiven als Modelling Perspective (siehe Abbildung 10) bzw. Cartridge Perspective (siehe Abbildung 11) bezeichnet. In den Abbildungen 10 und 11 sind die Werkzeuge der jeweiligen Perspektive gekennzeichnet. In den Abbildungen sind jedoch nicht alle Werkzeuge gleichzeitig sichtbar. In diesem Fall sind die Button gekennzeichnet, mit denen die Werkzeuge aufgeklappt werden können. Die Werkzeuge der beiden Perspektiven werden im Folgenden beschrieben. Modelling Perspective UML Tool Mit diesem Tool können die UML-Modelle entwickelt werden. In ArcStyler ist das UML-Tool MagicDraw integriert. Project Info Hier lassen sich Informationen über das MDA Projekt anzeigen. Ant Ant (siehe [Fou]) ist ein Buildtool, das verschiedene Aufgaben bei der Softwareentwicklung, wie z.b. Compilieren und Testen, automatisiert. Dieses Kommandozeilen- Werkzeug kann in ArcStyler über die GUI gesteuert werden. Logs Über dieses Tool werden dem Anwender Loggingdaten angezeigt. Bei der Generierung von Artefakten aus den entwickelten Modellen, werden dem Benutzer hier die erzeugten Dateien, sowie auftretende Fehlermeldungen angezeigt. Desweiteren werden hier Systemmeldungen von ArcStyler aufgelistet. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 55

57 6.1 ArcStyler eine kurze Einführung Project Info ANT UML-Tool Logs Abbildung 10: ArcStyler GUI - Modelling Perspective Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 56

58 6.1 ArcStyler eine kurze Einführung Project Info Cartridges Cartridge Editor Debugger Repository Browser Logs Abbildung 11: ArcStyler GUI - Cartridge Perspektive Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 57

59 6.2 Modellierung und Generierung der Komponente mit ArcStyler Cartridge Perspective Cartridge Editor Mit diesem Text Editor können Cartridges entwickelt und bearbeitet werden. Repository Browser Mit diesem Browser kann der Anwender das aktive UML-Modell durchblättern. Cartridges Hier werden die aktuell geladenen Cartridges angezeigt. Project Info Siehe Modelling Perspective. Debugger Mit diesem Tool ist das Debuggen von Cartridges möglich. Logs Siehe Modelling Perspective. Für eine ausführliche Dokumentation der Tools und Perspektiven wird auf den ArcStyler Platform Guide (siehe [Sof03b]) verwiesen. 6.2 Modellierung und Generierung der Komponente mit ArcStyler In diesem Kapitel soll nun die Modellierung und Codegenerierung der Sendertransfereinheit beschrieben werden. Es wurde für die Codegenerierung die Java2 Cartridge verwendet. Diese Wahl soll jedoch keine Vorgabe für eine spätere Realisierung sein. Das Ziel in dieser Arbeit war, exemplarisch das Prinzip der Codegenerierung zu untersuchen. Zunächst wurde mit ArcStyler ein neues Java2 Projekt angelegt. Um die zu entwickelnden Modelle zu gruppieren wurde ein UML-Package erzeugt. In diesem Fall wurde das Package Diplomarbeit genannt. In diesem Package wurden darauf Subpackages für die identifizierten Komponenten erzeugt (siehe Abbildung 12). Diesen Packages kann nun über das Kontextmenu ein Hauptdiagramm zugewiesen werden. Dem Package sendertransferunit aus der Abbildung 12 wurde etwa das oben beschriebene Klassendiagramm (siehe Abbildung 8) als Hauptdiagramm zugewiesen. Den anderen Packages wurden jeweils die oben spezifizierten Schnittstellen als Klassendiagramm zugewiesen. Durch diese Verknüpfung kann nun durch einen Doppelklick auf das Package das dazugehörige Hauptdiagramm geöffnet werden. Über die Packages lassen sich natürlich auch Diagramme gruppieren, die nicht zur Codegenerierung verwendet werden, wie z.b. Use Case Diagramme. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 58

60 6.2 Modellierung und Generierung der Komponente mit ArcStyler In dem Fall der Sendertransfereinheit wurde nun das Klassendiagramm entwickelt. Die Eigenschaften einer Klasse können über das Class Specification Fenster (siehe Abbildung 13) modelliert werden. Dieses Fenster kann über einen Doppelklick auf die entsprechende Klasse oder mit Hilfe des Kontextmenus geöffnet werden. Abbildung 12: Gruppierung der UML-Modelle Die für die Sendertransfereinheit verwendeten Bereiche der Spezifikation werden nun beschrieben: General Hier wird der Name der Klasse spezifiziert und sowie unter anderem ihre Sichtbarkeit. Attributes Es können Attribute für die Klasse spezifiziert werden. Für diese Attribute können unter anderem Eigenschaften wie Typ, Sichtbarkeit und Initialwert angegeben werden. Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 59

61 6.2 Modellierung und Generierung der Komponente mit ArcStyler Operations Die Operationen können ebenfalls mit einer Reihe von Eigenschaften wie unter anderem Sichtbarkeit, Rückgabetyp und Parameter spezifiziert werden. MDA Marks In diesem Bereich läßt sich unter anderem spezifizieren, ob eine Klasse Remote Eigenschaften besitzen soll (siehe Abbildung 13). Weiter unten wird beschrieben, welche Auswirkung die Auswahl der Remote Eigenschaft auf die Codegenerierung hat. An diesem Beispiel soll exemplarisch die Umsetzung des MDA Prinzips in ArcStyler erläutert werden. Für eine detaillierte Beschreibung dieser Eigenschaften wird auf den ArcStyler Users Guide (siehe [Sof03a]) verwiesen. Nach der Beschreibung der Spezifikation wollen wir die Codegenerierung aus den Modellelementen untersuchen. Für ein Modellelement, eine Klasse etwa, kann die Codegenerierung unter anderem über das Kontextmenu gestartet werden. Abbildung 13: RMI Aktivierung in der MDA Spezifikation Betrachten wir exemplarisch die Klasse TransferManagementSystemRI. Diese Klasse enthält eine Reihe von Operationen mit jeweiligen Parametern und Rückgabewerten. Auf die Operationen der Klasse soll auch von entfernten Objekten zugegriffen werden können (es ist also in der Spezifikation der Klasse die Remote Eigenschaft gesetzt). Diese Eigenschaft besagt noch nichts über die verwendete Technologie. In unserem Fall soll nun diese Eigenschaft mit Remote Method Invocation realisiert werden. Dafür wird die Java2 Cartridge verwendet. Wir bilden nun also eine plattformunabhängige Eigenschaft auf eine spezifische Plattform ab. Nach dem Spezifikation und Codegenerierung einer Video-Filetransfer Komponente in UML 60