Comprehensibility of UML-based software product line specifications

Abstract

Software Product Line Engineering (SPLE) deals with developing artifacts that capture the common and variable aspects of software product families. Domain models are one kind of such artifacts. Being developed in early stages, domain models need to specify commonality and variability and guide the reuse of the artifacts in particular software products. Although different modeling methods have been proposed to manage and support these activities, the assessment of these methods is still in an inceptive stage. In this work, we examined the comprehensibility of domain models specified in ADOM, a UML-based SPLE method. In particular, we conducted a controlled experiment in which 116 undergraduate students were required to answer comprehension questions regarding a domain model that was equipped with explicit reuse guidance and/or variability specification. We found that explicit specification of reuse guidance within the domain model helped understand the model, whereas explicit specification of variability increased comprehensibility only to a limited extent. Explicit specification of both reuse guidance and variability often provided intermediate results, namely, results that were better than specification of variability without reuse guidance, but worse than specification of reuse guidance without variability. All these results were perceived in different UML diagram types, namely, use case, class, and sequence diagrams and for different commonality-, variability-, and reuse-related aspects.

Appendices

Appendix A: Comparison of UML-based SPLE Methods

Table 5 Comparison of UML-based SPLE methods

Appendix B: The Formalism of the ADOM Method

Next we formally define the ADOM method.

The elements of UML are classified into three categories: dependent, relational, and first order elements.

Definition 1

Dependent elements are elements that depend on other elements in the model such that the omission of the dependees from the model implies the omission of the dependent elements.

Examples of dependent elements are attributes and operations in UML class diagrams that depend on their owning classes and sub-packages that depend on their owning packages.

Definition 2

Relational elements are explicit binary (directional) relationships between pairs of elements.

Examples of relational elements are associations in UML class diagrams and messages in UML sequence diagrams. Note that all kinds of relationships in UML are binary or can be mapped to binary relations.

Definition 3

First order elements are elements which are not relational nor dependent in the model.

All kinds of elements can be associated with the «multiplicity» stereotype which is defined next.

Definition 4

The «multiplicity min=n max=m» stereotype, which can be associated to any element in the domain model, specifies the range of elements in the application artifact that can be classified as the same domain element. The two tagged values, min and max, are used for defining the lowest and upper-most boundaries of that range.

The meanings of the «multiplicity» stereotype are slightly different according to the element types: first order, dependent or relational elements. The multiplicity stereotype of a dependent element specifies the range of times this domain element can be used in any dependee of a software product in that line. Specifying, for example, the multiplicity of an attribute A of class C as «multiplicity min=1 max=*» implies that between 1 to ∞ attributes of type A have to be included in each class of type C in a certain product in the line.

The multiplicity stereotype of a relational element specifies the range of times this domain element can appear, connecting the relevant source and target in any product of the line. Specifying, for example, the multiplicity of an association r between class A and class B as «multiplicity min=1 max=*» implies that in any product in the line in which both A and B appear, each appearance of A is connected to at least one appearance of B via associations of type r, and vice versa.

Lastly, the multiplicity stereotype of first order elements specifies the range of times the relevant domain elements can appear in any product of that line.

Note that any combination of the multiplicity stereotypes is feasible. For example, a mandatory relational element can connect two optional elements, implying that if the two elements appear in a certain product, then the relational element must connect them. Similarly, a mandatory dependent element may reside within an optional element, implying that if the dependee appears in a certain product, then the dependent element must appear too.

Optional elements can be connected via «requires» and «excludes» dependencies in order to constrain larger configurations.

Definition 5

Let A and B be two optional elements in a domain model. A «requires» B implies that if A appears in a particular product, then B should appear too. A «excludes» B implies that if A is included in a particular product, then B should not appear. Furthermore, in order to avoid redundancy or non-feasible models, the following constraints must hold:

• C1. If A requires B, then A.multiplicity.min=0 and B.multiplicity.min=0.

• C2. If A excludes B, then A.multiplicity.min=0 and B.multiplicity.min=0.

  The following definitions refer to the specification of variability in ADOM.

Definition 6

The «variation_point open=true/false card=m..n» stereotype indicates places in which variability can be introduced. The variation point can be open (open=true), meaning that product-specific variants not specified in the domain models can be added at this point or closed (open=false), i.e., addition of product-specific variants that are not specified in the domain models is not allowed at this point. The card tagged value indicates the minimal (m) and maximal (n) numbers of variants the can be selected for this variation point. The following constraints must hold with respect to variation points:

• C3. If m = 0, then open=true.

• C4. If open=false, then m ≥ 1.

Definition 7

