Application Scenario

In this section, we investigate the claim that component encapsulation can facilitate the systematic development of models. We provide an application scenario concerned with the collaborative development of a web application using purpose-tailored DSMLs. Inspired by a similar scenario first introduced in [8, 57], the application under development is an administrative web application for a vehicle rental company. The models in the scenario are based on the domain and hypertext DSMLs introduced in Sec. 3.2.1. We assume that these languages have been subject to encapsulation, yielding the meta-model components as pro-vided in Fig. 3.4. We discuss the scenario in the light of the following research questions:

• RQ1: Is component encapsulation suitable to facilitate indepen-dent editing while ensuring consistency of model components?

• RQ2: Is the same language-level encapsulation useful when ap-plied to different application scenarios?

First, we demonstrate the scenario in detail, considering a sequence of six revisions during collaborative development. Second, we discuss observations concerning the research questions.

3.8 Application Scenario 63

Figure 3.17:Overview of the application scenario, indices denoting re-vision numbers of the individual models.

Demonstration

The scenario, shown in Fig. 3.17, features three team members, Saman-tha, Frank, and Mike. Samantha is the team manager; she assigns the remaining team members to viewpoints: Frank becomes the domain modeler. Mike becomes the hypertext modeler.

The starting point of the scenario are existing data and hypertext mod-elsDandH, being connected using remote references. In the first revi-sion, Samantha encapsulates along the given language-level encapsula-tion, replacing the remote references with export and import interfaces.

The internal details of remote components are hidden to both develop-ers respectively: Frank’s scope of visibility is restricted to his assigned component being D. Mike’s scope of visibility comprises his assigned component being H, and remote component D’s export (cf. the notion of weak composite graphs introduced in Sec. 3.4).

Samantha, Frank, and Mike perform a series of asynchronous and syn-chronous editing steps, reflected in increasing revision numbers. One editing step introduces an inconsistency, being reconciled in a subse-quent revision. We consider all six revisions in detail.

Revision 1. (Fig. 3.18)This revision comprises the initial state of the involved models. We show the revisions in a textual notation, which provides an alternative concrete syntax to the one shown earlier. As

in-Figure 3.18:Revision 1: Models with remote references.

Figure 3.19:Revision 2: Models aftercomponent encapsulation.

dicated by the four occasions in the hypertext model where model ele-ment names are prefixed with the name of the data model VehicleRental-Data, the two models are connected using remote references.

Revision 2. (Fig. 3.19) As triggered by Samantha, component encap-sulation of the models along the encapencap-sulation of the DSMLs has been performed. Each model now contains a dedicated interface: The data model contains an export interface. The hypertext model contains an import interface referencing this export interface. The model elements exchanged between these interfaces are named explicitly. The remote references have been replaced by plain references to the imported ele-ments.

3.8 Application Scenario 65

Figure 3.20:Revision 3: Models after performingadd attribute.

Figure 3.21:Revision 4: Models after performingremove entity.

Revision 3. (Fig. 3.20)Frank has introduced a new attribute for main-taining the manufacturer of a car, an asynchronous editing step only af-fecting one component. This step is neutral to inter-model consistency and does not require conflict handling.

Revision 4. (Fig. 3.21)As required by a law change prohibiting the storage of credit card information, Frank has removed the entity Credit-Cardfrom the data model. Since this editing step involves the deletion of an exported model element, it is a critical editing step threatening consistency. Frank receives a warning. His options are: to manually establish communication to Mike clarifying the change, to let a default message be delivered to Mike, to take back the change or to do nothing.

In the two former cases, Mike can react by performing an editing step to retain consistency.

Figure 3.22: Revision 5: Models after reconciling the inconsistency in-troduced in Revision 4.

Figure 3.23: Revision 6: Models after performingadd corresponding en-tity and index page.

Revision 5. (Fig. 3.22) Frank has decided to inform Mike about the change, so that Mike has been able to react immediately. Mike has re-moved the page that shows the credit card information from the hyper-text model.

Revision 6. (Fig. 3.23) To support the management of agencies, a new requirement requested by the customer, Samantha has performed a synchronous editing step changing both components in parallel.

Eventually, Samantha decides that the model components have accom-plished a stable state and should be used for code generation. A global consistency check may be performed before the code generation to en-sure a valid result. If at some later point in time new requirements are added, the components can be further evolved.

3.8 Application Scenario 67

Discussion

Below, we discuss the two research questions outlined in the beginning of this section.

RQ1: Is component encapsulation suitable to facilitate independent editing while ensuring consistency of model components?

In accordance with the original motivation, the maintenance of explicit export and import interfaces supported a smart and relaxed conflict avoidance in this scenario: At all times, developers were aware whether their editing is either safe or critical to inter-model consistency. In the case of critical steps, further intervention became necessary. An au-tomatized conflict detection and resolution algorithm can be consid-ered complementary and might be applied at any time throughout the development process. Especially a conflict detection step right before the code generation step is highly desirable.

RQ2: Is the same language-level encapsulation useful when applied to different application scenarios?

The language encapsulation of theSwalData andSwalHypertext meta-models, originally introduced in Fig. 3.4 together with a different ex-ample model to illustrate the approach, was sufficient to enable consis-tent editing most of the time while helping to reconcile an inconsistency immediately in one occasion.

Threats to validity and limitations

In this section, we considered only one scenario for the proposed pro-cess, a potential threat to external validity. In addition, the considered scenario is an artificial one. A more diverse, preferably empirical vali-dation is required to ensure the utility of our approach in realistic set-tings.

A threat to construct validity involves our notion of “usefulness” of the language-level encapsulation. As one caveat, we identify the

sit-uation where the application model developers need to inspect addi-tional model elements to understand the context of imported elements.

For instance, in order to understand the intention of a specific class, it might be reasonable to introduce references and attributes as well.

This requirement can only be satisfied by extending the language-level encapsulation.