Arab Open University- Lebanon

Faculty of Computer Studies

Information Technology and Computing

Department

Lebanese Dating Room (LDR)

John Elias Assy

SID: 007280

T471: Final Year Project, May 2010

Supervisor: Dr. Hassan Sbeity

Abstract

The following report contains details of the analysis, design and

development of the Lebanese Dating Room. It starts by the

introduction of the project topic, its purpose, objectives, scope and its

schedule, and then lists the literature search and the reference

evaluation. Next it shows the details of the analysis stage by listing the

function requirements from use cases and scenarios, then the

constraints, the data requirements and the software and hardware

requirements. The analysis stage is followed by the design stage which

includes the use cases diagram, the data flow diagram and the entity

relationship diagram in addition to the method used in the development

of the system, with detailed explanation, and the alternative methods,

with their justifications. It proceeds with the implementation stage that

shows how the analysis and design stages were transformed into

pieces of code, by explaining in details how each step was

implemented, in addition to screenshots and examples. The

implementation stage also includes the verification, validation and

testing steps. A summary of the project is posted at the end of this

report in addition to the bibliography.

Table of Contents

i- Chapter 1: Introduction & Overview.

ii- Chapter 2: Literature Search.

iii- Chapter 3: The Analysis Stage.

iv- Chapter 4: The Design Stage.

v- Chapter 5: Implementation & Testing.

vi- Chapter 6: Conclusion.

Chapter 1: Introduction & Overview.

1.1- Topic Introduction & background.

1.1.1- Project Title: Lebanese Dating Room (LDR).

1.1.2- Describing the Area of Study:

The Lebanese Dating Room is a web system that enables

Lebanese users from different areas, ages and genders to

search within the website for their matches, based on pre-

defined criteria, and at the same time, submitting their personal

information in order to be found and viewed by other users. The

system allows its users to connect, communicate and share

information about each others.

1.2- Topic Purpose.

1.2.1- The Purpose of the topic is to build a system based on a web

programming language in to develop personal skills in this domain.

1.3- Topic Objectives.

The aim of this Project is building a web program that allows registered

users to meet (or to date) each others. It enables the users to find their

matches based on specific criteria and to communicate in an organized

way.

1.4- Problem Definition.

Lebanon Lacks the presence of a pure Lebanese dating website,

although more than 15% of the population is using the internet. The

Lebanese seek a system that enables them to meet new people, from

specific areas in Lebanon and from different ages and genders,

instead of using worldwide social networks that randomly enables

people to communicate.

1.5- Problem Solution.

The solution of the problem is by building a website for a specific and

lonely target which is dating. Secondly, allowing users to search for

their matches by specifying what they are looking for, and their favorite

criteria, and last but not least by limiting the communication just

between a user and his match, instead of a random open

communication between all the available active users.

1.6- Target Costumers.

The audience of this website is represented by any Lebanese Internet

user, from different ages, genders and locations that is willing to

communicate with new Lebanese citizens online, and looking for

possible relationships. The website targets Lebanese users only, in

order to achieve a possible realistic relationship.

1.7- Topic Scope.

Only Lebanese users can subscribe to this website. A location field is

set with options specified as the different Lebanese regions, from north

to south.

The users must create an account in order to use the website. Guests

can view just a limited number of pages. A User can connect with an

unlimited number of other users in the website.

1.8- Schedule.

A Schedule has been set to cover the whole project duration and to

organize the work and deliver the system on time, as shown in Table-

1.

Start Date End Date Task

25/10/2009 15/11/2009 Topic Introduction and Overview (problem

definition, solution, scope, target customers…).

17/11/2009 30/11/2009 Literature Search.

2/12/2009 9/12/2009 Specifying use cases (functional requirements).

Writing scenarios.

10/12/2009 17/12/2009 Building use case model.

Specifying data requirements: addressing content and data dictionary

18/12/2009 24/12/2009 Building initial dataflow diagram.

Building initial Entity relationship diagram.

26/12/2009 31/12/2009 Reviewing Project Requirement Analysis.

Reviewing Project Design steps.

1/1/2010 10/1/2010 Creating database and tables. Building initial control panel (for administrator). Building user registration form.

11/1/2010 20/1/2010 Building user information and permission page (to manipulate user data). Building User login page.

21/1/2010 30/1/2010 Building User profile page. Building Private Messaging system. Building Abuse reporting system.

1/2/2010 15/2/2010 Building the matching engine.

16/2/2010 28/2/2010 Building “Reset Password” plugin.

3/3/2010 7/2/2010 Completing Project Draft of TMA03

8/3/2010 12/3/2010 Writing the “Introduction & Overview” of Project Report.(1st part) Completing the members profile page design.

13/3/2010 18/3/2010 Writing “Review & Evaluation of Literature” (2nd part). Completing relations page design.

19/3/2010 25/3/2010 Writing “The Analysis Stage” (3rd part). Completing the private messages pages design.

26/3/2010 2/4/2010 Writing “The Design Stage” (4th part). Completing the “Matching engine” pages design.

3/4/2010 9/4/2010 Writing the “Implementation & Testing Stage” (5th part). Completing the user info page design.

10/4/2010 16/4/2010 Writing the “Summary & Conclusion” (6th part) Completing the member report page design.

17/4/2010 23/4/2010 Completing the Bibliography part. Designing the admin control panel. Review of the work done on the project. Completing the project slideshow. Delivering Project Report.

24/4/2010 30/4/2010 Finalizing the Project Poster. Submitting TMA04.

Table-1 shows the project schedule.

Chapter 2: Review & Evaluation of Literature.

2.1- Proposed Literature Search. 2.1.1- Web Building- Reference.

The following document explains the steps needed for web building: http://www.w3schools.com/site/default.asp It starts by listing what a web developer needs, from HTML, to CSS, Javascript and a server scripting language such as ASP and PHP. Then it explains each one of the above. The next step is highlighting the importance of web design and how much it’s important to know what the website’s audience wants, in addition to some useful design advices. Then it focuses on the importance of building a website that is compatible with user’s software and hardware. On the other hand, the same website presents detailed tutorials of PHP, CSS and Javascript.

2.1.2- Reference Evaluation: That document is useful because it shows all the steps needed to focus on when building a website and it’s considered as a very helpful document due to the amount of information on the programming languages, and it will be my favorite document to help me out in the implementation process.

