Heim >Web-Frontend >Front-End-Fragen und Antworten >Verwandte Erläuterungen zum objektorientierten Design

Verwandte Erläuterungen zum objektorientierten Design

jacklove
jackloveOriginal
2018-06-20 15:31:302189Durchsuche

Viele Elemente des Entwurfsmodells sind UML-Diagramme, die im Analysemodell verwendet werden. Der Unterschied besteht darin, dass diese Diagramme im Rahmen des Entwurfs verfeinert und detailliert werden und mehr umsetzungsspezifische Details liefern, indem sie die Struktur und den Stil der Architektur, die in der Architektur vorhandenen Komponenten und die Schnittstellen zwischen den Komponenten und der Außenwelt hervorheben.

1. Objektorientiertes Designmodell
Designmodellierungsaufgaben:
Architekturdesign
Paket- und Subsystemdesign
Klassendesign
Persistenzdesign

(1) Komponentendiagramm
(2) Bereitstellungsdiagramm
(3) Zustandsmaschinendiagramm

2. Architekturdesign
(1) 4 + 1 Architekturansicht
Logische Ansicht, Entwicklungsansicht, Prozessansicht, physische Ansicht, Szenenansicht
(2) Logisches Ansichtsdesign
Die logische Struktur der Software wird zur Unterstützung funktionaler Anforderungen verwendet.
(3) Prozessansichtsdesign
Die Prozessarchitektur der Software ist auf nichtfunktionale Anforderungen ausgerichtet.
Die Aufgaben, aus denen ein Prozess besteht, sind separate Steuerungsstränge, und die Software ist in eine Reihe unabhängiger Aufgaben unterteilt. (Bereitstellungsdiagramm)
(4) Design der Entwicklungsansicht
Die Entwicklungsarchitektur der Software, dh wie sie in Implementierungseinheiten zerlegt wird, ist die Grundlage der Nachfrageverteilung und die Grundlage der Entwicklungsorganisationsstruktur.
Wie in Abbildung 7-7 dargestellt, werden im horizontalen Aufteilungsschema 6 Pakete 6 Entwicklungsgruppen zugewiesen und befinden sich auf verschiedenen Ebenen der Architektur. Die Entwicklungsgruppen können Personal entsprechend den technischen Ebenen zuweisen.
Das vertikale Segmentierungsschema in der folgenden Abbildung verteilt Aufgaben entsprechend der Geschäftslogik auf mehrere Entwicklungsgruppen. Jede Entwicklungsgruppe muss über umfassende Entwicklungsfunktionen verfügen.
(5) Design der physischen Ansicht
Die physische Architektur der Software, Benutzerfreundlichkeit, Zuverlässigkeit, Skalierbarkeit usw. für nichtfunktionale Anforderungen. (Bereitstellungsdiagramm)
(6) Szenenansichtsdesign
Ein Szenario ist eine Instanz eines Anwendungsfalls, der die vier Ansichten organisch verknüpft. Es ist die treibende Kraft hinter der Entdeckung architektonischer Elemente und übernimmt die Rolle der Verifizierung und Erklärung.

3. Prinzipien des Paketdesigns
Wiederverwendungs-Release-Äquivalenz: Wiederverwendungsgranularität ist gleich Release-Granularität
Gemeinsame Wiederverwendung: Alle Klassen im Paket werden gemeinsam wiederverwendet Gemeinsamer Abschluss: Alle Klassen im Paket sind gegenüber Änderungen desselben Typs geschlossen Azyklische Abhängigkeit: azyklische Abhängigkeitsstruktur zwischen Paketen
Stabile Abhängigkeiten: Ein Paket sollte von einem Paket abhängen, das stabiler ist als es selbst
Stabile Abstraktion: Das stabilste Paket ist das abstrakteste, und das instabile Paket ist das konkrete Paket.

4. Klassendesign

Einzelne Verantwortung, Lee-Ersatz, Abhängigkeitsumkehr, Schnittstellenisolation, Entwicklungs-Schließungs-Prinzip.

5. Persistenzdesign

(1) Entitätsobjektmodellierung (3) Persistenz-Framework.


6. Objektorientierter Designprozess

