Transcript OPUS-College

OPUS-College
ACADEMIC INFORMATION AND
REGISTRATION SYSTEM
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.
Advantages / Merits of OPUS-College (1)

OPUS-College covers a broad range of functionality concerning
academic administration issues and tasks in an integrated way: full
registration and update functions for student, staff, course, subject and exam
information in one system.

OPUS-College is cheap: given the fact that OPUS-College is open source,
the system as such is for free.

No risk of vendor dependency or lock-in. Institutions implementing
OPUS are not dependent of the policy of vendors, e.g. as to when and how
new versions or functionality becomes available, but the open source
character of the systems make adjustments by any qualified IT-expert
possible at any time.
Advantages / Merits of OPUS-College (2)
 Based on proven and future-oriented technology:

Application written in JAVA: the worldwide standard for professional
open source application development.

Database PostgreSQL: called the “ORACLE of Open Source”. But in
principle any other database can be used in combination with the OPUSCollege application.

Full modular service-oriented architecture; based on OSGI: the
leading framework for service-oriented JAVA application development.

100% web-based: accessible anytime from anywhere over the Internet. All
the user need to use the system is a web browser, so no technical learning
investment needed by the user.

XML-based interoperability: all the exchange of information with
other systems is done by means of XML with existing schemas for validation.
Advantages / Merits of OPUS-College (3)
 Easily extendible: given the modular architecture of the system, the
functionality of OPUS-College can easily be extended with modules of various
kinds (e.g. a module for managing the housing of students on campus, an
electronic publication module, a research information module, etc…).
 Platform independent: can run on Windows, Linux and Mac operating
systems.
 Based on (international) “community approach”: OPUS-College is
developed in cooperation with various international IT-experts (Netherlands,
Austria, Mozambique) and all modules developed by participants are put
available for free to the whole community. This approach makes the system a
good platform to initiate South-South cooperation.
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 OPUSCollege 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
Additional Modules
Part 1: the
Reports Module
The following screens will illustrate the “Reports Module” of OPUSCollege 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 the
Fees 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 student
concerning 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 whateve
currency 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
applicationContext.xml
spring
- define beans
- wire service beans into controllers
- wire dao beans into managers
- map exceptions to pages
…
spring
frontcontroller-servlet.xml
- define controllers
- resolve views
...
Database
Web.xml
web flow
load: spring applicationContext and frontcontroller –
servlet
mappings:
*.jsp -> dispatchServlet
Command Object
StudentUpdater
getName()
setName()
…
Client
FrontController
get / post
urlMapping:
*.jsp  appController
…
…
resolve views
map models to views
render views
Map
ModelAndView
- view
- model
sqlMap.xml (Ibatis)
<sqlmap name=“getStudents”>
SELECT * FROM STUDENTS
</sqlmap>
…
- Database / JDBC Config
- sqlMap locaties
…
StudentValidato
r
Validate()
Data Access Object
formController
FrontcontrollerServlet
Ibatis
ApplicationController
(d)html / custom javascript
authorManager.findStudentsByName()
SqlMapConfig.xml
StudentDao
Handler() {
// call business logic,
// return model and view.
}
findStudentsByName() {
return sqlMap.getStudents();
}
persistenc
e
ApplicationController
ApplicationController
simpleController
Handler() {
// call business logic,
// return view.
}
Service
StudentManager
findStudentsByName() {
students =
StudentDao.findStudentsByName();
// perform business logic on students:
if(students==null) {StudentDao.helplist};
return students;
}
web view
service
domain
See Object-model
• 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).
web view
•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.
web flow
service
persistence
• 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.
database
domai
n
Some Modeling and Technical Notes.
Part 4:
Object Model
Has 1..*
Institution
Role
Has 1
has 1..*
Address
Opus User
Person
Organizational
Unit
has 0..1
is authorised for 1..*
belongs to 1
Study
has 1..*
Staff Member
Contract
Student
has 1..*
concerns 1
has 1..*
Exam Result
has 0..1
taught by 1..*
has 1..*
Examination
Result
= Association from object
Grade Type
Study plan
Subject Result
Legenda:
Has 1..*
has 1..*
is 1..*
has 1..*
Branch
has *..* has *..*
Subject Block
has 0..1
has 0..*
has 0..*
has 1..*
Study Year
has 0..*
Subject
has 0..*
= Shortcut for an association from object
A
B
= Subclass from (A is a subclass from B)
Examination
has 1..*
(version 4 2007-10-17)
Some Modeling and Technical Notes.
Part 5:
Database Model