Costes por secciones

The following derives an estimate of the time complexity of a simulation run. It iden- tifies the factors which influence the length of simulation runs. An important aspect in this context is the accuracy needed by the software architect. As the PCM’s aim is to support selecting between competing design alternatives, the software architect needs a prediction sufficiently accurate for this.

How long it takes to reach a sufficient accuracy, depends on several factors. First, the differences in the results for the respective design alternatives are important. If the alter- natives show large differences in their performance, this is usually visible in simulation results after short simulation times. Second, the complexity of the input model is impor- tant. More components having more SEFFs or workloads with larger numbers of users

extend the state space of the simulation model significantly. Third, the simulation’s stop condition makes a difference. If stop conditions based on confidence intervals and point estimators are used, it may take a long time to reach that confidence level. Opposed to that, using an upper simulation time limit or a predefined number of samples of the re- sulting distribution function, may yield faster results which are not as accurate. Fourth, the complexity of the result distribution function has an impact. The larger the range of this function is, the longer it takes to simulate a given single case at least once. The following elaborates on the second and third factor as they are under the control of the software architect.

For SimuCom the most expensive basic operations are to draw samples for random variables and to generate and process events in the underlying event-based simulation framework. The number of random variables to draw depends on the upper bound of the number of probability function literals npf lin all stochastic expressions and the number of

probabilistic branches npbfor a single UsageScenario. The complexity class for the number

of random variables rv needed in a single simulated control flow thread when neglecting the time needed for the scheduling algorithm in the simulated resources is Orv(npf l+ npb).

Note, that npf l and npb may depend on other structures, especially loops or external

service calls in loops. As loops are simulated, the amount of iterations in the simulation is equal to the amount of iterations specified in the input model. As a consequence, the amount of probability function literals to evaluate or probabilistic branches needs to be multiplied by the loop iteration count for all occurrences of these objects in loop bodies. However, due to the PCM’s abstraction many loops in the software are not part of the RD- SEFF as loops which are part of the modelled component become a single InternalAction in the RD-SEFF. For example, a bubble sort algorithm which usually consists of two loops can be replaced by an InternalAction having a resource demand which reflects bubble sort’s complexity of approx. n2

2 . However, the precondition for this is that there is no

external service call in the modelled loop body. Nevertheless, in general, arbitrary control flow structures can be modelled using the RD-SEFF. Potentially, any number of loops can be nested in a PCM instance, leading to large polynomes for the number of random variables to draw.

For every ParametricResourceDemand in every control flow thread two events are gen- erated (cf. section 4.4.3): one for rescheduling the next finished job and one if the job has been processed finally. Let nprd be the upper bound of ParametricResourceDemands

caused by executing a single UsageScenario and u be an upper bound on the number of concurrent users in the simulated system. Again, nprd also depends on the loop struc-

ture of the model as explained in the previous paragraph. Then the number of events needed for this scenario falls in the complexity class Oev(nprd∗ u). Taking the number of

users into account the complexity class for the number of random variables rv to draw is Orv((npf l+ npb+ nprd) ∗ u).

Finally, the number of repetitions for the stochastic experiment where each user ex- ecutes his scenario once is determined by the simulation stop condition. Let m be the number of repetitions, then the overall simulation run time is of complexity class

O(m ∗ (u ∗ (npf l+ npb+ nprd)))

The stop condition is in many simulations the factor which can be modified easily. SimuCom currently contains two stop conditions: a basic condition which is independent from the input model and which stops the simulation as soon as a given maximum sim- ulation time is reached by the simulation and second a more advanced condition which stops depending on the confidence interval of the mean value estimator of the overall passage time sensor. Additional stop conditions, for example those given by Page and

Kreutzer(2005), may be supported in future implementations.

The experiences gained in modelling and simulating the examples given in section 5

showed that the simulation time is not a major issue for small to medium sized system models. They take approx. 5 minutes with up to 200 simulated users on a recent computer to get a distribution function which does not change any more significantly, i.e., sufficient for choosing a design alternative, compared to running the simulation for a longer time. Even a larger model like the PCM model of CoCoME (Krogmann and Reussner,2008) re- turns a result in 5-10 minutes which is sufficient for early design time analyses. However, a case study with larger industry style models is still missing (cf. section6.3).