Software Requirements Specification 3



Software Design Description 2.0

Googolplex Dental Office Scheduling System

Team 2: Peter Anania, Vijay Gangareddygari, Ronald Olaski,

Nicole Staretz, and Melisa Tyira

SE 516 Engineering of Software Systems

Fall 2002

Table of Contents

1. Introduction 4

1.1 Purpose of the document 4

2. References 4

3. Overview of the Document 5

4. 4+1 View Model of Architecture of the system 5

4.1 Logical View 6

4.2 Process View 8

4.3 Development View 10

4.4 Physical View 12

5. Architectural Design 13

5.1 Googolplex Dental Office System Level Architecture 13

Name: Googolplex Dental Home Page 13

5.2 Boundary Servlet 14

Name: Boundary 14

5.3 Control Servlet 15

Name: Control 15

5.4 Control Home Servlet 17

Name: Control Home 17

5.5 Control Search Servlet 17

Name: Control Search 17

5.6 Control Choose Entity Servlet 18

Name: Control Choose Entity 18

5.7 Control View Edit Patient Servlet 19

Name: Control View Edit Patient 19

5.8 Control View Edit Appt Servlet 20

Name: Control View Edit Appointment 20

5.9 Control Add New Patient Servlet 20

Name: Control Add New Patient 20

5.10 Control Add New Appt Servlet 21

Name: Control Add New Appointment 21

5.11 Control View Schedule Servlet 22

Name: Control View Schedule 22

5.12 Control View Week Schedule Servlet 23

Name: Control View Schedule By Week 23

5.13 Entity Appointment Servlet 23

Name: Entity Appointment 25

5.14 Entity Person Servlet 26

Name: Entity Person 26

5.15 Entity Employee Servlet 26

Name: Entity Employee 26

5.16 Entity Patient Servlet 27

Name: Entity Patient 27

5.17 Database Initialization Servlet 28

Name: DB Init 28

6. Data Structure Design 29

6.1 Team2_Dent Database 29

6.2 Database Description 30

7. Use Case Realizations 31

7.1 Use case: Enter Patient data 32

7.2 Use Case: Enter Appointment Data 33

7.3 Use case: View Patient Data 33

7.4 Use Case: View Schedule by Month 35

7.5 Use Case: View Schedule by Dentist 36

7.6 Use Case: View Schedule by Dental Assistant 37

7.7 Use Case: View Schedule by Patient. 38

7.8 Use Case: Modify Patient Data 39

7.9 Use Case: Modify Appointment Data 40

7.10 Use Case: Delete Patient 41

7.11 Use Case: Delete Appointment 42

8. User Interface Design 43

8.1 Index.html 44

8.2 Person Search 45

8.3 Patient Search 46

8.4 Choose Appt 47

8.5 View/Edit Patient, View/Edit Appointment 48

8.6 New Patient 50

8.7 View Schedule 52

8.8 Weekly Schedule View 53

1. Introduction

1.1 Purpose of the document

This document contains the complete design description of the Googleplex Dental Office Scheduling System. This includes the architectural features of the system down through details of what operations each code module will perform and the database layout. It also shows how the use cases described in the SRS will be implemented in the system using this design.

The primary audience of this document is the software developer.

1.2 Scope

This Software Design Document provides a complete description of the design of the GDOSS developed for the Googleplex Dental Office – Scranton, Pennsylvania. The dominant design methodology is an object-oriented design using a web interface to a database management system.

The system once working will allow the secretary to schedule appointments for any day in the future and update this data, the secretary upon request can then display this information. In addition, a mechanism will exist that allows the secretary to view the dentist, dental hygienist and dental assistant schedules as well.

The Googolplex Dental Office Scheduling System application is a web-based system and will be written to conform with Internet Explorer v5.5 or higher. The system would be developed in Java with PostgreSQL as the database. The system handles the user requests using the java servelets, which access the database using JDBC to retrieve information, and generates the html pages.

1.3 Glossary

|G-DOSS |Googolplex Dental Office Scheduling System |

|URL |Uniform Resource Locator |

|HTTP |Hypertext Transfer Protocol |

|JDBC |Java Database Connectivity |

|CGI |Common Gateway Interface |

|Boundary Classes |These are used to model interaction between the system and its actors. |

|Control Classes |These are used to represent coordination, sequencing, transactions, and control of other objects. |

|DBMS |Database Management System |

2. References

Googolplex Dental Office Scheduling System, Software Requirements Specification 3.0.

3. Overview of the Document

The document contains the following sections and their contents are

• Section 4 is the 4+1 View Model of Architecture of the system that depicts the architectural diagrams for the system. The 4+1 model presents four views of the architecture: Logical View, Process View, Development View and Physical View.

• Section 5 is the Architectural Design. This is the heart of the document. It specifies where each design entity will reside and the design entities that collaborate to perform the functionality of the system.

• Section 5 is the basic Data Structure Design, which for this project is a relational database. It describes the database schema of the system.

• Section 6 exhibits the Use Case Realizations. The implementation of each use case identified in the SRS is shown using the services provided by the design objects.

• Section 7 describes the User Interface Design.

4. 4+1 View Model of Architecture of the system

The architectural diagrams for the G-DOSS are based on the ‘4+1 View Model of Architecture’, proposed by Phillipe Krutchen. This model suggests four views of the architecture: Logical View, Process View, Development View and Physical View. In addition to these four views, scenarios are provided hence, ‘+1’.

• The Logical View depicts the system’s architecture.

• The Process View describes concurrency and synchronization issues.

• The Development View describes the software with respect to the development environment.

• The Physical View maps the software onto hardware components. The physical view shows the deployment of the system.

4.1 Logical View

Diagram:

[pic]

Description:

This view shows the essential architecture of the system. The G-DOSS system will be

built using a 2 – tier structure, where functional components exist both on the server machine and on the client machine.

The client side of the system will be composed of a browser and a page. The page will in turn be composed of at least one of the following three components: the html code that makes the page, the CGI code that creates the forms and the JavaScript that will populate drop down lists and the like. This page will be assembled from this/these part/s by the software residing on the server side.

On the server side the system will be composed of several classes, a JavaScript library, the Java libraries and packages, the OS and a DBMS.

4.2 Process View

Diagram:

[pic]

Description:

This view shows how the components mentioned in the logical view interact. The client requests are issued via the node and sent (via IP address) to the server. The Boundary object, an instantiation of the Boundary class, responds to these requests. The Boundary object employs the ‘Factory’ design pattern to instantiate the Control classes as needed.

The instantiated control object will serve the request issued from the node. Depending on the request from the node the control object may instantiate entity objects, use JavaScript library components and/or use text files to fulfill the request. The control object then itself becomes the page requested and returns to the node.

4.3 Development View

Diagram:

[pic]

Description:

This view shows how the system is intended to be built. The system is depicted as a layered architecture. The outer most layer of the system is the “Human Communication Interface” layer, which is a web page, viewed on a browser. The web page is comprised of three parts: the html code, the CGI code and the JavaScript. These components reside on the second layer – “The Request Fulfillment Systems” layer. These components reside in the same layer as they are built together and share data to complete the process. The next layer, which is the “The Entities and Page Components” layer, consists of the objects that will be used to construct the finished product. Each of these can be developed separately and simultaneously. The entity classes when instantiated as objects will access the data from the database. The next layer is called the Java Development Kit, Software Development Kit, Java Virtual Machine and Database layer, as is appropriate for the operating system. As the classes above are built from the java libraries and packages, they must all reside in layers above the libraries and packages.

The final layer is the “The Operating System” layer that holds all the necessary low-level support for the Java libraries.

The layers can communicate with objects in their own layer and only one object in each layer can communicate with adjacent layers.

