Best代写-最专业靠谱代写IT | CS | 留学生作业 | 编程代写Java | Python |C/C++ | PHP | Matlab | Assignment Project Homework代写

C语言代写 | CMPT 201 Assignment 3

C语言代写 | CMPT 201 Assignment 3


CMPT 201 – Spring 2019, Assignment 3

Due: June 17th, 2019, 11:59 pm. Weight: 10% of your final mark Work type: Team assignment

Your assignment is to implement a peep editor and create a peep ledger using block chain. A peep (not to be confused with a tweet:-) is a 256-character banner that can be edited at any time and can be traced back to any moment since its inception. You must create a project on CS GitLab server (at on which the members of the team can cooperatively work on the assignment.


This assignment has three milestones which are to be met:

  • Milestone 1 – Team: Due Friday June 7th at 11:59 PM. Submit on eSubmit a text file containing

    details of your plan for working on the assignment. This includes dates, work distribution, algorithms, implementation ideas, and technical/algorithmic issues you anticipate facing. Name the text file A3plan.txt. The file must be saved in the Gitlab project.

  • Milestone 2 – Team: Due during your lab session on Tuesday June 11th or Wednesday June 12th
    1. You must have the implementation of the editor working and you must demo it to your lab


    2. The file which implements the editor must be saved in the GitLab project. You must show your

      instructor the GitLab project and a list of the commits.

  • Milestone 3 – Individual: Due June 18th before midnight. Send your lab instructor

    ( an e-mail, detailing the individual contribution of each member of your team. You just need to specify the percentage of the team work done by each student. It can be as simple as: Student A a%, student B b%, Student C 100-(a+b)%.


    Implements a module named peepEditor which allows for the editing of an existing peep (if it is a brand new peep it assumes that the existing peep is empty). The main function of the module is:
    unsigned int editor(char * peep, struct transaction * modBuffer );

    This function allows the editing of the peep and fills the modBuffer with the transactions performed on the original peep. It returns the number of transactions written in the buffer. The term session will be used to refer to all transactions performed during a single call of the editor.
    See the attached peepEditor.h

    Block Chain:

    Implements a module named blockChain which produces an immutable ledger of all the modifications of the peep. The structure of the block is described in the attached file blockChain.h .
    Each session will start as a new block and if needed will be split over several blocks. The blocks will be added

    to the existing chain. The block chain will be saved/read into/from a binary file. The file will contain the blocks in increasing order of their block number.
    The module must contain AT LEAST the following functions which are loosely described in blockChain.h writeBlockChain



Main program which allows interactions with a peep. The program must be able to:

  • Create a new peep and its ledger
  • Edit an existing peep and append corresponding transactions to the ledger
  • Verify the integrity of a peep ledger
  • Show a peep at a given timestamp
  • Display modification history
    What mode it runs in is handled from the command line, this program does not take standard input. For sanity and practice, consider using getopt for the command line manipulation.
    The possible program invocations are ([ ] indicate a parameter):

    peep -c [fileName] – to create (by invoking the editor) a new peep
    peep -e [fileName] – to edit an existing peep
    peep -v [fileName] – to verify the integrity of an existing peep
    peep -h [fileName] – to print the transaction history of an existing peep
    peep -p [fileName] -t [timestamp] –to reproduce a peep at a given timestamp

    peep -p [fileName] –to reproduce the current peep


    1. Please follow Good Programming Style document for guidelines on style.
    2. Some information regarding hashes and block chains will be provided in class. You are encouraged to

      seek out information about these subjects. Make sure to reference any sources you use.

    3. You should design your data structures carefully.

    Packaging and Deliverables

    Your tar file should contain an A3 directory which includes all files related to this assignment. In particular, the A3 directory should contain:

    • READMEatextfileexplainingthecontentofeachfileyouhaveincludedinthedirectoryandtheusage of your submission

  • makefile, in which make all produces all executables as you described in the README file
  • all source files
    • design.txt a design document that describes the design decisions you made. The design document

    is supposed to record the important decisions you made about what had to be done (analysis) and how to do it (design). In particular, it should contain the reasons for why you made your decisions. Part of your design document will be the issues list, which identifies the issues that you encountered during the assignment, whether resolved or not, and how you resolved those that were resolved.

    • Testadirectorycontainingacollectionofyourtestfiles,whichalsomustcontainatestingreportin a text file called testing.txt, describing what and how you tested. We want to be able to easily run the (highest level at least) tests that you ran, so be sure to automate their use in your makefile.

    Your submission must only include source files and documentation files. Do not include any executable, object or core files.

    You are expected to meet normal coding standards. 1. Packaging:

• makefile must work perfectly, so that:
• all executables are created when make all run
• A3.tar.gz tarball is created when make A3.tar.gz run

• Code must compile with no avoidable warnings under -Wall. We expect to see your makefile using this flag when compiling. Marks will be deducted if it does not.

2. Design

  • You are allowed at most one global variable.
  • Were design decisions documented?
  • Was a coherent design approach attempted and how well did it work?
  • Were the principles of program organization applied?

    3. Coding:

  • Produces reasonable output, even with unreasonable input (i.e., exits with error, warns about


  • Prints out warnings upon detection of problems (i.e., “Cannot open file !”).
  • Marks will be deducted for significant coding errors, such as:

    §Not checking the return code where it should be checked. §Not matching the specifications pre/post conditions. §Failure to document a non-obvious loop.

  • Frees any allocated memory.

4. Testing Strategy:

• Any programs (source code) used in order to test programs must be included. We expect you to submit the tests you used and explain why you believe them to be a satisfactory test of your program.

5. Style:

  • All source files must have a header comment box giving the usage information and purpose of the


  • All additional functions must have function information and purpose documented (put such

    documentation with the prototype of the function), as well as having the code documented internally.

  • “Bad” documentation (spurious, misleading or just plain wrong) will be penalized.

    Submission: Your compressed tar file will be submitted through esubmit.

    Marking Scheme

    The following marking scheme will be used for this assignment:



Milestone 1


Milestone 2


Packaging – module has correct structure (README, makefile, source files, Test directory, no extra files) , tarfile extracts properly, …etc.



  • make all
  • executable generated (must be named peep or you risk receiving a 0)
  • testing targets


Peep module passes our tests


Module testing strategy, testing.txt, test documentation


Module and program documentation, design.txt, coding style


Program design, good program structure, no extra global variables, use of multiple files, error checking (insufficient memory, files, …etc.), etc


GitLab project created and used properly


Milestone 3




If files are not named as specified, you risk receiving a mark of zero.

NOTE: Your mark will have two components:

  • 50% of your mark is the team mark
  • 50% of your mark depends on your individual contribution to your team work.
    The individual contribution will be calculated as the average of the reported work contributions from Milestone 3. No mark shall exceed 100.