Download - Using an object-oriented approach to the development of a relational database application system

ELSEVIER Information & Management 29 (1995) 107-121

Techniques

Using an object-oriented approach to the development of a relational database application system

Pi-Sheng Deng a,*, Cynthia L. Fuhr b a Department of Computer Information Systems, School of Business Administration, California State University at Stanislaus, Turlock, CA

95380, USA b Department oflnforraation Systems, Yosemite Community College District, Modesto, CA 95352, USA

Abstract

Object-oriented technology has been proposed in recent years as a promising approach to increasing programmer productivity and the quality of software development. The traditional development of a database application system distinctively separates a system's behavior and its data by using entity-relationship diagrams, functional decomposition, and process-dependency diagrams. The object-oriented approach, on the other hand, integrates both data and behavior, and this can result in a merging of both software and databases. To gain more insight into the object-oriented approach to the analysis and design of software development, we applied this approach to the development of a simplified hospital administration system. The resulting application system is an object-based system but uses a relational database manager. This illustrates the fact that object-oriented approaches are not limited to object-oriented systems or databases: they can, in fact, be used for more traditional design. This technique may allow easier transition from data-based to object-based systems. Software that is reusable, improved in its design, more reliable, and simpler in its programming and maintenance requirements would truly be an advantage to users and developers alike.

Keywords: Classes; Messages; Objects; Object-based database systems; Object-oriented analysis and design; Object-oriented technology; Signatures

1. Introduction

Computer industry analysts have been stating for many years that we have a "sof tware crisis." As computers are becoming faster, cheaper, and more powerful, software develoPment has become more costly and time-consuming. In fact, studies have shown that up to 95% of all software development projects are never completed without some major reconstruction or redesign.

* Corresponding author

The problem lies in the approach to software development. Traditional structured analysis and design techniques leading towards modular top-down programming is very t ime-consuming and often cannot allow even simple modifications to a module without a complete redesign of the system. Although CASE tools were once acclaimed to solve the software problem by automatically generating programs, they still require a lengthy design process and are relatively fragile in use.

One approach that is growing in popularity and which may solve this problem is object-oriented programming (OOP) [10,17]. The premise of object-

0378-7206/95/$09.50 © 1995 Elsevier Science B.V. All fights reserved SSDI 0378-7206(95)00020-8

108 P.-S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121

orientation is that it can model the real world. Pro- grammers can organize entities through objects using encapsulation, classification and messaging. This allows end users to access a more user-friendly system with graphical user interfaces and more understand- able designs. Other advantages are: 1. Reusability. Classes can be put into libraries and

parts reused later in other systems. 2. Productivity. It is "natural" to solve problems in

object form rather than in low-level detail. Com- plex objects can be built simpler, in building blocks consisting of simple objects. Also, the design phase could be made faster by using ready-made classes and case tools. Changes are easier.

3. Reliability. One class used in several areas is likely to reduce the total number of bugs.

4. Easier programming and maintenance. Coding is at a high-level, using a building blocks method. Classes are independent of each other and changes do not upset other independent objects.

5. Communications. The object-orientation way of thinking promotes better communications between business people and their Information Sys- tems staff. The application developer should have an easier

job as well. An increase in productivity will result when code can be reused, because models of the real world will not have to be "reinvented" for each project [1]. Programming should be at a higher level (building blocks method) and easier to accomplish [7]. Changes can be made in the implementation cycle so that most of the earlier design can be retained.

Object-orientation is not a new concept. Object- oriented programming began in the 1960's with the SIMULA language, followed by SMALLTALK, and hybrid languages, such as C ÷+ and ADA. Since then, analysis and design methods have been developed to aid the modeling of data-oriented systems. There are over 100 object-based and object-oriented languages available today [3].

An object-based language directly supports data abstraction and classes, while an object-oriented language is object-based and supports inheritance. Pure languages have been built to be object-oriented and only accept objects, methods, and classes. Hybrid languages are non-object-oriented, accepting other

data types than objects, but also allowing objects, classes, and methods. A disadvantage to this type of language is that it tends to lead the programmer back to a traditional approach [5].

In terms of database technology, there seems to be an on-going controversy over object-oriented ver- sus relational approaches [2,9,11,16]. One solution has been to merge the technologies, allowing object- based routines in SQL databases [13].

In order to gain more insight into the object-oriented technology, we apply the approach to the analysis and design of a relational database application system. MicroSoft's Visual Basic 3.0 standard edition was used in implementing the research.

2. Principles of object-oriented technology

The object-oriented approach to information system development is built upon three basic ideas: objects, messages, and classes. An object is a software entity with behavior (or a collection of procedures) and data. It is autonomous, in the sense that it can satisfy requests sent from other objects without a need for any external step-by-step instruction. This is attained through the set of procedures (called methods) embedded in the object. Such self-sufficiency renders objects ideal software modules, and their maintenance can be accomplished independently.

Objects communicate by sending messages, and objects respond by carrying out their own methods. A message for an object mainly consists of the name of the object and the name of a method that the object can execute. Message passing is the necessary means to activate objects, and objects respond only to messages.

Since objects communicate through message passing, an object cannot directly access another object's variables. This provides a form of encapsulation, protecting an object's variables from being corrupted by other objects; this also simplifies the interactions between objects. In addition, the same message can be used to obtain different results by sending it to different objects. This hiding alternative procedures behind a common interface is called polymorphism. One of its key benefits is that it helps keep the number of names for different tasks or operations to a minimum. This also simplifies the programming

P.-S. Deng, C.L. Fuhr / lnformation & Management 29 (1995) 107-121 109

process and improves the readability of the program. As a consequence, modification and maintenance are also simplified.

The object oriented approach uses the concept of classes: similar objects are grouped together. The objects belonging to the same class are called in- stances of that class. A class serves as a template (or definition) for the common methods and variables shared by its objects; the actual values for the variables or the parameters used in the methods are contained in the object instance.

Actually, a class is a generalization of its objects. Thus, classes can be grouped into superclasses to form different levels of generalization. In this class hierarchy, a lower level class can inherit methods and variables from its superclass, but still establishes its own special characteristics by adding to the inher- ited behavior. When an object receives a message to carry out a method that has not been defined in its class, the object searches up its class hierarchy until it finds the definition of that method and then applies it to its own local data values.

Another characteristic of the class hierarchy is its ability to accommodate exceptions. In the class hierarchy, exceptions defined at a lower level always

override the more general methods defined at a higher level. With overriding, special cases can be handled efficiently and easily.

3. Object-oriented approach

3.1. Object-oriented analysis

Although a traditional structured analysis approach can still be used, other views have surfaced to handle object oriented (OO) analysis. In object-oriented analysis, the behavior and data of the system are treated as integrated objects using a variety of techniques [8]: there is still no current standard approach.

Martin [15] uses object structure and object behavior analysis for building the model. The main purpose of the analysis is to identify object types and their associations; then their relations to other objects, as well as their purpose and role, are also defined. In OO analysis, the primary focus is in finding out what happens to the objects over time: state transitions -the states that the objects can take and the events that cause the change and the result-

Inventory Item

General Ledger Bill

Service Physician Employee Item

Cost Center

Patient Party i

I

Fig. 1. Enterprise model of the patient care administrative system.

110 P.-S. Deng, C.L. Fuhr ~Information & Management 29 (1995) 107-121

Table 1 Candidate classes after elimination of redundant classes.

Patient Name Treatment Patient Bill Patient Service Expected Date Discharged Room Accommodations Patient SSN Main Menu Patient Information Display Room Utilization Display Phone (Contact Info) Patient Home Phone Room Location

Physician Name Patient Record (Patient) Insurer Service Charge Date Discharged Patient Address (Contact Info) Room Identification (Location) Physician Phone Ext. Patient Bill Display Services Display Patient Procedure (Treatment) Patient Charge

Room (Location) Physician Identification Patient Balance Date Admitted Physician Specialty Patient Identification Room Phone Ext. Third Party (Insurer) Patient Treat. Display Physician Info Display Service Identification Patient Contact Info

ing outputs. Object-flow diagrams, event schemata, operation diagrams, object states, and trigger rules are used to do this.

According to Jacobson et al. [12], during the analysis phase we must identify objects, organize them, describe how they interact, define the operations of them, and define their internal aspects. The model captures the information, behavior, and pre- sentation of the objects. Objects are one of three types: entity, interface or control.

The "core model," proposed by de Champeaux et al. [6], has four components. A matrix shows how objects are defined based on their static and dynamic

characteristics and behavior both inside the object and between objects. In a static dimension, objects need attributes to describe them. Constraints define the limitations of attribute value combinations. For example, a department may have the attributes director and secretary with "employee" as their value; however, a director is not a secretary, and vice versa, so a constraint could be: director ~ secretary. In the dynamic dimension, the different states and expected behavior of the object and its interactions are defined.

Coad and Yourdon [4] have developed a well- known approach to analysis that consists of:

Table 2 Superclasses identified during the exploratory phase.

Super Class Classes Super Class Classes

Display Main Menu Identification Patient Information Patient Billing Patient Treatment Physician Information Service Information Room Information

Phone Room Phone Ext Name Physician Phone Ext

Patient Home Phone

Charge Patient Charge Date Service Charge

Patient Identification Patient SSN Physician Identification Service Identification Location Identification

Patient Name Physician Name Insurer

Date Admitted Expected Discharge Date Discharge Date

P.-S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121 111

1. identify objects by studying the " p r o b l e m space ," reading requirements, noting any nouns, and lis- tening to the users. Analyze text and pictures.

2. identify structures of the problem by class-member grouping and whole-part grouping. For example, the class vehicle could have car, truck, and motorcycle members, while a car could contain an engine, tires, steering wheel, and transmission.

3. define each structure and object limiting the number of components of each so that the intended user can easily comprehend the problem. Using the " 7 + 2 " rule is one way of accomplishing this.

4. define attributes to add detail to the object or classification structure; e.g., the class vehicle and all its members will have VIN, model, and color attributes.

5. define services or required behavior of each object and classification structure upon receipt of a message.

3.2. Object-oriented design

In object-oriented design, a variety of techniques can be used to design a system. Several possible approaches have been proposed.

Mart in ' s approach uses class structure and method design. The results from the object structure analysis are used to define and design classes, class methods, class hierarchies, inheritance, data structures, and databases. In method design, the primary focus is towards designing the methods of objects, based on the behavior analysis. The design of methods and operations, procedural logic, non-procedural code,

Table 3 Purpose of each class.

Class Description and Purpose of Class

Patient Name Physician Name Treatment Patient Bill Insurer Patient Balance Patient Service Service Charge Date Admitted Expected Date Discharged Date Discharged Physician Specialty Room Accommodations Patient Identification Patient SSN Physician Identification Room Phone Ext. Main Menu Patient Treatment Display Physician Phone Ext. Room Utilization Display Services Display Physician Info Display Service Identification Patient Home Phone Patient Charge Patient Contact Information Room Location Patient Information Display Patient Bill Display

First, Middle Initial, Last Name identifying patient First, Middle Initial, Last Name identifying physician Procedure physician performed on patient Patient charges for services rendered at the hospital Third Party agency for cost coverage Amount Patient owes for a particular service Service/item a patient has received at the hospital Default amount that is charged a patient for a service Date patient was admitted into the hospital Expected date patient will leave the hospital Date patient was discharged or released to coroner Specialization or title of physician General/specific room characteristics Unique number identifying patient (SSN can change) Patient social security number Unique number identifying physician (SSN can change) 4 digit extension for rooms that have a phone Entry menu of patient care administration system Entry/Query screen for patient treatment (from main/info) 4 digit extension for physicians that have a phone Entry/Query screen for room information (from main/info) Entry/Query screen for services information (from main menu) Entry/Query screen for physician information (from main menu) Unique code identifying type of service Home phone number to reach patient/immediate family Amount patient charged for service (may be different than default service charge) Mailing Address, city, state and zip code of patient Unique room number identifying a particular room Entry/Query screen for patient information (from main menu) Entry/Query screen for patient billing (from main menu/info)

112 P. -S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121

Table 4 Roles of each class.

Class Roles ofClass

Patient Name Physician Name Treatment Patient Bill Insurer Patient Balance Patient Service

Service Charge

Date Admitted Expected Date Discharged Date Discharged Physician Specialty

Room Accommodations

Patient Identification Patient SSN

Physician Identification Room Phone Ext. Main Menu

Physician Phone Ext. Patient Information Display

Patient Bill Display

Patient Treatment Display

Room Utilization Display

Services Display

Physician Info Display

Identify patient Identify physician Provide medical/surgical care to patients Inform patient of charges incurred and balance due Identify agency for partial/full payment of patient bill Accept/Display balance due for service rendered Accept/Display service rendered Provide service/item to patient Accept/Display default service charge for service Display default charge when adding patient billing record Accept/Display date Accept/Display date Accept/Display date Accept/Display specialization Query doctors for particular specialization needed for a patient Accept/Display accommodations Provide specific options for patient care bedding Accept/Display/Validate unique identification Accept/Display/Validate unique SSN Inform third party agencies of SSN for identification Accept/Display/Validate unique identification Accept/Display phone extension Present user with choices Determine when and what user responded to Accept/Display phone extension Present user with choices: (add /edit /delete /view /query /search /help) (treatment/billing/room) Determine when and what user responded to View/maintain Patient Information records Validate/Update corresponding room information if patient assigned to a location Validate patient not assigned to multiple rooms or occupied rooms User choices: (add/edit/delcte/view/query/search/help) Determine when and what user responded to View/maintain Patient Billing records Return to main menu if selected from main menu Return to patient information if selected from there User choices: (add/e~t/delete/view/query/search/help) Determine when and what user responded to View/maintain Patient Treatment records Return to main menu if selected from main menu Return to patient information if selected from there User choices: (add/edit/delete/view/query/search/help) Determine when and what user responded to View/maintain Room Information records Validate patient not assigned to multiple rooms Return to main menu ff selected from main menu Return to patient information if selected from there User choices: (add/edit/delete/view/query/search/help) Determine when and what user responded to View/maintain Service Information records User choices: (add/edit/delete/view/query/search/help) Determine when and what user responded to View/maintain Physician Information records


Table 4 (continued)

Class Roles of Class

Service Identification Patient Home Phone

Patient Charge

Patient Contact Info Room Location

Accept/Display/Validate unique identification Accept/Display phone number Reach patient/immediate family if emergency Accept/Display charge Display default service charge when adding record Accept/Display contact information Accept/Display/Validate unique Room Number

input to code generators, screen and dialog design, and prototyping are accomplished here.

Wirfs-Brock et al. [18] design method encom- passes definition of a system of objects, description of their public behavior, and their patterns of communication. In the exploratory phase, classes will be developed, assigned responsibilities stating their purpose and required actions and information, and their collaborations with other classes producing a list of other classes that are needed. In the analysis phase, hierarchies of classes are developed, followed by their subsystems. Then protocols are setup for each class. The final design process results in a graph of each class hierarchy, a graph of the paths of collabo- ration for each subsystem, a specification of each subsystem, and the contracts supported by each class and subsystem.

Booch [3] suggests a "notation" for showing logical and physical and static and dynamic models of the system.

Lastly, de Champeaux et al. identify three types of design: functional, physical, and performance. The first includes defining properties of "classes obeying the declarative constraints specified." Phys- ical design maps objects to the physical system. Performance design reconciles functional and physical requirements to meet performance requirements.

4. Development of an object-based relational database application system

A case example of a patient care administrative system adapted from McFadden and Hoffer [14] is used to illustrate the application of object-based principles to the development of a data base application system.

The hospital is a medium-sized non-profit organi- zation. Its main goal is to provide high-quality health care and, at the same time, lower the cost of care. To do this, the hospital physically expanded in 5 years by adding and renovating facilities. What is now needed is to improve its patient care administrative system. Currently, the hospital uses a minicomputer to handle batch-oriented processing for accounting, billing and accounts receivable, and financial accounting. The new system should allow on-line procedures, such as patient registration or billing in- quiries, and also track medical staff, laboratory test results, and patient treatments. Months of planning and analysis led the study team to determine the ten basic functions of the hospital with 22 total processes. The enterprise model is shown in Fig. 1.

4.1. Exploratory phase

In the exploratory phase of system design, classes are fully defined indicating the purpose of the class, its task(s) that need to be performed when called upon, and any collaborations with other objects to perform the desired task. Completion of the following steps will result in a list of candidate classes and superclasses. In order to develop classes and superclasses we follow the six-step procedure of Wirfs- Brock et al. 1. List a description of the goals of the design 2. Discover expected inputs and desired outputs 3. Look for noun phrases in required specifications 4. Model categories of classes 5. Model interfaces to the system 6. Model values of attributes, not attributes them-

selves After obtaining a list of candidate classes, we

114

Table 5 Class interactions.

P.-S. Deng, C.L. Fuhr /Information & Management29 (1995) 107-121

Class Interactions Between Classes

Patient Bill

Main Menu Patient Information Display




Services Display


