CORD an Object Model supporting Statistical Summary Information for Management Decision Mak

CORD an Object Model

supporting Statistical Summary Information for Management Decision Making

PAUL ANTHONY GOLDER

Doctor of Philosophy

ASTON UNIVERSITY

October 1997

This copy of the thesis has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the thesis and no information derived from it may be published without proper acknowledgement.

-1-

Summary

Aston University

CORD an Object Model

supporting Statistical Summary Information for Management Decision Making

PAUL ANTHONY GOLDER

Doctor of Philosophy

1997

Information systems have developed to the stage that there is plenty of data available in most organisations but there are still major problems in turning that data into information for management decision making. This thesis argues that the link between decision support information and transaction processing data should be through a common object model which reflects the real world of the organisation and encompasses the artefacts of the information system. The CORD (Collections, Objects, Roles and Domains) model is developed which is richer in appropriate modelling abstractions than current Object Models. A flexible Object Prototyping tool based on a Semantic Data Storage Manager has been developed which enables a variety of models to be stored and experimented with. A statistical summary table model COST (Collections of Objects Statistical Table) has been developed within CORD and is shown to be adequate to meet the modelling needs of Decision Support and Executive Information Systems. The COST model is supported by an statistical table creator and editor COSTed which is also built on top of the Object Prototyper and uses the CORD model to manage its metadata. Keywords

Object modelling; Statistical Summary Tables; Statistical Metadata; Management Information; Decision Support; Object Database Management.

-2-

Acknowledgements

My thanks to Vivienne for inspiration, encouragement,

support and a lot of checking.

Copyright

The author acknowledges the rights of the following companies to the products referred to in the text

Microsoft Corporation : Visual Basic, MS Access, Excel

Oracle Corporation : Oracle, SQL*Forms

Seagate Software Information Management Group : Crystal Reports

-3-

List of Contents

CORD an Object Model

supporting Statistical Summary Information

for Management Decision Making

Paul Anthony Golder

Title Page (1)

Summary (2)

Acknowledgements (3)

List of Contents (4)

List of Figures (5)

List of Tables (9)

Chapter 1 Information from Data (10)

Section A Conceptual Modelling and the CORD model (24)

Chapter 2 The Nature of Data (28)

Chapter 3 Objects and Classes (44)

Chapter 4 Modelling the Dynamics of Objects (58)

Chapter 5 Entities and Roles (68)

Chapter 6 Relationships and other Associations (91)

Chapter 7 The CORD Model (108)

Chapter 8 The Object Prototyper (130)

Section B From Data to Management Information (150)

Chapter 9 Modelling the information system (155)

Chapter 10 Statistical Summaries (167)

Chapter 11 The Collections of Objects Summary Table Model (196)

Chapter 12 Structural Summaries (214)

Chapter 13 The Presentation Model (226)

Chapter 14 Implementing the COST Models (241)

Chapter 15 Conclusions (261)

References (274)

Appendix 1 CORD model (280)

Appendix 2 COST model (286)

Appendix 3 Test models (287)

Appendix 4 The initial triples (292)

Appendix 5 Examples of COST models (294)

-4-

List of Figures Continued

Figure 1.1The various domains implicit in the research (16)

Figure 1.2Matching model to problem domain (21)

Figure 2.1Levels of data abstraction (30)

Figure 2.2 A record and three sentences derived from it (33)

Figure 2.3Dimensions and scales of measurement (35)

Figure 2.4Approximate relationships between data forms (38)

Figure 2.5 A conventional E-R model (39)

Figure 2.6An instantiation of figure 2.5 (40)

Figure 2.7Representing Attributes in OOA (41)

Figure 2.8Attributes and an instance in OMT (42)

Figure 3.1Different levels of abstraction (44)

Figure 3.2Nested domains of discourse (45)

Figure 3.3 A variety of relationships (47)

Figure 3.4Two generalisation constructs (49)

