Homework #12 - 9/24

     I found this article an interesting read. Control flow graphs are kind of understood subconsciously by programmers, but when we actually look at them and investigate their properties, there's a lot more to them than you might think at first. One thing that was confusing to me, or at least not very intuitive, was the GEN KILL IN() OUT() sets. The GEN, IN, and OUT I understand: GEN meaning anything the line of code produces, IN consisting of all of the input variables, and OUT consisting of all of the output variables. The KILL set, however, is a little more difficult to wrap my head around. It is defined as the set of definitions that are killed if they reach the entry to the node. An example they give is the KILL set of {3 : sum, 5 : sum, 8 : sum} for the line of code sum = 0; I understand that the sum of 3 and 5 is 8 from the set (although I'm not sure if that's what is meant by the values in the set), but how did those numbers get derived for that particular line of code where it is merely setting a variable equal to zero?
     When reading about Definition-Use pairs, the first thing I thought was fields and methods of classes. Every node in the control flow graph is like a class (even though it could be just a single line of code) and its definition are the field values and its uses are the methods. It mentions an upward exposed use which it describes as a use of some variable which can be reached by a definition of the variable that reaches the node. This is a little confusion to me, it almost seems ambiguous. What I grasp from it is when a variable is defined, and then used in a child node, the use in the child node is considered upward exposed.
     Program paths are another one of those intuitive subjects in the article. My understanding is that any number of consecutive nodes where the output of node n leads to the input of node n+1 is a path (or subpath). A program path is complete if the starting node of the path is the starting node of the whole program and likewise the ending node is the exit node of the program. Definition-clear paths are something I never thought of, but easy enough to understand. A path is definition-clear with respect to a variable v if it does not depend (contain, basically) on v. Also, the article talks about infeasable paths, which are basically just any path that cannot be executed regardless of input of the program. An example would be:

     String myName = "";
     if(false) {
          myName = "Justin";
     }

The variable myName will never be set to "Justin" no matter what code comes before or after it, therefore that program path is infeasible.
     All of this material seems familiar or intuitive to us as programmers, because as seen in the code above, we use them regularly, we have just been unaware of it and their formal definitions until now.

Homework #10 - 9/17

Response to readings

     While the readings for today were not the most exciting, I can see why they were important. We have many UML diagrams to explain different parts of a computer software project, from class diagrams which describe the actual classes in the code, to sequence diagrams that describe how different actors in the program or environment communicate with each other, but there's so many different types of diagrams and they can be too cumbersome at times, I feel. The "higraphs" that the author introduces seems to solve the issue of being able to describe nearly any type of diagram or graph with one standard, allowing for dynamic meanings of edges, directed or non-directed, and also modular definitions of the "blob" which represents a set of elements. A blob within a blob could represent the entire set of the outer blob, or not, its meaning adjusts to whatever you want it to be. I also really like the idea of being able to express the Cartesian products of sets with higraphs. I happen to be in the databases class this semester and certain queries we've learned will calculate the Cartesian product of two tables, then apply the filter to select only the tuples of interest, so being able to express this visually without having to do the calculations is useful, as with large sets, the product can get out of hand very quickly. The only issue I have with these higraphs is because they are so versatile, you may have to explain the graph to viewers, and it may not be as intuitive to understand as some of the more traditional diagrams. 

     Aside from the readings, I'd also like to talk about my experience selecting candidates for my group's open-source project. We met on Saturday to get a good first idea on what project to do, but I feel like we were pretty distracted by all of the other roommates present. Only two of us had our computers with us, so while I browsed the H/Foss list, another group member was looking at projects on sourceforge.com. He suggested a few gaming related programs that are being developed and put them on the list, which we would later vote on. After what turned out to be a mostly unproductive meeting, we decided that each member would go home, find another project of their choosing to add to the list, and try and compile/run them. I went home and installed a bunch of software on my laptop - a VM program, eclipse for C/C++ and Java EE, as well as some other programs I thought I would need, and attempted to compile some of the source code of a couple of the game related programs. I'm not sure if it's just me, or if the eclipse IDE is complicated, but I couldn't get anything to compile and run. I was greeted with build path errors, project names not matching files, and other issues as well. So I threw in the towel and searched for the program I would contribute to the list. While I do like games, I felt that we should focus on something more meaningful, and that would look better on a resume, so I suggested a music composition/sheet music program. We'll see what the group thinks soon enough.

Homework #6 - 9/5

Problem Set:

4.5) Using the technique suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:

• An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the reader then specifies the amount of fuel required. The fuel is delivered and the customer's account debited.
• The cash-dispensing function in a bank ATM
• The spelling-check and correcting function in a word processor.

4.6) Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.

Functional requirements should be able to be tested by specific code then determined whether or not the prototype fulfills the requirements or not. Non-functional requirements are usually some sort of constraint imposed on the system, for example, the code must be written in Java.


4.7) Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.

Homework #5 - 9/3

Responses for readings for 8/29 and 9/3

     In homework #2, we were asked to discuss whether or not we think programmers should be certified professionals like doctors and lawyers. I held the position that we should not, but after reading some of these articles, I have rethought my take on this subject. In the article about the Therac-25 incidents, the authors say that "more events like those associated with the Therac-25 will make such certification inevitable". I have to agree at least in the case of safety-critical systems and perhaps systems that deal with sensitive data as well, where security is essential. Of course, one could argue that nearly all modern applications fit these categories - apps are getting more and more complicated and requesting access to all sorts of personal information on our phones, and even becoming integrated in our homes and cars. I think software engineers in these fields should undergo extra training on how to handle sensitive data as well as implement safety features in their programming. The Therac-25 case unfortunately held partial blame on simple programming mistakes, such as implementing a variable by one and eventually causing an overflow condition instead of setting the variable to a non-zero value.

     Another focus of the readings was to have thorough requirements outlined before starting a project. The main example of this is the FBI case tracking system, VCF. It is hard to believe that such a massive software development failure could have happened so recently. The major time constraints put on the project as well as focusing on small details of the final product, such as where a button should be located in the interface, instead of the overall functionality of the program set it up for failure from the beginning. It is also disturbing that the FBI was going to do what's called a 'flash cutover' where you replace a legacy system with a totally new one in one fell swoop and cannot revert if there are any failures. This was all exacerbated by the 9/11 event as well as several staff and management turnovers during the development process.  

     Another common theme I noticed was about complacency. Software from previous versions was reused and it was assumed to work correctly when that was not necessarily the case. The Therac-20 contained some of the same software bugs as the Therac-25, but the earlier machine had hardware fallout systems in place to prevent overdose even if the software had a failure. This resulted in many blown fuses, but prevented potentially fatal overdoses of radiation. This is also observed in the Ariane 5 incident, where software from the Ariane 4 was reused and some functions that were already implemented were left in, even though the newer version had no use for them. The software "was assumed to be correct until it was

shown to be faulty" as the accident report points out. Unfortunately, as projects have limited budget, it seems that potential risks get downplayed and do not receive as much attention as they should. Although it shouldn't be this way, perhaps it is up to the developers to ensure they're doing everything they can to practice safe programming and to avoid unnecessary complication when writing software.

My Subversion Experience

I'm not too familiar with command line executions in windows, so you can imagine that getting started with subversion was a little difficult. After downloading subversion 1.7 from the website and extracting the zip file, I was sadly distraught not to find an "install" file to make my life easy. I read some quick start tutorials on the website and couldn't seem to find a straight answer on how to really get started. Luckily, I read that if you are unfamiliar with command line executions, there are several gui clients available online for free and you need only search for them. So, I Googled "svn gui client" and ended downloading the top one from the list: SmartSVN. This is a super easy and intuitive program to use. Extract the download file (that they email you) and use the setup file. While setting up, it asked if I wanted help setting up a repository, or already had on set up. I chose the later option, as we have a class repository. After installation was finished, it asked for the repository location. I simply copy/pasted the url for our class repository, and it found it and asked for my login and password. After inputting my password, created a local directory of our playground repository on my machine. All I had to then do was create a new folder, called "Wooton", within windows. I added a txt file as well, which only contained the text "Test Doc". These changes showed up in the GUI client and I was then able to use the "commit" button at the top to basically add my local changes to the repository and thus, my directory was created. I refreshed the website and sure enough, my name and txt file showed up, yay! So, my svn directory is from now on https://svn.cs.cofc.edu/repos/CSCI362201301/playground/Wooton/. That wasn't so bad, yeah?