Patient Information Display (patient id, ssn, name, contact information, insurer) Service Information Display (service description) Patient Service Patient Service Charge Patient Balance Monitor Patient Identification, Patient Name, Patient SSN, Patient Contact Information, Patient Home Phone, Date Admitted, Expected Discharge Date, Discharge Date, Location, Insurer Room Information Display Patient Information Display (patient id, ssn, name) Physician Information Display (physician id, physician name) Treatment Patient Information Display (patient id, ssn, name, contact information, insurer) Service Information Display (service description) Patient Service Patient Service Charge Patient Balance Patient Information Display (patient id, ssn, name) Location, Accommodations, phone extension Service Identification Patient Service Service Charge Physician Identification Physician Name Physician Phone Extension Physician Specialty

eliminate redundancies: see Table 1. Then, we group related classes into a superclass: see Table 2.

In order to exist, a class must have a purpose. The purpose is simply a definition of what it is, elaborat- ing on the name in which it was assigned. The purpose of each class is documented in Table 3.

Next, the role of each class is defined to show the operations that an object must perform when it receives a message. 1. Split classes if they have too many roles to per-

form. This will result in a system that is easier to maintain by having fewer areas for modification.

Trealanent Patient Bill

Patient Servi~

Room Aceomodation

Patient Balanee S p e ~

Patie~lt Control

InformaUon

Fig. 2. Stand-alone classes.

P.-S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121 115

Class (Client/Server)

Patient Name Physician Name Treatment Patient Bill Insurer Patient Balance Patient Service

Service Charge

Date Admitted Expected Date Discharged Date Discharged Physician Specialty

Room Accommodations

Patient Identification

Table 6 Message request and provision between client and server objects.

Message

Patient SSN

Physician Identification

Room Phone Ext. Main Menu

Physician Phone Ext. Patient Information Display




Services Display


1. Identify patient (35,36,37,38,41) 2. Identify physician (40) 3. Provide medical/surgical care to patients (37) 41. Inform patient of charges incurred and balance due (36) 4. Identify agency for partial/full payment of patient bill (35,41) 5. Accept/Display balance due for service rendered (36,41) 6. Accept/Display service rendered (36,39,41) 7. Provide service/item to patient 8. Accept/Display default service charge for service (36,39) 9. Display default charge in patient charge when adding patient billing record (36) 10. Accept/Display date (35) 11. Accept/Display date (35) 12. Accept/Display date (31,35) 13. Accept/Display specialization (40) 14. Inform, through query, those doctors for particular specialization that is needed for a patient (37) 15. Accept/Display accommodations (38) 16. Provide specific options for patient care bedding 17. Accept/Display identification (1,3,5-7,10-12,19,26,28,30,41) 18. Validate that patient identification is unique (35) 19. Accept/Display SSN (1,4-7,10-12,41)

Validate that patient SSN is unique 20. Inform third party agencies of SSN for identification (41) 21. Accept/Display identification

Validate that physician identification is unique (37) 22. Ac.cept/Display phone extension (38) 23. Present user with choices

Determine when and what user responded to 24. Accept/Display phone extension (40) 35. Present user with choices:

Determine when and what user responded to View/maintain Patient Information records Validate/Update corresponding room information if patient assigned to a location Validate patient not assigned to multiple rooms or occupied rooms (23, 36, 37, 38)

36. Present user with choices: Determine when and what user responded to View/maintain Patient Billing records Return to main menu if selected from main menu Return to patient information if selected from there (23, 35)

37. Present user with choices: Determine when and what user responded to View/maintain Patient Treatment records Return to main menu if selected from main menu Return to patient information if selected from there (23, 35)

38. Present user with choices: Determine when and what user responded to View/maintain Room Information records Validate patient not assigned to multiple rooms Return to main menu if selected from main menu Return to patient information if selected from there (23, 35)

39. Present user with choices: Determine when and what user responded to View/maintain Service Information records (23)

40. Present user with choices: Determine when and what user responded to View/maintain Physician Information records (23)

116

Table 6 (continued)

P.-S. Deng, C.L. Fuhr / lnformation & Management 29 (1995) 107-121

Class (Client/ServeD Message

Service Identification 25.

Patient Home Phone 26. 27.

Patient Charge 28. 29.

Patient Contact Info 30. Room Location 31.

Accept/Display identification Validate that service identification is unique (41,8,9,39) Accept/Display phone number (35) Reach patient/immediate family if emergency Accept/Display charge (41,36) Display default service charge when adding record (36) Accept/Display contact information (41,35) Accept/Display Room Number (38) Validate that number is unique

2. Define roles of a class in order to search for related classes more easily.

3. Objects requiring information would be most effi- cient if they could maintain it, thus reducing the number of messages between objects.

4. Maintain data integrity -keep information about one thing in one place.

5. Share roles between objects, when needed. Larger roles can sometimes be broken down into smaller ones and assigned to more suitable classes. Following these guidelines, the role(s) for each

class are shown in Table 4. Lastly, we need to identify the interactions be-

tween classes; i.e., collaborations. This could be viewed as the first part of a message, the name of the receiving object, without detailing the method of obtaining this information or the parameters to be used: these show the flow of control and data within and between classes. Table 5 shows the high-level interactions between classes that are required in order to perform the roles.

4.2. Analysis phase

In the analysis phase, hierarchies of classes are developed, as well as subsystems for classes with a high level of interaction. Detailed messages are then defined for each class, resulting in a graph of each class hierarchy, a graph of the class interactions, a specification of each subsystem, and the messages supported by each class.

The first step is to review the previous class roles and interactions in order to determine if other superclasses can be formed. The hierarchies generated from this step are essentially a graphical view of

each of the final superclasses and its subclasses. Abstract classes are created only as the top of a hierarchy. These classes are Identification, Charge, Name, Date, and Phone. Concrete classes are created to be instantiated. Examples are Patient Information, Patient Billing, Physician Information, Service Infor- mation, etc..

There are still some stand-alone classes that could not be grouped into a superclass. That type of stand- alone classes are shown in Fig. 2. These classes are still required for the hospital patient care management system.

The next step is to detail what inputs are needed from other classes for a class to perform its duties. This establishes communication between two classes and is similar to a client/server environment where one class (client) requests some kind of action(s) from another class (server). This demand and supply relationship between the client and the server is shown in Table 6. The numbers in parenthesis indicate what the client requests from the server. This form of messaging shows the receiver of the message, the method or action to be taken, and the requirements from other classes. For example, the class "Patient Name" is required for classes "Pa- tient Information Display," "Patient Bill Display," "Patient Treatment Display," "Room Utilization Display," and "Patient Bill," while it requires the class "Patient SSN." The "Identify" method, or procedure, is included in those messages that require locating information based on some key, such as locating a patient record by social security number in order to find his/her name.

After identifying what is required by a client and what can be supplied by a server, they must be able

P.-S. Deng, C.L. Fuhr /Information & Management 29 (1995) 107-121 117

Table 7 Signatures of each Class

Class Signatures

Patient Name Physician Name Treatment Patient Bill Insurer Patient Balance Patient Service Service Charge Date Admitted Expected Date Discharged Date Discharged Physician Specialty

Room Accommodations Patient Identification

Patient SSN

Physician Identification

Room Phone Ext. Main Menu Physician Phone Ext. Patient Information Display




Get_PatientName (Text) Get PhysicianName (Text) Get Treatment (Text) Prin-tBill (Text) returns (Boolean) Getlnsurer (Text) Get PatientBalance (Currency) Get PatientService (Text) Get ServiceCharge (Currency) GetAdmitted(Date) Get ExpDischarge(Date) Get_Discharge(Date) Get_PhysicianSpecialty(Text) Query_Physician(Text) returns Physician Info Display Get RoomAccommodations(Text) Get_Patientld(Integer) Validate Patientld(Integer) returns (Boolean) Get_PatientSSN(Integer) Validate_PatientSSN(Integer) returns (Boolean) Get_Physicianld(Integer) Validate_Physicianld(Integer) returns (Boolean) Get RoomPhone(Integer) Display_MainForm(Text) Get PhysicianPhone(Integer) Display_Patientlnformation(Text) AddPatientRecord(Boolean) EditPatientRecord(Boolean) DeletePatientRecord(Boolean) ViewPatientRecord(Boolean) QueryPatientRecord(Boolean) SearchPatientRecord(Boolean) HelpPatientRecord(Boolean) Validate_RoomNumber(Integer) returns (Boolean) Display PatientBilling(Text) AddPatientBillRecord(Boolean) EditPatientBiURecord(Boolean) DeletePatientBillRecord(Boolean) ViewPatientBillRecord(Boolean) QueryPatientBillRecord(Boolean) SearchPatientBillRecord(Boolean) HelpPatientBillRecord(Boolean) DisplayTreatment(Text) AddTreatmentRecord(Boolean) EditTreatmentRecord(Boolean) DeleteTreatmentRecord(Boolean) ViewTreatmentRecord(Boolean) QueryTreatmentRecord(Boolean) SearchTreatmentRecord(Boolean) HeipTreatmentRecord(Boolean) DisplayRoom(Text) AddRoomRecord(Boolean) EditRoomRecord(Boolean) DeleteRoomRecord(Boolean) ViewRoomRecord(Boolean) QueryRoomRecord(Booleau) SearchRoomRecord(Boolean) HelpRoomRecord(Boolean)

118

Table 7 (continued)

P.-S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121

Class Signatures

Services Display


Service Identification

Patient Home Phone Patient Charge

Patient Contact Info Room location

DisplayService(Text) AddServiceRecord(Boolean) EditServiceRecord(Boolean) DeleteServiceRecord(Boolean) ViewServiceRecord(Boolean) QueryServiceRecord(Boolean) SearchServiceRecord(Boolean) HelpServiceRecord(Boolean) Display_Physicianlnformation(Text) AddPhysicianRecord(Boolean) EditPhysicianRecord(Boolean) DeletePhysicianRecord(Boolean) ViewPhysicianRecord(Boolean) QueryPhysicianRecord(Boolean) SearchPhysicianRecord(Boolean) HelpPhysicianRecord(Boolean) Get_ServiceId(Text) Validate_ServiceId(Text) returns (Boolean) Get PatientPhone(Integer) Get PatientCharge(Currency) Display_ServiceCharge (Currency) Get_PatientContactlnfo(Text) Get_RoomNumbeKInteger) Validate_RoomNumber(Integer) returns (Boolean)

