1. Overview of system design

1.1 Overview of system design

design and abstraction

System behavior drives the design

object-oriented design

System data driven to complete the design

operations-oriented design data-oriented design

The design is mainly divided into three steps:
Outline design: receive the required documents and complete the decomposition of modules
Detailed design: design its internal details (algorithms, data structures, variables, etc.) according to the decomposed modules

module

(A module is a lexically contiguous sequence of program statements, scoped by boundary elements, with an aggregate identifier)

Semantic adjacency consists of program statements.
There are signs of start and end, that is, there is a boundary.
It has an aggregation identifier.

High Cohesion, Low Coupling

1.2 Module Cohesion

accidental cohesion

A module performs multiple completely different functions without any logical relationship

Certain regulations dictate that each module must be of a certain size

Decreased maintainability
Difficult to reuse

least cohesive

solve:

complete functional division

logical cohesion

A module can perform many related operations , the cohesion of the selection is made by the calling module

There is a problem that the interface is difficult to understand.
Modifying the content of a module can easily affect other modules

Difficult to reuse

Gather in time

The execution of many operations is time-related and illogical (actions are time-sequenced, not logical-sequenced)

The internal correlation of the module is relatively weak, and the external correlation is relatively strong
Poor reusability of software modules

solve:

complete functional division

Process cohesion (cohesion is higher than the first three)

Many operations have a logical sequence (if the order is reversed, the function cannot be realized)

The action relationship is not very strong
and the reusability is poor

correspondence

Perform a series of operations, related to the order in which the product is to be performed, and operate on the same data

poor reusability

functional cohesion

Execute only one operation, or complete only one function

The possibility of reuse is the greatest.
It is relatively easy to perform corrective maintenance.
It is easy to realize product expansion.

Information cohesion (highest ideal cohesion)

Many operations, each with its own entry. Each operation has its own code, and each operation is based on the same data

insert image description here

1.3 Module Coupling

content coupling

In two modules, the content of one module directly refers to the content of the other module

Modification of one module will cause changes of two modules, increasing maintenance cost

public coupling

Two modules access the same global data at the same time

question

Boundary impact, concurrent impact and control impact, difficult to maintain

When maintaining the global variables of a module, it will affect other modules

Difficult to reuse in new target systems

make boundary effects unclear

lead to computer crime

control coupling

Two modules, one module transmits control elements (simple information or control information-action instructions) to the other module

The two modules restrict each other and influence each other, and their independence is poor.
A module must have logical cohesion

tag coupling

A data structure is passed between two modules, and the calling module only operates on a part of the data structure

Unclear, the name of the data structure passed cannot determine what information is used
Difficult to maintain
and low possibility of reuse
Excessive data passed

data coupling (ideal)

All parameters of the two modules are the same data items (all data items in the passed simple parameter or passed data structure are used)

1.4 Operation-Oriented Design

The early data flow chart must be able to describe the operation in detail

Transformation type (judging the two highest abstraction points from the data flow diagram to obtain logical input, logical output and logical processing)
Transactional (decomposed into transaction analyzer and transaction dispatcher)

1.5 Data-Oriented Design

First determine the data structure and then determine the product structure

Jackson

Data structure representation (in the way of Jackson graph)
Find out the relationship between the input data structure and the output data structure (there is a direct causal relationship, which can be processed at the same time || For repeated data, the order and number of repetitions must be the same to have a corresponding relationship)
Draw the processing frame according to the input and output data structure (if the levels are different, follow the design of the lower level)
List all operations and conditions,
And mark the location of the program structure diagram
Described in pseudocode

2. Detailed design of the system

Determine the algorithm and data structure used in each module,
design the external interface and user interface,
express in detail with a certain expression tool