2.2- Review of References. 2.2.1- Document Evaluation:

Based on the document I have chosen earlier (http://www.w3schools.com/site/site_intro.asp), the PROMPT criteria can be resumed like this:

The presentation of the document is very well structured and the information is clearly communicated. The 1st page of the document is a table of contents that shows what the document explains. The design of the page is clear and not complicated, and the text is easy to be read, and the info is displayed in tables, where there’s a title in big font for each section. The document is written for beginners in web building, and it’s almost covering all the details, and linking to other documents for further information.

The document is relevant and explains easily what the user needs in order to build a web page. The introduction page is a portal containing links to other pages in the document and the important steps needed. Those steps are indeed important for anyone who wants to build a website, and should be followed in order to get a good result. The simplicity and richness of information make this document the right one for learning how to build the website.

The document is objective, and the author input in it is almost unavailable and stating educational information. The high ranking of this page on alexa.com (International Statistics Company) is one of the reasons to trust the content of the website (thousands of hundreds of users visit the website to get information).

Method: The document doesn’t state how the information was collected, but the correctness of the information was made clear, after testing the methods posted there.

At the bottom of the document, there’s a disclaimer stating the copyright of the company who released the document (Copyright 1999-2009 by Refsnes Data). The website is ranked 411 in the whole world.

The timeliness of the document is not clear, but the website seems up to date, because they are putting news from 2009-09-15: Google Chrome 3 released. As a conclusion, the information available is good enough to help out with the project, especially the ones related to the coding stage.

2.2.2- Effective Information Sources:

The most effective sources of information that I have used were my courses materials and the online search. I got most of the information from my courses material, especially the M301II (block4) and the CS490. The M301 course contains almost all the useful design information needed to accomplish the initial design step. The information are clear and organized, in addition to the fact that we already studied that course not a long time ago, so it’s easy to look for the information there. The CS490 course contains details related to the database part. I have no doubt that the same information is available online, but I had to put extra effort to search for them, and to find good sources of information. Nevertheless I have used the online search to find details that are not discussed in the courses material. The difficulty here is represented by the big amount of available information.

Chapter 3: Analysis Stage

3.1- Functional Requirements:

3.1.1- The Actors:

The Guest can see limited functions of the website, he

registers a new account to be able to use and see all the

content.

The User searches for members who match him according to

the criteria that he chose, and he’s able to use the functions

inside the website.

3.1.2- Use Cases:

Use case name: CreateAccount

Actor: Guest.

Pre-Condition: The actor must not be logged in to the

system.

Flow of Events:

- The Guest browses the registration form.

- The Guest fills it up with correct and required information, like the username, password, email, gender, location.

- The system validates the registration data and responds with success notification

- The system emails the user a registration notification. Post-Condition: The guest must activate his account in order to use it.

Use case name: ActivateAccount Actor: Guest. Pre-Condition: The actor must visit the activation link sent to hi e-mail address. Flow of Events: - The user visits the activation link - The system approves the account. - The system redirects the guest to the login page. Post-Condition: The user can login to his account and use it.

Use case name: RetrieveLostPassword Actors: Guest, User. Pre-Condition: The guest must be already registered in the website. Flow of Events: - The user clicks on “Forgot Password” link.

- The system prompts the user to enter his username. - The system checks the database for that user’s email

address. - The system sends an email to that address including a

hash and a link to change the password. - The User clicks on the link from the e-mail, and insert his

new password. Post-Condition: The user can login using his new password.

Use case name: MatchingMember Actor: User Pre-Condition: The User must be logged in to the system Flow of Events: - The User browses the “Search-For-Match” form. - The User fills it up with the criteria form. - The system shows the matching results. - The system shows a “RelationInvitation” button. Post-Condition: The user can choose another member to send a “Relation Invitation”.

Use case name: BuildingRelation Actor: User Pre-Condition: The User must be logged in to the system Flow of Events: - The user sends an Invitation request to another user. - The system sends an email to the 2nd user informing

about the Invitation. - The system sends a private message including

information about the sender and the matching percentage, with an “accept” or “decline” button.

- The system includes in the email information related to the sender and the percentage of matching, with a link to the receiver’s private message.

- The Receiver of Invitation may accept or decline the Invitation by clicking on “Accept” or “Decline” button.

- The system emails the sender about the acceptance or declination.

- The system updates the User’s Relations Page. Post-Condition: The user can invite another member, or break relation with a member he’s in relation with.

Use case name: BreakingRelation Actor: User

Pre-Condition: The user must be logged in, and in relation with 1 member at least. Flow of Events: - The user browses his “Relationships” page. - The user clicks the “Break Relation” button. - The System updates the “Relationships” page. - The system emails the 2nd user with the update.

Use case name: EditDetails Actor: User Pre-Condition: The user must be logged in Flow of Events: - The user browses his edit password/email/profile - The user enters the old email and old password - The user enters the new email and new password - The user confirms the new password - The user updates his profile information. - The user saves the changes. - The system saves the changes in the database.

Use case name: ReportAbuse Actors: User Pre-Condition: User must be logged in. Flow of Events: - A user presses the report button in the profile another

user in case of abusing the system (spam, unethical material…) and fills up the abuse form.

- The system notifies the administrator by sending a private message.

- The Administrator decides whether the action to take.

3.1.3- Scenarios:

Scenario Name: CreateAccount Actor: Guest Flow of Events:

- The Guest browses the registration form. - The Guest fills it up with correct and required information,

like the username, password, email, gender, location. - The system validates the registration data and returns a

registration completion notification. - The system redirects the user to login page after

completing the registration. - The system emails the user a registration notification

containing an activation link.

Scenario Name: ActivateAccount Actor: Administrator Flow of Events: - The user visits the activation link - The system approves the account. - The system redirects the guest to the login page.

Scenario Name: Login Actor: User Flow of Events: - The user browses the login form and enter his login

details (username/password)

- The system checks and validates the login data. - The system redirects the user to the tools page.

Scenario Name:RetrieveLostPassword Actor: User Flow of Events: - The user clicks on “Forgot Password” link. - The system prompts the user to enter his username. - The system checks the database for that user’s email

address. - The system sends an email to the user including a

security hash. - The system validates the hash and allows the user to put

a new password.

Scenario Name: MatchingMember Actor: User Flow of Events: - The User browses the “Search-For-Match” form. - The User fills it up with the criteria form. - The system shows the matching results. - The system shows a “RelationInvitation” button.

Scenario Name: RelationInvitation Actor: User Flow of Events: - The user sends an Invitation request to another user. - The system sends an email to the 2nd user informing

about the Invitation. - The system sends a private message including

information about the sender and the matching percentage, with an “accept” or “decline” button.

- The system includes in the email information related to the sender and the percentage of matching, with a link to the receiver’s private message.

Scenario Name: AcceptInvitation Actor: User Flow of Events: - The Receiver of Invitation Accepts the Invitation by

clicking on “Accept” button. - The system emails the sender about the acceptance. - The system updates the User’s Relations Page.

Scenario Name: DeclineInvitation Actor: User Flow of Events: - The user browses his private message inbox to check

the invitation. - The Receiver of Invitation Decline the invitation by

clicking on “Decline” button. - The system emails the sender about the declination.

Scenario Name: BreakingRelation Actor: User Flow of Events: - The user browses his “Relationships” page. - The user clicks the “Break Relation” button. - The System updates the “Relationships” page. - The system emails the 2nd user with the update.

Scenario Name: EditLogin Actor: User Flow of Events: - The user browses his edit password/email page - The user enters the old email and old password - The user enters the new email and new password - The user confirms the new password - The user saves the changes

Scenario Name: EditProfile Actor: User Flow of Events: - The user browses the profile page. - The user updates his profile information. - The user saves the changes.

Scenario: ReportAbuse

Actors: User Flow of Events: - A user presses the report button in the profile another

user in case of abusing the system (spam, unethical material…) and fill up the abuse form

- The system notifies the administrator by sending a private message.

- The Administrator decides whether the action to take.

3.2- Non Functional Requirements. 3.2.1- Constraints on the system:

- The User must have a valid e-mail account on registration.

- The user must be logged into the system in order to use the matching engine.

- Users must have an active relationship in order to use private messages.

3.3- Data Requirement.

Table Fields

User id, username, password, email, registration_date, ip_address, gender, location, age, Religion, occupation, height, weight ,usergroup, picture.

Usergroup id, group_name

Preferences id ,gender, age, location, religion, height, weight,

education, occupation

Reports id, abuser_id, reporter_id, reason, comment.

Private_Messages id, sender_id, receiver_id, date_sent, message.

Relationships Id, sender_id, receiver_id, status

Table-2 shows the database tables and fields.

3.4- Software Requirements:

3.4.1- Software List: - The following software programs are used in the design

and implementation stages: XAMPP.

Notepad++. AgroUML.

3.4.2- Description of used software: - XAMPP (Version 2.5): It’s a web server that consists of

an Apache HTTP Server and a MySQL Database in order to interpret scripts written in PHP, since the website will be written in PHP language. I’ll use xampp as a local server in to be able to open the pages that I write using the browser.

- Notepad++ (version 0.28): It’s a text and source code editor that supports syntax highlighting for most common languages. Notepad ++ is very useful, when writing a code I can choose what language I’m writing, so it highlight the code and makes it easy to be read, and to find syntax errors. (It doesn’t search for the error, it just that its highlighting makes it possible for a programmer to see the sequence of code in a clear way). So I’ll be using it instead if the normal notepad application or other text editor.

- AgroUML, will be used to draw diagrams and charts. - EdrawMax Will be used to draw Data Flow Diagram.

3.5- Tools, Hardware and software needed. The Following Tools are needed to run the system:

- Computer connected to the internet. - Web Browser (Chrome, Firefox...).

Chapter 4: The Design Stage

4.1- Use Case Diagram:

Figure-1 shows the Use Case Diagram.

4.2- The Data Flow Diagram of the system:

Figure-2 shows the Data Flow Diagram.

4.3- The Entity Relationship Diagram:

Figure-3 shows the Entity Relationships Diagram.

4.4- Methods Used in Developing the System.

4.4.1- The Waterfall Model:

In order to deliver the project on time and meet all the

requirements, I have applied some project management

techniques, based on a clear software development life cycle,

and most specifically, the waterfall model, that has the following

activities:

Figure-4 shows a representation of the waterfall model’s steps.

Requirement specifications:

It’s a description of the behavior system that will be

developed. It includes the use cases and scenarios

(also known as “Functional Requirements”) that

describe the interaction between the users and the

system.(1)

a- Eight use cases have been defined to describe the

dating Website system behavior. They cover all

the behaviors that are possible to take place

between the user and the system, and between

the users themselves. These use cases go like

this:

CreateAccount: Describes how the user will create

an account in order to join the website and access

its services. It starts by filling up the registration

page fields in a correct way, and ends by

submitting it to the system.

ActivateAccount: Describes how the system sends

a notification email to the newly registered users,

with a confirmation link in order to activate the

account, once it’s clicked. The system at this point

allows the user to access the website services.

RetrieveLostPassword: Describes what the user

will do in order to retrieve his password in case he

lost it. The user enters his username in an

appropriate form. The system sends an email

containing a link that will allow him to change his

password.

MatchingMember: Describes how the user will

choose criteria in order to look for members in the

website.

BuildingRelation: Allows a user to send a relation

request to another user in the website. The system

saves the relation in the database in case the

target user has accepted the relation.

BreakingRelation: Allows a user to break a

relation that was built with another user in the

website. The System updates the database once a

relation has been broken.

EditDetails: Allows the user to edit his registration

details, such as the email,password, age,

gender,… The system updates the database with

the new details.

ReportAbuse: In order to ban users from abusing

the website’s services in an unethical or

disrespecting behavior, the system allows the

users of the website to report other users, if they

find their behavior inappropriate. The system

generates abuse reports that are accessible by the

website’s administrator.

The use cases can be amended in a way that

preserves the right description of the system

behavior.

b- On the other hand, those use cases has been

developed into series of scenarios that describes in details what are the exact behaviors of the user and the system and how they will interact together in order to achieve the user cases aims.

c- The Non-Functional Requirements are also an

important part of the requirements specifications, since they describe the constraints of the system, and what behavior that system won’t be able to achieve. The Dating Website, for example, doesn’t allow guests to access user’s pages, and doesn’t allow those guests to search for their matches in

the system. It also restricts the possibility to contact a user by another user, for the users that has an active relation between each others.

d- The Data requirements are also present in the

Dating Website. Those simply describe how the system database and its tables are set. An important part of this system relies on an interaction with the database, in order to save and retrieve users’ information, and store their behavior (matching and connecting with other users). A users table has been set, that contains fields such as the username, password, email ... and other details that are important to allow the member to access the system, and to interact with other users. Another table was set in order to store the matching preferences of the user, which are the criteria that a certain user is looking for in the website. This allows more flexibility in the system, and gives the costumer/user a better and faster service. The private messages between users have also a table in database, in order to store their conversations together.

e- The Hardware and Software requirements define what tools the client/user needs in order to access this system. That certainly doesn’t require more than an internet connection with browser software.

The Design Stage: It’s the process of planning how to find the solution for the software that will be developed. Some concepts have been taken into consideration in order to show the fundamental functions that will be developed in the system. a- The Abstraction process: that is the process of

generalization and reducing the information in order to show the most relevant ones. This process is shown via the Data Flow Diagram that represents the interaction between the system and the external users in a simple way.

b- The Refinement stage is the process of elaborating how the interaction between the users and system will be achieved. That is shown via the Use Cases Diagram.

c- The Data Structure represents the logical relationships among data elements. It is shown via the Entity Relationship Diagram.

d- UML was used to process these 3 stages: Argo-UML to draw the use cases diagram and the Entity Relationship Diagram. EdrawMax: to draw the Data Flow Diagram. No Limitations has been faced at this stage.

The Implementation Stage: PHP Language has been adopted in this phase, due to its flexibility and its need in the Lebanese market. MySQL was used for the database. The work has started by implementing the use cases step by step, building each system, and linking it to the other pages. In addition to a back-end system that allows the webmaster to manipulate some data automatically.

The Validation & Verification Stage: The system has been tested and checked if its results are the same as the ones specified in the design stage. On the other hand, the system was validated as it satisfies the project objectives and scope. Each time a function was done, it was tested to make sure it works fine and gives the correct result. Then functions were tested together, same as the files of the software.

The maintenance Stage: It’s were the system could be a subject of errors after it has been delivered, and then fixed by the programmer.

4.4.2- The Spiral Model: There are possible alternative approaches to use in the Software development process, one of them is the Spiral Model that is a software development process combining elements of both design and prototyping-in-stages. Its steps are the following.

The system requirements are written in the most detailed way that starts from the topic choice justification, passing through defining the problem solution and setting the scope of the system. That Can be done by posting details about the choice of topic, and the reasons why the choice was made, with an external opinion from experts for example,

and people that are involved in this domain. It also shows why this solution was chosen, and what the other possible ones were. Is it better to build a dating room for Lebanese people only or to make it a worldwide network, or at least a regional one? In both cases, different steps were required in this stage, in order to know how the system will function exactly. Many other questions would be asked in the topic scope and the problem’s solution.

A preliminary design that discusses all the possible strategies and methods that can be used in designing the system. It also shows a comparison between these methods and phases. For example, different types of flowcharts and diagram can be presented, and drawn to conclude the best solution to solve the problem. A Use case diagram and a data flow diagram would have been drawn in this case, to show all the possibilities of solutions. If users were allowed to search for matches without being registered in the website or members of the website can’t build relationships if the number of active ones exceeds the limits. All that would lead to build new diagrams to explain how the system will run, according to the use cases and scenarios that might be added or modified.

Constructing a prototype of the system to represent how the system might look like, and to show some useful details that have an effect on the system processing. Building a small registration form that doesn’t include all the profile details, with the ability to save the registered username in the database, then a login form that allows the user to be logged in, in order to edit and modify his profile details. A small matching engine that searches in the database for members with limited number of criteria, and the ability to post a comment on their profile, would be developed in a larger system, since the basic options were built.

Evaluating the 1st prototype and finding the flaws and errors, and then creating a new clearer prototype that will be tested. Building such prototype enables editing the way the system functions, and allows the developer to focus on the most

important detail, whether it’s the registration page, or the matching engine, and sending messages to the members.

Advantages: Coping with the changes that are possible to be made on the system is easy. The Schedule & Budget of the project are estimated in a realistic way, because it’s easy to discover problems and issues.

Disadvantages: Expertise in risk evaluation and reduction is required. It’s applicable only to large systems.(2)

4.4.3- The Iterative Development

Another possible alternative approach to use in the Software development process is the Iterative development that starts with an initial planning and ends with deployment with the cyclic interaction in between. (3) It allows the developer to learn from the mistakes and use his experience from the earlier versions of the system.

The Identification of project scope is similar to the steps done in the waterfall model that assures the gathering of all the important information at a high level, which allows the estimation of work.

The risks are specified in the Elaboration stage. The possible flaws in the system can be determined here.

For example, how the user will be marked as logged in, and how it will be logged out from the system. If the user sends a private message to another user, then went to his sentbox and read it, would it be marked as read on receiver’s side too? When the user searches for match, how the system will select the matching possibilities? Is by selecting all the users from the database and overloading the server, or by adding the chosen criteria together in all the possible ways, which it overloads the system but gives more reliable results? Or simply by looking for the chosen criteria as they are submitted by the system, and not complicating it with additional load?

The Construction stage follows the earlier stage, and includes writing the code of software.

The code is chosen according to the elaboration stage, but nonetheless the functionality of the system is not determined

unless more than one possibility of coding the engine is presented. Building a matching engine that uses the criteria in all possible ways can be tricky, because at the beginning it looks like the most logical option. The number of code and the load put on the server’s side can help in choosing the 3rd option, which is building a simple system that looks for the matches the way the user submitted them.

At the end, the Transition stage links the developed part of code together. The private messages functionality can’t be verified and validated unless the inbox and the sentbox are built; in addition to the function that reads the private messages.

Advantages: There’s always a running version of the program, so if you run out of time, you can present a working version. It takes less time to correct error in earlier stages of development. Finding the bugs is much faster, and the identification of errors is possible easily.

Disadvantages: Knowing that the code implementation can start too early, it’s important to have a good idea how the program will look like, in order to prevent huge mistakes.

4.4.4- Agile Development Model

One more possible development model is the Agile Software Development model that uses people-centric viewpoint and feedback rather than planning. The feedback is driven by tests on software.(4)

The Agile method principles can be resumed as the following: A plan isn’t followed, but the response to a change in the requirement is applied. The priority goes for “working software” and for interaction between users. For example, it’s not important if guests can search for matches, or they must be logged in to do that. And sending private messages could be exclusive for members in relation, or simply open for all members to use it. Such plugins can be added later to restrict the use of the functions.

Advantages: It’s possible to change in the requirement at a late stage. High quality software is delivered at the end in the least time.

Disadvantages:

If the customer wasn’t clear in what he asks for, that could cause lot of troubles. Experienced and senior programmers are the only ones capable to hold such project and take decisions in early stages.

4.5- Skills needed to build a project.

Knowing how to transform a project idea into a clear

proposal: everything begins by step, if the project idea is

clear, then it’s easier to develop it.

Organizing and scheduling the steps: one of the most important steps to build a project and managing it, it starts by knowing what and when you have to do this or that step.

Design stage: The design of the project represents a clear development of the project idea, and sets how the project will function and what it needs in order to work.

Programming Language: The programming language is essential to develop a project; it can’t be replaced by templates built by other people. One should develop his programming skills in order to personalize and build the project the ways he wants.

Staying up to date with project management stages: Reading and staying in touch with the development skills is the key for the project manager to build a complete project without missing any step, and to clear all the stages needed.

Organizing and scheduling the project’s steps is necessary, without it, there’s no clear program for this project to be done. A schedule should be set at the beginning of the project, and by highlighting all the needed steps. This can be gained by experience.

Being strong in the design stage is very important. Drawing diagrams and charts is helpful in building the project. Those diagrams are an important key to organize the project, and to know how this project works.

Developing the programming skills starts by mastering a programming language, then testing and prototyping. Building small examples using that language is the best way to be strong in programming. It’s also important to know what environment should be used.

4.6- Method Justifications.

The process of developing this software has started few months ago,

when the headlines and important stages were drawn in the TMA01.

The problem definition, its solution, the objectives and goals and the

scope of the system were all set at the beginning. That process

outlined the future step that will be done to develop the software. But

the work wouldn’t have been achieved without a clear schedule that

defined what the future steps that will be done are. The clear timeline

and time limits that have been assigned was the basis of the work.

That produced flexibility in the process and allowed the transition from

the analysis phase, to the design stage were numerous decision were

taken to complete this stage successfully at an early period. The tutor

feedback on the design stage was an important key for the success in

presenting a well structured software design. It has put the work on the

right track, same as all the feedback and notes given in tutorials and

TMAs. The strict schedule and the consideration of Tutor’s feedback

allowed the transition to another important stage, which is the

implementation one. The aim of the project is developing students’

skills and introducing them to new work techniques, by profiting from

the courses and tutorials studied at the AOU, Therefore the choice of

the programming language was important, and the ability to master it

was needed. During the work on the analysis and design stages, and

as a response to the tutor’s notes, the training on the programming

language (PHP) has started just few days after the choice if project

topic has been made. The work was running in parallel, and that need

a concentration on the goals of learning the language, and the topic

requirement. At this stage, another schedule has been developed to

specify how much time each use case and scenario needs to be

implemented. Each step was given enough number of hours to be

completed. The mixture between the design stage and the training on

the programming language, gave a good result, and a fine preparation

in order to start the implementation stage right after the end of design

stage, without the need to wait few additional weeks to start the

implementation. At the implementation stage, many troubles have

occurred, but with the help of the PHP tutorial, and the online search,

such troubles were overpassed, and certainly with a continuous

practice and testing of small chunks of code and functions that was

included in the system.

Chapter 5: Implementation & Testing

5.1- Implementation Phase 5.1.1- The Registration:

The implementation stage is the transformation of the design stage into pieces of codes. This stage starts by coding the “CreateAccount” use case, also known as the user registration. A form has been created in order to be filled up with user’s information upon registration. It contains all the fields that the user should fill in order to have an account in the LDR, as shown in Figure 5.

Figure 5- LDR registration form.

The visitor of the website should choose a username that allows him to login later on to the members’ area of the website, along with a password. The system requests that the user confirms his password in another field, and then enters a valid e-mail address, that will be used by the system to complete the registration process by sending a confirmation e-mail to that address. Later on the guest has to fill up his gender, location, occupation, religion, education, height, weight and age.

Note that the requested fields (gender, location, occupation, religion, education, height, weight and age) represent a list of pre-defined values that the user has to choose from them. These values are integers, in the form, but presented as text values (like the age “17-20” has the integer value “1” in the form, and so on). After filling them all, the guest has to click on “Create Account”, as shown in figure 5. When submitting the registration information, the system checks in the background all the fields if they are correct or wrong. One or more of the following errors could occur: - Username is too short(less than 3 characters), or too

long (more than 12 characters), or already exists in the database.

- Password is too short(less than 5 characters), or too long (more than 12 characters), or doesn’t match with the password confirmation.

- The email address is short(less than 10 characters), or long (more than 25 characters), invalid or already exists in the database.

- The user has not selected a valid age, gender, religion, location, occupation, education, height and weight.

Figure 6- the system displaying a registration error.

Figure 7 shows the PHP function that checks if the requested username is available: The system searches the database for that username, by running a query that selects

the corresponding username from the users table. If it exists (the query counts the number of rows using the PHP function “mysql_num_rows”, if it was 0, the username does not exists), the system displays an error (as shown in Figure-6), and otherwise it allows the user to have that username.

Figure 7- PHP function to check the username’s availability.

Note that a username is set as a “unique” field in the database, in order to prevent multiple registrations with the same username. Another PHP function is built to check if the requested e-mail address is available, by running a query that selects the corresponding email address from the users table. An e-mail address can be used only one time and assigned to one username. If the e-mail address already exists (the query counts the number of rows using the PHP function “mysql_num_rows”, if it was 0, the email does not exists), the system displays an error (as shown in Figure-6), otherwise it allows the user to have that e-mail address. Figure 8 shows the code that checks the submitted fields. If the values of gender, location, occupation, religion, education, height, weight and age are not selected as displayed in the values list (the value that the server gets from the form should be one of the integers given to the form’s fields values, and greater than zero), the system displays the errors shown in Figure-6.

Figure 8- Submitted fields’ checker.

After checking all the submitted fields, if the system finds out that there were no errors in the registration, it saves the submitted info in the database, after encrypting the password, using md5 encryption technique. MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function with a 128-bit hash value. Specified in RFC 1321, MD5 has been employed in a wide variety of security applications, and is also commonly used to check the integrity of files. (5)

Figure 9- shows the MYSQL code that stores the information in the

database.

In order to store those values in the database, mysql database scripting language is used. A database has been created specifically for the LDR. A table called “users” has also been created, in order to save the user’s information in it. The system also logs the registration date and the user’s IP address, and sets the user’s usergroup to 0. A table (usergroups) is set in order to give access to users according to each usergroup. An unconfirmed user would be placed in usergroup “0”, while a confirmed user would be placed in usergroup “1”.

The system assigns the new user a profile picture, and sets a default profile picture. This picture’s name is saved in the database, and specifically in the users table. The system saves the user’s information values as integers in the database.

Figure 10 - The users table fields in the database.

At this moment, the system creates a row in the table of the user’s preferences, and fills it up with “0” values. The user’s preferences are the options specified by every user to help the system searching for that user’s preferred options in the other users. This part will be discussed later in this section. Another table (preferences) has been created in the database in order to store that information. Once the information has been stored in the database, the system sends an e-mail to the user informing him that the registration needs confirmation. In order to prevent eavesdroppers from hijacking the confirmation e-mail, a hash is sent that will allow the system to check if registered user in the one who’s confirming the registration.

Figure 11- PHP function that sets the hash.

A hash is a value created by concatenating the email address value with a key set by the system, then encrypting them using the MD5 technique (defined earlier). This has can’t be hacked or know by an eavesdropper, but the system can compare it to other hashes. Once the e-mail is sent, the system shows a registration success message, and asks the user to check his inbox in order to confirm his registration. When the user checks the confirmation email, he will find a link to the website, that once it’s clicked, the system matches the hash sent within the link, with the one set by the system. The system gets the email address and the hash from the clicked link, and then it builds a new hash using the email address, and the key set earlier by the system. Once it’s done, the system compares the new hash, with the one retrieved from the clicked link. If the hashes are identical, the system approves the registered user, and set the usergroup of user to “Registered User”. Once the confirmation is completed, the system shows the user a confirmation success message; otherwise it shows a failure message. The registration functions are all based in the file register.php.

5.1.2- Logging In

In order for the user to browse the members’ area, he must login using his approved username and password that he has set during the registration. The system shows the user a login form that contains a username and password fields. Once the user clicks the “login” button, the system validates if the login information is correct (whether the submitted username and passwords are not empty or not to long).

Figure 12 - PHP code that validates the login fields.

If the system didn’t detect any errors in the login details, it checks in the database if the entered password is assigned to the provided username.

Figure 13 - PHP code that matches the username and password.

If the username and password are correct, the system logs the user into the members are by accomplishing the following steps.

- The system uses PHP sessions and generates a new session upon log in.

- The system sets a session code for the user. - The system saves the user’s id and username in the

session array. - The system displays a correct login message, and

redirects the user to the members’ area. (The importance of the sessions that each session id is different than the other, and they are saved on the server’s side, so that no one will be able to modify them, getting information about the user, of create a session with the same id)

If the system detects error in the login details, or the username and passwords don’t match, it shows an error message and returns the user to the login form.

Figure 14- shows the possible error messages after failing to login.

5.1.3- Logging out:

The system allows the user to logout of the members’ area by destroying the session that was created on login.

5.1.4- Retrieving lost password:

If the member has lost his password, the system allows him to retrieve it. It displays a password reset form, which enables the member to enter his username in order to reset his password. Once the user enters his username, the system checks if the entered username is correct, and exists in the database.

Figure 15 - PHP code that verifies the entered username.

If there are no errors, the system will send the user a password resetting e-mail. The system will use the email assigned to the username. The e-mail contains a link to reset the password, and a hash to protect the system from hacking and ensure the id of the user. Setting the hash is similar to the process done in the registration confirmation step.

Figure 16- PHP function that sends the password reset e-mail.

When the user clicks on the links that he received to his email, the system checks the email address and the hash in that link:

- The system checks if the email is available in the database, and if that was the case, it select the old password of the user.

- The system then sets a hash using that password, and compares it to the hash already set.

- If they are identical, the system shows the user a form to set his new password.

- In the new password form, the user has to enter his new password, and then confirms it. Once the user submits his new password, the system validates the data then saves the new password in the database. Otherwise it displays an error message.

- In case the email or the hash are not correct, the system shows the user an error message and doesn’t allow him to change the password until he requests a new one again.

The Login, Logout and password reset functions are set in the login.php file.

5.1.5- Editing Profile.

In order for a member to access his profile page, he must be logged in using his username & password. As mentioned before, when logging in, the system creates a session and assigns a session code. So the system checks if the member is logged in by comparing the newly created session code, by another key set within the system.

Figure 17- PHP function that checks if the member is logged in.

Once logged in, the member can browse his profile by visiting the page “profile.php”. The system directly displays the

member’s information, such as age, gender, education… in addition to the member’s profile picture. The system selects from the database the profile information of the logged in user (by getting the user’s id from the session array, since the id was saved on login). The retrieved information is in the form of integers, for that, each one is transformed into a text value by using the PHP function “str_replace”. The profile fields are now displayed as string values in the drop down lists of the form, but still have the integer values within the form. In the same page, the member can choose to edit his profile information, by choosing new values from the lists related to each profile field.

Figure 18- Profile Page.

Once the member clicks on “Save Changes”, the system checks the submitted data if they are correct. If an error occurs, the system displays an error message and redirects the user to the same page; otherwise the system displays a success message. On the other hand, the system allows the member to change his e-mail and password. For that the system displays a form to change them. The user can change his e-mail address while changing the password, or can choose to keep the old one. The system also asks the user for his old password, in order to prevent hacking the member’s account. In addition, the user has to fill the new password field, and another field to confirm the new password.

When the user clicks on “Save Changes”, the system checks the submitted data: - It checks if the entered e-mail address is not already

used by another member. (the user can keep his old email address)

- It checks if the old password is the user’s correct password (by selecting it from the database and checking if it’s available and belongs to the selected user).

- It checks if the new password fields are identical. - It checks if the lengths of email and passwords fields are

correct.

Figure 19- filters that check the email and passwords before saving them.

Once the system ensures that there were no errors, it encrypts the new password and saves it to the database.

Profile Picture: The system also allows the user to change his profile picture. When the user browses a new profile picture from his local directory and submits it, the system checks if the uploaded file fits with specific criteria (size, height, width, name…).

Figure 20- PHP code that validates the uploaded picture.

If the picture upload doesn’t contain any error, the system deletes the old picture and saves the new picture in the database and displays it in the member’s profile page. If an error occurs, the system displays an error message. Member’s page: The member’s public page is where the member’s information is displayed to LDR’s registered and logged in users.

The system gets the user’s id from the URL, and search the database for this id, the username and its related public information, then it transforms the integer values into strings. The system also displays a button to connect with the selected user, in addition to a button to report that user to the administration of the website. On the other hand, if 2 members are connected together (the system looks in the relationships table for the logged in user id, and the id of the user from the URL), the system shows a button in order to send a message to the selected user.

5.1.6- Reporting a User:

If a user is abusing the website’s terms of use, the system allows the user to fill up a form to report that user. (Figure 21)

Figure 21- User Reporting Form.

The user selects a reason of reporting the member from a pre-defined list, and post additional notes. Once the report is submitted, the system validates the submitted data, by checking if the selected reason and the length of note are correct. If no errors have occurred, the system saves them in the database, specifically in a table called (reports).

The system saves the member who sent the report, and the member that was reported, in addition to the date and time, the reason of report, and the additional notes. A success message is shown at the end. That information can be retrieved by the administration form the back-end in order to decide what to do. If one or more errors occur, the system displays an error message. Note that the member has to be logged in, in order to be able to report another member.

5.1.7- Private Messages.

The system provides the users the ability to contact each others, only in case they have an active relationship between each others.

The member can insert the recipient’s name, with a message title and message body. On submit, the system first checks if the sender and the receiver are connected. This is done by checking the database where the relationships between users are stored. If the system founds out that there’s an active relationship between those users, it allows the sender to send a private message.

Figure 22- PHP function that checks if the users are in relation.

Now if the users are already connected, the system starts checking and validating the submitted data from the form. It starts by checking if the username of the receiver exists, and if the message title and body lengths are correct.

Figure 23 -Filter that validates the data.

If there were no errors, the system sends the message to the receiver, and that is done by saving it in the database in the private messages table. On a side note, when the sender clicks on the “send message” link available in the receiver’s profile page, the system gets the receiver id from the URL, and gets the username related to that id.

Figure 24 Function that converts the user id into username.

If one or more errors occur while sending a private message, the system displays an error message. Inbox: When a member receives a private message from another user, it is stored in his inbox. The system selects from the database all the private messages related to the logged in user (as receiver). In the private messages table, there’s a field that defines whether the message is read or unread. If the message is unread, it’s displayed in bold fonts, while it’s displayed in normal fonts if it’s read. By clicking on a message, the member can read the body of that message.

Sentbox: The concept of sentbox is similar to the inbox, but it’s the place where the messages sent by a user are stored. Reading Messages: When the user clicks on a message in his inbox, the system redirects him to a new page where it displays the selected private message. The message is displayed by selecting the id of the message from the URL. The system checks if this message is related to the reader (receiver), by checking the private messages table and comparing the receiver’s id with the logged in user id. If the message and the reader are related, the system shows the message and allows the user to send a reply to the sender by clicking on “send reply”. When the message is viewed, the system updates the database by setting the status field of the private message into “read”.

Figure 25- MYSQL command that updates the message status.

Note that the user must be logged in, in order to access and use the private messages system.

5.1.8- Matching engine In order to search for the members in the LDR, a matching engine has been built, starting with a form that contains the fields the members can look for. The fields have been divided into 2 parts:

- Required fields: those fields are the ones required to be filled up in order to complete a search. The age, gender, education and occupation fields are mandatory.

- Additional fields: those fields are not required for the search, but the user can use them in order to refine the search and get more specific results.

The height, weight, location and religion are additional fields.

Figure 26- Matching engine form.

In the form, the values of the fields are set as integers, because when the members register their accounts, the info is saved as integers in the database. The user must be logged in, before using the matching engine. After selecting search criteria and submitting them, the system verifies the submitted data. It also checks if the required fields are submitted. If the system finds out that there were no errors, it sends a query to the database, to select the users that have the age, gender, occupation and education values selected by the member. The system compares the integers submitted by the user, with the ones of the other members saved in the database. On the other hand, the system checks if the user has submitted additional fields, and in case he did, it adds those fields to the query.

Figure 27- Matching engine’s MYSQL queries.

If there was no results that match the search, the system display a corresponding message. If the system locates members, it displays their profile pictures, usernames, a link to their profile and a link to build a relationship. If one or more errors occur while searching for matches, the system displays an error message.

5.1.9- Managing Relationships. Relation Invitation: The system allows the members to invite each others to start a relation. The invitation is sent from one user to another by creating a new row in the relationships table in the database. In the same table, the status field of the relationship defines whether the relation is active, broken or declined. The system also checks if the members are already connected, and in this case it shows an error message, otherwise it inserts the new relationship in the database and shows a success message.

Figure 28- MYSQL query that saves the relationships.

At the same time, the system sends an e-mail to the receiver of the invitation, informing him that a member has sent him an invitation. This invitation will be listed in his relationship page. If the receiver decides to decline the relationship, the system updates the relationship status in the database (by running a query) and sets to “declined”. A confirmation message is displayed to the user, and his relationship page is updated. If the receiver accepts the relationship, the system runs a query and updates the relationship status into active. The system sends an email to the sender informing him that the relationship has been accepted. The system displays a message to the receiver that he accepted the relationship, and both members’ relationships pages are updated. Both users now can send messages to each others A user can break up a relationship with another user, the system then updates the relationship status in the database to broken. The members’ relationships pages are updated, and the system doesn’t allow them to send message to each other’s anymore. Listing Relationships: The system selects from the relationships table in the database the logged in member’s active and pending relationships and displays them with links to break up active relations and to accept or decline active relations.

5.1.10- Building pages.

In every page of the website, the header and footer are included in the page using the PHP include function. The Header contains the title of the page, the logo and the slogan, in addition to a login form if the user is not logged in, or a welcome message for the logged in users. The header also links to the CSS file. The footer contains some static links related to the page overview.

The index page: The index page contains a matching form, and random pictures of the registered members. The Design: The website was designed using CSS. A CSS file has been dedicated to contain the code of the design. It’s linked from the header page.

Figure 29- Some chunks of CSS code.

5.2- Verification: The verification was used at each stage of the life cycle to ensure that the requirements were implemented correctly. The process of verification starts with the registration page, and it was checked against the registration use case, scenario and constraints. The same process was repeated each time a new part of the system is being implemented. And knowing that each page consists of many functions, each time a function was built; it was verified against the steps of the use case. After the end of the function that checks if the registration data are correct, another function was introduced, that sends email to the registered user, then another function to approve the registered accounts. Each time those

functions inside the registration page were verified against the requirements of the system.

5.3- Validation: The validation is the process of checking that the system description is consistent with the system requirements. For example, the matching engine was validated against the initial requirements and use cases, same as the profile and details editing.

5.4- Testing:

Testing is the process of executing a software system to check that

it meets its requirements.

There are four distinct types of testing:

Usability testing.

Developmental testing: Checks correctness of

developmental activities.

Requirements-based testing: Checks that a system meets

the customer’s requirements.

Regression testing: Occurs during developmental testing

and system maintenance.

5.4.1- Usability Testing:

The users are able to access the system just by browsing

the address of the website easily.

It’s easy for them to use the features of the website. For

example, the matching engine form is displayed in the

homepage, and easily seen by the users, same as the login

form.

Those users just need to have access to the internet, which

is common.

5.4.2- Developmental testing:

Developmental testing consists largely of three stages:

- Unit testing: Units of functionality are tested in isolation.

The registration page was tested alone, same as the

login. The relation building and the relation breaking are

testing alone too, as different units.

- Integration testing: Previously unit-tested units are tested

together.

A relation was build between 2 members, then it was

checked if it’s displayed for both users, then broken. The

system should here change the relation status and

update the member’s relationships page, and that was

the result after the testing.

- System testing: The completed system is tested against

the customer’s requirements.

After finishing the whole system, a registration of a

member is done, confirmed by visiting the link in the

email, then logged in using that username and password.

The matching engine is used to search for matches, and

once a match was found, a relation was built with him,

and then a private message was sent after the approval

of relationship. The private message was then read, and

the user broke the relationship. The member’s details

were edited, same as the password and email address.

The reporting system was posted too. The whole system

works fine and it met all the requirements.

5.4.3- Requirements-based testing:

The system’s functions were tested against the

requirements, one by one. For example, the requirements

states that once the registration is complete, the system

sends an email to the user. That feature was tested and

found correct, same as all the other requirements.

5.4.4- Regression testing: The regression testing is part of system testing which consist of the following generic tests: - User-command testing: All the input fields in the website

(login form, registration, private message, report) were

tested, and working fine. If an error in one of them occurs

(if they were empty, or inputs were too long), the system

notifies the user about the error.

- Interface and protocol testing: All the features of the

system are linked together. For example if a user checks

another user’s profile page, he can see a relation button,

or button to send a private message. If the user is logged

in, he can see the logout button, and if he’s not

registered/logged in, he can see a login form, and a link

to the registration page.

- Start-up and initialization testing: The system just needs

an internet connection and any browser to work.

- Security testing: The database is secured using a general

password, and all the input fields are cleaned by the

system whenever a user uses them. For example if

someone submits a MySQL query in the username and

password fields, the system cleans them before they are

connected to the database.

Chapter 6: Conclusion

6.1- Summary: The Lebanese Dating Room is ready to be launched online and used by users. The system works fine as planned in the analysis and design, and the design of the website allows users to use it easily, since it links all the features together and shows them in a smooth friendly way. The system is easy to use, starting from the registration to the username verification to the login, passing by the matching engine, the profile editing, and the abuse reporting. After taking an overview on the whole system, I can ensure that it’s a good project that can be developed more in the future, although some steps could have been modified, and some of the functions could have been more flexible. Many other features could have been added to the system, and more functions would have been good as additional plug-ins. That requires more time, and changes in the project management, and in the planning of the whole system. And knowing that developing a website is a non-ending process, the current system can be considered a base for a more larger project with more sophisticated features, in addition to some other changes in the design, and in the PHP coding and style. Such steps will be the subject of my research and concentration.

6.2- Future work perspectives:

The future steps will be represented by an overall enhancement of the website’s design, by adding graphics

and colors, in addition to some changes in the current pages designs. On the other hand, I’ll use Javascript in the pages, especially the login and registration form, in addition to the matching engine’s form, for that if the users entered false inputs in the fields, the system directly prompts them the errors that occurred. That will definitely help in enhancing the system. On the other hand, I’m planning to include AJAX in the registration form, to make it easy and fast for the users to register. For that some changes in the system and the PHP code will be made, to reduce the quantity of information needed on registration. Another idea that I’m planning to implement in the near future, is building a chatting system and including it in the website, so it will be used in the communication between members, instead of the private messages. The above steps will surely allow me to lunch this website on the net, so real members can register and use the system. This is another way to know the system’s flaws, and if any changes should be made.

Bibliography (1) Waterfall Model, in Wikipedia, retrieved from

http://en.wikipedia.org/wiki/Waterfall_model (2) Spiral Model, in Wikipedia, retrieved from

http://en.wikipedia.org/wiki/Spiral_model (3) Iterative Development, in Wikipedia, retrieved from

http://en.wikipedia.org/wiki/Iterative_development (4) Agile Software Development, in Wikipedia, retrieved from

http://en.wikipedia.org/wiki/Agile_software_development

(5) Message-Digest algorithm 5 in Wikipedia ,retrieved from http://en.wikipedia.org/wiki/MD5