Validation Based on Observation of the Behavior of Distributed Components

In this paper, we present the results of a research in which the validation activity of distributed software components is accomplished via formal models based on the observation of the component behavior. The proposal is to present an improved manner to validate the component by using its real behavior, and not only insufficient documentation and suppositions. 1. Research topic and Motivation Validation is essential in software development because it is responsible for the correspondence between the functionalities required by the client and those specified and implemented by the developer. Validation corresponds to the application of several test levels, such as unit, integration, system, acceptance, regression, etc., based on the test scenario created during the verification activity [1][2]. Once there is a difference between test results and specified results, it is an indication that the components were not implemented according to the specifications. In component-based software development, validation is not a trivial task, for system quality is dependent upon individual component quality. In this context, the difficulty to accomplish the validation tests comes from the fact that the components may be created by different suppliers, which use distinct techniques, methods and tools in the production process. This miscellany which occurs in software validation becomes even more challenging when the software is distributed among different teams, located, e.g. in different countries. As an example, one specific component may be developed and tested by a company in Brazil which needs the contribution of a component developed and tested in China, which in turn, may need a component developed and tested in France. How can these clients and suppliers communicate with each other efficiently once they are endowed with different cultures and languages? Each company has its own techniques, methods and tools according to its technical skills related to tests, its culture, its language, etc. Information related to component tests, necessary for the test execution or resulting from executed tests, even when available to other clients, will be difficult to understand once they do not feature a sharing pattern. Moreover, the internal structure of outsourced components is generally unknown and the documentation is not sufficient to work with all of the details and their interaction with other components. A solution to this problem may be found by using a common validation process among all of the teams which test each component. This process is based on the observation of the behavior of each component. This behavior is modeled in such a manner that client teams are able to test its real behavior without the need to make suppositions or jump to conclusions about it. In Figure 1 is showed the common validation process used by different teams that is based on component behavior. Figure 1. Example of teams that use a common validation process. 2. Proposed Technique The internal structure of a component is generally unknown and the documentation is not sufficient to solve details about its interaction with other components. In order to identify the relevant tests of the interactions, these tests are based on formal models of the components. However, the COTS are not often provided with complete and precise models which would help the integration tests. In practice, maintaining formal models is unrealistic because COTS evolve along time, which quickly invalidates the original project. A solution to this problem may be found by generating models directly from the components. In this case, the component system itself will act as an oracle during the tests. To accomplish this, an iteration technique is created to learn formal models from blackbox components. In Figure 2, the steps of the algorithm for the validation of the distributed component from the observation of its behavior are depicted, based on [3] and [4]. Figure 2. Steps of distributed component validation.