Dojoman
Design
Document
XYZz Software.
Contracted by Acme Tae Kwon Do
ICS 52
Summer 2003
Instructor: Michele Rousseau
Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted.
Permission is hereby granted to reprint or retransmit this document, in original, printed or photocopied format as required.
© 2003 The Regents of the University of California. All Rights Reserved Worldwide.
Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Table of Contents
1Introduction
2Architecture Style
3Module Design
3.1User Interface Manager Module
3.2Report Generator
3.3Student Management
3.4Database
4Abstract Data Types
5Comprises Diagram
6Uses Diagram
1Introduction
This document presents an overview of the main architectural style for the Dojoman system. It is based on the official requirements document for the same system, as developed by XYZz Corporation.
Dojoman is a student management system for Acme Tae Kwon Do (ATKD) studio. It enables the users (staff members primarily) to keep track of student’s records, generate reports as well as maintain and update the information. XYZz Software has been hired to develop the complete system.
In this document we describe the system design in terms of modules, sub-modules, their relationships, and behavior. Other aspects of the system such as the database are also described in detail. The system will be implemented in modules. It will be broken down so each module is easy to implement and integrate.
2Architecture Style
The Dojoman system is designed using a combination of Repository and layered approach. The layered approach tends to allow for a good separation of concerns and the repository model is well suited because there would be separate parts of the system interacting with the database. This along with the layered approach allows for good separation of functionality at different layers hence enhancing the performance of the system. This would also facilitate the independent evolution of modules at different layers without much dependence on modules above it. Any layer above is totally dependent on the layer below for data and communication, thus also making it secure. The layered approach will also assist any future enhancements to the user interface as that would not affect any functionality below it and any enhancements at lower levels would require adding additional sub-modules which would have independent functionality from the ones already existing hence minimizing the work load.
The following diagram depicts the high level architecture of the Dojoman System.
User Interface Manager:
The User Interface Manager module is concerned with separating the functionality for the different types of users. The most important function of this module is managing the user UI and providing information to the user. For the purpose of this design we do not consider the functionality of different types of users, i.e. we ignore separate functionality.
Student Management:
Student management module is the main module of the system where all the processing of the student information is done based on the input received from the upper level modules. It is the primary means of manipulating the database. The report generator module does not have “write” privileges of the database but this module has privileges to insert, delete, and update records of students.
Report Generator:
Report Generator accesses desired information from the database to appropriately compose the desired report. The reports are generated based on the request from the user that is directed from the user manager that also displays the information.
Database:
Database is the central repository where all the information pertaining to a student is stored, primarily a Microsoft Access database.
3Module Design
This section provides detailed module level design. Here we specify the details of each module by breaking it up into sub-modules. All the modules from the high-level architecture are broken down into sub-modules. In this section we describe all the modules, sub-modules and their interactions.
3.1User Interface Manager Module
Purpose
The purpose of the UI Manager module is to provide the functionality that is needed by a regular staff member for managing student information. This module provides the UI for adding, deleting, searching, and presenting reports to staff members.
The sub modules of this module are:
1) Module Student Information is responsible for adding, deleting, updating student information.
2) Module Medical Information is responsible for adding, updating student’s medical information.
3) Module General Information is responsible for adding, updating student’s general information.
4) Module Report is responsible for generating various reports.
5) Module Search is responsible for searching and displaying the search results.
Provided Interface
This module is a top-level module, so it does not provide any interface.
Required Interface
The required interface for this module is provided in part by Student Management Module as well as Report Generator module. The required interface of this module is a combination of the required interfaces of the sub-modules
3.1.1Login
Purpose
This sub-module is authenticating the user and logging him/her into the system.
Provided Interfaces
Boolean authenticateUser (String login, String password);
Description: This method authenticates the user to use the system
Return Type: Returns if the user is valid
Parameter: login – the login name supplied
password – the password supplied
Required Interfaces
None at this stage as it uses a file and not a database for authentication.
3.1.2Student Information
Purpose
This sub-module is responsible for providing the staff member with the UI for adding, updating, and deleting student information.
Provided Interfaces
None
Required Interfaces
boolean addStudent(StudentInfo student)
Description: This method adds a student to the database
Return Type: Returns if the student has been added successfully
Parameter: StudentInfo, is an ADT that gets the student information from the UI to be stored in the database, it is defined as,
StudentInfo{
String lastName,
String firstName,
String parentsName,
Boolean holdHarmAgree,
String class,
Boolean active,
String notes,
Int beltSize,
Int Gup, //stands for belt color
Date birthdate,
String homePhone,
String workPhone
String address,
StringCity,
String zip
}
int updateStudent (String studentID, StudentInfo student)
Description: This method updates the student information in the database
Return Type: Returns if the student has been updated successfully
Parameter: studentID is the unique ID to identify the student.StudentInfo, is an ADT that gets the student information as defined above.
Boolean deleteStudent (String studentID)
Description: This method deletes the student’s information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
Boolean deleteGeneralInfo (String studentID)
Description: This method deletes the student’s general information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
Boolean deleteMedicalInfo (String studentID)
Description: This method deletes the student’s medical information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
3.1.3General Information
Purpose
This sub-module is responsible for providing the staff member with the UI for adding, updating, and deleting student’s general information.
Provided Interfaces
Boolean deleteGeneralInfo (String studentID)
Description: This method deletes the student’s general information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
Required Interfaces
boolean addGeneralInfo(String studentID, GeneralInfo genInfo)
Description: This method add student’s general information to the database. The student has to be present before adding this information
Return Type: Returns if the information has been added successfully
Parameter: GeneralInfo, is an ADT that gets the student’s general information from the UI to be stored in the database, it is defined as,
GeneralInfo{
String Email,
String PrevMartArts
String PMAStyle,
String PMAWhen,
String PMAWhere,
String PMABelt,
String IntSelfC,
String IntSelfD,
String IntDisc,
String IntFit,
String IntConc,
String IntComp,
Date DateSigned,
String IntOther,
String Reference,
Date StartDate,
Int Dues
}
int updateEmail (String studentID, String newEmail)
Description: This method updates the student’s email address in the database
Return Type: Returns if the field has been updated successfully
Parameter: studentID is the unique ID to identify the student.NewEmail is the new email id of the student.
Boolean deleteGeneralInfo (String studentID)
Description: This method deletes the student’s general information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
3.1.4Medical Information
Purpose
This sub-module is responsible for providing the staff member with the UI for adding, updating, and deleting student’s medical information.
Provided Interfaces
Boolean deleteMedicalInfo (String studentID)
Description: This method deletes the student’s medical information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
Required Interfaces
boolean addMedicalInfo(String studentID, MedicalInfo medInfo, EmergencyInfo emInfo)
Description: This method adds student’s medical/emergency information to the database. The student has to be present before adding this information
Return Type: Returns if the information has been added successfully
Parameter: MedicalInfo, is an ADT that gets the student’s medical information from the UI to be stored in the database, EmergencyInfo is an ADT that gets the student’s emergency contact information from the UI to be stored in the database, they are defined as,
MedicalInfo{
String AllergiesSpecialCond,
String FactorsEffectCareQ,
String FactorsEffectCare,
String MedProbsQ,
String MedProbs
}
EmergencyInfo{
String EmPhone,
String AltEmPhone,
String EmContact
}
int updateEmergencyContact (String studentID, EmergencyInfo emInfo)
Description: This method updates the student’s emergency contact information in the database
Return Type: Returns if the student has been updated successfully
Parameter: studentID is the unique ID to identify the student.EmergencylInfo, is an ADT that has the student’s emergency information as defined above.
Boolean deleteMedicalInfo (String studentID)
Description: This method deletes the student’s medical information from the database
Return Type: Returns if the student has been deleted successfully
Parameter: studentID is the unique ID to identify the student.
3.1.5Report
Purpose
This sub-module is responsible for displaying the reports to the students. It provides the UI for displaying the reports
Provided Interfaces
None
Required Interfaces
EmergencyRep[] getEmergencyInfo ();
Description: This method generates the report for emergency contact information of provided students
Return Type: Returns emergency contact information, the ADT is defined below
Parameter: None.
EmergencyRep{
Int studentID,
String lastName,
String firstName,
String EmPhone,
String AltEmPhone,
String EmContact
}
StudentInfo[] getStudentInfo ();
Description: This method generates the report for student information of provided students
Return Type: Returns student information
Parameter: None.
BeltInfo[] getBeltInfo ();
Description: This method generates the report for students in various category of belts information of provided students. Information to be color coded and grouped by belt color
Return Type: Returns Belt information in an ADT BeltInfo, described below
Parameter: None
BeltInfo{
Int StudentID,
String lastName,
String firstName,
String BeltColor,
}
3.1.6Search
Purpose
This sub-module is responsible for displaying the search results to the staff members. It provides the UI for displaying the results and performing the search. We implement only two types of searches, search student by student ID and search student by last name.
Provided Interfaces
None
Required Interfaces
StudentInfo getStudentInfo (int studentID);
Description: This method generates the report for student information of provided students
Return Type: Returns student information
Parameter: searches by student ID.
StudentInfo[] getStudentInfo (String lastName);
Description: This method generates the report for student information of provided students
Return Type: Returns student information
Parameter: searches by student last name.
StudentInfo[] getStudentInfo (String beltColor);
Description: This method searches for students in a category of belt
Return Type: Returns student information in an ADT BeltInfo
Parameter: beltColor based on which search is to be performed
3.2Report Generator
Purpose
The purpose of the Report Generator module is to provide the functionality needed to communicate with the database to generate the various reports that are requested by the User Interface Manager Module. It only has read access to the database and retrieves all the information that is asked for by the user manager module. The module is sub-divided into two sub-modules, one is responsible for communicating with the Database while the other is responsible for communicating with the user interface manager.
Provided Interface
The report generator module provides most of the interfaces that are required by the user interface manager module for displaying reports. The functions are
EmergencyRep[] getEmergencyInfo ();
BeltInfo[] getBeltInfo ();
StudentInfo[] getStudentInfo ();
Required Interface
The required interfaces are the same as the provided interface as the same functionality is expected from the database.
3.2.1Report Generator UI
Purpose
This sub-module provides the functionality that is required by the User interface manager module for displaying the reports.
Provided Interface
Same as provided interface of the module.
Required Interface
Same as the provided interface of the sub-module.
3.2.2Database Comm
Purpose
This sub-module provides database communication. This allows for good separation of concerns and performance gains.
Provided Interface
Same as that of Report Generator UI sub-module.
Required Interface
None, since this is the lowest level sub-module above the database.
3.3Student Management
Purpose
The purpose of the Student Management module is to provide the functionality needed to communicate with the database to add, update, and delete student information from the database. This module has write access to the database. This module takes in information from the user interface manager and modifies the database.
Provided Interface
The report generator module provides most of the interfaces that are required by the user interface manager module for displaying reports. The functions are
EmergencyRep[] getEmergencyInfo ();
BeltInfo[] getBeltInfo ();
StudentInfo[] getStudentInfo ();
Boolean addStudent (StudentInfo student);
boolean addGeneralInfo(String studentID, GeneralInfo genInfo)
Boolean addMedicalInfo (String studentID, MedicalInfo medInfo, EmergencyInfo emInfo);
int updateEmail (String studentID, String newEmail);
int updateStudent (String studentID, StudentInfo student);
int updateEmergencyContact (String studentID, EmergencyInfo emInfo)
Boolean deleteStudent (String studentID);
Boolean deleteGeneralInfo (String studentID);
Boolean deleteMedicalInfo (String studentID);
StudentInfo getStudentInfo (int studentID);
StudentInfo getStudentInfo (String lastName);
StudentInfo getStudentInfo (String beltColor);
Required Interface
The required interface is the same as the provided interface, because all calls are made to the database layer which provides all the functionality.
3.3.1Student Management UI
Purpose
This sub-module provides all the functions that are needed by the user interface manager for managing students. This is used separately from database communications to provide for good separation of concerns and performance gains.
Provided Interface
Same as that of main module.
Required Interface
Same as that of the sub-module.
3.3.2Database Comm
Purpose
This sub-module provides database communication. This allows for good separation of concerns and performance gains.
Provided Interface
Same as that of Student management UI sub-module.
Required Interface
None.
3.4Database
Purpose
The database is used for persistent storage of data. This is where the student information is stored currently. It has one table that stores all the information. This is the design for simplicity purposes and will be changed in the future.
Data Structure
Here we explain the various fields of the database, some of the fields are self-explanatory and might not require any mention.
"ID" – lists the student ID
"LastName" – the students last name
"FirstName" – the students first name
"ParentsName" – the students parent name in case of minor
"HoldHarmAgree" – a yes/no field if the student holds the studio harmless in case of injury
"Class" - Whether the student is enrolled in the early or late class
"Active" – whether the student is currently active/attending classes etc.
"Notes" – free form field for entering comments
"BeltSize" – beltsize of student, here for future use
"Gup" – the gup corresponds to the color of the belt (more information below)
"Birthdate" – birthdate of the student
"Home_Phone"
"Work_Phone"
"Address"
"City"
"Zip"
"EmPhone" – Emergency phone for the student
"AltEmCont1" – Emergency Contact (other then parents)
"AllergiesSpecialCond" – medical conditions, allergies that need to be taken care of in emergencies
"FactorsEffectCareQ" – did they check yes to “Are there factors that may effect the care of you/your child? “
"FactorsEffectCare" – what were the Factors that effect their care – if any.
"MedProbsQ" – did they check yes to ”Do you/your child have any injuries, handicaps, or medical problems?
"MedProbs" – what medical problems do they have
"Email" – email address of the student