Copier Paper Path Simulator - Release 2
This second release of the generic copier paperpath simulator project is aimed at making the simulator capable of handling a wider variety of copier configurations, handle more complex jobs and providing better debugging support.
Additional Copier Configurations
The support for additional copier configurations includes:
- Components with different characteristics e.g. a DividerFeeder that feeds sheet dividers and has timing and behavior different from Feeder1 and Feeder2.
- Components with multiple capabilities e.g. a 2-way Stapler that can either put a single staple in the top left corner, two staples along the left side, or pass items through unstapled.
- New types of components e.g. a Binder, which takes a set of items and binds them.
You should be able to support at least three configurations: the configuration from phase 1, and the two configurations shown below. The configuration is selected via a command line argument when the program is started.
Configuration 2
New Components
- DividerFeeder that feeds sheet dividers. It includes two motors, the second must be turned on 5 milliseconds after the first (otherwise the DividerFeeder will jam). The sheet reaches the output 5ms after the second motor is turned on.
- Fuser2 is identical to the Fuser component from phase 1, except that it requires a command to turn on its heating element as soon its sensor has been triggered. The heating element must be turned off precisely 5 milliseconds after it is turned on. (If the turn on command is issued late, fusing happens badly and the paper has streaks. If the turn off command is issued late, the Fuser burns out, and the copier needs a fuser replacement – expensive!). Thus, the Fuser2 timing characteristics are:
- Fuser2Sensor is triggered 10ms after the sheet enters. Fuser2HeaterOn command must be issued at this time.
- 5ms later Fuser2HeaterOff command must be issued.
- Paper stops moving in Fuser2 30ms after entry, until Fuser2Motor is turned on. It takes another 20ms to exit Fuser2.
- Duplexor2 functions exactly the same as Duplexor, except it has different timing characteristics. This configuration happens to have the two path splitters in sequence. A command must be issued to each to direct the paper as desired.
- 30ms to reach the sensor from paper entry. Paper stops at that point until the first motor is on.
- 100 ms to reach the vertical area. It stops there until the second motor is on.
- 100 ms after that to reach PathMerger1.
Configuration 3
This configuration has all three types of feeders. It also includes two new components, the 2-way Stapler and the Binder.
New Components
- The 2-way Stapler is exactly like the stapler, except that it has different capabilities depending on the commands it receives. The features of this stapler are:
- It can output individual sheets through without stapling them, if the output motor is turned on after a single sheet has arrived.
- lt can stack a set of sheets, then output them to the Binder as a set without stapling.
- It can stack a set of sheets, put a single staple in the top left corner and then output the set to the Binder.
- It can stack a set of sheets, put two staples on the left side, and output the set to the Binder. Naturally, this uses up two staples.
- The timing characteristics of the 2-way Stapler are identical to the Stapler.
- Binder stacks all the items it receives. The input to the Binder can be individual sheets, unstapled sets, stapled sets or any combination of these. It takes an optional command to Bind (i.e. it can output unbound sets or sheets if no command is received). It creates and outputs a single bound item.
Generalization of Job Construct
This phase generalizes the concept of a job. A job consists of one or more sets, and these may either be bound together or not. Each set consists of several sheets, which may or may be stapled together. The input may also contain definitions of sets, which are stored and may be used as part of future jobs.
Job Language Grammar
Below is an example set of productions describing the grammar for the input protocol.
Input :== SetDefinition Input | Job Input | Job
SetDefinition :== DEFINESET Setname Set ENDDEFINESET
Setname :== string
Job :== BEGINJOB BIND SetSequence ENDJOB | BEGINJOB SetSequence ENDJOB
SetSequence :== Set SetSequence | Set
Set :== STAPLE SheetSet | STAPLE-2 SheetSet | SheetSet | SET Setname
SheetSet :== Sheet SheetSet | Sheet
Sheet :== SHEET Type | SHEET Type Side1 | SHEET Type Side1 Side2
Type :== LEGAL | LETTER | DIVIDER
Side1 :== string
Side2 :== string
Debug Report
The third feature to be added in this release is some debugging support for the application software. The support to be provided is the ability to display the machine status at any given time, and the ability for applications to modify simulator behavior (to simulate faults etc), without modifying the simulator itself.
The machine status is displayed through a “SHOWSTATUS” command, which takes a time value as an argument. These commands must be issued before the beginning of job execution – for simplicity, you can read them from standard input for your application, prior to the job input. (Realistically, these commands would be part of a simulation control interface, either standard input, command line parameters or a simulation control GUI, whereas the jobs would probably be read from a file).
SHOWSTATUS causes each component in the system to print its current status:
- Whether it contains any items at present. If it does contain items, it reports the physical position of the item and its contents. For simplicity, we will assume that items move at a constant speed of 1cm per millisecond, and start and stop moving instantaneously. Hence you can compute the position of the item relative to the input port [its leading edge, actually] simply by computing the number of milliseconds since its entry, or since the motor to send the item out was turned on. Note that for many components if the output motor has not been turned on, the paper stops inside the component after a certain number of milliseconds.
- If the component contains a stack (e.g. staplers, binder, duplexor), report the contents of the stack. This includes printing out a list of items along with its contents.
- If the component has consumables, print out the current level of the consumable.
SHOWSTATUS 400
DEFINESET sectionSeparator
SHEET DIVIDER
SHEET LETTER ThisPageIntentionallyLeftBlank
END DEFINESET
BEGINJOB BIND
STAPLE 2-way
SHEET LETTER section1page1
SHEET LETTER section1page2
SET sectionSeparator
STAPLE
SHEET LEGAL section2page1 section2 page2
SET sectionSeparator
SHEET LETTER section3 page1 section3 page2
SHEET LETTER
ENDJOB
The output would include the following:
- The description of the final job. The structure of your output should show the structure of the job – as bound, consisting of 5 sets, with one or two sheets in each set.
- Each item (sheet, set, bound set) should display its event trace.
- At t=400, each component should print out its status. At that time, the binder might contain 2 or 3 sets, the stapler might have 1 or 2 sheets, and there might be a sheet in another component e.g. Duplexor2. Duplexor2 should print out the position of the sheet e.g “20cm after input” or “45cm after VerticalPart”. Each component should print out its current consumable holding.
Summary
To summarize, the features desired are the ability to handle multiple copier configurations, job hierarchies, job store-and-recall, and displaying component status. Note that you do not have to do any fault or exception handling, and it is OK to assume that only jobs that are valid for that configuration will be input.
All three configurations can process a series of jobs and stack them on the TopTray and/or OutputBin. All components in every configuration are capable of printing out status information. The initial state of consumables is as follows:
- Feeder1: 40 LETTER sheets
- Feeder2: 20 LEGAL sheets
- Stapler: 50 staples
As before, you need not handle reloading of consumables. If a consumable runs out, trigger the appropriate sensor, and then halt execution if a subsequent operation needs the consumable.
Future Extensibility
This release provides generality in terms of configurations and jobs, as well as better debugging and fault injection support. Hopefully with this base, it would be easy to generalize the simulator to support any configuration, perhaps even read the configuration as an input.
One additional feature that is usually found on high end copiers is the ability to process multiple sheets of paper concurrently. It can be extremely difficult to support concurrency, both in terms of copier control software and in terms of the simulator, which has to be able to keep track of all the different sheets and move them along realistically.
Analyze your design to identify what you would need to do to support concurrent paper movement. Describe an approach for how this feature could be implemented in your system. You do not need to work out all design details or implement the approach. You will provide a one or two paragraph description of your suggested approach in your final design document. If you think a diagram will help explain the idea you can include that also.
Metric Data
You will gather the following product metric data on your unit 2 submission and then again when submitting for unit 3. This data is simple enough that it can be manually collected and computed. Using a spreadsheet for reporting the data may prove helpful. For lines of code (LOC) count you can do this manually, using simple collection routines such as Unix string processing commands or you can also look on the web for programs to analyse C++ program metrics. The LOC metric should not include header files. (Teams should report to the entire class any metrics programs that are found to work well. This can be done in the myCourses discussion area.) The metrics to report are:
- Classification of classes in system. Report the number of classes in each category. Classify each class in your program into one of these categories:
- Trivial: Basically data containers, hardly any behavior
- Manageable: Class that provides a few behaviors, has a limited well-defined responsibility
- Complex: Class that has extensive functionality (lots of code), or many methods, or interacts with many other classes
- Interfaces: All methods pure virtual
- Total size of the whole product in LOC
- Average LOC per class
- Average number of methods per class
- LOC in each method reported as a histogram with bars for 0-5, 6-10, 11-15 LOC, etc. Adjust the numeric bin ranges as you see fit to present what you feel is the clearest picture of your project.
- Average coupling for each class: For each class analyze the code for the class and count the number of different classes that are data members within the class, local variables within methods in the class, used as parameters in the class's methods, are called from methods in the class, and the overal coupling as the sum of all four categories. Report the average coupling per class in each of the four categories and the average overall coupling per class.
General Information
- This project will be implemented in C++. It must run either under Linux on linus.se.rit.edu or Windows XP using g++ and the cygwin toolset.
- This is a simulator, so performance is not critical. Evolvability is the key attribute.
- You are not being graded on minute details of the functional behavior. As long as you broadly get the functionality right, that is enough. You are graded primarily on quality of design and your implementation of it, how well you have achieved fitness for the purpose and your discussion of the rationale behind your design choices.
- You may rework the input and output formats, if so desired, as long as you provide documentation of these changes with your submission.
Assessment
| Component |
Percent |
Comments |
| Presentation |
20 |
Quality of the team's presentation of their product (including prototype demonstration). |
| Design Quality |
50 |
Quality of the product design, including the degree to which it addresses the functional and non-functional requirements, the appropriate use of patterns, and adherence to proven software engineering design principles. |
| Design Diagramming |
10 |
Quality of the design diagrams provided in the documentation and presentation. Elements of this grading will be readability of diagrams at 100% zoom and when projected during the presentation, provision of the necessary complement of diagrams (component, class, sequence, collaboration) to understand the design, and correlation between the diagrams and delivered code. |
| Implementation |
20 |
Quality of the implementation in implementing the functionality of this simulator. An element of this will also be the adherence of the implementation to the design described in the diagrams and presentation, and to C++ coding style standards from previous coursework. Variations to these conventions must be approved by your instructor, and, if approved, must be adhered to by all team members. |
Submission Instructions
- A zip file named p362-unit3project-SSX.zip where SS is the section number and X is your team letter (lower case), where the zip file contains:
- The final design documentation will be submitted as a single Word document, including at a minimum:
-
- Title information, including the name of your team, the name of your product, the date, and a list of all the team members.
- A short overview section describing the product and the features included.
- A UML class diagrams showing the main classes and interfaces in your design, along with inheritance (generalization), association, aggregation, and composition relationships. Include cardinality and role indicators as you deem appropriate to make the diagram clear. DO NOT include state or method information. You will need several class diagrams at different levels of abstraction and for different subsystems to completely document your design in a way that the reader can physically see and intelligently understand.
- Other UML diagrams (e.g., sequence charts, collaboration diagrams) to provide insight into the key dynamic characteristics of your design.
- A table summarizing the responsibility(ies) of each major class. A table of the object data defined by the class and the signatures of the methods in the class other than the accessors and mutators.
- A narrative outlining how the design reflects a balance among competing criteria such as low coupling, high cohesion, separation of concerns, information hiding, the Law of Demeter, extensibility, reusability, etc. This should include a discussion of the design patterns used to achieve this balance in the context of expected further product development.
- Metric data for the system as submitted for unit 2 and when submitted for unit 3. A discussion of this data and any reflections on what it indicates.
- A short reflection on the two strongest and the two weakest aspects of your design.
- The team's ideas for extending the design for concurrent paper handling.
- A copy of the final PowerPoint presentation.
- All the C++ source files required to compile, link, and run your project. A Makefile or script file to rebuild the system must be included.
- A Testing directory which contains a set of test input files and files with the associated output generated by the system when each test was executed. In this directory place a file place a spreadsheet TestIndex.xls that lists the name of each test input/output file and provides a short description of the test and the results. In TestIndex.xls tests that pass simply need to be labeled as such; if a test fails provide a description of the nature of the failure. Test output files will be annotated. After capturing the output generated by the implementation into a file open the file in an editor. Add annotations, i.e. comments, to the test output that will guide the reader to understand the results being shown. You can consider this annotation to be what you would say in your response to your instructor's question when reviewing test output, "Describe why you think this works/fails."
- A file README.txt that includes any other information the team wishes the instructor to know.
Upload the zip file to the myCourses site for this course and section, placing it in the Unit 3 Project folder of Collaborative Files. The title of the submission should be "Unit 3 Project for Team SSX", where SS and X are the same as in step (1) above.
The zip file must be submitted by the end of the day on which the presentations for this unit are made. Late submissions will not be accepted; teams are advised to submit something early to ensure they receive at least minimal credit.
Note: In Windows/XP you can create a zip file simply by creating a new compressed folder.
Documentation and Presentation Instructions
You can find general instructions for your documentation and presentation on the Unit Activities page.
Revision: 1.2, 2005/03/31 06:18:28
