Konzept und Implementierung eines heuristischen Editors für Domänenmodelle im Requirements Engineering

Größe: px
Ab Seite anzeigen:

Download "Konzept und Implementierung eines heuristischen Editors für Domänenmodelle im Requirements Engineering"

Transkript

1 Leibniz Universität Hannover Institut für Praktische Informatik Fachgebiet Software Engineering Konzept und Implementierung eines heuristischen Editors für Domänenmodelle im Requirements Engineering Concept and implementation of a heuristic editor for Domain Models in Requirements Engineering Masterthesis Godehard Konrad Hecke 17. Oktober 2011 Erstprüfer: Zweitprüfer: Prof. Dr. Kurt Schneider Dr.-Ing. Eric Knauss

2

3 Gewidmet ist diese Arbeit meinem Vater Wolfgang. Ein besonderer Dank gilt meiner Mutter Marianne, meinem Bruder Tobias sowie meinen Freunden.

4

5 v Zusammenfassung In vielen Bereichen der Software-Entwicklung setzt sich die Meinung durch, dass eine strukturelle Gliederung der betrachteten Objekte nicht erst für den Entwurf in Form eines Klassendiagrammes durchgeführt werden sollte, sondern diese bereits in der Analysephase vorgenommen werden sollte, um so mit den Anforderungen mit zu wachsen. Diese Gliederung soll das Domain Model übernehmen. Entsprechend dieser Meinung beschäftigt sich diese Arbeit mit der prototypischen Implementierung eines Editors für Domain Models auf Basis der UML-Notation für Klassendiagramme. Des Weiteren legt diese Arbeit dar, wie unter Zuhilfenahme heuristischer Kritiken die Konsistenz zwischen den häufig in Anforderungsdokumenten vorkommenden Use Cases und den neu erstellten Domain Models geprüft und gesichert werden kann. Die entwickelten Resultate und Verfahren sowie der Prototyp, wurden in dem am Fachgebiet Software Engineering der Leibniz Universität Hannover entwickelten Programm HeRA umgesetzt und auf ihre Effizienz getestet. Abstract In many areas of Software Engineering the opinion establishes, that a structural partition of all the objects used is not only important by creating the design of the software. It rather should grow up with the entire project, starting with the Requirements Analysis by using a Domain Model. According to this meaning, this approach shows an implementation of a prototype for a Domain Model Editor which realizes the notation of the UML Class Diagram. Furthermore it shows how this Domain Models could be examined for consistency with Use Cases of the Requirements Document. All results of this approach and the prototype are examined by creating an extension of HeRA, a tool of the Software Engineering Group at the Leibniz University of Hannover to support the Requirements Analysis.

6

7 vii Inhaltsverzeichnis 1 Einführung Motivation Problemstellung Einordnung in die Software-Entwicklung Struktur der Arbeit Domain Models Domain Models und ihr Nutzen Domain Model-Notationen Einsatzgebiet des Domain Models Nutzergruppen des Domain Models Die Konsistenzproblematik Domain Model-Erweiterung für HeRA Einführung in HeRA Relevante UML-Elemente Realisierung des Editors Konsistenzsicherung durch heuristische Kritiken Einführung in das Kritiksystem von HeRA Intra-Modell-Kritiken Inter-Modell-Kritiken Anpassung des Kritiksystems von HeRA Weiterführende Ergebnisse Prävention Katalogkomponente für Analysemuster Kommentare als Glossareinträge Export Abschließende Betrachtung der erarbeiteten Ergebnisse Fazit Abgrenzung zu ähnlichen Konzepten Anregungen für zukünftige Arbeiten Anhang 69 Definitionsverzeichnis 77 Glossar 79 Literaturverzeichnis 81

8

9 1 1 Einführung 1.1 Motivation In der traditionellen Software-Entwicklung unterscheidet man unter anderem zwischen den zwei Disziplinen Requirement Engineering und Software-Entwurf. Als Folge des logisch vorangehenden Requirement Engineerings entstehen eine Vielzahl von Anforderungen, die häufig mittels Use Cases strukturiert und präzisiert werden. Diese Use Cases werden in einer Spezifikation festgehalten. Mit der Erstellung dieses Dokuments endet dann auch der Aufgabenbereich der Requirement Engineers und der des Entwurfsteams beginnt. Im Software-Entwurf werden nun die Anforderungen schrittweise in einen Bauplan für das zu erstellende Programm überführt. Hierzu wird zunächst eine grobe Architektur entwickelt, welche unter anderem in einem Domain Model festgehalten wird. Dieses Modell zeigt dabei, welche Entitäten beteiligt sind und wie sie miteinander in Verbindung stehen. Das erstellte Domain Model wird im Laufe der Entwurfsphase nach und nach verfeinert, bis schlussendlich ein detaillierter, statischer Entwurfsplan in Form eines Klassendiagramms entsteht. Dieser wird im Anschluss an den Entwurf implementiert und es entsteht ein lauffähiger Code. Im besten Fall nehmen einige Mitarbeiter sowohl eine Rolle in der Anforderungserhebung, als auch eine im Entwurf ein. Dadurch gehen die in der ersten Phase erlangten Erkenntnisse über strukturelle Zusammenhänge sowie das daraus abgeleitete Verständnis nicht ganz verloren und kann so in die zweite Phase transferiert werden. Im schlimmsten Fall jedoch, werden beide Phasen von verschiedenen, klar voneinander getrennten Abteilungen realisiert. In beiden Fällen geht durch die Trennung beider Rollen Information verloren, die erneut erschlossen werden muss. Neben der verlorenen Information besteht auch die Gefahr der Fehldeutung und damit verbunden der Fehlimplementierung der analysierten Anforderungen. Durch die fehlende Bindung beider Phasen wird somit unnötig Energie für die Wiedergewinnung bereits erlangten Wissens verschwendet. Das kostet Zeit und Geld, welches im folgenden Projektverlauf fehlt, und kann sogar das Scheitern desselben nach sich ziehen. Aus diesem Grund wäre es wünschenswert, bereits in der Anforderungsanalyse gewisse Strukturinformationen in Form eines Domain Models festzuhalten und diese auf ihre Konsistenz hinsichtlich der formulierten Use Cases zu prüfen, um gegebenenfalls regulierend einzugreifen. Im Idealfall könnte dieses Modell ohne großen Aufwand als Ausgangsmodell für den späteren Entwurf dienen. Besser wäre gar eine semiautomatische Ableitung des Domain Models aus den erhobenen Use Cases. Somit wären beide Verfah-

10 2 Einführung ren direkt miteinander verknüpft. Denn nur ein in sich konsistentes Anforderungsdokument reduziert den oben genannten Mehraufwand auf ein Minimum und kann als solide Grundlage für die auf die Anforderungserhebung folgenden Schritte der Softwareentwicklung dienen. Ziel dieser Arbeit soll es nun sein, das bestehende Requirement Engineering Tool HeRA um eine Funktionskomponente zur Erstellung von Domain Models zu erweitern. Diese Erweiterung soll zum einen den Requirement Engineer bei der Modellierung, Verwaltung und Änderung von Domain Models unterstützen und zum anderen zeigen, in wie weit dieser Prozesse durch gezielte Feedbacks, in Form von heuristischen Kritiken, geleitet werden kann, um so die Konsistenz zwischen den bestehenden Use Cases und den neu erstellten Domain Models zu sichern. 1.2 Problemstellung In der folgenden Abhandlung soll die Beziehung zwischen Use Cases und Domain Models untersucht und ein Konzept zur Sicherung der Konsistenz zwischen beiden Verfahren entwickelt werden. Hierzu werden Use Cases als Funktion über dem Domain Model gesehen. Sie sollen die verschiedenen Instanzen der Entitäten, ausgehend von einem Ausgangszustand, in einen definierten Folgezustand überführen. Resultierend aus diesen Erkenntnissen wird ein Prototyp als Erweiterung für den am Fachgebiet Software Engineering entwickelten Heuristic Requirements Assistant (He- RA) implementiert. Dieser soll das bestehende Programm um einen Editor für Domain Models erweitern und das entwickelte Konzept zur Konsistenzsicherung umsetzen. Dies geschieht unter Zuhilfenahme des bestehenden Konzeptes der heuristischen Kritiken. 1.3 Einordnung in die Software-Entwicklung In vielen Softwareprojekten bilden Use Cases einen der wichtigsten Kerne der Spezifikation. Sie stellen dabei das Ergebnis des in Abbildung 1.1 dargestellten Requirement Engineering-Prozesses, bestehend aus der Elicitation, der Interpretation und der Negotiation, dar, an dessen Ende eine vollständige und korrekte Dokumentation aller für das Projekt relevanten Anforderungen steht. Use Cases gewährleisten dabei in erster Linie eine einfache, gut gegliederte und leicht verständliche Methode, um die vom Kunden geforderten funktionalen Anforderungen zu notieren. Sie dienen jedoch auch dazu, diese besser zu verstehen und zu verifizieren. Im Verlauf der folgenden Projektphasen werden Use Cases als Bauplan für die zu implementierenden Abläufe und Szenarien genutzt. Am Ende eines Projektes kommen sie erneut in den Fokus des Entwicklerteams. Hier setzt man sie als Referenz für die Abnahmetests ein, die über Erfolg und Scheiten eines Projektes entscheiden.

11 1.4 Struktur der Arbeit 3 Abbildung 1.1: Phasen der Software-Entwicklung [Dai98] Domain Models hingegen kommen in den meisten Fällen erst im Übergang zur Entwurfsphase zum Einsatz. Sie sollen einen groben Überblick über die zu berücksichtigenden Objekte und deren Beziehungen bieten. In vielen Fällen entsprechen diese bereits den späteren Klasseneinteilungen. 1.4 Struktur der Arbeit Diese Arbeit gliedert sich in sechs Kapitel. Während im ersten Kapitel grob der Problembereich umrissen wird, stellt das zweite Kapitel eine Einführung in die Begrifflichkeiten dar. Hier wird die für diese Arbeit relevante Definition für Domain Models aufgestellt sowie die Wahl der Notation begründet. Zusätzlich wird genauer auf die Konsistenzproblematik eingegangen. Kapitel 3 beschreibt die gewählte Notation sowie den Funktionsumfang des erstellten Editors für Domain Models. Im folgenden vierten Kapitel wird das in dieser Arbeit erstellte Konzept zur Konsistenzsicherung erläutert sowie dessen Realisierung beschrieben. Erkenntnisse, die über die reine Konsistenzsicherung hinausgehen, diese jedoch aktiv unterstützen, werden in Kapitel 5 vorgestellt, bevor in Kapitel 6 ein abschließendes Fazit über die in dieser Arbeit dargestellten Ergebnisse gezogen wird. Im Anhang dieser Arbeit befindet sich eine ausführliche Beschreibung der Ergebnisse anhand eines realen Beispiels, das die einzelnen Mechanismen demonstriert und deren Nutzen zeigt. Begriffe, die nicht direkt im Zusammenhang mit dieser Arbeit stehen, jedoch für dessen

12 4 Einführung Verständnis notwendig sind, werden im Glossar erläutert. Die betreffenden Begriffe sind im Text kursiv gedruckt. Alle im Rahmen dieser Arbeit definierten Begriffe werden im Definitionsverzeichnis aufgelistet.

13 5 2 Domain Models Der Begriff Domain Model ist vielen bekannt, jedoch gibt es keine eindeutige Meinung, wann und wie man diese Modelle einsetzt, geschweige denn zu welchem Zweck. Zum Teil kommen sie in Anforderungsdokumenten vor, fristen dort aber oft ein eher tristes Dasein am Rande der Wahrnehmungsgrenze. In einigen Fällen versucht der Requirement Engineer mit ihnen Einfluss auf die Architektur des späteren Programms zu nehmen, was jedoch nicht Sinn und Zweck von Domain Models ist. Dieses Kapitel soll ein grundlegendes Verständnis über Domain Models vermitteln. Zunächst werden hierzu mögliche Notationen zur Darstellung des Domain Models diskutiert, bevor anschließend eine Betrachtung der Einsatzgebiete und der dort agierenden Anwender stattfindet. Abschließend geht dieses Kapitel noch auf die Konsistenzproblematik ein. 2.1 Domain Models und ihr Nutzen In der Software-Entwicklung können Analysten und Entwickler fremden Fachgebieten, so genannten Domänen begegnen. In diesen herrschen ureigene Gewohnheiten und Verhaltensweisen. Hier spricht man eine eigene Fachsprache, betrachtet Dinge als allgemeingültig, die anderswo nicht mal bekannt sind und operiert selbstverständlich mit den verinnerlichten Werkzeugen. Definition 2.1: Domäne (engl. Domain) Anwendungsgebiet bzw. Problembereich, innerhalb dessen die fachliche Modellierung stattfindet. nach Oestereich [Oes09, S. 385] Dieses ihm unbekannte Gebiet muss vom Analysten systematisch erkundet, verstanden und festgehalten werden. Hier kommt nun das Domain Model zum Einsatz. Es soll sowohl beim Verständnis der Domäne helfen, als auch im Anschluss die wichtigsten Objekte (auch Entitäten genannt) und deren Zusammenhänge festhalten und bei Bedarf leicht verständlich wiedergeben.

14 6 Domain Models Definition 2.2: Objekt (auch Entität) [..] Es besitzt einen Zustand sowie eine definierte Menge von Handlungsmöglichkeiten (Operationen), die auf diesem Zustand aufsetzen. Der Zustand wird als Menge von Objektattributen dargestellt. Die Operationen dieses Objekts bieten anderen Objekten (Clients) ihre Dienste an, um z.b. Berechnungen auszuführen. [..] nach Sommerville [Som01, S. 271] Definition 2.3: Modell 1. Modell als a) Abbild von etwas sowie als b) Vorbild für etwas, 2. Modell als c) Repräsentation eines bestimmten Originals (im Sinne von a) und b)) [..]. Drei Hauptmerkmale: Abbildungsmerkmal: Jedes Modell ist ein Modell von etwas, Abbild oder Repräsentation eines natürlichen oder künstlichen Original, das selbst wieder ein Modell sein kann. Verkürzungsmerkmal: Jedes Modell abstrahiert die für den Modellerschaffer und/oder Modellbenutzer relevanten Teile des Originals. Pragmatisches Merkmal: Jedes Modell erfüllt seine Ersetzungsfunktion a) für ein bestimmtes Subjekt b) innerhalb eines bestimmten Zeitintervalls und c) unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen. nach Stachowiak [Sta73, S. 129ff] Abbildung 2.1: Modelltheorie nach [Sta73] Entsprechend der Definition 2.3 und Abbildung 2.1 beschreibt ein Domain Model alle für das Verständnis relevanten Entitäten einer Domäne und fasst deren Beziehungen grafisch zusammen. Dabei können unwichtige Teile der Realität verschwiegen und in der

15 2.1 Domain Models und ihr Nutzen 7 Realität nicht vorhandenen Teile hinzugefügt werden. Ein Domain Model lässt sich also wie folgt definieren: Definition 2.4: Domain Model Visuelle Repräsentation konzeptioneller Klassen oder realer Objekte aus der betrachteten Domäne. nach Schneider [Sch09, S. 88] Schneider vergleicht in seinem Buch [Sch09] Domain Models mit der Kombination eines Glossars, das die relevanten Begrifflichkeiten einer Domäne speichert und einer Mind Map, welche die einzelnen Begriffe miteinander in Beziehung setzt. Definition 2.5: Use Case Beschreibung einer Interaktion zwischen (mindestens) einem Akteur und dem System, durch die ein Ziel des Hauptakteurs erreicht wird. nach Schneider [Sch10, S. 32] Für den Einsatz von Domain Models im Requirement Engineering gibt es mehrere Gründe, aus denen sich ein Mehrwert für die Software-Entwicklung ergibt. So reicht es nach Glinz [Gli00] nicht aus, die Szenarien der Benutzerinteraktionen in Use Cases oder ähnlichem festzuhalten. Denn diese betrachten nur einzelne Ausschnitte, in denen auf einen Auslöser reagiert wird, nie aber das Ganze. Somit braucht man für die objektorientierte Analyse neben der dynamischen Szenariobeschreibung auch noch eine statische Komponente zur vollständigen Darstellung des Verhaltens. Nach Balz [Bal09] kommt das Domain Model für diese Darstellung der statischen Zustände und der Methoden, die sie ändern, in Frage. Domain Model vs. Ontologie Um die an einer Domäne beteiligten Objekte festzuhalten, käme als Konzept auch eine Ontologie in Frage. Während jedoch Ontologien in erster Linie für die Schlussfolgerung von Zusammenhängen und der sich daraus ergebenen Eigenschaften der enthaltenen Objekte gedacht sind, steht beim Domain Modell vor allem die grafische Präsentation der Modellelemente im Vordergrund. Zwar besitzen auch Ontologien Notationen zur grafischen Darstellung, jedoch ist der beschriebene Schlussfolgerungsmechanismus für diese Arbeit nicht relevant. Gesucht ist ein Konzept für die visuelle Verständnishilfe und zur Kommunikationsgrundlage. Genau diese erfüllt das Domain Model.

16 8 Domain Models 2.2 Domain Model-Notationen Zur grafischen Darstellung des Domain Models nutzt man in vielen Fällen das aus der UML bekannte Klassendiagramm, wobei die Entitäten zu Klassen abstrahiert werden. Oft wird dabei auf die Angabe von Attributen und Operationen verzichtet und der Fokus lediglich auf die Domänenobjekte und ihre Beziehungen gelegt. Durch die Nutzung der Notation für UML-Klassendiagramme zur Darstellung des Domain Models ergeben sich einige Vorteile. Die Notation ist den meisten Informatikern bekannt und für alle anderen Beteiligten leicht zu lernen. Zudem ist die Komplexität leicht skalierbar. So kann zum Beispiel in einigen Fällen auf komplexe Konstrukte wie Aggregation und Komposition verzichtet werden und diese durch einfache Assoziationen mit entsprechenden Beschriftungen ersetzt werden. Dies würde sich zum Beispiel im Gespräch mit einem Kunden anbieten. Ist für die spätere Dokumentation eine Vervollständigung erforderlich, so kostet dies keinen großen Aufwand. In der Literatur findet man das Domain Model auch unter anderen Bezeichnungen, wie beispielsweise dem konzeptionellen Klassendiagramm/-modell oder unter dem Begriff Fachklassenmodell. Auch die Art der Darstellung ist nicht auf das UML-Klassendiagramm beschränkt. So wäre eine Darstellung als Entity-Relationship-Modell (ER-Modell) möglich, welches besonders bei der Erstellung von Datenbanksystemen Anwendung findet. Auch hier versucht man die Objekte und ihre Beziehungen grafisch festzuhalten. Unterschiede ergeben sich in erster Linie in der verwendeten Symbolik. Tabelle 2.1 vergleicht einige Notationen, die für eine Realisierung von Domain Models in Frage kämen. Abweichend zu der in [Sch09] dargestellten Notation, die ebenfalls auf dem UML-Klassendiagramm basiert, gestattet die hier vorgestellte auch die Angabe der Fähigkeiten einer Entität, da diese eine präzisere Darstellung der möglichen Aktionen erlauben. Denn Fähigkeiten sind weit mehr als reine Zugriffsmechanismen für die Eigenschaften einer Entität. Sie erlauben zudem das Anwenden und die Kombination einer oder mehrerer Eigenschaften. Außerdem werden die Fähigkeiten, wie in der Arbeit von Glinz [Gli00] beschrieben, auch für die Verknüpfung zwischen Use Cases und Domain Model (siehe Abschnitt 4.3.2) relevant. Im Gegensatz zum adaptierten Klassendiagramm erlaubt ein Domain Model auch die Darstellung von Entitäten, die gar nicht durch das zu realisierende System vertreten werden sollen. So ist es möglich, die mit dem späteren System interagierenden Personen anhand ihrer Rollenbezeichnung im Domain Model abzubilden. Eine ausführliche Betrachtung der Syntax findet in Abschnitt 3.2 statt. Zur klaren Abgrenzung zum Klassendiagramm und zur Schaffung eines einfacheren Verständnisses auf Seiten des Kunden, bietet es sich an, anstatt von Attributen und Operationen wie im Klassendiagramm, von Eigenschaften und Fähigkeiten einer Entität zu sprechen. Somit ergeben sich für diese Arbeit die folgenden Definitionen:

17 2.3 Einsatzgebiet des Domain Models 9 Merkmale Mind Map Klassendiagramm ER-Modell Aufgabe Listet Konzepte auf und setzt diese in Beziehung Beschreibt das Konzept einer Software, mit den zu betrachtenden Klassen samt ihrer Attribute, Operationen und Beziehungen Beschreibt die Elemente, die in einer Datenbank gespeichert werden sollen sowie deren Attribute und Beziehungen Definition von Beziehungen Kann nur einfache Beziehungen darstellen, keine weiter Typisierung möglich Kann verschiedene Beziehungen, samt Beschreibung und Typisierung, darstellen Kann Beziehungen mit verschieden Beschreibungen darstellen Definition von Eigenschaften Eine direkte Modellierung ist nicht vorgesehen Eigenschaften durch Attribute modellierbar Eigenschaften durch Attribute modellierbar Definition von Fähigkeiten Bekanntheit Eine direkte Modellierung ist nicht vorgesehen, wenn nur über weitere Unterknoten möglich Auf Grund der universalen Anwendungsgebiete nahezu jedem bekannt Fähigkeiten durch Operationen modellierbar Bei den meisten Software-Entwicklern bekannt Nicht modellierbar Eher im Datenbankbereich zu Hause Nutzbarkeit Nicht mächtig genug Vom Funktionsumfang passend, dazu verständlich, skalierbar und leicht erlernbar Vom Funktionsumfang passend Tabelle 2.1: Vergleich potentieller Notationen zur Darstellung von Domain Models Definition 2.6: Eigenschaft Zum Wesen einer Person oder Sache gehörendes Merkmal; charakteristische (Teil)beschaffenheit [..]. Duden - Universalwörterbuch [KRA03] Definition 2.7: Fähigkeit Geistige, praktische Anlage, die zu etwas befähigt; Wissen, Können [..]. Duden - Universalwörterbuch [KRA03] 2.3 Einsatzgebiet des Domain Models Der genaue Einsatzzeitpunkt sowie das genaue -gebiet sind in Fachkreisen nicht ganz eindeutig geklärt. So gibt es zwei Standpunkte, die sich auf die folgenden zwei Szenarien herunterbrechen lassen:

18 10 Domain Models Szenario 1 Ein Softwareunternehmen bekommt den Auftrag, eine Anwendung für eine Online-Versandapotheke zu erstellen. Das Unternehmen schickt einen Mitarbeiter des Requirement- Teams in die für ihn vollkommen unbekannte Domäne des Online-Versandhandels von Medikamenten. Zum besseren Verständnis erstellt sich der Mitarbeiter ein Domain Model. Dies beinhaltet alle wichtigen Objekte und Rollen, die im Geschäftsbereich des Versandhandels wichtig sind. Zudem lernt er gleich den Umgang mit den wichtigsten Begriffen und Gepflogenheiten. Szenario 2 Das Requirement Team dokumentiert zusammen mit dem Kunden die Anforderungen für die zu erstellende Software. Im Laufe dieser Anforderungserhebung werden einige elementare Objekte des Systems benannt. Zum besseren Verständnis der Objekte, ihrer Eigenschaften und Fähigkeiten, sowie der Beziehungen untereinander, erstellt das Team ein Domain Model. Die Autoren [Huh05] und [Bal05] vertreten dabei den Standpunkt aus Szenario 2. Der Standpunkt von Szenario 1 hingegen wird von [ZGK04] und [Sch09] vertreten. Obwohl die den Standpunkten zugrunde liegenden Szenarien weit voneinander entfernt sind, haben beide Standpunkte ihre Berechtigung. Jedoch lassen sich Unterschiede in der Formalität und der Lebenserwartung der in den Szenarien erstellten Modelle erkennen. Das Domain Model aus Szenario 1 ist weitestgehend informell gehalten. Es wird sich eher um eine einfache Bleistiftskizze handeln, als um ein valides Modell, welches in einem speziellen UML-Editor erstellt wurde. Doch für den Zweck des ersten Kontakts mit der fremden Domäne kommt es auch nicht auf die Korrektheit des Modells an. Hier wird das Domain Model vielmehr als Mittel zum Zweck gesehen und soll die Verständnisbarrieren zwischen Softwareunternehmen und dessen Kunden überwinden sowie die Kommunikation zwischen beiden Parteien vereinfachen und verbessern. Eine spätere Überführung des Modells gemäß Szenario 2 in eine formale Darstellung ist natürlich jederzeit möglich. Hingegen entspricht das Domain Model, welches in Szenario 2 erstellt wird, einer formalen Notation und wird sauber in das Requirement Dokument integriert. Es dient nicht mehr primär dem Grundverständnis der Domäne, vielmehr hilft es als erklärendes Element bei der Einordnung der einzelnen Anforderungen in den Kontext der zu erstellenden Software. Auch kann es helfen, einige Entscheidungen nachzuvollziehen. Einen weiteren Mehrwert erzielt es durch die Unterstützung der Kommunikation zwischen den beteiligten Mitarbeitern des Entwicklungsteams. Denn so ist allen Beteiligten klar, über was gerade gesprochen wird und welche Details zu betrachten sind. Somit verläuft die Kommunikation weitaus weniger abstrakt. Zum Teil werden hier schon erste Anforderungen an die später im Entwurf entstehende Architektur festgehalten. Allein durch die fehlende Formalität in Szenario 1 begründet sich die Einordnung die-

19 2.3 Einsatzgebiet des Domain Models 11 ser Arbeit zu Standpunkt 2. Im Fokus stehen die den Prozess der Anforderungsanalyse begleitenden und unterstützenden Domain Models, die den Ansprüchen einer formalen UML-Notation entsprechen und überdies auch noch konsistent zu den erhobenen Anforderungen in Form von Use Cases sind. Nach Heide Balzert ([Bal05]) ist es dabei wichtig, dass das Domain Model als Teil der in der objektorientierten Anforderungsphase (OOA) erhobenen OOA-Modelle klar vom späteren Klassendiagramm (aus der Entwurfsphase) abgegrenzt wird. Dies begründet sie mit der Perspektive, aus der das Modell betrachtet wird. So sei ein Domain Model ein Modell des Problembereichs, wohingegen ein Klassendiagramm das Modell eines Lösungsraums sei. Auch würden sich beide Modelle in ihrer Beziehung zur Effizienz unterscheiden. Beim Domain Model spielt nach Heide Balzert die Effizienz keine Rolle. Hier soll lediglich das System aus Sicht des Nutzers modelliert werden. Ganz anders beim Klassendiagramm, bei dem die Effizienz oberstes Ziel ist. Der Übergang von der Anforderung zum Entwurf sei dabei aber kein Paradigmenwechsel, sondern ein Prozess des Erweiterns und Präzisierens. Domain Model vs. Agile Software-Entwicklung Neben dem traditionellen Software-Entwurf hat sich gerade in den letzten Jahren eine zweite große Bewegung entwickelt. Diese verfolgt einen komplett neuen und dem traditionellen, konträr gegenüberstehenden Ansatz für den Prozess der Software-Entwicklung. In einem agilen Softwareprojekt wird auf die beim traditionellen Verfahren als Overhead bemängelte Dokumentation weitestgehend verzichtet. Die Anforderungen der Kunden werden ohne die Erstellung einer umfangreichen Anforderungsspezifikation direkt implementiert. Dabei werden die Anforderungen nicht als großes Ganzes gesehen. Vielmehr wird jede einzelne Anforderung für sich betrachtet und die bereits umgesetzten Teile der Software soweit angepasst, dass die betrachtete Anforderung erfüllt ist. Das aus der Umsetzung resultierende Feedback des Kunden wird dabei als eines der wichtigsten Elemente zur Erreichung eines dem Kundenwunsch zu 100 Prozent entsprechenden Ergebnisses gesehen. Durch den Wegfall der Dokumentation fällt auch die Existenzberechtigung eines Domain Models, wie in Szenario 2 beschrieben, weg. Da es keine langfristig festgehaltenen Dokumentationen gibt, gibt es auch keinen Bedarf mehr für ein formales und langfristig gespeichertes Domain Model. Lediglich eine Ausweitung des in Szenario 1 beschriebenen, explorativen Einsatzes des Domain Models in den Iterationsschritten des agilen Prozesses wäre denkbar. Hier könnte es zur Erschließung der sich, auf Grund der fehlenden Planungsphase, erst langsam, von Iteration zu Iteration, mit den immer wieder neu geäußerten Anforderungen, öffnenden Domäne angewandt werden. Aber auch hier findet keine dauerhafte Fixierung des Modells statt. Das so erstellte Modell wird meist nur für die Dauer seiner Relevanz innerhalb der aktuellen Iteration in Form einer Skizze an die Wand gemalt und später wieder entfernt.

20 12 Domain Models 2.4 Nutzergruppen des Domain Models Nun stellt sich die Frage: Wer nutzt Domain Models überhaupt? Aus den zwei Szenarien ergeben sich besonders drei Rollen innerhalb der Software-Entwicklung, die zu betrachten sind. Sie verkörpern die Hauptrollen in den für diese Arbeit relevanten Phasen der Software-Entwicklung (Requirement Engineering und Entwurf). Entsprechend des ersten Szenarios ist der Domain-Analytiker zu nennen. Er fungiert als Speerspitze des Requirement Teams und wagt sich in die unbekannte Domäne. Er arbeitet sich mit dem Domain Model in die Beschaffenheiten und Eigenarten des neu zu erschließenden Gebietes ein und dient im weiteren Entwicklungsprozess als Vermittler und Übersetzer zwischen Kunde und Softwareunternehmen. Dem Domain-Analytiker folgen die Requirement Engineers. Sie profitieren zwar von den Errungenschaften des Domain-Analytikers, haben aber mit der Anwendung des Domain Models, wie in Szenario 1 beschrieben, nichts zu tun. Bei ihnen liegt der Fokus auf den Anforderungen, deren Umsetzung und damit verbunden der adäquaten Dokumentation selbiger (Szenario 2). Nach Abschluss der Requirement-Phase folgt in der klassischen Software-Entwicklung der Entwurf, in dem unter anderem der Software-Architekt agiert. Er blickt zurück auf das abgeschlossene Dokument mit all den Anforderungen der Anforderungsphase. Für ihn dient das Domain Model nach Szenario 2 als Ausgangspunkt für die Durchführung des Entwurfs. 2.5 Die Konsistenzproblematik Die Wahrung von Konsistenz innerhalb der Software-Entwicklung ist ein weitverbreitetes Problem, besonders im Bereich der Anforderungserhebung. In den seltensten Fällen gelingt eine vollständige Lösung des Problems, denn oft kann der Aufwand, der für die Beseitigung der Inkonsistenzen notwendig ist, nicht ins Verhältnis zum Mehrwert gesetzt werden. Trotzdem sollte ein nicht zu geringer Aufwand in eine bestmögliche Beseitigung von Inkonsistenzen investiert werden. In allen anderen Fällen sollten zumindest Hinweise den Leser des Dokumentes über das Vorhandensein von Konsistenzproblemen informieren. Im Allgemeinen können Inkonsistenzen als Ursache und Hinweis auf mögliche Missverständnisse bei der Interpretation und Erfassung von Anforderungen gesehen werden. Diese Missverständnisse äußern sich in Form von Lücken in den Anforderungen, oder noch verheerender, als Fehldeutungen. Diese Fehler in der Anforderungserhebung ziehen sich wie ein roter Faden durch alle anschließenden Phasen des Projektes und führen in aller Regel von Phase zu Phase zu einer Verschärfung und somit einem erheblichen Mehraufwand für ihre Beseitigung. Schlussendlich resultieren sie oft in einer fehlerhaften

21 2.5 Die Konsistenzproblematik 13 Implementierung mit falschen Realisierungen und erheblichen Lücken im Funktionsumfang. Ganz allgemein gilt in der Software-Entwicklung: Je später ein Fehler auftritt, desto höher sind die Kosten für seine Beseitigung. Dabei geht man von einem exponentiellen Wachstum der Kosten über die Zeit aus (Abbildung 2.2). Relative Fehlerbehebungskosten Codierungsfehler Entwurfsfehler Anforderungsfehler Review der Anforderungen Review des Entwurfs Code Review Strukturtest Funktionstest Entdeckungszeitpunkt des Fehlers Abbildung 2.2: Relative Fehlerkosten über die Latenzzeit aus [Mey07] nach [FLS91] Betrachtet man erneut die zwei Szenarien aus Abschnitt 2.3, so stellt man fest, dass es mehrere Adressaten für die Konsistenz gibt. Im ersten Szenario ist lediglich die Konsistenz zum Original, in diesem Fall der Domäne, zu wahren. Der Modellierer muss beachten, dass sein Modell möglichst nahe an die abzubildende Realität kommt. Diese Konsistenzprämisse ergibt sich schon alleine aus der Intention, die hinter dem Einsatz einer Modellierungssprache steht. Abgesehen von der geforderten Konsistenz zum abgebildeten Original gibt es beim Einstieg in eine Domäne noch keine weiteren Elemente, zu denen irgendeine Form von Konsistenz zu wahren ist. Somit bleibt nur noch die konsistente Darstellung des Domain Models zu sich selbst und zur verwendeten Notation zu beachten. Hier ist zu berücksichtigen, dass die modellierten Elemente sich nicht widersprechen oder bei der Modellierung gegen Auflagen der verwendeten Notation verstoßen wird. Domain Model vs. Use Cases Für den Einsatz von Domain Models nach Szenario 2 gibt es neben den bereits beschriebenen drei Konsistenzadressaten noch einen weiteren. Da in einem Anforderungsdokument Domain Models nur eine untergeordnete Rolle spielen und das Dokument noch

22 14 Domain Models weitere Modelle beinhaltet, ist hier die Konsistenz zum gesamten Dokument zu wahren, besonders gegenüber den Use Cases, die einen erheblichen Anteil am Umfang des Dokumentes ausmachen, sobald sie als Mittel der Anforderungsdokumentation genutzt werden. Oldfield ([Old02]) beschreibt Domain Models als Modelle des Raums, in dem eine Firma agiert. Dabei sei es wichtig, dass diese für verschiedene Firmen im gleichen Businessbereich inhaltlich identisch sind, somit also unabhängig von den Firmen, für die sie modelliert werden. Nach Meinung des Autors sind die im Domain Model enthaltenen Entitäten meist recht konstant und ändern sich nur selten. Somit sei eine dem Modell entsprechende Programmaufteilung sehr flexibel für Änderung, da das Grundgerüst tief in der Domäne verankert ist. Dies hat zur Folge, dass Domain Models in anderen Projekten derselben Domäne erneut genutzt werden können und so der Aufwand für ihre Erstellung auf ein Minimum reduziert wird. Jedoch kann es so passieren, dass nicht alle Entitäten für das neue Projekt relevant sind und somit kein Gegenüber in den aktuellen Use Cases zu finden ist. Abbildung 2.3 zeigt die Überdeckung bezüglich des behandelten Inhaltes. In der Grafik links wurde das Domain Model allein für das zu realisierende Projekt entworfen. Wie man sieht, stimmen die Inhalte größtenteils überein. Dies begründet sich aus der Tatsache, dass man in diesem Domain Model nur die für die Umsetzung relevanten Elemente der Domäne betrachtet. Wenn man so will, stellt dieses Domain Model nur einen Ausschnitt aus dem tatsächlichen, das gesamte Geschäftsfeld abdeckenden Modell dar. Die Grafik rechts zeigt ein Domain Model, das nicht speziell für ein Projekt entworfen wurde und mindestens einmal wiederverwertet wurde. Wie man sieht, ist es größer als das linke und die Use Cases der einzelnen Projekte decken nicht mal annähernd den vollständigen Inhalt des Modells ab. Somit ist neben der Zuordnung der einzelnen Use Abbildung 2.3: Links: Domain Model erstellt für ein einzelnes Projekt Rechts: Wiederverwendung eines Domain Model in mehreren Projekte

23 2.5 Die Konsistenzproblematik 15 Cases zu den Elementen im Domain Model, wie in der Grafik links, noch zusätzlich zu klären, ob ein Element des Domain Models überhaupt für das aktuelle Projekt relevant ist. Für die Darstellung von Use Cases (auch Anwendungsfälle genannt) gibt es diverse Formen, die von einem knappen, frei formulierten Prosatext bis hin zu einem ausführlichen und strikt reglementierten Formular reichen. Im Bereich des Software Engineerings der Leibniz Universität hat sich die tabellarische Darstellung bewährt. Diese folgt einer vom Fachbereich bereitgestellten Vorlage (Tabelle 2.2), die jedoch je nach Einsatzgebiet und Schwerpunkt des zu realisierenden Projektes angepasst werden kann. Use Case Nr. <ID> Erläuterung <Titel des Use Cases> <Ausführlichere Beschreibung des Use Cases> Autor <Ersteller des Use Cases> Systemgrenzen <Zu betrachtende Systemkomponenten> Ebene {Überblick, Hauptziel, Unterfunktion} Vorbedingung <Zustand, der zur Durchführung des Use Cases erfüllt sein muss> Mindestgarantie <Zustand, der unabhängig vom Erfolg garantiert wird> Erfolgsgarantie <Zustand, der im Erfolgsfall garantiert wird> Stakeholder Stakeholder <Stakeholder> Interessen <Interessen des ersten Stakeholders> Hauptakteur <Rolle oder Person, dessen Ziel mit dem Use Case verfolgt wird> Auslöser <Ereignis, das den Use Case auslöst> Hauptszenario Akteur Aktion <ID> <Akteur> <Durchgeführte Aktion> Erweiterungen Tech. Variationen <ID> <Begründung warum vom Hauptszenario abgewichen wird> Akteur Aktion <ID> <Akteur> <Durchgeführte Aktion> <Technische Abweichungen von der betrachteten Realisierung> Tabelle 2.2: Use Case-Templates nach Cockburn [Coc00] Use Cases werden im Verlauf der Anforderungsanalyse erstellt. Dabei werden die vom Kunden formulierten funktionalen Anforderungen in einzelne Interaktionen des Nutzers mit dem System heruntergebrochen und schrittweise notiert. Bei den hier vorgestell-

24 16 Domain Models ten tabellarischen Use Cases werden des Weiteren noch Fakten wie Vorbedingungen, Garantien und Auslöser festgehalten, welche bei der Umsetzung der Anforderungen zu berücksichtigen sind und von der finalen Implementierung eingehalten werden müssen. Die im Use Case festgehaltenen Interaktionen und Werte dienen am Ende eines Softwareprojektes als Ablaufplan für die Abnahmetests. Somit begleiten sie das entstehende Produkt von der Anforderungsanalyse, über den Entwurf und die Implementierung, bis zur Abnahme durch den Kunden. Durch den hohen Detailgehalt des tabellarischen Use Cases kann es passieren, dass diese nur noch von Fachleuten und somit nicht mehr unbedingt vom Kunden verstanden werden können. Hier hilft das Use Case-Diagramm weiter. Es fasst eine Vielzahl von Use Cases zusammen, abstrahiert diese und zeigt den gesamten Kontext eines Teilsystems. Von den einzelnen Use Cases werden lediglich die Titel, die beteiligten Akteure und die Verknüpfungen mit benachbarten Use Cases übernommen. So erlaubt das Diagramm ein schnelles Verständnis bezüglich des Zusammenwirkens der einzelnen Use Cases und der daran beteiligten Akteure. Ordnet man Use Cases und Domain Model in das Drei-Schichten-Modell (nach [DH03]) ein, so gehören zwar beide Modelle zur 2. Schicht, der Anwendungsschicht, jedoch verkörpern die Use Cases Geschäftsprozessklassen und das Domain Model Entitätsklassen. Dies begründet sich vor allem durch den beschriebenen Inhalt. Zwar beinhalten auch Use Cases Entitätsklassen, deklarieren diese allerdings nicht eindeutig. Während Use Cases dynamische Abläufe zwischen verschiedenen Objekten modellieren, repräsentiert das Domain Model die statischen Zusammenhänge dieser Objekte. Somit ergibt sich bei der Überprüfung beider Modelle ein Zuordnungsproblem zwischen den Objekten, welche die Use Cases nutzen, und denen, die das Domain Model strukturiert. Anders als die Domain Models gehören Use Cases zu den dynamischen Modellen. Sie geben an, wie ein Akteur zu seinem Ziel kommt und welche Schritte er hierzu befolgen muss. Trotz dieses grundlegenden Unterschiedes muss eine gewisse Konsistenz zwischen beiden Modellen vorhanden sein. In einem Use Case sollten nur Objekte genutzt werden, die im Domain Model enthalten sind und dabei nur Aktionen ausgeführt werden, die diese Objekte nach dem Domain Model beherrschen. Use Cases zeigen somit gewissermaßen, wie die Entitäten des Domain Models unter Verwendung ihrer Fähigkeiten miteinander interagieren. Definition 2.8: Konsistenz zwischen Use Case und Domain Model Use Cases und Domain Model sind zueinander konsistent, wenn gilt: Alle erwähnten Entitäten im Use Case sind im Domain Model modelliert und alle ausgeführten Aktionen entsprechen einer Fähigkeit der Entität im Domain Model. Umgekehrt muss nicht jede Entität oder Fähigkeit aus dem Domain Model im Use Case vorkommen.

25 2.5 Die Konsistenzproblematik 17 Konsistenzprüfung vs. Agil Modeling Agil Modeling ist ein Ansatz, der auf Scott W. Ambler zurückgeht ([Amb02]). Dabei nutzt man Modelle, die gerade noch gut sind, das heißt man nutzt sie trotz bekannter Mängel. Die Modelle werden erst dann aktualisiert, wenn die Mängel nicht mehr ertragbar sind ( Only when it hurts ). Für die Konsistenz zwischen Use Cases und Domain Model würde dieser Ansatz bedeuten, dass man die Modelle, trotz bekannter Inkonsistenzen, solange für nutzbar hält, bis die Konsistenz als nicht mehr ausreichend betrachtet wird. Hieraus stellt sich die Frage: Wann oder wie lange sind zwei oder mehr Modelle ausreichend konsistent zueinander? Ambler beantwortet diese Frage in seinem Buch [Amb02] mit der Aussage, dass Inkonsistenzen, die zu keinen Folgeproblemen führen, tragbar sind und man nur dann Energie in ihre Behebung stecken sollte, wenn dies einen Nutzen nach sich zieht. Eine derartige Wertung zwischen gerade noch tragbar und nicht mehr tragbar kommt einem Balanceakt gleich, zudem hängt das Ergebnis dieser Bewertung stark von der Person und deren Hintergrund, mit dem sie das Problem betrachtet, ab. Daher kann die hier realisierte Konsistenzprüfung lediglich als Hinweisgeber auf Inkonsistenzen gesehen werden. Die Entscheidung, ob diese relevant sind oder nicht, also ob sie behoben werden müssen oder nicht, liegt weiterhin beim Anwender. Für die definierte Konsistenz bedeutet dies, dass sie weiterhin Bestand hat. Fraglich ist nur, ob sie je erreicht wird beziehungsweise erreicht werden soll oder muss. Ein weiteres Argument für die aktive Konsistenzprüfung ist die Annahme, dass Inkonsistenzen als Hinweise auf noch nicht, oder zumindest fehlerhaft erschlossene Anforderungen gesehen werden können. In dem Moment, in dem sich eine Inkonsistenz aufzeigt, kann man oft daraus schlussfolgern, dass in diesem Bereich noch unklare beziehungsweise vage formulierte Anforderungen vorhanden sind. Würden diese Anforderungen in die Dokumentation aufgenommen, könnten diese später in der Realisierung zu Lücken in der Implementierung führen. Somit würde eine unterlassene Konsistenzsicherung frei nach dem Motto: Solange es nicht knallt ist alles in Butter! zwar nicht unbedingt zum Scheiten des Projektes führen, jedoch wäre die Gefahr hoch, dass wichtige Anforderungen unentdeckt und somit auch unberücksichtigt blieben. Glinz beschreibt in seiner Abhandlung über die Konsistenzsicherung zwischen Use Cases und Klassendiagrammen ([Gli00]) Regeln, die beim Klassendiagramm und den zugrunde liegenden Use Cases eingehalten werden müssen. Wegen der bereits beschriebenen Affinität zwischen Domain Models und dem Klassendiagramm können diese auch auf Domain Models angewandt werden. So sollte jeder Auslöser eines Szenarios im Use Case einer Fähigkeit im Domain Model zugeordnet sein, die das entsprechende Ergebnis des Szenarios erzeugt. Werden für die Ausführung des Szenarios weitere Daten benötigt, so müssen auch diese im Domain Model vorhanden sein.

