Ein grafischer Editor mit Annotationsmöglichkeit für SPEM ... · Im Prinzip verfeinern Profile...

Gottfried Wilhelm

Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik

Institut für Praktische Informatik Fachgebiet Software Engineering

Ein grafischer Editor mit Annotationsmöglichkeit für SPEM-Modelle

Bachelorarbeit

im Studiengang Informatik

von

Andelko Jovancevic

Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr.-Ing. Christian Grimm

Betreuer: Dipl.-Math. Thomas Flohr

Hannover, 30. März 2007

Bachelorarbeit: Ein grafischer Editor mit Annotationsmöglichkeit für SPEM-Modelle

Erklärung

Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig und ohne fremde Hilfe verfasst habe. Es wurden keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet.

_____________________________________ Hannover, 30. März 2007 Andelko Jovancevic

1


Zusammenfassung

Seit dem man Softwareprozesse strukturierter und disziplinierter gestallten will, ist eine Wissenschaft geboren worden, die sich mit der Modellierung von Softwareprozessen beschäftigt. Inzwischen existieren viele verschiedene Sprachen, die man verwenden kann, um Softwareprozesse zu beschreiben. SPEM ist der Versuch der OMG eine Sprache als Standard einzuführen. Da SPEM ein UML Profil ist und UML schon als Standard zur Beschreibung von Systemen angesehen werden kann, kann jeder Softwareprozessentwickler der UML versteht auch SPEM verstehen. Ich habe SPEM am Beispiel des Softwareprojektes benutzt, um dessen Prozess zu beschreiben. Dieses Beispiel kann man lesen und verstehen, wenn man UML Erfahrungen hat. Deswegen kann man gespannt sein, ob sich SPEM als Standard zur Beschreibung von Prozessen durchsetzen wird. In dieser Bachelorarbeit wurde ein Editor entwickelt, mit dem man Klassendiagramme, Aktivitätsdiagramme und Use Case Diagramme nach der Prozessmodellierungssprache SPEM modellieren kann. Ein wesentlicher Bestandteil meiner Bachelorarbeit war es, ein Bewertungsmodell für Prozesse und deren Elemente zu entwickelt. Dies dient natürlich der Verbesserung von Prozessen. Mit Hilfe eines Szenarios werde ich später darauf genauer eingehen.

2


Inhaltsverzeichnis

1 Einleitung ...........................................................................................................................4 1.1 Hintergrund ................................................................................................................4 1.2 Aufgabe......................................................................................................................4 1.3 Gliederung..................................................................................................................5 2 SPEM ................................................................................................................................6 2.1 SPEM Einleitung....................................................................................................6 2.1.1 MOF (Meta Object Facility).............................................................................6 2.1.2 Motivation ........................................................................................................7 2.2 SPEM Foundation .................................................................................................8 2.2.1 SPEM_Foundation::Core Paket........................................................................8 2.2.2 SPEM_Foundation::Action Paket.....................................................................11 2.2.3 SPEM_Foundation::StateMachine Paket .........................................................12 2.2.4 SPEM_Foundation::Activity_Graphs Paket.....................................................12 2.3 SPEM Stereotypbeschreibung...............................................................................13 2.4 Diagrammtypen .....................................................................................................20 2.4.1 Klassendiagramm .............................................................................................21 2.4.2 Paketdiagramm .................................................................................................22 2.4.3 Use Case Diagramm .........................................................................................22 2.4.4 Aktivitätsdiagramm ..........................................................................................23 2.5 Wohlgeformte Regeln ............................................................................................23 3 Editor ..................................................................................................................................26 3.1 SPEM Umsetzung .................................................................................................26 3.1.1 Eclipse ..............................................................................................................26 3.1.2 Graphical Editing Framework und ProFlow ....................................................27 3.1.3 Was nicht mit ProFlow umsetzbar war.............................................................27 3.1.4 Wohlgeformte Regeln im Editor .......................................................................27 3.2 Annotation um zu bewerten und um Erfahrung zu speichern ...............................30 3.2.1 Konzept einer Skala..........................................................................................31 3.2.2 Konzept der Annotation mit Dialogfeld ...........................................................31 3.2.3 Zweck der Bewertung.......................................................................................35 3.3 Softwareprojekt als Beispiel für einen Prozess .....................................................36 3.3.1 Aktivitätsdiagramm ..........................................................................................37 3.3.2 Use Case Diagramm .........................................................................................38 3.3.3 Klassendiagramm .............................................................................................39 4 Bedienungsanleitung .........................................................................................................40 4.1 Installation .............................................................................................................40 4.2 Benutzung..............................................................................................................41 5 Glossar ................................................................................................................................45 6 Quellenangaben .................................................................................................................46

3


1 Einleitung

1.1 Hintergrund

Es existiert eine Vielzahl von verschiedenen Modellierungssprachen, mit denen Softwareprozesse dargestellt werden können. Das Software Process Engineering Metamodel (kurz: SPEM) ist eine solche Sprache zur Modellierung von Softwareprozessen. SPEM wurde von der Object Management Group (OMG) zusammen mit Industrieunternehmen entwickelt und gilt daher als viel versprechender Standard zur Modellierung von Softwareprozessen. Leider existieren keine uns bekannten grafischen Editoren, um SPEM-Modelle zu erzeugen.

1.2 Aufgabe

Im Rahmen dieser Bachelorarbeit soll ein grafischer Editor entwickelt werden, mit dessen Hilfe Prozessmanager SPEM basierende Softwareprozessmodelle erstellen können. Dabei bildet die SPEM Spezifikation 1.4 die Grundlage aller im Editor zu implementierenden Modellierungsrichtlinien. Da Prozesse in aller Regel nicht perfekt sind, ist es sinnvoll, Prozessteilnehmern die Möglichkeit einzuräumen, Prozesselemente (Rolle, Aktivitäten, Artefakte etc.) bewerten zu können. Ein Wesentlicher Teil dieser Bachelorarbeit ist es ein Konzept für ein Bewertungsmodell zu entwickeln. Dies kann in Form von Annotationen erfolgen, welche direkt an die Prozesselemente geknüpft werden können. Ein Teil der Arbeit besteht darin, zu überlegen welches Bewertungsmodell das Beste dafür ist und dieses in den Editor zu integrieren. Die Modellierungsmöglichkeiten sollen durch das Beispiel des Softwareprojekts des Fachgebiets Software Engineering aufgezeigt werden. Technisch betrachtet soll der Editor als Eclipse-Plugin implementiert werden. Dabei soll explizit das ProFLOW-Plugin des Fachgebiets Software Engineering als Basis dienen. Weiterhin muss eine Exportmöglichkeit implementiert werden, welche den Export der Modelle in mindestens ein übliches skalierbares Grafikformat erlaubt (z.B. wmf oder svg). Auf SPEM basierende Modelle müssen als XML abspeicherbar sein. Für die Arbeit ist es ebenfalls nötig, eine 40- bis 50-seitige Ausarbeitung zu erstellen, welche die Umsetzung des SPEM-Modells in den Editor beschreibt und ebenfalls auf das Bewertungsmodell eingeht.

4


1.3 Gliederung

In Kapitel 1 werden die Aufgabenstellung und die daraus resultierenden Anforderungen beschrieben. In Kapitel 2 beschreibe ich die Prozessmodellierungssprache SPEM ausführlich. Erst beschreibe ich allgemein den Aufbau (SPEM Foundation), dann die wichtigsten SPEM Modellelemente, dann die Diagrammtypen und zuletzt die wohlgeformten Regeln. In Kapitel 3 geht es dann um das fertiggestellte Produkt dieser Bachelorarbeit. Hier gehe ich erst auf die Umsetzung der Prozessmodellierungssprache SPEM zu einem Editor ein. Des Weiteren gehe ich in diesem Kapitel genauer auf das Bewertungsmodell ein. Die Konzepte, die hierfür notwendig waren, werden ausführlich beschrieben. Weitergehend werde ich beschreiben, wie, wann, wo und mit wem man diese Bewertungen veranstalten sollte. Die Frage, wieso man Prozesse und deren Prozesselemente überhaupt bewerten soll wird hier auch erläutert. Zuletzt wird anhand des Softwareprojekts des Fachgebiets Software Engineering der fertiggestellte Editor demonstriert. Kapitel 4 enthält die Bedienungsanleitung für den entwickelten Editor. Diese hier beschriebene Bedienungsanleitung stammt größtenteils aus der Bedienungsanleitung für den ProFlow von Andreas Meißner. Da die von mir umgesetzten Diagramme auf der Basis von ProFlow arbeiten, ist die Bedienung bis auf ein paar kleine Änderungen, die ich hier übernommen habe, gleich. Das Kapitel 5 ist das Glossar. Im Glossar beschriebene Begriffe sind kursiv dargestellt. Im Kapitel 6 werden die Quellenangaben angegeben.

