Structure drawing in software development-software development, software engineering, project management

The structure diagram proposed by Yourdon is another powerful tool for software structure design. A structure diagram is similar to a hierarchy diagram, and is also a graphical tool for describing software structures, in which a box represents a module with the name or main function of the module; the arrow (or line) between the boxes represents the calling relationship of the module. Because the formula is always the module at the top of the module call in the diagram, even without the arrows does not produce ambiguity. For simplicity, you can use a straight line instead of an arrow to represent the calling relationship the module asks.
In a structure diagram, you typically also use annotated arrows to indicate the information that is passed during a module call. If you want to further indicate whether the information being passed is data or control information, you can distinguish it by the shape of the tail of the annotation arrow: the tail is a hollow circle that conveys the data, and the solid circle represents the control information. Figure 4. 8 is an example of a structure diagram.

This is the basic symbol of the structure diagram, which is the most commonly used symbol. In addition, there are additional symbols that can represent the selection call or circular call of the module. Figure 4. 9 means that module A is called when a decision in module M is true, and module B is called when false. Figure 4. 10 represents the module M loop calling modules A, B, and C.

Note that hierarchical and structural diagrams do not strictly represent the order in which the modules are called. Although most people are accustomed to drawing modules from left to right in order of invocation, there is no such provision, and for other reasons (for example, in order to reduce the intersection line), it is entirely possible to not draw in this order. In addition, hierarchy and structure diagrams do not indicate when the underlying modules are called. There are usually other statements in the upper module, in addition to the statements that call the underlying module, whether to execute the statement that calls the underlying module first or to execute the other statements, which are not indicated in the diagram. In fact, the hierarchy and structure diagram only indicate which modules a module calls, and there are no other components in the module that are not represented at all.

    typically use a hierarchy diagram as a document that depicts a software structure. A structure chart is not a good fit for a document because the amount of information contained on the diagram is sometimes less clear. However, it is a good method to check the correctness of design and the independence of the module by using the information from the IPO map or data dictionary to get the information from the module call, and then the process of the structure diagram is derived from the hierarchy diagram. Each data element that is transmitted is necessary to complete the function of the module, on the contrary, every data element required to complete the function of the module is transmitted, and all data elements are only related to a single function? If you find that the links between the modules on the chart are not easy to interpret, you should consider whether there is a design problem.