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

Größe: px
Ab Seite anzeigen:

Download "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

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

Mehr

Michael Piechotta - CASE Tools. openarchitecture Ware

Michael Piechotta - CASE Tools. openarchitecture Ware Model Driven Development Michael Piechotta - CASE Tools openarchitecture Ware Gliederung 1.Einleitung - Was ist MDD? - Wozu MDD? 2.Model Driven Development - OMG Konzepte: Modelle,Transformationen Meta-Modellierung

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

Mehr

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

Mehr

UML 2.0 Quelltextgenerierung

UML 2.0 Quelltextgenerierung UML 2.0 Quelltextgenerierung Seminararbeit im Fach Informatik im Rahmen des Seminars Sicherheitskritische Systeme an der Universität Siegen, Fachgruppe für Praktische Informatik eingereicht bei Dr. Jörg

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

SysML Die Zukunft des Systems Engineering?

SysML Die Zukunft des Systems Engineering? ECC 2012 Winterthur 5. Juni 2012 SysML Die Zukunft des Systems Engineering? Omar Naas, Senior Consultant, EVOCEAN GmbH 1934 Citroën 2CV Citroën Direktor Pierre-Jules Boulanger definierte 7 Anforderungen,

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme Gerhard Wanner (wanner@hft-stuttgart.de) Stefan Stefan Siegl Siegl (s.siegl@novatec-gmbh.de) Agenda Model Driven Architecture (MDA) Einführung/Übersicht/Motivation

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg Modellgetriebene Softwareentwicklung von mobilen Anwendungen WS 2014/15 Philipps-Universität Marburg Organisation der LV Umfang: 6 SWS, 9 ECTS Punkte Veranstalter:, Daniel Strüber, Steffen Vaupel Kontakt:

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 5. UML Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 5. UML 2 Unified Modeling Language (UML) Standardisierte grafische Notationen um Strukturen und Abläufe eines

Mehr

Christian Kurz SWT Projekt WS 07/08

Christian Kurz SWT Projekt WS 07/08 Christian Kurz SWT Projekt WS 07/08 1. Allgemeine Aspekte der generativen GUI- Entwicklung 2. Entwicklung mit Hilfe von GUI-Designern 3. Entwicklung mit Hilfe deklarativer GUI- Sprachen 4. Modellgetriebene

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Stefan Link, Thomas Schuster, Philip Hoyer, Sebastian Abeck Institut für Telematik, Fakultät für Informatik Universität Karlsruhe (TH)

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

SECTINO. Security for Inter-Organizational Workflows

SECTINO. Security for Inter-Organizational Workflows SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering

Mehr

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de Beispielhaft MDSD in der Praxis Dr. Shota Okujava shota.okujava@isento.de www.isento.de Agenda Einführung Softwareentwicklungsprozess und MDSD Technologien und Werkzeuge Demo Entwicklung der Metamodelle

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Dipl. Inform. Olaf Maibaum DLR, Abt. Simulations- und Softwaretechnik DLR, Abt. Simulations- und Softwaretechnik 1 Übersicht Bird-Satellit

Mehr

Buddy - Algorithmus Handbuch für Endnutzer Stand 02.08.2005

Buddy - Algorithmus Handbuch für Endnutzer Stand 02.08.2005 Buddy - Algorithmus Handbuch für Endnutzer Stand 02.08.2005 1. Vorwort 1 2. Systemvoraussetzungen 2 3. Programmarten 2 4. Sicherheit der Endnutzer 2 5. Handhabung 3 5.1 allgemeine Programmübersicht 3 5.2

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

LiLa Portal Leitfaden für Dozierende

LiLa Portal Leitfaden für Dozierende Library of Labs Lecturer s Guide LiLa Portal Leitfaden für Dozierende Meist werden Dozierende die Lerninhalte ihrer Studierenden festlegen und aus der großen Auswahl von LiLa Experimenten diejenigen auswählen,

Mehr

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik

Mehr

