Systementwicklung Vorlesung SS 2006 Paul Manthey.

121
Systementwicklung Systementwicklung Vorlesung SS 2006 Paul Manthey

Transcript of Systementwicklung Vorlesung SS 2006 Paul Manthey.

Page 1: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systementwicklung

Vorlesung SS 2006

Paul Manthey

Page 2: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Motivation (1): Verschiedene Definitionen

• System (griechisch: systema (syn + histanai) = Zusammenstellung, geordnetes Ganzes).

• A system is a set of objects, together with relationships between the objects and between their attributes (Hall and Fagen 1956). (Ein System ist eine Ansammlung von Elementen und deren Eigenschaf-ten, die durch Wechselbeziehungen miteinander verbunden sind.)

• Unter einem System versteht man in der Praxis ein Gebilde, das in der Lage ist, Signale umzuwandeln (Unbehauen 1990).

• Ein System ist ein nach einer bestimmten Ordnung gefügtes, in sich einheitliches Ganzes (Lexikon der deutschen Sprache 1969).

• System ist ein ganzheitlicher Zusammenhang von Dingen, Vorgängen, Teilen, von der Natur gegeben oder von Menschen hergestellt (Imboden 1992).

• Ein System ist durch seinen Systemzweck (Funktion), seine Systemelemente und Wirkungsverknüpfungen (Wirkungsstruktur) und seine Systemintegrität gekennzeichnet (Bossel 1992).

Page 3: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Motivation (2): Beispiele

• Wirtschaftssysteme, z.B. Jäger- und Sammler, Sozialismus, Marktwirtschaft,

• Verkehrssysteme, z.B. Bahn, öffentlicher Personennahverkehr,

• Ökosysteme, z.B. Wald, Teich,

• Umweltsysteme, z.B. Atmosphäre, Hydrosphäre,

• Waffensysteme, z.B. Flugzeugträger, Interkontinentalraketen,

• Betriebssysteme; z.B. MS Windows, Linux,

• Nervensysteme, z.B. des Tintenfisches, der Biene ...

Unterschieden werden kann dabei zwischen

• statischen und dynamischen Systemen,

• realen und formale Systemen,

• systemischen und systematischen Systemen ...

Page 4: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Motivation (3): Vorlesungs-Schwerpunkte

• Betriebliche Systeme, Informationssysteme und Anwendungssysteme. Diese Systeme weisen z.T. eine erhebliche Komplexität auf.

• Bereitstellung einer einheitlichen Terminologie und Methodik zur Erfassung, Untersuchung und Beschreibung unterschiedlicher Arten von Systemen.

• Strukturen und Ursache-Wirkungs-Zusammenhänge

• Beispiele aus BWL, Naturwissenschaften, Psychologie ...

• Analyse und Gestaltung von Software-Systemen (Softwareengineering).

Page 5: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Informaler Systembegriff

Definition

Ein System ist eine Menge von Komponenten, die miteinander in Beziehung stehen.

Merkmale des informalen Systembegriffs

• Keine Aussage über die Beschaffenheit der Beziehungen zwischen den Komponenten. Komponenten können selbst wieder Mengen von (Teil-)Komponenten sein, die ihrerseits in Beziehung stehen. Komponenten können somit auch Teilsysteme eines Systems sein.

• Keine Aussage über die Beschaffenheit der Beziehungen zwischen den Komponenten. Die Beziehungen können z.B. die Zusammen-fassung von Teilkomponenten zu einer Komponente beschreiben (Aggregation, ist_Teil), die Weitergabe von Komponenteneigen-schaften an Teilkomponenten (Vererbung, ist_ein) oder die Wechselwirkung zwischen Komponenten und Teilkomponenten (Interaktion, interagiert_mit).

• Insgesamt ist der informale Systembegriff zu wenig operabel für unsere Zwecke.

Page 6: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Allgemeiner Systembegriff

Definition

Sei I eine beliebige Indexmenge (I ) und V = {Vi: i I} eine Familie von nichtleeren Mengen. Ein allgemeines System SG ist definiert als Relation über den Mengen Vi

SG Vi

iI

Merkmale

• Struktur: Die Struktur eines allgemeinen Systems wird durch paarweise Beziehungen zwischen den Systemkomponenten Vi bestimmt

RG {(Vi, Vj): i, j I i j}.

• Verhalten: Die in SG enthaltenen Tupel von Elementen aus Vi definieren das Verhalten eines allgemeinen Systems.

Page 7: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Ampelgeregelte Kreuzung

Das System besteht aus 4 Verkehrsampeln (Systemkomponenten), die durch die Mengen VA = VB = VC = VD = {rot, gelb, grün, rot/gelb} dargestellt werden. Sie Relation SG = VA VB VC VD wird als Tabelle geschrieben:SG VA VB VC VD

rot grün rot grün

grün rot grün rot

rot rot/gelb

rot rot/gelb

rot/gelb rot rot/gelb

rot

gelb rot gelb rot

rot gelb rot gelb

• Die Struktur des Systems umfasst die Menge der Beziehungen zwischen gleich- und gegengeschal-teten Ampeln:

RG = {(VA, VB), (VB, VC), (VC, VD), (VD, VA), (VA, VC), (VB, VD)}

• Die Tabelle beschreibt das Verhalten des Systems. Nicht zum Verhalten gehö-ren u.a. (rot, rot, rot, rot) und (grün, grün, grün, grün) als Kombinationen.

Page 8: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Kundenbestand eines Unternehmens (1)

Der Kundenbestand eines Unternehmens kann als System über Wertebe-reiche von Attributen dargestellt werden. Als relevante Attribute werden KdNr, KdName, KdPLZ, KdOrt und KdSaldo gewählt. Für jedes Attribut wird die Menge der zulässigen Werte in Form eines Wertebereichs (Domäne) angegeben (z.B. dom(KdNr) = {1000 .. 99999}). Die Systemrelation ist wiederum in Form einer Tabelle dargestellt.

SG dom(KdNr) dom(KdName) dom(KdPLZ) dom(KdOrt) dom(KdSaldo)

KdNr KdName KdPLZ KdOrt KdSaldo

1001 Huber KG 80335 München 1300,00

1010 Meier, Josef 96050 Bamberg 965,30

1012 Schulze AG 56070 Koblenz 732,90

Page 9: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Kundenbestand eines Unternehmens (2)

• Die Systemrelation beschreibt das Verhalten des Systems. Sie umfasst den aktuellen Kundenbestand, jeder Kunde wird dabei durch eine Zeile (Tupel, Datensatz) repräsentiert.

• Es können jederzeit Zeilen hinzugefügt, geändert oder gelöscht werden. Dies bedeutet eine Modifikation des Systemverhaltens und damit des Systems.

• Die Struktur des Systems wird durch die Menge

RG = {(KdNr, KdName), (KdNr, KdPLZ), (KdNr, KdOrt), (KdNr, KdSaldo)}

