FSKSM Online Timetable Application (Architecture and Design Pattern)

1. Application Background

• General Information & Development History• Usage Statistic• Platform

1. 1 General Information & Development History

• Used as a support and adds-on services to university’s e-learning system

• Limited at faculty (FSKSM) level with main focus to handle time table and space management (labs, classrooms, & lecture halls) correspond to teaching & learning activities such as classes, labs, exam and other academic/non-academic activities

• Development was started in 2002, begin tested in 2003 until 2004 and then fully publish to end-users by second semester in 2005

• Until now the application is still actively used and there are more new functions have been added

• The most recent and featured function added is fully computer aided final exam timetabling

1.2 Usage Statistic

Table 1. Total hits for each session and semester within the study weeks

Table 2. Number of total login by different types of users into the system

Session-Semester Student Lecturers Technical Clerical Guest Total Login20092010-2 360 305 138 198 1598 259920092010-1 511 420 222 227 2469 384920082009-2 1084 472 101 192 1910 375920082009-1 1287 676 237 204 1260 366420072008-2 242 555 149 155 1186 2287

Session-Semester Date Period Total Hits Highest Hits/Day20092010-2 2009-12-14 / 2010-03-28 21518 1934 (2009-12-14)20092010-1 2009-07-06 / 2009-10-18 33604 3776 (2009-07-06)20082009-2 2008-12-29 / 2009-04-12 34028 3826 (2008-12-30)20082009-1 2008-07-07 / 2008-10-26 39067 5080 (2008-07-07)20072008-2 2007-12-31 / 2008-04-13 27349 2454 (2008-01-01)

1.2 Usage Statistic

• In term of total hits as shown in Table 1, the highest total hits recorded is in semester 1 session 2008/2009 with 39067 hits within 112 days give a rate of 348 hits per day

• The highest hits number per day is also in 20082009-1 with 5080 number of hits an have around 3.5 hits for each minute

• All the highest hits per day happen at the very beginning of each session-semester days and this is a natural behavior in academic/campus life

• Looking at these scenarios we recognize that performance issues related with enormous number of users access will not very significant to the current system

• This is based on fact that high performance web site normally will have more than a millions of hits per day or even a hundred thousand in a single minute

1.2 Usage Statistic

• Table 2 clearly shows that the anonymous users (user type Guest) contribute to most total login in each session and semester

• Referring to the case study application, it demonstrates how system policies that provide an open view to as many as possible application resources defined as public can help increase users participants

• There many other online systems in our organization that don’t have this open view features to the anonymous visitors

• This situation is normal since developing any kind of applications that support more than single users with multi level roles and access is the most difficult and challenging task even for most experienced developers

1.2 Usage Statistic

• One of easier approach is by separating each types of users to different logical system spaces though they may refer to the same data resources

• In client browsers this will end-up with the application separating their users into different login pages and URLs

• Consequently, in most cases, anonymous or prospective users are frequently ignored thus don’t have any single privilege to access application resources though many of these resources are highly possible to be a public if referred to organization’s IT policies

1.2 Usage Statistic

Session-Semester Ever Login Total Registered % Ever Login Total Registered %20092010-2 106 1110 9.5 47 90 52.220092010-1 162 1169 13.9 56 92 60.920082009-2 417 1159 36.0 71 87 81.620082009-1 326 1277 25.5 60 102 58.820072008-2 106 1103 9.6 75 91 82.4

Session-Semester Ever Login Total Registered % Ever Login Total Registered %20092010-2 9 19 47.4 3 4 75.020092010-1 9 19 47.4 3 4 75.020082009-2 11 19 57.9 4 4 100.020082009-1 12 19 63.2 3 4 75.020072008-2 11 19 57.9 4 4 100.0

Student Lecturer

Technical Clerical

Table 3. Number of different users types ever used or login into the system

1.2 Usage Statistic

• Type of users that mostly benefited from the system are implied in Table 3

• Users with type of student are the lowest that participate in using the system though they have the highest number registered in the system

• This can be further proved by looking at the fact that students will only used the system as read-only users which likely has the same level of access as a guest type user

• The only benefit they can get when logging as a student is to have the facility to view information that only related to their profile for example their own timetable view sheet

• This also explain why guest type users have higher login number as listed in Table 2 as it’s strongly believe that many of them (students) log into the system using guest type user profile

1.2 Usage Statistic

• Lecturer type users showing quite better participation with more than half of them ever using the system in each session-semester since 20072008-2

• It has been expected and parallel with our motivation when developing the system which is to solve the problems complained and faced by the lecturers when managing their academic timetable slot manually support by technical and clerical staffs

• On the other hand, technical and clerical staffs becomes the most benefited users with this situation where half of the previous manual task has been distributed to the lecturers

1.2 Usage Statistic

• We present application usage statistic here as it can adequately describe some of the characteristics of domain problem solved by the application

