Modeling the Architecture
PolarSys CHESS supports the modeling of the architecture at system, software, and hardware levels. This is done using:
- SysML Block Definition Diagrams and SysML Internal Block Diagrams in the System View (system architecture)
- UML Class Diagrams and UML Composite Structure Diagrams in the Functional View (software architecture) and in the Deployment View (hardware architecture).
You don't need to define all the three architectures in order to execute CHESS-SBA. If you define one, two, or all of them, depends on the nature of your project and the current stage of its development.
Here we detail the minimal steps to model each of the three architectures. Real-life architectures can be more complex and organized in multiple hierarchical diagrams. Further examples can be found in the examples section.
The first step consists in creating a new Block Definition Diagram in the System View, which will hold the definition of all the blocks of the system architecture. In fact, system-level "components" are modeled using SysML «Block» elements. Add all the needed block in the diagram. Consider that the same block can be instantiated multiple times, therefore there is no need to create multiple copies of identical blocks.
Blocks can have ports, which are modeled using the «FlowPort» construct.
A «FlowPort» is an interaction point through which input and/or output of items such as data, material, or energy may flow. The direction property of a «FlowPort» can be in, out, or inout, depending on the direction in which data/material/energy flow between elements.
Then, after having defined which are the block that take part in the architecture, and which are their interaction points, the second step is to detail the internal structure of composite components, that is, how the components are arranged.
To do this, create an Internal Block Diagram for each block that you wish to detail, and add instances of the previously defined blocks as parts of the composite element.
In this simple example, GasSensor, ManualGasDetection, and GasDetectionFunction are parts of the GasDetectionSystem element.
In general, the modeling of the software architecture follows a similar approach: UML Class Diagrams to model the set of available components, and UML Composite Structure Diagrams to model the internal sturcture of composite components. However, the CHESS methodology prescribes a stricter process for the definition of the software architecture, which is detailed in the CHESS Toolset User Guide. We summarize such process in the following. We recall that this process is performed in the Functional View.
Interfaces of software components need to be defined first. This is done using a Class Diagram. Components will be allowed to communicate using such interfaces only.
Then, component types should be defined. A component type defines the provided and required interfaces of a component, but not its actual implementation. Component types are added in the Class Diagram using the ad-hoc element in the CHESS palette, which creates a UML «Component» with the «ComponentType» stereotype.
After adding component types to the model, it is necessary to actually define which interfaces they provide/require. This is done by creating a new Composite Structure Diagram for each of them, where ports («ClientServerPort» elements) can be added to the component type. By selecting a newly created port, a Marte tab appears in the properties page, where the provided or required interfaces can be selected, among those present in the model.
In this example, we also set the type of the port to the corresponding interfaces. This however is not required and was done only for the cosmetic effect of visualizing the interface alongside the port.
Following the specification of provided and required interfaces in the Marte tab, the tool automatically creates the corresponding Dependency and Realization relations between the component type and the involved interfaces, as well as the operations that the component need to implement.
Such relations are created in the of the Model Explorer only, and must be dragged onto the Class Diagram to visualize them.
The software elements that can be actually instantiated in the software architecture are component implementations. Component implementations need to be defined in a Class Diagram, still using the specific button in the CHESS palette. The button creates a UML «Component» with the «ComponentImplementation» stereotype. Each component implementation must reference its type, that is, it must have a Realization relation with a «ComponentType». Based on these relations, the operations that the component must implement are automatically derived.
A component can be implemented as an aggregation of sub-components. That is, a «ComponentImplementation» can be a composite element. In this case its parts are specified using a Composite Structure Diagram. Note that specifing the internal structure is allowed for component implementations only. Component types only define provided and required interfaces, and do not provide details on the internal implementation.
Even when no composite component implementation exists, we need to define how the top-level components are connected together.
For this purpose, a fictional UML Component (in our case SwSystem) is added to the Class Diagram, to represent the entire software system.
Instances of the defined component implementations, modeled as UML Part elements, form its internal structure. The associated Composite Structure Diagram defines the
how component instances are connected together.
The same approach is used when defining the internal structure of a composite component implementation.
The modeling of the hardware architecture is similar to the modeling of the system architecture, with the main differences of being performed in the Deployment View, and with UML constructs.
The first step consists in creating a new Class Diagram in the Deployment View, which will hold the definition of all the components of the hardware architecture. Hardware components are modeled as proper UML «Component» elements. Also in this case, consider that the same component can be instantiated multiple times.
Also hardware components can have ports, which are modeled using the «FlowPort» construct from MARTE. At the hardware level, a «FlowPort» models data flow-oriented communication between components, where messages that flow across ports represent data items.
The direction property of a «FlowPort» can be in, out, or inout, depending on the direction in which data flows between elements.
Ports at the hardware level do not need to have an explicit interface associated to them (the same applies to system-level modeling). Also, the notion of component implementation do not apply. Therefore, the modeling is simpler with respect to the software architecture.
Then, after having defined which are the block that take part in the architecture, the second step is to detail the internal structure of composite components, that is, how the components are arranged and connected.
To do this, create a Composite Structure Diagram for each component that you wish to detail, and add instances of the previously defined components as parts of the composite element.
When modeling the hardware or the system architecture, ports can be defined either during the specification of components (Class Diagram or Block Definition Diagram), or during their instantiation as parts of a composite (Composite Structure Diagram or Internal Block Diagram). The two approaches are equivalent, and the resulting models are identical in terms of structure.
You may have noticed that Composite Structure Diagrams only supports the specification of one level of composition.
That is, it is not possible to model, in the same diagram, a situation for which component A is a composition of B and C and, in turn, C is a composition of D and E.
To model this with the available UML diagrams, one would need to create two separate Composite Structure Diagrams, one in which A is modeled as a composition of B and C, and another in which C is modeled as a composition of D and E. The same applies to SysML Internal Block Diagrams.
The PolarSys CHESS framework contains a feature to automatically generate the complete tree of instances from a set of Composite Structure Diagrams or Internal Block Diagrams. This feature is called Build Instances and it is available for «Component» and «Block» elements that have been assigned the «CHGaResourcePlatform» stereotype from CHESS ML.
Typically, the top-level elements of the system, software, and hardware architectures are assigned the «CHGaResourcePlatform» stereotype.
The feature is activated by right-clicking on the element in the model explorer, selecting CHESS, and then Build Instances.
The tool generates, in the same model, a new UML Package, containing the tree of instances having the element with the «CHGaResourcePlatform» stereotype as root.
The package is composed of InstanceSpecification elements, obtained by the specification of composites given in Composite Structure Diagrams (or Internal Block Diagrams).
Note that instances are generated for components/blocks, as well as for connectors that connect them. The result of applying Build Instances to the SwSystem component previously defined is shown in the image below.
This facility has several advantages. It allows the user to verify that the intended structure of the system/software/hardware architecture is correct; it permits to differentiate between component-level and instance-level properties, and simplifies the application of transformation algorithms. Besides that, running the Build Instances command is a pre-requisite for running CHESS-SBA, as well as other analysis techniques. Further details will be provided when detailing the CHESS-SBA workflow. Running the command multiple times simply overwrite what has been generated previously.
Finally, PolarSys CHESS allows the modeler to specify the allocation of software to hardware. This is used for several purposes in different analysis techniques. In CHESS-SBA, is one of the means used to derive propagation paths.
For each software component instance, allocation specifies the hardware component instance on which it is allocated, thus creating links between the software and the hardware architectures. In CHESS ML, allocation is modeled by a UML Comment with the «Assign» stereotype, which is directly available in the CHESS palette.
The from attribute accepts a set of software instances, while the to attribute accepts a single hardware instance.
Typically, allocation comments are attached to the top-level component of the hardware architecture.
Note that allocation works on component instances. That is, the from and to fields should contain InstanceSpecification elements generated by the Build Instances command. Therefore, the Build Instance command should be executed before, both on the top-level software component, as well as on the top-level hardware component.
Now let's understand how to attach CHESS-SBA dependability annotations to the defined architecture.