course home↑
 
  FSU Seal - 1851 Course Assignments
COP 5385 / COP 4380 Hierarchical State Machines and Reactive Systems Programming
Spring Semester 2011
 
  © 2011 R. C. Lacher.
 

Instructions for Assignments

There are generally four kinds of activities in assignments: reading, software, discussion, and exercises. (Not every assignment will have every kind of activity.) All portions of an assignment should be completed by the due date.

The exerices in an assignment should be submitted for grade by the due date. These should be prepared and submitted as follows:

  1. Specs. Prepare a complete document:
    1. Provide a header that identifies the document and its author, for example: 
      COP 5385 [ or COP 4380] Assignment xx
(your name)
(date)
    2. Number your pages
    3. For each exercise:
      1. State the exercise
      2. Provide your solution to the exercise
  2. Submissions. Submit your assignments via the Blackboard Assignments button. Written documents and graphics should be in pdf format (NOT MS Word source code). Computer code should be left as is, a text file with appropriate suffix. Zip'ed collections may be submitted.
  3. Deadlines. I am more interested in quality than time, within practical limits. Therefore I am leaving seven extra days to complete each assignment, measured from the posted due date. Please make sure that your use of this extra time shows in the quality of your submission.

Assignment 1

  1. Review Course Syllabus
  2. Read Chapter 1 of [Sam2]
  3. Locate the Visual Basic Calculator on the textbook support web site, download and launch it. Try the sequence of operations: 1 , / , - , = , 2 , = and watch it crash. Launch again and try 2 , x , CE , 2 , = and notice that CE had no effect, even though it appeared to cancel the entry 2. See how many ways you can break the VB calculator.
  4. Find and launch the Quantum Calculator QCalc. Run QCalc and try to alighn actions with the statechart on Slide 1-8 in the lecture notes. (Note the State display.) Can you break QCalc? See how it handles the unary + and - operators.
  5. Not all states of QCalc can be active. For example, ready, operand1 and operand2 can never be active. Explain why.
  6. Download/Install the latest versions of Quantum Event Processor QP/C++ (baseline code) for C++.

Assignment 2

  1. Read Chapter 2 of [Sam2]
  2. Read OMG UML Statecharts Specification Section 2.12. (Download or click-to-read the OMG document here.)
  1. Modify the portion of QCalc illustrated in the figure to the right to allow the user to enter any number of unary "-" operations with the effect of reducing an even number of "-" entries to none and an odd number to one, as in: 
          --2   = 2
      ---2  = -2
      ----2 = 2
      . . .
  2. Propose HSM to model ...
    1. Postfix (reverse Polish) logic calculator
    2. A nifty app for desktop or handheld device
 Fig 2.9 of [Sam]

Assignment 3
  1. Read Chapter 3 of [Sam2]
  2. CParser Revisions
    1. Find the source code cparser4.h implementing CParser, along with the accompanying test harness test4.cpp. (See the course code library ~cop4380p/spring11/assign3.) Make sure you can compile and run the test.
    2. Extend the CParser4 FSM to a C++ Comment Parser FSM by adding appropriate states, events, and transitions to handle the double slash comment style.
    3. Extend each of the implementation to this new FSM. Test the code using an extension of the test harness distibuted. Call the extension CPPParser4
    4. Describe systematically the kind of effort required to make these modifications: what new things need to be created? Where is code added? How spread out is the upgrade with respect to the original code?
 Fig 3.1 of [Sam]
  1. Revise CPPParser4 to CPPParser4a by adding initial, entry, and exit actions to states:
    1. Initial action (defined for initial state): calls initial transition
    2. Entry action: announces entry to state (and possibly more)
    3. Exit action: announces exit from state (and possibly more)
    Use the following enumerations for this implementation: 
    enum FsmEvent     // system events
{
  INIT_SIG = 0, ENTRY_SIG, EXIT_SIG, USER_SIG
};

enum CParserEvent // CParser events
{
  CHAR_SIG = USER_SIG, STAR_SIG, SLASH_SIG, BLANK_SIG
};

Literary Deliverables: (submit to Blackboard under Assignment 3)

  1. Responses to questions
  2. Evaluation report, source code, and discussion of working code.

