Managing design-time uncertainty

Abstract

Managing design-time uncertainty, i.e., uncertainty that developers have about making design decisions, requires creation of “uncertainty-aware” software engineering methodologies. In this paper, we propose a methodological approach for managing uncertainty using partial models. To this end, we identify the stages in the lifecycle of uncertainty-related design decisions and characterize the tasks needed to manage it. We encode this information in the Design-Time Uncertainty Management (DeTUM) model. We then use the DeTUM model to create a coherent, tool-supported methodology centred around partial model management. We demonstrate the effectiveness and feasibility of our methodology through case studies.

Appendices

Appendix 1: Operators

Here we give the detailed descriptions of the Uncertainty Operators from Sect. 4 (see Tables 3, 4, 5, 6, 7, 8, 9, 10, 11, 12).

Table 3 Operator MakePartial

Table 4 Operator Expand

Table 5 Operator Transform

Table 6 Operator Verify

Table 7 Operator Deconstruct

Table 8 Operator Decide

Table 9 Operator Constrain

Table 10 Operator GenerateCounterExample

Table 11 Operator GenerateExample

Table 12 Operator GenerateDiagnosticCore

Appendix 2: Models

In this appendix, we provide additional details about the worked examples in Sects. 6.1 and 6.2.

1.1 UMLet Bug #10

Figure 14 shows the Mu-Mmint model K0 that encodes the UMLet model shown in Fig. 10. The encoded model contains the relevant slices of both the class diagram and the sequence diagram (bottom), as well as traceability links between them, linking messages in the sequence diagram to operations in the class diagram and objects to their classes. In the sequence diagram model, objects and lifelines are represented by the same model element. Mu-Mmint uses yellow and pink stars to, respectively, indicate edges that represent the source and target lifelines of messages.

Fig. 14

Mu-Mmint model K0

Table 13 Valid combinations of repair strategies for ClasslessInstance and DanglingOperation

Table 13 shows the valid combinations of strategies for repairing the ClasslessInstance and DanglingOperation consistency violations. Each combination represent a repair of the model shown in Fig. 14, i.e., a concretization of the partial model K1, shown in Fig. 15

Fig. 15

Diagram of the Mu-Mmint partial model K1

Figure 15 shows the diagram of the partial model K1 created by the maintainer to express her uncertainty about which of the 44 alternative repairs in Table 13 to select. To enhance diagram readability, we have hidden the labels of the arrow model elements. This has resulted in hiding Maybe annotations as well; however, it is easy to deduce that edges that are in K1 but not in K0 have Maybe annotations.

Figure 16 shows the ground propositional encoding $\phi _{U1}$ of the property U1, expressed in SMT-LIB [4]. The formula encodes the property as a conjunction of the variables (see [18]) of the messages that are required to perform pasting.

Figure 17 shows the ground propositional encoding in SMT-LIB of the sequence diagram well-formedness constraints for the slice of K1 involved in checking U1. Specifically, we check that for each message in Fig. 16, there is an operation reference that maps it to the appropriate method definition. The abbreviation “or” in the name of the variables means “operation reference”.

Fig. 16

Ground propositional encoding of the property U1

Fig. 17

Ground propositional encoding of sequence diagram well-formedness constraints involved in checking the property U1

Fig. 18

Ground propositional encoding of the property U2

Figure 18 shows the ground propositional encoding $\phi _{U2}$ of the property U2 for K1, in SMT-LIB. Specifically, we check whether the message ${\mathtt {setComponentZOrder}}$ exists in every concretization. We have combined the property with the sequence diagram well-formedness constraint additionally requiring the appropriate operation reference to the method definition.

Figure 19 shows the model K2, a concretization of K1. It was created by invoking the operator GenerateCounterExample with inputs K1 and U1. Mu-Mmint has greyed out Maybe elements of K1 that are not also part of K2.

Figure 20 shows the diagram of the partial model K3, resulting from invoking the operator Constrain with inputs K1 and U1. To enhance diagram readability, we have hidden the labels of edge elements. Every edge that is outgoing from the elements ${\mathtt {new}}$, ${\mathtt {moveToTop}}$, ${\mathtt {setComponentZOrder}}$, and ${\mathtt {positioner}}$ is annotated with Maybe.

Fig. 19

Concretization K2 of the partial model K1, a counterexample demonstrating why checking U1 yields Maybe. Mu-Mmint has greyed out elements of K1 that are not also part of K2

Fig. 20

Diagram of the partial model K3

Fig. 21

Diagram of the final model K4, implementing the repairs RC4 and RD2

Figure 21 shows the (concrete) model K4, resulting from invoking the operator ${\mathtt {Decide}}$ with K3 as input while choosing the repairs RC4 and RD2.

1.2 Petri net metamodel

Figure 22 shows the Mu-Mmint diagram of the partial metamodel N0. Meta-associations are decorated with the icon “

”, whereas containment references—with the icon “

”. Maybe elements are annotated with “[M]” and one or more alternatives from the uncertainty tree of N0 in square brackets. The uncertainty tree of N0 is shown in Fig. 23.

The May formula of N0 is constructed from the uncertainty tree using the technique described in Sect. 5. Specifically:

• The May formula is a conjunction of the decision variables:

  • ${\mathtt {d1\_ArcClasses}}$ $\wedge$ ${\mathtt {d4\_Locations}}$ $\wedge$

  • ${\mathtt {d5\_TokenClass}}$ $\wedge$ ${\mathtt {d7\_Executions}}$

• Each decision variable is equivalent to an exclusive disjunction of the alternative variables. For example:

  • ${\mathtt {d1\_ArcClasses}}$$\Leftrightarrow$((${\mathtt {d1ynw}}$$\bigoplus$${\mathtt {d1yw}}$$)\bigoplus$${\mathtt {d1n}}$).

• Each alternative variable is equivalent to the conjunction of the Maybe elements that are annotated with the alternative and the negations of the Maybe elements that are annotated with other alternatives of the same decision. For example:

  • ${\mathtt {d1n}}$ $\Leftrightarrow$ ${\mathtt {src\_placeToTransition\_Association}}$ $\wedge$

  • ${\mathtt {src\_transitionToPlace\_Association}}$ $\wedge$

  • ${\mathtt {dst\_placeToTransition\_Association}}$ $\wedge$

  • ${\mathtt {dst\_transitionToPlace\_Association}}$ $\wedge$

  • $\lnot$ ${\mathtt {PlaceToTransition\_Class}}$ $\wedge \lnot$

  • ${\mathtt {TransitionToPlace\_Class}}$ $\wedge \ldots \wedge$

  • $\lnot$ ${\mathtt {weight\_P2T\_Attribute}}$ $\wedge$

  • $\lnot$ ${\mathtt {getWeight\_P2T\_Operation}}$ $\wedge$

  • $\lnot$ ${\mathtt {setWeight\_P2T\_Operation}}$ $\wedge \ldots$

Fig. 22

Diagram of the partial metamodel N0

Fig. 23

Uncertainty tree of the partial metamodel N0

With the exception of the class ${\mathtt {Location}}$, the various meta-attributes, and the getter and setter operators, the diagram of the metamodel N0 was created by merging slices of the AMZ metamodels listed in Table 2. We sliced the AMZ metamodels in order to get a model that can be used with the ORM transformation described in “Appendix 3”, which requires the input class diagram to have a flat class inheritance hierarchy.

Figure 24 shows the ground propositional encoding $\phi _{U3}$ of the property U3, expressed in SMT-LIB [4]. The formula encodes the property as a conjunction of the variables (cf. atomToProposition) of the tables that are needed to map tuples from tables representing graphical PTN elements to tuples of the table ${\mathtt {Location}}$.

Fig. 24

Ground propositional encoding of the property U3

Figure 25 shows the partial PTN metamodel N2 that results from invoking the operator Decide on the partial model N0 to select the alternative ${\mathtt {d4y}}$ of the decision ${\mathtt {d4\_Locations}}$ in the uncertainty tree in Fig. 23.

Fig. 25

Partial PTN metamodel N2

Fig. 26

Partial PTN metamodel N3. The uncertainty tree is shown in Fig. 27

Figure 26 shows the diagram of the partial PTN metamodel N3 that results from invoking the operator Expand on the partial model N2 to include uncertainty about which domain-specific PTN constructs should be included in the ConcMod tool.

Fig. 27

Uncertainty tree of the partial metamodel N3

Figure 28 shows the concrete PTN metamodel N5, resulting from invoking the operator ${\mathtt {Decide}}$ with N3 as input and making the decisions ${\mathtt {d1yw}}$, ${\mathtt {d2n}}$, ${\mathtt {d3n}}$, ${\mathtt {d5y}}$, ${\mathtt {d6n}}$, ${\mathtt {d7y}}$, ${\mathtt {d8n}}$, ${\mathtt {d9n}}$, ${\mathtt {d10n}}$ from the uncertainty tree in Fig. 27.

Fig. 28

Diagram of the final PTN metamodel N5

Appendix 3: Object-relational mapping

Figure 29 shows the first three Henshin rules ${\mathtt {classTo}}$${\mathtt {Table}}$, ${\mathtt {associationToTable}}$, and ${\mathtt {attributeTo}}$${\mathtt {Column}}$ used to perform the Object-Relational Mapping (ORM) transformation.

Fig. 29

Rules ${\mathtt {classToTable}}$, ${\mathtt {associationToTable}}$, and ${\mathtt {attributeToColumn}}$ used to perform the ORM transformation

Fig. 30

Rules ${\mathtt {attributeToForeighKey}}$ and ${\mathtt {associationToForeignKey}}$ used to perform the ORM transformation

Figure 30 shows the last two Henshin rules ${\mathtt {attribute}}$${\mathtt {ToForeighKey}}$ and ${\mathtt {associationToForeignKey}}$ used to perform the ORM transformation.