Use case analysis method

Use case analysis method comes from object-oriented analysis method. Use cases describe the interaction process between users of the system and the system itself, thereby providing a detailed statement of how to use the system and gaining an understanding of the system requirements. Use case analysis is an important technique for obtaining system functional requirements.

In the use case, the user term is actor. The users do not have to be real people. If the system to be developed provides services to another computer system, then the other system is the user of this system.

A use case consists of multiple scenarios. In a use case, all scenarios have the same user goals. It generally includes a main success scenario and several additional extension scenarios. For example, in an online supermarket system, the "shopping process" is a use case. In this use case, the most common user goal is to complete shopping. But this goal may be accomplished successfully, or it may fail for some reason. In this way, there is a main scenario of successful shopping, and multiple scenarios of failed shopping: such as credit card failure, goods sold out, etc.

A complex step in a use case may be another use case. This is the inclusion relationship between use cases.

UML use case diagram focuses on two relationships:

The relationship between users and use cases. That is which use case was initiated by that user.

Relationships between multiple use cases. For example, a use case contains other use cases

Almost all the value of a use case lies in its content. Use case diagrams by themselves are of little value. When you use use cases for analysis, you don't need to focus too much on the use case diagram. You should focus on the text of the use case. This is where the real value of this technology lies.

In addition to simple inclusion relationships, UML also defines many other relationships. But I think that except for the inclusion relationship, other relationships can be ignored. Other relationships offer little value other than causing confusion and complexity.

Never make use cases too complex. Doing too little is usually less harmful than doing too much. If too little is done, a short and easy-to-read document forms the starting point for asking questions. If it were done more, it would be difficult for anyone to read and understand.

Use cases can be divided into system use cases and business use cases according to levels. System use cases focus on the interaction of the software system, and business use cases discuss how a business responds to events from customers.

There is also a more detailed classification method: sea-level use cases, fish-level use cases and kite-level use cases. A sea-level use case describes a complete interaction between the main actor and the system and is not a step in any other interaction process. Use cases included in the sea level are fish level use cases. Higher-level kite-level use cases, kite-level use cases are the above business use cases. If adapted to wider business interactions.

Data flow analysis method

This method comes from the traditional structured analysis method. Use data flow diagrams to describe the system's data processing model.

Note: The data flow diagram depicts the logical model of the system. There are no specific physical elements in the diagram, but it only describes the flow and processing of information in the system.

Data flow diagrams are used in the early stages of analysis and design. The processing in the data flow diagram is a process that exists logically. Do not consider corresponding to any specific software entity at the beginning (do not regard processing as a module ). When the input data and output data are determined, what kind of processing is required to produce output from the input? --Acquire an understanding of the system's functional requirements through this idea. Which software entity will ultimately undertake a process is a matter of the design stage. Ultimately, it is possible that one process is ultimately undertaken by multiple software entities, or it is possible that multiple processes are undertaken by one software entity. It is even possible that some processing is a manual process and ultimately does not correspond to any software entity - which part of the processing is completed manually by the user is also part of the design.

The data storage in the data flow diagram is not an actual physical entity.

The basic point of data flow diagrams is to describe "what to do" rather than "how to do it". The point of data flow diagrams is analysis, not design. Avoid design smells in data flow diagrams.

Many people cannot draw data flow diagrams well because they are in the process of drawing data flow diagrams. Because they think of data processing as modules or objects, and data storage as specific data files or databases.

In addition, do not show branches and loops in the data flow diagram. This will cause confusion and prevent you from drawing a correct data flow diagram. In a data flow diagram, all possible data flow directions should be depicted, rather than the conditions for a certain data flow to occur. --Sometimes you can think of judgment conditions as input data.

Object-oriented and data flow analysis

Whether data flow analysis can be used in object-oriented design is a controversial topic. Most books on object-oriented design methods oppose the use of traditional structured methods in object-oriented methods. Personally, I think it can be used, but it must be used with caution. There are the following reasons:

Data flow diagram involves analysis within the system. The use case analysis method does not involve the internals of the system. When analyzing a system only through use cases, I always feel that the analysis is not thorough enough.

Some systems have data processing as their main task, and the application logic focuses on data processing rather than the interactive process, so use case analysis is not suitable.

Data flow diagrams have been around for a long time, are easy to understand, and are easy to use in communication. Few people use use case diagrams, and many people are unfamiliar with it.

In the object-oriented design method, after using the data flow diagram to analyze, it is necessary to abstract objects on the basis of the data flow diagram. Each element on the data flow diagram: data flow, data storage; external Both entities and data processing may be used to abstract objects.

In a general sense, in object-oriented programs, objects or classes constitute the logical structure of the system. The modules reflect the physical structure of the system. The concept of modules is often related to specific programming languages. For example, in C++, modules correspond to independent compilation units. A compilation unit contains one or more closely related class implementations.

Module is a very imprecise concept. In actual communication, and even in some formal documents, modules may represent any software entity. Especially in the structured design method, modules can be individually named, and any collection of program objects that can be accessed by name, procedures, functions, subroutines, and macros can be used as a module. What should be done about this inaccurate concept? We should be liberated from the narrow concept and "seek its meaning and forget its shape."

But be warned: using data flow diagrams during object-oriented design is indeed dangerous. Pay attention to the following two points:

Use data flow diagrams in the object-oriented design process, and be careful not to fall back on the path of structured design.

The main function of the data flow diagram is analysis, which is to help programmers understand the requirements. Do not let the data flow diagram have the flavor of design.

JACKSON analysis method

The JACKSON method is a complete set of analysis and design methods. Jackson believed that there are three forms of data structures. , sequence, selection and repetition. The three data structures can be nested and combined arbitrarily. Form a complex structural system. The JACKSON method starts with the input and output data structures of the target system, derives the program framework structure, and then adds other details to obtain a complete JACKSON diagram describing the program structure.

In practice, I have not completely used the JACKSON method (in fact, I have not studied this method systematically). I only use JACKSON diagrams during the analysis phase to describe the logical structure of complex data to be processed. I call this method that only uses the JACKSON method for analysis the JACKSON method.

The main idea of ??the JACKSON method is to analyze the complex data to be processed by drawing a JACKSON diagram to understand the requirements.

In addition, in addition to using JACKSON diagrams to complete analysis, I have also used JACKSON diagrams to describe the file structure of complex configuration files. Because the JACKSON diagram focuses on the logical structure of the data, rather than the specific existence form of the data. The format used to design configuration files is quite suitable.

In China Mobile data network management system. I used this kind of diagram to design the data structure of the data conversion configuration file. Finally, the configuration file uses XML files.

Select the analysis method according to the actual situation

Interactive systems: There are complex interaction processes between the system and the outside world, so the use case analysis method is suitable. This is often the case with software or servers with graphical interfaces.

For data processing systems, there may be complex data processing processes, and the system requires complex data processing processes. For such systems, data flow analysis is suitable.

If the data being processed has a complex structure, it is suitable to use data structure-oriented analysis methods. In the same project, multiple analysis methods may be used.