FSKSM Online Timetable Application (Architecture and Design Pattern)

1
FSKSM Online Timetable Application (Architecture
and Design Pattern)
2
1. Application Background

• General Information Development History
• Usage Statistic
• Platform

3
1. 1 General Information Development History

• Used as a support and adds-on services to
  universitys 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

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

6
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 dont 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

7
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
  dont have any single privilege to access
  application resources though many of these
  resources are highly possible to be a public if
  referred to organizations IT policies

8
1.2 Usage Statistic
Table 3. Number of different users types ever
used or login into the system
9
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 its
  strongly believe that many of them (students) log
  into the system using guest type user profile

10
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

11
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 doesnt exhibit a high
  performance web application (high number users
  access) but its very valuable in term of solving
  one of most complex business activity within the
  organization (FSKSM)

12
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

13
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 its the platform that has been long
  served and maintained in our organization

14
2. General Architecture
Web Server
Client
Main Controller
Application Components
View Templates
Figure 1 Application General Architecture
15
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

16
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

17
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

18
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

19
3. Application Design

• Links
• Database

20
3.1 Links
Root
Time Space
Doc.
Curriculum
Lecturer
Timetable
Analysis
Subject Section
Student
Event/Date
Timetable
Sess./Sem. Info.
Subject
Student
Lecturer
Current User
Subject
Introduction
View
Subject
Student Groups
Subject Section
Scope
Manage
Space
Space
Policy
Final Exam
Clash Timetable
Lecturer
Guide
Student
Space List
Space Occupation
Time Slot
Result
Figure 2 Link Hierarchy Structure
21
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 -gt Doc. -gt 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

22
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

23
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

24
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 its one of
  the core element that lead to the application
  design pattern

25
3.2 Database
Figure 3 ERD to Support Generic Application
Logic Control
26
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 its enough to help explain
  the tables design

27
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

28
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

29
3.2 Database

• Its 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

30
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) gt CMS --- LSL --- CRP
• CMS --- LSL --- CRP (CRP, SAC) gt CMS --- LSL
  --- CRP --- SAC
• CMS --- LSL --- CRP --- SAC (SAC, ALM) gt 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

31
3.2 Database
ACD
Main Controller
LSL
Application Components
CRP
CMS
SAC
DTRD
ALM
Figure 4 Application Logic Control Flow at
Application Class and Database Design Layers
32
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

33
3.2 Database

• Its 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

34
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,
  its unavoidably that the application must
  provide a service for different types of user
  with different roles within the system

35
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 its 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

36
3.2.1 Link Structure Logic (LSL)
37
3.2.2 Content Management System (CMS)
38
3.2.3 Components Runtime Parameters (CRP)
39
3.2.4 Security Access Control (SAC)
40
3.2.5 Access Log Management (ALM)