21.MyISERN-1.2

Milestone 1.2.1022

Project Homepage
Download Latest Release


What was difficult about this assignment?
The difficult part of this assignment was having to complete all the assigned tasks. This time there was much more to do than simply code, test, and fix. We also had to write use cases and put together a PowerPoint presentation.

Another difficult aspect of this assignment was testing. I found out that it was very difficult to test command line usage in JUnit tests because the I kept running out of memory when testing the input task for milestone 1.2.1022. I was testing the input capability by reading in input from a text file to simulate user input. That strategy seemed to work pretty well, but I guess it takes up a large amount of memory to do that so I kept running out of memory. Because of this, I was unable to fully test the input class, and as a result, both black and white box testing suffered.

Also the validate XML ant task turned out to be very difficult to satisfy. The collaboration years, it turns out (at least the way we handled them), does not get written to the XML file in a valid manner (when there are no collaboration years). However, the system still runs and everything is ok on the system side, but I guess the XML file is not up to par. Right now the only I can see to fix it is to put in a bogus value like 1000 for null collaboration years and then disregard this value when reading the data into the system. However, I refrained from doing something like that because then XML data by itself is not valid according to system specifications.

What problems were encountered in organizing the group and carrying out the work?
We divided up the input task into 3 issues, one for collaboration, organization, and researcher. Then everybody tried to help everyone else to do the use cases and the PowerPoint. This turned out to be a not very efficient way of tackling this milestone. That is because the 3 issues are basically the same issue, with a large amount of copying and pasting and then modification to fit each type. Also, because people were not assigned smaller tasks that they could finish on their own, everyone had to help everyone else out when they ran into problems and we spent a lot of time helping each other instead of working on what we were assigned.

Were all of the assigned tasks completed? If not, why not?
All of the tasks were completed successfully.

What will you do differently during the next Milestone to improve the process and the product of your efforts?
For the next Milestone, I will create smaller tasks for each person to work on. That way the person assigned that task should be able to complete them on their own or with minimal help from another group member.

19.UseCaseSpecification

Our Use Cases

From this assignment, I learned that use cases really do help you understand and focus on what the user needs are and reminds a software engineer that the system needs to focus on meeting those needs. I understood the principle of use cases after reading about them, but after having to go through the process of recording them and then reconstructing them into specific use cases, I realized and learned just how important they can be in helping to view the system from the user's perspective.

I also learned that making the use cases specific really does help and not hinder understanding the needs of the user. Originally I thought that if you make the use cases specific, then you would only be getting the user needs for that specific situation. However, after writing use cases, I realized that while some of the user needs that you learn from use cases may only apply to that particular case, other specific needs can be extracted from the use case that apply to the system as a whole. If you wrote only general use cases, then you would only be able to extract general user needs which may not prove to be very helpful at all.

22.MyISERN-1.1.Review

Project Reviewed:

MyISERN-1-Brown
Author that I am Reviewing: Kevin English

1. Installation Review

I was able to download the system as a distribution .zip file. However, I was not able to download the latest distribution from Kevin's Engineering Log (was the older version), and I had to go to the team's project page to get the latest distribution. The system allowed for the creation of a jar file "myisern.jar" which could be used to execute the system instead of having to use ant or Eclipse. It was not difficult to figure out how to run system, I simply had to type the command "java -jar myisern.jar" and a usage message appears that shows what args are supported. It also prints out a message that says "Thank you for shopping at Walmart".

Here are the results from invoking the following ant tasks:

JUnit ran successfully

Checkstyle ran successfully

PMD ran successfully

FindBugs ran successfully

ant -f verify.build.xml ran successfully.

2. Code format and conventions review

The code is very well organized into distinct modules. Other than the Cli.java class which contains some consistent errors, I see no other significant format or convention errors.

File	Lines	Violation	Comments
MyIsernModel.java	105, 113, 121, *	EJS-9	Use meaningful variable names
MyIsernTable.java	40, 58, 74	EJS-9	Use meaningful variable names
Display.java	30, 46, 60	EJS-9	Use meaningful variable names
Cli.java	30, 46, 60	ICS-SE-Eclipse-2	Left curly brace on preceding line; right curly brace on its own line
Cli.java	52, 60, 190, *	?	White space between methods

3. Test case review

Black Box Perspective

Black box testing looks good. All the classes are tested by generating equivalence classes and checking for the expected output or return values. Most of the testing does not involve testable boundary conditions so the black box testing looks very good.

White Box Perspective

The white box testing is not quite as good as the black box testing. Here are the results from running Emma:

Emma Coverage Summary
class:	92%	11/12
method:	89%	62/70
block:	88%	2020/2293
class:	82%	318/390

As is shown, the coverage across the lines of code is not great and several methods are never tested. Based on the Emma coverage summary and actually looking at the report, the white box testing does not fully cover the code. Most of the problems with the white box testing occurs in the Cli.java class and is due to the fact that not all the possible argument input types are tested. So to improve white box testing, I would simply recommend testing all possible argument input combinations, just to double check that the system is in fact executing the right code based on the input arguments.

Break da buggah

Although the white box testing is not as complete as one would like, because of the way that the command line arguments are handled, I cannot think of a way to break the code short of actually going in and manually rewriting code to produce an error.

4. Summary and Lessons Learned

After looking at Kevins's code I realized that the code I have written thus far for MyISERN is not modularized at all at the class level. My group has written different methods for the various tasks, but everything is still in the class MyIsernXmlLoader.java. After looking at Kevin's code, it dawned on me that only code pertaining to loading MyISERN information from XML files should be contained in the class MyISERNXmlLoader.java. So as soon as we implement the new input ability for the system, I will work on modularizing our group's code into intuitive class modules. Not only does it make the code much more logical in terms of organization, but it also makes modifying it much easier because everything is split into logical parts (and other parts will likely not be affected if one part is changed).

I've also learned that you don't necessarily have to handle command line arguments in the main method of one the classes you implement to perform a task. Instead, you can implement your own class that handles all the command line argument intricacies and then executes the necessary code based on the results of the checks that are performed. This seems like a very logical and modular design that I will definitely consider including something like it in my own group's code.

18.MyISERN-1.1

Milestone 1.1.1015

Download Latest Release


What was difficult about this assignment?
The difficult part of this assignment was delegating all the work so that we would not get in each other's way or spend all of our time doing the same task. Also, when multiple are programming the same system, it is difficult to make everything consistent and easily readable. While we do share the same ant tasks such as PMD, CheckStyle, and FindBugs, the actual code that we write may not necessarily be consistent. One of us might choose to use a void method, while the rest of us use methods that return strings for instance. This type of inconsistency can make code very difficult to debug and read at times. I found that I had to spend a good amount of time making our code as consistent as possible so that it was more readable and easier to debug and change.

What problems were encountered in organizing the group and carrying out the work?
We divided up the various tasks into distinct issues. Since each issue was pretty much independent of the other issues, we assigned one person to work on each issue. The problem with this approach though, was that because only one person was working on each task, if the person ran into trouble, then no one else was working on that issue. I'm not sure if it would have been better for everyone to work on the same issue using the XP approach. During our in-person meetings we used that approach to do some of the tasks and it turned out pretty well. The only problem is during the in-person meetings, we only have one computer so it is a little inefficient.

Were all of the assigned tasks completed? If not, why not?
All of the tasks were completed successfully.

What will you do differently during the next Milestone to improve the process and the product of your efforts?
For the next Milestone, instead of just dividing up the work, I (our group) will attempt to divide the work to better cater to our strengths. I think this will help us to better use our time and will make achieving the next milestone far easier, since hopefully it will be a much more efficient process. Also, I think we will try having one person work on the main method and testing, and the other two people working on the task methods. This will allow the code to be more consistent and easier to debug and change. Another possibility is to define team standards that we will use to program, so that everything will be as similar as possible.

16.MyIsernReview

Project Reviewed:

MyISERN-1-Orange
Author: Michal Zielinski

1. Installation Review

I was able to download the system as a distribution .zip file. The system allowed for the creation of a jar file "MyISERN-1-Orange.jar" which could be used to execute the system instead of having to use ant or Eclipse. It was not difficult to figure out how to run system, I simply had to type the command "java -jar MyISERN-1-Orange.jar" and the 3 tables appeared.

Here are the results from invoking the following ant tasks:

JUnit ran successfully

Checkstyle ran successfully

PMD ran successfully

FindBugs ran successfully

ant -f verify.build.xml ran successfully.

2. Code format and conventions review

One thing I noticed about the code is that the code used to generate the 3 tables is placed in the main method. Even for a small assignment like this one, I would recommend moving the code to one or more non-static methods and if anything, use a static method to generate the GUI.

Another issue that I noticed is that the code is very case specific. The code used to generate the 3 tables knows exactly how many rows are in each table. This means, that if more organizations, collaborations, or researchers are added, the code will need to be changed for each addition.

Another issue is the commenting of the main method. Two types of comment markers are used: "//" and the "/** * */". Since the comments are within a method, only the "//" type should be used. Also, the comments are very general and do not really add anything to the code.

One additional issue I noticed in the main method is that the toString() method is called on several String objects even though it is unncessary.

3. Test case review

Black Box Perspective

Several MyIsernXmlLoader objects are created and all the methods are tested. Because all the newly implemented code is in the main method, the only way to test it is to invoke the main method. If the code is taken out of the main method and placed in individual methods, the code can be more effectively tested (if they return something). Since the main method is a void method, it is much more difficult to conduct black box testing since the return values cannot be tested.

White Box Perspective

