Academic
Publications
FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures

FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures,Annals of Software Engineering,Kyo Chul Kang,Sajoong Kim,Jaejoon Le

FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures   (Citations: 335)
BibTex | RIS | RefWorks Download
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 actual 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. 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. .
Journal: Annals of Software Engineering - ANSOFT , vol. 5, pp. 143-168, 1998
Cumulative Annual
View Publication
The following links allow you to view full publications. These links are maintained by other sources not affiliated with Microsoft Academic Search.
    • ...Kang et al, [19] introduced the notion of feature in the context of requirements engineering (feature oriented application development or FOAD), and Kang et al. [20] extended this notion to develop the domain architectures and components...

    Suresh Kamath. Capabilities and Features: Linking Business and Application Architectu...

    • ...During the project, we identified (and evaluated) the following different conventions: FODA [17], FORM [17], FODAcom [15], FeatuRSEB [18], GP [19], FOPLE [20], FORE [21], CONSUL [22], PLUSS [8], etc...
    • ...During the project, we identified (and evaluated) the following different conventions: FODA [17], FORM [17], FODAcom [15], FeatuRSEB [18], GP [19], FOPLE [20], FORE [21], CONSUL [22], PLUSS [8], etc...

    Georgi A. Markovet al. Requirements Engineering Process Improvement: An Industrial Case Study

    • ...1 1 1 FORM Feat. [24] PuLSE Gen. [3] KobrA Comp...

    Juan Manuel Moreno-Riveraet al. Evaluation of SPL Approaches for WebGIS Development: SIGTel, a Case St...

    • ...Such an approach is similar to other related work that promotes the (systematic) use of FMs [11], [13], [16], [17], [24]...
    • ...Several definitions of feature appear in the literature, ranging from "anything users or client programs might want to control about a concept" [7], "a prominent or distinctive user-visible aspect, quality or characteristic of a software system or systems" [16] to "an increment in product functionality" [5]...
    • ...1) Systematic Use of FMs: Several approaches promote the (systematic) use of FMs during SPL engineering [1], [13], [16], [17], [24]...
    • ...FORM promotes a systematic organization of features in four layers, represented as four FMs related by dependency relations [16]...

    Mathieu Acheret al. Modeling Variability from Requirements to Runtime

    • ...[9,16]) model different feature configurations through variation points and different semantics for composing and combining features based on predefined constraints...
    • ...There are several approaches that focus on the problem-level specification of variation through features, such as using domain-specific feature graphs [9] or decision models [1]...

    Borislava I. Simidchievaet al. Characterizing process variation: NIER track

Sort by: