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 elearning 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
Session-Semester
20092010-2
20092010-1
20082009-2
20082009-1
20072008-2
Date Period
Total Hits
2009-12-14 / 2010-03-28
21518
2009-07-06 / 2009-10-18
33604
2008-12-29 / 2009-04-12
34028
2008-07-07 / 2008-10-26
39067
2007-12-31 / 2008-04-13
27349
Highest Hits/Day
1934 (2009-12-14)
3776 (2009-07-06)
3826 (2008-12-30)
5080 (2008-07-07)
2454 (2008-01-01)
Table 1. Total hits for each session and semester within the study weeks
Session-Semester Student Lecturers Technical Clerical Guest Total Login
20092010-2
360
305
138
198
1598
2599
20092010-1
511
420
222
227
2469
3849
20082009-2
1084
472
101
192
1910
3759
20082009-1
1287
676
237
204
1260
3664
20072008-2
242
555
149
155
1186
2287
Table 2. Number of total login by different types of users into the system
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
Student
Session-Semester Ever Login Total Registered
20092010-2
106
1110
20092010-1
162
1169
20082009-2
417
1159
20082009-1
326
1277
20072008-2
106
1103
Technical
Session-Semester Ever Login Total Registered
20092010-2
9
19
20092010-1
9
19
20082009-2
11
19
20082009-1
12
19
20072008-2
11
19
%
9.5
13.9
36.0
25.5
9.6
%
47.4
47.4
57.9
63.2
57.9
Ever Login
47
56
71
60
75
Lecturer
Total Registered
90
92
87
102
91
Ever Login
3
3
4
3
4
Clerical
Total Registered
%
4 75.0
4 75.0
4 100.0
4 75.0
4 100.0
%
52.2
60.9
81.6
58.8
82.4
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 sessionsemester 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
Client
Web Server
Main Controller
DB
Application Components
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
^ Time & Space
Doc.
^ Curriculum
^ Lecturer
Timetable
^ Event/Date
Sess./Sem. Info.
^ Subject
^ Subject & Section
Analysis
Timetable
^ Student
^ Student
^ Lecturer
^ Current User
#Introduction
^ Subject
^ View
^ Subject
#Scope
Student Groups
^ Subject & Section
^ Manage
^ Space
#Policy
^ Space
^ Final Exam
Clash Timetable
^ Lecturer
#Guide
^ Student
^ Space List
Space Occupation
^ 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
ACD
Main Controller
LSL
Application
Components
CRP
CMS
SAC
ALM
DTRD
Figure 4: Application Logic Control Flow at Application Class and
Database Design Layers
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 databasebackend 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)