A context-pattern consists of the following parts:


A method contains a sequence of steps. Each step is described using well defined activities, inputs, and outputs. Inputs are descriptions of the required artifacts to perform the activities of the method step. Activities are descriptions of the processing of all inputs into outputs. Outputs are the desired results of the activities of this step. A context- pattern has to contain a method that describes how to use the context-pattern.

Graphical pattern

Our context-patterns do not enforce considering the machine meaning the thing we are going to build explicitly, but demand a description of its environment in graphical form. This environment contains domain knowledge. In particular, any given environment considers certain elements, e.g., stakeholders or technical elements. Moreover, we believe that every environment of a software engineering problem can be divided into parts that have direct physical contact with the machine and parts in the environment that have an effect on the machine without physical contact, e.g., laws. These relations between the environment and the machine have to be part of the graphic, as well. A context-pattern has to contain at least one graphical pattern. We use a UML-based notation for our graphical patterns that uses, e.g., stick figures for actors, but we also use notation elements that are not part of the UML such as rectangles that symbolize an environment, and all elements in the rectangle belong to this environ- ment. We explain the concepts that we use in all our graphical patterns in Chapter 10 in detail. This is part of the effort to create a pattern language for context-patterns. Never- theless, we show in Sect. 9.3.5 that a mapping from our graphical patterns to a model in strict UML notation is possible.


Templates contain additional information about elements in the graphical pattern. For example, a graphical pattern contains a graphical figure of a stakeholder and a corre- sponding template for the stakeholder can contain, e.g., the motivation of the stakeholder for using the machine and the relations to other stakeholders. Templates provide the means to attach further information to the graphical pattern. The reason for adding this refinement in a template and not in the graphical pattern is not to overload the graphical pattern with too many elements. Templates are optional elements of context-patterns, because not all graphical patterns require a refinement. In addition, it is possible to attach diagrams to our context-patterns, e.g., UML activity diagrams that refine interactions between different stakeholders of a context-pattern. These diagrams can support different views and levels of granularity. All these diagrams are based upon our patterns. Hence, we can apply consistency checks and traceability links with the elements in the attached diagrams and the created patterns.

Moreover, the domain knowledge elicited using our patterns is not limited to software engineering. We showed that the knowledge can also support the establishment of security standards of the ISO 27001 standard e.g. in this publication.