Using Design Structure Matrices to Assess Modularity in ... - CiteSeerX

Using Design Structure Matrices to Assess Modularity in Aspect-Oriented Software Product Lines Pedro Matos Jr Rafael Duarte Ivan Cardim Paulo Borba Centro de Inform´atica, Universidade Federal de Pernambuco. Recife PE, Brazil {poamj, rmd, icc2, phmb}@cin.ufpe.br

Abstract

components of an application [6]. In these approaches, the chosen design parameters are implementation artifacts like classes, interfaces, aspects, packages, among others. As far as we know, there are no reports on the use of this approach in the context of Aspect-Oriented SPLs. On this paper, we report our experience in assessing the modularity of a mobile game product line using DSMs.

This paper presents our experience on assessing the modularity of software product lines through the dependencies found using design structure matrices. We conducted a case study on a mobile game software product line and we were able to identify some important dependencies between the modules.

2. Case study 1. Introduction

We conducted a case study on a real mobile game product line, created and evolved using the method described in [1]. Our first step was to decide which design parameters were relevant. If we had chosen classes and aspects as design parameters, the DSM would have been very complex to build for a preliminary study. Packages offered the necessary information, so we chose them instead. In our DSM, a design parameter A depends on another one B when any class/aspect in A references any class/aspect in B. Also, when an aspect from package C introduces static members or extra behavior to a class/aspect from package D, design parameter D depends on design parameter C. This dependency exists because a class in C relies on the existence of another artifact which introduces the missing parts, therefore being statically or semantically incomplete.

Software product lines (SPLs) are families of software systems that share a common set of features and are developed from a common set of core assets [3]. In addition to a common set of features, the instances (products) of a SPL have a specific set of variable features. Because some features can be present in only a particular subset of products, the development of SPLs demands programming technologies able to implement these features in a modular fashion. There are a number of techniques for managing variability from requirements to code level, most of which rely on object-oriented concepts. These techniques, however, are well-known for failing to capture crosscutting concerns, which often appear in highly variant domains. In a previous work, we have proposed a method for creation and evolution of SPLs relying on Aspect-Oriented Programming (AOP) and the use of refactorings for extracting variations [1]. Although we applied this method successfully in some case studies, we still lack an effective mechanism to assess the modularity in the created SPLs. Design structure matrices (DSMs) [2] are important tools to analyze dependencies between the design elements of a product, namely design parameters. A DSM is a matrix where each row and column represent a design parameter. An X in the cell corresponding to the ith row and jth column of the matrix indicates that design parameter i depends on design parameter j. In the aspect-oriented software development context, DSMs have been used to represent dependencies between

3. Results One of the benefits of using DSMs was the facility to identify cyclical dependencies between classes and aspects. Some techniques have been proposed to introduce interfaces between classes and aspects [4, 7, 5]. These interfaces can be represented as design rules 1 in the DSM, eliminating the cyclical dependencies. However, most of these techniques only deal with static dependencies, leaving the semantic dependency between classes and aspects unsolved. 1 A design rule is a design parameter used as an interface between modules and that are less likely to be changed [2]

1

Our study reinforces the idea that a more elaborated interface between classes and aspects is necessary. Our analysis shows that such interfaces can be even more useful when packages that implement mandatory features 2 are affected by aspects in packages that implement alternative features 3 , especially in cases when the package that implements the mandatory feature depends on all the packages that implement the group of alternative features. If we introduced an interface between these packages we would have a design rule representing the interface and all packages depending on it. This scenario would be better than the first one, because the package which implemented the mandatory feature would only depend on one design rule, instead of depending on a group of design parameters. For example, consider a SPL where game.gui is a package containing code artifacts responsible for drawing the user graphic interface of a game. This package implements a feature common to all products and is present in the build file of every instance of this SPL. Lets assume that the screen size of the device is a variation handled in this SPL. The packages game.screen.128x128, game.screen.128x117 and game.screen.128x160 implement three possible screen sizes. Each of these three packages contains code artifacts (classes, aspects and interfaces) that implement the screen size concern. Each one of these packages has aspects that are responsible for adding static members and extra behavior to classes in the game.gui package in order to implement this concern. Based on our definition of dependency, each of the screen packages depends on the game.gui package, as they contain aspects that refer to members of this package. On the other hand, game.gui depends on each of these three aspects because it assumes that they will add the screen concern functionality to it. Figure 1 shows the DSM for this SPL.

Figure 1. Cyclical Dependencies Screen size represents an alternative feature of this SPL. Therefore, only one of the three screen packages can be present in a build of and instance of the SPL. The package game.gui depends on the screen size packages, as they crosscut game.gui in order to introduce a missing part (screen size concern). In this particular case, game.gui has 2 Features

common to all products. group of features from which only one must be present on each product. 3A

a syntactic dependence on the screen size packages, because they introduce static members necessary for game.gui to compile. It should be noted, though, that in addition to syntactic dependency, modules might depend semantically on other modules. A semantic dependency between modules arise when a module does not depend on another to compile, but relies on its correct implementation to work properly. The differences between static and semantic dependencies are discussed in [8]. It is natural to think that game.gui should not depend on all three screen size packages, as it requires only one of them for each product build, although this is not represented by the DSM. This is a particular issue of SPLs, as they include alternative and optional features. A possible solution for this problem would be the introduction of a design rule, DR1, to eliminate these dependencies. The new design rule would be a contract stating that the screen size concern is introduced by another module in the game.gui package. Therefore, game.gui package would not depend directly on the other screen modules, depending only on DR1. On the other hand, DR1 also states that the code artifacts contained in game.gui must respect some restrictions in order for the aspects in the screen size packages to work properly. Thus, the three screen size packages package would depend only on DR1. Figure 2 shows the modified DSM.

Figure 2. Introduction of a Design Rule The new design rule, DR1, represents a set of interfaces between aspects and classes, all contained in the package game.designrules.DR1. Although we did not modify our case study SPL to include interfaces between aspects and classes, we believe that existing techniques [4, 7, 5] are a good starting point for defining these interfaces. The need for well defined interfaces between aspects and classes is still an open issue in this research area. The use of DSMs helped us identify cyclical dependencies between aspects and classes. It also helps do visualize the the extra benefits of well defined interfaces between aspects and classes in the SPL context, where classes may be crosscutted by several modules, each one implementing choices of an alternative feature. Although the class should depend solely on the abstract concept of the alternative feature, the lack of a well defined interface forces its developer

to be concerned about the implementation of each of the alternative modules. Therefore, SPL developers would not have the benefits of modularization, like independent development and modular reasoning.

4. Conclusions Although we are still in a very initial phase of our study, we believe that DSMs are a powerful tool to help in assessing the modularity of Aspect-Oriented SPLs. Based on our experience, we observed that the existence of well defined interfaces between classes and aspects, represented as design rules in DSMs, seems to be even more useful in the software product line context than in conventional software development, especially in SPLs with many alternative features. One problem of traditional DSMs is that they only capture the existence of dependence between two modules, but not the strength of these dependencies. They are not capable of representing the coupling level between two modules, like some software metrics would do. However, some approaches modify the original DSM notation to express the degree of dependence between modules [9]. Some decisions about the use of DSMs to assess the modularity of SPLs should be investigated. One of the them is the choice of design parameters. For our case study, we chose packages, but other design parameters must be considered. Design parameters could be source code artifacts like aspects and classes, but could also be features, design restrictions, among others. Another decision is wether we should use only one DSM, containing all the design parameters of a SPL (including the optional and alternative ones) or create a DSM for each instance of the SPL, each one containing only the design parameters related to a specific instance. There is still a lot of work to be done such as defining how the interfaces between classes and aspects should be defined (possibly at programming language level), in order to create the design rules. Also, the case study needs to be further developed to include these interfaces, so we can see how efficiently they address the problems we found, their disadvantages and possible solutions for them.

5. Acknowledgments We would like to thank Alberto Costa Neto and other members of Software Productivity Group4 for the help on the paper review. We also extend our thanks to CNPq and Capes, Brazilian research funding agencies, for partially supporting this work. 4 http://www.cin.ufpe.br/spg

References [1] V. Alves, P. M. Jr., L. Cole, P. Borba, and G. Ramalho. Extracting and Evolving Mobile Games Product Lines. In Proceedings of the 9th International Software Product Line Conference (SPLC’05), volume 3714 of Lecture Notes in Computer Science, pages ”70–81”. Springer-Verlag, Sep 2005. [2] C. Y. Baldwin and K. B. Clark. Design Rules, Vol. 1: The Power of Modularity. The MIT Press, March 2000. [3] P. Clements, L. Northrop, and L. M. Northrop. Software Product Lines : Practices and Patterns. Addison-Wesley Professional, August 2001. [4] W. G. Griswold, K. Sullivan, Y. Song, M. Shonle, N. Tewari, Y. Cai, and H. Rajan. Modular Software Design with Crosscutting Interfaces. IEEE Software, 23(1):51–60, 2006. [5] U. Kulesza, R. Coelho, V. Alves, A. C. Neto, A. Garcia, A. von Staa, C. Lucena, and P. Borba. Implementing Framework Crosscutting Extensions with EJPs and AspectJ. In Proceedings of the 20th Brazilian Symposium on Software Engineering (SBES 2006), Oct 2006. [6] C. V. Lopes and S. K. Bajracharya. An Analysis of Modularity in Aspect-Oriented Design. In Proceedings of the 4th International Conference on Aspect-Oriented Software Development (AOSD’05), pages 15–26, New York, NY, USA, March 2005. ACM Press. [7] A. C. Neto, V. Alves, and P. Borba. Declaring Static Crosscutting Dependencies in AspectJ. In 3rd Brazilian Workshop on Aspect-Oriented Software Development (WASP’06), in conjunction with the 20th Brazilian Symposium on Software Engineering (SBES’06), Florianopolis, Brazil, Oct 2006. [8] A. C. Neto, M. Ribeiro, M. Dosea, R. Bonifacio, P. Borba, and S. Soares. Semantic Dependencies and Modularity of Aspect-Oriented Software. In 1st Workshop on Assessment of Contemporary Modularization Techniques (ACoM’07), in conjunction with the 29th International Conference on Software Engineering (ICSE’07), Minneapolis, USA, May 2007. ”To appear”. [9] N. Sangal, E. Jordan, V. Sinha, and D. Jackson. Using dependency models to manage complex software architecture. In OOPSLA ’05: Proceedings of the 20th annual ACM SIGPLAN conference on Object oriented programming, systems, languages, and applications, pages 167–176, New York, NY, USA, 2005. ACM Press.