Pattern Language

We describe in the following our pattern language for context-patterns, which is shown in detail in this publication. In addition, we working on further publications to describe further details of our pattern language.

Patterns (Vocabulary)

We analyze which elements and concepts we used in our context-patterns. Further, we described the relations between the identified elements and concepts in a meta-model in the following and we show how to describe a context-pattern using the meta-model. We claim our meta-model contains the vocabulary for our pattern language.

Connections between Patterns (Syntax)

We analyzed the relations between our context-patterns. Context-patterns can refine each other. Moreover, the domain knowledge elicited and stored in one context-pattern can be used by another pattern as input. This requires that both patterns are combined in a new method and that their elements have to be mapped. We showed how this can work in by combining the cloud system analysis pattern with the law pattern adding a new method.

Connections between Problems and Solutions (Grammar)

Our context-patterns each address a particular problem and have a method that states how to solve this problem. Hence, we do not have explicit sections for problems and solutions in our context-patterns, but we describe them combined in the introduction texts of each method. Moreover, describing the solution in a method provides engineers with descriptions of how to apply the solutions. Furthermore, if a pattern shall support a different solution, its method has to be adapted.

A Meta-model for Context-Pattern

In the following, we present a meta-model for building context-patterns that consider domain knowledge during the analysis phase of software engineering. We consider different kinds of domain knowledge, e.g., technical domain knowledge. Therefore, we use a bottom-up approach, starting with a set of previously and independently developed context-patterns. We identify the common concepts in our existing context-patterns, and aggregate this knowledge into a meta-model of elements one has to talk and think about when describing a new context-pattern.

This is quite similar to what Jackson proposed for requirements. He defined a meta-model of reoccurring domains, like causal, biddable and lexical domains. These domains are used to define basic requirements patterns, so-called Problem Frames.

In this work, we show a similar meta-model for context-patterns. We show how we derived it from already existing context-patterns and how it can be used to describe the structural part of a new context-pattern. This meta-model has several benefits. First, it forms a uniform basis for our context-patterns, making them comparable. Second, findings and results for one pattern can be transferred to the other patterns via a generalization of meta-model elements. Third, the meta-model contains the important conceptual elements for context-patterns. Fourth, it enables us to form a pattern language for context-patterns. However, in this work we focus on the aspects of the meta model which create the basis of a pattern language for context-patterns.

Using this meta-model we empower requirements and software engineers to describe their own context-patterns, which capture the most important parts for understanding the context of a system-to-be. The meta-model was derived in a bottom-up way from the different patterns we described independently for different domains. For the process of deriving the general elements, which then form the meta-model, we started to analyze each context-pattern in isolation. For each element in a context-pattern we discussed what the general concept behind this element is or if it is a general concept in itself. Therefore, we set up a table containing the elements of the current pattern to be analyzed as rows and the conceptual elements as columns. For each concept found we checked if this concept was already covered in the table or not. In the case it was already covered, we only added a cross to the table. In the case the concept was not covered by a conceptual element, we added a new column. After iterating over the elements of the pattern, we did a second step by adding the found conceptual elements as rows and analyzing for each of them if they could be further generalized in a reasonable way or not. This way we also found new conceptual elements. Hence, we had to do the second step several times. If nothing new was found, we finished the analysis. This way, we obtained the conceptual elements which were candidates for the meta-model.

One table shows the result of our work for the SOA pattern. In this case, we analyzed two context-patterns in conjunction, because the stakeholder SOA pattern reuses many elements of the SOA layer pattern. In a next phase we harmonized the conceptual elements by comparing the found elements, merging them if needed and setting up their relations. This way we got a coherent set of conceptual elements over all patterns.

In the last phase we had to choose which conceptual elements should be part of the meta- model. Another table shows the conceptual elements and in which of the patterns a corresponding element exists. Additionally, we selected for each pattern those elements which were not explic- itly part of the pattern and checked if the missing element is an implicit part of the pattern. Patterns can focus on organizational or technical views. Technical views concern mainly ICT elements of a system and organizational views focus on stakeholders, activities, and business processes in relation to a system.

