Structured Behavioral Programming Idioms

  • Adiel Ashrov
  • Michal Gordon
  • Assaf Marron
  • Arnon SturmEmail author
  • Gera Weiss
Conference paper
Part of the Lecture Notes in Business Information Processing book series (LNBIP, volume 287)


Behavioral Programming (BP) is a modelling and programming technique proposed for specifying and for implementing complex reactive systems. While effective, we report on a weakness that stems from the verbosity and from the complexity of the programming constructs in BP. Our analysis, described in this paper, shows that developers who work with BP use specific patterns that allow them to control the complexity of their specification. Thus, the main contribution of this paper is a set of specification constructs that represent those patterns. We report on the design of the new idioms, termed structured constructs for behavioral programming and on an empirical evaluation in a controlled experiment that proved their effectiveness. In particular, the experiment examined the comprehensibility differences between behavioral specifications with non-structured BP programming idioms and with the structured ones. The results indicate that the new structures improve the comprehension of the behavioral specification.


Behavioral modeling Behavioral specification Behavioral programming Experimentation Abstraction Comprehension 



This research was partially supported by the Israel Science Foundation, the Philip M. Klutznick Research Fund, and the Dora Joachimowicz research grant.


  1. 1.
    Hendrix, T.D., Cross II, J.H., Maghsoodloo, S., McKinney, M.L.: Do visualizations improve program comprehensibility? experiments with control structure diagrams for Java. ACM SIGCSE Bull. 32(1), 382–386 (2000)CrossRefGoogle Scholar
  2. 2.
    Briand, L.C., Bunse, C., Daly, J.W., Differding, C.: An experimental comparison of the maintainability of object-oriented and structured design documents. Empirical Softw. Eng. 2(3), 291–312 (1997)CrossRefGoogle Scholar
  3. 3.
    Feo, J.T.: A Comparative Study of Parallel Programming Languages: The Salishan Problems. Elsevier, North Holland (2014)Google Scholar
  4. 4.
    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Addison-Wesley, Boston (1995)Google Scholar
  5. 5.
    Beck, K., Crocker, R., Meszaros, G., Vlissides, J., Coplien, J.O., Dominick, L., Paulisch, F.: Industrial experience with design patterns. In: Proceedings of the 18th International Conference on Software Engineering (1996)Google Scholar
  6. 6.
    Budinsky, F.J., Finnie, M.A., Vlissides, J.M., Yu, P.S.: Automatic code generation from design patterns. IBM Syst. J. 35(2), 151–171 (1996)CrossRefGoogle Scholar
  7. 7.
    Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns. Wiley, New York (1996)Google Scholar
  8. 8.
    Florijn, G., Meijers, M., Winsen, P.: Tool support for object-oriented patterns. In: Akşit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 472–495. Springer, Heidelberg (1997). doi: 10.1007/BFb0053391 Google Scholar
  9. 9.
    Prechelt, L., Unger, B., Philippsen, M., Tichy, W.: Two controlled experiments assessing the usefulness of design pattern information during program maintenance. IEEE Trans. Software Eng. 28(6), 595–606 (2002)Google Scholar
  10. 10.
    Prechelt, L., Unger, B., Tichy, W.F., Brossler, P., Votta, L.G.: A controlled experiment in maintenance: comparing design patterns to simpler solutions. IEEE Trans. Softw. Eng. 27(12), 1134–1144 (2001)CrossRefGoogle Scholar
  11. 11.
    Harel, D., Marron, A., Weiss, G.: Behavioral programming. Commun. ACM 55(7), 90–100 (2012)Google Scholar
  12. 12.
    Damm, W., Harel, D.: LSCs: breathing life into message sequence charts. J. Formal Methods Syst. Des. 19(1), 45–80 (2001)Google Scholar
  13. 13.
    Harel, D., Marelly, R.: Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer, Heidelberg (2003)Google Scholar
  14. 14.
    Harel, D., Marron, A., Weiss, G.: Programming coordinated behavior in Java. In: D’Hondt, T. (ed.) ECOOP 2010. LNCS, vol. 6183, pp. 250–274. Springer, Heidelberg (2010). doi: 10.1007/978-3-642-14107-2_12 CrossRefGoogle Scholar
  15. 15.
    Ashrov, A., Marron, A., Weiss, G., Wiener, G.: A use-case for behavioral programming: an architecture in JavaScript and Blockly for interactive applications with cross-cutting scenarios. Sci. Comput. Program. 98(Part 2), 268–292 (2015)Google Scholar
  16. 16.
    Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., et al.: Scratch: Programming for all. Comm. ACM 52(11), 60–67 (2009)Google Scholar
  17. 17.
    Maoz, S., Harel, D., Kleinbort, A.: A compiler for multi-modal scenarios: transforming LSCs into AspectJ. ACM Trans. Softw. Eng. Methodol. (TOSEM) 20(4) (2011). Article 18Google Scholar
  18. 18.
    Wand, Y., Weber, R.: On the ontological expressiveness of information systems analysis and design grammars. Inform. Syst. J. 3, 217–237 (1993)CrossRefGoogle Scholar
  19. 19.
    Bajaj, A., Rockwell, S.: COGEVAL: applying cognitive theories to evaluate conceptual models. In: Advanced Topics in Database Research, pp. 255–282 (2005)Google Scholar

Copyright information

© Springer International Publishing AG 2017

Authors and Affiliations

  • Adiel Ashrov
    • 1
  • Michal Gordon
    • 2
  • Assaf Marron
    • 3
  • Arnon Sturm
    • 1
    Email author
  • Gera Weiss
    • 1
  1. 1.Ben Gurion University of the NegevBeer ShevaIsrael
  2. 2.Holon Institute of TechnologyHolonIsrael
  3. 3.The Weizmann Institute of ScienceRehovotIsrael

Personalised recommendations