Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
M5: Application Design
M5 Requirements
Create your Software Architecture and Trust Boundaries
Identify your Application and Utility Objects (those new objects specifically developed for the design. You do not have to say which are which, just id the ones that were added from the domain analysis) This should be easy, as all classes that were not identified with a CRC card will be in this category. You can annotate them on the class diagram, or you can list them separately. These are all the classes that don't fit into the domain, like data structures, network and thread classes, database access classes, UI classes, data validation classes, and any other classes necessary for this to run on a computer, but are not really part of the domain itself (and thus don't have CRC cards).
Add necessary CRC Cards and any new scenarios needed (for newly discovered domain classes if any). If you have no new classes, and nothing to fix from your TA meeting, then you may not have anything for this point. In that case you will receive the points for "free" as a reward for doing a good job the first time.
Submit a UML Class diagram of your refined design (shows all domain and application/utility objects)
Submit 2 UML Sequence diagrams that shows your full design handling one or more scenarios. You should make your scenarios interesting so these diagrams help you.
Submit screen mockups that show your preliminary user interface. These screens can either be hand-drawn, or prototyped with the VW Painter and then captured.
Submit a written contract (1 per person on the team) for an object or method in the design. Remember that the contract is basically the pre and post conditions of the method, or guarantees of the object as a whole.
Submit a short paragraph on your error handling and exception handling design strategy.
Strategy
After receiving a low grade for M3 as a team, we wanted to step it up and get back on track. The first thing we needed to do was sit down and completely redo all of our original material. This was a huge pain because we couldn't make back points, it was such a small part for this hw, and it was very time consuming. We all had a general consensus that we should have done it right the first time
For the CRC cards, we etched out our main classes and this time formatted everything correctly. Our scenarios were a little better but we still lost points not showing enough detail.
On to the new stuff
Probably the most time consuming task is making the UML diagram. There are two options: do it by hand or do it with software. We chose software because it looks clean and is easy to change. Now time wise I believe that by hand is faster but you have to take into account what having only one copy means and that task of changing something.
The trust boundaries and archeticture were an easy task. We did a layered archeticture which has several layers like domain classes and interface classes. Each layer shows the trust boundaries. Common classes can trust each other while if you have to move into another layer you should check your information.
The contracts are a simple task because we have all taken java. Write what a method needs, what it does, what it return, and if there are any errors to watch for.
The last part with the screen mock ups is the fun part. You get to begin to visualize what your code will end up looking like which is neat. Remember that super fancy is not the way to go at first though. You need to get the basics working first and then implement the fancy things you have invisioned.
Reflections
This was the last planning hw before we got our hands dirty with some code. As we worked through our project it was nice to have something to look back on and see what we had planned and to see what needed to be done. It is also good to know that your plans will change. I don't think one team stuck true to their original plan WHICH IS A GOOD THING. It shows you are thinking, learning, and adapting. On to the code you go...
Link to this Page