A Support Tool for Domain Analysis
Liana Barachisio Lisboa
RiSE - Reuse In Software Engineering
Bahia - Brazil
Vinicius Cardoso Garcia
Silvio Romero de Lemos Meira
RiSE and Federal University of Pernambuco
Eduardo Santana de Almeida
RiSE and Federal University of Bahia
Bahia - Brazil
Abstract—Nowadays, companies need to improve their com-
petitiveness. Thus, they seek systematic ways of adopting
software reuse, and domain analysis is one possibility to reach
it. However, it involves the management and analysis of a large
set of interrelated information from several systems. Hence,
due to its complexity, a support tool is necessary. This paper,
presents a tool called ToolDAy, which aims at making the
process semi-automatic and at aiding the domain analyst to
achieve systematic reuse in an effective way. In addition, its
evaluations are also described.
Keywords-Domain Analysis Tool, ToolDAy, Evaluation
Nowadays, companies are seeking for ways to improve
their competitiveness, which involves less time-to-market
and high quality for products. The adoption of software reuse
is an option to obtain these beneﬁts. Although the beneﬁts
of software reuse are promising, it is a complex task to put
it into practice. A way to maximize these possible beneﬁts
is through a systematic reuse approach, which is domain
focused, based on a repeatable process, and concerned with
reuse of higher level life cycle artifacts . One of the
ways to accomplish this is through a domain analysis (DA)
process, which is the process of identifying common and
variable characteristics of systems in a speciﬁc domain.
The DA process is composed of some interdependent
activities that involve the management of complex and
interrelated information from various sources. Due to this,
the use of human expertise in industrial projects without
automation can contribute to risks in a project.
The development of ToolDAy was based on a system-
atic review of DA tools that analyzed how existing tools
supported the DA process . In this review, the authors
analyzed nineteen relevant tools to extract the results.
From the results, it was identiﬁed that tools usually come
from the necessity of supporting a speciﬁc process instead
of a generic one. However, this may force companies to
modify or adapt established development processes, which
can lead to a higher learning curve and a bigger impact on
the company development life cycle .
Another outcome was the identiﬁcation of a set of func-
tionalities that any tool should have. They were extracted
from the selected tools and grouped into phases, which were:
(i) Planning, analyze systems to see what is valid or not
FUNCTIONALITIES GROUPED BY PHASE WITH THEIR PRIORITIES
Pre Analysis Documentation Low
Domain Matrix Essential
Evaluation Functions Low
Scope Deﬁnition Important
Domain Representation Essential
Mandatory Features Essential
Composition Rules Essential
Feature Group Identiﬁcation Low
Relationship Types Low
Feature Atributes Low
Domain Documentation Essential
Feature Documentation Important
Requirements Management Important
Relationship between Features and Requirements Low
Consistency Check Essential
Product Derivation Important
Product Documentation Important
to be included in the domain scope; (ii) Modeling, model
the deﬁned domain in a visual way; and (iii) Validation,
document and validate the generated artifacts.
Furthermore, functionalities for the product derivation
were also identiﬁed in the majority of tools. Finally, a total
of twenty functionalities were recognized, which are shown
in Table I with their priorities. With these analyses, the
reviewers identiﬁed that there is not a tool that focus on
all phases, and the majority of them offer support, mainly,
to the modeling phase.
This tool development also came from industrial needs
that were experienced along ﬁve years of projects involving
software reuse at C.E.S.A.R1, a Brazilian Innovation Insti-
tute with CMMI level 3.
This paper presents ToolDAy, which goal is to support the
DA process, making it semi-automatic and aiding the analyst
to achieve systematic reuse in an effective way. This work
1Recife Center for Advanced Studies and Systems - http://www.cesar.
extends a previous one , in which the main functionalities
of the tool (Table I) were described. This paper makes two
contributions, (i) describing the second iteration of ToolDAy
and (ii) reporting two evaluations.
Due to lack of space, several artifacts are just mentioned
herein, to see the artifacts and some screen shots go to http:
The DA process starts with the planning phase. ToolDAy
provides a set of documentation ﬁelds for pre-analysis doc-
umentation that aids in the identiﬁcation of what character-
istics should be in the domain. The documentation includes:
identifying the stakeholders; objectives and constraint deﬁ-
nition; market analysis and data collection.
Then, the domain scope can be deﬁned through the
product map (domain matrix in Table I) that relates and
compares characteristics of domain applications, extracted
from pre-analysis documentation, to identify which ones
should be part of the domain through some metrics, called
evaluation functions. Their results, which can be mandatory,
variable or out of the scope, inﬂuence the domain scope.
In the modeling phase, ToolDAy performs the domain
representation with a feature model, in which the features
are diagrams and their types are relationships (which can be
alternative, or, optional and mandatory, plus the composition
rules that can be implication and exclusion).
Also regarding the relationships between features, they
can be represented in the model with different line formats.
The types are composition, used if there is a whole-part
relationship; generalization, when features are generalization
of sub-features; and implementation, when a feature imple-
ments the other feature. There is also the default relationship
that has no type.
Besides, features can be grouped according to the infor-
mation they represent. The groups are identiﬁed through
different colors in the feature border. They can be: capabil-
ity, characterizes a distinct service or functionality a product
may have; operating environment, represents an environment
attribute in which the product is used; domain technology,
corresponds to a domain speciﬁc implementation; and im-
plementation technique, implementation details that can be
reused cross domains.
ToolDAy also implements the inclusion of attributes for
the features. They synthesize the representation of a large
number of possible variations improving the understandabil-
ity of the feature model.
For the validation phase, ToolDAy provides a large
set of documentation. Apart from the domain and features
documentation , ToolDAy permits the description of re-
quirements and use cases, which are optional artifacts in
The requirement documentation includes priority, type
(functional or non-functional) and description, while the use
case includes pre and post conditions and the execution
ﬂows: main, alternative and exception.
After specifying the requirements, use cases and features,
it is possible to map the traceability among them. This fa-
cilitates the identiﬁcation of the impact of one modiﬁcation.
This traceability is done in a visual model with different
diagrams shapes for each artifact.
The consistency checker veriﬁes if the relationships be-
tween features are correct. ToolDAy’s consistency rules are
divided in three categories: redundancy, the same semantic
information is represented in more than one way. Anomalies,
some features conﬁgurations are lost and the domain cannot
be completely conﬁgurable. And, inconsistency, some rep-
resentation contradicts with other information in the model.
Each category has a set of veriﬁcations .
Moreover, ToolDAy also supports the inclusion of a dic-
tionary, which purpose is to clarify the terms of the domain.
Furthermore, there is no advantage in proving a large set
of documentation, if they were only available within the
tool environment. Thus, to provide their visualization in
other environments, ToolDAy permits the creation of several
reports in different formats (PDF, Excel or Images).
The product derivation with ToolDAy is done through
the selection of the domain features. This selection occurs
in a tree view representing the domain hierarchy. There
is also a consistency checker for the product, but it has
different validation rules  and all of them are classiﬁed as
inconsistencies. Once the product is valid, the product model
can be generated. In this model all features are mandatory
and the user can include new features, usually the ones
marked as ”out of scope” in the product map. Each product
has a simple documentation that includes the domain version
it was based on and its description.
III. EVA L UA T I O N
To evaluate the described tool, two case studies were
performed. The ﬁrst was in a controlled environment, while
the second was in a software company.
A. Controlled Environment
The case study followed guidelines from . This study
was performed before the second development iteration.
The goal of the study was to analyze ToolDAy with
respect to its aid in the DA execution and easy to use
environment. To achieve it, some questions were deﬁned
for the subjects. They were, (Q1) if ToolDAy aids in the
execution; (Q2) if there were any difﬁculties using the tool;
(Q3) if the consistency checker is helpful; and (Q4) if
ToolDAy tutorial is enough to learn how to use it.
The study was conducted in a post-graduation course at
a university lab from November, 2007 to February, 2008
by the students that performed a domain engineering (DE)
project based on a real-world case.
The project consisted of four reuse tools, which provided
solutions to increase the organization productivity through
reuse according to its maturity level. At the end of the
DA, they generated a feature model with 64 features, 14
requirements and 38 use cases.
The subjects were six students that played the domain
analyst role. All of them had worked before with the same
platform ToolDAy uses (Eclipse2) and half of them knew
some DA processes, while the other half knew just one.
After the project was concluded, the subjects were asked
to fulﬁll a feedback form with questions related to it. Their
answers are described next.
Q1: Four subjects considered that the tool aided in the
process execution, another judged that the tool did not help
a lot during the process execution, and the other did not see
the gain in using the tool.
The reasons given by the two subjects for not considering
the tool helpful were: great part of the process can be done
without tool support; lack of integration with the next steps
of DE; and the tool is not completed integrated with the
DA process used. However, ToolDAy focuses is on the DA
process support, a few steps of the product derivation, and
on generating the artifacts that will be later used on the DE
phases, it does not intend to integrate the complete process.
The other subjects explained why they considered the tool
helpful: it helps the process execution steps; and it aids in
the scope deﬁnition and in the domain modeling.
They also described some weakness and strengths about
the tool. The weaknesses were: traceability among require-
ments, use cases and features is too simple (in the evalu-
ation, requirements and use cases only had the name and
description and the traceability editor did not exist); lack
of requirement management; and a model with too many
features becomes too polluted. Some of the strengths were
the consistency checker; generation of reports; and the visual
representation of the domain model.
Q2: Only one subject did not have difﬁculty with the
tool. The other answers were (mutiple answers per subject):
Two said that the navigation is hard (both are familiar with
the platform and some DA processes). Two answered that
there was lack or insufﬁcient explanation for using the tool
(both are familiar with the platform, but one knows few DA
processes and the other just one). A subject related the lack
of knowledge in the DA process (he knows only one DA
process). In addition, a few subjects also informed that the
difﬁculty occurred because of the symbols used to represent
the relationships and the traceability between the domain
feature model and the product map.
Even though several subjects reported at least a difﬁculty,
they were mostly related to GUI or to speciﬁc aspects of
traceability (which have already being improved) and not to
the main functionalities of the tool.
Q3: Only one subject informed that the consistency
checker did not fully aid the problem identiﬁcation. The
restriction was the lack of an easier identiﬁcation of where
the problem is, i.e. the tool should select the exact spot of the
problem. The others considered it sufﬁcient for identifying
and resolving the problems.
Q4: Four subjects considered the information of the
tutorial sufﬁcient for learning how to use the tool and the
other two subjects did not use it. In addition, one that did not
use it was the same who declared that had some difﬁculty
due to lack or insufﬁcient explanation for using the tool.
Therefore, it indicates that the tutorial may overcome this.
Even with the analysis not being conclusive, the study
indicated that the tool has some strength for the DA sup-
port. On the other hand, aspects related to understanding
(difﬁculties during the process execution) were the focus of
the second iteration.
Nevertheless, some of the problems described by the
subjects can be resolved if a proper training, before the tool
starts to be used, is performed. After concluding the study,
some aspects should be considered before repeating it.
Training. Instead of the subjects learning how to use it
through the tutorial, a basic training can be applied. The
training can emphasize on unused aspects by the subjects of
this study and on the complaints related to it.
Questionnaires. The questionnaires should be reviewed
to collect more precise data related to where the problems
and difﬁculties occurred.
According to the feedback, some requirements were iden-
tiﬁed and developed in the second iteration. The consistency
checker now selects the exact spot where the problem is.
The requirements and use cases (as described before) are
more detailed and permit the traceability with features. The
traceability model can be exported as an excel document.
Additionally, some visualization ﬁlters to models with too
many features were created.
The other improvements from the questionnaires, such
as import the features added in the domain feature model
to the product map and search for features have not been
B. Industrial Case Study
The industrial case was developed at C.E.S.A.R. and it
is part of the company software reuse effort, as a way to
institutionalize reuse in all of its projects.
The business goals deﬁned for the project were: (a)
increase the productivity and (b) reduce maintenance costs
and development efforts. The pilot project selected was a
web/social network with seven different releases. The project
goal was to adopt a software product line with the beneﬁts
of: (i) better understandability of the project business; (ii)
identiﬁcation of new market opportunities; (iii) identiﬁcation
of new functionalities for the product; and (iv) decrease the
The team goal for the DA phase was to identify existing
features from other tools that were not present in their tool.
They performed the DA documenting the domain, deﬁning
its scope and building a glossary. They created the product
map of the analyzed applications and the features model of
domain with 74 features.
At the end, the team considered that the DA goal was
achieved. Moreover, a better understanding of the domain
being developed was accomplished, since several new fea-
tures were identiﬁed and planned to be developed.
The domain analyst did not have any formal DA process,
therefore he followed ToolDAy steps and had no difﬁculty
in using it. However, improvements were highlighted, such
as the possibility to export the product map as a table.
Even though the goal was achieved and the process result
brought beneﬁts to the team, for the domain analysts there
was no real data that using ToolDAy during the DA process
aided it. However, it is necessary to highlight that since the
user did not follow a speciﬁc process, the tool contributed
in the process execution because it provided a guideline to
deﬁne the domain scope, its feature model and to document
them. Furthermore, this industrial case worked as a proof of
concept for the tool.
IV. RELATED WORK
The systematic review  identiﬁed nineteen tools sup-
porting the DA processes. Some concentrate on the planning
phase - like PuLSE-BEAT  and DREAM  - while
others on the modeling - such as RequiLine . The support
for the validation phase differentiates among them, from
almost all to none support. Two tools outstand in the review
according to the number of essential requirements they
support, Holmes and RequiLine.
Holmes  provides functionalities for all identiﬁed
phases. It permits pre-analysis, domain documentation, com-
position rules support and validation, along with the domain
scope and a visual representation of the domain. Even
though it supports product instantiation, no documentation
is provided to it and to the features.
RequiLine  supports almost all functionalities for the
modeling phase, except feature group identiﬁcation. It pro-
vides a vast documentation for the domain and features, and
permits the inclusion of requirements that can be related
with the features in the domain. Besides, it supports product
derivation and documentation.
Among the analyzed tools, none of them provides a full
support to the process. The two closer to it still lack few
functionalities. ToolDAy development was planned focusing
on this problem and its development, according to results of
the review, is fulﬁlled.
V. C ONCLUSION
This paper presented ToolDAy, a tool that offers support
to several requirements within the process, which includes
scope deﬁnition, domain modeling, documentation and con-
sistency. Furthermore, ToolDAy also supports requirements
for the product derivation.
The support to requirements in every phase and having the
whole support in the same environment is one of ToolDAy
advantages when compared to other DA tools. Even though
it has a deﬁned process, it can be used without following
it, since the artifacts of planning and modeling (domain and
product) can be independently built.
The evaluations highlighted improvements that are being
developed. Furthermore, they indicate that the tool aids in
the process support, but new studies are necessary. For future
work, ToolDAy is being extended with feature interactions;
metrics regarding the domain information and different
visualization views for the domain representation.
This work was partially supported by the National Institute of Science
and Technology for Software Engineering (INES3), funded by CNPq and
FACEPE, grants 573964/2008-4 and APQ-1037-1.03/08.
 W. B. Frakes and S. Isoda, “Success factors of systematic
