1. ACADEMIC INFORMATION AND REGISTRATION SYSTEM OPUS-College

2. 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)

3. 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.

4. Some Primary Points of Interest “ Focus on how to USE the system NOT how to BUILD it ” (Ed Simons)

5. 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.

6. 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).

7. 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”.

8. 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...

9. 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

10. 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.

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

12. The “Student Background” screen.

13. The “Student Identification (document)” screen.

14. The “Student Miscellaneous” screen.

15. The “Student Photograph” screen.

16. The “Student Remarks” screen.

17. The screen with information on the student’s family.

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

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

20. 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 2 nd year in 2009 and has planned the 3 rd year in 2010. On top of this she has planned to follow an extra “free choice” subject in 2010, called: “Theories of Management).

21. 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.

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

23. Data in the Core or Kernel Module Part 2: COURSE information in OPUS-College

24. The screen for registering basic information on a course.

25. The screen for registering the GRADES of a course.

26. The screen for registering the STUDY YEARS of a grade.

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

28. The screen for describing the CONTENT OF A SUBJECT.

29. The screen for registering the TEACHERS OF A SUBJECT.

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

31. 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%.

32. 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.

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

34. EXAMPLE: screen for selecting students to produce STUDENT CARDS.

35. The STUDENT CARD selection screen explained.

36. STUDENT CARD output from the previous selection.

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

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

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

40. 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.

41. 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.

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

43. 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.

44. 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.

50. 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.

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

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

53. Some Modeling and Technical Notes. Part 3: Software Architecture

54. Database Web.xml load: spring applicationContext and frontcontroller – servlet mappings: *.jsp -> dispatchServlet ApplicationController formController ApplicationController Handler() { // call business logic, // return model and view. } simpleController Handler() { // call business logic, // return view. } StudentValidato r Validate() 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) SELECT * FROM STUDENTS … Data Access Object SqlMapConfig.xml - Database / JDBC Config - sqlMap locaties … Ibatis web flow domain service persistenc e ApplicationController 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 … spring frontcontroller-servlet.xml - define controllers - resolve views... spring

55. web view web flow service persistence domai n 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.

56. Some Modeling and Technical Notes. Part 4: Object Model

57. Person Opus User Address Study Organizational Unit 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..* Role has 1..* Branch Has 1..* Study plan has 1..* Grade Type has 1..* 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..*

58. Some Modeling and Technical Notes. Part 5: Database Model