FORM: Feature-Oriented Reuse Method

Kaan Kaynar

Domain Analysis and Engineering

Domain: a family of related systems Domain analysis: examining a family of related systems and extracting the commonalities and differences of these systems Domain engineering: using analysis results to create a set of reference models, i.e., reusable software architectures and componentsApplication engineering: creating applications using these reusable artifacts

Feature-Oriented Domain Modeling Methods

Captures the commonalities and differences of systems in a domain in terms of features

The use of features is motivated by the fact that customers and developers speak about product characteristics in terms of features the product has or delivers

Features are distinctively identifiable functional abstractions of a system (that is relevant to any end-user or developer of the system)

Feature Model

The model constructed during the analysis is called the "feature model” which represents relationships between features as an AND/OR graph

AND branches imply the mandatory selection of all the children of the parent feature, OR branches imply the selection of exactly one of the children -- whenever the parent feature is selected

FODA (Feature-Oriented Domain Analysis) can be termed as the mother of all feature-oriented modeling methods

Feature Model

Importance of Feature Models

Standardization The feature model standardizes the meanings of features, it is possible to define standard domain terminology and ease communication problemsFeature Model = Theory of a Domain The feature model can be used for evaluating commonalities and differences between domains, and surely, applications in a domainCommonalities -> Reusable ArtifactsFeature models are used to support engineering of reusable domain artifacts and development of applications using these domain artifacts

FORM

FORM extends FODA, however it covers both domain and application engineeringThere are three phases in FORM domain engineering: context analysis, domain modeling, and architecture modeling During the context analysis, the scope and intended use of the domain are identifiedDomain modeling defines the “decision space” (the feature model) consisting of user selectable features Architectural modeling defines the “artifact space” which consists of the reusable artifacts and their hierarchical decompositions

FORM Domain Modeling

FORM domain modeling identifies the features in four different layers: service, operating environment, domain technology, and implementation technique layer featuresA “service” or a “capability” feature represents a distinct service or a functionality that an application may have. Service features can be found in user manuals They are divided into “functional” and “non-functional” ones. Non functional features represent intended use, or expected performanceAn “operating environment” feature represents attributes of environment in which an application is operated. They can be found in requirements and design documents

FORM Domain Modeling (cont.)

“Domain technology” and “implementation technique” features represent implementation details at lower levels

The difference between these two is that a “domain technology” feature is more related to a given domain (e.g., navigation methods in the aviation domain), while “implementation technique” feature is more generic

Domain technology features can be found in requirements and design documents, and implementation technique features can be found in design documents and program sources

FORM Feature Model of the EBBS (Electronic Bulletin Board System) Domain

Bit Eþlem Resmi

FORM Feature Model

Features can be “mandatory”, “optional” (denoted with a circle), or “alternative” (denoted with an arc) Three types of relationships are represented in this model: “composed-of”, “generalization/specialization” and “implemented-by”Composition rules can support the feature model with mutual dependency and mutual exclusion relationshipsIssues and decisions can also support the feature model with trade-offs and selection criteria for feature selection

Comments on the Feature Model

A feature model with AND-nodes at an upper level and OR-nodes at a lower level indicates a high level of reusability. There are different ways of implementing certain components below in the hierarchy

OR-nodes at the upper level indicates that applications in the domain do not have much commonalities in terms of services provided by them

Validation of the Feature Model

The feature model should be validated before use

Validation is performed by instantiating the model for each application considered in the domain analysis and checking if the instantiated model represents the application’s requirements

An instantiation of a feature model is a selection of a set of capability, operating environment, domain technology and implementation technique features from the model

FORM Architecture Modeling

Reference architectures and reusable components instantiatable during application development are definedReference architectures are defined in three levels of abstraction: subsystem model, process model and module model

“Decision Space” “Artifact Space”They are defined according to the feature model following the four-level hierarchy and considering the “functional” and “non-functional” featuresThe functional features are used to identify components, while non functional features are used to partition the components – at every abstraction level

Subsystem Model

The “subsystem model” defines the overall system structure by packaging service features into subsystems

Features having a strong data or control dependency are allocated to a subsystem to minimize coupling

A feature that requires a time-critical function may be allocated to its own subsystem (a GUI service)

Data flow between subsystems (also processes) can be by a non-blocking communication via a message queue, or a blocking communication via a message/reply mechanism

A Subsystem Model For the EBBS Domain

Process Model

Each subsystem is decomposed into a set of concurrent processes considering the operating environment features

The process model represents the dynamic behavior of each subsystem

The decomposition/refinement process is guided by loose coupling and cohesion

Operational features of resident and transient nature should be separated

Operational features that are time-critical or have high priority may be allocated to separate processes

A Process Model For the Board Subsystem of the EBBS Domain

Choice of two operating environment features; “Database” and “Fault Tolerance” have resulted in a separate “DB Client Daemon” process

Module Model

Modules are defined based on the features on domain technology and implementation techniques

A module only contains an abstract specification which defines how it is integrated into an application

Multiple code level reusable components can be created that match the specification of the module

A module may be specified in different ways to enable different reuse techniques: selecting a precoded component, instantiating a parameterized component by supplying the parameter values, or completing a skeletal code component

A Module Model of the Board Client Process of the EBBS Domain

Choice of domain

technology feature

“Textual display”

is implemented by

both providing

“VT series”

terminal handling

module, integratable

into the application

as a template, and

“TTY” terminal

handling module

Parameterization in Architecture Modeling

There can exist as many reference architecture models as feature selections

Alternative features (OR-nodes) often indicate the need for parameterization of an architecture or a component

Hence, features are used as parameters of an architecture or a component template

In FORM, software reuse is advanced from the traditional module level to the design level through these architecture templates

Architecture Modeling: Summary

FORM Application Engineering

Concerns finding a correct reference architecture through feature selection and then putting in reusable software components

Feature SelectionUsers are concerned about services or functions provided by the system (service features)System analysts and designers are concerned about operating environment conditions and domain technologiesDevelopers are concerned about implementation techniquesApplications are built by reconciling these concerns that results in a selected set of features (instantiation of a feature model)

Feature SelectionStepwise Refinement

An effective method of finding such a feature set is by following the four-level feature hierarchy: first considering capabilities, then operating environments, and finally domain technologies and implementation techniquesWhile finding the features, there may be a case when a user is not allowed to select a feature because of the dependencies among the features In such a case, the developer should analyze the path of feature selection and either negotiate with the user to change the requirements, or try to find an alternative feature set that will satisfy the requirementsAt the end, the developer should verify the completeness and consistency of the selected features through the use of “composition rules” and “issues and decisions”

Architecture Selection and Components Integration

After the feature selection process, a corresponding reference architecture model is identified in the artifact space Once a reference architecture is identified, reusable components are found by using the specifications and methods defined in the modules Components are instantiated, and integrated in a bottom-up fashion completing the application development based on the integration rules defined in the modules FORM defines various types of “connectors” (e.g. socket, LPC, RPC, CORBA) for different architectural models. This minimizes problems related to the integration of reusable components

FORM Application Development

Conclusion

“Seperation of concerns” provides high adaptability and reusability of architectures and components to/by applications While at the module model level matching reusable components can be searched, at the subsystem and process levels these components can be viewed in the context of a larger architecture“Seperation of concerns” also provides ease of modification of architectures and componentsIn addition, the relations among different types of features can be analyzed and problems can be identified early in the development

References

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

Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Gerard Jounghyun Kim, Euiseob Shin

Representing Feature Models of Software Product Families Using a Configuration Ontology

Timo Asikainen, Tomi Männistö, Timo Soininen

Feature-Oriented Product Line Engineering

Kyo C. Kang, Jaejoon Lee, Patrick Donohoe