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 components Application 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 problems Feature Model = Theory of a Domain The feature model can be used for evaluating commonalities and differences between domains, and surely, applications in a domain Commonalities -> Reusable Artifacts Feature 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 engineering There 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 identified Domain 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 features A “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 performance An “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

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 relationships Issues 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 defined Reference 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” features The 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 Selection Users are concerned about services or functions provided by the system (service features) System analysts and designers are concerned about operating environment conditions and domain technologies Developers are concerned about implementation techniques Applications are built by reconciling these concerns that results in a selected set of features (instantiation of a feature model)

Feature Selection Stepwise 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 techniques While 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 requirements At 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 components In 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