Course Curriculum Planning and Management System MARIN RUDIC

Transcription

1 Course Curriculum Planning and Management System MARIN RUDIC School of Innovation, Design and Engineering Subject: Computer Science Advanced level 30 ECTS Credits Thesis advanced level, Computer Science Course Code: CDT504 Supervisor: Ivica Crnkovic Examiner: Kristina Lundqvist Date:

2 2

3 DEDICATE Friends. This thesis is dedicated to my beloved Family, Teachers and years. Especially for my parents and sister who woke me up all those 3

4 ACKNOWLEDGMENT I have had pleasure to work on this project. However, it would not have been so good and interesting without support and help of my supervisor Mr. Ivica Crnkovic. I would like to extend my sincere thanks to him, to IDT School at MDH and all colleagues. They were my support in completion of this Master Thesis. 4

5 TABLE OF CONTENTS 1. INTRODUCTION Project motivation The project aim Thesis overview DEVELOPMENT PROCESS Software prototyping development process Evolutionary prototyping process Prototyping of the COSY information system REQUIREMENTS SPECIFICATION Overview of the course and management process Schema of the current actions and users Requirements specification for COSY FIRST PROTOTYPE ARCHITECTURE Structure of the application User permissions Module components FIRST PROTOTYPE IMPLEMENTATION The Back-end application implementation The Front-end application implementation ANALYSIS OF THE FIRST PROTOTYPE OF THE APPLICATION Description of the first prototype Strategy for the next prototype THE CURRENT PROTOTYPE ARCHITECTURE Application architecture Database Users permissions THE CURRENT PROTOTYPE IMPLEMENTATION COSY module implementation WordPress implementation ANALYSIS OF THE CURRENT PROTOTYPE Description of the current prototype Strategy for the next prototype USED TECHNOLOGIES PHP / MySQL WordPress WordPress plug-ins

6 10.4. HTML / CSS JavaScript / JQuery FUTURE WORK CONCLUSION ABSTRACT SUMMARY ON CROATIAN / SAŽETAK REFERENCES

7 1. INTRODUCTION This thesis describes a design and implementation of Course Information Management System (COSY) for a Curriculum planning support at MDH. The thesis includes a description of the current curriculum planning processes, the requirements analysis and data analysis, modelling the current processes in information system and development software that implements these processes. The current process of the course curriculum program management system is based on a manual exchange of a document usually in a paper form or exchanges. The overview of available information about courses and programs is not on satisfactory level. With the COSY information system we want to improve accessibility and overview of information and documents of curriculum process Project motivation Every academic year MDH must publish program of the next academic year with all associated documentation which must be available to all students and the staff. Associated documentation must include all courses and programs of that academic year. If a course or a programme is just being introduced, firstly, it must pass through a verification process and must be approved by different instances at MDH. For the existing courses and programs there exists data in form of files and web pages, but that data is not suitable for management. Motivation for the project is to simplify the management and planning of the courses and programs inside the university. The major problems of the current system are: There is no data management system for managing programs and courses (Data management system cares about changes in the data and privileges about changing some data). No data validation other than manual people work (There is no validation of data and it is possible to make some mistakes like collisions of courses, or some data can be lost). Lack of visualization of the data (Visualization of the data through excel sheets is usually hard and it is impossible to make good relations between data, especially if data is in different datasheet). 7

8 The system does not provide tools for better management of the courses, programs and assign staff The project aim The project aim is to provide a web application that would solve all mentioned issues and provide functionality that would further increase a productivity of the people involved, i.e.: Provide a simplified management of the data about courses, course instances, programs, program instances and staff, by storing it and protecting it from unwanted changes; Provide visual aid to cope with the planning and management of academic year Thesis overview The rest of the thesis is organized as follows: Chapter 2 describes software prototype development process. Chapter 3 contains project requirements specification, to clearly understand the goals of this project. Chapter 4, 5 and 6 contain description of the first application prototype. Chapter 6 also contains description of the strategy for the current prototype which is described in chapter 7, 8 and 9. Chapter 7 descripts architecture while chapter 8 descripts implementation of the current prototype. Analysis of the architecture and implementation is done in chapter 9. Chapter 10 contains description of used technologies. Chapter 11 contains the discussion about ways of future work based on chapter 9. Chapter 12 contains the conclusion. 8

