At the beginning of the class, the first blog asked us to write about the intended learning objectives of the course. As I was writing the first blog, I did expect to learn a lot from this course Fortunately, I think the progress so far meets my expectation very well. I would like to share some learning outcomes in the following paper.
First of all, I want to do an introduction of the subversion, which is the tool that we use as part of developing project. Briefly, Subversion is a source control system available in many operating systems, which allows a group of people to work on a same piece of code at the same time. Before this course, I have never heard of the term "source control", and of course, have no idea what it is. After reading some related paper and some programming experience in the lab, I come to realize the importance of source. Since it is able to put all the sources into a network drive, and several developers will be able to work with them. By using Subversion, my partner and I can do our lab and project separately. We can save our revision of the code by using the command "commit". It will keep the record of the change to our repository-where all the files and all their different versions are stored. And by using the command "update", we can merge others committed changes into our workspace files. Such functions really make our work much easier and convenient, however, there are also some disadvantages using subversion. Case in point, I remember when we were doing the iteration 1; we have to move the file from "lab" directory to a new directory "project". I simply copied the whole folder to the new directory, then I found out that I am not able to turn in my work since there are many hidden svn file in the document, I have to delete them one by one. It took me about two hours to turn in that homework, it is nearly the same time that I wrote the code. After that, when turn in the iteration 2, I have to make sure that I have to only copy the files in the folder to a new directory, thus get rid of the hidden svn files. We have a lab specifically focus on how to use Subversion, and since we use it every time as we doing the lab; we become more and more familiar with it gradually.
Secondly, the testing process also left me a strong impression during the study. As we learned in lecture, testing can be roughly defined as the process of executing code and comparing the actual results to expected results. In other words, if the actual result fit the expected result, then we say the program is successful; however, if the actual result is different from the expected result, there is some problem with your code. There are many kinds of testing, such as unit testing, component testing, integration testing, regression testing, and system testing. For all the testing I listed above, unit testing is kind of the most basic one. Unit testing can be defined as an execution of a complete class, routine, or small program that has been written by a single programmer or team of programmers, which is tested in isolation from the more complete system. As I got some basic idea of the testing from the lecture, however, I came to understand more about unit testing in one of the lab assignment. I remember it is lab 5, and it is about testing with cxxTest which is a kind of unit testing. Actually, cxxTest is a very basic testing skill. Specifically, what we did in the lab is to write the test for a "ReadInput" file, after loading a cxxTest file provided, we try to use it to test ReadInput function. Basically, there involved three tests, the first one ensures that the null pointer is returned if no file name is provided, the second one ensures that the null pointer is returned when the name of a non-existent file is passed and the function attempts to access that file. The third one ensures that when given proper input referring to an existing, readable, filename, the pointer returned is not null. Finally, we modified the "makefile " to include all the test files we just wrote, and run the program to check the testing results. As I mentioned above,
cxxTest is a kind of unit testing, which is relatively basic. Thus, we can say this lab is straightforward, but it is definitely a good way to give a general idea of cxxTest. In addition, it helps me to understand the benefit of testing, which we talked about in the lecture that testing improves your confidence that the code is correct, and avoid collateral damaging in fixing bugs. However, to write a good test, there is still a long way to go, as we know from Meyer's first principle, "when we write a test, we want to make it fail." But as testing can only find errors, it does not demonstrate their absence. Therefore, we should think about as many situations as we can that make the program fail.
In last paragraph, I mentioned a file called "makefile". This is also one of the lab topics. Makefile has very strong functionalities, so it is very useful. Usually, compiling the source code files can be tedious, especially when there are many sources files that you want to include. Since you have to type the compiling command every time you want to do it, and a little mistake will make your other commands fail in vain. However, makefile can totally change it. With its special format, makefile will help you to automatically build and manage your projects. With the progress of lab and iteration, there are more files coming up, and then the makefile is becoming more important since it can save a lot of time and much easier to run the executable file. However, what is interesting is that I found that I have used the makefile in last semester already, but I do not have any idea how it works until I started to do this makefile lab. I try to come up with in which lab specifically did I use the makefile. Later I helped a friend who is taking CSCI 2021(machine architecture and organization) this semester with her "data lab", I found the Makefile in this lab, which helped to compile several source codes together and run the main function. I open the Makefile and take a look at the code inside. I feel very happy that I can understand it, but I also feel a little regretful that I did not try to understand it the first time I use it. If I did not get a chance to learn it, I even do not remember I have ever used it before. It may sound ridiculous, but it is really the case. Therefore, from my point of view, we should pay attention to everything that we see, we use, we hear in order to learn more.
For the first two iterations, and from lab 2 to lab 7, all the stuff is strongly connected, since we are engaged in the same topic--the Regular Expressions in C. In lecture we discussed regular expressions and how they can be used to specify the lexical syntax of a language. That is, they define what constitutes a variable name, an integer literal, a floating point literal, a comment, and so on. The concept of regular expression can be defined as follows: a regular expression is a text pattern consisting of a combination of alphanumeric characters and special characters known as met characters. A close relative is in fact the wildcard expression which is often used in file management. The pattern is used to match against text strings. Based on the definition above, we can tell that the experiment of regular expression involved mostly testing. In fact, it is not overweight to say that all the labs and iterations are about testing. As for lab2, we are provided with two programs, the first one is "RegexTest" - this program lets you experiment with the regular expression library by writing regular expression strings and checking if the match against a text sample, and the second one is "WordCount" - this program counts the number of words and integer constants in a text file, avoid those inside of C-style block comments. What we have to do is some modification of the code and implement it to satisfy the requirements we are going to meet. In addition, lab 6 and lab 7 are about using a recursive descent parser with the scanner. The parser, as we learned in class is the process of analyzing a text, made of a sequence of tokens, to determine its grammatical structure with respect to a given formal grammar. As for the recursive descent parser is defined as a top-down parser built from a set of mutually-recursive procedures or a non-recursive equivalent where each such procedure usually implements one of the production rules of the grammar. Thus the structure of the resulting program closely mirrors that of the grammar it recognizes. For both lab6 and lab7, we should understand the provided "parser" code first, and then modify our scanner code we wrote in former labs so that it can be used by our parser. These two labs are pretty straightforward since we just have to follow the instructions step by step. I would like to say that the most important thing is the patience for sometimes you just make very stupid mistakes because of carelessness.
By doing all the experiment of regular expression, it helps me to better understand two software development process models that we talked about in lecture, the waterfall model and iterative model. The waterfall model is a flow based model, in which you pass every phase once, and cannot go back to that phase again, whereas the iterative model is that you can come back to previous phases, and make the changes accordingly. From my point of view, I classify our project as iterative model for the reason that there are many iterations in the development. Each iteration however, covers new topics in specification, design, implementation and tool usage.
As the very beginning of this course, the first blog asked us to write about the intended learning outcomes of this course. For all the labs I did, they are really a good approach to improve program design and development techniques, such as designing a useful class hierarchy, developing a set of routines at the right level of abstraction, writing loops, and code in general, that are easy to understand, so on and so forth. In addition, we improve our practice of software development through the use of code development tools, case in point, version control system, testing frameworks, writing good tests. All I mentioned above can be familiar for most people, since we all have some programming experience. However, the learning outcomes are not limited to these. In lecture, we discuss a relatively new field, software models. It is aiming at creating accurate and descriptive formal and informal models and using them to guide the development of and verification of software. Some models include UML, state machines / regular expressions, context free grammars, and sets of equations, mathematical models. More specifically, we focus on UML. Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of object-oriented software engineering. It is is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development. UML involves many lots of different types of diagrams, and the diagrams represent two different views of a system model, which can be summarized as structural view and behavioral view. In class, we did some exercise about drawing class diagram, which is one of the structure diagram. As a software model, UML is really a good way to help programmer better understand the class hierarchy, also, as UML is object-oriented, the key reasons for using UML modeling is to improve the software development process. The UML diagram help client, analyzer, designer, and achiever have a better communication since it is straightforward. The requirements are obvious. In addition, the model is consistent during all the development process; it guaranteed the testing can be done on time.
In conclusion, as taking this course so far, I try my best to meet my intended learning outcomes at the very beginning of this semester. I found out all the stuff that we covered in lecture has a strong connection with the lab, and this help me have a better understanding of the lecture material. In addition, all the techniques and tools we learned can be combined together, which means the integration of some techniques can work really well. Case in point, testing frameworks work really well with a waterfall development process. This is because that waterfall model enforces testing in every stage in the form of reviews and unit testing. Computer science usually involve very abstracted ideas, and sometimes it makes no sense to me. However, all the instructions in the labs are in detailed, and the material are closely related to the lecture slides. This gave us more clues when we get confused. To put all into a nutshell, compare to the labs in CSCI 1901 and CSCI 1902, every lab and iteration we did have given me more vivid concepts of what software development is like.
November 2011 Archives
As what we learned in the class, testing is about the process of executing code and comparing the actual results to expected results. If the actual result fit the expected result, then we say the program is successful; however, if the actual result is different from the expected result, there is some problem with your code. There are many kinds of testing, such as unit testing, component testing, integration testing, regression testing, and system testing. In the class 3081, we did a lab which is about testing with cxxTest, which is a kind of unit testing. Unit testing, however, can be defined as an execution of a complete class, routine, or small program that has been written by a single programmer or team of programmers, which is tested in isolation from the more complete system. So as we can see from the definition, cxxTest is a very basic testing skill. Specifically, what we did in the lab is to write the test for a "ReadInput" file, after loading a cxxTest file provided, we try to use it to test ReadInput function, basically, there involved three tests, the first one ensures that the null pointer is returned if no file name is provided, the second one ensures that the null pointer is returned when the name of a non-existent file is passed and the function attempts to access that file, and the third one ensures that when given proper input referring to an existing, readable, filename, the pointer returned is not null. Finally, we modified the "makefile " to include all the test files we just wrote, and run the program to check the testing results. As I mentioned above, cxxTest is a kind of unit testing, which is basic. Thus, this lab is straightforward, but it is definitely a good way to give a general idea of cxxTest. In addition, it helps we to understand the benefit of testing, which we talked about in the lecture that testing improves your confidence that the code is correct, and avoid collateral damaging in fixing bugs. However, to write a good test, there is a long way to go, as we know from Meyer's first principle, when we write a test, we want to make it fail. But as testing can only find errors, it does not demonstrate their absence. Therefore, we should think about as many situations we can that can make the program fail.
