Final Year Project Title - shiningstudy.com€¦ · SE- UOG - Project Coordination Office Version:...

SE- UOG - Project Coordination Office Version: 1.0

Final Project Deliverable Guide Date: September 25, 2017

© Department of Software Engineeering.

1

Department of Software Engineering

University of Gujrat

Final Year Project Title

Rent a House Website

Submitted By:

Fazeela Younas Awan

Sonia Mukhtar

14071598-032

14071598-010

Supervised By:

Mr. Muhammad Manzoor Hussian




2

TABLE OF CONTENTS

SECOND DELIVERABLE FOR OBJECT ORIENTED APPROACH ..................... 4

CHAPTER 2: SYSTEM REQUIREMENT SPECIFICATION ................................... 4

2.1 INTRODUCTION: ......................................................................................................... 5 2.1.1 Systems Specifications ....................................................................................... 5 2.1.2. Identifying External Entities ............................................................................. 5 2.1.3. Context Level Data Flow Diagram: ................................................................. 6

2.1.4. Capture "shall" Statements: .............................................................................. 7 2.1.5. Allocate Requirements: ..................................................................................... 7 2.1.6. Prioritize Requirements: ................................................................................... 8 2.1.7. Requirements Trace-ability Matrix: ................................................................. 9

2.2. EXAMPLE: ......................................................... ERROR! BOOKMARK NOT DEFINED. 2.2.1. Introduction........................................................ Error! Bookmark not defined. 2.2.2. Existing System .................................................. Error! Bookmark not defined.

2.2.3. Scope of the System ............................................ Error! Bookmark not defined. 2.2.4. Summary of Requirements:(Initial Requirements)........... Error! Bookmark not

defined. 2.2.5. Identifying External Entities: ............................. Error! Bookmark not defined. 2.2.6. Capture "shall" Statements: ............................... Error! Bookmark not defined.

2.2.7. Allocate Requirements: ...................................... Error! Bookmark not defined. 2.2.8. Priorities Requirements: .................................... Error! Bookmark not defined.

2.2.9. Requirements Traceability Matrix: .................... Error! Bookmark not defined. 2.2.10. High Level Usecase Diagram: ........................................................................ 9

2.2.11. Analysis Level Usecase Diagram: ................................................................ 10 2.2.12. Usecase Description ..................................................................................... 11

CHAPTER 3: DESIGN DOCUMENT.......................................................................... 12

3.1. INTRODUCTION: ...................................................................................................... 13 3.2. DOMAIN MODEL ..................................................................................................... 14

3.3. SYSTEM SEQUENCE DIAGRAM ................................................................................ 14 3.4. SEQUENCE DIAGRAM .............................................................................................. 15

3.4.1. Defining a Sequence diagram ............................ Error! Bookmark not defined.

3.4.2. Basic Sequence Diagram Symbols and Notations ........... Error! Bookmark not

defined. 3.4.3. Example.............................................................. Error! Bookmark not defined.

3.4.4. Distributing Control Flow in Sequence Diagrams .......... Error! Bookmark not

defined. 3.5. COLLABORATION DIAGRAM .............................. ERROR! BOOKMARK NOT DEFINED.

3.5.1. Contents of Collaboration Diagrams ................ Error! Bookmark not defined.

3.5.2. Constructs of Collaboration Diagram: .............. Error! Bookmark not defined. 3.6. OPERATION CONTRACTS ................................... ERROR! BOOKMARK NOT DEFINED. 3.7. DESIGN CLASS DIAGRAM ........................................................................................ 17

3.7.1. Create Initial Design Classes ......................................................................... 17 3.7.2. Designing Boundary Classes .......................................................................... 17




3

3.7.3. Designing Entity Classes ................................................................................ 17 3.7.4. Designing Control Classes ............................................................................. 18

3.7.5. Identify Persistent Classes .............................................................................. 18 3.7.6. Define Class Visibility..................................................................................... 19 2.7.7. Design Class Relationships............................................................................. 19

3.8. STATE CHART DIAGRAM .......................................................................................... 19 3.9. DATA MODEL.......................................................................................................... 20




4

Second Deliverable For Object Oriented Approach

Chapter 2: System Requirement Specification




5

2.1 Introduction:

2.1.1 Systems Specifications

The following are the clauses that must be included while describing the system

specifications.

Introduction

This project help the users to make good decision regarding rent a house. This online

system help the user to search a house for rent. This website save the user’s searching

time. Due to this website user now does not have to search so much and can find the

house for rent easily. This website includes house details like Address, Rooms

information, Owner’s name and its contact number plus its email id. Also help to

maintain good relationship between tenant and owner of house. And one thing which is

very important in this project which is about tenant get 3D view of house which is the

concept of virtual reality and it would safe a lot of time of the tenant.

Existing System

Currently the most property managers manage property and tenants details on papers.

Once customers finds a vacant house, they can call or email manager of the houses

indicating the size of the house they would like rented to them.. The property manager

can email them back giving them all the details about the house they are requesting.

Hence, there is need of reformation of the system with more advantages and flexibility.

The system eliminates most of the limitations of the existing system. The details include;

3D view of the house. He/ She agree to buy or taking house on rent.

Terms and conditions to follow acceptance.

Organizational Chart

Organizational chart will be very much supportive to get a better overview of the

organization’s business areas and their decomposition into different departments.

Scope of the System

The Rent a House website is divided in to two phases.

Phase I

Phase I includes following business areas:

• User can maintain his account.

• User can find house according to his need.

• Complete detail about houses is given.

Phase II

• Owner can update information at any time about houses.

• Rent a House website provides 3D view of houses RMMIS

Summary of Requirements: (Initial Requirements)

The purposed system must fulfill following requirements as follow:

1) A user should register his/her self. The site will verify the user. A customer will buy

sell and take house on rent.

2) Landlord will register his/her self also. A customer will login to the system and can

change his/her password. Landlord shall provide the houses on different locations.

3) Site will update the customer’s Request. Site will process of updating e.g. Addition of




6

new houses. A customer will get the verification notification

4) Site will provide the profile of the landlord. Site can search any customer details.

Admin can delete the previous records. Site will provide the contact detail of landlord.

2.1.2. Identifying External Entities.

The Identification of External Entities is done in two phases.

a. Over Specify Entities from Abstract:

On the basis of the Abstract, one might identify the following entities from the Rent a

House Website.

• Customer

• House

• Admin

• Location

• Landlord

• Login Account

b. Perform Refinement:

• Customer

• Landlord

• House

2.1.3. Context Level Data Flow Diagram:




7

2.1.4. Capture "shall" Statements:

Para

#

Initial Requirements

1.0 A user “shall “register his/her self

1.0 The site “shall” verify the user.

1.0 A customer “shall” buy sell and take house on rent.

2.0 Landlord “shall” register his/her self also.

2.0 A customer “shall” login to the system and can change his/her password

2.0 Landlord shall provide the houses on different locations

3.0 System “shall” update the customer’s Request.

3.0 System “shall” process of updating e.g. Addition of new houses.

3.0 A customer “shall” get the verification notification.

4.0 Site “shall” provide the profile of the landlord

4.0 Site “shall” search any customer details

4.0 User shall search house according to his/her desire.

4.0 Admin shall delete the previous records.

4.0 System “shall” provide the contact detail of landlord.

Para # Initial Requirements Use Case Name

1.0 A customer “shall” register him/herself UC_User_Registration_Request

1.0 Site shall verify the user UC__Process _User_Request

1.0 The site “shall” provide three categories

(buy,sell and rent)

UC_Select_Category

2.0 Landlord “shall” register his/her self also. UC_Landlord_Registration_Req

uest

2.0 A customer “shall” login to the system. UC_Login

2.0 Landlord shall provide the houses on

different locations

UC_Provide_ Houses

3.0 Site “shall” update the customer’s Request UC_Update_Request




8

3.0 User shall receive the verification

notification.

UC_Notification_Status

4.0 Site “shall” provide the profile of the

landlord

UC_View_Profile

4.0 Site “shall” search any customer details UC_Search_Customer

4.0 User shall search house according to his/her

desire.

UC_Customer_Request

4.0 Admin shall delete the previous records. UC_Deletion

4.0 Site “shall” provide the contact detail of

landlord.

UC_Provide_Contact_Details

2.1.6. Prioritize Requirements:

Para

#

Rank Initial

Requirements

Use

Case

ID

Use Case Name

2.0 Highest Landlord

shall

provide the

houses on

different

locations.

UC_1 UC_Provide_ Houses

4.0 Highest Site “shall”

provide the

contact detail of

landlord.

UC_2

UC_Provide_ Houses

1.0 Highest A customer

“shall” register

him/herself

UC_3 UC_

User_Registration_Request

2.0 Highest A customer

“shall” login to

the system.

UC_4 UC_Login




9

1.0 Highest The site

“shall” verify

the user.

UC_5 UC_Process_User_Request

2.0 Highest Landlord “shall”

register his/her

self also.

UC_6

UC_Landlord_Registration_Re

quest

4.0 Medium Site “shall”

provide the profile

of the landlord

UC_7

s

UC_View_Profile

3.0 Medium User shall receive

the verification

notification.

UC_8 UC_Notification_Status

4.0 Medium User shall search

house according

to his/her desire.

UC_9 UC_Customer_Request

3.0 Medium Site “shall”

update the

customer’s

Request.

UC_1

0

UC_ Update_Request

4.0 Lowest Admin shall

delete the

previous records.

UC_1

1

UC_Deletion

4.0 Lowest Site “shall” search

any customer

details

UC_1

2

UC_Search_Customer

1.0 Lowest The site “shall”

provide three

categories (buy,

sell and rent)

UC_1

3

UC_Select_Category

2.2.12 High Level Use Case Diagram The use case of rent a house website is a model in which the actors are landlord, admin or

a user who wants to get any kind of help about the houses from this website. In this site

the user interact with the site by showing a sign up page if both of the landlord or user

don’t have already any log in account they must be fill the sign up form, otherwise the

user or landlord will direct logging in into the site by using his/her email id or password.

At the time of registration the user is provided with a number of terms and conditions

which must be agreed upon by the user, then patient will be able to use the application.

After being logged in the landlord will view the interface where basic modules are

provided like add/delete or update house details. The housing detail will save in database.

And after the user being logged in the user will see the different houses with their details

with their 3D view. The user will choose house according to his/her desire. When user

choose his/her house then the contact information of landlord will be provided to the




10

user. Then the user will easily interact with the landlord for further discussion. After that

the user can signing out to the website.

Figure 2.2 High Level Use Case Diagram

2.2.13 Analysis Level Use Case Diagram Two types of relationships are used in this diagram which are:

• Extend

• Include




11

Figure 2.3 Analysis Level Use Case Diagram

2.2.14 Use Case Description

Brief description

The use case of rent a house website is a model in which the actors are landlord, admin

or a user who wants to get any kind of help about the houses from this website. In this

site the user interact with the site by showing a sign up page if both of the landlord or

user don’t have already any log in account they must be fill the sign up form, otherwise

the user or landlord will direct logging in into the site by using his/her email id or

password. At the time of registration the user is provided with a number of terms and

conditions which must be agreed upon by the user, then patient will be able to use the

application. After being logged in the landlord will view the interface where basic

modules are provided like add/delete or update house details. The housing detail will save

in database. And after the user being logged in the user will see the different houses with

their details with their 3D view. The user will choose house according to his/her desire.

When user choose his/her house then the contact information of landlord will be provided

to the user. Then the user will easily interact with the landlord for further discussion.

After that the user can signing out to the website.

Preconditions

Preconditions of use case are that the user/landlord must have an email account to

validate him/ herself for the sign up. And the user/landlord must have the internet and

system then he/she uses to get the services of site. User/landlord must have an account on




12

the site or a email id. .

Basic flow

The basic work flow of our system is:

1. User will create an account for using the website.

2. After having an account, user will log in to the website.

3. User will be provides different modules to select.

4. User select the categories to get the house information.

5. User will provided the 3D view of houses.

5. User will be select the house.

6. User will signing out.

Alternate flows

The alternate flow of the site are at several points just like if user creates a sign in id and

wants to exit he/ she can exit the site at that point by logging out..

Post conditions

The post condition for our site’s use case is that the user must be logged in to exit the site.

2.1.7. Requirements Trace-ability Matrix:

The requirements trace-ability matrix is a table used to trace project life cycle activities

and work products to the project requirements. The matrix establishes a thread that traces

requirements from identification through implementation.

Chapter 3: Design Document




13

3.1. Introduction:

Third deliverable is all about the software design. In the previous deliverable, analysis of

the system is completed. So we understand the current situation of the problem domain.

Now we are ready to strive for a solution for the problem domain by using object-

oriented approach. Following artifacts must be included in the 3rd deliverable.

1. Domain Model

2. System Sequence Diagram

3. Sequence Diagram

4. Collaboration Diagram

5. Operation Contracts

6. Design Class Diagram

7. State Transition Diagram




14

8. Data Model

Now we discuss these artifacts one by one as follows:

3.2. Domain Model

Domain models represent the set of requirements that are common to systems within a

product line. There may be many domains, or areas of expertise, represented in a single

product line and a single domain may span multiple product lines. The requirements

represented in a domain model include:

• Definition of scope for the domain

• Information or objects

• Features or use cases, including factors that lead to variation

• Operational/behavioral characteristics

A product line definition will describe the domains necessary to build systems in the

product line.

What is domain modeling?

According to Rational Unified Process,® or RUP,® a domain model is a business object

model that focuses on "product, deliverables, or events that are important to the business

domain." A domain model is an "incomplete" business model, in that it omits individual

worker responsibilities. The point of domain modeling is to provide "the big picture" of

the interrelationships among business entities in a complex organization. The domain

model typically shows the major business entities, and the relationships among the

entities. A model that typically does not include the responsibilities people carry is often

referred to as a domain model.

It also provides a high-level description of the data that each entity provides. Domain

Sequence Diagram

3.3. Admin Sequence Diagram




15

Figure 3.2 Site Sequence Diagram




16

3.4. User Sequence Diagram

Figure 3.3 User Sequence Diagram




17

3.7. Design Class Diagram

3.7.1. Create Initial Design Classes

Figure 3.5 Initial Design Classes

3.7.2. Designing Boundary Classes

Figure 3.6 Boundary Classes




18

3.7.3. Designing Entity Classes

Figure 3.7 Entity Classes

3.7.4. Designing Control Classes

Figure 3.8 Control Classes

3.7.5. Identify Persistent Classes

Figure 3.9 Persistent Classes




19

3.7.6. Define Class Visibility

Figure 3.10 Class Visibility

2.7.7. Design Class Relationships

Figure 3.11 Class Relationships




20

3.8. State chart diagram

Figure 3.12 State chart diagram




21

3.9. Data Model

Figure 3.13 Data Model

Final Year Project Title - shiningstudy.com€¦ · SE- UOG - Project Coordination Office Version:...

Documents

Transcript of Final Year Project Title - shiningstudy.com€¦ · SE- UOG - Project Coordination Office Version:...