more subtle gains
Written in front of the front The drawing of this blog uses: Baidu Brain Map , ProcessOn (part of the legend has already published the template).
write in front
This time, I want to write some unreal things in front of this writing - demand analysis. There may be classmates who started writing requirements analysis documents after writing the code like me. I was "forced by life" because the estimation of the workload is not accurate enough, and I don't know how much time I can complete the code construction. work, so choose to write code first. But if you have enough experience and time, it may be a more reasonable choice to do a needs analysis first. Here we take the 7th assignment as an example to try to analyze the benefits of doing a requirements analysis first.
Performance Requirements for System Operation
time precision
Systems involving time need to consider time accuracy when analyzing performance requirements. It can neither be completely real-time (a general real-time system refers to a system whose processing frequency is above a certain value, and perfect real-time cannot be achieved at present), nor can it completely ignore the time problem (the correctness of the system may be based on the time series relationship). On the other hand, the processing frequency of the demand system is directly related to the performance of the demand system. Therefore, it is necessary to determine within what time precision the system is guaranteed to be correct.
Abstractly, this system is mainly a bridge to communicate two types of objects: one is the user who needs a car, and the other is a taxi. The time precision requirements of this system are mainly based on the minimum time for state update of these two types of objects, which is analyzed here (representing users with requests).
| Status update item | Update minimum time |
|---|---|
| vehicle | 200ms |
| ask | 100ms |
The time required for the vehicle to move from one vertex to another vertex connected to it around it is 200ms, and the length of time for the vehicle state to maintain: 20s, 1s, etc. are all multiples of 200ms. After inquiring , we learned that the detailed state of the vehicle within 200ms of movement is not within the scope of demand. Here we consider 200ms as the minimum time unit for vehicle update.
The time precision of the request is clearly 100ms. Further inquiring about the requirements shows that 100ms is mainly used to determine whether it is a homogeneous instruction. If the requested closing time conflicts with the vehicle status update time, that is, when all waiting taxis are in the process of moving at the time of requesting closing, the window is requested to close, since the detailed information of the vehicle's movement within 200ms cannot be determined, you can choose to move at all vehicles. Dispatch orders after completing the journey, or choose to judge according to the status information of the vehicle before departure from the previous node.
To sum up, 200ms will be selected as the time precision requirement of the system, that is, after each trigger state update, all operations related to the current state should be completed within 200ms.
task size
How large-scale tasks the system needs to support in the same time slice is also an important part of system performance requirements.
The task scale is also analyzed from the two types of objects.
In a time slice (200ms), the system should support the following tasks:
| task name |
|---|
| Update taxi status |
| Request an update to the preemption list |
| Allocate a taxi |
| shortest path planning |
The scale of the task of updating the taxi status is fixed, and the task complexity depends on the method used to transfer the status of the taxi. The scale of the update request list is very flexible: from 0to 6400×30. The scale of allocating taxis also has great flexibility. In order to complete the assignment task in a time slice, an upper bound of the number of times to traverse the taxis is 6400×100. In the same time slice, there may be 100a shortest path planning requirement. Within 200ms, without the necessary initialization, it is difficult to complete these tasks with the operating efficiency of Java. Therefore, the system needs to perform the necessary initialization to improve the runtime performance, or use the operation cache thread to slowly climb the system performance.
Interaction analysis
The requirements of the assignment are basically the standard routines that lead us to modeling in UML.
This system is a simulation system, and the interaction analysis can be divided into two levels, one is the analysis in the sense of simulation, and the other is the interaction analysis in actual use. Here, we mainly conduct in-depth interaction analysis in the sense of simulation.
interactive relationship
Here, the project requirements will be analyzed using the UML Unified Modeling Language .
The external interaction analysis will be based on the use case diagram .
Here, passengers and taxis are regarded as the external interaction objects of the taxi distribution system, and the interaction relationship is shown in the above use case diagram. The oval-shaped graphic in it represents the use case, even the events where the roles are related. This distribution system mainly needs to solve these three events and the relationship shown in the use case.
In fact, taxis are also a part of this system and do not belong to external roles, but in order to better show the relationship between roles (passengers) and this system, taxis are also analyzed as external roles here.
interactive action
The interactive action analysis here considers the taxi distribution system and the taxi as a unified system (the "system" in the table below refers to the unified system).
| serial number | Initiator | recipient | interactive action name | describe |
|---|---|---|---|---|
| 01 | passenger | system | Make a ride request | Contains information such as departure location, destination location, etc. |
| 02 | system | passenger | Go to departure point | The system assigns a taxi to the trigger location to pick up the passenger |
| 03 | system | passenger | go to destination | Taxis transport passengers to their destination |
Data
The passenger sends a request, that is, the requested data is passed into the system. From the data point of view, the interaction at this stage is explicit. For the system, the incoming data is uncontrollable and unknowable in advance. The data generated after the taxi arrives at the departure point to pick up the passenger and send the passenger to the destination is internal to the system (the taxi sends data to the distribution system), and the data interaction with external passengers is implicit, but it can be recorded by logging. , showing the interactive actions at this stage through the status information on the side.Time
The time when a passenger generates a request is unpredictable within the system, and the time for subsequent interactions to the departure point and to the destination point is predictable by the system.
Object Recognition and Construction in the System
- incoming data class
FileInputHandler is mainly responsible for reading and initially parsing the map information saved in the file. ConsoleInputHandler is mainly responsible for processing the data from the console, among which there is an external method run for the corresponding input of the new thread.
- request class
The Request class abstracts the request information input to the system, and further can be said to abstract the customer's specific demand information. CRRequest inherits from Request and is mainly responsible for parsing CR requests and related operations related to CR request characteristics.
The RequestList manages the requests that have been entered into the system so far. The same requestList object is referenced in ConsoleInputHandler and Scheduler to implement message passing between multiple threads.
- Scheduler class
The Scheduler is responsible for updating the order grab list (goThroughRequest) for each Request, and after each Request closes the order grab window, constructs a taxi selection order according to certain rules, and tries to get the taxi order grab (trySendRequest) in sequence.
- Taxi
The Taxi class implements the underlying functions of taxi navigation, driving, order taking, and state transfer. The interface TaxiOperation abstracts and shields the functions of taxis in all directions, so that the TaxiHandler taxi cluster management class can operate taxis based on the abstraction. TaxiStatusPackage abstractly manages taxi information and implements functions similar to creating snapshots.
Concurrency analysis
taxi
Generally, a single-computer program (non-distributed program) should not use too many threads: the actual computing resources are limited, and the hardware does not support too many threads at the same time, and the switching of threads brings additional overhead.
After analyzing the algorithmic complexity of the implementation details of the program, I think it is not appropriate to open a thread for each taxi. One thread can be used to manage all taxis in a unified manner, so that it is too late and will not bring additional overhead. .
- GUI
GUIs often take up more computing resources, and a single thread should be opened to implement the update operation of the GUI.
- Input
The speed of the input response is a key factor affecting the user experience, so a new thread is also opened to complete the corresponding work on the input. - Scheduler
The information required for the scheduler to run comes from the update operation of the taxi management thread, which should follow the taxi update operation in time sequence. However, the taxi management thread needs to set the GUI after updating the status. This part can be performed in parallel with the scheduler, so here a single thread of the scheduler is opened for management.