Geschäftsprozessorientierte Anwendungsentwicklung

Transkript

1 Geschäftsprozessorientierte Anwendungsentwicklung Ein Ansatz zur Kopplung von ADONIS und Rational Rose eingereicht von: Michael Derntl DIPLOMARBEIT zur Erlangung des akademischen Grades Magister rerum socialium oeconomicarumque Magister der Sozial- und Wirtschaftswissenschaften (Mag. rer. soc. oec.) Fakultät für Wirtschaftswissenschaften und Informatik, Universität Wien Fakultät für Technische Naturwissenschaften und Informatik, Technische Universität Wien Studienrichtung: Wirtschaftsinformatik Begutachter: O. Univ.-Prof. Dr. Dimitris Karagiannis Dipl. Wi.-Inf. Harald Kühn Wien, im Oktober 2001

2 Ehrenwörtliche Erklärung Ehrenwörtliche Erklärung Ich versichere hiermit, dass ich die vorliegende Diplomarbeit selbständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe. Diese Diplomarbeit hat in gleicher oder ähnlicher Form im In- oder Ausland noch keiner Prüfungsbehörde vorgelegen. Wien, den 16. Oktober Michael Derntl Seite I

3 Vorwort Vorwort Im Zuge der Entstehung dieser Diplomarbeit sind nicht wenige Jahreszeiten gekommen und gegangen, und doch ist sie noch in einem letzten Kraftakt kurz vor Einführung der Studiengebühren fertiggestellt worden. Mein Dank gilt gleichsam - in alphabetischer Reihenfolge meinen Eltern, die mir das Studium der Wirtschaftsinformatik ermöglicht haben, meiner Freundin für die zwar fachfremde, jedoch rechtschreibtechnisch und grammatikalisch unerlässliche Durchsicht, den Herren Professor Dr. Karagiannis und Harald Kühn für richtungsgebende Anregungen, Betreuung und Verbesserungsvorschläge, sowie allen, die soweit vorgestoßen sind, diese Zeilen zu lesen. Möge diese Arbeit häufig in Literaturhinweisen auftauchen, auf dass sie nicht in der Bibliothek verstaube. Seite II

4 Inhalt Inhalt 1 Einführung Motivation Aufgabenstellung Aufbau der Arbeit Begriffe und Grundkonzepte Software-Entwicklung Begriffsbestimmung Phasen der Software-Entwicklung Unified Modeling Language (UML) Klassendiagramme Klassen Interfaces Beziehungen UseCase-Diagramme System UseCases Akteure Beziehungen Aktivitätsdiagramme Aktivitätszustand Transitionen Entscheidungsknoten Synchronsiation Swimlanes Unified Software Development Process Begriff und Hauptmerkmale Phasen CASE Geschäftsprozessmanagement Das BPMS-Paradigma Strategic Decision Process Reengineering Process Resource Allocation Process Workflow Process Performance Evaluation Process Geschäftsprozessmodellierung Werkzeuge Allgemeines zur Werkzeugunterstützung Das Geschäftsprozessmanagement-Werkzeug ADONIS Theoretische Basis Funktionalität und Einsatzszenarien Programmierschnittstellen ADLP AdoScript Das CASE-Werkzeug Rational Rose Seite I

5 Inhalt Theoretische Basis Funktionalität und Einsatzszenarien Programmierschnittstellen COM-API RoseScript Kopplungsansätze Einleitung Entscheidungsvariablen eines Kopplungsansatzes Dimensionen eines Kopplungsansatzes Bereitschaft des Kopplungsmoduls Onlinemodule Offlinemodule Kopplungsrichtung Automation der Transformation Automation der Integration Konkrete Ansätze Modellmanipulation Direkter Zugriff auf die Beschreibungssprache Indirekter Zugriff auf die Beschreibungssprache Automatische Ansätze Mapping-Scripts Integrationsregeln Integration im Offlinemodul Integration im Onlinemodul Benutzergesteuerte Ansätze Benutzergesteuerte Onlinemodule Benutzergesteuerte Offlinemodule Gemischte Ansätze Geschäftsprozesse und Anwendungsentwicklung Geschäftsprozessorientierte Anwendungen ADONIS-Standard-Anwendungsbibliothek Transformation von Modellen gleichen Typs Transformation von Modellen verschiedenen Typs Generierung von UseCase-Diagrammen aus Geschäftsprozessmodellen Generierung von Aktivitätsdiagrammen aus Geschäftsprozessmodellen Anwendungsorientierte Geschäftsprozesse Generierung von Geschäftsprozessmodellen aus UseCase- Diagrammen Zusammenfassung der Überführungsmethoden Fallstudie: AdoRose Kopplung von ADONIS und Rational Rose Realisierung Entwicklungsumgebung und Zielsystem Konzeption und Architektur ADLP-Client-Modul COM-Client-Modul Script-Parser Konvertierungsmodul Seite II

6 Inhalt Kommandozeile Benutzerschnittstelle Einsatz und Grenzen Zusammenfassung Verzeichnisse Abbildungen Literatur Abkürzungen Seite III

7 Motivation Einführung 1 Einführung 1.1 Motivation Da nicht zu übersehen ist, wie die Unified Modeling Language (UML) seit 1997 ein Standard der Object Management Group (OMG) in der objektorientierten Anwendungsentwicklung immer mehr an Bedeutung und Akzeptanz gewinnt, sind Kopplungsmechanismen zwischen organisations- und administrativ orientierten Werkzeugen einerseits, und IT-nahen Werkzeugen andererseits für eine umfassende Befriedigung der Kundenbedürfnisse unerlässlich. Gerade Unternehmen, die viele Mitarbeiter beschäftigen und eine Vielzahl konkreter und potentieller Arbeitsabläufe aufweisen, sind auf die Dokumentation und Transparenz ihrer Geschäftsprozesse angewiesen. Gute Beispiele für Unternehmen dieser Kategorie sind Banken und Versicherungen, bei deren Umstrukturierungen und Reorganisationsprojekten in der Regel mehrere hundert verschiedene Prozesse ermittelt werden können. Um diesen organisatorischen und administrativen Aufwand bewältigen zu können, wird viel Geld in Modellierungswerkzeuge investiert. Ein vor allem in Europa bedeutender Vertreter dieser Werkzeuge ist ADONIS 1, ein Geschäftsprozessmanagement- Werkzeug, das seit 1996 von der BOC Information Technologies Consulting GmbH entwickelt und weiterentwickelt wird. Auf ADONIS und seine Fähigkeiten und Einsatzmöglichkeiten wird in den Kapiteln des Hauptteils näher eingegangen (s. Kap. 3.2). Um die Automation der Geschäftsprozesse soweit als möglich zu fördern, können die Unternehmen weder auf spezialisierte, noch auf standardisierte Software verzichten. Es kommt häufig vor, dass Geschäftsprozesse auf Informationssysteme als Ressourcen zurückgreifen oder einzelne Aktivitäten vollständig durch Informationstechnologie umgesetzt werden. Da viele Software-Komponenten, vor allem betriebliche Informationssysteme, hochgradig prozess- und damit unternehmensspezifisch sind, muss das Unternehmen auf Grundlage der identifizierten Prozesse Anwendungssoftware entwickeln, die den Mitarbeitern der Ausführungsebene ermöglicht, in den Prozessen gewonnene Daten per Computer in das betriebliche Informationssystem - ohne über die reine Benutzung hinausgehende Kenntnisse - einzuspeisen. Als einfaches Beispiel hierfür könnte man die Kontoeröffnung eines neuen Kunden einer Bank anführen. Ein Ausschnitt aus diesem Prozess, der vor allem auch vom Kunden aktiv miterlebt wird, ist das übliche Frage- und Antwortspiel, bei dem die personenbezogenen Kundendaten vom Mitarbeiter in die dafür vorgesehene Eingabemaske eingetragen werden. Aus dieser Überlegung ist ersichtlich, wie eng das Geschäftsprozessmanagement und die Anwendungsentwicklung miteinander verwoben sind. Was zumindest für den Außenstehenden verborgen bleibt, um das obige Beispiel 1 ADONIS ist ein eingetragenes Warenzeichen der BOC Information Technologies Consulting GmbH. Seite 1

8 Aufgabenstellung Einführung weiterzuführen, ist der meist äußerst holprige Weg von der Prozessmodellierung bis zur fertigen und ins betriebliche Informationssystem integrierten Eingabemaske. Die Anwendungsentwickler können logischerweise aus den Geschäftsprozessmodellen nicht unmittelbar die Architektur des Softwaresystems ableiten, vor allem wie es mit bestehenden Komponenten integriert werden kann (Problematik der Legacy-Systeme). Daher ist es auch in diesem Bereich vordergründig notwendig, Modelle des Systems zu entwerfen. Die Firma Rational hat sich mit dieser Problematik intensiv auseinandergesetzt und eine Methodik entworfen, mit der iterativ und inkrementell ein Softwaresystem aus den Anforderungen entwickelt wird. Die Rede ist vom Unified Software Development Process, der ein mehrstufiges Phasenschema für die Entwicklung komplexer Software-Architekturen bereitstellt. Rational hat zur Unterstützung des Entwicklungsprozesses ein Werkzeug implementiert, das die Modellierung sämtlicher UML-Modelltypen integriert ermöglicht Rational Rose 2. Um die Einführung nicht mit technischen Details zu überladen, wird der Rational Unified Process als ein wichtiger Vertreter moderner und objektorientierter Software-Entwicklungsschemata in Kap und das CASE-Werkzeug Rational Rose in Kap. 3.3 näher beschrieben. Die Motivation dieser Arbeit lässt sich anhand obiger Ausführungen leicht formulieren. Es soll ein Konzept entworfen werden, das Ansätze zur Integration von Geschäftsprozessmodellierung und Anwendungsentwicklung liefert. Ziel ist ein methodisches Rahmenwerk, das einen einheitlichen und durchgängigen Weg von der Prozesserhebung bis zum fertigen Softwaresystem ermöglicht. Zentral ist die Realisierung eines Konzeptes zur Kopplung der beiden Werkzeuge ADONIS und Rational Rose. 1.2 Aufgabenstellung Diese Arbeit soll einerseits vorrangig konzeptionelle Ansätze zu entsprechenden Kopplungsmechanismen entwickeln, um andererseits gleichzeitig die theoretische Basis für die Realisierung eines Kopplungsmoduls der Werkzeuge ADONIS und Rational Rose zu bieten. Der Entwurf effektiver Kopplungen wirft eine Vielzahl von Fragen auf, die gründlich zu überlegen sind, unter anderem: Worauf spezialisiert sich das Geschäftsprozessmanagement-Werkzeug? Wo zeichnet es sich aus, ab wann scheint es sinnvoll, ein CASE-Werkzeug einzusetzen? Ab welchem Zeitpunkt ist es unumgänglich, mit einem CASE-Werkzeug weiterzuarbeiten? Gibt es einen Anhaltspunkt für eine gemeinsame Schnittstelle oder ein gemeinsames Metamodell? Sind etwaige Schnittstellen homogen? Welche Kopplungsansätze gibt es und welcher bringt kundenspezifisch die meisten Vorteile? 2 Rational Rose ist ein eingetragenes Warenzeichen der Rational Software Corporation. Seite 2

9 Aufbau der Arbeit Einführung Die Entwicklung eines Konzeptes zur Beantwortung dieser und anderer wesentlicher Fragen erfolgt - wie bereits oben angesprochen zuerst theoretisch, sowie anschließend konkret mittels je einem gängigen Vertreter seiner Sorte: Das Geschäftsprozessmanagement-Werkzeug ADONIS einerseits, Rational Rose als CASE-Werkzeug andererseits. Es sollen Möglichkeiten vorgestellt werden, wie Modelle zwischen den Werkzeugen ausgetauscht, also transformiert werden können. Um dies zu ermöglichen, müssen Regeln definiert werden, wie eine solche Transformation vonstatten gehen soll, wobei unterschiedliche Modelle durch ihre unterschiedliche Semantik auch individuelle Regeln erfordern. Die Transformation von UseCase-Diagrammen 3 als statische Sicht auf die Anforderungen an ein Software-System (s. Kap ) stellt andere Anforderungen als die Transformation dynamischer Modelle, wie etwa von Aktivitätsdiagrammen, die unter anderem dazu benutzt werden können, Abläufe, Objekt- und Kontrollflüsse innerhalb von UseCases zu beschreiben (s. Kap ). Ebenso wichtig sind Aussagen über grundsätzliche Ansätze der Transformation. So kann ein Kopplungsmodul über Nachrichten und individuelle Schnittstellen mit den Werkzeugen kommunizieren, oder aber einen Ansatz wählen, der über Mapping-Scripts, die Transformationsregeln beinhalten, funktioniert. Relevant ist auch die Frage nach dem Automatisierungsgrad der Kopplung: Wird der Benutzer miteinbezogen? Wenn ja, zu welchem Grad? Wird vollautomatisch transformiert? Wie hoch ist dann der Informationsverlust oder die Anzahl der Fehltransformationen? All diese Fragen werfen zahlreiche Dimensionen von Kopplungsmechanismen auf, die im Rahmen der Kopplungsansätze diskutiert werden (s. Kap. 4). Um auf eine gemeinsame begriffliche und sprachliche Basis zu gelangen, werden vorerst jene Begriffe und Grundkonzepte erläutert, die dann im Hauptstück ohne nähere Erläuterung verwendet werden. 1.3 Aufbau der Arbeit Folgende Abb. 1 zeigt die Struktur und die Zusammenhänge der Kapitel dieser Arbeit, jeweils mit kurzen Zusammenfassungen der Kapitelinhalte. Pfeile deuten auf inhaltliche, konzeptionelle oder begriffliche Abhängigkeit hin. 3 Für UseCases und UseCase-Diagramme existieren in der Literatur verschiedene Schreibweisen (u.a. "use case", "Use Case", "Use-Case"), in dieser Arbeit wird ausschließlich die Bezeichnung "UseCase" verwendet in Anlehnung an [OMG 1999]. Seite 3

10 Aufbau der Arbeit Einführung 1 Einführung Motivation, Aufgabenstellung und Aufbau der Arbeit. 2 Begriffe und Grundkonzepte Erläuterung von Konzepten und Begriffen der Software-Entwicklung allgemein, sowie der Unified Modeling Language (UML). Einführung in in Geschäftsprozessmanagement und Geschäftsprozessmodellierung. Einführungsteil 3 Werkzeuge Beschreibung von Funktionalität, Einsatzmöglichkeiten und Programmierschnittstellen des Geschäftsprozessmanagement- Werkzeugs ADONIS sowie des CASE-Werkzeugs Rational Rose. 4 Kopplungsansätze Definition der verschiedenen Dimensionen von Kopplungsansätzen, sowie Vorstellung von Möglichkeiten der Realisierung. Identifikation der Kluft zwischen Geschäftsprozessmanagement und Anwendungsentwicklung, sowie der Versuch der bidirektionalen Integration der beiden Disziplinen. 5 Fallstudie: AdoRose Vorstellung der Konzeption, Realisierung, Implementierung, Einsatzmöglichkeiten und Grenzen eines spezifischen Kopplungsansatzes zur Transformation von Modellinformationen der Werkzeuge ADONIS und Rational Rose: Das Kopplungsmodul AdoRose. Hauptteil 6 Zusammenfassung Zusammenfassung der Kernaussagen der Arbeit und Ausblick. 7 Verzeichnisse Verzeichnisse der Abbildungen, Literatur und Abkürzungen. Schlussteil Abb. 1: Kapitelstruktur der Arbeit Die Arbeit ist, wie in Abb. 1 ersichtlich, in drei wesentliche Teile gegliedert: Einführungs-, Haupt- und Schlussteil. Die durch die Pfeile dargestellte Kapitelabhängigkeit kann über mehrere Stufen führen: Da Kap. 6 von Kap. 5 inhaltlich abhängig ist, ist es auch von Kap. 3, 4 und 2 inhaltlich abhängig, wobei eine solche Abhängigkeit nicht als "Lesepflicht" zu verstehen ist, sondern die Gesamtheit der Abhängigkeiten einen Wegweiser durch die Arbeit bieten soll. Seite 4

