Dr. Welf Löwe und Markus Noga1 Gliederung: Teil 3 - Anpassungen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,

Präsentation zum Thema: "Dr. Welf Löwe und Markus Noga1 Gliederung: Teil 3 - Anpassungen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,"—  Präsentation transkript:

1 Dr. Welf Löwe und Markus Noga1 Gliederung: Teil 3 - Anpassungen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle, akademische) 2. Industrielle Komponentensysteme der 1. Generation 1. CORBA 2. Enterprise JavaBeans 3. (D)COM 3. Anpassungen –Daten und Funktion –Interaktion Kommunikation Synchronisation Protokolle –Lebendigkeit

2 Dr. Welf Löwe und Markus Noga2 Problem Komponenten mit Zustand Aufruf der Methoden (Dienste) bewirkt Zustandstransformationen Nicht jeder Dienst kann in jedem Zustand erbracht werden Protokoll beschreibt Folgen möglicher „Dienstleistungen“ einer Komponente

3 Beispiele Komponente „Datei“: open (read | write )* close Komponente „Keller“: (push n pop n )* Thermostat: (zu kalt | zu heiss)* Telefonleitung: Abheben ( Ziffer* ( Aufgelegt | Timeout | NummerKorrekt ( besetzt | klingelt ( Aufgelegt | Angenommen Sprachdaten*(Aufgelegt|RemoteAufgelegt) ))))*

4 Dr. Welf Löwe und Markus Noga4 Definitionen Protokoll: –Menge von Folgen von Methodenaufrufen –Formale Sprache mit Methoden als Alphabet Komponentenprotokoll K –Protokoll (Sprache), das legale Aufruffolgen von Methoden einer Komponente definiert Aufrufprotokoll A –Protokoll, das die tatsächliche Verwendung einer Komponente definiert

5 Dr. Welf Löwe und Markus Noga5 Korrekte Verwendung Sei prefix(K) die Menge aller Methodenfolgen, die Anfang eines Satzes aus K sind. Komponente wird korrekt verwendet, wenn A  prefix(K) oder A  K Frage, ob Endzustand erreicht werden muss Was gelten muss, hängt von der Komponente ab (Datei vs. Keller)

6 Dr. Welf Löwe und Markus Noga6 Anpassung Wrapper um die Komponente –Generiert notwendige Methoden –Konsumiert überflüssige Methoden –Blockt Methoden, die ungelegen kommen, dadurch Umsortieren von Methodenaufrufen zur Laufzeit Insgesamt teuere Operationen Was kann bereits statisch erkannt werden?

7 Dr. Welf Löwe und Markus Noga7 Problem... File f=new File(); File g=new File(); f=g; f.open(...); g.open(...); f.write(...); g.write(...);... File g ist „Alias“ für File f Um festzustellen, ob Komponenten richtig verwendet werden, müssen „Aliases“ gefunden werden

8 Dr. Welf Löwe und Markus Noga8 Problem... File f=new File(); File g=new File(); if someFunc() f=g; f.open(...); g.open(...); f.write(...); g.write(...);... File g ist vielleicht „Alias“ für File f Finden von „Aliases“ ist unentscheidbar Ergebnis von someFunc() müsste statisch geraten werden können

9 Dr. Welf Löwe und Markus Noga9 Aliasproblem Komponente kann durch mehrere Ausdrücken (Zugriffspfaden) referenziert werden (alias) Komponentenprotokoll kann durch alle Aliases fortgeschaltet werden Finden von Aliases ist unentscheidbar Lösung –Points-To Analyse –Typsplitting

10 Dr. Welf Löwe und Markus Noga10 Points-To Analyse Datenflussanalyse Datenstruktur ist –Steuerflussgraph –SSA Graph des Programms Jedem Ausdruck im Programm wird Menge von Definitionen zugeordnet Aktualisierung bei Zuweisung, Prozeduraufruf May und Must Problem unterschieden –Unterschiedliche Behandlung bei Zusammenflüssen im Steuerflussgraph