9 2. DEVELOPMENT PROCESS This chapter describes the process of production of the COSY project. In the production of the COSY project, on which continually worked a few people, we can describe software prototyping method of development Software prototyping development process Understanding user requirements is an integral part of the information systems design [1] and is critical to the success of interactive systems; a successful system implementation begin with an understanding of the needs and requirements of the users. Particular problems faced by the analyst are: addressing complex organizational situations with many stakeholders users and designers thinking along traditional lines, reflecting the current system and processes, rather than being innovative users don t know in advance what do they want from the future system Those problems are the reason to go on with the software prototyping development [2] concept because it keeps us in a circular contact with the user, reducing the time available for the user needs analysis and representing the user requirements in an appropriate form. Software prototyping refers to the activity of creating prototypes of software applications, incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing. A prototype typically simulates only a few aspects of, and may be completely the final product. Figure 1:Software prototype model shows a development process with the prototype as continuous activities. 9

10 Prototyping Initial requirements Design Custo Customer mer satisfied Evaluation Review and updating Maintain Test Development Figure 1:Software prototype model The process of prototyping [3] involves the following steps until the user is satisfied: Identify basic requirements - Determine basic requirements including the input and the output information desired. Details, such as security, can typically be ignored. Develop Initial Prototype - The initial prototype that includes only user interfaces is developed. Review - The customers, in this case supervisor, examine the prototype and provide feedback on additions or changes. Revise and Enhance the Prototype - Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the product may be necessary. If changes are introduced then a repetition of the previous and this step may be needed Evolutionary prototyping process This project is produced in Evolutionary prototyping process. The main goal in using Evolutionary Prototyping [4] is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and then improvements and further requirements will be built. 10

11 When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt. Evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood [5]. This technique allows the developer to add features, or make changes that couldn't be conceived during the requirements and design phase. In Evolutionary Prototyping, developer is focused to develop parts of the system that he understands instead of working on the development of the whole system. Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met Prototyping of the COSY information system Evolutionary prototyping software development process is used in previous work on this project. Description of the first prototype is processed in chapters 4 First prototype architecture and 5 First prototype implementation. Analysis of that prototype is done with the supervisor s consultation in the chapter 6 Analysis of first prototype of application. The first prototype of the application helps in better understanding of the user s needs and necessary functionalities which must be supported. Also it takes experience with the problems related with the implementation and usage of some tools, what can be improved and corrected inside the next prototype. After the first prototype, done in a previous work, we continued the work, but with several major changes in the design and the technology. The work continued using the same method, evolutionary prototyping. 11

12 3. REQUIREMENTS SPECIFICATION This chapter provides details about the current process of the curriculum planning at MDH which yields to the actions and requirements of the COSY system. Requirements specification in the second subchapter is the result of the analysis of the role and activity showed in the first subsection Overview of the course and management process An overview of the overall functionality is given below. A university (here MDH) performs education in form of programs and courses. Each program defines a curriculum, i.e. the courses which can be given as a part of that program. In addition a program defines a number of other data, such as who has the main responsibility for the program, a short description of the program, how many years it includes, etc. Each course is uniquely defined by the course code, and the name. In addition it includes information about what is the course about, of which education and examination elements it consist, what are the requirements to enrol in the course, how much credits it provides, and similar. Figure 2: People and activity in current process Both programs and courses have instances. Each academic year, a new program instance must be created. Such an instance defines the program start, the responsibility, and 12

13 of which course instances it consists (a program instance does not need to include all courses predefined in the program). A course instance is a course that will be performed in a program instance starting at particular date, having a schema, responsible teachers, and a certain number of students that will take this course. Figure 2 shows the data structure. There exists a strictly defined process about programs and courses management i.e. their creation, editing, and approval. The process is defined through a number of activities. They are described in subchapter

14 3.2. Schema of the current actions and users Figure 3: People and activity in current process describes roles and activities of programs and courses management. Management Board Initiate New Program Creation Approve Program Curriculum Define Courses Involved in Program Define Course Plans Manages Data of Free Places and Enrollment Statistic of Courses Define Course Instance Lecturer Define Program Curriculum Define Course Plans Head of Division Cancel Courses Define New Course Define Program Schedule Configure International Coordinator Program Coordinator Define Detailed Program Description Define Program Proposal Course Planning Group Define Program Popular Description Review/Accep t Course Plans Define Program Description for the catalogue Import/Export Data Enters Data in DSI Administrator Secretary Figure 3: People and activity in current process 14

