Evaluate goals and contracts


“Evaluate Goals and Contracts” provides the ability to define semantically precise goals/contracts and then, as part of Statistical Model Checking, to determine under what conditions each goal/contract is met or not met.

Initial Situation

“Evaluate Goals and Contracts” is used when there are specific requirements that the SoS and the CSs are desired to meet, and it is uncertain whether a given architecture might or might not meet them. The following conditions and solution methods are pre-conditions:

  1. Configure DANSE Tool-Net Environment is complete.

  2. Model SoS is essentially complete, although it may be modified.

  3. Abstract Constituent System Model is complete for those CSs of interest.

  4. The developer has worked with stakeholders to identify global and local goals for the SoS and CSs.

Example: The SoS is pre-existing, but is being evolved to new configurations to meet new envisioned capabilities. The developer has created a descriptive UPDM model for the SoS, including OV-5 (operational activities), SV-5 (system functions), SV-4 (functional sequences), and SV-1 (system description) diagrams. Some CS models are available from system owners, and those have been converted into executable models by a suitable abstraction method. The developer has had work sessions with the SoS agency owner and with the owners of each CS, in which each owner has identified verbal statements of the goals important to that owner. The goals conflict within each CS, between the CSs and the SoS, and within the SoS, leading the developer to need trade-offs to optimize the SoS architecture among the goals.

Expected Result

The developer knows under what conditions each of the goals and contracts can be met. The information is catalogued by architecture alternatives to support trade-offs and further architectural exploration.

Example: At the end of this solution method, the developer knows that it is not possible to meet all SoS/CS goals, but that there are some architectures that meet all SoS/CS contracts. The developer has sufficient information to explore optimization of the goals within the design space under which all contracts are met. Following this exploration, for the selected architecture, the developer can assure stakeholders of the compliance with goals and can identify conditions under which various goals are met or not.

Required Tools

  • IBM Rhapsody UPDM
  • Goals and Contracts Specification Language (GCSL)
  • GCSL Editor (accessed within Rhapsody)

Additional tools needed to perform “Joint Simulation, which is required as a part of the GCSL solution method

  • Appropriate CS modelling tools
  • DANSE Tool-Net semantic mediation

Figure 55. Tool Flow: Evaluate Goals and Contracts


“Evaluate Goals and Contracts” activities are shown in the following Activity Diagram, with descriptions following the diagram.

Figure 56. Activity Diagram for Evaluate Goals and Contracts

Model SoS

This is the solution method Model SoS described in section 5.1. The model of the SoS must specify how the Constituent Systems are interconnected and what information they exchanged in order to properly interact. This activity can be carried out using UPDM in Rhapsody, by developing an Internal Block Diagram that connects the Constituent Systems through a set of ports.

Formalize SoS requirements in GCSL

The verbal requirements created in discussions with stakeholders are typically in stakeholder natural language. Convert these requirements into semantically precise statements using the GCSL specification and the GCSL Editor. Within Rhapsody, place GCSL statements into a constraint block on the SoS SV-1 diagram, typically in the form of an internal block diagram (ibd).

Perform joint simulation

This is the solution method Perform Joint Simulation described in section 5.6. The joint simulation uses the capabilities of DESYRE to combine the executable elements of the SoS and CS models into a single simulation environment. Part of this activity is to define the simulation configuration and trace configuration that creates the information needed for statistical model checking.

The simulation configuration file in the DESYRE workspace specifies the SoS model to be simulated, simulation time, number of independent simulation runs, fault injection, and so on. These parameters are essential for the correct execution of the simulation, and allow the designer to customise the simulation infrastructure according to the objective of the analysis.

The trace configuration file specifies which elements of the SoS model shall be traced by the simulator (by default, all CS input/outputs are traced). The designer must specify the signals of interest in the SoS, whose evolution must be recorded and then displayed by the simulator.

Perform “Statistical Model Checking”

This is the solution method Perform Statistical Model Checking in section 5.7. In this method, the GCSL constraints are exported from Rhapsody to DESYRE and become part of the joint simulation. Results of the joint simulation are then exported from DESYRE to PLASMA to become the basis for statistical model checking. This activity creates simulation results available within DESYRE.

Results Satisfactory?

Evaluate the simulation results to determine which goals/contracts are met under which conditions. If the results are not satisfactory, then either:

  1. use various solution methods to generate architecture alternatives that may improve performance, or

  2. modify the goals/contracts with stakeholder concurrence.


Success of this solution method depends on:

  • The quality of the requirements elicitation with the stakeholders
  • The available logical constructs within GCSL.
  • Cycle time to perform architecture alternatives generation and return to statistical model checking.

Follow-up Solution Methods

The following solution methods are likely to be used after “Evaluate Goals and Contracts”:

  • “Evaluate SoS Performance” to determine the performance level to which goals are met or not met.
  • “Generate Architecture Alternatives – Concise Modelling” when goals/contracts results are not satisfactory, and variation might be achieved within the general architectural structure.
  • “Generate Architecture Alternatives – Patterns” when goals/contracts results are not satisfactory, and new architectures are needed.
  • “Generate Architecture Alternatives – Graph Grammar” when goals/contracts results are not satisfactory, and architectural structure variation might be possible.
Home About Technical Approach Evaluate goals and contracts