CSci 3081W: Program Design and Development

Testing can be a challenging task for a programmer. Especially when using source control systems with multiple developers working on the same project. There are several strategies to go about tackling this. In this entry and I am only going to talk about unit testing. Unit testing is done by testing small portions or segments of the code to ensure correct functionality. The idea is to test individual but complete units so that developers can test and debug as they write more code. Like white-box testing, this method is used for validating the design and the inner workings so that the functionality is clearly known to the programmer throughout the development process. Typically, we write tests for each method or function so that if in the future any problem is encountered, it can be identified and fixed quickly. Before this class, I never had the opportunity to use this style of testing and I am quite impressed by it. Not only it helps you spot bugs in the early stages of development but also helps you save a significant amount of time in debugging. It can be painful to write test cases after a project is complete. You can be lost simply answering questions like, Where do I start? Which test needs to be called when? Which cases can be integrated? Etc. In situations like these, you might end up writing a entire test plan which can be a project in itself. Therefore to avoid such circumstances, it is essential to write out tests at an earlier stage of coding so that we are able to identify and isolate small parts of our code for robust testing.

Now we know that writing tests for every function/method or class can be very tedious and time consuming, but is there a way to automate the execution of these tests? For our project in this class, we have been using cxxTest for automating unit testing. This framework allows us to define tests for functions or methods by creating a header file and a class that inherits from the test suit. Once defined, the calls for these test cases can be automated using a makefile, so that they are all called automatically in a consistent manner. You can also run tests with assertions. For example, TS_ASSERT (expr), verifies if the given expression is true or not. TS_ASSERT_EQUALS (x,y), checks to see if x is equal to y. More assertions and info on cxxTest can be found here: http://cxxtest.sourceforge.net/guide.pdf. Using cxxTest, we have been able to quickly pinpoint the changes that cause a test to fail, helping us resolve issues as soon as they arise. The framework can be a little challenging to understand at first. But once you have the individual tests created and added to your compiled script, then it only becomes a matter or calling a command to execute all the tests. As a programmer, I would strongly recommend writing small test cases during development rather than waiting till the very end. It makes testing more consistent and debugging a lot easier.

As software developers, while programming we often feel the need to go back to an older "version" of our code or perhaps a previous implementation that worked correctly. How do we do this? Most development these days is done by multiple programmers. How can these developers work on the same project at the same time? All of this can be done using source control. Source or version control systems are tools that enable programmers to manage and maintain software during or after development. We can use these tools to create revisions as we make advancements in writing code or adding features; and then during any stage of development we can revert back to those revisions if needed. These systems can be used for plenty of other purposes as well. We can create multiple versions of the same software and work on them in parallel (did this in my internship this past summer). Or simply use it for backing up data to avoid any accidental data loss or file corruption.

Subversion is one such source control system that my partner and I have been using extensively this semester. We have been working on different segments of the code and committing changes frequently, so that both of us work on the most updated copy of the code. From the labs that we are doing in this class, we get to use the branching feature that subversion has to offer. For example, we have been creating tags for marking the completion of various labs and iterations. By creating tags we are essentially creating names and associating them with a specific time or snapshot of the repository contents. This allows us to work on the bugs in code branches and at the same time continue development in our main source code (which is in the "trunk"). There are some issues with subversion that we have encountered over the course of this semester. These might be important things to know if you are going to start using subversion soon. First, when a conflict occurs, that is when you and your partner try to commit changes to the same piece/section of the code, subversion detects this and gives you the option to merge files or resolve the conflict. What we found interesting was that by simply typing in 'svn resolved filename' we were able to overwrite proposed changes made by other developers with that of ours. This can be an issue if there are any communication lags between you and your partner. Before resolving any conflict, subversion should verify the proposed solution with all the developers working on the project and only then proceed with the override. Another thing that we noticed was the 'svn update' command only updates the contents of the folder that the command was called from. At first we expected that it would update all the files in our top level project directory, but this was not the case. This took me a while to get used to. Creating tags/branches in subversion is very intuitive. This can be done using the 'svn move' command or by simply copying and pasting your source code to a new directory. This was a huge hassle in CVS, because once files were moved, their change histories were lost. However this is not the case with subversion. In the past, I've had the opportunity to work with perforce (another version control system) which in contrast to subversion allows users to graphically diff and merge files. Something we might find helpful in the industry when working on large projects. For those who are still contemplating whether to use a source control system or not, I will highly recommend that you start using one ASAP. Especially if you working in teams. It's definitely one of those tools that we talked about in the beginning of the semester that help us "program better" and try and make software development less painful.

Working in teams is great! I think my partner and I have made some significant progress by working together in this class. Sure, there are times when we have a difference in opinion, but that's part of the learning process. When two people work on a project or assignment, it is natural for them to run into challenges simply because there are two different sets of minds working on it. In such circumstances, it is very important for the teammates to openly communicate and talk about their differences in opinion. I think this class is doing a great job of showing us what software development is really about and at the same it is also preparing us for the industry, where the teamwork is an integral part of the development process.

I think the benefits of working in groups are far more greater than the challenges one might encounter in such situations. Projects or assignments that require coordination can be better performed by groups than individuals. Work can be divided amongst the members of the group and a system of checks and balances can be used to determine the efficiency and accuracy of the results. In my experience, working with other students helps me share ideas, opinions, and skill sets that can significantly contribute to the success of a project. In CSci 1902, when working on projects and labs, I had opportunity to share some of my previous Java experience with my lab partner. It is often the case that your partner can make up for the skills that you might lack in areas related to coding or design style. However, as a team member it is our responsibility to make sure that we equally partake in the work that is being done and also provide the team with important contributions.

Tools for version control systems allow multiple developers to work on the same project at the same time. My partner and I have been making an extensive use of Subversion this semester. We work on different sections of the code in our local workspaces and then commit it to the repository (while either one us is working on it). This saves us a good deal of time because we get to work in parallel without needing to worry about the time or place of work. Despite of minor challenges or differences in opinions that have occurred so far, I strongly believe that working in teams is essential for software development and will tremendously improve my teamwork skills.

I hope to learn various software design and development techniques in this class. Hopefully, all of those listed in the course syllabus! I feel that I have a good understanding of version control systems that are used for software management and maintenance purposes. I'm particularly interested in learning techniques for design patterns and their importance in the world of software engineering. Also, by the means of writing blog entries and papers in this class, I hope to improve my writing skills in the English language.

I think that I have a reasonably decent understanding of version control systems. This past summer, I had the opportunity to intern at National Instruments, where I used Perforce as the version control system for the software application I designed. I worked on the application for sixteen weeks and used Perforce extensively for making code revisions and backing up data (submitting at least one revision every two to three days). Just couple weeks into the internship, I started creating several change-lists and revision copies of my code. My colleagues strongly encouraged me to commit changes on a regular basis, so that the master copy stored on the repository contained the most recent version of my code. It didn't take me long to realize how powerful and awesome version control systems are. On several occasions, I felt the need to go back to an older version of my code and make design comparisons with my current version. Also, there were times when I had to revert back to an older version, simply because of changes in the design specs or for readability or modularity purposes. In all these situations, Perforce proved to be very useful. It allowed me to view multiple revisions simultaneously, revert back to an older version when needed, and share my code with fellow colleagues who were also working on the same project. Certainly, this is not all that we can do using Perforce or any other version control system. There are a lot more features that I hope to learn in this class, which will eventually help me improve my software management skills in the future projects.

I'm extremely interested in learning design patterns. In software development, we as programmers often run into problems that are commonly occurring and usually have a specific type of solution to them. Using design patterns we can study such problems and learn how to deal with them. These patterns are nothing but generalized design strategies that serve as a generic solution for certain problems. I've had very little experience in dealing with design patterns and would like to significantly improve upon in this class. What I find interesting is that, these patterns help us in creating simple and elegant solutions without 'reinventing the wheel'. They also help us in communicating effectively with other programmers, especially when making major design decisions for an application. It is definitely easier to read and modify someone else's code if we know the design pattern used beforehand. Some of the application design patterns that I learned over the summer are standard state machines, producer/consumer loops, queue based message handlers, and object-oriented design approach. Most of these are limited to LabVIEW, except for object-oriented design, which intrigues me the most. It is also of key importance to know when to use which design pattern. This is something that I am hoping to learn in this class. By the end of this course I anticipate that I should be able to identify a problem and find the correct design strategy to go about solving it.

I'm taking CSci 4011 (Formal languages and Automata theory) along with this course and I believe that the theory based knowledge from 4011 and the design and development techniques that I learn in this class will help me prepare for the oncoming challenges in the software engineering track. I have a lot of expectations from this class. I understand the level of dedication and sincerity this class demands and I'm determined to give it my best. Undoubtedly, the techniques and tools that I develop here will help me become a successful programmer in the future.

- Ajay