Software-Design-Strategien

Software-Design ist ein Prozess zur Konzeption der Softwareanforderungen in die Software-Implementierung. Das Software-Design nimmt die Benutzeranforderungen als Herausforderung und versucht, eine optimale Lösung zu finden. Während der Konzeption der Software wird ein Plan erstellt, um das bestmögliche Design für die Implementierung der beabsichtigten Lösung zu finden.

Es gibt mehrere Varianten des Software-Designs. Lassen Sie uns sie kurz studieren:

Strukturiertes Design

Strukturiertes Design ist eine Konzeptualisierung des Problems in mehrere gut organisierte Lösungselemente. Grundsätzlich geht es um das Lösungsdesign. Der Vorteil von strukturiertem Design besteht darin, dass es ein besseres Verständnis dafür gibt, wie das Problem gelöst wird. Strukturiertes Design erleichtert es dem Designer auch, sich genauer auf das Problem zu konzentrieren.

Strukturiertes Design basiert hauptsächlich auf der Strategie „Teilen und Erobern“, bei der ein Problem in mehrere kleine Probleme unterteilt wird und jedes kleine Problem einzeln gelöst wird, bis das gesamte Problem gelöst ist.

Die kleinen Probleme werden mit Hilfe von Lösungsmodulen gelöst. Strukturiertes Design betont, dass diese Module gut organisiert sind, um eine präzise Lösung zu erreichen.

Diese Module sind hierarchisch angeordnet. Sie kommunizieren miteinander. Ein gut strukturiertes Design folgt immer einigen Regeln für die Kommunikation zwischen mehreren Modulen, nämlich -

Cohesion - Gruppierung aller funktional verwandten Elemente.

Coupling - Kommunikation zwischen verschiedenen Modulen.

Ein gut strukturiertes Design hat eine hohe Kohäsion und niedrige Kopplungsanordnungen.

Funktionsorientiertes Design

Beim funktionsorientierten Entwurf besteht das System aus vielen kleineren Teilsystemen, die als Funktionen bekannt sind. Diese Funktionen können wichtige Aufgaben im System ausführen. Das System wird als Draufsicht auf alle Funktionen betrachtet.

Funktionsorientiertes Design erbt einige Eigenschaften des strukturierten Designs, bei denen die Divide and Conquer-Methode verwendet wird.

Dieser Entwurfsmechanismus unterteilt das gesamte System in kleinere Funktionen, die Abstraktionsmöglichkeiten bieten, indem die Informationen und ihre Funktionsweise verborgen werden. Diese Funktionsmodule können Informationen untereinander austauschen, indem sie Informationen weitergeben und global verfügbare Informationen verwenden.

Ein weiteres Merkmal von Funktionen ist, dass wenn ein Programm eine Funktion aufruft, die Funktion den Status des Programms ändert, was von anderen Modulen manchmal nicht akzeptiert wird. Funktionsorientiertes Design funktioniert gut, wenn der Systemstatus keine Rolle spielt und Programm / Funktionen eher auf Eingabe als auf einen Status arbeiten.

Designprozess

• Das gesamte System wird anhand eines Datenflussdiagramms als Datenfluss im System angesehen.
• DFD zeigt, wie Funktionen Daten und Status des gesamten Systems ändern.
• Das gesamte System wird aufgrund seines Betriebs im System logischerweise in kleinere Einheiten unterteilt, die als Funktionen bezeichnet werden.
• Jede Funktion wird dann allgemein beschrieben.

Objektorientiertes Design

Objektorientiertes Design arbeitet um die Entitäten und ihre Eigenschaften herum anstatt um Funktionen, die am Softwaresystem beteiligt sind. Diese Entwurfsstrategie konzentriert sich auf Entitäten und ihre Eigenschaften. Das gesamte Konzept der Softwarelösung dreht sich um die beteiligten Einheiten.

Lassen Sie uns die wichtigen Konzepte des objektorientierten Designs sehen:

• Objects - Alle am Lösungsentwurf beteiligten Entitäten werden als Objekte bezeichnet. Beispielsweise werden Personen, Banken, Unternehmen und Kunden als Objekte behandelt. Jeder Entität sind einige Attribute zugeordnet, und es gibt einige Methoden, die für die Attribute ausgeführt werden können.

