Homework II

Explanations about keys (PK / FK)

PK (primary key) – Unique field or a group of fields in a table or a file that identifies a record (row in a file). Typically an integer or UUID is used, but it can be any value that is unique. One file or table can only have a single primary key. Each file or table has to have a primary key.

FK (foreign key) – this is used to create relations to other tables or files. If a foreign key matches the primary key in another file or table, then these items are related to each other. One file or table can have multiple foreign keys and they’re not unique (can repeat).

Foreign key and primary key form a relation between two files or database tables.

E.g. one person can have multiple children; one receipt can have multiple products; one student can have multiple subject declarations; One person can own multiple properties;

For homework II, you have to write a program based on the set requirements and document the work. The focus of this homework is implement dynamic memory allocation for data storage and writing a large, complex program.

This homework task is larger and more complex than any of the homework tasks before. Plan your time accordingly!

The task

Requirements for the program

The code must adhere to all of the best practices introduced during Programming 1 and Programming 2.

Your solution can include topics that have not been covered, as long as they are used correctly and well documented. You need to provide motivation why those concepts were used so that it clear, that you have mastered those topics.

Requirements for the standards and environment

The program must be written in the C programming language. You are permitted to use the C90 and C99 standards. Using newer standards (C11, C17, C23) is permitted, if it provides additional value. This must be explained in the report.

In addition to the standard C libraries, you are allowed to use C POSIX and GNU C libraries and extensions. Use of any other third party libraries must be agreed upon separately.

Your program will be compiled and tested in a Linux environment, equivalent to the one in the lab computers (OpenSUSE SLED-15 SP5, using GCC-12) or with the latest Ubuntu version (Ubuntu Linux 25.10, using GCC-15 or later). Compatibility with Windows or MacOS is not required.

General requirements for the solution

  • Code must be divided into more than a single file. Exact number of files is and code division left to the author of the solution.
    • Minimally it must be split into a header and a code file
    • If multiple code files exist or code is divided between multiple directories, a Makefile must be provided for compilation
  • The data must be read from two separate files into memory
  • Default data file names must be coded into the program. You are allowed to use command line arguments, but they must not be necessary to use your program.
  • Data must be kept in dynamically created data structures
    • You can use dynamic arrays, linked lists, trees etc.
    • The amount of memory allocated must be dependent on the number of records in the input file
    • The amount of memory allocated must match what is required to keep the data in memory
    • Program must work with a variable amount of records – adding or removing records from files should not cause issues
    • There must not exist any arbitrary size limitation for the input files
    • Variable length arrays inside of the struct (e.g. strings) must be allocated dynamically to match exactly what they require to be stored. Fixed length arrays and strings must be static
    • Limitations do not apply to temporary buffers. You can use both static and dynamic memory for buffers.
  • Structures used must be appropriate for the given task
    • At minimum, all information from the files should be stored in the structures
    • You can add members to the structure as needed
    • You can define additional structures to support your task as needed
    • If your data contains time and/or date, you must either use a nested structure to store them or pick an appropriate data type from time.h  library
  • All actions by your program must be repeatable without exiting the program!
    • Create a menu that allows performing all tasks listed in your variant
    • Each task in your variant creates at least one menu option for your program.
    • You are allowed to add additional menu options that are not defined in the variant (e.g. for debugging).
    • The result of each action is displayed on the screen
    • There must be an option to gracefully exit the program
  • If a task requires you to modify, add or delete data, the modifications must be persistent (written to the data files used by the program). If the program is executed again, it must use the updated data
  • Your program must include logging
    • Every action by the user must be logged
    • One log entry per line
    • All log entries must include a date and a time
    • Log must also include non-visible actions such as starting of the program, successful reading of input file, etc.
    •  All previous logs must be retained.
  • The program must provide basic user experience (UX)
    • If a user is sent to a nested menu (i.e. second level menu), they must be able to return from it without completing the action.
    • The program must notify the user of any errors encountered in a clear manner. The message must be precise and helpful to the user to solve the issue. All error messages must be written to the stderr  standard stream.
    • When user input is expected, the prompt must be clear to the user. If the input needs to be in a specific format, you must provide the user with the expected format. If applicable, add an example of how the input should be written.
    • If the program contains searching, filtering or grouping features and there are no matches the set criteria, it must be written explicitly to the user.
  • No memory leaks, wasted or unreleased resources. All resources must be returned to the system by you before the program exits. Use Valgrind to check.

Input data file requirements

  • In total, you must create and use two data files. Each data file can only contain the fields described in your task variant.
  • The data in the files is connected by a PK-FK (primary key – foreign key) key-pair
    • The entities are tied with a zero to many multiplicity (e.g. one student can declare multiple subjects; a student can also have no subjects declared)
  • Data model for the input files is created by the author of the solution based on their capabilities and knowledge. This includes data field delimiters, order of data fields, data field contents,  complexity,  etc. The chosen data model and the decisions for it are documented by the author in the document provided alongside the program.
  • The data records will be created by the author of the solution and submitted with the solution.
    • There must be at least 10 records the first file (containing only the primary key) and at least 15 records in the second file (containing the FK referring to the records in the first file).
    • If the author submits multiple sets of input files to demonstrate different capabilities of the program, the minimum data length limits are only applied to one of the sets.

Documentation template

