“OPUS-College”: an Academic Registration and Information

System

Introduction

“Opus-College” is the name of a web-based information system for the registration and

consultation of information on:

- Students (personal data, study plan, previous educational career, absence registration, etc..)

- Courses (structure and content: grade, study year, subjects, exams, tests...)

- Teachers (staff members involved in the academic education process)

- Organisational units (faculties, departments, laboratories, institutes, ...)

So the system concerns the “Higher Education Business Domain” and as such is based on:

- A conceptual domain analysis of the HE business domain structure.

- A use case analysis of the HE business domain processes.

OPUS-College is a very detailed system, which the following pages will amply illustrate.

Technically speaking the system is based on and built with open source software tools, notably:

- JAVA and the JAVA Spring Development Framework for the application

- Ibatis for the persistence (communication of the application with the database)

- PostgreSQL as the database

- A web browser as the user interface. Being a web-based application, the browser is all a user

needs to work with the system, both for the registration, update and consultation of information

and the functional management of the system.

The system has a fully modular architecture based on the revolutionary OSGI-modular framework,

fastly becoming the international standard for service oriented modularisation of JAVA applications,

allowing a.o.t. the plug-in of additional modules at runtime, i.e. without having to stop the system!

Just like you plug in and plug out a USB-stick in/out a PC.

In the following paragraphs a detailed overview of the system will be given from:

- The usage (user) perspective.

- The analysis perspective.

- The technical perspective.

The system is developed by the Radboud University Nijmegen as part of a NUFFIC NPT-project,

lead by the University of Groningen, called: “ICT Capacity Building in Institutions of Higher

Learning in Mozambique”. So the development started as a Mozambican project, which explains

why the system, apart from an English version, is also available in Portuguese.

To start a few words will be spent on the name of the system, to make things clear and rule out

any confusion concerning names used for the system.

For all documentation, latest news and a fully-fledged up-to-date demo version of the system,

please visit the website: http://www.opus-college.net/

1. OPUS-College or eSURA: what’s in a name?

The general or generic name of the system is “OPUS-College”, where OPUS stands for “Open

University Systems”, indicating the open source character of the system. The Mozambican or

Portuguese instance or implementation of the system is called “eSURA”, which in Portuguese

means: (electronic) system for academic registration.

So it is possible that you will see and hear the 2 names being used, OPUS-College as well as

eSURA. We will here consequently use the name OPUS-College or the abbreviated “OPUS” to

indicate the system, since this is the general – English - name of the system. But when “eSURA” is

used, be sure that it concerns the same system, but in this case the Portuguese version.

As did the Mozambicans, every country can choose its own instance name of the OPUS-College

system, or keep the generic “OPUS-College” name.

ATTENTION: the screen images used in this brochure are taken from the Mozambican

implementation and so have the logo “eSURA”.

2. OPUS-College: the user perspective.

In this paragraph we will deal with the most important aspect of the system, notably the

functionality or, in other words: the activities and goals the system was meant for. We will do this

by going through the system and its functions as it presents itself to the user. We will do this by

using concrete screen images of the system, taken from the public demo version at the web site,

which at the time of writing of this brochure was version 3.0, available as per 1st of August 2009.

2.1. Possible users of OPUS-College.

a. Academic Registry personnel: to register students, and linked information, possibly also

information on the organisational units and their studies (depending whether this is centrally

organised in the university); further: to produce student cards, diploma‟s etc... out of the system

(if this is centrally organised).

b. Branch, Faculty or Department administrations: to register information about their staff

members, studies and subjects teached and to consult information on their staff and students (if

this is decentrally organised in the university), to produce student cards, diploma‟s etc... out of the

system (if decentrally organised).

c. Teachers: to enter information about the subjects they teach, the exam results they supervise,

and possibly their personal data (depending on what the university policy is on what teachers may

enter in the system) and to consult information on their students, subjects and exams they

supervise.

d. Students: to consult information on their study plan, the subjects they (have to) follow, their

exam results, etc...

2.2. Global description of the functions in OPUS-College.

a. Registration and update functions: full functionality for the registration and update of

information on the 4 basic entities in OPUS-College: students, courses, teachers and organisational

