First International Workshop on Variability Modelling of Software-intensive Systems January 16–18, 2007 Limerick, Ireland Klaus Pohl, Patrick Heymans, Kyo-Chul Kang, Andreas Metzger (Eds.)
— Proceedings —
Lero Technical Report 2007-01
Message from the Organizers Welcome to VaMoS’07 – the First International Workshop on Variability Modelling of Software-intensive Systems! The goal of VaMoS is to help the variability modelling community to more thoroughly understand how the different variability modelling approaches complement each other and how these approaches can be improved and integrated to better meet the needs of practitioners. To this end, VaMoS is planned to be a highly interactive event. Each session is organized in order to stimulate discussions among the participants (see page 4). The high number of submissions and the quality of the accepted papers show that variability modelling is an important field of research. We hope that VaMoS will stimulate work on new challenges in variability modelling and thus will help to shape the future of variability modelling research. In total, we have received 38 papers for VaMoS, out of which 20 were accepted. Each paper was reviewed by at least three members of the programme committee. Based on the PC members’ reviews, the final decision was taken by the organization committee during a two day meeting in Essen on the 1st and 2nd of December. The accepted papers address a wide range of topics relevant to variability modelling. In detail, the following topics are covered: • Requirements Engineering • Separation of Concerns & Aspects • Quality & Complexity • Embedded Systems & Context-awareness • Lifecycle & Evolution • Tools We like to extend our gratitude to all the people who offered their time and their energy to help make VaMoS a success. VaMoS’07 would not have been possible without their efforts and expertise. We are honoured and thankful that Dave Parnas has accepted our invitation to provide a keynote on “Software Product-Lines: What To Do When Enumeration Won’t Work”. We also like to thank all the members of the VaMoS programme committee for devoting their time to reviewing the submitted papers. We are grateful to the people who helped preparing and organizing the event, especially Niamh O’Donovan, Gerard Mulligan, and Thomas Preuss. Finally, we thank the main sponsors of VaMoS: Lero (The Irish Software Engineering Research Centre), University of Duisburg-Essen, and University of Namur. Enjoy VaMoS 2007 and beautiful Ireland! The VaMoS organizers
Klaus Pohl
Patrick Heymans
Kyo-Chul Kang
11
Andreas Metzger
22
Organization Organizing Committee Klaus Pohl, Lero, Limerick, Ireland & University of Duisburg-Essen, Germany Patrick Heymans, University of Namur, Belgium Kyo-Chul Kang, Pohang University of Science and Technology, Korea Andreas Metzger, University of Duisburg-Essen, Germany
Programme Committee Don Batory, University of Texas at Austin, USA Jan Bosch, Nokia Research Center, Finland Krzysztof Czarnecki, University of Waterloo, Canada Ulrich Eisenecker, University of Leipzig, Germany Hasan Gomaa, George Mason University, USA Øystein Haugen, University of Oslo, Norway André van der Hoek, University of California, Irvine, USA Jean-Marc Jezequel, IRISA, France Charles Krueger, BigLever Software, USA Frank van der Linden, Philips, The Netherlands Tomi Männistö, Helsinki University of Technology, Finland Dirk Muthig, Fraunhofer IESE, Germany John Mylopoulos, University of Toronto, Canada Linda Northrop, SEI, USA Bashar Nuseibeh, The Open University, UK David L. Parnas, University of Limerick, Ireland Pierre-Yves Schobbens, University of Namur, Belgium
33
Workshop Format As VaMoS is planned to be a highly interactive event, each session is organized in order to stimulate discussions among the presenters of papers, discussants and the other participants. Typically, after a paper is presented, it is immediately discussed by two pre-assigned discussants, after which a free discussion involving all participants follows. Each session is closed by a general discussion of all papers presented in the session. For VaMoS, each of the sessions will consist of two paper presentations, two paper discussions, and one general discussion. Three particular roles, involving different tasks, are taken on by the VaMoS attendees:
Presenter A presenter obviously presents his paper but additionally will be asked to take on the role of discussant for the other paper in his session. It is highly desired that you attend the complete event and take an active part in the discussion of the other papers. Prepare your presentation and bear in mind the available time, which is 15 min for the paper presentation.
Discussant A discussant prepares the discussion of a paper. Each paper is assigned to two discussants (typically the presenter of the other paper in the same session and a member of the programmme or organization committee or a presenter of another session). The discussants’ task is to give a critical review of the paper directly after its presentation. This task is guided by a predefined set of questions that are found in the discussion template provided by the VaMoS organizers.
Session Chair A session chair’s tasks are as follows: Before the session starts: - Make sure that all presenters and presentations are available. - Make sure that all discussants are present and that they have their discussions available on transparencies for the overhead projector (OHP). For each paper presentation: - Open your session and introduce the presenters. - Keep track of the time and signalize the presenters when the end of their time slot is approaching. - Invite the discussants and organize the individual paper discussions, i.e., ensure that the discussion is structured. - Close the paper discussion and hand over to the next presenter. After the last presentation: - Moderate the general discussion. - Finally, close the session when the time is over.
44
Table of Contents Keynote Software Product-Lines: What To Do When Enumeration Won’t Work ............................ 9 David L. Parnas Technical Papers Exploring the Dimensions of Variability: a Requirements Engineering Perspective ........ 17 Sotirios Liaskos, Lei Jiang, Alexei Lapouchnian, Yiqiao Wang, Yijun Yu, Julio Cesar do Prado Sampaio Leite, John Mylopoulos Requirements Modelling and Design Notations for Software Product Lines .................... 27 John Brown, Rachel Gawley, Ivor Spence, Peter Kilpatrick, Charles Gillan, Rabih Bashroush An Aspect-oriented Approach for Representing Variability in Product Line Architecture .................................................................................................. 37 Youngbong Kim, Mikyeong Moon, Keunhyuk Yeom Separation of Variability Dimension and Development Dimension.................................. 45 Isabel John, Dirk Muthig, Jaejoon Lee Modelling Variation in Quality Attributes ......................................................................... 51 Leire Etxeberria, Goiuria Sagardui, Lorea Belategi KumbangSec: An Approach for Modelling Functional and Security Variability in Software Architectures................................................................................................... 61 Varvana Myllärniemi, Mikko Raatikainen, Tomi Männistö Visualisation of Variability in Software Product Line Engineering .................................. 71 Daren Nestor, Luke O'Malley, Ernst Sikora, Steffen Thiel Unified Feature Modeling as a Basis for Managing Complex System Families ............... 79 Mark-Oliver Reiser, Ramin Tavakoli, Matthias Weber Adding Aspects to xADL 2.0 for Software Product Line Architectures ........................... 87 Nadia Gámez, Lidia Fuentes Language and UML Support for Features: Two Research Challenges.............................. 97 Roberto Lopez-Herrejon Using Goal-Models to Analyze Variability ..................................................................... 101 Bruno Gonzalez-Baixauli, Miguel A. Laguna, Julio Cesar do Prado Sampaio Leite
55
On the Structure of Problem Variability: From Feature Diagrams to Problem Frames................................................................................................................ 109 Andreas Classen, Patrick Heymans, Robin Laney, Bashar Nuseibeh, Thein Tun DecisionKing: A Flexible and Extensible Tool for Integrated Variability Modeling...... 119 Deepak Dhungana, Paul Grünbacher, Rick Rabiser FAMA: Tooling a Framework for the Automated Analysis of Feature Models.............. 129 David Benavides, Sergio Segura, Pablo Trinidad, Antonio Ruíz-Cortés Specifying Variability of an Extensive Mobile System for Feasible Stakeholder Communication and Optimized Delivered Product Architecture ................ 135 Lech Krzanik Challenges in the Application of Feature Modelling in Fixed Line Telecommunications ...................................................................................... 141 Charles Gillan, Peter Kilpatrick, Ivor Spence, Rachel Gawley, John Brown, Rabih Bashroush Using Problem Descriptions to Represent Variabilities For Context-Aware Applications............................................................................................ 149 Mohammed Salifu, Bashar Nuseibeh, Lucia Rapanotti, Thein Tun Layered design approach for context-aware systems....................................................... 157 Brecht Desmet, Jorge Vallejos, Pascal Costanza, Robert Hirschfeld A Plea for Help with Variability, in Two Acts ................................................................ 167 Reed Little, Randy Blohm Variability Models Must Not be Invariant!...................................................................... 171 Elmar Juergens, Markus Pizka
66
– Keynote –
79
8
Software Product-Lines: What To Do When Enumeration Won’t Work David Lorge Parnas Software Quality Research Laboratory (SQRL) Department of Computer Science and Information Systems Faculty of Informatics and Electronics University of Limerick, Limerick, Ireland
[email protected]
the most difficult to revise. If we want programs to implement a common interface, it is important to agree on that interface at the start of development rather than to try to revise the programs after completion1. These thoughts were generalized and published in [PA76], which was, as far as I know, the earliest paper to discuss the design and development of programfamilies. In this paper, I defined “program-family” by stating that, “A set of programs constitutes a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members”2. The essence of that paper was simple - when developing a family of programs, develop, and document, the common/shared aspects first. The documented decisions must be binding on the developers who work on the individual family members. I had a second encounter with the problem of multiversion software when designing software for the U.S. Navy’s A-7 aircraft [Pa77, NRL80, NRL81]. In this application, frequent replacement of peripheral devices was the rule rather than the exception and the software should have been designed in such a way that the software needed to operate new versions of these devices, could be written and “plugged in” quickly. In the original software, the substitution of a new device usually required difficult, and widespread, modification
Abstract The history of research on the development of program-families is briefly reviewed. Two distinct problems, configuration-management and family-design are identified. It is explained that, while software configuration-management is not fundamentally different from configurationmanagement for other products, in practice, inadequate attention to family-design exacerbates all problems associated with developing and maintaining program families. It is suggested that although enumeration is useable for configuration-management, product-line design by enumeration is not generally feasible. An alternative approach, family member characterization using abstract documentation, is discussed. This approach is practical for family-design and can make configuration-management easier. The advantages of designing an interface in terms of programs over an interface expressed as a data structure using conventions such as XML are also discussed.
1. Designing program-families: early history I first observed an industrial effort to develop a family of programs, in this case a product-line, in 1969. The developer’s plan was to develop three operating systems independently and, after all three were completed and functioning, meet to make them compatible for users and software. Even the limited software development experience accumulated by that time, made it clear that this was not likely to succeed. The earliest design decisions in a project are usually
1
Of course one can hide that interface but this requires agreeing on another, more abstract, interface. Only certain aspects of the interface are actually hidden.
2
It should be noted that this definition encompasses sets of programs that would not be included in what is commonly understood as a product-line. A program-family may include programs that are used for entirely different purposes.
9
of the code3. In our approach, the detailed characteristics of each of the devices would be “hidden” by a software device interface module that would be revised or replaced whenever a new type of device was installed4. The key to easing this replacement was to design and document an interface for the device dependent module that would not need to be changed even though the device, and the software that communicated directly with it had to be revised or replaced. We viewed this problem as one of designing for families of such software modules. Again, we found that the common aspects of these modules, in this case the interfaces to the rest of the software could be developed before developing any members of the family. In other words, we had to design software for a program-family at a time when we could not possibly know what members of the family would actually be built. The papers cited above discuss principles and procedures for designing lasting interfaces before the hardware is designed, i.e. before a domain analysis could be done. It may seem paradoxical, but the key idea to designing for variation, was to find, and document, the commonalities. This will be discussed further below.
combinations of “features5” that work badly or do not work at all. This leads to a different problem, one that is sometimes called variability management, but might better be called configuration-management; it is the problem of knowing which combinations will be useful and which make no sense. It has often been observed that maintaining a set of almost alike products is more difficult than maintaining a set of radically different products. The similarities lead to confusion. The situation gets worse as each variant is maintained separately and they begin to diverge as each team fixes a problem in a different way. Returning to my 30 year old definition, “it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members” we see that, because the commonalities are not documented, it is not easy to begin by studying them. As the products evolve, the commonalities often evaporate; the individuals maintaining individual family members often do not know that these properties should be preserved. In general, the commonalities that could or did exist are neither exploited nor maintained.
2. Program-families today
3. What is special about software productlines?
Today, more than 35 years later, many softwareproducing companies are faced with problems arising because they sell a large set of closely related products. For example, those who manufacture mobile phones must offer models that work in a variety of network connectivity protocols, offer a variety of features, and support a variety of provider specific services. As a result, I can buy two phones that look about the same but whose capabilities differ in many ways. The only difference may be the software. Those who produce car radios, telephone switches, and desktop software are all faced with the same problems; all of their products share basic functions in common but the developers must deal with many different configurations of hardware, environmental interfaces, and user interfaces. The simultaneous maintenance of so many variants leads to problems that were not often encountered in the early days of software development. Because the interfaces of the software components are complex, there are
I prefer the term “configuration-management” to “variability management” because the former term suggests that the problems are neither new nor unique to software. One finds the same problem with many types of products. For example, in the airline industry, improvements and part-substitutions while a plane is in active service are commonplace. Moreover, because it is economically important to keep the aircraft in service, a part may be replaced by a version with a different internal structure and hence different components. The part that was removed can be repaired (with reduced time-pressure) and later installed on another aircraft. As a result of this “replace now, repair and reuse later” policy, a model type such as “A320” actually denotes a huge family of aircraft versions and the set of versions actually in service varies frequently. Further, the timein-service of components in a given aircraft can be very different resulting in complex inspection and maintenance schedules. There has been at least one publicly known incident caused by substituting an “almost compatible” to get a plane “up” quickly. In
3
This was considered quite typical. In fact, the original software was considered to be of high quality. 4 The hardware did not allow us the luxury of having many alternative drivers in the software and having the software select the correct driver when a device is installed.
5
10
an overused and under-defined term
other words, all of the complexity that software developers are experiencing in managing product-lines can found in aircraft fleet maintenance. In spite of this, software researchers and developers seem to have the impression that software “variability management” is unique in its complexity. They have this impression for two, very different, reasons: • Many software developers are unaware of the complexity of the configuration-management problem in other Engineering fields; • It is especially difficult to “manage variability” in software because it is unreasonably difficult to predict which combinations of component versions or features will function properly. Whereas an automobile manufacturer is almost always aware that a certain engine variant may make a tyre type inappropriate, software developers are often surprised to discover that revising or replacing one application or component has implications for others. We have all experienced an “upgrade” that led to a problem with one of our other applications or components. The cause of the unexpected difficulties that software purveyors experience when dealing with product-lines is easy to explain: the interfaces between software components are complex, poorly understood, and poorly documented. It is because of this that when one version of a component is substituted for another, there may be unexpected consequences. In other words, the problem of variability management is often exacerbated by the fact that the design was done badly6.
having a great many code artefacts including classes of components that are almost alike but not interchangeable, and • having to deal with a large (but finite) set of functional and environmental alternatives some of which may be incompatible with others. The “symptomatic relief” comes in the form of: • emphasis on sharing concrete artefacts among family members, and • attempting to design software product lines by enumerating alternatives discovered in a “domain analysis”. These will be discussed in more depth in below. •
4.1. Commonalities need not be concrete code artefacts Many current articles on software product-line development propose either the development of a set of common components (e.g. frameworks) or the development of tools that will be used to produce the members of the product-line. Reviewing the early definition of program-family given in [Pa76], it should be obvious that the commonalities need not be executable code; commonalities might include such things as a user’s manual or even a “look and feel”; these can be shared by programs that have no instructions in common and were not generated by the same set of tools. There may be good reasons that make it impossible for a set of products to share any concrete artefacts, but we can still have them present a common interface to their user or share a common “architecture”. If we want such abstract properties to be shared, we need to make the corresponding design decisions, and document them, early in the development process.
4. Program-family design revisited The problems that companies are experiencing when managing software product-lines illustrates a decades-old software design observation, software projects are usually difficult to manage because the software is poorly designed. In the software field, as in many others, we often see researchers and developers studying, ways to treat, the symptoms rather than trying to find and eliminate the cause of those symptoms. In the case of “product-line” development, we see two approaches that I consider to be instances of treating the symptoms rather than the disease. The symptoms that we researchers are trying to cure are:
4.2. Enumeration is insufficient for designing program-families The dilemma faced by those who want to make common decisions for product-lines is that, as discussed in [NRL80, NRL81] we rarely know all the variants that will be needed when we start to develop a program-family7; under those circumstances, it is impossible to describe the family by enumerating all the members8. However, it is well known that there are 7 8
If we think we know, we are usually wrong.
In my experience, if I point out a missing alternative to someone who has illustrated an enumerative approach to product-line development, they shrug their shoulders and remark that they cannot be expected to see into the future or to know everything. While that
6
It can also be the case that the design was good and welldocumented but later ignored. I have seen this but it is rare simply because good well-documented designs are rare.
11
two ways to describe sets, one can either enumerate the members or describe a characteristic predicate, a predicate on the set of possible members that is true if and only if applied to a member of the set. The design of program-families requires that we use characterization rather than enumeration. Enumeration may be appropriate when managing a fixed set of products, but it will not work when we try to prepare for future variants, i.e. when we plan ahead.
not. Essentially, the designer must look for properties that all variants will possess and make sure that there are fundamental reasons for expecting those properties to be unchanged. These properties must relate to the functions that can be provided, not to the way that they are provided. For example, an interface for a navigation device can be written so that it applies to rotatable gyroscopes, gyroscopes that are fixed in inertial space, laser-based inertial measurement systems, and GPS-based systems. Although these use very different implementations, they must all provide the same information; programs that provide that information can be specified as the interface. [Pa77] and [NRL81] also discuss the design of more “powerful” interfaces that apply to a subfamily of the variants. When needed, we can define sub-families of the family, comprising products with additional properties, i.e. properties that are not shared by all members of the full family. Of course the interfaces must be described precisely in a way that can be used by those who implement components with that interface and those who write programs that interact with the specified component. Mathematical notations that can be used to document these shared interfaces in a way that is both precise and readable exist now. Our methods are based on the A-7 work (e.g. [NRL84]) but have been substantively improved and tested in a variety of applications (e.g. [PLD06, SQR05, SQR06]). Each interface specification document can be viewed as a representation of a predicate that characterizes a large set of possible implementations (variants). Only a few of these will ever be built, but a user program that is consistent with the interface as specified will be prepared to handle any of them. The specification documents may include parameters to account for visible variations in the interfaces. If such parameters are used, each implementation of the interface and each program using the interface can refer to the values of the parameters. A set of such documents, specifying the common requirements for all the components in the product, describes the “architecture9” for the family of products. If the managers exercise the discipline needed to make sure that all implementations conform to these specifications, configuration-management of the resulting program family becomes relatively simple.
5. Documents as representations of the characteristic predicate. As was mentioned above, software product lines are often difficult to manage because the component interfaces are not well understood or documented. One of the illnesses of the software development field is that interfaces are decided by implementers while programming, not by the architects or designers before implementation begins. Moreover, they are often defined by whoever “gets there first” with the result that they may not be optimal for others. Even when an interface is specified by the architects, the actually implementation often introduces undocumented communication channels or deviates in some undocumented but “necessary” way from what was specified. Precise interface documents can solve two problems: • they can make it possible to produce interchangeable versions of a component and thereby simplify the configuration-management problem, • they can characterize a set of implementations even if some characteristics of some existing or future members of the set are not known. Any implementation that conforms to the specified interface is a potential variant. Any program that can be written using the specified interface, and whose correctness could be proven using only information in the interface document, will work with any potential variant. When a new variant is introduced, the rest of the software is compatible with it provided that it satisfies the specification and the rest of the software assumes no additional properties. As discussed in more detail in [Pa77, NRL81] the design of these interfaces is not a “quick-and dirty” job. It requires careful research to determine what is possibly a variant and, perhaps more important, what is
6. An illustrative example: car radios
is undoubtedly true, [NRL80, NRL81], show that we can plan for the future by describing the commonalities in advance.
9
12
Another overused and under-defined word.
Designers and researchers who are warned that enumerating a set of known alternatives is not the right way to design a family of programs often (figuratively) throw up their hands, saying something like, “How can I possibly know all the variations that might come along in the future. They do not believe that they can be asked to state properties of some “to be developed product”. This section describes a simple example that shows how that can be done. The example is car radios. A quick tour of some car dealers will show that they vary in a huge number of ways including the layout of the controls, the technology used for tuner and amplifier, sensors available for background noise level, the number of speakers, etc. Those who designed the simple radio in my first car would be amazed at what we can buy today. Many of the new features are implemented with software. A manufacturer of such radios, especially one that sells a broad variety of radios to several automotive manufacturers, would like to take advantage of commonalities that exist. They must however do this without having the radios look alike or share certain features because their customers (the automobile manufacturers) want their radios to have special features that they can claim as unique selling points. The more one looks at the variety on the market and gets a sense for the rapid rate at which new capabilities are invented, the more discouraged one might become about finding a substantial set of commonalities. However, if we focus on what capabilities must be there, we get a different picture. Suppose that we want to design an interface to the control panel(s). These may change from a simple set of switches and rheostats on the dash, to “soft” panels that are images on a touch sensitive display, to sequence buttons on the steering wheel to a remote control or (perhaps even a programmable controller that switches programmes on schedule). In spite of the huge differences in arrangement and function, there are certain capabilities that a radio control panel must have. Some examples are: • It must be possible to determine if the radio should be on or off. It must be possible to determine if the user • wants the volume raised, lowered, or kept the same. • It must be possible to determine if the user wants to listen to the present station, to change to another pre-set station, to seek a station higher in frequency, to seek a station lower in frequency, etc.
In other words, although there are many differences, there must be common capabilities because without them the device would not be suitable as a radio control panel. These facts allow us to identify a set of “methods” or “access programs” that we will always be able to implement, e.g. “get radio on/off switch state”. These would allow us to define a basic interface in the form of a set of programs that could be used to interact with the control panel. If the panel is replaced by another model, the interface methods might have to be implemented again, but the rest of the software need not change. The fact that implementable capabilities are usually commonalities, while the nature and format of the data can vary, is one of the reasons why an interface in the form of a set of programs is better than using an interface description language such as XML or its cousins. However, this basic interface is not the whole story because, in addition to the superficial differences used in the illustration, there can be more substantive differences, capabilities of one unit that are not shared by all others. For example, there might be a “sleep” switch that allows the driver to request that the radio be left on for a fixed period of time before it switches off, or some “alarm” capability that increases volume at a certain time. These would not be available on all models and the basic interface would not allow them to be accessed and exploited. This issue was also discussed in [NRL81]. We can define subfamilies with additional sets of interface programs. These would only be available for the subfamily. Here we see a further advantage of a programbased interface: Additional capabilities require adding interface programs but do not require modifications to existing ones. This means that existing software that used those programs need not be modified unless they want to exploit the added capability. Such code sharing is one of the ways firms can profit from applying program-family concepts.
7. Summary and conclusions While the interest of researchers in the very practical problems associated with software product lines is welcome, it is short-sighted to focus on the problems of configuration-management, the phase in which enumeration and combinatorial analysis is possible. The greatest leverage can be obtained by focussing on the design and documentation of the family architecture at a stage where the set of variants cannot be enumerated but can be characterized. By the
13
Interface Modules”, Proceedings of the 5th International Conference on Software Engineering, March 1981, pp. 195204. Reprinted as Chapter 15 in [HW01].
time that one can enumerate alternatives, it is often too late to make a real difference. A set of interface specifications can be interpreted as a characteristic predicate for a family of programs even though the exact membership of the family is not known. Any software product that implements the specifications correctly is a member of the family. In other words, precise documentation allows us to characterize the program family in situations where it would be impossible to enumerate the alternatives.
[NRL84] Clements, P.C., Parnas, D.L., “Experience with a Module Interface Specification Technique”, Proceedings of International Workshop on Models and Languages for Software Specification and Design, 30 March 1984, Orlando, Florida, pp. 70-73. [Pa76] Parnas, D.L., “On the Design and Development of Program Families”, IEEE Transactions on Software Engineering, Vol. SE-2, No. 1, March 1976, pp. 1-9. Reprinted as Chapter 10 in [HW01].
8. Acknowledgements
[Pa77] Parnas, D.L., “Use of Abstract Interfaces in the Development of Software for Embedded Computer Systems”, NRL Report No. 8047, June 1977, 30 pgs. Reprinted in Infotech State of the Art Report, Structured System Development, Infotech International, 1979.
I am grateful to Marius Dragomiroiu and Ridha Khedri for several thoughtful remarks that have led to improvement of this paper.
9. References
[PLD06] V. Pantelic, X. Jin, M. Lawford, and D. Parnas, “Inspection of concurrent systems: Combining tables, theorem proving and model checking”, in SERP’06: Proceedings of the International Conference on Software Engineering Research and Practice, vol. 2, (Las Vegas, Nevada, USA), pp. 629-635, 2006
[Hen80] Kathryn L. Heninger. “Specifying software requirements for complex systems: New techniques and their application”, in IEEE Trans. Softw. Eng., SE-6(1):2–13, January 1980. Reprinted as Chapter 17 in [HW01].
[SQR05] Baber, R., Parnas, D.L., Vilkomir, S., Harrison, P., O'Connor, T., “Disciplined Methods of Software Specifications: A Case Study”, Proceedings of the International Conference on Information Technology Coding and Computing (ITCC 2005), April 4-6, 2005, Las Vegas, NV, USA, IEEE Computer Society.
[HW01] Hoffman, D.M., Weiss, D.M. (eds.), Software Fundamentals: Collected Papers by David L. Parnas, Addison-Wesley, 2001, 664 pgs., ISBN 0-201-70369-6. [NRL78] Heninger, K., Kallander, J., Parnas, D.L., Shore, J., “Software Requirements for the A-7E Aircraft”, NRL Report 3876, November 1978, 523 pgs.
[SQR06] Colm Quinn, Sergiy Vilkomir, David Parnas and Srdjan Kostic. “Specification of Software Component Requirements Using the Trace Function Method”, Proceedings of the International Conference on Software Engineering Advances (ICSEA 2006), October 29th – 2006, Tahiti, French Polynesia. November 1st,
[NRL80] Parker, R.A., Heninger, K.L., Parnas, D.L., Shore, J.E., “Abstract Interface Specifications for the A-7E Device Interface Modules”, NRL Report 4385, November 1980, 176 pgs. [NRL81] Britton, K.H., Parker, R.A., Parnas, D.L., “A Procedure for Designing Abstract Interfaces for Device
14
– Technical Papers –
10 15
16
Exploring the Dimensions of Variability: a Requirements Engineering Perspective Sotirios Liaskos1 Lei Jiang1 Alexei Lapouchnian1 Yiqiao Wang1 2 3 Yijun Yu Julio Cesar Sampaio do Prado Leite John Mylopoulos1 1
Dept. of Computer Science, University of Toronto, Canada, {liaskos,leijiang,alexei,yw,jm}@cs.utoronto.ca 2 Dept. of Computing, Open University, United Kingdom,
[email protected] 3 Dept. of Computer Science, PUC-Rio, Brazil,
[email protected]
Abstract Goal models have been found to be effective for representing and analyzing variability at the early requirements level, by comprehensibly representing all alternative ways by which stakeholders may wish to achieve their goals. Our study of goal models as instruments for acquiring and analyzing variability has showed that, focusing on one particular variability dimension, which in our case was the intentional one, allows better understanding of the identified variability and offers more opportunities for analysis and evaluation of alternatives. In this paper we explore other dimensions of variability that have emerged in our study of several areas, including autonomic computing, business process design and database design, and discuss how variability can be modeled and analyzed in each of these dimensions. Then we show how we can manage the variability space that emerges by putting together such dimensions and discuss the role of fitness criteria for identifying alternatives of interest.
1. Introduction Software variability is an increasingly important research topic in Software Engineering, and a key concept for the study of software product lines and software adaptability. Modeling of variability is known to be essential for analyzing reuse strategies, understanding customization options and communicating these options to stakeholders. Furthermore, variability modeling has recently been found to be a useful instrument for both variability acquisition, that is discovery of variation points in a problem, and variability analysis, that is evaluation of the applicability of each identified variant in a given context and situa-
tion. These functions of variability modeling require knowledge of the origin and the meaning of variability, in a way that also allows understanding of the implication of elementary choices to overall properties of the system and, consequently, enables the specification of fitness criteria for selecting desired alternatives. The need to explore and analyze variability at a higher level of abstraction is driven by the great amount of features that are observed in modern software systems, and the difficulty in understanding how the technical details of individual choices affect stakeholder intentions about the system. Direct manipulation of variability under such circumstances may prove difficult, unless the modeling process is focused on the particular dimensions that define the space of possible designs for a software system. Each variability dimension comes with a set of concerns to be addressed, a set of relevant concepts, its own modeling practices as well as its own definition of variation types and their semantics. Thus, modeling variability in its particular dimension leads to richer representations that are amenable to reasoning and allow high-level leveraging of variation using dimensionspecific terms. In this paper, we summarize the work we have done so far on variability acquisition, representation and analysis at the level of stakeholder goals, and use it as an example of how focusing on a particular variability dimension supports both the purpose of systematic variability identification and the goal of selecting alternatives that best solve particular problems. Then, focusing on our current work, we discuss other dimensions of variability and for each of them we describe what particular concerns they pose, what modeling challenges they introduce and how the fitness criteria for selecting alternatives can be derived. We organize our presentation as follows. Section 2 explores how the current research tackles the problem of vari-
17
ability modeling along some of the dimensions in which it occurs. We also discuss efforts that attempt a categorization of variability. In Section 3, we reflect on our earlier study of intentional variability and make some observations that may apply for the study of other variability dimensions. In Section 4, we explore such dimensions and focus on concerns that are particular to them. In Section 5 we discuss how the dimensions form a variability space, how we can potentially represent constraints that span across dimensions, and how we can use fitness criteria to isolate points of interest. We conclude in Section 6.
2. Understanding Variability Variability identification and representation has extensively been investigated in the context of domain analysis ([44, 41]). In that context, commonality and variability analysis is aimed at identifying common and varying characteristics among systems that belong to the domain under investigation. The result of this process is commonly formulated as a feature model ([28, 13]). Features are uservisible characteristics of software products, while feature models represent admissible combinations of features. Feature models are generally understood as tools for modeling the configurability aspect of high-variability systems ([13]). This approach assumes that the feature model plays the exclusive role of gathering and representing all variability aspects of a system (or a family thereof) in one central variability view ([6]). This, however, implies that, since they must potentially accommodate a wide diversity of feature types (such as behavioral, structural or data), feature models necessarily have little to say about the meaning of the variability they represent. Thus, researchers have been examining ways by which variability pertaining to a specific view of a problem can be implicitly accommodated or explicitly represented in the models corresponding to that view. To model structural variability of a problem, Gomaa [21] or America et al. [2], for example, suggest the use of existing modeling constructs to represent variability in class diagrams, by possibly allowing special use of existing constructs, such as stereotypes. In [23], on the other hand, explicit use of variation points within use-case diagrams is suggested, while [27], [26] or [53] propose parameterization of use cases or requirements documents; these can be seen as methods for representing functional variability ([23]). Several options have also been introduced for modeling variability in behaviors. Conditions on statechart transitions, which are true or false depending on the variant that has been chosen have been proposed in [28] and [39]. In a similar spirit, a method for generating SCR representations in which rows in the transition tables can be optional is proposed in [17]. In [50], message sequence charts with vari-
able parts are proposed, while [7] and [1] suggest the use of generic storyboards and generic activity diagrams, respectively. Further, in [18] the notion of modal transition systems is discussed, where transitions can be either required or optional (“maybe”) depending on the requirements for the particular product instance. Methods for capturing intentional variability have recently been proposed. Constructing AND/OR hierarchies of goals has been shown to be an effective way to model intentional variability. Each solution of the AND/OR goaltree provides an alternative way by which stakeholders can achieve their goals, while soft-goals are used to model qualitative characteristics of alternatives. We elaborate on intentional variability in the next section. The above proposals are mostly suitable for describing the variability of the problem. Similar work has been done for accommodating and representing variability in models that describe aspects of the solution. At an architectural and design level, in the context of modeling objectoriented designs, inheritance, aggregation and parameterization have been found to be useful constructs for accommodating variability (e.g. [2, 21] discussed above). In modeling component-connector views of architectures, notable is the Koala extension to Darwin architecture description language ([55]), which introduces the notion of the switch, whereby alternative bindings of interfaces can be represented. An additional technique for representing variability in module views of architectures is presented in [5]. Further, at an even lower level lies the problem of variability implementation. Numerous techniques have been proposed; [19] and [22] constitute comprehensive surveys on the matter. Perry also provides a set of options for implementing architectural variability ([42]). Observe that, at this level, the presence of alternative variability implementation and architecting techniques constitutes variability on its own. Furthermore, variability is relevant to human computer interaction (HCI) design in the context of adaptable and adaptive interfaces. In [38], for example, the alternative configuration of function availability in the main screen (through visual elements such as menus and buttons) of a popular text editor versus the complexity of the resulting interface are studied, while in [37] the problem of customizing such applications is investigated. Explicit modeling of variability in user interfaces is usually not in the scope of these efforts. Nevertheless, in the adaptiveness literature, variability is implicitly modeled by modeling the decision making mechanism, e.g. Markovian processes in [25]. The study of variability in its particular context, such as function, behavior, stakeholder intention, architectural view or user interface offers the opportunity of identifying the particular considerations that apply to each such dimension which in turn may again help the construction of systematic frameworks for variability identification and
18
management. The literature is already rich of proposals on what important dimensions of variability should be. Thus, in [23], essential variability, that is variability from a user point of view, is distinguished from technical variability, which concerns implementation issues. Essential variability can pertain to functionality (including behavior), system environment, quality, data and others. FORM ([29]) proposes a more coarse grained categorization into four layers, namely capability (e.g. available services to the users), operating environment (i.e the underlying infrastructure), domain technology and implementation technique. In [52], variability in behavior and hardware configuration are given as examples of two distinct variability dimensions. In [1] the accommodation of variability in customer, application, functional, conceptual and realization views is discussed, while in [33] the identification of variability dimensions in requirements is seen as an issue of separation of concerns specific to the particular problem that is being studied. The definition of variability dimensions facilitates the discovery of variation points and allows understanding of its meaning, origin and rationale. This, in turn, facilitates the process of selecting the appropriate variant. For this to be possible, apart from the identification of the dimensions per se, a modeling framework for both accommodating variability and allowing the selection of variants needs to be introduced for each dimension. This constitutes a significant finding of our earlier work on intentional variability identification and analysis through goal models, which we summarize in the next section.
of the tree. For the meeting to be scheduled the individual constraints must be collected and some time slot must be selected. Thus, we AND-decompose the root goal accordingly. Constraints can then be collected by a person (e.g. a secretary) or the system to be; we express this option through an OR-decomposition. The system has several options to collect the constraints. It can unobtrusively check the invitees’ on-line calendars or it can send them a request. The invitees, on the other hand, can be given several choices as to whether or not they want to broadcast their constraints. And then, different rules can apply for the selection of the right time slot. In all, it can be observed that the root goal can be achieved in 10 different ways, as many as the solutions of the AND/OR tree. We call these alternatives for fulfilling the root goal. Schedule Meeting AND
-
Avoid Obtrusiveness
+
+
Accuracy of Constraints
OR
OR OR
By avoiding any Conflict
By avoiding Conflicts among Significant Participants
AND
Dative Invitees Respond OR
Enhance Participatory Spirit
Choose Meeting Time
Secretary to Collect Constraints
Collect From Invitees Software Calendars
AND
+
Manner OR
OR
Solicit Response
3. Reflections on the Study of Intentional Variability
AND
OR
Means System to Collect Constraints
System Send Request
Goal modeling has been found to be an effective way for identifying requirements of software systems by focusing on understanding the intentions of the involved stakeholders ([14, 3, 57]). Central to goal modeling is the idea of constructing hierarchies of AND- and OR-decompositions of high-level stakeholder goals into subgoals and then, recursively, into low-level subgoals and tasks that lead to requirements of the system-to-be. When a goal is ANDdecomposed into subgoals, all of them must be satisfied for the parent goal to be satisfied. When a goal is ORdecomposed, the satisfaction of one of the OR-subgoals suffices for the satisfaction of the parent goal. Thanks to the existence of OR-decompositions, the resulting hierarchy already constitutes a representation of variability in stakeholder goals. In Figure 1, oval shaped elements are goals forming such a hierarchy. The model shows how the goal Schedule a Meeting is analyzed into subgoals. Normally the decomposition continues until tasks that can fulfill the goals in a known way can be defined; for the interest of space we focus on the higher levels
Agentive Collect Constraints
Minimize Human Effort
To Other Invitees
Invitee’s Privacy
OR OR
To System To Secretary
+
Figure 1. A goal model
Thus, expression of variability in goal models is possible by using OR-decompositions. But what is the meaning of OR-decomposition of goals? In i* ([56]), a notation widely used for constructing goal models, OR-decompositions are simply understood as alternative means (subgoals) by which certain ends (parent goal) can be achieved. Nevertheless, in [48] and [47], Rolland et al. propose the use of a set of drivers that can guide the OR-decomposition of goals, and, thus, implicitly associate the meaning of ORdecompositions with the meaning of these drivers. The drivers are a universal set of parameters that are understood as potential parts of the definition of any goal. The acceptance of different values for different parameters introduces
19
variability in goal specification. This idea, originally proposed in the context of scenario identification, was later brought in a variability acquisition and modeling context ([36]). In that work, we introduced a method for identifying such decomposition drivers, which we called variability concerns, given textual information specific to the domain and the goal. Thus, each goal can be associated with a set of variability concerns, each of which must be addressed through an OR-decomposition in the AND/OR tree that emerges from the analysis of the goal. Returning to our example of Figure 1, each OR-decomposition is annotated with the variability concern that it addresses. For instance, alternative agents that can collect the constraints address the agentive variability concern, while different algorithms for picking a suitable slot address the concern manner. By referring to the variability concerns that are relevant to the goal at the time we decompose it, we allow the discovery of variability that might otherwise remain hidden. Thus, the dative concern, which refers to the agent that is affected by the achievement of a goal, is used to suggest that different response styles to an invitation (to everybody or only to the solicitor) may need to be accounted. Therefore, by exclusively focusing on acquiring and modeling variability on one dimension, the intentional one, we were forced to construct a specific semantic framework in which the particular dimension of variability can be expressed. This way, apart from facilitating the discovery and understanding of variability, we also allow the definition of fitness criteria to be used for evaluating alternatives implied by goal models. Our investigation of the intentional dimension of variability has already led us to the consideration of three categories of criteria that can be used for selecting alternatives in goal models: user skills and stakeholder preferences ([24]) as well as contextual characteristics ([36]). User skills are associated with leaf level goals in goal models, which, as mentioned above, describe tasks to be performed by humans alone or through interaction with the system. Thus, for each such task we construct a list of skills that a user who needs to perform the task must have. Conversely, if we are given the skills of a particular individual we are able to filter out courses of tasks that she cannot perform. In our scheduling example, assume that tasks at the leaf level mention that an invitee responds to the constraint collection by filling up a web form. This requires some sensory (e.g. vision) and motor or speech skills to perform the input, some basic cognitive skills as well as language and computer skills. Individuals that lack any of the required skills (e.g. elderly, people with cognitive or other impairments, illiterate) must be provided a different alternative whose tasks they can actually perform. This may even imply that a completely different strategy for collecting constraints must be selected at the higher level. A similar approach is followed for contextual character-
istics: tasks can only be performed under specific circumstances. In our example of Figure 1, constraints can be selected from individual calendars only if the invitee has made them public and there is a means to access them through a network. From a modeling point of view, contextual characteristics are a generalization of skills, as they are also used as conditions for the performance of leaf level tasks. User preferences on the other hand are specifications of priorities over soft-goals that alternatives must satisfy. As opposed to hard-goals we discussed so far, soft-goals are goals for which there is no clear criterion that can be used for deciding whether they are satisfied or not. Thus, softgoals are satisficed (versus satisfied) to a degree and based on relevant evidence. In Figure 1, soft-goals are represented as cloud-shaped elements. Contribution links, annotated with “+” and “-” symbols in the figure, allow us to represent the fact that satisfaction of hard-goals affects positively or negatively the satisfacing of soft-goals. Thus, in Figure 1, the choice to broadcast one’s constraints may hurt one’s privacy, but it helps building a participatory spirit. Conversely, if we state that building a participatory spirit is more important than privacy of individual invitees, we implicitly suggest that the particular response style should be used. Thus, by specifying the relative importance of softgoals we implicitly bind low level options. Note that, in practice, goal models can be more complicated networks of soft-goals, requiring advanced reasoning techniques for understanding how satisfaction and denial is propagated from goal to goal. Such reasoning techniques are discussed in [20] and [49]. Notice that these types of fitness criteria are semantically correlated with concepts of the goal models, and this is why they naturally emerged throughout our investigation. Tasks, for example, that lay at the leaf level of goal models, represent courses of actions that are performed by actors in a particular time and place and have an estimated impact on high-level objectives of stakeholders. Thus, by referring to the meaning of tasks, we already refer to a set of concerns (actor characteristics, times, locations, and actor preferences respectively) that may influence variability identification and analysis. If the building blocks of our models were more abstract concepts, such as features, we perhaps wouldn’t have been able to detect these additional concerns, cleanly express their relationship with our main concepts, and use them as fitness conditions. Interestingly, fitness criteria themselves can vary and, thus, they are also subjects for variability analysis. For example, evaluating each of the supported means of transportation a stakeholder can use to Travel from Home to Work may depend on the weather conditions. But weather conditions themselves can vary preventing the selection of certain alternatives for fulfilling our goal, in different ways. For example, rain or cold may trivially pre-
20
vent the use of a bicycle, but, more rare phenomena, such as sleet, may even prevent the use of any street vehicle. In other words, by systematically analyzing all potential states the weather can take, forces us to consider more alternatives for fulfilling the goal Travel from Home to Work. In order to systematize this, in the goal oriented context we found it helpful to separate core variability from background variability. While the former is the variability we are trying to model, the latter refers to variability of factors that influence the fitness evaluation of core alternatives and, in many cases, necessitate the introduction of more alternatives. We expect that a similar distinction can be made in other variability dimensions as well. For example in the behavioral dimension, alternative behaviors constitute core variability, while alternative conditions on admissibility of states, transitions or courses thereof may constitute background variability. Similarly, the choice of a particular variability implementation policy ([22]) among a set of options (core) may depend on factors pertaining, for instance, to the device where the software is to be deployed, the expertise of the developers or characteristics of the project (background). The variability analyst develops the core variability model having in mind those background circumstances and how their change may indicate a change to a different variability implementation strategy.
4. Dimensions of Variability In this Section, we present some observations from our investigation of analysis and design methods in four different areas of software development: business process design, autonomic computing, database design as well as architectural design for pervasive systems. Based on our early evidence, for each of these areas, we explore potential variability dimensions and discuss criteria that can be used for evaluating alternatives.
4.1. Business Processes Design The design of business processes (BPs) and the supporting IT infrastructure is an important software development area. BPs are characterized by the high level of human involvement in their execution and thus, in addition to the variability normally present in the usual software development process, there are some new variability dimensions to be considered during business process design. Also, prominent among the fitness criteria for selecting appropriate alternatives in these variability dimensions (besides the usual ones such as cost and resource utilization) are social aspects such as rewarding and challenging work environment. There are many definitions of what a business process is, but in general a BP is seen as a sequence of activities that achieves some business purpose. Since the notion of
purpose is present in BPs, they can be modeled using goaloriented notations (e.g., [30]). Thus, a lot of the discussion on intentional variability included in this paper can be applied to these processes. However, in practice BPs are usually modeled as workflows, which represent activities arranged in sequence or in parallel, each taking some input and producing some output. Common notations for workflow specification are BPMN ([10]) and Petri Nets ([54]). When designing BPs, analysts need to determine which parts of the BP can be represented as well-defined workflows and which – usually highly unstructured creative subprocesses – need to be left underspecified (perhaps, aside from the definition of inputs and outputs). While modeling BPs through workflows, we are presented with several types of variability that need to be represented and analyzed. For the unspecified parts, the variability will be dealt with at runtime by participating employees. First, we have to deal with the temporal ordering of activities in a workflow. Obviously, there are constraints on that ordering: some activities require inputs that are produced by other activities and this limits their ordering variations. However, this still leaves a lot of choices of how to sequence/parallelize activities. Important criteria to consider here is the performance of the BP (parallelism generally means increased performance), the availability of resources, as well as whether inputs/outputs of activities can be duplicated (for parallel execution). Another important variability consideration in BP design is the assignment of workflow activities to human/computer resources. Part of the task is to determine which portions of a process can be automated and which should be left for human execution. This can be viewed as defining the boundary for the IT support system. While some tedious and mechanical activities can be easily automated, BPs usually require certain amount of human creativity and problem solving. The criteria here are the availability of human/computing resources, performance, scalability, utilization as well as the desire to keep employees challenged and interested in their jobs. The other part of the task is to determine which particular employees, roles or teams as well as systems, components, or services are going to be responsible for executing workflow activities. Examples of important considerations here are resource cost, and capabilities of the involved employees. The measurement of BP performance requires the setup of an efficient, non-disruptive, and cost-effective monitoring framework [46]. Key Performance Indicators (KPIs) are measures commonly used to track the critical success factors in BPs from a business perspective. The choices of the appropriate KPIs for processes and their refinement into sets of monitorable and measurable parameters represent another variability dimension in BP design. There are other BP design activities that give rise to ad-
21
ditional variability concerns. For example, dealing with failures in BPs involves the selection of error notification (whom to notify, through what means), diagnosis (e.g., automated vs. human intervention) and compensation mechanisms (such as wait, re-execute the activity, re-assign it to another actor, or cancel).
4.2. Autonomic Systems Design Autonomic Computing (AC) is an example of a software engineering field where we see a great need to model and analyze various aspects of variability during the development process. AC is a rapidly growing research area that aims at reducing software maintenance cost and management complexity. AC promises to move most of this complexity from humans to the software itself by endowing a software system with capabilities to self-configure (to adapt to dynamically changing environment and requirements), self-optimize (to improve its performance and/or other characteristics), self-heal (to monitor, diagnose, and recover from its failures), and self-protect (monitor, detect, and protect itself from attacks and other malicious behaviour) [31]. Collectively, these are referred to self-* capabilities. There are a number of possibilities for designing AC software systems. For example, one is to use software agents capable of planning and social interaction to create self-managing systems ([31]). The problems in this approach are the computational complexity of multi-agent systems and the inherent difficulty of predicting and analyzing emergent behavior in them. Since, in a nutshell, an AC system is a flexible software system that changes its behavior in a purposeful way while achieving its goal, in [34] we presented an alternative approach that aims at producing systems supporting a space of possible behaviors which are realized through the isomorphic space of possible system configurations. While designing AC systems, a number of variability dimensions must be represented and analyzed. Obviously, the intentional perspective must be represented. Thus, the approach in [34] uses high-variability requirements goal models to capture variability in the problem domain of autonomic systems. These models represent multiple ways the goals of AC systems can be attained as well as the characteristics of these alternatives in terms of the important quality criteria (softgoals). These models are then enriched with control information capturing temporal ordering constraints on goals to support variability-preserving mapping into designlevel notations such as statecharts (that represent variability in the behavior of the system). AC systems are then designed to support all (or some) of the alternatives captured in their corresponding goal models and are then augmented with capabilities to switch from one alternative to another at runtime, thus exhibiting adaptive behavior.
In the AC literature (e.g., [31]), self-managing systems are viewed as networks of Autonomic Elements (AEs) that are capable of tuning/modifying their resources or processes and that are furnished with the feedback loop consisting of activities that monitor the system and its environment, analyze the monitored data (i.e. diagnose), plan a course of action if an intervention is needed, and execute the plan. All of these activities provide a wealth of alternatives that need to be systematically represented and analyzed. For example, in case of the monitoring, the paramount problem is the selection of data that needs to be captured in order for an AC system to be able to perform the self-* activities. For example, for self-optimization, the system needs to evaluate the currently executing alternative in terms of how it meets quality constraints such as performance to determine if a switch to another option is warranted. For self-healing, data on successes/failures of its constituent components are needed. For self-protection, data on, for example, failed login attempts, must be captured. Similarly, there are several parameters that need to be decided on when designing a monitoring framework for an AC system. The characteristics of the individual monitors themselves need to be defined. Monitors can be on-line or off-line, intrusive or non-intrusive, adaptive or maladaptive. The specifics of the measurement process such as sampling rates and data storage constitute additional variability concerns. Then, the specific monitoring policy in relationship with the monitored system needs to be established. We are currently working towards constructing a richer categorization of such concerns. We also explore ways by which we can construct models that facilitate both understanding of the available options in a monitoring problem and making the appropriate decisions. The aspect of diagnosis gives rise to another variability space with a wealth of options and concerns (e.g., how eager the system is to generate diagnosis vs. to wait and collect more data). Similarly, the system’s adaptivity strategy can be aggressive (possibly resulting in frequent oscillation among behavior alternatives), conservative (possibly resulting in missed opportunities for optimization, but providing a more stable behavior) or can depend on the diagnosis (e.g., very aggressive in case of security concerns/failures and conservative in case of self-optimization). Variability manifests itself in many other aspects of AC systems design, such as the selection of components for achieving the leaf-level goals in the goal models. Component’s characteristics such as cost or performance play a role in this.
4.3. Information Modeling and Database Design Information modeling is concerned with the construction of computer-based symbol structures (i.e., information
22
bases) which model some part of the real world (i.e., the application domain) [40]. In the case of databases, data modeling focuses on the static aspect of the application domain and uses modeling constructs that denote particular individuals, generic concepts and associations that are part of the domain. Classic approaches [4, 45, 12] divide the overall database design into three phases: conceptual, logical and physical design. At conceptual level, the designer collects, analyzes, structures and formalizes relevant domain concepts, referring to a conceptual data modeling language (e.g. Entity-Relationship models). Furthermore, data abstraction mechanisms are essential components in conceptual data modeling and an important part of the relevant modeling languages. These abstraction mechanisms include the classic ones such as classification, generalization and aggregation as well as less known ones such as contextualization [51], materialization [43] and parameterization [16]. To understand how variability occurs in conceptual design we need to understand the process with which such designs are developed. Conceptual database design is, to all intents and purposes, an engineering process. It consists of a series of decision-making steps and is guided by well-defined design strategies. For example, in the classic conceptual database design methodology [4], the topdown strategy produces a conceptual schema by a series of successive refinements. In this approach, starting from an initial schema that describes all the data requirements by means of a few highly abstract concepts and then gradually refining the schema by transforming these concepts into ones with more complex structure, capable of describing the original concepts in more detail. For each design strategy, a set of transformation primitives is proposed to guide the transformation process. For example, one top-down primitive may transform an entity into two entities connected by a relationship while another may instead transform the entity into a generalization hierarchy. In addition, conceptual rules ([4]) may help designers make strategy-independent decisions, such as whether to model a concept as an entity, relationship or attribute. The application of alternative transformation primitives and conceptual rules lead to alternative designs, in a way similar to how alternative variability implementation techniques are chosen in [22]. The notion of relevance can be considered as the general criterion for selecting among alternatives. For example, the specialization of a general concept into more concrete subconcepts relies on the determination of the “discriminator” [9], which is the property of the concept that is “more relevant” to the problem at hand. Consider the concept Material. It can be specialized into sub-concepts Book and Journal on the basis of the format, or into Paper, Audio or Video on the basis of the medium. Thus, as with variability concerns in the intentional case, such discriminators both guide
the identification of alternative specializations and allow us assess the relevance (fitness) of particular specializations through reference to such discriminating characteristics. Furthermore, more concrete variability concerns and fitness criteria can be used for particular purposes. For example, temporality specifies whether the temporal aspect of an entity in the application domain is of interest in the context of a particular problem. In a hospital management system, for example, temporality questions whether the historical data of patient medical profile need to be kept in the database. On the other hand, accuracy is concerned with the degree by which details of the relevant concepts are included in the model (e.g. what configuration of attributes to use to model properties of a concept or how to separate units and values for measurement concepts). In both cases, an obvious fitness criterion is the accommodation of data queries that are already known to be of interest, or are conjectured to be of potential interest. As a last example, access refers to alternative ways by which external agents can read and manipulate the data entities. Here the degree of trust amongst various stakeholders may be an example of a criterion for selecting among alternative permission schemes.
4.4. General Architectural Design Several frameworks for architectural modeling based on views have been proposed, including Kruchten’s 4+1 view framework ([32]), as well as Clements et al. approach ([11]) based on viewtypes. Independent of the views one chooses to represent an architecture, each such view becomes a variability dimension that needs to be addressed. Further, each view is associated with one or more modeling notations. In Section 2 we already discussed several existing approaches in modeling variability in architectural designs. These include accommodating variability in use cases, class diagrams, component-connector views, statecharts and interaction diagrams. The question is whether existing efforts are sufficient for representing variability in every essential architectural view. Our experience in analyzing problems that called for solutions of ubiquitous nature (e.g. advanced nurse notification systems for the health care domain), showed the extensive need of variability representation mechanisms for deployment views. Such views describe the assignment of software elements to environmental entities (i.e. computing hardware). Likewise, variability occurs within the nodes in terms of their capabilities (e.g. a PC vs. a PDA), which can often dynamically change (e.g. network connectivity of a mobile device). Interestingly, dynamic change of capabilities may depend on pure environmental factors. Thus, network connectivity or power supply may need to be modeled as properties of a location, rather than properties of devices. From there, an initial allocation of software components
23
to devices requires modeling of both what software components assume about their environment and what capabilities nodes (e.g. devices) actually offer. In addition to the hard-constraints implied by the capability matching problem, soft-constraints related to quality attributes, such as usability, performance and cost, need to be set for further evaluating the admissible assignments of components to devices.
5. Managing the Design Space In every dimension, variability is present in the form of variation points. A variation point can be explicit by appearing as a separate construct of the modeling language (as e.g. variation point elements in use case diagrams – [23]) or implicit, through the use of existing constructs (e.g. alternative specializations in class diagrams – [21]). In both cases, the variation point offers alternative instantiations of a highvariability model, by being bound appropriately. Putting all dimensions together, the resulting design space is a crossproduct of the alternatives found in each dimension. Thus, since the design space encompasses all possible combinations of alternatives, it can be vast. This constitutes a problem when e.g. in a product derivation context ([15]) a point in this space is sought that best solves a problem. A first step towards coping with large design spaces is the use of cross-dimensional interdependency links between elements and decisions involved in variation points. For example, in a study of alternative event notification designs for nurses in hospitals, a leaf level task Send Audio Notification in the intentional dimension, a component audioNotifier in a structural dimension, and a state Audio Notification Being Sent in a behavioral dimension can all be associated through such interdependency links. Then, when they appear as alternative selections in the context of a variation point (which in our case may concern alternative notification modes such as visual or haptic), binding of a variation point in one dimension automatically constraints the way others are bound. This way, we can greatly reduce the size of the design space through a small number of decisions. In [58], we introduce a set of patterns that can guide the derivation of interdependency links between the intentional variability dimension at the problem level and other dimensions at the solution level, namely the behavioral, modeled through statecharts, and the component interconnection dimension, modeled through component-connector diagrams. Furthermore, the fact that variability is modeled and understood across dimensions, offers the opportunity to leverage the design space by specifying preferred characteristics of the alternatives of interest, instead of directly handling variation points. This is exactly where the fitness criteria identified in each dimension play a major role. In our inves-
tigation of the intentional dimension, fitness criteria such as the ones discussed in Section 3 were used for restricting the design space implied by the AND/OR-hierarchy of the hard goals. In one of the applications ([35]) we showed that it is possible to configure an e-mail client by only referring to desired satisficing of soft-goals, which was the primary fitness criterion. For example, a stakeholder’s desire to maximize Privacy while receiving e-mail, implies the selection of the subgoal Use Encrypted Communication (as opposed to not using an encrypted one) which, by following a pre-established interdependency link to configuration details of the software system, enables secure sockets layer or secure authentication. Thus, fitness criteria specified for one dimension, automatically pose constraints to other dimensions through the interdependency links. The use of fitness criteria in other dimensions can have the same effect. For example, a reference to discriminators allows the leverage of variability in static structures, which again may have consequences on behavioral views (e.g. remove states related to objects that are absent from the reduced static structure). Note that the criteria specification approach to variability leverage is not distant from the notion of domain specific languages (DSLs - [8, 13]), since DSLs allow the use of domain specific terms to describe a particular solution. One of the differences, however, may be that fitness criteria specification, the way we envision them, have the form of hard and soft-constraints that prune a design space that is already defined, instead of languages for generating members of that space. On the other hand, handling the design space that emerges from the combination of individual dimensions is greatly facilitated if the space is of propositional nature. If the variation points of each dimension can be modeled in AND/OR trees with lateral constraints amongst their nodes as well as between their nodes and the nodes of the respective trees of the other views, then the reasoning problem is one of satisfiability of the underlying propositional theory. However, in order to enjoy the benefits of dimensionspecific criteria specification, an extra step must precede to convert such criteria into actual bindings of variation points expressed in a propositional form.
6. Conclusions Putting variability modeling and analysis in the context of the particular dimensions in which variability appears, allows better understanding of its meaning and offers several analysis and evaluation opportunities. Throughout our work on several domains we have acquired an initial understanding of potential variability dimensions and the special concerns each of these introduces. However, our work is still at an early stage. In the future, we expect to have an
24
exact picture of what these dimensions are and a systematic framework for defining interdependencies among them. We also intend to focus on modeling aspects of these ideas. We saw that the literature is already rich of proposals for accommodating or explicitly representing variability in a number of different modeling notations. One question is whether and how variation points appearing in models of each dimension can form dependency hierarchies that can be translated to propositional formulae. This, together with a framework for establishing interdependencies across dimensions (again based on propositions), would provide a convenient representation of the design space amenable to well known reasoning techniques. Furthermore, for the variability space to be accessible, the translation of fitness criteria into part of the propositional representation poses an additional challenge.
References [1] P. America, E. Rommes, and J. H. Obbink. Multi-view variation modeling for scenario analysis. In Fifth International Workshop on Product Family Engineering (PFE), pages 44– 65, 2003. [2] P. America and J. van Wijgerden. Requirements modeling for families of complex systems. In IW-SAPF-3: Proceedings of the International Workshop on Software Architectures for Product Families, pages 199–209, London, UK, 2000. Springer-Verlag. [3] A. I. An´on and C. Potts. The use of goals to surface requirements for evolving systems. In Proceedings of the 20th International Conference on Software Engineering, 1998. [4] P. Atzeni, S. Ceri, S. Paraboschi, and R. Torlone. Database Systems - Concepts, Languages and Architectures. McGraw-Hill Book Company, 1999. [5] F. Bachmann and L. Bass. Managing variability in software architectures. In Proceedings of the 2001 Symposium on Software Reusability (SSR ’01), pages 126–132. ACM Press, 2001. [6] F. Bachmann, M. Goedicke, J. Leite, R. Nord, K. Pohl, B. Ramesch, and A. Vilbig. A Meta-model for Representing Variability in Product Family Development. In Proceedings of the 5th International Workshop on Software ProductFamily Engineering (PFE5), Siena, Italy, 2003. [7] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, and J.-M. DeBaud. PuLSE: A methodology to develop software product lines. In Proceedings of the Symposium on Software Reuse (SSR’99), 1999. [8] J. Bentley. Programming pearls: little languages. Communications of the ACM, 29(8):711–721, 1986. [9] A. Borgida and R. J. Brachman. Conceptual modeling with description logics. In The description logic handbook: theory, implementation, and applications, pages 349–372. Cambridge University Press, New York, NY, USA, 2003. [10] Business process modeling notation, version 1.0. www. bpmi.org.
[11] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford. Documenting Software Architectures: Views and Beyond. Addison Wesley Professional, 2003. [12] T. M. Connolly and C. E. Begg. Database Solutions: A step by step guide to building databases. Addison Wesley, 2nd edition, 2003. [13] K. Czarnecki and U. W. Eisenecker. Generative Programming - Methods, Tools, and Applications. Addison-Wesley, June 2000. [14] A. Dardenne, A. van Lamsweerde, and S. Fickas. Goaldirected requirements acquisition. Science of Computer Programming, 20(1-2):3–50, 1993. [15] S. Deelstra, M. Sinnema, and J. Bosch. Product derivation in software product families: a case study. Journal of Systems and Software, 74(2):173–194, 2005. [16] E. Dubois, P. D. Bois, and A. Rifaut. Elaborating, structuring and expressing formal requirements of composite systems. In International Conference on Advanced Information Systems Engineering (CAiSE’92), pages 327–347, 1992. [17] S. R. Faulk. Product-line requirements specification (PRS): An approach and case study. In Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE’01), pages 48–55, 2001. [18] D. Fischbein, S. Uchitel, and V. Braberman. A foundation for behavioural conformance in software product line architectures. In Proceedings of the ISSTA 2006 workshop on Role of software architecture for testing and analysis (ROSATEA’06), pages 39–48, New York, NY, USA, 2006. [19] C. Gacek and M. Anastasopoulos. Implementing product line variabilities. SIGSOFT Softw. Eng. Notes, 26(3):109– 117, 2001. [20] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and R. Sebastiani. Reasoning with goal models. In Proceedings of the 21st International Conference on Conceptual Modeling (ER’02), pages 167–181, London, UK, 2002. [21] H. Gomaa. Object oriented analysis and modeling for families of systems with UML. In ICSR-6: Proceedings of the 6th International Conference on Software Reuse, pages 89– 99, London, UK, 2000. Springer-Verlag. [22] J. V. Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In WICSA ’01: Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01), page 45, Washington, DC, USA, 2001. IEEE Computer Society. [23] G. Halmans and K. Pohl. Communicating the variability of a software-product family to customers. Software and System Modeling, 2(1):15–36, 2003. [24] B. Hui, S. Liaskos, and J. Mylopoulos. Requirements analysis for customizable software: A goals-skills-preferences framework. In Proceedings of the 11th IEEE International Requirements Engineering Conference (RE’03), 2003. [25] A. Jameson, B. Großmann-Hutter, L. March, R. Rummer, T. Bohnenberger, and F. Wittig. When actions have consequences: Empirically based decision making for intelligent user interfaces. Knowledge-Based Systems, 14:75–92, 2001. [26] S. Jarzabek, W. C. Ong, and H. Zhang. Handling variant requirements in domain modeling. Journal of Systems and Software, 68(3):171–182, 2003.
25
[27] I. John and D. Muthig. Tailoring use cases for product line modeling. In International Workshop on Requirements Engineering for Product Lines (REPL’02), 2002. [28] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990. [29] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh. FORM: A feature-oriented reuse method with domainspecific reference architectures. Annals of Software Engineering, 5:143–168, 1998. [30] V. Kavakli and P. Loucopoulos. Goal-driven business process analysis application in electricity deregulation. Information Systems, 24(3):187–207, 1999. [31] J. O. Kephart and D. M. Chess. The vision of autonomic computing. Computer, 36(1):41–50, 2003. [32] P. Kruchten. The 4+1 view model of architecture. IEEE Software, 12(6):42–50, 1995. [33] C. Kuloor and A. Eberlein. Aspect-oriented requirements engineering for software product lines. In 10th IEEE International Conference on Engineering of Computer-Based Systems (ECBS), pages 98–107, 2003. [34] A. Lapouchnian, Y. Yu, S. Liaskos, and J. Mylopoulos. Requirements-driven design of autonomic application software. In Proc. 16th Annual International Conference on Computer Science and Software Engineering (CASCON 2006), October 2006. [35] S. Liaskos, A. Lapouchnian, Y. Wang, Y. Yu, and S. Easterbrook. Configuring common personal software: a requirements-driven approach. In 13th IEEE International Conference on Requirements Engineering, 2005. [36] S. Liaskos, A. Lapouchnian, Y. Yu, E. Yu, and J. Mylopoulos. On goal-based variability acquisition and analysis. In Proceedings of the 14th IEEE International Conference on Requirements Engineering (RE’06), Minneapolis, Minnesota, September 2006. IEEE Computer Society. [37] W. E. Mackay. Triggers and barriers to customizing software. In CHI ’91: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 153–160, New York, NY, USA, 1991. ACM Press. [38] J. McGrenere, R. M. Baecker, and K. S. Booth. An evaluation of a multiple interface design solution for bloated software. In CHI ’02: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 164–170, New York, NY, USA, 2002. ACM Press. [39] H. Muccini and A. Bucchiarone. Formal behavioral specification of a product line architecture. Technical Report Technical Report TRCS 014/2004, Univ. of L’Aquila, 2004. [40] J. Mylopoulos. Information modeling in the time of the revolution. Inf. Syst., 23(3-4):127–155, 1998. [41] J. M. Neighbors. Draco: a method for engineering reusable software systems. Software reusability: vol. 1, concepts and models, pages 295–319, 1989. [42] D. E. Perry. Generic architecture descriptions for product lines. In Proceedings of the Second International ESPRIT ARES Workshop on Development and Evolution of Software Architectures for Product Families, pages 51–56. SpringerVerlag, 1998.
[43] A. Pirotte, E. Zim´anyi, D. Massart, and T. Yakusheva. Materialization: A powerful and ubiquitous abstraction pattern. In VLDB ’94: Proceedings of the 20th International Conference on Very Large Data Bases, pages 630–641, San Francisco, CA, USA, 1994. Morgan Kaufmann Publishers. [44] R. Prieto-D´iaz. Domain analysis: an introduction. SIGSOFT Software Engineering Notes, 15(2):47–54, 1990. [45] R. Ramakrishnan and J. Gehrke. Database Management Systems. McGraw-Hill Science/Engineering/Math, 2002. [46] I. Robson. From process measurement to performance improvement. Business Process Management Journal, 10(5):510–521, 2004. [47] C. Rolland, G. Grosz, and R. Kla. Experience with goalscenario coupling in requirements engineering. In RE ’99: Proceedings of the 4th IEEE International Symposium on Requirements Engineering, page 74, Washington, DC, USA, 1999. IEEE Computer Society. [48] C. Rolland, C. Souveyet, and C. B. Achour. Guiding goal modeling using scenarios. IEEE Transactions on Software Engineering, 24(12):1055–1071, 1998. [49] R. Sebastiani, P. Giorgini, and J. Mylopoulos. Simple and minimum-cost satisfiability for goal models. In Proceedings of the 16th Conference On Advanced Information Systems Engineering (CAiSE’04)., 2004. [50] T. Ziadi and L. H´elou¨et and J.-M. J´ez´equel. Modeling behaviors in product lines. In International Workshop on Requirements Engineering for Product Lines (REPL), pages 33–38, September 2002. [51] M. Theodorakis, A. Analyti, P. Constantopoulos, and N. Spyratos. Contextualization as an abstraction mechanism for conceptual modelling. In ER ’99: Proceedings of the 18th International Conference on Conceptual Modeling, pages 475–489, London, UK, 1999. Springer-Verlag. [52] J. M. Thompson and M. P. E. Heimdahl. Extending the product family approach to support n-dimensional and hierarchical product lines. In 5th IEEE International Symposium on Requirements Engineering (RE’01), pages 56–65. IEEE Computer Society, 2001. [53] W. Tracz. DSSA (domain-specific software architecture): pedagogical example. SIGSOFT Software Engineering Notes, 20(3):49–62, 1995. [54] W. van der Aalst. The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers, 8(1):21–66, 1998. [55] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The Koala component model for consumer electronics software. Computer, 33(3):78–85, 2000. [56] E. S. K. Yu. Towards modelling and reasoning support for early-phase requirements engineering. In Proceedings of the 3rd IEEE Int. Symposium on Requirements Engineering (RE’97), Washington D.C., USA, January 1997. [57] E. S. K. Yu and J. Mylopoulos. Understanding “why” in software process modelling, analysis, and design. In Proceedings of the Sixteenth International Conference on Software Engineering (ICSE’94), pages 159–168, 1994. [58] Y. Yu, J. Mylopoulos, A. Lapouchnian, S. Liaskos, and J. C. Leite. From stakeholder goals to high-variability software design. Technical report, University of Toronto, 2005.
26
Requirements Modelling and Design Notations for Software Product Lines. T.J.Brown, R. Gawley, I. Spence, P. Kilpatrick, C. Gillan, R. Bashroush. School of Electronics, Electrical Engineering and Computer Science, The Queen’s University of Belfast. {r.gawley, tj.brown , i.spence, p.kilpatrick @qub.ac.uk {C.Gillan, R. Bashroush}@ecit.qub.ac.uk
continue to be the focus of active research with a consequent proliferation of notations and methods. Clearly there is a case for trying to agree on a standard approach to commonality/variability modelling. Equally clearly, there are still some aspects that merit continued investigation. In this paper we first briefly explore the basics of commonality/variability modelling using feature modelling. We then pose what seems to us a fairly fundamental question relating to the intended role of the commonality variability model within the engineering process. How one answers this question influences the notation and process needed. We describe our own vision of the role that commonality/variability models should play, and discuss our notation which combines both feature and behavioural modelling facilities. We also describe our current research which aims to understand the relationships between variability exposed within the feature and behavioural model and variability realisation techniques. Included among the latter are techniques such as those described in [3,4], along with design patterns, many of which serve to introduce flexibility into software designs. An understanding of these relationships opens up the possibility of creating an architect’s advisor, i.e. an intelligent tool with the ability to analyse the variability it finds within the commonality/variability model for an intended product line, and identify possible design techniques that allow it to be managed.
Abstract Although feature modelling is a frequently used approach to the task of modelling commonality and variability within product lines, there is currently no standard modelling notation or methodology. On the assumption that the commonality/variability model will be used as a basis for architecture design, our modelling notation allows features to be augmented with behavioural detail, captured using the UCM path notation. This gives rise to models that capture commonality and variability in behaviour as well as in product features, and are thus more valuable for downstream design activities. This paper outlines the modelling notation and describes ongoing work on the characterisation of variability points within models based on this notation, and on the relationships between model fragments and solution domain techniques such as design patterns or variability realisation techniques. It also describes preliminary work, aimed at evolving an intelligent tool that can characterise feature and behavioural model fragments and suggest design and realisation methods. Keywords:Feature diagram, Modelling language, UML
1. Introduction Software Product Line engineering [1] aims to maximise reuse within a family of related systems, by exploiting the commonalities across the family, while at the same time managing and accommodating the variability. The successful analysis and modelling of commonality and variability is therefore a crucial earlystage activity within software product line engineering. The most widely used approach to the capture of commonality and variability makes use of feature modelling. The basic concepts of feature modelling were introduced by Kang et al in 1990 [2], but have subsequently been revised and extended by many authors. Feature modelling notations and techniques
2. Feature Modelling: Basic Concepts and Contemporary Developments Feature Modelling originated in the work of Kang et al published in 1990 [2]. Their modelling schema Feature-Oriented Domain Analysis (FODA) introduced the foundational idea of describing product line requirements in terms of features that could be mandatory, optional or alternative, were organised into a tree and could be subject to constraints in the form of mutual exclusion or requirement relationships.
27
will influence the detailed notation and techniques that need to be used to capture the commonality and variability. Software systems are often large and the construction of commonality/variability models for a family of such systems represents a considerable investment in effort. In our approach to commonality/variability modelling we assume implicitly that maximal use should be made of such models once they have been constructed. Thus a commonality/variability model should certainly document the variety of product features and the potential for variability in the features supported within individual products. It should also allow the creation of individual product definitions as valid collections of supported features. Most approaches reported in the literature share these objectives. In our work we also seek to use the model to support the software design process, and in particular the derivation of a generic architecture for the product family. This aspiration introduces a number of issues. We must think carefully about how we should model commonality and variability, given the objective of using the model to guide architecture development. Identifying mechanisms to handle variability at the architectural and implementation stages is a significant issue in this process. Closely related to this is the question: How can we relate variability points within the model to actual variability realisation techniques? We are beginning to see the cataloguing of variability realisation techniques, for example in the work of Svahnberg et. al. [3], and the more recent work reported in [4]. Moreover, we already have a large literature on design patterns [16]. Many of these represent techniques for introducing flexibility into software designs, which makes them potentially valuable in the context of product line architectures, a point recognised by some authors [17]. It is probably unrealistic to expect that we can reach a stage where variability points manifest within commonality/variability models, can be mapped directly or uniquely to a particular realisation technique, or a particular combination of design patterns. But it would still be very useful to architects to be able to obtain guidance on possible design strategies. A further issue is how we relate the commonality/variability model to the generic architecture. Linking these two spaces allows us to relate architectural components to the product features that they support. This in turn makes it possible to derive product architectures from individual product feature sets.
Numerous developments have followed. The FORM notation [5,6] made use of layering within the model hierarchy, and. allowed the use of feature groups wherein selection is based on inclusive OR relations. Riebisch et al [7] introduced the idea of using explicit UML style multiplicities to constrain the selection of features from groups, an approach that has been further developed in several papers by Czarnecki et al. [8,9]. Using explicit cardinalities to regulate selection from groups conveys more flexibility than simply using alternative or OR feature groups which become special cases in this situation. More recently cardinality values have been attached to solitary (i.e. non group) features. In this context the cardinality specifies the number of times the features and its sub-tree can be replicated. Several authors have made use of feature properties or attributes. Fey et al [10] made use of the idea of feature properties and introduced two forms of relationship involving features and properties. Czarnecki et al [8,11] use the slightly different concept of attributes. An attribute type can be associated with a feature, indicating that a value of that type can be assigned during configuration, but only one such attribute is allowed per feature. Modularisation of feature models has also been recognised as desirable in practice because feature models are often very large. Bednasch et.al. [12] proposed an approach based on the use of special leaf nodes, while the idea of feature macros can be found in the work of Cechticky et al [13]. The potential value of incorporating behaviour in some way began to be recognised with the work of Mei et al [14]. In their FODM feature modelling notation they discuss the concept of behavioural characteristics attached to features that are recognised as functional in character. In the PLUSS feature modelling approach [15] broadly similar motives have prompted Eriksson et al. to combine features with Use case models and Use Case realisations. As described below the modelling of common and variant behavioural characteristics forms a key element in our approach. Clearly there is at this time a wide range of approaches to commonality/variability modelling and a corresponding argument for some form of rationalisation.
3. Role of Commonality Variability Models What should be the role of commonality and variability modelling in product line development? Should it be simply a means of recording and documenting the common and variant aspects of the product line, essentially for the benefit of customers, managers and sales personnel, or should it also play a more significant role in the software design and implementation activities? The answer to this question
4. The QUB Approach In our work we have sought to address all these issues. This has led us to develop a unique strategy for
28
inclusion in any given product. They are thus mutually exclusive: if one is supported the others cannot be. In addition, rationalised feature modelling allows the use of OR features [26]. An OR feature set is a set of features from which one or more may be selected into any product within the family. At least one must be selected but there is no exclusivity relationship, and in fact a product may contain all features within any OR feature set. As in FODA, feature selections may be subject to constraints and the now-standard constraints of mutual exclusion and requirement are supported. Features may also have attached properties and, borrowing from the work of Fey et al. [10], properties may participate in relationships.
commonality/variability modelling [18] that is based, like most such efforts, on feature modelling, but with facilities for capturing feature behaviour and behavioural variability. For this purpose we have adopted the Use Case Maps (UCM) notation. The UCM path notation [19,20,21,22,23] provides a means of capturing behaviour at an abstract level, independent of any assumed component architecture. A path can be attached to any feature provided the behaviour associated with the feature can be fully represented by a single path. (High level features within the model are assumed to aggregate behaviour associated with their children). As we relate below, having behavioural information allows a more complete characterisation of variability points. We have also developed a relational architecture description language called ADLARS [24]. This is a notation that supports the description of generic software architectures with embedded relationships between architectural components on the one hand and the supported product features on the other. This allows variant features within the commonality/variability model to be linked, for example, to alternative or optional components within the architecture design. Hence at the application engineering stage, as soon as the feature set for a single product has been defined, it becomes possible to generate the architecture for that product. We do not discuss ADLARS herein, since it is well documented in several publications. Instead we review the feature and behavioural modelling notation and then go on to describe current research efforts. These are focussed on two closely related problems. The first is to understand how variability points exposed within feature and behavioural models can be related to variability realisation techniques, including design patterns. The second is to identify the technology underpinnings for an ‘intelligent’ tool that could scan feature and behavioural models, abstracting out model fragments that encompass specific variation points and then offer guidance to the software architect on how each variability point could be managed in terms of software design. These are difficult topics and our research on them is at an early stage.
4.2. Bi-Directional Feature Modelling Perhaps the most radical aspect of the core feature modelling scheme is its support for bi-directional models [25]. In this approach a conventional top-down feature tree models features of the family that are software based, or have a software component, and an inverted feature tree models the hardware and operating system platform. The top-down feature tree follows the FORM practice of layering the feature tree. A threelayer model is used with a capability feature layer, which models high level product features, a domain technology layer and then an implementation feature layer below.
4.1 Feature Modelling Specifics In common with the original FODA framework, and most subsequent notations, our feature modelling schema allows features to be mandatory, optional or alternative. A mandatory feature will be supported by every product instance that supports it parent. Optional features are features that may be present or absent from any product within the family. Alternative feature sets are sets of features from which only one is selected for
Fig.1 Screen shot of a bi-directional feature model arising from ALS/APR safety procedure used on Optical Network Products [31]
The inverted feature tree can hold features arising from the operating system and/or the hardware platforms on which the software will operate. There can be relationships across the boundary between software
29
and the operating system platform. The first form of across-boundary relationship is that of mutual dependency between an optional or alternative software feature in the upper feature tree and an operating platform feature. The implication is that the software feature requires or depends on the availability of the platform feature. If an optional platform feature is excluded then the software feature depending on it cannot be provided. Although this may be a low level feature, the implications can extend upwards to the capability feature layer. The second across-boundary relationship is that of a hardware-software feature alternative. In this case we are dealing with the same feature which may be provided in software within one member of the family but in hardware within others. This kind of situation may arise in practice when the first products within an intended family are released with a certain feature provided in software; whereas in later models the feature migrates to a hardware device such as an ASIC, FPGA or DSP (we have encountered this phenomenon with some families of network products). It is worth noting that any kind of feature may participate in this relationship. Thus, we could have a mandatory feature which in some products is provided via software and in others via hardware. Likewise we could have an optional feature which, within some products, may not be provided at all, but if it is provided then it may be provided as either hardware or as software.
In the UCM notation, behaviour is captured in terms of a causal path. The path begins at a starting point, which may have triggering events and/or preconditions associated with it, and it continues to one or more end points, which may have associated resulting events and/or post-conditions. Along the way it may contain responsibility points, representing actions or responsibilities that must be discharged in the sequential order in which they appear. Paths may have loops, ORforks, which indicate alternative paths, and AND-forks that give rise to concurrent path segments that may be executed in parallel. Alternative paths may be labelled with the conditions that give rise to their selection. Concurrent and alternatives paths may rejoin at an AND-join, or OR-join, respectively. Data items may be created or destroyed and may be placed on, or removed from a path. Data placed on a path is considered to move along the path. The notation supports the concept of a pool, which is a form of generic data store, and data items may be moved into or out of pools. Paths may contain waiting points representing situations where processing is delayed awaiting the arrival of some external event, or the satisfaction of some condition. Synchronization and rendezvous points may also be included. A timer feature allows the introduction of timed path segments, in which execution must complete within a defined time, otherwise the normal execution path is aborted in favour of an alternative error path. In the basic notation a path may cross one or more components. Components need not be shown if no component architecture is available, or they may be included as rectangles.
4.3. Linking Behaviour to Features To capture feature behaviour, it is essential to have a suitably abstract notation. There are several well known notations that are often used for modelling behaviour. Within the UML, sequence and collaboration diagrams, Use Case diagrams, and activity diagrams can all be used for behaviour capture. For a number of reasons however [18], we have chosen the Use Case Maps path notation as the most appropriate form of notation. Use Case Maps, like feature modelling itself, is a requirements capture notation. Its focus is on the capture of behaviour at a reasonable level of detail. The founding concepts of the notation were introduced by Buhr [19] and have subsequently been extensively developed by Amyot and others [21]. Whereas feature modelling is inherently a notation targeted at productline requirements, UCM was developed as a general purpose requirements modelling notation, aimed at providing an abstract, path-centric view of system functionality. It has now been standardized and integrated into the User Requirements Notation (URN) [23].
Take sensor reading
Compare with threshold Too high Reduce power
normal
reading
Reset timer
Increment counter
Fig. 2 An example illustrating the UCM path notation
Where a responsibility point is located on the path in such a way that it is coincident with a component, this denotes the fact that the responsibility is being
4.4. UCM Path Notation
30
assigned to that component. An example of a UCM path is shown in fig. 2.
architecture and ultimately, implementation components. One of the principal difficulties in designing architectures for product lines is the need to accommodate variability from product to product. It is therefore important that the commonality/variability model should allow a clear understanding of the underlying nature of each variability point, and where possible, allow the identification of possible variability realisation methods. The decision to integrate behavioural modelling with feature modelling was prompted by this objective. A key theme in our current research efforts is the identification of possible variability realisation techniques using information within the feature and behavioural model. Although still at an early stage, factors that we have found to be important include the actual pattern of features in the environment of a variability point, the pattern of allocation of behaviour to those features and the pattern of usage of behavioural elements, such as stubs, within the path definitions. Properties attached to features can also be important. Our long term aim in this endeavour is the creation of an ‘intelligent’ tool with the ability to analyse the content of a commonality/variability model, characterise variability points within the model and offer recommendations on possible realisation techniques. Clearly this is an ambitious objective and much research is still needed. However, the problem is potentially more tractable with the fusion of feature and behavioural information. Some model fragments with mapped behaviour lead fairly readily to realisation strategies. For example, consider a feature model fragment in which a parent feature has an associated path containing a dynamic stub, with as children, an alternative feature group whose member features each have associated paths. A likely interpretation of this situation is a single algorithm with alternative subalgorithms, only one of which can be selected. A simple pattern, such as the template pattern, could be an appropriate realisation strategy in the case of finegrained algorithm variability. On the other hand, the same feature model structure, but this time with a parent feature whose associated behaviour could not be represented by a single path, would point to a different realisation strategy, perhaps, for example, the strategy pattern, as a possible realisation mechanism. The feature model fragment has the same structure in both cases, but the pattern of allocation of behaviour is different. As this work has progressed, an emerging issue is the possible advantage in adding some further facilities to the notation. Two new notational concepts that have been identified as potentially useful are those of property bound alternatives and synchronised alternatives.
4.4.1 Static and Dynamic stubs
A very important concept in the UCM notation is the idea of stubs. When a stub is embedded within a path it acts as a placeholder into which further behaviour can be plugged. Graphically a stub is represented as a diamond on the UCM path, and the plug-in behaviour will be represented as another UCM path. Stubs can be of two types. The simplest are called static stubs and only one subsidiary path can be plugged in to them. In this case the plug-in serves as a definition of the behavioural detail at that point within the containing path. The second kind of stub, called a dynamic stub, is characterized by the fact that several alternative plug-in maps may be inserted in them. The UCM concept is that the actual plug-in may be selected at run-time, depending on the satisfaction of associated pre-conditions. Dynamic stubs therefore represent points at which behaviour may vary. However, the plugins that may be inserted into either static or dynamic stubs may themselves contain stubs that may in turn be either static or dynamic. So, paths may have stubs for which the plug-ins may contain stubs, essentially to any level of nesting. Clearly this mechanism provides scope for the capture of behavioural variability to any level of detail. This is a very important capability and one that is exploited fully in the integration of Use Case Maps with feature modelling.
4.5 Capturing Feature Behaviour To add behaviour to a feature, in the simplest case, we attach a UCM path to the feature. We follow the principle that a UCM path will only be attached to a feature if that feature’s associated behaviour can be captured by one unique path. At first sight that might appear to imply that the allocation of behaviour to a feature would preclude the allocation of behaviour to its children. However paths can contain stubs. When a parent feature has a path with stubs, its children can contribute the plug-in behaviour needed. Of course the child feature’s path may also contain stubs which accept behaviour provided by grandchildren. Thus behaviour may be woven into multiple levels within the feature model structure.
5. Relating Variability points Variability Realization Techniques
and
To derive maximum benefit from the integration of these notations we clearly need to understand how to use the resulting framework to evolve a generic
31
notational feature, and the way multiple factors impinge on the possible variability realisation strategy chosen.
5.1. Property bound alternatives An alternative feature group wherein the alternative chosen depends on some property of its parent feature is what we refer to as a property bound alternative. Graphically this can be represented as shown below in fig 3. Feature ‘f’ is a parent feature with a group of five alternative children. The value of the ‘selecting property’ determines the choice of alternative child feature. An important consideration is that it is often possible to nominate a binding time for feature alternatives. One such option is run-time binding. By implication choice of run-time binding in this situation means that the selecting property is a variable, whose value at run-time will fix the alternative chosen. On the other hand a binding time earlier than run-time will imply that the selecting property is a constant. It is interesting that Svahnberg’s taxonomy of variability realisation techniques [3] includes two mechanisms described as condition on constant and condition on variable, respectively.
5.2. Synchronised Alternatives As described earlier, our modelling notation allows platform features to be modelled separately and allows relationships to be specified between platform based and software based features. It can be the case that variability at the platform level is closely coupled to variability at the software level. Within a model one can find a group of alternative features within the platform layer, which are effectively coupled to one or more alternative feature groups within the software layer. Selection of a particular alternative at the platform level effectively fixes the alternative required at each of the software based alternative feature groups. We describe this scenario as a set of synchronised alternative groups. However synchronised alternatives can arise wholly among the software based features. The example below shows a parent feature ‘f’ with four mandatory children. Each child devolves to an alternative feature group and all features have associated behaviour. Binding time is not shown in the interests of clarity. The set of four alternative feature groups are indicated as being synchronised, by the link between the four arcs. The implications of synchronisation are that either a1,b1,c1and d1 or a2,b2,c2 and d2 or a3,b3,c3 and d3 must be chosen. Given run-time binding, the fragment as a whole could be interpreted as indicative of the runtime variant component specialisation discussed by Svahnberg [3], with the abstract factory pattern being a candidate solution strategy. With an earlier binding time, other solution strategies become feasible including the strategy pattern.
f
Selecting property Value of selecting property will determine the alternative chosen
alt1
alt2
alt3
alt4
alt5
f
Fig. 3 Illustration of the property bound alternative concept
The most appropriate implementation technique depends on a number of considerations. If each alternative has an attached UCM path (not indicated in the diagram) then a fine-grained variability point is suggested and a simple programming based approach using, for example, a switch construct might be appropriate. On the other hand, if the alternative features do not have attached paths, then by implication we are dealing with coarser grained alternatives. Use of conventional pre-processor directives (#IFDEFs) to include one file or component instead of another represents one possible approach, particularly when the alternatives have compile-time binding. If the alternatives have run-time binding then design patterns like the state pattern can be considered. This discussion both illustrates the potential usefulness of this particular
a
a1
a2
a3
c
b
b1
b2
b3
c1
c2
d
c3
d1
d2
Fig. 4 The concept of synchronised Alternative Feature Groups
32
d3
framework, for product line design. Verification (see e.g. Czarnecki [32]) will be an important function of the tools. Prototype graphical editors have been developed, both for the feature and behavioural modelling notation and for ADLARS. Feature and behavioural models, created using the graphical tool are saved in XML. They can be viewed within a browser with the aid of an XSL style sheet and can be imported into the ADLARS Graphical editor. This can then be used to create a generic software design with linkages back to features. Individual product feature sets can then be used to produce custom architecture descriptions for the products. However, because product features are linked to behaviour, the behaviour associated with architectural components can be identified, allowed the generation of code stubs by the ADLARS Editor. This capability has been demonstrated in the prototype tools and is currently being further developed.
6. Grammar based model representations Several authors, building on the work of de Jonge and Vissor [27], have proposed translating feature models into context free grammars [28, 29]. More recently Batory [28] has described the interpretation of grammar representations in terms of propositional logic formulae. The motivation for much of this work comes from the need for verifying the correctness of feature model selections that represent individual products. Using Batory’s work as a starting point we are developing a notation to support the translation of feature and behavioural models into an attribute-based grammar representation that includes information on binding times, properties and crucially behavioural detail. However the motivation for this extends beyond the issue of verification, and includes the provision of technology support for a tool to identify design techniques from commonality/variability models. As part of this effort we are also developing a second, more abstract grammar notation capable of describing the generic characteristics of model fragments which point to particular variability realisation techniques. This is intended to provide a means of describing simple rules of the general form:
Library of patterns / variability realisation techniques Design assistant
Generic architecture
Feature/behavioural Model
Abstract fragment description »α variability realisation technique
Graphical Tool for Feature and Behavioural modelling
α
where » can be read as “suggests with probability α”. The intended strategy will be to match actual grammar productions derived from models with the abstract fragment descriptions found within rules to enable selection of possible realisation techniques. Because features can have attached behaviour (which is treated as an attribute), and given that the behaviour, specified as a UCM path, is itself structured the grammar formalism emerging from this work corresponds most closely to a higher-order attribute grammar. Recall that a normal attribute grammar has a context free grammar kernel, which represents a ‘structure tree’, with attributes that are associated with the elements within the structure, and may be related by semantic functions or constraints. In a higher-order attribute grammar [30], the attributes can themselves be structured, and constraints and functional relationships can be more complex.
Feature and Behavioural Modelling Notation
ADLARS Graphical Editor ADLARS: a language relating Architectural components to features
Fig. 5. Multiple tool Requirements modelling and design environment. ‘Design Assistant’ is an intelligent tool using Commonality/variability model information to actively support the identification of realisation techniques.
8. Conclusions and future work A commonality/variability modelling notation with tool support is key to our vision for a product line engineering framework. Within this vision, the commonality/variability model must perform a number of roles. As well as being a means of documenting product options and variability points, it must act as a starting point and a source of guidance to the downstream software design and development process. For this reason, our commonality/variability modelling schema combines behavioural modelling with feature modelling. This gives a richer pool of information, and makes it feasible to consider the possibility of intelligent tool-assisted architecture design. When used in conjunction with a relational architecture description
7. A multiple-tool requirements modelling and design environment Our research efforts are guided by the overall vision of a multiple notation and multiple tool commonality variability modelling and architecture development
33
language (a language relating the feature and architecture spaces), the behavioural information in the model can be carried across to the architecture design. Architectural Components therefore can have knowledge of the behaviour they must execute, thus opening the way for initial code generation. Further work on understanding the relationships between variability points revealed within model fragment structures, and variability realisation techniques, is clearly needed and may lead to new notational concepts like those discussed above. Additionally, the introduction of explicit cardinality annotations, a contemporary concept that has emerged from the work of others, is currently under consideration. One further point worth noting is that some work has been carried out [33] on the derivation of performance estimates from Use Case Maps, by first generating layered queuing networks (LQNs). This raises the possibility of a mechanism for assessing the performance costs associated with product features. In a product line context, the ability to make estimates of the performance implications associated with features and feature combinations would be a very useful capability. While we are not currently pursuing this issue, we are aware of the potential, another potential benefit of capturing feature behaviour in terms of the UCM notation.
[6] Kyo C. Kang, S. Kim, J. Lee and K. Lee, “FeatureOriented Engineering of PBX Software for Adaptability and Reusability”, Software Practice and Experience, vol. 29, 1999, pp. 875 – 896. [7] M. Riebisch, K. Bollert, D. Streitferdt, and I. Philippow, “Extending feature diagrams with UML multiplicities”, 6th Conference on Integrated Design and Process Technology (IDPT), 2002, [8] K. Czarnecki and C.H.P. Kim, “Cardinality-Based Feature Modeling and Constraints: A Progress Report”, OOPSLA’05 Workshop on Software Factories, 2005, available from [9] K. Czarnecki, S. Helsen and U. Eisenecker, “Staged Configuration Through Specialization and Multi-Level Configuration of Feature Models”, Software Process Improvement and Practice, vol.10, no.2, 2005, pp.143-169. [10] D. Fey, R. Fajta and A. Boros, “Feature Modeling: A Meta-model to Enhance Usability and Usefulness”, Proceedings of the 2nd International Conference on Software Product Lines (SPLC2), Springer, LNCS 2379, 2002, pp. 198 – 216. [11] K. Czarnecki, T. Bednasch, P. Unger and U. W. Eisenecker, “Generative Programming for embedded software: An industrial experience report”, Proceedings of the ACM SIGPLAN/SIGSOFT Conference on Generative Programming and Component Engineering (GPCE’02), Springer LNCS 2487, pp.156-172.
9. Acknowledgements
[12] T. Bednasch, “Konzept und Implementierung eines konfigurierbaren Metamodells fur die Merkmalmodellierung”, available (in german) from http:
We would like to thank the anonymous referees for their helpful comments on an earlier version of this paper.
[13] V. Chechticky, A. Pasetti, O. Rohlik and W. Schaufelberger, “XML-based feature modelling”, Proceedings of the 8th International Conference on Software Reuse: Methods, Techniques and Tools (ICSR 2004), Springer LNCS 3017, 2004, pp. 101-114.
10. References [1] L. M. Northrop, “A Framework for Software Product-Line Practice – version 3”, Software Engineering Institute, 2001.
[14] H. Mei, W. Zhang, F, Gu, “A Feature Oriented Approach to Modelling and Reusing Requirements of Software Product Lines”, Proceedings of the 27th International Computer Software and Applications Conference (COMPSAC’03). IEEE Computer Society Press, 2003.
[2] Kyo C. Kang, G. C. Shalom, J. A. Hess, W. E. Novak and A. S. Petersen, “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, Technical Report CMU/SEI 90-TR-21, 1990. [3] M. Svahnberg, J van Gurp, and J. Bosch, “A Taxonomy of variability realization techniques”, Software-Practice and Experience, vol. 35, 2005, pp. 705-754.
[15] M. Eriksson, J. Borstler, K. Borg, “The PLUSS Approach – Domain Modeling with Features, Use Cases and Use Case Realisations”, Proceedings of the 9th International Conference on Software Product Lines (SPLC 2005), Springer LNCS 3714, 2005.
[4] J. van Gurp, J. Savolainen, “Service Grid Variability Realisation”, Proceedings of the 10th International Software Product line conference (SPLC2006), IEEE Computer Society Press, 2006, pp. 85-94.
[16] E. Gamma, R. Helm, R. Johnson, J. Vlissides, “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley 1995.
[5] K. Lee, Kyo C. Kang, W. Chae and B.B. Choi, “Featurebased approach to object-oriented engineering of applications for reuse”, Software Practice and Experience, Vol. 30, 2000, pp. 1025 – 1046.
34
[17] S. Hallsteinsen, T.E. Faegri and M. Syrstad, “Patterns in Product Family Architecture Design”, Proceedings of the 5th International Software Product Family Engineering Workshop (PFE 2003), Springer LNCS 3014, 2003, pp261-268.
SIGPLAN Conference on Programming Language Design and Implementation, 1989, pp. 131-145. [31] ITU-T Recommendation G.664, “Optical safety procedures and requirements for optical transmission systems”, International Telecommunication Union, 2003.
[18] T. J. Brown, R. Gawley, R. Bashroush, I. Spence, P. Kilpatrick and C. Gillan, “Weaving Behavior into Feature Models for Embedded System Families”, Proceedings of the 10th International Software Product line conference (SPLC2006), IEEE Computer Society Press, 2006, pp. 52-61.
[32] K. Czarnecki and K. Pietroszek, “Verifying feature-based model templates against well-formedness OCL constraints”, Proceedings of the 5th international Conference on Generative Programming and Component Engineering (Portland, Oregon, USA, October 22 - 26, 2006). GPCE '06. ACM Press, New York, NY, pp211-220.
[19] R.J.A. Buhr, R.S. Castleman, “Use Case Maps for Object Oriented Systems”, Prentice Hall, 1996. [20] R.J.A. Buhr, “Use Case Maps as Architectural Entities for Complex Systems”, IEEE Transactions on Software Engineering, Dec. 1998, pp 1131 - 1155.
[33] D. Petriu and M. Woodside, “Software Performance Models from System Scenarios in Use Case Maps”, Proceedings of the 12th International Conference on Modelling Techniques and Tools, (TOOLS 2002), 2002, Springer LNCS Vol. 2344.
[21] D. Amyot, “Use Case Maps as a Feature Description Language”, Proceedings of FireWORKS ’00, S. Gilmore and M. Ryan (Eds), Language Constructs for Designing Features. Springer-Verlag, 2000, pp. 27 - 44. [22] ITU-T URN Focus Group (2002) Draft Rec. Z152 – UCM: “Use Case Map Notation (UCM)”, ITU_T, Geneva, 2002. [23] UCM web site at : http://www.usecasemaps.org. [24] T.J. Brown, I. Spence and P. Kilpatrick, “A Relational Architecture Description Language for Product Families”, Proceedings of the 5th International Software Product Family Engineering Workshop (PFE 2003), Springer LNCS 3014, 2003, pp282-295. [25] T.J.Brown, R. Bashroush, I.Spence, P.Kilpatrick, “Feature Guided Architecture Development for Embedded System Families”, Proceedings of the IEEE Working International Conference on Software Architecture, (WICSA), 2005. [26] K. Czarnecki and U. W. Eisenecker, “Generative Programming: Methods Tools and Applications, - Chapter 4”, Addison-Wesley, 2000. [27] M. de Jonge and J. Vissor, “Grammars as feature Diagrams”, in ICRS7 Workshop on Generative Programming (GP2002), online proceedings available at http://www.cwi.nl/events/2002/GP2002/ 2002.html, pp. 23-24. [28] D. Batory, “Feature Models, Grammars and Propositional Formulae”, Proceedings of the 9th Software Product line Conference (SPLC 2005), 2005, Springer LNCS 3714. [29] K. Czarnecki, S. Helsen andU. Eisenecker, “Formalising Cardinality-based Feature Models and their Specialisation”, Software Process Improvement and Practice, vol. 10, no. 1, 2005, pp. 7 – 29. [30] H. H. Vogt, S. D. Swierstra and M. F. Kuiper, “Higher Order Attribute Grammars”, Proceedings of the ACM
35
36
An Aspect-oriented Approach for Representing Variability in Product Line Architecture* Youngbong Kim, Mikyeong Moon, Keunhyuk Yeom** Pusan National University {saram, mkmoon, yeom}@pusan.ac.kr point is a conceptual point in a core asset that can be altered by the asset consumer. Each variant is one way to realize a particular variability and thus bind it in a concrete way [2]. In recent years, aspect-oriented software development (AOSD) techniques have been proposed that can separate crosscutting concerns clearly from modular units, so that these can be modularized as separate entities which would otherwise be scattered. In software product line engineering, aspects have emerged as a new variability management mechanism for the separation of variability in a software product line. For example, a combination of AOP and feature-oriented analysis (FOA) was proposed in [3] and Alves et al. [4] applied aspect-oriented programming(AOP) to the development of mobile game product lines. Griss proposed a conceptual framework of feature-driven, aspect-oriented product line engineering [5]. However, most of our current knowledge of combining aspects and variability management comes from the programming level of aspect-oriented concepts introduced in the early stages of AOSD. The initial focus of AOSD techniques has been at the programming level, resulting in a range of AOP techniques. However, the focus of AOSD has moved to crosscutting concerns that arise before implementation, because it is helpful for a developer to be able to consider the structure of the final implementation at all stages of the software life-cycle [6, 7, 8, 9]. Despite the rise of aspect studies as a modeling discipline and the importance of seamless traceability between the design and the code, few researchers have adopted aspects in a product line architecture design. This work focuses on the representation of the variability in the architectures of a given software product line development with aspect orientation. We propose a meta-model that describes extensions to the Object
Abstract Aspect-oriented software development has recently emerged as a new paradigm for systematic modularization and representation of the crosscutting concern. Because the variability in a software product line often has a crosscutting nature, several researchers have adopted aspects in variability management to separate the variability. While much work has been carried out at the programming level of aspect-oriented concepts, relatively little attention has been paid to the adoption of aspects in the early development stages, namely, product line architecture design. We present a meta-model that describes extensions to the Object Management Group’s Reusable Asset Specification by combining the many principles and concepts of aspectoriented modeling and product line architecture design. To validate our meta-model, we applied it to the engineering of an electronic travel service product line. Our metamodel-based product line architecture supports a systematic separation of the variability and a seamless traceability between the design and the aspect-oriented code.
1. Introduction Through the reuse of core assets, software product line based development can help to reduce time-to-market as well as development costs. The reusability of core assets requires the effective management of the variability of products in a software product line. Variability in a software product line is defined as a measure of how members of the product line may differ from each other [1]. A variability point (also called a variation point) and variants are used to define the variability. A variability *
This research was supported by the MIC(Ministry of Information and Communication), Korea, under the ITRC(Information Technology Research Center) support program supervised by the IITA(Institute of Information Technology Advancement)" (IITA-2006-(C1090-0603-0032)) ** Corresponding author
37
Management Group’s (OMGTM) Reusable Asset Specification (RAS) [10] by combining the many principles and concepts of aspect-oriented modeling (AOM) and product line architecture design. To validate our meta-model, we apply it to the engineering of an electronic travel service (e-TS) product line. Our metamodel can support a collection of models and diagrams to describe product line architecture effectively by localizing the effects of variability with aspect orientation. In addition, it can support a seamless traceability between the design and the aspect-oriented code. To provide a better understanding of our work, the next section presents an overview of RAS and AOM. Section 3 describes the e-TS product line and Section 4 presents our meta-model to represent variability in a product line architecture with aspect orientation. Related work is described in Section 5 and our conclusions are provided in Section 6.
artifact context such as a requirement, design, implementation, or test context. An artifact context helps explain the meaning of the elements in the artifact. The usage section describes the activities to be performed for applying or using the asset. Some activities are for the asset in general whereas other activities are for a specific artifact within the asset, and other activities may be relevant to a particular artifact context. For each variability point, there must be at least one activity that describes how to bind that variability point. The related assets section describes this asset’s relationship to other assets.
2. Background Our meta-model describes an extension to the fundamental element of Core RAS with many principles and concepts from AOM and in product line architecture design. This section briefly reviews RAS and AOM. Figure 1. The core Reusable Asset Specification (RAS) model
2.1 Reusable Asset Specification A Reusable Asset Specification (RAS) was recently adopted by the Object Management Group (OMGTM) and is now an open standard that can be used to manage any set of development artifacts. The scope of this specification is a set of guidelines and recommendations about the structure, content, and descriptions of reusable software assets [10]. RAS is described in two major categories: Core RAS and Profiles. Core RAS represents the fundamental elements of asset specification. The Profiles describe extensions to those fundamental elements. RAS defines three profiles, Default Profile, Default Component Profile, and Default Web Service Profile. Figure 1 shows a Core RAS Model. As the figure below indicates, Core RAS defines four major sections to an asset including the classification section, solution section, usage section, and related assets section. The classification section lists a set of descriptors for classifying the asset. The solution section describes the artifacts of the asset. An artifact is a work product that can be created, stored and manipulated by asset producers, consumers and tools. An artifact may have a relationship with another artifact. An artifact may have a variability point that is expected to be altered by the asset consumer, and which describes where and what in the artifact can be modified. An artifact may be relevant to a particular
2.2 Aspect-Oriented Modeling AOM ought to have the same relationship to AOP as object-oriented modeling has to object oriented programming [6]. Applying aspect orientation at the modeling level is not simply injecting code at a certain point within a program but requires the consideration of the full spectrum of modeling concepts not presented in programming: e.g., different views on the application’s structure and behavior as provided by current modeling languages, such as UML [11]. To establish a common terminology, a reference architecture for AOM was recently proposed in [9]. Figure 2 shows the reference architecture which is adopted from [9]. A concern is an interest that pertains to the system’s development and presents an inclusive term for an aspect and a base. A base is a unit of modularization formalizing a non-crosscutting concern. An aspect is a unit of modularization formalizing a crosscutting concern. The composition of aspects with bases is called weaving. An aspect consists of a description of how to adapt the concern, and a pointcut and an optional relative position describing where to adapt the concerns. The language describes the concepts required to formalize the concerns. Concerns are formalized using elements of a certain
38
language. Such elements are either structural elements or behavioral elements. An adaptation specifies in what way the concern’s structure or behavior is adapted, i.e., enhanced, replaced, or deleted. This concept is similar to the commonly found definition of an advice. A structural adaptation comprises a language’s structural elements for adapting concerns. Likewise, a behavioral adaptation comprises a language’s behavioral elements for adapting concerns. Figure 3. A PR matrix for an e-TS product line
Concern Weaving Base
Aspect
0..1
1..*
RelativePosition
4. Representing Variability in a Product Line Architecture with Aspect orientation
1..*
Pointcut
Adaptation
0..*
formalizedBy
representedAs
A product line architecture is defined as “a reference model for a set of applications sharing similar functionality, behavior and structure” [13]. The product line architecture has two main roles. First, it must describe the commonality and variability of the products in the software product line, and second, it must provide a common overall structure. In this section, we will present a product line architecture meta-model by extending the Solution model of a Core RAS model in a product line design context. First, we will describe the constructs for representing commonality and variability in a product line architecture with aspect orientation and then we will describe the product line architecture models which are composed of the elements in the constructs.
Structural Adaptation Behavioral Adaptatio modeledBy 1..*
1 Language
1..*
Element
modeledBy
Structural Element 1..* Behavioral Elemen
Figure 2. The AOM reference architecture
3. Example A product line architecture model is an instance of a product line architecture meta-model in a specific domain. In this section, we will describe an e-TS product line that we applied our meta-model to. The e-TS product line provides facilities on the Internet, such as e-travel catalogs, online reservations, secure e-payment systems, e-travel portal site service, and e-travel network/chain management. Figure 3 shows a partial primitive requirement (PR) [12] matrix of an electronic travel system domain, where the identified PRs are listed in the first column and the names of the electronic travel systems are listed in the header row. The determination of whether or not a PR can be reused is based on the frequency of its appearance in the PR matrix (i.e., the commonality ratio of the PR). The variation of the product line architecture reflects properties that were identified from the requirements analysis step, such as commonality and variability. Even though a single domain component or an single aspect may implement only one PR, frequently several related PRs are encapsulated as a domain component or an aspect.
4.1 Product Line Architecture Constructs Figure 4 shows an overview of our product line architecture meta-model from the point of view of architecture constructs. The solution has one new element: product line architecture. In the following text, the constructs for the product line architecture are described, along with its major characteristics. Asset 1
1
Solution
Product Line Archietcture
Usage
1..*
1..*
Artifact
0..*
Variability Point
1..*
0..* 0..* vp binding rule
Activity
Domain Component 0..* Variant Domain Component Binding 1..*
0..*
Interface
0..* Variability Point Bindin
Aspect Weaving
1..* Operation
0..1 Relative Position
1..* Point Cut
1..* Adaptation
Structural Adaptation
Behavioral Adaptation
Figure 4. A meta-model for product line architecture constructs with aspect orientation
39
The base constructs for representing a product line architecture are a domain component, an interface, an operation, and a domain component binding. These classify the types of variability points that can be identified at the architecture level.
Domain Component. A domain component describes a unit of computation or a date store. In general, a domain component represents commonality decoupled from variability in a product line architecture. Therefore, it can be commonly reused “as-is” in the production of multiple product architectures. In addition, the variability in a product line architecture can be formalized using a domain component when it can be encapsulated into a modular unit. In that case, the aspect can be used to describe the dependency between a variable domain component and the other domain components. Interface. An interface describes a set of defined operations that are accessible from outside the domain component and form the signature of the interface. The external behavior of a domain component is defined by its provided and required interface. Operation. An operation describes an individual action that a component instance will perform. Domain Component Binding. A domain component binding describes architectural building blocks used to model interactions between domain components.
Figure 5 shows some of the domain components that were extracted from the e-TS product line. The Customized Plan Mgr domain component that contains PR12, PR13, and PR14 has a variable property that indicates that it may appear optionally in an application.
Figure 5. Domain components in e-TS product lin. Constructs for representing variability in a product line architecture are a variability point, and a variant. An aspect and its constituents form a representation of variability with aspect orientation.
attached, or where a behavior can be changed. From an aspect-oriented point of view, a point cut describing when to adopt the adaptation represents the formation of a variability point. Variant. A variant defines one way to realize a particular variability, and bind it in a concrete way. An adaptation describing what to do at a point cut can be used to represent a variant. Aspect. An aspect is defined as a unit of modularization formalizing variability in a product line architecture. In the case where variability cannot be modularized as a domain component, an aspect forms a representation of the variability. In addition, as has been pointed out, an aspect can be used to describe a dependency between a variable domain component and other domain components. Along with [9], we define an aspect as consisting of a relative position, a point cut, and an adaptation. Relative Position. A relative position may provide further information on where adaptations have been introduced. Point Cut. A point cut defines a location in a product line architecture that is expected to be modified in the production of multiple product architectures. Adaptation. An adaptation defines in what way a product line architecture is to be adapted. Commonality models, which are composed of elements in the base constructs, can be augmented by new constructs or replaced. Structural Adaptation. A structural adaptation comprises structural elements of a product line architecture for adapting the common structural model. That is, a structural adaptation can be defined as augments or replacements in the common structure model. Behavioral Adaptation. A behavioral adaptation comprises the behavioral elements of a product line architecture for adapting the common behavioral model. Because the common behavioral model contains interactions for each interface and operation, their variability causes the interactions to alter. That is, the variability in the domain component interactions is defined as an alteration in which an execution flow may or may not appear in a common behavioral model based on the variability of the interface or operation. A structural adaptation is often required to conduct a behavioral adaptation.
Figure 6 shows some of the aspects that were extracted in our e-TS product line. Because the Customized Plan Mgr domain component has a variable property, an ACustomized Plan Mgr aspect is extracted to describe the
Variability Point. Along with [10], we define a variability point as a location in a product line architecture where additional behavior can be
40
oriented codes. In the following, the models for a product line architecture are described, along with their major characteristics.
dependency between the ACustomized Plan Mgr and other domain components. The Package Reservation Mgr domain component provides functions for reservation, review, modification, and cancellation of vacation packages. The Search Engine Mgr domain component provides function for package search, flight search and hotel search. Supporting a list of options for a vacation package is variable function. An IPackage Reservation interface of the Package Reservation Mgr domain component and an IPackage Search interface of the Search Engine Mgr domain component have a variation point that indicate it may optionally support a list of options for a vacation package. As Figure 6 shows, an APackage Option Mgr aspect provides an implementation of an operation display package option of the IPackage Search interface and an operation select package option of the IPackage Reservation interface. The Customer Info Mgr domain component provides the functions for managing information regarding the customers. Customer information concerning e-money, gift certificates, or coupons is only necessary when an application can support payment services, such as payment by coupon or by e-money. Therefore, the ICustomer Supplement Info interface in the Customer Info Mgr domain component has a variability point that indicates that it may be optionally realized in an application component. As shown in Figure 6, the ICustomer Supplement Info interface in the Customer Info Mgr domain component is extracted as an ACustomer Info Mgr aspect.
Figure 7. A metamodel for product line architecture model with aspect orientation A commonality model and a domain component specification form a representation of commonality. The model can be commonly reused “as-is” in the design of multiple product architectures. In addition, it can be augmented by new constructs or replaced by weaving aspects to fulfill specific product requirements.
Figure 6. Aspects in the e-TS product line 4.2 Product Line Architecture Models The product line architecture models are composed of elements in the constructs. Figure 7 shows that the product line architecture is associated with several classes, including model, diagram, and specification. A model may have multiple diagrams and specifications. A model represents an inclusive term for the commonality model, describing the commonality in a product line architecture, and the variability model, describing the variability in a product line architecture. The composition of the commonality and variability models produces an integrated view of the product line architecture. Using a separate variability model, we can simplify an already complex commonality model that can be overloaded by adding the variability. In addtion, it can support seamless traceability between a design and aspect-
41
Commonality Model. A commonality model describes the common structural and behavioral solutions for the product line requirements. A commonality model represents an inclusive term for a common structural model, a common behavioral model, and a domain component specification. Common Structural Model. A common structural model is used to describe a common static structure of the product line. Domain components and their relationships are intended to describe a common structural model. A common structural model can, but does not have to, be related to one or several variability points and variants. Common Behavioral Model. A common behavioral model is used to describe a common behavior of the product line by representing how the domain components interact with each other, or how interfaces will be used. A common behavioral model can, but does not have to, be related to one or several variability points and variants. Domain Component Specification. A domain component specification includes the interface specifications that are specified by a set of operation specifications, and also the constraints on the way the interfaces are to be implemented.
Figure 8 shows a partial common structural model of the Search Engine Mgr domain component.
variability in behavior of the product line. Aspect Specification. An aspect specification details aspects depicted in the variability model.
Figure 10 shows a partial variable structural model of the APackage Option Mgr aspect. An implementation of the search package option operation and the display package option operation are provided by the APackage Option Mgr aspect.
Figure 8. A common structural model of the Search Engine Mgr
Figure 10. A variable structural model of the APackage Option Mgr
Figure 9 shows a partial common behavioral model of the Search Engine Mgr.
Figure 11 shows a partial variable behavioral model of the APackage Option Mgr aspect. The APackage Option invokes an operation of the IPackage Search and an operation of the IPackage Reservation before the reserve package operation.
Figure 9. A common behavioral model of the Search Engine Mgr A variability model and an aspect specification form a representation of the variability.
Figure 11. A variable behavioral model of the APackage Option Mgr
Variability Model. A variability model describes the variability that can be found in the structural and behavioral solutions for the product line requirements. In general, the aspects are intended to describe a variability model. In addition, as we have seen, a variable domain component and an aspect that defines a dependency between the domain component and other domain components can be included in a variable model. A variability model represents an inclusive term for a variable structural model, a variable behavioral model, an aspect specification, and a domain component specification. Variable Structural Model. A variable structural model is used to localize the variability in a static structure of the product line. Variable Behavioral Model. Likewise, a variable behavioral model is used to localize the
5. Related Work There has been other research effort into the application of AOSD techniques to product line engineering. The combination of AOP and FOA was proposed in [3], and the result of using FOA includes commonalities and variabilities, dependencies among the features, and feature binding time information. This work presents how these analysis results can be used as key design drivers for aspect-oriented product line asset development, namely asset implementation. Alves et al. [4] applied AOP to the development of mobile game product lines, and Griss proposed a conceptual framework of feature-driven, aspect-oriented product line engineering [5]. The key idea is to use AOP techniques for
42
implementing features that are identified as commonalities and variabilities in a software product line. In addition, there have been several approaches on extending AOP techniques by combining then with other techniques, such as feature-oriented programming (FOP) [14] and frame technology [15]. Mezini et al. [16] proposed a method, called Caesar, which combines the benefits of FOP and AOP, and Loughran et al. [17] combined the benefits of frame technology and AOP. This works has shown that when using AOP, we can implement variable features that may crosscut several modular units as separate aspects. The main difference between the above works and ours is that we have applied the aspects from architecture variability-oriented point of view and have identified the aspects in the architecture design and not in the code. In particular, we have proposed a meta-model to support a collection of models and diagrams to describe a product line architecture effectively by localizing the effects of variability with aspect orientation. Through a product line architecture, which is an instance our the proposed meta-model in specific product line, we support seamless traceability between the design and aspect-oriented code. Referring particularly to the product line architecture, an important task is to analyze the product line and to identify the commonalities and variabilities of the components and operations of the product line. The Feature-oriented Reuse Method (FORM) [18] was developed as an extension of the Feature-oriented Domain Analysis (FODA) method [19]. The main characteristic of FORM is its four-layer decomposition, which describes different points of view with regard to product development. However, this does not address explicitly the variability in a product line architecture, and entails complexity when many variants must be represented. In [20], the variation is represented using patterns associated with discriminants: there are three types of discriminant, single, multiple, and optional, which are closely related to the division of the feature properties into mandatory, optional, and alternative. However, the above method does not emphasize the characteristics of the variability at the design level. The variability in the various phase of a software product line development has different abstractions. While the requirements models are concerned with features and capabilities of the product line, the design models focus on components, interfaces, and operations.
from early AOSD. The focus of AOSD has moved to crosscutting concerns that arise before implementation. In addtion, seamless traceability between the design and the code with aspect orientation is important. To tackle these problems, we have proposed a meta-modeling approach for representing the variability in a product line architecture. First, we specified the constructs of a product line architecture to explicitly represent and separate the variability with aspect orientation. As an extension of the RAS, these constructs were extracted by mapping to a variability and using well-developed existing AOM approaches. Then we presented a product line architecture model that was composed of elements in its constructs. Our future research activities will include traceability management from the requirements level aspects through later product line architecture and aspect-oriented implementation.
7. References [1] Weiss, David M. and Chi Tau Robert Lai, Software Product-Line Engineering: A Family-based Software Development Process, Reading, MA, Addison-Wesley [2] G. Halmans and K. Pohl, “Communicating the Variability of Software-Product Family to Customers”, Proc. Software and System Modeling, vol. 2, Feb. 2003, pp. 15-37 [3] K.W. Lee, K.C. Kang, M.S. Kim and S.Y. Park, “Combining Feature-Oriented Analysis and AspectOriented Programming for Product Line Asset Development”, Proc. of 10th International Software Product Line Conference, Baltimore, USA, 2006. [4] V. Alves, P. Matos Jr., L. Cole, P. and Borba, G. Ramalho, “Extracting and Evolving Mobile Games Product Lines”, Proc. of 9th International Software Product Line Conference, Rennes, France, Sep. 2005, pp. 70-81. [5] M. L. Griss, “Implementing Product-Line Features by Composing Aspects”, Proc. of First Software Product Line Conference, Denver, Colorado, 2000, pp. 271-288 [6] R. Filman, T. Elard, S. Clarke, and M. Aksit (eds), Aspect-Oriented Software Development. Addison-Wesley, 2005 [7] R. France, I. Ray, G. Georg, and S. Ghosh, “Aspectoriented approach to early design modeling”, IEE Proceedings Software, 151(4), Aug, 2004, pp. 173-185 [8] M. Kande, J. Kienzle, and A. Strihmeier, “From AOP to UML - A Bottom-Up Approach”, Proc. Of the Workshop on Aspect-Oriented Modeling, Mar, 2002 [9] A. Schauerhuber, W. Schwinger, E. Kapsammer, and M. Wimmer, “Towards a Common Reference Architecture for Aspect-Oriented Modeling”, Proc. of the 8th International Workshop on Aspect-Oriented Modeling, Mar, 2006
6. Conclusions Aspects are a major concern for the variability management method used in software product line engineering. However, most works have been conducted using the programming level aspect-oriented concepts
43
[10] The Object Management Group (OMG), Reusable Asset Specification (RAS) Version2.2, http://www.omg.org/technology/documents/formal/ras.ht m, Nov. 2005. [11] Object Management Group (OMG), Meta Object Facility (MOF) 2.0 Core Specification Version 2.0. http://www.omg.org/docs/ptc/04-10-15.pdf, Oct, 2004 [12] M. Moon, K. Yeom, and H.S. Chae, “An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability in a Product Line”, IEEE Transactions on Software Engineering, 30(7), Jul, 2005, pp.551-569 [13] D.J. Duffy, Domain Architecture: Models and Architectures for UML Applications, Wiley, 2004 [14] D. Batory, J. N. Sarvela, and A. Rauschmayer, “Scaling Step-Wise Refinement”, IEEE Transactions on Software Engineering, 30(6), 2004, pp. 355-371 [15] P.G. Bassett, Framming, Software Reuse: Lessons From The Real World, Yourdon Press, New Jersey, 1997 [16] M. Mezini and K. Ostermann, “Variability Management with Feature-Oriented Programming and Aspects”, Proc. of twelfth ACM SIGSOFT International Symposium on Foundations of Software Engineering, Newport Beach, CA, 2004, pp. 127-136 [17] N. Loughran and A. Rashid, “Framed Aspects: Supporting Variability and Configurability for AOP”, Proc. of eighth International Conference on Software Reuse, Madrid, Spain, 2004, pp. 127-140. [18] K.C. Kang, S. Kim, J. Lee, and K. Kim, “FORM: A Feature-Oriented Reuse Method with Domain Specific Reference Architectures”, Annals of Software Engineering, vol. 5, pp.143-168, 1998. [19] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, Feature-Oriented Domain Analysis (FODA) Feasibility Study: Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Nov. 1990. [20] B. Keepence and M. Mannion, “Using patterns to model variability in product families”, IEEE Software, 16(4), pp.102-108, 1999.
44
Separation of Variability Dimension and Development Dimension Isabel John, Jaejoon Lee, and Dirk Muthig Fraunhofer Institute for Experimental Software Engineering (IESE), Kaiserslautern, Germany {isabel.john, jaejoon.lee, dirk.muthig}@iese.fraunhofer.de
Managing variations at different levels of abstraction and across all generic development artifacts is a daunting task, especially when the systems supporting various products are very large, as is common in an industrial setting[2]. With large systems the necessity to trace variability from the problem space to the solution space is evident. Approaches for dealing with this complexity of variability need to be clearly established. When applying product line engineering in practice. it has been recognized that a unified approach for variability management has to be defined. In [3], one of the four aspects in the context of a unified variability management approach (consistency, scalability, traceability and visualization), namely traceability, has been analyzed. It starts with a traditional view on software engineering for single systems, which has thus far been done in two dimensions: one representing the phases of development, the other levels of abstraction. With abstraction we describe mechanism and practice to reduce and factor out details so that one can focus on few concepts at a time [4]. Artifacts that do not contain implementation details and so leave many solutions as possible (like use cases in a requirements specification) are on a high abstraction level, artifacts with few or only one concrete implementation solution (like the concrete source code or the compiled and linked program) are on a low abstraction level. All development artifacts can be placed somewhere in these dimensions. The structure of development artifacts is determined by structures useful for capturing system information, such as requirements, architectural views, or design information. Variation points, representing variability, are woven into these structures given by single system software development approaches. The artifacts in the development dimension (requirements, architecture...) are distributed from problem space to solution space and have a decreasing abstraction level because they restrict the number of possible solutions from development step to devel-
Abstract Controlling and managing variability across all life cycle stages is the key practice area that distinguishes product line engineering from single system development. Therefore, product line researchers have proposed many approaches and techniques for addressing variability management. There is, however, no standard or standardized framework yet that organizes and structures the different approaches in a clear and comparable way. This paper uses the concept of a variability dimension to clearly separate variability-related issues from all other aspects related to development artifacts. Along the variability dimension, the paper then presents the variability philosophy used by Fraunhofer PuLSE (Product Line Software and System Engineering)1 that manages all kinds of variabilities (i.e., from problem to solution space, from specification to runtime) in a unified way. Keywords: Variability Management, Variability Dimension, Decision Modeling, Problem Space, Solution Space.
1. Introduction Product line engineering is an approach that develops and maintains families of products while taking advantage of their common aspects and predicted variabilities [1]. A product line infrastructure is developed based on the commonality and variability that exists between the products in a family. Commonality defines those characteristics that are the same between products, whereas variability implies the opposite, i.e. the differences between the products.
1
PuLSE is a registered trademark of the Fraunhofer Institute for Experimental Software Engineering (IESE), Kaiserslautern, Germany
45
High Abstraction Variability Information
Requirements Analysis Architecture
Component Design Source Code
Problem Space
Low Abstraction
Solution Space
Variability
Figure 1. Three dimensions for software product line engineering opment step and therefore come to a more and more concrete solution. Then, variability as needed in software product line engineering is introduced by adding a third dimension that explicitly captures variability information between product line members (see Figure 1). Variability is an orthogonal concept here: Variability is not part of the development artifacts and therefore not part of the models or code, it has a dimension of its own. In this paper we define the three main concepts that hold together the variability dimension and the development and abstraction level: variation points, decisions and binding time. With these three concepts we can explain what variation or variability is and what advantages an orthogonal variability dimension has if we have to model variability in different phases as this happens in product line engineering. The following sections describe different aspects related to variability information. Section 2 maps the concept of variation points that – as defined in [5] – identify locations at which variation will occur in development artifacts. Section 3 introduces a decision model that captures all kinds of relationships among variation points. Section 4 discusses binding time of decisions or variation points in the context of underlying development processes. Section 5 concludes the paper.
2. Variation Points Orthogonal variability dimensions have been introduced in many variability modeling approaches [6][7][8]. A variation point as it was originally defined by [5] ”identifies one or more locations at which a variation will occur”. A variation point describes the occurrence of variability in a development artifact. As the variation point is part of the development artifact, it fully lies in the development dimension of the model described in figure 1. At the different levels, variation points can (and should) be represented differently. It is often represented by a certain variability notation or variability modeling mechanism as e.g. features for requirements, variant UML for architectures and different variability mechanisms for code [3]. One variability often is represented in many variation points. The same variability can have different variation points in one development artifacts (e.g. the variability display size can occur in different requirements of a mobile phone) or it occurs in the different development artifacts (the display size can be described by variation points in requirements, architecture, or code). One variation point is always assigned to one variability, so the variation point maps the variability into the development dimension. We have to distinguish between the conceptual variation point which should only be seen as a point or pointer into the development artifacts to show where the variability occurs from the physical representa-
46
Decision Name A name for the decision
Decision /Question
Type
Variation Points
The question that describes the decision
The varia- The variation points Constraints of the decition type the decision relates to sion to different vari(e.g. opabilities tional, 1:n etc) Table 1 Elements of the decision model
tion of the variation point where we have a concrete notation that marks variability in the development artifacts. Nevertheless the variability dimension should be separated as much as possible, so we need an additional concept to map the variation points to the variability dimension and to describe influences and constraints of variabilities and variation points. This concept is the decision and the decisions are collected in a decision model.
Constraints
Binding Time
The possible binding times for the decision and its variation points
ity (e.g. the variability type of a variability that the decision resolves). Feature modeling is a common decision modeling approach known in literature to be used for the management of variabilities in software product lines. The feature model has been recognized by Riebisch [9] [10] to be the model that closes the gap between the problem space and the solution space by providing means for tracing variability. Other, more text/table oriented approaches for decision modeling are described in [11]. By specifying the possible features, the possible solutions for a variation point are specified and the constraints are given. In our research and industrial projects we have identified the following relationships that should be captured in a decision model [3][11][7]: - Restrictions on the variation points that are related to the variability (e.g. possible variability types), - Restrictions on the binding time of the variability (see section 4), - Relationships of variabilities (constraints of one variability to others, for example if the absence of one variability implies the absence of another one). With these relationships identified we get the following decision model (see Table 1). The variation points are either listed explicitly in the decision model or the link is made by using the name of the decision in the representation of the variation point in the development artifact as e.g. described in [7] and [11]. In the decision model all constraints are captured that constrain other decisions or variabilities (e.g. display_size < 12 => display_lines < 4). The possible binding time also includes runtime, so we have to represent the decision model in a way that it can be at least partially interpreted at runtime. This can be done by operationalizing configuration strategies as it is described in [12].
3. Decision Models Simply identifying and modeling variabilities among the products in a product line as this is done in the variability dimension spans up the space of all possible products. But the variation points do not define the association of the features to the planned products of the product line and what dependencies and interrelationships exist among variabilities and variation points. This information is captured with decisions collected in a decision model. Additionally, the decision model restricts the value range of the variation points from a general range to the values that are possible and wanted for the products in a product line. For example, if we have a variation point that specifies the number of lines that a mobile phone can display, values from 1 to 50 might be possible. But if we plan a product line of business phones with large displays, this number is restricted to 10 – 20 in the decision model. So a decision is strongly related to a domain concept and so to the problem space (c.f. Figure 1). Essentially a decision model consists of decisions that relate user visible options to specific system features and finally to variation points within generic artifacts. The decisions are views on the variability dimensions, as they cluster and filter the variability information. As the bridge between the variability dimension and the development dimension, they are partially integrated with the development artifact dimension over the relationship to the variation points and partially integrated with the variability dimension by giving general information on variabil-
47
-
to adopt the variability mechanism to be used to the development dimension, to the level of abstraction and to the context of the product line and - to explicitly support all binding times, including runtime. In order to fulfill this philosophy, we need an adequate representation of variation points and variability mechanisms for every artifact; for all types of useful binding times etc. They all must be connected to the variability dimension [7] in order to provide traceability and understandability for all documentations. In order to satisfy the four central aspects in the context of a unified variability management approach (consistency, scalability, traceability and visualization [3]), more research is needed in the area of usable decision models but also on analyzing, representing and validating information in the variability dimension and on the influence of different binding times (especially runtime) on the variability dimension.
4. Binding Time The time of when to make a decision on variants of a variation point is referred to as ‘binding time’ and its importance is being recognized in the literature [2][12]. The key issues related to binding time include [12]: - Explicit expression of binding time of each variation points with consideration of available binding techniques, - Binding time consistency among variation points, - Binding time dependency among variation points, - Binding at runtime (i.e., selection of variants at runtime). The first issue is about the ‘identification’ of binding time for each variation point: each variation point can have unique binding time. For example, some variants are selected and bound to a product at product development time, while others may be determined from a list at installation time. The second issue is about the ‘unit’ of binding: variation points that belong to the same binding unit must have the same binding time. The third issue refers to the ‘order’ of binding: some variants of a variation point become available only after a certain set of variants are bound beforehand. The fourth issue is about the ‘runtime selection’ of variants: some variants of a variation point may be selected and/or parameterized at runtime by a user or by a product itself when a certain contextual change is recognized. In our variability model, these issues can be addressed explicitly as we can analyze and specify binding time information at the variability dimension. It addresses the binding time issues not only within an artifact (e.g., binding time of different requirements in requirements specifications) but also across artifacts (e.g., binding time between requirements specifications and architecture models). Therefore, this separate view on product line variations facilitates the explicit and rigorous exploration of binding time of variation points.
Acknowledgement This research is partially carried out in the Cluster of Excellence 'Dependable adaptive Systems and Mathematical Modeling' project, which is funded by the Program 'Wissen schafft Zukunft' of the Ministry of Science, Education, Research and Culture of Rhineland-Palatinate, Germany, AZ.: 15212-52 3092/40 (30).
References [1] Weiss D., Lai C: Software Product Line Engineering. Addison-Wesley (1999) [2] Bosch, J., Florijn, G., Greefhorst, D., Kuusela, J., Obbink, J. H., Pohl, K.: Variability Issues in Software Product Lines. In: van der Linden, F. (eds.): Software Product Family Engineering. Lecture Notes in Computer Science, Vol. 2290. Springer-Verlag, Berlin Heidelberg (2002) 13-21 [3] Berg, K., Bishop, J., and Muthig, D. Tracing software product line variability: from problem to solution space. In Proceedings of SAICSIT 2005, ACM International Conference Proceeding Series, vol. 150. 2005 [4] http://en.wikipedia.org/wiki/Abstraction_%28dis ambiguation%29 [5] Jacobson, I.; Griss, M.; & Jonsson, P. Software Reuse: Architecture, Process, and Organization for Business Success. Reading, MA: AddisonWesley Longman, 1997.
5. Outlook The position that we describe in this paper is that with the main concepts of variation point, decision, and binding time we can explain the variability dimension in a sufficient way. Our philosophy is: - to clearly separate the variability dimension and the development dimension during product line modeling, derivation and usage
48
AND D, STREITFERDT, Eds. BooksOnDemand Publ. Co., Norderstedt, 64-76. [10] Riebisch, M. 2004. Supporting Evolutionary Development by Feature Models and Traceability Links. In Proceedings of the 11th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, ECBS 2004, Brno, Czech Republic, May 2004, Computer Society Press, 370-377. [11] Schmid, K., John, I.. A customizable approach to full lifecycle variability management, Science of Computer Programming, v.53 n.3, p.259-284, December 2004 [12] Lee, J. and Kang, K.. Feature Binding Analysis for Product Line Component Development. In: F. van der Linden (eds.): Software Product Family Engineering. LNCS, Vol. 3014. Springer-Verlag, Berlin Heidelberg (2004) 266-276
[6] van Gurp, J., Bosch, J. and Svahnberg, M.. On the Notion of Variability in Software Product Lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01), 2001. [7] Muthig, D. and Atkinson, C. Model-Driven Product Line Architectures. In Proceedings of the 2nd International Software Product Line Conference, SPLC 2, Springer-Verlag 2002 [8] Lauenroth, K.; Pohl, K.: Principles of Variability. In: Pohl, K.; Böckle, G.; van der Linden, F.: Software Product Line Engineering – Foundations, Principles, and Techniques. Springer, Heidelberg 2005. [9] Riebisch, M. 2003. Towards a More Precise Definition of Feature Models. In Proceedings of Modelling Variability for Object-Oriented Product Lines ECOOP Workshop, Darmstadt, Germany, July 2003, M. RIEBISCH, J. O. COPLIEN
49
50
Modelling Variation in Quality Attributes Leire Etxeberria, Goiuria Sagardui, Lorea Belategi Computer Science Department University of Mondragon Loramendi 4, 20500, Mondragon, Spain {letxeberria, gsagardui}@eps.mondragon.edu,
[email protected]
In a product line different members of the line may require different levels of a quality attribute, for instance they could differ in terms of their availability, security, reliability… One product may require a very high reliability whereas in another reliability is not important. There may also be products that have the same functionality but differ in quality attribute levels. The idea of variations in quality is considered in different works [21][13][23] and there are also some approaches that address variability modelling taking into account quality attribute variability. However, “there is a lack of thorough understanding of existing approaches to be able to integrate quality attribute variability as a part of the systematic variability management of software product lines” as proposed by [21]. In this paper we survey several existing methods that address quality attribute variability and we define a set of requirements that those methods and approaches should have in our opinion to allow modelling different kinds of quality attribute variability. The rest of the paper is organized as follows. In Section 2 quality attribute variability modelling is discussed, section 3 addresses an overview of the compared methods, section 4 presents a set of requirements for modelling approaches and in section 5 an evaluation framework is proposed to compare different approaches and results of the comparison are presented. In section 6 related work is presented and finally section 7 draws conclusions.
Abstract In a software product line different products often require different levels of quality attributes. In several domains quality attribute variability gets even more importance that functional variability management. However, quality attribute variability in software product lines has not received much attention by researchers. This paper presents a survey of existing approaches for specifying variation in quality attributes.
1. Introduction “Software product line (SPL) is a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [7]. Variability is a key aspect in software product lines but traditionally the main focus has been on functional variability. There are a lot of methods and notations to model functional variability in product lines, some of the most used are feature model based notations [8][17][18]. On the other hand, quality attribute variability in software product lines has not received so much attention by researchers. Software quality is the degree to which software possesses a desired combination of attributes [14]: Performance, security, availability, functionality, usability, modifiability, portability, reusability, integrability, testability [1]… In some domains the fulfilment of quality attributes is even more important that addressing functional requirements. For instance, in embedded systems time or safety issues may be of great importance and their modelling has even bigger complexity that functional requirements modelling.
2. Quality attribute variability modelling In a product line, there are often products with varying levels of quality attributes. This variability should be modelled and managed from the beginning of the product line development and taken into consideration for designing. Quality attribute
51
In this section, each of those methods is briefly explained.
variability is much related to functional requirement variability because often quality attribute variability is achieved through varying functionality and this interrelation must be also represented. This information is very important when deriving because selecting one or another variant has different impact on quality. Many variants represent design decisions that can have a great impact on quality attributes. A model where quality attribute variability is modelled as well as the impacts of functional variants on quality attributes is indispensable to take the most adequate decisions during design and derivation and get the required quality levels. There are approaches for specifying quality attribute requirements that do not address variability explicitly. In a similar fashion, there are approaches for specifying varying requirements that do not address quality attributes [21]. One of the most used modelling techniques to specify varying requirements is the feature model. This model by definition may be used to specify both functional and quality characteristics but in fact quality attributes are difficult to capture in the model due to their ambiguous nature. Moreover, different types of quality variability can be identified. Niemelä [23] defines three types of quality attribute variability: o Variability among different quality attributes: For example, for one family member the reliability is important, but for other family members there are no reliability requirements. o Different priority levels in quality attributes: For example, for one family member the extensibility requirements are extremely high, whereas for others those requirements are at the lowest level. o Indirect variation: Functional variability can indirectly cause variation in the quality requirements
3.1. Goal-based model This approach [11] proposes to use goal-oriented analysis in product lines. Goal-oriented requirements engineering is an approach that deals with quality attributes or non-functional requirements in singlesystems [5]. A goal-based model for representing requirements variants (different set of requirements for each product of a product family) is proposed and a visual variability analysis technique is provided. This model is a restricted version of the goal model of the NFR framework [22] and in goal reasoning framework (a probabilistic model) [10]. Two sub-models are proposed: A functional goal model and a softgoal model. The functional goal model represents goals and tasks (functions) and the softgoal model represents conditions or criteria that the system should meet (non-functional requirements or quality attributes). So quality attributes are represented as soft-goals and the operationalization of those quality attributes is encoded in the functional goal sub-model as tasks. Both sub-models are AND/OR trees. Priorities are given per each softgoal on a percentile scale to perform the analysis. And correlations are used to represent the links among functional and softgoals. Correlation links have different influence labels (--,-,?,+,++). Those qualitative labels are converted to quantitative values: one value for satisfiability and another for deniability.
3. Overview of quality attribute variability modelling approaches Six modelling methods that address varying quality attributes have been compared: o Goal-based model [11][12] o F-SIG (Feature-softgoal interdependency graph) [16] o COVAMOF [26] o Extended feature model [3][4] o Definition hierarchy [19] o Bayesian Belief Network [28]
Figure 1: Functional goal model, soft-goal model and correlations (figure taken from [11]) An extension of this approach proposes to use this approach in conjunction with the feature model and use cases [12].
52
o
3.2. F-SIG (Feature-softgoal interdependency graph) The main goal of this approach is to provide a framework to record design rationale in the form of interdependencies among variant features and quality attributes. For doing that a new graph is proposed: FSIG, a union of a feature model and a SIG. F-SIG is used. Feature-softgoal interdependency graph [16] is a extension of FORM [18] with concepts of goaloriented analysis [5]. FORM (Feature Oriented Reuse Method) is an extension of FODA (Feature Oriented Domain Analysis) [17], a very well known method to analyze and model a domain that uses a feature model to represent variability. And SIG (Softgoal interdependency graph) is the diagram proposed to model non-functional requirements using softgoals [5]. In F-SIG, explicit and implicit contributions from features to quality attributes are modeled. To express the degree of influence, correlations may also have a label (break:--, hurt:-, unkown: ?, Help: +, Make: ++).
Logical association is used when the influence is fully known and is specified as formal knowledge.
Figure 2: Some examples of dependencies and variation points (taken from [26])
3.4. Extended feature model Benavides et al [3][4] propose to extend feature model to deal with extra-functional features. They propose a notation extending feature models with attributes, characteristics of a feature that can be measured such as availability, cost, latency, bandwidth and relations among attributes. Every feature may have one or more attributes relations taking a range of values in both discrete or continuous domain. And it provides automatic reasoning on those extended feature models using CSP (Constraint Satisfaction Problems).
3.3. COVAMOF COVAMOF (ConIPF Variability Modelling Framework) [26] is a framework for variability modelling in software product families. With this framework is possible to model the variability on all layers of abstraction of the product family (from features to code). This framework use the CVV (COVAMOF Variability View) which encompasses the variability of artefacts on all layer of abstraction of the product family. CVV has two views: Variation Point View and Dependency view. The CVV captures the variability in the product family in term of variation points and dependencies. Quality attributers can be modelled with dependencies [27], a dependency can specify a property that specifies the value of a quality attribute such as performance or memory usage. Association is used to associate variation points and dependencies. There are three association types: o Abstract association means that the variation point influences the dependency values but there is no information about how. o Directional association is used when the influence is not fully known and is not specified in a formal manner but there is some information on how the value depends on its binding.
Figure 3: An example (taken from [3])
3.5. Definition hierarchy Kuusela and Savolainen [19] proposed a definition hierarchy method for requirement engineering in product families. The hierarchy is a logical AND tree and topmost nodes are design objectives: architectural drivers and other quality attributes that the system is supposed to fulfil. The other nodes are design decisions and when an edge is between a design objective and a design decision it shows that this requirement is (partially) satisfied by design decisions. Each node in the definition hierarchy gets a priority that reflects the importance of that node in supporting the intention of its parent.
53
Priorities are product specific; they are used as the mechanism to describe products in the definition hierarchy.
Quality Quality attribute characterization: attributes have vague definitions. In different domains, one quality attribute may not mean exactly the same or different names are used for the same concept. So it is necessary to concretize and make quality attributes more specific. A mechanism for describing and explaining a quality attribute adequately must be provided: A structure where a quality attribute may be explained through refinement among different levels. Optionality: In one product one attribute may be important and in another this attribute not be required. So this attribute is optional in the product line. This may happen at quality attribute level but also at lower level, in the refinements of this quality attribute. For instance, in a quality attribute (performance) that is decomposed into two concerns (“Data latency” and “Transaction throughput”). Those concerns can also be optional or variant. This variability must be represented and not only at product level. It is not enough with specifying this optionality when deriving products. Another example: economy may be optional, for some customers is something to consider but for others is not important. Levels: Different priority levels in quality attributes are need. For example, for one family member the extensibility requirements are extremely high, whereas for others those requirements are at the lowest level. However, quality attributes due to their nature are not easy to quantify, only more concrete concerns (refinement results) may be quantified. It is necessary to provide a way to define different levels (high, medium, low) at quality attribute high level and map those levels to more concrete concerns’ values. Following the previous example: some customers consider economy a high-priority issue whereas others consider it with different degree of importance: quite important, important… Quantitative and qualitative: Indirect variation must be represented with qualitative and quantitative impacts and means must be provided to quantify qualitative influences to be able to do an automatic analysis. Some examples of impacts: o To have different languages impacts positively on usability (qualitative). o To be local application impacts very positively on availability (qualitative). o All features impact on Application Price (quantitative). The price of each feature is known. Group impacts: There are some types of influential relationships that are not addressed in all approaches, for instance, the influence of a group of variants. The
3.6. Bayesian Belief Network Zhang et al. [28] proposed a Bayesian Belief Network (BBN) based approach to quality prediction and assessment for a software product line. The BBN is used to explicitly model the impact of variants (especially design decisions) on system quality attributes. Feature model is used to capture functional requirements and BBN model to capture the impact of functional variants on quality attributes. Quality attributes are represented as nodes in the BBN model. And they are noted with definitions. For instance “High” or “Low”, and those definitions are specific for each domain. (In a specific domain “High” means response time is less or equal to 0.5 ms.) Directed edges are used to relate a design decision or variant to a quality attribute. Conditional probability is used to quantify the conceptual relationships. This probability number reflects domain expert’s belief in how much a given design decision influences quality attributes.
4. Requirements for a quality attribute variability modelling approach Below, we present several requirements that we consider important for modelling quality attribute variability: Modelling and automatic reasoning: To provide a way to represent quality attribute variability in order to analyze and reason about the model. Because if so interesting information is captured, it is very reasonable to use it when deriving or taking other type of decisions. Different reasoning tasks should be interesting: get an approximate value or level for several quality attribute starting from a set of functional requirements, detect impossible configurations starting from a set of functional and quality requirements, detect conflicts among qualities and provide help to performance a trade off analysis... Due to the complexity of this analysis and reasoning, it is very advisable to make it automatic. To achieve automatic reasoning artificial intelligence techniques are need. Three well known problems in the area of automated reasoning are Constraint Satisfaction Problems (CSP), Boolean Satisfiability Problems (SAT) and Binary Decision Diagrams (BDD) [4].
54
impact of two variants together is not always the sum of the individual impacts of those two variants alone. For instance, in some applications the price of some packages that have several features or options together may be cheaper that buying all the features separately.
5.1. Goals Two main goals have been detected in the analyzed approaches: o Modelling or representation: To provide a way to capture and represent varying quality attributes and impacts of functional variants on those quality attributes. o Analysis or reasoning: To provide support for variability analysis and reasoning. Reasoning on variability in a product line requires previous quality attribute variability modelling. For that reason, all the methods surveyed that provide support for reasoning also provide a way to represent quality attribute variability. Although some of the methods are clearly oriented to reasoning, for instance [3]. On the other hand, there are methods that only support the representation of varying qualities but not the reasoning, for instance [16].
5. Comparison of methods An evaluation framework to compare variability modelling approaches that address quality attribute variability has been defined taking into account the quality attribute variability types and the requirements gathered in the previous section (see Table 1). General aspects of the methods are considered: goals, models which are based on, tool support, etc. Reasoning technique is also contemplated, modelling is important but to reason about a model starting from some conditions can be very useful. And of course, how they address variability modelling is also considered: quality attribute variability modelling and functional variability modelling.
5.2. Models Variability representation requires the use of diagrams or models to capture all the information. In the most of the cases, existing models are extended or used in conjunction with other models. The most used model is the feature model. F-SIG, Extended goal-based model [12], Benavides et al’s extended feature model and BBN approach use it. “A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate among systems in a family” [8]. Quality attributes can also fit in the definition of feature. A feature is “a prominent or distinctive uservisible aspect, quality or characteristic of a software system or systems” [17]. However, specifying quality attributes as features is not advisable because quality attributes have vague definitions and feature models does not support the necessary characterization of attributes neither the way to represent the impact of functional variants on quality attributes. In the approaches, feature models are used for representing functional requirements; and they are extended or complemented with other models for representing quality. In order to represent quality, goal-oriented model seems to be appropriate (two of the approaches use it: Goal-based model and F-SIG). Goal-oriented requirements engineering is an approach that deals with quality attributes or non-functional requirements in single-systems [5]. It uses the concept of softgoal and qualitative reasoning to provide a way to
Table 1: Evaluation framework Element Specific goals Models Reasoning technique Case studies Tool support Variability representation Quality attribute variability Optionality
Levels
Impacts
Functional variability
Description Which are the goals of the approach? Which models or diagrams are used? Does the approach use any reasoning technique? Which one? Where has the approach been applied? Does the approach provide tool support? How does the approach propose to model variability? How does the approach represent quality attribute variability? How does the approach represent variability among quality attribute? How does the approach represent different priority in quality attributes? How does the approach represent indirect variation? Qualitatively or quantitatively? Does it allow representing group impacts? How does the approach represent functional variability?
A summary of the results of the comparison are shown in “Appendix: Comparison results”.
55
represent quality attributes more accurately taking into consideration the vague definitions and the soft nature of the quality attributes. Another existing model used by an approach is the Bayesian Belief Model (BBN). It is used to model the impacts of functional variant on quality attributes. New diagrams specially developed for variability representation are also proposed by surveyed approaches: COVAMOF framework and the definition hierarchy which model functional and quality variability.
with low level quality concepts but they do not provide a way to understand a higher level quality attribute and decompose it in related low-level attributes or concerns. Levels and optionality In general the representation of optionality or variability among different quality attributes and different priority levels in quality attributes is supported but only at product level. It is possible to specify that a product requires a determined level of a quality attribute or that does not require an attribute. Priorities, criterions… are used for defining the requirements of a product in order to derive. However, it is not possible to model this variability at product line level. It is not possible to specify that a quality attribute has different degrees in a product line or that some concerns are optional, quality attribute variability is only represented as an effect of functional variants’ influences. The exception may be the BBN method that allows defining levels with a related condition. However, in this approach it is not possible to characterize the attributes so it seems difficult to define these conditions. Impacts or Indirect variation Functional variability can indirectly cause variation in quality requirements. One variant may influence many quality attributes and one quality attribute may be influenced by many variants. All approaches allow that kind of impacts. But it could be useful to represent feature groups that impact on qualities because the impact of a feature group is not always the sum of the impact of each feature alone. Sometimes there are functional variants that potentialize other variants’ impact, for instance if “help” is optional in a product line, its impact on usability is not fix, it depends on the selection of other functional variants where “help” can be useful. Only two approaches take into account group impact (COVAMOF and BBN). The definition of impact can be quantitative or qualitative. Most of the methods that allow defining quantitative relations are useful for defining qualitative impacts because the values give an idea of the direction of the influence. The only one that is specific for quantitative impacts is Benavides et al. because this approach only is applicable for attributes that can be measured. Table 2 presents the surveyed approaches and how those methods fulfil the identified requirements.
5.3. Reasoning technique and tool support Most of the methods use a reasoning technique to make easier the derivation of products. They propose techniques from artificial intelligence: Probabilistic models, CSP-Constraint Satisfaction Problems, rules… The exception is the database and queries that Kuusela and Savolainen [19] propose for getting information and performing analysis. About the tools, most of the methods provide tools that have been developed specifically for those methods. The exception are BBN approach that use a commercial tool for Bayesian networks and F-SIG that uses MS Visio for drawing the models.
5.4. Case studies Most of the approaches apply their methods in theoretical and existing examples but a case study has not been performed. COVAMOF and Definition hierarchy’s approaches are the only ones that have applied their methods in a real product line case. Moreover, COVAMOF is based on more industrial case studies.
5.5. Quality representation
attribute
variability
Quality attributes usually have vague definitions and no clear-cut satisfaction criterion [16] so it is not easy to describe them. One requirement for surveyed approaches is to provide a way to define and characterize a quality attribute. The soft-goal approach is very useful for characterizing quality attributes and the definition hierarchy also but other approaches are not so adequate. They do not provide a structure for characterizing quality attributes: a unique element is used to represent a quality attribute or concern: a node in BBN, a dependency in COVAMOF, a feature attribute in Benavides et al’s approach. They work
56
Table 2: Surveyed approaches and how they address identified requirements Requirement Approach Goal-based model F-SIG COVAMOF Extended FM Definition Hierarchy BBN
Automatic reasoning Yes No Yes Yes No Yes
QA characterization Yes Yes No No Yes No
Optionality at PL level No No No No More or less No
Degrees No No No No No More or less
Quantitative and Qualitative Yes No Yes No Yes Yes
Group impacts No No Yes No No Yes
techniques from artificial intelligence: Probabilistic models, CSP-Constraint Satisfaction Problems… seem to be very useful. These techniques could help to find the most adequate configuration satisfying some conditions (product requirements). Tool support is very important to facilitate the derivation. Tools should support not only quality attribute variability modelling and reasoning but also functional requirement variability. So existing tools for functional variability should be taken into account and extend them or integrate the new tools with the existing ones. Most of the surveyed methods have not been applied in real industrial product lines. As a conclusion a new approach or an extension of an existing approach could be interesting to address all the identified requirements for modelling varying quality attributes.
6. Related work There are also other methods that are related, for instance methods for architecture evaluation in product lines [9]: RAP, HoPLAA… The Reliability and Availability Prediction (RAP) method [15], part of QADA methodology [20][23], is used for predicting reliability and availability at the architecture level in a product line. This method captures reliability and availability requirements and maps them to functionality. And it uses a Soft-goal interdependency graph (SIG) for selecting the most adequate architectural style for the product line. HoPLAA (Holistic Product Line Architecture Assessment) [24] is an adaptation of ATAM (Architecture Trade-off Analysis Method) [6] for product lines. This method introduces variability in the quality attribute utility tree used for evaluation. For single-systems there are also approaches for modelling quality aspects. For instance, the UML QoS profile [25] for modelling quality aspects and fault tolerance characteristics.
Acknowledgements This work was partially supported by The Basque Government, department of education, universities and research. Leire Etxeberria enjoys a doctoral grant of the researchers’ formation program.
7. Conclusions This study has compared six approaches for modelling quality attribute variability. And no approach meets all the identified requirements. The less fulfilled requirements are optionality at product line level and different priority levels in quality attributes. Optionality at PL level is only addressed more or less by Kuusela and Savolainen’s approach (definition hierarchy) in which quality attribute variability is represented at product level but with several representative products. In other approaches optionality is represented through priorities for each product, so there is not a global view of this optionality, it is only represented at product level. And different priority levels at product line level are only addressed at Zhang et al’s work (BBN approach). A reasoning technique is necessary to perform a complete analysis of the product line. Reasoning
8. References [1] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison Wesley, 1998 [2] Benavides, D., Trinidad, P., Ruiz-Cortés, A., Using Constraint Programming to Reason on Feature Models, The Seventeenth International Conference on Software Engineering and Knowledge Engineering (SEKE'05) [3] Benavides, D., Trinidad, P., Ruiz-Cortés, A., Automated Reasoning on Feature Models, Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05), 2005, pp. 491 – 503 [4] Benavides, D., Segura, S., Trinidad, P., Ruiz-Cortés, A first step towards a framework for the automated analysis of feature models, Managing Variability for Software Product Lines: Working With Variability Mechanisms workshop (SPLC'06), 2006
57
conference on Quality of Software Architecture QoSA, 2006 [22] Mylopoulos, J., Chung, L., Yu, E. and Nixon, B., Representing and Using Non-functional Requirements: A Process-Oriented Approach, IEEE Transactions on Software Engineering, 18 (9), June 1992, pp. 483-497 [23] Niemelä, E., Architecture Centric Software Family Engineering, Product Family Engineering Seminar Product Family Engineering Seminar, 2005 [24] Olumofin, F.G., Misic, V.B.: Extending the ATAM Architecture Evaluation to Product Line Architectures, 5th Working IEEE/IFIP Conference on Software Architecture, WICSA 2005, IEEE Computer Society, 2005 [25] OMG Adopted Specification, UML TM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, ptc/2004-06-01, 2004 [26] Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J., COVAMOF: A Framework for Modelling Variability in Software Product Families, Proceedings of the Third Software Product Line Conference (SPLC 2004), Springer Verlag, (LNCS 3154), pp. 197-213, August (2004) [27] Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J., Modelling Dependencies in Product Families with COVAMOF, Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS'06), 2006, pp. 299-307 [28] Zhang, H., Jarzabek, S., Yang, B., Quality Prediction and Assessment for Product Lines, Proc. of the 15th International Conference On Advanced Information Systems Engineering (CAiSE'03), 2003, LNCS 2681, Springer-Verlag, pp. 681-695
[5] Chung, L., Nixon, B., Yu, E. and Mylopoulos, J., Nonfunctional Requirements in Software Engineering, Kluwer Academic Publishers, 2000 [6] Clements, P., Kazman, R., Klein, M., Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2001 [7] Clements, P., Northrop, L., Software Product Lines: Practices and Patterns, Addison Wesley (2002) [8] Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000 [9] Etxeberria, L., Sagardui, G.: Product-Line Architectures: New Issues for Evaluation, 9th International Software Product Line Conference SPLC-EUROPE, 2005, pp. 174-185 [10] Giorgini, P., Mylopoulos, J., Nicchiarelli, E., and Sebastián, R., Reasoning with goal models”, Proceedings of ER’02, 2002 [11] González-Baixauli, B., Leite, J., Mylopoulos, J., Visual Variability Analysis for Goal Models, Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), 2004, pp. 198 – 207 [12] González-Baixauli, B., Laguna, M.A., Crespo, Y., Product Line Requirements based on Goals, Features and Use cases, International Workshop on Requirements Reuse in System Family Engineering (IWREQFAM), 2004, pp.4-7 [13] Halmans, G., Pohl, K., Communicating the variability of a software-product family to customers, Journal on Software and Systems Modeling (2003)2:15 –36 [14] IEEE Standard 1061-1992. Standard for a Software Quality Metrics Methodology. New York: Institute of Electrical and Electronics Engineers, 1992 [15] Immonen, A., A Method for Predicting Reliability and Availability at the Architecture Level, in Ed.: Timo Käkölä, T., Dueñas, J.C., Software Product Lines, Research Issues in Engineering and Management, Springer, 2006 [16] Jarzabek, S., Yang, B., Yoeun, S., Addressing quality attributes in domain analysis for product lines, IEE Proceedings Software., Vol. 153, No. 2, April 2006 [17] Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E, Spencer Peterson, A., Feature-Oriented Domain Analysis (FODA) Feasibility Study, CMU/SEI-90-TR21, Technical Report, 1990 [18] Kang, K.C., Kim, S., Lee, J., Shin, E., and Huh, M., FORM: a feature-oriented reuse method with domainspecific reference architectures, Annals of Software Engineering, 5, 1998, pp. 143-168 [19] Kuusela, J., Savolainen, J., Requirements Engineering for Product Families, Proceedings of the 22nd international conference on Software Engineering (ICSE), 2000, pp. 61 – 69 [20] Matinlassi, M., Niemelä, E., Dobrica, L., Qualitydriven architecture design and quality analysis method: A revolutionary initiation approach to a product line architecture, VTT Publications, 2002 [21] Myllärniemi, V., Männistö, T., Raatikainen, M., Quality Attribute Variability within a Software Product Family Architecture, Second International
58
F-SIG [16]
Explicit representation of the variability in software product families
Feature model extended to deal with extra-functional features (quality features)
Provide automatic reasoning on SPL dealing with extrafunctional features
Definition hierarchy
Requirements capturing, analysis and documentation for product families
Definition hierarchy [19]
Feature model and BBN model
Represent the impact of variants on quality attributes
BBN [28]
Extended FM [3]
CVV (COVAMOF Variability View)
CSP-Constraint Satisfaction Problems
COVAMOF [26]
Rules and inference
Appendix: Comparison results Goal-based model [11]
Method Specific goals
Represent requirements variants in a product line and provide support for variability analysis
Element
Models
Goal model: functional goal sub-model and softgoal sub-model
Probabilistic model
Priorities are given per each softgoal Priorities are given per each softgoal Correlations among functional goals and softgoals.
59
A framework to record design rationale in the form of interdependencies among variant features and quality attributes F-SIG (FeatureSoftgoal interdependency graph): FORM’s feature model + SIG (Softgoal interdependency graph) No
Reasoning technique
Nodes in the BBN model No
Case studies
A set of tools to manipulate information stored in a DB Design objectives in topmost nodes Priorities
Annotations
Probabilistic reasoning: Bayesian belief network Example with CAD (Computer Aided Dispatch) system PL
A database and tools to allow complex queries A case study of a weather station product family
Dependencies
Feature’s attribute relations No
Priorities
Two examples: Home Integration Systems (HIS) and JAMES PL
No
Criterions
Priorities and tree
Directed edge between a design decision or variant and a quality attribute. Both
Example with CAD (Computer Aided Dispatch) system PL
Softgoals
No
Features have attribute with quantitative value
Both
Yes
MS Visio
No
Association among variation points and dependencies
Quantitative
No
Feature model
A commercial tool for BBN: Hugin tool is used
No
Both
No
A prototype of a holistic Feature Solver
Explicit and implicit contributions from features to quality attributes Qualitative
Yes
Feature model
Case study: Intrada product family. There are also previous case studies COVAMOF-VS: Tool Suite for Microsoft Visual Studio
Both
No
Variation points
A tool implemented in Excel with visual basic components
No
Feature model
Softgoals
Functional goal submodel
Design decisions in the definition hierarchy
A published example giving the emphasis on variability
Functional variability
Qualitative or quantitative Group impacts
Impacts
Levels
Optionality
Quality attribute variability
Tool support
Variability representation
60
KumbangSec: An Approach for Modelling Functional and Security Variability in Software Architectures Varvana Myll¨arniemi, Mikko Raatikainen, Tomi M¨annist¨o Helsinki University of Technology Software Business and Engineering Institute P.O. Box 9210, 02015 TKK, Finland {varvana.myllarniemi, mikko.raatikainen, tomi.mannisto}@tkk.fi Abstract Software products often need to vary in terms of functionality, but also in terms of quality attributes. We describe KumbangSec, which in an approach for modelling functional and security variability applying different architectural viewpoints. KumbangSec builds on an existing variability modelling method, Kumbang, by extending it with security engineering concepts. KumbangSec consists of a conceptualisation and a language implementing the conceptualisation. The semantics for the conceptualisation has been described using natural language; the syntax for the language has been defined in a grammar. KumbangSec can be supported with a configurator, which is an intelligent tool supporting derivation of products that each satisfy specific and different functional and security requirements. Such a tool, KumbangSec configurator, is currently being developed.
1
Introduction
Quality attributes, such as performance, security and availability, are important in many industrial software products. Quality attribute has been defined as a feature or characteristic that affects an item’s quality [16]. Many quality attributes are architectural, meaning that the architecture of the software is critical to their realisation, and these qualities should be designed in and evaluated at the architectural level [4]. Today, many software product companies have to face the diversity of customer needs. Instead of developing a single product as a compromise of these needs, many companies offer several software products with slightly varying capabilities. Variability is the ability of a system to be efficiently extended, changed, customised or configured for use in a particular context [36]. Feature models [19] are one
of the first widely known approaches to express variability. Recently, several other approaches to express variability by modelling have emerged. Modelling methods such as orthogonal variability modelling [27] and COVAMOF [33] augment other models of software to express variability. These methods can be used at any level of modelling: at the requirements, architecture or detailed design level. In contrast, Koala [37] and its derivate Koalish [2] are modelling methods that contain specific constructs for variability and address only architectural level modelling. Finally, despite the lack of explicit constructs for variability, existing modelling methods such as UML are used to express variability [11]. However, research on variability rarely addresses quality attributes. In particular, most variability modelling approaches do not have explicit constructs for quality attributes. Despite this, there are industrial cases in which the products in a product family have different quality attribute requirements; such examples of varying qualities include security [10] and performance [25]. Thus quality attribute variability needs to be realised [12, 22, 26, 24]. Since software architecture is critical to the realisation of many quality attributes, modelling quality attribute variability is relevant at the architectural level. Further, the fact that software architecture is a key asset in realising software product family variability [6] stresses the importance of addressing quality attribute variability at the architectural level. In this paper, we describe KumbangSec, which is an approach for modelling functional and security variability in software architectures. KumbangSec is built on the concepts of product configuration, software architectures, feature modelling, and security engineering. To address functional and security concerns, KumbangSec has been organised into four architectural viewpoints [15]: functional view, component view, deployment view and security policy view. KumbangSec approach consists of a conceptualisation
61
and a language. The language has been unambiguously specified in such a way that KumbangSec models can be configured with a configurator. A configurator is an intelligent tool that enables derivation of products satisfying specified functional and security requirements; such a configurator tool is currently being developed. The rest of the paper is organised as follows. Firstly, Section 2 outlines the background for KumbangSec. Thereafter, Section 3 introduces KumbangSec. Section 4 discusses the validity of KumbangSec. Finally, Section 5 draws conclusions and discusses future work.
2
Previous work
This section discusses the research on which KumbangSec is based.
2.1
Figure 1. ISO/IEC 15408 security concepts [17]
Quality attributes in software architectures
According to [15], software architecture is the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. State of the practice is to model and document software architectures using different viewpoints and views as described in IEEE Standard [15]. A view is a representation of a whole system from the perspective of a related set of concerns. Example viewpoints include module view that describes the decomposition of code units, and deployment view that describes how software is allocated to physical devices. Typically, certain viewpoints are used to answer concerns related to certain quality attributes; e.g. process view is often used when addressing performance concerns. The goal of KumbangSec is to enable tool-supported derivation of products that satisfy varying quality attribute requirements. In order to target this goal, the approach should include a mechanism for ensuring that quality attribute requirements are met. This can be done in two ways. Firstly, the approach can apply well-known quality attribute solutions, such as patterns [31] or tactics [4]. Secondly, the approach can evaluate quality attributes from the architectural models. When applications are built by reusing existing components, as is the case with configurable component-based products, the task of evaluating quality attributes from the architectural models can utilise information about the characteristics of components. The problem of predictable assembly [7] is as follows: given a set of components with know property p, and the composition of these components, how can system-wide property P be evaluated? Several approaches have been presented, e.g., for static memory consumption [9], performance [5], and reliability [28]. How-
ever, some quality attributes, such as security or safety, are more difficult in the sense that their prediction requires more information [21]. A prediction mechanism for security has also been proposed [30]. However, a problem with security is that it is not trivial to come up with a quantitative, composable metric that captures security concepts well.
2.2
Software security
According to ISO/IEC 9126 [18], security is the capability of the software to protect information and data so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them. That is, security is a composite of confidentiality, integrity and availability [3]. Confidentially means absence of unauthorised disclosure of information; integrity means absence of unauthorised system alternations [3]; and availability means readiness for correct service for authorised actions [3]. Figure 1 illustrates high-level security concepts of ISO/IEC 15408 [17]. Security is concerned with the protection of assets from threats [17]; assets are defined to be information or resources to be protected with countermeasures [17]. A threat exploits vulnerability in the software. In order to reduce vulnerabilities, countermeasures are imposed in the software (see Figure 1). The definition of ISO/IEC 9126 [18] makes a distinction between authorised and unauthorised persons or systems; these parties are termed as principals (e.g.[29, 20]). In order to specify authorisation, an access policy (also called security policy) should be defined. In the security perpective tactics by Rozanki and Woods [29], access policy is constructed by first identifying assets and principals, classifying them, and then mapping principal classes to asset
62
classes. Principals can also be software systems; in fact, some studies on security of component-based software treat components as principals (e.g.[20]). As noted in ISO/IEC 9126 [18], security also applies to data in transmission. In order to ensure that security policies are not violated when components transmit information with each other, Herrmann [13] has proposed an approach for analysing information flow in component-structured architectures by labeling pieces of information with access policies. The idea is to prevent information from flowing to unauthorised principals. The concepts illustrated in Figure 1 are to some extent reflected in the conceptual model of reference architectures for software product lines with varying security requirements [10]. The model consists of three submodels [10]. Security submodel deals with risk assessment; core concepts include threat, asset, vulnerability, unwanted incident and risk. An architecture submodel incorporates architectural solutions, that is, countermeasures that promise to address security requirements. A decision support submodel supports security requirements through scenarios.
2.3
Kumbang
Variability has been studied in the domain of traditional products, i.e. mechanical and electrical ones. This domain of research is called product configuration, and it pertains to modifying the general design of a product in prescribed ways to produce product individuals that match the specific needs of customers [35]. The results include a number of conceptualisations [34], languages and tools. Recently, these same concepts have been applied to software products [1] [14]. Kumbang [1] is a domain ontology for modelling the variability in software product families. It includes concepts for modelling variability both from an architectural and feature point of view. From architectural point of view, Kumbang builds on Koala [37], which is an architecture description language developed and used in Philips. More specifically, the modelling concepts include components and features with compositional structure, attributes, the interfaces of components and connections between these, and constraints. Hence, Kumbang enables modelling variability in parallel from an architectural and feature point of view as well as describing how features are implemented by the architectural elements. The semantics of Kumbang is rigorously described using natural language and a UML profile. A language based on the Kumbang ontology likewise called Kumbang has been defined. Kumbang has been provided with formal semantics by defining and implementing a translation from Kumbang to WCRL (Weight Constraint Rule Language) [32], a general-purpose knowledge representation language with
formal semantics. Kumbang addresses only functional aspects of configurable software products. This means that using Kumbang, it is possible to derive configurations in which the component architecture satisfies functional requirements, which are specified through features. It is possible to model quality attribute variability with features [14]. However, Kumbang does not provide explicit constructs for modelling quality attributes, which makes it more difficult to address quality attribute variability.
3
KumbangSec
In this section, we describe KumbangSec that builds on the concepts outlined in Section 2. KumbangSec is an approach that includes a conceptualisation and a language for modelling component-based products that satisfy varying functional and security requirements. The ultimate goal of KumbangSec is to provide intelligent tool support for deriving these products from family models. Firstly, Section 3.1 gives an overview of the approach. Thereafter, Section 3.2 describes the conceptualisation KumbangSec is based on, and how this conceptualisation makes a distinction between instances and types. Finally, Section 3.3 describes the language that implements the conceptualisation.
3.1
Overview of KumbangSec approach
3.1.1
Basic ideas
KumbangSec is an approach for modelling componentbased architectures from functional, compositional and security point of view. KumbangSec builds on Kumbang language [1] by extending it with concepts from security engineering. KumbangSec is organised to reflect the idea of separate architectural viewpoints discussed in IEEE 1471-2000 standard [15]. The viewpoints in KumbangSec are feature viewpoint, component viewpoint, deployment viewpoint, and security policy viewpoint. Features mean user visible characteristics of a system. Components refer to the reused software entities that are connected to form an application. Deployment shows the software components operating on physical devices and networks; this information is needed in order to analyse security threats. Security policy specifies the threats and applied countermeasures; countermeasures are realised within the component architecture. The viewpoints can be linked with constraints in such a way that a change in one viewpoint is reflected to other viewpoints as well. The foundation of Kumbang, and therefore also of KumbangSec, lies on the dichotomy between types and instances, and between a configuration model and configuration, respectively. The situation is illustrated in Figure 2.
63
Figure 2. Metamodel of KumbangSec configuration models, configurations, types and instances.
A configuration describes one particular software product variant, while a configuration model describes the rules and the structure upon which valid configurations can be constructed. A configuration contains instances of types defined in the configuration model. Types in the configuration model contain variability, while instances in the configuration do not; a configuration has been resolved from all variability. This dichotomy is similar to development for reuse and development with reuse; domain and application engineering in family based development; and types and instances in object oriented programming. A corollary of this position is that we need to capture a configuration model only, since a configuration can be derived from the configuration model by selecting one variant for each variation point. Therefore, KumbangSec provides a language that can be used for describing configuration models. An essential aspect of this language is that it can be translated to a form that enables tool support for deriving configurations from configuration models. 3.1.2
Security in KumbangSec
In order to address security, KumbangSec conceptualises assets, principals, threats and countermeasures. In component-based systems and component models, information is not usually explicitly modelled, but is encapsulated in the components and their connections. In order to support explicit reasoning about security, KumbangSec contains concepts for modelling assets. An asset in KumbangSec is information that needs to be protected. However, only information that is relevant to security reasoning needs to be modelled. Since the number of different assets can be considerable, it is possible to classify assets that have similar security requirements into groups; such a group is called an asset class. Instead of considering stakeholders as principals, KumbangSec adopts the approach by Khan and Han [20] to treat software components as principals. However, components represent different stakeholders through their origin or role in the system. In a similar fashion to assets, principals can be classified into principal classes.
Typically, threats and countermeasures that are relevant to an application are very much dependant on the domain at hand. As a consequence, it is difficult to come up with a fixed set of threats and countermeasures that are suitable to all applications. Therefore, threats and countermeasures can be specified in the configuration model to match security requirements at hand. Threats and countermeasures are specified in a security policy. One threat can be addressed by several countermeasures. A countermeasure represents a constraint that is implemented by the component and deployment architecture. In order to achieve finer granularity, one countermeasure can be selected individually for different elements; for example, it is possible to specify for each network which kind of encryption to use. To exemplify how threats and countermeasures can be represented, we have modelled three threats to confidentiality and integrity, and corresponding countermeasures to them. Firstly, information should not flow to unauthorised components; this threat is addressed by preventing such connections between components. Secondly, malicious components may try to access or modify information in the memory; this can be prevented by instantiating components into separate, restricted processes. Thirdly, connections that transmit assets over networks are vulnerable to eavesdropping; this can be addressed by encrypting such connections. 3.1.3
Variability in KumbangSec
As is illustrated in Figure 2, configuration models describe the types from which instances in configurations are instantiated. Therefore, configuration models specify variability, whereas all variability has been bound in configurations. There are four kinds of variability in KumbangSec. Firstly, functional variability is specified through features. This variability is achieved through subfeature structures, in which the number and types of subfeatures can vary. Further variability can be achieved through attributes. Secondly, security variability is specified through security policy. Threats cannot be varied, but for each threat, the desired countermeasures (if any) can be varied. Thirdly, architectural variability is specified through component and interface structures. For each component, the number and types of contained components can vary. Further, interfaces can be optional, and interfaces can be bound in different ways. Finally, variability can be achieved by characterising components with attributes. Finally, it is possible to vary deployment by varying the number and types of devices that are deployed to networks. For further discussion about variability in types, please refer to Section 3.2.2.
64
Figure 4. An example how components are deployed to devices and networks
tree; a configuration contains exactly one root feature. Further, features can be characterised with attributes: a feature can be attached with an attribute that is a name/value pair.
Figure 3. KumbangSec instance metamodel
3.2
KumbangSec conceptualisation
The following describes the conceptualisation upon which KumbangSec is based. We first describe the concepts that are reflected in the configuration, that is, KumbangSec instances. Thereafter, we discuss how KumbangSec types are used to characterise instances in the configuration model. 3.2.1
KumbangSec instances
A configuration in KumbangSec consists of instances that are features, components, interfaces, bindings, assets, networks, devices, threats, and countermeasures. Figure 3 shows the metamodel of these instances. A configuration provides a set of features, and adheres to a security policy. Components provide or require interfaces that can be bound together, and can form structures in terms of other components as parts. Components are deployed to devices, which reside on networks. Components handle and store assets and transfer them through interfaces. Feature instances The basic representation of a functional requirement in KumbangSec configuration is a feature. Since the number of features in a typical application can be considerable, features can be composed into hierarchies. Thus there can be is-subfeature-of relation between two features in a configuration. Feature hierarchies form a
Component and interface instances The basic building block of KumbangSec component architecture is a component. The components in KumbangSec configuration are conceptually much akin to Koala components. However, any component technology with similar concepts can be used for implementing KumbangSec components. A component can specify a number of interfaces, which are sets of operation specifications. The interfaces that a component specifies have a direction, i.e., interfaces are either provided or required. A provided interface offers its operations for other components to use, while a required interface states that the component needs other components to provide the operations. Interfaces can be bound with each other according to the rules specified in [37]. Components can be organised into hierarchies. A component can contain other components; thus components are in a compositional relation with each other, and this hierarchy forms a tree. Also, components may be characterised with attributes. An attribute is a name/value pair that can be used, e.g., for parameterisation of the component. Device and network instances Software components in the configuration may be deployed to separate physical devices; these devices are deployed in a network. Figure 4 illustrates an example situation of deployment. A network can contain several different devices, but devices cannot contain other devices. Networks can form hierarchies through subnets similarly as, e.g., corporate intranet is a part or subnet of Internet. A configuration that has more than one device is distributed. A binding that crosses device borders is a distributed binding, which represents communication over network.
65
Asset, threat and countermeasure instances Assets are attached to components in three different ways. Firstly, a component may handle an asset, which means it stores it in random access memory. Secondly, a component may also store the asset in a permanent storage, for example to a file on the disk. Thirdly, a component may transmit an asset to another component via its interfaces. Security policy specifies how threats are addressed with countermeasures. Each configuration has one security policy, which lists a number of threats. For each threat, a number of countermeasures can be selected to address the threat. In the most simple case, a countermeasure selection is either applied or not applied; in the former case, the countermeasure is enforced in the architecture, while in the latter case not. In general, a countermeasure can be characterised with a selection, which acts as a parameter for implementing the countermeasure in the architecture. For example, a countermeasure that encrypts communication may be attached with a selection SSL 2.0, RSA 128 bit encryption, which specifies the encryption protocol to use. 3.2.2
KumbangSec types
As is illustrated in Figure 2, types are the elements in the configuration models, from which instances in the configurations are instantiated. Figure 5 illustrates the metamodel of KumbangSec types. All instances in Figure 3 have a respective type, and vice versa. However, there are two exceptions to this rule. Firstly, binding instances are defined solely upon their connected interface instances, and thus they need no information from the types. Secondly, principal classes and asset classes do not have respective instances, since they are already instantiated by component instances and asset instances, respectively. A distinctive difference to the metamodel of instances (Figure 3) is the use of definitions. A definition separates typing from the structure, and acts as a point of variability. For example, a part definition specified by a component type C states what kind of components a component instantiated from C can contain. As an example, a part definition named database in component type Server may specify that possible component types are Oracle and mySQL and that cardinality is (0, 1). This means that a component instance of type Server may contain zero or one Oracle or mySQL component instances. Similar compositional structures can be defined between features, or between networks and devices or devices and components. Another example is the use of attribute definitions. Attribute value types specify the value range of attributes; for example, attribute value type Boolean may specify value range (yes, no). Attribute value types are attached to feature and component types through attribute definitions; for
Figure 5. KumbangSec type metamodel
66
example, feature type Map may define an attribute definition zoomable of type Boolean. To summarise, variability may occur in the compositional structure of networks, features, and components; in attributes; and in what interfaces components contain and which bindings between interfaces exist. The variability in compositional structures is specified using part definitions: the number and type of parts an entity has may vary. Features and components can be parameterised using attributes. Similarly, interfaces may be defined optional and be of different types. Finally, security policies can vary how countermeasures are applied.
3.3
KumbangSec language
In order to use KumbangSec concepts for modelling product families, a language that captures the conceptualisation described in Section 3.2 has been developed. The language has been constructed in such a way that it enables development of tool support. Since KumbangSec configurations are derived from KumbangSec configuration models (Figure 2), only a language for specifying configuration models is required. The language represents KumbangSec types (see metamodel in Figure 5). KumbangSec language is specified using XML. KumbangSec grammar has been described as an XML schema, whereas the configuration models are XML instance documents from the schema. XML was chosen due to its widespread use; for example, a number of parsers and editors are available for XML. The XML schema that represents KumbangSec grammar has been specified. Each definition and each type in KumbangSec type metamodel (Figure 5) has its own XML schema data type in the grammar. For example, the XML schema definition for ComponentType is illustrated in Figure 6(a). This snippet states that each component type has a name, a principal class, defines any number of interfaces, any number of component parts, any number of attributes and any number of assets. Finally, a component type can specify constraints on its elements. An example of the corresponding component type specification is shown in Figure 6(b). It specifies a component type named ServerMain that belongs to principal class InHouse. Further, the component type contains two interfaces, named TransmitInterface and StorageInterface, and specifies that is handles an asset nodeLocation belonging to asset class Location. A component instance instantiated from type ServerMain is visualised in the lower part of Figure 7. In order to give formal semantics to KumbangSec, KumbangSec has been provided with a translation to WCRL (Weight Constraint Rule Language) [32]. WCRL is a form
of logic programming, using which one can specify a set of atoms, statements concerning atoms and rules that extend these statements [32]. Further, this translation makes it possible to utilise smodels [32] inference engine to automatically verify whether the configuration matches the rules of the configuration model. The translation to WCRL utilises the fact a translation from Kumbang to WCRL has already been defined [1]. Therefore, KumbangSec is provided with the translation by first translating KumbangSec to Kumbang, and then using the existing translation to WCRL. The translation between KumbangSec and Kumbang treats assets, devices and networks as special kind of components, and policies as special kind of features. Figure 6(c) illustrates part of the WCRL that has been translated from the component specification in Figure 6(b). The first line specifies that component of type ServerMain is an InHouse component. The second and the third line specify the two interfaces this component has. The fourth line specifies that this component defines an asset named nodeLocation.
4
Evaluation
In this section, the validity of KumbangSec is evaluated from the following viewpoints. How well does KumbangSec address the problem; are the conceptualisation and language sound; and can KumbangSec be applied in practice, integrated with component implementation technologies and supported with tools? Addressing the problem. The aim of KumbangSec is to study how security variability and functional variability can be modelled from architecture point of view. To target this aim, several existing approaches are integrated into one. The novelty of KumbangSec is combining existing concepts to model variability, while the concepts themselves are based on existing studies. Therefore, the soundness of KumbangSec concepts can be argued from these existing studies. For functional and architectural variability, KumbangSec is based on Kumbang, which in turn is based on feature modelling, Koala, and traditional product configuration concepts. For security variability, KumbangSec extends Kumbang with established security concepts that underlie many studies, including ISO/IEC standard 15408 [17] and security model presented in [10]. However, it is yet unknown how well this combination of concepts addresses the problem. For example, it is unknown whether explicit concepts for risks or vulnerabilities should be included, or how well the conceptualisation supports definition of different kinds of threats and countermeasures.
67
Figure 6. Example translations from a weather station network configuration model. (a) A snippet from the XML schema that defines how component types are specified. (b) An example component type specification in a configuration model. (c) Few lines of the WCRL that is produced from the component type specification.
Figure 7. A screenshot of KumbangSec configurator under development (some inconsistencies with current conceptualisation may occur)
68
Soundness of conceptualisation and language. To address the problem of modelling functional and security variability, KumbangSec conceptualisation has been defined. The concepts and their relations have been specified using natural language and metamodels. Further, the separation between instances and types has been specified. To implement the conceptualisation, KumbangSec language has been defined. The semantics of KumbangSec language follows the semantics of KumbangSec conceptualisation. The syntax of the language has been described using an XML schema, which validates that the language can be captured with a grammar. Moreover, using the grammar, it has been possible to parse XML instance documents that represent KumbangSec configuration models. Further, KumbangSec has been given a semantics by providing a translation to WCRL. This validates that the approach can be subjected to automated reasoning. Practical feasibility. KumbangSec has been used to model two small configurable products. Firstly, we have modelled a weather station network that is loosely based on a real software product family. Secondly, we are currently modelling a map viewer application for Nokia 770 Internet Tablet. This application is currently being developed to demonstrate the approach. Hence, it has been shown that it is possible to model products using KumbangSec. However, the limitation to this validity is that no industrial products have been modelled. Further, there is no general knowledge on how easily KumbangSec constructs can be used for capturing product characteristics. Further studies on KumbangSec applicability are therefore required. Integration with component implementation technology. The scope of KumbangSec is high-level variability modelling. That is, KumbangSec is not limited to any particular component implementation technology, but it can be integrated with any approach that is compatible with the conceptualisation, and is able to enforce the specified countermeasures. At the moment, we are integrating KumbangSec with a component technology developed within the research project. Tool support. Finally, the validity of the approach can be demonstrated by building a configurator tool to support derivation of products based on KumbangSec configuration models. We are currently developing KumbangSec configurator by extending previously developed Kumbang configurator [23]. The configurator utilises smodels [32] inference engine for implementing the configuration reasoning in an efficient manner. Further, it is being developed in Java programming language on top of Eclipse platform [8].
A preliminary screenshot of KumbangSec configurator is illustrated in Figure 7. The current results seem to indicate the feasibility of constructing such a configurator.
5
Conclusions
We have presented KumbangSec, which is an approach for modelling functional and security variability in software architectures. To address functional and security concerns, KumbangSec has been organised into functional view, component view, deployment view and security policy view. KumbangSec approach consists of a conceptualisation and a language. They have been constructed in such a way that they can be supported with a configurator, which is an intelligent tool that enables derivation of products satisfying specified functional and security requirements. However, the work is still in progress. We are working on developing a configurator tool that supports derivation by extending existing Kumbang configurator. Further, we are validating the approach by modelling product families or configurable products with KumbangSec language. There are several directions to which this approach can be extended. Firstly, KumbangSec assets are considered to be information. However, it is possible that also resources or operations could be treated as assets that need protection. We seek to extend the concept of asset to cover also these, e.g., by classifying interfaces in components according to asset classes. Secondly, more threats and countermeasures should be modelled to study how the conceptualisation can be used to capture different kinds of security characteristics. Finally, different aspects of quality may require different concepts and viewpoints. It has proven to be laborous to extend existing languages with new concepts in such a way that existing tools can be reused efficiently. Therefore, we are currently working on a meta-language, using which concrete languages can be specified; corresponding configurator tool implementation can be generated from the specification.
Acknowlegments This research is being carried out in participation of Nokia within Trust4All ITEA project. The authors acknowledge Nokia and all other participants of Trust4All project who have provided feedback and comments on this work.
References [1] T. Asikainen, T. M¨annist¨o, and T. Soininen. Kumbang: A domain ontology for modelling variability in software prod-
69
[2]
[3]
[4] [5]
[6] [7]
[8] [9]
[10]
[11]
[12]
[13]
[14]
[15] [16] [17]
[18] [19]
uct families. Advanced engineering informatics journal, Accepted, 2007. T. Asikainen, T. Soininen, and T. M¨annist¨o. A Koala-based approach for modelling and deploying configurable software product families. In Proc. of Workshop on Product Family Engineering, 2003. A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004. L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley, 2nd edition, 2003. E. Bondarev, M. R. V. Chaudron, and P. H. N. de With. A process for resolving performance trade-offs in componentbased architectures. In Proceedings of International Symposium on Component-Based Software Engineering, 2006. P. Clements and L. Northrop. Software Product Lines— Practices and Patterns. Addison-Wesley, 2001. I. Crnkovic, H. Schmidt, J. Stafford, and K. Wallnau. Anatomy of a reseach project in predictable assembly. In Proc. of 5th Workshop on Component-Based Software Engineering, 2002. Eclipse, http://www.eclipse.org/. E. Eskenazi, A. Fioukov, D. Hammer, and M. Chaudron. Estimation of static memory consumption for systems built from source code components. In Proceedings of the 9th IEEE Conference and Workshops on Engineering of Computer-Based Systems, 2002. T. E. Fægri and S. Hallsteinsen. A software product line reference architecture for security. In T. K¨ak¨ol¨a and J. C. Due˜nas, editors, Software Product Lines—Research Issues in Engineering and Management. Springer, 2006. H. Gomaa. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley, 2004. S. Hallsteinsen, T. E. Fægri, and M. Syrstad. Patterns in product family architecture design. In Proc. of Workshop on Product Family Engineering, 2003. P. Herrmann. Information flow analysis of componentstructured applications. In Proceedings 17th Annual Computer Security Applications Conference (ACSAC 2001), 2001. L. Hotz, K. Wolter, T. Krebs, J. Nijhuis, S. Deelstra, M. Sinnema, and J. MacGregor. Configuration in Industrial Product Families—The ConIPF Methodology. IOS Press, 2006. IEEE Std 1471-2000. IEEE recommended practice for architectural description of software-intensive systems, 2000. IEEE Std 610.12-1990. IEEE standard glossary of software engineering terminology, 1990. ISO/IEC 15408-1. Information technology—security techniques—evaluation criteria for IT security—part 1: Introduction and general model, 1999. ISO/IEC 9126-1. Software engineering—product quality— part 1: Quality model, 2001. K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, ADA 235785, Software Engineering Institute, 1990.
[20] K. Khan and J. Han. Composing security-aware software. IEEE Software, 19(1):34–41, 2002. [21] M. Larsson. Predicting Quality Attributes in Componentbased Software Systems. PhD thesis, M¨alardalen University, 2004. [22] M. Matinlassi. Quality-driven software architecture model transformation. In Proc. of Working IEEE/IFIP Conference on Software Architecture, 2005. [23] V. Myll¨arniemi, T. Asikainen, T. M¨annist¨o, and T. Soininen. Kumbang configurator—a configuration tool for software product families. In IJCAI-05 Workshop on Configuration, 2005. [24] V. Myll¨arniemi, T. M¨annist¨o, and M. Raatikainen. Quality attribute variability within a software product family architecture. In Short paper in Conference on the Quality of Software Architectures (QoSA), 2006. [25] V. Myll¨arniemi, M. Raatikainen, and T. M¨annist¨o. Interorganisational approach in rapid software product family development—a case study. In Proc. of International Conference on Software Reuse (ICSR), 2006. [26] V. Olumofin, F.G.; Misic. Extending the ATAM architecture evaluation to product line architectures. In Proc. of Working IEEE/IFIP Conference on Software Architecture, 2005. [27] K. Pohl, G. B¨ockle, and F. van der Linden. Software Product Line Engineering. Springer, 2005. [28] R. Reussner, H. Schmidt, and I. Poernomo. Reliability prediction for component-based software architectures. Journal of Systems and Software, 66(3), 2003. [29] N. Rozanski and E. Woods. Software Systems Architecture. Addison-Wesley, 2005. [30] V. S. Sharma and K. S. Trivedi. Architecture based analysis of performance, reliability and security of software systems. In Proceedings of the 5th International Workshop on Software and Performance, 2005. [31] M. Shaw and D. Garlan. Software Architecture–Perspectives on an Emerging Discipline, chapter 2. Prentice Hall, 1996. [32] P. Simons, I. Niemel¨a, and T. Soininen. Extending and implementing the stable model semantics. Artificial Intelligence, 138(1–2), 2002. [33] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A framework for modeling variability in software product families. In Proc. of Software Product Line Conference (SPLC 2004), 2004. [34] T. Soininen, J. Tiihonen, T. M¨annist¨o, and R. Sulonen. Towards a general ontology of configuration. AI EDAM (Artificial Intelligence for Engineering Design, Analysis and Manufacturing), 12(4):357–372, 1998. [35] T. Soininen, J. Tiihonen, T. M¨annist¨o, and R. Sulonen. Special issue: Configuration (guest editorial introduction. AI EDAM (Artificial Intelligence for Engineering Design, Analysis and Manufacturing), 17(1–2), 2002. [36] M. Svahnberg, J. van Gurp, and J. Bosch. A taxononomy of variability realization techniques. Software—Practice and Experience, 35(8), 2005. [37] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The Koala component model for consumer electronics software. IEEE Computer, 33(3):78–85, 2000.
70
Visualisation of Variability in Software Product Line Engineering Daren Nestor1, Luke O’Malley2, Aaron Quigley2, Ernst Sikora1, Steffen Thiel1 Lero – The Irish Software Engineering Research Centre 1
2
University of Limerick Limerick, Ireland
University College Dublin Dublin, Ireland
{ daren.nestor | luke.omalley | aaron.quigley | ernst.sikora | steffen.thiel }@lero.ie
[5] [6]). However, these techniques have mainly been applied in prototypical settings in which relatively few variation points and variants had to be managed. Consequently, there is a need for appropriate techniques for “industry-size” software product lines with a high number of variants which can support product line stakeholders in performing their tasks. This paper elaborates on the idea of using information and software visualisation techniques to achieve the economies of scale required to support variability management in industrial product lines. Information visualisation is the use of computersupported, interactive, visual representations of abstract data to amplify cognition [7]. Software visualisation is a sub-area of information visualisation that focuses on both the human understanding and effective use of computer software [8]. Visualisation has proven useful to amplify cognition in a number of ways, for example, by increasing the “memory” and “amount of processing” available to users, by supporting the search for information, and by encoding information in a manipulable medium [7]. The authors are convinced that visualisation techniques can also amplify the cognition about the large and complex data sets created and used in industrial software product line engineering. The exploration of the potential of visual representations such as trees and graphs combined with the effective use of human interaction techniques such as dynamic queries, direct manipulation, and details-on-demand when applied in a software product line context is a challenging research task. Improving the effectiveness of significant product line activities such as variability management and product derivation is a major goal of this research. The remainder of this paper is organised as follows: Section 2 introduces variability modelling approaches and discusses representation techniques commonly used in product line engineering. Section 3 explains some of the limitations of current variability
Abstract Using a product line approach allows companies realize significant improvements in time-to-market, cost, productivity, and quality. One fundamental problem in software product line engineering is related to the fact that a product line of industrial size can easily incorporate several thousand variation points. This makes variability management and product derivation tasks extremely difficult. This paper elaborates on the idea of using visualisation techniques to support and improve the effectiveness of these tasks. A reference model that helps to frame the visualisation research and important areas that affect the use of visualisation techniques in software product line engineering are presented.
1. Introduction In software product line engineering similarities between products are exploited to reduce the amount of work involved in product derivation. Software product line engineering has rapidly emerged as an important software development paradigm during the last few years. Developing products based on a product line approach allows companies to build a variety of systems with a minimum of technical diversity and to realize significant improvements in time-to-market, cost, productivity, and quality [1]. One fundamental problem with many software product line engineering approaches is that they do not scale well for industrial size product lines. This is due to the fact that industrial size product lines can easily incorporate thousands of variation points and configuration parameters for product customization (see e.g., [2]). Managing this amount of variability is extremely complex and requires sophisticated modelling techniques. Current variability modelling techniques have proven useful to represent product variation in various application domains (e.g., [3] [4]
1
71
representations and motivates the challenges of applying software visualisation techniques in that area. Section 4 presents a reference model that helps to frame the visualisation research in software product lines. Section 5 discusses three areas that are of particular importance to this research. Section 6 outlines future research activities. Finally, Section 7 summarises the conclusions of the paper.
product line artefacts, partially by exploiting variation points and variants.
2.2 Variability Modelling Approaches Over the last few years, numerous models and approaches have been proposed for representing variability information in various development phases of a software product line approach, especially in requirements engineering (e.g., [3] [4]) and architecture design (e.g., [5] [6]). In this context, many researchers have suggested the integration of product line variability into traditional development artefacts such as feature models (e.g., [3]), use case models (e.g., [4]), architecture variability models (e.g., [5]), and class variability diagrams (e.g., [6]). Other researchers have emphasized the need for separating variability information from the original development artefacts in order to support the communication of variability and to improve consistency (e.g., [11]). Recently, the formalisation of variability emerged as an important research area, especially to support tool development and automation in software product line engineering. Existing approaches deal, for example, with the formalisation of feature models (e.g., [12] [13]) and the formal analysis of dependencies among features (e.g., [14] [15]). Further, a number of tools for variability modeling have been developed (e.g., [15] [16] [17]).
2. Variability Modelling 2.1 Terminology Variability refers to the ability of a software product line development artefact to be configured, customized, extended, or changed for use in a specific context [9]. It thus provides the required flexibility for product differentiation and diversification within the product line. Variability can evolve both in time and space. Variability in time is the existence of different versions of an artefact that are valid at different times. It thus denotes the evolution of an artefact over time. Variability in space is the existence of an artefact in different shapes at the same time. By this we mean that the same basic asset can be used differently in different products. External variability is variability visible to (and thus selectable by) customers. Internal variability is variability that is hidden from customers but visible to particular stakeholders of the product line effort, for example, product developers. Variation points identify locations in product line artefacts at which variation will occur [10]. The binding time refers to the point in a product’s lifecycle at which a particular variant for a variation point is bound to the system, e.g. pre- or post-deployment. A realisation mechanism refers to the technique that is used to implement the variation point [10]. Product derivation is the process of constructing products from
(a) Application-Requirements Matrix
2.3 Variability Representations Common notations used in existing approaches and tools for representing variability in product lines are application-requirements matrices (e.g., [1]), feature diagrams (e.g., [3]), and UML-based models with specialised notations (e.g., [5] [11] [18]).
(b) Feature Diagram Figure 1: Variability Representations
2
72
(c) Specialised Notations
An application-requirements matrix represents common and variable requirements of a set of applications (or products) in a matrix (see Figure 1a). The left column of the matrix usually shows the requirements of the applications considered in the product line. The applications themselves are given in the top row, whereas the body of the matrix provides information about which requirements are mandatory for a certain product. A feature diagram is a graphical representation of a feature model which shows a hierarchically structured set of features of the product line (see Figure 1b). Features are represented as nodes and relationships between features as links. Possible relationships between features are usually categorized as “And” (all subfeatures must be included), “Or” (one or more subfeatures can be included), “Alternative” (only one subfeature can be included), “Mandatory” (required feature), and “Optional” (potential feature). A feature diagram is typically represented as a tree where primitive features are leaves and compound features are interior nodes. Finally, several researchers have proposed approaches to model variability by using UML-based or specialised notations. The notations usually contain specific extensions or symbols for denoting the existence of variation points and variants. These models are often created from metamodels that define how to build valid model instances. A sample notation introduced in [11] is given in Figure 1c.
of products, different manufacturers, and different product models. To represent the variability of (a part of) the E&P product line we have applied the ApplicationRequirements Matrix technique discussed in Section 2.3. In this example, the rows of the matrix contain simulation features. Figure 2 shows an excerpt of the product line features, limited to twelve products and 120 features. Mandatory features are marked as black rectangles. From a visualisation point of view, a representation such as that depicted in Figure 2 supports retrieving certain facts related to variability, for instance, which features are common to most products listed and which features apply only to a small subset of products. This simple and compact visualisation allows us to reason about which features are candidates for common assets, and identify other features as areas where variation points could be introduced. However, the matrix conveys a very limited set of information. Relational and dependency information are not included, for instance. Information about binding times is missing and it is not clear which features include internal variability and to which implementation structures (e.g. modeules) a particular variation point is assigned. Yet, this information is essential to accomplish variability management and product derivation tasks in a product line approach. Consequently, the tabular visualisation presented in Figure 2 is useful for some tasks but generally not sufficient. More sophisticated visualisation techniques are required in order to satisfy all information needs that arise in variability management and product derivation. Other variability techniques, such as those discussed in Section 2, allow the addition of some of the information missing from this representation. Yet, graph based visualisations such as feature diagrams or UML models suffer from other limitations. Graph based diagrams can, for example, easily overwhelm stakeholders with information, especially when the diagram includes a high number of nodes, detailed information for each node, and a high number of links. Extensive study is required to retrieve specific information from such diagrams. In addition, since the visualisations are (essentially) static, it is not possible to create customised views, e.g. to support particular product derivation tasks.
3. Research Challenges for Variability Visualisation While numerous modelling approaches and representations for variability have been proposed in the past, the visualisation of variability information is still limited in certain cases. To illustrate this assertion we first introduce an example from one of our industrial partners and then discuss problems that arise with existing variability representations. 3.1 E&P Variability Example E&P is a company that specializes in authentic simulations and interactive tutorials for consumer electronics such as car infotainment systems, mobile phones, and digital imaging systems. The product line approach is effective in this domain because due to the similarities in the structure and behaviour of the different simulations. For example, all simulations have a similar user interface comprising one or multiple (simulated) displays and (simulated) control buttons. The number of variation points is high as the simulations have to be customised for different types
3.2 Limitations in Variability Representation From the example above, it is clear that even with a relatively small product line of twelve products and by applying the existing techniques to represent
3
73
variability, an effective variability management is difficult to achieve. There are two main limitations the authors want to expand on: the representation of large variability structures and interacting with the variability representation.
Limited representation of a large variability structures: Existing approaches are limited with respect to representing information about large variability structures. Industrial product lines such as those reported by Nokia [19], Philips [20], and Bosch [2] usually include hundreds of products. This means that these product lines could easily incorporate many thousands of variation points, making it extremely difficult to handle relationships among product line artefacts and to manage systematic product derivation. The extraction of information from existing variability representations is possible for software product lines with only small variability models but severely impaired for large-scale models. Limited interaction with variability representation: A single, static visualisation can hardly support different product line engineering tasks such as exploring the variation points or deriving product variants. Product line engineers must be able to interact with visualisations and adapt the information that is visualised. Yet, existing approaches provide either no or very limited support to interact with the visualisation. To overcome these limitations in representing variability, the authors propose to investigate in information and software visualisation techniques (see e.g. [7]). These techniques have proven useful in the comprehension of large amounts of data. However, the use of information/software visualisation techniques in the context of a software product line approach is largely unexplored. In the following, the authors elaborate on the idea of using visualisation techniques in software product line engineering and introduce a reference model to illustrate potential research areas of investigation.
4. Visualisation Reference Model According to the work of Card et al. [7], visualisation can be described as “adjustable mappings from data to visual form to the human perceiver.”. Figure 3 shows a slightly adapted version of the reference model given in [7] that illustrates these mappings for variability visualisation in the context of software product lines. In Figure 3, the arrows flow from data on the left to the human perceiver, indicating a series of data transformations. Arrows also flow from the human perceiver at the right into the transformations themselves, indicating the adjustment of these transformations by user-operated controls. The first type of transformation is Data Transformations which map raw SPL Data (i.e., data about the software product line (SPL) artefacts, their
Figure 2: Excerpt of a Feature Matrix
4
74
variability, and the dependencies among them) into Data Tables. Data Tables are relational descriptions of data extended to include metadata (i.e. descriptive information about the data). The usual strategy here is to achieve a set of relations that are more structured than the original data and thus easier to map to visual forms. Visual Mappings then transform Data Tables into Visual Structures. Visual Structures are structures that combine spatial substrates (e.g., nominal or ordinal axis), marks (points, lines, areas, volumes), and graphical properties (e.g., colour, texture or intensity) to encode information. It is important to note that a Visual Mapping preserves the data and that it can be perceived well by the human. View Transformations create Views of the Visual Structures by specifying graphical parameters such as position, scaling, and clipping. As such, View Transformations interactively modify and augment Visual Structures to turn static presentations into visualisations. They exploit time to extract more information from the visualisation than would be possible statically. Finally, user interaction controls parameters of these transformations, restricting the view to certain data ranges, for example, or changing the nature of the transformation. The visualisation and their controls are used in service of some task. A summary of interaction tasks is given in Table 1. There are various visualisation techniques that are applicable to the interaction tasks described above. Filtering of the source data could allow the breaking down of systems into manageable chunks, making it possible for meaningful tasks to be completed on the data (e.g., examining the variability of a particular subsystem of the product line).
Table 1: Visualisation Interaction Tasks Task Overview Zoom & Pan Filter Details-ondemand Relate History
Extract
Description Gain an overview of the entire collection Zoom in on items of interest and move about the visualization Filter out uninteresting items Select an item or group and get details when needed View relationships among items Keep a history of actions to support undo, replay, and progressive refinement Allow extraction of subcollections and of the query parameters
Focus of attention techniques could allow an engineer to keep a mental map of the overall product line artefacts while emphasizing the information of current interest, allowing this information to be communicated or acted upon with greater efficiency and success (e.g., variability dependencies). Aggregation and decomposition allow the data to be either grouped or partitioned in some meaningful manner, allowing for less overwhelming visualisations while keeping the relevant connections between artefacts and products, allowing for more effective product navigation and derivation. Interactive details on demand allows information to be accessed when required, while keeping them hidden when they are not needed, resulting in effective information communication and preventing information overload (e.g., details on binding times of variation points).
Figure 3: Reference Model for Variability Visualisation (based on [7])
5
75
These techniques could be applied to product line use scenarios that have emerged during consultation with our industrial partners. Information such as typical product configurations where products can be categorised into regional variants or customer specific variants would be useful. Purely technical information, such as a representation of assets used to create a product, or visualization of architectural structures, was also considered desirable. Figure 4 is a concept of visualising the crossover of variation between different products based on set notation. It effectively illustrates the feature set of each product, and makes it easy to identify commonality, variability and exclusivity in the variation sets.
Outline methods can provide both structural and content information. Yet the structural information can be extracted only for a few lines at the same time. For both, listings and outlines, the number of lines required to present a hierarchy is equal to the number of nodes. According to Johnson and Shneiderman (see [7], p. 152) listings and outlines are “inadequate for structures containing more than a few hundred nodes.” The authors point out that “a great deal of effort is required to achieve a mental model of the structure in large hierarchies using these methods.” Tree drawings are excellent at presenting structural information for small hierarchies. However, they make poor use of available display space. To provide a global view on a large hierarchical structure, nodes have to be very small. In this case, content information cannot be presented well. Hence, tree drawings are of limited use for the visualisation of variability, unless the available display space is large. The presentation of hierarchical information can be improved even if the display space is limited. Visualisation techniques that are based on enclosure rather than on connection, for example, allow improved display space usage. Examples of such techniques are Venn Diagrams and Tree-Maps (see e.g. [21]).
5. Discussion Three important research directions for further investigation are outlined in this section: presentation of information, task support, and user interaction. The authors believe that these areas will be important to ensure that visualisation will be effective in supporting variability management and product derivation in the context of a product line approach.
5.1 Presentation of Information An important issue in this area is to overcome the problem of communicating information effectively in a high information density environment. Extracting information from high variability representations can lead to information overload. Hierarchical structures can help in this respect. Common visualisation techniques for hierarchical information structures include listings, outlines, and tree diagrams [7]. Listings are good at providing detailed information on content but poor at presenting structural information.
5.2 Task support The visualisations need to provide direct support for the product line stakeholders’ tasks in variability management and product derivation. This requires identification of the tasks, the information required to perform the tasks, and the group of stakeholders who are associated to the tasks. Typical tasks for variability management (VM) and product derivation (PD) are shown in Table 2. Table 2: Product Line Engineering Tasks Type VM VM VM VM PD PD PD
Figure 4: Feature Set Visualisation Concept
6
76
Stakeholder Task Determine in how many products a particular variant is used Determine how many versions of a variant are available Determine the internal/external variability of the product line Determine the dependencies of a particular variant to other variants Derive the design for a product variant based on a set of requirements Derive the design of the minimum product variant (entry level system) Derive the design of the maximum product variant (high end system)
According to the authors opinion, task support could be best provided by interactive visualisations. Support for different tasks could be achieved by providing different views (e.g., one view to explore structural information and another view to explore content details). In addition, each view could be adjustable for different purposes, as each task has different information requirements.
is thought that the view transformations to be applied to the visual structures will require interaction (cf. Section 5.3) to provide the task support necessary.
7. Conclusions This paper has elaborated on the idea of using information and software visualisation techniques to support software product line activities such as variability management and product derivation. Current techniques for representing variability were introduced and it has been discussed that these techniques have trouble scaling to the levels required to allow for their use in the medium and large scale product lines that are prevalent in industrial applications. Further, a reference model that helps to frame the visualisation research in software product lines has been presented. The model helps to map out the use of techniques from visualisation research to assist with managing variability and product derivation. Promising techniques were mentioned, along with their benefits. In addition, important areas that could affect the use of these techniques were discussed, and a general road map for moving this research forward was outlined. In the context of the examples presented, the authors feel that visualisation could be of assistance in many areas. For example, in relation to managing the asset base and the links to current products, visualisation could assist in keeping the required level of understanding as the product line expands. Rather than relying on a paper trail, or on the tacit knowledge and experience of a small number key people, a visualisation toolkit could lower the complexity involved in managing the documentation, application and reuse of assets. However, further research is necessary to explore the full potential of visualisation techniques in the software product line area.
5.3 User Interactions Interaction is important to get the most out of a visualisation. Different interactions produce different results, and are effective for different tasks. Simple actions such as zooming and rotation of a visualisation can greatly increase its effectiveness at communicating information. One of the more powerful possible user interactions are dynamic queries. These support information seeking by allowing the user to adapt a visualisation and to observe the effect of the adaptation immediately (see [7], p. 235). The adaptation is accomplished by adjusting visualisation parameters through user interface elements. A typical application of dynamic queries is the filtering of the set of objects displayed on the screen. For example, the user may influence the set of visible objects by selecting and unselecting check boxes or by moving a slider. A possible use of dynamic queries for the visualisation of variability is allowing the user to turn on and off entities and relationships based on their type and on attribute values (e.g., represent all features of a certain priority that are not assigned to a component; or represent all features that are assigned to product X and product Y but not to product Z).
6. Future Work The authors envisage their future work in this area to broadly follow the visualisation reference model introduced in Section 4. This will involve the identification of product line data required to be of assistance for product line stakeholders for variability management and product derivation and storing it in an appropriate format. This data then needs to be mapped to a selection of visual structures (such as those discussed in Section 5). However, an adaptation of existing structures and the development of new visual structures are expected in order to present the data in a coherent manner. It would be desirable that a visual structure can be selected interactively rather than arbitrarily presented as the “best” solution to a given problem. Views on these structures will then need to be provided to support the identified product line tasks. It
8. Acknowledgements This work is partially supported by SFI grant no. 03/CE2/I303_1.
References [1]
[2]
7
77
K. Pohl, G. Böckle, and F. v. d. Linden, Software Product Line Engineering: Foundations, Principles, and Techniques, 1st ed. New York, NY: Springer, 2005. M. Steger, C. Tischer, B. Boss, A. Müller, O. Pertler, W. Stolz, and S. Ferber, "Introducing PLA at Bosch Gasoline Systems: Experiences and Practices," Software Product Line Confernce (SPLC-2004), Boston, MA, USA 2004.
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
K. C. Kang, J. Lee, and P. Donohoe, "FeatureOriented Product Line Engineering," IEEE Software, Vol. 19, No. 4, pp. 58-65, 2002. G. Halmans and K. Pohl, "Communicating the Variability of a Software Product Family to Customers," Software and Systems Modeling, Vol. 2, No. 1, pp. 15-36, 2003. S. Thiel and A. Hein, "Modelling and Using Product Line Variability in Automotive Systems," IEEE Software, Vol. 19, No. 4, pp. 66-72, 2002. J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, H. Obbink, and K. Pohl, "Variability Issues in Software Product Lines," 4th International Workshop on Product Family Engineering (PFE-4), Bilbao, Spain, October 2001. S. K. Card, J. D. Mackinlay, and B. Shneiderman, Readings in Information Visualization: Using Vision to Think: Morgan Kaufmann Publishers, 1999. B. A. Price, R. M. Baecker, and I. S. Small, "A Principled Taxonomy of Software Visualization," Journal of Visual Languages and Computing, Vol. 4, No. 3, pp. 211-266, 1993. J. van Gurp, J. Bosch, and M. Svahnberg, "On the Notion of Variability in Software Product Lines," Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), Amsterdam, The Netherlands, August 2001. I. Jacobson, M. Griss, and P. Jonsson, Software Reuse. Architecture, Process and Organization for Business Success: AddisonWesley, 1997. S. Bühne, K. Lauenroth, and K. Pohl, "Modelling Requirements Variability Across Lines," 13th International Produduct Conference on Requirements Engineering (RE'05) 2005. A. G. J. Jansen, R. Smedinga, J. van Gurp, and J. Bosch, "First Class Feature Abstractions for Product Derivation," IEE Proceedings Software, Vol. 151, No. 4, pp. 187-197, 2004. D. Batory, "Feature Models, Grammars, and Propositional Formulas," 9th International
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
8
78
Conference on Software Product Lines (SPLC 2005), Rennes, France 2005. M. Ryan and P. Y. Schobbens, "FireWorks: A Formal Transformation-Based Model-Driven Approach to Features in Product Lines," 3rd Software Product Line Conference (SPLC 2004), Workshop on Software Variability Management for Product Derivation, Boston, MA, August 2004. M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch, "Modeling Dependencies in Product Families with COVAMOF," 13th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS 2006), Potsdam, Germany, March 2006. M. Antkiewicz and K. Czarnecki, "FeaturePlugin: Feature Modeling Plug-in for Eclipse," OOPSLA Workshop on Eclipse Technology eXchange, Vancouver, British Columbia, Canada 2004. D. Beuche, "Variants and Variability Management with pure::variants," 3rd Software Product Line Conference (SPLC 2004), Workshop on Software Variability Management for Product Derivation, Boston, MA, August 2004. H. Gomaa and M. E. Shin, "Multiple-View Meta-Modeling of Software Product Lines," 8th International Conference on Engineering of Complex Computer Systems (ICECCS 2002) 2002. A. Maccari and A. Heie, "Managing Infinite Variability in Mobile Terminal Software," Software - Practice and Experience (SPE), Vol. 35, No. 6, pp. 513-537, 2005. F. van der Linden, "Software Product Families in Europe: the ESAPS & CAFE Projects," IEEE Software, Vol. 19, No. 4, pp. 41-49, 2002. B. Johnson and B. Shneiderman, "Tree-Maps: A Space-Filling Approach to the Visualisation of Hierarchical Information Structures," IEEE Visualization, pp. 189-194, 1991.
Unified Feature Modeling as a Basis for Managing Complex System Families Mark-Oliver Reiser, Ramin Tavakoli Technische Universit¨at Berlin Fakult¨at IV, Lehrstuhl Softwaretechnik Franklinstraße 28/29 D-10587 Berlin, Germany {moreiser,tavakoli}@cs.tu-berlin.de
Matthias Weber Carmeq GmbH Business Team Process Management Carnotstraße 6 D-10587 Berlin, Germany
[email protected]
Abstract
a sound formal basis, [4, 9, 21]. Others seek to overcome the diversity of the various feature techniques that currently exist side by side by using a unified approach for feature modeling, e.g. [1]. In this paper, we aim to contribute to this unification effort by showing its great relevance for the automotive domain and by identifying several requirements for a unified feature-modeling approach, some of which – to the best of our knowledge – have not yet been considered in the relevant literature. As a starting point for this discussion, we present, in Section 3, our view of how to employ feature modeling in the development of highly complex families of software-intensive systems, such as an automotive manufacturer’s product range. From this, we then deduce several requirements for a unified feature-modeling technique (Section 4). The final two sections are then devoted to a discussion of related work and concluding remarks.
When developing large-scale, industrial system families, variability management is faced with a number of challenges: the heterogeneity of development processes, methods and tools; a high degree of collaboration not only between departments and projects but also between different companies; and diverging life-cycles of subsystems. In this paper, we outline a possible framework for applying feature modeling in such intricate development environments. In doing so, our main objective is to deduce from the framework several requirements for feature-modeling techniques intended to be applied in this manner. Since these requirements are all centered around the basic demand that feature models be as flexible as possible – in order to cover as many proprietary variability modeling and specification techniques as possible – we refer to them as “unified feature models”. We believe that these requirements can help guide the current discussion in research literature on consolidating and integrating feature modeling concepts.
2 Terminology But before going into details, let us define a number of basic terms in this section. A product line is a set of several products which share many common characteristics but also show certain substantial differences. When following a product-line oriented approach, the individual products are no longer developed independently from one another, but instead only a single, but variable product is developed (also called product line infrastructure). From this variable product, the actual products (also called product instances) can then be derived by configuration. Consequently, development is divided into two separate phases: The development and evolution of the product line infrastructure (called domain engineering) and the definition of individual product instances to be derived from that infrastructure (called product engineering). All development artifacts that make up the product line
1 Introduction Feature modeling has become a popular instrument for both domain analysis in general and as a core concept for product-line-oriented software and systems development. Initially, research in this field focused on extending the original notion of feature modeling as introduced by Kang et al. in 1990 [14], by adding new concepts and enhancing the expressiveness of the models. Over the past one or two years, the focus has shifted toward consolidating the feature-modeling concepts proposed so far and integrating them into what could be called a unified feature-modeling technique. One such a consolidation effort is the attempt, in several recent publications, to put feature modeling on
79
relationships arises, in which virtually everyone is at least indirectly related to everyone else. On the other hand, development means are highly heterogeneous: even within a single company, many different methods and tools are used, for historical reasons sometimes even for a single purpose, and when cooperation between manufacturers and suppliers is taken into account, heterogeneity further increases dramatically. And finally, differing development processes also contribute to the heterogeneity of system family development. This picture might give the impression that heterogeneity is rather a deficiency of today’s industry to be overcome by new, comprehensive development means, instead of being specifically supported by them. Should we not aim to find methodologies that overcome heterogeneity instead of encouraging it? Of course, to some extent this is true, and there are several joint efforts of the automotive industry and research institutions to reduce heterogeneity by means of standardization, for example the AUTOSAR partnership [3] or the European project ATESST [2]. However, heterogeneity will remain an issue,
infrastructure (e.g. requirements, design models, test cases) can be defined in a variable form, if their content varies from product to product. This is usually achieved by adding variation points to them and defining several variants for each such variation point. The term product family is sometimes used synonymously to product line. We prefer to think of a product family as a very complex product line, possibly made-up of several smaller product lines. One of the most common concepts of product line methods are feature models, which were introduced by Kang et al. [14, 15]. In particular, they are used to document what characteristics are common to all product instances and which characteristics differ from one product instance to another. Also dependencies between characteristics are defined in feature models. A feature in this context is a certain characteristic or trait that each product instance may or may not have. Often, feature models are hierarchically structured as feature trees. Apart from documenting the commonalities and differences between product instances, feature models also serve as coarse-grained requirements. Further details of these basic terms are beyond the scope of this paper but can be found in [5, 7, 8, 17, 24].
1. for practical reasons (adopting of new methods takes time; not everyone will be willing to employ the same methods and tools),
3 Framework for Complex System Families
2. because computer science is an evolving discipline and, whenever progress is made, there exist – at least for a while – several alternatives and in most cases it is impossible to say in advance which is the best way to proceed,
In this section we outline a framework for applying feature modeling in complex system families. We do not aim to provide a thorough and comprehensive approach to system family engineering here. Instead, the framework should illustrate our view of how to employ feature modeling in system engineering and of the role it is playing within the overall development context. From this, we will then deduce several requirements for a feature-modeling technique to be applied in this manner (Section 4). Before discussing the framework in Section 3.2, we give a motivation by highlighting several important characteristics of complex system families, using the automotive domain as a model.
3.1
3. because in large organizations new methods and tools can never be introduced everywhere at once; instead, to reduce risk, they first have to be introduced and tested only for a single project, subsystem or product model, thus being employed in parallel with the legacy methods and tools, and 4. because there is normally no one single solution that serves everybody’s needs, especially when considering the diverse needs that differing development processes impose on methods and tools.
Complex System Families
Consequently, a methodology for system family development must cope with heterogeneity. Equally important, diverging life-cycles of individual subsystems and development artifacts pose another challenge to system family development. A subsystem like a wiper or a brake-by-wire system is usually not only built into several vehicle models produced in parallel but also into several consecutive generations of these models; and often, during the production of one generation of a vehicle model, such a subsystem may even be replaced by another, i.e. the introduction of a new subsystem does not necessarily coincide with the introduction of a new vehicle model.
One of the most important attributes of the development of complex families of software-intensive systems is heterogeneity. This is true both for the organizational context in which development takes place and for the methods, tools and processes employed. For example, not only are today’s global car manufacturers organized as groups of several large divisions each comprising a multitude of units, departments, teams and projects, but automotive development is also highly distributed among the manufacturer and its suppliers. Since each supplier usually works for several different manufacturers, a complex network of
80
These observations are arguably applicable to most other domains of industrial, software intensive systems, such as medical technology or mobile devices [6].
3.2
be propagated from the core feature model to those of the artifact lines, and not the other way round. Artifact lines may, in turn, be composed of other, lowerlevel artifact lines. To achieve this, the feature models of the lower-level lines are linked to the top-level line’s feature model in exactly the same way as described before for an artifact line’s feature model and that of the overall product line. In this way, variability exposed by the lower-level artifact lines may be partly hidden, diversely packaged or presented in a different form. Consequently, two sorts of variability information are hidden: first, the details of how variability is technically defined within the specific artifact (e.g. with explicitly defined variation points together with variants for them or with aspects that may optionally be woven into the artifact), and second, in the case of composite artifact lines, the details of how variability is exposed by the lower-level artifact lines. We refer to both cases of concealment as configuration hiding. This configuration hiding is key to supporting the diverging life-cycle of individual development artifacts as well as the complex network of manufacturer-supplier relationships described above. In addition, such a hierarchical management of variability is an effective instrument to reduce the combinatoric complexity of product-line engineering [16]. Here, an interesting analogy to interfaces of classes and components is noticeable: the higher-level feature models (including the core feature model of the overall product line) can be seen as a description of required variability, whereas the lower-level feature models describe provided variability. However, the analogy has an important limitation: a matching lower-level feature model – i.e. one that provides all the variability required by the higher-level feature model – does not usually match the higher-level model structurally; by contrast, the correspondence may be fairly complex and only perceptible when considering the involved feature’s semantics together with the corresponding artifact’s role within the overall product line. Instead of having a single core feature model, it is also conceivable to hierarchically decompose this core model into several feature models linked by way of the concept used to link the artifact lines’ feature models to the core. For example, two core feature models could be used to distinguish a customer viewpoint and an engineering viewpoint on variability, as explained in [19]. Finally, since the number of artifact lines can grow quite large and the links between them can become rather complex, there probably is a need for a dedicated type of diagram presenting an overview of this structure. This diagram could also serve other purposes: for example, it could be used to document conflicts that appear when a team responsible for an artifact line discovers the need for additional variability in another artifact line. However, the details of
Framework
Especially in such intricate development contexts, feature modeling has great potential: features may serve as a link between management, marketing and development in a single company and as a link between companies to facilitate communication. And they can provide a central view of variability in a wide range of development artifacts – such as requirements, design models or test cases – thus becoming the core of all variability and evolution management. But when applied in this way, feature-modeling techniques are confronted with the full heterogeneity of development means and the diverging life-cycle of subsystems as described above. To take full advantage of this potential, it is therefore essential to find a way to meet these challenges. The basic idea of the systems family framework proposed here is that each development artifact may be organized as its own small product line. Similarly, several artifacts may be combined and may be managed together as a single small-sized product line. Of course, the instances of these subordinate product lines are different in nature from the instances of the overall product line: in the first case we have an initialized, non variable development artifact, such as a test-case description or a requirements specification, while in the latter case we actually have a product, e.g. an automobile. To emphasize this fact and to avoid confusion with the term product subline as defined in [20], we refer to these small-sized “product lines” of development artifacts as artifact lines or artifact sublines1 . The main property distinguishing an artifact line from a simple variable artifact in a product line infrastructure is that the artifact line is provided with its own feature model. This feature model is used to publish an appropriate view of the artifact’s variability to the actors interested in instances of this artifact. This makes the one or more artifacts in the artifact line independent from the global core feature model of the overall product line. The link between the artifact line and the overall product line is achieved by defining the configuration of the artifact line’s feature model as a function of the configuration of the core feature model of the overall product line, as illustrated by the dashed arrow in Figure 1. Then, whenever a configuration of the core feature model is given, the configuration of all artifact lines can be deduced from it. In most cases, these links are directed in the sense that configuration can 1 The distinction between an artifact line and an artifact subline follows the definition of product subline in [20]; the details of this distinction are not necessary for the following discussion and are beyond the scope of this paper.
81
Figure 1. Framework for applying feature models in system family oriented development. link between the two. The latter two are highly artifactspecific, i.e. the variability definition mechanism must be tailored to the specific nature of the artifact and its corresponding method and tool. In addition, they must be adapted to the feature-modeling technique used for the core feature model because they are directly related through the link between the two. Consequently, it is impossible to devise and formulate the many individual mechanisms for variability definition without being aware of the modeling technique for the core feature model, and vice versa. Given the fact that many tool vendors are currently enhancing their tools, together with the underlying methods, by proprietary concepts for expressing variability, this is a show-stopper for managing a system family through a central global feature model.
this overview diagram are not directly related to the feature modeling technique being used and can therefore be left aside here. To summarize, the framework is made up of the following constituents: 1. a feature modeling technique 2. a concept to link two feature models A and B, i.e. to define the configuration of B as a function of the configuration of A 3. several artifact-specific techniques to define variability within each artifact 4. a modeling technique for an overview diagram
By contrast, when inserting an additional feature model between the core model and the variable artifact (as illustrated in Figure 1), the situation is different: At first sight, not much has changed because everything is still related to everything else. However, if we assume that the feature modeling technique used for the core feature model and the artifact line’s model was extremely flexible, such that virtually any variability specification mechanism could be perceived as being a special case of our flexible feature modeling language, the artifact’s feature model could be a highly artifact-, method- and/or tool-specific variability specification and, at the same time, be used as a feature model. The advantage would be that the link between the feature models would no longer span diverse methods but could be defined within a single methodology and tool.
In the remainder of this paper, we focus on the feature modeling technique (no. 1). Further information on the link between feature models (no. 2) in the form of product decisions and product sets can be found in [19]. No. 3 is not really a true constituent of the framework. In fact, one important idea of the framework is that such artifact-dependent techniques can be devised without considering the framework. This is explained in the coming section. As stated above, No. 4 is beyond the scope of this paper.
3.3
Dealing with Heterogeneity
How, then, does this framework tackle heterogeneity and diverging life-cycles ? To illustrate this, we first examine the traditional situation without artifact lines. We have, in this case, the overall product line’s core feature model, the artifact with its variability definition mechanism and some
By way of an example, let us consider three development artifacts: a piece of C source code, a state-machine model
82
• feature groups (i.e. the ability to group several children of a feature and impose a constraint on them, e.g. that they are alternative, without affecting the other children; having several of these groups below the same parent)
in some modeling tool T and a set of test case specifications (whether the source code is intended to be an implementation of the behavioral model or not is irrelevant here). Assume that variability for the source code is expressed by means of preprocessor macros and that tool T provides a variation point- / variant-based technique for introducing variability in state machines, where each variant is supplied with a propositional formula specifying when it is valid; the formulas of a single variation point’s variants must be disjoint. Finally, the test team decided to use a feature tree managed in the commercial tool pure::variants [18] to systematize variability. In the case of the source code, the variability specification simply consists of the set of preprocessor variables and their allowed values, i.e. the values that are used within the code in preprocessor commands, such as #ifdef and #ifndef. In the case of the state machine, the Boolean variables used in the logical expressions form the variability specification. The goal is now to come up with a feature-modeling technique that is flexible enough to treat these two kinds of variability specification as normal – if degenerate – feature models. Similarly, the feature tree of pure::variants could be incorporated. Then, the link between the global product line’s core feature model and certain configurations of these three artifacts could be formulated in a single methodology and tool. Thus, the feature modeling technique used for system family engineering according to the framework proposed above must be as flexible as possible. In the next section, we examine in detail what “flexible” means in this context.
• feature references (i.e. features that are reused and appear more than once within the same feature model, thus turning the feature tree into a directed acyclic graph) • parameterized features (i.e. features that are not merely selected or deselected during configuration of the feature model but, if selected, are – during configuration – also assigned a value of a certain type; often this is also referred to as a feature attribute) • links between features of various types (such as f1 “requires” f2 or f1 “excludes” f2 ) Nevertheless, some concepts may also be completely ruled out, in case they are deemed to lie outside the scope of feature modeling. For example, Czarnecki et al. have suggested that for reference attributes in [12]. But this should only be done, if the concept in question is not used by any important, well-established feature modeling techniques. In addition, many classifications and additional characterizations for features have been proposed, e.g. an assignment of features to different layers [15], binding times [5, 22] and a distinction between primitive and compound features [21]. Directly adding all these different notions to the modeling technique would make it very complex; this problem can be solved with the next required concept. (2) As described in the previous section, the technique is supposed to be used as a means of communication between many different departments, projects and even companies. In these situations, there will often be a need to supplement the information in the feature models with some additional meta-information (e.g. customer visibility for features). The approach must therefore provide means to define custom attributes, their types and allowed values. It should be possible to attach these custom attributes to features, edges (parent/child relationships) and links between features. Naming conventions should be part of the featuremodeling technique to avoid conflicts between attribute and type identifiers when feature models of different organizational units are incorporated into a single system family. For example, a naming scheme similar to that of Java classes and packages (e.g. org.xml.sax and org.w3c.dom for XML parsers) could be used. This concept could also be used to cover the numerous classifications and characterizations of features mentioned above. For these, certain “custom” attributes together with possible values and their semantics could be standardized in the feature method so that they would not contribute to
4 Requirements for Unified Feature Modeling After describing a possible way of using feature models to meet important challenges of complex system families, we can now deduce several requirements for featuremodeling techniques to be used accordingly. (1) First of all, since the feature-modeling technique we are seeking must – according to the above framework – be able to express feature models of many other existing feature techniques and tools, it is required to comprise all important feature-modeling concepts proposed in the literature in recent years. The only exception here are concepts that can straightforwardly be mimicked by other concepts. The principal concepts that need to be supported include: • parent/child relationship • mandatory and optional features • features with a cardinality above 1 (often referred to as cloned features, [12]) • typed edges, i.e. typed parent/child relationships
83
The question as to which feature-modeling concepts are appropriate then turns into the question: In which situations should each concept be used and in which not? This leads us to an additional requirement for the modeling technique. (7) The technique should provide ways of restricting its use for certain feature models. For example, features with a cardinality greater than 1 are very useful in some contexts, while the additional complexity they introduce is unnecessary in other contexts; it should therefore be possible to restrict the upper bound of cardinalities to 1 where this is deemed appropriate. Furthermore, it should be possible to restrict use of the technique to a subset of concepts, corresponding to the concepts provided by a certain established featuremodeling technique from literature (e.g. FODA [14] or FORM [15]) or an established feature-modeling tool, such as pure::variants. Such restrictions could be imposed by way of a general constraint mechanism. Constraints that realize such restrictions could then be called compliance constraints2 , to highlight that fact that they enforce compliance with a certain modeling technique or tool.
the structural concepts but would be available when needed. The various link types and types of edges proposed in the literature could also be supported this way. (3) In addition, it should be possible to deliberately determine the order of features. This is true of both the order of root features in the model and the order of child features within their parent’s list of children. While order does not have a semantical meaning in feature modeling, it is often used to structure and organize features. This is especially true of very flat but wide feature “trees”, which often arise early on when adopting the notion of feature modeling. (4) Furthermore, the feature-modeling technique should be careful to avoid – both on the syntactical as well as the semantical level – any unnecessary special cases or restrictions, that are aimed at imposing a certain style of feature modeling. For example, root features should simply be treated as features not having a parent; grouped features should simply be features that have a feature group as their parent instead of a feature; feature models with more than one root feature should be allowed. This is because such restrictions always increase the risk that some special forms of feature modeling or variability specification introduced by proprietary tools will not be supported. This applies in particular to “degenerate” feature models that are not normally perceived as feature models but should be covered by the variability modeling technique for the reasons given in the previous section: e.g. sets of booleans or sets of enumerates. (5) The entire technique, both syntax and semantics, must be based on a solid formal foundation. As Schobbens et al. have shown in [21], this is necessary to prevent ambiguities within the approach. But it is also necessary to prevent misinterpretations when applying it or when defining syntactical and semantical mappings from proprietary techniques to it. (6) Finally, the technique should comprise an open, reusable reference implementation as well as a mapping to XML, in order to facilitate providing support for it.
5 Related Work The main body of related literature consists of the feature modeling techniques proposed so far, such as FODA [14], FORM [15], cardinality-based feature modeling [10, 11], etc. as well as recent contributions to a consolidation and integration of feature modeling concepts, e.g. [1, 21]. These were already discussed throughout the above description. The idea of managing variability in a hierarchical manner is not new. Krueger has described in [16] how modularization and hierarchical decomposition can be used to cope with combinatoric complexity in software product lines. The framework outlined in Section 3 is different in that it only consists of feature models and configuration links between them while in [16] the additional concept of matrices is introduced to allow for the hierarchical composition of modules. Another important difference is that the framework above suggests to embrace proprietary variability mechanisms as a special case of a single, very flexible feature modeling technique in order to deal with heterogeneity. This was a crucial point in the above discussion. As a minor difference, modularization and decomposition is, according to the above framework, rather motivated by the partitioning of development artifacts instead of subsystems or subcomponents. Due to its hierarchical structure, the framework descibed above also shows a certain similarity to component-oriented approaches to system family engineering, such as the Koala
However, a feature-modeling technique that met all the above requirements would be enormously flexible. And great flexibility of modeling means always entails additional difficulties for the modeler. Thus, an important motivation for many of the feature-modeling techniques proposed in the literature was to avoid just that by carefully selecting the most appropriate concepts and ruling out the inappropriate or not really necessary ones. We do not question this objective, but we feel that the question as to which feature modeling concepts are appropriate cannot be answered for all application domains and contexts in the same way. We therefore propose to devise a highly flexible and comprehensive modeling technique but restricting its use depending on the needs of the concrete application context.
2 Not
84
to be mistaken with conformance constraints as defined in [20].
component model by van Ommering [23]. The difference however is that the above framework tries to not make any assumptions on the nature and content of the artifacts and does not aim to embrace the entire system family with a single consistent methodology. If there were a component model, defining how the system’s subcomponents are to be connected to form the system, this model would simply be viewed as yet another artifact. While system family oriented component approaches try to bring together variability management and a certain development paradigm, i.e. component-oriented design, the framework above tries to separate variability management from the employed development methods as strictly as possible. In other words, the above framework does not replace these component-oriented approaches but provides a parenthesis to combine them with other development methodologies, such as requirements engineering or test methods. The same applies to other approaches that complement an existing development method or tool with variability management, for example [13] in the case of UML.
[5] J. Bosch. Design and Use of Software Architectures – Adopting and Evolving a Product-line Approach. AddisonWesley, 2000. [6] J. Bosch. Software product families in nokia. In 9th International Software Product Lines Conference (SPLC 2005), volume 3714 of LNCS, pages 2–6, 2005. Keynote. [7] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley, 2002. [8] K. Czarnecki and U. Eisenecker. Generative Programming. Addison-Wesley, 2000. [9] K. Czarnecki, S. Helsen, and U. Eisenecker. Formalizing cardinality-based feature models and their specialization. Software Process: Improvement and Practices, 10(1):7–29, 2005. [10] K. Czarnecki, S. Helsen, and U. Eisenecker. Staged configuration through specialization and multi-level configuration of feature models. Software Process: Improvement and Practices, 10(2):143–169, 2005. [11] K. Czarnecki and C. H. P. Kim. Cardinality-based feature modeling and constraints: A progress report. In Proceedings of the OOPSLA’05 Workshop on Software Factories, oct 2005. [12] K. Czarnecki, C. H. P. Kim, and K. T. Kalleberg. Feature models are views on ontologies. In Proceedings of the 10th International Software Product Line Conference (SPLC 2006), pages 41–51, 2006. [13] H. Gomaa. Designing Software Product Lines with UML. Addison-Wesley, 2004. [14] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-oriented domain analysis (foda) – feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute (SEI), Carnegie Mellon University, 1990. [15] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh. Form: A feature-oriented reuse method with domain-specific reference architectures. Annals of Software Engineering, 5:143–168, 1998. [16] C. W. Krueger. New methods in software product line development. In Proceedings of the 10th International Software Product Line Conference (SPLC 2006), pages 95–102, 2006. [17] K. Pohl, G. B¨ockle, and F. van der Linden. Software Product Line Engineering: Foundations, Principles and Techniques. Springer, Heidelberg, 2005. [18] Pure-systems gmbh web-site. www.pure-systems.com. [19] M.-O. Reiser and M. Weber. Using product sets to define complex product decisions. In Proceedings of the 9th International Software Product Line Conference (SPLC 2005), 2005. [20] M.-O. Reiser and M. Weber. Managing highly complex product families with multi-level feature trees. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE 2006), pages 146–155. IEEE Computer Society, 2006. [21] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, and Y. Bontemps. Feature diagrams: A survey and a formal semantics. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE 2006), pages 136–145. IEEE Computer Society, 2006.
6 Conclusion We have sketched a possible framework for applying feature modeling in complex system families, tailored to the specific challenges faced in these domains, namely heterogeneity of development methods and tools, high degree of collaboration not only between departments and projects but also between companies and diverging life-cycles of subsystems. From that, we deduced several requirements for feature modeling techniques to be employed in such a context. These requirements are all based on the central demand that the feature models be as flexible as possible, in order to cover as many proprietary variability modeling and specification techniques as possible. Thus, feature modeling techniques that meet all these requirements could be referred to as unified feature modeling techniques. We believe that these requirements are a useful instrument that can help guide further research in this field to improve the suitability of feature modeling for developing complex families of software intensive systems.
References [1] T. Asikainen, T. M¨annist¨o, and T. Soininen. A unified conceptual foundadtion for feature modelling. In 10th International Software Product Line Conference (SPLC 2006), pages 31–40, 2006. [2] Atesst project web-site. www.atesst.org. [3] Autosar project web-site. www.autosar.org. [4] D. Batory. Feature models, grammars, and propositional formulas. Technical Report TR-05-14, University of Texas at Austin, March 2005.
85
[22] J. van Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), 2001. [23] R. van Ommering. Building Product Populations with Software Components. PhD thesis, University of Groningen, 2004. [24] D. M. Weiss and C. T. R. Lai. Software Product-Line Engineering: A Family-Based Software Development Process. Addison-Wesley, 1999.
86
Adding Aspects to xADL 2.0 for Software Product Line Architectures* Lidia Fuentes, Nadia Gámez Dept. of Computer Science, University of Málaga, Spain {lff,nadia}@lcc.uma.es
commonalities and variabilities inside product line architectures. However, crosscutting variables features and dependencies between features are commonly found during a feature-oriented analysis. In [14] it is proposed to combine feature-oriented analysis and AspectOriented Programming (AOP), to solve the problem of crosscutting variables features and dependencies between features. Aspect-Oriented Software Development (AOSD) promotes the separation of concerns at every stage of the software lifecycle, from requirements and architectural design (early aspects) to implementation. Therefore, instead of generating an implementation in AspectJ directly from a feature model, it is better to specify the non-crosscutting and crosscutting features using an ADL first. The benefits of doing so are, that the software architect can manage the evolution of crosscutting features and dependencies at architectural level; it is possible to reason and solve crosscutting feature dependencies before accomplishing the implementation task, which is less time consuming and error prone and, since the aspect-oriented architecture specification eradicates the crosscutting feature and dependencies problem, the implementation generated from it will be much simpler than for example considering the AspectJ implementation of [14]. This paper presents our proposal to combine AOSD and architectural aspects with FOA, instead of FOA and AOP, with the goal of improving the reusability, adaptability and configurability of product line architectures. We compare AspectJ implementation derived directly from FOA [14] with the specification of non-crosscutting and crosscutting features at architectural level. In order to represent product line architectures in an aspect oriented ADL we extend xADL 2.0 to incorporate aspects. We use the aspects and the product line facilities provided by xADL 2.0 therefore to separate the features that may crosscut modular units and to solve the dependencies. This paper is organized as follows. In Section 2, we present an overview of feature-oriented analysis, xADL
Abstract The Feature–Oriented approach provides a way of modelling commonalities and variabilities among products of a software product line. A feature model can be used as input for generating an architectural representation of a product line. Product line architectures can be specified using one of the architecture description languages that already supports the specification of commonalities and variabilities. xADL 2.0 is a highly-extensible XMLbased architecture description language that allows product lines architectures to be defined. But, in the process of generating the architecture from a feature model, several crosscutting variables features and dependencies between features are commonly found from a feature-oriented analysis. These features and dependencies can be modeled using an aspect-oriented architecture approach. In this paper we present how a xADL 2.0 extension with aspects can help represent the crosscutting variables features and the dependencies in product line architectures from a feature-oriented analysis.
1. Introduction The use of product lines [5] increases the reusability, adaptability and configurability of components and architectures. Software Product Line (SPL) promotes the notion of architecture centric software engineering [4]. Feature-Oriented Analysis (FOA) identifies commonalities and variabilities of the products of a product line in terms of features [14]. From a feature model it is possible to make an architectural representation of a product line. In order to represent Product Line Architectures (PLAs) one of the architecture description languages (ADLs) that supports the specification of PLAs, such as xADL 2.0, can be used. xADL 2.0 is a highly-extensible XMLbased ADL [8] that allows software architects to define _______________ *
This work has been supported by EC Grant IST-2-004349-NOE AOSD-Europe and AMPLE Grant IST-033710.
87
2.0 and AOSD. Problems to do with modelling features only with components are discussed in Section 3. Our approach is detailed in Section 4. And to validate it, we present the example shown in [14], at architectural level, in Section 5. In Section 6 we compare the AspectJ solution and our approach at architectural level. In section 7 the use of architectural description is presented. We discuss related work in Section 8 and Section 9 concludes this paper.
because the optionality is specified at structural level and variability at type level.
2.3. AOSD AOSD is a technology which improves separation of concerns, by encapsulating crosscutting concerns in modular units, called aspects. AOSD promotes the separation of crosscutting concerns at every stage of the lifecycle, from requirements and architectural design (early aspects) to implementation. According to AspectJ [2] terminology, the advice of an aspect defines its behaviour. This advice is executed when a certain join point is reached. A join point model defines the set of behaviors that can be intercepted by an aspect during the execution of the application. The set of join points intercepted by an aspect are specified as a set of predicates called pointcuts. The process of injecting aspect behavior into core elements is known as weaving.
2. Background 2.1. Feature-Oriented Analysis In the feature-oriented approach, commonalities and variabilities are analyzed in terms of features. These features are organized into a feature model that represents all possible products of a software product line. Variabilities are modeled as variable features which are classified as alternative or optional features. For each variable feature, feature dependency analysis identifies dependencies between features. At architectural level commonality and variability analysis is useful to separate the units of variations from the common part of the product line architecture. Dependency analysis can be used to encapsulate and localize the effects of a feature variation in other components of the product line architecture.
3. Addressing Crosscutting Feature Dependency at Architectural Level In the FOA approach a feature may intuitively correspond with an architectural component. But there are some features that crosscut other parts of the product line architecture, which drastically reduce reusability, adaptability and the evolution of a PLA. This problem is still worse for variable features of a family product. This means that a variable feature may affect other components of the PLA. In consequence all the components influenced by a variable feature have to be modified in accordance with this variation. Therefore, the benefits of separating variable features that crosscut several components and model them as aspects are evident. If we encapsulate a crosscutting variable feature in an aspect, we can specify different architectural configurations without modifying other components. There is another problem with variable features. If they are dependent on each other, their variation may produce chained changes affecting different base elements of the product line architecture. This problem is called invasive change. To solve this problem, the dependencies between features must be analyzed and separated from the other components. In [13] six kinds of dependencies are specified: • The Usage dependency means that a feature depends on other features for its correct functioning.
2.2. xADL 2.0 xADL 2.0 is a highly-extensible XML-based ADL that supports the specification of product line architectures. xADL 2.0 is built as a set of extensible schemas. The core of xADL 2.0 is the Structure and Types schema. The basic elements provided by this schema are the component and the connector with their interfaces, and the links between the interfaces. All elements (components, connectors and interfaces) are typed. xADL 2.0 is one of the ADLs that provides schemas to define product line architectures. The Options and Variants schemas extend the Structure and Types schema with variation points. The Version schema allows modelling the evolution of a PLA. A Boolean guard must be specified in an architectural element that is optional. This guard decides if an optional component or connector should be included in a particular product architecture. Mutually exclusive Boolean guards describe which component or connector type (variant type) should be used in a given product architecture. Combined optional variant elements are supported by xADL 2.0,
88
• The Modification dependency occurs when the behaviour of a feature may be modified by other feature. • Exclusive-Activation dependency happens when different features must not be active at the same time. • Subordinate-Activation dependency occurs when a feature can be active only if another specific feature is also active. • Concurrent-Activation dependency means that some subordinators of a superior (in a Subordinate-Activation dependency) must be active concurrently while the superior is active. • Sequential-Activation dependency denotes that some subordinators of a superior must be active in sequence. To encapsulate and separate these dependencies we can use aspects. Thus, the impact of changes in a chain of variable features can be easily localized.
4. xADL 2.0 Extension for Product Line Architecture with Aspects
Figure 1. ComponentDAOPType XML Schema.
In our approach we incorporate aspects into xADL 2.0 to solve the above problems at architectural level. Then, in this section we present how aspects are incorporated into xADL 2.0. We will show how with this architecture description language we can represent product line architectures without the problems of crosscutting variable features and invasive change.
The ProvidedInterfaceType shows the messages that the component provides. The RequiredInterfaceType has the messages that the component requires from another component (the target component). The EventInterfaceType specifies the events that the component can throw. The EvaluatedInterfaceType is relative to the aspectual behavior. This interface defines the messages, events, component creation and component destruction (i.e. the joinpoints) that the aspectual component can intercept and when. Finally, the ConnectorType is extended to an AspectualConnectorType. This type encapsulates the composition rules (pointcut definition) between components and aspects. These rules define how and when aspects are applied to components. A composition rule consists of two parts: the joinpoint captured and the aspects that have to be applied when this joinpoint is intercepted. The AspectualConnectorType defines a rule for every message sent, event thrown, created or destroyed component intercepted. This extended type is shown in Figure 2.
4.1. Adding Aspects to xADL 2.0 In previous work [9] we extended xADL 2.0 with aspects incorporating the DAOP-ADL language constructions [19]. In this extension, the ComponentType, InterfaceType and ConnectorType are extended and a new element is incorporated. This new element is the property. The properties are used to encapsulate shared data that has to be accessed from different components and aspects. The VariantComponentType (that is the xADL 2.0 extension for variant component types) is extended to incorporate the properties that it uses and its state attributes. This component type called ComponentDAOPType is show in Figure 1. The InterfaceType is extended to specify if it is a ProvidedInterfaceType, RequiredInterfaceType, EventInterfaceType for components or EvaluatedInterfaceType for aspectual components.
89
The problem with the Usage dependency can be formulated at architectural level where common component makes use of a variable component. Then, in products where the variable component is not needed, the common component has to be modified. Table 1. Mapping between FOA features and xADL 2.0 with aspects. FOA
xADL 2.0 with aspects
Non crosscutting common feature.
Structure: Component. Type: Extended ComponentType with its own provided, required and event interfaces. Structure: Component. Type: Extended ComponentType with an evaluated interface (aspectual component). There will be an aspectual connector to specify the pointcuts of this aspect. Structure: OptionalComponent with a guard. Type: Extended ComponentType with its own provided, required and event interfaces. Structure: Component. Type: Extended ComponentType with the mutually exclusive guards and its variants sub-features types. Structure: OptionalComponent with a guard. Type: Extended ComponentType with an evaluated interface (aspectual component). There will be an aspectual connector to specify the pointcuts of this aspect. Structure: Component Type: Extended ComponentType with the mutually exclusive guards and its variant sub-features types There will be an aspectual connector to specify the pointcuts of this aspect.
Crosscutting common feature.
Figure 2. AspectualConnectorType XML Schema.
Non crosscutting variable feature: optional feature.
4.2. Mapping FOA to xADL 2.0 Extension with Aspects
Non crosscutting variable feature: variant feature.
AOSD promotes the separation of concerns at every stage of the lifecycle. In the context of SPLs, the commonalities will be decoupled from variabilities, because common features will be the base modular components and variable features will be aspectual components, which adapt or extend the base modular components. But common features that crosscut other parts of the architecture can also be modelled as aspects. As commented in previous sections, the effects of the variations of crosscutting variables features can be minimized by modeling such features in separate entities as aspectual components. In this way, this variable feature can be incorporated into the product line in an additive way without modifying any other components of the product line architecture. Variable features that do not crosscut other components can be designed as components. Table 1 describes how the features of feature models can be mapped to architectural elements in the aspect-oriented extension of xADL 2.0. Dependencies among features have to be taken into account at architectural level to avoid the invasive changes problem. These dependencies must be analyzed and separated from other components of the architecture. Each kind of dependency can be treated to be encapsulated in an aspectual component to facilitate the localization of the effects of a feature variation (See Table 2).
Crosscutting variable feature: optional feature.
Crosscutting variable feature: variant feature.
Something similar happens with the Modification dependency. The problem occurs when the common component being modified depends on a variable component. Such dependencies are solved by reversing dependencies, i.e. by modelling the variable component as an aspect, the dependency from common components to variable component is reversed to a dependency from the variable component (aspectual component) to the common component. Others dependencies can be grouped as Activation dependencies. This kind of dependency is solved using the properties of the proposed ADL (see Table 2). Therefore, using aspectual components and properties we solve the dependencies between features without affecting other components, as is shown in Table 2. This table describes how the dependencies
90
between features can be solved with architectural elements in the aspect-oriented extension of xADL 2.0.
Regarding the dependencies, the Collision Avoidance feature must be active only while the Navigation Control feature is active. Then, they have a Subordinate-Activation dependency. Another dependency is found if the Manipulation feature is incorporated. When the robot is manipulating something (e.g. opening the fridge) the Collision Avoidance may detect this thing (the fridge) as an obstacle. This detection is not correct. Then Manipulation and Collision Avoidance features must not be active simultaneously.
Table 2. Mapping between FOA dependencies and xADL 2.0 with aspects. FOA dependency
xADL 2.0 with aspects
Explanation
Usage: common component makes use of a variable component.
Model the common component as a common feature (Table 1). Model the variable component as a crosscutting variable feature (Table 1).
Reversing dependencies: variable aspectual components make use of the common component.
Modification: common component being modified depends on variable component.
Model the common component as a common feature (Table 1). Model the variable component as a crosscutting variable feature (Table 1).
Reversing dependencies: the modifications are managed in the variable aspectual component instead of in the common component.
Activations dependencies.
A Property stores whether a feature is active or not.
That property must be checked in the guard of the variable aspectual component to activate it or not.
Figure 3. The partial feature model of the Service Robot product line.
5.1. Service Robot Product Line in xADL 2.0 Figure 4 shows the diagram for the architecture of Service Robot Product Line (we will use similar diagrams to those used by xADL 2.0 authors instead of XML schemas which are not very readable). Solid boxes are the core components (common features) and dashed boxes indicate optional components (optional features). The ovals are the component interfaces, and the dashed ovals represent the interface that depends on the optional component. The connectors are omitted at this point for the sake of simplicity. The xADL 2.0 architecture of this product line consists of three regular components and one optional component. If Collision Avoidance is not selected, the NavigationControl component has two required interfaces. From the SensorInterface component, the readSensor message is required and from the WheelActuatorInterface, moveWheel and stopWheel are required. The SensorInterface component provides the readSensor message. And the WheelActuatorInterface provides moveWheel and stopWheel messages. If Collision Avoidance is selected, some components have to be modified by adding some interfaces. Collision Avoidance features affect Navigation Control and Wheel Actuator features. Then, NavigationControl and WheelActuatorInterface components have to be modified. The
5. Case Study To validate our approach we use the case study shown in [14] but at architectural level, instead of at implementation level. This example is an intelligent service robot product line that is specified in [12]. Figure 3 depicts a minimized feature model with the features used in the case study. The Auto Navigation feature enables a user to order the robot to move to a specific position. To do so, the Navigation Control executes a previously formulated path plan, and the Sensors are constantly read. The optional sub feature Collision Avoidance allows emerging obstacles to be avoided. With the Errand Service the robot can manipulate things, carry objects, and so on. The variable feature Collision Avoidance affects the Navigation Control and Wheel Actuator component. If the optional feature Collision Avoidance is selected, the Navigation Control component has to be changed by adding collision detection and emergency stop functions. The Wheel Actuator component has to be changed by adding the function emergency stop wheel.
91
CollisionAvoidance component has three messages in its provided interface: detectCollision, emergentStop and emergentStopWheel. Therefore, we have to add a required interface in the NavigationControl component with the detectCollision, and emergentStop messages. In WheelActuatorInterface a required interface is added with the emergentStopWheel message.
5.2. Service Robot Product Line in xADL 2.0 with Aspects In order to validate our approach, we will show in the same example but now using aspects, how components affected by crosscutting variable features do not have to be changed. In accordance with the mapping, the crosscutting variable features are modeled as aspects. In the example, the variable feature is an optional feature, and so, the fifth rule of table 1 must be followed. For the dependencies we use table 2. In the study case there are two Activation dependencies which are solved using properties. Figure 5 shows the Diagram for a Robot Service Product Line with components, aspects and aspectual connectors. In this case, the architectural components are not modified depending on Collision Avoidance is selected or not. There are three regular components (mapping rule for non crosscutting common features), one optional aspectual component and one aspectual connector (mapping rule for crosscutting variable features).
Figure 4. Diagram for a Robot Service Product Line only with components. With this example we show that some components have to be changed depending on the variation of a variable feature. The selection of the optional component CollisionAvoidance provokes changes in NavigationControl and WheelActuatorInterface. The second problem we are studying is the dependency between features. In this example we have two dependencies: a Subordinate-Activation between Collision Avoidance and Navigation Control features, and an Exclusive-Activation between Collision Avoidance and Manipulation features. For both dependencies the CollisionAvoidance components requires messages to know if NavigationControl and Manipulation are active. Then, those components have to provide those messages. For example, as is shown in Figure 4, the NavigationControl component must add to its provided interface a message called isNavigating. The CollisionAvoidance must incorporate a required interface with target NavigationControl to require the isNavigating message. The same thing happen with the Manipulation component, this dependency is not shown in Figure 4. Again, some components have to be modified to solve the dependencies.
Figure 5. Diagram for a Robot Service Product Line with components and aspects. The NavigationControl, WheelActuatorInterface and SensorInterface components have the same interfaces as in the xADL 2.0 version when Collision Avoidance is not selected. The CollisionAvoidance is an OptionalComponent with a guard to check if this optional feature is selected or not. The ComponentType of this structure has one
92
isManipulating false
evaluated interface with joinpoint ANY, i.e. any pointcut that is specified in the AspectualConnector. The AspectualConnector has to capture the message readSensor sent by NavigationControl to SensorInterface. After this message is sent, the CollisionAvoidance aspectual component has to be executed. This aspectual component is responsible for detecting a collision and when the robot comes across an obstacle it has to stop suddenly (emergency stop and wheel emergency stop). This abbreviated XML fragment represents the AspectualConnector (some tags are omitted for the sake of clarity):
Again, we solve the dependencies between features using aspects and without modifying other parts of the architecture. The crosscutting variables features and the dependencies are encapsulated in aspects and in the aspectual connector. In addition, component interfaces of both common and variable components are much simpler than in a non-AO approach.
navigationControl sensorInterface
6. AO Architecture vs AspectJ Based Solutions In the case study of [14] each common feature is implemented as a Java class. These classes are later modified using AspectJ aspects. AspectJ aspects are used both to implement crosscutting variables features and to solve different kind of dependencies. They make use of some advanced aspect-oriented extension/adaptation methods very specific to the AspectJ language such as the inter-type mechanisms. At architectural level components are considered mostly black-box elements, and specifically in our extension of xADL 2.0 with aspects, we follow this approach for both components and aspectual components. This means that the definition of join points that intercept this internal behaviour of components is deliberatelly avoided. Therefore, the inter-type and other invasive AspectJ mechanisms are not present at architectural level in either traditional ADLs or in xADL 2.0 extension with aspects. But these mechanisms are not necessary when the separation of concerns is tackled at architectural level and not at implementation level. Since the aspect-oriented architecture specification eradicates crosscutting features and the dependencies problem, the implementation generated from it will be much simpler than in the case study of [14]. In order to illustrate this, we will compare the AspectJ implementation of the robot system product line described in FOA [14] and the equivalent architectural specification using the xADL 2.0 extension with aspects. This comparison is shown in Table 3.
Using our approach, to solve the SubordinateActivation dependency, nothing has to be done by the software architect. The reason is that the CollisionAvoidance is only executed when NavigationControl sends the readSensor message. And this is possible only if the NavigationControl is active. For the Exclusive-Activation we can use the properties of our ADL. There will be a boolean property called isManipulating, which is true when the robot is manipulating something and false in any other case. This property will be consulted in the CollisionAvoidance guard. Then the CollisionAvoidance will be active when the Collision Avoidance feature is selected and the robot is not manipulating anything. The guard of this optional aspectual component is shown in the following abbreviated-XML description: hasCollisionAvoidance true
93
In the AspectJ implementation the problem with the crosscutting variable feature Collision Avoidance is solved using inter-type mechanisms to extend the class that implements the Navigation Control feature with two methods. The WheelActuatorInterface component also affected by this variable feature is extended in the same way by adding the method to stop the wheel in an emergency. This is a heterogeneous crosscut, because it extends multiple join points by adding multiple extensions, where each individual extension is implemented by a different piece of code that affects exactly one join point [6]. For example, an aspect bundles a set of inter-type declarations – each intended for a different class [1]. Heterogeneous crosscuts which extend only methods and classes, OOP techniques for collaboration-based designs suffice [1], instead of inter-type mechanisms. In our approach this is not a proper mechanism. Instead we implement these three methods separately from the beginning in the CollisionAvoidance aspectual component. In the pointcuts defined in this Aspectual Connector we specify, precisely at which point of the execution these three methods have to be executed. The Subordinate-dependecy between Collision Avoidance and Navigation control is specified in the AspectJ implementation as part of an execution object pointcut CollisionAvoider of the CollisionAvoidance aspect. In this pointcut the start method of the Controller is captured (the component that implements the Navigation Control feature in AspectJ) to add the three methods using the inter-type mechanism. Similary, in our case study we define the pointcut to capture the message readSensor in the aspectual connector. The message readSensor is captured because the collision detection must to be constantly checked when the sensor is read. Finally, the Exclusive–dependency between Collision Avoidance and Manipulation features are solved using the AspectJ mechanism cflow in the CollisionAvoider pointcut. In our approach this dependency is solved using a property called isManipulating which is checked in order to know whether Collision Avoidance should be activated or not. This property is consulted in the guard of the CollisionAvoidance optional aspectual component. With this comparison we demonstrate how the separation of crosscutting concerns at architectural level, instead of postponing it until the implementation level, makes the use of complicated mechanisms of a particular aspect language like AspectJ unnecessary. As an alternative, we use simpler mechanisms in an architecture description language that can be
implemented in only aspect oriented implementation language or even plain Java. Table 3. Solutions for the crosscutting features or dependencies. Crosscutting feature or dependency Crosscutting variable feature Collision Avoidance.
Subordinatedependecy between Collision Avoidance and Navigation control.
Exclusive– dependency between Collision Avoidance and Manipulation.
Implementation Solution (AspectJ) vs Architectural Solution (xADL 2.0 with aspects) public aspect CollisionAvoidance{ … public int Controller.detectCollision (SensorData data){ …} public int Contoller.emergentStop (int nObstacleCnt){ …} public int WheelActuatorInterface. emergentStopWheel(){ …} … public aspect CollisionAvoidance{ … pointcut collisionAvoider(Controller cont): call(boolean start(..) && this(cont); …} … … pointcut collisionAvoider(Controller cont): call(boolean start(..)) && this(cont) && ! cflow(manipulator()); … isManipulating false …
7. Using the Product Line Architecture Description The architectural representation is very useful to the development of a product line asset. Instead of generating the code from the feature models if an architectural description of a product line is made, a selection of a particular product can be created. From this selection an architectural description of one product is obtained. And an application can be generated using this description. To get the generation several options are available. For example, an
94
architectural based weaver can be used or the weaving can be done in AspectJ style. In the first option, an architectural based weaver can interpret the XML file containing the representation of the architecture in xADL 2.0 with aspects. The implementation of the components and the aspectual components will be regular Java classes and not AspectJ classes. The interpreter reads the XML file, and extracts information about the components, aspects and the composition rules between components and aspects. Then, when a component sends a message, event, etc., that has to be intercepted by an aspect, the interpreter calls the aspect to do its execution. The other option makes use of two tools. One for generate skeleton of Java classes from the components and aspects interfaces described in the XML files, and the other tool will be a preprocessor that will take these classes and the compositions rules between components and aspects described in the XML file. Using the classes and the composition rules, the preprocessor will do the weaving in AspectJ style and generate the new Java classes. Using these generations we get a plain Java aspectoriented implementation without using proper mechanisms of any aspect-oriented programming language. Our group has some experience in both options. DAOP (Dynamic Aspect-Oriented Platform) [18] is a distributed component and aspect based platform that uses the information provided by DAOP-ADL language at runtime. It provides a dynamic composition mechanism that plugs software aspects into components at runtime. For the second option we are implementing a code generator to get skeleton code from the architecture description defined in the extension of xADL 2.0 with aspects.
implementation level approach is [15], in which AOP, frame technology and feature-oriented domain analysis are combined. Griss [11] outlines a systematic, feature-driven, aspect-oriented component-based product line development approach. In this conceptual framework no architectural description language for the architectural design stage is specified. In [16] feature models for aspect-oriented product lines are generated from requirements documents. Alternatively in our approach we make use of the features models to generate architectural descriptions. Dashofy et al [8] define an ADL that is useful to describe product line architectures. We extend this language to incorporate aspects and represent product line architectures using aspects. There are other ADLs that support the specification of PLAs, like Koala [20], Mae [21], GenVoca[3] and to some extent Acme[10]. However none of these languages have the aspect or the aspectual composition in their constructors. In [7] the development of an Aspect Oriented Product Line Architecting methodology is justified. By incorporating an aspect-oriented approach (Early Aspects) in the design of product line architecture, crosscutting concerns will be properly identified and included into the product line architecture.
9. Conclusion We have presented throughout this paper a mapping between feature-oriented analysis and an extension of xADL 2.0 with aspects for product line development. We have shown the problems with modeling only with components the crosscutting variables features and the dependencies among features and how the aspects could solve them. Since aspect-oriented implementations are complicates some pointcuts are not intuitive for the programmers. In addition, each aspect-oriented language can provide different solutions for the same thing. We propose therefore to do the separation of crosscutting features at architectural level, using an aspect-oriented ADL for SPLs. In order to show the benefits of specifying the noncrosscutting and crosscutting features at architectural level, instead of generating an implementation in AspectJ directly from a feature model, we have specified the case study of [14] in the extension of xADL 2.0 with aspects and we have compared both solutions. From this comparison we have been able to observe that generating the aspect-oriented implementation directly from feature models is more
8. Related Works This approach makes use of two previous works [14] and [8]. Lee et al [14] combine FOA and AOP for product line asset development. We use this approach at architectural design level to do the mapping from FOA to xADL 2.0 with aspects. Other approaches also apply aspect technology for improving the product lines development. Mezini et al [17] present Caesar, a language which combines concepts from AspectJ and feature-oriented approaches. Likewise in this paper, these authors discuss the importance of crosscutting modularity support for variability management. But this proposal is limited to the implementation level. Another
95
complicated than if an aspect-oriented architectural representation in an ADL is performed beforehand.
[13] K. Lee and K. C. Kang, Feature Dependency Analysis for Product Line Component Design, Lecture Notes in Computer Science, Vol. LNCS 3107, 2004, pp.69-85.
10. References
[14] K. Lee, K. C. Kang, M. Kim, Combining FeatureOriented Analysis and Aspect-Oriented Programming for Product Line Asset Development, Proceedings of the 10th International Software Product Line Conference, 2006.
[1] S. Apel, D. Batory, M. Rosenmüller. On the Structure of Crosscutting Concerns: Using Aspects or Collaborations? In Proceedings of GPCE Workshop on Aspect-Oriented Product Line Engineering (AOPLE'06), Portland, Oregon, October 2006, to appear. [2] AspectJ Team, http://www.eclipse.org/aspectj/.
“AspectJ
[15] N. Loughran and A. Rashid, Framed Aspects: Supporting Variability and Configurability for AOP, Proceedings of 8th International Conference on Software Reuse, Madrid, Spain, 2004, pp. 127-140.
Project”,
[3] D. Batory , B.J. Geraci, Composition Validation and Subjectivity in GenVoca Generators. IEEE Transactions on Software Engineering, 1997. 23(2): p. 67-82.
[16] N. Loughran, A. Sampaio, A. Rashid, From Requirements Documents to Feature Models for Aspect Oriented Product Line Implementation, Workshop on MDD in Product Lines, 2005.
[4] J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, AddisonWesley, New York, New York, 2000.
[17] M. Mezini and K. Ostermann, Variability Management with Feature-Oriented Programming and Aspects, Proceedings of 12th ACM SIGSOFT International Symposium on Foundations of Software Engineering, Newport Beach, CA, 2004, pp. 127-136.
[5] P. Clements, L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, New York, New York, 2002.
[18]M. Pinto, L. Fuentes, J.M. Troya, A Component and Aspect Dynamic Platform, The Computer Journal 2005 48(4):401-420
[6] A. Colyer, A. Rashid, and G. Blair, On the Separation of Concerns in Program Families, Technical report, Computing Department, Lancaster University, 2004.
[19] M. Pinto, L. Fuentes, J.M. Troya, DAOP-ADL: An architecture description language for dynamic component and aspect-based development, GPCE 2003, LNCS 2830, pp. 118-137, sep 2003, Erfurt, Germany.
[7] K. Cortes, C. Lemus, Assessment of Product Line Architecture and AspectOriented Software Architecture Methods, In Proceedings of GPCE Workshop on AspectOriented Product Line Engineering (AOPLE'06), Portland, Oregon, October 2006, to appear.
[20] R. van Ommering, et al., The Koala Component Model for Consumer Electronics Software. Computer, 2000. 33(3): p.78-85.
[8] E. Dashofy, A. van der Hoek, R. Taylor, A Comprehensive Approach for the Development of Modular Software Architecture Description Languages, ACM Transactions on Software Engineering and Methodology, Vol. 14, No. 2, April 2005, Pages 199–245.
[21] A. van der Hoek, A., et al., Taming Architectural Evolution, in Proceedings of the Joint 8th European Software Engineering Conference and 9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering, 2001.
[9] L. Fuentes, N. Gámez, M.Pinto, DAOPxADL: Una extensión del lenguaje de descripción de arquitecturas xADL con aspectos, Proceedings of DSOA 2006. (Only in spanish). [10] D. Garlan, R. Monroe, and D. Wile, ACME: An Architecture Description Interchange Language, in Proceedings of CASCON’97. 1997. [11] M. L. Griss, Implementing Product-Line Features by Composing Aspects, Proceedings of First Software Product Line Conference, Denver, Colorado, 2000, pp 271-288. [12] M. Kim, S. Kim, S. Park, M. Choi, M. Kim, H. Gomaa, UML-Based Service Robot Software Development: A Case Study, Proceedings of the International Conference on Software Engineering, 2006.
96
Language and UML Support for Features: Two Research Challenges Roberto E. Lopez-Herrejon Computing Laboratory Oxford University Oxford, England, OX1 3QD
[email protected]
We believe that providing language support for features and extending UML can help remedy the feature abstraction loss in the modeling and implementation activities of product line development.
Abstract Features have been recognized as important building blocks of software product lines. Unfortunately, features have been mostly confined to modeling activities as they were originally conceived by Kang and his group in the early 90’s. In this paper we address the negative impact this has had on product line development and how research on programming languages and UML support for features can help.
2 Language Support For Features There are many definitions of the concept of feature in the product lines research literature [8][10][11][15][16][26][31] [33]. All these notions of features are valid and more relevant for different stages of product line development or for different product line methodologies. For this paper we regard features as increments in program functionality [33]. This definition afford us to focus on the implementation issues of features.
1 Introduction Features have been recognized as important building blocks of software product lines. Unfortunately, features have been mostly confined to modeling activities of product lines as they were originally conceived by Kang and his group in the early 90’s [15].
We developed a simple case study to evaluate support for features in novel modularization technologies. In this section, we briefly describe the domain problem and the evaluation criteria used, and summarize the results. For further details on the study please refer to [19][21].
The negative consequence is that the abstraction level gained by features is lost throughout Domain and Application Engineering activities. This abstraction loss complicates product line development and evolution as multiple artificial mechanisms are required to trace features at different activities.
Our case study, the Expressions Product Line (EPL), is based on the extensibility problem also known as the “expression problem” [9][30]. It is a fundamental problem of software design that consists of extending a data abstraction to support a mix of new operations and data representations. It has been studied within the context of programming language design, where the focus is achieving data type and operation extensibility in a type-safe manner. Instead, our focus is on the design and synthesis aspects of the problem to produce a family of program variations.
A place where this is acute is at the implementation level where multiple mechanisms have been put in place to help implement features [4][8][10][21]. Examples are preprocessors and frame technology that, though alleviate some of the problems, do not provide the robust support (i.e. type checking, debugging, etc.) for features as a programming languages would do. In recent years there has been an extensive research in modularization technologies that address some of the limitations of Object Oriented Programming and that can potentially improve the support for features at the programming language level. In this paper we summarize the results we obtained from a survey of sixteen of these modularization technologies.
EPL consists with six features, implemented with 66 Java lines of code in total, and that can synthesize 22 different product line members. Though deceivingly small, EPL allowed us to illustrate and identify a basic set of properties that the features that implement EPL should provide. These properties guided our evaluation. They are categorized into definition and composition properties as explained next.
Modeling is a crucial activity of any software system and it is even more critical in the context of product lines. There are many modeling techniques but without doubt one of the most popular ones is OMG’s Unified Modeling Language (UML) [28]. Not surprisingly, there have been multiple efforts to extend UML for product line modeling. In this paper we present preliminary results of an ongoing analysis of extensions of UML to support feature modeling.
Definition Properties. The first category relates to the definition of the basic building blocks of EPL, the representation of each piece, and their organization into features. • Program deltas. Program deltas are the program fragments that a feature can modularize. For example,
97
• Separate compilation. Separate compilation of features is important for two reasons: a) feature debugging (catching syntax errors), and b) distribution of bytecode. Composition Properties. The second category describes the basic properties that the composition mechanisms of modularization technologies should provide. • Flexible Composition. The implementation of a feature should be syntactically independent of the composition in which it is used. In other words, a fixed composition should not be hardwired into a feature module. Flexible composition improves reusability of modules for constructing a family of programs. • Flexible Order. The order in which features are composed can affect the resulting program. Hence, features should be composable in different orders. • Closure under Composition. Feature are closed under composition if one or more features can be composed to make a new composite feature. Composite features must be usable in all contexts where basic features are allowed. • Static Typing. Features and their composition are subject to static typing which helps to ensure that both are well-defined, for instance detecting errors such as methods not found. We evaluated this property on the availability of a formal or semi-formal theory or mechanism. We evaluated with these properties sixteen modularization technologies. Our study showed that only six of them had adequate tool support to implement EPL. We first present the results of these six technologies followed by an overview of the remaining ten. The results of the implementation of EPL are summarized in Figure 1. The technologies capable of implementing EPL were: • AspectJ. It is the flagship tool of Aspect Oriented Programming (AOP), a paradigm whose goal is modularizing so-called crosscutting concerns [3][17]. AspectJ cannot add new classes thus it partially supports program deltas property, and does not support cohesion. It does not support separate compilation because the AspectJ compiler requires base code to weave aspects to. Static typing of aspects is an area of active research.
98
• Jiazzi [23]. It is a component system that implements units in Java which containers of classes and interfaces. The drawback of this technology is its verbose and convoluted mechanism to describe compilation by wiring unit interfaces. • Scala [24]. Scala is a strongly-typed language that fuses concepts from object-oriented programming and functional programming. It supports two nontraditional modularization mechanisms: traits and mixins. A trait in Scala can be regarded as an abstract class without state and parameterized constructors, whereas a mixin is a class whose superclass is undefined. The drawback of this technology is its verbose and non-trivial composition specification. • CaesarJ [2]. It is an aspect oriented language that merges concepts of collaboration-based designs [27], mixins, aspects, and virtual classes [18] into modules called class families. CaesarJ uses AspectJ to implement its advice so it also does not support separate compilation. Its mixin composition algorithm does not permit to easily infer the order in which their class families should be specified for composition, something which limits its order flexibility. • AHEAD [1][7]. It is a feature modularization and composition technology based on step-wise development that was created to address the issues of feature-based development of product lines. This technology does not support separate compilation and does not have a static typing theory behind it.
pe c Hy tJ pe Jia r/J zz i Sc al a AH EA Ca D es ar J
• Cohesion. The capacity to collect a set of program deltas and assign them a name so that they can be identified and manipulated as a cohesive entity.
• Hyper/J [25]. It is the Java implementation of an approach to Multi-Dimensional Separation of Concerns (MDSoC) called Hyperspaces. This technology partially supports separate compilation as their modularization units must be completed manually for compilation, and does not have any type theory to provide static typing.
As
classes, interfaces, new methods, fields, etc.
9
9
9
9
9
9
U U
Program deltas
±
9
9
9
Cohesion
U
9
9
Separate compilation
U
±
±
Flexible composition
9
9
9
±
9
Flexible order
9
9
9
9
9
±
Closure under composition
U
9
9
9
9
9
Static typing
±
U
9
9
U
9
9 property supported
U property not supported
9
± incomplete or verbose
Figure 1. Implementation Summary
We also evaluated other ten technologies. Here we highlight the main characteristics of them, for further details please refer to [21]. • MultiJava. It is an extension of Java that supports symmetric multiple dispatch and modular open classes. It does not support all program deltas that EPL requires. • Classboxes. This technology provides modules implemented as packages of classes that allow to add new classes and refine existing ones. It does not support all program deltas and its composition mechanism is not flexible. • Difference-Based Modules. This technology is based on collaborations [27]. It cannot implement all the program deltas of EPL, does not provide true separate compilation, modules are not closed under composition, and do not have a model of static typing. • Object Teams. This technology is also based on collaborations [27]. The only program delta of EPL not supported by teams is constructor extensions. The relationships between teams are hardwired, and teams are not closed under composition. We are unaware of any model of static typing. • Aspectual Collaborations. It is also a technology based on collaborations whose goal is to reconcile modules and aspects. They don’t provide support for all program deltas of EPL, but they support separate compilation, provide flexible composition and order, are closed under composition, and have a model for static typing. • Delegation Layers. It is also another technology based on collaborations. Its goal is to scale Object Oriented mechanisms such as delegation, late binding, and subtype polymorphism to sets of collaborating objects. Delegation layers appear to be able to implement all program deltas of EPL but it is unclear how they would support constructor extensions. Delegation layers do not have a flexible composition and order, are not closed under composition, do not have a model of static typing. • Aspectual Mixin Layers. This approach capitalizes on the strengths of Feature Oriented Programming (FOP) [1][7] and AOP. In this context, features are mixin layers that contain mixin classes and aspects that can also refine pointcuts and pieces of advice. A prototype tool is under development. • Classpects. They attempt at unifying aspects and classes. They do not provide support for feature cohesion, are not compiled separately, and are not
99
closed under composition. We are unaware of any static typing model. • Open Modules. A common criticism of AOP is the unrestricted capability of aspects to break standard modularization properties such as encapsulation and modular reasoning. Open Modules address this issue by providing a module system on top of aspects to specify methods and pointcuts to which client programs can apply advice. Because it is based on AspectJ, its evaluation is similar to the evaluation of AspectJ with an improvement in feature cohesion. • Framed Aspects. This technology merges frames and AOP. AOP is used to modularize crosscutting concerns while frame technology is utilized for configuration, validation and variability via parameterization, conditional compilation and code generation. This approach relies on AOP languages so its evaluation is similar to that of those languages.
3 UML Support For Features In this section we present preliminary results of an ongoing analysis of literature about extensions of UML to support feature modeling. Product Line UML-based Software engineering (PLUS) [11][12] is a method that brings FODA [15] ideas to the realm of UML. PLUS models features as packages of use cases that are stereotyped with the kind of feature they implement such as optional, alternative, etc. Though this method uses features throughout the entire product line development process, their boundaries are lost in the modeling diagrams. In other words, the diagrams in this approach show elements that either belong to all the product line or to those of a particular product configuration (i.e. a selected set of features). This effectively hinders traceability of features at the different activities of the development process. Jayaraman and Whittle have also recognized this shortcoming which they try to address in their work on feature slices, collections of fragments of UML diagrams whose composition is performed via graph transformations [14][32]. To the best of our knowledge PLUS and feature slices do not currently have tool support. Ziadi and Jézéquel describe extensions to model variability in class and sequence diagrams and an algorithm for product derivation based on UML model transformations [34]. We are unaware of any efforts to extend this line of work to other types of diagrams or to other activities in the product line development process. Recently, there has been an extensive research in applying aspect oriented ideas to product line development specially at the modeling stages. We performed an exploratory study on how use case slices, a technique proposed by Jacobson
and Ng that applies AspectJ aspect ideas to use cases, could be used to model features [22]. Our study showed that use case slices lack a clear and concise composition model. This result is in part due to the support limitations to compose features of AspectJ [20]. We are currently investigating if other aspect modeling approaches such as Theme could be used for feature modeling [5].
4 Conclusions and Future Work In this paper we described the shortcomings of novel modularization technologies to support features and the negative consequences it has on product line implementation. We briefly touched on work that extends UML to support feature variability modeling. We argued that providing language support for features and extending UML can help remedy the feature abstraction loss in the modeling and implementation activities of product line development. We are working on a UML profile extension to support Feature Oriented Programming [7] along the lines of the one proposed in [29]. We also plan to evaluate other promising language technologies.
5 References [1] AHEAD Tool Suite (ATS). http://www.cs.utexas.edu/users/ schwartz [2] I. Aracic, V. Gasiunas, M. Mezini, K. Ostermann. An Overview of CaesarJ. Transactions on AOSD, Vol. 1 (2006) [3] AspectJ Manual. http://eclipse.org/aspectj/doc/progguide/ language.html [4] M. Anastasopoulus, C. Gacek. Implementing Product Line Variabilities. SSR (2001) [5] E.L.A Baniassad, S. Clarke. Theme: An Approach for Aspect-Oriented Analysis and Design. ICSE (2004) [6] D. Batory, R. Cardone, and Y. Smaragdakis. Object-Oriented Frameworks and Product-Lines. SPLC (2000) [7] D. Batory, J.N. Sarvela, and A. Rauschmayer. Scaling StepWise Refinement. IEEE TSE, June 2004 [8] P. Clements, L. Northrop. Software product lines: practices and patterns. Addison-Wesley (2002) [9] W. R. Cook. Object-Oriented Programming versus Abstract Data Types. Workshop on FOOL, Lecture Notes in Computer Science, Vol. 173. Spring-Verlag, (1990) 151-178 [10] K. Czarnecki, and U.W. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, (2000) [11] H. Gomaa. Designing Software Product Lines with UML. From Use Cases to Pattern-Based Software Architectures. Addison-Wesley (2004) [12] H. Gomaa. Software Product Lines with UML. Tutorial Notes. MoDELS Conference (2006) [13] I. Jacobson, P. Ng. Aspect-Oriented Software Development with Use Cases. Addison-Wewley (2004)
100
[14] P. K. Jayaraman, J. Whittle. Models, Aspects and Product Lines: What kind of composition do we need?. AMPLE Launch Workshop. Lancaster University, November 1 (2006) [15] K. Kang, et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study. CMU/SEI-90-TR-21, Carnegie Mellon Univ., Pittsburgh, PA, Nov. (1990) [16] K. Kang, J. Lee, P. Donohoe. Feature-Oriented Product Line Engineering. IEEE Software, Vol. 19, No.4 (2002) [17] G. Kiczales, E Hilsdale, J. Hugunin, M. Kirsten, J. Palm, W.G. Griswold. An overview of AspectJ. ECOOP (2001) [18] O. Lehrmann Madsen, B. Moller-Pedersen. Virtual Classes: A Powerful Mechanism in Object Oriented Programming. OOPSLA (1989) [19] R.E. Lopez-Herrejon, D. Batory, and W. Cook. Evaluating Support for Features in Advanced Modularization Techniques. ECOOP (2005) [20] R.E. Lopez-Herrejon, D. Batory, C. Lengauer. A Disciplined Approach to Aspect Composition. PEPM (2006) [21] R.E. Lopez-Herrejon. Understanding Feature Modularity. Ph.D. Dissertation. The University of Texas at Austin. Department of Computer Sciences. Technical Report TR-0645. September (2006) [22] R.E. Lopez-Herrejon, D. Batory. Modeling Features in Aspect-Based Product Lines with Use Case Slices: An Exploratory Case Study. AOM Workshop at MoDELS (2006) [23] S. McDirmid, M. Flatt, W.C. Hsieh. Jiazzi: New age components for old-fashioned Java. OOPSLA (2001) [24] M. Odersky et al. An Overview of the Scala Programming Language. September (2004), http://scala.epfl.ch [25] H. Ossher, P. Tarr. Multi-dimensional separation of concerns and the Hyperspace approach. In Software Architectures and Component Technology, Kluwer (2002) [26] K. Pohl, G. Böckle, F. van der Linden. Software Product Line Engineering. Foundations, Principles, and Techniques. Springer (2005) [27] Y. Smaragdakis, D. Batory. Mixin Layers: An Object-Oriented Implementation Technique for Refinements and Collaboration-Based Designs. ACM TOSEM April (2002) [28] UML. Unified Modeling Language. http://www.uml.org/ [29] V. Vranic, J. Snirc. Integrating Feature Modeling Into UML. NoDE (2006) [30] P. Wadler. The expression problem. Posted on the Java Genericity mailing list (1998) [31] D.M. Weiss, C.T.T Lai. Software Product-Line Engineering. A Family-Based Software Development Process. AddisonWesley (1999) [32] J. Whittle, J. Araujo, A. Moreira. Composing Aspect Models with Graph Transformations. Workshop on Early Aspects at ICSE (2006) [33] P. Zave. FAQ Sheet on Feature Interaction. http:// www.research.att.com/~pamela/faq.html [34] T. Ziadi, J.-M Jézéquel. Software Product Line Engineering with the UML: Deriving Products. FAMILIES project research book. To appear in Springer LNCS.
Using Goal-Models to Analyze Variability Bruno González-Baixauli Universidad de Valladolid
[email protected]
Miguel A. Laguna Universidad de Valladolid
[email protected]
Julio Cesar Sampaio do Prado Leite PUC-RIO http://www.inf.puc-rio.br/~julio/
in each level [19], the sooner the better. Therefore, we propose to start from a requirements perspective. Deciding which variability must be in the system is a challenging task. Feature oriented domain analysis [11] has aimed to gather abstract concepts of the domain and to organize them as features; yet there is a gap. The early handling of variability is present in different lines of recent research. Halmans and Pohl deal with this using a variation of use cases [9], Schmid [18] uses product portfolios and Lee, Kang and Kim [10] use the idea of product planning. We explore the representation of variability in the context of goal oriented requirements engineering [19]. Features, usually, do not consider, explicitly, the semantics of the interplay among functional and nonfunctional requirements. As such, those models lack foundations to reason about the relationships among different requirements. As an addition to being critical for softwareintensive systems [2][13][21], Non-Functional Requirements (NFRs) may serve as basis for reasoning about choices. The NFR Framework [2], where AND/OR graphs are used to represent choices of different options of how a given NFR (softgoal, i.e. goals with non clear-cut satisfaction criteria) may be realized, appears to be a reasonable choice to reason about variants. Using a network of goals and softgoals, different interrelationships may be possible when a goal is satisfied or/and a softgoal is satisficed (i.e. sufficiently satisfied). Choosing to satisfice a softgoal implies in selecting a variant. As such, the softgoal (NFR) is the natural rationale of why a given operationalization (variant) was selected, that is how a given goal will be satisfied given certain restrictions (softgoal). Goal oriented approaches provides certain “separation of concerns” by modeling different concerns in different AND/OR graphs. But this separation of concerns is partial, since all functionality is finally included in the same graph (both function and non-function goals will need to be operationalized as functions), tangling and scattering concerns. This
Abstract On our ongoing research on variability analysis, two major drawbacks have been identified: a) the lack of an effective tracing from the rationale to the selected variant, and b) the lack of an effective support to decide what variability should be implemented. In order to perform variability analysis we propose to combine goal-oriented requirements strategies with the concept of early aspects. This paper aims to contribute to the general discussion of variability, in particular variability analysis. We stress some of our initial findings on a meta-model to handle the amalgamation of a goals network with the concept of early aspect. We discuss some of the problems we are facing and the possible ways of addressing them.
1. Introduction It is our belief that anchoring variability on the realm of goal and softgoal interrelationships is a strong base to tracing. We also believe that organizing the complex interrelationships as aspects contributes to meliorate the central issue of complexity. The study of systems, taking into account different possible variants or configurations, has been approached from different perspectives. Software Product Lines [3], where variability is embedded in a portfolio of different products sharing a common core, is already been used in industry. Software Customization [13][14] is an approach where all variants are in one single system and the focus is to study what customization is needed by a single user. Exploring alternatives [15] focus on exploring a space of alternatives before selecting the one to be implemented. The work on software configuration management deals with the problem of managing the set of different system compositions and versions for a given system. Variability can be analyzed from different abstraction levels, but since variability is constrained
101
identified (reusing Non Functional Requirements Catalogues [4]), and decomposed successively to define the variability space. Also, crosscutting relationships between concerns’ elements are defined. This variability space can be huge, with too many variants to implement; therefore it must be limited to have an affordable system. PRUNE - Prune space: first analyzing locally solutions in concerns to drop not good enough solution; then, analyzing how these solutions affect other concerns, and deciding what combination must be implemented in the variable system. The result of this analysis is the variability model of the domain (pruned variability model). REUSE - Previous phases are aimed towards analysis for variability (domain engineering), but our goal model is also useful for analysis with variability, that is, provide a customized product for a given client. The analysis with variability is a quest for an “optimal” configuration as to fit the product requirements. Goal-oriented approaches are a good candidate for supporting the three parts. First, in variability exploration, goals allow to start exploration from a higher abstraction level. Abstract functional goals are decomposed in parts (And decomposition) or alternative means to achieve them (Or decomposition). An important advantage is that those alternatives are related with other goals by correlation links. Correlations are defined in the NFR Framework to relate functional elements to, the NFR (softgoals) they affect, producing a rationale for alternatives selection.
tangling/scattering is the reason to use aspect orientation, what applied to requirements is named early-aspects [1]. Using the goal softgoal network (AND/OR graphs) annotated with contributions and correlations (interrelationships) brings up the issue of complexity. The better modularization provided by aspect orientation seems to be a reasonable way of dealing with this complexity [17][21]. We are exploring the combination of goal graphs and aspects as to support a better way of producing requirements models with variability, as well as a systematic way of choosing variability (customization). In the next sections we present our ideas: on the process of dealing with variability (Section 2), on the problems we see as the choices grow (Section 3), on our initial modeling strategy (Section 4), and on dealing with complexity (Section 5). We conclude (Section 6) stressing our findings, problems, and the work we believe lies ahead.
2. Variability Analysis Our aim is to deal with variability from an intentional and quality driven viewpoint. We see variability analysis as split in three different parts. The SADT model of Figure 1 shows how these parts interact. EXPLORE - In this part functional and nonfunctional requirements are modeled to find candidate variability (requirements). Here, concerns are
for Variability (Domain Eng.) decomposition heuristics NFR catalogue
with Variability (Product Eng.)
concern composition selection heuristics
domain requirements
EXPLORE
full model pruned variability model
PRUNE pruning feedback (result from selection)
REUSE product requirements product feedback (result from analysis)
Figure 1: Variability Analysis SADT
102
product
Variability concerns (models) must be composed in PRUNE to find the right variability to be implemented. This composition will produce again the problem of complexity, and how to manage it. In our proposal, different non-functional requirements can be combined with functional goals. So, solutions of the nonfunctional are combined with functional, but also combinations of the non-functional solutions are also possible. To analyze variability, all possible combinations have to be taken into account, but the number of combinations grows exponentially on the number of non-functional requirements and their solutions. Thus, dealing with this complexity is fundamental. Therefore, we divide PRUNE in three steps: a) concerns are locally analyzed and all goals out of interest or not-enough good solutions1 are eliminated; b) analyze composition in tasks: for each functional task we look for softgoal solutions that can be composed with it (given by crosscutting relationships), so possible compositions are evaluated; c) with a composed system, it is possible to find better variants giving priorities to different softgoals as done in [7]. Goal oriented variability analysis is useful in selecting the best variant (see REUSE in Figure 1), given product requirements (functional and nonfunctional). In that context, our previous work [7] uses a functional goal model to calculate the variants, a contribution matrix to relate them to the softgoals (NFR), and a priority scheme that returns a set of charts that compare the variants to choose the optimal one. This work is compatible with our ideas, since the result of composition is a functional model.
Figure 2 shows how the rationale for different Login variants can be represented. In this case, three alternatives are given: a) use password, which is not so good for authenticate user, and hurts memorability, but it is a widely used mechanism, and consequently more natural; b) fingerprint, which is good to assure user authenticity, but hurts commonality, and cost for the user (he needs to buy a fingerprint device); and c) using an internet certificate, which also assures authenticity, but hurts naturalness. NFR are not only used to justify alternatives, applying the NFR Framework [2] and the softgoal concept, it is possible to deal with NFR in variability analysis. Softgoals are also decomposed from high level NFR until operationalized NFR (solution), but because of their fuzzy nature, their solutions are in different degrees (similar to correlations). Memorability [System]
+ -
Login [User, System]
OR
Authenticity [User]
++
++
OR
OR
Use [UserID, Password]
+
-
Use [Fingerprint] Use [Certificate, CertificateProvider]
Naturalness [System] Softgoal
Goal
-
3. Goal Composition
Cost [User] Task
Model composition is basic for our proposal, since we need a mechanism to join concerns and get a complete vision of the system. Since our aim is to analyze variability, our focus in composition is to discover what combinations are possible, i.e. we need to know how different goal models can be composed with others. Therefore, we do not need a complex composition mechanism as in early-aspects or AOSD [1][16][17]. Because tasks (Tasks are the functional operationalization of both goals and softgoals) are the specific elements of goal models (versus the generality of goals and softgoals), composition is done at task
Correlation Decomposition type
type
Figure 2: NFR are the rationale for variant decision On the other hand, early-aspect ideas [1] are a natural way to integrate functional and non-functional models, and to improve modularity in goal oriented approaches. Good modularity is basic in variability analysis since dealing with multiple solutions for a problem increases complexity. Better modularity provides chances of a deeper analysis since the problem is separated in multiple parts, and therefore more variability can be explored. Also, aspect weaving provides a new variability mechanism since an NFR can be composed or not.
1
For instance, in Figure 2 Use [Fingerprint] has the same advantages and disadvantages than Use [Certificate, CertificateProvider], plus another disadvantage.
103
level, generating new task that will achieve goals and correlate softgoals. Figure 3 shows a simple composition where a Softgoal (SG2) with two possible solutions (with contribution value c1 and c2) is related to a Goal (G1) decomposed in two tasks (decomposition can be And or Or). G1ƔT2.1
Initial Models SG2
G1
c1 T1.1
T1.2
c1
c2
T2.1
T2.2
T1.1ƔT2.1
T1.1ƔT2.2
T1.2ƔT2.1
SG2
G1
c1Ɣc2
c2
T1.2ƔT2.2
Softgoal
Goal
c1
G1ƔT2.1ƔT2.2
SG2 c2
SG2
G1
G1ƔT2.2 G1
have four variants for it, but if it is an Or, variants will be multiplied by the number of subtasks, that is the number of variants for this goal. Therefore, we need a mechanism to deal with the number of possible compositions, and consequently variants. Note that all these variants should be represented in the same model as shown in Figure 4, since our main interest is to show and analyze variability. Figure 4 represent different means to get the password in a Login system. It can be understood in two ways: as the way that the goals is represented in a typical goal model; or as the result of composing the goal Get [Pass] with two solutions (Ask or Use previous password) and Privacy of password, with two operationalizations (Show password with asterisks instead of letters and Hiding the input). This graph shows the resulting composition, therefore the initial elements are represented as references (dotted elements), but also new solutions taking into account the softgoal and new correlations links are shown. In this case, softgoal solutions are not compatible, so there is only 2 new goals (has no sense show asterisks and hide the input at the same time). Note that other contributions are not shown (e.g. Use [Previous] hurts Privacy [System] or Hide [Input] hurts Usability, since number of letters is not shown). In general, for a goal G1 decomposed in N tasks: G1{T1.1, T1.2, …, T1.N}; and a softgoal SG2 solved by M tasks: SG2 {T2.1, T2.2, …, T2.M}, we will have 2M variants (combinations of 0 elements for the initial solution, of 1 element for composition of one solution, …, of M elements for all solutions composed) if G1 decomposition is an And or Nx2M if it is an Or. Nor M or N will usually be too big, but several Softgoals can be composed at the same time, in this case we will have Nx2L, where L is the sum of all solutions of the
c1Ɣc2
T1.1ƔT2.1ƔT2.2 T1.2ƔT2.1ƔT2.2 Decomposition (AND/OR) Contribution (++,+,-,- -) Correlation (++,+,-,- -) Crosscutting
Task
Figure 3: Possible compositions for a goal (G1) with two sub-task and a softgoal (SG2) with two solutions This simple composition produces three new variants: one where Goal subtasks are combined with T2.1 solution of SG2, another where they are combined with T2.2, and one more with the combination of both solutions if they are compatible. Actually, compatibility is a decision of the domain engineer. Note that contributions (decompositions in softgoal graph) are transformed to correlations to represent that composed tasks are solutions of functional goal, instead of non-functional softgoals. Considering that G1 is decomposed by And, we will
+
Get [Pass] OR
OR
OR
simple OR
Ask[Pass]
Goal
++
w Hide[Input]
w Show[Asterisk] OR
OR
Use[Previous]
Softgoal New Elements
Ask[Pass]Ɣ Show[Ast]
Task
Privacy [Pass] +
Goal
OR
OR
Ask[Pass]Ɣ Hide[Input]
Use[Previous]Ɣ Show[Ast] Softgoal
Task
References to Elements
OR
Use [Previous]Ɣ Hide[Input] Decomposition (AND/OR) Contribution (++,+,-,- -) Correlation (++,+,-,- -)
Figure 4: Goal model showing different means for get password in a login t
104
softgoals that affect the goal. Considering that softgoals may interact at different levels of a goal graph, it is easy to imagine that we are facing a combinatorial explosion.
Project
Concern
View
4. Variability Model In this section, we present an initial idea of the variability model needed to support the intentional and quality based variability analysis presented. In our proposal, variability is represented by goal oriented relationships (Or-decomposition and contributions), and by aspect oriented since concerns can be composed or not. This model has to deal with the characteristics of our proposal that are: 1) to support goal oriented elements as goals, softgoal and task, and their decomposition; 2) to allow goal analysis, by defining correlation and contribution relationships; 3) to deal with concerns, separating them in different models; 4) to define where tasks must be adapted to achieve softgoal satisficing; 5) to support composition, including new models to contain the resulting composition. We take as basis of our model the goal oriented models of [21] and [12], but adding the idea of a metamodel as to organize relationships among different sets (named Concern). Meta modelling is also applied to the model View, created by composition of other models. Existing approaches that integrate goal with aspects usually create completely new models when they make the composition, but we support the idea of references to avoid new elements, and the possible inconsistencies. Figure 5 shows a representation of the modelling elements, and their relationships: a Project is composed by Concerns and Views. Concern is a model with goals and tasks (usually functional) or with softgoal and tasks (usually non-functional). All elements can be decomposed (And or Or) by the same kind of element, but tasks can also decompose goals and tasks. Goals, function tasks and softgoals can correlate, indicating how they affect (make, help, hurt and break), softgoals. Softgoal tasks and Softgoals can contribute, solving at some degree (make, help, hurt and break), a softgoal. Correlations and contributions are different since contributions have a decomposition meaning, task that correlates a softgoal solves that softgoal in some degree. Meanwhile, correlations represent how decomposition of other elements affects the softgoal.
goal
softgoal
function tasks
softgoal tasks
composition
decomposition
correlation
goal
softgoal
Task contribution
crosscutting
Figure 5: Modeling elements and relationships. Dotted elements can be references or elements Views are composition of other models (Concerns or Views), and they have references to Concern’s elements (goal, softgoals or tasks), but also can have new elements as a result of the composition (see Figure 4). Note that in composition, new goals gain a correlation of the same value of the contribution from softgoals task composed with it to the corresponding softgoal. We defined a first version of the modelling elements and relationships in [8] using a meta-model. Also, we implemented a prototype modelling tool using a meta-modelling application: Generic Modeling Environment (GME 5) [5].
5. Dealing with Complexity Complexity in this environment has two causes: a) goal models usually integrate all functionality in one model: b) variability space size. Our first solution to complexity is to divide the system in different models, modularizing concerns as much as possible. To support this, we applied an aspect oriented approach. In addition, better model modularization implies more independence in concerns, what permits to perform local analyses, as explained before (Section 3). So, a first step of variability decision is done locally, analyzing solutions in concerns, and taking off what are not a “good enough” solution. But this is not enough, it is necessary to analyze how those solutions affect each system part, which in goal-oriented approaches is represented by tasks. Therefore, we need to know what softgoal solutions
105
but in analysis of the composition of T1.1.1 with T3.1 it was concluded that it will not be in the system. So, even if the composition of the other task (T1.1.2) could be done, the propagation shows it is not enough, and deletes softgoal’s solution T.3.1.
affect to each task. However, representing the graph with all possible combination of tasks with softgoal solutions that affect them will create a too huge model (see Figure 4 for two simple graphs). This task analysis could be done by following crosscutting relationships in an indirect way, however since crosscutting relationships can affect different goals in the decomposition hierarchy; it is difficult to know what softgoals affect a task. To solve this problem, we propose to use a labelling mechanism to attach what softgoals (and solutions) can affect a sub-graph (tree). Figure 6 shows an example of labels for two simple goal tree (goal G1.2 decomposition is not shown). The labelling algorithm will go through the softgoal graph since they are the source of crosscutting relationships, and will create the label structure. Then, it will go through the goal graph from the target of crosscutting and will add the structure to the tasks. Note that lower level softgoals can be more specific in their crosscutting relationships as happen with SG2.1. SG2 { + SG2.2 { ?, ?} }
G1.1
G1
G1.1
SG3 {++ T3.1, +T3.2}
…
T1.1.1 SG2 { + SG2.2 {+ T2.2.1, ++T2.2.2} + SG2.1 {+ T2.1.1, ++ T2.1.2} }
T2.1.1
SG2.2
T1.1.2 T2.2.1
T3.2
T1.1.2 SG3 {++ T3.1, +T3.2}
Obviously, it has no sense to have T1.1.2 with T3.1, consequently the analysis should be redone to allow the combination with the first task or discard the one with the second task. Label propagation, as shown, is not enough to analyze the combination of several softgoals, e.g. compose T1.1.1 with T2.2.1 and T2.1.1 at the same time. Labels should be enriched with all possible combinations. Note that this labelling is done from the concern definition, similar to weaving in AOSD approaches. Therefore, since concerns are defined independently, separation of concerns is not affected. We are looking for yet another mechanism to help shrinking the variable space. We believe that annotations with hints to restrict the possible combinations are a good idea. These restrictions would be based on softgoal interference, if more than one softgoal was been considered. As such, some possibilities could be eliminated due to pre-defined unwanted interferences. We have implemented a composition mechanism, without new task creation, using XSLT [8]. First results are promising and we are planning to continue as we consider our annotation model.
T2.1.2
SG2 { + SG2.2 {+ T2.2.1, ++T2.2.2} + SG2.1 {+ T2.1.1, ++ T2.1.2} }
T3.1
Figure 7: Label Propagation scheme
SG2
SG2.1
and
T1.1.1
G1.2 SG2 { + SG2.2 { ?, ?} }
+
G1.2 SG3 {++ X, + V}
and
G1
SG2 { + SG2.2 { ?, ?} + SG2.1 { ?, ?} }
SG3 ++
T2.2.2
Figure 6: Composition labels example. SG2 affects all sub-goals, but SG2.1 only G1.1 Not only tasks have labels, goals too. This is a structure to analyze if a softgoal’s solution is going to be used or not. So, task compatibility analysis will result in what task compositions are compatible and can be on the system, but this local analysis can produce partial compositions, not enough to contribute to the softgoal. Therefore, selections in tasks must be propagated to upper goals as in the Label Propagation Algorithm in [2][6]. Here, since the model is functional, we have only the decomposition relationship (without correlations as in softgoal graphs): if we have an And, all tasks should implement the composition to propagate. In the other hand, if it is an Or, only one is needed. Finally, labels of the root goal (considering the crosscutting relationship subtree) will provide us what softgoal’s solutions are going to be implemented. Figure 7 shows an example of propagation: G1.1 is And-decomposed in two tasks,
6. Conclusion In this paper we have explored how goal models and early aspect concepts can be applied to deal with variability, and to decide what should be in the variable system-to-be. Goal model brings to light the rationale behind variability by linking variants with softgoals. This is achieved by means of correlations as in the NFR framework. Combining goal modeling with aspects improves modularity and helps dealing with complexity.
106
[7] B. González-Baixauli, J.C.S.P. Leite, and J. Mylopoulos, “Visual Variability Analysis with Goal Models”, Proc. of the RE’2004, IEEE Computer Society, Sept. 2004, Kyoto (Japan), pp. 198-207. [8] B. González-Baixauli, M. Laguna, and J.C.S.P. Leite, “A Meta-model to Support Visual Variability Analysis" (submitted to conference). [9] G. Halmans, K. Pohl, “Communicating the Variability of a Software-Product Family to Customers”, Journal of Software and Systems Modeling 2(1), 2003, pp. 15-36. [10] J. Lee, K.C. Kang, and S. Kim. “A Feature-Based Approach to Product Line Production Planning”, 2004. [11] K.C. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, Technical Report, CMU/SEI-90-TR-21, SEI (Carnegie Mellon), Pittsburgh, 1990 [12] J.C.S.P. Leite, Y. Yu, L. Liu, E.S.K. Yu, and J. Mylopoulos “Quality-Based Software Reuse”. Proc of CAiSE 2005, Porto (Portugal), pp. 535-550 [13] S. Liaskos, A. Lapouchnian, Y. Wang, Y. Yu, and S. Easterbrook, “Configuring Common Personal Software: a Requirements-Driven Approach”, Proc of RE'05, Paris, (France), 2005, pp. 9-18. [14] S. Liaskos, A. Lapouchnian, Y. Yu, E. Yu, and J. Mylopoulos, "On Goal-based Variability Acquisition and Analysis," Proc of RE’06, Minneapolis/St. Paul (Minnesota), sept 2006, pp. 76-85, [15] J. Mylopoulos, L. Chung, S. Liao, H. Wang, and E.S.K. Yu, “Exploring Alternatives during Requirements Analysis”. IEEE Software 18(1), jan 2001, pp.92-96 [16] A. Rashid, A. Moreira, and J. Araujo, "Modularisation and Composition of Aspectual Requirements", Proc. of 2nd AOSD, 2003, ACM, pp. 11-20. [17] L.F. Silva, “An Aspect-Oriented Requirements Modeling Strategy”, Tese de Doutorado. Departamento de Informática, PUC-Rio, Rio de Janeiro, (Brazil), 2006 (in Portuguese) [18] Schmid, K. “Strategically Defining and Exploiting Product Portfolios with a Product Line Approach”, in Perspectives on Software Requirements, Kluwer, 2004 [19] J. van Gurp, J. Bosch, and M. Svahnberg, “On the Notion of Variability in Software Product Lines”, Proc. of WICSA 2001, Amsterdam (The Netherlands), aug. 2001 [20] A. van Lamsweerde, “Goal Oriented Requirements Engineering”, Proc. of 5th IEEE Intl. Symposium in Requirements Engineering, Toronto (Canada), aug. 2001, pp.249-263 [21] Y. Yu, J.C.S.P. Leite, and J. Mylopoulos, “From goals to aspects: discovering aspects from requirements goal models”, Proc. of RE'04. Kyoto (Japan), sep.2004, pp.38-47.
We have shown how complex the models turn out to be as one builds with variability. Our approach is to break the variability space, pruning the model as much as possible as to reduce its complexity and the complexity of its analysis. We have shown a preliminary strategy based on annotations that seem to be worth pursuing. Several problems lie ahead. How to define the composition operator, and its properties? How to allow crosscutting relationships between functional goals (not only from softgoals to goals)? How to refine the composition mechanism, allowing some types of task to be affected (constraints similar to when in [12])? How to deal with alternative crosscutting relationships, that is, crosscutting relationship from one softgoal to several goals, with one being enough to achieve the goal? How to deal with more operationalizable softgoal solutions that could be added as goals instead tasks (as in Login [System], or Log [Transactions], or Encryption [Data])? How to analyze the reusability of concerns (here [12] can help)? How to handle antigoals (obstacles)? Finally we need tool support. We have developed a simple modeling environment [8] using a metamodeling tool (GME 5 [5]), but more work on implementing composition and labels is needed.
7. References [1] R. Chitchyan, A. Rashid, P. Sawyer, A. Garcia, M. Pinto Alarcon, J. Bakker, B. Tekinerdogan, S. Clarke, and A. Jackson, “Survey of Aspect Oriented Analysis and Design Approaches”, AOSD-Europe Network of Excellence, Avail. at http://www.early-aspects.net/ (Last visited on Oct 06) [2] Chung, L., Nixon, B., Yu, E. and Mylopoulos, J. NonFunctional Requirements in Software Engineering Kluwer Academic Publishers, 2000. [3] Clements, P.C. and Northrop, L. “Software Product Lines: Practices and Patterns”. SEI Series in Software Engineering, Addison-Wesley. 2001. [4] L.M. Cysneiros, E. Yu, and J.C.S.P. Leite “Cataloguing Non-Functional Requirements as Softgoal Networks” In: Requirements Engineering for Adaptable Architectures @ RE’03. pp.13-20 [5] Generic Modeling Environment (GME 5). Vanderbilt University (Nashville). Available at (Last visited on Oct 06) http://www.isis.vanderbilt.edu/projects/gme/ [6] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and Sebastian, R., “Reasoning with goal models”, Proc. of ER’02, Tampere, Finland, October 2002.
107
108
On the Structure of Problem Variability: From Feature Diagrams to Problem Frames Andreas Classen∗, Patrick Heymans Computer Science Department, University of Namur 5000 Namur, Belgium {aclassen, phe}@info.fundp.ac.be Robin Laney, Bashar Nuseibeh, Thein Than Tun Centre for Research in Computing, The Open University Walton Hall, Milton Keynes MK7 6AA, UK {r.c.laney, b.nuseibeh, t.t.tun}@open.ac.uk Abstract Requirements for product families are expressed in terms of commonality and variability. This distinction allows early identification of an appropriate software architecture and opportunities for software reuse. Feature diagrams provide intuitive notations and techniques for representing requirements in product line development. In this paper, we observe that feature diagrams tend to obfuscate three important descriptions: requirements, domain properties and specifications. As a result, feature diagrams do not adequately capture the problem structures that underlie variability, and inform the solution structures of their complexity. With its emphasis on separation of the three descriptions, the problem frames approach provides a conceptual framework for a more detailed analysis of variability and its structure. With illustrations from an example, we demonstrate how problem frames analysis of variability can augment feature diagrams.
1
Introduction
A software product line (SPL) is “a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [6]. Software Product Line Engineering (SPLE) is a rapidly emerging software engineering paradigm that institutionalises reuse throughout software development. By adopting SPLE, one expects to benefit from economies of scale and thereby improving the ∗ Currently
visiting at The Open University, UK.
cost, productivity, time to market, and quality of developing software. Central to the SPLE paradigm is the modelling and management of variability, i.e. “the commonalities and differences in the applications in terms of requirements, architecture, components, and test artefacts” [21]. In order to tackle the complexity of variability management, a number of supporting modelling languages have been proposed. In this paper we examine two approaches for analysing requirements for SPLs: Feature Diagrams and the Problem Frames approach. Feature Diagrams (FD) [16, 17, 9, 8, 28, 2] are mostly used to model the variability of application “features” at a relatively high level of granularity. Their main purposes are (i) to capture feature commonalities and variabilities, (ii) to represent dependencies between features, and (iii) to determine combinations of features that are allowed and disallowed in the SPL. An important limitation of FDs is that they tend to mix requirements, domain properties and specifications. For example, in FDs, it is not clear whether variability is a domain, requirement or solution property. The Problem Frames approach (PF) by Jackson [14] is a more general approach to requirements engineering. This approach emphasises a clear distinction between requirements, domain descriptions and specifications. However, the PF approach has not been applied in the context of feature-based development. In this paper we show that FDs and the PF approach can be used as complementary techniques. The basic idea is that a PF analysis would serve as an early requirements analysis in product line development. Yu et al. [30] identify lack of organisational and motivational context in FDs and propose goal models to com-
109
plement FD. Similarly, Halmans and Pohl [12] suggest that use case diagrams can help in communicating variability to different stakeholders. However, with the PF approach we aim to put FDs in the context of domains in the real world. Benefits of this approach include (i) existing FDs will be supplemented by an analysis of underlying problem complexity, (ii) notations and semantics of FDs and problem frames are not changed or extended, (iii) this approach is not prescriptive, meaning no change to process or methodology is suggested, and (iv) FDs can link problem frames to the solution space. We believe that our approach to use problem frames as an early analysis in SPL development is a novel contribution to this discussion. The rest of this paper is organized as follows. Section 2 describes the background to this work by providing an overview of FDs and the PF approach. Section 3 introduces the illustrative example, which is then analysed using FDs in Section 3.1, and using the PF approach in Section 3.2, before revisiting the initial analysis in Section 3.3. Section 4 gives an overview of related work. Discussions and conclusions can be found in Section 5.
2
Background
In this section we will briefly review the two approaches considered in this paper, Feature Diagrams and the Problem Frames approach.
2.1
Feature Diagrams
Feature diagrams are a common notation for representing requirements of SPLs using a feature tree, or a directed acyclic graph. Since their introduction in 1990 as part of the FODA method [16], many new or adapted notations have been published. Schobbens et al. [27, 25] give an overview of the existing FD notations and approaches. They define a formal semantics for FD notations. They also introduce their own FD language, varied FDs (VFD) inspired by Riebisch et al. [23], which only contains one decomposition relation with cardinalities. Their notation is used throughout this paper1 . Figure 1, adapted from [26], is an example of a simple feature diagram for a mobile phones product line. A mobile phone has a GSM connectivity feature, a messaging feature and a multimedia feature. They are linked by an and-relation, as the cardinality {3, 3} of the top feature indicates, which means that they all have to be included in a product. The cardinality {2, 4} of the GSM connectivity feature means that at least two frequency bands have to 1 To be precise, Schobbens et al. only defined the semantics and an abstract syntax. The concrete syntax we use here is inspired by Riebisch et al.’s FORE FD. In our concrete syntax, unary {0, 1} decompositions (i.e. optional features) are simplified with hollow circles.
Figure 1. A feature diagram for a mobile phone product line. 0RELOH3KRQH^`
*60&RQQHFWLYLW\^`
*60
*60
*60
*60
0HVVDJLQJ^`
606
0XOWLPHGLD^`
&DPHUD^` 006
03L[HO
03L[HO
0XVLF 3OD\HU
03L[HO
be supported. The messaging feature has two subfeatures connected by an and-relation: the mandatory SMS feature and the optional MMS feature (indicated by the hollow circle above it). It does not have to be included even though the cardinality of its parent node is {2, 2}. The Multimedia feature is decomposed with an or-relation (cardinality {1, 2}), that means that at least one of its subfeatures has to be included. The Camera feature is decomposed with a xor-relation (cardinality {1, 1}), meaning that only one of the three picture resolutions can be supported by the mobile phones’ camera. Features in FDs generally refer to requirements R, but they can also represent domain properties W, specifications S and design D, leading to confusion as to what exactly FDs are describing. This is reflected for example by the definitions by Kang et al. [17]: “a prominent or distinctive uservisible aspect, quality or characteristic of a software system or systems”. This notion of “feature” is not restricted to R, but also includes S and even D. As a result, FDs often do not reveal much about the underlying complexity of problem structures. FDs can also represent variability with different binding times, such as design-time variability and run-time variability according to van Gurp et al. [29]. The scope of this paper will be limited to design-time variability, that is variability occurring in the requirements. For a discussion on the PF approach to run-time variability, also referred to as context-awareness, see [24].
2.2
Problem Frames
The Problem Frames approach, proposed by Jackson in [13, 14], is a conceptual framework to software requirements engineering, which emphasises the need to put real software problems in their context. This contextualisation allows systematic reasoning about the required properties of the world the requirements refer to, the given properties of the world the machine must rely on, and the behavior of the machine (software) to bring about the necessary change in
110
the world properties. This conceptual framework has been used as a basis to (i) relate problem and solution structure [10], (ii) describe architecture-inspired problem decomposition [22], (iii) recompose software problems using a composition operator [18], and (iv) capture patterns of change in socio-technical systems [5].
context. A variant frame shares the central concern of the basic frame, but has additional concerns to deal with problems that do not fit basic frames. Variant frames are one technique of the PF approach considered in this paper for dealing with variability.
3 Figure 2. A context diagram for a traffic lights controller. A
/LJKWV FRQWUROOHU
/LJKW XQLWV
D /&^53XOVH>L@*3XOVH>L@`
Figure 2, taken from [14], shows a context diagram for a problem in which a machine is needed to control traffic lights. The context diagram contains the Lights controller machine, marked by the rectangle with two vertical stripes, and the real world domain Light units. These domains have shared states or events (a), known as shared phenomena, which denote the actions the Lights controller can perform on the Lights units.
Figure 3. A problem diagram for a traffic lights controller. 6SHFLILFDWLRQ /LJKWV FRQWUROOHU
5HTXLUHPHQW
'RPDLQSURSHUWLHV D
/LJKW XQLWV
D /&^53XOVH>L@*3XOVH>L@`
E
/LJKWV UHJLPH
E /8^6WRS>L@*R>L@`
The context diagram only describes the context in which the problem is set, and not the actual problem or the requirement, which in turn appears in the problem diagram. In figure 3, the dashed oval represents the requirement, which constrains the properties of the Light units. Decomposition of a complex problem is done by fitting its subproblems to basic frames, for which there is a known solution. Jackson discusses five basic frames, each describing a basic class of problems (a problem pattern). The PF approach also emphasises a clear distinction between the three different descriptions: the requirements R, the domain properties W and the specifications S. These three descriptions are linked by an entailment relationship W, S R. For each basic frame, the entailment relationship is expressed by a correctness argument. From the correctness argument we can derive certain frame concerns. These frame concerns help the analyst to raise questions about properties of the analysed problem, by providing a list of typical issues that apply to the problem frame at hand. Jackson also introduces variant frames, which extend basic frames by typically adding a new domain to the problem
Illustrative Example
The example we use throughout this paper is a simplified sea buoy system, which was discussed by Booch in [4]. The main purpose of the sea buoy is to provide navigation and weather data to passing vessels. The buoys collect air and water temperature, wind speed, and location data through a variety of sensors. The requirements for the basic version (p1 ) of the sea buoy are as follows: R1 Record current wind, temperature, and location information; wind speed readings are taken every 30 seconds, temperature readings every 10 seconds and location every 10 seconds. R2 Broadcast current wind, temperature, and location information every 60 seconds. A more sophisticated version (p2 ) of the sea buoy system also provides the following additional functionality: R3 Record and broadcast wave height measures; wave height readings are taken every 20 seconds and are broadcast together with the other gathered information. This product line has one variation point, which is the decision as to whether the additional wave height sensor will be included or not. The following two sections discuss how the addition of the requirement R3 affects the problem structure of R1 and R2.
3.1
Feature diagram analysis
Following the guidelines proposed by Lee et al. [20], we decompose the requirements R1 and R2 as follows. Globally the buoy serves two purposes: first it gathers data (R1), then it broadcasts the gathered data (R2), making them two compulsory features. The data gathering feature can be further decomposed into three subfeatures: (i) the wind speed measurement feature, (ii) the water temperature measurement feature and (iii) the location determination feature. Features in figure 4 can be described as follows (we omit the root). Data gathering This is a grouping feature for all data gathering activities. It has three subfeatures, corresponding to the different types of measures taken. Its cardinality
111
is {3, 3}, which means that all subfeatures have to be included in the product. Wind speed measurement Record wind speed measurement every 30 seconds. Water temperature measurement Record water temperature measurement every 10 seconds. Location determination Record position information every 10 seconds. Data broadcast Broadcast gathered weather information over the radio every 60 seconds.
Given this revised feature tree, the following two products (sets of features) can be derived: {Sea Buoy, Data gathering, Data broadcast, Wind speed measurement, Water temperature measurement, location determination} and {Sea Buoy, Data gathering, Data broadcast, Wind speed measurement, Water temperature measurement, location determination, wave height measuring}. This is the structure of variability revealed by the FD analysis.
3.2
Problem analysis
We now apply a PF analysis to the same example, first using the base requirements (R1 and R2), and then adding the variability requirement (R3). Figure 4. A feature diagram for the basic sea buoy system.. 6HD%XR\^`
'DWDJDWKHULQJ^`
:LQGVSHHG PHDVXUHPHQW
:DWHUWHPSHUDWXUH PHDVXUHPHQW
'DWDEURDGFDVW
3.2.1
Analysing R1 and R2
Figure 6 shows the context diagram for R1 and R2 of the sea buoy controller. Inclusion of the three real world domains2 (Water, Air, Location) raises concerns that otherwise would have been overlooked. These concerns are discussed towards the end of the analysis.
/RFDWLRQ GHWHUPLQDWLRQ
Figure 6. A first context diagram for the sea buoy example. Adding the variability requirement (R3) leads to the revision of the initial diagram as shown in figure 5. In the diagram, the cardinality of the data gathering feature needs to be changed to accommodate the new branch, representing the wave height measurement feature. The new feature can be described as follows:
:DWHU &
$LU &
/RFDWLRQ
Figure 5. A feature diagram for the basic and the advanced sea buoy system. 6HD%XR\^`
'DWDJDWKHULQJ^`
:LQGVSHHG PHDVXUHPHQW
:DWHUWHPSHUDWXUH PHDVXUHPHQW
/RFDWLRQ GHWHUPLQDWLRQ
'DWDEURDGFDVW
:DYHKHLJKW PHDVXULQJ
L
N &
7HPSHUDWXUH 6HQVRU &
:LQG 6SHHG 6HQVRU &
/RFDWLRQ 6HQVRU
J K I
5DGLR & F 6HD%XR\ &RQWUROOHU
&
K7[CURRENT,OCATION] C3"#[WHEATHER$ATA] F,3[MEASURED,OCATION] H73[MEASURED7IND3PEED] I![CURRENT7IND3PEED] G43[MEASURED4EMPERATURE] J,[CURRENT4EMPERATURE]
Wave height measurement Record wave height measurement every 20 seconds. This feature is optional, it is only included in the advanced version of the sea buoy. It is noted that the Data broadcast feature is also affected by the addition of the new requirement.
M
The shared phenomena between the machine and the Radio domain (c) are the emitted weather information. The Temperature Sensors domain shares the water temperature phenomenon (j) with the Water domain, and the measured water temperature (g) with the machine. The reasoning is similar for the other sensor and environmental domains. The shared phenomena descriptions will be omitted on later diagrams. Figure 7 shows the composite problem diagram for R1 and R2. The Recorder and Broadcast Machines are a decomposition of the Sea Buoy Controller machine shown in the context diagram of figure 6. In order to link both machines, we have to introduce a new domain: the Data Store. 2 These domains are causal domains, which is noted by the C in the lower right corner. Causal domains include predictable causal relationships among their causal phenomena.
112
Figure 7. A composite problem diagram for the sea buoy example. :LQG 6SHHG 6HQVRU &
K
7HPSHUDWXUH 6HQVRU &
L
$LU & M
Q :DWHU &
J N
/RFDWLRQ 6HQVRU &
/RFDWLRQ &
H
O 5
X 'DWD 6WRUH [
Y
G %URDGFDVW 0DFKLQH
Requirement. Record current wind speed information. Readings are taken every 30 seconds and written to the Data Store.
P
I 5HFRUGHU 0DFKLQH
5 D
F
Due to space constraints, our discussion will focus on the analysis of subproblem R1.A, which is similar to the other two subproblems. Figure 8 shows the problem diagram for the subproblem R1.A, the which fits a class of problem known as Information Display4 . The three constituent descriptions of the subproblems are given below.
5DG LR &
It is a designed lexical domain3 where the measures can be stored by one machine before they are broadcast periodically by the other. The requirements are depicted as dashed ovals R1 and R2. An arrow indicates a domain that is restrained by the requirement. R1 constrains the Data Store, meaning that the data stored represents the truthful current weather information. R2 constrains the Radio, meaning that the periodic broadcast contains appropriate weather information. The subproblem R1 is complex and requires further decomposition. We identify the following three subproblems. (R1.A) Wind speed recording subproblem: this subproblem requires that the machine reads the current wind speed and sends it to the Data Store every 30 seconds, and (R1.B) Location recording subproblem: this subproblem requires that the machine determines the current location and sends it to the Data Store every 10 seconds, and (R1.C) Temperature recording subproblem: this subproblem requires that the machine reads the current temperature. The subproblem R2 is already an instance of a basic problem frame, it requires no further decomposition.
Domain properties. We assume that at any time when a given value x is visible to the sensor at interface i (see figure 8), the same value is visible to the machine at interface h at the same time, i.e. ∀x ∈ R • x at h ⇒ x at i. In other words, we assume that the water temperature sensors are working correctly. We also assume that a value sent to the Data Store at b be stored. specification. forever { Read x from h; Write x to b; Wait 29 sec; } Note that the specification assumes that the read and write operations are atomic, and that their execution takes exactly one second.
Figure 9. A correctness argument for subproblem R1.A.
2. Domain properties
3. Domain properties
1. requirement 4. Specification
Wind Speed Sensor C
h Wind Speed Recorder M a ch i n e
5. Specification
i
Air C
n Data Store ~ Windspeed
b
a Data Store x 7. requirement 6. Domain properties
Figure 8. The wind speed recording subproblem. h Wind Speed Recorder Machine
Wind Speed Sensor C
i
Air C
n Data Store ~ Windspeed
b
properties)
4. the machine will then obtain the readings, (specification)
a Data Store x
n: {currentWindSpeed} a: {storedWindSpeed}
1. Given a current wind speed, (Requirement) 2. because the wind speed has certain properties making it measurable,5 (Domain properties) 3. the wind speed sensors are able to capture this information, (Domain
b: WSRM! {windSpeed} h: WS! {measuredWindSpeed}
i: A! {currentWindSpeed}
3 Which means that it’s a passive domain, where information may be stored temporarily, and that we have a certain control over its structure.
4 This is one of the basic frames discussed by Jackson. The problem is to build a machine that collects information about some part of the physical world and presents it at a given place, which is the data store in our case. 5 Common properties used by anemometers rely on the fact that there is a relation between the wind speed and the movement of flexible mechanical devices, like windmills or cups, exposed to the wind. Or the coolingeffect of the wind, which also varies with its speed.
113
5. and send them to the data store every 30 seconds; (specification) 6. the data store being capable of storing the sent information until it is needed, (Domain properties) 7. satisfying the requirement, that the given information should be saved every 30 seconds. (Requirement)
Figure 10. A high level problem diagram for R1 and R3.1.
R
Figure 9 shows a correctness (or adequacy) argument for the subproblem R1.A explaining how the requirement, the specification and the domain properties fit together, satisfying the entailment relationship S, W R. Further analysis of the problem reveals that there are important concerns to be considered. Domain reliability concern. The assumption for the wind speed sensor domain ∀x ∈ R • x at h ⇒ x at i is too strong, because in real life the sensor could fail or give incorrect information. This could lead to the requirement not being satisfied. Resource shortage concern. The Data Store can only be of finite size. This means that it can indeed be full at a given moment.
5HFRUGHU 0DFKLQH
IJK
:DYH KHLJKW 6HQVRU &
6HQVRUV
S NML
&
OQPT (QYLURQPHQW &
55
H¶ X¶ 'DWD6WRUH [
Other shared phenomena change. The shared phenomena e between the Recorder Machine and the Data Store, as well as the requirement phenomena u , change as in the new problem the wave height has to be sent to the Data Store as well. A new requirement phenomenon q has been added because the requirement R1, R3.1 also refers to the wave height in the real world.
Figure 11. A high level problem diagram for R2 and R3.2.
Initialisation concern. The Data Store can be empty when the first broadcast is due. These and other concerns need to be considered when implementing the specification for the subproblem.
d’ Broadcast Machine
Data Store x
v’ a’
c’
R2, R3.2
Radio C
3.2.2
Adding the variability requirement.
The requirement R3, that the wave height be recorded and broadcast as well, is a complex problem that can be decomposed into two subproblems. (R3.1) Wave height recording subproblem: the machine reads the current wave height and sends it to the Data Store every 20 seconds. (R3.2) Wave height broadcast subproblem: the machine broadcasts the wave height every 60 seconds. The resulting subproblems can be considered as variants of the initial two subproblems R1 and R2, represented in figure 7. Figure 10 shows a high level problem diagram for R1 and R3.1. The diagram has been simplified such that all sensors now form only one domain; the same holds for the environment. The Wave height Sensor domain has been added, connecting the machine to the environment, as stated by R3. The resulting problem diagram can be considered as being a variant frame of the initial diagram. The diagram in figure 10 shows that there are no additional or changing shared phenomena between the recorder machine (respectively the environment) and the sensors. This means that a big part of the preceding problem analysis is still valid. The Sensors domain can be considered as a “black box”, which is not touched by adding the Wave height Sensor domain. Hence, all concerns and all diagrams related to the sensors and the environment, are still valid.
Similar changes are observed for the broadcast subproblem of R2 and R3.2 which is represented in figure 11. In order to satisfy the new requirement, the shared phenomena between the broadcast machine and the Data Store (d ) now also contain the wave height information. The same applies to the shared phenomena between the broadcast machine and the radio (c ). The requirements phenomena change as well because the requirement now also refers to the wave height communicated over the radio (a ), and the wave height in the data store (v ). These changes will raise new concerns. Due to space constraints, the correctness argument is not given here. However, it is clear that the new concerns are very similar to the ones observed in section 3.2.1. For instance, the resource shortage concern has to be reconsidered, as the Data Store has to hold more information than before. Overall, this means that the initial concerns, while still being valid, have to be revised to take into account new concerns of similar nature. As far as the specification is concerned, it is sufficient to make sure that variability in the shared phenomena is possible. The variation barely affects the original diagram in terms of domains, and so large parts of the original analysis are still valid.
114
3.3
Feature diagram analysis revisited
The lessons learnt through the problem analysis are the following. Problem structure. The optional property of the wave height feature is not a local issue, it affects other features as well. The wave height feature affects its parent, the Data Gathering feature, as well as the Data Broadcast feature. This, however, is not visible in the problem structure given by the FDs in section 3.1. Issues and concerns. The problem analysis has revealed many issues and assumptions that could affect the specifications we write. For example, with the PF analysis it was possible to uncover domain assumptions that turned out to be too strong or unrealistic. These issues have not been discovered through the FD analysis. Finally, the problem analysis would not complement the Feature Diagrams, if we could not refer to their features. In our case, we observe a correspondence between features and subproblems fitting basic and variant frames, as summarised in Table 1. Hence, when we are treating and discussing a feature, we can easily refer to its underlying problem structure, and to all the concerns that arise from it. Table 1. Linking PF artefacts to features
4
Features
Problem frames
Data gathering
Subproblem R1, R3.1
- Wind speed measurement
- Subproblem R1.A
- Water temp. measurement
- Subproblem R1.B
- Location determination
- Subproblem R1.C
- Wave height measurement
- Subproblem R3.1
Data broadcast
Subproblem R2, R3.2
- Wind speed, water temp. and location broadcast
- Subproblem R2
- Wave height broadcast
- Subproblem R3.2
Related Work
Approaches to contextualising FDs already exist. Yu et al. [30] propose a procedure for translating goal models to FDs. Their early requirements analysis step uses goal models rather than problem frames. They produce preliminary FDs based on their goal models, thus making a step towards a more solution-oriented view. They also see features as
being part of the solution, or at least of the system (late requirements), whereas goals represent stakeholder intentions (early requirements). The Feature-Oriented Reuse Method (FORM) [17] is also an integrated process using FD to model variability. It extends the basic FD notation by defining a framework with guidelines and different classes of features. FORM distinguishes between capability features, operating environment features, domain technology features and implementation technique features. These four feature types are represented on a layered FD. This classification is similar to Jacksons’ requirements, domain properties and specification classification. However, its aim is not to reason about the problem, it is rather aimed at structuring requirements and how they lead to solutions. Griss et al. [9] as well as Halmans and Pohl [12] also try to put FD into context by linking them to use case diagrams. Griss et al. integrate the FODA approach [16] into the Reuse-Driven Software Engineering Business [15]. They consider use case models as being user oriented, and FD as being oriented towards the software developer. Halmans et al. use use cases to document product family variability, and to communicate it to the user. Czarnecki and Antkiewicz [7] take a similar approach. They argue that “features in a feature model are merely symbols”s and that mapping them to other models “gives them semantics”, which shows that the purpose of their work is similar to what is outlined in this paper. They describe a general approach for mapping different kinds of modelling languages to a feature model. They then illustrate it by mapping FDs to UML activity diagrams. In a way, all these approaches aim to address the lack of context in FD, either by introducing additional goal models, activity diagrams, or additional use case diagrams. They actually observe and address the same shortcomings of FD as we do in this paper. Yet, the techniques they use to address these shortcomings do not support problem reasoning at a level of granularity that separates descriptions of requirements, domain properties, and specifications, as problem frames do. Therefore we think that our paper is a novel contribution to this discussion on problem variability. Our approach fits also into the paradigm of Orthogonal Variability Modelling (OVM) introduced by Bachmann et al. [1]. This paradigm suggests the use of FDs as the central variability model, which is then linked to more detailed base diagrams, like class diagrams for data or state diagrams for behavior, in order to allow for more precise reasoning. Problem frames can be seen as being such a base diagram which allows detailed reasoning about the problem and its physical context. OVM suggests to extend base diagrams with explicit modelling of variability and to relate the global variability model to the variability in the base models. Although beyond the scope of this paper, the PF approach can
115
be extended to highlight variability in its models, and how it links to variability in the base models.
5
Conclusions & Future Work
In this paper we have examined problem-oriented approaches, and how they can be combined with well established product line development methods. We did this by analysing examples of both approaches, problem frames and FDs. Both were applied to an illustrative example, based on which we indicated different weaknesses of FDs that can be tackled by problem frames, thus showing a certain complementarity of both approaches. In the illustrative example, we have demonstrated the benefit of an early requirements analysis using the PF approach. It allows us to understand and to reason about the problem, rather than about some set of abstract requirements. It guides us in our discovery of the problem world by offering a complete and consistent methodology. By exploring the problem in greater detail, critical issues can be discovered at a much earlier stage of the development, when there is still enough flexibility for major architectural changes. One could argue that more elaborate dependency notations should be introduced into the FD notation, so that it can handle these problems by its own. This is done by Lee and Kang [19] as well as more recently by Zhang et al. [31]. However, since there is no notion of physical context in FDs, it is not clear how these dependencies can be detected effectively. In this sense, our approach could serve as an input for these notations. We also managed to establish a correspondence between basic problem diagrams and features. We thus introduced a certain amount of traceability because this correspondence tells us for each feature what problem it addresses. We can associate a problem diagram with every basic feature, represent its underlying structure and analyse potential concerns. Hence, we know what the issues for a certain feature are, and what the important or critical aspects of these features will be, even before we start to implement them. However, we need to validate whether or not the link from problem frames to FDs can be made in other cases. Finally, we have to acknowledge that FDs capture the essence, as well as the variability aspects in a very concise and intuitive way. Many different stakeholders have no difficulty talking about features, thus the same notation can be used to communicate with all of them, which simplifies things. FDs are indeed excellent at what they are intended for: represent requirements for product lines and featurebased development. In the introduction we argued that FDs can link problem frames to the solution space. As methods like FORM [17] already link FDs to the solution space, the step left is to link
problem frames to FDs. In this paper we examined a possible correspondence between artefacts of both approaches. This link has to be examined in greater detail in future work. A first step towards a formal combination of FDs and the PF approach is the definition of a formal semantics for both of them. Fortunately there has already been progress in this area: for example, Bontemps et al. [3] and Schobbens at al. [27, 25] define a semantics for FDs, and Hall et al. [11] for the PF approach. We intend to build on this work.
6
Acknowledgements
We would like to thank our colleagues at the Open University, especially Mohammed Salifu and Yijun Yu as well as Pierre-Yves Schobbens and Jean-Christophe Trigaux at the University of Namur, for their feedback and for many interesting discussions about the subject. We acknowledge the financial support of EPSRC.
References [1] F. Bachmann, M. Goedicke, J. C. S. do Prado Leite, R. L. Nord, K. Pohl, B. Ramesh, and A. Vilbig. A meta-model for representing variability in product family development. In PFE, pages 66–80, 2003. [2] D. S. Batory. Feature Models, Grammars, and Propositional Formulas. In SPLC, pages 7–20, 2005. [3] Y. Bontemps, P. Heymans, P.-Y. Schobbens, and J.-C. Trigaux. Semantics of FODA Feature Diagrams. In T. M¨annist¨o and J. Bosch, editors, Proc. of Workshop on Software Variability Management for Product Derivation Towards Tool Support held in conjunction with the 8th international Conference on Software Product Line Conference (SPLC04), pages 48–58, Boston, August 2004. [4] G. Booch. Object-oriented development. IEEE Trans. Software Eng., 12(2):211–221, 1986. [5] J. Brier, L. Rapanotti, and J.Hall. Towards capturing change in socio-technical systems requirements. In Proceedings of the 11th International Workshop on Requirements Engineering - Foundation for Software Quality, pages 225–237, 2005. [6] P. C. Clements and L. Northrop. Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Aug. 2001. [7] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. In GPCE, pages 422–437, 2005. [8] U. W. Eisenecker and K. Czarnecki. Generative Programming: Methods, Tools, and Applications. 2000. [9] M. Griss, J. Favaro, and M. d’Alessandro. Integrating Feature Modeling with the RSEB. pages 76–85, Vancouver, BC, Canada, June 1998. [10] J. G. Hall, M. Jackson, R. C. Laney, B. Nuseibeh, and L. Rapanotti. Relating software requirements and architectures using problem frames. In Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering, pages 137–144. IEEE Computer Society, 2002.
116
[11] J. G. Hall, L. Rapanotti, and M. Jackson. Problem frame semantics for software development. Software and System Modeling, 4(2):189–198, 2005. [12] G. Halmans and K. Pohl. Communicating the variability of a software-product family to customers. Inform., Forsch. Entwickl., 18(3-4):113–131, 2004. [13] M. Jackson. Software requirements & specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 1995. [14] M. Jackson. Problem frames: analyzing and structuring software development problems. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. [15] I. Jacobson, M. Griss, and P. Jonsson. Software Reuse. Architecture, Process and Organization for Business Success. 1997. [16] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Nov. 1990. [17] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh. Form: A feature-oriented reuse method with domain-specific reference architectures. Ann. Softw. Eng., 5:143–168, 1998. [18] R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh. Composing requirements using problem frames. In Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), pages 122–131, Washington, DC, USA, 2004. [19] K. Lee and K. C. Kang. Feature dependency analysis for product line component design. In ICSR, pages 69–85, 2004. [20] K. Lee, K. C. Kang, and J. Lee. Concepts and guidelines of feature modeling for product line software engineering. In ICSR-7: Proceedings of the 7th International Conference on Software Reuse, pages 62–77, London, UK, 2002. SpringerVerlag. [21] K. Pohl, G. Bockle, and F. van der Linden. Software Product Line Engineering: Foundations, Principles and Techniques. Springer, July 2005. [22] L. Rapanotti, J. G. Hall, M. A. Jackson, and B. Nuseibeh. Architecture-driven problem decomposition. In Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), Kyoto, Japan, 2004. IEEE. [23] M. Riebisch. Towards a More Precise Definition of Feature Models. In In Proceedings of Modelling Variability for Object-Oriented Product Lines ECOOP Workshop, Darmstadt, Germany, July 2003, Norderstedt, 2003. Eds. BooksOnDemand Publ. Co. [24] M. Salifu, B. Nuseibeh, L. Rapanotti, and T. Tun. Using problem descriptions to represent context-aware variabilities. Submitted to VaMoS Workshop 2006, November 2006. [25] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, and Y. Bontemps. Feature Diagrams: A Survey and A Formal Semantics. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE’06), pages 139– 148, Minneapolis, Minnesota, USA, Sept. 2006. [26] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, and Y. Bontemps. Feature Diagrams: A Survey and A Formal Semantics. Presentation for the 14th IEEE International Requirements Engineering Conference (RE’06), Minneapolis, September 2006.
[27] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, and Y. Bontemps. Generic semantics of feature diagrams. Computer Networks (2006), doi:10.1016/j.comnet.2006.08.008, special issue on feature interactions in emerging application domains, page 38, 2006. [28] A. van Deursen and P. Klint. Domain-Specific Language Design Requires Feature Descriptions. Journal of Computing and Information Technology, 10(1):1–17, 2002. [29] J. van Gurp, J. Bosch, and M. Svahnberg. On the Notion of Variability in Software Product Lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01), 2001. [30] Y. Yu, J. Mylopoulos, A. Lapouchnian, S. Liaskos, and J. Leite. From stakeholder goals to high-variability software designs. Technical report, Computer Systems Research Institute, University of Toronto, 2005. [31] W. Zhang, H. Mei, and H. Zhao. Feature-driven requirement dependency analysis and high-level software design. Requir. Eng., 11(3):205–220, 2006.
117
118
DecisionKing: A Flexible and Extensible Tool for Integrated Variability Modeling Deepak Dhungana
Paul Grünbacher
Rick Rabiser
Christian Doppler Laboratory for Automated Software Engineering Johannes Kepler University 4040 Linz, Austria
[email protected] different variability modeling techniques and tools in the domain of automation software for continuous casting technology in steel plants. Based on our experiences we see two major problems regarding variability modeling: (i) there is a lack of integrated approaches that work well with largely heterogeneous artifacts in different domains and product lines; (ii) there is a lack of flexible and extensible tools that can easily be tailored to diverse organizational needs. More specifically, we have been facing several issues in our industrial research collaboration: Weak support for domain specific adaptations: Different domains are characterized by different types of assets and domain-specific dependencies between these assets. Current variability modeling tools do not provide the full flexibility needed to deal with a flexible set of asset types, attributes, and domain-specific dependencies. They often assume a certain meta-model while real-world product lines require the definition of domain specific meta-models for variability modeling. Limited support for traceability and integrated PLE: When dealing with assets at different levels of abstraction, the traceability between these levels needs to be properly understood and managed [13]. Existing tools often emphasize one particular level of abstraction or a specific notation. For example, there are numerous tools available for feature modeling and several tools for modeling product line architectures. However, when trying to integrate such tools one finds that establishing traceability between them is hard. A typical traceability problem is that the external variability, i.e., the decisions taken by customers/sales, are often only weakly integrated with internal variability, i.e., decisions taken by engineers [9]. Limited extension mechanisms: It is often difficult to add company-specific extensions to existing product line tools due to a lack of extension mechanisms. An example of such an extension is a plug-in we have developed for our industry partner. This plug-in auto-
Abstract Variability modeling is at the heart of product line engineering. Variability models entail features and architectural elements, technical customization aspects, sales and marketing decisions, as well as complex traceability information. In this paper we describe DecisionKing, a variability modeling tool that offers a great degree of flexibility and extensibility and allows the creation of variability modeling tools for different domains and organizations. The tool is part of the DOPLER approach (Decision-Oriented Product Line Engineering for Effective Reuse) developed in an industrial research cooperation with Siemens VAI. We report on ongoing tool development and present experiences of using DecisionKing.
1. Introduction Complex software-intensive systems are typically not developed for a single customer [12]. Instead, a product line approach is pursued to increase productivity and reduce time-to-market by fostering the reuse of software assets [19]. Variability modeling is at the heart of Product Line Engineering (PLE) and required for enabling reuse on different levels of granularity and abstraction. Variability modeling is a complex task due to the diversity of core assets and complex interdependencies among them. Although various tools and techniques are already available, it remains a big challenge to define a variability modeling approach suitable for a particular domain or organization. Flexible and extensible ways for capturing and sharing variability models are thus needed to exploit the enormous potential of product line engineering [8]. In our ongoing research project in cooperation with Siemens VAI – the world’s leading engineering and plant-building company for the iron, steel, and aluminum industries – we have been experimenting with
119
matically creates an initial product line architecture model by analyzing configuration files of existing systems. However, adding such an external capability to existing variability modeling tools can be a big burden. Inadequate support for multi-team modeling: The size and complexity of many software-intensive systems makes it impossible for single developers or small teams to understand the complete variability model as the knowledge required for creating and evolving variability models is distributed among numerous heterogeneous stakeholders [8][10]. Existing tools provide only little support for multi-team modeling. Weak integration with sales processes: A variability model guides the product derivation and configuration process as it links the external variability such as sales and marketing decisions with the internal customization decisions. Current tools do not provide integrated support for non-technicians using a variability model in product derivation and customization [21]. Weak support for evolution: A variability model has to change over time as the product line assets are constantly evolving. For example, changes in the architecture can make the variability model inconsistent with the technical solution. Supporting the evolution of variability models to reflect changes in the asset base is success-critical for product line engineering. Existing tools often do not provide automated mechanisms for detecting changes in the assets and potentially outdated elements in the variability models. This issue is even more complicated in multi-team modeling environments. In our ongoing research collaboration with Siemens VAI we aim at addressing these issues by implementing the DOPLER approach. This approach consists of two parts: DOPLERVM (variability modeling) and DOPLERUCon (User-centered Configuration [22]). This paper gives an overview on the tool aspects of DOPLERVM and is structured as follows: In Section 2 we give an overview of existing product line tools and techniques related to our approach. Section 3 presents our decision-oriented variability modeling approach. Section 4 discusses the modeling capabilities of DecisionKing. Section 5 presents the variability mechanisms of DecisionKing that make it flexible and extensible. Section 6 rounds out this paper with a conclusion and an outlook on further work.
2.1 Modeling approaches Feature models are widely used for modeling variability on the requirements level. FODA is a wellknown notation [16]. Researchers have also been proposing variability modeling approaches that focus on the architecture level. Several extensions of architecture description languages such as xADL [7] or Koala [3] allow the definition of variants, versions, or optional elements in product line architectures. Other authors have proposed orthogonal approaches to variability modeling [4]. For instance, Bachmann et al. [4] propose a conceptual model of variation to represent variability in product family development. In their approach, a variation point represents an explicit engineering decision to allow for several alternative variants with regard to selected assets of system development. The authors differentiate between assets and artifacts; an asset is considered as a package of relevant artifacts providing a solution to a given problem. Schmid and John [15] describe a customizable approach to variability management which is independent from specific notations. Their approach is based on decision models which are built by specifying decision variables and constraints between them. Approaches have also been published that combine existing mechanisms or extend them with new concepts. For example, Mezini et al. [17] combine featureoriented with aspect-oriented programming in order to overcome deficiencies of a solely feature-based approach. Berg et al. [5] propose a unified approach for variability management focusing on traceability of variation across artifacts. Several authors have investigated the dependencies among different types of artifacts in product line models. For instance, Thiel et al. [23] present an approach for systematically and continuously incorporating and refining variability during core asset development. During the development process designers are instructed to explicitly map features to architectural variation points and capture those mappings in the product line model.
2.2 Tools Numerous tools have been proposed to support product line engineers. Here we describe just a few tools for the sake of brevity. FeaturePlugin [6][2] is a feature modeling plug-in for Eclipse. It supports cardinality-based feature modeling, specialization of feature diagrams, and configuration based on feature diagrams. The meta-model of FeaturePlugin can be extended to associate additional
2. Related Work Various modeling approaches and tools exist that deal with variability on different levels such as requirements, design, architecture, implementation, application, and runtime.
120
attributes to features, such as priorities, binding times, or implementation status. Varmod1 by the University of Duisburg-Essen supports the specification of product line variability models based on an orthogonal variability meta-model described in the OVM-notation. pure::variants by pure-systems GmbH is a variant and variability management tool for managing software product lines [20]. It is based on two modeling concepts: feature models and family models. The variability and commonality of a product line is captured in feature models whereas asset modeling is supported by family models describing the software in terms of architectural elements. The family model is extensible; however no specialization hierarchy for the model elements is supported. Components, which are the basic constituents of the family model, can be hierarchically decomposed into further components or into “part elements” that in turn are built from “source elements”. No explicit support is provided to model domainspecific asset types such as hardware resources, data models, development process guidance, libraries, etc. Gears [18] by Big Lever Software Inc. is a development environment for maintaining product family artifacts and variability models. Variability is handled at the level of files and captured in terms of features, product family artifacts, and defined products that can be derived from the variability model. The tool supports the identification of common and variable source code files.
(see Section 5.1). Asset models describe existing assets in the product line together with trace links specifying their dependencies. The decision model covers external and internal variability together with links to the assets (cf. Figure 2).
3.1 Asset and Decision Modeling DOPLERVM is based on a simple and extensible meta-model which captures the variability of and dependencies between assets like features, architectural elements, resources, etc. Assets and decisions represent the main modeling elements (see Figure 2). Users can define new asset types to reflect the specifics of a particular product line. Variation points are captured as decisions and the dependencies among assets and decisions are explicitly modeled [11].
Figure 2: Core meta-model [11] Assets are artifacts that are intended to be part of the product line. In the case of Siemens VAI we defined asset types for components, documentation, resources, and properties. We distinguish between structural dependencies and functional dependencies between assets. Whenever an asset is part of another asset or contributes in some way to its existence, we refer to it as structural dependency. For example, components have a structural dependency to the subsystem they belong to. Whenever an asset requires another asset in order to be useful we model a functional dependency. This is the case, e.g., when a component serves as input for another component. Any user intervention that is needed to choose the required assets for a concrete product is a decision. Decisions can be seen as variation points in the asset model. Some decisions need to be taken by customers or sales staff while others are taken by engineers. Decisions can be linked with each other in two ways: Some decisions are only relevant when taken in a certain order. The hierarchical dependency specifies how the decisions are organized. For example, the user needs to decide if an archiving feature is required, before taking more specific decisions on the type of database used for archiving. The known consequences of taking decisions are expressed as logical dependencies. Typically, these are business rules that need to be
3. Integrated Variability Modeling We have been developing the integrated DOPLERVM approach for variability modeling in cooperation with our industry partner Siemens VAI based on existing research on variability modeling [5][15][19]. Figure 1 gives an overview: Variability models are based on the definition of a domain model, i.e., a meta-model specifying the building-blocks for asset models and decision models.
Figure 1: DOPLERVM Overview The domain meta-model captures domain-specific asset types and the required types of interdependencies 1
http://www.sse.uni-essen.de/swpl/SEGOS-VM-Tool
121
For example, the Component SensorContainer will only be included in the product if there is a deburrer connection to level 1 and no weighing machine is needed in the plant. These conditions are defined iteratively while creating the decision model as they refer to the variables defined in the decision model (cf. the Boolean decision deburrerConnectionToL1 in the decision model in Figure 4). An asset model can be created semi-automatically by analyzing the existing asset base. For example, call dependencies as defined in existing system configuration files can be utilized to automatically derive requires dependencies among assets. When creating different asset models, one has to make sure that the assets are linked to each other based on the technical restrictions they underlie. In the Siemens VAI case this is ensured by a tool importing Spring XML2 system configuration files.
these are business rules that need to be checked before and after a decision is taken. In order to link assets and decisions, assets specify an inclusion condition which has to be satisfied for a particular asset to be included in the final product. Such a condition is a Boolean expression that can be composed of an arbitrary combination of decisions. These conditions allow the mapping of user demands to assets. Using decisions and inclusion conditions allows establishing traceability links. An asset model is based on the domain specific meta-model and consists of concrete assets which belong to a concrete asset type. Relationships between different asset types are modeled explicitly and represent qualified trace links that are consistent with the meta-model. The traceability information in the models becomes of great value as soon as the variability models are used for product derivation.
References{l1Link, logHMIInput, weighingMachine} Decisions{ Group Sales{ public Boolean deburrer{ Question = “Do you need a deburrer?”; Visibility = true; } Boolean deburrerConnectionToL1{ Question = “Is there a connection to the deburrer via the L1 link?”; Visibility = deburrer && l1Link; } public String markingPredecessor{ Question = “What is the predecessor of the marking machine?”; Visibility = deburrer!=null && weighing != null; Constraint = if(markingPredecessor != “input”, weighingMachine:=false) } }
3.2 Example The example depicted in Figure 3 contains three different sections of the variability model (i.e., asset models for components, resources, and properties) for Siemens VAI’s Runout subsystem of their continuous casting automation software. Each asset specifies an inclusion condition determining when it is part of the derived product. MetaModel = “vai”; References{ L1ConnectionManager, MarkingMachine} Assets{ Resource RunoutServer{ IncludedIf = (deburrer!=null); } Resource RunoutPropertiesFile{ IncludedIf = (deburrer!=null && l1Link==false); } public Component SensorContainer { Requires { L1ConnectionManager } ContributesTo{RunoutServer} IncludedIf = (deburrerConnectionToL1 && ! weighingMachine); } Component DeburrerDriver{ Requires {SensorContainer} ContributesTo{ RunoutServer } IncludedIf = (deburrer!=null); } Component MarkingNumberHandler{ Requires {MarkingMachine} ContributesTo{ RunoutServer } . . . } Property propMarkingPredecessor{ Key = “...runout.marking.predecessor”; Value = markingPredecessor; ContributesTo{ RunoutPropertiesFile } . . . . } . . . . }
Figure 4: Partial Decision Model of the Runout Subsystem After creating asset models, decisions that need to be taken in order to select the required assets for a concrete product are modeled in a decision model (see Fig. 4). Dependencies among decisions are for example informed by the marketing and release strategy of an organization. They are however also the result of technical restrictions. Adding inclusion conditions to the assets in the asset model is an important part of decision modeling. For example, the component DeburrerDriver will only be included if a user has decided to include a deburrer.
4. Variability Modeling with DecisionKing We have been developing the DecisionKing tool to support our integrated modeling approach. DecisionKing is an application based on the Eclipse platform.
Figure 3: Partial Asset Model of the Runout Subsystem (XML-tags removed for better legibility)
2
122
http://www.springframework.org/
Figure 5: Editing a Decision model in DecisionKing The tool has been implemented in a highly iterative process with continuous feedback from Siemens VAI engineers. Early versions of our modeling approach were tested using prototypes built with MS Excel. The suitability, adequacy, and usability of the approach have been tested by engineers of Siemens VAI, who have been using the tool to create variability models for different subsystems of the caster automation software. Figure 5 shows a snapshot of the modeling shell in DecisionKing. Decisions described in Figure 4 are listed in the left pane. The right pane shows a decision viewer graphically visualizing dependencies among decisions. There are different tabs allowing to import and capture assets into the product line (see Figure 3). For example, the Component tab allows to import components from existing configurations and to specify the links to the decision model. The Document tab is used to organize fragments of the documentation. Complex relationships between decisions and assets are expressed in a simple rule language. We are currently using a self-developed engine which will be replaced in the near future with an off-the-shelf engine to ensure scalability.
4.1 Multi-team modeling support Feedback from our industry partner shows that the modeling approach works well for capturing variability both from customer/marketing as well as from technical perspectives, but it is unrealistic to assume that such a model can be created and evolved by an individual or by a small team. The knowledge required to build such a model is typically spread across the minds of numerous heterogeneous stakeholders and different teams responsible for various parts of the system [10]. DecisionKing allows modeling different parts of a large variability model separately and merging the parts into one integrated model later on (see Figure 6). For this purpose, one team may only build the asset model, or even only a partial asset model or decision model. The different parts of the model are then merged using the model merger. Engineers can mark certain elements in the variability model as “public” meaning that these can be used in other variability models. Other elements are listed as references. A team of stakeholders responsible for a certain variability model can refer to elements of other variability models (even without explicitly stat-
123
partner. DecisionKing therefore supports comparison of variability models to detect changes automatically. For this purpose, we are currently experimenting with different tree differencing algorithms that can detect changes in variability models. Currently we are experimenting with THP and MDIR algorithms [1]. THP does not detect moves and does not support forcing/preventing matches. However, THP is faster than MDIR at detecting renames, inserts and deletes.
ing the source to allow a greater degree of flexibility). Engineers then use a model merger matching the references and exported elements of different models based on name and type to create a complete variability model. Whenever there isn’t enough information available for automatic matching of the elements the model merger relies on the user to resolve issues occurring during the merging process.
5. Variability mechanisms in DecisionKing It is one of our aims to create a flexible and extensible modeling tool that can be used in different domains and organizations. Ideally, DecisionKing itself can be seen as a product line offering a number of variability mechanisms such as meta-modeling capabilities and extension points to create domain-specific variability modeling tools. Figure 6: Merging of variability models using a merger is based on element types and names
5.1 Domain-specific meta-models The tool can be parameterized by creating a domain model defining concrete asset types and relationships to enable the creation of domain-specific variability models according to the meta-model. There are no restrictions regarding the types of assets that can be defined, which makes domain-specific adaptations fairly intuitive. The approach is similar to the approach pursued by Grundy et al. [14] to generate domain-specific visual language editors from high-level tool specifications in Eclipse. Figure 7 shows an example of a domain-model with three types of assets and two types of relationships we’ve created for Siemens VAI. The model allows DecisionKing to deal with Components, Resources and Properties. Figure 3 shows the GUI editor used to define meta-models in DecisionKing. One can also add arbitrary attributes to asset types. Asset attributes are typed properties of the assets. Apart from the standard types, we have defined a new type “Script”, which refers to code that can be interpreted by the constraint interpreter used in the model. The domain model can be changed at any time, i.e. new types of assets, attributes of assets, or relationship types among assets can be added if necessary. DecisionKing supports meta-model updates even for already existing variability models, a requirement stated by our industry partner. In order to validate the concepts we have been developing meta-models for other domains and projects. For example, DecisionKing has been used in another research project to model runtime variability of services in service-oriented computing.
In the example depicted in Figure 6, two parts of a variability model are shown. Model 1 imports DBProcessDisplay, a component defined public in model 2. Similarly model 2 refers to the FileManager component, which is set public by model 1. The variability model merger can combine the two models by resolving these references. Many problems can occur while merging different models, for example – missing references, multiple occurrences of the same element, or ambiguity in the mapping of referenced elements. When conflicts cannot be resolved automatically our merger relies on input from the user.
4.2 Model differencing and evolution Support for evolution is essential in product line engineering. For instance, it can take more than one year to deploy a steel plant to a customer at Siemens VAI due to the complexity of such projects. The derivation of the software within this project is therefore a fairly long process. This means that even during product derivation the assets (e.g., components and documentation) evolve continuously, e.g., due to updates and changes from other projects at Siemens VAI. The company deploys 20-30 products per year. It is essential to ensure the consistency of a variability model with the asset base under such circumstances. The evolution of the architecture and other changes in the asset base can make the variability model invalid. Variability models may change even during a project, just like in the case of our industry
124
domains deal with different types of assets, and need different variability management mechanisms. There is a lack of flexible and extensible tools that can easily be adapted to organizational needs. In this paper, we presented DecisionKing, a tool with highly flexible adaptation and integration capabilities. In contrast to most other variability modeling tools which integrate modeling and configuration into one, DecisionKing creates variability models, which can be imported by other tools that make use of this model. DecisionKing works independent of the programming language and the architectural style of the product line. It can be adapted to model variability in different organizational settings. It is based on a plugin architecture, which also makes it readily extensible. DecisionKing is currently being used by developers and engineers from Siemens VAI to validate the approach and to provide feedback. Several variability models for subsystems of the continuous casting system have already been developed using the tool with positive feedback regarding the extensibility of the modeling approach and the flexibility of the tool. However, users of the tool have also reported usability issues, which we will have to address in future work. For example, it is hard to visualize the relationships between the model elements due to the size of the models in our predominantly tree-based representation. The graphical representation of variability models is useful; however creating real-world examples covering a high number of elements and complex relationships such a graphical notation can get tedious. Currently, we are therefore exploring different visualization mechanisms for variability models. Another goal of our research is to integrate DecisionKing with tools supporting non-technicians to participate in the configuration of products [21]. For this purpose, DecisionKing offers an API, which enables easy usage of the variability models by different configuration tools. We are also developing a tool called ProjectKing [22] which makes use of the variability models and supports product instantiation and configuration by generating customer-/project-specific wizards. Sales managers can use ProjectKing, to define different products and to design sales processes for individual projects. For example, one can define typical products for different customer types (by setting defaults) or model additional guards/recommendations for the sales process.
Metamodel vai { AssetRelationships {Requires, ContributesTo} AssetType Component{ Attributes { String name, description; Script includedIf; } Relations { Requires{Component, Resource} ContributesTo{Component, Resource} } } AssetType Resource { Attributes { String name, description; Script includedIf; Double price; } Relations { Requires{Resource} ContributesTo{Component, Resource} } } AssetType Property { Attributes { String name, description, key; Script includedIf, value; } Relations { ContributesTo{Component, Resource} } } }
Figure 7: Domain-specific meta-model with concrete asset types and relationships
5.2 Plug-in Architecture Our second architecture-level variability mechanism ensures extensibility. DecisionKing is based on a plug-in architecture allowing arbitrary external tools to communicate and interact with it. This enables users to develop and integrate company-specific functionality. We have used this feature in three cases so far: (i) We can automatically import existing assets and their relationships from existing configurations to populate the variability model (see examples above). (ii) Our language to describe rules and constraints for relationships between decisions and is provided via a plug-in. We intend to replace our current rule language with a more powerful language based on the JBoss3 rule engine. (iii) We can use third-party model differencers as demonstrated with a plug-in by [1] we integrated via this mechanism.
6. Conclusions and Further Work There are several tools and techniques supporting variability modeling in product line engineering. Although all these tools represent important and valuable contributions for capturing variability there is still a need for research to improve approaches and tools for capturing and evolving variability models. Different 3
http://labs.jboss.com/portal/
125
Figure 8: Meta-model editor
Acknowledgements
[5]
This work has been conducted in cooperation with Siemens VAI and has been supported by the Christian Doppler Forschungsgesellschaft, Austria. We would like to express our sincere gratitude to Klaus Lehner and Christian Federspiel from Siemens VAI for their support and for sharing valuable insights. We thank Marwan Abi-Antoun from Carnegie Mellon University for his support regarding the model differencer. We are also grateful to Thomas Neumayer for his work on the multi-team capabilities.
[6]
[7]
References [1] M. Abi-Antoun, J. Aldrich, N. Nahas, B. Schmerl, and D. Garlan, ”Differencing and Merging of Architectural Views,” Proceedings of the 21st IEEE International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006, pp.47-58. [2] M. Antkiewicz and K. Czarnecki, “FeaturePlugin: Feature Modeling Plug-In for Eclipse,” presented at the OOPSLA’04 Eclipse Technology eXchange (ETX) Workshop, Vancouver, Canada, 2004. [3] T. Asikainen, T. Soininen, and T. Männistö, „A Koalabased Ontology of Configurable Software Product Families,” presented at the 18th International Joint Conference on Artificial Intelligence (IJCAI) Configuration Workshop, Acapulco, Mexico, 2003. [4] F. Bachmann, M. Goedicke, J. Leite, R. Nord, K. Pohl, B. Ramesh, and A. Vilbig, “A Meta-model for Representing Variability in Product Family Development,” in Lecture Notes in Computer Science: Software Product-
[8]
[9]
[10]
126
Family Engineering. Siena, Italy: Springer Berlin / Heidelberg, 2003, pp. 66-80. K. Berg, J. Bishop, and D. Muthig, “Tracing Software Product Line Variability – From Problem to Solution Space,” presented at 2005 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries, White River, South Africa, 2005. K. Czarnecki, M. Antkiewicz, C. Hwan, P. Kim, S. Lau, and K. Pietroszek, “fmp and fmp2rsm: Eclipse Plug-Ins for Modeling Features using model templates,” presented at OOPSLA’05, October 16–20, San Diego, California, USA, 2005. E. M. Dashofy, A. van der Hoek, and R. N. Taylor, “An Infrastructure for the Rapid Development of XMLbased Architecture Description Languages,” presented at International Conference on Software Engineering (ICSE 2002), Orlando, USA, 2002. D. Dhungana, R. Rabiser, P. Grünbacher, H. Prähofer, C. Federspiel, and K. Lehner, “Architectural Knowledge in Product Line Engineering: An Industrial Case Study,” presented at 32nd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Cavtat/Dubrovnik, Croatia, 2006. D. Dhungana, “Integrated Variability Modeling of Features and Architecture in Software Product Line Engineering,” presented at Doctoral Symposium, 21st IEEE International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006. D. Dhungana, R. Rabiser, and P. Grünbacher, “Coordinating Multi-Team Variability Modeling in Product Line Engineering,” presented at 2nd International Workshop on Supporting Knowledge Collaboration in Software Development (KCSD2006), collocated with the
[11]
[12]
[13]
[14]
[15]
[16]
21st IEEE International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006. D. Dhungana, R. Rabiser, and P. Grünbacher, “Decision-Oriented Modeling of Product Line Architectures,” presented at Sixth Working IEEE/IFIP Conference on Software Architecture, Mumbai, India, 2007. J. Estublier and G. Vega, “Reuse and Variability in Large Software Applications,” presented at 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering, Lisbon, Portugal, 2005. P. Grünbacher, A.F. Egyed, and N. Medvidovic, “Reconciling software requirements and architectures with intermediate models”, Journal on Software and System Modeling, vol. 3(3), pp. 235-253, 2004. J. Grundy, J. Hosking, N. Zhu, and N. Liu, “Generating Domain-Specific Visual Language Editors from Highlevel Tool Specifications,” presented at 21st IEEE/ACM International Conference on Automated Software Engineering, Tokyo, Japan, 2006. K. Schmid and I. John, “A Customizable Approach to Full-Life Cycle Variability Management,” Journal of the Science of Computer Programming, Special Issue on Variability Management, vol. 53(3), pp. 259-284, 2004. K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility
[17]
[18] [19]
[20]
Study,” Software Engineering Institute, Carnegie Mellon University, USA, 1990. M. Mezini and K. Ostermann, “Variability Management with Feature-Oriented Programming and Aspects,” Proceedings of the 12th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE12), Newport Beach, USA, 2004, pp. 127-136. C. W. Krueger, “Software Mass Customization,” BigLever Software, Inc., 2005. K. Pohl, G. Böckle, and F.J. van der Linden, “Software Product Line Engineering: Foundations, Principles and Techniques,” Springer-Verlag, 2005. pure-systems GmbH, Technical White Paper, Variant Management with pure::variants, http://www.puresystems.com/fileadmin/downloads/pureconsul_en_04.pdf
[21] R. Rabiser, “Facilitating the Involvement of NonTechnicians in Product Configuration,” presented at Doctoral Symposium, 10th Software Product Lines International Conference (SPLC), Baltimore, USA, 2006. [22] R. Rabiser, D. Dhungana, P. Grünbacher, K.Lehner, and C. Federspiel, “Product Configuration Support for NonTechnicians: A Customer-Centered Approach in Software Product Line Engineering,” to appear in IEEE Intelligent Systems, Special Issue on Configuration, Jan/Feb 2007. [23] S. Thiel and A. Hein, “Systematic Integration of Variability into Product Line Architecture Design,” Proceedings of the 2nd International Conference on Software Product Lines (SPLC), 2002, pp. 130-153.
127
128
FAMA: Tooling a Framework for the Automated Analysis of Feature Models David Benavides, Sergio Segura, Pablo Trinidad and Antonio Ruiz-Cort´es Department of Computer Languages and Systems University of Seville Av. de la Reina Mercedes S/N, 41012 Seville, Spain e-mail: {benavides, segura, trinidad, aruiz}@tdg.lsi.us.es
Abstract
the use of different solvers [7] and logic representations [8] can have an important effect in the time and memory performance of the analysis process. We also showed that there is not an optimum logic representations and solver for all the operations that can be performed on an FM.
The automated analysis of feature models is recognized as one of the key challenges for automated software development in the context of Software Product Lines (SPL). However, after years of research only a few ad-hoc proposals have been presented in such area and the tool support demanded by the SPL community is still insufficient. In previous work we showed how the selection of a logic representation and a solver to handle analysis on feature models can have a remarkable impact in the performance of the analysis process. In this paper we present a first implementation of FAMA (FeAture Model Analyser). FAMA is a framework for the automated analysis of feature models integrating some of the most commonly used logic representations and solvers proposed in the literature. To the best of our knowledge, FAMA is the first tool integrating different solvers for the automated analyses of feature models.
Existing tools to analyse FMs depend on concrete solvers and their performance could be improved if they used several solvers. Two options arise to support multiple solvers: i) Extending an existing tool to use several solvers, ii) create our own multi-solver framework that supports any kind of representation and solver and could interoperate with existing tools. We have chosen the second option because the analysed tools are either not open–source tools or they are not prepared to be adapted to support multiple solvers. In this paper we present a first prototype implementation of FAMA. FAMA is an extensible framework for the automated analysis of feature models. FAMA allows the integration of different logic representations and solvers in order to optimize the analysis process. It can be configured to select automatically in execution time the most efficient of the available solvers according to the operation requested by the user. The current implementation of FAMA integrates three of the most promising logic representations proposed in the area of the automated analysis of feature models: CSP, SAT and BDD, but more solvers can be added if needed. The implementation is based on an Eclipse plug– in and uses XML to represent FMs so it can interoperate with other tools that support it.
1. Introduction Feature Modelling is a common mechanism to manage variability in the context of software product lines (SPL). A Feature Model (FM) represents all possible products in an SPL in terms of features. A feature is an increment in product functionality. FMs can be used in different stages of development such as requirements engineering [14, 15] , architecture definition or code generation [1, 4]. Automated analyses of FMs is recognized in the literature as an important challenge in SPL research [1, 3]. The automated analyses of FMs is usually performed in two steps: i) The FM is translated into a certain logic representation ii) Off-the-shelf solvers are used to extract information from the result of the previous translation such as the number of possible products of the feature model, all the products following a criteria, finding the minimum cost configuration, etc [6]. In previous works we introduced how
The remainder of the paper is structured as follows: in Section 2 the automated analysis of FMs is outlined and details of the performance offered by the solvers used are presented. Section 3 focuses on the description of the functionality and some of the most relevant design and implementations details of the framework. A brief overview of some related tools is introduced in Section 4. Finally we summarize our conclusions and describe our future work in Section 5.
129
2. Automated Analysis of Feature Models
2.3
Once an FM is translated into a suitable representation it is possible to use off–the–shelf solvers to automatically perform operations to analyse a FM [5, 6]. The current implementation of the framework integrates three of the most commonly used logic representations proposed for the automated analyses of feature models: CSP, SAT and BDD. A complete performance test of solvers dealing with such representations and details about the translation of an FM into a CSP, SAT and BDD were introduced in [8, 5]. Following, we overview these representations and we outline the most relevant performance details obtained from such test.
A Binary Decision Diagram (BDD) [10] is a data structure used to represent a boolean function. A BDD is a rooted, directed, acyclic graph composed by a group of decision nodes and two terminal nodes called 0-terminal and 1-terminal. Each node in the graph represents a variable in a boolean function and has two child nodes representing an assignment of the variable to 0 and 1. All paths from the root to the 1-terminal represents the variable assignments for which the represented boolean function is true meanwhile all paths to the 0-terminal represents the variable assignments for which the represented boolean function is false. Although the size of BDDs can be reduced according to some established rules, the weakness of this kind of representation is the size of the data structure which may vary between a linear to an exponential range depending on the variable ordering [10]. Calculating the best variable ordering is an NP-hard problem. However, the memory problem is clearly compensated by the time performance results offered by BDD solvers. While CSP and SAT solver are incapable of finding the total number of solutions of medium and large size feature models in a reasonable time, BDD solvers can work out it in an insignificant time, so it justifies their usage at least on counting operations.
2.1
Constraint (CSP)
Satisfaction
Problem
A Constraint Satisfaction Problem (CSP) [17] consists on a set of variables, finite domains for those variables and a set of constraints restricting the values of the variables. Constraint Programming can be defined as the set of techniques such as algorithms or heuristics that deal with CSPs. A CSP is solved by finding states (values for variables) in which all constraints are satisfied. CSP solvers can deal with numerical values such as integer domains. The main ideas concerning the use of constraint programming on FM analysis were stated in [5]. Constraint Programming is the most flexible proposal. It can be used to perform the most of the operations currently identified on feature models [6]. However, constraint programming solvers reveal a weak time performance when executing certain operations on medium and large size feature models as for example calculating the number of possible combinations of features [7, 8].
2.2
3
Binary Decision Diagrams (BDD)
FAMA framework
FAMA has been implemented as a complete tool for the edition and analysis of FMs. FAMA supports cardinalitybased feature modelling (that includes traditional feature models, e.g FODA, Feature–RSEB, and so on), export/import of FMs from XML and XMI and analysis operations on FMs. In order to make our tool multiplatform and easy to access we implemented FAMA as a plugin for the Eclipse Platform1 . In the next sections we overview of the functionality offered by the framework and we describe some of the most relevant design and implementation details.
Boolean Satisfiability Problem (SAT)
A propositional formula is an expression consisting on a set of boolean variables (literals) connected by logic operators (¬, ∧, ∨, →, ↔). The propositional satisfiability problem (SAT) [12] consists on deciding whether a given propositional formula is satisfiable, i.e., a logical values can be assigned to its variables in a way that makes the formula true. The basic concepts about the using of SAT in the automated analysis of FMs were introduced in [1]. The performance results of SAT solvers are slightly better than the results of CSPs however this approach is not so powerful [8]. To the best of our knowledge, there is not any approach in which feature models attributes can be translated to SAT in order to perform operations as maximizing or minimizing attribute values.
3.1. General Description FAMA offers two main functionalities: visual model edition/creation and automated model analysis. Once the user has created or imported (from XML/XMI) a cardinalitybased FM, the analysis capability can be used. Most of the operation identified on FMs [6] are being currently implemented. At the moment of writing this article the operations fully supported by FAMA are: 1 http://www.eclipse.org/
130
• Finding out if an FM is valid, i.e. it exists a a product satisfying all the constraints.
modelling framework and code generation facility for building tools based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable editing of the model, and a basic editor. The EMF editor of the presented tool is based on an Extended FM Metamodel containing all the information of the metamodel used in the analysis engine plus information specifying the way in which the FMs can be edited. The FMs created are saved in XMI format in order to maximize the interoperability with other applications using the OMG specifications. However, importation and exportation of FMs in XML format is also supported.
• Finding the total number of possible products of an FM (number of products). • List all the possible products of a feature model (list of products). • Calculate the commonality of a feature, i.e. the number of products where a feature appears in. FAMA integrates different solvers in order to combine the best of all of them in terms of performance. The actual version of the framework integrates CSP 2 , SAT 3 and BDD 4 Java solvers to perform the analysis tasks. However, an unlimited number of new analysis operations and solvers could be added. One of the advantages of FAMA is the ability to select automatically, in execution time, the most efficient solver according to the operation requested by the user. The mapping from a FM onto the correspondent solver is done on demand. Therefore, if the user asks for the number of possible combinations of features of an FM the framework will select automatically the BDD solver to get it (the most efficient known approach for this operation). The automated selection of a solver is based on the value of some configuration parameters establishing the priority between the available solvers for each operation. The values of these parameters were set according to the results from a complete performance test of the solvers integrated in the framework [8].
Figure 1. Analysis Engine and EMF Editor FAMA has been implemented as a plugin of the Eclipse Platform. Eclipse is an open development platform comprised of extensible frameworks, tools and runtimes for developing and managing software. The integration of a tool in the Eclipse Platform not only reduce significantly the development effort but also guarantee that the built software will be easy to access and install in any platform using Java. A screenshot of our FAMA Eclipse plug–in deployed is shown in Figure 2. The GUI of the plug–in is composed by two main customised tree views: the modelling view (Figure 3) and the analysis view (Figure 4). The modelling view allows the edition and modification of existing FMs. Roughly speaking, the edition process is based on the selection of existing nodes and the use of the context menu to add new subnodes. When a new FM is created the root node is automatically added. The attributes of the nodes (name, description, min and max cardinality, etc.) can be edited using a property view implemented for such end. Once the FM is created or imported, the user can start using the analysis view to automatically extract information from it. When the analysis view is enabled all the features of the FM adopt a selection state. The user can apply filters by labelling the feature as selected or removed. By default, FAMA uses the most efficient solver for
3.2. Design and Implementation FAMA is logically divided into two modules: the analysis engine and the visual editor (Figure 1). The FAMA analysis engine is the responsible for performing the analysis tasks requested by the user. It receives as main input what we define as questions. A question is composed by an FM in XML format and the parameters, if any, associated to the operation requested by the user. The FMs supplied as main input of the analysis engine are instances of an FM Metamodel [9] defined in an XML Schema. The metamodel defines two kinds of relations: binary relations (such as mandatory, optional and cardinality relations) and set relations (such as alternative, or-relations and cardinality groups). It accepts depends and excludes constraints and feature attributes. The FAMA graphical user interface was implemented using the Eclipse Modeling Framework (EMF). EMF is a 2 we
used JaCoP solver http://www.cs.lth.se/home/Radoslaw zymanek/ used SAT4j http://www.sat4j.org 4 we used JavaBDD, http://javabdd.sourceforge.net 3 we
131
Figure 2. Eclipse Plugin
Figure 3. Modeling View Figure 4. Analysis View
132
each operation. Current implementation uses JaCoP5 solver for CSP representation, Sat4j6 for SAT and JavaBDD7 for BDD. However, the plugin is equipped with a fine–grained configuration utility which allow selecting what of the available solver will be used to perform each operation. Figure 5 shows a screenshot of the property page used to set the configuration options.
FMP
XFeature
CaptainFeature
RequiLine
Pure::Variants
AHEAD Tool Suite
FAMA
an integrated configurator to specialize the created feature diagrams. CaptainFeature does not support the automated analysis of FMs. Requiline11 [18] is defined as a requirement engineering tool for the efficient management of software product lines. From the edition of a group of features and requirements Requiline derives product configurations. It also includes a consistency checker and a query and XML interface. Apart from the consistency checking, RequiLine does not perform any of the others analysis operation identified on FMs [6]. Pure::Variants12 is a commercial tool supporting feature modelling and configuration. This actual version of tool does not support cardinalities. Pure::Variants supports basic analysis operations through a Prolog-based constraint solver. The AHEAD Tool Suite13 (ATS) [2] is a set of tools for product-line development that support feature modularizations and their compositions. AHEAD can perform certain analysis operations on FMs by means of SAT solvers [1]. It does not include feature models attributes in the analysis. Feature models are saved as grammars and no XML representation is provided. Table 1 summarizes the exposed proposals.
+ + + + +
+ + + +
+ +
+ + +
+ + +
+ + +
+ + + + + + + ∼
Figure 5. Preferences Page
4
Related Work
The Feature Model Plugin8 (FMP) [13] has also been implemented as an Eclipse plug–in. It supports cardinalitybased feature modelling, specialization of feature diagrams and configuration based on feature diagrams. FMP uses a BDD solver to work out the number of possible combination of features in an FM. It also supports the use of filters. FMP is becoming a mature tool with interesting extensions but it does not have the analysis of FMs between its main goals. It does not support attributed feature models and do not include more than one solver for the analysis. XFeature9 [11] is an XML-based feature modelling tool also implemented as an Eclipse plug–in. XFeature supports the modelling of product families and applications instantiated from them. This tool does not support the automated analysis of FMs. CaptainFeature10 is a feature modelling tool using the FODA notation to render feature diagrams. It also includes 5 http://www.cs.lth.se/home/Radoslaw
CSP SAT BDD Multi Solver Basic FMs Cardinality-based FMs XML/XMI Maturity
Table 1. Summary of the proposals
5
Conclusions and Future Work
In this paper we introduced the first prototype implementation of FAMA which is a framework for the automated analysis of feature models. We introduced the logic representations currently used in the framework and we exposed
zymanek/
6 http://www.sat4j.org 7 http://javabdd.sourceforge.net 8 http://gp.uwaterloo.ca/fmp/
11 http://www-lufgi3.informatik.rwth-aachen.de/TOOLS/requiline/
9 http://www.pnp-software.com/XFeature/
12 http://www.pure-systems.com/
10 https://sourceforge.net/projects/captainfeature/
13 http://www.cs.utexas.edu/users/schwartz/ATS.html
133
some of the most relevant design and implementation details. Finally, we compared our proposal with some other feature modelling tools and we concluded that this is the first tool integrating different solvers to optimize the analysis of feature models. Although FAMA is not a mature tool yet, its promising capabilities of extensibility, interoperability and integration make it a tool to take into account in the future. Several challenges remain for our future work. The integration of new solvers and new analysis operations are currently in process. All the integrated solvers performance must be analysed in order to define the selection criterion for each kind of operation. We are also studying licenses issues in order to release our tool. We really trust that formal semantics [16] are needed for the verification of our framework and we are working on that direction too.
[7] D. Benavides, S. Segura, P. Trinidad, and A. RuizCort´es. Using java csp solvers in the automated analyses of feature models. LNCS, 4143:389–398, 2006. [8] D. Benavides, S. Segura, P. Trinidad, and A. RuizCort´es. A first step towards a framework for the automated analysis of feature models. In Managing Variability for Software Product Lines: Working With Variability Mechanisms, 2006. [9] D. Benavides, S. Trujillo, and P. Trinidad. On the modularization of feature models. In First European Workshop on Model Transformation, September 2005. [10] R. Bryant. Graph-based algorithms for boolean function manipulation. IEEE Transactions on Computers, 35(8):677–691, 1986. [11] V. Cechticky, A.Pasetti, O. Rohlik, and W. Schaufelberger. Xml-based feature modelling. LNCS, Software Reuse: Methods, Techniques and Tools: 8th ICSR 2004. Proceedings, 3107:101–114, 2004.
Acknowledgments The work reported in this article was supported by the Spanish Ministry of Science and Technology under grants TIC2003-02737-C02-01 and TIN2006-00472. We would like to thank Salvador Trujillo and Daniel Le Berre for their helpful comments on an earlier draft of this paper.
[12] S. Cook. The complexity of theorem-proving procedures. In Conference Record of Third Annual ACM Symposium on Theory of Computing, pages 151–158, 1971. [13] K. Czarnecki and P. Kim. Cardinality-based feature modeling and constraints: A progress report. In Proceedings of the International Workshop on Software Factories At OOPSLA 2005, 2005.
References [1] D. Batory. Feature models, grammars, and propositional formulas. In Software Product Lines Conference, LNCS 3714, pages 7–20, 2005.
[14] S. Jarzabek, W. Ong, and H. Zhang. Handling variant requirements in domain modeling. The Journal of Systems and Software, 68(3):171–182, 2003.
[2] D. Batory. A tutorial on feature oriented programming and the ahead tool suite. In Summer school on Generative and Transformation Techniques in Software Engineering, 2005.
[15] M. Mannion. Using first-order logic for product line model validation. In Proceedings of the Second Software Product Line Conference (SPLC2), LNCS 2379, pages 176–187, San Diego, CA, 2002. Springer.
[3] D. Batory, D. Benavides, and A. Ruiz-Cort´es. Automated analysis of feature models: Challenges ahead. Communications of the ACM, December, 2006.
[16] P. Schobbens, P. Heymans, J. Trigaux, and Y. Bontemps. Feature Diagrams: A Survey and A Formal Semantics. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE’06), Minneapolis, Minnesota, USA, September 2006.
[4] D. Batory, J. Sarvela, and A. Rauschmayer. Scaling step-wise refinement. IEEE Trans. Software Eng., 30(6):355–371, 2004.
[17] Edward Tsang. Foundations of Constraint Satisfaction. Academic Press, 1995.
[5] D. Benavides, A. Ruiz-Cort´es, and P. Trinidad. Automated reasoning on feature models. LNCS, Advanced Information Systems Engineering: 17th International Conference, CAiSE 2005, 3520:491–503, 2005.
[18] T. von der Massen and H. Lichter. Requiline: A requirements engineering tool for software product lines. In F. van der Linden, editor, Proceedings of the Fifth International Workshop on Product Family Engineering (PFE-5), LNCS 3014, Siena, Italy, 2003. Springer Verlag.
[6] D. Benavides, A. Ruiz-Cort´es, P. Trinidad, and S. Segura. A survey on the automated analyses of feture models. In Jornadas de Ingenier´ıa del Software y Bases de Datos (JISBD), 2006.
134
Specifying Variability of an Evolving Mobile System for Feasible Stakeholder Communication and Optimized Delivered Product Architecture Lech Krzanik University of Oulu, Department of Information Processing Science Linnanmaa, FIN-90014 Oulu, Finland
[email protected]
with relaxed conditions on random variation and natural selection. Therefore even more attention must be attached to the efficient and well-targeted ways of generating variants and assessing and selecting them by real stakeholders. The paper briefly considers both these aspects. First we discuss such stakeholder communication that assures a successful selection process in a community of many stakeholders, and with the results consistent with product management information. We formulate feasibility conditions for stakeholder communication. The feasibility conditions affect the formulation of the orthogonal variability model embedded in the product line on which the project is founded. Secondly, we discuss the delivered product architectures, the impact on effective realization of the variation process, and the associated optimization problem. An extended, in relation to [16], orthogonal variability model is formulated. An analysis of the two processes of variation and selection results in recommendations regarding variability specification, which are conclusions from an ongoing project in the domain of mobile systems. Finally we demonstrate an example from the project.
Abstract The paper describes experience with the specification, analysis and realization of software product line in the domain of mobile systems. The target system of applications and services is characterized by massive space and time variability, and the emphasis is on a variability strategy that supports evolutionary product deliveries. It has been observed that explicit and effective stakeholder communication and the adequate architecture of the delivered products are the important overall criteria for such systems. Feasibility of stakeholder communication and optimization of delivered product architectures as well as the respective variability modelling and analysis approaches are investigated in the paper. An example from the Nomadic Media project is demonstrated.
1. Introduction The evolutionary software development strategy is well suited for projects of various sizes, under considerable uncertainty of requirements, technologies, markets and regulations [12, 13]. Thanks to their embedded variability management, software product lines [4, 16] offer a suitable way of implementing evolutionary projects. This report discusses some critical extensions, focused on variability aspects, necessary to make the product line approach even better suited for evolutionary projects. In general an evolutionary project consists of two interleaving processes of variation and selection. The former delivers variant instances of the system under consideration, e.g., a mobile service system, while the latter selects the specimen to survive - best fit and most responsive to change. Different than the natural evolutionary systems, software evolutionary projects may happen with considerably accelerated pace and
2. Stakeholder communication Successful stakeholder communication is fundamental to the selection process whose goal is to select the preferred products and services of the system under evolutionary development. The selection process should satisfy the general evolutionary conditions such as: (i) only real deliveries to real stakeholders are considered; (ii) arbitrarily small differences between variants and arbitrarily small development deltas are allowed; (iii) the variants are understandable to stakeholders and can easily be related to product and service goals and benchmarks, the rationale of the variants and decisions is straightforwardly conveyed; (iv) selection decisions may be taken individually or in
135
groups, various forms of selection decisions are allowed. The selection process usually occurs in a community of many stakeholders, and the results should be consistent with the product management subsystem which is responsible for integrating the variation and selectiton stages into a consistent evolutionary process. Three kinds of communication channels are considered: (a) between stakeholders of same type; (b) between stakeholders of different types (e.g., users and developers); and (c) between stakeholders and product management.
appropriate measurement concepts, with references to benchmark values, and with targets corresponding to subsequent stepwise deliveries. We propose an orthogonal variability model built around a bipartite representation of requirements including disjoint subsets of functions and attributes. The model is outlined in Figure 1. Qualities, functions and features are specified with ranges of variants. Quality-oriented architectural evaluation supports stakeholders’ decisionmaking.
2.1. Feasibility of stakeholder communication We formulate a set of practical feasibility conditions for stakeholder communication. It is recommended that variability investigation is fueled by requirements that are in quantifiable form - such as performance and resource attributes. Because of the general conditions (ii) and (iii) above, in most cases only quantitative attributes allow for comprehensive overview and comparison of variants. All software engineering assets, in particular application requirements shall be demonstrated against respective domain requirements variability that should give idea about the scope of domain, system goals, benchmarks, competitors’ values, etc. Related domain and instance requirements shall be presented together - this will help avoid ambiguity when using certain simplified presentation formats such as feature trees. The domain variability presentation shall support comparisons of various stakeholders’ specifications as well as the resulting application contributions and impacts on the critical requirements. For variability in time and dynamically set delivery steps it will also support cooperative incremental development decisions. The above conditions may affect formulation of the orthogonal variability model embedded in the product line on which the evolutionary project is founded. Conventional ways of decoupling product management and the functions of domain engineering and application engineering may also need revisions.
Figure 1. A requirement-focused variability model.
orthogonal
The model follows the decision approach to software architecture [8, 11, 19, 1]. The Feature association is by definition restricted to customerdeliverable pairs of attributes and functions. The QBoM (Quantified Bill of Material) pattern [17, 20, 6] defines composite hierarchies of variants of attributes, functions, features and designs. The quality attribute schema has been inspired by [7]. The indicated architectural evaluation follows the overall evaluation procedure common to, for instance, the SAAM method, but can be implemented with many other methods [2]. The approach allows for quantification of all variants of attributes, features and designs with regard to the provided requirements. It puts the results in the background of a feature- or requirementsoriented overview of the domain. In the next section we are specifically interested in the quantification of architectural artifacts.
3. Orthogonal variability model A conventional definition of the orthogonal variability model is given in [16]. Such a variability model often concentrates on functional requirements. As a consequence of the above conditions, we propose a requirements-focused model, with system functions and design artifacts qualified with quantitative quality attributes. The attributes shall be specified with
136
management and shift them to requirements engineering. Consequently, the product roadmap artifact that links the two process areas changes respectively. On the other hand product management takes responsibility of a more extensive support of evolutionary variation. It is also proposed that responsibilities regarding other new process areas, such as evolutionary selection support, are divided between product management, integrated requirements engineering and the variability model. The revised variability model and the revised responsibility structure have been investigated in a project outlined below.
4. Target architectures The architectures of the delivered applications are critically important for the effective and efficient realization of the variation process. They should be consistent with the current functional and quality goals of the deliveries, and should demonstrate acceptable performance and resource consumption. In product lines individual application architectures are derived from the domain architecture. We introduce the term target architecture to represent the application architecture of a selected delivery step of the application (which may differ from the architecture of another delivery step of the same application), or the dynamic architecture corresponding to a trace of several evolutionary delivery steps of the application.
6. Example The revised variability model has been investigated and validated in a project outlined in this section. The mission of the project Nomadic Media has been to “find solutions that allow consumers to enjoy their content and use interactive services at the times and in the places they prefer, using the devices that best suit their circumstances.” The domain of such an exploratory project is characterized by considerable uncertainty of requirements, technologies, markets and regulations. Hence the evolutionary strategy has been selected for project deliveries. After a period of investigation a relatively stable functionality referred to as nomadic blogging had been defined [3, 9] and a product line platform, the PORO system [10] for context-sensitive nomadic blogging has been built that was used for systematic evolution of nomadic media systems. Examples of the functionality are visualized in Figure 2.
4.1. Target architecture optimization To assure effectiveness and efficiency of the variation process the target architecture should be dynamically optimized with regard to the selected requirements. The target architecture may include both external and internal system variability, and thus may be not available to some stakeholders. An appropriate follow-up optimization control should be applied based on the current selection of requirements variants. In any case the association of architectural artifacts with requirements in the orthogonal variability model, as demonstrated in Figure 1, facilitates such optimization procedures. We observe that the revised orthogonal variability model is more suitable not only for the selection process but also for the variation process. An important practical strategy is to construct a “minimalist architecture” [14] that focuses on architectural decisions where the payoff is highest and which tends to maximize the likelihood of success. Such architectures also facilitate stakeholder communication and can be derived from the introduced variability model. For instance, requirement priorities can be derived from the specified multiattribute interval specifications [18].
5. Discussion With reference to the conventional orthogonal variability model [16], we introduce a revised model that better supports variation and selection processes of evolutionary development of software systems. Another proposed change is a closer cooperation between the processes of domain and application requirements engineering. We also offload some nonfunctional attribute process areas from product
Figure 2. Two applications derived from nomadic blogging: virtual city (left) and public screen control (right).
As at that stage the functionality was sufficiently stable, the evolution was mostly attribute-driven with usability [15, 5] as the most critical driver. Figure 3 demonstrates sample usability-driven evolutionary
137
development paths. Efficiency, effectiveness and satisfaction were main sub-attributes of usability. Usability-oriented new applications and features were investigated by various stakeholders of the system. We investigated variants with seemingly quite different functionality, although logically the variants were very close to one another.
sizes under considerable uncertainty of requirements, technologies, markets and regulations. In doing so we should carefully investigate issues connected with variability specification such as stakeholder communication or architecture optimization. Revisions to conventional approaches to the variability models and the product line engineering process may prove necessary. We recommend use of orthogonal variability models with explicit links to quantifiable attributes.
8. Acknowledgment This work was supported in part by project E!2023 ITEA Nomadic Media.
9. References
Figure 3. Generating application variants driven by functionality and usability changes.
We found that the use of domain vocabularies associated with domain requirements engineering (and the revised orthogonal variability model) was necessary in order to effectively support the stakeholders in the evolutionary selection process. Vocabularies as well as other introduced support services and their positive effect on the selection process demonstrated importance of explicit consideration of stakeholder communication and the variation model. The various investigated applications were integrated into innovative packages such as the Mobile Bastide package [9] implemented as a dedicated product line for nomadic media. We observed that there could be important differences in implementation technologies for different variants of same variation point, for instance connected with various communication protocols, context-sensitive infrastructures, different approaches and extent of system distribution, additional use of external web services, etc. Therefore, in order to avoid inadequate (most often excessive) “variability footprint”, it was necessary to apply careful requirements-driven optimization of the successive target architectures. Again, the variability model with explicit links to quantitative requirements was useful in achieving this.
[1] A. Akerman and J. Tyree, “Position on Ontology-Based Architecture”. Proc. Of the 5th Working IEEE/IFIP Conf. on Software Architecture (WICSA’05). IEEE, 2005. [2] Bass, Len, et al., Software Architecture in Practice, 2nd Ed.. Addison-Wesley Longman, Inc., Reading, MA, 2003. [3] R. Blood, "How Blogging Software Reshapes the Online Community", Comm. ACM, 47, Nr. 2, 2004. [4] J. Bosch, Design and Use of Software Architectures. Addison-Wesley, 2000. [5] X. Faulkner, Usability Engineering, Macmillan Press, London, 2000. [6] Erich Gamma, et al., Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [7] Gilb, T., 2005. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, ButterworthHeinemann. [8] Jansen, A., and Bosch, J., 2005. Software Architecture as a Set of Architectural Design Decisions. 5th Working IEEE/IFIP Conference on Software Architecture, WICSA 2005. IEEE, 2005. [9] L. Krzanik, "Mobile Bastides: Flexible and Evolvable Business-Oriented Contextual Media", Proc. 11th Intl. VSMM Conf., Ghent, 2005. [10] L. Krzanik, et al., "Usability-Driven Evolution of Context-sensitive Nomadic Media", Proc. MUM’05 Conf., Christchurch, 2005.
7. Conclusion Evolutionary approaches based on product lines can be applied to software development projects of various
138
[11] P. Kruchten, "A Taxonomy of Architecture Design Decisions," in Proceedings of 2nd Groningen Workshop on Software Variability Management (SVM2004), 2005.
[16] Klaus Pohl, Günter Böckle, and Frank J. van der Linden, Software Product Line Engineering: Foundations, Principles and Techniques, Springer, Heidelberg, 2005.
[12] C. Larman, Agile and Iterative Development: A Manager’s Guide. Addison-Wesley, 2003.
[17] K. Stenback and L. Krzanik, “Composite Patterns for Evolutionary Delivery”, to appear (2006).
[13] Nazim H. Madhavji, Juan Fernandez-Ramil, and Dewayne Perry, Software Evolution and Feedback: Theory and Practice, Wiley, 2006.
[18] V. Törmänen and L. Krzanik, “Prioritization of Options with Multiattribute Interval Specifications”, to appear (2007).
[14] Malan, R., and Bredemeyer, D., 2002. Less is More with Minimalist Architecture. IT Professional, Sept./Oct. 2002.
[19] J. Tyree and A. Akerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, pp. 1927, March. 2005
[15] J. Nielsen, Usability Engineering, Academic Press, Inc., San Diego, 1993.
[20] J. Vlissides, Pattern Hatching. Design Patterns Applied, Addison-Wesley, 1998.
139
140
Challenges in the Application of Feature Modelling in Fixed Line Telecommunications C.J. Gillan, P. Kilpatrick, I. Spence, T.J. Brown, R. Bashroush and R. Gawley The Institute for Electronics Communications and Information Technology (ECIT) The Queen’s University of Belfast (QUB), The Northern Ireland Science Park Queen’s Road, Queen’s Island, Belfast, Northern Ireland BT3 9DT, UK c.gillan,
[email protected] i.spence,tj.brown,p.kilpatrick,
[email protected]
Abstract The global telephone system is a complex transmission network, the features of which are defined to a very high level by ITU-T standards. It is therefore a prime candidate at which to target the application of software product line techniques, and feature modelling in particular, in order to handle the inherent commonality of protocols and variability in equipment functionality. This paper reports on an experimental feature modelling notation and illustrates it with application to the modelling of embedded software for the core network elements. We look at three of the fundamental challenges facing the adoption of feature modelling in the field and explain how we have strived to address these within our tools set.
The next major evolution of the system is the incorporation of low cost Passive Optical Networks (PONs). A PON replaces the final mile copper network with an Optical Line Terminal (OLT) located at the local telephone exchange connected to an Optical Network Unit in the home (ONU) and for this reason is sometimes known as the Fibre To The Home (FTTH) solution. The roll-out of PON
1. Introduction The global telephone system is a technology space which is almost entirely defined by standards, mostly internationally agreed, and therefore should be a fruitful proving ground for the application of studies in variability management techniques. There are however relatively few such studies[1] in the literature. As a market, the telecommunications sector is currently influenced by a number of factors for change meaning that there will continue to be an evolution of the inherent feature set. The global system continues to evolve in order to accommodate new service requirements, one example being the modifications such as real and virtual concatenation[2] introduced over the last decade to accommodate transport of data rates such as Gigabit Ethernet (GbE) and also Storage Area Networking technologies (SAN) such as Fibre Channel (FC) in addition to the traditional multiplexed hierarchies of 64 Kbit/s voice channels.
Figure 1. Representation of the TMN pyramid defined in ITU-T standard M.3010. Each higher layer functions as a client of each immediate lower layer which therefore takes on the role of a server. The FCAPS functional areas are perpendicular to each layer and therefore cross-cut each.
141
technology has so far mostly taken place in the Asia-Pacific region but is expected to generate a global market opportunity approaching $2.2 billion by the end of the current decade. It is worth noting that the financial case for PON role-out is based on the continuing update of novel broadband services as the revenue generating potential of traditional voice telephony approaches saturation, at least in the developed world. The addition of new services obviously introduces yet more variability into an already complex system. In turn, the System on Chip (SoC) revolution, which we briefly describe later in this paper, has lowered the cost of equipment manufacture, even for large multiplexers, thereby opening the vendor space to Small and Medium Enterprises (SMEs) whereas previously it was essentially the sole preserve of a small number of large multi-national companies with sufficient resources to fund ASIC developments. Of course, this also generates intense competition which translates to severe Time To Market (TTM) pressures on any company working in the space. At present there are estimated to be more than twenty five companies actively developing equipment in the PON sub-space. Clearly, the telecommunications sector is critically dependent on software both at the embedded level, for device control and monitoring of the Network Elements (NEs), and in terms of the management, service and business level applications which are the tools with which a telecommunications operator leverages option value from their installed base of NEs. Although extreme programming is now being considered as viable alternative in some areas of embedded systems programming[3], legislative restrictions and the requirement for five nines reliability (99.999 percent) within the telecommunications industry is such that it will probably remain tightly bound to the traditional software development life cycle for some time to come. Telecommunications software engineering is by its nature a very conservative environment although somewhat less so than the aeronautical and nuclear industries. Related to this is the fact that ISO9001 certification is essentially mandatory for any telecommunications equipment manufacturer and this seems to generate a level of conservatism favouring the traditional waterfall life cycle of software development. Still, appropriate software engineering techniques applied to this domain can help ameliorate the increasing TTM pressures faced by all vendors in the telecommunications space and we believe that feature modelling is one such technique. There are, as we see it, three main challenges facing the adoption of feature modelling in telecommunications development. 1. the number of variability points is excessively large, reflecting the network itself. In addition, as new technology, such as PON, arrives the feature set will grow rapidly. So, clearly we need some mechanism of standardizing our approach to domain modelling.
2. The second problem, driven by advances in hardware engineering, and is that SoC concepts drive more and more functionality out of the software into hardware within any one product but sometimes only well beyond the first release. This can be due to either added new functionality or sometimes to cost reduction activities providing an opportunity to migrate functionality on a board away from the processor onto an FPGA device or similar. 3. The third challenge facing the adoption of feature modelling in telecommunications software development is the fact that elucidation of a set of binary yesno feature points is woefully inadequate to reflect the functionality of a device. One needs to encompass behaviour within the feature modelling in order to capture fully the behaviour of a software load.
Regenerator Section Payload Multiplex Section
Figure 2. The generic physical view of the SDH frame structure. This needs to be contrasted with the logical layered view shown in figure 3. In this paper, we report on the strategies that we have followed to begin to address each of these challenges and we illustrate these with examples from our research tools set. However, we stress at the outset that much work remains to be done to achieve a successful application of feature modelling to telecommunications and we comment at the end of our paper on what we believe to be the way forward. Telecommunications is in itself a diverse field presenting substantial challenges for variability management some of which are unique to the field itself. We have developed our strategies within the telecommunications field and have not as yet attempted to apply them in a wider context.
1.1. Focusing on the Core Within this paper it is neither feasible nor appropriate to try to consider the entire telecommunications domain so we pick one subset of it for illustration. Specifically, we choose
142
the fibre optic backbone, at the heart of the global telecommunications system. Differences with the US and Canada at the protocol level notwithstanding, this implements the Synchronous Digital Hierarchy (SDH) protocol[4]. Our group has considerable experience in this sub-space through participation over several years in a program of industrial research, known as JigSAW, funded by Nortel Networks. So, for the rest of this paper we shall be applying feature modeling to SDH concepts. However, we stress that the points that we make are generally applicable in other telecommunications technology spaces.
1. the overhead bytes within the protocol definition (see figure 2) 2. the traffic rate layer within the SDH frame at which the overhead is found (see figure 3).
VC-12 (LP) VC-3 (LP) VC-4 (HP)
2. Divide and Conquer: The ITU-T Standards and TMN Perhaps the key enabler which facilitates global telephone systems, and that includes all technologies not just SDH, is that it is subject to strict standardization under the direction of the United Nations by the sub-division known as The International Telecommunications Union Standardization Sector (ITU-T). ITU-T is responsible for “studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.” In order to react to the changing telecommunications environment. At the outset of the digital communication era, in the 1980s, the ITU defined the Telecommunications Management Network (TMN) model to specify a set of standard functions and interfaces for management of a multitechnology network thereby reflecting the functionality offered by a system. The TMN framework is typically viewed as a pyramid composed of layers enjoying a client-server relationship to each other as shown in figure 1. Perpendicular to these layers are a set of vertical functional areas: • Fault • Configuration • Accounting • Performance • Security known as the FCAPS model for short. This TMN based strategy, we therefore propose, is the one that should be followed in order to divide and conquer the problem of feature scalability and evolution in telecommunications. We have approached feature modelling therefore by classifying features in line with the FCAPS model. This also, we have found, lowers the barrier to adoption by telecommunications software engineers. An alternative perspective is to take a hardware engineer’s perspective and to view the features in terms of
MS RS Physical Figure 3. Some of the logical layers, from the standard ITU-T G.707, within an SDH signal. An STM-1 frame contains 1xRS, 1xMS, 1xVC-4 containers. The VC-4 container has 3xVC-3s and each VC-3 has 21xVC-12. VC-4 is known as a high path layer (HP), VC-3 and VC-12 as low path layers (LP) In our experience, the latter approach alone generates a feature model with many more cross linkages, being therefore much more complex to maintain and manipulate, than starting with an FCAPS based model. Note, however, that within the FCAPS model, as shown in figures 4 and 5, generating using our tools set which is discussed later in the paper, there is still a need to take account of the traffic rates. However, we have to add that this FCAPS distinction alone is not sufficient to guarantee a unique feature model, and this in itself is a problem. For example figures 4 and 5 are essentially representing the same thing, that is the collection of performance monitoring data on the overhead bytes of a telecommunications signal. In figure 4,the sub-tree under Performance Monitoring has been developed to incorporate the logical layers of the signal which are shown in figure 3. This is why there is a dense mesh of features on the lower left-hand side of the screen. For example the overhead bytes B3 and G1 which are present in the High Path (HP) signals are shown as a subtree under the HP feature. The B3 byte is further expanded to encompass all of the properties pertaining to it such as 24 hour and 15 minute history bin collection. In the case of figure 5, the explicit specification of the logical layers hierarchy has been omitted and it is only im-
143
plicit contained within the Traffic Handling sub-tree on the right-hand side of the figure, a tree which is apparently decoupled from the Defect Monitoring feature. In this representation the Defect Monitoring feature incorporates all of the process issues surrounding collection of bit rate errors but does not distinguish the details for individual bytes. In general, we would probably also need to define a dependency between the Traffic Handling and Defect Monitoring feature. Indeed, this approach would be extensible to other functional areas of the system, such as the treatment of the features associated with the configuration of data for each port. This is because each port is ultimately involved in a connection at some particular data rate. However it would be just as valid to define a port in terms of logical layers.
3. Co-design feature models: handling the impact of FPGAs
Figure 4. A small number of the variability points related to SDH performance monitoring and their coupling to the multiplexing hierarchy (dashed lines). The named bytes are described in ITU-T G.707. The amount of clutter is clear.
Figure 5. An alternative, but equally valid way to present the same set of features as in figure 4. This illustrates the non-unique nature of the feature modelling technique.
System-on-a-chip (SoC) design, in its most general form, is about integrating all the components of an electronic system into a single chip, for example containing digital, analog, mixed-signal, and often radio-frequency functions all on one chip. SoC is therefore a key driver in decreasing the size of electronic boards. An SoC consists of this hardware but also of the software that controls the microprocessor and/or DSP cores, peripherals and interfaces. The design flow for an SoC aims to develop this hardware and software in parallel. For example, most SoCs are developed from pre-qualified blocks for the hardware elements (called IP cores), together with the software drivers that control their operation. The hardware blocks are put together using CAD tools; the software modules are integrated using a software development environment. The Field Programmable Gate Array (FPGA) is one technology that has facilitated the SoC revolution because, as its name implies, it is hardware which can be reprogrammed hardware. Often in the early life cycle of a product and FPGA will be used and later the hardware design will be migrated into an ASIC which remains the more cost effective solution for high volume production. Clearly, the SoC concept can have a practical impact on any telecommunications board in the sense that one might migrate some of the functionality into a combined electronic device over the life cycle of manufacture of the product. Take as an example performance monitoring collection. In the simplest case one has a traffic carrying ASIC that records bit rate defects per channel over the course of one second. So, one must then schedule a one second interrupt on the programmable interval timer (PIT) of the board’s microprocessor and within that piece of interrupt code collect the bit rate counts. Note the time constraint is important here. These are then passed, for example via a VxWorks message queue, to a lower priority process which stores the
144
counts into relevant data bins and performs various summations on the counts. Every fifteen minutes, as mandated by standards, we must roll over to a new bin but retain several of the previous bins, typically up to 96 of them. On top of this recording mechanism, at any instant, a management interface request to be given visibility of any bin, active or historical, may need to be handled. In essence, this is the set of features being recorded in figures 4 and 5; it is a significant part of the software implementation on any SDH equipment and scales in portion to the number of traffic channels carried. However, today it is possible to buy COTS ASICs that perform essentially all of this activity and thus render the entire software module for performance collection obsolete in any product variant which adopts such an ASIC. All that is required is to interface the management application to the registers holding history data. So, we need to able, in our feature models to handle the situation whereby we have this migration of a feature into hardware. We have previously introduced the concept of bi-directional feature modelling[5] to handle this situation. We illustrate its role in figure 6 in which we present a drastically simplified feature model for the situation. This figure
erating System.
4. Adding Behaviour Feature modelling, at least in its original form [6] is simply a set of binary points for which any given product adds the values yes/no. This alone is not sufficient to classify the behaviour of a telecommunications product as we show in figures 7 and 8 and discuss below. Consider first the case of a feature point with two mandatory child features and one alternative child feature, such as the one shown in figure 7. The collection, storage and reporting of performance monitoring data is one example of this. The two mandatory child features are 1. collection 2. sorting into bins. The alternative child feature relates to the way in which the data is reported. In older systems, where there are relatively few monitoring points and perhaps few history bins, it is viable to report performance monitoring data at the command line interface (CLI) without otherwise impacting the NE itself or indeed the management network overhead channels (the 192 Kbit/s D1-D3 DCC bytes defined in G.707) that
Figure 6. This figure illustrates the role of the platform node in our bi-directional feature modelling notation. In the potential migration of the PM collect-and-bin function from software to hardware is shown.
Figure 7. Example of a feature for which the three child features can be assigned to a specific behaviour pattern. The graphics are extracted from our feature GUI and we added some additional text, in this figure, to help explain these.
has been created by condensing the features in figure 5 into subsets and then showing the relationship between the subsets. Being much less cluttered, figure 6 is also able to show the link between functional features and the ASIC and Op-
145
link the management monitoring workstation to the NE being investigated. However, in larger NE systems this puts a heavy load on both the processor and the DCC channels, so it is preferable to perform bulk FTP transfers of compressed files at set intervals. They key point here is that the behaviour of the parent feature can be classified as execution of each child in succession from left to right; that is the behaviour pattern is always the same. We have augmented out feature modelling GUI to include the Use Case Maps (UCM) notation to capture behaviour. Actually this is line with totally independent recommendations of the ITU where UCM has been adopted and renamed URN. The ITUT Z Series, Languages and General Software Aspects for Telecommunications Systems, has two standards which are of particular relevance:
Task Force (IETF). With reference to the ISO seven layer model, SNMP is considered as an application layer protocol and in turn it uses UDP, at layer four, as a server layer. Therefore, SNMP is used by network management systems to monitor network-attached devices particularly for alarm conditions requiring administrative attention. There will additionally be at least one kind of Command Line Interface (CLI) for the system. CLIs are generally preferred by telecommunications operators as opposed to the use of SNMP by enterprise operators or even for Customer Premises Equipment (CPE). A key advantage of any CLI
Z.150 User Requirements Notation (URN) - language requirements and framework Z.152 ITU-T Study Group 17, Progress work on URN Use Case Map Notation (Z.152). This is not yet formally adopted as a standard but it is expected that it soon will be adopted. Of course not all features will have a unique behaviour assigned to them. Consider for example the feature shown in figure 8. At first sight this looks the same as the feature in figure 7 with two mandatory child features and one alternative child feature. However, in this case the feature represents the presence of a variety of management interfaces. All products require a serial port interface, which is typically based on an Intel NS16550 chip, so that they can be commissioned in the field. This interface can be connected to the serial port on laptop PC using an appropriate serial port cable. As serial ports are readily supported, for example by the Microsoft Windows HyperTerminal program, this interface provides the simplest type of physical connection to the NE obviating the need for the presence of a network of any kind. Of course, there needs to be a layer of software to handle commands and to provide responses to those commands at the interface. In summary, the serial port interface is the primary route by which an NE is commissioned onto the network and brought into service making it a mandatory feature. Once in this state, network based management interfaces are clearly more suitable and at least one such networked interface will always be provided thereby enabling the capacity to remotely manage the NE from a Network Operations Centre (NOC) which could, in principle, be anywhere in the world. Almost all products now incorporate an SNMP interface as that is a very popular management interface in the enterprise field. SNMP standards for Simple Network Management Protocol (SNMP) which is a part of the Internet Protocol (IP) suite as defined by the Internet Engineering
Figure 8. For this parent the child features do not have an associated unique behaviour pattern and so represent an entirely different type of feature than the one in figure 7. is that one can write scripts, for example in Perl, to automate any amalgam of required command line operations. By contrast, when using SNMP, a layer of client software is required. In the US and Canada provision of the CLI known as TL1 is essentially mandatory for transmission equipment because of the widespread use of Telcordia network management software, whereas in the rest of the world a different kind of CLI can be just as acceptable. TL1, which is in fact based on the ITU-T Z.300 series Man Machine Language (MML) standards, was developed by Bellcore (which has subsequently been renamed Telcordia Technologies) around 1984 for the Regional Bell Operating Companies (RBOCs) in North America as a language with which to manage NEs. TL1 is full standardized in publication GR-831 by Bellcore. Telcordia Operation Support Systems
146
(OSS) such as Network Monitoring and Analysis (NMA) uses TL1 as the Element Management System (EMS) protocol for example and therefore drove NE vendors to implement TL1 in their devices. Generally though in the case of embedded systems, each vendor will also define their own CLI and a proprietary set of rules to which all commands within their CLI conform. One such example is Cisco IOS. This diversity of CLIs is represented by the features alt1 and alt2 in figure 8.
system[7, 8, 9]. Our feature modelling tool, which has been illustrated earlier in this paper, is part of a wider research effort to generate feature architecture development tools. This is reflected in the grand view of our QUB/ECIT tools set in figure 9. If we consider the actor in the centre of figure 9 as the end goal of creating a running software system, we can identify several steps to achieving this by working inwards from the periphery of the figure. On the left-hand side we have the feature modelling tool which we have illustrated in this paper. The output from this tool feeds directly into the architecture editor (ADLARS) tool within which we can add event driven behaviour, this being a well known technique for construction of embedded systems. The ADLARS tool can create code although currently only Java. The PATTERNAL tool, which is still being actively researched is used to represent object-oriented patterns in visual notation.
5.1. Addressing the documentation requirements
Figure 9. Overview of the QUB/ECIT tools set for feature guided architecture development which is explained further in the text.
We cannot assign a unique behaviour path to the parent feature here. So, clearly, the parent feature in figure 8 is an entirely different one than that depicted in figure 7. So, it is only by adding a notation for behaviour to the features that permits us to make a distinction between them. We have found UCM to be well suited to this. We have also found, by distinguishing features in this way, that we can gain information on possible implementation strategies. Figures 7 and 8 include comments on the possible relevant object oriented patterns for implementation in each case.
5. Beyond Feature Modelling To conclude the paper we point out that we do not see our work on feature modelling in isolation from other efforts that must be undertaken to deliver a working software
It is our observation that in the telecommunications software industry today the process of preparation of ISO9000 compliant documentation is largely divorced from the creation of the core asset code base thereby leading to substantial duplication of effort. Yet there are now many techniques, driven largely by Web technologies, that would facilitate substantial auto-generation of documentation. In addition, one then removes the problem of keeping document and code in synchronization, a working practice that is particularly difficult to maintain under TTM pressures. We have found that it is actually quite straightforward to incorporate the aforementioned Web technologies into our tools set therefore overcoming, we suggest, the aforementioned disconnection between documentation and implementation. To this end, we use an XML representation behind the scenes of our GUIs and combine this with XSL transforms to generate documentation from our feature models in such formats as PDF, Word, Excel, HTML, etc. The Word for PDF formats remain, in our experience, by far the most popular for ISO 9000 review process in most companies. We should point out that this idea for documenting software is in itself not particularly new but is an evolution of Knuth’s literate programming idea. In the eighties, Donald Knuth created a language known as The Web language, and later CWeb, to allow the preparation of a single document containing all the information that is needed both to produce a compilable Pascal program, and later C, and to produce a well-formatted document describing the program in as much detail as the writer may desire[10, 11].
147
6. Summary and Conclusions In this work, we have addressed some of the main challenges facing the adoption of feature modelling within the telecommunications software industry and have focused on the role of performance monitoring within SDH network elements to illustrate out ideas. We propose firstly that, in order to overcome the sheer size of the variability management problem, the analysis of features should be guided by existing domain specific partitioning ideas, specifically the FCAPS model. This will lower the barriers to adoption of the techniques in what is quite a conservative industry. Next, we have explained how the role of SoC forces us to integrate hardware co-design features at least into the software engineering feature model. We have then argued the case for the need to add behaviour to a feature model in order to clarify its meaning. Finally, we have explained how we are incorporating behaviour guided feature modelling into out tools set for architecture development. As we have shown, there is no unique way to express the feature model for a telecommunications system and we believe that overcoming this hurdle would expedite the acceptance of the technology in the field. Clearly, there is a requirement for more and deeper case studies in the area.
7. Acknowledgements The Institute for Electronics Communications and Information Technology (ECIT) is jointly funded by The Queen’s University of Belfast, Invest Northern Ireland and The Department of Employment and Learning for Northern Ireland.
References [1] K Lee, K C Kang, S Kim and J Lee, FeatureOriented Engineering of PBX Software Proceedings of the Sixth Asia-Pacific Software Engineering Conference (APSEC’99) page 394, pub: IEEE Computer Society.
[4] See the ITU-T section at the web address http://www.itu.int. [5] T J Brown, R Gawley, R Bashroush, I Spence, P Kilpatrick and C J Gillan, Weaving Behavior into Feature Models for Embedded System Families, Proceedings 10th International Software Product Line Conference, Baltimore Maryland, IEEE Computer Society, pp5264, August 2006, ISBN 0-7695-2599-7. [6] K C Kang, S G Cohen, J A Hess, W E Novak and A S Patterson, Feature Oriented Domain Analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR21, available from the Software Engineering Institute, Carnegie-Mellon University 1990. [7] T J Brown, I Spence and P Kilpatrick, A Relational Architecture Description Language for Software Families in Proceedings of the 5th International Workshop on Product Family Engineering, Sienna, Italy 2003. [8] T J Brown, R Bashroush, I Spence and P Kilpatrick, Feature-guided architecture development for embedded system families, in Proceedings IEEE/IFIP Working International Conference on Software Engineering (WICSA ’05), pp. 223-226, Pittsburgh, 2005. [9] R Bashroush, T J Brown, I Spence and P Kilpatrick, ADLARS: An Architecture Description Language for Software Product Lines, Proceedings of the 29th IEEE/NASA workshop on software architecture, Nov. 2005. [10] D. Knuth, Literate Programming, 1992, pub: Center for the Study of Language and Information - Lecture Notes, ISBN 0-937-07380-6 [11] D. Knuth, The CWEB System of Structured Documentation, Version 3.0, 1993, pub: Addison-Wesley Professional ISBN: 0-201-57569-8
[2] See ITU-T standards: G.707 Virtual Concatenation (VCAT), G.7041 Generic Framing Procedure (GFP) and G.7042 Link Capacity Adjustment Scheme (LCAS). [3] P Manhart and K Schneider, Breaking the Ice for Agile Development of Embedded Software: An Industry Experience Report, Proceedings of the 26th International Conference on Software Engineering (ICSE’04), pages 378-386, pub: IEEE Computer Society
148
Using Problem Descriptions to Represent Variability For Context-Aware Applications Mohammed Salifu
Bashar Nuseibeh Lucia Rapanotti The Open University, Milton Keynes, UK {M.Salifu, B.Nuseibeh, L.Rapanotti, T.T.Tun}@open.ac.uk
Thein Than Tun
variability is expected to increase the complexity and scale of traditional variability analysis and management, the impact of which has remained unexamined [23]. The primary objective of our research is to develop an approach to identify, represent, analyse and reason about common and variant sub-problems; and to link such representations to architectural variability types. It is aimed at problem descriptions of product-families operating in varying context environments. Therefore, the emphasis is on contextual variability in the problem space rather than solution space. Other issues relevant to context-awareness are (1) the monitoring of operating context, (2) the detection of changes in context and (3) the switching of operation from one variant to another. Variation in context may well induce variations in each of these issues. The remainder of the paper is structured as follows: we begin with a brief overview of related work (section 2), followed by a brief description of problem frames (section 3), which we use as an approach to represent identify problem descriptions. We then describe our proposed approach to represent problem variability (section 4), and provide a detailed illustration of the feasibility and applicability of problem diagrams to describe and reason about problem variations (sections 4.1-4.3). We conclude (section 5) with a discussion of lessons learnt and further work.
Abstract This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work.
Keywords Contextual variability; context-awareness; problem variants; solution variants; product-families
1. Introduction There is an increasing expectation for softwareintensive devices to be context-aware, and many consumer devices such as mobile phones, which are developed as product families, are expected to follow this trend. By context-aware, we mean that products are expected to change their behaviour in response to changes in their operating environments due to changes in properties of domains that are external to them but still affect their behaviour. Reasons for changes in context vary from fluctuating resources upon which a product relies (e.g., reduced bandwidth for a mobile phone) to different operating locations (e.g., a mobile user travelling long distance) or the presence of other objects (e.g., Bluetooth-enabled phones) [7]. Changes may also be caused by users’ preferences; for example, users of a mobile phone may require a particular set of features to be available to them while at work and a different set while at home. Mobility is therefore central to our notion of context. This context-induced
2. Related Work This section briefly discusses current representation of variation points and dependency relations between variants. This will be followed by a discussion of related approaches to context-awareness.
2.1 Variability points and dependencies Variations in requirements are generally regarded as variations in the intention of a stakeholder in terms of the intended use of an end product [5]. This type of variability has often been modelled and analysed using feature diagrams [34], which capture user-visible functionalities. However, Liaskos et el [23] have observed that variability in requirements may be exacerbated by contextual variability which they refer to as background (or unintentional) variability. They
149
[2] which is aimed at supporting platform heterogeneity in a multi-device varying context environment. However, developing such middleware requires good knowledge of the domain, something not always available. Current application level approaches to contextawareness also tend to focus on specific problem issues such as self-healing or self-reconfiguring [10] and platform resource fluctuations or differences in the cost of computing resources [31]. Those that are more general, such as the work of Oreizy et el [29], tend to be vague in discussing issues such as monitoring and switching at a very high abstract level, lacking details on what the underlying requirements are. Therefore, the discussion of possible variability in monitoring or switching is absent. In the case of Oreizy et el, an attempt is made to define context-aware infrastructure by a prescribed set of rules with which applications operating in such an environment must comply. But this still does not give sufficient detail as to what the underlying requirements are. All these approaches are largely solution space oriented to context-aware application development. However, Zhang et el [37] has argued for a requirements approach to adaptive software development, and that the semantics of adaptation is made explicit in requirements. This they noted enables the evaluation of adaptive systems not only in terms of the requirements of problem variants in different context but also in terms of how adaptation is achieved. This position is consistent with Hayes et el [15] arguing for deriving specification of embedded systems from that of its environment. In this case, the specifications are first expressed in terms of the domains of the physical world after which they are derived in terms of the solution machine’s interface to the world. Related work that has tried to deal with both context-awareness and product-families is based on software architecture configuration techniques [2, 12, 13, 19]. Each of these is briefly discussed later in this section. The configuration of an architecture refers to its set of components, their interconnections and the constraints defining the behaviour of this architecture [35]. The replacement of such a configuration with a new (or different) one after it has been released or during the operation of the applications based on it, is referred to as reconfiguration [21, 28]. The work of Gomaa and Hussein [12, 13] is based on the use of architectural styles or patterns, such as the client server architectural style, to construct what they refer to as a reconfiguration pattern (based on the style of the generic architecture). A reconfiguration pattern is used to guide the process of automatically deriving
argue that feature diagrams do not take contextual variability into consideration and are therefore unsuitable for representing and reasoning about variability of systems where contextual changes are common place. Therefore, they have proposed a goaloriented approach which takes into account both intentional and unintentional variability in its representation. In an earlier paper [32], we discussed in detail the work of Bachmann and Bass [3] on sources of variability types, and that of Jaring and Bosch [17] on relational dependencies which we argued are consistent with earlier observations by Buhne et el [6]. However, we also looked at other representation using use cases [6]. We concluded that what these approaches have in common is that, none of them explicitly consider the properties of the operating contexts and their constituent domains. For instance, the work of Buhne et el on using use cases to communicate variability to consumers is effective in showing user visible functional dependencies. It is, however, weak at capturing other contextual information such as differences in technology. To the best of our knowledge, Liaskos et el’s work is the only attempt at understanding the impact of contextual variability on variant requirement derivation. However, their approach assumes a ‘greenfield’ development and does explicitly considered the issue of variability in adaptive elements [4]. By adaptive elements, we mean techniques for context monitoring, context change detection and variant switching. These elements are discussed further in sections 4.2 and 4.3.
2.2 Context-Awareness & Adaptive product families Since our work deals with product-family and context-awareness, we are interested in adaptive approaches that address variability in context and adaptation mechanisms. Current approaches to context-awareness are largely focused on the use of middleware to support varying contexts [25] such as the One.World approach by [14] and the Odyssey approach by [26] which are aimed at supporting heterogeneity and hiding variations in context from application software. However, Abowd [1] has noted that a middleware-based approach to context-awareness is insufficient, as some contextual changes are only visible in the application level or requires the interpretation of human user. Also, context-aware middleware tends to focus on specific application domains such as hiding variations in platform infrastructure or location details in distributed computing [25]. An example is the work of Apel et el
150
need for understanding the physical context of software problems. We now introduce and discuss briefly some of problem frames notation and concepts relevant to our discussion. This is done with the aid of a simple problem diagram in Figure 1.
one product-line member from a different one. This can be argued to be a generalised form of parameterisation [30], as all instances of this product-family must conform to the style and different members are instantiated by changing the values of parameters. The work of Kim et el. [19] is similar to that of Gomaa and Hussein. The key difference is that Kim et el. provide an architectural description language for describing architectures and modifications to be applied to them during reconfiguration. The example in [19] adopts a pipe-and-filter architectural style and could therefore be argued to be a specialised case of the work of Gomaa and Hussein with the addition of a means to describe the architecture and its modifications. The work of Apel and Bohm [2] is based on the use of a layered architectural style to design a reconfigurable middleware for a context-aware environment. In this work, context-aware environment refers to an operating environment with network bandwidth fluctuations, connection interruptions, device mobility and resource-constrained devices. The services provided by this architecture are operating system-based and largely limited to the network infrastructure. In designing the reconfigurable middleware architecture, Apel et el have adopted the product-line paradigm and produced a generic architecture from which specific architectures tailored to different environments are produced as and when the context requires, during runtime. Again, to the best of our knowledge, it is only the last three approaches that have considered both product-family and adaptability and in the case of Apel et el context-awareness too. However, these attempts are all solution space oriented and implicitly consider the underlying requirements that lead to the use of their approaches.
e
Library Database
d Register new reader
Registration Handler
c a b Input Device
Library Member
b: LM!{Personal Details}, a: ID!{commands} e: RH!{Reader Record} d: LD!{New Reader Record} c: LM!{Personal Details} Figure 1: A Simple Problem Diagram. In Figure 1, the rectangles with no stripes (Library Database, Input Device and Library Member) represent physical domains of the problem world whose properties are relevant to the problem. The dashed oval represents the requirement, and the rectangle with a double stripe is the machine domain whose specification is required. Thick lines between the domains present sets of shared properties of the domains involved and are referred to as shared phenomena. For example, the shared phenomenon e indicates that details of reader records are shared between the two domains Registration Handler (RH) and Library Database (LD). The prefix RH! suggests that RH can manipulate the reader records, whilst LD can only observe them. The dashed line between the requirement and Library Member (LM) denotes that the requirement references the property of LM, and the dashed line with an arrow head between the requirement and LD denotes that the requirement constrains the property of LD. It means that when the library member provides personal details, a new reader record is expected to be added to the database. A problem frame is a known class (pattern) of problem with a well understood structure and concern. The problem diagram in Figure 1 represents an instance of a basic type of problem known as the Workpieces frame [16]. The main concern of this frame is as follows:
3. Problem Frames for Representing Variability The Problem Frames approach (PF) to requirements engineering provides a conceptual basis for analyzing software problems in context [16]. In this approach, problems comprise three descriptions: (i) a description of the given properties of the world in which the problem resides (domain knowledge), (ii) a description of the required properties of the world (requirement), and (iii) a description of what the machine, or the computer implementing the software, must do to affect the required properties (specification). Unlike other requirements engineering approaches such as Use Cases [8] and Goals [36], PF is particularly suitable for analyzing context-awareness because it emphasizes the
151
“A tool is needed to allow a user to create and edit a certain class of computer-processable text or graphic objects, or similar structures, so that they can be subsequently copied, printed, analysed or used in other ways. The problem is to build a machine that can act as this tool.”
4. Outline of Our Approach Given a requirement R, our approach begins with the identification and representation of a problem diagram aiming to fit a known problem frame or a variant of a basic frame. In some cases, R may need to be decomposed into sub-requirements in order to fit known problem frames. Using available knowledge about the problem context, we identify a set of variables (V1, V2 … Vm) representing possible sources of contextual variations. Assuming a non-varying context, we construct problem diagram for the requirement. The resulting problem diagram is contextunaware. We next vary each of the contextual variables one at a time accessing its impact on the context-unaware problem diagram. Where a variation in contextual variable causes requirement R not to be satisfied, we derive a variant problem diagram for this context situation ensuring that R is satisfied. Note that in some cases, it may be necessary to arrange the contextual variables in sequence as they may be some dependency relations between them requiring simultaneous consideration of two or more variables. This case is not considered in this paper but is being explored. Following the derivation of problem variants for variations in context, we carry out variants analysis and address context-awareness concerns such as the detection of changes in varying context. This involves the identification of domains and phenomena to be monitored in the problem world in order to do so. This may introduce new physical domains inducing new sub-problems into the problem analysis. For instance, problem diagrams to monitor and report changes in physical domains or to update designed lexical domains storing contextual information. We next consider the composition of problem variants to enable the context-aware product operate in all contexts. Other concerns such as switching, interference, consistency, etc can also be addressed. These concerns are only briefly discussed.
In Figure 1, the domain Library Database is the “computer-processable” object, and Registration Handler is the “tool needed” to allow Library Member using Input Device to “create” a member record. Although most software problems, when decomposed, are expected to fit the basic frames, Jackson acknowledges that there could be problems that have extra concerns. A problem variant frame represents a new problem class (pattern) that closely matches a known problem frame such as the workpieces frame but differs because of the presence of a problem domain or control pattern not found in the existing problem frame [16]. One of such variants is called a “connection variant”. A connection variant introduces a domain into the basic frame diagram. For example, Figure 2 shows a problem diagram that is similar to the one in Figure 1, with an additional connection domain Librarian between Input Device and Library Member. The new diagram signifies the fact that, rather than library member, it is the librarian who interacts with machine through the input device. Since this problem diagram shares the main concern of the problem diagram in Figure 1, we regard this new problem diagram as a variant of the original problem diagram in Figure 1. e
Library Database
d Register new reader
Registration Handler
c a
Input Device
b
Librarian
f
Library Member
b: L!{Membership Details}, a: ID!{ commands } e: RH!{Reader Record} d: LD!{New Reader Record} c: LM!{Personal Details} f: LM!{Membership Form}
4.1 A pilot study This study is intended to illustrate the use of problem descriptions for capturing contextual variability in problem variant diagrams. This is done with regards to software applications for contextawareness. Software is required to control the transmission of pictures from an external digital camera (Concord EyeQ [9]) into a mobile phone’s storage (Nokia 9500 [27]) under the control of the phone user. This is to be
Figure 2: A Variant Problem Diagram. In this paper, we use the notion of variant frames to capture contextual variability in context-aware applications.
152
done using Bluetooth wireless technology at two different locations. In the first case, the transmission is to be done without encryption while in the second case it should be done using the Secure Socket Layer/Transport Layer Security protocol (SSL/TLS) [18]. These are for secure and non-secure locations respectively. Further details are:
a
c
s
External Digital Camera
a
Secure Environment
Controller 1
b k c
Phone Internal storage
1. The phone makes a request for a picture which must be transmitted, received, and saved on its internal storage. 2. The camera prompts a user when transmission starts and when it stops. 3. All transmissions must be secured. This means that, all picture transmissions in a non-secure location must be encrypted. However, encryption is not necessary in a secure location. The software must adapt its behaviour (i.e. carry out encryption or not) without explicit user involvement.
R
Phone User p
s:PIS!{receivespicture, savespicture} a:C1!{RequestTransmission, TerminatesTransmission} b: EDC!{BeginsTransmission, EndsTransimission} p:PIS!{receivespicture, savespicture} c: PU!{StartTransmission, StopTranmission} k:PU!{ConfirmsStartedTransmission, ConfirmsCompletedTranmission} Figure 3: A basic problem diagram for secure location.
Considering the pilot study along the three descriptions of problem frames concepts, the following observations are made: 1. The underlying requirement (R) is a secure transfer of pictures from a digital camera to the mobile phone’s storage. 2. The need to secure or not, represents one source of a contextual variable in W.
Non-Secure Environment
a
Controller 2
External Digital Camera
a
SSL/TLS
c
b k
s
c
R
Phone User
The overall requirement (R) fits a problem frame known as Command Behaviour frame. Therefore, there is no need for decomposing R into sub-requirements. Also, assuming a secure location the problem diagram for this is as given in Figure 3. This represents our basic problem diagram and assumes a non-varying context (i.e. all operating locations are secured). Hence, no phenomena relevant to the detection of changes in context are identified and represented. Using the basic problem diagram in Figure 3 and withdrawing the assumption of a secure location, we realise that the requirement will not be satisfied using this problem diagram in non-secure locations. Therefore, we now derive a variant problem diagram for non-secure locations. To achieve this, we apply a Connection variant as it is suitable for connecting a problem domain to a machine domain where there is a need for intermediate processing. This introduces a domain into the problem diagram to carry out the required encryption/decryption. Figure 4 gives the resulting variant problem diagram.
p
Phone Internal storage
Figure 4: A variant problem diagram for nonsecure location.
Non-Secure Environment
a
Phone SSL/TLS
a-secure
Camera SSL/TLS
a
Figure 5: A partial problem diagram of Figure 4 showing further details of the SSL/TLS domain. Even though the SSL/TLS domain is shown to be a single domain in the problem diagram in Figure 4, a critical look will show otherwise. This is shown in Figure 5.
153
development of adaptive software and reuse, both of which are essential to context-awareness. We now take a closer look at each of the problem variants and attempt to address some of the contextawareness concerns such as monitoring and change detection. Consider a situation in which the transfer of a picture started in a secure location and continues into a non-secure one. There will be a need for suspension of transmission to switch from a non-secure channel to a secure one after which transmission must be resumed at the point for which it was suspended. This is a significant problem, and raises concerns such as initialization and interference [16]. One possible approach to compose the two subproblems is through the use of composition frames proposed by Laney et el [22]. This effectively inserts a controller between the problem world domains and the sub-machines. All interactions between the submachines and the problem world domains are intercepted by the controller and the constraints defined by the composition requirements determine permissible patterns of interactions. In this case, the composition rules are dynamically determined by the environmental properties (secure or non-secure). We define the composition requirement as follows:
The introduction of the SSL/TLS domain has resulted in an addition of the shared phenomenon ‘asecure’, which is defined as follows: a-secure: PS!{secRequestTransmission, secTerminatesTransmission}
It is worth noting that SSL/TLS represents a solution to the sub-problem of encryption/decryption which we do not need to solve as the solution is given. If this was not the case, then a sub-problem would have to be introduced to carry out the securing of the transmission channel. Problem frames treats solution machines to sub-problems as given domains when used in other problem diagrams. The use of problem frames or variant frames in this way contributes to knowledge reuse in the problem space as they represent recurring problem classes. In addition to that however, our introduction of a nonvarying context problem diagram from which problem variants are derived for different context situations represents further reuse. This allows us to reuse the analysis done on the original problem in Figure 3 on the one in Figure 4. It also enables reuse in different contexts of the same product. However, non-varying context problem diagrams and their related variants may well be composed and used in different products operating in the same application domain. This is not illustrated in this paper but is being explored.
RC: In a non-secure location make sure that picture transmission is handled by Controller2. In a secure location make sure that picture transmission is handled by Controller1.
4.2 Problem Variants Analysis The approach taken in the variant derivation is based on the application of the standard principle of separation of concerns [11]. That is, the concerns of each of the sub-problems were considered independent of that of managing the varying operating context. For instance, the sub-problem shown in Figure 3 is suitable for an operating environment where encryption is not required. The designed machine assumes this fact and will always operate under it. Alternatively, the subproblem diagram shown in Figure 4 assumes an operating environment where encryption is required and will always operate under this assumption. We therefore consider these two sub-problems as being context-unaware as they assume fixed contexts of operations and therefore do not explicitly carry out checks on the operating environment in order to adjust their behaviour. This approach has enabled us to consider the problems of monitoring, change detection, and managing varying contexts outside the original sub-problem variants. This has been observed by McKinley et el [24] to contribute positively to the
cda Controller2 cra Context Controller
cdb Controller1
cdc
Context Sensor
crb
RC
cdc
cdc: CS! {SecureEnv, NonSecureEnv} cda: CC! {Initialize(InitState), Start, Suspend, Enquire(CurrentState)} cdb: CC! {Initialize(InitState), Start, Suspend, Enquire(CurrentState)} cra: C2! {Running, Stopped} crb: C1! {Running, Stopped} Figure 6: A Composition Problem Diagram. Figure 6 gives a possible problem diagram for such a composition, referred to as a composition problem diagram. The diagram suggests that the Context
154
different domain which in turn will vary the existing phenomena will be required. Therefore, we are seeking to extend the definition of problem variant to take such situations into account. Raising the abstraction level of domains is one possible line of investigation. For instance, raising the abstraction level of the digital camera in the pilot study to a “Bluetooth device” will allow for more variants to be derived. Replacing the camera with a “Bluetooth printer” may result in a Control variant frame. So far we have considered only one source of contextual variability. Where many sources of contextual variability are present with crosscutting concerns, it may be necessary to use other techniques to capture such variability sources and their dependencies. This will then be used to inform the variant problem derivation and formulation composition requirements. This is currently being investigated. We have not considered the detail specification of each sub-problem machine and that of the context controller in this paper. This is not necessary in illustrating the fundamentals of our approach. However, in deriving the detail specification of each machine, especially in the case of the context controller machine, it may be necessary to introduce some form of formality in deriving a specification. To this end, we are currently exploring the possible use of event calculus [20, 33] for its suitability in doing so.
Controller (CC) can monitor the environmental property and switch between Controller1 and Controller2 accordingly to meet RC. In the diagram, CC can enquire current states of Controller1 and Controller2, and initialise Controller1 and Controller2 to required states, as well as start and suspend executing of Controller1 and Controller2. These operations allow CC to switch between secure and nonsecure transmission in response to environmental properties dynamically.
4.3 Discussion Using the problem frames approach allows us to separate composition concerns from the basic problem in each problem variant. We therefore argue that problem frames facilitate separation of concerns by allowing different sections or sub-problems of a bigger problem to be considered individually. They allow for different levels of abstractions of domains and their phenomena in variant problem representations. This, we suggest is useful for the representation of contextaware applications as illustrated in the pilot study. An alternative approach to that of ours would be to consider the problem of context-awareness in the original problem variants diagrams. That is, Figure s 3 and 4 each address the issue of context-awareness as part of the problem. The problem with this alternative approach in our view is that it (1) tries to address many concerns simultaneously and (2) does not scale as each subsequent addition or derivation of a variant will have to be based on the immediate preceding one (to maximise reuse). These could create difficulties for analysts working on later variants.
Acknowledgements We thank the EPSRC for their financial support. We also thank our colleagues Andreas Classen, Armstrong Nhlabatsi, Yijun Yu, Robin Laney and Michael Jackson for many useful discussions and feedback on earlier drafts of this paper.
5. Conclusions & Further Work The focus of this paper has been on the representation and analysis of contextual variability due to its importance for context-awareness. We have illustrated, using a pilot study, the use of problem descriptions for capturing contextual variability in problem variant diagrams. This is done using Jackson’s notion of variant frames. Despite the apparent suitability of problem descriptions for representing contextual variability, Jackson’s notion of problem variants is restrictive. The current definition requires either the addition of a domain or changes in the control pattern of an existing problem diagram. For instance, the digital camera in our pilot study could easily be replaced with a printer or a projector and a mobile phone could be required to interact with all these in different contexts. In such a case, the replacement of an existing domain with a
References 1.
2.
3.
4.
5.
155
Abowd, G.D., "Software engineering issues for ubiquitous computing", in ICSE '99, 1999, Los Angeles CA, IEEE CNF. Apel, S. and K. Böhm, "Towards the development of ubiquitous middleware product lines", in Software Engineering and Middleware: 4th International Workshop, SEM 2004, 2005, Linz, Austria. Bachmann, F. and L. Bass, "Managing variability in software architectures", in SSR'01, 2001, Toronto, Ontario, Canada, ACM Press. Berry, D.M., B.H.C. Cheng, and J. Zhang, "The four levels of requirements engineering for and in dynamic adaptive systems", in REFSQ'05, 2005, Porto, Portugal. Bosch, J., "Design & use of software architectures adopting and evolving a product-line approach", 2000, Great Britain, Addison-Wesley, 1-354.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18. 19.
20. 21.
22.
Bühne, S., G. Halmans, and K. Pohl, "Modelling dependencies between variation points in use case diagrams", in Proceedings of the 9th International Workshop on Requirements Engineering Foundation for Software Quality (REFSQ), 2003, Klagenfurt, Austria. Chen, G. and D. Kotz, "A survey of context-aware mobile computing research", in Technical Report TR2000-381, 2000, Dartmouth Computer Science. Cockburn, A., "Writing effective use cases", 1st ed, 2001, Longman, Upper Saddle River, NJ, AddisonWesley, 1- 304. Geeks.com, C., "Concord eyeq go wireless 2mp bluetooth digital camera", 2006, http://www.geeks.com/details.asp?invtid=EYEQ&cat=C AM. p. 1-2. Georgiadis, I., J. Magee, and J. Kramer, "Self-organising software architectures for distributed systems", in ACM SIGSOFT Workshop on Self-Healing Systems (WOSS ‘02), 2002, Charleston, South Carolina, ACM. Ghezzi, C., M. Jazayeri, and D. Mandrioli, "Fundamentals of software engineering", Second ed, 2003, Upper Sadle River, New Jersey, Prentice Hall. Gomaa, H. and M. Hussein, "Dynamic software reconfiguration in software product families", Lecture Notes in Computer Science, 2004, 3014/2004, p. 435 444. Gomaa, H. and M. Hussein, "Software reconfiguration patterns for dynamic evolution of software architectures", in Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04), 2004, IEEE CNF. Grimm, R., et el., "System support for pervasive applications", ACM Transactions on Computer Systems., 2004, 22(4), p. 421–486. Hayes, I.J., M.A. Jackson, and C.B. Jones, "Determining the specification of a control system from that of its environment", Lecture Notes in Computer Science 2805- Proceedings of FME2003, 2003, p. 154-169. Jackson, M., "Problme frames: Analyzing and structuring software development problems", 1st ed, 2001b, New York, Oxford, Addison-Wesley, 390. Jaring, M. and J. Bosch, "A taxonomy and hierarchy of variability dependencies in software product family engineering", in Proc. of the 28th Annual International Computer Software and Applications Conference (COMPSAC'04), 2004, IEEE CNF. Kegel, D., "Ssl / tls", in Accessed on October 11th 2006, 2001, http://www.kegel.com/ssl/. Kim, M., J. Jeong, and S. Park, "From product lines to self-managed systems: An architecture-based runtime reconfiguration framework", in Workshop on the Design and Evolution of Autonomic Application Software (DEAS 2005, 2005, ACM Press. Kowalski, R. and M. Sergot, "A logic-based calculus of events", New Generation Computing, 1986, 4, p. 67–94. Kramer, J. and J. Magee, "The evolving philosophers problem: Dynamic change management", IEEE Transactions on Software Engineering, 1990, 16(11). Laney, R., et el., "Composing requirements using problem frames", in Proceedings of the 12th
23.
24. 25. 26.
27. 28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
156
International Requirements Engineering Conference (RE'04), 2004, Kyoto Japan., IEEE Computer Society Press. Liaskos, S., et el., "On goal-based variability acquisition and analysis", in 14th IEEE International Requirements Engineering Conference (RE'06), 2006, Minneapolis/St. Paul, Minnesota, USA,, IEEE CNF. Mckinley, P.K., et el., "Composing adaptive software", IEEE Computer, 2004, 37(7), p. 56-64. McKinley, P.K., et el., "Composing adaptive software", Computer, 2004, p. 56-64. Noble, B.D., M. Price, and M. Satyanarayanan, "A programming interface for application-aware adaptation in mobile computing", in February 1995, 1995, School of Computer Science, Carnegie Mellon University. p. 114. Nokia, F., "Enterprise: Developing end-to-end systems", 2006, Nokia Forum, Online. p. 1-54. Oreizy, P., et el., "An architecture-based approach to self-adaptive software", Intelligent Systems and Their Applications, IEEE [see also IEEE Intelligent Systems, 1999, 14(3). Oreizy, P., N. Medvidovic, and R.N. Taylor, "Architecture-based runtime software evolution", in Software Engineering, 1998. Proceedings of the 1998 (20th) International Conference on Software Engineering, 1998. Perry, D.E., "Generic architecture descriptions for product lines", in Lecture Notes in Computer Science, 1998, Springer Berlin / Heidelberg. Poladian, V., et el., "Dynamic configuration of resourceaware services", in Proceedings of the 26th International Conference on Software Engineering ICSE '04, 2004, IEEE Computer Society. Salifu, M., B. Nuseibeh, and L. Rapanotti, "Towards context-aware product-family architectures", in First International Workshop on Software Product Management, 2006, Minneapolis, Minosota, US. Shanahan, M., "The event calculus explained." Springer Lecture Notes in Artificial ntelligence, 1999, 1600, p. 409–430. Sochos, P., "Feature models to the architecture", in Proceedings of the First International Software Product Lines Young Researchers Workshop(SPLYR). 2004. van der Hoek, A., "Configurable software architecture in support of configuration management and software deployment", in INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 1999. Van Lamsweerde, A., "Goal-oriented requirements engineering: A guided tour", in Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium, 2002. Zhang, J. and B.H.C. Cheng, "Using temporal logic to specify adaptive program semantics", Architecting Dependable Systems-Journal of Systems and Software (JSS), 2006, 79(10), p. 1361-1369.
Layered design approach for context-aware systems Brecht Desmet, Jorge Vallejos, and Pascal Costanza Programming Technology Laboratory Vrije Universiteit Brussel B-1050 Brussels, Belgium {bdesmet, jvallejo, pascal.costanza}@vub.ac.be Abstract The omnipresent integration of computer technology in everyday applications introduces new opportunities to make software systems aware of the context in which they are used. Such context-aware systems can respond more adequately to user expectations. However, modelling the context influence inside of software systems burdens developers for several reasons. First, context-dependent behaviour might crosscut the application logic of a software system. Next, since software systems can simultaneously reside in multiple contexts, context-dependent behaviour should be composable. Furthermore, since context information is volatile, these compositions are subject to change at runtime. This paper explores how layered design approaches can be used to deal with these specific characteristics.
1. Introduction The Ambient Intelligence vision describes scenarios in which people are pervasively surrounded by interconnected embedded and mobile devices. A pertinent issue in such a setting is the continuous changes of context in which such devices have to operate. Context-aware computing is already established as a field in which the sensing of, and reasoning about, context information is explored [15, 11, 3]. However, little attention has been paid to approaches for structuring the actual behaviour variations in context-aware systems. On the one hand, such behaviour variations are cross-cutting because in the general case, they affect different parts of the overall system. From this perspective, they give rise to a layered architecture, as conceptualized for example in feature-oriented programming, in which each behaviour variation is captured by a separate software layer. On the other hand, such context-aware layers require support for dynamic activation and deactivation due to the volatile nature of context. The contribution of this paper is an analysis of the vari-
Robert Hirschfeld Hasso-Plattner-Institut Universit¨at Potsdam D-14482 Potsdam, Germany
[email protected]
ous issues in employing a layered architecture for contextaware systems. Specifically, we discuss: • the emergent interactions between layers that need to coexist because a system can reside in different contexts at the same time; • a possible formalization of such interactions; • how these interactions affect dynamic composability of layers; • and how the consistency of the system behaviour can be ensured in the presence of sudden context changes. We base our discussion on an extensive example and provide a proof-of-concept implementation by combining features of ContextL, a programming language extension for Context-oriented Programming based on the notion of layers, with a logic engine using production rules for reasoning about layer interactions.
2. Example scenario We present the software of a simplified cell phone as an illustration of a context-aware system. The application core logic of the cell phone is to ring whenever somebody calls or sends a message, and to provide the means to answer calls and read messages. Furthermore, the phone contains a list of contacts, some of them marked as VIPs.
2.1. Context-dependent adaptations The behaviour of the application core logic can be adapted at runtime according to context changes. We introduce three context-dependent adaptations, each of which contains two parts: a context condition that explains when the adaptation is applicable and the actual contextdependent behaviour of the adaptation.
157
IgnoreAdaptation Battery = Low → I If the battery level is low, ignore all phone calls except for contacts classified as VIP. AnswermachineAdaptation 11pm < time < 8am → A If the time is between 11pm and 8am, activate the answering machine for incoming phone calls and the auto-reply service for messages. RedirectAdaptation Location = M eetingroom → R If the user is in a meeting, redirect all calls and messages to the secretary. VibrationAdaptation N oise = High → V If the ambient noise is high, activate vibration. CostAdaptation Switch = On → C If the user requests so, a cost estimation for incoming phone calls is maintained. This adaptation consists of two alternatives. • Location = Abroad → CI If the user is abroad, InternationalTariffAdaptation (CI) is applicable. • Location = ¬Abroad → CN Otherwise, NationalTariffAdaptation (CN ) is applicable.
2.2. User policy Although all context conditions (battery low, time between 11pm-8am, meeting room location, noise level, and user request) can be true at the same time, the behaviour of the adaptations cannot be freely combined. This is because adaptations might interact with each other. A user policy describes what the interactions are and how they can be resolved. For instance, the following informal rules constitute a possible user policy for the cellular phone scenario. PolicyRule I InternationalTariffAdaptation and NationalTariffAdaptation are mutually exclusive. Furthermore, both adaptations depend on CostAdaptation since they share some common behaviour. PolicyRule II IgnoreAdaptation and RedirectAdaptation cannot coexist. RedirectAdaptation has priority. PolicyRule III AnswermachineAdaptation and RedirectAdaptation cannot coexist. IgnoreAdaptation is only applied if RedirectAdaptation failed (e.g. the secretary did not answer the incoming phone call). PolicyRule IV VibrationAdaptation can coexist with all other adaptations without interference.
3. Problem statement We focus on three fundamental characteristics of context-aware systems: In the general case, contextdependent behavior variations are cross-cutting, multiple behavior variations need to coexist, and they have to react to possibly unexpected context changes. Therefore, they require modularisation, dynamic composability, and means to ensure consistency.
3.1. Modularisation Context-dependent behaviour can cut across multiple units of modularisation. For example, AnswermachineAdaptation refines the behaviour of both phone and message traffic. Without a suitable modularisation mechanism, the code of context-dependent behaviour can easily get scattered and tangled with the code of the application core logic. Such a lack in separation of concerns results in software systems that are difficult to maintain and evolve.
3.2. Dynamic composability Since a context-aware system can simultaneously reside in multiple contexts, one needs to compose contextdependent behaviour dynamically. An important issue in the composition is caused by interactions that can occur between context-dependent behaviour. In our example, we identify the following relationship types between contextdependent behaviour: inclusion, exclusion, conditional dependency, ordering, and independence. • Inclusion - If the user has activated the cost estimation service and the user receives an incoming phone call while residing abroad, InternationalTariffAdaptation is applicable. However, according to PolicyRule I of Section 2.2, this adaptation cannot exist individually since it depends on CostAdaptation. In this case, CostAdaptation is included in the composition whenever InternationalTariffAdaptation (or NationalTariffAdaptation) is applicable. includes
Ci, Cn −→ C
(1)
Furthermore, PolicyRule I describes a mutual exclusion between Ci and Cn. This is ensured by the fact that the context conditions of Ci and Cn are disjoint and complementary (the user is either abroad or not). However, it could be interesting to make such relationships explicit in order to increase program comprehension. • Exclusion - If the battery level is low and the user is in a meeting, both IgnoreAdaptation and RedirectAdaptation are applicable. These adaptations cause a semantic interaction since they ignore and redirect incoming phone calls
158
respectively. PolicyRule II prescribes that phone call redirection has a higher priority, and hence the IgnoreAdaptation is omitted. This means that RedirectAdaptation excludes IgnoreAdaptation. R
excludes
−→
I
(2)
• Conditional dependency - Another possible interaction arises when the user is still in the meeting room at midnight. In such a case, AnswermachineAdaptation and RedirectAdaptation are applicable. PolicyRule III specifies that first phone calls are redirected to the secretary (RedirectAdaptation). If this fails (e.g. secretary absent), the answering machine is activated (AnswermachineAdaptation). In summary, the execution of AnswermachineAdaptation depends on the outcome of RedirectAdaptation. A
depends on
−→
R
(3)
• Ordering - The execution order of context-dependent behaviours, that constitute a particular composition, might influence the semantics of a context-aware system. The inclusion example (1) has an ordering constraint. Consider, for instance, that context-dependent behaviour is composed using inheritance1 . In such a case, C should appear before Ci (or Cn) in the inheritance tree. bef ore
C −→ Ci, Cn
(4)
Furthermore, the conditional dependency example (3) also implicitly indicates an ordering constraint: First the RedirectAdaptation is tried, afterwards the AnswermachineAdaptation is activated. bef ore
R −→ A
has triggered is still being executed. The injudicious abortion or continuation of context-dependent behaviour could lead the system into an anomalous program state. We distinguish different activation and deactivation strategies that should be applied depending on the desired semantics of the context-dependent behaviour. • Loyalty - Suppose there is an incoming phone call at 7:59am which means that the answering machine is activated according to AnswermachineAdaptation. The system should be loyal to that decision, even if the time elapsed beyond 8am. However, all subsequent incoming phone calls are not submitted to AnswermachineAdaptation until 11pm. • Promptness - Whenever the ambient noise level exceeds a certain threshold, the VibrationAdaptation should be applied immediately and vice versa. This action can be applied at arbitrary moments in time without any further conditions.
(5)
• Independence - In contrast, our cell phone example also covers a case in which the order of execution does not affect the system semantics. If the ambient noise is high, the VibrationAdaptation is included in the composition. This adaptation does not interact with any other adaptation in the system according to PolicyRule IV. Hence, there are no relationship types involved.
3.3. Consistency We call context information volatile since it is subject to change at arbitrary moments in time. A context-aware system should adapt its behaviour according to these context changes. In this way, the possibility exists that some context condition becomes invalid while the behaviour it 1 In Section 4.1 we actually compose context-dependent behaviour using inheritance.
4. Layered design approach This section provides an answer to the problems of modularization, dynamic composability, and consistency that hamper the development of context-aware systems. The solution for all problems is illustrated by means of a proof-ofconcept implementation.
4.1. Modularisation Layers in Context-oriented Programming are a good match to modularize context-dependent behaviour. In the following, we base our implementation of the cell phone scenario on ContextL, one of the first programming language extensions that explicitly support a context-oriented programming style [9]. It is an extension to the Common Lisp Object System (CLOS, [1]), which in turn is based on the notion of generic functions instead of the more widespread class-based object model. However, the context-oriented features of ContextL are conceptually independent of the CLOS object model, and a mapping of ContextL features to a hypothetical Java-style language extension called ContextJ has been described in [10]. Layers are the essential extension provided by ContextL on which all subsequent features of ContextL are based. Layers can be defined with the deflayer construct, for example like this. (deflayer cellphone-layer)
Layers have a name, and partial class and method definitions can be added to them. There exists a predefined root or default layer that all definitions are automatically placed in when they do not explicitly name a different layer. For
159
example, consider the following interface in ContextL for making phone calls. (define-layered-function accept-call (nr)) (define-layered-function receive-message (nr txt))
This defines two generic functions, one taking a phone number as a parameter and the other taking an additional text parameter. A default implementation to make phone calls for these as yet abstract functions can be placed in the root layer. (define-layered-method accept-call (nr) ... phone calls inactive on this device ...) (define-layered-method receive-message (nr txt) ... messages inactive on this device ...)
Only if the phonecall-layer is active, a user can actually answer phone calls and receive messages. (define-layered-method accept-call :in-layer cellphone-layer (number) ... actual implementation ...) (define-layered-method receive-message :in-layer cellphone-layer () ... actual implementation ...)
Layers can be activated in the dynamic scope of a program. This layer activation is illustrated in Figure 1. Rectangular boxes represent layered functions and oval boxes represent layered methods. The latter oval boxes are contained within a larger rectangular box which denotes a layer. (with-active-layers (cellphone-layer) ... contained code ...)
or not. In other words, dynamically scoped layer activation obeys a stack-like discipline. Likewise, layers can be deactivated with a similar with-inactive-layers construct that ensures that a layer is not active during the execution of some contained code, and that has no effect when that layer is already inactive. Again, on return from a dynamically scoped layer deactivation, a layers activity state depends on whether it was active before or not. Furthermore in multithreaded Common Lisp implementations, dynamically scoped layer activation and deactivation only activates and deactivates layers for the currently running thread. If a layer is active or inactive in some other thread, it will remain so unless it is incidentally also activated or deactivated in that thread. Multiple layers can contribute to the same layered functions. For example, the context-dependent behaviour of the IgnoreAdaptation (see Section 2.1) refines the behaviour of accept-call. (deflayer ignore-layer) (define-layered-method accept-call :in-layer ignore-layer (nr) (if (vip-p nr) ; nr is VIP? (call-next-method) ; super call ... ignore call ...)
This layered method checks whether nr is classified as a VIP contact. If so, a super call is invoked. Otherwise, the phone call is ignored. The activation of both cellphone-layer and ignore-layer constitute the inheritance hierarchy displayed in Figure 2. (with-active-layers (cellphone-layer ignore-layer) ... handle phone call in context of low battery level ... )
accept-call
receivemessage
cellphone-layer accept-call
receivemessage
In this particular layer composition, the super call in accept-call of ignore-layer invokes the accept-call of the cellphone-layer. In other words, if the caller is a
VIP contact, we delegate the incoming phone call to the cellphone-layer.
Figure 1. Layer activation. Dynamically scoped layer activation has the effect that the layer is only active during execution of the contained code, including all the code that the contained code calls directly or indirectly. Layer activation can be nested, which means that a layer can be activated when it is already active. However, this effectively means that a layer is always active only once at a particular point in time, so nested layer activations are just ignored. This also means that on return from a dynamically scoped layer activation, a layer’s activity state depends on whether it was already active before
Throughout this paper, we consider the existence of answermachine-layer, redirect-layer, discreet-layer, cost-layer, int-tariff-layer, and nat-tariff-layer that respectively implement the contextdependent behaviour of the AnswermachineAdaptation, RedirectAdaptation, VibrationAdaptation, CostAdaptation, InternationalTariffAdaptation, and NationalTariffAdaptation.
4.2. Dynamic composability Dynamic composability addresses the problem of interactions that arise in compositions of context-dependent
160
accept-call
receivemessage
accept-call
receivemessage
cellphone-layer
ignore-layer accept-call
Figure 2. Composing layers in inheritance hierarchy.
adaptations. Our solution consists of making all these interactions explicit and available for automatic reasoning. To this end, we employ a forward-reasoning engine. The production rules of such an engine capture the context conditions of adaptations and the relationships between contextdependent adaptations. • Context conditions are predicates that describe when some context-dependent behaviour is applicable. For example, Section 2.1 presents the context conditions of the cell phone scenario in both logical and textual format. We now implement these context conditions using production rules of the LISA forward chainer [18]. These production rules complement the ContextL layers which contain the contextdependent behaviour of the cell phone scenario. Since the implementation of all context conditions is quite similar, we only show the implementation of the IgnoreAdaptation (I) context condition as an illustration. We assume the existence of a mechanism that computes high-level context information (like e.g. (battery (level low))) out of low-level sensor data. One could use existing tools like ContextToolkit [15], WildCAT [11], or Java Context Awareness Framework [3] to perform this job. (defrule ignore-adaptation (battery (level low)) => (assert (layer (name ignore-layer))))
The body of a LISA production rule consists of a condition and an action part which are situated before and after the => symbol respectively. Logic variables are symbols with a leading question mark. For a more detailed explanation of LISA production rules, we refer to the documentation [18]. • Composition rules describe valid compositions of layers based on user-defined policy rules. For example, the cell phone scenario of Section 2.2 has five policy rules that informally describe what should happen in case of interacting
behaviour. The formalization of these policy rules in Section 3.2 extracts five relationship types that exist among the context-dependent adaptations of the cell phone example. As a proof of concept, we implement these relationship types (Formulas 1-5) using production rules of the LISA forward chainer. The inclusion relationship is implemented as follows: If either nat-tariff-layer or int-tariff-layer is applicable (and hence defined in the fact base of LISA), cost-layer should be added to the fact base. (defrule inclusion () (or (layer (name nat-tariff-layer)) (layer (name int-tariff-layer))) (not (layer (name cost-layer))) => (assert (layer (name cost-layer))))
The exclusion relationship checks whether both and ignore-layer are defined in the fact base. If so, the latter is retracted from the fact base.
answermachine-layer
(defrule exclusion () (layer (name answermachine-layer)) (?x (layer (name ignore-layer))) => (retract ?x))
The ordering relationship is realized by associating a slot with layer facts. An ordering can be established by filling in this before slot. The following LISA production rule implements Formula 4.
before
(defrule ordering () (layer (name cost-layer)) (?x (layer (name nat-tariff-layer) (not (before cost-layer)))) => (modify ?x (before cost-layer)))
The conditional dependency relationship is a special case of the ordering relationship. The redirect-layer is placed after the answermachine-layer in the inheritance hierarchy (see Figure 3). (defrule conditional-dependency () (layer (name redirect-layer)) (?x (layer (name answermachine-layer) (not (before redirect-layer)))) => (modify ?x (before redirect-layer)))
The inheritance path indicates the chain of dependency. First, the layered method accept-call of redirect-layer is executed. If the redirection fails, a super call to answermachine-layer is invoked. Furthermore, the layered method receive-message of answermachine-layer is always invoked since redirect-layer does not refine this method.
161
accept-call
receivemessage
answermachine-layer accept-call
receivemessage
redirect-layer accept-call
Figure 3. Conditional dependency. The independence relationship does not interfere with other layers, thus no production rules are required. All production rules of this section allow the LISA forward chainer to reason about the user policy and to compute valid layer compositions according to context information. Since this context information is volatile, the computation of layer compositions must happen at runtime to reflect the actual context situation. We therefore require the ability to deploy layer compositions at runtime. The with-active-layers and with-inactive-layers cannot be employed for these purposes since these constructs require manual specification of layer compositions at design time. Dynamic deployment of layer compositions can be realized with the reflective infrastructure of ContextL [8] which allows introspection and intercession of layer activations and deactivations at runtime. The with-current-context construct is an extension to ContextL which is built entirely on top of the reflective architecture. It automatically computes layer compositions based on a user policy (implemented by means of LISA production rules) and actual context information. The with-current-context construct has, apart from computing the layer composition automatically, the same functionality as the existing with-active-layers construct: Layers are activated in a stack-like way within the dynamic scope of with-current-context, and confined to the running thread. (with-current-context (... parameters ...) ... contained code ...)
The parameter list of with-current-context delimits the set of LISA production rules that are evaluated for computing the layer composition. We omit the details of this interface to improve the clarity of the example.
4.3. Consistency Section 3.3 identifies two different strategies that describe when context-dependent adaptations can be safely
activated and deactivated. We show how these strategies can be realized in ContextL. • Loyalty is supported by the with-current-context construct.2 The layer composition is determined before the execution of the contained code and does not change within the dynamic scope of with-current-context3 , even if the layer composition does not reflect the actual context situation anymore. Furthermore, the layer activations (and deactivations) are confined to the running thread only. • Promptness is currently not supported in ContextL. Enforcing the deactivation of context-dependent behaviour means that one jumps out of the dynamic scope of with-current-context and interrupts the execution of the contained code. This might possibly require the execution of some compensating actions (e.g. proper disconnection from a database) to avoid anomalous program behaviour. To this end, we are looking in the direction of transaction management to deal with the promptness strategy in ContextL. The opposite situation, in which the immediate activation of context-dependent behaviour is enforced on a context change, is also not straightforwardly available in ContextL. One possible way to deal with such a requirement is to incorporate continuations. However, this idea is subject to further investigation.
5. Related work 5.1. Collaborations Our layered design approach is established by composing layers in ContextL which is essentially a realization of a collaboration-based design [6]. During the last decade, diverse implementation models have been proposed that modularize collaborations, like mixin layers, CaesarJ, Classboxes, LasagneJ, and ObjectTeams. Each of these implementations has varying technical characteristics to support specific problem domains. In the following, we briefly discuss these implementations and compare them with ContextL. Mixin layers [16] are a means to achieve a layered design while overcoming the scalability issues of role-based designs indicated by Vanhilst and Notkin [17]. A concrete implementation technique for mixin layers is suggested using templates in C++. The deployment of mixin layers has a global impact on a software system. In contrast, ContextL employs dynamic scoping to delimit the deployment scope of layers. The latter is essential to context-aware system 2 This loyalty strategy is inherited from the with-active-layers construct. 3 Unless the programmer explicitly makes use of the with-inactive-layers construct to deactivate layers within a particular dynamic subscope.
162
since context-dependent adaptations typically affect only delimited scopes of a running software system. A classbox [7] is a module system which allows for class extensions. Classboxes are not properly suited for our purposes since they are statically bound. Furthermore, the activation of classboxes cannot be explicitly scoped to certain parts of the program control flow. Instead, classboxes support the notion of so-called local rebinding which is actually a kind of implicit dynamic scoping on the level of modules. CaesarJ [2] is a programming language which supports both aspect-oriented and component-oriented programming through the integration of aspects, virtual classes, and mixin composition. As is the case with mixin layers, virtual classes have a global impact on a software system. Aspects can be activated within a dynamic scope and hence approximates dynamically scoped layer activations. However, since aspects cannot be thread-locally deactivated in CaesarJ, the use of the cflow construct is required for certain idioms [10]. LasagneJ [14] is a language extension of Java which provides dedicated language constructs for the wrapper design pattern to support the dynamic evolution of collaborating objects. Their notion of constructive downcasting allows to propagate the activation of collaborating wrappers along consecutive object invocations. This can be regarded as an implicit form of dynamic scoping. In contrast, ContextL provides explicit language constructs to delimit dynamic scopes and allows for deactivation within subscopes. An ObjectTeam [12] is a collaboration unit integrated in Java which modularizes cross-cutting concerns in an independent and reusable fashion. Furthermore, this approach facilitates the a posteriori integration of collaborations into existing systems. To this end, ObjectTeams hook in the basic behaviour through a mechanism called lowering and lifting, whereas ContextL extends the basic behaviour with layers through linear inheritance. Interestingly, ObjectTeams can be activated and deactivated within a dynamic scope either globally or thread-locally [13].
5.2. Feature oriented programming Feature Oriented Programming (FOP) introduced by Batory et al. is a design methodology for software product lines [5]. The variation points in FOP are units of functionality (i.e. features) that distinguish product variations within a family of related programs. Alternatively, the variation points of context-aware systems are places where the program behaviour can be adapted according to runtime context information. The modelling of context-dependent adaptations and the relationships between them goes beyond traditional feature models found in FOP because of the following reasons. First, the idea central to feature modelling in FOP is to describe all feature compositions that yield valid product
variations. This allows product line engineers to verify and debug their feature composition descriptions [4]. In contrast, context-aware systems require the automatic selection and composition of context-dependent behaviour at runtime based on actual context parameters. Second, context-aware systems require a more advanced set of relationships, like e.g. conditional dependency which employs runtime information to determine its outcome. Finally, since context information is volatile, the composition of context-dependent behaviour is continuously subject to change. On the contrary, feature compositions in FOP are not subject to change at runtime and are therefore typically bound at compile time using program synthesis techniques.
6. Position statement We advocate to implement context-aware systems using a layered design approach. The basic idea is to separate context-dependent adaptations from the basic behaviour and organize them in layers. Depending on the context in which the system resides, these layers can refine the basic behaviour. This paper proposes to use the Context-oriented Programming style of ContextL to implement the contextdependent behaviour using layers. Next, since software systems can simultanelously reside in multiple contexts, multiple layers can be applicable which might cause interactions. We therefore explicitly describe relationships between layers. Moreover, since context information is volatile, we write these relationships in a declarative style which allows a reasoning mechanism to automatically compute valid layer compositions at runtime. Finally, we identify two strategies that prescribe when context-dependent behaviour can be safely activated or deactivated. The loyalty strategy aims at consistent program behaviour by ignoring context changes within a particular scope of a software system. This strategy is explicitly available in ContextL since layer deployment is delimited to a particular dynamic scope and confined to the running thread. However, the promptness strategy, which requires immediate recomputation and deployment of layer compositions upon context changes, is not straightforwardly supported by ContextL.
7. Future work The cell phone scenario focuses solely on five kinds of relationships between context-dependent behaviour. However, a more exhaustive study of context-aware scenarios could give rise to more interesting relationships. The same remark holds for the activation and deactivation strategies for context-dependent behaviour.
163
Currently, both the context conditions and relationships between context-dependent behaviour are implemented with production rules as a proof of concept. For future perspectives, we are considering descriptive logics, backward chainers like Prolog, and other more domain-specific reasoning mechanisms. The specification of relationships between contextdependent behaviour is very hard to accomplish in practice. The translation process of the user policy into declarative rules suffers from accidental underspecification, ambiguities, and contradictions. Furthermore, as the number of possible context parameters increases, one has to deal with a combinatorial explosion of possible behavioural variations. This scalability issue severely hinders the evolvability and maintainability of a context-aware system. A real solution to the problem does not exist since the combinatorial explosion is inherently present. However, we can alleviate the scalability issue by incorporating tool support for specifying relationships. The functionality of this tool support should consist of controlling the correctness of all specifications and validating the specifications against all possible context situations.
References [1] American National Standards Institute and Information Technology Industry Council. ANSI Common Lisp Language Specification: ANSI X3.226-1994 (R1999), 1999. [2] I. Aracic, V. Gasiunas, M. Mezini, and K. Ostermann. An overview of caesarj. In Transactions on Aspect-Oriented Software Development I, volume 3880 of Lecture Notes in Computer Science, pages 135–173. Springer Berlin / Heidelberg, February 2006. [3] J. E. Bardram. The Java Context Awareness Framework (JCAF) - A Service Infrastructure and Programming Framework for Context-Aware Applications. In Pervasive, pages 98–115, 2005. [4] D. Batory. Feature models, grammars, and propositional formulas. In SPLC ’05: Proceedings of 9th International Software Product Line Conference, September 2005. [5] D. Batory, J. N. Sarvela, and A. Rauschmayer. Scaling stepwise refinement. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering, pages 187– 197, Washington, DC, USA, 2003. IEEE Computer Society. [6] K. Beck and W. Cunningham. A laboratory for teaching object oriented thinking. In OOPSLA ’89: Conference proceedings on Object-oriented programming systems, languages and applications, pages 1–6, New York, NY, USA, 1989. ACM Press. [7] A. Bergel, S. Ducasse, O. Nierstrasz, and R. Wuyts. Classboxes: controlling visibility of class extensions. Computer Languages, Systems and Structures, 31(3-4):107–126, November 2004. [8] P. Costanza and R. Hirschfeld. Reflective Layer Activation in ContextL. In Programming for Separation of Concerns (PSC) of the ACM Symposium on Applied Computing (SAC) 2007, New York, NY, USA. ACM Press, To appear. [9] P. Costanza and R. Hirschfeld. Language constructs for context-oriented programming: an overview of ContextL. In DLS ’05: Proceedings of the 2005 conference on Dynamic languages symposium, pages 1–10, New York, NY, USA, 2005. ACM Press. [10] P. Costanza, R. Hirschfeld, and W. D. Meuter. Efficient layer activation for switching context-dependent behavior. In JMLC ’06: Proceedings of the Joint Modular Languages Conference, volume 4228 of Lecture Notes in Computer Science, pages 84–103. Springer Berlin / Heidelberg, 2006. [11] P.-C. David and T. Ledoux. Wildcat: a generic framework for context-aware applications. In MPAC ’05: Proceedings of the 3rd international workshop on Middleware for pervasive and ad-hoc computing, pages 1–7, New York, NY, USA, 2005. ACM Press. [12] S. Herrmann. Object teams: Improving modularity for crosscutting collaborations. In NODe ’02: Revised Papers from the International Conference NetObjectDays on Objects, Components, Architectures, Services, and Applications for a Networked World, pages 248–264, London, UK, 2003. Springer-Verlag. [13] S. Herrmann and C. Hundt. ObjectTeams/Java Language Definition (OTJLD) version 0.9, June 2006.
164
[14] B. N. Jørgensen and E. Truyen. Evolution of collective object behavior in presence of simultaneous client-specific views. In OOIS ’03: Proceedings of the 9th international Conference on Object-Oriented Information, volume 2817 of Lecture Notes in Computer Science, pages 18–32. Springer Berlin / Heidelberg, 2003. [15] D. Salber, A. K. Dey, and G. D. Abowd. The context toolkit: aiding the development of context-enabled applications. In CHI ’99: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 434–441, New York, NY, USA, 1999. ACM Press. [16] Y. Smaragdakis and D. S. Batory. Implementing layered designs with mixin layers. In ECOOP ’98: Proceedings of the 12th European Conference on Object-Oriented Programming, pages 550–570, London, UK, 1998. SpringerVerlag. [17] M. VanHilst and D. Notkin. Using C++ Templates to Implement Role-Based Designs. In ISOTAS ’96: Proceedings of the Second JSSST International Symposium on Object Technologies for Advanced Software, pages 22–37, London, UK, 1996. Springer-Verlag. [18] D. E. Young. Lisp-based Intelligent Software Agents, http://lisa.sourceforge.net. SourceForge, 2006.
165
166
A Plea for Help with Variability, in Two Acts Reed Little Software Engineering Institute 1 Carnegie Mellon University
[email protected]
Randy Blohm Northrop Grumman
[email protected]
Abstract
product within the Framis product line and priced it accordingly.
A short theatrical exaggeration (but not too much) which describes practical problems with variability as experienced by real-world software developers. Real issue, there are no practicable schemes, mechanisms, methods, or tools available which support software developers and allow reasoning about variability seamlessly, throughout the entire system life-cycle.
DR. SPACELY That is all well and good in theory, but how did Cogswell Cogs come in so much lower? Mr. Cogswell will be insufferable now, and I will have to wallow in his taunts, when we play golf next week at Pebble Beach. GEORGE I just don't understand, sir. We thought that our Framis product line approach would provide us with a differentiated capability to produce a faster, better, cheaper Farkle. I heard through the grapevine that Cogswell Cogs also has a software product line, named FooBar, which is similar in scope to our Framis product line. I anticipated that they would also structure their bid using a product line approach, but I thought that since ours had a longer history, we would have an advantage.
Act 1 (The boardroom of Spacely Sprockets, Inc. The Board of Directors (including Dr. Spacely the chairman) sit imposingly at one end of a long, curved table fashioned from a glass counter and tapered steel legs. George J, manager of the Farkle proposal and Spanky M, George's chief technical adviser, sit, uncomfortably, at the other end of the table. )
DR. SPACELY Well if that were really the case, then how did we get so drastically underbid?
DR. SPACELY I just received word from the government that we lost the Farkle contract. Everybody in this room assured me that we had that work locked in. Our proposal was technically acceptable but Cogswell Cogs underbid us by almost 50%. I don’t need to remind you how crucial the Farkle contract was for our company's continued growth. Our stockholders will be incensed. WHAT HAPPENED? Why was our bid so high?
GEORGE Spanky, you were heavily involved with the design of the Farkle system; do you have any explanation for this? SPANKY Well, I was at the Golden Goose recently with some folks from Cogswell. After a few rounds of drinks they started to discuss and divulge some details of their work. The Cogswell folks, in a roundabout way, let on that the FooBar product line does in fact exist and that they would have to develop very little new code to implement a Farkle system when they won the contract. If I understood them correctly, it sounded like, with the tweak of some knobs and levers, they
GEORGE Well sir, when we first read the Farkle request for proposals, we determined that a Farkle system was without question within the scope of our current Framis software product line. Because the Framis product line core assets and processes are very mature and well tested, we designed the Farkle system to be a
1 The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense.
167
could quickly produce a Farkle while only having to add a very small amount of Farkle specific code.
the contract to Cogswell Cogs is this—while we had preplanned for variability in our product line architecture, the majority of our sprockets, which we had planned to assemble into a Farkle, contained variation points which were realized by ad hoc variation mechanisms whose binding times were simply not flexible enough for us to be able to assemble our sprockets into a Farkle without changing a lot of source code; additionally, the variability…
GEORGE That could explain how they underbid us, sir. While the Farkle product is definitely within the scope of our product line, we estimated we would have to develop 33% of the product as new code. DR. SPACELY I don't understand. If a Farkle product is so clearly in scope why would so much new code have to be developed? Why couldn’t we leverage our core asset base in the same manner? Isn't the whole idea of a software product line to reduce the amount of new code needed for any one product, which should reduce the cost? GEORGE That’s exactly right, Dr. Spacely. I just don't understand, but those were the numbers provided by the software cost estimators.
DR SPACELY (Exasperated, with arms folded) Varia-what? George, I’m afraid you’ll need to speak a little more plainly if we are to have any hope here of understanding you. GEORGE That’s precisely the problem, Dr. Spacely. As we analyzed the usage of variability in our product line, we realized that we lacked a consistent set of terms for reasoning about the problem. We have since codified these terms on a set of stone tablets that all new employees are required to read immediately upon joining our team.
DR. SPACELY George, I’ve heard enough. If you want to retain your job here, then track all this down and develop a get well plan. I never want to loose a contract this way again. Report back to me 14 days from today with what caused this sad state of affairs and your plans to fix the situation.
DR SPACELY (Brimming over with sarcasm)
GEORGE Yes sir, two weeks it is.
Well, I’m glad to hear that you and your team can now successfully converse with one another George, but I must confess we were expecting to hear that you had made a little more progress than that.
Act 2
GEORGE Indeed we have, Dr. Spacely; now if I may continue, I was saying that the real reason we lost the contract is that our core sprockets were unable to be successfully assembled and tailored to form a Farkle. We had plenty of systems engineers at the time who were working on requirements for the sprockets, but because of schedule pressure, too little attention was paid to addressing variability requirements up front. Developers who came along afterwards did their best to introduce variation points into the sprockets, but without support from systems engineering in the form of requirements to guide them, developers often fell back to using a single variation mechanism which everyone was familiar with, configuration files. It was only afterwards that we realized that this would not be sufficient to meet the needs of product builders in all cases.
(Dr. Spaceley’s office. Dr. Spacely and his immediate staff are assembled around a long, elliptical space age table that narrows in width on one end. George and his team enter the room and assemble around the narrow end of the table, while trying to remain as far away as possible from Dr. Spacely who is seated at the opposite end. DR SPACELY George, come in. Me and my team are very anxious to hear your report…and how you intend to keep your job by coming up with a solution to this problem you’ve created! GEORGE Well, Dr. Spacely, after extensive research my team and I have concluded that the real reason that we lost
168
GEORGE Our first guestimate is 5 people for 6 calendar months to get an initial set of tools and processes ready for consumption by the masses.
DR SPACELY George, we are all too aware now of the problem. What we want is a solution. What do you propose to do to fix this?
DR SPACELY And when do you plan to start this valiant mission, if I approve?
GEORGE Well, we’ve ascertained that the root cause of our problem lies with our lack of an ability to seamlessly reason about variations from the requirements phase all the way to the deprecation of assets. We plan to investigate available tools and methods which support variation on the various stages of software development and ascertain the feasibility of tying the tools and methods together. We need to find a practical scheme to deal with and reason about variability across the entire software life-cycle.
GEORGE There is an excellent variability workshop in Limerick, Ireland next January. I plan to take Spanky with me to engage the best minds in variability on this problem. DR SPACELY OK, George, go forth and variate.
These tools and methods will need to support large (~ 5 million lines of code) software systems. Additionally, we need tools that can support the syntactic complexity of a modern object oriented language like C++. Certain language features in particular, such as templates, have hindered our ability to reverse engineer variability using static source code analyzer type tools.
Prologue (The plenary session of the First International Workshop on Variability Modelling of Software-intensive Systems, Limerick, Ireland 16 January, 2007. George and Spanky are in the audience)
DR SPACELY
GEORGE HELP !!!!
(Shielding his checkbook) George that is a big issue you plan to attack; how long will it take, and more importantly how much will it cost me?
169
170
— Problem Statement — Variability Models Must Not be Invariant! Elmar Juergens and Markus Pizka Technische Universit¨at M¨unchen Institut f¨ur Informatik {juergens, pizka}@in.tum.de Abstract Variability modeling techniques are used to specify variable aspects of members of a family of related software artifacts. Instances of variability models are then used to efficiently produce members of such a family. By making variability explicit, variability models determine implicitly the common properties among family members as well. This partitioning of information into variable and invariant parts predetermines the reuse benefit obtainable from a variability model. In most current approaches to variability modeling, the decision between variable and invariant information has to be done in an up-front manner and is very difficult to change later on. However, the distinction between variable and common parts of members of a system family varies over time. Variability modeling techniques must thus be able to cope with changes to the variability models. Since many variability modeling techniques do not currently support this, research is required to allow an evolution of the distinction between what is variable and what is invariant over time. This paper elaborates on the necessity, related work and possible approaches to tackle this challenge. Keywords modeling, software evolution, formal methods, software reuse
1
and software product lines. As accurately noted by Krueger in his influential paper on software reuse [9], abstractions are the basis of all reuse mechanisms. In [17], Wegner illustrates the close relationship between abstractions and reuse by pointing out that every abstraction describes a collection of related, reusable entities, and that vice versa, every collection of related, reusable entities determines an abstraction. Hence, in order to better understand the potential of approaches to software reuse — both old and new ones — it is important to understand the principles of abstraction. In order to better understand the benefit of variability modeling approaches (such as model driven software development and software product lines), we investigate in this paper various abstraction mechanisms from the perspective of software reuse. This investigation reveals that the partitioning of information into variable and invariant parts of an abstraction is the crucial factor determining the overall benefit of an abstraction for software reuse. This paper further shows that it is impossible to achieve an optimal partitioning in practice, if it cannot be altered during the lifetime of an abstraction, since the creation of an optimal partitioning would requires complete and in-advance knowledge of future requirements. From this, we conclude that in order to exploit the optimal reuse benefit of an abstraction, it is of utmost importance to be able to evolve the partitioning into variable and invariable properties itself over the lifetime of the abstraction.
Introduction
Since the term Software Engineering was coined in 1968 [14], software reuse is considered a potential means to alleviate the difficulties encountered in the construction of large software systems. It promises to decrease costs and increase quality by reusing existing components for the construction of new systems. This hope also drives several approaches that receive increased attention in recent years, such as generative programming, model driven software development
Outline The remainder of this paper is structured as follows: Section 2 investigates the role of variability in different abstraction mechanisms from the perspective of reuse. Section 3 illustrates the impact that the amount of invariant information has on the reuse benefit an abstraction provides. Section 4 gives additional evidence for the claim that increased variability is needed by referencing numerous iso-
171
lated approaches to tackle this problem for different abstraction mechanisms. Section 5 concludes the paper with the appeal to join research efforts in order to move from isolated ad-hoc approaches to a general, unified understanding of variability evolution in abstraction mechanisms.
2
6SHFL¿FDWLRQ
^`
Abstractions, Reuse and Variability
According to Krueger [9], every abstraction mechanism employed in software development comprises two levels: the higher referred to as specification and the lower as realization of an abstraction. Specifications define the variability among the realizations of an abstraction. Different instantiations of the variability defined within an abstraction specification map to different realizations of the abstraction. This perception of abstractions is depicted graphically in Figure 1. The variability exposed by the abstraction specification is depicted by red, blue and green triangles. Depending on the variable information, the abstraction specification maps to different abstraction realizations. This mapping is performed by abstraction mechanism-specific translation mechanisms. (In the case of programming languages for example, it is performed by the compiler, for domain specific languages by the generator and for libraries by the developer that implements the library’s interfaces and methods.) The colored half-circles depict those parts of the abstraction realizations that are generated from the variable information. The commonality among the realizations is depicted by gray squares. By making variability explicit, a specification also implicitly defines the invariant parts of an abstraction. Since they are common among all realizations of an abstraction, they hold the potential for reuse: the bigger the invariant parts are, the more information can be reused between abstraction realizations.1 This consideration of abstractions as specification and realization is still as applicable to the conception of abstraction mechanisms today, as it was in 1992. Let us consider various commonly used reuse mechanism from this perspective.2 Assembly Language: Every statement in assembly language abstracts from a micro program in machine code. Assembly language statements are abstraction specifications, the micro programs they are translated to are the corresponding abstraction realizations. The variability consists of the parameters offered by the 1 Krueger further divides the invariant information into a visible and a hidden part. The hidden part comprises those common aspects among abstraction realizations, which are not “visible” in the abstraction specification. For the sake of simplicity, we omit the distinction between visible and hidden aspects of invariant information in abstractions in this paper. 2 Several of these observations can already be found in [9]
5HDOL]DWLRQ
Figure 1. Abstraction Principles statements. Every aspect of a statement that cannot be parameterized is common among all corresponding machine code programs. The statement MULT , for example performs the multiplication of 32 bit numbers. The registers from which the numbers are read, are variable. However, the actual algorithm used for multiplication, or the register in which the result is stored, is invariant and thus common among all micro programs generated from MULT statements. High Level Programming Languages (i.e. C/C++, Java): Every construct in a high level programming language specifies an abstraction that is realized by an assembly language program. Again, the variability is defined by the parameters provided on the specification level. The statement while() {} for example loops over the statements in , as long as evaluates to true. Parameters and are variable, the fact that a loop is performed, and the assembly language statements generated for it are invariant, however. Libraries: High level programming languages provide abstraction mechanisms (i.e. methods, classes) that are employed to create abstractions that can be reused in programs in that language. Libraries are collections of such abstractions. The public interface provided by a class in a library corresponds to the specification, its implementation to the realization of an abstraction. MsgBox("Low Battery", vbWarning)3 for example opens a dialog that displays a warning message. The parameters of the method make the warning 3 In
172
Microsoft Visual Basic 6.0
and the message type variable. All other aspects — such as color, widgets, displayed icons, size or layout of the dialog — are invariant. Domain Specific Languages (DSLs): DSLs allow the concise expression of problems from a specific technical or business domain by offering abstractions from that domain as first-class language elements. These language elements are abstraction specifications that are often translated to programs in high level programming languages. An example for this are regular expressions, from which Lex4 generates finite state machines that perform tokenization in compiler front ends. In this case, the regular expressions define the variability: Lex can generate finite state machines for all regular languages. However, the finite state machine implementation, the target language and the input text encoding are invariant and thus common among all generated lexers. Software Product Lines: In software product lines, members of a family of software systems are created by composition of standardized components. In feature modeling tools such as fmp5 , configurations serve as composition descriptions. In such a setting, feature diagrams serve as abstraction specifications. The systems that are composed from their configurations correspond to the abstraction realizations. In software product lines it is especially obvious that any aspect that is not explicitly made variable in the feature diagram is invariant and thus necessarily common among all realizations. The above mentioned abstraction mechanisms are often layered on top of each other in practice: Micro programs are generated from assembly language, assembly language is compiled from programs in high level languages, and so on. Every layer increases the level of abstraction of the highest abstraction specification. For software developers working on the highest level of abstraction in this stack has two major consequences:
for all high level language programs that are translated by a compiler. Decrease in applicability: The developer loses some control over the final result. E. g. since the compiler takes care of register allocation, a developer cannot influence it anymore, even if it was needed. In this example, this limits the applicability of higher level programming languages for system level programming. This negative effect necessarily increases with the level of abstraction. The more invariant information an abstraction contains, the more specialized and thus the less widely applicable it becomes. Obviously, a DSL for parser generation cannot be used to program a web server. Making information in an abstraction invariant thus increases productivity and decreases applicability. This gives rise to the crucial question of abstraction creation: What should be variable, and what should be invariant? We are convinced that (in general), this question cannot be answered satisfactorily once for the entire lifetime of an abstraction. Instead, we believe that it must evolve continuously in order to reflect unanticipated changes.
3. Invariance Dilemma The overall reuse benefit that the creation of an abstraction brings to software development, depends on at least two things: how much effort does the application of the abstraction save, and how many times can the abstraction be applied. Unfortunately, both factors depend on the level of abstraction of the abstraction specification, and thus on its amount of invariant information. Hence, increasing the level of abstraction reduces the applicability, and vice versa, increasing the applicability by reducing invariant information reduces the level of abstraction: • Increasing invariant information increases the amount of knowledge that can be reused among abstraction realizations. The more invariant information, the higher thus the saving in developer effort every time the abstraction is used. However, more invariant information requires more commonality among the abstraction realizations and thus reduces the number of opportunities for applying the abstraction.
Increase in productivity: developer productivity increases, since many details are “abstracted away” and taken care of by the translation to lower levels. For example, letting the compiler take care of register allocation saves developer time and effort. Regarded from the perspective of variability and invariance in abstraction specifications, this means moving register allocation from the variable to the invariant part: the algorithm employed for register allocation is invariant 4 The
• Reducing invariant information reduces the distance between specification and realization and thus the size of the reused artifacts. Reducing invariant information thus reduces the amount of saved development effort for each use of an abstraction.
Lex & Yacc Page: http://dinosaur.compilertools.net Modeling Plug-in: http://gp.uwaterloo.ca/fmp
5 Feature
173
However less invariant information relaxes the commonality requirement — an abstraction can be applied more often. The optimal amount of invariance in an abstraction can thus only be determined with respect to the abstraction’s use cases: ideally, all common aspects of the use cases of an abstraction should be made invariant. In other words: if the use cases of an abstraction are not known, it is not possible to determine the optimal partitioning of information into variable and invariant parts of an abstraction. Since in practice the use cases of an abstraction (including future use cases!) are hardly ever known, we call this observation the invariance dilemma. Let us consider the development of a product line as an example to make this dilemma more tangible. The Feature Diagram in a product line defines the variability (and commonality) among products. Every single feature that is added to the diagram decreases the level of abstraction, but increases the size of the product family (and thus the potential number of applications). If abstraction specifications cannot be altered during their lifetime, abstraction creation is thus the quest for the lesser evil: waste of potential productivity increase or waste of potential abstraction applications. This dilemma can be elegantly avoided, if abstractions can be easily evolved during their lifetime. We start by creating an abstraction specification that only considers variability among the already known use cases. All commonality is made invariant. As soon as a new use case comes up that requires to make a certain — formerly invariant — part variable, the abstraction is adapted accordingly. This way, abstractions start at the highest possible level of abstraction. Every decrease of abstraction is however justified by an additional application, avoiding the decrease in overall reuse benefit. If this procedure is followed consequently, this bottomup way of abstraction creation always achieves optimal reuse benefit. However, in order to exploit this in practice, it must be possible to adapt the separation between variable and invariant information during the life time of the abstraction. In other words: variability models must be variable!
4. Variability Evolution Since abstractions play such a central role in software engineering, changes to an abstraction can affect many artifacts in a development process. In general, changes to the specification of an abstraction affect the already existing instances of the abstraction and the tools used for processing them. Figure 2 illustrates this problem, using Domain Specific Languages as exemplary abstraction mechanism. Every
change to the specification of a language requires compensating migrations of the words6 and adaptations of the processing tools7 of the language.
Figure 2. Abstraction evolution triggers migration of existing words and adaptation of processing tools
Performing these migrations manually is tedious, error prone and costly. Abstraction mechanisms that do not automate these compensational efforts effectively inhibit abstraction evolution in practice. Partial solutions to automate the compensational effort triggered by abstraction evolution have been developed for various abstraction mechanisms. The existence of these efforts substantiates our claim for the need of abstraction mechanisms that support variability evolution in practice. These approaches include: Schema Evolution: The schema of a database system 8 determines which entities and relationships — and attributes thereof — can be stored in a database. All aspects not contained in the schema are not considered. The decision of which information to include into a schema, is related to the decision which information to make variable in an abstraction. Schema evolution [2, 3] deals with altering this decision — that is the entities, relations and attributes of a schema — while the schema is in use. Schema evolution research mainly deals with the problem of migrating instance data. Adaptation of tools is only, if at all, considered laterally. However, after decades of mainly academic interest, some transition to industrial projects seems to be taking place [1]. Grammar Engineering: Grammars of different forms9 are used to describe the syntax of formal languages 6 The term “word” is used as in formal language theory to depict strings that conform to the language syntax. 7 I.e. compiler, debugger, pretty printer, ... 8 Independent of whether it is relational, hierarchical or object oriented 9 I.e. context free grammars, XML schemas or document type definitions. Compare [8] for a more comprehensive list.
174
and the structure of software systems. Grammar engineering [8, 10] deals with the systematic development and maintenance of grammars. In [12, 11], L¨ammel also investigates the coupled evolution of grammars and their words. While these approaches constitute considerable progress in the field, a lot of research is still necessary in order to better understand and master the evolution of grammars. Furthermore, grammar engineering mostly concerns the evolution of grammars and migration of words, but largely ignores the adaptation of processing tools. Refactoring: High level programming languages offer facilities such as methods and classes for abstraction creation. Since the invariance dilemma also holds for these abstraction mechanisms, classes and methods too have to evolve over time to adapt to changes to the variability / invariance separation. Refactoring is the restructuring of programs by “altering its internal structure without changing its external behavior”[4]. This limitation of expressiveness allows for a high level of automation. Several state of the art development environments such as Eclipse10 implement a number of refactorings that automate the adaptation of abstraction instances to changes to abstraction specifications. Some refactorings, i.e. rename class/method, introduce/remove parameter [4] can be used to change the parameters offered by classes and methods and thus for evolution of variability in abstraction specifications. The concept of refactoring has been applied to numerous languages [13] and even to meta models [18]. While refactorings are a help for mastering variability evolution, they are certainly not sufficient due to their limited expressiveness. Feature Model Synchronization: In [7], Kim and Czarnecki propose an approach to adapt feature configurations to changes to their feature model that can arise during product line evolution. While they state promising results for feature model synchronization, they do not address the problem of tool adaptation. Language Evolution: In [6] we present the Lever11 , a tool for the evolutionary development of (domain specific) languages. Lever provides evolution operations on the language specification level, that automate the migration of existing words and the adaptation of the compiler / generator for the language. Lever is currently implemented as a research prototype that will be released beginning of 2007. We believe that many of the 10 www.eclipse.org 11 Stands
for “Language Evolver”
concepts that Lever employs for the evolution of languages are also applicable for the evolution of other abstraction mechanisms. TransformGen [5] is an earlier approach to language evolution that was developed in the context of syntax directed editors. It cannot deal with arbitrary syntax and ignores the adaptation of language processing tools, though. To the best of our knowledge, these approaches consider the mechanics of evolution of their abstraction mechanisms in relative isolation. We are not aware of an underlying theory of abstraction or variability evolution. However, we are convinced that this problem is so fundamental to software reuse and variability management that it deserves consideration on a general level.
5. Conclusion The amount of variable and invariant information in an abstraction specification — independent of the actual abstraction mechanism used — determines the reuse benefit that the creation of an abstraction brings to software development. Unfortunately, variability is a two-edged sword: too much variability results in too low a level of abstraction. Too little variability on the other hand reduces the number of times an abstraction can be reused and thus also ruins the reuse benefit of an abstraction. The optimal partition between variable and invariant information can only be determined with respect to all cases in which an abstraction is to be applied. Since this is impossible in practice — because future use cases are unknown — abstractions can only achieve optimal reuse benefit, if they consider the currently known use cases and are adapted when new use cases arise. Since the evolution of an abstraction affects its existing instances and processing tools, evolution of abstractions is only feasible if the compensational effort is automated to a high degree. Approaches to automate this compensational effort have been developed in relative isolation for numerous abstraction mechanisms. These approaches tend to reinvent the wheel, since the underlying problem of abstraction evolution is common among all abstraction mechanisms. We are convinced, that a unified analysis — across different abstraction mechanisms — is required to tackle the problem at its core. We hope that results obtained this way will be beneficial for many abstraction mechanisms, including the ones mentioned in this paper.
6
Acknowledgements
The authors would like to thank Birgit Penzenstadler, Florian Deißenb¨ock, Stefan Wagner and Martin Feilkas for
175
inspiring discussions on the topic and helpful comments on the paper.
References [1] Scott W. Ambler and Pramodkumar J. Sadalage. Refactoring Databases: Evolutionary Database Design (The Addison-Wesley Signature Series). AddisonWesley Professional, 2006. [2] Jay Banerjee, Won Kim, Hyoung-Joo Kim, and Henry F. Korth. Semantics and implementation of schema evolution in object-oriented databases. In SIGMOD ’87: Proceedings of the 1987 ACM SIGMOD international conference on Management of data, pages 311–322, New York, NY, USA, 1987. ACM Press. [3] Kajal T. Claypool, Jing Jin, and Elke A. Rundensteiner. Serf: schema evolution through an extensible, re-usable and flexible framework. In CIKM ’98: Proceedings of the seventh international conference on Information and knowledge management, pages 314– 321, New York, NY, USA, 1998. ACM Press. [4] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional, 1999. [5] David Garlan, Charles W. Krueger, and Barbara Staudt Lerner. Transformgen: automating the maintenance of structure-oriented environments. ACM Trans. Program. Lang. Syst., 16(3):727–774, 1994.
[11] Ralf L¨ammel. Coupled Software Transformations (Extended Abstract). In First International Workshop on Software Evolution Transformations, November 2004. [12] Ralf L¨ammel and Wolfgang Lohmann. Format Evolution. In Proc. 7th International Conference on Reverse Engineering for Information Systems (RETIS 2001), volume 155 of
[email protected], pages 113–134. OCG, 2001. [13] Tom Mens and Tom Tourwé. A survey of software refactoring. IEEE Trans. Softw. Eng., 30(2):126– 139, 2004. [14] Peter Naur and Brian Randell, editors. Software Engineering: Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7th to 11th October 1968. Scientific Affairs Division, NATO, 1969. [15] Markus Pizka and Elmar Juergens. Tool Supported Multi Level Language Evolution. To Appear, 2007. [16] Stefan Wagner and Florian Deissenboeck. Language development is software design. To Appear, 2006. [17] P Wegner. Varieties of reusability. In Workshop on Reusability in Programming, 1983. [18] Jing Zhang, Yuehua Lin, and Jeff Gray. Generic and domain-specific model refactoring using a model transformation engine.
[6] Elmar Juergens and Markus Pizka. The Language Evolver Lever - Tool Demonstration. In John Boyland and Anthony Sloane, editors, Proceedings of the Sixth Workshop on Language Descriptions, Tools and Applications, pages 62–67, 2006. [7] Chang Hwan Peter Kim and Krzysztof Czarnecki. Synchronizing cardinality-based feature models and their specializations. In ECMDA-FA, pages 331–348, 2005. [8] Paul Klint, Ralf L¨ammel, and Chris Verhoef. Toward an engineering discipline for grammarware. ACM Trans. Softw. Eng. Methodol., 14(3):331–380, 2005. [9] Charles W. Krueger. Software reuse. ACM Comput. Surv., 24(2):131–183, 1992. [10] Ralf L¨ammel. Grammar Adaptation. In Proc. Formal Methods Europe (FME) 2001, volume 2021 of LNCS, pages 550–570. Springer-Verlag, 2001.
176
