next up previous contents index
Next: Component Assembler Up: Resource Demanding Service Effect Previous: Control Flow   Contents   Index


Parametric Dependencies

A major problem for component developers is that during component specification it is unknown how the component will be used by third parties. Thus, in case of varying resource demands or branch probabilities depending on user inputs, component developers cannot specify fixed values. However, to help the software architects in QoS predictions, the component developer can specify the dependencies between input parameters and resource demands, branch probabilities, or loop iteration numbers in SEFFs. If an usage model of the component has been specified by business domain experts or if the usage of the component by other components is known, the actual resource demands and branch probabilities can be determined by the software architect by solving the dependencies. In the following, examples for the specification of parametric dependencies in the PCM will be illustrated. Note that as a concrete syntax a more easily readible UML-based notation is used for the examples instead of the abstract syntax.

As the first example (Figure 3.22), the ResourceDemandingSEFF of the service HandleShipping from an online-store component is depicted. It has been specified by a component developer in a parametrised form. The service calls required services shipping a customer's order with different charges depending on its costs, which it gets passed as an input parameter. If the order's total amount is below 100 Euros, the service calls a service preparing a shipment with full charges (ShipFullCharges). If the costs are between 100 and 200 Euros, the online store grants a discount, so ShipReducedCharges is called. Orders priced more than 200 Euros are shipped for free with the ShipWithoutCharges service.

Figure 3.22: Branch Condition Example
Image dependency1

Once a domain expert specifies the value of the parameter costs, it can be derived which of the services will be called.

The second exmample (Figure 3.23) illustrate assigning a number of iterations to a loop in a parameterisable way. The illustration shows the ResourceDemandingSEFF of the service UploadFiles. It gets an array of files as input parameter and calls the external service HandleUpload within a loop for each file.

Figure 3.23: Loop Example
Image dependency2

With the specified dependency to the number of elements in the input collection, the probability distribution of random variable $ X_{iter}$ for the number of loop iterations in the ResourceDemandingBehaviour can be determined once the number of elements are known. If the dependency had not been specified, it would not have been known from the interfaces how often the required service would have been called. Thus, with the specified PMF, a more refined prediction can be made for varying usage contexts.


next up previous contents index
Next: Component Assembler Up: Resource Demanding Service Effect Previous: Control Flow   Contents   Index
Snowball 2007-03-16