CDSER: CATALOGING DATASETS FOR SOFTWARE ENGINEERING REPOSITORIES A Project

CDSER: CATALOGING DATASETS FOR SOFTWARE
ENGINEERING REPOSITORIES
A Project
Presented to the faculty of the Department of Computer Science
California State University, Sacramento
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
Computer Science
by
Uday Kanth Chintala
FALL
2012
© 2012
Uday Kanth Chintala
ALL RIGHTS RESERVED
ii
CDSER: CATALOGING DATASETS FOR SOFTWARE
ENGINEERING REPOSITORIES
A Project
by
Uday Kanth Chintala
Approved by:
__________________________________, Committee Chair
Du Zhang, Ph.D
__________________________________, Second Reader
Ying Jin, Associate Professor
____________________________
Date
iii
Student: Uday Kanth Chintala
I certify that this student has met the requirements for format contained in the University format
manual, and that this project is suitable for shelving in the Library and credit is to be awarded for
the project.
__________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D
Department of Computer Science
iv
___________________
Date
Abstract
of
CDSER: CATALOGING DATASETS FOR SOFTWARE
ENGINEERING REPOSITORIES
by
Uday Kanth Chintala
The purpose of CDSER is to improve the software productivity and quality. As the software plays
an important role in businesses and various fields, mining the software data and analyzing it later
on by the experts will help in prediction and improvement of the quality and productivity of the
software in future. It’s difficult for the researchers to get all the relevant data at one place to do
their research so the main idea of this project is to lead all the interested researchers in software
engineering domain to a single location where they can find all the information and data related to
software engineering projects organized in a certain way which will reduce the work of searching
various sources for obtaining the relevant information and data.
My project is to collect data from various open source projects and software engineering
repositories, identify the common attributes if any for the datasets, provide a clear explanation of
the attributes used in the datasets, give the references of who used the datasets and for what
purpose, provide the actual data of the software engineering projects and finally create a web
interface for the user in an organized way.
v
In this project, we will explore how the user restrictions and access controls can be enforced
using a Content Management System (CMS). Drupal is one of the powerful CMSs where a
developer has to integrate various modules with core modules and configure them as per the need
of the system. We will focus on effective use of Drupal for managing users and to develop a
system that helps researchers to find relevant data at one place.
HBAP [1] site provides a similar functionality as CDSER but it provides information and data
relating to only ADA language, my project on the other hand provides information relating to all
the software engineering projects and software engineering data repositories. For future
researches, the CDSER system can be migrated to smart-phone or tablet devices. Nowadays
smart-phone platform is picking up the market. So it will be an added advantage to the system if
it is also configurable for smart devices. Another enhancement to CDSER could be adding as
many software engineering projects as possible and automating the process of collecting data.
, Committee Chair
Du Zhang, Ph.D
______________________
Date
vi
ACKNOWLEDGMENTS
I am heartily thankful to my advisor, Dr. Du Zhang, whose encouragement and guidance from the
beginning to the final level enabled me to design and implement CDSER.
I also thank Prof. Ying Jin for her precious time, and all the people who supported me in any
respect during the completion of this project.
vii
TABLE OF CONTENTS
Page
Acknowledgments.......................................................................................................................... vii
List of Tables ................................................................................................................................. xii
List of Figures ............................................................................................................................... xiii
Chapter
1. INTRODUCTION ....................................................................................................................... 1
1.2. Scope of CDSER................................................................................................................... 2
1.3. Roles ..................................................................................................................................... 2
1.4. Related Work ........................................................................................................................ 2
2. BACKGROUND ......................................................................................................................... 3
2.1. WAMP Server and MySQL Database .................................................................................. 3
2.2. Open Source CMS Drupal, Modules, Plug-ins and Libraries ............................................... 4
2.2.1. Available WCMS ........................................................................................................... 4
2.2.2. Drupal ............................................................................................................................ 5
3. REQUIREMENT ANALYSIS .................................................................................................... 7
3.1. General Description .............................................................................................................. 7
3.1.1. User Characteristics ....................................................................................................... 7
3.1.2. Functional Requirements ............................................................................................... 7
3.2. Specific Requirements .......................................................................................................... 8
viii
3.2.1. Interface Requirement .................................................................................................... 8
3.2.2. Non-functional Requirements ........................................................................................ 8
3.2.3. Data Model Diagram...................................................................................................... 9
3.2.4. Use Case Model ........................................................................................................... 10
3.2.4.1. Use Case Diagram.................................................................................................. 10
3.2.5. Typical Flow Scenario of the CDSER System ............................................................ 11
3.2.5.1. Use Case: Administrator Manages Users ............................................................... 11
3.2.5.2. Use Case: Administrator Manages Modules .......................................................... 11
3.2.5.3. Use Case: Administrator Manages the Content ..................................................... 11
3.2.5.4. Use Case: Administrator Search ............................................................................ 12
3.2.5.5. Use Case: Authenticated User Manages Personnel Information ........................... 12
3.2.5.6. Use Case: Authenticated User Manages the Content ............................................. 12
3.2.5.7. Use Case: Authenticated user Search..................................................................... 13
3.2.5.8. Use Case: Guest User Views the Content .............................................................. 13
3.2.5.9. Use Case: Guest User Search ................................................................................. 13
4. DESIGN AND IMPLEMENTATION....................................................................................... 14
4.1. Overview of CDSER System .............................................................................................. 14
4.1.1 Home Page of CDSER .................................................................................................. 14
4.1.2 Projects in CDSER ........................................................................................................ 17
ix
4.2. Database Design and Implementation................................................................................. 21
4.2.1. Tables related to Node Module .................................................................................... 21
4.2.2. Tables related to Taxonomy Module ........................................................................... 23
4.2.3. Tables related to Search Module .................................................................................. 25
4.2.4. Tables related to User Module ..................................................................................... 26
4.3. IMPLEMENTATION OF CDSER ..................................................................................... 28
4.3.1. Online Access and Management of CDSER................................................................ 28
4.3.2. Drupal 6.X Modules and Libraries: Integration with CDSER ..................................... 30
4.3.3. Module Integration and Configuration for CDSER ..................................................... 34
5. SECURE WAY OF HANDLING ACCESS CONTROL BY CDSER ..................................... 45
5.1. User Privilege Levels Defined by CDSER ......................................................................... 45
5.1.1. Users, Roles ................................................................................................................. 45
5.1.2 Permissions ................................................................................................................... 47
5.2. Security Measures Against PHP Scripting Attacks by CDSER .......................................... 49
6. PERFORMANCE EVALUATION ........................................................................................... 50
7. CONCLUSION .......................................................................................................................... 52
7.1. Future Work ........................................................................................................................ 52
Appendix A. WAMP Server Installation ....................................................................................... 54
Appendix B. PhpMyAdmin and MySQL Configuration ............................................................... 55
x
Appendix C. Drupal Installation .................................................................................................... 56
Appendix D. Implementation and Environment Setup for CDSER .............................................. 58
Appendix E. Adding Third Party Modules by CDSER Admin ..................................................... 59
Appendix F. Navigational Structure of CDSER ............................................................................ 61
References ...................................................................................................................................... 68
xi
LIST OF TABLES
Table
Page
1.
Node Table ................................................................................................................22
2.
Node_Revisions Table ..............................................................................................22
3.
Node_Type Table ......................................................................................................22
4.
Vocabulary Table ......................................................................................................23
5.
Vocabulary_Node_Type Table ..................................................................................23
6.
Term_Node Table .....................................................................................................24
7.
Term_Data Table ......................................................................................................24
8.
Term_Hierarchy Table ..............................................................................................24
9.
Search_Dataset Table ................................................................................................25
10.
Search_Index Table ..................................................................................................25
11.
Search_Total Table ..................................................................................................25
12.
Users Table ..............................................................................................................26
13.
History Table ...........................................................................................................26
14.
Users_Roles Table ...................................................................................................26
15.
Role Table ................................................................................................................27
16.
Permission Table ......................................................................................................27
17.
Directory Structure Layout .......................................................................................32
18.
Administrative Categories ........................................................................................33
xii
LIST OF FIGURES
Figure
Page
1.
Content Management Framework ............................................................................... 5
2.
Drupal Core Overview ............................................................................................... 6
3.
Entity Relationship Diagram ...................................................................................... 9
4.
Use Case Diagram .....................................................................................................10
5.
CDSER Home Page with Top Navigation .................................................................15
6.
CDSER Home Page Table .........................................................................................17
7.
Open Source Project Page (example MongoDB) .......................................................18
8.
Data Repository (Promise Home Page) .....................................................................19
9.
Effort Prediction Area page .......................................................................................20
10.
cocomosdr Dataset Attributes ....................................................................................21
11.
Upgrading Drupal Installation using CRON Procedure ..............................................28
12.
Home Page of Local CDSER Website .......................................................................30
13.
Integrating Custom Modules to Drupal Core .............................................................31
14.
Configuration of Modules .........................................................................................34
15.
Configuring Content Access Depending on User Privileges ......................................35
16.
Defining Taxonomy for CDSER System ...................................................................36
17.
Content Types Specification in CCK Field ................................................................37
18.
Node View of Content Created ..................................................................................38
19.
Node Structure ..........................................................................................................38
20.
CKEditor ...................................................................................................................39
21.
Content Search ..........................................................................................................40
22.
User Search ...............................................................................................................41
xiii
23.
Login Page ................................................................................................................46
24.
Users ..........................................................................................................................46
25.
Roles ..........................................................................................................................47
26.
Permissions ................................................................................................................48
27.
Permissions Continued ...............................................................................................48
28.
Database Creation and Configuration Using phpMyAdmin ........................................55
29.
Enabling, Disabling and Uninstalling of Module ........................................................59
xiv
1
Chapter 1
INTRODUCTION
Software developers lack objective information to assess the effectiveness of current and
proposed technologies and practices. Cataloging Datasets for Software Engineering Repository
(CDSER) will be an organized repository of software development datasets. These raw materials
provide a base for carrying out analyses and the results stored as related artifacts in the repository.
In this way, the knowledge content of the repository can be built incrementally, providing a rich
support base for other research activities. Research programs can thus be built upon the results
produced by other programs that utilize the repository. The purpose of this project is to improve
the software productivity and quality. It’s difficult for the researchers to get all the relevant data
at one place to do their research so the main idea of this project is to lead all the interested
researchers in software engineering domain to a single location where they can find all the
information and data related to software engineering projects organized in a certain way which
will reduce their work of searching various sources for obtaining the relevant information and
data.
The goal of this project is to collect data from various repositories. The organizational criteria
will be the following:
1. Projects categorized on basis of Software Engineering Repositories like Promise [21].
2. Open Source Projects categorized on the basis of their usage as Data Storage and
Management, Networking and Internet, Group ware, Programming Language Support,
Operating System, Security etc.
While users of CDSER may get the impression that the datasets are physically stored in a central
location, this may not be the case for all artifacts. We will allow CDSER contributors to locate
2
artifacts on their sites and build links to the sites from the CDSER site. The intent is to build up a
network of software development research resource that researchers and practitioners can access
from a single point. We also envisage that the repository will contain other artifacts that may not
necessarily be directly related to development projects in the repository, for example, links to
software engineering research programs, email conversation between developers, conference
papers etc.
1.2. Scope of CDSER
Scope of CDSER includes addition, updating, searching and viewing datasets. Scope of CDSER
also includes administrator and user roles (Admin and Authenticate User and Guest User).
1.3. Roles
CDSER system differentiates the system rights via Admin and an Authenticated User. Admin can
access Add, Update and Delete functionality along with View and Search functionality. On the
other hand authenticated user can access View, Add, Update and Search functionality.
1.4. Related Work
Based on the searching result of Google, I can barely find some systems or tools which can
provide same functions as CDSER does. There is another system called HBAP [1], however, it
provides information and data relating to only ADA language, my project on the other hand
provides information relating to all the software engineering projects and software engineering
data repositories.
3
Chapter 2
BACKGROUND
This Master’s Project is divided into two phases, namely data collection and development. The
first phase is to gather datasets of all the available open-source software engineering projects,
software engineering data repositories and second phase being the basis of this project is the
development of the website CDSER.
Considering the functionality required by the proposed CDSER system, we have selected
Drupal v6.22 as the development platform. MySQL is the database used to maintain the
repositories for the pages, and its contents. The application suite required to host the website, to
install and run Drupal is WAMP 2.0i. This report mainly focuses on the approach taken towards
second phase of the project that is, installing Drupal, developing and managing the repository.
For basic software implementation details, refer to appendices [A, B, C].
2.1. WAMP Server and MySQL Database
WampServer [11] is a Windows based web development environment (application suite). It
facilitates the developer to design and develop web services and applications with Apache, PHP
and MySQL database. For the project, WampServer 2.0i will be used which includes the recent
releases for MySQL v5.5.23 and PHP v5.2.17.
The databases can be easily managed with an interface provided in the Wamp suite called
“phpMyAdmin”. It allows tuning the server without affecting the pre-configured files. It allows
reproducing the production server which means that we can import the entire server and web
4
services from localhost to a web hosting service over the internet without developing the website
again from scratch.
2.2. Open Source CMS Drupal, Modules, Plug-ins and Libraries
Firstly, we shall discuss what the Content Management System (CMS) is all about.
A CMS [2] is a collection of manual or automated procedures to manage the work flow in a
collaborative environment.
Open WCMS [3] is the combination of Open Source software applications and Web based CMS.
WCMS provides a ready platform for developer to construct upon the foundation such as inbuilt
themes, scripts, modules, and database connectivity. Because of this provision it is also very easy
to maintain the website for a novice web-developer having very basic knowledge of programming
and scripting languages.
Predefined modules in WCMS provide easy integration with the system. Drupal, Joomla,
WordPress, dotCMS, eZ Publish, etc. are few of the well-known and widely used stable Opensource Web-based Content Management Systems [3].
2.2.1. Available WCMS
There are many SaaS (Software as a Service; generally paid services) and Free or Open
Source CMS available. Each of them has particular functionality depending on the base
technologies used to develop; such as AJAX framework, PHP Engine, MySQL/ SQLite/
PostgreSQL, Perl, etc. Drupal [5], Joomla [6], and WordPress [7] are the most efficient and
widely used PHP and MySQL based Open Source CMS available. All of them provide Content
5
Management Framework (CMF) [8]. Basic or core framework for CMS, e.g Drupal is shown in
the figure 1 [9].
Figure 1: Content Management Framework.
2.2.2. Drupal
Drupal provides collaborative modules which can be integrated with core modules to achieve
desired functionalities. Core modules are those modules which are provided by default package
and on clean installation of Drupal framework on a server. Figure 2 [9] shows cleanly installed
configuration of Drupal core modules.
Drupal provides several built-in modules and customized third party modules developed by many
contributors, code committers across the globe. Drupal Module Index lists all the available
modules with their version information, compatibility, and functionality. Till date there are
overall 19091 third party modules available considering all Drupal versions: 4.x, 5.x, 6.x, and 7.x.
User may choose the appropriate one, integrate that with core modules, and enable them to use its
functionality depending on the Drupal version he is using. The great advantage to the developer is
that, he may disable or enable any module any time without affecting the functionality of other
modules and also rendering of the already hosted web contents! It provides a thick edge of
6
modularity in developing with Drupal compared to other CMF and CMS available. Stanford
University website [23], White House govt. website [22] are the popular examples of stable and
secure Drupal development [6].
Drupal is a freeware Content Management System that comes with various installation packages
including the Core Drupal modules. For controlling the web services’ access permissions, control
policies can be enforced by installing suitable modules with Drupal core modules. Drupal also
provides with built-in themes to design a Graphical User Interface for better and user friendly
web service.
Chapter 4 discusses in detail the required core Drupal modules, third-party modules and
steps involved in their installation, integration with each other and configuration to achieve the
CDSER system for different set of users.
Figure 2: Drupal Core Overview.
7
Chapter 3
REQUIREMENT ANALYSIS
3.1. General Description
3.1.1. User Characteristics
There are three types of users in this system, guest user, authenticated user and administrator.
Administrator could set up the system, add, and delete modules to upgrade the system.
Administrator has the privilege to update or delete content, view user’s information and delete
users. Authenticated users could view, add and update the content of CDSER whereas guest user
can just access the content on CDSER.
3.1.2. Functional Requirements
3.1.2.1. Administrator Functional Requirements

Administrator has ability to add or delete a user.

Administrator has ability to add or delete modules.

Administrator has ability to view users and edit their privileges.

Administrator has ability to view, add update and delete the content.
3.1.2.2. Authenticated User Functional Requirements

User can view, update and add content to the system.

User can check his/her account history.
8
3.2. Specific Requirements
3.2.1. Interface Requirement
3.2.1.1. Browser
CDSER works on any web browser Mozilla Firefox, Google Chrome, Internet Explorer and
Apple Safari etc.
3.2.1.2. Communication Interface
CDSER server communicates with the client through HTTP protocols.
3.2.2. Non-functional Requirements

Usability – The user interface should be intuitive for both administrator and users.

Availability – The system should be available all the time.

Fault-tolerance – The system should tolerate some small runtime error without crashing.

Security – The system should provide secure service for both administrator and users.
o
System backup database by using database dump.
o
System prevents unauthorized access
9
3.2.3. Data Model Diagram
Figure 3: Entity Relationship Diagram.
10
3.2.4. Use Case Model
3.2.4.1. Use Case Diagram
Figure 4: Use Case Diagram.
11
3.2.5. Typical Flow Scenario of the CDSER System
3.2.5.1. Use Case: Administrator Manages Users

Administrator enters the URL of CDSER in the web browser.

