Title: FORM: Feature-Oriented Reuse Method
1FORM Feature-Oriented Reuse Method
2Domain 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
3Feature-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)
4Feature 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
5Feature Model
6Importance 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 -gt Reusable Artifacts
- Feature models are used to support engineering of
reusable domain artifacts and development of
applications using these domain artifacts
7FORM
- 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 -
8FORM 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
9FORM 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
10FORM Feature Model of the EBBS (Electronic
Bulletin Board System) Domain
11FORM 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/special
ization 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
12Comments 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
13Validation 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 applications 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
14FORM 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
15Subsystem 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
16A Subsystem Model For the EBBS Domain
17Process 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
18A 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
19Module 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
20A 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
21Parameterization 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
22Architecture Modeling Summary
23FORM 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)
24Feature 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
25Architecture 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
26FORM Application Development
27Conclusion
- 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
28References
- 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