Modellbildung in der Entwicklung mit Schwerpunkt Architekturen Integration von Modellsichten am Beispiel von AutoFocus

Volltext

(1)Modellbildung in der Entwicklung mit Schwerpunkt Architekturen Integration von Modellsichten am Beispiel von AutoFocus Prof. Dr. Dr. h.c. Manfred Broy Gemeinsam mit Dr. Bernhard Schätz Fakultät für Informatik, TU München SS 2007. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(2) Modellintegration Modellintegration: Von Teilsichten zur Gesamtsicht • Ein Modell ist eine Abstraktion: Definiert eine Sicht auf ein System • Typische Sichten – Datensicht: Datenmodell – Schnittstellensicht: Black Box Modell – Zustandssicht: Zustandsmaschinen – Prozesssicht: Ablaufmodell – Architektursicht: Architekturmodell. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(3) Aufgaben der Modellintegration • Zusammenspiel unabhängiger Modellsichten – Konsistenz – Vollständigkeit. • Zusammenspiel redundanter Modellsichten – Konsistenz. • Zusammenspiel der Modellierungstechniken einer Modellierungssprache. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(4) Beispiel Konsistenz Daten-/Zustandsmodell • Eine Zustandsmaschine mit Ein/Ausgabe arbeitet mit Daten – Zustandsattribute – Nachrichten für Ein/Ausgabe. • Ein Datenmodell definiert eine – Menge von Sorten/Datentypen – Menge von Operationen darauf. • Konsistenz: Die Typen/Sorten werden wie durch ihre Operationen festgelegt verwendet • Vollständigkeit: Alle verwendeten Typen/Sorten und Operationen sind definiert Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(5) Das Beispiel: AutoFocus Wir demonstrieren die Problematik am Beispiel • AutoFocus: Ein Werkzeug für modellbasierte Entwicklung von Software für eingebettete Systeme. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(6) Konzept: Offenes System/Komponente. Offenes System/Komponente: Gekapselter Teil des Gesamtsystems •. Kopplung mit Umgebung über Schnittstelle. •. Umgebungsunabhängig beschreibbares Verhalten Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(7) Konzept: Schnittstelle. Syntaktische Schnittstelle: Interaktionspunkte Komponente/Umgebung •. Richtung der Interaktion (Ein-/Ausgabe). •. Art der Interaktion (Nachrichtentyp) Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(8) Kompatibilität zum Datenmodell • Die auftretenden Nachrichten sind im Datenmodell deklariert. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(9) Kompatibilität bei Verhaltensmodellierung • Soweit ist nur ein „syntaktische Schnittstelle“ des Systems/der Komponente beschrieben • Das „Innere“ (das Verhalten) des Systems/der Komponente wird beschrieben durch – Architektur – Zustandsmaschine – Interaktionsdiagramme – Black Box Spezifikation (in AutoFocus nicht implementiert). • Kompatibilität: Das „Innere“ passt zur Syntaktischen Schnittstelle. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(10) Konzept: Architektur und Hierarchie. BA:Signal. A. A. Merge. PL:PedColor. R eq:Signal. BB:Signal. TL:TrafColor. Controller. IndA:IndSig IndB:IndSig. Hierarchie: Strukturelle Komponentenarchitektur •. Interne Komponentenstruktur („glass box“). •. Unterkomponenten und interne Kanäle. •. Interne und externe Schnittstelle Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(11) Integration: Kopplung Externe/interne Sicht. BA:Signal. A. A. Merge. PL:PedColor. R eq:Signal Controller. BB:Signal. TL:TrafColor. IndA:IndSig IndB:IndSig. Integration: Schnittstellensicht •. Interne Eingabe = externe Ausgabe. •. Interne Ausgabe = externe Eingabe Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(12) Konzept: Signal. t. t+1. t+2. t+3 T. ButtonB Pr. -. Pr. Signal: Kanalhistorie •. Gezeitete Beobachtung des Kanals mit globalem Zeittakt. •. Definition der beobachteten Nachrichten pro Zeittakt Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(13) Modell: Strom (wie gehabt) Strom: (Potentielle unendliche) Nachrichtensequenz • Daten: Trägermenge M = {m1, m2, m3,...} • Nachrichten: Datum oder Absenz M⊥ = M ∪ { ⊥ } • Ströme: Sequenzen über M⊥ – Endliche Ströme: M⊥* – Unendliche Ströme: M⊥∞ – Potentiell unendliche Ströme: M⊥ω = M⊥* ∪ M⊥∞ – Funktional: M⊥ω = N → M⊥. • Varianten: Mω (ungezeitet), (M*)ω (schwach kausal) • Spezialfall Autofocus: Genau eine Nachricht pro Zeitintervall Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(14) Konzept: Ablauf ButtonB ButtonA TrafLightsPedLights IndicatA IndicatB. Pr. t+2. t+2 Pr t+3. -. t+3. •. Alle Schnittstellenelemente. •. Alle Zeitschritte. t+2. t+3. Green t+3. Stop t+3. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. t+1 -. t+2. Ablauf: Signalhistorie Komponente. -. t+1. t+2 -. t -. t+1. t+1. -. t. -. -. t+1. t+1. t. t. t. t. t+2. On. On t+3.

(15) Interaktionsdiagramme • Ein Interaktionsdiagramm entspricht in unserer Terminologie eine Ablauf (Prozesssicht) • Das Interaktiondiagramm beschreibt einen Ablauf (Beispiel) und dabei welche Nachrichten in welchen Zeitintervallen auf welchen Kanälen fließen. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(16) Konzept: Interaktionssequenz Facility. ButtonB. ButtonA TrafLights PedLights IndicatA IndicatB ButtonB.Present. t Pr. -. -. -. -. IndicatorA.On. -. t+1. IndicatorB.On. -. -. -. -. -. -. Pr. -. Green. Stop. On. On. TrafLights.Green. t+2 PedLights.Stop ButtonB.Present. t+3. Sequenz: Beschreibung Teilablauf. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(17) Modell: Ablauf (Syntaktische) Schnittstelle: Typisierung • Komponentenbezeichner: K • Kanalbezeichner: i1,...,im,o1,...,on • Nachrichtentyp: I1,...,In,I1,...,In (Semantische) Schnittstelle: Verhalten • Abläufe: I1,⊥∞ × ... × Im,⊥∞ × O1,⊥∞ × ... × On,⊥∞ • Verhalten: B(i1,...,im,o1,...,on): B: I1,⊥∞ × ... × Im,⊥∞ ×O1,⊥∞ × ... × On,⊥∞ → B Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(18) Zusicherungen für Kommunikationshistorien •. Die Spezifikation eines System/Komponenten- verhaltens durch eine Formel B(i1,...,im,o1,...,on) ist syntaktisch korrekt, wenn – Die Formel nur über die vorgesehen Kanäle spricht – In der Formel die Kanalnamen für Ströme des ensprecenden Datentyps verwendet werden. •. Darüber hinaus gibt es noch semantische Bedingungen – Keine Widersprüche in der Formel – Keine Beschränkungen der Eingabe: ∀ i1,...,im. ∃ o1,...,on. B(i1,...,im,o1,...,on) – Keine Widerspruch zur Kausalität. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(19) Komposition • Syntaktische Kompatibilität – Kanalnamen und Kanaltypen passen zusammen. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(20) Konzept: Komposition A. A. BA:Signal. Merge. PL:PedColor. R eq:Signal. R eq:Signal. TL:TrafColor. Controller. BB:Signal. IndA:IndSig IndB:IndSig. BA:Signal. Merge BB:Signal. A. A. TL:TrafColor PL:PedColor. R eq:Signal Controller. IndA:IndSig IndB:IndSig. Komposition: •. Kopplung Komponenten mittels gemeinsamer Kanäle. •. Komponenteninteraktion mittels Nachrichtenaustausch. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(21) Verhalten von Architekturen • In den Architekturen gibt es Interaktion zwischen den Komponenten • Diese Interaktion kann wieder durch Interaktionsdiagramme dargestellt werden • Die so dargestellten Beispielabläufe müssen zu dem Verhalten der Komponenten passen. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(22) Konzept: Verteilter Ablauf C ontroller. Merge. BB.Present BA:Signal. A. A. Merge. TL:TrafColor PL:PedColor. R eq:Signal Controller. BB:Signal. R eq.Present. IndA:IndSig IndB:IndSig. IndA.On IndB.On TL.Green PL .Stop BB.Present. Ablauf: Signalhistorie komponiertes System •. Abläufe Komponenten. •. Synchronisation gemeinsamer Kanäle. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(23) Konzept: Kompositionalität BA:Signal. A. A. PL:PedColor. R eq:Signal. Merge. TL:TrafColor. Controller. BB:Signal. IndA:IndSig IndB:IndSig. C ontroller. Merge. BB.Present. R eq.Present. IndA.On IndB.On TL.Green PL .Stop BB.Present. Kompositionalität: Verhaltensbestimmung •. Von: Verhalten Einzelkomponenten. •. Zu: Verhalten Gesamtsystem Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(24) Modell: Komposition Komposition: K || K‘ • Schnittstelle K: i1,...,im,o1,...,on • Schnittstelle K‘: i‘1,...,i‘m‘,o‘1,...,o‘n‘ • Synchronisation i1 = o‘1,...,ik = o‘k, i‘1 = o1,...,i‘k‘ = ok‘ • Schnittstelle K||K‘: ik+1,...,im, i‘k‘+1,...,i‘m‘,o1,...,ono‘1,...,o‘n‘) • Verhalten K||K‘(ik+1,...,im, i‘k‘+1,...,i‘m‘,o1,...,ono‘1,...,o‘n‘) = K(i1,...,im,o1,...,on,) ∧ K‘(i‘1,...,i‘m‘,o‘1,...,o‘n‘) • Zusätzlich: Verstecken der internen Kanäle durch Existenzquantoren Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(25) Konzept: Kapselung. BA:Signal. A. A. Merge BB:Signal. TL:TrafColor PL:PedColor. R eq:Signal Controller. IndA:IndSig IndB:IndSig. Kapselung: Verbergen interner Struktur •. Unterkomponenten. •. Interne Kanäle Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(26) Konzept: Abstraktion Merge. TL:TrafColor. A. A. BA:Signal. PL:PedColor. R eq:Signal Controller. BB:Signal. IndA:IndSig IndB:IndSig. C ontroller. Merge. BB.Present. R eq.Present. IndA.On IndB.On TL.Green PL .Stop BB.Present. Abstraktion: Verbergen interne Kommunikation •. Von: Abläufe Glass-Box. •. Zu: Abläufe Black Box Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(27) Modell: Abstraktion. Komposition: K\{i1,...,ik,o1,..., ok‘} • Schnittstelle K: i1,...,im,o1,...,on, • Schnittstelle K\{i1,...,ik,o1,..., ok‘}: ik+1,...,im, ok‘+1,..., on • Verhalten K\{i1,...,ik,o1,..., ok‘}(ik+1,...,im, ok‘+1,..., on) = ∃i1,...,ik,o1,..., ok‘ . K(i1,...,im,o1,...,on). Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(28) Komposition von Spezifikationen Einführung. Ausgabekanäle. Eingabekanäle. Architekturbeschreibung Formale Modellierung Entwurf Wiederverwendung Evolution. Interne Kanäle. Composed components spec in x1: M1 , x2: M2 , ... out y1: N1 , y2: N2 , ... !c1, c2 , ... : P1 " ... " Pn. x1: M1 Composed Component. y1: N1. P1. c1 : T1. P3 P4. P2 y2 : N2. x2 : M2. Systemkomposition = logisches UND Channel Hiding = Existenzquantifikation Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(29) Zustandsmaschinen • Das Verhalten eines Systems/einer Komponente kann auch durch Zustandsmaschine mit Ein/Ausgabe beschrieben werden. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(30) Konzept: Zustandsautomat Signal requested. Receive request. Local Variables ofController:Controller Intt= -1 A. Green. Switch to yellow. TL:TrafColor. initialize Wait in yellow. RedYellow. Yellow. PL:PedColor. R eq:Signal Controller. IndA:IndSig. Switch to green. Init Switch to red. Switch to redyellow. IndB:IndSig. Red Wait in red. Automat: Zustandsorientierte Verhaltensbeschreibung •. Zustand: Betriebsmodi, Variablen , Eingabe Ausgabe. •. Übergang: Lese-/Schreibe-Aktion Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. Wait in redyellow.

(31) Konzept: Zustand State. Green. Green. Green. -1. 10. 9. Present. -. -. TL. -. Green. -. PL. -. Stop. -. Ind. -. On. -. T Req. Receive Request. Signal Requested. Zustand: Beobachtung zwischen zwei Übergängen •. Ports: aktuelle Nachrichten. •. Variablen: aktuelle Werte. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. T.

(32) Konzept: Übergang (t == (-1)):Req?Present:TL!Green; PL!Stop; Ind!On:t = TGreen Green. Receive request. Vorzustand. Nachzustand. Modus. t. Req. TL. PL. Ind. t. Modus. Green. -1. Present. Green. Stop. On. TGreen. Green. Übergang: Relation Vorzustand/Nachzustand •. Vorzustand: Modus, Variablen, Input Ports. •. Nachzustand: Output Ports, Variablen, Modus Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(33) Konzept: Ausführung State. Green. Green. Green. -1. 10. 9. Present. -. -. TL. -. Green. -. PL. -. Stop. -. Ind. -. On. -. T Req. t. t+1 Receive Request. t+2 Signal Requested. (t == (-1)):Req?Present:TL!Green; PL!Stop; Ind!On:t = TGreen. Receive request. Green. T t+3. Pre-State. Post-State. State. t. Req. TL. PL. Ind. t. State. Green. -1. Present. Green. Stop. On. TGreen. Green. Ausführungsschritt: Lesen Vorzustand/Schreiben Nachzustand •. Vorzustand: Kontrollzustand, Datenzustand, Eingabe. •. Nachzustand: Ausgabe, Datenzustand, Kontrollzustand. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(34) Modell: Ausführung Automat: Struktur •. Zustand: S (s0 Startzustand). •. Eingabe: i1,...,im. •. Ausgabe: o1,...,on. •. Übergangsrelation: T(s,i1,...,im,o1,...,on ,s): S ×I1× ... ×Im×O1× ... ×On×S → B. Automat: Verhalten • A(s,i1,...,im,o1,...,on): S∞ × I1,⊥∞ × ... ×Im, ⊥∞ ×O1,⊥∞ × ... ×On,⊥∞ → B •. A(s, i1,...,im,o1,...,on) = s.0 = s0 and o1.0 = ⊥ ∧ ... ∧ o1.0 = ⊥ ∧ ∀t. T(s.t,i1.t,...,im .t,o1 .(t+1),...,on.(t+1) ,s.(t+1)) Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(35) Ablauf einer Maschine • Eine Zustandsmaschine mit Ein-/Ausgabe erzeugt – für jede Eingabehistorie – Einen Ablauf bestehend aus • einem Strom von Zuständen • einerAusgahistorie. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(36) Konzept: Ablauf Zustandsautomat Local Variables ofController:Controller Intt= -1 A. TL:TrafColor PL:PedColor. R eq:Signal Controller. IndA:IndSig Signal requested. IndB:IndSig. Receive request. Green. Switch to yellow initialize Wait in yellow. Switch to green RedYellow. Yellow. Wait in redyellow. Init Switch to red. Switch to redyellow Red Wait in red. Ablauf Zustandsautomat: Einschränkung Ausführung •. Einschränkung auf Schnittstellen. •. Kapselung von Daten und Modus Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(37) Modell: Ablauf. Automat: Ausführungsablauf • K(i1,...,im,o1,...,on): I1,⊥∞ × ... ×Im, ⊥∞ ×O1,⊥∞ × ... ×On,⊥∞ → B •. K(i1,...,im,o1,...,on) = A(s,i1,...,im,o1,...,on) \ {s}. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(38) Zusammenfassung Integration von Modellen: •. Abläufe (Ströme) als gemeinsames Modell. •. Modularer Modellbegriff – Abläufe komponierter Komponenten aus Abläufen der einzelnen Komponenten – Abläufe gekapselter Komponenten aus Abläufen der offenen Komponenten – Abläufe implementierter Komponenten aus Abläufen der Zustandsmaschinen der Komponenten. Modulare Integration von Systemmodellen erlaubt modulare Systementwicklung Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(39) Towards a theory of modelling: meta model Composition Refinement Time Feature model Interface model: components Input and output uses Abstraction Abstraction. Composition Refinement Time. Is sub-feature. Composition Refinement Time. Implementation. Process transition model: Events, actions and causal relations Implementation. Abstraction. Hierarchy and architecture. uses State transition model: States and state machines uses Data model: Types/sorts and characteristic functions Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. Composition Refinement Time.

