WACHEMO UNIVERSITY

COLLEGE OF ENGINEERING AND TECHNOLOGY

SCHOOL OF COMPUTING AND INFORMATICS
DEPARTMENT OF SOFTWARE ENGINEERING
DEPARTMENT OF SOFTWARE ENGINEERING
SENIOR PROJECT SUBMITTED FOR THE PARTIAL
FULFILLMENT OF DEGREE PROGRAM AT DEPARTMENT
OF SOFTWARE ENGINEERING
Title:WCU ONLINE CONDOMINIUM HOUSE MGMT
SYSTEM
Prepared by: Group
NAME ID.NO
1. SENBETO MEGERSA………………………004713

2. ANDUALEM LEGESA………………………004687

3. NURADIN HUSEN……………………………00899

ADVISOR MR. FIKIRAB LOPISO.

SUBMISSION DATE: March 10, 2022.G.C

Approval of advisors and examiners
Submitted by

1. Senbato Megersa ___________ ___________

(Student) Signature Date
2. Andualem Legesa ____________ ___________
(Student) Signature Date
3. Nuradin Husen ____________ ___________
(Student) Signature Date

Approved by
Fikirab Lopiso: _____________ __________
(Advisor) Signature Date

i|Page
 Declaration

This is to confirm that the project report entitled WCU Condominium House Management
System submitted to Wachemo University, college of computing and informatics department of
Software Engineering in partial fulfillment of the requirement for the award of the degree of
Bachelor of Science in Software Engineering is an original work carried out by Senbato
Megersa, Andualem Legesa, and Nuradin Husen. The matter embodied in this project is reliable
and is genuine work done by the group and has not been submitted whether to this University or
any other University/Institute for the fulfillment of the requirement of any study.

Declared by:

Senbato Megersa __________________ _________________

Student Signature Date

Andualem Legesa ___________________ _________________

Student Signature Date

Nuradin Husen___________________ _________________

Student Signature Date

Confirmed by advisor:

Mr. Fikirab Lopiso

Name: ___________________

Signature: ___________________

Date: ___________________

Place and date of submission: Hossana, June

ii | P a g e
 Acknowledgement
First of all, we would like to thank our God, who gives us love, patience, healthy, wisdom
and ability to walk through all the problems and obstacles during the period of our study. Then
we would like to thank our advisor, instructor Fikerab Lopiso for her constructive opinion and
willingness to participate in each part of our project and her effective direction, assistance and
guidance for the accomplishing of this project. who gave us the required information about the
office. Finally we would like to express love, thanks, appreciation, and respect to our families
and friend. Also we would like to thank the teaching staffs of Software Engineering who have
contributed wholly to the success of this project.

iii | P a g e
Contents Page
Approval of advisors and examiners ...........................................................................................................i
Declaration...................................................................................................................................................ii
Acknowledgement......................................................................................................................................iii
List of Tables..............................................................................................................................................vii
List of Figures...........................................................................................................................................viii
CHAPTER ONE.......................................................................................................................................xiv
1. INTRODUCTION.................................................................................................................................xiv
1.1. BACKGROUND.............................................................................................................................xv
1.2 STATEMENT OF THE PROBLEM...............................................................................................xvi
1.3 Purpose of the project......................................................................................................................xvi
1.4. Team composition..........................................................................................................................xvi
1.5 OBJECTIVES OF THE PROJECT................................................................................................xvii
1.5.1. General Objective.......................................................................................................xvii
1.5.2 Specific objectives.......................................................................................................xvii
1.5 Feasibility Study.............................................................................................................................xvii
1.5.1 Economic Feasibility..................................................................................................................xviii
1.5.2 Technical Feasibility.....................................................................................................................xix
1.5.3 Operational feasibility..................................................................................................................xix
1.6. Scope and Limitation of the project.....................................................................................................xx
1.6.1 Scope of the project.......................................................................................................................xx
1.6.2 Limitation of the project................................................................................................................xx
1.7 Significance of the project...............................................................................................................xxi
1.9. Methodology..................................................................................................................................xxi
1.9.1 Requirements gathering techniques.............................................................................xxii
1.9.2 Development tools.......................................................................................................................xxii
1.9.2.1 Hardware Tools........................................................................................................xxii
1.9.2.2 Software Tools.........................................................................................................xxii
1.9.3Testing Procedure........................................................................................................................xxiii
1.9.3.1 Unit testing..............................................................................................................xxiii

iv | P a g e
 1.9.3.2 Integration testing....................................................................................................xxiii
1.10 Overview of Project Phases.........................................................................................................xxiv
1.11 Task and schedule.........................................................................................................................xxv
1.11.1 Time Plan...................................................................................................................xxv
1.11.2 Budget plan...............................................................................................................................xxvi
Chapter two............................................................................................................................................xxvii
2. Description of the existing system......................................................................................................xxvii
2.1. Major function of the current system..........................................................................................xxviii
2.2. Users of the current system.........................................................................................................xxviii
2.3. Drawback of the current system....................................................................................................xxix
2.4. Business rule of the current system...............................................................................................xxix
2.5. Alternative solutions......................................................................................................................xxx
Chapter three............................................................................................................................................xxx
Proposed system.......................................................................................................................................xxx
3.1. Functional requirement..................................................................................................................xxx
3.2. Non-functional requirement.........................................................................................................xxxii
3.3. System model..............................................................................................................................xxxii
3.3.1. Scenario...................................................................................................................................xxxiii
3.3.2. Use case model.........................................................................................................................xxxv
3.3.3. Use case description...............................................................................................................xxxviii
3.4. Object Model...................................................................................................................................liv
3.4.1. Data dictionary.............................................................................................................................liv
3.4.2. Class diagram................................................................................................................................lv
3.5. Dynamic model..............................................................................................................lvii
3.5.1. Sequence diagram........................................................................................................................lvii
3.5.2. Activity diagram.........................................................................................................................lxiii
3.5.3. State diagram............................................................................................................................lxxiv
\...............................................................................................................................................................lxxvi
CHAPTER FOUR.................................................................................................................................lxxvii
SYSTEM DESIGN................................................................................................................................lxxvii
4.1. Purpose.......................................................................................................................................lxxvii

v|Page
 4.2. Design goal.................................................................................................................................lxxvii
4.2.1 Performance Criteria:...............................................................................................lxxvii
4.2.2. Dependability Criteria............................................................................................lxxviii
4.2.3. Maintenance Criteria..............................................................................................lxxviii
4.2.4. End-user criteria.....................................................................................................lxxviii
4.2.5. Priorities of Design goal...........................................................................................lxxix
CHAPTER FIVE....................................................................................................................................lxxxi
PROPOSED SYSTEM (ARCHITECTURE)..........................................................................................lxxxi
5.1. High-level design: describe the system architecture.....................................................................lxxxi
5.2. Scenario view:.............................................................................................................................lxxxii
5.3. Process view ..............................................................................................................................lxxxiii
5.4. Development view.....................................................................................................................lxxxiv
5.4.1. Subsystem Decomposition......................................................................................................lxxxiv
5.4.2. Subsystem description..............................................................................................................lxxxv
5.5.1 Physical view (Hardware /software Mapping)..........................................................................lxxxv
5.6. Persistent data management.......................................................................................................lxxxvi
5.6.1. Data schema view...................................................................................................lxxxvi
5.6.2. Mapping class to table. (In case of using relational DBMS)...............................lxxxviii
Mapping with Normalization...........................................................................................................lxxxviii
5.7. Access control:............................................................................................................................xcviii
5.8.User interface model:........................................................................................................................xcix

vi | P a g e
List of Tables
Table 1 . Team composition........................................................................................................xvii
Table 2 . PERT Table..................................................................................................................xxv
Table 3 . Use Case Description for Login.............................................................................xxxviii
Table 4 . Use Case Description for Create Account...............................................................xxxix
Table 5 . Use Case Description for View Account........................................................................xl
Table 6 .Use Case Description for Update an Account..............................................................xlii
Table 7 . Use Case Description Register Applicant online.....................................................xliii
Table 8 . Use Case Description for Manage Applicant.............................................................xliv
Table 9 . Use Case description to send notification................................................................xlvi
Table 10 . Use case description to manage information.........................................................xlvi
Table 11 .Use case description for view information..............................................................xlix
Table 12 . Use case description for View notification..................................................................l
Table 13 .Use case description for giving comment....................................................................li
Table 14 . Use case description to create account......................................................................lii
Table 15 . Use Case Description for Register finished house..................................................liii
Table 16 .Condominium House Admin Data Dictionary............................................................liv
Table 17 .Distribute Committee Data Dictionary........................................................................liv
Table 18 .WCU Finance Office Data Dictionary........................................................................liv
Table 19 .Applicant Data Dictionary.............................................................................................lv
Table 20 . access control...........................................................................................................xcix

vii | P a g e
List of Figures
Figure 1 .Time plan....................................................................................................................xxv
Figure 2 . Use Case Diagram.................................................................................................xxxvii
Figure 3 . Class Diagram.............................................................................................................lvi
Figure 4 . Sequence Diagram for Login...................................................................................lviii
Figure 5 . Sequence Diagram for Register Finished House.....................................................lix

viii | P a g e
 Figure 6 .Sequence diagram for sending notification........................................................lx

ix | P a g e
 Figure 8 .Sequence diagram for search applicant information........................................lxi
Figure 9 . Sequence diagram for registering applicant...........................................................lxii
Figure 10 .Sequence diagram for payment.............................................................................lxiii
Figure 11 .Activity Diagrams for Login.....................................................................................lxiv
Figure 12 .Activity Diagram for a registered applicant. .lxvi
Figure 13 .Activity diagram for updating applicant information .......................................lxvii
Figure 14 . Activity diagram for Delete applicant information...........................................lxviii
Figure 15 . Activity diagram for sending Notification............................................................lxix

x|Page
Figure 16 .Activity diagram for View comment.....................................................................lxix
Figure 17 .Activity diagram for creating an account..............................................................lxx
Figure 18 .Activity diagram for payment................................................................................lxxi
Figure 19 .Activity diagram for post information lxxii
Figure 20 .Activity diagram for logout..................................................................................lxxiii
Figure 21 .State Diagrams for Login.............................................................lxxiv
Figure 22 .State Diagrams for Registration..............................................................................lxxv
Figure 23 . State Diagram for Create Account.........................................................................lxxv
Figure 24 .State Diagrams for House Registrations...............................................................lxxvi
Figure 25 . Scenario View of the system..............................................................................lxxxiii
Figure 26 .sub system decomposition....................................................................................lxxxv
Figure 27 .Hardware and software architecture mapping................................................lxxxvi
Figure 28 .Data schema view of the system..........................................................................lxxxvii
Figure 29 .Mapping class....................................................................................................lxxxviii
Figure 30 . mapping for normalization..................................................................................xcvii
Figure 31 .Relationship mapping..........................................................................................xcviii

Abbreviation lists Meaning

CHMS------------------------------------------------Condominium Housing Management System

DB: ----------------------------------------------------Database

SQL----------------------------------------------------Structural Query Language

UC----------------------------------------------------- Use Case

ID------------------------------------------------------Identification number

SW/HW----------------------------------------------- Software and Hardware

xi | P a g e
PC------------------------------------------------------Personal Computer

Fig------------------------------------------------------ Figure

CRC---------------------------------------------------Class Responsibility Collaboration

UI------------------------------------------------------- User Interface

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

xii | P a g e
 Abstract

This project document deals with online condominium house management system
development specifically project proposal system analysis, design, and implementation
methodology and partial conclusion and recommendation of full online condominium house
management system. Our propose system maintain necessary information of the Wachemo
University housing development agency. Online condominium house management system
mainly provides effective and fast data processing, registration, notification, and placement. This
web-based system of managing applicant house information in house development agency
setting is expected to help various services keep an updated data on the status of their
information. In designing and analyzing such a system, object-oriented designing and analysis
tool and technique has been employed. Generally, the main goal of online condominium house
management system is to shorten data-processing time, to reduce errors, to improve the accuracy
of input and to provide data reliability of the information and to change the manual data handling
system into automated system.

xiii | P a g e
 Chapter one
1. Introduction
Now a day, most people are having familiarity with computer and computer based
applications. Many organizations and individuals have their computer based applications for the
purpose of running their business, to perform different activity.Currently, the condominium
management office process data manually, and this manual processing system has many
drawbacks. After completion the project is expected to solve the problems that are affecting the
WCU condominium housing development offices. Since it is an online system it will reduces
costs, time to travel to the offices, work overload and it also minimizes the space used to store
the data. Besides, it enables applicants online registration, search, update applicants’ data,
placement and register finished houses.

1.1. Background
Hossana Town is located in Southern part of Ethiopia, in SNNP Regional State, hadiya Zon
e, at a distance 230 km from Addis Ababa. In Hossana Town the population growth is increasing
day to day that means different branch offices are opened like Wachemo University, this universi
ty other company’s needs employees and teachers to work in their company and these employees
need house to serve their life. .The Ethiopian government is trying to solve shortage of house for
the low-income community living in the urban area. One solution for this shortage program is
condominium housing development project. Condominium housing is the name given to the
forms of housing contract when each applicant can get house by applying and registering to the
office.

1.2. Statement of the problem

Currently, the office is using a manual handling system in its day-to-day activities which
has many problems. These problems are:-
 The problem in distributing condominium house:-Since they do it manually it’s
difficult to know the occupied class and unoccupied class surely.

1|Page
  The problem in management:-since there is a lot of documents in the office it’s hard to
manage such huge data manually.
 Data Redundancy:-Since there is no organized database there is a problem of giving
more than one house for a single person.
 Lack of accuracy and loss of document:-Since registration is handled manually there is
the chance of getting two houses for a single family like husband and wife and also loss
of applicant and contractor data.
 Lack of security:-Since the office uses a manual system, the mechanism of data
handling is unsecured.
 They need a large number of human resources to process office jobs.
 The manual lottery system is error-prone, vulnerable to corruption.

1.3 Purpose of the project

The main purpose of this project is to develop and implement a web-based application
entitled “Online Condominium House management system” to help applicant get reliable
services.
To achieve the following objectives:
 Identifying problems of the Existing System to design the new system.
 Designing database system for Online Condominium House management system.
 Design interactive user interface for Online Condominium House management system.
 Test and evaluate the performance of the system.

1.4. Team composition

Each group member has their own responsibility to complete the CHMS project
successfully. We are three in number. Our group members are just working together to
achieve this project in a good manner by playing our best role on this project. Our
responsibilities are stated in the table below:-

2|Page
Table 1.Team composition

NO Group Member Responsibility

1 Nuredin Husen Leader and system designer
2 Andualem Legase System analysis and tester
3 Senbeto Megersa System analysis and
programmer

1.5. Objectives of the project

In this project, we can specify the objective of the project as general objective and specific
objective.

1.5.1. General Objective

The aim of this project is to develop a web-based online condominium house management
system for the Wachemo University community.

1.5.2. Specific objectives

 To study the existing system of the residential building distribution system of WCU.

 To identify problems with the existing system in the organization.

 To propose alternative solutions and select the best among the alternatives to the
identified problem.

 To identify functional and non-functional requirements

 To design the proposed system.

 To design a user-friendly interface

 To design a relational database for the proposed system

 To implement the proposed system in an efficient way.

 To test the proposed model.

3|Page
1.6. Feasibility study
Most Software Engineering projects have budgets and deadlines, and analysis of factors
for the feasibility forms the business case (analysis of assumptions like resource availability and
potential problem and system costs and benefits) that justifies the expenditure on the project.
Our system feasibility will be seen according to the following literal:

1.6.1. Economic feasibility

Our proposed system was justified by cost and benefit. Criteria to ensure that effort is
concentrated on the project, which will give best, return at the earliest. One of the factors, which
affect the development of a new system, is the cost it would require. The following are some of
the important financial questions that were asked during the preliminary investigation:
 The costs conduct a full system investigation.
 The cost of the hardware and software.
 The benefits are in the form of reduced costs or fewer costly errors. By conducting a
cost-benefit analysis we found that our proposed system is economically feasible due to
the factor of cost and benefit and their relationship. Our team has analyzed by identifying
tangible and intangible costs needed for system development.

By conducting a cost-benefit analysis, we will find that our proposed system is economically
feasible due to the factor of cost and benefit and their relationship. Our team will analyze by
identifying tangible and intangible costs needed for system development.
 Tangible Benefits:
We will calculate the corresponding tangible benefits with sample monetary.
Cost reduction:-To calculate the following things must be considered.
Total Number of an employee of the project office in existing system=6
The average salary of each employee per month=4500.00birr
Total money required for payment per year=6*4500*12=324,000.00birr
The average number of employees needed when the new system will be deployed=1
Salary per month=5000birr
Total money required for payment per year=1*5000*12=60,000.00birr.
Difference between before and after deployment money required for payment

4|Page
 Cost Reduction and Avoidance=324,000-60,000=264,000.00birr
As a result, our project is economically feasible because it can decrease an amount of
264,000birr.
 Intangible Costs
Those are uncountable costs. The intangible costs to will be acquired in developing the
system are:-
 Human Knowledge: Our knowledge that we will spend to develop the system may not
be measurable in terms of money.

1.6.2 .Technical Feasibility

Our proposed system will be evaluated from a technical point of view. The assessment of
this feasibility must be based on an outline design of the system requirement in the terms of
input, output, programs, and procedures. Having identified an outline system, the investigation
must go on to suggest the type of equipment, required method developing the system, of
running the system once it will be designed.
Technical issues that will raise during the investigation are:
 Does the existing technology sufficient for the suggested one?
 Can the system expand if developed?
Through the technology may become outdated after some time, because a new version of the
same software supports older versions, the system may be used for the longer future. So there
are minimal constraints in this project, and it, in turn, indicates that the solution is technically
feasible.

1.6.3. Operational feasibility

It determines how the proposed system will satisfy the need of Wachemo university's
academic staff workers, lecturers, and it also offers a secure, accurate, and efficient system to
the organization. The system which we are going to develop will also be compatible with all
operating systems and web browsers.
By conducting an operational feasibility study we examine whether the new project will attain
its desired objective, we also understand the degree to which the proposed system will likely
solve the problems so in this study we will identify that operational feasible that the system is
user-friendly, easy to access. It can be run in any operating system.

5|Page
1.7. Scope and Limitation of the project
1.7.1 Scope of the project
Scope of the system identifies the problem to be studied, analyzed, designed, constructed
and ultimately improved. It is specifically concerned with what problem the proposed system
addresses. The system focuses on condominium house management system for the Wachemo
University community and will perform the following activities:
 Online Registration of applicants:- The proposed system will register all the
applicant information that is used to get the condominium house.
 Register Finished Condominium houses:-Will register the finished condominium
houses that are found on different sites. Besides, it will help to know the number of the
applicant relative to the number of finished condominium houses.
 Update Applicant’s Data: It will update the applicant information when needed.
 Search Applicant’s Data: It will search applicant data within a short period.
 Notification: The system will give notifications to the users.
 Clearance: The users must clear when they will go out of the house.
 Maintenance: The users can request maintenance and necessary services will be given
to them.

1.7.2 Limitation of the project

Our proposed system will be limited only to the process condominium house distribution
system of the WCU community. The system will have the following limitation:
 The system will give service for those university lecturers and academic workers
only
 The system will not consider reserved houses.

1.8 .Significance of the project

This project aims to give a brief description of the condominium house management
systems. Accurate, timeliness, reliable, secured, relevant, and valuable data are needed for
condominium house management systems in all dimensions.

6|Page
 • This project will reduce the work overload of Condominium house coordinator office
workers.
• Will make the work environment favorable, information dissemination from agency to
applicant easily.
• The system will help the Wachemo university Condominium house coordinator office
workers to handle the applicant effectively and supports the smooth functioning of the
business.
• The system will increase document preservation without the need for a large area.
• Fast accessibility of stored data and saving of resource

1.9 .Methodology
To develop this project all the relevant techniques, tools, models which are used in an
object-oriented development environment are applied.
The particular methodology and tools are listed below:

1.9.1. Requirements gathering techniques

For the development of this system, several fact-finding techniques were employed and
several data sources were considered here to get a precise understanding of the subject matter.
The project team uses the following fact-finding methods which are considered suitable for this
project;

 Observation:-Observation is a common method of scientific research to collect

data. We used observation to know how the existing system work, to know
exactly how different sub-offices and how office members are handling the work
in the office.

 Interview:-Interview is particularly useful for getting the history behind the

participant’s experiences. We used the interview to get information about the
existing system for developing our project. The interview was conducted with the
head of town condominium house management office and staff members.

7|Page
  Document Analysis: - Document analysis is used to understand how the system
is working. We used this method to know all about the staff's mission, vision,
function, and overall their work in short and brief.

1.9.2 .Development tools

To develop the system different software, hardware tools, and programming language are very

important.

1.9.2.1 Hardware Tools

Different hardware was used to develop our project.

 Computer

 Network cable

 Flash Disk and CD/DVD

 Printer

 and others

1.9.2.2. Software Tools

 Power-point

 E-Draw max

 Bracket

 Windows Operating System(window 7,8.1)

 XAMPP

 Visual paradigm

 Microsoft Visio

 Microsoft office word

 and others

8|Page
1.9.3. Testing Procedure

Before directly deploying this system the team will perform different testing for its

functionality and meet customers' needs.

1.9.3.1. Unit testing

Unit testing is a software development process in which the smallest testable parts of an

application, called units, are individually and independently tested for proper operation.

 Unit testing involves only those characteristics that are vital to the performance of the

unit under test. This encourages developers to modify the source code without

immediate concerns about how such changes might affect the functioning of other units

or the program as a whole. Once all of the units in a program are working in the most

efficient and error-free manner possible, larger components of the program can be

evaluated through integration testing.

 Unit testing can be time-consuming and tedious. It demands patience and thoroughness

on the part of the development team.

 Testing of individual's software components or modules of the system

 Typically done by the programmer.

 It requires detailed knowledge of the internal program design and code, so non-

programmer users cannot perform the unit test.

1.9.3.2. Integration testing

 Integration testing, also known as integration and testing (I&T), is a software

development process in which program units are combined and tested as groups

in multiple ways.

9|Page
  Integration testing can expose problems with the interfaces among program

components before trouble occurs in real-world program execution.

There are two major ways of carrying out an integration test

 Bottom-up integration testing: begins with unit testing, followed by tests of

progressively higher-level combinations of units called modules or builds.

 In top-down integration testing: the highest-level modules are tested first and

progressively lower-level modules are tested after that.

In a comprehensive software development environment, bottom-up testing is usually done first,

followed by top-down testing. The process concludes with multiple tests of the complete

application, preferably in scenarios designed to mimic those it will encounter in customers'

computers, systems, and networks.

Alpha testing

 In this testing method, the system will be tested by giving the correct input. It is tested by

a customer at the developer Site.

Beta testing

 In this testing method, the team will force the system to be tested for incorrect data input.

The System will be tested by the customer at their actual workplace.

 If any failures occurred while testing the system in all the above testing methods, the

team will take immediate correction beginning where this fault occurred before jumping

to the next workshop so that it will meet the goal. If all the above testing methods are

carried out and found to be valid the system will be directly deployed.

 System testing

 The entire system is tested as per functional and non-functional requirements.

10 | P a g e
1.10. Overview of Project Phases
  There are six stages to the software development lifecycle and there follow a
specific order except in certain circumstances .these stages are planning, analysis,
design, implementation/development, testing/integration, and maintenances.

 Planning:- All software development projects are at the planning stage. This is
where the initial idea for the software is formed. The planning phase focuses on
identifying the problem, gathering the information needed to plan a solution and a
review of all of the available data. This is the most important part of the project
since effective planning can eliminate the majority of the problem.

 System Analysis: - system analysis is essential, a feasibility study to see if your

idea is viable. The goal is to explore the idea for your software from the lens of a
business executive trying to avoid a bad investment. You will have to build out the
rest of the idea and find ways to justify its development

 System Design:- the system design stage is where you create the fully developed
design of your software. This is where all of the design work happens so that the
development team can work on the project. in many cases, both teams are working
at this point since the development team can begin setting up a system for further
development and coordinate resources

 Implementation:- the development stage is where the software is assembled. This

involves a variety of processes, including coding, setting up infrastructure, and
creating documentation on how the system works. Developers may work with
designers to ensure that their work aligns with design. If there is a problem, the
development team may work with the design team to find a solution.

 Testing: - when the bulk of the work is completed, it may be sent for system
testing. All software is rigorously tested before being released to the public the
QA team uses tools like automated testers, to rapidly try scenarios so that they can
find the problem in the software.

11 | P a g e
 Maintenance:- At this phase, the development cycle is almost finished. The application is
done and being used in the field. The Maintenance phase is still important, though. In this
phase, users discover bugs that weren’t found during testing. These errors need to be
resolved, which can spawn new development cycles.

1.11 Task and schedule

1.11.1 Time Plan

Table 2.PERT Table

Figure 1.Time plan

12 | P a g e
1.11.2 Budget plan
For estimating of Effort and development of this project we assume the semi-detached mode of
the basic COCOMO model.
 For Effort: (semi-detached)
Effort = a1*(KLOC)a2 PM
a1= 3.0
a2=1.12
let assuming Source line of code is 20,000
Effort= 3.0*(20)1.12 PM
Effort = 86 PM

 For the Development of the project

TDev = b1*(Effort)b2 M

b1 = 2.5
b2 = 0.35
TDev = 2.5 * (86)0.35 M
TDev = 11.88 Month

