WebUML
UML zur Modellierung von DataWeb Applikationen
- Art: Diplomarbeit
- Autor: Werner Hartmann
- Abgabedatum: März 2001
- Umfang: 133 Seiten
- Dateigröße: 1,5 MB
- Note: 1,0
- Institution / Hochschule: Johannes Kepler Universität Linz Österreich
- ISBN (eBook): 978-3-8324-3253-9
-
ISBN (Paperback) :
978-3-8324-3253-9 P - ISBN (CD) :978-3-8324-3253-9 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Hartmann, Werner März 2001: WebUML, Hamburg: Diplomica Verlag
- Schlagworte: Internet, Datenbank, UML, XML, eCommerce
In den Warenkorb
58,00 €
Diplomarbeit von Werner Hartmann
Einleitung:
Das Internet - und speziell das World Wide Web – liefern die technologischen Grundlagen für neue, vielversprechende Anwendungsbereiche, wie etwa Electronic Commerce, und werden mehr und mehr zur Plattform für vollwertige Informationssysteme, die nicht nur statische HTML Seiten zur Verfügung stellen, sondern auch eine weitreichende Interaktion erlauben. Diese sowohl datenintensiven als auch hypertextbasierten Informationssysteme, die meist auf einer sehr komplexen Applikationslogik aufbauen, werden im folgenden als DataWeb Applikationen bezeichnet.
Die Entwicklung solcher DataWeb Applikationen ist aufgrund der Kombination konventioneller Softwaretechniken mit hypertextorientierten Aspekten eine sehr anspruchsvolle und komplexe Aufgabe. Dennoch herrscht ein „quick and dirty“ Ansatz mit Hilfe von einfachen Werkzeugen wie HTML Editoren vor. Es gibt keine allgemeinen, systematischen Vorgangsweisen für die Entwicklung von DataWeb Applikationen, und der Modellierung wird ein sehr kleiner Stellenwert eingeräumt. Die Praxis der Entwicklungsarbeit ist vielmehr geprägt von der Erfahrung und dem Wissen einzelner Entwickler. Dies führt zu schwerwiegenden Problemen wie unzureichender Dokumentation, aufwendiger Wartung und Schwierigkeiten bei der Anpassung der Applikation an veränderte Anforderungen.
Ziel dieser Arbeit ist die Entwicklung einer allgemeinen Modellierungsmethode für DataWeb Applikationen, auf Basis der Unified Modeling Language UML. In einer ersten Phase werden dazu die Anforderungen erhoben, die eine Modellierungsmethode erfüllen muss, um für den Einsatz in diesem Anwendungsbereich geeignet zu sein. Diese Anforderungen werden einerseits durch die spezifischen Charakteristika von DataWeb Applikationen vorgegeben, andererseits werden sie aus den Eigenschaften der verfügbaren Technologien für die Realisierung solcher Applikationen abgeleitet. Durch die Einbeziehung von technologischen Anforderungen wird sichergestellt, dass die semantische Lücke zwischen Entwurf und Implementierung klein gehalten wird. Die ermittelten Anforderungen gliedern sich in allgemeine Anforderungen für Modellierungsmethoden, spezielle Anforderungen für die Modellierung von DataWeb Applikationen und entwicklungsaufgabenspezifische Anforderungen.
Auf Basis dieser Anforderungsanalyse wurden Stärken und Schwächen existierender Modellierungsansätze für DataWeb Applikationen untersucht. Die Ansätze wurden dazu in drei grundlegende Kategorien Hyperbasisorientiert, Problembereichsorientiert und Technologieorientiert eingeteilt. Dabei zeigte sich einerseits, dass insbesonders Problembereichsorientierte Ansätze mächtige Konzepte zur Verfügung stellen. Andererseits wurden aber auch eklatante Schwächen aufgedeckt, die einen Großteil der untersuchten Ansätze betreffen. So ist die Modellierung der dynamischen Aspekte einer DataWeb Applikation mit den meisten Ansätzen nicht möglich.
Die bei der Stärken/Schwächen Analyse gewonnenen Erkenntnisse wurden herangezogen, um UML um entsprechende Konzepte zur Modellierung von DataWeb Applikationen zu erweitern. Dabei wird vor allem darauf geachtet, bereits bestehende Konzepte von UML zu verwenden, bzw. diese den Zwecken der Modellierung von DataWeb Applikationen entsprechend zu adaptieren. Zur Realisierung der Notation werden nur die von UML zur Verfügung gestellten Erweiterungsmechanismen wie Stereotype, Tagged Values und Einschränkungen verwendet. Dadurch kann die DataWeb spezifische Erweiterung von UML in jedes Modellierungswerkzeug, das UML vollständig unterstützt ohne zusätzlichen Aufwand integriert werden. Die Funktionsweise der hier entwickelten Notation wird anhand der Modellierung eines Beispiels aus der Realität, einem Teil des Destinationsinformations- und Buchungssystems TIScover, verdeutlicht.
Inhaltsverzeichnis:
| 1. | Einleitung | 1 |
| 2. | Kriterienkatalog | 4 |
| 2.1 | Allgemeine Kriterien für eine Modellierungsmethode | 7 |
| 2.2 | Kriterien für eine DataWeb Modellierungsmethode | 8 |
| 2.2.1 | Aufgabenspezifische Kriterien | 10 |
| 2.2.1.1 | Content | 10 |
| 2.2.1.2 | Hyperbasis | 11 |
| 2.2.1.3 | Präsentation | 13 |
| 3. | Analyse existierender Modellierungsansätze | 15 |
| 3.1 | Kategorisierung der Ansätze | 16 |
| 3.2 | Hyperbasisorientierte Ansätze | 17 |
| 3.2.1 | Hypertext Design Model (HDM) | 17 |
| 3.2.1.1 | In-the-large-Konstrukte | 18 |
| 3.2.1.2 | In-the-large Typen und Schemata | 21 |
| 3.2.1.3 | In-the-small-Konstrukte | 22 |
| 3.2.1.4 | In-the-small-Typen | 23 |
| 3.2.1.5 | Zugriffsbereich | 24 |
| 3.2.2 | HDM-Lite | 25 |
| 3.2.2.1 | Hyperbase Schema | 25 |
| 3.2.2.2 | Zugriffsschema (Access Schema) | 27 |
| 3.2.2.3 | Präsentationsschema | 29 |
| 3.3 | Problembereichsorientierte Ansätze | 31 |
| 3.3.1 | Relationship Management Method (RMM) | 31 |
| 3.3.1.1 | Relationship Management Data Model (RMDM) | 32 |
| 3.3.2 | Object Oriented Hypermedia Design Method (OOHDM) | 37 |
| 3.3.2.1 | Konzeptuelles Design | 38 |
| 3.3.2.2 | Navigationsdesign | 38 |
| 3.3.2.3 | Abstraktes Schnittstellen Design | 45 |
| 3.3.2.4 | Implementierungsphase | 48 |
| 3.3.3 | Araneus Methode | 48 |
| 3.3.3.1 | Konzeptuelles und Logisches Datenbankdesign | 49 |
| 3.3.3.2 | Konzeptuelles Hypertextdesign mittels NCM | 49 |
| 3.3.3.3 | Logisches Hypertextdesign mittels ADM | 53 |
| 3.3.3.4 | Präsentationsdesign | 57 |
| 3.3.3.5 | Seitengenerierung aus der Datenbank mit Penelope | 57 |
| 3.3.3.6 | Site Integration mit Penelope und Ulixes | 58 |
| 3.3.4 | Strudel | 58 |
| 3.3.4.1 | Strudel Datenmodell | 59 |
| 3.3.4.2 | Die Abfragesprache StruQL | 59 |
| 3.4 | Technologieorientierte Ansätze | 60 |
| 3.4.1 | Conallen | 60 |
| 3.4.1.1 | Seiten | 60 |
| 3.4.1.2 | Verweise | 61 |
| 3.4.1.3 | Komponenten | 62 |
| 3.4.1.4 | Formulare | 62 |
| 3.4.1.5 | Rahmen | 63 |
| 3.4.2 | World Wide Web Design Technique (W3DT) | 64 |
| 3.4.2.1 | Entwurfsprozeß | 65 |
| 3.4.2.2 | Metamodell | 66 |
| 3.4.2.3 | Notation | 67 |
| 4. | Vergleich der Ansätze | 70 |
| 4.1 | Aufgabenvergleich | 70 |
| 4.1.1 | Content | 71 |
| 4.1.2 | Hyperbasis | 72 |
| 4.1.3 | Präsentation | 73 |
| 4.2 | Aufgabenspezifischer Vergleich | 75 |
| 4.2.1 | Content | 75 |
| 4.2.2 | Hyperbasis | 76 |
| 4.2.3 | Präsentation | 79 |
| 5. | Konzeption von WUML | 81 |
| 5.1 | Usecasespezifische Erweiterungen | 82 |
| 5.2 | Strukturbeschreibende Erweiterungen | 84 |
| 5.2.1 | Content | 85 |
| 5.2.1.1 | Analyse | 85 |
| 5.2.1.2 | Logischer Entwurf | 86 |
| 5.2.1.3 | Physischer Entwurf | 87 |
| 5.2.2 | Hyperbasis | 88 |
| 5.2.2.1 | Analyse | 88 |
| 5.2.2.2 | Logischer Entwurf | 92 |
| 5.2.2.3 | Physischer Entwurf | 94 |
| 5.2.3 | Präsentation | 98 |
| 5.2.3.1 | Physischer Entwurf | 98 |
| 5.3 | Dynamikbeschreibende Erweiterungen | 100 |
| 5.3.1 | Intraobjektdynamik | 101 |
| 5.3.2 | Interobjektdynamik | 102 |
| 5.4 | Methode | 105 |
| 5.5 | Zusammenfassung | 107 |
| 6. | Ausblick | 108 |
| 6.1 | Evaluierung und Weiterentwicklung | 108 |
| 6.1.1 | Evaluierung | 109 |
| 6.1.2 | Ausformulierung der WUML Methode | 109 |
| 6.1.3 | Realisierung | 109 |
| 6.1.4 | Transaktionsmodellierung | 112 |
| 6.1.5 | Physische Erweiterungspakete | 112 |
| 6.1.6 | Erweiterung des Entwurfsmustervokabulars | 113 |
| 6.1.7 | Modellierung nichtfunktionaler Systembestandteile | 113 |
| 6.1.8 | Erweiterung zur Modellierung von Verteilung | 114 |
| 6.1.9 | Entwicklung einer Sprache zur Beschreibung von UML Erweiterungen | 114 |
| 6.2 | Erweiterungen von UML | 114 |
| 6.2.1 | Zeiger Mechanismus in UML | 114 |
| 6.2.2 | Definition von Einschränkungen für Erweiterungen | 115 |
HTML-Formulare werden durch Klassen mit dem Stereotyp <<form>> modelliert. Formulare existieren nur auf der Clientseite, als Teil von übergeordneten Client-Seiten. Formularklassen enthalten nur Attribute und keine Methoden, da HTML-Formulare selbst kein dynamisches Verhalten haben [CONA98]. Conallen will hier nicht so sehr das HTML Form-Tag, sondern vielmehr den URL-String modellieren, den das Formular an ein CGIScript schickt, der nur aus Argument-Wert Paaren besteht und somit keine Methoden enthält. Die Methoden der übergeordneten Clientseite haben Zugriff auf diese Attribute. Über eine spezielle Assoziation, die durch das Stereotyp <<submits>> gekennzeichnet ist, wird die Klasse identifiziert, welche die Formulardaten verarbeitet. Diese Klasse ist meist eine Serverseite. In Abbildung 3-31 wird ein Beispiel für die Verwendung von Formularen gezeigt. Die Clientseite cpCourseRegistration enthält die zwei Formulare frmNewStudent und frmStudent, die über <<submits>> Beziehungen mit den Serverseiten spProcessNewStudReq und spGetStudentRecord verbunden sind. [...]
Das zentrale Konstrukt des Conallen Modells ist die HTML Seite. Wie oben erwähnt, unterscheidet Conallen zwischen Serverseiten und Clientseiten. Seiten werden als Klassen modelliert, die Unterscheidung zwischen Client- und Serverseite erfolgt über die Stereotype <<server page>> bzw. <<client page>>. Zur besseren Unterscheidung zwischen Clientund Serverseite werden die Namen der Seitenklassen mit dem Präfix sp für Serverseiten und cp für Clientseiten versehen. Außerdem werden die Stereotype mit Graphiken verknüpft, sodaß sich Client- und Serverseiten auch graphisch unterscheiden. Serverseiten bauen eine oder mehrere Clientseiten auf und können den Leser an andere Serverseiten weiterleiten. Zur Notation dieser Beziehungen werden die Stereotypen <<builds>> und <<redirects>> definiert. Diese Stereotypen werden auf Beziehungen zwischen Seiten angewandt. In [...]
Technologieorientierte Ansätze greifen Ideen der beiden anderen Gruppen (hyperbasisorientiert und problembereichsorientiert) auf und versuchen diese an eine bestimmte Implementierungstechnologie (in den meisten Fällen das WWW) anzupassen. 3.4.1 Conallen Das Modell von Conallen basiert auf der Notation von UML [CONA98]. Es erweitert UML durch die (von UML zur Verfügung gestellten) Erweiterungsmechanismen wie Tagged Values, Stereotype und Constraints zu einer Modellierungsnotation für das Web. Im Modell wird streng zwischen Vorgängen am HTTP Server und am HTTP Client unterschieden, was dazu führt, daß z.B. HTML Seiten als Serverseiten, die Clientseiten aufbauen, modelliert werden. Dadurch können die Unterschiede in Verhalten und Inhalt zwischen einer HTML Seite am Server und ihrer „Abbildung“ am Client modelliert werden. 3.4.1.1 Seiten [...]
In den Warenkorb
58,00 €
Entdecken Sie mehr zum Thema