4.4 Physical View

Diagram:

[pic]

Description:

This view shows the physical components the system. The system has a two-tiered architecture.

5. Architectural Design

Refer to the Process View Diagram in the preceding section for an overview of the architecture components depicted in the architectural design section. This section specifies the design entities that collaborate to perform the functionality of the system. Each of these entities has an Abstract Specification and an Interface that expresses the services that it provides to the rest of the system. In turn each design entity is expanded into a set of lower-level design units that collaborate to perform its services.

5.1 Googolplex Dental Office System Level Architecture

Name: Googolplex Dental Home Page

Type: index.html

Description: This is the home page for the Googolplex Dental Office System software. It displays all the main links and provides the navigation for the system.

Operations:

Page is Loaded

No arguments.

No return value.

Pre-condition: None.

Post-condition: System is ready for use.

Exception: None.

Flow of Events:

1. The Secretary navigates to the Googolplex Dental Home Page.

2. The logon screen appears.

Logon ()

No arguments.

No return value.

Pre-condition: index.html page loaded.

Post-condition: Logon passes/fails.

Exception: None.

Flow of Events:

1. The Secretary logs on to the system.

2. The logon method returns either pass or fail

3. Failure returns an error message and displays the logon screen again.

4. Success displays the main page.

5. The system awaits a menu choice or an exit command.

See also Test Design, Unit Test: Logon.

Home

Home is a link to index.html.

Pre-condition: User is successfully logged on to system.

Post-condition: index.html

Flow of Events:

1. The user click on the Home Link.

2. Call doGet() in Boundary Servlet.

Patient Data

Patient Data is a link to search for and display patient data.

Pre-condition: User is successfully logged on to system.

Flow of Events:

1. The user click on the Patient Data Link.

2. Call doGet() in Boundary Servlet.

Appt Data

Appt data is a link to search for and enter/modify appointments.

Pre-condition: User is successfully logged on to system.

Flow of Events:

1. The user click on the Appt Data Link.

2. Call doGet() in Boundary Servlet.

Schedule

Schedule is a link to display schedule.

Pre-condition: User is successfully logged on to system.

Flow of Events:

1. The user click on the Schedule Link.

2. Call doGet() in Boundary Servlet.

5.2 Boundary Servlet

Name: Boundary

Type: Java Servlet boundary.class

Description: This is the boundary class for the system. It determines which modules are called based on an input parameter.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

doGet ()

Arguments: menuChoice – string representing which action to perform

No return value.

Pre-condition: Logon successful.

Post-condition: Requested HTML page returned.

Exception: throws ServletException

Flow of Events:

1. Call to doPost()

doPost ()

Arguments: menuChoice – string representing which action to perform

No return value.

Pre-condition: Logon successful.

Post-condition: Requested HTML page returned.

Exception: throws ServletException

Flow of Events:

1. Switch statement determining which control class to call

2. Instantiate specific cntrl class: cntrl_home() or cntrl_search, etc.

3. Call displayHeader()

4. Call displayMenu()

5. Call displayHTMLAction()

6. Call displayFooter()

term ()

No arguments.

No return value.

Post-condition: system terminates.

Exception: None.

5.3 Control Servlet

Name: Control

Type: Java Servlet cntrl.class

Description: This is the control class for the system. It is a non instantiate-able parent class with many child control classes inheriting methods and properties from it. The child control class represent each of the available actions requested through the main html pages.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHeader()

No arguments.

No return value.

Pre-condition: Logon successful.

Post-condition: HTML header information displayed.

Exception: throws ServletException

Flow of Events:

1. Open file header.txt and read into buffer.

2. Print buffer to screen.

3. Close file header.txt.

displayMenu()

No arguments.

No return value.

Post-condition: HTML left hand TD menu information displayed.

Exception: throws ServletException

Flow of Events:

1. Print MENU html information into the second row and first column to the screen.

2. I.e. menu info …

displayHTMLAction()

No arguments.

No return value.

Exception: throws ServletException

Flow of Events:

1. None. Dummy class for child cntrl classes.

DisplayFooter()

No arguments.

No return value.

Post-condition: HTML footer information displayed.

Exception: throws ServletException

Flow of Events:

1. Open file footer.txt and read into buffer.

2. Print buffer to screen.

3. Close file header.txt.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.4 Control Home Servlet

Name: Control Home

Type: Java Servlet cntrl_home.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display a calendar of the current month as the default HTML text.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains current month in calendar.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.5 Control Search Servlet

Name: Control Search

Type: Java Servlet cntrl_search.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the search for patient dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains search for patient dialog.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.6 Control Choose Entity Servlet

Name: Control Choose Entity

Type: Java Servlet cntrl_choose_entity.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the search for choose patient or appt dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains patient list or appointment

list results.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.7 Control View Edit Patient Servlet

Name: Control View Edit Patient

Type: Java Servlet cntrl_view_edit_patient.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view/edit patient dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view/edit patient dialog.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.8 Control View Edit Appt Servlet

Name: Control View Edit Appointment

Type: Java Servlet cntrl_view_edit_appt.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view/edit appointment dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view/edit appt dialog.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.9 Control Add New Patient Servlet

Name: Control Add New Patient

Type: Java Servlet cntrl_new_patient.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the add new patient dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains new patient dialog.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.10 Control Add New Appt Servlet

Name: Control Add New Appointment

Type: Java Servlet cntrl_new_appt.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the new appt dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains new appt dialog.

Exception: throws ServletException

Flow of Events:

1. Calls getData from appropriate entity class.

2. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.11 Control View Schedule Servlet

Name: Control View Schedule

Type: Java Servlet cntrl_view_schedule_by.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view schedule dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Pre-condition: Logon successful.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view schedule dialog.

Exception: throws ServletException

Flow of Events:

1. Instantiate schedule entity class.

2. Calls getData from appropriate entity class.

3. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.12 Control View Week Schedule Servlet

Name: Control View Schedule By Week

Type: Java Servlet cntrl_view_week_schedule.class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view weekly schedule dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

1. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view weekly schedule dialog.

Exception: throws ServletException

Flow of Events:

1. Instantiate schedule entity class.

2. Calls getData(day, “week”, “week”) from appropriate entity class.

3. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.13 Control View Day Schedule Servlet

Name: Control View Schedule By Day

Type: Java Servlet cntrl_view_week_day.schedule class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view daily schedule dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

2. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view weekly schedule dialog.

Exception: throws ServletException

Flow of Events:

1. Instantiate schedule entity class.

2. Calls getData(day) from appropriate entity class.

3. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.14 Control View Employee Schedule Servlet

Name: Control View Employee Schedule

Type: Java Servlet cntrl_view_employee_schedule class

Description: This is the control class for displaying the default home page of the system. It inherits the displayHeader, displayMenu, displayHTMLaction, and displayFooter (as well as init and term) from the parent cntrl class. This class is will display the view weekly schedule dialog in the second TD table tag in main window.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

3. Any initialization done.

displayHTMLAction()

No arguments.

No return value.

Pre-condition: cntrl class instantiated.

Post-condition: HTML right hand TD contains view weekly schedule dialog.

Exception: throws ServletException

Flow of Events:

1. Instantiate schedule entity class.

2. Calls getData(day, SSN) from appropriate entity class.

3. Displays html data returned from entity class to screen.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.15 Entity Appointment Servlet

Name: Entity Appointment

Type: Java Servlet entty_appointment.class

Description: This is the appointment entity class for the system.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

1. Any initialization done.

getData()

Arguments include search criteria for returning data.

Returns a record set containing data.

Pre-condition: None.

Post-condition: Database record set data found.

Exception: throws ServletException

Flow of Events:

1. Instantiate database class

2. Call getRS().

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.16 Entity Person

Name: Entity Person

Type: Java class entty_person.class

Description: This is the person entity class for the system. It is a parent non-instantiate-able class with two sub-classes under it.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

1. Any initialization done.

getData()

No arguments.

No return value.

Exception: throws ServletException

Flow of Events:

1. None. Dummy class for child entity classes.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.17 Entity Employee

Name: Entity Employee

Type: Java class entty_employee.class

Description: This is the child class of person entity for the system. It contains the methods of entity_person and returns the employee data.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

1. Any initialization done.

getData()

Arguments include search criteria for returning data.

Returns a record set containing data.

Pre-condition: None.

Post-condition: Database record set data found.

Exception: throws ServletException

Flow of Events:

1. Instantiate db_init class

2. Call getRS().

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.18 Entity Patient

Name: Entity Patient

Type: Java class entty_patient.class

Description: This is the child class of person entity for the system. It contains the methods of entity_person and returns the employee data.

Operations:

Init()

No arguments.

No return value.

Exception: None.

Flow of Events:

1. Any initialization done.

getData()

Arguments include search criteria for returning data.

Returns a record set containing data.

Pre-condition: None.

Post-condition: Database record set data found.

Exception: throws ServletException

Flow of Events:

1. Instantiate db_init class

2. Call getRS().

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

5.19 Database Initialization

Name: DB Init

Type: Java class db_init.class

Description: This is the class for doing database initialization and using the SQL statement as a parameter running the statements and returning the recordset.

Operations:

Init()

No arguments.

Returns error message if no database connection is made.

Exception: Throws ServletException.

Flow of Events:

1. Connect to database.

getData()

Arguments include SQL statement for running and returning data.

Returns a record set containing data.

Pre-condition: Successful database connection.

Post-condition: Database record set data found.

Exception: throws ServletException

Flow of Events:

1. Run SQL statement.

2. Return record set.

term ()

No arguments.

No return value.

Post-condition: class terminates

Exception: None.

Flow of Events:

1. Close database connection.

6. Data Structure Design

The database for the G-DOSS is called the Team2_Den Database. It handles all the current Patients.

The database has all the functionality usually associated with relational databases and these operations are used extensively and implicitly in this document.

6.1 Team2_Dent Database

The Team2_Den database has six tables organized as follows:

Persistent Data:

room_tbl

timeslot_tbl

employee_tbl

Transient Data:

patient_tbl

appointment_tbl

assignment_tbl

[pic]

6.2 Database Description

The room_tbl and timeslot_tbl are static data tables used for listing rooms and times.

The patient_tbl consists of important information pertaining to the patients. The primary key of the patient_tbl is ID, which is the social security number of the patient and the foreign key on the appointment_tbl.

The employee_tbl consists of names (FName, Lname) of all employees working for the Dental office. The primary key of the employee_tbl is EmployeeID, which is the social security number of the employee. Each employee will be classified by type, which is S for Secretary, D for Dentist and A for Dental Assistant.

The appointment_tbl has a composite key made up of Date of appointment, TimeSlotID and RoomID. TimeSlotID is used to determine the StartTime and EndTime on the timeslot_tbl. For example, if an appointment was for time slot 1, the StartTime is 9:00am and the EndTime is 9:30am. Each time slot is in increments of 30 minute appointments. RoomID is used to determine RoomDesc on the room_tbl.

The assignment_tbl is used to link an appointment, employees and a patient. There can be many employees with the same appointment and patient.

7. Use Case Realizations

For each use case in the Requirements Specification, there is a use case realization here. That is, the design objects in the above architecture perform a sequence of events realizing each of the operations promised in the SRS. We are using sequence Diagrams to show these realizations.

For each use case, we assume that the Administrator has started the program running and that we are at the main menu. Further, we assume that the preconditions on each use case have been met.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download