Startseite
Begleitmaterial
Impressum


auf der Website von Dr. Hans-Jochen Sepp

Seminar: Software-Engineering                                   

Einführung in die Entwicklung betrieblicher Informationssysteme

1.  Probleme der Software-Entwicklung und Modelle der   

      Softwareentwicklung

2.  Anforderungsanalyse mit UML

3.  Systementwurf mit UML


LITERATUR

Prof. Dr.(PL) Unterstein Zur Problematik der Use Cases in UML 2LiteraturBurk97

Burkhardt, Rainer: UML - Unified Modeling Language. Addison Wesley, München etc. 1997.

Cock01 http://members.aol.com/acockburn/papers

DeMa79: De Marco, Tom: Structured Analysis and System Specification; New York
1979.

Inno00: Innovator 6.2.02. MID GmbH Nürnberg, 2000.

Jeck01a http://www.jeckle.de/uml_pub.htm

Jeck01b http://www.jeckle.de/files/uniproc.pdf

Jec+04 Jeckle, M., Rupp, C., Hahn, J., Zengler, B., Queins, S.: UML 2 glasklar.

Hanser Verlag, München, Wien 2004

Glinz, Martin; Universität Zürich:http://www.ifi.unizh.ch/groups/req/ftp/se_I/kapitel_05.pdf

Nest01 http://nestroy.wi-inf.uni-essen.de

Oest01 Oestereich, Bernd: Objektorientierte Softwareentwicklung. 5. Auflage,

Oldenbourg: München, Wien 2001.

Raas91 Raasch, Jörg: Systementwicklung mit Strukturierten Methoden. Hanser:

München, Wien 1991.

ZBGK01 Zuser, W., Biffl, S., Grechenig, T., Köhle, M.: Software Engineering mit

UML und dem Unified Process. Pearson Studium 2001.

Übersicht http://www.sigs.de/publications/docs/obsp/umlkomptAbgerufen: 1.10.03www.sigs.de/publications/docs/obsp/umlkompt.htm

www.futureobjects.de/content/intro_use_case.html

http://www.tu-chemnitz.de/wirtschaft/wi1/lehre/2003_ss/memobis/Folien%20219-
243.pdf Abgerrufen: 8.9.03

http://www.oose.de/downloads/uml-notationsuebersicht.pdf


1. Probleme und Modelle der Softwareentwicklung

Die Softwareentwicklung läßt sich ablaufbezogen durch die Analyse (Systemanalyse), 

das Design und die Softwareimplementierung beschreiben, wobei systembezogen

organisatorische, technologische und motivative Aspekte zu beachten sind.

(vgl.: R. Burkhardt, UML, S. 302)

1.1 Probleme der Softwareentwicklung

Probleme der Softwareentwicklung sind ein Ergebnis der unterschiedlichen

Vorstellungen der Anwender und Hersteller und der beteiligten Entwickler.

Letztere sind explizit zu nennen, da sie sich als Interessengruppe sowohl

auf der Anwender- als auch Herstellerseite befinden können.

Im zeitlichen Rückblick ist festzustellen, dass die Probleme der Software-

entwicklung auf  den z.T. nicht greifenden Bemühungen der Vereinheitlichung,

der Standardisierung der Softwareentwicklung zurückzuführen sind.

Dabei wurden die ersten Regelvorgaben bereits in den achtziger Jahren normiert.

1.2. Die Unterstützung der Softwareentwicklung durch "Styleguides"

Hier sind Definitionen der Hersteller und ihrer Ingenieure, herstellerneutrale Anforderungen

und anwenderbezogene Anforderungen zu unterscheiden.

1.2.1 Hersteller unabhängige Richtlinien

- ISO 9241: Die Richtlinie aus dem Jahr 1980 behandelt u.a. softwareergonomische Aspekte.

  Es wurden zu den Benutzeroberflächen 7 Kriterien definiert:

  - Selbstbeschreibungsfähigkeit, - Erwartungskonformität, - Steuerbarkeit, -Individualisierbarkeit,

  - Erlernbarkeit, - Fehlerresistenz, Aufgabenagemessenheit. 

   - EU-Richtlinie 90/270/EWG

1.2.2 Hersteller Styleguides

- Als eine der ersten Herstellernormen sind die von Big-Blue zu nennen. Im Jahr 1987 legte

  IBM den Common-User-Access Styleguide basierend auf dem Betriebssystem OS/2 fest.

- 1986 definierte Apple seine Human-Interface-Guidlines.

- Aus Gründen der Vollständigkeit ist auch Styleguide "MS-Windows-Interface" zu nennnen.  

1.2.3 Anwender "Online-Styleguides"

Als umfangreich ist das IDS "Interactive Documentation System" zu bezeichnen. In dem

Guide werden 18 Hauptinformationsknoten definiert. Viele dieser Informationsknoten sind

dem "Grafical User Interface" (GUI) zuzuordnen.

(vgl.: Bullinger, Fähnrich: Betriebliche Informationssysteme, S. 332).

1.3. Von der problemorientierten zur objektorientierten Softwareentwicklung

Während noch in den siebziger Jahren die problemorientierten Sprachen, wie Agol, Fortran,

PL/1, Cobol, Pascal und C dominierten, traten in den achtziger und neunziger Jahren die

objektorientierten Sprachen (OOL), wie Modula2, Delphi und später Java und C# und...

UML in den Vordergrund. Letztere berücksichtigt die Grundkonzepte objektorientierter

Programmiersprachen wie Ada, Simula und Smaltalk (vgl.: Peter Fettke: Objektorientierte

Modellierung in Enzyklopaedie der Wirtschaftsinformatik). Als weiterführende und z.T ver-

gleichbare Modellierungstools sind "Rational Rose" von IBM und OBA++ (Object Behavior

Analysis) zu nennen 

Mit UML wurde die vereinfachende Behandlung komplexer Zusammenhänge propagiert.

Jedoch nur scheinbar - wie jüngste Entwicklungen zeigen:

UML wird ergänzt durch eUML oder exUML (e und ex für embadded und executable).

Es tritt in der jüngsten Entwicklung also das Ziel einer ganzheitlichen, vereinfachten

Softwarentwicklung - von der Systemanalyse bis hin zur Implementierung - der

Modell-Driven-Arcitecture in den Vordergrund.    

    

2. Anforderungsanalyse mit UML

Für die Anforderungsdefinition stehen gemäß OMG-Board (Object Management Group)

13 Diagramme zur Verfügung. Bei 6 Diagrammen handelt es sich um Struktur-

diagramme und bei 7 um Verhaltensdiagramme.

In den beiliegenden Charts sind jedoch nicht 13 sondern 15 Diagramme aufgeführt!

Bitte prüfen Sie daher die Zulässigkeit der Diagramme!   


2.1. Verbale, informelle Beschreibung eines Systems 

Requirements:

Anforderungen an ein Softwaresystem aus Sicht
der Anwender:

Welche Verarbeitungsleistungen erbringt es?

Welche Benutzerinteraktion findet statt?

    Welche Eingaben tätigt der Benutzer?

    Welche Resultate und Ausgaben kommen heraus?

Nicht: Wie leistet es das! 

Also: unabhängig von der Implementation.

Wie macht man das?· 

- Für Anwender nachvollziehbar ihre Anforderungen festhalten

- Das System für Softwareentwickler in einer brauchbaren Genauigkeit 

   beschreiben. 

- Die Beschreibung muss als Grundlage für die Abnahme der Software  

   taugen (Pflichtenheft).

Erforderlich sind:

- Exaktheit

- Verständlichkeit

Diese Forderungen widersprechen sich!

Lösung in UML: Anwendungsfälle

Problematik der USE CASES in UML

2.2. Grundbegriffe der Modellierung von Anwendungsfällen

2.2.1. Anwendungsfall (use case)

Beschreibung einer typischen Interaktion zwischen

Anwender und System.

Sie stellt externes Systemverhalten aus Sicht des

Anwenders dar.

· Was das System leisten muss.

· Nicht, wie es das tut.

· Keine einzelne Operation, eher eine   Transaktion                                                                                           

=(Folge zusammenhängender Aktivitäten).

Sie kann in verschiedenen Varianten auftreten.

Anwendungsfall 1


Zur Problematik der Use Cases in UML


2.2.2. Akteur (actor, stakeholder)

Eine außerhalb des Systems liegende Einheit

beteiligt an einer Interaktion mit dem System

(wie in dem Anwendungsfall beschrieben)

Anwender des Systems (nicht Person, sondern Rolle)




Akteur 1

Beispiele:

· Hausratsversicherungssachbearbeiter

· Außendienstmitarbeiter  

1 Person kann mehrere Rollen ausüben.

1 Rolle kann mehreren Personen angehören.

Akteur kann auch ein fremdes System sein:


Externes System


Zur Problematik der Use Cases in UML

2.2.3. Anwendungsfalldiagramm

Beschreibt Zusammenhänge zwischen einer

Menge von Anwendungsfällen und den daran

beteiligten Akteuren.

                    Zeitschriftenumlauf:

   

                  Zeitschrift registrieren


           

Auswerter     Zeitschrift auswerten

                                                                   Bibliothek

                   Umlaufzettel erstellen

 

                   Zeitschrift archivieren



Sekretariat



Zur Problematik der Use Cases in UML


2.2.4. Regeln für Anwendungsfälle

Definition:

Ein Anwendungsfall beschreibt eine Menge von

Aktivitäten eines Systems aus der Sicht seiner

Akteure, die für die Akteure zu einem wahrnehmbaren

Ergebnis führen.

Ein Anwendungsfall wird stets durch einen Akteur

initiiert.

Ein Anwendungsfall ist eine komplette, unteilbare

Beschreibung.[Oest01a S. 199]

Regeln:

Jeder Anwendungsfall hat einen fachlichen Auslöser.

- Jeder Anwendungsfall produziert ein für die Akteure

  ein relevantes fachliches Ergebnis.·

- Ein Anwendungsfall enthält keine zeitliche Unterbrechung.

Konsequenzen:

- Anwendungsfälle stellen keinen Entwurfsansatz dar.

- Sie sind nur Hilfsmittel bei der Ermittlung der Anforderungen an

   ein System.

- Sie sollen nicht zur funktionalen Dekomposition ver-

  wendet werden.

- Sie sind keine Ablauf-, Datenfluss- oder Klassendiagramme.


Zur Problematik der Use Cases in UML


Beispiel Autovermietung


Definition Nr. 1 (Nestroy, Uni Essen)

Use Case beschreibt eine Interaktion eines

Aktors mit dem System in natürlicher Sprache.

Er beinhaltet alle Einzelereignisse, die bei der

Interaktion durchgeführt werden.

(...)

Die Summe aller Use Cases beschreibt die

Gesamtfunktionalität des Systems.“

1. Satz: Konsens.

2. Satz: Was für Ereignisse? Mausklicks,

            Datenabfrage, Fehlermeldung bei

            Datenabfrage?

3. Satz: „... Gesamtfunktionalität ...“

Sieht der Nutzer einzelne Funktionen oder sieht

er Transaktionen?

Später im Text derselbe Autor:

„Use Cases zerlegen das System nach

funktionalen Gesichtspunkten, dies widerspricht

objektorientierten Vorgehensweisen.

Definition Nr. 2 (Oestereich)

„Ein Anwendungsfall beschreibt eine Menge von

Aktivitäten eines Systems aus der Sicht seiner

Akteure, die für die Akteure zu einem wahrnehm-

baren Ergebnis führen. 

"Ein Anwendungsfall wird stets durch einen Akteur

initiiert".

“aus der Sicht seiner, die für die Akteure zu einem wahrnehmbaren                                                  führen.[Oest01a S. 199]


2.2.5. Anwendungsfälle identifizieren und beschreiben

Auslöser und Ergebnis bestimmen Anfang und Ende des Anwendungsfalles.

Festzuhalten für jeden Anwendungsfall

- Name

- Kurzbeschreibung (1-20 Zeilen freier Text)

- Akteure

- Auslöser

- Ergebnisse

- Vorbedingung (Beispiel später)

- Nachbedingung (Beispiel später)


Beispiele:

Name:                              Kfz reservieren

Kurzbeschreibung:              Ein Kunde reserviert für

                                       einen definierten Zeitraum

                                       ein Kfz.

Akteure:                           Kunde, Call Center Agent

Auslöser:                          Kunde möchte Kfz reservieren.

Ergebnisse:                       Kfz-Reservierung, Reservierungsbestätigung