The «variant vp=name» stereotype is used for indicating a possible way to realize variability in a certain variation point. vp indicates the name of the variation point in case an explicit inheritance relationship between the variant and variation point cannot be specified (in the case of non-classifiers). The following constraints must hold with respect to variants and their associated variation points:

• C5. The multiplicity of a variant (v) can be the same or more restricted than the multiplicity of the relevant variation point (vp). Formally expressed as: vp.multiplicity.min ≤ v.multiplicity.min ≤ v.multiplicity.max ≤ vp.multiplicity.max.

Note that no restriction exists between the cardinality values and the multiplicity values of both variants and variation points, as cardinality refers to the selection of variants in a single occurrence of the variation point in a software product, while multiplicity refers to the general number of occurrences of the variation point or the variant in the whole product.

Finally, the reuse guidance is specified in ADOM using the «reuse» stereotype, defined below.

Definition 8

The «reuse mechanism=name» stereotype is used to guide the usage of a domain element in various products in the line. The mechanism tagged value specifies the applicable reuse mechanism. In the current work we refer only to the following values: s—usage (a representative of the selection reuse mechanisms), e—extension (a representative of the substitution reuse mechanisms), and se—not constrained (i.e., either usage or extension). The following constraints must hold with respect to the reuse guidance of variation points and the associated variants:

• C6. The reuse mechanisms of a variant (v) can be the same or more restricted than the reuse mechanisms of the relevant variation point (vp), namely:

• 1. If vp.reuse.mechanism = ‘se’, then v.reuse.mechanism∈{‘s’, ‘e’, ‘se’}.

• 2. If vp.reuse.mechanism = ‘e’, then v.reuse.mechanism = ‘e’.

• 3. If vp.reuse.mechanism = ‘s’, then v.reuse.mechanism = ‘s’.

Note that there are no constraints on the reuse mechanisms of dependees and dependent elements or on the reuse mechanisms of relational elements and their associated source and target elements, as these are separate elements whose reuse may differ.

Appendix C: The Experiment Questionnaire

Below are the models and translation of the 15 comprehension questions given to the ‘reuse and variability’ group. The questions of the other three groups were identical to the questions provided here, while the different models can be found with the experimental material at http://mis.hevra.haifa.ac.il/~iris/research/SPLEeval/ComADOM.htm#reusability.

• 1. A product in the CICO line may include an item reservation. In this case, only borrowers and workers can perform this activity that cannot undergo any refinement or extension.

• 2. Each product in the CICO line must interact with either private borrowers or cooperation borrowers.

• 3. In case a product in the CICO line has the functionality of “Check-In with Fee Calculation”, then it must include the functionality of “Calculate Fee” too.

• 4. In the CICO line there might be products which will not include explicit reference to fee calculation (through use cases, such as “Check-In with Fee Calculation”, “Check-In with possible Fee Calculation” or “Check-In without Fee Calculation”).

• 5. In the CICO line there might be products that support both Lending Policy and Waiting Lists.

• 6. Products within the CICO line may include associations of type “handle” between Borrower and Lending that are not of type “manage” nor of type “perform”.

• 7. Products in the CICO line may include Items with no loan fee information nor location details.

• 8. An Item in a CICO product may have both loan fee information and location details.

• 9. A product in the CICO line may include a virtual item that exhibits a method for calculating reservation fees which receives the actual lending period as a parameter.

• 10. In each product in the CICO line, a class of type Lending should be related to exactly one class of type Borrower.

• 11. In each product in the CICO line, if a class of type Borrower is associated to a class of type Lending with an association of type “manage”, then there should be an association class of type “managing” which documents the changes.

• 12. There might be a product in the CICO line in which a controller object will not be involved in a scenario of Check-Out Item to Borrower.

• 13. In a Check-Out scenario of a CICO product, one can borrow both virtual and physical items.

• 14. In a CICO product, a controller object can send messages other than getItemDetails and verifyStatus to an Item object while executing the scenario named “Check-Out Item to Borrower without Waiting List”.

• 15. It is possible that in a CICO product that does not define a waiting list, the combined fragment named “Check Out-Item to Borrower with Waiting List” will be executed while performing Check-Out.

  Fig. 11

  

  CICO model: the top level use case diagram

  Fig. 12

  

  CICO model: the Borrower variation point

  Fig. 13

  

  CICO model: the Check In Item variation point

  Fig. 14

  

  CICO model: the top level class diagram

  Fig. 15

  

  CICO model: the Item variation point

  Fig. 16

  

  CICO model: the Handle variation point

  Fig. 17

  

  CICO model: the check out scenario

  Fig. 18

  

  CICO model: check out without waiting list

  Fig. 19

  

  CICO model: check out with waiting list