The Three Prime Directives discussed throughout this semester are defined Here.
To summarize, they are
1. The system successfully accomplishes a useful task. (Is it useful?)
2. An external user can successfully install and use the system. (Is it usable?)
3. An external developer can successfully understand and enhance the system. (Is it enhanceable?)
For each software engineering tool or method we have used or discussed this semester, I will briefly outline how it pertains to these directives (if at all). Rather than specifically describing each tool, I will explain how each type of tool affects the Three Prime Directives.
1. Interactive Development Environments (Eclipse, VisualStudio, etc.)
Interactive Development Environments (IDEs) describe a huge variety of tools used by many types of software developers. They range from complete, contained tool kits to only slightly enhanced text editors. The goal of IDEs is to enable more efficient and correct programming.
IDEs do not directly affect any of the Three Prime Directives. Most of the tools provided IDEs do not affect the directives at all. Only the third directive could potentially be affected by the use of these tool kits. If the user uses a specific, defined set of tools, it could enable a developer to more easily recreate the original development environment. Use of the same development environment could make it easier for a developer to read, understand, and improve or maintain the system.
An example of a powerful development tool provided by most IDEs is colorized keywords for a specific language. Eclipse provides this tool and it can make reading the code much easier.
2. Coding Standards and Coding Standards Compliance Tools (Checkstyle, etc.)
Coding standards provide clearly defined standards for code style. While style may not directly affect the system itself, it greatly affects the readability of the code. Coding standards compliance tools enable the system developer to ensure all of the code complies with a defined standard.
Since the style of the code is not seen by the user, the first two Prime Directives do not affected by coding standards. However, following coding standards can greatly improve the readability of the code. Therefore, it can make the final system much easier to enhance and maintain, even by the original developer.
Checkstyle, the Java coding standards tool used this semester, provides clear errors when the specified coding standards are not met. It ensures the code is more easily readable and all members of a software team follow the same standards of code.
3. Build Systems (Ant, Make, etc.)
Build systems provide configuration and automation for any or all steps of building of a system. They directly affect every Prime Directive because of the importance of configuration. Many systems must be built first to run on the system. Build systems provide a simple procedure to build, install, or run a system. Without this procedure, configuration can be very difficult and time-consuming for a user or developer.
Make is a very popular and heavily used build system. It allows a developer to create a file that will compile, install, or perform many other tasks automatically. When a user or developer downloads a system, they can simple type "make", rather than having to follow a complex series of instructions.
4. Automated Quality Assurance Tools (PMD and FindBugs, etc.)
Automated quality assurance tools are a family of tools that provide automated, standardized tests that can be run on a developing or completed system. Many of these tools parse the code directly to try and detect certain types of errors. While many developers do not use these types of tools, they can affect the second two Prime Directives by improving the quality of the system. A system with less bugs will be a system that is more usable and and easier to enhance.
The Java tools we used this semester (PMD and FindBugs), while sometimes annoying and difficult to satisfy, was useful at times. It would occasionally reveal bugs that would have been problematic.
5. Black and White Box Testing
Testing is a very important phase in the development of any system. Black box testing focuses on the overall behavior of the system (or components), while white box testing is concerned with details of the code itself. Both of these systems can improve the quality of the system. As mentioned earlier, system quality affects Prime Directives two and three. In addition, black box testing can increase usefulness of the system (Prime Directive 1) by revealing requirements and desired behavior of the system.
For most of the software I created this semester, I used both of these testing techniques. I created many "use case" types of tests for black box testing. These tests performed certain actions a user may take and test the outcome. I also used the tool EMMA to test code coverage of white box testing.
6. Automated Testing Tools (JUnit, HttpUnit, etc.)
Automated testing tools provide a simple and routine way of testing the system. Like previously discussed, this can increase the overall quality of the system, thereby increasing the ability to achieve the Three Prime Directives. For the Java software I created this semester, I used JUNIT to run tests on the system. It was a very useful and powerful tool that made the testing process simple and straightforward. It also made it easy to test components during development, allowing test-driven design.
7. Configuration Management (CVS, SVN, etc.)
Configuration management tools are essential for any software project with more than one member (and very useful for every project). CM tools provide a safe and effective way of managing, tracking, and documenting changes to the system. In addition to making development much easier and smoother, it also improves the quality of the system (thereby affecting the Three Prime Directives). The documentation and tracking of changes and versions also makes it easier for developers to enhance and change the system.
I used SVN this semester and found it rather useful. It took some learning to be able to quickly and easily work with SVN, but once I was comfortable with it I found it very useful. It made working with group members easier and allowed for easy version control and documentation.
8. Issue Driven Project Management
Issue driven management is a process of dividing the tasks of development into issues and working on individual issues at a time. While it could be argued that it increase overall system quality, this method of development does not, necessarily, help the system to satisfy the Three Prime Directives. Use of this type of organization is not essential to a system, though for some projects it can be a very useful documentation and communication tool. If used correctly, the documentation it provides can be useful for developers enhancing the system.
I found the Google project hosting issue tracker to be a useful tool when I was working in groups. It provided a method of task division that aided group work. I do not, however, think it directly affected the Three Prime Directives in my experience.
9. Use Cases
Use cases are a powerful tool for requirements definition, elicitation, and testing. Since use cases are directly concerned with the users and requirements of the system, they play a large role in satisfying Prime Directive 1 ("is the system useful?"). With proper use case definition, one can make sure the system meets the needs of the users and provides clear use. In addition, it can improve the overall quality of the system through better black box testing and acceptance testing.
I used a form of use cases in my black box testing for many projects. With the use of JUNIT and HTTPUNIT, I tested specific behavior of a user to guarantee the system met the users needs.
10. Software Review
Software review involves having a third party review and test a system. This is the only real way to be sure the system meets the Prime Directives. No developer testing or tools can guarantee the system meets the Prime Directives. Having a third party install, run, and test the system can directly make sure the Prime Directives are met (at least 2 and 3).
We were asked to have other groups test our software several times throughout this semester. I found their review and feedback useful, especially the bug description and testing review.
11. Agile Methods (XP, Scrum, etc.)
Agile methods are techniques of a specific family of software development models. They stress simplicity, rapid releases, close interaction with users, and other techniques. This style of software development is not essential, and is more of a project management choice. It is a debate as to how this affects the Three Prime Directives, as there are many other software development models that can be used. For example, the spiral model or waterfall model may be more appropriate for certain projects.
12. Open Source Licenses (GPL, CPL, etc.)
There are many different open source licenses, but they all share the goal of making source code available. Projects that are open source tend to be community types of projects that have many people working on them. This type of development environment can produce high quality products in a short time.
The use of open source licenses (when paired with community support and communication) can also guarantee satisfaction of the Three Prime Directives. The first Prime Directive is met because the community would not work on a system that is not useful. With so many people installing running, and working on the system, it is guaranteed to be usable (Prime Directive 2). Finally, with so many developers, there has to be extensive documentation and methods to enhance the system (Prime Directive 3).
A prime example of the power of open source licenses is the development of the Linux operating system. This open source system is considered by many to be superior to other, proprietary systems such as Windows.
13. Online Hosting Services (Google Project Hosting, SourceForge, etc.)
There are many online hosting services available on the Internet today. They provide easy access to source code, documentation, and binaries. Making a system more widely available along with its documentation and use/development guides helps the system meet all three Prime Directives. More people will use the system, it will be easier to obtain and install, and the resources will be available to users and developers.
I used Google project hosting this semester and found it a easy to use tool for uploading of project material.
Summary
All of the tools and methods we have been introduced to this semester help in the developing of a system that meets the Three Prime Directives. There is no one tool that will solve all the problems of software development, but many can help. With the right tools and methods, the development of a useful, usable, and enhanceable system is possible.
Sunday, December 9, 2007
Friday, November 16, 2007
29.MyIsern-1.3-review
Reviewing Team Purple.
Team Purple distribution available Here
Installation review:
I began, as any user should, by looking at the installation guide available Here. The guide is short with just a few bulleted points. It was all very simple except for a couple points of confusion:
- "run the junit task..." is a bit confusing. I was not immediately certain that this was the command "ant -f junit.build.xml."
- There is no mention about the URL of the project once it is deployed. I had to go into the tomcat manager to find the exact URL of it. It would be helpful to mention this in the installation guide.
Other then the above confusing points, it was quite simple to install and run the MyIsern-purple system.
I then ran the verify ant task. I was quite impressed with the sheer volume of tests running. It seems they tested the project quite thoroughly. Verify, however, does not pass. Some warnings from Findbugs causes it to fail. The 9 Findbugs warnings range from simple redundant ToString() operations to perhaps more complex problems involving non-serializable objects and HttpSessions.
Code format and conventions review:
I was quite surprised by the number of classes that were present in this code. However, the design seemed quite clean. I could not find many code conventions violations, though I did find some redundancy in certain parts of the code:
- The login() method in the LoginActionBean.java file separately checks if the username, password, or both failed. This can all be done with a single check to greatly reduce the complexity.
- In the CollaborationFormActionBean.java file on line 129 the .toString method is used on a String.
- Perhaps some of the class names are too verbose. For example CollaborationFormActionBean is a bit long for a class name.
Most of the code seemed to follow the guidelines quite well. I could not find many violations.
Test case review:
As I mentioned earlier, there are a rather large number of tests for this project. Running the junit task takes around 30 seconds to complete with 42 total tests running.
Black Box Perspective:
Since black box testing should focus on I/O behavior, it must deal with the UI for this type of project. UI testing, however, can be difficult on this type of client-server application. While there were a large number of tests, particularly dealing with login/logout behavior, some of the more basic tests of the linking system were missing. To greater cover black box testing, it may be useful to create a series of tests (perhaps another test class) that checks all links and navigation through the system. A large part of web applications is navigation through the system, so it is important to test it.
There may also be an issue with concurrency, which is nearly impossible to test for. I would think it would fall into the black box perspective since concurrency issues come about when certain I/O events take place at certain times. There are no tests that deal with concurrency, though I do not think it is even feasible to test concurrency.
White Box Perspective:
The emma results were fairly good for this project, considering the difficulty of testing server-side components. The results from emma were
Emma Coverage summary
class: 88% (29/33)
method: 67% (172/255)
block: 61% (1908/3153)
line: 62% (405.1/656)
For many of the classes, general tests were performed over the entire class (or functionality), yet not many had tests for each individual method. The coarse granularity of the tests focused more on Black box testing. For example, the LoginActionBean class only have tests for the SecurityFilter and various standard login events. Each specific method of the class is not tested, as should be attempted with a white box testing perspective. Many very small tests could be added to test each small piece of code. This could increase the coverage as well.
Break Da Buggah:
I think many people had trouble getting the system complete by this stage, so I was not surprised to find an unfinished section of the project. The "about us" link leads to a non-existent page called reports.jsp. This is simply a finishing problem and not an actual problem with the project.
Another small bug I found involved adding new objects. When a new collaboration is being added, the Years list is not filled with any values, so it is impossible to specify what years the collaboration took place during. This is simply a matter of propagating the list even when a new entry is being created.
User Interface review:
At this point in the project, I try not to focus on aesthetics of the pages at all. The "fluff" can be added later once all of the functionality is available.
The basic navigation of the system is quite nice. It is easy to view each list and navigate to the edit page. I like the feature that automatically propagates the edit form when the user clicks on the edit button for a particular row. It reduces mouse clicks and enables users to quickly and easily make changes. The use of thumbnails for researchers is nice as well. Perhaps even logo thumbnails could be added for the organizations table.
I think an easy way to see all of the data for every entry would be nice. The lists for each type (Researcher, Collaboration, or Organization) only contain the names. Some users may way to see every Researcher and their organizations in a single table, for example. Either an additional page is needed to display this information or the lists could contain all the data relevant to each object.
The system works quite well with a small amount of screen space. At 1/3 width and 1/3 height of my screen, I was still able to see the tables and all of the text boxes (on the add/edit pages).
One small change I would suggest is using a button instead of link for the "create" button after the tables. Using a button and perhaps placing an additional one just before the table could make it easier for new users.
Summary and Lessons Learned:
I learned a great deal from reviewing this project, since our project is less polished at this stage. While there are many components to this system, they are well integrated and nearly everything works perfectly. After reviewing this project, I may break up my project at this point to modularize it.
The login system using the SecurityFilter works very well. The login system used by my project is very different. Perhaps the SecurityFilter method is better.
I also realized how thorough the testing needs to be for this project. Since 1.2 this project has become much more complex and the volume and quality of test cases needs to reflect that. I will add many more tests to my own project now that I have seen many methods of testing this type of project.
Team Purple distribution available Here
Installation review:
I began, as any user should, by looking at the installation guide available Here. The guide is short with just a few bulleted points. It was all very simple except for a couple points of confusion:
- "run the junit task..." is a bit confusing. I was not immediately certain that this was the command "ant -f junit.build.xml."
- There is no mention about the URL of the project once it is deployed. I had to go into the tomcat manager to find the exact URL of it. It would be helpful to mention this in the installation guide.
Other then the above confusing points, it was quite simple to install and run the MyIsern-purple system.
I then ran the verify ant task. I was quite impressed with the sheer volume of tests running. It seems they tested the project quite thoroughly. Verify, however, does not pass. Some warnings from Findbugs causes it to fail. The 9 Findbugs warnings range from simple redundant ToString() operations to perhaps more complex problems involving non-serializable objects and HttpSessions.
Code format and conventions review:
I was quite surprised by the number of classes that were present in this code. However, the design seemed quite clean. I could not find many code conventions violations, though I did find some redundancy in certain parts of the code:
- The login() method in the LoginActionBean.java file separately checks if the username, password, or both failed. This can all be done with a single check to greatly reduce the complexity.
- In the CollaborationFormActionBean.java file on line 129 the .toString method is used on a String.
- Perhaps some of the class names are too verbose. For example CollaborationFormActionBean is a bit long for a class name.
Most of the code seemed to follow the guidelines quite well. I could not find many violations.
Test case review:
As I mentioned earlier, there are a rather large number of tests for this project. Running the junit task takes around 30 seconds to complete with 42 total tests running.
Black Box Perspective:
Since black box testing should focus on I/O behavior, it must deal with the UI for this type of project. UI testing, however, can be difficult on this type of client-server application. While there were a large number of tests, particularly dealing with login/logout behavior, some of the more basic tests of the linking system were missing. To greater cover black box testing, it may be useful to create a series of tests (perhaps another test class) that checks all links and navigation through the system. A large part of web applications is navigation through the system, so it is important to test it.
There may also be an issue with concurrency, which is nearly impossible to test for. I would think it would fall into the black box perspective since concurrency issues come about when certain I/O events take place at certain times. There are no tests that deal with concurrency, though I do not think it is even feasible to test concurrency.
White Box Perspective:
The emma results were fairly good for this project, considering the difficulty of testing server-side components. The results from emma were
Emma Coverage summary
class: 88% (29/33)
method: 67% (172/255)
block: 61% (1908/3153)
line: 62% (405.1/656)
For many of the classes, general tests were performed over the entire class (or functionality), yet not many had tests for each individual method. The coarse granularity of the tests focused more on Black box testing. For example, the LoginActionBean class only have tests for the SecurityFilter and various standard login events. Each specific method of the class is not tested, as should be attempted with a white box testing perspective. Many very small tests could be added to test each small piece of code. This could increase the coverage as well.
Break Da Buggah:
I think many people had trouble getting the system complete by this stage, so I was not surprised to find an unfinished section of the project. The "about us" link leads to a non-existent page called reports.jsp. This is simply a finishing problem and not an actual problem with the project.
Another small bug I found involved adding new objects. When a new collaboration is being added, the Years list is not filled with any values, so it is impossible to specify what years the collaboration took place during. This is simply a matter of propagating the list even when a new entry is being created.
User Interface review:
At this point in the project, I try not to focus on aesthetics of the pages at all. The "fluff" can be added later once all of the functionality is available.
The basic navigation of the system is quite nice. It is easy to view each list and navigate to the edit page. I like the feature that automatically propagates the edit form when the user clicks on the edit button for a particular row. It reduces mouse clicks and enables users to quickly and easily make changes. The use of thumbnails for researchers is nice as well. Perhaps even logo thumbnails could be added for the organizations table.
I think an easy way to see all of the data for every entry would be nice. The lists for each type (Researcher, Collaboration, or Organization) only contain the names. Some users may way to see every Researcher and their organizations in a single table, for example. Either an additional page is needed to display this information or the lists could contain all the data relevant to each object.
The system works quite well with a small amount of screen space. At 1/3 width and 1/3 height of my screen, I was still able to see the tables and all of the text boxes (on the add/edit pages).
One small change I would suggest is using a button instead of link for the "create" button after the tables. Using a button and perhaps placing an additional one just before the table could make it easier for new users.
Summary and Lessons Learned:
I learned a great deal from reviewing this project, since our project is less polished at this stage. While there are many components to this system, they are well integrated and nearly everything works perfectly. After reviewing this project, I may break up my project at this point to modularize it.
The login system using the SecurityFilter works very well. The login system used by my project is very different. Perhaps the SecurityFilter method is better.
I also realized how thorough the testing needs to be for this project. Since 1.2 this project has become much more complex and the volume and quality of test cases needs to reflect that. I will add many more tests to my own project now that I have seen many methods of testing this type of project.
Monday, November 5, 2007
25.WebAppQuestions
1. Explain in your own words the meaning of the web "request-response cycle".
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
5. What is the directory and file layout of an installed web application like StackStripes? (This is NOT the same as the directory and file layout of the StackStripes distribution!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
13. What is HttpUnit? How is it different from JUnit? Why is it useful? What is an example use of HttpUnit from the StackStripes system?
HttpUnit provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
14. What needed to be changed in order to implement the Double It button? What didn't need to be changed? What did you learn about the MVC design pattern from this exercise?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty stack.
16. Provide two screen images of your new StackStripes application with the Double It button, one showing the page before and one showing the page after hitting the "Double It" button.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
19. Running 'ant -f junit.build.xml' results in the following target invocations: tomcat.check, tomcat.undeploy, compile, war, tomcat.deploy, junit.tool, junit.report, junit. Explain what each of these targets do.
tomcat.check - checks to make sure Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
The request-response cycle is the method by which web applications retrieve data from sources on the web. The client sends a request to a server that will use the data in the request to return a response. When the client performs some other action, it sends another response and the cycle continues.
2. Explain how servlets facilitate processing of the request-response cycle.
A servlet is a program that runs on the server to handle requests and return responses to the client. Unlike client applets that run on the client side and send requests, a servlet receives requests from the client, performs some operations, and returns a response.
3. How do you login to the Tomcat Manager?
To login to Tomcat Manager you simply run Tomcat on your local machine and connect to http://localhost:8080/ and click on the "Tomcat Manager" link. You are then prompted for the username and password that is defined in the conf/tomcat-users.xml file.
4. What is the Tomcat Manager used for in the StackStripes application?
The Tomcat Manager enables you to make the StackStripes program available to web users. The StackStripes application provides the Tomcat Manager with locations and configuration options of files that are to be deployed on the server and the manager makes them accessible to clients.
Any application that is deployed on Tomcat and therefore available to web users is contained in the webapps directory. Within the webapps directory, each application will have its own directory structure. The StackStripes application has, within its folder in the webapps directory, the following files/folders:
5. What is the directory and file layout of an installed web application like StackStripes? (This is NOT the same as the directory and file layout of the StackStripes distribution!)
META-INF - Contains meta file(s) with various meta data about the application.
WEB-INF - Contains the actual application and configuration files.
index.jsp - The default page that loads when no specific file is provided.
6. How do you build a war directory structure in Ant? Where is this accomplished in the StackStripes application?
A war directory structure can be built using ANT with a build.xml file. The build.xml file for the StackStripes creates a war structure in the "war" target. It contains a war element that creates a .war file in a specific file location defined within the element.
7. How do you install a war directory in a running Tomcat server? What information does the Ant task need to accomplish this?
If configured to automatically deploy, you can simply place a war directory into the webapps folder to install it on the server. The Ant task needs only to know the location of the webapps folder which is available in the $CATALINA_HOME environment variable.
8. What is the "Model2" architecture? What are its advantages?
Model2 is also knows as MVC (or Model View Controller) because it structures the client/server architecture into three components. The model contains any data or structures needed to maintain it (ie. database), the view contains the client presentation, and the controller accepts requests from the client and gives necessary data to the model. This architecture provides modularity and allows each component to be built in such a way that changes to one will not impact the others.
9. What are JSP pages? How are they related to servlets?
JSP (or JavaServer pages) are pages that are compiled into Java servlets on the server. They allow the server to dynamically generate pages in response to a client request.
10. Why is there a delay when retrieving a JSP page for the first time? Where is the Java code for that page stored?
Since they must be compiled into a servlet the first time the page is being retrieved, there is a delay for the JSP compiler to run on the server. However, once the servlet is compiled it is contained within memory and does not need to be compiled for further use.
11. What are JSTL tags? Why are they useful? What is an example JSTL tag from the StackStripes system?
JSTL tags are a set of tags usable within JSP pages provide methods for performing common tasks without the need of embedded Java. Since they allow you to perform tasks without embedded Java, they allow better separation of the application from the user interface defined in the JSP pages. The StackStripes system uses "c:forEach" tag to easily iterate and display all of the elements of the stack.
12. What are Stripes tags? Why are they useful? What is an example Stripes tag from the StackStripes system?
Stripes tags are tags defined by the Stripes web application framework. They enable you to easily link JSP tags with classes and methods in the Java application. Many Stripes tags are needed by the StackStripes system, for example the tag
< stripes:submit value="push" name="push"/>
causes the method called push to be evoked when the user clicks the "push" button.
13. What is HttpUnit? How is it different from JUnit? Why is it useful? What is an example use of HttpUnit from the StackStripes system?
HttpUnit provides a method for visiting and performing operation on websites automatically within code. It allows us to test systems that operate on the web, while JUnit is limited to a single local system. Every test that is performed on the server requires HttpUnit to run. Every test of the JavaActionBean class of the StackStripes uses HttpUnit.
14. What needed to be changed in order to implement the Double It button? What didn't need to be changed? What did you learn about the MVC design pattern from this exercise?
Very little had to be changed to implement the DoubleIt button. I simply had to add a new form to the JSP page and add the functionality to the StackModel class. The controller component did not have to be changed. This exercise illustrated how the MVC architecture allowed functionality to be added without changing every component.
15. What are the equivalence classes that need to be tested for the Double It button?
There were only two equivalence classes that needed to be tested: doubling an empty stack and doubling a non-empty stack.
16. Provide two screen images of your new StackStripes application with the Double It button, one showing the page before and one showing the page after hitting the "Double It" button.
And after clicking the "Double It" button.
17. What is the singleton design pattern? What is an example of its use in StackStripes? Why is it needed?
The singleton design pattern restricts the class to having only a single instantiation. For all users to interact with the same stack, this method is required. The stack in the StackStripes system is defined as a singleton by declaring the constructor as private and defining a single instance variable was static.
18. Some of the StackStripes tests exercise code on the "server side", while others exercise code on the "client" side. Which test classes exercise code on the "server", and which exercise code on the "client"? How does Emma deal with this to create appropriate coverage data?
The tests in TestStackActionBean are run on the server while the tests in TestStackModel run on the client. Emma can collect coverage data from both classes of JUnit test cases, but it cannot collect the data on the server until Tomcat is shutdown. That is why the emma.build.xml file shuts down the Tomcat server.
19. Running 'ant -f junit.build.xml' results in the following target invocations: tomcat.check, tomcat.undeploy, compile, war, tomcat.deploy, junit.tool, junit.report, junit. Explain what each of these targets do.
tomcat.check - checks to make sure Tomcat is currently running on the local machine and that it has the correct login/password.
tomcat.undeploy - deletes StackStripes from the Tomcat server.
compile – compiles the StackStripes system.
war – builds the war directory structure to be deployed on the Tomcat server.
tomcat.deploy – deploys the previously created war file to the Tomcat server.
junit.tool – runs all JUnit tests.
junit.report – creates the JUnit report files.
junit – Runs both the junit.tool and junit.report targets.
26.StackStripesExtension
The distribution is available
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Here
This was a simple exercise in learning the technology that will be used in later projects.
Installing Tomcat
I found this rather easy. I simply downloaded it, unzipped it, read some of the documentation to make sure I had everything correct, and ran it. I was able to connect to http://localhost:8080 right away without any problems.
Installing Stripes
Another rather easy task, as it simply involved downloading files and placing them in correct directories. After placing the stripes-examples.war file in the webapps directory, I was able to connect to http://localhost:8080/stripes-examples without any problems.
Installing StackStripes
Now this task was a bit more tricky. I was able to get it downloaded and deployed on Tomcat rather quickly, but came across some problems with getting all of the build.xml files to work correctly. I would always get a fail on verify because emma would not run properly. However, after reading the discussion boards about emma, I simply ran junit first and ran tomcat from the stackstripes project directory. After doing this, everything worked fine.
Improving coverage
When I first looked at the TestActionBean.java file, I was rather confused. It seemed that it was quite complicated to run tests on the server side of the project. However, after reading some more documentation and playing around with some of the code, I managed to get a good grasp on it. It appeared that the two methods that were not tested were the pop method in StackActionBean and the iterator in StackModel. I added test for these two methods and a error check for popping an empty stack to achieve 100% coverage in all areas.
The Double It button
It was surprisingly easy to create the "Double It" button and functionality. I did, however, have one strange problem with concurrency. There are some concurrency issues when iterating over a stack and pushing new elements on it at the same time. To overcome this, my doubleIt method first copies the entire stack to a temporary location then pushes the new members onto the original stack. This prevents concurrency problems with the iterator.
I also added one additional test of this method to keep emma coverage at 100%.
Conclusions
Overall this was a pretty straightforward task that allowed me to learn some of the technology we will need in the future. I like the simplicity of Stripes and the ease of adding new components. I think I am now ready to do more complex work with this technology.
Monday, October 22, 2007
21.MyISERN-1.2
Distribution of system available Here
Project home page is Here
All tasks were completed.
Difficulties
There were numerous difficulties in this section of the project. At first glance, I thought it would be rather easy, yet it turned out to be quite challenging. The annoyances of many of the components made getting the final project working quite difficult.
At our first meeting, we began discussing the UI and possible cases we needed to consider that might happen. It turned out that there were so many strange cases that could occur that the UI and underlying error checking system had to be quite complex. There were so many cases to consider and messages to give the user that just the UI because quite monstrous.
Once we had a partially working system, I began playing around with some of the data and trying to run as many cases as I could. At this point I realized how unforgiving JAXB and XML can be. Several times in this process the JAXB marshalling methods corrupted the XML files. It turns out that the JAXB Marshaller will sometimes write a format that will cause the Unmarshaller to crash with an exception. Our error checking mechanisms within the system had to be very robust to ensure this type of problem never occurs.
The testing of this system was a real problem. Since so many components of the additions in 1.2 rely on user interaction from System.in, I was unable to write many JUNIT test cases. Much of my testing was done by simply using the system and trying to break it. Entering the data turned out to be an exercise in breaking the system as well. On several occasions the system created corrupt XML files after I had entered a rather large amount of data, revealing a new bug. The SVN revert option was quite handy.
Group Organization
As we had done for our earlier version, myself and my teammate Shaoxuan Zhang met at the library for a long hacking session. After this 3 hour meeting on Thursday, we had most of the system complete. After that, we simply stayed in contact with email and Skype. It turned out quite well, since most of the data entry and debugging was difficult to work on as a team.
Future thoughts
At this point, the program is already becoming very large and somewhat difficult to manage. I think the incremental development we have been doing with 1.0, 1.1, and 1.2 made the design process difficult. Now that we have a more clear idea of how the entire final system will be, we can design a much more efficient system. There are many components in our current system that may not be used in the future. The slimming down of the system will make it much less buggy and more easily manageable in the future.
Lessons Learned
JAXB can be a pain, especially since the Marshaller and Unmarshaller do not behave the same when errors are present. I also learned the importance of early and complete design to keep the final system manageable. Finally, I gained some more experience with eclipse and the debugging features it provides.
Project home page is Here
All tasks were completed.
Difficulties
There were numerous difficulties in this section of the project. At first glance, I thought it would be rather easy, yet it turned out to be quite challenging. The annoyances of many of the components made getting the final project working quite difficult.
At our first meeting, we began discussing the UI and possible cases we needed to consider that might happen. It turned out that there were so many strange cases that could occur that the UI and underlying error checking system had to be quite complex. There were so many cases to consider and messages to give the user that just the UI because quite monstrous.
Once we had a partially working system, I began playing around with some of the data and trying to run as many cases as I could. At this point I realized how unforgiving JAXB and XML can be. Several times in this process the JAXB marshalling methods corrupted the XML files. It turns out that the JAXB Marshaller will sometimes write a format that will cause the Unmarshaller to crash with an exception. Our error checking mechanisms within the system had to be very robust to ensure this type of problem never occurs.
The testing of this system was a real problem. Since so many components of the additions in 1.2 rely on user interaction from System.in, I was unable to write many JUNIT test cases. Much of my testing was done by simply using the system and trying to break it. Entering the data turned out to be an exercise in breaking the system as well. On several occasions the system created corrupt XML files after I had entered a rather large amount of data, revealing a new bug. The SVN revert option was quite handy.
Group Organization
As we had done for our earlier version, myself and my teammate Shaoxuan Zhang met at the library for a long hacking session. After this 3 hour meeting on Thursday, we had most of the system complete. After that, we simply stayed in contact with email and Skype. It turned out quite well, since most of the data entry and debugging was difficult to work on as a team.
Future thoughts
At this point, the program is already becoming very large and somewhat difficult to manage. I think the incremental development we have been doing with 1.0, 1.1, and 1.2 made the design process difficult. Now that we have a more clear idea of how the entire final system will be, we can design a much more efficient system. There are many components in our current system that may not be used in the future. The slimming down of the system will make it much less buggy and more easily manageable in the future.
Lessons Learned
JAXB can be a pain, especially since the Marshaller and Unmarshaller do not behave the same when errors are present. I also learned the importance of early and complete design to keep the final system manageable. Finally, I gained some more experience with eclipse and the debugging features it provides.
19.UseCaseSpecification
Our use case wiki pages are available Here.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
At first we were a little bit confused as to the particular format wanted. Most of the information available on the web about use cases involves stick figures and bubbles. Very few even mention UI mock-ups. Most pages show are very rigid templates, for example Here.
After realizing what we needed to do, we first created the use case for a simple log in. After that, we decided to come up with the "home page" that contains all of the features of the system. From there, we simply made a use case for each link from the home page (each has one specific function).
When I first pulled up Gimp and started working hard trying to make the pages look nice, I realized the aesthetics are unimportant. The objective is to outline the functionality, not the look of the final UI. In the end I threw away my complex diagrams and made very simple, functional diagrams.
Wednesday, October 17, 2007
22.MyISERN-1.1.Review
Author: Chiao-Fen Zielinski-Liu
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Installation
I was easily able to download and use the system. The UserGuide provided is quite straightforward and it was a simple task to get the system running. I was able to immediately run all of the queries through the commands of the form
java -jar myisern.jar
Loading the project into eclipse, however, was not quite as easy. Once imported, I got many errors from the build path. Since this always happens, I knew what environment variables to load to get the system working. The DevelopersGuide, however, does not clearly outline the required variables to import the system into eclipse. Overall it was rather easy to get all aspects of the system installed and running properly.
Code Format and Conventions
When I first looked at the source code for this project, I was rather surprised and pleased by the small number of classes and only one package. Some versions of this system can quickly become monstrously large. Most of the code fit the conventions rather well, however I did see some areas with some minor documentation and naming issues:
| File | Lines | Violation | Comments |
| TestMyIsernXmlLoader.java | 18 | N/A | Author and comment unedited since example |
| PrinterData.java | 120,140,160,... | EJS-33 | Whitespace or moving comments may make reading easier |
| MyIsernPrinter.java | 16 | EJS-7 | White space needed between methods |
Test Cases
The test cases are, overall, rather extensive. The basic functionality of almost every unit is separately tested well, though I was confused to find all the tests in the same file (except for one that was in MyIsernXml.java). The majority of the testing seemed to be of the parser "MyIsernPrinter" class.
Black Box
Many of the units were tested for their specific I/O. For example, various input strings were tested on the MyIsernPrinter class and the return code was tested. However, specific end-to-end I/O black box tests were somewhat lacking. From a black box perspective, a test of the I/O relationship over the entire system can be useful.
White Box
Quite a lot of white box testing was done in this system. Emma shows the coverage to be over 90%. All the modules were tested for many different values. The details of the TablePrinter and MyIsernPrinter classes were especially well tested. However, from a white box perspective, exception testing was missing.
Testing for exceptions can be very important when analyzing the structure of the system. Rather than having the tests just throw the exception away, it can be helpful to test when an exception should be thrown and when they should not be.
Break Da Buggah
This system was quite difficult to break. I behaved quite well with nearly any input. Most of the problems I was able to find were simply unclear error messages and unexpected features.
For example, when running the system with no arguments a rather nice (though unexpected) thing occurs. Windows appear containing the contents of each table. While this functionality is nice, the documentation is rather unspecific about it and the requirements do not mention it. Some of the error messages are also quite unspecific and general.
After lots of trying, I did manage to get the system to behave unexpectedly. When running the following query:
-listOrganizations -collaborationLevelEquals 99999999999999999999
The following is output:
Print job was not successful
A check for values over the maximum integer size could fix this problem.
Summary and Lessons Learned
Overall this system is quite simple and concise. It handles many unexpected values rather well, delivers the data correctly, and even has some nice additional features. However, there are some places where the structure could be improved. Some of the functionality is rather rigidly implemented that may make future enhancement of the system difficult. For example, the class used to parse the command line may be very difficult to later expand. It uses a rather complex "code" type of system with many if statements that may be problematic in future development.
From this system I learned about the JFrame utility, which seems like a really nice tool for displaying various objects to the user. I think it may come in handy in future projects. I also saw some places where my own system could be improved, for example the handling of very unexpected input values.
Subscribe to:
Posts (Atom)