=Paper=
{{Paper
|id=Vol-3089/ttc21_paper_labflow_Hinkel_solution
|storemode=property
|title=An NMF solution to the TTC2021 incremental recompilation of laboratory workflows case
|pdfUrl=https://ceur-ws.org/Vol-3089/ttc21_paper9_labflow_Hinkel_solution.pdf
|volume=Vol-3089
|authors=Georg Hinkel
|dblpUrl=https://dblp.org/rec/conf/ttc/Hinkel21b
}}
==An NMF solution to the TTC2021 incremental recompilation of laboratory workflows case==
https://ceur-ws.org/Vol-3089/ttc21_paper9_labflow_Hinkel_solution.pdf
An NMF solution to the TTC2021 incremental
recompilation of laboratory workflows case
Georg Hinkel1
1
Tecan Software Competence Center GmbH, Peter-Sander-StraΓe 41a, 55252 Wiesbaden, Germany
Abstract
This paper presents a solution to the Incremental Recompilation Laboratory Workflows Case at the TTC 2021 using the .NET
Modeling Framework (NMF). This solution is able to derive an incremental change propagation almost entirely in an implicit
manner.
Keywords
Incremental, Model transformation, Laboratory automation, Workflows
1. Introduction Section 2 gives a brief overview on how NMF Expressions
and NMF Synchronizations work. Section 3 explains the
The transformation of high-level process models to low- actual solution. Section 4 evaluates the solution against
level jobs actually executed on machines is a common the reference solution. Finally, Section 5 concludes the
problem not only in laboratory automation but also in paper.
other domains such as smart production. In these do-
mains, it is desirable to adapt an executed process in case
of errors or at least avoid wasting resources if it is clear 2. NMF Expressions and NMF
that the complete workflow cannot be performed com- Synchronizations
pletely. As there are typically a lot of things that could go
wrong, it is desirable to design a transformation system NMF Expressions [2] is an incrementalization system
in such a way that an incremental change propagation integrated into the C# language. It takes expressions of
can be inferred, i.e. does not have to be specified by the functions and automatically and implicitly derives an
developer. incremental change propagation algorithm. This works
To assess to what degree current model transformation by setting up a dynamic dependency graph that keeps
tools are able to infer an incremental change propagation track of the modelsβ state and is adapted when necessary.
in such scenarios, the Transformation Tool Contest1 2021 The incrementalization system is extensible and supports
hosts a case for incremental recompilation of laboratory large parts of the Standard Query Operators (SQO2 ).
automation workflows. This paper presents a solution NMF Synchronizations is a model synchronization ap-
to this case using the .NET Modeling Framework (NMF) proach based on the algebraic theory of synchronization
[1]. blocks. Synchronization blocks are a formal tool to run
NMF is a framework built to support model-driven en- model transformations in an incremental (and bidirec-
gineering, incremental model analyses and incremental tional) way [4]. They combine a slightly modified notion
model transformations. In particular, NMF Expressions of lenses [5] with incrementalization systems. Model
[2] is an incrementalization system able to incremen- properties and methods are considered morphisms be-
talize arbitrary function expressions and NMF Synchro- tween objects of a category that are set-theoretic products
nizations [3, 4] is an incremental model transformation of a type (a set of instances) and a global state space β¦.
approach. Using both tools in combination, it is possi- A (well-behaved) in-model lens π : π΄ Λβ π΅ between
ble to solve the incremental laboratory workflows case types π΄ and π΅ consists of a side-effect free Get mor-
in a declarative manner such that the required change phism π ββ π ππ(π΄, π΅) (that does not change the
propagations can be derived mostly implicitly. global state) and a morphism π ββ π ππ(π΄ Γ π΅, π΄)
The remainder of this paper is structured as follows: called the Put function that satisfy the following condi-
tions for all π β π΄, π β π΅ and π β β¦:
TTCβ21: Transformation Tool Contest, Part of the Software
Technologies: Applications and Foundations (STAF) federated
conferences, Eds. A. Boronat, A. GarcΓa-DomΓnguez, and G. Hinkel,
π β (π, π β (π)) = (π, π)
25 June 2021, Bergen, Norway (online). π β (π β (π, π, π)) = (π, π Λ β β¦.
Λ ) for some π
" georg.hinkel@tecan.com (G. Hinkel)
Β© 2021 Copyright for this paper by its authors. Use permitted under Creative 2
Commons License Attribution 4.0 International (CC BY 4.0).
http://msdn.microsoft.com/en-us/library/bb394939.aspx;
CEUR
Workshop
Proceedings CEUR Workshop Proceedings (CEUR-WS.org)
http://ceur-ws.org
ISSN 1613-0073
SQO is a set of language-independent standard APIs for queries,
1
https://www.transformation-tool-contest.eu specifically defined for the .NET platform.
The first condition is a direct translation of the orig- 1 public void InitializeContext(IEnumerableExpression
samples, ISynchronizationContext context) {
inal PutGet law. Meanwhile, the second line is a bit 2 context.Data.Add( _platesKey, samples
weaker than the original GetPut law because the global 3 .ChunkIndexed( 8, ( samples, column ) => new
ProcessColumn( column,
state may have changed. In particular, we allow the Put 4 samples.Select( tuple => new ProcessWell(
function to change the global state. tuple.Item2 % 96, tuple.Item1 ) ) ) )
.Chunk( 12, ( columns, plateIndex ) => new ProcessPlate(
A (single-valued) synchronization block π is an 8- 5 $"Plate{plateIndex+1:00}", columns ) )
tuple (π΄, π΅, πΆ, π·, Ξ¦π΄βπΆ , Ξ¦π΅βπ· , π, π) that declares a 6 .AsNotifiable() );
synchronization action given a pair (π, π) β Ξ¦π΄βπΆ : 8 7 context.Data.Add( _tubesKey, samples
.ChunkIndexed( 16, ( samples, tubeIndex ) => new Tubes( $
π΄ βΌ = πΆ of corresponding elements in a base isomor- "Tube{tubeIndex+1:00}",
samples.Select( tuple => new ProcessWell(
phism Ξ¦π΄βπΆ . For each such tuple in states (ππΏ , ππ
), 9 tuple.Item2 % 16, tuple.Item1 ) ) ) )
the synchronization block specifies that the elements 10 .AsNotifiable());
(π (π, ππΏ ), π β (π, ππ
)) β π΅ Γ π· gained by the lenses 11 }
π and π are isomorphic with respect to Ξ¦π΅βπ· . Listing 1: Setting up the mapping of samples to plates
and wells
Ξ¦π΄βπΆ
π΄ πΆ
π π
π΅ π· This flexibility makes it possible to reuse the specifi-
Ξ¦π΅βπ·
cation of a transformation for a broad range of different
Figure 1: Schematic overview of unidirectional synchroniza- use cases. Furthermore, the fact that NMF Synchroniza-
tion blocks tions is an internal language means that a wide range
of advantages from mainstream languages, most notably
modularity and tool support, can be inherited [6].
A schematic overview of a synchronization block is
depicted in Figure 1. The usage of lenses allows these
declarations to be enforced automatically and in both di- 3. Solution
rections, if required. The engine computes the value that
the right selector should have and enforces it using the This section describes key aspects of our solution. First,
Put operation. Similarly, a multi-valued synchronization we describe how samples are chunked into plates and
block is a synchronization block where the lenses π and columns in Section 3.1. Next, we give a high-level
π are typed with collections of π΅ and π·, for example overview of the actual synchronization in Section 3.2.
π : π΄ Λβ π΅* and π : πΆ Λβ π·* where stars denote Sections 3.3β?? describe how the different high-level pro-
Kleene closures. tocol steps are synchronized. Section 3.6 explains the
Synchronization blocks have been implemented in synchronization of the Next reference and finally, Sec-
NMF Synchronizations, an internal DSL hosted by C# tion 3.7 shows how the synchronization is initiated.
[3, 4]. For the incrementalization, it uses the extensible
incrementalization system NMF Expressions. This DSL 3.1. Assignments of plates, columns and
is able to lift the specification of a model transforma-
tion/synchronization in three orthogonal dimensions:
wells
As a first step, the samples to process are grouped into
β’ Direction: A client may choose between trans- plates and columns. Each column consists of 8 wells that
formation from left to right, right to left or in can be pipetted at the same time. This is done using the
check-only mode Chunk operation recently built into NMF. This comes in
β’ Change Propagation: A client may choose two versions, Chunk and ChunkIndexed where the lat-
whether changes to the input model should be ter also keeps the original index in the original collection.
propagated to the output model, also vice versa The code for calculating the assignments of samples to
or not at all plates, columns and tubes is depicted in Listing 1. This
β’ Synchronization: A client may execute the listing shows how to register a collection of samples with
transformation in synchronization mode between a synchronization context. That is, because the assign-
a left and a right model. In that case, the engine ment of plates is needed in many places throughout the
finds differences between the models and han- synchronization, we put it as context.
dles them according to the given strategy (only The input type IEnumerable used in
add missing elements to either side, also delete Line 1 of Listing 1 denotes an incrementalizable collection
superfluous elements on the other or full duplex of samples. NMF essentially implements the Standard
synchronization) Query Operators of C# and a few more operators on
1 public class JobRequestToJobCollection : 1 public class AddReagentToJobsRule : SynchronizationRule<
SynchronizationRule { AddReagent, JobsOfProtocolStep> {
2 public override void DeclareSynchronization() { 2 public override void DeclareSynchronization() {
3 SynchronizeManyLeftToRightOnly( SyncRule()
>(), );
4 request => request.Assay.Reagents, jobCollection => 4 SynchronizeManyLeftToRightOnly(
jobCollection.Labware.OfType() 5 SyncRule(),
); 6 ( step, context ) => GetPlates( context )
5 SynchronizeManyLeftToRightOnly( SyncRule< 7 .SelectMany(p => p.Columns, (plate, column) => new
ProcessPlateToMicroplate>(), AddReagentLiquidTransfer(column, plate, step))
6 (request, context) => GetPlates(context), 8 .Where(transfer => transfer.Column.AnyValidSample.
7 (jobCollection,_) => jobCollection.Labware.OfType< Value),
ILabware, Microplate>() ); 9 ( jobsOfStep, _ ) => jobsOfStep.Jobs.OfType() );
SamplesToTubeRunner>(), 10 }
9 (request, context) => GetTubes(context), 11 }
10 (jobCollection,_) => jobCollection.Labware.OfType<
ILabware, TubeRunner>() );
11 SynchronizeManyLeftToRightOnly( SyncRule<
Listing 3: Synchronizing the jobs for an AddReagent
ProtocolStepToJobsRule>(), protocol step
12 (request, _) => request.Assay.Steps,
13 (jobCollection, context) => new
CollectionOfJobCollections( jobCollection,
context ) );
14 }
15 }
of the requested assay should be synchronized with
the job collections in the low-level model. For this,
Listing 2: The entry point synchronization rule we use a custom collection implementation that essen-
tially groups the low-level jobs of the resulting job
collection by name. This needs access to the trans-
formation context as it will store information such
top of this interface in order to derive an incremental as the affected samples of a job. The four calls to
change propagation for a given query. That is, the system SynchronizeManyLeftToRightOnly basically define
allows developers to obtain incremental updates of the collection-valued unidirectional synchronization blocks
results upon changes of the input models, such as adding that are only enforced from the left to the right.
a sample.
Lines 3β5 in Listing 1 calculate columns as chunks
of samples. These columns are then chunked into mi- 3.3. Synchronization of AddReagent
croplates. Line 6 forces the incrementalization of this The actual high-level process steps are translated using
collection. The idea of this order as opposed to chunking separate synchronization rules. That is, we synchronize
the samples into plates and then further into columns a protocol step with the jobs implementing this protocol
is to allow NMF to rebalance samples between columns step. The approach to transform the other types of high-
and then rebalance columns between plates. However, level jobs is conceptually similar, although the different
we did not specify a balancing strategy and thus, NMF complexity of the job types leads to a different complex-
will not try to rebalance the chunks. Similar, lines 8β9 ity of the synchronization rules required. The synchro-
calculate the collection of tube runners from different nization rule for the synchronization of AddReagent is
chunks of the input samples. depicted in Listing 3.
Line 3 marks the synchronization rule as instanti-
3.2. The model synchronization ating for ProtocolStepToJobsRule, which means
that the synchronization rule is used when the
The actual model synchronization is split into several ProtocolStepToJobsRule is executed with an Add-
synchronization blocks that act as isomorphisms. Each Reagent protocol step. Lines 4β9 denote the synchro-
synchronization rule defines a list of synchronization nization block that computes the elements from which
blocks that define what data should be synchronized. to create the jobs, using a dedicated class to represent
The entry point synchronization rule, depicted in Listing the request for a liquid transfer. The query calculates all
2, synchronizes an overall high-level job request with a columns of all plates that have at least any valid (i.e., not
low-level job collection. In this listing, Lines 3β4 denote failed) sample.
that the reagents are mapped to troughs and lines 5β Because the latter needs to be calculated incremen-
10 denote that that tube runners should be created to tally for each ProcessColumn, the calculation (and its
host the samples as well as microplates for processing. incrementalization) is separated into a static function
For the tubes and the microplates, we consume a second (see Listing 4).
parameter in the lens to access the plate collections stored The reason to separate the logic into an
in the context (cf. Listing 1). ObservingFunc instance here is that the incre-
In Lines 11β13 of Listing 2, we define that the steps
1 private static ObservingFunc 1 public class AddReagentTipToTipTransfer :
_anyNonErrorSample = new ObservingFunc( c => c.AllSamples.Any( s => s.State != > {
SampleState.Error ) ); 2 public override void DeclareSynchronization() {
2 ... 3 SynchronizeLeftToRightOnly( well => well.AddReagent.
3 AnyValidSample = _anyNonErrorSample.Observe( this ); Volume, transfer => transfer.Volume );
4 SynchronizeLeftToRightOnly( well => well.TargetWell.Well,
transfer => transfer.TargetCavityIndex );
Listing 4: Calculating whether a column has any sample 5 SynchronizeRightToLeftOnly( well => IsSampleFailed( well.
that is not in the error state. TargetWell.Sample ), transfer => transfer.Status
== JobStatus.Failed );
6 }
7 }
1 public class AddReagentLiquidTransferToLiquidTransfer :
SynchronizationRule { AddReagentTipToTipTransfer
2 public override void DeclareSynchronization() {
3 SynchronizeLeftToRightOnly( SyncRule(),
step => step.AddReagent.Reagent, liquidTransfer =>
liquidTransfer.Source as Trough );
4 SynchronizeLeftToRightOnly( SyncRule<
ProcessPlateToMicroplate>(), step => step.Plate, mation of tip liquid transfers. Lines 3β4 synchronize the
liquidTransfer => liquidTransfer.Target as volumes and the target cavity (the source cavity is always
Microplate );
5 SynchronizeManyLeftToRightOnly( SyncRule< 0 for a trough).
AddReagentTipToTipTransfer>(), The last synchronization block in line 5 specifies that
6 step => step.Column.Samples
7 .Where( s => s.Sample.State != SampleState.Error ) the failure of the tip transfer should be synchronized back
8 .Select( s => new AddReagentTip( step, s ) ), to the high-level job request model.
9 liquidTransfer => new TipCollection( liquidTransfer.
Tips ) );
10 SynchronizeManyLeftToRightOnly(
11 ( step, _ ) => step.Column.AllSamples, 3.4. Synchronization of
12 ( liquidTransfer, context ) => GetAffectedSamples(
context, liquidTransfer ) );
DistributeSample
13 }
14 } The synchronization of DistributeSample elements
works exactly like the synchronization of AddReagent
Listing 5: The synchronization of add reagent elements with one important exception: While the source labware
to actual LiquidTransferJob elements. of an AddReagent is accessible easily via the transfor-
mation trace from the reagent, this is unfortunately not
as easy for DistributeSample.
As a reason, the current design of the solution has
mentalization of a method in NMF involves some
no direct connection between a column of a processing
reflection and takes a bit of time while applying it to
microplate and the tube runner that holds the samples.
a particular element is rather cheap. Using a static
First, we created an approach that would calculate the
instance essentially caches the incrementalization and
mapping incrementally, but this turned out to be very
applies it to multiple instances. For this reason, although
resource-intensive both in terms of time and memory.
supported by NMF, nested queries are currently rather
slow and hence we refrain from using the C# query 1 private static Tubes GetSourceTube( ITransformationContext
context, ProcessColumn column ) {
syntax in the mappings such as Listing 3. 2 return GetTubes( context )
The child synchronization rule AddReagentLiquid- 3 .AsEnumerable()
4 .FirstOrDefault( t => t.Samples
TransferToLiquidTransfer defines how the in- 5 .AsEnumerable()
stances of this intermediate class are transformed into a 6 .Any( s => column.Samples
7 .AsEnumerable()
low-level job as depicted in Listing 5. Line 3 defines that 8 .Any( s2 => s.Sample == s2.Sample ) ) );
the source of the liquid transfer should be synchronized 9 }
with the trough created for the reagent. Line 4 specifies
Listing 7: Calculating the rube runner for a given column
that the reagent should be pipetted into the microplate
of a processing plate
created for the processing request. In Lines 5β9, the syn-
chronization block denotes which tips exactly need to be The solution now is to break out of the incremental-
created. We use an intermediate class and a custom col- ization monad explicitly and calculate the source tube
lection again in Line 9 in order to control that a tip liquid runner only once as depicted in Listing 7: We explicitly
transfer is only removed when it is still planned. Lines call the AsEnumerable method here in order to instruct
10β12 specify that the samples created for this liquid the compiler to actually compile the lambda expressions
transfer are stored inside the transformation context. used to calculate the tube runner. This, however, breaks
The synchronization rule AddReagentTipToTip- the support of rebalancing the chunks making up the
Transfer depicted in Listing 6 specifies the transfor- columns and plates.
1 public abstract class MicroplateProtocolStepRule : SynchronizationRule {}
JobsOfProtocolStep> 2
2 where TProtocol : IProtocolStep 3 public class WashToWashJob : MicroplateJobRule {
4 where TJobRule : MicroplateJobRule 4 protected override Expression>
5 { MicroplateProperty => wash => wash.Microplate;
6 public override void DeclareSynchronization() { 5 public override void DeclareSynchronization() {
7 MarkInstantiatingFor( SyncRule() 6 base.DeclareSynchronization();
); 7 SynchronizeManyLeftToRightOnly(
8 SynchronizeManyLeftToRightOnly( 8 tuple => tuple.Item2.Columns.SelectMany( c => c.Samples.
9 SyncRule(), Where( s => s.Sample.State != SampleState.Error ).
10 ( step, context ) => GetPlates( context ) Select( s => s.Well ) ),
11 .Where( plate => plate.AnyValidSample.Value ) 9 wash => wash.Cavities );
12 .Select( plate => Tuple.Create( step, plate ) ), 10 }
13 ( jobsOfStep, _ ) => jobsOfStep.Jobs.OfType() );
14 }
15 }
Listing 9: Synchronization of Wash steps
16 public abstract class MicroplateJobRule :
SynchronizationRule,
TJob>
17 where TProtocol : IProtocolStep
18 where TJob : IJob such that instance rules have to specify the property used
19 {
20 public override void DeclareSynchronization() {
to store the microplate.
21 SynchronizeManyLeftToRightOnly( The instantiation of the rule templates for Wash ele-
22 ( step, _ ) => step.Item2.AllSamples,
23 ments is depicted in Listing 9. Since the rule to synchro-
( job, context ) => GetAffectedSamples( context, job )
); nize Wash protocol steps is sufficiently described using
24 SynchronizeRightToLeftOnly(
25 step => AreAllFailed( step.Item2.AllSamples ),
the synchronization template, we do not need to provide
26 job => job.State == JobStatus.Failed ); any further specification other than the type parameters
27 SynchronizeLeftToRightOnly( SyncRule<
ProcessPlateToMicroplate>(),
to be used, including a reference to the child rule. Unfor-
28 tuple => tuple.Item2, MicroplateProperty ); tunately, the C# compiler is not (yet?) able to infer the
29 }
30 protected abstract Expression>
type parameters TProtocol and TJob, so they must be
MicroplateProperty { get; } specified explicitly.
31 }
For the synchronization of a Wash in conjunction with
Listing 8: Template for synchronization of microplate a specific processing plate, we need to specify the prop-
processing protocol steps erty holding the microplate (in Line 4) and handle the
additional reference to the cavities that should be washed.
For this, we need to override the declaration of the syn-
chronization rule. Because we do want to inherit the
3.5. Synchronization of Wash and declaration of the template, we need to call the base dec-
Incubate laration in line 6. Then, we add the synchronization of
the cavities in lines 7β9.
The synchronization of Wash steps and Incubate steps The synchronization of Incubate protocol steps
is very similar, because both steps (as many in lab au- works in the same way, except that the child rule extends
tomation) operate on entire microplates. The protocol the template with synchronization blocks for tempera-
step needs to be instantiated for each microplate used for ture and duration.
sample processing.
The synchronization rule templates for protocol steps
operating on a single microplate is depicted in List- 3.6. Synchronization of the Next
ing 8. There are two rule templates, one for synchro- reference
nizing a protocol step with a collection of low-level In order for the scheduler to be able to actually schedule
jobs, the other for actually synchronizing the proto- the low-level jobs, the base class for jobs keeps a reference
col step for a given microplate into a given job. The to the next and previous jobs. That is, the scheduler may
MicroplateProtocolStepRule class marks the rule
only schedule a job if all previous jobs are completed and
as instantiating and registers the calls to the child rule. in the opposite direction, the job is a prerequisite for all
The template for the latter, MicroplateJobRule, reg- next jobs.
isters affected samples, sets the samples to failed (using To aid this situation, we use a utility class called
another lens called AreAllFailed in Line 25) and syn- CollectionBinding that essentially enforces the syn-
chronizes the target microplate. As the target metamodel chronization of elements between an incrementalizable
does not use a shared base class for jobs operating on source collection (typically a query) and a target col-
microplates, the rule template uses an abstract property lection that should be adapted. The implementation is
1 CollectionBinding.Create( Before we describe the results in terms of performance,
2 _nextJobs.Jobs.Where( j => ProtocolSynchronization.
keep in mind that the reference solution is a solution
GetAffectedSamples( _context, j ).Intersect( samples
).Any() ), tailored manually and explicitly for the given types of
3 item.Next )
changes, without any incrementalization system or alike.
Listing 10: Binding the next low-level jobs to the jobs of Therefore, it is hard to beat it in terms of performance
the next job collection that affect the same and the strengths of our solution are rather in the declar-
samples ativeness and large variety of supported change types.
To evaluate the solution in terms of performance, we
have run the benchmark on a system equipped with a
Intel Core i7-8850H CPU clocked at 2.6Ghz and 32GB
depicted in Listing 10. The query calculates the jobs RAM, running Windows 10. The results are discussed in
for which the set of affected samples intersects the af- the remainder of this section.
fected samples of the current job. The return value is an
instance of the IDisposable interface, the typical inter- 4.1. Scaling Samples
face in .NET to dispose objects. In this case, the binding
is stopped when disposed. Since NMF supports bidirec- The results in terms of time to execute the initial trans-
tional references, only one direction of the the association formation for the scaling samples scenario are depicted
has to be set manually, the other is set automatically by in Figure 2. In this scenario, the different models repre-
NMF. sent loads of 8 samples (size 1) to 256 samples (size 32),
Unfortunately, the management of the collection bind- applied to a simple ELISA assay model. The results show
ing currently has to be done manually by handling change that whereas the time for the reference solution is essen-
events of the jobs created for a job collection. tially constant at around 50ms, the initial time for the
NMF solution grows worse than linear, it is more like
quadratic.
3.7. Starting the synchronization
To run the solution, we create a new context for the
model synchronization, initialize the samples and start
Tool
the model synchronization in the direction LeftToRight ATL_Incremental
with change propagation in both directions. 104 NMF
Reference
ttc2021_iworkflows_YAMTL
1 _context = new SynchronizationContext( _synchronization,
2 SynchronizationDirection.LeftToRight,
Time [ms]
3 ChangePropagationMode.TwoWay );
4 _synchronization.InitializeContext( _jobRequest.Samples, 103
_context );
5 _synchronization.Synchronize( ref _jobRequest, ref
_jobCollection, _context );
Listing 11: Starting the model synchronization 102
1 2 4 8 16 32 64 128 256 512 1024
Model
4. Evaluation
Figure 2: Time for the initial transformation in the scale sam-
The strongest point of the presented solution is that ples scenario
the change propagation can be inherited mostly from
a declarative specification. As a consequence, essentially
all types of changes are supported, not just the change We profiled the NMF solution. The results show that
types executed by the benchmark framework. This means much of the time is lost because NMF Synchronizations
that new types of error handling do not necessarily have executes the incrementalization of the queries used to
an effect on the transformation but they are supported specify the synchronizations over and over again instead
by default. The declarative specification, however, keeps of reusing it. Furthermore, the collection binding de-
the understandability of the solution at a good level. The picted in Listing 10 also requires the system to be in-
attendees of TTC will judge on the understandability crementalized over and over again. We expect that the
compared to the reference solution. performance gap could be reduced, if the frameworks
In addition to the inherited change propagation, the can be adapted to cache the incrementalization properly.
solution also means that no changes to the metamodel The results for propagating the state changes of low-
code are necessary and the model representation can be level elements are depicted in Figure 3. This includes both
reused independently of the transformation. changing the sample state and potentially removing low-
4 Γ 100
3 Γ 100
2 Γ 100 Tool
ATL_Incremental
Time [ms]
Time [ms]
NMF
Reference
100 ttc2021_iworkflows_YAMTL
Tool
ATL_Incremental 100
NMF
Reference
ttc2021_iworkflows_YAMTL
1 2 4 8 16 32 64 128 256 512 1024 1 2 4 8 16 32
Model Model
Figure 3: Results for the average time for an update in the Figure 5: Results for the average time for an update in the
scale samples scenario scale assay scenario
level job elements as they have become obsolete (since takes longer for smaller models up to some point. This
all processed samples failed). Although the NMF solution is because the benchmark framework uses Pythons
is slower, it is still within few milliseconds even for the subprocess.POpen to spawn the processes for the
largest models considered. model sizes and they can make use of JIT optimizations
of earlier runs. Again, the propagation of the changes
4.2. Scaling the Assay happens in a few milliseconds, both for NMF and the
reference solution, the reference solution being slightly
In the scale assay scenario, all model sizes use 96 samples, faster.
but the number of protocol steps varies: Whereas the
smallest model (size 1) uses a simplified ELISA assay
4.3. New samples
model with 8 steps, the largest model uses 32 repetitions
(256 protocol steps in total). The execution time for the The results for the initial transformation in the new sam-
initial transformation is depicted in Figure 4. The runtime ples scenario are depicted in Figure 6. Not very surpris-
of the NMF solution is again quadratic in the size of the ingly, they are similar to the scaling samples case because
model while the reference solution remains fast. the parameters for the initial model are exactly the same.
Tool Tool
ATL_Incremental ATL_Incremental
NMF 103 NMF
Reference Reference
103 ttc2021_iworkflows_YAMTL ttc2021_iworkflows_YAMTL
Time [ms]
Time [ms]
102 102
1 2 4 8 16 32 1 2 4 8 16 32 64 128
Model Model
Figure 4: Time for the initial transformation in the scale as- Figure 6: Time for the initial transformation in the new sam-
say scenario ples scenario
The results for updates are depicted in Figure 5. The The difference to the scaling samples scenario is that
results look awkward because the change propagation new samples are introduced during the runtime of the
2015, Held as Part of STAF 2015, LβAquila, Italy,
July 20-21, 2015. Proceedings, Springer Interna-
tional Publishing, Cham, 2015, pp. 3β17. URL: http:
101 //dx.doi.org/10.1007/978-3-319-21155-8_1. doi:10.
1007/978-3-319-21155-8_1.
Tool [4] G. Hinkel, E. Burger, Change propagation and
ATL_Incremental
Time [ms]
NMF bidirectionality in internal transformation DSLs,
Reference Softw. Syst. Model. 18 (2019) 249β278. URL: https:
ttc2021_iworkflows_YAMTL
//doi.org/10.1007/s10270-017-0617-6. doi:10.1007/
s10270-017-0617-6.
[5] J. N. Foster, M. B. Greenwald, J. T. Moore, B. C. Pierce,
A. Schmitt, Combinators for bidirectional tree trans-
100
1 2 4 8 16 32 64 128 formations: A linguistic approach to the view-update
Model problem, ACM Transactions on Programming
Figure 7: Results for the average time for an update in the Languages and Systems (TOPLAS) 29 (2007). URL:
new samples scenario http://doi.acm.org/10.1145/1232420.1232424. doi:10.
1145/1232420.1232424.
[6] G. Hinkel, T. Goldschmidt, E. Burger, R. Reuss-
ner, Using Internal Domain-Specific Languages
benchmark. The results for propagating these changes to Inherit Tool Support and Modularity for Model
are depicted in Figure 7. Still, the changes are propagated Transformations, Software & Systems Model-
within a few milliseconds, but this time this is much ing (2017) 1β27. URL: http://rdcu.be/oTED. doi:10.
slower than in the other two scenarios, in line with the 1007/s10270-017-0578-9.
performance issues in the initial transformation.
5. Conclusion
The solution has shown that it is possible to derive an
incremental change propagation for most of the trans-
formation. Only for smaller parts such as the synchro-
nization of the next reference, manual code is necessary.
The evaluation shows that the performance is good, al-
though it cannot keep up with the reference solution.
In exchange, the solution supports much more types
of changes. However, the solution also shows a perfor-
mance problem caused by the current inability of NMF
to cache the query incrementalization properly.
References
[1] G. Hinkel, NMF: A multi-platform modeling
framework, in: A. Rensink, J. SΓ‘nchez Cuadrado
(Eds.), Theory and Practice of Model Transforma-
tion, Springer International Publishing, Cham, 2018,
pp. 184β194.
[2] G. Hinkel, R. Heinrich, R. Reussner, An extensible
approach to implicit incremental model analyses,
Software & Systems Modeling (2019). URL: https://
doi.org/10.1007/s10270-019-00719-y. doi:10.1007/
s10270-019-00719-y.
[3] G. Hinkel, Change Propagation in an Internal Model
Transformation Language, in: D. Kolovos, M. Wim-
mer (Eds.), Theory and Practice of Model Trans-
formations: 8th International Conference, ICMT