Steps in Performing the Assignment

1. Steps in Performing the Assignment • Where do we start ?--- from the infrastructure or from the application --- or both for awhile and then decide. • Web-based application --- so may be a 2-tier system with browser rendering UI on the user side PC and a server hardware with some kind of DB. (The software may still be 3-tiered.) • Postpone the choice of language, tools, subsystems, and platforms such as Tomcat for later. • Switch over and look at the application functionalities and components: • Input the student data • Batch (e.g. import) ---- something not clearly specified in requirements • Interactive • Set up authorization “groups” to perform different tasks • Sort the student data by different fields • Query (and Print?) the student data • What should we do next? • Consider performance a bit: as the # of records grow, we “probably” need to use a real DB and a sort routine such as Quicksort instead of writing one’s own algorithm ---- potentially buy or re-use some routine. • Think about student record accesses: to handle real-time update/view conflict, we need some kind of locking mechanism. Let’s use a real DB to help access conflict resolution.

2. 3. Let’s look at the main components from requirements statements: Steps (continued) Input student data Set-up Authorization Student data sort Query/Report Student data 4. How are these RELATED? - Set-up authorization must be performed first by a “special” administrator who can log on with a specially set up id/password so that others users’ id/password can be set up for logging into the system for different functionalities - We can consider sort as an option (sub-component) under Query Report (make a decision to do just that) - Input student data may be further decomposed into batch or interactively put into the system by the student himself/herself. (there is potential problem --- student data can only be modified by students --- creation & deletion is allowed by “special” administrator only.)--- rethink about breaking this up - We need to add a “Log-in” Component to allow differentiation of users and allowable functionalities

3. Steps (cont.) 5. Re-Defined the main components ---- started the Application Architecture (note that the components set-up authorization & create/delete student records require different authorization ---- originated by “non-functional” requirement ) Set-up Authorization batch import Student Recds Create/Delete Student Recds Create/Delete individual Recd User Login Student data sort Student data manipulation Query/Report Student data Note student number is not included; decide later Modify own Name/Address

4. Steps (cont.) 6. Look at the application components and starting thinking about the UI, logic, and data again: • Which components will have UI that will be rendered by browser. • Which components will have interactions with DB 7. Consider “common” UI look and navigation 8. Consider a possibility of a “common” DB access component (keeping performance in mind) . . . Note that : I approached the performing of these steps using Wolfe & Perry’s {elements, form, rationale} “definition” of architecture