Name:                              Kfz-Mietvertrag abschließen

Kurzbeschreibung:

Akteure:

Auslöser:

Ergebnisse:


Nicht relevante Anwendungsfälle sind solche:

die nicht durch das System unterstützt werden sollen

oder können.

Beispiel:

Gemietetes Kfz benutzen.

Sie können modelliert werden, sind dann aber als "excluded"

gekennzeichnet.


Relevante Auslöser (Beispiele):

- Kunde möchte Vertrag schließen

- Kunde möchte eine Auskunft

- Marketingabteilung verlangt Auswertung

Keine relevanten Auslöser:

- Kundennummer eingeben

- Vertrag speichern

- Relevante Ergebnisse

- Kfz-Reservierung

- Brief an Kunden

- statistische Auswertung gedruckt

Keine relevanten Ergebnisse:

- Kunden gespeichert

- Vertrag gefunden


Noch mehr Regeln:

Abläufe, die unterbrochen werden oder deutlich

unterscheidbar von mehreren Akteuren bearbeitet

werden,

--> aufteilen in mehrere Anwendungsfälle.

Keine funktionale Zerlegung. Ein Anwendungsfall

ist kein einzelner Schritt.

Anwendungsfalldiagramm beschreibt einen Ablauf.

Ist aber keine Ablaufbeschreibung im Sinne einer

Reihenfolge, Abhängigkeit von Bedingungen etc.


Anwendungsfall erfordert Abstraktion von

bestimmten Detailabläufen bei individuellen Fällen.

Checkliste
- Beschreibt der Anwendungsfall, was das System, aber                                                        nicht: wie es dies leisten soll?

- Sind für jeden Anwendungsfall: Name, Kurzbeschreibung,                                                       Akteure, Auslöser und Ergebnisse notiert worden?
                                     
- Beschreibt jeder Anwendungsfall einen zeitlich
  ununterbrochenen und funktional nicht zerlegten
  Ablauf?

- Ist es vermieden worden, mit dem Anwendungs-                                                 falldiagramm Ablaufreihenfolge festzulegen?

[Oest01 a.S. 101]


Use Case Diagramm mit Fehler:


Käufer                                                             Verwaltung

                     Schuhhandel              Buchhaltung




                                     Angestellter



Use Case Diagramm mit Fehler:


                                                                   - Ende25    Verwaltung

Käufer                                      Buchhaltung                   - Ende26

               Schuhhandel                                 - Ende27

                                                                             Anlagenbuchhaltung     

                                                                             - Ende28     

                                                                              Debitorenbuchhaltung
                                         Angestellter




Zum Vergleich:

Anwendungsfall versus funktionale Dekomposition

                                    Hochschulverwaltung








2.2.6. Ablaufvarianten:

Für einen Anwendungsfall kann es verschiedene Durchführungs-       

varianten geben.

Beispiel:

"Kfz reservieren" kann telefonisch, per Fax oder per Internet erfolgen.

Dadurch ergeben sich im Detail unterschiedliche Abläufe ("Szenarien").

--> separate Beschreibung in einem "Geschäftsprozessmodell"

Ein Anwendungsfall soll möglichst allgemein und abstrakt sein und alle

möglichen Varianten einschließen.


2.2.7 Essenzielle Beschreibung von Anwendungsfällen

Anwendungsfälle sollen so beschrieben werden, dass sie hinsichtlich der                                 Details das Wesentliche aller Abläufe festhalten.

Beispiel Identifizierung des Kunden bei Reservierung eines Kfz:

- per Telefon: Name, Fahrernummer

- per Internet: PIN

- persönlich: Kundenkarte mit Kundennummer

Wichtig:

Bei allen Arten von Reservierung wird die Identität des Kunden festgestellt.

Das ist die Essenz!

Name:

Kurzbeschreibung:

Akteure:

Auslöser:

Vorbedingungen:

Nachbedingungen:

Eingehende In-

formationen*:

Ergebnisse:

Nachbedingungen:

Ablauf:

* gehört meiner Ansicht nach nicht dazu, da Ablaufdetail.

Beispiel:

Name:                                      Kfz reservieren

Kurzbeschreibung:                      Für Kunden wird Kfz für               
                                              definierten Zeitraum reserviert.

Akteure:                                   Reservierer

Auslöser:                                  Kunde möchte Kfz reservieren

Vorbedingungen:

Eingehende
Informationen*:                         Kundennr, weitere Kundendaten

Ergebnisse:                               Reservierung, Reservierungsbestätigung

Nachbedingungen:                      Kfz. für Kunden ist reserviert.

Ablauf                                      1. Kunde identifizieren oder neu aufnehmen

                                              2. Reservierungswunsch aufnehmen

                                              3. Reservierungsmöglichkeit prüfen

                                              4. Wenn nicht erfüllbar, andere Alternative                                                        vorschlagen

                                              5. Kfz reservieren

                                              6. Reservierung bestätigen

Wo verbesserbar?

Aufnahme eines neuen Kunden ist als eigener Anwendungsfall ausgliederbar.

Reservierungsmöglichkeit prüfen kann den Vorschlag von Alternativen umfassen.


Ablauf                                           1. Kunde identifizieren

                                                   2. Reservierungswunsch
                                                       aufnehmen
                                                   3. Reservierungsmöglichkeiten                                                  
                                                       prüfen 
                                                   4. Kfz reservieren

                                                   5. Reservierung bestätigen


2.2.8. Beziehungen zwischen Anwendungsfällen

<<include>> , <<verwendet>>

stellt dar, dass innerhalb eines Anwendungsfalls

ein anderer Anwendungsfall vorkommt.

Abschnitte, die in mehreren Anwendungsfällen

vorkommen, können so extrahiert werden, um

Redundanz zu vermeiden.

Lagerbestand                                       Kundenumsatz
aktualisieren                                        aktualisieren 


«verwendet»

                                                         «verwendet»

Rechnung erstellen




aktualisieren


<<extend>> , << erweitert>>

stellt dar, dass ein Anwendungsfall unter

Umständen duch einen anderen erweitert wird.

Damit lässt sich optionales Systemverhalten von

Standardverhalten trennen.

Bedingungen der Option können dokumentiert

werden:

Kfz reservieren


«erweitert»


Kunde neu aufnehmen


Weiteres Beispiel aus [ZBGK01]

## Neu ##

Weitere Beispiele

Glinz, Martin; Universität Zürich

http://www.ifi.unizh.ch/groups/req/ftp/se_I/kapitel_05.pdf

Andere Anforderungen:

- Funktionale Anforderungen

- Benutzbarkeit

- Performance

- Zuverlässigkeit (Reliability)

- Änderbarkeit, Erweiterbarkeit

Verbindlichkeitsgrade

- Pflichtanforderungen

- Optionale Anforderungen

- Absichten

- Vorschläge

2.3. Was hat man gewonnen, was kommt danach?

Positive Ergebnisse:

eines Systems aus Nutzersicht.

- strukturierte (nicht bloß intuitive) Beschreibung eines                                                           Systems aus Nutzersicht. "Geschäftsmodell"

- Abgrenzung von einzelnen Leistungen des Systems.


Man weiß, was vom System erwartet wird.

Nicht erreicht:

· funktionale Dekomposition

· Vorgaben für Klassenstrukturen·

Vorgaben für sonstige Implementierungsdetails.

(war auch nicht beabsichtigt!)

Wie geht es weiter?

Klassendiagramme beschreiben Datenstrukturen

und deren Methoden.

Sequenzdiagramme beschreiben die

Kommunikation zwischen Objekten bei der

Bewältigung bestimmter Aufgaben.

etc.

- Objektorientierter Systementwurf.


Einordnung der Anwendungsfälle

Rahmen und Einstiegspunkt

Nicht ausreichend, um z.B. Qualitätsanforderungen

zu beschreiben (Anwendungsfallübergreifend).

Allgemeine Anforderungen müssen allgemein

beschrieben werden.

Ein Anwendungsfall ist demnach:

eine Zusammenstellung vorhandener, allgemeiner

Anforderungen im Kontext eines fachlichen

Ablaufs.    

[Oest01 S. 119]


3. Systementwurf

3.1. Geschäftsklassen identifizieren

Eine "Geschäftsklasse" beschreibt die Abbildung eines                                                                 Gegenstands im weitesten Sinne, der im Sinne der                                                           Systemaufgabe von Interesse ist und über den Daten                                                                gespeichert und verarbeitet werden müssen.

