1. COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-w2006.html

2. Top-Level Use Case Diagram

3. Worker Scenarios

4. Each session has begin..end indicated Each session identifies The user (presumably by loginID and password) The project (if project management used) The role of the user (in the project) Each session requests a series of activities (commands) be carried out These are work commands for publishing documents Somehow permissions are checked, only valid commands are executed Activity is logged Versions are tracked

5. Worker Scenarios work commands are for publishing documents Download necessary files/documents Organize/edit/review/comment/etc Publish (ie create a new release version) Also Merge (independent) versions Create branch in version tree …

6. Admin Scenarios

7. Note that these are similar to work scenarios But, need special roles (and project) to permit administrator access Activities (commands) relevant to admin are Set up user, role, permission (object, operation, condition) Set up project Work (admin?) for project manager in addition Assign users to roles for a project Define the project activities Define the project schedule …

8. Top-Level Architecture for Web

9. Proof-of-Concept Note the …string… which identifies activity Can make session_begin and session_end compatible with other activity requests Pick a syntax like http cgi convention CUWME to identify the system Command requested List of parameters Eg CUWME?cmd=c&pmtr1=p1&pmtr2=p2

10. Proof-of-Concept Eg CUWME?cmd=c&pmtr1=p1&pmtr2=p2 The string is the request Note that CommandFactory parses this string And collaboratively creates a Command object Invokation (and hence logging) is done in ActivityManager You need to also decide how permission is checked.

11. Proof-of-Concept Note that “information” can be created by hand using editors to produce text files (csv format?) or xml files User info Project info Document store, including files, versions, … … with code to read these in and create internal collections (or dictionaries or databases) Log need be the only “output” that is persistent for the proof-of-concept itself

12. Proof-of-Concept You can create a simple test infrastructure: Input: a text file with one command per line for one or more user sessions (sequential) Expected output: a log of (permissible) commands being executed How would you set up a test infrastructure for multiple concurrent user sessions?