The Design Principles and Practices of Interoperable Smart Spaces - Advanced Design Approaches to Emerging Software Systems - page 41

the context filter/reasoner, classified as
“Filter”&“Aggregator” ).
• Monitor is any KP which collects relevant
information for a pre-defined purpose.

engineering that enhances model driven develop-
ment with the use of ontologies for sharing the
meanings of domain, tasks and software concepts
in the development of the ready-to-use building
blocks for speeding up the SSA integration and
testing with the help of a KP repository. Thus, an
efficient use of the SmartModeller expects actions
to be written and available in a repository.
All three SSA development approaches have
been applied in practice. The integration of KPs
can be made by hand through the SIB. Thereaf-
ter, testing is made by a running demonstrator
that realizes one or a set of scenarios. Later on,
the working functionalities can be used by the
SmartModeller that integrates the building blocks
(data from SIB and actions from the repository)
together in a new way, i.e. by mashing up a new
SSA. The SmartModeller is intended for the use
of end-users; the professionals are expected to
use the KP template or the convenience libraries.
We have evaluated the KP template by designing
and implementing a set of scenarios for different
kinds of smart spaces. The convenience libraries
are still under testing. The SmartModeller has been
tested in a laboratory setting by professionals and
improved based on the evaluation results. So far,
a set of end-users (not experienced with the IOP
nor SS development tools) have begun an exercise
with the SmartModeller. These evaluation results
will be used towards the further improvement of
the tool.

The taxonomy tree, shown in Figure 3, rep-
resents our first attempt to define the roles of
KPs, starting from the core mission of the smart
spaces, which is making “information” in the
physical world available to smart applications.
The taxonomy includes examples of proof-of-
concept legacy adapters, aggregators, controllers
and filters, some of which were already available
as proof-of-concept prototypes.
Although the development of the KP taxonomy
is in its initiation phase, we are convinced of its
advantages in speeding up the development of
SSAs and guaranteeing a high quality of SSAs.
Obviously, there may be a great many classifica-
tions for KPs, and many properties and relations
between the KPs are hidden by the tree based tax-
onomy shown. Therefore, additional descriptions
(and tooling) are required when a KP ontology is
revised from this KP taxonomy. This is considered
to be a challenging and promising opportunity, as
a KP ontology would be extremely useful both at
design time and at run time for searching for the
most suitable KP.

THE INTEGRATION AND TESTING
OF SMART SPACE APPLICATIONS

THE EVALUATION OF
SMART SPACES

When the KPs required for an SSA are identified
and defined, their implementation can be deployed
to the concurrent distributed teams, which proceed
according to the productivity principle, searching
first the repository for existing KPs to be reused.
The KP may be specified by using an appropriate
KP template (in a tabular form) or the SmartMod-
eller tool (Katasonov & Palviainen 2010). The KP
template was useful in the early phase when no
KPs had been implemented yet. The SmartMod-
eller assists in adopting ontology driven software

In smart space evaluation, the ASSDE approach
focuses both on the instantiated IOP and the de-
veloped SSAs. As the SSA is intended to be used
in a smart environment, it cannot be evaluated
without the IOP. Thus, the evaluation is performed
as a combined effort of the IOP developers and
application developers. As IOP is already working
and the applications are made by end-users, the