Academia.eduAcademia.edu

Figure 7 – uploaded by Nicole Levy

See full PDFdownloadDownload figure
Fig. 7. Metric Model One of the requirements of our framework is flexibility. Any moment, it is possible to add or modify the criteria of IS evaluation. These two operations require sometimes the addition of new metrics. The calculation of metric implies the notion of the metric variables (Mv). The Mvs are basic measurement functions extracted from IS or data collected by the designers. The majority of existent metric collection forces the user to write code to define each new metric. In our work, we chose to develop an approach allowing reducing the effort when adding news metrics. The idea consists in fact that an Mv is used in the calculation of one or more metric, and a metric can be used in the calculation of one or more other metrics. As Mvs are pre-implemented, the value of metric is obtained by the evaluation of its expression. It is necessary to write code when the calculation of a metric requires the definition of a new Mv. The user can enter all the necessary information about the metric model by using the interface description component (Fig. 1), "component description of metric"). This component contains for example the following input forms:

Figure 7 Metric Model One of the requirements of our framework is flexibility. Any moment, it is possible to add or modify the criteria of IS evaluation. These two operations require sometimes the addition of new metrics. The calculation of metric implies the notion of the metric variables (Mv). The Mvs are basic measurement functions extracted from IS or data collected by the designers. The majority of existent metric collection forces the user to write code to define each new metric. In our work, we chose to develop an approach allowing reducing the effort when adding news metrics. The idea consists in fact that an Mv is used in the calculation of one or more metric, and a metric can be used in the calculation of one or more other metrics. As Mvs are pre-implemented, the value of metric is obtained by the evaluation of its expression. It is necessary to write code when the calculation of a metric requires the definition of a new Mv. The user can enter all the necessary information about the metric model by using the interface description component (Fig. 1), "component description of metric"). This component contains for example the following input forms:

Related Figures (17)

