vorgehensmodell für analyse, entwurf und realisierung ... · pdf...

© Florian Matthes, 1997

- 1 -

Vorgehensmodell fürAnalyse, Entwurf und Realisierung

&Objektorientierte Modellierung mit UML

Ulrike Steffens, Holm WegnerArbeitsbereich STS

TU Hamburg-Harburg

{ul.steffens,ho.wegner}@tu-harburg.de http://www.sts.tu-harburg.de

Projektseminar: Objektorientierte Realisierung eines Internet-Informationssystems

211-98-StWe-OOII-OOAD+UML

Phasen des VorgehensmodellsPhase I (Analyse)

Anforderungsanalyse: Projektbeschreibung, Use Cases und einfache Klassendiagramme

Phase II (Entwurf)

Systementwurf: Objektorientierte Modellierung der zentralen Konzepte

Phase III (Implementierung)

Objektorientierte Realisierung: Implementierung des Informationssystems ineiner objektorientierten Programmiersprache unter Verwendung einer relationalen Datenbank


- 2 -


Phase I: AnforderungsanalyseZiel:

Präzise Beschreibung der Anforderungen an das Informationssystem

Vorgehensweise:

o Erstellung einer Projektbeschreibung

o Identifikation der wichtigsten Use Cases des Informationssystems

o Erstellung von Use Case-Diagrammen und textuellen Beschreibungen

o Sammlung der wichtigsten Konzepte/Begriffe in einem Glossar

o evtl. Entwurf der zentralen Benutzerschnittstellen und


Projektbeschreibung

Ziele:

o Übersicht über die Ziele und Anforderungen des Informationssystems

o Absichtserklärung

o Vertrag

Inhalt:

o Kurze textuelle Beschreibung der Anforderungen an das Informationssystem

o Schwerpunkt auf den Zielen des Informationssystems aus Kundensicht

o Managementsicht, nicht zu viele Details

o Randbedingungen: Zeit, Budget, Plattform, BS usw.


- 3 -


Was ist ein Use Case ?Use Cases sind typische Interaktionen zwischen Benutzern und einemComputersystem

dt.: „Anwendungsfall“, „Szenario“

Eigenschaften von Use Cases:

o beschreiben eine für den Benutzer sichtbare Funktionalität

o dienen zur Erreichung eines abgrenzbaren Ziels des Benutzers

o können in Größe und Granularität variieren

Beispiel Hotelreservation

ConfirmationReservationInquiry

CreateReservation

Offer


Use Cases: Vorgehensweise

1. Identifikation und Benennung eines abgrenzbaren Vorgangs,den der Benutzer mit dem Informationssystem durchführen möchte

2. Identifikation der beteiligten Aktoren

3. Eintragung in Aktorenkatalog

3. Erstellung eines Use Case - Diagramms

4. Beschreibung des Use Case in einem Use Case-Katalog

CheckoutReservation

InquiryGuest Contact


- 4 -


Use Cases: AktorenEin Aktor ist die Rolle, die ein Benutzer in Bezug auf das System einnimmt.

Möglich sind:

o mehrere Rollen für einen Benutzer

o mehrere Benutzer mit der gleichen Rolle

o Systeme als Aktoren

Beispiele Hotel Reservation

o Contact

o Guest

o Travel Agency

o Hotel

o Service Recipient

o Back Office System


AktorenkatalogTabellarische Auflistung der Aktoren mit kurzer Tätigkeitsbeschreibung

Actor Brief DescriptionReservation Manager • checks availability of rooms

• supports Contacts with reservation inquiry• ...

Contact • contacts hotel for information, reservation etc.• ...

Guest ...Travel Agency ...Service Recipient ...Hotel ...


- 5 -


Use Cases: Diagramme

Create Offer

Create Group Offer

„extends“

„uses“

„extends“- Beziehung zur Definition von Variationen und Sonderfällen„uses“-Beziehung zum Herausziehen mehrfach verwendeter Vorgänge

Aktor

Use Case

Identify BusinessPartner

ReservationManager


Use Case KatalogKurze textuelle Beschreibung der einzelnen Use Cases

Use Case Brief DescriptionCreate Business Partner Create a business partner as Single Person, Company or

Travel Agent by specifying attributes and optionally creatingan address and defining relationships to other businesspartners

Create Reservation Offer Creates reservation offer by specifying participating businesspartners and inquiry information and then selecting availableproducts that match this inquiry

