Architecture-Centric Evolution in Software Product Lines: Position Paper Hassan Gomaa Department of Information and Software Engineering George Mason University Fairfax, Virginia 22030, USA hgomaa@gmu.edu Abstract: This paper describes how an architecture-centric evolution approach can be used to develop and evolve software product line architectures. The architecturecentric evolution approach described in this paper uses a model driven architecture concept in which UML models of the software architecture are developed prior to implementation and later evolved after original deployment. 1. Introduction A software product line consists of a family of software systems that have some common functionality and some variable functionality [Parnas79, Clements02, Weiss99]. This paper describes an architecture-centric evolutionary development approach for software product lines. This paper advocates that a much clearer idea about how to develop and evolve the software product line is obtained by considering the software architecture rather than by starting directly from the code. The architecture-centric evolution approach described in this paper follows the model driven architecture concept in which UML models of the software architecture are developed prior to implementation. With this approach, the models can later evolve after original deployment. The kernel software architecture represents the commonality of the product line. Evolution is built into the software development approach because the variability in the software architecture is developed by considering the impact of each variable feature on the software architecture and evolving the architecture to address the feature. The development approach is a feature-driven evolutionary approach, meaning that it addresses both the original development and subsequent post-deployment evolution. Being feature based, the approach closely relates the software architecture evolution to the evolution of software requirements.
2 Hassan Gomaa This paper addresses the key factors needed for architecture centered evolution of software product lines, which include: - Evolutionary software process model. It is necessary to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution. - Model-driven software architecture, in which the architecture is developed before the code. - Evolutionary dynamic analysis. Consider the dynamic impact of each feature on the architecture. The results in new components being added or existing components having to be adapted. - Specialization vs. parameterization. When components are adapted for evolution, there are two main approaches to consider, specialization or parameterization. - Component based design. Software components, in which the interface is separate from the implementation. Components differ from objects in that the required interface is designed explicitly in addition to the provided interface. - Software architectural patterns. Architectural structure and communication patterns help in developing and evolving the software architecture. 2. Evolutionary Software Product Line Engineering The Evolutionary Software Product Line Engineering Process [Gomaa99, Gomaa04] is a highly iterative software process that eliminates the traditional distinction between software development and maintenance. Furthermore, because new software systems are outgrowths of existing ones, the process takes a software product line perspective; it consists of two main processes: a) Product line Engineering. A product line multiple-view model, which addresses the multiple views of a software product line, is developed. The product line multipleview model, product line architecture, and reusable components are developed and stored in the product line reuse library. b) Software Application Engineering. A software application multiple-view model is an individual product line member derived from the software product line multipleview model. The user selects the required features for the individual product line member. Given the features, the product line model and architecture are adapted and tailored to derive the application architecture. The architecture determines which of the reusable components are needed for configuring the executable application. 3. Model-driven Architecture The Object Management Group (OMG) promotes model-driven architecture whereby modeling is designing of software applications before coding. Software
Architecture-Centric Evolution in Software Product Lines: 3 modeling approaches are now widely used in software development and have an important role to play in software product lines [Gomaa04]. Modern software modeling approaches, such as the Unified Modeling Language (UML) [Rumbaugh04], provide greater insights into understanding and managing commonality and variability by modeling product lines from different perspectives. A better understanding of the software product line architecture can be obtained by considering the different perspectives, such as requirements modeling, static modeling, and dynamic modeling, of the product line. 4. Evolutionary Dynamic Analysis. Evolutionary dynamic analysis is an iterative strategy to help determine the dynamic impact of each feature on the software architecture. This results in new components being added or existing components having to be adapted. The kernel system is a minimal member of the product line. In some product lines the kernel system consists of only the kernel objects. For other product lines, some default objects may be needed in addition to the kernel objects. The kernel system is developed by considering the kernel use cases, which are required by every member for the product line. For each kernel use case, an interaction diagram is developed depicting the objects needed to realize the use case. The kernel system consists of the integration of all these objects and the classes from which they are instantiated, as described in [Gomaa00, Gomaa04]. The software product line evolution approach starts with the kernel system and considers the impact of optional and/or alternative features. This results in the addition of optional or variant components to the product line architecture. This analysis is done by considering the variable (optional and alternative) use cases, as well as any variation points in the kernel or variable use cases. For each optional or alternative use case, an interaction diagram is developed consisting of new optional or variant objects the variant objects are kernel objects that are impacted by the variable scenarios, and therefore need to be adapted. 5. Managing Variability through Specialization and Parameterization When components are adapted for evolution, there are two main approaches to consider, specialization or parameterization. Specialization is effective when there are a relatively small number of changes to be made, so that the number of specialized classes is manageable. However, in product line evolution, there can be a large degree of variability. Consider the issue of variability in control classes, which are modeling using statecharts [Harel96], which can be handled either by using parameterized statecharts or specialized statecharts. Depending on whether the product line uses a centralized or decentralized approach, it is likely that there will be several different
4 Hassan Gomaa state dependent control components, each modeled by its own statechart. The following discussion relates to the evolution within a given state dependent component. To capture product line variability and evolution, it is necessary to specify optional states, events and transitions, and actions. A further decision that needs to be made when using state machines to model variability is whether to use state machine inheritance or parameterization. The problem with using inheritance is that a different state machine is needed to model each alternative or optional feature or feature combination, which rapidly leads to a combinatorial explosion of inherited state machines. For example, with only three features that could impact the statechart, there would be eight possible feature and feature combinations, resulting in eight variant statecharts. With 10 features, there would be over 1000 variant statecharts. However, 10 features can be easily modeled on a parameterized statechart as 10 feature dependent transitions, states, or transitions. It is often more effective to design a parameterized state machine, which consists of all states, events, and transitions, corresponding to all features Optional transitions can be specified by having an event qualified by a feature condition, which guards entry into the state. Thus the feature condition is True if the optional feature is selected for a given product line member, and false if the feature is not selected. The impact of feature interactions can be modeled very precisely using state machines through the introduction of alternative states or transitions. Designing parameterized statecharts is often less complex than designing specialized statecharts. 6. Modeling Component-based Software Architectures Software components are similar to classes in that the component interface is specified separately from the implementation. However, components differ from classes in that the required interface is designed explicitly in addition to the provided interface. This is particularly important for architecture-centric evolution, since it is necessary to know the impact of the change to a component on all components that interface to it. UML 2.0 has added new concepts for depicting software architectures and components. Components can be effectively modeled with structured classes and depicted on composite structure diagrams [Rumbaugh04]. Structured classes have ports with provided and required interfaces. Structured classes can be interconnected through their ports via connectors that join the ports of communicating classes. To provide a complete definition of the component-based software architecture for a software product line, it is necessary to specify the interface(s) provided by each component and the interface(s) required by each component. A provided interface is
Architecture-Centric Evolution in Software Product Lines: 5 a collection of operations that specify the services that a component must fulfill. A required interface describes the services that other components provide for this component to operate properly in a particular environment. This capability for modeling component-based software architectures is particularly valuable in product line engineering, to allow the development of kernel, optional and variant components, plug-compatible components, and component interface inheritance. There are various ways to design components. It is highly desirable, where possible, to design components that are plug-compatible, so that the required port of one component is compatible with the provided ports of other components to which it needs to connect. Consider the case in which a producer component needs to be able to connect to different alternative consumer components in different product line members. The most desirable approach, if possible, is to design all the consumer components with the same provided interface, so that the producer can be connected to any consumer without changing its required interface. As the product line evolves new producers can communicate with the consumer. It is possible for a component to connect to different components and have different interconnections such that in one case it communicates with one component and in a different case it communicates with two different components. This flexibility helps in evolving the software architecture. When plug-compatible components are not practical, an alternative component design approach is component interface inheritance. Consider a component architecture that evolves in such a way that the interface through which the two components communicate needs to be specialized to allow for additional functionality. In this case, both the component that provides the interface and the component that requires the interface have to be modified the former to realize the new functionality, and the latter to request it. The above approaches can be used to complement compositional approaches for developing component-based software architectures. 7. Software Architectural Patterns Basing the software architecture on one or more software architectural patterns, both architectural structure patterns and architectural communication patterns, helps in designing the original architecture as well as evolving the architecture [Gomaa98, Gomaa04]. This is because the evolutionary properties of architectural patterns can also be studied. For example, a layered architectural pattern allows for ease of extension and contraction [Parnas79] because components can be added to or removed from higher layers that use the services provided by components at lower layers of the architecture. In a centralized control pattern, evolution takes the form of
6 Hassan Gomaa added input and output components that interact with a controlling control object, which executes a statechart that can evolve as described in Section 5. In a client/server pattern, the server can evolve by adding new services, which are discovered and invoked by clients. In addition to the above architectural structure patterns, certain architectural communication patterns also encourage evolution. In software product lines, it is often desirable to decouple components. The Broker, Discovery, and Subscription/Notification patterns encourage such decoupling. With the broker patterns, servers register with brokers, and clients can then discover new servers. Thus a product line can evolve with the addition of new clients and servers. A new version of a server can replace an older version and register itself with the broker. Clients communicating via the broker would automatically be connected to the new version of the server. The Subscription/Notification pattern also decouples the original sender of the message from the recipients of the message. 8. Conclusions This paper has described an architecture-centric evolutionary development approach for software product lines. This paper has discussed several key factors to consider for architecture centered evolution of software product lines, which assist in developing the software architecture before implementation and later evolving the software product line architecture after original deployment. 9. References [Clements02] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison Wesley, 2002. [Gomaa98]H. Gomaa and G. Farrukh, Composition of Software Architectures from Reusable Architecture Patterns, Proc. IEEE Intl Wkshp on Soft Arch, Orlando, FL, Nov 1998. [Gomaa99] H. Gomaa and G.A. Farrukh, Methods and Tools for the Automated Configuration of Distributed Applications from Reusable Software Architectures and Components, IEE Proc - Software, Vol. 146, No. 6, December 1999. [Gomaa00] H. Gomaa, "Designing Concurrent, Distributed, and Real-Time Applications with UML", Addison Wesley, Reading MA, 2000. [Gomaa04] Gomaa, H. Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures, Addison-Wesley, July 2004. [Harel96] Harel, D. and E. Gary, Executable Object Modeling with Statecharts, Proc. 18 th International Conference on Software Engineering, Berlin, March 1996. [Parnas79] Parnas D., "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, March 1979. [Rumbaugh04] J. Rumbaugh, G. Booch, I. Jacobson, The Unified Modeling Language Reference Manual, Second Edition, Addison Wesley, Reading MA, 2004. [Weiss99] D M Weiss and C T R Lai, Software Product-Line Engineering: A Family-Based Software Development Process, Addison Wesley, 1999.