Quality of Service and AOP in Font

Drawer Data Matrix 2d barcode in Font Quality of Service and AOP

ince computing capacity follows the famous Moore s law, software limits are constantly being pushed back, and applications are becoming increasingly more complex. This complexity has to be managed and controlled because it can induce shortcomings and failures that can impact the application s Quality of Service. Quality of Service is a broad topic that covers several complex issues. In this chapter, we will not enter into the details of the topic, but we will focus on techniques that help to ensure that the functions implemented by the application are correctly defined and executed. These techniques can be seen as a first step toward more complex Quality of Service issues. Several techniques can be used to manage the complexity of an application. This chapter introduces three complementary techniques, all of which can be improved by using AOP: Design by Contract: This design methodology aims to formalize the constraints that are linked to the use of classes. The principles of Design by Contract are far from being integrated into languages; they can, however, be implemented by using AOP. Coverage Analysis: This technique checks for completeness through the implementation of sound test cases and nonregression tests, which check whether the functions that are related to an implementation change are still behaving according to the initial specification. These tests can use the AOP code-instrumentation capabilities to better watch over the application s executions. Administration and Supervision: This technique keeps track of the running application in order to prevent incidents or repair failures. With AOP, the Administration and Supervision functions can be easily separated from the rest of the application.

Design by Contract is a design methodology that consists of formalizing the use of application components. To do this, a number of logical constraints must be specified and checked by the components to guarantee that their behavior is consistent with their specifications. Design by Contract concepts were popularized by Bertrand Meyer in his book, ObjectOriented Software Construction, Second Edition (Prentice Hall, 1997). Contracts were used in a number of languages, such as Eiffel, as early as 1985. AOP provides the basic techniques to efficiently implement Design by Contract. Before detailing the AOP implementation of Design by Contract, we will first explain the main principles of this methodology in the Java context.

Most languages basic consistency-control mechanisms, such as type checking, are not sufficient to ensure that a given class is properly used by a client program. The consistency of an instance state with a method call or result necessitates the use of a more evolved concept contracts. By implementing contracts, an application benefits in the following ways: Testing and debugging is improved. Contracts allow the strict definition of execution conditions. Documentation and reusability are improved. Contracts are clearly materialized in the component code or interface. The contracts can be taken into account to help avoid mistakes when a component is reused. Error handling is improved. When a contract is not fulfilled, the initial error can be more easily identified, and strategies can be implemented to overcome the problem. Languages supporting Design by Contract can usually activate or deactivate the contracts at compile time or at run time to improve performance. Note that contracts may be of different natures, but they are not meant to replace any kinds of tests, such as security-related tests. This is so even though some of these tests might then become redundant and possibly be removed from the test suite.

A software-level contract can be compared to a legal contract. In a contract, there are typically two contracting parties (the contractors). In software, the two contractors are a user component and a provider component. A contract also defines an object, which defines what kind of relationship is materialized between the two contractors. In addition to the contractors and the object, a contract must also define mutual obligations, which regulate how the two contractors realize the object of the contract. In software, these obligations are defined through assertions.

Definition Assertion A logical Boolean expression that must be true at a given point in the program s