This April, multi-threaded elevator, IFFF file management, taxi series of jobs - version1. (Ghost knows what I have experienced...)
Needless to say, none of the three jobs are fuel-efficient lamps (white eyes). Let's start with the ultimate version of the elevator series operation - multi-threaded elevator.
Because I didn't write the elevator program well before, and I didn't make extensive changes to the code in the previous two versions, so various design flaws accumulated, and the old code could not withstand the toss of multi-threading. So I simply restructured and wrote a brand new multi-elevator scheduling job. The general design is to derive the two subclasses of elevator request and floor request from the request class by means of inheritance, which seems to be more convenient for judgment and management; the elevator class is a state machine, which is assigned to its own request queue according to the scheduler. The scheduler runs by itself; the scheduler does not give him too much burden this time, it is only responsible for throwing the request to a certain elevator, the scheduler keeps querying the access request queue, and then according to the current running status of the elevator and the lighting conditions of the floors. Determine homogeneous or piggyback requests, and then assign the request to an elevator.
I think the multi-threaded elevator has less logic to consider than the first two elevator scheduling, because the multi-threaded job uses the sleep method of the Thread class to simulate the real operation of the elevator, as long as the real-time elevator status and lighting conditions are obtained. It is easy to judge whether the request is homogeneous and whether it can be piggybacked; and the time calculation of the previous job completely relies on logical theoretical analysis, and the time calculation logic is easy to make mistakes when writing, which makes the request judgment very easy to make mistakes. However, multithreading also brings thread safety issues. Which objects need to be locked and which code segments should be locked are all things that we need to consider carefully.
The class diagram is as follows: (After lining up for a long time, isn't it very hin good-looking! Praise me quickly!)
The following are metrics: (In order to inherit the scheduler of the last job, I forcibly pulled the package of the last job over)
UML：
It can be seen that the function of input judgment and the run function of the elevator class have relatively large cyclomatic complexity and block nesting depth. I wrote the conditions of input judgment together into one function, resulting in high cyclomatic complexity of this function; elevator The class is because I wrote a state machine in the run function, and run has to be responsible for scheduling the elevator operation (this seems to reduce the burden of the scheduler, but at the same time increase the responsibility of the elevator class). In general, the code measurement this time is much bluer than the previous elevator operations. I feel that this modification is quite successful.
No bug was found in this evaluation. For the other party, it is probably because the branches of the bug tree are too thin. Several nodes are red due to a bug. It’s really a pity. I felt very guilty, but fortunately, I revoked a few of the classmates through the appeal, otherwise I might want to dig a hole to hide, otherwise I don’t know how to face the classmate.
Alright, next job.
I thought I could take a break after multi-threaded OO, but it seems that I am too young.
IFFF, that name sounds annoying. This homework is really annoying. The instruction book is not clear, which means that this homework basically depends on the readme. I wrote this homework in a hurry, probably because I was a little tired from writing in the elevator. There are no requirements, and the readme is written casually. I know this is wrong, but it was Wednesday when I woke up :[
This time I use one monitoring task and one thread, take a snapshot every 2s, and store it in the Info queue. I have to say that it is really very, very, very, very, very, very, very, very much to combine the four types of monitors and write them into one class. . . It's cumbersome, Trigger has written nearly 350 lines, and it is very difficult to modify the code, but when I realized this, it was too late to change, so I had to break the jar. . . I have been thinking about how to take a snapshot of the directory for several days, and I have thought of many methods, but I think it is too cumbersome. In the end, all the leaf nodes within the monitoring range are added to the arraylist, and the snapshot only needs to scan this list.
The class diagram is as follows:
The metrics are too red, so I won't let them go. . .
UML：
Because I didn't read the issue, it's a big loss to be deducted this time because the function is not fully written. After rename and path-change, I have to continue to track the file. In fact, it only takes a few sentences to modify it, but because I didn't write the full function, I think It is also very kind that my classmates can help me finish the test. And there are many unreproducible bugs in this job, because the time is tight and the full thread safety issue is not considered.
Ok next.
I thought that after IFFF, OO will pass. I don’t know which senior I heard rumors. I don’t think taxis are easy. Oh╰(‵□′)╯ is still too young.
One AlltTaxi thread is used to manage 100 taxis, and the status is updated every 200ms; each time the shortest path is calculated, the Dijkstra algorithm is called once, which is a waste of time. The dispatching system scans the order list every 100ms, and broadcasts it to all taxis that meet the order acceptance conditions. After 3s, the order management class processes these dispatched orders or passengers who have no fate to take the taxi.
The class diagram is as follows: (There are too many classes in the gui to fit in, so I didn't pull it in)
The metrics are as follows:
UML： 
A lot of bugs have been caught this time, and there are also a lot of imperfections in the design. I am very grateful to the testers for raising these problems. There are still many designs that should be changed in the next assignment. The classmates I tested seem to have some problems with the choice of credibility, no major problems.
Thoughts: Having experienced elevator operations, I found that code plasticity is very important. Instead of writing a one-time homework every time, it is better to think about architectural issues from the first time to improve code plasticity. Because it complains about some irreproducible problems, it is better to avoid such problems when writing. In addition, for multi-threaded programs, thread safety is an important aspect of the fat intestine. We must pay special attention to which places need to be locked, but cannot be locked at will to avoid deadlocks.