Guidelines for the incremental identification of aspects in requirements specifications

Abstract

The desired principle of separation of concerns in software development can be jeopardized by the so-called crosscutting concerns, which tend to be scattered over (and tangled with) the functionality of the modular units of a system. The correct identification of such concerns (and their encapsulation into separate artifacts) is thereby considered a way to improve software understanding and evolution. Pursuing a proper management of concerns from the requirements engineering stage can greatly benefit the entire software life-cycle. In this paper, we propose conceptual guidelines on how to perform the identification of crosscutting concerns in the process of building requirements specifications. We argue that the identification must be carried out in an incremental way, to encapsulate apart the crosscutting concerns even if they have not emerged completely yet.

Appendices

Appendix 1: The mining algorithm

Algorithm 1 shows the pseudo-code of the mining algorithm implemented in SCTL-MUS, that receives two parameters: (1) the MUS model of a component $\mathcal{C},$ and (2) a set $\delta_{\mathcal{C}}$ containing the events of $\mathcal{C}$ that do not appear in the models of the other components. The output consists of a model for the clean component $\mathcal{C}_{clean}$ and another one for the projection of the aspect $\mathcal{P}roj.$ We use the notation $s_{i} \xrightarrow{a} s_{j}$ to represent a possible transition from state s _i to state s _j through the event a. On its part, $\overline{s_{i}[a]}$ represents a non-possible transition from state s _i through event a (i.e. the fact that the event a is specified as false in s _i , also denoted by s _i [a]=false).

The algorithm starts out by making the models of $\mathcal{C}_{clean}$ and $\mathcal{P}roj$ equal to that of $\mathcal{C},$ and then proceeds by distributing the possible and non-possible transitions of the latter. The successive transformations are such that it always holds that $\mathcal{C} = \mathcal{C}_{clean} ||_{\mathcal{M}} \mathcal{P}roj,$ or, what is the same, $\mathcal{C} = \mathcal{C}_{clean} |[\Lambda]|_{\mathcal{M}} \mathcal{P}roj$ with Λ the whole set of events that appear in possible or non-possible transitions in $\mathcal{C}.$

The pseudo-code of Algorithm 1 does not show the following features:

• 1. The splits that assign all the transitions to either $\mathcal{C}_{clean}$ or $\mathcal{P}roj$ are automatically discarded.

• 2. The algorithm keeps track of the options it has traversed, to explore others in case a solution is rejected by the stakeholders.

• 3. Some options may not be explored following stakeholders’ indications (see Sect. 4.2).

 

The simplification mentioned in line 31 of Algorithm 1 works as follows. Given $\mathcal{C} = \mathcal{C}_{clean} |[\Lambda]|_{\mathcal{M}} \mathcal{P}roj,$ it attempts to remove events from $\mathcal{C}_{clean}$ and/or $\mathcal{P}roj$ and from the Λ set. The eligible events are those that appear only in possible or unspecified state transitions in $\mathcal{C}_{clean} (\mathcal{P}roj),$ and in unspecified transitions or unit loops in $\mathcal{P}roj (\mathcal{C}_{clean}).$ Any such event e can be removed from Λ, and the unit loops through e in $\mathcal{P}roj (\mathcal{C}_{clean})$ become unspecified transitions—producing simplified models $\mathcal{P}roj^{e} \quad (\mathcal{C}_{clean}^{e}).$ The changes must preserve that $\mathcal{C}_{clean}|[\Lambda - \{e\}]|_{\mathcal{M}} \mathcal{P}roj^{e} \quad (\mathcal{C}_{clean}^{e}|[\Lambda - \{e\}]|_{\mathcal{M}} \mathcal{P}roj)$ equals the original $\mathcal{C}.$

Next, we describe the execution of the mining algorithm when applied over the MUS model of $\mathcal{S}tation_{i}^{1}$ (Fig. 5) (with the set $\delta_{\mathcal{S}tation_{i}^{1}} = \{rdy_{i}\}$). We label each step with the corresponding line number in the pseudo-code of the algorithm.

• [line 1] Figure 17 depicts the initial situation, where the models of $\mathcal{S}tation_{i_{clean}}^{1}$ and $\mathcal{P}roj_{i}$ are equal to the original one (the layout represents the equality $\mathcal{S}tation_{i}^{1} = \mathcal{S}tation_{i_{clean}}^{1}||_{\mathcal{M}} \mathcal{P}roj_{i}).$ The dotted lines represent unassigned transitions. Once a transition has been assigned to either $\mathcal{S}tation_{i_{clean}}^1$ or $\mathcal{P}roj_{i},$ it becomes a solid line in that part and in the original component; thus, the algorithm finishes when all the transitions of the original component are solid lines.

• [line 2] Let Υ be the possible transition $s_{1} \xrightarrow{rdy_i} s_{2}.$

• [line 4] Υ is assigned to $\mathcal{S}tation_{i_{clean}}^{1},$ which implies joining the states s ₁ and s ₂ in $\mathcal{P}roj_i$ (Fig. 18).

• [line 2] Let Υ be the possible transition $s_{2} \xrightarrow{init_i} s_{3}.$

• [line 4] As first option (shown in Fig. 19), Υ is assigned to $\mathcal{S}tation_{i_{clean}}^{1},$ which implies: (1) the transition $s_{3} \xrightarrow{end_i} s_{1}$ is also assigned to $\mathcal{S}tation_{i_{clean}}^{1},$ because it joins the same states in $\mathcal{P}roj_i$ (s _1,2 and s ₃) than Υ [line 5]; (2) joining the states s _1,2 and s ₃ in $\mathcal{P}roj_i$ [lines 6–16].

• [line 2] Let Υ be one of the possible transitions $s_{2} \xrightarrow{init_j} s_{4},$ for some j ≠ i.

• [line 4] As first option (shown in Fig. 20), Υ is assigned to $\mathcal{S}tation_{i_{clean}}^{1},$ which implies: (1) assigning all the other possible transitions between s ₂ and s ₄ to $\mathcal{S}tation_{i_{clean}}^1$ [line 5]; (2) assigning the transition $\overline{s_4[init_i]}$ to $\mathcal{S}tation_{i_{clean}}^1$ [line 10]. This option is discarded, because it leads to a split where all the transitions have been assigned to $\mathcal{S}tation_{i_{clean}}^{1}.$

• [line 19] As second option (shown in Fig. 21), Υ is assigned to $\mathcal{P}roj_{i},$ which implies: (1) assigning all the other possible transitions between s ₂ and s ₄ to $\mathcal{P}roj_i$ [line 5]; (2) assigning the transition $\overline{s_4[init_i]}$ to $\mathcal{P}roj_i$ (line 10).

• [line 31] Having assigned all the transitions, it is possible to remove from $\mathcal{S}tation_{i_{clean}}^1$ the transitions $s_{2} \xrightarrow{\{end_j\}} s_{2} \forall j \neq i,$ also removing the events end _j ∀j ≠ i from the $|\,|_{\mathcal{M}}$ operator; the same happens with the transitions $s_{1} \xrightarrow{rdy_i} s_{1}$ and $s_{1} \xrightarrow{end_i} s_{1}$ in $\mathcal{P}roj_{i}.$ The result is shown in Fig. 22.

Fig. 17

The initial situation [line 1 in Algorithm 1]

Fig. 18

Dealing with the transition $s_{1} \xrightarrow{rdy_i} s_{2}$ [lines 4–18]

Fig. 19

Dealing with the transition $s_{2}\xrightarrow{init_i} s_{3}$ [lines 4–18]

Fig. 20

From [line 4] to [line 31] with one of the transitions $s_{2} \xrightarrow{init_j} s_{4}:$ an automatically discarded split

Fig. 21

From [line 19] to [line 31] with one of the transitions $s_{2}\xrightarrow{init_j} s_{4}:$ first solution

Fig. 22

Simplification of the first solution [line 31]

Appendix 2: Combining the projections to make up the aspect

The following steps illustrate the process to gather together the projections of an aspect:

• Figure 23 graphically depicts (5), that is reached after the mining algorithm has found the split of Fig. 6.

• As shown in Fig. 24, the common set of events Ω of (5) is obtained by adding convenient unit loops to the clean component and the projection of the aspect. ⁷

