M5 -- Application Design

• 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.

• What Worked

1. Identifying utility object has to be about the easiest part of this project, it really is just what the description say, anything that you didn't make a CRC card for because it wasn't a domain class.
2. Our design was good from the beginning, we were told, so we didn't need to make any changes to our CRC cards or to our scenarios. That was a great things to hear, and free points are always nice.
3. UML Class Diagrams are not hard to draw, but they are time consuming. For this part we each took a subset of our classes, and worked out how each individual class would look on paper, then as a team we decided how they would be linked, and had one person get on a drawing program and put them together.
4. Written contracts are also pretty easy to do. Precondition/postcondition stuff is taught to all of us from day 1 and it's just a formal way of writing it out. There isn't much to worry about here, just make sure everyone does their part.

• What Didn't

1. UML Sequence Diagrams are trickier than they look. Get a good grasp on them before you start or you'll be going through a lot of paper. Make you you space things out properly and remember all of the intricacies. There are only a few part to remember, but if you miss one, it'll cost you.
2. Error handling and exception handling strategies aren't difficult to come up with, but our team second-guessed everything we put down on that paper. If you aren't sure just ask Bob or the TA.

• What We Would've Done Differently

1. We would've definitely asked more questions, especially about the Error/Exception handling
2. We didn't delegate the work very well for the project so it turned into a large group where everyone worked on everything at once. This wasn't necessarily bad, but it toko us a lot longer than it could have. In the end, we all knew the material better for doing so, but we probably would've tried to split it up in some kind of reasonable fashion.

• Navigate to the link below to see a list of image links.
• Click individual ones for examples

Link to this Page

• Team TFC & The CMs last edited on 29 April 2009 at 9:53 pm by 128.61.87.51