Apply architecture patterns


Patterns are the embodiment of the structure and capabilities of other successful systems, represented in such a way that they can be re-applied into this system to obtain similar success.In DANSE, the methodology and tools provide the capability to create a repository of architectural patterns from any system or SoS, then to draw from that repository to enhance the current SoS model.Through analysis of the changed configuration, the SoS architect can determine whether the new pattern, as applied, will enhance the actual SoS.

The pattern repository is a database of known SoS and system patterns.The repository created during the DANSE project contains patterns observed in the SoS test cases used in DANSE, and is not intended to be a complete repository.Each SoS architect using the DANSE methodology may add to the repository, either a local version for local use or a public version for use by other architects.Addition of new patterns typically happens by “mining” the existing world and its knowledge.

DANSE provides the capability to search the repository based on key words that represent concepts in the patterns.When a key word matches, the SoS architect may explore the matching patterns for their applicability to the SoS.If a pattern appears to be useful, then the structures in that pattern are available as Rhapsody profiles that can be inserted into the SoS model.

Application of architecture patterns may be useful during the SoS initiation or creation phases, to develop a useful or enhanced model of the SoS that will act as a design template for changes to the constituent systems.Architecture patterns may also be useful during the SoS operation phase, to discover evolutionary changes to the SoS that can enhance its operation in desired areas.

Initial Situation

This solution method typically starts with an initial SoS model that has been created using the Model SoS solution method.There is a desire in the mind of the SoS architect to improve the model, and some concept for what is meant by improvement.

Expected Result

At the completion of this solution method, the SoS model has been changed to encompass a pattern that offers improvement in the areas of interest to the architect.Through simulation and statistical model checking, the changed SoS model has been tested to comply with the SoS goals and contracts while meeting the desired evolutionary performance.

Required Tools

The following DANSE tools are necessary to this solution method:

-       Rhapsody

-       Architecture Patterns

-       DANSE modelling extension profiles

Figure 43: Tool Flow: Apply Architecture Patterns


There are two entry points for the activities related to this solution method.One entry point (“Mine knowledge for patterns”) creates and enhances the patterns repository.The other entry point (“Model SoS”) applies to the use of patterns to enhance the SoS.Figure 44 depicts the flow of activities in the solution method, with both entry points.

Figure 44.  Activity Diagram: Apply Architecture Patterns

Mine knowledge for patterns

Applying architecture patterns can only be as good as the richness of the patterns repository allows.For best use, the repository should be enhanced on a regular basis to include any new patterns that are discovered.

Pattern mining is a “soft systems” art.The elements that make a pattern useful are the architectural structure, the capabilities, activities, and functions, and the performance of the pattern in terms of technical quality and emergent behaviours.Therefore, discovering new patterns involves interaction with the SoS users to determine the capabilities, activities, technical quality and emergent behaviour, as well as interaction with the SoS and CS architects to determine the architectural structure and the technical details of activities and functions.These interactions can often be performed through focus groups, with a qualified facilitator seeking to elicit the desired information.

The form of a pattern is given in D5.1 Reusable Architectural Patterns.  That form defines the information that should be mined during any work session.  The discovered patterns are entered into the repository using the Architecture Patterns tool, with UPDM structures created in Rhapsody as profiles to be stored with the pattern.

Model SoS

This activity is the solution method Model SoS that is described in section 5.1. The activity results in an SoS UPDM model in the Rhapsody tool. For the purposes of this solution method, that model is considered to be an “initial” model, to be improved by the application of patterns.

In some cases, during the SoS creation phase, there may in fact be no effective SoS model. In such a case, this solution method may be used to discover patterns that will be used to design the SoS in its initial state.

Identify desired improvements

In any phase of the SoS lifecycle, the SoS architect is interested in improving the SoS through adaptation or evolution. Improvements may be in capability, performance, cost, or other areas. There may also be time frames for the improvements. The architect must identify what improvements are desired, and what would be the measures of improvement.

Search patterns repository

Using the desired improvements, the architect searches the patterns repository using key words.The search may seek specific capabilities, specific performance parameters, specific structures, or improved cost.The architect uses the Architecture Patterns tool to perform the search, resulting in a list of patterns that include the key words used.The architect can then explore the found patterns to determine which of them might offer the benefits and improvements desired.

Useful pattern found?

Through the search, the architect may or may not discover a pattern within the repository that appears useful.If no such pattern is found, then the architect should revise the definitions of improvement and/or revise the key words used in the search.If an apparently useful pattern is found, then the architect should modify the SoS model to incorporate the pattern.

Insert pattern into SoS model

With a potentially useful pattern identified, the SoS architect will next explore a potential change to the SoS model. It is suggested at this point that such changes should be explored in a copy of the SoS model, so that multiple possible changes may be tried without modifying the base SoS model that represents the real SoS.

To insert the pattern into the model, obtain the UPDM structures of the pattern from the DANSE modelling extensions profiles for Rhapsody. The pattern will be a file of UPDM structures that can be added to the existing Rhapsody UPDM model. In most cases, however, applying a new pattern is not simply a matter of replacing diagrams; usually, it requires some “surgery” on the existing model to change it into the form of the pattern. This adaptation should be performed carefully to retain the essential characteristics of the pattern that lead to its success. The experience level of the architect will have a significant effect on the success of this adaptation.

However it is adapted, it is necessary for the SoS model still to retain the depth that supports joint simulation.  Block definition diagrams, internal block diagrams, activity diagrams, state machine diagrams, and sequence diagrams are key to the simulation.

Perform joint simulation

This activity is the solution method Perform joint simulation described in section 5.6.Joint simulation is necessary to evaluate the revised SoS model against the desired measures of improvement, to check its performance levels, to evaluate and discover emergent behaviours, and to facilitate statistical model checking.

Perform statistical model checking

This activity is the solution method Perform statistical model checking described in section 5.7.Statistical model checking is necessary to confirm that the new SoS model conforms to the goals, contracts, and performance levels desired.

New model improved?

The architect then evaluates the results of joint simulation and statistical model checking to determine whether the new SoS model is improved in the areas of interest over the original SoS model. In particular, the results should be examined for the following:

·  Improvement in the areas of interest

·  Compliance with necessary goals and contracts at SoS and CS level, with acceptable compromises where the there is conflict

·  Performance levels in other areas that are either (a) retained at original levels, (b) improved against the desires for those other areas, or (c) acceptable compromises against the gains achieved in the areas of interest.

·  Designed emergent behaviour that is either (a) improved over the original, or (b) acceptable compromise against the gains achieved in the areas of interest.

·  Newly discovered surprise emergent behaviour that is acceptable.

If the revised SoS model meets these criteria, then the architect can proceed to determine how to influence and implement the changes to the constituent systems. If the revised SoS model is not acceptable, then the architect must seek other patterns using the same or revised areas of improvement and key word searches.


The effectiveness of this solution method is highly dependent on the richness of the patterns repository.  Constant improvements of the repository are indicated.

The experience level of the architect is a key part of effectively applying any pattern into the model. The architect must be able to envision the appropriate “surgery” to apply the pattern within the model.

Follow-up Solution Methods

Given the limitations, it is natural to use Generate Optimized Architectures in conjunction with Apply Architecture Patterns and Generate Architecture Alternatives as alternative methods to explore architecture variations. Each of the three methods offers a different approach with different benefits and limitations.

It is already noted that the following solution methods are integral to this one:

·  Model SoS

·  Perform joint simulation

·  Perform statistical model checking

After applying architecture patterns, other solution methods that might be useful are:

·  Evaluate goals and contracts, to ensure that the revised SoS model is still compliant.

·  Generate architecture alternatives, to explore structural variants of the revised SoS model.

·  Generate optimized architectures, to explore quantified variants of the revised SoS model.

·  Evaluate emergent behaviour, to determine whether the revised SoS model meets desired emergent behaviours and to discover any new surprise emergent behaviours.

Perform formal verification, to verify desired properties of the revised SoS model.
Home About Technical Approach Apply architecture patterns