ising Stability
In this section, we discuss our multi-dimensional perspective for characterising and engi- neering stability as a software property.
3.3.1
Dimensions of Stability
While we believe the literature covered important aspects of stability which are scattered, we argue that a multi-dimensional pragmatic view is required to offer a systematic way for practitioners and researchers to deal with stability as a software property. We integrated the taxonomy dimensions (section 2.5) to create a pragmatic view for stability, as shown in Figure 3.1.
Considering this view could help the community to identify the dimensions ignored in the literature and motivate possible research directions. Also, rather than thinking in an isolated manner about stability, we should be looking for methods and tools to explore inter-dependencies between the different dimensions throughout the software lifecycle for a more integrated thinking to achieve software longevity.
Figure 3.1: Dimensions of Stability as a Software Property
3.3.2
Engineering Stability as a Software Property
Our engineering proposal, illustrated in Figure 3.2, is based on the proposed working def- inition for the concept of stability, where we consider the different dimensions (5W+1H) of the taxonomy (section 2.5). Engineering stability as a software property requires ad- dressing the following issues:
• Stability analysis. As stability is not an absolute property and given its different dimensions, this requires further case- and context-dependent analysis. Such analy- sis should depend on the system in question, its architecture, the variables subject of interest (e.g. behavioural attributes that should be kept stable) and the system context (i.e. contextual aspects influencing the system and its stability). By the system in question, we mean the type of application and/or the software domain
Figure 3.2: Engineering Stability as a Software Property
that determine the associated dynamics and contextual aspects, while the architec- ture type determines the aspects that should be kept stable. As an example, in the case of adaptive architectures, the behaviour of the adaptation controller would be considered in the stability analysis.
• Integration in the different lifecycle phases. The integration of stability in the differ- ent phases would render strategic benefits throughout the software lifetime. We ar- gue that the realisation of stability in the different phases is complementary. A good realisation plan should, for instance, include evaluating architecture alternatives for long-term evolution and defining runtime adaptation policies in advance, which will ease the evolution process in the long-term and render stable runtime adaptation actions. Meanwhile, putting the architecture in operation with less design-time planning for stability will degrade the architecture performance during runtime. Though stability analysis could be foundational, engineering practices should be distinct for each phase. During the design phase, a candidate architecture should be evaluated by the ability of its structure (structural stability) to maintain fulfilling the functional and behavioural requirements that are known at this stage, as well as the likely changes to occur in the future when put into operation (functional and behavioural stability). While the software is operating, the architecture ability to fulfil the changing requirements and workloads (behavioural requirements) should
be continuously assessed during runtime. The evaluation of architecture alternatives during the design phase is evidently different from the retrospective evaluation for evolution planning. Runtime evaluation approaches can vary between online and offline techniques.
• Integration in the different software artefacts.
– Design and architecture. As architectures typically play a key role in achiev- ing quality requirements [319] [63] [377] [378] and guiding the software evo- lution [17] [117], we can evidently agree that realising stability at the design and architecture levels should be based on the quality requirements subject to stability [319] [378] [379], where requirements are the key to long-term stability and sustainability [215] [380]. In other words, the outward requirements goal is concerned with what the system will accomplish for its end-users [61], which will be achieved by the architecture.
– Requirements engineering. Realising stability should start in an earlier stage prior the design, i.e. in the requirements engineering phase [4], where qual- ity requirements are assessed throughout the architecture’s lifespan and will be used in informing architecture decisions, so that the architecture will not break-down easily when coping with increased runtime load demands or evo- lution [381] [19]. Hence, a “behaviourally stable” architecture design should be based on the requirements subject to stability. Requirements engineering for stability will help in capturing and analysing the quality attributes sub- ject to stability while building stable architectures. Such requirements subject to stability should be modelled as goals at an abstract level, then technically fine-grained to be allocated to single specific components [382] [383]. Explicit relation between the requirements model and the architecture should also be present to consider the architectural stability [384] [381] [385] [39]. As runtime requirements engineering has the main role in monitoring the satisfaction of requirements during runtime [386], they should explicitly consider stability at- tributes, their dynamic traces to architecture components, and the historical information related to the fulfilment of these attributes. The link between the requirements and architecture during runtime should be explicit and symbi- otic. From the requirements side, if the architecture will change/adapt in light of the changing requirements, this will ensure fulfilling the changing runtime requirements. From the architecture side, this will ensure that the architec- ture will have the expected behaviour, avoiding performance degradation and phasing-out.
• Contextual aspects influencing architectural stability. Dealing with stability should be associated with the contextual aspects of the system, which should be tackled in the different engineering practices during design-time and runtime. This includes changes and uncertainty. Practices should be moving towards a new era, where architectures are considered in the environment of unpredictability. Designing and evaluating under the unknown should benefit from the information value [387] to evaluate the risk, value perception and quantify the unpredictability.
– Changes. Changes have been classified by timing: (i) short-term, dynamic changes in the system or requirements, (ii) medium-term, reconfigurations for maintenance, and (iii) long-term, radical changes, reconfigurations and reor- ganisations for evolution [141]. Changes differ also in their nature, they could be functional changes, quality requirements changes, operational (changing behaviour of a service component when sharing resources) and technological (either software or hardware) [141]. Different types of changes are affecting the architectural stability at the different time phases and should be handled. For instance, architects should consider the long-term evolutionary changes when designing architectures for stability. In designing adaptive architectures, it is important to capture the possible changes that will drive adaptations [388]. Dealing with the operational and behavioural aspects of stability, architects should also cater to the runtime changes in user and quality requirements. Evaluating adaptation decisions during runtime would require estimating pos- sible future changes, in order to avoid unnecessary frequent adaptations. – Uncertainty. Modern complex systems exhibit uncertainty from many sources,
arising from the heterogeneity and dynamism of both the system itself and the operating environment [329] [22] [23]. Runtime uncertainty is associated with changes in workload [168], runtime requirements [389] [390] and the nature of the software paradigm. As an example, considering the cloud paradigm, that offers pay-per-use service for the end-users, the architecture exhibits a high de- gree of uncertainty in the workload received from different users with different SLAs. In the case of adaptive and self-adaptive software, added the uncer- tainty arising from the effect of the adaptation actions [391] [392]. Although major advances have been made for handling uncertainty, existing works do not systematically address the stability of the architecture notwithstanding uncertainty. Requirements engineering should consider the uncertainty asso- ciated with the requirements subject to stability according to the stability purpose, which will be passed to the architecture design phase. Evaluating architectures (and their adaptations) during runtime should consider how sta- bility will be affected by any form of uncertainty. This could be done either online or offline. Like other quality attributes (e.g. reliability, robustness and resilience) [393], sensitivity analysis for parameters of the probabilistic quality models is needed for the stability of these attributes. Online evaluation ap- proaches should consider the stability of the architecture decisions and relate their evaluation results to the online autonomous architectural decisions.