FORM - A FEATURE-ORIENTED REUSE METHOD WITH DOMAIN-SPECIFIC REFERENCEARCHITECTURES

Citation
Kc. Kang et al., FORM - A FEATURE-ORIENTED REUSE METHOD WITH DOMAIN-SPECIFIC REFERENCEARCHITECTURES, ANNALS OF SOFTWARE ENGINEERING, 5, 1998, pp. 143-168
Citations number
27
Categorie Soggetti
Computer Science Software Graphycs Programming","Computer Science Software Graphycs Programming
ISSN journal
10227091
Volume
5
Year of publication
1998
Pages
143 - 168
Database
ISI
SICI code
1022-7091(1998)5:<143:F-AFRM>2.0.ZU;2-C
Abstract
Systematic discovery and exploitation of commonality across related so ftware systems is a fundamental technical requirement for achieving su ccessful software reuse. By examining a class/family of related system s and the commonality underlying those systems, it is possible to obta in a set of reference models, i.e., software architectures and compone nts needed for implementing applications in the class. FORM (Feature-O riented Reuse Method) supports development of such reusable architectu res 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 commonal ity among applications in a particular domain in terms of services, op erating environments, domain technologies, and implementation techniqu es. 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 feature s selectable for different applications. Then, this model is used to d efine parameterized reference architectures and appropriate reusable c omponents 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 f urther decomposed into processes considering the operating environment features. Modules are defined based on the features on domain technol ogy and implementation techniques. These architecture models that repr esent an architecture at different levels of abstraction are derived f rom the feature hierarchy captured in the feature model. Modules serve as basis for creating reusable components, and their specification de fines how they are integrated into the application (e.g., as-is integr ation 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) do mains, ''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 develo pment, and is a good starting point for identifying candidate reusable components.