document

SCHOOL OF INFORMATICS
DEPARTMENT OF INFORMATION TECHNOLOGY

Tittle: Condominium management system for WSU
Group members
Name ID Number
1. Geremew Gero--------------------------231/05
2. Mesfin Mathewos----------------------363/05
3. Tesfaye Yitagesu--------------------------------514/05
4. Ribika G/Michael----------------------422/05
5. Abebayitu Yihun----------------------027/05
Advisor:-
1. Mr. Siraj Sebhatu
Submission Date: 26/02/2008

Wolaita, Ethiopia
I|Page
Abstract
Now days, using computers to simplify deadly manual work is significance. Therefore, this our
project will uses the web based system to solve the mannal system of the work to computerized
web based system. Because using computer gives many benefits like speed, accuracy, storage
capacity, flexibility, cost reduction and minimizing tedious manual work. So, wolaita sodo
university condominium system is limited on manual works. This has a limitation for customer’s
used up large amount of time in front of the office to register and high consumption of resources.
To overcome this problem we are proposing the new web based system for WSU.The
programming languages will be used to develop this project are PHP, JAVA SCRIPT,
HTML.Database application is MYSQL.
II | P a g e
Acknowledgement
First of all we would like to thank almighty God who helped us through preparation of this
proposal and documentation. Next to that the group members would like to express greatest
gratitude to our advisors Mr. Siraj Sebhatu to his extensive advice for the project completion
and great thanks to all condominium committee who helped us by presenting important
information on the existing condominium distribution and management system.
III | P a g e
List of Tables
Table 1.Team Composition table.................................................................................................................2
Table 2. Development tools table................................................................................................................6
Table 3. Required resources with cost table................................................................................................7
Table 4. Task and Schedule.........................................................................................................................8
Table 5.Use case description for login.......................................................................................................19
Table 6. Use case description of distribute the house...............................................................................20
Table 7.Use case description for manage account....................................................................................21
Table 8. Use case description for Create account......................................................................................21
Table 9.Use case description for delete account.......................................................................................22
Table 10. Use case description for update account...................................................................................23
Table 11. Use case description for maintenance request..........................................................................23
Table12.Use case description for generate report....................................................................................25
Table 13. Use case description for clients online registration...................................................................26
IV | P a g e
List of Figures
Fig 1 .Use case diagram.............................................................................................................................17
Fig 2 .Class diagram……………………………………………………………………………………………………………………………….28
Fig 3. Sequence diagram for login.............................................................................................................30

Fig 4.Sequence diagram for create account..............................................................................................31
Fig 5. Sequence diagram for delete account..............................................................................................32
Fig 6.Sequence diagram for update account.............................................................................................32
Fig 7. Sequence diagram for distributing house........................................................................................34
Fig 8. Sequence diagram for manage account...........................................................................................35
Fig 9 .Sequence diagram for generate report............................................................................................36
Fig 10.Sequence diagram for online clients’ registration...........................................................................37
Fig 11. Activity diagram for Login..............................................................................................................38
Fig 12. Activity diagram for delete account...............................................................................................40
Fig 13. Activity diagram for update account..............................................................................................41
Fig 14. Activity diagram for register clients...............................................................................................42
Fig 15. Activity diagram for manage account.............................................................................................43
Fig 16. Activity diagram for maintenance request.....................................................................................44
Fig 17.Activity diagram for generate report..............................................................................................45
Fig 18. Activity Diagram for online registration.........................................................................................46
Fig 19.user interface prototyping diagram................................................................................................47
Fig 20. System architecture for Condominium Distribution and Management system.............................52
Fig 21. Hardware/Software Mapping for WSU CMDS (deployment diagram)...........................................53
Fig 22. persistence data management diagram.........................................................................................54
Fig 23. DB diagram.....................................................................................................................................56
Fig 24.Home page user interface design....................................................................................................58
Fig 25. Login use interface page................................................................................................................59
Fig 26.Manage user account interface page..............................................................................................60
Fig 27. Clients registration form................................................................................................................61
V|Page
ACRONOMY
HTML-----------------------------Hypertext Markup Language
PHP--------------------------------Hypertext pre Processor
SQL--------------------------------Structural Quire Language
CSS--------------------------------Cascade Style Sheet
PC----------------------------------Personal Computer
MS Word--------------------------Micro Soft Word
CD----------------------------------Compact Disk
UC----------------------------------Use Case
WSU--------------------------------Wolaita Soddo University
UML--------------------------------Unified Modeling Language
CDM--------------------------------Condominium Management System
XML--------------------------------Extensible Markup Language
ER-----------------------------------Entity Relation
DB-----------------------------------Data Base
VI | P a g e
Table of Contents
1. Background.............................................................................................................................................1
2. Statement of the problem.........................................................................................................................1
4. Objectives of the project..........................................................................................................................3
4.1. General objective..............................................................................................................................3
5. Specific Objective of the project..............................................................................................................3
5.1 Significance of the project.................................................................................................................3
6. Limitation of the project..........................................................................................................................3
7. Scope of the project.................................................................................................................................3
8. Feasibility analysis..................................................................................................................................4
8.1 Technical feasibility...........................................................................................................................4
8.2 Scheduling feasibility.........................................................................................................................4
8.3 Operational feasibility......................................................................................................................4
9. Methodology...........................................................................................................................................5
9.1 Fact finding techniques......................................................................................................................5
9.2 Data sources......................................................................................................................................5
9.3 Development tools............................................................................................................................6
10. Required resources with cost.................................................................................................................7
11. Tasks and schedule of the project..........................................................................................................8
CHAPTER TWO.........................................................................................................................................8
SYSTEM REQUIREMENT SPECIFICATION (SRS)...............................................................................8
2.1 Description of the existing system.........................................................................................................8
2.1.1Players in existing system................................................................................................................9
2.1.2 Major functions /Activities in current system.................................................................................9
2.1.3Bussiness Rules..............................................................................................................................10
2.1.4 Report generated in the existing system......................................................................................10
2.1.5Forms and other documents in existing system............................................................................11
2.1.6 Bottlenecks of the existing system................................................................................................12
VII | P a g e
2.2 Description of the proposed system.....................................................................................................13
2.2.1 Requirements of the proposed system.........................................................................................14
2.2.2 Functional Requirements..............................................................................................................14
2.2.1.2 Nonfunctional Requirements.....................................................................................................15
CHAPTER THREE...................................................................................................................................16
SYSTEM MODEL....................................................................................................................................16
Introduction...............................................................................................................................................16
3.1 Use Case Diagram...............................................................................................................................16
3.1.1 Actor specification........................................................................................................................17
Condominium management System Actors...............................................................................................18
Condominium management System Use Case Listing..............................................................................18
3.1.2 Use case Description.....................................................................................................................18
3.2 Class Diagram.....................................................................................................................................26
3.3 Dynamic model...................................................................................................................................29
3.1.1 Sequence diagram........................................................................................................................29
3.1.2 Activity Diagram............................................................................................................................38
3.4 User interface prototyping...................................................................................................................46
Chapter four...............................................................................................................................................48
4. System design........................................................................................................................................48
4.1 Introduction.........................................................................................................................................48
4.2 over view of system design..................................................................................................................48
Logical design...................................................................................................................................48
Physical design..................................................................................................................................48
4.3 Design goal..........................................................................................................................................49
4.4 Proposed Software Architecture..........................................................................................................51
4.5 Hard ware and Software mapping........................................................................................................52
4.6 persistent data management.................................................................................................................53
4.6.1 Data base design...........................................................................................................................55
4.6.2 ER diagram....................................................................................................................................57
4.7 user interface design............................................................................................................................58
Chapter Five: Implementation and Testing..............................................................................................62
5.1 Introduction.....................................................................................................................................62
VIII | P a g e
5.2.Final Testing of the system..............................................................................................................62
5.3 Hardware software acquisitions......................................................................................................80
5.4 User manual preparation.................................................................................................................81
5.5 Training............................................................................................................................................83
5.6 Installation Process..........................................................................................................................83
Chapter Six: Conclusions and Recommendation.......................................................................................84
6.1 Conclusions......................................................................................................................................84
6.2 Recommendations...........................................................................................................................84
References.................................................................................................................................................86
IX | P a g e
CHAPTER ONE
1. Background
Wolaita Sodo University is a one of Ethiopian university which was established in the year of
1999 E.C. in this manner, the university has 225 condominium houses which contains 15
buildings which are bought from housing development agency. Housing the houseless people is
one of the basic strategies. House is one of the basic necessities for human beings. However, it is
a critical problem for thousands of poor people in Ethiopia.
The Wolaita Sodo University condominium management system has its own administration
committee to organize, control and manages the local communities. The integration of web based
in condominium management service is necessary for providing housing service effectively and
efficiently through a better management at all levels of office. This shifts to automation by the
integration of operations using computer technologies to save record time and improving
reliability of ordering and obtaining results. Wolaita sodo university condominium distribution
and management office is which is found in WSU. It is responsible to control the activities such
as distributing the finished houses to resident and facilitates infrastructure regarding
condominium house.
This study aimed at addressing problems of security, secrecy and confidentiality of
condominium records and distributions. Timely access to historical records.
Now a days, the condominium house classification is given based on the criteria which is listed
below:
 For academic level
 year of service
 Job of responsibility
 Status of married or unmarried
