Gliederung teil 3 anpassungen
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

Gliederung: Teil 3 - Anpassungen PowerPoint PPT Presentation


  • 45 Views
  • Uploaded on
  • Presentation posted in: General

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 Java Beans 3. (D)COM 3. Anpassungen Daten und Funktion Interaktion

Download Presentation

Gliederung: Teil 3 - Anpassungen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Gliederung teil 3 anpassungen

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


Problem

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


Beispiele

Beispiele

  • Komponente „Datei“:open (read | write )* close

  • Komponente „Keller“:

    (pushn popn)*

  • Thermostat:(zu kalt | zu heiss)*

  • Telefonleitung:

    Abheben (

    Ziffer* (

    Aufgelegt |

    Timeout |

    NummerKorrekt (

    besetzt | klingelt (

    Aufgelegt |

    Angenommen Sprachdaten*(Aufgelegt|RemoteAufgelegt)

    ))))*


Definitionen

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


Korrekte verwendung

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)


Anpassung

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?


Problem1

...

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

Problem


Problem2

...

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

Problem


Aliasproblem

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


Points to analyse

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


Points to may

Points-To (May)

...

File f=new File();

File g=new File();

if someFunc() f=g;

f.open(...);

g.open(...);

f.write(...);

g.write(...);

...

new

f=#1

g=?

new

f=#1

g=#2

if

f=#2

=

g=#2

f={#1,#2}

g=#2

f={#1,#2}

g=#2

f={#1,#2}

g=#2

f={#1,#2}

g=#2


Points to must

Points-To (Must)

...

File f=new File();

File g=new File();

if someFunc() f=g;

f.open(...);

g.open(...);

f.write(...);

g.write(...);

...

new

f= #1

g=?

new

f= #1

g=#2

if

f= #2

=

g=#2

f= 

g=#2

f= 

g=#2

f= 

g=#2

f= 

g=#2


Typsplitting

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


Beispiel typsplitting

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(...);

}


Problem3

...

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

Problem


Problem4

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

Problem


Namensschemaproblem

Namensschemaproblem

  • Potentiell beliebige Anzahl von von dynamisch erzeugten Komponenteninstanzen

  • Muss für statische Analyse zu endlicher Anzahl abstrahiert werden

  • Analyse muss fehlerhaft sein


M gliche namensschemata

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


Problem5

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


Problem nebenl ufigkeit

Problem Nebenläufigkeit

  • Sei A1 das Aufrufprotokoll von Klient 1 und A2 das Aufrufprotokoll von Klient 2

  • Sei f1: m1,m2, ... , mnA1 die Aufruffolge von Klient 1 undf2:m‘1,m‘2, ... , m‘kA2 die Aufruffolge von Klient 2

  • An der Komponente kann jede Folge der Bauart:m‘‘1, m‘‘2, ... , m‘‘n+k ankommen mit m‘‘i  f1  m‘‘i  f2 und Folgen f1 undf2 sind Teilfolgen

  • Aufrufprotokoll ist Produkt der Sprachen A1A2

  • Verallgemeinerung auf k Klienten A1A2 ... Ak

  • Exponentielles Wachstum:

    • Der Sprache (nicht so schlimm)

    • Der Sprachdefinition


Beispiel keller

SSS

| push S pop

|

SSS

| push S pop

|

S‘(S|S) (S|S)

S  push pushS‘pop pop

| 

Spush push S‘pop pop

| 

Spush S‘ pop

|

Spush S‘ pop

|

Beispiel Keller


Beispiel 2 klienten f r eine datei

Beispiel: 2 Klienten für eine Datei

read/

write

open

close

read/

write

open

close


Nebenl ufige klienten der datei

Nebenläufige Klienten der Datei

read/

write

open

close

read/

write

open

open

open

read/

write

read/

write

read/

write

close

close

close

open

close

read/

write


Legale aufrufe an eine datei

Legale Aufrufe an eine Datei

read/

write

open

close

open

open

read/

write

read/

write

close

close

open

close

read/

write


Problem6

Problem

  • Ein Klient und eine Komponente im System

  • Komponente ist web-Dienst

  • Aufrufprotokoll A: z.B. sei f: m1,m2, ... , mnA

  • Komponentenprotokoll K: z.B. sei g: m1,m2, ... , mnK

  • Web-Kommunikation ist nicht reihenfolgeerhaltend

  • An der Komponente kommen die Aufrufe in vertauschter Reihenfolge an, z.B. f‘: m2,m1, ... , mn mit f‘ K

  • Immer Anpassungen zur Laufzeit notwendig


Statische analyse

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


Program slicing

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


Berechnung der aufrufprotokolls

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


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

Beispiel


Ergebnis

Ergebnis

  • Kontextfreie Grammatik

  • Definiert Obermenge A‘ des Aufrufprotokolls A

    AA‘

    A‘ K AK

  • Wie ist K definiert?


Endlicher automat

Endlicher Automat

  • K ist durch endlichen Automaten gegeben

  • Alternativ regulärer Ausdruck oder Grammatik

  • A‘ Kist 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?


Regul re obermenge kontextfreier sprachen

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: SN (vor Akzeption), S‘N (nach Akzeption)

    • N  tSN t  S‘NS‘N  SF

    • N t N‘SN t  SN‘ S‘N‘   S‘N

    • N N‘N‘‘SN SN‘ S‘N‘   SN‘‘ S‘N‘‘   S‘N


Eigenschaften

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


Zustandsexplosion bei nebenl ufigkeit

Zustandsexplosion bei Nebenläufigkeit

read/

write

open

close

read/

write

open

open

open

read/

write

read/

write

read/

write

close

close

close

open

close

read/

write


Modellpr fung

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


Erreichbarkeitsanalyse

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 !


Grenzen der expliziten darstellung

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)


Klammersprachen

Klammersprachen

  • Dycksprachen

  • Wohlgeformte Klammerausdrücke über einem Alphabet von Klammern

  • Beispiel Warenkorb

    • Paar: Auswahl (X) – Zurücklegen (X)

    • Ware X beliebig

  • Inklusionsproblem entscheidbar


Kontextfreie sprachen

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


Pr dikatenlogik

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


Beispiel1

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;

}


Pr dikatenlogik1

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


Guarded methods

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


Kriterien

Kriterien

  • Vollständige Spezifikation des Komponentenverhaltens?

  • Automatische Tests auf Konsistenz?

  • Verständlichkeit / Effizienz der Spezifikation?

  • Effizienz der Ausführung?


Spezifikationstechniken im vergleich

Spezifikationstechniken im Vergleich


Zusammenfassung

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)


Warum geht alles gut

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


Best practice

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


  • Login