beschrieben und gibt die funktionalen Abhängigkeiten zwischen den Attributen wieder

KdNr KdName, KdPLZ, KdOrt, KdSaldo. Bei Kenntnis eines Wertes zu KdNr können die zugehörigen Werte zu KdName, KdPLZ, KdOrt und KdSaldo bestimmt werden.

Page 10: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemkomponenten und Teilsysteme

Definition

Die in SG auftretenden Mengen Vi werden als Systemkomponenten, die Menge V wird als Systemträgermenge eines allgemeinen Systems bezeichnet.

Systemkomponenten können selbst wiederum Systeme darstellen. In diesem Fall wird eine Systemkomponente Vi = {Vij: j J} als Familie von nichtleeren Mengen interpretiert.

Definition

Die Relation über den Mengen Vij

SGi Vij

jJ

wird als Teilsystem von SG bezeichnet.

Page 11: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Auftragsbestand eines Unternehmens

Die Tabelle zeigt den Auftragsbestand eines Unternehmens. Attribute von Auftrag sind AuftrNr (Auftragsnr.), KdNr (Kundennr.), AuftrDatum (Auf-tragsdatum), AuftrFaell (Fälligkeit) und AuftrPos (Auftragsposition). Das Attribut AuftrPos umfasst die Teilattribute PosNr (Positionsnr.), ArtNr (Artikelnr.) und PosMenge. Zu jedem Auftrag gehört eine nichtleere Menge von Auftragspositionen. Diese bilden ein Teilsystem des Auftrags.AuftrNr KdNr AuftrDatu

mAuftrFaell Aufpos

PosNr ArtNr PosMenge

2006/17

1010 2006-04-21

2006-05-03

001 A1720 50

002 A2330 100

003 A1030 80

2006/18

1012 2006-04-23

2006-05-05

001 A1720 100

002 A4330 65

003 A5033 70

004 A6020 20

Page 12: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Input-Output-System

Das Input-Output-System stellt einen Spezialfall des allgemeinen Systems dar. Dabei wird die Indexmenge I in zwei Teilmengen Iin und Iout zerlegt, so dass gilt

I = Iin Iout und Iin Iout = .

Auf der Basis dieser Zerlegung der Indexmenge werden über der Mengen-familie V = {Vi: i I} eine Eingabemenge IN und eine Ausgabemenge OUT gebildet.

IN = Vi OUT = Vi

iIin

iIout

Definition

Das System Sio IN OUT heißt Input-Output-System.

Ist die Beziehung zwischen IN und OUT funktional, so liegt ein funktiona-les Input-Output-System Sio: IN OUT vor. Input-Output-Systeme dienen der Beschreibung von Black-Boxes, deren innere Struktur nicht bekannt oder irrelevant ist. Das Verhalten wird hingegen durch Sio vollständig beschrieben.

Page 13: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Berechnung von Forderungssalden

Das Beispiel zeigt ein Input-Output-System als Programmfunktion, welche an Hand der offenen Forderungen an Kunden die zugehörigen Forderungs-salden als kumulierte Forderungsbeträge bestimmt.

KdNr Ford.

K001 100

K001 150

K002 070

K003 120

Sio: IN OUT

IN OUT

in IN

KdNr Saldo

K001 250

K002 070

K003 120

out OUT

Page 14: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustandsraum-System

Definition

Eine weitere Spezialisierung des allgemeinen Systems stellt das Zustands-raum-System dar. Dabei werden eine Menge Z von Zuständen und Übergänge zwischen den Zuständen betrachtet. Die Übergänge werden durch die Relation

SZ Z Z

beschrieben. Falls SZ funktional ist, handelt es sich um ein deterministi-sches System

SZ: Z Z.

Das Verhalten des Zustandsraum-Systems wird durch SZ beschrieben.

Page 15: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Ablauf des Ampelsystems

Die Systemrelation SG = VA VB VC VD beschreibt das Verhalten der am-pelgeregelten Kreuzung in Form von gültigen Zuständen des Ampelsystems. Durch Ergänzung der Systemrelation SG um die Spezifikation eines Zu-standsraum-Systems SZ können die Übergänge der Zustände beschrieben werden. z1 rot grün rot grün

z2 grün rot grün rot

z3 rot rot/gelb

rot rot/gelb

z4 rot/gelb rot rot/gelb rot

z5 gelb rot gelb rot

z6 rot gelb rot gelbDie Übergänge des Ampelsystems werden deterministisch durch die Relation

SZ = {(z1, z6), (z6, z4), (z4, z2), (z2, z5), (z5, z3), (z3, z1)}

beschrieben.

Page 16: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Endlicher Automat

Endliche Automaten vereinen die Eigenschaften von Input-Output- und Zustandsraum-Systemen. Es handelt sich um Systeme mit einer endlichen Menge von Zuständen, die einen Ausgangszustand auf Grund eines Stimu-lus (Eingabe) verändern, dabei in einen Folgezustand wechseln und eine Reaktion (Ausgabe) erzeugen.

IN: Menge der Stimuli (Eingabewerte)

OUT: Menge der Reaktionen (Ausgabewerte)

Z: Endliche Zustandsmenge

Definition

Ein endlicher Automat ist ein System SA = (R1, R2) mit

R1 IN Zvor Znach und R2 IN Znach OUT.

Im Allgemeinen sind R1 und R2 Funktionen auf IN Z. Dann gilt

R1 : IN Zvor Znach und R2 : IN Znach OUT.

Page 17: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Ein Beispiel für einen endlichen Automaten ist eine Terminpla-nungsaufgabe. Jeder Zustand repräsentiert die Menge der aktuell geplanten Termine.

Durch einen Eingabewert (Ter-minwunsch: Mi, 10-11) geht der Automat in einen Folgezu-stand über, der den neuen Termin umfasst; gleichzeitig wird der Ausgabewert „ge-bucht“ erzeugt.

Kann der Termin nicht einge-plant werden, so ist der Folge-zustand mit dem Vorzustand identisch; der Ausgabewert ist „nicht gebucht“.

Zeit Mo Di Mi Do Fr

8-9 X X X

9-10 X X X

10-11

X X X X X

11-12

X X X X

12-13

X X

13-14

X X X X

14-15

X

15-16

X X

16-17

X

Sio: IN OUT

IN

(Mi, 10-11)

OUT

gebucht

Beispiel: Terminplanung

Page 18: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Reale Systeme

• Der bisher behandelte Systembegriff und seine Spezialformen bauen auf den mathematischen Begriffen Menge und Relation auf. Es handelt sich also um formale Systeme. Sie entstehen als künstliche Systeme durch ihre Definition.

• Im Gegensatz dazu stehen reale Systeme, die Teilausschnitte der realen Welt darstellen. Reale Systeme bestehen aus realen, d.h. materiellen oder energetischen Komponenten. Reale Systeme werden durch Ab-grenzung gegenüber ihrer Umwelt erfasst. Ein reales System und seine Umwelt sind bzgl. ihrer Komponenten disjunkt.

