Eclipse Model Repository

Produktskizze

Projektziele

Kurze Problembeschreibung mit fachlichem Hintergrund

Softwareentwicklung wird durch steigende fachliche und vor allem technische Anforderungen immer komplexer. Modellgetriebene Softwareentwicklung (MDSD) bietet eine Möglichkeit, die gestiegene Komplexität der Software durch ein höheres Abstraktionsniveau zu beherrschen und ist daher ein Softwareentwicklungsansatz mit hohem Zukunftswert. Dabei stellen Modelle die wichtigsten Artefakte des Entwicklungsprozesses dar. Auf Grund der Vielzahl an Modellen besteht der Bedarf, sie zu verwalten.

Ableitung der Projektziele

Ziel des Projektes ist die Entwicklung eines Ablage- und Verwaltungssystems für Modelle (M1) und Metamodelle (M2). Als Metametamodell wird das EMF (Eclipse Modeling Framework) Ecore verwendet. Das System muss folgende Funktionalitäten bereitstellen: Speichern, Laden, Vergleichen von Modellen sowie das Suchen nach Modellen und Modellelementen. Weiterhin muss es möglich sein, Modelle miteinander zu verschmelzen . Eine Anwendung, die Modellrepository genannt wird, soll die Ablage- und Verwaltungslogik des Systems bereitstellen. Zur Nutzung des Modellrepositorys wird eine grafische Oberfläche entwickelt, die sich als Plugin in die Entwicklungsumgebung Eclipse integrieren lässt.

Anwendungsfälle

UML 2.1 Anwendungsfalldiagramme

Übersichtsdiagramm der Grobziele

Anwendungsfalldiagramm der Nutzerziele

Anwendungsfallbeschreibung

Anwendungsfall: [1] Modell laden

Nutzungskontext	Modellierer möchte ein im Repository befindliches Modell anzeigen und bearbeiten. Dazu wird eine Arbeitskopie des ausgewählten Modells im lokalen Workspace abgelegt.
Primärer Akteur	Modellierer
Auslöser	Modellierer fordert ausgewähltes Modell an
Vorbedingungen	Im Repository befindet sich mindestens ein Modell
Wichtigstes Erfolgsszenario	Siehe Aktivitätsdiagramm
Extensionen	Siehe Aktivitätsdiagramm
Nachbedingungen	Bei Ausgang „Erfolg“: Das Repository befindet sich im gleichen Zustand wie vorher; das geladene Modell ist in der lokalen Projektstruktur verfügbar Bei Ausgang „Misserfolg“: Das Repository sowie die lokale Projektstruktur befinden sich im gleichen Zustand wie vorher
Priorität	kritisch

Anwendungsfall: [2] Modell speichern

Anwendungsfall: [1] Modell speichern

Nutzungskontext	Modellierer möchte ein Modell aus der lokalen Projektstruktur im Repository ablegen. Dazu wird geprüft, ob das Repository bereits ein Modell mit dem gleichen Identifikator enthält. Falls ja, wird der Modellierer gefragt, ob das bestehende Modell ersetzt werden soll und entsprechend den Angaben weiter verfahren.
Primärer Akteur	Modellierer
Auslöser	Modellierer fordert Speicherung des ausgewählten Modells an
Vorbedingungen	Mindestens ein Modell existiert im lokalen Workspace
Wichtigstes Erfolgsszenario	Siehe Aktivitätsdiagramm
Extensionen	Siehe Aktivitätsdiagramm
Nachbedingungen	Bei Ausgang „Erfolg“: Das zu speichernde Modell ist im Repository abgelegt Bei Ausgang „Misserfolg“: Das Repository befindet sich im gleichen Zustand wie vorher
Priorität	kritisch

Anwendungsfall: [3] Suche durchführen

Nutzungskontext	Modellierer möchte das Repository nach Modellen und Modellelementen mit bestimmten Eigenschaften durchsuchen. Dazu spezifiziert er eine Reihe von Suchkriterien.
Primärer Akteur	Modellierer
Auslöser	Modellierer spezifiziert Suchkriterien und startet die Suche
Vorbedingungen	Im Repository befindet sich mindestens ein Modell
Wichtigstes Erfolgsszenario	Siehe Aktivitätsdiagramm
Extensionen	Siehe Aktivitätsdiagramm
Nachbedingungen	Bei Ausgang „Erfolg“: Das Repository befindet sich im gleichen Zustand wie vorher; die Liste der gefundenen Modelle wird dem Modellierer angezeigt Bei Ausgang „Misserfolg“: Das Repository befindet sich im gleichen Zustand wie vorher
Priorität	kritisch

Anwendungsfall: [4] Modelle vergleichen

