Research Article
Structural Test of a Data Basis Oriented Object after Phase of Conception
Laboratory of Research in LRI Data Processing, University Badji Mokhtar Annaba, Algeria
INTRODUCTION
The modelling aims to réduirela compléxité as isolating a peutit numbers elements importing at the same time to éxaminer. A model constructs itself therefore from an abstraction of the studied problem. The abstraction is a human faculty that permits to separate what is important and of what is not. To a reality, there is an infinity of modéles. A good model is the one that describes a reality for a problem posé (www.univ-reunion.fr/~panelli/enseignement/coo/td.htm).
The recent research at the level of SGBDs has the tendency to demonstrate that the most promising solution to remedy the hiatuses of the present SGBDs (basis of data for the domains industrial and big systems) consists in adding persistence to a programming language.
While insuring that this system possesses an important modeling power and offers all other functionalities of SGBDs.
SGBDOOs based on programming languages such as (Small Talk, C++, etc.) correspond well to this reality, whereas traditional SGBDs and the programming languages constitute two distinct realities (forever compatible) SGBDs are the result of the integration of the classical functionalities of SGBDs and an Object Oriented Language (www.syspotico.ca/mapoisson/sgbdoo/chap2. html).
If we consider the conception of an object oriented database many methods of conception will be the object of surveys (www.Vision; www.orsys.fr/cours/conception _orientée objet.htm; www.ese_metz.fr/metz/personnel/popineau/UML/UML_présentationpdf; www.ceation_ site_internet.info/chap004.htm; www.test.int-evry.fr:8088/biblio/livres/basesdonnees.php; www.alrj.org/docs/ langages/pooc.pdf); for the stage of test no strategy of test has been proposed however, except some works that propose specific tests in the used domains (www.VerifySoft.com/fr_cmtjava.htm; WWW.VerifySoft.com/fr-jcover.htm; WWW.moteurprog.com/?url=article_ Affiche.php&\D_article=68; WWW.Papp.in2p3.fr/Evenement/Anssors/aussoicristal.pdf; www.i3s.unice.fr/ ~mh/RR/2002/RR-02.01-F.MALLET.pdf; www.phpaie.net/archives/jan04/threads.html,Janvier; www.microsoftemea.comea.com/desktopdeployment/download/BDDtechnicaltraining/FAQ%20section; www.news.webplanete.net/Optimiser_ objet_messages.htm,8/3/2005) and its especially applied in the phase of validation of the database.
If we consider AOO, a strategy of test has been proposed and can be adapted to the object oriented database (Badri et al., 1995a, b).
Our project consists in the realization of a data basis multi médiat that will allow us to stock medical pictures of the sound and the text. Its data will be used later in entry for applications of treatments of pictures and the sound.
This basis of data must be reliable and of quality to be able to use given them without none problems.
After of the phase of analysis and conception of the data basis. The graphs results of this conception will be used at the time of the stage of test. As for the programming the whole work will be achieved in an environment of Java programming.
It is in this context and with the aim of proposing a general test strategy for BDDOO that study was located. This strategy tests the database right after its conception, something which permits to the inventor to correct his mistakes early before putting it at the disposal of the user.
The proposed strategy is essentially based on two steps: a static analysis and a dynamic analysis.
Static analysis: In a first step a code static analysis of different classes of the basis was done; the sought goal being:
• | The assessment of a set of quality indicators. |
• | The construction of the graphs of controls of the class methods. |
• | The construction of the graphs of dependence between classes. |
• | The analysis and the edition of the different graphs (class, method) |
• | The interdependence between the different constituents of the software. |
• | The addition, deletion and the modification of a class of the database. |
Dynamic analysis: In a second stage, we conduct the analysis of the dynamic behaviour of the classes of the database was conducted. The sought goal is:
• | The assessments of the efficiency of the tests. |
• | Help to the follow up and the pursuit of the tests. |
• | The assessment of the stopping criteria. |
INDICATOR OF ESTIMABLE RELIABILITY
It is intend to evaluate, starting right at the conception phase of the database, an indicator characterizing the estimable reliability of a class noted IFP (Aubry et al., 1984; Badri et al., 1989a, b; 1995a, b).
It is in fact about an evaluation of the rate of mistakes that if we can think that it is often linked to the failing rates, doesnt permit however, to evaluate to assess the operational reliability (Aubry et al., 1984; Laprie, 1988).
The IFPs are used in the test strategy of databases to inform us about the classes of the most critical databases as well as the critical methods on which it is necessary to concentrate more the test. Thereafter, all along present study, they will help us to update the database (when adding, deleting and modifying).
Indicator of estimable reliability of a method: IFP of a method Mi noted IFPMi is function of his intrinsic IFP of the method Mi IFP*Mi and of the IFP of all the methods that they call, weighted by their probability of call.
IFP Mi = IFP*Mi * F*Mi(IFP* Mi) , j = 1 ., k
Where: | ||
IFP* Mi | : | 1- tfp*Mi , IFP*Mi = - tfcMi*t - tcMi )/ aq Mi |
tfp*Mi | : | Indicatory of rate of estimable vestigial mistakes intrinsic of the method Mid. |
tfcMi | : | Indicatory of rate of estimable mistakes bound to the complexity of the method Mi 0 [0.1]. |
tc Mi | : | Rate of cover of unit test of the method of Mi ∈ [0.1]. |
aqMi | : | Effort of insurance and control of applied quality (>= 1). |
K | : | Numbers of the methods called by the method Mi. |
IFP *Mi | : | Intrinsic IFP of the method Mi. |
F Mi ( ) Function taking into account the graph of reduced control of the method Mi and pondering the IFP of the Mj methods called by Mi.
Indicator of estimable reliability of a class: To value IFP of a given class we interested to his public methods. The hold in account of the prived methods of the class is done in an implicit way in the assessment of the IFP of the public methods. The IFP of the methods of the class will be then:
With: | ||
K | : | Number of public methods. |
IFPMi | : | IFP of the public method Mi. |
We gets in this case, a system of N+1(N = n+k ) non linear equation where the numeric resolution gives the IFP of the methods as well as the one of the class
SENSIBILITY OF THE ESTIMABLE RELIABILITY
we chose a numeric approach, following which we value an indicator of the sensibility of the indicator of the estimable reliability of a classes is defined by:
IFPpi | : | Initial IFP of the packet class pi. |
IFPpi* | : | New value of IFP of the class packet after an improvement of IFP of the class. |
Here following an improvement of one of the characteristic parameters of its methods.
Test strategies of the object oriented applications: The strategy recommended for the unit tests and integration of the classes of the object oriented applications presents
the advantage of being general and remains applicable in most part of the programming languages by object. Its based on the two approaches introduced in the previous section. The static analysis permits to evaluate an important number of quality indicators (Aubry et al., 1984; Badri et al., 1989; Laprie, 1988) specific to the object oriented applications, starting at the first phases of the cycle, thus permitting, on one hand, the development control at different levels, and on the other hand, to orient the test process (Badri et al., 89). The dynamic analysis permits on one hand , to refine a part of these indicators, and on the other hand, to evaluate the efficiency of the test through the retained rates of cover (Badri et al., 1995a, b).
PROPOSED STRATEGY
After the conception of the database, the inventor applies the test strategy of object oriented applications , to his object oriented database since we retrieve the same concepts packets of classes, classes, methods .and can construct all the graphs, necessary to the test of present database (graph of inheritance, graph of call between classes, graph of control of a method, graph of call between methods). It is intend to evaluate, starting right at the conception phase of the database, an indicator characterizing the estimable reliability of a class noted IFP (Aubry et al., 1984; Badri et al., 1995b).
It is in fact about an evaluation of the rate of mistakes that if we can think that it is often linked to the failing rates, doesnt permit however, to evaluate to assess the operational reliability (Aubry et al., 1984; Laprie, 1988).
The strategy is summarized by the following Fig. 1.
The strategy starts with the unit test of the classes, we use the graph of inheritance between class. we test every method of the class under test while using its graph of control to execute all paths and to keep their trace. Thereafter we passe to test it of integration of the methods we use the graph of call between methods, after every test we value the rates of corresponding test cover as. rate of cover of test of the instructions, rate of cover of test of the conditions, rate of covers of test of the branches, rates of cover of test of the paths réduits, rates of cover of test of the massages.
Fig. 1: | Etapes of the strategie |
His rates are going to allow us to value the new values of the IFP correspendants and The compassion to have an idea on the critical components on which it is necessary to concentrate the more the test.
Then we passe to the integration test of the classes, and it is an ascendant test. We use the graph of call between classes, informed of the reliability information indicator estimable IFP, Sensibilité S, couplage, C, as the Fig. 2 indicates it and give an idea. This test is going to help us to can executed at least once these calls between classes that are represented by the coupling between classes, then we calculates the rates of cover corresponding that allows us to calculate the new values of the IFP .
All along our strategy we chose a quantitative approach where we calculate rates of test cover, that help us to calculate the IFP to be able to calculate the sensibility.
This sensibility allows us to determine the critical components on which it is necessary to concentrate the more of test.
All along the test we keeps some traces these traces are going to help us in the follow-up and the orientation of the test. The proposed strategy should be able to add, suppress or modify a class.
Addition of a class: We indicate the super class of the class to add, in other words, the code of the class to add. We dont accept the addition before the root class of the graph. We display the initial inheritance graph and the modified inheritance graph by marking the added class (Fig. 3).
The analysis of the code of the methods of the class will allow us to know the communication of this class with the other classes (through these methods) of the BDD (Fig. 4).
Test of the added methods was thrown as well as their integration test. Thereafter we throw the unit test of class and its integration test. Throughout this work we use the test that it is already used for the AOO, as well as the rates corresponding to each step of the test to be able to evaluate the IFPs of this added class.
Once this part is finished, it is noticed that in the methods of this added class we needed the other methods pertaining to the BDD class, but no class of the database needed the methods of the added class.
This modification (add a call toward these methods) will be taken under account by the modification part.
Addition of a method: The developer indicates the class where he wants to add a method.
Fig. 2: | Graph of dependence used between classes of the application |
Fig. 3: | General principle of the addition of a class |
Fig. 4: | Global communication of the class |
Thereafter the method is added, we analyze the code of this method and we should display the method control graph and the graph of call between methods of the class and the graph is used since its modified by the adding of that of that method. We throw the unitary test of the method and its integration test.
Deletion of classes: The developer indicates the class to suppress, we dont admit the suppression of the root class of the inheritance graph. We display the inheritance graph and the used graph informed of the information (IFP, Si, C) (www.philippe.guezelon.frée.fr/mcd/mcd.htm.) to indicate for it the importance of the class relatively to the set. The developer can come back on his decision if he judges the class important otherwise he will have an idea on the modifications to bring thanks to the information on the machings indicated at the level of the used graph (C). Figure 2 gives an idea of that information:
If the developer indicates a class which has some son classes, all the class packet will be suppressed. We display the inheritance graph by marking the class or classes to suppress.
Fig. 5: | Steps to follow for the suppression of a class |
Fig. 6: | Steps used to suppress a method |
For each class to suppress we should consider its methods and indicate for each method the set of methods it calls and the set of methods calling it, like indicated in Fig. 5.
For the methods which call the methods of the class to suppress, we should modify these methods and ignore their call toward these suppressed methods. It is thrown back the unitary test of these methods and their integration test. We should redo this same work for all the classes to suppress.
During the suppression we should follow the following steps: (Fig. 5).
Suppression of a method: if we want to suppress a method in a class we should first indicate the class to which the method belongs. Thereafter, it is determined the communication of that class with the other classes (for that method). Then we should update the calls of the other methods toward that method. We should throw the unitary test of the updated methods and thereafter throw their integration test. Throw the unitary test of the class where we operated a modification (Fig. 6).
Modification of a class: This modification consists on deleting, adding or modifying a method.
Modify a method: The developer brings the desired modification at the level of the method and then throws the unitary test of this one and then its integration test.
The strategy that we recommend for the unitary and integration tests for the classes of the oriented object databases has the advantage to be general. It is proposed to AOO and can be applied to BDDOO right after the conception phase.
It stands on two approaches: static and dynamic, it permits us to evaluate in the static analysis phase an important number of quality indicators specific to object oriented applications which will be adapted to BDDOO and the dynamic analysis permits us to refine these indicators, to follow their evolution during test and evaluate the efficiency of the test.
This strategy is the first part of a work on the test of BDDOO, the second part should take under account the dynamic test of the object oriented database to be able to verify the integrity constraints of the database.