Funktionsorientierte Entwurfstechnik Funktions- versus Objektorientierter Entwurf Funktionaler Entwurf Das System wird aus einer funktionsorientierten Sichtweise heraus entworfen. Das Prinzip der schritt weisen Verfeinerung wird angewendet. Der Systemzustand ist zentralisiert. Beispiele sind Strukturierter Entwurf und SADT (Structured Analysis and Design Technique) Bild: Software-Entwurf Top-Down und funktionsorientiert Vorgehensweise des funktionsorientierten Entwurfes Im Funktionsorientierten Entwurf wird das System in eine Menge interagierender Funktionen zerlegt, die auf einen gemeinsamen Systemzustand zugreifen. Die Details der zu realisierenden Algorithmen werden in den Funktionen verborgen, nicht jedoch der Systemzustand, dies kann u.u. zu unerwünschten Seiteneffekten führen. Funktionsorientierter Entwurf wurde informell bereits mit Beginn des Programmierens praktiziert. Der folgende Algorithmus zeigt einen Funktionsorientierten Entwurf für einen Bankautomaten. Dieser folgt dem Modell der zentralisierten Kontrolle. Das System ist als Endlosschleife modelliert und die Aktionen werden angestoßen, sobald eine Karte eingeführt wird. Funktionen sind durch ihre Parameterlisten erkennbar. 1
Funktionsorientierte Entwurfstechnik Bild: Beispiel Bankautomat Structured Analysis and Design Technique (SADT) Strukturierte Analyse und Entwurfstechnik SADT ist eine Funktionsorientierte Entwurfstechnik, die von Ross und Schoman 1977 entwickelt wurde. SADT ist eine graphisch-verbale Methode, die in der Praxis hauptsächlich eingesetzt wird, um Systemstrukturen funktionsorientiert zu beschreiben. Jede Funktion (hier Activity genannt) führt Transformationen durch, die von bestimmten Mechanismen unterstützt werden oder von Steuerungsvorgängen angestoßen bzw. beeinflusst werden. Beschreibungsmodell Ein zu untersuchendes Gesamtsystem (A0 Activity 0) wird hierarchisch bis hinunter auf konkrete Systemfunktionen ebenenweise aufgegliedert. Jede Ebene muss mindestens drei und darf höchstens sechs Funktionen haben. Jede aufgegliederte Funktion wird in einem in Formblatt (hier Aktigramm genannt) dargestellt. Aus den Indizes für die Funktion kann man ablesen, auf welcher Ebene sie angesiedelt ist, auf welche übergeordnete Funktion sie sich bezieht und an wievielter Stelle sie auf ihrer Ebene steht. Dadurch wird eine baumartige Funktionsstruktur erzeugt. 2
Funktionsorientierte Entwurfstechnik Die folgende Abbildung zeigt ein Beispiel für eine funktionale Zerlegung in SADT. Funktionen sind als Rechtecke dargestellt. Im Rechteck wird die Funktion durch einen Namen semantisch beschrieben. Pfeile repräsentieren Zusammenhänge zwischen den Funktionen. Dies können Objekte oder Daten sein, die von der Funktion benötigt oder von dieser erzeugt werden. Bild: Beispiel SADT-Diagramm und Ebenenmodell Die folgende Abbildung zeigt die notwendigen Beschreibungshilfsmittel für ein SADT-Aktigramm: Die Funktion verarbeitet die Eingänge (I) zu Ausgängen (O) Bedingungen (C) werden durch Pfeile an der Oberkante des Rechtecks als Steuerdaten vorgegeben. Die für die Ausgabe der Funktion benötigten Ressourcen (R) sind Pfeile, die auf die Unterkante des Rechtecks gerichtet sind. Die Pfeile werden ebenfalls mit beschreiben Namen versehen und auch ähnlich den Funktionen indiziert (Nummerierung erfolgt von links nach rechts und von oben nach unten). 3
Objektorientierter Entwurf Objektorientierter (OO-) Entwurf basiert auf der Idee des information hiding. Im Gegensatz zum funktionalen Ansatz wird ein System als Menge interagierender Objekte mit privatem Zustand betrachtet und nicht als Menge von Funktionen mit globalem Zustand. Wesentliche Eigenschaften eines objektorientierten Entwurfs: Das System wird als eine Sammlung von Objekten angesehen. Der Systemzustand ist dezentralisiert, und jedes Objekt verwaltet seine eigenen Zustandsinformationen. Objekte bestehen zum einen aus einem Satz von Attributen, die den Objektzustand bestimmen, sowie aus Methoden, die auf den Attributen operieren. Objekte sind Instanzen von Objektklassen, in denen die Attribute und Methoden definiert wurden. Die Klassen können von einer oder mehreren Oberklassen abgeleitet werden. Die abgeleitete Klasse erbt somit die Eigenschaften ihrer Oberklassen, so dass gemeinsame Eigenschaften nur einmal definiert werden müssen. Objekte kommunizieren über das Austauschen von Nachrichten. In der Praxis wird dies dadurch realisiert, dass ein Objekt die Methode eines anderen Objektes aufruft. Beim Objektorientierten Ansatz fungieren bereits existierende Objekte als Rahmenwerk auf dem der Entwurf entwickelt wird. Bild: Software-Entwurf objektorientiert Des weiteren gilt: Objekte sind Abstraktionen von Dingen in der realen Welt oder im Rechnersystem, die ihren eigenen inneren Zustand verwalten. 4
Objekte sind unabhängig voneinander und lassen sich daher leicht ändern. Die Funktionalität des Systems wird durch Operationen oder Dienste beschrieben, die die Objekte anbieten. Es gibt keine gemeinsamen Datenbereiche mehrerer Objekte. Objekte kommunizieren, indem sie Dienste anderer Objekte aufrufen. Dies reduziert die Kopplung des Gesamtsystems. Objekte können verteilt sein und sequentiell oder parallel ausgeführt werden. Objekte sind dazu geeignet, wieder verwendet zu werden, da sie Zustand und Operationen unabhängig vom Rest eines Systems kapseln. Entwürfe können daher auf existierenden Objekte aufbauen, was die Entwurfs-, Implementierungs- und Validierungskosten senkt. Objektorientierte Analyse, Objektorientierter Entwurf und Objektorientiertes Programmieren sind Bestandteile der Objektorientierten Entwicklung, bei der während des ganzen Entwicklungsprozesses OO-Methoden eingesetzt werden: Objektorientierte Analyse: bemüht sich um ein OO-Modell des zu lösenden Problems. Die dabei identifizierten Objekte können direkt auf Systemobjekte abgebildet werden, aber müssen nicht. Objektorientierter Entwurf: beschäftigt sich mit der Entwicklung eines OO-Modells des zu entwickelnden Softwaresystems. Dieses kann, muss aber nicht auf den während der Analyse gefundenen Objekten basieren. Objektorientierte Programmierung: befasst sich mit der Realisierung eines Softwareentwurfs. Es gibt Objektorientierte Programmiersprachen, die die OO-Programmierung erleichtern sollen (etwa indem sie die direkte Implementierung von Objekten, Klassen und Vererbung vorsehen). OOProgrammierung ist aber grundsätzlich in fast jeder (imperativen) Programmiersprache möglich. Objektorientierte Entwurfsmethoden Diverse objektorientierte Entwurfsmethoden wurden vorgeschlagen (Coad & Yourdon 1990, Rumbaugh et al. 1991, Jacobson et al. 1993, Booch 1994,... ), die sich alle mehr oder weniger ähneln. Die meisten mfassen unter anderem: Identifizierung der Objekte im System mit ihren Attributen und Methoden, Organisation der Objekte in eine Aggregationshierarchie, die wiedergibt, welche Objekte Teil anderer Objekte sind und welche Vererbungsbeziehungen zwischen ihnen bestehen, Aufstellen dynamischer Verwendungsmodelle, die angeben, welche Dienste welcher Objekte von anderen Objekten benutzt werden und wie, Spezifikation von Objektschnittstellen. 5
Bild: Entwicklung der Entwurfsmethoden In der letzten Zeit haben sich die Proponenten einiger verschiedener Entwurfsmethoden zusammengetan (Booch, Rumbaugh, Jacobson) und ihre Methoden in einen Topf geworfen. Das Resultat die Unified Modeling Language oder UML hat einige Chancen, als Industriestandard akzeptiert zu werden. UML ist recht umfangreich es ist die Summe aus drei nicht völlig überlappenden Entwurfsmethoden, die als Teilmengen in UML integriert wurden. Objekte, Klassen und Vererbung Die Wörter Objekt und objektorientiert sind heutzutage Modewörter, die auf alle möglichen Programme, Systeme, Methoden usw. angewendet werden. Alles, was nicht gerade rein funktional ist, wird (von der Marketingabteilung) als objektorientiert bezeichnet. Für unsere Zwecke soll gelten: Objekt: hat Zustand und Methoden, die auf dem Zustand operieren. Zustand: wird als Menge von Objektattributen repräsentiert. Methoden: stellen anderen Objekten Dienste zur Verfügung, die das Objekt erbringen kann. Klassen: sind Schablonen für die Erzeugung gleichartiger oder ähnlicher Objekte, die Deklarationen der Attribute und Methoden für Objekte der betreffenden Klasse enthalten. Vorgehensweise zur Objektidentifikation Das Hauptproblem beim OO-Entwurf besteht darin, die Objekte, Attribute und Operationen zu identifizieren, aus denen das System bestehen soll. Hier sind Können und Erfahrung der Designer entscheidend. Verschiedene Vorschläge wurden gemacht: Man analysiert eine natürlichsprachige Beschreibung des Systems. Objekte und Attribute sind Substantive, Operationen sind Verben (Abbott 1983). Man verwendet tatsächliche Dinge im Problembereich (z. B. Flugzeuge), Rollen (Manager), Ereignisse (Anfragen), Interaktionen (Konferenzen), Örter (Büros), Organisationseinheiten (Firmen), etc. (Shlaer& Mellor 1988, Coad & Yourdon 1990, Rumbaugh et al. 1991, etc.). 6
Man verwendet einen Ansatz, in dem der Designer erst das Gesamtverhalten des Systems versteht. Teilaspekte des Verhaltens werden unterschiedlichen Teilen des Systems zugeordnet, und es wird abgeleitet, wer ein Verhaltensmuster initiiert und wer daran teilnimmt. Teilnehmer mit wesentlichen Rollen werden zu Objekten erklärt (Rubin & Goldberg 1992). Man verwendet einen Ansatz, in dem verschiedene Szenarien der Verwendung des Systems (use cases) identifiziert und analysiert werden. In jedem Szenario werden die beteiligten Objekte, Attribute und Operationen benannt (Jacobson et al. 1993). Diese Ansätze schließen sich nicht gegenseitig aus. Gute Designer verwenden sie ggf. alle, um Objekte zu identifizieren. Sie sind auch nicht eindeutig ; verschiedene Designer können mit derselben Methode durchaus unterschiedliche Objekte finden. 7