Figure 3.5An aggregation hierarchy (49)

Figure 3.6Representing Classes and Objects in OOA (53)

Figure 3.7OMT notation for classes and objects (54)

Figure 3.8 A class and object with attribute values (54)

Figure 3.9Links and associations (55)

Figure 3.10Generalisation / specialisation structures (55)

Figure 3.11Whole part structures (56)

Figure 4.1Actions, Events and Processes (58)

Figure 4.2State diagram (after Rumbaugh) (63)

Figure 4.3Library member model (after Jackson) (65)

Figure 4.4Examples of Entity Life Histories (65)

Figure 5.1Subtypes and Roles (71)

Figure 5.2An ORD - Union Membership as a Role (72)

Figure 5.3Not an ORD - Union Membership in a Closed Shop (73)

Figure 5.4 A sub role (73)

Figure 5.5Concurrent Roles (74)

Figure 5.6Mutually exclusive roles (74)

Figure 5.7 A sequence of roles (75)

Figure 5.8The missing roles (76)

Figure 5.9Roles replacing transitions (76)

Figure 5.10More accurate representation of advanced first aiders (77)

-5-

List of Figures Continued

Figure 5.11An E-R model of a relationship (77)

Figure 5.12The Object Role diagram for Figure 5.11 (78)

Figure 5.13Cardinality of Roles (79)

Figure 5.14Required Occurrence of Roles (80)

Figure 5.15 A complex Entity Life History (81)

Figure 5.16Three simpler ELHs (81)

Figure 5.17States and roles (82)

Figure 5.18Specialisations of natural kinds and roles (83)

Figure 5.19Figure 5.1 reprised (84)

Figure 5.20 A specialisation of Research Project (85)

Figure 5.21Two different ELHs completely defined (85)

Figure 5.22Only the different activity is defined (86)

Figure 5.23Life Histories and Roles (Figure 5.16 reprised) (87)

Figure 6.1Cardinality of relationships with role names (92)

Figure 6.2 A required relationship (93)

Figure 6.3An alternative representation (93)

Figure 6.4Several different relationships (93)

Figure 6.5Binary relationship modelling (94)

Figure 6.6Instance connections in OOA (95)

Figure 6.7Links and associations in OMT (95)

Figure 6.8Association showing Roles (96)

Figure 6.9 A Part_ Of association (OMT) (96)

Figure 6.10Whole Part Structures (97)

Figure 6.11Conceptual modelling of the implementation (99)

Figure 6.12E-R model with a classification entity (99)

Figure 6.13Description of a class (100)

Figure 6.14An instance of the class in Figure 6.13 (101)

Figure 6.15Two different DoDs (101)

Figure 6.16References and domains (105)

Figure 7.1An Object Class (112)

Figure 7.2Specialisations (112)

Figure 7.3Role (118)

Figure 7.4Distinct class model (123)

Figure 7.5Mule model (124)

Figure 7.6Synchronisation model (124)

Figure 7.7Partnership model (124)

Figure 7.8Main elements and relationships in the CORD model (128)

-6-

List of Figures Continued

Figure 8.1Main Screen Menu (142)

Figure 8.2The Loader Screen (143)

Figure 8.3The OQL form (144)

Figure 8.4The Object Tree (145)

Figure 8.5The Browser (146)

Figure 8.6Print form (146)

Figure 9.1Nested levels of modelling (155)

Figure 9.2 A screen form (160)

Figure 9.3Typical MIS report (161)

Figure 9.4Model of form architecture after Adiba and Collet (162)

Figure 9.5Mapping the organisation to the paradigms (163)

Figure 9.6Alternative Presentation of Report (164)

Figure 9.7Instantiation of forms (165)

Figure 10.1Membership association (168)

Figure 10.2Entity Types (168)

Figure 10.3Generic Types (169)

Figure 10.4Relationship types (170)

Figure 10.5Composition Types (170)

Figure 10.6Composition to create a class of objects (171)

