1. Programming 3: Interfaces and Techniques »
  2. Project Start »
  3. Project: Sisu Unraveled

Project: Sisu Unraveled

The project is done is groups of 2–3 students.

The input of each member of the group must be visible in the program!

For those who work alone or are missing a group!

An individual student cannot create a group in Plussa, and, as a result, cannot have the remote group repository that is needed to implement and submit the project work. Please, contact the teachers via email, to get the repository and/or join to a project group: Contact the responsible teachers of the course (jorma.laurikkala@tuni.fi and mika.saari@tuni.fi), if want to work alone. Contact the course staff (prog3@tuni.fi), if you are missing a group. Tell in latter case your target grade to help the staff to find a suitable group for you. Please, note that there are no guarantees that a group will be found. However, working individually is still an option, if a group cannot be found.

Deadlines

  • Final submission: Friday, 28.4.2023, 23:59.

  • Grace period ends: Friday, 5.5.2023, 23:59.

    • A grace period starts automatically after the actual deadline.

    • Any submission during the grace period means that the actual deadline was missed.

    • Even under grace, submit the project as early as possbile as the grading gets tougher over time.

      • The limit to pass (grade 1) does not change.

      • As the grace period starts, limits for other grades are raised by half a grade. For example, right after the actual deadline, a project must gain points worth the grade of 4.5 for the grade of 4, the limit for the grade of 3 is that of 3.5 etc.

      • The limits are raised gradually over the grace period so that by the end of the period the limit for the grade of 4 is the same as the original limit for the grade 5. The other grades scale accordingly.

  • A project that does no fulfill the minumun requirements can receive a so called boomerang. In this case, an extra week is given to fix the project implementation.

Learning Outcomes

You practise the following things:

  • Adding functionality to a program using object oriented design.

  • Using external libraries as a part of the implementation (design by contract).

  • Implementing a GUI as a part of program.

  • Unit testing of your own code.

  • Implementing a program as a team effort.

Implementation

Since Sisu has been causing premature grey hair, you decide to implement a program for handling degree data to get an easy way to keep track of where you are at regarding completing a degree. The program can be used to investigate the degree structures of study programmes of the Tampere University. In addition, the user’s progress over their studies can be viewed. The user can define his or her own study programme and mark courses completed as the studies go forward.

Program Use

A settings dialog is shown, when the program starts. On the dialog, for example, student’s name and student number and possibly start year of studies or target graduation year can be given. After providing the initial information, the program opens the main window, where the study program, orientation and possible other needed information is given. The study program and the orientation can be changed in the main window. In addition to the study program selection, a view of student’s study progress view can be shown. This view shows which courses the student has completed. On this view, the student can also mark new courses as completed.

Since Ssudent information is personal data, a JSON file is used for handling them in the program. The program execution ends by pressing a button on the main window. Student progress is stored into the JSON file at program exit.

Below is a draft of what the UI might look like:

../../_images/gui_luonnos.png

Many details on the program implementation are intentionally left open and they can be implemented as the team sees fit. Such details include:

  • The exact starting point of the program: What is the start state of the program and what information it asks from the user at start?

  • The usr interface: How the different functionality is run on the program?

  • The user’s role in the program: How student progress is shown?

  • Showing course information: What kind of view is used to present course data? What amount of detail the information of one course contains?

A simple JavaFX project, which creates an empty window, has been given in the remote group repository. The project in the Maven form and can be opened with NetBeans without any modifications. This project is meant (as it is) for mainly those who plan to achieve the grade of 1.

Program Features

You must implement at least the minimum requirements to get the project work accepted. Moreover, implementing optional additional requirements and extra-work you can increase your grade. With the minimum implementation you can pass (grade 1). Implementing the requirements set for the intermediate implementation, you can get the grade 3 at maximum. A higher grade requires the implementation of some additional features.

The points collected from the project form a partial grade with grade = points / 100. The project amounts to 35% of the grade.

Minimum Requirements

The grade of 1 at maximum. Maximum of 140 points.

The minumum implementation must contain the following features:

  • The program compiles.

  • The program contains one dialog window such as the initial dialog.

  • The program uses the course provided user interface as its main window.

  • The program gets the structures of the degrees from a defined JSON file and uses the provided interface in implementing the file processing.

  • The program is able to show the selected study program structure in the main window.

  • The program uses inheritance in implementing the study program structure.

  • A final document that contains:

    • Class responsibilities. The UML class diagram is good tool in this.

    • Division of labour in the team.

More project points can be collected by implementing intermediate and additional requirements and by other merits of the project (extra-work).

Intermediate Requirements

The grade of 3 at maximum. At minimum 300 points.

The intermediate implementation meets all the minimum requirements except the reading degree structures from the JSON files. Instead, the program gets the degree structures from the Sisu API and utilises the provided interface in implementing the API handling. Sisu API is described further below.

In addition, the intermediate implementation meets the following requirements:

  • A graphical user interface has been implemented by the team. If the user interface is based on the readily-provided JavaFX project, team’s user interface must be clearly unique, when compared to the provided interface.

  • The program works, that is, the degree shown can be changes and the progress situation of the student’s degree is shown.

  • The program handles errors during the file processing.

  • Unit tests have been implemented for the program.

Extra-points can be collected by implementing additional requirements or by extra-work. One additional requirement is worth 50–100 points. Extra-points can compensate up to one grade’s worth of mistakes.

Top-Grade Requirements

The grade of 5 at maximum. At minimum 500 points.

In addition to the minimum and intermediate requirements:

  • At least two additional requirements have been implemented. One additional requirement is worth 50–100 points.

Points from the additional features can compensate up to one grade’s worth of mistakes. In addition, also extra-work can provide extra-points.

Additional Requirements

The features listed below do not need to be implemented, but a good implementation is worth an increase in the grade. Each additional feature is worth 50–100 extra-points. The effect of a feature can be increased, if it turns out to require more work than expected. In order to get the grade increase, the feature must be documented in the submission. The TAs do not search for additional features from the code.

  • Course view. On hovering the mouse cursor on a course additional information is shown on the course.

  • Student settings. At start of the program a settings window is opened and the student using the program can be set. The situation for the degree is read and stored in a JSON file.

  • Showing the schedule of student progress in respect to the degree structure.

  • Adding a teacher role into the program.

  • Showing some information entity available in the Sisu API such as assessment items as part of the program.

  • Unit tests have been implemented for the graphical user interface. Use the TestFX framework for testing JavaFX programs.

  • Own feature. An additional feature outside this list has been implemented. Note! The feature needs to clearly require coding.

Note! All additional features must clearly require coding.

Note! ALL ADDITIONAL FEATURES MUST BE DOCUMENTED TO GET THE POINTS.

Extra-work

In addition to the additional features, extra-work can provide extra-points:

  • Additional, well implemented unit tests (150 points in total).

  • Nice graphics (maximum 100 points).

  • A very good GUI (maximum 100 points).

  • Well-documented interfaces and classes (maximum 50 points).

Grade Calculation

The grade is determined by the sum of the points of the implementation level (minimum, intermediate or top-grade) and the extra-points from the possible implementation of additional requirements and possible extra-work. Final maximum grade is limited by as described in the previous subsections.

Graded sections:

  • Overall design and structure

  • Class design and implementation:

    • Proper principles in object-oriented programming.

    • Documentation of classes and interfaces.

  • Exception handling:

    • Proper usage and handling of exceptions.

  • Code quality:

    • Following the good programming principles.

    • Style.

  • Version history and teamwork.

  • Extra-points:

    • Awared from additional requirements and extra-work investested to implement features especially well.

Environment

Remote Group Repository

A remote GitLab group repository has been created for each group. The repository can be found at

https://course-gitlab.tuni.fi/compcs140-spring2023/group----,

where ---- is the group id of Plussa. For example, if group’s id is 1234, group’s remote repository is at

https://course-gitlab.tuni.fi/compcs140-spring2023/group1234.

The repository contains a simple JavaFX project and JSON files for Sisu data. The project is in the Maven form and can be opened with the NetBeans IDE. Clone this repository as your local repository.

Set the remote repository of the project material as a remote to your local repository to fetch possible course side changes.

Please, contact the course staff via the course email (prog3@tuni.fi), if your group’s remote repository is missing.

The use of version control is both a graded part of the project and an indication of team work. The remote repository must contain a clear contribution for each member of the team.

Continuous Integration

The root directory of the remote project repository has the .gitlab-ci.yml file that configures how GitLab runs the so called CI/CD pipeline. The pipeline supports the practise of continuous integration by executing tasks defined in .gitlab-ci.yml, when a developer pushes to the remote repository. The file has the pre-defined build task that compiles the project with Maven.

The use of CI/CD pipeline is optional. Rename the .gitlab-ci.yml file or delete it, if you do not want that pushing triggers the compilation. However, please note that CI/CD pipeline is a way to detect broken code that should not be pushed to begin with.

In this task, the group can augment the continuous integration with testing. GitLab has a runner that executes the test task, if the group has defined it in .gitlab-ci.yml by themselves. Please, give the compcs140 tag for this task also. By defining the test task, a group can bolster the testing of their project work, and, possibly gain by this extra-work extra-points.

Using Sisu API

Sisu allows to access its data via Internet by using the Kori API. The API returns data in JSON format.

A helpful starting point is that a list of all degrees offered by our university can be retrieved, for example, by the www request: https://sis-tuni.funidata.fi/kori/api/module-search?curriculumPeriodId=uta-lvv-2021&universityId=tuni-university-root-id&moduleType=DegreeProgramme&limit=1000.

Sisu uses the following hierarchy for describing degree structures:

  • An abstract supertype Module.

  • DegreeProgramme.

    • The root level of a degree structure. Describes, for example, the name and extent (study credits) of the degree.

  • StudyModule.

    • A study module, which usually consists of courses or submodules.

    • Study module completions can be included into a student’s university study record. Study modules have information about study credits, grading, responsible persons etc.

  • GroupingModule.

    • A technical substructure that describes an intermediate level in the degree structure. It usually consists of courses or submodules and is superficially similar to a study module.

    • These differ from study modules mainly in that grouping module completions cannot be recorded into the study record. Hence these do not have information about study credits etc.

  • CourseUnit.

A degree structure consists of a tree-like module hierarchy. Each module, regardless of the module type, contains an attribute rule that describes its submodules, that is, children in the tree structure. A degree structure can thus be traversed by starting from its root level, that is, its DegreeProgramme module and then inspecting in recursive manner the submodules described by each module’s rule attribute. Each concrete rule mentions a type, such as CourseUnitRule or ModuleRule that describe specific courses or modules that are directly under the curtent module. AnyCourseUnitRule and AnyModuleRule are sort of wildcard rules that mean that any courses or modules can be included under the current module.

The bottom part of the Sisu Kori API documentation contains technical descriptions of these types.