End-to-end programming 1175 1176

I,Pair programingAdvantages and disadvantages:

1,Advantages: First of all, in the process of independent programming, each person will inevitably make such errors in the Process of independent software design and implementation. In Pair programming, because there are reviews and exchanges at any time, the quality of each aspect of the program depends on the one who has a high level in all aspects of the programmer (the one with a low level can sometimes find some critical errors. After all, the angle for everyone to analyze the problem is different ). In this way, there will be much fewer errors in the program, and the initial quality of the program will be much higher, saving the modification and testing time in the future. The official summary is as follows:

(1) At the development level, paired programming can provide better design quality and code quality, and the cooperation between the two parties can provide better problem-solving capabilities.

(2) For developers themselves, pairing work can bring more confidence, and high-quality output can bring higher satisfaction.

(3) psychologically, when another person is by your side and works closely with you to do the same thing, you may be embarrassed to make it easy and confused.

(4) At the enterprise management level, pairing can communicate more effectively, learn from each other and pass on experience, and better handle the flow of personnel. Because one person's knowledge has been shared by others.

2,Disadvantages: First of all, the efficient pair programing can be done in less than a day or two. Everyone has their own programming habits. in the initial stage of cooperation, the efficiency of Pair programming is not necessarily higher than that of personal programming; second, I personally think that pairing programming will allow a flood of people to achieve the same results, which is unfair to pair. From another perspective, a person with poor levels cannot effectively exercise and his/her dependence increases.

II,Analysis of the personal advantages and disadvantages of this elevator pair programing

12061175: He is the core of this pair programming. He has completed most of the work on Algorithm Implementation and has many advantages. The following are some simple examples: 1. Strong programming skills 2. understanding and grasp of the entire project, strong global control ability 3. enthusiastic and patient, very patient and enthusiastic to teammates 4. Strong expressive ability, your ideas can be clearly expressed and easily understood. Disadvantages: We have to say disadvantages, that is, a little obsessive-compulsive disorder, and the pursuit of perfection.

12061176: advantages: 1. Be careful. 2. Be conscientious. 3. Learn modestly. Learn modestly. Disadvantages: relatively lazy, highly dependent, and overly dependent on teammates.

3. ProgrammingInformation Hiding, interface design, loose couplingThese good methods

Through this pair programing practice, we are very impressed with the above methods and have gained a lot. Below are some of our gains:

1,Information Hiding (Information Hiding):For object-oriented programming, Information Hiding is an important software development method, which is closely related to the object encapsulation (encapsulation) and modularization (modularity. In my opinion, Information Hiding allows a class to encapsulate complicated, sensitive content that may cause adverse consequences once captured by the outside world, code other than this class cannot obtain such information (which may be obtained through reflection or other means) to improve program security and robustness. First, you can add an underscore (_) to the variables and methods defined in the class to mark them. This is a good naming convention and can avoid assigning values to Private Members accidentally. When exchanging information between classes and classes, you must use a pre-designed method to access private variables. If we call the private variables of another class in other classes, then we must define a method to obtain the private variables of this class. When we want to change the variables of another class in another class, we also need to define a method to change the private variables of this class. In C #, set and get are particularly convenient. We can easily define methods for accessing a class private variable.

2,Interface Design (Interface Design) And loose coupling (Loose coupling):In my opinion, these two concepts complement each other. The latter is the purpose of the former, and the former is the implementation means of the latter. From the perspective of street design, a good interface can provide a good framework for subsequent programming. In this elevator scheduling project, the interfaces ielevator, ipasator, ischeduler, and irequest, through interfaces, we can quickly know the attributes of elevators, passengers, scheduling schemes, and requests, and what methods should be implemented without worrying about specific implementation details; this makes software testing easier. From the perspective of loose coupling, you don't have to worry about cracking code elsewhere in code design. This design method has a low dependency between classes, so that a class is separated from another class, and they are only associated by messages. Therefore, when designing a class, you don't have to worry about destroying another class. When the code is changed, we don't need to modify our code on a large scale. We only need to locate a problematic module and then make changes to it, in addition, services of other modules are not changed. This is fully reflected in the MVC model.

Iv. DBC

When I first saw the contractual design, I thought of the next major (including the last exam) Class Oo, which is as lethal as this course. before writing every class and every method, you must write a lot of requires with annotations, define Abstract Functions and non-variant expressions in the class, and set the parameters to requires in the method, note the non-temporary variables that need to be changed for this method and check whether the class's variant is satisfied before and after the method is run. This is the first time I have come into contact with contractual design (or contractual programming ).

Let's simply sort out the contractual design. There are six principles:

L Principle 1 differentiate between commands and queries. The query returns a result without changing the visible nature of the object. Command to change the object status, but no results are returned.

L Principle 2: Separate basic queries from derived queries. A derived query can be defined using a basic query.

L Principle 3: Set a posterior condition for each derived query and define it using the results of one or more basic queries. In this way, as long as we know the value of the basic query, we can know the value of the derived query.

L Principle 4 Write a posterior condition for each command to specify the value of each basic query. Combined with the principle of "defining derived queries with basic queries" (principle 3), we can now understand all the visual effects of each command.

L Principle 5 use an appropriate prior condition for no queries or commands. A prior condition limits the client's time to call queries and commands.

L Principle 6: Write an variant to define the constant characteristics of an object. Class is an embodiment of an abstraction. We should focus on the most important attributes to establish a correct conceptual model for class abstraction.

There are also six principles:

L criterion 1 adds physical limitations where appropriate. Especially those that require variable restriction should not be void.

L criterion 2 use efficient queries as much as possible in prior conditions. If necessary, you can add efficient derived queries and ensure the equivalence between them and inefficient basic queries in their posterior conditions.

L Criterion 3 limits attributes with a non-variant pattern. If a derived query is implemented as an attribute, it should be consistent with other queries through the non-variant assertions in the class. During the development of a class, we usually set the level of assertion detection to the highest level, so that the anterior conditions, posterior conditions, and non-variant conditions are detected. Once the detection and testing are passed, generally, the level of assertion detection can be reduced, and only a prior condition can be detected to improve the code running efficiency.

L Criterion 4 to support the redefinition of features, Each posterior condition is ensured with a prior condition. In this way, unpredictable redefinition can be performed during subclass development.

L criterion 5 places the expected changes and rules in different classes. This gives developers more freedom to extend existing classes.

L Criterion 6 if confidentiality requirements exist, queries that violate confidentiality can only be set to private and used in the contract. Here, "set as private" refers to the level under "using the Query Class in the contract". As for the level above the class, this query can certainly be used.

In fact, in the programming of this elevator scheduling, I used the idea of Contract Design in many places. Although I did not strictly follow the requirements of DBC, I have a similar idea. For example, many methods need to read the current direction of the elevator. We should naturally talk about the status. currentdireciton is used as a parameter to pass in these methods. The problem is that the elevator scheduling method only schedules the elevator up or down (because the floor priority is determined, so there must be a clear up, down), then when the elevator opens the door, direction is no. How to deal with it? Therefore, before I pass in the ction, I added the no judgment. If it is no, I will take the historydirection of the elevator. In addition, when the elevator is connected to historydirection at the beginning, it will also be no, this also requires special processing and will not be repeated. In fact, I did something like this in DBC: The caller must first make sure that he meets the call conditions to get the correct results.

V,Unit TestTestSumreq() Method as an Example)