(40) Systemmodell Ein System •. hat eine syntaktische Schnittstelle (Ein-/Ausgabekanäle). •. wird in Verhalten und/oder Struktur dargestellt – IF: durch stromverarbeitende Funktion beschrieben eine logische Formel (Schnittstellenspezifikation) – ZM: eine Zustandsmaschine, beschrieben durch ein Zustandsübergangsdiagramm – AR: eine Architektur, beschrieben durch ein Netzwerk von Komponenten (für die wiederum Verhaltensbeschreibungen existieren) – PR: durch Mengen von Abläufen, beschrieben durch eine Menge von Interaktionsdiagrammen. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(41) Übergänge zwischen Darstellungen Zwischen jeder der Darstellungen gibt es Übergange. IF. ZM. AR. IF ZM AR PR. Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. PR.

(42) Wechsel zwischen Systemsichten • Ist für jede Komponente einer Architektur eine Zustandsmaschine gegeben, so kann die Architektur als Zustandsmaschine aufgefasst werden. • Jede stromverarbeitende Funktion definiert eine Zustandsmaschine und umgekehrt • .... Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(43) Beispiel für ein Verträglichkeitseigenschaft ... Sei • Abs die Schnittstellenabstraktion für Zustandsmaschinen • II die Komposition auf Zustandsmaschinen • ⊗ die Komposition für Schnittstellen. Abs((Δ1, σ1) || (Δ2, σ2) ) = Abs((Δ1, σ1)) ⊗ Abs((Δ2, σ2)) Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering.

(44)