26 18 Domain Models Problemfall natürliche Sprache Ein großes Problem bei der Konsistenzsicherung zwischen dem formalen Domain Model in den eher informell gehaltenen Use Cases ist die natürliche Sprache, in der die meisten Use Cases festgehalten werden. Was auf der einen Seite als Vorteil in Bezug auf die Verständlichkeit, gerade mit Sicht auf den technisch unversierten Kunden, bezeichnet werden kann, erschwert auf der anderen Seite eine formale Prüfung der Konsistenz. So kann bereits die Nutzung von Synonymen den Aufwand bei der maschinellen Auswertung erheblich erhöhen. Auf Seiten der Domain Models erschwert die Möglichkeit, dass semantisch identische Modelle syntaktische Unterschiede aufweisen können, eine einfache Überprüfung. Doch durch den hohen Grad an Formalität ist diese Hürde nicht unüberwindbar. Realisierung der Konsistenzsicherung Eine Möglichkeit zur Konsistenzsicherung ist bereits im Umfang der UML-Notation enthalten. So erlaubt die Object Constraint Language (OCL) die Definition von Konsistenzbedingungen innerhalb des Domain Models mit Hilfe der Prädikatenlogik. Jedoch beziehen sich diese Contraints auf Bedingungen, die durch die Implementierung der jeweiligen Entität erfüllt sein müssen, und nicht auf den Prozess der Modellierung. Hinzu kommt die Tatsache, dass nur wenige Requirement Engineers in der Lage sind, Bedingungen in OCL zu formulieren. Somit ist die OCL für das hier diskutierte Vorhaben der Konsistenzsicherung bei der Modellierung von Anforderungen durch Domain Models und Use Cases nicht ausreichend. Als drittes Argument gegen eine Nutzung der OCL spricht die fehlende Distanz zum Modell. Die Bedingungen der OCL werden im Modell aufgeführt, während die Konsistenzprüfung, wie sie in HeRA implementiert ist, eine modellunabhängige Instanz darstellt. Wie dieses Kapitel zeigt, gibt es zwischen den geforderten Eigenschaften an die Notation des Domain Models und der Notation des UML-Klassendiagramms eine große Überschneidung. Somit liegt eine Realisierung in Form eines entsprechenden Editors zur Modellierung von Domain Models nahe. Dieser wird, zusammen mit einer ausführlichen Betrachtung der Notation, in Kapitel 3 beschrieben. Ein weiterer Schwerpunkt dieser Arbeit ist es, neben der Erstellung eines Editors auch die Realisierbarkeit einer automatisierten Konsistenzprüfung unter Zuhilfenahme heuristischer Kritiken zu ergründen. Eine genauere Ausführung dieser Realisierung findet sich in Kapitel 4.

27 19 3 Domain Model-Erweiterung für HeRA Dieses Kapitel beschäftigt sich mit dem Konzept und der Implementierung einer Erweiterung des Use Case gestützten Anforderungseditors HeRA zur Erstellung und Verwaltung von Domain Models. Diese stellt dabei eine zunächst unabhängige neue Komponente dar, die erst im Kapitel 4 mit der bestehenden Use Case-Einheit verknüpft und beide mit Hilfe der HeRA typischen Kritiken einer Konsistenzsicherung unterzogen werden. Im ersten Teil des Kapitels werden die für die Realisierung des Editors wichtigsten Konzepte und die Struktur des Programms HeRA erläutert. In Abschnitt 3.2 und Abschnitt 3.3 wird zunächst die dem Editor zugrunde liegende Notation auf Basis des UML-Klassendiagramms erläutert, bevor abschließend dann eine genauere Betrachtung des erstellten Domain Model-Editors mit seinen Funktionen stattfindet. 3.1 Einführung in HeRA Der Heuristic Requirements Assistant, kurz HeRA 1, ist ein Programm, das am Fachgebiet Software Engineering der Leibniz Universität Hannover zur Unterstützung des Requirement Engineering entwickelt wurde. Das von Knauss entwickelte und betreute Programm bietet in seiner Basisversion einen Editor zur heuristisch gestützten Aufnahme und Verwaltung von Use Cases ([KF07], [KLM09]). Die Use Cases folgen dabei der von Cockburn [Coc00] vorgeschlagenen Form. Durch die modulare Architektur erlaubt HeRA neben den im Requirement Engineering oft verwendeten Use Cases auch die Integration weiterer Funktionen. Dies führte dazu, dass im Laufe der Zeit, im Zusammenhang mit wissenschaftlichen Arbeiten, eine Handvoll Erweiterungen, unter anderem zur Verwaltung eines projektbegleitenden Glossars [Mey07] oder zur Erzeugung von EPK-Modellen [KL08], entstanden sind. Sie haben HeRA zu einem umfangreichen Programm zur Unterstützung des gesamten Prozesses rund um die Entstehung von Software gemacht. Auch für diese Arbeit bildet HeRA die Basis für die konzeptionelle Implementierung und Validierung des entwickelten Konzeptes eines heuristisch unterstützen Editors für Domain Models. Das projektbegleitende Glossar dient dabei zur Minimierung von Mehrdeutigkeit, die durch die Zusammenarbeit von Personen aus verschiedenen Bereichen entstehen können. So besteht bei der gemeinsamen Bearbeitung der Anforderungen die Gefahr, dass einige der beteiligten Personen, begründet durch ihren beruflichen Hintergrund, demselben Begriff unterschiedliche Bedeutungen zuordnen und es so zu Missverständnissen bis hin zu fehlerhaften Anforderungen kommt. 1 https://trac.se.uni-hannover.de/trac/hera

28 20 Domain Model-Erweiterung für HeRA Die Arbeit [KMS08] zeigt, dass eine Aufnahme derartiger Begriffe in ein Glossar, ergänzt um eine eindeutige Definition, zusammen mit einer deutlichen Kennzeichnung der Begriffe im bearbeiteten Dokument zu einer erheblichen Verbesserung der Qualität des Dokumentes geführt hat. Ein möglicher Einsatz dieser Glossar-Erweiterung bei der Konsistenzsicherung wird in Kapitel 4 erläutert. Abbildung 3.1: Grafische Oberfläche von HeRA Die grafische Oberfläche (Abbildung 3.1) von HeRA basiert auf der DODE-Architektur von Fischer [Fis94], in der fünf Komponenten unterschieden werden. Diese fünf Komponenten wurden bis auf die Spezifikationskomponente und die Katalogkomponente in der bestehenden Version von HeRA realisiert. Beide entsprechen, wie in der Arbeit von Knauss [Kna10, Kapitel 3] argumentiert, nicht den Erfordernissen der Anforderungserhebung. Gegen die Notwendigkeit einer Umsetzung der Spezifikationskomponente spricht die fehlende Vergleichsmöglichkeit. Und da es, mit Ausnahme von Software- Produktlinien, in normalen Softwareprojekten keinen großen Bedarf für die Wiederverwendung von Anforderungen gibt, gibt es bisher auch keinen Grund für die Umsetzung der Katalogkomponenten. Die verbleibenden drei Komponenten sind zum Teil in weitere Segmente unterteilt, sodass sich HeRA in fünf Bereiche einteilen lässt, die im Folgenden der DODE-Architektur zugeordnet und eingehender betrachtet werden sollen.

29 3.1 Einführung in HeRA 21 Konstruktionskomponente Die Konstruktionskomponente stellt nach Fischer den Mittelpunkt eines Programmes dar, in der sein Anwender die Hauptarbeit verrichtet. In HeRA ist diese Komponente in zwei Segmente unterteilt. Der an der linken Seite angeordnete Projektbaum beinhaltet die zum aktuell geöffneten Projekt gehörenden Objekte. In der Basisversion sind dies die einzelnen Use Cases. Hier lassen sich neue Objekte anlegen und bestehende entfernen. Beinhaltet ein Objekt Fehler, so werden diese durch eine Markierung des entsprechenden Elementes hervorgehoben. Die mit dem Prototypen erzeugten Domain Models werden ebenfalls im Projektbaum eingegliedert und verwaltet. Im Fokus des Programmes steht der Eingabebereich für das im Projektbaum ausgewählte Objekt. Je nach Objekttyp erscheint hier eine Eingabemaske zur Vervollständigung und Bearbeitung. In diesem Bereich kann der Anwender später auch die Domain Models erzeugen und verändern. Argumentationskomponente In dieser Komponente werden dem Benutzer Rückmeldungen zu den aktuellen Arbeitsschritten gegeben. Wie die Konstruktions-, ist auch die Argumentationskomponente in zwei Segmente (Problemsicht und Assistentsbereich) unterteilt. Die Problemsicht zeigt dem Anwender eine Übersicht über die fehlerhaften Bereiche im Projekt. Neben dem Namen des betroffenen Use Cases wird hier eine kurze Problembeschreibung wiedergeben sowie das Attribut, in dem das Problem auftritt. Je nach Feld der Eingabemaske, das gerade durch den Anwender bearbeitet wird, werden im Assistenzbereich Hinweise, Warnungen und Fehler zur gegenwärtigen Eingabe angezeigt. Dies geschieht in Echtzeit, währende der Benutzer noch mit der Ausfüllung der Felder beschäftigt ist. Somit kann der Benutzer entscheiden, ob er den Fehler umgehend behebt oder vorerst mit der Eingabe fortfährt. Die gezeigten Feedbacks beruhen auf Erfahrungen, die in Form von heuristischen Kritiken in HeRA gespeichert sind und im Verlauf der Verwendung weiter verfeinert werden. Dabei sollen sie unter anderem helfen, Mehrdeutigkeiten, entstehend durch sogenannte Weak Words, zu vermeiden. Empfindet ein Anwender eine Kritik als unpassend, so hat der die Wahl, ob die Kritik nur für den aktuellen Use Case, das betroffene Feld in allen Use Cases oder für immer ignoriert werden soll. Das Kritiksystem von HeRA kommt auch im erstellten Prototypen zum Einsatz und wird in Kapitel 4 noch detaillierter betrachtet.

30 22 Domain Model-Erweiterung für HeRA Neben den Hinweisen zum bearbeiteten Use Case werden dem Nutzer im Assistenzbereich auch Begriffe zur Aufnahme ins Glossar vorgeschlagen. Auch hier kommen heuristische Regeln zum Einsatz, die die Begriffe nach Häufigkeit ordnen und unerwünschte anhand von Filtern unterdrücken. Eine entsprechende Vorschlagskomponente für Entitäten wird in Abschnitt 5.1 beschrieben. Simulationskomponente In der Simulationskomponente sollen die erhobenen Werte weiterverarbeitet und so dem Benutzer ein direktes Feedback über die Güte seiner Arbeit gegeben werden. Die Ableitung des Feedbacks geschieht dabei parallel zum entstehenden Dokument und spiegelt jederzeit dessen aktuellen Stand wieder. In HeRA zeigt der Simulationsbereich den für das geöffnete Use Case relevanten Ausschnitt aus dem Use Case-Diagramm des gesamten Projektes. Somit bekommt der Nutzer einen Eindruck über die beteiligten Akteure und die gegebenenfalls involvierten Use Cases, die im gegenwärtig bearbeiteten Use Case eingebunden sind. Auch wird hier das aus den Use Cases abgeleitete EPK-Modell zur Verdeutlichung des zugrunde liegenden Geschäftsprozesses und die mittels Use Case Point erhobenen Aufwandsschätzungen präsentiert. Im Gegensatz zu den zwei erwähnten grafischen Modellen wird der Editor zur Erstellung der Domain Models nicht im Simulationsbereich untergebracht sein, sondern Teil des Eingabebereichs sein. Dies begründet sich mit der Tatsache, dass sich das Domain Model nicht als Feedback, sondern als eigenständiges Modell in den Requirements-Prozess eingliedert. Spezifikationskomponente Fischer sieht in dieser Komponente den Vergleich zwischen erarbeiteter Spezifikation und dem erstellten Entwurf zur Sicherung der Symmetrie beider Dokumente vor. Da HeRA jedoch als unterstützendes Programm zur Erstellung der Anforderungen konzipiert ist, die nur einen Teil der Spezifikation ausmachen und vor dem Entwurf realisiert werden, fällt hier der Vergleichsrahmen weg. Durch das Hinzufügen der Domain Models wird die Frage zu klären sein, in wie weit Domain Models den späteren Entwurf repräsentieren und ob so gegebenenfalls nicht die Konsistenzprüfung zwischen Use Case und Domain Model die von Fischer geforderte Spezifikationskomponente darstellt.

31 3.2 Relevante UML-Elemente 23 Katalogkomponente Wie zu Beginn dieses Abschnittes erwähnt, findet die Katalogkomponente in HeRA auf Grund der fehlenden Erfordernisse bisher keinerlei Verwendung. Fischer sieht in dieser Komponente die Möglichkeit, den Nutzer durch die Bereitstellung von Beispielen und Vorlagen bei seiner Arbeit zu unterstützen. Entsprechend wird in Abschnitt 5.2 eine Realisierung dieser Komponente in Form eines Kataloges für vorgefertigte Analysemuster beschrieben. Diese kann vom Nutzer durchsucht werden. Entspricht ein Muster den Erfordernissen, kann es in das aktuelle Modell übernommen werden. 3.2 Relevante UML-Elemente Bevor in Abschnitt 3.3 die Umsetzung des Domain Model-Editor erklärt wird, ordnet dieser Abschnitt zunächst die einzelnen Elemente der Notation des UML-Klassendiagramms ein und bewertet deren Relevanz für die Modellierung eines Domain Model. Die Einordnung geschieht dabei unter Zuhilfenahme der Werke von Oestreich [Oes09] und Kecher [Kec06] und basiert auf UML 2.3. Definition 3.1: Unified Modeling Language (kurz UML) Notation zur grafischen Darstellung objektorientierter Konzepte (objektorientierte Software-Entwicklung). Zur grafischen Darstellung gehören unter anderem Klassendiagramme[, Use Case-Diagramme] und Objektdiagramme. Die UML wurde [..] 1997 von der OMG (Object Management Group) als Standard verabschiedet. nach Helmut Balzert [Bal09, S. 601] Die UML ist ein weit verbreitetes Werkzeug in der Software-Entwicklung und findet in nahezu jeder Etappe des Entwicklungsprozesses Anwendung, beginnend bei der Anforderungsanalyse bis hin zur Dokumentation der Implementierung. Sie dient dabei zur visuellen Darstellung der erhobenen Fakten und als Kommunikationsgrundlage zwischen den beteiligten Disziplinen. Die von UML unterstützten Diagrammtypen lassen sich grob in zwei Gruppen einteilen. Zum einen gibt es die dynamischen Modelle zur Beschreibung ablaufender Prozesse. Sie besitzen einen Ausgangspunkt und einen zu erreichenden, definierten Endpunkt. Hierzu gehören Diagramme wie das Aktivitäts- oder das Zustandsdiagramm. Die zweite Gruppe beschreibt die statischen Modelle, welche die Strukturen eines Systems festhalten. Zu dieser Gruppe gehören die für diese Arbeit relevanten Klassendiagramme und somit auch die daraus abgeleiteten Domain Models.

32 24 Domain Model-Erweiterung für HeRA Definition 3.2: Klassendiagramm (engl.: Class Diagram) Stellt die objektorientierten Konzepte Klasse, Attribute, Operationen und Beziehungen (Vererbung, Assoziation) zwischen Klassen in grafischer Form dar (UML). nach Helmut Balzert [Bal09, S. 594] Mit Hilfe von Klassendiagrammen lassen sich sowohl die für die Implementierung einer Software nötigen Klassen, mit den enthaltenen Attributen und Operationen, als auch die Beziehungen unter den Klassen darstellen. Die Beziehungen zwischen den einzelnen Klassen werden mittels Assoziationen verdeutlicht. Kardinalitäten geben dabei an, wie viele Instanzen einer Klasse an der Beziehung beteiligt sein können oder gar müssen. Auch Vererbungen sind im Klassendiagramm mittels Generalisierung zulässig und erlauben es somit, anzugeben, welche Elternklasse ihre Attribute und Operationen an welche Kinderklassen weitergibt. Dabei unterstützt das Klassendiagramm laut UML, wie die meisten objektorientierten Programmiersprachen, die einfache Vererbung, und darüber hinaus auch die Mehrfachvererbungen, sprich die Vererbung der Eigenschaften und Fähigkeiten von mehr als einer Oberklasse an die jeweilige Kinderklasse. Bei der Umsetzung der Domain Model-Erweiterung für HeRA folgt diese Arbeit dem gängigen Ansatz und nutzt die aus den Klassendiagrammen bekannte Notation zur Darstellung der Entitäten, ihrer Eigenschaften (Attribute) und Fähigkeiten (Operationen) sowie der möglichen Beziehungen zwischen einander. Bezüglich der Notation wird HeRA mit Abschluss dieser Arbeit in der Lage sein, sowohl Domain Models als auch (mit kleinen Einschränkungen) Klassendiagramme darzustellen. Die Reichweite der entwickelten heuristischen Unterstützung für Domain Models bleibt jedoch zu überprüfen. Zunächst sollen kurz die einzelnen Objekte der UML-2-Notation für Klassendiagramme betrachtet und ihre Funktion innerhalb des Domain Models erläutert werden. Definition 3.3: Klasse Eine Klasse ist eine Definition der Attribute, Operationen und der Semantik für eine Menge von Objekten. Alle Objekte einer Klasse entsprechen dieser Definition. Klassenname Attribut Attribut Operation Operation nach Oestereich [Oes09, S. 274] Klassen werden im Klassendiagramm als Rechtecke dargestellt. Je nach Detaillierungsgrad werden neben dem Klassennamen noch die in der Klasse enthaltenen Attribute und Operationen aufgelistet. Der Klassenname wird in der Regel fettgedruckt und zentriert. Horizontale Linien separieren Klassenname, Attribute und Operationen. Klassen beschreiben die Hauptobjekte in einem Klassendiagramm und repräsentieren die am abgebildeten System teilnehmenden Personen oder Objekte mitsamt ihrer Eigenschaften und ihrer Fähigkeiten. Die im Anschluss beschriebenen Verbindungen geben

33 3.2 Relevante UML-Elemente 25 dem Leser Hinweise auf die Art der Beziehung, in der die zwei Klassen zueinander stehen. So kann eine Klasse die Fähigkeiten einer anderen zur Bewältigung einer Aufgabe nutzen, durch Vererbung als Kinderklasse deklariert werden oder sogar ein Teil der anderen sein. Klassen entsprechen bei der späteren Implementierung des Systems den Bauplänen der zu erstellenden Objekte inklusive der für die Datenhaltung relevanten Variablen und der Operationen für die Datenbearbeitung. Interne Zählervariablen oder kleinere Hilfsmethoden, die für das Verständnis der Klasse und ihren Stellenwert im Gesamtsystem der Klassen irrelevant sind, werden nicht aufgeführt. Im Domain Model nutzt man ebenfalls das Klassensymbol, jedoch dient es hier vor allem der Darstellung in der Domäne vorhandener Entitäten und ist so nicht unmittelbar mit den späteren Objekten in der Implementierungsphase verknüpft. In der Regel sind hierfür noch einige Iterationsschritte zur Verfeinerung des Inhalts und zur Festlegung der für die Umsetzung relevanten Einheiten und ihrer Beziehungen von Nöten. Diese noch ausstehenden Iterationsschritte begründen auch das häufige Weglassen von Modifier, Typendeklaration, Parameter und des Rückgabewertes. Da das Domain Model weniger formal gehalten ist als ein Klassendiagramm, sind diese Angaben nicht zwingend erforderlich. Oft reicht die Angabe eines eindeutigen Namens. Wie Klassen können auch Entitäten durch das Hinzufügen von Stereotypen typisiert werden. So lassen sie sich zum Beispiel als Interface oder Enumeration deklarieren. Die Stereotypen werden oberhalb des Entitätsnamens eingefügt und sind durch je ein Guillemet am Anfang des Wortes («) und einem am Ende (») gekennzeichnet. Eine Liste möglicher Stereotypen findet sich im Buch [Oes09] auf Seite 296. Eine weitere Art der Typisierung ist die Kennzeichnung einer Klasse als abstrakt. Hierbei handelt es sich um keinen Stereotypen, sondern um eine Eigenschaft der Klasse. Gekennzeichnet sind derartige Klassen durch den Begriff {abstract}. Bei der Darstellung der abstrakten Klasse weicht der Editor aus Gründen der besseren Übersicht und der Einheitlichkeit von der UML-Notation ab und führt die entsprechende Typisierung wie bei den Stereotypen oberhalb des Entitätsnamens auf, anstatt darunter, wie es die UML- Notation vorsieht. Auf die Kursivschreibung des Entitätsnamens wird aus Gründen der Lesbarkeit verzichtet. Nachdem nun die Darstellung der Entitäten mittels Klassensymbol betrachtet wurde, soll im Folgenden auf die möglichen Referenzen zwischen Entitäten eingegangen werden.