• Classes - Eine Klasse ist eine verallgemeinerte Beschreibung eines Objekts. Ein Objekt ist eine Instanz einer Klasse. Die Klasse definiert alle Attribute, die ein Objekt haben kann, und Methoden, die die Funktionalität des Objekts definieren.

  Im Lösungsentwurf werden Attribute als Variablen gespeichert und Funktionalitäten mittels Methoden oder Prozeduren definiert.

• Encapsulation - In OOD werden die Attribute (Datenvariablen) und Methoden (Operation an den Daten) gebündelt, was als Kapselung bezeichnet wird. Durch die Kapselung werden nicht nur wichtige Informationen eines Objekts gebündelt, sondern auch der Zugriff auf die Daten und Methoden von außen eingeschränkt. Dies wird als Verstecken von Informationen bezeichnet.
• Inheritance - Mit OOD können ähnliche Klassen hierarchisch gestapelt werden, wobei die unteren oder Unterklassen zulässige Variablen und Methoden aus ihren unmittelbaren Superklassen importieren, implementieren und wiederverwenden können. Diese Eigenschaft von OOD wird als Vererbung bezeichnet. Dies erleichtert das Definieren bestimmter Klassen und das Erstellen verallgemeinerter Klassen aus bestimmten Klassen.
• Polymorphism - OOD-Sprachen bieten einen Mechanismus, bei dem Methoden, die ähnliche Aufgaben ausführen, jedoch unterschiedliche Argumente aufweisen, denselben Namen zugewiesen werden können. Dies wird als Polymorphismus bezeichnet, bei dem eine einzelne Schnittstelle Aufgaben für verschiedene Typen ausführt. Abhängig davon, wie die Funktion aufgerufen wird, wird der jeweilige Teil des Codes ausgeführt.

Designprozess

Der Software-Design-Prozess kann als eine Reihe klar definierter Schritte wahrgenommen werden. Es variiert zwar je nach Entwurfsansatz (funktionsorientiert oder objektorientiert, kann jedoch die folgenden Schritte umfassen:

• Ein Lösungsentwurf wird aus der Anforderung oder dem zuvor verwendeten System und / oder Systemsequenzdiagramm erstellt.
• Objekte werden identifiziert und in Klassen gruppiert, um die Ähnlichkeit der Attributmerkmale zu gewährleisten.
• Klassenhierarchie und Beziehung zwischen ihnen ist definiert.
• Anwendungsframework ist definiert.

Software-Design-Ansätze

Hier sind zwei generische Ansätze für das Software-Design:

Top-Down-Design

Wir wissen, dass ein System aus mehr als einem Teilsystem besteht und eine Reihe von Komponenten enthält. Ferner können diese Subsysteme und Komponenten einen Satz von Subsystemen und Komponenten haben und eine hierarchische Struktur im System erzeugen.

Beim Top-Down-Design wird das gesamte Softwaresystem als eine Einheit betrachtet und anschließend zerlegt, um basierend auf bestimmten Merkmalen mehr als ein Subsystem oder eine Komponente zu erhalten. Jedes Subsystem oder jede Komponente wird dann als System behandelt und weiter zerlegt. Dieser Prozess läuft so lange weiter, bis die niedrigste Systemebene in der Top-Down-Hierarchie erreicht ist.

Das Top-Down-Design beginnt mit einem verallgemeinerten Systemmodell und definiert weiterhin den spezifischeren Teil davon. Wenn alle Komponenten zusammengesetzt sind, entsteht das gesamte System.

Top-Down-Design ist besser geeignet, wenn die Softwarelösung von Grund auf neu entworfen werden muss und bestimmte Details unbekannt sind.

Bottom-up-Design

Das Bottom-Up-Designmodell beginnt mit den spezifischsten und grundlegendsten Komponenten. Es wird mit dem Zusammenstellen einer höheren Ebene von Komponenten fortgefahren, indem grundlegende oder niedrigere Komponenten verwendet werden. Es werden so lange übergeordnete Komponenten erstellt, bis das gewünschte System nicht mehr als eine einzige Komponente entwickelt wird. Mit jeder höheren Ebene wird der Abstraktionsgrad erhöht.

Eine Bottom-up-Strategie ist besser geeignet, wenn ein System aus einem vorhandenen System erstellt werden muss, in dem die Grundelemente im neueren System verwendet werden können.

Sowohl Top-Down- als auch Bottom-Up-Ansätze sind für sich genommen nicht praktikabel. Stattdessen wird eine gute Kombination von beiden verwendet.