OO second summative assignment

Multithreaded elevator

Design requirements

  This work is to design a set of multi-elevator dispatching system composed of 3 elevators. By adopting the thread mechanism, the new dispatching system procedure is completed on the basis of the procedure realized by the third operation.

  I have to say that this assignment is substantially more difficult than the previous assignments. The first time I came into contact with multithreading, I felt very uncomfortable. The inability to set breakpoints for debugging made the already difficult multithreaded job even more difficult to figure out. Before starting to code, the author spent a lot of time reviewing the things in the classroom, and also found many java related courses on the Internet, but always found it difficult to start. In the end, under the pressure of ddl, I finally took a difficult step. I have to say that although this assignment has a lot to do with the previous one, the logic itself is not much different, and the function of the work has not been improved a lot, but in fact, after I finished writing it, it can be said that the previous work is basically the same. All the code was torn down and rewritten. Of course, this is also the same as what I said in my previous summary blog, my previous design was flawed to a certain extent, and the scalability was poor, and this time the workload of such a large job is the best proof.

Class Diagram

 

metric graph

analyze

  Since it is the first time to contact multi-threading, and time is tight, just being able to complete the function and find bugs as much as possible has consumed a lot of time. Although a lot of preparations were made at the beginning, when I actually started to write code, I still encountered many difficulties that I did not think of before. Patching everywhere, tearing down the east wall to make up the west wall, made the function and positioning of the class confusing, and to a certain extent created the birth of "God class" and "Fool class". In the subsequent bug debugging and mutual testing, in my ladder rank, it can be seen that everyone has used a lot of power to complete the basic functions, and it is obvious that some extreme situations are not handled carefully enough. And thread safety is also a big deduction point. For accessing an object at the same time, if proper processing is not carried out, the situation of "reading while writing" is easy to occur, which makes the program chaotic and even some inexplicable behaviors. However, multi-threading cannot perform breakpoint debugging. Through output debugging, the difficulty of debugging is greatly increased. At the same time, if you don't seriously think about the code logic, but just add locks to all of them, it will not only make the program programming a veritable single-threaded program, reduce the efficiency, and even cause the phenomenon of "deadlock", that is, calling a lock in an object This method calls other locked methods, which is undoubtedly contradictory, resulting in the phenomenon of "deadlock".

 

Summarize

  This assignment is still a big challenge for the author. In addition to the weekly os computer and the electrician internship that has been cool for half a semester, the author has stayed up for several days before submitting it before the ddl deadline. I put my own code and a readme of writing whatever comes to my mind. Fortunately, my efforts were not in vain, and I did not get many points deducted in this test. The questions I ignored will also be ignored by many students. Through this assignment, the author has deepened the understanding of multithreading (really, one-day fast java, one-day fast multithreading!!) I also have a lot of my own experience in the output debugging method. Facts have proved that in the writing of the next two assignments, it is much more mature than this assignment, and many bugs that were not thought of before have also been avoided.

 

IFTTT

Design requirements

  The goal of this assignment is to train students on how to balance the conflict between thread access control and shared objects for thread safety issues. The job content is to implement a monitoring program, for the monitoring objects within a given monitoring range, to detect the changes of the related attributes of the monitoring objects in a scanning manner, thereby triggering the specified processing actions.

  I have to say that this homework was really deceived by the teacher and teaching assistant. After the baptism of the multi-threaded elevator, the author dragged his tired body, lay on his own little bed, and fell asleep peacefully. Teachers in the classroom, including after-class communication with teaching assistants, all say that the multi-threaded elevator is the peak of oo, and there will be a drop in difficulty after that. Right, after being tired for so long, it's time to rest. Knowing this, I put the oo aside with peace of mind, and bravely waited until Monday night to open it.

  The author who is full of confidence thinks that he only needs one night and one day to finish this assignment easily, because in my mind it is probably about the same difficulty as the smart elevator. However, when I actually started reading the instructables, I realized it wasn't that simple. First of all, this job can be said to have a more in-depth examination of the security of multi-threading. Operations performed on the same file will trigger multiple triggers, and there will undoubtedly be great security risks in this process. In addition, for the author who has never understood java before, and for the author who has just made java in one day, what is the file operation? ? For me, who had no idea how to start this program, I calmed down and started searching the website for java operations on files. How to create a file, how to move a file, how to write a file, all from scratch. After countless attempts and inquiries, I finally staggered to learn the basic operation of files, and finally started to type the code, and looked at the time, um, one o'clock in the middle of the night

  The interface that followed was also one of the headaches for me. It was the first time I wrote this kind of test program, and I was very afraid that there was something I didn’t write well or didn’t take into account, which would lead to unnecessary loss of points. However, it is safer to use your own test interface for your own program. If you let the tester write the test interface for testing, there may be more ambiguous bugs and unnecessary contradictions. The author had to choose to give up this week's electrician internship and os, and devote myself to the writing of this assignment.

Class Diagram

measure

analyze

  With the experience of the previous assignment, I have a clearer understanding of the positioning of the class function, but the time is not very abundant, some methods may be written a bit ugly, and the efficiency is not so high, but this time The program has a higher emphasis on thread safety, preventing simultaneous read and write operations on a file. During the debugging process, due to the file moving or renaming, the object refers to the empty and the phenomenon of crash often occurs, and it also becomes a big score and loss point in the subsequent mutual test. At the same time, the author also ignored a situation. When the two files are the same except for the name, if one of the files is removed at this time, the author's program will consider the other file to be obtained after renaming the current file. And this was undoubtedly wrong, which led to the loss of points. The author is also not very careful about the preparation of the readme due to time constraints, which makes some unnecessary conflicts with the testers.

Summarize

  不得不说这次作业真是给我了一次惊喜。其实如果我分配更多时间的话,应该会有更好的发挥,但就是对于自身的过分自信,对于外界言论的过分自信以及多线程电梯后留下的伤疤,让我迟迟没有开始动手。也正是这样,让我在下一次作业的编写中,更加合理地安排时间,从而达到了很好的效果。

 

滴滴打车

设计要求

  本次作业模拟出租车的乘客呼叫与应答系统,开发相应的程序,继续训练线程安全设计方法,同时应用课堂所讲授的面向对象分析方法和设计原则来开展分析和设计

  本次作业做好了提前计划,且对于题目有了很深的了解。虽然动手打代码的时间不算早,但可以算是一气呵成,用了一个下午就基本完成了。之后简单进行了调试就可以跑了。不得不说看见一堆红点在地图上跑的时候还是开心地笑了出来。

类图

度量

分析

  本次作业整体难度感觉相比于之前有所下降,可能也是自己写了这么几次多线程以后有所提升吧。虽然之后出了一些bug,但基本是自己有些小地方没理清楚导致的,整体上打代码的感觉还是很舒服。基本冲突的地方就是对于一个请求,不捅出租车对它进行的响应。不过本次作业的gui部分以及地图读取部分,都是使用的课程网页提供的代码。如果需要自己读入地图并进行容错处理,以及自己去求最短路径,其实还是很有难度的。

总结

  连续三次的oo作业终于结束了,这几周内也一起完成了os的期中考试以及电工实习的期末验收。不得不说这几周以来压力还是挺大的,在最后搞定oo的那一刻,感觉终于可以放松下了哈哈。不过oo的征程还没有结束,下周,让我们重新上路。

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325233024&siteId=291194637