The sumreq () method is used to calculate the number of floors to be docked between the current floor of the elevator and the target floor issued by the external Request command. It is used to calculate the waiting time for a passenger from sending a request to reaching the elevator.

Test1:

The first case is: the elevator is just getting started. We set that the return value is 0, and the test result is as follows:

Test2:

The elevator is on its way and request to be in front of the elevator,

The elevator is on its way from the 20 th floor to the 9 th floor. It will be stopped five times in the middle, which is consistent with the actual operation.

Test3:

The elevator is in the same direction, but the requested floor is behind the elevator,

Test4: the previous tests are all module tests, so the code coverage rate is not taken into account. This test tests the entire function method, but only tests in one direction (that is, downward) are considered ), because of the difference in the direction, I am a little lazy. I didn't cover that part of the Code. The coverage rate is only about 35%. Considering the direction, the coverage rate should be around 80%, almost the whole code is covered. An example of test coverage is as follows:

VI,Paired programming cooperation photo

Finally, we attached a pair of programming cooperation photos to commemorate!

VII. Algorithms

About Algorithms

After a passenger enters the elevator, the target floor is told to the elevator, which is irrelevant to the scheduler. Therefore, the Scheduler only needs to process external requests.

The time consumed by a passenger to take the elevator is divided into two parts: waiting time and taking the elevator time. Compared with the waiting time, the elevator ride time is relatively short, and the running status of the elevator is not accurately estimated at the start of scheduling, therefore, we decided to determine which elevator to schedule only through the waiting time of the passengers.

 

When a passenger presses an external request, the scheduler calculates the time for each elevator to respond to the request, and selects the minimum scheduling time. I will discuss this question in a major direction:

There are three external requests for an elevator in operation: first, the Operation direction of the elevator is the same as that of the elevator and the floor to be reached by the elevator; second, the Operation direction of the elevator is the same as that of the elevator, but the elevator has already passed the floor. Third, the Operation direction of the elevator is the opposite.

In these three cases, the order in which the elevator responds to external requests is different. First, the elevator goes smoothly and stops directly when passing by. Second, the elevator keeps the current direction running to the far end, reversely runs to the far end, and then responds to the current external request. Third, the elevator maintains the current direction to the far end, and reversely runs to the current external request.

From the above discussion, we can see that the scheduler needs to know the direction and source of the current request, the current floor and direction of the elevator, and other requests to be completed by the elevator, this is also the method we wrote for the elevator class. The waiting time can also be divided into two types: the elevator running time and the elevator staying time on other floors. The latter operation also needs to know how many times the elevator needs to be stopped, this is also the task to complete the sumreq method added in elevator.

 

The Code details are described here:

1. The sumreq method does not simply add the external request and internal request queue of the elevator, but calculates the number of different requests based on the three States mentioned above.
2. The scheduler should only know the source floor, so only when the request is on a floor that cannot be reached by the elevator, the elevator is not transferred to the corresponding floor, which leads to a tentative scheduling problem: if the elevator to be dispatched cannot reach the floor required by the passenger, the passenger again sends an external request, which records the passenger's refusal to enter the number of elevators. During the next scheduling, schedule another elevator for it.
3. When the elevator has completed all internal requests, the two of us disagree with scheduling: whether to call the first external request to run or the external Request closest to the current elevator to run, first, we tried the later solution and moved the floor closest to the current elevator to respond. The result was not very good. The test cases during the peak hours were not as good as the bus algorithm. The results also showed this problem: 1,000th people press the request at 50tick and the response time is very late:

 

This also inspired us to use the previous solution to schedule the tasks by entering the Team, which is much better:

 

This blog was written by Lin Jiang and I. Now the Pair programming is finished. Haha

End-to-end programming 1175 1176