COMP 6471 Software Design Methodologies

Winter 2006 Semester

Project

The design case study is the Concordia University Work Management Environment (CU WME). The CU WME provides support for an organisation of people who produce and publish documents.

There are several components which comprise the CU WME, namely:

  1. CU User Management system: users have specific roles in an organisation or project which grants them specific access rights to resources (including computers, files, activities, ...).
  2. CU File Management system: files are tracked in terms of their location, location of copies and versions, including copies on back-up or in archives; the source of uploaded files is tracked, as is the destination of published files (documents); files can be organised into hierarchical directories; files are owned, and have access control.
  3. CU Change Management system: versions of files (documents) are managed so that independent sets of changes can occur simultaneously, changes can be merged, and any version of a file can be re-created upon request.
  4. CU Activity Management system: sessions of use of the WME is monitored, controlled in collaboration with User Management system.
  5. CU Collaborative Publication system: coordinates and manages the production and publication of documents across a group of users working collaboratively. Support for comments, changes, reviews, revision, acceptance, and publication of documents is provided.
  6. CU Project Management system: projects may be defined as a sequence of activities to be carried out with a given set of resources (users)for the delivery of a document. This system tracks the completion of activities against a pre-defined schedule.
  7. CU Workflow Management system: users can define a workflow process, initiate the execution of an instance of a workflow process, and coordinate the execution of the activities which comprise the workflow process.
  8. CU Resource Management system: inventories physical resources, tracks their use.
  9. CU Time Management and Billing system: tracks how users spend their time, and determines who should pay for their time spent.
  10. etc
At this stage we are interested in the first five or six components of CU WME (as we work in teams of five or six software designers).

The basic work pattern of CU publication team is as follows.
They upload files with images, text, etc that they will use in documents into the WME. These files may be moved, copied, deleted, changed, backed-up, archived duirng the course of the work.
Documents are produced using the information in files, as well as new information entered into documents. They go through an iterative lifecycle of review and revision before they are accepted and published. Several versions of a document may be published over the course of years. Documents may be treated as a collection of document parts, each part having its own lifecycle. Document production is a collaborative activity. Of course, documents are files too.

Good management of the publication process needs to track the location of files and documents, make sure they are backed up, and to log who does what with each document.

The group may wish to organise the publication of a document as a project. It may wish to define a specific workflow for the process of production and publishing the document. And if this needs to be charged to an internal or external account then the use of physical resources and personnel resources needs to be tracked.

Our aim is to produce a clean conceptual design and working proof-of-concept.

Note: Feature bloat will not be tolerated. This is an exercise in producing a clean design where it is obvious how additional features can be added to the design. However, there are many key issues that you need to identify as important for the CU WME and hence handle them in the design. These relate to collaborative concurrent work as well as resource access control in a distributed setting. These also relate to ensuring the different components work well together (using the abstractions consistently).

Note: We will not concern ourselves with design of user interfaces nor with the design of the database schema for persistency. We will design APIs to hide these concerns.

Note: In each assignment, a team member will be reponsible for one specific component: a different component for each assignment. The work for individual components must be consistent with each other, so the CU WME as a whole is consistent. Hence, you must understand the work done by every member of your team.

Assignments

2006-01-23 Week 3: Assignment 1 due at 18:00 on 2006-01-25.
Assignment 1 delivers a two-page problem statement for the requirements of each component.

Marking Schema for Assignment 1 (out of 10)
For each component deliver a two-page well organized document containing the following:

  1. Clear description of the problem that the component addresses. (3 points)
  2. Causes of the problem. This part answers why we need such a component in the system. (2 points)
  3. Scope of the component in the system, and the users that benefit from the component. (2 point)
  4. Brief description of main entities for the component. Describe at least 3 entities but no more than 6 entities. (3 points)

Look at Role-Based Access Control, Open Source Java Software, and other open source projects for inspiration.

Marks 

