18-649 Project 2

Event-Based System: Scenarios and Sequence Diagrams

Due Thursday January 29, 2009, at 11:59 PM

Please submit all project-related correspondence to

Changelog:

Dated entries will appear here if any changes are made after the project is released.

This semester, your group will specify, design and build an elevator control system and use it to control a simulated elevator. You will learn of and deal with many of the details of building a distributed, real-time, embedded system.

For this part of the project you will begin to write your requirements for an Event-based System. In project 3, you will construct your full requirements and traceability. Project 2 requires you to create scenarios for the elevator system and draw out sequence diagrams. Follow the format of the "formula for behavioral requirements" you'll see in multiple lectures. A particularly important concern is that only one message can be used as the trigger for an action. If you need two messages to trigger an action, you will generally need to use multiple behavioral requirements and intermediate variables to do this. That having been said, the pre-written behaviors are already in time-triggered format so they can remain unchanged for later project phases. If you are wondering why this is all such a big deal, come to office hours and ask us.

Assignment:

We've done a lot of the work for you already!

First, download the portfolio template from the portfolio page. You will fill in the template as you go through the projects. Make sure you read in detail the requirements for formatting and portfolio structure. You will be expected to follow these requirements throughout the semester, and you will lose points if you do not follow them.

Once you have unpacked the portfolio template, you should check out the following documents that we've provided (each file is listed along with its path in the portfolio template):

Architecture diagram - architecture/architecture.html
Use Case diagram - architecture/usecases.html
Behavioral Requirements I - System Object Descriptions and Message Dictionary - reqs/requirements1.html
Behavioral Requirements II - Distributed Controller Requirements - reqs/requirements2.html

From that use case diagram we've given you a Scenario and Sequence diagram template (scen_sd/scen_sd.html). There are a few examples given in the template to get you started; you will be responsible for filling in the rest.

We want you to use UML (Unified Modeling Language) to develop your behavioral requirements. Here is the procedure for developing your behavioral requirements by first creating sequence diagrams:

Complete the Scenario and Sequence Diagram template by filling in a Scenario, Post-Conditions, and a Sequence Diagram for each of the Scenarios given. You should pick reasonable and useful post-conditions, and we realize that post-conditions will vary among different project teams. The Scenario is a brief statement of how a user might use the system -- the same idea as in Project 1. Post-Conditions tell the state of the system after the Scenario is completed. The Sequence Diagram graphically shows messages passed between objects in the system. Use only objects given in the Elevator Behavioral Requirements and obey the interface of each object (i.e. objects receive only documented messages and don't receive the rest; objects can only send documented messages and not others in the message dictionary). These restrictions are in place to get you headed in the right direction to create a highly distributed system.
We've provided a couple examples to get you started. Feel free to leverage work done from Project 1 - realize, though, the Pre-Conditions are a little different and you are concerned with the behavior or the entire elevator system, not just the doors. Feel free to change the examples, as well - the examples given aren't very 'smart' and are sub-optimal in terms of performance.

There are 12 sections total - we want each team member to complete at least three sections. Please have the author team member record his/her name in the section that he or she wrote. The project will be graded on a team basis, and collaboration is encouraged, but we want everyone to get a shot at it. Turn in the completed template with each section signed by the author. You are welcome and encouraged to complete additional scenarios and sequence diagrams that you think are relevant. You will almost certainly have to create more of them in later project phases to specify complete behavior for the elevator, so it won't hurt to get an early start.
As As in Project 1, a checklist of your work is required. We want to have traceability from your numbered scenarios to the sequence diagram. Have another member of your group check the following list of questions about your sequence diagram:
1. Name of the person conducting the audit?
2. Does each step in the scenario match an event in the sequence diagram?
3. Are all arcs labeled with a valid command in the sequence diagram?
4. Are all boxed items correct parts of the elevator architecture?
The results of this audit must be included in the Scenarios and Sequence Diagrams document. You should include a copy of the audit for each and every scenario/sequence diagram combination. Place the audit in the file after the sequence diagram it is related to.

Use Cases and Scenarios

Each use case defined in the Use Cases Diagram has one or more corresponding scenarios. Every use case should have at least one scenario and sequence diagram.

You will not need to create any additional scenarios in this project, but you will add scenarios and sequence diagrams as you go through later projects. When you do so, think about which use case each new scenario corresponds to, and add the new scenario in the appropriate part of the document. If you need to create additional use cases, you may also need to modify the use case diagram.

Team Design Portfolio:

Each team shall maintain a design portfolio to organize all materials for the design package of its elevator system. You are going to update your portfolio every week, so be sure to keep an up to date working copy.

Files that you should update for this week are:

Portfolio Table of Contents
Scenarios and Sequence Diagrams
Improvements Log

Ensure your design portfolio is complete and consistent

The following is a partial list of the characteristics your portfolio should exhibit:

All required documents are complete and up-to-date to the extent required by the projects (you do not need to update files or links related to future projects).
All documents include group # and member names at the top of the document. (This includes code, where this information should appear in the header field)
Individual documents have a uniform appearance (i.e., don't look like they were written by 4 individual people and then pieced together)

Handing In Results

Each team shall submit exactly one copy of the assignment.

Follow the handin instructions detailed in the Project FAQ to submit your portfolio into the afs handin directory (/afs/ece/class/ece649/Public/handin/project2/group#/ontime/).

Be sure to follow ALL the portfolio guidelines detailed in the Portfolio Layout page.

Any submission that contains files with modification dates after the project deadline will be considered late and subject to a grade deduction (see course policy page for more information).

If you don't already have an ECE account send e-mail to gripe@ece.cmu.edu and Cc to staff list requesting a course account for 18-649.

Deliverables

This assignment counts as one team grade.

Points will be assessed as follows:

(96 points) 8 points for each scenario. Each scenario, post-condition description, and sequence diagram will be graded as an integrated whole worth 8 points. The primary grading questions are: Are the post-conditions reasonable and precisely specified? Does the sequence diagram represent a sequence of messages that would produce the behavior described in the scenario? There are 12 scenarios, in addition to the 3 we have completed for you. These must go in the Scenarios and Sequence Diagrams document mentioned earlier.
(12 points) 1 point for each checklist being present and complete, one checklist per scenario. The person who completes the checklist for a scenario must not have written that scenario, as described above. For each scenario, the corresponding checklist should be next to it in your Scenarios and Sequence Diagrams document page.
(5 points) An entry in the Improvements Log that tells us what can be improved about this project. If you encountered any minor bugs that we haven't already addressed, please mention them so we can fix them. If you have no suggestions, say so in your entry for this project.

We want you to go through the process of developing the scenarios and sequence diagrams, and in project 3 use them to generate the behavioral requirements. Project 3 will require that you show traceability between them. Consistency and coherence are the two criteria we're looking for. Your UML diagrams do not have to be perfect. You should make your best effort to completely specify all behaviors for the software control objects. However, be warned that if you slack off here, you'll have a much harder time with later project phases because you'll have to do all the work eventually to create a completed system. If you chose to create additional scenarios and sequence diagrams you should follow through with them as with the mandatory assignment. But we won't take off points for mistakes made that solely involve optional material.

Back to course home page