15 3.3. Requirements specification for COSY Requirements are described with identification of the necessary data and short description on how to fill those data inside COSY application Create program Data required: Program code Title (English), Title (Swedish) Degree School Coordinator Syllabus link Language of Instructions Duration Courses Description (English), Description (Swedish) Comment (English), Comment (Swedish) Description: Data are entered in a predefine form. Input form must be in English and Swedish where the names of the form fields will be visible in current active language, and if some field is select type of input field it will be in current active language too. Courses can be dynamically added or removed. The fields Title (English), Title (Swedish) Degree, School and Coordinator are compulsory and the form can t be completed before that fields are filled Create program instance Data required: Program Coordinator Academic year Courses Syllabus link Description: Input form must be in English and Swedish where the names of the form fields will be visible in the current active language, and if some field is selected the type of input field it will be in current active language too. Course instances can dynamically added in information 15

16 system from this form with help in fill data if any previous interesting course instance exists in system. The course instance can be connected with the new program instance which will be created in this form. The fields Program, Academic year and Coordinator are compulsory and the form can t be completed before that fields are filled Approve program Data requirement: Status Description: Administrator and Education leader must have privileges to change program status. After program is once approved it is no longer possible to make changes on its data Approve program instance Data requirement: Status Description: Administrator and Education leader must have privilege to change program instance status. After program instance is once approved it is no longer possible to make changes on its data Edit program Data requirement: Program code Title (English), Title (Swedish) Degree School Coordinator Syllabus link Language of Instructions Duration Courses Description (English), Description (Swedish) 16

17 Comment (English), Comment (Swedish) Description: Input form must be in English and Swedish where the names of the form fields will be visible in current active language, and if some field is select type of input field it will be in current active language too. Courses can dynamically add or remove until form isn t completed. The fields Title (English), Title (Swedish) Degree, School and Coordinator are compulsory and the form can t be completed before that fields are filled. Edit form is accessible only if program isn t approved Edit program instance Data requirement: Program, Coordinator, Academic year, Courses, Syllabus link, Description: Input form must be in English and Swedish where the names of the form fields will be visible in current active language, and if some field is select type of input field it will be in current active language too. The course instances can dynamically added in information system from this form with help in fill data if any previous interesting course instance exists in system. The course instance can be connected with new program instance which will be created in this form. The fields Program, Academic year and Coordinator are compulsory and the form can t be completed before that fields are filled. Edit form is accessible only if program instance isn t approved Delete program Description: Deleting a program is possible form the page with full description about the program, and system must ask if the user is sure about that action. 17

18 Delete program instance Description: Deleting a program instance is possible from the page with full description about the program instance, and system must ask if the user is sure about that action Create course Data required: Program code, Title (English), Title (Swedish) Level Marks Examination Credits Area of education Subject School Responsible Language of Instructions Syllabus link Main field of study Prerequisites (English), Prerequisites (Swedish) Objectives (English), Objectives (Swedish) Learning objectives (English), Learning objectives (Swedish) Content (English), Content (Swedish) Teaching methods (English), Teaching methods (Swedish) Workload (English), Workload (Swedish) Environmental aspects (English), Environmental aspects (Swedish) Other Regulations (English), Other Regulations (Swedish) Literature (English), Literature (Swedish) Comment Valid from semester Valid from Description: Input form must be in English and Swedish where the names of the form fields will be visible in current active language, and if some field is select type of input field it will be in current active language too. Examinations can be dynamically added or removed until the 18

19 form isn t completed, if some examination is selected than it is required to all fields about that examination. Credits of course are sum of all selected examination credits. The fields Title (English), Title (Swedish), Level, Marks, Examination, Credits, Area of education, Subject, School, Responsible and Prerequisites (English), Prerequisites (Swedish) are compulsory and the form can t be completed before that fields are filled. The valid from is date type of field Create course instance Data required: Course Estimated number of students Actual number of students Planned budget in hours Workload Staff Location Syllabus link Academic year Periods Description: Input form must be in English and Swedish where the names of the form fields will be visible in current active language, and if some field is select type of input field it will be in current active language too. Course instance can be made of any existing course. The fields Course, planed budget in hours, Workload, location and Academic Year are compulsory and the form can t be completed before that fields are filled Approve course Data required: Status Description: Administrator and Education leader must have privilege to change course status. After course is once approved it is no longer possible to make changes on its data Approve course instance Data required: 19

