Use case driven design
introduction
Use case-driven design is one of the methodologies for effective software engineering design. The whole process is divided into five stages: demand acquisition, demand analysis, system analysis, system design, coding realization, and test delivery. Each stage is interlocked to form an iterative cycle.
1 Demand acquisition
The entire requirement acquisition stage can be divided into four parts: preliminary exploration, business acquisition, refinement rules, and acquisition of non-functional requirements.
1.1 Preliminary preparation
In the early exploration, we must first understand the current business status of users; then explore the user's business goals; and finally explore the expectations of the business-related stakeholders for the system. After understanding the current situation of the business, formulating business goals that can more impress consumers is the key to the success of the project. For R&D projects of custom products, digging out business goals and stakeholders is the key to the successful positioning of the product. In addition, business goals are also the starting point and boundary of the subsequent use case analysis.
1.2 Obtaining business
The entire acquisition business includes four steps: discovering business use cases and business protagonists, discovering business use case scenarios, discovering business use case realizations, and discovering business use case realization scenarios.
- Exploring business use cases and business protagonists
Set boundaries around business goals to discover business use cases and business protagonists. The entire process needs to output a business use case view and a business actor view presented in two dimensions: business goals and business actors . - Explore business use case scenarios
Explore the business process of each business use case , and output business use case scenario views in the form of activity diagrams with participants and business workers as swimlanes . Regarding whether the process belongs to a branch of a scene or an independent scene, it is generally an independent business for the user. Even if the two scenes have many processes consistent, they must be regarded as an independent business scene.
In addition, this stage also needs to output business use case specification reports , including pre-conditions, post-conditions, executors, main processes, branch processes, abnormal processes, business rules, business rules, etc. - Discover business use case realizations Output a business use case realization view
for each business use case scenario . - Explore business use case realization scenarios
. Sort out more detailed business processes for each activity in the business use case scenario activity diagram corresponding to the business use case realization , and output the business use case realization scenario view ; the view uses the salesman and the computer as the swimlane, according to the activity diagram. Present. In addition, you can also output a timing diagram as a supplement.
Finally, use the domain package diagram to classify and archive the above views. The classification methods are based on business modules, business goals, business processes, and business departments. In addition, business use cases focus on business rather than realization, and there should be no computer-related technical terms; business use case realization can have computer-related concepts, but cannot go deep into the internal logic of the computer.
1.3 Refinement rules
Business is to explain what the system can do for users, and business rules are to explain what users want the system to do. The rules are divided into global rules, interaction rules and intrinsic rules.
- Global rules
Global rules are binding requirements for the entire system. Need to be exported to the supplementary statute . - Interaction rules
Interaction rules are constraints on business use cases and need to be output to the previous business use case specification report . The pre-conditions, post-conditions, and business rules are all interaction rules. - Intrinsic rules
Intrinsic rules are constraints on business objects. For example, in an employee management system, an employee's phone number must be 11 digits. Need to be output to the following business object description document .
1.4 Obtaining non-functional requirements
Non-functional requirements refer to the features that the system meets the user's business functions, including security, reliability, interoperability, robustness, etc. For each non-functional requirement, a non-functional requirement report needs to be output .
2 Demand analysis
The entire requirements analysis stage can be divided into three parts: domain analysis, conceptual analysis, and establishment of business architecture. Both domain analysis and conceptual analysis finally output the final model view through the analysis model.
2.1 Domain analysis
The goal of domain analysis is to build a domain model. More precisely, it is to define appropriate business objects to satisfy the preceding business use cases.
There are many methodologies for domain analysis, and the most common domain analysis steps are as follows:
First, list the problems one by one. Then analyze, model, and verify each problem.
- Ask a question
raised the issue can be said to advance a list of issues, systematic thinking of architects, global thinking, forward-thinking high requirements. If a key issue is missed, it is very likely to cause immeasurable risks in the later stage. - Analyzing the problem
Analyzing a problem is to dig out a domain model, and this process is like solving an equation. The unknown is the domain object, the equation is the object interaction scene, and the final solution is the domain model. To find the domain model is to find the basic objects that constitute the business system. - Establishing the model
After analyzing the problem, the domain object model is established, and then the domain model view is output in the form of entity object diagram . - Validation model
Substitute the established domain objects into the business use case realization scenario to verify whether the established model meets the business requirements. Participants and domain objects are used as interactive objects, and the domain object scene view is output as a sequence diagram .
2.2 Concept analysis
Conceptual analysis is to establish a conceptual model to provide a foundation for system analysis and design. The domain model is mainly for technical issues, while the conceptual model is only for business. The whole concept analysis steps are as follows:
- Defining the core business process
conceptual model is more precise than precise. Many of the business models established through the requirements acquisition phase may be redundant, so it is necessary to sort out the core business that supports the user's business, and then output the main line view of the core business and present it as an activity diagram. - Mining conceptual use cases
Find the key business use cases for each activity in the core business line. At this time, it is possible that multiple business use cases are related to a certain activity in the core business line, so only common and typical business use cases need to be found. Finally, the key business use case view is composed .
In each key business use case, find the links that are closest to the core business line. These links are the conceptual use cases of the key business use cases, and output the conceptual use case view . - Organize conceptual use case scenarios
Output a conceptual use case scenario view for each conceptual use case . - Sort out key business objects
According to the conceptual use case scenario, sort out the key business objects participating in it, and output the key business object view , that is, the conceptual model. Key business objects can include domain objects established in the domain analysis phase. - Sort out the business object scene
Substitute the established business object into the conceptual use case scene to verify whether the conceptual model is reasonable, and output the key business object scene view . The view takes participants , business entity objects , system boundaries , control objects , and engineering flow controllers as interactive objects.
2.3 Organize business structure
The previous business use case model explains the business details, the domain model provides solutions to business problems, and the conceptual model provides the business skeleton. The establishment of a business architecture is an in-depth analysis of requirements, abstracting relatively independent business modules, and forming self-consistent business components. .
There is no uniform method for organizing business architecture, which mainly tests the abstract thinking and boundary thinking of the architect. But generally start with a conceptual model. Finally, the core business architecture view is output in the form of a component diagram . In addition, it is necessary to present the analysis classes contained in each business component in the form of domain package diagrams.
3 System analysis
Requirement analysis takes the business as the center to analyze and establish the business architecture, then the system analysis phase will analyze and establish the system architecture around the system as the boundary. The business architecture is the jigsaw unit, and the system architecture is the jigsaw method. The whole system analysis stage can be divided into four parts: discovering system use cases, designing business rules, sorting out the realization of system use cases, and designing system architecture.
3.1 Discovering system use cases
The entire process of discovering system use cases consists of three steps: discovering system use cases, sorting out system use case scenarios, and sorting out system use case specifications.
- Discovering system use cases Perform in-depth analysis of the corresponding business use case scenarios
for each business use case, and discover system use cases by means of mapping, abstraction, merging, splitting, and deduction. This is a transition from business requirements to system requirements. Output system use case view . - Sorting out system use case scenarios
Sort out the system workflow for each system use case, and output the system use case scenario view in the form of activity diagrams with participants and computers as swimlanes . - Carding system use cases the statute
Finally, we need to sort out the use cases for each system system use case specification statements . Like business use cases, it includes pre-conditions, post-conditions, executors, main processes, branch processes, abnormal processes, business rules, business rules, etc.
The difference between system use cases and business use cases is that the system use cases revolve around the abstract process of how the system implements the business, but do not go into the specific implementation details; while the business use cases revolve around how the user completes the business and do not involve the system boundary.
Compared with the realization of business use cases, system use cases include computer terminology in the business use case realization scenarios, but do not go into how the computer realizes the business; however, the system use case scenarios include the abstract process of how the computer realizes the business functions.
3.2 Design business rules
Design rules are to extract common rules in the system, and embrace changes in requirements by abstracting a unified design. The global rules, interaction rules, and intrinsic rules are designed hierarchically and presented in a design-based way.
- Global rules
Global rules are effective for the entire system, and it is relatively high risk to the system to be handed over to the engineer. Therefore, the program design must be given in the system analysis stage. For example, the log system needs to be used for each module, and how the log system divides the log record level, log switch, etc., must be finalized by the system analysis stage. All global rules output the global rule design view in the form of design class , and output the global rule realization view in the form of object sequence diagram for all operations of the global rule . - Interaction rules
Interaction rules act on system use case scenarios. It is also necessary to design an interaction rule design view during the system analysis stage , and output the interaction rule realization view in the form of an object sequence diagram for all operations of the interaction rule . Usually, it is also necessary to design a management library for all delivery rules, and the output includes an interactive rule management design view and an interactive rule management implementation view . - Intrinsic rules
Intrinsic rules only affect a single business object, and the scope of influence is relatively small. In theory, it can be determined by the engineer himself. For example, the previous phone number has an inherent rule of only 11 digits. When the information is entered, the phone number that is not 11 digits will be prompted when coding! However, I personally think that it is necessary for architects or senior engineers to provide a rule engine or choose a general rule matching library to provide developers with lower development costs.
3.3 Carding system use case realization
The whole process of combing system use case realization is divided into three steps: discovering system use case realization, combing system use case realization scenarios, and sorting system use case analysis model.
- Exploring the realization
of system use cases Analyze the possible realization of each system use case and output the system use case realization view . For example, in the employee management system, the system use case of entering employee information may be realized by two system use cases of single entry and batch entry. - Sort out system use case realization scenarios
. Output system use case realization scene views for each system use case realization . - Sorting out the system use case analysis model
Sorting out the system use case analysis model is relatively more complicated. First, the system use case realization scenario is combined with the domain model and the conceptual model, and the entity objects in the scene are sorted out. If they are insufficient, they need to be defined and supplemented; second, the control object is defined to manipulate the data of the entity object, and the system interaction is the boundary object; then, Output the system use case realization interactive view of each system use case . Finally, the related interactive views are sorted and merged into the system use case analysis model view of each system use case .
The system use case realization interactive view uses entity objects , boundary objects , control objects , rule management libraries , workflow engines, and business protagonists as interactive objects, and is presented in the form of sequence diagrams; the system use case analysis model view is presented in the form of analysis class relationship views.
3.4 Design system architecture
The process of designing the system architecture is divided into three steps: designing the architecture model, verifying the architecture model, and designing the component model.
- Design architecture model
After technical selection and establishment of the business architecture, the macro architecture of the design system (that is, the breadth perspective) Output the system architecture breadth view in the form of package diagrams . For the introduced framework, standard documents and programming model examples should be given ; in particular, if it is a self-developed framework, the framework design implementation ( design class diagram and interaction diagram ) should also be given . - Verify the architecture model
Combine the system use case realization scenarios and the system use case analysis model , analyze the realization of the system use cases at each level of the architecture breadth perspective, output the system use case in-depth interactive view and the system use case in-depth perspective analysis view ; finally, sort out the system use case analysis model View .
The system use case depth perspective interactive view is output as an interactive diagram, and the system use case depth perspective analysis view and the system use case analysis model view are output as an analysis class relationship diagram. In addition to the entity objects , boundary objects , control objects , rule management library , workflow engine, and business protagonists in the realization phase of the combing system use case, all the diagrams also include design objects in the architecture model . In addition to verifying the rationality of the architecture design, this process also substitutes the architecture model into each system use case implementation scenario and outputs a deep perspective. - Split business domains
Map the business architecture established above to domain functional modules, and design reusable functional components that realize all system use cases. Output the system component relationship view and the system component deployment view , and organize the system use case component interaction view of the component to complete the system use case function . If the architecture model is divided according to the level of the system, and the system component model is divided according to the business domain, the two dimensions are indispensable. Similarly, it is also necessary to present the analysis classes contained in each system component in the form of a domain package diagram.
4 System design
The whole system design stage can be divided into two parts: the establishment of the design model and the establishment of the development view.
4.1 Establish a design model
The process of establishing a design model is divided into two steps: analysis model transfer to design model and data entity design.
- Conversion of analysis model to design model
For each system use case analysis model, the system use case design model view is mapped out and presented as a design class diagram. Then output the system use case design interaction view for the interaction process of the design model view , and present it as an interaction diagram. - Data entity design
Data entity design is to model the data entity objects in the design model, including cached data entities and persistent data entities. Export data model views in ER diagrams or other ways .
4.2 Establish a development view
Establishing a development view is to implement the previously established system architecture into development, which is mainly divided into two steps: dividing the development boundary and designing the boundary interface.
- Divide the development boundary
According to the business architecture and system architecture established above , divide the functional components of the development phase, and output the development architecture view in the form of package diagrams . In addition, it is necessary to archive the design model and data model established in the previous stage for each package in a separate view. - Design boundary interface
Design boundary interface is to refine the development boundary divided in the previous stage to make it clearer and make subsequent coding smoothly and parallel. Output the module interface design view in the form of design class diagram for each function package . In addition, it is necessary to clarify which specific interfaces each function package depends on.
5 Coding implementation
The entire coding realization phase can be divided into two phases: contract development specification and execution coding.
- Conventional development specifications
Conventional development specifications include formulating coding specifications, agreed development languages, compiler versions, tripartite library versions, code warehouse management, and so on. - Execution coding
Since clear functional boundaries have been defined above, the development process will be carried out in parallel. At this stage, the functional implementation needs to be written with the design model as a reference, and module unit tests need to be written. In addition, it is possible that an efficient member has completed the function ahead of time, but the function that is dependent on another member has not been developed yet. At this time, it is also necessary to write fake code for the dependent module for loopback testing.
6 Test delivery
In the testing phase, the system use case is used as a benchmark, and black box testing is carried out until all functions are normal. During this process, there will be situations where BUG is modified. Therefore, in order to avoid the recurrence of the previously fixed problems caused by the correction of new problems, it is necessary to do a regression test of all functions for the last time, and all the smooth tests can be passed before it can be officially delivered.
to sum up
Whether it is use-case-driven or domain-driven, an architectural model needs to be established in the end. Although the starting point is different, the end point is the same; domain-driven emphasizes designing with the domain model as the center, while use-case-driven analysis needs to be centered on the use case.
The use case drive requires the architect's business and system analysis capabilities to be very good. As the saying goes: encountering bronze will result in functional realization; encountering the king, it will be realized with a high level of architecture. Because the use case drive is more dependent on the personal ability of the architect, there is not so much experience to learn from the domain drive, which is the reason why many companies adopt the domain drive. If domain-driven is to learn from and carry forward accumulated domain experience, and use-case-driven is to invent and explore new domain experience.
For some areas where there is no mature solution, it is necessary to iterate out the domain model through the use case drive. The initial domain-driven model is generally iteratively driven by use cases. Even if you are domain-driven from the beginning, then you must be the first person to stand on the shoulders of the mature domain experience accumulated by the company or predecessors. It must be thankful.
sublimation
For the first six processes, in fact, they can be streamlined according to actual conditions in engineering practice. Take R&D basic middleware as an example:
In addition to the preliminary preparations, other steps can be omitted at this stage;- The analysis phase
can combine the two phases of demand analysis and system analysis into one; - System design At
this stage, you can omit the establishment of a design model according to the project situation, and only retain the establishment of a development view; - Coding test
No need to think about it, these two stages are essential.