SYSTEM DESIGN 1 Introduction: The purpose of System Design is to create a technical solution that satisfies the functional requirements for the system. During analysis, the focus is on what needs to be done intendment of how it is done. During design, decisions are made about how the problem will be solved, first at a high level, then at increasingly detailed levels. System design is the first stage in which the basic approach to solving the problem is selected. During system designing the overall structure and style are decided. The system architecture is the overall organization of the system into components called system. System design deals with transforming the customer requirements, as described in the SRS document, into a form that is implement able using the programming language. Certain items such as modules, relationships among identified modules, data structures, relationships between the data structures, and algorithms for implementation should be designed during this phase. 1.1 Overview: This System Design provides the overall design of the Student Information Management system implemented during this project, covering the purpose and reasoning behind the system's major components. 1.2 Scope: The main scope of the system design is : Organize the system into modules Organize sub-modules for each module Allocate tasks to processors Choose an approach to manage data store Handle access to global resources Choose implementation logic
The basic idea behind System Design is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. 1.3 Background: The Student Information System records basic student information, Examination information, education information regarding student. Student management function involves : Manage student records Student Basic Information Manage course and specialty Manage semester and year Result management Subject management In Student Management System, administrator has a Login ID and Password. Also all the users have different permission rights to access the applications. There are two main roles in the system. Admin and operator. Admin has complete access to the whole system, while operator is the role that is responsible for the use of the system. 1.4 References: Systems Analysis and Design - Allan Dennis St. Philomena College
1.5 Assumptions and constraints: 1.5.1 Assumptions: The system is not required to save generated reports. The code should be free with compilation errors/syntax errors. The details must have an interface which is simple enough to understand. 1.5.2 Constraints: Internet connection is required. The constraints of this project are the system must support the latest web browser and must be able to run all the forms. Login and password is used for identification of administrator and there is no facility for users. 2 Applicable documents-methodology: This web application is developed for managing student details, examination details and attendance details. As the project is user friendly, it can be applied to large database with more information. This software can use by any sanitary administrator to make their work simple. They can get information quickly as possible. It can handle large volume of data and present reports whenever required. Structure of software Pacakage The main functional components are Administrator/Operator login. Course details. Subject details. Student records. Examination details.
Attendance records. Logout. 2.1 System Design Alternatives: Adobe Dreamweaver PHP Designer 2.2 Risks: The risk factors are, In case the database lost because of some OS failure or because of Anti Virus actions the software should have option for restore data. The restore is possible only if the backup maintained by the user is up to date. Otherwise the restore may failure or the restore point may not be up to date. 2.3 Updated Requirements Compliance Matrix: Since we are using PHP 5.2 version and MySQL 5.0 version, if there is any updates, upgrade Apache server to update PHP and MySQL. 3 Functional Decomposition-SYSTEM DESCRIPTION: The software is decomposed into several modules for the convenience of the user. The operator enters the student details, examination details, attendance details. In this all information are already stored in access. Here we can add, delete or update the existing records.
3.1 System Software Architecture: PHP INI Smarty PHP Apache Server MySQL MySQL Web Server Internet Server Fig 1.1 System Software Architecture 3.2 System Technical Architecture: Apache Server MySQl Server Web Server Template engine Administrator Fig 1.2 System Technical Architecture
3.3 System Hardware Architecture: In engineering, hardware architecture refers to the identification of a system's physical components and their interrelationships. This description, often called a hardware design model, allows hardware designers to understand how their components fit into system architecture and provides software component designers important information needed for software development and integration. Fig 1.3 System Hardware Architecture
3.4 External Interfaces: A. Name of application Student Information System B. Details of interface Admin login into the application user name and password. After successful login enters the details of new students details, course details, subject details, examination details, attendance details etc. Finally the details like students details examination reports, attendance details can be viewed by students, parents, teachers etc. C. Description of operational implications of data transfer, including security considerations Operational implication of the data transfer is done through validation. 4 Description of Programs Subsystem Specification: 4.1 CONTEXT FLOW DIAGRAM (CFD): A Context Flow Diagram is a top level (also known as level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities. In context diagram the entire system is treated as a single process and all its inputs, outputs, sinks and sources are Identified and shown.
Administrator Operator Controls Manages records Student Information System Information Report Reports Students Examination Attendance 4.2 Data Flow Diagram(DFD): Fig 1.4 Context Flow Diagram A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an Information System. A data flow diagram can also be used for the visualization of Data Processing. It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system being modeled. A DFD represents flow of data through a system. Data flow diagrams are commonly used during problem analysis. It views a system as a function that transforms the input into desired output. A DFD shows movement of data through the different transformations or processes in the system. Dataflow diagrams can be used to provide the end user with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram. The appropriate register saved in database and maintained by appropriate authorities.
NOTATION DESCRIPTION Processes or transform are represented by circles in a DFD. This shows what systems do. Each process has one or more data inputs and produces one or more data outputs. Each process has a unique name which appear inside the circle that represent the process in a DFD. The rectangle Is used to represent an external entity, that is a system element or another system that produces information for transaction by the software or receives the information produced by the software. An arrow represent one or data items or data objects. A data flow shows the flow of information from its source to its destination. A database is a holding place for information within the system. It is represented by cylindrical notation. Data stores may be long-term files or may be short-term.
4.2.1 Level 0: Admin/Operator Login Login Input Output Fig 1.5 Level 0 2.2 Level 1(Top Level DFD): Admin Login Admin Admin Admin Add Details Edit Details SelectCourse DeleteCourse SelectSubject DeleteSubject Student Details Course Subject Store Data Store Data Admin Admin Admin Stores Edit Details Stores Edit Details Adds Delete Examination Attendance Semester Store Data Store Data Store Data Fig 1.6 Level 1
4.2.3 Second Level DFD for Course and Subject: Administrator Create operators Stores in Add course Course details Add Operator Retrieves Add subject View Course Subject Fig 1.7 DFD for Course and Subject Subject 4.2.4 Second Level DFD for Semester: Upload student details Select course Operator Course Select / update semester Student Details Update Stores student info Course Student Details Semester Fig 1.8 DFD for Semester
4.2.5 Second Level DFD for Attendance: Select course Operator Select semester Course Details View Course Semester Select subject Subject details View Add attendance details Subject Attendance Details Updates Attendance Attendance Fig 1.9 DFD for Attendance
4.3 Description of components: 4.3.1 Functional component 1: Login 4.3.1.1 Input: Admin name and password. 4.3.1.2 Output: Allows administrator to enter into a new page. 4.3.1.3 File I/O interface: Functional components login when clicked after giving the username and password correctly it takes us to a new page which is the home page, with other functional components. 4.3.2 Functional component 2: Student details 4.3.2.1 Input: reg.no, first name, last name, dob, fathers name, sex, address, contact no, course, semester. 4.3.2.2 Output: Details of each and every students. 4.3.2.3 File I/O interface: This module is not related to other functional components. 4.3.3 Functional component 3:Course details 4.3.3.1 Input: course id, course name, comment, course key. 4.3.3.2 Output: All the entered data will be stored in respective database and will be displayed in the grid. 4.3.3.3 File I/O interface: This module is not related to other functional components. 4.3.4 Functional component 4:Subject details 4.3.4.1 Input: subject id, subject name, comment, course, subject type, semester. 4.3.4.2 Output: All the entered data will be stored in respective database and will be displayed in the grid. 4.3.4.3 File I/O interface: This module is not related to other functional components.
4.3.5 Functional component 5:Examination details 4.3.5.1 Input: course, semester, internal type,marks. 4.3.5.2 Output: All the entered data will be stored in respective database and will be displayed in the grid. 4.3.5.3 File I/O interface: This module is not related to other functional components. 4.3.6 Functional component 6:Attendance details 4.3.6.1 Input: course, semester, subject, total classes. 4.3.6.2 Output: All the entered data will be stored in respective database and will be displayed in the grid. 4.3.6.3 File I/O interface: This module is not related to other functional components.
Student Information System Team code: 111201 Submitted by: Priya H J (091540623) Shruthi K (091540643) Submitted to: Mr. Vinayachandra Department Of Computer Science St.Philomena College, Puttur External guidance by: Aravinda.M.V Technopulse City Light Building, Balmatta Road, Mangalore 575003 Date of submission: 06/01/2012