34 26 Domain Model-Erweiterung für HeRA Definition 3.4: Generalisierung Die Generalisierung (engl. Generalization) modelliert eine Beziehung zwischen einer spezifischen Subklasse und einer allgemeinen Superklasse und definiert damit eines der zentralen Konzepte der Objektorientierung. Eine Subklasse kann bei der Spezialisierung automatisch alle Attribute und Operationen ihrer Superklasse verwenden. Sie erbt sozusagen alle Eigenschaften und Fähigkeiten ihrer Superklasse, weshalb man diesen Vorgang in der Objektorientierung auch als Vererbung bezeichnet. nach Kecher [Kec06, S. 75] Eine Generalisierung wird durch einen Pfeil mit unausgefüllter, geschlossener Pfeilspitze dargestellt; die Spitze deutet dabei auf die Superklasse. Je nach angewandter Programmiersprache sind Einfach- oder Mehrfachvererbungen möglich. In beiden Fällen erbt die Subklasse alle Eigenschaften und Fähigkeiten der Superklasse und darf diese erweitern oder sogar verändern. Auch im Domain Model sind Vererbungen denkbar, beispielsweise bei der Modellierung verschiedener Arten von Personen, die in der Domäne auftreten und später vom System verwaltet und/oder unterschieden werden müssen. Assoziationen beschreiben die Verbindung zwischen Klassen. Die einfachste Form ist eine Linie. Sie gibt lediglich an, dass die Klassen in Verbindung stehen und miteinander kommunizieren. Assoziationen sind zwischen beliebig vielen Klassen möglich. Verbindet eine Assoziation lediglich zwei Klassen, so spricht man von einer binären Assoziation. Definition 3.5: Binäre Assoziation Eine binäre Assoziation (engl. Binary Association) spezifiziert eine semantische Beziehung zwischen zwei Klassen. nach Kecher [Kec06, S. 49] Ein besonderer Fall der Assoziation ist die reflektive Assoziation. Hier referenziert eine Klasse sich selbst, was beispielsweise bei der Modellierung einer Eltern-Kind-Beziehung notwendig ist, da hier oft sowohl das Eltern- als auch das Kindobjekt die gleiche Klasse instanziieren. Kardinalitäten oder auch Multiplizitäten geben an, wie viele Objekte der gegenüberliegenden Klasse an der Beziehung beteiligt sind. Sie werden jeweils an die Enden der Assoziation geschrieben und können als Intervall von 0 bis n oder als fester Wert angegeben werden. Intervalle werden in der Form i..j geschrieben, der Wert * steht für beliebig viele Elemente. Ist keine Kardinalität angegeben, so gilt für diese Assoziationsseite eine Kardinalität von 0..*. Tabelle 3.1 zeigt die gängigsten Kardinalitäten.

35 3.2 Relevante UML-Elemente 27 Kardinalität Beschreibung null oder ein Objekt 1 genau ein Objekt 0...* beliebig viele Objekte * beliebig viele Objekte 1..* mindestens ein Objekt bis 13 Objekte Tabelle 3.1: Beispiele für mögliche Kardinalitäten Will man angeben, dass eine Klasse auf eine andere zugreift, die zugegriffene jedoch keine Information über die zugreifende Klasse erhält, so nutzt man eine gerichtete Assoziation. Lässt man das Kreuz weg, so verdeutlicht dies, dass eine Kommunikation in diese Richtung weder eingeschränkt, noch ausdrücklich erforderlich ist. Sollen beiden Klassen auf die jeweils andere navigieren, so kann man die zwei gerichteten Assoziationen zu einem Doppelpfeil zusammenfassen. Definition 3.6: Gerichtete Assoziation Eine gerichtete Assoziation ist eine Assoziation, bei der von der einen beteiligten Assoziationsrolle zur anderen direkt navigiert werden kann, nicht aber umgekehrt. nach Oestereich [Oes09, S. 306] Eine weitere Verfeinerung der Assoziation ist die Aggregation. Sie erlaubt es, zwei Klassen mit einer Ganzes-Teile-Beziehung zu verknüpfen. Dabei gibt die Raute die Klasse an, die dem Ganzen entspricht und die offene Seite die Klasse, die ein Teil des Ganzen ist. Aggregationen sind demnach Assoziationen mit einer semantischen Erweiterung am Kantenende. Definition 3.7: Aggregation Die Aggregation (engl. Aggregation) ist eine spezielle Form der binären Assoziation und beschreibt eine Ganzes-Teile- Beziehung. Aggregationen mit mehr als zwei Enden (n-är) sind nicht definiert. nach Kecher [Kec06, S. 66] Die Komposition verschärft die Ganzes-Teile-Beziehung der Aggregation um die Existenzabhängigkeit. Diese gibt an, dass das Teil mit dem Ganzen erzeugt und auch wieder zerstört wird, also nicht ohne das Ganze bestehen kann. Daher muss hier auf Seiten des Aggregats eine 0-oder-1-Beziehung (0..1) stehen.

36 28 Domain Model-Erweiterung für HeRA Definition 3.8: Komposition Die Komposition (engl. Composition) ist eine starke Form der Aggregation, die ebenfalls eine Ganzes-Teile-Beziehung definiert. Die Verbindung zwischen den Teilen und dem Ganzen wird jedoch als untrennbar definiert. nach Kecher [Kec06, S. 69] Als Beispiel zur Verdeutlichung der Existenzabhängigkeit bei der Komposition können die Beziehungen zwischen einem Gebäude, einem Raum und einem Tisch betrachtet werden. Während der Tisch als Teil eines Raumes, auch ohne den Raum besteht, kann ein Raum nur solange bestehen, wie es auch ein Gebäude gibt. Neben Generalisierung, Assoziation und Aggregation gibt es noch eine vierte Verknüpfung zwischen Entitäten, die Abhängigkeitsbeziehung. Sie gibt an, dass ein Element von einem anderen abhängt. Dabei zeigt der Pfeil von der abhängigen Entität zur unabhängigen. Anwendungen findet die Abhängigkeitsbeziehung beispielsweise bei der Modellierung von Interfaces. Definition 3.9: Abhängigkeitsbeziehung Eine Abhängigkeit (engl. Dependency) signalisiert, dass eine Klasse eine andere für Ihre eigene Spezifikation oder Implementierung benötigt. Sie wird als Client-Supplier-Beziehung bezeichnet (Kunde-Dienstleister) und dient lediglich der Dokumentation. nach Kecher [Kec06, S. 72] Ein Sonderfall der Abhängigkeitsbeziehung ist die Realisierungsbeziehung. Sie stellt die Beziehung zwischen einer Implementierung und ihrem Spezifikationselement dar. Dargestellt wird sie wie die Abhängigkeit, nur mit einer geschlossenen unausgefüllten Pfeilspitze. Ähnlich wie den Klassen, können auch den Abhängigkeitsbeziehungen Stereotypen zugewiesen werden. Diese werden anstelle der Kantenbeschriftung platziert. Zum besseren Verständnis ist es möglich, den Verbindungen Rollen zu geben. Sie werden wie Kardinalitäten an den Enden der Assoziation platziert. Eine weitere Verständnishilfe bietet die Kantenbeschriftung einer Assoziation. Sie gibt die Art der Beziehung an und optional die Leserichtung. Diese Beschriftung ist vergleichbar mit dem Relationship- Symbol im ER-Modell. Im Klassendiagramm wird sie mit Hilfe eines mittig orientierten Textes und eines Dreiecks für die Richtungsangabe dargestellt. Abbildung 3.2 zeigt die genaue Anordnung von Kardinalitäten, Rollen und Kantenbeschriftung.

37 3.2 Relevante UML-Elemente 29 Um einzelne Entitäten näher zu erläutern, bietet die UML-Notation die Möglichkeit, Kommentarfelder einzufügen und dieses mit der zu kommentierenden Entität zu verknüpfen. Hierzu verwendet man eine gestrichelte Assoziation ohne Kardinalitäten oder Beschriftungen. Da Kommentarfelder semantisch nicht sehr stark sind, sollten sie auch nur semantisch schwache Aussagen beinhalten. Definition 3.10: Kommentarfeld Fügt zu beliebigen UML-Modellelementen Anmerkungen, Kommentare, Erläuterungen und zusätzliche Beschreibungstexte hinzu, ist jedoch ohne semantische Wirkung. Kommentar nach Oestereich [Oes09, S. 297] Kardinalität Entitätsname Eigenschaft Unternehmen name anschrift arbeitgeber Name & Leserichtung beschäftigt Rolle 0..* arbeitnehmer Mitarbeiter name anschrift personalnr... produkterstellen... Fähigkeit Abbildung 3.2: Beispielanordnung von Kardinalität, Rolle und Kantenbeschriftung Nicht berücksichtigte Elemente Für die Realisierung der Domain Models nicht relevant und daher hier auch nicht weiter ausgeführt sind die in Tabelle 3.2 kurz zusammengefassten Elemente. Abbildung A.10 im Anhang fasst nochmals alle im Editor realisierten Elemente der UML-Klassennotation zusammen.

38 30 Domain Model-Erweiterung für HeRA Element Aktive Klasse Aktive Klasse Begründung Stellen Klassen dar, deren Instanzen in einem eigenen Thread laufen. Da eine derartige Entscheidung nicht mehr Gegenstand der Anforderungsanalyse ist, wurde das entsprechende Symbol nicht realisiert. Parametrisierte/generische Klasse I:Element Parametrisierbare Klasse Entsprechen generischen Schablonen, mit denen gewöhnliche Klassen erzeugt werden können. Der generische Parameter repräsentiert dabei die späteren tatsächlichen Parameter der konkreten Klasse. Da derartige Entscheidungen eher Gegenstand der Entwurfsphase sind, wurde auf eine Umsetzung des Symbols verzichtet. Attributierte Assoziation Klasse Attribut Attribut Klasse Attribut Attribut Klasse Attribut Attribut Fügt der Assoziation Klasseneigenschaften hinzu. Sie sind jedoch in objektorientierten Sprachen nicht umsetzbar und werden hier nicht weiter beachtet. Auf Grund der strukturellen Ähnlichkeit zu den Kommentaren lassen sie sich jedoch darstellen. Qualifizierte Assoziation Klasse Attribut Attribut Qualifikation Klasse Attribut Attribut Unterteilt die referenzierten Objekte in Partitionen. Dies führt jedoch oftmals zu Verwirrungen und wird daher nicht realisiert. Mehrgliedrige Assoziation Klasse Attribut Attribut Klasse Attribut Attribut Klasse Attribut Attribut Führt wegen der nicht eindeutigen Angabe von Kardinalitäten eher zu Missverständnissen, als dass sie hilft. Da sie meist mit einfachen Assoziationen dargestellt werden kann, wird auf eine Umsetzung im Editor verzichtet. Tabelle 3.2: Nicht berücksichtigte Elemente 3.3 Realisierung des Editors Dieser Abschnitt beschreibt die Integration des neu erstellten Domain Model-Editors in das bestehende Konzept von HeRA und gibt einen kurzen Einblick in die wichtigsten Bedienelemente. Abschließend wird kurz die technische Umsetzung des Editors thematisiert.

39 3.3 Realisierung des Editors 31 Abbildung 3.3: Editor für Domain Models in HeRA Anpassungen des User-Interfaces Für die Realisierung des Domain Model-Editors (Abbildung 3.3) wurde das Grafische User Interface von HeRA um einen weiteren Eingabebereich für die Konstruktionskomponente erweitert. Dieser umfasst eine Toolbar für die elementarsten Operationen und eine grafische Zeichenebene zur Darstellung der einzelnen Elemente des Domain Models. Toolbar Abbildung 3.4: Toolbar des Domain Model-Editors Die Toolbar (Abbildung 3.4) ist in die folgenden sechs Bereiche unterteilt, Objekte erzeugen, Darstellungsdetails, Redo/Undo, Darstellungsgröße, Editoroptionen, Reifegrad. Über den Bereich Objekte einfügen lassen sich Entitäten, Kommentarfelder und Referenzen zum Einfügen auswählen. Dabei kann der Nutzer angeben, wie viele der ausgewählten Elemente der Objektgruppe er einfügen will. Das Einfügen wird durch Angabe der Einfügeposition mittels Klick auf der Zeichenfläche vollendet.

40 32 Domain Model-Erweiterung für HeRA Über die Darstellungsdetails kann der Benutzer zwischen drei Darstellungen der Entitäten wählen. Je nach Wahl werden entweder nur der Name der Entitäten angezeigt, der Name samt Eigenschaften oder zusätzlich noch dessen Fähigkeiten. Mit den Redo/Undo-Schaltflächen können einzelne Modellierungsschritte zurückgenommen, beziehungsweise erneut ausgeführt werden. Die Schaltflächen der Darstellungsgröße erlauben es dem Benutzer, die Anzeigegröße der Zeichenfläche zu verändern. Über die Editoroptionen lassen sich Funktionen, wie das Anzeigen eines Gitternetzes, zur besseren Orientierung auf der Zeichenebene ein- oder ausschalten. Der letzte Bereich der Toolbar steuert den Reifegrad des Domain Models. So lassen sich zum einen Leser und Zweitautoren über die Aussagekraft des Modells unterrichten und zum anderen Funktionen, die das Modell als Input nutzen, wie beispielsweise das Kritiksystem, steuern und so diese gezielt für die einzelnen Reifegrade aktivieren beziehungsweise deaktivieren. Eine genauere Betrachtung folgt in Abschnitt 4.4. Grafische Zeichenebene Die grafische Zeichenebene dient der Darstellung der Objekte im Modell. Diese lassen sich verschieben und auch wieder löschen. Je nach Objekt stehen verschiedene Optionen im Kontextmenü zur Verfügung, mit denen sich die einzelnen Objekte genauer typisieren lassen. So können Entitäten mit Stereotypen versehen werden und an den Kanten die Art der Assoziation, Kardinalitäten und Beschriftungen eingestellt werden. Abbildung 3.5: Einstellungen des Domain Model-Editors Das genaue Verhalten der Zeichenebene und der in ihr enthaltenen Objekte lässt sich in den Editoreinstellungen (Abbildung 3.5) konfigurieren, welche sich in der Menüleiste von HeRA unter Einstellungen einordnen.

41 3.3 Realisierung des Editors 33 Erweiterung des Projektbaums Die Domain Models werden im Projektbaum unter dem Ordner UML-Modelle angezeigt. Dabei können innerhalb eines Projektes mehrere Domain Models verwaltet und bearbeitet werden. Über das Kontextmenü lassen sich die Eigenschaften, wie zum Beispiel der Name, der Autor oder der Reifegrad des Modells, verändern (Abbildung 3.6). Auch eine kleine Beschreibung lässt sich hier für das jeweilige Modell hinterlegen. Abbildung 3.6: Eigenschaften des Domain Models Technische Umsetzung Der Prototyp ist eine eigenständige Erweiterung für HeRA und somit optional zum Kernprogramm hinzufügbar. Die Erweiterung beinhaltet den Domain Model-Editor sowie alle zugehörigen Komponenten, die nicht bereits im Kern von HeRA vorhanden sind. Das bereits in HeRA vorhandene Kritiksystem bleibt unverändert. Lediglich auf Seiten des Editors wurden Markierungsmöglichkeiten, für die Anzeige der durch die Kritiken gefundenen Probleme, hinzugefügt und die Experience-Base um die neuen Kritiken erweitert. Die Domain Model-Erweiterung greift neben dem Kern von HeRA und der Erweiterung für das Kritiksystem auch auf die Use Cases und die Glossareinträge zu. Diese Abhängigkeiten zu den entsprechenden Erweiterungen sind allerdings nur einseitig und nicht zwingend. Ist beispielsweise die Glossarerweiterung installiert, so können Kommentarfelder mit einem Eintrag verknüpft werden (siehe Abschnitt 5.3). Fehlt die Erweiterung, so steht dem Nutzer diese Option nicht zur Verfügung, die restlichen Komponenten bleiben jedoch weiterhin funktionsfähig. Für die Darstellung der Elemente des Domain Models kommt das Framework JGraph 2 zum Einsatz. Hierzu wurden die einzelnen Elemente in Form von Kanten und Knoten hinzugefügt und entsprechend der Notationsvorgaben angepasst. 2

42

43 35 4 Konsistenzsicherung durch heuristische Kritiken Nachdem in Kapitel 3 die grundlegenden Eigenschaften des Domain Model-Editors dargelegt wurden, folgt in diesem Kapitel die Beschreibung der Adaption des in HeRA integrierten Kritiksystems, welches den Nutzer bei der Erhebung qualitativ hochwertiger Anforderungen unterstützen soll. Hierzu wird zunächst die bestehende Struktur in HeRA sowie die zugrunde liegende Intention vorgestellt. Im weiteren Verlauf des Kapitels wird dann gezeigt, wie die heuristischen Kritiken zur Sicherung der Konsistenz zwischen Use Cases und Domain Model eingesetzt werden können. Die dabei erarbeiteten Ergebnisse werden präsentiert und mit bestehenden Ansätzen verglichen. Zur Lösung der in Abschnitt 2.5 beschriebenen Konsistenzproblematik erarbeitet Abschnitt 4.2 zunächst Ansätze zur Lösung der gegebenenfalls auftretenden internen Konsistenzprobleme des Domain Models, bevor in Abschnitt 4.3 das eigentliche Hauptproblem der Konsistenzsicherung zwischen Use Case und Domain Model erschlossen wird. 4.1 Einführung in das Kritiksystem von HeRA Das Kritiksystem von HeRA greift auf eine mit den Erfahrungen des Requirement Teams wachsende Wissensbasis zu. Diese speichert die im Laufe der Zeit errungenen Erfahrungen im Umgang mit Anforderungen als heuristische Kritiken und stellt diese dem Anwender zur Verfügung, sodass dieser bei seiner Arbeit am aktuellen Anforderungsdokument durch kontextbasierte Feedbacks unterstützt wird. Die von HeRA unterstützten Feedbacks lassen sich in zwei Gruppen unterteilen. Zum einen beinhaltet HeRA heuristische Kritiken, welche den Anwender konstruktiv bei seiner Arbeit am aktuellen Dokument unterstützen sollen, zum anderen leitet HeRA aus den geleisteten Eingaben des Benutzers Modelle ab, die im Anschluss an den Eingabeprozess einen zweiten Betrachtungswinkel bieten und so eine Möglichkeit zur Reflexion der geleisteten Arbeit ermöglichen. Für die Konsistenzsicherung kommt jedoch nur erstere Gruppe in Frage.

44 36 Konsistenzsicherung durch heuristische Kritiken Definition 4.1: Feedback Feedback (auch Rückkoppelung oder Rückmeldung) ist [..] (i) ein Mechanismus, der einen Teil der eingehenden Informationen analysiert, aufbereitet oder bewertet und das Ergebnis zu deren Quelle zurückführt, (ii) die zurückgeführte Information nach (i) nach Knauss [Kna10, S. 108] Heuristiken sind Näherungen zur Lösung von Such- und Vergleichsproblemen. Sie lösen diese Probleme, für die es keine effizienten Algorithmen gibt, in vertretbarer Zeit und einem angemessenen Platz. Heuristiken führen zwar zu keiner optimalen Lösung, sind aber in der Regel besser als gar kein Ergebnis. Knauss fasst in seiner Arbeit [Kna10] die von Russell und Norvig ([RN95]) erstellte Abhandlung über Heuristiken in der folgenden Definition zusammen: Definition 4.2: Heuristik (allgemein) In der Informatik versteht man unter einer Heuristik Techniken, die gute (beinahe optimale) Lösungen mit angemessenen Berechnungskosten [..] [ermitteln]. Dabei garantieren Heuristiken weder die Brauchbarkeit noch die Optimalität einer Lösung. In vielen Fällen kann für eine brauchbare Lösung nicht angegeben werden, wie nahe sie der optimalen Lösung kommt. aus [Kna10, S. 111] nach Russell et al. [RN95, Kap. 3.5] Im Kontext von HeRA wird diese Definition jedoch noch enger gefasst. Dabei stellen Heuristiken einen Zusammenhang zwischen den im Anforderungsdokument auftretenden Indikatoren und den erkannten Problemen her. Hierfür werden heuristischen Regeln zur Erkennung und Verarbeitung dieser Indikatoren erstellt. Liegt eine passende Kombination von Indikatoren vor, so kann davon ausgegangen werden, dass das Problems vorliegt. Diese Regeln garantieren dabei zwar weder, dass alle Probleme erkannt werden, noch dass alle aufgezeigten Probleme auch wirklich welche sind, bilden aber meist eine gute Näherung. Entsprechend gilt für heuristische Regeln die folgende Definition:

45 4.1 Einführung in das Kritiksystem von HeRA 37 Definition 4.3: Heuristische Regel zur Verbesserung von Anforderungsdokumentation Eine heuristische Regel zur Verbesserung von Anforderungsdokumentation stellt einen Zusammenhang zwischen Indikatoren und einem bestimmten Problem in Anforderungsdokumenten her. Sie beschreibt, wie Indikatoren (automatisch) in einem Anforderungsdokument nachgewiesen werden können und unter welchen Umständen (Kombination von Indikatoren) von einem Problem ausgegangen werden soll. Die heuristische Regel garantiert nicht, dass a) das Problem vorliegt, wenn die Kombination von Indikatoren vorliegt und b) das Problem nicht vorliegt, wenn die Kombination von Indikatoren nicht vorliegt. nach Knauss [Kna10, S. 111] In diesem Zusammenhang werden in der Informatik die aus dem Information Retrival bekannten Maße Precision und Recall herangezogen. Sie geben an, wie gut ein Mechanismus im Verhältnis zur Realität abschneidet. Unter Berücksichtigung dieser Maße lässt sich nun eine Definition für die in HeRA umgesetzten heuristischen Kritiken erstellen. Definition 4.4: Heuristische Kritik Als heuristische Kritik wird computerbasiertes Feedback zu einer Aktivität oder einem Arbeitsergebnis bezeichnet. Grundlage der Kritik ist eine Erfahrung. Eine heuristische Kritik besteht aus a) einer heuristischen Regel, die vom Computer angewendet werden kann, b) einer Kritikalität, c) einer bedeutungsvollen und konstruktiven Meldung. Sie kann zudem noch eine ausführliche Beschreibung der ursprünglichen Beobachtung aus der zugrunde liegenden Erfahrung enthalten. Wenn die heuristische Regel (a) feuert, wird die Kritische Formulierung der Beobachtung (c) dem Durchführenden der Aktivität oder dem Autoren des Arbeitsergebnisses als Feedback gegeben. Die Darstellung des Feedbacks soll sich an der Kritikalität (b) orientieren. nach Knauss [Kna10, S. 112] Individuelles Wissen entsteht nach der in der Lerntheorie verbreiteten Meinung durch die Reflexion eines Ereignisses und der neuerlichen Anwendung des Erfahrenen zur Abstimmung zwischen der in der Reflexion erstellten Hypothese und der Wirklichkeit. Nach Schneider [Sch09] können zudem Erfahrungen nur von Personen gesammelt werden, die

46 38 Konsistenzsicherung durch heuristische Kritiken in der jeweiligen Domäne aktiv sind. Darüber hinaus kann diese nach Schön [Sch83] nur dann entstehen, wenn das Individuum in seiner Tätigkeit unterbrochen wird und so die Zeit hat, diese zu reflektieren und so Erkenntnisse für zukünftiges Handeln zu ziehen. Die resultierenden Erkenntnisse können sowohl positiver Natur (Akzeptanz des mit der Tätigkeit erzielten Ergebnisses) sein, als auch negativer (Erkennen einer Verfehlung). Schön nennt dieses Unterbrechen zum Reflektieren Brakedown. Die Erkenntnis entspricht der Hypothese, die dann den folgenden Aktionen zu Grunde liegt. In der Art und Weise, in der sie den Workflow des Anwenders unterbrechen, kann zwischen verschiedenen Brakedowns unterschieden werden. Dabei betrachtet man bei der Unterscheidung den Zeitpunkt der Systemaktivität (pro-aktiv) und den Umfang der Systemaktivität (interpretierend). Definition 4.5: Pro-Aktiv Die Pro-Aktivität eines heuristischen Werkzeugs beschreibt, wie stark dieses Werkzeug den Zeitpunkt des Feedbacks selbst bestimmt. Ein heuristisches Werkzeug ist schwach pro-aktiv oder reaktiv, wenn es nur auf direkte Anforderung des Nutzers aktiv wird, mittelstark pro-aktiv, wenn es auf bestimmte Nutzer-Aktionen reagiert, stark pro-aktiv, wenn es selbstständig den Zeitpunkt des Feedbacks festlegt. nach Knauss [Kna10, S. 122] Definition 4.6: Interpretierend Ein heuristisches Werkzeug ist interpretierend, wenn es zu einer Situation Daten sammelt, auswertet und dem Nutzer eine Bewertung präsentiert, die über die direkt vorliegenden Daten hinaus geht. Ein heuristisches Werkzeug ist schwach interpretierend, wenn es vorhandene Daten aufbereitet, die Bewertung jedoch dem Nutzer überlässt, mittelstark interpretierend, wenn es die aufbereiteten Daten sortiert oder stark gefiltert darstellt und so eine bestimmte Interpretation nahe legt, stark interpretierend, wenn es basierend auf aufbereiteten Daten eine Bewertung vornimmt. nach Knauss [Kna10, S. 121] Somit gibt es in HeRA Breakdowns, die während und nach der Eingabe ausgelöst werden und dabei unmittelbar den Arbeitsablauf unterbrechen oder erst am Ende wahrgenommen werden. Jedoch wird auf den extremsten Fall, Unterbrechung des Arbeitsablaufes

47 4.1 Einführung in das Kritiksystem von HeRA 39 durch das Anzeigen eines Dialog-Fensters, verzichtet, da dieser nicht im Sinne eines konstruktiven Feedbacks steht und den Benutzer unverhältnismäßig stört. In HeRA werden fünf Arten von Kritiken bei Bearbeitung von Use Cases unterschieden: Allgemeine Hinweise. Solange der Benutzer kein Feld im Use Case ausgewählt hat, werden ihm im Assistenzbereich allgemeine Informationen zur Erstellung von Use Cases angezeigt. Allgemeine Hinweise zur Eingabe. In diesem Fall prüft HeRA, ob für das ausgewählte Feld Indikatoren vorliegen, die einen Rückschluss auf einen Verstoß gegen allgemeine, nicht feldspezifischer Regel zur Erstellung von Use Cases zulassen und gibt diesen in Form eines Hinweises aus. Kontextspezifische Hinweise. Analog zu den allgemeinen Hinweisen, zeigt dieser Informationen an, die bei der Bearbeitung des gewählten Feldes zu beachten sind. Dies kann beispielsweise die Intention hinter dem Feld sein. Kontextspezifische Hinweise zur Eingabe. Auch hier wird in Analogie zu den allgemeinen Hinweisen zur Eingabe nach Indikatoren für fehlerhafte Eingaben gesucht, jedoch diesmal speziell auf den erwarteten Inhalt des selektierten Feldes. Kontextübergreifender Hinweis zur Eingabe. Die bisher beschriebenen Hinweisgruppen bezogen sich lediglich auf den Kontext des geöffneten Use Cases. Bei den kontextübergreifenden Hinweisen zur Eingabe wird hingegen geprüft, inwieweit der aktuelle Use Case Konflikte zu anderen Use Cases auslöst. Das Erstellen neuer heuristischer Kritiken Das von HeRA verwaltete Kritiksystem zur Speicherung des Erfahrungsschatzes basiert auf einer Menge von heuristischen Kritiken, die der Anwender anpassen kann. Macht ein Anwender eine neue, bisher noch nicht berücksichtigte Erfahrung, so erlaubt ihm das Kritiksystem, diese in Form einer neu erstellten Kritik zu der Menge der bestehenden Erfahrungen hinzuzufügen. Die gespeicherten Kritiken entsprechen der Syntax eines Javascripts. Zur Definition neuer Kritiken erlaubt HeRA dem Anwender, auf die Datenmodelle der Konstruktionskomponenten für Use Cases, Anforderungen und Glossare zuzugreifen. Hierzu stellt es ihm eine definierte Schnittstelle zur Verfügung. Ebenfalls sind einige Basisfunktionen für wiederkehrende, komplexe Berechnungen sowie ein Assistenzsystem zur automatisierten Erstellung einfacher Heuristiken vorhanden. Neben der Berechnungsregel muss für jede neu erstellte Kritik auch eine kurze Funktionsbeschreibung abgegeben werden. Bei der funktionalen Umsetzung der Heuristik stehen dem Autor Parameter zur Verfügung, die eine Kalibrierung durch die Anpassung dieser Parameter ermöglichen. Da die Änderungen zur Laufzeit umgesetzt werden können, ist eine schnelle und einfache Änderung einer Kritik sowie deren Überprüfung möglich.

48 40 Konsistenzsicherung durch heuristische Kritiken Im Allgemeinen lassen sich drei typische Regeln unterscheiden: Schlüsselwortsuche: Sucht im zu prüfenden Objekt nach vorgegebenen Wörtern, die als Indikator dienen. Konsistenz: Stellt Vergleiche zwischen verschiedenen Objekten an und prüft deren Konsistenz. Analyse der Struktur: Überprüft, ob strukturelle Vorgaben eingehalten wurden. Der Nutzer kann dabei zwischen fünf Arten von Erfahrungen wählen und so angeben, wann und wo das Feedback gegeben wird. Unterschieden wird dabei zwischen Kritiken, Warnungen und Fehlern, die in der Problemsicht angezeigt werden, sowie zwischen Informationen und Hinweisen, welche im Assistenzbereich unterkommen. Abbildung 4.1 zeigt entsprechend der Definition 4.4 den Aufbau, der in HeRA genutzten Kritiken. Neben einigen Metadaten, sind besonders die hier markierten Bereiche der heuristischen Regel als Berechnungsvorschrift, die Kritikalität sowie die Meldung, die an den Nutzer weitergegeben wird relevant. Abbildung 4.1: Beispiel für eine heuristische Kritik in HeRA Das in diesem Abschnitt vorgestellte Kritiksystem soll nun auch in der Erweiterung zur Konsistenzprüfung zwischen Use Cases und Domain Models zum Einsatz kommen. Hierzu sollen analog zu den bereits bestehenden Use Case-Kritiken weitere Kritiken und die für ihre Prüfung notwendigen Mechanismen erstellt werden. Die neuen Kritiken sollen sich dabei nahtlos in das bestehende Kritiksystem einfügen und sich analog verhalten. Das heißt, auch sie werden die Aktionen des Nutzers beobachten,

49 4.2 Intra-Modell-Kritiken 41 diese interpretieren und gegebenenfalls aktiv eingreifen. Für die so zu realisierenden Kritiken kommen dabei alle fünf von [Kna10] vorgestellten Arten in Frage. Zum einen kann es sinnvoll sein, dem Nutzer Hinweise für den aktuell zu bearbeitenden Bereich des Domain Models zu geben, zum anderen muss diese Bearbeitung nach ihrer Beendigung geprüft und so auf ihre Konsistenz zu dem jeweils anderen Modell getestet werden. 4.2 Intra-Modell-Kritiken Nachdem nun das Kritiksystem in HeRA betrachtet wurde, sollen in den folgenden zwei Abschnitten zunächst die Kriterien zur Sicherung der Qualität der Domain Models erläutert werden, bevor diese in sich korrekten Modelle in eine konsistente Form bezüglich der beteiligten Use Cases gebracht werden. Die Qualität der Use Cases ist bereits durch die bestehenden Kritiken gesichert. Die hier erstellten Kritiken sollen erste Ideen darstellen und zeigen, dass ein Einsatz für die Konsistenzsicherung sinnvoll ist. Obwohl die hier aufgelisteten Kritiken keinen Anspruch auf Vollständigkeit und entsprechend der ihnen zugrunde liegenden Definition für Heuristiken (Definition 4.2 bzw. 4.3) auch keinen Anspruch auf Korrektheit haben, so kann zumindest davon ausgegangen werden, dass die hier erstellten Gruppierungen weitestgehend vollständig sind. Wie bereits das bestehende System gezeigt hat, entstehen Kritiken am besten durch den Anwender im Verlauf der Interaktion mit HeRA. Gegebenenfalls verfeinert oder entfernt er dabei bestehende Kritiken. Somit ist die folgende Aufzählung nur eine erste Ansammlung sinnvoller und nützlicher Kritiken, die als Startpunkt gesehen werden kann und mit der Akzeptanz der Nutzer wachsen wird Forschung im Bereich der Intra-Modell-Kritiken Auf Grund der engen Beziehung zwischen Klassendiagramm und Domain Models werden im Folgenden auch einige Qualitätsanforderungen für Klassendiagramme genannt und gegebenenfalls an die Erfordernisse für Domain Models angepasst. Heide Balzert führt in ihrem Buch [Bal05] einige Kriterien für gute Klassendiagramme auf. Diese sind hier zum größten Teil in den Tabellen 4.1 bis 4.4 enthalten und entsprechend der adressierten Elemente im Modell sortiert. Zusätzlich wurde eine kurze Bewertung in Bezug auf ihre Realisierbarkeit durch heuristische Kriterien vorgenommen. Die folgende Liste erklärt die verwendete Symbolik. Einfach als Kritik in HeRA zu realisieren, da der zugrundeliegende Vergleich ohne viel Aufwand zu realisieren ist. Die Lösung des Problems ist abhängig von der gewünschten Qualität und somit dem Umfang der Prüfung. Eine Umsetzung als Kritik ist nicht ohne die Integration zusätzlicher Funktionseinheiten und dem damit verbundenen Aufwand möglich. Eine Lösung des Problems ist auf Grund der hohen Komplexität des Problems kaum bis gar nicht zu realisieren.

50 42 Konsistenzsicherung durch heuristische Kritiken / Vorschlag [Bal05] Bewertung, ggf. Anpassung Der Klassenname sollte der Fachterminologie entsprechen. Eine Prüfung der Fachterminologie ist eventuell über die in der Glossar-Erweiterung ([Mey07]) definierten Begriffe zu realisieren. Der Klassenname sollte ein Substantiv im Singular sein. Analogie zu bestehenden Kritiken wie der Passivregel in HeRA. Der Klassenname sollte so konkret wie möglich gewählt werden. Der Ausdruck so konkret wie möglich ist eine zu vage Angabe und nur von Menschenhand prüfbar. Der Klassenname sollte dasselbe ausdrücken wie die Gesamtheit der Attribute. Ohne große Datenbank mit Domainwissen nicht zu lösen, einzige Möglichkeit ist ein Abgleich mit dem Definitionstext im Glossar. Der Klassenname sollte nicht die Rolle dieser Klasse in der Beziehung zu einer anderen Klasse beschreiben. Der Klassenname sollte eindeutig im Paket bzw. im System sein. Abgleich der Klassennamen gegenüber den Rollennamen an den Assoziationen. Durch eine Dublikatsprüfung aller erstellten Klassennamen realisierbar. Der Klassenname sollte nicht dasselbe ausdrücken wie der Name einer anderen Klasse. Entspricht einer Synonymprüfung, welche ebenfalls eine gewisse Wissensbasis verlangt. Zu untersuchen wäre, ob hier die in der Arbeit [Hec09] entstandene Datenbasis ausreicht. Tabelle 4.1: Regeln für den Namen einer Klasse / Vorschlag [Bal05] Bewertung, ggf. Anpassung Der Name eines Attributes sollte kurz und eindeutig sein. Entspricht einer Überprüfung der Länge des Wortes und der Anzahl des Auftretens innerhalb der Klasse Der Attributname sollte im Kontext der Klasse verständlich sein. Ohne weitere Hilfsmittel nicht maschinell realisierbar, da eine Prüfung der Verständlichkeit eine umfassende Sprachanalyse und somit erheblichen Aufwand erfordert. Der Name eines Attributes sollte ein Substantiv oder Adjektiv-Substantiv sein (kein Verb!). Abhängig von der erwarteten Güte der Überprüfung und der Qualität der Eingabe durch einen einfachen Zeichenvergleich umsetzbar, andernfalls ist die Einbindung eines Wörterbuches unumgänglich. Der Attributname sollte den Namen der Klasse nicht wiederholen. (Ausnahme: feststehende Begriffe) Ein Attribut sollte nur fachspezifische oder allgemein übliche Abkürzungen im Namen enthalten. Auch hier hängt der Aufwand von der erwarteten Qualität des Ergebnisses ab. Auch hier wird für den Abgleich eine gewisse Wissensbasis benötigt. Tabelle 4.2: Regeln für Attribute

51 4.2 Intra-Modell-Kritiken 43 / Vorschlag [Bal05] Bewertung, ggf. Anpassung Der Name einer Operation sollten ein starkes Verb enthalten. Aus Gründen der Effizienz ist hier wohl der Abgleich mit einer Verbotsliste sinnvoller. Der Operationsname sollte beschreiben, was die Operation tut. Erfordert eine umfassende Sammlung von Verben, die erlaubt bzw verboten sind. Der Name ist eindeutig im Kontext der Klasse. Entspricht einer einfachen Duplikatsprüfung. Tabelle 4.3: Regeln für Operationen / Vorschlag [Bal05] Bewertung, ggf. Anpassung Assoziations- und Rollennamen sind notwendig, wenn zwischen Klassen mehrere Assoziationen bestehen. Dabei sind Rollennamen den Assoziationsnamen zu bevorzugen. Umsetzung durch einen Abgleich der Anzahl der Assoziationen zwischen zwei Klassen unter der Berücksichtigung der Beschriftungen möglich. Rollennamen sind bei reflexiven Assoziationen immer notwendig. Realisierung durch eine Prüfung auf Identität zwischen den beiden beteiligten Klassen der Assoziation. Rollennamen sind Substantive, Assoziationen enthalten Verben. Analogie zur Prüfung von Klassen- und Attributnamen. Klasse1 Assoziationsnamen Klasse2 ergibt einen sinnvollen Satz. Auch hier hängt der Aufwand von der gewünschten Güte ab. Unter Umständen reicht eine einfache Prüfung der beteiligten Wortarten. / Existieren mehrere Assoziationen zwischen zwei Klassen, so ist zu prüfen, ob sie eine unterschiedliche Bedeutung besitzen und/oder unterschiedliche Kardinalitäten. Die Überprüfung der Kardinalität und Assoziationstypen entspricht einem Vergleich aller infrage kommenden Assoziationen. Zieht man die Beschriftungen mit ein, so hängt der Aufwand von der Berücksichtigung von Synonymen ab. Abgeleitete Assoziationen dürfen keine neue Information hinzufügen. Entspricht einer Überprüfung der beiden Assoziationen auf eine Identität. Die Kardinalität bei Aggregationen beträgt 0..1 oder 1. Realisierung durch einen Abgleich zwischen Kardinalität und Assoziationstyp möglich. Tabelle 4.4: Regeln für Assoziationen und Kardinalitäten Umsetzung der Intra-Modell-Kritiken Grob lassen sich die Intra-Modell-Kritiken entsprechend der beteiligten Elementgruppen weiter unterteilen. So erhält man die Bereiche Domain Model, Entitäten und Referenzen. Dabei greifen Kritiken des Bereichs Modell-Kritiken auf das gesamte Modell zu

52 44 Konsistenzsicherung durch heuristische Kritiken und betrachten zum Beispiel die Anzahl der im Modell enthaltenen Elemente (Entitäten, Kommentare und Referenzen). Kritiken der Gruppen Entitäts-Kritiken und Referenz-Kritiken greifen direkt auf die Elemente des Modells zu und prüfen hier zum Beispiel die Einhaltung von Namenskonventionen bei den Entitäten oder das Zusammenpassen von Pfeiltyp und Kardinalität bei den Assoziationen. Da die heuristischen Kritiken in HeRA in einer mitlernenden und somit auch mitwachsenden Experiencebase gehalten werden, wird im Folgenden zu jeder der drei Gruppen eine Beispielkritik formuliert. Modell-Kritiken Zu der Gruppe der Modell-Kritiken gehören all die Kritiken, die sich mit dem Domain Model als Ganzen beschäftigen. Oft wird zum Beispiel gefordert, dass ein Klassendiagramm und somit auch das adaptierte Domain Model nicht mehr als 5-30 Klassen beinhalten soll ([Old02]), oder es zwischen zwei Klassen nur eine gewisse Anzahl an Referenzen geben darf. Alternativ könnte man diese Art der Kritiken auch Strukturkritiken nennen. Beispielhaft zeigt Listing 4.1 die Regel der heuristischen Kritik zur Prüfung der Anzahl von Entitäten innerhalb eines Domain Models. 1 var dms = domainmodelhandler.getallelements(); 2 3 for(var i=0; i<dms.length; i++){ 4 var ecount = dms[i].getentities().length; 5 if(ecount > parameter){ 6 contextlist.addcontext( Zu viele Entities ( + ecount + ), project, 7 dms[i]); 8 } 9 } Listing 4.1: Heuristische Regel zur Prüfung der Anzahl von Entitäten Entitäts-Kritiken Die Überprüfung des Entitätsnamens auf die Einhaltung der Namenskonvention oder die Prüfung der Werte innerhalb der Eigenschafts- und Fähigkeitslisten hingegen gehören zur Gruppe der Entitäts-Kritiken. Hier wird jede Entität für sich betrachtet und geprüft, ob sie den gängigen Regeln beziehungsweise Erfahrungen entspricht. Auch hier soll eine Beispielimplementierung einer heuristischen Kritik zur Überprüfung des Entitätsnamens den Nutzen und die Notwendigkeit dieser Kritikenklasse zeigen. Die in Listing 4.2 aufgeführte Regel prüft, ob es sich bei den Entitätsnamen um Nomen handelt. Denkbar wäre für diese Gruppe der Kritiken auch eine Überprüfung der Entitäten

53 4.2 Intra-Modell-Kritiken 45 bezüglich der Gleichheit ihrer Eigenschaften und Fähigkeiten und daraus resultierend das Vorschlagen einer Elternentität. 1 var dms = domainmodelhandler.getallelements(); 2 3 for(var i=0; i<dms.length; i++){ 4 var tools = domainmodelhandler.getvalidationtoolsformodel(dms[i]); 5 var entities = dms[i].getentities(); 6 7 for(var j=0; j<entities.length; j++){ 8 var ename = entities[j].getentityname(); 9 var n = ename.substr(0,1); 10 var g = ename.substr(0,1).tolowercase(); if(n.equals(g)){ 13 var id = entities[j].getvalue( ID ); 14 contextlist.addcontext(ename, project, dms[i], classname_ +id); 15 } 16 } 17 } Listing 4.2: Heuristische Regel zur Prüfung des Klassennamens Referenz-Kritiken Analog zu den Entitäts-Kritiken sichern die Referenz-Kritiken die Einhaltung der für die Modellierung von Assoziationen und Generalisierungen zwischen den Entitäten vorgesehenen Richtlinien. Zur Verdeutlichung dieser Gruppe zeigt Listing 4.3 eine Regel zur Überprüfung der Kompositionen. Sie prüft, ob die Kardinalität auf der Seite des Ganzen, wie von [Oes09] gefordert, immer 0..1 ist. Mögliche andere Kritiken könnten beispielsweise prüfen, ob es Dopplungen bei den angegeben Rollen oder Beziehungen gibt. 1 var key = var message = 0..1 einsetzen ; 3 var dms = domainmodelhandler.getallelements(); 4 5 for(var i=0; i<dms.length; i++){ 6 var edges = dms[i].getedges(); 7 8 for(var j=0; j<edges.length; j++){ 9 var edge = edges[j]; 10 var id = edge.getattributes().get( ID ); if(edge.getvalue(edge.key_source_type) == edge.type_composition 13 &&!edge.getvalue(edge.key_source_multiplicity).equals(key)){ 14 contextlist.addcontext(message, project, dms[i], 15 S_MULTIPLICY_ +id); 16 } 17 else if(edge.getvalue(edge.key_target_type) == edge.type_composition 18 &&!edge.getvalue(edge.key_target_multiplicity).equals(key)){

54 46 Konsistenzsicherung durch heuristische Kritiken 19 contextlist.addcontext(message, project, dms[i], 20 T_MULTIPLICY_ +id); 21 } 22 } 23 } Listing 4.3: Heuristische Regel zur Prüfung der richtigen Kardinalität an einer Komposition 4.3 Inter-Modell-Kritiken Die Schwierigkeit bei der Sicherung der Inter-Modell-Konsistenz liegt in der fehlenden Formalität der Use Cases, resultierend aus dem Gebrauch der natürlichen Sprache. Da weder die Verbesserung der Formalität der in HeRA realisierten Form von Use Cases Thema dieser Arbeit ist, noch ein derartiger Eingriff in die funktionierende Struktur der Use Cases unter dem Vorwand der Konsistenzsicherung den damit verbundenen Preis für die Aufgabe der Intuitivität in der Nutzung rechtfertigt, zeigt diese Arbeit, wie weit man die Konsistenz unter Beibehaltung der bestehenden Strukturen sichern kann. Neben der fehlenden Formalität kommt als weitere Hürde hinzu, dass ein Domain Model gegen eine Vielzahl von Use Cases geprüft werden muss (siehe Abschnitt 2.5). Hierdurch kann es zu einer gewissen Redundanz bei der Zuordnung von Objekten im Domain Model gegenüber einer Menge von Objekten im Use Case kommen. Im Idealfall unterscheidet sich diese Menge nicht, sodass das Vorkommen synonym genutzter Begriffe außer Acht gelassen werden kann. Aber auch eine gewisse Segmentierung der Domain Model-Objekte auf mehrere Use Cases darf nicht unterschätzt werden Forschungen im Bereich der Inter-Modell-Kritiken Glinz entwickelt in seiner Arbeit [Gli00] ein Verfahren zum Vergleich von Use Cases und Klassendiagrammen unter der Zuhilfenahme von Zustandsdiagrammen. Er geht dabei von zwei unabhängigen, wenig formell definierten Modellen aus, die wie in der UML nicht direkt miteinander verknüpft sind. Für Glinz sind Überlappungen zwischen beiden Modellen Quelle von Inkonsistenz. Zwei Modelle sind für ihn konsistent, wenn zwei Faktoren erfüllt sind. a) Es gibt keine Widersprüche zwischen den Informationen in beiden Modellen und b) in beiden Modellen gibt es keine einseitige Information in Bezug auf das andere Modell. Zur Konsistenzsicherung beschreibt er Regeln für die Eliminierung von Überlappungen, ohne dabei durch falsches Löschen neue, einseitige Informationen zu erzeugen. Des Weiteren nennt er zwei, bezüglich der Veränderung der Ursprungsmodelle, unterschiedlich weit gehende Ansätze zur Referenzierung zwischen beiden Modellen. Im ersten Ansatz

55 4.3 Inter-Modell-Kritiken 47 verknüpft er dabei lediglich die Use Cases durch Links mit den im Klassendiagramm vorhandenen Methoden. So wird ersichtlich, welche Operation für die Ausführung des aktuellen Szenarioschrittes notwendig ist. Wohingegen der weiter gehende Ansatz in beide Modelle eingreift. Dabei fügt Glinz in das Domain Model Pseudoklassen ein, die durch Stereotypen die Use Cases repräsentieren. Diese Klassen werden mittels gestrichelter Linien mit den am Use Case beteiligten (echten) Klassen verbunden. Darüber hinaus werden alle Operationen in Pseudocode grob umrissen. Auch die Links in den Use Cases bekommen konkrete Angaben über die Parameter, mit denen die Operationen aufgerufen werden sollen, und darüber, welche Bedingungen vor dem Aufruf gelten müssen. Auf Grund der in Abschnitt 2.5 beschriebenen Thematik, dass nicht alle Objekte des Domain Models einem Objekt in den Use Cases entsprechen, kann die von Glinz erstellte Definition nur in einer Richtung auf die Konsistenz zwischen Domain Model und Use Cases übertragen werden, denn einseitige Informationen auf Seiten des Domain Models lassen sich nicht vermeiden. Da weder eine weitreichende Veränderung der beiden Modelltypen (Use Case und Domain Model) im Interesse dieser Arbeit ist, noch zum Zeitpunkt der Erstellung eines Domain Models alle notwendigen Informationen für die Umsetzung des zweiten, tiefgreifenderen Ansatz nach Glinz vorhanden sind, wird auf die entsprechende Umsetzung durch heuristische Kritiken verzichtet. Die im einfachen Ansatz enthaltenen Links vom Use Case zum Domain Model hingegen werden bei der Realisierung der Konsistenzsicherung berücksichtigt (siehe Abschnitt 4.3.2). Die Autoren Kösters, Pagel und Winter gehen in ihrem Konzept [KPW97] zunächst von hierarchisch strukturierten Use Cases aus, in denen das Szenario schrittweise beschriebenen ist. Die für die Durchführung eines Schrittes notwendigen Klassen werden dabei, genau wie die im Verlauf des Schrittes veränderten oder ausgelösten Klassen, mit dem jeweiligen Schritt verknüpft. Somit entsteht ein Use Case-Graph (nicht zu verwechseln mit dem Use Case-Diagramm), der die Schritte eines Use Cases entsprechend ihrer zeitlichen Relevanz ordnet und so eine Art grafischen Ablaufplan erstellt. Der Use Case-Graph beinhaltet wie auch das Use Case-Diagramm alle beteiligten Akteure und die verknüpften Use Cases. Darüber hinaus werden im Graphen die einzelnen Use Case Schritte als Knoten modelliert und den Operationen im Klassendiagramm zugeordnet. Die Klassen des Klassendiagramms, die zum Erreichen des (Teil-)Ziels notwendig sind, werden als Vorbedingungen der Interaktion eingefügt. Klassen, die ihren Zustand im Verlauf der Interaktion verändern, werden hingegen als Nachbedingungen betrachtet. Jeder Use Case-Graph endet immer in einem definierten Endzustand, dabei spielt es keine Rolle, ob das Ziel des Anwenders erfüllt werden konnte oder nicht. Die Prüfung der Konsistenz überlassen die Autoren jedoch dem Menschen. Der entwickelte Use Case-Graph dient nur zur methodischen Unterstützung des Verifizierungsprozesses. Dabei signalisieren fehlende Vor- und Nachbedingungen an Interaktionsknoten Lücken im Klassendiagramm. Da die Autoren in ihrem Ansatz keine Regeln zur Automatisierung der Zuordnung von

56 48 Konsistenzsicherung durch heuristische Kritiken Elementen des Klassendiagramms zu den Knoten im Graphen beschreiben und zudem der Use Case-Graph eher als methodische Unterstützung des Menschen gesehen werden kann, kommt dieser Ansatz für eine weitere Betrachtung nicht in Frage Umsetzung der Inter-Modell-Kritiken Wie bereits erläutert, unterscheiden sich Use Cases und Domain Models inhaltlich voneinander. Während das Domain Model die Struktur der Domäne abbildet, beschreiben die einzelnen Use Cases Interaktionen des Anwenders mit einem System innerhalb dieser Domäne. Dabei nutzen vor allem die einzelnen Schritte des Hauptszenarios die Entitäten des Domain Models und verändern diese. Kurz gesagt: Use Cases verändern als Funktion die Entitäten des Domain Models. Betrachtet man diesen Sachverhalt aus Sicht der Konsistenz, so ist zu beachten, dass zum einen die vom Use Case durchgeführten Aktionen vom Domain Model unterstützt werden müssen und zum anderen diese auch im gegenwärtigen Zustand des Modells erlaubt sein müssen. Analog zu den Intra-Modell-Kritiken lassen sich auch die Inter-Modell-Kritiken in zwei Kategorien unterteilen. So gibt es die Kategorie Domain Model Use Cases- Kritiken für alle Kritiken, die prüfen, ob ein gewisses Element aus dem Domain Model in den Use Cases vorkommt und entsprechend für die Gegenrichtung, die Kategorie Use Cases Domain Model-Kritiken. Diese Kritiken prüfen Use Case-Elemente auf ihr Vorkommen im Domain Model. Zu beachten ist, dass nicht alle Felder eines Use Cases einen entsprechenden Gegenpart im Domain Model besitzen. So dient beispielsweise der Eintrag für die technische Variante lediglich dazu, die für die Implementierung relevanten technischen Merkmale festzuhalten. Entsprechend lässt sich das von Cockburn abgeleitete Template ([Coc00]) für die Konsistenzprüfung, wie in Tabelle 4.5 gezeigt, vereinfachen. Abgesehen vom Hauptszenario und den zugehörigen Erweiterungen beschreiben die Felder nur die vorhandenen Entitäten, nicht aber, wie sie miteinander in Beziehung stehen. Diese Beziehungen werden erst innerhalb der Schritte der Szenariobeschreibung beziehungsweise der einzelnen Erweiterungsschritte erkennbar. Use Cases Domain Model-Kritiken entsprechen weitestgehend den Regeln zur Ableitung von Klassendiagrammen aus Use Cases. Diese lassen sich in den meisten Fällen auf die Nominal-Technik von Abbott zurückführen und ordnen den einzelnen Wortarten im Use Case Modellelemente im Domain Model zu. So nutzt beispielsweise Cachia in seinem Artikel [Cac03] die folgenden, von Dennis ([Den02]) für englischsprachige Use Cases erstellten, Regeln: Ein Gattungsbegriff impliziert eine Klasse. Ein Eigenname oder eine direkte Referenz implizieren ein Objekt (Instanz einer

57 4.3 Inter-Modell-Kritiken 49 Klasse). Ein Sammelbegriff impliziert eine Klasse, erstellt von einer Gruppe von Objekten einer anderen Klasse. Ein Adjektiv impliziert ein Attribut. Ein Verb des Tuns impliziert eine Operation. Ein Verb des Seins impliziert eine Klassifikation. Ein Verb des Habens impliziert eine Aggregation oder eine Assoziation. Ein transitives Verb (kommen mit einem Akkusativ vor z.b. schlagen, sehen, lieben) impliziert eine Operation. Ein intransitives Verb (kommen mit einem Dativ vor z.b. lachen, denken, schlafen) impliziert eine Exception. Ein Prädikat oder ein beschreibendes Verb implizieren eine Operation. Ein Adverb impliziert ein Attribut einer Beziehung oder eine Operation. Use Case Nr. <ID> Vorbedingung <Titel> <Vorbedingung> Mindestgarantie <Mindestgarantie> Erfolgsgarantie <Erfolgsgarantie> Stakeholder Hauptakteur Stakeholder <Stakeholder> <Hauptakteur> Interessen <Interesse> Auslöser <Auslöser> Hauptszenario Akteur Aktion <ID> <Akteur> <Aktion> Erweiterungen <ID> <Erweiterungsgrund> Akteur Aktion <ID> <Akteur> <Aktion> Tabelle 4.5: Relevante Felder des Use Case-Templates nach Cockburn [Coc00]

58 50 Konsistenzsicherung durch heuristische Kritiken Song und Yano [SYT04] beziehen neben der Erkennung von Wortarten auch noch die Zugehörigkeit zu gewissen Kategorien sowie Domänenwissen mit in ihre Ableitung ein, um so auch versteckte Klassen zu erkennen. Dabei betrachten sie 14 Arten von Klassen, wie zum Beispiel Rollen oder Orte. Insgesamt kommen sie auf vier Regeln zur Erkennung von Nomen, sieben Regeln für Verben und neun Regeln für die Eliminierung irrelevanter Daten. Wie unschwer zu erkennen ist, benötigt man zur Durchführung beider Ansätze eine komplexe Sprachanalyse. Besonders die Unterscheidung zwischen Gattungsbegriffen und Eigennamen sowie die Zuordnung der einzelnen Verben in die oben genannten Gruppen erfordert weitreichende Kenntnisse über die verwendete Sprache. Hinzu kommt, dass diese Analysen auf Wörterbüchern basieren, die die enthaltenen Wörter in die entsprechenden Kategorien einteilen. Da es sich jedoch bei den Domänenbegriffen oft um Fremd- oder gar Fachwörter handelt, ist nur schwer zu garantieren, dass diese sich in den verwendeten, meist einsprachigen Wörterbüchern wiederfinden. Erschwert wird diese Zuordnung zudem durch den potentiellen Gebrauch synonymer Begriffe. Entsprechend kommen hier für die Überprüfung nur ausgewählte Regeln in Frage, sodass für die Konsistenzsicherung weitere Mittel nötig sind. Verknüpft man die Use Cases, ähnlich der Beschreibung von Glinz ([Gli00]), mit dem Domain Model, so wäre der erste Punkt, bezüglich der Unterstützung der im Szenario genutzten Funktionen durch das Domain Model, sichergestellt beziehungsweise prüfbar. Wie von Glinz vorgeschlagen, können in die Szenariobeschreibung der Use Cases Operationsaufrufe in Form von Verweisen auf das Domain Model eingefügt werden, um so die Fähigkeiten im Domain Model zu adressieren (Abbildung 4.2). Führt ein Link ins Leere, so wird die genutzte Fähigkeit von der Domäne nicht unterstützt, oder zumindest nicht vom stellvertretenden Modell. Abbildung 4.2: Szenariobeschreibung mit eingefügten Links. Generell können die Links in jedes Feld des Use Cases eingefügt werden, jedoch beschreiben der Auslöser, die einzelnen Aktionen des Szenarios sowie der Erweiterungsgrund mit den zugehörigen Aktionen die relevanten Interaktionen zwischen den Entitäten. Dieses aktive Einfügen des Zusammenhangs zwischen Use Case und Domain Model durch den Use Case-Autor hat, neben der Konsistenzsicherung, noch einen weiteren positiven Nebeneffekt. So führt das Identifizieren der passenden Entität beziehungsweise der zugehörigen Fähigkeit zu einer Reflexion und Validierung des Use Cases und der in ihm

59 4.3 Inter-Modell-Kritiken 51 enthaltenen Schritte. Dies hilft dem Anwender bereits beim Verfassen des Use Cases einige logische Fehler zu erkennen. Neben dem Autor des Use Cases kann auch der Leser von der Verknüpfung beider Modelle profitieren. So helfen ihm die Links, die einzelnen Schritte einfacher in das Gesamtmodell einzuordnen und diese so besser zu verstehen. Zeichnet man für jedes Use Case ausgehend von den genutzten Fähigkeiten der Entitäten Graphen, in denen die Entitäten entsprechend der Aufrufe miteinander verknüpft sind, so kann man das Problem auf ein Graph-Matching-Problem reduzieren. Hierbei muss geprüft werden, ob der zum Use Case gehörende Graph im modellierten Domain Model enthalten ist. Bei der Beantwortung dieser Frage müssen modellierte Vererbungen und eingeschränkte Assoziationen besonders berücksichtigt werden. Eine Beispielanwendung dieser Methodik wird im Anhang A.1 gezeigt. Neben der einfachen Überprüfung der Existenz einer für die durchzuführende Aktion nötigen Fähigkeit, könnte in einem weiteren Schritt geprüft werden, ob eine Operation im gegenwärtigen Zustand des Domain Models überhaupt durchführbar oder auf Grund interner Beschränkungen gar verboten ist. Hierzu muss die Erreichbarkeit der Operationen und der aktuelle Zustand des Modells festgehalten werden. Erschwerend hinzu kommen Use Cases, die aufeinander aufbauen. Somit müssen auch deren Zustände betrachtet werden. Eine denkbare Möglichkeit für die Beurteilung der im aktuellen Zustand erlaubten Aktionen wäre die Einbeziehung von OCL-Anweisungen in die Zustandsanalyse und daraus abgeleitet die Beantwortung, ob die geplante Zustandsänderung von den Beschränkungen des Modells geduldet wird. Jedoch würde sich hier zunächst eine Umwandlung der Use Cases in Zustandsautomaten oder Aktivitätsdiagramme, als Zwischenschritt auf dem Weg zur Zustandskontrollen, anbieten. Denn diese Modelle sind weitaus formaler gehalten als ein Use Case und können die Anforderungen als Ganzes modellieren. Da weder die systematische Auswertung von OCL-Anweisungen noch die Transformation von Use Cases im Fokus dieser Arbeit steht, kann dieser weiterführende Ansatz lediglich als Hinweis auf zukünftige Arbeiten gesehen werden. Bei den Domain Model Use Cases-Kritiken ist das Zuordnungsproblem aus Abschnitt 2.5 zu berücksichtigen. Denn durch die Tatsache, dass ein Use Case nicht zwangsläufig alle Entitäten im Domain Model adressieren muss, entsteht bei der Zuordnung der Domain Model-Objekte zu den Objekten im Use Case die Frage, ob es überhaupt einen Gegenwert auf Seiten des Use Cases gibt, oder ob dieses Objekt in die nicht zu berücksichtigende Menge fällt. Somit bleibt diese Richtung nur für Domain Models prüfbar, die speziell für diesen einen Anwendungsfall konzipiert sind und somit jedes Objekt im Domain Model ein Gegenüber in einem oder mehreren Use Cases besitzt. Für diesen Idealfall können die in diesem Abschnitt erwähnten Maßnahmen in umgekehrter Richtung angewandt werden.

60 52 Konsistenzsicherung durch heuristische Kritiken Links zwischen Use Case und Domain Model Für die Links zwischen Use Case und Domain Model gibt es vier mögliche Zugriffsarten, die bei der Realisierung zu betrachten sind. Zunächst kann ein Akteur im Szenario des Use Cases auf eine einzelne Entität zugreifen. Hier reicht die Nennung des Entitätsnamens. Eine weitere Zugriffsart ist die Adressierung einer Fähigkeit innerhalb einer Entität. Hier sollte neben dem Namen der Entität auch der Name der Fähigkeit genannt werden. Die Syntax orientiert sich hier an der gängigen Syntax für Methodenaufrufe in objektorientierten Programmiersprachen (siehe Abbildung 4.2). Ein Sonderfall ist die Nutzung von Gettern und Settern, die nach verbreiteter Meinung nicht extra im Modell angegeben werden, da sie sich implizit aus dem Vorhandensein des Attributs (beziehungsweise der Eigenschaft) ableiten lassen. Dennoch lassen sie sich referenzieren. Neben diesen direkten Zugriffen gibt es noch zwei Möglichkeiten, indirekt auf Eigenschaften und Fähigkeiten zuzugreifen. Diese indirekten Zugriffe werden im Modell anhand von Assoziationen, Aggregationen beziehungsweise Kompositionen und Generalisierungen modelliert. Entitäten, die über Assoziationen oder Aggregationen verbunden sind, adressiert man, als wenn die beiden Entitäten bei der jeweils anderen als Eigenschaft notiert wären und diese über einen Getter verfügten. Eine Ausnahme bildet die verbotene Assoziation. Hier wird die entsprechende Entität nicht als Eigenschaft der anderen realisiert. Bei Generalisierungen werden die Eigenschaften und Fähigkeiten der Elternentität auf das Kind übertragen. Entsprechend können sie wie direkt in der Kind-Entität beschriebe Werte adressiert werden. Bei der Realisierung eines Interfaces verhält es sich ähnlich. Tabelle 4.6 zeigt noch mal alle möglichen Adressierungsarten, jeweils mit den entsprechenden Domain Model-Elementen. Dabei sind die Eigenschaften und Fähigkeiten, die sich aus den Referenzen ergeben, kursiv dargestellt. Gleiches gilt für die Getter und Setter, die sich aus den Eigenschaften ergeben. Mit der Domain Model-Erweiterung bietet das Kritiksystem von HeRA entsprechende Methoden zur Prüfung der Links und dem Vorhandensein entsprechender Eigenschaften und Fähigkeiten (siehe Abschnitt 4.4). Neben den manuellen Links können auch noch die mit dem Use Case verknüpften Glossareinträge als Maß für die Relevanz eines Begriffes für die Konsistenzsicherung herangezogen werden. So legt das Vorhandensein eines Begriffes innerhalb der Szenariobeschreibung, der gleichzeitig auch im Glossar definiert ist, nahe, dass dieser Begriff auch für das Domain Model relevant sein könnte und somit bei der Konsistenzprüfung berücksichtigt werden sollte.

61 4.3 Inter-Modell-Kritiken 53 Link im Use Case direkte Links Entität Entität.doit() Entität.getSomething() Entität.setSomething() Modellierung im Domain Model Entität something doit() getsomething() setsomething() indirekte Links Aggregation Ganzes Ganzes.getTeil().doit() Ganzes.getTeil().getSomething() Ganzes.getTeil().setSomething() Ganzes teil getteil() setteil() Teil something doit() getsomething() setsomething() indirekte Links Generalisierung Kind Kind.doit() Kind.getSomething() Kind.setSomething() Kind something doit() getsomething() setsomething() Eltern something doit() getsomething() setsomething() Tabelle 4.6: Beispieladressierung von Elementen im Domain Model Somit ergibt sich für die Berücksichtigung bei der Konsistenzprüfung die folgende Definition, bezüglich der Relevanz: Definition 4.7: Erhöhte Relevanz für die Konsistenzprüfung Eine erhöhte Relevanz für die Berücksichtigung bei der Konsistenzprüfung ergibt sich durch a) das Auftreten einer manuellen Verknüpfung zwischen Use Case und Domain Model oder b) dem Vorkommen eines Use Case-Begriffes im Glossar. Problematische Fälle Aus Sicht der Konsistenzprüfung bleiben einige problematische Bereiche offen. So lassen sich zum Beispiel die Kardinalitäten mangels Gegenpart im Use Case nicht verifizieren. Somit ist lediglich eine Plausibilitätsprüfung innerhalb des Modells anhand der gegebenen Faktoren möglich. Auch die Eigenschaften einer Entität werden nur indirekt über die sie manipulierenden Fähigkeiten im Use Case wiederzufinden sein. Abschließend kann nun festgehalten werden, dass die hier erstellten Kritiken nach der

62 54 Konsistenzsicherung durch heuristische Kritiken Einteilung von Knauss ([Kna10]) sowohl mittel-pro-aktiv als auch stark interpretierend sind (siehe Definition 4.5 und 4.6). Dabei werten sie aktiv die Eingaben des Nutzers aus, interpretieren diese und leiten so ein Feedback ab. 4.4 Anpassung des Kritiksystems von HeRA Analog zu den heuristischen Kritiken für Use Cases kann auch bei der Formulierung der Domain Model-Kritiken mit Hilfe eines Handlers auf die Werte der Domain Models zugegriffen werden. Das Domain Model liefert neben seinem Namen, einer Beschreibung, dem Autor, der Version und dem Reifegrad über die Methoden getclasses(), getcomments() und get- Edges() alle im Modell enthaltenen Elemente. Die einzelnen Modellelemente verfügen wiederum über entsprechende Mechanismen zum Zugriff auf ihre internen Werte. Markierung der fehlerhaften Elemente im Domain Model Die einzelnen Elemente des Domain Models können durch eine eindeutige ID identifiziert und einzelne Bereiche markiert werden. So lassen sich bei Entitäten beispielsweise Markierungen für das gesamte Objekt, den Entitätsnamen, die Attribute und Operationen sowie die Typenbezeichnung hinzufügen und der Nutzer kann so auf fehlerhafte Stellen hingewiesen werden. In den Attribut- und Operationsfeldern lassen sich zudem bestimmte Textstellen hervorheben. Die entsprechenden Kontextinformationen werden dabei durch den entsprechenden Bereich adressiert und anhand der ID dem Objekt zugewiesen. Tabelle 4.7 zeigt die einzelnen Markierungsmöglichkeiten und die entsprechenden Adressierungen. Die erste Spalte der Tabelle gibt dabei den in der Kritik zu adressierenden Kontext an, während die restlichen zwei Spalten die Art der Markierung wiedergeben. So können einige Elemente im Graph mit einem Symbol markiert, beziehungsweise gewisse Bereiche rot eingefärbt werden. Bei den Highlights handelt es sich um die Möglichkeit, bestimmte Wörter eines Textfeldes durch farbiges Unterstreichen hervorzuheben. Zur Überprüfung der modellierten Elemente bietet der Handler zudem eine Werkzeugsammlung an, mit der man neben der Validität von Links auch prüfen kann, ob es zu einem Begriff eine Entität im Domain Model gibt oder ob zwei Entitäten durch eine Kante verbunden sind.

63 4.4 Anpassung des Kritiksystems von HeRA 55 Adresse Marke Highlight Beispiel classcell_<id> classname_<id> classtype_<id> attributes_<id> operations_<id> X X X X X X X edgecell_<id> source/targetrole_<id> source/targetmultiplicity_<id> source/targettype_<id> description_<id> X X X X X commentcell_<id> comment_<id> X X - X Tabelle 4.7: Markierungen und ihre Adressen Berücksichtigung des Reifegrads eines Modells Da unter Umständen das gerade erstellte Modell noch im konzeptionellen Status ist und so noch keine Inter-Modell-Kritiken für die Konsistenzsicherung gegenüber den Use Cases in Frage kommen, erlaubt es die Erweiterung, den Domain Models Reifegrade zuzuweisen. Anhand dieser Reifegrade kann der Autor die zu erstellende Kritik auf bestimmte Reifegrade beschränken. Hierzu lassen sich die Modelle in die von Knauss ([Kna10]) beschriebenen sechs Reifegrade (Tabelle 4.8) einteilen. Reifegrad Konzept Skizze Entwurf Rohfassung Vorschlag Version.x.y Beschreibung grobe Struktur, vereinzelte Entitäten unvollständiges Modell vollständiges Modell, jedoch ohne Konsistenz inhaltlich vollständig, strukturelle Änderungen noch möglich inhaltlich vollständige und konsistente Fassung, jedoch noch ungeprüft geprüfte und freigegebene Fassung Tabelle 4.8: Reifegrade nach [Kna10] Listing 4.4 zeigt einen Codeausschnitt zur Berücksichtigung des Reifegrades bei der Realisierung der heuristischen Kritiken. Die Regel der anzupassenden Kritik muss lediglich um die entsprechenden Zeilen erweitert werden.

64 56 Konsistenzsicherung durch heuristische Kritiken 1 var dms = domainmodelhandler.getallelements(); 2 3 for(var i=0; i<dms.length; i++){ 4 if(dms[0].getstate() > 2){ 5 6 <heuristische Regel> 7 } 8 } Listing 4.4: Erweiterung von heuristischen Regeln zur Berücksichtigung des Reifegrads Die Tabellen A.2 und A.3 im Anhang fassen neben den in diesem Kapitel beschriebene Kritiken, noch einmal alle im Verlaufe dieser Arbeit entstandenen Kritiken zusammen.

65 57 5 Weiterführende Ergebnisse Dieses Kapitel beschreibt Ergebnisse, die im Verlauf dieser Arbeit entstanden sind, sich jedoch nicht direkt der Konsistenzsicherung unter Zuhilfenahme heuristischer Kritiken einordnen lassen. Diese Ergebnisse dienen vielmehr der Prävention von Inkonsistenzen zwischen den beiden Modellen, wie beispielsweise der gezielten Generierung von Vorschlägen für die Modellierung im Domain Model (Abschnitt 5.1) oder der Verbesserung des Domain Models durch die Realisierung der bereits in Abschnitt 3.1 kurz angerissenen Katalogkomponente zur Integration von Analysemustern (Abschnitt 5.2). Der vorgestellte Katalog lässt sich dabei ebenfalls über heuristische Kritiken ansteuern und so aktiv durch das Vorschlagen gespeicherter Muster auf die Modellierung einwirken. Die in diesem Kapitel erörterten Ergebnisse wurden dabei weitestgehend im Prototypen realisiert und so auf ihre Funktion und den Nutzen überprüft. 5.1 Prävention Zur Prävention können bereits bei der Eingabe der Modellelemente Informationen über dessen korrekte Verwendung angezeigt werden. So lässt sich zum Beispiel darauf hinweisen, dass für Entitäten Nomen als Namen genutzt werden sollten und dass auf die Angabe von Gettern und Settern verzichtet werden sollte, um so die Modelle übersichtlicher zu gestalten. Entsprechende Hinweise ließen sich über die ersten drei Kritiken aus der Arbeit von Knauss (Abschnitt 4.1) realisieren. Zusätzlich werden die Links zwischen Use Case und Domain Model (siehe Abschnitt 4.2.2) beim Einfügen über das Kontextmenü bereits auf ihre Validität geprüft und gewisse Begriffe aus ausgewählten Use Case-Feldern zur Modellierung im Domain Model vorgeschlagen. Ableitung von Vorschlägen aus den Use Cases Wie bereits in Abschnitt erläutert, gibt es zwar gewisse Regeln zur Ableitung von Domain Models aus Use Cases, welche die Use Case-Einträge entsprechend ihrer Wortfamilie den Objekten des Domain Models zuordnen und so eine Ableitung denkbar machen. Da jedoch eine automatisierte Ableitung auf Grund der Komplexität der natürlichen Sprache nicht ohne weiteres umsetzbar ist, soll in diesem Abschnitt eine Teilableitung beschrieben werden. Diese geschieht manuell durch den Nutzer, der vom System aktiv durch Vorschläge unterstützen wird.

66 58 Weiterführende Ergebnisse Die manuelle Ableitung geschieht auf zwei Wegen. Zum einen kann der Benutzer mit Hilfe des Kontextmenüs einzelne Begriffe aus einem Use Case für die spätere Modellierung als Entität vormerken und so in das Domain Model aufnehmen. Zum anderen generiert HeRA aus den Use Cases eine Vorschlagsliste (Abbildung 5.1), in der dem Nutzer potentielle Entitäten präsentiert werden. Abbildung 5.1: Liste mit Vorschlägen für potentielle Entitäten Die vorgeschlagenen Wörter können entweder ignoriert werden, so dass sie nicht mehr erwähnt werden, oder in einer zweiten Liste für die spätere Modellierung vorgemerkt werden. Bei der Generierung der Entitätsvorschläge nutzt die Erweiterung entsprechend der Erkenntnisse von Abbott (siehe Abschnitt 4.3.2) ein einfaches Nominalisierungsverfahren und schlägt alle im Use Case enthaltenen Nomen vor. Dabei werden standardmäßig nur der Auslöser, das Hauptszenario und dessen Erweiterungen berücksichtigt, andere Felder können jedoch über die Einstellungen hinzugefügt werden.

67 5.2 Katalogkomponente für Analysemuster Katalogkomponente für Analysemuster Neben der Konsistenzsicherung zwischen Use Cases und Domain Model lassen sich die heuristischen Kritiken und die dahinter stehenden Regeln auch nutzen, um den Benutzer bei der Eingabe des Domain Models zu unterstützen. So können neben allgemeinen Informationen, wie zum Beispiel Hinweise über ein systematisches Erschließen der relevanten Objekte, auch konkrete Informationen zur Verbesserung der Modellierung ausgegeben werden. Zur Realisierung dieser Benutzerunterstützung wurde die bereits in Abschnitt 3.1 beschriebene Katalogkomponente entsprechend der Vorgabe von Fischer [Fis94] in HeRA umgesetzt. Fischer beschreibt die Katalogkomponente als Sammlung gespeicherter Designvorschläge, die für eine Wiederverwendung in Folgeprojekten in Frage kommen. Diesen Vorgang der Wiederverwertung nennt er Design durch Modifizierung. Der Anwender sucht dabei aus den Designvorschlägen die Vorlage heraus, die seinen Wünschen entspricht oder zumindest diesen am nächsten kommt. Die ausgewählte Vorlage kann er dann nach dem Hinzufügen zum Eingabebereich nach seinen Wünschen erweitern und verändern. In der Domain Model-Erweiterung für HeRA enthält die Katalogkomponente oft genutzte Analysemuster, wie zum Beispiel im Buch [Fow96] von Fowler beschrieben. Diese Muster können bei Bedarf vom Anwender in das aktuell geöffnete Domain Model eingefügt werden. Dies hat zum Vorteil, dass zum einen der Eingabeprozess gerade für unerfahrene Anwender vereinfacht wird und zum anderen die Modelle zu einem gewissen Grad standardisiert werden und somit sowohl Qualität als auch Lesbarkeit steigen. Definition 5.1: Analysemuster (engl. analysis pattern) Ein Analysemuster ist eine Gruppe von Klassen [Entitäten] mit feststehenden Verantwortlichkeiten und Interaktionen, die eine bestimmte - wiederkehrende - Problemlösung beschreiben. nach Heide Balzert [Bal05, S. 526] Analysemuster beschreiben in der Praxis bewährte Strukturen für häufig auftretenden Probleme. Diese Strukturen sind dabei soweit verallgemeinert, dass sie mit geringfügigen Veränderungen wiederverwendet werden können und so das erprobte Wissen in das eigene Projekt importiert werden kann. Die Katalogkomponente ist dabei bidirektional gehalten und erlaubt es so dem Nutzer, nicht nur Vorlagen aus dem Katalog in sein Modell zu integrieren, sondern auch eigene Analysemuster hinzuzufügen oder bestehende zu löschen. Dies hat den Vorteil, dass die Auswahl jederzeit auf die aktuellen Bedürfnisse angepasst, neue Erkenntnisse integriert, aber auch veraltetes Wissen entfernt werden kann.

68 60 Weiterführende Ergebnisse Neben der explorativen Ansicht der Muster ist die Katalogkomponente ebenfalls in das Kritiksystem integriert und kann so gezielt genutzt werden, um dem Anwender im Verlauf des Eingabeprozesses sinnvolle Muster vorzuschlagen und so zu helfen, die Qualität des Modells zu verbessern. Somit ist der Nutzer nicht gezwungen, selbst nach einer besseren Lösung als der Eigenen zu suchen. Diese Unterstützung kommt vor allem dem unerfahrenen Nutzer zu Gute. Ihm fehlt die Erfahrung, die ihm hilft, zu erkennen, wann es sinnvoll ist, ein Analysemuster anzuwenden. Aber auch der erfahrene Anwender zieht seine Vorteile aus dieser Verknüpfung von Kritiksystem und Katalogkomponente, denn gerade in komplexen Modellen kann es schnell passieren, dass man nicht auf den ersten Blick erkennt, dass eine alternative Modellierung sinnvoller wäre. Realisierung der Katalogkomponente Die Katalogkomponente mit den Analysemustern (Abbildung 5.2) wird an der gleichen Stelle in die grafische Oberfläche von HeRA integriert wie auch die Simulationskomponenten. Diese kommt für das Domain Model nicht in Frage und so kann der freie Bereich während der Modellierung anderweitig genutzt werden. Abbildung 5.2: Katalogkomponente für Strukturmuster Die Analysemuster können über die Navigationsleiste durchsucht und gegebenenfalls in das gegenwärtig geöffnete Domain Model integriert werden. Für jedes Muster wird dabei eine grafische Abbildung, ein Name sowie eine optional einzublendende Beschreibung bereitgehalten. Neue Muster können im normalen Editor modelliert werden und über das Kontextmenü zur Katalogkomponente hinzugefügt werden. Innerhalb des Kataloges ist lediglich eine

69 5.2 Katalogkomponente für Analysemuster 61 Bearbeitung des Namens sowie der Beschreibung des Analysemusters möglich. Geänderte wie auch neu hinzugefügte Muster müssen vor dem Beenden von HeRA einzeln gespeichert werden und werden dann beim nächsten Programmstart automatisch geladen. Im Prototypen wurden aus dem Buch von Fowler [Fow96] exemplarisch die Muster Party und Event umgesetzt. Eine Erweiterung dieser Auswahl ist jedoch denkbar. Beispielkritik Besitzen zwei Entitäten mehr als drei identische Einträge, so könnte eine Generalisierung in Betracht kommen. Die angeschlossene Regel (Listing 5.1) erkennt dies und schlägt das Party-Muster vor. Adressiert werden die einzelnen Muster der Katalogkomponente durch den Schlüssel PatternPanel_<Patternname>. 1 var dms = domainmodelhandler.getallelements(); 2 var aktiv = true; 3 if(aktiv){ 4 for(var h=0; h<dms.length; h++){ 5 var tools = domainmodelhandler.getvalidationtoolsformodel(dms[h]); 6 var entities = dms[h].getentities(); 7 for(var i=0; i<entities.length; i++){ 8 var feat1 = tools.getemptystringlist(); 9 feat1.addall(entities[i].getfeatures()); 10 feat1.addall(tools.getfeaturesforownassoziations(entities[i])); 11 for(var j=i+1; j<entities.length; j++){ 12 var eq = 0; 13 var feat2 = tools.getemptystringlist(); 14 feat2.addall(entities[j].getfeatures()); 15 feat2.addall(tools.getfeaturesforownassoziations(entities[j])); 16 for(var k=0; k<feat1.size(); k++){ 17 for(var l=0; l<feat2.size(); l++){ 18 if(feat1.get(k).equals(feat2.get(l))){ 19 eq++; 20 } 21 } 22 } 23 if(eq > parameter){ 24 contextlist.addcontext( Elternklasse modellieren,project, 25 dms[h], PatternPanel_Party ); 26 } 27 } 28 } 29 } 30 } Listing 5.1: Heuristische Regel zur Prüfung möglicher Generalisierungen

70 62 Weiterführende Ergebnisse 5.3 Kommentare als Glossareinträge Die im Domain Model realisierten Kommentarfelder sind in ihrer Bedeutung den Glossareinträgen der Use Cases recht ähnlich. Daher liegt es nahe, beide Elemente miteinander zu verknüpfen. Entsprechend dieser Symmetrie ist es möglich, sowohl den Inhalt der Kommentarfelder in einen neuen Glossareintrag zu speichern, als auch die bestehende Definition eines Eintrages in ein Kommentarfeld zu kopieren. Entsprechende Kommentarfelder sind durch eine Einfärbung der rechten oberen Ecke gekennzeichnet. Diese Fähigkeit des Editors erlaubt es dem Modellierer, direkt auf das bereits im Projekt gespeicherte Wissen zuzugreifen und dieses für eine bessere Erläuterung der Entitäten zu nutzen. Neben der so wegfallenden Redundanz in der Beschreibung eines Begriffes, kann durch diese Verknüpfung mit den Glossareinträgen auch eine aktive Validierung der Begriffsdefinitionen erreicht werden. Denn sollte der Modellierer bemerken, dass die bereits im Glossar gespeicherte Definition nicht mit der Definition der modellierten Entität übereinstimmt, so kann er eine Negotiation dieses Begriffes und der zugehörigen Definition anregen und so die widersprüchlichen Definitionen beheben. 5.4 Export Die mit HeRA erstellten Domain Models lassen sich als Bilddatei exportieren und so in Anforderungsdokumente übertragen. Neben dem Export in Form eines Bildes lassen sich Modelle ebenso aus einem alten Projekt in ein neues Projekt übertragen. Das Austauschformat entspricht jedoch keinem gängigen Format, sodass ein Import in andere Tools nicht möglich ist. Eine zusätzliche Exportierung in das XMI-Format wäre denkbar. So ließen sich die Modelle in speziellen Case-Tools für den Entwurf importieren und dort weiterverarbeiten. Dies würde beispielsweise die Nutzung eines Codegenerators erlauben, der aus dem Domain Model einen groben Rumpfcode erzeugt, welcher dann im Lauf des Entwurfs weiter genutzt werden kann. Durch die Übernahme des Modells aus der Anforderungsphase in den Entwurf würden zusätzlich beide Phasen noch enger verknüpft werden. Wie dieses Kapitel zeigt, gibt es einige Möglichkeiten, neben den heuristischen Kritiken, die ja nur reaktiv auf eine Aktion des Nutzers agieren können, bereits konstruktiv in die einzelnen Schritte einzugreifen und so präventiv zu wirken. Mit Ausnahme der hier vorgestellten Exportfunktion, die eine Verknüpfung hin zur Entwurfsphase repräsentiert, unterstützen die anderen Funktionen den Nutzer aktiv bei seiner Arbeit und versuchen dabei Inkonsistenzen gar nicht erst entstehen zu lassen.

71 63 6 Abschließende Betrachtung der erarbeiteten Ergebnisse Im letzten Kapitel dieser Arbeit werden die erarbeiteten Ergebnisse resümierend in einem Fazit dargestellt und anschließend von bestehenden Arbeiten abgegrenzt. Darüber hinaus wird ein Ausblick auf zukünftige Arbeiten gewährt. 6.1 Fazit Im Rahmen dieser Arbeit wurde dem Leser aufgeführt, welchen Stellenwert Domain Models in der Software-Entwicklung einnehmen und welcher Nutzen sich aus ihrer Verwendung ergibt. So lässt sich, wie in Kapitel 2 beschrieben, die Anforderungsanalyse sowie die daraus resultierende Dokumentation der Anforderungen durch die Modellierung der Domäne aktiv unterstützen und Inkonsistenzen aufdecken. Kapitel 3 zeigt, wie ein sinnvoller und benutzerfreundlicher Editor für die Erstellung und Bearbeitung von Domain Models aussehen kann. Auch lässt dieses Kapitel erkennen, wie passend die Nutzung des UML-Klassendiagramms als Notation zur Darstellung der Domäne ist. Wie durch einfache Mittel die Konsistenz zwischen Use Cases und Domain Model geprüft und durch heuristische Kritiken gesichert werden kann, beschreiben Kapitel 4 und 5. Während Kapitel 4 zeigt, dass bereits das manuelle Einfügen von Links in die Felder des Use Cases zur Adressierung der Domain Model-Elemente ausreicht, um beide Modelle auf ihre Konsistenz zueinander zu prüfen, erläutert Kapitel 5, wie diese Konsistenz bereits durch präventive Maßnahmen unterstützt werden kann. Besonders die in Abschnitt 5.2 erläuterte Katalogkomponente für Analysemuster bietet dem Nutzer einen echten Mehrwert, da er so zum einen Vorschläge für die Modellierung nachschlagen kann, HeRA aber zum anderen auch in der Lage ist, ihn durch heuristische Kritiken aktiv bei seiner Arbeit zu unterstützen und ihm so gezielt Verbesserungsvorschläge für bestimmte Bereiche im Modell unterbreiten kann. Der im Verlauf dieser Arbeit entstandene Prototyp ist noch nicht ausgereift für den täglichen Gebrauch, reicht aber aus, um zu zeigen, dass mit Hilfe einfacher Links und der Formulierung von Kritiken zur Validierung dieser Links sowie einer kontrollierten Unterstützung des Erstellungsprozesses bereits recht konsistente Modelle erstellt werden können.

