Software Product Line

Aspect-oriented and Component Adaptation for SPL Hozefa Jodiawalla, Sindhu Balakrishnaachari, Sandeep Bansal, Bharni Ellenki Illinois Institute of Technology {hjodiawa; sbalakr3; sbansal;bellanki}@iit.edu

Abstract Software product lines (SPLs) based development aims at saving development cost as well as reducing time-to-market by structured reuse of base assets for a group of similar products. Requirements of product line are organized into features in FOA (FeatureOriented Analysis) approach. Commonalities and variabilities among products in a product line are showed in the features. The effectiveness of a SPL approach depends on how well feature variability is implemented and managed. Because there is crosscutting among the features, it is difficult to implement these features into architectural components. In this paper we discuss the role of aspect oriented programming and component adaptation with regard to the benefit they provide to software product line.

1. Introduction In recent times, the term Software Product lining has been widely known for its usage and benefits that it provides to the clients. One increasing trend in software development is the need to develop multiple, similar software products instead of just a single individual product. There are very solid reasons for its popularity among the business solutions providers. Products that are being developed for the international market must be adapted for different legal or cultural environments, as well as for different languages, and so must provide adapted user interfaces. Most high-tech companies provide products for a specific market; thus the products have many things in common. An increasing number of these companies realize that product line development fosters reuse at all stages of the product life cycle, shortens development time and helps staying competitive..Because of cost and time constraints it is not possible for software engineers to develop a new product from scratch for each new customer, and so the only way possible to reduce time is to increase the reusability of the CS 487: SPM

1

functionalities and commonalities in software systems developed for different clients. We can also interpret it as using various predefined components and integrating those components using interfaces. Component adaptations and aspect orientation programming are one of the most associated terms used while discussing the Software Product line as it play a vital role. To understand how aspect oriented programming and component adaptation are implemented, we are going to discuss these topics in details further below.

2. Aspect-Oriented Programming Aspect-oriented programming is a new programming technique that takes another step towards increasing the kinds of design concerns that can be captured cleanly within source code. Aspectoriented programming provides explicit language support for modularizing design decisions that cross-cut a functionally-decomposed program. Instead of spreading the code related to a design decision throughout a program’s source, a developer is able to express the decision within a separate, coherent piece of code. Let's introduce some standard terminology to help us understand the concepts. Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the dataaccess layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical. Advice: This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method. Point-cut: This is the term given to the point of execution in the application at which cross-cutting IIT

concern needs to be applied. In our example, a pointcut is reached when the thread enters a method, and another point-cut is reached when the thread exits the method. Aspect: The combination of the point-cut and the advice is termed an aspect. In the example below, we add a logging aspect to our application by defining a point-cut and giving the correct advice. Joint point: distinguishable point in progress of executing program. That might be calling methods or assigning values to members of objects.

// primary code { //secure code } // other code } Any time any code calls this program with any parameters and if u want to secure few lines of code, then consider these two classes:

There are many other facets of AOP, such as introductions (where interfaces/methods/fields can be added to existing classes), that hold tremendous potential for developers. For example, ensuring that a set of operations do not execute concurrently typically requires spreading code throughout the operations; an aspect-oriented approach allows the synchronization constraint to be specified in one separate piece of code. The aspect code is combined with the primary program code by an aspect weaver.

Class C1 {

Object oriented programming has become main stream over the last years, having almost completely replaced the procedural approach. One of the biggest advantages of object orientation is that a software system can be seen as being built of a collection of discrete classes. Each of these classes has a well defined task; its responsibilities are clearly defined. In an OO application, those classes collaborate to achieve the application's overall goal. However, there are parts of a system that cannot be viewed as being the responsibility of only one class, they crosscut the complete system and affect parts of many classes. Examples might be locking in a distributed application, exception handling, or logging method calls. Of course, the code that handles these parts can be added to each class separately, but that would violate the principle that each class has well-defined responsibilities. This is where AOP comes into play: AOP defines a new program construct, called an aspect, which is used to capture cross-cutting aspects of a software system in separate program entities. The application classes keep their welldefined responsibilities. Additionally, each aspect captures cross-cutting behavior.

C2 with method m3, m4 and m5

Consider the example where AOP is illustrated Aspect Logging { CS 487: SPM

2

C1 with method m1, m2

m1() {…..} m2() {….} }

Class C2 { m3() {…..} m4() {….} m5() {….} } In the above code, suppose the secure code is println login id and method call. This need to written in the code 5 times which shows repetition and again a change required in the secure code we would have to change it at 5 different code locations in methods. Here AOP comes into picture and Logging Aspect will be defined once but will be applied at those 5 point cuts formula specified. A very powerful formula named AspectJ, which is Java programming language plus aspect oriented concept. Grammatical constructs to present crosscutting concerns in AspectJ are dynamic cross cutting concern that adds or modifies behavior of a program and static crosscutting concern that intervene in modifying static structure of a program. IIT

Software product line is designed for the effective management and use of the asset through the separation of commonality and variability. Therefore, development of product line costs to manage assets separately so that users are different from developer for components. AOP when adapted in software product line implementation helps modulation. AOP makes the effect minimum for the components that developed commonalities and variability’s in the assembly process with them, and used aspect as the glue role. Variant functions are combined with the core asset implement common functions using advice that is a grammatical construct of AOP. If variant components are divided optional functions and alternative functions and if it is realized using before advice, after advice and around advice of AOP, core assets can combine with variability’s without any change of them. If we can make a next edition product be completed with no change of code, it is very efficient in assets management and usage.

3. Component Adaptation The developers would like to make use of the available components which have high quality and reliability to build applications according to the normal formal of the large-scale software development in CBSE. However, the differences between the names, parameters and their types of component and the requirement of application or the matter that the requirement of application is satisfied partly by the retrieved component is often unavoidable. Different component adaptation algorithms are proposed by the researchers which strongly dependent on the representation of the component in the library, the component granularity, and so on. Most proposals concentrate on adaptations that can be achieved either at compile time or at link time. Current support for dynamic component adaptation, i.e. unanticipated, incremental modifications of a component system at run-time, is not sufficient. From a technical perspective, the reason is largely due to the difficulty of locating suitable components in the library and adapting these components to meet the specific needs of the user. 3.1 Different types of component adaptation There are formally several component adaptation types including changing interface names when the CS 487: SPM

3

names of some of the operations provided by the component do not match the expected interface, changing interface parameters when the number of interface parameters provided by the component does not match the number of the expected interface parameters, function adaptation when the function of the retrieved component satisfies partly the exception function, component composition when a combination of two or more components is able to provide the required functionality. System will select a kind of adaptation type to adapt the component according to the difference between the semantic specification of the retrieved component and the semantic specification of the user requirements. Different adaptation approach can be used according to the amount of components involved in component based system. A component can be adapted by a serial of adaptors according to the differences. The semantic specification is, where is a type of adaptor which can be used to adapt the correspond difference. (ak,…,ak)c =ak(…(a2 (a1 c))),k >=0, where akis a type of adaptor which can be used to adapt the correspond difference. There are two types of differences between component and the user requirements. One is that the interface name, named ‘a’, whose correspond method function satisfies the user need is different from the interface name, name dc, which is needed by the user. The other difference is function mismatch. For example, f unction whose method name is needed to be added to the retrieved component. System can use the following two adaptors. 3.2 Adaptation Techniques There are two kinds of components needed to be adapted. One kind is the components retrieved from component library satisfy partly the user needs. The other kind is the components interoperating in the open system have the behavior mismatch. Adapted components are amended to address the source of conflict with other components or with the underlying integration framework. A component interface consists of two parts: A signature definition (describing the functionality offered and required by the component), and a behavior specification (describing the interaction protocol followed by the component). These techniques adapting the IIT

component’s names, parameters or data types, parameter reordering between components, are Signature Level Adaptation (Modified services). Many of the works in the literature of component adaptation deal with adapting the component behaviors. These techniques often extend or change the functionality of involved components. The functionality that we wish to support is not part of the API of the user, and we must composed two components or more by writing glue code that combines the functionalities of the components. This definition of glue is oriented more toward programmatic constructs. Some techniques often change or add non-functional properties, such as temporal properties, security, reliability, accuracy, cost, Quality of Service (QoS) related notations, and so on. 3.3 Future Works Component adaptation is a hard problem which involves a large amount of domain knowledge and may require complex reasoning. Now, there does not existing a standard for component adaptation. As shown, there is a big research effort being put in the field of automatic and dynamic component adaptation. Not many efforts have been devoted to concern the questions, e.g. how to measure the adaptor used for component adaptation precisely in time and memory consume, what impact to the Quality of Service properties of the adapted component, how to measure the adequacy of the adapted components, How to reduce the complexity of the adaptation, and the automate adaptation of components etc. So, there are some interesting issues still open which deserve future research. A valid mathematic model of component adaptation can help to prove the correctness and the validity of component adaptation in theory. There does not existing an objective or subjective standard to assess the component adaptation. The formal method consists of a complex problem divided into several sub-problems; all of the sub-problems can be solved by existing adaptable components. Formal method is a good way to adapt components in CBSE. A major drawback of the mainstream approach for CBSE is that it mainly focused on programming/low level features making it difficult to reason on problematic issues hidden behind the CBSE promised results. Not many efforts have been devoted to develop well-founded component adaptation theories. CS 487: SPM

4

In general, component adaptation can be divided into three families. One is to adapt component signature properties, such as names, parameters. The second one is function adaptation that is how to integrate the different components both meeting partly the user’s requirement to satisfy the final requirement. The third one is behavior adaptation that is how to mediate the component behavior when behavior mismatches occur. Existing methods are not commonly used because of their complexity and insufficient tool support. The adaptation mechanisms of component software are still limited.

4. Software Product Line Software product line has emerged as an attractive phenomenon within organizations dealing with software development process. The concept of software product line, proposed by SEI is a comprehensive model for an organization building applications based on common architectures and core assets. The concept of software product line is based on development of identical systems having controlled variability among each other. Clements and Northrop defined software product line, a set of software-intensive systems sharing a common, managed set of features that satisfy 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. Software product line deals with assembly of products from existing core assets, commonly known as components, and continuous growth in the core assets as production proceeds. The study of software product lines addresses the issues of engineering software system families, or collections of similar software systems. The objective of a software product line is to reduce the overall engineering effort required to produce a collection of similar systems by capitalizing on the commonality among the systems and by formally managing the variation among the systems. This is a classic software reuse problem. The primary focus of software product line research has been on domain analysis and modeling, architecture modeling, software reuse repositories, generators, and process definition. In contrast, for engineering single systems, these technologies and techniques provide significant value, while for engineering software product lines the conventional wisdom suggests they are essential. IIT

4.1 The Void in Existing Software Technology There are several reasons why domain analysis, architecture modeling, software reuse repositories, generators, and process definition have occupied the central focus in software product lines. First, since software product lines are harder to engineer than single software systems, the most rigorous and advanced software engineering techniques are the most likely candidates to apply to the problem. Second, domain and architecture models can represent abstractions for a software family. This is an essential feature of any software reuse technology. Finally, the software engineering processes for building software product lines can be quite different from the process for building single systems. Software process definitions can succinctly express these differences. The majority of the engineering effort in the life of a single software system is spent at the source level. Software product lines in practice (as opposed to in the research lab) have a similar profile. The effectiveness and efficiency of a practical software product line deployment is therefore dependent on how well this source level activity is supported. Several important differences exist at this level between single systems and software product lines. This accounts for the primary engineering differences between the two approaches. With single systems, software engineers can maintain a single point of view throughout the development process (i.e., focused on the implementation of the single system). In contrast, with software product lines, software engineers must take different points of view at different times in order to effectively develop the software family.

based on feature parameterization. The selfconfiguring software product line technology allows software engineers to move between and to work from different points-of-view, or levels of software reuse abstraction, in order to effectively create, evolve, and maintain a software product line. There are different views from which the software can be viewed: the global view allows engineers to see and modify the combined collection of common and variant components in a product line the product view allows engineers to see an individual product that is produced by the product line and to make modifications that are reflected back into the global view the feature view allows engineers to declare the dimensions of variation in a product line and to define the specific feature choices for the individual products the mapping view allows engineers to see and modify the mapping between the abstraction specification for a product line and the abstraction realizations (i.e., the mapping from the global and feature views to the product views). 4.3 Software Product Line Configurations Configurators take two types of inputs – core software assets and product models – in order to automatically create product instances. The core software assets can include requirements, architecture and design, source code, test cases, product documentation, and so forth. The product models are concise abstractions that characterize the different product instances in the product line, typically expressed in terms of a feature model.

4.2 Filling the Void A new type of technology is needed to support the different software reuse points-of-view and to thereby fill the void in the day-to-day engineering activities for software product lines. At BigLever Software, we research, develop, and commercialize software product line technology that fills the void in the existing tool and technology space. We refer to this technology as self-configuring software product line technology. This term suggests the analogy to agile manufacturing systems that can reconfigure themselves to produce different products CS 487: SPM

5

Predominate development effort with configurators is domain engineering of the core assets. There is a relatively small effort that goes into the product models, which essentially replaces the manual application engineering effort. At first glance, this appears similar to the use of abstraction in conventional source code compilers, software IIT

generators, or model-driven development compilers. However, configurators work more by composition and configuration of conventional assets rather than generation, transformation, or translation of one representation into another representation. Software mass customization with configurators provides a simpler, more efficient, and more scalable solution. Since all software exists within a consolidated collection of core assets, everything is candidate for reuse. This is true even for product-specific assets that start out as unique to one product. Since all development is focused on core asset development, teams are organized around the assets. Evolution of the core assets and products is synonymous. For example, a change in the core assets can follow by automated re-instantiation of all products to reflect that change. No manual merging and reintegration is required.

5. Conclusion Aspect-oriented methodology arises as an approach to separate concerns in software development. In recent year AO techniques are used in SPLs that is a promising software development approach. AO techniques can modularize crosscutting common features, manage variability, and support the evolutions of the core. Beside what we describe above, AO techniques can benefit SPLs from other phases, for example, aspects play an important role in the domain analysis for concerns separation. From what we discussed above, we are aware of the role of aspects in SPLs, and convinced that Aspect Oriented Product Line Engineering will show its advantages with the research going on. Despite the success of component-based reuse, the mismatches between available pre-qualified components and the specific reuse context in individual applications continue to be a major factor hindering component reusability and smooth composition. The aspect-oriented nature of our approach makes it particularly suitable for the improvement of non-functional features of the target component-based software, such as dependability and performance.

approach. Commonalities and variabilities among products in a product line are showed in the features. The effectiveness of a SPL approach depends on how well feature variability is implemented and managed. Because there is crosscutting among the features, it is difficult to implement these features into architectural components. In recent years some papers introduce aspect-oriented techniques into SPL to modularize the variable features.

6. References [1] Walker, R.J.; Baniassad, E.L.A.; Murphy, G.C. An initial assessment of Aspect-Oriented Programming. Software Engineering, 1999. Proceedings of the 1999 International Conference. [2] Krueger, C.W. Software product line reuse in Practice. ASSET '99. Proceedings. 1999 IEEE Symposium. [3] Krueger, C.W. New methods in software product Line Development. Software Product Line Conference, 2008. [4] Xie Xiong; Zhang Weishi. The Current State of Software Component Adaptation. Semantics, Knowledge and Grid, 2005. SKG '05. [5] T Elrad. Introduction.

Aspect-oriented

programming:

Software product lines (SPLs) based development aims at saving development cost as well as reducing time-to-market by structured reuse of base assets for a group of similar products. Requirements of product line are organized into features in FOA (Feature-Oriented Analysis) CS 487: SPM

6

IIT