Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Will Work For Food Cases
Edit Will Work For Food Cases here.
• Form a 3-4 Person Team
This is one of the critical parts of the project. If you are willing to learn Smalltalk and visual works, do not form a group with people you cannot depend on. Avoid forming a group with buddies, too. If your friend gives up in the middle of the project or become lazy, it will be hard for you to change him or see the professor about it. Define your ways of communication and try to pick a leader for the group and another person for communication issues.
• Identify Domain classes
Here is what we did: list everything that comes across our mind. As the project goes along you will come up with different ideas, but define as many as you can at the beginning. This is another chance to analyze your teammate. Make sure you have some agreement now to avoid a lot of changes down on the road.
• Create CRC Cards and Scenarios for the Candidate classes
We came up with a list of scenarios and each team member had to make crc cards based on the scenarios created. Then, we compare the crc cards. First thing was to select the common ones and second presents the arguments for a particular card. Make sure the scenario is a sentence (complete thought), not just a word or couple of words.
• Assign Role Stereotypes and Responsibilities to classes
Once the scenarios and Crc Cards are done, each team member had to assign role stereotypes and responsibilities. Make sure to defend you choices, which will be based on your understanding of the project. This is only temporary because as the project goes, you still can make changes.
• Role-play scenarios to clarify responsibilities and collaborations
This part was the most confusion of the project. Make sure to ask the TA questions about it for better understanding. The Role-playing will depend on the definition of responsibilities and the way you set the collaboration.
• Meet with your assigned TA (after submission grading) to discuss your design and possible improvements
It is very important to know your grading TA and get a feedback on your progress. Write down any question that you have before you meet with the TA
So, this is the second phase of the project. You will be creating Software Architecture and Trust Boundaries. This shouldn't be too bad if you know how your classes are grouped and interacting with each other. This part will be very similar to one of your homework assignments.
Identify Application and Utility Objects.
As you go on working on the following milestones, you will be most likely making changes to your original design unless you are the master of designing programs. As you begin coding and testing, you will be stubbing out some classes or methods or adding some more classes. In the worst case, you might consider changing major parts of your design as you find that some requirements are hard to be implemented. To avoid this as much as possible, create more scenarios and CRC Cards and role play them.
After adding CRC Cards, modify your UML diagram. This is not much painful. But, drawing sequence diagrams may take much more thinking and time. To draw a sequence diagram, you need a thorough understanding of how classes are interacting with each other as well as their methods. Make use of sequence diagrams. It's going to be really helpful when you actually start coding.
Then, you will be creating screen mockups. Don't underestimate this part. User Interface in 2340 is a very important topic. Milestone 5 is going to focus on UI evaluation. Other group will be the user of your application and evaluate your design. So, think about what would make the application easier for user to understand and use. Remember that you are not the user of the program. Grab a random person in the CoC commons, he should be comfortable using your program. So, take user's perspective and design things simpler. One drawback is that you are probably not familiar with GUI capabilities of smalltalk and Visualworks. Just keep this in mind that you will need to change your User Interfaces later on.
This milestone is one of the toughest to over come. You are suppose to implement the backhand code for the Project. All the domain classes. Before you start coding it is best to learn how to use small talk and how objects work. The domain classes are the classes that are used by the program itself. Within the ecode project, it is used for storing most of the information such as name, method, attribute, and different information of the CRC card.
RolePlaying is the part that we got stumped over. The visual representation of roleplay is an essential part of the project and we continuously had to refine the design to accomodate the changes that the TA wants us to have. A good way of approaching roleplay is to make sure the Roleplaying design is what they expect from the TA's. One suggestion is to add steps to each responsibility added so while roleplaying it can go through the responsibilities knowing which responsibility is next.
During this stage, we had trouble coding with small talk; therefore, it took us a really long time to finish the domain classes. That shorten the time that we got to spent on the User Interface. Even though we had a rough time we realize that as long as you have a good design of the project and have a good idea of how to code with small talk. This stage will be easy to be implemented.
With the User Interface at this stage does not needed to be completely done; therefore, it is a good idea to test them using the SUnit tests. They can provide a similator that test whether the code is valid, and if not then it would not work when implementing the View part. SUnit should be done while you are coding to test for its validity.
While coding it is always good to keep in mind to comment. You might think commenting is a waste of time, but it can actually be a time saver. Often we come across each other's code not knowing what it is doing and the reason why they implement it in such a way; commenting resolve some of the issues of these problem
Another thing to watch out is to try not to write all the user interface stuff in one class. Try and spread them out to seperate classes, but making sure it does not get interwined with the domain class. They should be created seperately
• The domain and SUnit was working perfectly
What didn’t work:
• Some problems occured during creating scenario and minor details within the UI design
What would’ve been different:
• If we had been more familiar with the small talk language it would have helped tremendously
This milestone will be the final touches of the User Interfaces. The hardest part of this milestone is to incorporate the extra credit stuff while coding for the basic functionality. The best way of approaching this is by keeping in mind the implementation of the extra credit and just code the basic structure of the extra credit part. And worry about the basic functionality later.
The Crc Card layout display, a good way of representing it would be drawing them into an actual size of a CRc card so it would be as realistic as possible. Remember to refresh the drawing board when implementing the changes within the display area.
Roleplaying at this phase should be almost finished thanks to the previous planning during the M3. And during the roleplaying try to make the cards as small as possible so it'll be easier to represent small cards showing the relationship with one another as suppose to a big card that takes 1/4 of the screen and making the screen barely able to fit 4 cards.
While creating the UML diagram. A way of creating it would be to draw rectangles and just fill in the name at the top left corner of the box. That is the easy part of it. The hard part is creating lines, it is something to think about. We performed a search for the shortest distant between two classes and connect with a line at the shortest distance of the two classes. Also when drawing the different arrows make sure it consider how far the line would really connect with the arrow present.
For the SUnit part, again it is a good way of practice and performing tests to validify the code that are implemented.
• UML diagram
Representing the CRC card graphically
Saving and Loading
What didn’t work:
• The role playing was poorly designed and was criticized by the TA
We found issues with some part of the design of the UI
What would’ve been different:
• If we met with the TA more often. A better design during the earlier phases might have made the coding smoother.
This milestone is about evaluating other team’s prototype, and reaction (rebuttals) towards your team’s evaluation from other team.
There are three evaluating methods—heuristic evaluation, cognitive walkthrough, and think aloud. You need to choose one that you think it is appropriate for evaluating.
We chose heuristic evaluation for it has specified evaluating fields: Ten Usability Heuristics. You can get those heuristics from here. http://www.useit.com/papers/heuristic/heuristic_list.html
When you plan the evaluation with the heuristic method, your testing tasks should involve possibly everything that you can do with the prototype. Our tasks included UML creation and Roleplaying. Those are pretty much the last steps of Ecode including from making candidate classes to scenarios and CRC cards.
After setting up proper test tasks, when you test the prototype, if you find bugs and/or UI awkwardness, be sure to record them as you go as detail as possible if you don’t want to run your tasks several times. With heuristics, you can later categorize what field(s) those bugs affect. And when you write your report, try to be respectful and keeping the other team’s dignity even if you are tired from lots of bugs. :)
Now, it’s time to face other team’s evaluation of your team’s prototype. In rebuttals, what you do is basically making excuses or rejections towards their findings. Again, be sure to be respectful.
During evaluation, try to meet the team that evaluates yours, and show them how to run your code properly, not how to use the prototype (obviously). Between computers, the same thing works in one and doesn’t in another. In our case, font sizes in Visual Works were not properly recognized between different language versions of Windows.
• Using heuristics to evaluate prototype specifically
What didn’t work:
• Showing other team’s how to use our code or set their computers
• Writing report more logically or reasonably
What would’ve been different:
• Meeting the other team would resolve many conflictions between machines
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu