Conclusion - User-Level Workflow Design: A Bioinformatics Perspective - page 188

the applied constraints, such as a service whose existence in the solution
is enforced by constraints, so that one synthesis run can be performed to
generate the workflow up to this service, and another for creating the rest of
the workflow.
Specification flexibility
A central functionality improvement in order to increase the flexibility of the
synthesis method would be to distinguish more clearly between domain- and
problem-specific constraints. Currently, all constraints are treated equally
and applied to the same scope (i.e., the currently considered loosely speci-
fied branch). The only difference between domain- and problem-specific con-
straints is that the former are defined along with the domain model, while the
latter are dynamically added during the synthesis process. Actually, however,
it is desirable for the domain constraints to be applied globally to the entire
workflow models, while problem-specific constraints may only be associated
to a particular loosely specified branch. This goes in line with the ultimate
ambition of loose programming [178]: finally, the whole workflow model as
defined by the user will be treated as one comprehensive loose specification.
The synthesis framework detects the actually underspecified parts automat-
ically, and automatically creates a fully specified, readily executable model
corresponding to the abstract description.
In this regard also relevant is the appropriate treatment of second order
effects, which may occur when the workflow model contains several loose
branches: In general, the synthesis algorithm can not treat multiple loose
branches independently, since the concretization of one may cause side effects
that influence others (positively or negatively). An approach that resolves the
(potentially) occurring side-effects following a strategy based on property-
oriented expansion [296] is currently being developed.
Instance-based synthesis
The current implementation of the loose programming framework performs
the synthesis based on data types , rather than on concrete instances in terms
of the services' input/output parameters. Consequently, if several parame-
ters of the same type are involved, the synthesis framework is not able to
tell them apart. As detailed in Section 2.3.2, this can cause ambiguities, espe-
cially with respect to inserting and instantiating services that have more than
one parameter of a particular type. The simple heuristics for the parameter
instantiation that is currently applied by PROPHETS does indeed result in
correctly executable workflows in most cases studied. However, in particular
cases the parameters of the SIBs had to be (re-) configured manually in order
to obtain fully executable workflows.
To properly overcome these issues is a central aspect of future work on the
framework. One possibility would be to develop more sophisticated heuristics
for the instantiation, for instance by taking into account more of the available