Dynamic Evolution and Reconfiguration of Software Architectures Through Aspects

Abstract

Change is an intrinsic property of software. A software system, during its lifetime, may require several updates, improvements, or new features. If these change requirements are not addressed, the risk of becoming a useless system increases. In fact, this is a challenging issue of safety-and mission-critical software systems, which cannot be stopped to perform maintenance or evolution operations due to their continuous operation. To reduce the aging of these critical systems, they must be provided with mechanisms enabling their dynamic evolution, i.e. the support of changes on their structure and behaviour while they remain in operation.This thesis is concerned with the design of a framework to build architecturebased, dynamically evolvable, software systems. The fact that this framework is a software architecture based approach provides the following advantages: (i) it offers a high-level of abstraction for describing dynamic changes; (ii) it allows varying the level of system description; and (iii) it advantages from the existing support for system modelling, code-generation, and formal analysis provided by architecture description languages.The framework presented in this thesis, called Dynamic PRISMA, is characterized by the combination of two levels of dynamism: Dynamic Reconfiguration, which addresses changes at the configuration level (i.e. the architectural configuration), and Dynamic Type Evolution, which addresses changes at the type-level (i.e. the specification of architectural types and instances). This combination is one of the major contributions of this thesis: thus a system is not only able to reconfigure at runtime the building blocks it is composed of (i.e. architectural types), but also to redefine these building blocks (or introduce new ones) at runtime.Another contribution of the thesis is the identification of the concerns related to dynamic evolution and their integration in the framework through aspects. This improves the separation of concerns and allows us to change reconfiguration specifications, evolution mechanisms, or the business logic independently of each other.A third contribution of this thesis is how this dynamism is supported: reconfiguration through autonomic capabilities, which provides proactivity according to either internal or external stimuli; and type evolution through asynchronous reflection, which enables the modification of a type specification and the transformation of their instances at different rates (i.e. when they are ready for evolution). Specifically, the asynchronous evolution vi semantics is precisely described by means of graph transformations. This formalism has been chosen because it naturally models both the system architecture and its asynchronous evolution.The work presented in this thesis is illustrated through a case study from the robotics domain; an area which could potentially benefit from the results of this thesis. KEYWORDSsoftware architectures, dynamic evolution, dynamic reconfiguration, dynamic type evolution, dynamic instance evol...

Dynamic and coordinated software reconfiguration in distributed data stream systems

“…Despite extensive research in dynamic software reconfiguration [8][9][10][11], safe reconfiguration is still an open problem [2,[12][13][14]. A common approach is to put the component that has to be updated into a safe state, such as the quiescent state [15], before reconfiguring the system [16].…”

Uma Abordagem Eficiente Para Reconfiguração Coordenada Em Sistemas Distribuídos De Processamento De Data Streams

“…Apesar da extensa pesquisa em reconfiguração dinâmica de software [11]- [14], reconfiguração consistente (i.e., uma reconfiguração onde "... o sistema pode continuar processando normalmente ao invés de avançar para um estado errôneo..." [15]) ainda é um desafio em aberto [5] [16] [17]. Uma abordagem comum é levar o componente que será modificado para um estado seguro, como por exemplo o estado quiescente (i.e., de inatividade parcial) [15], antes de reconfigurar o sistema [15] [18] [19].…”

“…Assim, o middleware repassa o estado da versão antiga para a função de transformação. Esta, por sua vez, deve mapear o estado do componente antigo para o estado da nova versão[17]. Por outro lado, a transferência automatizada é capaz de fazer o mapeamento entre os estados autonomamente, sem qualquer intervenção do desenvolvedor.…”

“…Por outro lado, a transferência automatizada é capaz de fazer o mapeamento entre os estados autonomamente, sem qualquer intervenção do desenvolvedor. Entretanto, a depender das mudanças realizadas, a completa automação pode não ser viável, uma vez que nem sempre a semântica do estado pode ser automaticamente derivada a partir do código fonte[17] [71][72]. No exemplo da Figura 6, o middleware não foi capaz de identificar que o atributo addr foi renomeado para useraddress e teve seu tipo alterado de short para int.…”

“…atualizado consistentemente, e (ii) transferir o estado entre os componentes que estão sendo substituídos[17]. Como a reconfiguração dinâmica pode gerar uma inconsistência e fazer com que o sistema antiga um estado errôneo no momento da substituição dos componentes, o sistema -ou preferencialmente apenas suas partes afetadas -deve estar em um estado seguro no qual as mudanças realizadas preservem a corretude das atividades -i.e., transações ou Neste caso, para que a transferência de estado seja realizada corretamente, deverá haver uma função de transformação responsável por realizar a conversão do tipo String[] para EmailAddress[].…”