PROGRAMA DE MINIMIZACIÓN Y MANEJO DE RESIDUOS SÓLIDOS

In this thesis, we define component properties (cf. Section 3.1.5) by architectural con- straints. An architectural constraint defines a condition on the configurations of a (struc- tured) component instance [GMW00]. In addition, we enable to define such component properties as invariants. An invariant needs to evaluate to true for any configuration

of the component, whereas other component properties may evaluate to false for some configurations. Invariants enable to define valid configurations of a component, which we exploit for verifying the correctness of the reconfiguration behavior in Section 4.5.1. We define a new language called component story decision diagrams (component SDDs, [Hei14]) for modeling architectural constraints. Component SDDs combine the con- straint specification of story decision diagrams (SDDs, [KG07, Sta08]) with component story patterns (cf. Section 3.3.1) for referring to components. They have a name and always apply to one component of our component model. This component defines the type of thethisvariable which is used in the component story patterns.

In the following, we give a brief overview of component SDDs using examples in con- crete syntax and an informal description of their semantics. Component SDDs have been formalized by a metamodel [SV06, ch. 4] whose abstract syntax is given in Ap- pendix D.2.4. Their operational semantics has been formally defined in form of a trans- lational semantics [SK95] by defining a transformation to SDDs. We describe this trans- formation in our technical report [Hei14].

Component SDDs use the same syntactic elements as SDDs [KG07]. They consist of one initial node, a set of pattern nodes and leaf nodes, and a set of directed edges connecting the nodes. The initial node denotes the starting point for evaluating the component SDD. A pattern node contains a component story pattern. Leaf nodes mark the end for evaluating the component SDD. There exist two kinds of leaf nodes: (0)-nodes and (1)-nodes. The nodes are connected by two kinds of edges: then-edges (also called high- edges) and else-edges (also called low-edges). The initial node has exactly one outgoing then-edge and no incoming edge. Each pattern node has exactly one outgoing then-edge and one outgoing else-edge, while leaf nodes have no outgoing edges. The number of incoming edges is not restricted for pattern nodes and leaf nodes, but nodes and edges need to form a directed acyclic graph [Sta08, p. 60].

 cc, ps then else 0 1 RailCabDriveControl::isCoordinator this cc / convoy : ConvoyCoordination :curPos ps / pos : PositionSensor :position

Figure 3.19 shows an example of a simple component SDD calledisCoordinator. The initial node is visualized as a filled black circle. It shows the name of the component and the name of the component SDD. (1)-nodes are visualized as green circles containing a

1, while (0)-nodes are visualized as red circles containing a0. Pattern nodes are visual- ized as squares and visualize the component story pattern that they contain. It the upper left corner, they have a label that enumerates all unbound variables of the component story pattern. In our example, the component story pattern defines thatRailCabDrive- Controlembeds instances ofConvoyCoordinationandPositionSensor. The pattern node is connected by a solid then-edge to the (1)-node and by dashed else-edge to the (0)-node.

The semantics of a component SDD is defined analogously toSDDs [Sta08]. The eval- uation starts at the initial node with a variable binding that only assigns thethisvariable of the component story pattern to the component instance on which the component SDD should be evaluated. In our example, this is an instance ofRailCabDriveControl. This variable binding is passed to the first pattern node. If the contained component story pat- tern can be matched onRailCabDriveControl, then the variable binding is extended with bindings for all unbound variables (ccandps) of the component story pattern and passed down the then-edge. Otherwise, the variable binding remains unchanged and is passed down the else-edge. If the evaluation ends at a (1)-node, then the component SDD is fulfilled. If the evaluation ends at a (0)-node, then the component SDD is not fulfilled. Thus, the component SDD in Figure 3.19 is fulfilled for an instance ofRailCabDriveCon- trolif it embeds instances ofConvoyCoordinationandPositionSensorthat are connected by an assembly connector instance.

Since component SDDs are a constraint language, the component story patterns used in pattern nodes may not use«create»or«destroy»annotations. In addition, we do not allow to use optional or negative variables. Optional variables have no influence on a successful matching and, thus, cannot be referenced in subsequent nodes. Thus, they have no semantics in component SDDs. In accordance to Stallmann [Sta08], we do not use negative variables either but express negation by switching the then- and else-edges. As an example, consider the component SDDisStandaloneshown in Figure 3.20.

The component SDDisStandalonedenotes thatRailCabDriveControlneither operates as a coordinator nor as a member of a convoy. It is fulfilled if the component story patterns in both pattern nodes cannot be matched on an instance ofRailCabDriveControl. If one of the component story pattern could be matched, the evaluation would proceed via the then-edge and end at a (0)-node.

The pattern nodes that are used in Figures 3.19 and 3.20 are so-called existential pat- tern nodes. A component SDD containing only existential pattern nodes is fulfilled if and only if there exists one variable binding for the pattern nodes such that the evalua- tion terminates at a (1)-node. In addition, there exist so-called universal pattern nodes as shown in Figure 3.21. They are visualized with a cascaded border line [Sta08] in accordance to CSDs. If a component SDD contains a universal pattern node, then the

 cc, ps then 0 RailCabDriveControl::isStandalone this cc / convoy : ConvoyCoordination :curPos ps / pos : PositionSensor :position  mc this mc / member : MemberControl then else 0 1 else

Figure 3.20: Component SDDisStandalonefor ComponentRailCabDriveControl

evaluation needs to terminate at a (1)-node for any matching that can be obtained for the universal pattern node.

The invariant component SDDconvoyOrdershown in Figure 3.21 specifies that any two successive subport instances ofrefDistProviderare delegated to successive subport in- stances ofConvoyCoordination. This ensures that reference speeds and distances can al- ways be distributed within the convoy in the right order. In the component SDD, the first pattern node matches an instance ofConvoyCoordinationthat is embedded inRailCab- DriveControl. The second pattern node is a universal pattern node that matches all pairs of successiverefDistProviderport instances. For any match that may be obtained for this pattern node, the third pattern node needs to be matched as well such that the execution terminates at the (1)-node. If there exists no matching for the universal pattern node, then the component SDD is fulfilled. For this reason, we only visualize one outgoing then-edge for an universal pattern node as a shorthand notation [Sta08, p. 63].

A component SDD may require that an embedded component instance has a component property with a particular value. This component property may be specified, again, using a component SDD. This enables to connect architectural constraints through the different hierarchy levels of the component model. In Figure 3.21, the part variableccin the universal pattern node requires that the component propertyconvoyOrderis true for the component instance matched tocc.

1 cc then «invariant» RailCabDriveControl::convoyOrder  rdp1, rdp2 this cc [convoyOrder] rdp1:refDistProvider «next» rdp2:refDistProvider this cc / convoy : ConvoyCoordination then else rdp3, rdp4 this cc rdp1 rdp2 rdp3:refDistProvider «next» rdp4:refDistProvider then else 0 1