CC BY
50
UNIVERSITY ELECTRONIC MANAGEMENT SYSTEM OF DNIPROPETROVSK NATIONAL UNIVERSITY. MAIN PRINCIPLES AND FEATURES © S.V. Chernyshenko, G.V. Baranov, A. Degtyarev, V.S. Chernyshenko
Dnipropetrovs ’k National University (Dnipropetrovs ’k, Ukraine)
E-mail: svc@a-teleyort.com
The main target of the SMOOTH international project of EU Tempus-Tacis programme was designing an automation computer system of university management for Ukrainian and Russian University. The Ukrainian team was responsible for the system design for Dnipropetrovsk National University.
Enterprises and institutions automation systems typically provide such key possibilities as: standardized data sources and information inputs; data storing and representation; standardized visual documents and forms interface; managed universal directories, collections and lists of ordered data that can be searched and used freely in the system; analytical data processing and report builders; flexible navigation between a parts of the system; security and safety; scheduled automatic processing.
The main stages of projection of enterprise automation systems include: enterprise business model developing and analyzing; enterprise business logic formalization; application platform, engine and key technologies selection; application architecture projection; application code designing and testing; application operation and maintenance.
1. Computer network of Dnipropetrovsk National University, Ukraine
Dnipropetrovsk National University (DNU) is one of the leading universities in Ukraine according to the number of students (about 15000) and staff (about 1500, including 600 professors). There are 18 faculties and institutes with 104 departments in the university structure. The university provides education in 78 specialties covering all main fields of human activity. DNU has 18 studying buildings and 7 student hostels; its principal territorial distribution is represented in Fig. 1.
Fig. 1. The university campus and its computer network
DNU is quite a difficult object for the automation both from territorial and organisational sides. Taking into account the complex management structure, the main idea of improving university management in DNU is considered as creation of a full-scale computer network and optimization of information flows in it. A big distance between university buildings creates a possibility to design multi-server hierarchical structure of the network. DNU built special fibre-glass connections between the main buildings; local networks are based on the twisted-pairs technology. The computer network has only one Internet portal, DNS, firewall and so on. The principal scheme of the network is shown in Fig. 2.
100 Mbit/c optical fiber connection
100 Mbit/c TP connection
NS, proxy OMSCI server
I
Another servers <
Applications hosting Windows 2000, IIS 6, MS-SQL, Apache, PHP
Fig. 2. The key principles of the DNU network topology
The architecture of the DNU network is distinguished by the following characteristics:
• TCP/IP-oriented LAN and WAN network technologies.
• Virtual LAN IP addresses and connection to the Internet through the proxy server only.
• One Internet service provider (ISP).
• One Central Internet node.
• Independent connection of each university building.
• Optical fibre connections of all buildings.
• One data server per each faculty or department
• The main border gateway (router/switch/converter) under Red Hat Linux.
• The e-mail, news, ftp, irc server, user accounts server under Free BSD Unix.
• The main web server under Red Hat Linux, apache.
• DNS and proxy servers under Free BSD Unix.
• COMSCI faculty server under Windows 2000 server, Active directory Domain controller, IIS, ASP, MS-SQL server, Net framework, Apache, PHP, Java server, users account and faculty LAN services server software.
• SMOOTH project server under Windows 2003 server, IIS, ASP, MS-SQL server, Net framework, Apache, PHP, Java etc...
2. University Electronic Management System
On the basis of the organised network a special managerial computer system has been elaborated under assistance of the SMOOTH project. We called it “University Electronic Management System” (UEMS).
The main objectives of UEMS are as follows: storage of all essential university data at the central server; operative providing decision makers with all necessary information; optimisation of information flows in the network; automatic preparation of the formal documentation. The main requirements to the system composition are the following: web-interface and remote access possibility; distributed data storage; simple modernisation of the system; high level system security; possibility of user profiles generation.
We selected the web interface as the main software technology, which is characterised by such positive peculiarities as minimal requirements to client hardware; no additional software needed (internet browser and text processor only); server-side software updates absolutely transparent for users; worldwide access.
The modern Internet environment was selected also for internal network environment, so the system is based on Intranet. We used client-server principles, the World Wide Web interface, and other technologies, associated with the Internet: web-servers; universal web clients; SQL database servers; Internet network communications; open data representation technologies, protocols and formats; open data processing libraries and network tools.
The key features of the World Wide Web technology, which can be effective in the enterprise automation engineering:
• Internet Application Architecture (IAA) and Web Application Architecture (WAA) as a standard.
• Open script sources and libraries.
• Powerful interfaces for all known Internet client-server systems including data storing, communications, searching and archives.
• Powerful libraries like network communications, operating systems, user interfaces controls and classes, raster and vector graphic, streaming data processing, encrypting, and others.
• Universal browser client’s technologies.
• Universal open data representation and structural formats like HTML, XHTML, XML, DML, VML, UML, open binary documents formats like PDF, and so on.
• Full client support under all most popular and well known operating systems.
The internal architecture of Multi-user Enterprise Management System (MEM), on the basis of the IAA and WAA technologies, consists of three main parts:
• Input (generalization of the data inputs, formats and data pre-processing, like HTTTP methods GET and POST, cookies, environmental and files sources).
• Processing (all operations with data, including database, file, network and other operations and the output content generation).
• Output (sending content header and data to the client and closing the network connection)
Code subdividing architectures include procedural, module, and mixed approaches.
Distributed database architecture of WAA engines and solutions will be used:
• Data storing systems (SQL servers, file and other data sources like ODBC drivers).
• Data schema structure (location and relations of databases, tables, fields and stored procedures).
• Subdividing the application on central or main server and local remote office parts, probably with different data storing engines (for example SQL server and file data source or ODBC can be used in one system corresponding in the main server and local office server).
• Data synchronization and load balancing principles and technologies (mirroring and clustering).
• Database schema and data security on the application level (application level developer database access secured API)
Mirroring, a most popular data synchronization and load balancing architecture, is selected (Fig. 3).
Web Server 1 Web Server 2 Web Server N
V
Fig. 3. The scheme of mirroring
The selected software instruments:
• Server platform (operating system) - MS NT-based OS (NT, XP, 200x).
• Web server - MS IIS web server (supplies with OS).
• Database engine - MS Jet (Access) for local servers and MS SQL server for central one
• Server side script language - ASP server-side technology.
• Client side script language - JavaScript as client-side script language.
3. Logical structure of UEMS
The hierarchical structure of UEMS is determined not only by territorial distribution, but also by organisational structure of the university management, by “administrative distance” between university divisions. Some corresponding principles are illustrated in Fig. 4.
The organisational structure should be reflected both in the database and programme interface. At first general question, appeared of the system, is the organization of the database, which one could put on either in general, or for every faculty own, local ones. We propose a special approach, when during the day faculties work with their local copies in the faculty servers, but during the night they are synchronised with the main university database in the central server (Fig. 5).
The level of security of the central server is essentially higher than that of the local ones, so the limitation of the direct work with it guarantees a reliable storage of the data. During the night the network traffic is low, and software environment was optimized so access to the server becomes faster.
UEMS is organized as an entire set of relatively independent modules and each of the modules performs a definite task or a set of similar tasks.
Fig. 4. Organisational structure of the DNU network
m ran □ □ □
Local bases
Central base
I----1 Students and curricula data
----- separately for each faculty
I----1 All other operating data
----- the same for all divisions
Fig. 5. Database storing concept
Internal logical structure of the system can be represented by several programmes: student database and interfaces; staff database and interfaces; “curricula” database and interfaces; retrieval information system; system of database presentation at the university site; “Virtual University”, an interactive system of the Internet presentation of teaching materials.
The programme interface reflects the annual cycling character of the university life. Correspondingly, the UEMS has the following separate interfaces (“steps”): 1. new academic year (summer-autumn); 2. new semester; 3. semester; 4. new academic year preparation (spring); 5.examinations; 6. retrieval sub-system. An example of the interface is represented in Fig. 6.
Ц Автоматизована система "Деканат” - Microsoft Internet Explorer
J File Edit View Favorites Tools help ІГ^іИ
J Ф1 Back t ^ t ijjj g] (Ц Search [|j Favorites 0 History | gf т gj ^
J Address |@ http ://localhost/dnu2/index. asp ^j if^Go [ Links w|
Дніпропетровський національний університет employee
|£j Done Local intranet
:^0Start 'Jl 0 Еїд] If 0 ;3’ Щ{D:\work\Pr,,,| [e]MicrosoftP,,, |f^Автомати... ^Jasc Paints,,,) | j Desktop ” ^4t: 8^1*030 16:41
Fig. 6. Example of the general program interface (step 1)
Let us characterise sub-steps of the main steps.
Step 1. New academic year (summer-autumn) - orders of moving up into the next year of study or admission to the 1st year of study; forming of groups; students personal data input; generation of the lists of new students; preparation of graduation documents; practical training reports.
Step 2. New semester - redistribution of the teaching load; data preparation for timetable composition; studying timetable composition.
Step 3. Semester - blank templates printing; preparation of orders; table of the students’ list change; teachers’ work with students’ personal data; preparation of the academic certificate.
Step 4. New academic year preparation (spring) - perspective curricula for bachelors, specialists, masters; working curricula; reports of departments readiness; assignments on teaching load.
Step 5. Examinations - exam timetable preparation; generation of lists of students for an exam; input of exam results; summary register of lists of students for groups; statistical analysis of exam results; orders of exclusion, for scholarships.
4. Curriculum preparation and correction
Let us consider, as examples, a few special parts of UEMS, and start from the programmes for preparation and correction of a study curriculum.
UEMS should serve as an efficient tool for the arrangement of the curriculum. If earlier this was put together by means of Excel and different other aids, now a web-based application should be responsible for this. As it had been expected, we confronted with different problems and difficulties connected with planning and production of the software. There were several solution attempts. Be-
sides, till present new ideas have come up, so that we must be ready constantly to integrate the changes.
Our purpose is modelling of the curriculum and on its basis modelling of the outgoing working plan. Besides, should become systematically gone forward to maximize the working efficiency. Alexander Rostilov and Leonhard Detzel, SMOOTH participants from the University of Koblenz-Landau, took part in rearrangement of the modules on ASP.NET and C#, as well as the export of the data in Excel for the wide treatment and for printing out of the curriculum. The corresponding graphic screen form is shown in Fig. 7, and more traditional table presentation is in Fig. 8.
The production of the plan is finished with the help of the web forms, which the user fills according to the previously agreed rules. Thus insists for him on selecting the possibility from the available disciplines, or on providing a new discipline. At the same time the inputs should be checked, corrected if necessary, or be pretended. The programming of the web forms, which should allow the production of the curriculum to the user of the system, included the definition and the integration of certain rules after which should be approached. Thus, for example, the user first of all, should determine the number of hours per semester, which will be maintained by the production of the curriculum. If this number falls short or is crossed, the system reacts with an error message. Validation should also provide for the error messages if a wrong value is given, e.g., text instead of a number.
After entire filling of the forms and based on this inputs, first of all a graphic representation of the simplistic curriculum is indicated, which shows the lecture types and contains information about lab hours, a training period, lectures and a kind of exam. Besides, it explains the fissures of the table, which was originating in this manner, the semesters in which the before selected lectures are put down. The lecture types are shown to the better overview in a colour code so that all lectures which belong to the same lecture type are indicated in their own colour.
Furthermore, the graphic representation (Fig. 9) shows the possibility of the correction and the balance of the lecture hours about all semesters, as well as the registration of the new disciplines. This occurs with the help of the web form which is directly about the graphic representation and also allows selecting the disciplines which were stored before in a .csv-file.
Fig. 7. Graphic presentation of a curriculum
Fig. 8. Table presentation of the curriculum
^_________________________________________________________________________________________________________^Jnjxj
Open | ReDraw |
12004 “EH iHtfiopMaTMKa ^ |Linear algebta pi 3 fl fl [o fl
Fig. 9. Process of curriculum formation
Now a certain sort of algorithm which distributes the given disciplines to semester is used. Besides, the priority values which are determined for every field especially are selected from the database. The distribution should automatically take place on all 8 semesters, so that a certain current value per semester is not crossed.
The correction of the curriculum in the graphic representation takes place through clicking the respective discipline. As a result this is displayed in the web form, with the actual settings for the selected lecture, about the table. Now there is a possibility to determine the duration of the discipline, as
well as the semester in which this should take place as well as to adapt the remaining information (lab hours, training period, exam kind), or to change.
Thus, the semester hours number is the sum of all lecture hours in a semester which is identical for all semesters shown with a horizontal line under the table, so that one also has an optical border by which one can orientate himself by the timetable production or correction in the graphic representation.
For the graphic representation we also plan the introduction of two buttons in every discipline, with which one can extend or shorten the duration of the respective lecture. In addition, an announcement with the actual semester hours number is planned, so that the user will still have another further control, as well as a better overview by the planning of the hours. Perhaps, an error message will occur if too much or not enough semester hours are chosen and ask the user to change this setting.
A previously planned function with the help of which one could adapt the hourly number of the respective discipline by the drawing with the mouse, was rejected for the time being, because from our viewpoint the introduction of the buttons would be completely sufficient and also a simpler and better alternative for this.
Of course, one has a possibility to return to any mode at any time. With the help of the present inputs, as well as the data being in the database the final curriculum is provided. On the basis of the curriculum the working plan for the current year is automatically provided. This is not changeable. Should the working plan be changed, nevertheless, this can happen only about the change of the curriculum.
5. Searching and statistical subsystems
An important additional part of UEMS is the information, searching and statistical module. Examples of module interfaces are represented in Fig. 10, 11. Let us have a look at the group of the statistic modules, or the modules of statistics, as they are also called. The purpose of every statistic module is getting some statistic data that suit a set of given conditions in a definite output format.
Fig. 10. The interface of the information and searching system
Fig. 11. Personal data of a student (the information and searching system)
The parameters of request to a module for getting responding data, structure and format of output data are determined by a concrete problem. That can be, for example, getting the quantity of every kind of mark got inside the groups of current faculty within pointed examinations, or calculating average progress of that or another group of current faculty within the whole period of studying, or, finally, getting all the marks and total average progress of every student of a stated group within a stated studying period.
As a rule, the format of output data is based on an official form that is used in the work of the dean’s office. But in some cases it is necessary to get some additional data in a comfortable format. Most of such cases are also provided: a user is given a possibility to select values of as many parameters as possible according to the data security requirement and the way of formulating the task of the module.
The resulting data can be useful information in making decisions. It means that as a result of further data processing a definite summary can be made and appropriate measures can be taken relatively to the analysed aspect of the work of the dean’s office.
The main purpose of 'Statistics of teachers' module is providing the possibility to get full information about marks put by a definite teacher to students of a definite group for a definite discipline within stated examinations. In case of successful authorization in the main module and successful definition the current faculty by this module, there appears the result of starting call of this module in the working frame. The content of the working frame is shown in Fig. 12.
The user is to point wanted examinations with selecting the appropriate academic year and kind of examinations (winter or summer) in the form. In addition to that, the user is given the possibility to choose the categories he wishes to output the statistics in. By default all the checkboxes inside the 'Statistics' field-set are checked, so the statistics in this case will be displayed in all of the three available categories: teachers, groups and disciplines. Pushing the 'Clear form' button will lead to clearing the fields for academic year and examinations kind and setting the default values for the checkboxes.
Fig. 12. The working frame of the statistical module
If all the required parameters (such as academic year, kind of examinations and at least one category) are stated, pushing the 'Display statistics' button will be followed by making the appropriate request to the server program. Otherwise there will be displayed a message about the absence of required data in the form. If there is at least one record regarding the mentioned examinations at current faculty found in the server database, the responding statistics will be calculated in the mentioned categories and the result will be sent to the client. After that the table in the lower frame will be filled with resulting statistics. Also there will appear the 'Print ' button at the bottom of the table - when the button is clicked, the table is printed. If there are no appropriate records in the database, the appropriate message will appear and the content of the lower frame will include only the full caption of the resulting table.
The structure of the caption of the table is quite simple: the leftmost column is the ordinal number of a record, then there are columns for the values of mentioned categories, the further four columns are for the quantities of the kinds of marks (those are fives, fours, threes and twos), and, finally, there are three columns for the quantities of absences without valid reasons, absences for valid reasons and quantities of students who were not allowed to take examinations.
It is worth saying that indicating the categories has an influence just upon the output format: in fact the work is performed with the same data, so the sums of the values in every column for quantities of marks for the same examinations are constant and do not depend on selected categories.
The resulting data can be used to compare progress of groups. In addition to that, basing on statistics of teachers and groups and considering statistics only of groups’ user can assess objectivity of that or another teacher. For instance, if a group is totally weaker according to the statistics of groups but according to the results of the examinations that group gets on average higher marks for disciplines taught by some other teacher, than a stronger group, there can be raised a question about the objectivity of that teacher.
Basing on statistics of disciplines we can see which disciplines are studied better by students. This information can be useful when some curricula or timetables are being created. Statistics of groups and disciplines can be utilized in assigning students to special directions.
Results, computed by the program, cannot be the only basis for taking a decision; however, they can be a useful additional tool. Other means and information should be considered additionally to the suggested statistics, and only after a full detailed analysis of all the obtained results the decision can be taken.
Now 'Statistics of students' module is being developed. This module is to simplify getting a list of students who are going to get a diploma with honours. Usually this process is accompanied with raising a lot of examination lists, looking through them for every student and checking whether their marks let them get a diploma with honours. The check includes calculating the average progress, a quantity of “threes” and re-examinations of every student. Performing that task manually by one man requires a high level of concentration and huge amount of time. In addition to that, the probability of
making a mistake is quite high. After considering all those arguments, it appears very useful and necessary to create a module that will fully solve the problem.
The module is to provide the possibility to show marks in all the disciplines and calculate average progress of every student of a definite group or entire faculty. Also there must be provided a possibility to show the data just of those students who can still obtain a diploma with honours by showing the examinations that must be re-taken, and students who cannot obtain a diploma with honours in any case by showing marks which do not meet the requirements for obtaining a diploma with honours.
Both modules are created on the basis of ASP (Active Server Pages) technology. At the beginning the user makes a request to the server so as to get some ASP-page; if provided, the user sets some parameters in the forms on the page. When the server receives the request, it starts interpreting server scripts built in the code of the ASP-page. Those server scripts are mixed with a ready HTML-code. After performing, the scripts are replaced with white symbols and a ready HTML-page is got. Then the processed page is sent back to the client’s browser and the user gets the result of processing the ASP-page. All of that is meant to provide the possibility to create Web-pages with dynamic content. The content of the page can depend on data that are taken from the database located at the server when the server scripts are being interpreted and that are processed according to the parameters set in the forms.
In 'Statistics of teachers, groups and disciplines' module the identification parameters of examinations are passed as a set of parameters and the data about the examinations at the current faculty are received from the database located at the server. The database is a MS Access database and work with it is based on ADO technology. Selection of required data is performed by appropriate SQL requests. In ASP technology the default script language is VBScript but for creating the two modules JavaScript was chosen as both server and client script language.
UEMS is a complex rapidly developing system, so we described Now UEMS system is being converted into .NET platform. That includes using ASP .NET as a base server technology and writing all the server programs in compiled programming languages with strict type checking (such as C# or VB .NET). According to the specifications of .NET platform that is to increase the total speed and security level of the system.
Conclusion
only several of its aspects. Thanks to the Tempus programme it was possible to intensify the work and to collect very important EU experience. At the same time the project even during the Tempus project time has demonstrated its sustainability, and we are sure that its development will be still continued after the project ending.
Поступила в редакцию 15 октября 2006 г.