20 Status Description: Administrator and Education leader must have privilege to change course instance status. After course instance is once approved it is no longer possible to make changes on its data Edit course Data required: Same data as in Create course Description: Same form description as in Add new course, but page for edit data is accessible only while course isn t approved Edit courses instance Data required: Same data as in Create course instance Description: Same form description as in Create course instance, but page for editing the data is accessible only while course isn t approved Delete course Description: Deleting a course is possible from the page with full description about course, and system must ask the user if it is sure about that action Delete courses instance Description: Deleting a course instance is possible from the page with full description about course instance, and system must ask the user if it is sure about that action. 20

21 Create user Data required: Username First Name Last Name Password Confirm password Send password User group Description: Administrator can add a new users, this form doesn t have to be in English and Swedish. Generating of the password and sending connection data to the new user by are required functionalities. The fields Username, , password, confirm password and user group are compulsory and the form can t be completed before that fields are filled. 21

22 4. FIRST PROTOTYPE ARCHITECTURE The prototype was created using PHP framework Symfony with Doctrine plug-in [6]. The MySQL database management system is used and set-up based on tutorial [7]. The Symfony is running locally on WAMP [8] (Windows Apache MySQL PHP) server for developing applications. Files and module structures of the project are generated using terminal with Symfony scripts. The prototype itself is located at the host server. The information about database is provided in the following section. There is a MySQL Workbench 5.2 CE [9] connected to the database to help inspecting generated database Structure of the application The main structure of the project was implemented by the framework and it was kept consistent throughout the project. This prototype of the application used a concept of two applications: Front-end application This application is supposed to be used by users and it allows limited privileges to change data in the information system Back-end application This is used by a COSY administrator and he/she has privileges to change all data in the information system The Front-end application The Front-end application provides functionalities that are accessed by the common system users for all their functions. There are four main modules in the front-end of the application, as shown on Figure 4: The main structure of COSY web system pages in the front-end of application Course course management (creation, editing) Course instance course instances management (creation, editing) Programs programs management (creation, editing) 22

23 Program instance program instances management (creation, editing) Figure 4: The main structure of COSY web system pages in the front-end of application The Back-end application The Back-end application is intended to provide a possibility to manipulate data only for a few privileged users (like administrator) and an access to the components of the management system for groups, permissions, etc. See Figure 4: The main structure of COSY web system pages in the back-end of application. Figure 5: The main structure of COSY web system pages in the back-end of application 23

24 4.2. User permissions The users are divided in six groups and each group has different privileges like it is showed in Table 1: Permissions for user groups inside the system. Types of users in the system: EL - Education Administrator and Education Leader (one role for the first iteration) DV - Division Manager PC - Program Coordinator CR - Course Responsible Person TA - Teacher and teacher assistant A Admin Table 1: Permissions for user groups inside the system E D P C T A L V C R A Create program x x Create program instance x x x Approve program x x Approve program instance x x Edit program x x x Edit program instance x x x Delete program x x Delete program instance x x x Create course x x x x x x Create course instance x x x x x Approve course x x Approve course instance x x Edit course x x x Edit courses instance x x x x x x Delete course x x Delete courses instance x x x x x Create user x Edit user x x x x x x Delete user x 24

25 4.3. Module components Each model contains the following components: Filters The filters [10] are an important part of reducing the amount of results in screen. This helps the user to find particular entries easier. File filters on a single table are easy to create by specifying the field and the rules in specific file. The Symfony documentation provides information required to create them. On the other hand, there were problems when it comes to filtering on tables with relations to other tables. For example, the course instance inherits the course name from a course table. In the course instance table the user would like to filter on course name and there have emerged problems Forms The forms [11] are a big part of the application and Symfony provides lots of widgets to make validation and presentation easier. As in all parts of Symfony, executing forms on a single database table is rather straight forward and adding some additional functionality from other tables requires merge and embedding to be correctly saved in the database Database This project is using Doctrine - PHP Object Persistence Libraries, which is part of Symfony project to generate database. The MySQL database is called cosy and database ER diagram is presented in Figure 6: ER diagram of COSY application first prototype. Some of the tables like user profile and program documents have been removed from diagram in order to improve the readability. Required files for generating database: schema.yml This file contains description of the database tables and relations in YAML language. Simply put, this is the database structure. fixtures.yml This file contains basic information to be loaded into the database in YAML (Yet Another Markup Language) [12] language. Some data are required for the system to run (e.g. 25

26 the possible user s roles in the system) and the others are there for the test purposes (dummy records). databases.yml This file describes the location, type and the connection details of the database to be created and loaded for the project. The file is written in YAML language 26

