End-of-term First Aid Kit for Introduction to Software Engineering (Medium)

Functional requirements define the software functions or services that developers should provide, but do not involve the realization of these functions or services.

Non-functional requirements are supplements to functional requirements, including various restrictions on the system and user quality requirements for the system.

Commonly used analysis methods for needs analysis

Based on the structured method of the waterfall model, the analysis strategy of the structured analysis method is: top-down, layer-by-layer decomposition
A prototyping method based on dynamic definition of requirements
Object-oriented approach: UML is an important tool in software development
Data-based data flow development method
The Jackson method for data structure design gives three structures. Sequence structure, selection structure, and repetition structure
Object-Oriented Requirements Analysis

1 Booch method

2 Rumbaugh method

3 The Coad and Yourdon method

4 Jacobson method

5 Wirfs—Brock method

6 UML's OOA method (current mainstream technologies basically use UML to model, and others are rarely used)

software design

The traditional structured method divides software design into four parts: architecture design, data design, interface design and process design;

Features of structured analysis: top-down, step-by-step refinement

The object-oriented method divides software design into four parts: architecture design, class design/data design, interface design, and component-level design.

Principles for creating a good design

The design should follow the principle of abstraction, including data abstraction and process abstraction

The design should follow the principle of modularity.

The design should follow the principle of information concealment.

module independence

High Cohesion, Low Coupling

Cohesion

Cohesion is a measure of how tightly the elements of a module are combined with each other.

(1) Functional cohesion

All parts of a module work together to complete a specific function, are closely connected and inseparable. Such modules are functionally cohesive modules. Functionally cohesive modules have the strongest module independence.

(2) layer cohesion

Related services are put together and have a strict hierarchy. High-level services can access low-level services, but not vice versa. Such as hierarchical structure.

(3) Communication

Processes that access or manipulate the same data are placed in a class, and these processes can communicate with each other. Such as a class design.

(4) Sequential cohesion

There is a sequence of processes, one of which provides input to another, which, taken together, forms sequential cohesion. Such as message sequences in object-oriented systems.

(5) Process cohesion

Several one-call operations are placed in a module, they are related and must be executed in a specific order, and this module is called a procedural cohesive module. But within such a module, the output of one operation is not necessarily the input of the next operation. Such as call structure.

(6) Gather in time

The operations completed in the same stage during program execution are put together to achieve time aggregation.

(7) Utility Cohesion

Related utilities that cannot logically fit into other cohesion types are put together to form utility cohesion. Such as reusable procedures or classes.

Coupling

Coupling is a measure of how closely connected modules are to each other, and it depends on the complexity of the interfaces between modules, how they are called, and what information passes through the interfaces.

The higher the coupling between modules, the weaker their module independence. The more cohesive a module is, the less coupled it will be to other modules, and the more independent the modules will be.

(1) Content coupling

Modules are content coupled if the following situations occur: one module directly accesses the internal data of another module;

(2) Public coupling

If a set of modules all access the same common data environment, then the coupling between them is common coupling. The public data environment can be global variables, global data structures, shared communication areas, public coverage areas of memory, etc.

(3) Control coupling

Control coupling occurs when one process explicitly controls the actions of another process through flags, switches, or commands.

(4) Label coupling

If a group of modules passes structures or objects (note, not simple variables or components in structures) through parameter tables, it is marked as coupled.

(5) Data coupling

If the access between modules exchanges input and output information through data parameters (not control parameters, structure or object parameters, public data structures), this coupling is called data coupling.

(6) Routine call coupling

Routine call coupling occurs when a program (or an object's operation) calls another program (or another object's operation).

(7) Types use coupling

Typed (nested) coupling occurs when a class declares an instance variable or local variable as an instance of another class.

(8) Include/introduce coupling

Import coupling occurs when a component imports a package, and include coupling occurs when a component includes another component.

(9) External coupling

External coupling occurs when a module has dependencies on external systems, such as the operating system, shared libraries, or hardware. This dependency can be reduced through information hiding.

Various Views and Their Functions in UML

view name	Jurisdiction block diagram	function
use case view	use case diagram	The high-level model of the system is established from the use case level, and the specific implementation of the system is not concerned. Class diagrams, interaction diagrams, state diagrams, and activity diagrams are used to roughly describe the model of the business domain of the system, excluding the interface and service object layers
	Class Diagram
	interactive diagram
	State diagram
	activity diagram
logical view	use case diagram	Establish the implementation model of the system from the class (object) level. Class diagrams, interaction diagrams, state diagrams, and activity diagrams are used to describe in detail the design models at all levels of the entire system engineering, including the interface and service object layers
	Class Diagram
	interactive diagram
	State diagram
	activity diagram
component view	component diagram	Modeling the relationship between various modules, connection libraries or files of the system to be realized
deployment view	deployment diagram	Model the physical deployment of the system to be implemented and its performance requirements

Use Case View VS Logical View

The use case view mainly looks at the system from the outside of the system, describing such as what interface the user logs in, how to log in, and how the system responds, but it does not describe how to authenticate users inside the system; the logical view describes the internal structure of the system, such as how the system authenticates users , there may be a validation class, an authentication control class, etc. (One is the surface of the program, and the other is the inside of the program)

Main Diagrams and Their Functions in UML

( 1 ) Use case diagram: It describes the system functions understood by the actors ( Actors ), and is used in the requirements analysis phase to list the use cases and actors in the system , and to show which actor participates in the execution of which use case .

(2) State machine diagram: By modeling the life cycle of class objects to describe the dynamic behavior of objects over time, it can also be used to describe the dynamic behavior of use cases, collaborations, and methods. It is a diagram that shows states and state transitions.

A state machine is a model of all possible life courses of objects of a class. State machines include state diagrams and activity diagrams.

Activity diagram: It is used to describe the activities to be performed to meet the requirements of the use case and the constraint relationship between the activities, which is conducive to the identification of parallel activities and workflow situations. Activity diagrams are actually tools used to model the flow of events of a use case. The main content displayed is the active state of the object.

Statechart: Used to model the dynamic aspects of the system.

(3) Class diagram: It is an important part of the logical view and is used to model the static structure of the system, involving specific implementation details. In the system analysis phase, class diagrams are mainly used to show the roles and responsibilities of entities that provide system behavior; in the system design phase, class diagrams are mainly used to capture the class structure that makes up the system architecture; in the system coding phase, according to the class diagram Classes and their relationships implement the functionality of the system.

Association relationship: If the member variable in class A is an object declared with class B , then the relationship between A and B is an association relationship

Dependency relationship: If the parameter of a method in class A is an object declared with class B or the data type returned by a method is an object of class B , then the relationship between A and B is a dependency relationship

Generalization (inheritance) relationship: If a class is a subclass of another class, then there is a generalization (inheritance) relationship between the two

Implementation relationship: refers to a class that implements the interface interface

Aggregation relationship: Represents the relationship between objects of a class as a whole and a part

Combination relationship: represents the relationship between the objects of the class as a whole owning parts, and the coexistence of parts and the whole. The whole does not exist, the part disappears with it.

(4) Interaction Diagram: It can be used to model the event flow of a use case, or it can be used alone to visualize, detail, construct and document the dynamic aspects of a specific object group. An interaction diagram shows an interaction, consisting of a set of objects and the relationships between them, including: what objects are required, what messages the objects send each other, what role initiates the messages, and in what order the messages are sent.

There are two types of interaction diagrams: sequence diagrams and collaboration diagrams; sequence diagrams emphasize the time sequence of message sending, and collaboration diagrams emphasize the organizational structure of objects that receive and send messages.

(5) Component diagram: Provide the physical view of the current model, and model the static realization view of the system. Component diagrams show the configuration of classes and objects to which components map when a system is physically designed. The component diagram mainly includes the following contents: components, interfaces, dependencies and component packages.

(6) Deployment diagram: Model the physical aspects of the object-oriented system, and describe the configuration of nodes, component instances and their objects when the system is running. A node is a general name for various computing resources, including two types of processors and devices. The difference between the two is that a processor can execute a program on a hardware component (such as a computer host), while a device is a hardware component that does not have computing capabilities. (like a printer)

Software Development Process and UML Visual Modeling

software development stage	UML usage	UML model diagrams and elements that may be used
Initial stage	Build a business model ( Business Use Case )	business use cases, business actors, business workers
Initial stage	Determine the use case model ( Use Case )	Actors, Use Cases, Relationships
Elaboration stage	Refined use cases	Actors, Use Cases, Relationships
	event flow modeling	Sequence diagrams, collaboration diagrams, state diagrams
	Model the static structure and dynamic behavior of the system	Class diagrams, interaction diagrams, state machine diagrams
	identify system components	Component diagrams, relationships
build phase	Forward engineering generates framework code	Class diagrams, interaction diagrams, state machine diagrams, component diagrams
	Reverse engineering the updated model	component diagram
	create deployment	deployment diagram
delivery stage	Delivering, maintaining and upgrading models	component diagram, deployment diagram

Different from the data design in the traditional method, the data design in the object-oriented design is not carried out independently. The class diagram in the object-oriented design is equivalent to the logical model of the data, which can be easily converted into a physical model of the data.

MVC pattern

That is, the model-view-controller (Model-View-Controller) pattern, which corresponds to the internal data, data representation and input/output control parts, and designs them separately. The process is: first, the controller receives the user's request and decides Which model is called for processing; then the model uses business logic to respond to the user's request and returns data; finally, the controller uses the view to represent the data returned by the model and presents it to the user.

The model focuses on data and functions, the view focuses on data display, and the controller focuses on user input. Its advantage is that data and business rules are expressed separately.

1) Model objects

The model object is the part of the application that is used to process the application data logic . Changes in the model object are notified to the view and controller objects through event processing.

2) View object

The view object represents the GUI object, and represents the model state in the format required by the user, and is the interface between the interactive system and the outside world. View objects can contain subviews, which are used to display different parts of the model. Typically, each view object corresponds to a controller object.

3) Controller object

The controller object represents the event, processes the user's input behavior, sends the business event to the model, and parses it into the action executed by the model. At the same time, the update and modification of the model is notified to the view through the controller, so that each view is consistent with the model.

MVVM pattern

The MVVM pattern improves on the MVC pattern by better separating the view and the model.

The composition structure of MVVM.

a) Model layer (Model): refers to the data model, or refers to the data access layer representing the content. In the architecture where the front and back ends are separated, it can be understood as the data transmitted from the back end to the front end.

b) View layer (View): refers to the user interface.

c) View model layer ( ViewModel ): This layer is mainly responsible for the communication between the Model layer and the View layer and the binding of data and view. Encapsulate and pass the data to the view layer, and pass the behavior and state transformation of the view to the model layer.

MVVM is developed separately from the front and back ends.

The course case is developed using a front-end and back-end separation architecture. In this architecture, the backend corresponds to the Model layer in the MVVM pattern, processes business logic around the database system, encapsulates data (mainly in JSON format) and transmits it to the frontend. The front end corresponds to the ViewModel layer and View layer in the MVVM pattern. The data obtained by the front-end from the back-end is re-encapsulated through JavaScipt code to generate a view data model that meets the expectations of the View layer and display it in the form of a web page. When the view changes, the front-end initiates a request to the back-end through JavaScipt code according to the interface rules agreed with the back-end. The MVVM mode reduces the coupling between modules, and the front-end and back-end separation architecture improves development efficiency.

Design and implementation of information system with front-end and back-end separation (MVVM-based design pattern)

The composition structure of MVVM.
1. Model layer (Model): refers to the data model, or refers to the data access layer representing the content. In the architecture where the front and back ends are separated, it can be understood as the data transmitted from the back end to the front end.
2. View layer (View): refers to the user interface.
3. View model layer ( ViewModel ): This layer is mainly responsible for the communication between the Model layer and the View layer and the binding of data and view. Encapsulate and pass the data to the view layer, and pass the behavior and state transformation of the view to the model layer.

This mode can achieve high cohesion and low coupling

What are the main components of the object-oriented model?

1 The object model describes objects, classes, hierarchies and relationships, and the static structure, whose role is to describe the static structure of the system, including the classes and objects that make up the system, their attributes and operations, and the connections between them . – The object model includes class diagrams

2 The function of the dynamic model is to describe the control logic of the system, which mainly involves the timing and changes of various classes and objects in the system. Timing diagram etc.

3. Functional model describes the functional representation of the system : data flow diagram, use case diagram

What are the basic tasks in the outline design phase?

(1) Design the software system structure (software structure for short), specifically:

① Use a certain design method to divide a complex system into modules according to its functions.

② Determine the function of each module.