Figure 10.7Crossproduct (171)

Figure 10.8 A summary type (171)

Figure 10.9Confusing data model (174)

Figure 10.10Relationships between classes, collections and instances (175)

Figure 10.11Domain Hierarchy (180)

Figure 10.12 A STORM Model (Rafanelli & Shoshani) (184)

Figure 10.13Elements of a summary table management system (187)

Figure 11. 1The COST and CORD models in context (197)

Figure 12. 1An inhertitance hierarchy (216)

Figure 12. 2Part_ Of hierarchy (219)

Figure 12. 3 A relationship (219)

Figure 12. 4 A role model (222)

Figure 13.1 A 3 dimensional dataset (227)

Figure 13.2Flattening a hypercube into views (227)

Figure 13.3Collecting slices into views (228)

-7-

List of Figures Continued

Figure 13.4All dimensions of a dataset in a view (228)

Figure 13.5Nesting dimensions in a view (228)

Figure 13.6 A category tree (229)

Figure 13.7 A view of a three dimensional slice of a dataset (230)

Figure 13.8 A view of a partial four dimensional slice of a dataset (230)

Figure 13.9An example of the Star+ notation (231)

Figure 13.10Star+ notation for figure 13.8 (231)

Figure 13.11Two compatible tables (238)

Figure 13.12Concatenated table (238)

Figure 13.13COST-Table and COST-View in Context (239)

Figure 14. 1Different meanings of "Domain" in the CORD model (246)

Figure 14. 2The COSTed main screen (258)

Figure 14. 3Table editor screen (259)

Figure 14. 4The View editor (260)

-8-

List of Tables

Table 2.1Relationships between semantic concepts (33)

Table 2.2Common data representations (37)

Table 8.1Samples of triples as stored in the dataabse (136)

Table 10.1SAM* concepts ..............................................................................

compared with traditional data modelling concepts (172)

Table 10.2Mapping Summary table to Relational table (188)

Table 10.3 A statistical table (191)

Table 10.4Employee Analysis: a 4 dimensional statistical table (192)

Table 10.5Underlying data table (192)

Table 10.6Two compatible tables (193)

Table 10.7Concatenated table (194)

Table 11.1Characteristics of members of a collection (200)

Table 12. 1Summary and Category attributes and inheritance (218)

Table 12. 2Summary and Category attributes from aggregations (221)

Table 12. 3Summary and Category attributes from roles (223)

-9-

Chapter 1

Information from Data

1.1. MOTIVATION FOR THE RESEARCH

The motivation for this research arose from a series of events and experiences which are useful to recount as they help to justify the research and to establish the problem which the research addresses.

A research student of mine, Kevin Lawson (1987), examined some of the requirements for intelligent statistical packages, and in particular focused his attention on the nature of variables and the appropriateness of particular statistical operations on them. It became apparent that, for this work to be useful in real world information systems as distinct from the structured world of statistical analysis, there was a bridge to be built which would enable the metadata implicit in an information system to inform any system attempting to carry out statistical analysis on the data held in the information system.

A consultancy project for Aston Business School concerned the development of an Executive Information System to facilitate access to summary information about the strategy and operations of the Business School. The project was only partially successful because, although it was relatively straightforward to build a vehicle for delivering executive information, it emerged that the most laborious task was the definition of the data and summaries to be presented. In many cases the data was already available in a computerised form but without the necessary metadata to enable summaries to be generated without considerable effort.

Another consultancy project for a small company encountered similar problems in that there were several computerised operational systems in place and more being introduced, but it was very difficult for the Managing Director to extract management information triggering the complaint "I have all the data but no information".

-10-

Chapter 1Information from Data

1.2. THE PROBLEM

