Einstieg in die Objektorientierung .ppt

• OO als neuer methodischer Ansatz
• Der grundsätzliche Unterschied
• Die Stärken der OO-Methode
• Konzept und Begriffe der OO-Welt
• • Objekte
  • Nachrichten
  • Klassen
  • Assoziation
  • Aggregation
  • Vererbung
  • Polymorphismus und Binden
• Terminologie und Notation
• Verschiedene Sichten auf das Modell
• OOA: Objektorientierte Analyse
• • Der Prozeß der Systementwicklung
  • Strukturierung des Systems (Problemanalyse)
  • Objektorientierte Analyse (OOA)
• OOD: Objektorientiertes Design
• • Object Modelling Technique (OMT) nach Rumbaugh
• OOP: Objektorientierte Programmierung

OO als neuer methodischer Ansatz

Ausgangspunkt für die Aktualität des Themas Objektorientierung sind die praktischen Erfahrungen, die bei

• der Entwicklung der OO-Programmiersprachen (z.B. Smalltalk, C++,
  Eiffel, etc.) sowie
• dem Einsatz objektorientierter Applikationen (z.B. Desktop-Oberflächen, Simulationssysteme, etc.)

gesammelt wurden und bereits zu Beginn der 80er Jahre zur Etablierung des Begriffs objektorientierte Programmierung (OOP) führten.

Begonnen hat die Geschichte" vor über 25 Jahren /Heilmann/ :

• In der Programmiersprache SIMULA wurde das Klassenkonzept eingesetzt.
• Der Begriff Objektorientierung wurde jedoch von Smalltalk geprägt, indem das Klassenkonzept von SIMULA übernommen wurde.
• Smalltalk-76 sah Vererbungseigenschaften vor.
• Ab ca. 1985 begann die Einbindung der objektorientierten Konzepte in die prozeduralen Programmiersprachen, wodurch sogenannten hybride Sprachen entstanden, wie z.B. C++, Objective-C, Object Pascal, objektorientiertes COBOL.
• Als reine objektorientierte Sprache entstand z.B. Eiffel.
• Ab ca. 1988 wurde die Notwendigkeit erkannt, ein methodisches Vorgehen für die objektorientierte Analyse und das objektorientierte Design zu entwickeln.

Das Bestreben, die Paradigmen der objektorientierten Programmierung (OOP) auf die frühen Phasen des Software-Lebenszyklus zu übertragen, war methodisch fruchtbar.

Eine beachtliche Anzahl von Methoden zur objektorientierten Analyse (OOA) und zum objektorientierten Design (OOD) entstanden und entstehen immer noch, entweder

• als neue Technik mit eigenem Regelwerk, im Gegensatz zu konventionellen Techniken (revolutionärer Ansatz); (vgl. /Booch/, /Embley u.a./), oder
• als alte Technik modifiziert für die Objektorientierung (traditioneller Ansatz);
  (vgl. /Shlaer,Mellor/, /Rumbaugh u.a./) oder
• als Synthese des revolutionären und traditionellen Ansatzes (evolutionärer Ansatz); (vgl. /Coad,Yourdon/, /Martin,Odell/, /Wassermann u.a./).

Der grundsätzliche Unterschied

In traditionellen Softwaresystemen arbeitet eine Reihe von Progammen oder Unterprogrammen auf einer Sammlung von mehr oder weniger in Beziehung stehender Daten. Dabei sind die Daten und die prozedurale Logik separate Komponenten.

Traditionelles Softwaresystem

Das Konzept der Datenkapselung (encapsulation) sieht eine untrennbare Zusammenfassung von Daten und Funktionen, die ausschließlich zur Manipulation dieser Daten dienen, zu einer Einheit vor.

Objektorientiertes Softwaresystem

Die Daten der Datenkapsel sind damit nur exklusiv von den dazugehörigen Funktionen, und von niemand anderem sonst, manipulierbar. Die Funktionen werden von der Datenkapsel dem Umfeld angeboten, um die Daten in der Datenkapsel lesen bzw. manipulieren zu können.

Die künstliche Trennung von Daten und Funktionen der klassischen Anwendungssysteme wird somit aufgehoben.

Die Stärken der OO-Methode

Die Stärken der Methode liegen in:

• Der besseren Beherrschung der Komplexität von Systemen.
  Das liegt in erster Linie daran, dass die Methode eine Abbildung der Objekte der realen Welt und deren Kommunikation und (Re-)Aktionen ermöglicht und damit der menschlichen Denkweise entspricht sowie der einheitlichen Darstellung des Systems in allen Phasen der SW-Entwicklung.
• Der Förderung der Wiederverwendbarkeit von Teilen des Systems.
  Die Modellierung von Gemeinsamkeiten und die Vererbung sorgen bei sachgerechter Anwendung einerseits für eine Codereduktion, andererseits für die Bildung abstrakterer, mehrfach verwendbarer Klassen.
• Zuverlässigkeit und Änderungsfreundlichkeit.
  Langfristig sorgt die Wiederverwendung von vorhandenen und bereits getesteten Systemteilen für eine größere Zuverlässigkeit des Systems. Der modulare Aufbau erleichtert die Erweiterung und Änderung des Systems.

Diese Vorteile kann man erreichen, jedoch darf man nicht vergessen:

A fool with a tool is just a fool!

Konzept und Begriffe der OO-Welt

In diesem Abschnitt werden zunächst die Konzepte der Objektorientierung und die in diesem Kontext jeweils relevanten Begriffe erklärt.

Die Kenntnis und das Verständnis der Konzepte und Begriffe der OO-Welt ist die wesentliche Voraussetzung für die nachfolgend beschriebene objektorientierte Modellbildung in den jeweiligen Phasen des Prozesses der Systementwicklung.