Administrator log into the system by providing his/her user name and password.

Administrator clicks on the “administer” in left navigation bar on the Home page.

Administrator is redirected to an administer list page which lists users management.

Administrator clicks on the users in user management list.

Administrator can than add/delete users.

Administrator can add/delete roles and assign to users.

Administrator can add/edit/delete privileges assigned to user roles.
3.2.5.2. Use Case: Administrator Manages Modules

Administrator enters the URL of CDSER in the web browser.

Administrator log into the system by providing his/her user name and password.

Administrator clicks on the “administer” in left navigation bar on the Home page.

Administrator is redirected to an administer list page which lists site building.

Administrator clicks on the modules in site building list.

Administrator can than add/delete/edit modules.
3.2.5.3. Use Case: Administrator Manages the Content

Administrator enters the URL of CDSER in the web browser.

Administrator log into the system by providing his/her user name and password.

Administrator clicks on the “administer” in left navigation bar on the Home page.

Administrator is redirected to an administer list page which lists content management.

Administrator clicks on the content in content management list.
12

Administrator can than add/delete/edit pages in the CDSER system.
3.2.5.4. Use Case: Administrator Search

Administrator enters the URL of CDSER in the web browser.

Administrator log into the system by providing his/her user name and password.

Administrator clicks in the search box in the Home page.

Administrator enters the content he wants to search in the search box and clicks search
button to get the result.

Administrator enters the name of the user he wants to search and clicks search button to
get the result.
3.2.5.5. Use Case: Authenticated User Manages Personnel Information

Authenticated user enters the URL of CDSER in the web browser.

Authenticated user log into the system by providing his/her user name and password.

Authenticated user clicks on the “my account” in the left navigation bar on the Home
page.

Authenticated user is redirected to his/her account page.

Authenticated user edits his personnel information and clicks save button to save.
3.2.5.6. Use Case: Authenticated User Manages the Content

Authenticated user enters the URL of CDSER in the web browser.

Authenticated user log into the system by providing his/her user name and password.

Authenticated user clicks on the “create content” in left navigation bar on the Home page
to create new pages.

Authenticated user can click on any page on the CDSER and edit the page.
13

Authenticate user can view all the pages on the CDSER.
3.2.5.7. Use Case: Authenticated user Search

Authenticated user enters the URL of CDSER in the web browser.

Authenticated user log into the system by providing his/her user name and password.

Authenticated user clicks in the search box in the Home page.

Authenticated user enters the content he wants to search in the search box and clicks
search button to get the result.

Authenticated user enters the name of the user he wants to search and clicks search
button to get the result.
3.2.5.8. Use Case: Guest User Views the Content

Guest user enters the URL of CDSER in the web browser.

Guest user can view all the pages on the CDSER.
3.2.5.9. Use Case: Guest User Search

Guest user enters the URL of CDSER in the web browser.

Guest user clicks in the search box in the Home page.

