Software Architecture Design-design based on robust Graphs

How can we use robust graphs for preliminary design?

The admems method summarizes 10 key points of robust graph modeling, covering four aspects: syntax, thinking, skills, and precautions.

10 pieces of experience in robust graph modeling.

1. Follow modeling rules.

The following four statements can be used to understand the nature of the graph:

1.1 participants can only talk to border objects.

1.2 The boundary object can only talk to the control object and the participant.

1.3 entity objects can only talk to control objects.

1.4 The control object can talk to both the border object and the control object, but cannot talk to the participant.

2. simplified modeling syntax

2.1 The admems method recommends the syntax of robust graph modeling. In practice, the simplified robust graph syntax will help you focus on preliminary design, rather than focusing on details.

3. Follow the discovery ideas of three elements

Use Cases = n scenarios. The implementation of each scenario is the result of a series of responsibilities for collaboration. Therefore, the preliminary design can identify the different responsibilities behind the scenario by studying different scenarios of case execution.

4. incremental Modeling

Example: We have used compression tools like WinZip and WinRAR. Perform a preliminary design based on the robust graph for the "compression" function.

First, identify the most obvious responsibilities. Yes, that is, what you think is the most obvious responsibilities-do not think that design and modeling have strict standard answers. If you think that compression is the process of converting the original file into a compressed package, you have identified three responsibilities:

Next, consider the relationship between responsibilities and discover new responsibilities. The package reads the original file and generates a compressed package. The package can be independently generated. The package is commissioned by the compressed file.

Continue with the same way of thinking. The intermediate results of the robust graph introduce compression configuration, which affects the working methods of the compressors, such as encrypted compression, Volume compression, or other.

The final robust diagram is shown in Figure 8-13. The compression function also supports displaying the compression progress and canceling the compression at any time. Therefore, you have recognized the responsibilities of compressing the traveling interface and listener.

5. Only draw robust diagrams for key functions (Use Cases)

Based on the concept that "key requirements determine the architecture", functional requirements are a type of requirement, so you do not have to draw a robust Diagram for each function when designing the architecture.

6. Each robust graph has 2-5 control objects.

Since it is a preliminary design, in robust graph modeling, the control objects in each robust graph with key functions do not need to be too much or too small. Five are common upper limits. On the contrary, if only one control object is included in the robust graph to implement a function, it is obvious that "the design is insufficient"-the name of this control object must be the same as that of the function, this means no real splitting of duties. For example, it makes almost no sense to design the WinZip compression function into a robust diagram shown in 8-14.

7. Do not pay attention to the details:

Preliminary Design should not focus on details. For example,

1. Each object only identifies the Object Name and does not recognize its attributes and methods.

2. The "current account sales interface" may be a dialog box, Web interface, or character Terminal interface, but the robust diagram does not care about these details.

3. Do object objects such as "customer data" need to be persistent? Don't care, not to worry about using table or using file or other methods for persistence.

4. There is no strict order for marking the control flow.

8. Do not focus too much on the UI unless you assist or verify the UI design.

If you care too much about the UI, there will be several windows, whether there is a special Result Display page, and many other details. The preliminary design won't work.

Don't forget. The initial design goal is to discover responsibility. The preliminary design does not need to expand the architectural design details, otherwise it will carry a "burden", which is a taboo in the beginning of the complex system architecture design.