27 Figure 6: ER diagram of COSY application first prototype 27

28 5. FIRST PROTOTYPE IMPLEMENTATION This chapter describes the structure of the COSY implemented in Symfony framework as one module of a back-end and front-end application. The front-end application is visible for all users and they can use all functionalities. The back-end application is visible only for administrators which can use all functionalities of front-end and back-end application The Back-end application implementation The Back-end application is generated by Symfony framework and it has unfinished GUI (Graphic User Interface). On homepage Figure 7: Back-end application homepage is visible that there are more options than in front end application described in the chapter Front-end application implementation. Figure 7: Back-end application homepage Program instance list After click on Program Instances button in main menu information system showing module instances (Figure 8: Program instance module ). 28

29 Figure 8: Program instance module View/edit program instance By select a program instance on the list of existing program instances in Figure 8: Program instance module a screen page view/edit selected program instance will be shown (Figure 9: Program instance view/ edit module). Figure 9: Program instance view/ edit module 29

30 5.2. The Front-end application implementation The project design is created as suggested by framework, using decorator design pattern and a combination of HTML and CSS. The main layout is described in main.css layout for front-end. The logo was created using font Jokerman. Homepage with the logo is visible in Figure 10: COSY homepage. Figure 10: COSY homepage Program instance list After click on Program Instances button in main menu information system taking Figure 11: Program instance module screen. 30

31 Figure 11: Program instance module View program instance By a selection of a program instances on the list of existing program instances in Figure 11: Program instance module screen page with detail information about selected program instance will be shown Figure 12: View program instance module. Figure 12: View program instance module Add new / edit program instance 31

32 By click on Edit button under main menu on the Figure 12: View program instance module screen page edit program instance module will be shown Figure 13: Edit program instance module. Figure 13: Edit program instance module 32

33 6. ANALYSIS OF THE FIRST PROTOTYPE OF THE APPLICATION Analysis of the first prototype is described in two subchapters. In the first subchapter is description of the first prototype which explains how it is implemented. Analysis of the implementation is in the second subchapter and it is done by comparing the provided functionalities and requirements, with goal to improve application (system) Description of the first prototype Symfony is an Object-Oriented framework and it prefers to manipulate objects whenever it is possible. For example, instead of writing SQL statements to retrieve records from the database it is preferred to use objects. The relational database information is mapped in an object model. This can be done with an ORM (Object Oriented Mapping) tool. Symfony comes bundled with two of them: Propel [13] and Doctrine [14]. The description model of the database used in the project provides adding new columns or tables in the database and relations between tables without any problems. But the problem comes in defining the display and manipulation of data. Project was developed following the step by step directions of official tutorial of Symfony framework based on development of the Jobeet application.[15] Within the documentation there is description on how to make multi language applications using Symfony framework. At the beginning of the project the use of multiple languages was not anticipated, all description was how to make one language site. The adaptation of the web pages for multiple languages is on the end of the demo project described through translation of the names of some links and categories that are manually entered into the database via a file fixtures.jml with initial data in the database. There is no dynamics that we need and there are no more tutorials which can help us to make everything what we need in COSY project. Symfony framework is based on MVC (Model View Control) [16] model and generating View and Control parts according to database Model of application thus reduces the dynamics of manipulation with forms. Making customized forms and available data in forms thought description files is more complicated than simple use of PHP and HTML and some solutions are impossible to make because they are not provided by Symfony. 33

