Leseprobe
Inhaltsverzeichnis
0 Verzeichnisse
0.2 Abbildungsverzeichnis
0.3 Tabellenverzeichnis
0.4 Abkürzungsverzeichnis
1 Einleitung
1.1 Problemstellung
1.2 Vorgehensweise und Zielsetzung
2 Grundlagen
2.1 Dienste in Portalen
2.2 Kommunikations Portal
2.2.1 Corporate Portal / Enterprise Portal
2.2.2 Business Portal
2.2.3 Dokumentenverwaltung
2.2.4 Informationsdienste
2.2.5 Application Service Provider (ASP)
2.2.6 Berater
2.3 Zusammenfassung
2.4 Prozessmodelierungstechniken
2.4.1 ARIS
2.4.2 UML
2.4.3 Zusammenfassung
3 Analyse bestehender Systeme
3.1 Einführung
3.2 Beispiele
3.2.1 Intershop Enfinity
3.2.2 Adenin Enterprise Portal
3.2.3 BizTalk
3.3 Erkenntnisse und Auswertung
4 Entwurf
4.1 Ansichten
4.2 Anforderungen an das System
4.2.1 Technische Anforderungen
4.2.2 Betriebswirtschaftliche Anforderungen
4.3 Aufbau des Systems
4.3.1Überblick
4.3.2 Logische Komponenten
4.3.3 Visuelle Komponenten
4.3.4 Datenbank Anbindung
4.3.5 XML Import und Export
4.3.6 Identifikation der Komponenten
4.3.7 Erzeugung und Entfernen von Komponenten
4.3.8 Aufbau der Java Pakete
4.3.9 Verzeichnisstruktur des Systems
5 Fallbeispiel ADVICE
5.1 Einführung
5.2 Realisierung
6 Auswertungen und Erfahrungen
6.1 Design und Implementierung
6.2 Fallbeispiel ADVICE
7 Anhang
7.1 Literaturverzeichnis
7.2 XML Definition
0.2 Abbildungsverzeichnis
Abbildung 1 Kommunikationsportal Freemail
Abbildung 2 Business Portal von Festool USA
Abbildung 3 ARIS Haus
Abbildung 4 Beispiele für logische Verknüpfungen
Abbildung 5 Beispiel Bestellung
Abbildung 6 Anwendungsfalldiagramm
Abbildung 7 Klassendiagramm
Abbildung 8 Zustandsdiagramm
Abbildung 9 Aktivitätsdiagramm
Abbildung 10 Sequenzdiagramm
Abbildung 11 Kollaborationsdiagramm
Abbildung 12 Komponentendiagramm
Abbildung 13 Einsatzdiagramm
Abbildung 14 Komponenten von Enfinity
Abbildung 15 Visual Pipeline Manager
Abbildung 16 Ablauf einer Anfrage
Abbildung 17 Holschuld - Bringschuld
Abbildung 18 Aufbau Adenin
Abbildung 19 Verwaltung des Adenin Portals
Abbildung 20 Ansatzpunkte verschiedener Integrationswerkzeuge
Abbildung 21 Baum Ansicht
Abbildung 22 Vereinfachung des Entwicklungsprozesses durch das ESW
Abbildung 23 Drei Schichten Architektur
Abbildung 24 Portabilität von Java Programmen
Abbildung 25 EComponentManager
Abbildung 26 Erzeugung einer EComponent aus einem Modell
Abbildung 27 Kommunikation zwischen EComponents
Abbildung 28 Das komplette EService Werkzeug
Abbildung 29 Interface Menü
Abbildung 30 Anordnung der FlowConnection
Abbildung 31 Beispiel einer FlowConnection
Abbildung 32 TreeView
Abbildung 33 ER Modell für die Speicherung eines ESW Projektes in der Datenbank
Abbildung 34 Die Ebenen des Systems
Abbildung 35 Aufbau der XML Datei
Abbildung 36 Aufbau des ADVICE Systems
Abbildung 37 Die Seiten von Festo mit integriertem ADVICE Berater
Abbildung 38 Das ADVICE System als Sequenzdiagramm
Abbildung 39 Das Advice System im Kollaborationsdiagramm
Abbildung 40 Das ADVICE System in der Flow Ansicht
Abbildung 41 Das ADVICE System in der Baum Ansicht
0.3 Tabellenverzeichnis
Tabelle 1 Vergleich Enfinity - Intershop4
Tabelle 2 Funktionen der Menüleiste
Tabelle 3 Funktionen der Schaltflächen
Tabelle 4 Funktionen des Kontextmenüs
Tabelle 5 Funktionen des Properties Menü
Tabelle 6 TreeView
Tabelle 7 Datenbank Projekt Tabelle
Tabelle 8 Datenbank EComponent Tabelle
Tabelle 9 Datenbank FlowComponent Tabelle
Tabelle 10 Datenbank EConnection Tabelle
Tabelle 11 Datenbank FlowConnection
Tabelle 12 Erzeugen der XML Datei
Tabelle 13 Pakete des ESW Systems
Tabelle 14 Verzeichnisstruktur des Systems
0.4 Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
1.1 Problemstellung
Business Portale stellen kundenindividuell personalisiert Dienstleistungen zur Verfügung. Die Gesamtheit solcher Dienstleistungen soll fortan mit EService bezeichnet werden.
Die Dienstleistungen werden auf Grund der Markanforderungen und der erweiterten technischen Möglichkeiten immer umfangreicher. Sie bestehen aus z.T. komplexen Prozessen (z.B. Konditionengestaltung), die auf Grund der schnell wechselnden Kundenbeziehungen (z.B. auf Projektbasis) rasch rekombinierbar sein müssen. Hierfür ist der Datenaustausch mit verschiedensten meist heterogenen Systemen (z.B. ERP-Systeme, CRM-Systeme, etc.) nötig.
Diese immer komplexer werdenden Systeme erfordern einen immens steigenden Entwicklungs- aufwand. Daher ist es erstrebenswert ein Werkzeug zu besitzen, welches diesen Aufwand so weit wie möglich verringert. Im Rahmen dieser Studienarbeit soll untersucht werden inwieweit bestehende Werkzeuge dieses leisten können. Desweiteren ist ein Prototyp für die grafische Erstellung von EService Systemen zu realisieren. Dieser soll den folgenden Anforderungen genügen:
Grafischer Editor zur Erstellung von EService Systemen Offene Architektur, erweiterbar Standard Schnittstellen Java basierend Die Ergebnisse der Arbeit bilden einen Teil einer Werkzeugumgebung für das Engineering von Prozessen in Portalen.
1.2 Vorgehensweise und Zielsetzung
Zuerst werden in Kapitel zwei verschiedene Arten von Portalen untersucht um einen Einblick in die verschiedenen Arten von Systemen zu gewinnen. Es wird analysiert welche Komponenten zusammenarbeiten müssen um dynamische Serviceleistungen im Internet anbieten zu können. Desweiteren wird untersucht welche Möglichkeiten es gibt um solche Systeme formal zu beschreiben. Dazu wird ARIS und insbesondere UML auf Ihre Eignung für eine derartige Aufgabenstellung untersucht.
In Kapitel drei werden drei Applikationen (Intershop Enfinity, Adenin Enterprise Portal und Microsoft Biztalk) vorgestellt, welche für die Erstellung von EService Systemen benützt werden können. Sie greifen an jeweils unterschiedlichen Punkten an um eine Integration von Prozessen und Systemen zu erreichen. Es wird untersucht inwieweit sie für die Erstellung von EService Systemen geeignet sind. Es stellt sich heraus, dass sie zwar in dem für sie gedachten Einsatzgebiet durchaus ihre Berechtigung haben, aber für EService Systeme nur bedingt geeignet sind. Idealerweise kann man mit einem ESystem Werkzeug (ESW) ein EService System visuell zusammenstellen und konfigurieren und dann daraus das System direkt generieren lassen. Bisher ist kein Softwarewerkzeug bekannt welches genau darauf zugeschnitten ist.
Aus oben genannter Motivation heraus wurde ein Teil, die Benutzeroberfläche, eines solchen ESW konzeptioniert und implementiert. Zuerst wurden die Anforderungen an so ein System sowohl in betriebswirtschaftlicher, wie auch technischer Hinsicht untersucht. Dann wurde der Softwareentwurf erstellt. Dabei war zu berücksichtigen, dass das System Teil eines noch zu entwickelnden kompletten ESW ist. Dies ist in Kapitel vier beschrieben.
Das entwickelte Werkzeug wird dann wie in Kapitel fünf beschrieben in dem Projekt ADVICE eingesetzt. Hier wird ein elektronischer Verkaufsberater entwickelt. Die verschiedenen Komponenten des ADVICE Systems werden in dem ESW nachgebildet. Es wird untersucht wo die eventuellen Schwachstellen liegen.
Kapitel sechs enthält abschließende Betrachtungen und einen Ausblick.
2 Grundlagen
2.1 Dienste in Portalen
Im Internet haben sich zahlreiche Informationsangebote und Dienste etabliert. Bei Informationsangeboten wird zwischen vertikalen und horizontalen Angeboten unterschieden. Diese Kategorisierung spielt vor allem bei Internet Portalen und Marktplätzen eine wesentliche Rolle. Vertikale Angebote fokussieren auf eine Thematik oder eine Zielgruppe und fassen Angebote für diese Zielgruppe zusammen. In vertikalen Angeboten wird die gesamte Tiefe der Thematik abgedeckt. Horizontale Angebote fassen ein möglichst breites Spektrum zusammen ohne Teilbereiche in der vollen Tiefe abzudecken.
Portale sind ein zentraler Zugang zu Ressourcen aus verschiedenen Quellen. Ein Portal bietet somit einenÜberblicküber die angebotenen Informationen und erlaubt den direkten Zugriff. Je nach Art des Portals ergeben sich völlig verschiedene Aufgabenstellungen, die sich in verschiedenen Arten von Portalen niederschlagen. Im folgenden sollen verschiedene angebotene Dienste untersucht werden.
2.2 Kommunikations Portal
Es haben sich Unternehmen darauf spezialisiert ihren Kunden eine Informationsplattform zur Verfügung zu stellen. Zuerst beschränkte sich dies auf die Bereitstellung eines e-mail Postfachs. Inzwischen werden aber auch andere Kommunikationswege wie Fax, Anrufbeantworter, Short Message System (SMS) und Telefon angeboten. Dies wird meist mit Unified Messaging bezeichnet.
Durch die Integration der neuen Techniken steigt der Aufwand für die Erstellung und Anpassung eines solchen Systems rapide an. Es müssen die verschiedenen Module miteinander vernetzt und aufeinander abgestimmt werden. Einheitliche Schnittstellen sind erforderlich um einen sicheren Datenaustausch zu gewährleisten. Daher wäre es wünschenswert eine Entwicklungsumgebung zu besitzen, welche die Integration eines neuen Dienstes ohne großen Aufwand ermöglicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 Kommunikationsportal Freemail
2.2.1 Corporate Portal / Enterprise Portal (nach [Gurzki01b])
Das Corporate Portal oder auch Enterprise Portal ist als Unternehmens-Portal eine firmen- oder konzerninterne Anwendung für Mitarbeiter und bilden den Kern des Intranets. Es wird zwischen Enterprise Information Portals (EIP), Enterprise Application Portals (EAP) und Enterprise Knowledge Portals (EKP) unterschieden. Enterprise Information Portals dienen der Aggregation und Verwaltung von unternehmensinternen Informationen. Sie bieten die Möglichkeit Informationen abzulegen, zu strukturieren und wiederzufinden. Enterprise Application Portals (EAP) entstammen dem Host-Zugriff auf Enterprise Resource Planning Systeme und bieten eine Möglichkeit Daten aus diesen Systemen zu visualisieren, bzw. auf Informationen in diesem Systemen lesend oder schreibend zuzugreifen. Ein Beispiel für eine EAP-Anwendung ist ein web- basierendes E-Procurement-System. Enterprise Knowledge Portals enthalten Knowledge Management Werkzeuge zur Erfassung und Strukturierung von Wissen und dienen somit der effizienten Gestaltung des Wissenstransfers zwischen Mitarbeitern und zur Unterstützung von Entscheidungen.
2.2 Kommunikations Portal
2.2.2 Business Portal
Business Portale bilden die zentrale Anlaufstelle für Kunden eines Unternehmens. Sie beschränken sich jedoch nicht auf eine reine Information, wie zum Beispiel eine einfache UnternehmensWebsite, sondern bieten eine Vielzahl von Diensten rund um das Unternehmen und dessen Produkte an. Diese Dienste können nicht nur die Auswahl von Produkten, den Kauf (ShopFunktion), sondern auch den Bereich des After-Sales-Service (z.B. Support, Bestellung von Ersatzteilen, etc.) umfassen. In Business Portalen können Kunden-Gemeinschaften (Communities) integriert sein, die mit Foren dieöffentliche Kommunikation zwischen Unternehmen und Kunden, sowie die Kommunikation zwischen Kunden ermöglichen und somit die Bindung an das Unternehmen bzw. die Besuchshäufigkeit der Kunden erhöhen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 Business Portal von Festool USA
2.2.3 Dokumentenverwaltung
Es liegen immer mehr elektronische Datenmengen in Unternehmen vor. Diese müssen aufbereitet, verwaltet und gesichert werden. Das erfordert einen hohen personellen und technischen Aufwand.
Es ist zu beobachten, dass sich Unternehmen immer mehr auf ihre Kernkompetenzen beschränken. Benötigte Hilfsdienste wie Transport, Kantine oder eben auch die Datenspeicherung und Verwaltung werden ausgelagert. Aus dieser Aufgabe ergeben sich verschiedene Anforderungen. Die Daten müssen vor Verlusten durch technische Defekte aber auch durch unsachgemäße Bedienung geschützt werden. Damit die Informationen den Mitarbeitern zur Verfügung gestellt werden können ist ein System zur Vergabe von Rechten nötig. Es muss festgelegt werden, wer welche Information wie nutzen darf.
Der Außendienst, Telearbeit und die Kooperation mit anderen Firmen machen es nötig die Daten auch außerhalb des Intranets verfügbar zu machen. Dies kannüber den Laptop aber auch per PDA1, (Mobil) Telefon oder das Faxgerät geschehen. Um unbefugten Personen den Zutritt zu verwehren muss eine sichereÜbertragung gewährleistet werden.
2.2.4 Informationsdienste
Das World Wide Web wurde schon seit seinen Ursprüngen als Informationsmedium genützt. Die Anforderungen an die Daten sind im Laufe der Zeit gestiegen. Sie müssen nicht nur aktuell, sondern sollten auch gut strukturiert sein um die Auffindbarkeit der gesuchten Information zu erleichtern. Die bereitgestellten Datenmengen werden immer größer. In der Zwischenzeit ist es nicht mehr das Problem, dass eine Information nicht verfügbar ist, sondern besteht darin sie zu finden. Deshalb wird das Informationsmanagement und umfangreiche Suchmechanismen immer wichtiger. Das ist mit statischen HTML2 Seiten nicht realisierbar. Es wird immer mehr dazuübergegangen, die Webseiten individuell zu erzeugen um zu erreichen, dass ein Benutzer die für ihn relevanten Daten erhält.
Internet Portale sind ein thematisch orientierter Einstiegspunkt zu online verfügbaren Informationen. Sie enthalten einen Katalog mit thematisch sortierten und zumeist ausgewählten Verweisen (Links) auf andere Web-Angebote.
Oftmals spielt neben der Katalogfunktion bei vertikalen Internet-Portalen ein redaktionell betreutes Informationsangebot eine große Rolle um die Besucher zu häufiger Wiederkehr anzuregen. Gerade bei den führenden Internet Portalen im Consumer-Bereich (wie z.B. Yahoo) war dieser Trend in den letzten Jahren sehr ausgeprägt.
Als Beispiel sei ecin3 (vertikal) und yahoo [Yahoo02] (horizontal) angeführt.
2.2.5 Application Service Provider (ASP)
ASP wird vom deutschen ASP-Konsortium wie folgt definiert:
Das Geschäftsmodell ASP (Application Service Provider) basiert auf der Idee, dem Kundenüber einen vereinbarten Zeitraum Software-Lösungenüber das Internet bereit zu stellen. Der ASP betreibt als Geschäftspartner ein Rechenzentrum und ist verantwortlich für die IT-Infrastruktur. Hohe Verfügbarkeit und Performance der Applikationen sowie die Sicherheit der Kundendaten stehen dabei im Vordergrund. Die Bezahlung erfolgt in der Regel nach einem Mietmodell, das bestimmte Softwarepakete, Funktionen, Services und/oder getätigte Transaktionen berechnet. ASP bedeutet somit für den Kunden die Verlagerung von Aufgaben, die bisher der PC und damit verbundene PC-Netzwerkeübernahmen, ins Internet. ASPs unterstützen die Firmen dabei, sich auf ihre eigentliche Geschäftstätigkeit und Kernkompetenz zu konzentrieren.
[ASP01]
Neben den oben zitierten Vorteilen können auch Probleme und Risiken für Unternehmen entstehen, die sich für ASP entscheiden. Eventuell sicherheitsrelevante Daten sind für die Mitarbeiter des ASP Anbieters einsehbar. Desweiteren muss sichergestellt werden, dass der Dienst immer verfügbar ist. Bei einem Ausfall des ASP Providers oder der Verbindung zum Unternehmen können die
2.2 Kommunikations Portal
Mitarbeiter nicht mehr auf ihre Programme und Daten zugreifen.
Bei derÜbertragung der Daten zwischen ASP und Kunde muss die Datensicherheit durch geeignete Sicherheitsmaßnahmen vor dem Zugriff Dritter geschützt werden.
2.2.6 Berater
Momentan werdenüber das Internet vor allem C Klasse Güter verkauft. Sie haben einfach zu vergleichende Eigenschaften. Diese sind in der Regel in Katalogen einsehbar. Sollen jedoch andere Güter, wie Versicherungen, hochwertige Werkzeuge oder Haushaltsgeräteüber das Netz verkauft werden, setzt dies eine gute Beratung voraus. Es gibt zwei verschiedene Ansätze um dies zu realisieren:
Es wird dem Kunden die Möglichkeit geboten mit Fachleuten zu kommunizieren. Dabei werden z.B. bestehende Callcenterüber das Internet verfügbar gemacht. Dies kann durch Chats, Internettelefonie, E-mail oderähnliches geschehen.
Die andere Möglichkeit ist der Versuch intelligente Software zu entwickeln, die dem Kunden hilft seine Auswahl zu treffen. Im Idealfall wird sie mit natürlicher Spracheingabe und Sprachausgabe arbeiten.
Eine solche Software kann z.B. in ein Shopsystem, oder in eine umfangreiche Unternehmenswebsite integriert werden.
In diesem Bereich wird zur Zeit von Unternehmen und Forschungseinrichtungen intensiv geforscht. Als Beispiel sei das EU Projekt ADVICE (siehe [Gurzki01] und [Gurzki01a]) genannt.
Die Komplexität eines Beratersystems und damit der Entwicklungsaufwand steigt exponentiell zu dem Prozentsatz der richtig gegebenen Antworten an. Um einerseits möglichst jede Frage des Kunden beantworten zu können und andererseits die Entwicklungskosten im Rahmen zu halten wird man eine Software einsetzten die etwa 80% der Fragen korrekt beantwortet. Für die restlichen 20% wird ein Call Center nachgeschaltet.
2.3 Zusammenfassung
Es wurden verschiedene auf dem Internet basierende Dienste diskutiert. Diese stammen aus den unterschiedlichsten Anwendungsbereichen des Endkunden- wie auch Geschäftsbereiches. Trotzdem lassen sich Gemeinsamkeiten erkennen:
Die Dienste sind komplex und stellen keine isolierte Anwendung dar, sondern sind vielmehr in ein Gesamtkonzept eingebunden und arbeiten mit Backendsystemen, Datenbanken und anderen Diensten zusammen. Sie setzen verschiedene Kommunikationswege und Schnittstellen ein. Sie sollten eine offene Architektur aufweisen um auf zukünftige Entwicklungen reagieren und neue Techniken integrieren zu können.
Hier zeichnet sich ein Entwicklungsprozess ab, den das Internet durchlaufen hat: von einfachen isolierten Anwendungen hin zu komplexen vernetzten Systemen. Hieraus ergibt sich ein immer größer werdender Entwicklungs- und Wartungsaufwand für derartige Systeme. Daher wird es in Zukunft immer wichtiger geeignete Techniken, Hilfsmittel und Standards zu finden um dem steigenden Aufwand entgegenzuwirken.
2.4 Prozessmodelierungstechniken
2.4.1 nach [Scheer98]
Das ARIS Konzept wurde im Buch Scheer, ARIS - Vom Geschäftsmodell zum Anwendungssystem 1988 entwickelt. Es dient zur Reduktion der Komplexität der Geschäftsprozessbeschreibung durch die Strukturierung in Beschreibungssichten und Phasen eines Life-Cycle-Models.
ARIS4 unterscheidet vier Anwendungsaspekte:
Das ARIS-Konzept (Aris Haus) dient als Bezugsrahmen zur Geschäftsprozessbeschreibung ARIS stellt Modellierungsmethoden bereit, deren Meta-Strukturen in einem Informationsmodell zusammengestellt sind.
Das ARIS-Konzept ist Basis des von der IDS Prof. Scheer GmbH entwickelten Software Systems ARIS-Toolset zur Unterstützung der Modellierung.
Mit dem ARIS - House of Business Engeneering (HOBE) wird ein Ansatz zum ganzheitlichen computergestützten Geschäftsprozessmanagement bereitgestellt.
2.4 Prozessmodelierungstechniken
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3 ARIS Haus
Auf dem ARIS Konzept aufbauend wurde ab 1992 von der IDS Prof. Scheer GmbH das ARIS Toolset entwickelt. Dieses Software System unterstützt den Modellierer bei der Erstellung und Verwaltung von Modellen. Man hat zu unterscheiden zwischen dem ARIS Modell und dem ARIS Toolset. Während ersteres eine Methode darstellt ist zweiteres ein Softwarewerkzeug.
Der ARIS-HOBE Ansatz wurde ebenfalls in dem Buch Scheer, ARIS - vom Geschäftsprozess zum Anwendungssystem 1998 entwickelt. Er zeigt wie von der Gestaltung der Geschäftsprozesseüber deren Planung und Steuerung bis zur Umsetzung durch Workflow-Systeme und Funktionsbausteine vernetzte Regelkreise bestehen.
Die Methode „Ereignisgesteuerte Prozesskette“ (EPK) wurde von der Universität Saarland im Zusammenarbeit mit der SAP AG entwickelt. Sie ist zentraler Bestandteil der Modellierungskonzepte des Business Engeneering und Customizing des SAP R/3 Systems.
Einem Ereignis können mehrere Funktionen folgen, andererseits kann erst der Abschluss mehrerer Funktionen ein Ereignis auslösen. Die logischen Verknüpfungen werden durch UND ODER und Exklusiv-Oder (XOR) dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4 Beispiele für logische Verknüpfungen
Wie oben dargestellt werden Ereignisse mit Rauten symbolisiert, Kästchen stellen Funktionen dar. Die logischen Verknüpfungen werden durch Kreise repräsentiert.
Mit Hilfe der EPK ist es möglich betriebliche Abläufe darzustellen. Dies soll anhand eines praktischen Beispiels verdeutlicht werden. Es ist ein Bestellvorgang abzubilden. Ist der Bestellwert unter 1000 Euro, so wird die Bestellung direkt versandt. Liegt erüber 1000 Euro, so muss die Bestellung erst genehmigt werden. Dies stellt sich als Prozesskette wie folgt dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 Beispiel Bestellung
2.4 Prozessmodelierungstechniken
2.4.2 nach [Dumke01] und [Oestereich01]
Die Unified Modelling Language (UML) ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis zu diskutieren. Die UML wird seit 1998 als Standard angesehen. Sie lag und liegt weiterhin bei der Object Management Group5 zur Standardisierung vor.
Entwickelt wurde die UML von Grady Booch, Ivar Jacobsen und Jim Rumbaugh von Rational Rose Software6. Sie kombinierten die besten Ideen objektorientierter Entwicklungsmethoden und schufen daraus die UML. Viele führende Unternehmen der Computerbranche (Microsoft, Oracle, HewlettPackard,...) wirkten aktiv an der Entwicklung mit und unterstützen die UML.
Die UML ist keine Methode. Sie ist lediglich ein Satz von Notationen zur Formung einer allgemeinen Sprache zur Softwareentwicklung. Eine Methode beinhaltet Empfehlungen zur Vorgehensweise bei Entwicklungsprozessen. Um UML erfolgreich zu nutzen, ist es notwendig eine passende Methode zu entwickeln, welche die UML unterstützt.
Die Modellelemente der UML werden nach Diagrammtypen gegliedert. Im folgenden werden die verschiedenen Typen kurz erklärt. Anwendungsfalldiagramm 7
Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungsfällen und stellt die Beziehungen zwischen Akteuren und Anwendungsfällen dar. Es zeigt dasäußerlich erkennbare Systemverhalten aus der Sicht eines Anwenders.
Ein Akteur ist eine Person, Organisation oder wiederum ein System der mit dem Anwendungsfallsystem kommuniziert und es beeinflusst. Der Akteur befindet sich außerhalb der Systemgrenze, d.h. er ist nicht Teil des Anwendungsfallsystems.
Ein Anwendungsfall beschreibt die Art und Weise wie ein Akteur auf das System wirkt. Er ist eine Beschreibung für dasäußerlich sichtbare Systemverhalten. Alle Anwendungsfälle zusammen ergeben demnach das systembeschreibende Modell. Anwendungsfälle sind ein Hilfsmittel zur Anforderungsanalyse. Sie sollen verdeutlichen was das System leisten soll, aber nicht wie das System etwas leisten soll. Anwendungsfälle helfen die Kommunikation zwischen den zukünftigen Systemnutzern und den Systementwicklern zu unterstützen, bzw. zu verbessern.
Anwendungsfälle werden durch Ellipsen die den Namen des Anwendungsfalles tragen und einer Menge von beteiligten Objekten (Akteuren) dargestellt. Zu jedem Anwendungsfall gibt es eine Beschreibung in Textform. Die entsprechenden Anwendungsfälle und Akteure sind durch Linien miteinander verbunden. Akteure können durch Strichmännchen o.ä. Symbole dargestellt werden. Die Systemgrenze wird durch einen Rahmen um die Anwendungsfälle symbolisiert.
Anwendungsfälle können hierarchisch geschachtelt werden. Ein Anwendungsfall kann also durch eine weiteres Anwendungsfalldiagramm in mehrere genauere Anwendungsfälle untergliedert werden. Anwendungsfälle tragen zur Identifikation einen eindeutigen Namen oder eine Nummer.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6 Anwendungsfalldiagramm
Klassendiagramm 8
Eine Klasse ist eine Zusammenfassung gleichartiger Objekte9. Ein Objekt ist ein aktives, konkret vorhandenes Modellelement in einem laufendem System. Die Gleichartigkeit bezieht sich auf Eigenschaften (Attribute) und/oder auf Fähigkeiten (Operationen/Methoden) der Objekte einer Klasse. Eine Klasse enthält gewissermaßen die Konstruktionsbeschreibung für Objekte die mit ihr erzeugt werden. Das Verhalten der Objekte wird durch die Möglichkeit eines Objektes, Nachrichten zu empfangen und zu verstehen beschrieben.
Ein Attribut ist ein Datenelement, das in jedem Objekt einer Klasse gleichermaßen enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird. Es gibt, je nach Programmiersprache, die Möglichkeit die Sichtbarkeit der Attribute nach außen hin einzuschränken. Dies geschieht mit Hilfe der Sichtbarkeitskennzeichen:
public: verfügbar für alle Klassen des Systems protected: verfügbar für Objekte der eigenen und aller abgeleiteten Klassen private: verfügbar nur für Objekte dieser Klasse Operationen sind Dienstleistungen, die von einem Objekt aufgerufen werden können. Sie werden durch ihre Signatur (Operationsname, Parameter, Rückgabewert) beschrieben. Eine Methode ist die Implementation einer Operation. Sie besteht aus einer Folge von Anweisungen.
Klassen werden durch Rechtecke dargestellt, die den Namen der Klasse und/oder die Attribute und Operationen der Klasse enthalten. Klassenname, Attribute und Operationen werden durch eine horizontale Linie getrennt. Der Klassenname steht im Singular und beginnt mit einem Großbuchstaben. Attribute können näher beschrieben werden, z.B. durch ihren Typ, einen Initialwert und Zusicherungen. Sie werden aber mindestens mit ihrem Namen aufgeführt. Operationen können ebenfalls durch Parameter, Initialwerte, Zusicherungen usw. beschrieben werden. Auch Sie werden mindestens mit ihrem Namen aufgeführt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7 Klassendiagramm
2.4 Prozessmodelierungstechniken
Neben den beschriebenen „normalen“ Klassen können zusätzlich Metaklassen, parametrisierbare Klassen, Schnittstellenklassen und abstrakte Klassen definiert werden.
Zustandsdiagramm 10
Ein Zustand ist die endliche nicht-leere Menge von möglichen Attributwerten, welche die Objekte einer Klasse annehmen können. Er wird als Zeitspanne zwischen zwei Ereignissen angesehen. EineÄnderung von Attributwerten eines Objektes, die das Verhalten des Objektes maßgeblich verändern, heißt Zustandsänderung. Zustände sind durch einen für sie eindeutigen Namen definiert. Gleichnamige Zustände innerhalb eines Zustandsdiagrammes beschreiben den selben Zustand eines Objektes.
Ein Zustandsdiagramm beschreibt eine hypothetische Maschine, die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet. Sie besteht aus:
einem Anfangszustand einer endlichen Menge von Zuständen einer endlichen Menge von Ereignissen einer endlichen Anzahl von Transitionen11, die denÜbergang des Objektes von einem zum nächsten Zustand beschreiben einem oder mehrerer Endzustände Im Zustandsdiagramm werden die Zustände als abgerundete Rechtecke, verbunden durch Pfeile, auf denen die Transitionen stehen, visualisiert. Startzustand ist ein gefüllter Kreis, die Endzustände sind leere Kreise mit einem kleineren gefüllten in der Mitte.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8 Zustandsdiagramm
Aktivitätsdiagramm 12
In einem Aktivitätsdiagramm werden die Objekte eines Programmes mittels der Aktivitäten, die sie während des Programmablaufes vollführen, beschrieben. Eine Aktivität ist ein einzelner Schritt innerhalb eines Programmablaufes, d.h. ein spezieller Zustand eines Modellelementes xxx eine interne Aktion sowie eine oder mehrere von ihm ausgehende Transitionen enthält. Gehen mehrere Transitionen von der Aktivität aus, so müssen diese mittels Bedingungen von einander zu unterscheiden sein. Somit gilt ein Aktivitätsdiagramm als Sonderform eines Zustandsdiagrammes (siehe unten), dessen Zustände der Modellelemente in der Mehrzahl als Aktivitäten definiert sind.
Eine Aktivität wird durch ein "Rechteck" mit konvex abgerundeten Seiten visualisiert. Sie enthält eine Beschreibung der internen Aktion. Von der Aktivität aus gehen die Transitionen, die den Abschluss der internen Aktion und denÜbergang zur nächsten Aktivität darstellen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9 Aktivitätsdiagramm
Sequenzdiagramm 13
Das Sequenzdiagramm beschreibt die zeitliche Abfolge von Interaktionen zwischen einer Menge von Objekten innerhalb eines zeitlich begrenzten Kontextes.
Die Zeitlinie verläuft senkrecht von oben nach unten, die Objekte werden durch senkrechte Lebenslinien beschrieben und die gesendeten Nachrichten waagerecht entsprechend ihres zeitlichen Auftretens eingetragen. Die Objekte werden durch Rechtecke visualisiert. Von ihnen aus gehen die senkrechten Lebenslinien, dargestellt durch gestrichelte Linien, ab. Die Nachrichten werden durch waagerechte Pfeile zwischen den Objektlebenslinien beschrieben. Objekte können während des zeitlichen Ablaufes des begrenzten Kontextes erzeugt und gelöscht werden. Ein Objekt wird erzeugt, indem ein Pfeil mit der Aufschrift neu() auf ein neues Objektsymbol trifft und zerstört, indem seine Lebenslinie in einem Kreuz endet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 10 Sequenzdiagramm
2.4 Prozessmodelierungstechniken
Kollaborationsdiagramm 14
Das Kollaborationsdiagramm visualisiert die einzelnen Objekte und ihre Zusammenarbeit untereinander. Dabei steht, im Vergleich zum Sequenzdiagramm, der zeitliche Ablauf dieser Interaktionen im Hintergrund, vielmehr werden die für den Programmablauf wichtigen kommunikativen Aspekte zwischen den einzelnen Objekten ereignisbezogen dargestellt.
Der zeitliche Verlauf der Interaktionen wird lediglich durch eine Nummerierung der Nachrichten symbolisiert. Die einzelnen Objekte können Nachrichten austauschen, ein Objekt kann sich jedoch auch stets selbst Nachrichten zusenden, ohne dass eine Assoziation vorhanden sein müsste.
Das Kollaborationsdiagramm kann für die Darstellung von Entwurfs-Sachverhalten benutzt werden und, in etwas detaillierter Form, von Realisierungssachverhalten. Es beinhaltet stets kontextbezogene begrenzte Projektionen des Gesamtmodells.
Die einzelnen Objekte werden als Rechtecke dargestellt. Diese werden durch Assoziationslinien mit einander verbunden, auf denen dann die Nachrichten, bestehend aus einer durchgehenden zeitlichen Nummerierung, dem Namen der Nachrichten und Antworten und ihren möglichen Argumenten, dargestellt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 11 Kollaborationsdiagramm
Komponentendiagramm 15
Damit bei späterer Implementierung der Softwarelösung Compiler- und Laufzeitabhängigkeiten klar sind, werden die Zusammenhänge der einzelnen Komponenten der späteren Softwarelösung in einem Komponentendiagramm dargestellt.
Eine Komponente stellt ein physisches Stück Programmcode dar, welches entweder ein Stück Quellcode, Binärcode oder ein ausführbares Teilprogramm der gesamten Softwarelösung sein kann.
Die einzelnen Komponenten werden als Rechtecke dargestellt, die den Namen und den Typ der jeweiligen Komponente enthalten. An deren linken Rand tragen sie eine Ellipse sowie 2 Rechtecke. Eine Komponente kann wiederum weitere Elemente, wie Objekte, Komponenten oder Knoten enthalten und Schnittstellen besitzen.
Die Abhängigkeiten zwischen den einzelnen Komponenten werden durch gestrichelte Pfeile symbolisiert. Die in dieser Art dargestellten Abhängigkeiten zeigen die spätere Compilierreihen- folge auf.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 12 Komponentendiagramm
Einsatzdiagramm 16
Ein Einsatzdiagramm beschreibt, welche Komponenten (Objekte) auf welchen Knoten ablaufen, d.h. wie diese konfiguriert sind und welche Abhängigkeiten bestehen.
Knoten werden im Einsatzdiagramm als Quader visualisiert. In den Knoten können die dort ablaufenden Komponenten (Objekte) dargestellt werden, wobei auch Schnittstellen und Abhängigkeitsbeziehungen zwischen den Elementen erlaubt sind. Knoten, die miteinander kommunizieren, werden durch Linien miteinander verbunden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 13 Einsatzdiagramm
2.4.3 Zusammenfassung
Um ein elektronisches Dienstleistungssystem zu entwickeln ist es nötig, dieses zuerst formal zu beschreiben und zu spezifizieren. In den vorangegangenen Kapiteln wurden zwei Ansätze dazu beschrieben.
UML ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Softwaremodellen. Sie ist jedoch keine Methode, kann aber als Grundlage für verschiedenen Methoden dienen. UML ist keine Software mit der man ein EService System implementieren kann. Eine derartige Software kann jedoch auf UML basieren. UML ist sehr umfangreich und komplex.
[...]
1 Personal Digital Assistent.
2 HTML Hyper Text Markup Language, Seitenbeschreibungssprache 1992 am CERN [CERN01] entwickelt. Siehe auch: [W3C01].
3 Ecin (Electronic Commerce InfoNet). Siehe auch: [ECIN01].
4 Architektur integrierter Informationssysteme.
5 Object Management Group - OMG. Siehe auch: [OMG01].
6 Hersteller des UML Werkzeug Rational Rose, siehe auch: www.rational.com.
7 Auch use case diagram oder Nutzungsfalldiagramm genannt.
8 Auch Class, Typ oder Objektfabrik genannt.
9 Auch Exemplar oder Instanz genannt.
10 Auch State Diagram, State Machine, Zustandübergangsdiagramm oder Endlicher Automat genannt.
11 Eine Transition ist ein Zustandsübergang eines Objektes, der durch ein wesentliches Vorkommnis - ein Ereignis ausgelöst wird.
12 Auch Activity Diagram, Objektzustand, Aktionszustand oder Ablaufdiagramm genannt.
13 Auch Sequence Diagram, Interaktionsdiagramm, Ereignispfaddiagramm, Szenario oder Nachrichtendiagram genannt.
14 Auch Collaboration Diagram, Zusammenarbeits- oder Interaktionsdiagramm genannt.
15 Auch Component Diagram genannt.
16 Auch deployment diagram oder Knoten Diagramm genannt.