0512575 printing request_and_press_resource_management_system_for_udara_type_setting_in_panadura

Printing Request And Press Resource
Management System For Udara Type Setting
in Panadura.
M.S.D. Perera
Index Number:R0512575
BIT Registration Number:051257
Dr. Virjraj Pinto
December 2014
This dissertation is submitted in partial fulfilment of the requirement of the
Degree of Bachelor of Information Technology (external) of the
University of Colombo School of Computing
1

Abstract
Udara Type Settings Panadura is a mediumn scale offset printing press in Panadura town area. They
had a old class manual system to perform their basic business operations and deliver their services to
public. It's so time consuming and wasting lots of resources. So a new computer based system was
suggested.
The new system is providing almost all the basic business functions computerized. Keeping tracks of
the customers, accepting new print jobs , accepting payments and delivering completed offset print jobs
to end customers. As an addition an information module was suggested to help making high risk
business decisions.
C++/C is a high level programming language which is well matched to linux based gnome destop
based developments. As other programming languages only open source onces are used, for a example
for the web site ,it's PHP and Apache2 server. Further MySql database server have been used because
it have well tested and free for the linux enviroment. The system was planed to implement on low cost
intel hardware as the end of the project.
In future the system would be completely ported into the ARM architecture for energy efficiency.So the
software system have been developed portability in mind. So platform independent tools and API's
such as GTK have been choosed.
ii

Acknowledgement
I would like to thank Udara Type Setting and it's owner Mr. M.T.Perera for allowing me doing this
project to his printing press. I should also thank to Dr. Viraj Pinto who is the managing director of the
Matrix Institute of Information Technology who encourages me and supervise my project.
Completing this project up to this extend is not an easy task. There are lots of people who are beind this
and who have helped me. Finally my gratitute also gone to all of my instructors, teachers and friends
who helped and encourage me on various technical difficulties during the project activities.
Secondly my gratitute is going to all online people in stackexchange Q&A community for helping me
on my technical matters.
iii

Table of Contents
CHAPTER 01 – INTRODUCTION..........................................................................................................1
1.1. Mortivation.....................................................................................................................................1
1.2 Brief Introduction............................................................................................................................1
1.3 Scope Of The System......................................................................................................................2
1.3.1 Limitations...............................................................................................................................2
1.3.2 Scope.......................................................................................................................................2
1.3.3 Technology...............................................................................................................................2
CHAPTER 02 – ANALYSIS.....................................................................................................................3
2.1. Requirement Analysis.....................................................................................................................3
2.2 Identify Users..................................................................................................................................3
2.3 Functional Requirements.................................................................................................................5
2.3.1 Basic User Functionalities.......................................................................................................6
2.3.2 Basic Administrator Functionalities........................................................................................6
2.3.3 Basic Receptionist Functionalities...........................................................................................8
2.4 Non Functional Requirements.......................................................................................................10
2.4.1 Security..................................................................................................................................10
2.4.2 Easy To Learn User Interfaces...............................................................................................11
2.4.3 Legal Requiremetns...............................................................................................................12
2.5 Hardware And Software Requirements.........................................................................................12
CHAPTER 03 - DESIGN........................................................................................................................13
3.1 Introduction...................................................................................................................................13
3.2 System Decomposition Into Modules...........................................................................................13
3.2.1 Customer Handling Module..................................................................................................13
3.2.2 Payroll Module......................................................................................................................15
3.2.3 Resource/Procument Module.................................................................................................17
3.2.4. Information Module..............................................................................................................17
3.3 Structural Design...........................................................................................................................18
3.4. Database Design...........................................................................................................................19
3.5. Overall Architecture.....................................................................................................................20
3.6 User Interface Design....................................................................................................................21
3.6.1 Administrator Console...........................................................................................................22
3.6.2 Receptionalist Console..........................................................................................................24
3.6.3 Web Site.................................................................................................................................25
CHAPTER 04 – IMLEMENTATATION.................................................................................................28
4.1 Introduction...................................................................................................................................28
4.1.1 Programming Lanagues Used................................................................................................28
4.1.2. Libraries and APIs................................................................................................................28
4.1.3 The Operating System and software platform.......................................................................29
4.2 User Interface Implementation Concerns......................................................................................30
4.3 Algorithms.....................................................................................................................................33
4.3.1. Text Processing Algorithms..................................................................................................33
4.3.2 State Charts............................................................................................................................34
4.4 Data Structures..............................................................................................................................34
4.4.1. Standard Template Library Containers.................................................................................34
4.4.2. Link Lists..............................................................................................................................35
iv

Chapter 05- EVALUATION.....................................................................................................................36
5.1 Introduction...................................................................................................................................36
5.2. Code Coverage Testing.................................................................................................................36
5.2.1 Statement Coverage...............................................................................................................36
5.2.2. Path Coverage.......................................................................................................................37
5.2.3. Entry Exit Coverage.............................................................................................................38
5.2.4. State Coverage .....................................................................................................................39
5.2. Penetration Testing.......................................................................................................................39
5.3. Unit Testing..................................................................................................................................40
5.4. Integration Testing........................................................................................................................41
5.5. Load Testing.................................................................................................................................44
5.6. User Feedback..............................................................................................................................45
CHAPTER 06 - CONCLUSION.............................................................................................................46
6.1 Introduction...................................................................................................................................46
6.2 Future Enhancements....................................................................................................................46
6.3 Lesson Learnt................................................................................................................................46
References................................................................................................................................................48
Appendix A-SYSTEM DOCUMENTATION..........................................................................................49
A.2 Installing the Dependencies..........................................................................................................50
A.2 Database Metadata And Initial Data Setup...................................................................................51
Appendix B – DESIGNDOCUMENTATION.........................................................................................52
B.1 Flow Charts...................................................................................................................................52
Appendix C – USER MANUAL.............................................................................................................55
C.1 Login.............................................................................................................................................55
C.2 Main Navigation...........................................................................................................................55
C.3 Manage Pending Users.................................................................................................................57
C.4 Manage Customers.......................................................................................................................58
C.5 Incomming Print Requests............................................................................................................58
C.6 Search Facilities............................................................................................................................59
Appendix D- Code Listing.......................................................................................................................61
Appendix E-Client Certificate..................................................................................................................63
Appendix – F Alphabetical Index............................................................................................................64
v

