PROJECT SECME

Detailed Design

SOFTWARE ENGINEERING FALL 2002

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

10/22/02

Carthik A Sharma

Initial Version - Submitted

...

 

 

 

 

 

Team Name: TEAM SECME

Team Members:

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

 

Design Issues: 

                Please refer to the Use cases description to see the precursor of the design. The Use cases form the basis form the basis for the development of the design of the product.

                In this detailed design document, the Entity-Relationship Diagram and the Class Diagram are given, and these form an accurate representation of the design of the system.

                The following is a description of the issues faced in the design and how they were overcome:

1)       Modification of Information

The issue faced was that , for example, when the school coordinator changes just one parameter in the registration information of a particular student, then it is a difficult task to modify just that particular information about the student. The complexity involved in the implementation and the shortage of time lead to implement this function of modification by defining modification as a deletion followed by an insertion of a record. Analysis shows that this is a very reasonable tradeoff and the time saved in coding and maintaining the system as well as the ease of implementation justifies this design decision. This is the standard procedure followed for all “modification” of data in the software.

2)       Accessing the Database

Various modules in the system need to access, as also delete from, and insert data to, the database. In order to simplify the implementation of these database accesses and writes, a general class ConnectionManager has been defined, which is the only class which will have to interact with the database.

3)       Email and Inquiries

The system , in its final form will have the ability to provide for better communication between the users using the email function. The “to” address has to be dynamically fetched from the database each time the email(s) has to be sent, also, the school coordinators need to have the option of sending queries whenever they face a problem, and the “from” address of the email as well as the return address need to be dynamically fetched. Since the inquiry and email functions have to be thus implemented, and also since these functions have multiple points of access on the website, a separate class called Email has been defined which simplifies the design.

4)       Adding Event Details

We decided to maintain the registration details for succeeding years because it may help in a statistical analysis of the data regarding the MECSP- SECME programs. The historical data will be stored in the database but will not be visible to the end users, since it will add to the complexity and not add any considerable vale to the system. This was done keeping in mind the fact that the end product should be a user friendly system. This decision thus is a via-media between user friendliness and historical data collection. However, preserving the data over the years meant that the events in the annual competition to which are mapped the registration information of the corresponding year’s annual competition should remain as such, thus , we arrived at the decision that the details of a specific event in the annual competition can only be modified by creating a new event, with the new (differing) characteristics, so that the old event is preserved unmodified. This decision is made easier by the fact that the annual competition is defined only once a year, and the changes to the rules are minimal, from experience related by the client. We hope that this design decision will come of use in the future when the historical data needs to be retrieved.

5)       Organization of data

The data has been organized thus: there is a class Student, a class School, and a class CoOrdinator. The tables in the ER diagram show the conceptual scheme of the database. The classes are linked together in the specific way shown in the class diagram in this document because this leads to modularity of data, and ease of data management. The tables in the database are also organized by function, and so we have a student, a school, and a coordinator table to facilitate actions on the database.

                These decisions were taken in a democratic manner during the team meeting that took place on the 12th, 16th, 19th and 21st of October.

Detailed Design Information:

The Class Diagram and the Entity- Relationship Model are given below. A detailed class diagram can be referenced here

CLASS DIAGRAM

 

The above figure shows the conceptual schema of the database, which we are going to create for this project.

 

 

USER TABLE:

 

     The data in this table will be filled by the MECSP organizer. The description about each field in this table is given below.

 

    

US_USERID – This field represents the ID of the user, which is assigned to each and every user who uses the system. Data type – Integer.

 

US_SCHOOL_LOGIN_ID  – This field represents the Login ID given to every school, using which the user logs in to the SECME system. Data type – varchar.

 

US_PASSWORD  – This field represents the Password used by the user to log into the MECSP system after entering the SCHOOL_LOGIN_ID. Data type – varchar.

 

US_FNAME – This field represents the First Name of the user, stored for reference purposes. Data type – varchar.

 

US_MNAME – This field represents the Middle Name of the user, stored for reference purposes. Data type – varchar.

 

US_LNAME – This field represents the Last Name of the user, stored for reference purposes. Data type – varchar.

 

US_EMAIL – This field represents the Email Address of the user, stored for reference purposes. Data type – varchar.

 

 

SCHOOL TABLE:

 

     The data in this table will be filled by the MECSP organizer. The description about each field in this table is given below.

 

 

SC_ID – This field represents the School ID given to each school, stored for reference purposes. Data type – varchar.

 

SC_NAME – This field represents the Name of each School for which the ID is created.

Data type – varchar.

 

SC_ADDRESS – This field represents the address of each school, stored for reference purposes. Data type - varchar. 

 

SC_PHONE - This field represents the phone number ooof each school, stored for reference purposes. Data type - varchar.

 

SC_FAX - This field represents the fax number of each school, stored for reference purposes. Data type - Integer.

 

SC_UID1 - This field represents the UserID of the School Coordinator-I of the particular school who actually access the SECME system. Data type - Integer.

 

SC_UID1 - This field represents the UserID of the School Coordinator-II of the particular school who can also access the SECME system. Data type - Integer.

 

 

ANNUAL_COMPETITION TABLE:

 

     The data in this table will be filled by the MECSP organizer. The description about each field in this table is given below.

 

 

AC_DATE - This field represents the date at which the annual competition will occur. Data type - Date.

 

AC_DEADLINE - This field represents the date before whhhich the schools have to register for the annual competition. Data type - Date.

 

AC_COMP_ID - This field represents the Annual Competiiition ID, stored for reference purposes. Data type - Integer.

 

 

EVENT TABLE:

 

     The data in this table will be filled by the MECSP organizer. The description about each field in this table is given below.

 

 

 

EV_ID - This field represents the ID given for eeeach event, stored for reference purposes. Data type - Integer.

 

EV_NAME - This field represents the Name for each event corresponding to their ID's. Data type - Varchar.

 

EV_COMP_ID - This field represents the Competition IDDD, stored for reference purposes. Data type - Integer.

 

EV_NUMBER_IN_TEAM - This field represents the maximum numberrr of students who can actually participate in that particular event. Data type -Integer.

 

EV_RULES - This field represents the rules and prerrrequisites for participating in a particular event. Data type - varchar.

 

EV_DATE_TIME - This field represents the date and time at which the particular event will take place. Data type - Date/Time.

 

EV_VALID - This field purpose is to decide whether the particular event has to be displayed in the Registration_Annual.jsp page or not. Data type - Boolean.

 

 

REGISTRATION_ANNUAL TABLE:

 

     The data in this table will be filled by the School Coordinator. The description about each field in this table is given below.

 

 

ACR_STU_FNAME - This field represents the First name of the student who will participate in an event. Data type - varchar.

 

ACR_STU_MNAME - This field represents the Middle name offf the student who will participate in an event. Data type - varchar.

 

ACR_STU_LNAME - This field represents the Last name of ttthe student who will participate in an event. Data type - varchar.

 

ACR_STU_EVENTID - This field represents the ID of the evennnt in which the student will participate. Data type - Integer.

 

ACR_SC_ID - This field represents the ID of the schooool to which the student belongs to, stored for reference purposes. Data type - Integer.

 

ACR_STU_GLEVEL - This field represents the Grade level offf the student participating in an event. Data type - Integer.

 

ACR_STU_MATHLEVEL - This field represents the Math level of the student participating in an event. Data type - varchar.

 

ACR_STU_DATE_TIME - This field represents the Date and Time at which the school coordinator filled in all the details for each row in the

REGISTRATION_ANNUAL table. Data type - varchar.

 

ACR_STU_SUBMIT - This field represents whether all the deeetails for each row filled in by the school coordinator has been in the

REGISTRATION_ANNUAL table has been submitted to the SECME database or not, stored for reference purposes. Data type - Boolean.

 

 

WORKSHOP TABLE:

 

The data in this table will be filled by the MECSP organizer. The description about each field in this table is given below.

 

 

WK_ID - This field represents the ID given for eeeach workshop, which will take place. Data type - Integer.

 

WK_NAME - This field represents the Name of the wooorkshops corresponding to their ID's. Data type - Varchar.

 

WK_DATE_TIME - This field represents the Date and the TTTime at which the workshop will take place. Data type - Date/Time.

 

WK_DESCRIPTION - This field represents the brief descriptttion about each workshop. Data type - varchar.

 

WK_DEADLINE_DATE - This field represents the date before whhhich the schools have to register for the workshop in order to participate. Data type - Date.

 

REGISTRATION_WORKSHOP TABLE:

 

The data in this table will be filled by the School Coordinator. The description about each field in this table is given below.

 

 

WKR_ID - This field represents the workshopID forrr which the school registers. Data type - Integer.

 

WKR_SC_ID - This field represents the ID of the schooool, which registers for the workshop. Data type - Integer.

 

WKR_NO_STUDENTS - This field represents the number of studddents who will participate in the workshop. Data type - Integer.

 

WKR_DATE_TIME - This field represents the Date and Time at which the school coordinator fills in the details in then REGISTRATION_WORKSHOP table. Data type - Date/Time.

 

Trace of Requirements to Design:           

No.

Requirement Statement

Method, Class Used to Satisfy Requirement

1

Ability to support multiple school participation in the registration process.

addSchool(), addSchoolCoordinator(),SchoolInfo

2

Ability to display general guidelines for the schools.

Next Phase

3

Ability for users to connect to the SECME national website.

Next Phase