2. Statement of the problem

The traditional methods of data management have resulted into incomplete and inaccurate data in
many cases. The system is characterized by delays and sometimes it is difficult to find the
1|Page
previous file of the clients from the document; errors were occurred in any entry and manual
analysis of results, secrecy and confidentiality of records lacked because unauthorized persons
could easily access the records. The major problems are listed below:
Data Redundancy: Since there is no organized database there is a problem of giving more than
one house for a single person.
 There is wastage of vast amount of human power.

 There is no security in the documents of the system.
 It has wastage of time in the system.
 Data modification is very difficult.
 Searching for customer information (record) was difficult to get.
Poor data management
 Duplication of record.
3. Team composition
Project tittle Condominium management system for WSU

Prepared by s.no. Id no. e-mail/phone no Role & Responsibility
1.Geremew Gero 231/05 0964013544 Project manager
514/05 0916113208 System designer
2.Tesfaye Yitagesu
Programmer
3.Mesfin Mathewos 363/05 0926148105
4.Ribika G/Michael 422/05 0927160075 System analysis
Abebayitu Yihun 027/04 0923043247 DB interface

Date
22/02/08
Advisor Mr. Siraj Sebhatu

Table 1.Team Composition table
2|Page
4. Objectives of the project
4.1. General objective
To develop a new web based condominium management system for wolaita Sodo
University which solves the above mentioned problems with the existing system. This is
achieved by developing or designing a web based application program that will change
the actual manual processing in to a computerized environment.
5. Specific Objective of the project
 To store the data’s of the applicants into the database.

 To minimize data redundancy.
 To design and developed a user friendly system to handle data insertion, updating,
deletion, retrieving on the database.
 Analyze the existing system and design better system for the organization
5.1 Significance of the project

 It automates the system by saving time of the organization and clients.
 Reduce wastage of time, cost and redundancy of information or data.
 The information of the condominium should be reliable and secure, that means the
information is not access by unauthorized person.
6. Limitation of the project

 The system does not draw the lottery chance for those condominium house users
 The system does not have online relationship with banking system.
 It gives service for those university lecturers and academic workers only.
 The system does not include the whole payment process.
7. Scope of the project

Our system basically works on wolaita sodo university condominium management system for
web based system.
3|Page
To avoid the problems associated with the manual processing.
The project can cover Home seeker in the following activities:-
 Registering new customers
 Generate registered client report
 Post notifications
 Distribute the condominium houses
 It gives house maintenance service/descriptions
8. Feasibility analysis
A feasibility study is an initial study assumed to determine whether it is possible, advantageous
and realistic to develop the system it is the discipline of planning, organizing, and managing
resources to bring about the successful completion of specific project goals and objectives.
8.1 Technical feasibility

The technology that is used to develop this system is widely available and it is easy for the users
to make use of it. In this regards the project is feasible since it does not require any cultured
knowledge; simply users are required to work with computers and simple MySQL applications.
So it will be possible for the users to use the system more efficiently and effectively. The system
have user friend interface that allows the users of the system to perform the action they want
without confusion.
8.2 Scheduling feasibility

This determines how long the system will take to develop. Despite the complexity of the project
all the group members will try to come to an end to the project in the time stated without
considering any delay or any of the members being absent, sick or late. But if such things happen
we will provide the things we have so far and come with some compensation mechanism.
However the team is so determined to finish this project according to the schedule. Therefore,
the project is feasible in terms of time schedule. The reason is that the group is well organized
and knows its duties and responsibility.
8.3 Operational feasibility

With regard to this, the developing team answers questions like will the system developed be
operational in the organization, will it solve problems it was meant to solve, etc. The system will
4|Page
definitely have a positive impact on the users and have a massive effect in terms of solving the
problems for which the system was set out to do. The new system is operationally feasible
because we are following each step how the existing system is working and our technical skill is
transforming the existing system into a computerized one. And also users are involved in the
development of this project by providing their opinion and feedback and they have understood
how it supports their day to day business operation which makes the system operational.
9. Methodology
There are different methodologies used to develop the proposed system. From these
methodologies, object oriented programming is used to achieve reliable and effective working
system.
9.1 Fact finding techniques

For the development of this system several fact finding techniques were employed. And a
number of data sources were considered here to get precise understanding on the subject matter.
The project team uses the following fact finding methods which are considered as suitable for
this project.
System analysis and design approaches

Among the techniques, the one we will use to develop our system is object oriented approach .
Because it makes the system more reusable.
 It clarifies the real world by its objects, entity, services.
 This approach also combines the process and data in to single entities
9.2 Data sources

Interview
Extensive interview is conducted with the wolaita sodo university condominium committee. One of
the condominium management committee we interviewed is Mr.Kedir
ous
man who is the wolaita sodo university instructor(teacher).
5|Page
Observation
We made observation how the office participated in condominium distribution and management and
how to store data in their office. We made this observation orally by asking one of the condominium
committee Mr. Kedir
9.3 Development tools
Activity Tools(programs)
Client side coding HTML,css,php,XML
Client side scripting Java script
DB server MySQL
Server side scripting(wamp server) Php
Browser Google, Mozilla firefox
Editor Notepad++,dream
waver
Documentation MS word, power point
Table 2. Development tools table
To develop the system different software, hardware tools and programming language are very
Important.
Software tool requirements