34 Symfony framework s advantage in production of forms and their validation with object oriented modes is in serialization and readability of source code but it reduces the necessary freedom to manipulate the data in this project. This application requires a complete operation and manipulation of multi-language data. Current solution implemented with Symfony is not practical because the used framework in the project should allow easier and faster operations Strategy for the next prototype Database model of application implemented with Symfony generated useful relation database with main structure of tables but the tables don t contain all necessary data columns. The problem with the display and manipulation of data trough MVC model will be resolved with avoid using the MVC model and use direct manipulation of data with PHP. Also low level of flexibility in using more languages inside standard Symfony functions is problem which must be resolved. Alternative solutions to the Symfony framework are Drupal [17], WordPress [18] and specially made CMS for this application. CMS (Content management system) [19] is a computer system that allows publishing, editing, modifying content and its structure from a central page independent of application functionality. The biggest difference between WordPress and Drupal is that Drupal is a Content Management System, and WordPress was initially a blog engine. This means Drupal assumes that there will be many different kinds of users with various levels of control who are administering a website, and WordPress assumes there will be only one. WordPress has moved into CMS space, because most people who started off as simply bloggers have realized that they need more than just a blog, but they already have experience with WordPress and they are familiar with its interface. Similarly, Drupal needs additional modules to be installed and configured to get exactly the same functionality as a WordPress blog, and considerable time would be needed to do setup and configuration. We selected WordPress because Drupal is more complicated with user level privileges, i.e. solution with multiple administrator types that we don t need on this project. There is only one level of developer administrator which has access to CMS and privileges to change data and structure of application. The welcome page in WordPress application is 34

35 organized like a blog page where administrator can put news related to the application. WordPress provides us with enough good tools to manage contents of other web pages. Making own CMS is impractical because it will take more time than the first two solutions and also it will be more complicated to build upon in the future for a new developer. Drupal and WordPress support Multilanguage sites and its structure is of the critical meaning for this project. In the next iteration the idea is to improve filters on the course, course instances, programs and program instances pages to work without refreshing the page. Distribution on front-end and back-end application which exists, because it was complicated to present different user interface to different users, will be abolished and implemented as one application which enables that functionality. 35

36 7. THE CURRENT PROTOTYPE ARCHITECTURE The first subchapter describes the architecture of COSY application (WordPress and core application levels) and its basic operations while in second subchapter are described changes in user privileges Application architecture Application is working in a client server architecture based on the HTTP protocol.[20] HTTP defines a request-response protocol in the client-server computing model. A web browser is the client application. Apache server in this case, is an application which running on a host computer and provides a web site is the server. The client submits an HTTP request message to the server. The server process request forwards it on associated PHP applications which like result make HTML and other content, or perform other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body. HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. That architecture is shown in Figure 14: Client server architecture. Client Web browser HTTP request response Server Apache Web server (service) COSY Applicaton PHP module qureys SQL MySQL server (service) Database Figure 14: Client server architecture 36

37 COSY Application architecture Apache web server forwards HTTP request to COSY application based on the request s message. Request s message contains data used by COSY application architecture shown in Figure 15: COSY application architecture. Data that are interesting for COSY application are in the URL (Uniform Resource Locator) and the posted fields. URL contains data for navigation on the web pages mostly used from WordPress application which is backend part of COSY application. WordPress is used like a CMS and it takes care about navigation through modules of COSY core application shown in Figure 16: COSY core application architecture and currently used language. Posted data are used from Cosy core application and its modules and sub-modules. COSY application WordPress Users COSY core Courses Course Instances Programs Program Instances Users Admin Figure 15: COSY application architecture 37

38 COSY core COSY core includes a basic functionality for course and program management information system shown in Figure 16: COSY core application architecture. It contains courses, course instances, programs, program instances, users and admin modules which contain its sub modules responsible for each action of parent module. COSY core Courses Course Instances Programs Program Instances Users Admin Figure 16: COSY core application architecture All modules are made based on the same pattern to simply understand concept of work and file structure of each module. List sub-module presenting table with short description of course, program or other data for which is that module responsible. View submodule presenting full data, edit sub-module provides changing of data while Add new provide insert new data in the COSY information system. A Module contains the following sub-modules: List - table view of data View full data description Edit edit data Add new add new data 38

39 7.2. Database This chapter describes the database structure. WordPress database is described in the first subsection, while COSY core application database is described in the second. COSY core and WordPress applications have only one common table wp_users, because information system needs possibility to get different content to different role of users like it is descript in chapter 7.2 Error! Not a valid bookmark self-reference WordPress database The diagram Figure 17: WordPress database diagram provides a visual overview of the WordPress database [21] and the relations between the tables created during the WordPress standard installation. 39

