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

  • Authors:

  • Kyo C. Kang;Sajoong Kim;Jaejoon Lee;Kijoo Kim;Euiseob Shin;Moonhang Huh

  • Affiliations:

  • Department of Computer Science and Engineering, Pohang University of Science and Technology (POSTECH), San 31 Pohang, Kyoungbuk 790‐784, Korea E-mail: {kck,sjkim,kijoo}@po ...;Department of Computer Science and Engineering, Pohang University of Science and Technology (POSTECH), San 31 Pohang, Kyoungbuk 790‐784, Korea E-mail: {kck,sjkim,kijoo}@po ...;Information Systems Division, LG Information & Communications Ltd., R&D Complex, 533, Hogye‐dong, Dongan‐gu, Anyang‐shi, Kyounggi‐do 430‐080, Korea E-mail: gib&c ...;Department of Computer Science and Engineering, Pohang University of Science and Technology (POSTECH), San 31 Pohang, Kyoungbuk 790‐784, Korea E-mail: {kck,sjkim,kijoo}@po ...;Multimedia Laboratory, Korea Telecom Research & Development Group, 17 Woomyung‐dong, Seocho‐gu, Seoul 137‐790, Korea E-mail: {esshin,moonh}@rcunix.kotel.co.kr;Multimedia Laboratory, Korea Telecom Research & Development Group, 17 Woomyung‐dong, Seocho‐gu, Seoul 137‐790, Korea E-mail: {esshin,moonh}@rcunix.kotel.co.kr

  • Venue:
  • Annals of Software Engineering
  • Year:
  • 1998

Quantified Score

Hi-index 0.00

Visualization

Abstract

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.