Validating conceptual models – utilising analysis patterns as an instrument for explanation generation

Maria Bergholtz, Paul Johannesson

Department of Computer and Systems Sciences

Stockholm University and the Royal Institute of Technology

Electrum 230, S-164 40 Kista, Sweden

Email: {maria, pajo}@dsv.su.se

Abstract. In this paper we outline an architecture and design principles to support the validation of conceptual models by generation of explanations in natural language. The architecture utilises the concept of analysis patterns as a context for explaining implicit dependencies between different parts of the model. In addition Toulmin’s argumentation model is used to structure the interaction between user and system. We argue that this architecture assists in building explanation generation systems that are highly interactive and provide an adequate amount of information for different user categories.

1 Introduction

The main challenge in systems development is that of building the right system – one that meets the user needs at a reasonable cost. The key to achieving this goal lies in the early stages of systems development, i. e. in the analysis and representation of the requirements of the system to be built. It is essential that the constructed model of the system correctly represents the piece of reality under consideration and the user’s requirements. The process of ensuring that a model possesses these qualities is called validation.

Validation is often an informal process where the different stakeholders participate, including people with limited knowledge of modelling and systems design. However, people who are unfamiliar with modelling languages may have severe difficulties in understanding and thus validating a model. Furthermore, the sheer size and complexity of a model may make it difficult even for experienced designers to validate a model.

Several techniques to ease the validation process have been proposed. One approach is to introduce graphical symbols, [11], or user defined concepts, [18]. Another approach is to paraphrase parts of the conceptual model into natural language [2], [3], [19]. Model simulation can be used for observing and experimenting with the dynamic properties of a model, [21]. Explanation generation techniques have been used to integrate the techniques mentioned above. Explanation generation extends paraphrasing by including question-answer facilities that interactively supports a user exploring a model. Model simulation can be complemented by explanation generation that guides a user through the execution and explains the system’s behaviour. Explanation generation has previously been used mainly for expert systems, e. g. the Explainable Expert System (EES), [17], which provides natural language explanations of rule-based systems based on Rhetorical Structure Theory (RST), [14].

Recently, there has also been an interest in using explanation generation for the purpose of validating conceptual models. A problem in this respect is that of finding a domain independent context in which to structure the explanations. Earlier work [8], [5] use RST to create coherent language output. However, this approach require customisation for each domain since typical RST-relations have no correspondence to conventional conceptual model constructs. An alternative is found in [4] where Toulmin’s argumentation model [20] is mapped onto a conceptual model in order to structure the user dialog. However, the mapping of the constituents of the argumentation model and conceptual model is still rather coarse, which results in relatively unstructured explanations.

In this paper we introduce an additional level into the explanation architecture proposed by [4] by utilising the concept of analysis patterns as a context for structuring natural language explanations of conceptual models.

The purpose of this paper is to propose an architecture for explanation generation of object oriented conceptual models. The work reported upon in this paper builds on the work of [4] and extends it by utilising the concept of analysis patterns as a context for structuring natural language explanations of conceptual models. The paper is organised as follows. The next section introduces the modelling language. Section 3 discusses analysis patterns and data abstractions as a context for explaining conceptual models. In section 4 an architecture for explanation generation is outlined. Section 5 and 6 elaborate on this architecture by discussing explanations of static and behavioural parts of the conceptual model. Section 7 summarises the paper and gives directions for future work.

2 Conceptual Models and Modelling Formalism

A conceptual model [1] consists of a conceptual schema and a corresponding information base, i. e. the instances corresponding to the types in the conceptual schema. The conceptual schema, in turn, can be viewed as a language (i. e. enumerations of entity types, attributes, relations) to describe the phenomena in the system to be modelled, a set of derivation rules and integrity constraints and a set of event-rules describing the behaviour of the object system.

For the purpose of explaining conceptual models, the Unified Modelling Language (UML) is chosen as modeling notation. An example UML class diagram and part of the corresponding object (instance) diagram is shown in Figure 1 and Figure 2, respectively.

Fig.1. A UML Class Diagram

Fig.2. Part of a UML Object Diagram corresponding to the diagram of Figure 1.

3 Patterns and data abstractions for explanation generation

When designing an explanation architecture for conceptual models it is essential to investigate what concepts to explain. Another question is how large parts of the schema should be included in an explanation. Much of the semantics in the conceptual schema is given by the graphical notation itself and an appropriate choice of names for classes and associations. Simply paraphrasing, for instance, an association between two classes may not contribute much to the user’s understanding of the schema. Even for a person with only rudimentary knowledge of a modelling language, inspecting a graphical schema-fragment may be more informative than reading a text in natural language describing the same phenomena. What is not explicitly graphically captured is harder to make inferences about. The overall semantics of the conceptual model is a result of dependencies between different parts of the conceptual model. Explanations of too large fragments of the model may, on the other hand, prove counter productive. [8] states that it is not very effective to paraphrase large parts of the conceptual model, since the user may find the paraphrased text too general or unfocused. [4] argues that short texts or visualisations that answer focused questions about the structure or behaviour about a model in the context of a special use case, are much more effective. Especially effective are answers that combine information from different parts of the conceptual model, for instance by combining static and dynamic aspects [2], [4].

3.1 Analysis patterns

Our approach is that the concept of analysis patterns may be part of a solution to the problem of finding a context that provides an adequate abstraction level for effectively explaining the semantics of different model constructs and naturally limiting the scope of the explanations to include a relevant part of the conceptual schema.

The notion of patterns come in a large number of varieties. One of these is the design pattern, [7]. While design patterns address the design stage in systems development, an analysis pattern concerns the analysis and specification stage. An analysis pattern describes, at an arbitrary level of abstraction, a set of real-world objects, their interrelationships, and the rules that govern their behaviour and state. Examples of analysis patterns are the patterns in [6], the data model patterns of [9] and domain abstractions discussed in [12]. These patterns may be viewed as conceptual patterns (i. e. small parts of a conceptual model), to be used, and reused, as an already constructed solution to a modelling problem. In this paper we are viewing analysis patterns from the opposite direction, as an instrument for generating explanations of relationships between constructs in a conceptual model in a validation situation. The use of patterns, in general, in this respect is not very well investigated. One example is [13] where design patterns are used for validating system requirements.

Fig.3. Resource allocation analysis pattern [6] (modified)

In Figure 3 an example analysis pattern, resource allocation [6], is given. The resource allocation pattern models different types of allocation of resources. Some resources are consumed in an activity, e. g. in surgery blood plasma is consumed. Other resources, assets, can be reused, e. g. a nurse. The consumable type classifies the consumable resources while individual assets are categorised by the asset type. A temporal resource is a specific resource allocation of an asset, whereas a consumable is a resource allocation of a consumable type from a certain holding (finite store). General resource allocation is used to represent what resource types are required for a certain activity. This feature is shown in the class diagram of Figure 4 where the resource allocation pattern is used to model the allocation of resources for patient activities in a health-care system. Figure 5 shows part of a corresponding object diagram.

Fig. 4. A class diagram utilising the resource allocation analysis pattern

Fig. 5. An object diagram corresponding to the class diagram of Figure 4

3.2 Additional data abstractions for explanation generation

We will include three additional data abstractions, the semantics of which we believe also offers an adequate context to create explanations in natural language of different parts of conceptual models.

GENERALISATION HIERARCHY

A hierarchy of classes related by means of generalisation relations connecting specific classes (subclasses) to general classes (super classes). The subclass inherits attributes, methods and associations from the super class and may also have additional attributes associations and methods (or method implementations) of its own.

POWER TYPE

[15] defines a power type as an object type whose instances are subtypes of another object type. The Asset type class of Figure 4 is a power type for the Asset class. Instances of the Asset type class are the different categories of recources, for instance a nurse type or surgeon type. Instances of the Asset class are the surgeon ‘Molly Brown’ and nurse ‘Lisa Anderson’.

RELATIONAL CLASSES (ASSOCIATION CLASSES)

An important concept is objectification [10] (introduction of a relational class/association class) of relationships that occur time and again in different analysis patterns and even form the basis of some of these patterns, examples are the accountability pattern with its numerous variations [6] and the asset structure element models of [9].

We will give an example of a description in natural language of the relational class. In a user dialog, this text will serve as a motivation why a relational class has been introduced into the conceptual schema as well as giving the semantics of the relational class. The definition below should be additionally augmented by example instances from the schema.

A relational class (or association class) must be introduced if there exists either a multivalued relation (in UML this corresponds to a relation where both roles have either multiplicity 0..* or 1..*) where the relation has properties of its own or a relation between more than two classes. The properties of the relation become attributes of the relational class.

One reason to include additional, generally smaller, modelling concepts in addition to the analysis patterns into the explanation architecture is that in some situations explaining an entire analysis pattern may generate too large an explanation. Exactly what modelling constructs to include is not obvious. Our choice of generalisation, power-type and relational (or association) classes is based on our experience that these concepts are fundamental in the sense that they are used more frequently in a modelling situation than are other related concepts and are generally represented in most modelling languages by means of classes (entities) and associations (relationships) without any additional language symbols.

3.3 Demands on the modelling language

One problem in utilising analysis patterns in an explanation architecture is that this puts explicit demands on the modelling language to be used. The notation must include language fragments for the purpose of classifying objects and associations as constituting an analysis pattern. One approach is that the language contains explicit (preferably graphical) symbols for different pattern types. It is difficult to envisage how this approach would be carried out in practice, though. The complexity of the language would increase to a level where the advantages of the graphical notation may be diminished by an introduction of too many new symbols. Another approach is to incorporate the use of analysis patterns into CASE tools in the sense that the tool aids the user in constructing conceptual schemas by offering a variety of different domain independent analysis patterns to be used as building blocks in the schema. In either approach the semantics of the different analysis patterns will be present in the CASE tool. An explanation component can thus base the generation of explanations in natural language on the constraints and dependencies pertaining to a generic pattern. One possibility is to make use of ‘canned text’, a hard coded explanation in natural language, describing the semantics of different constructs of the conceptual model. Such a library of explanations in natural language corresponding to different generic constructs of the modelling language may either be maintained by an explanation component for conceptual models or pertain to the specification of the modelling language.

However, state of the art for CASE-tools of today does not generally include the concept of analysis patterns. We are aware of very few tools that aid the user in utilising analysis patterns in requirements engineering even if some attempts to enlarge and refine the diagramming techniques in this direction have been made. One example can be found in the utilisation of stereotypes in the class diagrams of UML where a stereotype can be used to denote the concept of power-types.

4 Argumentation model

In organising the generation of explanations some problems inherent in text generation must be addressed, for instance what is the focus of the explanation, on what level of detail should an explanation be given, for whom is the explanation given, what sources of information should be used in the explanation, etc. These issues are mainly solved by a deep generator (i. e. a planner and organiser of a coherent text, for a detailed explanation please refer to [16]). In addition, a surface generator is needed to realise the output from the deep generator, i. e. a grammar to create syntactically correct sentences and a lexicon to generate the words. The surface grammar and lexicon are not addressed in this paper.