MetaFrame in Practice: Design of Intelligent Network Services - Correct System Design: Recent Insights and Advances - page 389

of growing size of services, which may contain several hundreds of nodes and
which are in their whole unmanageable.
Most useful are error views , which are implicitly dened by global constraints.
They reduce the service size on the basis of the so-called model collapse [24].
Their pragmatics is illustrated in the next section.
In their handling, views do not dier much from the actual IN models. E.g.
they can be loaded and edited in the usual way, however, often with quite dra-
matic eects: minor modications on views may correspond to radical structural
changes of the underlying concrete model. In addition, views can be created ,
corresponding to the application of an abstraction function, and applied to the
underlying concrete model, corresponding to the application of a concretization
function (cf. Fig. 1 and 5). Execution of a view means execution of the underlying
concrete model.
Fig. 4 shows a version of the UPT service, which has 158 nodes and 239
edges together with a comprehensible error view: just 10 nodes and 16 edges.
Spotting the errors (informally explained in the pop-up window) in the original
service graph is dicult, even though their location is indicated here by the thick
arrows.

3U ingthe M eta Frame -based Service Denition

The service denition environment must be easily usable also for pure appli-
cation experts: IN-service designers with hardly any programming skills. They
graphically build services on top of the SIBs, usually interactively, in cooperation
or even in presence of the customers, and need an intuitive tool support which
does not restrict creativity.

3.1 Background

Service Denition (SD) Environments for the creation of IN-services are usu-
ally based on classical `Clipboard-Architecture' environments, where services
are graphically constructed, compiled, and successively tested. Two extreme ap-
proaches to error handling characterize the state of the art of marketed SD
environments:

{ The avoidance approach guarantees consistency by construction, but the
design process is strongly limited in its flexibility to compose SIBs to new
services. A representative of this category is e.g. described in [4], where the
output of a Service Logic element is checked for its consumability by its
successor.
{ The creative approach allows flexible compositions of services, but provides
little or no feedback on the correctness of the service under creation during
the development: the validation is almost entirely located after the design
is completed. Thus the resulting test phase is lengthy and costly. [27] de-
scribes an IN environment to develop, in several cycles, service logic program