11 Software-Entwicklung Begriffe und Grundkonzepte 2 Begriffe und Grundkonzepte 2.1 Software-Entwicklung Ein zentraler Begriff bereits in der Einleitung war die Software-Entwicklung, in dieser Arbeit auch synonym verwendet mit Anwendungsentwicklung und Software-Engineering Begriffsbestimmung Für Software-Engineering gibt es eine Menge von anderslautenden Begriffsbestimmungen, die jedoch im wesentlichen gleiches aussagen. Deshalb sei hier stellvertretend die Beschreibung des Begriffes von Sommerville [Sommerville 1995, S. 3-20] angeführt. Demnach beschäftigt sich Software-Engineering mit Methoden, Werkzeugen und Techniken des Managements, sowie der Erstellung und Entwicklung von Software-Produkten Phasen der Software-Entwicklung Da hier ein durchgängiges Konzept vom Geschäftsprozessmanagement bis zur fertigen Software-Lösung angestrebt wird, seien die wichtigsten Phasen der Software-Entwicklung angeführt. Phasenschemata des Software-Engineering haben schon seit den 60er-Jahren die Literatur beschäftigt, daher ist es auch verständlich, dass eine Vielzahl von Modellen existiert. Trotzdem können die meisten Modelle, wie beispielsweise das Wasserfallmodell [Royce 1970] oder das Spiralmodell [Boehm 1988] durch folgende Phasen charakterisiert werden [Sommerville 1995, S.10] (s. Abb. 2 4 ): Abb. 2: Phasen des Software-Engineering als Geschäftsprozessmodell 1. Anforderungsanalyse und -definition (requirements analysis and definition): In Zusammenarbeit mit den Benutzern werden Funktionalität, Einschränkungen und Ziele erhoben. Wichtig ist das gemeinsame Verständnis zwischen Entwicklern und Benutzern, die Anforderungen müssen also auch für die Benutzer verständlich repräsentiert werden, 4 Zur Erstellung sämtlicher Geschäftsprozessmodelle in dieser Arbeit, sowie für die Generierung der hier abgebildeten Grafiken von Geschäftsprozessmodellen wurde das Geschäftsprozessmanagement-Werkzeug ADONIS verwendet. Seite 5

12 Software-Entwicklung Begriffe und Grundkonzepte zum Beispiel durch einfache Modellierungstechniken wie das UseCase- Diagramm in UML (s. Kap ). 2. System- und Softwaredesign (system and software design): Die Anforderungen werden unterteilt in Hard- und Software-Anforderungen, sodass ein allgemeines Modell der Systemarchitektur entsteht. Das Softwaredesign liefert eine Vorgehensweise für die Umsetzung der Funktionalität der ausführbaren Programme. 3. Implementierung und Unit-Tests (implementation and unit testing): In dieser Phase wird die im Softwaredesign spezifizierte Funktionalität realisiert in Form eines oder mehrerer Programmmodule. Die einzelnen Module werden isoliert auf Erreichung der erwarteten Leistung getestet. 4. Integration und Systemtests (integration and system testing): Die in der vorangegangenen Phase entwickelten Programmmodule werden zu einem kompletten System integriert. Nach sorgfältiger Testung des integrierten Systems wird das Produkt an die Endbenutzer ausgeliefert. 5. Einführung und Wartung (operation and maintenance): Das System wird beim Kunden eingeführt. In früheren Zyklen nicht erkannte Fehler werden im Rahmen der Wartung ausgebessert. Die Wartung umfasst jedoch auch die Weiterentwicklung der Module und des Systems, um neuen Anforderungen gerecht zu werden. In der Regel ist dies die längste und teuerste Phase im Lebenszyklus eines Softwareprodukts Unified Modeling Language (UML) Da die Unified Modeling Language (UML) in den bisherigen Ausführungen eine Rolle gespielt hat, und auch weiterhin vor allem in Bezug auf die Modellierungswerkzeuge eine tragende Rolle spielen wird, seien hier einführend die wichtigsten Konzepte, Diagrammtypen und elemente erklärt. Aus der Tatsache, dass die UML-Spezifikation in der aktuellen Version 1.3 über 800 Seiten umfasst, lässt sich ableiten, dass hier wirklich nur äußerst kurz die für diese Arbeit relevanten Gebiete und Konstrukte der UML erläutert werden. UML ist eine grafische Modellierungssprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Softwaresystemen [OMG 1999]. UML basiert auf objektorientierten Software-Entwicklungskonzepten, die im Rahmen dieser Arbeit nicht näher erläutert werden können. Zur Einführung in objektorientierte Software-Entwicklung sei z. B. verwiesen auf [Meyer 1994]. Die UML unterscheidet Modelle und Diagramme. Modelle stellen bestimmte Aspekte eines Softwaresystems dar. Für diese Arbeit interessanter sind jedoch Diagramme. Diagramme stellen eine (grafische) Sicht auf ein Modell dar, wobei je nach Komplexität ein oder mehrere Diagramme ein Modell bilden können [Hitz et al. 1999]. In der UML-Spezifikation werden 9 verschiedene Diagrammtypen unterschieden [OMG 1999]: Klassendiagramme, Objekt- Diagramme, UseCase-Diagramme, Sequenzdiagramme, Kollaborationsdia- Seite 6