11 Dr. Welf Löwe und Markus Noga11 Points-To (May)... File f=new File(); File g=new File(); if someFunc() f=g; f.open(...); g.open(...); f.write(...); g.write(...);... new if = f=#1g=? f=#2 f={#1,#2} f=#1 g=#2 

12 Dr. Welf Löwe und Markus Noga12 Points-To (Must)... File f=new File(); File g=new File(); if someFunc() f=g; f.open(...); g.open(...); f.write(...); g.write(...);... new if = f= #1g=? f= #2 f=  f= #1g=#2 

13 Dr. Welf Löwe und Markus Noga13 Typsplitting Jedes Objekt hat Protokoll als Typ Beim Erzeugen von Aliases wird das Protokoll zwischen beiden Aliasausdrücken aufgeteilt Es entstehen zwei Sichten auf die Komponente, die zusammen das gesamte Protokoll bilden Schwierigkeiten –mit may-alias –Zusammenflüssen im Steuerfluss

14 Dr. Welf Löwe und Markus Noga14 Beispiel Typsplitting... File (open, write*, close) f=new File(); init(f); f.write(...); //f ist vom Typ: File (write*, close)... f.close(...);... void init (File (open write) g){ g.open(...); g.write(...); }

15 Dr. Welf Löwe und Markus Noga15 Problem... loop{ x=new K(); x.init(); x.doSome(); x.close(); }... new K() steht für eine Menge von Komponenteninstanzen zur Laufzeit Abstrakte Namen zur Bezeichnung in der statischen Analyse