units. These functions are bundled in the “kernel” or core module of the system, which is the same

for all institutions using the system.

b. Consult and report functions: to produce all kinds of output from the system, ranging from lists

on screen to printed student cards and diploma‟s, overviews of students per study-year, per

subject, with or without their marks for the subject, etc.. For the output of lists and documents

(e.g. student cards, diploma‟s), a special “Reports” module has been developed. This module can

be adjusted to the specific needs of a university.

c. System administration functions: special functions for the functional administrators of the

system by means, allowing to “tune” the system to the local situation, e.g.: defining the list of

academic fields present in their institution, the list of provinces in the country, the type of

addresses allowed in the system (e.g. home, work, other), etc... Also these functions allow the

administrators to adjust the layout of certain reports in the “Reports” module, e.g. the headers and

logo on a student card.

e. Additional modules: given the modular structure of OPUS-College, any specific module wanted

by a university or within a country, can be added to the system without interfering with the generic

“kernel”. At this moment a “Scholarhsip” and a “Fees” module have been added for the

Mozambican situation.

2.3. OPUS-College in detail.

After login in the system, the main screen appears (taken from the Mozambican “eSURA”

implementation of OPUS-College, English version of eSURA):

FIGURE 1: The opening screen of OPUS-College (eSURA implementation)

2.3.1. Functions of the core or kernel module.

As indicated by the menu the core module holds functions for the registration and updating of

information on:

- Organisational units

- Staff members (teachers)

- Studies (structure of a study)

- Subjects (content of a subject, belonging to a study)

- Student (individual and group registration)

- Exams (registration of exam and test results per individual student or for a group of students

per subject).

Each menu-item of the kernel has an “overview” and an “add” function, as shown in the image

below where the menus of the kernel are pulled down. “Institutions”, “students” and “exams” have

further submenu divisions.

FIGURE 2: Menus of the kernel module pulled down.

EXAMPLES 1: THE SCREENS FOR REGISTERING A STUDENT (individually).

When you click on the “overview” function, the information already registered in OPUS is shown,

for instance, clicking on the “overview” for students give a screen like the one below:

FIGURE 3: overview of students( in this example: for the selection “Faculty of Social Sciences” and

the study “Sociology”).

Clicking on the function “add” of the kernel menus, opens the registration screen to add new

information. For instance, clicking on the “add” function for the “student” menu gives the following

registration screen:

FIGURE 4: Opening screen for entering students: “personal data”

When registering a new student, first some personal data have to be entered. After filling in this

screen, other screens to fill more information on the student become available:

FIGURE 5: The student registration screen after the first initial screen has been filled, showing the

links to other screens for the registration of more information on the student.

From the screen above it becomes clear that a lot of information on a student can be registered in

OPUS-College. Let‟s take a look at the various screens indicated above:

FIGURE 6: The student “background” screen.

FIGURE 7: The student “identification” (document) screen.

FIGURE 8: The student “miscellaneous” screen.

FIGURE 9: The student “photograph” screen.

FIGURE 10: The student “remarks” screen.

FIGURE 11: The screen with info on the student’s family.

FIGURE 11: The “opususer data” screen with the user login and password of the student to access

the OPUS College system.

FIGURE 12: “subscription data” screen nr. 1: general info on the studyplan of a student, with links

to further detailed information on the studyplan as well as info on the educational career (previous

institution) of the student.

FIGURE 13: details on the studyplan of the student. (Note that for 2010 the student has planned

an extra subject “Theories of Management” in addition to the regular 3rd year of the bachelor.)

FIGURE 14: information about the previous institution the student has attended, in this (as in

most) case it’s her secondary school college. Note also that a copy of the diploma of the secondary

school has been uploaded and is now available as an electronic document (PDF) in the system.

FIGURE 15: screen for registering information on the absence of students.

EXAMPLE 2: THE SCREEN FOR MASS OR GROUP ENROLLMENT (MATRICULATION) OF

STUDENTS.

The screen examples above illustrated the various screens or steps for registering an individual

student. To speed things up and make life of the Academic Registry personnel a bit more pleasant,

OPUS-College also has a function for group or mass registration of students, which allows fast