• Die Struktur eines realen Systems ist eine Menge von paarweisen Bezie-hungen zwischen seinen Systemkomponenten. Die Beziehungen sind vom Typ besteht_aus und interagiert_mit.

• Das Verhalten eines realen Systems kommt durch Interaktionen von Systemkomponenten zu Stande, welche durch interagiert_mit-Bezie-hungen verbunden sind.

• Ein reales System, bei dem Interaktionen mit seiner Umwelt betrachtet werden, wird als offenes, sonst als geschlossenes System bezeichnet.

Page 19: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Modelle

Auf der Basis der systemtheoretischen Grundlagen lassen sich Modelle als formale Systeme definieren, die reale Systeme einschliesslich ihrer relevanten Umwelt abbilden.

Definition

Ein Modell M = (SO, SM, f) ist ein 3-Tupel bestehend aus

SO : Das Objektsystem ist ein System über der Systemträgermenge VO (SO VOi ). Im Zusammenhang mit betrieblichen Systemen ist das Objektsystem i.a. ein reales System.

SM: Das Modellsystem ist ein System über der Systemträgermenge VM (SM VMj ). Im Zusammenhang mit betrieblichen Systemen ist das Objektsystem meist ein formales System.

f: Die Modellabbildung f: VO VM bildet die Komponenten des Ob-jektsystems auf Komponenten des Modellsystems ab. Die Modell-abbildung f und der Begriff Systemträgermenge sind streng genom-men nur für formale Systeme definiert. Sind reale Systeme an einem Modell beteiligt, so sind diese Begriffe geeignet zu interpretieren.

Page 20: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Informaler Modellbegriff

Definition

Modelle von Objekten sind Ersatzobjekte mit analoger Struktur, Funktion oder analogem Verhalten.

Page 21: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Grundlagen: Modell

Definition

Modelle von Objekten (Originalen) sind vereinfachte Abbildungen der Objekte (Abstraktionen).

• Das Original ist meist ein Realitätsausschnitt, es kann aber auch selbst etwas Fiktives sein (z. B. ein dreidimensionales Modell eines zwar konstruierten, aber noch nicht realisierten Gebäudes.)

• Es gibt unterschiedliche Modelle desselben Originals, unterschiedliche Abstraktionen.

• Ein Modell kann andere Modelle integrieren oder konkretisieren, ist aber dennoch ein Modell des Originals (z. B. ein dreidimensionales Modell eines Gebäudes integriert die Modelle Grundriss und Seitenansichten und konkretisiert diese z. B. durch Textur und Farbe der Außenwände).

• Ein Modell besitzt nicht alle Merkmale des Originals.

Page 22: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Grundlagen: Partialmodelle, unterschiedliche Sichten

Definition

Ein Modell stellt eine Sicht auf ein Objekt dar. Werden verschiedene Sichten betrachtet, spricht man auch von Partialmodellen. “Umfassen-dere” Modelle können durch Integration der Partialmodelle gebildet werden).

Verschiedene Sichten/Aspekte:

Architektur:

• Grundriß

• Elektro-Plan (elektrisches System)

• Plan der Wasserversorgung (hydraulisches System)

• Integration in den Grundriß.

Page 23: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Modell eines Geschäftsprozesses (Objektfluss)

Page 24: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Modell eines Geschäftsprozesses (Vorgangskette)

Page 25: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Grundlagen: System

Definition

Ein System ist eine Menge von Objekten, die untereinander in Beziehung stehen.

Beispiel: Unternehmen - es besteht aus

• Menschen

• Technik (Gebäude, Maschinen, ...)

• Arbeitsergebnisse

• Organisatorische Regelungen

• Beziehungen zwischen diesen Bestandteilen

• Person stellt Ergebnis her

• Person benutzt Maschine

• Person arbeitet in Gebäude

• Person ist Vorgesetzter von Person

• ...

Page 26: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

(System-)Modell

Page 27: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Grundlagen: Modell (3)

Forderung an die Abbildung:

• Jedem Element und Attribut sowie jeder Attributausprägung und Relation des Ausschnitts ist durch die Abbildung genau ein Element, ein Attribut, eine Attributausprägung oder Relation des Modellweltausschnittes zugeordnet.

Abstraktion:

• Nicht alle Elemente der Originalwelt müssen im Ausschnitt der Originalwelt und nicht alle Elemente der Modellwelt müssen im Ausschnitt der Modellwelt vorkommen

• Nicht alle Attribute, Ausprägungen von Attributen und Relationen der Originalwelt (Modellwelt) müssen im Ausschnitt der Originalwelt (Modellwelt) vorkommen (Relationen des Ausschnitts können Teilrelationen von Relationen der Originalwelt sein)

• Verschiedene Elemente (Attribute, Attributausprägungen, Relationen) der Originalwelt können aber auf gleiche Elemente (Attribute, Attributausprägungen, Relationen) der Modellwelt abgebildet werden.

Page 28: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Übungsaufgabe (1)

Beschreiben sie den Schaltplan (Modell) explizit als Abbildung von Ausschnitten im Sinne der Definition eines (System-)Modells, d.h. Elemente, Attribute, Ausprägungen, Relationen für den Ausschnitt der Modell- und der Originalwelt sowie die Abbildung explizit beschreiben. Ist ein Kabel ein Element oder eine Relation?

Page 29: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Übungsaufgabe (2)

Was ist falsch an dem folgenden Modell und warum?

Page 30: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Vorgehen bei der Entwicklung eines Modells

Mehrere Schritte, die mit Wiederholungen und Rücksprüngen, tendenziell in der folgenden Reihenfolge ausgeführt werden:

• Den zu modellierenden Gegenstand festlegen.

• Den Modellierungszweck bestimmen.

• Die Modellwelt/Beschreibungsmittel bestimmen.

• Regeln für die Abstraktion festlegen.

• Die Abbildung der Realität auf die Modellwelt bestimmen.

• Modell überprüfen.

Page 31: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Der Zweck eines Modells

Verstehen der Realität (Ist-Modelle)

• zur Beschreibung: Z.B. Nutzung der Anschauung

• zur Exploration: Z.B. Vorhersage über das Verhalten

• zur Bewertung/Analyse: Z.B. Bestimmung von Mängeln

Konstruktion/Gestaltung der Realität (Soll-Modelle)

• Beschreibung einer Vorgabe für die Konstruktion

• Analyse/Simulation zur Prüfung der Konstruktion vor der Realisierung

• Analyse möglicher/alternativer Gestaltungen der Realität

• Z.B. Identifikation von Fehlern vor der Realisierung

• Bestimmung von Charakteristika (Verhalten, Kosten etc.)

• Abstimmung zwischen Beteiligten (Auftraggeber, Auftragnehmer, Koordination zwischen oder verschiedenen Mitarbeitern/Organi-sationen, die die Realisierung kooperativ durchführen, z. B. Auftragnehmer, Unterauftragnehmer)

Page 32: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Darstellungsmittel für Modelle (Modellsprache) (1)

• meist graphische Elemente

• Kombinationsregeln

• meist allgemein anwendbar

• Funktion einer Sprache

Beispiele in der Architektur:

• perspektivische Darstellung

• Schaltpläne/Vernetzungspläne

Beispiele aus der Unternehmensbeschreibung:

• Organigramm

Page 33: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Syntax und Semantik

Syntax einer Sprache:

• Alphabet

• Regeln nach denen aus dem Alphabet Terme (zur Bezeichnung von Dingen) gebildet werden

• Regeln nach denen aus Termen und dem Alphabet Aussagen/Modelle gebildet werden

Semantik einer Sprache:

• Sprache wird interpretiert, d. h. es wird ein Anwendungsbereich zugeordnet

• Regeln mit denen die Bedeutung sprachlicher Ausdrücke (Terme und Aussagen) festgelegt wird

• Bedeutung von Termen sind Elemente des Anwendungsbereichs

• Bedeutung von Aussagen sind die Wahrheitswerte wahr und falsch

Page 34: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel Arithmetik

Syntax

• Alphabet: d.h. Zahlzeichen wie 0,1,2,3 etc. bzw. +, *, -, /, =, <, > oder Hilfszeichen (,)

• Terme: Zahlzeichen sind Terme.

• Sind t und s Terme, so auch (t + s), (t * s), (t – s) und (t / s)Beispiele: (2 + 3), (2 – 2), (((2 + 3) * 2) – (3 – 1))

• Aussagen:

• Sind t und s Terme, so sind t = s, t < s und t > s AussagenBeispiele: (((2 + 3) * 2) / (3 – 1)) = 3 oder 4 < 3 oder (2+3)=(3+2)

Semantik

• Terme bezeichnen Anzahlen von Objekten, bezeichnen t und s Anzahlen, so bezeichnet (t + s) die Anzahl der zusammengelegten Objekte etc.

• Sind t und s Terme, so ist t = s wahr, wenn die durch t und s bezeichneten Anzahlen identisch sind.

Page 35: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel Schaltpläne (1)

Page 36: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel Schaltpläne (2)

Page 37: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel Schaltpläne (3)

Page 38: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel Schaltpläne (4)

Simulationsmodell gestattet die Ableitung von Aussagen:

• Für einen bestimmten Schaltplan (siehe Beispiel) gilt:

• Wenn Schalter zu, dann Lampe an.

• Wenn Schalter auf, dann Lampe aus.

• Simulationsmodelle gestatten also Vorhersagen (Aussagen) über das Verhalten zusammengesetzter Objekte (Systeme)

• Die Aussagen werden aus der Struktur des Systems (des zusammengesetzten Objekts) abgeleitet.

• Semantik des Modells:

• Bezeichnet ein zusammengesetztes Objekt (System)

• Zum Simulationsmodell gehört ferner eine Sprache zu Bildung von Aussagen, mit der Bedeutung: wahr oder falsch

• Häufig werden Modelle nicht explizit als Simulationsmodelle beschrie-ben, aber als solche genutzt (z.b. der übliche „intuitive“ Gebrauch der Schaltpläne)

Page 39: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Darstellungsmittel für Modelle (Modellsprache) (2)

Vorteil durch Verwendung derselben Darstellungsmittel für verschiedene Modelle (wie z. B. bei den Schaltplänen):

• Routine im Umgang mit den Darstellungsmittel

• Perfektionierung der Darstellungsmittel (z. B. wohldefinierte Semantik)

• Einfachere Sicherung der Vollständigkeit und Relevanz der Modellelemente

• Routine in der Entwicklung von Modellen

• Möglichkeit der Entwicklung von Werkzeugen zur Unterstützung

• Vergleichbarkeit der Modelle/Originale

Page 40: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Was ist eine Modellierungsmethode?

Page 41: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Modellierungsmethode

• laut Duden ist Methode ein planmäßiges Vorgehen, Verfahren

• Modellierungsmethode: planmäßiges Vorgehen zur Entwicklung eines Modells

• Anforderung:

• strukturiert die Entwicklung eines Modells in Teilaufgaben und Schritte

• bedient sich bestimmter Darstellungsmittel

• gibt Anleitung für die Durchführung der Modellierung,

• Unterstützt die Sicherung der Qualität der Modelle oder enthält Kriterien für “gute” Modelle,

• ist in der Regel kein Algorithmus (im Sinne der Mathematik)

• unterstützt die relevanten Partialmodelle und deren Integration

• ist effizient

Page 42: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Arten von Systemen

Page 43: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Arten von Systemen: interaktive Systeme

Page 44: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Weitere Arten von Systemen (1)

Page 45: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Verschiedene Modellierungen eines Systems

Page 46: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Weitere Arten von Systemen (2)

Systeme mit geplanten Reaktionen (McMenamim/Plamer)

Definition

Ein System mit geplanten Reaktionen ist eine Einheit (oder eine Sammlung von Einheiten), die vordefinierte Aktionen ausführen, wenn ein bestimmtes Ereignis außerhalb ihres Einflußbereiches eintritt.

Ein System mit geplanten Reaktionen ist transportabel, wenn seine geplanten Reaktionen in einer symbolischen Sprache ausgedrückt werden können, so daß auch andere aktive Einheiten diese ausführen könnten.

Ähnliche Abgrenzung:

• formal Systems (formale, formelle Systeme) auf expliziten, akzeptierten Regeln basierend

versus

• informal Systems (nicht formale, informale, informelle Systeme) z. B. die Büro-Tratsch-Netzwerke

Page 47: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiele von Systemen mit geplanten Reaktionen (1)

Tante-Emma-Laden

• Geplante Reaktionen

• Ungeplante Reaktionen

• Geschäftsprozesse

• Außerhalb der Betrachtung

• Süßigkeiten als Geschenke

• Architektur des Ladens

• Vertretung von Tante Emma durch ihre Freundin

• ...

Arzt bei Operation

• System mit geplanten Reaktionen, aber nicht transportabel

Page 48: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiele von Systemen mit geplanten Reaktionen (2)

Unternehmen oder andere Organisationen und Organisationseinheiten

• bestehen aus Menschen, Organisation, Technik und Management

• Betrachtungsgegenstand: Verarbeitung und Transport von Material und Information (Fokus ist die Arbeitsweise des Unternehmens)

Geschäftsprozesse

• regelmäßig wiederkehrende geplante Aktivitäten, die durch einen Kundenkontakt (Auftrag/Anfrage) ausgelöst werden und mit einem Kundenkontakt (Auslieferung/Bezahlung) enden (End-to-End-Prozesse).

• Ist ein Prozess ein System? System = alle Elemente eines Unternehmens, die an der Ausführung des Geschäftsprozesses beteiligt sind. Geschäftsprozess stellt die geplanten Reaktionen dar.

