Spezifikationsmodule - Software and Systems Engineering - TUM

Weitere Magazine

Empfehlungen

Info

zwei Datentypen auf Vereinbarkeit geprüft werden. Anh<strong>and</strong> eines einfachen Beispiels haben wir die interaktive Typvereinigung auch konstruktiv durchgeführt und schließlich noch die allgemeine Version der interaktiven Vereinigung von Datentypen, Konstruktoren und Selektoren programmiert. Dieses Wissen wird uns im Weiteren helfen ein Lösungskonzept für die gestellte Gesamtaufgabe aus theoretischer Sicht zu entwickeln. Bei der konkreten Umsetzung eines auf diesem Konzept beruhenden interaktiven Ablaufs werden wir Teile der hier definierten ODL-Ausdrücke wiederverwenden. 31
Kapitel 4 Spezifikationsvereinigung aus theoretischer Sicht Nachdem wir in Kapitel 3 einen ersten Eindruck gewonnen haben, wie mit ODL das Teilproblem der Typunifikation gelöst wird, wenden wir uns nun wieder dem Gesamtproblem der Spezifikationsvereinigung zu. In diesem Kapitel werden wir hierfür ein Lösungskonzept entwickeln und formal fundieren. Wir erläutern zunächst geeignete Lösungsstrukturen. Über diesen werden wir, ausgehend vom AutoFocus 2-Metamodellstruktur, Prädikate definieren, welche uns die Lösung des Vereinigungsproblems als Variablenbelegungsproblem ermöglichen. Eine Betrachtung des notwendigen Berechnungsaufw<strong>and</strong>es des beschriebenen Verfahrens schließt dieses Kapitel ab. Die hier gezeigte theoretische Fundierung ist für das Anwendungsbeispiel aus Kapitel 2 um viele Modellelemente vereinfacht worden. In Anhang A finden sich die für das Anwendungsbeispiel relevanten, zusätzlichen Theorieüberlegungen, die aber im Wesentlichen den hier beschriebenen entsprechen. 4.1 Definition des Lösungsraumes Im Einführungsbeispiel (siehe Kapitel 3) zu ODL haben wir gesehen, wie die Typunifikation realisiert wurde. Das Problem der Spezifikationsvereinigung werden wir ebenfalls mit Hilfe eines der Unifikation ähnlichen Ablaufs lösen. In Abschnitt 3.4 haben wir gesehen, wie die Typvereinigung mit ODL interaktiv durchgeführt wird. Die Eingabe des Benutzers waren dabei Mengen von 2-Tupeln über den Modellelementmengen der Datendefinitionen DataDef, Konstruktoren Constructor und Selektoren Selector. Verallgemeinern wir diese Strukturen, so kommen wir zu Relationen von zu unifizierenden Modellelementen, die wir im folgenden als Unifikationsrelationen bezeichnen. Wir erhalten jeweils eine Unifikationsrelation für jedes Metamodellelement, also für jede Klasse von Modellelementen. Für unser Beispiel sind dies die folgenden Relationen: componentMap ∈ P( Component × Component ) portMap ∈ P( P ort × P ort ) 32
Seite 1 und 2: Modellbasierte Entwicklung: Spezifi
Seite 3 und 4: Ich versichere, dass ich diese Dipl
Seite 5 und 6: Zusammenfassung Im Bereich eingebet
Seite 7 und 8: 6 Fazit und Ausblick 58 6.1 Einordn
Seite 9 und 10: Entwicklungsprozesses und der Einze
Seite 11 und 12: Kapitel 2 Modelltransformationen, W
Seite 13 und 14: Recheneinheiten bzw. -funktionen da
Seite 15 und 16: oder Ausgabeschnittstelle der Kompo
Seite 17 und 18: Modellschnittstellen Datentypen, Te
Seite 19 und 20: ) result has Name(np, data.s) and r
Seite 21 und 22: ErrorTreatment Verhalten :Cntrl?Sta
Seite 23 und 24: 2.5 Einschränkungen für die Model
Seite 25 und 26: Kapitel 3 Einführungsbeispiel: Typ
Seite 27 und 28: DTD 0..* DTDModule 0..* TypeDef 0..
Seite 29 und 30: 1. eines der beiden Zeichen ist ein
Seite 31 und 32: Haben wir namensgleiche Konstruktor
Seite 33 und 34: Abschließend erzeugen wir die Kons
Seite 35: 30 Abbildung 3.3: Eingabedialog zur
Seite 39 und 40: ErrorTreatment Verhalten :Cntrl?Sta
Seite 41 und 42: DataDefinition Component Constructo
Seite 43 und 44: ... exists constructorMap: set (Con
Seite 45 und 46: Kapitel 5 Interaktive Spezifikation
Seite 47 und 48: 5.2.1 Struktursicht Die Struktursic
Seite 49 und 50: Abbildung 5.3: Dialog für Zuständ
Seite 51 und 52: leiten wir die zu vereinigenden Kon
Seite 53 und 54: 5.4 Umsetzung der Dialogführung in
Seite 55 und 56: tm_fp3.one = fp3_it.one.TransitionS
Seite 57 und 58: Abhängigkeiten bezüglich dieser b
Seite 59 und 60: deten Quellstrukturen identisch zum
Seite 61 und 62: esult has Name(mk_prt.copy, concat(
Seite 63 und 64: Kapitel 6 Fazit und Ausblick Abschl
Seite 65 und 66: nisch umsetzbar, da die bisherigen
Seite 67 und 68: Anhang A ODL Programm der Spezifika
Seite 69 und 70: Das im nächsten Abschnitt abgedruc
Seite 71 und 72: sel1:Selector, sel2:Selector ) := (
Seite 73 und 74: * LocVariable */ exists lvar_map_po
Seite 75 und 76: exists lvm_fpactm:lvar_map . ( fpac
Seite 77 und 78: forall ap1:(ae.one.Args) . exists a
Seite 79 und 80: fpclvrs_it.Component = component_pa
Seite 81 und 82: exists copy_action_set: lfp FP_CACT
Seite 83 und 84: exists new_automaton:new Automaton
Seite 85 und 86: )) and /* copy constructors not mer
Seite 87 und 88:
* merged states are part of root st
Seite 89 und 90:
nctsgm_mkifp.orig.SourcePoint = mk_
Seite 91 und 92:
nlvm_elem_lvcnm.orig.one = mk_lvc.o
Seite 93 und 94:
nlvarcopy_arg.orig = param and resu
Seite 95 und 96:
exists new_copy_output_map:map orig
Seite 97 und 98:
new_constructor_map, new_copy_const
Seite 99:
[TUM04b] AutoRaid. http://www4.in.t
Alle anzeigen

Spezifikationsmodule - Software and Systems Engineering - TUM

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?