Guest user enters the content he wants to search in the search box and clicks search
button to get the result.
14
Chapter 4
DESIGN AND IMPLEMENTATION
4.1. Overview of CDSER System
This chapter explains about how the CDSER system is organized and the different attributes
involved.
4.1.1 Home Page of CDSER
The home page of CDSER contains a navigation on the top (refer Figure 5) and a table at the
bottom (refer Figure 6) which has all the datasets present in the system. It contains links to open
source projects and software engineering repositories. The projects in the home page are
categorized on the basis of their usage as Data Storage and Management, Networking and
Internet, Group ware, Programming Language Support, Operating System, Security and Data
Repository etc.
15
Figure 5: CDSER Home page with Top Navigation.
Each project in the home page is divided into 8 attributes Project Name, Type, Operating System,
Language, Year, Source Code, Mailing Lists, and Development Status.
1. Project Name:
It gives the name of the open source project or the name of the data repository.
2. Type:
It gives the type of the project. It can be one of the following; Data Storage and Management,
Networking and Internet, Group ware, Programming Language Support, Operating System,
Security etc.
3. Operating System:
16
It tells about the compatibility of the project with the various Operating Systems.
4. Language:
This attribute has the information regarding project development language. It can be one of the
many programming languages like C, Java, Perl, JavaScript etc.
5. Year:
This tells the year in which the project was started.
6. Source Code:
This attribute links to the actual source code of the project.
7. Mailing List:
This attribute is in turn divided into user and developer, where user links to the user mailing lists
of the project and developer links to developer’s mailing lists of the project.
8. Development Status:
This attribute tells whether the project is still active for development or not.
17
Figure 6: CDSER Home page Table.
4.1.2 Projects in CDSER
The projects included in CDSER are categorized into two Open Source projects and Data
Repository projects, Open Source projects are divides into few of many project domains available
in the Computer Science society. Each project mentioned on the CDSER home page is a small
website with its own home page that describes about the project and few attributes. Following is a
brief description of each project included in CDSER.
1. Open Source:
18
Each Open Source project has a main / home page which has description about the project and 15
additional attributes. Figure 7 shows an example of an Open Source project MongoDB
Figure 7: Open Source project Page(example MongoDB).
2. Data Repository:
Data Repository projects’ home page (refer Figure 8), describe about the data repository and a
table which has areas and number of datasets in form of a two –column table. The Area column
has seven categories: Defect Prediction, Effort Estimation, Effort Prediction, General, Model
19
Based SE, New Release Problem, Text Mining and Product Line Feature Models which are
described in Promise Data Repository. The number of datasets column gives the details of
number of datasets present in each of the seven categories.
Figure 8: Data Repository (Promise home page).
Each Area is a link to a page which has a table with 6 columns that has information about the
dataset in detail. The columns are: Dataset name, Donor, Date Donated, Description, Attributes
in the dataset and Download URL as shown in Figure 9.
a. Dataset Name: This column provides the name of the dataset.
20
b. Donor: It gives the name of the donor, who donated the dataset in the repository.
c. Date Donated: Defines the date on which the dataset was donated.
d. Description: It gives the description about the dataset.
e. Attributes: It links to a page which has the list of attributes in that dataset (Figure 10)
f.
Download URL: It links to the actual download link of the dataset.
Figure 9: Effort Prediction Area page.
21
Figure 10: cocomosdr Dataset Attributes.
4.2. Database Design and Implementation
Based on the ERD diagram in software requirement analysis chapter, this project needs sixteen
tables/entities.
4.2.1. Tables related to Node Module

Node, the table Contains basic information about each and every node in the system.
Body content information is not retained here. See Node_Revisions table. This table
serves the purpose of being able to quickly access information about nodes.
22
Table 1: Node Table.
Attribute
nid
vid
type
language
title
uid
status
created
changed

Type
int
int
varchar
varchar
varchar
int
int
int
int
Null
No
No
No
No
No
No
No
No
No
Key
Yes
Auto_increment
Yes
Node_Revisions, the table contains every revision (edit) of every node in the system. if
you delete a node, the revisions go, too.
Table 2: Node_Revisions Table.
Attribute
nid
vid
uid
title
body
timestamp

Type
int
int
int
varchar
longtext
int
Null
No
No
No
No
No
No
Key
Auto_increment
Yes
Yes
Node_Type, stores information about all defined node types.
Table 3: Node_Type Table.
Attribute
Type
Name
Module
Description
has_title
Type
varchar
varchar
varchar
varchar
varchar
Null
No
No
No
No
No
Key
Yes
Auto_increment
23
title_label
has_body
body_label
orig_type
varchar
varchar
varchar
varchar
No
No
No
No
4.2.2. Tables related to Taxonomy Module

Vocabulary, the table stores vocabulary information.
Table 4: Vocabulary Table.
Attribute
vid
name
description
module
relations
hierarchy
required

Type
int
varchar
longtext
varchar
tinyint
tinyint
tinyint
Null
No
No
Yes
No
No
No
No
Key
Yes
Auto_increment
Yes
Vocabulary_Node_Types, the table stores which node type’s vocabularies may be used
with.
Table 5: Vocabulary_Node_Type Table.
Attribute
vid
type
Type
int
varchar
Null
No
No
Key
Yes
Auto_increment
24

Term_Node, stores the relationship of terms to nodes.
Table 6: Term_Node Table.
Attribute
nid
vid
tid

Type
int
int
int
Null
No
No
Key
Auto_increment
yes
yes
Term_Data, stores term information.
Table 7: Term_Data Table.
Attribute
tid
vid
name
description

Type
int
int
varchar
longtext
Null
No
No
Yes
No
Key
Yes
Auto_increment
Yes
Term_Hierarchy, stores the hierarchical relation between terms.
Table 8: Term_Hierarchy Table.
Attribute
tid
parent
Type
int
int
Null
No
No
Key
Yes
Auto_increment
25
4.2.3. Tables related to Search Module

Search_Dataset, each row of this table is the simplified content of a node.
Table 9: Search_Dataset Table.
Attribute
sid
type
data

Type
int
varchar
longtext
Null
No
Yes
No
Key
Auto_increment
Search_Index, an index of every word of the content in search_dataset.
Table 10: Search_Index Table.
Attribute
word
sid
type

Type
varchar
int
varchar
Null
No
No
Yes
Key
Auto_increment
Yes
Search_Total, unique lists of words from Search_Index, with frequency statistics.
Table 11: Search_Total Table.
Attribute
word
count
Type
varchar
float
Null
No
Yes
Key
Auto_increment
26
4.2.4. Tables related to User Module

Users, this table stores user data.
Table 12: Users Table.
Attribute
uid
name
pass
mail
mode
theme
created
access
login
status
timezone

Type
int
varchar
varchar
varchar
tinyint
varchar
int
int
int
tinyint
varchar
Null
No
No
No
Yes
No
No
No
No
No
No
Yes
Key
Yes
Auto_increment
Yes
History, this table contains a record of which user has read which node.
Table 13: History Table.
Attribute
uid
nid
timestamp

Type
int
int
int
Null
No
No
No
Key
Yes
Yes
Auto_increment
User_Roles, this table maps users to roles.
Table 14: Users_Roles Table.
Attribute
uid
rid
Type
int
int
Null
No
No
Key
Yes
Yes
Auto_increment
27

Role, stores user roles.
Table 15: Role Table.
Attribute
rid
name