Nutzungskontext	Modellierer möchte Unterschiede und Gemeinsamkeiten zweier Modelle ermitteln, zum Beispiel, ob sie das gleiche Metamodell und/oder Modellelemente mit gleichem Namen oder Bedeutung haben.
Primärer Akteur	Modellierer
Auslöser	Modellierer spezifiziert die zu vergleichenden Modelle und startet den Vergleich
Vorbedingungen	Mindestens eines der ausgewählten Modelle befindet sich im Repository
Wichtigstes Erfolgsszenario	Siehe Aktivitätsdiagramm
Extensionen	Siehe Aktivitätsdiagramm
Nachbedingungen	Bei Ausgang „Erfolg“: Das Repository befindet sich im gleichen Zustand wie vorher; die Liste der ermittelten Gemeinsamkeiten und Unterschiede wird dem Modellierer angezeigt Bei Ausgang „Misserfolg“: Das Repository befindet sich im gleichen Zustand wie vorher
Priorität	kritisch

Anwendungsfall: [5] Modelle zusammenführen

Nutzungskontext	Modellierer möchte ein bestehendes Modell durch Zusammenführen mit einem anderen bestehenden Modell und ggf. schrittweiser Konfliktlösung erweitern bzw. zu einem neuen Modell verschmelzen
Primärer Akteur	Modellierer
Auslöser	Modellierer wählt zwei zu verschmelzende Modelle aus
Vorbedingungen	Mindestens eines der ausgewählten Modelle befindet sich im Repository
Wichtigstes Erfolgsszenario	Siehe Aktivitätsdiagramm
Extensionen	Siehe Aktivitätsdiagramm
Nachbedingungen	Bei Ausgang „Erfolg“: Entsprechend den Modelliererangaben wurde das Repository um eine neue Version des zu aktualisierenden Modells oder um ein neues Modell erweitert Bei Ausgang „identische Modelle“: Das Repository befindet sich im gleichen Zustand wie vorher Bei Ausgang „inkompatible Modelle“: Das Repository befindet sich im gleichen Zustand wie vorher Bei Ausgang „unlösbarer Konflikt“: Das Repository befindet sich im gleichen Zustand wie vorher; die Liste der ungelösten Konflikte wird dem Modellierer angezeigt
Priorität	kritisch

"Rollenbeschreibung"

Rolle	Modellierer
Tätigkeitsprofil	Modelle speichern Modelle laden Modelle vergleichen Suche durchführen Modelle zusammenführen
benötige Fähigkeiten	PC-Anwenderkenntnisse: Anwendungen lokalisieren und starten sicherer Umgang mit der Benutzeroberfläche Modellierungskenntnisse im verwendeten Metamodell
Akzeptanzkriterien	Zuverlässigkeit Ergonomie Verfügbarkeit Robustheit Interoperabilität
Nutzungshäufigkeit	Nicht schätzbar
Anzahl Benutzer	Plugin – in der Regel ein Benutzer Repository – nicht schätzbar

Nicht funktionale Anforderungen