13 | P a g e
 Chapter two
2. Description of the existing system
Higher education institutions to make the learning and teaching, studying and exercising
and also society service works successful for their workers specially for the academic staffs
creating comfortable leaving environment is known that is key issue. Similarly to make the
workers work initiations increase and control the workers working condition one of the methods
higher educations institutions use for motivation package is giving leaving house access.

In this chapter we will study the existing system deeply, since it is necessary to know the existing
working system of office so as to develop a better system. When we study the existing
system we gave emphasis for here under listed questions:

 how the existing system is working

 what kind of method they use to handle applicant data
 in what way the office is handling users complaint
 what is the business rule they use

After studying the existing system, we also determined the requirement or the feature that
must be included in the proposed system. Furthermore by analyzing the current system,
we could also estimate how the propose system solve the setbacks of the existing
system.According to this the university in 2004 sold 12 buildings holding 180 houses from
hosanna city house project agency. Wachemo University works for academic staffs in managing
and assigining house in the ownership of the university so they try to make the distribution and
competition transparent and fair. The management system works by doing different actions. First
of all it checks whether there is a free home or not and then if a home is free and available, it
posts advertisement or notice to the lecturers that there is free home and they can to apply and
compete to get home. The criterias used to get in to competition are academic position,
experience, work responsibility, marriage status, and special cases.so by seeing this criterias and
giving point according to their status the management system functions properly.

14 | P a g e
2.1. Major function of the current system
Hereunder we have listed several functions of the current system that are operated manually:

 Registering applicant
 Storing applicants’ data.
 Announcement
 Registering result of the lottery
 Manual notification by using notice board.
 Gives a payment form for the applicant to pay in the Ethiopian national bank.
 Control the status of condominium houses.

2.2. Users of the current system

 Property-management office of WCU:-they registers the property of the employees they
have a house registered by their name or their family. It is an agency at Wachemo
University.
 Construction management office of WCU: - they are sectors in the Wachemo University
that prepare a house for the employees managed by the contractor by contract agreement.
 House Development Corporation: - they are one of the agencies in the Wachemo
University that prepare the house for the employee or lecturer in the Wachemo University.
 Applicant –they are house seekers from Wachemo University
 Lectures committee
-listening complaints.
-participating in selecting users.

 Representative member
- participating in selecting users.
-making contact with committees.
 Lecture affairs Director Directorate

-giving key for the users.

- giving maintenance.
 Academic Issues vice president member and secretary

15 | P a g e
 - Manage the system.
-organize the system.

2.3. Drawback of the current system

The existing system has many problems. Among others
 Housing supply is insufficient (shortage of houses).
 Lack of more experienced employees for engineering and project administrator.
 Organizations give less consideration to information technology due to this technology-based
information management is less.
 Registration of customers in the existing system is a count long period.
 Many projects take a longer time to complete, cost more than necessary and some projects are
canceled because of various factors directly or indirectly related to them.
 Currently, the House distribution program for the state is unavailable.
 Shortage of land to the project.
 Poor selection of well-standard consultants and contractors during bidding.
 Within distribution there is duplication.
 Data redundancy in a database.
 Distributing information to the customer is insufficient because currently, the agency uses
a notice board and news.

2.4. Business rule of the current system

Business rules are principles and polices that must be fulfilled and obligated in order to well
function, to be properly and effectively. Identifying the business rule of the proposed system will
help us to specify and describe each use case in effective way. The business rules of the
wachemo university house management system are listed as following:-

1. The applicant should be from Wachemo university.

2. If the applicant has a house registered by him/her husband/wife he/she is not allowed to
take house.
3. To do their responsibilities well and as they work out of the given work time, for
presidents and vice presidents house is given with out any priority at first position.

16 | P a g e
 4. When people who are disabled have the chance to get the house ground floor is assigned
to them.
5. The lecturers registered for competition the experience they get from wachemo university
will be take in to account
6. The president of wachemo university have the authority to give home in special
cases(economy, disabled persons)
7. The cafeteria's taken in to account are academic position, experience, work responsibility,
marriage status, and special cases.
8. The payment is not done by the competitors rather the house allowance payment is
transferred to this house management bank account.

2.5. Alternative solutions

 Projects are needed to be completed within the time frame, budgeted cost, and required quality
so an organization should do each activity based on the plan.
 Use more experienced contractors for performance.
 To address the need of all people in the country corporation should make available.
 Organizations must use Information technology.
 To reduce duplication in the distribution system the distributing committee should check the
system before they draw a real one at least 3 and more times.
 To make the information is available to all employees in WCU organizations should use
appropriate social media.
 The system does not display an update form to update the applicant information with the
entered id.
 The system displays an error message if the applicant information doesn’t fill accurately.
 The system displays a fill again message to the Administrator if the entered id is
incorrect.
 The system displays a fill again message to the Administrator if the entered id is
incorrect.
 the applicant may not click the delete button so that there is no display delete a
successful message.

17 | P a g e
 Chapter three
3.Proposed system

3.1. Functional requirement

Functional Requirements are those that refer to the functionality of the system, i.e., what
services it will provide to the user. It specifies the service that the system should provide, and
also how the system should react to particular inputs and how the system should behave in
particular situations.
 FR1: The system shall allow the condominium administrator to Register a finished
condominium house (CH).
 FR2: The system shall allow the condominium administrator to update applicant
information.
 FR3: The system shall allow the condominium administrator to update house
information.
 FR4: The system shall allow the condominium administrator to search applicant
information.
 FR5: The system shall allow the condominium administrator to search house information.
 FR6: The system shall allow the condominium administrator to delete applicant
information.
 FR7: The system shall allow the condominium administrator to delete house information.
 FR8: The system shall allow the condominium administrator to view information.
 FR9: The system shall allow the condominium administrator to send notifications.
 FR10: The system shall allow the condominium administrator to add a site.
 FR11: The system shall allow the condominium administrator to post information.
 FR12: The system shall allow the condominium administrator to add a block.
 FR13: The system shall allow the applicant to register online.
 FR14: The system shall allow the applicant to view notifications.
 FR15: The system shall allow the applicant to view distribution results.
 FR16: The system shall allow the applicant to view posted information.
 FR17: The system shall allow the distribution committee to distribute houses.
 FR18: The system shall allow the distribution committee to generate a report.

18 | P a g e
  FR19: The system shall allow the condominium administrator to view house information.
 FR20: The system shall allow the condominium administrator to view applicant
information.
 FR21: The system shall allow the condominium administrator to view the comment.
 FR22: The system shall allow you to log out.

3.2. Non-functional requirement

 User interface: The system provides PHP user interfaces that are compatible with the
Windows platform.
 Hardware consideration: The organization should have computers having typical storage
capacity and processing speed.
 Software consideration: Data management systems play an essential role in the day-to-day
operations of any business.
 Performance characteristics: The end-user computer should have a medium processor and
the server computer should have a large processor. It's measured by the speed of the
processor.
 Reliability: The reliability of the proposed system will be better due to proper storage of
information Error handling Exception: The system must recover immediately when a user
enters incorrect (error) data
 Security: The system should have a security privilege that secures the system. And also
there must be physical security that secures (especially) the server computer. That means the
server computer is only allowed for the server admin.

3.3. System model

System modeling is a technique to express, visualize, analyze and transform the architecture of
a system. A system model is then a skeletal model of the system that helps us to model our
function of the system and it is used to ensure that a developing piece of software evolves
consistently and that the task of integrating software components is simplified.

Actors: are persons, organizations, or an external system that is used by our system to reach its
goals.

19 | P a g e
 Applicant: it is the employee that works at the Wachemo university who needs a
condominium house from the university if they fulfill the criteria that are entitled in the
agency. Applicants can apply for a house in the online condominium house management
system by creating their account or signup for accessing the application form.
 Condominium house management administrator: performs different activities on this
system. Administrators have a user name and password to log in to their administration page.
Moreover, on this system, the condominium administrator enables to register houses that are
finished.
 Distribution committee: they collected and selected people to distribute houses by seeing so
many criteria and generating a report to the administrators.
 Finance Office: it manages payment

3.3.1. Scenario
Scenario 1
Use case name: login
Goal: System administrator creates his/her account and account to housing manager.
Flow event:
I. The member the admin open the system
II. The login form is displayed on the index page.
III. The manager or the CHMadmin fill in the correct username and password.
IV. Click login button
V. Logged successfully message is displayed.
Exceptional flow:

a. If the user does not fill in the correct username and password the system displays, please fill
in the correct username and password message.

Alternative flow: none.

Scenario 2
Use case name: Notification

Goal: to know about the house

Flow event:

I. click notification page from the menu

II. display notification page
III. Fill the notification
IV. Repeat information the process end

20 | P a g e
 V. Click send button
VI. Display sent the successful message
VII. Finish notification and the use case ends

Scenario 3
Use case name: payment

Goal: - to payment

Flow Event

I. Click the payment link from the registration form

II. display payment page
III. Fill in all payment information.
IV. click pay button
V. display payment successful message
VI. finish payment and the use case ends

Exceptional flow:

 If the applicant does not have a bank account number the system display an error
message.
 if the applicant has insufficient balance in his/her bank account insufficient
balance message will be displayed

Scenario 4
Use case name: Manage applicant

Goal: - The system to manage applicants.

Flow Event

I. the Administrator click the manage applicant link

II. the system displays manage applicant page
III. the administrator enter the id number of the applicant to update
IV. the system displays the update form with the registered applicant information
V. The administrator fills in the new updated information of the applicant.
VI. Click submit button
VII. display update successful page

Exceptional flow for updating applicant

 The system does not display an update form to update the applicant information with the
entered id.

21 | P a g e
  The system displays an error message if the applicant information doesn’t fill
accurately.

Scenario 5
Use case name: searching applicant

Goal: To search applicant information

Flow Event

I. the Administrator click the manage applicant link

II. the system display manage applicant page
III. The administrator enters the id number of the applicant to search and click the search
button.
IV. the system display the applicant information
V. finished searching and stop the use case

Exceptional flow: for the searching applicant

 The system displays a fill again message to the Administrator if the entered id is
incorrect.

Scenario 6
Use case name: delete applicant

Flow Event

I. the Administrator click the manage applicant link

II. the system display manage applicant page
III. The administrator enters the id number of the applicant to search and click the search
button.
IV. the system displays the applicant information
V. the administrator enter the delete button
VI. the system display delete the successful message and stop the use case

Exceptional flow: for delete applicant

 The system displays a fill again message to the Administrator if the entered id is
incorrect.
 The system display deletion failed if the entered data are not available.

22 | P a g e
3.3.2. Use case model

 The use case of the system

A use case is a list of steps, typically defining interaction between a role or actor and the
system to achieve a goal.

The following use cases of our system:-

 is functionality or services that are offered by the system. Use-cases that are included
under our proposed system are the following:
 Login
 Logout
 Registration of finished house
 Register applicant online
 Search applicant information
 Update applicant information
 Delete applicant information
 View Applicant information
 Search house information
 Update house information
 view house information
 Delete house information
 View comment
 View notification
 View posted information
 Send notification
 Create account
 Add block
 Add site
 Give comment
 Distribute house

23 | P a g e
  Manage information
 Generate report

Figure 2.Use Case Diagram

24 | P a g e
3.3.3. Use case description

Table 3.Use Case Description for Login

Use case name Login

Use case number UC-01

Participation actor Housing manager, Finance office, applicant, and distribution

committee.

Entry condition The system administrator creates his/her account and account to the
housing manager.

Flow of events User action System response

Step1: open the home page. Step3: Display the form to insert
Step2: Click on the login username and password.
button. Step6: The system verifies the user
Step4: Insert user name and name and password.
password. Step7: The System allows the
Step5: Click to “log in” participant to log in to the intended
button. page.

C4 Invalid information entry.

4.1 Error message is displayed
Alternative action 4.2 Go to step 3 C6: non-existing user name and password
6.1 Error message displayed.
6.2 go to step 3.

25 | P a g e
 Postcondition Go to the page they are allowed to see

Table 4. Use Case Description for Create Account

Use case name Create account

Use case UC-02

number

Participation Condominium house Administrator

actor

Entry condition Log in to the system

Scenario The Condominium house administrator is responsible to give the user name and
password to the manager

Actor action System response

Step 1: The administrator

login
Step 4: The system displays the ‘create Account’
Into the Admin page. form to the admin.

Step 2: open the manage

Flow of events account page.

Step 3: Click the 'create

Account' link. Step 7: The system checks the existence of the
account from the database.
Step 5: The administrator
fills out the form. Step8: The system returns a success message

Step6: Click the “create”

button.

Alternative C 5: Invalid information

action entry

5. 1: The system provides an

26 | P a g e
 error message.

5.2: go to step

4. C7: The ID of the account

has existed.

7.1: The system provides an

error message. 7.2: go to step
4

Postcondition The database is updated

Exit condition Administrator log out from the system

Table 5.Use Case Description for View Account

Use case name View account

Use case number UC-03

Participation actor Condominium house Administrator

Entry condition The Condominium house administrator login to the system.

Actor action System response

Step1: the administrator Step 4: The system extracts all information

login into the admin from the system database and displays it for the
Flow of events page. Step 2: click the admin.
“manage account” link.

Step 3: The admin

selects view account.

Step 5: the admin view

the account information

Alternative action C2: no account from the database

27 | P a g e
 2.1: The system provides error

message 2.2: go to step 2

Exit condition The condominium house Administrator log out from the system

Table 6.Use Case Description for Update an Account

Use case name Update account

Use case number UC-04

Participation actor Condominium House Administrator

Entry condition Log in to the system

Flow of events Actor action System response

Step1: the administrator login into Step4: the system displays

the admin page. the form with searched
account information.
Step 2: the admin searches and
view the account. Step 7: The system updates
the intended account and
Step 3: The admin clicks the updates the database
“update” button.
Step 11: The System
Step 5: The administrator change displays a success message
(edits) the account.

Step 6: The admin clicks the

“save” button.

Postcondition The database will be updated

Exit condition Condominium House Administrator log out from the system

28 | P a g e
 Table 7. Use Case Description Register Applicant online
Use case name Register Applicant online

UC_ID: UC_05

Actor: Applicant

Description: This use case is well performed by the applicant to be registered as a new applicant
for getting a condominium house.

Precondition: 1. He/she must get an internet connection and his or her full information is must
available in WCU.
2. The user must sign up first to register
Post-condition: The applicant must be registered successfully.

Basic course of Actor action System response

action:
Step1: the applicant opens Step2: the system displays the home page.
the home page of the
Step4: the system displays the applicable registration
website.
form.
Step3: select apply for the
Step6: The system displays the register successfully
house.
message and end-use case.
Step5: fill out the
registration form and click
the Register button.

Exception If there is no internet connection no registration

Condition:

29 | P a g e
Alternative Course A8: The system display register failed message if there is unfilled information in the
of Action form.

Table 8.Use Case Description for Manage Applicant

Use case Name Manage applicant

UC_ID: UC_06

Actor: condominium office Administrator

Description: This use case is done by the CHM Administrator when they need to
update, search and delete applicant information

Stake Holders

Precondition: The Administrator must log in to the system to manage the

applicant.

Flow Event: Actor action System response

Step 1: the Step2: the system displays the manage

Administrator click the applicant page
manage applicant link
Step4: the system displays the update
Step3: the form with the registered applicant
administrator enter the information
id number of the
applicant to update Step7: display update successful page

Step 5: the
administrator fills in
the new updated
information of the

30 | P a g e
 applicant.

Step 6:click submit

button

The flow of events (for search Actor action System response

applicants)
Step 1: the Step2: the system displays manage
Administrator clicks the applicant page
manage applicant link
Step 3: the administrator Step4: the system displays the applicant
enters the id number of information
the applicant to search Step8: finished searching and stop the
and click the search use case
button.

The flow of events for deleting Actor action System response

applicant
Step 1: the Step2: the system displays manage
Administrator clicks the applicant page
manage applicant link
Step 3: the administrator Step4: the system displays the applicant
enters the id number of information
the applicant to search Step6: the system display delete the
and click the search successful message and stop the use case
button.

Step 5:the administrator

enter the delete button

31 | P a g e
 Table 9.Use Case description to send notification

use case name Send Notification

UC_ID: UC_08

Actors: Condominium house administrator

Description: The condominium house administrator after distribution notifies the result for the
winner applicant by rank.

Stakeholders: Applicant

Precondition: The Condominium administrator must log in to view the winner of the house.
And the applicant must have a phone number.

Postcondition: the admin notify to all applicant

Basic course of action: Actor action System response

Step1:click notification link from Step2:display notification page

the menu
Step6:display sent successfully message
Step3:fill notification
Step7:finish notification and end-use case
Step4:repeat notification until
process end

Step5:click send button

32 | P a g e
The alternative course of A.6: if the administrator does not fill correct phone number system display an
action: error message.

Table 10.Use case description to manage information

Use case Name Manage information

UC_ID: UC_09

Actor: Condominium house administrator

Description: When condominium house administrator needs manipulation of data such as

