focused conceptualisation: framing questioning and ... · presented are then linked to generic...

P. van Bommel et al. (Eds.): PoEM 2010, LNBIP 68, pp. 190–204, 2010. © IFIP International Federation for Information Processing 2010

Focused Conceptualisation: Framing Questioning and Answering in Model-Oriented Dialogue Games

S.J.B.A. (Stijn) Hoppenbrouwers and I. (Ilona) Wilmont

Radboud University Nijmegen Institute for Computing and Information Sciences

Heijendaalseweg 135 6525 AJ Nijmegen, The Netherlands

[email protected], [email protected]

Abstract. This paper reports on a next step in a line of research taking the perspective that modelling as an activity is a ‘constrained conversation’. We focus on concrete communication situations in context of (enterprise) modelling sessions, with special attention to the involvement of ‘novice modellers’. We present some theoretical notions that are helpful in understanding why modelling performed by/with novice modellers can usually be best broken down in sub-tasks, and how such decomposed tasks can be analysed and structured to match the limited skills of (novice) modellers. The generic aspects presented are then linked to generic types of questions and answers that are both drivers and constraints for the ‘dialogue games’ played in conversations-for-modelling. We also present and illustrate an instrument for analysis, the ‘Focused Conceptualisation’ (FoCon), which can help identify, evaluate and create dialogue games for model-oriented communication situations; we discuss three working examples of the use of FoCons.

Keywords: Conceptualisation, enterprise modelling, dialogue games, collaborative modelling.

1 Introduction

The context of this paper is the study of what goes on, essentially, when people engage in enterprise modelling. Through such insight, we hope to eventually improve the practice in applied situations. We present a next step in our inquiries of modelling as a specialized class of conversation [1]. Earlier work in this line has identified goals of modelling [2], and explored the basic conversational view on modelling and its elementary units of analysis [3]. We now focus on concrete communication situations.

Modelling is increasingly becoming a required activity in many situations [4,5]. Often, participatory principles in system design require that modelling efforts, or at least some phases in them, become more accessible to participation of what we might call “novice modellers”: people who are typically untrained in modelling, and who do

Focused Conceptualisation 191

not view modelling as a professional skill or responsibility relevant to them personally. In practice, novice modellers are typically non-technical stakeholders.

We observe, as before [5], that current tools for modelling are mostly expert-oriented editors, providing hardly any active support for the challenging, creative process of conceiving and formulating a good abstract model. Support of a ‘way of working’ may not be needed or even wanted by expert modellers (who often find a prescribed modelling procedure an impeding factor rather than a help [6], and just want an aid for representing the model they conceive) but in cases where novice modellers are involved, methods tailored to support a stepwise way of working that novices can understand and deal with can be of considerable value. While we embrace the use of formal modelling languages, we emphasise that the cognitive burden their direct, unguided use places on the novice modeller is often too high [7]. Hence we study ways of making formal conceptualisation easier and more accessible without abandoning formality as such.

The main question underlying this paper is: ‘how can we understand and frame the questioning-and-answering that constitutes conversations for modelling, and as an extension of this, how can we usefully analyse concrete model-oriented communication situations, in particular in view of their accessibility to novice modellers’.

We will first provide some theoretical background and relevant concepts. Next we will discuss stepwise, focused questioning and answering within modelling processes, and how this corresponds to the existing notion of dialogue game. We will then discuss in detail a novel ‘operational method analysis’ concept, the Focused Conceptualisation, and illustrate it. Finally, we will conclude and suggest directions for further work.

2 Theoretical Background: Modelling As a Conversation

With ‘modelling’ we here mean the purposeful creation of structured and coherent texts or graphical artefacts and subject to strong conceptual (and other) constraints. Such constraints may for example pertain to syntax (often with some mathematical semantics underlying it), the domain targeted, aspects focused on, and the level of agreement to be reached among co-modellers [2]. We take a goal-driven perspective on modelling: every model serves or works towards at least one clear, utilitarian purpose [4]. Examples of such models include all regular types of modelling as encountered in enterprise engineering, information systems engineering, and software engineering (most prominently, requirements engineering). Similar practices can also be found in fields like knowledge engineering, system dynamics and operations research.

Regular, language-oriented textbook methodology does not offer much help concerning detailed, situation-specific ways of working. This has led us to look for specialized ways of researching operational modelling, i.e. the detailed (inter)actions performed by people when they model, and how this relates to resulting models, modelling languages, procedures, and tools [3]. We have found it very useful to view modelling methods and procedures as interactive systems. The activity of modelling is strongly language-oriented and produces explicit conceptual constructs (the model);

192 S.J.B.A. Hoppenbrouwers and I. Wilmont