Type
int
varchar
Null
No
No
Key
Yes
Auto_increment
Yes
Permission, stores information regarding user permissions.
Table 16: Permission Table.
Attribute
pid
rid
perm
tid
Type
int
int
longtext
int
Null
No
No
Yes
No
Key
Yes
Auto_increment
Yes
28
4.3. IMPLEMENTATION OF CDSER
4.3.1. Online Access and Management of CDSER
After configuring the WAMP Server, Database set-up, and Drupal installation, next step is to
integrate, configure and manage the CDSER. Refer to appendices [A, B, C] for installation
details. As shown in Figure 11, the built-in procedures such as Cron and update.php allow Drupal
to find the updates and install them in the background without affecting the functionality of the
web application or services already running. Drupal generates the status report and notifies site
admin periodically. It can be accessed with admin privileges only.
Figure 11: Upgrading Drupal Installation using CRON procedure.
4.3.1.1. Integrating CDSER with Drupal: Setting up Root
After following the step mentioned in Section 4.3.1, Drupal 6.x.zip archive is to be
extracted at:
29
C:/wamp/www/drupal-6.22
For simplicity the <Drupal Core folder 1> i.e. drupal-6.22 can be renamed as per developer’s
convenience and choice. It is a good practice to use an elaborative name for Drupal installation.
This practice helps in finding the configuration files, resources, libraries for a particular Drupal
installation among many Drupal versions hosted under same www directory. It also helps the new
developers to take charge and locate the repositories.
Example 1:
C:/wamp/www/CSDER(vD6.22)
The above example clearly states that the current Drupal repository is for CSDER project and it is
using Drupal core version 6.22.
4.3.1.2. Accessing CDSER on Localhost
After following steps up to 4.3.1.1, Drupal website is ready to access on localhost refer Figure
12, with port number being 8080 usually, The URL shown in example 2 is to be used to open
the home page of the website. The Drupal CMF parses the CSDER (vD6.22) directory in URI
field. This is followed by Drupal CMS which locates and executes index.php file. This renders the
home page of the installed Drupal. Now the repository (web service) is ready to be configured
further with the help of other modules and their integration with core modules.
Example 2:
http://localhost/CDSER(vD6.22)/
30
Figure 12: Home page of local CDSER Website.
4.3.1.3 Accessing CDSER online
Steps mentioned in Section 4.3.1.2 are used to test the website in development phase. After
completing necessary configurations and module integrations, and the website is ready to be
accessed publicly, it is to be hosted with domain name instead of localhost.
Web hosting servers are to be configured and the Drupal installation folder created in
Section 4.3.1.1 is to be imported to the allocated web space using any FTP connection. The
proposed CDSER system will be reproduced under http://csder.cs-csus.com/cdser/
4.3.2. Drupal 6.X Modules and Libraries: Integration with CDSER
The procedure followed till Section 4.3.1, creates an online presence of CDSER System. Now the
next step is to configure the core or built-in modules and to integrate the third party modules. We
have discussed the clean installation of Drupal in Chapter 2.2.2 it forms a foundation to build the
31
infrastructure for the proposed CSDER System. The process of adding customized or third party
modules to Drupal is shown in the following Figure 13 [9].
Figure 13: Integrating Custom Modules to Drupal Core.
4.3.2.1. Default Directory Structure for CDSER
Table 17 explains the directory structure for Drupal core modules. It shows the procedures of
initiating files residing under each directory. Each time when any event is triggered, the
concerned library file is executed by php-engine.
32
Table 17: Directory Structure Layout.
Directory/ Repository
Libraries
Includes
Cron.php
Misc
Index.php
Modules
Install.php
Profiles
Robots.txt
Sites
Update.php
Scripts
Xmlrpc.php
Themes
page.tpl.php & template.php
Custom directory
customized themes, modules
“Update.php” checks for available updates to modules. Any modification, customization of
libraries and modules are taken care by update.php and stored under site’s directory.
4.3.2.2. Configuring Modules
This section discusses the Drupal modules for their features, applications to implement
“Access Policies”. After repositioning these downloaded module, directories to project
33
Resource folder i.e. CSDER(vD6.22) and enabling them; the featured settings can be configured
through the settings page. The modules can be configured through:
Administer -> Content Management,
Administer -> Site Configuration, and
Administer -> Side Building
The paths to other administrative categories can be referred in Table 18.
Table 18: Administrative Categories.
Category
Path
Content Management
admin/content
Site Configuration
admin/settings
User Management
admin/user
Site Building
admin/build
Reports
admin/reports
For implementing the CDSER features, enforcing the taxonomies, and setting
access controls various modules are integrated and their features. We will discuss each
feature in detail in Section 4.3.3
34
Figure 14: Configuration of Modules.
4.3.3. Module Integration and Configuration for CDSER
Integration of selective third-party modules with the core modules have provided the
extended features in CDSER System.
4.3.3.1. Configuring Core Modules
4.3.3.1.1. Content Access
Content Access [12] is the core Drupal module which when enabled provides a panel to configure
the permissions for users associated with relevant privileged level of hierarchy. Administrator or
authenticated user is generally considered at LEVEL = 0 i.e. highest privileged level. Also it
35
allows editing the permissions for authenticated general users. For current system, each
authenticated user cannot be an administrator. It is possible that a registered user is an
authenticated user but may not be an administrator, in which case, View, Edit, and Write
accessibilities can be set separately. It also allows specifying the custom view, editing and
deleting permissions for each content type.
Figure 15 shows the control panel for assigning the permissions. This control panel is
produced after a developer configures the function in “content_access” module.
Advantage of using Open Source Drupal CMS is that, developer may modify the original
code as per his requirements. Thus it offers scalability, extensibility along with modularity.
Figure 15: Configuring Content Access depending on User Privileges.
4.3.3.2 Taxonomy
In general, Taxonomy [13] means classification or categorization of a data. Taxonomy is core
module of Drupal distribution. It allows organization and departmentalization of the contents. The
36
content is classified as tags, metadata or categories. It associates itself with integrated custom
modules. Developer or site administrator of the System has to define the categories or tags for
particular content types. Also under THEME_VIEW vocabulary, there can be many themes
stored. When an admin calls any function for particular vocabulary or even any tag under
particular vocabulary, that particular data can be easily accessed or operated.
Figure 16: Defining Taxonomy for CDSER System.
Figure 16 shows the customization of a Taxonomy module where the books taxonomy
has Vocabulary name as Topic and content types distributed as Book page, Page, and Story. It
allows author or administrator to simply add new web pages and assign a category just by single
click. We will discuss the configuration of access controls in latter sections.
4.3.3.3. CCK (Content Construction Kit)
The Content Construction Kit [14] is one of the most important Drupal core modules. It is
highly scalable, because it is required for all custom third-party module integration. Integration of
custom modules with CCK permits to generate custom fields to the nodes. CCK module makes
the CMS very powerful by extending its functionality with many different and new contributed
modules.
37
Figure 17: Content Types specification in CCK Field.
Figure 17 shows the integration of third-party and customized modules such as Page and
Story to CCK fields. This serves the purpose of creating contents for CDSER system and
constructing nodes for each metadata added to it.
4.3.3.4. Node
A chunk of content created using “create content” is known as a Node. Nodes can be given a title
for identification. Figure 18 shows the nodes created on the CDSER website, where pages can be
clearly identified by their names. E.g. qosdata Attributes, Promise.
38
Figure 18: Node view of content created.
Each node when created, is assigned with a unique Node ID i.e. $nid. Node titles help
users to search, locate, view contents whereas, Node IDs help Drupal system to identify and
locate the node when revoked. Every node has unique ID, user defined Title and custom Body,
where html contents are rendered for web view. Figure 19 shows a node structure [9]:
Node
ID
Title
Body
Figure 19: Node Structure.
4.3.3.5. CKEditor (WYSIWYG)
CKEditor [15] allows client-side editors to edit content on CDSER. It simplifies the installation
and integration of the editor of a user’s choice. This module replaces all other editor integration
modules. No other Drupal module is required. Wysiwyg module is capable to support any kind of
client-side editor. It can be a HTML-editor (a.k.a. WYSIWYG), a pseudo-editor (buttons to insert
39
markup into a text area), or even Flash-based applications. CKEditor module also provides an
abstraction layer for other Drupal modules to integrate with any editor.
Figure 20: CKEditor.
4.3.3.6. Search: Internal CDSER search
The search module lets users search for specific content on the site. You can search both for users
and for particular words. To search any information on through the Search web page, following
search home page appears refer to Figure 21.
40
Figure 21: Content Search.
When you are on the "content" tab, you will be able to search for words that appear in the
default rendering of node content on the site, which would include the default rendering of any
CCK fields, Location fields, Taxonomy, etc., as well as comments. When you are on the "users"
tab, you will be able to search for user names of registered users on the site, and if you have
sufficient permissions, then you can also view their email addresses. Refer to figure 22.
41
Figure 22: User Search.
If you enter more than one search term in the content search, the search module will look
for content that has all the terms you've entered. If instead you want either one term or another,
join your terms with "or." If you're looking for an exact phrase, enclose it in quotation marks.
With Advanced search you can also look for results using one or both of the following
search query "any of these words" or "this phrase," .You can rule out words you don't want, and
you can choose content types to confine your search. You can enable the search module on
the modules page (administer >> site building >> modules) in earlier versions of Drupal.
Note that by default, content search only finds exact matches for the keywords in your content.
4.3.3.6.1. Search Mechanism in CDSER:
The search mechanism in CDSER uses indexes for faster accessibility.
1) Indexing:
Drupal's search engine created indexes on the text content of the nodes of the site. The search
engine does its indexing at intervals chosen by the administrator by setting "cron runs." Cron
42
(which stands for chronograph) is not a part of Drupal. It's a scheduler that resides on the server
and runs tasks (called "cron jobs") specified by the administrator, in intervals. The cron jobs can
be scheduled on weekly, daily or hourly basis. The admin can also define a customized schedule
for running the jobs on the server.
When a new web page or content is added in the CMS, it is added in the database
immediately, but it is not indexed immediately because cron script needs to be executed for
indexing any new contents. Therefore, you need to schedule a "cron job" that sends a browser
request on your server regularly and visits your "cron page." For instance, if your site
were www.example.com , your cron page would be http://www.example.com/cron.php in Drupal
6 and earlier vers ions.
So, whenever a visit to the cron URL occurs, the search engine will take up the work of
indexing. You need to set up these cron runs before your search engine can search any newly
added data.
For a modest personal site to which you post now and then, you might set up a cron job to
run once a day. For a more active site you'd likely want to run that job more often--perhaps every
few hours or every hour.
On your settings page for Search (administer >> site configuration >> search settings in
Drupal 6, you can limit how many items should be indexed in a single cron run. This can help
keep your system from getting overloaded with work. If you get a message that cron is timing out
or PHP is running out of memory, lower the number of items to index per run. There are few
more search settings that can be explored.
43
2) Re-indexing content:
Content-related actions on your site (creating, editing, or deleting content and comments)
automatically cause affected content items to be marked for indexing or re-indexing at the next
cron run. When content is marked for re-indexing, the previous content remains in the index until
cron runs, at which time it is replaced by the new content.
Unlike content-related actions, actions related to the structure of your site do not cause
affected content to be marked for re-indexing. Examples of structure-related actions that affect
content include deleting or editing taxonomy terms, enabling or disabling modules that add text
to content (such as Taxonomy, Comment, and field-providing modules), and modifying the fields
or display parameters of your content types. If you want to ensure that the search index is updated
to reflect your changed site structure, you can mark all content for re-indexing by clicking the
"Re-index site" button on the Search settings page (administer >> site configuration >> search
settings in Drupal 6).
3) Accessing Search:
If both the search module and the menu module are enabled, from the menus page (administer >>
menus) you can enable on the Navigation Menu the item Search. The option to show this menu
item may be disabled by default, but you can enable it. (And you can rename "Search" to
whatever you wish.)
You can also place a link to Search among your site's primary and secondary links, or on any
other menu as well. Click "add menu item," and when you fill in the "path" field on the dialogue
page just enter "search".
On your blocks page (administer >> site building >> blocks) in Drupal 6, there's also
a Search form which you can enable, and can choose where you want it to display.
44
On your permissions page (administer >> user management >> permissions) in Drupal 6, you
can decide who can do searches and who can administer the search settings. By default,
anonymous users cannot perform searches.
45
Chapter 5
SECURE WAY OF HANDLING ACCESS CONTROL BY CDSER
This chapter focuses on default access controls permitted by Drupal, the deficiencies and how
CDSER hardens it up to make the system secure and robust. Drupal has a dedicated
security team since 2005 that looks after all security threats and incidence response to patch up
the loop holes. Core Drupal modules i.e. modules which are available on clean Drupal
installation are secured, but the third party modules available for integration with Drupal core are
not as secured as Drupal core modules. Drupal being an open source system, contributors across
the globe build their customized modules on the top of the core modules. In this process the third
party modules can be vulnerable to few security loopholes.
5.1. User Privilege Levels Defined by CDSER
5.1.1. Users, Roles
CDSER users need to log in, in order to add content to the system. Refer Figure 23. CDSER
defines each of the Users with specific Roles. Each user and role combination enforces various
privilege levels and corresponding access controls. It defines the contribution level for that
particular user. The users or contributors for CDSER site are mainly categorized into Guest or
Anonymous user, Authenticated user and Administrator. According to user contribution
privileges; Anonymous user can view the pages of the CDSER and Authenticated users have an
access permission to add new pages. Only Administrator can add new content and delete pages.
CDSER achieves these access levels and capabilities by defining roles to set the
permissions for the users. The assigned roles include Guest, Authenticated, and Administrator.
46
Figure 23: Login Page.
Figure 24: Users.
47
Figure 25: Roles.
5.1.2 Permissions
Each user role has its own set of permissions. Permissions let you control what users can
access, edit or delete and even share the responsibility of Administrator.
48
Figure 26: Permissions.
Figure 27: Permissions continued.
49
5.2. Security Measures Against PHP Scripting Attacks by CDSER
While building a site, developers need to take care of default permissions and settings
assigned by Drupal for the modules. Drupal page creation body area, accepts php code as input
along with another scripting languages; mainly html. The code or scripts posted in body area are
generally saved in respective database tables. Attacker can write a small piece of php code and
can execute malicious code to deploy XSS, Web Defacement, Database stealing attacks [18, 20].
CDSER takes care of such attacks by not allowing access to create new contents to privileged
level 2 user’s i.e. Anonymous user. Also by disabling an access to the php input filter malicious
scripts, CDSER prevents scripting attacks.
50
Chapter 6
PERFORMANCE EVALUATION
CDSER system performs effectively and efficiently for all the three types of users; administrator,
authenticated users and the guest users. The administrator and authenticated users were able to
log in into the system to do the necessary changes to the site and afterwards they logged out.
Performance evaluation for a website is done by reviewing its key indicators. The key indicators
offer a snapshot of the website’s overall performance and a high-level view of areas that require
improvement.
The following were observed during the performance analysis of CDSER System.
Load time of CDSER
Users are enamored with speedy websites, and when a site responds slowly, visitors lose their
patience and are less likely to come back. But, in case of CDSER, it’s a different situation.
CDSER took 2 seconds to load when it was tested for “webpage performance test” at Web Page
Test [17]. Administrators and website managers can also reduce the 2 seconds loading time by
optimizing and compressing images and contents on CDSER and not adding any video content.
Comparing with HBAP
51
HBAP site has a search tool which does a Google search whereas CDSER search tool does an
internal search of the content. Therefore the search tool of CDSER is very useful for finding the
content within the system
Domain Name Creation and Expiration
The domain name creation and expiration dates are important to search engines. The longer a
website has been in existence (and by the expiration date, intends to be in existence), the more
trustworthy it appears. In particular, search engines look at a domain name’s creation and
expiration dates. Domains that have been registered for less than a year or will expire in less than
a year raise red flags for search engines. CDSER has an expiration date after a year and later it
can be registered again for renewal.
Yahoo! - Directory Listing
This key indicator helps increase visitors for any website. Yahoo is the most visited internet
destination. Once a website is listed in Yahoo directory listings, it provides more traffic
(searches) than all other search engines combined.
Performance Issues
Problem
The content of the CDSER would grow in size, which would require a large database setup and
indexing scheme for contents. The search might become ineffective or time consuming.
Solution
The only feasible solution is replacing the search module with Solr[16] module. This module
performs efficient searches without adding database overhead.
52
Chapter 7
CONCLUSION
The CDSER system can be used by the experts to help in future prediction for improvement of
quality and productivity of the software. It’s difficult for the researchers to get all the relevant
data at one place to do their research, therefore, CDSER system will lead all the interested
researchers in software engineering domain to a single location where they can find all the
information and data related to software engineering projects organized systematically, which
will reduce the amount of time for searching various sources for obtaining relevant information
and data.
From the developer’s perspective, integrating and configuring the Drupal modules and
developing a site is easier and less time consuming with lesser scripting and design knowledge.
There are many modules available for Drupal, but the selection of appropriate module is of prime
importance. So anyone with the zest of learning new things can build on skills to use CMS and
CMF effectively.
CDSER has an advantage of being modular and flexible system. Any time any content,
any new module can be added, modified, deleted or integrated without affecting the performance
and functionality of the current system.
7.1. Future Work
Drupal has more than 19000 modules available. You would not get a single package that can
provide all the functionalities you need, therefore, as a developer you need to incorporate
different modules according to their functionality capabilities.
53
Customizing many modules and then selecting fewer appropriate ones seems time
consuming. Instead the functionalities of all related or dependent modules can be integrated in
which can be specially developed for developing similar online CDSER.
The Drupal system can be migrated to smart-phone or tablet devices. Nowadays smartphone platform is picking up the market. So it will add an advantage to the system if it is also
configurable for smart devices. Another enhancement to CDSER could be adding as many
software engineering projects as possible and automating the process of collecting data.
54
APPENDIX A
WAMP SERVER INSTALLATION
As discussed in Section 2.1, WAMP server is freeware software and can be downloaded
at http://www.wampserver.com WAMP stands for Windows-Apache-MySQL-PHP package that
provides inbuilt libraries and backend interface through phpMyAdmin which is configured at
localhost running on port 8080. After installing it creates the wamp directory in the destination
drive. The www directory resides under the wamp directory; where the actual website resources
are stored. The selected Drupal distribution and the set up files reside under www directory. The
www directory can contain any number of Drupal installations under one cover. The www
directory is a root directory for any Drupal installation and website contents hosting. It acts as a
repository to store all configuration files, libraries, resources, and user files. The MySQL
database can be shared among all these Drupal installations.
Here, C:/wamp/www/<Drupal Core folder 1>
C:/wamp/www/<Drupal Core folder 2> ……… and so on.
After putting the WAMP server online, services such as phpMyAdmin and MySQL are
started automatically (and manually from WampServer control panel). Files on the WAMP
servers are then hosted to the web servers with dedicated domain name. Thus WAMP is used for
developing and testing the website on local machine before making it available online publically.
In other words, it acts as a simulator.
55
APPENDIX B
PhpMyADMIN AND MYSQL CONFIGURATION
Before installing Drupal, the important step is to set up the database. WampServer 2.0i
installation provides the releases for MySQL 5.5.23 and PHP 5.2.17. The Database administrator
can configure the database access policies by setting user name and password credentials along
with the read-write permissions to the database. The database can be configured and accessed at:
URL: http://localhost/phpmyadmin/
Figure 28: Database Creation and Configuration Using phpMyAdmin.
Figure 28 shows the creation and configuration of a database on localhost. The advantage
of setting up the database before installing a Drupal is that, while installing a Drupal core, it
automatically detects the available databases through WAMP server and it is easy to select and
assign particular database to the exact Drupal integration. Database admin needs to set up the
permissions, user roles for accessing database while configuring through above process.
56
APPENDIX C
DRUPAL INSTALLATION
Now next step is to select appropriate version for Drupal core. Recently Drupal 7.x has
been launched. But yet it is in development phase and all the necessary modules for configuring
library system are not yet upgraded to v7.x from v6.x. Drupal 6.x is the most stable version
available till date. Also in future, migration to v7.x will not be tedious process because, by that
time, Drupal 6 modules will be upgraded to have Drupal 7 compatibility. As Drupal provides
high degree of modularity; without affecting previous installations; Drupal core can be upgraded
to the latest version.
Here are the steps to be followed for localhost Drupal 6.x installation:
1. Download Drupal latest version (here Drupal 6.22) from http://drupal.org/download
2. Extract the files into a directory under C:\wamp\www.
3. Move the contents of that directory into a directory within your web server's document
root(…webroot/htdocs/drupal6.22)
4. Go to http://localhost/phpMyAdmin
5. Create new database called DRUPAL and database admin.
6. Go to http://localhost/D6.22-CDSER and enter the database details for the database which
you have created in step 5.
7. Progress with Drupal installation steps and create Drupal site admin username and
password. This is the admin user having all site creation, maintenance, configuration
privileges.
8. Other non-admin users can be created by clicking “create new account” on the home page
of your site at http://localhost/D6.22-CDSER
57
9. After developing a site, next step is to upload the site contents to the public site.
10. For that you need a dedicated domain name. For CDSER CMS it is
www.cdser-cs-csus.com/cdser
58
APPENDIX D
IMPLEMENTATION AND ENVIRONMENT SETUP FOR CDSER
1) FTP your Drupal files to the following
a. FTP: with your ftp user name
b. FTP password
2) Export your database for this Drupal site by accessing your phpmyadmin
a. Select the database that links to your Drupal site
b. Select export menu in the top middle area
c. Select zipped next to compression in the bottom of the page
d. Select Go to start exporting the file to somewhere in your Laptop
3) Import this exported database to the public site by accessing
http:// www.cdser-cs-csus.com/cdser/phpmyadmin
a. Use your user id and password to login
b. Select CDSER on the left menu if it is not selected
c. Select import menu on the top middle area
d. Select Browse and look for the exported database file you downloaded to
your laptop in step 2.d
e. Select “Go” to start importing
4) After completing all the above mention steps, Drupal site is reproduced under
http://www.cdser-cs-csus.com/cdser
59
APPENDIX E
ADDING THIRD PARTY MODULES BY CDSER ADMIN
Third party modules are those, which are developed by volunteers, code committers.
These volunteers commit their code to the Drupal modules’ index. As these modules are open
sourced, other committers keep them updating for removing bugs, adding functionalities.
The reason to add third party module is that, Drupal ships with only core modules which
are just enough to set up the structure of the web site. Now to have desired functionality on the
top of these core features, third party modules need to be integrated.
Figure 29: Enabling, Disabling and Uninstalling of Module.
The modules should be extracted to the modules directory. To activate the features of the
module, it should be enabled from the admin settings. The above admin control panel shown in
60
Figure 29 allows administrator to enable or disable the module just by clicking a check box.
After enabling certain modules, the features associated with it, are integrated with the related
core module and can be used in conjunctions.
61
APPENDIX F
NAVIGATIONAL STRUCTURE AND LINKS TO OPEN SOURCE PROJECTS
Data storage and Management