4

Ability to define two school coordinators for each of the participating schools

addSchoolCoordinator(),SchoolInfo

4.a

Each school coordinator will have an id and password, with each school having a single user id, and password.

addSchool(), addSchoolCoordinator(),SchoolInfo

4.b

Each school coordinator will have an email address that will be used to notify him/her about upcoming events like annual competition and workshops.

addSchool(), addSchoolCoordinator(), SchoolInfo

5

Ability to define upcoming workshops

addWorkshop(), Workshop

5.a

Each workshop will have a date and time of conduction.

addWorkshop(), Workshop

5.b

Each workshop will have details like the workshop subject, description and rules.

addWorkshop(), Workshop

5.c

Each workshop will have a registration deadline (in terms of date).

addWorkshop(), Workshop

5.d

Each workshop will have a limit on maximum number of participants.

addWorkshop(), Workshop

6

Ability to define upcoming annual competition

modifyCompetition(), modifyEvent(), Competition, Event

6.a

Competition will have a date of conduction.

modifyCompetition(), Competition

6.b

Competition will have a registration deadline (in terms of date)

modifyCompetition(), Competition

7

Ability to define multiple events for the competition

modifyEvent(), Event

7.a

Each event will have a date, time and location of conduction.

modifyEvent(), Event

7.b

Each event will have details like an event description and rules

modifyEvent(), Event

7.c

Each event will have a limit of the maximum number of participants.

modifyEvent(), Event

8

Ability for school coordinators to post messages or queries from the website.

sendInquiry(), Email

9

Ability to define MECSP organizer

getUserType(), Logon

9.a

The organizer will have an email address

getUserType(), Logon

9.b

All questions posted by school coordinator will be sent to this email address 

sendInquiry(), Email

10

Ability to differentiate between school user and MECSP user.

getUserType(), Logon

11

Ability to store following information with respect to school, coordinators and students

N/A

11.a

School: name, type, phone, fax

retrieveSchool(), School, SchoolDetails

11.b

Coordinator: name, email address

retrieveSchool(), School, CoOrdinator

11.c

Student: name, grade level, math level.

retrieveStudent, Student, RegCompetition

12

School users (i.e. school coordinators) can: 

N/A

12.a

Register for the annual competition and workshop online.

RegCompetition, RegWork

12.b

View/modify information about participants of their schools alone.

retrieveStudent(), retrieveEvents

12.c

Review and modify the participant’s information before completing the registration process.

Next Phase

12.d

Modify participant’s information after it has been posted for registration process but before the registration deadline.

retrieveStudent(),deleteStudent(), submitRegInfo(), RegCompetition

12.e

Receive confirmation of submission/modification of data.

Next Phase

13

Ability to notify the MECSP organizer by email whenever school registration information is added or modified, i.e., whenever the school coordinator submits/modifies the school registration form.

sendNotification(), Email

14

MECSP users will be able to:

N/A

14.a

Define the competition and workshops.

Competition, Event, Workshop

14.b

Define school coordinators and their information.

addSchool(), addSchoolCoordinator(),SchoolInfo

14.c

View the details of the school coordinators, for the different schools.

retrieveAllSchools(), SchoolDetails

14.d

Notify via email all participants about the upcoming workshop or annual competition. All email will have a carbon copy sent to MECSP organizer as well.

sendMessage(), Email

14.e

View information about all the participating schools and their students in relation to the competition or a workshop.

retrieveSchoolWorkInfo(), retrieveAllSchools(), SchoolDetails, RegWork, RegCompetition

14.f

View summary of whole annual competition with school, the events and the students within each event in a tabular format

retrieveAllSchools(), SchoolDetails

14.g

View summary of competition filtered by school type providing information on school, events and the students within each event in a tabular format.

retrieveByType(), SchoolDetails

14.h

View registration information, with the ability to view all submissions/updates received from a specified date, till a specified date.

retrieveAllSchools(), SchoolDetails

14.i

View student information with respect to Math level of the students.

retrieveByMathLevel(), SchoolDetails

15

Both users should be able to sign in/out of the system using their own id and password.

logout(), login(), getUserType(), Logon

16

An enhanced user interface is required which will provide easy navigation and better look and feel.

Next Phase

 

Data Requirements: Previous registration information will be retained for historical reasons.

Competition, Workshop, see Design Issues 4

 

Security Requirements: Both types of users (MECSP user and school coordinator) have respective security requirements. School coordinator will be able to modify only his school's information while MECSP user will be able to view and define upcoming event information.

Logon

 

All other requirements are not applicable to the system. Please Refer to the SRS for details.

 

 

 

Template created by G. Walton (GWalton@mail.ucf.edu) on August 15, 2000

This page last modified by Carthik A Sharma (appcash@yahoo.com ) on October 21, 2002