18-649 Project 2

Event-Based System: Scenarios and Sequence Diagrams

Check the course webpage for due dates

Please submit all project-related correspondence to  


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.


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):

It is important that you read and understand the above documents before continuing with this assignment.  For this project, you will be filling in the Scenario and Sequence diagram template (scen_sd/scen_sd.html).  We have already completed the first three scenarios to get you started; you will be responsible for filling in the rest.

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.

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. The Dia source files for the example sequence diagrams are included in the project portfolio. (Dia is availiable in Ubuntu's default repositories, and is available for most OS's from their Sourceforge page )

There are 12 sections total - we want each team member to complete at least three sections. Please have the author of each scenario/sequence diagram record his/her name and andrewID 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. 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.

Use Cases and Scenarios

Each use case can have multiple corresponding scenarios.  Therefore, every use case should have at least one scenario and sequence diagram.  The template provided to you in the portfolio already has 9 pre-defined use cases (derived from the use case 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.

Peer Reviews

Each students work needs to be peer reviewed by another member in the group.  A template for the peer review checklist can be found in logs/peerreviewlog.html. A few things to keep in mind while performing the peer review are:

Once the peer review checklist has been completed, update the the Peer Review Log.  A detailed explanation of how the checklist should be used can be found in the Project 2 Recitation slides.

Individual Contribution

Every task defined in this project should be included in the Individual Contribution spreadsheet and assigned to the student that completed it. The minimum requirements of the project are listed in the spreadsheet already. If you did any additional work for the project, please include it in the spreadsheet.

Individual student penalties for not performing The minimum required tasks are:

After completing this spreadsheet including it in the same folder with your Peer Reviews. You will submit one of these spreadsheets every week.
An example of how to complete this spreadsheet is provided here.

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:

Ensure your design portfolio is complete and consistent

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

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).

Grading (121 points)

This assignment counts as one team grade.  The grading rubric ( PDF) is available for your reference.  You are NOT required to submit a self-grade for this project.  Please note that the grading rubrics are a general guideline and that you are still responsible for all the details in the writeup.  If the grading rubric and the project writeup conflict, the project writeup takes precedence.  If you find a conflict, please let us know by sending mail to the staff list.

Points will be assessed as follows:

Note 1:  The scenarios you develop here will be used in Project 3 to generate the behavioral requirements. Your design does not have to be perfect, but you should make a sincere effort at a correct design.  If you haven't already, read about the importance of design process.

Note 2:  Eventually, you will have to create additional scenarios and sequence diagrams.  You are not required to do so for this project, but if you choose to, you should follow through with them as with the mandatory assignment. We won't grade any optional additions you make, but we won't take off points for mistakes either (until we reach the project where the additional sequence diagrams are mandatory).

Each team member must satisfy the minimum stated per-member requirements. Team members who omit any required per-member activity will be penalized as described on the course admin page.

Back to course home page