registration of students for a given study year of a study in a given academic year. The image

below shows the screen in question.

In this example a screen is shown which allows rapid registration of a group of students for the

first study year of the bachelor of the study “Mathematics” for the academic year 2009. All the

people from the Registry have to do is for each student fill in the fields in the lower part of the

screen. Only the surname, first names, gender and birth date are compulsary data.

FIGURE 16: Screen for fast (mass) input of a group of students. After filling in a student’s data,

this one is automatically added to the list and the fields of the lower part of the screen become

empty again to add the next student. The upper part of the screen remains the same. For each

student registered, automatically a correct study plan is created “in the background” by the

system.

EXAMPLE 3: THE SCREEN FOR MASS OR GROUP SUBSCRIPTION OF STUDENTS TO THE

NEXT YEAR OF STUDY.

Every year the students already studying at the institution have to subscribe for the next year of

their study. To facilitate this OPUS-College also has a “mass subscription to the next year”

function, analoguous to the mass matriculation function described in the previous page. The screen

to do this is the following:

FIGURE

17: Screen for the mass transfer (subscription) of students from one study year to the next study

year. Shown is the list of students in the 1st year of the bachelor of Sociology for the year 2008

(see selection criteria on top of the screen). By means of the selection in the middle of the screen,

these students can in one move all be subscribed to the 2nd year of the bachelor study.

EXAMPLES 4: THE SCREENS FOR THE REGISTRATION OF A COURSE (STRUCTURE and

CONTENT).

In this brochure we will not show all of the registration functions available in OPUS-College, so we

will not go into the registration of organisational units of staff members (this is more or less

analoguous to registering the personal data of the students), but we will still show one part of the

system, which – apart from the student registration – deals with key information when it comes to

an academic registration and information system, notably: the structure and content of the

courses.

Registration of courses in OPUS-College, involves the following steps:

- Registration of basic descriptive information of the course as such.

- Registration of the various grades of the course.

- Registration of information on the various study years of each grade.

- Registration of information on the subjects constituting a study year.

Step 1: registering basic information on the course as such

The following screen shows the data elements registered in OPUS-College on the course level

(ATTENTION: in the English version of eSURA the word “study” is used to denote a course).

FIGURE 18: Screen for entering basic information on a course.

Step 2: registering information on the grades of the course (bachelor, master..)

FIGURE 19: Screen for registering a grade for a course.

Step 3: registering information on the study years of a grade.

FIGURE

20: Screen for registering info on a study year of a grade (Note: the subjects constituting the year

are registered by means of the subject screens, see below).

Step 4: registering the subjects (constituting a study year).

The actual details about the content of a course are registered in OPUS-College by means of the

“subject” function. Given the fact that a lot of information can be stored for a subject, this process

also is divided in various stes, notably:

- Registering basic information on the subject

- Describing the content (summary) of the subject (by means of an editable text field).

- Registering the teachers of the subject.

- Linking a subject to a grade and a study year.

- Indicating the didactical forms or methodology used in the subject.

- Registering the examination structure of the subject: exams of the subjects and possibly

underlying tests (up to 3 levels deep)

Now let‟s take a closer look at these various steps by means of the screens in question.

Step 1: basic information on the subject:

FIGURE 21: Screen for registering basic information on a subject.

Step 2: describing the actual content of the subject:

FIGURE 22: Screen for describing the content of the subject (editable text field).

Step 3: registering the teachers:

FIGURE 23: Screen for registering the teachers of a subject.

Step 4: linking a subject to a grade and a study year.

FIGURE 23: Screen for linking a subject to a study year of a grade.

Step 5: indicating the didactical forms (methodology) of a subject:

FIGURE 24: Screen for registering the didactical forms of a subject (in this case 2 forms are used:

“lecture” and (study of) “literature”).

Step 6: registering the examination structure.

In eSURA an exam/test-structure of 3 level deeps can be registered. For instance: a subject which

has an exam consisting of 2 parts (e.g. an oral and a written exam) with a different weight (e.g.

the oral counts for 60% and the written part for 40%) and on top of the oral part of the exam in its

turn consists of 2 monthly tests by means of a presentation by the student and a final oral exam

session with the teacher). The screens below show how this can be registered in OPUS-College.