DBMS
MongoDB:
http://www.mongodb.org/display/DOCS/Source+Code
HyperTable:
http://code.google.com/p/hypertable/wiki/SourceCode?tm=4#Get_the_H
ypertable_source_code
Apache CouchDB:
http://couchdb.apache.org/community/code.html
Riak:
https://github.com/basho/riak
Apache Cassandra:
http://cassandra.apache.org/download/
Firebird:
http://www.firebirdsql.org/en/code-repository/
Hbase:
http://hbase.apache.org/source-repository.html
Drizzle:
https://code.launchpad.net/drizzle

File Archivers
Ark:
62
http://www.kde.org/applications/utilities/ark/development
QuickZip:
http://code.google.com/p/quickzip/source/checkout
Xarchiver:
https://launchpad.net/xarchiver

RDBMS
MySQL:
The source code of MySQL can be found at
http://dev.mysql.com/doc/refman/5.0/en/installing-developmenttree.html
MySQL Server:
The source code of MySQL Server can be found at
https://code.launchpad.net/mysql-server
SQLite:
http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
PostgreSQL:
http://www.postgresql.org/docs/8.1/static/sourcerepo.html

File Systems
OpenAFS:
Source code of OpenAFS can be found at
http://www.openafs.org/release/latest.html
http://wiki.openafs.org/AFSLore/HowToBuildOpenAFSFromSource/

Data mining
Weka:
http://www.cs.waikato.ac.nz/ml/weka/
63
Scriptella:
http://scriptella.javaforge.com/download.html
Networking and Internet

File Transfer
Filezilla:
http://filezilla-project.org/sourcecode.php
Openfiler:
http://www.openfiler.com/about/openfiler-source-code-released
Samba:
http://www.samba.org/samba/cvs.html

File sharing
EMule:
http://sourceforge.net/projects/emule/files/
FileScope:
http://www.filescope.com/

Remote access and Management
TightVNC:
http://www.tightvnc.com/download.php
OpenVPN:
http://svn.openvpn.net/
Rdesktop:
64
http://sourceforge.net/projects/rdesktop/

Web browsers
Chromium:
http://www.chromium.org/developers/how-tos/get-the-code
Lynx:
http://lynx.isc.org/
Firefox:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Struct
ure

Portal Server
Uportal:
https://wiki.jasig.org/display/UPM/02+uPortal+Source+Control

Middleware
GlassFish Application Server:
http://glassfish.java.net/public/downloadsindex.html#top
Apache:
http://www.apache.org/dev/version-control.html#source-coderepositories
Groupware

Content Management System
Joomla:
http://developer.joomla.org/code.html
WordPress:
http://wordpress.org/download/source/
Operating System
65
Ubuntu:
https://wiki.ubuntu.com/Kernel/SourceCode
Linux:
http://www.kernel.org/
Programming Language support