• Able to understand and explain the real application characteristic also give us significant and valuable facts to support the rationale behind the proposed architecture and design pattern within the system

• Though the system doesn’t exhibit a high performance web application (high number users access) but it’s very valuable in term of solving one of most complex business activity within the organization (FSKSM)

1.3 Platform

• Application currently run in LAMP platform

• The acronym LAMP known as an open-source solution which incorporating together the operating system (Linux), web server (Apache), database application server (MySql), and dynamic scripting languages (Perl, Python, PHP) to provide full stack system infrastructure and facilities for web based application development

• LAMP is well known for its low cost and reliable solution for hosting web based applications

• Using standard CGI programming run in Perl/Python or server pages technology (PHP) LAMP provide less complex platform if compared to other such as J2EE

1.3 Platform

• One of its scripting language (Perl) is undoubtedly among the most establish dynamic language with abundance support modules repository available at CPAN

• All above motivate us to choose LAMP besides the reason that it’s the platform that has been long served and maintained in our organization

2. General Architecture

Web Server

Main Controller

Client

Application ComponentsDB

View Templates

Figure 1: Application General Architecture

2. General Architecture

• Client & web server communicate using standard HTTP protocol mainly using POST/GET methods

• Application main controller is invoked by web server via standard Perl CGI script (index.cgi)

• This Perl script act as a main executable script with its other main task is to instantiate core application modules to support database connection, CGI data processing, session handling, and users access logging

• Except for View Templates, all entities are dynamic & active by the way that they are calling other entities for services and may return some values to the calling entities

2. General Architecture

• View Templates are static entities since they are only used inside Application Components to layout page presentation views

• Template engine logics are embedded inside Application Components and used simple-generic text processing to produce new dynamic content based on layout defined in View Templates

• Application Components act as a higher level interface that provide standard class/module implementation for most generic application domain solutions such as link management, authentication, and database operations

2. General Architecture

• Application Components are supported by core application libraries/APIs that provide most basic functions such as CGI data handling, database connection, and view template processing

• Main Controller itself actually is one that fall in Application Components category but with special more complex business logic and unique features

• Main Controller and standard Application Components used DB resources in different perspective

• Main Controller use information from database tables as a main resource for application generic controls and logics while other standard Application Components might also do the same but most often they use it to solve problems defined within application domain

2. General Architecture• Generally, Main Controller core tasks is to instantiate

application modules (Application Components) that mapped with current selected link node and its structure, assigning parameters to instances , and call its methods

• Other Application Components modules essentially used to solve and provide services related to application domain problems

• Application Components can either be used directly or via sub-classing (inheritance) if particular business problem in application domain requires customization

3. Application Design

• Links• Database

3.1 Links

* Root

Doc.

Sess./Sem. Info.

^ Curriculum

^ Subject

^ Lecturer

^ Student

Timetable Analysis

^ Event/Date

^ Current User

^ Subject

^ Space

^ Final Exam

Timetable

Student Groups

Clash Timetable

Space Occupation

#Introduction

#Scope

#Policy

#Guide

^ View

^ Manage

^ Subject & Section

^ Student

^ Lecturer

^ Time & Space

^ Subject

^ Subject & Section

^ Space

^ Lecturer

^ Student

^ Space List

^ Time Slot

^ Result

Figure 2: Link Hierarchy Structure

3.1 Links

• The *Root link node is only for the purpose of conceptual & logical view of the link structure

• It will not appear as a tangible entity (as a link text/label) in the application presentation elements

• By default the application will point to the link node: *Root -> Doc. -> Introduction ; after users login into the system

• Link nodes name that start with ‘^’ character are an end-point nodes where the core application domain business process executed

• These end-point nodes are mapped to specific Application Components that solved particular business problems and will instantiated by Main Controller

3.1 Links

• End-point nodes name that start with ‘#’ are used for displaying static content where in our case study application they are the application documentations

• All other parent nodes are mainly purposed for information categorization to provide high level view of services available in the application.

• Some of them may also used to map other standard miscellaneous Application Components to provide generic application functionalities

3.1 Links

• All link nodes displayed in the link hierarchy is the main link that build up the main navigation structure of the application

• This main navigation structure is stored inside the database tables together with its association to other application resources such as static files, application modules, and application parameters

• We will explain all above in more detail in the database design section

• Other link nodes exist beneath these main link nodes might generated dynamically by Application Components and its sub components

3.2 Database

• Following general application architecture as explained in section 2 (Main Controller and Application Controllers) that use database resources (tables) with different purposes, database tables are grouped into two main categories

• One group of tables are designed correspond to application specific domain problems requirements and the other one are dedicated to support general application logic and control

• There are currently 24 tables used within the application domain problems scope and 17 tables for application logic and control

• In this section we will only explain and discuss the second type of tables design as it’s one of the core element that lead to the application design pattern

3.2 Database

