Entwicklung und Anwendung eines Bezugsrahmens zur ...

1) Das Tool weist auf Konflikte im Rahmen einer Konsistenzüberprüfung des Modells unabhängigvon der anvisierten Programmiersprache hin2) Die Strategie wird an die Vorgaben der als Zielsprache festgelegte Programmiersprache angelehnt3) Es wird keine oder eine nicht nachvollziehbare Unterstützung bei der Auflösung von KonfliktenangebotenIm Fall 1) wäre denkbar, daß die Konsistenzprüfung zu vom Benutzer gewählten Zeitpunkten erfolgt,um so auf nicht UML-konforme Modellkonstrukte hinzuweisen. Eine alternatives Vorgehen ist dieÜberprüfung der Konsistenz des Modells bei jeder Änderung, so daß beim ersten Auftreten möglicherInkonsistenzen ein Hinweis auf die Problemquelle erfolgt. Bei beiden Varianten sollte die Möglichkeitbestehen eventuell vorgeschlagene Änderungen des Systems zu übernehmen oder diese zuverwerfen und eigene Lösungsstrategien zu verfolgen, die anschließend wiederum vom Tool überprüftwerden müssen. Eine Bindung an die Vorgaben der Software ohne die Möglichkeit eigeneStrategien zu verfolgen ist weniger wünschenswert. Neben der Frage des Zeitpunkts der Konsistenzüberprüfungist die Reichweite der Kontrollmechanismen bzgl. der Konsistenzerhaltung desModells zu klären. Bei Einfachvererbung sollten die oben diskutierten Restriktionen bei der Redeklarationvon Attributen und Operationen überprüft werden. Im Falle von Mehrfachvererbung ist zusätzlichauch auf widersprüchlich formulierte Zusicherungen, die einen Konflikt verursachen können,zu achten. Es ist im Rahmen der Evaluation zu ermitteln, ob diese Zusicherungen vom Modellierungswerkzeuginterpretiert und somit in eine Überprüfung des Modells mit einbezogen werden.Wenn wie unter 2) aufgeführt die Realisierung der Generalisierung sich an den Vorgaben der Programmierspracheorientiert, die als Implementierungsbasis festgelegt wurde, ist zu klären, inwieweitdiese mit der Semantik der Generalisierung in der Sprachspezifikation der UML konfligiert. Da einigeProgrammiersprachen wie z.B. Java keine Mehrfachvererbung zulassen, wird in diesem Fall dieMächtigkeit des Sprachschatzes der UML zugunsten der Kompatibilität zu der Programmierspracheeingeschränkt. Falls die Software Phasen eines Prozesses unterstützt, ist zu untersuchen, ob eineBindung an die Semantik der Programmiersprache schon in den frühen Prozeßphasen oder erst währenddes Designs erzwungen wird. Wird das Modell auf eine Programmiersprache abgebildet, dieselektives Erben unterstützt, d.h. ein Mechanismus zur Auflösung von Namenskonflikten steht zurVerfügung, ist zu verifizieren, wie dieser Mechanismus umgesetzt wird. Auch hier kann der Zeitpunktder Überprüfung der im Tool festgelegten Regeln für die Generalisierung variieren. Entweder könnendie unter 1) beschriebenen Strategien der Überprüfung vor dem Hintergrund der Vorgaben der Programmiersprachevom Tool umgesetzt werden, oder die Aufgabe wird an den Compiler delegiert,der als letzte Instanz die Zulässigkeit der Konstrukte bzgl. der Möglichkeiten, welche die Programmiersprachebietet, überprüft und entsprechende Fehlermeldungen generiert.Der Fall 3), bei dem keine oder eine nicht nachvollziehbare Unterstützung zur Lösung der Problematikseitens des Tools angeboten wird, ist als signifikante Einschränkung des Komforts bei der Arbeitmit der Software zu interpretieren und prinzipiell negativ zu beurteilen. In diesem Falle werden dieMöglichkeiten, die ein Modellierungswerkzeug vom Potential her bieten kann, nicht konsequent ausgeschöpftund Fehler bei der Erstellung eines Modells toleriert.3.3.2.3.2 AssoziationenIn diesem Abschnitt wird die Definition der Assoziation in der UML kurz erläutert und ausführlicherauf die Semantik der Generalisierung von Assoziationen eingegangen.- 83 -