Object-oriented eighth homework

Object-oriented eighth homework

code analysis

Fifth job multithreaded elevator

UML diagrams and collaboration diagrams

Code complexity analysis

The main difficulty of this assignment lies in the understanding and practice of multi-threading. On the one hand, because the teacher is anxious in class, and the content is more inclined to the introduction of JVM, so there is not much understanding of some ideas and methods of multi-threaded programming. On the other hand, due to lack of time and no time to learn more about multithreading by yourself, basically you can only rely on your own exploration in the process of typing code and debugging process, as well as the reference of multithreading ideas in other people's code to implement.

On the other hand, since the previous elevators were all simulated time, it suddenly becomes real time from this time, so almost everything written before is not available, only the input and output parts can be slightly modified, the rest of the controls, etc. Part of it is a method that relies entirely on simulation time. If I knew before that this job will use real time, even if the previous jobs may be reported as incomplete due to timeout, I would not use simulation time. On the one hand, simulation time is undoubtedly more difficult to judge and process for homogeneous and piggyback requests. On the other hand, the simulation time is basically not helpful for this operation, and the judgment of homogeneity and piggyback must be redesigned and reimplemented.

BUG

There are two bugs in this work

1. Multiple lines of input cannot be copied. If multiple lines are copied, only the first line can be read. However, if the Scanner reading the console is allowed to sleep for a period of time before starting, the input data of multiple lines can be read in, and the input time is the same. . The reason is unknown.
2. Misunderstanding, the requirement of the number of instructions per line and the number of instruction lines is reversed

sixth assignment

UML diagrams and collaboration diagrams

The threads involved in the code and their cooperation relationships:

Code complexity analysis

After completing the task of the multi-threaded elevator, I have a further understanding of multi-threaded programming. The main difficulty of this work is the conflict problem when reading and writing file information, which is solved by the SafeFilecorrect class lock.

On the other hand, due to the difficulties of IFTTT itself and the ambiguity, multiple revisions, and even repeated changes of the homework instructions, it greatly increases the difficulty of completing homework and the possibility of bugs, especially in the When you have finished programming and started debugging, you generally don't pay attention to the content of the issue, so you don't know the conflict with the previous requirements, and you report bugs that do not meet the previous requirements but meet the later requirements to others. bug.

BUG

1. I am not allowed to establish any monitoring on any subdirectory/parent directory of the established file/directory, the teaching assistant said that this is not possible
2. Because in the process of updating the file snapshot, there are some bugs in the parameter transfer part, which affects the recover operation and the output file information after the change-path.
3. Conflict of work instructions. The initial work instruction required the operation to start to 0KB after the file disappears size-changed, but the final issue content became not triggering any triggers.

The seventh homework

UML diagrams and collaboration diagrams

The threads and operation flow charts involved:

Code complexity analysis

The taxi dispatching system implemented this time requires interaction between the following objects:

1. Passenger request: send a request, the request will be RequestHandlercaptured by the request processing developed in the system, and then for each captured request, set up its corresponding request thread to actually execute the command
2. Request thread: used to actually execute the instruction, established by the requested processing module, scan the taxi information around the place where the instruction is issued, determine which taxis can take orders, and that taxi will be dispatched at last; in this thread, also A new thread will be established BFSThreadto obtain the distance information from each point in the graph to the departure point and the destination point
3. Map: used to store the input map information, obtain distance information, judge connectivity and other map operations
4. Taxi: move randomly when the order is not dispatched, after being dispatched by the requesting thread, get the direction of the next operation through the map every time, until the destination is turned into random movement

Therefore, the system mainly includes the following four main classes:

1. RequestHandler: Process the input request, judge the legitimacy of the request, and start the execution of the request
2. RequestThread: the actual performer of each request
3. Map: Manage map information and perform map operations
4. Taxi:taxi

BUG

Bugs still under complaint:

Time increment: I am calculating the system time instead of using an additional counter to store the time, so there must be errors. Some people use a basic value that keeps +200, I think this is fake time, and the tester on the other side thinks that there is a problem with the real time I output

Dispatching time: It is written in the readme that if the taxi is between the two positions when the order is dispatched, that is, when the taxi is sleep for 200ms, it will start to process the dispatch after waking up. The tester felt that the dispatch needs to be processed immediately.

Strategies for finding bugs

When looking for your own bugs, you rely more on pre-coding design and thinking during coding, as well as self-constructed targeted tests after finishing coding.

When looking for other people's bugs, first roughly find some possible bugs of the other party, including basic functions, tests in some complex situations, edge tests, and work instructions that are not completely consistent and unclear during the continuous revision process. requirements, and then use some error-prone points and more complex test points found in the process of constructing the program and debugging by yourself for testing.

After finding some problems, read the code roughly to find the error location, and consider whether there are other related bugs.

experience

1. Fully design and verify algorithms before starting coding
2. testing during coding
3. Consider the impact of modifications when modifying code
4. Refer to the questions of other people in the issue before constructing
5. Don't dwell on edge points. After all, edge points are rare and the probability of occurrence is extremely low. In addition, since the execution of multi-threading is unpredictable, pay a little attention after finding possible edge points, and don't pay too much attention.
6. Set up DEFINE class or interface. There is no #define in C language in java, you can set up a separate interface, define some constant lights, and implement it in the class that needs to be used.
7. Reasonable design of data structure, appropriate use of LinkedList, LinkedBlockingQueue, HashMap, etc.
8. Pay attention to the README modification, in case there is a conflict before and after the README, which is dug by the tester.