Homework 2: Analysis

1. Introduction

For this homework assignment, you are asked to develop a candidate object model (objects, roles, responsibilities, and collaborations) and a set of use cases for a software requirements task. This assignment is meant to get you started with the techniques discussed in the first 10 lectures.

Problem Context

In particular, the problem context is one of managing the review process for papers submitted to a journal, such as the ACM Transactions on Computer-Human Interaction, or any other peer-reviewed publication. The stakeholders in such a process typically include authors, reviewers, editors, and a publisher. There are typically three types of editors, an editor-in-chief, a managing editor, and action editors. Typically a journal has only one editor-in-chief, one managing editor, and multiple action editors.

2. Stakeholders

2.1 Editor-in-Chief

The editor-in-chief is responsible for:

  1. reviewing submitted papers to check that they are in-scope (and auto-rejecting those that are out-of-scope),
  2. contacting authors if other problems arise (such as a paper that is significantly longer than the journal's publication guidelines),
  3. assigning in-scope papers to action editors for review,
  4. and working with authors of accepted papers to get the final version of the paper sent to the publisher.

The editor-in-chief has other responsibilities such as publicizing the journal, soliciting authors to submit papers, and working with the publisher to decide how to group accepted papers into future issues of the journal.

2.2 Managing Editor

The managing editor is responsible for:

  1. tracking the state of each paper as it moves through a review process (such as marking a paper as "received" when it is first submitted, "in review" when it has been assigned to an action editor, etc.),
  2. compiling quarterly statistics about the state of the journal (e.g. "18 papers are currently being reviewed. 5 new papers were submitted, 4 accepted, 3 rejected, and 7 received ‘revise and resubmit’ outcomes."),
  3. and contacting authors if there are problems with the manuscript (such as a figure being illegible or if an author forgot some piece of required information such as a phone number or contact address).

The managing editor is also responsible for sending a paper to the action editor once the action editor has been assigned to the paper by the editor-in-chief. After sending the paper to the action editor, the managing editor will also notify the author that the paper is now being reviewed and supply the contact information of the assigned action editor.

2.3 Action Editor

An action editor is responsible for:

  1. finding three reviewers for each assigned paper,
  2. waiting for reviews to be written (an action editor will typically set a deadline for the reviews to be returned, and will then nag reviewers who miss the deadline for their reviews),
  3. and writing a summary review of the paper that conveys the outcome of the review process to the author while also highlighting important issues raised by the reviewers.

The possible outcomes for a review cycle are "accept", "accept with revisions", "revise and resubmit", or "reject".

2.4 Authors

Authors are responsible for submitting papers to the journal and waiting for the outcome of the review process. Authors will sometimes have to respond to the concerns of the editor-in-chief or managing editor if a problem occurs. This may include supplying missing contact information, correcting a problem with one of the paper's figures, or having to rewrite the paper to meet the journal's publication guidelines. Once a paper is in review, the author receives the contact information of the assigned action editor, and may use this information to inquire about the progress of the review. Finally, once the review is complete, the author may have to work with the editor-in-chief to get an accepted paper published or they may have to rewrite the paper to address the issues raised by reviewers before submitting the paper again.

2.5 Reviewers

A reviewer is responsible for reading an assigned paper and writing a review that evaluates whether the paper is ready for publication. A reviewer is typically given a deadline for returning the review to the action editor. If a paper that received a "revise-and-resubmit" is submitted once again, a reviewer will be asked to re-read the paper to evaluate whether the authors have addressed the issues raised by the first-round review.

2.6 Additional Requirements

3. The Problem

You have been asked to design a Web-based system that automates the process of reviewing papers for a journal that currently manages the entire process using paper and postal mail. That is, currently, authors mail six copies of a paper along with a cover letter to the managing editor. The managing editor checks the submission, and then sends the cover letter and one copy of the paper to the editor-in-chief. If there are no problems, the editor calls the managing editor by phone to assign a particular action editor. The managing editor then mails four copies of the paper to the action editor, who then begins the review process. Your customer would now like to move the entire process on-line, including electronic submission of documents, e-mail based reviews and notifications, and automatic collection of paper statistics for the quarterly reports.

4. Instructions

  1. Write a set of medium ceremony use cases that can support the following sequence of events.

    a. John submits a paper to the journal whose length exceeds the journal's publication guidelines.

    b. After John revises the paper and resubmits it, the editor-in-chief sends its title and abstract to the action editors and waits for a volunteer. No action editor responds to the request, even though the paper's topic falls within Bob's and Sally's area of expertise.

    c. Having been assigned to John's paper by the editor-in-chief, Sally sends e-mail to Max, Ellen, and Peter asking if they are interested in reviewing the paper. Max and Ellen accept but Peter declines. Sally asks Tom if he is interested and he accepts. Ellen completes her review in one month, Max takes four months, and Tom finishes his review in three and a half months. Once all the reviews are complete, Sally writes her summary review and sends all four reviews to John.

    At a minimum, there should be one use case that handles submitting a paper, one use case that handles selecting an action editor for a paper, and one use case that handles the review process for a paper. (You can write more if you find a need...for instance, if you find that an extension is getting too big, you can put it's information in a separate use case.) Use the use case template provided by Cockburn that was covered in Lecture 9, but stick to the most important fields: Name, Primary Actor, Main Success Scenario, and Extensions. The Trigger and Precondition fields can be used if you find a need for them.

    Note, your use cases need to support the sequence of events above, not mimic them. Thus, your use cases should not refer to John, Sally, Bob, Ellen, or Peter! Instead, they should generically capture the functional requirements of the system, correctly handling success and failure scenarios.

  2. Using CRC cards develop a candidate object model that you think will support the creation of a software system that handles your three use cases. We have not yet discussed the creation of object neighborhoods (or collaborations), so you do not have to explain (yet) how your objects work with one another to handle the use cases. But, instead try to identify objects that will be important in modeling the domain, responding to events, or carrying out various actions (such as sending notifications). Please use the format specified for CRC Cards in the Object Design book on pages 61-63. Try to identify role stereotypes and a good set of responsibilities for each candidate object or role.

    Note, I recommend actually trying out the CRC cards technique with real index cards. You can either submit the real index cards (either by handing them to me in class or mailing them to me), or you may send me an electronic version of your cards (be sure to include both the lined and unlined sides of each card) along with your use cases and class diagram (see below).

  3. Once you have finished creating your candidate object model, create a UML class diagram that documents any relationships that you believe exists between your classes. Be sure to indicate inheritance relationships as well as any relevant associations between your classes. (Hint: If you say that two classes collaborate on your CRC Cards, then an association needs to exist between them.)

Evaluation

You will be evaluated at how well you have addressed capturing the details of this problem domain (and the specific problem) in your use cases and candidate object model. This homework assignment is worth 50 points (10 points for each use case, 10 points for a well-balanced, well-designed object model and 10 points for your class diagram.

Please submit this homework assignment electronically via the moodle. (Index cards may be handed into me at class or mailed to me. If you decide to send me index cards via postal mail, be sure to have their postmark be on or before the due date of the assignment, and be sure to submit the use cases and class diagram via the moodle.) Please remember that acceptable formats for electronic submission are ASCII, postscript, and PDF. If you upload postscript, be sure to embed any special fonts that you may use directly into the postscript font. (Most printer drivers provide an option to allow you to embed fonts.)

Any questions?

Send questions to <kena@cs.colorado.edu>. Answers to common questions will be discussed in class and/or posted to the class website.

Honor Code

Note: This is an individual assignment. Please do not work on or discuss this assignment with other students in the class.