Software Engineering & Business Process Management: Interpretatio, Imitatio, Aemulatio Prof.dr.ir. Hajo Reijers 1st IEEE International Workshop on Communicating Business Process and Software Models, September 23rd 2013

Some context

• Arno Reiff. “Interpretatio, imitatio, aemulatio: Begriff und Vorstellung literarischer Abha ̈ngigkeit bei den Ro ̈mern”, dissertation, Universita ̈t zu Köln, 1959.

PAGE 2 26-09-2013

Pindarus (522 BC – 443 BC) Horatius (65 BC – 8 BC) Vergilius (70 BC – 19 BC) Homerus (around 850 BC)

Software programs & business processes

• Design-time vs. run-time

• Information processing

• Compositional structure

• Humans in vs. out-of-the-loop

• Artifacts: design, maintenance, sense-making PAGE 3 26-09-2013

I. Vanderfeesten, H.A. Reijers, and W.M.P. van der Aalst. Evaluating Workflow Process Designs using Cohesion and Coupling Metrics. Computers in Industry, 59(5), 420-437, 2008.

Some reflections

Software engineering Business process management

PAGE 4 26-09-2013 Note: in neither domain are models the only or even the main artifact.

Design principles

PAGE 5 26-09-2013

Design principles

Loose coupling, tight cohesion

PAGE 6 26-09-2013

Law of Demeter:

1. Your method can call other methods in its class directly

2. Your method can call methods on its own fields directly (but not on the fields' fields)

3. When your method takes parameters, your method can call methods on those parameters directly.

4. When your method creates local objects, that method can call methods on the local objects.

Translated:

1. You can play with yourself.

2. You can play with your own toys (but you can't take them apart)

3. You can play with toys that were given to you.

4. And you can play with toys you've made yourself.

PAGE 7 26-09-2013 http://c2.com/cgi/wiki?LawOfDemeter

Design principles

PAGE 8 26-09-2013

Design principles

PAGE 9 26-09-2013

Design principles

PAGE 10 26-09-2013

Design principles

Design principles

PAGE 11 26-09-2013

PAGE 12 26-09-2013

Design principles

“Cyclomatic complexity (CC), another widely used industry indicator of software quality, represents the number of independent paths through the program source code. The CC number for individual modules or units can be calculated using one of several commercial tools. Best industry practice seeks to limit the complexity of individual code units to 10 or less because software modules having a CC greater than 10 have a higher risk of defects and a higher risk of "bad fixes" in which attempts to correct a defect result in new defects being inadvertently created. Typically. CC values exceeding 20 should be considered as alarming. While the percent of UCMS software modules with a CC greater than 10 is small, about 1,600 modules have a CC value greater than 20 which indicates a moderate to high risk. Of those with a CC greater than 20, almost 100 have a value of 50 or greater which means that they are not testable in a practical sense. The discovery of defects in User Acceptance Test may be, at least in part, the result of the high CC factor in these modules.”

PAGE 13 26-09-2013

C. Bennett et al. (2013). Independent Assessment of the Commonwealth of Pennsylvania Unemployment Compensation Modernization System Program (UCMS). SPECIAL REPORT CMU/SEI 2013-SR-020 - RESTRICTED USE

Design principles

What is the scientific basis for this?

“CC can be said to have absolutely no explanatory power of its own”

J. Software Engineering & Applications, 2009, 2: 137-143 doi:10.4236/jsea.2009.23020

Correctness

PAGE 14 26-09-2013

Correctness

PAGE 15 26-09-2013

Correctness

PAGE 16 26-09-2013

Correctness

PAGE 17 26-09-2013

/ name of department PAGE 18 26-09-2013

Correctness

Correctness

PAGE 19 26-09-2013

i o

Liveness and boundedness of short-circuited net

⇔ Soundness of net

Correctness

PAGE 20 26-09-2013

W.M.P. van der Aalst, K.M. van Hee, A.H. ter Hofstede, N/ Sidorova,, H.M.W. Verbeek, M. Voorhoeve, M., & M.T. Wynn. (2011). Soundness of workflow nets: classification, decidability, and analysis. Formal Aspects of Computing, 23(3), 333-363.

Correctness

PAGE 21 26-09-2013

S. Rinderle, M. Reichert, P. Dadam. Correctness Criteria for Dynamic Changes in Workflow Systems – a Survey. Data and Knowledge Engineering, Special Issue on Advances in Business Process Management 50(1):9–34 (2004)

Experimentation

PAGE 22 26-09-2013

Experimentation

PAGE 23 26-09-2013

Experimentation

/ name of department PAGE 24 26-09-2013

Experimentation

• Factor and factor levels • Subjects • Objects • Tasks • Response variables • Hypotheses • Parameters • Design • Instrumentation • Data collection

PAGE 25 26-09-2013

Experimentation

PAGE 26 26-09-2013

Experimentation

PAGE 27 26-09-2013

a randomized 2x2 factorial experiment

P. Pichler, B. Weber, S. Zugal, J. Pinggera, J. Mendling and H.A. Reijers. Imperative versus Declarative Process Modeling Languages: An Empirical Investigation. In F. Daniel, K. Barkaoui and S. Dustdar, editors, Proceedings of the BPM Workshops 2011, Lecture Notes in Business Information Processing 99, 383–394, 2012.

Experimentation

“Model interpretation occurs in two stages (Newell & Simon, 1972), these being perceptual processing (seeing) and cognitive processing (understanding). During perceptual processing, computational offloading effects can occur that can aid the subsequent cognitive processing. Model elements that can be perceptually discriminated reduce the processing burden of the cognitive system because the parsing of model elements to different semantic components is performed by the perceptual sensors (Treisman & Gelade, 1980). Several studies suggest that perceptual processing largely explains differences in the effectiveness of the subsequent cognitive processes (Larkin & Simon, 1987; Petre, 1995). These considerations suggest that the perceptual discriminability effect of an explicit visual syntax of Gateway constructs will be stronger when model complexity is increased.”

PAGE 28 26-09-2013

Recker, J. (2012). Empirical investigation of the usefulness of Gateway constructs in process models. European Journal of Information Systems. doi:10.1057/ejis.2012.50

Exemplary research where theory feeds hypotheses and where results are

assessed on theoretical contribution.

Summary

• Illustration of areas where: • SE clearly source of inspiration for BPM • SE and BPM go head-to-head • BPM improves upon SE

• It sounds like a nice marriage.

Hajo Reijers h.a.reijers@tue.nl http://www.reijers.com Twitter: @profBPM

Software Engineering & �Business Process Management:�Interpretatio, Imitatio, Aemulatio��Some contextSoftware programs & business processesSome reflectionsSlide Number 5Design principlesDesign principlesDesign principlesDesign principlesDesign principlesDesign principlesDesign principlesDesign principlesSlide Number 14CorrectnessCorrectnessCorrectnessCorrectnessCorrectnessCorrectnessCorrectnessSlide Number 22Experimentation ExperimentationExperimentationExperimentationExperimentationExperimentationSummary