1 Introduction

Model-based approaches have proven to be useful for developing interactive systems [12]. However, creating models is still challenging. Even with tool support modeling of real world problems is still time consuming an error prone.

The number of errors can be reduced if existing building blocks can be assembled that have proven to be useful in other projects. This phenomenon is well known from programming. The reuse of already tested code fragments is very helpful to improve the quality of software. For programming subroutines, templates, macros, components, and patterns are known concepts to reuse already specified knowledge.

There have been attempts to apply similar ideas to specifications describing the activities of humans in form of task models or workflow specifications. We will have a look at such approaches and try to harmonize the terminology.

The paper is structured in such a way that reuse of task models and reuse of workflow specifications are revisited and discussed separately. Afterwards, it is tried to find a common terminology in a kind of ontology. The paper ends with a summary and an outlook.

2 Reuse of Models

From our point of view, the reuse of models in general is best supported by Design Patterns [11]. They allow the reuse of modeling knowledge on an abstract level. First, a submodel has to be identified that is a candidate for a pattern application. After a pattern was identified that is appropriate, the solution has to be adapted to the context provided by the submodel. An instance of the pattern is created that is ready for integration (application). The four application steps of design patterns can be formalized in the following way.

  1. 1.

    Identification: A subset M’ of the original model M is selected for pattern application \( {\mathbf{M}}^{{\prime }} \subseteq {\mathbf{M}} \)

  2. 2.

    Selection: A pattern P is selected that can be usefully applied to M’

  3. 3.

    Adaptation: The pattern P is adapted to the current context C of M’. As a result a pattern instance I is delivered. \( {\mathbf{A}} \, \left( {{\mathbf{P}},{\mathbf{C}}} \right) \, = \, {\mathbf{I}} \)

  4. 4.

    Integration: The instance I is integrated into M’ \( {\mathbf{F}} \, \left( {{\mathbf{M}}^{{\prime }} , \, {\mathbf{I}}} \right) \, = \, {\mathbf{M}}^{{{\prime }*}} \) (which also changes M to M*)

Design patterns are generic solutions for reoccurring problems. UML provides a notation for applying design patterns. Figure 1 provides an example for that.

Fig. 1.
figure 1

Application of the GoF patterns observer

Full size image

Identification was performed by selecting the appropriate classes. Selection was done manually to insert the pattern symbol with the name observer. Adaptation is represented by the connecting arcs. In the above example, there are e.g. two concrete observers. Integration is not represented. The consequences of the pattern application have to be done manually. However, tool support is provided for pattern application in a different way by some case tools.

Additionally to the application of patterns, UML has a notion for generic classes. However, tool support is missing for presenting the resulting models in all case tools we know.

In the following two paragraphs, we will have a look at approaches applying ideas of patterns and genericity for models able to describe activities of humans.

2.1 Reuse for Task Models

In [3] the term task pattern was discussed the first time. However, it was defined as sub-tree only. Within the HAMSTERS environment ([9, 10]) this kind of reuse is called submodel.

The usage of generic task patterns was suggested in [7]. Tool support for task patterns was discussed in [13]. It was shown how generic task patterns were adapted to the context of use and inserted into a larger model. However, in both cases the substitution of parameter values was considered to be performed during design time only. In [5] the runtime substitution of parameter values was discussed the first time for such models. For those patterns, the notation of HAMSTERS was used that allows submodels, procedures, and conditional sub-trees.

To get an impression of the notation, we will specify an example that was given as introduction to BPMN modeling [1]. It originally specifies that it is noticed that somebody recognizes to be hungry. Groceries have to be acquired to be able to prepare the meal. After preparing the meal, it can be eaten. Afterwards, hunger is satisfied. Pre- and post-conditions are not visually represented in Hamsters. Therefore, the task model looks like the graphics presented in Fig. 2.

Fig. 2.
figure 2

Task model for overcoming hunger

Full size image

The presented model can be generalized in such a way that activities of thirsty people can be covered as well. The following generic task model component fulfills the mentioned requirements. It can be instantiated to models for hungry and thirsty people (Fig. 3).

Fig. 3.
figure 3

Generic component to overcome hunger or thirst

Full size image

Two parameters are used. The first one is called item and can have the values “groceries” for meals and “ingredients” for drinks. The second parameter result can have the values “meal” and “drink”. Instantiating the task component with “groceries” and “meal” results nearly in the original model. The only difference is the task eat meal that is generalized to consume meal to abstract eat and drink to consume. A further parameter could have been introduced to deliver exactly the original model.

Additional, to simply propagating values it is possible to make decisions based on these values during design time as well as during runtime. Within runtime, it can be decided, whether values for parameters are used at instantiation time or at decision time.

2.2 Reuse of Workflow Models

Van der Aalst et al. introduced 20 workflow patterns in [15]. Most of these patterns are discussed on a low level of abstraction (see also [16, 17]). They describe solutions for workflow patterns on the level of language features like sequences, alternatives, procedure, metaphors etc.

They are not on the level of describing something like buying or managing something. In [6] we introduced the concept of generic components for BPMN specifications. The hungry people example that was already used for task models [1] was generalized to a generic component. Figure 4 provides this example.

Fig. 4.
figure 4

Generic workflow component for supporting hungry or thirsty people

Full size image
Fig. 5.
figure 5

Instantiation and instance of a generic workflow component

Full size image

Parameter P1 is expected to have the values “thirsty” or “hungry”. The second parameter P2 specifies the required resources. It can have the values “groceries” or “ingredients”. The third parameter P3 specifies the wanted final result. The values could be “drink“ or “meal”. Figure 5 presents the component with parameter values “hunger”, “groceries”, and “meal” and the corresponding instance of the pattern with substituted parameters.

Hopefully, the selected example allows a good understanding of the idea and a good comparison of task models and workflow specifications. However, it might be too tiny to show the advantages of reuse of existing generic component.

Therefore, an example for ordering a pizza is recalled and generalized. The pizza that is ordered is represented by parameter <sthg> which stays for something. The term “Hungry for Pizza” is generalized to “Keen on <sthg>”. Correspondingly, “Hunger satisfied” is replaced by “Satisfied with <sthg>. Additionally, the roles “pizza customer”, “pizza vendor” and “pizza chief” are replaced by “<sthg> customer”, “<sthg> vendor” and “<sthg> creator” respectively. The resulting generic workflow component is presented in the following Fig. 6.

Fig. 6.
figure 6

Generic workflow component based on the pizza ordering example from [2]

Full size image

The generic workflow component allows not only the specification of ordering pizzas but also of sandwiches in a simple way.

Analysts or business process modelers have simply to instantiate the generic submodel accordingly by providing appropriate parameter values.

2.3 Discussion

Currently, generic components are implemented only for task models for the HAMSTERS case tool [8]. In a case study existing task models describing tasks for a ground segment application was reengineered.

The application is used to monitor and to control the Picard satellite that was launched in 2010 for solar observation. More details about the system are discussed in [5, 9, 10].

The task models became smaller and better readable. The identification of possible component applications allowed even to correct an existing modeling mistake.

Some statistical data are recalled in the following Table 1.

Table 1. Quantitative comparison of the approach (from [5])
Full size table

Using structuring mechanisms allowed to reduce the size of the specification by nearly 50 %. This makes us hope that workflow specifications can benefit in the same way. Their similarity was already discussed in [4].

The wording for the different technologies is quite difficult to follow. The term pattern e.g. is used quite differently. Within the context of workflow specifications, it is used quite specific. In the context of workflows, a sequence of actions is called a pattern [15]. This is quite different for task models. In the context of tasks, a pattern is considered to be something more abstract like buying something or running a shop. It is also considered to be generic [7].

While reviewing the models of an existing project we identified our generic task patterns as reusable submodels. They allowed us to model the project in a more compact and better readable way [5]. Our first submission used the term generic patterns.

However, reviewers complained that the identified generic submodels are too specific to be patterns. It was suggested to use the term generic component. Indeed our specified submodels are in no way general patterns that have to be taught to analysts. They are in some way similar to subroutines. In addition to subroutines of Hamsters, task names are not the same all the time. With respect to this aspect, the notion of a template describes the behavior in a better way.

However, templates assume to get all values for generic parameters at the same time. Most of the time this parameter substitution is performed during design time. This could be extended to instantiation time or even runtime. Nevertheless, the combination of value propagation during design time, instantiation time, and runtime is not part of the concept of templates.

Therefore, the term generic component was used in the implementation and in several publications.

Unfortunately, some aspects of the technology we are proposing do not fit to the concept of components. In fact, components support information hiding, which is not true for our ideas. There is one important aspect we want to support. Stakeholders should be able to see the instances of the so called generic component like in Fig. 5. Details of the execution should be visible and not hidden.

Therefore, the term generic submodel seems to be more appropriate than generic component.

Figure 7 provides the suggested ontology for reusable parts of models

Fig. 7.
figure 7

Suggested ontology

Full size image

From our point of view, generic submodels inherit all features from templates. Parameters can be used to specify any generic aspect. In this way, names of model elements can be adapted. The same is true for conditions or any expressions.

In addition, generic submodels inherit some features from components. Parameters can be instantiated at several stages of development and execution. However, information hiding is not inherited.

Generic submodels can be patterns. However, not all submodels are patterns. It depends on the level of abstraction and on the importance for general applications. There can be patterns for general solutions and domain-specific patterns that are important for reuse in a specific domain.

Additionally, there might be submodels that are important in a specific project. However, these submodels are not general or abstract enough to be considered as patterns. This is reflected by the inheritance relation from generic submodels to patterns. Specific submodels are patterns but not all of them.

However, patterns do not have to be submodels in the sense of templates and components. They can provide general ideas as well.

This reflected in our suggested ontology by providing inheritance from class generic solution to class pattern.

3 Summary and Outlook

This paper has discussed some strategies of reusing models. It started with the application of design patterns and generic classes for object-oriented class diagrams and continued with task models and workflow specifications describing activities of users. Such specifications are very important for human-centered design of interactive systems in general and for user interfaces in detail.

It was discussed, how terms like templates, components, submodels, and patterns are related to each other. It was suggested to use the term generic submodel in connection with tool support for task models because not all useful model fragments are patterns. Additionally, patterns do not have to be some kind of template, component, or submodel. They can provide more general and abstract ideas as well.

Additionally, it is important to notice, that users can be presented models with appropriate names and terms from the domain, that is modelled and that is familiar to the users. Names and terms are presented in a way they are used to. Models can be easily reused in a way that allows user friendly specifications.

Based on the experience with task models in Hamsters, an implementation of generic submodels is under development for a BPMN editor of an open source projects. Experiments with business process modelers have to show how predefined generic submodels are used.

Later, libraries of already specified submodels have to be created that support a good overview of the generic submodels. Additionally, they have to provide efficient search strategies.