Hi. This lecture is about implementation, that means we code and build the system. In this lecture, I'm not going to teach you how to code, but instead I would teach you how to avoid making mistake when you code. This are the learning objectives of this lecture. After this lecture, you will know the purpose and the major activities of implementation. You will also know how to protect your code and also how to improve your code. Then you will learn how to debug your code, and then finally how to backup your code. This lecture is an overview about implementation, and I will also talk about how to avoid making mistakes when you code using defensive programming, code review and also refactoring. If we are talking about the implementation, we focus mainly on construction and that means code and building the system. In implementation, we try to transform a design into executable code, and the implementation workflow implements the system in terms of modules and subsystems. We try to develop modules one by one, and then we try to go subsystems one by one. A module is a physical replaceable part of a system that packages implementation and conforms to and also provides a set of interfaces. A subsystem organize modules into more manageable pieces. We tried to group modules together as a subsystem. Examples of modules are for example source code, binaries, scripts or executables. During implementation, we try to generate source code for each class, and we need to choose and code suitable algorithms to implement the methods that we have within the software system. Then we have to assign classes to different modules. Then we have to integrate modules and subsystems by compiling them and linking them together into executable. When we perform implementation, we need version control. Then when we perform integration, we also need an integration plan. Eventually, if we say distributed system, then we may have to distribute the executable modules onto different processing nodes. Now I would talk about how we can avoid making mistakes by defensive programming. What is defensive programming? The rule of thumb is that you try to protect yourself at all times, and we never trust anyone including your users. We have to double check all the values of all data from external sources, especially those data from users. Also check the values of all routine input parameters, and also decide how to handle bad inputs. One important thing that you have to do in defensive programming is to double check all the inputs from external sources using barricade classes. You may get some inputs from your user via Graphical User Interface, Command Line Interface, et cetera. For all inputs that you get from the user, you have to double check them before you feed them into internal classes, into your system. Now let's say we have a course registration system and student has to inputs student ID and email address before they can assess something on a system, then we have to double-check this inputs. That means their student IDs and email address before we feed the student ID and email address into the internal classes, into our system. By doing this, we can use the barricade classes to clean the data before we feed any data into internal classes. All the data that we use within the internal classes, they are clean and they can be trusted. Assertion are your friend, and you can use assertion to double-check all inputs that you can get from external sources. What are assertions? Assertions are statement that you can insert into your program to double check for some conditions within your program. For example, what is true here? X should be 17 then you can insert an assertion here to double-check that x should be 17 at this point of execution. What should be true here, now x should be 17 and y should be 42. Now you can insert another assertion here to double-check that and make sure that x should be 17 and y should be 42. Just to make sure that you achieve all the required conditions while you are executing the program. What should be true here, now x should be 17, y should be 42, and then z should be 59. Then finally, what should be true here? Nothing, it's going to be just true. Now you can insert assertions into your program to double-check for some condition while you're executing the program. That's why I say here, an assertion is a logical formula inserted at some point in a program. You can use assertions to check for precondition and also post-condition. Precondition means an assertion inserted before the execution and post condition means an assertion inserted after execution. We can come up with all the assertions using forward reasoning. This means we know what is true before running the code, then we ask ourselves what must be true after running the code. This is one example. Let's say the precondition is that x is even, then after we execute these free lines of source code, what should be the post-condition? Now, you can see that after you execute these free lines of code, x should be 5 and y should be even because y is 2 times x and it's going to be always even. Or you can come up with assertions using backward reasoning. Backward reasoning means we know what's going to be true after executing the code, then we try to derive what should be true before running the code. This is one example. Let say that you know what the post-condition is y is going to be bigger than x, then what should be the precondition? Now let's say x and y, they are both integer. Then if y is bigger than x, now, in the last line of code, we know that x should be five. If y is bigger than x, then y has to be bigger than or equals to 6. Y is equals to 2 times x in the second line of code. That means x has to be bigger than or equals to 3 in the second line of code. In it's first first line of code we know that x is going to be equals to x plus three, and since from the second line of code, we know that x has to be bigger than or equals to 3. That means we need x to be non-negative in the first line of code in order to achieve the necessary post-condition, that means x has to be bigger than or equals to zero. Now why backward reasoning is good because somehow you can reestablish a class invariant at operation exit. Given a post-condition, you will know exactly what is required to generate the post-condition. Also, for example, given a bug, you will know exactly what must input have been in order to somehow we poach used the bug. Notice that forward reasoning is more intuitive for most people because it's going to help you understand what will happen in your program. But then you may introduce facts that may be irrelevant to the goal because during the execution you're going to derive a large set of conditions, and some of them may not be relevant to the goal. It may take you a long time before you can derive all the relevant facts. That's why usually backward reasoning is going to be more useful. It's going to help you watch it happen. That means given a specific goal, how do you achieve it, and given an error or a bug, how to produce a test case to somehow reproduce the bug. That's why I say backward reasoning is going to be very useful for testing because given a buck or given a mistake, you will know exactly how to reproduce the mistake. Then you can use assertions to double-check for the following things. For example, input parameters, output parameters, whether a file or a stream is opened or closed, and the value of an input only variable, a pointer is empty or not. An array or out of container passed into a routine can contain at least X number of elements. A table has been initialized, or a container is empty. You can use assertions to double-check for all these things. Why do we focus on checking these things? Because these are the places that we can easily make mistakes. That's why we focus on double checking these things in our program. These are some guidelines for using assertions. You can use assertions to document and verify preconditions and also post-conditions. You can use assertions to check for conditions that should never occur. You should avoid putting executable code into assertions. This is an example assertion is C-sharp and the condition here is that the denominator should not be equals to zero. If it's equal to zero, then this message will pop up during execution of your program.
