In the previous section, we identified different input factors of the provided QoS of the same component in various contexts. In order to cope with these factors, we model a component's context explicitly as described in sections 3.3.3, and 3.4.5. Tabular 2.1 summarizes the attributes of our context model.
T>[gray]0.8c
|
We arrange the tabular according to two dimensions. One is dividing the attributes into ones that have to be specified during the design process and such that can be computed or predicted using the former ones. The other dimension divides the properties according to the roles of the development process that specify them: Software architects, deployers, and domain experts. While functional properties of the architecture can already be analysed on the basis of the system assembly, since only components and their connections are required to perform interoperability checks [13] or to evaluate parametric contracts [14], extra-functional attributes require additional information on the execution environment and usage of the system.
The deployer needs to specify the underlying hardware (CPU speed, cache sizes, available memory, available bandwidth, ) and system software (details on the used middleware, virtual machines, container configurations,
).
The domain expert specifies probabilities for calling specific services, probability distributions on the actual parameter characteristics, or the request arrival rates. Using this information, it is possible to estimate QoS properties, like the actual execution time of a service on the specified runtime environment considering the specified usage profile.
However, it depends on the capabilities of the analytical method, which information has to be specified and which QoS metrics can be derived.