ACADEMIC INFORMATION AND REGISTRATION SYSTEM

OPUS-College

Purpose of this Presentation

1. Part 1:Introduction of OPUS-College, especially to show the professional setup and the scope of the system.

2. Part 2: Discussion about some primary points of interest when it comes to developing software systems for Developing Countries:

Customization

Sustainability

Empowerment (of local people)

Some Primary Points of Interest

Customization Should never be done on the kernel of the system (database, primary logic) Should be done on the User-interface on the one hand and the Reporting (output of

the system) on the other.. AND: Specific requirements should be realized through plug-in modules. Often need to change inefficiënt processes within the university so that the system

fits optimally, instead of adapting the system to the inefficiënt reality.

Sustainability Does not depend so much on local people (with the skills to) building the system. Does heavily depend on the functionality (system does what users want) And also on the availability of a professional (technical and functional) support

organisation.

Empowerment (of local people) Not necessarily the IT-people, but firt of all the users of the system to learn them

how to get the optimal use out of the system. This could require the readibility to change processes and habits of working.

As for the IT-people: focus (in their training) on the transition aspects or objects of the system: interface and reports.

Some Primary Points of Interest

“ Focus on how to USE the system

NOT how to BUILD it ”

(Ed Simons)

A short definition

“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, ...).

Note: if wanted OPUS-College can also be used as a HRM-system, given the extensive data on staff members which can be stored in the system.

Technical aspects in a nutshell

The Opus-College 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.

Apache Tomcat as the web server (container).

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.

The screen images used in this brochure are taken from the

Mozambican implementation and so have the logo “eSURA”.

The users OPUS-College is meant for.

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.

b. Branch, Faculty or Department administrators: 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...

The modules of OPUS-College.

OPUS-College is a full modular system, based on the OSGI-modular framework for JAVA applications: a revolutionary new service-oriented architecture for the JAVA programming environment.

The module structure of OPUS-College is as follows (version 3.0 as per 1st of August 2009):

A Core Module or Kernel common for all institutions implementing OPUS-College and dealing with all data registration and update functions.

Additional Modules, which can be specified and tailored to the needs and situation of a country or even an individual institution. Currently the following additional modules are in OPUS-College:

A Report Module which holds all the output functions of OPUS-College and which can be tailored to the needs and (style) requirements of each individual university.

A Scholarship Module for registering information about student’s scholarship (Mozambican situation).

A Fees Module for registering information on the fees pais by students at a given

Data in the Core or Kernel Module

Part 1:

STUDENT

information in OPUS-COllege

The following slides with screen shots will give an idea of the various data concerning students which can be registered in OPUS-College.

As said before, the screen shots are taken from the Mozambican instance of OPUS-College and therefore bear the “e-SURA” logo instead of the generic “OPUS-College” logo.

First student screen for entering basic personal data on the student.

The “Student Background” screen.

The “Student Identification (document)” screen.

The “Student Miscellaneous” screen.

The “Student Photograph” screen.

The “Student Remarks” screen.

The screen with information on the student’s family.

The screen for the log-in data of the student for the OPUS-College system.

The screen with general info on the study plan of a student.

The screen with detailed info on the study plan of a student (this one has followed the first year of the Bachelor of Sociology in 2008, the 2nd year in 2009 and has planned the 3rd year in 2010. On top of this she has planned to follow an extra “free choice” subject in 2010, called: “Theories of Management).

The screen with detailed info on 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.

The screen for registering info on the absences of a student.

Data in the Core or Kernel Module

Part 2:

COURSE

information in OPUS-College

The screen for registering basic information on a course.

The screen for registering the GRADES of a course.

The screen for registering the STUDY YEARS of a grade.

The screen for registering basic information on a SUBJECT of a course.

The screen for describing the CONTENT OF A SUBJECT.

The screen for registering the TEACHERS OF A SUBJECT.

The screen for registering the DIDACTICAL FORMS or METHODS OF A SUBJECT.

The screen for entering data on the EXAMS and TESTS OF A SUBJECT. Here the exam of the subject is composed of 2 monthly tests each counting for 25% and a final oral exam, counting for 50%.

Additional Modules

Part 1: the

Reports Module

The following screens will illustrate the “Reports Module” of OPUS-College in which all the output functions of the system are bundled. Since it is a separate, additional module not part of the core, this module can be tailored to the specific needs and requirements of a university.

We again, as was the case for the core module, will show examples from the Mozambican “eSURA” instance of OPUS-College.

The currently available forms of output (reports) in OPUS-College.

EXAMPLE: screen for selecting students to produce STUDENT CARDS.

The STUDENT CARD selection screen explained.

STUDENT CARD output from the previous selection.

Another report example: a list of students per study year, grade and course.

Yet another report example: a list of students per subject, with their marks for the subject

And a last example: a list of subjects per student (subjects passed by the student)

Additional Modules

Part 2: the

Scholarship Module and theFees Module

These two additional modules were developed for Mozambique and are tailored to the Mozambican situation and regulation. But just as is the case for the Reports Module, these modules can be left out of the system or re-tailored to the specific needs and requirements of any country or institution.

We will just deal briefly with these modules in the next slides.

Screenshot from one of the screens of the SCHOLARSHIP Module, including a complaint by the studentconcerning the fact that part of the scholarship money was not paid in time.

Screenshot from the FEES Module, showing that the student in question has paid 100 (euros, dollars…) or whatevercurrency is applicable for the country in question, and still has to pay 50.

Some Modeling and Technical Notes.

The remaining slides of this presentation will give an impression of the Modeling and Technical background of the OPUS-College system.

More specifically, we will show some screens to illustrate the:

-Higher Education Business Domain analysis on which the system

is based.

-An example of the HE-Business Process analysis we did.

-The Software Infrastructure of the system.

-The Object Model of the system.

-The Database Model.

Some Modeling and Technical Notes.

Part 1:

HE-Business Domain Analysis

The following slides will show the core entity diagrams and taxonomies for the part of the Higher Education Business Domain, coverd by Opus-College. These diagrams have led to the definition of the entities and attributes included in the system.

Some Modeling and Technical Notes.

Part 2:

HE-Busines Process Analysis

The following slides will illustrate the analysis we did of the relevant business processes for OPUS-College. For this we used the “use case” approach and worked this out by applying the UML framework for use case analysis.

Primary use case in OPUS-College, initial enrollment (matriculation) of students.

The previous use case “Enrollment” written out (part of it).

Some Modeling and Technical Notes.

Part 3:

Software Architecture

Database

Web.xml

load: spring applicationContext and frontcontroller –servletmappings:*.jsp -> dispatchServlet

ApplicationController

formController

ApplicationController

Handler() {// call business logic, // return model and view.}

simpleController

Handler() {// call business logic, // return view.}

StudentValidatorValidate()

StudentManager

findStudentsByName() { students = StudentDao.findStudentsByName(); // perform business logic on students: if(students==null) {StudentDao.helplist};return students;}

Service

findStudentsByName() { return sqlMap.getStudents(); }

StudentDao

sqlMap.xml (Ibatis)

<sqlmap name=“getStudents”>SELECT * FROM STUDENTS</sqlmap> …

Data Access Object

SqlMapConfig.xml

- Database / JDBC Config- sqlMap locaties …

Ibatisweb flow

domain

service

persistenceApplicationController

authorManager.findStudentsByName()

get / post

(d)html / custom javascript Client

FrontController

urlMapping:*.jsp appController……

resolve views map models to views render views

FrontcontrollerServlet

web view

StudentUpdater

Command Object

getName()setName()…

ModelAndView Map

- view- model

See Object-model

applicationContext.xml

- define beans- wire service beans into controllers- wire dao beans into managers- map exceptions to pages…

springfrontcontroller-servlet.xml

- define controllers- resolve views...

spring

web view

web flow

service

persistence

domain

• This layer encapsulates the business logic. It is built with JavaBeans. JavaBeans have a certain state (‘name’, ‘address’, …) and behaviour (‘register()’, …).• Goal is to encapsulate all business logic in the domain model.• All other layers depend on the domain layer. However: The domain layer may not depend on any other layer.

• a.k.a.‘user-interface’ layer• responsible for the presentation towards the end-user. This layer presents (‘renders’) response data from the web-flow layer.• does not contain navigation and no business logic• contains Jsp’s (with images and stylesheets) and JavaScript (Ajax).

database

•responsible for the navigation of the end-user.•transforms HTTP-requests into general requests (without HTTP specific matters) for the underlying service layer•does not contain business logic, but does call business logic in the service layer.•contains Servlets (Controller function)•uses POJO’s and the JavaBeans from the domain-layer.

•offers business logic to the web flow layer in the form of ‘coarse grained’ methods (this means that each method represents a use-case). These methods may not contain ‘state’.•handles concurrent requests and therefore has to be totally stateless !• contains Manager-JavaBeans•uses POJO’s and the JavaBeans from the domain-layer. The JavaBeans will have to contain as much as possible the ‘real’ business logic.

• responsible for the storage and retrieval of objects from the domain model. Typical strategy herefor are the ‘CRUD’ methods.• can only be addressed by the service layer. The service layer is therefore responsible for the coordination of transactions.• uses the iBatis SQLMaps framework.

• responsible for the storage of data and not for business logic. Only in the case of persistency logic or performance matters it is acceptable to store logic in the database.

Some Modeling and Technical Notes.

Part 4:

Object Model

Person

Opus User

Address

Study

OrganizationalUnit

Student

Subject

is 1..*

has 1..*

Has 1

concerns 1

is authorised for 1..*

BA = Subclass from (A is a subclass from B)

Legenda:

= Association from object

= Shortcut for an association from object

taught by 1..*

(version 4 2007-10-17)

Study YearSubject Block

Staff Member

has 0..1

has 1..*

has 0..*

has 0..*

Role

has 1..*

BranchHas 1..*

Study plan

has 1..* Grade Type

has 1..*has *..*has *..*

Institution

belongs to 1

Has 1..*

has 0..*

Examination has 1..*

Subject Result

has 0..1

has 1..*Examination

Result

Exam Result has 0..1

Contract

has 1..*

has 0..*

has 1..*

Some Modeling and Technical Notes.

Part 5:

Database Model