SMarty Components

 

SMarty Components is an extension of UML Components for product-line architecture design. The activities of UML Components produce a use case and a business type model. According to the SMartyProcess, both models might be used to produce variability models for a PL by following guidelines which suggest how to apply the SMartyProfie to manage variabilities. Thus, SMarty, by means of the SMartyProcess guidelines, is applied to the UML Components models to identify, delimit and represent their respective variabilities. Therefore, the extension of UML Components by means of SMarty is represented as follows: (i) the Business Type Model from UML Components is the input to the SMartyProcess to define the Business Type Variability Model (line 2 of Table 1); and (ii) the Component Architecture from UML Components is the input to define the Variability Implementation Model (line 3 of Table 1). Although SMarty is able to manage variabilities at the use case level, in this work we only take into consideration the class and component levels as they represent product-line architectures, but it could be made according to the line 1 of Table 1.

 

Table 1. SMarty Components

Ord

UML Components

SMarty (SMartyProcess)

Activity

Output

Activity

Output

1

Use Case Model Definition

Use Case Model

Variability Identification and Delimitation

Use Case Variability Model

2

Business Type Model Definition

Business Type Model

Variability Identification and Delimitation

Business Type Variability Model

3

Architecture Definition

Component Architecture

Variability Implementation Mechanism Identification

Variability Implementation Model

 

Mobile Media Architecture Design using SMarty Components

 

Mobile Media [2, 8] is a product-line composed of features that handle music, videos, and photo for portable devices, such as cell phones and PDAs. Such a PL provides support for managing different types of media. The existing Mobile Media designs have been systematically revisited in the last years [1, 2] since the first implementation [1] has been released. For instance, similar modularity and stability measures (Section Quantitative Analysis) were previously used to guide the existing designs of Mobile Media [1, 2]. As a consequence, Mobile Media has been used by several researchers (e.g. [1, 3]) as a benchmark to evaluate a wide range of component- and aspect-based techniques.

 

Component-based Architecture

 

SMarty Components was applied to the Mobile Media product line without any kind of access to the existing Mobile Media designs. As a result of the application of this approach, Figure 1 presents the variability use case model for Mobile Media. It can be observed in Figure 1 that all variabilities are tagged. There are three well-defined variation points tagged with <<variationPoint>>. The first one is the use case where the User can setup how media is sent to other devices. Such a variation point is also optional. The second one is related to the use case Play Media, where the User sets up how media plays. The third one is the use case Manage Media. Note that the last two variation points are compulsory.

Fig. 1. Mobile Media Variability Use Case Model according to SMarty Components.

 

There is a relationship tagged with <<requires>> between the use cases Play Media and Manage Media. It defines that media management can only be realized if playing media is selected. In addition, there are optional features, such as: relating media to contact, playing media as ring tone, naming files, and managing favorite media. The <<requires>> relationship between Link Media with Address Book Entry and Play Media determines that only device-compliant media can be related to a contact.

 

SMarty was also applied to the Mobile Media business type model to generate its variability business type model (Figure 2). Thus, tracking of variabilities is kept at the business type level, as every variability from Figure 1 is also present in Figure 2. Then, a component-based architecture was proposed to Mobile Media product line (Figure 3). The component-based architecture presents the AlbumCtrl and MediaCtrl components which manage the album and media respectively.

 

Fig. 2. Variability Business Type Model according to SMarty Components

Fig. 3. The Mobile Media Component-based Architecture

 

Component-based AO Architecture

 

An alternative aspect-oriented architecture was also designed for Mobile Media in order to evaluate the results achieved by the use of SMarty Components. For supporting the design of aspect-oriented (AO) elements, a complementary method, called DSBC/A, was used. DSBC/A [4] is an extension of UML Components that allows designing component-based AO architectures. This method follows the UML Components process with additional activities to modularize crosscutting features.

The use of DSBC/A guides the elaboration of functional and non-functional models and the interaction between them; the goal is to identify transversal and aspectual elements in the architectural design. Therefore, it must identify non-functional variabilities in its use case and business type models. In addition, DSBC/A enables to identify crosscutting interfaces for the aspectual components in charge of modularizing crosscutting features. SMarty Components must be applied to such interfaces in order to generate corresponding variability implementation models.

Figure 4 shows the component-based AO architecture for Mobile Media. The major differences between the two alternative architectures for AGM are in the inclusion of aspectual components represented by the stereotype <<aspect comp spec>>. These components encapsulate operations that crosscut the whole system to improve modularization. For instance, the component PersistDataMgr encompasses the persistence operations which are required in several parts of the architecture. The component ExceptionHandlingMgr is responsible for operations related to error handling and recovery. The latter components were revealed in the identification of transversal use case present in Mobile Media. These components were scattered in several parts of the product-line design and, according to DSBC/A, they are candidates to be implemented as aspects. In addition, the basic and crosscutting operation were separated as, for instance, the interface IPersistableAlbum that is crosscut by the aspectual component PersistDataMgr.

 

Fig. 4. The Component-based AO Architecture of Mobile Media.

 

From these alternative architectures of different styles [5] (i.e. component-based vs component-based AO architectures), we performed a qualitative and quantitative analysis of results. The quantitative analysis is presented in the following section.

 

Quantitative Analysis

 

The objective of the metrics applied was to analyze if the developed architectures are likely to entail proper designs from the point of view of modularity and stability. The instability measure (I) [6] takes into account the coupling represented in the relationships between components with the objective of predicting the difficulty of modifying a component. Tightly coupled components are very instable and difficult to be reused. The instability is calculated by equation (1), where Ce represents Efferent Coupling, which is the number of elements of a component that depend on external elements and Ca represents Afferent Coupling, which is the number of external elements of a component that depend on its internal elements. The expected values are on the range [0,1], where 0 is minimal instability and 1 is maximum instability.

 

I = Ce / (Ca+Ce)            (1)

 

The values of I for Mobile Media alternative architectures can be seen in the graphic of Figure 5. Medium values for the instability measures were achieved. This indicates that the components are not very strict as well as little stable. This means that the components may allow modifications but control must be in place to avoid impacts and dissemination of changes for the whole architecture.

 

Fig. 5. Instability measure values for Mobile Media’s PLAs.

 

The cohesion measure (H) [7] calculates the medium number of relationships between classes and interfaces inside a component. It is measured by equation (2) where N represents the number of elements inside a component and R is the number of relationships inside a component.

 

H = (R+1) / N            (2)

 

The value 1 is added to R to avoid H to be 0 when N is 1. Measure H supports designers to identify components which have not strongly-related elements. This means that component cohesion is weak. The H values for Mobile Media alternative architectures can be seen in Figure 6.

 

Fig. 6. Cohesion measure values for Mobile Media architectures.

The cohesion measures have indicated that the internal elements of components present a reasonable number of relationships. This means that the components are cohesive. The relationships are designed according to the dependencies needed for the component behavior. When the number of relationships is low, the components are not cohesive, thus requiring redesign to improve the architecture.

 

Although the measures H and I has been proposed to implementation level, we used them in our evaluation in the architectural level. In addition to these measures, concern metrics [2] have also been considered. These metrics aim at evaluating the degree of modularization of an architectural design in terms of the architectural concerns being realized. They are relevant in the design of product lines because if features are not neatly encapsulated in specific components, product line architecture may negatively impact reusability and maintainability of the product-line. The metrics Lack of Concern-Based Cohesion (LCC) and Concern-Diffusion over Architectural Components (CDAC) were collected. They are intended to measure the degree of tangling and scattering of each feature in the product line architecture designs.

 

The metric LCC calculates the number of features associated with a certain component; the metric also considers the number of distinct features associated with its interfaces plus the number of distinct features associated with the interface operations. This metric indicates that a component that addresses many features is not very stable as a modification in any of the associated features may impact the others. The values of these measures for the Mobile Media architectures are shown in the graphic of Figure 7.

 

Fig. 7. LCC values for Mobile Media’s PLAs.

 

The results of LCC show that the component-based architecture present a higher number of features implemented by each components than the component-based AO architecture. As expected, the product line architecture developed using DSBC/A contains only one feature per component. This difference is due to the possibility of encapsulating crosscutting feature into aspectual components.

 

The measure CDAC calculates the number of components that contribute to the realization of a certain feature. It takes into account both the components that exclusively contribute to a feature and those which have at least one interface or operation associated with a feature. This measure considers that a feature scattered through a high number of elements has negative impact on modularity.

 

The values of CDAC are shown in Figure 8. The component-based AO architecture presents low values to exception handling and persistence whereas component-based architecture presents higher values. This reflects the scattering of those crosscutting features across several components. These values are higher due to the same reasons that justify the difference between the values of LCC.

 

Fig. 8. CDAC values of the Mobile Media’s PLA.

 

From the point of view of coupling and cohesion, SMarty Components lead to effective architectural solutions for Mobile Media. Although the architectures present differences in respect to feature modularization, the values of CDAC and LCC are acceptable with respect to modularization. These are good indicators that SMarty Components can lead to the design of modular architectures. In addition, by using a PL variability management approach, there is the possibility of applying measures that reveal the differences between possible architecture versions of product lines. Thus, the best architecture can be chosen according to the business drivers.

 