The decision maker in an organisation has a very simple requirement: s/he needs access to the right information at the right time. Despite 40 years of computer support for business activities and great progress in the power of hardware and the quality of software, most decision makers are still frustrated by their inability to satisfy this need. This is all the more surprising when the abilities of modern computing systems to manage, to transmit, to locate and to reproduce vast quantities of business data are well known. Many decision makers will have access to a personal computer which may well be networked to the corporate data-server. Nevertheless it is not a simple task to obtain the right information at the right time.

The user attempting to access organisational data will find that the information system appears to "know" little or nothing about the organisation and the way it operates. The user has to repeatedly restate basic facts such as that Accounts is a Department, that Departments have Managers and that Managers have Names. Thus a simple SQL query could have the form:

SELECT manager. n ame FROM department, manager

WHERE department. n ame = "Accounts"

AND department. m anager_ i d = manager. m anager_ i d;

It is clear that current systems do not contain (or are unable to access) knowledge about the structure of the organisation which they support.

The distinction between data and information has been made by many authors and the problem can be seen as a simple issue, "Why when we have so much data easily accessible in most organisations is it so hard to find the appropriate information?". The existence of this problem, first discussed by Ackoff (1967), is well known and although there is an abundance of partial solutions on offer, no evidently satisfactory comprehensive approach has been reported.

This author will argue that the heart of the problem lies in the mapping of the detailed data which is generated by the activities of the organisation to the models of the organisation which underpin the decision maker's approach to his/her tasks. It will be argued that this mapping is not well supported by current design

-11-

Chapter 1Information from Data

methodologies or by current decision support systems and tools for creating them. Finally this thesis will propose a set of tools and methods for reducing the mismatch.

1.3. THE REFERENCE DISCIPLINES

The problem outlined above is situated within the domain of research conventionally referred to as Information Systems; however as Robert Blanning et al (1995) quote in their introduction to a recent special issue of Decision Support Systems, "The reference discipline of (information systems) is computer science, or experimental social psychology, or alas the International Case Clearing House". In the same issue, Stuart Madnick (1995) in his paper "Integration technology: The reinvention of the linkage between information systems and computer science" identifies what he sees as the directions in which information systems research should go. Resisting the temptation to digress into applications of information in management, such as marketing and strategy, he suggests as examples of key integration technology research issues: "data semantics acquisition", "data quality", and "evolving semantics", suggesting that in addressing these sorts of issues the discipline will be addressing key business problems. In particular he observes that an "organisation can be simultaneously 'data rich' and 'information poor' if they do not know how to identify, categorise, summarise and organise the data". The author supports this argument and observes that the issues explored in this research fall clearly into the domain of "integration technology" as identified by Madnick and thus have as reference disciplines computer science and information systems. In particular, the construction of databases, the design of information systems, the creation of decision support systems and the specification of statistical summaries are of concern to this work and material from all these areas is brought together in this thesis.

1.4. CURRENT APPROACHES TO THE PROBLEM

The problem outlined is well documented and many authors are engaged in research which addresses it. As always researchers bring their own specialism to

-12-

Chapter 1Information from Data

bear on any problem and the different approaches derive from existing schools of research in computer science. Two main themes can be identified under which research into the wider area of this problem domain is currently being carried out.

The engineering approach, which focuses on the system design process, is concerned with successful elicitation of requirements and construction of robust systems to meet these requirements. The tools being developed by this approach are those of Computer Aided Systems Engineering (CASE), formal methods, and more recently Object Oriented Analysis and Design. These methods acquire and build models of the organisational structure, and these knowledge bases inform the design process and may be significant in the maintenance and evolution of the applications. Nevertheless the knowledge is embedded in the design is implicit rather than explicit, and is not generally available to the user. Thus this approach, whilst valuable for the construction of many applications, is not directly applicable to the construction of decision support systems where the user wishes to address and model ad-hoc problems.

Another approach is the application of artificial intelligence. Given an "unintelligent" information system the aim is to facilitate the user's access. An expert system front end can incorporate the knowledge of an expert user and can deduce user's intentions. Alternatively a natural language interface can achieve the same results. Both approaches require encoding of the organisational knowledge in an appropriate form. This knowledge is then accessed by an inference engine which draws conclusions about the request being submitted.

Both approaches suffer from the same shortcoming, which is that they both separate data structure from organisational knowledge. Thus they treat the fact that "customer X has an overdrawn credit account" in a completely different way to the fact that "a customer providing evidence of credit worthiness may be granted credit account facility". Applications based on these approaches will inevitably mean that the user has to navigate two different systems. The seamlessness of this navigation from the user's point of view will depend on the quality of the user interface and will therefore be application dependent.

-13-

Chapter 1Information from Data

1.5. THE RESEARCH DOMAIN

From these experiences, and many similar examples encountered in teaching and consulting across the spectrum of statistical analysis, decision support systems, management information and information systems design, a solution domain emerged.

To tackle the problem it will be necessary to exploit and integrate several current research directions. Current approaches to organisational modelling will be assessed. OOA is an obvious candidate together with the work on data modelling inherent in Object Oriented database development. The gap between operational data and information for decision making is similar to the work on statistical databases and statistical data modelling, so this literature will be relevant as will current work in the design and construction of Decision Support Systems.

1.5.1 Conceptual modelling

First, it became clear that the problem area was not at the implementation level. That is, it was not concerned with how statistical packages operate nor how data is stored in databases, but how knowledge about these two fields is managed and exploited. To characterise current practice, a model is constructed when an information system is designed and built, and this is then lost or forgotten once the system becomes operational. But the operational system cannot tell the user much about the world it serves, and to understand the operational system, particularly why things happen the way they do, requires reference to external documentation, or usually discussion with members of the original project team. Thus when a user wishes to produce management information, summaries and aggregates; let alone more sophisticated forecasts, they have to provide a lot of extra information to make this possible and in particular, knowledge about the types of variables and about their domains. This information is typically referred to as metadata within the statistical community, but is identical in nature to the conceptual models of the information systems community.

-14-

Chapter 1Information from Data

A major theme of this research is the construction of appropriate models to represent the problems being addressed by the development of an information system. The accepted terminology for high level abstract models which the developer uses to communicate with the problem owner is conceptual models and the process of deriving such a model is called conceptual modelling. The consideration of different approaches to conceptual modelling means the discussion of different frameworks for achieving a conceptual model. Logically one should refer to such as a conceptual modelling framework, toolkit or method however this is clumsy and we will follow convention and talk about a conceptual model when it is wished to refer to the method and not just the instantiation of a particular modelling approach.

1.5.2 Domains of discourse

It also became clear early in the research that there are several different areas to this study which many researchers have inadequately differentiated. A conceptual model is traditionally presented as a model of the real world or at least the part of the real world of interest to the organisation, commonly referred to as the Domain of Discourse or Universe of Discourse (UoD). However there are several other domains which need to be crossed in creating a path between the decision maker and the information they require. These are illustrated in figure 1.1. There is the information system itself, an analogue hopefully of the real world, but often we do not distinguish between them and will refer to customer when we mean a customer's record. The author was once told by an enquiry clerk at Paris Charles de Gaulle that the plane he had arrived on had not yet landed. It took some persuasion that landed it had, but the information system had not been appraised of the fact. Within the information system there are other domains all of which contain representations of the real world: there are logical data models and flow charts and binary information stored on disc. These do not directly interest us but often confusion can arise when for example we are told that the department to which an employee is assigned is a character string with a maximum of 20 characters. Somewhere else in the world of interest there will be a manager with a

-15-

Chapter 1Information from Data -16-problem. The term problem domain is used for any representation of the complex interactions, variables and objectives that make up the problem. There will also be a domain in which information is presented, structured in a manner pertinent to the problem domain. The language of this domain will be one of statistical summaries and management reporting: breakdowns, averages, totals etc.

Figure 1. 1 : The various domains implicit in the research

1.5.3 Object orientation

It also became clear that any new approach to this area would have to draw on recent work in object oriented analysis and design. It was going to be necessary to create richer conceptual models which were capable of expressing not only the structure of the real world but also the content of the information systems and the structure of the statistical summaries describing them. It was expected that merely extending conventional modelling tools such as the E-R model would not be a

satisfactory way of describing the different domains to be spanned. The richness of an object model was likely to be needed and the discipline of the object oriented approach would be essential for controlling the complexity in the overall model.

1.6. WHAT IS AN INFORMATION SYSTEM?

Whilst there is a lot of discussion about the nature and construction of information systems, there is relatively little work which discusses the purpose, not of an

Chapter 1Information from Data

individual system but of information systems in general. The work of Stafford Beer (1979) and the cybernetic fraternity has given us a useful way of looking at the role of information systems in organisations. Information is what flows in control loops which are central to the survival of any self regulating system. Although the cybernetic model has its critics it is useful for us to take on a key proposition: that is that the control system needs to contain a model of the system being controlled. It follows that if an organisation’s information system has this control function it must contain or at least be in conversation with a model of the organisation. This is not very different from the idea of van Gigch and

Le Moigne (1990) that the identity of an organisation is held in its memory, and that the information system is the organisational memory.

However, the development of information systems has never seemed to realise their promise, and although to some extent this may reflect over optimistic promotion of "business solutions", there is also reason to believe that there are many problems inherent in the development of such systems.

The literature on the failure of conventional approaches to the development of information systems starts with Ackoff's paper (1967) “Management Misinformation Systems”. Ackoff argues that there are basic misconceptions about information systems that contribute to their lack of success.

Give them more is the view that managers need more information to enable them to make adequate decisions. The counter position is that in fact managers suffer from an information overload and that a minimum set of information should be provided to support the decision process in question. The tendency to provide too much irrelevant information results from a lack of understanding of the problem and the decision process appropriate to its resolution. The growth of large corporate databases has made it easier to provide too much information, although the considerable improvement in quality of user interfaces to database systems may help the decision maker to be more selective in extracting relevant information.

The manager does not need to understand the information system. This view

-17-

Chapter 1Information from Data

ignores the reality of the decision making process. It is usual for a decision maker when faced with information to want to know how it was assembled, and this is particularly true of condensed information which is far removed from the original elementary data. This need to understand the process reflects the need to establish confidence in the information prior to basing a decision on it. The user needs to understand the process at a conceptual level. It is not the intricacies of the database and its associated physical storage but the logical operations in deriving the figures presented which the user needs to understand.

The wider the view of the organisation the better. This position assumes that if managers have access to information about the rest of the organisation, they will be able to take better decisions. Ackoff argued that such information may easily be misinterpreted by someone not involved in its derivation, and may thus have deleterious consequences on the decisions being made. Ackoff was arguing for a very hierarchical approach to management which may in part have its origins in the management culture of the time and the technology of the late sixties. Whilst the danger of misusing information is a real one, the danger of taking decisions based on a myopic view of the current situation is also real. It is likely that current thinking would stress the communication of situation reports between parts of the organisation, so that any decision maker could inform him/herself of the wider context of their current problem. There is a considerable difference between encouraging someone to look at the notes and discussion documents of another and keeping colleagues informed about objective changes and approved policies.

Data makes decisions. This position suggests that information necessarily contributes to improved decision making. Ackoff argued that without understanding the decision process and identifying the appropriate information required by it, it is not automatic that merely providing more (irrelevant) information will aid the making of the decision.

Although written thirty years ago Ackoff's critique is still appropriate today. Madnick in 1995 still considers it relevant to repeat the familiar adage that data richness and information poverty remains with us and this despite the substantial

-18-

Chapter 1Information from Data

growth in power of hardware and usability of software over the last 30 years. The matching of problem domain to information clearly remains a challenge.

1.7. THE THESIS

This author will argue that the heart of the problem lies in the mapping of the detailed data which is generated by the activities of the organisation to the models of the organisation which underpin the decision maker's approach to his/her tasks. It will be argued that this mapping is not well supported by current design methodologies or by current decision support systems and tools for creating them (see figure 1.1). This research makes several contributions to the solution of this problem:

? A review of existing conceptual modelling frameworks and, in particular, the modelling of behaviour, leads to the proposed CORD (Collections, Objects, Roles and Domains) Model.

? A conceptual model which cannot usefully be implemented or exploited is of limited value. The Object Prototyper has been developed which is a tool for managing object models and is the basis for both developing and testing the usability of the CORD model.

? A review of the literature on management reporting and statistical summary tables identifies the essential features of management reports. The literature reflects a confusion between the logical and the presentation issues, so a

conceptual model is developed, the COST (Collections of Objects Summary Tables) model, which separates these two levels of abstraction.

? The COST-table and COST-view models are both defined within the COST framework and a software tool is constructed, COSTed, which enables tables and views to be defined using a wimp interface, as well as the definition

language of the COST model.

These improvements in conceptual modelling, the definition of management

-19-

Chapter 1Information from Data

summaries, and the integration of a management summary into a standard object model, are all major contributions of this thesis.

1.8. TESTING OF THE THESIS

In developing and testing conceptual models it is not appropriate to consider proving something to be true or false ,or even to hope to discover something. The natural focus of the research in this area is that of generating descriptors of a view of a section of the real world, but in accepting that the information system of the organisation is also part of the real world, this language of description also needs to be able to describe the IS. The section of the real world under discussion is that of management information systems. This is much narrower than all computer systems, and the techniques explored and proposed are unlikely to be relevant to command and control systems, or network management systems, or a large number of other applications of computing. The justification for focusing on such a restricted area is its significant economic importance as represented by the number of people employed in it. The other justification is that the interface between technical specialist and non technical users and clients is much more significant in this area than in the specification of a highly technical application.

Every specialist area has its own language for describing it, and the fact that some of these languages use very familiar terms does not make them less technical than a language structured entirely in a mathematical symbolism. This research aims to develop a language and to test this language. How can it be tested and what would constitute a validation of the work? In the review many such languages are encountered, each developed to solve a perceived problem with the (then) current state of conceptual modelling. There is an evident tension between semantically rich descriptions with a large number of different constructs which are not always easy to match to the real world, and semantically poor languages with a few constructs which mean that the modeller needs a lot of supplementary information to help understand the model.

Although it seems to have received little discussion, the implication is that there is

-20-

Chapter 1Information from Data

an ideal modelling language which is not too poor to be able to represent the richness of a real world domain nor too rich to make the modelling process impossibly complex (figure 1.2). The author suspects that there is not such a language. The suitability depends not only on the richness and structure of the language but on the complexity of the real world domain, and the purpose of the modelling, and the experience of the players in the modelling process - the modeller and the user / client - will also moderate the success of a particular approach to conceptual modelling.

Difficulty

of

modeling

the DoD

Richness of the data modeling schema

Figure 1. 2 : Matching model to problem domain

It would be a very poor modelling method which could not be shown to be superior to all others for a particular problem description. Unfortunately, because of the high dimensionality of the real world, the success of problem domain modelling languages is not transitive and it does not follow that because A has been shown to be superior to B and B superior to C that A is any advance on C.

How then is it proposed to test the models developed in this thesis? The main requirement is consistency: that is, the language should be applicable in a consistent way without arbitrary treatment of particular situations. The language should be robust: that is, it should apply to situations for which it was not specifically intended. Thirdly the language should be parsimonious: that is, it should contain the minimum of constructs necessary to describe the domains for which it is intended. In this particular case robustness is of the essence, as it is intended to develop a modelling language which will not only represent in a satisfactory way the section of the real world being modelled, but also permit the

-21-

本文来源：https://www.bwwdw.com/article/uk3q.html