StudentID    Mark/10   Team   Component
3955141       10.0        1        1
4439449       10.0        3        1
4440358        5.5        3        5
4561139        8.3        7        1
4562577       10.0        6        3
4798821        8.3        5        3
4812298        9.8        3        6
5132290        7.0        3        4
5297478        8.15       3        3
5315239        8.5        2        5
5315298        7.0        5        4
5317665        9.5        1        3
5357896        5.0        2        3
5374049          -        -        -
5404967       10.0        6        5
5511186       10.0        7        3
5544351        9.5        6        4
5548934       10.0        2        1
5599644        8.5        5        1
5611458        8.5        4        1
5632242        9.0        6        2
5653622       10.0        5        2
5696569        8.5        7        2
5758246        9.0        2        2
5761549        9.5        7        6
5763134        9.0        7        5
5763320        9.0        1        2
5775221        9.0        6        1
5787084        9.0        3        2
5788250        5.0        6        6
5789877        8.5        7        4
5798558        5.0        1        4
5812984       10.0        4        3
5847745        7.0        4        4
5946565        9.8        2        4

Sample solutions

Here are some of the best solutions. I have provided commentary.

  1. Component 1: User Management
    Good, simple. However, this component really does not need to mention the overall system goal of document management. It could be used as a component in many systems, not just CU WME.
    Still it helps to have a concrete focus like the CU WME.
    Specific roles are mentioned: really the roles can be entered at load time, or run time.
    Note that RBAC controls access by assigning the right to perform a specific "operation" (command or activity in our case) on a specific "object" (file, document, resource in our case) under specific "conditions". Our component does not need to be that complicated.

  2. Component 2: File Management
    Good. Tries to separate responsibility of this component from others.
    Again, this component is separate from the CU WME system. Does need access control, so how do file access roles (like user, group, other in Unix) synchronize with Component 1?
    Some questions for longer term: does a file system track changes? What is the relationship between back-up component and file system? What are the essential differences between files and documents?

  3. Component 3: Change Management
    Bit confused on responsibility for this component and document managament (C5), group awareness (C4?), access control (C1 and C4) and role management (C1 and C6).
    What do you want to manage changes of? file, document, resource, ...

  4. Component 4: Activity Management
    Seems to confuse "access" with "activity". And buys into the full scope of security management, encryption. What exactly is "activity management"? How do User Management (C1), file system (C2) permissions, and this component collaborate to achieve security of access to data?

  5. Component 5: Collaborative Publication
    or more simply "document management".
    This is a major component, but not the whole system. This description includes user management (C1), logging (C4 and C5) as well as requiring specific roles.
    Needs to be simpler and more focused on document management. Leave policy and control to other components.
    Important to distiguish between documents and files. What does this component need from the file system?

  6. Component 6: Project Management
    It is important to keep this simple.
    A project defines the "policy" for how to produce/publish documents; C5 provides the mechanisms (operations) for the activities of the project, but does not require policy in C5.

2006-02-06 Week 5: Assignment 2 due at 18:00 on 2006-02-08.
Assignment 2 documents the domain model (of each component and the system as a whole).

Marking Schema for Assignment 2 (out of 10)
For each component deliver a five-page well organized document containing the following:

  1. A class diagram for the domain of the component: show main classes; associations with names, direction, and roles. Show class attributes only when necessary. (One page or less) (3 points)
  2. Description of three main classes. (About 10 lines each.) (1.5 points)
  3. Description of three main associations. (About 10 lines each.) (1.5 points)
  4. Brief descriptions of other classes and associations (about 2-3 lines each). (2 points)
  5. Include a section called "Component Consistency" where you discuss how you ensure consistency between your component and the other components within your team. (About half a page.) (2 points)

Marks 

StudentID    Mark/10    Component
3955141        8          3
4439449        7.5        3
4440358        8          1
4561139        7.25       6
4562577       10          4
4798821        7.25       4
4812298       10          2
5132290        7          6
5297478        5.5        5
5315239        8.75       1
5315298        6.5        1
5317665        8.75       6
5357896        7.5        2
5374049
5404967        7.75       6
5511186        8.75       2
5544351        8.75       5
5548934        6.75       4
5599644        8.5        2
5611458        9.5        4
5632242        8.25       3
5653622       10          3
5696569        8.5        2
5758246        9.25       3
5761549        9          5
5763134        8.25       4
5763320        9.25       5
5775221        8.75       2
5787084        8.25       4
5788250        7.75       1
5789877        8          3
5798558        6.5        1
5812984        9.5        2
5847745        8          5?
5946565        8.75       6