Informationssysteme

• Menge von Einheiten zur Verarbeitung, Speicherung und zum Transport von Informationen, ihre Beziehungen untereinander sowie alle technischen, organisatorischen und Managementregelungen zur Verarbeitung und Speicherung von Informationen

• Verarbeitungseinheiten können Menschen oder Maschinen sein, Speicher können elektronische Systeme, Papier etc. sein, Transport kann materiell oder immateriell erfolgen

Page 49: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Abstraktionskriterium: geplante Reaktion

Page 50: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Aufgaben der spontanen Hülle

typische Aufgaben der spontanen Hülle:

• Filtern relevanter Ereignisse,

• Ereignisse aktiv herbeiführen, auf die der geplante Kern reagieren kann,

• Übersetzung von Umgebungsanforderungen/Informationen

• Ausführung von Aktivitäten, die der geplante Kern nicht oder nur unzureichend leisten kann,

• Spezialfälle behandeln, deren Planung nicht wirtschaftlich ist (z.B. zu selten),

• Informelle Kommunikation mit der Umgebung (z.B. Beratung)

Page 51: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Abstraktionskriterium: perfekte Technologie*)Komplexität durch Mängel der Technologie

• Zerstückelung: Verteilung auf verschiedene Prozessoren

• Redundanz:

• Mehrfachspeicherung von Daten

• Durchführung der gleichen Aktivität an verschiedenen Daten

• Zusatzkomponenten dienen dem Ausgleich von Unzulänglichkeiten der Implementation

• Verwicklung

• umständliche Ausführung einer Aktivität wegen Unzulänglichkeiten der Implementation

• Konglomerate

• Zusammenfassung unterschiedlicher Aktivitäten (auf einem Prozessor)

*) Gemeint sind die Mittel der Realisierung (Implementierung). Bei manuellen Systemen ist auch der Mensch ein Mittel der Realisierung.

Page 52: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Essenz des geplanten Kerns

Definition

Die Essenz eines Systems beschreibt alle Aspekte des Systems, die existieren müssen, unabhängig davon, welche Technologie zur Implementierung des Systems (interne Technologie) verwendet wird.

• Soll vom technologischen Wandel unberührt bleiben

• Technologische Neutralität

• Zur Abgrenzung der Essenz gehen wir von einer perfekten internen Technologie aus d. h. alle Komponenten

• haben unendliche Verarbeitungsgeschwindigkeit,

• haben unbegrenztes Fassungsvermögen,

• arbeiten absolut fehlerfrei.

Page 53: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Inkarnation

Definition

Die Inkarnation eines Systems ist die sichtbare Form des Systems im Betrieb d. h. die Gesamtheit aller Prozessoren, Speicher und sonstigen Hilfsmittel, die benutzt werden, um die Essenz des Systems zu implementieren.

Bindung an reale, imperfekte Technologie:

• Prozessoren brauchen Zeit, können Fehler machen, verursachen Kosten

• Speicher haben nur eine endliche Kapazität, Speicherung unsicher

Page 54: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Verschiedene Sichten

Z.B. in der Geometrie:

• UnabhängigkeitJede Sicht abstrahiert jeweils von einer Dimension und ist daher von ihr unabhängig. Aber: Veränderungen einer Sicht i.A. mit Folgen für andere Sichten

• Vollständigkeit

Die drei Sichten zusammen beschreiben den Körper vollständig

Page 55: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Verschiedene Sichten bei der Modellierungvon Unternehmensprozessen und

Informationssystemen

Funktionssicht (Prozesssicht oder -modell): Beschreibt die Funktionen (man spricht auch von Prozessen, Vorgängen, Tätigkeiten, Aktivitäten oder Auf-gaben) und Teilfunktionen. Abstrahiert von der Zeit und damit vom Ablauf.

Ablaufsicht (Dynamisches oder Ablaufmodell): Beschreibt welche Aktivi-täten, Vorgänge gleichzeitig oder nacheinander ablaufen. Abstrahiert von der Semantik der Daten.

Datensicht (Datenmodell): Beschreibung der Daten, die in einem Prozess oder IS verarbeitet oder gespeichert werden. Abstrahiert von der Zeit, unabhängig von Ablaufsicht.

Objektsicht (Objektmodell): Beschreibt einen Prozess oder ein IS als eine Menge von interagierenden Objekten. Abstrahiert vom Ablauf, Integration der Daten- und der Funktionssicht

Organisationssicht: Beschreibt den Aufbau der Organisationseinheiten, die an einem Prozess oder IS beteiligt sind. Zur Aufbauorganisation gehören die Kommunikations- uns Weisungsbeziehungen zwischen den Einheiten Leistungssicht. Beschreibung der Ergebnisse der Prozessausführung durch Produktmodelle

Page 56: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Fachkonzept und DV-Konzept

Im Rahmen der Entwicklung von IS wird wie beim Bau eines Hauses zunächst ein Modell entwickelt. Dabei wird unterschieden zwischen Fachkonzept und DVKonzept Beides sind Modelle von Geschäftsprozessen oder IS allerdings mit unterschiedlichem Konkretisierungsgrad

Fachkonzept

• Beschreibt, was ein System tut

• abstrahiert vom Verfahren und von der Technik der Realisierung

• ist ein essentielles Modell

DV-Konzept

• beschreibt die Struktur der DV-technischen Realisierung und Algorithmen

• beschreibt, was ein System tut und wie es dies tut

• ist abstrakter als die Inkarnation

• genauere Beschreibung später

Keine scharfe Abgrenzung

Page 57: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (1): Ereignisse, Auslöser, Antworten

Page 58: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (2): Ereignistabelle

Beispiel: Tante-Emma-Laden

(Gemeint sind Unternehmensprozesse. Sie werden aber oft einfach mit dem Namen der Organisation bezeichnet, die sie ausführt.)

Page 59: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (3): SA

Strukturierte Analyse (SA)

Man beschreibt ein System durch im wesentlichen vier unterschiedliche Beschreibungsmittel:

• Kontextdiagramme geben einen Gesamtdarstellung des Systems

• Datenflussdiagramme beschreiben, welche Daten durch das System fließen und auf welchen Wegen sie dies tun.

• Das Datenlexikon legt fest, wie diese Daten strukturiert sind, sofern es sich nicht um primitive Daten handelt.

• Mini-Spezifikationen („minispecs“) beschreiben die Leistungen einzelner Systemteile.

Page 60: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (4): DFD

Ein Datenflussdiagramm besteht aus vier Sorten von Objekten:

• Terminatoren, d.h. Endpunkte des Systems. Sie stellen die Grenz-linie des Systems zum Rest der Welt dar und grenzen somit den betrachteten (analytischen) Teil der Welt gegen die nicht betrach-tete Umwelt ab. Hier gelangen Daten ins System bzw. kommen aus dem System heraus.

• Prozesse, stellen die aktiven Komponenten eines Systems dar. Im Rahmen der SA interessiert man sich nur für das Ein/Ausgabever-halten der Prozesse, d.h. dafür, welche Eingabedaten sie verwenden und welche Ausgabedaten sie hieraus erzeugen.

• Datenspeicher, in welchen Daten abgelegt werden können. Sie repräsentieren Datenspeicher oder Datenträger..

• Datenflüsse zwischen Terminatoren, Prozessen und Datenspeichern. Hierbei interessiert nicht nur die reine Tatsache, dass Daten fließen können, sondern auch, welche Daten hier fließen können.

Page 61: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (5): DFD-Symbole

Beispiel: Übersichts-DFD

Page 62: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (6): Datenlexikon

Definition

Ein Datenlexikon ist eine endliche Menge von Datendefinitionen.

Beispiel

• Personendaten = Name + Vorname + Geb-Datum + Adresse + (Tel.Nr.) + Familienstand + {Kind}

• Familienstand = [ledig|verheiratet|verwitwet|geschieden]

• Kind = Name + Vorname + Geb-Datum

• Adresse = Strasse + Hausnr. + PLZ + Stadt + (Staat)

Page 63: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (7): DFD-Arten

Definition

Ein DFD heißt Übersichts-DFD, wenn darin keine Speicher vorkommen. Ein Verfeinerungs-DFD ist ein DFD, in dem keine Terminatoren vorkommen.

Beispiel

Page 64: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (8): Beispiel

Page 65: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Systemanalysetechniken (9): Syntaktische Regeln für SA

• jeder Datenfluß in jedem Diagramm muß mit mindestens einer Funktion/Prozess verbunden sein

• d.h. keine Datenflüsse zwischen Terminatoren

• und keine Datenflüsse zwischen Speichern

• keine Datenspeicher im Kontextdiagramm

• keine Terminatoren in Verfeinerungen

• jeder Speicher und jede Funktion/Prozess muß mindestens einen Zufluss und einen Abfluss besitzen

• jedes Objekt im DFD muß einen Namen besitzen (Ausnahme: Datenflüsse in oder aus Speichern, dabei sind Doppelpfeile eine Abkürzung für zwei einfache Pfeile)

Page 66: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugkarten-Verkauf (1)

Aufgaben des Systems:

1. Auskunft geben über Daten verfügbarer Flüge

2. Buchen eines Flugs mit Ausgabe der Flugkarte (=Rechnung) und Anstoßen der Abwicklung des Zahlungsverkehrs durch die Buchhaltung.

Page 67: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugkarten-Verkauf (2)

Kontextdiagramm

Page 68: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugkarten-Verkauf (3)

Datenflussdiagramm

Page 69: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugkarten-Verkauf (4)

Datenflussdiagramm von Funktion/Prozess(3): Flug aktualisieren

Page 70: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Unified Modelling Language

Definition

Die UML ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von System-Modellen.

Wichtige Modellelemente der UML gegliedert nach Diagrammtypen

• Anwendungsfalldiagramm

• Klassendiagramm

• Aktivitätsdiagramm

• Kollaborationsdiagramm

• Sequenzdiagramm

• Zustandsdiagramm

• Komponentendiagramm

• Einsatzdiagramm

Page 71: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Anwendungsfalldiagramm

Definition

Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungs-fällen und stellt die Beziehungen zwischen Akteuren und Anwendungs-fällen dar. Es zeigt das äußerlich erkennbare Systemverhalten aus der Sicht eines Anwenders.

Notation

Anwendungsfälle werden durch Ellipsen die den Namen des Anwendungs-falles tragen und einer Menge von beteiligten Objekten (Akteuren) darge-stellt. Zu jedem Anwendungsfall gibt es eine Beschreibung in Textform. Die Beschreibung kann ausführlich oder stichpunktartig erfolgen. Es em-pfiehlt sich aber eine inhaltliche Gliederung. Die entsprechenden Anwen-dungsfälle und Akteure sind durch Linien miteinander verbunden. Akteure können durch Strichmännchen o.ä. Symbole dargestellt werden. Die Sy-stemgrenze wird durch einen Rahmen um die Anwendungsfälle symbo-lisiert.

Page 72: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Anwendungsfalldiagramm - Beispiel

Page 73: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Präzisierung des Begriffs Anwendungsfall

Problem der Begriffsbildung

• Ist die Erste Hilfe der Tante Emma an einem ohnmächtigen Kunden ein Anwendungsfall?

• Erste Hilfe ist eine mögliche Sequenz von Interaktionen, die von einem Akteur (Tante Emma) durchgeführt werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen (z. B. stabile Seitenlage).

Präzisierung der Definition: Anwendungsfall

• ist eine aus mehreren zusammenhängenden Aktionen (bzw. der Erfüllung mehrerer zusammenhängenden Aufgaben) bestehende, technologieunabhängig beschriebene, geplante Reaktion, die auf ein von einem Akteur (z. B.: Kunde) ausgelöstes externes Ereignis (z. B. Kunde wünscht Ware) oder ein Zeitereignis hin ausgeführt wird. Dabei können weitere Akteure involviert sein.

Anwendungsfall (Use case) = essentieller Anwendungsfall (essentieller Use case)

Page 74: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Textschablone zur Darstellung von Anwendungsfällen

• Name: sollte aus einem aussagekräftigen Substantiv im Singular und einem starken Verb gebildet werden.

• Ziel: globale Zielsetzung bei erfolgreicher Ausführung

• Kategorie: primär (notwendig, häufig), sekundär (notwendig, selten), optional (nützlich, nicht notwendig)

• Vorbedingung: erwarteter Zustand vor Beginn der Ausführung

• Nachbedingung Erfolg: erwarteter Zustand nach erfolgreicher Ausführung

• Nachbedingung Fehlschlag: erwarteter Zustand nach fehlgeschlagener A.

• Akteure: Rollen von Personen oder anderen Systemen, die den Use case auslösen oder daran beteiligt sind

• Auslösendes Ereignis:

• Beschreibung: Normale Sequenz von Aktionen, Alternativen der Ausführung, Sonderfälle

Page 75: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Use Case Tante-Emma-Laden

Page 76: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beziehungen zwischen den Anwendungsfällen

Page 77: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Anwendungsfällen (1)

Von den Akteuren ausgehen. Die folgenden Fragen an die Akteure stellen:

• Welches Ereignis löst den Auftrag aus?

• Welche Eingabedaten werden benötigt?

• Welche Schritte sind auszuführen?

• Ist eine Reihenfolge der Schritte festgelegt?

• Welche Zwischenergebnisse werden erstellt?

• Welche Vorbedingungen müssen erfüllt sein?

• Welche Nachbedingungen (Vorbedingungen anderer Anwendungsfälle) müssen sichergestellt werden?

• Wie wichtig ist diese Arbeit?

• Warum wird diese Arbeit durchgeführt?

