OOAD - Objektorientiertes Design

Nach der Analysephase wird das konzeptionelle Modell mithilfe des objektorientierten Designs (OOD) zu einem objektorientierten Modell weiterentwickelt. In OOD werden die technologieunabhängigen Konzepte im Analysemodell auf implementierende Klassen abgebildet, Einschränkungen identifiziert und Schnittstellen entworfen, was zu einem Modell für die Lösungsdomäne führt. Kurz gesagt, es wird eine detaillierte Beschreibung erstellt, in der angegeben wird, wie das System auf konkreten Technologien aufgebaut werden soll

Die Stufen für objektorientiertes Design können identifiziert werden als -

  • Definition des Kontextes des Systems
  • Systemarchitektur entwerfen
  • Identifikation der Objekte im System
  • Konstruktion von Designmodellen
  • Spezifikation von Objektschnittstellen

System-Design

Beim objektorientierten Systemdesign wird der Kontext eines Systems definiert und anschließend die Architektur des Systems entworfen.

  • Context- Der Kontext eines Systems besteht aus einem statischen und einem dynamischen Teil. Der statische Kontext des Systems wird anhand eines einfachen Blockdiagramms des gesamten Systems entworfen, das zu einer Hierarchie von Subsystemen erweitert wird. Das Subsystemmodell wird durch UML-Pakete dargestellt. Der dynamische Kontext beschreibt, wie das System mit seiner Umgebung interagiert. Es wird mit modelliertuse case diagrams.

  • System Architecture- Die Systemarchitektur wird auf der Grundlage des Systemkontexts in Übereinstimmung mit den Prinzipien des Architekturentwurfs sowie dem Domänenwissen entworfen. Typischerweise wird ein System in Schichten aufgeteilt und jede Schicht wird zerlegt, um die Subsysteme zu bilden.

Objektorientierte Zerlegung

Zerlegung bedeutet, ein großes komplexes System nach den Prinzipien von Teilen und Erobern in eine Hierarchie kleinerer Komponenten mit geringerer Komplexität zu unterteilen. Jede Hauptkomponente des Systems wird als Subsystem bezeichnet. Die objektorientierte Zerlegung identifiziert einzelne autonome Objekte in einem System und die Kommunikation zwischen diesen Objekten.

Die Vorteile der Zersetzung sind -

  • Die einzelnen Komponenten sind weniger komplex und daher verständlicher und überschaubarer.

  • Es ermöglicht die Aufteilung von Arbeitskräften mit speziellen Fähigkeiten.

  • Es ermöglicht das Ersetzen oder Ändern von Subsystemen, ohne andere Subsysteme zu beeinflussen.

Parallelität identifizieren

Durch die Parallelität können mehrere Objekte gleichzeitig Ereignisse empfangen und mehr als eine Aktivität gleichzeitig ausgeführt werden. Parallelität wird identifiziert und im dynamischen Modell dargestellt.

Um die Parallelität zu aktivieren, wird jedem gleichzeitigen Element ein separater Steuerungs-Thread zugewiesen. Wenn sich die Parallelität auf Objektebene befindet, werden zwei gleichzeitigen Objekten zwei verschiedene Steuerungs-Threads zugewiesen. Wenn zwei Operationen eines einzelnen Objekts gleichzeitig ausgeführt werden, wird dieses Objekt auf verschiedene Threads aufgeteilt.

Parallelität ist mit den Problemen der Datenintegrität, des Deadlocks und des Hungers verbunden. Daher muss immer dann eine klare Strategie festgelegt werden, wenn Parallelität erforderlich ist. Außerdem muss die Parallelität bereits in der Entwurfsphase selbst identifiziert werden und kann nicht für die Implementierungsphase belassen werden.

Muster identifizieren

Beim Entwerfen von Anwendungen werden einige allgemein akzeptierte Lösungen für einige Problemkategorien übernommen. Dies sind die Muster des Designs. Ein Muster kann als dokumentierter Satz von Bausteinen definiert werden, die bei bestimmten Arten von Anwendungsentwicklungsproblemen verwendet werden können.

Einige häufig verwendete Entwurfsmuster sind -

  • Fassadenmuster
  • Trennmuster der Modellansicht
  • Beobachtermuster
  • Modellansicht-Controller-Muster
  • Abonnementmuster veröffentlichen
  • Proxy-Muster

Ereignisse steuern

Während des Systemdesigns müssen die Ereignisse, die in den Objekten des Systems auftreten können, identifiziert und angemessen behandelt werden.

Ein Ereignis ist eine Spezifikation eines signifikanten Ereignisses, das einen Ort in Zeit und Raum hat.

Es gibt vier Arten von Ereignissen, die modelliert werden können:

  • Signal Event - Ein benanntes Objekt, das von einem Objekt geworfen und von einem anderen Objekt gefangen wird.

  • Call Event - Ein synchrones Ereignis, das den Versand einer Operation darstellt.

  • Time Event - Ein Ereignis, das den Lauf der Zeit darstellt.

  • Change Event - Ein Ereignis, das eine Zustandsänderung darstellt.

Umgang mit Randbedingungen

In der Systementwurfsphase müssen die Initialisierung und die Beendigung des gesamten Systems sowie jedes Subsystems behandelt werden. Die verschiedenen Aspekte, die dokumentiert werden, sind wie folgt:

  • Der Start des Systems, dh der Übergang des Systems vom nicht initialisierten Zustand in den stationären Zustand.

  • Die Beendigung des Systems, dh das Schließen aller laufenden Threads, das Bereinigen von Ressourcen und die zu sendenden Nachrichten.

  • Die Erstkonfiguration des Systems und die Neukonfiguration des Systems bei Bedarf.

  • Vorhersagen von Fehlern oder unerwünschter Beendigung des Systems.

Randbedingungen werden mithilfe von Randanwendungsfällen modelliert.

Objektdesign

Nachdem die Hierarchie der Subsysteme entwickelt wurde, werden die Objekte im System identifiziert und ihre Details entworfen. Hier beschreibt der Designer die Strategie, die während des Systemdesigns gewählt wurde. Der Schwerpunkt verlagert sich von Anwendungsdomänenkonzepten zu Computerkonzepten. Die während der Analyse identifizierten Objekte werden zur Implementierung herausgeätzt, um die Ausführungszeit, den Speicherverbrauch und die Gesamtkosten zu minimieren.

Das Objektdesign umfasst die folgenden Phasen:

  • Objektidentifikation
  • Objektdarstellung, dh Konstruktion von Entwurfsmodellen
  • Klassifizierung von Operationen
  • Algorithmusdesign
  • Gestaltung von Beziehungen
  • Implementierung der Kontrolle für externe Interaktionen
  • Paketklassen und Assoziationen in Module

Objektidentifikation

Der erste Schritt der Objektgestaltung ist die Objektidentifikation. Die in den objektorientierten Analysephasen identifizierten Objekte werden in Klassen gruppiert und so verfeinert, dass sie für die tatsächliche Implementierung geeignet sind.

Die Funktionen dieser Stufe sind -

  • Identifizieren und Verfeinern der Klassen in jedem Subsystem oder Paket

  • Definieren der Verknüpfungen und Zuordnungen zwischen den Klassen

  • Entwerfen der hierarchischen Assoziationen zwischen den Klassen, dh der Generalisierung / Spezialisierung und der Vererbungen

  • Aggregationen entwerfen

Objektdarstellung

Sobald die Klassen identifiziert sind, müssen sie mithilfe von Objektmodellierungstechniken dargestellt werden. In dieser Phase werden im Wesentlichen UML-Diagramme erstellt.

Es gibt zwei Arten von Designmodellen, die hergestellt werden müssen -

  • Static Models - Beschreibung der statischen Struktur eines Systems anhand von Klassendiagrammen und Objektdiagrammen.

  • Dynamic Models - Beschreibung der dynamischen Struktur eines Systems und Darstellung der Interaktion zwischen Klassen mithilfe von Interaktionsdiagrammen und Zustandsdiagrammen.

Klassifizierung von Operationen

In diesem Schritt wird die an Objekten auszuführende Operation definiert, indem die drei in der OOA-Phase entwickelten Modelle kombiniert werden, nämlich Objektmodell, dynamisches Modell und Funktionsmodell. Eine Operation gibt an, was zu tun ist und nicht, wie es zu tun ist.

Die folgenden Aufgaben werden in Bezug auf Operationen ausgeführt:

  • Das Zustandsübergangsdiagramm jedes Objekts im System wird entwickelt.

  • Operationen werden für die von den Objekten empfangenen Ereignisse definiert.

  • Fälle, in denen ein Ereignis andere Ereignisse in demselben oder verschiedenen Objekten auslöst, werden identifiziert.

  • Die Unteroperationen innerhalb der Aktionen werden identifiziert.

  • Die Hauptaktionen werden zu Datenflussdiagrammen erweitert.

Algorithmus-Design

Die Operationen in den Objekten werden unter Verwendung von Algorithmen definiert. Ein Algorithmus ist eine schrittweise Prozedur, die das in einer Operation festgelegte Problem löst. Algorithmen konzentrieren sich darauf, wie es gemacht werden soll.

Es kann mehr als einen Algorithmus geben, der einer bestimmten Operation entspricht. Sobald die alternativen Algorithmen identifiziert sind, wird der optimale Algorithmus für die gegebene Problemdomäne ausgewählt. Die Metriken zur Auswahl des optimalen Algorithmus sind -

  • Computational Complexity - Die Komplexität bestimmt die Effizienz eines Algorithmus in Bezug auf Rechenzeit und Speicherbedarf.

  • Flexibility - Die Flexibilität bestimmt, ob der gewählte Algorithmus ohne Implementierungsverlust in verschiedenen Umgebungen geeignet implementiert werden kann.

  • Understandability - Dies bestimmt, ob der gewählte Algorithmus leicht zu verstehen und zu implementieren ist.

Gestaltung von Beziehungen

Die Strategie zur Implementierung der Beziehungen muss während der Objektentwurfsphase festgelegt werden. Die Hauptbeziehungen, die angesprochen werden, umfassen Assoziationen, Aggregationen und Vererbungen.

Der Designer sollte in Bezug auf Assoziationen Folgendes tun:

  • Identifizieren Sie, ob eine Zuordnung unidirektional oder bidirektional ist.

  • Analysieren Sie den Pfad der Assoziationen und aktualisieren Sie sie gegebenenfalls.

  • Implementieren Sie die Assoziationen als eigenständiges Objekt bei vielen-zu-vielen-Beziehungen. oder als Verknüpfung zu einem anderen Objekt bei Eins-zu-Eins- oder Eins-zu-Viele-Beziehungen.

In Bezug auf Vererbungen sollte der Designer Folgendes tun:

  • Passen Sie die Klassen und ihre Zuordnungen an.

  • Identifizieren Sie abstrakte Klassen.

  • Treffen Sie Vorkehrungen, damit Verhaltensweisen bei Bedarf geteilt werden.

Implementierung der Kontrolle

Der Objektdesigner kann Verfeinerungen in die Strategie des Zustandsdiagrammmodells einbeziehen. Im Systemdesign wird eine grundlegende Strategie zur Realisierung des dynamischen Modells erstellt. Während des Objektdesigns wird diese Strategie für eine angemessene Implementierung passend verschönert.

Die Ansätze zur Implementierung des dynamischen Modells sind -

  • Represent State as a Location within a Program- Dies ist der traditionelle prozedurgesteuerte Ansatz, bei dem der Ort der Steuerung den Programmstatus definiert. Eine endliche Zustandsmaschine kann als Programm implementiert werden. Ein Übergang bildet eine Eingabeanweisung, der Hauptsteuerpfad bildet die Folge von Anweisungen, die Verzweigungen bilden die Bedingungen und die Rückwärtspfade bilden die Schleifen oder Iterationen.

  • State Machine Engine- Dieser Ansatz repräsentiert direkt eine Zustandsmaschine durch eine Zustandsmaschinen-Motorklasse. Diese Klasse führt die Zustandsmaschine über eine Reihe von Übergängen und Aktionen aus, die von der Anwendung bereitgestellt werden.

  • Control as Concurrent Tasks- Bei diesem Ansatz wird ein Objekt als Aufgabe in der Programmiersprache oder im Betriebssystem implementiert. Hier wird ein Ereignis als Inter-Task-Aufruf implementiert. Es bewahrt die inhärente Parallelität realer Objekte.

Verpackungsklassen

In jedem großen Projekt ist eine sorgfältige Aufteilung einer Implementierung in Module oder Pakete wichtig. Während des Objektdesigns werden Klassen und Objekte zu Paketen zusammengefasst, damit mehrere Gruppen gemeinsam an einem Projekt arbeiten können.

Die verschiedenen Aspekte der Verpackung sind -

  • Hiding Internal Information from Outside View - Damit kann eine Klasse als „Black Box“ betrachtet und die Klassenimplementierung geändert werden, ohne dass Clients der Klasse Code ändern müssen.

  • Coherence of Elements - Ein Element wie eine Klasse, eine Operation oder ein Modul ist kohärent, wenn es nach einem einheitlichen Plan organisiert ist und alle seine Teile eng miteinander verbunden sind, sodass sie einem gemeinsamen Ziel dienen.

  • Construction of Physical Modules - Die folgenden Richtlinien helfen beim Aufbau physischer Module -

    • Klassen in einem Modul sollten ähnliche Dinge oder Komponenten in demselben zusammengesetzten Objekt darstellen.

    • Eng verbundene Klassen sollten sich im selben Modul befinden.

    • Nicht verbundene oder schwach verbundene Klassen sollten in separaten Modulen platziert werden.

    • Module sollten eine gute Kohäsion aufweisen, dh eine hohe Zusammenarbeit zwischen ihren Komponenten.

    • Ein Modul sollte eine geringe Kopplung mit anderen Modulen aufweisen, dh die Interaktion oder Interdependenz zwischen Modulen sollte minimal sein.

Designoptimierung

