Operations and Scoped Relations Used

A Scoped relationship is used to select specific instances of a class to be used. In Figure4.6 is a simple example of a scoped relation in a meta-model. A Shopper can only shop items that are available in the Shop where he is shopping. Therefore, the shopItem relation is scoped by the shop relation.

Figure 4.6: An example of how Scoped can be used

In Figure 4.7 is the Ecore tree view of the Shopper example meta-model in Fig 4.6. The ext

annotation with the scoped keyword ’binds’ the scoped constraint (which is pre-programmed in the Altran EcoreExt plugin) to the Shopper class. Since the shopItem relation is scoped by the shop relation, there must be an EAnnotation added to the shopitem reference within the Shopper class. The Ecore EAnnotation indicates which constraints to check for the class. This is a list of constraints, where scoped needs to be added, to have the scoped constraint be evaluated for the Shopper class.

This is made possible by a plugin provided by Altran that enables Ecore to handle such scoped relations. In the following part is explained how the scoped relation is present in various relations in the assessment meta-model.

Presented in Figure 4.8 is the Ecore tree view of the scoped relations used in the assessment meta-model.

Figure 4.7: The Ecore view of the Scoped Shop example

Figure 4.8: The Ecore view of the Scoped relation in the AssessmentPracticeContribution class

AssessmentPracticeContribution class

The relation practice in AssessmentPracticeContribution is scoped by practicegroup in Assessment-GroupDefinition, as indicated in Figure4.8. The scoped relation is used in this class to select from the Specific Practices that have been defined in the standard at the previous level meta-model. In Figure4.9, on the left is the CMMI standard, defined in an instance of the standards meta-model, and on the right hand side is an instance of the assessment meta-model where an assessment has been defined. Only the practices that have been defined in the instance of standard, within the Goal PPQA SG1, can be selected as Practices, in the instance of assessment.

Figure 4.9: A run-time instance of assessment showing the scoped relation being used for the element AssessmentPracticeContribution

AssessmentGroupDefinition class

The scoped relation is used in this class, as shown in Figure4.10, to select from the Practice Groups that have been defined in the standard at the previous level meta-model. The practicegroup in AssessmentGroupDefinition is scoped by the reference

• genericpracticegroups in the concrete subtypes of: GenericPracticeGroupReference (Assess-mentProductCharacteristic or AssessmentProcessGroup)

• process in the AssessmentProcess

In Figure4.11 on the left is the CMMI standard, defined in an instance of the standards meta-model, and on the right hand side is an instance of the assessment meta-model where an assessment has been defined. Only the goals/ practice groups that have been defined in the instance of standards within the Process Service Delivery , can be selected as PracticeGroups, in the instance of assessment.

Figure 4.10: The Ecore view of the Scoped relation in the AssessmentGroupDefinition class

Figure 4.11: A run-time instance of assessment showing the scoped relation being used for the element AssessmentGroupDefinition

In the following part is explained the calculation operations in the Scoring and ScoreAverage classes:

Scoring class

The Scoring class has two operations:findAssessmentPracticeContribution and findMeasurement, which are explained later in this chapter. The body of both these operations are ’null’, to be later overridden in the actual meta-model, as shown in Figure4.13.

Figure 4.12: The Scoring class in assessment in the Ecore tree editor

Figure 4.13: The Scoring class and its overridden form in the actual meta-model In the Scoring class are 3 EStructuralFeatures (as seen in Figure 4.12) :

• measurement - This is an Eattribute of Etype AssessmentPracticeContribution

• assessmentcontribtion - This is an EReference of Etype Measurement

• score - This is an EReference of Etype Score

The score is calculated from the satisfactionLevel of a Measurement and the consequence level of an AssessmentPracticeContribution. Finding the relevant Measurement and the relevant assess-mentcontribution depends on where the concrete sub-types of Scoring reside in the meta-models.

Therefore, in the actual meta-model, the body of the findMeasurement() and findAssessmentPrac-ticeContribution() operations need to be redefined (or even: can only be defined in the concrete Scoring sub-types in Actual.

Figure 4.14: The Value of Score contained within the Pivot of Score in the Scoring class of assessment

In Figure 4.14 can be seen how the Score is calculated for individual practices, using OCL syntax. The value is calculated using ConsequenceLevel and SatisfactionLevel, in accordance with the Altran scoring matrix in Figure2.6.

ScoreAverage class

Figure 4.15: The ScoreAverage class in assessment in the Ecore tree editor In Figure4.15, can be seen the different functions in the class.

In the body of the findRelevantScores() function is Sequence which is a pre-defined collection type in OCL. This function has Etype Score. Essentially, this function is responsible for finding relevant scores of from which the average score value has to be calculated. It has two uses, depending upon the context:

• To find which scores to consider, while calculating individual process scores.

• To find which scores to consider, while calculating the overall process assessment score.

This will be elaborated upon further in Section 4.5.2.

Next, the convertScore() function has an EParameter called inputScore of Etype Score (which has previously been defined in the meta-model). This function is to convert individual practice scores from Etype Score to Etype Eint or integers. The body of the function to understand how it works can be seen in Figure4.16

Figure 4.16: The body of the convertScore function

Next is the calculateScoreAverage() function. As the name suggests, this one is used to calculate the average score value, and it uses the convertScore function to convert the relevant scores first to integers. The body of the function, written in OCL can be seen in Figure 4.17. This is the default calculation of this function.

Figure 4.17: The body of the calculateScoreAverageValue function

In Figure4.18, can be seen two views, on the left and right. They are the assessment and actual meta-models respectively, in the Ecore tree view. In the final, third level meta-model, the Assess-mentScore and AssessmentProcessScore classes are specializations (children) of the ScoreAverage class. Due to this, they inherit the functions of the class. In the figure, can be seen how the bodies of both the functions are overridden in the actual meta-model, as indicated by the red arrows.

There is a difference in calculation between the AssessmentProcessScore, averaging the indi-vidual scores (using the default calculation of calculateScoreAverageValue() function), and the AssessmentScore, which averages the AssessmentProcessScores, requiring redefinition of the cal-culateScoreAverageValue() body.

This will be elaborated upon more in the following sections, once the actual meta-model and its classifiers have been explained.

Figure 4.18: The ScoreAverage class and its overridden form in the actual meta-model