We stated in the first table for each pattern if it focuses on an organizational or technical view or both. This is important to consider because there might be elements which only occur in one of the views. The general rule to include an element into the meta-model was to add every element with an occurrence greater than three, which means the element occurs in more than half of the patterns. In addition, elements that occurred two times in either an organizational or technical view were discussed and also included into the meta-model if we decided these are relevant elements for the particular view.

In general, most decisions did not require discussions. However, for the conceptual elements requirement and machine we required intensive discussions. We had to discuss the conceptual elements requirement and machine. We discovered that the machine is part of all patterns that consider the technical and the organizational views. Hence, we decided to include the machine into the meta model. Our experience with context-patterns supports this decision. This experience includes context-patterns that we currently describe. We also discovered that the context-patterns with only technical view consider the machine implicitly. For example, for the SOA Layer pattern the machine is not an explicit model element, but the extension to the Stakeholder SOA pattern shows that elements of the SOA layer pattern directly relate to the machine. We also discussed the requirement element and decided not to include it into the meta-model. The reason is that we do not want to enforce the consideration of requirements in context-patterns. This should remain optional. They should be included if the method in the context-pattern needs them, which is the case for the P2P pattern and the Law Pattern. Finally, we formed the meta-model as depicted in Fig. 10.1 out of the selected conceptual elements. The meta-model was modeled using the UML notation.

The root element is the Pattern itself. Each pattern contains at least one Area. In general, an area contains elements of either a technical or organizational view. An area can contain other areas, which do not need to be the same view. An area can concern either a Machine, i.e., the thing to be developed, an Environment, which in turn contains elements that have some kind of relation to the machine, or a Layer, which encapsulates a set of elements.

The environment can be further refined. There are elements which directly interact with the machine, captured in the Direct Environment. And there are elements which have an influence on the system via elements of the direct environment, captured by the Indirect Environment.

An element which is part of an Area can be a Process, a Stakeholder, or a Resource. A process describes some kind of workflow or sequence of activities. Therefore, it can contain Activities. A stakeholder describes a person, a group of persons, or organizational units, which have some kind of influence on the machine. A stakeholder can be refined to a Direct Stakeholder who interacts directly with the machine, and an Indirect Stakeholder who only interacts with direct stakeholders but has some interest in or influence on the machine. A Resource describes some physical or non-physical (e.g., information) element which is needed to run the machine or which is processed by the machine and which is not a stakeholder.

A resource can be an Active Resource with some behavior or a Passive Resource without any behavior.

This meta-model has several benefits. First, it forms a uniform basis for our context-patterns, making them comparable. If a method already makes use of one of the patterns, it is now easy to generalize the usage to the elements of the meta-model. This enables one to replace a given used pattern by another one easily. Second, findings and results for one pattern can be transferred to the other pattern via a generalization to the meta-model elements. Third, the meta-model contains the important conceptual elements for context-patterns. Thus, it is helpful to know these elements and search for them in a specific domain when setting up a new context- pattern for a domain. Fourth, it enables to form a pattern language for the context-pattern. The common meta-model eases relating the patterns to each other.

Relations between existing Context-Patterns

We defined relations between our patterns and identified the following kinds of relations: refines The refines relation describes that one pattern refines another pattern or parts thereof. For example, one pattern can refer to services, while another describes how these services are composed. input The information contained in the instantiation of one pattern can be the input for another pattern. For example, our law pattern can use the information of other patterns to identify relevant laws. We show how the information in the cloud pattern can be used as scenario description for the law pattern. We describe each relation using a template that states first the Direction of the relation, second the Relation Type, and third the Reasoning why the relationship holds. Relations between patterns can consist of several relations.

We present an overview of all defined pattern relations in the following tables. The table shows relations from a pattern in the horizontal to a pattern in the vertical axis. The fields of the table refer to the relation types defined in the beginning of this section. We marked all fields that do not contain a relation with a “–” symbol. Further relations may exist, but at this point we have not identified them. We have presented an initial step for creating a pattern language for context patterns, which provide a structured means for eliciting domain knowledge. This step is creating a meta-model for context patterns and identifying relations between context-patterns.