Microsoft office word:-It is very useful because it takes less time to write and format the text,
communicative effectively smart diagram and chart tools, quickly assemble document. By looking its
useful properties we use Microsoft office word to type our project work to get all the above benefits
of it.
Power point: We use this tool to present the document in abstract forms. We use it to present our
presentation in short and brief way.
Html: The html language was designed to an effective way of achieving this transferring of data
and was designed to be evolving as new media format was created. We use html to develop our
statically parts of our code. We use because of html is compact and effective language.
JavaScript: JavaScript is very interesting language used to validate data and develop different
messages. We use it to validate our data which we use in html code.
6|Page
Php: Php is one of sever side scripting language, which means the scripts are executed on the
server, which can be embedded in HTML or used as standalone binary. We use it to develop the
dynamic part of the web site.
MySQL: The most commonly used database with PHP. It is a free and open source of database that
has a lot of user especially for web applications.
Hardware tools requirements
Different hardware used to develop this project.
Computer: All tasks are done on computer.
Network cable: Used to get the internet access by connecting internet line from internet hub to
computer for further read and search information from internet.
Flash Disk and CD Hardware: Used for the movement of data from one machine to another.
We use both of them when we move our data from one machine to another.
10. Required resources with cost

Type of quantity Unit price total price
RESOURCES Table
Pc &laptop 2 19000 19000 3.
flash 2 140 140
pen 1 4.00 4.00
Ear phone 1 50 50
Paper 35 9.50 9.50
1 13 13
CD
TOTAL 19216.5\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Required resources with cost table
7|Page
11. Tasks and schedule of the project
N activities Oct18_oct25/02/ Oct29_Nov9/03/ Nov9_Nov23/03/ Nov24_Dec17/ D
o 08 08 08 04/08 Ec18_de
. c 28
1 Project
proposal
2 Analysis and
design
3 Implementati
on
& coding
4 Testing and
verification
5 documentatio
n
Table 4. Task and Schedule
CHAPTER TWO
SYSTEM REQUIREMENT SPECIFICATION (SRS)
2.1 Description of the existing system

The system in which our project is applied on web based condominium management System.
The University has 225 condominium houses which contain 15 buildings and they are bought
from house development agency. In the existing system the responsible individuals who are
participating in the distribution and management of condominium houses. Now days the Wolaita
Sodo University condominium has two sites, the first one is the condominium house which is
found in front of the University. That condominium has 150 classes. Among those classes, 60
classes each has with 2 beds, another 60 classes each has only 1 bed and 30 studios. The second
site of the condominium has 75 classes. They are divided in to two. These are 30 classes with 2
beds and the other is 45 classes with 1 bed.
Now a days, the condominium house classification is given based on the criteria which is listed
below:
8|Page
 For academic level
 year of service
 Job of responsibility
 Status of married or unmarried
Therefore, the above mentioned paragraph explains about the description of the existing system.
2.1.1Players in existing system

As mentioned earlier, the web based condominium management system consists of players
(actors). Each actor (players) has their own responsibilities. Those are as follows.
 Condominium committee: - these committees are selected from each college of the
WSU and they are responsible for distributing the houses for the University lectures that
got the chance to the condominium house.
 The lectures (staff members):-are an individual who wants to have condominium house
which have no private house. The house is only given to the lectures who have no their own
house. If they have their private house, the University committee doesn’t give house for
them.
 General Service: is one of an entity who is responsible to control the whole process of
the condominium for the staff members.
2.1.2 Major functions /Activities in current system
In the existing system, different activities are accomplished. The activities are;
 Input: - in the existing system there are different input forms which help to staff
members. This input forms are found in Wolaita Sodo University teachers common
housing committee. The following are considered as inputs.
-Application: the customers submit the application for the computation to get the house.
This application is submitted to the condominium committees.
- Year of service, Job responsibility, Academic levels, Marriage status etc.
 Process: -In the existing system the process of activity is the customer can only fill the
information’s on a given manual form by the criterion which is putted in the University
guide lines. The processes are as follows:-
9|Page
- After they submit the application for the computation, they see their result if they Winn to get
the house or not by notice. This is one the process.
-transferring the house to another person is impossible.

- After the customer gets the house, if the house is damaged or any safety problem
occurs, he/she has the duty to maintain the house.
-the customers should respect and apply the rules and responsibilities which are
transferred from the committee.
-When the customers (lectures) leaving the house, they have to report to the University
committee about leaving the house.etc.
 Output: - in the existing system, if the lecture (customer) can Winn or get the chance
she/he can get the house easily and directly.
- The other output is the lectures knows if they get house or not by notice.
2.1.3Bussiness Rules
A business rule is an operating principle or policy that must be fulfilled and in order to the
system function properly and effectively. The business rules are as follows:-.
 Business rule 1:- For academic level, the point from 100% will be given 50%.
 Business rule 2:-For year of service, 25% will be given out of 100%.
 Business rule 3:-Marriage status, 10% will be given.
 Business rule 4:-For job responsibility, 15% will be given.
 Business rule5:-For disability (for disable female teachers 10% will be given
additionally).
 Business rule 6:-There will be 1200 birr payment for the lectures per month about the
house, if the lectures get condominium house, the University don’t pay those birr for the
lectures. Etc.
2.1.4 Report generated in the existing system
These are reports generated for the Committee; this enables the committees to control the
activities of the condominium house.
-When the process is finished, that means the lectures get the chance of the house, the committee
submit the report for the University president.
-the users of this report are the customers that mean the University lectures.
10 | P a g e
-The other report generated in existing system is when the lectures are leaving the house by
different causes such as if they get the chance to education or if the wants to change the
University, they firstly submit the report to the general service office and the general service
takes the report submit to the administrative office (Astedader limat), after that he/she can leave
the house.
2.1.5Forms and other documents in existing system
11 | P a g e
12 | P a g e
13 | P a g e
2.1.6 Bottlenecks of the existing system
As we described in the proposal paper in problem formulation part there are some problems the
existing system face because it is manual. Some of them are as follows.
 Performance: the performance of the existing system is very low &it takes long time.
-because when the lectures are filling the form, the redundancy will be occur.
14 | P a g e
-If the damage will occur, for example, fire, some moisture, etc., the data will be easily
loosed.
 Security and control: - There is no security because it is booklet anyone can see the
document. For this reason there is controlling error,
 Efficiency (well-organize):- The existing system is not fully efficient by structurally.
Because there will be:
-no network service in the existing system
-there is no training about the system
-there is no well-organized structure about the existing system
- The guide lines are not put structurally.
 Data stored: -the data is stored manually prepared documents which contains the
information about the condominium. This data storage is based on paperwork. For this
reason many different problems will be occurring. For example:-
-many data redundancy occurs exactly.
- If any person picks the data suddenly, those data will be loosed easily because it is
paper work. Etc.
2.2 Description of the proposed system
The proposed system will solve the problems of the existing system by changing manual system
into web based system. The new proposed system will have the following features which are not
in the existing system. These are:-
 The new system will be web based or automated system.

 It automates the system by saving time of the organization and Clients.
 The system also prevent data lose by preventing outsiders using authentication i.e. Using
password, authorization using access control mechanism.
 It will have additional database, which was not on the previous system.
 The system will come up with updated information contents
15 | P a g e
 Business rules about the proposed system
The business rules about the proposed systems are as follows. These are:-
 BR1: The lectures (customers) must be only the Wolaita sodo University lectures.
 BR 2: the lectures must fulfill the criteria to get the house which will be found in
WSU condominium guide lines
2.2.1 Requirements of the proposed system
The Condominium distribution and management System expected to perform lots of tasks
successfully inquired by the users. The purpose of the requirement gathering and management is to
correctly identify the data, process and interface functional and non-functional requirements for the
user of the new system
2.2.2 Functional Requirements
Functional requirements are requirements that are used to capture the intended behaviors of the
system. Since we are going to develop a web based application for condominium management
system, the system will have different functions. Some of the functions are;
 Login: - to identify the authorized person to use the system.

 Data update:- needs to update data from the system when it is necessary
 Assigning the staff members: - it means that the condominium house is only given
for the University lecture. It doesn’t allow for other employees. Etc.
 Generate report:-the system allows manager to generate reports about the
condominium house.
 Manage condominium related information.
16 | P a g e
2.2.1.2 Nonfunctional Requirements
Nonfunctional requirements are features of the system which has no direct implementation on the
system.
Economy: System reduces the cost related to the condominium house. Example as a result of a
new system the payment for many clients will be reduced. Reduce cost of paper; reduce the time
spent by the committees as well as the clients.
Efficiency: The web based distribution and management System by itself is short and clear and in
this system there is no duplication of data. The new system is powerful to manage things around
house.
Security Issue: To protect condominium distribution and management system data, to avoid loss
of information and system misuse, the system will provide restriction in using functionality and
information access by its users. Security is implemented by requiring users to login before using
the system. The login procedure is password protected.
 The system doesn’t have any commercial bank relationship. Etc.
17 | P a g e
CHAPTER THREE
SYSTEM MODEL
Introduction
Model is an abstraction of the real world. It deals with the complexity in a current real-world
problem by focusing on the essential and interesting features of an application. The techniques
and associated notation used for object oriented analysis and design in incorporated in to a
standard object – oriented language called unified Modeling language (UML).
3.1 Use Case Diagram

A use case diagram is a graphic description of the interactions among the elements of a system.
Use case is a methodology used in the system analysis to identify, clarify, and organize the
system requirements. In this context the term system refers to something being developed or
operated, in our case condominium distribution and management system.
18 | P a g e
create
account
distribution
delete <<include>>
house manager account
gererate report <<include>>
update
manage
send <<include>>
notification account account
clients login
Online registration sysstem admin
maintenance
view winner
view notifacation
Fig 1 .Use case diagram
3.1.1 Actor specification
Condominium management System Actors
19 | P a g e
Actors Description
Administrator A special user of the system who can manage the system setup access
right for other users and administer the system .Also can remove the user
information from the database in consultation with the manager.
Generally the administrator gives technical support for the system and
manages the system.
client Someone who can access the system and he/she should be the member
of society.
Manager Someone who can manage the user information, approve users request
and activate or deactivate the user account. Also remove the user from
the database.
Condominium management System Use Case Listing

Use Case no Use Case Name
UC 1 login
UC 2 Create account
UC 3 delete account
UC 4 Update account
UC 5 Registration
UC 6 distribution
UC 7 Manage account
UC 8 Generate report
UC 9 maintenance
UC 10 View notification
UC 11 View winner
3.1.2 Use case Description

Describing each use case process helps to clarify the concept of the use case
Table1: Use case documentation for log in
Use case Name Login
Use case number Uc1
Actor All actors
20 | P a g e
Description This use case is used to authenticate users to the system
Precondition User must have username and password
Post condition Users enter to the authorized page

Basic course of Actor Action System Response
action
1. The user loads to the 3. Systems display the login
system. form and ask to fill the
2. The users click on the username and Password.
login page.
4. The users enter user name 5 System check entered
and password. value and its privilege.
7. The users go to their own 6 System displays
page. authorized page.
8 Use case ends.
Alternative course
Al: The system validates the entered information

And if the input data is invalid
The system asks again to enter password and username.
Table 5.Use case description for login
Use case name Distribute the house
Use case number Uc2
primary Actor Housing manager
Description The Housing manager login to the system
21 | P a g e
preconditions 1. Select from the winners table whose requesting parameter is one
class
2. Map the each customer to the house with one class.
3. Repeat step 1 for two classes, three classes
4. Repeat step 2.
5. Save the mapped table.
6. Display to the customer.
Post condition Save the mapping table and post to the client
Exit condition Housing manager logout from the system
Table 6. Use case description of distribute the house
Use case name Manage account

Use case number Uc3
Primary Actor System admin
Description The Administrator of the system manages the all term of the system.
Pre-condition The Administrator should be login to the system.
Basic course of Actor action system response

action Step1.The Administrator Step2. The system displays the home page of the
must login to the system. administrator and user information page
Step3.TheAdministrator Step4.The system updates user information database.
searches &manages user Step 6. If there is an error or bugs, the system displays
information and creates it.
new user account.
Step5.
The administrator checks
the system errors or bugs.
Step7. Fix the error or
bugs.
Alternative course 1. If there change and updated user information message from the system asks to
of action save the changed or is an error or bugs the system display an error message.
2. Prompt the manager to check for error.
.
Post condition User information will be updated or deleted. Also manages the system.
Table 7.Use case description for manage account.
22 | P a g e
Use case name Create Account
Use case no Uc-4
Primary actor System administrator
Description Describe in detail, create user account for users of the system.
Pre-condition The admin must login to the system and the system displays
services home page
Basic course of Actor action System response
action Step1. The User launches the Step2. The system displays the
system. Main page.
Step3. The user clicks sign up Step4. The system displays the
button. Registration form.
Step 5. The user fills the Step6. The system checks the
information and click submits. information filled for validity.
Step7. If the user information is
valid go to login page.[Alt1]
Alternative [Alt1]: If the user enters invalid information, the system displays
course of action error message and prompts the user to try again.
Post condition New account and new user can be added to the system.
Table 8. Use case description for Create account.
Use case name Delete account
Use case number Uc5
Primary Actors System administrator
Description Describe in detail, Remove user account from system if it is unwanted
23 | P a g e
Pre-condition
Administrator must be to login to the system.
Post-condition The account has been deleted from the system.

Basic course of action Actor action System response
1. The admin click on 2. The system displays the to fill delete form
page.
the delete account
4.The system validates the deletion
link on the 5. The system displays the successful message.
administrator page. 6. Use case ends.
3. Select the account
which is deleted then
click on delete.
Table 9.Use case description for delete account
Use case name Update account

Use case no Uc-6
Primary actor System administrator
Description Describe in detail update user account with in a system if it is necessary.
Pre-condition The admin must login to the system and the system displays home page.
Post condition The system displays the successful message.
Basic course Actor action System response
of action 1. Admin Click on the 2. The system displays the update page.
update link from the 5. Use case ends.
administrator Home page.
3. select the update account
4.Admin click update button
Alternative [Alt1]: If the user enters invalid information, the system displays error message and
course of prompts the user to try again.
action
Table 10. Use case description for update account
Use case name Maintenance
24 | P a g e
Use case number Uc7
secondary Actor client
Pre-condition The client must win and get the house & login to the system
Post condition The data is sent.

