COMP 6471 Software Design Methodologies

1
COMP 6471Software Design Methodologies

• Winter 2006
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/comp647-w20
  06.html

2
Top-Level Use Case Diagram
3
Worker Scenarios
4
Worker Scenarios

• 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
Admin Scenarios

• 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?cmdcpmtr1p1pmtr2p2

10
Proof-of-Concept

• Eg
• CUWME?cmdcpmtr1p1pmtr2p2
• 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?