Index of Tables
2.2 Identify Users.Internal Users..............................................................................................................3
2.2 Identify Users.List of External Users..................................................................................................4
2.2 Identify Users.List Of Customer Types...............................................................................................5
2.4.1 Security.Database Priviledges of each database client...................................................................11
4.1.3 The Operating System and software platform.API , Operating System and Development Tools
Used.........................................................................................................................................................29
4.2 User Interface Implementation Concerns.Window ID and glade Filenames....................................31
5.2.3. Entry Exit Coverage.Loop Testing Test Results...........................................................................38
5.2.4. State Coverage .State Coverage Test Results................................................................................39
5.3. Unit Testing.Unit Test Results..........................................................................................................41
Integration Test Results...........................................................................................................................44
B.1 Flow Charts.Flow Charts..................................................................................................................54
vi

CHAPTER 01 – INTRODUCTION.
My client is a offset printing press owner and a small size businessmen in the Panadura city since
2004. As any other printing press we outsource mediumn size printing orders from our customers.
The exitsting manual system is currently keeping a large number of manual paper/file based
operations.
1.1. Mortivation.
The current press operating procedure is highly a manual one. The owner of the company does
needed to experiment with a new computer based system to handover it's manual paper based
operations. Not only the basic offset printing press functionality , it does handle customers ,
customer contract information, press operator details, payment and procument details. The report
generation feature was also added into the system for my client to aid in taking high risk business
decisions.
1.2 Brief Introduction.
The system does support basic business functionalities of my client. As a printing press ower my
client have to keep track of his customer details. Where using this new system our customers
could navigate into our site and just register into the system as a customer. System will maintain
each and every customer's persional bio-details , payment history, previous and current printing
jobs.
Each customer could make their printing job request into the sytsem. Then these requests would
be notifided to reviewed by the print administrator and to be scheduled. The finial decision about
printing it or not would be completely decided by the print administrator and he could choose to
completely ignore the request/user or add the ignored job to a ignored queue to reconsideration.
The system is also support accepting payments from customers and generating invoices.As well as
it does manage the press resources and human resources.
To continue typical business operation on a press , my client does need to keep his press resource
1

state more than a predefined threshold. So the system does implements another module to keep
the track procuments to be made and procuments which are already made.
1.3 Scope Of The System.
1.3.1 Limitations.
The system does not support onlie billing, all the billing should be done to the receptionist desk.
System does not support automatic scheduling and allocation of press resources into print job.
Orignally this project is ment to be developed as a complete automatic system but this idea have
been withdrawn due to security and legal issues.
The system is only operating under 32-bit linux x86 plactform due to technical and legal
constrains that we have at the current moment.
1.3.2 Scope.
Provide basic printing press operations like accepting print job requests, deliver bills for the
finished jobs and collect the fee. Register new customers.
Provide administration functionalities like add /register new customers , process new customer
registration requests .
Provide basic resource managemnt functionalities like papers, machine time ,ink and electricity.
Generate reports to aid high risk business decisions and keep procuments handy.
1.3.3 Technology.
Hardware.
Required x86 processor which is later or equal to P4 1.7GHz.
Required memory at least 1GB.
Software:
Linux x86 32-bit.. We are using the SMP kerenl on the solution space to utilize the
hardware.
Latest version of the Apache 2 server.
PHP 5.
Config Parser [ also one of my open source project ]
2

CHAPTER 02 – ANALYSIS.
2.1. Requirement Analysis
As I already mentioned the current system is a highly a manual system and my client not only
want to make it automated but also add some more features into the system. However to get a
more better understand about the current system I have completely study the current business
process by studying the manual documents and files.
2.2 Identify Users.
It's ideitified two major stakeholders in the system. They are receptionist and the administrator.
Their roles are as follows.
User Roles
Receptionist Accept new user registrations
Accept cash and deliver jobs and bills to
customer.
Keep the link between customer and the print
administrator.
Handover collected money to the administrator.
Accept updated information from each customers.
Accept new jobs from the customer.
Make modifications to the current scheduled jobs
or non scheduled jobs to the system.
Administrator Review new user registration requests.
Add users to ignore list.
Delete uers from the system.
Schedule or ignore new printing jobs.
Postpone printing jobs.
Review customer information.
Review previous customer payment history.
Generate various reports.
Table 1: Internal Users
3

The above two users are completely internal to the system and customers are also could be
identified as an external customer.
There are three kids of external customers have been identified. They are guest , customer waiting
for registration and registered customer. Again registered customer is divided into several
categories according to their payment history and the strength of the business association between
the client and him. For a example my client does have higher business relationship with Lakrasa
ketering services, so the customer registered representing Lakrasa need to be handled differently
than other normal customers. So various customer types have been identified. As the following
table.
Customer Type Roles
Guest Could view the web site.
He is viewing client's web site and he have
interested to be registered into the system.
Pending User Could be identified by the system using
cookies, so system should not be allowed him
to register another pending user.
Registered Customer Could update his profile.
Could make new printing requests.
Could monitor the progress of his current
printing jobs.
Access old data on previous jobs, or request
them to be prementaly deleted.
Pay fees for printing jobs and collect the job(s).
Review his payment history.
Make an feedback into the system.
Alter ongoing job.
Table 2: List of External Users.
4

Trusted Customer. The customer who does have a good customer
reltionship with my client.
Banned Customer. Customer whose profile was banned due to the
misuse of the system nor due to lots of debt to
be paid.
Full Paid Customer. The customer who had paid early for the
printing job.
Partially Paid Customer The customer who made and advancement on
his printing job. But he is a new user.
Debt Customer The customer whose printing job is going on a
credit basic. He would have to pay when he is
collecting his finished job.
Table 3: List Of Customer Types.
The print administrator could anytime label any customer and put him/her into any category.
Where administrator does no doubt have all the priviledges over the system.
2.3 Functional Requirements.
The functional requirements have been identified by interviewing users and various fact gathering
techniques. On the other hand the manual data flow have been carefully studied.
• Customers should be able to visit the web site as a guest.
• Guests could make a new customer registration request to the system.
• Administrator could review new customer registration requests and register them or ignore
them.
• System should be able to automatically switch user types of a particular user when his
credit status changed.
• The above automatic functionality should be able to control manually and further
configured to switch off this automatic feature for some customer.
• Receptionalist should be able to accept payments.
• Administrator could be able to review the incoming pending payments and clear the cache
desk.
• Receptionalist/Administrator could generate invoices.
• Users shouldm be able to make printing requests to the system.
5

• Users should be able to make printing requests to the system.
• Users should be able to ask for a termination request or a halt request from the
administrator.
• Administrator should be able to insert new procument details into the system.
• Receptionalist should be able to enter resource/raw material consumption details to the
system.
• System should be able to generate detailed reports to support high risk business decisions.
2.3.1 Basic User Functionalities.
In the manual system each uers who needed to be registered should fill a manual paper form and
handover it to the receptionist. Then these form will be forwarded to the administrator.
Administrator then review the user submitted information and then he decide whether user
information will be registered into the system or not. Administrator does keep a separate file on
each customer and with his all the previous printing jobs , payment history included. Each
customer does had a log about his payment history. This should be updated each and every
time,for a example when customer collect his finished printing job. There manual system uses 5
different racks with different colors to maintain different customer types. For a example trusted
customer files were kept in the red painted rack.
Customer registration form could collect basic bio-information about the customer and keep it in
that dedicated file. For a example a given existing record look like bellow.
Customer name: K U Rupasinghe
Customer business address: No 04, Kavi Raja Mawatha , Panadura.
Customer Contract No : 0782234523
Customer Picture: <customer picture>
Customer email: rupasinghe111@yahoo.com
2.3.2 Basic Administrator Functionalities.
The print administrator does have all the priviledges over all the business operations going on the
press. He could,
* Manage customers.
6

* Schedule printing jobs.
* View Scheduled jobs.
* Resolve conflits between scheduled jobs and jobs to be scheduled.
* Generate Reports.
* Reschedule jobs.
* Register new resources into the system.
* Diposit finished jobs in output bank.
* Be notified by the system on critical business events like procumentation.
The priviledge is identified as a main concern over administrator functions. The system does
restrict any priviledge from the administrator but support validation on his inputs. For a example
when he is scheduling a job, the system checks whether there already a job allocated for that
machine and for that time slot.
The system support administrator to take business decisions , example is when he is upto decide
whether to schedule or not to schedule a large un-paid printing job, the system aids him by
generating a report on subjected customers paid history. He could anytime disable any customer
from further adding new print requests to the system or alter his personal bio information.
On scheduling printing jobs, the system would not automatically schedule it and allocate
resources for the job. Instead it would notify the administrator and aid him to fix such confliting
scheduling issue.
The administrator could generate and compare reports on individual users and between individual
users. So administrator could further decide which customer jobs should be printed first. Another
example is regardless of customers , the administor could generate revenue reports on different
types of printing jobs, for a example how much revenue we receive from single color printing jobs
over 4 color printing jobs. Such decision is very valuable for my client to decide further investing
decisions on machines and their maintaince.
As discussed in the previous section, customers could request alternation on submitted jobs. So
the administrator could receive such request on his administrator console and take it into
7

consideration if possible. If it's not possible to do such thing, such alternation request will be
ignored and printing job could be terminated but customer have to pay the loss and he/she may
collect the partialy printed material.
As the resources are always limited and there is always a possibility to have conflits between
resources , the system aids administrator with resource management. The administrator could add
new resources to the system. Resources are papers, ink , offset machines and press operators
avaliable. Each allocated or partially terminated printing job should update a summary of
resources that consumed by the job. So the system could update it's resource status. By the way
print administrator could always update the status of avaliable resources manually at any time. So
the system could keep the up-todate resource status information.
When the job is finished the delivered job will be placed in a free customer bank while he will be
arrived and job is collected. The delivered job will be parciled properly and labled with the job
id.So when the customer comes to collect his job , print receptionist could easily query the system
and find his print job id and find where is it on the output job bank.
Administrator should be notified on certain business events. For example when the resources are
going too much low. There is a threshold value on each resource, for a example when certain kind
of A4 papers are going lower than that pre-definied threshold value, the system will generate an
noticification message to the print administrator and show it in his main administrator console
welcome page.
2.3.3 Basic Receptionist Functionalities.
The receptionist acts like an intermedite person between the administrator and client. She could
also be able to accept manual user regitration cards from customers and register him/her into the
system. When a customer have some inquery about his/her user profile, customer could come and
contract receptionist. If the receptionist have the access to do the business operation then she
could directly handle that business issue. When a job is done, the press operator submit the the
information about how much resources have been consumed on the job , so the system could aid
that information to decide a fee to finished or hold job.
8

Receptionist actions on system are always logged. So she have to answer for her actions. For a
example when a user made a payment to the system, and receptionist accepted it, then it was
logged and cash or cheaque will be kept in the receptionist cash locker while administrator could
clear it.
The overall system user case diagram would look like this. Which involves three main identified
stakeholders and the system.Users cases will be further broken into more managable parts in the
later chapters.
9

2.4 Non Functional Requirements.
2.4.1 Security.
I have identified that security as a main concern. I've stuided the security and legal concerns
regarding the current manual system and I found out the following. Only the administrator could
open the locks on racks where customer files are stored. Even receptionist should come to the
administrator and ask for a key to perform certain business operations. However receptionist
could temporary register a new user on her temporary pending book and accept full payment or
partial payments on a printing job. So in the automated system the receptionist could be able to
10
Drawing 1: Use Case For Whole System

register new users as paid customers and partially paid customers regarding a particular printing
job.
In technical terms so I have identified various INSERT and UPDATE and SELECT priviledges on
different three database users. Administrator have all the priviledges over all the tables.
receptionist does have a limited set of priviledges. In the computerized system there is one another
user called 'web_client'. It does not directly refering to a human user but refers to the web server
application with runs the client web site.
The following table explains priviledges of each database user.
User Priviledges
Print Administrator All.
Receptionalist. Insert new records to pending user table.
Update them.
Insert new payment to pending payment table.
Make updates to resource and raw material
tables.
web_client To select from customer able.
To select some several fileds from customer
table.
To select from jobs table.
To update from customer table.
Table 4: Database Priviledges of each database client
On the next two chapters design and implementation I would discuss this security and priviledge
issue more deeply.
2.4.2 Easy To Learn User Interfaces.
User interfaces should be lightweight and easy to learn. They should be self describing and
simple. Also they should avoid fancy unnecessary graphics and animations, where even a mobil
customer could simply have the accessibility to the system. User interfaces would be discussed
more widely in the implementation chapter.
11

2.4.3 Legal Requiremetns.
We should collect the information from the users which are highly necessary to our business
operation. And we are also obgligated to keep them safe and updated.
Since my client could not afford the license fee of the microsoft windows operating system we
have to keep only using open source technologies like mysql, php ,apache, linux.
2.5 Hardware And Software Requirements.
Hardware on the system should consume low power. Since we are looking for a very little server
runs linux. Probably this server could be run on a P4 old laptop computer which would cost
around 8000/- Rs on second hard market.Since we have only 100+ customers currently to handle
this server could be run on a very slow uplink. We also have to use CNAME and DDNS instead of
a static domain name.
If we could use a low cost and higher energy efficient ARM raspaberry pi board as the server and
use tablets in administrator desk and receptionist desk, that's also fine. So the system have been
modeled with almost opensource API's and dependencies so later this could be easily ported to
ARM tablet and RPI server.
12

