The project is done is groups of 2-3 students.
The input of each member of the group must be visible in the program!
Final submission: 2.5.2022
Grace period ends: 6.5.2022.
A grace period starts automatically after the deadline until Friday on the deadline week.
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.
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.
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
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.
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:
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.
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
The program is able to show the selected study program structure in the main window
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
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 (see the TestFX framework for testing JavaFX programs).
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)
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
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
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.
Overall design and structure
Class design and implementation
Proper principles in object-oriented programming
Proper usage and handling of exceptions
Following good programming principles.
Version history & Teamwork
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)
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.
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
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
Sisu uses the following kind of type hierarchy for describing degree structures:
An abstract supertype Module.
Has concrete subtypes Education, DegreeProgramme, StudyModule and
GroupingModule that describe parts of educations and degrees.
The coursework will not need to use Education modules, so we will not describe it
Sisu API offers endpoints for retrieving modules e.g. based on their id’s or groupId’s.
Detailed information about a module with a given id (e.g. here the id` is
“otm-1d25ee85-df98-4c03-b4ff-6cad7b09618b”) can be retrieved by the following kind of a request:
Detailed information about a module with a given groupId (e.g. here the groupId is
“uta-ok-ykoodi-41176”) can be retrieved by the following kind of a request:
Sisu return module information in JSON format, and each module has an attribute type that
specifies the concrete type of the module (one of the subtypes listed above).
The root level of a degree structure. Describes e.g. the name and extent (study credits) of
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.
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.
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:
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
contains technical descriptions of these above described types.