Anforderung	Verifikationskriterium
Technische Anforderungen
Programmiersprache	Es kommt ausschließlich die Programmiersprache Java zum Einsatz.
Hardwarekomponenten	Das System wird so gestaltet, dass es auf einem Rechner vergleichbar der aktuellen Hardwareausstattung des FRZ zum Einsatz kommen kann.
Datenaustausch	Die Kommunikation zwischen Plugin und Repository-Server soll auf Basis der Protokolle TCP/IP und der im FRZ bestehenden Netzwerkinfrastruktur möglich sein.
Eingesetzte Software	Der Repository-Server muss innerhalb einer Java VM ohne grafische Oberfläche lauffähig sein. Das Plugin muss innerhalb der Eclipse-Version 3.4 lauffähig sein.
Architektur	Das System wird als zwei getrennte Anwendungen entwickelt: das Modell-Repository und das Eclipse-Plugin. Die Architektur wird als Client-Server-Muster ausgeprägt.
Mengengerüst	Das Modell-Repository muss gleichzeitig von mindestens einem Client verwendet werden können. Das Plugin muss von genau einem Benutzer gleichzeitig verwendet werden können.
Bedienelemente	Die Entwicklung des Plugin-Frontends und dessen Bedienelemente erfolgt mit SWT und abgeleiteten Techniken. JFC (AWT, Swing) kommt nicht zum Einsatz.
Bedienkonzepte	Das Eclipse-Plugin wird entsprechend der Richtlinien für Eclipse-Plugins entwickelt und fügt sich in das Look-and-Feel (Konfiguration, Farben, Fonts und Bedienung) der Eclipse-Plattform.
Qualitätsanforderungen nach DIN EN ISO 66272
Funktionalität
Interoperabilität	Das Modell-Repository soll innerhalb eines Java-Web-Containers installiert werden können und darf allein durch seine Anwesenheit andere Anwendungen nicht beeinflussen. In Lastsituationen kann es zu einer Beeinflussung paralleler Prozesse kommen. Das Plugin darf durch seine Anwesenheit nicht die Anwesenheit anderer Plugins ausschließen.
Zuverlässigkeit
Fehlertoleranz	Bei unvorhergesehenen Situationen muss das Modell-Repository eine Fehlermeldung an seinen Client liefern. Das Plugin muss bei Auftreten von unvorhergesehenen Situationen eine Fehler-, Warn- oder Informationsmeldung anzeigen oder in einer Fehlerliste eintragen. Beim Start des Modell-Repositorys muss dessen Konsistenz überprüft und bei Bedarf automatisch wiederhergestellt werden. Es dürfen nur konsistente Daten Eingang ins Modell-Repository finden, was durch Validierung abzusichern ist.
Reife	Das Modell-Repository muss ununterbrochen einsetzbar und lauffähig sein. Vollständige Testabdeckung aller öffentlichen Service-Methoden des Modell-Repositorys muss gewährleistet sein.
Wiederherstellbarkeit	Nach Absturz des Modell-Repositorys muss die Anwendung ohne externen Reparaturaufwand wieder startbar sein und alle ggf. notwendigen Reparaturarbeiten selbständig ermitteln und ausführen. Sicherung des Persistenzmediums erfolgt mit den Mitteln des darunter liegenden Dateisystems. Nach Absturz des Plugins muss dieses zumindest durch Deinstallation und Neuinstallation in die Eclipse-Umgebung wieder zum Einsatz gebracht werden können.
Benutzbarkeit
Verständlichkeit	Alle Bedienelemente und Beschriftungen des Plugins liegen in englischer Sprache vor. Fehler-, Warn- und Informationsmeldungen sind in englischer Sprache ausformuliert und erklären das eingetretene Ereignis.
Bedienbarkeit	Die Bedienung des Plugins muss durch Maus- und Menüinteraktionen erfolgen können.
Erlernbarkeit	Die Beschriftung der Bedienelemente des Plugins erfolgt mit Begriffen aus der fachlichen Domäne des Modellierers. Die Einarbeitung beschränkt sich auf das Lernen der Prozessabläufe.
Effektivität	Das Plugin führt Aktionen nach deren Start ohne erneute Rückfrage aus. Im Fehlerfall erfolgt eine Fehler- oder Warnmeldung.
Einheitlichkeit	Das Plugin fügt sich in das Look-and-Feel (Konfiguration, Farben, Fonts und Bedienung) der Eclipse-Plattform ein.
Effizienz
Zeitverhalten	Das Plugin signalisiert nach spätestens 2 Sekunden Arbeitsdauer mit einer Sanduhr oder einem Fortschrittsbalken die andauernde Tätigkeit des Systems.
Änderbarkeit
Aufwand und Auswirkungen auf Gesamtsystem	Das System ist so zu entwickeln, dass es leicht erweitert werden kann. Dies bedingt, dass Schichten entkoppelt sind und sich austauschen lassen, ohne die Architektur des Gesamtsystems zu verändern.
Übertragbarkeit
Konformität	Die Entwicklung erfolgt unter Einhaltung der Code-Konventionen und Dokumentationsrichtlinien in englischer Sprache.
Installierbarkeit	Das Modell-Repository lässt sich als Webanwendung innerhalb eines Java-Webcontainers installieren. Das Plugin lässt sich in die Eclipse-3.4-Plattform installieren. Die Installation muss auf der Grundlage einer JVM von Sun erfolgreich sein können.
Anforderungen an sonstige Lieferbestandteile
Software-Dokumentation	Für das System wird eine Dokumentation der Funktionen der Software erstellt.
Entwickler-Dokumentation	Es wird eine Anleitung zum Entwickeln der Anwendung erstellt, die einem neuen Teammitglied mit Details einen Einstieg in die Weiterentwicklung ermöglicht. Diese Dokumentation enthält eine Anleitung, wie aus dem Quellcode der lauffähige Objektcode mit allen installierbaren Artefakten erstellt werden kann.
Installations-Dokumentation	Es wird eine Dokumentation erstellt, die beschreibt, wie das Modell-Repository und das Plugin installiert, konfiguriert und in Betrieb genommen werden.
Wartungs-Dokumentation	Es wird eine Dokumentation erstellt, die beschreibt, wie das Modell-Repository und das Plugin gewartet werden.
Anwender-Dokumentation	Es wird eine Dokumentation erstellt, die aufgabenzentriert beschreibt, wie ein Anwender mit dem System arbeitet.
Test-Dokumentation	Es wird eine Dokumentation erstellt, die zeigt, wie die Projektumgebung aufgesetzt und in Betrieb genommen werden kann, um das Projekt neu aufzusetzen.
Anforderungen an durchzuführende Tätigkeiten
Abnahmezeitpunkte, Übergabe	Der vorgegebene Zeitplan muss eingehalten werden.
Projektrahmenhandlungen	Die im Rahmen der Entwicklung erstellten Artefakte werden an das Betreuerteam übermittelt.

Architektur- und Schichtenmodell der Anwendung

Nach oben

Überblick

Projektdokumentation