Analogie: "Entitätsbegriff" im Entity Relationship

Modell.

Diese Klassen und ihre Beziehungen untereinander

sind zunächst aus fachlicher Sicht zu

beschreiben, d.h.

ohne Detailangaben zu Attributen und

Methoden.

Geschäftsklassen werden evtl. im Design weiter

zerlegt und führen ggf. zu weiteren EDV-technisch

begründeten Klassen. 

3.1.1. Beispiel fachliches Klassendiagramm Autovermietung

siehe Skript, S. 40  

3.1.2. Beziehungstypen (Kardinalität)

Wenn K1 und K2 zwei Klassen sind, die in dem zweistelligen                                            Beziehungstypen R stehen, interessieren wir uns dafür,

wie viele Elemente aus K2 jeweils zu einem Element aus

K1 in Beziehung stehen können (und umgekehrt).

Mindestzahlen

O: Optional

d.h. es kann Elemente aus K1 geben, für die kein Element aus                                                         K2 in der Relation R steht.

1: obligatorisch

d.h. für jedes Element aus K1 muss (mindestens) ein Element aus                                                   K2 in der Relation R stehen.

Höchstzahl

1: eindeutig,

d.h. für jedes Element aus K1 kann nur

höchstens ein Element aus K2 in der Beziehung R stehen

* mehrdeutig,

d.h. es kann Elemente aus K1 geben, für die mehr als ein ein                                                            Element aus K2 in derR stehen.

In der Verknüpfung gibt es somit vier Möglichkeiten

in einer Richtung:

0..1

0..*

1..1

1..*

Andere Darstellungen (in Entity Relationship Modellen)

siehe S.43 Skript

Klassendiagramm Versandhandel: siehe S. 44 Skript 

Gegenüberstellung ERM / UML-BegriffeBegriff

Begriff der ERM    Begriff der UML

Entität                    Objekt

                             Exemplar (instance)

Entitätentyp            Klasse

Entitätenmenge        (extent)

Beziehung               Assoziation

Beziehungstyp         Assoziation

Attribut                  Attribut

Grundsätzlicher Unterschied

Eine Klasse hat Methoden, die ihr Verhalten beschreiben.

Hierzu gibt es keine Entsprechung im ERM.

Aggregation:

Hierdurch wird ausgedrückt, dass Objekte einer Klasse Bestandteile von

Objekten einer anderen Klasse sind. ## Neu ##

Beispiel

Motor ist ein Aggregat eines Kraftfahrzeugs.

Die Aggregate können auch ohne ein Objekt existieren, von dem sie

Bestandteil sind.

siehe Skript S. 46

Alternative Bezeichnungen des Beziehungstyps

"Teil - Ganzes"

"HAS A"

Komposition ## Neu ##

Sie ähnelt der Aggregation mit dem einzigen Unterschied, dass

die Bestandteile nur im Zusammenhang mit genau einem Vaterobjekt

existieren können.

Beispiele

Gebäude mit ihren Zimmern, Rechnung und ihre Positionen

Vererbung

Zu einer Klasse können Unterklassen existieren.

- Jede Unterklasse erbt alle Attribute und alle Methoden der Oberklasse

- Jede Unterklassse kann weitere Attribute haben oder Attribute verändern

- Kann das Verhalten "überschreiben", eigene Methoden hinzufügen.

Jedes Objekt einer Unterklasse ist auch gleichzeitig

ein Objekt der entsprechenden Oberklasse.

Beziehungstyp

IS A

Siehe Skript S. 49

UML Modell Versandhandel siehe Skript S. 50


Beispiel Fahrzeugwartung

- Es gibt Fahrzeuge, Motoren, Bremsanlagen, Geriebe und weitere                                           Aggregate die hier nicht beachtet werden

- Jedes Fahrzeug kann ein Aggregat von einer Klasse enthalten
   Ein Aggregat kann auch fehlen, dann ist das Fahrzeug in der Werksatt                                       
   und nicht verkehrsbereit.

- Jedes Fahrzeug kann ein Aggregat von einer§

einer Variante gehören (z.B. Dieselmotor,

Automatikgetriebe).Jedes Fahrzeug und jedes Aggregat kann zu§

