Vorlesung "Praktische Softwaretechnik" Teil 10: Basiskonzepte der Systemanalyse (2) Vortragender: Prof. Dr. Dirk Riehle, FAU Folien: Prof. Dr.­Ing. Detlef Kips, develop group

Praktische Softwaretechnik • Informatik • Martensstraße 3 • 91058 Erlangen

Systemanalyse: Überblick der Sichten und Basiskonzepte Funktionsorientierte Sicht Funktionsbäume Datenflussdiagramme

Objektorientierte Sicht • Klassenmodelle (Forts.)

Datenorientierte Sicht • Entity­Relationship­Modelle • Datenkataloge

Szenariobasierte Sicht • Szenarien und Interaktionen • Interaktionsdiagramme

Zustandsorientierte Sicht • Zustandsautomaten und Statecharts • Petri­Netze Kontrollflussorientierte Sicht • Kontrollstrukturen • Ablaufpläne • Aktivitätsdiagramme Regelbasierte Sicht • Entscheidungstabellen / ­bäume • Regelsysteme

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 2

Generalisierung/Spezialisierung: Einführungsbeispiel (1)  Die Klassen Kunde und Dozent weisen gemeinsame Eigenschaften auf:  Gemeinsame Attribute, z.B. Name und Adresse  Gemeinsame Operationen, z.B. Adresse drucken

Kunde Name Adresse Funktion Umsatz Adresse drucken Umsatz ermitteln

Dozent Name Adresse Biographie Honorar pro Tag Adresse drucken Trage Zuordnung Seminartyp ein Trage Zuordnung Seminarveranstaltung ein

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 3

Generalisierung/Spezialisierung: Einführungsbeispiel (2)  Die gemeinsamen Eigenschaften der Klassen Kunde und Dozent werden in einer gemeinsamen Oberklasse Person zusammengefasst  („ausgeklammert“).  Die Klasse Person ist eine Generalisierung der Klassen Kunde bzw.  Dozent.  Die Klassen Kunde bzw. Dozent sind Spezialisierungen der Klasse  Person. Person Name Adresse Adresse drucken

Kunde Funktion Umsatz Umsatz ermitteln

Dozent Biographie Honorar pro Tag Trage Zuordnung Seminartyp ein Trage Zuordnung Seminarveranstaltung ein

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 4

Generalisierung/Spezialisierung: Grundprinzip  Generalisierung und Spezialisierung sind (komplementäre) Abstraktions­ prinzipien zur hierarchischen Strukturierung der Semantik eines  Systemmodells.  Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische  Beziehung zwischen einem spezielleren und einem allgemeineren  Modellelement (bzw. vice versa).  Das speziellere Element verfügt über alle Merkmale des  allgemeineren, kann jedoch zusätzliche Merkmale aufweisen.  Forderung: Das speziellere Element ist verhaltenskompatibel zum  allgemeineren, das allgemeinere kann also durch das speziellere  Element semantisch ersetzt werden (Substitutionsprinzip).  Spezialisierung = semantische Verfeinerung Generalisierung = semantische Verallgemeinerung

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 5

Generalisierung/Spezialisierung: Beziehung zwischen Oberklasse und Unterklassen Durch eine Generalisierung (bzw. Spezialisierung) wird eine Oberklasse zu  einer oder mehreren Unterklassen in Beziehung gesetzt:  Unterklassen übernehmen von der Oberklasse  sämtliche Eigenschaften (alle Attribute und Beziehungen)  das gesamte Verhalten (alle Operationen)  Unterklassen können gegenüber der Oberklasse  Eigenschaften und Verhalten hinzufügen (d.h. neue Attribute,  Beziehungen und Operationen definieren)  Eigenschaften und Verhalten redefinieren (d.h. unter Wahrung  bestimmter Randbedingungen vorhandene Attribute, Beziehungen  und Operationen ändern)  Zusicherungen verschärfen  Unterklassen können weder Attribute und Beziehungen, noch  Operationen der Oberklasse entfernen (Verstoß gegen das  Substitutionsprinzip)

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 6

Generalisierung/Spezialisierung: Mengentheoretische Interpretation  Mengentheoretisch kann jede Instanz einer Unterklasse auch als Instanz der  Oberklasse aufgefasst werden:  Definition: Generalisierung/Spezialisierung  Seien A, B Klassen mit A, B ⊆ Ω (Objektuniversum)  A ist Generalisierung von B :⇔ B ⊆ A

(Mengeninklusion, B "is_a" A)  A ist Spezialisierung von B :⇔ A ⊆ B

(inverse Mengeninklusion, A "is_a" B)  Eigenschaften:  Die Gen/Spez.­Beziehung ist reflexiv (trivial) und transitiv:  A "is_a" B ∧ B "is_a" C ⇒ A "is_a" C  Die irreflexive, transitive Hülle der (direkten) Ober­ bzw. Unterklassen­ beziehung heißt Vorgänger­ bzw. Nachfolgerbeziehung.

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 7

Generalisierung/Spezialisierung: Notation in UML  Notation für einfache Gen/Spez­Beziehungen: Person

Kunde

Dozent

 Zusammenfassung mehrerer semantisch verwandter Gen/Spez­ Beziehungen: Person

Kunde

Dozent

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 8

Mehrfachgeneralisierung (1)  Mehrfachgeneralisierung („Multiple Inheritance“) tritt auf, wenn eine (Unter­)Klasse Eigenschaften und Verhalten von mehreren Oberklassen in  sich vereinigt. Sie kann dann als Spezialisierung verschiedener Oberklassen  aufgefasst werden.  Mengentheoretisch ist die Unterklasse als Teil der Schnittmenge ihrer  sämtlichen Oberklassen zu interpretieren.   Spezialfall: Die Oberklassen sind ihrerseits überlappende Unterklassen  einer gemeinsamen Ahnenklasse.  In Modellen mit Mehrfachgeneralisierung bilden die Gen/Spez­Beziehungen  einen gerichteten, azyklischen Graphen ("Klassenheterarchie").

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 9

Mehrfachgeneralisierung (2): Beispiel

Uhr-Anzeige Stunde Minute

DigitalAnzeige 13:45

Analog-Anzeige

Anzeigengröße

Ziffernblatt Stundenzeiger Minutenzeiger

DigitalAnalog-Anzeige DigitalAnordnung

13:45

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 10

Abstrakte Klassen und Operationen (1)  Eine abstrakte Klasse ist eine Klasse, zu der es keine Instanzen gibt.  Abstrakte Klassen dienen als Strukturierungsmechanismus zum  "Ausklammern" gemeinsamer Eigenschaften aus mehreren  "ähnlichen" konkreten Unterklassen.  Der so entstehende Oberbegriff ist im Regelfall eine verallgemeinerte  Abstraktion ohne reale Entsprechung in der Anwendungswelt.  Eine abstrakte Operation wird nur durch ihre Signatur spezifiziert und besitzt  keine Implementierung.  Hat eine Klasse abstrakte Operationen, so ist sie abstrakt.   Eine abstrakte Operation muss in allen konkreten Unterklassen  implementiert werden.   Abstrakte Elemente (Klassen, Operationen) werden in UML durch kursive  Schrift oder durch die Eigenschaftsspezifikation {abstract} gekenn­ zeichnet.

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 11

Abstrakte Klassen und Operationen (2): Beispiel   

Icon {abstract} origin : Point display() {abstract} getID() : Integer

Rectangularlcon {abstract} height : Integer width : Integer

Button display()

Arbitrarylcon {abstract} edge : LineCollection isInside(p : Point) : Boolean

MyIcon display()

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 12

Redefinition von Operationen: Beispiel



Operation Buchen der Klasse Konto: Operation Buchen(Betrag : Geld) { Kontostand := Kontostand + Betrag }



redefinierte Operation Buchen der Klasse Sparkonto: Operation Buchen(Betrag : Geld) { KS := self.GetKontostand(); //Lesender Zugriff auf das //geerbte Attribut if KS + Betrag >= 0 then Konto.Buchen(Betrag); // Aufruf der geerbten Operation }

Konto Konto-Nr: int Kontostand: int Buchen (Betrag: Geld) GetKontostand(): Geld

Sparkonto

Buchen (Betrag: Geld)

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 13

Polymorphismus: Begriffsklärung   Grundprinzip des Polymorphismus: Hinter dem gleichen Operationsbezeichner können sich unterschiedliche  Realisierungen (Methodenimplementierungen) verbergen. Beispiele:  Operator­Überladung ("Overloading")  Konstruktoren mit unterschiedlicher Signatur  Vererbungs­Polymorphismus Prinzip des Vererbungs­Polymorphismus:  Voraussetzungen auf seiten der Programmiersprache:  Möglichkeit der Redefinition von Operationen in den Unterklassen  Dynamisches Binden zur Laufzeit ("late binding")  Wird eine redefinierte Operation zur Laufzeit aufgerufen, so gelangen  unterschiedliche konkrete Implementierungen der Operation zur  Ausführung, je nachdem, zu welcher Klasse (innerhalb der Gen/Spez­ Hierarchie) das Empfängerobjekt gehört. Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 14

Vererbungspolymorphismus: Beispiel 

Spezifikation einer Klienten­Operation,  die ein Objekt der Klasse Konto aufruft: 

void Barein_und_auszahlungen (Konto &object, float Zahlung) {... object.Buchen(Zahlung); ... }



Konto-Nr: int Kontostand: int Buchen (Betrag: Geld) GetKontostand(): Geld

Aufrufe der Klienten­Operation:

Barein_und_auszahlungen (einKonto,300.20); Barein_und_auszahlungen (einSparkonto,-500.00);



Konto

Beim Aufruf object.Buchen(Zahlung)  kommen unterschiedliche Methoden zur  Ausführung, je nachdem, ob object auf ein Konto oder auf ein Sparkonto  verweist.

Sparkonto

Buchen (Betrag: Geld)

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 15

Einschränkungen / Zusicherungen: Motivation und Begriffsklärung  Motivation  Bei der schrittweisen Präzisierung eines Klassenmodells im Rahmen  der Systemanalyse und des Grob­ und Feindesigns stößt man immer  wieder auf komplexe Zusammenhänge, die sich einer Spezifikation mit  graphischen Ausdrucksmitteln entziehen.  Man benötigt deshalb geeignete Möglichkeiten, um das Klassenmodell  durch zusätzliche, textuell spezifizierte Einschränkungen zu ergänzen.  Definition: Einschränkung (Constraint)  Eine Einschränkung ist eine Bedingung bzw. ein abstraktes Prädikat,  das die möglichen Inhalte, den Zustandsraum oder die Semantik eines  Modellelements näher bestimmt (≅ "einschränkt").  Synonyma und verwandte Begriffe:  Zusicherung (Assertion), Integritätsbedingung, Invariante, Restriktion

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 16

Einschränkungen / Zusicherungen: Typische Einsatzmöglichkeiten  Einschränkungen (Constraints) werden typischerweise verwendet zur  Definition von ...  ... Restriktionen für zulässige Werte von Attributen  ... Vor­ oder Nachbedingungen für Operationen  ... Invarianten für Klassen, Objektlebenszyklen, ....  ... Berechnungsvorschriften für → abgeleitete Elemente  ... Ordnungsbeziehungen auf Mengen von Modellelementen  ... Überwachungsvorschriften für Nachrichten und Zustandsübergänge  ... zeitlichen Reihenfolgebedingungen

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 17

Einschränkungen / Zusicherungen: Notation in UML (1)  Zusicherungen werden in UML in geschweifte Klammern gefasst: { constraint_specification }  Die UML schreibt keine spezifische Syntax für Einschränkungen bzw.  Zusicherungen vor. Es gibt mehrere sinnvolle Möglichkeiten, Constraints  zu formulieren:  natürlichsprachliche Beschreibung  Prädikatenlogik  Object Constraint Language (OCL)  Pseudocode  Die Spezifikation von Einschränkungen / Zusicherungen wird typischer­ weise im Laufe des Analyse­/Designprozesses sukzessive präzisiert:   In den frühen Phasen (Anforderungsdefinition, Analyse) kommen  eher informelle Notationsformen zum Einsatz (natürl. Sprache,  einfache prädikatenlogische Ausdrücke, wenn/dann­Regeln)  In der Designphase werden dann, soweit erforderlich, komplexere  Zusammenhänge formal spezifiziert (Pseudocode, OCL). Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 18

Einschränkungen / Zusicherungen: Notation in UML (2)  Einschränkungen bzw. Zusicherungen können in UML an beliebige  andere Modellelemente "angehängt" werden.  z.B. an Klassen, Attribute, Operationen, Assoziationen, ...  Die Verknüpfung von n Modellelementen mit einer Einschränkung bzw.  Zusicherung kann graphisch notiert werden ...  ... im Spezialfall n = 1 durch direkte Angabe der Einschränkung „in  der Nähe“ des betroffenen Modellelements;  ... im Spezialfall n = 2 durch eine gestrichelte, evtl. gerichtete Kante  zwischen den beiden betroffenen Modellelementen, neben der die  Einschränkung notiert wird;  ... im allgemeinen Fall n ≥ 1 durch Angabe der Einschränkung in  einer „Notiz“ (Note), die mit allen von der Einschränkung  betroffenen Modellelementen durch gestrichelte Kanten verbunden  ist

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 19

Einschränkungen / Zusicherungen: Beispiele Beispiel 1: Zusicherungen für Attributwertemengen Rechteck a {a > 0} b {b > 0} kantenAendern(pA,pB) anzeigen () entfernen ()

Quadrat {a = b}

Beispiel 2: Ordnungsbeziehungen auf Aggregationen Namensliste

1

1..* enthält {geordnet:nachname}

Kunde nachname vorname

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 20

Einschränkungen / Zusicherungen: Beispiele Beispiel 3: Logische Konsistenzbedingungen für Assoziationen

projektleiter

leitet

1

Mitarbeiter

0..*

Projekt

{subsets} 0..*

1..*

projektmitglieder

hat

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 21

Einschränkungen / Zusicherungen: Beispiele Beispiel 4: Logische Konsistenzbedingungen für Assoziationen

Dozent

1..*

kann fachlich abhalten

Seminarleiter

1..*

{∀ v ∈ Veranstaltung: v.Dozenten ⊆ v.Seminartyp.Dozenten}

* Veranstaltung

1..*

entspricht *

1

Seminartyp

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 22

Einschränkungen / Zusicherungen: Beispiele Beispiel 5: Vor­ und Nachbedingungen von Operationen Kunde Vorname: Nachname: Funktion: Umsatz:

String String String real

... Umsatz_ermitteln (in Intervall_Beginn: date, Intervall_Ende: date): real ...

{ «precondition» Intervall_Beginn forAll (d | self.Seminartyp.Dozenten -> includes(d)) Beispiel 2: Definition einer Klasseninvariante

Context Projekt self.Projektmitarbeiter -> notEmpty AND self.Projektmitarbeiter -> includes(self.Projektleiter) Beispiel 3: Berechnungsvorschrift für ein abgeleitetes Attribut

Context Seite /self.Basisadresse = = self.Segment.Basisadresse + self.offset * self.Segment.Seitentyp.Länge Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 30

Modularisierung objektorientierter Modelle  Die Komplexität großer objektorientierter Klassenmodelle wird schnell  schwer beherrschbar.  Strukturierung durch Modulbildung und Kapselung erforderlich  Verwendung von Paketen (Packages) als Strukturierungshilfsmittel  Ein Paket fasst mehrere Modellelemente (z.B. Klassen) zu einer größeren  Einheit zusammen.  Pakete werden aufgrund logischer und/oder physischer  Zusammenhänge gebildet.  Besonders geeignet sind sie zur Kapselung von separaten  Bibliotheken, Subsystemen oder Schnittstellen zu Fremdsystemen.

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 31

Pakete und Paketelemente  Pakete können beliebig viele, verschiedene Modellelemente enthalten.  Jedes Modellelement ist einem bestimmten Paket zugeordnet, d.h. ein  Modellelement kann nicht zu verschiedenen Paketen gehören.  Paketelemente können nach außen sichtbar oder verborgen sein  Kennzeichnung durch + (public) oder - (private).  Pakete sind selbst Modellelemente, die ihrerseits Bestandteil eines  Pakets sein können (⇒ Hierarchiebildung möglich)  In UML werden Pakete als Karteikarten  mit "Reiter" dargestellt.  Paketname wird in der Karteikarte  oder auf dem "Reiter" notiert  Karteikarte enthält eine graphische  Repräsentation der im Paket  zusammengefassten Modell­ elemente (Klassen, Assoziationen, Schnittstellen, Pakete, ...)

Auftragsverwaltung

Auftrags­ verwaltung ­ Preiskalkulation ­ DB­Schnittstelle + Auftragserfassung

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 32

Beziehungen zwischen Paketen  Um die logischen und strukturellen Zusammenhänge zwischen den Paketen  eines Systemmodells auf einem hohen Abstraktionsniveau zu zeigen, kann  man Beziehungen zwischen Paketen spezifizieren:   «import»­ bzw. «access»­ Abhängigkeit: Paket A hat Zugriff  auf alle sichtbaren Modell­ elemente aus Paket B  «use»­Abhängigkeit: Paket A  benutzt Modellelemente aus  Paket B.  «merge»­Abhängigkeit: Paket B  erbt und spezialisiert die  Modellelemente aus Paket A (Spezialisierungsmechanismus  für Pakete)

Benutzerschnittstelle «import»  

«access»  

Auftragsbearbeitung «import»  

«access»  

Preiskalkulation

Datenbank­ Schnittstelle «merge»  

«merge»  

Server­DB­ Schnittstelle

Lokale DB­ Schnittstelle

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 33

Vorgehensweisen zur Paketbildung  Top­Down­Ansatz  Eine grobe Partitionierung des Systemmodells in Pakete erfolgt  bereits zu Beginn der Systemanalyse, d.h. vor der Identifikation der  einzelnen Klassen.  Ausgehend von der dabei gefundenen groben Paketaufteilung wird  die Systemanalyse für die einzelnen Pakete separat durchgeführt.  Bottom­Up­Ansatz  In einem Systemmodell, das eine kritische Größe bzw. Komplexität  überschritten hat, wird durch Partitionierung in Pakete eine  zusätzliche Abstraktionsebene eingeführt.  Modellelemente, die in mehreren Paketen benötigt werden, werden  dabei in separaten Paketen „ausgeklammert“ (→ „Faktorisierung“).

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 34

UML­Diagramme zur Klassen­ und Objektmodellierung Klassendiagramme  Klassendiagramme dienen zur Darstellung einer Menge von semantisch  zusammengehörigen Klassen sowie von deren Beziehungen untereinander.  Ein Klassendiagramm liefert eine strukturelle Beschreibung des statischen  Daten­ bzw. Objektmodells. Instanzdiagramme  Ein Instanzdiagramm zeigt eine Menge von semantisch zusammengehörigen  Objekten und deren Beziehungen untereinander.  Ein Instanzdiagramm liefert einen "Schnappschuss" des dynamischen  Systemzustands zu einem bestimmten Zeitpunkt der Systemlaufzeit. Paketdiagramme  Ein Paketdiagramm zeigt eine Menge von Paketen, deren Inhalte und ihre  Beziehungen zueinander.  Ein Paketdiagramm liefert eine Partitionierung des Zielsystems in modulare  Subsysteme und verdeutlicht deren Zusammenhänge und Abhängigkeiten. Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 35

UML­Klassendiagramme: Beispiel

Person

Bankverbindung

1..*

1

hat

Zahlungsempfänger

1

1

1..*

0..*

Bankkunde 1..*

verfügt über 1..*

ist Begünstigter

Ziel

Berechtigung

Bankkonto 1..*

0..*

Zahlungsanweisung

Einzelüberweisung 2..*

besteht aus

0..*

1 Quelle

Girokonto

Depot

Sparkonto

Dauerauftrag 1

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 36

UML­Instanzdiagramme: Beispiel eineBankverbindung KtoNr = "4711" BLZ = "76050080"

einGirokonto KtoNr = "880090" BLZ = "76050070" verfügt über

hat ist Begünstigter

einZahlungsempfänger Name = "HansMoser" ...

einBankkunde Name = "TheoLingen" ...

Ziel

Ziel

eineEinzelüberweisung Datum = "01.04.2007" ... eineEinzelüberweisung Datum = "04.05.2007" ...

ist Begünstigter

eineBankverbindung KtoNr = "4712" BLZ = "76150190"

ist Begünstigter

hat eineBerechtigung

verfügt über

Verfügung  = "einzeln"

einGirokonto KtoNr = "1355455" BLZ = "76050101" einDauerauftrag

Zweck       = "Miete            Postweg 7" besteht aus Frequenz  = "monatlich" ...

besteht aus

Quelle

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 37

UML­Paketdiagramme: Beispiel

Kontoverwaltung

«access» 

Benutzerschnittstelle

GUIManager

«import»  «access» 

Zahlungsverkehr «import» 

«access» 

Dauerauftrags­ verwaltung

Datenbank­ Schnittstelle «merge» 

Server­DB­ Schnittstelle

«access» 

«merge»  «access» 

Lokale DB­ Schnittstelle

DBMS

«merge»  «merge» 

Server­ DBMS lokales DBMS «access» 

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 38

Einsatz objektorientierter Klassenmodelle  Objektorientierte Klassenmodelle können durchgängig in sämtlichen  Phasen des Entwicklungsprozesses eingesetzt werden.  Dabei wird das Klassenmodell im Verlauf des Entwicklungsprozesses  typischerweise in mehreren Iterationen sukzessive immer weiter  verfeinert.  Typische Schritte eines iterativen OOAD­Vorgehensmodells sind u.a.:  Identifikation der relevanten Klassen und Objekte  Grobe Festlegung ihrer Eigenschaften und Verantwortlichkeiten  Spezifikation der semantischen Beziehungen zwischen den Klassen  ... durch Assoziationen, Multiplizitäten und Rollen  ... durch Generalisierungs­/Spezialisierungsbeziehungen  Modularisierung des Systemmodells, insbesondere durch Paketbildung  Präzisierung des Systemmodells, insbesondere durch Einführung von Einschränkungen und Zusicherungen   Ein ausführliches Beispiel für ein OOAD­Vorgehensmodell folgt später! Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 39

Vor­ und Nachteile objektorientierter Klassenmodelle Vorteile + allgemein anerkannter „State of the Art“ der Systemmodellierung + mächtiges Konzept zur universellen Modellierung komplexer Systeme + integrierte Modellierung struktureller und dynamischer Eigenschaften   + schrittweise Verfeinerung der Modellinformation durch sämtliche Phasen  des Entwicklungsprozesses + Für OOA/OOD sind ausgereifte Vorgehensmodelle sowie eine allgemein  akzeptierte Standardnotation (UML) verfügbar. + sehr gute Integration mit anderen Basiskonzepten (Zustandsautomaten,  Aktivitätsdiagrammen, Szenarien, Interaktionsdiagrammen, ... ) + gängige CASE­Tools bieten mächtige Werkzeuge zur objektorientierten  Modellierung und Codegenerierung Nachteile

– Mächtigkeit und Komplexität der zugrundeliegenden Modellierungs­ –

konzepte führt u.U. zu schwer verständlichen, fehlerbehafteten Modellen mangelnde formale Fundierung erschwert Modellvalidierung

Prof. Dr. Detlef Kips • Praktische Softwaretechnik • Informatik • Universität Erlangen­Nürnberg • 40