in particular if conducted collaboratively, it also involves communication about the model. It is quite appropriate in this vein to view the model as a text (in the theoretical sense [8], consisting of interrelated propositions [1]. These propositions can be represented by graphical or textual means; often, a combination thereof. This implies that modelling processes are conversations leading to models. The three basic concepts in our view on modelling processes are shown in Fig. 1.

Fig. 1. The RIM framework

The Rules essentially serve to constrain the conversations-for-modelling. We distinguish between 3 types of rules: goal rules, interaction rules and procedural rules. Goal rules define the goals set for the conversation-for-modelling: what sort of model it is to render. The tighter the goal rules, the more constrained the product of the conversation. The most important goals-for-modelling within goal rules are content goals, syntax goals, validation goals and argumentation goals [2]. Interaction rules constrain interaction itself. They may simply be the implicit set of conventions for acceptable and anticipated conversation patterns [9], but they may also be more explicit and specialized. Finally, procedural rules determine the order in which certain activities within the process are to be carried out (‘workflow’). Such activities are typically related to goals and sub-goals of the modelling effort at large.

We can also define a fairly standard set of interaction types [3]: propositions, questions, agreements, disagreements, arguments, clarifications, acceptations, rejections. These are in line with categories commonly used in fields like argumentation theory and conversation analysis. We have by now analysed a number of conversations-for-modelling using the RIM framework, refining and validating it to a reasonable degree.

Two of the RIM framework’s three basic concepts, rules and interactions, reflect the basic elements of what in Argumentation Theory [10] is referred to as Dialogue Games. [11] reports on an implemented educational interactive system called InterLoc, designed for creating and playing collaborative versions of dialogue games (fig. 2). Another implementation illustrative of our approach is CMapTools [12], a software package supporting the creation of Concepts Maps, which are explicitly defined and implemented as graphical representations of sets of textual propositions [13], thereby aptly mirroring the third RIM concept: ‘model’. Combining InterLoc


and CMapTools, InterLoc’s structured dialogue games can indeed render the propositions that can then be visualised and refined by means of Concept Maps. Both applications are rather basic and do not support advanced meta-models (ways of modelling) or interfaces (editors) of the kind needed for adequate support of specialized modelling efforts. Combined, they do, however, convincingly illustrate the basic workings of the RIM framework and show that it is at the least a viable and realistic view on the process of modelling.

Fig. 2. An example fragment of a logged InterLoc conversation (part of step 1 in the GMB dialogue game: see section 4.2)

We are fully aware that constrained conversations-for-modelling as illustrated in fig. 2 may serve well as a theoretical and methodological basis for analysing and reasoning about modelling processes, but that as an operational interface for interactive systems supporting modelling, they leave much to be desired. We therefore emphatically distinguish between the deep interface and the surface interface of such systems.

The deep interface closely mirrors the RIM framework and distinguishes, enables and (possibly) logs interactions one-by-one, as the moves in a dialogue game, thus creating and logging an incremental set of deltas on the model that is created. A surface interface (not illustrated in fig. 2) should support more efficient and user-friendly execution of deep surface interactions, including graphical editing, textual editing, form filling, and so on.

Still, every interaction at surface level can in principle be reanalysed as a set of related interactions at deep level. Note that this implies that any existing setup for the support of a modelling effort (even very low-tech setups) can be analysed as a dialogue game under the RIM framework, at the level of the deep interface. This provides a generic analytical instrument across all sorts of operational modelling sessions.


3 Focus Questions and Abstract Conceptualisation

In this section we discuss an issue key to understanding the sort of abstract conceptualisation that is modelling: what essential (types of) questions are asked in view of a modelling effort, and how do these relate to constrained abstract conceptualisation as performed using certain ‘ways of modelling’ (modelling languages)?

3.1 Abstract Conceptualisation: Three Activity Types Distinguished

Modelling is largely about abstraction (or rather, abstract conceptualisation). As explained in [14]:

“There are many ways to define abstraction, depending on which perspective is taken. In fields such as philosophy, mathematics and logic abstraction is characterised as information neglect: “eliminating specificity by ignoring certain features” [15]. […] The highly dynamic and interactive nature of computer science is fundamentally different and therefore requires a different interpretation: information hiding. A key concept in information hiding is the deliberate omission of irrelevant information so that the focus is only on the relevant aspects of conceptualisation. […] Human beings engage in abstraction all the time, often without noticing it. Abstraction always requires a form of representation or description, making it inextricably bound to language.”

We observe that in the conceptualisation of abstract propositions there can typically be a distinction between three different flavours of activity:

• generation of proposals (by ‘thinking them up’ or alternatively by importing them from existing sources)

• classification of the proposals (e.g. according to topic or aspect, or according to word forms or meaning categories: ‘nouns’, ‘verbs’; ‘causes’, ‘activities’, ‘objects’; and so on)

• selection of certain categorised concepts based on criteria matching the conceptualisation goals set (i.e. the modelling goals).

Thus, a generative aspect (idea formulation) is combined with a constraint aspect (checking of conformance to pragmatic, syntactic and semantic restrictions of various sorts). It is quite possible that in operational conceptualisation, the three activities are in fact collapsed into a single visible activity, i.e. in such cases no distinct intermediate products are created except perhaps in the mind of the participant. However, in many other cases (in particular those involving novice modellers) one or more of the activities are performed in separation. This seems to be a general property of explicit conceptualisation, not one unique for specification and modelling [16].

3.2 Two Basic Foci in Conceptualisation

Zooming in on the types of focus used in conceptualisation, we observe that in modelling practice, two main foci can be distinguished: focus on information that is


deemed relevant for the purpose of the model (let us call this pragmatic focus) and focus on concepts that fit some prescribed semantic and/or syntactic frame of description: a modelling language (this we call the semantic-syntactic focus). Both pragmatic focus and semantic-syntactic focus can play a role in the generation, classification and selection of propositions.

Pragmatic focus concerns the purpose for which the domain description is created. What is the description to be used for? Explaining to someone how to do something? Where to find something? Why things in the domain are how they are? What problem to solve? What to build? What is and is not allowed? Such questions bear great resemblance to what [13, p19] call “focus questions”. They are also (more distantly) related to aspects of text functionality [17].

People intuitively know how to formulate a description for specific pragmatic purposes, and they are normally quite capable of fine-tuning their description for the goal it is meant to serve. Explorative research [14] suggests that they will intuitively prefer the use of certain semantic/syntactic conceptual categories (e.g. activities, objects, is-a relations, causes, etc.) as they aim for a certain type of description. However, this indeed happens very intuitively, and within the boundaries and means of normal natural language. Hence, applying a pragmatic focus is to a considerable degree accessible to novice modellers: it is largely a 'natural' capacity in people, connected to pragmatic language skills (using language in specific contexts, for specific situational goals).

The second type of focus (semantic-syntactic) is not so 'natural', and is associated with the use of restricted artificial languages with some special purpose syntax. It concerns form and concept classification rather than ‘content’: actively selecting certain types of conceptual categories, instantiating them, and combining them into structures with strong limitations. Such constrained syntax is typically introduced for very good reasons to support a particular, limited goal in language expression (for example, describing process flow in terms of Petri Nets, or entities and relationships in terms of first order predicate logic). They do, therefore, provide a kind of focus that is imminently useful in particular modelling contexts, and that is in line with some pragmatic focus –indeed it very much supports the 'intention of the description' as seen from the engineering side. The problem is that to use a constrained syntax in such a way demands special skills to a much higher degree than does a pragmatic focus [7].

3.3 Discussion: Pragmatic and Semantic-Syntactic Focus in Practice

Typically, pragmatic focus should be leading in the choice of modelling language (right language for the job); we observe, on the side, that in practice this is not always the case, and that indeed this can seriously hamper realization of proper pragmatic focus and delivery on pragmatic goals.

In ‘informal modelling’ the pragmatic focus (what the model is for) need not necessarily be augmented by a constrained modelling language: such use of a formal language is typically due to additional requirements on the language of model formulation, usually of a technical or mathematical nature. In other words, pragmatic focus can be pretty well achieved if descriptions are phrased in informal diagrams or natural language, but additional goals-for-modelling may still demand a strong


semantic-syntactic focus. Note that it is also possible to adhere to the semantic-syntactic focus but still model irrelevantly because of a flawed pragmatic focus.

Concerning the semantic-syntactic focus, it is a well known phenomenon in modelling that a specific aspect of a domain may well be modelled in various ways (for example, imperatively or declaratively: as a flow or as rules) but that if the mindset of the modeller is not clear on one specific paradigm/meta-model from the beginning, an entangled mess of concepts may be the result. In other words, meta-models do not mix well in conceptualisation (in particular if they are based on differing modelling paradigms). So from a semantic-syntactic focus point of view it is in principle a bad idea to start off with a 'general (unfocused) exploration of what the domain looks like' if a constrained syntax is what is aimed for, while pragmatic focus may well call for such a generic overview. For semantic-syntactic focus, the sharper a focus question is put from the very start, the better it is: it focuses the mind of the domain expert and in her conceptualisation makes her weed out concepts and propositions irrelevant to the goal of the model that is being constructed. If the semantic-syntactic focus is insufficiently clear, the description will become less sharp, leading to the introduction in early versions of the conceptualization of concepts and propositions that may be valid in the sense that they reflect a real and even significant aspect of the domain, but that are not relevant to the specific modelling task at hand.

Disentangling a mixed conceptualization is a job that is not for the faint-hearted; it is usually best to go back to start and reconceptualise the model. While this may not always be avoidable, it is time consuming and frustrating for all involved. Starting off instead with a clear semantic-syntactic goal/focus in mind (in this case, a clear meta-model) therefore helps greatly if clean and efficient conceptualization is to take place. Unfortunately, this means that 'generic and free descriptions' of domains, that are intuitively useful as a starting point for novices and that for pragmatic reasons may well be desirable, can in fact very much hinder the semantic-syntactic focus in conceptualization down the road. This is a tricky point of which we should be well aware.

So for a good model to serve some clear pragmatic goal (and assuming a constrained meta-model is needed for analytical or engineering purposes), both the pragmatic focus and the semantic-syntactic focus are required. Expert modellers are usually capable of combining pragmatic and semantic-syntactic focus in one creative act of modelling (discarding the workings of their inner thoughts). Not so for novices.

All too often models are created only explicitly employing a semantic-syntactic focus, leading to syntactically correct models in some modelling language which may nevertheless be quite useless. We observe that in many modelling efforts (especially in educational and training contexts), the situational purpose of a model is hardly made explicit and modelling is indeed reduced to a syntactic exercise. We thus point out the importance of clear awareness of the pragmatic focus in addition to the semantic-syntactic focus for any modelling effort that is meant to be 'useful'. If syntactic exercises are performed separately (and indeed this seems alright as a limited exercise), we should also train/guide modellers in developing a proper pragmatic focus: train them to produce relevant descriptions (perhaps in natural language at first) that serve specific purposes.

To conclude: in view of breaking down modelling efforts into manageable steps (for novices but also for experts), it seems potentially helpful to separate steps


involving pragmatically focused description from steps involving semantic-syntactic focus, and have the former precede the latter. Also, it can be helpful to break down conceptualisation into three further steps: generation, classification, and selection of propositions. In other words, a maximal breakdown combining pragmatic versus semantic-syntactic focus combined with the generation – classification – selection distinction leads to a 2x3 matrix of possible main foci.

The separation in skills that may or may not be required for the application of these possible foci in conceptualisation creates opportunities for nuanced analysis and design of ‘mini dialogue games’ built around assignments with clear and sufficiently limited focus questions, fit for participants with particular (possibly limited) competencies.

4 Focused Conceptualisations

Based on the theoretical findings and assumptions sketched in the previous sections (that in turn are based on the literature, practical experience, and focused explorative research), we now zoom in on a detailed aspect of the formulation and execution of conversations-for-modelling (viewed as dialogue games): concrete ‘mini-games’ as parts of larger modelling efforts, as discussed in section 1.

As mentioned, expert modellers typically want cut to the chase and create a conceptual model straight away (though perhaps taking sub-steps ‘inside their heads’), but all novice-oriented approaches to modelling we are aware of break up the modelling process in smaller, more workable (‘playable’) chunks. Novices indeed seem better capable of dealing with small, focused conceptualisation assignments than with immediate and holistic ‘diagram drawing’, and this is commonly reflected in many of the more developed elicitation and modelling practices.

In our analysis of ‘mini dialogue games’, that we dubbed Focused Conceptualisations or FoCons, we are particularly interested in the questions asked in them, and the restrictions on answers to be given in them. Indeed, the FoCon concept is designed to support thinking about questions and answers. This basic principle should never be forgotten when dealing with focused conceptualization of any kind. Note, however, that questioning and answering are primarily theoretical devices here (deep interface) that may or may not be explicitly present in the surface interface.

In close relation with the identification of questions and answers (explicitly stated or not), we can then for specific situations consider who is or is not capable of understanding particular questions and provide acceptable (sufficient quality) answers to them. This is a second analytical use of FoCons: providing more detailed insight in what is asked of modellers in actual situations, and whether this is realistic in view of their actual competencies and expertise [18].

Essentially, a Focused Conceptualisation is a description of a communication situation in which one or more participants engage in a focused conversation in order to arrive at a specific conversational goal, typically some sort of highly structured abstract description, specification, or (partial) model.

FoCons can in principle be used both descriptively and prescriptively; they can be used in the analysis of observed model-oriented conversation, but also in method design, framing such conversations in order to guide them (the frame being a dialogue game). Once a FoCon (or set of FoCons) is sufficiently clear, it can be used as a basis for designing one or more deep level dialogue games, which in turn may serve as a


basis for a Surface Interface design. In this paper, however, the main emphasis lies on the FoCon as an analytical instrument. We will report on FoCon-based dialogue games elsewhere.

4.1 The Content of FoCons

A modelling effort can in principle be covered by a single (rather large) FoCon1, but as should be clear by now we are mostly interested in the use of FoCons as a means to decompose a modelling effort in phases/steps/activities with a more constrained focus than the modelling effort as a whole. Previous research suggests that even unguided, real life modelling exercises nature often consist of such focused sub-activities [3]; often this even holds expert modellers.

In describing a FoCon, we distinguish between the following main aspects of a communication situation (Table 1):

Table 1. Information categories that make up a FoCon description

Short description Clarification What may or must ‘go in’ Types of information; sources thereof What should ‘come out’ Pragmatic as well as semantic/syntactic

constraints on textual and other results (including social results), preferably phrased as ‘modelling (sub)goals’ (see section 2)

The type(s) of abstraction activity involved Generation, classification or selection (separate, or integrated in one step)

The specific focus questions asked (literally so)

This concerns both the pragmatic and the semantic-syntactic focus)