5


2 SPEM

2.1 SPEM Einleitung

Ein Standard zur Beschreibung von Software Prozessen ist das von der Object Management Group (OMG) entwickelte SPEM (Software Prozess Engineering Metamodel). Dabei handelt es sich in erster Linie um ein Metamodell, mit dessen Hilfe konkrete Softwareentwicklungsprozesse dargestellt werden können. Dabei wird das von SPEM beinhaltete Metamodell zur Definition von Prozessen und deren Komponenten eingesetzt. Der SPEM Ansatz ist ein objektorientierter Ansatz zur Modellierung von Softwareprozessen und verwendet die UML als Basisnotation. Dabei wird ähnlich zur UML ein 4-Schichten-Konzept zur Modellierung eingesetzt, wie es die Abbildung 1 veranschaulicht.

Abbildung 1: 4-Schichten-Konzept aus der SPEM Spezifikation 1.1 [SPEM]

In diesem Modell wird ein tatsächlicher Prozess auf der Ebene M0 ausgeführt. Während seine Definition auf Ebene M1 stattfindet. Entsprechend der Metaebenenarchitektur bei MOF wird dann das Prozessmodell wiederum auf Ebene M2 modelliert usw. Wir konzentrieren uns hier auf das Metamodell, das sich in der Ebene M2 befindet und als eine Dokumentvorlage für Level M1 dient.

2.1.1 MOF (Meta Object Facility)

MOF (Meta Object Facility) ist ein OMG-Standard, der eine gemeinsame und abstrakte Sprache für die Spezifikation von Metamodellen anbietet. MOF ist also ein Beispiel für ein Meta-Metamodell (eine Art Beschreibung eines Metamodells). MOF hat seine Stärken im Austausch von Metadaten und in der Interoperabilität von Metamodellen. Angewendet wird eine Teilmenge von UML für die Modellierung und ein Teil von IDL (Interface Definition Language) zur Anwendung in Applikationen. Modelle, die beschreiben, wie Modelle gebaut werden, nennt man Metamodelle. Die SPEM Spezifikation Version 1.1, die im Januar 2005 von der OMG veröffentlicht wurde, ist strukturiert als ein UML Profil und liefert ein komplettes MOF-basiertes Metamodel.

6


Im Prinzip verfeinern Profile nur die Standardsemantik der UML, indem sie weitere Beschränkungen und Interpretationen hinzufügen. SPEM ist der Softwareprozess-modellierung gewidmet, so dass viele Besonderheiten der UML, die erforderliche Basis Liefern, um Prozesse zu modellieren und viele andere UML-Fertigkeiten liefern nützliche zusätzliche Entwurfskapazitäten. Der Kerngedanke des SPEM ist die Idee, dass ein Softwareentwicklungsprozess ein Zusammenspiel zwischen abstrakten und aktiven Elementen ist. Prozessrollen führen Tätigkeiten aus, die Activities (Aktivitäten) genannt werden. Jede Prozessrolle kann zudem für mehrere Arbeitsprodukte zuständig sein und Arbeitsprodukte können Eingaben und Ausgaben für die Activities (Aktivitäten) sein. Das Diagramm in Abbildung 2 veranschaulicht diesen Kerngedanken.

Abbildung 2: Kerngedanke aus der SPEM Spezifikation 1.1 [SPEM]

2.1.2 Motivation

Die Geburt des Unified-Prozess und der UML hat in den späten 90ern eine fundamentale Veränderung in der Softwareentwicklungsindustrie bewirkt. Es wurden Varianten der Unified-Prozesse in der Industrie-Anwendung benutzt, um die Prozesse disziplinierter und strukturierter zu gestalten. Prozesse waren selbst wie Produkte und veränderten und entwickelten sich ständig. Sie mussten geführt und gestaltet werden, um sie an die Organisations-Wechsel-Bedürfnisse und an die Umgebung anzupassen. Der Bedarf an Prozessmodellierungstechniken und Technologien war aufgetaucht. Mit der Zeit existierte eine Vielzahl von verschiedenen Prozessmodellierungssprachen, die alle verschiedene Bezeichnungsweisen oder eine andere Bedeutung für dasselbe Wort oder denselben Ausdruck verwendeten. In Erkenntnis dieses Bedarfs hat die OMG die SPEM Spezifikation definiert und herausgegeben. Da SPEM eine Untermenge von UML grafischer Notation verwendet und eine breite Gemeinde von Softwareentwicklern mit UML vertraut sind, fällt es den Entwicklern, die sich mit anderen Prozessmodellierungssprachen auskennen, nicht schwer, mit SPEM Prozesse zu modellieren. Das Definieren eines UML Profils erlaubt es dieser Gemeinde ihre Fachkenntnisse und Tools in der Softwareprozess-Modellierungs-Domäne wieder zu verwenden.

7


Der Unterschied zwischen UML und SPEM ist, dass UML ein Industriestandard für eine Modellierungssprache (Notation) von Systemen ist. SPEM dagegen ist ein Industriestandard für eine Modellierungssprache von Prozessen. SPEM beschreibt nicht, wie die Planung oder die Durchführung eines Prozesses auszusehen hat. Dafür gibt es genügend andere Projektvorgehensmodelle (z.B.: V-Modell XT (VXT)). Jedoch ist es die primere Aufgabe beider Standards (UML / SPEM), den Austausch von Prozessen und Systemen möglichst einfach zu halten, so dass jeder, der Wissen über UML / SPEM besitzt, diese auch lesen kann.

Grob gesprochen lässt sich SPEM in der Version 1.1 im Verhältnis zur UML folgendermaßen charakterisieren:

• SPEM ist eine definierte Teilmenge der Klassen des UML 1.4 Meta-Modells.

• SPEM definiert spezielle zusätzliche Bedingungen.

• SPEM definiert spezielle Stereotype, welche durch grafische Symbole repräsentiert werden.

Als UML-Profil erbt SPEM bereits die grundlegenden Konzepte wie die Vererbungsbeziehung, Abhängigkeiten und Assoziationen zwischen Modellelementen. Er spart sich jedoch auch Konzepte wie beispielsweise Interfaces und n-fache Beziehungen. SPEM bietet vergleichbare Diagrammtypen wie die UML selbst an, wobei nur sechs wirklich sinnvoll für die Domäne der Softwareentwicklungsprozesse sind

2.2 SPEM Foundation

Die UML Untermenge heißt SPEM Foundation. Die Foundation, die die fundamentale Grundarchitektur von SPEM ist, besteht hauptsächlich aus dem SPEM_Foundation::Core Paket, SPEM_Foundation::Action Paket und SPEM_Foundation::StateMachine Paket.

2.2.1 SPEM_Foundation::Core Paket

Das SPEM_Foundation::Core Paket ist ähnlich strukturiert, wie das UML 1.4 Core Paket.

8

http://de.wikipedia.org/wiki/V-Modell_XT


Die folgende Abbildung 3 zeigt die Modellelemente, die das strukturelle Rückgrat des Metamodells formieren.

Abbildung 3: strukturelles Rückgrat des Metamodells aus der SPEM Spezifikation 1.1 [SPEM]

Die folgende Abbildung 4 zeigt, wie die Modellelemente in Beziehung zueinander stehen.

Abbildung 4: Beziehungsmodell aus der SPEM Spezifikation 1.1 [SPEM]

9


Die folgende Abbildung 5 zeigt, wie die Modellelemente Dependencies (Abhängigkeiten) definieren.

Abbildung 5: Abhänigkeitsmodell aus der SPEM Spezifikation 1.1 [SPEM]

Die folgende Abbildung 6 zeigt, wie die Modellelemente die auxiliary Elements (Hilfs-Elemente) definieren.

Abbildung 6: aus der SPEM Spezifikation 1.1 [SPEM]

In jedem Kasten, jeder Klasse und jeder Assoziation wurde von dem UML 1.4 Metamodel etwas weggelassen. Was übergeblieben ist, sind die Teile der UML 1.4 Definition, die erforderlich sind, um SPEM Modelle zu definieren. Diese Teile sind exakt definiert, wie in

10


UML 1.4 Abschnitt 2.5, außer dass einige dieser Klassen abstrakt definiert sind. Dort sind folgende drei kleine Variationen:

• Bei AssociationEnd sind die Verbindungen zwischen Association und AssociationEnd mit der Kardinalität 2 und nicht wie in UML mit 2…*. Dies gilt, weil nur binäre Verbindungen von der SPEM unterstützt werden.

• Bei Dependencies (Abhängigkeiten) enden die Quell-und Zielverbindungen zwischen Dependency (Abhängigkeit) und Modellelementen mit der Kardinalität 1 und nicht wie bei UML 1…*. Dies gilt, weil nur binäre Dependency (Abhängigkeit) von der SPEM unterstützt wird.

• SPEM Assoziationen sind nicht generalisierbar.

2.2.2 SPEM_Foundation::Action Paket

Das SPEM_Foundation::Action Paket ist eine Untermenge des UML 1.4 Common_Behavior Pakets und ist in der folgenden Abbildung 7 gezeigt. Die Elemente in diesem Paket sind definiert wie in UML 1.4 Part 2.9.

Abbildung 7: SPEM_Foundation::Action Paket aus der SPEM Spezifikation 1.1 [SPEM]

11


2.2.3 SPEM_Foundation::StateMachine Paket

Das Spem_Foundation::State_Machines Paket ist eine Untermenge des UML 1.4 State_Machines Pakets und ist in der folgenden Abbildung 8 gezeigt. Die Elemente in diesem Paket sind wie in UML 1.4 Abschnitt 2.12 definiert, mit der Ausnahme, dass der Kontext einer State_Machine eher eine Komposition als eine geteilte Gruppierung ist.

Abbildung 8: Spem_Foundation::State_Machines Paket aus der SPEM Spezifikation 1.1 [SPEM]

2.2.4 SPEM_Foudation::Activity_Graphs Paket

Das Spem_Foundation::Activity_Graphs Paket ist eine Untermenge des UML 1.4 Activity_Graphs Pakets und ist in der folgenden Abbildung 9 gezeigt. Die Elemente in diesem Paket sind wie in UML 1.4 Abschnitt 2.13 definier

12


Abbildung 9: Spem_Foundation::Activity_Graphs Paket aus der SPEM Spezifikation 1.1 [SPEM]

2.3 SPEM Stereotypbeschreibung

Das SPEM Metamodel enthält die folgenden Stereotype die ich im Folgenden ausführlich mit ihren Funktionalitäten beschreiben werde. Dabei ist zu beachten, dass in SPEM nicht jeder Stereotyp ein Notationssymbol besitzt. Außerdem werde ich auf die verschiedenen Diagrammtypen eingehen und zuletzt noch die wohlgeformten Regeln erläutern.

• Basiselement:

o ExternalDescription (externe Beschreibung)

o Guidance

• Dependencies (Abhängigkeiten):

o Categorizes

o Impacts

o Import

o Precedes

o RefersTo

o Trace

• Prozess Struktur:

o WorkDefinition (Arbeitsbeschreibung)

13


o WorkProduct (Arbeitsprodukt)

o Activity (Aktivität)

o Step (Schritt)

o ProcessRole (Prozessrolle)

• Prozesskomponenten:

o Package (Pakete)

o ProzessComponent

o Prozess

o Discipline

• Prozesskreisläufe:

o Lifecycle

o Phase

o Iteration

o Precondition (Vorbedingung)

o Goal (Ziel)

ExternalDescription (externe Beschreibung)

Mit jedem Modellelement ist eine oder sind mehrere externe Beschreibungen verbunden, die eine Beschreibung der Modellelemente enthält. Externe Beschreibungen beinhalten auch die Benutzersichtbare Schnittstelle der Prozessbeschreibung.

Eine externe Beschreibung hat vier Attribute von Typ „String“:

• Content: eine natürliche Sprachbeschreibung der Modellelemente

• Name: Der Name der Modellelemente ist eine natürliche Sprache

• Language: Der Name der natürlichen Sprache wurde benutzt für das Nutzen des Inhalts und des Namens

• Medium: Eine Beschreibung des Mediums und ein Format der externe Beschreibung

Guidance

Guidance Elemente können mit Modellelementen assoziiert werden, um den Anwendern detailliertere Informationen über die assoziierten Modelelemente, zu liefern. Guidance sind keine WorkProducts (Arbeitsprodukte), sie werden weder im Prozess bearbeitet noch entworfen.

Mögliche Typen der Guidance richten sich an die Prozessfamilie und können zum Beispiel sein:

• Guideline

• Technique

• Metric

• Example

14


• UML Profiles

• Tool Mentors

• Checklist

• Templates

Guidance geben detaillierte Informationen über die Modelelemente, die im GuidanceKind weiter spezialisiert werden. Jede Guidance ist assoziiert mit einer GuidanceKind und der Name der GuidanceKind zeigt an, welche Art von Guidance es ist.

Arten von Guidance

1. Technique ist eine Art Anleitung. Eine Technique ist ein ausführlicher genauer Algorithmus, der benutzt wird, um ein Arbeitsprodukt zu entwerfen. Technique hilft, um die Fertigkeiten zu definieren, die erforderlich sind, um gezielte Typen der Activities (Aktivitäten) auszuführen. Der offene Prozess benutzt die Bezeichnung „Technique“. Andere Prozesse benutzten „Procedure“ oder „Derectiv“. 2. UML Profile ist eine Art Anleitung. Ein UML Profil liefert Mechanismen, die UML für eine spezielle Vorgabe wie C++, Java und CORBA oder für eine besondere Absicht wie Analysis, Design, usw. spezialisieren. Jede Entwicklungsaktivität, die UML benutzt, kann durch Profile geregelt werden. Diese Profile diktieren Beschaffenheitsregeln, die angewendet werden müssen oder die angeben, welches UML Modell für den derzeitigen Zusammenhang und Konzentration der Aktivitäten relevant ist. 3. Checklist ist eine Art Anleitung. Eine Checkliste ist ein Dokument, das eine Liste der Elemente repräsentiert, die erfüllt werden müssen. 4. ToolMentor ist eine Art Anleitung. Ein ToolMentor zeigt, wie ein spezielles Tool zu benutzen ist, um eine Aktivität durchzuführen. Jeder ToolMentor ist verbunden mit einem einzelnen Tool und erbt die Verbindungen mit der Aktivität, die er unterstützt von der Guidance. 5. Guideline ist eine Art Anleitung. Eine Guideline ist eine Reihe von Regeln und Empfehlungen, die festlegen wie ein bestimmtes Arbeitsprodukt aussehen muss oder organisiert sein muss. 6. Template ist eine Art Anleitung. Ein Template ist ein festgelegtes Dokument, das ein standardisiertes Format für bestimmte Teile der WorkProducts (Arbeitsprodukte) liefert: z.B. „Microsoft Word Template für Business UseCase Modellierung“.

15


Dependencies (Abhängigkeiten)

Die folgende Abbildung 10 zeigt, die in SPEM definierten Abhängigkeiten.

Abbildung 10: Dependencies aus der SPEM Spezifikation 1.1 [SPEM]

Die folgenden Abhängigkeiten werden von der SPEM für Prozessengineering unterstützt. 1. Categorizes Eine Categorizes-Abhängigkeit agiert von einem Paket individuellen Prozesselement zu einem anderen und liefert Hilfsmittel, um Prozesselemente mit verschiedenen Kategorien zu vereinigen. Diese Eigenschaft ist allgemeinen nützlich und fungiert insbesondere in Verbindung mit Discipline(Disziplinen), um eine erste Kategorisierung aller Elemente zur Verfügung zu stellen.

2. Impacts Eine Impacts-Abhängigkeit agiert von einem Arbeitsprodukt zu einem anderen Arbeitsprodukt, um anzudeuten, dass die Modifikation eines Arbeitsprodukts ein anderes entkräften könnte. 3. Import Eine Import-Abhängigkeit bezeichnet, dass der Inhalt des Zielpakets dem Namensraum des Quellpakets hinzugefügt wird. Dieses hat die gleiche Semantik wie der UML Import, außer dass in SPEM alle Elemente public Sichtbarkeit haben.

4. Precedes Eine Precedes-Abhängigkeit agiert von einer Aktivität zu einer anderen oder von einer WorkDefinition (Arbeitsbeschreibung) zu einer anderen, um anzudeuten, ob es eine Ende-Start oder Ende-Ende Abhängigkeit zwischen der beschriebenen Arbeit ist, abhängig von dem Wert des Teilattributes.

16


5. RefersTo Eine RefersTo-Abhängigkeit fungiert von einem Prozesselement zu einem anderen, um sicherzustellen, dass sie in der gleichen Prozesskomponente eingebunden sind. Die allgemeine Situation, wo dies verwendet wird, ist dort, wo der Text eines Prozesselements, durch den Namen oder Inhalt, zu einem anderem Element verweist. Um die Konsistenz der Bedeutung des Textes abzusichern, sollte eine RefersTo-Abhängigkeit etabliert sein, um eine explizite strukturelle Repräsentation derartiger Abhängigkeit anzugeben. Wenn das bezügliche Element in einem ProzessComponent (Prozesskomponenten) eingebunden ist, so muss auch der Bezug zum Element eingebunden sein. 6. Trace Eine Trace-Abhängigkeit agiert zwischen 2 Modellelementen irgendeiner Art und wird hauptsächlich benutzt, um Anforderungen und Auswechslung zwischen Modellen aufzuzeichnen. Es hat dieselbe Semantik wie ein UML Trace.

WorkProduct (Arbeitsprodukt)

Ein Arbeitsprodukt ist etwas Produziertes, Konsumiertes oder Modifiziertes durch einen Prozess. Es könnte ein Art Information, ein Dokument, ein Model, Source Code usw. sein. Ein WorkProduct beschreibt eine Klasse von Arbeitsprodukten, die in einem Prozess produziert sind. Ein Arbeitsprodukt ist eine Spezialisierung der Classifier. Dadurch können sie in Verbindungen teilnehmen und enthalten verschachtelte Definitionen. Sie können jedoch keine Merkmale besitzen. Ein Arbeitsprodukt kann mit einer zuständigen Rolle assoziiert sein, um die Rolle so darzustellen, als wäre sie formell verantwortlich für die Produktion des Arbeitsproduktes. Ein Arbeitsprodukt kann mit einer StateMaschine assoziiert sein, die die Zustände beschreibt. Ein Arbeitsprodukt muss mit einem WorkProductKind assoziiert sein. Ein WorkProductKind beschreibt eine Kategorie des Arbeitsprodukts wie Text, Dokument, UML Model, Executable, Code Libery usw. Ferner kann definiert werden, ob ein Arbeitsprodukt ein vereinbarter Ergebnistyp ist (isDeliverable). Das isdeliverable Attribut auf dem Arbeitsprodukt ist zutreffend, wenn dieses Arbeitsprodukt als formell lieferbar definiert wird. Deliverable ist nicht ein Hauptmodell-Element in SPEM, weil nicht alle Arbeitsprodukte lieferbar sind und ob ein Arbeitsprodukt lieferbar ist oder nicht, kann sich im Verlauf ändern.

WorkDefinition (Arbeitsbeschreibung)

Eine Arbeitsbeschreibung ist eine Art Arbeitsablauf, der die Tätigkeiten, die in einem Prozess durchgeführt werden, beschreibt. Ihre Hauptunterklasse ist die Aktivitäts-Klasse, aber auch, Phase, Iteration und Lifecycle, sind ebenfalls Unterklassen der Arbeitsbeschreibung. Arbeitsbeschreibung ist keine abstrakte Klasse und Instanzen der Arbeitsbeschreibung selbst können erzeugt werden, um zusammengesetzte Arbeitsteile, die weiter zerlegt sind, zu repräsentieren. Sie hat explizite Inputs und Outputs, die per ActivityParameter (Aktivitäts- Parameter) zugewiesen werden.

Abbildung 11: WorkDefinition aus der SPEM Spezifikation 1.1 [SPEM]

17


Eine Arbeitsbeschreibung kann aus anderen Arbeitsbeschreibungen durch die Verwendung von Verbindungen genannt subwork, bestehen. Die Aufspaltung kann mit einem Aktivitätsdiagramm modelliert werden. In so einem Fall wird die subwork-Assoziation von der Aktivitätsdiagrammstruktur abgeleitet. Eine Arbeitsbeschreibung hängt mit dem Arbeitsprodukt zusammen, das es durch die AktivityPrameter-Class (Aktivitäts-Parameter-Klasee) verwendet, die festlegt ob sie als Input oder Output verwendet wurden. Die Arbeit, die in der Arbeitsbeschreibung beschrieben wird, benutzt die Input Arbeitsprodukte und erzeugt oder aktualisiert die Output Arbeitsprodukte. Eine Arbeitsbeschreibung hat einen besitzenden ProcessPerformer (Prozessbearbeiter) und stellt die Primärrolle dar, die diese Arbeitsbeschreibung im Prozess durchführt. Im Falle der Aktivitäten, die von einem Einzelnen oder von einer kleinen Gruppe durchgeführt werden, ist dies eine Prozessrolle und im Falle hochgradiger Arbeitsbeschreibungen ist dies häufig eine einzige Instanz der ProcessPerformer, die dem kompletten Prozess entspricht. Auf eine Arbeitsbeschreibung kann durch ein AktionState in einem Aktivitätsdiagramm Bezug genommen werden. Das Attribut „kind“ auf Parametern wird verwendet, um anzuzeigen ob das assoziierte Arbeitsprodukt ein Input, Output, ein modifizierbarer Input oder ein Rückgabewert für die Arbeitsbeschreibung ist. Das Attribut „hasworkPerArtifact“ bedeutet, dass mehrfache Instanzen der Arbeitsbeschreibung gebraucht werden, eine pro Instanz des entsprechenden Arbeitsprodukts.

Step und Activity (Aktivität)

Aktivität ist die Hauptunterklasse der Arbeitsbeschreibung. Sie beschreibt einen Teil der Arbeit, die von einer Prozessrolle durchgeführt wird, die Aufgaben, Tätigkeiten und Aktionen, die von einer Rolle durchgeführt werden oder durch die die Rolle unterstützt wird. Eine Aktivität kann aus den atomaren Elementen, die Steps genannt werden, bestehen. Aktivität erbt von der Arbeitsbeschreibung die Tatsache, dass die Input- und Outputparameter vom Typ Arbeitsprodukt hat. Eine Aktivität wird von einer Prozessrolle besessen, die der Ausführende der beschriebenen Aktivität ist. Sie kann sich auf zusätzliche Prozessrollen beziehen, die die Assistenten in der Aktivität sind. Obwohl das nicht explizit untersagt ist, benutzt eine Aktivität normalerweise nicht die von der Arbeitsbeschreibung geerbte subwork Struktur. Stattdessen wird die Aufspaltung innerhalb der Aktivität durch die Verwendung von Steps erzeugt. Ein Step ist im Zusammenhang der umfassenden Aktivität, in Bezug auf die Prozessrolle und Arbeitsbeschreibung, die er verwendet beschrieben. Ein Step erbt vom ActionState so, dass der Ablauf der Steps innerhalb einer Aktivität durch ein Aktivitätsdiagramm dargestellt werden kann.

18


Abbildung 12: aus der SPEM Spezifikation 1.1 [SPEM]

Packages (Pakete)

Wie in UML sind Pakete in SPEM Container, die Prozessdefinitionen importieren. Aktivitäten und Arbeitsbeschreibung werden von Prozessrollen und ProcessPerformer besessen; StateMachines werden von Arbeitsprodukten besessen und besitzen ihre internen Zustände und Übergänge; Aktivitätsdiagramme können in Pakete, Classifier oder BehavioralFeatures enthalten sein; andere SPEM Modelelemente können in Paketen enthalten sein. Paketen und die Categorizes Abhängigkeiten können verwendet werden, um allgemeine Kategorien von Prozessbeschreibungselementen einzuführen. Ein Paket wird erstellt, um jede Kategorie darzustellen, und alle Elemente, die per Categorizes Abhängigkeiten in diesem Paket enthalten sind, repräsentieren die Angehörigkeit der Kategorie. Ein Paket stellt eine Kategorie dar, wenn es die Quelle von mindestens einer Categorizes Abhängigkeit ist. Der Name der Kategorie ist derselbe, wie der Name des Paketes. Mehrfach überlappende Categorizes können erstellt werden, um allerlei Verwendungszwecke in der Prozess Entwicklung zu dienen.

ProzessCoponent (Prozesskomponente)

Eine Prozesskomponente ist eine Menge von Prozessbeschreibungen, die intern konsistent und abgeschlossen sind und möglicherweise mit anderen Prozesskomponenten zusammengesetzt werden können, um einen ganzen Prozess darzustellen. Eine Prozesskomponente importiert einen unwillkürlichen Satz von Prozessdefinitionen, die in SPEM durch Modellelemente modelliert sind. Prozesskomponente ist eine Teilmenge der UML 1.4 Model_Management-Pakete. Die Elemente sind wie in UML 1.4 definiert und Elemente die in Paketen importiert werden, dürfen nicht umbenannt werden.

19


Prozess

Ein Prozess ist ein spezieller Prozess-Baustein, der den gesamten Prozess darstellt. Die Intention liegt daher weniger in der Verknüpfung mit anderen Prozess-Bausteinen, sondern eher in der ganzheitlichen Darstellung. Die Klasse Prozess kann eine Familie von Prozessen darstellen, die ein Prozessbestandteil ist, aus dem heraus mehrfache überlappende Prozesse definiert werden können.

Discipline (Disziplinen)

Eine Disziplin ist eine Spezialisierung der Pakete, die die Aktivitäten innerhalb eines Prozesses dementsprechend zu einem Thema untergliedert. Die Unterteilung auf diese Weise besagt, dass die assoziierten Guidance und Output Arbeitsprodukte in gleicher Weise unter dem Thema kategorisiert sind. Das Einbinden einer Aktivität in eine Disziplin wird repräsentiert durch die Categorizes Abhängigkeiten, mit der zusätzlichen Einschränkung, dass jede Aktivität exakt durch eine Disziplin kategorisiert wird.

Phase

Eine Phase ist eine Spezialisierung „Arbeitsbeschreibung“, so dass ihre Vorbedingungen die Phaseneingangskriterien definieren. Ihr Ziel definiert die Phasenausgangskriterien. Phasen sind mit der zusätzlichen Einschränkung der Sequenzialität definiert; d.h. ihre Inkraftsetzung wird mit einer Serie von Meilensteinen ausgeführt und oft nimmt man minimale Überlappung von ihren Tätigkeiten rechtzeitig an.

Precondition (Vorbedingung) and Goal (Ziel)

Mit jeder Arbeitsbeschreibung können Vorbedingungen und Ziele verbunden werden. Vorbedingungen und Ziele sind Einschränkungen, welche in der Form eines booleschen Ausdrucks auftauchen; gefolgt von einer Syntax, die ähnlich ist zu der Guard Condition in UML. Die Bedingung ausgedrückt in Termen von Zuständen der Arbeitsprodukts, die die Parameter der Arbeitsbeschreibung oder von einer einschließenden Arbeitsbeschreibung sind.

Lebenszyklen

Ein Lebenszyklus ist als eine Reihenfolge von Phasen definiert, die ein spezifisches Ziel erreichen. Es definiert das Verhalten von einem vollständigen Prozess, in einem gegebenen Projekt erlassen zu werden oder programmiert zu werden.

2.4 Diagrammtypen

UML Diagramme können benutzt werden, um verschiedene Perspektiven von Software Prozess Modelle zu veranschaulichen.

SPEM benutzt folgende Diagrammtypen:

• Klassendiagramm

• Paketdiagramm

• Aktivitätsdiagramm

• Use Case Diagramm

20


• Sequenzdiagramm

• Statechart Diagramm

2.4.1 Klassendiagramm

Klassendiagramme erlauben die Präsentation von folgenden Aspekten der Softwareprozesse:

• Erbschaft

• Abhängigkeiten

• Einfache Assoziation

• Kommentar, um auf die Guidance aufmerksam zu machen (zum Beispiel URL Verbindung)

• Verhältnisse zwischen ProzessPerformer oder ProcessRole(Prozessrolle) und Arbeitsprodukt

• Struktur, Auflösung, und Abhängigkeiten von Arbeitsprodukts Folgende Aspekte sollten jedoch nicht repräsentiert werden:

• Interface

• Template

• Weißer Diamant

• Qualifizierte Assoziationen

• N-fache Assoziationen

•

Abbildung 13: Klassendiagramm aus der SPEM Spezifikation 1.1 [SPEM]

21


2.4.2 Paketdiagramm

Paketdiagramme erlauben die Repräsentation von Prozessen, Prozesskomponenten, Prozesspaketen und Disziplinen. Geschachtelte und nicht geschachtelte Formen können benutzt werden.

Abbildung 14: Paketdiagramm aus der SPEM Spezifikation 1.1 [SPEM]

2.4.3 Use Case Diagramm

Use Case Diagrams zeigen die Beziehungen zwischen Prozessrollen und den Haupt-Arbeitsbeschreibungen. Keine besonderen Einschränkungen werden verwendet.

Abbildung 15: Use Case Diagramm aus der SPEM Spezifikation 1.1 [SPEM]

22


2.4.4 Aktivitätsdiagramm

Aktivitätsdiagramme zeigen den sequenziellen Ablauf von Aktivitäten mit ihren Input und Output des Arbeitsprodukts. Swimlanes können die Verantwortlichkeitsbereiche der ProcessRoles (Prozessrolle) abgrenzen.

Abbildung 16: Aktivitätsdiagramm aus der SPEM Spezifikation 1.1 [SPEM]

2.5 Wohlgeformte Regeln

Die folgenden wohlgeformten Regeln aus der UML 1.4 Spezifikation gelten bei den Spem_Foundation Paketen. Ich habe nur die wohlgeformten Regeln erwähnt, die in Zusammenhang mit meiner Aufgabenstellung relevant sind.

Namensraum [C1] Ist ein Element in einem Container und ist das Element keine

Assoziation oder Generalisierung dann muss der Name in dem Namensraum eindeutig sein

[C2] Alle Assoziationen müssen einen eindeutigen Namen und dazugehörigen Classifier in dem Namensraum haben.

23


Beschränkungen [C3] Eine Beschränkung kann nicht auf sich selbst bezogen sein

Assoziations-Ende [C4] Eine Instanz kann nicht durch eine Komposition zu mehr als

einer Kompositions- Instanz gehören

Endzustand [C5] Ein Endzustand kann nicht ausgehende Übergänge haben.

Aktivitätsgraph [C6] Ein Aktivitätsgraph bestimmt die Dynamik der (i) Pakete oder

(ii) der Classifier oder (iii) BehavioralFeature.

Categorizes [C7] Die Quelle muss eine Art Paket sein.

Impacts [C8] Das Ziel muss eine Art Arbeitsprodukt sein

Import [C9] Die Quelle und das Ziel müssen eine Art Paket sein.

Precedes [C10] Die Quelle und das Ziel müssen eine Art Arbeitsbeschreibung

sein.

Aktivität [C11] Jede Aktivität ist genau von einer Disziplin importiert.

[C12] Jede Aktivität gehört zur einer Prozessrolle

Prozessrolle [C13] Jede Arbeit muss eine Art Aktivität sein.

Step [C14] Ein Step hat keine assoziierten Aktionen.

24


Arbeitsbeschreibung [C15] Wo ein Aktivitätsgraph ist, ist ein subWork abgeleitet.

Prozesskomponenten [C16] Keine Abhängigkeiten außerhalb von Prozesskomponenten

[C17] Keine Assoziationen außerhalb von Prozesskomponenten

25


3 Editor

3.1 SPEM Umsetzung

Wie schon in der Aufgabenstellung erwähnt, war es meine Aufgabe einen grafischen Editor zu entwickeln, mit deren Hilfe man spezielle SPEM Prozessmodellierungsdiagramme entwerfen kann. Dieses sollten als ein Eclipse Plug-In programmiert werden.

3.1.1 Eclipse

Eclipse ist ein Open-Source-Framework zur Entwicklung von Software nahezu aller Art. Die bekannteste Verwendung ist die Nutzung als Entwicklungsumgebung (IDE) für die Programmiersprache Java. Eclipse ist nicht auf Java festgelegt und wird aufgrund seiner offenen plugin-basierten Struktur mittlerweile für sehr unterschiedliche Entwicklungsaufgaben eingesetzt, da so die Notwendigkeit für jeden Nischen-Hersteller entfällt, seine eigene IDE für jedes Entwicklungstool zu entwickeln. Da man in dieser Entwicklungsumgebung ganze Projekte aufbauen und strukturieren kann, hat dies denn Vorteil, die Prozessmodellierungsdiagramme in die Struktur dieser Projekte mit einzubauen. Abbildung 17 zeigt die Entwicklungsumgebung Eclipse.