• Kann die Durchführung verbessert werden?

Page 78: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Anwendungsfällen (2)

Sind die Akteure organisatorische Einheiten oder technische Schnittstellen:

• Ereignisse suchen: Welche Ereignisse der Umgebung sind für das System relevant? Worauf reagiert es geplant?

Weitere Möglichkeit des Vorgehens:

• Aufgabenanalyse:

• Zweck, Ziele des Systems beschreiben

• Die zu ihrer Erreichung notwendigen Aufgaben auflisten.

• Die Ziele der wichtigsten Aufgaben bestimmen.

• Die zur Erreichung dieser Ziele notwendigen Aufgaben ableiten etc.

Page 79: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Tante-Emma-Laden

Page 80: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Klassendiagramm

Definition

Eine Klasse ist eine Menge von Objekten, in der die Eigenschaften (Attribute), Operationen und die Semantik der Objekte definiert werden. Alle Objekte einer Klasse entsprechen dieser Festlegung.

Notation

Klassen werden durch Rechtecke dargestellt, die den Namen der Klasse und/oder die Attribute und Operationen der Klasse enthalten. Klassen-name, 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.

Page 81: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Woraus besteht ein Objektmodell?

Klassen mit

• Attributen und ihren

• Attributspezifikationen

• Operationen

• Beziehungen mit Angabe der

• Kardinalitäten

• insbesondere Generalisierungen

• (Zusammenfassung der Klassen in Pakete) Evtl. auch Objekte

Page 82: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Vergleich des Objektmodells mit dem essentiellem Prozessmodell

• Prozessmodell beschreibt ein System als Menge von Prozessen, die Daten austauschen

• Objektmodell beschreibt ein System als Menge strukturierter Klassen/Objekten (Daten), die Operationen auf ihren Daten ausführen können und miteinander kooperieren.

• Ergänzt man das Prozessmodell um eine geeignete Methodik zur Gestaltung der Speicher, dann erhält man einen Zusammenhang zwischen Prozessmodell und Objektmodell.

• Das Prozessmodell beschreibt welche Operationen der Klassen welche Daten untereinander austauschen und welche Operationen aus welchen anderen Operationen zusammengesetzt sind.

• Das Objektmodell beschreibt zusätzlich zum Prozessmodell, Beziehungen zwischen Daten (Klassen/Objekten).

Page 83: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugbuchung (1)

Page 84: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Flugbuchung (2)

Page 85: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Attributspezifikation

• Name

• Typ

• Anfangswert

• Muß-Attribut (mandatory): muß bei Anlegen des Objektes definiert werden

• Schlüssel (key): kennzeichnet das Objekt eindeutig, auch mehrere Attribute möglich

• Attributwert nicht änderbar (frozen): z.B. Matrikelnummer

• Einheit: (km, DM etc.)

• Beschreibung: Erläuterung bzw. Definition bei abgeleiteten Attributen

Page 86: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beziehungen

Page 87: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Modellierung von Beziehungen als Klassen

Page 88: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Kardinalitäten

Page 89: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

3er Beziehungen

Page 90: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Aggregation

Spezielle Beziehung: Teil-Ganzes (part-whole)

Daher zusätzliche Eigenschaften (z.B. transitiv und antisymmetrisch)

Page 91: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Komposition

Komposition ist ein Spezialfall der Aggregation:

• Jedes Objekt der Komponentenklasse kann nur Komponente eines Objektes der Aggregatklasse sein. D.h. Kardinalität der Aggregat-klasse in der Aggregation darf nicht größer als eins sein. Im all-gemeinen darf eine Komponente aber Komponente anderer Aggregate sein.

• Die dynamische Semantik des Ganzen gilt auch für seine Teile. Wird z.B.das Ganze kopiert, werden auch die Teile kopiert.

• Wird das Ganze gelöscht, so werden auch seine Teile gelöscht

Page 92: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Aggregation und Komposition

Page 93: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Generalisierung und Vererbung

Modellierungsphase:

• Klarheit durch Modellierung von Gemeinsamkeiten

• Vereinfachung durch Reduzierung unabhängiger Features

Implementationsphase:

• Wiederverwendung

• Vereinfachung durch Reduzierung unabhängiger Features

Page 94: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Generalisierung und Vererbung (1)

Page 95: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Generalisierung und Vererbung (2)

Page 96: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beispiel: Generalisierung und Vererbung (3)

Page 97: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Probleme der Vererbung

Vererbung verletzt das Geheimnisprinzip

• Die Unterklasse kennt die Struktur der Implementation der Attribute und Operationen der Oberklasse.

Vererbung verletzt das Lokalitätsprinzip

• Um die Unterklasse zu verstehen, muss man die Oberklasse kennen.

Grenzen der Wiederverwendung

• Wird die Oberklasse neu implementiert, muss evtl. auch die Unterklasse neu implementiert werden.

Page 98: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Schritte zur Konstruktion des Objektmodells

1. Identifizierung von Objekten/Klassen

2. Identifizierung von Beziehungen

3. Identifizierung von Attributen

4. Organisation des Modells mittels Vererbung

5. Iterationen und Verfeinerungen des Modells

Page 99: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Problembeschreibung: Geldautomat

Erstellen Sie ein Modell eines Banknetzwerkes, das Geldschalter und Geldautomaten beinhaltet.

Jede Bank hat ihren eigenen Computer, um Konten zu verwalten und um Transaktionen auf den Konten zu verarbeiten. Die zu den einzelnen Banken gehörenden Geldschalter kommunizieren direkt mit den Bankcomputern.

Kassierer geben an den Geldschaltern die Kontonummer und die eigentliche Transaktion ein.

Die Geldautomaten kommunizieren mit einem Zentralcomputer, welcher die vom Kunden gewählten Transaktionen an die jeweilige zuständige Bank weitergibt. Der bereitgestellte Zentralcomputer gehört einem Konsortium von Banken. Die Geldautomaten akzeptieren Scheckkarten, interagieren mit den Benutzern, kommunizieren mit dem Zentralcomputer, um Transaktionsdaten weiterzugeben und geben Geld aus.

Das System besitzt besondere Sicherheitsvorkehrungen. Dazu gehört die korrekte Verarbeitung eines gemeinsamen Zugriffs auf ein Konto.

Die Banken stellen für ihre Computer ihre eigene Software bereit. Sie sind also nur zuständig für die Entwicklung der Software für die Geldautomaten und das Netzwerk.

Page 100: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Objekten und Klassen (1)

Vorgehensweise

• Objekte und Klassen können oft durch Nominalphrasen in der Problembeschreibung (unstrukturiert oder strukturiert durch z.B. Use cases) identifiziert werden (Nominalphrasenanalyse).

• Kandidaten aus der Problembeschreibung müssen überprüft werden.

Page 101: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Objekten und Klassen (2)

Klassenkandidaten

Page 102: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Objekten und Klassen (3)

