Motivation

The Need for Conceptual Models

Software systems are linguistic artefacts. Designing, implementing and using them requires languages. For a software system to be executable, the concepts of language for describing software need to be mapped to the instruction set of processors. Furthermore, the description should be sound in order to foster the software’s reliability. That recommends the use of formal languages. However, formal languages are not sufficient. To make sense of a software system, a linguistic representation is required that corresponds to the language common in the targeted domain.

Conceptual modelling is the approach of choice to establish a correspondence between implementation languages and technical languages used in certain domains. It is based on the idea to use a common ontological foundation both for programming languages and for the reconstruction of domain-specific natural languages. Furthermore, the correspondence depends on common domain-specific designators used for naming concepts in conceptual models. As far as the common ontological foundation is concerned, basic concepts such as entity type, thing, property, event etc. are a good choice. They are used both in philosophical ontologies such as in Bunge’s “furniture of the world” (ref) and in conceptual modelling languages like the ERM or state machines. This common foundation of two separate language worlds enables to create a bridge between them – through conceptual models.

The Object-Oriented Paradigm: Strengths…

During the last decades, one particular language paradigm has gained outstanding relevance. Object-oriented programming languages allow for abstracting the cryptic representation of machine languages away and provide programmers with concepts such as class, object, attribute, etc. At the same time, these concepts form the linguistic foundation of object-oriented modelling languages. Since they correspond to basic concepts of philosophical ontologies, they are suited to reconstruct natural language descriptions of the domain a software system is supposed to represent. Hence, object-oriented models are enabled by two lines of abstraction: on the one hand, there is abstraction from machine code. On the other hand, there is abstraction of natural language descriptions that fades out irrelevant aspects and removes ambiguities.

^{Animation: Object-oriented conceptual models}

The object-oriented paradigm does not only foster the correspondence between natural language and program code, it also contributes to reuse and flexibility of software artefacts by providing powerful concepts such as classification, encapsulation, generalization/specialization and polymorphism.

… and Limitations

The clear benefits of the object-oriented paradigm are contrasted by two limitations, which may not be obvious at first sight, but have a serious impact on the usability of object-oriented languages. While it may be regarded as convenient that “the objects are there for the picking” (Bertrand Meyer), a language that offers primitive concepts like class and attribute only is a threat to productivity (imagine you would have to read a text like this where every concept was defined from scratch using class, object, attribute etc only) and integrity (an object can be anything, while more specific concepts constrain the number of meaningful sentences they can be used in). This limitation has been known for some time. It inspired the introduction of domain-specific modelling and implementation languages (DSML, DSL), which include domain-specific concepts. Therefore, a modeler or programmer does not have to build these concepts from scratch, but can use them directly.

The second limitation is not necessarily inherent to object-oriented abstractions per se, but to the dominating paradigm of object-oriented programming and modelling languages. According to this paradigm, an object-oriented system is characterized by the dichotomy of objects and classes. A class can be thought of as a template that serves to create objects of a certain kind. As a consequence, a class does not have a state and cannot execute methods. This strict dichotomy of objects and classes has been softened to some extent. To specify classes, a further language level with metaclasses has been introduced. Accordingly, meta-modelling tools allow for the construction of metamodels, which can be instantiated into models that consist of classes or types. However, these extensions did not remove one principal restriction of most object-oriented systems: one system may include objects and classes only, where classes do not have a state. In case of a meta-modelling tool, classes are actually represented as objects, that is, the object layer is overloaded. From a logical point of view, it does not seem convincing to restrict classes to templates only and to limit the representation of software systems to two levels of abstraction (objects and classes) only. Instead, it seems more reasonable to enrich the concept of class to allow for state and the execution of methods:

• Specific properties: a class has a certain creation time, it was created by somebody, it may represent a certain version …
• Specific values of properties that are shared by all instances of a class, e.g. the resolution of all screens of a certain kind.
• Properties that depend on the instances of a class, such as the number of instances, or the average value of a certain property. To avoid redundancy, these properties should be calculated dynamically, which recommends to enable classes to execute methods.

It seems like an arbitrary decision to limit software systems and conceptual models to one classification level only. Classification is a powerful abstraction that enables us to express knowledge about an entire set of objects. Why should we not be allowed to express the knowledge we have knowledge about a set of classes – or meta-classes – accordingly by using further levels of classification?

Motivating Problems (Video)

This video was produced for the lecture “Enterprise Modelling II” in the Masters programme “Wirtschaftsinformatik”. It serves illustrating the motivation for multi-level modelling by pointing at various serious problem related to the traditional paradigm.

 

References