Presentation is loading. Please wait.

Presentation is loading. Please wait.

WELCOME TO THE PRESENTATION OF OUR FINAL PROJECT!.

Similar presentations


Presentation on theme: "WELCOME TO THE PRESENTATION OF OUR FINAL PROJECT!."— Presentation transcript:

1 WELCOME TO THE PRESENTATION OF OUR FINAL PROJECT!

2 DEC REGISTRAR OFFICE DATABASE SYSTEM DEC REGISTRAR OFFICE DATABASE SYSTEM Developed By: Hailemariam Abera RDEG/037/95Hailemariam Abera RDEG/037/95 Markos Borena RDEG/040/95Markos Borena RDEG/040/95 Yeshimebet Hagos RDEG/074/97Yeshimebet Hagos RDEG/074/97 Yirgalem Hailu RDEG/084/95Yirgalem Hailu RDEG/084/95  In Fulfillment for the Award of Bachelor of Technology in Computer Science Under the guidance of: Under the guidance of: Kalechristos Abebe(2nd Cpl)Kalechristos Abebe(2nd Cpl) DEFENCE UNIVERSITY COLLEGE DEFENCE UNIVERSITY COLLEGE COLLEGE OF ENGINNERING COLLEGE OF ENGINNERING October 2009 October 2009

3 1. INTRODUCTION 1.1. Back Ground  Defence Engineering College shall normally operate on a two-semester basis.  The main function of the registrar office is To keep records or registers for all students. To keep records or registers for all students.  To manage all the activities being processed in the registrar office in each semester, manually, is a tough work and mostly prone to errors. Thus, our main objective is to help the registrar office by converting the former system into automated ones. Thus, our main objective is to help the registrar office by converting the former system into automated ones.

4 1.2. Statement of the Problem  In response to our motive to analyze the registrar system practices, this project will answer the following questions: How the system was being performed? How the system was being performed? What difficulties or problems were observed? What difficulties or problems were observed? How to reveal all the problem and former system? How to reveal all the problem and former system? What makes our project effective? What makes our project effective?

5 1.3. Purpose of the System 1.3. Purpose of the System  The new system provides handling and registering of student records in an efficient and effective manner.  Computerizing the system basically has positive impact in: time consumption, time consumption, resource and material utilization and resource and material utilization and error minimization. error minimization.

6 1.4. Objectives of the Project 1.4.1. General Objective Analyzing the existing system and replacing it with an automated system. Analyzing the existing system and replacing it with an automated system. 1.4.2. Specific Objectives 1.4.2. Specific Objectives Obtain understanding about the existing information system. Obtain understanding about the existing information system. Identify potential users and their information needs. Identify potential users and their information needs. Increase profitability by improving controlling system of the registrar. Increase profitability by improving controlling system of the registrar. Convert the manual system to an automated one. Convert the manual system to an automated one.

7 1.5. Methodology 1.5. Methodology  A methodology is a formalized approach to implementing the system development life cycle (SDLC).  In this project we use  In this project we use object-oriented system analysis and design methodologies.  The most advantage of object-oriented system analysis is that; it is simple for representation of real world object and it is flexible. it is simple for representation of real world object and it is flexible.

8 Fact Finding Methods Interview Interview Questioner Questioner Observation Observation Document Analysis Document Analysis 1.6. Scope of the Project  The scope of this project is focused or limited to the registrar office activities.

9 2. REQUIREMENT SPECIFICATION 2. REQUIREMENT SPECIFICATION  Is to cover analysis of existing activities in registrar (work flow) and its boundary in detail. 2.1. Business System Analysis of registrar 2.1. Business System Analysis of registrar  The business area analysis will enable the team to investigate the business in which the software we will develop and operate. 2.2. Current System 2.2. Current System  One of the reasons for studying and documenting the existing system is that: it will be helpful for understanding of current business with its problems and requirements built in. it will be helpful for understanding of current business with its problems and requirements built in.

10 2.3. Proposed System 2.3.1. Overview: 2.3. Proposed System 2.3.1. Overview:  The new system will introduce simple, easy and efficient method of the database system. 2.3.2. Requirement Definition 2.3.2. Requirement Definition  The important goal of requirement modeling is to come to an understanding of the business problem.

11 3. OBJECT ORIENTED ANALYSIS  Analysis is a process of separating a whole into its component parts.  The goal of analysis is: To understand the problem or problems To understand the problem or problems To prompt relevant questions To prompt relevant questions To provide a basis for answering questions To provide a basis for answering questions To decide what the system should do. To decide what the system should do. To decide what the system should not do. To decide what the system should not do. etc.. etc..

12 3.1. System Models  System modeling abstracts the overall system under consideration. Hence, we are trying to present the Hence, we are trying to present the, actor, use case, use case, scenarios, scenarios, sequence diagram and also sequence diagram and also the class diagram of the proposed system. the class diagram of the proposed system. 3.2. Actor’s Identification  An actor represents anything or anyone that interfaces with the system. 3.3. Use Case Definition  A use case describes a sequence of actions that provides a measurable value to an actor.

13 3.3.1. List of Use Cases Register student Register student Fill in semester grade Fill in semester grade Generate Reports Generate Reports Prepare student copy Prepare student copy Prepare grade report Prepare grade report

14

15

16 3.4. Scenarios  It is “a narrative description of what people do and experience as they try to make use of computer system and application”.  We described the scenario by listing the main activities that is carried out in the system. Scenario name: - Register Student Scenario name: - Register Student Participating actor instance: Markos (Registrar Clerk) Participating actor instance: Markos (Registrar Clerk) Pre Condition: Pre Condition: Markos wants to register students. Markos wants to register students. Markos login to the system. [alternative flow of event:[RLE] ] Markos login to the system. [alternative flow of event:[RLE] ] System displays the main menu. System displays the main menu. Markos selects Register Students Menu. Markos selects Register Students Menu. System displays formats to register students menu. System displays formats to register students menu. Markos enters to the system Student details.[RFE] Markos enters to the system Student details.[RFE] The system updates the database. The system updates the database.

17 Post Condition: Post Condition: Student Registered. Student Registered. Alternative Flow of Event: Alternative Flow of Event: RLE RLE Markos provides wrong login information and the system notifies Timer to re-enter login information for 3 times. Markos provides wrong login information and the system notifies Timer to re-enter login information for 3 times. RFE RFE Markos provided wrong entry data and the system notifies Timer to re-enter data. End of register Good Receiving Notes. Markos provided wrong entry data and the system notifies Timer to re-enter data. End of register Good Receiving Notes.

18 3.5. Conceptual Diagrams 3.5. Conceptual Diagrams 3.5.1. Class Diagram 3.5.1. Class Diagram  Class modeling is the main stage of object oriented analyses and design. oriented analyses and design.

19

20 3.5.2. Sequence Diagram 3.5.2. Sequence Diagram  Sequence diagram is used to model the logic of usage scenarios.  The following sequential diagrams are stated for each use case to help the user to understand the elements clearly:

21

22

23 4. OBJECT OREINTED DESIGN 4. OBJECT OREINTED DESIGN  This section describes design goals of the project, design goals of the project, subsystem decomposition, subsystem decomposition, hardware or software platforms on which the system will run, hardware or software platforms on which the system will run, the persistent data management, the persistent data management, access control, access control, control flow mechanisms, and control flow mechanisms, and boundary conditions. boundary conditions.

24 4.1. 4.1. Purpose of the system  We have selected strategies for building the system, such as, hardware/software platform on which the system will run, hardware/software platform on which the system will run, the persistent data management strategy, the persistent data management strategy, the global control flow, the global control flow, the access control policy, and the handling of boundary conditions. the access control policy, and the handling of boundary conditions.  The result of this design is a model that includes a clear description of each of these strategies, a clear description of each of these strategies, subsystem decomposition, and subsystem decomposition, and a deployment diagram representing the software/hardware mapping of the system. a deployment diagram representing the software/hardware mapping of the system.

25 4.2. Design Goals The design goals are explained as follows: The design goals are explained as follows:   Performance Criteria describes the speed and space requirements of our system. describes the speed and space requirements of our system. : - once the Registrar System is started all requests should be responded. Response time : - once the Registrar System is started all requests should be responded. : - not less than 120 MB of memory is required to run the system. Memory : - not less than 120 MB of memory is required to run the system.

26  Dependability Criteria : - Registrar System should be secured. Security : - Registrar System should be secured.  Maintenance Criteria : - As we are using Object Oriented Design, it is possible to add new functionality or new classes at any stage of development. Extensibility : - As we are using Object Oriented Design, it is possible to add new functionality or new classes at any stage of development. : - If it is needed to change the functionality of the system, it should be accomplished without the need of rewriting the whole system. Modifiability : - If it is needed to change the functionality of the system, it should be accomplished without the need of rewriting the whole system. :- The code has to be documented well so that it will be easily understandable in time of maintenance. Readability :- The code has to be documented well so that it will be easily understandable in time of maintenance.  End User Criteria :- There will be a help menu for users of the system if they come across some difficulties. Usability :- There will be a help menu for users of the system if they come across some difficulties.

27 4.3. Proposed Software Architecture  The proposed software architecture is a repository architecture where subsystems access and modify data from a single data structure.  Subsystem Decomposition Login This subsystem checks whether the user is valid or not. Registration The Registration subsystem consists of functionalities of registering students Prepare Report The Report subsystem consist all functionalities of the system that produce report concerning the students. Data Management The Data Management subsystem connects the overall system to the database and serves as a facilitator between them.

28

29 4.4. Hardware/software Mapping The system is going to be implemented on a server having greater than 2 GHz of CPU speed. The system is going to be implemented on a server having greater than 2 GHz of CPU speed. The hard disc capacity is greater than 40 GB which is enough to handle the data of the registrar, and The hard disc capacity is greater than 40 GB which is enough to handle the data of the registrar, and the memory is 256 MB in capacity. the memory is 256 MB in capacity.

30

31 4.5. Access Control and Security 4.5. Access Control and Security During system design, we modeled access by examining the object model and determining which objects are shared among actors, and by defining how actors can control access. During system design, we modeled access by examining the object model and determining which objects are shared among actors, and by defining how actors can control access. The access control is regulated by the user Administrator which has an unbounded access to the SYSTEM. The access control is regulated by the user Administrator which has an unbounded access to the SYSTEM. Every user of the SYSTEM will have username and password with different privileges given by the user Administrator. Every user of the SYSTEM will have username and password with different privileges given by the user Administrator.

32 4.6. Boundary Conditions   System Star The starting condition of the system is when the user double clicks the icon of the SYSTEM. The starting condition of the system is when the user double clicks the icon of the SYSTEM.   Initialization Initialization will happen when the user tries to execute one of the system’s classes. Initialization will happen when the user tries to execute one of the system’s classes.   Shutdown i. When the session expires without the user doing any action on the system. i. When the session expires without the user doing any action on the system. ii. When the user selects the Exist Command which is the appropriate way to shut down the system on the user’s end.   Exception Handling Exception handling is the mechanism by which Exception handling is the mechanism by which the treats an exception. the treats an exception.

33 4.7. 4.7. Conclusion The developer team strongly believes that, this project has paved a way towards the understanding object oriented analysis and design. The developer team strongly believes that, this project has paved a way towards the understanding object oriented analysis and design. As it is the one the motivations behind project work, we have tried our best to study new system development techniques. As it is the one the motivations behind project work, we have tried our best to study new system development techniques. Due to the limitation of time, we can not accomplish all what we intend to do. Due to the limitation of time, we can not accomplish all what we intend to do.


Download ppt "WELCOME TO THE PRESENTATION OF OUR FINAL PROJECT!."

Similar presentations


Ads by Google