Entwicklung und Anwendung eines Bezugsrahmens zur ...

und Schnittstellen, die in Klassendiagrammen definiert wurden, aufgeführt. Andere Elemente werdendahingehend nicht berücksichtigt. Der Aufruf des Eigenschaftendialogs der angezeigten Modellelementekann auch vom Explorer aus erfolgen, wobei sich dort vorgenommene Modifikationen analogzu Änderungen in einem Diagramm auf das Modellelement inkl. der Summe seiner grafischen und imQuellcode existierenden Repräsentationen auswirkt. Das Diagramm, das gerade bearbeitet wird,kann zusätzlich in einer verkleinerten Form im Explorer an Stelle der Liste der Modellelemente angezeigtwerden. Diese Überblicksdarstellung dient zur Navigation zu den einzelnen Elementen in demeigentlichen Diagramm, indem der sichtbare Ausschnitt dort in seiner Vergrößerungsstufe und Positionfrei bestimmt werden kann. Allerdings ist es in dieser Darstellung nicht möglich die Diagrammelementegenau zu identifizieren. Alternativ kann die Vergrößerungsstufe in der eigentlichenDiagrammanzeige festgelegt werden. Die automatische Anordnung der Diagrammelemente (autolayout)funktioniert nur bei kleineren Diagrammen zufriedenstellend. Insbesondere bei Diagrammen miteiner großen Anzahl an Beziehungen zwischen den Elementen gerät die Darstellung schnell unübersichtlich,so daß eine Anordnung per Hand vorzuziehen ist.MechanismenEs wird keine vom Benutzer explizit initiierbare Konsistenzüberprüfung des Modells angeboten. Dieeinzigen diagrammübergreifenden Möglichkeiten zur Konsistenzerhaltung werden implizit durchgeführtund betreffen zum einen die Synchronisierung zwischen entsprechend verknüpften InteraktionsundKlassendiagrammen bzgl. Objekten und Methodenaufrufen und zum anderen die gemeinsameVerwaltung von Sequenz- und Kollaborationsdiagrammen. Diese werden in Together als semantischeEinheit verwaltet, d.h. es kann ein Diagramm einer der beiden Diagrammarten erstellt und gegebenenfallsin ein Diagramm des anderen Typs überführt werden. Dabei werden alle Einstellungenbeibehalten, die für eine Diagrammart festgelegt wurden, auch wenn sie in dieser Form nicht in demkorrespondierenden darstellbar sind (s. dazu auch Abschnitt 4.3.3.3). Alle anderen Diagramme werdenaußer bei Verwendung von Shortcuts, die in der Terminologie von Together Referenzen aufModellelemente anderer Diagramme darstellen, nicht auf Konsistenz bzgl. des Gesamtmodells überprüft.Shortcuts werden mit dem Element, aus dem sie hervorgegangen sind, bei Änderungen in beideRichtungen synchronisiert.Falls mit mehreren Together-Instanzen gearbeitet wird oder die gleichzeitige Nutzung einer anderenApplikation wie bspw. eine Entwicklungsumgebung für Java oder C++ angestrebt ist, verfolgt Togetherdie Strategie anhand des Änderungsdatums der jeweiligen Datei zu überprüfen, ob an diesereine Modifikation vorgenommen wurde. Falls dies zu einem Zeitpunkt zutrifft, wird der betroffeneQuellcode und in der Folge das Modell entsprechend der extern vorgenommenen Änderung aktualisiert.Diese Synchronisierung kann gegebenenfalls auch manuell initiiert werden. Als Folge werdenjegliche Informationen das Modellelement betreffend in Together überschrieben und sind auch durchdie Funktion zum Rückgängigmachen der letzten Benutzeraktion nicht mehr zu revidieren. Somit isteine Gefahr der Erzeugung von Inkonsistenzen implizit gegeben. Um dies zu vermeiden, bietet sichder ausschließliche Datenaustausch mit externen Applikationen über den Checkin/Checkout-Mechanismus eines Repositories an. Dieser erscheint zwar gegenüber der eben erläuterten Strategieweniger flexibel, ist dafür aber eher geeignet, die Entstehung von Inkonsistenzen zu verhindern.Insgesamt ist aufgrund der größtenteils semantischen Isolation der Diagrammarten im Modell dieUnterstützung des Werkzeugs bei der Konsistenzerhaltung minimal. Die Verantwortung diesbezüglichobliegt in der Hauptsache dem Modellierer. Die vornehmlich impliziten Konsistenzüberprüfungsmechanismenberücksichtigen diagrammübergreifend nur die Diagrammarten, die eineVerbindung zum Quellcode besitzen.- 201 -