CHAPTER 03 - DESIGN
3.1 Introduction.
As in the previous chapter Analysis we have carefully studied the overall business functionaliteis
and operations of the system. Now it's time to draw the system into bluepritns.
As a whole the system is an complicated entity. Therefore we use the method called “system
decomposition” to divide the overall system into more managable modules so and documented
interactions with them to work as a whole.
3.2 System Decomposition Into Modules.
By analyzing the system it's consie that system could be decomposed into bellow modules.
1. Customer Handling moudle.
2. Payroll module.
3. Resource/Inventory Module.
4. Information Module.
3.2.1 Customer Handling Module.
Customer handling module will undertake the basic business operations like new customer
registration, customer profile management, accepting new printing jobs to customers, notifying
customers about finished printing jobs.
The high level view of the Customer Handling module could be seen as in the bellow figure.
13

The basic business operations on the customer handling module have been detailed modeled using
DFD diagrams as bellow figure deplicits.
14
Drawing 1: Customer Handling Module User Case
Drawing 2: Customer Handling Module DFD

Each process in the above DFD diagram which are event/time critical so they are modeled by
sequence diagrams as above.
Note : Sequence diagrams for other business operations invoked by this moulde could be found in
the Appendix.
3.2.2 Payroll Module.
This module handles the basic business operations like accepting a payment from customer and
generate the invoices to the customer.
15
Drawing 3: Register New User Sequence Diagram

16
Drawing 4: Use Case Payroll Module
Drawing 5: Payroll Module DFD diagram

When the customer made a payment , his credit history should be updated. His due payments
should marked paid approprimately. The user and the print receptionist could be able to view
payment history and generated invoices . Futher the invoices could be printed and given to the
customer.
The print receptionist could take payments instead of administrator. But in such case she always
have to be reviewed and clear his cache desk by the administrator. As explained in the bellow ER
diagram.This should be done prediocally , may be once per month, every day, or once per week.
Till the receptionist handover his cache to the administrator, she is obgligated to answer about all
the incomming payments that she entered into the system.
Other diagrams corresponding to this module could be found in the Appendix.
3.2.3 Resource/Procument Module.
This module keeps the resources up-to-date which allows it's business operations could run
smoothly. There is a threshold level on each and every resource in the press. For a example when
A4 papers are going lower than 1000 of quantity the sysetm will automatically generate a
notification message to the print administrator so he should do a procument.
When a procument have been done the system should keep it's tracks. These information are
useful in generating reports. When scheduling new print job the system will always check
whether the system does have enough resources to finish that job. If not it would again notify the
print administrator for a procument.
When a job is done , the receptionist should add the resource consumption details into the system,
so system is always up-to-date after that submission.
Print admin could always alter the resource state at anytime manually. Even when he scheduling
the a job he could always skip resouce status check. Every manual resource status alternation was
logged into an external file for security purposes.
3.2.4. Information Module.
My client have a special requirement here. For example he need to compare two customers , or
generate customer ranking using his payment history. For a example when the system receives a
17

printing job from a customer who does not even paid an advancement but his history shows a
large successfully completed and paid jobs, such customer would have special priorities when
deciding whose job should to be completed first.
The customers are ranked and categorized. Customer category could be automatically updated ,
or print administrator could program the system to not to update or switch his customer category
unless explicitly stated.
Generating a summary of procument details is an essential for my client to keep future business
decisions. For a example he could decide which procuments are heavily utilized for profit.What
kind of fee adjustments should be preformed to billing, etc.
3.3 Structural Design.
The system was structured using class diagrams. The entities and relationships between them have
been identified and I have came up with the following class diagram.
18
Drawing 6: Information Module DFD diagram

3.4. Database Design.
The data which stored in the system have been modeled using the relational database modeling
techniques. Further they were normalized into the 3NF to avoid data redundancies. The following
ER diagram shows the data decomposition among various tables in the database.
19
Drawing 7: Overall Class Diagram.

3.5. Overall Architecture.
The overall architecture explains how each individual module integrate with other modules and
how it could preform as a one big system. The interactions between each module have been
carefully studied and implemented with loose coupling and high coherience in mind. Which is a
great concept highly important to future increments.
20
Drawing 8: Overall System ER diagram.

3.6 User Interface Design.
User interfaces should be carefully engineered for bellow considerations.
1. Simplisity.
2. Learnability.
3. Accessibility.
Another criteria that highly concern regarding a system like this is security and integrity of user
interfaces. User interfaces should be able to detect the mistakes done by the users.
For a example data should be validated before they are further processed , if they invalid then user
should be prompted.
On considering the security, only the data which is authorized by the preticular users should be
able to access by each users. Other concerns like validating user inputs against SQL injection is
also highly concerned.
There are main three user consoles have been identified in the system.
21
Drawing 9: Physical Overall System Architecture.

1. Administrator Console.
2. receptionist Console.
3. Web User Interface.
3.6.1 Administrator Console.
This user interface should design security kept in mind. It should implement a md5 encrypted
password mechanism and that password validation over md5 digest should be used in every
attempt login to the system. When system recieves along ideal time the console should be disabled
and prompt user to enter password back.
Glade designer have been used to generate this user interface. Since Glade files are easy to read
and understand and also it's modifiy it through the glade designer.
22
Drawing 10: User Ported to Enter His
Password.
Drawing 11: Left Plane Menu
Options

It was decided to add a tree and side plane for easy navitation. As the bellow figure deplicits. Each
window/form could be navigated by just simply clicking the side plane entries.
When searching for a particular user, the administrator definitely aid the use of filtering options
supported on search results. Shortcut keys and menu enteries have been provided to support expert
user interactions, in the case when administrator get more familiar with the system and decided to
use shortcuts instead of mouse clicks.
A Welcome window with status information have been implemented to greet the administrator and
give him brief information bout the system. Through this administrator could easily navigate into
different other windows quickly by just clicking a button or a link.
In the pending user form , all the pending user registrations have been shown in. It is decided to
implement limited serach here too.
Pending user entries could be edited using the pending user edit form as bellow.
23
Drawing 12: Pending User Requests

