- Email: [email protected]
Object-oriented methods
ELSEVIER
Clinica Chimica
Acta 222(1993)3-l I
Object-oriented
methods
Helge Erik Solberg Department
of Clinical Chemistry,
Rikshospitalet.
N-0027 Oslo, Norway
Abstract
In modern computer science and practice, there is a strong trend towards object-oriented methods, a tendency that has a hearing also on clinical laboratory computing. The purpose of this introduction is to present the concepts of objects and object-oriented methods from a laboratory scientist’s point of view. Key words: Clinical laboratory; Computing; Object; Object-orientation
‘Object-oriented’ has become almost synonymous with modernity, goodness and worth in information technology circles (Ian Graham [l]).
1. Introduction
In modern computer science and practice, there is a strdng trend towards objectoriented (00) methods, a tendency that has a bearing also on clinical laboratory computing. The purpose of this introduction is to present the concepts of objects and object-oriented methods from a laboratory scientist’s point of view. Probably the most well-known objects in computing are those of the familiar graphical user interfaces. Every user of a personal computer running Windows (DOS) or the Presentation Manager (OS/2) or of a Macintosh manipulates objects on the computer screen. Each window is an object, as are usually also the various constituents of the window: title bar, menu line, scroll bars, buttons, output text, input fields, etc. In the computer program these items have their own data and functionality. A window, for example, ‘knows’ its position on the screen (this is part of its local data) and you can change the window’s localization by a mouse or through * Corresponding author. Abbreviations: LIS, Laboratory Information System; 00, object-oriented. 0009-8981/93/$06.00 0 1993 Elsevier Science Publishers B.V. All rights reserved. SSDI 0009-898 1(93)05716-R
4
H.E. Solberg. /C&I.
Chim. Acia 222 (1993) S-11
keyboard commands (then you activate the window’s own moving function). This simple example illustrates two basic features of an object in computing: it is an item that has both local data and own functionality. 2. The concept of object The term object has a plethora of meanings, among which ‘anything visible or tangible’ [2] seems to partly underlie the concept of object in computing: objects belong to the real world and they may be represented in computer software. Historically, object-oriented methods were first introduced in informatics in the domain of computer simulation of real-world phenomena, of physical entities (objects) and their processes and interactions. But soon objects were also used to represent more abstract items, which are neither visible nor tangible. In this respect, the computer language Smalltalk holds the most extreme view: ‘everything is an object’, from such humble elements as integers and real numbers up to the most complex entities like Smalltalk itself. In 00-programming, an object may rather loosely be defined as a nameable combination of data and methods (Fig. 1). The three key words in this definition are nameable, data and methods. (1) In computer programs each object is identified by name. An example: the object labelled Inpatient in a program may represent a hospitalized person. (2) The object’s data carry status and attribute information. The Inpatient object may, for example, have a Status data element that can take the
Data
Methods
Interface
L
Encapsulation
Fig. 1. An object icon (graphical representation). The object’s name is specified in the icon’s top compartment. The object is encapsulated and has a hidden interior, symbolized by the icon’s data and methods compartments and an accessible interface consisting of message slots used for activation of methods (section of program code).
H.E. Solberg. /Clin. Chim. Acta 222 (1993) 3-11
5
values OnWaitingList, Admitted and Discharged and it may have attribute data elements like Name, BirthDate, Sex, DiagnosisCode and DoctorInCharge. (3) The methods (sections of program code) of an object take care of its functionality. The Inpatient object certainly will have a method that can set the Status to either of the valid values and another method that returns the current value of the Status when inquired. Another important feature of objects is encapsulation. The object has a hidden interior, containing the local data and the methods. The surrounding parts of the program can only access an object at its interface, the ‘visible’ exterior. Thus, one can directly manipulate neither an object nor its data from the outside. The object will itself perform the required operation upon the reception of a message, which activates one of the methods. Other parts of the computer program, for example other objects that it contains, must therefore ask an object to do something by sending a message to which the object can respond. Such a message consists of an address (the object’s name) and the identification of one of the receiving object’s methods. If required by the method, the message may also contain one or moreparameters that specify details of the requested action. The parameters may, for example, state the values to which interior data elements should be set. The set of messages that an object may respond to, i.e. the set of methods that have message ‘slots’ at the interface (Fig. l), constitute the object's protocol. In addition to these exposed methods, the object may have entirely hidden methods that are activated by internal mechanisms. An object may communicate with its surroundings, either by sending messages to other objects or by methods that return simple values or more complex data structures. An 00-program, therefore, consists of a number of objects that interact by politely requesting services from each other through message exchange. 3. An example: the clinical laboratory One may take the clinical biochemistry laboratory (Fig. 2) as an example of an
Specimen
and order Results
Fig. 2. The clinical biochemistry laboratory as a real-world object.
6
H.E. Solberg. /C/in.
/
Chim. Acru 222 (1993) 3-11
LabSystemObj Order info Raw data Final results
--mm---Handle order ( Handle ( Control
analysis )
and verify
results )
Report results ( Store results )
Fig. 3. The object-representation of the clinical biochemistry laboratory in its computer system (LIS). Completely interior methods are specified in parentheses. The other methods interact with the object’s exterior through the interface.
object, a truly giant real-world object. This object may be reflected in an objectoriented computer program, the Laboratory Information System (LB) (Fig. 3) which’might be an OO-module in a global hospital information system. For the purpose of illustration, the laboratory has been greatly simplified: it receives specimens with associated test orders and it produces reports with results (Fig. 2). In 00-terms one may say that this object (the laboratory) may receive one kind of message (the order) that activates an internal method (specimen handling, a set of assays, controls, etc.) according to the message’s parameters (the test requests); after a while the method returns data (the results report). To the requestor the laboratory is encapsulated, the specimen reception desk being the accessible part of its interface (the message slot). The interior workings of the laboratory are completely hidden, like a ‘black box’, but it certainly contains data (request information, measurement raw data, final results, etc.) and methods (assays and administrative routines). Therefore, the internal routines of the laboratory and its analytical methods may be changed without affecting the requestor’s interaction with the laboratory. Figure 3 shows the corresponding LIS object. It contains several internal methods, some of which interact with the object’s surroundings through its interface (handle order, report results, billing) while other methods are completely interior and hidden.
I
H.E. Solberg. / Clin. Chim. Acta 222 (1993) 3-I I
This extremely simplified OO-model may easily be extended to give a more realistic picture of the clinical laboratory and its computer system. The latter is, in fact, an exceptionally complex real-time system and information handler. Still, a completely object-oriented approach is not only feasible, but possibly one of the best approaches, for designing and implementing a clinical laboratory system. The giant LIS-object (Fig. 3) then contains a number of modules, all designed as objects that interact by message exchange and themselves made up of minor objects. Some examples of such parts of the LIS will be discussed in later sections of this introduction. 4. Classes, hierarchies and instances In traditional computer programs a variable is a data element of a specified type. Analogously, in an object-oriented program an object is an instance of a specified cluss (or object type). For example, the objects named Patient, Physician and Labtechnician may all be instances of the class Person. The class is an abstract description of the data and the behavior of an object or a collection of similar objects. It is a template from which object instances are created. (A word of caution may be appropriate here: the nomenclature in this field is not stable [1,3]. The terminology used here is more familiar to users of conventional programming languages with 00-extensions, like C++ and TurboPascal, than to those preferring Smalltalk and other ‘pure’ OO-languages.) A static object is established (instantiated) at compile time and has a fixed location in memory during the complete life-time of the computer program. In contrast, a dynamic object may be created and disposed of at run time. Its memory address is determined when it is instantiated. The latter type of objects may be used to economize memory: they are created when needed and then disposed of again. It is in this way that pop-up windows and dialogue boxes on a graphical user interface Department
Clinical
C
=
Medical services
May have instances
Fig. 4. Example of a class hierarchy. The classes marked with a box may have instances; the other classes are only abstract classes used for building the hierarchy.
8
HE. So/berg. i Clin. Chim. Acta 222 j1993j
3-11
are established. When such an object is needed, it is created dynamically and subsequently removed from memory when the window or box is closed. Related classes may be organized into a class hierarchy. Figure 4 shows an example: the classes used in a LIS to represent the various departments in a hospital. The class Biochemistry laboratory is a descendant (child class) of the abstract class Laboratory, the ancestor (parent class). An abstract class may not have any instances; it has only a role in building the tree. The Laboratory class is itself a descendant of the abstract class of Medical services department. On top of the hierarchy we find the common, abstract ancestor Department. The purpose of organizing the classes in a hierarchy is inheritance. Each descendant is a specialization of its ancestor, which in turn may itself be a descendant. A child class inherits all properties of its parent class and introduces modifications by substitution of some methods (called overriding) and by adding new methods and data elements. For example, the Department class (Fig. 4) is specialized into the Clinical and Medical services department classes. The former class have data elements and methods for storing and handling patient-related information and it is further specialized into two other classes with their own extra data elements and methods depending on whether the patients are hospitalized or not. Some data elements and associated methods are, however, inherited throughout the whole department hierarchy from the root ancestor, e.g. a data element for the name of the department and methods related to that name (setting, changing, reporting, etc.). To organize classes in an inheritance hierarchy makes ~~~y~~rp~~s~ possible. We might, for example, have an abstract class called Number and two descendants called Integer and Real. As their names indicate, instances of the latter two classes handle integers and real numbers. Furthermore, if virtual methods named Add, Multiply and Compare are defined in the Number class and these three methods are overridden in the two child classes, the syntax for adding, multiplying and comparing is the same for both kinds of numbers. Object-oriented systems have the ability to determine at run time the actual class within an inheritance hierarchy of an object. Therefore, the appropriate mathematical method will be invoked for a given integer or real number. This ability to determine an object’s class at run time is called dynamic or late binding, in contrast to static or early binding where the class membership is determined at compile time. OO-languages usually permit the user to select between these two kinds of bindings, the former being more flexible at some cost of computing efficiency. Above, the term ‘object-oriented’ has only been used in relation to programming. In fact, OO-programming was historically the first among 00-methods. The pioneering step towards object-orientation in computing was the introduction of inheritable classes by the computer language Simula [4] in the late 1960s. Simula is a general-purpose OO-language, although it was originally designed to handle discrete events simulation, The development of the Smalltalk language [S] in the 1970s brought the concept of 00-programming to maturity. Since then a plethora of OOlanguages and 00-extensions to conventional programming languages have been developed [l J. However, the concept of object-orientation in computing has recently come to
HE. So&erg. / C&n. Chim. Act@222 (1993) 3-f I
9
have a wider scope than OO-pro~~n~. Now it also includes the methods of OOanalysis, 00-design and 00-storage (databases), which were introduced in the order stated during the last few years [I]. 5. Benefits and fwrther examples 00-methods have some advantages over other strategies in computing. A few of these benefits will be mentioned here. (1) Software objects generally provide a good mapping of reality. Therefore, there may be very close links between the analysis, design and programming phases of a project if an object-oriented approach is used. The Coad-Yourdon approach [6,7] to OO-analysis and 00-design (with their modelling tools) is popular although many alternatives exist [I]. (2) Object-oriented techniques are among the best tools available for structured progra~ng. The encapsulation of data and methods in objects and the messagepassing strategy make it possible to design extremely modular programs with very little interdependency among their different parts. Therefore, it is possible to completely change the interior of an object without affecting other parts of the program as long as the interface and the protocol are not changed. The introduction of new
Fig. 5. Main objects in an object-oriented instrument workstation (explained in the text).
10
H.E. Solberg./ Clin. Chim. Ada 222 (1993) 3-1 I
functionality by adding modules is also fairly easy when everything is implemented as objects. An example from my own laboratory may illustrate this. We had to replace the system for linking analytical instruments to our old laboratory system and installed a network with token ring topology. The network is connected to the LIS through a network server (an IBM PS/2 running under OS/2). The instruments are attached to this network through instrument work stations (also IBM PS/2s), which can handle up to four instruments each. Because of very tight time constraints and because we wanted the system to be maximally modifiable and extendable, we chose an object-oriented approach. Figure 5 shows a very simplified model of the instrument work station (depicting only the main objects) which handles the communication with the instruments, the host computer and the operator under the control of a monitoring object. Communication with the instruments are handled by objects (two of them, InstrObj 1 and InstrObj2, are shown in the figure), which are instances of classes that are all descendants of a generic instrument class. Opening and closing the communication with an instrument may by be done at run time by dynamically instantiating and disposing of the appropriate instrument object. Since all instrument objects have identical interfaces, an instrument work station may handle up to four different instruments simultaneously. This flexibility is obtained because all instrumentspecific features are hidden within the instrument objects. Thus the monitor of the whole system engages in the same message-passing dialogue with all instrument objects, regardless of their internal differences. Another example of the flexibility provided by the object-oriented design is given by the object linking the instrument work station with the host computer. Actually several host objects were developed, all being descendants of a common class and all having identical interfaces. They are therefore all plug-in compatible; the monitor does not see the difference between them. This allows the system to handle different situations. One host object is used when the total system is functioning properly. Then the instrument work stations have close to real-time bidirectional communication with the LIS running on the host computer. Other host objects may handle the situations where there are linking problems between the host and the nework server unit or when the network as such does not function properly, i.e. cases where data have to be written to temporary files either at the net server or in the work stations. The alternative host objects may be activated and taken down dynamically as the situation demands. (3) 00-methods permit the construction of reusable software (class libraries). Many class libraries and object-oriented tools for the construction of windowing user interfaces under DOS, Windows, OS/2, Unix and other system environments have already been commercially available for some time. New products covering other areas of computing are appearing on the market at a quick pace. Private collections of reusable classes may also be developed, however. The use of class libraries may substantially cut down time expenditure in projects. Upgrading of programs as new versions of the libraries become available often consists of the simple task of replacement because of encapsulation of code (see above). In conclusion, object-oriented methods represent a new paradigm in computing that may be very useful also for developing systems for clinical laboratories.
H.E. S&erg. /C&n. Chim. Acta 222 (f993) 3-11
11
6. References 1
2 3 4 5 6 7
Graham I. Object-oriented methods. Wokingham, UK: Addison-Wesley, 1991. Webster’s New Twentieth Century Dictionary, 2nd ed. William Collins + World Publishing Co., Inc., 1978. Budd T. Object-oriented programming. Reading, MA: Addison-Wesley, 1991. Kirkerud B. Object-oriented programming with SIMULA. Wokingham, UK: Addison-Wesley, 1989. Goldberg A, Robson D. Smalltalk-8~ the language and its implementation. Reading, MA: AddisonWesley, 1983. Coad P, Yourdon E. Object-oriented analysis. Englewood Cliffs, NJ: Yourdon Press, Prentice Hall, 1990. Coad P, Yourdon E. Object-oriented design. Englewood Cliffs, NJ: Yourdon Press, Prentice Hall, 1991.
Clinica Chimica
Acta 222(1993)3-l I
Object-oriented
methods
Helge Erik Solberg Department
of Clinical Chemistry,
Rikshospitalet.
N-0027 Oslo, Norway
Abstract
In modern computer science and practice, there is a strong trend towards object-oriented methods, a tendency that has a hearing also on clinical laboratory computing. The purpose of this introduction is to present the concepts of objects and object-oriented methods from a laboratory scientist’s point of view. Key words: Clinical laboratory; Computing; Object; Object-orientation
‘Object-oriented’ has become almost synonymous with modernity, goodness and worth in information technology circles (Ian Graham [l]).
1. Introduction
In modern computer science and practice, there is a strdng trend towards objectoriented (00) methods, a tendency that has a bearing also on clinical laboratory computing. The purpose of this introduction is to present the concepts of objects and object-oriented methods from a laboratory scientist’s point of view. Probably the most well-known objects in computing are those of the familiar graphical user interfaces. Every user of a personal computer running Windows (DOS) or the Presentation Manager (OS/2) or of a Macintosh manipulates objects on the computer screen. Each window is an object, as are usually also the various constituents of the window: title bar, menu line, scroll bars, buttons, output text, input fields, etc. In the computer program these items have their own data and functionality. A window, for example, ‘knows’ its position on the screen (this is part of its local data) and you can change the window’s localization by a mouse or through * Corresponding author. Abbreviations: LIS, Laboratory Information System; 00, object-oriented. 0009-8981/93/$06.00 0 1993 Elsevier Science Publishers B.V. All rights reserved. SSDI 0009-898 1(93)05716-R
4
H.E. Solberg. /C&I.
Chim. Acia 222 (1993) S-11
keyboard commands (then you activate the window’s own moving function). This simple example illustrates two basic features of an object in computing: it is an item that has both local data and own functionality. 2. The concept of object The term object has a plethora of meanings, among which ‘anything visible or tangible’ [2] seems to partly underlie the concept of object in computing: objects belong to the real world and they may be represented in computer software. Historically, object-oriented methods were first introduced in informatics in the domain of computer simulation of real-world phenomena, of physical entities (objects) and their processes and interactions. But soon objects were also used to represent more abstract items, which are neither visible nor tangible. In this respect, the computer language Smalltalk holds the most extreme view: ‘everything is an object’, from such humble elements as integers and real numbers up to the most complex entities like Smalltalk itself. In 00-programming, an object may rather loosely be defined as a nameable combination of data and methods (Fig. 1). The three key words in this definition are nameable, data and methods. (1) In computer programs each object is identified by name. An example: the object labelled Inpatient in a program may represent a hospitalized person. (2) The object’s data carry status and attribute information. The Inpatient object may, for example, have a Status data element that can take the
Data
Methods
Interface
L
Encapsulation
Fig. 1. An object icon (graphical representation). The object’s name is specified in the icon’s top compartment. The object is encapsulated and has a hidden interior, symbolized by the icon’s data and methods compartments and an accessible interface consisting of message slots used for activation of methods (section of program code).
H.E. Solberg. /Clin. Chim. Acta 222 (1993) 3-11
5
values OnWaitingList, Admitted and Discharged and it may have attribute data elements like Name, BirthDate, Sex, DiagnosisCode and DoctorInCharge. (3) The methods (sections of program code) of an object take care of its functionality. The Inpatient object certainly will have a method that can set the Status to either of the valid values and another method that returns the current value of the Status when inquired. Another important feature of objects is encapsulation. The object has a hidden interior, containing the local data and the methods. The surrounding parts of the program can only access an object at its interface, the ‘visible’ exterior. Thus, one can directly manipulate neither an object nor its data from the outside. The object will itself perform the required operation upon the reception of a message, which activates one of the methods. Other parts of the computer program, for example other objects that it contains, must therefore ask an object to do something by sending a message to which the object can respond. Such a message consists of an address (the object’s name) and the identification of one of the receiving object’s methods. If required by the method, the message may also contain one or moreparameters that specify details of the requested action. The parameters may, for example, state the values to which interior data elements should be set. The set of messages that an object may respond to, i.e. the set of methods that have message ‘slots’ at the interface (Fig. l), constitute the object's protocol. In addition to these exposed methods, the object may have entirely hidden methods that are activated by internal mechanisms. An object may communicate with its surroundings, either by sending messages to other objects or by methods that return simple values or more complex data structures. An 00-program, therefore, consists of a number of objects that interact by politely requesting services from each other through message exchange. 3. An example: the clinical laboratory One may take the clinical biochemistry laboratory (Fig. 2) as an example of an
Specimen
and order Results
Fig. 2. The clinical biochemistry laboratory as a real-world object.
6
H.E. Solberg. /C/in.
/
Chim. Acru 222 (1993) 3-11
LabSystemObj Order info Raw data Final results
--mm---Handle order ( Handle ( Control
analysis )
and verify
results )
Report results ( Store results )
Fig. 3. The object-representation of the clinical biochemistry laboratory in its computer system (LIS). Completely interior methods are specified in parentheses. The other methods interact with the object’s exterior through the interface.
object, a truly giant real-world object. This object may be reflected in an objectoriented computer program, the Laboratory Information System (LB) (Fig. 3) which’might be an OO-module in a global hospital information system. For the purpose of illustration, the laboratory has been greatly simplified: it receives specimens with associated test orders and it produces reports with results (Fig. 2). In 00-terms one may say that this object (the laboratory) may receive one kind of message (the order) that activates an internal method (specimen handling, a set of assays, controls, etc.) according to the message’s parameters (the test requests); after a while the method returns data (the results report). To the requestor the laboratory is encapsulated, the specimen reception desk being the accessible part of its interface (the message slot). The interior workings of the laboratory are completely hidden, like a ‘black box’, but it certainly contains data (request information, measurement raw data, final results, etc.) and methods (assays and administrative routines). Therefore, the internal routines of the laboratory and its analytical methods may be changed without affecting the requestor’s interaction with the laboratory. Figure 3 shows the corresponding LIS object. It contains several internal methods, some of which interact with the object’s surroundings through its interface (handle order, report results, billing) while other methods are completely interior and hidden.
I
H.E. Solberg. / Clin. Chim. Acta 222 (1993) 3-I I
This extremely simplified OO-model may easily be extended to give a more realistic picture of the clinical laboratory and its computer system. The latter is, in fact, an exceptionally complex real-time system and information handler. Still, a completely object-oriented approach is not only feasible, but possibly one of the best approaches, for designing and implementing a clinical laboratory system. The giant LIS-object (Fig. 3) then contains a number of modules, all designed as objects that interact by message exchange and themselves made up of minor objects. Some examples of such parts of the LIS will be discussed in later sections of this introduction. 4. Classes, hierarchies and instances In traditional computer programs a variable is a data element of a specified type. Analogously, in an object-oriented program an object is an instance of a specified cluss (or object type). For example, the objects named Patient, Physician and Labtechnician may all be instances of the class Person. The class is an abstract description of the data and the behavior of an object or a collection of similar objects. It is a template from which object instances are created. (A word of caution may be appropriate here: the nomenclature in this field is not stable [1,3]. The terminology used here is more familiar to users of conventional programming languages with 00-extensions, like C++ and TurboPascal, than to those preferring Smalltalk and other ‘pure’ OO-languages.) A static object is established (instantiated) at compile time and has a fixed location in memory during the complete life-time of the computer program. In contrast, a dynamic object may be created and disposed of at run time. Its memory address is determined when it is instantiated. The latter type of objects may be used to economize memory: they are created when needed and then disposed of again. It is in this way that pop-up windows and dialogue boxes on a graphical user interface Department
Clinical
C
=
Medical services
May have instances
Fig. 4. Example of a class hierarchy. The classes marked with a box may have instances; the other classes are only abstract classes used for building the hierarchy.
8
HE. So/berg. i Clin. Chim. Acta 222 j1993j
3-11
are established. When such an object is needed, it is created dynamically and subsequently removed from memory when the window or box is closed. Related classes may be organized into a class hierarchy. Figure 4 shows an example: the classes used in a LIS to represent the various departments in a hospital. The class Biochemistry laboratory is a descendant (child class) of the abstract class Laboratory, the ancestor (parent class). An abstract class may not have any instances; it has only a role in building the tree. The Laboratory class is itself a descendant of the abstract class of Medical services department. On top of the hierarchy we find the common, abstract ancestor Department. The purpose of organizing the classes in a hierarchy is inheritance. Each descendant is a specialization of its ancestor, which in turn may itself be a descendant. A child class inherits all properties of its parent class and introduces modifications by substitution of some methods (called overriding) and by adding new methods and data elements. For example, the Department class (Fig. 4) is specialized into the Clinical and Medical services department classes. The former class have data elements and methods for storing and handling patient-related information and it is further specialized into two other classes with their own extra data elements and methods depending on whether the patients are hospitalized or not. Some data elements and associated methods are, however, inherited throughout the whole department hierarchy from the root ancestor, e.g. a data element for the name of the department and methods related to that name (setting, changing, reporting, etc.). To organize classes in an inheritance hierarchy makes ~~~y~~rp~~s~ possible. We might, for example, have an abstract class called Number and two descendants called Integer and Real. As their names indicate, instances of the latter two classes handle integers and real numbers. Furthermore, if virtual methods named Add, Multiply and Compare are defined in the Number class and these three methods are overridden in the two child classes, the syntax for adding, multiplying and comparing is the same for both kinds of numbers. Object-oriented systems have the ability to determine at run time the actual class within an inheritance hierarchy of an object. Therefore, the appropriate mathematical method will be invoked for a given integer or real number. This ability to determine an object’s class at run time is called dynamic or late binding, in contrast to static or early binding where the class membership is determined at compile time. OO-languages usually permit the user to select between these two kinds of bindings, the former being more flexible at some cost of computing efficiency. Above, the term ‘object-oriented’ has only been used in relation to programming. In fact, OO-programming was historically the first among 00-methods. The pioneering step towards object-orientation in computing was the introduction of inheritable classes by the computer language Simula [4] in the late 1960s. Simula is a general-purpose OO-language, although it was originally designed to handle discrete events simulation, The development of the Smalltalk language [S] in the 1970s brought the concept of 00-programming to maturity. Since then a plethora of OOlanguages and 00-extensions to conventional programming languages have been developed [l J. However, the concept of object-orientation in computing has recently come to
HE. So&erg. / C&n. Chim. Act@222 (1993) 3-f I
9
have a wider scope than OO-pro~~n~. Now it also includes the methods of OOanalysis, 00-design and 00-storage (databases), which were introduced in the order stated during the last few years [I]. 5. Benefits and fwrther examples 00-methods have some advantages over other strategies in computing. A few of these benefits will be mentioned here. (1) Software objects generally provide a good mapping of reality. Therefore, there may be very close links between the analysis, design and programming phases of a project if an object-oriented approach is used. The Coad-Yourdon approach [6,7] to OO-analysis and 00-design (with their modelling tools) is popular although many alternatives exist [I]. (2) Object-oriented techniques are among the best tools available for structured progra~ng. The encapsulation of data and methods in objects and the messagepassing strategy make it possible to design extremely modular programs with very little interdependency among their different parts. Therefore, it is possible to completely change the interior of an object without affecting other parts of the program as long as the interface and the protocol are not changed. The introduction of new
Fig. 5. Main objects in an object-oriented instrument workstation (explained in the text).
10
H.E. Solberg./ Clin. Chim. Ada 222 (1993) 3-1 I
functionality by adding modules is also fairly easy when everything is implemented as objects. An example from my own laboratory may illustrate this. We had to replace the system for linking analytical instruments to our old laboratory system and installed a network with token ring topology. The network is connected to the LIS through a network server (an IBM PS/2 running under OS/2). The instruments are attached to this network through instrument work stations (also IBM PS/2s), which can handle up to four instruments each. Because of very tight time constraints and because we wanted the system to be maximally modifiable and extendable, we chose an object-oriented approach. Figure 5 shows a very simplified model of the instrument work station (depicting only the main objects) which handles the communication with the instruments, the host computer and the operator under the control of a monitoring object. Communication with the instruments are handled by objects (two of them, InstrObj 1 and InstrObj2, are shown in the figure), which are instances of classes that are all descendants of a generic instrument class. Opening and closing the communication with an instrument may by be done at run time by dynamically instantiating and disposing of the appropriate instrument object. Since all instrument objects have identical interfaces, an instrument work station may handle up to four different instruments simultaneously. This flexibility is obtained because all instrumentspecific features are hidden within the instrument objects. Thus the monitor of the whole system engages in the same message-passing dialogue with all instrument objects, regardless of their internal differences. Another example of the flexibility provided by the object-oriented design is given by the object linking the instrument work station with the host computer. Actually several host objects were developed, all being descendants of a common class and all having identical interfaces. They are therefore all plug-in compatible; the monitor does not see the difference between them. This allows the system to handle different situations. One host object is used when the total system is functioning properly. Then the instrument work stations have close to real-time bidirectional communication with the LIS running on the host computer. Other host objects may handle the situations where there are linking problems between the host and the nework server unit or when the network as such does not function properly, i.e. cases where data have to be written to temporary files either at the net server or in the work stations. The alternative host objects may be activated and taken down dynamically as the situation demands. (3) 00-methods permit the construction of reusable software (class libraries). Many class libraries and object-oriented tools for the construction of windowing user interfaces under DOS, Windows, OS/2, Unix and other system environments have already been commercially available for some time. New products covering other areas of computing are appearing on the market at a quick pace. Private collections of reusable classes may also be developed, however. The use of class libraries may substantially cut down time expenditure in projects. Upgrading of programs as new versions of the libraries become available often consists of the simple task of replacement because of encapsulation of code (see above). In conclusion, object-oriented methods represent a new paradigm in computing that may be very useful also for developing systems for clinical laboratories.
H.E. S&erg. /C&n. Chim. Acta 222 (f993) 3-11
11
6. References 1
2 3 4 5 6 7
Graham I. Object-oriented methods. Wokingham, UK: Addison-Wesley, 1991. Webster’s New Twentieth Century Dictionary, 2nd ed. William Collins + World Publishing Co., Inc., 1978. Budd T. Object-oriented programming. Reading, MA: Addison-Wesley, 1991. Kirkerud B. Object-oriented programming with SIMULA. Wokingham, UK: Addison-Wesley, 1989. Goldberg A, Robson D. Smalltalk-8~ the language and its implementation. Reading, MA: AddisonWesley, 1983. Coad P, Yourdon E. Object-oriented analysis. Englewood Cliffs, NJ: Yourdon Press, Prentice Hall, 1990. Coad P, Yourdon E. Object-oriented design. Englewood Cliffs, NJ: Yourdon Press, Prentice Hall, 1991.