FIGURE 25: Screen for registering (parts of) an exam of a subject.

FIGURE 26: Screen for entering details of the exam, including (possibly) underlying constituting

tests. Here the exam itself is constituted of 3 parts: 2 monthly tests counting each for 25% and a

final oral exam, counting for 50%.

FUNCTIONS FOR THE (FUNCTIONAL) ADMINISTRATORS OF OPUS-COLLEGE

In Opus-College there are currently 2 administrator functions:

- Defining the content of the so-called lookup tables, holding all kinds of standardised

semantic (meta)data use in the system. Examples are: the list of academic fields used by

the insitution, list of possible provinces or regions of origin of students, distinctions in study

forms (e.g. regular learning, e-learning), in study time (e.g. daytime, nighttime, both),

possible contract types of staff members, etc.. It should be clear that such lists will differ

between countries and possibly some of them between universities in the same country.

- Defining and changing lay-out elements of the reports used in the “Reports” module. For

instance: one of the reports is the student card; the administrator can change the front and

back logo as well as the title of the student card.

Editing the lookup tables.

This function is accessed by the menu entry “admin” on the kernel bar:

FIGURE 27: Starting up the administrator function “lookup tables”

Once “overview” is clicked on, the list with lookup tables in the system appears:

FIGURE 28: Screen showing the list of available lookup tables in OPUS-College.

Clicking on the title of a lookup table will open the current content of the lookup table:

FIGURE 29: Screen showing the content of a lookup table (here the table “Academic Fields). The

entries in the lookup table can be deleted or edited (by clicking on the edit icon or the description

itself).

IMPORTANT TO NOTICE: the table above shows a “language” field. By choosing another of the

available languages (currently English, Portuguese and Dutch. French and Spanish under way), the

table content will immediately be displayed in that language.

Editing layout elements of reports.

This function is equally accessed by the menu entry “admin” on the kernel bar:

FIGURE 30: Starting up the administrator function “reports”

A list of editable reports is shown:

FIGURE 31: List of currently editable reports in OPUS-College.

Clicking on the name of a report shows the lay-out elements which can be edited. For instance

clicking on the report “student card” shows the following screen:

FIGURE 34: Editable elements on the student cards: front logo, background image and title.

2.3.2. Aditional Modules: the Reports Module.

Apart from the kernel, which holds the generic registration and update functions, applicable to all

institutions of higher learning, OPUS-College also allows to extend the system with additional

modules, containing specific functionality for a given country or insitution.

For instance: it may be clear that the (desired) structure and layout of output generated from the

system will be different from institution to institution. A good example for instance is the layout of

the diploma‟s: headers and texts as well logo‟s used will be particular for each institution. Also the

lists of reports and overviews wanted from the system may differ significantly: a list considered

important by one institution may be of less relevance to another, depending for instance on the

management style and processes in the institution.

Trying to integrate all these different wishes and lay-out styles into the core or kernel of the

system is – for obvious reasons – as impossible as it should be avoided, since the system may end

up with tens if not hundred of different output functions in its core which would not only make the

core hopelessly complex and heavy, but would also frustrate and irritate a user, being confronted

continuously with “dead weight” functions only relevant to other(s) institutions.

That is why the designers of OPUS-College have decided to put all output functions of the system

into a separate plug-in module, called “Reports” which does not interfere with the kernel and which

can be tailored to the specific needs and requirements of and by any institution. In other words:

the Reports module may look very different from one institution to another, while the kernel of

OPUS-College will still be the same.

The Reports module, as all additional modules available in Opus-College, are listed in a menu

above the kernel functions:

FIGURE 35: Position of the additional modules on the OPUS-College menu.

At the moment of this writing, the Reports module contains the following forms of output, all

concerning students:

FIGURE 36: Forms of output currently available through the “Reports” module.

When clicking on the name of a report, a selection screen appears which allows to specify the

selection of students for which a report is wanted. We will illustrate this for the “student card”

report:

FIGURE 37: The selection screen for the report “Student Card”. In this example only the “Faculty of

Social Sciences” is given as a selection criteria, so all students of that faculty are shown in the list.

Clicking on the “Create report” button will produce student cards for all the students of that faculty.

In the image below the various parts of this selection screen are explained:

FIGURE 38: The selection screen for the report “Student Card” with multiple selection criteria filled

in. In this example the system will generate students cards in a PDF file for all students who in the

acaemic year 2008 were in the first year Bachelor of the study Sociology from the Faculty of Social

Sciences (demo data, normally of course the list will contain more students).

The following screen shot shows the output of the student cards in the PDF-file:

FIGURE 39: Example of student cards as output from OPUS-College. Here: the lay-out of the

student cards of one of the Mozambican universities is presented.

The same principle of selection applies to all reports currently in the Reports module. Below we just

show another example, this time the report which contains a list of students for a given study per

study year.

FIGURE 40: OPUS-College output example. List of students of the first year of the Bachelor

Socioloy in the years 2007, 2008 and 2009 respectively.

Another example of output by means of the Report module is shown in the image below. This time

it is a list of students per subject, with their marks for that subject.

FIGURE 41: OPUS-College output example List of students per subject with their marks for that

subject (note that some students still have to take the exam for the subjects).

Finally a last example showing a list of students with for each student all the subjects passed and

their marks for the subjects.

FIGURE 42: OPUS-College output example. List of subjects passed per student with their marks

for each subject.

2.3.3. Aditional Modules: the Scholarship and Fees Module.

Apart from the Reports module OPUS-College currently contains 2 other additional modules,

specifically tailored to the Mozambican situation: the Scholarship module allowing to register

information on the possible student scholarships existing in Mozambique and the Fees module

which is a simple module to keep track of the student fees payments, again according to the

Mozambican situation. We do not go into detail in these modules, given their specific character,

and just give a few screen shots:

FIGURE 42: Screenshot from (part of) Scholarship module, showing the type of scholarship

granted to the student, the decision on which the scholarship was granted, the period for the

scholarship and a sent in complaint by the student concerning the payment of the scholarship (for

the handling of complaints a separate screen is available in the scholarship module).

The following shows a screen from the Fees module:

FIGURE 43: Screenshot from (part of) Fees module, showing the amount of the fees already paid

by a student on a given date, the total fees due, the deadline for payment and the amount still to

pay.

3. OPUS-College: the underlying domain analysis.

Opus-College is based on an analysis of both the structure and the processes of the Higher

Education Business Domain, more notably. Below we give a brief impression of these analyses.

3.1. Business domain structure.

This paragraph contains a conceptual domain analysis of the HE-business domain, in other words:

an overview of the core entities and their specific aspects and structure when looked upon from an

OPUS-College point of view.

More specifically we will show the main entity-diagram of the business domain OPUS-College

applies to, and the worked-out taxonomies of these main entities. Finally we present the full list of

entities and attributes dealt with in OPUS-College.

These presentations will give insight in the material object of OPUS-College, i.e. the domain the

system covers.

For a more complete analysis, consult the following document at the web site:

http://www.opuscollege.net/docs/Conceptual_Domain.doc

FIGURE 44: Core entities of OPUS-College with their relations.

FIGURE 45: Taxonomy diagram of the core entity “Person”, including students, academic staff

members and administrative personnel.

FIGURE 46: Taxonomy diagram of the core entity “Organisational Unit”.

FIGURE 46: Taxonomy diagram of the core entity “Course”.

FIGURE 47: Taxonomy diagram of the core entity “Subject”.

FIGURE 48: Subject exam structure model used in OPUS-College, up to 3 levels deep for a subject.

OVERVIEW OF ENTITIES AND ATTRIBUTES IN OPUS-COLLEGE (CORE or KERNEL)

1. Entity Person and its sub-entities

Common for all “Persons”

- Full surname of the person - Alias surname of the person - Full first names of the person - Alias first names (initials) of the person - national registration number (NUIT) - Photograph - Civil title (mr. mrs., etc…) - Academic title - Gender (M,F,X) - Birth date - Nationality (default local countr) - Place of birth (City) - District of birth - Province of birth - Country of birth - Place of origin - Administrative post of origin - district of origin - province of origin - Country of origin (before coming to the university) - Nationality - Civil status - Housing on campus (y/n)