72 64 Abschließende Betrachtung der erarbeiteten Ergebnisse Verbesserungsbedarf besteht vor allem im Bereich der Performance und der Usability. Ein Großteil der Probleme lassen sich allem Anschein nach auf das genutzte J-Graph- Framework zurückführen. Besonders in Sachen Usability verhält es sich nicht besonders flexibel und so gestalten sich Anpassungen der bestehenden Elemente des Frameworks und deren Verhalten als besonders aufwändig. Abhilfe könnte hier der Austausch oder gar eine Neuentwicklung der grafischen Komponente schaffen. Auch die Realisierung eines Layoutalgorithmus wäre zur Verbesserung der Handhabbarkeit sinnvoll. Generell scheint mit diesem einfachen, aber dennoch recht wirksamen Ansatz der Balanceakt gelungen, zum einen die Use Cases um genügend Informationen zu erweitern, um damit die Konsistenz zum Domain Model zu überprüfen, zum anderen jedoch die Lesbarkeit und Verwendbarkeit der Use Cases größtenteils beizubehalten. Würde man HeRA um einen Filter erweitern, der die hinzugefügten Links bei Bedarf aus- beziehungsweise einblendet, könnte man sogar aus Sicht des Lesers den bestehenden Grad an Lesbarkeit und Verwendbarkeit beibehalten. Lediglich der Autor würde mit dem Aufwand der Verlinkung belastet werden. Jedoch bekommt dieser für diesen recht geringen Mehraufwand ein direktes Feedback bezüglich der Korrektheit seiner Arbeit und zudem bietet der Prozess des Verlinkens gleichzeitig die Gelegenheit zur Reflexion und Validierung des aktuellen Arbeitsschrittes. Alles in allem sollte sich der kleine Mehraufwand für alle beteiligten Parteien rentieren. Zu klären bleibt, inwieweit der hier beschriebene Editor, zusammen mit der Erweiterung des Kritiksystems, die von Fischer ([Fis94]) beschriebene Spezifikationskomponente erfüllt und in welchem Umfang die Ergebnisse dieser Arbeit auch auf den Gebrauch des UML-Klassendiagramms im Entwurf übertragen werden können. 6.2 Abgrenzung zu ähnlichen Konzepten Der folgende Abschnitt grenzt die hier vorgestellten Ergebnisse von bestehenden Ergebnissen ab und hebt so die neu ermittelten Erkenntnisse hervor. ArgoUML Das auf einen Prototypen von Robbins und Redmiles zurückgehende Entwurfswerkzeug ArgoUML 1 realisiert eine Designumgebung für kritikgestütztes Feedback bei Entwurfsentscheidungen. ArgoUML folgt dabei ebenso wie HeRA bei der Umsetzung der grafischen Oberfläche dem Konzept von Fischer ([Fis94]). ArgoUML nimmt dabei jedoch nur bedingt Bezug auf die Anforderungen. Es unterstützt zwar die grafische Darstellung von Use Case-Diagrammen und Klassendiagrammen, jedoch liegt der Fokus von ArgoUML im Gegensatz zu HeRA und somit auch der erstellten Erweiterung, auf der Umsetzung von Designentscheidungen im Entwurf. Eine Verwaltung von Use Cases ist hingegen nicht angedacht und somit ist auch nicht deren Konsistenz in Bezug auf Domain Models prüfbar. 1

73 6.3 Anregungen für zukünftige Arbeiten 65 Parallelen zu HeRA ergeben sich ebenfalls in der Umsetzung eines Kritiksystems. So bietet ArgoUML ebenfalls die Möglichkeit, anhand von Kritiken die Qualität der erstellten Modelle zu verbessern (siehe [Arg11]). Besonders in Bezug auf die Kritiken für das Klassendiagramm ergeben sich so Übereinstimmungen mit den in Abschnitt 4.2 beschriebenen heuristischen Kritiken für Domain Models. Auf Grund der fehlenden Use Case-Unterstützung von ArgoUML, ergibt sich gegenüber dem hier präsentierten Prototypen ein beachtliches Differenzierungsmerkmal in Bezug auf die Konsistenzsicherung zwischen Use Cases und Domain Models. Ansatz von Glinz Die erarbeiteten Ergebnisse von Glinz ([Gli00]) können zum Teil als Vorlage gesehen werden, die dieser Arbeit zugrunde lagen. Das hier erstellte Konzept zeigt dabei, wie die von Glinz vorgeschlagenen Links zwischen Use Cases und Klassendiagramm für die Konsistenzsicherung in Bezug auf Domain Models genutzt werden können. Abweichungen ergeben sich dabei jedoch aus der Berücksichtigung der mit der Verwendung von Domain Models auftretenden Zuordnungsproblematik (Abschnitt 2.5) sowie der Tatsache, dass die Regeln für die Konsistenzsicherung auf anpassbaren und somit erweiterbaren heuristische Kritiken basieren. Andere Ansätze Andere Konzepte zur Konsistenzsicherung sind entweder nur manuell durch den Benutzer anhand der aufgeführten Regeln durchführbar ([KPW97]) oder beschreiben wie Liang ([Lia02]) nur die Ableitung in eine Richtung, nicht aber die Prüfung bestehender Modelle. Des Weiteren benötigt die von Liang beschriebene Ableitung ein manuell erstelltes Zwischenmodell. Auch die Arbeit von Cachia ([Cac03]) sowie die von Song und Yano ([SYT04]) betrachten lediglich die Ableitung. Allen gemein ist die Tatsache, dass sie sich nur mit dem Zusammenhang zwischen Use Cases und Klassendiagrammen, nicht aber mit dem zwischen Use Cases und Domain Model beschäftigen. 6.3 Anregungen für zukünftige Arbeiten Dieser Abschnitt beinhaltet Ansätze für weiterführende Arbeiten, welche während der Auseinandersetzung mit der hier betrachteten Thematik entstanden sind. Sie konnten entweder auf Grund inhaltlicher Abweichungen vom hier bearbeiteten Kernthema nicht aufgegriffen werden oder waren für eine Realisierung zu weitreichend.

74 66 Abschließende Betrachtung der erarbeiteten Ergebnisse Erweiterung der Konsistenzprüfung um eine aktive Zustandskontrolle Wie bereits in Abschnitt 4.3 beschrieben, könnte die in dieser Arbeit entwickelte Konsistenzprüfung noch um eine aktive Zustandskontrolle erweitert werden und so den gegenwärtigen Zustand des Domain Model bei der Prüfung berücksichtigen. Hierzu wäre eine Auswertung der gegebenenfalls in den Kommentarfeldern festgehaltenen OCL-Bedingungen sowie die Transformation der Use Cases in Aktivitätsdiagramme denkbar. In diesem Rahmen wäre zu prüfen, inwieweit hierzu die parallel zu dieser Arbeit entstandenen Ergebnisse von Gross ([Gro11]) zur Ableitung von Aktivitätsdiagrammen aus Use Cases mit dem Ziel der Unterstützung des Entwurfs genutzt werden können Erweiterung des Kritiksystems Da das bisher beschriebene Kritiksystem bisher lediglich auf Basis der Identität die Konsistenz prüft und somit bereits an der Erkennung zweier semantisch identischer Begriffe, die jedoch auf Grund verschiedener Konventionen in Use Case und Domain Model unterschiedlich dargestellt werden, die Identität nicht erkennt, wären die folgenden zwei Erweiterungen des Kritiksystems denkbar, diese Problemstellung zu überwinden: weitergehende Einbeziehung der Glossareinträge und des in ihnen gespeicherten Wissens, zum Beispiel Synonyme. Erweiterung des Kritiksystems um linguistische Funktionen, zum Beispiel zur Erkennung von Wortarten Erweiterung des Domain Model-Editors Neben der Erweiterung des Kritiksystems wäre auch ein Ausbau des hier erstellten Editors denkbar. So ließe sich der Notationsumfang um weitere Modelle des Requirement- Prozesses erweitern. Denkbar wären hier vor allem dynamische Modell wie das Sequenz-, oder Aktivitätsdiagramm. Durch eine derartige Erweiterung könnten weitere Modellarten mit den Anforderungen verknüpft und gegebenenfalls durch heuristische Kritiken kontrolliert werden Kooperationsperspektive zwischen zwei Eingabebereichen Für die Vereinfachung der Modellierung wäre zu prüfen, ob es hilfreich wäre, neben der teilautomatischen Ableitung von möglichen Objekten auch eine zweite Perspektive in HeRA umzusetzen, die eine zeitgleiche Betrachtung des Domain Models und eines Use Cases erlaubt. Gegebenenfalls macht dieser Anzeigemodus bereits bei der Bearbeitung der Use Cases Sinn, da so nicht andauernd zwischen zwei angrenzenden Use Cases hin und her gewechselt werden muss.

75 6.3 Anregungen für zukünftige Arbeiten 67 Als mögliche Realisierung käme hier eine sekundäre Anzeige für die Elemente des Projektes innerhalb der Simulationskomponente von HeRA in Betracht. Zusammen mit der bestehenden Möglichkeit, einzelne Komponenten wie zum Beispiel die Projektsicht auszublenden, würde so der beschränkte Platz für beide Perspektiven reichen. Der Eingabebereich sollte dabei jedoch weiterhin als Mittelpunkt wahrgenommen werden Design History für Änderungsentscheidungen Robbins und Redmiles ([RR98]) beschreiben für ihren Prototypen ArgoUML zur Unterstützung des Nutzers beim Entwurfsprozess eine Design History, die Änderungen über die Zeit verfolgbar macht. Gerade durch das Hinzufügen einer grafischen Komponente durch den Domain Model-Editor käme eine derartige Protokollierung der Modelländerungen, verbunden mit einer Begründung, auch für HeRA in Frage. Hier könnte der Modellierer frühere Änderungen des Modells anhand von Kommentaren nachverfolgen, die mit den Änderungen gespeichert werden, und erklären, warum sie durchgeführt wurden. Dabei muss nicht zwangsläufig jede kleine Anpassung dokumentiert werden. Es reicht, wenn lediglich weitreichende Änderungen festgehalten werden, wie zum Beispiel das Hinzufügen einer neuen Entität. Denkbar wäre hier das Anfertigen von Snapshots nach relevanten Änderungen. Zu klären wäre, ob diese Auswahl von relevanten Speicherpunkten automatisiert oder manuell durch den Benutzer geschehen sollte Komponente zur grafischen Präsentation von Feedbacks Anstatt nur Probleme anzuzeigen, kann auch die Präsentation der gefundenen Übereinstimmungen sinnvoll sein, um auf die Konsistenz beziehungsweise die herrschende Inkonsistenz zwischen Modellen hinzuweisen. Somit wäre eine Simulationskomponente denkbar, die eine statistische Auswertung der Kritiken erlaubt und das Ergebnis dem Anwender entsprechend präsentiert Verwaltung von Teilmodellen Wie bereits in Abschnitt 2.5 erläutert, ergibt sich durch Unabhängigkeit des Domain Models zu den realisierten Anforderungen die Tatsache, dass ein Domain Model oft mehr beschreibt, als für die Realisierung der Anforderungen von Nöten wäre, da diese nur einen kleinen Ausschnitt des kompletten, vom Domain Model beschriebenen, Geschäftsbereiches betrachten. Somit wäre zur Steigerung der Übersicht und unter Umständen auch zur Verbesserung sowie Vereinfachung der Konsistenzprüfung ein Mechanismus sinnvoll, der es erlaubt, Bereiche eines Domain Models als Teilmodelle zu definieren und sie so einer Menge von Use Cases zuzuordnen. Betrachtet man das entgegengesetzte Szenario, also das Zusammenführen mehrerer Teilgeschäftsbereiche zu einem neuen großen, so wäre auch eine Fusion von Modellen betrachtenswert.

76 68 Abschließende Betrachtung der erarbeiteten Ergebnisse Verbesserung der Vorschlagskomponente Auch ein Ausbau der Vorschlagskomponente durch die Integration von linguistischen Methoden in HeRA mit dem Ziel der vollständigen Umsetzung der auf Abbott aufbauenden Ergebnisse wäre denkbar. So könnte die Qualität der Vorschläge erhöht und vielleicht sogar die Erkennung potentieller Referenzen realisiert werden.

77 69 Anhang A.1 HaLT-Beispiel Im Folgenden werden die in Abschnitt 4.3 beschriebenen Ergebnisses anhand eines reellen Beispiels verdeutlicht. In dem beschriebenen Beispiel geht es um die Realisierung einer Notfallsoftware für Smartphones. Die Software soll Jugendliche in Notfallsituationen beim Umgang mit stark alkoholisierten Freunden unterstützen. Dabei soll ihnen die Software anhand von geleiteten Dialogen helfen, die Situation zu erkennen und qualifizierte Gegenmaßnahmen einzuleiten. Im Verlauf der Anforderungsphase wurden zunächst einige Use Cases zur Beschreibung des funktionalen Umfangs der zu erstellenden Handysoftware aufgestellt (Tabelle A.1) und im Anschluss ein dazu passendes Domain Model (Abbildung A.1) erstellt. Die so entstandenen Anforderungen dienen nun als Grundlage zur Überprüfung der Konsistenz zwischen den Use Cases und dem Domain Model. ID Use Case Titel 1 Im Notfall gleich Notruf beginnen 2 Notfallplan als Simulation durchlaufen 3 Bewusstloses Opfer behandeln 4 Nicht bewusstlosen Freund nach Hause bringen 5 Ist ein Notfall eingetreten 6 Notruf abschließen 7 Programm beenden 8 Beatmung 9 Wiederbelebung nach Herzstillstand 10 Notfallplan durchlaufen 11 Anwendung auf anderes Handy weitergeben Tabelle A.1: Titel der Use Cases im HaLT-Projekt Zunächst einmal wurden auf das Domain Model die Intra-Modell-Kritiken aus Abschnitt angewandt und die so erkannten Fehler behoben. Dabei wurden die Entitätsnamen entsprechend der gängigen Konvention für Klassennamen zu einem zusammenhängenden Begriff zusammengefasst und der Anfangsbuchstabe großgeschrieben. An den Kompositionen wurde die entsprechende 0..1 Kardinalität auf Seiten des Aggregats eingefügt. Abbildung A.2 zeigt einige vom Kritiksystem erkannten Intra-Modell-Fehler und Abbildung A.3 stellt beispielhaft die Markierung des entsprechenden Bereichs im Domain Model dar. Nach der Behebung aller bemängelten Fehler entspricht das Domain Model der Abbildung A.4.

78 70 Anhang Abbildung A.1: Original Domain Model, vor der Anwendung von Kritiken Abbildung A.2: Problemsicht mit dem Hinweis auf die Intra-Modell-Fehler

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Dieses Dokument wurde verfasst von Dr. Jürgen Pitschke, BCS-Dr. Jürgen Pitschke, www.enterprise-design.eu Diese Unterlagen können frei für nicht-kommerzielle

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Das Lehren von objektorientierter Programmierung in Java mit

Das Lehren von objektorientierter Programmierung in Java mit Das Lehren von objektorientierter Programmierung in Java mit Dr. Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Überblick Kurz zu meiner Person Objektorientierung

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS)

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) BPM und egpm Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) C1 WPS GMBH //// Vogt-Kölln-Str. 30 //// 22527 HAMBURG

Mehr

A Domain Specific Language for Project Execution Models

A Domain Specific Language for Project Execution Models A Domain Specific Language for Project Execution Models Eugen Wachtel, Marco Kuhrmann, Georg Kalus Institut für Informatik Software & Systems Engineering Inhalt Einführung und Hintergrund Problembereiche

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Software Engineering. 2. Requirements Engineering. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering. 2. Requirements Engineering. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 2. Requirements Engineering Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 2. Requirements Engineering 2 Definitionen Anforderungen (Requirements) legen fest,

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Techniken der Projektentwicklungen

Techniken der Projektentwicklungen Von der Analyse zum Entwurf 5. Termin Vom Use Case zum Domänenmodell Bis zum nächsten Mal Vom Use Case zum Domänenmodell Vom Use Case zum Domänenmodell Was ist ein Domänenmodell? Graphische Beschreibung

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

IT-Organisation Superuser und Local Support

IT-Organisation Superuser und Local Support IT-Organisation Superuser und Local Support Inhalt VORWORT... 2 DEFINITION DER VORAUSSETZUNGEN... 3 ORGANISATION... 4 DEFINITION DES SUPERUSERS... 5 KOMPETENZABGRENZUNG... 6 AUFGABEN DES SUPERUSERS...

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die

Mehr

Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus!

Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus! Grüezi Mein Name ist Susanne Bandi und ich begrüsse Sie herzlich zum Kurzreferat: So richten Sie ihr Configuration Management auf die Zukunft aus! SIE sind hier, weil sie Potential sehen für ihr Configuration

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Praktikum Software Engineering

Praktikum Software Engineering Praktikum Software Engineering Verwendung von Enterprise Architect Pascal Weber, David Kulicke KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft

Mehr

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Alistair Cockburn Use Cases effektiv erstellen Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Die Regeln für Use Cases sicher beherrschen A Abdeckung Grad der 163

Mehr

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases Dr. Alexander Rachmann Hartmut Schmitt Softwareforen Leipzig 9. Mai 2014 Agenda Der Use-Case-Arbeitskreis der Gesellschaft für Informatik/Fachgruppe

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Roman Roelofsen Prof. Dr. Stephan Wilczek Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Konferenz Software Engineering & Management 2015 Dresden 19.03.2015 3 Rollen

Mehr

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam SmartOffer Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten Axel Kalenborn & Sebastian Adam Universität Trier Motivation: Phasen der Software Entwicklung Analyse Entwurf Umsetzung

Mehr

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Toolgestützte Prozessdokumentation Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Wir bieten unseren Kunden End-to-End Lösungen an Consulting Systems Integration

Mehr

Requirements Management Center

Requirements Management Center Requirements Management Center Überblick - 1 - Inhalt OMNITRACKER Requirements Management Center im Überblick Workflow im Überblick Informationsmodell Dokumentation und Reports Leistungsmerkmale Anforderungsdefinitionsprozess

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts Dokumentation Projekt: Innovation Management Plattform To Activate Creative Thoughts Betreuer: Dr. Joachim Kurzhöfer, Stefan Wunderlich, Jens Siewert Referentin: Yaping Lian Gliederung Einleitung: Agiles

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Softwareentwicklung

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Erstellung eines Pflichtenhefts (I)

Erstellung eines Pflichtenhefts (I) 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps

Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps Sprint Minus One Agiles RE zur Konzeption Mobiler Business Apps Steffen Hess steffen.hess@iese.fraunhofer.de Mobile Business Apps Business Prozesse Services Backend 2 3 Potential von mobilen Business Apps

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen.

Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen. Teil B: Erweiterungen Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen. Die folgenden Aufgaben und Ausführungen geben einige Hilfestellungen, welche (mindestens

Mehr

Integration von User Centered Design und Software-Entwicklung zur Optimierung von Workflow-Unterstützung

Integration von User Centered Design und Software-Entwicklung zur Optimierung von Workflow-Unterstützung Integration von User Centered Design und Software-Entwicklung zur Optimierung von Workflow-Unterstützung Lennart Grötzbach, Siemens Business Services, C-LAB Karsten Nebe, Universität Paderborn, C-LAB Aufbau

Mehr

Grundlagen der Programmentwicklung. Datenbanken und Softwareentwicklung I

Grundlagen der Programmentwicklung. Datenbanken und Softwareentwicklung I Schulinternes Curriculum Oberstufe, Fachbereich (Erstwahl und fortgeführt Wahlpflichtfach) Georg-Herwegh-Gymnasium Berlin Semester 1.Semester 3.Semester Inhaltsbezogene Kompetenzen/Standards Prozess-bezogene

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Klausur Software Engineering für WI (EuI)

Klausur Software Engineering für WI (EuI) Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

Entwicklung von Data-Warehouse-Systemen

Entwicklung von Data-Warehouse-Systemen Matthias Goeken Entwicklung von Data-Warehouse-Systemen Anforderungsmanagement, Modellierung, Implementierung Mit einem Geleitwort von Prof. Dr. Ulrich Hasenkamp Deutscher Universitäts-Verlag Inhaltsverzeichnis

Mehr

Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli

Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli Inhaltsverzeichnis 1 Rückblick auf Requirements Engineering Teil 1... 2 1.1 Was ist Requirements

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Individuelles Bachelorstudium. Software Engineering for Physics

Individuelles Bachelorstudium. Software Engineering for Physics Individuelles Bachelorstudium Software Engineering for Physics 1 Qualifikationsprofil Das individuelle Bachelorstudium Software Engineering for Physics vermittelt eine breite, praktische und theoretische

Mehr

Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007)

Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007) Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007) Kriterien zur Bewertung von Aufgaben: s. EPA: Gesamtanforderung umfasst inhaltliche, methodische und sprachliche Leistung; die Bearbeitung

Mehr

Requirements Engineering für IT Systeme

Requirements Engineering für IT Systeme Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Basistraining Vektorgrafik

Basistraining Vektorgrafik Basistraining Vektorgrafik Der kreative Pfad zu besseren Grafiken Bearbeitet von Von Glitschka 1. Auflage 2014. Taschenbuch. XVI, 234 S. Paperback ISBN 978 3 86490 182 9 Format (B x L): 18,5 x 24,5 cm

Mehr

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Model Driven Requirements Engineering im Energiehandel Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Requirements Engineering ETG-RPI Autor Lars van Brackel V.10

Mehr