Abbildung 17: Ausschnitt aus dem Programm „Eclipse“

26


3.1.2 Graphical Editing Framework und ProFlow

Das Graphical Editing Framework (GEF) ist ein Plugin für Eclipse, welches den Entwicklern erlaubt, ein existierendes Anwendungsmodell zu nehmen und daraus schnell einen grafischen Editor zu erstellen. GEF basiert auf einer MVC-Architektur, die es erlaubt, einfache Änderungen vom Modell auf der View anzuwenden. Es ist außerdem komplett anwendungsneutral und bietet den Grundstock zum Bau beinahe jeder Anwendung. Auf der Basis von GEF wurde von Mitarbeitern des Institutes Software Engineering an der Universität Hannover ein grafisches Framework entwickelt, das ProFlow heißt. Bei der Umsetzung der Prozessmodellierungssprache SPEM in ein ProFlow Editor musste ich in erster Linie alle SPEM Elmente, Transition und die Annotation in den Editor umsetzten. Dazu war eine Einarbeitung in die SPEM Spezifikation notwendig. Nach Absprache mit meinem Betreuer habe ich das Klassendiagramm, Aktivitätsdiagramm und Use Case Diagramm in ProFlow umgesetzt.

3.1.3 Was nicht mit ProFlow umsetzbar war

Da dieses Framework noch nicht ganz ausgereift ist, konnte ich nicht alle Möglichkeiten der Prozessmodellierungssprache SPEM in den Editor umsetzen. Im Folgenden werde ich erläutern, welche ich davon nicht implementieren konnte. Bei den Aktivitätsdiagrammen von SPEM existieren optionale Swimlanse, die gewisse Containereigenschaften besitzen. Aber Containerstrukturen und Elemente sind im ProFlow Framework noch nicht entwickelt worden. Zusätzlich haben sich einige wohlgeformten Regeln aus der SPEM Spezifikation auf den Namensraum bezogen. Diese waren nicht mit der aktuellen Version von ProFlow umsetzbar.

3.1.4 Wohlgeformte Regeln im Editor

In dieser Spezifikation existieren wohlgeformte Regeln, die die Modellierung der SPEM Diagramme betreffen. Einige von diesen Regeln habe ich in den Editor umgesetzt, damit dem User bestimmte Fehler in der Modellierung von Diagrammen nicht passieren. Abhängigkeiten habe ich als spezielle Transitions mit dementsprechenden Beschriftungen entwickelt. So konnte ich Einschränkungen auf die Benutzung der Abhängigkeiten aus den wohlgeformten Regeln der SPEM Spezifikation erzeugen. Wie man in Abbildung 18 sieht, sollte die Quelle einer solchen categorizes Transition immer eine Art Paket sein. Das betrifft also die Prozesspakete und die Disziplinen.

Abbildung 18: Eigene Darstellung mit dem SPEM Editor erzeugt.

27


Wie man in Abbildung 19 sieht, sollte das Ziel einer solchen impacts Transition immer ein Arbeitsprodukt sein.


Wie man in Abbildung 20 sieht, sollte die Quelle und das Ziel einer solchen import Transition immer eine Art Paket sein.


Wie man in Abbildung 21 sieht, sollte die Quelle und das Ziel einer solchen precedes Transition immer eine Arbeitsbeschreibung sein.


Wie man in Abbildung 22 sieht, sollte bei einer Komposition Transition ein Element wie dieses Dokument nur Assoziation haben.


28


Wie man in Abbildung 23 sieht, sollte ein Start-Zustand eine ausgehende Transition und keine eingehende Transition haben und ein End-Zustand eine eingehende Transition und keine ausgehende Transition.


Viele der wohlgeformten Regeln beziehen sich auf Diagrammtypen, die ich nach Absprache mit meinem Betreuer nicht umsetzen sollte. Zusätzlich haben sich einige wohlgeformte Regeln aus der SPEM Spezifikation auf den Namensraum bezogen. Diese waren nicht mit der aktuellen Version von ProFlow umsetzbar. Weitere Einschränkungen habe ich der folgenden Abbildung 24 entnommen, indem ich die Kardinalitäten der einfachen Verbindungen im Editor umgesetzt habe.

Abbildung 24: SPEM Hauptklassen aus Acuna, Juristo, „Software Process Modeling“ (2005) [Acun]

29


3.2 Annotation um zu bewerten und um Erfahrung zu speichern

Ein Teil dieser Arbeit war es, ein Konzept zu entwickeln, womit man Prozesse und deren Elemente bewerten kann. Wie man schon aus der Aufgabenstellung sieht, soll diese Bewertung in Form einer Annotation erfolgen, die man den Elementen des Editors anheften kann.

Abbildung 25: höchste Abstraktionsebene des Konzepts

Wie man in der Abbildung 25 sieht, wird dieser Rolle (Strichmännchen) eine Annotation, die die Form eines Rechtecks bildet, angeheftet. Die Verbindung zwischen Prozesselement und Annotation wird in Form einer gestrichelten Linie realisiert. Dieses Model ist die höchste und damit die erste Stufe der Abstraktion. Nachdem wir die Struktur dieses Abstraktionslevels definiert haben, werden wir nun eine Struktur der Annotation selbst entwickeln müssen. Da die Annotation als Mittel zum Zweck der Bewertung verwendet werden soll, müssen wir uns erst einmal überlegen welche Parameter und Informationen für die Bewertung von Prozessen und deren Elemente wichtig sind. Das erste und naheliegendste, das mir einfiel, war eine umgangssprachliche Bewertung. Dieses würde man ganz einfach als eine Textbox realisieren. Die Unbeschränktheit des Bewertenden in diesem Konzept könnte aber zu einer Bewertung führen, dessen Informationsgehalt entweder sehr hoch oder sehr niedrig ist. Dies ist allein von dem Bewertenden selbst abhängig. Deswegen habe ich mich für ein Konzept entschieden, das ein Mindestmaß an Informationsgehalt zusichert. Um über dieses Mindestmass zu gelangen, wird die umgangssprachliche Bewertung auch in dieses Konzept integriert werden. Um dieses Mindestmass an Informationsgehalt zu erhalten, sollten folgende Projektmerkmale abgefragt werden:

• Projektgröße

• Projekttechnologie

• Teamgröße

• Projektarchitektur Die Projektmerkmale lassen Vergleiche zwischen Projekten mit ähnlichen Projektmerkmalen zu. Außerdem sollte eine Skala vorhanden sein, um die Bewertung durchzuführen.

30


3.2.1 Konzept einer Skala

Mit der Skala soll die Bewertung vollzogen werden. Dazu sollte man sich überlegen, welche Art von Skala benutzt werden sollte. Eine ordinale Skala würde sich hier gut eignen, da man nicht wie bei einer nominalen Skala nur auf Gleichheit unterscheiden kann (=, !=) sondern auch auf Größer/Kleiner-Gleich (>=) unterscheiden kann. Dadurch ist ein Vergleich erst möglich. Die Skala der Schulnoten sind ein Beispiel einer solchen Ordinalen Skala, die ich in einer Vereinfachung übernommen habe, wie die Abbildung 26 zeigt.

Abbildung 26:Radiobutton Skala der Schulnoten

Die Annotation sollte nun wie in Abbildung 27 aussehen.

Abbildung 27: Struktur der Annotation

3.2.2 Konzept der Annotation mit Dialogfeld

Da die Annotation schnell durch die Anzahl der Projektmerkmale sehr groß wird, sowie aus der Tatsache, dass jedes Element des Editors eine Annotation erhalten kann, wird klar, dass ein Diagramm schnell überladen und unübersichtlich werden kann. Deswegen kam ich zu dem Entschluss, folgendes Konzept zu entwickeln.

31


Abbildung 28: Konzept der Annotation mit Dialogfeld

Wie die Abbildung 28 zeigt, existiert ein zusätzliches Dialogfeld rechts. In diesem Dialogfeld sollen alle Information der Bewertung eingegeben und gespeichert werden. Eine kurze Zusammenfassung oder eine Auswahl dieser Informationen soll dann in der Textbox der Annotation erscheinen. Das Dialogfeld selbst soll man bei Bedarf aufrufen und schließen können, damit das Diagramm nicht überladen wird.

Abbildung 29 Eigenes Klassendiagramm des Bewertungskonzept mit dem SPEM Editor erzeugt.

Wie man in Abbildung 29 sieht, kann jedes SPEM-Element eine oder mehrere Annotations-Elemente besitzen. Das bedeutet gleichzeitig auch, dass jedes SPEM-Element mehrfach

32


bewertet werden kann. Über einen Dialog lassen sich Bewertungen zu einem bestimmten Kontext eingeben und speichern. Eine Bewertung besteht aus einem Skalenwert und einem Erfahrungstext. Der Kontext besteht aus Merkmalswerten. Alle Annotations-Elemente besitzen eine Box (Annotations Box). In dieser Box wird eine Kurzfassung (z.B. nur der Skalenwert) der eingegebenen Daten des Dialogfeldes erscheinen. Dies dient der Übersichtlichkeit der Diagramme. Die tatsächliche Realisierung dieses Konzeptes sieht wie in Abbildung 30 aus.

Abbildung 30: Ausschnitt aus meinem entwickelten SPEM Editor

Wie man erkennen kann, habe ich das Konzept in der tatsächlichen Realität um eine Tab-Funktion erweitert. Dies war notwendig, da die Vielzahl der Projektmerkmale drohte, das Dialogfeld zu groß und unübersichtlich zu machen. Das Dialogfeld besteht jetzt nun aus drei Ebenen:

• Bewertung

• Merkmale

• Architektur

33


Wie in Abbildung 31 sind in der Ebene „Bewertung“ nun die ordinale Skala und das Textfeld für die Erfahrung enthalten.

Abbildung 31: Ausschnitt des Dialogfeldes aus meinem entwickelten SPEM Editor

Wie in Abbildung 32 sind in der Ebene Merkmale nun Projektgröße, Teamgröße und Technologie enthalten.


Wie in Abbildung 33 sind in der Ebene Architektur eine Vielzahl bekannter Software-Architekturen enthalten.


34


3.2.3 Zweck der Bewertung

Dieser Teil meiner Aufgabe, eine Bewertung in Form einer Annotation in Prozessdiagrammen zu entwickeln, hat die Motivation Prozesse zu optimieren. Durch eine Bewertung und einem Vergleich erhofft man sich, Prozesse schneller und effizienter zu gestalten. Ein Szenario würde folgendermaßen aussehen. Nachdem man ein Softwareprojekt absolviert hat, treffen sich Mitglieder dieses Projekts zu einem Workshop. Eine wichtige Frage wäre, welche Personen eines Projekts sollten zu diesem Workshop eingeladen werden? Da eine Bewertung immer etwas Subjektives ist, sollte man sich vorher klar machen, welche Personen welche Sicht auf das Projekt haben. Bei einem Manager würde die Kostenfrage eine höhere Bedeutung haben als bei einem Programmierer. Eine bestimmte Rolle in einem Projekt würde auch ungern einräumen, das sie überflüssig ist. Deshalb sollte man am besten eine gute Mischung der Personen erreichen, damit man am Ende eines solchen Workshops viele Daten aus verschiedenen Blickwinkeln hat, um dann an einer eventuellen Neumodellierung des Prozesses zu arbeiten. Solch ein Workshop, wo mit Hilfe dieses Bewertungskonzept eine Rekapitulation des Prozesses eines Projektes durchgeführt wird, soll in erster Linie zur Gewinnung von Informationen dienen. Bei der Verarbeitung dieser Informationen können die schon erwähnten Projektmerkmale helfen, Prozesse bis zu einem bestimmten Grad zu vergleichen. Das zum Beispiel folgende Szenario „Was bei dem einem Projekt super war, könnte in einem anderen Projekt auch funktionieren“ liefert die Motivation, die Projektmerkmale in dieses Bewertungskonzept mit einzubinden. Abbildung 34 zeigt einen solchen Workshop.

Abbildung 34: Grafik für einen Workshop aus der Vorlesungsfolie 116 des Faches Anforderung und

Entwurf des Institutes Software Engineering an der Universität Hannover [Schn]

35


Im Endeffekt soll ein Kreislauf entstehen, wie die folgende Abbildung 35 zeigt.

Abbildung 35: Bewertungskreislauf

Die vier Aktivitäten bilden hier den Kreislauf. Die Projektteilnehmer erfassen und bewerten den durchgeführten Prozess ihres Projektes und die Prozessanalytiker unterstützen die Projektteilnehmer dabei. Danach begibt sich der Prozessanalytiker zur Auswertung. Mit Hilfe der analysierten Bewertungen lassen sich dann Anpassungen an die Prozesse vornehmen. Durch die Vergleiche mit anderen Prozessen, die man durch die Projektmerkmale erhalten hat, lassen sich Prozessauswahlkriterien für neue Projekte bestimmen.

3.3 Softwareprojekte als Beispiel für einen Prozess

Das Softwareprojekt ist eine Pflichtveranstaltung innerhalb des Studiumsverlaufs des Studienganges Informatik an der Universität Hannover. Innerhalb dieser praktischen Veranstaltung sollen Gruppen von 5-6 Studenten zusammen an einem Softwareprojekt arbeiten. Hat man das Vergnügen, ein solches Projekt von dem Software Engineering Institut zu erhalten, dann wird dieses nicht nur zur einer reinen Programmierveranstaltung. Die Berufsrealität wird bis zu einem gewissen Grade simuliert. So wurde eine fiktive Computerspielefirma ins Leben gerufen namens FunGate oder die Gruppen erhalten zum Beispiel Kundengesprächsgutscheine, die den Wert von 15 Minuten haben. Damit wird die Problematik simuliert, dass meist in der Realität der Kunde schwer zu einem Gespräch zu erreichen ist. Der Prozess dieses Softwareprojekts, das ich selbst absolviert habe, werde ich nun mit Hilfe von SPEM modellieren.

36


3.3.1 Aktivitätsdiagramm

Abbildung 36: Aktivitätsdiagramm des Softwareprojekts

Wie man im Aktivitätsdiagramm der Abbildung 36 sieht, besteht der Prozess hauptsächlich aus den Phasen „Anforderungsanalyse“, „Entwurf“, „Implementierung“ und den „Quality Gates“ Phasen die zwischen den anderen Phasen stehen. In den „Quality Gates“ Phasen überprüft ein Qualitätsexperte die Ausgabedokumente einer Phase darauf, ob sie den Qualitätsanforderungen des Kunden genügen.

37


3.3.2 Use Case Diagramm

Anforderung Analyse

Abbildung 37: Use Case Diagramm des Softwareprojekts

Die Abbildung 37 zeigt, wie man mit Hilfe des Use Case Diagramms der Prozessmodellierungssprache SPEM den Prozess des Softwareprojektes weiter in die tiefe darstellen kann. Außerdem werden durch den Diagrammtypwechsel neue Informationen sichtbar. Hier erkennt man, welche Rolle bei welcher Aktivität assistiert oder verantwortlich ist.

38


3.3.3 Klassendiagramm

Abbildung 38: Klassendiagramm des Softwareprojekts

In der Abbildung 38 wird ein Klassendiagramm gezeigt. Hier erkennt man, dass die Rolle „Requirements Engineer“ aus den Rollen „Protokollant“, „Systemanalytiker“ und „Interviewer“ besteht.

39


4 Bedienungsanleitung [And] 4.1 Installation

Diese hier beschriebene Bedienungsanleitung wurde größtenteils aus der Bedienungsanleitung für den ProFlow von Andreas Meißner angepasst. Da die von mir umgesetzten Diagramme auf der Basis von ProFlow arbeiten, ist die Bedienung bis auf ein paar kleine Änderungen, die ich hier erweitert habe, identisch. ProFLOW wurde mit und für Eclipse 3.2 entwickelt. Das Eclipse 3.2 Releases steht unter folgendem Link zur Verfügung: http://download.eclipse.org/eclipse/downloads/ Zur Installation von Eclipse muss lediglich die heruntergeladene .zip-Datei in einen gewünschten Zielordner entpackt werden. Außerdem benötigt man noch das Graphical Editing Framework (GEF) in der entsprechenden Version 3.2. Dieses ist unter dem folgenden Link verfügbar: http://download.eclipse.org/tools/gef/downloads/index.php Die hierzu gehörende .zip-Datei muss ebenfalls lediglich in den Eclipse-Ordner entpackt werden. Dabei werden die Unterordner /features und /plugins um einige Dateien und Ordner erweitert. Abschließend muss nun noch das ProFLOW Framework installiert werden. Hierzu muss ebenfalls lediglich die gegebene .zip-Datei in den Eclipse-Ordner entpackt werden, so dass die Unterordner /features und /plugins mit den notwendigen Dateien erweitert werden. Abschließend müssen Sie nun nur noch die beiden Frameworks GEF und ProFLOW in Eclipse aktivieren. Führen sie hierfür folgende Schritte aus:

1. Starten Sie Eclipse (Ausführen der eclipse.exe im Eclipse-Ordner) 2. Aktivieren Sie die beiden Frameworks unter Help Software Updates Manage Configuration 3. Aktivieren Sie den dritten Schalter in der Toolbar-Leiste "Show Disabled Features" und aktivieren Sie die deaktivierten Frameworks GEF und ProFLOW (auswählen und "enablen" … siehe Abbildung 1-1) 4. Schließen und Starten Sie Eclipse neu

Die Installation ist somit abgeschlossen und sie können ihre ersten ProFLOW Diagramme erstellen. Außerdem ist es nun auch möglich, neue Eclipse Plugins zu entwickeln, welche auf ProFLOW aufbauen und das Framework um weitere Diagrammtypen erweitern.

40

http://download.eclipse.org/eclipse/downloads/

http://download.eclipse.org/tools/gef/downloads/index.php


Abbildung 39: Ausschnitt aus der Eclipse Programmierumgebung

4.2 Benutzung

In diesem Kapitel soll nun kurz darauf eingegangen werden, wie sie mittels ProFLOW Diagramme erstellen können.

Anlegen eines neuen Projekts

ProFLOW Diagramme müssen einem Projekt zugeordnet sein. Somit benötigen sie, bevor sie ein ProFLOW Diagramm erstellen möchten, zunächst ein Projekt. Es genügt, wenn sie ein einfaches Projekt anlegen. Starten sie hierfür den Menupunkt: File New Project. Es erscheint somit der Project Creation Wizard. Hier wählen sie den Eintrag Project im Ordner General aus. Natürlich können sie hier auch jeden anderen Projekttyp auswählen.

Erzeugen eines neuen Diagramms

Haben sie ein neues Projekt erstellt, können sie in diesem ein neues ProFLOW Diagramm erzeugen. Klicken sie mit der rechten Maustaste auf das neu angelegtes Projekt und starten sie den folgenden Kontextmenueintrag: New Other. In dem erscheinenden Creation Wizard wählen sie nun den Eintrag ProFLOW Diagram im Other Ordner aus und drücken

41


sie Next. In der folgenden Wizard Page können sie den Diagrammtyp auswählen. Hier können sie zwischen allen registrierten Diagrammtypen wählen. Das Description-Feld liefert die Beschreibung zu dem ausgewählten Diagrammtyp. Haben sie sich für einen Diagrammtyp entschieden, müssen sie in der folgenden Wizard Page nun nur noch den Namen und den Dateinamen des zu erstellenden Diagramms definieren. ProFLOW Diagramm Dateien müssen mit der Extension .proFLOW enden. Schließt man den Creation Wizard mit Finish wird die erzeugte .proFlow- Datei mit dem grafischen ProFLOW Editor geöffnet.

Abbildung 40: Ausschnitt aus der Eclipse Programmierumgebung

Editieren eines Diagramms

In dem geöffneten ProFLOW Editor können sie nun ihr Diagramm erzeugen. Hierfür müssen sie lediglich ein gewünschtes Element in der Palette auswählen und in der Zeichenfläche platzieren. Das Cursor-Feedback zeigt dabei an, ob das Hinzufügen eines Elementes bzw. das Verbinden zweier Elemente miteinander über eine Transition zulässig ist. Die Palette des jeweiligen Editors beinhaltet immer die Elemente des jeweiligen Diagrammtyps sowie alle FLOW Elemente. Außerdem stehen immer die Paletteneinträge Select und Marquee zum Auswählen von Elementen zur Verfügung sowie der Eintrag Text zum Hinzufügen einfacher Text-Labels.

42


Abbildung 41: Ausschnitt aus dem SPEM Editor

Die erzeugten Elemente lassen sich frei auf der Zeichenfläche positionieren. Sie können zudem (soweit zulässig) auch in einem fest vorgeschriebenen Bereich vergrößert bzw. verkleinert werden. Das Routing einer Transition kann zudem mittels Bendpoints verändert werden. Der Name eines Elements kann mittels Doppelklick mit einem TextCellEditor verändert werden. Der Name sowie weitere registrierte Attribute eines selektierten Elements können auch über die Properties View geändert werden. Sollte die Properties View nicht sichtbar sein, öffnen sie diese mittels Window Show View Other General Properties. Der ProFLOW Editor verfügt über eine Undo/Redo Funktionalität, sodass alle Veränderungen auch wieder rückgängig gemacht werden können.

Weitere Features

• Zoom: Über die Kontextmenueeinträge Zoom In und Zoom Out des ProFLOW Editors sowie über den entsprechenden Toolbar Eintrag ist es möglich, in die Editor-Zeichenfläche zu zoomen.

• Drucken:

Über den Menueeintrag File Print.. ist es möglich, den Inhalt des aktuellen ProFLOW Editors auszudrucken.

43


• Alignment und Match Actions: In der zugehörigen Toolbarleiste des ProFLOW

Editors werden noch einige Actions zur Verfügung gestellt, womit selektierte Diagrammelemente ausgerichtet werden können oder deren Größe angeglichen werden können. Abbildung 41 zeigt diese Toolbarleiste.

Abbildung 42: Ausschnitt aus dem SPEM Editor

• Annotations-Daten: Diagrammelemente lassen sich über Annotations-Elemente bewerten. Wählt man mit der rechten Mausetaste den Kontextmenueeintrag Annotations-Daten bei den Annotations-Elementen aus, so öffnet sich ein Dialogfeld mit deren Hilfe man eine Bewertung über das Diagrammelement abgeben kann, das mit dem Annotations Element verbunden ist.

• Image Export Ruft man mit der rechten Maustaste das Kontextmenue auf, so erscheint der Menueeintrag Image Export. Wählt man diese aus, so öffnet sich ein Dialog, indem man ein grafisches Ausgabeformat wählen kann. Hat man dann noch über den Browse Button das Ziel gewählt so kann man die modellierten Diagramme exportieren.

44


5 Glossar Im Glossar aufgeführte Begriffe sind im Text kursiv hervorgehoben.

Eclipse Eclipse ist ein Open-Source-Framework zur Entwicklung von Software nahezu aller Art. Die bekannteste Verwendung ist die Nutzung als Entwicklungsumgebung (IDE) für die Programmiersprache Java.

Plugin Plugins sind Erweiterungen eines Programms, die neue Funktionalitäten anbieten.

UML UML ist ein Industriestandard für eine Modellierungssprache (Notation) von Systemen.

Wohlgeformte Regeln Die wohlgeformten Regeln aus der SPEM Spezifikation sind Beschränkungen, die man bei der Modellierung von SPEM Diagrammen beachten muss.

Interoperabilität Als Interoperabilität bezeichnet man die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen, Techniken oder Organisationen. Dazu ist in der Regel die Einhaltung gemeinsamer Standards notwendig. Wenn zwei Systeme miteinander vereinbar sind, nennt man sie auch kompatibel.

GEF Das Graphical Editing Framework (GEF) ist ein Plugin für Eclipse, welches den Entwicklern erlaubt, ein existierendes Anwendungsmodell zu nehmen und daraus schnell einen grafischen Editor zu erstellen.

Kardinalität Kardinalitäten werden auch Multiplizierer genannt. Kardinalitäten beziehen sich auf Verbindungen zwischen Elementen in einem Diagramm. Kardinalitäten sind numerische Werte, die darüber Auskunft geben mit wie vielen Repräsentanten eines Elementen ein anderes Element in Beziehung stehen kann.

45


6 Quellenangaben

[SPEM] Software Process Engineering Metamodel Specification Version 1.1 [Sch] Prof. Dr. Kurt Schneider, Anforderung und Entwurf (2006) Folie 116 [And] Andreas Meißner, Bedienungsanleitung ProFlow [Acun] Auna, Juristo, „Software Process Modeling“(2005)

46

Ein grafischer Editor mit Annotationsmöglichkeit für SPEM ... · Im Prinzip verfeinern Profile...

Documents

Transcript of Ein grafischer Editor mit Annotationsmöglichkeit für SPEM ... · Im Prinzip verfeinern Profile...