Goal

  Develop a simulator of process scheduling in an operating system.

  Phase 1 - application development

  Specifications

  The system is described by the following characteristics:

• The system contains a certain number of processors and a certain amount of memory (RAM), which are parameters of the simulation.
• The scheduling algorithm is preemptive Round-Robin, and all user processes have the same priority. The size of the scheduling time slice is a parameter of the simulation.
• If the scheduler decides to schedule a user process and there are multiple processors available, the process is scheduled on the processor on which it was executed most recently in the past.
• Apart from user processes, there is a system process, which has the task of executing the system calls requested by the user processes. This process has a higher priority and is released on a periodic basis (the period is a parameter of the simulation); when released, it has to wait until a processor becomes available (if no processor is available at the release moment).
• A process can be executed only if it is loaded into the memory. The amount of memory available in the system may be less than the total amount required by all processes, so virtual memory is used: some of the processes are stored onto the disk. Whenever a process is scheduled that is not already in the system's memory, it must be copied from the disk, which may in turn require saving other processes onto the disk. The replacement policy used for the virtual memory is LRU (Least Recently Used). The transfer rate to/from the disk is constant and is a parameter of the simulation.
• Scheduling must be employed:
  • when one or more processors have become available
  • when one or more processes have been released, if there is at least one processor available

  The input for scheduling is a file containing the simulation parameters (see above) and a list of processes. For each process, the following information must be provided:

• The release time.
• The required amount of memory.
• A sequence of execution intervals, interleaved with system calls, for which the execution times are indicated.

  An execution interval can only be executed sequentially.
  Example: the sequence (5 2 3 4 9 4 6) means that the process consists in 5 execution intervals, of lenghts 5, 3, 9, 6, respectively. They are separated by 4 system calls, whose execution times are 2, 4, 4, respectively.

  The output is a description of the execution of all actions (processes, system calls, virtual memory transfers) on the corresponding processors. This must be provided both as a text file and as a graphical representation.

  General requirements

• The implementation must not make use of library functions, i.e., the code must be written by the programmers. There is one exception from this rule: the implementation of the graphical interface, where the use of libraries is allowed.
• Permanent communication with the beneficiary is necessary, so feel free to ask any questions you may have about the requirements. Programs that do not do what they are supposed to, due to misunderstanding the requirements, will be penalized.
• Any programming language may be used, provided there are unit testing and mocking tools for it, as well as assertions (which must be language-specific, apart from unit testing assertions); all these will be necessary during the subsequent phases.
• It is recommended to design a program structure as simple as possible, without including any additional features than the ones mentioned above. The goal is to create a working version of the program, not necessarily fully stable or error-free, on which testing techniques will subsequently be applied.
• Throughout the project phases it is also necessary to sketch the documentation, which will be written and delivered in the final phase.

  Deadlines

• Set up the teams (3-4 persons): April 19
• Finalize program development: April 27-29

  Phase 2 - unit testing

  Specifications

• Use of unit testing tools to test the code developed during phase 1.
• Reminder: unit testing is about discovering if the module being tested can handle incorrect input data (provided by other modules or by application I/O). Error fixing is NOT required.
• Testing must provide code coverage as complete as possible. For indications regarding the conditions to be tested, read the courses.
• Each module must be tested independently. For simulating the interactions with other modules, where necessary, mocking will be used.

  Deadline

• Finalize the unit testing code: May 11-13

  Phase 3 - use of assertions

  Specifications

• Assertions will be inserted in the application code, in order to check the preconditions, postconditions, and invariants for the operations implemented during phase 1 (see course 7 for details). The assertions are inserted directly into the application code, so this phase has nothing to do with unit testing.
• If the programming used for development has no built-in assertions, a function/method must be written to provide similar behaviour.

  Deadline

• Finalize the assertions code: May 18-20

  Phase 4 - documentation

  Specifications

• Write the documentation for phases 1-3.
• There is no specific requirement for the size of the documentation, but everything that has been done must be described clearly: program design and implementation, a brief user manual, testing, use of assertions.
• The contribution of each team member must be stated explicitly.

  Deadline

• The documentation will be discussed on May 25-27.