This course has already ended.
  1. COMP.CS.140
  2. 13. Project Start
  3. 13.1 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!

Deadlines

  • Final submission: 9.12.2022

  • Grace period ends: 16.12.2022.

    • A grace period starts automatically after the deadline until Friday on the deadline week.

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

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

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

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

  • A project that does no fullfill the minumun requirements can receive a so called boomerang when an extra week is given to fix the project implementation.

Learning outcomes

You practice 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

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

Program use

When starting the program a settings dialog is shown. On the dialog for example the student’s name and student number and possible start year of studies or target graduation year can be given. After providing the needed start information the program moves into the main window of the program where the study program, orientation and possible other needed information is given. The study program and the orientation can be changes in the main window. In addition to the study program selection view the student’s study progress view can be shown. On it the student’s current situation of completed courses is shown. On this view the student can also mark new courses as completed.

Student information is personal data so a JSON file has been defined 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 program UI: How the different functionality is run on the program?

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

  • Showing course information:L 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 simply creates an empty window, has been provided through version control. It is meant for mainly those who plan to achieve grade 1.

Compulsory Features

You must implement at least the listed basic features to get the project work accepted. Moreover, there some optional additional features, and by implementing them 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. 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 45% of the grade.

Minimum requirements (Max Grade 1): maximum of 140 points. The minumum implementation must contain the following features:

  • The program compiles

  • The program contains one dialog window (e.g. the initial dialog)

  • The prorgam uses the course provided UI 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 handling

  • 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 (class diagram is good tool in this)

    • Division of labour in the team.

By implementing intermediate and additional requirements and other merits of the project more project points can be collected.

Intermediate requirements (Max Grade 3): at minimum 300 points

  • A graphical user interface has been fully implemented by the team (the simple readily provided JavaFX project is not used)

  • The program gets the degree structures from the Sisu API and utilizes the provided interface in implementing the API handling

    • Sisu API is described further below.

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

  • The program handles errors in file handling.

  • Unit tests have been implemented for the program

  • Bonuspoints can compensate up to one grade’s worth of mistakes.

Top-grade requirements (Max Grade 5): at minimun 500 points

  • At least two additional features have been implemented (one additional feature is worth 50-100 points)

  • Bonuspoints can compensate up to one grade’s worth of mistakes.

Additional Features

The features listed below do not need to be implemented but a good implementation is worth an increase in the gradfe. Each additional feature is worth 50-100 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 assesment items as part of the program

  • Unit tests have been implemented for the graphical user interface (see 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! Additional features must clearly require coding.

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

Grade Calculation

Grading will consist of smaller sections and bonus-points. Final grade is limited by requirements specified in previous subsection After meeting intermediate requirements, bonus points can compensate 1 grade. After implementing 2 additional features, bonus points can give 2 extra grades.

Graded sections:

  • Overall design and structure

  • Class design and implementation

    • Proper principles in object-oriented programming

    • Class documentation

  • Exception handling

    • Proper usage and handling of exceptions

  • Code quality

    • Following good programming principles.

    • Style

  • Version history & Teamwork

  • Bonus points

    • Awared from additional features and features implemented especially well

Extra work qualified for bonus points:

  • Additional (well implemented) unittests (150p in total)

  • Nice graphics (max 100 points)

  • A very good GUI (max 100 points)

  • Well documented interfaces and classes (max 50p)

Environment

The working environment is provided in Course-Gitlab. Each team has a repository named based on the name of the team. It is worth to note that some team names were adjusted to match suitable names for a GitLab project. The simple ready JavaFX project and some JSON files containing Sisu data are provided through version control. Set group_template_project as a remote to your local repository to fetch course side changes. 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.

Using Sisu API

Sisu allows to access its data via internet e.g. by using the so-called Kori API. A fairly technical documentation of the Kori API is available on the page https://sis-tuni.funidata.fi/kori/swagger-ui/index.html?configUrl=/kori/v3/api-docs/swagger-config&filter=true. 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 e.g. 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 kind of type hierarchy for describing degree structures:

  • An abstract supertype Module.

  • DegreeProgramme.

    • The root level of a degree structure. Describes e.g. 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 e.g. study credits, grading and responsible persons.

  • 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.

    • Describes a course: e.g. the code, name, awarded study credits, course description, and so on.

    • Note that Sisu does not treat this as a subtybe of Module. Sisu offers separate API endpoints for retrieving information about courses (e.g. by their id’s or groupId’s).

    • Detailed information about a course with a certain groupId (e.g. here the groupId is “uta-ykoodi-47926”) can be retrieved by the following kind of a request: https://sis-tuni.funidata.fi/kori/api/course-units/by-group-id?groupId=uta-ykoodi-47926&universityId=tuni-university-root-id

    • Modules that directly contain courses refer to courses by their groupId’s.

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 (= children in the tree structure). A degree structure can thus be traversed / processed by starting from its root level, that is, its DegreeProgramme module, and then inspecting in recirsive manner the submodules described by each module’s rule attribute. Each concrete rule mentions a type: e.g. CourseUnitRule and ModuleRule 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 earlier mentioned Sisu Kori API documentation https://sis-tuni.funidata.fi/kori/swagger-ui/index.html?configUrl=/kori/v3/api-docs/swagger-config&filter=true contains technical descriptions of these above described types.

Posting submission...