I've described the mark scheme in terms of perspectives like those that appear in the Rational document. Students are not required to follow the template. Nevertheless, they must somehow present the perspectives typically referred to as logical, implementation and deployment. The process view is not very interesting in this case, so it's okay if it's omitted.
In general the assignment does not give enough detailed requirements to specify the throughput or latency requirements of the system. If a student makes specific assumptions and then follows up with more specific specifications (eg. in the deployment or process view) that is above and beyond the call of duty.
The logical view should give the reader some insight into how the software is organized. Traditionally this has often been done with a diagram such as the one appearing on slide 20 of the client-server lecture slides. For this assignment we need to focus more deeply on the box simply marked "app" on the slide. The goal is to show the structure and organization of the proposed software and where it fits into the overall system.
During office hours several people have questioned me about how processes and threads work in apache with a view, I presume, to creating a detailed process view. I suggested that if they want to do this they should make some system load assumptions and the provide a back-of-the envelope throughput calculation to estimate the characteristics of their httpd. I stress this is not required but appears to be a question that interests some students.
A detailed database model (say in the form of ER diagrams) is NOT required. In general the architecture document for a system that has not been designed yet cannot possibly include the detailed database design. On the other hand some vision for how data persistence is going to be handled should be given. Many systems built using proprietary middleware, especially database oriented client-server middleware, simply use what their vendor provides. In the last ten years or so many new (often web based) systems have been built on top of legacy databases. In these cases database models may appear in a first architecture document.
| Marks | Comment |
|---|---|
|
Bookstore. Context and coverage.
Does the document include sufficient context and cover enough perspective to communicate to a group of one's peers? |
5 |
|
Bookstore. Logical Perspective.
Is the proposed software divided up into logical components in any useful way? This likely is in the form of some kind of layering or package structure. A few students have created interesting diagrams that combine layers and packages for the web variation. |
5 |
|
Bookstore. Implementation
The implementation perspective should somehow be covered. For instance, if the student has chosen a web systems obvious choices like the httpd should be identified. |
3 |
|
Bookstore. Deployment
A deployment diagram or some way of describing what parts of the system runs on what box should be included. Gear should be arbitrarily chosen unless specific assumptions are given. On the other hand, machines can be identified very generically (eg. PC running linux) |
2 |
|
Farm. Context and Coverage.
You should have a sense of how the system suggested by the student is going to work. Essentially any technology choice that is reasonable is acceptable. For instance it's okay if they insist on the data being stored in a relational database or even managed by a J2EE container if they want. Many students seemed to want to take some particular infrastructure out for a test-drive. That's fine with me. If you are uncomfortable marking because the technology choice is unfamiliar, pass it to me. |
5 |
| 20 | Total |
Suggested quality to marks:
| 5 | Excellent | superior grasp of the subject matter | no problems |
| 4 | few and minor problems | ||
| 3 | okay | a few more problems, none major | |
| 2 | marginal | some slight evidence that they understand. | |
| 0-1 | inadequate | little to no evidence of even a superficial understanding of what is required | |