Sample solutions

Here are some of the best solutions. I will provide commentary.
Overall System

  1. Component 1: User Management

  2. Component 2: File Management
    Component 2: File Management

  3. Component 3: Change Management

  4. Component 4: Activity Management

  5. Component 5: Collaborative Publication

  6. Component 6: Project Management

2006-02-27 Week 7: Assignment 3 due at 18:00 on 2006-02-29.
Assignment 3 documents the use cases of each component and the system.

Marking Schema for Assignment 3 (out of 10)
For each component deliver a five-page well organized document containing the following:

  1. A summary diagram for the use cases and actors of the component. (One page or less) (2 points)
  2. Description of each actor. (About 3-5 lines each.) (2 points)
  3. Brief description of (up to) four use cases. (About 5 lines each.) (2 points)
  4. Fully dressed description of the main use case (about 2 pages). (2 points)
  5. Include a section called "Component Consistency" where you (a) present the summary use case diagram of the CU WME system, and (b) discuss how your use cases are consistent with those of the system. (About 0.5-1.0 pages) (2 points)

Marks 

StudentID    Mark/10    Component
3955141         8.25      2
4439449         9.0       4
4440358         9.5       2
4561139         7.75      5
4562577         8.75      5
4798821         
4812298         9.25      3
5132290         6.0       1
5297478         9.25      6
5315239         9.5       3
5315298         8.5       2
5317665         6.0       1
5357896         9.0       4
5374049         
5404967         
5511186         9.75      1
5544351         8.5       6
5548934         9.0       2
5599644         6.75      3
5611458         6.0       6
5632242         8.75      4
5653622         7.5       4
5696569         8.5       6
5758246         8.0       6
5761549         8.25      4
5763134         7.5       3
5763320         8.0       4
5775221         8.5       3
5787084         8.75      5
5788250         8.0       2
5789877         7.0       2
5798558         
5812984         7.25      5
5847745         7.5       1
5946565         9.0       5

Sample solutions

Here are some of the best solutions. I will provide commentary.

  1. Component 1: User Management

  2. Component 2: File Management

  3. Component 3: Change Management

  4. Component 4: Activity Management

  5. Component 5: Collaborative Publication

  6. Component 6: Project Management

2006-03-13 Week 9: Assignment 4 due at 18:00 on 2006-03-15.
Assignment 4 produces a design of the basic system and Java code for a proof-of-concept.

Figure 13.1 shows you the information that the design model contains: a logical architecture showing the layers of the system; interaction diagrams which are the use case realizations; and the class diagram of the design.

As a team you should decide on a logical architecture (ie layers) for the system as a whole. In the package diagram, show where each component is located within the layers.

Each component should have a facade class which provides the interface for the services offered by the component. Clearly document this interface.

Develop a use case realization for two or three main use cases which carry out work activities related to the main goal of the system which is the publication of documents. Do not spend time on CRUD use case. Assume that you have facilities which can carry out CRUD and store the information in appropriate files (which are accessible to components).

Note that all commands should be invoked within the Activity Manager.

Do develop a class diagram for the design of your component.

Do create code skeleton and code stubs for your proof-of-concept. The code only needs to handle the two or three use case realizations described in your design model.

Marking Schema for Assignment 4 (out of 10)
Each person should submit a zip file containing a pdf file of the design model, and a source directory containing your java proof-of-concept.
The design model will be a five-page document containing:

  1. An package diagram presenting the logical architecture of the whole system, with components clearly indicated. (One page or less) (2 points)
  2. Sequence diagram for two or three use case realizations for non-CRUD use cases of your component. (About 0.5 page each.) (2 points) [13-03-2006: 3 points]
  3. Class diagram for the design of your component with brief text descriptions. (About two pages) (2 points)
  4. Clear description of the interface of your component provided by the facade class. (About one page.) (2 points) [13-03-2006: 3 points]
The source code will be worth 2 points [13-03-2006: 0 points]. It will be worth more in latter assignments.

Marks 

StudentID    Mark/10    Component
3955141        7           6
4439449       10           5
4440358        8           3
4561139        9.5         4
4562577        8           2
4798821
4812298       10           4
5132290        5.75        2
5297478        8.75        1
5315239        9           2
5315298        6           3
5317665        9.75        4
5357896        8.75        1
5374049
5404967
5511186        9.5         6
5544351        8           3
5548934        9           5
5599644        8.75        2
5611458        7           5
5632242        9.5         1
5653622        8.25        1
5696569        8.5         5
5758246       10           4
5761549        8.5         3
5763134        9           2
5763320
5775221        8.25        4
5787084        9.5         6
5788250        6.25        5
5789877        9.75        1
5798558        8           2
5812984        9.25        1
5847745
5946565       10           3

Sample solutions

Here are some of the best solutions. I will provide commentary.

  1. Component 1: User Management

  2. Component 2: File Management

  3. Component 3: Change Management

  4. Component 4: Activity Management (needs Adobe Acrobat v7.0)

  5. Component 5: Collaborative Publication

  6. Component 6: Project Management

2006-03-27 Week 11: Assignment 5 due at 18:00 on 2006-03-29.
Assignment 5 is a refinement of Assignment 4 which includes special features in the design and code. Concentrate on getting the proof-of-concept working. If the design of the component needs improvement then iterate the design process as well.

Marking Schema for Assignment 5 (out of 10)
Each person should submit a zip file containing a pdf file of the design model, and a source directory containing your Java proof-of-concept including data files.
Submit a five-page document containing:

  1. A description of the data files you created for the proof-of-concept in order to set up sample data on users, projects, documents, etc for the complete CUWME system. (One page or less) (2 points)
  2. A description of what was omitted/simplified in the proof-of-concept, and a description of how logging of commands is performed in the proof-of-concept for the complete CUWME system. (About 0.5 page) (2 points)
  3. Clear description of the interface of your component as provided in the proof-of-concept source code. (About one page.) (2 points)
  4. The new design of your component in terms of a class diagram and one sequence diagram (for the major non-CRUD use case). (Up to two pages) (2 points)
Also submit the source code itself. (2 points)

Marks 

StudentID    Mark/10    Component
3955141        8           4
4439449        5           6
4440358        9.5         4
4561139        8.5         3
4562577        9.5         1
4798821
4812298        7.5         5
5132290        7           3
5297478        8.25        2
5315239        9.75        4
5315298        8.25        1
5317665        9.5         2
5357896        8.5         6
5374049
5404967
5511186        7           5
5544351        8           2
5548934        9           2
5599644        9           3
5611458        7.75        1
5632242        8.5         3
5653622        9           2
5696569        8.5         4
5758246        8.25        5
5761549        7.5         2
5763134        7.5         1
5763320
5775221        6.5         5
5787084        7.5         1
5788250        9           4
5789877        8           6
5798558        9           5
5812984        8           3
5847745
5946565       10           1

2006-04-10 Week 13: Assignment 6 due at 18:00 on 2006-04-10.

Assignment 6 due at 18:00 on 2006-04-10 (note Monday deadline rather than Wednesday).
Assignment 6 is a refinement of Assignment 4 which includes exceptions and failures in the design and code. Create a test infrastructure for your proof-of-concept; include JUnit tests in the proof-of-concept; and present a final design. Your tests should include some failure cases.

Marking Schema for Assignment 6 (out of 10)
Each person should submit a zip file containing a pdf file of the design model, and a source directory containing your Java proof-of-concept including data files and test infrastructure.
Submit a five-page document containing:

  1. A description of the test infrastructure for the CUWME system as a whole; a description of the JUnit tests for your component. (One page or less) (2 points)
  2. A description of the changes in the design of your component from Assignment 4 (as text only, no diagrams here). (One page or less) (2 points)
  3. Class diagram for the design of your component with brief text descriptions. Remember to include exceptions. (About two pages) (2 points)
Also submit test infrastructure (with test cases and JUnit tests). (2 points)
Also submit the source code itself, showing handling of failures and exceptions. (2 points)

Last modified on April 09, 2006 by gregb@cs.concordia.ca