=Paper=
{{Paper
|id=Vol-2857/pt_paper1
|storemode=property
|title=BeSoS: A Tool for Behavior-driven and Scenario-based Requirements Modeling for Systems of Systems
|pdfUrl=https://ceur-ws.org/Vol-2857/pt1.pdf
|volume=Vol-2857
|authors=Carsten Wiecher,Joel Greenyer
|dblpUrl=https://dblp.org/rec/conf/refsq/WiecherG21
}}
==BeSoS: A Tool for Behavior-driven and Scenario-based Requirements Modeling for Systems of Systems==
https://ceur-ws.org/Vol-2857/pt1.pdf
BeSoS: A Tool for Behavior-driven and Scenario-based
Requirements Modeling for Systems of Systems
Carsten Wiechera , Joel Greenyerb
a
Dortmund University of Applied Sciences and Arts, 44139 Dortmund, Germany
b
FHDW Hannover, 30173 Hannover, Germany
Abstract
Systems of Systems (SoS), like connected vehicle systems, provide their functionality by the interaction of several constituent
systems (CSs). [Problem] Due to the managerial, operational and evolutionary independence of the CSs in an SoS, requirements
constantly change over time and linear, top-down requirements engineering methods cannot be applied without significant
adaptations. New tools are needed that support the continuous and iterative specification and alignment of requirements across
different levels of abstraction. [Principal Ideas] We propose to integrate the behavior-driven development (BDD) approach with
an intuitive and executable scenario-based modeling of functional requirements. In this way, stakeholder expectations can be
structured via features and documented in natural language as usage scenarios. Based on usage scenarios, the modeling of
functional requirements can be driven by tests, allowing for the automated testing and analysis of requirements. This in turn
supports the iterative specification of requirements and the alignment of stakeholder needs. [Contribution] In this paper we
showcase the tool BeSoS that supports the iterative and behavior-driven specification of requirements in an SoS context. We
propose a method and describe its tool components using an example. The tool is available here: https://vimeo.com/512739942
Keywords
System of Systems Engineering, Requirements Analysis, Scenario-based Requirements Modeling, Requirements Specification
1. Introduction
With this paper we present the tool BeSoS 1 , a tool for the behavior-driven and scenario-based requirements modeling
and validation. In BeSoS we combine the Scenario Modeling Language for Kotlin (SMLK)2 with the behavior-driven
development tool Cucumber3 to support the requirements engineer in the iterative specification and analysis of
functional requirements in a system of systems (SoS) context [1].
In the automotive domain, requirements are usually documented in natural language [2]. Although model-
driven methods are widespread in the automotive domain, only a few frameworks explicitly integrate model-driven
techniques that support the validation and analysis of requirements [3]. With BeSoS we propose an application-
oriented approach with the aim of facilitating the use of formal, executable requirements specification and analysis
in practice. In collaboration with a Tier1 supplier company, we already showed that the formal and scenario-based
modeling can reveal contradictions in automotive requirements specification [4] and can help to bridge the gap
between the business and technical domains via continuous validation and short feedback loops [5]. Based on these
In: F.B. Aydemir, C. Gralha, S. Abualhaija, T. Breaux, M. Daneva, N. Ernst, A. Ferrari, X. Franch, S. Ghanavati, E. Groen, R. Guizzardi, J. Guo, A.
Herrmann, J. Horkoff, P. Mennig, E. Paja, A. Perini, N. Seyff, A. Susi, A. Vogelsang (eds.): Joint Proceedings of REFSQ-2021 Workshops, OpenRE,
Posters and Tools Track, and Doctoral Symposium, Essen, Germany, 12-04-2021
Envelope-Open carsten.wiecher@fh-dortmund.de (C. Wiecher); joel.greenyer@fhdw.de (J. Greenyer)
Orcid 0000-0002-3280-4471 (C. Wiecher); 0000-0003-0347-0158 (J. Greenyer)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings CEUR Workshop Proceedings (CEUR-WS.org)
http://ceur-ws.org
ISSN 1613-0073
1
https://bitbucket.org/crstnwchr/besos/
2
https://bitbucket.org/jgreenyer/smlk/
3
https://cucumber.io
findings, we specifically focused on modeling requirements in a system of systems (SoS) context [6] to address the
challenges in requirements engineering (RE)[7] for the next generation of automotive systems [8].
Ncube and Lim argue that it is important to identify the SoS type in an early phase of system development, because
the SoS type has a significant influence on the applicability of RE methods [7]. We chose to focus on acknowledged
SoS, which are arguably the most common kind of SoS in transportation and mobility use cases. An acknowledged
SoS is an SoS where a central authority can be identified that directs the SoS operation (e.g. a local government).
Furthermore, for an acknowledged SoS the requirements, objectives and responsibilities can be recognised on the SoS
level, and there can be contractual relationships between the central authority and the individual constituent systems’
(CSs) owners. However, the CSs keep their own management, funding, and development processes (cf. [9, 10, 11]).
BeSoS - Behavior-Driven Requirements Modeling for Systems of Systems
BeSoS - Behavior-Driven Requirements Modeling for Systems of Systems
With this context set, we focus on the modeling and analysis of requirements in an automotive context by mainly
Cucumber
Cucumber
SMLK
addressing the research theme of multi-level modeling techniques for SoS requirements, as identified by Ncube and
Test Step Specification
Inter
System
Scenarios
CS1 CS2 CS2
CS1
CS4
CS3
Lim [7]. We propose an iterative and integrated modeling method for the SoS behavior and the CS behavior (see
Usage Usage CS3 CS4
Scenarios Scenarios Given
Usage Intra
Scenarios System S1
When
Then Scenarios
details on the methodology in [6]). The proposed tool is part of an ongoing research in close collaboration between a
Feature Feature SoS Scenario Specification S3
Specification Test Step Scheduler Specification SoS Test Step
(System of Systems) (Constituent Systems Level) Feature Specification
Specification SoS Scenario Program
Tier1 supplier and different research institutions.
CS Scenario Specification
CS Scenario Program
CS4
CS3
2. The BeSoS Tool
CS2
CS1
Usage Test Executer
Given
Inter Intra When Scenarios
System CS1 CS2 System S1 S2 Then
Scenarios Scenarios
The intended user of the tool are requirements engineers that are responsible for the specification of requirements
CS3 CS4 S3 S4 CS
Feature
Specification
Scenario Specification SoS Scenario Specification CS
for technical systems in an SoS context. We first show an idealized process including the single steps and involved
Event Selection
Scenario Program SoS
Event Selection
Scenario Program CS
artifacts. Second, we describe the components of the tool. SMLK
2.1. Method
Clarification of Stakeholder Needs Information from different
Stakeholders
(Requirements Lists,
Emails, Error Reports, .... )
Specification of Features
9. Clarify
stakeholder
requirements
Feature
Specification
1. Identify features Test-Driven Scenario Specification
Skeleton Scenario
Specification
test passed test failed
2. Define
Test Step
Usage each feature by 4. Extend/adapt 5. Execute 6. Extend/adapt
Specification 7. Execute
Scenarios one or more usage Skeleton test step newly added scenario
scenarios test all tests
specification test behavior specification
failed
all tests passed
3. Derive test
skeletons Test Step
Specification
8. Analyze
test results
Legend
Start Data Automated Manual Control Data
Iteration Process Flow Flow
Object Process Process
Figure 1: Method for the iterative formalization of requirements.
The aim of the method is to create a formal specification of system requirements on the SoS and CS level that can
be validated to iteratively align system requirements with the stakeholder needs.
Figure 1 shows the process supported by BeSoS; it covers different areas within the RE process: elicitation, modeling,
and requirement analysis, which we grouped into clarification of stakeholder needs, specification of features, and test-
driven scenario specification (TDSS). Each of these areas includes artifacts with different degrees of formality. The
starting point is a collection of informal information artifacts. This can be requirements lists, emails, validation
results, or other sources of information that reflect stakeholder needs in different formats and levels of abstraction.
To drive the scenario-based requirements modeling, we first identify features and create separate feature files (1).
Subsequently, we derive usage scenarios for each feature (2), which describe the stakeholder needs in a structured and
comprehensive form, using behavior-driven development (BDD) techniques. In (3) we use this structured specification
of features and usage scenarios to automatically derive test skeletons. Test skeletons provide a Given-When-Then
structure for a testing framework, and serve as the starting point for the TDSS sub-process, cf. [4]. In TDSS, the
requirements are modeled, driven by the tests, using an executable scenario modeling language. Driven by tests, the
requirements models are extended and completed in an iterative way, continuously validating them, and checking
and resolving inconsistencies, until all requirements are modeled, i.e., all generated tests are passed.
Since we generate the tests from usage scenarios that relate to features that in turn are derived from stakeholder
needs, we create a closed loop with analyzing the test results (8) and clarifying stakeholder requirements (9).
All steps are consistently supported by BeSoS by integrating the technologies provided by Cucumber, JUnit, and
SMLK: The specification of features (1) and usage scenarios (2) are supported by the Cucumber tool that also allows
the generation of test steps (3). The test-driven requirements modeling (4,6) is is done by using SMLK. Within the
TDSS sub-process, the actual test execution (5,7) is directed by JUnit, which in turn integrates with Cucumber and
links test results with features, this way supporting steps 8 and 9.
2.2. Architecture
BeSoS - Behavior-Driven Requirements Modeling for Systems of Systems
Cucumber SMLK
CS4
CS3
CS2
CS1
Given Usage Inter CS1 CS2
Intra S1 S2
When Scenarios System CS3 CS4 System S3 S4
Then Test Step
SoS Specification Scenarios Scenarios
Feature
Specification
SoS Scenario Specification CS Scenario Specification
SoS Scenario Program CS Scenario Program
Given Usage
When Scenarios Test Executer
Then
CS
Feature
Specification
Figure 2: Architecture of the BeSoS tool that combines SMLK and Cucumber.
BeSoS consists of the components shown in Fig. 2. Features can be specified on the SoS- and CS-level and are
stored in separate files, including one or several usage scenarios written in the Gherkin syntax4 as shown in Listing 1.
4
https://cucumber.io/docs/gherkin/
9. Clarify
1 Feature: send advertisement with available charging stations near vicinity
2 Scenario: electric vehicle changes position
3 When the electric vehicle changes its position
4 Then the advertisement SoS offers available charging stations in the closer vicinity
Listing 1: Feature specification using the Gherkin syntax.
When conceiving a new SoS, we propose to start with the definition of features that describe how users and
external systems interact with the SoS. Formally modeling these interactions is done, on the one hand, with usage
scenarios and detailed test step specifications that describe the expected reactions of the SoS to external events. On
the other hand, we suggest to use inter-system scenarios [6], motivated by [12], for modeling the SoS end-to-end
system interactions. The goal is to conceptualize which CSs are necessary to provide the SoS functionality, and how
these systems must interact. The inter-system scenarios form the SoS scenario specification. Together with the tests,
this specification is executable as an SoS scenario program.
Based on the SoS scenario specification, we can detail the expected behavior of the to-be-developed CSs in
separate CS scenario specifications [6]. The goal here is to provide a thorough basis for implementing new CSs. With
specific CS-level feature specification and detailed test step specifications, these CS specifications can be executed
as independent CS scenario programs. But the CS specifications can also be executed in conjunction with the SoS
scenario program. This way, both views can be aligned in order to identify possible contradictions between the
expected SoS behavior and specified behavior of individual CSs.
2.3. Example
To illustrate the usage of the tool, we consider an example SoS with systems that interact in order to provide a driver
of an electric vehicle with current price information of nearby charging stations. We assume that an electric vehicle
regularly sends its current location to an advertising service, which then collects pricing information about nearby
charging stations. The advertising service collects this information and sends it to the user via a their smartphone
app.
We consider three viewpoints in this example (VP1-VP3, see Fig. 3). VP1: SoS-level features and detailing tests;
VP2: inter-system scenarios; VP3: CS specification scenarios. For VP1 we consider the SoS as a black-box and create
the SoS feature specification as exemplary shown in Listing 1. This feature documents that an offer with available
charging stations should be made to the SoS user when the vehicle sends an updated location.
Following the BeSoS method, we generate test steps based on the defined usage scenario (Listing 1) as shown in
Listing 2. (We keep it simple for brevity; a test could also specify that specific prices of specific nearby stations are
correctly displayed.) Subsequently we enter the TDSS sub-process; with starting the TDSS iterations we change to
the viewpoint VP2 and specify of inter-system scenarios.
1 When(”the \”Electric Vehicle\changes its position”) {
2 trigger(gpsSensor sends electricVehicle.positionChanged(VehiclePosition(23232.323, 323.2323))) // manually added SMLK code
3 Then(”the \”Advertisement SoS\offers available charging stationin the closer vicinity”) {
4 eventually(smartphoneApp sendsosUser.showAdvertisement())} // manually added SMLK code
Listing 2: Generated test steps.
To pass the test in Listing 2, we model SoS requirements as a scenario, see Listing 3 (also see bottom of Fig. 3). This
scenario is triggered when the GPS sensor sends the position changed message to the electric vehicle. In the body of
the scenario we model the interactions between the CSs: the vehicle sends its current position to the advertisement
service (line 3) that in turn inquiries information about charging stations in the vehicle’s vicinity (line 4). This
information is then provided (line 7) and the advertisement service sends an offer to the smartphone app (line 10),
Smartphone Advertisement
App CS Service CS
VP3
VP1
Advertisement SoS
VP2
position
Gps changed
Sensor Electric Charging Station
Vehicle Operation Service
Smartphone currentVehicle getChargingStations
show App Location
advertisement
getCurrent
Advertisement KWHPrice Charging
advertisement Service Stations
Information
SoS User
Smartphone Advertisement
App CS Service CS
VP3
Smartphone Electric Advertisement Charging Station
SoS User
App Vehicle Service Operation Service
currentVehicle
Location(loc) getChargingStation
Near(loc)
charging
StationNear(loc, CSList)
advertisementInformation(advertisement)
showAdvertisement()
Figure 3: SoS example: e-mobility advertisement SoS
which displays it to the SoS user (line 11). Let us suppose that on this level, we have not yet detailed the way in
which charging stations become known to the operations service. To nevertheless have a meaningful and executable
specification, we can provide prototypical parameter values within the scenario (lines 5 and 6). Likewise, let us
suppose it is to be clarified how the advertisement service actually compiles the pricing information. Should the
service query each charging station every time? Should the charging stations receive regular pricing updates? That
may be an architectural decision to be taken later. At this stage, we provide a prototypical advertisement object here
as well (line 9).
1 scenario(gpsSensor sends electricVehicle receives ElectricVehicle::positionChanged){
2 val loc = it.parameters[0] as Location
3 request(electricVehicle sends advertisementService.currentVehicleLocation(loc))
4 request(advertisementService sends chargingStationOperationService.getChargingStationsNear(loc))
5 val dummyCS1 = ChargingStation(”EcoBigCharge”)
6 val dummyCS2 = ChargingStation(”StarCharge”)
7 requestParamValuesMightVary(chargingStationOperationService sends advertisementService.chargingStationsNear(loc, listOf(dummyCS1, dummyCS2)))
8 // To be refined: how does the advertisementService actually collect the price updates to forward to the user?
9 val dummyAdvertisement = Advertisement(mapOf(dummyCS1 to 295, dummyCS2 to 289)) // use dummy values for now
10 requestParamValuesMightVary(advertisementService sends smartphoneApp.advertismentInformation(dummyAdvertisement))
11 request(smartphoneApp sends sosUser.showAdvertisement())
12 }
Listing 3: SoS Scenario Specification
In this fashion, we can incrementally add further scenarios and CSs until the previously defined test cases are satisfied.
The next step is to specify the behavior of the individual CSs, and we switch to the viewpoint VP3. Here we
abstract from a concrete SoS context and support the application of the proposed method independently for each
CS, by using abstract interfaces. As an example, Listing 4 shows a CS scenario for the advertisement service. This
scenario is triggered when the vehicle sends its current location to the advertisement service (line 1). Then the
scenario specifies to retrieve a list of charging stations near that location from the charging station operation service
(line 2). This is similar to the SoS-level scenario—some redundancies can be expected. Next, however, the scenario
specifies how the pricing information shall be obtained (lines 8-12). Indeed the taken approach is to ask each charging
station nearby. The information is collected in a map that is defined within the scenario (line 6), and this map is now
used to create an advertisement object (line 14), which is then sent to the smartphone app (line 15).
In this CS-level scenario we use the keyword r e q u e s t where the specified CS sends messages and w a i t F o r where
the CS receives messages. Moreover, as we no longer resort to prototypical parameter values, we no longer use
r e q u e s t P a r a m V a l u e s M i g h t V a r y . In lines 7, 13 we see a construct s c e n a r i o . . . b e f o r e < e v e n t > , which specifies that
the nested scenario must occur before the occurrence of < e v e n t > . In this case, collecting the price information must
happen before sending the advertisement information to the smartphone app. Also thinking about what events
are forbidden in certain event sequences is important, especially when jointly executing scenarios on the SoS and
CS-level. Here this forces the two scenarios to synchronize on the event, while the prototypical value suggested in
the SoS-level scenario will be overwritten with the value provided in the CS-level scenario.
1 scenario(electricVehicle sends AdvertisementService::currentVehicleLocation.symbolicEvent()){
2 val loc = it.parameters[0] as Location
3 request(advertisementService sends chargingStationOperationService.getChargingStationsNear(loc))
4 val availableChargingStationsEvent = waitFor(chargingStationOperationService sends AdvertisementService::chargingStationsNear.symbolicEvent())
5 val availableChargingStations = availableChargingStationsEvent.parameters[1] as List
6 val chargingStationsCurrentPrice = mutableMapOf()
7 scenario {
8 for(chargingStation in availableChargingStations){
9 request(advertisementService sends chargingStation.getCurrentKWHPrice())
10 val replyEvent = waitFor(chargingStation sends AdvertisementService::updateCurrentKWHPrice.symbolicEvent())
11 chargingStationsCurrentPrice.put(chargingStation, replyEvent.parameters[1] as Int )
12 }
13 } before (advertisementService sends smartphoneApp receives SmartphoneApp::advertismentInformation)
14 val advertisement = Advertisement(chargingStationsCurrentPrice)
15 request(advertisementService sends smartphoneApp.advertismentInformation(advertisement))
16 }
Listing 4: CS Scenario Specification
3. Closing
In this paper we present the tool BeSoS that integrates the BDD paradigm with an intuitive and scenario-based
requirements modeling. The contribution is twofold: 1) With the comprehensive specification of features that
drive the intuitive and iterative modeling of functional requirements, we enable practitioners to use executable,
formal requirements specification and analysis techniques. Especially in the context of SoS with its independent and
evolving CSs, we believe that this tool and the proposed iterative method can be helpful. 2) Using formal scenario
models to bridge the gap from informal requirements to the design and implementation of systems is not new.
Different approaches argue that this is beneficial [13, 14, 15, 16]. The contribution of this work is that BeSoS supports
scenario-based modeling and programming techniques in a SoS context, based on LSC Play-Out [15] and behavioral
programming [17]. Thereby, the integration of the BDD and TDSS approach [4] addresses the coverage and sampling
concerns in scenario-based requirements engineering [16]: following the method shown in Fig. 1, we can ensure
that every feature is modeled by an appropriate set of scenarios (BDD), and that these scenarios are validated by an
appropriate set of tests (TDSS) (see also [6]).
References
[1] J. Lane, D. Epstein, What is a System of Systems and Why Should I Care, 2013.
[2] G. Liebel, M. Tichy, E. Knauss, O. Ljungkrantz, G. Stieglbauer, Organisation and communication problems in auto-
motive requirements engineering, Requirements Engineering 23 (2018) 145–167. doi:1 0 . 1 0 0 7 / s 0 0 7 6 6 - 0 1 6 - 0 2 6 1 - 7 .
[3] G. Liebel, M. Tichy, E. Knauss, Use, potential, and showstoppers of models in automotive requirements engi-
neering, Software and Systems Modeling 18 (2019) 2587–2607. URL: https://doi.org/10.1007/s10270-018-0683-4.
doi:1 0 . 1 0 0 7 / s 1 0 2 7 0 - 0 1 8 - 0 6 8 3 - 4 .
[4] C. Wiecher, J. Greenyer, J. Korte, Test-Driven Scenario Specification of Automotive Software Components,
in: 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems
Companion (MODELS-C), Munich, Germany, 2019, pp. 12–17. doi:1 0 . 1 1 0 9 / M O D E L S - C . 2 0 1 9 . 0 0 0 0 9 .
[5] C. Wiecher, S. Japs, L. Kaiser, J. Greenyer, R. Dumitrescu, C. Wolff, Scenarios in the Loop : Integrated Require-
ments Analysis and Automotive System Validation, in: ACM/IEEE 23rd International Conference on Model
Driven Engineering Languages and Systems (MODELS ’20 Companion), 2020. doi:h t t p s : / / d o i . o r g / 1 0 . 1 1 4 5 /
3417990.3421264.
[6] C. Wiecher, J. Greenyer, C. Wolff, H. Anacker, R. Dumitrescu, Iterative and Scenario-based Requirements
Specification in a System of Systems Context, in: F. Dalpiaz and P. Spoletini (Eds.): REFSQ 2021, LNCS 12685,
2021, pp. 1–17. doi:h t t p s : / / d o i . o r g / 1 0 . 1 0 0 7 / 9 7 8 - 3 - 0 3 0 - 7 3 1 2 8 - 1 _ 1 2 .
[7] C. Ncube, S. L. Lim, On systems of systems engineering: A requirements engineering perspective and research
agenda, Proceedings - 2018 IEEE 26th International Requirements Engineering Conference, RE 2018 (2018)
112–123. doi:1 0 . 1 1 0 9 / R E . 2 0 1 8 . 0 0 0 2 1 .
[8] O. M. Hoehne, G. Rushton, A System of Systems Approach to Automotive Challenges, in: SAE Technical Paper,
SAE International, 2018. URL: https://doi.org/10.4271/2018-01-0752. doi:1 0 . 4 2 7 1 / 2 0 1 8 - 0 1 - 0 7 5 2 .
[9] M. W. Maier, Architecting Principles for Systems-of-Systems, INCOSE International Symposium 6 (1996)
565–573. doi:1 0 . 1 0 0 2 / j . 2 3 3 4 - 5 8 3 7 . 1 9 9 6 . t b 0 2 0 5 4 . x .
[10] J. S. Dahmann, K. J. Baldwin, Understanding the Current State of US Defense Systems of Systems and the
Implications for Systems Engineering, in: 2008 2nd Annual IEEE Systems Conference, 2008, pp. 1–7.
[11] C. Nielsen, P. Larsen, J. Fitzgerald, J. Woodcock, J. Peleska, Systems of Systems Engineering, ACM Computing
Surveys 48 (2015) 1–41. doi:1 0 . 1 1 4 5 / 2 7 9 4 3 8 1 .
[12] D. Harel, R. Marelly, A. Marron, S. Szekely, Integrating Inter-Object Scenarios with Intra-object Statecharts for De-
veloping Reactive Systems, IEEE Design and Test (2020) 1–19. doi:1 0 . 1 1 0 9 / M D A T . 2 0 2 0 . 3 0 0 6 8 0 5 . a r X i v : 1 9 1 1 . 1 0 6 9 1 .
[13] C. Damas, B. Lambeau, A. van Lamsweerde, Scenarios, goals, and state machines: A win-win partnership
for model synthesis, in: Proceedings of the 14th ACM SIGSOFT International Symposium on Foundations of
Software Engineering, SIGSOFT ’06/FSE-14, Association for Computing Machinery, New York, NY, USA, 2006, p.
197–207. URL: https://doi.org/10.1145/1181775.1181800. doi:1 0 . 1 1 4 5 / 1 1 8 1 7 7 5 . 1 1 8 1 8 0 0 .
[14] J. Whittle, J. Schumann, Generating statechart designs from scenarios, in: Proceedings of the 22nd International
Conference on Software Engineering, ICSE ’00, Association for Computing Machinery, New York, NY, USA,
2000, p. 314–323. URL: https://doi.org/10.1145/337180.337217. doi:1 0 . 1 1 4 5 / 3 3 7 1 8 0 . 3 3 7 2 1 7 .
[15] D. Harel, R. Marelly, Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach,
SoSyM 2 (2003) 82–107.
[16] A. Sutcliffe, Scenario-based requirements engineering, in: Proceedings of the IEEE International Conference on
Requirements Engineering, 2003, pp. 320–329. doi:1 0 . 1 1 0 9 / I C R E . 2 0 0 3 . 1 2 3 2 7 7 6 .
[17] D. Harel, A. Marron, G. Weiss, Behavioral programming, Comm. ACM 55 (2012) 90–100. doi:1 0 . 1 1 4 5 / 2 2 0 9 2 4 9 .
2209270.