The (types of) participants involved and their relevant competencies and expertise

Possibly, flaws therein; possibly, other relevant information on the participants

Instructions given and/or procedures, conventions and guidelines

Explicit and also implicit if relevant; adhered to by the participants (‘rules of the game’)

Further situational aspects or constraints E.g. media involved, resources required, organisational issues, social issues, political issues, or whatever is deemed relevant.

4.2 Examples of the Use of FoCons in Case Analysis

We will illustrate the use of FoCons as an analytical device at the hand of the three examples.

1 Note that though strictly speaking a FoCon is a description of a communication situation, we

allow ourselves to refer to both specific communication situations and situation types as “FoCons”.


The first example concerns a relatively unguided modelling assignment in which three participants (students) were asked to create an as-is process model of a well- documented domain. The modelling language was not dictated, but the students chose to use UML activity diagrams. As discussed in [3], the students’ modelling behaviour clearly showed division of their 18 minute session in 3 phases: i. choosing the modelling language and sub-division of work, ii. exploring and deciding which actors play a role in the first partial process model, and iii. modelling the sub-process. The second of these phases is a good example of an (improvised) FoCon. The participants first needed to establish which of a fair number of actors (roles) in the domain were relevant for a particular sub-process (swim lane diagram) they set out to create. Thus they focused on a sub-set of questions of those underlying the whole effort assigned to them:

• They focused on the selection of relevant actors only • They restricted themselves to only one sub-process (out of five given in the

domain description)

At the hand of the FoCon analytical categories listed earlier in this section (Table 1.), we will consider this communication situation in more detail (note that this is a marked extension of the initial analysis reported in [3]).

• What may or must ‘go in’: The participants were provided with an existing list of roles, hence they merely had to select relevant roles. The problem lay in understanding the roles and how they related to activities in the process. Hence, important input was also the list of activities as understood to be part of the sub-process under consideration (with the domain description as a source). It served to create (implicitly!) a ‘table’ of relevant activities and actors involved. Ordering of activities was not relevant within this particular FoCon. The textual source that was provided proved to be insufficient: after a failed attempt to solve the puzzle based on documentation alone, additional information was obtained by actively involving the person (researcher) who drew up the textual documentation.

• What should ‘come out’: For this FoCon, the participants really only wanted to identify the actors (in order to set a ‘swim lane’ for each of them). The activity list was a by-product that would nevertheless be useful later on. The pragmatic focus was clear: “describe who is involved in the sub process as described in the case documentation”. The matching semantic-syntactic focus was also clear: just an unordered, agreed list of actors (a basic concept in UML activity diagrams).

• The type(s) of abstraction activity (generation, classification, selection). Generation and classification of the main concepts involved, actors, was not necessary since they were given, leaving selection. However, in order to do this the activities involved needed to become clear as well as, more importantly, the activities which specific actors were involved with. Obtaining this information did involve some active content generation in the end: they asked an expert. Classification never was a real issue, so selection was what this FoCon was mostly about: setting up a clear-cut way of reasoning about determining the actors involved, and gathering the facts needed to carry through such reasoning.