Designelemente identifizierenBestimmen Sie den Architekturstil und entwerfen Sie die GesamtstrukturDesign auf Komponentenebene


7, Subsystem-Designprozess

(1) Definieren Sie die Verantwortlichkeiten des Subsystems, dh die Definition der Schnittstelle (2) Bestimmen Sie die Elemente im Subsystem durch Zuweisung von Verantwortlichkeiten und implementieren Sie die Verantwortlichkeiten nach Komponenten und anderen Elementen (3) Entwerfen Sie jedes Element im Subsystem, dh Klassendesign (statische Struktur und dynamische Struktur); (4) Bestimmen Sie die Abhängigkeiten zwischen Subsystemen.
8. Schritte des Designs auf Komponentenebene

Anwendungsfallrealisierung aktualisieren
Subsystemdesign: Entwerfen Sie Interaktionsdiagramme und VOPC-Klassendiagramme für jede Operation jeder Schnittstelle, ähnlich wie das Design des Systems, das heißt das Design der Use-Case-Realisierung

Klasse:

(1) Erstellen Sie eine Designklasse: Ordnen Sie die Analyseklasse der Designklasse zu (2) Definieren Sie die Operation : eine einzelne Verantwortung implementieren; (3) Methode definieren: die interne Implementierung der Operation beschreiben; (4) Status definieren: die Auswirkung des Objektstatus auf das Verhalten beschreiben und die Attribute des Objekts mit der Operation verknüpfen ;
(5) Attribute definieren: Einbeziehung von Parametern in Methoden, Status von Objekten usw.;
(6) Abhängigkeiten definieren: bestehende Beziehungen zwischen Klassen, nichtstrukturelle Beziehungen; Einzelheiten zur Assoziationsklassifizierung, einschließlich Aggregation und Kombination, Anleitung, Multiplizität und Assoziationsklassen
(8) Erstellen Sie ein Spezifikationsbuch für Designspezifikationen.


9. Sequenzdiagramm

Extrahieren Sie verschiedene Ereignisse aus dem Anwendungsfall-Ereignisstrom und bestimmen Sie die Sende- und Empfangsobjekte des Ereignisinteraktionsverhaltens. Verwenden Sie das Sequenzdiagramm, um die Ereignissequenz zu verbinden und Ereignisse mit Objektbeziehungen werden ausgedrückt.

10. Zustandsmaschinendiagramm
Zustandsdiagramm zeigt die Beziehung zwischen Ereignissen und Objektzuständen. Wenn ein Objekt ein Ereignis empfängt, wird die verursachte Zustandsänderung als „Übergang“ bezeichnet.
Verwenden Sie ein Zustandsdiagramm, um das Verhalten eines Objekttyps zu beschreiben, der die Abfolge von Zuständen bestimmt, die durch die Abfolge von Ereignissen hervorgerufen werden. Es werden nur Klassen mit signifikantem Interaktionsverhalten berücksichtigt.
Im Ereignisverfolgungsdiagramm werden Ereignisse als gerichtete Kanten (d. h. Pfeillinien) in das Zustandsdiagramm eingegeben und die Kanten werden mit Ereignisnamen gekennzeichnet. Das Intervall zwischen zwei Ereignissen ist ein Zustand.
Die im Ereignisverfolgungsdiagramm projizierte Pfeillinie stellt das Verhalten des durch diese vertikale Linie dargestellten Objekts dar, wenn es einen bestimmten Zustand erreicht (häufig ein Ereignis, das den Zustandsübergang eines anderen Objekttyps verursacht).

In diesem Artikel werden verwandte Inhalte zum objektorientierten Design erläutert. Weitere verwandte Empfehlungen finden Sie auf der chinesischen PHP-Website.

Verwandte Empfehlungen:

php-Datei enthält Verzeichniskonfiguration, open_basedir-Nutzung und Leistungsanalyse

Linux verwendet den Befehl pwgen, um Zufallsgeneratoren zu erstellen Passwort

php-Datei enthält Verzeichniskonfiguration, open_basedir-Nutzung und Leistungsanalyse

Das obige ist der detaillierte Inhalt vonVerwandte Erläuterungen zum objektorientierten Design. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn