diff options
Diffstat (limited to 'document.tex')
| -rw-r--r-- | document.tex | 176 |
1 files changed, 90 insertions, 86 deletions
diff --git a/document.tex b/document.tex index 35a7589..8aa76a0 100644 --- a/document.tex +++ b/document.tex @@ -1,7 +1,7 @@ % !TEX TS-program = pdflatex -shell-escape % !TEX encoding = UTF-8 Unicode \documentclass[%draft, -12pt,titlepage,abstracton,DIV=10]{scrreprt} +12pt,titlepage,abstracton,DIV=10,BCOR=0.5cm]{scrreprt} \usepackage[T1]{fontenc} \usepackage{ucs} \usepackage[utf8x]{inputenc} @@ -221,10 +221,10 @@ auszuliefern. aus der Eclipse Plattform kann auf aufwendige, fehleranfällige Eigenentwicklungen verzichtet werden. -\textbf{Bessere GUI\ } Für Benutzer von Eclipse wird das Arbeiten mit -Workspaces und Projekten in der Eclipse~Art bereits vertraut sein. Alle anderen -werden mit einem intuitiven Standard- --- weniger individuell-kreativen --- -Oberfläche konfrontiert. +\textbf{Bessere GUI\ } Für Benutzer von Eclipse wird das Arbeiten mit Workspaces +und Projekten beim Umgang mit KSM bereits vertraut sein. Alle anderen werden mit +einer intuitiven, Standard- --- weniger individuell-kreativen --- Oberfläche +konfrontiert. \textbf{Lizenzmanagement\ } KSM soll in naher Zukunft öffentlich verfügbar sein, QKSM nicht. Wäre QKSM ein Zusatzmodul (Bundle, Plugin) für KSM, dann @@ -267,7 +267,7 @@ In der Studienarbeit 1 wurde mit einem vereinfachten Datenmodell gearbeitet. Da zukünftig sowohl KSM/Swing als auch /RCP die gleichen Daten verarbeiten können sollten, liegt es nahe, dass das Format in dem die Daten persistent im -Dateisystem abgelegt sind vereinheitlicht werden sollte. +Dateisystem abgelegt sind, vereinheitlicht werden sollte. Im folgenden wird ausgeführt warum das aktuelle Datenformat in KSM/Swing nicht geeignet ist und wie ein neues entwickelt wurde. @@ -276,7 +276,7 @@ geeignet ist und wie ein neues entwickelt wurde. \begingroup \leftskip=1.5cm % ggf. verstellen \noindent In Anhang \ref{chapter:doku-datamodel} ist die vollständige Dokumentation des -neuen Datenformat zu finden dessen Entwicklung in diesem Kapitel beschrieben +neuen Datenformat zu finden, dessen Entwicklung in diesem Kapitel beschrieben wird. \par \endgroup @@ -306,7 +306,7 @@ Model-Objekte einfach mittels leicht annotierten JAXB serialisiert wurden <id>e36a0368-d8f6-40a2-bd29-375352045da8</id> <location> <x>531</x> - <y>104</y> + <y>104</y> </location> <nodeProperties/> </nodes> @@ -333,7 +333,7 @@ Speicherung erzeugte XML wieder. caption={Datenformat aus KSM/Swing Applikation Stand 22.02.2011}]{files/ksm-example.xml}\label{ksmswingdata} -Für das KSM/Swing Datenform existiert ein XML-Schema in der Ausarbeitung der +Für das KSM/Swing Datenformat existiert ein XML-Schema in der Ausarbeitung der Studienarbeit von Friedhelm Wolf \cite{wolf05} in Anhang 4. Es wurde aber in den folgenden Studienarbeiten nicht mehr weiter gepflegt und ist daher vermutlich nicht mehr gültig. @@ -346,19 +346,19 @@ Weiterhin scheinen die Konventionen beim Entwurf dieses Formates (oder ,,Schema'') eher beliebig gewesen zu sein. Dies fällt als erstes auf bei der Benennung der der Eigenschaftsnamen (Tags), wo \texttt{CamelCase} (,,Microsoft Stil''), \texttt{javaStilArt} und -underline\_stil wild gemischt werden. Die Benamung verwendet teils einen -Typ-Prefix (\texttt{sIconPath}), teils auch nicht. +\texttt{underline\_stil} wild gemischt werden. Die Benamung verwendet teils +einen Typ-Prefix (\texttt{sIconPath}), teils auch nicht. Die Ein- und Ausgabe erfolgt in KSM/Swing mithilfe der Java-Bibliothek -\textit{com.machinedialog}. Von Seiten der Projektbetreuung wurde geäußert, dass -es gewünscht ist diese alte Bibliothek nicht mehr weiter zu verwenden. Zu den +\textit{com.\-machine\-dialog}. Von Seiten der Projektbetreuung wurde geäußert, +dass es gewünscht ist diese alte Bibliothek nicht mehr weiter zu verwenden. Zu den genauen Gründen sei auf die Studienarbeit\,\oldstylenums{1} von Tobias Dreher verwiesen \cite[S. 24]{dreher10}. Die fehlende Dokumentation und der anscheinend unstrukturierte Entwurf sprachen ebenfalls gegen die Weiterverwendung dieses Datenformates. In Sicht zur Zukunft ist das Format ungeignet, weil es nicht erlaubt, dass -zusätzliche Eigenschaften rückwärtskompatibel abzubilden. +zusätzliche Eigenschaften rückwärtskompatibel abgebildet werden. Weiterhin ist es ist nicht (mehr) durch ein XML-Schema gestützt und es wurde im Laufe der Entwicklung mehrmals beliebig verändert. Es ist nicht dokumentiert und @@ -370,7 +370,7 @@ Wie an diesen beiden Beispielen zu sehen ist, bietet das XML-Format aus der Studienarbeit~1 nicht das Ausdrucksvermögen des KSM/Swing Format. Letzteres ist jedoch ungeeignet zur Nutzung in einer neuen KSM RCP-Applikation. -Daher lag es nahe ein Format zu entwerfen welche sowohl von KSM/Swing mithilfe +Daher lag es nahe ein Format zu entwerfen, welches sowohl von KSM/Swing mithilfe einer sauberen neuen Import/Export Infrastruktur als auch in der RCP-Anwendung genutzt werden kann. Es wurde hierbei ein Ansatz gewählt der sowohl Knoten, Gruppen von Knoten (auch bekannt als ,,Hirarchien'') als auch gerichtete @@ -378,18 +378,18 @@ Verbindungen zu einem anderen Knoten abbilden kann. Alle drei Objekte können durch Eigenschaften dynamisch, nicht schema-gebunden mit Informationen angereichert werden. -\par -\begingroup -\leftskip=1.5cm % ggf. verstellen -\noindent Die Implementierung des neuen Datenformat in \textbf{KSM/Swing} wurde -von Tobias Dreher vorgenommen. Siehe dazu seine Studienarbeit \cite{dreher11}. -\par -\endgroup +\par \begingroup \leftskip=1.5cm % ggf. verstellen +\noindent +Die Implementierung des Exports in das neue Datenformat in \textbf{KSM/Swing} +wurde von Tobias Dreher vorgenommen. Siehe dazu seine Studienarbeit +\cite{dreher11}. \par -Zu festen Standardisierung wurde ein XML-Schema erstellt woraus wiederum mittels -des XML-Schema-Compiler (xjc) von JAXB Java-Klassen erzeugt werden die mit -weiteren, handgeschrieben Klassen eine Bibliothek zur Abbildung von +\endgroup + +Zu festen Standardisierung wurde ein XML-Schema erstellt, woraus wiederum +mittels des XML-Schema-Compiler (xjc) von JAXB Java-Klassen erzeugt werden, die +mit weiteren, handgeschrieben Klassen eine Bibliothek zur Abbildung von KSM-Diagrammen im Speicher sowie Funktionen zum Laden und Speichern bietet (Abb. \ref{fig:class-diagram-xmlschema}). Diese kann sowohl von KSM/RCP als auch beliebigen Java-Anwendungen verwendet werden. @@ -402,9 +402,9 @@ Model-Klasse} \label{fig:class-diagram-xmlschema} \end{figure} -Die Datenmodell Bibliothek (Name \texttt{de.\-dhbw.\-horb.\-ksm.\-xmlschema}) -ist als Eclipse-Project angelegt kann jedoch auch nur mit Apache-Ant verwaltet -werden (ist somit Netbeans kompatibel). Das Projektverzeichnis enthält weiterhin +Die Datenmodell Bibliothek (Projektname: +\texttt{ksm-model}) ist als Eclipse-Project angelegt, kann jedoch auch nur mit +Apache-Ant verwaltet werden (ist somit Netbeans kompatibel). Das Projektverzeichnis enthält weiterhin umfassende Unit-Tests, teils im Beaviour-Driven Stil mithilfe der Bibliothek \textit{mockito}. @@ -458,20 +458,21 @@ Das \texttt{\ldots qksm}-Projekt ist als Eclipse-Projekt vom Typ ,,Plugin-Fragment'' abgelegt. Das bedeutet, es hängt direkt vom KSM-Core Plugin als Host-Plugin ab und ist kein eigenständiges (OSGi-)Bundle. Es wird wird beim Start mit dem Host-Plugin vereinigt. Diese vorgehensweise eignet sich um ein -Plugin ohne es zu verändern nachträglich um Features wie z.B. -Internationalisierung oder plattformabhängigen Code zu erweitern. +Plugin ohne es zu verändern nachträglich um Features, wie z.B. +Internationalisierung oder plattformabhängigen Code, zu erweitern. Ein Fragment Projekt unterscheidet sich von einem Plugin Projekt in weiteren -Punkten. Da es kein eigenständiges Bundle ist, besitzt keine Activator-Klasse. -Die Datei zur Beschreibung der Extensions heißt \texttt{fragment.xml} anstatt -\texttt{plugin.xml}. In \texttt{META-INF/MANIFEST.MF} wird daher kein Activator -deklariert - jedoch mit \texttt{Frag\-ment-Host} das zu erweiternde Plugin. +Punkten. Da es kein eigenständiges Bundle ist, besitzt es keine +Activator-Klasse. Die Datei zur Beschreibung der Extensions heißt +\texttt{fragment.xml} anstatt \texttt{plugin.xml}. In +\texttt{META-INF/MANIFEST.MF} wird daher kein Activator deklariert - jedoch mit +\texttt{Frag\-ment-Host} das zu erweiternde Plugin. Das \texttt{\ldots model} Projekt wurde durch den Eclipse Assistenten ,,Plug-In from existing JAR'' erstellt. Es enthält die \texttt{.class} Dateien aus dem JAR das im Projekt \texttt{ksm-model} durch ant erzeugt wird. Die zukünftige -aktualisierung kann einfach dadurch erfolgen, dass die Class-Files von Hand in -das \texttt{\ldots model} Projekt kopiert werden. Dadurch dass man auf diesen +Aktualisierung kann einfach dadurch erfolgen, dass die Class-Files von Hand in +das \texttt{\ldots model} Projekt kopiert werden. Dadurch dass man auf diesem Weg das \texttt{ksm-model} Projekt als OSGi Bundle zur Verfügung hat können KSM/RCP-erweiternde Plugin dieses einbinden. Alternativ wäre es möglich gewesen die \texttt{.jar}-Datei aus \texttt{ksm-model} in das \texttt{\ldots @@ -493,7 +494,7 @@ Einstiegspunkt in die Ausführung. Diese implementiert das Interface das grundlegende Aussehen mithilfe von Perspektiven und anhand einem \texttt{Work\-bench\-Window\-Advisor} steuert \cite{vogelrcp}. -In KSM/RCP ist im Kern-RCP Plugin die gesamte KSM-Editierfunktionalität +Im \texttt{\ldots ksm.core} Plugin ist die gesamte KSM-Editierfunktionalität enthalten. Dazu gehört der GEF-basierte Editor, das Outline und die Projektansicht. @@ -510,14 +511,15 @@ Projektansicht. Der mit dem Graphical Editing Framework (GEF) umgesetzte Editor ist teil des \texttt{\ldots ksm.\-core} Plugin-Projekt. GEF geht von einem existierenden Datenmodell aus welches hier durch das Plugin-Project \texttt{\ldots ksm.model} -anstelle von \texttt{ksm-model} zur Verfügung gestellt wird \cite{gef1}. +anstelle von \texttt{ksm-model} zur Verfügung gestellt wird. Bei der ,,Initialisierung'' eines GEF-Editors wird dem Editor eine Factory zugewiesen die für die Objekte/verschiedenen Typen des Datenmodells GEF-EditParts erzeugen kann -(\texttt{Diagram\-Editor\-\#configureGraphicalViewer} (Abb. \ref{fig:model}). +(\texttt{Diagram\-Editor\-\#configureGraphicalViewer}, Abb. \ref{fig:model}) +\cite{gef1}. -Anschliessend wird des Datenmodell zugewiesen +Anschliessend wird das Datenmodell zugewiesen (\texttt{DiagramEditor\-\#initialize\-Graph\-ical\-Viewer}). Der GEF-Editor ruft nun mit dem ,,Parent''-Objekt des Datenmodells die \texttt{Part\-Factory} auf und erhält das entsprechende EditPart. Der weitere Abstieg in der Hirarchie des @@ -556,8 +558,8 @@ Alle Manipulationen des Datenmodells werden durch sogenannte \texttt{Commands} beschrieben. Abbildung \ref{fig:commands} zeigt die Basisklasse und abgeleitete Klassen die Manipulationen des \texttt{Node}-Typ beschreiben. -Commands implentieren jeweils die Durchführung der Manipulation als auch das -Rückgängig machen. Durch GEF werden die Commands bei Anwendung auf einem Stack +Commands implementieren jeweils die Durchführung der Manipulation als auch das +rückgängig Machen. Durch GEF werden die Commands bei Anwendung auf einem Stack abgelegt wodurch das klassische Undo/Redo ermöglicht wird. Dieses Pattern verhindert weiterhin, dass das Datenmodell an beliebigen @@ -583,8 +585,9 @@ Das ,,Simulation'' Project \texttt{\ldots ksm.simulator} zeigt als Prototyp wie es möglich ist, Daten die im Editor bearbeitet werden live mit einem Chart auszuwerten. -Der Chart ist als View implementiert. Diese View besitzt für mehrere Zustände -für alle KSM-Editoren die geöffnet sind und wird entsprechend aktualisiert. +Der Chart ist als View implementiert. Die View besitzt mehrere +Zustände/Ansichten für alle KSM-Editoren die geöffnet sind und es wird immer die +zum aktuell fokussierten Editor passende dargestellt. Für den Linechart wird die Bibliothek SWT-Chart verwendet die dem Projekt beigelegt ist. Sie wird im OSGi-Manifest angegeben: @@ -609,11 +612,12 @@ des KSM-Nodes auf die Y-Achse auf und die KSM-Node-Beschriftung auf die X-Achse. \section{Property Editor} Damit ein Model für die Standard Eclipse-Properties-View nötigen Informationen bereitstellt muss eine \texttt{Prop\-erty\-Source} bereitgestellt werden. Dies geschieht im -einfachen Fall indem die Model-Klasse \texttt{IProp\-erty\-Source\-Provider} implementiert. +einfachen Fall indem die Model-Klasse \texttt{IProp\-erty\-Source\-Provider} +implementiert wird. Ist dies nicht der Fall fragt die Properties-View das \texttt{EditPart} über -\texttt{getAdapter\-(IProp\-erty\-Source\-Provider.class)} nach einem Objekt das -die Properties des Model beschreibt. Dieser Ansatz wurde gewählt, da die +\texttt{getAdapter\-(IProp\-erty\-Source\-Provider.class)} nach einem Objekt, +das die Properties des Model beschreibt. Dieser Ansatz wurde gewählt, da die Klassen des Models nicht angepasst werden konnten. Dies ist in einer Designschwäche der Model-Bibliothek begründet. Es ist noch nicht möglich eigene, abgeleitete Klassen für das Model zu verwenden. @@ -625,7 +629,7 @@ Klassen zur Verwaltung der Properties. \begin{figure}[mt] \centering -\includegraphics[width=0.7\textwidth]{images/ext-property-descriptors.PNG} +\includegraphics[width=0.5\textwidth]{images/ext-property-descriptors.PNG} \caption{Klassen des Extension Point für Property Deskriptoren} \label{fig:ext-property-descriptors} \end{figure} @@ -653,15 +657,15 @@ Extensions registriert wurden. Extensions sehen so aus, dass eine von \texttt{Abstract\-Property\-Descriptor\-Advisor} abgeleitete Klasse (im -Beispiel sind schon BaseNode[Group]PropertyAdvisor dargestellt die die +Beispiel sind schon BaseNode[Group]PropertyAdvisor dargestellt, die die Manipulation der grundlegenden Eigenschaften Farbe und Beschriftung erlauben) angegeben wird die Descriptoren für Eigenschaften des Model-Objekt erstellt. Abbildung \ref{fig:property-declaration-extensionpoint} zeigt wie der Extension Point deklariert wurde. Das gezeigte GUI ist eine Maske für eine XML-Datei die -im Prinzip ein XML-Schema für das XML ist mit dem der Extension-Point -genutzt werden kann. In diesem Fall können auf den Extension-Point beliebig -viele ,,advisor'' Elemente angelegt werden die auf eine von +im Prinzip ein XML-Schema für das XML ist mit dem der Extension-Point von +Client-Plugins konfiguriert wird. Auf diesen Extension-Point können beliebig +viele ,,advisor'' Elemente angelegt werden, die auf eine von \texttt{Abstract\-Property\-Descriptor\-Advisor} abgeleitete Klasse zeigen und ein Attribut \texttt{type} haben (Abb. \ref{fig:eclipse-property-usage-extensionpoint}). @@ -673,9 +677,8 @@ Funktionalitäten: [Editoren für] ,Edge Values' – Kanteneigenschaften [..] ,Node Values' – Knoteneigenschaften'' (Studienarbeit Christian Riess \cite[S. 24]{riess03}). -Im Rahmen dieser Studienarbeit wurde ein Table-Editor prototypisch entworfen -welcher Knoteneigenschaften manipulieren kann. Abbildung \ref{fig:table-editor} -zeigt die dabei eingeführten Neuigkeiten. +Abbildung \ref{fig:table-editor} zeigt den Table-Editor der im Rahmen dieser +Studienarbeit prototypisch entworfen wurde. \begin{figure}[ht] \centering @@ -685,18 +688,17 @@ zeigt die dabei eingeführten Neuigkeiten. \end{figure} Rot markiert ist die neue View des ,,Table-Editor''. Sie wird durch den Aufruf -der Table-Editor Perspektive aktiviert (Button ebenfalls rot markiert). +der Table-Editor Perspektive aktiviert (Button ist ebenfalls rot markiert). Bei der View handelt es sich \texttt{PageBookView}. Sie instanziert für jeden offenen Editor einen Table-Editor. Es wird jeweils der zu dem fokussierten Diagramm-Editor passende Table-Editor angezeigt. Die Implentierung folgt dabei dem Eclipse-Standard wie er auch in Outline verwendet wird. -Änderungen am Diagramm übernimmt der Table-Editor einfacherweise indem er auf -alle Node/NodeGroup Objekte listener registriert sondern er beobachtet den -Command-Stack des Editors. Dies funktioniert nur solange wie keine weiteren -Änderungen am Modell vorgenommen werden die kein Command im Diagramm-Editor -Command-Stack erzeugen. +Änderungen am Diagramm übernimmt der Table-Editor einfacherweise nicht indem er +auf alle Node/NodeGroup Objekte Listener registriert, sondern er beobachtet den +Command-Stack des Editors. Dies funktioniert nur solange alle weiteren +Änderungen am Modell Command-Objekte im Diagramm-Editor Command-Stack erzeugen. Der Table-Editor nutzt im Prototyp noch keine Undo-/Redo-Funktionalität sondern arbeitet ,,dreckig'' direkt am Datenmodell. @@ -713,7 +715,7 @@ werden. Weiterhin werden Vorschläge zur stärken Integration von Eclipse-Tools in das Studium aus der Sicht eines Studenten vorgestellt. -Es bei dieser Studienarbeit mit dem Eclipse \oldstylenums{3}.6 / Helios Package +Es bei dieser Studienarbeit mit dem Eclipse \oldstylenums{3}.6/Helios Package ,,for RCP and RAP Developers'' gearbeitet. \section{Hilfsmittel} @@ -740,10 +742,10 @@ Klassen ist meist sehr hilfreich. Zum Einstieg ist das RCP Tutorial von Lars Vogel empfehlenswert \cite{vogelrcp}. Zu den Grundlagen von GEF sind die Folien eines EclipseCon Tutorials interessant \cite{gefslides}. Tiefergehende jedoch teils veraltete Informationen bietet -das IBM Redbook zu diesem Thema \cite{gefredbook}. +das IBM RedBook zu GEF \cite{gefredbook}. Einen allgemeinen Überblick und guten Enstieg in die Eclipse Plugin Entwicklung -(weniger RCP) findet sich in der Seminararbeit im Kurs Software-Engineering +findet sich in der Seminararbeit im Kurs Software-Engineering 2011/\textsc{TIT2008} von Felix Kienzle \cite{kienzle11}. Da Eclipse~RCP kein monolithisches Produkt ist sondern sich aus einzelnen @@ -840,22 +842,24 @@ it2008 Jahrgang nicht mehr zugänglich. Die Veröffentlichung - bzw. eine sauber strukturierte Ablage - ist ein Baustein im Prozess der Zustand ändert. -In Hinblick auf eine Open-Source Entwicklung wird das private und sich als -unzuverlässig herausgestellte Subversion-Repository gegen ein Git-Repository -getauscht. Die Wahl für Git begründet sich durch die starke Präsenz im -Open-Source Bereich, besonders auch in Eclipse nahen Projekten und dadurch, dass -bereits im Kurs Software-Engineering mit Git gearbeitet wurde. Es wird die -ebenfalls im Studium bereits verwendete Plattform \texttt{github.com} verwendet. -Dort stehen weitere, integrierte Funktionen wie Messaging, Issue-Tracker und -Wiki zur Verfügung. Diese wurden jedoch im Rahmen dieses Projektes noch nicht -eingesetzt. +In Hinblick auf eine Open-Source Entwicklung wird SVN Repository an der +Hochschule, welches sich zeitweise als unzuverlässig herausstellte, gegen ein +Git-Repository getauscht. + +Die Wahl für Git begründet sich, neben der Abkehr von SVN aus allgemeinen +Gründen, gegenüber konkurrenzfähigen Versionskontrollsystemen durch die +starke Präsenz im Open-Source Bereich, besonders auch in Eclipse nahen Projekten +und dadurch, dass bereits im Kurs Software-Engineering mit Git gearbeitet wurde. +Es wird die ebenfalls im Studium bereits verwendete Plattform +\texttt{github.com} verwendet. Dort stehen weitere, integrierte Funktionen wie +Messaging, Issue-Tracker und Wiki zur Verfügung. Diese wurden jedoch im Rahmen +dieses Projektes noch nicht eingesetzt. Die Quellen des Eclipse basierten KSM/RCP werden unter dem Github Organization-Account \textit{dhbw-horb} -({\small\url{https://dhbw-horb.github.com}}) veröffentlicht bzw. hinterlegt -werden. Ebenso wird ein Verweis auf die KSM-Website hinterlegt. Zukünftige -Entwickler erhalten Zugriff, indem sie Mitglied dieses Organization-Account -werden. +({\small\url{https://dhbw-horb.github.com}}) veröffentlicht bzw. hinterlegt. +Ebenso wird ein Verweis auf die KSM-Website hinterlegt. Zukünftige Entwickler +erhalten Zugriff, indem sie Mitglied dieses Organization-Account werden. Zwar wird der Quellcode möglicherweise veröffentlicht - von Open-Source im Sinne der allgemeinen Bedeutung ist allerdings nicht zu sprechen, da keine Open-Source @@ -882,19 +886,19 @@ Prozessgrößen (QKSM) zu verwenden ohne die ,,Hauptapplikation'' verändern zu müssen was im schlimmstenfall wieder zu einer Zerspaltung der Projekte führen könnte. -Die grafische Darstellung von Hirarchien in KSM/RCP unterscheidet sich von der -Darstellung im Swing-basierten KSM. Meiner Ansicht erfordert das Thema +Die grafische Darstellung von Hirarchien in KSM/RCP unterscheidet sich optisch +von der Darstellung im Swing-basierten KSM. Meiner Ansicht erfordert das Thema \textit{Hirarchien} eine radikale Lösung z.B. durch die Ersetzung von Hirarchien durch ,,Tags'' mit denen Knoten gruppiert werden können. Probleme wie ,,Phantom -Knoten''\cite[S. 49]{pustelnik10} gibt es jedoch in KSM/RCP da die -Daten im Modell auch echt hirarchisch abgelegt sind. +Knoten''\cite[S. 49]{pustelnik10} gibt es jedoch in KSM/RCP da die Daten im +Modell auch echt hirarchisch abgelegt sind. Im Bereich des grafischen Editors könnte möglicherweise bald unter Verwendung -des Eclipse Graphiti Project welches auf GEF aufbaut einiges vereinfacht werden. -Weiterhin entfällt bei Beendung der KSM/Swing Entwicklung der Grund, das +des Eclipse Graphiti Project, welches auf GEF aufbaut, um einiges vereinfacht +werden. Weiterhin entfällt bei beendung der KSM/Swing Entwicklung der Grund, das Datenmodell unabhängig von Eclipse-Bibliotheken zu halten und das Datenmodell -könnte möglicherweise besser mit den Eclipse Modeling Werkzeugen erstellt -werden. +könnte einfacher und professioneller mit den Eclipse Modeling Werkzeugen +erstellt werden. %% Table-Editor Mit dem \emph{Table-Editor} Entwurf wurde gezeigt, dass die aus KSM/Swing @@ -913,7 +917,7 @@ des Simulierens ist nicht implementiert. In der \emph{Datenmodell} Library \texttt{ksm-model} sollte es möglich sein, Vererbung zu Nutzen um die Model-Klassen für den Einsatzbereich zu erweitern. Hierzu -müsste zur Instantierung neuer Model-Objekte jedoch ein Factory-Pattern +müsste zur Instanzierung neuer Model-Objekte ein Factory-Pattern eingesetzt werden was nicht der Fall ist. Auch in der Datenmodell Library wurde der Ansatz gewählt, dass sich auf alle |