update, search and delete house and applicant information he/she use this
use case.

Precondition: The condominium administrator must log in to the system to

manage the applicant information.

Postcondition: All necessary information must be manipulated successfully.

Basic course of action for Actor action System response

update
Step1: The condominium administrator Step2: Display the updated
click the manage information link. applicant and house page.
Step3: Condominium Administrator
Step4: The system displays an
enters id number of applicant and block
update form with registered
number.
applicants and blocks
Step5: The Condominium
information.
administrators fill in new applicant and
house information. Step7: display update successful
Step6: Click the Update button. message and end-use case

The alternative course of An A.4: The system does not display an update form to update if the app

33 | P a g e
 action for update: applicant id and the house number is not entered.

A.7: the system displays an error message if the applicant information doe
doesn't fill accurately.
Basic course of action for Actor action System response
search:
Step1: the Condominium Step2: Display the manage applicant
administrator click the manage and house page.
information link.
Step4: the system display applicants
Step3: Condominium administrator and block information.
enters id number of applicant and
Step5: finish searching and end-use
block number to search and click
case.
the search button.

An alternative course of A.4: the system displays an error message if the entered id and block
action for search : number are incorrect.

Basic course of action for Actor action System response

delete:
Step1: the condominium administrator Step2: Display the manage
click the manage information link. applicant and block page.

Step3: condominium administrator Step4: the system display

enters id number of applicant and house applicant and house information.
number to delete.
Step6: the system display
Step5: the condominium administrator deletes Successful message and
clicks the delete button. uses case end.

An alternative course of
action for delete : A. A.4: the system displays an error message to the Administrator if the entered
id and house number are invalid.
A.A.6: the system display deletion failed if the entered data are not available.

34 | P a g e
 Table 11.Use case description for view information

Use Case name View information

UC-ID: UC-10
Actor: Condominium house administrator.
Description: When the Condominium house wants to view required information.
Precondition: The CH administrator login to view block or house information, applicant
information, and comment.
Postcondition: CH Admin view required information
Basic Course of Actor action System response
action Step1: the administrator clicks the view Step2: System display house page.
House information: house information link. Step5: The system displays house
Step3: enter block number to view required information.
block information. Step7: the system finished its
Step4: The condominium administrators click work and use case
the view button.
Step6: The condominium administrator view
blocks information.
An alternative A.5. if the condominium administrator does not enter the correct house number, the
course of action: system will display please enter correct house number message.
Basic course of Actors action System response
action for view Step1: the condominium administrator click Step2: System displays comment
comment: the view comment link. page and new sent the comment.
Step3: the CH administrator view comment. Step4: the system finished its
work and use case.
Alternative course A.3: if there is no new sent comment, the condominium administrator views the old
action: sent comment.
Basic course of Actors action System response
action for view Step1: the condominium administrator click Step2: System displays applicant

35 | P a g e
applicant on the view applicant information link. page.
information: Step3: enter applicant id to view the required Step5: the system display
applicant. applicant information.
Step4: The condominium administrators click Step7:the system finished its
the view button. work.
Step6: the condominium administrator views
applicant information.
An alternative A.5: if the condominium administrator enters an incorrect id the system will not
course of action: display applicant information.

Table 12.Use case description for View notification

Use case name View Notification

UC- ID: UC-11

Actors: Applicants

Description: When the Condominium house administrator distribute house send

information about who gets the house applicant view required
information (notification).

Precondition: The applicant login to view notification information about a house.

Postcondition: View notification

Basic Course of action: Actor action System response

Step1: the applicant clicks the Step2: System display notification

notification button link. page.

Step3: the applicant view Step4: the system finished its work.
notification.

Table 13.Use case description for giving comment

36 | P a g e
Use case name Give comment
UC-ID: UC-12
Actor : Applicant
Description: When the applicant has any suggestion, opinion, feeling he/she can write a
comment
Pre-condition: The applicant must log in to give a comment and write a comment
Postcondition: Send comment to the CH admin.
Basic course of Actor action System response
action: Step1:the applicant Step2: the system displays the
Click comment link comment page.
Step3: applicant write a comment Step5:you are successfully sent an
Step4:click send button end-use case

Table 14.Use case description to create account

Use case name Create Account

UC- ID: UC-13
Actor: Applicant.
Description: Create a new account for the new Applicant.
Pre-condition: Applicants must log in to the system.
Basic course of action: Actor action System response
Step1. Applicant after login Step2. The system displays the
own page clicks the user Registration form.
account. Step4. The system checks the
Step3.The user fills the information filled for validity.
Necessary information and Step5. The system display account is
click submit. created successfully.
Step 6. The user uses their user
name and password can log in
to the system

37 | P a g e
 Postcondition The account created

An alternative course of 1. If the Applicant enters invalid information the system displays error
action message.
Table 15.Use Case Description for Register finished house

Use case name Register finished house(CH)

UC_ID: UC_14

Actor : Condominium house administrator

Description : Condominium house administrator Register houses that are finished or ready with
their full description

Precondition: The condominium administrator must log in to register the house information
(UC_01), the newly finished house must exist

Postcondition: The entire new houses that are finished must be registered or recorded with their
full information successfully.

Basic course of action: Actor action System Response

Step1:the CH administrator run the Step2:system display house registration

system and open house registration page form
from the menu
Step5: display message register
Step3:fill all finished house information successfully.

Step4: click the register button Step6:finish recording and use case end.

38 | P a g e
An alternative course A.1: if there is no new finished condominium house, the condominium house
of action administrator stops or pauses the use case.

3.4. Object Model

 Data dictionary
 Class diagram

3.4.1. Data dictionary

Table 16.Condominium House Admin Data Dictionary

Attribute Data type Data size Key Constraint Constraint

Admin_ID int 15 Primary key Not null

Admin_Name string 20 Not null

Phone_no int 15 Not null

Table 17.Distribute Committee Data Dictionary

Attribute Data type Data size Key Constraint Constraint

Committe_ID int 15 Primary key Not null

Committe_Name string 20 Not null

Phone_no int 15 Not null

Table 18..WCU Finance Office Data Dictionary

Attribute Data type Data size Key Constraint Constraint

Finance_ID int 10 Primary key Not null

Finance_Name string 20 Not null

Finance_phone int 15 Not null

39 | P a g e
Table 19.Applicant Data Dictionary

Attribute Data type Data size Key Constraint Constraint

APP_ID int 15 Primary key Not null

APP_Name string 20 Not null

APP_Age int 2 Not null

APP_phone int 15 Not null

APP_address string 20 Not null

3.4.2. Class diagram

The class diagram is static. It represents the static view of an application. The class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but
also for constructing executable code of the software application.
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object-oriented
systems because they are the only UML diagrams, which can be mapped directly with object-
oriented languages. The class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram.
The purpose of the class diagram can be summarized as
 Analysis and design of the static view of an application.
 Describe the responsibilities of a system.
 The base for component and deployment diagrams.
 Forward and reverse engineering.
In the following diagram, we are trying to show the basic classes of our system and their
relationship. The class represents those objects that need permanent storage in a database. The
cases of our system are users which are the aggregation of the applicant, system administrator,
housing manager and applicant, house, house distribution, and payment table.

40 | P a g e
Figure 3.Class Diagram

3.5. Dynamic model

 Sequence diagram
 Activity diagram

41 | P a g e
3.5.1. Sequence diagram
A sequence diagram is an interaction diagram that shows how objects operate with one another
and in what order. It is a construct of a message sequence chart.
A sequence diagram shows object interactions arranged in a time sequence. It depicts the objects
and classes involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenario. Sequence diagrams are typically
associated with use case realizations in the Logical View of the system under development.
Sequence diagrams are sometimes called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the
order in which they occur.
Key parts of a sequence diagram
 Participant
 Message

42 | P a g e
Figure 4.Sequence Diagram for Login

43 | P a g e
Figure 5.Sequence Diagram for Register Finished House

44 | P a g e
 Condominium Home Notification
Controller Database
admin page Page
<<Controller>> <<DB>>
<<Actor>> <<UI>> <<UI>>
1:open home page
2:click notification
link
3:display registered winner list and
send link

4:click send link

5:display notification page

6:fillwiner phone number and

notification 7:click send button

8:save notification

9:display successful message

Figure 6.Sequence diagram for sending notification

45 | P a g e
Figure 7.Sequence diagram for search applicant information

46 | P a g e
Figure 8.Sequence diagram for registering applicant

47 | P a g e
3.5.2. Activity diagram
An Activity diagram is similar to a flowchart to represent the flow from one activity to another
activity. Activity diagrams and State chart diagrams are related. While a Statechart diagram
focuses attention on an object undergoing a process (or on a process as an object), 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.

