Back Room Front Room 2

196 ENTERPRISE INFORMATION SYSTEMS VI
2.3 Proposed Model-based Software
Engineering Method
In (Raabe, 2003), we proposed solution domain
analysis as an additional step during the software
process (as shown in Fig. 1). Introducing this
additional step will produce a solution domain
model and will allow us to use formalized results of
problem domain analysis and solution domain
analysis as a basis for deriving the description of
transformation from the analysis model to the
implementation model.
3 DOMAIN ANALYSIS
Domain engineering (SEI, 2002) encompasses
domain analysis, domain design, and domain
implementation. Domain analysis contains the
following activities:
• domain scoping, where relevant domain with
its sub-domains will be selected and the
main area of focus will be defined, and
• domain modeling, where relevant domain
information is collected and integrated into a
coherent domain model.
Domain model defines the scope (i.e. boundary
conditions) of the domain, elements or concepts that
constitute the domain (i.e. domain knowledge),
generic and specific features of elements and
configurations, functionality and behavior.
According to the different domain engineering
approaches, there are several different domain
analysis methods (Czarnecki and Eisenecker, 2000).
3.1 Feature-Oriented DomaiAnalysis
Feature modeling, also known as feature analysis, is
the activity of modeling the common and the
variable properties of concepts and their
interdependencies.
Feature-oriented domain analysis methods
describe the characteristics of a problem and the
required characteristics of a solution independently
of their structure.
Examples of feature-oriented domain analysis
methods are:
• Feature-Oriented Domain Analysis (FODA)
from SEI (Kang et al., 1990), which became
a part of their MBSE framework (SEI);
• Feature-Oriented Reuse Method (FORM)
developed by K. Kang (Kang, 1998);
• Domain Engineering Method for Reusable
Algorithmic Libraries (DEMRAL) by
Czarnecki and Eisenecker (Czarnecki and
Eisenecker, 2000).
Feature model consists of the following
elements:
• concepts – any elements and structures of the
domain of interest and
• features – qualitative properties of the
concepts.
A feature model represents feature types and
definitions, hierarchical decomposition of features,
composition rules (i.e. dependencies between
concepts) and rationale for features. It consists of a
feature diagram and additional information.
Feature diagram is a tree-like diagram, where the
root node represents a concept and other nodes
represent features of this concept and sub-features of
features. An example of a feature diagram is shown
in Fig. 2.
From the composition point of view, the
following feature types are most commonly used in
feature models:
• mandatory features (e.g. f1, f2, f5, f6, f7, f8, f9),
• optional features (e.g. f3, f4),
• alternative features (e.g. f5, f6), and
• or-features (e.g. f7, f8, f9).
Composition rules between features are
constraints for composing features for instances of
concepts (e.g. “requires”, “excludes”).
f 3
f 1
f 4
f 7
C
Figure 2: Example of a feature diagram
From the domain point of view, it is possible to
describe different feature classes.
FODA (Kang et al., 1990) distinguishes between
context features (non-functional characteristics of
application), operational features (application
functions), and representation features (interface
functions).
FORM (Kang, 1998) distinguishes between
capability features (further divided into functional
and non-functional features), operating environment
features, domain technology features, and
implementation technique features.
DEMRAL (Czarnecki and Eisenecker, 2000)
distinguishes between the following feature classes:
f 5
f 8
f 2
f 9
f 6