next up previous contents index
Next: Structure Up: Parameter Model Previous: Motivation   Contents   Index

Example

Before describing the parameter model in detail, two short examples are shown in Figure 3.36 to give the reader a feel for the modelling capabilities. These examples extend certain actions from the usage model example in Figure 3.33 with parameter characterisations.

Figure 3.36: Parameter Characterisation Examples
[] Image UsageModelExample_Par1 [] Image UsageModelExample_Par2

Example 3.12   In Figure 3.36(a), a parameter 'searchTerm' has been introduced to the 'Search' action. The Parameter class of the PCM enables specifying a name and a data type (not shown here) for a parameter. Thus, it includes only information about the formal parameter. The actual parameter, i.e., the value a parameter takes when the service is actually called, can be characterised with a VariableUsage. In this case, the parameter is a string, which is the name of the item to be searched for. The database is assumed to contain 40 items. The domain expert has characterised the value of the input parameter and has specified a probability distribution for the search terms users pass to the service. Therefore, the domain expert has divided the input domain of the service into four subdomains (item1-10, item11-20, item21-30, item31-40) to reduce the modelling effort, and has provided probabilities for each of these subdomains. If the behaviour of the component service changes depending on which item is searched for (e.g., because of calling different databases), this can be included in the performance prediction, because the parameter has been characterised.

Example 3.13   In Figure 3.36(b), an array 'listOfItems' is passed to the 'BuyItems' action. The domain expert has not characterised the value of this array, but just the number of elements it contains. It is a suitable abstraction of the parameter in this case, because the value of the array is not relevant in this example. The service 'Buy Items' calls required services for each item in the array (not shown here because this is part of the service's SEFF and not the usage model), so that the number of elements in the array is sufficient for the performance predictions, as it is directly related to the number of loop iterations in the SEFF of this service. The number of elements is specified as a probability distribution, so that the loop is iterated with the same probability distribution.


next up previous contents index
Next: Structure Up: Parameter Model Previous: Motivation   Contents   Index
Snowball 2007-03-16