reuse,” IEEE Software, vol. 11, no. 5, pp. 14–19, 1994.
 L. B. Lisboa, D. Lucrdio, V. C. Garcia, E. S. Almeida,
S. R. L. Meira, and R. P. M. Fortes, “A systematic review of
domain analysis tools,” Journal of Information and Software
Technology, vol. 52, pp. 1–13, 2010.
 L. B. Lisboa, V. C. Garcia, E. S. Almeida, and S. L. Meira,
“Toolday - a process-centered domain analysis tool,” in Brazil-
ian Symposium on Software Engineering - Tools Session,
Brazil, 2007, pp. 54–60.
 T. v. d. Massen and H. Lichter, “Deﬁciencies in feature
models,” in Workshop on Software Variability Management for
Product Derivation, EUA, 2004.
 C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell,
and A. Wessln, Experimentation in Software Engineering: An
Introduction. Kluwer Academic Publishers, 2000.
 K. Schmid and M. Schank, “Pulse-beat – a decision support
tool for scoping product lines,” in Software Architectures for
Product Families, Spain, 2000, pp. 65–75.
 M. Moon, K. Yeom, and H. S. Chae, “An approach to develop-
ing domain requirements as a core asset based on commonality
and variability analysis in a product line,” IEEE Transactions
on Software Engineering, vol. 31, no. 7, pp. 551–569, 2005.
 T. v. d. Massen and H. Lichter, “Requiline: A requirements
engineering tool for software product lines,” in International
Workshop on Product Family Engineering. Italy: Springer
Verlag, 2003, pp. 168–180.
 G. Succi, J. Yip, E. Liu, and W. Pedrycz, “Holmes: a system
to support software product lines,” in International Conference
on Software Engineering. Ireland: ACM, 2000, p. 786.
3INES - http://www.ines.org.br