1. client click on button ‘Maintain 2. The system Display the form.
request’ 4. Checks the entered data is correct or
3. insert his/her basic data on the not.
form provided 5. system displays the information
6. Open the common email given 7. If the client is not found in the winner
to the customers and phone database, The system provide error
number message
8. Go to step 3
9. use case ends
Table 11. Use case description for maintenance request
25 | P a g e
Use case name Generate Report
Use case number Uc9
Actor manager
Description Use case to generate report.
Precondition These use case allows manager to generate report

about condominium information of month.
Post condition System displays report.
Actor Action System Response
1. The manager wants to 4. The system

generate report. responds the
2. Manager activities the requested page.
report interfaces.
3. Manager selects the 5. System responds by
Basic course of the action
report type from the displaying report
displayed report link. extracts from the data
base.
6. Use case ends.
Table13.Use case description for generate report
Use case name Use case number

Use case no 10
26 | P a g e
Actor clients
precondition The clients to have open the web page
Post condition The database will be updated
The clients clicks on ‘home seeker 1. Check the whether the
registration ’ button requesting home seeker data is
1. Registration form will be updated or not.
displayed 2. Check the validity of the data
2. Fill the data on the provided text inserted by the customer
filed or text area. 3. Check home seeker data found
3. click on register button in the database.
4. Check whether he/she has home
registered by his/her name.
5. Check whether the requesting
home seeker previously take house
or not by checking in the previous
winner database.
Alternative action
C3 Invalid information entry.
3.1 Error message is displayed
3.2 Go to step 2
Special requirement
Registration information should be entered correctly
Table 14. Use case description for clients online registration
3.2 Class Diagram

The UML (unified modeling language) class diagram represent the object model, describes the
structure of a system in terms of objects, attributes, associations, and operations. We use class
diagrams to describe the structure of the system. Classes are abstractions that specify the
common structure and behavior of a set of objects. Objects have state that includes the values of
its attributes and its relationships with other objects.
Description of the class diagram in partial:-
27 | P a g e
Class name Attributes Description
Manager Fname,Lname,age,sex,phone, Registration,distributehouse,
Address, generate report
System administrator Lname,Fname,sex,age,phone Manage account:-

number delete,create,update account
Clients Fname, Lname,sex, age, Viewwinner,maintenance,
address, phone number. request
28 | P a g e
*
house clients house distribution
- house no: int -Fname:string -winner name:string
get - block no: int -Lname:string -house number:int
- site:string - ID: int -block:int
-Age: int -map()
-register() -Sex:string
maintenance request() *
create account make
1
1
system Admin
home seeker house manager
1 create account 1
-username:string
Fname:varchar(20) -pass word:string -memberName
* Lname:varchar(20) -manage account()
. -user name:string
view -pass word:string 1
phone:int -create account()
-phone no: int -delete account() -distribute house()
-disable:string -view winner()
E-mail notification generate report()
-register() maintenance
winner recieve
- view winner() -winner *
-winner name:string
name:string
-winner ID:srting require -Fname:string
winner ID:int send notification
-house no:int -Lname:string
-phone:int
-maintenance -sex:string
-message:string -winner name:string
type:string winner ID:int
-send() -winne phone:int
request() -register() house no : int
-print()
Fig 2.Class diagram
29 | P a g e
3.3 Dynamic model
Model is an abstraction of the real world. It deals with the complexity in a current real-
world problem by focusing on the essential and interesting features of an application. The
techniques and associated notation used for object oriented analysis and design in
incorporated in to a standard object – oriented language called unified Modeling language
(UML). An important goal of requirement modeling is come to an understanding of the
use case problem that the new system is to address. This chapter focuses on developing
the requirement and analysis models for the new system using the UML use case model,
sequence diagram, activity diagram, class diagram and interface prototyping are also
included.
3.1.1 Sequence diagram

UML sequence diagrams is a dynamic modeling technique, that shows an interaction between
objects arranged in a time sequence. A sequence diagram aims to represent the detailed object
interaction that occurs for a single use case.
This section of the document consists of sequence diagrams representing the major use case.
They are useful for identifying additional objects that participate in the use cases.
Sequence diagrams show the timing of transaction between object as they occur. It depicts the
interactions between objects during a certain period of time. The interaction proceeds from top to
bottom a vertical timeline, while the horizontal arrows represent messages from one object to
another.
30 | P a g e
Sequence diagram for login
Fig 3. Sequence diagram for login
31 | P a g e
Fig 2 below shows how the system administrator creates his/her account and registers housing
manager and creates account to him (her). After he/she got his/her user name and password he/
she can perform any action allowed to do or specified on the privilege
Fig 4.Sequence diagram for create account
32 | P a g e
Fig 5. Sequence diagram for delete account
Fig 6.Sequence diagram for update account
33 | P a g e
Sequence diagram for distributing house.
Fig 6 below shows the mapping of the winner to the available class. The housing manager login
to the system and make the map the winner randomly to the house type are ask. After make the
mapping post the result to the customer.
Fig 8. Sequence diagram for distributing house.
34 | P a g e
Fig 9. Sequence diagram for manage account.
35 | P a g e
manager generate report: button generate report:controller generate report: generate report
form
click()
activate report cntroller()
display report form()
fill report parameter()

submit report parameter()
submitt formcontent()
validatereport parameter()
invalid parameter acknowledgement() valid parameter generated()
display()
report displayed,yes acknowledgement()
Fig 10 .Sequence diagram for generate report
36 | P a g e
Fig 11.Sequence diagram for online clients’ registration
37 | P a g e
3.1.2 Activity Diagram
An Activity diagram is similar to a flowchart to represent the flow from one activity to
another activity. An Activity diagram focuses on the flow of activities involved in a single
process. The Activity diagram shows how these single-process activities depend on one another.
Fig 12. Activity diagram for Login
38 | P a g e
Fig 13. Activity diagram for Create account
39 | P a g e
Fig 14. Activity diagram for delete account
40 | P a g e
Fig 15. Activity diagram for update account
The above figure shows the updating customer data. The housing manager login to the system
after that searches the required customer then insert new value &Save the updated data.
41 | P a g e
Fig 16. Activity diagram for register clients
42 | P a g e
Fig 14 .below shows the what conditions are seen to manage the accounts of the users i.e. first
login to the system, then click on manage button , then the system provide list of operations
under manager account this includes delete account, create new account& update account. Select
one of them perform action and finally save the result.
login
manage
update
delete
update
create
delete
create fill the form
invalid
valid
save
Fig 17. Activity diagram for manage account.
43 | P a g e
maintenance request
fill the form
invalid
valid
insert email or
phone
send
Fig 18. Activity diagram for maintenance request
Fig 18 above shows how the winners send maintenance request to the housing manager using the
system. This is implemented through Email or phone number.
44 | P a g e
Fig 19.Activity diagram for generate report
45 | P a g e
Open registration form
Fill the form
The input is not true

invalid
vali
d
Register success
Fig 20. Activity Diagram for online registration
3.4 User interface prototyping
Since our project deal on developing a web based condominium management system application, it is
hard to show all single pages which are found within the website, but for the time being we would like to
roughly design of the hyperlinks of website
46 | P a g e
Fig 21.user interface prototyping diagram
47 | P a g e
Chapter four
4. System design
4.1 Introduction
This chapter mainly concerned with the design part of web based condominium house
management and distribution system.
System design is the transformation of the analysis model into a system design model. During
system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams. The result of system design is a
model that includes a clear description of each of these strategies, subsystems and a UML
diagrams representing the hardware/software mapping of the system.
4.2 over view of system design