Figure 3: ERD to Support Generic Application Logic & Control

3.2 Database

• Figure 3 is the ERD extracted from current database tables design embodied within the application

• Reverse engineering approach was used in the process of extraction

• The steps are involving the procedures to dump all related tables structure from the MySQL database application server

• MySQL Workbench from mysql.com was used as a tools to read back all dumped tables structure and then display them in ERD graphical view

• The table relationship reconstruction was done manually with the help of tools provided within MySQL Workbench

• For simplicity only primary and foreign keys are shown in the ERD and it’s enough to help explain the tables design

3.2 Database

• There are some difficulties when try to interconnecting tables relationships due to some bad practices in the database tables design implemented at the beginning of application development task

• Many of tables relationships are connected by using keys with inconsistence naming scheme

• Inconsistence naming scheme also happen among tables that have relationship

• There are also table that requires better normalization form to achieve more efficient data organization in the application

• However, besides all these lack and weakness, the overall design has been proved useful and applicable within the application domain problem scope and has no serious error that badly affect the application in term of functionalities

3.2 Database

• As shown in the Figure xxx, tables relationship are further divided into other four subsections (SAC, ALM, LSL, CRP, and CMS) correspond to its roles in the application

• Full phrase of abbreviations used in each table design subsections are as follows: SAC – Security and Access Control (authentication & session) ALM – Access Log Management (accountability) LSL – Link Structure Logic (main links structure) CRP – Components Runtime Parameters (runtime logic) CMS – Content Management System (document publishing)

• Using these subsections information can help us deeply understand the overall design by the way that it further categorized the design information into smaller scope for easy design analysis

3.2 Database

• It’s important to note that there are tables which have overlapped post across several design subsections or in other word have multiple roles in supporting generic application requirements

• The tables and their overlapped roles : link_reference (LSL, CMS and LSL, CRP) dyna_mod (CRP, SAC) user and session (SAC, ALM)

• link_reference table is one that shown uncommon overlapped features due to the fact that it requires better normalization

• It used the foreign key fk_ref_name to refer both file_name in blob_info table and dyna_mod_name in dyna_mod table

3.2 Database

• Tables overlapped roles exhibits the bound of application logic control and can be captured by rearrange back the set of overlapped subsections as follows: (LSL, CMS) & (LSL, CRP) => CMS --- LSL --- CRP CMS --- LSL --- CRP & (CRP, SAC) => CMS --- LSL ---

CRP --- SAC CMS --- LSL --- CRP --- SAC & (SAC, ALM) => CMS ---

LSL --- CRP --- SAC --- ALM

• As discussed in section 2, Main Controller will instantiate other Application Modules base on current selected link node and its structure information

• This link structure information is gathered by manipulating LSL database table design subsection

3.2 Database

Main Controller

Application Components

LSL

CRP

ALM

CMS

Figure 4: Application Logic Control Flow at Application Class and Database Design Layers

ACD

DTRD

SAC

3.2 Database

• Base on application logic control bound captured previously, the basic flows of application logic control are as depicted in Figure xxx

• Its show how Main Controller and Application Controllers manipulating each database tables design subsections to cover most basic and generic web application logic control requirements

• In general the application used two different design layers to maneuver the control flow mechanism which are the application class design layer (ACD) & database tables relationship design layer (DTRD)

• At the ACD layer, application modules/classes are responsible to indirectly providing application logic control by using information acquired from LSL design subsection within the DTRD layer

3.2 Database• It’s done directly by Main Controller or indirectly by other

Application Components• Following general application architecture explained in section

2, Application Components themselves normally are invoked by Main Controller

• Next, after application logic control gathered from LSL and become available at the application runtime, the control flow will move on either to CMS or CRP SAC ALM control flow

• The application will use CMS resources for static content publishing

• For example in the current application there are system usage policies description and application documentation itself

• CMS design subsection plainly provide a simple content management system services within the application

3.2 Database• In the other hand CRP, SAC, and ALM subsections provide

resources to support core application services involving database access functions and more complex domain business logic

• CRP design subsection mainly purpose for Main Controller to assign parameters to Application Components at runtime and accidentally enabling the principle of CBSD via black box approaches

• As in many web applications and also the same with current selected case study application, it’s unavoidably that the application must provide a service for different types of user with different roles within the system

3.2 Database

• All these requires some logical mechanism for application resource usage control and monitoring that including the application classes/modules and database tables rows and items

• SAC and ALM tables design subsections are introduced to cater with all these requirements and it’s an indispensable part that must exist in most multi users web database-backend applications

• Details on each subsections tables design (LSL, CRP, SAC, ALM, and CMS) are given in the next subsections

3.2.1 Link Structure Logic (LSL)

3.2.2 Content Management System (CMS)

3.2.3 Components Runtime Parameters (CRP)

3.2.4 Security & Access Control (SAC)

3.2.5 Access Log Management (ALM)