Properties for Sale in Istanbul with Schools and Parks | Antalya Development
Real estate
1. 1
SATISH PRADHAN DNYANASADHANA COLLEGE
OF ARTS, SCIENCE AND COMMERCE
THANE
PROJECT REPORT
ON
CLASSES MANAGEMENT
SYSTEM
SUBMITTED BY
Ashwinikumar R Sharma
PROJECT GUIDED BY
Mr. K. M. SATHE
T. Y. B. Sc. COMPUTER SCIENCE
UNIVERSITY OF MUMBAI
2017 - 2018
2. 2
CERTIFICATE
This is to certify that Mr. Ashwinikumar R Sharma has completed his Course
USCSP602 (Project documentation and Project Development)
“Real Estate management System” for the T. Y. B. Sc. Computer Science
examination of University of Mumbai, held in March 2018. Under our guidance
and supervision and to our complete satisfaction.
Ms. V. Y. Rane Mr. K. M. Sathe
Professor And I/C Head Project Guide
Dept. Of Computer Science
Satish Pradhan Dnyanasadhana Date: ____________
College, Thane
3. 3
CERTIFICATE
This is to certify that , Mr. Ashwinikumar R Sharma have completed
the
project of , “Real Estate management system” as per our
requirements for our Real estate .
His character shows that he is sincere, hard worker, faithful, honest,
industrious and reliable person. He is capable to shoulder
responsibility entrusted to him
__________________
Head,
5. 5
(iii) Limitations of present system
(iv) Proposed system and its adv.
[ For web project, URL can be mentioned]
(v) Feasibility Study
(vi) Gantt Chart
3 System Analysis
(i) Fact Finding Techniques (Questionnaire, Sample
Reports, Forms...)
(ii) Prototypes(if any)
(iii) Event Table
(iv) Use Case Diagram, Scenarios & Use Case
Description
(v) ERD
(vi) Activity Diagram
(viii) Class diagram
6. 6
(x) Sequence diagram/Collaboration Diagram
4 System Design
(i) Converting ERD to Tables
(ii) Design Class diagram[with UI classes, Persistent
classes etc…]
(iii) Component Diagram
(iv) Package Diagram
(v)Deployment Diagram
(vi) Program Flow charts & System flow chart
(vii) Structure Chart (Prg level and System level)
5 System Coding
(i) Menu Tree / Sitemap
(ii) List of tables with attributes and constraints
(iii) Design Patterns used (if any)
(iv) Program Descr[ Programs /Classes and their
responsibilities in brief ] with Naming Conventions
(v) Validations
(vi) Test Cases, Test Data and Test Results [Write test
cases for all imp. programs]
(vii) Screen Layouts & Report Layouts
(viii) Program Listing[for dummy proj]
6 System Implementation / Uploading
7 Future Enhancements
8 References and Bibliography
8. 8
Property dealing project is a user friendly software developed in Asp.net
programming language as front end and SQL server database as back end. This
project is designed to save the data of all those persons who will hire, lease or
buy any kind of property like buildings, flats, plots etc. which will reduce
manual work and helps the dealer to save the records efficiently. This project is
aimed at developing a Property Dealer Software. It provides the simplest,
cheapest and an less time and energy consuming way of Property Dealing.
In old days, the Property Dealer may have to keep records of the properties
manually. This method of keeping the records is quiet time consuming and less
efficient. Also there are more chances of mistakes by keeping the records
manually as human beings are habitual of doing mistakes. So with the help of
this, Property Dealing Software, the chances of mistakes becomes very few.
Also it is very efficient method of keeping the records of properties sold as well
as unsold properties. It consumes very less time as compared to manual
method.
The application is divided into three modules. The admin i.e. the Property
Dealer itself handles the whole software . He managed the database as well as
all the records.
INTRODUCTION
9. 9
In old days, the Property Dealer may have to keep records of the properties
manually on the papers. This method of keeping the records is quiet time
consuming and less efficient. Also there are more chances of mistakes by
keeping the records manually as human beings are habitual of doing mistakes.
There are several types of cost associated with manual records. One type ,
duplication of the record, requires paper and copying supplies, as well as the
staff to create and distribute the copies. Staff hired to assemble, file, retrieve,
or distribute the hard copy chart is a costly expenses. Storage of the paper
record necessitates the use of valuable space that could be better utilized. The
records also need to be protected from water, fire, or mishandling of the paper
to preserve their physical integrity. Staff members time required to deliver
paper records to a specific location. If the paper record is not readily available,
clerical staff responsible for filling documentation may need to make several
attempts before the task is completed. There is no ability to sort data fields in
a paper record. Staff responsible for reporting mandated data elements to the
appropriate organizations must perform a manual review. There is limitation to
the physical quality of the paper record. Paper is fragile and does not last
permanently. Normal use of the record may result in torn or stained
documents also over the years, ink used to complete documentation can fade.
Actual damage resulting from water or fire is another threat to the physical
integrity of the paper records.
Major Disadvantage:
• Cost of manual records
• Lost productivity from manual records
• Accessibility of records • Quality of manual records
• Fragmentation caused by manual records
Present System and Limitation
10. 10
Features:
All the records and data have been computerized and are now persistent.
Manual calculations have been automated.
Access to all types of records made easy.
The proposed system is a computerized system.
The customer has to just give his details like contact number, address,
Number of person accommodating with him and also the mode of payment
along with his details.
It also maintain record of all people who have visited their hotel, has a stay
before through a database.
Paper work is avoid.
Advantages of Proposed System:
This system is User-friendly, interactive and easy to use.
Save excess paper work.
Time saving.
No complexities.
Data security and backup facility.
The system simplifies the work of searching and adding the details of
customer.
Formatted data.
Records/ information’s are easily approachable.
The calculation can be done automatically.
PROPOSED SYSTEM
12. 12
Preliminary Investigation is the first phase in any system developing life cycle.
The Feasibility Study is a major part of this phase.
Feasibility Study means selecting the best system that meet the performance
requirement.
It is the measure of how beneficial or practical the development of an
Information System would be to the organization.
Our study of the feasible development of the software is going to be in
terms of the following aspects:
Operational Feasibility:
Proposed system is beneficial only if it can be turned into management system
that will meet the need of the client’s operating requirements. Kalidasa
Library’s work is increasing day by day.
The proposed system is operationally feasible due to the following reasons:
• The system is easy to use and is very simple.
• The proposed system will cost no harm to the company; instead it will
enhance the result in a better respect.
• The new system will avoid confusion and resistance by catching the user’s
attention, as it is presentable.
Economical Feasibility: 1. Development Cost
• Equipments required for developing the software are easily available.
• Equipment maintenance is also minimum.
• Saving of paper work and manpower reduced.
• Once the required hardware and software requirements get fulfilled there is
no need for the user of our system to spend for any additional overhead.
• Training cost is reduced. 2. Benefits which cannot be measured:
• Increased customer Loyalty
• Increased customer satisfaction
Technical Feasibility:
FEASIBILITY STUDY
13. 13
At first it is necessary to check that the proposed system is technically feasible
or not and to determine the technology and skill necessary to carry out the
project. If they are not available then find out the solution to obtain them.
Hardware is already available in the college.
Social feasibility:.
Although generally there is always resistance, initially to any change in the
system is aimed at relieving the workload of the users to extent the system is
going to facilitate user to perform operations like calculating salary amounts
and deductions, generating the reports using data reports with less possible
errors. Thus there is no reason to make system socially unfeasible
14. 14
An event occurs at a specific time & place, that can be described & is worth
remembered by the system. Events drive or trigger all processing that a system
does, so listing them & then analyzing them make sense when you need to
define system requirements.
EXTERNAL EVENT:
An event that occurs outside the system usually initiated by an external agent
or actor.
TEMPORAL EVENT:
An event that occurs as a result of reaching a point in time.
EVENT
15. 15
EVENT TABLE
A table that lists events in rows & key pieces of information
about each event in columns.
TRIGGER:
An occurrence that tells the system that an event has
occurred, either the arrival of data needing processing or of
point in time.
SOURCE:
An external agent or actor that supplies data to the system.
ACTIVITY:
Behavior that the system performs when an event occurs.
RESPONSE:
An output, produce by the system that goes to the system.
DESTINATION:
An external agent or actor that receives data from the
system.
Event List:
• Admin Maintain Seller record
• Admin Maintain Property record
• Seller Add Personal Details
16. 16
• Seller Add Property Details
• Seller Give Feedback
• Seller View Appointment
• Buyer Search Property
• Buyer Take Appointment
• Buyer Give Feedback
17. 17
Event Table
Sr.
No
Event Trigger Source Activity Response Destination
1. Admin
Maintain
Seller record
Seller record Admin Maintain
Record of
Seller
Seller Record Database
2. Admin
Maintain
Seller record
Property
Record
Admin Maintain
Record of
Property
Property
Record
Database
3. Seller Add
Personal
Details
Personal
Details
Seller Seller Successfully Database
4. Seller Give
Feedback
Give
Feedback
Seller Give
Feedback
Successfully Database
5. Buyer
Search
Property
Search
Property
Buyer Search
Property
Searching
Successfully
Database
9. Buyer Give
feedback
Give
feedback
Buyer Give
feedback
successfully Database
10. Buyer take
appointment
Take
Appointment
Buyer View Profile Buyer Take
Appointment
Successfully
Database
18. 18
Use Case Diagram is used to identify the “uses” or use cases of the new
system-- in other words, to identify how the system will be used .The Use Case
Diagram is essentially an extension of the Event Table.
USE CASE:
It describes an activity the system carries out in response to an event.
ACTOR:
In UML, the person involved is called an Actor. An Actor is always outside of
the Automation Boundary of the system.
CONNECTING LINE:
The arrow is used to show which Actors participate in which Use cases.
Use case
Automation
Boundary
Use case
Connecting Link
Actor
Use case Diagram
19. 19
DESCRIPTION:
The Object Oriented approach uses the term use case to describe an
activity the system carries out in response to an event. One can think of a use
case as a case or situation where the system is used for some purpose .A use
case diagram is a convenient way to document the functions that the system
must support. Sometimes a single, comprehensive diagram is used to describe
the entire system. At other times, a set of smaller use case diagrams make up
the use case model.
21. 21
Activity diagrams are graphical representations of workflows of stepwise
activities and actions with support for choice, iteration and concurrency. In the
Unified Modeling Language, activity diagrams can be used to describe the
business and operational step-by-step workflows of components in a system.
An activity diagram shows the overall flow of control. The most important
shape types:
• Rounded rectangles represent activities;
• Diamonds represent decisions;
• Bars represent the start (split) or end (join) of concurrent activities;
• A black circle represents the start (initial state) of the workflow;
• An encircled black circle represents the end (final state).
• Arrows run from the start towards the end and represent the order which
activities happen.
Activity Diagram
25. 25
CLASS DIAGRAM:
The Class diagrams are used to identify and classify the objects which
constitute a system. It also includes the important attributes of the objects
which must be captured.
CLASS:
It is a collection of objects of same type.
RELATIONSHIP:
A naturally occurring association among specific things.
CLASS DIAGRAM NOTATIONS:
In Class diagram, rectangles represent Class and the lines connecting
the rectangle show the relationships among Classes.
DESCRIPTION:
It is a model which is used to show the classes constituting a system
and their interrelationships .It is based on UML (Unified Modeling Language).
Only the important attributes and methods are shown in Class Diagrams. In the
initial period of analysis, the important attributes of the classes, which must
be captured and the functionalities provided by the class may not be very clear
. As the analysis progresses the attributes and methods may be added.
Class Diagram
27. 27
A Sequence Diagram has the following features:
A Sequence diagram describes interactions among classes in terms of an
“exchange of messages over time”.
Some of the facts related to Sequence Diagrams are:
Sequence Diagrams are used to depict the time sequence of messages
exchanged between objects.
Messages can correspond to operation on class or a event trigger.
Notations of a Sequence diagram include:
Lifeline: It is a vertical dashed line that represents the “lifetime” of an Object.
Arrows: They indicate flow of messages between objects.
Activation: It is a thin rectangle showing period of time, during which an
object is performing an action.
Sequence Diagram
29. 29
Component Diagram
Component Diagrams describe the organization of components, including
source code, run-time (binary) code, and executables.
Component Diagrams:
Give the physical view of the system in terms of implementation aspect. This
is important for reusability and performance purpose. Constitute the
Components, their interfaces and realizations, and dependencies between
Components
Component Diagrams are used:
To depict organizations and dependencies among Component type. To
show allocation of “classes” and “objects” to Components (also referred to as
modules) in the physical design of the system.
To indicate the “physical layering” and “partitioning” of the system
Architecture
A Component typically encompasses:
Structure and behavior of a “collaboration of classes” from the system
design. Interfaces that describe a group of operations implemented by
Components
Realization which is the relationship between an “interface” and the “class”
that provides the interface’s services
31. 31
A package diagram in the Unified Modeling Language depicts the
dependencies between the packages that make up a model.
In addition to the standard UML Dependency relationship, there are two
special types of dependencies defined between packages:
package import
package merge
A package import is "a relationship between an importing namespace and
a package, indicating that the importing namespace adds the names of the
members of the package to its own namespace." [1] By default, an unlabeled
dependency between two packages is interpreted as a package import
relationship.
A package merge is "a directed relationship between two packages, that
indicates that the contents of the two packages are to be combined. It is very
similar to Generalization in the sense that the source element conceptually
adds the characteristics of the target element to its own characteristics
resulting in an element that combines the characteristics of both"
Package diagrams can use packages containing use cases to illustrate the
functionality of a software system.
Package diagrams can use packages that represent the different layers of a
software system to illustrate the layered architecture of a software system.
The dependencies between these packages can be adorned with labels
stereotypes to indicate the communication mechanism between the layers.
33. 33
COLLABORATION DIAGRAM:
The UML Collaboration diagram is used to model how objects involved in a
scenario interact, with each object instantiating a particular class in the system.
Objects are connected by links, each link representing an instance of an
association between the respective classes involved. The link shows messages
sent between the objects, and the type of message passed (synchronous,
asynchronous, simple, balking, and timeout).
Collaboration diagrams offer a better view of a scenario than a Sequence
diagram when the modeler is trying to understand all of the effects on a given
object and are therefore good for procedural design.
Objects
Objects are depicted on a Collaboration diagram as rectangles. The object name
is provided first, with the class name to the right; the two names are separated
by a colon. You may specify the multiple occurrence of an object by opening its
definition dialog, selecting its Symbol tab, and toggling on the Multiple choice.
You may also select theMultiple Object tool from the toolbar.
Links
Messages passed between objects are specified within the Link drawn between
objects.
36. 36
ER-DIAGRAM:
• The relation upon the system is structure through a conceptual ER-Diagram,
which not only specifics the existential entities but also the standard relations
through which the system exists and the cardinalities that are necessary for the
system state to continue.
• The entity Relationship Diagram (ERD) depicts the relationship between the
data objects. The ERD is the notation that is used to conduct the date modeling
activity the attributes of each data object noted is the ERD can be described
resign a data object descriptions.
• The set of primary components that are identified by the ERD are
Data object Relationships
Attributes Various types of indicators.
The primary purpose of the ERD is to represent data objects and their
relationships.
Entity–relationship model (ER model) in software engineering is an abstract way
to describe a database.
An ER model is an abstract way to describe a database. Describing a database
usually starts with a relational database, which stores data in tables. Some of
the data in these tables point to data in other tables - for instance, your entry in
the database could point to several entries for each of the phone numbers that
are yours.
The ER model would say that you are an entity, and each phone number is an
entity, and the relationship between you and the phone numbers is 'has a phone
37. 37
number'. Diagrams created to design these entities and relationships are called
entity–relationship diagrams or ER diagrams.
Using the three schema approach to software engineering, there are three
levels of ER models that may be developed.
The conceptual data model: This is the highest level ER model in that it contains
the least granular detail but establishes the overall scope of what is to be
included within the model set. The conceptual ER model normally defines
master reference data entities that are commonly used by the organization.
Developing an enterprise-wide conceptual ER model is useful to support
documenting the data architecture for an organization.
A conceptual ER model may be used as the foundation for one or more logical
data models. The purpose of the conceptual ER model is then to establish
structural metadata commonality for the master data entities between the set
of logical ER models. The conceptual data model may be used to form
commonality relationships between ER models as a basis for data model
integration.
The logical data model: A logical ER model does not require a conceptual ER
model especially if the scope of the logical ER model is to develop a single
disparate information system. The logical ER model contains more detail than
the conceptual ER model. In addition to master data entities, operational and
transactional data entities are now defined.The details of each data entity are
developed and the entity relationships between these data entities are
established. The logical ER model is however developed independent of
technology into which it will be implemented.
The physical model: One or more physical ER models may be developed from
each logical ER model. The physical ER model is normally developed to be
38. 38
instantiated as a database. Therefore, each physical ER model must contain
enough detail to produce a database and each physical ER model is technology
dependent since each database management system is somewhat different.
The physical model is normally forward engineered to instantiate the structural
metadata into a database management system as relational database objects
such as database tables, database indexes such as unique key indexes, and
database constraints such as a foreign key constraint or a commonality
constraint. The ER model is also normally used to design modifications to the
relational database objects and to maintain the structural metadata of the
database.
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how
“entities” such as people, objects or concepts relate to each other within a
system. ER Diagrams are most often used to design or debug relational
databases in the fields of software engineering, business information systems,
education and research. Also known as ERDs or ER Models, they use a defined
set of symbols such as rectangles, diamonds, ovals and connecting lines to depict
the interconnectedness of entities, relationships and their attributes. They
mirror grammatical structure, with entities as nouns and relationships as verbs.
40. 40
DEPLOYMENT DAGRAM:
Deployment diagrams depict the physical resources in a system including
nodes, components, and connections.
• A deployment diagram shows the configuration of run time processing
nodes & components that live on them.
• This involves modeling the topology of the h/w on which your system
resides.
• Deployment diagram contains
– Nodes
Dependency & Association
Basic Deployment Diagram Symbols and Notations:
Component
A node is a physical resource that executes code components.
Association
Association refers to a physical connection between nodes, such as Ethernet.
44. 44
FINAL LIST OF TABLES AND VALIDATIONS:
LIST OF TABLES:
Customer Register:
Sr no. Attributes Datatype
1. Cust__id numeric
2. Cust_name varchar
3. Cust_contact nvarchar
4. Cust_adress Nvarchar
5. Cust_mail nvarchar
6. Cust_password nvarchar
Property:
Sr no. Attributes Datatype
1. p__id numeric
2. p_name varchar
3. C_contact nvarchar
4. C_address Nvarchar
5. C_mail nvarchar
6. P_room nvarchar
7. P_cost Numeric
8. P_type nvarchar
9. P_location nvarchar
11. P_sufeet numeric
45. 45
Buyer Feedback:
Sr no. Attributes Datatype
1. id numeric
2. name nvarchar
3. Feed_ans nvarchar
Seller Feedback:
Sr no. Attributes Datatype
1. id numeric
2. name nvarchar
3. Feed_ans nvarchar
Appointment
Sr no. Attributes Datatype
1. id numeric
2. b_email varchar
3. name nvarchar
4. number Nvarchar
5. email nvarchar
6. Address nvarchar
7 b_id numeric
46. 46
VALIDATIONS:
1. All fields are required in registration form.
2. Valid email and mobile number should be accepted.
3. Only alphabets allows in full name.
4. Check username and password across login form .
5. Student registration must be valid.
6. All fields are required in admission form.
8. Start date is greater then end date.
9. Valid date should be accepted.
10. password and confirm password should match.
47. 47
CUSTOMER TEST CASES:
1. Customer Registration
Sr. no. Test case Expected result Result
1. Enter valid
information and
click on register
registered Successfully
2. Login
Sr. no. Test case Expected result Result
1. Enter valid
information and
click on login
login Successfully
3. Upload Property
Sr. no. Test case Expected result Result
1. Upload Property Uploaded Successfully
48. 48
4 Appointment
Sr. no. Test case Expected result Result
1. View
Appointment
View Successfully
5. Add feedback
Sr. no. Test case Expected result Result
1. Enter feedback
click on add
feedback send Successfully
ADMIN TEST CASES:
1. Login
Sr. no. Test case Expected result Result
1. Enter valid
information and
click on login
login Successfully
2. Maintain
Sr. no. Test case Expected result Result
1. Maintain Seller
Details
Maintain
49. 49
3. maintain
Sr. no. Test case Expected result Result
1. Maintain
Property Details
Maintain
4 view
Sr. no. Test case Expected result Result
1. View Feedback view