13 Software-Entwicklung Begriffe und Grundkonzepte gramme, Zustandsdiagramme, Aktivitätsdiagramme, Komponentendiagramme und Einsatzdiagramme. Für die weiteren Ausführungen relevant sind jedoch nur das Klassendiagramm, das UseCase-Diagramm und das Aktivitätsdiagramm, da diese drei im Wesentlichen als einzige sinnvolle Anhaltspunkte für eine Kopplung von Geschäftsprozess- und UML-Modellen dienen können. Diese Diagrammtypen und ihre Elemente werden nun genauer betrachtet Klassendiagramme Klassendiagramme (eigentlich static structure diagrams [OMG 1999]) gehören zur Gruppe der Strukturdiagramme, beschreiben also statische Aspekte des zu entwickelnden Systems unter Verwendung von Paketen, Klassen, Objekten, Interfaces (d.h. Schnittstellen) und deren Beziehungen Klassen Eine Klasse (s. Abb. 3 und Abb. 4) repräsentiert ein abstraktes oder konkretes Konzept aus dem Problembereich, also eine Menge von Objekten mit gemeinsamen Attributen und Operationen, wobei Attribute gemäss dem objektorientierten Konzept den Zustand, und Operationen das Verhalten eines Objektes zeigen. In der grafischen Repräsentation ist die Klasse horizontal in drei Abschnitte untergliedert. Im ersten (oberen) Abschnitt befindet sich der Name der Klasse und etwaige Einschränkungen (constraints), auf die hier nicht näher eingegangen wird. Im zweiten (mittleren) Abschnitt befinden sich die Attribute, und im dritten (unteren) Abschnitt befinden sich etwaige Operationen. Die unteren beiden Abschnitte (Attribute und Operationen) können je nach gewünschtem Detaillierungsgrad im Diagramm weggelassen werden. Abb. 3: Klasse Customer (detaillierte Notation) Interfaces Abb. 4: Klasse Customer (vereinfachte Notation) Ein Interface (deutsch "Schnittstelle", grafische Notation s. Abb. 5 und Abb. 6) ist dem Konzept einer abstrakten Klasse ähnlich; sie besitzt jedoch keine Attribute, sondern ausschließlich Operationen, die das Verhalten eines Elementes beschreiben. Interfaces können nicht instanziert werden, d.h. es können keine konkreten Objekte angelegt werden. Daher müssen alle Operationen einer Schnittstelle von einer konkreten Klasse implementiert werden, um ein Objekt mit dem beschriebenen Verhalten erzeugen zu können. Seite 7

14 Software-Entwicklung Begriffe und Grundkonzepte Abb. 5: Interface SecureInformation (detaillierte Notation) Abb. 6: Interface SecureInformation (vereinfachte Notation) Beziehungen Die wichtigsten Beziehungen innerhalb eines Klassendiagramms seien anhand eines kleinen Beispiels erläutert (s. Abb. 7). Abb. 7: Beispiel eines UML-Klassendiagramms Abb. 7 zeigt den stark vereinfachten Aufbau eines Unternehmens. Die Klasse Unternehmen ist über eine Aggregation mit der Klasse Abteilungen verknüpft. Das heißt, ein Unternehmen besteht aus mehreren Abteilungen, wobei die Abteilungen auch ohne das Unternehmen existieren können. Wären die Abteilungen vom Unternehmen existenzabhängig, so würde es sich um eine Komposition im Sinne der UML handeln. In diesem Fall wäre für die Notation anzumerken, dass die Raute am Ende der Beziehung ausgefüllt werden müsste. Seite 8

15 Software-Entwicklung Begriffe und Grundkonzepte Die Abteilung ist mit dem Angestellten über eine (binäre) Assoziation verbunden. Eine Assoziation beschreibt die gemeinsame Struktur einer Menge von Beziehungen zwischen Objekten zweier (binäre Assoziation) oder mehrerer Klassen. Sie hat in der Regel einen Namen, im dargelegten Fall ist das works in, d.h. Angestellte arbeiten in Abteilungen. An den Enden der Assoziation können nun Kardinalitäten (synonym auch Multiplizitäten) angegeben werden, welche die Anzahl der an einer Beziehung beteiligten Objekte festlegen. Typische Ausprägungen für Kardinalitäten sind 1 (genau ein Objekt), x..y (mindestens x, maximal y Objekte, z.b ). Ein Stern ( * ) deutet jeweils auf Beliebigkeit hin, was nur alleinstehend (weder Ober- noch Untergrenze), oder als beliebige Obergrenze wie in 1..* Sinn macht. Für obiges Beispiel bedeutet das, dass an einer Beziehung works in mit einer Abteilung mindestens ein Angestellter (1..*) vorkommen muss, umgekehrt es für jeden Angestellten nur eine works in -Beziehung mit einer Abteilung gibt. Umgangssprachlich formuliert: Ein Angestellter arbeitet in genau einer Abteilung, in einer Abteilung arbeitet mindestens ein Angestellter. Optional können an den Enden der Assoziationen auch die Rollen, welche die beteiligten Objekte an der Beziehung spielen, notiert werden. Die Klassen Angestellter und Kunde sind über eine Generalisierung mit der Klasse Person verbunden. Die Generalisierung stellt eine taxonomische Beziehung zwischen einer spezialisierten Klasse (Unter- oder Subklasse) und einer allgemeineren Klasse (Ober-, Basis- oder Superklasse) dar, wobei die Subklasse die Charakteristika der Superklasse erbt und weitere Merkmale hinzufügen kann [Hitz et al. 1999]. In der grafischen Notation zeigt die Generalisierung von der Subklasse über einen Pfeil mit unausgefülltem Dreieck zur Superklasse. Für das Beispiel bedeutet dies, dass sowohl Angestellte als auch Kunden (logischerweise) Personen mit Namen und anderen Eigenschaften sind. Der Kunde erweitert die geerbten Merkmale um eine Kundennummer, der Angestellte um ein Gehalt. Eine Person besitzt spezifische Personaldaten, die über die Operation "GetPersonalData" ermittelt werden können. Daraus resultiert die Abhängigkeitsbeziehung zur Klasse Personaldaten. Sie wird als gestrichelter Pfeil mit offener Spitze dargestellt. Die Klasse Personaldaten realisiert (Realisierungsbeziehung) das Interface SecureInformation, das heißt, dass die Personaldaten eine Operation zur Übertragung der Daten (Operation "Transmit") anbieten. Als alternative Notationsform dieses Beziehungstyps kann ein gestrichelter Pfeil mit geschlossener Spitze verwendet werden UseCase-Diagramme UseCase-Diagramme (deutsch auch Anwendungsfalldiagramme) beschreiben die Kernfunktionalität eines Systems und bestehen aus drei wesentlichen Bestandteilen: UseCases, Akteure (actors) und deren Beziehungen untereinander. Sie bilden einen wesentlichen Teil der Beschreibung der Anforderungen an ein System und sind durch recht einfache Notation sowohl von Entwicklern, als auch von Benutzern inhaltlich zu verstehen und bilden damit eine wichtige Austauschbasis zwischen Entwicklern und Kunden. Die Bestandteile sollen anhand eines kleinen Beispieldiagramms erklärt werden (s. Abb. 8). Seite 9