When a new customer is submitting a manual form and requesting to register into the system, the
administrator could add his new information using “pending user new” form.
3.6.2 Receptionalist Console.
Receptionist console also protected with a username and password. Where receptionist is
responsible for all the operations that she invoke using that console. Further all actions were
logged into a separate file. Including each logging attempt to payroll that she do.
24
Drawing 13: Pending User Edit Window
Drawing 14: Pending User New

It is choosen a 1024x728 cheap dell monitor for the receptionist console. So it should support
large font sizes.
The print administrator and the receptionalist could be able to execute search queries based on a
search parameter or a keyword.
3.6.3 Web Site.
The web user could be logged into the sysetm by just entering the username and his password.
25
Drawing 15: Email Specific Search Results.

The user could be able to fill his registration information request to register into the system.
Registered users could update their profile information using the bellow web form.
26
Drawing 16: Web User Login Prompt.
Drawing 17: Web Form Register New User

Registered users could submit a new print request using the bellow web form.
27
Drawing 19: Web Form Make New Print Request
Drawing 18: Update User Web Form.

CHAPTER 04 – IMLEMENTATATION.
4.1 Introduction.
Now blueprints of the system have been created. But nothing on paper would execute business
operations unless it was implemented. Implementation is a technology specific process, and there
are technology and software engineering issues, this chapter describes those issues in detail.
The following technologies and environments and platforms were selected and reasons were
explained.
4.1.1 Programming Lanagues Used.
PHP 5.0 was used in the project to implement the web application part of the project. PHP is good
for web site programming and easy to configure on linux platform.
• C++ was used to develop main GUI front ends for receptionlist and administrator
interface.
• C programming language was used where mysql pure C API was used.So both C/C++ was
used in mixed as in many projects.
• Makefile and bash shell scripts have been used for compiling , installing ,administrating
and initializing application.
• C++ standard template library was used.
• C standard library was also used.
• GDB was used to debug the C/C++ code.
• XDEBUG was used to debug php code.
4.1.2. Libraries and APIs.
• PHP gc image handling API have been used for converting various image types and
storing them in the database.
• Mysql C client API have been used to communicate with the underlaying database.
• My own config parser library have been used to parse ini based configuration files.
Example the administrator have a configuration file /etc/print_request_conf.conf file
which describe the various parameters on system when loading administrator console of
the program.
28

• MFDParser was suggested to use but it's still unstable so that idea was dropped in early
stages of implementation.
• Haru API was used when generating reports and write to PDF files.
4.1.3 The Operating System and software platform.
Linux was used as the operating system for web server and the administrator and user consoles,
not because it's free but because it's opensource and stable. Kali linux i386 distribution was
selected just because it comes with lots of networking friendly tools. For a example HTTP dump
tools so it ease the development.And also apache 2 ,php5 and mysql implicitly came with the
distribution so the end user or my client does not need to read pain how to documentation on how
to install them and configure them.The following table describes the versions of each software
component used in this project.
Software Component Version
Linux Kerenl 3.12-kali-i686-pae
Apache HTTP server Server version: Apache/2.2.22 (Debian)
Server built: Mar 4 2013 21:32:29
PHP5 PHP 5.4.4-14+deb7u7 (cli) (built: Dec 12 2013
10:55:22)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012
Zend Technologies
Mysql 5.5.35
Icewesel Web browser 2.20
GCC compiler toolchain 4.7.2 (Debian 4.7.2-5)
GDB GNU gdb (GDB) 7.4.1-debian
Anjuta SDK 3.4.3
Table 5: API , Operating System and Development Tools Used
Editing a large codebase is so easy with Anjuta SDK because it supports many features when
navigating between different code which are distributed in different modules. Cscope is also used
when it needed some advanced source code searching.Text editors like kate and gedit was used
during coding. Netbeans IDE was used when debugging PHP server side code.
29

4.2 User Interface Implementation Concerns.
Templates of user interfaces were designed through the glade interface designer.The version
which is used was glade. GUI template glade files are spaning across multiple files. All the glade
files were readed and initialized by the bellow code.
GError* error = NULL ;
gtk_builder_add_from_file(global.gtk_builder,
"./pending_user_show_requests.glade",&error) ;
GError* error2 =NULL;
"./pending_user_new.glade",&error2);
GError* error_date_time_widget = NULL;
"./date_time_grabber.glade" , &error_date_time_widget);
GError* error_pending_user_view_widget = NULL;
gtk_builder_add_from_file(global.gtk_builder,"./pending_user_view.glade",&erro
r_pending_user_view_widget);
GError* error_pending_user_edit_widget = NULL;
"./pending_user_edit.glade",&error_pending_user_edit_widget);
GError* error_customers_view_window = NULL ;
gtk_builder_add_from_file(global.gtk_builder, "./view_customers.glade",
&error_customers_view_window);
GError* error_customer_view =NULL ;
gtk_builder_add_from_file(global.gtk_builder, "./customer_view.glade"
,&error_customer_view);
GError* error_edit_customer = NULL;
gtk_builder_add_from_file(global.gtk_builder, "./customer_edit.glade",
&error_edit_customer);
GError* error_pending_jobs = NULL ;
"./pending_jobs.glade",&error_pending_jobs);
Code Listing 4.2.1 Loading Glade Files.
The administrator console have various kind of loadable windows. Each window have a separate
glade file describes it's geometry and widgets. There is a window ID and that's a parameter to the
window manager when you want to refer to a specific window.
30

Glade File Description Window ID
pending_user_new_requests.gl
ade
The window shows pending
user requests
WINDOW_VIEW_PENDING
_USERS
pending_user_new.glade Window that allow
administrator to enter a new
pending user
WINDOW_PENDING_USER
_NEW
pending_user_view.glade Window that shows
registration information on a
specific pending user request.
WINDOW_PENDING_USER
_VIEW_WINDOW
pending_user_edit.glade Window that allow
administrator to edit pending
user request details.
WINDOW_PENDING_USER
_EDIT_WINDOW
view_customers.glade Window which shows all the
registered users of the sysetm.
WINDOW_CUSTOMERS_VI
EW_WINDOW
customer_edit.glade Window which used to edit
customer details.
EDIT_CUSTOMER_WINDO
W
pending_jobs.glade Window which shows and
searches pending job requests.
PENDING_JOBS_WINDOW
Table 6: Window ID and glade Filenames.
As described above the administrator console is a GUI which support to navigate between
different windows. The main window is static and it acts as a container to the scrolled child
window. The left middle widget is just a GtkScrollWindow which could be loaded and unloaded.
31
Drawing 1: Geometry Of The Root Window

