WILBERFORCE ISLAND, P.M.B.

091,
YENAGOA, BAYELSA STATE,
NIGERIA

UNDERGRADUATE PROJECT

ENHANCED DECISION SUPPORT SYSTEM FOR ONLINE TENDERING

YOUR FULL NAME

MAT. NO

APRIL, 2024

i
 ENHANCED DECISION SUPPORT SYSTEM FOR ONLINE TENDERING

YOUR FULL NAME

MAT. NO

RESEARCH PROJECT TO THE DEPARTMENT OF COMPUTER SCIENCE,

FACULTY OF SCIENCE, IN PARTIAL FULFILMENT OF THE REQUIREMENTS
FOR THE AWARD OF BACHELOR OF SCIENCE DEGREE (BSc) IN COMPUTER
SCIENCE.

APRIL, 2024

ii
 Declaration

I, YOUR NAME with Matric Number: ………….. declare that this Project on

the Topic: ENHANCED DECISION SUPPORT SYSTEM FOR ONLINE TENDERING

was carried out by me; that this is my original work and that it has not been submitted wholly or

in part for the award of a degree in any institution.

YOUR NAME Signature/Date: ……………………..

iii
 CERTIFICATION

NIGER DELTA UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE
FACULTY OF SCIENCE

ENHANCED DECISION SUPPORT SYSTEM FOR ONLINE TENDERING

BY

YOUR FULL NAME

MAT. NO

The Board of Examiners certifies that this Project is accepted in partial fulfillment of the
requirements for the degree of Bachelor of Science (BSc) in Computer Science.

Dr. Bunakiye R. Japheth ................................ …………………

(Project Supervisor) Signature Date

Dr. Dr. Bunakiye R. Japheth …….………………... ……………………

(Head of Department, Signature Date
Computer Science)

Prof. A Inengite ………...………….. ……………………...

(Dean, Faculty of Signature Date
Sciences)

Prof. Jackson Akpojaro ……………………… ……..………………..

(External Examiner) Signature Date

iv
 DEDICATION

This research work is dedicated to the Almighty God and

………………………………………….

v
 ACKNOWLEDGEMENT

I want to sincerely express my profound gratitude to God Almighty for His grace and guidance

in my life and throughout my study days. My special appreciation goes to my supervisor, Dr.

Bunakiye R. Japheth who in spite of his numerous responsibilities found time to read all the

chapters of this work and made necessary corrections, suggestions and comments that led to the

successful completion of the project work, please Sir, I am grateful.

My gratitude also goes to my lecturers namely: ………………………….

My profound thanks go to my mother ……………………………

The support and encouragement given to me by the following people deserve a special mention:

……………………..

I will not fail to appreciate the support given to me by my beloved ……………………..

vi
 ABSTRACT
In other to maximize the full potentials of information technology, both private and public
establishments have been increasingly exploring and migrating manual processes into automated
processes and the tendering system is not left out in these innovative migrations. This project
work is aimed at developing an enhanced decision support system for online tendering which has
helped to speed up decision making processes that improve the efficiency of the online tendering
process. The specific objectives of this research work are to; Examine the current decision support
system for the online tendering, design an enhanced decision support model for commercial bid
evaluation in online tendering, Implement the enhanced decision support model for the online
tendering and to evaluate the developed enhanced decision support model for the online
tendering. The Object-Oriented Analysis and Design method has been used in the development
of this project work with the unified modeling language (UML) diagrams used to explain the
workability of the various objects of the system. All the modules of the developed system have
worked according to specifications and design, and the system performed excellently well. The
system has enhanced significantly the time taken to analyze and make decision cutting down cost
of printing.

vii
 TABLE OF CONTENTS

Cover page i

Title Page ii

Declaration iii

Certification iv

Dedication v

Acknowledgements vi

Abstract vii

Table of Contents viii

List of Tables xi

List of Figures xii

References xiii

CHAPTER ONE: INTRODUCTION

1.1 Background to the Study 1

1.2 Statement of the Problem 3

1.3 Aim and Objectives of the Study 4

1.4 Significance of the Study 4

1.5 Scope of the Study 4

1.6 Limitations to the Study 5

1.7 Definition of Terms 5

viii
CHAPTER TWO: LITERATURE REVIEW

2.0 The Review of Related Literatures 8

2.1 Theoretical Framework 8

2.1.1 The Theoretical Idea of Tender and Online Tendering 8

2.1.2 The Theoretical Idea of Decision Support System 11

2.1.3 Types of Decision Support System 14

2.1.4 The Theory of Enhanced Systems 16

2.2 Conceptual Framework 16

2.2.1 The Concept of Enhanced Tender and Online Tendering 16

2.2.2 The concept of Enhance Decision Support System 20

2.3 Review of Empirical Studies 24

2.3.1 The Use of Decision Support System 24

2.3.2 A Review Relating to Online Tendering System 27

2.3.3 Electronic Tendering In Procurement 31

2.3.4 Electronic Tendering In Construction 34

2.3.5 Tendering Evaluation in Nigerian Public Sector 41

2.3.6 Tendering System in Government Sector 47

CHAPTER THREE: SYSTEM ANALYSIS AND DESIGN

3.1 Methodology 50

3.1.1 Tools and Technique 50

3.2 Analysis of Existing System 50

3.2.1 Architectural Framework of the Existing System 51

3.2.2 Constraints of the Existing System 52

3.3 Analysis of the Proposed System 53

ix
3.3.1 Architectural Framework of the Proposed System 54

3.3.2 Object Oriented Analysis and Design 55

[Link] Use CASE Diagram 56

[Link]. Activity Diagram 58

[Link] Class and Relationship Diagram 59

3.4 System Design 59

3.4.1 Input Design of the Proposed System 60

3.4.2 Process Design of the Proposed System 60

3.4..3 Output Design of the Proposed System 61

3.5 Database Design of the Proposed System 63

3.6 Decision Support System for the Proposed System 65

CHATPER FOUR: SYSTEM IMPLEMENTATION

4.1 Choice of Development Environment 68

4.11 Justification of Choice of Environment 68

4.2 Implementation Architecture 69

4.3 System Testing 69

4.3.1 Create Tender Form Interface Display 70

4.3.2 Create Bid Form Interface Display 70

4.3.3 View Created Bids of Registered Users 71

4.3.4 View Accepted Bids from Admin 72

4.3.5 View Accepted Bid by the User 73

4.3.6 User Dashboard Interface Display 74

4.4 Result and Discussion 75

4.5 Documentation 75

x
4.6 System Setup and User Manual 76

CHAPTER FIVE: SUMMARY, CONCLUSION AND RECOMMENDATION

5.1 Summary 79

5.2 Conclusion 80

5.3 Recommendations 80

5.4 Contribution of the Author 80

5.5 Suggestion for Further Studies 80

References 82

Apendix A 85

Apendix B 125

xi
 LIST OF TABLES

Table 3.1: User Table of the Proposed System 63

Table 3.2: Tender Table of the Proposed System 64

Table 3.3: Bid Table of the Proposed System 64

Table 3.4: Bid Acceptance Table of the Proposed system 65

Table 3.5: Notification Table of the Proposed System 65

xii
 LIST OF FIGURES

Figure 3.1: Architectural Framework for the Existing System (Priya & Ramamoorthy, 2016) 51

Figure 3.2: Architecture Framework for the Proposed System 54

Figure 3.3:Admin Use CASE Diagram for the Proposed System 56

Figure 3.4. User Use CASE Diagram for the Proposed System 57

Figure 3.5: Activity Diagram for the Proposed System 58

Figure 3.6: Class Diagram for the Proposed System 59

Figure 3.7: Input Design of the Proposed System 60

Figure 3.8: Process Design of the Proposed System 61

Figure 3.9: System Administrator Bid Preview Output Design of the Proposed System 62

Figure 3.10: Accepted Bid and Company Information Output Display of the syste 63

Figure 4.1 Implementation Architecture of the Developed System 69

Figure 4.2 Create Tender Form Page of the Developed System 70

Figure 4.3: Create Bid Form for Published Tender of the Developed System 71

Figure 4.4: Member Bid Display Screen of the Developed System 72

Figure 4.5 The view Accepted Bid Display screen of the Developed system 73

Figure 4.6: Accepted Bid Page Display from the User Section of the Developed System 74

Figure 4.7: User Dashboard Display Screen of the Developed System 74

xiii
 CHAPTER ONE

INTRODUCTION

1.1 Background to the Study

Domain-Specific Modeling (DSM) raises the level of abstraction beyond programming by

specifying the solution directly using domain concepts (Kelly and Tolvanen, 2008). The final

products are generated from these high-level specifications. This automation is possible because

both the language and generators need fit the requirements of the domain. The most logical

reason to use DSM is simply the increased productivity. According to Software Productivity

Research (ISVWorld, 2010) the average productivity in Java is only 20% better than in BASIC.

C++ fares no better than Java.

There was actually up to 400% increase in productivity level from Assembler to BASIC. The

400% increase was because of a step up to the next level of abstraction. Each statement in C++,

BASIC or Java corresponds to several statements in Assembler. Most importantly, these

languages can be automatically translated into Assembler. In terms of productivity, this means

only a line of code of either of C++, BASIC or Java could do the work for up to five or more

lines of code in Assembler.

Traditional modeling languages like UML have not also increased productivity, since the core

models are on the same level of abstraction as the programming languages supporting them. The

user still need to code by hand to conform to the objects constraint language (OCL) and the

meta-object facility (MOF) diagram definition standards (Giovanni et al., 2009). Conventional

computer aided design and modeling systems has never helped either. Manual editing is still

required to complete a modeling task; and it could take a whole day worth of code to define

1
behaviours of solids. All of these tasks are attempts trying to maintain the same information in

two places, code and models, and that's always a troublesome technique.

Why was that leap between Assembler and BASIC so big, and how can we achieve it again

today. The reason was because abstractions about the Assembler instances were raised and

hidden under the BASIC code. We can as well achieve the same productivity level in software

development by adopting Domain-specific modeling for productivity. Domain-Specific

Modeling raises the level of abstraction and hides today's programming languages, in the same

way that today's programming languages hide assembler. Symbols in a domain-specific model

map to things in the domain, the creation in which the application is to run.

This is a whole level of abstraction higher than code centered developments, and makes each

symbol worth several lines of code. The application is automatically generated from these high-

level specifications with domain-specific code generators, aided where necessary by existing

component code. As the name suggests, Domain-Specific Modeling is only possible because it

narrows down the design space or domain, often to a single range of products for a single

domain.

The target domain in this research is oil and gas pipeline systems. The ranges of products in this

domain of our interest are the pipeline physical components, which are the models of

computation (Zezula, 2000). The research interest in this work is to see how modeling pipeline

systems can be enhanced by raising the abstractions about the domain model and considering

appropriate concepts (concepts: a prescriptive list of all the salient technical characteristics

prevalent with oil and gas pipeline systems) for the abstraction levels.

To achieve this success of hiding the complexities associated with UML, general-purpose

languages (GPLs), and CAD systems, we need to get to a situation of domain-specific modeling.

Three things are possible: a domain-specific modeling language and editor, a domain-specific

2
code generator, and a domain-specific component library. This work is therefore dedicated to

the development of a transmission pipeline systems modeling language and associated

components for implementation and evaluation.

1.2 Statement of the Problem

A domain-specific language (DSL), which is invariably a domain specific modeling language, is

a computer language specialized to a particular application domain. This is in contrast to a

general-purpose language (GPL), which is broadly applicable across domains, and lacks

specialized features for a particular domain.

General purpose software design and development tools such as conventional programming

languages (C++, Java, C# etc.), and CAD systems (AutoCAD, Solid Works, ArchiCAD,

RapidVu etc.), which fall under the category of GPLs usually adhere to a protocol. AutoCAD

software, for example, is the industry-standard design tool for 2D drafting and detailing, and for

3D work. It provides native DWG compatibility, plus the ability to personalize the software or

add third-party applications for specific design requirements.

It features new productivity tools, presentation graphics, CAD standards, and more for faster,

easier data creation and sharing. For many CAD designers, drawing the design from scratch is

very tedious. Like every time they have to draw some lines, circles, donuts, text etc. for every

new project. To eliminate this repetitive work AutoCAD has provided its managed dynamic link

libraries access its functionality. C# can be used to draw AutoCAD objects and access AutoCAD

functions.

If all these potentials are very possible with AutoCAD; then some very important questions such

as the ones listed below may arise.

1. What is the trade-off of switching from a CAD system to using the proposed language?

3
2. Could the benefits of expressing every detail of the pipeline overcome the simplicity that

normally is associated to a CAD system in terms of usability for the user?

3. What clear benefit can be gained using the approach over existing approaches?

4. How is the DSML used?

5. What evidence is there for its benefits/effects?

6. Why is a DSML needed at the first place?

The trade-off of switching to using this language is reduction in design time and cost of

operations. For example, BG Technical Nigeria Limited, an oil and gas servicing company

located in Nigeria is having a whole department dedicated to trained CAD software professionals

whose job is to oversee and attend promptly to varying engineering designs and fabrication

considerations. The simplicity in usability of this language is clearly exemplified in the

vocabulary of components. Having captured the vocabulary and then translated into a modelling

platform, the users need not any engineering design expertise to get their design intents achieved.

In optimal cases, programming expertise must be needed to achieve some design intents. For

example, a particular API call sequence that is required to create executable commands.

Generally, these rules are at the same level of abstractions within the mechanism that implements

them; the problem is that it creates a substantial semantic gap between design intent and the

expression of this intent in several lines of codes.

The clear benefit is that in this language, the metamodel is a repository of concepts from the oil

and gas pipeline domain. The models are constructed using these concepts and not the concepts

of a given programming language. Therefore the semantic gap between design intent and the

expression of this intent in several lines of codes is bridged. The users have the freedom of

expressing their intents through familiar domain representations; without facing any difficulties

of how the policies are mapped onto the underlying mechanisms implementing them. We are

4
motivated to solving this problem by coming up with a domain specific language formalism that

separates the policies and the mechanisms that implements them. A metamodel about a pipe line

systems domain model is defined with focus on closing the semantic gap by mapping domain

concepts to appropriate levels of abstractions.

1.3 Aim and Objectives

The aim of this research is to develop a domain specific modelling language (DSML) for

modelling oil and gas pipeline systems.

The objectives for achieving the aim are as follow:

1. To analyse the existing domain of oil and gas pipelines in order to come up with

requirements engineering framework

2. To design a structure for the execution of the modeling tool

3. To implement the proposed modeling language system

4. To evaluate the metrics of success of the software solution

1.4 Scope of the Study

The possibility of this research is in utilizing domain specific modelling technologies in pipeline

systems metamodeling. In the domain of oil and gas transmission pipeline engineering, there

have been constant demands for more cost-effective and efficient tools and methodologies that

could aid better, and provide faster and productive solutions to production of artefacts for

pipelines systems. The use of Computer Aided Design (CAD) systems provides such tools that

represent a technological advancement in computer software that has also expanded into

Computer Aided Manufacturing and Computer Aided Engineering.

Though common interactive CAD systems (e.g. AutoCAD) are effectively utilized by designers

for modeling graphics through graphics design analysis, they do lack the necessary power to

5
express the specifications of these models in a language (i.e., formal notations), which could

enable the systematic representation of the various facets of the specific pipeline domain.

The activity involves developing a system that could tackle all the identified complexities of

conventional modelling systems, it will enable stakeholders to handle modeling for only oil and

gas pipeline common features and not machine implementation. It simply offers primitives

whose semantics are familiar only to oil and gas transmission pipeline policy mechanisms.

1.5 Significance of the Study

General purpose programming languages and computer aided design systems are characterized

with the complexities of time consuming, syntax oriented and code centred development to

achieving results in particular problem spaces. This means they cannot express domain concepts

appropriately. With this well-defined domain specific modeling (DSM) approach, this inability

can be tackled. This new platform, which is simply a domain specific modelling language will

increase productivity as it provides non-programmers and domain experts the resource to operate

on very familiar notations and achieving great results without bothering on how the system is

working, and without being burdened by its syntactic or semantic requirements.

1.6 Limitation of the Study

May be in the near future but our system does not contain in its language definition logic the

capability to satisfy multiple design tasks and conformance. However multiple design intents can

be accommodated.

Though in our approach, model transformation between platforms is more or less an internal data

source binding activity, we are to some extent bound by the properties of the visual studio SDK.

Also, though a detailed stakeholder’s variability analysis is incorporated; one major disadvantage

6
with ours is the non-inclusion of an analysis module that allows stakeholders to perform domain

analysis via the system.

Another identified limitation is in the fact that thorough performance evaluation cannot be

performed without the presence of domain experts.

1.7 Definition of Technical Terms

1. Domain-specific modeling (DSM): Creating and using modeling languages that are