40 Figure 17: WordPress database diagram The table overviews and additional details about tables and columns can be found on WordPress official site [18] followed by specific information of each table COSY core database COSY core database is built on the database descript in chapter Database of the first prototype s ER diagram Figure 6: ER diagram of COSY application first prototype which stayed unchanged. Only users are referenced on WordPress-s table, but that doesn t change ER diagram, and the fields added in the tables are not visible on ER diagram Figure 18: COSY core part of database. 40

41 Figure 18: COSY core part of database 7.3. Users permissions Users permissions are changed instead of users permissions used in the first prototype described in the Table 1: Permissions for user groups inside the system. In this prototype user permissions can be observed from two points. The first point of observation is from WordPress which observes the users in a two groups, administrators and COSY users, with possibility that an administrator is COSY user too. Second point of observation is from COSY core, which observes users in a few groups depending on a role in the information system. 41

42 WordPress users In this chapter describes how WordPress observes users [22] of the information system and which privileges do they have in the WordPress application. WordPress uses a concept of Roles, designed to give the administrator the ability to control and assign what users can and cannot do on the page or in CMS. An administrator can manage and allow access to such functions as writing and editing posts, creating Pages, defining links, creating categories, moderating comments, managing plug-ins, managing themes, and managing other users. WordPress has five pre-defined Roles: Administrator Editor Author Contributor Subscriber Each Role is allowed to perform a set of tasks called Capabilities. In this case WordPress is configured to have users divided in two groups: Administrators COSY users Administrators have full access to perform all possible Capabilities in WordPress and administrator role in COSY core system too, which grants them full privileges. COSY users don t have access to WordPress and don t have direct access to any Capability. They only can indirectly access to add_users create_users promote_users list_users remove_users delete_users Capabilities through COSY core are available if their role in COSY core allows that. 42

43 COSY core users In this chapter describes how the COSY core application observes users and which privileges they have in the core of information system. Privileges are a little changed since the first prototype, instead of privileges used in the first prototype described in Table 1: Permissions for user groups inside the system. Types of users and capabilities of each group of users in the system are represented in Table 2: COSY users and privileges: A - Administrator EL - Education administrator and Education Leader DV - Division manager TA - Teacher and teacher assistant Table 2: COSY users and privileges A EL DV TA PC CR Create program X X Create program instance X X X Approve program X X Approve program instance X X Edit program X X X Edit program instance X X X Delete program X X Delete program instance X X X Create course X X X X Create course instance X X X Approve course X X Approve course instance X X Edit course X X X Edit courses instance X X X Delete course X X Delete courses instance X X X Create user X X Edit user X X Delete user X X Separated groups: PC - Program Coordinator CR - Course Responsible Person In Table 2: COSY users and privileges descript privileges of a user from any group who is selected as responsible person for course or program. 43

44 8. THE CURRENT PROTOTYPE IMPLEMENTATION In this chapter structure of the COSY information system implemented in WordPress backend application and one module of COSY core application are described. COSY core application is visible for all users but all users can t use all functionalities, it depends on the user role and privileges like it is described in Table 2: COSY users and privileges. It also describes features in WP application that are visible only for administrator COSY module implementation In this chapter Program Instances module of the COSY is described. All COSY modules visible in Figure 16: COSY core application architecture are made following the same pattern so there is no need to describe each module individually. After signing up in the COSY information system user is located in Figure 19: COSY homepage from where is possible to go on any module. Program Instances module is selected because it is the most complicated module and uses parts of other modules, which will be described too. Also description is made for administrator accounts that some options will not be visible or permitted if a user sign-up in the system from other non-administrator account. Figure 19: COSY homepage 44

45 Program instance list When clicking on Program Instance button in the main menu, the COSY information system get response like Figure 20: Program instance list module screen. Figure 20: Program instance list module Table content is sortable by all columns and searchable through text input in the top right corner of table. Content of the table is automatically filtered with the search criteria, independently of which data column satisfies it. These features are made with the DataTables jquery plug-in. DataTables operates on the principle of progressive enhancement, whereby an enhanced and interactive table will be presented to the end user in their browser. When the jquery.datatable object is initialized, information about the table is ready for use directly from the HTML page. 45