Code Deliverables: (submit from shell via submit script)

  1. cppparser4a.h
  2. test4a.cpp

When these two files are in a directory on linprog, the command "g++ -I. -otest4a.x -W -Wall -Wextra test4a.cpp" should build without warnings the executable ./test4a.x.

Optionally, you may use the distributed test harness test4acpp.cpp (requiring a couple of additions to CPPParser4a). See area51/test4acpp.x for behavior illustration.

Assignment 4
  1. Read Chapters 4 of [Sam2]
  2. Extend the statechart on the right to a C/C++ comment parser. This machine should correctly process C++ code with both C style comments and C++ style comments.

    Note: You may use a text-based description of the statechart in place of graphics, provided that you (1) describe the original statechart shown and (2) use color to highlight the changes you make in extending the original to include C++ comments.

 Fig 4.4b of [Sam]

    Literary Deliverables: (submit to Blackboard under Assignment 4)

    1. Revised statechart diagram or precise discussion
    2. Brief discussion of product and development process

Assignment 5
  1. Modify QHsmTest as follows:
    1. Begin with the code distributed in the course code library: ~cop4380p/spring11/assign5.
    2. Add new state s22 with parent state s2
    3. Change transition d:s211 -> s21
      to d:s21 -> s22
    4. Add new signal J_SIG
    5. Add new transition j:s22 -> s11 triggered by j_SIG

    2. Literary Deliverables: (submit to Blackboard under Assignment 5)

    1. Revised statechart diagram or precise discussion
    2. Code printout
    3. Brief discussion of product and development process
    QHsmTest Statechart from Fig 4.3 of [SAM, p95].

    Fig 4.3

    We are working with the new version, depicted in Fig 2.11 of [SAM2, p88]. The essential differences are the way init signals are processed.

    Code Deliverables: (submit from shell via submit script)

    1. qhsmtest2m.h
    2. qhsmtest2m.cpp
    3. main2m.cpp
    4. makefile2m

    When these four files are in a directory on linprog, the "make -f makefile2m" command should build the debug version as dbg/ace.x, and "make -f makefile2m rel" should build the release version as rel/ace.x

    See area51/ace2m.x for behavior illustration.

Assignment 6
  1. Using QHsmTest as a model, create a working QHsm implementation of the C++ comment parser CPPParser that functions as close as practical to the stand-alone FSM implementation from assignment 3. See area51/cppparser.x for behavior illustration.

    2. Follow the convention established in the QHsmTest, wherein:
    cppparser.h: contains the CPPParser signals and external declaration of the_hsm
    cppparser.cpp: contains the class definition and implementation
    main.cpp: contains event loop, stand-alone (static - file scope) dispatch, and any other special stuff such as BSP functions.

    Literary Deliverables: (submit to Blackboard under Assignment 6)

    1. Revised statechart diagram or precise discussion
    2. Code printout
    3. Brief discussion of product and development process

    Code Deliverables: (submit from shell via submit script)

    1. cppparser.h
    2. cppparser.cpp
    3. main.cpp
    4. makefile

    When these four files are in a directory on linprog, the "make" command should build the debug version as dbg/cppparser, and "make rel" should build the release version as rel/cppparser

    See area51/cppparser.x for behavior illustration.

Assignment 7

Open for discussion in the Project forum - be sure to attend there for possible refinements.

  1. Extend the DPP model to include:
    1. A new Philosopher state "working" with substates "thinking" and "writing"
    2. The TIMEOUT-triggered transition to "hungry" would be handled by this parent state.
    3. A transition to "working" descend into the most recent substate occupied (or triggered) most recently.
    4. The new signal AHHA would trigger a transition from "thinking" to "writing", and the new signal "HMM" would trigger the transition from "writing" to "thinking". Your solution should be in the form of new statechart models with adequate descriptions of terms.
     
    Fig 7.6

           DPP Statecharts before changes
  1. The new system should consume two additional keyboard signals: "wn" (n = 0,1,2,3,4) should send the AHHA[n] event, and "tn" should send the HMM[n] event. Note that the AHHA and HMM events should be consumed by all reallizable Philosopher states (except the one that is the target of the triggered transition). When a philosopher is not in a working substate, these signals should trigger an internal transition that revises the work_history target.

  1. Note the material distributed in LIB/assign78. This is a working implementation of the DPP as described in the text, with 5 philosophers. Make an ordered list of the tasks required to upgrade the Dining Philosophers Problem QF implementation for your new model.
  2. Implement your new model, as described above, including calls to BSP_displyPhilStat that announce the current state for each philosopher. Use "1" appended to file names for this new implementation.

