Design of software architecture---based on robust graph

How to use the robust diagram for preliminary design?

The Admems method summarizes the 10 points of experience in the modeling of robust graphs, covering 4 aspects, including grammar, thinking, skill, and attentions.

10 experiences in robust graph modeling.

1. Abide by the modeling rules.

You can understand the nature of the diagram by following 4 statements:

1.1 Participants can only talk to boundary objects.

1.2 Boundary objects can only talk to control objects and participants.

1.3 Entity objects can also only talk to control objects.

1.4 The control object can talk to the boundary object as well as to the control object, but not to the participant.

2. Simplifying the modeling syntax

The 2.1 Admems method recommends the syntax for robust graph modeling. In practice, simplified robust graph syntax will help focus on initial design rather than attention to detail.

3. Follow the discovery idea of 3 kinds of elements

Use cases =n a scene. The implementation of each scenario is the result of a series of responsibilities for collaboration. Therefore, the preliminary design can be done by "studying the different scenarios of use cases, to find out what the different responsibilities behind the scene"

4. Incremental modeling

Examples: Compression tools like Winzip,winrar have been used by everyone. For the "compression" function in the initial design based on the robust diagram.

First, identify the most obvious responsibilities. Yes, that's what you think is the most obvious--don't think that design and modeling have strict answers. If, in your opinion, compression is the process of turning the original file into a compressed package, 3 responsibilities are identified:

Next, begin to consider the relationship between the responsibilities and discover new responsibilities. The compressor reads the original file and eventually generates the compressed package---here you can separate the packager, which is commissioned by the compressor.

Continue the same way of thinking. In the middle of the robust graph, and introduces a compression configuration, which affects the way the compressor works, such as encryption compression, sub-volume compression or other.

The final robust graph is shown in 8-13. Compression also supports the display of compression progress and the ability to cancel half of the compression at any time. So you recognize the responsibility of compressing the travel interface and the listener.

5. Only the key functions (use cases) to draw a robust diagram

Based on the concept of "critical requirements decision architecture", functional requirements are a type of requirement, and there is no need to draw a robust diagram for each feature when designing the architecture.

6. There are 2-5 control objects for each of the robust graphs

Since it is a preliminary design, in the case of robust graph modeling, it is not necessary to control objects in every robust diagram for key functions, and 5 is a common upper limit value. Conversely, if a robust graph that implements a function contains only one control object, it is clearly "inadequate design"-the name of the control object must be the same as the function name, which means that the responsibility is not truly segmented. For example, WinZip's compression function is designed to be a robust graph shown in 8-14, with little meaning.

7. Do not pay attention to the details:

The preliminary design should not pay attention to details. For example

1. Only the object name is identified for each object, and its properties and methods are not recognized.

2. "Current Account Pin user interface", which may be a dialog box, Web interface, character terminal interface, but the robust diagram does not care about these details.

3. Are entity objects such as "customer data" required to be persisted? Do not care, more do not care to use table or file or other means of persistence.

4. There is no strict order to identify the control flow.

8. Do not focus too much on the UI unless you are assisting or validating the UI design.

Overly concerned about the UI, will fall into such as a few windows, whether there is a special result display page and many other details, the preliminary design can not be done.

Don't forget, the goal of the preliminary design is to find responsibility. The preliminary design does not need to unfold the architectural design details, otherwise it will carry the "burden", this is the complex system architecture design starts the taboo.

Design of software architecture---based on robust graph