Exploring the Commonality in Feature Modeling Notations

Transcription

1 Exploring the Commonality in Feature Modeling Notations Miloslav ŠÍPKA Slovak University of Tehnology Faulty of Informatis and Information Tehnologies Ilkovičova 3, Bratislava, Slovakia Abstrat. Feature modeling is an important approah to apturing ommonalities and variabilities in system families and produt lines. This artile analyzes the ommonalities and variabilities among different approahes to feature modeling with respet to their use in order to determine how feasible is to unite their notations into a onsistent unit and support them in a single feature modeling CASE tool. Suggested notation basis ombines the extended Czarneki- Eiseneker notation (with UML like ardinalities) with Gurp-Bosh- Svahnberg edge deorations and identifies mandatory parts of the information assoiated with features. 1 Introdution Feature modeling is the ativity of modeling the ommon and the variable properties of onepts and their interdependenies and organizing them into a oherent model referred to as a feature model [1]. A feature model represents the ommon and the variable features of onept instanes and the dependenies between the variable features. Model represents the intention of a onept, whereas the set of instanes it desribes is referred to as the extension of the onept. A feature model onsists of a feature diagrams and some additional information suh as short semanti desription of eah feature, rationale for eah feature, onstraints, default dependeny rules et. A feature diagram onsists of a set of nodes, a set of direted edges, and a set of edge deorations. The nodes and the edges form a tree. he edge deorations are drawn as ars onneting subsets or all of edges originating from the same node. Supervisor: Ing. Valentino Vranić, PhD., Institute of Informatis and Software Engineering, Faulty of Informatis and Information Tehnologies STU in Bratislava M. Bieliková (Ed.), IIT.SRC 2005, April 27, 2005, pp

2 140 Miloslav Šípka A mandatory feature is inluded in the desription of a onept instane if and only if its parent is inluded in the desription of the onept. If the parent of a mandatory feature is optional, the mandatory feature should not be part of the desription. A mandatory feature node is pointed to by a simple edge optionally ending with a filled irle (Fig. 1 row 1). An optional feature may be inluded in the desription of a onept instane if the parent is inluded. If the parent is not inluded, the optional feature annot be inluded. An optional feature node is pointed to by a simple edge ending with an empty irle (Fig. 1 row 1). A onept (and similarly a feature) may have one or more sets of diret alternative features. If the parent of a set of alternative features is inluded, then exatly one feature from this set of alternative features is inluded in the desription, otherwise none. The nodes of a set of alternative features are pointed to by edges onneted by an ar (Fig. 1 row 2). A onept (and similarly a feature) may have one or more sets of diret orfeatures. If the parent of a set of or-features is inluded in the desription of a onept instane, then any non-empty subset from the set of or-features is inluded in the desription, otherwise none. The nodes of a set of or-features are pointed to by edges onneted by a filled ar (Fig. 1 row 3). Feature modeling helps us to avoid two serious problems: First, relevant features and variation points are not inluded in the reusable software. Seond, many features and variation points are inluded but never used and thus ause unneessary omplexity, development ost, and maintenane ost. Finally, the feature models provide us with an abstrat (sine implementation independent), onise, and expliit representation of the variability present in the software. 2 A Survey of Feature Modeling Notations Today most aepted is Czarneki-Eiseneker notation. Its main advantages are that this notation is ompatible with the original FODA notation while at the same time bringing some new possibilities. In Fig. 1 the original FODA notation and both Czarneki-Eiseneker notations-the base and the extended one-are ompared.

3 Exploring the Commonality in Feature Modeling Notations 141 Original FODA notation [4] mandatory and optional subfeature Czarneki-Eiseneker notation mandatory and optional subfeature Extended Czarneki- Eiseneker [2] mandatory and optional subfeature alternative subfeatures XOR group [1..1] [0..1] group with ardinality <1-1> fn fn OR group <1-1> fn group with ardinality <0- k> <0-k> fn XOR group with optional subfeatures fn group with ardinality <0- k> <0-1> fn fn Fig. 1. Comparison of feature modeling notations [2] Another UML-based notation is the one used in FeatuRESB [3]. It expliitly deals with variation points. It defines stati and dynami binding in a variation point. This notation was overome by Gurp-Bosh-Svahnberg notation [6] whih has been developed for expressing variability in software produt lines. It brings OR and XOR speialization into variation points. Initially, the binding type was not represented as edge deorations, but this an be done using the flag at the feature. In Fig. 3, the two mentioned UML-based notations are onfronted with Czarneki-Eiseneker notation.

4 142 Miloslav Šípka Czarneki-Eiseneker notation XOR group FeatuRESB [3] Variation point feature, dynami binding Variability in software produt [6] XOR generalization dynami dynami XOR group Variation point feature stati binding Load time XOR generalization OR group OR generalization Fig. 2. Comparison of others feature modeling notations 2.1 Additional Information provided with features First additional information provided with features is binding time and binding mode. Binding time is important if we have to desribe implementation details of feature and ode with referenes feature. So it is important to identify binding time of feature. First of five binding time is soure time. The deision to bind feature is made by programmer or designer during the implementation phase. Other binding times are ompile and link time. In this ase the feature is bound automatially by preproessor or speial linker program. There is no reason to make differene between linking and ompile time. Some languages do not have linking at all. This three times represents stati binding. Other two types of bounding represent dynami bounding. It is load and rum time. Feature with load time bounding is seleted in instane of onept in time when the program loads in to memory. Feature with run time bounding an be seleted widely when the program is running. In both ases we must implement feature and ompile it.

5 Exploring the Commonality in Feature Modeling Notations 143 But in fat implementing other modules an be different if feature an hange in run time of the program. Another additional information supported with feature is layer. FODA [4] identifies four layers of features. There are Operating environment layer, Capability layer, Domain tehnology and Implementation tehnique. But there an be need of more than four layers of features. So ategorization of features in layers is not so important and is used very rarely. One important ategorization is to identify if feature represents abstrat (idential as a abstrat lass in OOP) thing or have to be implemented and integrated as a part of ode. Other additional information provided with features and feature model in general are onstraints and default dependeny rules. Constraints represent neessary onditions eah instane of onept have to fulfill. Default dependeny rules represent rules of hoosing default feature while reating instane of a onept. In FODA the onstraints are redued to simple rules representing the so-alled requires and mutual exlusion relationships between features. A more sophistiated way of representing onstrains is to use prediate logi [5]. 2.2 Common parts of feature diagram notation After omparing several notations we an extrat the ommon parts. Czarneki- Eiseneker notation an at as a bakbone for this. The reason is simple: eah of the analyzed notations extends this notation. Original Czarneki-Eiseneker notation will be improved in two ways. The first is extending by ardinalities as it is in Fig. 1. The seond way is to identify relationship between a feature and its subfeature as in Fig Common parts of assoiated information It seems there are lot of information assoiated with features and feature diagram. If fat it is impossible to hoose set of information for ommon notation. The best way is let user to hoose with assoiated information he need. In this ase it is important to let user hoose what assoiated information will be displayed in a feature diagram and how. Truly ommon parts of assoiated information are onstrains and default dependeny rules. One effetive way to express onstraints is prediate logi [5]. 3 Conlusions In our survey we ompare six notations of feature model. We disover that there are no ollisions between these notations. Conerning feature diagram, eah notation introdues different quantum of information in diagram. At one side, information ontained in diagram doesn t have to be inluded as additional information. At other side feature diagram an be diffiult to read. Conerning additional information, we found that eah notation provides other type of information.

6 144 Miloslav Šípka Further work inludes developing of a metamodel that ontains all desribed notation elements. After that implementing a support tool whih will use this metamodel. So it allows user to hoose how to express relations between features, either in diagram or as assoiated information. Aknowledgement: This work has been partially supported by the Grant Ageny of Slovak Republi grant No.VG1/0162/03. Referenes 1. Czarneki, K. Eiseneker, U.W.: Generative Programming: Priniples, Tehniques and Tools. Addison-Wesley, Czarneki, K. Helsen, S. Eiseneker, U.W.: Staged Configuration Using Feature Models. In: SPLC 2004, LNCS 3154, R.L. Nord (Ed.), 2004, Giss, M. L. Favaro, J. d'alessandro, M.: Integrating Feature Modeling with the RSEB. In: Pro. of 5th International Conferene on Software Reuse, Vioria, B.C., Canada. IEEE Computer Soiety Press (1998), 4. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Featureoriented domain analysis (FODA): A feasibility study. Tehnial Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA, November Vranić, V.: Multi-Paradigm Design with Feature Modeling. PhD thesis, Slovak University of Tehnology in Bratislava, Group, J., Bosh, J., Svahnberg, M.: On the Notion of Variability in Software Produt Lines. In: Proeedings of WICSA 2001 (2001),