IDENTIFICATION:

- Type of identification document (passport, etc…) - Number of id. document - Date of issue id. Document

- Place of issue - Date of expiration of id. Document

- Profession (..,..) - Second language - Mastering level second language (fluent, basic, poor) - Third language - Mastering level third language (fluent, basic, poor) - Contact person emergencies name - Contact person emergencies address (see below) - blood type - health issues (txt) - Home ADDRESS (see ADDRESS)

- Date the person was registered in the system ADDRESS INFORMATION: - Street + number - Number extension - Zip code - City - Administrative post - District - province - Country - Telephone number - Mobile phone number - Fax number (only for org. unit address) - E-mail

Specific for “Students” - Student ID (to be generated by the system – including

university ID and branch ID - or provided by administration) - Date of enrolment - Status (active, temporary inactive, stopped without

diploma,graduated) - startdate of temporary inactivity - enddate of temporary inactivity - reason for absence

Previous institution:

- Id. Nr. of previous institution - Name of previous institution where diploma was obtained. - City where the previous institution is located. - Province where the previous institution is located - Country where the previous institution is located. - Type of previous institution (secondary school, university,

etc.) -> lookuptable education - Field of education of previous institution (general,

agricultural, technical, pedagogical, etc.) - Final grade type of previous institution – if university

(bachelor, master, etc.) - Final mark obtained from previous institution - Photograph of diploma (SE)

- Scholarship (y/n) - Full Name of father - Education of father - Profession of father - Full name of mother - Education of mother - Profession of mother - Full name financial guardian (if other than parents) - Relation financial guardian with student (brother, aunt,

etc…) - Profession financial guardian (…,…) - Address financial guardian (see ADDRESS) - Study ADDRESS (see ADDRESS)

Specific for “Staff Members”

- Staff ID (to be generated by the system – including university ID and branch ID - or provided by administration)

- Date of appointment - Type of staff (administrative, academic) - Academic/educational grade - Primary unit of appointment

Contract information local universities (multiple entries

possible):

- type (partial / full time) - startdate of contract - enddate of contract - contact hours (only for partial contract type) - F.t.e. appointment overall - F.t.e. for education - F.t.e. for research - F.t.e. for administrative tasks (incl. management) - Function (e.g. director, professor, registrar, lecturer,

assistant-professor, etc…- multiple entries possible) - Type of appointment (tenured or associate) - Function level (management, normal employee)

2. Entity Study and its sub-entities

Data on a “Course”

- Name of study - Organizational unit which owns the study - Academic Field (Law, Mathematics, etc..) - Date of establishment - Formal address for communication (see ADDRESS) - Date the study was registered in the system

Data on a “Grade of a course”

- Study ID - Indication of grade (Bachelor, Masters, Licentiate, Ph. D.) - Number of years - Name contact person (see entity “person”)

Data on a “Study year of a grade”

- (name of) study_grade_type the year belongs to - Form of study (regular/distant learning/semi-regular) - Time of day study is organized (daytime / evening) - Indication number of study year (1

st, 2

nd, etc…)

- BR for Maximum contact hours for this year - Academic year from which on the course structure of the

study year is valid (e.g. 2001) - Academic year until which the course structure of the study

year is valid (e.g. 2005 or when blank meaning: not yet known)

- Overall amount of credits to be earned (e.g. 42 credit points)

- Amount (%, total number of credits) of compulsory courses - Amount (%), number of cr.) of compulsory from list courses - Amount (%, number of cr.) of free choice space BR stating the rules for passing the study year, including

final mark explanation (e.g. AA = + 90% of the credits, A = +

80% of credits, etc…)

Data on a “Subject”

- Name of subject - Subject code

- Study year ID (if part of study year program. If not, then it is thematic)

- subject block ID (if part of a block) - Indication of grade (Bachelor, Masters, Licentiate, Ph. D.)

(if part of thematics program) - Indication of time_unit (semester 1, trimester2, etc.) - Indication of rigidity(freedom of choice, compulsory,

compulsory from list ) - Indication of importance (major or minor, only when subject

is in a study year) - Indication whether subject is offered as “free choice”