Graphischer Editor für die technologieunabhängige User Interface Modellierung

Graphischer Editor für die technologieunabhängige User Interface Modellierung Universität Augsburg Lehrstuhl für Softwaretechnik und Programmiersprachen Prof. Dr. Bernhard Bauer Praktikum Modellgetriebene Softwareentwicklung SS 2008 Graphischer Editor für die technologieunabhängige

Mehr

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation WF2Trans Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation Aus unserer langjährigen Erfahrung in Kundenprojekten wissen wir, dass ein klares und eindeutiges

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Tanja Schmedes Betriebliches Informationsmanagement OFFIS Institut für Informatik tanja.schmedes@offis.de MKWI 2008

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Aspektorientierte Modellierung

Aspektorientierte Modellierung Aspektorientierte Modellierung Softwaretechnik-Seminar 2002 Thema: Evolutionäre Software Referent: Alexander Winter Gliederung Einführung und Motivation Was ist Aspektorientierte Modellierung? Vorstellung

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

Mehr

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems Michael Gebhart (1), Jürgen Moßgraber (2), Thomas Usländer (2), Sebastian Abeck (1) (2) (1) Cooperation & Management, Karlsruher Institut

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Das Komponentendiagramm Dient Darstellung

Mehr

Einführung in die Unified Modeling Language (UML)

Einführung in die Unified Modeling Language (UML) Einführung in die Unified Modeling Language (UML) Hausarbeit zum Proseminar Datenbanken Wintersemester 2002/03 Seminarleitung: Dr. Christoph Draxler Verfasserin: Michaela Geierhos Centrum für Informations-

Mehr

3 Das verbindungslose Vermittlungsprotokoll IP

3 Das verbindungslose Vermittlungsprotokoll IP Das verbindungslose Vermittlungsprotokoll IP 27 3 Das verbindungslose Vermittlungsprotokoll IP In diesem Kapitel lernen Sie das verbindungslose Vermittlungsprotokoll IP näher kennen. Nach dem Durcharbeiten

Mehr

Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Modellgetriebene Softwareentwicklung bei der IBYKUS AG Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

TUDOOR - Ein Java Adapter für Telelogic DOORS

TUDOOR - Ein Java Adapter für Telelogic DOORS TUDOOR - Ein Java Adapter für Telelogic DOORS Jae-Won Choi, Anna Trögel, Ingo Stürmer Model Engineering Solutions GmbH Abstract: Im Bereich des Requirements Engineering hat sich DOORS der Firma Telelogic

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03. Software-Engineering 2 Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.2009 1 Entwicklungsumgebungen, CASE-Tools, CASE-Werkzeuge unterstützen den Software-Entwicklungsprozess

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Do 8.3. Schwarzweiss. Peter Hruschka. January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich

Do 8.3. Schwarzweiss. Peter Hruschka. January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Do 8.3 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Schwarzweiss Peter Hruschka schwarzweiß Peter Hruschka Principal of the Atlantic Systems Guild Aachen - London - New

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

Mehr

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems Diplomarbeit an der Private Fernfachhochschule Darmstadt Fachbereich Informatik Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

Konzept / Architektur Diagramme

Konzept / Architektur Diagramme Architektur-Modell Konzept / Architektur Diagramme Im Übergang Analyse Design wird das System konzipiert und seine Architektur entworfen: Subsystem-Modell (execution view) UML 1.x Package Diagram «subsystem»

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

***** BEGINN DER SOFTWARE REQUIREMENTS SPECIFICATION *****

***** BEGINN DER SOFTWARE REQUIREMENTS SPECIFICATION ***** Wichtige Fragen, die noch zu klären sind: Wichtig für die Funktion Ressourcenverwaltung: Können Filialmitarbeiter selbstständig Material und Werkzeug etc. nachbestellen oder meldet der Mitarbeiter (evtl.

Mehr

A classification and comparison framework for software architecture description languages

A classification and comparison framework for software architecture description languages A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr