Eine kurze Diskussion über das GRASP-Softwareentwicklungsmodell

Sind Sie ein guter Softwareentwickler? Kennen Sie GRASP? Das GRASP-Softwareentwicklungsmodell, der vollständige Name lautet General Responsibility Assignment Software Patterns, ist ein weiteres Softwareentwicklungsmodell, das so berühmt ist wie das berühmte Softwaremodell GoF (Gang of Four, die 23 Softwareentwicklungsmodelle, die wir oft als Modell bezeichnen). Aber im Gegensatz zu GoF schlägt es keine spezifischen Software-Organisationsstrukturen vor, sondern schlägt vielmehr vor, was wir bei der Abstraktion realer Geschäftsfunktionen in spezifische Objekte in der Softwareentwicklung befolgen sollten . Nur wenn wir diese Grundprinzipien befolgen, können wir hochwertige Software entwickeln. Für die Softwareprojekte, die wir entwickeln möchten, müssen wir nicht das Factory-Muster verwenden, wir müssen nicht das Singleton-Muster verwenden, wir müssen es nicht verwenden das Beobachtermuster, aber es ist für uns unmöglich, in der Softwareentwicklung reale Geschäftsfunktionen nicht in konkrete Objekte zu abstrahieren. Aus dieser Perspektive müssen wir die Qualität unserer Softwareentwicklung verbessern. Ein tiefes Verständnis von GRASP ist wichtiger als ein tiefes Verständnis von GoF. Aber ich sehe, dass es viele Artikel gibt, die GoF vorstellen, und nur wenige Artikel, die GRASP vorstellen. Aus diesem Grund stelle ich GRASP jetzt allen vor. GRASP enthält 9 Modelle, die 9 Grundprinzipien darstellen. Dies wird im klassischen Buch „UML and Pattern Application“ des Software-Design-Guru Craig Larman ausführlich erläutert. GRASP wird als „General Responsibility Assignment Software Pattern“ bezeichnet. Um GRASP zu verstehen, müssen wir zunächst die Frage verstehen, warum wir während des Objektanalyse- und Designprozesses Verantwortlichkeiten zuweisen müssen.

1. Verantwortungsverteilung und verantwortliches Design