Bug Tracker
Bugzilla:
http://www.bugzilla.org/download/
Mantis:
http://www.mantisbt.org/sources.php
RedMine:
http://www.redmine.org/projects/redmine/wiki/Download

Debugger
GNU Debugger:
http://www.gnu.org/software/ddd/

Integrated Development Environment
Eclipse:
http://www.st.cs.uni-saarland.de/softevo/bug-data/eclipse/
Emacs:
http://savannah.gnu.org/projects/emacs
Security

Antivirus
Gateway Antivirus:
66
http://gatewayav.sourceforge.net/download.html
ClamAV:
http://www.clamav.net/lang/en/download/sources/

Firewall
IPFire:
http://www.ipfire.org/development
Firestarter:
http://www.fs-security.com/docs/cvs.php
Institutional
Carnegie Mellon University
http://repository.cmu.edu/sei/
Stanford University
http://snap.stanford.edu/data/index.html#socnets
University of Canterbury
http://www.cosc.canterbury.ac.nz/research/RG/alg/repository.html
Saarland University
http://www.st.cs.uni-saarland.de/softevo/bug-data/eclipse/
University of Texas at El paso
http://repository.cs.utep.edu/
Loughborough University Institutional Repository
67
https://dspace.lboro.ac.uk/dspace-jspui/handle/2134/83
Workshops and Conferences
http://www.conference-service.com/conferences/us/software-engineering.html
http://promise.site.uottawa.ca/
http://www.wikicfp.com/cfp/servlet/event.showcfp?eventid=18665&copyownerid=23046
http://www.cmu.edu/silicon-valley/wmse/
https://sites.google.com/site/eseworkshop2012/
http://2012.gasworkshop.org/
http://promisedata.org/?cat=13
68
REFERENCES
[1] “Home of Brave ADA Programmers” [Online Document]
http://www.adahome.com/welcome/
[2] “Content Management System” [Online Document]
http://en.wikipedia.org/wiki/Content_management_system
[3] “Web Based Content Management Systems – The Preference of the Wise” [Online
Document] http://photoshop2cms.com/?p=42
[4] “List of Content Management Systems” [Online Document]
http://en.wikipedia.org/wiki/List_of_content_management_systems
[5] “Drupal” [Online Document] http://drupal.org
[6] “Joomla!” [Online Document] http://www.joomla.org/
[7] “Wordpress” [Online Document] http://wordpress.com/
[8] “CMF” [Online Document]
http://en.wikipedia.org/wiki/Content_management_framework
[9] John K. VanDyk: Pro Drupal Development, Spring, NY: Apress, 2008.
[10] “Drupal Modules Index” [Online Document]
http://drupal.org/project/modules/index
[11] “Wamp Server 2.0i” [Online Document]
http://www.wampserver.com/en/
[12] “Content Access” [Online Document]
http://drupalmodules.com/module/content-access
[13] “Taxonomy” [Online Document]
http://drupal.org/documentation/modules/taxonomy
[14] “CCK Content Construction Kit” [Online Document]
69
http://drupalmodules.com/module/content-construction-kit-cck
[15] “CKEditor” [Online Document] http://drupal.org/project/ckeditor
[16] “Solr Search” [Online Document] http://drupal.org/project/apache_solr_search_view_modes
[17] “Web Page Test” [Online Document] http://www.webpagetest.org/
[18] “Open Source Security - Drupal Security” [Online Document]
http://www.madirish.net/?article=449
[19] Benjamin J. J., Gregory J. K., 2010. Drupal Security White Paper.
http://drupalsecurityreport.org/sites/drupalsecurityreport.org/files/drupal-security-white-paper1-1.pdf
[20] “Spyware, viruses, & security forum: VULNERABILITIES / FIXES” [Online Document],
http://forums.cnet.com/7723-6132_102-525217.html
[21] “PROMISE” [Online Document] http://code.google.com/p/promisedata/wiki/About
[22] “White House” [Online Document] http://www.whitehouse.gov/
[23] “Stanford University” [Online Document] http://www.stanford.edu/