Henderson-Sellers hat 12 Literaturquellen ausgewertet und daraus die Grundpfeiler des OO-Paradigmas extrahiert /Heilmann/:

• Datenkapselung
• Klassen von Objekten
• Vererbung und
• Polymorphismus

Zusätzlich, aber nicht durchgängig, sind auch Verweise auf :

• dynamisches Binden
• Overloading
• Methoden
• Nachrichten

enthalten.

Heute besteht weitgehend Einigkeit darüber, welche Elemente für die Objektorientierung erforderlich sind:

• Objekt
• Nachricht
• Klasse
• Assoziation
• Aggregation
• Vererbung
• Polymorphismus

Objekt

Die Einheit von Funktionen und Daten wird als Objekt (Instanz / object) bezeichnet. Objekte sind damit Ansammlungen von Daten bzw. Attributen (in einer Einheit), die auf Anstoß (Botschaften) von anderen Objekten mit der Ausführung von Funktionen bzw. Methoden reagieren.

Attribute und Methoden können öffentlich oder privat sein. Öffentliche Attribute widersprechen dem Prinzip der Datenkapselung; sie sind zu vermeiden und zum Glück in einigen Programmiersprachen (z.B. Smalltalk) verboten.

Die öffentlichen Methoden ermöglichen die Kommunikation mit dem Objekt und legen sein Verhalten fest. Die privaten Methoden tragen ebenfalls zum Verhalten des Objekts bei, die privaten Attribute beschreiben den inneren Zustand des Objekts.

Das Objekt

• Objekte haben Attribute

  Alle Daten, die den aktuellen Zustand eines Objektes repräsentieren und Bestandteil der Datenkapsel sind, werden als Attribute (attributes / Instanzvariablen / instance variables) bezeichnet.

  Attribute können elementare Elemente (z.B. NetzspannungInVolt : INTEGER) oder auch wiederum Objekte (z.B. SpannungsWandler : Transformator) sein. Jedem Attribut ist ein entsprechender (Daten-) Typ zugeordnet.

  Objekte können somit atomare Objekte (wenn sie nur elementare Attribute haben) oder zusammengesetzte Objekte sein (wenn sie mindestens ein Attribut haben, welches nicht elementar ist).

• Objekte haben Methoden

  Die Funktionen zur Realisierung der Manipulationen der Attribute und / oder sonstiger Aktionsfolgen, die beim Empfang einer Botschaft im Objekt aktiviert werden, werden als Methoden (methods / Operatoren / operators / Dienste / services) bezeichnet.

  Sie erlauben den Zustand eines Objektes abzufragen, zu verändern und allgemein mit ihm zu kommunizieren.

• Objekte haben einen Zustand

  Objekte haben, über einen beliebigen Zeitraum betrachtet, unterschiedliche Zustände. Zu jedem Zeitpunkt weiß jedes Objekt, in welchem Zustand es sich gerade befindet. Der Zustand eines Objektes muß also in irgendeiner Weise im Objekt gehalten werden (Zustands-Attribute). Hier z.B. die Zustände eines Fahrscheinautomaten:

  Z1 : bereit, wartet auf 1. Geldstück,

  Z2 : wartet auf ein weiteres Geldstück.

  Der Fahrscheinautomat weiß, dass er noch kein Geldstück erhalten hat (Z1) bzw. dass er noch ein weiteres Geldstück empfangen muß (Z2).

• Objekte empfangen Botschaften von anderen Objekten

  Objekte leben nicht in der Isolation, d.h. sie haben ein Umfeld, von dem sie u.U. angesprochen werden. Objekte müssen (sollten) sinnvoller Weise in der Lage sein, Anstöße aus dem Umfeld aufzunehmen, z.B. Eingabemöglichkeiten bei einem Fahrscheinautomaten:

  X1 : Eingabe eines 1-DM-Stücks,

  X2 : Eingabe eines 2-DM-Stücks.

  Der Fahrscheinautomat bietet nach außen die Möglichkeiten an, ein 1-DM-Stück (X1) oder ein 2-DM-Stück (X2) einzugeben.

• Objekte sind (re-)aktionsfähig

  Wenn ein Objekt eine Botschaft empfängt, dann wird es abhängig von seiner ihm eigenen Verhaltensweise, also abgestimmt mit seinem jeweiligen Zustand, auf diese Botschaft reagieren:
  f(Z) : X x Z --> Z.
  Der Fahrscheinautomat reagiert abhängig von seinem aktuellen Zustand (Z) und des eingegebenen Geldstücks (X) unterschiedlich, d.h. der Zustand des Fahrscheinautomaten ändert sich nach bestimmten Regeln (Algorithmen).

• Objekte senden Botschaften an andere Objekte

  Objekte, die ihren Zustand verändern bzw. auf empfangene Botschaften reagieren, senden ggf. wiederum Botschaften an andere Objekte, z.B. die Ausgabemöglichkeiten des Fahrscheinautomaten.

  Y1 : 1 Fahrkarte,

  Y2 : 1 Fahrkarte + Rückgeld.

  Der Fahrscheinautomat bestimmt nach seiner Zustandsänderung das Verhalten nach außen, indem er entweder 1 Fahrkarte (Y1) oder 1 Fahrkarte + Rückgeld (Y2) ausgibt.

• Objekte sind konkrete Ausprägungen einer Art"

  Dieser eine Fahrscheinautomat ist nur einer von vielen der gleichen Bauart, des gleichen Modells, des gleichen Typs. Dieser Fahrscheinautomat unterscheidet sich von seinen Brüdern durch seine eigene Identität, z.B. der Serien-Nr., seinen Standort und seinen aktuellen Zustand.

  Bei Vernachlässigung dieser drei Aspekte ist er gleich, d.h. sogar identisch mit seinen Brüdern.

