course home↑
 
  FSU Seal - 1851 Course Assignments
COP 4380 Hierarchical State Machines and Reactive Systems Programming
Summer Semester 2016
 
  © 2016 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 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 five 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.
  4. Collaboration is encouraged. You are encouraged to collaborate (only with other students in this class) on ideas behind assignments, including design. However: each student is required to type (not copy) their own words and code and submit this work individually. Copying files or copy/paste from files is strictly prohibited for any assignment. Type your own sentenecs and your own code files. All collaboration on programming must be disclosed in your log.txt file.

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 version of Quantum Event Processor QP/C++ (baseline code) for C++. Install in your CS files system in this directory: ~/cop4380/qpcpp. Use the "make" command in the directory qpcpp/ports/posix/ to build the library. Then test build some of the examples in qpcpp/examples/posix/. The supplied makefiles should work without modification.
  7. (Optional.) You may also want to install both qpcpp and the associated modelling tools on your personal workstation. Any code you develope there should be tested on linprog before submission.

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/LIB/proj3.) 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 under the name "proj3")

  1. cppparser4a.h
  2. test4a.cpp
  3. log.txt # your work log, which should outline both development, including all collaboration information, and testing

When these two files are in a directory on linprog, the command
  g++ -I. -otest4a.x -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/LIB/proj5.
    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
    6. Add new transition j:s11 -> s22 triggered by j_SIG

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

    1. Revised statechart diagram or precise discussion
    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 under the name "proj5")

    1. qhsmtest2m.h
    2. qhsmtest2m.cpp
    3. main2m.cpp
    4. qhsmtest2mx.h
    5. qhsmtest2mx.cpp
    6. main2mx.cpp
    7. log.txt # work log, which should outline development, testing, and collaboration

    The supplied makefiles should build the two projects separately.

    See area51/ace2m.x area51/ace2mx.x for behavior illustrations.

Assignment 6
  1. Using QHsmTest as a model, create a working QHsm implementation of the C++ comment parser CPPParser that functions as (or improves upon) the stand-alone FSM implementation from assignment 3. See area51/cppparser6.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 (may be identical with assignment 4)

    Code Deliverables: (submit from shell via "submit.sh deliverables.sh" - be sure you have copied LIB/proj6/deliverables.sh)

    1. cppparser.h
    2. cppparser.cpp
    3. main.cpp       # note that example main.eg is supplied
    4. log.txt        # work log, which should outline development, testing, and collaboration

    Note that there is a supplied makefile. When your files are in a directory on linprog together with the supplied makefile, the "make" command should build the debug version as dbg/cppparser.x, and "make CONF=rel" should build the release version as rel/cppparser.x

    Note also that there is an example main supplied under the name "main.eg".

    See area51/cppparser.x for behavior illustration.

Philosophers Banquet (level 1)

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" descends into the 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 process two additional signals (annotated for a specific philosopher). The AHHA[n] event and the HMM[n] event are generated by philosophers and trigger a transition one substate or working to the other. 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/proj7. 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 may 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 should be triggered by the (upgraded) random signal generator used in the original simulation. The effect should be to shift all subsequent transitions into working to that substate, until the opposit transition is triggered for that philosopher.

    Literary Deliverables: (submit to Blackboard under Project)

    1. Revised Philosopher statechart accompanied by discussion of operation

    Code Deliverables: (submit from shell via submit script "submit.sh deliverables1.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
log.txt    # work log, which should outline development, testing, and collaboration

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

    Note: This represents a level 1 project, the minimum for a passing grade. The assessment process will first look at the "2" version and, only if necessary, revert to the "1" version.

Philosophers Banquet (level 2)
  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). If there are good reasons to do so, this number of philosophers may be limited by an upper bound determined by these good reasons. Explain in your log.txt.

    Literary Deliverables: (submit to Blackboard under Project)

    1. Revised Philosopher statechart accompanied by discussion of operation
    2. Discussion of modification process, what major hurdles needed to be overcome, and how it was accomplished.

    Code Deliverables: (submit from shell via submit script "submit.sh deliverables2.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
log.txt    # work log, which should outline development, testing, and collaboration

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

    Note: This represents a level 2 project, the minimum for a grade of B. The assessment process will first look at the "2" version and, only if necessary, revert to the "1" version.

Philosophers Banquet (level 3)
  1. Add an active object to the level 2 DPP that is a control module. This module should accept commands beginning with 'C' and provide a way to control the parameters of the banquet. The design, implementation, and integration of this control object into the level 2 banquet is open-ended.