Hints:

  • You will find it convenient to move the calls to BSP_displyPhilStat from table1.cpp to philo1.cpp, since some of the new state transitions will not involve table. (Do this before any other modifications, to be sure you have it right. The obvious place for these calls is in the case handling Q_ENTRY_SIG.)
  • Note that the sub-states of "working" don't affect transitions to "hungry" and "eating".
  • You will need a private pseudo-state of the appropriate type to remember the working history - a slight misnomer, since this history can be revised when the philosopher is in the hungry or eating states - which is the target of transitions out of eating. (See the Transition to History state pattern.)
  • The transitions between thinking and writing are keyboard-triggered. The effect should be to shift all subsequent transitions into working to that substate, until the opposit transition is triggered for that philosopher. See the sample executable LIB/area51/dpp1.x (which also mirrors keyboard signals to screen). Try entering something like: 
    dpp.x 100000000
w0 w1 w2 w3 w4
    Note that before the keyboard entries all philosophers work in the "thinking" state, and afterward they all work in the "writing" state. 
    dpp.x 100000000
t1 t3
    will shift Philosophers 1 and 3 back to work in the "thinking" state.

    Literary Deliverables: (submit to Blackboard under Assignment 7)

    1. Revised Philosopher statechart accompanied by discussion of operation
    2. Ordered task list, briefly annotated after completing the development process
    3. Code printout

    Code Deliverables: (submit from shell via submit script LIB/assign78/assign7submit.sh)

    dpp1.h     # defines api for problem
bsp1.h     # "board specific" stuff
bsp1.cpp   # implements bsp1.h
philo1.cpp # implements philosopher
table1.cpp # implements table
main1.cpp  # driver program
makefile1  # builds project

    When these files are in a directory on linprog, the "make -f makefile1" command should build the debug version as dbg/dpp.x, "make -f makefile1 rel" should build the release version as rel/dpp.x "make -f makefile1 spy" should build the spy version as spy/dpp.x

    Note: Assignments 7 and 8 may be developed and submitted simultaneously. Together, these two comprise a final project for the class. The code file naming should make it convenient to develop both assignments in the same directory with a copy of the distributed files. The assessment process will first look at the "2" version from assignment 8 and, only if necessary, revert to the "1" version from assignment 7.

Assignment 8
  1. Extend the DPP model from assignment 7 (with the more complex philosophers who think and write) to allow a number of philosophers to be determined by the user. This may be at compile time (setting a constant in the file "main2.cpp") or at runtime (supplying a command line argument). Runtime is preferred. If there are good reasons to do so, this number of philosophers may be limited by an upper bound, not less than 50.

    Literary Deliverables: (submit to Blackboard under Assignment 7)

    1. Discussion of modification process, what major hurdles needed to be overcome, and how it was accomplished.
    2. Code printout

    Code Deliverables: (submit from shell via submit script LIB/assign78/assign8submit.sh)

    dpp2.h     # defines api for problem
bsp2.h     # "board specific" stuff
bsp2.cpp   # implements bsp2.h
philo2.cpp # implements philosopher
table2.cpp # implements table
main2.cpp  # driver program
makefile2  # builds project

    When these files are in a directory on linprog, the "make -f makefile2" command should build the debug version as dbg/dpp.x, "make -f makefile2 rel" should build the release version as rel/dpp.x "make -f makefile2 spy" should build the spy version as spy/dpp.x

    Note: Assignments 7 and 8 may be developed and submitted simultaneously. Together, these two comprise a final project for the class. The code file naming should make it convenient to develop both assignments in the same directory with a copy of the distributed files. The assessment process will first look at the "2" version from assignment 8 and, only if necessary, revert to the "1" version from assignment 7.