A recently introduced master program offering a Business Modelling track in the authors' university includes several courses that touch on conceptual modelling topics. They cover both modelling with well-known languages (UML, BPMN etc.), as well as the development of domain-specific modelling software driven by targeted requirements. Consequently, the study program aims to support two complementary modeller perspectives: (i) of the modellers who adopt "de jure" or "de facto" standards that are reusable across domains; (ii) of the modellers who prefer to have a modelling tool tailored for specific needs and their preferred domain-specific abstraction. While the first perspective is quite common and well served in Business Information Systems curricula, the second perspective requires a well-designed minimal case capable of fostering deep understanding of a modelling method's building blocks and of the methodology needed to tailor or evolve those building blocks towards satisfying explicit requirements. The paper reports on such a teaching experience and provides insights regarding its learning design rationale.
The goal of the paper is to reflect on the teaching experience and the design rationale
of a teaching case developed for a conceptual modelling study track covering both
practitioner-oriented and research-oriented topics. The study program was proposed
to align the local Business Information Systems curriculum to various study programs
around Europe, and to benefit from the teachers' experience and interactions with the
community of experts giving lectures in the Next Generation Enterprise Modelling
(NEMO) Summer School series [
The profile of the master students participating in the hereby discussed teaching experience is summarised as follows:
Student background: The majority of students graduated a Business Information Systems (IS) program or a Computer Science (CS) program. A minority (<10%) graduated a Business Administration (BA) program.
Student experience with modelling: The majority (IS/CS graduates) used UML in MS Visio as means of graphically documenting their bachelor thesis. ER diagrams were used in their Database courses. The BA graduates prefer to use Powerpoint diagramming – typically for organisational charts and process diagrams - due to the lack of constraints ("the freedom of drawing"). The students have a general intuition that not all models are correct, but take a rather intuitive approach in assessing this.
of modelling is to support human understanding of a system design through graphical documentation, as alternative to written text which is "tiring to read". Some CS graduates are aware about the "code generation" use case but have never employed it.
Considering this profile, a showcase modelling method was designed and employed as a teaching artefact, in order to emphasise its engineering process in a tutorial style and to widen the perception on the role and means of conceptual modelling. This experience and its learned lessons are further shared in this paper. The remainder of the paper is structured as follows: Section 2 will decompose this initial state of affairs in more granular teaching challenges and concerns. Section 3 will discuss methodological aspects. Section 4 will overview the modelling method employed as a teaching artefact. Section 5 will summarise findings via a SWOT analysis. Section 6 will comment on related works. The paper ends with conclusions. 2
The initial state of affairs (summarised in the Introduction) is decomposed in Table 1 in several directly targeted "issues" that needed to be alleviated, considering the initial understanding of students about certain key concepts. 3 3.1
Overarching the identified teaching challenges, the tutorial's design rationale is also
driven by several targeted meta-qualities: (i) minimalism to ensure quick
comprehension, requiring only trivial domain expertise, (ii) domain-specificity manifesting in all
building blocks of the engineered method, (iii) an evolutionary approach highlighting
how each method building block can evolve under an assumption of evolving
requirements, (iv) a constructivist approach [
Issue A: Understanding the goals and value of "modelling at large" Initial assessment: Limited understanding of modelling goals. All students agree that the goal of modelling is graphical documentation of system design or requirements. Some CS graduates are aware about the "code generation" goal (they can point to the UML Class Diagram, as a potential source for code generation). Inability to provide a simple Knowledge Management (KM) scenario that can use models. Teaching goal: To shift the student understanding from "modelling is drawing" to "modelling is knowledge representation". To raise awareness on the Knowledge Management paradigm.
Issue B: Understanding the modelling method building blocks Initial assessment: Weak understanding of distinctions between notation, syntax, semantics, modelling procedure, modelling method, modelling functionality. Students intuitively distinguish between syntax ("pertaining to form") and semantics ("pertaining to meaning").
Teaching goal: To clarify these distinctions.
Issue C: Understanding the semantics of "semantics" Initial assessment: Confusion regarding the distinction between human-oriented semantics and machine-oriented semantics. When asked "who is the main consumer of models – humans or machines?" the majority answers "humans" ("machines do not need diagrams").
Teaching goal: To clarify the different semantic levels of diagrammatic models.
Issue D: Understanding model "correctness" Initial assessment: Weak understanding of model qualities and model-to-reality relation. When asked "what is a correct model?" the common answer is "a model that accurately represents reality". Teaching goal: To reveal the axiomatic principle that "all models are wrong, but some are better than others" (according to the model's purpose).
Issue E: Understanding the application domain of conceptual modelling Initial assessment: Weak understanding of the application domain for conceptual modelling. When asked "where is conceptual modelling applied?" the common answer is "software engineering". Teaching goal: To emphasise the general value of models as means of knowledge externalisation independent of domain (i.e., adaptable to any application domain).
Issue F: Understanding agility at "modelling method level" Initial assessment: A recurring idea that all modelling should be done with UML "because it is a standard". General lack of awareness of the Design Science paradigm and of the fact that modelling software/languages/methods are artefacts subjected to design/development processes.
Teaching goal: To shift the student understanding that a modelling language is a given invariant towards the understanding that agility principles from software development can be easily transferred to modelling method implementation. To raise awareness on the Design Science paradigm.
Issue G: Low awareness of conceptualisation activities Initial assessment: The general perception is that a modelling language is a set of graphical symbols to which meaning is assigned, rather than a conceptualisation whose elements have visual representation. When asked to make a presentation about BPMN, the students' discourse starts from the "numerous graphical symbols" rather than from the set of concepts.
Teaching goal: To create awareness on conceptualisation efforts that stand behind a modelling method. By aggregating the teaching goals in Table 1, several high-level goals are formulated in Fig. 1(a) – these are the "targeted revelations" to be induced to students with respect to established Information Systems paradigms: (i) establishing the role of a modelling method as a means of externalising "query-able" knowledge (and not only as support for graphical documentation or code generation); (ii) establishing the role of a modelling method as a Design Science artefact that can be tailored for a specific purpose/usefulness and is subjected to a specific engineering process involving both abstract conceptualisation and implementation of usable tooling; (iii) introducing the "agility" quality of a modelling method; (iv) establishing the non-fixed application scope of modelling methods (complementing the popular use in software design).
Fig. 1. The paradigms grounded in the proposed teaching case (a) and
the orthogonal criteria for incrementing the teaching artefact (b)
Process-wise, the teaching starts by presenting the modelling method building blocks
cf. the definition of [
The learning effort is supported by the agile (incremental, iterative and requirementsdriven) implementation of a usable artefact – a modelling tool that deploys a domainspecific modelling method designed for knowledge acquisition (i.e., models form a knowledge base which can be queried and processed by machines). Two orthogonal criteria are thus guiding the incremental development, as highlighted in Fig. 1b: (i) gradually adding building blocks to the modelling method; (ii) agilely evolving each building block in relation to satisfy some assumed changing requirements.
The additive and the evolving development are intended to reflect the two
manifestations of agility as stated by the AMME framework: (i) artefact agility and (ii)
methodological agility. The first means that a (partial) separation of concerns should be
achieved by decomposing the modelling method artefact in constituents – notation,
syntax, semantics, functionality and modelling procedure (derived from the definition
in [
The application domain of Cooking was selected for several reasons: (i) to provide a uniform starting point for all students regardless of their background and modelling experience; (ii) to defuse the dominant perception that modelling activities are subordinated to software engineering, as means of graphical documentation for which a "drawing tool" is sufficient; (iii) to show what domain-specificity means without requiring extensive domain expertise; (iv) to be able to make analogies with business process modelling.
The assumed case is that of a Food Establishment whose manager decides to apply
a KM strategy of collecting recipes from the hired chefs in the form of a model base
that can be later consulted, analysed and transferred to other human resources (cooks,
future chefs). The role of modelling in KM was discussed in deep detail in [
The conceptualisation effort starts with imagining how a diagram describing a cooking recipe should look. Intuitive mock-ups such as the one in Fig. 2 (bottom) are created on blackboard or with Powerpoint, then the types for each diagram element are collected in the "language terminology" layer (top of Fig. 2). The mock-up shows a cooking recipe described as a linear chain of cooking steps, with the Start and Stop clearly distinguished. To enrich the KM value of a recipe (i.e., semantic richness), each step is attached to requirements for an ingredient, a tool and/or further documentation support (e.g., a video showing how to perform the step).
After the types for mock-up elements are collected at metamodel level, the notion of (abstract) syntax is introduced and minimally exemplified through domain and range constraints for visual connectors – i.e., what types of elements should be connected by each type of connector. Students are already accustomed from natural language grammar (or from programming "syntax errors") that syntax governs the structure of sentences/statements and the order of their constituents. In conceptual modelling, the domain, range (and cardinality, to be introduced later) dictate the order in which elements of different types can be connected in models. Unlike natural language where words are linearly juxtaposed (e.g., left-to-right), in models the elements are connected in a graph expanding in all 2D directions. Model elements are presented as "words", models as "phrases", and the metamodel as "the language terminology" ("vocabulary", "dictionary"). The analogy with natural language facilitates to bring all students to a common level of understanding without resorting to the specialised jargon of metamodelling (as homework, they are also asked to organise the metamodel as a UML class diagram). Since some relations may connect multiple types of elements, those types are unified under common generalised superclasses presented as "uninstantiated concepts" - i.e., concepts that will not be directly instantiated in models (i.e., no graphical symbol will be devised for them) but are nonetheless useful as a generalisation mechanism. They allow, for example, the SEQUENCE relation to connect elements of any of the types START, STOP or COOKING STEP.
The next building block that is introduced is the notation (concrete syntax) – i.e., a
graphical symbol is attached to each concept and relation. Syntax and notation are
implemented in tandem to obtain a usable modelling tool, based on the ADOxx
platform [
Semantics is dominantly understood as the meaning that a user assigns to (or
understands from) a model, primarily through labels. However, this is a drastically
reductive viewpoint that stands behind the "modelling is drawing" understanding. Even
under this understanding, (i) graphical shapes should not be arbitrary shapes (see the
works of Moody on notational qualities [
Fig. 4(a) shows an explicit example of such a schema for one of the language terminology concepts (COOKING STEP), thus introducing a clear notion of domainspecificity manifesting on semantic level. Based on the machine-readable semantics (induced by either conceptional schema or by syntax), model query functionality can be developed. A simple query builder is automatically generated by ADOxx (Fig. 4(b) and Fig. 4(c)) and additional functionality is implementable with the help of its internal programming environment (ADOScripts).
Finally, the last building block of a modelling method – the procedure is introduced as a human-oriented (documented or assisted) process of creating models that are adequate for some targeted purpose. This also creates the opportunity of discussing the notion of correctness, emphasising the following: • the relativity of model correctness to purpose – i.e., a process simulation algorithm would require more constraints than the model query functionality, and possibly even more concepts (e.g., decisions) or properties (e.g., probabilities); • the variety of means for enforcing correctness: (i) at interaction level (i.e., when the modellers tries to create an invalid element); (ii) at saving time (i.e., a global check is applied only when saving); (iii) through fully customised functionality (e.g., checking properties of the conceptional schemata); (iv) through procedural guidance (i.e., leaving the user interaction unconstrained but providing assistance and documentation).
Fig. 4. Conceptional schema of COOKING STEP instantiated for the "Prepare Dough" step (a), model query that uses this schema (b) and model query that uses only the syntax (c) 4.3
The agility quality for modelling methods is introduced in tight relation with that of modelling requirements – i.e., requirements that are specifically targeted to the mentioned building blocks. This section only briefly suggests several increments driven by assumed requirements. Table 2 summarises these requirements and the associated increments, while Fig. 5 shows how the evolved version of the modelling language looks after these increments are applied.
Fig. 5. Model examples according to the evolved version of the modelling language
The DOCUMENTATION concept was created to offer concrete documents (videos, Web pages, PDFs etc.) that describe how to perform a certain cooking step. Therefore it makes more sense to use addressable documents directly linked to model elements.
Functionality to compute total ingredient cost is needed, based on prices and quantities required along a cooking recipe model.
Domain-specificity, which currently manifests on a semantic level, should also be reflected in notation.
The relations between a cooking step and its ingredients, tools or documentation are differentiated. This distinction may be ensured either by (i) specialising the REQUIREMENT relation for each type of required thing or by (ii) replacing some of its specialisations with hyperlink (see next row).
A separation of concerns can be obtained by splitting the modelling language in two types of models: one that describes strictly the recipe (order of steps) and one that catalogues the resources required for recipes. Consequently, the REQUIREMENT visual connector will be replaced by hyperlinks that communicate relations on an interaction level (and through visual anchors rather than connectors). The DOCUMENTATION concept will be completely removed from the language terminology. Instead, a dedicated hyperlink will be added to the COOKING STEP concept. Prices may be added to the conceptional schema of INGREDIENT, but quantity is not a property of ingredients, it is a property of the relation between COOKING STEP and INGREDIENT. Since we decided above that this relation will not be a visual connector anymore, but a hyperlink, a tabular property is necessary to attach attributes to the hyperlink. Once the new properties are made available and filled with values, a menu item will be added to perform the required calculation with the help of the internal scripting language of ADOxx (and the procedure will be updated to teach users how to use it).
The modeller should have the freedom of selecting preferred icons for the required tools or ingredients. Domain-specific information, based on the properties in the conceptional schema, should be communicated through visual cues and hyperlinks that are interactive directly on the elements' notation. 5
Table 3 reflects on the teaching goals formulated in Table 1 and indicates the explicit means of pursuing them, directly illustrated and commented upon during the students' hands-on experience discussed in the previous sections. In the following, a SWOT analysis summarises the reported experience and its learned lessons:
Strengths: The proposed modelling method has the following teaching qualities: (i) minimalism and ease of implementation (reduced repetitive tasks); (ii) it reveals the notion of modelling method as a Design Science artefact; (iii) it is detached from software engineering and is domain-specific without requiring prior domain expertise; (iv) it relies on free tooling towards deploying a usable result in which students can relate their modelling effort to the design decisions on which it is based.
Weaknesses: When presenting their own homework projects, all students reported process-centric methods. This is due to the behavioural focus of popular modelling languages (BPMN, Petri Nets, EPC etc.), which is also central to the showcase method example. A false impression was created, that any modelling method should depict behaviour. It is therefore necessary to complement the showcase method with others that share its meta-qualities while avoiding behaviour modelling (i.e., limited to rulescentric or dependency-centric model types) in order to further push the lateral thinking that is stimulated through this teaching case.
Issue C: Understanding the semantics of "semantics" Approach: Distinguishing explicitly between human interpretation (label-based or graphics-based) and machine interpretation (based on conceptional schemata and their editable properties to support model queries) Issue D: Understanding "model correctness" Approach: Revealing a multitude of means for ensuring correctness relative to the purpose of models: (i) metamodel constraints vs. programmatic constraints, (ii) UI event-based checking (during modelling actions) vs. global model checking, (iii) syntactic constraints vs. semantic constraints.
Issue E: Understanding the application domain of conceptual modelling Approach: Targeting an application domain far detached from software engineering concerns (and revealing that software engineering is itself an application domain).
Issue F: Understanding agility at "modelling method level" Approach: Taking an iterative and incremental approach to deploying a modelling method while emphasising its status as a requirements-oriented Design Science artefact.
Issue G: Low awareness on conceptualisation activities Approach: Creating awareness on the conceptualisation phases leading to the modelling software implementation.
Opportunities: By decoupling conceptual modelling from software engineering, students are stimulated towards lateral thinking and the ability to devise and use modelling methods for domain-specific goals (e.g., business model evaluation, service/value designs). They can transfer their expertise and learned lessons to arbitrary other Business Administration domains (accounting, marketing, management), to develop modelling methods for student projects or theses that are not necessarily subordinated to business informatics.
Threats: Preconceptions and a narrow end-user perspective pose default resistance against the notion of modelling method agility and domain-specificity. A particular threat is raised by how conceptual modelling is introduced to students as subordinated to software development goals and processes. Common practices around the local industry also show (i) a limited goal of models as graphical documentation (lack of awareness on the notions of user-centric modelling goals and modelling requirements); (ii) limited practice and understanding of modelling methods (e.g., Powerpoint drawings with UML shapes rather than UML modelling per se); (iii) lack of awareness on conceptualisation efforts and design rationale underlying any modelling method.
As the discussed teaching goals indicate, the work at hand contributes to devising effective means for teaching conceptual modelling as a design paradigm for knowledge capture rather than as a practice subordinated to popular use cases or application domains (e.g., software engineering).
The challenge of "how can conceptual modelling education be improved?" is
become more relevant in recent years – see the position statements in the panel
discussion summarised by [
The proposed teaching case aims to stimulate design thinking as a necessity for any
conceptual modelling effort, while also fostering creativity in the sense discussed by
[
The authors of [
The paper reported on the teaching experience and design rationale aimed to establish a strong foundation for Business Information Systems master students in understanding the modelling method concept from multiple perspectives – as a Design Science artefact; as means of knowledge externalisation; as an evolvable artefact, adaptable to any domain-specificity; as having a usable manifestation in the form of modelling software. A showcase modelling method for Cooking Recipes was analysed through the lens of the Agile Modelling Method Engineering framework. The teaching goals and means to achieve those goals were analysed in a granular way, relative to the starting state of affairs (initial student understanding and profile). Future work will refine the discussed artefact towards non-behavioural types of models in order to further generalise the learned lessons.