16 Software-Entwicklung Begriffe und Grundkonzepte System Abb. 8: UseCase-Diagramm Das zu entwickelnde System wird in der grafischen Notation durch ein Rechteck dargestellt, in dem die Anwendungsfälle platziert werden. Die Kanten des Rechtecks zeigen somit die Grenzen des Systems UseCases UseCases beschreiben einen Ausschnitt des Systemverhaltens. Im Beispiel oben beschreibt der UseCase Konto eröffnen jene Aktionen, die nötig sind, um ein neues Konto anzulegen. Im Allgemeinen sollte die Gesamtheit der identifizierten UseCases auch die Gesamtsystemfunktionalität dokumentieren, was sich in der Praxis bei größeren Projekten als sehr schwierig erweisen kann [Hitz et al. 1999]. Zur grafischen Notation von UseCases s. Abb Akteure Abb. 9: UseCase Kundendaten erfassen Die im Diagramm modellierten Akteure legen fest, wer mit dem System interagiert. Sie sind daher per definitionem außerhalb der Systemgrenzen platziert. Durch die Darstellung als Strichmännchen kommt die falsche Vermutung auf, dass Akteure ausschließlich menschlich sind. Es kann sich auch um Seite 10

17 Software-Entwicklung Begriffe und Grundkonzepte externe Systeme handeln, wie z.b. Datenbanken oder Mailsysteme. Menschliche Akteure befinden sich meist in der Benutzerrolle, das heißt, sie initiieren Anwendungsfälle, hingegen werden nicht-menschliche Akteure eher vom System benützt. Im Beispiel ist gut erkennbar, das Kunden und Angestellte das Eröffnen eines Kontos initiieren, die Kunden-Datenbank jedoch benützt wird, um die Kundendaten zu erfassen. Zur grafischen Notation s. Abb Beziehungen Abb. 10: Akteur Benutzer Anwendungsfalldiagramme können vier verschiedene Beziehungstypen beinhalten: Kommunikationsbeziehung (communicates relationship): Diese beschreibt eine Beziehung zwischen genau einem Akteur und genau einem UseCase und ist ungerichtet. Eine Kommunikationsbeziehung besagt entweder, dass der Akteur den UseCase initiiert (Kunde initiiert Kontoinformationen abrufen), oder dass der UseCase externe Akteure benützt (Teilnehmer verständigen benützt -System). Grafische Notation als Linie. Include-Beziehung (include relationship): Die include-beziehung ist gerichtet, verbindet genau zwei UseCases und besagt, dass der inkludierte UseCase in den inkludierenden UseCase eingefügt wird. Der inkludierte UseCase kommt zwingend im Ablauf des inkludierenden UseCases vor (Konto eröffnen inkludiert Kundendaten erfassen). Grafische Notation als Pfeil mit Beschriftung <<include>>. Extend-Beziehung (extend relationship): Die extend-beziehung besitzt eine ähnliche Semantik wie die include-beziehung, die Richtung ist jedoch umgekehrt und die zwingende Einschließung bedeutet hier eine mögliche Erweiterung (Geld abheben erweitert möglicherweise das Abrufen der Kontoinformationen). Grafische Notation als Pfeil mit Beschriftung <<extend>>. Generalisierung (generalization): Die Generalisierungsbeziehung zwischen zwei UseCases definiert, dass der erbende UseCase das gesamte Verhalten des Super-UseCases erbt und gegebenenfalls erweitern und überschreiben kann (Geschäftskonto eröffnen und Privatkonto eröffnen erben von Konto eröffnen). "Generalization between UseCases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations" [OMG 1999, Kap. 2 S. 120]. Grafische Darstellung erfolgt als Pfeil mit unausgefülltem gleichseitigen Dreieck als Spitze; zeigt vom Sub- zum Super-UseCase. Seite 11