next up previous contents index
Next: Related Work Up: Usage Model Previous: Example   Contents   Index

Structure

The meta model for usage modelling in the PCM is described with more detail in the following (see Figure 3.34). A usage model consists of a number of usage scenarios. Each usage scenario is intended to model a use case of the system and the frequency of executing it. Thus, a usage scenario contains a Workload to model execution frequency and a ScenarioBehaviour to model a use case.

Figure 3.34: Usage Model: Scenario and Workload
Image UsageModel1

Modelling workloads in the PCM is aligned with performance models such as queueing networks [35] or stochastic process algebras [] as well as the UML SPT profile [36]. Therefore, open and closed workloads can be specified. An open workload models an unbounded (thus open) number of users entering the system with a specific inter-arrival time as a random variable (e.g., a new customer arrives each 0.5 seconds) and leaving the system after executing their scenario. A closed workload models a bounded (thus closed) number of users entering the system, executing their scenario, and then re-entering the system after a given think time, which can be specified as a random variable (see Section 2.6).

Figure 3.35: Usage Model: Scenario Behaviour
Image UsageModel2

Modelling scenario behaviours in the PCM (Figure 3.35) is similar to modelling resource demanding behaviours in SEFFs (see Section 3.2.9). However, SEFFs contain notions of resource usage, while the language for usage scenarios is reduced to concepts familiar to domain experts, and does not refer to resources.

ScenarioBehaviours contain a number of user actions. Within a scenario behaviour, the flow of actions can be described as follows: Each AbstractUserActions references at most one predecessor and one successor. StartActions initiate a scenario behaviour and contain only a successor, while StopActions end a scenario behaviour and contain only a predecessor. Notice, that the start and stop actions in the example above (Figure 3.33) follow this pattern.

Loops can be modelled to describe user actions that are repeated multiple times (e.g., searching for an item in a online store by repeatedly entering search terms, or repeatedly checking the latest status of an online auction). Loops over user service invocations are modelled with LoopActions, which are attributed with the number of iterations and contain inner ScenarioBehaviours to model loop bodies. These loop bodies may consist of multiple actions or even nested loops themselves. In the example (Figure 3.33), the browse action is called within a loop three times. It is additionally possible to specify the number of loop iterations with a probabilty distribution instead of a constant value to allow more fine-grained modelling (see Section 2.6).

Notice that the chain of user actions in a scenario behaviour must not contain cycles to model loops, i.e., an action referencing another action as its successor and predecessor. Instead, loops always have to be modelled explicitly with loop actions. This explicit modelling eases the later analyses, as it arranges actions hierarchically in a tree structure, which can be analysed by standard tree traversal algorithms.

Most often, users have multiple choices to continue their interaction with the system. For such cases, the usage model offers branch actions, which are able to split the user control flow with an XOR-semantic and allow different successors to a single user action. A probability of executing each branch transition can be specified. In the example (Figure 3.33), users first log in to the system and then have the choice to either search the shop with a probability of 40% or browse in the shop's catalog with a probability of 60%. BranchTransitions contain inner ScenarioBehaviours to model the content of a branch. With this kind of modelling, additional merge actions for reconnecting two branches are not needed, as the control flow continues with the successor of the branch actions once the end action of the the branched behaviour is reached. Forks of user behaviour (i.e., splitting the flow with an AND-semantic) are not allowed so far, as it is assumed that a single user only executes the services of the same system subsequently but not concurrently.

Besides these control flow constructs, actual service invocations to the architecture are modelled by EntryLevelSystemCalls. They refer to services in system provided roles (see Section 3.3.6), which are connected to component services directly visible to the users. Inner component services, which are only called by other components cannot be referenced from the usage model.


next up previous contents index
Next: Related Work Up: Usage Model Previous: Example   Contents   Index
Snowball 2007-03-16