1. Menu Bar.
2. Tool Bar.
3. Left Side Plane Tree View.
4. Right Side Scroll Window.
5. Status Bar.
In the first initialization of each window , it should be removed from it's original root window and
then add it to the scroll window. Then it's signals were connected. Example code is bellow.
//gtk_widget_reparent(scroll_window,global.main_window);
/* attach this to main window */
gtk_container_add(GTK_CONTAINER(global.main_scroll_window),scroll_window);
g_object_unref(scroll_window);
gtk_entry_set_text( GTK_ENTRY(entrySearch), "");
done=1;
Code Listing 4.2.2 Removing Layout From It's Original Parent.
It's not only enough to load and unload the windows. Windows should be able to receive
parameters, for a example for the “edit pending user” window , it should be able to pass
parameters to it. And after saving the results it should be able to recall the previous window which
was loaded before. To implement that facility Window manager was introduced. Main toolbar
does have navigation keys to navigate back and forth on windows.
Window Manager itself keep a record of each and every window it visited, as well as parameters
passed to each and every window when it is initialized.Window Manager is internally maintaining
a window stack when navigation request was invoked the current window will be saved to the
stack and then insert the new window. Window Manager does support three main navigate
options.
1. Navigate To A New Window.
2. Navigate To Previous Window.
3. Navigate To Next Window.
Bellow flow charts describe its operations more deeply.
32

4.3 Algorithms.
4.3.1. Text Processing Algorithms.
Some text processing algorithms have been used in this application.
1. “ucuc” encoding to store md5 digest on a text file.
2. “File Ids” text string processing.
For the text processing functions , we are strongly using standard C library functions sine they are
platform independent and tested many times. The bellow is the code listing which encode a give
text to the “ucuc” format.
static char * uc_encode_md5(const char * password)
{
char digest_output[1024];
MD5_CTX md5_ctx ;
MD5_Init(&md5_ctx);
MD5_Update(&md5_ctx,password,strlen(password));
MD5_Final((unsigned char*) digest_output,&md5_ctx);
char* ret = (char*) malloc(500);
int len=0;
int i ;
33
Drawing 2: Window Manager "Navigate New" Flow
Chart.

for(i=0;i<16;i++)
{
len+= sprintf(&ret[len],"uc%d",(unsigned char)digest_output[i]);
}
return ret;
}
Code Listing 4.3.1 'ucuc' encoding to store md5 hash in pain text.
4.3.2 State Charts.
State charts have been used to process input config file. Bellow is the state chart for processing
input file.
4.4 Data Structures.
4.4.1. Standard Template Library Containers.
We are heavily depend on standard library containes like 'std::stack' and 'std::vector' instead of
arrays.They are even used when passing parameters between windows. Code example is a bellow.
34
Drawing 3: Config File Parser State Chart.

static std::vector<PrintRequest*> getByQuery(std::string /*query_in */);
Code Listing 4.4.1 Use Of Standard Library Container std::vector to return an array of objects.
4.4.2. Link Lists.
We are using link lists in the config file module to dynamically keep seesions and key-value pairs.
One session could contain multiple key value pairs. The data structure looks like bellow
illustrated.
35
Drawing 4: Link List Destructure Which Keeps sessions and key value
entities.

Chapter 05- EVALUATION
5.1 Introduction
Now it's necessary to find out that whether this software system meet it's functional and non
functional requirements.
We have used following testing methods.
• Code Coverage Testing.
• Penetration testing.
• Unit Testing.
• Integration Testing.
• Load Testing.
• User Feedback.
5.2. Code Coverage Testing.
Since this is a software which was written in a C++ , code coverage testing should be used. Since
the C/C++ is considered as error prone programming language than other languages shuch as C#.
Code coverage had done in bellow four methods.
• Statement coverage.
• Path Coverage.
• Entry/Exit coverage.
• State coverage.
5.2.1 Statement Coverage.
Ensures that there are no executed statements during testing. Every branch have been taken during
testing and no bugs are left behind.
The tools used in this session are the GNU GDB debugger and we are making a test case and
stepping through the code and ticking each executed statement number in a cell sheet [ could use
open office calc lke spread sheet program for this BTW].
36

Multiple test data had to be generated to cover all the code in here.
It's used the flow chart in aid when need to markup branches that are taken , by ticking taken
paths at the flow chart help to ensure that whether all the branches were taken during testing.
5.2.2. Path Coverage.
Even all the statements are covered through the test data, there may be path flows which would
result some un expected behaviour in a software. There are essential paths which is considered.
Test data have generated to flow execution in pre suggested path and tested for it's correct
behaviour.
37
Drawing 1: Code Listing During Code Coverage
Tool.
Drawing 2: Generated Test Results For
Code Coverage.

It's not possible to cover all paths in any software, because number of paths that program could
travel are expontially proportional to it's number of decisions. So only few specific paths were
considered.
5.2.3. Entry Exit Coverage.
Every loop or function which is entered should be exited or terminated. In a case of a loop , test
data should be generated to check that loop was executed ,
• zero time.
• One time
• n times.
For a example the loop in the bellow code listing.
while( print_request_iterator != pending_job_vec.end() ) {
PrintRequest* print_request = *print_request_iterator ;
gtk_list_store_insert_with_values( list_store , NULL ,-1 ,
0, print_request->m_job_id , 1,
print_request->m_user_name.c_str() ,
1, print_request->m_extra.c_str() , 2 ,
print_request->m_user_name.c_str() ,
3, print_request->m_date_time.c_str() , -1);
print_request_iterator++;
}
Code Listing 5.2.3.1 Loop Coverage Test For a Particular loop.
Bellow are the test results.
Test Case Result
Zero Time PASS
One Time PASS
N Times PASS
Table 7: Loop Testing Test Results
38

5.2.4. State Coverage .
In the config file parse module , there's a state machine which was used to process configuration
file.It's all states should eansured that at least one time covered by the test data there.So test data
should be generated to cover all states.Therefore it had to generate multiple test inputs.
Bellow are test results obtained. To ensure that each state have reached GDB debugger
breakpoints were used.
State Result
CONFIG_STATE_1 REACHED
CONFIG_STATE_ERROR REACHED
CONFIG_STATE_START REACHED
Table 8: State Coverage Test Results.
5.2. Penetration Testing.
Since this is a web application it's necessary to check the server interface for possible attacks. One
of a serious lame attack was ' or 1=1--' attack. So the login entry have been checked against that
attack.
39

