Jaejoon Lee

FORM: A feature-oriented reuse method with domain-specific reference architectures

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse. By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, i.e., software architectures and components needed for implementing applications in the class. FORM (Feature-;Oriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering. FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques. The model constructed during the analysis is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications. Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during application development. Architectures are defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features. The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment. Each subsystem is further decomposed into processes considering the operating environment features. Modules are defined based on the features on domain technology and implementation techniques. These architecture models that represent an architecture at different levels of abstraction are derived from the feature hierarchy captured in the feature model. Modules serve as basis for creating reusable components, and their specification defines how they are integrated into the application (e.g., as-;is integration of pre-;coded component, instantiation of parameterized templates, and filling-;in skeletal codes). Our experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make up for a common domain language and the main communication medium among application users and developers. Thus, the feature model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable components.

Feature-oriented product line engineering

The feature-oriented reuse method analyzes and models a product lines commonalities and differences in terms of product features and uses the analysis results to develop architectures and components. The article illustrates, with a home integration system example, how FORM brings efficiency into product line development.

Concepts and Guidelines of Feature Modeling for Product Line Software Engineering

Product line software engineering (PLSE) is an emerging software engineering paradigm, which guides organizations toward the development of products from core assets rather than the development of products one by one from scratch. In order to develop highly reusable core assets, PLSE must have the ability to exploit commonality and manage variability among products from a domain perspective. Feature modeling is one of the most popular domain analysis techniques, which analyzes commonality and variability in a domain to develop highly reusable core assets for a product line. Various attempts have been made to extend and apply it to the development of software product lines. However, feature modeling can be difficult and time-consuming without a precise understanding of the goals of feature modeling and the aid of practical guidelines. In this paper, we clarify the concept of features and the goals of feature modeling, and provide practical guidelines for successful product line software engineering. The authors have extensively used feature modeling in several industrial product line projects and the guidelines described in this paper are based on these experiences.

Software Product Lines: Going Beyond

Why should wait for some days to get or receive the software product lines going beyond 14th international conference splc 2010 jeju island south k book that you order? Why should you take it if you can get the faster one? You can find the same book that you order right here. This is it the book that you can receive directly after purchasing. This software product lines going beyond 14th international conference splc 2010 jeju island south k is well known book in the world, of course many people will try to own it. Why dont you become the first? Still confused with the way?

Feature-oriented re-engineering of legacy systems into product line assets: a case study

Home service robots have a wide range of potential applications, such as home security, patient caring, cleaning, etc. The services provided by the robots in each application area are being defined as markets are formed and, therefore, they change constantly. Thus, robot applications need to evolve both quickly and flexibly adopting frequently changing requirements. This makes software product line framework ideal for the domain of home service robots. Unfortunately, however, robot manufacturers often focus on developing technical components (e.g., vision recognizer and speech processor) and then attempt to develop robots by integrating these components in an ad-hoc way. This practice produces robot applications that are hard to re-use and evolve when requirements change. We believe that re-engineering legacy robot applications into product line assets can significantly enhance reusability and evolvability. n nIn this paper, we present our experience of re-engineering legacy home service robot applications into product line assets through feature modeling and analysis. First, through reverse engineering, we recovered architectures and components of the legacy applications. Second, based on the recovered information and domain knowledge, we reconstructed a feature model for the legacy applications. Anticipating changes in business opportunities or technologies, we restructured and refined the feature model to produce a feature model for the product line. Finally, based on the refined feature model and engineering principles we adopted for asset development, we designed a new architecture and components for robot applications.

Feature-oriented engineering of PBX software for adaptability and reusability

Incorporating a high level of adaptability and reusability into software is one challenge that all software engineers face. PBX (Private Branch Exchange) is one such system that requires a high level of adaptability and reusability because of rapidly expanding service features, ever changing communication technology, continuously evolving standards and diverse communication laws and standards in different countries. The software engineering community has made various efforts to address the problem of enhancing software adaptability and reusability. As a result, many programming concepts, such as information hiding, encapsulation, object orientation, abstract data type and modularization, have been developed. Although adequate application of these principles requires the domain or program family perspective, most methods, so far, have been oriented toward developing a single application. FORM (Feature‐Oriented Reuse Method), the domain‐based software reuse method applied in this paper, concentrates on analyzing and modeling commonalities and differences in applications of a given domain and using the analysis results to develop domain‐oriented architectures and software components. The model that captures commonalities and differences is called the ‘feature model’ and it is used for both the engineering of reusable domain artifacts and the development of actual application software with reusable artifacts. We found that FORM facilitates analysis of variability, as well as commonality, of software before the start of engineering and implementation. With this understanding, adaptability and reusability can be built into software. Also, feature modeling has been found to be an effective method for identifying objects. Copyright

Using a Marketing and Product Plan as a Key Driver for Product Line Asset Development

The product line engineering paradigm has emerged recently to address the need to minimize the development cost and the time to market in this highly competitive global market. Product line development consists of product line asset development and product development using the assets. Product line requirements are essential inputs to product line asset development. These inputs, although critical, are not sufficient to develop product line assets. A marketing and product plan, which includes plans on what features are to be packaged in products, how these features will be delivered to customers (e.g., feature binding time), and how the products will evolve in the future, also drives product line asset development; thus this paper explores design issues from the marketing perspective and presents key design drivers that are tightly coupled with the marketing strategy. An elevator control software example is used to illustrate how product line asset development is related to marketing and product plans.

Feature Binding Analysis for Product Line Component Development

Feature analysis, which provides commonality and variability information of a product line, is essential for product line asset development. Moreover, feature binding information (i.e., when and how product features are included to products and delivered to customers) also drives product line component design. Feature binding can be examined from three perspectives: what features are bound (feature binding unit), when features are bound (feature binding time), and how features are bound (feature binding techniques), and this information must be made available to component design so that composition of components for feature binding becomes feasible. In this paper, we introduce an approach to analyzing feature binding from the three perspectives (i.e., what, when, and how) and illustrate how the analysis results can be used for component development of a product line.

A Feature-Based Approach to Product Line Production Planning

A production plan, which describes how core assets are used to develop products, has an important role in product line engineering as a communications medium between core asset developers and product developers. Recently, there have been efforts to address issues related to production planning, most of which focus on the process and business/management aspects of production planning; not much emphasis is given to technical issues such as deciding which features will be made as core assets and what their granularity will be. In this paper, we introduce a feature-based approach to product line production planning and illustrate how our approach addresses these technical issues. In our approach, a feature model and feature-binding information are used as primary input to production plan development. A product line production plan created using our approach could be customized easily to a product-specific production plan, because when we developed the approach, we considered units of product configurations as well as their integration techniques.

Re-engineering software architecture of home service robots: a case study

With the advances of robotics, computer science, and other related areas, home service robots attract much attention from both academia and industry. Home service robots present interesting technical challenges to the community in that they have a wide range of potential applications, such as home security, patient caring, cleaning, etc., and that the services provided by the robots in each application area are being defined as markets are formed and, therefore, they change constantly. Without architectural considerations to address these challenges, robot manufacturers often focus on developing technical components (e.g., vision recognizer, speech processor, and actuator) and then attempt to develop service robots by integrating these components. When prototypes are developed for a new application, or when services are added, modified, or removed from existing robots, unexpected, undesirable, and often dangerous side-effects, which are known as feature interaction problem, happen frequently. Reengineering of such robots can make a serious impact in delivery time and development cost. In this paper, we present our experience of re-engineering a prototype of a home service robot developed by Samsung Advanced Institute of Technology. First, we designed a modular and hierarchical software architecture that makes interaction among the components visible. With the visibility of interactions, we could assign functional responsibilities to each component clearly. Then, we re-engineered existing codes to conform to the new architecture using a reactive language Esterel. As a result, we could detect and solve feature interaction problems and alleviate the difficulty of adding or updating components.