Inkonsistenzen und deren Konsequenzen in Software Modellen

Integrierte Softwareentwicklungsumgebungen verfügen über ein reiches Angebot an Funktionalitäten zur Entdeckung und Beseitigung von Fehlern im Quellcode. Zum Beispiel bietet Eclipse sogenannte "Quick Fixes", die potentielle Lösungen für Programmierfehler generieren. Programmierer finden diese Art der Unterstützung sehr nützlich. Manche Designwerkzeuge bieten bereits ähnliche Mechanismen um Designprobleme zu lösen, jedoch ist die Unterstützung auf Modellebene momentan noch sehr eingeschränkt. In Modellierungssprachen wie der Unified Modeling Language (UML) werden Einschränkungen typischerweise in Form von Konsistenzregeln definiert. Um automatisierte Auflösungsmechanismen anbieten zu können, sind Werkzeugentwickler somit gezwungen manuell zu beschreiben wie die Verletzung einer Konsistenzregel behoben werden kann. Wenn die Anzahl an Konsistenzregeln steigt, stellt dies einen erheblichen Aufwand dar. Zusätzlich müssen Entwickler dieser Auflösungsmechanismen dafür sorgen, dass die angebotenen Lösungen korrekt sind, also Inkonsistenzen auflösen ohne neue einzuführen. Dies ist besonders schwierig für Multi-Paradigmen Modellierungssprachen wie der UML, da eine Vielzahl von Interaktionen zwischen Konsistenzregeln existieren. Ein zusätzliches Problem stellt die Tatsache dar, dass unterschiedliche Entwicklungsteams oft unterschiedliche Konsistenzregeln verwenden, oder verschiedene Gruppen von Regeln in verschiedenen Phasen des Projektlebenszyklus verwendet werden. "Fest programmierte" Auflösungsmechanismen die für einen fixen Satz an Konsistenzregeln definiert werden sind somit unbrauchbar, da sie deren variierende Auswirkungen vernachlässigen. Die vorgeschlagene Arbeit wird eine Grundlage entwickeln um Änderungen in Designmodellen zu verstehen. Dieses Problem ist komplex da nicht jede Änderung Inkonsistenzen hervorruft, nicht jede Inkonsistenz unerwünscht ist und nicht jede Inkonsistenz lösbar ist ohne neue Inkonsistenzen zu erzeugen. Genauso ist es nicht praktikabel alle Möglichkeiten einer Inkonsistenzbeseitigung aufzulisten da dies typischerweise sehr viele sind, was den Modellierer wiederum überfordern würde. Um zu entscheiden wie eine Inkonsistenz beseitigt werden kann, ist es sehr nützlich zu wissen was sie hervorgerufen hat. Manche Inkonsistenzen werden durch fehlerhafte Änderungen, manche durch korrekte jedoch unvollständige Änderungen erzeugt. Schlussendlich kann noch unterschieden werden zwischen Inkonsistenzen die ein Modellierer so schnell wie möglich beseitigen möchte und Inkonsistenzen die der Modellierer bereit ist zu tolerieren. Das Verstehen wie Inkonsistenzen behoben werden können ist ein ungelöstes Problem das jedoch unerlässlich ist für die Zukunft der Softwaremodellierung und der Softwareentwicklung im gesamten.

Viele Softwarefirmen sind auf Software Design Modelle angewiesen. Trotzdem haben diese Firmen falsche Vorstellungen vom Nutzen solcher Modelle. Im Unterschied zu anderen Ingenieursdisziplinen, in welchen das Modellieren sich als effektiver Mechanismus beim Umgang mit Komplexität bewiesen hat, müssen Software Modelle dieses Levels an Reife erst erreichen. Eine der wichtigsten Herausforderungen ist die Evolution von Modellen und die Fähigkeit Modeländerungen und deren Auswirkungen zu verstehen. Änderungen haben gewünschte Effekte indem sie Softwareeigenschaften hinzufügen oder ändern. Allerdings, haben sie auch ungewünschte Seiteneffekte und erzeugen häufig Fehler. Im Kontext von Designmodellen manifestieren sich diese Fehler als Inkonsistenzen.Dieses Projekt beschäftigte sich damit Inkonsistenzen zu erkennen und zu beheben, wenn sie durch definierte Constraints (Bedingungen) nachweisbar sind. Inkonsistenzen treten typischerweise durch unvollständiges oder falsches Reagieren auf Änderungen auf. Die Behebung von Inkonsistenzen in Softwaremodellen ist eine komplexe Aufgabe, weil die Anzahl der möglichen Reparaturaktionen exponentiell anwächst. Im Zuge dieses Projekts wurde eine Methode für den Umgang mit diesem Problem beigesteuert, durch Konzentration auf die Ursache der Inkonsistenz und das hierarchische Präsentieren von Reparaturaktionen. Die Ursache wird durch die Analyse der Struktur und des Verhaltens bei der Validierung des verletzen Constraints festgestellt. Dies erlaubt uns festzustellen welcher Teil des Constraints nicht erfüllt wurde und warum.Ein Schlüsselaspekt unserer Vorgehensweise ist das Behandeln von Inkonsistenzen als Symptome von Fehlern und nicht als Fehler selbst. Da falsche Änderungen mehrere Inkonsistenzen hervorrufen können (oder keine wenn sie noch keine Constraints verletzen), ist es nicht nützlich dass der Ingenieur die Fehler anhand der Reparaturvorschläge identifizieren muss. Unsere Vorgehensweise empfiehlt daher das Identifizieren von Fehlern anhand von Kombinationen von Inkonsistenzen und erlaubt daher das Filtern und Untersuchen von Inkonsistenzen in verschiedenen Dimensionen. Ein anderer Schlüsselaspekt unserer Vorgehensweise ist ein generischer Grundgedanke, um nicht nur aktuelle Modelliersprachen (wie z.B. UML) zu unterstützen. Daher haben wir unsere Vorgehensweise auch in verschiedenen Modellierdomänen angewandt: bei Produktlinien, in der Mechatronik, der Coevolution von Meta-Modellen und Modellen, und Entscheidungsmodellen. Dadurch haben wir nicht nur die Korrektheit und Skalierbarkeit in einer Domäne erforscht, sondern auch die Anwendbarkeit in verschiedenen Domänen demonstriert.