Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf1 SOFA & DCUP Software Appliances & Dynamic Component Update

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf2 Das SOFA-Project l SOFA steht für Software Appliances l Gründer des SOFA-Projects: uAbteilung für Software-Entwicklung der Karls-Universität Prag, Tschechische Republik uZiel: Entwicklung einer Software-Umgebung mit besonderem Augenmerk auf die Beziehung zwischen Software-Anbieter und Software-Benutzer l Aktueller Entwicklungsstand: uPrototyp in Java 2 uExperimentelle Implementation in C++

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf3 Ziele und Prinzipien von SOFA l Dynamischer Download von Komponenten l Dynamisches Update von Komponenten zur Laufzeit (DCUP) l Komponenten-Hierarchie l Einsatz auf verteilten Systemen l Verschiedene Komponenten-Versionen parallel

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf4 SOFA Component Model l Grundlegende Eigenschaften von SOFA Applikationen sind durch das SOFA Component Model fest definiert. l Eine SOFA Komponente besteht grundsätzlich aus: uProvided und Required Interfaces uFrame (black-box view) uArchitecture (gray-box view) uConnectors uBehaviour protocols

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf5 SOFA-Components l Primitive Component uEnthält keine weiteren Subkomponenten sondern ist direkt implementiert uEnthält letztendlich alle Funktionalitäten · Atomare Teile des Baukastenprinzips –(Analogie: LEGO-Steine) l Composed Component uAusschließlich zusammengesetzt aus anderen Komponenten uEnthält keine eigentlichen Funktionalitäten, sondern benutzt und kombiniert die Funktionalitäten anderer Komponenten · Baukastenprinzip –(Analogie: Gebilde aus LEGO-Steinen)

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf6 Frame/Black-Box-Ansicht l Das Frame ist die Black- Box-Ansicht einer Komponente uInhalt der Black-Box ist nicht bekannt, sondern nur die Funktion urequires und provides Interfaces zum Verbinden mit anderen Komponenten · Baukastenprinzip Black-Box Provides Interfaces Requires Interfaces Black-Box-Ansicht einer Komponente

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf7 Architecture/Grey-Box-Ansicht I l Die Architecture beschreibt das Innere eines Frames uPrimitive Components sind direkt implementiert in einer beliebigen Programmiersprache uEinem Frame können mehrere Architectures zugrunde liegen · Verschiedene Versionen Gray-Box-Ansicht einer Primitive Component While... If... Then... Else... usw. Sourcecode

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf8 Architecture/Grey-Box-Ansicht l Die Architecture beschreibt das Innere eines Frames uComposed Components bestehen aus miteinander verknüpften Unterkomponenten uEinem Frame können mehrere Architectures zugrunde liegen · Verschiedene Versionen binding delegating subsuming exempting Gray-Box-Ansicht einer Composed Component

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf9 Hierarchie While... If... Then.... Usw.

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf10 Component Definition Language (CDL) I l CDL ist die SOFA-Sprache zur Definition von Komponenten l CDL dient zur Beschreibung von : uInterfaces uFrames uArchitectures uBindings uProtocols l Basiert auf OMG IDL uOMG = Object Management Group uIDL = Interface Definition Language

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf11 interface Login { CentralPlayerServices login(in string who); }; frame Client { provides: Client iClient; requires: Login iLogin; CentralPlayerServices iCPS; }; architecture CUNI GameGen implements GameGenerator { inst GameGeneratorDBServices aGGDBS; inst ConfigurationFileParser aConfig; inst GameGeneratorFunctionality func; bind func:iConfig to aConfig:iConfig; bind func:iGGDB to aGGDBS:iGGDB; subsume aGGDBS:iDatabase to iDatabase; }; Component Definition Language (CDL) II Sourcecode-Beispiel in CDL (Quelle: SOFA Implementation Manual) Return-Typ: CentralPlayerServices Name: login Eingabe-Typ: String Interface-Definition Name: Login Frame-Definition Name: Client provided und required Interfaces werden definiert Architecture-Definition inst = Instanzierung Connectors werden definiert

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf12 Type Information Repository (TIR) I l CDL-Beschreibungen werden im Type Information Repository (TIR) kompiliert und verwaltet l Jedes Element im TIR ist eindeutig identifiziert durch uSeinen Namen · Definiert in der CDL-Spezifikation uSeine Specification Version · Die Version eines neuen Elements wird automatisch anhand des TIR-Inhalts und des gewählten Profiles berechnet. l Ein Profile ist eine Liste von Tupeln der Art (Name, Version) uBestimmt die richtige Version beim Kompilieren

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf13 Type Information Repository (TIR) II l Die Versions-Wahl beim Kompilieren geschieht nach folgenden Prioritäten: 1)Der Entwickler hat die gewünschte Version direkt in der CDL- Definition vorgeschrieben 2)Dem Namen der Komponente wird im aktiven Profil eine Version zugeordnet 3)Die neueste Version wird gewählt

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf14 Connectors binding subsuming delegating exempting Grey-Box-Ansicht einer Composed Component l Connectors realisieren die Verbindungen zwischen Interfaces l SOFA behandelt Connectors analog zu Komponenten: uPrimitve Connector · Direkt implementiert uComposed Connector · Zusammengesetz aus primitive C.s l Drei vordefinierte Connectors: uCSProcCall uEventDelivery uDataStream Zur Erinnerung:

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf15 Events l Es gibt vier verschiedene Events, die bei der Kommunikation zwischen Komponenten auftreten können l In dem von uns betrachteten Modell werden Events mit atomaren Event Tokens behandelt: Event NameEvent Token für Methode m Methodenaufruf senden!m^ Methodenaufruf empfangen?m^ Antwort senden!m$ Antwort empfangen?m$

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf16 Behaviour l Eine Abfolge von Events, dargestellt durch Event Tokens, nennt man Trace uBsp.: · Ruft Methode m auf, wartet auf Return, ruft Methode n auf und wartet auf Return l Die Menge aller möglichen Traces einer SOFA Einheit nennt man Behaviour uBsp. für das Interface i1 : · Das Interface i1 erwartet entweder den Aufruf von Methode m oder Methode n und antwortet {, }

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf17 Behaviour Protocols I l Da Konstrukte wie nicht gut lesbar sind, gibt es Behaviour Protocols uBehaviour Protocol des obigen Ausdrucks: · ?m steht abkürzend für (?m^; !m$) · + bezeichnet Alternative l Behaviour Protocols werden direkt in CDL Code integriert {, } Prot-F = ?i1.m + ?i1.n

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf18 Behaviour Protocols II l Drei Arten von Behaviour Protocols: uFrame Protocols uInterface Protocols uArchitecture Protocols · Architecture Protocols werden automatisch vom CDL Compiler aus den Frame Protocols der Subkomponenten erzeugt l Der CDL Compiler überprüft alle Protokolle auf semantische Konsistenz: uPasst das Frame Protocol zu den Interface Protocols? uPasst das Architecture Protocol zu seinem Frame Protocol?

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf19 l Primitive & Composed Components l Frame (Black-Box) & Architecture (Grey-Box) l Component Definition Language (CDL) l Type Information Repository (TIR) l Connectors l Events & Behaviour Protocols Zusammenfassung

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf20 l Ein SOFAnode ist eine Umgebung zur uEntwicklung uVerteilung uAusführung von SOFA Applikationen l Mehrere SOFAnodes können zu einem SOFAnet verbunden werden SOFAnodes I

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf21 SOFAnodes II l Ein SOFAnode besteht aus max. fünf logischen Teilen: uTemplate Repository (TR) · Enthält Implementation und CDL-Code aller Komponenten uMADE part · Umgebung zur Erstellung neuer Komponenten (CDL Compiler, TIR, Code Generator) uIN und OUT part · Zur automatischen Verteilung von Komponenten zwischen SOFAnodes uRUN part · Laufzeitumgebung TR IN MADERUN OUT Schematische Darstellung eines SOFAnodes

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf22 SOFAnet TR 0 MADERUN OUT TR 0 MADERUN OUT TR IN MADERUN 0 TR IN MADERUN 0 Schematische Darstellung eines SOFAnets

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf23 Dynamic Component Update (DCUP) I l DCUP ist eine Erweiterung von SOFA-Komponenten und ermöglicht sicheres Updaten zur Laufzeit l Eine DCUP-Komponente besteht aus zwei Teilen: uPermanent Part · Kein Update möglich · Bei allen Versionen einer Komponente identisch uReplaceable Part · Austauschbar · Verschiedene Versionen einer Komponente unterscheiden sich hier

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf24 Dynamic Component Update (DCUP) II l DCUP-Komponenten enthalten zwei Kontrollobjekte: uComponent Manager (CM) · Kontrolliert den Lebenszyklus der Komponente zur Laufzeit · Gehört zum Permanent Part der Komponente · Der CM ist für jede Version einer Komponente gleich uComponent Builder (CB) · Zuständig für die Inneren Abläufe der Komponente: –Bei Primitive Components: Implementation –Bei Composed Components: Subkomponenten · Gehört zum Replaceable Part der Komponente · Kann für jede Version einer Komponente unterschiedlich sein

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf25 Dynamic Component Update (DCUP) III CM A CB A CM B CM C A B C Replaceable Part Permanent Part Component Border CM Component Manager CB Component Builder Schematische Darstellung einer DCUP-Komponente Control Part Functional Part

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf26 Prototyp in Java 2 l Eine SOFA-Komponente wird in Java durch folgende Objekte dargestellt: uComponent Manager · Wird als erstes initialisiert · Registriert und verwaltet die Komponente · Verantwortlich für das dynamische Update/DCUP uComponent Builder · Erstellt Subkomponenten und Verbindungen bei Composed Components · Erstellt die Objekte zur Implementierung bei Primitive Components uWeitere Objekte zur Implementierung der Funktionalität · Nur bei Primitive Components

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf27 Deployment Descriptor l Component Deployment Descriptor (CDD) uBeschreibt eine einzelne Komponente uGrundgerüst wird automatisch erstellt aus CDL-Definitionen uDer Entwickler ergänzt: · Die Versionsnummer der Komponente (Primitive) · Die Versionsnummern der Subkomponenten (Composed) l Application Deployment Descriptor (ADD) uBeschreibt die gesamte Baum-Hierarchie der Applikation uRekursiv erstellt aus dem CDD und den CDDs der Subkomponenten

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf28 Quiescent State l Die Thread Registry im CM registriert alle threads l Quiescent State einer Komponente bedeutet uKein thread wird in der Komponente ausgeführt uDie Komponente wartet nicht auf einen Aufruf durch eine andere Komponente l Updates sind ausschließlich bei Quiescent State erlaubt

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf29 Ablauf eines dynamischen Updates l Update-Flag wird gesetzt uAlle eingehenden Methoden-Aufrufe werden geblockt l CM wartet bis Quiescent State erreicht ist l CM ersetzt CB, Subkomponenten usw. l Update-Flag wird zurückgesetzt uNeue Version der Komponente steht bereit uAlle geblockten Aufrufe werden abgearbeitet

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf30 Warum Prototyp? l In dem Java-Prototyp fehlen immer noch einige Features l Im SOFAnode fehlt z.B.: uAutomatische Verteilung zwischen SOFAnodes uTR fehlt. Stattdessen: · Ein http-Server stellt die Komponenten-Klassen zur Verfügung · TIR stellt die Komponenten-Spezifikationen zur Verfügung uSpeichern und Wiederherstellen des Komponenten-Status während des dynamischen Updates und des Terminierens fehlt

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf31 Fragen zu SOFA?

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf32 Normale Folie l Stichwort uErläuterung uUnter-Stichwort · Unter-unter-stichwort oder Erläuterung... l Stichwort uErläuterung uUnter-Stichwort · unter-unter-stichwort oder Erläuterung... l Stichwort uErläuterung uUnter-Stichwort · unter-unter-stichwort oder Erläuterung...

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf33 Zweispaltiges Layout l selten sinnvoll uhäufig umgebrochener Text wirkt unruhig und ist schwer zu lesen uim allgemeinen lieber volle Breite nutzen! l usw. u... l nur sinnvoll bei uGegenüberstellungen uLinks Text, rechts Graphik · siehe nächste Seite

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf34 Man kann in PPT mitten in ein Graphik- Objekt hineinschreiben, ohne extra ein Textobjekt erzeugen zu müssen Courier eignet sich gut für Code- Beispiele. Man muss diese Schrift aber immer fett setzen, da ihr Schnitt so dünn ist, daß man sie sonst auf Folien kaum lesen kann. Und hier etwas allgemeines bla, das zuerst den gesamtkontext des Beispiels hilfreich darstellt und danach von dem pop-up abgedeckt werden kann. Zweispaltiges Layout mit Graphik l oft hilfreich, aber uhäufig umgebrochener Text wirkt unruhig und ist schwer zu lesen uim allgemeinen lieber volle Breite nutzen u... bzw. Text kurz halten! l usw. u... Dieser Kasten ist so animiert, daß er wie ein pop-up aus dem darunterliegenden auftaucht. Manchmal gut geeignet um in ein Beispiel herein zu Zoomen. Meist kommt man aber ohne sowas aus (vor allem wenn man mit Folien statt Projektor arbeiten muss ;-) ). Dieser Kasten ist so animiert, daß er wie ein pop-up aus dem darunterliegenden auftaucht. Manchmal gut geeignet um in ein Beispiel herein zu Zoomen. Meist kommt man aber ohne sowas aus (vor allem wenn man mit Folien statt Projektor arbeiten muss ;-) ).

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf35 Was man tun und lassen sollte (1) l Schriftgröße unicht ändern! u... und wenn überhaupt dann nicht manuell auf der Folie... u... sondern einheitlich für alle Seiten in der Folienvorlage!!! l Folienvorlage unichts ändern, außer · Namel · Schriftgröße (aber nur im Ausnahmefall, s.o.!) l Ausformulierter Vortragstext ugehört auf die Notiz-Ansicht! ·Folien enthalten nur die Essenz des Vortrags ·Sie sollen helfen dem Vortrag zu folgen, nicht alle Details aufführen

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf36 Was man tun und lassen sollte (2) l Graphiken ureichlich benutzen unur in PowerPoint selbst erstellen · geht leichter · ist plattformunabhängig! (OLE-eingebettete Objekte könnte man nicht woanders weiterverarbeiten) · kann bei Bedarf animiert werden · was PPT nicht kann ist garantiert überflüssiger Schnick-Schnack · Ausnahme: Scanns, Screenshots uTip: vorher die PPT-Symbolleisten anpassen · Zeichen-, Gruppierungs- und Ausrichtungswerkzeuge aktivieren / einbauen · spart beim Arbeiten viel Zeit!

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Tobias Rudorf37 Was man tun und lassen sollte (3) l Farben ueinfach so sein lassen! · helfen bei der Erstellung Strukturen besser zu erkennen · helfen bei der Projektor-Vortrag den Zuhörern Strukturen besser zu erkennen · im Folien-Druck mit Graustufen auf jedem Laser-Drucker (an der Uni) ist der Kontrast groß genug um Unterschiede gut erkennen zu lassen –provare per credere: ruhig mal ausprobieren...