subject for students of other studies (y/n) - (name(s)) of professor(s)/teacher(s) - Credits/burden (study points, hours) - % (credits/burden) of theory - % (credits/burden) of practice - Frequency (every year, every 2 years) - Content description of course - (name of) Responsible organizational unit - Type (lecture, workshop etc.. - multiple entries possible)

- Type of exam (multiple or single event) - Type of examination (oral, written, paper, etc… - multiple

entries possible) - Target group (all students, students from study, all

international students, all national students etc…). - Maximum participants - Target group - BR’s stating the rules for passing the subject , including

the algorithm (calculation method) applied in case of multiple event exams. -> see notes Markus

- BR’s applying to the subject (e.g. whjch subjects proceed the actual one or which knowledge, experience etc… is supposed)

- BR’s concerning exemptions - Date the subject was registered in the system

Data on a “Test or Exam”

- Subject the test/exam applies to - Date of the test/exam - Type of test/exam (partial, final, part of normtest/exam-

cluster, etc..) - Minimum score - Maximum score - Pass Norm (minimum score to pass the test/exam) - Amount of retries - Calculated weighing factor for this test/exam in the total

subject result BR’s normtest/exams

Data on a “Study Plan”

- Name of the study plan - Student ID - Study ID - Grade type of study (bachelor, master,licenciate,Ph.D.) - Type of student (regular/distant learning/semi-regular) Study time (daytime/evening)

3. Entity Organisational Unit

Data on the “Institution” as a whole

- University ID (to be generated by the system or provided by administration) - Name of the university - Date the university was registered in the system

Data on the “Branch” of an institution (e.g. branches in different towns) - BRANCH-ID (to be generated by the system or provided by administration) - Name of the branch - University ID - Date the branch was registered in the system

Data on the “Faculties, Departments, Laboratories, Institutes,...” of an institution - Name of the unit - Branch ID - Organizational level of the unit (1, 2, 3) - Area of the unit (academic, administrative) - Type of unit (faculty, department, institute,….) - Academic field of unit (in case of academic org_unit) - Director (full name) - Formal address for communication (see address)

- Date the unit was registered in the system

3.2. HE Busines Process analysis.

Apart from the domain structure analysis, presented in paragraph 3.1. above, OPUS-College is also

based on an analysis of the Business Processes in the Higher Education Domain.

For this analysis the “use case” approach was used, as implemented in the UML modeling

framework. Below we limit ourselves to an illustration of one of the main business processes

included in OPUS-College, notably the initial enrollment of students at the university also known as

the “matriculation process”.

Example of a business process analysis as worked out in OPUS-College.

4. OPUS-College: technical perspective.

4.1. Hard- and software infrastructure.

Prerequisites

While designing OPUS-College two main concerns were to guarantee platform independency and

develop within the Open Source standards. The Open Source standards can be found at the

following web-address: http://www.opensource.org/docs/osd.

The design and architecture of the system therefore has to fit in the demands of these two concerns.

A further concern was to build the system in a generic way. It has to be possible for external

developers (for instance local Mozambican developers) to expand the system. Therefore the system

will have a modular structure. Re-use of components will be encouraged. Examples for these generic

parts of the system are:

guarantee multilingual support through multiple configuration files

The suggested layout for the application was presented in the shape of a prototype (screen-dumps),

that was presented to the Mozambican response-group. Through this prototype the group got an

impression of the look and feel of the application. After feedback from this response-group about

these screens and possible changes in the layout-design, the prototype were built fully functional.

This included coupling to the real business logic and data.

Supported platforms and resources

In acordance with the open source demands the application was built with the following components

(minimum):

Linux server (kernel version 2.6) or Windows 2003 Server

Apache Tomcat webserver (5.5)

PostgreSQL database (8.2)

The application is guaranteed for end-use on the following platforms and browsers (minimum):

Windows XP IE 6.0, Firefox 1.5

Linux (kernel version 2.6) Firefox 1.5

Reasons for choices made

POSTGRESQL

MySQL is expected to be too “small” for this application, therefore PostgreSQL is used. PostgreSQL is

an open source database (like MySQL). PostgreSQL strongly conforms to the ANSI-SQL 92/99

standards. Features of PostgreSQL are:

Multi-Version Concurrency Control (MVCC)

point in time recovery

tablespaces

asynchronous replication

nested transactions (savepoints)

online/hot backups

sophisticated query planner/optimizer

write ahead logging for fault tolerance.

support for international character sets, multibyte character encodings, Unicode

locale-aware for sorting, case-sensitivity, and formatting

highly scalable (data quantity and number of concurrent users)

full support for subqueries (including subselects in the FROM clause), read-committed and

serializable transaction isolation levels

fully relational system catalog

Data integrity features include (compound) primary keys, foreign keys with restricting and

cascading updates/deletes, check constraints, unique constraints, and not null constraints.

auto-increment columns through sequences

LIMIT/OFFSET allowing the return of partial result sets.

support for compound, unique, partial, and functional indexes

table inheritance

a rules system

database events

Used frameworks and techniques

Web View (presentation) HTML, JavaScript, JSTL, EL

Web Flow (navigation) JSP, JSTL, EL, Spring Web MVC

Modularisation: OSGI-framework and Spring Dynamic Modules

Service POJO‟s and JavaBeans (Spring)

Business POJO‟s and JavaBeans (Spring)

Persistence/Data iBatis (Spring)

Database PostgreSQL

Logging Log4J

JSTL = Java Standard Tag Library

EL = Expression Language

The application is set up as a modular system, according to the OSGI Java modular framework and

its implementation tool “Dynamic Modules” of the Spring Source cooperation.

For more information on the OSGI-modular framework, see: http://www.osgi.org/About/Technology

For more details on the Spring Dynamic Modules, see: http://www.springsource.org/osgi

Reasons for choices made

SPRING WEB MVC

The Spring Framework is a lightweight framework, that Works on top of the architecture of J2EE.

Parts of the framework can be implemented, like Web MVC (MVC = Model View Control).

Advantage of the use of Spring Web MVC is the automatic handling of standard functionality (a.o.

validation, error-handling, request-handling). Besides a reduction of programming time there is also

standard formed consistency in the default handling principles.

POJO’S AND JAVA BEANS

J2EE is a very solid framework, which handles cross-cutting concerns like session-handling, security,

transaction management and container-management. Through Aspect Oriented Programming Spring

arranges these cross-cutting concerns easily.

Because our application has no need for remoting and other „heavy‟ requirements (high concurrency,

transactioning, container managed security, need for portability, a-synchronous messaging), there „s

no need to use Enterprise Java Beans. The POJO (Plain Old Java Object) together with JavaBeans

will suffice.

IBATIS

We were building a new database, based on the object-model for the application. To manipulate the

data we used iBatis. This is a lightweight framework for SQL Object Mapping, which uses JDBC

under the surface (JDBC is the normal JAVA API for manipulation of data). The SQL-queries are

placed in separate XML-files through SqlMaps and compiled run-time. Advantage of the use of this

framework is the isolation of SQL-statements without having to use a whole new approach to data-

access (like for instance Hibernate).

OSGI-modular framework

The OSGI-framework is becoming the defacto international standard for modularisation of JAVA

applications. It provides so to speek a complete Service Oriented Architecture (SOA) within the JAVA

programming environment. OSGI is a module system for Java that implements a complete and

dynamic component model, something that does not exist in standalone Java/VM environments.

Applications or components (coming in the form of bundles for deployment) can be remotely

installed, started, stopped, updated and uninstalled without requiring a reboot; management of Java

packages/classes is specified in great detail. Life cycle management is done via APIs which allow for

remote downloading of management policies. The service registry allows bundles to detect the

addition of new services, or the removal of services, and adapt accordingly.

LOG4J

Log4J is a robust and simple way of logging, which is a de facto standard in JAVA-programming.

COS

For file-upload functions we use the (standard) COS-jar. This is an open-source library, with license

conditions for developers. UCI takes these license conditions into account.

ITEXT

For exporting several formats (xml, rtf, etc.) we will use the Itext library.

Tools

Design/Modeling PowerPoint, Visio

Building Eclipse 3.1.2 with WTP and Spring IDE, pgAdmin III

Testing JUnit

4.2. Software Architecture

4.3. Object Model

4.3. Database model