Test Result Currently Vulnurable. Need to Fix.
5.3. Unit Testing.
Each module should be white box checked before it was integrated into the system. But some
modules are not standalone and it's existance depends on other modules. In that case we have
simulate them or their behaviour and test ioslated. Bellow code listing explains how we set up
some mimic the database module to conduct unit testing on 'file' class(file.cpp).
static void init(){
global.is_database_initialized= TRUE;
global.mysql_connection = mysql_init(NULL);
if(global.mysql_connection == NULL) {
printf("error allocating memoryn");
exit(0);
}
MYSQL* ret
=mysql_real_connect(global.mysql_connection,"localhost","print_admin","nature"
,"print_request",0,NULL,0) ;
if(ret==NULL)
{
printf("Error had happened of mysql_read_connect() n");
exit(0);
}
}
Code Listing 5.3.1 mimic the database module by manually assigning it.
Unit tests have been conducted to almost all modules in the program and obtained test results
explicited by the table bellow. You could find unit test results in “test_cases” directory.
40
Drawing 3: Penetration Test Result.

Test file name Module Functions Tested
/test/file.cpp /file.cpp Create a new file.
Create a database based file.
Create a disk based file.
Load file.
Save file into a directory.
Load temporary file.
Update file.
/test/test_file_manager.cpp /file_manager.cpp Insert a new file.
Update a new file.
View files.
Delete file.
Open file.
/test/test_customer.cpp customer.cpp Create a new customer object.
Serialize to db functions.
Read from id function.
Load and save image function.
/test/test_image_class.cpp image.cpp Read image from db.
Create a new image object.
Seralize functions.
Save to directory function.
Load as GTK widget.
Table 9: Unit Test Results
You could find all the unit tests in the /projectdir/test/ directory.
5.4. Integration Testing.
Unit testing alone is not sufficient , it's necessary to test the how modules will work together as a
whole. So bellow test cases have been conducted to ensure it's behaviour when modules are
integrated.
Following are few integration test cases with screenshots.
41

View Pending User PASSED
Loading Pending Users PASSED
Edit Pending User PASSED
Pending User edit validation
testing.
PASSED
Load Customers PASSED
Edit Customer PASSED
43

Delete Customer PASSED
Load Job Requests. PASSED
Edit Print Request PASSED
Add New Print Request PASSED
Table 10: Integration Test Results
5.5. Load Testing.
It's necessary to test this web application for certain loads, for a example what will happen when
there are one thousand requests per a second ? Unfortunately due to the time limitations this
testing have been dropped from the schedule.
44

5.6. User Feedback.
User feedback testing have to be done in future.
45

CHAPTER 06 - CONCLUSION.
6.1 Introduction.
Udara type setting is a well known mediumn size offset printing press in Panadura area. They
need to computerize the their manual process of their business operations and to avoid paper
work. Earliear they have faced so much trouble with the manual paper work. But currently they
are completely handling without paper work. Registering a new user , accepting new jobs from
users, scheduling new print jobs , allocating press resources and raw materials to print jobs,
generate pay slips for hired press machine operators , keep track of the customer payment and
their files are all done automatically now.
Since the new system and the technology is helping my client to save time and money, he is
currently satisfied with the system but he still need more features to be built. However they are
outside my current project scope and they needed to be built in next increments to. By deatiled
analysis of the new system my client have identified the following future enahncements.
6.2 Future Enhancements.
* Enable online customers to add files larger than 64Kbytes.
* Some security countermeasures against DDoS attacks since when we allow adding large files for
users this will be an issue.
* Port the system to lightweight twm windowing environment.
* Add GPS based location system instead of street address for user registrations.
* Develop a google calander like user interface to view scheduled jobs in ech machine.
* Extend the system to accept pay-pal based payments from customt
* To enhance the web based interface with more flash and javascript rich technologies.
6.3 Lesson Learnt.
I have learnt many lessons during this project and I'm being tankful for UCSC to given me this
opportunity to have real life working experience building a real life system.
• Experience to deal with people, customers, press operators and built my skills on
how to make professional level professional connections on the subject of human
factor of a business.
46

• Developed my basic business analysis skills, skills on how to document a business
requirement, how to interview with stakeholder and skills on basic interviewing.
• Developed my skills on new programming languages like PHP, HTML 5 and
Javascript.
• During the evaluation phase I learn how to create basic test plan and gained basic
skills on software testing.
47

References
1. Code Complete : A Pratical Handbook of Software Construction Second Edition by Steve
McConnell.
2. MySQL in Nutshell by Russel J.T. Dyer.
3. Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma.
4. Head First C by David Griffiths and Dawn griffiths.
5. Apache Cookbook: Solutions and Examples for Apache Administrators by Rich Bowen and
Ken Coar.
6. Head First PHP & MySQL by Lynn Beighley and Michael Morrison.
7. Foundations of GTK+ Development( Experts Voice in Open Source) by Andrew Krause.
48

Appendix A-SYSTEM
DOCUMENTATION.
System Manual.
A.1 Compiling the System:
To compile the sysetm navigate to the main project directory and then type make all.
To make a complete clean built.
# make clean
# make all
NOTE: clean compilation from scratch will take up to 5 minutes.
To deploy the web site on localhost ,
#cd /project_dir
#cd site
#make deploy
49
Drawing 1: Compiling The Whole Source Code

To generate a password which is 'ucuc' encoded, navigate to the project directory, type and enter.
#./md5_password_gen
Then enter the password to be md5 hashed and 'ucuc' encoded.
A.2 Installing the Dependencies.
You need to install following packages to run and function this system correctly.
• libgtk-2.0
• mysql
• libharu
• libmysqlclient
• glade-3.12
You could use 'apt-get install' command to install those above packages or you could go to
package manager and install them manually.
50
Drawing 2: Deyploying Server Side Scripting Files On The Server.
Drawing 3: Generating MD5 crypted and 'UCUC' Encoded Text.

A.2 Database Metadata And Initial Data Setup.
To create table and setup priviledgs there is a script on the project directory to be executed.You
could automatically execute that script and have new freshed tables by invoking tables target in
the main Makefile.
# make tables
The database should have initial data to be working property. You could enter them to the database
by invoking bash script “enter_initial_data.sh” or just invoking make target 'initial_data'.
# make initial_data
There are initial data files on the database. You could go and edit initial data files manually.
Data File Contents
data_press_resources.data Contains details about press machines. Every
offset machine or other type of machine does
have a unique record with an in.
data_raw_material.data Contains all the information about paper
types,clip types or binding types.
data_human_resources.data Contains initial detailed information about press
operators.
51

Appendix B –
DESIGNDOCUMENTATION
B.1 Flow Charts.
52

53
Drawing 1: Enter New Customer Flow
Chart
Drawing 2: Create New Customer Flow
Chart.
Drawing 4: Enter New Print Job Flow Chrt
Drawing 3: General Object Seralize
Flow Chart.

Table 11: Flow Charts
54
Drawing 5: Seralize Press Resources Flow
Chart.
Drawing 6: Set New Image Flow Chart.

Appendix C – USER MANUAL.
C.1 Login.
You should setup your login passwrod md5 crypted and 'ucuc' encoded in the file main
configuration file /etc/print_request_conf.conf file. Since the settings of that file are senseative
and system depend on it, it's better to setup read and write settings only to print administrator.
[main]
LoginPassword=uc64uc90uc175uc246uc96uc130uc255uc231uc35uc29uc124uc31uc121uc146uc
108uc23
Under the session 'man' and on the key 'LoginPassword' you could have the 'ucuc' encoded
password that you desired.
When you enter to the application you need to give this password. Please note that administrator
and receptionalist does have two separate passwords. Receptionalist password is stored on the
database and could be changed by print administrator anytime.
In the case when administrator enters a wrong password, the system will wait 3 seconds before it
let the administrator to enter correct password back. This is done to avoid burte force password
cracking.
C.2 Main Navigation.
Administrator could navigate between different windows by using following three ways.
• Menus.
• Navigation Slide Plane.
• Next , Back ,Previous buttons on the toolbar.
• Buttons in the inno window itself.
55
Drawing 1: Login Prompt

The system reminds each window that administrator navigate and keep track of it. Like in any
web browser.
56
Drawing 2: Slide
Navigation Menu.

C.3 Manage Pending Users.
By just clicking menu->view->Pending Registrations or by selecting the “Pending Registrations”
on the main left plane you could see new user registration requests.
By clicking the edit button administrator could edit the request and correct errors. For me detailed
information than listed in the list above he could click view button. To delete and reject a new user
registration request he could press delete button. And to enter a new user manually he could click
new user button.
57
Drawing 3: Pending User Registrations.

C.4 Manage Customers.
Administrator could view all the registered customers by entering into the “All Customers”
window shown bellow. He could enter to this window by selecting the “Customers” option in the
slide plane or menu.
He could view customer information in more advanced by pressing the view button or edit
customer details by pressing the “edit” button. A new customer could be added by pressing “new”
button as well as delete an existing customer by pressing the “delete” button.
C.5 Incomming Print Requests.
You could navigate into “incomming print requests” window by using menu or slide plane as
bellow.
58
Drawing 4: Customers Show Window.

He could aslo use the “new” button to make a new request manually, or press “edit” button to edit
existing request or press “delete” button to delete an existing record.
C.6 Search Facilities
To make it easy find appropriate entity in a main view window , a search box with advanced
search option have been implemented. The search box supports following search modes.
59
Drawing 5: Incoming Print Requests.
Drawing 6: An Advanced Serach Based On User Name.

Serach based on user name. For a example only to show customer enteries which from customer
'root' you could type in the search box, 'username:root'.
Email and telephone number based searches are also supported.
The search syntax is as follows.
<search_key>:<search_text>
search_key: could be 'username' , 'tel_no' or 'email'
search_text: If wants to search based on 'username' and then this filed should be appropriate
name of the user.
60

Appendix D- Code Listing.
main_window =
GTK_WIDGET(gtk_builder_get_object(global.gtk_builder,"main_window"));
tree_view =
GTK_TREE_VIEW(gtk_builder_get_object(global.gtk_builder,"treeview1"));
scrolled_window =
GTK_WIDGET(gtk_builder_get_object(global.gtk_builder,"scrolledwindow1"));
load_glade_files();
global.is_main_window_initialized = TRUE;
global.main_scroll_window = scrolled_window;
global.main_window = main_window;
Listing D.1 Connecting Signals To Widgets.
/* check for the prerequisites */
if( ! global.is_database_initialized )
{
printf( "PendingUser::getAllPendingUsers() Database should be initialized
before calling this.n");
exit(0);
}
D.2 Checking For Prerequisites.
int DATABASE_init()
{
if( global.is_database_initialized )
{
printf("Database connection is already registered ");
exit(0);
}
if(! global.is_config_initialized)
{
printf("Config should be initialized before databasen");
exit(0);
}
MYSQL* connection = mysql_init(NULL);
61

if(mysql_real_connect(connection,global.database_ip_address,global.administrat
or_database_username,
global.administrator_database_password
,global.database_name,0,NULL,0) == NULL)
{
fprintf(stderr,"%sn", mysql_error(connection));
mysql_close(connection);
exit(0);
}
global.is_database_initialized = TRUE;
global.mysql_connection = connection;
return 0;
}
D.3 Connecting To The Database.
// query //
const char * database_query = "SELECT * FROM pending_user_registration;" ;
if( mysql_query ( global.mysql_connection,database_query) ){
fprintf(stderr,"%s n", mysql_error(global.mysql_connection));
exit(0);
}
D.4 Executing Mysql Query.
62

Appendix E-Client Certificate
63

Appendix – F Alphabetical Index.
Alphabetical Index
A
administrator.....................................................................1, 3, 5-12, 17, 18, 22-25, 28-31, 55-58, 62
C
C++..................................................................................................................................................12
C++ Programming...........................................................................................................................12
configure................................................................................................................................5, 28, 29
Connecting.................................................................................................................................61, 62
customer............................................................1-8, 10-15, 17, 18, 24, 30, 31, 41, 43, 44, 46, 58, 60
D
Development....................................................................................................................................29
F
fprintf...............................................................................................................................................62
H
HTTP...............................................................................................................................................29
L
Linux................................................................................................................................2, 12, 28, 29
Login..............................................................................................................................22, 39, 42, 55
O
open source..................................................................................................................................2, 12
P
Payroll........................................................................................................................................13, 15
PHP..................................................................................................................................2, 28, 29, 47
Q
Query.....................................................................................................................................8, 35, 62
R
Request.....................................................................1-8, 24, 26-28, 30-32, 35, 38, 40, 44, 55, 57-59
64

0512575 printing request_and_press_resource_management_system_for_udara_type_setting_in_panadura

Recommended

Recommended

More Related Content

Similar to 0512575 printing request_and_press_resource_management_system_for_udara_type_setting_in_panadura

Similar to 0512575 printing request_and_press_resource_management_system_for_udara_type_setting_in_panadura (20)

More from Sandun Perera

More from Sandun Perera (6)

Recently uploaded

Recently uploaded (20)

0512575 printing request_and_press_resource_management_system_for_udara_type_setting_in_panadura