Post on 13-Mar-2018
“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