16 Problem Fabrik(){ K[] container; init(){ loop{ container.add(new K()); } get(){ return(container.get()); } x=get(); y=get(); x.init(); y.init();... Abstrakte Namen können konkrete Komponenten nicht immer unterscheiden Problem unentscheidbar

17 Dr. Welf Löwe und Markus Noga17 Namensschemaproblem Potentiell beliebige Anzahl von von dynamisch erzeugten Komponenteninstanzen Muss für statische Analyse zu endlicher Anzahl abstrahiert werden Analyse muss fehlerhaft sein

18 Dr. Welf Löwe und Markus Noga18 Mögliche Namensschemata Alle (dynamischen) Objekte sind eins Alle (dynamischen) Objekte gleichen Typs (der gleichen Komponente) zu einem abstrakten zusammenfassen Alle Objekte, die an der gleichen Stelle erzeugt wurden, zusammenfassen Alle Objekte, die an der gleichen Stelle erzeugt wurden, wobei diese Erzeugung von der gleichen Prozedur aufgerufen wurde Letzteres verallgemeinerbar auf Aufrufpfade der Länge k

19 Dr. Welf Löwe und Markus Noga19 Problem Mehrere Klienten greifen auf identische Komponente zu Klienten laufen parallel aber nicht synchron Beobachtbares Verhalten der Umgebung ist nicht deterministisch –Reihenfolge der Methodenaufrufe, wie sie an der Komponente ankommen, ist Verzahnung („Interleaving“) der Aufrufe der beteiligten Klienten –Eingeschränkt durch Abhängigkeiten der Klienten untereinander

20 Dr. Welf Löwe und Markus Noga20 Problem Nebenläufigkeit Sei A 1 das Aufrufprotokoll von Klient 1 und A 2 das Aufrufprotokoll von Klient 2 Sei f 1 : m 1,m 2,..., m n  A 1 die Aufruffolge von Klient 1 und f 2 : m‘ 1,m‘ 2,..., m‘ k  A 2 die Aufruffolge von Klient 2 An der Komponente kann jede Folge der Bauart: m‘‘ 1, m‘‘ 2,..., m‘‘ n+k ankommen mit m‘‘ i  f 1  m‘‘ i  f 2 und Folgen f 1 und f 2 sind Teilfolgen Aufrufprotokoll ist Produkt der Sprachen A 1  A 2 Verallgemeinerung auf k Klienten A 1  A 2 ...  A k Exponentielles Wachstum: –Der Sprache (nicht so schlimm) –Der Sprachdefinition

21 Dr. Welf Löwe und Markus Noga21 Beispiel Keller S  SS | push S pop |  S  SS | push S pop |  S‘  (S|S) (S|S) S  push push S‘pop pop |  S  push push S‘pop pop |  S  push S‘ pop |  S  push S‘ pop | 

22 Dr. Welf Löwe und Markus Noga22 Beispiel: 2 Klienten für eine Datei open read/ write close open read/ write close

23 Nebenläufige Klienten der Datei open read/ write close open read/ write close open read/ write close open read/ write close read/ write read/ write open close

24 Legale Aufrufe an eine Datei openclose open read/ write close open read/ write close read/ write read/ write open close

25 Dr. Welf Löwe und Markus Noga25 Problem Ein Klient und eine Komponente im System Komponente ist web-Dienst Aufrufprotokoll A : z.B. sei f: m 1,m 2,..., m n  A Komponentenprotokoll K : z.B. sei g: m 1,m 2,..., m n  K Web-Kommunikation ist nicht reihenfolgeerhaltend An der Komponente kommen die Aufrufe in vertauschter Reihenfolge an, z.B. f‘: m 2,m 1,..., m n mit f‘  K Immer Anpassungen zur Laufzeit notwendig

26 Dr. Welf Löwe und Markus Noga26 Statische Analyse Simulieren der Methodenaufrufe zur Übersetzungszeit expr.m() erzeugt sog. „Update“ der Menge von Objekten, die expr bezeichnet –Mögliche Aliases – „weak update“ – alter Zustand wird als möglicher aktueller gemerkt –Garantierte Aliases – „strong update“ – alter Zustand wird fortgeschaltet Aussagen –Garantiert korrekt –Fehler können nicht ausgeschlossen werden –Fehler garantiert

27 Dr. Welf Löwe und Markus Noga27 Program Slicing Aufgabe: lösche Programmstellen, die zu Aufrufen an die Komponente keinen Beitrag leisten Ziel: konservative Abschätzung Datenstruktur ist Aufrufgraph oder Steuerflussgraph Anfang: potentielle Erzeugungen und Aufrufe Lösche alle Knoten, die nicht auf einem Pfad vom Programmanfang main zur Erzeugung einer Instanz oder zum Aufruf an eine Instanz führen Ungenau, da in gelöschten Prozeduren berechnete Werte den Steuerfluss zum Aufruf beeinflussen können

28 Dr. Welf Löwe und Markus Noga28 Berechnung der Aufrufprotokolls Definition einer Grammatik Jeder Methode der Komponente entspricht Terminalsymbol Jeder anderen Methode entspricht Nichtterminal main – Satzsymbol Methodenrümpfe entsprechen rechten Seiten von Produktionen –Schleife: * –Bedingung: | –Methodenaufruf: Terminal oder Nichtterminal

29 Dr. Welf Löwe und Markus Noga29 Beispiel main{ File f=new File(); start(f); } start(File f){ f.open(...); doSome(f); f.close(); } doSome(File f){ loop char c=f.read(); f.write(„bla“); } Main  Start Start  open DoSome close DoSome  read* write

30 Dr. Welf Löwe und Markus Noga30 Ergebnis Kontextfreie Grammatik Definiert Obermenge A ‘ des Aufrufprotokolls A A  A ‘ A ‘  K  A  K Wie ist K definiert?

31 Dr. Welf Löwe und Markus Noga31 Endlicher Automat K ist durch endlichen Automaten gegeben Alternativ regulärer Ausdruck oder Grammatik A ‘  K ist unentscheidbar, da A ‘ kontextfrei Lösung: finde reguläre Obermenge A ‘‘ von A ‘ A  A‘  A ‘‘ A ‘‘  K  A  K Finden einer möglichst genauen regulären Obermenge einer kontextfreien Sprache?

32 Dr. Welf Löwe und Markus Noga32 Reguläre Obermenge kontextfreier Sprachen Grammatik in Greibach Normalform: –N  t –N  t N‘ –N  N‘N‘‘ Immer möglich für jede KfG Konstruiere Endlichen Automaten Jedem Nichtterminal N werden 2 Zustände zugeordnet: S N (vor Akzeption), S‘ N (nach Akzeption) –N  tS N t  S‘ N S‘ N   S F –N  t N‘S N t  S N‘ S‘ N‘   S‘ N –N  N‘N‘‘S N   S N‘ S‘ N‘   S N‘‘ S‘ N‘‘   S‘ N

33 Dr. Welf Löwe und Markus Noga33 Eigenschaften Ist regulär (per Konstruktion) Akzeptiert Obermenge der Sprache Ist nicht unnötig groß, d.h., wenn die Sprache regulär ist (nur unglücklicher Weise kontextfrei definiert), so wird der Automat konstruiert, der die Sprache exakt akzeptiert

34 Zustandsexplosion bei Nebenläufigkeit open read/ write close open read/ write close open read/ write close open read/ write close read/ write read/ write open close

35 Dr. Welf Löwe und Markus Noga35 Modellprüfung Ursprung: Formale Logik –Gegeben eine Formel  und –ein mathematisches Modell M der Formel –Wird  von M erfüllt? Anwendung auf Software –Formel  ist Spezifikation, –Modell M ist Umsetzung: –Erfüllt M seine Spezifikation  ? Ablaufaussagen erfordern Zeitbegriff –Temporales Zeitmodell:( ,  ) –Quantitatives Zeitmodell:( , , |·|) für Echtzeitprobleme, reduzierbar auf temporales Zeitmodell

36 Dr. Welf Löwe und Markus Noga36 Erreichbarkeitsanalyse Aufgabe –Gegeben ein Zustand –Welche Zustände sind erreichbar? Algorithmus –Beginne mit Z={Start} –Solange  z  Z, z nicht bearbeitet Z := Z  {y | y ist von z direkt erreichbar} –Terminiert, da Zustandsmenge endlich Anwendung auf Modellprüfung –Gegeben eine Formel  und einen Startzustand –Gilt  auf allen Ausführungspfaden, auf einem Ausführungspfad... –Berechne erreichbare Zustände und prüfe  !

37 Dr. Welf Löwe und Markus Noga37 Grenzen der expliziten Darstellung Berechnung der Erreichbarkeit ist linear in Größe –des Zustandsraums –der Übergangsrelation –der zu beweisenden Formel In der Praxis –Systeme sind Komposition paralleler Komponenten –Zustandsraum wächst exponentiell (Zustandsexplosion) –In expliziter Darstellung nicht beherrschbar Ausweg –Implizite Darstellung mit booleschen Formeln (symbolisch) –Zustandsraum ist n-dimensionaler boolescher Raum –Kodierung als geordnete binäre Entscheidungsdiagramme (OBDD)

38 Dr. Welf Löwe und Markus Noga38 Klammersprachen Dycksprachen Wohlgeformte Klammerausdrücke über einem Alphabet von Klammern Beispiel Warenkorb –Paar: Auswahl (X) – Zurücklegen (X) –Ware X beliebig Inklusionsproblem entscheidbar

39 Dr. Welf Löwe und Markus Noga39 Kontextfreie Sprachen Inklusionsproblem unentscheidbar im allgemeinen Ansatz: transformiere beide Grammatiken –Konstruiere Greibach Normalform –Eliminiere Kettenproduktionen –Eliminiere nicht erreichbare Produktionen –Eliminiere nicht terminierende produktionen Vergleiche auf strukturelle Inklusion Semientscheidbar

40 Dr. Welf Löwe und Markus Noga40 Prädikatenlogik Natürliche Form der Komponentenprotokollspezifikation Jeder Dienst hat Vorbedingung (pre-condition) –Prädikatenlogische Formel über dem Zustand der Komponenteninstanz und den Parametern Jeder Dienst garantiert Nachbedingung (post-condition) –Prädikatenlogische Formel über dem Zustand der Komponenteninstanz und den Parametern vor Dienstausführung und über dem Zustand der Komponenteninstanz und dem Resultat nach Dienstausführung –Eigentlich Temporallogik Nachbedingung impliziert die Gültigkeit von anderen Vorbedingungen

41 Dr. Welf Löwe und Markus Noga41 Beispiel class Stack(T) { pre: true; push(T t); post: Stack.count == Stack.count‘ +1 pre: Stack.count != 0; pop(T t); post: Stack.count == Stack.count‘ -1; }

42 Dr. Welf Löwe und Markus Noga42 Prädikatenlogik Statisch unentscheidbar Beobachtung in der Praxis: –Teil des Zustandes, der relevant ist für korrekte Verwendung ist als Dienst an der Schnittstelle verfügbar –Bsp.: Funktion isEmpty() beim Stack Lösung zur Laufzeit immer möglich

43 Dr. Welf Löwe und Markus Noga43 Guarded Methods Dienste sind durch Wächter (guards) geschützt Garantieren, dass kein Dienst aufgerufen wird, wenn die Komponente im falschen Zustand ist Korrektheit dynamisch gesichert durch Umordnen von Methodenaufrufen Laufzeitprobleme –Teuer Operationen (Kerneintritt notwendig) –Verwaltung von Methodenwarteschlangen Lebendigkeit (Verklemmungsfreiheit) offenes Problem

44 Dr. Welf Löwe und Markus Noga44 Kriterien Vollständige Spezifikation des Komponentenverhaltens? Automatische Tests auf Konsistenz? Verständlichkeit / Effizienz der Spezifikation? Effizienz der Ausführung?

45 Dr. Welf Löwe und Markus Noga45 Spezifikationstechniken im Vergleich VollständigTestSpecCode Sequence Diagrams-- +++ Endliche Automaten-+++ Modellprüfung-/++++ Prädikatenlogische Formeln +-++ Guards++ ---

46 Dr. Welf Löwe und Markus Noga46 Zusammenfassung Alias-Problem (unentscheidbar) Abstrakte Namen finden (exakt sein unmöglich, exponentielles Wachstum der Datenstruktur mit der Genauigkeit) Aufrufprotokoll Finden (unentscheidbar auch ohne Alias- und Namensproblem) Nebenläufige Aufrufer (exponentieles Wachstum möglicher Sequenzen) Kanäle, die die Ordnung nicht erhalten (exponentieles Wachstum möglicher Sequenzen) Sprachinklusion (unentscheidbar oberhalb von regulären Sprachen)

47 Dr. Welf Löwe und Markus Noga47 Warum geht alles gut Komponenten in der Praxis haben einfache Schnittstellen (sonst können die Dienste nicht verwendet werden) –Einfache Protokolle Komponenten in der Praxis grobgranular (sonst macht Wiederverwendung keinen Sinn) –Wenige Instanzen Hierarchischer Aufbau von Systemen –Aufrufer in lokalen Subsystemen zu finden Gegenstand aktueller Forschung – richtige Mischung von statischen und dynamischen Techniken wird gesucht

48 Dr. Welf Löwe und Markus Noga48 Best practice Garantiere Korrektheit durch guards Analysiere (statisch), welche guards wegfallen dürfen Analysiere (statisch oder dynamisch), ob System lebendig –Verklemmungsvermeidung (statisch) –Verklemmungsentdeckung (dynamisch) Verweben von guards und Komponenten