MAin M~nu

Physician Subsystem

Patient Subsystem

Room S u ~

Service S u l x ~ ¢ ~

Treatment Subayatam

Billin~ Sub~C~am

Fig. 3. Structure of the main menu.


Billing Treatment Mountain View Community

Hospital

; !

- v

11

Patient Care Administration System Fig. 4. The main menu screen.

to send messages to one another. Message passing among client objects and server objects is controlled by the "signature," which specifies the type of parameters and objects that it can receive and send. Table 7 shows the signatures for the patient care administrative system.

The final step is creating a set of subsystems in which the classes and superclasses are graphically grouped so that they can perform efficiently. The structure of the main menu, as shown in Fig. 3, consists of six choices, or subsystems, of patient care information. The dotted lines represent the data flow relationship between the two subsystems. The screen of the main menu is displayed in Fig. 4. Since physicians treat patients, the treatment subsystem can also be accessed through the physician subsystem. Likewise, since services are charged to patients in the form of a bill, the billing subsystem can be accessed through the service and patient subsystems. These two subsystems are activated through the pull-down menu of the Patient command in the menu bar of the system.

Each subsystem has been designed and fully implemented. For example, Fig. 5 shows the structure of the Patient subsystem, which is designed to display the contact (i.e. address, relative), insurance,

and scheduling information about the patient. A sample screen for the Patient subsystem is shown in Fig. 6. The other subsystems are described briefly here. The physician subsystem shows physician information, including his/her specialization for patient treatment. The room subsystem displays its location within the hospital, phone extension, and the accom-

e~

m t I I

l - - t

1

- - t ssN 1

Contact Information

Date Admitted

Zxt~ted Date ~ a r s , ed

Date

Fig. 5. Structure of the Patient subsystem.

120 P.-S. Deng, C.L. Fuhr / Information & Management 29 (1995) 107-121

P~i~ tNu~r ~ SSN t12345s78s ]

Patient Name [nettj ] ~ [Brown ]

Addre## [123W. 52rid ]

City [Nodello ]

s,.to ['ff-]

Phone Number Lz0m234567 ]

Admitted [12/13/93 I Ezpected Dischmge [11/11/94 I

Oi#¢hamged L I

),)IL'

Location

Imuml LBlue tie**

1141 4 1 Recmd $_._,z,~_.~n 11,11,41

Fig. 6. A sample screen of the Patient subsystem.

modations (outside view, television, etc.). Each room has one bed and no more than one patient. The service subsystem maintains services performed by hospital staff. The patient billing subsystem will indicate what is owed by the patient, the original amount owed and the remaining balance. Lastly, the treatment subsystem records services performed on patients by physicians. Charges of services are up- dated in patient billing.

The database component is built by using Micro- soft ® Access TM, a PC-based relational database management system. This database component is accessi- ble through each subsystem. The Record Selection menu bar at the bottom of the display screen of each subsystem serves this function. We also built indexes for each table. Users can issue their own queries through the Record Selection menu bar.

5. Discussion and conclusion

In conclusion, object-oriented technology is more than a programming language. It is an approach to

software development that uses objects, classes and messages to model real world processes. Objects can be both clients and servers in performing their different roles, just as humans can both request as well as provide services within their varying roles. In the same way that humans are dependent on others to provide a service.

To demonstrate the object-oriented approach to software development, a case of hospital management situation was adapted as an illustration. The system is an object-based relational database application system. This allows an easier transition from data-based to object-based systems.

Due to the limitations of the software used in implementing our application system, it should be noted that our system is just object-based instead of object-oriented. As a consequence, our system cannot utilize many of the advantages of an object-oriented system. It would be easier to use an object-oriented database that can utilize this design to store and access objects instead of a relational database. Secondly, structured and object-based programming


languages do not support inheritance, and thus the advantage of reusing code by one or more classes 'adopting' the behavior and structure of another can not be implemented.

Ad-hoc queries are not possible with encapsulation, since data can be accessed only through pre-defined methods or functions. Also, object-oriented databases require object-ids instead of keys.

This approach along with the use of an object-oriented programming language should solve the ever- increasing software crisis. Software that is reusable, improved in its design, more reliable, and simpler in its programming and maintenance requirements would truly be an advantage to both users and developers.

[12] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Menlo Park, CA: Addison-Wesley, 1993.

[13] B. Machrone, "Object Oriented: Old Wine, New Bottles?" PC Magazine, Vol. 8, No. 9, 1989, pp. 65-66.

[14] F.R. McFadden and J.A. Hoffer, Data Base Management, Fourth edition, Menlo Park, CA: Benjamin/Cummings, 1994.

[15] J. Martin, Principles of Object-Oriented Analysis and De- sign, Englewood Cliffs, NJ: Prentice Hall, 1993.

[16] G. Ray, "Growing Pains: Object-Oriented Databases Lack Development Tools," ComputerWorld, Vol. 27, No. 21, pp. 79-80.

[17] D. Taylor, Object-Oriented Information Systems: Planning and Implementation, New York, NY: John Wiley and Sons, Inc, 1992.

[18] R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.

References

[1] C. Babcock, "Object Lessons," ComputerWorld, Vol. 27, No. 18, 1993, p. 58.

[2] C. Babcock, "Relational Backlash," ComputerWorld, Vol. 27, No. 26, 1993, p. 36.

[3] G. Booch, Object-Oriented Design with Applications, Menlo Park, CA: Benjamin/Cummings, 1991.

[4] P. Coad and E. Yourdon, Object-Oriented Analysis, Engle- wood Cliffs, NJ: Prentice Hall, 1990.

[5] C. ComaFord, "Are You Object-Based or Object-Oriented?" PC Week, Vol. 10, No. 23, 1993, p. 56.

[6] D. de Champeaux, D. Lea, and P. Faure, Object-Oriented System Development, Reading, MA: Addison-Wesley, 1993.

[7] R. DelRossi, "Update Makes a Good Visual Basic Even Better," InfoWorld, Vol. 15, No. 29, 1993, pp. 78-79.

[8] J. Fitzgerald and A. Fitzgerald, Fundamentals of Systems Analysis. New York, NY: John Wiley and Sons, 1987.

[9] T.J. Heintz, "Object-Oriented Databases and Their Impact On Future Business Database Applications," Information and Management, Vol. 20, No. 2, 1991, pp. 95-103.

[10] T.J. Heintz, "An Object-Oriented Approach to Planning and Managing Software Development Projects," Information and Management, Vol. 20, No. 4, 1991, pp. 281-293.

[11] Interface: Candle's View on IBM's Database World, "The Relational World of Chris Date," Vol. 3, No. 2, 1993, pp. 1-5.

analysis and design.

Pi-Sheng Deng is Professor of Com- puter Information Systems at California State University, Stanislaus. He received his Ph.D. in Management Information Systems from the Krannert Graduate School of Management at Purdue Uni- versity. His current research interests include machine learning and its application to the design of intelligent agents, distributed decision systems, ecology of computation, knowledge-based software engineering, and object-oriented systems

Cynthia L. Fuhr received her MBA from California State University at Stanislaus with a concentration in Com- puter Information Systems. Currently, she is a Programmer/Analyst with the Yosemite Community College District in Modesto, California, which serves both Modesto Junior College and Columbia Community College in the California Central Valley. Her research and consulting interests include object- oriented programming systems and

database management applications. Ms. Fuhr is a member of Association of Systems Management.

Download - Using an object-oriented approach to the development of a relational database application system

Top Related