FORM: Feature-Oriented Reuse Method

1
FORM Feature-Oriented Reuse Method

• Kaan Kaynar

2
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

3
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)

4
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

5
Feature Model
6
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 -gt Reusable Artifacts
• Feature models are used to support engineering of
  reusable domain artifacts and development of
  applications using these domain artifacts

7
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

8
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

9
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

10
FORM Feature Model of the EBBS (Electronic
Bulletin Board System) Domain
11
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/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

12
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

13
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 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

14
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

15
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

16
A Subsystem Model For the EBBS Domain
17
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

18
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

19
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

20
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

21
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

22
Architecture Modeling Summary
23
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)

24
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

25
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

26
FORM Application Development
27
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

28
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