Object-oriented programming has been around for more than 50 years and is now the most dominant style of programming. In recent years there has been an increasing criticism of object-oriented programming. Some people argue that the mainstream object-oriented languages do not capture the intentions of object-orientation as intended by its founding fathers. There are indeed issues with object-orientation as practiced by mainstream. In this essay, we identify a number of issues that we think are problematic. We argue that the primary reason for these issues is that reuse is considered the main advantage of object-orientation at the expense of modeling. We argue that modeling should be the main focus, that programming is modeling, and we describe a number of principles to follow when practicing object-oriented modeling.

In this paper, we present research on CoPI4P (Community of Practice & Interest for Purpose) communities that consist of knowledge and creative workers in domains such as education, environmentalism, inter-disciplinary research, engaged art, and practice F2V (face-to-virtual) processes, i.e. processes that consist of both face-toface and virtual (online) activities. Standards and methods for modeling business processes have successfully solved various crucial problems, such as providing boundary objects (or a common language) between business analysts, domain experts, process performers and business solutions developers. Performers can execute business processes with standards that support the execution of such processes. However, for CoPI4P communities, BPM standards 1) require additional domain specialization and 2) are either too imperative, or fail to provide enough guidance. This paper identifies these challenges and provides partial solutions applicable to modeling and supporting CoPI4P communities and the corresponding F2V business processes. In addition, results of focus groups interviews and surveys are provided that shed light, notably, on the way CoPI4P communities have been impacted by COVID-19 and how they have coped with digital disruptions to their working models. Our contribution to business processes management lies in researching and identifying the peculiarities of such communities and their workflows, followed by interventions in the BPM, and particularly the BPMN, domain. We then propose a toolset of BPMN extensions required to match the observed F2V workflows and thus to digitalize CoPI4P business models. In this context, we introduce the notion of sub-process palettes as a means to reduce the rigidity, and introduce personalization, of processes.

This paper discusses the term ’model’ and the role of the level M0 in the four-layer metamodeling architecture of MOF/OMG. It illustrates the failures of the OMG MOF standard and how a model is an abstraction, not a description. We apply two simple approaches: (1) observing the use of models (of real or planned systems) in system development, including prototyping, simulations, and models in general, and (2) comparing modeling with programming. These approaches lead to the conclusion that models should be placed on M0, while UML models are model descriptions. This conclusion leads to a better understanding of InstanceSpecification for description of snapshots, and of metamodeling applied to ontologies.

Modelling and Programming are often used together in system development. However, typically there is a large difference between the handling of modelling parts and the handling of programming parts. This leads to the fact that the transition between the two is not easy, and important information is lost as well as extra information has to be provided when combining modelling and programming. This paper shows how modelling and programming could work together in system development.

Most modelling languages support full state machine modelling, including especially composite states. Existing approaches to programming with states (state design patterns) either represent composite states by means of inheritance between state classes, or do not support composite states, and instead use inheritance for specialization of extensible state machines. In this paper, we present 1) a state design pattern using delegation to support composite states and inheritance together with virtual classes to support extensible state machines, and 2) a framework, implemented in Java, which also supports history and entry/exit actions. Together, these form the basis for developing support for state machines in a combined modelling and programming language.

An essential operation in model-driven engineering is composition of models and their metamodels. There exist several mechanisms for model composition. However, most of these only consider composition of either models or metamodels and not both kinds of models simultaneously, and do not address how the composition impacts modelling artefacts like editors, transformations and semantics. Moreover, model composition mechanisms typically deal with model structure and do not consider operational semantics. In this paper, we discuss a novel approach for the composition of both models and metamodels in a virtually non-intrusive manner. We achieve this by utilising a placeholder mechanism where classes in one metamodel may represent classes of another. The ideas presented have been validated by the construction of a framework. We will illustrate how non-intrusive composition allows linking the operational semantics of different languages without rendering existing modelling artefacts inconsistent. This increases the flexibility in how languages can be combined, and reduces the amount of necessary changes of tools and other modelling utilities.

In model-driven engineering, models are considered first-class entities. Model-driven engineering has been around for over a decade. Still, there has not been much work on how to type models or metamodels, which is important to realise true model-driven software development. In this paper, we discuss how a metamodel can be typed by means of an enclosing class whose state can be utilised by tools such as editors and interpreters. This allows using established object-oriented mechanisms on the metamodel level and supports specialisation of metamodels.

This paper discusses a class modeling approach for managing tool integration. Model concepts like Artifact and Role are introduced as integration backbones. Artifacts represent real artifacts like model elements that are maintained by tools. Different kinds of tools require different kinds of Artifact classes. The Role classes capture integration scenario-specific properties for Artifacts. As the same Artifact may be involved in different scenarios, and as integration scenarios may come and go, Roles can be dynamically attached to Artifacts. It is also demonstrated the possibility to model with Artifacts and Roles alone, without any real model elements. OSLC Web services (and as part of that, OSLC resources) are generated from these class models, and it is demonstrated that class modeling of Artifacts are superior to plain OSLC specification of resources.

This paper presents an extension of a previously presented tool integration approach: tool integration for different scenarios may be specified as integration models, and these integration models can be executed or form the basis of code generation for implementing integration on different platforms. Integration models cover both the data and behavior parts of tool integration. The benefits of separating the details of integration models from the models being integrated through tool integration are illustrated and it is indicated what a DSL for making integration models would be.

An important challenge in today's software development domain is to integrate diverse development tools. In this paper we present a method that combine various modeling languages which underline a set of steps for the purpose of specifying tool integration, and then establish tool chains above the Service cloud and provide these tools as Services. A case study from the embedded system development area is used to exemplify the method, highlighting the benefits and challenges of establishing tool chains above the service cloud.

