Critique of the Object Oriented Paradigm: Beyond Object-Orientation
By
Shajan Miah
Date: 14th May, 1997
Chapter 1
"In the name of Allah, the most gracious, the most merciful"
1.0 Introduction
This research study, investigates some of the problems and unresolved issues in the OOPar. Contrary to adopting a WHAT (the problem) and HOW (the solution) approach it uniquely asks WHY these problem and issues exist. We argue that the WHAT & HOW approach, although useful in the short term, does not provide a long term solution to the problems in data modelling (DM). As a result of adopting such an approach and the empirical and wide ranging nature of chapter 3, four aspects are proposed. These are:
philosophical presuppoisition,
subjectobject integration,
appropriateness,
and levels of description.
We believe that the problems exist, because of weaknesses in these four areas. We show how the problems identified link in to these four aspects, and also recommend further research direction in these aspects. This report, also highlights that the WHYs proposed by the philosophical and rationalist camp, although useful, do not account for most of problems and issues found in data modeling.
2.0 Motivation
The object oriented paradigm (OOPar) has been heralded as the saviour to the problems faced in software development (ACM,1990, 1992). Indeed, Cox(1991) goes to the extent of describing it as the "silver bullet" to the software crisis. In the computing press, there are literally 100s of articles expounding the benefits of the OO approach. The motivation for this writer, to adopt an impartial perspective and to carry out a critique of the OOPar, ironically originates from these avalanche of uncritical testimonials.
3.0 Objectives
In investigating a new area of this type it is difficult to define a full set of objectives, hence our objective at the start of this project was to:
1. Investigate the OOPar and see if any problems exist.
However, our research for (1), has led to some very interesting new findings. It has resulted in an initial proposal for a radically different approach to data modeling, which we discuss in due course.
4.0 The Structure
This report is structured as follows:
Chapter 2 provides description of the underlying concepts of the OO model, and outlines some of the claimed benefits. Chapter 3 highlights some of the problems, found in the OOPar. Chapter 4 lists solutions (where they exist) to some of the problems discussed in chapter 3. It argues that these solutions are symptomatic, and proposes a different approach to understanding and addressing the issues and problems identified in chapter 3. Chapter 5 delves deeper into the proposals made in chapter 4, and shows how the problems identified in chapter 3 link into these proposals. Chapter 6 analyses the rationalist and philosophical camps views, as to why the problems in data modeling exist, in respect of the framework proposed in chapter 4. It also provides suggestions for future research areas. Chapter 7 concludes this study.
5.0 Method
The research methods used in this study have varied throughout the course of this project. In chapters 2 and 3 the primary research approach has been to widely search for existing critical literature on the OOPar and discuss problems and issues with OO practitioners. The remainder, has been a combination of originality, discussions with many people, and some reading into the issues covered in chapters 4, 5, and 6.
6.0 For The Reader
6.1 Why you should read it?
There are perhaps several good reasons for this, here we highlight the key ones:
1. Firstly, OO has been heralded as the "silver bullet" (Cox, 1991) to the software crisis. However, this technique as yet has had no empirical evaluation. As Curtis (1995) points out "it is curious that industries which perform sophisticated return on investment analyses of investments in plant and equipment will commit billions of dollars to investment in software development which uses new techniques [OO] that have received little to no valid empirical evaluation."(p.337). The empirical nature of this study, highlights some problems and key issues that yet remain to be solved in the OOPar.
2. Secondly, there are very few critiques of the OO model. Those handful of critical assessment that exist, are sadly buried in the avalanche of uncritical testimonials, found in the computer press. This study, references, re-surfaces, and uses many of these critiques.
3. As a result of our findings, we propose a new framework to data modeling. The framework we tentatively propose and discuss is unique, although not complete, it explains why many of the problems found in DM exist. The framework we propose, provides a radically different and interesting insight into the issues in DM, and we feel merits further research.
A radical study of this type, is naturally controversial. The report is very much, in the spirit of the framework, holistic - therefore we beg for the readers patience.
Acknowledgments
The author wishes to extend his thanks and gratitude to the following people for their help, direct or indirect, throughout the course of this study: Naveed Ikram, TIME Research, University of Salford - for his advice and the very useful informal discussion sessions, Young Baik, University of Waterloo (Canada), Liz Hampson, University of Lancaster, Gillian Ritchie, LPAC, London University, Tim Ottinger, Rekal Nahar, Professor Oscar Nierstrasz, University of Geneva, and those good folks at comp.object and comp.databases.object.
Special word of thanks are also due to all the writers, (i.e. practitioners) who have reported the problems in the OO paradigm.
Last but not least, the author would like to express his sincere thanks to Dr A. Basden, for his constructive criticism, and encouragement throughout this project. Without his advice, guidance and support, the outcome of this study, surely would have been much less interesting and useful.
References
1. ACM (1990). "Special Issue on object-oriented design". Communications of the ACM, Vol: 33, Issue: 9.
2. ACM (1992). "Special issue on analysis and modeling in software development". Communications of the ACM, Vol: 35, Issue: 9.
3. Brooks, FP (1987). "There is no Silver Bullet".***
4. Cox, B (1991). "There is a silver bullet". Byte (16), pp.108-110, 1991.
5. Curtis, B (1995). "Objects of Our Desire: Empirical Research on Object-Oriented Development". Jn: Human-Computer Interaction, Vol: 10, pp.337-344.
Chapter 2
1.0 Introduction
In this chapter some of the core concepts of the OOPar are introduced. We also outline some of the benefits claimed by advocates of this approach. Both of these areas are covered comprehensively in many standard OO books, therefore we will not describe them in any detail.
2.0 Concepts of the OO model
The main concepts that underline the OOPar, are outlined in the following sections.
2.1 Object Classes & Objects
In the OOPar, the problem domain is modeled using object-classes, and there instances objects (Booch, 1994). An object is any abstract or real world item that is relevant to the system. An object class is a grouping of these objects. For example, in a library information system an object-classes would be such things as members, books, etc. Objects would be instances of these classes, e.g. Joe Bloggs, Object-oriented analysis by Martin, etc.
2.2 Methods
Methods are predefined operations, and are associated with an object-class. "Methods specify the way in which an object's data are manipulated" (Martin & Odell, (1992), p.17). Therefore, the member object class identified earlier may contain methods such as reserve_book, borrow_book, and etc. Access to an object is only granted via the methods.
This, in fact is one of the key features of the OO model, that is behaviour (methods) and data-structures (i.e. the declarative aspect of an object) are not separated - these are encapsulated together in one module.
2.3 Encapsulation
The process of keeping methods and data together, and granting access to the object only through the methods is referred to as encapsulation. This achieves information hiding, i.e. "The object hides its data from other objects and allows the data to be accessed via its own methods" (Martin & Odell, p.17).
2.4 Inheritance
Inheritance is the process, where a high-level object class can be specialised into sub-classes. Wirfs-Brock et al(1990), define inheritance as "... the ability of one class to define the behaviour and data structure of its instances as a superset of the definition of another class or classes." (p.24).
For example, in the library system, at a later stage we may find that two types of members exist, children and adult. To accommodate this, we can make use of inheritance by abstracting all the common features into a high-level member class and further create two new sub-classes, adult-members and child-members, under the member class. Sub-classes would also inherit data and functions from the super class.
2.4.1 Multiple Inheritance
Multiple inheritance, is almost identical in concepts to single inheritance, however in this case a sub-class can inherit from many super-classes. For example, at a later design stage of the library system, we may have a situation, where a book is of type fiction and is also a reference book. This potentially, allows the use of multiple inheritance.
2.4 Polymorphism & Dynamic Binding
The term polymorphism, originates from the Greek word 'poly morph' meaning many forms. In the context of the OOPar, the polymorphism concept allows different objects to react to the same stimuli (i.e. message) differently (Hymes, 1995). For example, adult and child members, may only be allowed to borrow books for up to 6 and 3 weeks respectively. Therefore the borrow_book message to the adult-member class will respond differently (i.e. date books by 6 weeks), than the same message to the child-member class (date books by 3 weeks). There are variations and degrees of polymorphism (e.g. operator overloading), which the interested reader is guided to standard OO textbooks (see refs. at end).
2.5 Genericity
Generic (or parametric) classes are those that define a whole family of related classes, differing only in matters concerning one or more types that are used as arguments to the class of declarations (deChampeux et al, 1993). The concept of genericity allows the designer to specify standard generic classes that can be reused. For example, in designing any system, a number of common programming situations require the same class structure to be applied to different data types. Examples of several situations in user interface systems are the following:
queue class
* a queue of characters entered by a user
* a queue of mouse events that have occurred and are waiting to be handled.
In each case the same basic algorithms and supporting data structures are needed. What varies among uses of the class is the type of the data being manipulated. Lists are also used to maintain relationships in OO programming languages, hence in the case of the library system a standard generic list class could be defined to maintain the relationship between members and books reserved, for example.
3.0 Claimed Benefits
This section describes some of the key, general claimed benefits of the OOPar. The list is, of course, not extensive and their are many other claimed benefits of this approach which are described later, in their respective sections.
3.1 Naturalness of Analysis & Design (Cognition)
One of the frequently claimed benefits of the OOPar is that it is natural (therefore more understandable), and is assumed to be cognitively similar to the way human beings perceive and understand the real-world (Meyer, (1988); Rosson & Alpert (1988); Rosson & Alpert(1990). Martin & Odell (1992, p.31) for example, states "The way of thinking is more natural for most people than the techniques of structured analysis and design. After all, the world consists of objects." Mcfadden & Hoffer(1994, p.) similarly note "The notation and approach of the object-oriented data model builds on these paradigms that people constantly use to cope with complexity." This claim, therefore assumes that it is more natural for developers to decompose a problem into objects, at least as compared to the traditional structured languages. In other words, it should be natural for developers and users to map the problem into objects and into classification hierarchies.
3.2 Software Reuse
Software reuse is perhaps the most publicised benefits of the OOPar. Advocates of the OOPar claim that it provides effective mechanisms to allow for software to be reused (Meyer,1988). For example Budd(1996), states "Well designed objects in object-oriented systems are the basis for systems to be assembled largely from reusable modules, leading to higher productivity." (p.31). Martin & Odell(1992), similarly state "It [OO] leads to world of reusable classes, where much of the software construction process will be the assembly of existing well-proven classes." (p.31).
These mechanisms are encapsulation, polymorphism, and inheritance. For example, encapsulation allows object classes to be modified, or even added to new systems without requiring additional modification to other classes in the system. The end-goal of this, is to develop a component based software industry (as Martin & Odell point out), where classes can be purchased, and plugged in. Inheritance allows existing code to be reused. Genericity allows the reuse of one standard class.
3.3 Communication Process
Curtis & Waltz (1990) and Krasner, Curtis, & Iscoe(1987), report that at the software team level, some of the key problems encountered are communication and coordination, capturing and using domain knowledge and organisational issues. With the OO approach, advocates claim that communication and coordination between the project team and client(s), and also within the team are enhanced. For example, Rumbaugh et al(1991, p.4), claimed that "greatest benefits [of OO] come from helping specifiers, developers, express abstract concepts and communicate them to each other. Martin & Odell (1992, p.34) also similarly state, "Business people more easily understand the OO paradigm. They think in terms of objects.....OO methodologies encourage better understanding as the end users and developers share a common model." Similar statements can be found in many popular text books, e.g. (Coad & Yourdan (1991, p.3); Jacobson, Christerson, Johnsson, & Overgaard, (1992, p.43); Wirfs-Brock, Wilkerson, & Weiner (1990, pp. 10 - 11).
This claim is based on two premises:
1. Naturalness of OO (described above) makes understanding easier,
2. Objects are constructed from the problem domain, hence communication between project team and client(s) is enhanced. Also, because a single representation permeates throughout all stages of life-cycle, therefore communication and coordination within the team is facilitated.
3.4 Refinement & Extensibility
OO advocates, also claim that "software" developed using the OOPar is easy to refine and extend.
Khoshafian(1990) states "Object oriented programming techniques allow the development of extensible and reusable modules" (p.274). Graham(1994), similarly notes, "Inheritance, genericity or other forms of polymorphism make exception handling easier and improve the extensibility of systems." (p.37). These claims are related to three key principles of the OOPar, encapsulation, inheritance and polymorphism.
For example, encapsulation allows the internal implementation of a class to be modified without requiring changes to its services (i.e. methods). It also allows new classes to be added to a system, without major modifications to the system. Inheritance allows the class hierarchy to be further refined, and combined with polymorphism, the superclass does not have to "know" about the new class, i.e. modifications do not have to be made at the superclass.
4.0 Definition of OO Model
In critiquing a concept it is common to start with a formal definition. However, in this research project we will not do this, for the following reasons:
1. Unlike the relational model, the OO model does not have one commonly accepted formal definition.
2. As a result of (1) trying to define the OO model, is in itself a considerable research task.
Our approach will, therefore be to investigate reported problems in the application of the OOPar, and academic critiques. And, then to try and identify common threads and similarities between these problems.
5.0 Conclusion
In summary, in section 2 we outlined some of the core concepts that underline the OO model. Section 3 provided an outline of some of the key claimed benefits of the OO model. Finally in section 4, we discussed our reasons for not formally defining the OO model.
In the next chapter, we investigate some of the problems in the OOPar.
References
6. Booch, G(1994). "Object-Oriented Design with Applications". Second Edition - The Benjamin/Cummings Publishing Company, Inc.
7. Budd, TA (1996). "Object-oriented programming". Addison-Wesley, Reading, MA.
8. Coad, P, Yourdan, E (1991). "Object-oriented analysis (2nd. ed.)". Englewood Cliffs, NJ, Prentice-Hall.
9. Curtis, B, Krasner, H, & Iscoe, N (1988). "A field study of the software design process for large systems". Communications of the ACM, Vol: 31, pp. 1268-1287.
10. de Champeaux, D, Lea, D, Faure, P(1993). "Object-oriented system development". Corporate and Professional Publishing Group, ISBN: 0-201-56355-X.
11. Graham, I (1993). "Object Oriented Methods". Second Edition, Addison-Wesley. ISBN: 0-201-59371-8.
12. Hymes(1995). "Classification in the Object Oriented Paradigm from a Cognitive Psychological Perspective: A Research Proposal". http://www.csmil.umich.edu/~chymes/Professional/papers/OO/Dissertation/formal.html
13. Jacobsan, I, Christenson, M, Johnsson, P, and Overgaard, G (1992). "Object-oriented software engineering: A use case driven approach." Reading, MA, Addison-Wesley.
14. Khoshafian, S (1990). "Insight into object-oriented databases". Jn: Information and Software Technology, Vol: 32, Issue: 4, pp. 274-289.
15. Krasner, H, Curtis, B, Iscoe, N (1987). "Communication breakdowns and boundary spanning activities on large programming projects". In Oslon, GM, Sheppard, S, & Soloway, E (eds.), Empirical studies of programmers: Second Workshop (pp. 47-64). Norwood, NJ, Ablex.
16. Meyer, B (1988). "Object Oriented Software Construction". Prentice Hall, International Series in Computer Science.
17. Martin, J, Odell, J (1992). "Object-oriented analysis and design". Englewood Cliffs, NJ, Prentice-Hall.
18. McFadden & Hoffer (1994). "Modern Database Management Systems".
19. Rosson, MB, Alpert, SR(1990). "The Cognitive Consequences of Object-Oriented Design." Jn: Human-Computer Interaction, 1990, Vol: 5. pp. 345-379.
20. Rosson, MB, Alpert, SR (1988). "The Cognitive Consequences of Object-Oriented Design." Research report, RC14191, IBM, New York.
21. Rumbaugh, J, Blaha, M, Premerlani, W, Eddy, F, & Lorensen, W (1991). "Object-oriented modeling and design". Englewood Cliffs, NJ, Prentice-Hall
22. Wirfs-Brock, R, Wilkerson, B, & Weiner L (1990). "Designing object-oriented software". Englewood Cliffs, NJ, Prentice-Hall.
Chapter 3
1.0 Introduction
This chapter investigates some of the problems in the OOPar. It describes problems faced in the application of the OOPar, as well as general "academic" critiques - which are in most cases supported by problems encountered in the real world application of the OOPar.
2.0 Apparent Naturalness
2.1 Problem Discovery & Definition
With the now established OOA & OOD (see ref 1 - 10) methods, advocates of the OOPar insist that the object paradigm offers complete life-cycle support (see ref 1 - 10). However, Howitz(1992), argues that the OOPar offers very little help in some aspects of systems analysis that are critical in Management Information Systems (MIS).
MIS analysis activities are separated in to two areas (Howitz, 1992):
1. Problem investigation & discovery,
2. and system structure specification.
According to Howitz(1992), OO methodologies, by using techniques and concepts such as object-class, relationships, method-definitions, interaction definition, and etc, offer "excellent support" for area 2. Howitz complains that very little attention is given to area 1. Typically the types of questions that need to be addressed in area 1 are (Howitz, 1992):
1. What is the business problem/opportunity that the system should address?
2. What are the appropriate boundaries between the new system and manual procedures or other interfacing systems outside of our scope?
3. What are the key user events or activities the system is meant to impact and how do these activities interrelate?
4. What are the major abstractions that the system must store and what are the relationships between the data?
Some of the guidelines offered by OO advocates in addressing these issues are (Howitz, 1992):
a. Underline the nouns in a written specification and consider these as candidate classes.
b. Do your work side by side with a subject-matter expert.
c. Use rapid iterative proto-typing to elicit requirements.
According to Howitz(1993), "To an MIS manager, these types of answers seem both simplistic and hopelessly naive." (p.63). Howitz suggests that, perhaps one of the reasons why this area is inadequately supported, is because OO technology was pioneered by individuals with real-time scientific engineering applications in mind - were well known deterministic rules, and causal relationships exist. Therefore the area of problem definition is not a fundamental issue. These characteristics are, however very different to those found in developing MIS (Howitz, 1992), and in many complex problem areas in real life. This is also evident in many other ideas and concepts developed in academia, where very little consideration is given to tacit level (Polyani, 1967; Basden, 1996) issues, that is the use and actual application of the technology.
The following are some of the characteristics of MIS, identified by Howitz(1992):
e. Application boundaries undefined.
MIS projects start from symptoms. Investigation of the root-causes of the symptom to determine the application boundary of the system are very difficult and complex.
f. Lack of subject matter experts.
Subject-experts do not exist. Very few people understand the whole system, even personnel working in their areas, also often do not fully understand it.
g. Problems are not deterministic
There is no one right way for the system to address the symptoms (there are usually many ways). The appropriate way, often has to be negotiated, through dialog with the business customer - rather than confirming whether it is right or wrong.
e. Manual activities are important.
Understanding and even changing the manual areas outside the application boundary can also be as important. Howitz points out that, "The object-oriented methods and notations that I have observed tend to start and end with the automated portion of an application."(p.63).
A definition of the problem in this type of domain, would require a variety of approaches and techniques, such as consensus building, user communication, cost-benefit analysis, etc. Howitz, complains that the problem definition approaches in current OO methodologies are inadequate for large MIS systems, he notes, "I do not know of any single methodology that adequately deals with problem investigation and discovery." (Howitz, 1992, p.63).
Aksit & Bergmans(1992), also note similar class hierarchy definition problems in large systems (ref [68- 72]). In their study of 12 pilot OO objects, they found that in well defined, that is well understood, theoretically founded problem areas identification and classification of class hierarchies are not very complex. However, similarly to Howitz(1992) they also note that, "Quite often underlying theories of large systems are not completely understood, and it is difficult to define reusable hierarchies for these types of systems." (Aksit & Bergmans, (1992), p.12)
McGinnes(1992), after completing an evaluation of some of the popular OO methodologies similarly reports that most of them cannot be used in the very earliest stages of analysis, i.e. the problem definition stages. Most OO methods are preceded by a requirements definition activity, the output of which is a textual description of the system requirements (McGinnes, 1992). However, McGinnes argues that "the methods will not become widely used if they cannot be used from the earliest stages of analysis. The concept of prior narrative requirements specification needs to be viewed with some caution." (McGinnes, (1992), p.13).
The issues raised in this section would seem to suggest that the OOPar, is weak at defining the problem in ill-structured domains. In fact, Lewis(1993), argues this very point, he argues that these problems are a result of the naive realist philosophical assumptions of the OOPar. We discuss these further in chapter 5.
Key Issues:
1. Problem Definition & Discovery. OOPar does not adequately address problem definition and discovery in large complex (MIS) projects, i.e. in ill-structured domains.
2. Need method to overcome 1.
3. Philosophical Assumption. Makes naive philosophical assumption about real-world problems.
2.2 Naturalness of OO
In chapter 2, we described the naturalness claim made by advocates of the OOPar. We noted that this claim is based on two fundamental assumptions:
1. Assumes that the world is made of objects and relationships.
2. Assumes human beings think in terms of objects & classes, etc.
There has, however been no empirical study to support assumptions 1 and 2. We discuss assumption 2 in section 4 (below). Hence, there has been very little empirical evidence to support the ardent "naturalness" claim made by advocates of the OOPar.
Recent experimental study by Detienne(1990), shows that in fact the naturalness claim of OO may not be entirely accurate. In her experimental study, Detienne used 8 programmers experienced in structured programming. 4 of the programmers were trained in OO for several weeks and the other 4, where novices, but had a one day introduction to the principles of OO. The programmers were presented with two identical problems, one declarative-type and the other procedural. The programs were implemented in the O2 OODBMS (Lecluse, 1988; Deux, 1990). Subjects were also familiar with the problem area. Detienne(1990), reports that novices and "experienced" OO programmers generally had difficulties in appropriately structuring the classes. The following were some of the key difficulties novices faced using OO:
1. Identifying classes.
2. Experienced difficulty in structuring their solution (forming hierarchies, etc.)
3. Defining ISA and PART-OF relationships.
4. Associating methods to appropriate classes.
The findings reported by Detienne(1990), would then appear to contradict the claim made by OO advocates. In arguing against some of the claims made in the OOPar, Detienne(1990), states:
"It appears from our study that designing a problem with an object-oriented language is not so easy and so natural as the advocates of OOP say. The hypothesis on naturalness of design with an OOP language is not confirmed by our data. Our observations show that decomposing a problem into solution is not easy, specifically for identifying classes and articulating objects and functions....." (Detienne, (1990), p.976).
Similar research by Scholtz(1993) and Vessey et al(1994) also suggests that the naturalness claim of the OOPar is not supported. Vessey et al(1994), compared the design performance of novice programmer using object oriented, procedural, and data design methodologies. They reported that novices performed best using procedural methods and worst using object-oriented methods.
Scholtz(1993) reported findings from programmers shifting to OO approaches. Their research findings highlighted many design problems. Some of the main ones were:
1. Classes too finely decomposed
2. All functionality (i.e. methods) grouped in one class.
3. Identification of extra classes which did not exist in the problem area.
The cases presented in this section, highlight several issues:
Firstly, the claim that OO is more natural, and as a result finding abstraction should be straight-forwards, may not be as accurate as many believe it to be. Fischer(1995), commenting on the naturalness claim of the OOPar, similarly notes "...the mapping from the problem domain to the solution is not yet seamless."(p.106).
This leads to the second limitation of understandability, although even if we assume that developers and clients might both be thinking in terms of objects, this however does not mean that they will be thinking in terms of the same objects (illustrated in some of the above cases, e.g. identification of additional objects that do not exist in UoD). Fischer(1995) commenting on practical OO experience similarly points out "Not all objects that the users conceptualize in the problem domain will be objects in the solutions...."(p.106).
A third problem, that is apparent from the cases presented is, even using an OO approach it is not necessarily easy to select the "right" objects. This is a more deeper issue, and as Fischer(1995), points out "These problems reflect difficulties in modeling and communication, which are not resolved simply by adopting an OO approach."(p.105).
Key Issue:
4. OO design is not as natural as many believe it to be.
5. The DM, should be based on an accurate understanding of issues 1 & 2 (above).
2.3 Naturalness of OO - 2
McGinnes(1992), argues that objects in the real world are distant from those in the information systems. Often reality needs to be "bent" around the OO model. For example, purchase can be modeled as an object-class, event, or method - in the real-word it is in fact all of these (McGinnes, 1992). Also some operations do not belong to any classes, again reality needs to be adjusted to cater for the OO model. However, the problem that McGinnes argues is not so much bending reality to fit around the OO model, but more the failure to distinguish between real-world and system objects, that is a lack of conceptual model - which is evident in the object oriented literature. For example, Martin & Odell(1992) state "[In OO] The analysis translates directly into design and implementation." (p.34). Other statements to this effect can also be found in many OO textbooks, e.g. Wirfs-Brock et al(1990), Rumbaugh et al (1991), etc.
The lack of intermediate model (i.e. conceptual model) between the real-world and the information system can, as McGinnes argues be dangerous and result in misuse. He points out, "The confusion between objects in the system and objects in the world, and the lack of an intermediate conceptual model, are cause for concern. The idea that object-oriented systems are a "natural" representation of the world is a seductive but dangerous over-simplification. In reality, the fact that the object models seems so close to reality makes it far easier to misuse it than other modeling techniques which do not purport to represent the world so directly." (p13).
Key Issues:
6. Conceptual Model. The lack of clarity in conceptual model between real-world and system is dangerous, and can result in inaccurate use of the model.
7. Even though, OO may model reality more closer that its predecessors (e.g. RM), still require a conceptual model.
2.4 Multiple Views & Conflicting Views
In any problem area there will always be several views of what the actual problem is and its potential solutions. It is then a prerequisite for any useful modeling tool to be able to model and integrate these effectively. As a simple example, in the context of a specification for a factory floor information system, workers may feel that the specific problem is due to ageing machinery, whereas middle management, in contrast may adopt a different perspective to the problem.
A recent investigation by McGinnes(1992) reports, that out of the many OO design methodologies, few if any support the concept of multiple views in a problem domain. This problem is further increased when there is a conflict of objectives and interests, - which view, should then take precedence? These findings suggest that the OO model applied on its own is inadequate in these types of problems, and needs to be applied within a particular interpretivist systems development methodology.
Key Issue:
8. Inadequate support for multiple views.
2.5 SQL Views
In an organisation it is also common for different user groups to view the corporate data model in different ways (McGinnes, 1992). A particular user group may require a simplified view of the corporate data model. This is effectively supported by SQL views in the relational model. However no such equivalent mechanism exists in the OO database arena (McGinnes, 1992). Aksit & Bergmans(1992), also similarly report problems in four pilot projects (ref 68, 71,72), due to inadequate support for multiple views. They note, "The multiple views problem was clearly observed in the administrative system, the intelligent tutoring system, the distributed office system, and in the intelligent mail system." (Aksit & Bergmans, (1992), p.26).
The symbol level problems with views in the OOPar, are discussed in section 6.2. The support for SQL type views is also essential if the multiple views problem is to be effectively dealt with by the model (other issues also need to be addressed).
Key Issue:
9. Need support for multiple views.
3.0 The Query Problems
3.1 The Ad-hoc Query Problem
Ad-hoc queries, are specified by end users (generally) as and when required. Date(1995) notes the following key differences between programming and database technology:
1. Programming languages, design applications - specific for one area. Database applications are more generic.
2. Database applications continuously evolve.
These differences underline two fundamental implications:
a) Firstly, because programming languages are used in designing specific applications, ad-hoc queries are not essential.
b) Secondly, database systems are more generic and cater for a wider range of user. Date(1995), therefore argues that in a DBMS ad-hoc queries are not only necessary but essential.
In the OO model, objects are queried through pre-defined methods, the statements below underline this position:
"Object orientation focuses on the types of objects whose data structure can be manipulated only with the methods of the object class."(Martin & Odell, p.31).
"Modules implemented in an object-oriented style are accessed purely via their interface..." (Graham, (1993), p.37).
"Methods (or service): A processing routine that encapsulated in an object and operates on the data described within that object." (McFadden & Hoffer (1994), p.172).
The above statements (see also Rumbaugh et al, 1991; Wirsf-Brock et al, 1990), show that in the OOPar, objects can only be accessed through well-defined interfaces (via methods). Date(1995), argues that this approach leaves the data analyst with two key dilemmas:
3. In the pure OO model ad-hoc queries are not possible (as methods need to be pre-defined).
4. As a result of (3), If methods are the only way of interrogating an object (i.e. performing some operation on it), this then implies that in OO databases, every query must be predefined!
However, from the difference noted by Date(1995), we can see that (4) is an impossible task. Aksit & Bergmans(1992) further highlight the problem of adhoc querying in the OOPar, in real-world applications. They report on difficulties encountered in three projects (ref 68, 69, 72), due to weak querying mechanisms in the OOPar. Brown(1991), similarly highlights the difficulties of adhoc queries in OO databases, he notes, "Unfortunately, a large number of object-oriented database systems are specifically aimed at fixed interaction with complex objects; it is not at all easy to define ad hoc queries on the data." (p.102).
The inadequate consideration of adhoc queries, can perhaps be attributed to the "bottom-up" evolution of the OOPar, (i.e. evolving from a programming domain in to database technology). This is also consistent with the differences between programming and database technology noted by Date(1995), i.e. in designing specific applications ad-hoc queries are not essential.
The ad-hoc query problem, would seem to indicate that the pure OO model is perhaps inappropriate in the database domain.
Key Issues:
10. Ad-hoc queries. The DM should provide effective ad-hoc querying facilities, the OO model is inadequate in this area.
3.2 Method Placement Problem
If no powerful ad-hoc query facilities are provided in an OODBMS (Dittrich (1995)), the designer is then left with no option but to use methods for queries. Besides being almost impossible to define every query, methods also pose another placement problem in database systems. In the OO model, methods are associated with specific objects, either because:
1) The method carries out processing on the internal data structures of that object. For example, Martin & Odell(1992), state "The methods in an object type reference only the data structures of that object type."(p.17).
2) Or because it provides a service for that object (i.e. sends a message to another method, which is located using (1 - above) in another object).
Although in the context of a programming domain (1) and (2) are useful and appropriate, but this approach is not as appropriate in a database environment. Consider, the following example query:
Find all suppliers who supply at least one red part to more than one project (taken from Ling et al, 1993, p.268).
Besides being a complex method to write, there are (at least) three potential object-classes the method can be placed in, i.e. suppliers, parts, or project (placement guidelines for (1) do not apply as processing is carried out on three objects). The choice of location, in this case needs to be determined by efficiency concerns, i.e. in which object class most of the processing is carried out. The placement issue, is further complicated and becomes more critical, when objects are distributed across remote sites and different platforms. Inappropriate placement of methods, could result in a potentially simple query, taking lengthy periods of time to process.
Although, this may initially seem a trivial problem, in a distributed database system where it is common to have 1000s of objects, the placement of methods becomes a key efficiency concern. For example in an X.500 type database (Chadwick, 1995), appropriate placement of methods is critical.
In programming languages, placement of method is not a key issue. However, in distributed database systems where multiple objects are accessed using methods, placement is of fundamental concern. In the OO literature, inadequate guidance is given on the appropriate placement of methods in a database environment. This, similarly is not seen as an issue. Lack of consideration of this issue can also perhaps be attributed to the "bottom-up" evolution of the OOPar.
Key Issue:
11. How to prevent methods being placed in distant places leading to slow access.
4.0 The Identity Problem
One of the claimed advantages (see below) of object oriented systems is that it eliminates the problem of entity identity, i.e. the primary key problem. In the relational model primary keys are either artificially created or attributes of the tuple are used to form a primary key (PK). The main problem with PKs, is handling changes to the values of the key, maintaining updates are quite complex and difficult, even in most modern relational database management systems (RDBMSs).
Most of the published literature on database systems, when dealing with some of the problems associated with the use of PKs, only adopts a narrow symbol level perspective, i.e. difficulty in maintaining updates, changes, and etc. Very little, if any, consideration is given to the sometimes important role of the PK at the knowledge level (Newell 82, 93). The most important function of the PK is as an interaction element between the real-world and the database. It is thorough the primary key that we usually query the database. The primary key is of fundamental importance if we are to "usefully" relate the concepts of the database to the real world. Here we are going beyond the symbol level (S/L) to the knowledge level (K/L) use of the primary key concept.
"An object retains its identity through arbitrary changes to its own state. This is in contrast to the relational model where the properties of an entity must be sufficient for it to distinguish it from all other entities. That is, there must be an attribute or attributes whose values uniquely and immutably identify that entity. The properties of uniqueness and immutability are not always present in the real-world and it is often necessary in relational databases to introduce artificial identifiers for entities."(Hughes, 1993, p.117)
(This appears to be a paradoxical statement, as the author also admits that sometimes unique values may not exist!)
Hughes, implies in the above statement that this is a limitation of the Relational model, i.e. the introduction of an artificial value to identify some real-world concept. According to Hughes, the OO model does not have this problem as it uses system created OIDs (a bit level concept), some programming pointers to identify the real-world concept. However what Hughes does not consider is that, we do this in everyday life in the real-world we create artificial keys to identify real-world objects. For example the UK registration scheme on cars, the Ministry of Transport deliberately employs an artificial mechanism to identify the cars in the real world (in the UK). This is not done for efficiency purposes (bit & symbol level), but rather for identifying the item (in this case a car) in the real world, and hence is at the knowledge level. Consider another simple example - names are attached (artificially) to new-born children, usually by the family head and are generally (in most cases) unique within the family. These values identify a person within the context of the family. The deliberate creation of keys, also has another importance, from a HCI (Human-Computer Interaction) perspective, in that control of key values is retained by the user.
Date(1995), also notes two similar reasons why PKs are needed.
1. The concept of uniqueness does not apply to some objects (that is unless one goes to the extreme of including details of the physical matter of the object). This as we showed earlier, is applicable to the UK motor industry, where registration number is created to differentiate between cars with similar properties.
2. Standard way of linking the object to the real-world - the control is with the user, in contrast to the OO model, where the system decides.
The authors of the Third-Generation Database Manifesto (1990), also argue that "An immutable primary key has an extra advantage over a system-assigned unique identifier because it has natural, human readable meaning. Consequently, in data interchange or debugging this may be an advantage."(p.12).
Although, the OID approach to identification used in the OOPar, does overcome some of the symbol level problems associated with PKs, it ignores the sometimes important role of the PK at the K/L and therefore can result in fundamental problems at the K/L. Our claim is not that the OO model cannot cope with the PK concept, but rather that it takes a narrow bit & symbol level perspective, and as a result the concept of PKs is not actively supported by the OO community.
Thus, although the OO model claims to eliminate the need for keys (Hughes, 1993) the preceding examples illustrate the importance of the PK concept at the K/L.
Key Issues:
12. Key Support. The OO model ignores the usefulness of the PK at the K/L, and adopts a B/L approach to it. (Still need PKs).
4.1 PK In The OO Model
The use of pointers in the OO model, raises two further issues:
Firstly the PK has been extensively used in indexing, query optimisation, etc. theories in the relational model(Codd, 1970) - therefore new modified techniques would have to be developed for the OO model - but these are all at the S/L and B/L. The most important implications are, however at the K/L. One implication is, as Date(1995) also argues - if we do not have PKs, then we cannot usefully relate the entities in the database to the real-world.
In the following sections, we consider some of the important K/L implications.
4.1.1 Usefully Interacting to the Real World
The OO model implements keys at the Bit Level (B/L), i.e. using pointers to objects (Hughes, 1993). Pointers are hidden from the user, as they are seen as an unnecessary complication (Hughes, 1993; Third Generation Database Manifesto, 1990).
However, consider two identical cars, take the example of a Nissan Cherry, if we assume that the properties in the database system do not differentiate between the two cars - this is possible, in two cases:
1. Properties genuinely do not differentiate, e.g. reg-no not included,
2. Or typing error and two reg_no are the same
There is then no way for the user to tell the difference between the cars (as the OID is hidden from the user). There may be many Nissan Cherrys' in the UK, all having identical features (Red, 1.3, etc) - if the Ministry Of Transport cannot differentiate between these instances (i.e. "usefully" relate to the real-world"), this then results in a problem at the K/L, i.e. relating an object from the database to the real-world.
Key Issues:
13. Link to the R/W. OIDs do not "usefully" link an item to the real-world.
4.1.2 Maintaining Weak Entities / Semantics of OIDs
In the Relational model PKs are also used intrinsically to maintain integrity. For example, weak entities share part of the key with the parent entity. This builds an element of integrity constraint intrinsically within the model, i.e. a child cannot exist if the parent does not. However, due to the use of unique pointers this benefit is not available in the OO model - where derived entities are viewed as equal, in that they have an OID independent from the parent (Ling et al - 1993).
Dittrich(1995), similarly notes that the use of OIDs results in a lack of semantics in PART-OF relationships between object classes. Dittrich uses the example of a document class. A document class may have many chapter sub-objects (i.e. PART-OF relationship). If a document is deleted, printed, or formatted - then these operations should be repetitively applied to its sub-objects. Dittrich notes, as a result of the use of OIDs, "This is not supported in common ODBMS products, nor can users code this functionality in regular defined classes later on (at least not in its entirety)." (p.244).
Dittrich(1995), aptly summarises these problems in current OODBMSs, "Basically, all references are to independent objects, and semantics of relationships within complex objects are hidden within the user supplied operations." (p.243).
Key Issues:
14. Dependent entities. With OIDs, every item (i.e. object) is seen as equal. However some items, are dependent on others.
15. OID semantics. OIDs cannot capture the semantics in relationships.
5.0 OO Model From a Cognitive Perspective
The OO paradigm, was introduced in programming languages, one of its key objectives being to reduce the cognitive load imposed on programmers. It is then no surprise, that one of the most frequently quoted advantages of the OO model is that it provides a natural way of modeling the real world. This claim was described in chapter 2, we also noted that it is based on two fundamental premises:
1. Assumes that the world is made of objects and relationships.
2. Assumes human beings think in terms of objects & classes, etc.
Although advocates of the OOPar claim that OO model supports the human cognition process (2 - above), thereby making the modeling task easier, in actual fact there has been very little empirical research carried out to support this claim. Recent research by Hymes (1995), shows that the assumptions made in the OO model of the human cognitive process, is in fact not entirely accurate (and in some circumstances is less than ideal). We outline some of the key issues in the following sections.
5.1 Object Class - Fuzzy Set Membership
Current OO methods do not allow for ambiguity. The presence or absence of features of an object completely determines the class membership. In object classes these features are attributes (i.e. data structures) and the methods (Rumbaugh et al, 1991; Cox, 1991; Martin & Odell, 1992; Meyer 1988). This approach is very much like Aristotelian set theory. The presence of ambiguities, is in fact attributed to a lack of understanding of the problem domain (Yourdan, 1994, Martin, 1992). As Hymes(1995) notes, "Object Classes are perfectly rigid, an object is a member of a class or is not. It is not the case that an object is a member of a class to some degree..." (p.17).
Hymes (1995), argues that although human-beings understand the real world in terms of objects one, determining class membership is, however, fuzzy and not rigid. Human beings tend to fuzzify the boundaries of an object. To illustrate this point consider the class tall-person. How do we define whether a person qualifies to be a member of the sub-class tall? In the OO model either someone is a member of tall class (i.e. is tall) or is not. The human being, in contrast takes a different approach and attaches truth values to whether an item belongs to a class or not, e.g. 5 feet 9 inches is 'tallish', 6ft is tall, and 7ft is very tall. It is as a result of this concept of fuzziness that led to the advent of Fuzzy Logic (Zadeh, (1965). Hymes(1995), also points out that according to (Barsalou, 1983; Murphy & Medin 1985; Nakamura, 1985), "Even which attributes are relevant for determining category membership are also dependent upon goals of the reasoner, the context in which the decision is being made, and upon the knowledge base that the reasoner uses when determining membership" (p.17).
Therefore, in the above example, we can see that the OO model does not support the concept of fuzzy boundaries and imposes an "concrete ontological", or as Hymes(1995) uses "formal ontological" approach on to the designer and can hinder his/her understanding - thereby going against one of the key objectives of the OOPar.
Key Issues:
16. OO is not cognitively accurate as many believe it to be. See below.
17. Fuzzy set membership. OO demands crisp defined set boundaries; but in real life set boundaries are often fuzzy. The DM should offer support for this. [For instance Case Based Reasoning can help here.]
5.2 Some classes are more exemplary than others
In the real world some objects are more exemplary of a class than others, we account for these in an intrinsic psychological way. For example Robin is more exemplary of the class bird than the Emu (Smith, Shoben & Rips, 1989; Medin, 1989). However this is not accounted for in the OOPar, both instances are treated as equal members of the object class bird (Hymes, 1995).
Key Issues:
18. Typicality. In real life, some classes are more typical than others (e.g. robin vs. emu as typical bird); if it has the idea of class, the DM should recognise this.
5.3 Inclusiveness
In the OOPar, object classes are designed to be completely inclusive, where sub-classes inherit all features from its super-classes. Cancelling an inherited feature is considered as bad practice (Hymes, 1995). For example (adapted from Hymes, 1995), given a super-class Bird, where the behaviour "fly" is defined for all its objects, if a sub-class is required that does not use the "fly" behaviour, the guideline is then to create an extra-layer flying bird, and non-flying bird, under the Bird super-class (Cox 1991; Martin, 1992). However, Hymes(1995), argues that psychological categories do not have to be perfectly inclusive. The fact that some birds can fly, and some cannot does not require an additional layer (as is the case in OO guidelines). People simply treat these as atypical members of the class (Hymes, 1995).
Key Issues:
19. Inclusiveness. Psychological classes do not have to be perfectly inclusive, in OOPar object classes are designed to be perfectly inclusive.
5.4 Object Reusability
In the OOPar, one of the aims in design is to abstract and place attributes and methods in to the highest level possible of the hierarchy. This is done to allow for reuse of code.
Thus the design goals of object classes, is (Booch 1994, Rumbaugh et al, 1991):
However according to Rosch (1978); Rosch, Mervis, Gray, Johnson, & Boyes-Braem, (1976); Rosch & Carolyn, (1975) psychological categories in contrast have the following characteristics:
5. Have the most important information about category membership scattered throughout a hierarchy.
6. Have fewest top level attributes
7. Have many "mid-level" attributes
8. Have fewer lower level attributes
Object classes designed from the criterias above (1-4) will have a very top heavy distribution of features compared to psychological categories. Psychological categories, are in contrast (according to 5-8) networks formed by causal and explanatory links and properties, not a hierarchy based on attributes (Hymes, 1995). Psychological categories have many attributes in the mid-level categories, and fewer features in superordinate and subordinate categories (Rosch et al, 1975; Rosch et al, 1976; Rosch, 1978).
Thus the criterias set out for reusable class hierarchies, are not as natural as many believe it to be.
Key Issues:
20. Attribute density distribution. (Rosch et al, 1975; Rosch et al, 1976; Rosch, 1978) In OO the density distribution of attributes in the class hierarchy is different from that found in human knowledge.
21. Common types of relationship. OO emphasises different types of relationships than are found in real life (inheritance rather than causality etc.)
5.5 Summary
In sum, as Hymes(1995) notes, "A good deal is known about the structure and usage of peoples `categories and concepts, and these differ significantly from the design proposed in the Object oriented paradigms."
Psychological categories are hence, different from object classes in the rigidity of their definitions, the nature of category membership, and the distribution of the most salient attributes (Hymes, 1995). More importantly the issues described in this section show that the most oftly quoted "cognitively natural benefit" (see chapter 2) of OO, is in fact not entirely true.
6. Other Issues
6.1 Viewing everything as Objects
In the pure OO model, everything is viewed as objects (Aksit & Bergmans, 1992), The usefulness of this approach, has been well documented with the success of Smalltalk, in a programming environment.
Ling et al(1993), argue that this approach is not entirely suitable in a database environment. In a database environment, viewing everything as objects is not always appropriate. As Ling et al (1993), note "To treat everything as objects will only blur the differences among these notions."(p.271).
In databases system, there is also the need for the explicit notion of attributes, and the different types of relationships (i.e. M:N, 1:N, etc.). The Entity Relationship Model (Chen, 1976), takes this approach, by treating these differently, and representing each explicitly it captures the semantics of a problem domain more effectively than the OO model (Ling, 1993).
Key Issues:
22. Distinct Roles. Objects (items), attributes and relationships have different roles in a database; the DM should maintain their distinct nature; OO and (RDM) fail to do this.
23. Treating things as objects. Re. (1), the DM should nevertheless allow for attributes and relationships to be *treated as* objects (items) when necessary, even though their fundamental distinctiveness is maintained. (e.g. should allow relationships to have attributes, and even other relationships with other things.)
6.2 View Support
The OO Model, does not provide adequate support for views (Ling, 1993). The importance of views has been discussed in section "SQL Views". As Ling et al (1993, p.272) note "Except for those OODBMSs that are based on the extended relational model (e.g. POSTGRES), most OODBMSs do not fit into the 3-level schema architecture framework as spelled out in the ANSI/X3/SPARC proposal for DBMSs." After completing a survey on current OODBMSs Kim(1995), also notes "No OODB today supports views." (p.261).
Dittrich(1995, p.250), suggests the following possible reasons why views are inadequately supported in the OOPar:
1. There has been the opinion that data encapsulation and inheritance make view definitions unnecessary.
2. Views in relational DBMSs are treated like predefined queries. As OODBMs do not provide elaborate query languages, there is no powerful declarative language to define views.
3. Views in relational DBMSs can be considered as a means of access control. For a long time, access control has been a low interest to the OODBMS vendors, due to the typical CA* applications where rather coarse security mechanisms were considered sufficient.
4. The treatment of views is a problem of considerable complexity in the context of method invocation and inheritance.
Key Issues:
24. View Support. The OO DM does not provide adequate support for views. View support is also essential for other issues, e.g. security, corporate database etc.
6.3 Lack of Formal Foundation
Relational databases are based on the relational model, which is mathematically defined in FOL, normalisation, data dependency and set theory (Codd, 1970). Functional dependency, multi-valued dependency, etc. allows symbolic quality of data structure to be evaluated. However due to lack of formal foundation, the OO Model does not have these benefits. Therefore symbolic quality of an OO model cannot be judged.
Although, one may argue that the OO model provides better K/L quality (which is true - but see section 4 above) and is more important - but S/L is also important as well (see section 5.4 on Irreducibility of Levels - chapter 5).
Key Issues:
25. SL foundation and quality evaluation. RDM is founded in mathematics (SL); OO has no SL foundation. So its symbolic quality cannot be evaluated. [But we could say that OO is more founded in - even though (section 5) above - and hence provides greater KL quality than the RDM.]
6.4 Lack of Declarative Language
The Relational DBMS has SQL, as the defacto query language. However, no such standard exists for OODBMS. After a recent survey on issues in current OODBMSs applications, Dittrich (1995), highlights this position, "Today's OODBMSs offer restricted query facilities on object collections with rather simple optimization strategies (some products being more advanced than others)." Similarly Kim(1995), notes "Most of the OODBs suffer from the lack of query facilities..." (p.261).
Ling et al (1993), suggests that a query language for OODBMSs is likely to be more complex for the following reasons:
1. Query language, has to take into account the class hierarchy.
2. Output of queries usually not homogenous (unlike RDBMs) - so application must be able to cope with this.
3. Additional processing overhead needed to check the type of each instance.
Dittrich, 1995, p.241 also notes another key issue in developing a declarative query language for OODBMS, "The formalisation and algebraic description of the object model (or some object model) is far more difficult than, say the relational algebra and has not yet been achieved in a commonly accepted form. Especially when it comes to the use of method calls in queries, the formalization, is all but clear."
Supporting queries, also makes encapsulation, which is central to the OOPar, difficult to support.
Key Issues:
26. Query Language. No standard query language (with similar features as SQL) exists for the OO DM.
27. Type checking. Because of the importance of the Type idea, Type-checking should be carried out with minimum overheads; in OO the overheads are often large.
6.5 Class Hierarchy Conflict
Conflicts can occur in a class hierarchy. In a normal class hierarchy (i.e. single parent), the conflicting method or attribute is generally over-ridden by the sub-class, via redefinition. This problem is further increased in an multiple inheritance class hierarchy, where it is common to have conflicting (and repeating) attributes and methods. Ling et al 1993) identify, three ways that these problems are generally addressed:
1. For repeated inheritance, rename or ignore.
2. For conflicting inheritance, over-ride.
3. Do not allow this to occur (implemented by some OODBMS)
However all these approaches are at the syntatic (Ling et al, 1993), i.e. the symbol level and not at the semantic level. Consideration is not given to the meaning of these conflicts, i.e. why the occur in the first place. By ignoring the reasons for these conflicts, the designer is applying symbol level techniques, to a problem that has possibly important implications at the knowledge level. Consider for example, in a large system if inheritance conflict are occurring often, then there is a need to analyse - why they are occurring. This would require consideration of the semantics of the program structure. Applying symbol level techniques, would in effect be solving the symptoms of a K/L problem.
In current OO technology, these issues are, inadequately in the opinion of this author, dealt at the symbol level. This is perhaps, one reason why the issue of including multiple inheritance is "hotly" debated in the OO community.
Key Issues:
28. Inheritance Conflicts. The model should try to sort this at the K/L, not at the S/L.
29. K/L Mechanism. Need K/L mechanism in DM to solve (1).
6.6 Uncertain Information
From the prespective of the subject, the world is full of uncertain information. As database systems model portions of the real world, the data model should therefore provide mechanisms to handle uncertainty. In the real world, there are a wide variety of different degrees and types of uncertainties. In the context of database systems, Snodgrass(1995), identifies the following application areas where uncertainty handling mechanisms are essential:
Hetregenous Databases
As large database systems are tending to be merged, there will be a need to handle uncertainty as there may be contradictory data in each - with respect to some subject.
Multimedia Databases
In traditional databases retrieval is usually based on exact matching. This is however not ideal when dealing with digitised images in multimedia databases. For example, normally a text label is attached to image - which is then the field where search is carried out. However recent systems have attempted to offer approximate image matching searches (IBM's eg.) - this will require the use of uncertainty formalisms.
Imputation & Knowledge Discovery
In many scientific disciplines, it is sometimes essential to calculate missing data from other data that is available. This process is referred to as imputation. This cannot be dealt with by traditional databases. Uncertainty techniques are essential.
Snodgrass(1995), argues that current data models ignore the issues of uncertain information, he notes "Database systems of the current generation are not designed to manage information that is permeated with uncertainty. Uncertain data is stored as null values or it must be excluded from the database, and users with uncertain requests can use queries with simple patterns or they must browse the database to find their answers."( p.473).
The issue of uncertatinty appears to have been ignored in the OO literature (theoretical), Date(1995), aptly describes this, "Missing information is far from being a fully solved problem in relational systems. But OO systems mostly seem to ignore the problem altogether, at best the evidence suggests that the OO community lags some-way behind the relational community in this regard." p.681.
Key Issues:
30. Uncertainty. The DM should offer support for handling uncertainty of various kinds; OO does not do so. See following.
31. Contradictory Information. The wider the scope or domain of a database, the larger the portability that there will be contradictory information; the DM needs mechanism and methodologies to manage this.
32. Fuzzy matching. OO database matching is exact; in real life much matching is fuzzy; the DM needs to offer facilities for fuzzy matching.
33. Missing Information. In real life much information is missing and must be obtained, maybe to lesser accuracy, in other ways; the DM should offer ways of doing this.
7.0 Support for Relationships
Most OO data model, treat relationships intrinsically and do not provide explicit support for relationships. For example the O2 (see Deux, 1990; Lecluse et al, 1988) and ORION (Kim, 1991; also see Dittrich, 1995) OO data-models use this approach. Relationships are modelled using inter-object references (OIDs) and the ISA type class hierarchy.
However using this method, handling m:n and n-ary (n>2) relationships can be problematic (discussed below). These problems are very similar to those found in the network and hierarchical data model.
Several problems may arise, due to the lack of wide support for explicit relationships in the OOPar, these are discussed in the following sections.
7.1 Problem of Symmetry
Before discussing some of the different types of problems that may arise with handling relationships intrinsically - this section provides a brief summary of the issue of symmetry in queries, as discussed by Ling et al, (1993).
To explain the issue of symmetrical query, consider the following data schema - adapted from Lecluse (1988):
SUPPLIER (P1) supplies many PRODUCTS(P2) and PRODUCTS(P2) are supplied by many SUPPLIERS(P1).
In the relational model, this scenario would be modelled by two entities P1 and P2 and an explicit relationship, i.e. a gerund which may contain the quantity and date of delivery, etc. However in the OOPar, due to the lack of wide explicit support for relationships, there is a tendency for this scenario to be implemented using inter-object references (OIDs).
There are two options available, either P1 can contain a list of P2 and the respective quantities, etc - or P2 can contain a list of P1 also with a list of quantities, and so forth. However this option does not allow for symmetrical queries. Assuming that we have chosen the former option, then given P1, it is easy to find a list of P2. The reverse is however not possible.
In order to overcome these P2 also contains a list of P1, along with quantity, etc. Although this solves the symmetrical query issue - it gives rise to a further complex problem, which we discuss in the next section.
The issue of symmetrical queries, is also a problem in the Relational Model, i.e. we have to navigate through the gerund.
7.2 The Common Relationships - Inverse and M:N.
Consider the following data-structure adapted from Lecluse (1988).
(ob1, <name: 'John', spouse: ob2 (OID of)>)
(ob2, <name: 'mary', spouse: ob1 (OID of)>)
In the above example inverse relationships are used to implicitly model the relationship between object 1 and 2, primarily to overcome symmetrical query problems (discussed in the previous section). However the use of inverse relationships also leads to maintainability problems, consider the changes required if mary and john decide to have divorce. Then details in both object 1 and 2 would need to be changed, however this is not the case if relationships are modelled explicitly, i.e. changes only have to be made at one place (the relationship). This problem is further increased in m:n and n-ary relationships. Ling et al, (1993, p.272) describes this as "a contradiction to the easy maintainability objective of the OO Paradigm."
To illustrate this problem further, consider the following (M:N) example schema, adapted from Ling et al (1993):
PARTS (P), SUPPLIERS (S) - SUPPLIES is the relationship between SUPPLIERS and PARTS.
In the object oriented approach the relationship between S and P is modelled using inter object OID references. For example, S could contain a set of OID values of P and the respective quantity. However this does not allow efficient symmetrical querying. To overcome this P also, then includes a set of OIDs for S with and their respective quantities. This approach, again leads us to the anomaly discussed above, (i.e. redundancy which leads to update anomalies).
These problems are further increased when n-ary (n>2) relationships are increased - Ling et al (1993), argue that, "the OO Model provides no feasible solution for modeling n-ary relationships using OIDs (inter-object references)."
The above arguments indicate that the explicit notion of relationship is required. Cattrell (1991), suggests the use of new object type classes for relationships. However this concept is not widely supported in the OOPar.
Although, we say that the DM should provide explicit support for relationships, it is important that this support should be genuine. For example, M:N relationship types are supported in the relational model using two 1:N relationships (reducing to 1:Ns) - this overcomes maintainability issues, but it still does not resolve the symmetrical query problems, i.e. we can only navigate through the gerund. Therefore genuine support for M:N and other relationship types need to be provided. Many of the proposals for incorporating relationships in the OO model, are unfortunately taking this reductionist approach to relationships.
Basden(1993), reports on problems using the KAPPA-PC (object-oriented knowledge representation software package) in modeling relationships. In Kappa-PC, relationships other than ISA were not directly (i.e. explicitly) supported. This required some programming to overcome. Basden(1993), complains, that more seriously (due to lack of direct support) it proved very difficult for relationships to contain attributes.
Key Issues:
34. Relationships. Because of their distinct roles, the DM should provide explicit support for relationships, rather than rely on (10. Distinct Roles) above. See 2, 3 below.
35. Relationship cardinality. To achieve 1), in particular, the DM should support M:N rather than requiring the modeller or user to break them down to two 1:Ns.
36. Relationship Symmetry. To achieve (1), the DM should recognise that relationships are two-way (or n-way for n-ary relshps) rather than single-way pointers, and should therefore facilitate the two-way navigation and two-way labelling.
7.3 What about other relationship types?
In the ERM, other "special" relationship, such as union, intersection, and decompose are supported. Ling et al(1993) argue that using OIDs, these other relationships cannot be supported in the OO model.
In an earlier paper, Ling (1985), identifies the importance of these relationship types, Ling et al(1993) complain that these seem to have been largely ignored in the OOPar.
There are other relationship types these also need to be supported. These issues are further discussed in chapter 4 and 5.
Key Issues:
37. Other Relationship Types. The world is not only made up of n-ary relationship types, there are others. DM should provide support for other relationship types.
7.4 Support for Indirect Integrity
Referential integrity is concerned with maintaining the consistency of the database, and therefore is at the symbol level. Although, referential integrity, is at the symbol level, there is also another type of integrity constraint closely associated with it, which we refer to as indirect integrity, which is at the knowledge level(Newell 82, 93). Indirect integrity, is concerned with the meaning, i.e. the semantics of the reference (referential integrity). Common, with other K/L issues, indirect integrity is rarely discussed in text-books.
The following example (adapted from Basden, 1996) illustrates the importance of indirect integrity and allows us to discuss some of the issues.
In the Relation Model (Codd 1970), if we consider three relations Patients (P1), Problems(P2), and Patient-Problem (P3). Patient-Problem is an explicit relationship that is used to model the m:n relationship between P1 and P2. In the relation P3, if a user enters the value Patient-No: 1234, and Problem-No: XYZ, these are checked for existence in P1 and P2 - if they exist, then the transaction is accepted and the system is in a state of referential integrity. However, what if Patient 1234, is of the sex: male, and Problem XYZ is Pregnancy - is the system then still in a state of integrity? Although the meaning of the reference is nonsensical, at the referential integrity level the system is still in a state of integrity. But at the indirect integrity level - barring some future medical advance - the answer is no!
In the relational model genuine support for indirect integrity is not provided and has to be programmed in using SQL statements. The object-oriented model is no better in this respect. For example, if we consider the same patient-problem example, by replacing the keys with OIDs - the same problems will still persist, and therefore support for indirect integrity has to be programmed in. The support for sub-typing of relationships in the OOPar, is useful in dealing with some problems (similar to the above one) but it cannot be used in all cases. Reality is fluid, and relationships cannot always be divided into neat hierarchies (i.e. subtypes). Relationships are not always hierarchical, and often form a complex interlinked web.
The lack of support for indirect integrity is due to the value-oriented nature of the OO (and relational) data models.
As we noted, the above problem can be overcome by "programming" in indirect integrity constraints (in the OOPar or R/M), for example one option would be to have an additional attribute "suitability", which could perhaps contain a value of 1 to indicate relationship acceptable or 0 for invalid. However, this in effect solves the symptom of the problem and results in a loss of efficiency.
The use of OID may, in fact make programming in the solution-code even more difficult. If OIDs are system assigned and uniquely identify each object, then designing an algorithm to check for semantics perhaps becomes more tedious. The simplest approach to this problem is to add a character(s) to the PK, to indicate whether the patient is a male or female, however due to the lack of support for PKs in the OOPar this option is not available.
Although these problems can be overcome, by tedious IF-THEN programming or some other equally tedious method. The key issue here is that we need to go beyond the symbol level support provided and provide knowledge level support for indirect integrity. The OO model does not provide adequate knowledge level support for indirect integrity.
Key Issues:
38. Indirect Integrity. DM should provide genuine K/L support for indirect integrity. The OO (and relational) model fail to do this.
8.1 Subjective View Problem
In the pure object model, the intrinsic properties of an object are modelled as data members along with the respective member functions and placed within the object-class (Harrison & Ossher, 1993). For example in a tree object class (adapted from Harrison & Ossher, 1993) intrinsic properties are things such, as the weight, mass, height, etc (see diagram 1 below). In this simple example, if a tax assessor, or a bird also needed to use the tree class for calculating tax, we would then need to add additional data members, such as tax rate, etc. These are extrinsic to the tree. Harrison & Ossher(1993), identify two ways of handling this situation:
1. Treat the extrinsic properties as intrinsic.
2. Or "the application can be treated constructed as a client using the encapsulated methods.."(Harrison & Ossher, p.411).
Option 2) is not the norm and complicated (and not always possible), therefore following on from option 1, let us assume in order to cater for the tax assessor we treat the extrinsic properties as intrinsic to the tree. However what happens if there are further subjects? For example, a woodcutter, or even a bird. Each will have different requirements. This may then lead to complex, sophisticated object structures. Harrison & Ossher(1993) argue that "This ideal classical model is utterly inadequate to deal with the construction of large growing suites of applications manipulating the objects." (p.411).
Although these examples may seem anthropomorphic, they prove one key point, i.e. different subjects will have different requirements from the object. In the context of an integrated application suite, subjects could be different application programs, as Harrison & Ossher(1993), state "The tree could easily be a node in a parse tree, the bird an editor, the assessor a compiler...." (p.412).
The key problem then is how to predict and effectively design for all these subjective views, particularly in the OO model where the tendency is to consider the object as the basic fundamental primitive. Harrison & Ossher(1993) point out this tendency, they note "If object-oriented technology is to be successfully scaled from the development of independent applications to development of integrated suites of applications, it must relax its emphasis on the object." (p.411).
In the context of single application areas these problems do not arise, however as Ossher & Harrison (1993) identify when integrating objects into large multiple application domain then objects may have many different subject views.
Harrison & Ossher (1993) argue that, in an integrated application suite object oriented analysis alone is not sufficient, the subjective views also need to be taken into account and effectively integrated.
Key Issue:
39. Subjective View. (Harrison + Ossher, 1993). In an integrated application suite (or DB system) we have an ever expanding set of attributes for each object (type), because the differing views of the different applications (or users in a DB system), make use of different attribute sets.
a). The DM should facilitate such a 'subject-oriented' approach, and
b). we need a methodology for accounting for these views and attribute sets.
8.2 Subject / Object Problem
Although, this problem discusses the fundamental claim that objects map the real-world domain effectively, and would seem to be perhaps better placed under apparent naturalness - however due to its important significance (discussed further in chapters 4 and 5) we have treated it separately.
To illustrate this problem, consider the following scenario.
Scenario:
John: Can I have a drink please Barbara ?
Barbara: What drink, would you like John ?
John: I'd like some whisky in a tall glass, please.
Barbara: There you are John (after pouring the drink).
John: Thanks Barbara.
Implementing this scenario in the OOPar, would result in two object classes, which would send messages to each other, requesting the required services. For example, the glass would send a pour message to the bottle, etc. This is illustrated briefly below with classes in C++ notation.
(Scenario modified from presentation given by Smith(1996).
Class glass
{
public:
request_drink();
protected:
num size
....
}
Class whisky_bottle
{
public:
fill_glass();
protected:
int bottle_capacity
etc..
}
The implementation of scenario A in the above OO schema, leads to two important issues:
1. The claim that the OO model provides a natural reflection of the real-world, is not entirely correct.
For example, in the real world does the glass talk to the bottle, and vice-versa. Does the glass, "say bottle I want whisky in this glass"? No. - Although the use of language may seem flippant it highlights, that in the real-world objects do not pass messages to each other.
The degree of accuracy is left to the judgment of the reader - an ardent claim made by advocates of the OOPar (see chapter 2 & chapter 5).
2. Underlines the realist philosophical stance of the OOPar.
This issue is perhaps of a more fundamental importance. In the OOPar, the object is taken as the fundamental primitive of nature, therefore it de-emphasises the subject. Shell Netherlands reported problems (Kristen, 1996) using the OMT(Rumbaugh et al, 1991) OO method, because of this reason, i.e. the tendency to de-emphasise the subject. One of the major problems faced by Shell was communicating specification to users and defining user requirements. Shell, in fact changed to a different analysis approach (Kristen, 1994), based on user-language modeling, were at least more focus was placed on the subject.
These issues are discussed later in chapters 4, 5, and 6.
Key Issue:
40. Subjects as centres of action. The OO paradigm assumes it is objects that take action (methods and message passing) ; but in real life it is subjects that are the centres of action and meaning.
41. Subjects as centres of action 2. It is best to attach actions to 'objects' that represent actors in the real world, rather than attaching them for SL convenience. See 1 and 3.
KL-SL match. KL validity should override SL convenience.
9.1 Extensibility Issues
Advocates of the OOPar, frequently claim that the OO approach to software development allows software to be extended, and modified easily at later stages. We described this claim in chapter 2. However, what many OO proponents do not consider is that there are several different types of modification (of data structures), which are all equally important and needed in real-life.
A case study on the development of an OO CASE tool by Aoki(1992, 1993) - reported in Fischer et al, 1995) highlights some of the different types of modifications required in OO development, and the lack of support for these.
In the case study, the project team were engaged in developing MEI, an OO CASE tool, that supports various OO analysis approaches and notations, in the OOPL - Small-Talk80 (Goldberg & Robson, 1983). The project was carried out over a two year period by a large Japanese software house, and included 10 team members, with individual OO experience ranging from 1 - 10 years. The system included 700 object classes and 14,000 methods.
During the course of the project the team identified the following types of modifications required (reported in Fischer et al, 1995):
1. Refining existing classes.
2. Abstracting from existing classes.
3. Composing classes from existing components (aggregate objects).
4. Decomposing classes into new components.
Of the four modifications type identified, the project team found that only (1), and to a lesser degree (3) was effectively supported in Small-Talk80. However, no support was provided for (2) and (4).
Opdyke & Johnson(1989) - reported in Fischer et al), investigated some of the common changes required in the development of OO applications. They noted that, "object-oriented software is harder to change than it should be", this is because some changes require fundamentally "changing the abstractions embodied in existing classes object classes and relationships among those classes" (Opdyke & Johnson (1989), p.146).
Lubars et al(1992) - (reported in Fischer et al), also report some extensibility problems in the development of an object-oriented specification for an automated teller machine. They concluded that extensibility needs to be anticipated in advance and objects structured appropriately. Lubars et al(1992), however complain that current OO approaches rely on simple guidelines and strategies, they point out that "reliance on simple guidelines and strategies from methods textbooks may ...... cause the analyst to miss reuse opportunities and make the model more difficult to change." (Lubars et al, p.184 ).
Wolf(1992), also reports similar problems with maintaining relationships for newly added classes, in a OO CAD system.
Fischer et al (1995), suggest that inadequate support for the types of modifications required in software development, is perhaps due to a lack of understanding of the software evolution process. Fischer et al(1995) note, "..... current OO environments support evolution refinement but fall short in their support for many other evolutionary processes. There is a need for a better understanding of the processes involved in evolution and tools to better support these processes." p. 89.
Therefore, although OOPar, may provide better extensibility support than procedural languages, it does not go far enough, as some of the examples in this section highlight.
KEY ISSUE:
42. Sufficient support for extensibility is not provided. The types of extensibility/modifications required in software have not been adequately considered.
43. Extensibility. The DM should provide support for different types of extensibility required in real-life.
9.2 Object Orientation as a Communication Tool
One of the most oftly quoted benefit of the OOPar, is that the very use of domain vocabulary throughout the life-cycle of the project, results in enhanced communication within the design team and with the client(s). We described this claim in chapter 2.
This initially appears to be a valid claim. For example, in established domains such as accounting, production, etc - where a set of abstractions already exist, then it would be true to say that the OO model enhances understanding and communication flow. A wide range of case studies in the computing press have reported this benefit of the OOPar.
However, a recent study by Herbsleb et al (1995) shows that this claim, in the context of an ill-structured problem domain, is not entirely accurate. In the case study presented by Herbsleb et al (1995), the project team were engaged in designing a multimedia architecture. The project was unique, in the sense that very little previous work had been carried out in this area, i.e. no standard set of abstraction existed (unlike traditional application areas, such as accounting, production system, etc). The project team found that the very process of abstraction resulted in the creation of new concepts, i.e. forming new knowledge structures. Here the process of abstraction is more akin to knowledge formation, than knowledge representation. As Herbsleb et al(1995) aptly describe it, "...the design is not primarily an exercise in capturing domain knowledge but rather the extraordinarily difficult task of discovering the deep conceptual structure of this new, broadly defined domain." (p.287).
As a result of the ill-structured domain and creation of new knowledge (as opposed to abstracting existing concepts), one of the major problems reported in this study, faced by the team was communicating these concepts between the team and to the client(s). Even though, objects and relationships, and other OOA notation was used in analysis, clients found the concepts difficult to fully grasp and understand.
On trying to explain the communication difficulties (even though using OO), faced in the team, Herbsleb et al(1995) suggest that potential projects can be viewed on a continuum from pure knowledge capture to knowledge invention. This is depicted below:
(Knowledge) ________________________________ (Knowledge)
Capture Invention
They suggest that the numerous case studies supporting the "communication-benefit" of the OOPar are perhaps in the realms of the knowledge capture area. Herbsleb et al(1995) argue that in the context of an ill-structured problem area the claim of enhanced communication made by advocates of the OOPar are not entirely accurate. They conclude that "Toward the knowledge invention end of the scale, on the other hand, the risks will be high regardless of which method is used. Whether the arguments advanced in favor of OOD approaches have any basis at all in projects of this sort is unclear." (p.288).
Key Issues:
44. Communication. OO Model claim of enhancing communication, does not apply in ill-structured domains.
45. Methodology. The DM should provide some support for the communication process in ill-structured problem areas.
Part II
10. Case Studies
This section summarise the application of OO technology, in four manufacturing companies, highlighting observed advantages and limitations. The general structure adopted for each summary is as follows:
* The application of object oriented technology within a manufacturing scenario.
* Some of the observed advantages and disadvantages of OO
The summaries, of the case studies are based on the work carried out by Nof (1994), at the University of Purdue. For more detailed description of each scenario, the reader is directed to Nof(1994).
10.1 Company A
Company A, manufactures power-plant equipment, such as turbines, generators, motors, boilers, for electricity producing power plants. The case study presented in the article concentrates in the use of OO in the production control for the manufacture of steam turbine blades.
In Company A there are four production cells which carry out the above function (i.e. manufacture stream turbine blades). Each cell is equipped with the following:-
* 2 Milling Machines (MM) for machining of blade roots (RMM).
* 3 Milling Machines for blade profiles (PMM).
* 2 Intermediate inspection stations.
* and 1 coordinate measuring machine for (CMM) inspection of blade profiles.
The objective of the study was to design a cell controller for these blade cells.
The OO paradigm, applied in this case study resulted in the specification of object classes, such as robot_arm, blade_lot, inspection_station, cell_scheduler, and etc. Methods, for each respective class were also defined. The Smalltalk-80 programming language was used to develop this application, primarily because it enforces the OO paradigm. (During the design phase of the study message diagrams proved extremely useful, to show the relationships between items, hence method specification was made simpler).
One of the advantages noticed by the developers of this system was the 1:1 mapping between real world objects and those created in software. The cell_scheduler object class was at the core of the design, it would receive messages from other objects, and react by sending instructions to the appropriate object, for example the Lot_In message from the deliver object would result in Move_Lot message (with parameters) being sent to the Robot_Arm object.
By applying the OO paradigm the developers observed the following advantages:
Observed Advantages
1. 1:1 mapping between real-world and software objects.
2. Modularity of OOD, meant that the same control logic, hence control software could be applied in a another different cell - with little programming effort - (reusability).
3. The developers found that it was easy to divide the project. Once methods and object had been defined then little flow of information is required between the development team.
Observed Limitations
1. One of the major drawbacks of using OO in distributed production control was that there was no specific language support for such an application area, this resulted in problems with :
- a) coordination among hierarchies at different nodes.
- b) implementation of communication among different nodes.
The developers found that, the key area that needs to be addressed in the OOPar is message passing between objects that reside on different nodes. The use of Remote Procedure Calls (RPC) within OO is one way of overcoming this, but efficiency and processing factors need to be considered (particularly if real-time use is intended).
2. Most current OO languages, use dynamic binding at run-time, to select the method to be executed and to solve any type inconsistencies. However this results in extremely high run-time costs. If real-time control is required (which is normal, in most cases) then the processing power required, in terms of memory and speed at each node might be too high.
3. A key problem that OO languages have in this area is that no support for process synchronization is provided, namely semaphores and synchronization primitives like COBEGIN and COEND. Thus to implement process synchronization, classes for these concepts would have to be defined, along with a proprietary protocol.
Key Issues:
46. Integration of different knowledge bases. In a large multi-developer project, different class hierarchies will be generated, and these must be integrated (brought together) in an appropriate manner; the DM should offer facilities to do so. [Not just in OO hierarchies, but in knowledge bases e.g. inference nets, there is the problem of integration.]
47. Dynamic binding. Dynamic binding is too slow or resource-intensive for many of the activities that need to be carried out (esp. in real time computing). So DM should allow control of the degree of dynamicity in binding.
48. Concurrency 1. In many applications concurrent processes occur and need to be synchronized; the DM should provide mechanisms to synchronize the processes.
10.2 Company B
As part of radical change to its existing product line, decided to move from process-driven manufacturing environment to 20 autonomous cells, each dedicated to distinct sub-assemblies. Company B, also has a unique combination of cellular manufacturing and product line. Orders require a high-level of customization (up to 70% of orders), therefore flexibility is of the essence in design of the work cell. In order to increase the manufacturing flexibility of a cell the company, as a pilot project, the company decided to use an object oriented design approach for one of the cells.
One of the objectives of the proposed cell design was to maximise the flexibility inherent in the various CNC machine tools. The Object oriented design in specifying the work-cell, followed the technique for knowledge based support of OOA (Carver & Lee, 1991). One of the outcomes of this technique was specification of object classes laser-in-queue, monorail, laser-operator, laser-controller, sheet crane, etc. Parallel Objects (P/O - Corradi and Leornadi 1991) were defined so that logical conditions for object activation were met. For example, "upstream station is not allowed to produce a part unless downstream station has requested it", etc.
Observed Advantages:
1. The three main advantages observed in case 1 (i.e. Company A), were also found to hold in this instance.
Observed Limitations
1. However, a major challenge in this case study has been the modeling of complex concurrent functions.
P/O, Corradi and Leonardi (1991), was found to be useful in this respect.
2. The use of P/O has made the programming task extremely complex, the programmer has had to make sure that logical conflicts do not exist, specifically deadlocks, via a tedious verification process.
Key Issues:
49. Concurrency 2. Concurrency also requires explicit management in the DM in order to avoid things like deadlocks; the DM should handle these, not the modeller.
10.3 Company C - Inter-cell aerospace manufacturing with hierarchical control
Company C, manufactures 3 aerospace products. Each product is made of 3 sub-assemblies, totaling 25 component types. The company has 9 work cells, each of which can manufacture between 2-4 of these sub-assembly components. The goal of planning is to efficiently distribute tasks to each of the work cells. The key objective of this case study was therefore to develop hierarchical centralised control system, using an OO approach. The control structure for each work-cell controller is hierarchical and has been implemented using OO methods. The whole system was modeled using eight object classes and relationships between these classes. The modeled included task allocation, synchronisation, and communication functions.
In implementing this system the developers, observed the following advantages and limitations.
Observed Advantages
The advantages mentioned in the previous two case studies were also observed here.
Observed Limitations
The following limitations were observed:
1. Use of dynamic binding led to increased run-time costs. As a result, execution speeds were slower. This could lead to problems in effective real-time control on the shop floor.
2. Because of the centralised view of the hierarchical control strategy, the control logic specification suffered from the analyst, still thinking in a procedural way.
Key Issues:
50. Dynamic Binding (47).
10.4 Company D - Heterarchical FMS control with bidding
This case study focused on the production of a heterarchical, bidding based control of a flexible manufacturing system (FMS). The FMS, produces parts for small machined aircrafts. Over 900 components are produced by the FMS, in doing so it utilizes automated stores, local area network communications, and etc. Prior to deciding on an heterarchical control structure, a classical hierarchical control structure was used. However this imposed many limitations on production expansion, reconfiguration, reliability, etc. (and redundancy of the system).
The heterarchical bidding based control scheme for the system was implemented using the object-oriented C++ language. C++ was used, as it has some constructs useful in defining heterarchical behaviours. The control scheme, developed in C++ used two types of bidding protocols; the part initiated protocol and the machine initiated protocol.
In developing the control scheme, the developers observed the following advantages and limitations.
Observed Advantages
1 . Modeling and logic behind heterarchical system, are similar to those in OO programming in C++; each independent entity in the heterarchical system is like an object in the OOPar.
2. Polymorphism was found to be very useful in dynamically selecting appropriate member functions at run-time.
Observed Limitations
1. The volume of message passing between objects in the bidding process, results in a large overhead in terms of CPU processing.
Key Issues:
51. Message Passing. Message Passing is expensive in requires considerable resources.
10.4 Summary
This section, has described the application of the OOPar in four manufacturing companies. The observed advantages and disadvantage were also highlighted. The descriptions, necessarily have not been detailed, for further detailed description the reader is guided to Nof(1994).
11. Conclusion
This chapter has described and discussed many unresolved problems and issues in the OOPar. The issues and problems identified are presented in the form of a table below.
The Problems Brief Description
Problem Definition & Discovery OO is weak at defining problems in
ill-structured domains.
OO & Naturalness OO is not natural as many believe it
to be.
OO & Naturalness 2 Lack of conceptual model can result in
misuse and errors.
Multiple & Conflicting Views OO does not provide adequate support
for multiple views.
SQL Views As above.
Ad-hoc Queries No support for ad-hoc queries is
provided in pure OO model. Support for
this conflicts with encapsulation.
OIDs & Interacting with real world OIDs do not meaningfully interact with
real world.
OIDs & semantics in PART-OF No semantics attached to OIDs - thus
relationships weak entities view as equal.
Method Placement Problem Method placement is important in DBs -
not dealt with in OOPar.
OO & Human Cognition Assumption about human cognition in
OOPar are not as accurate as many
claim.
Viewing everything as objects Not appropriate in the DB domain.
View Support No view support in OOPar (that is
equivalent to relational views).
Lack of Formal Foundation Therefore S/L quality cannot be
checked.
Lack of Declarative Language No equivalent to SQL in the OOPar.
Class Hierarchy Conflict Current mechanisms are at the S/L need
K/L mechanism.
Uncertain Information Issue surrounding uncertain inform.
appears to be ignored.
Relationships Issues Weak support for relationships in
OOPar. Need K/L support for indirect
integrity.
Subjective View Problem Emphasis of objects can cause problems
in integrated app. suite - need
subject as well.
Subject-Object Issues Tendency to emphasise the object.
Shell Netherlands had difficulties
because of this.
Extensibility Issues Some types of extension need in
practice are not supported.
Communication Issues OO claim of enhanced comms. is not
true in ill-defined domains (Herbsleb
et al (1995).
Case Studies Highlight several bit level problems -
efficiency of message passing, cost of
dynamic binding, concurrency, and etc.
In the next chapter we consider attempted solutions to some of these problems.
References
Object Oriented Methods
23. Booch, G(1991). "Object-Oriented Design with Applications". The Benjamin/Cummings Publishing Company, Inc.
24. Booch, G(1994). "Object-Oriented Design with Applications". Second Edition - The Benjamin/Cummings Publishing Company, Inc.
25. Coad, P, Yourdan, E (1991). "Object-Oriented Analysis". Second Edition, Yourdan Press Computing Series, Prentice-Hall.
26. Coad, P, Yourdan, E (1991). "Object-Oriented Design". Yourdan Press Computing Series, Prentice-Hall.
27. de Champeaux, D, Lea, D, Faure, P(1993). "Object-oriented system development". Corporate and Professional Publishing Group, ISBN: 0-201-56355-X.
28. Matin & Oddell (1992). "Object-oriented analysis and design". Engle wood Cliffs, NJ, Prentice-Hall.
29. Meyer, B (1988). "Object Oriented Software Construction". Prentice Hall, International Series in Computer Science.
30. Rumbaugh, J, Blaha, M, Premerlani, W, Eddy, F, & Lorensen, W (1991). "Object-oriented modelling and design". Englewood Cliffs, NJ, Prentice-Hall.
31. Wirfs-Brock, R, Wilkerson, B, & Weiner L (1990). "Designing object-oriented software". Englewood Cliffs, NJ, Prentice-Hall.
32. Graham, I (1993). "Object Oriented Methods". Second Edition, Addison-Wesley. ISBN: 0-201-59371-8.
Other References
33. Aoki, A (1992). "The integration process in an object oriented programming environment". (Technical Report SEL-Boulder-92-1). Tokyo: Software Research Associates, Inc.
34. Aoki, A (1993). "Objecto shikou shisutemo bunseki sekkei nyuumon (Introduction to object-oriented analysis and design)". Tokyo: Software Research Associates, Inc, Japan.
35. Basden, A (1996). IT Notes on "Levels of Description". Contact Author, e-mail: A.Basden@iti.salford.ac.uk.
36. Basden, A (1993). "Appropriateness". In Bramer MA, Macintosh AL (eds.). "Research and Development in Expert Systems X". pp. 315-328, BHR Group Ltd.
37. Barsalou, L (1983). *
38. Brown, AW (1991). "Object-Oriented Databases: their applications to software engineering". McGraw-Hill International (UK) Limited. ISBN: 0-07-707247-2.
39. Carver, DL, Lee, S (1991). "Object-oriented analysis and specification: A knowledge base approach." Journal of Object Oriented Programming, January, pp. 35-43.
40. Cattrell, R (1991). "Object data management: object-oriented and extended relational database systems". Addison-Wesley.
41. Corradi, A, Leonardi, L (1991). "PO constraints as tools to synchronize active objects." Journal of Object Oriented Programming, October, pp 41 - 53.
42. Chadwick, D (1995). "Understanding X.500". Prentice-Hall.
43. Chen, PP (1976). "The entity-relationship model: toward a unified view of data". Jn: ACM TODS, Vol: 1, Issue: 1.
44. Cox, B (1991). "An evolutionary approach to object-oriented development". **
45. Codd, EF (1970). "A relational model of data for large shared data banks". Jn: CACM, Vol: 13, No: 6.0
46. Date, C (1995). "Introduction to Database Systems", Sixth Edition. Addison Wessley.
47. Detienne, F (1990). "Difficulties in designing with an object-oriented language: Am empirical study." Proc. of INTERACT, 1990, pp. 971 - 976. Elsvier Science Publishers B.V., North-Holland.
48. Deux, O et al (1990). "The Story of O2". Jn: IEEE Trans. on Knowledge & Data Engineering, Vol: 2, No: 1 (March, 1990).
49. Dittrich, K (1995). " Where Object-Oriented DBMSs Should Do Better: A Critique Based on Early Experiences." In "Modern Database Systems", Kim, W (eds), Addison Wesley, USA.
50. Fischer, G, Redmiles, D, Williams, L, Puhr GI, Aoki, A, and Nakakoji, K (1995). "Beyond Object-Oriented Technology: Where Current Approaches Fall Short." Jn: Human-Computer Interaction, 1995, Vol: 10, pp 79-119.
51. Goldberg, A, Robson, D (1983). "Smalltalk-80: The language and its implementation". Reading, MA: Addison-Wesley.
52. Herbseb, JD, Klein, H, Oslon, GM, Brunner, H, Oslon, JS, and Harding, J (1995). "Object-Oriented Analysis and Design in Software Project Teams." Jn: Human-Computer Interaction, Vol: 10, pp. 249-292.
53. Howitz, D (1992). "Bringing objects to mainstream MIS." Object Magazine, Vol: 2, No: 4 - Nov/Dec 1992.
54. Hughes, G (1993). "Object Oriented Databases". Prentice-Hall, Hemel Hampstead.
55. Hymes, C (1995). "Classification in the Object Oriented Paradigm from Cognitive Psychological Perspective: A Research Proposal.
56. http://www.csmil.umich.edu/~chymes/Professional/papers/OO/Dissertation/formal.html
57. Kim, W (1995). "Object-Oriented Database Systems: Promises, Reality, and Future." In "Modern Database Systems", Kim, W (eds), Addison Wesley, USA.
58. Kim, W (1991). ORION.
59. Kristen, GJHM (1994). "Object Orientation, The KISS-method, From Information Architecture to Information System". Addison Wesley, Wokingham, England.
60. Kristen, GJHM (1996). "Introduction of OO-methods in Shell Research". Unpublished paper.
61. Lewis, P (1993). "Information Systems Development". Pitman Publishing, London. ISBN 0273-03107-4.
62. Lecluse, C, Richard, P and Velez, F (1988). "O2, an object-oriented data model". Proc. Int. Conf. Mange. Data, Chicago, Illinois, USA.
63. Ling, TW (1985). "A normal form for entity-relationship diagrams". Proc. 4th Int. Conference : Entity-Relationship Approach, pp 24-35.
64. Ling, TW, Peo, TK (1993). "Towards Resolving the Inadequacies in Object Oriented Data Models". Jn: Information and Software Technology, Vol: 35, Issue: 5, pp.267-276.
65. Lubars, M, Meredith, G, Potts, C, & Rischter, C (1992). "Object-oriented analysis for evolving systems". Proc. of the 14th Int. Conference on Software Engineering, 173-185. Melbourne: ACM.
66. McFadden & Hoffer (1994). "Modern Database Management Systems". Addison Wesley.
67. McGinnes, S (1992). "How objective is object-oriented analysis?". Paper presented at the CAiSE 1992, 4th Conference on Advanced Information Systems, Manchester, UK, May 1992.
68. Medin, DL (1989). "Concepts and conceptual structure." Jn: American Psychologist, Vol 44, pp 1469-1481.
69. Murphy & Medin (1985). *
70. Nakamura (1985). *
71. Newell, A (1982). "The Knowledge Level". Jn: Artificial Intelligence, Vol :18 , Issue: 1, pp 87-127.
72. Newell, A (1993). "Reflections on the Knowledge Level". Jn: Artificial Intelligence, Vol:59, Issues: 1-2, pp 31-38.
73. Nof, S (1994). "Critiquing the Potential of OO in Manufacturing". Jn: International Journal of Computer Integrated Manufacturing, Vol: 7, Issue: 1, pp. 3-16.
74. OMG(1992). "Object Management Architecture Guide". Document 92.11.1, September, 1992.
75. Opdyke, W, Johnson, R (1989). Refactoring: An aid in designing application frameworks. Proc. of the Symposium on Object-Oriented Programming Emphasizing Practical Application, pp. 145-160. New York: ACM.
76. Polyani, M (1967). "The Tacit Dimension". Routledge and Kegan Paul.
77. Rosch, EM (1978). "Principles of categorization." In E. Rosch & B. Lloyd (Eds.), Cognition and categorization, (pp. 28 - 49). Hillsdale, NJ: Lawrence Erlbaum Associates.
78. Rosch, EM, Carolyn, CB, Gray, W, Johnson, D, Boyes-Braem, P (1976). "Basic objects in natural categories. Jn: Cognitive Psychology, Vol: 8, pp. 133-156.
79. Rosch, EM, Carolyn, B (1975). "Family resemblances: Studies in the internal structure of categories." Jn: Cognitive Psychology, Vol: 7, Issue: 4, pp. 573-605.
80. Smith, I (1996). "Sound Mind Projection using OO". Presentation at Staffordshire University, November, 1996.
81. Snoddgrass, R (1995). "Uncertain Information in OODBMS." In "Modern Database Systems: Beyond the OOM", Kim, W (ed.), Addison Wesley.
82. Scholtz, J, MacHaffe, S (1993). "Transfer to the Object-Oriented Paradigm by Procedure Programmers." Unpublished paper.
83. Smith, Shoben, and Rips (1989).*
84. The Committee for Advanced DBMS Function (1990). "Third generation database system manifesto". Memo No: UCB/ERL M90/28, University of California, Berkley (April, 1990).
85. Vessey, I, Cogner, S (1994). "Requirements Specification: Learning Object, Process, and Data Methodologies." Comms of the ACM, Vol: 37, Issue: 5, pp.102-113.
86. Harrison, W, Ossher, H (1993). "Subject Oriented Programming". In the Proc. OOPSLA, 1993, pp.411-428.
87. Wolf, W (1992). "Object-oriented Implementation Issues in an Experimental CAD system." Jn: Software-Practice And Experience, Vol: 22, Issue: 4, pp. 287-304.
88. Yourdan, E (1994). "Object-Oriented systems design: an integrated approach". Englewood-Cliffs, NJ, Prentice-Hall.
89. Zadeh, LA (1965). "Fuzzy stets." Jn: Information and Control, Vol: 8, pp. 338 - 352.
90. Greef, ND (1990). "Object-Oriented System Development". Msc Thesis, Department of Computer Science, University of Twente, The Netherlands, November 1990.
91. Offerins, M(1992). "Requirements for Building Intelligent Tutoring System". Memo, Department of Computer Science, University of Twente, The Netherlands.
92. Bempt, MVD (1991). "Construction of Hierarchies in Distributed Computer Systems". Msc Thesis, Department of Computer Science, University of Twente, The Netherlands.
93. Breunese, A(1992). "Design and Implementation of a Mechantronic Modelling Environment Using Object-Oriented Principles". Msc Thesis, Department of Computer Science, University of Twente, The Netherlands.
94. Aksit, M (1989). "Atomic Delegations" in "On the Design of the Object-Oriented Langauge Sina". Ph.d Dissertation, Chapter 4, Department of Computer Science, University of Twente, The Netherlands.
(*) - Pending reference details.
Chapter 4
1. Introduction
In this chapter we list some solutions proposed to some of the problems identified in chapter 3. This chapter also highlights, a key problem in the general solutions proposed, that is they take a narrow perspective in solving the overall problem. The solutions proposed by the respective authors, we believe deal with the symptoms of the problem - rather than addressing the core problem itself.
The main thrust of this chapter, is then not really what are the solutions, but rather what we should be asking is, why are the problems there in the first place? Taking a solutions perspective, is really dealing with the symptoms of some higher main problem. The author argues that we need to deal with the problem not its symptoms.
The structure of this chapter is thus:
Firstly, a brief description is provided to solutions (where they exist) of some of the problems outlined in chapter 3. Secondly, we discuss the key problems with the solutions outlined. We then suggest a different approach, that addresses the key problem(s), which is discussed here and provides the necessary background for the next chapter.
2.0 The Problems Identified
Problems
Problem Discovery & Definition
Apparent Naturalness
Multiple Views & Conflicting Views
SQL Views
Primary Key
Ad-hoc Query
Declarative Query Language
Method Placement
Subject/Object Problem
Subjective-View Problem
Class Hierarchy Conflict
Viewing Everything As Objects
Support for Relationships
Problem of Symmetry
View Support
Lack of Formal Foundation
OO Model & Human Cognition
Uncertain Information
Communication Tool
Extensibility Issues
Case Studies
OO in Manufacturing
- 4 Case Studies
OO in CAD
Table 1 - Summary List of Problems Identified in Chapter 3
2. The Solutions
Some of the above problems have been recognised as such by the OO community and solutions have been proposed:
2.1 Primary Key Problems
This problem, can be relatively easily supported in the OO model, however a lack of understanding surrounding its K/L issues, has resulted in this area not being considered as problematic. The author, recommends the wide support of the concept of keys (as used in the R/M), and for it to be widely accepted and supported in the OO model.
2.2 Ad-hoc query
There is no standard solution for this problem, that does not break the notion of encapsulation (that is central to the OOPar). Date(1995), and Darwin & Date (1993), recommend having a security layer, so that attributes can be directly accessed, subject to an authorization scheme (instead of encapsulation - where only pre-defined methods are allowed to access attributes), which would seem to be more appropriate in the context of a database system (see Date 95; The Third Database Manifesto(1993) - for further discussion).
2.3 Declarative Query Language
There have been several proposals made for a declarative query language for OODBMS, for example Abiteboul(1989), Kim(1989), Beech(1988), etc. However none of these match the features offered by SQL in the relational model, and Ling argues, are yet "still at a preliminary stage". (Ling, 1993, p.268).
2.4 View Support
Many published papers propose approaches for incorporating view support in OODBMSs, see Kung(1990), Abiteboul(1991), Hailpern(1990), and Shilling(1989), for example. However, Ling(1993), argues that none of the proposals provide the same flexibility of a declarative relational view mechanism.
2.5 Support for Relationships.
Cattrell(1991), suggest the use of special relationship type classes to overcome some of the problems in handling relationships in the OO model. However neither of these fulfill the requirement specified in key issues 34-36 in chapter 3 (i.e. no explicit support for M:N is provided - two 1:Ns are used). The symmetry found in relationships (e.g. "contains" = "contained by") is not recognised. Furthermore, arity is assumed to be two so that modeling ternary or higher relationships are difficult.
2.6 Viewing everything as Object
There have been several ways (refs***) that have been proposed and implemented to overcome these problems. The requirement of the pure OO model to view everything in terms of objects has had to be discarded, for modified models which also support the notion of attributes.
2.8 Subjective View Problem
This area has had very little research attention. Harrison & Ossher(1993), suggests a possible solution to this problem, however there recommendations although a stepping stone, has not been widely (non known to this author) incorporated in the OO community.
2.9 Lack of Formal Foundation
Ling et al (1993) propose an ER based approach to defining the conceptual schema of OO data models. This, potentially allows the use of normalisation and data dependency theories, hence symbolic quality of data can be judged. However this approach has not been widely, if at all, adopted in the OO community.
2.10 Class Hierarchy Conflict
Ling et al (1993), propose a partial algorithm based solution to this problem. Although, it is not purely at the knowledge level, it provides better support than that offered in current OO models. However, pure knowledge level support needs to be provided to fully address this issue.
Problems without Solutions
Apparent Naturalness
Multiple Views & Conflicting Views
OO Model & Human Cognition
Communication Tool
Uncertain Information
Subject-Object Problem
Extensibility Issues
Support for Indirect Integrity
Other Relationship Types
Problem Discovery & Definition
Method Placement
No solutions have been proposed for the above issues from within the OO community (not known to this author). Although it may be possible to deal with some of these, they are largely ignored and not viewed as a problem. This is perhaps due to the philosophical presupposition of the OOPar, which is discussed in the next section.
3. Discussion of Solutions
From the above problems, we can see that there is a wide diversity and range of issues. Most of these seem not to be admitted to by the OO community. The solutions, proposed by each respective author, we believe adopts a symptomatic approach , that is they deal with the symptoms of the problem - rather than the core problem itself. These solutions, in actual fact, are really of very little interest to us. The question we should be posing is not 'What are the problems and how do we overcome them', but rather 'Why do they occur, i.e. what is the root cause?' We will then be in a position to ask 'what steps do we need to take to solve it?' It i