Get Availability ...

Reservation Inquiry ...

... ...


- 6 -


Hinweis zu Use CasesZiel:

o Use Cases sollen das Verständnis von Kunden und Entwicklern für das Systemfördern.

o Sie ersetzen nicht den Entwurf!

o Sie beschreiben nicht die Benutzungsoberfläche!

o Sie sind kein Ersatz für Ablaufdiagramme, etc.

o ⇒ Use Cases sollten nicht zu detailliert sein.


GlossarZiel:

o Schaffung eines einheitlichen Verständnisses für die Terminologie

o Sammlung der wichtigsten Begriffe als Grundlage für den Entwurf

Anforderungen:

o Inhaltliche Konsistenz

o „Abgeschlossenheit“

Vorgehensweise:

o Extrahieren der wichtigen Substantive aus den Use Cases

o Sammlung der Begriffe in alphabetischer Reihenfolge in einem Glossar

o Festlegung einer kurzen Definition zu jedem Begriff, die die Bedeutung desBegriffs im Zusammenhang mit dem Informationssystem beschreibt


- 7 -


Glossar (Beispiel)

Term DefinitionHotel holds organizational and legal responsibility for the operation of

the hotel, has the role of a contractor towards guests; controls itsdepartments, ...

Offer ...

ReservationManager

receives reservation inquiries from guests or companies,processes offers and performs reservation orders; performschanges of these orders;

Resource physical or service, inventory controlled on an individual time grid(day, hour, month), allows for reservation of different kind(options, guaranteed, etc.); may consist of parts, has a validperiod, knows about minimal stock, knows availability

Room ...... ...


Entwurf der BenutzerschnittstellenZiele:

o Greifbare Konkretisierung zur weiteren Klärung der Anforderungen an das Informationssystem

o Grundlage für Diskussionen mit den Anwendern

o Vorlage und Startpunkt für die Anwendungsentwicklung

Vorgehensweise

o Entwurf der wichtigsten Benutzerschnittstellen für die einzelnen Use Cases

o Anlegen eines Verzeichnisses pro Use Case

o Realisierung der Benutzerschittstellen (z.B. mit HTML)

o Exemplarische Verbindung der Benutzerschittstellen

Erster flacher Prototyp


- 8 -


UML KlasendiagrammBeispiel Hotelreservation:

Confirmation

CancelationSalesProduct

Resource

Stock

OrderedItem

ReservationInqiry ReservationOffer

BusinessPartner

ReservationOrder


Klassendiagramm und ObjektdiagrammKlassendiagramm (Class Diagram ):

q Beschreibt Typen der Objekte im System und

q Die verschiedenen statischen Beziehungen zwischen ihnen.

Objektdiagramm (Object Diagram):

q Graph von Instanzen

q (Statisches) Object Diagram: Instanz eines Class Diagrams

Drei Perspektiven, aus denen ein Diagramm aufgestellt/gelesen werden kann:

q Konzept => Anwendungsdomäne

q Spezifikation => Software-Interfaces

q Implementation => Software-Implementation


- 9 -


Klassen, Attribute, Operationen

Attribute:

Sichtbarkeit ::= „+“ | „#“ | „-“

Hotel

Hotel

+ name:String = “Irgendein Hotel“

+berechneAngebot(Kunde): Angebot

public protected private

Operationen

Klassen: Kapsel für Attribute und Methoden.Der Name wird fett geschrieben.

Objekte:Instanzen der Klassen...


Einschränkende Regeln (Constraint Rules)

Es gibt Einschränkungen, die mit den graphischen Mitteln in UML nicht ausdrückbarsind.

UML bietet keine strikte Syntax, außer daß derartige Einschränkungen in geschweiftenKlammern stehen.

Randbedingungen können an verschiedene UML-Konstrukte geknüpft sein.

Beispiel: Invariante der Klasse Student.

{wenn Student.DiplomarbeitsStatus = „angemeldet“, dann mußStudent.StudienarbeitsStatus = „abgeschlossen“ sein}


- 10 -


Stereotypen (Stereotypes)Stereotypen stellen eine Klassifizierung auf einer hohen Ebene dar. Sie ermöglicheneine Einteilung der UML-Konstrukte. Notation: «Name» oder durch Symbol.In UML werden z.B. die uses- und extends-Beziehungen zwischen Use Cases durchStereotypen einer Relation modelliert:

Benutzerlisteexportieren

Administrator

«uses»Benutzerauflisten

Benutzereinrichten

«uses»

Es gibt eine Reihe vordefinierter Stereotypen (einige kommen im folgenden vor), aberder Modellierer kann beliebige ergänzen.


Berechnete Attribute

Attribute, die aus den anderen Attributen berechnetwerden, werden mit einem „/“ gekennzeichnet.

Dies ist nur eine äußere Beschreibung, es könnenz.B.

anfang und dauer gespeichert, und

ende berechnet werden.

Bei der Implementation ist die Angabe derberechneten Attribute nützlich, da die Redundanzsichtbar wird.

Zeitintervall

anfang :Datum

ende :Datum

/dauer :Datum

{dauer = ende - anfang}


- 11 -


Generalisierung, Klassifizierung

Person

Lehrer Schüler

Rolle

Generalisierung, Klassifizierung:Die bekannte Subtypisierung, Vererbung.

Mehrfachklassifikation:Unterschied zur Mehrfachvererbung: Objekt hatmehrere Typen.

Durch Diskriminator disjunkt (Objekt hathöchstens einen der Typen).

Constraint {complete} (Objekt hat genau einender Typen).

Supertyp

Subtyp1 Subtyp2

weiblich

männlichGeschl.{complete}


Interfaces und abstrakte KlassenInterfaces, um Trennung von Signatur und Implementation herzustellen.Kein Unterschied in der Verwendung abstrakter Klassen und Interfaces.

Notation:q Namen abstrakter Klassen, Methoden und Interfaces werden kursiv geschrieben.q Abstrakte Klassen tragen den Constraint {abstract}.

q Interfaces werden durch Stereotyp «interface» oder durch „Lollipop“ dargestellt.

MenschlKunde

«interface»

MenschlKunde

Kunde

Person{abstract}

Kunde Person{abstract}


- 12 -


Assoziationen (Associations) (1)

Jede Assoziation hat zwei Rollen (eine pro Leserichtung).

Rollen können explizit benannt werden (an der Zielseite).Ansonsten tragen sie den Namen der Zielklasse.

A

A

A

A

A

B

B

B

B

B

1

1..*

0..1

*

A BRolle B

Kardinalität:min. (1), max. (*), Bereich (1..15), Auswahl (2,4).

Eine Assoziation impliziert evtl . die Verantwortung für dieKonsistenz einer Beziehung(z.B. existentielle Abhängigkeit bei Kardinalität 1..1).

Navigierbarkeit: Symbolisiert durch Pfeilspitzen.Bei ungerichteten Kanten muß die Bedeutung festgelegtwerden: Verantwortung nicht spezifiziert oderbidirektional.

Student ProfessorBetreuer


Assoziationen (2)

Eine Rolle mit einer maximalen Kardinalität größereins modelliert eine Kollektion.Normalerweise wird eine Mengensemantikangenommen, durch Constraints kann ein anderesVerhalten dargestellt werden,

z.B. {ordered}, {bag}, {ordered bag}, {hierarchy}, ...

A B1..*

0..1

Eine Erweiterung stellen die qualifiziertenAssoziationen (Qualified Association) dar, diedie Zielklasse mit einer Instanz eines Schlüssels inBeziehung setzen.Kunde BestellungProdukt

Eine Abhängigkeit einer Klasse von einer anderendeutet an, daß sie diese in irgendeiner Weiseverwendet.

A B


- 13 -


Assoziationen (3)

Durch Assoziationsklassen könnenAssoziationen um Attribute, Operationenetc. bereichert werden.

Person FirmaArbeitgeber

Anstellungdauer:Zeit

0..1*


AggregationAggregation zur Modellierung einer Teil-Ganzes-Beziehung.

UML bietet noch eine stärkere Version der Aggregation: Komposition.Ein Teil gehört bei dieser nur zu genau einem Ganzen.

Der Teil hängt existentiell vom Ganzen ab (Õ z.B. kaskadierendes Löschen), Beziehungändert sich nicht.

Diplomarbeit Kapitel1 2..*

Diplomarbeit Inhaltsverzeichnis1 1

Inh:Inhaltsverzeichnis

Diplomarbeit

1

{ordered}

vorgehensmodell für analyse, entwurf und realisierung ... · pdf...

Documents