③ Determine the calling relationship between modules.

④ Determine the interface between the modules, that is, the information passed between the modules.

⑤ Evaluate the quality of the module structure.

⑵Data structure and database design.

⑶ Write the outline design document. Mainly include: outline design specification; database design specification; user manual; revised test plan. ⑷ review.

What are the basic tasks of detailed design? What are the description methods?

Detailed design is the second phase of software design

Its basic tasks are:

Detailed algorithm design for each module;

Design for the data structure within the module;

Physically design the database, that is, determine the physical structure of the database;

For other designs, depending on the type of software system, code design, input/output format design, and man-machine dialogue design may also be required;

Write detailed design instructions;

review.

Three tools are commonly used to describe the process in detail: graphics, tables, and language. Examples include structured program flowcharts, box diagrams, and problem analysis diagrams. The IPO diagram is also one of the main tools for detailed design. Tabular tools such as decision tables can be used to describe complex algorithms for logical conditions in detailed design. Procedural Design Language (PDL) is a language tool for describing the design and processing details of modular algorithms.

Graphical tools: program flow chart, NS, PAD, HIPO

Form Tool: Decision Form

Language tools: PDL, HIPO

Black box testing (Black_Box testing)

Black box testing regards the program as a black box that cannot be opened. It focuses on testing the functional requirements of the software without considering the internal structure and characteristics of the program . The tester tests at the program interface and only checks the program function. Whether it is used normally according to the specifications, whether the program can receive input data and generate correct output information, and maintain the integrity of the database and files

Methods of designing test cases with black box testing (functional testing) and their respective characteristics

(1) Equivalence class division . Equivalence class division is to divide the input data field into several equivalence classes according to valid or invalid (also called reasonable or unreasonable), and the representative value of each equivalence class is equal to the value of other values of the class. test.

A "salary adjustment" processing module accepts a variable of "professional title", and performs different processing according to the different professional titles (teaching assistant, lecturer, associate professor, professor). Among them, if it is a teaching assistant, the length of service must be entered, and the salary can only be adjusted if the working experience exceeds two years. Please use the equivalence class partitioning method to design test cases.

Divide into equivalence classes:

input conditions

reasonable equivalence class

unreasonable equivalence class

job title

①Professor

②Associate professor

③ Lecturer

⑤ Any one of the four professional titles

Title and length of service

④ teaching assistant and working experience more than 2 years

⑥Teaching assistant and working experience equal to two years

⑦ teaching assistant and working experience less than two years

Design test cases:

Input data

expected outcome

coverage

professor

The input is valid, and the wage adjustment process is performed

①

Associate Professor

The input is valid, and the wage adjustment process is performed

②

lecturer

The input is valid, and the wage adjustment process is performed

③

teaching assistant 3

The input is valid, and the wage adjustment process is performed

④

teaching assistant 2

Enter valid, do not adjust salary processing

⑥

teaching assistant 1

Enter valid, do not adjust salary processing

⑦

engineer

invalid input

⑤

(2) Boundary value analysis . This method takes the test boundary condition as the key target, selects the conditions that are exactly equal to, just greater than or just less than the boundary value, and selects test cases according to these conditions.

(iii) Wrong speculation . There are no definite steps in the wrong guessing method, and it is carried out by inspection. Its basic idea is to list the possible error situations in the program and select test cases according to these situations.

㈣因果图。因果图能有效的检测输入条件的各种组合可能会引起的错误。因果图的基本原理是通过画因果图，把用自然语言描述的功能说明转换为判定表，最后为判定表的每一列设计一个测试用例。

在网络中，sendfile命令用来发送一个文件到不同的服务器。Sendfile有三个变量：变量1是发送者根目录的文件名，变量2是接受文件服务器的名称，变量3是接受方的用户useid。如果所有的变量是正确的，那么文件成功发送，否则给发送者返回一个错误信息。如果原因用1代表变量1，2代表变量2，3代表变量3，结果用100代表成功，101代表返回错误信息，请画出因果图并建立因果关系判定表。

软件测试步骤及这些步骤的测试对象

白盒测试(White-box Testing)

白盒测试又称结构测试或逻辑驱动测试，指通过对程序内部结构的分析、检测来寻找问题。白盒测试把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件的内部动作是否按照设计说明的规定正常进行。