Systems design is therefore the process of defining and developing systems to satisfy
specified requirements of the user.
Object-oriented analysis and design methods are becoming the most widely used methods for
computer systems design.
There are two types of system design. These are:-
Logical design
The logical design of a system pertains to an abstract representation of the data flows, inputs and
outputs of the system. This is often conducted via modeling, using an over-abstract (and
sometimes graphical) model of the actual system. In the context of systems, designs are included.
Logical design includes entity-relationship diagrams (ER diagrams).
Physical design
The physical design relates to the actual input and output processes of the system. This is
explained in terms of how data is input into a system, how it is verified/authenticated, how it is
48 | P a g e
processed, and how it is displayed. In physical design, the following requirements about the
system are decided.
1. Input requirement,
2. Output requirements,
3. Storage requirements,
4. Processing requirements,
5. System control and backup or recovery.
The physical portion of systems design can generally be broken down into three sub-tasks:
1. User Interface Design

2. Data Design
3. Process Design
User Interface Design is concerned with how users add information to the system and with how
the system presents information back to them. Data Design is concerned with how the data is
represented and stored within the system. Finally, Process Design is concerned with how data
moves through the system, and with how and where it is validated, secured and/or transformed as
it flows into, through and out of the system.
4.3 Design goal

Design goals identify the qualities that our system should focus on. Many designing
goals can be inferred from the requirements of the system. Additionally designing goals are
elicited from the users. It is, however, necessary to state them explicitly such that every
important design decision can be made consistently following the same set criteria. The system
should satisfy the requirements of the user in a technically acceptable level.
The objectives of design are to model the system with high quality. Implementing of high quality
system depend on the nature of design created by the designer. If the system needs repair or
49 | P a g e
rebuilding then the whole process will be dependent on system design, so if the whole system is
designed effectively and precisely then it is easy to make change in the system.
The design goals include:-
Performance criteria:
Performance criteria reflect how the system is expected to behave under normal operating
condition. This includes the throughput and memory requirement of the system.
Dependability criteria
These criteria determine how much effort should be expanded in minimizing system crashes and
their consequence, and how available the system should.
Reliability: The system is expected to accept inputs and requests from the user and make the
necessary execution. The systems accept all valid user data and produce the expected output.
Fault tolerance: Fault may originate in a system level, in the system environment, or in the
interaction between user and the system. Some of the faults that may occur include: computer
failure, system failure due to virus, unauthorized user. The system tolerate the error occur due to
user-system interaction using proper execution handling methods.
Maintenance criteria
Maintenance criteria highlights how new functionalities can be added to the system in the future.
Modifiability: The system should be modifiability to modify different services depending on the
need of the institute.
Portability: The system works in different plat form and operating system.
Readability: The code will be easily readable and understandable by other programmers. To
achieve this goal we will supplement the code by proper naming convention, proper indentation
and comment.
Efficiency: The system must do what it is supposed to do efficiently without the problem.
50 | P a g e
4.4 Proposed Software Architecture
Here we design the conceptual model for the proposed system that describes the relationship
major participant in the condominium distribution and management system.
There is a client and the house manager who would like to use a computerized condominium
distribution and management service.
The house manager provides the necessary technical and financial infrastructure to facilitate
computerized condominium distribution and management system.
Condominium Distribution and Management system architecture: The proposed software
has the following layers of architecture. These are
Interface: There are two categories of interface class – user interface (UI) classes that provide
people access to your system and system interface (SI) classes that provide access to external
systems to your system.
Domain: This layer implements the concepts relevant to our business domain, focusing on the
data aspects of the business objects, plus behaviors specific to individual objects.
Process: The process layer implements logical system that involves collaborating with several
domain (system) classes or even other process classes in the system.
Persistence (data): Persistence layers encapsulate the capability to store, receive and delete
Objects/data permanently without revealing details of the system.

System: System classes provide operating-system-specific functionality for the applications,
isolating the software from the operating system (OS) by wrapping OS-specific features,
increasing the portability of the application
51 | P a g e
Fig 22. System architecture for Condominium Distribution and Management system
4.5 Hard ware and Software mapping

WSU Condominium management and distribution system is a web base application. Hardware
and software architecture mapping (deployment diagram) is used to show the hardware of the
system, the software that is installed in the hardware and also the middleware that is used to
connect the dissimilar machines to one and other. It also shows how the software and the
hardware components work together in order perform the task.
52 | P a g e
The diagram below shows the hardware/software mapping of CDMS.
Fig 23. Hardware/Software Mapping for WSU CMDS (deployment diagram)
4.6 persistent data management

The persistent data that must be stored in the database for future use with their data type and their
domain. Persistent data management deals with how persistent data (file, database) are stored
and managed. Persistence is the ability of an object to survive the lifetime of the OS process in
53 | P a g e
which it resides. Persistence is relevant for objects with an internal state. The state needs to be
retained between object deactivation and object activation.
Persistent objects are stored in a persistence mechanism. The Development Team identifies
tables that are present in the Data Base for describing the data stored on the database. Tables are
related to each through their primary and foreign key. Also each Table has Attribute with
compatible Data type.
Fig 24. persistence data management diagram
54 | P a g e
4.6.1 Access control and security (ACL and security)
Access control and security describes the user model of the system in terms of access matrix.
When the house manager wants to register, distribute house, generate report, send notification, it
needs authentication authentication mechanism.
User role Module and components
Send View Online Maintenanc

notificatio Generat Manag winne
House registratio e request
n r
e report e
registratio n
accoun
n
t
Administrato no no no yes no no no
r
House yes yes yes no yes no no
manager
clients no no no no yes yes yes
4.6.1 Data base design

Database design is transforming an E-R model and their data specifications design into a
normalized relation. Well-structured relation corresponds to records that contain a minimum
amount of redundancy and allows users to insert, modify and delete the rows without errors or
inconsistencies. It is the process of converting complex data structures into simple, stable data
structures using a process called normalization.
55 | P a g e
Fig 25. DB diagram
56 | P a g e
4.6.2 ER diagram
An entity relationship diagram is a specialized graphics that illustrate the interrelationship
between entities in a database. Here diagrams always use symbols to represent different types of
information.
Fig 26. ER diagram
57 | P a g e
4.7 user interface design
The goal of user interface design is to make the user interaction as simple and efficient as
possible in terms of accomplishing user goals that is known as user-center design
58 | P a g e
Fig 27.Home page user interface design
Fig 28. Login use interface page
59 | P a g e
60 | P a g e
Fig 29.Manage user account interface page
Fig 30. Clients registration form
61 | P a g e
Chapter Five: Implementation and Testing
5.1 Introduction
In this chapter we mainly focuses on the implementation part, implementation concerned with
the type of material (Hardware and software required), techniques to develop the system,
algorithm for the system, code samples of the system, data preparation, how to install the system,
some testing techniques, start up strategy for the new installed system are briefly described in
this part of documentation.
5.2.Final Testing of the system
The sample codes for testing the system is as follows.
The sample code for client registration form is:-

<?php
if(isset($_POST['ok'])){
$id=$_POST["id"];
$fname=$_POST["fname"];
$mname=$_POST["mname"];
$lname=$_POST["lname"];
$date=$_POST["date"];
$gender=$_POST["gender"];
$marriage=$_POST["marriage"];
$yofservice=$_POST["yofservice"];
$phone=$_POST["phone"];
62 | P a g e
$zone=$_POST["zone"];
$job=$_POST["job"];
$disable=$_POST["disable"];
$mysql_qry="insert into cregistration ( id, fname, mname, lname, date, gender, marriage,
yofservice, phone, zone, job,disable)
values( '$id','$fname', '$mname', '$lname', '$date', '$gender', '$marriage', '$yofservice', '$phone',

'$zone', '$job','$disable')";
if ($conn->query($mysql_qry)===TRUE){
echo' <meta content="10;cregistration.php" http-equiv="refresh" />';
echo "insert seccessfully";
else {
echo "error:".$mysql_qry . "</br>" . $conn->error;
$conn->close();
?>
<table>
<tr>
<td>
<form action ="cregistration.php" method="post">
63 | P a g e
<div id="wb_Text15">
<span><strong>
User_Id:</strong></span>    &nbsp
<input type="text" id="Editbox7" name="id" value="" required="required"><br>
<div id="wb_Text1">
<span ><strong>    First Name

:</strong></span>
<input type="text" id="Editbox1"name="fname" value="" required="required" pattern="[A-Za-

zÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿ]*$">
<div id="wb_Text2">
<span><strong>Middel Name</strong></span><span>
<strong>:</strong></span>
<input type="text" id="Editbox2"name="mname" value="" required="required" pattern="[A-Za-

<div id="wb_Text3">
<span><strong>   Last Name:</strong></span>

<input type="text" id="Editbox3" name="lname" value="" required="required" pattern="[A-Za-

<div id="wb_Text4">
<span><strong>     Birthdate:</strong></span>

<select name="date" size="1" id="Combobox3" required="required">
<option>01</option>
<option>02</option>
<option>03</option>
<option>04</option>
64 | P a g e
<option>05</option>
<option>06</option>
<option>07</option>
<option>08</option>
<option>09</option>
<option>10</option>
<option>11</option>
<option>12</option>
<option>13</option>
<option>14</option>
<option>15</option>
<option>16</option>
<option>17</option>
<option>18</option>
<option>19</option>
<option>20</option>
<option>21</option>
<option>22</option>
<option>23</option>
<option>24</option>
<option>25</option>
<option>26</option>
<option>27</option>
<option>28</option>
<option>29</option>
65 | P a g e
<option>30</option>
</select>
<select name="month" size="1" id="Combobox12">
<option>01</option>
<option>02</option>
<option>03</option>
<option>04</option>
<option>05</option>
<option>06</option>
<option>07</option>
<option>08</option>
<option>09</option>
<option>10</option>
<option>11</option>
<option>12</option>
</select>
<select name="year" size="1" id="Combobox6">
<option>1920</option>
66 | P a g e
67 | P a g e
68 | P a g e
69 | P a g e
</select>
<div id="wb_Text5">
70 | P a g e
<span><strong>        Gender:</strong></s
pan>
<select name="gender" size="1" id="Combobox1">
<option>select</option>
<option>Male</option>
<option>Female</option>
</select>
<span><strong>Marital status:</strong></span>
<select name="marriage" size="1" id="Combobox4">
<option>Single</option>
<option>Married</option>
</select>
<span><strong>Year of service:</strong></span>
<select name="yofservice" size="1" id="Combobox4">
<option>two year</option>
<option>three year</option>
71 | P a g e
<option>four year</option>
<option>five year</option>
<option>six year</option>
<option>seven year</option>
<option>eight year</option>
<option>nine year</option>
<option>ten year</option>
</select>
<span><strong>       Phone
No:</strong></span>
<input type="text" id="Editbox4" name="phone" value="+251" maxlength="13"

required="required">
<input type="text" id="Editbox5" name="number" value="" maxlength="9"

required="required" pattern="[0-9-]*$">
<div id="wb_Text6">
72 | P a g e
</select>
<div id="wb_Text8">
<span><strong>
Zone:</strong></span>
<select name="zone" size="1" id="Combobox2">
<option>Wolaita</option>
</select>
<div id="wb_Text9">
<span><strong>Acadamic Level:</strong></span>
<select name="job" size="1" id="Combobox8">
<option>professors</option>
<option>doctors</option>
<option>lectures</option>
<option>assistants</option>
</select>
</select>
73 | P a g e
<span><strong>Disable:</strong></span>

<select name="disable" size="1" id="Combobox11">
<option>No</option>
<option>Yes</option>
</select>
</select>
Sample code for Login :-


<?php
if (isset($_POST['submit']))
$username=$_POST['user'];
$password=$_POST['pass'];
$sql ="SELECT * FROM user WHERE username='$username' AND

password='$password'";
$result = mysql_query($sql);
// TO check that at least one row was returned
$rowCheck = mysql_num_rows($result);
74 | P a g e
$row=mysql_fetch_array($result);
if($row['user_type']=='hm'){
$_SESSION['user_id']=$row['user_id'];
echo "<script>window.location='hm.php';</script>";
else if($row['user_type']=='client'){
echo "<script>window.location='client.php';</script>";
else if($row['user_type']=='admin'){
echo "<script>window.location='Sadmin.php';</script>";
else {
echo'<br>';
echo' <p class="wrong">Check Your username or/and Password!</p>';
echo' <meta content="10;login.php" http-equiv="refresh" />';
mysql_close($conn);
?>
75 | P a g e

<form action="login.php" method="POST">
<center><table style='border:40px solid pink;border-radius:12px;box-shadow:1px 1px

20px #000000;width:1000px height:800px'>
<tr>
<td colspan='2' bgcolor="red" style='text-align:center;'><font color='#ffffff'>Users

login</font></td>
</td>
</tr>
<tr>
<td>Username</td><td><input type='text' name='user' required></td>
</tr>
<tr>
<td>Password</td><td><input type='password' name='pass' required></td>
</tr>
<tr>
<td></td><td><input type='submit' name='submit' value='Login'></td>
</tr>
<tr>
</tr>
</table></center>
</form>
76 | P a g e
<br>
<a href="creacount.php">click here to create account</a></u></td>
</center>
Sample code for post notification :-
<?php
if(isset($_POST['ok'])){
$id=$_POST["id"];
$title_name=$_POST["title_name"];
$post_date=$_POST["post_date"];
$end_date=$_POST["end_date"];
$email=$_POST["email"];
$mysql_qry="insert into post( id, title_name, post_date, end_date, email)
values( '$id','$title_name', '$post_date', '$end_date', '$email')";
if ($conn->query($mysql_qry)===TRUE){
echo' <meta content="10;post.php" http-equiv="refresh" />';
echo "posted seccessfully";
else {
echo "error:".$mysql_qry . "</br>" . $conn->error;
$conn->close();
77 | P a g e
?>
<div id="apDiv9">
<h2 align="center" class="style3">Post notification Form </h2>

<form id="form1" name="form1" method="post" action="post.php" onsubmit="return

Validate() ;">
<p> </p>
<table align="center" width="500" height="341" border="0" bgcolor="white">
<tr>
<td><label>Client ID</label> </td>
<td><input type="text" id="Editbox5" name="id" value="" maxlength="9"

required="required" pattern="[0-9-]*$">
<tr>
<td><label></label>
<tr><td>Title Name</td><td><textarea cols='30px' rows='4px' name='title_name'

required x-moz-errormessage="Enter tittle Here!" ></textarea></td></tr>
</tr>
<tr>
78 | P a g e
<td><label>Post Date</label> </td>
<td><input type="date" name="post_date" /></td>
<td colspan="2"> </td>
<td> </td>
</tr>
<tr>
<td>End of Date</td>
<td><input type="date" name="end_date" /></td>
<td colspan="2"> </td>
<td> </td>
</tr>
<tr><td>E_mail Address</td><td><textarea cols='18px' rows='1px' name='email'

required x-moz-errormessage="Enter tittle Here!" ></textarea></td></tr>
</tr>
<tr>
<td width="114"> </td>
<td width="79"><input type="submit" name="ok" value="Post " /></td>
<td><input type="reset" name="Submit2" value=" Clear " /></td>
</tr>
</table>
</form>
</div>
79 | P a g e
</div>
<div id="accounts">
<ul>
</ul>
</div>
</div>
5.3 Hardware software acquisitions

For the proper functioning of the system the following hardware and software are
required
Hardware’s includes:-
 Computer
 CD/DVD disk
 Flash disk
Software’s includes
 Wamp server
80 | P a g e
 Internet explorer, Mozila Firefox, google.baidu.
 Adobe dream weaver CS5,notpade++
5.4 User manual preparation
Steps1
 Activate wamp server from the Desktop or Start up Menu if it’s not
activated.
Click on start - >wamp server
Then Click on “Hide these window and start server” Button
81 | P a g e
Step2
 From the start menu click on start->All programAccessories Run
Steps3
 In the run Dialog box type the URL of the page (example
http://localhost/hrm/Home.php) and theclick“OK”button
82 | P a g e
After the application have been installed and tested the system is ready to be functional and then
preparation could begin to place the new system in to operation. Hence, in order the new system
to be operational the new system should be loaded with the existing data from the old system.
The start-up strategy used is parallel conversion strategy, means the old system and the new
system will operate simultaneously for some time, because the defect of the new system will be
identified if any, before the old system is abandoned and until get user acceptance
5.5 Training
Before have starting the project in first semester, we have try to gather information about the
WSU condominium house. In this manner we asked the condominium committee about the
house and they gives some manual about the house. Among the committees Mr.Demmisse and
Mr. kedir tells some informations us about condominium house progress.
5.6 Installation Process

After installing both Adobe Dreamweaver and wamp server software do the following steps
Step1
 Get the folder “Final project “from the Developing Team.
Step 2
 Copy the folder to WWW folder in the c: \wamp\www
After doing these steps again, copy the folder “Condominium management system data” from
the Developing Team then.
83 | P a g e
Step3
 Paste into the folder ”data “in the C: \Wamp\www\Data
Step4.Installation is finished.
Chapter Six: Conclusions and Recommendation
6.1 Conclusions
An effort has been made to study condominium management of WolaitaSodo University as
partial fulfillment of BSc degree in computer science and information Technology. In doing the
study the team has tried to follow object oriented system analysis and design methodology.
Since the success and failure of any system depends on gathering the right information through
different fact-finding techniques and user involvements, the team has made a good effort to
gather requirements. After a detail review and study of the existing system of CMS models have
been designed to reflect the new system that is suppose to solve problems.
Designing computerized condominium management system for WSU helps to maintain a

computer based CMS.
In order to solve different problems existed the team has tried to propose a solution that at
least reduce the existed problems and model the proposed system using different tools and
methodologies. We believe that different tools and techniques has helped us a lot in capturing
real user requirements and model the right system for the users for their day to day
transactions. Thus it should have the precedence in know-how and experience in collecting,
processing and utilizing information.
6.2 Recommendations
As its obvious the use of and advantage of computerized systems over manual information
systems, we strongly recommend Wolaita Sodo University condominium management system to
implement our new system in order to achieve capabilities like reliable data keeping ,fast data
processing and transmissions.
84 | P a g e
Appendix
HTML-----------------------------Hypertext Markup Language
PHP--------------------------------Hypertext pre Processor
SQL--------------------------------Structural Quire Language
CSS--------------------------------Cascade Style Sheet
PC----------------------------------Personal Computer
MS Word--------------------------Micro Soft Word
CD----------------------------------Compact Disk
UC----------------------------------Use Case
WSU--------------------------------Wolaita Soddo University
UML--------------------------------Unified Modeling Language
CDM--------------------------------Condominium Management System
XML--------------------------------Extensible Markup Language
ER-----------------------------------Entity Relation
DB-----------------------------------Data Base
References
1. http://www.condominium management system.pdf
85 | P a g e
2. Applying UML and patterns: An object- oriented analysis and design and the unified process
(second edition) as reference.
3. Condominium Management Education Programs and Courses
86 | P a g e

Sprache

Willkommen bei Scribd!

document

Hochgeladen von

Dokumentinformationen

Beschreibung:

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

document

Hochgeladen von

Beschreibung:

Copyright:

Verwandte Titel

SCHOOL OF INFORMATICS

DEPARTMENT OF INFORMATION TECHNOLOGY

Submission Date: 26/02/2008

Fig 3. Sequence diagram for login.............................................................................................................30

HTML-----------------------------Hypertext Markup Language

PHP--------------------------------Hypertext pre Processor

SQL--------------------------------Structural Quire Language

CSS--------------------------------Cascade Style Sheet

MS Word--------------------------Micro Soft Word

WSU--------------------------------Wolaita Soddo University

UML--------------------------------Unified Modeling Language

CDM--------------------------------Condominium Management System

XML--------------------------------Extensible Markup Language

2. Statement of the problem

 There is wastage of vast amount of human power.

Project tittle Condominium management system for WSU

4.Ribika G/Michael 422/05 0927160075 System analysis

Abebayitu Yihun 027/04 0923043247 DB interface

Advisor Mr. Siraj Sebhatu

5. Specific Objective of the project

 To store the data’s of the applicants into the database.

5.1 Significance of the project

6. Limitation of the project

7. Scope of the project

8.1 Technical feasibility

8.2 Scheduling feasibility

8.3 Operational feasibility

9.1 Fact finding techniques

System analysis and design approaches

9.2 Data sources

9.3 Development tools

Software tool requirements

10. Required resources with cost

SYSTEM REQUIREMENT SPECIFICATION (SRS)

2.1 Description of the existing system

2.1.1Players in existing system

2.1.2 Major functions /Activities in current system

- Year of service, Job responsibility, Academic levels, Marriage status etc.

-transferring the house to another person is impossible.

2.1.4 Report generated in the existing system

2.1.5Forms and other documents in existing system

 Efficiency (well-organize):- The existing system is not fully efficient by structurally.

Because there will be:

-no network service in the existing system

-there is no training about the system

-there is no well-organized structure about the existing system

- The guide lines are not put structurally.

2.2 Description of the proposed system

 The new system will be web based or automated system.

 The system will come up with updated information contents

2.2.1 Requirements of the proposed system

2.2.2 Functional Requirements

 Login: - to identify the authorized person to use the system.

 The system doesn’t have any commercial bank relationship. Etc.

3.1 Use Case Diagram

notification account account

Fig 1 .Use case diagram

3.1.1 Actor specification

Condominium management System Actors

Condominium management System Use Case Listing

3.1.2 Use case Description