• Objekte sind abstrakt beschreibbar

• Alle verbrüderten Fahrscheinautomaten haben die gleichen Eigenschaften und sind zu den selben (Re-) Aktionen fähig. Diese Eigenschaften und (Re-) Aktionen können losgelöst von einem konkreten Fahrscheinautomaten abstrakt, d.h. im Sinne einer Typdefinition für alle Objekte dieser Art, beschrieben werden.

• Objekte haben eine Identität

• als Bestandteil des Objektes (z.B. die Seriennummer 100998),
  durch einen direkten Verweis auf das Objekt (z.B. der einzige Fahrscheinautomat) oder durch einen Selektivpfad für das Objekt (z.B. Berlin/Hauptbahnhof/Fahrscheinautomat/3)

• Objekte haben eine Lebensdauer

• Objekte, die nur zeitlich begrenzt existieren, also nicht die Laufzeit eines Anwendungsprozesses überleben, werden als temporäre, oder auch transiente, Objekte bezeichnet.

  Objekte, die die Laufzeit eines Anwendungsprozesses überleben, und somit in einem beliebig zeitlich nachfolgendem Prozeß des Anwendungssystems noch vorhanden sind, werden als persistente Objekte bezeichnet.

  In der Regel werden diese Objekte dann in Datenbanken oder in Dateien abgelegt und gespeichert.

Nachrichten

Als Nachricht (message / Botschaft) wird der Anstoß zur Ausführung einer öffentlichen Methode bei Interaktion zweier Objekte bezeichnet.

Eine Nachricht enthä einen Namen, die ihr Ziel identifiziert und, wenn erforderlich, Parameter. Sie ist vergleichbar mit einem konventionellen Funktionsaufruf.

Nachrichten zwischen Objekten

Klassen

Die abstrakte, d.h. objektunabhängige Beschreibung der Eigenschaften, Strukturen und Verhaltensweisen gleichartiger Objekte erfolgt in Klassen (classes / Objekttypen / object types).

Die Klasse ist eine Schablone für Objekte. Ein Objekt wird durch Instanzbildung einer Klasse erzeugt.

Beispiele für Klassen

Klassen werden definiert durch Methoden und Attribute. Attribute sind ihrerseits nur durch Methodenaufrufe manipulierbar und die Methoden binden letztendlich die Algorithmen an die Attribute.

Auf diese Art und Weise wird die Unkenntnis des Benutzers von der Implementierung der Methoden, der Struktur dieser Attribute und der Speicherrepräsentation der Attribute erreicht (informationhiding, Objekte als black-box).

Assoziation

Assoziation ist eine bidirektionale Beziehung zwischen Objekten. Die Darstellung erfolgt analog zur Entity Relationship Modellierung. Die Kardinalität definiert die Anzahl der Beziehungen.

Objekte können nur dann miteinander kommunizieren, wenn eine Assoziation zwischen ihnen definiert ist.

Beispiel für Assoziationen

Aggregation

Die Aggregation ist eine stärkere Form der Assoziation. Es ist eine Ganzes-Teil-Beziehung (part of). Die Kardinalität gibt die jeweilige Anzahl der Teile an.

Beispiel für eine Aggregation

Vererbung (inheritance)

Schon die Bezeichnungen Fahrschein-Automat und Blumen-Automat erinnern daran, dass diese Klassen gemeinsame Eigenschaften haben, die vergleichbar und teilweise sogar identisch sind, wie z.B.

• Das Attribut Zustand kann die Werte (eingeschaltet, bereit, wartet auf 1. Geldstück), (wartet auf weiteres Geldstück) und (ausgeschaltet) annehmen.
• Die Methode anschalten ändert den Zustand (ausgeschaltet) nach (eingeschaltet, bereit, wartet auf 1. Geldstück).
• Die Methode einwerfen1DMStück ändert den Zustand (eingeschaltet, bereit, wartet auf 1. Geldstück) nach (wartet auf weiteres Geldstück) bzw. den Zustand (wartet auf weiteres Geldstück) nach der Ausgabe des gewünschten Produktes und ggf. des Rückgeldes nach (eingeschaltet, bereit, wartet auf 1. Geldstück).

Es liegt deswegen nahe, die Definition eines Objekttypen als Generalisierung, d.h. Verallgemeinerung, eines / mehrer Objekttypen,
z.B. FahrscheinAutomat, BlumenAutomat --> Automat, beziehungsweise die Definition eines / mehrer Objekttypen als Spezialisierung eines Objekttypen, z.B. Automat --> FahrscheinAutomat, BlumenAutomat, abzuleiten.

Die Generalisierung (generalization) wird auch als Abstraktion (abstraction), die Spezialisierung (specialization) auch als Konkretisierung bezeichnet.

Die Generalisierung bzw. Spezialisierung führt zu einer hierarchischen Anordnung der Klassen, ggf. über mehrer Stufen, zur Klassenhierarchie oder Vererbungshierarchie.

Klassenhierarchie

Die in der Hierarchie höher stehende Klasse ist der Supertyp (supertype) bzw. die Oberklasse (superclass), die tiefer stehende Klasse ist der Subtyp (subtype) bzw. die Unterklasse (subclass).

In der Klassenhierarchie werden die Methoden und die Instanzvariablen der (Super-) Typen (also z.B. Automat) an die Subtypen (z.B. FahrscheinAutomat, BlumenAutomat) vererbt, d.h. sie stehen dort zur Verfügung.

In den Subtypen kann bei Bedarf eine beliebige Erweiterung der Anzahl von Methoden und / oder Attributen erfolgen. Bei Bedarf können auch die Methodeninhalte ersetzt oder modifiziert werden (Methoden-Redefinition).

Wenn eine Klasse die Eigenschaften einer Klasse erbt, dann liegt einfache Vererbung (single inheritance) vor.

Erbt eine Klasse von mehreren Klassen, dann liegt Mehrfachvererbung (multiple inheritance) oder wiederholte Vererbung vor.

Vererbung

• abstrakte Klassen / konkrete Klassen

  Klassen, für die es keine realen Ausprägungen (sprich Objekte) gibt, werden als abstrakte Klassen (abstract class) bezeichnet.

  Fahrzeuge" ist eine solche abstrakte Klasse; in der realen Welt wird es immer ein Objekt der Klasse Flugzeug, Straßenbahn, Segelboot o.ä. sein.

  Konkrete Klassen (concrete class) haben im Gegensatz zu abstrakten Klassen reale Ausprägungen, d.h. Objekte. Da gibt es z.B. in Berlin einen PkW mit der Nummer B-AD 2051.

• virtuelle Methode

  Abstrakte Klassen erlauben, Methoden zu deklarieren, aber deren Implementierung noch offen zu lassen, sogenannte virtuelle Methoden ( virtual method).

  Damit ist die Möglichkeit gegeben, Platzhalter (als Erinnerung) für Methoden-implementierungen bereits auf einer hohen Ebene der Vererbungshierarchie einzuführen, obwohl die eigentliche Implementierung erst auf den tieferen Ebenen der Vererbungshierarchie erfolgt.

  Z.B. kann eine Klasse Fahrzeuge bereits die Methoden anhalten und abfahren anbieten, aber die vollständige Implementierung erst bei den konkreten Klassen wie z.B. PkW erfolgen.

  Bei einer nicht-strengen Vererbung können die geerbten Methoden in den Subtypen überschrieben werden; bei strenger Vererbung dagegen nicht. D.h. dort sind keine Methoden-Redefinitionen erlaubt.

• Overloading

  Das Overloading, auch funktionaler Polymorphismus /Heilmann/ genannt, erlaubt, dass Methoden, die gleiche Aufgaben an verschiedenen Typen von Objekten ausführen, den gleichen Methodennamen haben können.

Polymorphismus und Binden

Polymorphismus (polymorphism) ist die Fähigkeit einer Objektvariablen zur Laufzeit Objekte des statischen Typs der Variablen (static type) oder Objekte von Subtypen des statischen Typs der Variablen (dynamic type) beinhalten zu können.

Polymorphismus

Polymorphismus und Bindung

Zur Laufzeit des Systems kann also in einer Objektvariablen des Typs Konto ein Objekt des Typs Sparbuch gespeichert werden. Wird dann die Methode Buchen aufgerufen, so wird, wenn kein dynamisches Binden unterstützt wird, die Methode Buchen des Typs Konto, aber nicht des Typs Sparbuch, ausgeführt.

Dynamisches Binden (dynamic binding) ist der Mechanismus, der dafür sorgt, dass die Zuordnung der konkret auszuführenden Methode beim Methodenaufruf abhängig vom dynamischen Typ der Objektvariablen erfolgt.

Wie vorher bereits beim Polymorphismus beschrieben, kann zur Laufzeit des Systems in einer Objektvariablen des Typs Konto ein Objekt des Typs Sparbuch gespeichert werden. Wird dann auf der Objektvariablen die Methode Buchen aufgerufen, so wird beim dynamischen Binden die Methode Buchen des Typs Sparbuch ausgeführt und nicht die des Typs Konto.

Terminologie und Notation

	Booch	Coad Yourdon	Jacobson	Rumbaugh
Klasse	class	class (abstract)	class	class
Attribut	field	attribute	attribute	attribute
Methode	operation	service	operation	operation
Objekt	object	class & object	object	object
Subsystem	class category	subject	subsystem	subsystem, module
Vererbung	inheritance	gen-spec-struct	inherits	generalization
Aggregation	has	whole-part-struct	acquaintance association	aggregation
Assoziation	association	instance connection	acquaintance association	association (link)
Nachricht	message	message connection	communication association	data flow (event)

Terminologie und Notation

Verschiedene Sichten auf das Modell

Zur vollständigen Darstellung eines Systems reicht die Beschreibung der Objekte und ihrer Beziehungen nicht aus. Daher werden weitere Darstellungen, teilweise aus der Welt der strukturierten Analyse, zur Modellierung verwendet, so dass

• statische,
• dynamische und
• funktionale

Aspekte dargestellt werden können.

Die statischen Aspekte werden in Form von Klassen- bzw. Objektdiagrammen dargestellt. Aus ihnen wird ersichtlich, welche Objekte es gibt, welche Beziehung sie haben, welche Attribute und Methoden sie enthalten.

Die Dynamik wird durch Ereignisdiagramme (event trace diagram und event flow diagram) sowie durch Zustandsübergangsdiagramme (state transition diagram) deutlich gemacht.

• Event flow diagrams zeigen, welche Nachrichten zwischen welchen Objekten ausgetauscht werden.
• Event trace diagrams zeigen, welche Nachrichten in welcher Abfolgen zwischen Objekten für ein bestimmtes Szenario ausgetauscht werden.
• State transition diagrams stellen die inneren Zustände eines Objekts und die Ursachen (z.B. events) für die Zustandswechsel dar.

Der funktionale Aspekt wird durch Datenflußdiagramme (data flow diagram) berücksichtigt. Hier wird dargestellt, welchen Verarbeitungen Daten unterzogen werden und in welchen Schritten die Verarbeitung abläuft.

Nicht für alle Modelle bzw. nicht für alle Teile eines Modells müssen vollständig alle Betrachtungsweisen vorliegen. Wichtig ist allein, dass das System für einen Außenstehenden verständlich ist.

Beispiel für ein Objektmodell

Event Flow Diagram

Event Trace Diagram

State Transition Diagram

Die Elemente des Zustandsübergangsdiagramms sind:

• Zustände, auch mit den Sonderformen Start- und Endezustand.
  Zustände können auch hierarchisch dargestellt werden, d.h. ein Zustand enthä ein weiteres Zustandsdiagramm. Ein Zustandsdiagramm kann auch ein Gedächtni" enthalten, so dass bei einem erneuten Eintritt in dieses Diagramm wieder der letzte Subzustand eintritt.
• Eintreffende Ereignisse können zu einem Zustandswechsel führen.
• Aktionen werden durchgeführt. Aktionen innerhalb eines Zustandes können endlos oder zeitlich begrenzt ablaufen.
• Zustandswechsel bezeichnet man den Übergang von einem Zustand in einen anderen. Auslöser kann ein externes Ereignis oder die Beendigung einer Aktion innerhalb des Zustands sein. Zustandswechsel können auch an Bedingungen geknüpft sein oder Ereignisse auslösen.

OOA: Objektorientierte Analyse

Der Prozeß der Systementwicklung

Nachdem die Konzepte und die Begriffe der Objektorientierung erklärt wurden, gilt es nun im Prozeß der Systementwicklung das vermittelte Basiswissen anzuwenden und in Anwendungssysteme umzusetzen.

Im Prozeß der Systementwicklung soll aus einem Anforderungsmodell letztendlich ein reales System entstehen. Da die OO-Vorgehensweise immer versucht, ein Abbild der Realität nachzubauen, wird versucht, die Funktionalität des zu erstellenden Systems (von Anfang an) als das Ergebnis des Zusammenspiels bzw. der Zusammenarbeit von Objekten zu sehen, zu verstehen, zu designen und zu implementieren.

Da die traditionellen Methoden ausschließlich daten- oder funktionsorientiert sind, kann von dort keine Unterstützung für die Objektorientierung erwartet werden. Nur geeignete Methoden und Techniken, die die Konzepte der OO-Welt optimal unterstützen bzw. umsetzen helfen, werden benötigt und können genutzt werden.

Um keine Strukturbrüche zwischen Analyse, Design und Implementierung zu erleben bzw. eine hohe Durchgängigkeit der Arbeitsergebnisse dieser Phasen zu erreichen, müssen die Methoden und Techniken beim Beginn einer Phase auf den Ergebnissen der Vorphase aufsetzen.

So kann das Ziel, ein einheitliches Entwicklungsparadigma im gesamten Software-Lifecycle anzuwenden, erreichbar gemacht werden, und damit letztendlich auch eine hohe Stabilität der Ergebnisse im Prozeß der Systementwicklung erreicht werden [Heilmann].

Im Rahmen des Systementwicklungsprozesses ist dabei die 2-Dimensionalität des Modells zu beachten [Booch]:

• die statische und dynamische Sicht (als 1. Dimension) und
• die semantische und Implementierungssicht (als 2. Dimension).

Bei der semantischen Sicht stehen die Aspekte Klassenstruktur und Objektstruktur im Vordergrund.

Die Implementierungssicht bestimmt dagegen die Modul- und Prozeßarchitektur.

Strukturierung des Systems (Problemanalyse)

Die Phase der Problemanalyse ist hier bewußt aus der Phase der Analyse herausgezogen worden, um deutlich zu machen, dass bei komplexen Systemen zunächst eine Strukturierung des Systems in überschaubaren Einheiten erfolgen muß, um einen angemessenen Ausgangspunkt, nämlich ein Anforderungsmodell, für die nachfolgenden Phasen zu haben.

Ziel dieser Phase ist es, ein Anforderungsmodell zu erstellen, welches das System in überschauberen Einheiten beschreibt.

Bei der Problemanalyse sind folgende Fragen zu beantworten :

• Was muß das System leisten?
• Welche Anforderungen hat der Anwender?
• Was für ein System ist zu bauen?

Bei der Beschreibung sind folgende Punkte zu beachten :

• was! nicht wie?
  Zum Verständnis des Systems ist es zunächst wichtig festzustellen, was passiert und nicht wie etwas passiert. Spezielle Algorithmen und Implementierungsdetails können völlig außer Acht gelassen werden.
• wertfreie Beschreibung
  Die Beschreibung sollte möglichst wertfrei als eine natürliche Sicht auf die Problemwelt erstellt werden. Bewertungen führen u.U. zu frühzeitigen Schlagseiten bei der Betrachtung der Problemwelt.
• neutrale Beschreibung
  Die Beschreibung sollte möglichst neutral, d.h. unabhängig von einer Entwurfsmethodik und/oder einem speziellen Tool erfolgen, da sonst ein falsches Weltbild, bedingt durch Methodik und/oder Tool, entstehen kann.
  Es wird empfohlen, Pinnwände, Papier, Karten und ähnliche Dinge zu benutzen.

Die Problemanalyse vollzieht sich in folgenden, teilweise parallelen, Schritten:

• Sammlung der essentiellen Anforderungen an das System.
• Umweltabgrenzung durch Zuordnung von Anforderungen der Umwelt an das System, et vice versa .
• Verfeinerung des Systems bzw. der Teilsysteme unter Berücksichtigung von (betriebswirtschaftlichen) Einheiten und Abläufen zur verbalen Beschreibung der Teilsysteme.
• Sammlung von Bezeichnern, die sinnvoll gebündelte Informationsmengen der Problemwelt widerspiegeln.
• Das Ende der Verfeinerung der Problemwelt ist bei überschaubaren Teilsystemen mit Informationseinheiten der Sachbearbeiter- / Problemwelt erreicht.
• Die verbale, mit Graphiken ergänzte Dokumentation, beschreibt das Anforderungsmodell. Dazu gehören z.B.

• Szenarienbeschreibungen,
• ein Glossar/Dictionary,
• Objektdiagramme,
• Zustandsdiagramme (mit Zuständen und Ereignissen) und
• Funktionsdiagramme (mit Ereignissen und Aktivitäten).

Objektorientierte Analyse (OOA)

Bei der objektorientierten Analyse sind die Anworten auf die Fragen der Problemanalyse weiter zu verfeinern. Ein tiefergehendes Fachverständnis ist aufzubauen, um die Objekte des Anwendungsbereiches und deren Beziehungen zueinander aufzudecken.

Alle Aussagen zum Problembereich sind zu sammeln und zu ordnen, wobei die DV-technische Umsetzbarkeit in keinem Falle zu beachten ist. Das Ergebnis sollte allgemein und nicht ausschließlich auf den Problembereich zugeschnitten sein
/Heilmann/, um die Wiederverwendbarkeit, als einen entscheidenden Aspekt der Objektorientierung, von Anfang an zu berücksichtigen.

Ziel ist die Beschreibung des Systems mit Objekten (incl. Methoden und Attributen) durch Verfeinerung der logischen Sicht auf die Teilsysteme der Systemstruktur, damit aus dem Anforderungsmodell das Funktionsmodell entwickelt werden kann. In GRAPES wird das Funktionsmodell in ein Fach-Grobmodell (Ergebnis der fachlichen Aufgabendefinition der Phase A20) und ein Fach-Feinmodell (Ergebnis der fachlichen Lösungsdefinition) getrennt.

Bei der Objekt- und Methodenfahndung (Schimanksi-OO) sind folgende Punkte zu beachten :

• Substantive in der Beschreibung sind Kandidaten für Objekte.
• Zur leichteren Objektidentifikation sind Aufgaben von Objekten (is_responsible_for) durch schlagwortartige Kurzbeschreibungen festzulegen.
• Zur weiteren Objektspezifikation, d.h. zur Festlegung von Methoden und Attributen, sind Verben als Kandidaten für Methoden anzusehen.
• Redundanzen sind so früh wie möglich zu eleminieren.
• In Zweifelsfällen und bei Unklarheiten ist immer ein Abgleich mit der Sachbearbeiter-/Problemwelt durchzuführen, z.B. durch Szenarienbeschreibungen.
• Walk-Throughs sind durchzuführen. Sie dienen der Findung zusätzlicher Objekte, Methoden und Attribute. Dazu empfiehlt es sich, auf der Ebene von Vorgängen aufzusetzen, die dann schrittweise in Teilvorgängen, Tätigkeiten und Bearbeitungsschritte verfeinert werden. Dabei werden dann die Geschäftsvorfälle sowohl im Dialogverhalten als auch als Interaktion zwischen Objekten durchgespielt.
• Es ist auf eine sachlich korrekte Namensgebung (im Singular) für Objekte, Methoden und Attribute zu achten, z.B. durch ein Glossar.
• Die Objektstrukturen (statische Sicht) und -beziehungen (dynamische Sicht) aus rein logischer Sicht sind zu entdecken.

bei der statischen Sicht sind folgende Aspekte zu beachten und festzuhalten:

• strukturelle Beziehungen
  Die Analyse der strukturellen Beziehungen läßt erkennen, aus welchen Teilen ein Objekt besteht (is_composed_of) bzw. in welchem Objekt es Bestandteil ist (is_part_of).
• Verfeinerung von Klassen
  Die Eigenschaften der Klassen und ihre Wertebereiche, Datenabhängigkeiten (has_knowledge_of), funktionale Abhängigkeiten (depends_on), Integritätsbedingungen und Zusicherungen, durch Vor- und Nachbedingungen für Aktivitäten bzw. Ereignisse, sind zu beschreiben.
• Bei der dynamischen Sicht sind Aspekte, wie
  • Kommunikationsbeziehungen und
  • Ablaufstrukturen zu betrachten und festzuhalten.
• Die Fachwelt steht im Vordergrund. Deswegen wird auf der Ebene von Aktivitäten und Ereignissen und nicht auf Methodenebene analysiert, was in der Problemwelt für Kommunikationsbeziehungen zwischen Objekten existieren und wie deren Ablaufstrukturen aussehen.
• Die Beschreibung der Objekte mit ihren statischen und dynamischen Beziehungen erfolgt in unterschiedlichen Diagrammen.

Beispiel einer OOA nach Rumbaugh

OOD: Objektorientiertes Design

Beim objektorientierten Design sind folgende Fragen zu beantworten:

• Was kann das entstandene System leisten?
• Wie sehen die Lösungsmechanismen aus?
• Wie muß das System gebaut werden?
• Welche Aspekte sind aufgrund der Systembasis hinsichtlich
  • Anbindung der Benutzeroberfläche,
  • Anbindung der Datenbank,
  • Anbindung der Druckkomponente, etc. zu beachten?

Durch die Beantwortung dieser Fragen wird das Ziel, nämlich das Design des zu realisierenden Modells, erreicht und somit aus dem Funktionsmodell das Realisierungsmodell abgeleitet.

Die DV-technische Umsetzbarkeit der OOA-Ergebnisse wird von nun an mitbeachtet und fließt in das Realisierungsmodell mit ein.

Der Grundgedanke beim Design ist die Abbildung der Fachwelt (Ereignisse lösen Aktivitäten aus) auf die DV-Welt (Ereignisse lösen Botschaften aus, die Methoden auf Objekten anstoßen).

Zusätzlich werden die Abstraktion, die Generalisierung und die Aggregation als Umsetzungsprinzipien für die Festlegung der Objekttypen und der Vererbungshierarchie genutzt.

Durch Abstraktion werden aus Objekten Klassen gewonnen, wobei die statische Abstraktion auf der Ebene der Attribute und deren Strukturen sowie den Methoden erfolgt.

Generalisierung (is_like_a) bedeutet die Zusammenfassung gemeinsamer Eigenschaften in Supertypen unter Beachtung

• gleicher Attribute und
• (partieller) Gleichheit von Methoden.

Durch Generalisierung werden also aus Objekttypen die Supertypen abgeleitet.

Durch Spezialisierung (is_kind_of) werden aus Objekttypen die Subtypen abgeleitet.

Durch Analogien (is_analogous_of) werden weitere Subtypen von einem (gemeinsamen) Supertypen abgeleitet.

Ein Entwurfskriterium von Objekttypen muß auch der Aspekt der Wiederverwendbarkeit von Objekttypen sein. Je allgemeiner Objekttypen definiert werden, desto eher sind sie in einem anderen Kontext wiederverwendbar.

Die Klassifizierung bzw. die Typisierung der Objekte durch Abstraktion, Generalisierung und Aggregation sollte zu einem einfachen und übersichtlichen Modell der Objekttypen führen (Architekturplan).

Dieser implementierungsunabhängige Architekturplan beschreibt, wie die OOA-Ergebnisse realisiert werden können. Im Zentrum des Architekturplanes steht das Vererbunskonzept und damit die (maximale) Wiederverwendung bestehender Klassen. Wenn neue Klassen zur Realisierung erforderlich sind, müssen diese nachträglich im Architekturplan aufgenommen werden.

Die relevanten Zustandsgrößen und Wechselwirkungen sind, entsprechend der Komplexität, angemessen zu dokumentieren.

Das Realisierungsmodell sollte folgende Dokumentationen umfassen:

• Objekttypen mit Methoden und Attributen (Objektdiagramm), d.h. Name, Supertyp, funktionale methodenunabhängige Kurzbeschreibung, Attribute, Methoden mit Wirkungen auf Attribute und andere Objekttypen.
• Kompositionsdiagramm mit is_part_of / is_composed_of - Beziehungen; z.B. is_part_of => Aggregation (Wurzel, Stamm, Blätter --> Pflanze) oder is_composed_of => Dekomposition (Pflanze --> Wurzel, Stamm, Blätter)
• Vererbungsdiagramm mit is_kind_of / is_like_a - Beziehungen, z.B. is_kind_of => Spezialisierung (Palme, Birke, Tanne --> Pflanze) oder is_like_a => Generalisierung (Palme --> Birke --> Tanne => Pflanze)
• Kommunikationsdiagramm mit Objekttypen und Methoden zur Darstellung dynamischer Beziehungen zwischen Objekten.

Object Modelling Technique (OMT) nach Rumbaugh

Eine vollständige Systembeschreibung nach der Object Modelling Technique (OMT) von /Rumbaugh u.a/] z.B. umfaßtdrei Modelle:

• das Objektmodell (OM),
• das Dynamikmodell (DM) und
• das Funktionsmodell (FM).

Die Aufteilung eines Systems aus diesen drei Sichten führt zu eigenständigen, aber nicht generell unabhängigen, Modellen. D.h., es gibt in jedem Modell immer Beziehungen zu den beiden anderen Modellen, jedoch immer eindeutig begrenzt und explizit genannt.

Das Objektmodell definiert und beschreibt die:

• Objekte mit den Attributen (Datenstrukturen), auf denen das DM und das FM arbeiten,
• den Methoden, die auf die Ereignisse des DM reagieren und die Funktionen des FM benutzen, und
• den Verbindungen zu anderen Objekten.

Die Darstellung des OM erfolgt in:

• Objektdiagrammen (object diagram) und Klassendiagrammen (class diagram) und
• Vererbungshierarchien.

Struktur eines Klassendiagramms (class diagram)

Beispiel eines Klassendiagramms

Beispiele Instanzendiagramme (instance diagram)

Beispiele einer Vererbungshierarchie (instance hierarchy)

Klassendiagramm mit Assoziationen und Links

Instanzendiagramm mit Assoziationen und Links

Das Dynamikmodell definiert und beschreibt die Kontrollstrukturen für Objekte (mit Ereignissen und Zuständen über die Zeit) und die Entscheidungen, die abhängig von den OM-Datenwerten, FM-Aktionen benutzt, um OM-Datenwerte zu verändern.

Ein Ereignis wird dabei verstanden als ein Signal, welches zu einem bestimmten Zeitpunkt gegeben wird, dass etwas Bestimmtes passiert ist. Die Änderung eines Zustandes erfolgt immer durch ein entsprechendes Ereignis (Transition = Übergang).

Die Darstellung des DM erfolgt im Statusdiagramm (state diagram) mit Zuständen, Ereignissen und Verweisen auf Objekte (OM) und Funktionen (FM).

Statusdiagramm (state diagram)

Das Funktionsmodell definiert und beschreibt die notwendigen Funktionen für Werteveränderungen von Daten mit Abbildungsvorschriften, Bedingungen und Abhängigkeiten, und die Aktionen, die von Methoden (OM) und Aktionen (DM) angestoßen werden müssen, um mit den OM-Daten zu arbeiten.

Die Darstellung erfolgt im Datenflußdiagramm (data flow diagram) mit Werteabhängigkeiten, Umrechnung von Eingabe- in Ausgabewerten und Funktionen.

Prozeßnotation

Datenfluss zwischen Prozessen

Aktionsobjekte, die Daten konsumieren und/oder produzieren

OOP: Objektorientierte Programmierung

Ziel der Phase objektorientierte Implementierung, auch OO-Programmierung im weiteren Sinne (OOP) genannt, ist die Implementierung des Realisierungsmodells als ein reales System.

Es werden die OOD-Ergebnisse auf einer bestimmten Systemsoftwarebasis realisiert, d.h. die in der vorherigen Phase designten Klassen und deren Beziehungen werden in Quellcode umgesetzt. Jetzt erfolgt die Codierung der Objekttypen mit ihren Interfaces und Bodies.

Bei der OOP sind folgende Fragen zu beantworten:

• Wie sieht die Softwarestruktur aufgrund der Systembasis aus?
• Welche Moduln sind aus welchen Klassen zu bilden?
• Welche Subsysteme sind aus welchen Moduln zu bilden?

Wird die klassische Dreiteilung konventioneller Informationssysteme betrachtet, dann erhä man drei Klassen von OO-Implementierungswerkzeugen:

• OO-Benutzerschnittstellen-Werkzeuge,
• OO-Programmierumgebungen und
• OO-Datenbankmanagementsysteme.

Objektorientierte Benutzerschnittstellen-Werkzeuge sollten nicht nur den statischen Aufbau von Benutzerschnittstellen durch Fenster, Menues, Buttons, etc. berücksichtigen, sondern auch dynamische Aspekte wie Vorgänge oder Datenschutz, die letztendlich erst ein koordiniertes und kontrolliertes Zusammenspiel der Benutzer mit dem System erlauben.

Objektorientierte Programmierumgebungen sollten mindestens eine OO-Sprache, einen Compiler, einen Editor, einen Binder/Lader, einen Klassenverwalter und Testtools bereitstellen.

Die gängigsten Sprachen stehen heute auf den Betriebssystemen MS-Windows, OS/2 und UNIX zur Verfügung.

Objektorientierte Datenbankmanagementsysteme sind in Arbeit, als Prototypen am Markt verfügbar und erreichen immer mehr den Produktstatus.

inkrementelle Softwareentwicklung?

Systeme werden in Form von Zusammenarbeit von Objekten realisiert. Es kann unterstellt werden, dass z.B. das Aufnehmen eines neuen Objekttypen in die Anwendung recht unproblematisch erfolgen kann. Eine inkrementelle Softwareentwicklung wird dadurch umso eher möglich.

iterative Vorgehensweise?

Wenn die inkrementelle Softwareentwicklung durch OO unterstützt wird, dann wird auch ein iteratives Vorgehen ermöglicht. Das Ein- und Ausbauen von Objekttypen in die Anwendung zum Test des Designs, der Funktionalität etc. ist wiederholt möglich. Auch partielle Re-Designs der Anwendung werden möglich, denn die Objekttypen an sich behalten ihre Eigenschaften, weil z.B. nur die Koordination des Zusammenspiels der Objekttypen geändert werden muß.

Wiederverwendung von Software?

Softwaretechnische Abbildungen der Realität, sprich Objekttypen, sind in einem anderen Kontext eher wiederverwendbar als Datenstrukturen mit gestreut realisierten Funktionen zur Manipulation dieser Daten.

Objekttypen, im Sinne von Software-ICs, werden in die neue Anwendung gesteckt und ihre Methoden vom neuen Anwendungsumfeld aufgerufen.

Durch die entsprechende Klassenbibliothek wird die Wiederverwendung noch mehr erleichtert.

offene, erweiterbare Systeme?

Objekttypen, im Sinne von Software-ICs, bieten extensiv die Möglichkeit, Systeme leichter erweitern zu können. Damit sind OO-Softwaresysteme generell offen, andere Software-ICs aufzunehmen, um damit zum erforderlichen Zeitpunkt die neuen Eigenschaften des Objekttypen im Kontext der alten Anwendung nutzen zu können.

Erhöhung der Entwicklungsproduktivität?

Die Mehrfachentwicklung kann durch die Wiederverwendung vermieden werden. Insgesamt wird dadurch auch die Wirtschaftlichkeit des Entwicklungsprozesses gesteigert.

Verbesserung der Produktqualität?

Die Wiederverwendung bedeutet den Einsatz bereits ausgetesteter Komponenten. Somit kann von weniger Fehlern beim Einsatz des Softwareproduktes insgesamt ausgegangen werden, wenn die Wiederverwendung umfangreich genutzt wurde.

Reduzierung der Komplexität?

Das Klassenkonzept führt zu überschauberen Codeblöcken in den Objekttypen, da durch die Vererbung eine geringe Komplexität der Klassen erreicht werden kann / sollte.

wartungsfreundlicher?

Die potentiellen Fehlerquellen werden durch die Vererbung zusätzlich reduziert und damit auch letztendlich eine vereinfachte und schnellere Wartung ermöglicht.

geringerer Codeumfang?

Mächtige Systemklassen bzw. Klassenbibliotheken erleichtern bzw. reduzieren die Arbeit.

Weisheit

Es hat keinen Sinn, Sorgen in Alkohol ertränken zu wollen, denn Sorgen sind gute Schwimmer.

Thomas Bramwell Welch
† 1903

Musikerwitz

"Euer Bassist ist ja echt der Wahnsinn!"
"Den hättest mal vor seinem Schlaganfall hören müssen, da war er noch Gitarrist!"