Kriterien zur Wahl der richtigen Klassen

• Eine Klasse für ein Konzept (keine redundanten Klassen)

• Eliminierung von irrelevanten Klassen (Klassen, die nicht zum Problembereich gehören).

• Eine Klasse sollte spezifisch sein (keine unklaren Klassen, die mehrere Bedeutungen haben können).

• Wörter, die ein Objekt näher beschreiben, sollten als Attribut modelliert werden.

• Besteht die unabhängige Existenz eines Wortes, sollte dieses als Klasse modelliert werden.

• Operationen mit Merkmalen sollten als Klassen modelliert werden.

• Rollen sind Beziehungen, keine Klassen.

• Implementierungskonstrukte werden erst im Design modelliert.

Page 103: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Objekten und Klassen (4)

Eliminierung unnötiger Klassen

Page 104: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Beziehungen

Vorgehensweise

• Beziehungen können oft durch Verbalphrasen in der Problembeschreibung (unstrukturiert oder strukturiert durch z.B. Use cases) identifiziert werden (Verbalphrasenanalyse).

• Kandidaten aus der Problembeschreibung müssen analysiert werden.

Page 105: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Beziehungskandidaten aus der Problembeschreibung

• Banknetzwerk beinhaltet Geldschalter und Geldautomaten

• Bank hat Computer

• Bankcomputer verwaltet Konten

• Bankcomputer verarbeitet Transaktionen auf Konten

• Bank gehören Geldschalter

• Kassierer geben Transaktionen für Konten ein

• Geldautomaten kommunizieren mit Zentralcomputer über Transaktionen

• Zentralcomputer gibt Transaktionen weiter an Banken

• Zentralcomputer gehört Konsortium

• Konsortium besteht aus Banken

• Geldautomat akzeptiert Scheckkarten

• Geldautomat interagiert mit Benutzer ...

Page 106: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Identifizierung von Attributen

Vorgehensweise

• Die Problembeschreibung bietet selten die Möglichkeit, einen Großteil der Attribute zu identifizieren, statt dessen muß auch das Anwendungswissen herangezogen werden.

• Zuerst sollten nur die wichtigsten Attribute gesucht werden, andere können später identifiziert werden. Insbesondere sollten keine Attribute modelliert werden, die nur für die Implementierung von Bedeutung sind.

Page 107: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Aktivitätsdiagramm

Definition

In einem Aktivitätsdiagramm werden die Objekte eines Programms mittels der Aktivitäten, die sie während des Programmablaufs vollführen, be-schrieben. Eine Aktivität ist ein einzelner Schritt innerhalb eines Pro-grammablaufs, d.h. ein spezieller Zustand eines Modellelementes, 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 entscheiden sein. Somit gilt ein Aktivitätsdiagramm als Sonderform eines Zustandsdiagramms, dessen Zustände der Modellelemente in der Mehrzahl als Aktivitäten definiert sind.

Notation

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.

Page 108: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Aktivitätsdiagramm - Beispiel

Page 109: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Kollaborationsdiagramm

Definition

Die verschiedenen Modellelemente eines Programmes agieren innerhalb des Programmablaufes miteinander. Um diese Interaktionen für einen bestimmten begrenzten Kontext, unter besonderer Beachtung der Be-ziehungen unter den einzelnen Objekten und ihrer Topographie, darzu-stellen, verwenden wir das Kollaborationsdiagramm.

Notation

Die einzelnen Objekte werden als Rechtecke dargestellt. Diese werden durch Assoziationslinien mit einander verbunden, auf denen dann die Nachrichten, bestehend aus einer durchgehenden zeitlichen Nummerie-rung, dem Namen der Nachrichten und Antworten und ihren möglichen Argumenten. Ein Pfeil zeigt die Richtung der Nachricht vom Sender zum Empfänger. Antworten werden in der Form antwort:=nachricht() symbolisiert.

Die zeitliche Nummerierung erfolgt mittels Durchnummerierung der einzelnen Nachrichten angefangen bei 1, die interaktionsauslösende Startnachricht erhält noch keine Nummerierung.

Page 110: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Kollaborationsdiagramm - Beispiel

Page 111: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Sequenzdiagramm

Definition

Das Sequenzdiagramm beschreibt die zeitliche Abfolge von Interaktionen zwischen einer Menge von Objekten innerhalb eines zeitlich begrenzten Kontextes.

Notation

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 Objektlebens-linien beschrieben. Auf diesen Pfeilen werden die Nachrichtennamen in der Form: nachricht(argumente) notiert. Nachrichten, die als Antworten deklariert sind erhalten die Form: antwort:=nachricht(). Nachrichten können Bedingungen der Form: [bedingung] nachricht() zugewiesen be-kommen. Iterationen von Nachrichten werden durch ein Sternchen „*“ vor dem Nachrichtennamen beschrieben. Objekte, die gerade aktiv an Inter-aktionen beteiligt sind, werden durch einen Balken auf ihrer Lebenslinie zu kennzeichnen.

Page 112: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Sequenzdiagramm - Beispiel

Page 113: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustandsdiagramm

Definition

Ein Objekt kann in seinem Leben verschiedenartige Zustände annehmen. Mit Hilfe des Zustandsdiagramms visualisiert man diese, sowie Funktionen, die zu Zustandsänderungen des Objektes führen.

Notation

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.

Page 114: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustände

Definition

Zustand = Abstraktion der Gesamtheit der Merkmalsausprägungen eines Systems.

• Merkmale und Ausprägungen müssen zunächst nicht definiert sein.

• In einem Zustand qualitativ homogene Reaktion auf Events.

• In verschiedenen Zuständen mindestens für ein Event eine unterschiedliche Reaktion.

• Übergänge zwischen zwei Zuständen durch Events.

• Ein System reagiert in einem Zustand nicht auf ein bestimmtes Event gdw. für dieses Event ist kein Zustandsübergang eingetragen.

Page 115: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustandsdiagramm - Beispiel (1)

Page 116: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustandsdiagramm - Beispiel (2)

Page 117: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Zustandsdiagramm mit bedingten Übergängen - Beispiel (3)

Page 118: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Komponentendiagramm

Definition

Damit bei späterer Implementierung der Softwarelösung Compiler- und Laufzeitabhängigkeiten klar sind, werden die Zusammenhänge der einzel-nen Komponenten der späteren Softwarelösung in einem Komponenten-diagramm dargestellt.

Notation

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 Compilierreihenfolge auf.

Page 119: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Komponentendiagramm - Beispiel

Page 120: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Einsatzdiagramm

Definition

Ein Einsatzdiagramm beschreibt, welche Komponenten (Objekte) auf welchen Knoten ablaufen, d.h. wie diese konfiguriert sind und welche Abhängigkeiten bestehen.

Notation

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.

Page 121: Systementwicklung Vorlesung SS 2006 Paul Manthey.

Systementwicklung

Einsatzdiagramm - Beispiel