Many elements of the design model are UML diagrams used in the analysis model. The difference is that these diagrams are refined and detailed as part of the design and provide more implementation-specific details, highlighting the structure and style of the architecture, the components present within the architecture, and the interfaces between the components and the outside world.
1. Object-oriented design model
Design modeling tasks:
Architecture design
Package and subsystem design
Class design
Persistence design
(1) Component diagram
(2) Deployment diagram
(3) State machine diagram
2. Architecture design
(1) 4 1 Architecture view
Logical view, development view, process view, physical view, scene view
(2) Logical view design
The logical structure of the software is used to support functional requirements.
(3) Process view design
The process architecture of the software is aimed at non-functional requirements.
The tasks that make up a process are separate threads of control, and the software is divided into a set of independent tasks. (Deployment diagram)
(4) Development view design
The development architecture of the software, that is, how to decompose it into implementation units, is the basis of demand distribution and the basis of the development organizational structure.
As shown in Figure 7-7, in the horizontal splitting scheme, 6 packages are allocated to 6 development groups and are at different levels of the architecture. The development groups can allocate personnel according to technical levels.
The vertical segmentation scheme in the figure below distributes tasks among multiple development groups according to business logic. Each development group must have comprehensive development capabilities.
(5) Physical view design
The physical architecture of the software, targeting the availability, reliability, scalability, etc. of non-functional requirements. (Deployment diagram)
(6) Scene view design
A scenario is an instance of a use case, which organically links the four views. It is the driving force behind the discovery of architectural elements, taking on the role of verification and explanation.
3. Package design principles
Reuse-release equivalence: reuse granularity is equal to release granularity;
Common reuse: all classes in the package are reused together;
Common closure: All classes in the package are closed to changes of the same type;
Acyclic dependency: acyclic dependency structure between packages;
Stable dependencies: A package should depend on a package that is more stable than itself;
Stable abstraction: The most stable package is the most abstract, and the unstable package is the concrete package.
4. Class design
Single responsibility, Li replacement, dependency inversion, interface isolation, development-closure principle.
5. Persistence design
(1) Entity object modeling;
(2) Database design;
(3) Persistence framework.
6. Object-oriented design process
Identify design elements
Determine the architectural style and design the overall structure
Component-level design
7 , Subsystem design process
(1) Define the responsibilities of the subsystem, that is, the definition of the interface;
(2) Determine the elements in the subsystem through responsibility allocation, and realize the responsibilities by components and other elements;
(3) Design each element in the subsystem, that is, class design (static structure and dynamic structure);
(4) Determine the dependencies between subsystems.
8. Steps of component-level design
Update Use-case Realization
Design of subsystem: design interaction diagram and VOPC class diagram for each operation of each interface , similar to the design of the system, that is, the design of the Use case realization
class:
(1) Create a design class: map the analysis class to the design class;
(2) Define the operation: implement a single responsibility;
(3) Definition method: describe the internal implementation of the operation;
(4) Definition state: describe the impact of the object's state on behavior, and associate the object's attributes with the operation;
(5) Define attributes: including parameters in methods, object status, etc.;
(6) Define dependencies: existing relationships between classes, non-structural relationships;
(7) Define associations: details of associations ization, including aggregation and combination, guidance, multiplicity, and related classes;
(8) Form a specification book for design classes.
9. Sequence diagram
Extract various events from the use case event stream and determine the sending object and receiving object of the event interaction behavior. Use the sequence diagram to combine the event sequence and the event with Object relationships are expressed.
10. State machine diagram
The state diagram depicts the relationship between events and object states. When an object receives an event, the state change caused is called a "transition".
Use a state diagram to describe the behavior of a type of object, which determines the sequence of states induced by the sequence of events. Only those classes with significant interaction behavior are considered.
In the event tracking diagram, events are entered as directed edges (i.e. arrow lines) in the state diagram, and the edges are marked with event names. The interval between two events is a state.
The arrow line projected in the event tracking diagram is the behavior of the object represented by this vertical line when it reaches a certain state (often an event that causes the state transition of another type of object).
This article explains related content about object-oriented design. For more related recommendations, please pay attention to the php Chinese website.
Related recommendations:
php file contains directory configuration open_basedir usage and performance analysis
Linux uses the pwgen command to create a random Password
#php file contains directory configuration open_basedir usage and performance analysis
The above is the detailed content of Related explanations about object-oriented design. For more information, please follow other related articles on the PHP Chinese website!