Algebraic graph transformation has a wellestablished theory and associated tools that can be used to perform model transformations. However, the lack of a construct to match and transform collections of similar subgraphs makes graph transformation complex or even impractical to use in a number of transformation cases. This is addressed in this paper, by defining a collection operator which is powerful, yet simple to model and understand. A rule can contain multiple collection operators, each with lower and upper bound cardinalities, and the collection operators can be nested. An associated matching process dynamically builds a collection free rule that enables us to reuse the existing graph transformation apparatus. We present model transformation examples from different modeling domains to illustrate the benefit of the approach.

This paper presents a generic approach for automating the augmentation of product lines using model comparison and variability modeling techniques. Product lines are subject to frequent augmentation to include more products. Our approach aims to reduce manual effort involved in this process by automatically suggesting a tentative augmented product line model, which can serve as a baseline for the final product line. The Common Variability Language (CVL), a generic variability modeling language, is used to specify product lines in this approach. The approach applies CVL Compare, a generic approach for automating the synthesis of a CVL-based product line from a set of existing product models. The approach is illustrated with an example from a train control product line.

Existing approaches to tool integration based upon metamodels encounter the problem that common (integration) metamodels become too large and complicated, due to the large number of different tools that have to be integrated, each with their specific metamodel defining models handled by each tool. The approach taken here is radically different in that it distinguishes between the model for integration and the tool metamodels, and that it provides mechanisms by which the common integration model and the various tool metamodels can be related. In addition the integration model covers the need for expressing commonalities between models in different languages. Integration is done by means of Artifact resources that are representatives of the real models and model elements. Pure Artifact resources have properties that are required for simple tool integration like trace ability. In order to cover transformations, special Artifact resources for models and model elements in languages defined by metamodels will have properties identifying the metamodel of the language and the type of model element. In cases where integration is based upon concepts that are common to a set of languages, the common concepts are represented by roles played by Artifact resources, in general the same real model element may therefore play different roles for different integration purposes. The integration approach is validated by three experiments: trace ability, transformation, and common concepts for the purpose of software-hardware co-design. The approach is independent of specific implementation platforms. The paper demonstrates how the approach is realized based upon OSLC [24].

Existing tool integration approaches integrate various tools directly through tool proprietary APIs. This kind of integration lacks standardization and are different case by case. Integration based ...

We show how the effort needed to verify a transformed base model can be reduced by analyzing the definition of the modification. The Common Variability Language (CVL) is a generic language for modeling variability, where a CVL model describes the increment from one base model to another (transformed) base model. Assuming that a property of the base model has been verified, we use the CVL model to reduce the effort needed to verify the property of the transformed model. Based on the CVL model, we narrow down the set of traces required to be verified, including the increment and the cascading effects. We apply CVL to several models of the Train Control Language (TCL) to illustrate how the effort of verifying safety properties of transformed train station models can be reduced.

Current model-driven software product line development is mostly based on feature/variability modeling techniques, however, we see the potential for automatic assistance in identifying the commonality and variability of a set of models within the domain and synthesizing the product line model based on those. This paper presents a generic approach for synthesizing a software product line using model comparison. For model difference detection, the approach applies EMF Compare, a generic model comparison tool. For specifying the variability, the approach applies the Common Variability Language (CVL), a generic language for expressing variability. The SPL developer starts with comparing the existing potential product models in order to identify reusable assets (model fragments). Our tool prototype CVL Compare detects the difference between the existing product models and performs higher-order comparisons to explore the commonality and variability of the domain. Based on the comparison results, a preliminary product line model (CVL model) can be automatically induced and the SPL developer may further enhance the product line model. The approach is illustrated with an example of train control product line.

In addition to traditional object-oriented (OO) concepts such as inheritance and polymorphism, several modularization and composition mechanisms like e.g. traits, mixins and virtual classes have emerged. The Package Template mechanism is another attempt at providing a flexible mechanism for modularization, composition and adaption.

We show how a common language of variability can be used to enhance the expressiveness of a Domain Specific Language (DSL). DSLs have been proposed as a mechanism for expressing variability. Variability between models in a given domain or of a family of systems is captured by language constructs, implying that all possible models in this language are the allowed variations. We explore the possibility of expressing variability in a language independently of the base modeling language. We explore how this works for small DSLs as well as for general purpose languages like UML. Implications of this approach are that the variability language can be standardized, and that DSLs do not have to include variability mechanisms.

The decomposition of large systems into parts is a general principle of software design. Even more, in the scope of distributed systems, a partition of the whole system into distributable components is necessary. Decisions about what constitutes a component of a system are usually either based on the behavior or on the structure of the system. Nevertheless, there is a strong mutual influence between both kinds of decomposition. Despite the importance of structural and behavioral decomposition, many modeling notations and languages define the semantics of these concepts rather vaguely, and this may lead to incorrect implementation. This paper presents the new structuring mechanisms in the object-oriented specification and description language SDL-2000. The paper also gives a critical evaluation of these concepts and a comparison with similar approaches in UML (Unified Modeling Language) and ROOM (Real-time Object-Oriented Modeling).

The notions of class, subclass and virtual procedure are fairly well understood and recognized as some of the key concepts in object-oriented programming. The possibility of modifying a virtual procedure in a subclass is a powerful technique for specializing the general properties of the superclass.

The BETA programming language is developed as part of the BETA project. The purpose of this project is to develop concepts, constructs and tools in the field of programming and programming languages. BETA has been developed from 1975 on and the various stages of the language are documented in [BETA a].