targeted for a narrow problem domain; often, to generate full code from the models.

2. Model-driven architecture (MDA): The Object Management Group's approach to

model-driven development, relying largely on UML.

3. Software factories: Microsoft's approach to automating development, using DSM in a

central role.

4. Unified Modeling Language (UML): The Object Management Group's set of general-

purpose modeling languages for any problem domain, but focused on implementation

with an object-oriented programming language.

5. General purpose modeling language (GPML): provides modellers with rudimentary

concepts such as ‘Class’, ‘Attribute’ etc. only.

6. Domain Specific modeling language (DSML): includes higher level concepts that are

reconstructions of technical terms in the targeted domain, e.g. ‘Organisational Unit,

‘Business Process’, ‘Strategic Resource’ etc. Therefore, the modeller is not forced to

specify these high level terms on his own. Instead he may reuse the concepts of the

DSML.

7. Models: Models are simply outcomes from abstractions.

7
8. Abstraction: is simply human conceptions/expressions of a characteristic different from

specific object that relate to a domain

9. Modelling: is the act of creating models that can be processed to produce an artefact.

10. Modelling Language: is a platform with which models are created (hidden from the

user) and then allows processing to generate the desired artefact.

11. Abstract Syntax: means the appearance and structure of sentences in a computer

language. They are the rules for combining language constructs or concepts.

12. Concrete Syntax: means the graphical representation of a domain knowledge/notations.

13. Semantics: is the meaning of the language concepts, comprises semantic domains and

semantic mappings of concepts to the domains (actually following the abstraction rules).

CHAPTER TWO

LITERATURE REVIEW

2.1 Solid Modeling

Solid modeling (Autodesk Inc., 2013) is the process of building up of solid models (objects)

from primitives. Primitives are geometric shapes found in common computer aided design

8
(CAD) systems such as AutoCAD. Examples of primitives are torus, cone, cylinder, sphere, box

and prism.

Possible operations found in common CADs for solid modeling include extrusion, revolution,

sweep and Boolean operations such as union, subtraction and intersection. Illustrated in figure

2.1 is the model of a bolt head designed using constructive solid geometry (CSG) design

technique, were the components are combined through Boolean operations to produce the solid

(Andrade, 2011).

Figure 2.2 depicts a sweep representation of a set of pipes where the shapes are moved along a

path through a region of space (Alessandro, 2010). Illustrated in figure 2.3 is a B-rep model of

pipe elbow with flanges constructed using surfaces, curves and points and represented in a 3D

space (Andrade, 2011).

Figure 2.1: Bolt-head Solid Model

9
 Figure 2.2: Sweep Representation of Pipes

Figure 2.3: A B-rep Model of Pipe Elbow

Though it is possible to display in various ways and also to determine some material properties,

the solid models described in the examples above (Braha and Reich, 2001) are referred to as

dump solids for the following reasons:

1. It is difficult to change the geometry

10
2. Features contain only geometric information

3. Dimensions are static, i.e. they do not drive the geometry

4. The order of operation of the model is unavailable to the user

2.1.1 Parametric Modeling

Parametric modeling approach, recently associated with common interactive CAD systems such

as AutoCAD however addresses all of the shortcomings of dump solids. Parametric modeling

has become a basis for integration of differing possibilities of engineering designs modeling in a

homogenous platform and has provided the ability to reflect the way in which modern

manufacturing companies develop their products (Evila et al., 2012).

With parametric modeling (Leake, 2012) current Computer-aided Design systems are tools and

software packages that range from 2D vector-based drafting systems to 3D solid and surface

modelers. They are used for detailed engineering of 3D models of physical components, and also

used throughout the engineering process from conceptual designs and layout of products,

through strength and dynamic analysis of assemblies to definition of manufacturing methods of

components.

Parametric modelling (Kaskil et al., 2005) employs parametric dimensions and geometric

constraints to define features, and to create relationships between these features in order to create

intelligent models. These parts can then be combined to form virtual assembly models. Drawing

documents can then be extracted from both part and assembly models. Owing to its object-

oriented, parametric nature, parametric modeling has expanded the traditional role of CAD

beyond geometry creation and into the realm of product realization.

In parametric modeling, dimensions are associatively linked to the model geometry that they

describe. If a dimension changes, so does the associated geometry (Alessandro, 2010). Though

11
this flexibility gives the user enough room to explore design alternatives, it is still difficult for

domain specific concepts to be expressed easily during design.

2.2 Conventional Modeling

In conventional modeling objects are explicitly described, when one aspect of the model is

changed, often several changes have to be made to satisfy design intent or the implicit rules of

the design. This is because the software (Autodesk Inc., 2013) does not keep track of the rules

and the designer must decide where and when they are broken. In AutoCAD, for example

models are created in a conventional way. AutoCAD, however, comes with more than one

programming environment for creating a set of instructions, including the rules and constraints of

the design as well as parameters defining certain aspects of the design, which can be used to

build the model (Neil et al., 2007).

These instructions can be used to build a model from scratch, each time using the same

parameters, or experimenting with different ones. The parameters can be numeric values,

relationships, and can even include graphic parameters already existing in the model (e.g., a

building lot, angular pipes, etc.).

One basic challenge is the issue of interaction between models, interactions in the way of

concepts devoid of possible parametric constraints within a CAD system (Kaskil et al., 2005).

Interactions that can produce other complete models with noticeable properties relative to a

given set of concerns in relevant domains that captures accurately and concisely all of its

interpretation and design intent for specific problems and solutions. This has not been achieved

with current CAD systems, coupled with the third generation programming APIs inherent in

them, they still lack sufficient linguistic power to handle domain and platform complexities and

hasn’t moved speedily with domain technologies (Waddington and Patrick, 2006).

12
2.3 Domain Specific Languages

Domain specific languages (DSLs) are mini or special purpose languages that have been

designed and tailored for specific application domains. Some examples of domain specific

languages include Hancock, Backus Naur Form (BNF) and HTML (Marcus and Sebastian,

2010). HTML for example is a language explicitly designed for creation of web pages. With

domain specific features user of the language can construct with very familiar notations and get

desired outcomes. Presented below are a few main features of domain specific languages as

applicable to our work.

Expressiveness- Expressiveness of a language generally talks about how easy it is to express

various, often domain specific, ideas using the constructs appearing in the language. A language

is often called domain specific if it provides tailored notations and constructs for a particular

application domain. Such tailored notations and constructs allow experts from the domain to

easily express the things they require. For example, what general purpose programming

languages (GPLs) and conventional CAD systems cannot do in terms of expressing domain

concepts appropriately can be achieved by domain specific languages.

Extension- Another characteristic feature of a domain specific language, is that the language is

based on some existing language which has either been extended with extra features and

constructs that are only applicable to the domain under consideration or started up with new

features but built on top of an existing language.

Restriction- A language is domain specific if it is restricted to a sub language allowing the re-use

of tools and other features available for the language, provided that only certain `restricted'

programs may be created using the language.

2.3.1 Reasons for Developing Domain Specific Languages

13
A domain specific language is a language that is provided by a programming library or

Application Programming Interface (API) for an existing general purpose language. This means

in combination with an application library, any GPL can act as a DSL. The library’s Application

Programmers Interface constitutes a domain-specific vocabulary of class, method, and function

names that becomes available by object creation and method invocation to any GPL program

using the library.

Since DSLs are so functionally related to GPLs, why develop DSLs? The reasons are simple,

DSLs can:

i. Offer established domain specific notations beyond the limited user-definable operator

notation offered by GPLs.

ii. Appropriate domain-specific constructs and abstractions cannot always be mapped in a

straightforward way by GPL to functions or objects that can be put in a library. A GPL in

combination with an application library can only express these constructs indirectly or in an

awkward way. Traversals and error handling are typical examples.

iii. Offer possibilities for analysis, verification, optimization, parallelization, and

transformation in terms of DSL constructs that would be much harder or unfeasible if a

GPL had been used because the GPL source code patterns involved are too complex or not

well defined.

2.3.2 Model Driven Engineering Technology

Model Driven Engineering (MDE) technology is a suit of methodologies that supports the

development of domain specific languages. There are (Anders and Andler, 2012) two

approaches to MDE; the Model Driven Architecture (MDA) and Domain-Specific Modeling

(DSM). MDA is part of the object management group (OMG) standards that enable the model-

14
driven approach via the Unified Modeling Language (UML), the XML Metadata Interchange

(XMI), and the Meta-Object Facility (MOF)(Angel and Bruce, 2011). One distinguishing feature

of the MOF/ UML package is the incomplete syntax mappings that make it difficult for model

interchange because the language specification is complex and as such always requires the

diagram definition standard to resolving the deficiencies (Bernhard et al., 2011).

The Domain-specific modeling approach (Cariou et al., 2012) is characterized by a domain

specific modeling language (DSML). The language formalism usually is about requirements

within particular domains, such as oil and gas pipeline systems. All the models are defined in

some language which defines the relationships among concepts in the domain and precisely

specify the key semantics and constraints associated with these domain concepts (Bernhard et al.,

2011).

2.3.3 Language Metamodel

MDE with the DSML approach is declarative, usually expresses what the program should

accomplish by hiding from the user the complexities of how to solve the problem in terms of

sequences of actions to be taken (Bran, 2011). Policies are specified at a higher level of

abstraction using models and are separated from the mechanisms used to enforce the policies.

DSMLs as shown in figure 2.4 are described using metamodels, which help overcome the

semantic gap between the design intent and the expression of such design intent. This makes the

users of such languages free from difficulties of how the policies are mapped onto the underlying

mechanisms implementing them (Decker, 1998).

15
 Figure 2.4: The Language Metamodel

2.3.4 The Domain Model

Domain Model represents real world concepts and vocabulary of the problem domain. A

software engineering research activity like this work that relates to modeling language

development for pipeline systems specific domain, the necessity for a domain model is founded

on the fact that it is the exact conceptual framework that showcase the semantics and the

language workflow (Angel and Bruce, 2011).

Domain classes and relationships form the basic defining components for a domain model. In our

case this is simply the model representing oil and gas pipeline concepts relative to the core of the

language definitions (Bran, 2011).

Now putting the model at the core of development and ignoring any detail not relevant to the

application domain that the models represent(Giovanni et al, 2009) concepts associated with the

domain’s technical content are specified as shown in figure 2.5 (Deng et al, 2012).

16
 Figure 2.5: The Domain Model

2.4 Domain of Pipeline Systems

Pipeline systems are like arteries and veins; they are an essential and integral part of our modern

civilization just as arteries and veins are essential to the human body. In a modern city they

transport water from the sources of water supply to the points of distribution. Similarly, pipelines

carry crude oil or gas from wells to tank farms for storage or to refineries for processing (Anvil

International, 2012).

2.4.1 Pipeline Standards and Operations

The design, construction, operation, and maintenance of various pipeline systems involve

understanding of pipeline fundamentals, materials, generic and specific design considerations,

17
fabrication and installation, examinations, and testing and inspection requirements, in addition to

the local, state and federal regulations (Andrade, 2011).

Pipeline systems include pipe, flanges, fittings, bolting, gaskets, valves, and the pressure

containing portions of other piping components. It also includes pipe hangers and supports and

other items necessary to prevent over pressurization and overstressing of the pressure-containing

components (Andrade, 2011).

It is evident that the major component in pipeline systems is the pipe. Therefore, pipe sections

when joined with fittings, valves, and other mechanical equipment and properly supported by

hangers and supports makes up an entire pipeline (McAllister, 1998). Pipe is a tube with round

cross section conforming to the dimensional requirements of the American Society of

Mechanical Engineers (ASME) B36.10M Welded and Seamless Wrought Steel Pipe, and ASME

B36.19M Stainless Steel Pipe.

The inside diameter will depend upon the pipe wall thickness specified by the schedule number

as a reference to ASME B36.10M or ASME B36.19M. Another pipe size designation is the

diameter normal (Phil, 2002). Diameter nominal (DN) is also a dimensionless designator of pipe

size in the metric unit system, developed by the International Standards Organization (ISO). It

indicates standard pipe size when followed by the specific size designation number. For example

for pipe sizes larger than NPS 80, the DN equivalent can be determined by multiplying NPS size

designation number by 25without a millimetre symbol (Pipeline 101, 2010).

2.4.2 Generic Pipeline Design Considerations

Engineers responsible for the preparation of design documents must, from time to time, review

the current codes and standards in order to comply with and take advantage of the changes in the

industry which are expected to continue as computerized drafting and preparation of text and

18
record keeping improve. Before the detailed design is begun, it is usually advantageous for the

project to prepare a comprehensive set of documents defining the system design criteria. This

criterion may be part of overall project design criteria or may be a separate document prepared

solely for the piping design (McAllister, 1998).

In either case, the design criteria should reiterate the design requirements delineated in the

contract specification and should define the applicable codes and standards, environmental

conditions, design parameters, and other pertinent design bases that will govern the work. The

design criteria can be updated as the design progresses to reflect any change in the design basis

(Anvil International, 2012).

2.4.3 System Descriptions

The many organizations engaged in pipeline system design do perform system descriptions

(SDs) based on their needs. Systems whose operation may have public safety implications (e.g.,

nuclear power plant systems and chemical plant systems) may require very detailed system

descriptions (Anvil International, 2012).The purpose of the system description is to set forth,

specifically in writing, the functions, intent of the design, and major features of the

system(Andrade, 2011).Some common features include system design bases, operating

modes(start-up, normal, shutdown, emergency, or as appropriate), performance ratings of major

equipment, and control concepts.

The design basis stated in the SD is used to develop the system flow diagram(which shows the

features necessary to accomplish the design basis) and the pipeline diagram (which shows the

basic controls, interlocks, pipes, valves, vessels, pumps, and miscellaneous equipment

comprising the system). Therefore, the system description is important in the development of the

documents used in procurement, manufacturing, fabrication, and erection (Zezula et al., 2000).

19
2.4.4 Pipeline Drawings

Isometric or orthographic pipeline sketches are made, as determined by project requirements.

Portions of structural, and control information may be included in these sketches in which case

they are called composite drawings (Nayyar, 2000).These drawings form the basis for the

working physical drawings such as the system isometrics. The sketches and composites are not

used for construction or manufacture; they represent the pre-computer version of the present

database in a computer-aided design (CAD) system, or one of its several derivative systems,

which can provide the design study more efficiently than manual methods in many instances

today. Computer-aided design and drafting (CADD) software packages are available from a

number of commercial sources (McAllister, 1998).

With the development of three-dimensional computer-aided design (3DCAD) software, the

designer can check for interference and can generate different views. Once the orthographic

drawings are completed, they may be issued for piping fabrication and construction. However,

for complex pipeline systems, it is common practice to develop separate piping isometric

drawings for each pipe run (Zezula et al., 2000). For pipe stress analysis, fabrication, and

installation, the piping isometric drawings are easier to use than the orthographic drawings

because all the information on the isometric drawing pertains to the pipeline of interest without

cluttering with extraneous information (Phil, 2002).

2.4.5 Domain Driven Design of Pipeline Systems

Domain Driven Design (DDD) focuses software development on domains and domain logic

(Eric, 2003). The principle of DDD widely acknowledges that domain specific modeling is

central to software design. Through domain modeling, the developments of projects facing

20
complex domains are expressed in rich functionality and translate that functionality into software

implementation that truly serves the needs of its users (Angel and Bruce, 2011). For example, the

development and implementation of a pipeline project involves so much design efforts even with

the adoption of CAD systems. It is characterised with numerous compliance issues even after

design is completed and the project kicked off.

With DDD, the model is the heart of the design, and the methodology of manipulating this model

to ease the project execution for users is the Domain Specific Modeling (DSM) (Eric, 2003).

Keeping these CAD drawings as the model and presenting a domain model of them in a

metamodel of relationships and tributes will result in a modeling language. The modeling

language, which is specific to the domain of pipeline engineering, will be capable of allowing the

pipeline engineer to easily get his specifications correct on time and at very minimal costs

instead of always returning to conformal forms and related issues (Eric and Oliver, 2012).

2.5 Related Work

The review of literature in this section is covering some research areas in language development

and the drive to further the capabilities of this research for the design and implementation of an

enhanced modelling tool for pipeline systems.

2.5.1 Language Representation

An approach to formalize the semantics of a domain specific modelling language for multi-agent

systems (DSML4MAS) was proposed by (Christian and Klaus, 2009). A modelling language that

supports multi-agent system designers in validating and verifying generated designs. The

development of agent-based software systems are often associated with possibly adopting an

existing methodology, followed by manual programming of the base artefacts, and then

21
debugging the resulting system. Their main idea was to close this gap by introducing a

(Dsml4mas) that provides key features like a concrete syntax, abstract syntax, and semantics as

well as code generators that support the user in the three development steps. The entire language

definition was accomplished with the unified modeling language (UML) that provided a

graphical notation as shown in figure 2.6.

This approach to domain specific modelling is quite similar to ours in the areas of the provision

of concrete syntax, abstract syntax, and semantics as well as code generators that support the

user, but theirs is more useful to the developer or programmer and not the non-programmer.

Compared to our approach, the UML class diagrams are not sufficiently precise enough to set out

all the relevant aspects of the specifications. More so, UML is not an end user representation

language; there are restrictions that are not easily conveyed in diagrammatical forms.

A domain specific language to Define Gestures for Multi-Touch Applications was presented by

(Shahedul et al., 2010). Figure 2.7 shows the processing pipeline of a gesture recognition system.

The messages generated from hardware are translated into low-level data by the device drivers.

22
Figure 2.6: Metamodel of Multi-agent System View of Dsml4mas

Figure 2.7: The Gesture Recognition Process

23
A gesture recognizer then receives these data and evaluates them to detect gestures that are

requested by the application. When a gesture is detected, the gesture recognizer notifies the

application through an asynchronous call back.

To simplify using gestures in applications, they presented the gesture definition language (GDL)

that hides low level implementation complexities from application developers without

compromising the flexibility of gesture definitions (Shahedul et al., 2010). GDL is a domain-

specific language designed to streamline the process of defining gestures. It enables application

programmers to integrate application specific gestures into their software systems. In the

language structure graphs are shown as states and rules are defined as state transitions.

Transitions cannot be processed in our own rule processing system because the features which

are depicted by the vocabulary can only be translated to form a typical design scenario as the

user works through the concrete syntax to request design intent.

The Model-Driven Testing (MDT) work on automation of software testing emerged from the

project of (Youssef, 2010), which resulted in a domain specific modelling language (DSML) for

Mobile Phone Applications Testing. They were interested in providing a platform, where test

scenarios such as downloading an application, installing it, launching it, navigating in menus,

validating user permission requests that are typically repeated on several devices can be

performed by as a suite of actions by the tester or a non-programmer on one phone.

To this end they developed a DSML which uses models as instances of the language metamodel

to express and execute tests (Youssef, 2010). The language composition is invariably a UML

Sequence Diagram that allows the description of test scenarios in which commonalities and

variability between mobile phones can be expressed without great difficulties. The test scenarios

use distinct execution paths according to the expressed variation points. A key characteristic of

24
this DSML is a component of a tool suite enabling the test of different devices having variable

features with the ability to cope with variability in the spirit of product lines.

This approach resolved testing repetitiveness and annoyance, helps the tester to describe a test

scenario and run it on available devices, and promoted significant reuse of test material and the

replay and tracing of tests. The representations are very clear in the approach and the language

specifications of variability and commonalities were clearly characterized (Philip and

Roggenbach, 2014). Because UML is not an end user representation language; there are

restrictions that are not easily conveyed in diagrammatical forms. With DSM a potential user is

not restricted but has the freedom to express their viewpoints clearly to achieve desired results.

In this work, the language representations started graphically with domain model specifications.

It represented the vocabulary and key concepts of the problem domain, and also identifies the

relationships and attributes of all the entities within the scope of the problem domain. Through

tool integration and template transformation it resulted into an application model (editor) with

grids each representing textual input parameters.

2.5.2 Tool Integration

The integration of the visual studio modelling tool became a common requirement throughout

the software development process. It was desirable to perform the domain functionality to aid the

design decisions (Brooke, 2010). Applying Rational Rose tool suit in their approach is (Jonathan

et al., 2011), which focused more on providing a separate framework on which an open tool

integration platform is created. What this means is that it gives the developer freedom to make

design choices. Though in our approach, model transformation between platforms is more or less

an internal data source binding activity, the advantage of this approach over ours is that we are to

some extent bound by the properties of the visual studio SDK.

25
Tool interoperability was adopted by (Tratt, 2005), homogenizing various outputs formats of the

tools in a given domain. There has been a surge of interest in applying model engineering and

DSMLs to tool integration, with the benefits of model transformations (Zekai and Marjan, 2009).

The novel idea we are bringing to bear in this scenario is to greatly simplify the two issues of

syntactic and semantic interoperability via tool utilization instead of defining each dynamics

separately on a different framework before integrating to achieve desired model transformations.

In addition, the challenge of having various output formats is minimised because, though

homogenised but each tool may have a proprietary format and representation (Tratt, 2005).

The work on Linking a Medical Vocabulary to a Clinical Data Model using Abstract Syntax

Notation incorporated vocabulary using Base Coded; a primitive data type that allows

vocabulary concepts and semantic relationships to be referenced using standard ASN.1 notation

(Stanley, 1998). This methodology referred to words or terms used to denote pipeline

engineering concepts; a translation scheme that translates the vocabulary in the grammar

sequence into what the DSL does and what is carried out in real life was introduced. What in not

included is a primitive data type that is allowing clear referencing between concepts and the

semantic relationships. However, a common ground in our approach is the adoption of the

semantic model that is capable of being populated with the scripts anytime a request for resource

sharing is triggered by the user.

A development effort centred at tool selection Using Model-Driven Design Environments on the

increasing demand for developing languages that help reduce the very complex and error prone

code centric development using programming language platforms was presented by (Waddington

and Patrick, 2006). They emphasized on an integrated modelling approach called Model-Centric

Software Development (MCSD). The vision of MCSD is to solve very complex large scale

26
development problems by allowing developers to phase the processes in order to evaluate the

design properties and decisions until the implementation phase is complete.

Steven and Slaby presented the system execution modelling (SEM) tools that combine QoS-

enabled SOA middleware and model-driven development (MDD) technologies (Steven and

Slaby, 2006). Also supporting validation and checking for design rules and conformance, SEM

did make provisions for “what if” analysis of alternative designs to quantify the impact and costs

of certain design choices on end-to-end system performance.

This now enabled developers to be able to explore design alternatives from multiple

computational and valuation perspectives at multiple life-cycle phases using multiple quality

criteria with multiple stakeholders and suppliers. May be in the near future but our system does

not contain in its language definition logic the capability to satisfy multiple design tasks and

conformance. However multiple design intents can be accommodated (Steven and Slaby, 2006).

The Visual Studio SDK contains tools that make it easy to define and implement graphical

Domain-Specific Languages (DSLs) and associated code generators in Visual Studio. The tools

contained in the Visual Studio SDK use domain-specific development techniques to create and

implement DSLs for use in Visual Studio (Steven, 2007).

Domain specific development as shown in figure 2.8 is a pattern of model-driven software

development. It’s a very useful way of developing software when building a specific type of

solution in a particular domain. The domain in this context is pipeline systems (Mernik, 2010).

There are two main parts in figure 2.8: a variable part embodied by a model and a fixed part,

embodied by a framework. The common elements of the domain are captured in a reusable

domain framework so that building systems in the domain will become more easily (Steve,

2007). To make using the frameworks easier, domain-specific development technique introduces

a model from which a metamodel can be created to aid the solution part of the system.

27
 Figure 2.8: Domain-Specific Development Pattern (Source: Steve, 2007)

The elements found in these models encapsulate the right patterns for using the framework. For

example, a pipeline physical component in meta data of the model contains enough information

to specify how to derive a concept from some components relationships in the framework to

form part of an attribute-access layer. This clarifies the fact that these models contain

information that’s very specific to the domain (Ngoc, 2006). The information found in the

models naturally represents the things about the actual system design when building a solution in

that domain. To accomplish this, a domain-specific language (DSLs) is created to represent them

rather than using generic modeling languages.

The generated part in the framework is the integration between the fixed and variable parts of the

solution. Typically a code generator runs across the model and produces code that extends the

framework according to well-known patterns. The handwritten part acknowledges that in most

cases neither the framework nor the model will capture everything that is needed to produce a

100% complete solution. There will usually be some solution-specific code that can be

introduced for the first time in a particular solution (Mussbacher et al., 2012).

28
Meta-modeling in MetaEdit+ is based on the language's base type’s graphical meta-modeling

language. The base types is an acronym formed from this which are Graph, Object, Port,

Property, Relationship and Role (GOPPRR).Graph is the top-level structure of the meta-model.

It defines the language diagram technique such as Class Diagram or State Transition Diagram

(Steven, 2007). The actual semantics of the graph are defined as the binding of objects,

relationships, roles and ports within the graph. Properties are characterizing attributes that can be

attached to each of these other types. An object in a graph can contain sub graphs, this is called

decomposition. But is also allowed for objects, relationships or roles to be linked to other graphs,

this is called explosion.

In a graph objects, relationships and roles must be bound. A binding connects a relationship, two

or more roles, and for each role, one or more objects in a graph. Binding is further specified with

multiplicity. Objects can be grouped in Object Sets; these sets describe a collection of objects

that can play the same role in a binding. Graphs, Objects and Relationships can have attributes,

information that these concepts carry with them. This information can be of different types:

string, text, number, Boolean, collection etc. or they can contain a link too their modeling

language concepts. MetaEdit+'s implementation of the above described GOPPRR meta-modeling

language was written in Smalltalk and provides useful flexibility for the meta-modeler (Kelly

and Tovanen, 2008).

The meta-modeling state is always "live", i.e. the tool will automatically propagate changes in

the meta-models into the models. The functional architecture of MetaEdit+ is illustrated in

Figure 2.9, as depicted there are several different tools (Juha-Pekka, 2011).

A tool, as the term is used within the MetaEdit+ environment, is a window type with its

associated functionality, through which a user can view and possibly alter a design objects in a

particular way. Most of them will be discussed in the next section. The heart of the environment

29
is the MetaEngine, which handles all operations on the underlying conceptual data through a

well-defined service protocol. There is no direct communication between components at the

same level, or over a common bus between components separated by more than one level: tools

communicate only via the MetaEngine. The different tools request services of the engine in

accessing and manipulating repository data (Juha-Pekka, 2011).

The Graphical Editing Framework (GEF) provides technology to create rich graphical editors

and views for the Eclipse Workbench UI (Gustavo et al., 2012). These editors consist of several

components.

Figure 2.9: MetaEdit Environment (Source: Kelly and Tolvanen, 2008).

The diagram editor including tool palette which graphically represent the underlying data model

elements, Command objects that edit the model with the provision of options. Some of these

components are used to create an Eclipse plug-in, which will implement a graphical editor for a

specific domain model.

It is important to note that GEF makes no restrictions on the underlying model; it can be an EMF

model, Java code, etc. (Baar, 2006). GEF follows the MVC (model-view-controller) concept,

meaning that there is a separation between the model, its graphical representation (view) and the

30
program logic (controller) (Gustavo et al., 2012). In MVC design, the controller is often the only

connection between the view and the model. The controller is responsible for maintaining the

view, and for interpreting UI events and turning them into operations on the model.

GMF is mostly tied to UML and aims at the development of a DSML editor without significant

support for independent development. It is not found to be a sophisticated metamodeling tool,

because models are often accessed through extension points. MetaEdit+, though not tied to

UML, is a tool with very flexible possibilities for DSML definition. But the capabilities offered

are mainly centred on graphical DSMLs metamodeling paradigm and generator definition

language. Since the Eclipse Modelling Framework is available on any Java-enabled platform, it

means the generator definition language is Java (Baar, 2006).

Looking at the visual studio tools for DSML development, the target language for code

generation is C#, and as well, a Validation Framework readily available to help express the limits

of domain analysis. Since in this work, the aim is to develop a rule processing system capable of

processing a grammar (comprising oil and gas pipelines systems vocabulary), the Microsoft

Modelling and Visualization SDK (VMSDK) fits the requirements of this work, so VMSDK is

selected as the metamodeling tool for this work (Steve, 2007).

2.5.3 Model Transformation

The focus of (Jonathan et al., 2011) is more closely related on endogenous refinements where the

source and target share the same metamodel, or a metamodel with only evolutionary changes.

This work adopted the same approach to model transformation, but the bit of new thing we seem

to have added is the graphical domain model to a textual application model. Porres (2005), in his

work adopted model refactoring, where transformations were performed for semantically

equivalent state machines.

31
Graph rewriting method for developing model transformations was adopted by (Klar et al.,

2007), which improves the performance and utility of such transformations. The advantage of

graph rewriting approach is that new tools can be added easily to the integration chain by

specifying mappings to a pivot model that captures the integrated concerns of tools in a specific

domain. But why bother much about integrated concerns of different tools in settling a single

DSML solution. We are simply advocating model transformation as the conversion mechanism

between tool models within a single metamodel.

2.5.4 Language Functionality

Our language functionality is closely tied to the DSM manifesto, “raise the abstractions” in

which case the language metamodel represent concepts from a single domain and one pipeline

context model. For effective language functionality (Lee and Zheng, 2005) adopted multi-

paradigm modelling that combines discrete behaviour e.g. (state machines) with continuous

behaviour of system flow (e.g., differential equations).

This is typical of combination of several domains and various models of computation. Also

adopting the multi-paradigm modelling approach is (Mosterman and Vangheluwe, 2004), which

combines formalisms according to their unique strengths to obtain synergistic benefits useful for

some domains. Others (Buck et al., 1994) focused on heterogeneous modelling, which assisted in

the mixing of different models of computation.

Despite the benefits that hybrid and multi-paradigm modelling offer, the combination of different

formalisms presents the challenge of adaptation as each language may have connection

difficulties across the concepts that may be represented. What we have presented therefore is the

integration of semantic relationships among the concepts presented from a domain. So as far as

32
the abstractions are raised, the system through its application model is capable of allowing the

user to declaratively express design intents.

2.5.5 Language Definition and Domain Analysis

A pipeline systems modeling language is simply a domain specific modeling language whose

pre-constructed notations and abstractions only offer expressive power to the pipeline

engineering domain. As usual it has its own syntax and semantics definition, which we have

presented in this work using feature oriented domain analysis. We highlighted the usefulness of

feature models or diagrams to formalizing the syntax and semantics definitions of a domain

specific modeling language in the context of a software product line; however a few more

formally defined schemes have been identified.

Defining the domain directly as a language is (Zhao et al., 2004). They called it an open operator

definition, which gives much flexibility to the language for the evolution of operators of a

domain, and any compositions in the domain are the relationships presented by the grammar

rules and are not physically represented by any symbols. The identified differing point is that,

they were simply interpreting the feature compositions grammatically, while in ours, the

composition rules of the features were clearly set out for a separate grammar construction action

applying relevant language development methods.

Another exemplary language definition based on domain analysis is that of (Batory, 2005). He

translated a feature diagram to both grammars and propositional formulae. The semantics of the

grammar is a set of iterative tree with string tokens, and thus repetition was possible. His

definitions are close to ours but differs in the respect that there is no clear separation of

decomposable features. Shan et al. (2011) presented a framework for the formal definition of the

abstract syntax and type systems of modeling languages that facilitates formal specification and

33
automatic checking of consistency and completeness constraints on graphic models. This

approach illustrated a robust specification of the consistency and completeness constraints of a

modeling language, but we are much more interested in providing a modeling tool for domain

experts.

Czarnecki et al. (2005) defined a new Feature Diagram (FD) language to account for staged

configuration. They introduce feature cardinality (the number of times a feature can be repeated

in a product) in addition to the more usual (group) cardinality. Foremost, a new semantics is

proposed where the full shape of the unordered tree is important, including repetition and

decomposable features. From our point of view, we can argue that related approaches have some

varying grounds with our approach on generality, and abstraction. In most of the approaches the

semantics is tool-driven, while we are concentrating on building a tool on a carefully chosen and

well-studied semantics.

For others a FD language is defined with feature cardinalities to be explicitly applied, currently,

we are limited in defining cardinalities rather we focused more on interdependencies in the

formalization scope.

2.5.6 Language Design

Brady and Hammond provided a new overloading notation that facilitates programming,

modularity and reuse in embedded domain specific languages (EDSLs) (Brady and Hammond,

2012). Their goal is to use it to reason about safe resource usage and state management. The

translation semantics is closer to our products but differs in two respects: (a) the language

constructs are separated from the primitive operations, and (b) the typed functions only

implement a generic framework for systems programming.

34
In a seemingly new dimension (Núñez and Noyé, 2007) defined a recent approach, CEAOP

(concurrent event-based AOP), to the provision of an implementation of CEAOP as a small

DSAL (domain-specific aspect language) that can be compiled into Java. The compilation

process consists of translating both the CEAOP aspects and the Java base program into Java

finite state processes. This translation relies on Meta-objects to extend Java with CEAOP and

Reflex to instrument the base program (Sanna, 2008). Phillip and Roggenbach introduced a

methodology for developing domain specific languages for modelling and verification that aims

to aid in the uptake of formal methods within the railway domain (Phillip and Roggenbach,

2014).

This present work has acknowledged the design methodology and the specification patterns of

the domain specific language for the application in the Railway industry. In our approach we

have made efforts to move away from the use of the UML and Generic Modelling Environment

(GME) suite for specifying modelling concepts. The challenge in the UML paradigms is the lack

of a semantic definition within the context of the metamodel. Incorporated in our metamodel is a

semantic module in the domain model to alleviate this challenge.

35
 CHAPTER THREE

SYSTEM ANALYSIS AND DESIGN

3.1 Methodology

The research methodology used in this study is applied research method which is carried out to

resolve problems quickly while taking the necessary steps. With the findings of the researcher,

the method goes directly to apply the findings by developing the enhanced system to aid in

decision-making for online tendering after design. This method does not require data collection,

but during the implementation and corresponding execution of the system, data would be

collected.

3.1.1 Tools and Technique

The proposed system has explored some web development tools and techniques in the

development, implementation and testing of the system. Some of these tools and technique

include: Laravel Development framework, PHP, jQuery, JavaScript, CSS and XAMPP Server.

The PHP, jQuery, JavaScript, and CSS scripts are written in the Laravel framework. While the

MySQL Script is enabled and written on the XAMPP server. The XAMPP server helps with the

execution of the PHP script (it’s a server-side language).

The developed system or while developing the system, the XAMPP server is used to test the

progress of the written codes offline. This shows what the system would look like when it is

finally put online.

3.2 Analysis of the Existing System

Technology has advanced a lot and most manual system processes has been computerized, but

some are still partially computerized (that is, it has not undergone a complete computerization of

the system). There are still some aspects of manual intervention to the process of the system

which is the case of the existing system. Priya & Ramamoorthy, (2016) in their work, an online

36
tendering system was presented. The system allows users to access various tender from a

company and also submit tender documents online.

The user can respond to several tenders and the system is able to handle multiple tenders by

users of the system. The user submits detail with the quotation of the published tender to the

department responsible to evaluate it online. Then the department responsible retrieves the

documents that has been sent and evaluate it manually. Allocation is given to the user that is the

most eligible and has quoted for less amount.

3.2.1 Architectural Framework of the Existing System

Publication of Tender

User Bidding

Bid Acceptance
Figure 3.1: Architectural Framework for the Existing System (Priya & Ramamoorthy,

2016)

The existing system architectural framework is a simple design that highlight the current aspect

of the decision support system for online tendering (DSSOT). It shows the direction of flow for

all the three (3) modules of the system. Figure 3.1 is an illustration showing the various modules

of the system and they include:

Publication of Tender: The administrator, after it has been agreed by the board of directors of

the organization, creates a tender through the online system and publish it. This creates a

37
notification to the registered members of the system in that category. The published tender

remains in the dashboard of all registered members until the due date. After which, it is timed out

and button becomes inactive for all members.

User Bidding: The registered members of the system, on seeing the published tender, put-in

their bids to contest for the contract. The bidding process of the system allows user to add

multiple items as needed with the unit prices and quantity while the amount display

automatically. The total amount is also shown as the user enters items to be purchased. Each user

submits their bid form in the system after they have entered all the required information but the

evaluation of the bid is done offline after printing out various bid.

Bid Acceptance: The board of directors look through the supplied information and an

unanimous decision is made available to the system’s administrator. The administrator chooses

the user or company that won the bid after going through the response from the board of director

and from the evaluation report and the admin accepts the bid of the chosen user.

3.2.2 Constraints of the Existing System

The limitation of Priya and Ramamoorthy's (2016) previous work is that it does not include a

decision support system and that the evaluation of tenders is done offline. Hence, the tendency

for the existing system to still carry some of the challenges or problems of the manual process of

tendering will still be present in the existing system.

The process of retrieval of documents can be cumbersome and can affect the speed in the

processing of user details. The integrity of human intervention is still in question when it has to

do with the selection process of the qualified candidate for the published tender and so on.

Hence, the development of the proposed system to enhance the decision process for the online

tendering system.

38
3.3 Analysis of the Proposed System

The proposed system is a complete online processing system with the tender publication, bidding

and evaluation done online. The system gives the management suggested decision based on

information supplied by the bidder using the system to support their final decision by a click of

the button.

The contractors are registered members of the system with all their details as a licensed and

qualified contractors duly verified and entered into the system and are regarded and known as

users. When a tender is published, all duly registered members of the system receive a

notification either via an SMS, email or both. All users submit their bids through the system, as

there will be provision for that on each publish tender. When the duration of the published tender

elapsed, the system now evaluates the information provided by the users (contractors) and

displays it to the administrator of the decision-making management. From the evaluated result

displayed, the administrator will select the bid with the most favorable quotation or prices and

result published on the site with notification to the users.

With this system, the administrator cannot change any information on the supplied bids and each

user have rights to privacy of their bids as no other user sees their submitted bid except the

administrator who cannot effect any change on submitted bid. Time and human error has been

eliminated through this system as result can be available the same day the time for the bidding

process elapsed.

3.3.1 Architectural Framework of the Proposed System

Publication39of Tender
 Figure 3.2: Architectural Framework for the Proposed System

The proposed system architectural framework is a simple design that highlight the major aspect

of the decision support system for online tendering (DSSOT). It shows the direction of flow for

all the four (4) modules of the system. Figure 3.2 is an illustration showing the various modules

of the system and they include:

Publication of Tender: The administrator, after it has been agreed by the board of directors of

the organization, creates a tender through the online system and publish it. This creates a

notification to the registered members of the system in that category. The published tender

remains in the dashboard of all registered members until the due date. After which, it is timed out

and button becomes inactive for all members.

40
User Bidding: The registered members of the system, on seeing the published tender, put-in

their bids to contest for the contract. The system allows users to bid directly online to enable

automatic evaluation of the various bids of the users. The bidding process of the system allows

user to add multiple items as needed with the unit prices and quantity while the amount display

automatically. The total amount is also shown as the user enters items to be purchased. Each user

submits their bid form in the system after they have entered all the required information.

Bid Evaluation: The submitted bids are then evaluated automatically and sorted in ascending

order (that is, from the lowest amount to the highest amount). The system administrator views

the various bids and check the total amount that falls within the amount allocated for that

particular job/ contract and then views the content of each bid if it carries all the requirements

they need in that contract. From the listed information supplied, the administrator then makes

suggestions to the board of directors supplying them with the information of the selected users

and decision is then made from the information and suggestions made by the admin.

Bid Acceptance: The board of directors look through the supplied information and an

unanimous decision is made available to the system’s administrator. The administrator chooses

the user or company that won the bid after going through the response from the board of director

and from the evaluation page and the admin accepts the bid of the chosen user. This is now

displayed on the dashboard of all the registered member of the system. The user, whose bid was

accepted is then notified to proceed with the necessary procedure.

3.3.2 Object Oriented Analysis and Design

The Object-Oriented Analysis and Design method was adopted in the development process of

the system. This is because, it helps in the breaking down of the entire system into relatable

objects and step by step process of how the system should run exploring the unified modelling

41
language (UML) diagrams to demonstrate the entire system. Hence, the Use CASE, Activity

Diagram and Class and Relationship diagrams are used to present the proposed system.

[Link] Use CASE Diagram

Admin

Figure 3.3: Admin Use CASE Diagram for the Proposed System

The Use CASE of the proposed system is used to demonstrate the various use cases of the

system. This is separated into two distinct use case diagrams representing the ‘admin actor’ use

case and the ‘user actor’ use case. The admin creates its own account in the system by

registration and he/ she login using the valid login credentials. He is responsible for creating and

publishing tenders for users to bid on. He views the various bid and reports system bid

evaluation to the board of directors. He/ she is responsible to selected the accepted bid based on
42
the response of the board of directors which in turn publishes it to all members or users of the

system. Figure 3.3 is the Use Case diagram for the admin actor.

[Link] Use CASE Diagram

User

Figure 3.4: User Use CASE Diagram for the Proposed System

The users of the system are also required to register, providing every necessary document that

qualifies them as a contractor. After they are verified as members of the system, they can now

login to view tenders published by the admin of the system. The user bids for a published tender

and can also view the report of the board of directors that carries the result of the bid. Figure 3.4

is used to show the user actor use case.

43
[Link] Activity Diagram

Figure 3.5: Activity diagram for the Proposed System

The activity diagram is used to illustrate the various activity carried out by the system

administrator and the users. It shows the process from the registration to the published accepted

bid of the user. There are some parallel activities of the system which the user or admin can

perform independently which are: creating and publishing tender, viewing published tender and

user bids, view bid evaluation and creating bid for tender. The board of directors accepts bids

and its published. Figure 3.5 is used to demonstrate the various activities of the system.

44
[Link] Class and Relationship Diagram

Figure 3.6: Class Diagram for the Proposed System

The class and relationship diagram is used to show objects or classes and the relationship that

exist between them (that is, a one to one, one to many or a many to many relationship). Each

class or object contains data item or variables and the permissible operation that exist. Hence, the

class diagram as shown in Figure 3.6 is a small-scale class diagram for the proposed system

containing few classes and their relationship.

3.4 System Design

The system design of the proposed system is used to demonstrate the three aspects of the

development of the system. Using the scenario of a published tender on the purchase of computer

45
laboratory equipment for Computer Science Department, Ignatius Ajuru University of Education.

The input design, process design and the output design have been used to illustrate the aim of

this study.

3.4.1 Input Design of the proposed System

The input design is a demonstration of how the system takes in data for manipulation. The

proposed system has focused on the input design of the bidding form for the user and has not

included the tender creation form. The input design allows the user to enter as many rows as

possible to accommodate the number of items the user may want to enter and a submit button for

submitting the form after completion. Figure 3.7 is a pictorial view of the input design form for

bidding of published tender.

Figure 3.7: Input Design of the Proposed System

3.4.2 Process Design of the Proposed System

The process design of the proposed system demonstrates the processes involved during the use of

the enhanced decision support system for online tendering. From Figure 3.8, the system’s admin

46
creates tender that is save to the database of the system. The system manipulates on data save in

the database and presents it to everyone in an understandable format. The user/ contractors who

is a registered member of the system views the tender and bids for it, filling a bidding form that

is saved to the database of the system. The admin views the processed and evaluated data of the

different users who have submitted their bids and make recommendations to the board of

directors. From the reports of the directors, the admin now selects the user whose bid have been

selected and publish it for everyone to see. The system is programmed in such a way that it does

the comparison and ranking of bids in an ascending order (that is, the lowest quoted amount first

and the highest last). Figure 3.8 demonstrates this purpose.

Figure 3.8: Process Design of the Proposed System

3.4.3 Output Design of the Proposed System

The output design of the proposed enhanced decision support system for online tendering has

been demonstrated in two ways to show pictorially what the system should look like. The design

47
follows the scenario of the purchase equipment and setting up of a computer laboratory for

computer science department.

The system in Figure 3.9 shows the system administrator bid preview for all bids by users/

members of the system. It shows the bid title and the listed company, summary of their bid with

a button to view the details of the bid. From here, the admin can make its final suggestions on the

information of each bid. A pictorial view is shown in Figure 3.9.

Figure 3.9: System Administrator Bid Preview Output Design of the Proposed System

Again, the system displays the output of the selected bid for the published tender after being

approved by the directors following the admin’s suggestions. The accepted and published bid

displays the title of the tender, the user’s company name and other important details of the

company. Figure 3.10 is the pictorial illustration that shows the information on an accepted bid.

48
 Figure 3.10: Accepted Bid and Company Information Output Display of the Proposed System

3.5 Database Design of the Proposed System

The database design of the enhanced decision support system for online tendering are the

different tables in the database used in storing data entered from the front end of the system.

Each table contains the data item and the table name which describes the content of the table.

Some, includes foreign keys which links them to the content of other tables. These tables are

shown below:

Table 3.1: User Table of the Proposed System

User Table

UserI Passwor Nam Emai Phon Stat LG Se Do Com. Com Doc Logo/

D d e l e e A x B Nam . . passpor

e Reg. t

No

49
Table 3.1 is the user table of the proposed system that stores all information about the user and

their portfolios. This table also enables the user to login to the system and perform the necessary

processes in the system. It contains the registration number of the company which shows that the

company is eligible to bid for a contract.

Table 3.2: Tender Table of the Proposed System

Tender Table

TenderID Title Description Start End Date Active Accept

Date Flag

Table 3.2 is the Tender table that enables all created tender to be saved to the database so that,

they can be called to other parts of the system where it should display. The tender table contains

a start and end date which controls the appearance of the tender for bidding process to take place.

And the accept flag is active when the admin accepts the button on the user bid preview.

Table 3.3: Bid Table of the Proposed System

Bid Table

Bid_id User_id Tender_id Item_Des Item_unit_price Item_Qty Amount Total

Table 3.3 is the bid table of the proposed system that stores every information pertaining to user

bid in the database of the system. From this table, the system calls forth and manipulates on the

50
information needed for evaluation preview. It also enables the admin to view the details of the

user bid.

Table 3.4: Bid Acceptance Table of the Proposed System

Bid Acceptance Table

Bid_Acc_id Tender_i User_id Tender User User User User Date

d Title name Comp. Comp passport/

Name RegNo logo

Table 3.4 Stores all accepted bids to every tender that has ever been published. This is so that it

can be referred to in the future. The date controls the placement in the hierarchy of the accepted

bids to tender that has been published.

Table 3.5: Notification Table of the Proposed System

Notification Table

Notify_id User_id User_phone Tender_Title Message Date

Table 3.5 stores all the notification messages created and sent to users during the publication of

tenders and acceptance of bids. It carries the tender title and a message and the phone numbers to

send the messages to that is called from the user table.

3.6 Decision Support System for the Proposed System

51
There are many paradigms that can be used to explain how people make decisions. Among them,

Simon's paradigm has undergone extensive testing and is extensively employed. There are three

stages: choosing, design, and intelligence. A further step of implementation is included.

Khangmi, (2015).

The phase of intelligence is when the process starts. A decision-maker establishes a knowledge

of the opportunities and issue domain at this phase by observing reality. The decision criteria and

options are generated in the Design phase using a specific model, and the pertinent

uncontrollable events are recognized. The connections between the potential outcomes, actual

events, and choices must be precisely defined and quantified. As a result, the decision events and

alternatives can be logically assessed in the choice phase, which is the following phase. The

decision makers must review their choice evaluation and analysis during the implementation

phase and weigh the implications of their recommendations. The decision support system for the

proposed system is categorized into three which includes;

3.6.1 Intelligence
This is the ability to learn or understand or to deal with new or trying situations. : the ability to

apply knowledge to manipulate one's environment or to think abstractly as measured by

objective criteria. The following are considered un intelligence;

i. Observe reality

ii. Gain problem/opportunity understanding

iii. Acquire needed information DESIGN

iv. Develop decision criteria

v. Develop decision alternatives

vi. Identify relevant uncontrollable events

52
vii. Specify the relationship between criteria, alternatives and events

3.6.2 Choice of the Proposed Decision Support System

This is the act or opportunity of choosing or the thing chosen. choice suggests the opportunity or

privilege of choosing freely. The proposed system is programmed in a way where the system

immediately recognizes the lowest bidder and place as the first, follow by the second lowest

bidder and so on. The following are considered under choice;

i. Logically evaluate the decision alternatives base on lowest bidder.

ii. Develop the recommended actions that best meet the decision criteria base on lowest

bidder.

3.6.3 Implementation of the Proposed Decision Support System

This is the execution or practice of a plan, a method or any design, idea, model, specification,

standard or policy for doing something. As such, implementation is the action that must follow

any preliminary thinking for something to actually happen. At the implementation of the

proposed system, the system display the lowest bidder once a bid is submitted to the admin and

place it in the order of lowest to the highest. The following is considered under the

implementation.

i. Ponder the decision analyses and evaluations

ii. Weigh the consequences of the recommendations

iii. Gain confidence in the decision

iv. Develop an implementation plan

v. Secure needed resources

53
vi. Put implementation plan into action

54
 CHAPTER FOUR
SYSTEM IMPLEMENTATION

4.1 Choice of Development Environment

The choice of development environment was chosen based on the kind of system that is being

developed. The system is a web-based system and there are web development tools suitable for

this kind of system. The Komodo IDE 12 is the development environment used for the

development of this system. Komodo Edit IDE is an open-source editor and it is free for

developers to download. This dynamic text editor helps with programming dynamic languages

and was introduced in the year 2007 in January to complement the Active State’s commercial

Komodo IDE.

4.1.1 Justification of Choice of Environment

To justify the choice of development environment, we must state that, though the text editor is

free it is very good with PHP, Python, Pearl, Ruby etc. development and it aide the writing of

code faster. It’s a simple, yet powerful tool with robust functionalities like debugging, code

refactoring, unit testing, version control and code profiling. It supports some major web

technologies such as Laravel blade, HTML5, Zend Framework etc.

With multi-language syntax checking and highlighting, auto-complete, calltips, snippets, macros,

and other productivity-enhancing features, Komodo IDE helps PHP developers create code

quicker and more precisely. You can perform global code changes with code refactoring

(renaming variables and class members, removing methods), which saves time over making

changes manually.

55
4.2 Implementation Architecture

The implementation architecture is a skeletal structure showing the process of implementation of

the system. This section gives the basic flow of the process involved in the system

implementation as seen in the process design in Figure 3.8. From Figure 4.1, the admin creates

and publish the tender for registered members of the system to bid for. The user (registered

member) views the tender by the admin and create bid for the tender while the admin views the

bids by the user. The admin, after evaluation accepts the bid by one of the registered members

and it is being published. The user(s) are able to view the accepted bid from their dashboard.

Figure 4.1: Implementation Architecture of the Developed System

4.3 System Testing

The different pages of the developed system have been simulated and tested to make sure it

performs its function. It gives the different information in each screenshot to tell what that page

is all about. The following subsections are the interfaces of the developed system.

56
4.3.1 Create Tender Form Interface Display

The create tender form allows the administrator of the system to create a tender for the

organization and publish it for the registered users of the system to see. Figure 4.2 is the admin

view of create tender page. When the admin logs into the system he/ she navigates through the

top menu to access the pages of the system. After clicking on create tender menu, the admin

supplies the tender title, description, start date and end date. The created tender is then published

to the view of the users.

Figure 4.2: Create Tender Form Page of the Developed System

4.3.2 Create Bid Form Interface Display

The create bid form interface is used by the user to bid for the published tender. The form allows

the user to add as many items as possible for the tender. The published tender that is being bided

for is displayed in the option box at the top. If there are more than one tender by the
57
organization, it is displayed in the option box where the user can choose from and supply bids

for. The submit bids button sends the details of the bid and the total amount to two different

tables in the database for easy retrieval. It is with this information the admin creates reports to

the board of directors for their decision and approvals. Figure 4.3 is the interface display screen

for the create bid form.

Figure 4.3: Create Bid Form for Published Tender of the Developed System

4.3.3 View Created Bids of Registered Users

The view created bids page from the admin section of the developed system shows the various

bids of the registered users of the system. All supplied bids can be viewed by the admin from this

page to see the details and to make decision based on what is displayed here. After the details has

been reviewed, the admin can accept the bid from this page. This now sends the details of the

bids that was accepted to the accept bid table in the database for easy retrieval of that

information. Figure 4.4 shows the interface display screen of the page.

58
 Figure 4.4: Member Bid Display Screen of the Developed System

4.3.4 View Accepted Bids from Admin

The view accepted bid(s) from the admin page allows one to view all accepted bids of the system

by the users. The page displays the tender title and the details of the company or user whose bid

was accepted. The admin can know more about the company from the displayed information of

the company or user. Figure 4.5 is the interface display screen shot of the view accepted bid from

the admin section of the developed system.

59
 Figure 4.5: The View Accepted Bid Display screen of the developed System

4.3.5 View Accepted Bid by the User

The view accepted bid from the user section of the developed system displays the tender title, the

company name and their description and the company registration number. Any user can see the

company that won the contract for the published tender. Figure 4.6 shows the view accepted bid

page information from the user section of the system.

60
 Figure 4.6: Accepted Bid Page Display from the User Section of the Developed System

4.3.6 User Dashboard Interface Display

The user dashboard interface of the developed system previews the summary information about

the activities of the user. By the side are the navigation menu links to different parts of the

system and on the main dashboard, we have the preview of current tender, preview of user bid,

and the preview of the bid performance. The preview of the current tender displays the title of

the tender, description, start and end date. The bid preview shows the title of the bid and the total

amount of the user bid. While the bid performance displays how the bid is doing generally as

compared to bids by other users of the system.

Figure 4.7: User Dashboard Display Screen of the Developed System

61
4.4 Result and Discussion

An enhanced decision support system for online tendering has been developed using some web

design tools in the implementation of the system. The system has been designed to allow

different companies register as users/ members of the system and as members, they have access

to information about tendering or offers by the organization. When the organization publishes a

tender, through the create tender form as shown in Figure 4.2, all registered members of the

system will be able to view the published tender and if they are interested in it, they can bid for it

by creating a bid through a bid form in the developed system are shown in Figure 4.3. The admin

of the system can then view all the submitted bid as show in Figure 4.4; depending on the

amount they quoted, he/ she can view the details of each member’s bid to display the information

as shown in Appendix B10. After assessing the different bids by members of the system, the

admin now accepts the bid that met with the budget and parameters of the organization. This

accepted bid is then displayed in both the admin accepted bid page and user accepted bid page as

shown in Figure 4.5 and Figure 4.6. From the dashboard of the registered member, he/ she can

view the current published tender and if they have created a bid for the tender, it also shows a

preview of their total amount and the performance of the bid as shown in Figure 4.7.

4.5 Documentation

The developed system has been documented in two forms. This document has given a detailed

explanation of how the system works and can be operated. Chapter one gives the introduction

and the direction the project work, chapter two has reviewed some related literatures about the

project topic. The methodology of the work is in chapter three and chapter four and five is the

implementation result and conclusions of the work.

The work is further documented during implementation which can be seen in the Appendix A

and B. The source code in appendix A of the developed system has some comments on it that

62
explains what each section of code is doing. The system interface which is the Appendix B gives

the different interface of the developed system.

4.6 System Setup and User Manual

The user manual gives a description of the features of the system and how the user is expected to

use the system. They are described as followed:

Admin Registration: The admin of the system registers to be able to perform its administrative

duties. They do not follow the same link as the user but, a different route is used to checkmate

security. The link [Link] takes you to the admin login screen and if

you haven’t registered as an admin, you can register by clicking on sign up.

Admin Login: The admin login screen is used to login to the system and perform administrative

task. Ones the admin supplies its details, they are redirected to the admin dashboard.

Admin Dashboard: The admin dashboard displays some shortcut links to the desired page of

the admin task and also help to display the top menu bar.

Create Tender: The create tender menu link is used to create a tender by the admin to publish

for the registered users to see and bid. The admin provides the necessary information and provide

the start and end date the user can continue to bid for the published tender.

View Tender: The admin can view current and all previously published tender by clicking the

menu button of the view tender at the top menu bar.

View Members: The view member menu button allows the admin to view the list of registered

members of the system.

View Bids: The view bids menu button takes the admin to the list of bids that has been submitted

by the registered users for evaluation and the acceptance of best bid for the published tender.

From this page the admin can see the details of the submitted bids and make their

recommendations.

63
Accepted bids: The Accepted bid page is accessed through the top menu bar from the admin

dashboard. It displays all the accepted bids of every tender that has been published by the admin

in the system.

Create Report: The create report menu links the admin to the report page to create a report for

the accepted bid or make suggestions for the acceptance of the best performing bids.

User Registration: The user of the system registers to be able to bid for any published tender by

the organization. They do not follow the same link as the user but, a different route is used to

checkmate security. The link [Link] takes you to the user login screen and if

you haven’t registered as a user, you can register by clicking on sign up.

User Login: The user login screen is used to login to the system and perform task available for

the registered members of the system such as bidding for a published tender. Ones the user

supplies its details, they are redirected to the user dashboard.

User Dashboard: The user dashboard displays some shortcut links to the desired page of the

user task and also help to display the side navigations to other parts of the system. The dashboard

also displays the current tender, the user's bid and the performance of the user's bid.

User Profile: The user profile displays the credentials of the user that was filled during

registration. This can be accessed from the side navigation bar of the user dashboard.

View Tender: The view tender navigation is located at the side navigation bar. It links to the

published tender by the admin of the page. From here the user can view and create bid for the

tender.

Create Bid: The create bid navigation seen at the side navigation bar take the user to the page

where he/ she can create bid for the published tender of the system. The form allows user to add

as many items as possible with their prices and the total amount is shown at the bottom of the

items.

64
View Accepted Bid: The user, after the expiration of the tender time, can view the accepted bid

through the view accepted bid navigation menu by the side of the user dashboard of the system.

Logout: The logout menu or link of the system logs the user or admin out of the system. For the

admin, it is found the bottom of the sidebar navigation bar on the user dashboard, and in the

upper right corner of something like the system page for users.

65
 CHAPTER 5

SUMMARY, CONCLUSION AND RECOMMENDATION

5.1 Summary

The research work has been able to produce an online tendering with enhanced decision support

system. This was achieved following the accomplishment of the objective of the research work

as outlined in section 1.3. The major functions in online tendering system were determined; an

architectural framework was developed for the decision support system. The design and

implementation of the decision support system with the web development tools which include

Active State Komodo IDE, PHP, CSS, Java Script and other web development tools. The

simulation of the designed system was carried out using the XAMP offline server obtaining the

expected results.

Some of the system’s results has been displayed in section 4.8 as named sample output. Figure

4.2 is the screen shot for create tender page; this page is located at the admin section of the

developed system. It allows the admin to create the tender and publish it for the organization.

Figure 4.3 is the create bid form from the user page of the developed system. The form help the

registered user or company to bid for the published tender. It allows user to add as many items as

possible with their prices and automatically calculates the amount for each item and grand total

for all the added items. The member bid screen in Figure 4.4 displays the list of registered users

that has bided for the published tender, the view accepted bid page in Figure 4.5 displays the

accepted user bid in the admin section of the system. All accepted bid for published tender is

displayed in this page for the admin to view. Figure 4.6 displays the accepted bid page from the

user section of the system. While the user dashboard displays screen in Figure 4.7 gives a

preview of the overall system and direct link to other pages of the system.
66
5.2 Conclusion

This work has been able to explore the web development tools to produce an enhanced decision

support system for online tendering. A web system has been developed capturing all the major

function of tendering system, incorporating a decision support architectural framework that

enhances the process of making decisions concerning who an organization gives a contract. The

simulated system has performed very well and can be implemented in any given environment.

The result of the system shows that, the admin can view and make decision based on the

registered members’ bids and can also create report to the board of directors based on

information seen on the submitted bids. The overall simulation, efficiency and performance of

the system has been tested and verified to be in optimal performance.

5.3 Recommendations

I therefore recommend that; this enhanced decision support system for online tendering be fully

implemented in both private and public organization for procurement and contract services. This

system will be able to meet all necessary functions of the organization with respect to tendering

publishing for other companies to bid for.

5.4 Contribution of the Author

The contribution to knowledge of the work is the decision support system added to the online

tendering process which helps the admin make decision to the member bid to accept in all the

bids that was submitted.

5.5 Suggestion for Further Studies

The developed system has been designed to enable automation of commercial bid evaluation

online and bids acceptance. Further studies can be done to automate the technical bid evaluation
67
to select qualified contractors that will compete commercially by providing a platform for the

contractors to submit all the necessary documents required to qualify as a contractor for a

particular category.

68
 REFERENCES

Abdullahi, B., Ibrahim, Y. M., Ibrahim, A., & Bala, K. (2019). Development of e-tendering
evaluation system for Nigerian public sector. Journal of Engineering, Design and
Technology (pp. 77-80).
Agrahari, A., & Tripathi, S. (2012). A theoretical framework for development of decision
support system for agriculture. International Journal of Engineering and Science, 1(6),
(pp.50-55).
Al-Dmour, F. M. (2016). Towards understanding the factors that affecting the online bidding
implementation: Based on grounded theory method. The Journal of Internet Banking and
Commerce, 21(2). (pp.784-789).
Angehrn, A. A., & Jelassi, T. (1994). DSS research and practice in perspective. Decision Support
Systems, 12(4-5), (pp.267-275).
Arnott, D., & Pervan, G. (2015). A Critical Analysis of Decision Support Systems Research. In
Formulating Research Methods for Information Systems. Palgrave Macmillan, London.
(pp. 127-168)
Banwo, O., Agyekum-Mensah, G., & Arewa, A. (2016). Development of a procurement decision
support system to enhance construction project delivery-From claims management
perspective. In Proceedings of the International Conference on Industrial Engineering and
Operations Management. IEOM Society. (No. 135628, pp. 390-391).
Daradoumis, T., Caballé, S., Perez, A. A. J., & Xhafa, F. (Eds.). (2012). Technology-enhanced
systems and tools for collaborative learning scaffolding. Springer Science & Business
Media. (Vol. 350)
Elias, M. E., Mahidin, N., & Shiratuddin, N. (2003). E-Tendering system for construction
projects. Final Project of MSc Information Technology (pp.290-298).
Fong, S., & Yan, Z. (2009, November). Design of a web-based tendering system for e-
government procurement. In Proceedings of the 3rd international conference on Theory
and practice of electronic governance (pp. 321-328).
Galipalli, A. K., & Madyala, H. J. (2012). Process to Build an Efficient Decision Support System
(pp. 21-31).
Grayashan, K. L. S., Anujamali, W. J., Nadeesha, L. K. R., Thilani, M. E. A. & Amarasooriya,
N.P.N.D.K. (2014). Road Development Authority’s Tender Processing System. Kampala
International University Dar es Salaam College(pp.303-306).
Hadidi, S., Al-Rashdan, M., & Hadidi, M. (2020). Impact web on decision support systems on
the organizations. Int. J. Sci. Technol. Res, 9(4), (1450-1452).
Hamada, M., & Hassan, M. (2017). An enhanced learning style index: implementation and
integration into an intelligent and adaptive e-learning system. Eurasia Journal of
Mathematics, Science and Technology Education, 13(8), (4449-4470).

69
Hardy, C. A., & Williams, S. P. (2008). E-government policy and practice: A theoretical and
empirical exploration of public e-procurement. Government Information Quarterly, 25(2),
(155-180).
Jain, R. & Raju, S. S. (2016). Decision Support Systems: An Overview. Decision Support
System in Agriculture using Quantitative Analysis, (pp.42-50).
Kasser, J., Ceng, D., Miee, C.M. & Cook, S. C (2002). Introducing a next generation computer
enhanced systems engineering tool: the operations concept harbinger. Systems
Engineering, Test & Evaluation Conference (pp. 224-225).
Khodashahri, N. G., & Sarabi, M. M. H. (2018). Decision Support System (DSS). Singaporean J.
Bus. Econ. Manag. Stud, 1(6), (pp.95-102).
Kohli, J. (2010). Red flags in e-procurement/e-tendering for public procurement and some
remedial measures. IIT (Delhi).(pp. 259.263)
Kusumarukmi, E. I., & Adi, T. J. W. (2019). Public tendering process for construction projects:
problem identifications, analysis, and proposed solutions. In MATEC Web of
Conferences. EDP Sciences. (Vol. 258, p. 02013)
Medlock, S., Wyatt, J. C., Patel, V. L., Shortliffe, E. H., & Abu-Hanna, A. (2016). Modeling
information flows in clinical decision support: key insights for enhancing system
effectiveness. Journal of the American Medical Informatics Association, 23(5), (pp.1001-
1006).
Mohemad, R., Noor, N. M., Hamdan, A. R., & Othman, Z. A. (2018). A Comprehensive Review
of Decision Support Systems in Construction Tender Management. International Journal
of Civil Engineering and Technology (IJCIET), 9(7), (pp.1871-1886).
Mombini, H., & Tulu, B. (2020). A Systematic Review of Decision-making Theories used in
Decision Support Systems Research. AMCIS 2020 Proceedings. 8.(pp. 267-270).
Noor, N. M., Papamichail, K. N., & Warboys, B. (2006, June). An integrated web-based decision
support system for tendering processes. In Joint International Conference On Computing
And Decision Making In Civil And Building Engineering (pp.203-206).
Orta, E., Ruiz, M., Hurtado, N., and Gawn, D. 2014. "Decision-Making in It Service
Management: A Simulation Based Approach," Decision Support Systems (66), (pp. 36-
51).

Opus Kinetic (2019) Bid Management & Tender Evaluation: 4 Types of Tender and Tendering
Processes. Opuskinetic, [Link] Types of Tender
and Tendering Processes (pp.277-280)
Padumadasa, E. U. & Rehan, S. (2009, July). Investigation in to decision support systems and
multiple criteria decision making to develop a web based tender management system. In
International Symposium on the Analytic Hierarchy Process (pp. 21-37).
Palekar, A., Narwekar, K., Manjeshwar, P. & Rane, Y. (2015). Online Tender Management
System. International Journal for Scientific Research & Development, 3(8), (pp.688-689).

70
Parvar, J., Lowe, D., Emsley, M., Duff, R., & Akintoye, A. (2000). Neural networks as a
decision support system for the decision to bid process. In 16th Annual ARCOM
Conference (pp. 209-217).

Rotich, G., Muma, B., & Waruguru, E. (2015). Relationship between E-tendering and
procurement performance among County Governments in Kenya. Science Innovation,
3(5), (pp.46-51).
Runeson, G. & Skitmore, M. (1999). Tendering theory revisited. Construction Management and
Economics, 17(3), (285-296).
Runeson, G. (1996). Tendering theory 40 years on. CIB REPORT, (pp.535-548).
Sidwell, A. C., Budiawan, D., & Ma, T. (2001). The significance of the tendering contract on the
opportunities for clients to encourage contractorled innovation. Construction Innovation,
1(2) (pp.107 – 116).
Sutton, R. T., Pincock, D., Baumgart, D. C., Sadowski, D. C., Fedorak, R. N., & Kroeker, K. I.
(2020). An overview of clinical decision support systems: benefits, risks, and strategies for
success. NPJ digital medicine, 3(1), (pp.1-10).
Tender Info (2022). An Introduction to Tendering. Tendersinfo Resources Group –
[Link] (pp.20-27).
Tripathi, K. P. (2011). Decision support system is a tool for making better decisions in the
organization. Indian Journal of Computer Science and Engineering (IJCSE), 2(1), 112-
117.
Priya C. & K. Ramamoorthy, (2016). Online Tendering System (Volume 1, pp. 543-556)

71
 Appendix A

Source Code

USER DASHBOARD

<?php
use Phppot\Tender;
require_once __DIR__ . '/Model/action_tender.php';
//if (isset($_SESSION["uid"])) {
// require_once __DIR__ . '/Model/action_tender.php';
// $tender = new Tender();
// $tenderResult = $tender->getTender();
//}
?>
<?php include('includes/[Link]'); ?>

<div class="panel-header panel-header-lg">

</div>
<div class="content">
<div class="row">
<div class="col-lg-4" style="margin-top: -200px;">
<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Bidding Process is Ongoing</h5>
<h4 class="card-title">Current Tender</h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
<?php
$con = mysqli_connect("localhost", "root", "", "tendering");
$selecttender = "SELECT * FROM tbl_tender WHERE active='1'";
$querytender = mysqli_query($con, $selecttender);
while ($gettender = mysqli_fetch_assoc($querytender)) {
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<p class='card-title'>Title: ".$gettender["title"]."</p>
<p class='card-text'>Description: ".$gettender["description"]."</p><br>
<h5 class='card-text'>Start Date: ".$gettender["startDate"]."</h5><br>
<h5 class='card-text'>End Date: ".$gettender["endDate"]."</h5>
</div>
</div>";
}
?>
</div>
72
 </div>
</div>
</div>
</div>

<div class="col-lg-4 col-md-6" style="margin-top: -200px;">

<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Status from Admin</h5>
<h4 class="card-title">My Bid Review <br><sup><small>(Not Yet
Accepted)</small>
<sup></h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
<?php
$username = $_SESSION["username"];
$con = mysqli_connect("localhost", "root", "", "tendering");
$selectmember = "SELECT * FROM tbl_user WHERE username='$username'";
$querymember = mysqli_query($con, $selectmember);
$getmember = mysqli_fetch_assoc($querymember);
$uid = $getmember["uid"];
$selectquote = "SELECT * FROM tbl_quoted WHERE username='$username'";
$queryquote = mysqli_query($con, $selectquote);
while ($getquote = mysqli_fetch_assoc($queryquote)) {
$quoteid = $getquote["id"];
$bidid = json_decode($getquote["bid_id"])[0];
$selectbid = "SELECT * FROM tbl_bid WHERE bidId='$bidid'";
$querybid = mysqli_query($con, $selectbid);
$getbid = mysqli_fetch_assoc($querybid);
$tendid = $getbid["tendserId"];
$selecttend = "SELECT * FROM tbl_tender WHERE tenderId='$tendid'";
$querytend = mysqli_query($con, $selecttend);
$gettend = mysqli_fetch_assoc($querytend);

$selectacc = "SELECT * FROM tbl_bid_acceptance WHERE

quote_id='$quoteid'";
$queryacc = mysqli_query($con, $selectacc);
$num = mysqli_num_rows($queryacc);
if ($num == 0) {
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<p class='card-title'>Title: ".$gettend["title"]."</p>
<h4 class='card-title'>Total: ".$getquote["quoted_amount"]."</h4>
</div>
</div>";
73
 }
}
?>
</div>
</div>
</div>
</div>
</div>
<div class="col-lg-4 col-md-6" style="margin-top: -200px;">
<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Bid Statistics</h5>
<h4 class="card-title">Bid Performance</h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
<?php
$username = $_SESSION["username"];
$con = mysqli_connect("localhost", "root", "", "tendering");

$selectmember = "SELECT * FROM tbl_user WHERE username='$username'";

$querymember = mysqli_query($con, $selectmember);
$getmember = mysqli_fetch_assoc($querymember);
$uid = $getmember["uid"];

// Get all tenderid user bidded on

$tendarr = array();
$selectbid = "SELECT * FROM tbl_bid WHERE uid='$uid'";
$querybid = mysqli_query($con, $selectbid);
$num = mysqli_num_rows($querybid);
if ($num != 0) {
while ($getbid = mysqli_fetch_assoc($querybid)) {
array_push($tendarr, $getbid["tendserId"]);
}

//Get all tender

$selecttend = "SELECT * FROM tbl_tender";
$querytend = mysqli_query($con, $selecttend);
while ($gettend = mysqli_fetch_assoc($querytend)) {
$tendid = $gettend["tenderId"];

// Get all user bid

$userbid = array();
$selectbid = "SELECT * FROM tbl_bid WHERE uid='$uid' &&
tendserId='$tendid'";
$querybid = mysqli_query($con, $selectbid);
74
 while ($getbid = mysqli_fetch_assoc($querybid)) {
array_push($userbid, $getbid["bidId"]);
}

// Get all not user bid

$notuserbid = array();
$selectbid = "SELECT * FROM tbl_bid WHERE uid!='$uid' &&
tendserId='$tendid'";
$querybid = mysqli_query($con, $selectbid);
while ($getbid = mysqli_fetch_assoc($querybid)) {
array_push($notuserbid, $getbid["bidId"]);
}

// Sum user bid

$sumuserbid = 0;
foreach ($userbid as $key => $value) {
$sumuserbid = $sumuserbid + 1;
}

// Sum not user bid

$sumnotuserbid = 0;
foreach ($notuserbid as $key => $value) {
$sumnotuserbid = $sumnotuserbid + 1;
}

// Compare
$total = $sumuserbid + $sumnotuserbid;
$percent = ((intval($sumuserbid)/intval($total))*100);
if ($percent < 30) {
$remark = "Poor";
} elseif ($percent < 60) {
$remark = "Good";
} elseif ($percent <= 100) {
$remark = "Excellent";
}
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<p class='card-text'>Grand Total Bid: ".$sumuserbid."</p><br>
<p class='card-text'>Percentage Bid: ".$percent."%</p>
<p class='card-text'>Total Item on Bid: ".$total."</p>
<p class='card-text'>Remark: ".$remark."</p>
</div>
</div>";
}
}
?>
</div>
75
 </div>
</div>
</div>
</div>
</div>

</div>
<?php include('includes/[Link]'); ?>

INDEX PAGE
<?php
require_once __DIR__ . "/[Link]";
?>
LOGIN PAGE
<?php
use Phppot\Member;

if (! empty($_POST["login-btn"])) {
require_once __DIR__ . '/Model/[Link]';
$member = new Member();
$loginResult = $member->loginMember();
}
?>
<HTML>
<HEAD>
<TITLE>Login</TITLE>
<link href="assets/css/[Link]" type="text/css" rel="stylesheet" />
<link href="assets/css/[Link]" type="text/css" rel="stylesheet" />
<script src="vendor/jquery/[Link]" type="text/javascript"></script>
</HEAD>
<BODY>
<div class="phppot-container">
<div class="sign-up-container">
<div class="login-signup">
<a href="[Link]">Sign up</a>
</div>
<div class="signup-align">
<form name="login" action="" method="post" onsubmit="return
loginValidation()">
<div class="signup-heading">User Login</div>
<?php if(!empty($loginResult)){?>
<div class="error-msg"><?php echo $loginResult;?></div>
<?php }?>
<div class="row">
76
 <div class="inline-block">
<div class="form-label">
Username<span class="required
error" id="username-info"></span>
</div>
<input class="input-box-330" type="text"
name="username"
id="username">
</div>
</div>
<div class="row">
<div class="inline-block">
<div class="form-label">
Password<span class="required
error" id="login-password-info"></span>
</div>
<input class="input-box-330"
type="password"
name="login-password" id="login-
password">
</div>
</div>
<div class="row">
<input class="btn" type="submit" name="login-
btn"
id="login-btn" value="Login">
</div>
</form>
</div>
</div>
</div>

<script>
function loginValidation() {
var valid = true;
$("#username").removeClass("error-field");
$("#password").removeClass("error-field");

var UserName = $("#username").val();

var Password = $('#login-password').val();

$("#username-info").html("").hide();

if ([Link]() == "") {
$("#username-info").html("required.").css("color", "#ee0000").show();
$("#username").addClass("error-field");
valid = false;
}
77
 if ([Link]() == "") {
$("#login-password-info").html("required.").css("color", "#ee0000").show();
$("#login-password").addClass("error-field");
valid = false;
}
if (valid == false) {
$('.error-field').first().focus();
valid = false;
}
return valid;
}
</script>
</BODY>
</HTML>

LOGOUT PAGE

<?php
// clear all the session variables and redirect to index
session_start();
session_unset();
session_write_close();
$url = "./[Link]";
header("Location: $url");

USER PROFILE

<?php
include('includes/[Link]');
?>
<div class="panel-header panel-header-sm">
</div>
<div class="content">
<div class="row">
<div class="col-md-6 offset-md-3">
<div class="card">
<div class="card-header d-flex">
<h5 class="title">Profile</h5>
</div>
<div class="card-body">
<div class="table-responsive">
<table class="table">
<tbody>
<?php
$username = $_SESSION["username"];
$con = mysqli_connect("localhost", "root", "", "tender");
$selectuser = "SELECT * FROM tbl_user WHERE username='$username'";
78
 $queryuser = mysqli_query($con, $selectuser);
$getuser = mysqli_fetch_assoc($queryuser);
$uid = $getuser["uid"];
$selecttender = "SELECT * FROM tbl_user WHERE uid='$uid'";
$querytender = mysqli_query($con, $selecttender);
while ($gettender = mysqli_fetch_assoc($querytender)) {
echo "
<tr>
<th>Fullname</th>
<td>".$gettender["fullname"]."</td>
</tr>
<tr>
<th>Company Name</th>
<td>".$gettender["compName"]."</td>
</tr>
<tr>
<th>Description</th>
<td>".$gettender["description"]."</td>
</tr>
<tr>
<th>Registration Number</th>
<td>".$gettender["regNo"]."</td>
</tr>
<tr>
<th>Email</th>
<td>".$gettender["email"]."</td>
</tr>
<tr>
<th>Address</th>
<td>".$gettender["address"]."</td>
</tr>
<tr>
<th>Username</th>
<td>".$gettender["username"]."</td>
</tr>";
}
?>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

79
SUBMIT BID SCRIPT

<?php
session_start();
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$username = $_SESSION["username"];
$tender = $_POST["tender"];
$con = mysqli_connect("localhost", "root", "", "tender");
$desc = json_decode($_SESSION["desc"]);
$quan = json_decode($_SESSION["quan"]);
$unit = json_decode($_SESSION["unit"]);
$amount = json_decode($_SESSION["amnt"]);
$selectuser = "SELECT * FROM tbl_user WHERE username='$username'";
$queryuser = mysqli_query($con, $selectuser);
$getuser = mysqli_fetch_assoc($queryuser);
$uid = $getuser["uid"];
$compName = $getuser["compName"];
$quoted = 0;
$qdate = date("d-m-Y h:i:sa");
$arr_of_bid = array();

for ($i=0; $i < count($desc); $i++) {

$d = $desc[$i];
$q = $quan[$i];
$u = $unit[$i];
$a = $amount[$i];
$quoted = $quoted + $amount[$i];
$insertbid = "INSERT INTO tbl_bid (uid, tendserId, description, unitprices, quantity, amount)
VALUES ('$uid', '$tender', '$d', '$u', '$q', '$a')";
mysqli_query($con, $insertbid);
array_push($arr_of_bid, mysqli_insert_id($con));
unset($_SESSION["desc"]);
unset($_SESSION["quan"]);
unset($_SESSION["unit"]);
unset($_SESSION["amnt"]);
unset($_SESSION["amount"]);
}
$arr = json_encode($arr_of_bid);
$insertquoted = "INSERT INTO tbl_quoted (username, bid_id, tenderId, compName,
quoted_amount, qdate) VALUES ('$username', '$arr', '$tender', '$compName', '$quoted',
'$qdate')";
mysqli_query($con, $insertquoted);
$_SESSION["alert"] = "Bidding Successful";
header("location: create_bid.php");
}
?>
80
USER REGISTRATION PAGE
<?php
error_reporting(0);
use Phppot\Member;
if (! empty($_POST["signup-btn"])) {
require_once './Model/[Link]';
$member = new Member();
$registrationResponse = $member->registerMember();
}
?>
<HTML>
<HEAD>
<TITLE>Company Registration</TITLE>
<link href="assets/css/[Link]" type="text/css"
rel="stylesheet" />
<link href="assets/css/[Link]" type="text/css"
rel="stylesheet" />
<script src="vendor/jquery/[Link]" type="text/javascript"></script>
</HEAD>
<BODY>
<div class="phppot-container">
<div class="sign-up-container">
<div class="login-signup">
<a href="[Link]">Login</a>
</div>
<div class="">
<form name="sign-up" action="" method="post"
onsubmit="return signupValidation()">
<div class="signup-heading">Company Registration</div>
<?php if (! empty($registrationResponse["status"])) { ?>
<?php if ($registrationResponse["status"] == "error") { ?>
<div class="server-response error-msg"><?php echo
$registrationResponse["message"]; ?></div>
<?php
} else if ($registrationResponse["status"] == "success") {
?>
<div class="server-response success-msg"><?php echo
$registrationResponse["message"]; ?></div>
<?php
}
?>
<?php
}
?>
<div class="error-msg" id="error-msg"></div>
<div class="row">
81
 <div class="inline-block">
<div class="form-label">
Full Name<span class="required
error" id="fullname-info"></span>
</div>
<input class="input-box-330" type="text"
name="fullname" id="fullname">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Company Name<span
class="required error" id="compname-info"></span>
</div>
<input class="input-box-330" type="text"
name="compname" id="compname">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Company Description<span
class="required error" id="description-info"></span>
</div>
<input class="input-box-330" type="text"
name="description" id="description">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Registration Number<span
class="required error" id="regno-info"></span>
</div>
<input class="input-box-330" type="text"
name="regno" id="regno">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Email<span class="required error"
id="email-info"></span>
82
 </div>
<input class="input-box-330" type="email"
name="email" id="email">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Address<span class="required error"
id="address-info"></span>
</div>
<input class="input-box-330" type="text"
name="address" id="address">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Username<span class="required
error" id="username-info"></span>
</div>
<input class="input-box-330" type="text"
name="username" id="username">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Password<span class="required
error" id="signup-password-info"></span>
</div>
<input class="input-box-330"
type="password" name="signup-password" id="signup-password">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Confirm Password<span
class="required error" id="confirm-password-info"></span>
</div>
<input class="input-box-330"
type="password" name="confirm-password" id="confirm-password">
</div>
83
 </div>

<div class="row">
<input class="btn" type="submit" name="signup-
btn"
id="signup-btn" value="Sign up">
</div>
</form>
</div>
</div>
</div>

<script>
function signupValidation() {
var valid = true;

$("#username").removeClass("error-field");
$("#email").removeClass("error-field");
$("#password").removeClass("error-field");
$("#confirm-password").removeClass("error-field");

var UserName = $("#username").val();

var email = $("#email").val();
var Password = $('#signup-password').val();
var ConfirmPassword = $('#confirm-password').val();
var emailRegex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]
{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

$("#username-info").html("").hide();
$("#email-info").html("").hide();

if ([Link]() == "") {
$("#username-info").html("required.").css("color", "#ee0000").show();
$("#username").addClass("error-field");
valid = false;
}
if (email == "") {
$("#email-info").html("required").css("color", "#ee0000").show();
$("#email").addClass("error-field");
valid = false;
} else if ([Link]() == "") {
$("#email-info").html("Invalid email address.").css("color", "#ee0000").show();
$("#email").addClass("error-field");
valid = false;
} else if () {
$("#email-info").html("Invalid email address.").css("color", "#ee0000")
.show();
$("#email").addClass("error-field");
84
 valid = false;
}
if ([Link]() == "") {
$("#signup-password-info").html("required.").css("color", "#ee0000").show();
$("#signup-password").addClass("error-field");
valid = false;
}
if ([Link]() == "") {
$("#confirm-password-info").html("required.").css("color", "#ee0000").show();
$("#confirm-password").addClass("error-field");
valid = false;
}
if(Password != ConfirmPassword){
$("#error-msg").html("Both passwords must be same.").show();
valid=false;
}
if (valid == false) {
$('.error-field').first().focus();
valid = false;
}
return valid;
}
</script>
</BODY>
</HTML>

VIEW ACCEPTED BID

<?php
include('includes/[Link]');
?>
<div class="panel-header panel-header-sm">
</div>
<div class="content">
<div class="row">
<div class="col-md-6 offset-md-3">
<div class="card">
<div class="card-header d-flex">
<h5 class="title">Accepted Bids</h5>
</div>
<div class="card-body">
<?php
$username = $_SESSION["username"];
$con = mysqli_connect("localhost", "root", "", "tender");
$selectacc = "SELECT * FROM tbl_bid_acceptance WHERE username='$username'";
$queryacc = mysqli_query($con, $selectacc);
while ($getacc = mysqli_fetch_assoc($queryacc)) {
$tendid = $getacc["tenderId"];
$selecttend = "SELECT * FROM tbl_tender WHERE tenderId='$tendid'";
85
 $querytend = mysqli_query($con, $selecttend);
$gettend = mysqli_fetch_assoc($querytend);
echo "
<div class='card border m-2'>
<div class='card-header border m-2'><b>Tender Title: </b>".
$getacc["tenderTitle"]."</div>
<div class='card-body text-center'>
<p><b>Company Name:</b> ".$getacc["UcompName"]."</p>
<p><b>Tender Description:</b> ".$gettend["description"]."</p>
<p><b>Reg No:</b> ".$getacc["UcomRegNo"]."</p>
</div>
</div>";
}
?>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

VIEW TENDER PAGE

<?php
include('includes/[Link]');
?>
<div class="panel-header panel-header-sm">
</div>
<div class="content">
<div class="row">
<div class="col-md-6 offset-md-3">
<div class="card">
<div class="card-header d-flex">
<h5 class="title">Tender List</h5>
</div>
<div class="card-body">
<div class="table-responsive">
<table class="table">
<thead class=" text-primary">
<th>SN</th>
<th> Title</th>
<th>Description</th>
<th>Start Time</th>
<th> End Time</th>
</thead>
<tbody>

86
 <?php
$con = mysqli_connect("localhost", "root", "", "tender");
$selecttender = "SELECT * FROM tbl_tender";
$querytender = mysqli_query($con, $selecttender);
while ($gettender = mysqli_fetch_assoc($querytender)) {
if (time() <= (strtotime($gettender["endDate"])+86400)) {
echo "
<tr>
<td>".($gettender["tenderId"])."</td>
<td>".$gettender["title"]."</td>
<td>".$gettender["description"]."</td>
<td>".$gettender["startDate"]."</td>
<td>".$gettender["endDate"]."</td>
</tr>";
}
}
?>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

CREATE BID SCRIPT

<?php
if (isset($_SESSION["alert"])) {
echo "<script>alert(\"".$_SESSION["alert"]."\");</script>";
unset($_SESSION["alert"]);
}
include('includes/[Link]');
?>
<div class="panel-header panel-header-sm">
</div>
<div class="content">
<div class="row">
<div class="col-md-6 offset-md-3">
<div class="card">
<form method="post" action="submit_bid.php">
<div class="card-header d-flex">
<h5 class="title">Create Bid for
<select name="tender" class="form-control">
<?php
87
 $con = mysqli_connect("localhost", "root", "", "tender");
$username = $_SESSION["username"];
if (isset($_SESSION["desc"]) || isset($_SESSION["quan"]) ||
isset($_SESSION["unit"])) {
$desc = json_decode($_SESSION["desc"]);
$quan = json_decode($_SESSION["quan"]);
$unit = json_decode($_SESSION["unit"]);
}
$selecttend = "SELECT * FROM tbl_tender";
$querytend = mysqli_query($con, $selecttend);
while ($gettend = mysqli_fetch_assoc($querytend)) {
$tid = $gettend["tenderId"];
$selectquote = "SELECT * FROM tbl_quoted WHERE username='$username' &&
tenderId='$tid'";
$queryquote = mysqli_query($con, $selectquote);
$numquote = mysqli_num_rows($queryquote);
if ($numquote == 0) {
if (time() <= (strtotime($gettend["endDate"])+86400)) {
echo "<option value='".$gettend["tenderId"]."'>".$gettend["title"]."</option>";
}
}
}
?>
</select>
</h5>
</div>
<div class="card-body">
<!-- <?php
print_r($gettend) ?>
<?= time() ?>
<?= strtotime($gettend["endDate"])+86400 ?>
<?= $gettend["endDate"] ?> -->
<table class="table">
<thead class=" text-primary">
<th>SN</th>
<th>Description</th>
<th>Quantity</th>
<th>Unit Price</th>
<th>Amount</th>
</thead>
<tbody id="tbody">
</tbody>
</table>
<table class="table" style="display:block !important">
<thead class=" text-primary">
<th id='id'></th>
<th><td><input id='desc' class='form-control' placeholder='Description'
name='description[]'></td></th>
88
 <th><td><input id='quan' type='number' class='form-control'
placeholder='Quantity' name='quantity[]'></td></th>
<th><td><input id='unit' type='number' class='form-control' placeholder='Unit
Price' name='unitprice[]'></td></th>
<th id='amount'></th>
</thead>
</table>
<p>
<button class="btn" type="button" onclick="addItem();" id="login-btn">
+ Add New Item
</button>
</p>
<p>
<input class="btn" type="submit" name="bid-btn" id="login-btn" value="Submit
Bid">
</p>
</div>
</form>
</div>
</div>
</div>
</div>

<script type="application/javascript">
function addItem() {
var desc = [Link]("desc").value;
var quan = [Link]("quan").value;
var unit = [Link]("unit").value;
var xmlhttp = new XMLHttpRequest();
[Link] = function() {
if ([Link] == 4 && [Link] == 200) {
[Link]("tbody").innerHTML = [Link];
}
};
[Link]("GET","create_bid_func.php?
desc="+desc+"&quan="+quan+"&unit="+unit,true);
[Link]();
}
</script>
<?php include('includes/[Link]'); ?>

CREATE BID FUNCTIONS

<?php
session_start();
if (!isset($_SESSION["desc"]) || !isset($_SESSION["quan"]) || !isset($_SESSION["unit"])) {
$desc = array();
$quan = array();
89
 $unit = array();
$amnt = array();
array_push($desc, $_GET["desc"]);
array_push($quan, $_GET["quan"]);
array_push($unit, $_GET["unit"]);
$total = 0;
for ($i=0; $i < count($desc); $i++) {
$amount = (intval($quan[$i])*intval($unit[$i]));
echo "
<tr>
<td>".($i+1)."</td>
<td>".$desc[$i]."</td>
<td>".$quan[$i]."</td>
<td>".$unit[$i]."</td>
<td>".$amount."</td>
</tr>";
$total = $total + $amount;
}
array_push($amnt, $amount);
echo "
<tr>
<td>Total</td>
<td></td>
<td></td>
<td></td>
<td>".$total."</td>
</tr>";
$_SESSION["desc"] = json_encode($desc);
$_SESSION["quan"] = json_encode($quan);
$_SESSION["unit"] = json_encode($unit);
$_SESSION["amnt"] = json_encode($amnt);
$_SESSION["amount"] = $amount;
} else {
$desc = json_decode($_SESSION["desc"]);
$quan = json_decode($_SESSION["quan"]);
$unit = json_decode($_SESSION["unit"]);
$amnt = json_decode($_SESSION["amnt"]);
array_push($desc, $_GET["desc"]);
array_push($quan, $_GET["quan"]);
array_push($unit, $_GET["unit"]);
$total = 0;
for ($i=0; $i < count($desc); $i++) {
$amount = (intval($quan[$i])*intval($unit[$i]));
echo "
<tr>
<td>".($i+1)."</td>
<td>".$desc[$i]."</td>
<td>".$quan[$i]."</td>
90
 <td>".$unit[$i]."</td>
<td>".$amount."</td>
</tr>";
$total = $total + $amount;
}
array_push($amnt, $amount);
echo "
<tr>
<td>Total</td>
<td></td>
<td></td>
<td></td>
<td>".$total."</td>
</tr>";
$_SESSION["desc"] = json_encode($desc);
$_SESSION["quan"] = json_encode($quan);
$_SESSION["unit"] = json_encode($unit);
$_SESSION["amnt"] = json_encode($amnt);
$_SESSION["amount"] = $amount;
}
?>

ADMIN ACCEPT BID SCRIPT

<?php
session_start();
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$quote_id = $_POST["quoteid"];
$now = date("Y-m-d");
$con = mysqli_connect("localhost", "root", "", "tendering");
$selectquote = "SELECT * FROM tbl_quoted WHERE id='$quote_id'";
$queryquote = mysqli_query($con, $selectquote);
$getquote = mysqli_fetch_assoc($queryquote);
$bidid = json_decode($getquote["bid_id"])[0];
$selectbid = "SELECT * FROM tbl_bid WHERE bidId='$bidid'";
$querybid = mysqli_query($con, $selectbid);
$getbid = mysqli_fetch_assoc($querybid);
$uid = $getbid["uid"];
$tenderId = $getbid["tendserId"];
$selectuser = "SELECT * FROM tbl_user WHERE uid='$uid'";
$queryuser = mysqli_query($con, $selectuser);
$getuser = mysqli_fetch_assoc($queryuser);
$username = $getuser["username"];
$compname = $getuser["compName"];
$regNo = $getuser["regNo"];
$selecttender = "SELECT * FROM tbl_tender WHERE tenderId='$tenderId'";
$querytender = mysqli_query($con, $selecttender);
$gettender = mysqli_fetch_assoc($querytender);
91
 $title = $gettender["title"];
$insertbid = "INSERT INTO tbl_bid_acceptance (quote_id, tenderId, uid, tenderTitle,
username, UcompName, UcomRegNo, date) VALUES ('$quote_id', '$tenderId', '$uid', '$title',
'$username', '$compname', '$regNo', '$now')";
mysqli_query($con, $insertbid);
header("location: view_bids.php");
}
?>

<?php include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">Accepted Bids</h5>
</div>
<div class="card-body">
<div class="col-md-12">
<div class="card card-plain">
<div class="card-header">
</div>
<div class="card-body">
<div class="table-responsive">
<table class="table">
<thead class=" text-primary">
<th>SN</th>
<th>Tender Title</th>
<th>Bidder's Username</th>
<th>Bidder's Company Name</th>
<th>Bidder's Registration Number</th>
<th>Bidder's Company Logo</th>
<th>Date</th>
</thead>
<tbody>
<?php
$con = mysqli_connect("localhost", "root", "", "tendering");
$selectacc = "SELECT * FROM tbl_bid_acceptance";
$queryacc = mysqli_query($con, $selectacc);
while ($getacc = mysqli_fetch_assoc($queryacc)) {
echo "
<tr>
<td>".($getacc["bidAccId"])."</td>
<td>".($getacc["tenderTitle"])."</td>
<td>".($getacc["username"])."</td>
<td>".($getacc["UcompName"])."</td>
<td>".($getacc["UcomRegNo"])."</td>
92
 <td>".($getacc["UcompLogo"])."</td>
<td>".($getacc["date"])."</td>
</tr>";
}
?>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

ADMIN DASHBOARD SCRIPT

<?php include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">Admin Dashboard</h5>
</div>
<div class="card-body">
<h4 class="card-title">Features</h4>
<a href="create_tender.php" class="card-link">Create Tender</a>
<p class="card-text">Create Tender for bidding.</p>
<a href="View_tender.php" class="card-link">View Tender</a>
<p class="card-text">View created tenders.</p>
<a href="view_bids.php" class="card-link">View Users Bids</a>
<a href="accepted_bids.php" class="card-link">View Accepted Bids</a>
<p class="card-text">View and accept user bids.</p>
<a href="../" class="card-link">User Login Page</a>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

93
CREATE REPORT SCRIPT

<?php
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$con = mysqli_connect("localhost", "root", "", "tendering");
$tenderid = $_POST["tenderid"];
$report = $_POST["report"];
$date = date("Y-m-d");
$selectrep = "SELECT * FROM tbl_report WHERE tenderid='$tenderid'";
$queryrep = mysqli_query($con, $selectrep);
$num = mysqli_num_rows($queryrep);
if ($num == 0) {
$insertrep = "INSERT INTO tbl_report (tenderid, report, date) VALUES ('$tenderid', '$report',
'$date')";
mysqli_query($con, $insertrep);
} else {
$updaterep = "UPDATE tbl_report SET report='$report', date='$date' WHERE
tenderid='$tenderid'";
mysqli_query($con, $updaterep);
}
header("location: create_report.php");
}
include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">Create Report</h5>
</div>
<div class="card-body">

<div class="col-md-6 offset-md-4">

<h6 class="title">Select Tender</h6>
<ul class="nav nav-tabs" role="tablist">
<?php
$con = mysqli_connect("localhost", "root", "", "tendering");
$selecttender = "SELECT * FROM tbl_tender";
$querytender = mysqli_query($con, $selecttender);
$i = 1;
while ($gettender = mysqli_fetch_assoc($querytender)) {
if ($i == 1) {
echo "
<li class='nav-item'>
<a class='nav-link active' data-toggle='tab' href='#id".
$gettender["tenderId"]."'>".$gettender["title"]."</a>
</li>";
94
 } else {
echo "
<li class='nav-item'>
<a class='nav-link' data-toggle='tab' href='#id".$gettender["tenderId"]."'>".
$gettender["title"]."</a>
</li>";
}
$i = $i + 1;
}
?>
</ul>

<!-- Tab panes -->

<div class="tab-content">
<?php
$con = mysqli_connect("localhost", "root", "", "tendering");
$selecttender = "SELECT * FROM tbl_tender";
$querytender = mysqli_query($con, $selecttender);
$i = 1;
while ($gettender = mysqli_fetch_assoc($querytender)) {
$tendid = $gettender["tenderId"];
$selectreport = "SELECT * FROM tbl_report WHERE tenderid='$tendid'";
$queryreport = mysqli_query($con, $selectreport);
$getreport = mysqli_fetch_assoc($queryreport);
if ($i == 1) {
echo "
<div id='id".$gettender["tenderId"]."' class='container tab-pane active'><br>
<h3>".$gettender["title"]."</h3>
<p>".$getreport["report"]."</p>^{".$getreport["date"]."}<br>
<form name='sign-up' action='create_report.php' method='post'>
<input type='hidden' name='tenderid' value='".$gettender["tenderId"]."'>
<textarea class='phppot-textarea' rows='4' cols='50' name='report'
id='report'></textarea>
<div class='row'>
<input class='btn' type='submit' name='signup-btn'id='signup-btn' value='Create
Report'>
</div>
</form>
</div>";
} else {
echo "
<div id='id".$gettender["tenderId"]."' class='container tab-pane fade'><br>
<h3>".$gettender["title"]."</h3>
<p>".$getreport["report"]."</p>^{".$getreport["date"]."}<br>
<form name='sign-up' action='create_report.php' method='post'>
<input type='hidden' name='tenderid' value='".$gettender["tenderId"]."'>
<textarea class='phppot-textarea' rows='4' cols='50' name='report'
id='report'></textarea>
95
 <div class='row'>
<input class='btn' type='submit' name='signup-btn'id='signup-btn' value='Create
Report'>
</div>
</form>
</div>";
}
$i = $i + 1;
}
?>
</div>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

CREATE TENDER SCRIPT

<?php
use Phppot\Tender;
if (! empty($_POST["signup-btn"])) {
require_once './Model/action_create_tender.php';
$tender = new Tender();
$createTenderResponse = $tender->createTender();
}
?>
<?php include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">Create Tender</h5>
</div>
<div class="card-body">

<div class="col-md-6 offset-md-4">

<form name="sign-up" action="create_tender.php" method="post"
onsubmit="return signupValidation()">

<?php if (! empty($createTenderResponse["status"])) { ?>

<?php if ($createTenderResponse["status"] == "error") { ?>
<div class="server-response error-msg"><?php echo
$createTenderResponse["message"]; ?></div>
96
 <?php
} else if ($createTenderResponse["status"] == "success") {
?>
<div class="server-response success-msg"><?php echo $
$createTenderResponse["message"]; ?></div>
<?php
}
?>
<?php
}
?>
<div class="error-msg" id="error-msg"></div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Tender Title<span class="required error"
id="username-info"></span>
</div>
<input class="input-box-330" type="text" name="title" id="title">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Description<span class="required error"
id="username-info"></span>
</div>
<textarea class="phppot-textarea" rows="4" cols="50"
name="description" id="description"></textarea>
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
Start Date<span class="required error" id="sdate-info"></span>
</div>
<input class="input-box-330" type="date" name="sdate" id="sdate">
</div>
</div>

<div class="row">
<div class="inline-block">
<div class="form-label">
End Date<span class="required error" id="edate-info"></span>
</div>
97
 <input class="input-box-330" type="date" name="edate" id="edate">
</div>
</div>

<div class="row">
<input class="btn" type="submit" name="signup-btn"id="signup-btn"
value="Create Tender">
</div>
</form>
</div>

</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

VIEW MEMBER SCRIPT

<?php include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">List of Members</h5>
</div>
<div class="card-body">
<div class="table-responsive">
<table class="table">
<thead class=" text-primary">
<th>SN</th>
<th>Fullname</th>
<th>Company Name</th>
<th>Description</th>
<th>Registeration Number</th>
<th>Email</th>
<th>Address</th>
<th>Username</th>
</thead>
<tbody>
<?php
$con = mysqli_connect("localhost", "root", "", "tendering");
$selectmember = "SELECT * FROM tbl_user";
$querymember = mysqli_query($con, $selectmember);
while ($getmember = mysqli_fetch_assoc($querymember)) {
echo "
<tr>
98
 <td>".$getmember["uid"]."</td>
<td>".$getmember["fullname"]."</td>
<td>".$getmember["compName"]."</td>
<td>".$getmember["description"]."</td>
<td>".$getmember["regNo"]."</td>
<td>".$getmember["email"]."</td>
<td>".$getmember["address"]."</td>
<td>".$getmember["username"]."</td>
</tr>";
}
?>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>

<?php include('includes/[Link]'); ?>

VIEW TENDER ADMIN SCRIPT

<?php include('includes/[Link]'); ?>

<div class="row">
<div class="col-md-12 offset-md-0">
<div class="card">
<div class="card-header">
<h5 class="title">Tender List</h5>
</div>
<div class="card-body">
<div class="col-md-12">
<div class="card card-plain">
<div class="card-header">
</div>
<div class="card-body">
<div class="table-responsive">
<table class="table">
<thead class=" text-primary">
<th>SN</th>
<th> Title</th>
<th>Description</th>
<th>Start Time</th>
<th> End Time</th>
</thead>
<tbody>
<?php
99
 $con = mysqli_connect("localhost", "root", "", "tendering");
$selecttender = "SELECT * FROM tbl_tender";
$querytender = mysqli_query($con, $selecttender);
while ($gettender = mysqli_fetch_assoc($querytender)) {
echo "
<tr>
<td>".($gettender["tenderId"])."</td>
<td>".$gettender["title"]."</td>
<td>".$gettender["description"]."</td>
<td>".$gettender["startDate"]."</td>
<td>".$gettender["endDate"]."</td>
</tr>";
}
?>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<?php include('includes/[Link]'); ?>

DATABASE CONNECTIONS

<?php
/**
* Copyright (C) Phppot
*
* Distributed under 'The MIT License (MIT)'
* In essense, you can do commercial use, modify, distribute and private use.
* Though not mandatory, you are requested to attribute Phppot URL in your code or website.
*/
namespace Phppot;

/**
* Generic datasource class for handling DB operations.
* Uses MySqli and PreparedStatements.
*
* @version 2.7 - PDO connection option added
*/
class DataSource
{

// PHP 7.1.0 visibility modifiers are allowed for class constants.

100
 // when using above 7.1.0, declare the below constants as private
// for better encapsulation
const HOST = 'localhost';

const USERNAME = 'root';

const PASSWORD = '';

const DATABASENAME = 'tendering';

private $conn;

/**
* PHP implicitly takes care of cleanup for default connection types.
* So no need to worry about closing the connection.
*
* Singletons not required in PHP as there is no
* Concept of shared memory.
* Every object lives only for a request.
*
* Keeping things simple and that works!
*/
function __construct()
{
$this->conn = $this->getConnection();
}

/**
* If connection object is needed use this method and get access to it.
* Otherwise, use the below methods for insert / update / etc.
*
* @return \mysqli
*/
public function getConnection()
{
$conn = new \mysqli(self::HOST, self::USERNAME, self::PASSWORD,
self::DATABASENAME);

if (mysqli_connect_errno()) {
trigger_error("Problem with connecting to database.");
}

$conn->set_charset("utf8");
return $conn;
}

/**
* If you wish to use PDO use this function to get a connection instance
101
 *
* @return \PDO
*/
public function getPdoConnection()
{
$conn = FALSE;
try {
$dsn = 'mysql:host=' . self::HOST . ';dbname=' . self::DATABASENAME;
$conn = new \PDO($dsn, self::USERNAME, self::PASSWORD);
$conn->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
} catch (\Exception $e) {
exit("PDO Connect Error: " . $e->getMessage());
}
return $conn;
}

/**
* To get database results
*
* @param string $query
* @param string $paramType
* @param array $paramArray
* @return array
*/
public function select($query, $paramType = "", $paramArray = array())
{
$stmt = $this->conn->prepare($query);

if (! empty($paramType) && ! empty($paramArray)) {

$this->bindQueryParams($stmt, $paramType, $paramArray);

}
$stmt->execute();
$result = $stmt->get_result();

if ($result->num_rows > 0) {
while ($row = $result->fetch_assoc()) {
$resultset[] = $row;
}
}

if (! empty($resultset)) {
return $resultset;
}
}

/**
* To insert
102
 *
* @param string $query
* @param string $paramType
* @param array $paramArray
* @return int
*/
public function insert($query, $paramType, $paramArray)
{
$stmt = $this->conn->prepare($query);
$this->bindQueryParams($stmt, $paramType, $paramArray);

$stmt->execute();
$insertId = $stmt->insert_id;
return $insertId;
}

/**
* To execute query
*
* @param string $query
* @param string $paramType
* @param array $paramArray
*/
public function execute($query, $paramType = "", $paramArray = array())
{
$stmt = $this->conn->prepare($query);

if (! empty($paramType) && ! empty($paramArray)) {

$this->bindQueryParams($stmt, $paramType, $paramArray);
}
$stmt->execute();
}

/**
* 1.
* Prepares parameter binding
* 2. Bind prameters to the sql statement
*
* @param string $stmt
* @param string $paramType
* @param array $paramArray
*/
public function bindQueryParams($stmt, $paramType, $paramArray = array())
{
$paramValueReference[] = & $paramType;
for ($i = 0; $i < count($paramArray); $i ++) {
$paramValueReference[] = & $paramArray[$i];
}
103
 call_user_func_array(array(
$stmt,
'bind_param'
), $paramValueReference);
}

/**
* To get database results
*
* @param string $query
* @param string $paramType
* @param array $paramArray
* @return array
*/
public function getRecordCount($query, $paramType = "", $paramArray = array())
{
$stmt = $this->conn->prepare($query);
if (! empty($paramType) && ! empty($paramArray)) {

$this->bindQueryParams($stmt, $paramType, $paramArray);

}
$stmt->execute();
$stmt->store_result();
$recordCount = $stmt->num_rows;

return $recordCount;
}

HOME

<?php
use Phppot\Tender;
require_once __DIR__ . '/Model/action_tender.php';
//if (isset($_SESSION["uid"])) {
// require_once __DIR__ . '/Model/action_tender.php';
// $tender = new Tender();
// $tenderResult = $tender->getTender();
//}
?>
<?php include('includes/[Link]'); ?>

<div class="panel-header panel-header-lg">

</div>
<div class="content">
104
 <div class="row">
<div class="col-lg-4" style="margin-top: -200px;">
<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Bidding Process is Ongoing</h5>
<h4 class="card-title">Current Tender</h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
<?php
$con = mysqli_connect("localhost", "root", "", "tender");
$selecttender = "SELECT * FROM tbl_tender WHERE active='1'";
$querytender = mysqli_query($con, $selecttender);
while ($gettender = mysqli_fetch_assoc($querytender)) {
if (time() <= (strtotime($gettender["endDate"])+86400)) {
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<h6 class='card-title'>Title: ".$gettender["title"]."</h6>
<small class='card-text'>Description:
".$gettender["description"]."</small><br>
<small class='card-text'>Start Date: ".$gettender["startDate"]."</small><br>
<small class='card-text'>End Date: ".$gettender["endDate"]."</small>
</div>
</div>";
}
}
?>
</div>
</div>
</div>
</div>
</div>

<div class="col-lg-4 col-md-6" style="margin-top: -200px;">

<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Status from Admin</h5>
<h4 class="card-title">My Bid Review <br><sup><small>(Not Yet
Accepted)</small>
<sup></h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
<?php
$username = $_SESSION["username"];
105
 $con = mysqli_connect("localhost", "root", "", "tender");
$selectmember = "SELECT * FROM tbl_user WHERE username='$username'";
$querymember = mysqli_query($con, $selectmember);
$getmember = mysqli_fetch_assoc($querymember);
$uid = $getmember["uid"];
$selectquote = "SELECT * FROM tbl_quoted WHERE username='$username'";
$queryquote = mysqli_query($con, $selectquote);
while ($getquote = mysqli_fetch_assoc($queryquote)) {
$quoteid = $getquote["id"];
$bidid = json_decode($getquote["bid_id"])[0];
$selectbid = "SELECT * FROM tbl_bid WHERE bidId='$bidid'";
$querybid = mysqli_query($con, $selectbid);
$getbid = mysqli_fetch_assoc($querybid);
$tendid = $getbid["tendserId"];
$selecttend = "SELECT * FROM tbl_tender WHERE tenderId='$tendid'";
$querytend = mysqli_query($con, $selecttend);
$gettend = mysqli_fetch_assoc($querytend);

$selectacc = "SELECT * FROM tbl_bid_acceptance WHERE

quote_id='$quoteid'";
$queryacc = mysqli_query($con, $selectacc);
$num = mysqli_num_rows($queryacc);
if ($num == 0) {
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<h6 class='card-title'>Title: ".$gettend["title"]."</h6>
<small class='card-title'>Total Amount:
".$getquote["quoted_amount"]."</small>
</div>
</div>";
}
}
?>
</div>
</div>
</div>
</div>
</div>
<div class="col-lg-4 col-md-6" style="margin-top: -200px;">
<div class="card card-chart">
<div class="card-header">
<h5 class="card-category">Bid Statistics</h5>
<h4 class="card-title">Bid Performance</h4>
</div>
<div class="card-body">
<div class="chart-area">
<div class="card offset-md-50" style='box-shadow: none !important'>
106
<?php
$username = $_SESSION["username"];
$con = mysqli_connect("localhost", "root", "", "tender");

$bids = array();

// Get all user bid

$userbid = array();
$selectbid = "SELECT * FROM tbl_quoted WHERE username='$username'";
$querybid = mysqli_query($con, $selectbid);
$getbid = mysqli_fetch_assoc($querybid);
array_push($userbid, $getbid["quoted_amount"]);

$sumuserbid = array_sum($userbid);
array_push($bids, $sumuserbid);

// Get all not user bid

$notuserbid = array();
$selectbid = "SELECT * FROM tbl_quoted WHERE username!='$username'";
$querybid = mysqli_query($con, $selectbid);
while ($getbid = mysqli_fetch_assoc($querybid)) {
array_push($notuserbid, $getbid["quoted_amount"]);
array_push($bids, array_sum($notuserbid));
}
$sumnotuserbid = array_sum($notuserbid);

// Compare
$total = $sumuserbid + $sumnotuserbid;
$percent = ((intval($sumuserbid)/intval($total))*100);
if ($percent < 30) {
$remark = "Excellent";
} elseif ($percent < 60) {
$remark = "Good";
} elseif ($percent <= 100) {
$remark = "Poor";
}
asort($bids);
array_values($bids);
$i = 1;
foreach ($bids as $val) {
if ($val == $sumuserbid) {
break;
}
$i++;
}
if ($i == 1) {
$i = $i . "st";
} elseif ($i == 2) {
107
 $i = $i . "nd";
} elseif ($i == 3) {
$i = $i . "rd";
} else {
$i = $i . "th";
}
echo "
<div class='card text-center' style='box-shadow: none !important'>
<div class='card-body'>
<p class='card-text'>Bid Position: ".$i."</p>
<p class='card-text'>Percentage Bid: ".round($percent, 2)."%</p>
<p class='card-text'>Remark: ".$remark."</p><br>
</div>
</div>";

// $selectmember = "SELECT * FROM tbl_user WHERE username='$username'";

// $querymember = mysqli_query($con, $selectmember);
// $getmember = mysqli_fetch_assoc($querymember);
// $uid = $getmember["uid"];

// // Get all tenderid user bidded on

// $tendarr = array();
// $selectbid = "SELECT * FROM tbl_bid WHERE uid='$uid'";
// $querybid = mysqli_query($con, $selectbid);
// $num = mysqli_num_rows($querybid);
// if ($num != 0) {
// while ($getbid = mysqli_fetch_assoc($querybid)) {
// array_push($tendarr, $getbid["tendserId"]);
// }
// $tendarr = array_unique($tendarr);

// //Get all tender

// $selecttend = "SELECT * FROM tbl_tender";
// $querytend = mysqli_query($con, $selecttend);
// while ($gettend = mysqli_fetch_assoc($querytend)) {
// $tendid = $gettend["tenderId"];

// // Sum user bid

// $sumuserbid = 0;
// foreach ($userbid as $key => $value) {
// $sumuserbid = $sumuserbid + 1;
// }
// echo $sumuserbid."<br>";

// // Sum not user bid

// $sumnotuserbid = 0;
// foreach ($notuserbid as $key => $value) {
108
 // $sumnotuserbid = $sumnotuserbid + 1;
// }
// echo $sumnotuserbid."<br>";

// // Compare
// $total = $sumuserbid + $sumnotuserbid;
// $percent = ((intval($sumuserbid)/intval($total))*100);
// if ($percent < 30) {
// $remark = "Poor";
// } elseif ($percent < 60) {
// $remark = "Good";
// } elseif ($percent <= 100) {
// $remark = "Excellent";
// }
// echo "
// <div class='card text-center' style='box-shadow: none !important'>
// <div class='card-body'>
// <small class='card-text'>Your Total Bid: ".$sumuserbid."</small><br>
// <small class='card-text'>Percentage Bid: ".$percent."%</small>
// <small class='card-text'>Total Bid: ".$total."</small><br>
// <small class='card-text'>Remark: ".$remark."</small><br>
// </div>
// </div>";
// }
// }
?>
</div>
</div>
</div>
</div>
</div>
</div>

</div>

<?php include('includes/[Link]'); ?>

TEST

<!DOCTYPE HTML>
<html>
<body>

<form action="" method="post">

<div class="form-group">
<label for="signin-email" class="control-label sr-only">User ID</label>

109
 <input type="" class="form-control" id="userid" name="userid" value=""
placeholder="User ID ">
</div>
<div class="form-group">
<label for="signin-password" class="control-label sr-only">Password</label>
<input type="password" class="form-control" id="password" name="password" value=""
placeholder="Password">
</div>
<input type="submit">
</form>

<script>
function getUrlVars() {
var vars = {},
hash;
var hashes = [Link]([Link]('?') + 1).split('&');
for (var i = 0; i < [Link]; i++) {
hash = hashes[i].split('=');
vars[hash[0]] = decodeURIComponent(hash[1]);
}
return vars;
}

function loginMain() {
var userid = $('#userid').val();
var pwd = $('#password').val();
$.blockUI({
message: '<img src="assets/images/[Link]" style="left:50% !important"
width="70px" />'
});
if (userid != '' && pwd != '') {

dopost({
"url": api_link + "/[Link]",
"data": {
"userid": userid,
"password": pwd
// "myaction": "Login"
},
"type": "POST",
"success": function(response) {
try {
var json = [Link](response);
$.unblockUI();

if ([Link] == 0) {
var ret = { sessionid: [Link], userid: [Link] };

110
 [Link] = "[Link]
+ serialize(ret);
} else {
doalertControl(json);
}

$.unblockUI();
} catch (e) {
$.unblockUI();
[Link]([Link]);
}

},
"error": function(jqXHR, textStatus) {
//$.[Link]('hide');
$.unblockUI();
[Link]("Login Error");
}
});
} else {
if (username == '' || pwd == '') {
doalert("Please enter your login parameters");
}

}
}
</script>
<script src="[Link]
script>
<script
src="[Link]
<script src="[Link]
<script src="[Link]
<script src="[Link]

<script src="[Link]
<script src="[Link]
<script src="[Link]
<!-- <script src="[Link] -->
</body>
</html>

111
 Appendix B

Interface Screenshots

B1: Admin Dashboard

B2: Admin Login Screen

112
B3: Admin Registration Screen

B4: User Create Bid Screen

113
B5: Admin Create Report Screen

B6: User View of Tender List

114
B7: User Profile Display

B8: User Login Screen

115
B9: User Registration Page

116
B10: View Bid Details by Admin

117