Information Technology Reference
In-Depth Information
4.1
Separation of Concerns
This principle is a methodological cornerstone of our environment. It plays a cen-
tral role in our service denition environment e.g. for the management of teams
of designers that work on several aspects of the service under development. Ex-
amples for required separation of concerns are the `classical' distinction between
environment administrators, service designers, and service customizers with their
role-based responsibilities, as well as thematic-oriented separations according to
the aspect currently considered, e.g. user interaction, billing, exception handling,
routing and network related features. Our tool supports separation of concerns
{
at the
description level
, by oering a variety of constraint languages on dif-
ferent abstraction levels [19], which are typically tailored for dierent user
groups, and
{
at the
presentation and operation levels
, e.g. by means of its flexible
view
mechanism, which highlights the essence of the considered design decision
by hiding all the irrelevant details of the overall service graph [20].
4.2
Parameterization, Exchangeability and Reuse
Due to the abstract view of the components as coarse-grain, highly parameterized
procedural entities, their use is largely independent of their concrete realization.
Interchangeability of the implementing code has been exploited e.g. in order to
oer mixed-mode simulation of services. A component may in fact have several
implementations:
{
at dierents abstraction levels, from functional prototypes (adequate for ser-
vice animation) to the code running on the installed Service Control Point.
{
for operability in dierent environments (e.g., vendor-, country-, standard-
dependent).
Mixed-mode simulation enables the execution of services whose components are
not homogeneously realized. Obviously, correct executions are only possible if
the interoperability is guaranteed. Temporal constraints provide a corresponding
abstract means.
Besides the direct reuse of components in a dierent setting, we support a
more flexible reuse policy in the prototyping phase: a flexible wrapper/adapter
concept makes BBs
11
uniformly accessible for graphical, behaviour-oriented ap-
plication programming, and application-specic taxonomies, which may catego-
rize one and the same BB completely dierently in dierent contexts, provide
an application-specic view onto the content of the BB libraries. This supports
the construction of complex heterogeneous application programs by providing
policies for a context-dependent reuse of existing modules beyond the native
application domain, as long as the patterns of usage are compatible.
11
In particular also functionalities of legacy software.
Search WWH ::
Custom Search