46 Add new program instance After clicking on Add Program Instance button located in the top left corner of the table with list of existing program instances visible in Figure 20: Program instance list module user is redirected on the add new program instance page visible in Figure 21: Add new program instance form. Figure 21: Add new program instance form Module presenting input form for adding a new program instance in the system. To create new program instance first a Program of Program Instance must be selected. It can be done by selecting one of existing programs or program instance. Click on a button Select program will pop up dialog visible in Figure 22: Select program dialog or Select program instance will pop up dialog visible in Figure 23: Select program instance dialog. 46

47 Figure 22: Select program dialog Figure 23: Select program instance dialog There are similarities between the content of these two dialogs and list modules because they are in close relation with the list sub-modules of Program or Program instances module. Searching and sorting of data in the dialog are possible. After a user selects one of the programs or program instances, data in the form will be changed like it is shown in Figure 24: Add new program instance form after select program or program instance. If a program is selected, than input form will show selected program data and the list of all courses related to that program. In other case, when a program instance is selected, there will be program data of the program contained in that program instance. On the courses list there will be only courses from which selected program instance contains course instance. 47

48 Figure 24: Add new program instance form after select program or program instance It is always possible to add course on the list again by clicking on the button Add course and selecting it in the dialog in Figure 25: Add course in table dialog. Figure 25: Add course in table dialog A course is on the list in the dialog if it is included in selected program list of courses. 48

49 Program instance represents program of a specific academic year with specific course instances for that year. A program instance doesn t have to contain all courses of some program and nor does it have to contain same courses each year. Courses have some specific data each academic year and there can be more same courses in the same academic year with different specific data those the COSY system have course instances. Program instance will be related to course instances added in list of courses in Add new program instance form. Relation between program instance and course instance can be associated by clicking on New instance in course row and fill the form in dialog. Association with existing course instance can be done by click on Select Instance and select course instance in dialog. Figure 26: Create course instance dialog If the user clicks on New instance button, action will pop up dialog shown in Figure 26: Create course instance dialog which contains form to input data for new course instance. That form will have default values from existing course instance in association with selected program instance in dialog in Figure 23: Select program instance dialog if the user has previously made that action or it will be empty if the user previously selects a program in dialog Figure 22: Select program dialog. 49

50 Figure 27: Select course instance to gat data Independently if a user select program or program instance in dialog Figure 26: Create course instance dialog it is possible to click on button Existing course instance and get data from selected course instance in dialog in Figure 27: Select course instance to gat data to form in Figure 26: Create course instance dialog. Figure 28: Select user dialog In the form in Figure 26: Create course instance dialog it is possible to associate users in information system with a course instance. By clicking on the Add Staff button, dialog Figure 28: Select user dialog with all users will pop up. After user is selected it is possible to input role of that user on that course instance and planed working hours or removes the user from that course instance. 50

51 Figure 29: Add new program instance form after association with some course instance When the form Figure 26: Create course instance dialog is submitted or an existing course instance is selected in the dialog in Figure 30: Select course instance dialog, the course instances which will be associated with the new program instance, after saving the form, are visible on the list as shown in Figure 29: Add new program instance form after association with some course instance. Figure 30: Select course instance dialog After the form is successfully filled out and saved, the new program instance is visible to other parts of the information system. 51

52 View program instance View program instance module in Figure 31: View program instance module presents all data about selected program instance shown in Figure 20: Program instance list module. Figure 31: View program instance module Visible data belong to selected program instance, by clicking on View Program or one of View buttons in the list of course instances, new tab will be opened with detail data about program Figure 32: View program module or course instance Figure 33: View course instance module. 52

53 Figure 32: View program module Figure 33: View course instance module 53

54 On the bottom are documents and links tables which content can be added in Edit program instance module descript in next chapter Edit program instance module Edit program instance module in Figure 34: Edit program instance module is opened when click on Edit button in Figure 31: View program instance module. Edit program instance module has same functionality like module in Figure 21: Add new program instance form with additional modules to add documents and add links visible on the bottom of Figure 34: Edit program instance module. Figure 34: Edit program instance module Click on Upload document button pop up dialog on Figure 35: Upload document dialog where is possible to add new document associated with the current program instance, and which will be visible in documents table in Figure 34: Edit program instance module and Figure 31: View program instance module. 54