var=”variable whose value is being measured”, x &

(Abbreviations: var=”variable whose value is being measured”, x & y = “the (upper or lower) bound on the value of var”, res = “the actual value of var obtained from simulation results”, sat = “satisfied”, p.sat = “partially satisfied”, p.unsat = “partially unsatisfied”, !def(res) = “res is undefined”)

notation, viz.: constraint symbols can only link to one softgoal. What if multiple constraints link to the same goal, having different levels of satisfaction? One option is to extend normal SIG reasoning techniques to handle this situation. This is open to further research.

3.4.3 Initial Simulation, Results and Analysis

For the Current, Peak and Olympic workloads, using the estimated arrival rates and initial configuration discussed earlier, the first simulation experiment shows a very small, constant processing time and cost per request as shown in Table 7 and Fig. 7. For the !!Fast[response times] softgoal alone, this is a good thing. But, considering other goals, this is unlikely to lead to a fair system for all stakeholders. Annual Cloud Computing costs grow too quickly (cost as percentage of revenue is almost constant) as a 1-to-1 VM to request mapping is used (see iteration 1, Table 7 and Requests per minute and VM Usage graph, Fig. 7). The updated Agent-SIG in Fig. 8 indeed shows that multiple goals in the system have indeed been sacrificed in order to satisfice the critical performance softgoal while the Agent-SIG in Fig. 9 shows which stakeholders’ goals is (un)met. Steps taken to improve this initial design are discussed next.