Several additions were made to the main method to allow the organization, collaboration, and researcher lists to be tested to see if they contain the expected values. This is a good test to make sure that the getCollaboration(), getOrganization(), and getResearcher() methods are returning the expected lists. Combine that with the tests that make sure the collaborations, organizations, and researchers sizes are accurate, and everything needed to create the tables has been tested. Since, the main method contains all the code to create the tables, however, whether it actually creates the proper tables cannot be effectively tested. To fix this, I would recommend moving the code to create the tables from the main method to their own non-void methods. This will allow the return values generated from these methods to be tested against their expected values.

Break da buggah

I modified the researchers.example.xml file to add a fourth researcher to it. I modified the TestMyIsernXmlLoader.java by changing the expected number of researchers to 4:

assertEquals("Check researchers size", 4, loader.getNumResearchers());

I then ran the ant -f junit.build.xml task and it passed successfully. When I recreated the jar file and ran the jar, the fourth researcher did not show up in the table. This is the expected result, however, because the size of the researcher table is hard coded into the system instead of being based on the number of researchers in the researcher.example.xml file.

4. Summary and Lessons Learned

After looking at Michal's code I realized just how difficult void methods are to test. A lot of the time, there is no effective way to test the method using JUnit because no values are returned. And if there is a lot of code in the void method, then that can make JUnit testing pretty worthless. In this particular case, testing can be done on the void methods visually by inspecting the tables and visually checking to see that they have the rights results in them. However, this defeats the point of using the JUnit ant task.

Another interesting lesson learned from this exercise is that just because the various ant tasks run successfully on your computer, does not mean that they run successfully on someone else's computer. Michal emailed me saying that the tasks run successfully on his machine and provided a screenshot as evidence. However, when I ran the tasks on my machine, the findbugs.build.xml task had 1 warning. At this point, the only thing I can think of is that maybe we are using different versions of findbugs? Irregardless of the discrepancy though, the warning that it generated was correct since calling the toString() method on a string is unnecessary.
After further review, it turns out that I was using FindBugs 1.2.0 and Michal was using FindBugs 1.2.1. So one lesson learned is that it is important that everyone is using the same version of all software engineering tools

I've also learned from reviewing Michal's code, that the code I came up with for my own system needs to be revised so that it can be better tested. I will revise my code by adding another return method and by making my methods return testable values. This way, I can write better tests for my system which will better insure that it is functioning properly.

15.MyISERN-1.0

Group: MyISERN-1-Red

Here is the link to my group's project homepage: MyISERN-1-Red Homepage

This assignment was quite interesting. I have never really worked in a group on a programming assignment before, so it was a very novel experience for me. What made the assignment difficult was not the programming, but rather getting used to learning and using SVN and Google Projects. Also, at times, I found it difficult to adjust to working with other people. I found that at times I was going about the assignment as if I was working on it by myself. Our group used MSN messenger groups to facilitate communication and to meet, so I would often forget to tell (type) the other people in my group what I was doing. Luckily, whenever I did this, I was never working on the same thing as anyone else in the group. So ultimately, a lesson learned was making sure I vocalize my ideas and thought process to the group as often as possible, so that we can all stay on the same page and do software engineering in a coordinated and efficient manner.

Another difficult aspect was trying to meet in person. Even during the school week, it is somewhat difficult to coordinate everyone's schedule to be able to meet in person. In the real world of software development, this is not really a problem since everyone is working in the same office. However, as University students, we have different class and work schedules so coordinating all of that can be difficult. Luckily, through the use of MSN, we were able to conduct functional (if not rather informal) meetings online. MSN (or any instant messenger) proved to be a rather useful tool because we could use it to bounce ideas off of each other while we were programming. We could also use it to ask each other for help in areas that we were having problems and to check on each other's progress. In one sense, it was kind of like we were programming and working in the same office.

Working with JAXB and XML was a little difficult at first because I have had very little experience with either. However, once I got the basic understanding of JAXB down, I was able to utilize it to work with the example XML files that were provided. The tutorial for JAXB was very useful to gain a basic understanding of it. In the future, if I am working with unfamiliar tools or aspects, I will definitely look for tutorial type documentation.

Here is the link to my group's project homepage: MyISERN-1-Red Homepage

14.CM.Practice

Overall, I felt that this assignment was pretty straight forward. Even though I was using SVN and Google Project for the first time, the use of both of them was pretty intuitive. Because of that, I was able to complete all three tasks successuflly. One problem I had with SVN was that I had committed both my bin and build folders so I had to figure out how to delete them. Eventually, I realized that the TortoiseSVN option when you right click on something allows you to do a lot of things, including deleting files and folders from the trunk directory. The only other thing that I had to get used to with SVN was the icons that appear on the folders. When the bright red "!" appears on a folder or file that you have made changes to, but not committed, it makes it seem like you did something wrong when you really haven't.

As far as lessons learned, because of the simplicity of this assignment, I haven't really learned a lesson other then to check the TortoiseSVN menu option for various features. I'm sure in the next assignment, I will learn more valuable lessons as I really start to work with SVN and Google Projects.

My Project website