1 Introduction
I have seen too many software that can be called the "three nos", that is, no requirements, no design, and no comments. Strictly speaking, their requirements and designs are actually there, but they are not documented, but the comments are really not there. These softwares are available from large to small, but they all have a common feature, that is, "difficult to maintain".
I chatted with my colleagues a few days ago and heard that a XAML implementation would be rewritten and replaced with a local protocol, and then I would consider compatibility with XAML. Although I haven't seen the code of this project, I know that this project is basically "three noes".
Of course, this situation is also one of the major characteristics of the Three Nothings, that is, after the front foot is left, the back foot is "unintelligible and unable to move." As a result, it is not as simple as rewriting.
From the perspective of employees, of course there is nothing wrong with it, but from the perspective of the company and the product, it is a "meaningless loss".
A programmer who has requirements on himself should ensure that he does not produce the "three noes" project
"Standardization" can solve the "three noes" problem of the project. And this has always been my respect. It happened that some netizens started a certain booking system project, so I also took this example to report my design ideas to everyone, and also serve as a lesson preparation for such courses in my company.
2. About design
The software design process is actually a process of derivation. There are various relationships between each step of the process: either refinement, verification, or supplement.
When I was studying design before, I thought that looking at the textbook, I could design the system step by step based on "top-down" or "bottom-up", but then I found out that I was wrong. I believe that friends who are studying design should also feel this way.
The biggest difference between a computer and a human brain is that the former is a linear system, while the latter is a non-linear system. The so-called non-linearity, in a popular point of view, is to turn one's heads upside down and open the bow from left to right. In terms of literature and art, it pays attention to the "spiral upward". In short, it means the "mechanical" "one-time" action. The human brain is not good at it, of course, except for genius. .
The same is true for design. It is originally the processing result of the human brain, so its process is bound to be non-linear. A design method, in order to be easy to learn and accept, it must itself be a mechanism that includes a "spiral" improvement, which is Deminghuan's PDCA process (Plan-Do-Check-Adjust), but in the design process The factors of Plan are not obvious, mainly the process of DCA.
In the process of system design, the biggest feeling is not to limit yourself. I remember that in order to complete the design and meet the "top-down" requirements, I deliberately restricted myself not to think deeply, and the result was of course a failure.
Of course, "restrictions" are not only the limits of the thinking level just mentioned, but more importantly, they break the limits of tools. All tools will limit thinking and even work progress.
So far, the best design tools are still "pencil with eraser" and "paper", so you should make good use of it.
3. Demand
A certain ticket booking system is currently the most well-known and recognized website with poor human-computer interaction experience. How to make a better system than it? The answer is "design more carefully."
Before designing "more carefully", we need to collect requirements "more carefully".
The demand of software is the "purpose" that the software wants to achieve.
Don’t mention “requirements” as “requirements documents”. Documents are just a form of expression of requirements. Another common form of expression is the memory in the brains of programmers.
Crappy programmers often pass requirements through their mouths. They would rather take the trouble to say them over and over again, rather than spend a little time writing them all at once. They can’t stand the customer’s changing requirements again and again, but they don’t care about what they say every time. The same demand is a bit out of shape.
3.1. The first step: use case layering
Here we use UML use case diagrams (UseCase) to represent requirements.
The use case diagram is also described hierarchically. The top-level use case diagrams (zero-level use cases) of all systems are similar. They are all a circle surrounding many roles. The difference is how many roles there are and the words written in the circle are different.
This time we wrote "a ticket booking system" in our circle, and there are only two peripheral roles: user and administrator.
The first-level use case diagram is completely different. I divided it into 7 parts. The first-level use case name and the second-level use case names contained in it are described as follows:
- User management: registration, login, logout, password retrieval, information view, information modification, user verification, user query
- Inquiry: timetable, remaining tickets, connection planning, delay
- Order: place an order, cancel an order, modify an order, order query, make a reservation
- Ticketing: ticket booking, ticket collection, change, refund, ticket query
- Funds: payment, refund, check arrival, bank reconciliation
- Ticket pool: ticket entry, ticket issue, ticket pool query, ticket pool modification
- Maintenance: parameter setting, dictionary maintenance, topology management, log query, backup, recovery
The above list is for the convenience of everyone to read. In fact, I also use this outline to think. Then supplement the picture as follows:
Of course, the above part is neither the initial state nor the final state, but my current state after many adjustments and improvements, and will be further adjusted according to the analysis in the future. In addition, everyone must note that the use case representation of a system is not unique, and the use cases given by different people are different, but in theory they should be equivalent.
Each part of the use case diagram must be real and customer-oriented. The smallest unit it describes should be a business module.
The criterion for judging use cases is "business significance". The so-called "business significance" means that after the completion of the business module, the entire business or business process can be pushed forward. The result of this "promotion" should include the role change or goal The change.
From the above definition, "funds. Query to account" and "ticket pool. lock tickets" may not be a use case. Up to the time of writing this article, I still hesitated, but later decided to exclude them because they have no externally related actors, although it is true that these two use cases can push the business forward.
From this, I have also learned that it is best not to have an actor as an internal module or system in the first and second use cases.
Software testing exchange group: 785128166
WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"
Next update: Test case of stool
Here is a collection of selected dry goods articles for functional testing: