Practice DFDs, context diagrams, data dictionaries

Statement

• Choose any one of the problems given in the appendix and perform its structured analysis (you will have use this problem for the rest of the course also as many of the programming assignments are based on this choice. So please choose wisely).

Questions

1. Extract information needed for an automated application.
2. build its context diagram
3. build levels set of DFDs build balanced with the context diagram
4. build the data dictionary.

Criteria

Papers will be assessed on the following:

• The student described all the steps involved in structured analysis?
• Has the student drawn context diagram by defining the boundaries for the application?
• Has the student used circles and squares to define application names and entities?
• Has the student balanced the DFD with the context diagram?
• Has the student entered names and definitions of all the entities in the data dictionary?
• For each data flow, has the student created a definition and list of tentative contents in the data dictionary?
• Papers will be checked to be sure it is original work.

Introduction

• This text will use DR. Patel’s Dental Practice System as our main project.
• This text will start by giving a brief introduction to the system and the problem that system is trying to solve.
• Later we are following the Questions listed above, one by one.

DR. Patel’s Dental Practice System

• The dental practice uses a manual patient and billing system to serve approximately 1,100 patients. The primary components of the manual system are scheduling patient appointments, maintaining patient dental records, and recording financial information.
• Due to increased competitive pressure, Dr. Patel desires to automate his customer records and billing.
• New patients must complete the patient history form. The data elements are listed in Table 1.
• Then, at the first visit, the dentist evaluates the patient and completes the second half of the patient history information with standard dental codes (there are 2,000 codes) to record recommended treatments.
• The data elements completed by the dentist are listed as Table 2.
• The patient history form is filed in a manila folder, with the name of the patient as identification, along with any other documents from subsequent visits.
• A calendar of appointments is kept by the secretary, who schedules follow-up visits before the patient leaves the office. The calendar data elements are shown as Table 3.
• Also, before the patient leaves, any bills, insurance forms, and amounts due are computed.
• The client may pay at that time, or may opt for a monthly summary bill. The secretary maintains bill, insurance, and payment information with the patient history.
• Financial data elements are shown in Table 4.
• Every week, the secretary types mailing labels that are attached to appointment reminder cards and mailed.
• Once per month, the secretary types and sends bills to clients with outstanding balances.

1. Extract information needed for an automated application

• Based on the application above, the application would be a Query Application; the user would be able to query the database for information about the patients, the dentist, the appointments, and the billing information.
• Suggested users for this application would be the Dentist, the Secretary; patients would not be able to use this application.
• According to the information in Dr. Patel’s Dental Practice System, the application would only need to do:
  • Stor information permanently on a database (the patient’s information, the dentist’s information, the appointments, and the billing information).
  • The ability to update these data by the dentist and the secretary.
  • The ability to extends these data by adding new patients, new dentists, new appointments, and new billing information.
  • The ability to query, aggregate, and filter the data in a certain way that serves the purpose of the operation.
  • The ability to print the data in a certain way that serves the purpose of the operation, for example, building the monthly bills, then printing them.
  • The ability to store Procedure Codes, then retrieve and update them as needed.
• The application would not need to do:
  • No mentions about handling the payments, we expect that the secretary would handle the payments (cache, checks, ..etc); so the application would not need to handle the payments, but balances should be updated once a payment is made.
  • No mentions for reminders, not for the patients (for their appointments), nor for the secretary (for the weekly, monthly tasks); as mentioned above, the secretary will send weekly reminders for appointments, and monthly bills. The Requirement statement does not mention how this is going to be sent, but this is out of the scope of the application.
• To analyze the application, The text will use the structured top-down analysis, which includes the following activities:
  1. Developing the context diagram.
  2. Developing the data flow diagram, then balancing it with the context diagram.
  3. Developing the data dictionary.

2. Build the context diagram

• Since the application, will not send reminders, nor handle payments, there are not many external entities that the application will interact with.
• Only the Dentist and the Secretary will interact with the application.
• Secretary will perform the following tasks:
  • Add new patients (filling the first part of the patient history form).
  • Add new appointments.
  • Add new billing information.
  • Get the scheduled appointments for this week, and print them.
  • Get the monthly bills for this month, and print them.
  • Get Patient
• Dentist will perform theses actions on the application:
  • Complete the patient history form (filling the second part of the patient history form during their first visit to the clinic).
  • Add patient’s diagnosis Information.
  • Update Procedure Codes.
• So, the context diagram would be as follows:

3. Build levels set of DFDs build balanced with the context diagram

• The text will start by building the Level 0 DFD
• All modules in the diagram need to interact with single, relationally stored database; to simplify the diagram, the diagram shows only one database box, with two fat arrows, one for input, and one for output, to show that the database is both an input and an output for all the modules.
• please notice that the database her is a store and not an entity.

• To Simplify the detailed DFDs, the text will use the structure chart to build the deals as follows:

• similarly, the one can build the other levels of DFDs for the Secretary, the text will not include this chart.

4. build the data dictionary

Entities Data Dictionary

Entity Name	Alias	Relationship To App	Contents	Constraints
Patient	User,Client	Provides information about the patient, and the patient’s history. attend appointments, and pay bills.	ID + PatientName + AddressID + HomeTelephone + DOB + Sex + ParentID + KnownDentalProblems + KnownPhysicalProblems + KnownAllergies + WorkAddressID + WorkPhone + IncurrenceCompany + InsuranceCompanyAddress + InsuranceCompanyPolicyNumber + LastDentistName + LastDentistAddressId + PhysicianName + PhysicianAddressId	None
PatientDiagnosisHistory	None	Provides information about the patient’s diagnosis history.	ID + PatientID + ProcedureCode + ProcedureDate + ProcedureDescription + ProcedureCost + ProcedureNotes	must be a valid patient
Appointment	None	Provides information about the patient’s appointments.	ID + PatientID + AppointmentDate + AppointmentTime + AppointmentType + DateOfLastService	must be a valid patient, date in future
Billing	None	Provides information about the patient’s billing.	ID + PatientID + PatientAddress + DateOfService + DatePaid + AmountDue + AmountPaid + Balance + DateBillSent + DateOverdueNoticeSent	must be a valid patient
ProcedureCode	None	Provides information about the procedure codes.	ID + ProcedureCode + ProcedureDescription + ProcedureCost	None

Data Flow Dictionary

• For referencing, in the table below, the text will use the following notation:
  • PatientAttributes: ID + PatientName + AddressID + HomeTelephone + DOB + Sex + ParentID + KnownDentalProblems + KnownPhysicalProblems + KnownAllergies + WorkAddressID + WorkPhone + IncurrenceCompany + InsuranceCompanyAddress + InsuranceCompanyPolicyNumber + LastDentistName + LastDentistAddressId + PhysicianName + PhysicianAddressId
  • PatientDiagnosisHistoryAttributes: ID + PatientID + ProcedureCode + ProcedureDate + ProcedureDescription + ProcedureCost + ProcedureNotes
  • AppointmentAttributes: ID + PatientID + AppointmentDate + AppointmentTime + AppointmentType + DateOfLastService
  • BillingAttributes: ID + PatientID + PatientAddress + DateOfService + DatePaid + AmountDue + AmountPaid + Balance + DateBillSent + DateOverdueNoticeSent
  • ProcedureCodeAttributes: ID + ProcedureCode + ProcedureDescription + ProcedureCost

Name	Alias	Timing	Contents	Constraints
AddNewPatient	None	when patent first registers	PatientAttributes	None
CompletePatientRegistration	None	in the patient first visit	PatientAttributes	None
AddPatientDiagnosisHistory	None	when dentist adds diagnosis	PatientDiagnosisHistoryAttributes	None
UpdateProcedureCodes	None	when dentist updates procedure codes	ProcedureCodeAttribute	None
GetPatient	None	when secretary gets patient	PatientAttributes	None
AddAppointment	None	when secretary adds appointment	AppointmentAttributes	None
AddBilling	None	when secretary adds billing	BillingAttributes	None
GetAppointmentsForWeek	None	monday	AppointmentAttributes (collection)	None
GetBillsForMonth	None	1st of every month	BillingAttributes (collection)	None