Wondershare EdrawMind
Mindmap-Galerie Kapitel 4 Design Engineering Mind Map
- 9
Kapitel 4 Design Engineering Mind Map
Kapitel 4 Design Engineering Mind Map Diese Mind Map enthält einen Überblick über Software-Design-Engineering, Software-Design-Prinzipien, Design-Technologie auf Komponentenebene, Design-Spezifikationen und Design-Review.
Bearbeitet um 2023-11-14 21:39:57
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Projektmanagement-Prozess-Vorlage
Projektmanagement ist der Prozess der Anwendung von Fachwissen, Fähigkeiten, Werkzeugen und Methoden auf die Projektaktivitäten, so dass das Projekt die festgelegten Anforderungen und Erwartungen im Rahmen der begrenzten Ressourcen erreichen oder übertreffen kann. Dieses Diagramm bietet einen umfassenden Überblick über die 8 Komponenten des Projektmanagementprozesses und kann als generische Vorlage verwendet werden.
Kapitel 4 Design Engineering Mind Map
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Projektmanagement-Prozess-Vorlage
Projektmanagement ist der Prozess der Anwendung von Fachwissen, Fähigkeiten, Werkzeugen und Methoden auf die Projektaktivitäten, so dass das Projekt die festgelegten Anforderungen und Erwartungen im Rahmen der begrenzten Ressourcen erreichen oder übertreffen kann. Dieses Diagramm bietet einen umfassenden Überblick über die 8 Komponenten des Projektmanagementprozesses und kann als generische Vorlage verwendet werden.
- Für Sie empfohlen
- Gliederung
Anforderungsanalyse, Softwaretests, Softwareentwicklung, Softwaredesign, Selbststudium, Mindmap
- 20
Kapitel 4 Designprojekt
Überblick über Software-Design-Engineering
Überblick über Software-Design-Engineering
Die Softwareanforderungsanalyse löst das Problem „was zu tun ist“, während der Softwaredesignprozess das Problem „wie es zu tun ist“ löst.
Softwaredesign ist der Prozess der Umwandlung von Softwareanforderungen in Softwaredarstellung. Er besteht hauptsächlich aus zwei Phasen: der Entwurfsphase der Softwarearchitektur und dem Entwurf auf Komponentenebene.
Software-Design-Aufgaben
Mithilfe eines Entwurfsansatzes werden Informationen über die Softwareanforderungen, die durch Daten, Funktions- und Verhaltensmodelle im Softwareanalysemodell dargestellt werden, an die Entwurfsphase übergeben, was zu Daten-/Klassenentwurf, Architekturentwurf, Schnittstellenentwurf und Entwurf auf Komponentenebene führt
Daten-/Klassendesign: Transformieren Sie das Analyseklassenmodell in Klassenimplementierung und Datenstrukturen, die für die Softwareimplementierung erforderlich sind
Der detaillierte Dateninhalt, der in den im CRC und im Datenwörterbuch definierten Klassen und Datenobjekten und -beziehungen beschrieben wird, bildet die Grundlage für Datendesignaktivitäten.
Der Datenentwurfsprozess umfasst die folgenden zwei Schritte:
Erstens erfordert die Auswahl einer logischen Darstellung für die in der Anforderungsanalysephase ermittelten Datenobjekte eine algorithmische Analyse verschiedener Strukturen, um die effektivste Entwurfslösung auszuwählen.
Identifizieren Sie dann die Programmmodule, die mit den logischen Datenstrukturen arbeiten, die erforderlich sind, um die Auswirkungen einzelner Datendesignentscheidungen zu begrenzen oder einzuschränken.
Architekturdesign: Architekturdesign definiert die Gesamtstruktur der Software
Architekturdesign definiert die Gesamtstruktur der Software, die aus Softwarekomponenten, äußerlich sichtbaren Attributen und den Beziehungen zwischen ihnen besteht.
Architekturentwurfsdarstellungen können aus Systemspezifikationen, Analysemodellen und Interaktionen von Subsystemen abgeleitet werden, die im Analysemodell definiert sind.
Schnittstellendesign: Schnittstellendesign beschreibt, wie innerhalb der Software, zwischen der Software und kollaborativen Systemen sowie zwischen Softwarekollegen kommuniziert wird.
Das Interface-Design umfasst hauptsächlich drei Aspekte:
Entwerfen Sie Schnittstellen zwischen Softwaremodulen
Entwerfen Sie Schnittstellen zwischen Modulen und anderen nichtmenschlichen Informationsproduzenten und -konsumenten (z. B. externen Einheiten).
Die Schnittstelle zwischen Designer (Benutzer) und Computer
Komponentenebenendesign: Komponentenebenendesign transformiert die Strukturelemente der Softwarearchitektur in eine prozedurale Beschreibung der Softwarekomponenten.
Beim Design auf Komponentenebene werden die Strukturelemente der Softwarearchitektur in prozedurale Beschreibungen von Softwarekomponenten umgewandelt.
Die aus klassenbasierten Modellen, Strömungsmodellen und Verhaltensmodellen gewonnenen Informationen bilden die Grundlage für das Komponentendesign.
Ziele des Softwaredesigns
Beim Software-Design müssen wir den Qualitätsfaktoren der Software große Aufmerksamkeit schenken.
Die Ziele des McGlanghlin-Softwaredesignprozesses sind:
1) Der Entwurf muss alle im Analysemodell beschriebenen expliziten Anforderungen umsetzen und alle vom Benutzer erwarteten impliziten Anforderungen erfüllen.
2) Das Design muss lesbar und verständlich sein, sodass es in Zukunft einfach zu programmieren, zu testen und zu warten ist.
3) Der Entwurf sollte aus der Implementierungsperspektive beginnen und ein vollständiges Bild der Software in Bezug auf Daten, Funktionen und Verhaltensweisen vermitteln.
Technische Standards für Messdesign
1) Die entworfene Struktur sollte eine hierarchische Struktur sein, um die Kontrolle zwischen Softwarekomponenten herzustellen.
2) Das Design sollte modular sein und die Software logisch in Komponenten unterteilen, die bestimmte Funktionen oder Unterfunktionen vervollständigen.
3) Das Design sollte sowohl Datenabstraktion als auch Prozessabstraktion umfassen.
4) Der Entwurf sollte Module mit unabhängigen Funktionsmerkmalen etablieren.
5) Das Design sollte Schnittstellen schaffen, die die komplexen Verbindungen zwischen dem Modul und der externen Umgebung reduzieren.
6) Der Entwurf sollte in der Lage sein, eine fahrbare und wiederholbare Methode zu etablieren, die auf den Informationen basiert, die aus der Analyse der Softwareanforderungen gewonnen wurden.
Software-Designprozess
1) Spezifikationen entwickeln
2) Architektur und Schnittstellendesign
3) Daten-/Klassendesign
4) Design auf Komponentenebene (Prozess).
5) Entwurfsdokumente schreiben
6) Designüberprüfung
Prinzipien des Softwaredesigns
Abstraktion und schrittweise Verfeinerung
Abstraktion ist eine grundlegende Strategie zur Kontrolle der Komplexität, wenn der Umfang des Softwaredesigns allmählich zunimmt.
Der Abstraktionsprozess verläuft vom Spezifischen zum Allgemeinen. Das Konzept der oberen Ebene ist die Abstraktion des Konzepts der unteren Ebene, und das Konzept der unteren Ebene ist die Verfeinerung und Verfeinerung des Konzepts der oberen Ebene.
Jeder Schritt im Softwareentwicklungsprozess ist eine konkrete Beschreibung der Interpretation einer höheren Abstraktionsebene.
Die wichtigsten Abstraktionsmethoden im Softwaredesign sind: Prozessabstraktion und Datenabstraktion
Prozessabstraktion (auch funktionale Abstraktion genannt) bedeutet, dass jede Operation, die eine klar definierte Funktion ausführt, vom Benutzer als eine einzelne Entität behandelt werden kann, obwohl diese Operation tatsächlich durch eine Reihe von Operationen auf niedrigerer Ebene abgeschlossen wird
Datenabstraktion bezieht sich auf die Definition von Datentypen und Operationen, die auf Objekte dieses Typs angewendet werden, und begrenzt den Wertebereich von Objekten. Daten können nur durch diese Operationen geändert und beobachtet werden.
Streben Sie nach und nach nach einer Verfeinerung
Schrittweise Verfeinerung, bei der der Problemlösungsprozess in mehrere Schritte oder Stufen unterteilt wird, wobei jeder Schritt verfeinert und näher an der Lösung des Problems liegt als der vorherige Schritt.
Durch Abstraktion können Designer Prozesse und Daten beschreiben und dabei Details auf niedriger Ebene ignorieren, während Verfeinerung Designern dabei hilft, Details auf niedriger Ebene während des Designprozesses offenzulegen.
Modular
Modularisierung, also die Aufteilung von Software in kleinere, unabhängige, aber miteinander verbundene Komponenten nach vorgeschriebenen Prinzipien, ist eigentlich ein Prozess der Systemzerlegung und -abstraktion.
Ein Modul ist eine Sammlung von Programmobjekten wie Datenbeschreibungen und ausführbaren Anweisungen. Es ist individuell benannt und kann über den Namen aufgerufen werden.
Zum Beispiel Prozess. Funktionen, Unterprogramme, Makros usw.
Informationen verbergen
Die Implementierungsdetails jedes Moduls sollten vor anderen Modulen verborgen bleiben
Die im Block enthaltenen Informationen (einschließlich Daten und Prozeduren) dürfen nicht von anderen Modulen verwendet werden, die diese Informationen nicht benötigen.
Durch das Ausblenden von Informationen können Zugriffsbeschränkungen auf die Prozessdetails und lokalen Datenstrukturen des Moduls definiert und durchgesetzt werden.
Funktional unabhängig
Funktionale Unabhängigkeit: Funktionale Unabhängigkeit ist ein direktes Ergebnis von Konzepten wie Modularität, Abstraktion, Informationsverbergung und Lokalisierung. Funktionale Unabhängigkeit kann durch die Entwicklung von Modulen erreicht werden, die funktionsspezifisch sind und übermäßige Interaktionen mit anderen Modulen vermeiden.
Die Bedeutung der funktionalen Unabhängigkeit
Die Funktionalität wird getrennt und die Schnittstellen werden vereinfacht, was die Entwicklung von Software erleichtert
Da die durch Änderungen am Design oder der Codierung verursachten Nebenwirkungen begrenzt sind, wird die Fehlerausbreitung verringert und die Wiederverwendung von Modulen ermöglicht, wodurch die Software einfacher zu warten und zu testen ist.
Die funktionale Unabhängigkeit kann anhand von zwei Indikatoren gemessen werden: Kohäsion und Kopplung
Kohäsion ist ein Maß dafür, wie eng die Elemente innerhalb eines Moduls miteinander integriert sind.
Der allgemeine Modulzusammenhalt ist in sieben Typen unterteilt
1) Zufällige Kohäsion (zufällige Kohäsion): Ein Modul, das dieselben Programmcodesegmente, die keine eindeutig unabhängige Funktion aufweisen, in mehrere Module trennt, wird als zufälliges Kohäsionsmodul bezeichnet.
2) Logischer Zusammenhalt: Bezieht sich auf ein Modul, das eine Reihe logisch zusammenhängender Aufgaben ausführt. Wenn das Modul aufgerufen wird, bestimmen die an das Modul übergebenen Steuerparameter, welche Funktion das Modul ausführen soll.
3) Zeitkonvergenz: bedeutet, dass alle Aufgaben in einem Modul innerhalb derselben Zeitspanne ausgeführt werden müssen. Zum Beispiel Initialisierungsmodul und Abschlussmodul
4) Prozesskohäsion: bezieht sich auf ein Modul, das mehrere Aufgaben erledigt, und diese Aufgaben müssen gemäß einem festgelegten Verfahren (prozedural) ausgeführt werden.
5) Kommunikationskohäsion: bedeutet, dass alle Verarbeitungselemente in einem Modul in einem Bereich einer bestimmten Datenstruktur konzentriert sind
6) Sequentielle Kohäsion: Bezieht sich auf ein Modul, das mehrere Funktionen ausführt, und diese Funktionen müssen nacheinander ausgeführt werden
7) Funktioneller Zusammenhalt: bezieht sich auf die Tatsache, dass alle Teile eines Moduls zusammenarbeiten, um eine bestimmte Funktion zu erfüllen, eng miteinander verbunden und untrennbar miteinander verbunden sind
Die Kopplung ist ein Maß für die relative Unabhängigkeit zwischen Modulen (wie eng sie miteinander verbunden sind).
Im Allgemeinen gibt es sieben Arten möglicher Kopplungsmethoden zwischen Modulen.
1) Inhaltskopplung: Wenn ein Modul direkt auf die internen Daten eines anderen Moduls zugreift oder ein Modul über den normalen Eingang auf das andere Modul zugreift; Anschließend erfolgt eine inhaltliche Kopplung zwischen den beiden Modulen
2) Öffentliche Kopplung: Wenn eine Gruppe von Modulen alle auf dieselbe gemeinsame Datenumgebung zugreift, wird die Kopplung zwischen ihnen als öffentliche Kopplung bezeichnet. Die öffentliche Datenumgebung kann eine globale Datenstruktur, ein gemeinsam genutzter Kommunikationsbereich, ein öffentlicher Abdeckungsbereich des Speichers usw. sein.
3) Externe Kopplung: Wenn Module über eine Umgebung außerhalb der Software verbunden sind (z. B. durch E/A-Kopplung des Moduls mit einem bestimmten Gerät, Format oder Kommunikationsprotokoll), spricht man von externer Kopplung.
4) Steuerkopplung: Wenn die von einem Modul an ein anderes Modul übertragenen Parameter Steuerinformationen enthalten und die Steuerinformationen zur Steuerung der Ausführungslogik im empfangenden Modul verwendet werden, spricht man von Steuerkopplung.
5) Tag-Kopplung: Ein Teil einer Datenstruktur (z. B. eine Unterstruktur einer bestimmten Datenstruktur) wird zwischen zwei Modulen über eine Parametertabelle übertragen, bei der es sich um eine Tag-Kopplung handelt.
6) Datenkopplung: Über Parametertabellen werden nur einfache Daten zwischen zwei Modulen übertragen, was als Datenkopplung bezeichnet wird.
7) Indirekte Kopplung: Wenn zwischen zwei Modulen keine direkte Beziehung besteht, das heißt, eines davon ist nicht vom anderen abhängig und kann unabhängig voneinander arbeiten, wird diese Kopplung als indirekte Kopplung bezeichnet.
Je enger die Verbindungen zwischen Modulen, desto mehr Verbindungen gibt es, desto höher ist die Kopplung und desto schwächer ist ihre funktionale Unabhängigkeit.
Je enger die Verbindung zwischen den verschiedenen Elementen innerhalb eines Moduls ist, desto höher ist dessen Zusammenhalt.
Module mit starker funktionaler Unabhängigkeit sollten Module mit hoher Kohäsion und geringer Kopplung sein.
Entwurf einer Software-Architektur
Die Softwarearchitektur konzentriert sich auf eine oder mehrere Strukturen eines Systems, einschließlich Softwarekomponenten, der äußerlich sichtbaren Eigenschaften dieser Komponenten und der Beziehungen zwischen ihnen.
Bass nennt drei Hauptgründe, warum Architektur wichtig ist:
① Erleichtern Sie die Kommunikation zwischen den Beteiligten
②Fördert eine frühzeitige Entscheidungsfindung im Systemdesign
③Übertragbare Abstraktion auf Systemebene
Architekturentwicklungsprozess
Gemeinsame Softwarearchitektur
Einzelhoststruktur k
C/S-Struktur (Client/Server).
B/S-Struktur (Browser/Server).
Software-Architekturstil
Die überwiegende Mehrheit kann als einer von relativ wenigen Architekturstilen klassifiziert werden
Jeder Stil beschreibt eine Systemkategorie, die Folgendes umfasst:
① Einige Komponenten, die die vom System benötigten Funktionen implementieren (z. B. Datenbanken, Computermodule)
②Eine Reihe von „Anschlüssen“, die zum Verbinden von Komponenten für „Kommunikation, Koordination und Zusammenarbeit“ verwendet werden.
③ Definieren Sie Systembeschränkungen für die Art und Weise, wie Komponenten integriert werden
④ Semantisches Modell, das es Designern ermöglicht, die Eigenschaften des gesamten Systems zu verstehen und bekannte Eigenschaften zu analysieren
datenzentrierte Architektur
Einige Daten (z. B. eine Datei oder eine Datenbank) werden im Zentrum der Struktur gespeichert und von anderen Komponenten häufig verwendet, hinzugefügt, gelöscht oder geändert
Architektur im Datenflussstil
Diese Struktur eignet sich für die Umwandlung von Eingabedaten in Ausgabedaten durch eine Reihe von Berechnungs- oder Verarbeitungskomponenten.
Architektur im Call-and-Return-Stil
Dieser Stil ermöglicht es einem Softwareentwickler, eine Architektur zu entwerfen, die sich sehr einfach ändern und erweitern lässt.
Enthält: Architektur im Hauptprogramm-/Unterprogrammstil und Architektur im Remoteprozeduraufrufstil
Hier sind einige Konzepte zu verstehen:
Tiefe der Programmstruktur: Die Anzahl der Ebenen der Programmstruktur wird als Tiefe der Struktur bezeichnet. Die Tiefe der Struktur spiegelt in gewissem Maße die Größe und Komplexität der Programmstruktur wider.
Die Breite der Programmstruktur: Die maximale Anzahl von Modulen auf derselben Ebene in der Hierarchie wird als Breite der Struktur bezeichnet
Modul-Fan-In und Fan-Out: Fan-Out stellt die Anzahl anderer Module dar, die ein Modul direkt aufruft (oder steuert). Fan-In ist definiert als die Anzahl der Module, die ein bestimmtes Modul aufrufen (oder steuern). Aufgrund mehrerer Fan-Outs müssen viele untergeordnete Module gesteuert und koordiniert werden. Multi-Fan-In-Module sind in der Regel öffentliche Module.
Objektorientierte Stilarchitektur
Methoden für Systemkomponenten zum Kapseln von Daten und Bearbeiten von Daten
Die Interaktion und Koordination zwischen Komponenten erfolgt über Nachrichten
Architektur im hierarchischen Stil
In dieser Struktur sind verschiedene Ebenen definiert, und jede Ebene führt Operationen näher an Maschinenanweisungen aus als die äußere Ebene.
Bewerten Sie alternative Architekturen
Für die gleiche Softwareanforderung werden aufgrund unterschiedlicher Prinzipien verschiedener Entwurfsmethoden unterschiedliche Softwarestrukturen abgeleitet.
Unterschiedliche Softwarestrukturen für das gleiche Problem
ATAM (Architecture Trade-Off Analysis Method)
1) Definieren Sie Anwendungsszenarien (Szenarien): Drücken Sie das System aus der Sicht des Benutzers durch Anwendungsfalldiagramme aus
2) Anforderungen, Einschränkungen und Umgebungsbeschreibung ableiten: Dies ist Teil des Anforderungsengineerings, um sicherzustellen, dass alle Kundenanliegen aufgeführt werden
3) Beschreiben Sie den Architekturstil, der die oben genannten Situationen und Anforderungen bewältigen kann
4) Bewerten Sie jede Leistung des Systems einzeln. Die Leistung für den Architekturentwurf umfasst: Zuverlässigkeit, Leistung, Sicherheit, Wartbarkeit, Flexibilität, Testbarkeit, Portabilität, Wiederverwendbarkeit und Interoperabilität usw.
5) Bewerten Sie für verschiedene Architekturformen die Empfindlichkeit dieser in Schritt 4 genannten Leistungen. Es kann folgendermaßen bewertet werden: Nehmen Sie einige kleine Änderungen an der gesamten Architektur vor, analysieren Sie und stellen Sie fest, ob es sensible Änderungen in der Appellleistung gibt. Die Leistung, die durch Architekturänderungen stark beeinträchtigt wird, wird als sensible Punkte bezeichnet.
6) Bewerten Sie die in Schritt 3 vorgeschlagenen Architekturen anhand der Sensitivitätsanalyse in Schritt 5. Die von SEI beschriebene Methode lautet wie folgt: Wenn die sensiblen Punkte einer Architektur bestimmt werden, müssen wir die Faktoren finden, die die meisten Kompromisspunkte im System erfordern (Kompromisspunkte). Der Kompromissfaktor bedeutet, dass eine Änderung dieses Inhalts in der Architektur empfindliche Änderungen in der Leistung des Systems nach sich zieht. Beispielsweise hängt die Leistung eines Systems mit einer Client-Server-Struktur eng mit der Anzahl der Server im System zusammen (z. B. wird eine Erhöhung der Anzahl der Server die Leistung des Systems bis zu einem gewissen Grad verbessern)... In In diesem Fall ist die Anzahl der Server dieser Gleichgewichtspunkt in der Architektur.
Beim Entwurf einer Softwarearchitektur können Sie sich an den folgenden Regeln orientieren:
(1) Verbessern Sie die Softwarestruktur und verbessern Sie die Modulunabhängigkeit
(2) Angemessene Tiefe, Breite, Fan-Out und Fan-In des Moduls
(3) Der Beurteilungsbereich des Moduls sollte innerhalb seines Kontrollbereichs liegen
(4) Bemühen Sie sich, die Komplexität der Modulschnittstellen zu reduzieren
(5) Entwerfen Sie ein Modul mit einem einzigen Eingang und einem einzigen Ausgang
(6) Die Modulfunktionalität sollte vorhersehbar und die Modulgröße moderat sein
(7) Im Allgemeinen ist es besser, wenn ein Modul etwa 30 bis 50 Anweisungen enthält.
(8) Eine gut gestaltete Softwarestruktur weist normalerweise einen höheren Fan-Out auf der oberen Schicht, einen geringeren Fan-Out auf der mittleren Schicht und einen hohen Fan-In auf der unteren Schicht auf.
Designtechnologie auf Komponentenebene
In strukturierten Analyse- und Entwurfsmethoden werden Komponenten häufig als Module bezeichnet
In der objektorientierten Analyse und im objektorientierten Design werden Komponenten als Klassen bezeichnet. In komponentenbasierten Entwicklungsmethoden werden Komponenten als Komponenten bezeichnet.
In der Entwurfsphase auf Komponentenebene werden hauptsächlich die folgenden Arbeiten abgeschlossen:
Bestimmen Sie den für jede Komponente verwendeten Algorithmus, wählen Sie ein geeignetes Werkzeug aus, um den Algorithmusprozess auszudrücken, und schreiben Sie eine detaillierte Verfahrensbeschreibung der Komponente
Bestimmen Sie die Datenstrukturen, die intern von jeder Komponente verwendet werden
Am Ende des Entwurfs auf Komponentenebene sollten die oben genannten Ergebnisse in die Entwurfsspezifikation auf Komponentenebene geschrieben und durch Überprüfung in ein formelles Dokument umgewandelt werden, das als Grundlage für die nächste Stufe (Codierungsphase) dient.
Strukturierte Programmiermethode
Eine populärere Definition lautet: „Wenn die Codeblöcke eines Programms nur durch die drei grundlegenden Kontrollstrukturen Sequenz, Auswahl und Schleife verbunden sind und jeder Codeblock nur einen Eingang und einen Ausgang hat, dann wird das Programm als strukturiert bezeichnet.“ . von"
Mit der Entwicklung neuer Softwareentwicklungsmethoden und -technologien wie objektorientierter Software und Software-Wiederverwendung könnte ein realistischerer und effektiverer Entwicklungsansatz eine organische Kombination von Top-Down- und Bottom-Up-Methoden sein.
Grafische Darstellung
Programmablaufdiagramm
Programmablaufdiagramme sind unabhängig von jeder Programmiersprache, relativ intuitiv, klar und leicht zu erlernen und zu beherrschen.
Um Flussdiagramme zur Beschreibung strukturierter Programme zu verwenden, müssen Sie die Flussdiagramme auf nur fünf grundlegende Kontrollstrukturen beschränken.
N-S-Diagramm
Nassi und Shneiderman schlugen ein grafisches Beschreibungstool vor, das den Prinzipien der strukturierten Programmierung entspricht und als Boxdiagramm oder auch N-S-Diagramm bezeichnet wird.
Fünf grundlegende Kontrollstrukturen
UNTERLAGE
PAD ist die Abkürzung für Problem Analysis Diagram, die aus dem Programmflussdiagramm hervorgegangen ist.
Fünf grundlegende Kontrollstrukturen
Entscheidungstabelle
Wenn der Algorithmus mehrere verschachtelte Bedingungsauswahlen enthält, ist es schwierig, ihn mithilfe von Programmablaufdiagrammen, NS-Diagrammen oder PAD klar zu beschreiben.
Entscheidungstabellen können jedoch die Entsprechung zwischen komplexen Kombinationen von Bedingungen und den zu ergreifenden Maßnahmen klar zum Ausdruck bringen.
Der Vorteil der Entscheidungstabelle besteht darin, dass sie alle Verarbeitungsregeln prägnant und eindeutig beschreiben kann.
Die Entscheidungstabelle stellt jedoch eine statische Logik dar, die das mögliche Ergebnis unter einer bestimmten Kombination von Bedingungswerten darstellt. Sie kann weder die Verarbeitungssequenz noch die Schleifenstruktur ausdrücken.
Designsprache PDL
PDL (Program Design Language) ist eine Sprache, die zur Beschreibung des Algorithmusdesigns und der Verarbeitungsdetails funktionaler Komponenten verwendet wird und als Designsprache bezeichnet wird
Es handelt sich um eine Art Pseudocode. Im Allgemeinen werden die Grammatikregeln des Pseudocodes in „externe Grammatik“ und „innere Grammatik“ unterteilt.
Die fremde Syntax sollte den grammatikalischen Regeln häufig verwendeter Anweisungen in allgemeinen Programmiersprachen entsprechen.
Die interne Grammatik kann einige einfache Sätze, Phrasen und gebräuchliche mathematische Symbole auf Englisch verwenden, um die Funktionen zu beschreiben, die ein Programm ausführen soll.
Beispiele für die PDL-Nutzung
PDL-Funktionen
1. Es gibt eine feste schlüsselwortexterne Syntax, die alle strukturierten Kontrollstrukturen, Datenbeschreibungen und Komponentenfunktionen bereitstellt. Schlüsselwörter, die zur Fremdgrammatik gehören, sind ein begrenzter Vokabularsatz, der den PDL-Text strukturell segmentieren und ihn leicht verständlich machen kann. Zur Unterscheidung von Schlüsselwörtern ist festgelegt, dass Schlüsselwörter großgeschrieben und andere Wörter kleingeschrieben werden müssen.
2. Die innere Grammatik verwendet natürliche Sprache, um Verarbeitungsmerkmale zu beschreiben. Die interne Syntax ist relativ flexibel. Solange sie klar geschrieben ist, besteht kein Grund zur Sorge über Grammatikfehler, sodass sich die Leute auf die Beschreibung der Logik des Algorithmus konzentrieren können.
3. Es gibt Datenbeschreibungsmechanismen, einschließlich einfacher (z. B. Skalare und Arrays) und komplexer (z. B. verknüpfte Listen und hierarchische Strukturen) Datenstrukturen.
4. Es gibt eine Subroutinendefinition und einen Aufrufmechanismus, um Schnittstellenbeschreibungen auf verschiedene Arten auszudrücken.
Designspezifikationen und Designbewertungen
Design-Spezifikationen
Designprüfung
Das ultimative Ziel des Softwaredesigns ist es, die beste Lösung zu erhalten
„Beste“ bedeutet, dass unter allen Kandidatenlösungen die Lösung ausgewählt wird, die eine höhere Produktivität, höhere Zuverlässigkeit und Wartbarkeit erreichen kann, basierend auf den Bedingungen der Einsparung von Entwicklungskosten, der Reduzierung des Ressourcenverbrauchs und der Verkürzung der Entwicklungszeit.
Inhalte der Designprüfung
Rückverfolgbarkeit: Das heißt, die Systemstruktur und Subsystemstruktur der Software wird analysiert, um zu bestätigen, ob das Softwaredesign alle identifizierten Softwareanforderungen abdeckt und ob jede Komponente der Software auf eine bestimmte Anforderung zurückgeführt werden kann.
Schnittstelle: Analysieren Sie die Verbindung zwischen verschiedenen Teilen der Software und bestätigen Sie, ob die interne Schnittstelle und die externe Schnittstelle der Software klar definiert wurden. Ob die Komponente die Anforderungen einer hohen Kohäsion und einer geringen Kopplung erfüllt. Ob der Umfang der Komponente innerhalb ihres Kontrollbereichs liegt.
Risiko: Bestätigen Sie, ob das Softwaredesign unter den vorhandenen technischen Bedingungen und im Rahmen des Budgets termingerecht umgesetzt werden kann.
Praktikabilität: Bestätigen Sie, ob das Softwaredesign für die Lösung der Anforderungen praktisch ist
Technische Klarheit: Bestätigung, dass das Softwaredesign in einer Form ausgedrückt wird, die leicht in Code übersetzt werden kann
Wartbarkeit: Bestätigen Sie aus Sicht der Softwarewartung, ob das Softwaredesign die Bequemlichkeit zukünftiger Wartung berücksichtigt.
Qualität: Bestätigen Sie, ob das Softwaredesign gute Qualitätsmerkmale aufweist
Verschiedene Optionen: Sehen Sie, ob Sie andere Optionen in Betracht gezogen haben und welche Kriterien für den Vergleich verschiedener Optionen gelten?
Einschränkungen: Bewerten Sie, ob die Einschränkungen der Software realistisch sind und den Anforderungen entsprechen
Weitere spezifische Fragen: Bewertung der Dokumentation, Testbarkeit, Designprozess usw.
Es gibt zwei Arten der Überprüfung: die formelle Überprüfung und die informelle Überprüfung.
Neben Softwareentwicklern lädt die formelle Prüfung auch Benutzervertreter und Domänenexperten zur Teilnahme ein, meist in Form einer Verteidigung.
Informelle Bewertungen sind mehr oder weniger Peer-to-Peer-Begutachtungen und nicht auf Zeit oder Format beschränkt.