Advances in Behavior Modeling

Ella Roubtsova    Open University of the Netherlands, Heerlen, The Netherlands

1 Introduction

Modern software-based businesses are various and dynamic. E-commerce and E-procurement, Insurances, Mortgages, and E-education take a holistic approach, incorporate changeability of software to make a profit of it. As a result, the life cycle of businesses becomes similar to the software life cycle.

The users, being the parts of interactive business processes, always propose new requirements. Most often, the requirements deal with changes in the system behavior. Behavior models serve to clarify what is wanted and how it can be integrated into the existing system.

The competitors inspire analysis of success factors sometimes hidden in business processes. Analysis requires behavior models leading businesses to the business goals.

Optimization of expenses drives the search for collaboration and services that are capable of implementing auxiliary subprocesses. However, the orchestration and choreography of collaborative businesses are fulfilled based on behavior models.

With such tendencies, even daily business terminology, including key performance indicators and capability, cannot be fully understood without behavior models.

The question is whether the available behavior modeling techniques are good enough for the challenges of the support of all activities of the system life cycle from requirements engineering, analysis, implementation to model-based testing (MBT), simulation, and reengineering?

In order to answer this question in this chapter, we

• formulate the properties of behavior modeling semantics needed for the major activities of the system life cycle support;

• define common elements for separation of behavior models from other types of models, and the properties associated with combinations of elements with different semantics;

• analyze the behavior modeling approaches inside the Unified Modeling Language (UML) and outside the UML and summarize the analysis in a table that relates the combinations of modeling semantics to the properties of behavior modeling approaches needed for the system life cycle support.

The goal of the survey is to provide the semantic help for the choice or design of behavior modeling techniques for different activities of the system life cycle support.

2 Properties of the Modeling Semantics Needed for System Life Cycle Support

Any system, whether it be a business system or a software system or a combination of both, lives a spiral life cycle. Each turn of the spiral goes through the same stages of goal definitions, requirements gathering, design, analysis (simulation), implementation, and testing. After that, the system is maintained. When the new goals and requirements appear, the cycle is repeated.

1. Requirements engineering is a process of collecting of descriptions of desired system behavior. A requirement item always presents a part of behavior observed by a stakeholder from the stakeholder's perspective. Some of the requirements concern a localized domain; others crosscut many domains like the plumbing in a building across all its flats. In any case, a requirement represents a part of system behavior. The ability of the modeling technique to separate modeling of partial behavior simplifies interaction of stakeholders during modeling.

Therefore, the desired property of the modeling technique is the ability to separate the modeling of partial behavior both for the localized and crosscutting concerns.

2. The design process is aimed to combine all partial descriptions and produce a system that meets the requirements.

An ideal modeling method for design should allow composition of all the behavior models of requirements into the system model.

3. The analysis phase is aimed to validate the completeness of the design against the requirements. The adequate completeness can be validated by the execution of the model on different data. The result of the model execution is compared with the requirements.

For this stage, the ideal behavior modeling method should be executable or, in other words, work with data. The semantics of the modeling techniques at the design phase should be comparable or easy transformable to the semantics of the modeling techniques used for the requirements engineering.

During the comparison of the design model with the model of requirements, the tacit knowledge [1], hidden in the heads of users, often triggers new requirements so that the design is repeated until no more requirements are produced or until the deadline. If the semantics of the modeling techniques used for the requirements specification and the design are comparable, such a repetition of the design cycle demands less effort and time.

4. The implementation phase demands the modeling methods which reflect the restrictions of implementation platforms. Modern implementation platforms often do not support separation of concerns and their composition. The discrete event behavior modeling techniques used for modeling of the implementation reflect the implementation restrictions. The practice to apply the behavior modeling techniques reflecting implementation restrictions for modeling of business results in complex and not easily changeable models.
The implementation platforms evolve, and they will inevitably evolve to support smooth transformation of business models to implementation. Nowadays, however, the behavior modeling approaches need to propose traceable transformation to implementation models. The traceable transformation of executable behavior models to implementation leaves less room for errors because the models and implementation can be tested against requirements.

5. The testing phase is meant to check that the implementation corresponds to the requirements. The design level model is a very useful artifact for testing. It can even become the basis for the model-based automated testing. However, if the design phase produces a model with implementation details, then the model can cause error propagation in models both in the code and in the tests [2]. This means again that the traceability between the implementation model and the requirements models should be maintained. As we mentioned earlier, this activity has more precision when the model is executable.

6. The maintenance and evolution are also the activities of any system life cycle. These activities may be seen as analyses, requirements engineering, and design within the existing system. The composition property of behavior models eases the maintenance and evolution.

If we summarize the requirements for the modeling techniques coming from all activities of the system life cycle support, we can make the following conclusion: the behavior modeling techniques supporting the whole system life cycle should enable

1. separation of modeling concerns gathered at the requirement phase;

2. composition of concerns modeled from requirements;

3. execution of the model of requirements for establishing relations between the model and the requirements and between the model and the implementation.

In this survey, we analyze the semantic elements of behavior modeling approaches aiming to find how the semantic elements contribute to meeting the formulated above requirements.

3 Events, States, Transitions, and Communication–Composition

Discrete event behavior modeling techniques are all descendants of the finite-state machines (FSMs) (or finite-state automata) [3].

A finite-state machine FSM = (E, S, T) is an abstract machine,...