Fig. 1. Structure of IS evaluation approach
Fig. 1. Structure of IS evaluation approach
The first step of our approach is to permit to the users to model their IS using for example RM-ODP. RM- ODP (reference Model-Open Distributed Processing) is a standardized modelling framework to describe 4 distributed application according to five viewpoints (ISO/IEC 1996), (ISO/IEC 1998), (Putman 2000): Enterprise (objective, business, rules), Information (data), Computational (functional decomposition) Engineering (communication and deployment) anc Technology (hardware and software infrastructure).
The first step of our approach is to permit to the users to model their IS using for example RM-ODP. RM- ODP (reference Model-Open Distributed Processing) is a standardized modelling framework to describe 4 distributed application according to five viewpoints (ISO/IEC 1996), (ISO/IEC 1998), (Putman 2000): Enterprise (objective, business, rules), Information (data), Computational (functional decomposition) Engineering (communication and deployment) anc Technology (hardware and software infrastructure).
2.2. The Evaluation Model
2.2. The Evaluation Model
Fig. 4.. The meta-model evaluation The evaluation model is a predictive model of quality; it makes it possible to identify the forces and the weaknesses of IS according to predetermined criteria. n our approach, the evaluation model is composed of hree parts: the quality model, the metric model and the metric-quality model. Before seeing in detail each of hese parts we will present the meta-model evaluation Fig. 4). In this meta-model a factor can be constituted by one or several criteria. Each criterion is measured hanks to metric. A metric can call variable metrics or another metrics. Each metric and variable metric is defined by a measurement function or procedure.
Fig. 4.. The meta-model evaluation The evaluation model is a predictive model of quality; it makes it possible to identify the forces and the weaknesses of IS according to predetermined criteria. n our approach, the evaluation model is composed of hree parts: the quality model, the metric model and the metric-quality model. Before seeing in detail each of hese parts we will present the meta-model evaluation Fig. 4). In this meta-model a factor can be constituted by one or several criteria. Each criterion is measured hanks to metric. A metric can call variable metrics or another metrics. Each metric and variable metric is defined by a measurement function or procedure.
In our approach, the quality model is presented in form of tree structure in which each factor can have one or more criteria. Each criterion can have one or more sub- criteria. Fig. 5. The tree structure of the Factors and Criteria model
In our approach, the quality model is presented in form of tree structure in which each factor can have one or more criteria. Each criterion can have one or more sub- criteria. Fig. 5. The tree structure of the Factors and Criteria model
The user can enter all the necessary information about the quality model by using the interface description component (Fig. 1, "component description of qualities"). This component contains for example the following input forms: n this example, one quality factor is defined: Portability. Because of the short lifespan of high performance computing platforms and because many applications are developed and run in a distributed heterogeneous environment, most parallel programmers will work on a number of platforms simultaneously or over time. Programmers are understandably reluctant to learn a new performance ool every time they move to a new platform. Thus, we consider portability to be an important feature. om ae 41 ar qe agape 41 ar 1
The user can enter all the necessary information about the quality model by using the interface description component (Fig. 1, "component description of qualities"). This component contains for example the following input forms: n this example, one quality factor is defined: Portability. Because of the short lifespan of high performance computing platforms and because many applications are developed and run in a distributed heterogeneous environment, most parallel programmers will work on a number of platforms simultaneously or over time. Programmers are understandably reluctant to learn a new performance ool every time they move to a new platform. Thus, we consider portability to be an important feature. om ae 41 ar qe agape 41 ar 1
In this example, the metric correspondents with the criteria extracted from the quality model of Fig. 4. In order to define this metric we based on the expression of availability of software given by Akoka (Akoka 2002).
In this example, the metric correspondents with the criteria extracted from the quality model of Fig. 4. In order to define this metric we based on the expression of availability of software given by Akoka (Akoka 2002).
The metric model (Fig. 7) is presented as follow:
The metric model (Fig. 7) is presented as follow:
Fig. 8. Availability metric model NYSerH = A number of operating hours of the software per year, NYFH = A number of hours when at least a function is not available, NYVitFH = A number of hours when at least a vital function is not available, NYTFH= A number of hours of total stop due to a failure, NYFH>= NYVitFH >= NYTFH
Fig. 8. Availability metric model NYSerH = A number of operating hours of the software per year, NYFH = A number of hours when at least a function is not available, NYVitFH = A number of hours when at least a vital function is not available, NYTFH= A number of hours of total stop due to a failure, NYFH>= NYVitFH >= NYTFH
We can find certain couples (Criterion, Mv) which have conflicts of interests as in the case of couples (Criterionl10, Mv2) and (Criterionl1, Mv2) of the
We can find certain couples (Criterion, Mv) which have conflicts of interests as in the case of couples (Criterionl10, Mv2) and (Criterionl1, Mv2) of the
Fig. 9. Quality Metric model implemented by using the metric_variable_ tradeoffs (MvT) algorithm. Given two metric_variables (Mv), Mv A and Mv B, the possible relationships between these two Mvs are as follows: 1) Neutral: An improvement to the Mv A is unlikely to affect the Mv B. 2) Direct: An improvement to the Mv A is likely to cause an improvement to the Mv B. 3) Inverse: An improvement to the Mv A is likely to cause a degradation to the Mv B.
Fig. 9. Quality Metric model implemented by using the metric_variable_ tradeoffs (MvT) algorithm. Given two metric_variables (Mv), Mv A and Mv B, the possible relationships between these two Mvs are as follows: 1) Neutral: An improvement to the Mv A is unlikely to affect the Mv B. 2) Direct: An improvement to the Mv A is likely to cause an improvement to the Mv B. 3) Inverse: An improvement to the Mv A is likely to cause a degradation to the Mv B.
Fig. 10. The meta-model scenario One of the objectives of our approach is to give to the expert the possibility of creating his/her own evaluation scenarios and of safeguarding them. The evaluation scenario is composed of three parts: the description of the scenario, the fuzzy interpreter and the interpretations. Before seeing in detail each of these parts we will present the meta-model scenario (Fig. 10). In the meta-model scenario, a scenario is composed of a set of qualities (quality scenario) to be evaluated and of a set of variables (scenario_variables). A comparison scenario can call upon one or more other scenarios. Each set of qualities can contain one or more factors and/or one or more criteria. Each set of variables can contain one or more metrics and/or one or more variable metrics. The result of each scenario is saved in (Scenario_ result).
Fig. 10. The meta-model scenario One of the objectives of our approach is to give to the expert the possibility of creating his/her own evaluation scenarios and of safeguarding them. The evaluation scenario is composed of three parts: the description of the scenario, the fuzzy interpreter and the interpretations. Before seeing in detail each of these parts we will present the meta-model scenario (Fig. 10). In the meta-model scenario, a scenario is composed of a set of qualities (quality scenario) to be evaluated and of a set of variables (scenario_variables). A comparison scenario can call upon one or more other scenarios. Each set of qualities can contain one or more factors and/or one or more criteria. Each set of variables can contain one or more metrics and/or one or more variable metrics. The result of each scenario is saved in (Scenario_ result).
Fig. 11. The architecture of the Interpreter The role of t he result to t ‘measuremen’ he Interpreter is to execute the scenarios already defined in the component "Interpreter" of Fig. . Once the execution is finished, the interpreter passes he component "Evaluation report" of Fig. 1. The Interpreter is composed of three different parts: ts", "fuzzy interpretation", and finally the part "interpre ations".
Fig. 11. The architecture of the Interpreter The role of t he result to t ‘measuremen’ he Interpreter is to execute the scenarios already defined in the component "Interpreter" of Fig. . Once the execution is finished, the interpreter passes he component "Evaluation report" of Fig. 1. The Interpreter is composed of three different parts: ts", "fuzzy interpretation", and finally the part "interpre ations".
Fig. 12. Memberships functions of the fuzzy variable Cll We will linguistically express the levels of validation of the quality factors, then to project them on [0,1] (Table. 5). Thus, fuzzy logic makes it possible to express this concept by allotting a degree of truth ranging between 0 and | (Fig. 12). Thus, the Cll criterion is very strong with a degree of truth of 0.45 and strong with degrees of truth of 0.50.
Fig. 12. Memberships functions of the fuzzy variable Cll We will linguistically express the levels of validation of the quality factors, then to project them on [0,1] (Table. 5). Thus, fuzzy logic makes it possible to express this concept by allotting a degree of truth ranging between 0 and | (Fig. 12). Thus, the Cll criterion is very strong with a degree of truth of 0.45 and strong with degrees of truth of 0.50.
Table. 8: Table of evaluation of the criterion "Partial unavailability" And if the user select the criterion “Partial unavailability Partial unavailability ={Vital unavailability, Full unavailability}. 3. Conclusions
Table. 8: Table of evaluation of the criterion "Partial unavailability" And if the user select the criterion “Partial unavailability Partial unavailability ={Vital unavailability, Full unavailability}. 3. Conclusions
Fig. 15. The model of the criterion "Portability" It remains to evaluate the factor "Portability", after having to evaluate all its criteria and sub-criteria. The result of the evaluation of the factor "Portability" is in the following form:
Fig. 15. The model of the criterion "Portability" It remains to evaluate the factor "Portability", after having to evaluate all its criteria and sub-criteria. The result of the evaluation of the factor "Portability" is in the following form:
Related topics:
Computer ScienceQuality Measures
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved