Addressing the QoS drift in specification models of self-adaptive service-based systems

Abstract

Analysts elaborate precise and verifiable specification models, using as inputs non-functional requirements and assumptions drawn from the current environment studied at design time. As most real world applications exist in dynamic environments, recently there has been research efforts towards the design of software systems that use their specification models during runtime. The main idea is that software systems should endeavor to keep their requirements satisfied by adapting their architectural configurations when appropriated. Unfortunately, such specifications models use specific numbers (i.e. values) to specify non-functional constraints (NFCs) and may become rapidly obsolete during runtime given the drastic changes that operational environments can go through. The above may create circumstances when software systems are unaware that their requirements have been violated. To mitigate the obsolescence of specification models we have already proposed to use computing with words (CWW) to represent the NFCs with linguistic values instead of numbers. The “numerical meanings” of these linguistic values are computed from the measurements of non-functional properties (NFPs) gathered by a monitoring infrastructure. This article introduces the concept of “QoS-drift” to represent a significant degree of change in the “numerical meanings” of the linguistic values of the NFPs in the service market. We add to our former proposal a QoS-drift's vigilance unit to update linguistic values only when a QoS-drift is detected. Therefore, the new models are proactive and automatically maintained, what results in a more efficient assessment of run-time requirements' compliance under non-stationary environments. We validate the effectiveness of our approach using (1) a service market of 1500 services with two NFPs, (2) a synthetical QoS-drift and, (3) five systems built by different service compositions. We have detected that four of the five systems experienced requirements violations that would not have been detected without the use of our approach.