DBU Dormitory Management System: Development of an Online Dormitory Allocation System - Pr, Study notes of Software Engineering

Download DBU Dormitory Management System: Development of an Online Dormitory Allocation System - Pr and more Study notes Software Engineering in PDF only on Docsity! CHAPTER ONE 1. Introduction Technology is spreading its wing in almost every walks of human life activities. Now a day it is better if every activity is done using new technology in order to fulfill the need of human being, Organization, Enterprise etc. As today’s world there are many organizations and each organizations needs to be preferable, computable and work on fastest way in order to satisfy users interest etc. i.e. they should have facilitate their activities in computerized way. Many developing countries are in a good position to exploit the opportunity of technology revolution and advance human development. The information and communication technology provide new resource materials for expanding communication. In fact the second half of 20th century has wittiness the global phenomena of an information explosion. The development in communication technology has made it possible for millions of people to have fast access to vast information presented in several forms. Today computer and other electronic device increasingly communicate and interact directly with other devices over a variety of network such as internet. The internet provides individuals and small business centers for the ability to communicate inexpensively. Hence, developing the system using technology has a tremendous effect for organizations and offices; which is in our case the Debre Berhan University Online dormitory management system (DBUODMS). Currently, the system is manual based; due to this the students and proctors faces some problems Because of this, we are initiating to develop our project on dormitory system in order to minimize the problem by using computerized system. 1.1 Organizational background DEBRE BERHAN UNIVERSITY (DBU) is one of the thirteen new Universities which was established in the year 1997 E.C by the Ethiopian government (MOE).DBU is located in the Northern part of Ethiopia, in Amhara regional state, North Showa Zone, in Debre Berhan town which is 130 kms far from Addis Ababa to the North – East. The foundation of the University was laid down in May 1997 E.C. DBU-DMS 1 DBU started the teaching, learning Process on January 28, 1999 E.C (2008 G.C) with enrollment of 725 students in the faculty of education with two streams, namely Businesses Education and natural science. After four consecutive year’s i.e. 2003 E.C enrollment of DBU was 5387 Students. Currently the University runs over 31 departments in first degree and 5 postgraduate studies by the total of 10,000 students. In addition to the academic service the university provides dining, health care, dormitory, community service and other services for the students and Debre Berhan town communities. In the University there are different management activities were performed. Among those the main service which provides the university to the student is Students’ Dormitory Management can be taken as an example. In this process there is a problem associated with the Dormitory Management. So we the project team members were initiated for this project to identify and analyze those problems and to put possible solutions. 1.2 Statement of the problem Currently, DBU dormitory management system uses manual approach. To process the operation first the ministry of education sends all the information to the registrar bureau and gives to the student affairs (dormitory) and to the dinning office. After taking the list, they assigned students to each block and room. At that time they face different problems during operating their tasks. Working by paper based i.e. manual system is not only affecting the management members, rather it also for student during viewing of their dormitory information. Some of those problems are:-  Data duplication and Time consuming.  Require more human power to assign the students.  Management inflexibility DBU-DMS 2 1.7.1 Operational Feasibility The system to be developed will provide accurate, active, secured service and decreases labor of workers and also it is not limited to particular groups or body. And also it is plat form independent i.e. it run’s in all operating system. 1.7.2 Technical Feasibility The system to be developed by using technologically system development techniques such as PHP, Java script, css and Mysql database without any problems and the group members have enough capability to develop the project. So the system will be technically feasible. 1.7.3 Economic Feasibility The system to be developed is economically feasible and the benefit is outweighing the cost. Since this project already computerizes the existing system, by now the reduction of cost for materials used in manual operation becomes beneficiary to the organization. Generally the system that we developed, DBUODMS brought a number of tangible and intangible benefits. Tangible benefits: 1. Cost Reduction 2. Error Reduction 3. Increase Speed of activity The team member calculated the corresponding the tangible benefits with sample monetary: 1. Cost Reduction: - To calculate these following things will be considered. Total Number of proctors in existing system= 35 Average Salary of each proctor per month = 1250.00Birr Total money required for payment per year= 35*1250*12= 525,000Birr Average Number of proctors needed when the new system is deployed= 30 Average salary of each of them per month = 1250.00Birr Total money required for payment per year= 30*1250*12= 450,000.00Birr Difference b/n before and after deployment money required for payment Cost Reduction and Avoidance= 525,000Birr -450,000.00Birr = 75,000.00Birr DBU-DMS 5 2. Increase Speed of activity: - Increased speed calculated as follows Especially in allocation:- Average Days required for allocation= 15 days Average proctor salary per day=41.61birr Average Days required for allocation in terms of money=35*41.61*15= 21,845.25Birr Average days required for the system= 3 day Average Days required for allocation in terms of money=30*41.61*3= 3744.90Birr Difference = 21,845.25Birr-3744.90Birr=18,100.35 Birr Intangible benefits: 1. Reduce Resource Consumption 2. Increase security 3. Increase Management flexibility 1.7.4 Political feasibility The system to be developed is not conflict with any government directives, because it gives services for the people effectively and efficiently, all the stakeholders also agreed before the system developed. So the government is profitable and the system will be politically feasible. 1.8 Methodology 1.8.1 Fact finding techniques The data collection instruments used to gather accurate information about the existing system and the requirements for the new system. Interviews and questionnaires were administered to Stakeholders like Students, Proctors and Dormitory management officer to collect user requirements. Observation of the current existing system was done at the Dormitory management office in order to find out how the existing system functions, the problems encountered and how they can be solved by the new computerized system. To get a precise data, the team member has used the following data collection techniques. Those are: - A. Interview: - to get the basic information and background information about the existing management system, the team members has interviewed the proctors and some students DBU-DMS 6 about the services that are given to them, and the problems associated with that environment. B. Direct observation: even though interview is very important to gather information, direct observation is simple and we project team members physically observe information that cannot maintain from the interview or others and also it is important if they are unable to communicate with others because of the difficulties they have to the language. C. Questionnaires: since proctors as well as higher officials of proctors have work load they cannot able to answer/give information what we ask. So we prepare some sample questions to get précised information. D. Existing document: To get more information about the project we use earlier documents that help us to develop the project. During the analysis of documents, we give a special consideration to those documents which can bring more features to the project. 1.8.2 System analysis and design techniques Here for the analysis of our project we have selected object oriented system analysis and design method specifically UML (Unified Modeling Language) model. We have selected this because of the following advantages:-  To simplify the design and implementation of complex program.  To make it easier for teams of designers and programmers to work in a single software project.  To enable a high degree of reusability of designs and of software codes.  To decrease the cost of software maintenance.  Increase reusability.  Reduce maintenance burden.  Increased consistency among analysis, design and programming activities.  Improved communication among users, analysis, design and programming. DBU-DMS 7 1.10 Project Team Organization Debre Berhan University Online Dormitory Management System S.No Name ID NO. Email Address Responsibilities 1. Seleshi Zelalem COMPR/082/03 Seleshizelalem2@gmail.c om -V/group Coordinator -Testing 2. John G/Kiros COMPR/117/03 - -Data gathering 3. Henok G/Mariam COMPR/139/03 Welaygmariam139@gm ail.com - -Data gathering -Designer 4. Sintayehu Yimam COMPR/134/03 - -Designer 5. Gebiyanesh Gedefaw COMPR/069/03 - -Data gathering -Designer 6. Temesegan Walelign COMPR/089/03 temeseganwalelign@gmail .com -Group coordinator -Documentation -Implementation Project Advisor: Instructor EyobKebede (M.Sc) Table 1.5 Project Team composition 1.11 Risk Assumption During the development of the project there may be different problems that we may face. These are:  Time management problem: but we solve this problem by working cooperatively, divide our time by schedule for each phase of the project and we try to use this schedule effectively  The employees (proctors) of the student residence may not be voluntary to give detail information about their operations. To solve this problem we try to ask any thing politely and tell reason why we ask them.  Failure of electric power and internet connectivity- we try to solve this by taking back up to external storage devices. DBU-DMS 10 CHAPTER TWO DESCRIPTION OF THE EXISTING SYSTEM 2.1 Introduction This chapter describes the existing system, players in the existing system general work flow of DBU dormitory management. In addition to this the business rule is identified, report generated in the existing system, alternative solutions suggested to overcome existing system, finally the proposed system (functional and non-functional requirement). 2.2 Description of existing system The current system of DBU dormitory management system is manual (partial). In order to arrange and allocate students to dorms, they have to follow the record as it is arranged by DBU Registrar office and allocate Students depending on department and the lists of the students’ arrangement. After getting the list from the registrar office, the proctor allocates the students to each block and dorm. Since there are so many students, the allocation method causes problems like assigning female students to males’ dorm and vice versa and also assigning students more than the capacity of the dorm. In addition to these problems, during assignation there is no consideration of disable students. 2.3 Major functions of existing system Even if the existing system is performs its activities manually (partial), it has different major functions.  Arranging buildings for the allocation: here the total number of building is determined with its holding capacity  Arranging students for allocation: here total number of students and their academic information such as department, sex, faculty, and class year is received from registrar. Students are then arranged based on their sex, class year, and their department and faculty for dormitory allocation.  Dormitory allocation: based on the arrangement of students dorms are allocated for students along with associated dormitory resources, like lockers, tables, chairs, beds and the like. DBU-DMS 11  Generating allocation report: based the dormitory allocation the allocation report is prepared and posted for student when they arrive at the campus after annual break.  Managing and controlling dormitory materials: at the beginning and end of each year, dormitory materials are recorded and controlled whether they are functioning properly or not, then appropriate measure is taken.  Controlling student’s discipline: In addition to the above functionalities student’s discipline measures are controlled and recorded, whether they use the dormitory materials properly or not, and whether they act and perform things as per the dormitory rules and regulations. 2.4. Player of the existing system An existing system compromises different players to carry out its job. Among those different actors (players), the most common are Proctor manager, this body provides the list of all students who fulfilled every requirement for allocation to proctors, Students, they will be placed in their dorm by proctors and assigned for the property they get from the proctor, Proctors, They involved strongly in the existing system. Proctors collect students list from registrar. After they get all these information’s from this body they will place those students according to their sex, class year, department and faculty. The major actors in the existing system are:  Students  Proctors and  Proctor manager 2.5 Work flows in the existing system DBU-DMS 12 Fig 2.1 Student dormitory allocation form 2.9 Problems in the existing system The manual (partial) dormitory management system is disposed to various problems. These problems can be seen from the following perspectives like performance, information, economic, control, efficiency and services given by the existing system to the users. DBU-DMS 15  The performance of any system is required to show to meet the needs of users of that system. The current system’s performance is weak. This is due to the following reasons: - first the acceptable quantity rate is relatively high i.e. the time required from initiation to completion of a particular task is relatively high. For example during arrangement of buildings for the allocation it may take a week or more due to its manual operation. Second is the acceptable response time for a particular task is large.  Information- the main input for the current system is student record and records of different dormitory materials which enable the system to rearrange students and buildings for the allocation. Based on this the system rearranges and allocates dorms for students at the beginning each academic year and generates the allocation report which may be viewed by the students as well as the management. The other data that is stored is record of materials associated with the dormitory. The system manipulates and manages all of these and other records manually on papers.  Controlling- since all the records associated with the manual system are recorded and stored manually the security that the system provide for the privacy of this records is not good. The system shouldn’t provide sufficient protection for access and manipulation of the records associated with the system.  Services- the main users of the current system are students and the management itself. The services given to users are not flexible, reliable and expandable i.e. the users must there in the campus to get the services given by the system. Those services given by the system are limited to a particular area. DBU-DMS 16 2.10 Practices to be preserved from existing system Even if the existing system is manual system as it has weakness it also has some strong side that we need to be preserved are:  Provide the required infrastructure to the students.  Protecting dormitory resources.  Posting dormitory information in each building.  Generation timely report.  Assessing discipline cases. 2.11 Alternative solutions In order to overcome the current system problems that exist in the functioning of DBUDMS, our project team members have put down alternative options. These are:  Change manual system in to computerized system (online) without affecting the structure of the existing system.  Fetching records from excel sheet (.CSV) 2.12 The proposed system 2.12.1. Functional requirement The following are the functional requirements of the new system.  The system accepts (read) the uploaded record.  The system should arrange the buildings for the allocation.  The system should arrange students for the allocation.  The system should assign dorms for students.  The system should generate timely report about the allocation.  The system should store all the data related with all the tasks performed into a database. DBU-DMS 17 3.2.1 Actor identification In the use cases an actor interact with the system to perform a piece of meaningful work that helps them to achieve a goal and has access to define their overall role in the system and the scope of their action. Depending on the above explanation actors in this system are the following:  Student: The students view his/ her dormitory information online and submit comment.  Proctor: The proctor can assign student and generate report.  Proctor manager: search, generate report and change password.  Administrator: The administrator manages the overall system. 3.2.2 Use case identification Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior. The most important and basic use cases of this system are the following:-  Login  Allocate Student  Create account  View dorm  Submit comment  View comment  Register block (Allocate Proctor)  Register room  View StudentInfo  Generate report DBU-DMS 20 DBU-DMS 21 Fig 3.1 Use case diagram for the proposed system DBU-DMS 22  The system display error message and give a chance to retype.  Go to step 5  Use case ends. Post condition: The user sends comment to the system. Use Case Name: View DormInfo Use case Id: UC04 Description: The user can view his/her dormitory information. Actors: Student. Precondition: The Student must have valid Identification number. Flow of action: Actor action: Step1: The student wants to see his/her dorm. Step2: The student click on view dorm link. Step4: the student fills his/her identification number. System response Step3: the system displays the login form. Step5: the system validates the entered data. Step6: the system displays the dormitory information. Step7: Use case ends. Alternative course of action: (if student identification number is not existing)  The system display error messages that student identification is not exist.  Go to step 4 Post condition: The system displays the detailed information. Use Case Name: view Comment Use case Id: UC05 Description: Proctor manager can see the comments that are submitted from the user (student, proctor). Actors: Proctor manager. Precondition: The Proctor manager must have a full privilege to read the comments. DBU-DMS 25 Flow of action: Actor action: Step1: Proctor manager log to his/her page. Step2: Proctor manager click on view comment link. Step4: Proctor manager starts to view the comments. System response: Step3: The system reorders the comments according to the time of delivery Step5: Use case ends Post condition: The proctor manager views the submitted comments. Use Case Name: Manage Record Use case Id: UC06 Description: The Administrator can manage records. Actors: Administrator. Precondition: The administrator must log to his/her page. Flow of action: Actor action: Step1: The administrator log to his/her page. Step2: The administrator clicks on Manage Record link. Step4: The administrator selects one at a time from the given options. Step6: The administrator fills the form and click on buttons. System response Step3: The system will give the options like delete, update or search record. Step5: The system displays the available form. Step7: The system performs the task. Step8: Use case ends. Alternative course of action (The system validate the entered data is not correct) The system displays incorrect entered data message.  The system redirects to go step 6 i.e.to fill the data again.  Use case ends Post condition: The administrator manages the record. DBU-DMS 26 Use Case Name: Register Block Use case Id: UC07 Description: The user can register blocks information (including proctors) into the data base Actor: Proctor manager Precondition: Proctor manager must have full privilege to do this task. Flow of action: Actor action: Step1: The proctor manager log to his/her page. Step2: The proctor manager selects the register block link. Step4: The proctor manager fills the required fields. System response Step3: The system will display the registration form. Step5: The system validates the input data. Step6: The system displays the successful notification. Step7: Use case ends. Alternative course of action (the system validate the entered data if it is not correct) The system displays incorrect entered data message.  The system redirects to go step 4 i.e.to fill the data again.  Use case ends Post condition: The block registered. Use Case Name: Register Room Use case Id: UC08 Description: The user can register room information into the data base Actor: Proctor Precondition: Proctor must have full privilege to do this task. Flow of action: DBU-DMS 27 Actor action: Step1: The proctor must log to his/her page Step2: The proctor select Allocate student link Step4: The proctor selects and fills the required fields and clicks on save button. System response: Step3: The system displays the form with the options such as block no, room no. Step5: The system validates the entered values. Step6: Use case ends Post condition: The Student will be assigned. Alternative course of action: (the system verify information is not correctly)  The system displays error message as invalid value  Go to step4 3.3 Subsystem Decomposition To reduce the complexity of the solution domain, we decompose a system into simpler parts, called subsystems, which are made of a number of solution domain classes. In the case of complex subsystems, we recursively apply this principle and decompose a sub- system into simpler subsystems. Decomposition Results large systems in to a set of loosely dependent parts which make up the system. The main need of this portion is to design the external part of the system. Sub-System Decomposition is the way that helps us to distinguish the part of the operations that takes place under the organization. In this project, there are five sub system decompositions. These are: 1. Assignation Subsystem  Assign Student 2. Report Subsystem  Assignation report  Block and Room report  Comment report 3. Comment and Information Subsystem  Give comment and Message of current issues (may be for the system). DBU-DMS 30  View student dorm information 4. Fetch record  Fetch record from centralized database 5. User Account Subsystem  Create Account  Remove Account 3.4 Analysis level of Class diagram Class diagram is static model that shows the classes and the relationships among classes that remain constant over the time. Class is the main building block of class diagram, which stores and manages information in the system. In the phase of conceptual class modeling we just create or classes ad their interrelationship. DBU-DMS 31 Fig 3.2 Analysis level of Class Diagram DBU-DMS 32 * ** * * Student Fname Mname Lname Stud_Id Faculty Sex Batch Block_No. Room_No. View_DormInfo() Submit_Comment() Comment Name Email Comment User Fname Mname Lname User_id Sex Role Phone_no Username Password Submit_Comment() Generate_Report() Allocate_Student() View_StudentInfo() Register_Room() Block Block_No. Capacity Proctor_Fullname Store() Room Block_No. Room_No. Capacity Store() * 1 1 Fig 3.3 Sequence diagram for login DBU-DMS 35 Fig 3.4 Sequence diagram for View DormInfo DBU-DMS 36 : Student View DormInfo Link View DormInfo Form Validator Database 1.Select View Dorm link() 3.Fill Student Id or Registration number() 4.Submit() 5.Validate() 6.Retype() 8.Check() 7.Continue() 9.Display dorm information() 2.Display the form() Sequence Diagram for View Dorm Use case User(Student) Action: 1.Select view Dorm link. 3.Fill his or her identification number or registration number. System Response: 2.The system displays the form. 4.The system validate the entered data. 5.If the identification or registration number is exist display the dorm information, if not display as"The number is not exist". DBU-DMS 37 Fig 3.7 Sequence diagram for Remove account DBU-DMS 40 Administrator Page User Account Link Remove Account Form Remove Account Link Controller Database 1.Login to admin page() 2.Select link() 3.Select the link() 4.Display the account form() 5.Fill the form() 6.Remove Account() 7.Validate() 8.Try again() 9.Continue() 10.Check() 11.Display Response() Sequence Diagram For Remove Account Use case User (Administrator) Action: 1.User Login to admin page. 2.Select user account link. 3.select remove account link. 5.Fill the account form System Response: 4.Display the account form. 6.Validate the entered data. 7.Display response : Administrator Fig 3.8 Sequence diagram for Search Record DBU-DMS 41 : Administrator AdminPage Search Link Search Form Search Validator Database 1.Log to the page() 2.Select the link() 3.Display the Search Form() 4.Fill the form() 5.Submit() 6.Validate() 7.Try again() 8.Continue() 9.Check() 10.Display Response() Sequence Diagram for search record User(Proctor Manager) Action: 1.Log to the proctor manager. 2.Select the link. 4.Fill the search form. System Response: 3.Display the search form. 5.Validate the input data. 6.If the input data is exist in the database diplay the result if not Display as Doesn't exist : Administrator Admin Page Update Record Link Update Record Form Update Validator Database 1.Log to the page() 2.Select the link() 3.Display update record form() 4.Fill the update record form() 5.Submit() 6.Validate() 7.Try again() 8.Continue() 9.Check() 10.Try again() 11.Save Changes() Sequence Diagram for Upda... User(Proctor Manager) Action: 1.Log to the proctor manager. 2.Select the link. 4.Fill the Update form. System Response: 3.Display the Update form. 5.Validate the input data. 6.If the input data is correct check and save it if not display message as Try again Fig 3.9 Sequence diagram for Update Record DBU-DMS 42 3.6 Activity diagram Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc. The purposes of activity diagram can be described as:  Draw the activity flow of a system.  Describe the sequence from one activity to another.  Describe the parallel, branched and concurrent flow of the system. Fig 3.12 Activity diagram for Login DBU-DMS 45 Validate Enter Username And Password Incorrect Display Available Page Correct User(Administrator,Proctor Manager,Proctor) Found ? Enter ID no/Registration no Display dorm information Student Yes No Fig 3.13 Activity diagram for View DormInfo DBU-DMS 46 Found ? Fill the search form No Display Searched InformationYes Administrator Log Admin Page Select Search Record Link Fig 3.14 Activity diagram for Search Record DBU-DMS 47 CHAPTER FOUR DESIGN DELIVERABLES OF THE NEW SYSTEM 4.1 Introduction System design is the transformation of the analysis model into a system design model. Up to now we were in the problem domain. System design is the first part to get into the solution domain in a software development. This chapter focuses on transforming the analysis model into the design model that takes into account the non-functional requirements and constraints described in the problem statement and requirement analysis sections discussed earlier. The purpose of designing is to show the direction how the system is built and to obtain clear and enough information needed to drive the actual implementation of the system. It is based on understanding of the model the software built on. The objectives of design are to model the system with high quality. Implementing of high quality system depend on the nature of design created by the designer. If one wants to change to the system after it has been put in to operation depends on the quality of the system design. So if the system is design effetely, it will be easy to make changes to it. 4.1.1 Design goals and objectives The objectives of design are to model the system with high quality. The design goals are derived from non-functional requirements that means non-functional requirement is the description of the feature characteristics and attribute of the system as well as any constraints that may limit the boundary of the proposed solution. Design goals describe the qualities of the system that the developers should consider.  Reliability: DBUODMS system should be reliable.  Fault Tolerance: DBUODMS system should be fault tolerant to loss of connectivity with the service. DBU-DMS 50  Security: DBUODMS system should be secured, i.e., not allow other users or unauthorized users to access data that has no the right to access it.  Modifiability: DBUODMS system should be modifiable for further modification and enhancement of the application.  Performance: - The system should respond fast with high throughput, i.e. it should perform the task quickly possible as possible such as allocating students and proctors, viewing student and dormitory information etc.  Cost: The system should be developed with minimum cost possible. In reality there is always trade-offs or disadvantages and therefore from its previous experience the University prefers to invest more on development cost than maintenance cost to minimize bugs which may appear at the later stage.  End User Criteria: - The system should have simple and understandable graphical user Interface such as forms and buttons, which have descriptive names. It should give reliable response for each user request at least before the session expires. All the interfaces, forms and buttons are written or designed in a simple language or common language so that the user can access it without any difficult. 4.2 Design the class diagram The class diagram is a static diagram. It represents the static view of an application. 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 classes 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. DBU-DMS 51 DBU-DMS 52 views contains * 1 * Controlls submit inherits* inherits ** * * 1 * ** * * 1 1 Student Fname : Varchar(30) Mname : Varchar(30) Lname : Varchar(30) Stud_id : Varchar(12) Sex : Varchar(8) Batch : Varchar(10) Faculty : Varchar(30) Block_No : Varchar(3) Room_No : Varchar(3) View_DormInfo() Submit_Comment() Comment Name : Varchar(25) Email : Varchar(30) Comment : Varchar(200) Room Block_No. : Varchar(3) Room_No. : Varchar(2) nobed : Varchar(2) Store() Block Block_No. : Varchar(3) Reserved : Varchar(8) Capacity : Varchar(2) User_Id : Varchar(15) Sex_Category : Varchar(8) Proctor_name : Varchar(30) Sex : Varchar(8) Phone : Varchar(13) Store() User Fname : Varchar(30) Mname : Varchar(30) Lname : Varchar(30) User_id : Varchar(30) Sex : Varchar(8) Role : Varchar(15) Phone_no : Varchar(13) Username : Varchar(20) Password : Varchar(20) Submit_Comment() Generate_Report() Allocate_Student() View_StudentInfo() Register_Room() submit Fig 4.4 Collaboration diagram for View DormInfo DBU-DMS 55 : Student Validator View Dorm Link View Dorm Form Databas e 5: 8: Select View Dorm link() Display the form() Fill Student Id or Registration number() Submit() Retype() Validate() Continue() Check() Display dorm information() 1: 4: 6: 7: 3: 2: 9: : Administrator Administrator Page User Account Link Create Account Link Create Account Form Controller Database 7: 10: Login to admin page() Display the account form() Fill the form() Create Account() Select the link() Select link() Try again() Display Response() Check() Continue() Validate() 1: 6: 2: 3: 4: 5: 8: 9: 11: Fig 4.5 Collaboration diagram for Create Account DBU-DMS 56 Fig 4.6 Collaboration diagram for Remove Account DBU-DMS 57 User Account Link Remove Account Link Remove Account Form Controlle r Databas e : Administrator 7: 10: Administrator Page Login to admin page() Select link() Select the link() Display the account form() Fill the form() Remove Account() Try again() Display Response() Validate() Continue() Check() 2: 3: 4: 5: 8: 9: 11: 1: 6: Fig 4.9 Collaboration diagram for Generate Report DBU-DMS 60 : Proctor,Proctor Manager Proctor,Proctor manager Page Report Link Report Form Validator Database 6: 9: Log to the page() Select report link() Display report form() The user fill the required fields() Submit() Try again() Validate() Check() Continue() Display Response() 1: 5: 2: 3: 4: 7: 8: 10: 4.4 State chart diagram A state chart diagram is a view of a state machine that models the changing behavior of a state. State chart diagrams show the various states that an object goes through, as well as the events that cause a transition from one state to another. The common model elements that state chart diagrams contain are:  States  Start and end states  Transitions A state represents a condition during the life of an object during which it satisfies some condition or waits for some event. Start and end states represent the beginning or ending of a process. DBU-DMS 61 Idle State Home Page Login Link Login Form Initial State Activate Select Correct Final state Fill Verify Confirm Login Display Appropriate Page Logout Incorrect Fig 4.10 state chart diagram for login DBU-DMS 62 Idle Home Page Select Report Link Select Report Type initial State activate final state Displayed select select Fig 4.13 state chart diagram for Generate report DBU-DMS 65 Fig 4.14 state chart diagram for submit comment DBU-DMS 66 Idle Home Page Comment Form initial State activate Correct fill final state Validate Confirm Comment Display Successfull message Incorrect Select Comment Link select 4.5 Data base design Database design is the process of producing a detailed data model of a database. This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database. A fully attributed data model contains detailed attributes for each entity. The term database design can be used to describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. DBU-DMS 67 The purpose of deployment diagrams can be described as:  Visualize hardware topology of a system.  Describe the hardware components used to deploy software components.  Describe runtime processing nodes. DBU-DMS 70 Fig 5.2 Deployment Diagram 5.4 Persistence diagram Persistence modeling is used to communicate the design of the database, usually the data base to both the users and the developers. It is also used to describe the persistence data aspect of the system. The following diagram indicates the persistence diagram of the system. DBU-DMS 71 views contains * 1 * Controlls submit inherits n inherits ** * n 1 n *n n n 1 1 Student Fname : Varchar(30) Mname : Varchar(30) Lname : Varchar(30) Stud_id : Varchar(12) Sex : Varchar(8) Batch : Varchar(10) Faculty : Varchar(30) Block_No : Varchar(3) Room_No : Varchar(3) View_DormInfo() Submit_Comment() Room Block_No. : Varchar(3) Room_No. : Varchar(2) nobed : Varchar(2) Store() Comment Name : Varchar(25) Email : Varchar(30) Comment : Varchar(200) Block Block_No. : Varchar(3) Reserved : Varchar(8) Capacity : Varchar(2) User_Id : Varchar(15) Sex_Category : Varchar(8) Proctor_name : Varchar(30) Sex : Varchar(8) Phone : Varchar(13) Store() User Fname : Varchar(30) Mname : Varchar(30) Lname : Varchar(30) User_id : Varchar(30) Sex : Varchar(8) Role : Varchar(15) Phone_no : Varchar(13) Username : Varchar(20) Password : Varchar(20) Submit_Comment() Generate_Report() Allocate_Student() View_StudentInfo() Register_Room() submit 1 1 n Fig 5.3 Persistence Diagram 5.5 User Interface In this system users will communicate with it through the following user interfaces. I. Home Page: This form contains some links which lead it to the concerned page, and if the user has an account he/she will directly go to concerned page by entering their username and password. In case for the students the system requires ID no. DBU-DMS 72 Fig 5.6 User interface for view dorm page IV. Create Account: this is creating account page in this page the administrator create accounts for the user (proctor, proctor manager). DBU-DMS 75 Fig 5.7 User interface for Create Account page V. Assign Dorm: This is student assign page in this page after the proctor login into the login page then after the proctor assign students accordingly assign the dorm. DBU-DMS 76 Fig 5.8 User interface for assign student page Fig 5.9 User interface for the database DBU-DMS 77 DBU-DMS 80 echo' <p align="center"><font color="red" size="2"><img src="img/error.png">&nbsp;&nbsp;Your Account is not active Please contact the system Admin </font></p>'; echo' <meta content="4;login.php" http-equiv="refresh" />'; }}else if($row['level']==2){ if($status==1) { $_SESSION['user_id']=$row['user_id']; echo' <meta content="1;pro_manager.php" http-equiv="refresh" />'; }else{ echo' <p align="center"><font color="red" size="2"><img src="img/error.png">&nbsp;&nbsp;Your Account is not active Please contact the system Admin </font></p>'; echo' <meta content="4;login.php" http-equiv="refresh" />'; }} else if($row['level']==3){ if($status==1){ $_SESSION['user_id']=$row['user_id']; echo' <meta content="1;proctor.php" http-equiv="refresh" />'; }else { echo' <p align="center"><font color="red" size="2"><img src="img/error.png">&nbsp;&nbsp;Your Account is not active Please contact the system Admin </font></p>'; echo' <meta content="4;login.php" http-equiv="refresh" />'; }}else { echo'<br>'; echo' <p align="center"><font color="red" size="2"><img src="img/error.png">&nbsp;&nbsp;Check Your username or/and Password </font></p>'; echo' <meta content="4;login.php" http-equiv="refresh" />'; }} mysql_close($conn); ?> Sample code for View Dorm: DBU-DMS 81 <?php if (isset($_POST['submitlogin'])){ $idno=$_POST['idno']; $view=mysql_query("select * from students where stud_id='$idno'"); $rowCheck = mysql_num_rows($view); if($rowCheck<1) {echo"<script>alert('The ID no is not found');</script>";} else {while($row = mysql_fetch_array($view)) {$fname=$row['fname']; $lname=$row['lname']; $dorm=$row['roomno']; $block=$row['block_no']; } echo"<table align='center' style='border-radius:15px;border:1px solid #336699;' width='250px' height='100px'>"; echo"<tr>";echo"<th colspan='2' bgcolor='#336699'><font color='white' size='2'>".$fname."&nbsp;". $lname."</font><a href='viewdorm.php'><img align='right' src='img/close_icon.gif'></a></th>"; echo"</tr><tr>"; echo"<td><font face='Times New Roman' size='3' color='green'>Block No:</td><td>". $block.'</td></tr>'; echo"<td><font face='Times New Roman' size='3' color='green'>Room No:</td><td>". $dorm.'</td></tr>'; echo"</font></table>"; } } ?> Sample code for Assign Student: DBU-DMS 82 <?php if(isset($_POST['save'])) { $block=$_POST['block']; $dorm=$_POST['nodorm']; $sex=$_POST['sex']; $batch=$_POST['batch']; $fac=$_POST['faculty']; $aa="it"; $sum=0; for($i=1;$i<=$dorm;$i++) { for($j=$sum; $j<=$sum+9;$j++) { $f=$j+1; $result = mysql_query("SELECT * FROM registrar where sex='$sex' AND batch='$batch' AND faculty='$fac' AND no='$f'"); while($row = mysql_fetch_array($result)) { $r1=$row[1]; $r2=$row[2]; $r3=$row[3]; $r4=$row[4]; 7.3 Appendix References To do the system starting from the requirement analysis to the implementation the team members were used the following materials: Books  Essentials of System analysis and design(in analysis and design phase)  System analysis and Design methods(in analysis and design phase)  A modern, modular approach to standards-compliant web design Craig Grannell Foreword by Jon Hicks, Hicksdesign  Andrew Curioso, Ronald Bradford, Patrick Galbraith Join the discussion @ p2p.wrox.com Wrox Programmer to Programmer™ PHP and MySQL® Websites  www.tutorialspoint.com/index.html  www.w3schools.com/index.php  http://www.ibm.com/developerworks/rational/library/3101.html DBU-DMS 85 f oo Manager “ / With AL Money looe eco coos cccesae cess ' ' ‘ ‘ oy r \ Deposit DBU-DMS 86 DBU-DMS 87