Qualitative Analysis

 

This section presents a qualitative evaluation of the two PLAs in which the variability design was supported by SMarty. Our goal is to gather additional insights that complement the quantitative evaluation and enable us to better understand the efficacy of using SMarty Components. Our evaluation is conducted in the context of both Mobile Media and Arcade Game Maker.

The Mobile Media architectures were evaluated and contrasted against the designs previously conceived by their actual developers. The existing decompositions of the Mobile Media architectures were carefully designed with modularity and maintainability as the driving factors [1,2]. This strategy was applied to both purely component-based and component-based AO architectures. Moreover, the architects and developers of Mobile Media were available to discuss with us and reflect upon the quality of both architectural designs generated. In our discussion with them, we have also analyzed to what extent the domain-specific and non-functional features were satisfactorily realized by the generated architectures.

The decompositions of the generated component- and aspect-based architectures were found to be very similar to their existing counterparts as developed by the actual Mobile Media architects. However, two interesting major differences were observed. First, there were two components playing the role of controllers (namely, MediaCtrl and AlbumCtrl) in both component- and aspect-based architectures.

On the other hand, their existing counterparts had nine controller components, each of them realizing a specific interface. In our generated architectures, these interfaces were aggregated in the coarse-grained components MediaCtrl and AlbumCtrl. Even though these differences may be related to specific design decisions, the original design of Mobile Media had, in fact, only one single controller. As new variations were introduced through the Mobile Media project lifetime, the general controller started to be incrementally decomposed in more specific ones. In addition, the use of SMarty Components follows a proactive approach, where the design is directly conceived from the requirements.

The original designs of Mobile Media architectures followed an iterative process where the original architectures were revisited after implementation-level decisions were made. Once a first draft of Mobile Media architecture is released, someone could revisit the decision about the number of controllers. For instance, a careful analysis of stability metrics used in our study (e.g. Figures 5 and 6) reveals that MediaCtrl and AlbumCtrl would be major candidates for instability. Second, our generated aspect-oriented design embraced only two aspectual components. Both of them were realizing non-functional features, i.e. persistent storage (or persistence) and robustness (or error handling). On the other hand, the actual architecture of Mobile Media has nine aspectual components. Only one component addresses a non-functional feature, i.e. error handling. All the other architectural aspects implement domain-specific crosscutting features. In this case, we considered that the discrepancy was considerable. However, the feedback of the original developers was the following. First, it is an interesting alternative to realize persistence as an aspect in Mobile Media. They did not follow this path due to their overall design strategy: aspects were to be only used to implement optional or alternative features of the product line. Persistence has been a mandatory feature until the latest release of Mobile Media. Second, their aforementioned design strategy explains why even non-crosscutting features were aspectual components, differing from our generated component-based AO architectures.

 

References

 

1. Figueiredo, E.; Cacho, N.; Sant’Anna, C.; Monteiro, M.; Kulesza, U.; Garcia, A.; Soares, S.; Ferrari, F.; Khan, S.; Castor Filho, F.; Dantas, F.: Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability. In: 30th International Conference on Software Engineering (ICSE’08). pp. 261–270. ACM (2008)

2. Sant’Anna, C. N.: On the Modularity of Aspect-Oriented Design: A Concern-Driven Measurement Approach. Doctoral Thesis. PUC-Rio, Rio de Janeiro, Brazil (2008)

3. Nguyen, T. T.; Nguyen, H. V.; Nguyen , H.A.; Nguyen, T.N.: Aspect Recommendation for Evolving Software. In: 33th International Conference on Software Engineering (ICSE’11). IEEE (2011)

4. Eler, M.M.; Masiero, P.C.: Aspect as Components. In: 9th International Conference on Software Reuse. LNCS - Reuse of Off-the-Shelf Components. v. 4039, pp. 411–414. Springer, Berlin (2006)

5. Clements, P.; Bachmann, F.; Bass L.; Garlan D.; Ivers, J; Little, R.; Merson, P.; Nord R.; Stafford, J.: Documenting Software Architectures: Views and Beyond. Addison-Wesley (2010)

6. Martin, R.: Stability. C++ Report, (1997)

7. Martin, R.: Agile Software Development: Principles, Patterns, and Practices. Prentice Hall (2003)

8. Young, T.: Using AspectJ to Build a Software Product Line for Mobile Devices. MSc Dissertation, University of British Columbia (2005)