This exercise involved writing the use cases for the future MyISERN system. They were derived by talking to Dr. Johnson in our class.
From the flaming (OK, its not that bad) that happened on the class discussion board, one thing seems clear to me - sometimes the disagreement between client and developer can turn ugly. I know Dr. Johnson doesn't mean it in a bad way, but there are some experiences I can recall where the client insists the system is implemented in a certain way, while the developer knows that it is infeasible to implement it in that way.
And... well, this exercise brought back some of those memories :-(
The other thing I learned was a little more specific knowledge about the use cases. Many of them I would unknowingly do (as in rephrase them to be understandable to the client), but it was just nice to know there is some sort of "tao" about designing them.
Monday, October 22, 2007
21. MyISERN-1.2
This entry continues the MyISERN project from last time.
Updated link (Version 1.2): http://myisern-1-silver.googlecode.com/files/myisern-xml-1.2.1022.zip
For this installment we had to implement a command-line data entry system for the ISERN system, as well as input data that was given to us.
What was difficult about this assignment?
I'd say the biggest difficulty was the sheer amount of things to do in the course of 1-2 weeks. (Use cases, data entry module, data entry, presentation) I started almost immediately on the tasks (almost because of the code review from before), and still felt like there wasn't enough time. Then again, Parkinson's law seems to hold in general.
What problems were encountered in organizing the group and carrying out the work?
I'd say again the problem of in-person sessions were a problem again, due to circumstances beyond our control. Aside from that, splitting data entry was also difficult since many items link to other items.
Were all of the assigned tasks completed? If not, why not?
Yes. Were the completed in a satisfactory manner? That I'm not sure about.
I think this might be a good example for the real world, though, where sometimes we may come across a situation where it is not possible to do everything perfectly, and some compromises may need to be made in order to finish a project.
What will you do differently during the next Milestone to improve the process and the product of your efforts?
I want to say "start earlier" but we did start at a fairly early time anyways. The only thing that comes to mind is the line my professor said, along the lines of "work smarter, not harder". Thus, the solution seems to be to make the process more efficient.
Updated link (Version 1.2): http://myisern-1-silver.googlecode.com/files/myisern-xml-1.2.1022.zip
For this installment we had to implement a command-line data entry system for the ISERN system, as well as input data that was given to us.
What was difficult about this assignment?
I'd say the biggest difficulty was the sheer amount of things to do in the course of 1-2 weeks. (Use cases, data entry module, data entry, presentation) I started almost immediately on the tasks (almost because of the code review from before), and still felt like there wasn't enough time. Then again, Parkinson's law seems to hold in general.
What problems were encountered in organizing the group and carrying out the work?
I'd say again the problem of in-person sessions were a problem again, due to circumstances beyond our control. Aside from that, splitting data entry was also difficult since many items link to other items.
Were all of the assigned tasks completed? If not, why not?
Yes. Were the completed in a satisfactory manner? That I'm not sure about.
I think this might be a good example for the real world, though, where sometimes we may come across a situation where it is not possible to do everything perfectly, and some compromises may need to be made in order to finish a project.
What will you do differently during the next Milestone to improve the process and the product of your efforts?
I want to say "start earlier" but we did start at a fairly early time anyways. The only thing that comes to mind is the line my professor said, along the lines of "work smarter, not harder". Thus, the solution seems to be to make the process more efficient.
Tuesday, October 16, 2007
22. MyISERN1.1 Review
For this code review, I once again reviewed the code of the blue group. My rationale for choosing the same group is that I wanted to see how the code has improved over the last week.
1. Installation Review
The system didn't install as straightforward, which I believe was largely due to the incorporation of SWT into the code. The idea of putting a GUI into the program is a great idea, and it might be true that this point may have been early to implement it.
Steps taken to get the code to compile:
- Installation of SWT
- Modification of project to remove org.eclipse.swt and added SWT jar files to classpath
At this point, Eclipse was able to run; however, ant at the command line did not. Attempts were made to change the main class, but it didn't work. At this point I gave up and just figured to do all my testing via the Eclipse IDE.
2. Code Format and Conventions Review
Verify didn't pass. Checkstyle reported a redundant import statement - mainly due to the import statement importing the package the file was stored in. (line 7 of TestMyIsernXmlLoader.java)
Aside from this, verify passes.
No major coding violations were readily noted.
3. Testing
Black box
The following tests were used in our (silver) group's code, and was thus considered here:
- Checking unique IDs amongst all lists
- Checking years
- Checking validity of links
- Listing an object for a valid ID
- Listing an object for an invalid ID
- Listing an object for a null ID
- Listing all of a type of object
- Listing organizations with integer parameter valid
- Listing organizations with integer parameter zero
- Listing organizations with integer parameter negative
Also, checking for a non-null name was specified; however, JAXB does this automatically, so it wasn't tested.
White box
EMMA reports 62% overall coverage. The following were areas that weren't covered:
- Parser class. This command processes command line arguments, it seems. It didn't seem to be used much.
- MyIsern class. This is mainly due to the unimplemented GUI interface.
- MyIsernXmlLoader class. This was covered except for the invalid data cases.
Break da buggah
For this test, I took the malformed data that I used for my testing, where the invalid entries would hopefully be noted by the parser. The XML has invalid entries in two ways:
- There are two Philip Johnsons in the researchers file.
- There is an invalid year of 2050 in one of the collaborations.
Result: The duplicate Philip Johnson was detected, but the invalid organization (with the year 2050) was not.
4. Conclusions
The implementation of additional features sometimes makes development a lot more difficult, as in the case with easter eggs. I recall one of my prior ICS instructors mentioning how development frowns upon easter eggs because they are difficult to test since they are hidden in the functionality of the program. In this case, what seemed to be a useful feature seems to be more of a headache, since it made the building of the system more difficult.
This also is a good example of the difficulty of being IDE-independent. To me, it seemed like a lot of the development was done in Eclipse, and running the Ant build files from the command prompt didn't work as expected. I'm also suspecting this relates to the added library, since the creation of the JAR file did work the last time I reviewed this code.
Also, documenting the SWT_HOME environment variable in the documentation would have been helpful. It is difficult to sometimes do this though, since not everyone has access to a clean installation of an operating system.
Finally, I would like to make a comment of keeping multiple copies of a single file in the src folder - this generally is a bad idea. From my knowledge of CVS systems, Subversion keeps your revisions automatically in the repository - this is the purpose of keeping a repository.
On a side note, I still envy the table printout format :)
1. Installation Review
The system didn't install as straightforward, which I believe was largely due to the incorporation of SWT into the code. The idea of putting a GUI into the program is a great idea, and it might be true that this point may have been early to implement it.
Steps taken to get the code to compile:
- Installation of SWT
- Modification of project to remove org.eclipse.swt and added SWT jar files to classpath
At this point, Eclipse was able to run; however, ant at the command line did not. Attempts were made to change the main class, but it didn't work. At this point I gave up and just figured to do all my testing via the Eclipse IDE.
2. Code Format and Conventions Review
Verify didn't pass. Checkstyle reported a redundant import statement - mainly due to the import statement importing the package the file was stored in. (line 7 of TestMyIsernXmlLoader.java)
Aside from this, verify passes.
No major coding violations were readily noted.
3. Testing
Black box
The following tests were used in our (silver) group's code, and was thus considered here:
- Checking unique IDs amongst all lists
- Checking years
- Checking validity of links
- Listing an object for a valid ID
- Listing an object for an invalid ID
- Listing an object for a null ID
- Listing all of a type of object
- Listing organizations with integer parameter valid
- Listing organizations with integer parameter zero
- Listing organizations with integer parameter negative
Also, checking for a non-null name was specified; however, JAXB does this automatically, so it wasn't tested.
White box
EMMA reports 62% overall coverage. The following were areas that weren't covered:
- Parser class. This command processes command line arguments, it seems. It didn't seem to be used much.
- MyIsern class. This is mainly due to the unimplemented GUI interface.
- MyIsernXmlLoader class. This was covered except for the invalid data cases.
Break da buggah
For this test, I took the malformed data that I used for my testing, where the invalid entries would hopefully be noted by the parser. The XML has invalid entries in two ways:
- There are two Philip Johnsons in the researchers file.
- There is an invalid year of 2050 in one of the collaborations.
Result: The duplicate Philip Johnson was detected, but the invalid organization (with the year 2050) was not.
4. Conclusions
The implementation of additional features sometimes makes development a lot more difficult, as in the case with easter eggs. I recall one of my prior ICS instructors mentioning how development frowns upon easter eggs because they are difficult to test since they are hidden in the functionality of the program. In this case, what seemed to be a useful feature seems to be more of a headache, since it made the building of the system more difficult.
This also is a good example of the difficulty of being IDE-independent. To me, it seemed like a lot of the development was done in Eclipse, and running the Ant build files from the command prompt didn't work as expected. I'm also suspecting this relates to the added library, since the creation of the JAR file did work the last time I reviewed this code.
Also, documenting the SWT_HOME environment variable in the documentation would have been helpful. It is difficult to sometimes do this though, since not everyone has access to a clean installation of an operating system.
Finally, I would like to make a comment of keeping multiple copies of a single file in the src folder - this generally is a bad idea. From my knowledge of CVS systems, Subversion keeps your revisions automatically in the repository - this is the purpose of keeping a repository.
On a side note, I still envy the table printout format :)
Monday, October 15, 2007
18. MyISERN-1.1
For this assignment we (myself and Laura) continued where we left off of and added new functionality to the system.
The source code can be found at http://myisern-1-silver.googlecode.com/files/myisern-xml-1.1.1015.zip
What was difficult about this assignment?
I think the main issue was dividing up the work in the beginning - there were two 'features' to implement, and it is still unknown to this date whether or not they were both equal in terms of the amount of work. (We split the two between the two of us). It seemed to turn out fine, though.
The other issue came with EMMA coverage - it was mentioned in class that coverage is quite possibly a misleading metric that many companies go by; however, I also had a guilty voice that went off every time I didn't see a 100%. Unfortunately, I did use an enumerated type in my code, and since I don't use all the features of an enumerated type, it won't reach 100% coverage.
What problems were encountered in organizing the group and carrying out the work?
The biggest challenge was the comment that Dr. Johnson made in class about meeting in person. Meeting in person proved to be very difficult; however, this seemed to be made up by communicating online frequently. (True, you don't get to see neat tricks from each other if you do this)
Other than this, it went pretty smoothly. Frequent communication encouraged working on the code before the due date.
Were all of the assigned tasks completed? If not, why not?
Yes.
What will you do differently during the next Milestone to improve the process and the product of your efforts?
It would be good if we could meet in-person more often, although this is difficult due to scheduling issues. Aside from this, things went pretty smoothly, at least in my opinion.
The source code can be found at http://myisern-1-silver.googlecode.com/files/myisern-xml-1.1.1015.zip
What was difficult about this assignment?
I think the main issue was dividing up the work in the beginning - there were two 'features' to implement, and it is still unknown to this date whether or not they were both equal in terms of the amount of work. (We split the two between the two of us). It seemed to turn out fine, though.
The other issue came with EMMA coverage - it was mentioned in class that coverage is quite possibly a misleading metric that many companies go by; however, I also had a guilty voice that went off every time I didn't see a 100%. Unfortunately, I did use an enumerated type in my code, and since I don't use all the features of an enumerated type, it won't reach 100% coverage.
What problems were encountered in organizing the group and carrying out the work?
The biggest challenge was the comment that Dr. Johnson made in class about meeting in person. Meeting in person proved to be very difficult; however, this seemed to be made up by communicating online frequently. (True, you don't get to see neat tricks from each other if you do this)
Other than this, it went pretty smoothly. Frequent communication encouraged working on the code before the due date.
Were all of the assigned tasks completed? If not, why not?
Yes.
What will you do differently during the next Milestone to improve the process and the product of your efforts?
It would be good if we could meet in-person more often, although this is difficult due to scheduling issues. Aside from this, things went pretty smoothly, at least in my opinion.
Wednesday, October 10, 2007
16. MyIsernReview
For this review, I reviewed the MyIsern1.0 system for Sonwright Gomez, who was a part of the myisern-1-blue group.
1. Installation review
Installation was straightforward - the package downloaded and unzipped fine. Verify passed. The only point I would mention here is that the JAR file was included with the installation, which added 2 megabytes to the archive.
2. Code format and conventions review
The following formatting violations are noted:
3. Test Case Review
Black Box: The only test cases in the code assume the test data equals the sample data. Unfortunately, these test cases will fail if the sample XML data changes.
The following tests are missing from the code:
- Null entries for values in an entry (e.g. 0-character strings)
- Empty XML file (e.g. 0 bytes, but exists)
- No XML file (e.g. does not exist in file system)
- File with long field values, but are still valid
- Entry with an invalid type (e.g. a letter in the year field)
White Box: EMMA reports 100% code coverage. This means that all code that is written is executed in the test cases that were written.
Break da buggah: After executing the black box tests, the following results occurred:
- Null entries for values in an entry: NullPointerException
- Empty XML file (e.g. 0 bytes, but exists): UnmarshalException/SAXParseException
- No XML file (e.g. does not exist in file system): FileNotFoundException
- File with long field values, but are still valid: executed OK
- Entry with an invalid type (e.g. a letter in the year field): NullPointerException
4. Summary and Lessons Learned
This exercise seemed very trivial. However, despite being very easy to do, it is still fairly easy to break. Many of these tests are circumstances that would not happen very often; however, when they do happen, the system can come crashing down and cause downtime.
This assignment was different from the last since we were told about two days before the due date that testing would be performed on our code. This gave us motivation to improve our test cases. It would be a good idea to possibly set aside a couple of days before the due date to work on test cases if the project is finished ahead of schedule.
1. Installation review
Installation was straightforward - the package downloaded and unzipped fine. Verify passed. The only point I would mention here is that the JAR file was included with the installation, which added 2 megabytes to the archive.
2. Code format and conventions review
The following formatting violations are noted:
| File | Line Number | Violation | Notes |
| MyIsernXmlLoader.java | 31 | EJS-35 | Use meaningful Javadoc comments - should not mention it is 'sample' code anymore |
| MyIsernXmlLoader.java | 152, 224, 288 | EJS-9 | Explain the meaning of the constant 3000. |
| MyIsernXmlLoader.java | 211 | EJS-36 | Use /* ... */ to comment code rather than // |
3. Test Case Review
Black Box: The only test cases in the code assume the test data equals the sample data. Unfortunately, these test cases will fail if the sample XML data changes.
The following tests are missing from the code:
- Null entries for values in an entry (e.g. 0-character strings)
- Empty XML file (e.g. 0 bytes, but exists)
- No XML file (e.g. does not exist in file system)
- File with long field values, but are still valid
- Entry with an invalid type (e.g. a letter in the year field)
White Box: EMMA reports 100% code coverage. This means that all code that is written is executed in the test cases that were written.
Break da buggah: After executing the black box tests, the following results occurred:
- Null entries for values in an entry: NullPointerException
- Empty XML file (e.g. 0 bytes, but exists): UnmarshalException/SAXParseException
- No XML file (e.g. does not exist in file system): FileNotFoundException
- File with long field values, but are still valid: executed OK
- Entry with an invalid type (e.g. a letter in the year field): NullPointerException
4. Summary and Lessons Learned
This exercise seemed very trivial. However, despite being very easy to do, it is still fairly easy to break. Many of these tests are circumstances that would not happen very often; however, when they do happen, the system can come crashing down and cause downtime.
This assignment was different from the last since we were told about two days before the due date that testing would be performed on our code. This gave us motivation to improve our test cases. It would be a good idea to possibly set aside a couple of days before the due date to work on test cases if the project is finished ahead of schedule.
Monday, October 8, 2007
15. MyISERN 1.0
For this assignment we researched JAXB and wrote a program to output the XML data to the console.
Link to project: http://code.google.com/p/myisern-1-silver/
Lessons Learned:
JAXB and XML - An earlier program I wrote involved parsing XML data. I ended up reading the file manually and parsing the data stream. Had I known about this, I probably would have used this instead. The library that comes by default with Java didn't seem adequate at the time, though - this was about two years ago.
Group Software Development - It was actually a pretty good experience. Regarding software development in general, though, it sometimes feels like more of a disadvantage than an advantage - in many cases, if there was a design choice, if I were working on my own I would go ahead with a decision, but once the group factor comes in, it becomes an issue to consult the other group members before coming to a decision. The advantage, though, comes in being able to proofread each other's work - as I mentioned in a previous entry, it is difficult to hold a knife to your own work, but easy to do it to another person's.
Anything else - Again, this is a trivial assignment that ended up being not-so-trivial. If you look at our code, you'll see why ^^
Link to project: http://code.google.com/p/myisern-1-silver/
Lessons Learned:
JAXB and XML - An earlier program I wrote involved parsing XML data. I ended up reading the file manually and parsing the data stream. Had I known about this, I probably would have used this instead. The library that comes by default with Java didn't seem adequate at the time, though - this was about two years ago.
Group Software Development - It was actually a pretty good experience. Regarding software development in general, though, it sometimes feels like more of a disadvantage than an advantage - in many cases, if there was a design choice, if I were working on my own I would go ahead with a decision, but once the group factor comes in, it becomes an issue to consult the other group members before coming to a decision. The advantage, though, comes in being able to proofread each other's work - as I mentioned in a previous entry, it is difficult to hold a knife to your own work, but easy to do it to another person's.
Anything else - Again, this is a trivial assignment that ended up being not-so-trivial. If you look at our code, you'll see why ^^
14. CM.Practice
This assignment involves using SVN over Google Code to set up and use projects.
1. Install a SVN client
Straightforward. I installed TortoiseSVN since I am using a Windows system. This took about 5 minutes.
2. Modify an existing Google Project.
This was also straightforward. I used CVS before and the checkout/commit process was pretty straightforward. The only part I didn't like was running verify before and after commits. This took about 15 minutes.
3. Create a new Google Hosting project.
This was where most of the time was spent. The first difficult was to find the actual link to create the project, since code.google.com does not provide an obvious link. Next, choosing a license was iffy, and I just copied what was chosen in the slides. It might be an interesting topic to discuss in class, however.
Finally, creating the discussion lists and commit lists was a pain since I had to go to Google Groups and create the lists, then go back to the project page and add them. If this was integrated into the project creation step, it would be easier (and less time consuming).
After the project setup I uploaded my files. Unfortunately, I messed up the first time (I uploaded it as a single folder) so I removed it. Then I uploaded up, then renamed the project folder to "trunk". It worked. However, afterwards I noticed the notes renamed the folder to 'trunk' before uploading it.
I wanted to avoid uploading the files individually since TortoiseSVN warned me that uploading the 11 files or so would cause 11 revisions.
This took about an hour.
Lessons Learned
Even the simplest thing can be a pain to set up, sometimes. Otherwise, I think the process was straightforward. Google could work a little on the interface for creating a project, but otherwise this was pretty trivial.
1. Install a SVN client
Straightforward. I installed TortoiseSVN since I am using a Windows system. This took about 5 minutes.
2. Modify an existing Google Project.
This was also straightforward. I used CVS before and the checkout/commit process was pretty straightforward. The only part I didn't like was running verify before and after commits. This took about 15 minutes.
3. Create a new Google Hosting project.
This was where most of the time was spent. The first difficult was to find the actual link to create the project, since code.google.com does not provide an obvious link. Next, choosing a license was iffy, and I just copied what was chosen in the slides. It might be an interesting topic to discuss in class, however.
Finally, creating the discussion lists and commit lists was a pain since I had to go to Google Groups and create the lists, then go back to the project page and add them. If this was integrated into the project creation step, it would be easier (and less time consuming).
After the project setup I uploaded my files. Unfortunately, I messed up the first time (I uploaded it as a single folder) so I removed it. Then I uploaded up, then renamed the project folder to "trunk". It worked. However, afterwards I noticed the notes renamed the folder to 'trunk' before uploading it.
I wanted to avoid uploading the files individually since TortoiseSVN warned me that uploading the 11 files or so would cause 11 revisions.
This took about an hour.
Lessons Learned
Even the simplest thing can be a pain to set up, sometimes. Otherwise, I think the process was straightforward. Google could work a little on the interface for creating a project, but otherwise this was pretty trivial.
Subscribe to:
Posts (Atom)