In software engineering---like any engineering discipline---design is the activity that allows engineers to invent a solution to a problem. The input to the design activity consists of various requirements and constraints. The result of a design activity is a solution in which all major architectural and technical problems have been addressed. Design is an important activity since it allows engineers to invent solutions stepwise and in an organized manner. It makes engineers consider solutions and trade various system functions against each other.
To be useful, computer systems must deliver a certain quality of service
(QoS) to its users. By QoS, we refer to non-functional properties such as performance, reliability, availability, and security. Although the delivered QoS is an essential aspect of a computer system, traditional design methods, such as [,,,,], do not incorporate QoS considerations into the design process. We strongly believe that, in order to build systems that deliver their intended QoS, it is essential to systematically take QoS into account at design time, and not as an afterthought during implementation.
Figure: Class diagram for the currency trading system
We use a simple example to illustrate the need for design-time QoS considerations. Consider the currency trading system in Figure 1 . Currency traders interact with the trading station , which provides a user interface. To provide its functionality, the trading station uses a rate service and a trading service . The rate service
provides rates, interests, and other information important to foreign exchange trading. The trading service provides the mechanism for making trades in a secure way. An inaccessible currency trading system might incur significant financial loss, therefore it is essential that the system is highly available.
It is important, at design time, to decide the QoS properties of individual system components. For example, we need to decide the availability properties of the rate service . We can decide that the rate service should be highly available so that the trading station can rely exclusively on it for rate information. Alternatively, we can decide that the rate service need not be highly available. If the rate service is not highly available, the trading station
cannot rely exclusively on it, but must be prepared to continue operation if the rate service fails. To continue operation, the trading station could connect to an external rate service. As the example shows, different availability properties for the rate service can result in different system architectures. It is important to decide on particular QoS properties, and thereby chose a specific architecture, at design time.
Besides the system architecture, the choice of QoS properties for individual components also affects the implementation of components. For example, the rate service can be implemented as a single process or as a process pair, where the process-pair implementation provides higher availability. Different QoS properties are likely to require different implementations. Moreover, the QoS properties of a component may affect the implementation of its clients. For example, with a single-process implementation, the trading station may have to explicitly detect failures and restart the rate service , whereas with a process-pair implementation, failures may be completely masked for the trading station .
In the previous section we argued that QoS properties of individual components reflect important design decisions, and that we need describe these QoS properties as part of the design process. To capture component-level QoS properties, we introduce a language called QML (QoS Modeling Language).
Consider the CORBA IDL [] interface definition for the rate service in Figure 2 .
Figure: The RateServiceI
interface
A rate service provides one operation for retrieving the latest exchange rates with respect to two currencies. The other operation performs an analysis and returns a forecast for the specified currency. The interface definition specifies the syntactic signature for a service but does not specify any semantics or non-functional aspects. In contrast, we concern ourselves with how to specify the required or provided QoS for servers implementing this interface.
QML has three main abstraction mechanisms for QoS specification: contract type , contract , and profile . QML allows us to define contract types that represent specific QoS aspects, such as performance or reliability. A contract type defines the dimensions that can be used to characterize a particular QoS aspect. A dimension has a domain of values that may be ordered. There are three kinds of domains: set domains, enumerated domains, and numeric domains. A contract is an instance of a contract type and represents a particular QoS specification. Finally, QML profiles associate contracts with interfaces, operations, operation arguments, and operation results.
Figure: Contracts and Profile for RateServiceI
The QML definitions in Figure 3 include two contract types Reliability and Performance . The reliability contract type defines three dimensions. The first one represents the number of failures per year. The keyword ``decreasing'' indicates that a smaller number of failures is better than a larger one. Time-to-repair ( TTR ) represents the time it takes to repair a service that has failed. Again, smaller values are better than larger ones. Finally, availability represents the probability that a service is available. In this case, larger values represent stronger constraints while smaller values represent lower probabilities and are therefore weaker.
We also define a contract named systemReliabilty
of type Reliability
. The contract specifies constraints
that can be associated with, for example, an operation. Since the
contract is named it can be used in more than one profile. In this
case, the contract specifies an upper bound on the allowed number
of failures. It also specifies an upper bound, a mean, and
a variance for TTR
. Finally, it states that availability
must always be greater than 
.
Next we introduce a profile called rateServerProfile that associates contracts with operations in the RateServiceI interface. The first requirement clause states that the server should satisfy the previously defined systemReliability contract. Since this requirement is not related to any particular operation, it is considered a default requirement and holds for every operation. Contracts for individual operations are allowed only to strengthen (refine) the default contract. In this profile there is no default performance contract; instead we associate individual performance contracts with the two operations of the RateServiceI interface. For latest we specify in detail the distribution of delays in percentiles, as well as a upper bound on the mean delay. For analysis we specify only an upper bound and can therefore use a slightly simpler syntactic construction for the expression. Since throughput is omitted for both operations, there are no requirements or guarantees with respect to this dimension.
We have now effectively specified reliability and performance requirements on any implementation of the rateServiceI
interface. The specification is syntactically separate from the interface definition, allowing different rateServiceI
servers to have different QoS characteristics.
QoS specifications can be used in many different situations. They can be used during the design of a system to understand the QoS requirements for individual components that enable the system as a whole to meet its QoS goals. Such design-time specification is the focus of this paper. QoS specifications can also be used to dynamically negotiate QoS agreements between clients and servers in distributed systems.
In negotiation it is essential that we can match offered and required QoS characteristics. As an example, satisfying the constraint ``delay < 10 msec'' implies that we also satisfy ``delay < 20 msec.'' We want to enable automatic checking of such relations between any two QoS specifications. We call this procedure conformance checking , and it is supported by QML.
QML allows designers to specify QoS properties independently of how these properties can be implemented. For example, QML enables designers to specify a certain level of availability without reference to a particular high-availability mechanism such as primary-backup or active replication.
QML supports the specification of QoS properties in an object-oriented manner; it provides abstraction mechanisms that integrate with the usual object-oriented abstraction mechanisms such as classes, interfaces, and inheritance. Although QML is not tied to any particular design notation, we show how to integrate QML with UML [], and we provide a graphical syntax for component-level QoS specifications.
QML is a general-purpose QoS specification language; it is not tied to any particular domain, such as real-time or multi-media systems, or to any particular QoS category , such as reliability or performance.
We organize the rest of this paper in the following way. In Section 2, we introduce our terminology for distributed object systems. We present the dimensions of reliability and performance that we use in Section 3. We describe QML in Section 4, and we explain its integration into UML in Section 5. We use QML and the UML extensions to specify the QoS properties of a computer-based telephony system in Section 6. The topic of Section 7 is related work, and Section 8 is a discussion of our approach. Finally, in Section 9, we draw our conclusions.