Wartungen und Inspektionen, die zeitlich

und/oder nach Laufleistung seit der letzten

Wartung/Inspektion festgelegt sind. Diese

Wartungen bzw. Inspektionen sind von der

Klasse und der Variante abhängig.Es gibt eine Liste von vorgeschriebenen§

sind zu speichern.Die durchgeführten Wartungen und Inspektionen


Glinz, Martin; Universität Zürich

http://www.ifi.unizh.ch/groups/req/ftp/se_I/kapitel_05.pdf

3.2. Methoden (Operationen)

3.2.1. Methoden allgemeinDienstleistungen, die von einem Objekt angefordert werden können.

Beschreibung durch Signatur:

Sichtbarkeit

Operationsname

{ Eingabeparameter mit Datentyp }

: RückgabewertBeispielSetzen des Mittelpunkts für die Klasse Kreis:public setPosition(in x: Integer=1,

in y : Integer=1)Einzahlung in ein Konto mit Rückgabe des neuen Stands:public einzahlung(in betrag : Real):Stand

Parameter können gekennzeichnet werden als in, out, inout jenachdem, ob die Daten nur eingegeben, ausgegeben oder ein- und

ausgegeben werden.


3.2.2. Abstrakte Operationenwerden nur durch ihre Signatur repräsentiert.

Die Implementation erfolgt erst in einer Unterklasse.

Abstrakte Operationen gibt es nur in abstrakten Klassen.

3.2.3. NachrichtenObjekte kommunizieren untereinander durch Austausch von Nachrichten

(Botschaften).

Jedes Objekt versteht genau die Nachrichten, für die es eine Operation

besitzt.

Der Austausch von Nachrichten zwischen Objekten kann inKollaborationsdiagrammen

Dazu später mehr.oder Sequenzdiagrammen dargestellt werden.

3.2.4. Java-Beispielpublic class Artikel



3.3. Klassendiagramm mit Methoden

3.4. StereotypenEinteilung der Klassen nach der Rolle, die sie im gesamten System spielen

Boundary (Schnittstellenklasse). Modelliert Interaktion zwischen System

und Aktor.

Control-Klasse. Beinhaltet die dynamische Logik des Systems. Realiseren

zusammen die gesamte Funktionalität, um alle Anwendungsfälle

umzusetzen.

Entity-Klasse. Speichert persistente Daten, die im System verarbeitet und

gespeichert werden.## Neu ##

Beispiel für Klassendiagramm mit Stereotypen## Neu ##Aus [ZBGK01]

KollaborationsdiagrammeZeigen, welche Klassen über welche Botschaften kommunizieren.

http://www.unikoblenz.

de/~winter/Lehre/SS01/Loesung5.2/collaboration.png

3.5. Sequenzdiagramme stellen dar:

welche Nachrichten in bestimmten Situationen zwischen Objekten ausgetauscht werden.

Betont wird der zeitliche Ablauf.Objekt

Lebenslinie

AktivierungNachrichtenaustausch

Zeitverlauf

Bedingung

3.5.1. Syntaxelemente in Sequenzdiagrammen

Erzeugen von ObjektenObjekt wird durch Eintreffen einer Nachricht erzeugt, d.h. am Pfeil beginnt

die Aktivierung.Löschen von ObjektenKreuz am Ende der Aktivierungslinie.Iterationen'*' vor dem Nachrichtennamen

(geht bei Innovator nicht)Objekt führt eigene Methode ausÜberlagerung der Aktivierungslinie.


 

3.5.2. Zusammenhang zwische Use-Case-Modell,

Klassendiagramm und Sequenzdiagramm

Wenn die Klassenstrukturen stehen und die Abläufe spezifiziert sind, ...

... kann man einem Use Case ein Sequenzdiagramm zuordnen.

beschreibt das Zusammenwirken verschiedener Objekte für einen

bestimmten Anwendungsfall.

Es spezifiziert somit die interne Sicht eines Anwendungsfalls (Use Case),

beschreibt also, wie der Anwendungsfall innerhalb des Systems

abgewickelt werden kann.h

ttp://www.ifi.unizh.ch/groups/req/courses/seminar

ws00/referate/6fol.pdf

   


Top