Software Product Line Engineering (SPLE) is a new methodology of software product engineering. SPLE is able to support large-scale production of software in domain. Accepted by most developers, component-based development (CBD) is a technique to develop reusable components. This project purpose to research component-based reference architecture, which is the heart of SPLE.
This report starts with introduction of research background, including feature model, function model, reference architecture, etc. Then the report discusses the research method about component-based reference architecture. At the end, the report demonstrates the research progress, including underlying need, preliminary result, remaining work and so on.
Chapter 1 – Introduction
Software Product Line Engineering (SPLE), as its name implies, is a kind of industry using product line to produce software as the product. To understand what SPLE really is, we should understand product line first.
Product line is a group of related products that have similar functions and target customers. These products may have same marketing channel and price range as well. For example, Ford Motor Company’s product line include Model A, Model B, Model T, Model N, Model S and so on [1]. Some company even offer one more product lines.
Entering the 21st century, the IT industry has blossomed. More and more software developer realized that product line can be leaded into these field. The main goal of Software Product Line Engineering is to develop a group of related software products at lower costs, in shorter time and with higher quality [2]. These related software products should be produced from a shared set of software assets using a common means of production [3,4]. The characteristic of SPLE is predictive software reuse, which is a giant leap forward. Rather than put general software components into a library and hope maybe some day they will be reused, software product lines only call for software artifacts to be produced while reuse is predicted in one or more products in a well-defined product line [5].
As a field of study, SPLE can be traced back to the 1970s. Several methodologies and tools were invented, but each of them left something to be desired. In the current state of SPLE research, researchers seem to attach importance to the component-based development (CBD). Touted as the solution to the latest software crisis, CBD differs from traditional development in that the application is not developed completely from scratch. A component-based application is assembled from a set of pre-existing components [6]. This principle can be perfectly used in SPLE. When we design a software product line, we observe and analysis the group of related software products and find their commonality and variability first. Then we implement different components contains commonality or variability. Finally, we can assemble these components to create a software product just like automobile company produced different types of car by using assembly line.
A well-defined software product line ought to consider every possible variants. To do so, we should build a reference architecture that consist of two aspects: feature model and functional model. Feature Models were first introduced in the Feature-Oriented Domain Analysis (FODA) method by Kang in 1990 [7] and used to provide all the features of products in SPLE. A function model is a structured representation of the functions (activities, actions, processes, operations) within the modeled system or subject area [8]. However, it is difficult to combine feature model and functional model to create reference architecture. How to link feature model, functional model and reference architecture is exactly the key of SPLE.
SPLE could be seen as a model which has two life cycles. The first cycle is called Domain Engineering. The second cycle is Application Engineering. Domain Engineering focus on how to create a reference architecture based on feature model and functional model. Application Engineering, on the other hand, focus on designing and developing concrete software products by using the result from Domain Engineering.
There are some approaches of creating Software Product Line, for example, FODA [7] and Second Generation Product Line Engineering (2GPLE) [10]. But none of them can describe a complex reference architecture in detail without flaws. And there are also some tools that claimed can be used to build software product line, for example, pure::variants [11]. In fact, none of these tools can create a product line based on reference architecture, they uses feature model instead. However, a new tool named X-MAN Reference Architecture Tool (X-MAN RAT) [12] might be helpful. It can create a specific architecture for one product. The gap to a real reference architecture is still big, but it is a good start nevertheless.
1.1 Project Aims and Objectives
The main goal of the project is to investigate different Software Product Line Engineering methodologies and tools. After that, I will design and implement a reference architecture of software product by X-MAN RAT based on feature model and function model. Additionally, I will try to help the Component-based Software Development Group to develop the new tool of SPLE if I have enough time. For now, the objectives to achieve the goals of the project are defined:
Investigate different methodologies of Software Product Line Engineering to conclude the merits and demerits
Investigate different tools of creating Software Product Line to conclude the merits and demerits
Find a best tool to develop feature model
Learn how to use X-MAN RAT and use it to create a reference architecture.
Help the group to develop the new tool
1.2 Report Outline
The structure of the report is listed below:
Chapter 2 represents background knowledge, which explains the principles of Software Product Line Engineering, requirement management, variability management, organizations, feature model, functional model, different approaches of product line and so on.
Chapter 3 represents research methods including component-based approach modeling, different modeling tools and so on.
Chapter 4 represents progress of the research. The completed work and the remaining work will be discussed in this section.
Chapter 5 represents list of references
Chapter 2 – Background
In this Chapter, I will introduce some elementary knowledge about Software Product Line Engineering (SPLE). It consists of multiple aspects, such as life cycles, architecture, models, merit and demerit. And some approaches of SPLE will be presented in the end of this chapter.
2.1 Principle of Software Product Line Engineering
Software Product Line Engineering (SPLE) is a developing methodology of software engineering. The basic idea of SPLE is to generate a group of relevant software products that share commonalities and variabilities. Carnegie Mellon University Software Engineering Institute (CMU/SEI) offered a detailed definition of Software Product Line: ‘a set of software-intensive 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.’ [13]
The aim of using software product line is large-scale reuse of software. The extraordinary growth of software industry in the twenty-first century presented a new issue that the quantity of softwares could not keep pace with market demand. The similar incident happened in the beginning of twenty century, but people demanded for industrial products such as vehicles at that time. To solve the problem, automobile companies introduced product lines to reuse the models of different components. This method promoted productivity enormously. For example, the time of assembling chassis of a Ford Model T decrease from 12 hours and 8 minutes to one hour and 33 minutes. As a result, the price of a Model T decrease from 825 dollars to 260 dollars and 15 million Model T’s is produced in two decades [14]. Nowadays more and more software engineering researchers believe that the software product line will has the same performance. Moreover, software product line is deemed to improve reliability, usability, portability and maintainability of software product [15].
Software Product Line Engineering framework consists of two life cycles. The first lift cycle is called Domain Engineering. The main purpose of Domain Engineering is to support systematic reuse by concentrating on the common modeling knowledge in particular domain [16]. Domain Engineering presents five processes: product management, domain requirements engineering, domain design, domain realisation and domain testing. The development of five processes aims to reuse [17]. Application Engineering implement concrete family members or applications rapidly based on the result from Domain Engineering [18]. Four processes, which are application requirements engineering, application design, application realisation and application testing, are included in the Application Engineering. The figure 2.1 display the details of these two life cycles.
Figure 2.1 The software product line engineering framework [19]
Linda Northrop, the chief scientist from CMU/SEI, described three activities for Software Product Lines. As figure 2.2 shown, the activities are core asset development, product development and management. Core asset development. The core asset development will be in action when the conditions are met. Four of the most important contextual factors are product constraints, production constraints, production strategy and preexisting assets [20]. By and large, the core assets, which derived from the old products, are used to build new products [21]. The outcomes of core asset development, including product line scope, core asset base and production plan, are ready for product development. Product development happens when the essential requirements are satisfied either. The requitements are not only the derivations from core asset but also the specific product description. Finally, the product development creates concrete products and feedback to core asset development [21]. Product management, on the other hand, is not involved in the product line directly. The key function of management is to handle the economic issues. In spite of the consideration of business, it could influence the software product line and market strategy a lot [2].
Figure 2.2 The rotating circle of three activities for Software Product Line [20]
2.2 Merit of Software Product Line Engineering
Some researchers classify Software Product Line Engineering (SPLE) merit into three types: organizational bene’ts, software engineering bene’ts and business bene’ts [22].
Organizational benefits have regrouped outstanding advantages that ordinarily serve business goals. According A Framework for Software Product Line Practice, these benefits include:
‘ 1. large-scale productivity gains
2. decreased time to market
3. increased product quality
4. decreased product risk
5. increased market agility
6. increased customer satisfaction
7. more efficient use of human resources
8. ability to effect mass customization
9. ability to maintain market presence
10. ability to sustain unprecedented growth’
Organizational benefits are able to improve the reusability of core asset. Unlike traditional component reuse, software product line reuse is a strategic organizational alternative, a organization-wide reuse [24].
Software engineering benefits such as thorough view of client’s requirement, friendlier user interface, improvement of component’s reusability, better decomposition of product group, better quality of software and so on. Software engineering benefits are no doubt to promote the efficacy of product of development [22].
And last but not least, business benefits, which comprise of increasing production, reducing cost, economizing on manpower, improving maintainability, are the exact reason why companies and institutions choose product line reuse over traditional product reuse [22]. For example, Nokia Corporation has a massive product line of mobile phone. Over 220 different phones were produced. That means variable number of keys, display sizes, protocols, platforms, language supports, baseband, etc. are provided. Product line engineering bring Nokia astonishing business benefits in past decades [20,23]. Generally business benefits is relevant to the product management activity of product lines engineering.
2.3 Demerit of Software Product Line Engineering
Because of the merits presented above, Software Product Line Engineering (SPLE) has enjoyed increasingly wide adoption in the software industry. But in fact SPLE has demerits as well. The first life cycle, domain engineering, in the SPLE is helpful to design and develop core assets of product group. As a result, it describes detailed artifacts of product like requirements, architecture, feature model, functional model, performance criteria, constraints and so on. These things are important and might extensive reused in the process of application engineering. Unfortunately, these bring demerits either. The first demerit we should face up to is resistance of change [22].
To build a software product line, it is inevitable to create a reference architecture, which is a batch of product architecture. Product architecture is combined by feature model and functional model, which composed by elementary features and functions respectively. The relations between element could be very complex if the product is big enough. Likewise, the relations between products could be very complex if the product group is large enough. All in all a software product line looks just like a significant but subtle machine threatened by any tiny change. A ill-defined reference architecture could be ruined because of a new feature, an unworkable function or a changed requirement. And it is very difficult to build a perfect architecture unless the developers and architects not only give mature consideration to all aspects but also take a long-term view.
Another reason why product line architecture is difficult to build is the lack of guidelines, approaches and tools. SPLE is a developing methodology and the approaches of SPLE are controversial. Most of the approaches just use Feature-Oriented Product Line Engineering to replace it. The lack of tools is a more serious problem. Actually, there is no reference architecture tool so far. Even if developers have the ability to create a software product line, there still is a problem called cost-effectiveness.
We have already known many companies prefer SPLE because the advantages of SPLE will bring huge profits. However there is a reasonable explanation that why some other companies reject SPLE. SPLE, unlike traditional software engineering, needs more preparation. That means a company has to invest more money at the early stage to collect information, filter requirements, build models and create architecture. Indeed the more types of software product are produced by software product line, the lower average cost each product get. But if a software product line has few products, the cost of SPLE might equals, even higher then, the cost of traditional software engineering. Figure 2.3 visualize the relations between developments and efforts.
Figure 2.3 Software Product Line Engineering Costs [22]
2.4 Organization of Software Product Line
Software product line is a complicated system with multiple departments. To clarify different activities in these departments, the organization of software product line should be managed. Figure 2.4 is a hierarchical organization structure with multiple levels.
Figure 2.4 A simple hierarchical organization with four projects [2]
Jacobson (1997) presented the roles needed for a reuse organization [25]. Weiss and Lai (1999) discussed how to use a hierarchy as the start point to allocate responsibility in Family-oriented Abstraction, Specification, and Translation (FAST) process [26]. Bosch (2000) finally defined four basic types of organization structures which are development department, business units, domain engineering unit and hierarchical domain engineering units [24].
Development department model, as presented graphically in figure 2.5, separates the core assets and products. The core assets, including both architecture and components, are reusable and shared by the different products. Developers in the development department can be assigned to any work. But Bosch believed that the organization will be restructured somehow if the development department owns over 30 developers. The advantage of development department is to increase the efficiency and adoptability of software product line. The disadvantage is the terrible scalability. Every time the organization expands or updates, it is inevitable to be restructured [24].
Figure 2.5 Development Department Model [24]
Business unit model, as shown graphically in figure 2.6, is organized around business units. The reusable core assets are shared by multiple business units. A business unit develops a individual product, including expanding the utility of the shared assets, testing and so on. In general, business unit focus on creating and improving new products or components. Bosch believed that the number of staff members should between 30 and 100. The advantage of business unit model is that the sharing of assets is more effective, especially in terms of access to the assets. The disadvantage of business unit model is the lack of attention in the shared assets that may erode architecture and components in the product family [24].
Figure 2.6 Business Unit Model [24]
Domain engineering unit model, as displayed explicitly in figure 2.7, is similar to business unit model. The difference is that domain engineering unit model separate the development and shared assets advancement from the whole development system. The separated part is domain engineering unit concerned with core assets and the rest is product engineering part concerned with concrete products. Domain engineering unit model has several advantages. It is suitable for large organizations with more staff members then the aforementioned models. It also attaches importance to components in order to satisfy all the requirements of all systems in the product line. The disadvantage of domain engineering unit model is slow response to requirements change. The conflict requirements between domain engineering unit and product engineering unit will cause delays of new products [24].
Figure 2.7 Domain Engineering Unit Model [24]
Hierarchical domain engineering unit model, as figure 2.8 shown clearly, is an improvement of domain engineering unit model. We choose to use business unit model or domain engineering unit model depending on the size and complicatedness. However, hierarchical domain engineering unit model is only suitable for a large or very large organization. As its name implies, the product line is organized in a hierarchical mode. Sometimes we believe that the reusable assets on the top level is not explicit enough to be shared directly by products. The solution is to add specialized product line software architecture and the associated components. The specialized domain engineering units are helpful if too many members in the product family. Obviously, domain engineering engineering unit model has disadvantage as well. It is difficult to provide a rapid reaction of changed marked requirements [24].
Figure 2.8 Hierarchical Domain Engineering Unit Model [24]
2.5 Software Product Line Requirements Engineering
IEEE defined the term requirement as: ‘A requirement is:
a condition or capability needed by a user to solve a problem or achieve an objective
a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
a documented representation of a condition or capability as in definition 1 or 2 ‘ [27]
Requirements must be discovered and accepted by clients, users and providers of a software product before the software is developed [28].
Requirements engineering is the process of finding out, recording and coping with the requirements for computer-based system. The purpose of requirement engineering is to generate a collection of requirements, which should be completed, dependable, applicable and reflect the customer’s desire as far as possible. As figure 2.1 shown, requirements is an important part of both domain artefacts incl. variability model and application artefacts incl. variability model.
There are a great deal of activities in requirement engineering for variable systems. According Sommerville ‘s(1997) conclusion, these activities commonly includes ‘ elicitation, analysis, specification, verification, and management, where
Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user’s needs and constraints for the system.
Requirements analysis is the process of refining the user’s needs and constraints.
Requirements specification is the process of documenting the user’s needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification) ‘ [29,30]
In software product line engineering, requirements should be treated as core asset. Like architecture and components, requirements are reusable and shared by different products. Requirements have variation points that lead to variation models and products.
2.6 Variability Management
The key to creating a software product line is to define and comprehend the commonality and variability of products. The commonalities consist of entities and characteristics that are shared by all products produced by the product line. The variabilities, on the other hand, derive different products. It is the reason why that product line applications distinguish between each other [31]. Variability management, in principle, is the assurance of mass customization.
Domain engineering undoubtedly takes the responsibility for gathering the commonalities and variabilities of product line applications. In addition, the outcome of domain engineering should provide the implementation of commonalities and variabilities that are required for the particular products. After then, the application engineering takes the responsibility for using the commonalities and variabilities to assemble diverse software products [31].
To manage variability, there are several questions need to be answered, such as, how to identify and present variabilities? How to bind variabilities? How to control variabilities? [32]
The primary identification of variabilities are based on feature concept [33]. Feature, as a logical unit of behaviour, must match up a series of quality and functional requirements [33]. The feature concept has been repeatedly updated to adapt the demands of the product line approach [34,35,36]. Features are usually represented through dendrograms. The nodes can be regarded as variation points. We can realize the relations between features and variation points and the relations amongst features. Some software product line approaches are based on feature models. In that case, variability information is always integrated into existing models, for example, UML model.
The variability binding time suggests the achievement of software product line life cycle. It is how we know what variation point should be chosen in different periods [32]. According to Anastasopoulos and Gracek, the variability binding time is classified into: ‘(i) compile time ‘ the variability is resolved either before the program is compiled or at compile time; (ii) link time ‘ the variability is resolved during module or library linking, by selecting different library with different versions of exported operations; (iii) runtime ‘ the variability is resolved during program execution; (iv) update time or post runtime ‘ the variability is resolved during the program updates or after its execution. [32]’
2.6.1 Variability Management Process
Variability management interacts with every activity of a product line core assets development [32]. According Van Gurp, Bosch and Svahnberg, the variability management process consists of four activities. The first activity is variability identification, which is composed of recognizing product differences and locating product differences within product line artefacts. The second activity is variability delimitation, which describe the binding time and diversity. The third activity is variability is implementation, which is the choice of implementation mechanisms. The last one is variability management, which is domination of variants and variation points [33]. These activities serve to generation of variability management process.
Executed by the product line manager, the variability management process runs iteratively and incrementally in parallel with the core asset development. While the variability management process activities are executed, the number of variabilities is inclined to increase. After then, because of the iterative nature of process, the process is capable of updating itself from any activity within the process.
2.6.2 Categories of Variability
Aiello, Bulanov and Groefsema gave two main categories of variability, which are design-time and run-time variability. Obviously, the two types of variability are defined by its stage of the life cycle [38].
Design-time variability manages the variations in design-time process. In this process, similar processes are implemented based on a reference process and different variations with the aim of sustaining all variants. Put another way, this process is to figure out the commonalities between similar processes and establish variations where differences take place. The next step is conceiving the variations for the universal process in such a way that all identified variants in the requirements are contained due to the flexibility of variability. Reusing existing reference process or changing existing variants causes new variants to be added [38].
Run-time variability copes with the variations in run-time process. The main job of run-time variability is managing redesigns in the process, for example, modifying a single activity or removing a whole variant. The reason of changes possibly is requirements modification or response of an incorrect status [38].
2.7 Software Product Line Feature Model
Feature modeling is one of the most popular domain analysis techniques, which is used to create a comprehensible, hierarchical model that capture commonalities and variabilities in a domain with the aim of developing highly reusable core assets for a product line. Features are always described as key characteristics of a product. In software product line feature model, features are an abstract concept that is only used to represent commonalities and variabilities [39,40]. Beuche and Dalgarno defined the term ‘feature’ as below: ‘A feature in this sense is a characteristic of a system relevant for some stakeholder. Depending on the interest of the stakeholders a feature can be for the example a requirement, a technical function or function group or a non-functional (quality) characteristic.’ [40]
Generally, practitioners and researchers use dendrogram to describe a feature model. It is appropriate because feature models have a tree structure and the nodes and leaves are features. There are four types of features in a feature model [41]:
Mandatory: If a child feature is mandatory feature, it must be contained in the product. (‘n from n’)
Optional: If a child feature is optional feature, it can be contained (or not) in the product. (‘m from n, 0<=m<=n’)
Alternative: Exactly one feature must be chose from a group of alternative feature. If an alternative feature is chosen, its siblings cannot be contained. (‘1 from n’)
Or: At least one feature must be chose from a group of or feature. If an or feature is chosen, its siblings can be contained (or not). (‘m from n, m>1’)
Different types of feature can be labeled with notations, as figure 2.9 shown below. According to figure 2.9, we know an E-Shop must have a feature called Catalogue, a feature called Payment and a feature called Security. It can have a feature called Search additional. Feature Security can have a feature called High or another feature called Standard, but it must not have them both. On the other hand, feature Payment can have a feature called Bank transfer or another feature called Credit card or both of them.
Figure 2.9 An example of feature model [42]
Sometimes the features have more complex relationships or constraints between each other. For example, feature A ‘requires’ feature B or feature C ‘conflicts’ feature D. In this scenario, Object Constraint Language (OCL) is helpful. The definition of OCL is given as: ‘The Object Constraint Language is a precise textual language to complement graphical languages in modeling object-oriented systems. It allows constraints on the model to be expressed, that can not be expressed using standard diagrammatic notations.’ [43]
2.8 Software Product Line Functional Model
Functional model is a structured representation that demonstrates the product functionalities and the logical interconnections between those functionalities. The benefits of function modeling are [44]:
visually creating a model that reveals how the related system functionalities work
classifying the possible interfaces of a system
increasing the adaptability of a product line, pay more attention to execution environment
helping developers to understand the system and the customer’s expectation, helping the customer to understand the product developers will develop after
if working in a team, it shares information and keeps the collaboration closer
We can use three tools to construct a functional model. These three tools are Function Flow Diagram (FFD), Flow Dictionary and Function Specification.
The FFD is used to present the network of the system. It decomposes the system to component functions and adds ‘flow’ between these functions to show the internal dependencies. For example, as shown in figure 2.10, the function converts the input flow to output flow. The terminator is something can be a source or destination like another function or object. Flow is an input or output unit such as data or control. [44]
Figure 2.11 Function Flow Diagram [44]
The Flow Dictionary records every flow found in the function model. It is a collection of descriptions which affirm the component elements of each flow and the relationships amongst them. The Function Specification clarifies the functions of components by define the conversion between input flow and output flow. To construct a functional model, these three tools should be used together, like what figure 2.12 indicated.
Figure2.12 Using the three tools together
2.9 Software Product Line Reference Architecture
When a software product is planned to be developed, It is important to create a structure of the software first. This structure consists of components, properties of components and and relations between theses components. It helps the developers to understand what the software contains and what to use the software for. It helps the stakeholders to know if the requirements are satisfied and communicate with each other. We call this structure software architecture. A well-organized software architecture will make the following development more smooth with fewer costs and errors.
Reference architecture is a special architecture. It more like a blueprint, providing a generic view of a system. In software product line engineering, a reference architecture, which consists of a list of features and functions, is used to create concrete product by offering assets. Architects can add new products or new details for an existing product anytime in a well-defined software product line reference architecture without causing a chain reaction to other products.
Software product line reference architecture is a group of software product architecture. Each software product architecture should includes both feature model and functional model. Because models are abstract, sometimes functional model is hard to relate closely to feature model. In addition, the reference architecture is difficult to cover all the variant points and merge commonalities if the product line includes a number of product. Linden, Schmid and Rommes provided three methods to collect variation points, which are adaption, replacement and extension (see figure 2.13) [17]. Despite these are useful, but the problems of creating software product line reference architecture are not solved.
Figure 2.13 Three methods for collecting variant points in an architecture
2.10 Current Approaches of Software Product Line Engineering
Software product line engineering has been researched since 1990s. Some approaches is feature-oriented, some is aspect-oriented, some is model-driven. This section will introduce some typical approaches.
2.10.1 FAST
Family-oriented abstraction, specification and translation (FAST) [26] is a development process that uses family-oriented method to develop software products introduced by David M. Weiss. FAST separate a whole product line engineering process into two parts. The first part is domain engineering, which provides core assets. The second part is application engineering, which uses the core assets to produce different product [45].
According to Weiss, the key of FAST is ”nding the appropriate abstractions for the family, creating a language for describing them, and then developing the tools need to translate descriptions of family members into deliverable software and documentation.’ FAST process works on it. The purpose of FAST process is ‘to create processes and assets for rapidly creating different members of a program family’ [46].
Domain engineering and application engineering are subprocesses of FAST. Connected by feedback loops, they evolve the product family. The whole process is presented graphically:
Figure 2.14 FAST Process [46]
2.10.2 FODA
Feature-Oriented Domain Analysis (FODA) is a method for introducing a domain analysis. FODA defines not only products but also the process of domain analysis. The purpose of domain analysis is to discover the commonalities and variabilities. Domain engineering is ‘An encompassing process which includes domain analysis and the subsequent construction of components, methods, and tools that address the problems of system/subsystem development through the application of the domain analysis products’. [7]
There are three phases used to collect and demonstrate information on software system to share core assets in domain analysis process. These phases are represented below [7]:
Context analysis defines where is the domain for analysis.
Domain modeling creates a domain model with commonalities and variabilities, which is used to share core assets.
Architecture modeling builds an architecture of software system by using the feature model from the result of domain modeling phase.
Figure 2.15 shows the phases and products in domain analysis:
Figure 2.15 Phases and Products of Domain Analysis [7]
2.10.3 FORM
Feature-Oriented Reuse Method (FORM) is a software development method that focus on improving the reusability of architectures and components in order to develop software products using domain artifacts produced from domain engineering.
Analysis of commonality among products in specific domain is the first step in FORM process. A feature model must be created to achieve the step. After the analysis, the model will be used to create a reference architecture. Obviously, feature-orientation is the key in FORM process. Briefly, Kang list the importance and significance of the feature modeling as:
‘By standardizing the meanings of features and integrating them as a model, it is possible to define standard terms and ease communication problems.
The feature model can be used as a yardstick for evaluating commonalties and differences between applications.
The feature model characterizes a domain and it can be used to compare with other domains.
Construction of a feature model requires resolution of conflicting interpretations of the same feature, expediting the standardization process.
Commonalties manifested in the model indicate clearly where reuse opportunities are.
Complex interactions among features become visible.’ [9]
Figure 2.16 shows the whole process of FORM:
Figure 2.16 FORM Process
2.10.4 RSEB
Reuse-Driven Software Engineering Business (RSEB) is an improvement of FODA. It is a software development methodology based on use-case driven reuse process. Use cases, which convert to object models at the end, are descriptions of both architecture and reusable subsystem. The use cases can be traced from object models. RSEB has domain engineering and application engineering as well. But domain engineering of RSEB is a little different from traditional domain engineering. RSEB domain engineering has more steps [47].
RSEB domain engineering has seven steps:
Domain identification, which is used to confirm the extent of domain. Not every domain is suitable for the product line. In FODA, a context model is constructed in this step.
Analysis of domain. In this step, examples, requirements, trends and use cases are be selected and analysed. The purpose of analysis is to discover the commonalities and variabilities for reusable components and assets.
Identification, factoring and clustering of feature sets, which uses the result from step 2 to build a structured model for decision. In RSEB, this is where the a use case and analysis object model is created.
Development of architecture. In this step, an architecture finally is built using features, subsystems, variants, core mechanisms and some description of architecture.
Representation of usable commonality and variability, which identifies the generalized functions, modules, subsystems and relations among them.
Management of commonality and variability. Using notations and mechanisms to determine reusable product.
Implementation, certification, and packaging of reusable components. This is the most important step of RSEB domain engineering. [47]
Chapter 3 – Component-based Software Product Line Engineering
In this chapter, a new approach of software product line engineering (SPLE) will be introduced. This approach combines component-based development (CBD) and traditional software product line engineering approach. Some new tools will be used in the development using new approach.
3.1 Introduction of main approach
In order to achieve a software product line using component-based approach, the development process contains four steps:
Create a feature model. This feature model focus on feature sets. Commonality and variability of features should be easy to find in the model.
Create a functional model. This functional model demonstrates the functions of products.
Build a reference architecture through combining feature model and functional model. The reference architecture is a collection of product architectures. In principle, any product in the product line can be designed and produced based on the reference architecture.
Produce software product.
The functional model using component-based approach would have a hierarchical structure. The component of the functional model could be an object, an architecture unit or an encapsulated component. For example, X-MAN functional model using exogenous connectors and encapsulated computation and control as component. This approach not only brings stronger reusability to functional model but also improves the flexibility of reference architecture.
Because X-MAN functional model mentioned above is more efficient and well-organized than traditional functional model, traditional functional modeling can be replaced by X-MAN Functional modeling in SPLE. Figure 3.1 gives the new SPLE process.
Figure 3.1 X-MAN component-based approach for SPLE [48]
3.2 Introduction of tools
In this section, several feature modeling tools and functional modeling tools will be represented. The advantages and disadvantages of these tools will be discussed as well.
3.2.1 pure::variants
Pure::variants is a tool for variant management of product line. According to its documentation, "pure::variants provides a set of integrated tools to support each phase of the software product-line development process. pure::variants has also been designed as an open framework that integrates with other tools and types of data such as requirements management systems, object-oriented modeling tools, configuration management systems, bug tracking systems, code generators, compilers, UML or SDL descriptions, documentation, source code, etc." [11]. Figure 3.2 is a screenshot of pure::variants.
Figure 3.2 Screenshot of pure::variants
Pure::variants provides four types of features (mandatory, optional, alternative, or). It also provides a number of relationships between features (require, provide, influence, support, recommend, etc.). It is powerful and detailed. The disadvantages of pure::variants exists as well. It is too big and complex. User must takes much time to learn how to use it. And it does not detect the conflict between feature properties and relationships.
3.2.2 Feature Model Tool Lite
Feature Model Tool Lite (FMTL) is a home made application used to create a simple feature model. The innovation of FMTL is removing the types of feature. It describes feature model through object, cardinality like [minimum, maximum] and three relationships. The relationships are require, provide and conflict. For example, ‘a mandatory feature A’ can be describe as ‘a feature named A and its cardinality is [1,1]’, ‘a group of alternative features A,B,C,…’ can be describe as ‘feature A conflicts feature B conflicts feature C…’. Figure 3.3 shows the screenshot of FMTL.
Figure 3.3 Screenshot of Feature Model Tool Lite
FMTL is a web application developed by html5 and JavaScript. That means it can be used in any environment no matter what operation system is. It can detect the conflict between features that is pure::variants cannot do. But, unfortunately, it also has disadvantages. Although FMTL may be good at implementing a pure feature model, it is not good for variability management because the relations among features only depends on Object Constraint Language.
3.2.3 X-MAN Reference Architecture Tool
X-MAN Reference Architecture Tool (X-MAN RAT) is developed for creating component-based X-MAN architecture based on feature model and X-MAN functional model. Figure 3.4 displays the tool.
Figure 3.4 X-MAN Reference Architecture Tool [48]
3.3 New Tools in Future
As a feature modeling tool, pure::variants is too complex and cannot detect the conflicts. Feature Model Tool Lite is disadvantageous to variability management. Good news is that Component-based Software Development Research Group is developing a new feature modeling tool using XCore and Graphiti. X-MAN Reference Architecture Tool is quite good for component-based X-MAN architecture, but it still cannot build a reference architecture so far.
Chapter 4 – Progress of Research
So far, the research of software product line engineering goes well. I read a book, Software Product Line Engineering, written by Klaus Pohl, Frank van der Linden, et al. I also read dozens of articles about approaches of product line, domain engineering, variability management, etc. Now I understand the principle of domain engineering, variability management, feature modeling, functional modeling and so on. I also know several approaches of product line engineering. I developed a feature modeling tool by myself and I am helping some members of Component-based Software Development Research Group to develop the new feature model.
4.1 Additional Work
Although I acquired theoretical knowledge of software product line engineering, I have few experiences to develop a complete software product line. I will try different tools to build models and architectures in next stage of research. If I have enough time, I will try to improve existing tools like X-MAN RAT or even develop something new.
4.2 Expected Result
I expect to build a software product line with correct reference architecture so that I can use that produce different software products. I also hope I can finish the new feature tool and make progress on reference architecture tool development.
Chapter 5 – References
Ritzinger, Andr??: "Early Ford – models from the years 1903 – 1908"
Klaus Pohl: ‘Software Product Line Engineering’
Carnegie Mellon: ‘Software Product Lines’, from Software Engineering Institute Web Site
Charles W. Koushik: ‘Introduction to Software Product Lines’
Charles W. Krueger: ‘Introduction to the Emerging Practice of Software Product Line Development’
Sanjiv Purba: ‘Architectures for E-Business Systems: Building the Foundation for Tomorrow’s Success’, Chapter 23
Kang, K.C. and Cohen, S.G. and Hess, J.A. and Novak, W.E. and Peterson, A.S.: ‘Feature-oriented domain analysis (FODA) feasibility study’
FIPS Publication 183 released of IDEF0 December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST)
Kang, K.C. and Kim, S. and Lee, J. and Kim, K. and Kim, G.J. And Shin, E.: ‘FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures’
Rick Flores, Charles W. Krueger, Paul C. Clements: ‘Second-Generation Product Line Engineering: A Case Study at General Motors’
Pure::variants Variant Management Tool, Pure Systems, http://www.pure-systems.com/pure_variants.49.0.html
K.-K.Lau, P.Velasco Elizondo, and Z.Wang: ‘Exogenous connectors for software components’. In Proc. 8th Int. SIGSOFT Symp. on Component-based Software Engineering, LNCS 3489, pages 90-106, 2005.
‘Software Product Line’, Carnegie Mellon Software Engineering Institute Web Site, http://www.sei.cmu.edu/productlines/
‘The Model T Put the World on Wheels’, Ford Motor Company Web Site, http://corporate.ford.com/our-company/heritage/heritage-news-detail/672-model-t%20
Bosch, J. : Design & Use of Software Architectures, Addison-Wesley, Boston, 2000
Ricardo de Almeida Falbo,Giancarlo Guizzardi,Katia Cristina Duarte: ‘An ontological approach to domain engineering’
Linden, F., Schmid, K., Rommes, E.: ‘Software Product Lines in Action’, Springer, Berlin, 2007.
Christof Ebert: ‘Hands-On Experience Implementing a Product Line’
K Pohl, G B??ckle, F Van Der Linden: ‘Software product line engineering’, Springer, 2005
Linda Northrop: ‘Software Product Lines Essentials’, CMU/SEI.
‘A Framework for Software Product Line Practice, Version 5.0’, CMU/SEI Web Site, http://www.sei.cmu.edu/productlines/frame_report/PL.essential.act.htm
Patrick Heymans, Jean-Christophe Trigaux: ‘Software Product Line: State of the art’
SwapnilDeole, Marie Putri: ‘Nokia – Product Line Management Analysis’
Jan Bosch: ‘Software Product Lines: Organizational Alternatives’
Ivar Jacobson, Martin Griss, Patrik Jonsson: ‘Software reuse: architecture process and organization for business success’
David M. Weiss and Chi Tau Robert Lai: ‘Software product-line engineering: "a family-based software development process’
Institute of Electrical and Electronic Engineers. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). New York, NY: Institute of Electrical and Electronics Engineers, 1990.
Linda Westfall: ‘Software Requirements Engineering: What, Why, Who, When, and How’
Ian Sommerville: ‘Software Engineering’, 7th ed. Harlow, UK: Addison Wesley, 2006
Dorfman, M. & Thayer, R. H.: ‘Software Requirements Engineering’, Los Alamitos, CA: IEEE Computer Society Press, 1997.
Andreas Metzger, Klaus Pohl: ‘Variability Management in Software Product Line Engineering’
Edson Alves de Oliveira Junior, Itana M. S. Gimenes, Elisa Hatsue Moriya Huzita: ‘A Variability Management Process for Software Product Lines’
J. van Gurp, J. Bosch, M. Svahnberg: ‘On the notion of variability in software product lines’
M. Simons, D. Creps, C. Klingler, L. Levine, D. Allemang: ‘M. Simons, D. Creps, C. Klingler, L. Levine, D. Allemang’, version 2.0. Technical Report STARS-VC-A025/001/00, Lockheed Martin Tactical Defence Systems, 1996.
P. Sochos, I. Philippow, M. Riebish: ‘Feature-oriented development of software product lines: mapping feature models to the architecture’, Springer, LNCS 3263, 2004.
K. Czarnecki, S. Helsen, and U. Eisenecker: ‘Staged configuration through specialization and multilevel configuration of feature models’
M. Anastasopoulos, C. Gracek.: ‘Implementing product line variabilities’
Marco Aiello, Pavel Bulanov, Heerko Groefsema: ‘Requirements and Tools for Variability Management’
Kwanwoo Lee, Kyo C. Kang, and Jaejoon Lee: ‘Concepts and Guidelines of Feature Modeling for Product Line Software Engineering’
Danilo Beuche, Mark Dalgarno: ‘Software Product Line Engineering with Feature Models’
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, Carnegie-Mellon University Software Engineering Institute, November 1990.
E. Yourdon and L.L. Constantine: ‘Structured design: fundamentals of a discipline of computer program and systems design’. Yourdon Press, 1978.
Ali Hamie, John Howse and Stuart Kent: ‘Interpreting the Object constraint Language’
Stuart Burge: ‘The Systems Engineering Tool Box: Functional Modeling (FM) ‘
Maarit Harsu: ‘FAST product-line architecture process’
David M. Weiss: ‘Software Synthesis: The FAST Process’
Martin L. Griss, John Favaro, Massimo d’Alessandro: ‘Integrating Feature Modeling with the RSEB’
Mert Balci: ‘Component-based reference architecture tool for software product line engineering’