Institut für     praktische Informatik an der Leibniz Universität Hannover Institut für Praktische Informatik: Fachgebiet Software Engineering Leibniz Universität Hannover

Extension Points

Übersicht über extension points, die ProFLOW für eigene Erweiterungen zur Verfügung stellt.

Eine eigene Notation besteht aus einem Modell und aus der graphischen Repräsentation dieses Modells.

extension points für das Modell

Ein Modell aus verschiedenen Grundtypen bestehen:

  • einfache Elemente
    • werden miteinander durch Transitionen verbunden.
  • Transitionen
    • verbinden einfache Elemente untereinander
  • Container
    • können einfache Elemente enthalten, verhalten sich sonst wie einfache Elemente
  • Prozess
    • Wurzelcontainer für alle Elemente
  • Annotation
    • Kann an Transition oder Element angehängt werden.

Von jedem Grundtyp können mehrere eigene Typen definiert werden. Dazu muss eine

  • ID und eine
  • Java-Klasse

die den Typ definiert, angegeben werden. Diese Klasse muss eine Erweiterung der Klasse des Grundtyps sein. Folgend sind die extension points und die zugehörigen Grundklassen aufgelistet.

  • simpleElements
    • proFlow.core.model.SimpleElement
  • transitions
    • proFlow.core.model.Transition
  • containerElements
    • proFlow.core.model.ContainerElement
  • processes
    • proFlow.model.Process
  • annotations
    • proFlow.core.model.Annotation

extension points für die graphische Repräsentation

Für graphische repräsentation und Benutzerinteraktion müssen für eine Notation weitere extension points erweitert werden. Folgende Angaben sind nötig:

  • id - bezieht sich auf die ID, die für diesen Typ im Modell definiert wurde
  • name - Name des Elementes, taucht z.B. in der Palette auf.
  • description - Beschreibung des Elementes
  • icon - Icon des Elementes, z.B. für Paletteneintrag
  • editPart - EditPart-Klasse

Refactoring

Vorgehen (Stand: 25.10.2010)

Das Refactoring soll in folgenden Schritten durchgeführt werden:

  1. Umbenennen der Klassennamen von Elementen der FLOW-Notation (abgeschlossen #46)
  2. FLOW-Package als eigenes Plug-in extrahieren, umbenennen von basicFLOW zu FLOW
  3. Komponente "Simulation" von FLOW als eigenständiges Plug-In extrahieren, eventuell zusammen mit Schritt 2. (abgeschlossen #48)
  4. Das Kern-Modell umstrukturieren, Serialisierung der Elemente vereinfachen (z.B. mit XStream)
  5. Refactoring der Figure-Struktur

Refactoring von FLOW

  • (abgeschlossen #46) Umbenennung der Flow-Klassen und Korrektur des FLOW-Modells
    • Klassen sollen die Namen erhalten, die im Modell und Sprache verwendet werden
      • Beispiel: FlowBlock -> Activity
    • Das Präfix "Flow" soll entfernt werden, es ist aus der Packagestruktur schon ersichtlich
      • Beispiel: FlowInformationStorage -> InformationStore
  • Auslagerung des FLOW Modells als eigenes Plug-In in das Package proFLOW.BasicFLOW
    • Die Idee früher: FLOW bei allen Diagrammen mit dabei
    • Die Idee jetzt: minimales FLOW im eigenen Package, so dass komplett neue bzw. darauf aufbauende FLOW-Modelle möglich sind
  • (abgeschlossen #48) Auslagerung der Simulation in ein eigenes Plug-In (Im Diagramm nicht sichtbar, da es nicht zum FLOW-Modell gehört)
    • Momentan: Simulationselemente in den Modellklassen von FLOW integriert
    • In Zukunft: Simulation erweitert BasicFLOW als eigenes Plug-In

Refactoring der Kernklassen

  • Klasse ModelObject
    • Wie weit sollte man die Standard-Attribute wie Name, Typ-ID oder Dimension als Attribut registrieren?
  • Rund um die Klasse ContainerElement
    • Klasse ContainerElement enthält abstrakte Methode isCollapsable, wieso?
    • Klasse Process soll der Idee nach alle Elemente des Diagramms enthalten, deswegen Umbenennung von Process nach Diagram
    • Klasse SubProcess ist eine Erweiterung der Klasse ContainerElement um die Eigenschaft Collapsable, deswegen umbenennung in CollabsableContainer

  • Anchor-Klasse
    • erstmal aus dem flow-package rausnehmen, es gehört da nicht hin
    • Fragen zu klären:
      • wo wird die Klasse eingesetzt, wieso ist sie nötig?
      • Nur fürs Zeichnen des Einsprungpunktes?
      • Ist es ein Element oder ModelObject...oder weder noch?

Refactoring der Figure-Struktur

  • Die grundlegenden Figure-Klassen sind redundant aufgebaut, so gibt es drei Klassen, die ein Symbol mit einer Beschriftung implementieren:
    • LabeledRoundedRectangle
    • LabeledPolygon
    • LabeledFigure

Sie unterscheiden sich in der Form des Symbols (bei LabeledFigure kann man selbst ein Symbol erstellen) und in der Position der Beschriftung (im Symbol bzw. unter dem Symbol). Wünschenswert ist eine gemeinsame Klasse, die ein Symbol mit einer Beschriftung repräsentiert.

  • Information zum Aussehen der graphischen Elemente (z.B. Schriftart, Linienfarbe) ist redundant verteilt. Die Information sollte in einer Klasse oder einem Interface zusammengefasst werden.

  • Parallel zum Refactoring der Figure-Klassen sollten die EditPart-Klassen angeglichen werden

Modell von FLOW - Stand: Januar 2010

Aktuelles FLOW Modell als Klassendiagramm

Modell nach Schritt 1 (#46)

Refactoring des FLOW - Modells

Figure Klassenhierarchie - Stand: Oktober 2010

Attachments