48 | P a g e
Figure 9.Activity Diagrams for Login

49 | P a g e
Figure9.Activity Diagram for Register finished CH

50 | P a g e
 Figure 10.Activity Diagram for a registered applicant

51 | P a g e
Figure 11.Activity diagram for updating applicant information

52 | P a g e
 Figure 12. Activity diagram for Delete applicant information

53 | P a g e
Figure 13. Activity diagram for sending Notification

Figure 14.Activity diagram for View comment

54 | P a g e
Figure 15.Activity diagram for creating an account

55 | P a g e
Figure 16.Activity diagram for payment

56 | P a g e
Figure 17.Activity diagram for post information

57 | P a g e
Figure 18.Activity diagram for logout

58 | P a g e
3.5.3. State diagram
The state chart diagram shows the change of an object through time from one state to the
other state. State chart modeling is used to show the sequence of states that an object goes
through, the events that cause the transition from one state to the other, and the actions that result
from a state change.

Following are the main purposes of using State chart diagrams:

 To model the dynamic aspect of a system.

 To the model life of a reactive system.
 To describe different states of an object during its lifetime.
 Define a state machine to model the states of an object.

Figure 19.State Diagrams for Login

59 | P a g e
Figure 20.State Diagrams for Registration

60 | P a g e
Figure 21. State Diagram for Create Account

61 | P a g e
Figure 22.State Diagrams for House Registrations

62 | P a g e
 CHAPTER FOUR
SYSTEM DESIGN

4.1. Purpose
Design is the process of describing, organizing, and structuring system components at the
architectural design level and detailed design level. The design converts functional models from
analysis into models that represent the solution. The design may use structured or object-oriented
approaches. In the case of system design, developers fill the gap between the system
specification produced during requirement elicitation and analysis which is concentrated on the
purpose and the functionality of the system. In the design phase of the system, we will show the
decomposition, hardware-software mapping, and the exact architecture of the proposed system in
detail.

4.2. 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 at a technically acceptable level.

The objectives of the design are to model the system with high quality. Implementing a high-
quality system depend on the nature of the design created by the designer. If the system needs
repair or 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 a change in the system.
The design goals include:-

4.2.1 Performance Criteria:

 Performance criteria reflect how the system is expected to behave under normal
operating conditions. This includes the throughput and memory requirement of the
system.
 Response time: Depending on the strength of the available network, they
should respond in a short period.
 Storage space: To do work efficiently it needs the processor to be 2GB
RAM and above and the HD storage to be 20MB and above.

63 | P a g e
4.2.2. Dependability Criteria
These criteria determine how much effort should be expanded in minimizing system crashes and
their consequence, and how available the system should be.
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 at a system level, in the system environment, or the
interaction between the user and the system. Some of the faults that may occur include computer
failure, system failure due to the virus, unauthorized users. The system tolerates the error that
occurs due to user-system interaction using proper execution handling methods.

4.2.3. Maintenance Criteria

A measure of how easily bug fixes or functional modifications can be accomplished.

E x t e n s i b i l i t y : New capabilities can be added to the software without major

changes to the underlying architecture.
M o d i f i a b i l i t y : The system accepts modification of the functionality or additional
featuring.
R e u s ab i l i t y : the software can add further features and modifications with slight or
no modification.
Portability: the system is developed to be viewed and retrieved from any web browser
regardless of the version and platform it resides in it.
Readability: the system code can be viewed by clicking on the current web page and
choosing the “view the source code” option.

4.2.4. End-user criteria

In the Condominium House management system end-users Applicant are those who interact
specifically with the system.
This project is very simple to use. Anyone who can read the English language can use the
system, because, to use the system only by clicking a button, it does not need to write
commands and to think how to use it. This program will have a well-defined and easily
understood interface. The processes will be easy to understand and use by a user of any level.

64 | P a g e
4.2.5. Priorities of Design goal
To achieve the desired goals of a good design we use design patterns as a solution for common
design problems that use design principles. It has two main usages in our system

Common platform for developers: - It provides a standard terminology and is specific

to a particular scenario.
For example, we choose the Singleton design pattern from the Creational design pattern
category to specify the use of a single object all developers familiar with a single design
pattern will make use of a single object and they call tell each other that the program is
following a singleton pattern.
Best practices: - Learning design pattern helps inexperienced developers to learn
software design in an easy and faster way.

Architectural Styles and patterns

To show architectural styles and patterns we choose MVC (Model-View-Controller) Style. MVC
(Model-View-Controller) is one of many design patterns which we select to design our system.
MVC proposes three types of objects in an application, the Model, Views, and Controllers.

1. Model objects: hold data and define the logic for manipulating that data. It holds data
describing facts about the object like the username and password and any other
information about the user of the system or the system.
2. View objects: represent something visible in the user interface, for example, a
Dashboard, button, and it displays any output from the model for which we generate
input.
3. Controller object: acts as Observer between the Model and View objects. A Controller
object communicates data back and forth between the Model objects and the View
objects.
It reacts to user events and responds by invoking actions on the model. The following figure
shows how our system MVC works.

65 | P a g e
Figure.Design Pattern for the System

66 | P a g e
 CHAPTER FIVE

PROPOSED SYSTEM (ARCHITECTURE)

5.1. High-level design: describe the system architecture

Here we design the conceptual model for the proposed system that describes the relationship
between a major participant in the condominium distribution and management system.
There is Applicant and the house manager who would like to use a computerized condominium
distribution and management service.
The house Administrator 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 a logical system that involves collaborating with 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

67 | P a g e
5.2. Scenario view:
Scenario View is a view model used for "describing the architecture of software-intensive
systems, based on the use of multiple, concurrent views”. The views are used to describe the
system from the viewpoint of different stakeholders, such as end-users, developers, system
engineers, and project managers. The four views of the model are logical, development, process,
and physical view. In addition, selected use cases or scenarios are used to illustrate the
architecture serving as the 'plus one view. Hence, the model contains 4+1 views.

 Logical view: The logical view is concerned with the functionality that the system
provides to end-users. 
 Process view: The process view deals with the dynamic aspects of the system, explains
the system processes and how they communicate and focuses on the run time behavior of
the system. The process view addresses concurrency, distribution, integrator,
performance, scalability, etc.

68 | P a g e
  Development view: The development view illustrates a system from a programmer's
perspective and is concerned with software management. This view is also known as the
implementation view.
 Physical view: The physical view (aka the deployment view) depicts the system from a
system engineer's point of view. It is concerned with the topology of software
components on the physical layer as well as the physical connections between these
components.

Figure 23. Scenario View of the system

5.3. Process view

Process view of work is defined as the understanding that work can be viewed as a "process" that
has inputs, steps, and output(s) and that interfaces with other processes within an organization. It
is the overall awareness of the tactics and methodologies used "by an organized group of related
activities that work together to transform one or more kinds of input into outputs that are of value
to the User."

69 | P a g e
The Process view of Applicant Registration

Applicant browser website the system display home page select apply for
house.

display confirmation page display applicant registration form fill registration form and
click register button

displays register successfully message and end use case

The process view of CHAdmin

CHAdmin click notification link display notification page fill notification request

repeat notification until process end click send button display sent successfully
message

finish notification and end use case

5.4. Development view

5.4.1. Subsystem Decomposition

There are the working areas of the project after the completion of total process. In the
subsystem decomposition, we can see the different component emanated from system
architecture that collaborates to handle single application at a time.

70 | P a g e
Figure 24.sub system decomposition
5.4.2. Subsystem description
Condominium housing management system has the following major subsystems and these
subsystems can be further decomposed.

 The "CHAdmin" subsystem that perform the following functionalities view

information, add block, add site, manages applicant data, send notifications.
 The "Applicant" subsystem allowing Applicant to register for condominium by filling
the form provided.
 The "Finance office" subsystem manages the accounts of housing Adminstrator.
 The “Committee” subsystem distribute house and generate report.

5.5.1 Physical view (Hardware /software Mapping)

WCU 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.

71 | P a g e
The diagram below shows the hardware/software mapping of CDMS.

Figure 25.Hardware and software architecture mapping

5.6. Persistent data management
We should be able to store persistence data into database for future use with their attribute and
data type.

5.6.1. Data schema view

A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are associated.
It formulates all the constraints that are to be applied on the data.
A database schema defines its entities and the relationship among them. It contains a descriptive
detail of the database, which can be depicted by means of schema diagrams. It’s the database
designers who design the schema to help programmers understand the database and make it
useful.

72 | P a g e
Figure 26.Data schema view of the system
A database schema can be divided broadly into two categories:
 Physical Database Schema − this schema pertains to the actual storage of data