• Figure 25 results from reordering the artifacts of Fig. 24, applying the commutativity and associativity properties of $|[\Lambda]|_{\mathcal{M}}.$

• Figure 26 shows how the models are simplified, by following the same rules applied in Fig. 22.

• Finally, the model for the overall aspect results from composing those of its projections (see Fig. 27).

Fig. 23

Combining the projections (step 1)

Fig. 24

Combining the projections (step 2)

Fig. 25

Combining the projections (step 3)

Fig. 26

Combining the projections (step 4)

Fig. 27

Combining the projections (step 5)

Appendix 3: Rewriting requirements

This appendix details the derivation of the requirements for the projections of the candidate aspect in the first identification round of the example (Sect. 3.5), and for the clean components and the aspect projections in the second (Sect. 3.7).

3.1 Appendix 3.1: Requirements for the aspect projections (first round)

From the split shown in Fig. 6, the requirements in $\mathcal{S}pec (\mathcal{S}tation_{i}^{1})$ are rewritten by conveniently removing the events {rdy _j }_∀j ∪ {end _i }, which appear in unspecified transitions from every state of the MUS model derived for $\mathcal{P}roj_{i}.$ This operation leads to the provisional requirements of Fig. 28.

Fig. 28

Removing the events {rdy _j }_∀j ∪ {end _i } from $\mathcal{S}pec (\mathcal{S}tation_{i}^{1})$ to obtain the provisional requirements for $\mathcal{P}roj_{i}$

As shown in Fig. 9, $\mathcal{R}_{2_{cross}}$ does not become part of the specification of $\mathcal{P}roj_{i},$ because it is violated in state s ₁ of its MUS model (see Fig. 6). On its part, $\mathcal{R}_{5_{cross}}$ is removed because it does not specify anything—$\mathcal{R}_5$ adheres to the pattern $\mathcal{R} \Rightarrow \oplus [\neg] e$ (see Sect. 3.4). Also note that the true premise of $\mathcal{R}_{1_{cross}}$ can be omitted.

3.2 Appendix 3.2: Requirements for $Station_{i_{clean}}^2$

From the split shown in Fig. 13, the requirements in $\mathcal{S}pec (\mathcal{S}tation_{i}^{2})$ are rewritten by conveniently removing the events {rdy _j , init _j , end _j }_∀j≠i , which appear in unspecified transitions from every state of the MUS model derived for $\mathcal{S}tation_{i_{clean}}^{2}.$ This operation leads to the provisional requirements of Fig. 29.

Fig. 29

Removing the events {rdy _j , init _j , end _j }_∀j≠i to obtain the provisional requirements for $\mathcal{S}tation_{i_{clean}}^{2}$

As shown in Fig. 14, $\mathcal{R}_{7_{clean}}$ does not become part of the specification of $\mathcal{S}tation_{i_{clean}}^{2},$ because it is violated in state s ₂ of its MUS model. On its part, $\mathcal{R}_{6_{clean}}$ is removed because $\mathcal{R}_6$ adheres to the pattern $\mathcal{R} \Rightarrow\oplus [\neg] e$ (see Sect. 3.4).

3.3 Appendix 3.3: Requirements for the aspect projections (second round)

From the split shown in Fig. 13, the requirements in $\mathcal{S}pec (\mathcal{S}tation_{i}^{2})$ are rewritten by conveniently removing the events {rdy _j }_∀j ∪ {end _j }_∀j≠i , which appear in unspecified transitions from every state of the MUS model derived for $\mathcal{P}roj_{i}^{2}.$ This operation leads to the provisional requirements of Fig. 30.

Fig. 30

Removing the events {rdy _j }_∀j ∪ {end _j }_∀j≠i to obtain the provisional requirements for $\mathcal{P}roj_{i}^{2}$

As shown in Fig. 15, $\mathcal{R}_{1_{clean_{cross}}}$ does not become part of the specification of $\mathcal{P}roj_{i}^{2},$ because it is not satisfied in state s ₂ of its MUS model (see Fig. 13). $\mathcal{R}_5$ and $\mathcal{R}_7$ are removed because they follow the pattern $\mathcal{R} \Rightarrow\oplus [\neg] e$ (see Sect. 3.4).