• The specific focus questions asked. Though the focus questions were not all asked explicitly, they could be reconstructed as follows:

o MAIN Which actors are involved in the sub-process concerned?

SUB1 Which activities are part of the sub-process? SUB2 Which activities involve shortlisted actors? SUB3 Which actors are involved in the activities that are part of

the sub-process?

• The (types of) participants involved. The participants did not have enough information (until they asked an external source), but they did have sufficient basic skill to execute the FoCon. Importantly, they also had the skill to conceive and enter the FoCon as a sub-step in solving their problem: after all, the FoCon as a sub-game in the modelling effort was not dictated, but initiated by the modellers themselves as a strategic step of their own devising.

• Instructions, procedures, conventions and guidelines. Being of their own making, the FoCon largely concerns “rules in the game” [2,3]: goal rules set by the players themselves (chosen strategy) as a step in solve a larger problem. Conventions were mostly those of general constructive conversation.

• Further situational aspects or constraints. The FoCon would probably have been much more effectively executed if its questions and its simple underlying reasoning had been explicit from the start.

We trust the example above sufficiently illustrates the sort of information contained in a FoCon as an instrument of analysis. Also, we hope the reader will see that it immediately sparks ideas about possible use in method design. In the other two examples below, we will not repeat the point-by-point representation followed above for reasons of space.

The second example concerns analysis of an existing and well developed procedure for Group Model Building (System Dynamics) in context of reshaping it as a guided dialogue game.

Group Model Building (GMB) is a method for creating causal models in the context of ‘problem structuring’, based on input given by an (often heterogeneous) group of people. GMB is typically used as an instrument in performing interventions in (unwanted) situations: a method in management science. Main concepts used in constructing the most basic diagrams in GMB (‘Causal Loop Diagrams’) are the problem variable (some quantifiable indication of a problem, like “teenage pregnancies (too high)” or “number of cars produced (too low)”; causes (changes of which influence the problem variable, like “money spent on education” or “number of people employed”); consequences (effects of changes in the problem variable, like “rising unemployment” or “dropping customer satisfaction”). Crucial are also causal or feedback loops, circularly linking some causes and consequences, that capture the dynamics of the system (problem situation) described. GMB has been used for well over a decade, and has a well developed practice [19].

We analysed the existing ‘script’ (as GMB practitioners call it [20]) used by facilitators of the group model building process. The script contained explicit ‘steps’, but these did not fully match the five FoCons identified by us (more steps were distinguished in the script, based on instructional structuring rather than systematic process analysis). Though the script was quite workable as an informal guideline, it


had been somewhat unsystematically drawn up. Also, it was incomplete with respect to explicit statements concerning specific questions asked and decision criteria used (i.e. the rules of the game). Our initial analysis of the script was used as a basis for extensive questioning (two two-hour interviews) of a GMB expert. It soon became clear that this person could answer all our questions, i.e. indeed the script was lacking detailed and well-structured information but the GMB expert did have detailed knowledge of how to do the job. The FoCon structure and Dialogue Game metaphor (which was first explained to the expert) proved highly valuable as a scaffold for the interviews, which provided not only us, but also the GMB expert with a very satisfactory increase in insight in the structure and rules of the GMB operational procedure.

After the in-depth analysis, the five FoCons now defined were successfully used as a basis for the design of a playable dialog game implemented in InterLoc (see fig. 2). We plan to report on this game elsewhere. We briefly list the GMB basic FoCons below:

1. Create individual lists of ‘ideas’ and ‘variables’ with respect to factors influencing and/or being influenced by the (stated) ‘problem variable’

2. Create a list of ‘ideas’ and ‘variables’ understood by and agreed on by the group (‘group list’)

3. Decide (and discuss) which of the variables listed is a ‘cause’ variable 4. Decide (and discuss) which of the variables listed is a ‘consequence’

variable 5. Check for any causal loops found whether they are understood by all

participants, and deemed relevant (loops are identified through a deterministic ‘game procedure’ (like running the bank in Monopoly), so they only need to be pointed out, understood, and proclaimed relevant)

FoCons 1. and 2. emphasise focused generation of ‘ideas’ and distillation thereof in ‘variables’. In fact, one could say 1. and 2. both consist of two sub-FoCons, the first (‘idea’ generation) enforcing only a pragmatic focus, the second (‘variable’ generation) enforcing a more constrained pragmatic focus as well as a semantic-syntactic focus. This latter sub-step implies a mild form of classification and selection, and thus combines generation-classification-selection in one step. FoCons 3. and 4. are aimed not at generation but strictly at classification and selection: of ‘causes’ and ‘consequences’, respectively. The pragmatic and semantic-syntactic foci neatly fit together here. FoCon 5. does not require conceptualisation as such (except by the facilitator or ‘game master’), but only an understandability check and validation of content derived from other findings.

The step-by-step succession of focus questions thus creates a series of tasks which most educated novice modellers find quite feasible, as has been proven in many GMB application cases (GMB typically involves only novices except the facilitator).

This is only a basic example of a GMB dialogue game. We intend to later expand our analysis into the more technical, formally more challenging aspects of GMB and system dynamics modelling, which have so fare remained outside our scope.

The third example concerns analysis and critical discussion of a number of problematic model-related communication situations that occurred in the operational process of a large Knowledge Based Systems company; only one situation will be presented here.


The situation in question concerned elicitation of some legal decision criteria (declarative in nature) that had to be obtained, clarified, and reworked into the description of a stepwise decision process. Time pressure was great, and the one expert involved was not available for a personal interview. Instead, some telephone conversations had to do the job. Not surprisingly, this did not turn out too well.

We employed the FoCon template and Dialogue Game metaphor in systematically discussing the situation with the analyst who performed the sessions with the domain expert. This approach first served to create a new awareness with the analyst that such situations could be discussed as isolated ‘communication games’ and become subject to systematic evaluation and analysis. We quickly found that this particular FoCon suffered from a number of flaws, some of them obvious, some less so:

• The domain expert was not 100% knowledgeable about the legal details, even though he was an authority in the legal process

• The existing legal decision criteria were not phrased in a way directly fit to be transformed into ‘decision steps’. This concerns a clash of the pragmatic focus of the existing documentation with that of the pragmatic and semantic-syntactic focus of the FoCon, making necessary the active generation of conceptual content.

• The domain expert was not able to rephrase the declarative decision criteria as a decision procedure (i.e. generate the required content), thus leaving this to the analyst, who had insufficient legal knowledge. Thus, the focus questions could not be answered without the analyst ‘making up a decision process’.

• The medium used for this FoCon (telephone) was seriously sub-optimal for the task at hand

• Time pressure led to a cut-off of the elicitation process before validation of the results was complete (validation goal not achieved)

The example neatly demonstrates one particular use of FoCons: to determine whether a ‘player’ is fit for playing the game in the first place. Whether the flawed FoCon is to be blamed on the player (the ‘novice modeller’ domain expert) or the game (the questions asked, set by the analyst) is not our concern here, but in the example the deployment of the FoCon as an instrument enabled efficient, to-the-point and instructive analysis of the communication situation and provided valuable lessons learned as well as useful guidelines for the staging of similar situations in the future.

5 Conclusions and Future Work

In section 1., our main questions for this paper were put as follows: “how can we understand and frame the questioning-and-answering that constitutes conversations for modelling, and as an extension of this, how can we usefully analyse concrete model-oriented communication situations, in particular in view of their accessibility to novice modellers”. While certainly much more could be said in answer to these questions, we have done the following:

We recapitulated previous work in which the activity of modelling is viewed and analysed as a constrained conversation, driven and constrained by rules (also defining goals), consisting of interactions and rendering sets of propositions constituting


models. This makes it possible to view, and also shape, conversations-for-modelling as dialogue games.

Abstract conceptualisation being a core activity in modelling, we distinguished three generic types of conceptualisation task: generation, classification, and selection. While such logically divided goals may be catered for in a single task, they can also be separated, making the task easier (and thereby more accessible for novice modellers, at the least).

Noting that focus questions play a central role in guiding a dialogue game for modelling, we distinguished two essential and complementary types of focus: pragmatic and semantic/syntactic. Again, though both foci can be combined in one task, it is possible to separate tasks and take on once focus at the time, or to otherwise work with the separate foci to decompose the main task and create easier sub-tasks.

Finally, we introduced the analytical instrument of the Focused Conceptualisation or FoCon, a template that helps identify and analyse communication situations along the lines of the framework sketched in the other sections. A specific use of FoCons is to help establish whether certain players are up to the task set for them in terms of their conceptualisation skills and expertise. We illustrated the FoCon concept at the hand of three rather different cases in which FoCons were used.

Indeed we believe this paper represents a step forward in understanding at a micro level (‘operational’ level) how modelling as an activity works, and how we may deal with making it more accessible and structured. We have identified and demonstrated a number of concepts that are helpful in thinking about generic (types of) questions asked and answers given in modelling sessions, and how a decomposed conversation-for-modelling can be analysed and, possibly, constructed. We already experienced that the foci and other concepts introduced help us substantially in understanding and describing specific modelling situations, either observed ones or future ones.

Future research will focus on refining and expanding the framework, and applying it to more complex and diverse types of modelling. We will increasingly aim beyond analysis: for the design, implementation and testing of dialogue games, hoping to tackle increasingly challenging (and more formal) modelling tasks and making them accessible to a novice audience. However, experts may also benefit from our findings; in general we hope to provide a sound set of principles and patterns for the situational design of operational modelling methods as interactive systems. As we learn more about ‘deep interface’ operations and requirements, we intend to gradually shift our focus to ‘surface interface’ issues.

References

1. Hoppenbrouwers, S.J.B.A., Proper, H.A., Weide, T.v.d.: Formal Modelling as a Grounded Conversation. In M. Goldkuhl, G Lind and S. Haraldson (eds.): Proceedings of the 10th International Working Conference on the Language Action Perspective on Communication Modelling (LAP05), Kiruna, Sweden. Linkopings Universitet and Hogskolan I Boras, Linkoping, Sweden, EU, pp. 139-155 (2005)

2. Hoppenbrouwers, S.J.B.A., Weigand, H., Rouwette, E.A.J.A.: Setting Rules of Play for Collaborative Modelling. In: Kock, N., Rittgen, P. (eds.) International Journal of e-Collaboration (IJeC), vol. 5(4), pp. 7–52. IGI Publishing, USA (2009); Special Issue on Collaborative Business Information System Development


3. Ssebuggwawo, D., Hoppenbrouwers, S.J.B.A., Proper, H.A.: Interactions, Goals and Rules in a Collaborative Modelling Session. In: Persson, A., Stirna, J. (eds.) PoEM 2009. LNBIP, vol. 39, pp. 54–68. Springer, Heidelberg (2009)

4. van Bommel, P., Hoppenbrouwers, S.J.B.A., Proper, H.A., Roelefs, J.: Concepts and Strategies for Quality of Modeling. In: Halpin, T.A., Krogstie, J., Proper, H.A. (eds.) Innovations in Information Systems Modeling, ch. 9, IGI Publishing, Hershey (2008)

5. Hoppenbrouwers, S.J.B.A., van Bommel, P., Jarvinen, A.: Method Engineering as Game Design-An Emerging HCO Perspective on Methods and CASE Tools. In: Halpin, T., et al. (eds.) Workshop Proceedings of EMMSAD 2008: Exploring Modeling Methods for Systems Analysis and Design affiliated to CAiSE 2008, Montpellier, France, pp. 97–111 (2008)

6. Leahy, W.M.: Cognitive Load Theory and Instructional Design: An Outline of the Theory and Reflections on a Need for New Directions to Cater for Individual Differences and Motivation. In: Larson, J.E. (ed.) Educational Psychology: Cognition and Learning, Individual Differences and Motivation, ch. 8, Nova Science Publishers, New York (2009)

7. Bransford, J.D., Brown, A.L., Cocking, R.R. (eds.): How People Learn: Brain, Mind, Experience and School; expanded edn. National Academy Press, Washington (2000)

8. Taylor, J.R.: Rethinking the theory of organizational communication: how to read an organisation. Ablex Publishing, New Jersey (1993)

9. van Eemeren, F.H., Grootendorst, R.: A systematic theory of argumentation: The pragma-dialectical approach. Cambridge University Press, Cambridge (2004)

10. van Eemeren, F.H., Grootendorst, R., Snoeck Henkemans, F., Blair, J.A., Johnson, R.H., Krabbe, E.C.W., Plantin, C., Walton, D.N., Willard, C.A., Woods, J., Zarefsky, D.: Fundamentals of Argumentation Theory: A Handbook of Historical Backgrounds and Contemporary Developments. Lawrence Erlbaum Associates, New Jersey (1996)

11. Ravenscroft, A., McAlister, S.: Designing interaction as a dialogue game: Linking social and conceptual dimensions of the learning process. In: Juwah, C. (ed.) Interactions in Online Education: implications for theory and practice, ch. 4, pp. 73–90. Routledge, New York (2006), http://www.interloc.org/pubs/InterDG_AR&SRM.pdf

12. Cañas, A.J., Novak, J.D., González, F.M. (eds.): Proceedings of the First International Conference on Concept Mapping, Concept Maps: Theory, Methodology, Technology, Pamplona, Spain (2004)

13. Novak, J.D., Cañas, A.J.: The Theory Underlying Concept Maps and How to Construct and Use Them. Technical Report, Florida Institute for Human and Machine Cognition, IHMC (2008)

14. Wilmont, I., Brinkkemper, S., van de Weerd, I., Hoppenbrouwers, S.J.B.A.: Exploring Intuitive Modelling Behaviour. In: EMMSAD 2010. LNBIP, vol. 50, pp. 301–313. Springer, Berlin (2010)

15. Colburn, T., Shute, G.: Abstraction in computer science. Minds and Machines 17(2), 169–184 (2007)

16. Kolfschoten, G.L.: Theoretical Foundations for Collaboration Engineering. PhD Thesis, Delft University of Technology (2007)

17. Lentz, L., Pander Maat, H.: Functional Analysis for Document Design. Technical Communication 51(3), 387–398 (2004)

18. Frederiks, P.J.M., van der Weide, T.P.: Information modeling: the process and the required competencies of its participants. Data and Knowledge Engineering 58(1), 4–20 (2006)

19. Rouwette, E.A.J.A., Vennix, J.A.M.: System dynamics and organizational interventions. Systems Research and Behavioral Science 23(4), 451–466 (2006)

20. Andersen, D.F., Richardson, G.P.: Scripts for Group Model Building. System Dynamics Review 13(2), 107–129 (1997)

focused conceptualisation: framing questioning and ... · presented are then linked to generic...

Documents