Zu Beginn eines Softwareprojekts müssen wir normalerweise eine Anforderungsanalyse durchführen, um zu verstehen, welche Art von Software der Kunde entwerfen muss und welche Funktionen die Software hat hätte haben sollen. Die Anforderungsanalyse versteht die Geschäftsfunktionen, die Kunden in der realen Welt benötigen. Jede Geschäftsfunktion ist häufig ein Geschäftsprozess, dh der Geschäftsprozess, den Kunden weiterhin in ihrer täglichen Arbeit ausführen. Gleichzeitig muss es in der Problemwelt des Benutzers einige Dinge oder Dinge geben, die miteinander zusammenhängen.
Nehmen Sie als Beispiel ein Software-Review-Management-System. Die Geschäftsanforderungen des Bewertungsmanagementsystems lauten wie folgt:
1. Der Überprüfungsorganisator entwickelt einen Überprüfungsplan, legt ihn dem Leiter zur Genehmigung vor und benachrichtigt dann die Prüfer per E-Mail.
2． Die Prüfer werden aufgefordert, die Prüfobjekte jeweils zu prüfen, das Prüfformular auszufüllen und können Fragen zu den Prüfobjekten stellen.
3. Der Review-Organisator fasst die Fragen der Gutachter zusammen und hält ein Review-Meeting ab, um diese Fragen zu besprechen. Bei dem Treffen wurden einige Fragen zu Problemen, einige Fragen waren keine Probleme und einige konnten immer noch nicht bestätigt werden.
4． Nach der Besprechung sortiert der Review-Organisator die Fragen und erstellt einen Review-Bericht. Anschließend stimmen die Gutachter darüber ab, ob die Review bestanden wird oder nicht. Abschließend fasst der Review-Organisator die Abstimmungsergebnisse zusammen und bildet ein Review-Fazit.
5． Review-Organisatoren verfolgen die Lösung von Problemen.
Durch die Beschreibung der oben genannten Anforderungen fällt es uns nicht schwer, verwandte Dinge in der gesamten Problemwelt zu finden: Überprüfungsorganisator, Überprüfungsplan, Prüfer, Überprüfungsobjekt, Überprüfungsformular, Fragen, Überprüfungsbericht, Überprüfungsschlussfolgerung usw Fragen. Für uns ist es nicht schwierig, die Beziehung zwischen diesen Dingen zu analysieren. Beispielsweise sind der Überprüfungsplan und die Prüfer eine Eins-zu-Viele, während der Überprüfungsbericht und die Schlussfolgerungen der Überprüfung eine Eins-zu-eins sind.
In RUP bilden Geschäftsanforderungen Anwendungsfälle im Modell und seine Beschreibungsdokumente, und Dinge und ihre Beziehungen bilden Objekte im Domänenmodell. Natürlich, wie man Anwendungsfallmodelle und Domänen erstellt Modelle gehen über diesen Artikel hinaus. In Bezug auf den Umfang der Diskussion können interessierte Freunde relevante Artikel lesen.
Die Objekte im Domänenmodell werden zur Grundlage für die Bildung spezifischer Objekte in der Softwareentwicklung (welche Objekte in der Softwareentwicklung gebildet werden, hängt von den spezifischen Anforderungen der Softwareentwicklung ab und muss nicht unbedingt mit den Objekten übereinstimmen). des Domänenmodells). Die Anwendungsfälle im Anwendungsfallmodell werden durch die Zuweisung von Verhaltensweisen zu diesen Objekten implementiert. Nun stellt sich die Frage, wie diesen Objekten die Funktionen im Anwendungsfallmodell bzw. eine Reihe von Verhaltensweisen zugeordnet werden sollen. Mit anderen Worten: Um dieselbe Aufgabe zu erledigen, kann ich Verhalten A dem Objekt X oder dem Objekt Y zuordnen. Obwohl meine spezifische Implementierung von Verhalten A unterschiedlich ist, wenn ich es an Objekt X übergebe, und wenn ich es an Objekt Y übergebe, können beide die Aufgabe von Verhalten A erfüllen. Soll ich es also an Objekt X oder Objekt Y übergeben? Gibt es ein Grundprinzip? Ja, das heißt, Aufgaben nach Verantwortlichkeiten zu verteilen. Obwohl ich theoretisch Objekte willkürlich definieren, Objekte bedeutungslos machen oder willkürliche Aufgaben ausführen kann, entwerfen wir normalerweise nicht auf diese Weise. Normalerweise verbinden wir Objekte mit realen Objekten, z. B. beim Entwerfen eines Überprüfungsplanobjekts und eines Prüferobjekts. Und wir sollten beim Entwerfen von Objekten einen „geringen Darstellungsunterschied“ erreichen. Ein geringer Darstellungsunterschied bedeutet, dass die von uns entworfenen Objekte so konsistent wie möglich mit realen Objekten sein sollten. Wir entwerfen beispielsweise ein Objekt namens „Rezensent“, weil wir Rezensenten in der realen Welt haben. Gleichzeitig sollten die Verhaltensweisen, die wir Prüferobjekten zuweisen, so konsistent wie möglich mit der realen Welt sein, z. B. das Hinzufügen von Prüfern, das Ändern von Prüfern und das Abrufen von Prüferinformationen. Welche Verhaltensweisen diesem Objekt zugeordnet werden sollen, sollte also durch Verantwortlichkeiten bestimmt werden.
Wir entwerfen die Objekte im Softwaresystem durch Analyse der realen Welt oder Analyse des Domänenmodells. Zu diesem Zeitpunkt sollten wir jedem Objekt Verantwortlichkeiten zuweisen. Was ist die Verantwortung eines Objekts? Natürlich wird sie durch die Analyse der realen Welt und der Aufgaben definiert, die dieses Objekt erfüllen soll. Die Verantwortung des Prüferobjekts besteht beispielsweise darin, auf Daten zuzugreifen, die sich auf den Prüfer beziehen. Natürlich ist die Verantwortung des Objekts nicht unbedingt dieselbe. Beispielsweise enthält der Überprüfungsplan die Unterpunkte des Überprüfungsobjekts und des Prüfers, sodass er den Informationszugriff des Überprüfungsobjekts und des Prüfers im Namen des Prüfers verwalten kann Überprüfen Sie das Objekt, wenn die Arbeit nicht beschäftigt ist. Ein Objekt sollte jedoch nicht zu viele Verantwortlichkeiten haben (nur 2 oder 3) und eng miteinander verbunden sein. Wenn beispielsweise dem Objekt des Bewertungsformulars die Verantwortung zugewiesen wird, das Bewertungsformular zu bearbeiten und auch die Daten des Bewertungsplans zu verarbeiten, spricht man von einer Verantwortungsunabhängigkeit.
Verantwortungsverteilung wird mittlerweile allgemein als Prinzip anerkannt, dem ein exzellentes Software-Design folgen sollte. Es hat die folgenden Vorteile:
1. Geringe Darstellungsunterschiede machen Software klar strukturiert und leicht verständlich, da Softwareentwicklung keine Ein-Personen-Angelegenheit ist. Bei Softwareprojekten, die von mehreren Personen entwickelt werden, kann eine klare Softwarestruktur unnötige Fehler vermeiden, die durch Missverständnisse der Entwickler verursacht werden.
2． Einfach zu warten und zu wechseln. Wenn es ein Problem mit dem Prüfplan gibt oder eine Änderung erforderlich ist, wenden wir uns an den Prüfplan. Wenn es ein Problem mit dem Prüfer gibt, wenden wir uns an den Prüfer, und es wird niemals etwas mit anderen Parteien zu tun haben .
Diese Art von Objektdesign- und Komponentenansatz, der Objekte, Verantwortlichkeiten und Zusammenarbeit berücksichtigt, wird „Responsibility Drive Design (RDD)“ genannt. Verantwortungsgesteuertes Design umfasst zunächst das Entwerfen von Anwendungsfallmodellen, Anwendungsfallmodellbeschreibungen, Betriebsverträgen, Systemsequenzdiagrammen, Domänenmodellen und Glossaren und anschließend die schrittweise Erstellung von Analysemodellen und Entwurfsmodellen sowie das Schreiben von Interaktionsdiagrammen und Klassendiagrammen für jedes Auf den komplizierten Prozess werde ich hier nicht näher eingehen. Beachten Sie jedoch ein sehr wichtiges Detail. Wie bereits erwähnt, werden Objekte in Softwaresystemen von der realen Welt abstrahiert. Die Zuweisung von Objektverantwortlichkeiten basiert auf der Definition des Objekts und weist einige wenige und eng miteinander verbundene Aufgaben zu. Doch selbst wenn wir diese Prinzipien befolgen, verfügen wir immer noch über eine beträchtliche Designflexibilität. Verschiedene Menschen haben immer noch unterschiedliche Designs für dieselbe Funktion, basierend auf ihrem eigenen Verständnis. GRASP wird auf Chinesisch als „General Responsibility Assignment Software Pattern“ übersetzt und stellt mehrere Grundprinzipien für die Frage der Verantwortungszuweisung bei der Objektanalyse und dem Design vor. Gleichzeitig sollten diese Grundprinzipien aber auch bis zu einem gewissen Grad verstanden werden, das heißt, sie sind nicht in allen Situationen anwendbar und auch kein absoluter Indikator. Eine geringe Kopplung bedeutet beispielsweise keine absolute Nichtkopplung. Ohne Kopplung kann eine hohe Kohäsion nicht unendlich hoch sein, da das System sonst kompliziert und abnormal wird.

2. Analyse der GRASP-Muster einzeln

GRASP-Software Designmuster umfasst 9 Muster: Ersteller, Informationsexperte, Niedrig Kopplung, Controller, hohe Kohäsion, Polymorphismus, reine Fiktion, Indirektion, Mutationsverhinderung.

Das obige ist der detaillierte Inhalt vonEine kurze Diskussion über das GRASP-Softwareentwicklungsmodell. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!