and its form of storage like files, indices, etc. It defines how the data will be
stored in a secondary storage.
 Logical Database Schema − this schema defines all the logical constraints that
need to be applied on the data stored. It defines tables, views, and integrity
constraints.

73 | P a g e
5.6.2. Mapping class to table. (In case of using relational DBMS)

Figure 27.Mapping class

Mapping with Normalization

Data normalization is a process in which data attributes within a data model are organized to
increase the unity of entity types.  In other words, the goal of data normalization is to reduce and
even eliminate data redundancy, an important concern for application developers because it is
very difficult to stores objects in a relational database that maintains the same information in
several places.  There are three types of normalization rule:

 First normal form (1NF): An entity type is in 1NF when it contains no repeating groups
of data.

74 | P a g e
  Second normal form (2NF): An entity type is in 2NF when it is in 1NF and when all of
its non-key attributes are fully dependent on its primary key.
 Third normal form (3NF): An entity type is in 3NF when it is in 2NF and when all of
its attributes are directly dependent on the primary key.
Table name

 Account
 Condominium admin
 Finance Office
 Bank account
 Applicant
 Winner
 Payment
 Site
 Block
 House

No. Table name Attributes Data types Primary key Foreign key
1 Account User_Id Varchar(30) User_Id
Username Varchar(30)
Password String(30)
2 Condominium CA_Id Varchar(30) CA_Id
administrator Fname Char(30)
Mname Char(15)
Lname Char(30)
Email String(30)
Phone_No Int(13)
3 Finance FO_Id Varchar(30) FO_Id
Office Fname Char(15)
Mname Char(15)
Lname Char(15)
Email String(30)
5 Applicant Applicant_Id Varchar(30) Applicant_Id Site_Id
Site_Id Varchar(30)
Fname Varchar(30)
Mname Char(15)
Lname Char(15)
Age Cha(15)
Gender Int(15)
House_type Varchar(10)
Phone_no Varchar(30)
Email Int(13)

75 | P a g e
 Site_name String(30)
Nationality Varchar(30)
city Varchar(30)
Woreda Varchar(30)
kebele Varchar(30)
Varchar(30)
6 Winner Winner_Id Varchar(30) Winner_Id
Fname Char(15)
Mname Char(15)
Lname Char(15)
Email String(30)
Phone_no Int(13)
7 Payment tt_No Varchar(30) tt_No Winner_Id
Winner_Id Varchar(30)
Payment_type Varchar(30)
Amount Int(15)
8 Bank account Account_No Int(13) Account_No tt_No
tt_No Varchar(15)
Fname Char(15)
Mname Char(15)
Lname Char(15)
Phone_no Int(13)
Balance Varchar(30)
Photo Blob
Payment_type Varchar(30)
9 Site Site_Id Varchar(30) Site_Id Block_No
Block_No Varchar(30)
Site_name Varchar(30)
City Varchar(30)
Woreda Varchar(30)
Kebele Varchar(30)
Block_type Varchar(30)
10 block Block_No Varchar(30) Block_No Site_Id
Site_Id Varchar(30)
Block_type Varchar(30)
Site_name Varchar(30)
11 House House_No Varchar(30) House_No Block_No
Block_No Varchar(30) Site_Id
Site_Id Varchar(30)
House_type Varchar(30)
Block_type Varchar(30)
Floor_No Varchar(30)
Site_name Varchar(30)

76 | P a g e
First normal form

Account
User_Id Username password

Condominium admin
Admin_Id Fname Mname Lname Email Phone_No

The above table is not in 1NF, because a person may be having more than one email address and
phone number.

We can take example:

Condominium administrator

001 Senbeto Megersa Ali [email protected] 0915942378

[email protected] 0923806448

Not in the 1NF because single row contain two value

Condominium administrator

001 Senbeto Megersa Ali [email protected] 0915942378

m

001 Senbeto Megersa Ali [email protected] 0923806448

m

Now the above tables fulfill 1NF

Finance Office

DS_Id Fnam Mname Lname Email Phone_no

e

The above table is not in 1NF, because a person may be having more than one email address and
phone number.

77 | P a g e
 We can take example:

Finance Office

002 Senbeto Megersa Ali [email protected] 0915942378

[email protected] 0923806448

Not in the 1NF because single row contain two value

Finance Officer

002 Andualem Legase Tekile [email protected] 0915942378

002 Andualem Legase Tekile [email protected] 0923806448

Now the above tables fulfill 1NF

Applicant

Applicant_ Site Fna Mna Lna age gen House email Phon Site_ nationality Woreda
Id _Id me me me der _type e_no name

The above table is not in 1NF, because a person may be having more than one phone number and
email address.

We can take example:

Applicant

0 0 1 a b c 2 F singl 093856450 [email protected] Hosann ethi lem am

0 1 1 a b c 2 e 9 m a o o b

094356782 [email protected]
3 m

Not in the 1NF because single row contain two value

78 | P a g e
 Applicant

0 0 1 a b c 2 F singl 093856450 [email protected] Hosann ethi lem am

0 1 1 a b c 2 e 9 m a o o b

0 0 1 a b c 2 F singl 094356782 [email protected] Hosann ethi lem am

0 1 1 a b c 2 e 3 m a o o b

Now the above tables fulfill 1NF

Winner

Winner_I Fname Mname Lname email Phone_no

d

The above table is not in 1NF, because a person may be having more than one phone number and
email address.

We can take example:

Winner

001 Nuradin Husen adane 0938564509 [email protected]

0934567823 [email protected]

Not in the 1NF because single row contain two value

Winner

001 Nuradin Husen adane 0938564509 [email protected]

001 Nuradin Husen adane 0934567823 [email protected]

Now the above tables fulfill 1NF

Payment

tt_No Winner_Id Payment_type Bank_name amount

The above tables fulfill 1NF

Bank account

Account_N tt_No Fname Mname Lname Balance Photo Payment_type

o

The above tables fulfill 1NF

79 | P a g e
 Site

Site_Id Block_No Site_name City Woreda Kebele Block_type

The above tables fulfill 1NF

Block

Block_No Site_Id Block_type Site_name

The above tables fulfill 1NF

House

House_n Block_N Site_I House_typ Floor_N Service_typ Qualit Site_nam placemen

o o d e o e y e t

The above tables fulfill 1NF

Second normal form

Applican
t

Applican Site Fna Mna Lna age gen House_ emai Phone Site_ nationality
t_Id _Id me me me der type l _no name Woreda

 All non-key attribute fully depend on key.

Applicant

Applicant_I Fname Mname Lname age gender House_type email Phone_no

d

Site

Site_Id Site_name

New introduced table

80 | P a g e
 Applicant_Id Site_Id

Payment

tt_No Winner_Id Payment_type Bank_name amount

Payment

tt_No Payment_type Bank_name amount

New introduced table

tt_No Winner_Id

Bank account

Account_No tt_No Fname Mname Lname Balance Photo Payment_type

Account number

Account_No Fname Mname Lname Balance Photo

TT number

tt_No Payment_type

Bank account

Account_No tt_No

Site

81 | P a g e
Site_Id Block_No Site_name City Woreda Kebele Block_type

Site

Site_Id Site_name City Woreda Kebele

Block

Block_No Block_type

New introduced table

Site_Id Block_No

Block

Block_No Site_Id Block_type Site_name

Block

Block_No Block_type

Site

Site_Id Site_name

New introduced table

Block_No Site_Id

82 | P a g e
 House

House_no Block_No Site_Id House_type Block_type Site_name Floor_No

House

House_no House_type

Block

Block_No Floor_No Block_type

Site

Site_Id Site_name

New introduced table

House_no Block_No Site_Id

Figure 28. mapping for normalization

V.6.3. Relationship mapping
Data that must be stored in the database for future use with their data type and their domain must
be designed as a database design, this kind of design help as to build table relationship as well as

83 | P a g e
dependency between different tables in the database

Figure 29.Relationship mapping

5.7. Access control:

Utilize global access table, describing the access relation between the actors, objects and
operations in the system

Access control is a security technique that can be used to regulate who or what can view or use
resources in a computing environment. Access control list (ACL) refers to the permissions
attached to an object that specify which users are granted access to that object and the operations
it is allowed to perform. Each entry in an access control list specifies the subject and an
associated operation that is permitted.

84 | P a g e
 Table 20. access control

User Role Module and components

Registration Maintenance Placement Notification Payment House Update Info

registration
send receive send receive

CHAdmin x    x x  

Applicant   x x   x x

Finance x x x x x  x x
Office

Committee x x  x x x x x

5.8.User interface model:

85 | P a g e
86 | P a g e