Pattern Catalog

We illustrate several examples of context patterns in the following. Note that we show only short versions of our context-patterns. For the full versions we refer to our Publications.

P2P pattern.

Our P2P pattern is based upon a previously introduced P2P architecture, which is derived from a survey of existing P2P systems. This survey describes P2P systems as layered architectures that contain at least the following layers. The Application Layer concerns applications that are implemented using the underlying P2P overlay, for example, a Voice-over-IP (VoIP) application. The Service Layer adds application specific functionality to the P2P infrastructure, for example, for parallel and computing-intensive tasks or for content and file management. Meta-data describe what the service offers, for instance, content storage using P2P technology. Service messaging describes the way services communicate. The Feature Management Layer contains elements that deal with security, reliability and fault resiliency, as well as performance and resource management of a P2P system. All these aspects are important for maintaining the robustness of a P2P system. The Overlay Management Layer is concerned with peer and resource discovery and routing algorithms. The Network Layer describes the ability of the peers to connect in an ad hoc manner over the internet or small wireless or sensor-based networks.

Cloud Pattern.

We also briefly introduce our cloud pattern. A Cloud is embedded into an environment consisting of two parts, namely the Direct System Environment and the Indirect System Environment. The Direct System Environment contains stakeholders and other systems that directly interact with the Cloud, i.e., they are connected to the cloud by associations. Moreover, associations between stakeholders in the Direct and Indirect System Environment exist, but not between stakeholders in the Indirect System Environment and the Cloud. The Cloud Provider owns a Pool consisting of Resources, which are divided into Hardware and Software resources. The provider offers its resources as Services, i.e., IaaS, PaaS, or SaaS. The Pool and Service do not require instantiation. Instead, the specialized cloud services such as IaaS, PaaS, and SaaS and specialized Resources are instantiated. The Cloud Developer represents a software developer assigned by the Cloud Customer. The developer prepares and maintains an IaaS or PaaS offer. The IaaS offer is a virtualized hardware, in some cases it is equipped with a basic operating system. The Cloud Developer deploys a set of software named Cloud Software Stack (e.g., web servers, applications, databases) into the IaaS in order to offer the functionality required to build a PaaS. In our pattern PaaS consists of an IaaS, a Cloud Software Stack and a cloud programming interface (CPI), which we subsume as Software Product. The Cloud Customer hires a Cloud Developer to prepare and create SaaS offers based on the CPI, finally used by the End Customers. SaaS processes and stores Data input and output from the End Customers. The Cloud Provider, Cloud Customer, Cloud Developer, and End Customer are part of the Direct System Environment. Hence, we categorize them as direct stakeholders. The Legislator and the Domain (and possibly other stakeholders) are part of the Indirect System Environment. Therefore, we categorize them as indirect stakeholders.

SOA Pattern.

Our SOA patterns concerns domain knowledge for Service-Oriented Architectures (SOA). A SOA spans different layers, which form a pattern on a SOA with technological focus. The first and top layer is the Business Domain layer, which represents the real world. It consists of Organizations, their structure and actors, and their business relations to each other. The second layer is the Business Process layer. To run the business, certain Processes are executed. Organizations participate in these processes. These processes are supported by Business Services, which form the Business Service layer. A business service encapsulates a business function, which performs a process activity within a business process. All business services rely upon Infrastructure Services, which form the fourth layer. The infrastructure services offer the technical functions needed for the business services. These technical functions are either implemented especially for the SOA, or they expose interfaces from the Operational Systems used in an organization. These operational systems, like databases or legacy systems, are part of the last SOA layer at the bottom of the SOA stack. These layers form a generic pattern, the SOA layer pattern, to describe the essence of a SOA.

We adapted problem-based methods, such as problem frames by Jackson, to enrich the SOA layer pattern with its environmental context. The white area in the figure 2 spans the SOA layers that form the machine. The business processes describe the behaviour of the machine. The business services, infrastructure services, components, and operational systems describe the structure of the machine. Note that the business processes are not part of the machine altogether, as the processes also include actors which are not part of the machine. Thus, the processes are the bridge between the SOA machine and its environment. The environment is depicted by the grey parts in the figure. The light grey part spans the Direct Environment and includes all entities, which participate in the business processes or provide a part, like a component, of the machine. An entity is something that exists in the environment independently of the machine or other entities. The dark grey part in the figure 2 spans the indirect environment. It comprises all entities not related to the machine but to the direct environment. The Business Domain layer is one bridge between the direct and indirect environment. Some entities of the Direct Environment are part of organisations. Some entities of the Indirect Environment influence one or more organisations. The machine and the Direct Environment form the inner system, while the outer system also includes the Indirect Environment. The entities we focused on for the stakeholder SOA pattern are stakeholders, because all requirements to be elicited stem from them. There are two general kinds of stakeholders. The direct stakeholders are part of the direct environment, while the indirect stakeholders are part of the indirect environment. We derived more specific stakeholders from the direct and indirect stakeholders, because these two classes are very generic. Process actors and different kinds of providers are part of the direct environment. Legislators, domains, shareholders and asset providers are part of the indirect environment. In the figure the resulting stakeholder classes are depicted as stick figures.

Patterns for Requirement-Based Law Identification.

We consider legal domain knowledge using a set of law patterns. Commonly, laws are not adequately considered during requirements engineering. Therefore, they are not covered in the subsequent system development phases. One fundamental reason for this is that involved engineers are typically not cross-disciplinary experts in law and software and systems engineering. To bridge this gap we developed law patterns and a general process for law identification which relies on these patterns.

We investigated how judges and lawyers are supposed to analyse a law, based upon legal literature research. These insights lead to a basic structure of laws and the contained sections and how they relate to the context of a system-to-be in terms of requirements. One result of our investigations is a common structure of laws. Based on this structure of laws, we defined a law pattern (see figure). Every dictate of justice as part of a law states that every Addressee who avoids or accomplishes a certain Activity which influences a Target Subject or a Target Person, to which an Individual (Target Person) is entitled to, has to comply with law. This information forms the Law Structure. The artefacts of the Law Structure are generalized in the Classification part. The addressees of this section are specializations of Person Classifier, the activities of Activity Classifier, the target subject of Subject Classifier, and the target person of Person Classifier. A Law itself is enacted by a legislator for a Domain and related to other laws (Law Pattern).

To determine the legal context of a system the requirements have to be related to the law pattern. Therefore, we developed the law identification pattern (see figure). First of all, a Requirement can be related to other Requirements and dictates a certain behaviour of the machine. A behaviour can be a certain Activity or a whole Process. A Process consists of different Activities. An Activity involves an Active Stakeholder and in some cases an Asset. Additionally, an Activity influences a Passive Stakeholder in a direct way or indirect through an Assets which is entitled to the Passive Stakeholder. In addition, Assets can be related to each other, for example, one Asset is part of another Asset. All these relations also have to be discovered and documented. They form the Core Structure of the law identification pattern. Finally, the gap between the terms and notions of the technical world and the terms and notions of the legal world has to be bridged. Therefore, the parts of core structure have to be classified using the terms of the legal world. And the context in means of Countries and Domains the system will operate in has to be set up.