A student information system, followed from mark to transcript

How a mark becomes a result

A lecturer enters marks for a class. Those marks are provisional: an exam board still has to look at them, and it can scale a paper that turned out too hard or correct an error. Once the board approves, the marks become final grades and students are told. A transcript, later, is built only from final grades. That is three processes with two different kinds of data passing through the same store, which is exactly what a data flow diagram shows well.

Read the flows into and out of D1 and the control is visible without a word of explanation. Process 1.0 writes only provisional marks. Process 2.0 is the only one that writes final grades, and it cannot run without the exam board's approval flowing in. From D1, process 3.0 reads final grades and nothing else (the student's name and address come from D2), so an unapproved mark can never reach a transcript. A DFD in which the lecturer's marks flow straight to the student has lost that control, and a marker will notice. Process 4.0 sits outside the results story but keeps the diagram honest: admitting a student is what writes the record in D2 that the transcript reads, and without it D2 would be a store that is read but never written.

The data: module, offering and enrolment

The pattern that runs through this whole series appears again. A module (the syllabus, its code and its credits) is not the same as an offering of it (this spring's run, taught by one lecturer, with thirty places). Students enrol on offerings, not modules, because that is where the term, the teacher and the capacity live.

The enrolment is the meeting of a student and an offering, and it is where the mark and the grade belong. A grade is not a fact about a student, who has many, nor about a module, which many students take: it is a fact about one student on one offering.

Prerequisites are a relationship between a module and other modules, many-to-many in both directions: Databases 2 may need Databases 1 and Programming 1, and Databases 1 may be needed by several later modules. Resolved, that becomes a Prerequisite entity whose two keys both point at Module, and the two relationship lines between them carry different names so the direction is clear. Both keys make up the prerequisite's own key, so both lines are solid, identifying relationships, as are the two into Enrolment, whose key is the student and the offering. The other lines are dashed, because Student and Offering have keys of their own.

Classes: where the checks live

The class diagram gives each rule a single home. Student.hasPassed(module) looks through the student's final enrolments. Offering.placesLeft() counts enrolments against capacity. Enrolment.makeFinal() is the one method that turns a provisional mark into a final one, which is how the exam board's control in the DFD becomes code.

In UML, Enrolment could be drawn as an association class, a class hanging by a dashed line from the association between Student and Offering. Mermaid, and many courses' marking schemes, prefer it as an ordinary class linked to both, which is what is drawn here; it means the same thing, and it is easier to add behaviour to.

Registering for a module

Registration makes two checks in a fixed order, and the sequence diagram is where the order is decided. The prerequisite check comes first, because there is no point taking a place for a student who is not allowed it. Only then does the portal ask the offering for a place, and the answer can still be no.

The prerequisite check asks Enrolments for final grades, not provisional marks. A student whose Databases 1 exam has been marked but not yet approved has not passed it yet, and the diagram states that as plainly as the DFD did.

Use cases: four roles, one exception

The use cases sort neatly by role, which is a sign the roles are right: students register and see results, lecturers enter marks and see class lists, the registrar sets up each term, and the exam board approves. The one relationship worth discussing is the exception.

Registering always includes the prerequisite check. Occasionally the registrar waives a prerequisite for one student, a transfer student whose earlier study covered it, for instance. That is an «extend»: it attaches to the check at one point and only under a condition. Modelling the waiver as a separate route around the check would say registration sometimes skips checking, which is not what happens.

Common mistakes

1. A grade column on Student or on Module. Neither can hold one grade per student per module.
2. Module and offering as one entity, so capacity, term and lecturer cannot change from year to year.
3. Prerequisites as a text column ("DB1, PROG1") that no query can check.
4. Student and Module joined directly as many-to-many, with the enrolment's own data left homeless.
5. No difference between provisional and final marks, so the approval step cannot be shown or enforced.
6. A lecturer publishing results directly in the DFD, bypassing the board.

A school rather than a college will call these things classes, subjects and reports, and may have no prerequisites at all. The structure survives the renaming; the prerequisite entity simply goes.