Use the same templates as you used in Programming 1, Homework 1 (https://blue.pri.ee/ttu/programming-i/homework-i/) and adjust it to fit the requirements of this homework.

Documentation requirements

Focus on structured documentation!  Avoid story-telling (except summary).

  • Title page
  • Declaration of originality
  • List of abbreviations and terms (can be omitted if not present)
  • Table of contents
  • List of figures
  • List of tables
  • The task description (variant)
  • Detailed description of the solution (no walls of text!)
    • A brief description of what the program does.
    • Program workflow – In what order are things done? (Do not go into details! About half a page)
    • Project structure – names of files, short description. If code is divided into directories, explain the division.
      Recommended: show output of tree  application
    • Document the structures
      • Purpose of the structure
      • Details (member name, data type, description, example value), formatted as a table
    • Document the enumerations (if applicable)
      • Name, description and possible values of the enum
    • Special situation / error handling
      • Description of issue
      • What’s the status of it – did you solve it, work around it, is it still present in the code
      • If it was mitigated, how did you mitigate it.
  • Data file structure
    • Structure of one record (data field order, separators between fields, separators between records
    • Data fields – name, data type, example of a value, meaning of data (semantics), any limitations (e.g. length, value range, illegal values)
    • Present a single data record from the file as an example.
  • Extra task (if applicable)
  • Summary
    • Write a few sentences about your approach to the task and progression during it
    • Write a few sentences about the task itself and the complexity of it
    • If possible, give an estimate on the workload
    • Would you recommend using this task in the future? Would you change anything about it and if so, what?
    • Additional comments, emotions, thoughts
  • References (can be omitted if not present)
  • Screen capture(s) of the program
    • Screenshots can be added as an appendix or embedded within the write up of the solution – in this case you can extend the length by the amount of pictures
    • The screenshots should show both normal operation and operation in various error situations

Extra task for bonus points

It is possible to earn up to 15 bonus points from the task. In order to get any points, you must include the added features to the report. It is possible to obtain partial bonus points if not all requirements are met.

To get bonus points, the following requirements must also be met in addition to the base requirements

  • Code must be well structured. Makefile must be provided to compile the solution.
    • Code must be divided into multiple code and header files
    • You can’t have all the files left in the root directory of the project – some effort must be put into at least basic division of files into subdirectories
    • Makefile must minimally use CFLAGS and CC variables
    • Makefile must minimally contain recipes for  all  and clean .
    • Makefile must be written in such a way that it would support recompilation of only modified source files
    • The rest of the complexity for the Makefile is up to the author
  • Logging must be created as an independent library
    • It must be designed as an independent library, contained within itself (no use of extern )!
    • It must support setting the name of the log file
    • It must support different logging levels, implemented as an enumerable type
    • It must support setting the logging level. Logs with lower priority than the set level are not logged.
    • All logging events must include the logging level.
    • All state variables (log file name, logging level, …) for the library must be stored within the library. You are not allowed to directly access the variables from your main project, but instead must use the functions implemented in the logging library.
  • Program must be able to work with text fields containing multiple words
  • You must add a level 1 heading to the documentation called “Extra task”.
    • Describe the added features
    • Explain how your logging library could be used in other projects by other developers. Provide a specification for all the key (important) functions for someone who would like to use your library – i.e. the functions that they can call from your library, excluding the internal library functions not intended to be used by others.
    • Explain the weaknesses and strenghts of your chosen data file format. Are there any limitations to what the data can contain?
    • Walk through the reasoning for what you chose to include, or deliberately omit, in the Makefile. List all the recipes that can be called in your Makefile with a short description. Do not list the intermediate recipes that are only called by other recipes, which are not intended to be called directly.

Deadlines

A complete homework must be submitted no later than 26.04.2026

Each day passed the homework deadline will deduct 1 point from the final homework score. The late penalty is capped at 30 points.

If we have questions about the submitted homework or are not sure about the original author of this work, we will grade this with 0p. In this case, the work must be defended.

If it becomes necessary, we will enforce the rules and guidelines of [Procedure for processing a student’s violation of academic practices and contemptible behavior in the School of Information Technologies]

We will only accept Your homework until the lockdown date (check introduction slides). Past that, submitting your homework will not be possible.

Submitting Your work

The homework needs to be submitted in the Moodle course under Homework 2.

Files required:

  1. Documentation (PDF)
  2. All of the code files (.c and .h) to compile the program.
  3. Data files required to run the program

Depending on your solution, a Makefile may need to be included (e.g. multiple code files, different C standard, extra task, ..)

Naming schema: HW2_lastname[_filename]

Naming schema only applies to files directly uploaded to Moodle. It does not apply to files stored in the archive. Even if you upload the source code as an archive, the PDF file must be uploaded separately!

Example (separate files):

HW2_Tiib.c
HW2_Tiib.h
HW2_Tiib_data.txt
HW2_Tiib_report.pdf

Example (project as an archive):

Example:

HW2_Tiib_project.zip
HW2_Tiib_report.pdf

NB! If you changed the names of the files before uploading, make sure your solution still compiles and works with the new names!

Result and feedback

After your work has been checked and graded, you will see the result and feedback on Moodle (visible from your gradebook only!). If everything was well done, feedback may be absent.

Fixing your homework

You are allowed to fix and improve your homework score until the date of homework lockdown. All fixed submissions are subject to defense.

To fix your homework, first go through your feedback. Then contact your teacher and agree upon the process of how this homework can be fixed.

NB! If fixing the homework changes more than half of the original homework, it is considered as submitting a completely new homework, from which minus points can be deducted from depending on the time of submission.