Das Analysemodell erfasst die logischen Informationen über das System, während das Entwurfsmodell Details hinzufügt, um einen effizienten Informationszugriff zu unterstützen. Bevor ein Design implementiert wird, sollte es optimiert werden, um die Implementierung effizienter zu gestalten. Ziel der Optimierung ist es, die Kosten in Bezug auf Zeit, Raum und andere Messgrößen zu minimieren.

Die Designoptimierung sollte jedoch nicht übertrieben sein, da die einfache Implementierung, Wartbarkeit und Erweiterbarkeit ebenfalls wichtige Anliegen sind. Es zeigt sich oft, dass ein perfekt optimiertes Design effizienter, aber weniger lesbar und wiederverwendbar ist. Der Designer muss also ein Gleichgewicht zwischen beiden finden.

Die verschiedenen Dinge, die für die Designoptimierung getan werden können, sind -

  • Fügen Sie redundante Zuordnungen hinzu
  • Nicht verwendbare Assoziationen weglassen
  • Optimierung von Algorithmen
  • Speichern Sie abgeleitete Attribute, um eine Neuberechnung komplexer Ausdrücke zu vermeiden

Hinzufügen redundanter Assoziationen

Während der Entwurfsoptimierung wird geprüft, ob das Ableiten neuer Zuordnungen die Zugriffskosten senken kann. Obwohl diese redundanten Zuordnungen möglicherweise keine Informationen hinzufügen, können sie die Effizienz des Gesamtmodells erhöhen.

Weglassen nicht verwendbarer Assoziationen

Das Vorhandensein zu vieler Assoziationen kann ein System nicht entzifferbar machen und somit die Gesamteffizienz des Systems verringern. Während der Optimierung werden also alle nicht verwendbaren Zuordnungen entfernt.

Optimierung von Algorithmen

In objektorientierten Systemen erfolgt die Optimierung der Datenstruktur und der Algorithmen auf kollaborative Weise. Sobald das Klassendesign eingerichtet ist, müssen die Operationen und Algorithmen optimiert werden.

Die Optimierung von Algorithmen wird erreicht durch -

  • Neuordnung der Reihenfolge der Rechenaufgaben
  • Umkehrung der Ausführungsreihenfolge von Schleifen von der im Funktionsmodell festgelegten
  • Entfernung toter Pfade innerhalb des Algorithmus

Speichern und Speichern abgeleiteter Attribute

Abgeleitete Attribute sind solche Attribute, deren Werte als Funktion anderer Attribute (Basisattribute) berechnet werden. Die Neuberechnung der Werte abgeleiteter Attribute bei jedem Bedarf ist zeitaufwändig. Um dies zu vermeiden, können die Werte berechnet und in ihren berechneten Formen gespeichert werden.

Dies kann jedoch zu Aktualisierungsanomalien führen, dh zu einer Änderung der Werte von Basisattributen ohne entsprechende Änderung der Werte der abgeleiteten Attribute. Um dies zu vermeiden, werden die folgenden Schritte ausgeführt:

  • Bei jeder Aktualisierung des Basisattributwerts wird auch das abgeleitete Attribut neu berechnet.

  • Alle abgeleiteten Attribute werden in einer Gruppe und nicht nach jeder Aktualisierung regelmäßig neu berechnet und aktualisiert.

Designdokumentation

Die Dokumentation ist ein wesentlicher Bestandteil jedes Softwareentwicklungsprozesses, der den Herstellungsprozess der Software aufzeichnet. Die Entwurfsentscheidungen müssen für jedes nicht triviale Softwaresystem dokumentiert werden, um den Entwurf an andere zu übertragen.

Nutzungsbereiche

Obwohl es sich um ein Sekundärprodukt handelt, ist eine gute Dokumentation insbesondere in den folgenden Bereichen unabdingbar:

  • Beim Entwerfen von Software, die von einer Reihe von Entwicklern entwickelt wird
  • In iterativen Softwareentwicklungsstrategien
  • Bei der Entwicklung nachfolgender Versionen eines Softwareprojekts
  • Zur Bewertung einer Software
  • Zum Auffinden von Bedingungen und Testbereichen
  • Zur Wartung der Software.

Inhalt

Eine nützliche Dokumentation sollte im Wesentlichen die folgenden Inhalte enthalten:

  • High–level system architecture - Prozessdiagramme und Moduldiagramme

  • Key abstractions and mechanisms - Klassendiagramme und Objektdiagramme.

  • Scenarios that illustrate the behavior of the main aspects - Verhaltensdiagramme

Eigenschaften

Die Merkmale einer guten Dokumentation sind -

  • Prägnant und gleichzeitig eindeutig, konsistent und vollständig

  • Rückverfolgbar auf die Anforderungsspezifikationen des Systems

  • Well-structured

  • Diagrammatisch statt beschreibend