ACME vs PDDL: support for dynamic reconfiguration of software architectures

On the one hand, ACME is a language designed in the late 90s as an interchange format for software architectures. The need for recon guration at runtime has led to extend the language with speci c support in Plastik. On the other hand, PDDL is a predicative language for the description of planning problems. It has been designed in the AI community for the International Planning Competition of the ICAPS conferences. Several related works have already proposed to encode software architectures into PDDL. Existing planning algorithms can then be used in order to generate automatically a plan that updates an architecture to another one, i.e., the program of a recon guration. In this paper, we improve the encoding in PDDL. Noticeably we propose how to encode ADL types and constraints in the PDDL representation. That way, we can statically check our design and express PDDL constraints in order to ensure that the generated plan never goes through any bad or inconsistent architecture, not even temporarily.Comment: 6\`eme \'edition de la Conf\'erence Francophone sur les Architectures Logicielles (CAL 2012), Montpellier : France (2012

Architecture Diagrams: A Graphical Language for Architecture Style Specification

Architecture styles characterise families of architectures sharing common characteristics. We have recently proposed configuration logics for architecture style specification. In this paper, we study a graphical notation to enhance readability and easiness of expression. We study simple architecture diagrams and a more expressive extension, interval architecture diagrams. For each type of diagrams, we present its semantics, a set of necessary and sufficient consistency conditions and a method that allows to characterise compositionally the specified architectures. We provide several examples illustrating the application of the results. We also present a polynomial-time algorithm for checking that a given architecture conforms to the architecture style specified by a diagram.Comment: In Proceedings ICE 2016, arXiv:1608.0313

A Model of Layered Architectures

Architectural styles and patterns play an important role in software engineering. One of the most known ones is the layered architecture style. However, this style is usually only stated informally, which may cause problems such as ambiguity, wrong conclusions, and difficulty when checking the conformance of a system to the style. We address these problems by providing a formal, denotational semantics of the layered architecture style. Mainly, we present a sufficiently abstract and rigorous description of layered architectures. Loosely speaking, a layered architecture consists of a hierarchy of layers, in which services communicate via ports. A layer is modeled as a relation between used and provided services, and layer composition is defined by means of relational composition. Furthermore, we provide a formal definition for the notions of syntactic and semantic dependency between the layers. We show that these dependencies are not comparable in general. Moreover, we identify sufficient conditions under which, in an intuitive sense which we make precise in our treatment, the semantic dependency implies, is implied by, or even coincides with the reflexive-transitive closure of the syntactic dependency. Our results provide a technology-independent characterization of the layered architecture style, which may be used by software architects to ensure that a system is indeed built according to that style.Comment: In Proceedings FESCA 2015, arXiv:1503.0437

Specifying Self-configurable Component-based Systems with FracToy

International audienceOne of the key research challenges in autonomic computing is to define rigorous mathematical models for specifying, analyzing, and verifying high-level self-* policies. This paper presents the FracToy formal methodology to specify self-configurable component-based systems, and particularly both their component-based architectural description and their self-configuration policies. This rigorous methodology is based on the first-order relational logic, and is implemented with the Alloy formal specication language. The paper presents the dierent steps of the FracToy methodology and illustrates them on a self-configurable component-based example

Exception handling in the development of fault-tolerant component-based systems

Orientador: Cecilia Mary Fischer RubiraTese (doutorado) - Universidade Estadual de Campinas, Instituto de ComputaçãoResumo: Mecanismos de tratamento de exceções foram concebidos com o intuito de facilitar o gerenciamento da complexidade de sistemas de software tolerantes a falhas. Eles promovem uma separação textual explícita entre o código normal e o código que lida com situações anormais, afim de dar suporte a construção de programas que são mais concisos fáceis de evoluir e confáveis. Diversas linguagens de programação modernas e a maioria dos modelos de componentes implementam mecanismos de tratamento de exceções. Apesar de seus muitos benefícios, tratamento de exceções pode ser a fonte de diversas falhas de projeto se usado de maneira indisciplinada. Estudos recentes mostram que desenvolvedores de sistemas de grande escala baseados em infra-estruturas de componentes têm hábitos, no tocante ao uso de tratamento de exceções, que tornam suas aplicações vulneráveis a falhas e difíceis de se manter. Componentes de software criam novos desafios com os quais mecanismos de tratamento de exceções tradicionais não lidam, o que aumenta a probabilidade de que problemas ocorram. Alguns exemplos são indisponibilidade de código fonte e incompatibilidades arquiteturais. Neste trabalho propomos duas técnicas complementares centradas em tratamento de exceções para a construção de sistemas tolerantes a falhas baseados em componentes. Ambas têm ênfase na estrutura do sistema como um meio para se reduzir o impacto de mecanismos de tolerância a falhas em sua complexidade total e o número de falhas de projeto decorrentes dessa complexidade. A primeira é uma abordagem para o projeto arquitetural dos mecanismos de recuperação de erros de um sistema. Ela trata do problema de verificar se uma arquitetura de software satisfaz certas propriedades relativas ao fluxo de exceções entre componentes arquiteturais, por exemplo, se todas as exceções lançadas no nível arquitetural são tratadas. A abordagem proposta lança de diversas ferramentas existentes para automatizar ao máximo esse processo. A segunda consiste em aplicar programação orientada a aspectos (AOP) afim de melhorar a modularização de código de tratamento de exceções. Conduzimos um estudo aprofundado com o objetivo de melhorar o entendimento geral sobre o efeitos de AOP no código de tratamento de exceções e identificar as situações onde seu uso é vantajoso e onde não éAbstract: Exception handling mechanisms were conceived as a means to help managing the complexity of fault-tolerant software. They promote an explicit textual separation between normal code and the code that deals with abnormal situations, in order to support the construction of programs that are more concise, evolvable, and reliable. Several mainstream programming languages and most of the existing component models implement exception handling mechanisms. In spite of its many bene?ts, exception handling can be a source of many design faults if used in an ad hoc fashion. Recent studies show that developers of large-scale software systems based on component infrastructures have habits concerning the use of exception handling that make applications vulnerable to faults and hard to maintain. Software components introduce new challenges which are not addressed by traditional exception handling mechanisms and increase the chances of problems occurring. Examples include unavailability of source code and architectural mismatches. In this work, we propose two complementary techniques centered on exception handling for the construction of fault-tolerant component-based systems. Both of them emphasize system structure as a means to reduce the impactof fault tolerance mechanisms on the overall complexity of a software system and the number of design faults that stem from complexity. The ?rst one is an approach for the architectural design of a system?s error handling capabilities. It addresses the problem of verifying whether a software architecture satis?es certain properties of interest pertaining the ?ow of exceptions between architectural components, e.g., if all the exceptions signaled at the architectural level are eventually handled. The proposed approach is based on a set of existing tools that automate this process as much as possible. The second one consists in applying aspect-oriented programming (AOP) to better modularize exception handling code. We have conducted a through study aimed at improving our understanding of the efects of AOP on exception handling code and identifying the situations where its use is advantageous and the ones where it is notDoutoradoDoutor em Ciência da Computaçã

Better abstractions for reusable components & architectures

Software architecture (SA) is a crucial component of Model Driven Engineering (MDE), since it eases the communication and reuse of designs and components. However, existing languages (e.g., UML, AADL, SysML) are lacking many needed features. In particular, they provide rudimentary support for connectors, a first-class element in the components and connectors (C&C) architectural view and one of the most reusable architectural elements. This is unfortunate, since the difficult properties that need to be guaranteed for complex systems are mainly the non-functional properties, like throughput, security and dependability, which are greatly influenced by the employed connectors. This work reviews the basic abstractions of the C&C view of SA and examines extra architectural elements which can support the detailed, explicit and separate description of behaviour, interaction and control logic

Formalization and model checking of software architectural style

Formal analysis is required to check the behavior of the system before implementation of any safety critical system. As the complexity of software increases, the need for reasoning about correct behavior becomes more prominent. Algorithmic analysis of different programs is usually carried out in order to prove their properties of execution. Application of formal method is being considered necessary for modeling, verification, and development of any software or hardware systems. In the formal verification of behavioral model, an attempt has been made to formally describe a real-time system e.g., use of Automated Teller Machine (ATM) in Banks. In this thesis, formal models of ATM system are described using state-based languages such as, Z, B, and Alloy as well as event-based language such as, Monterey Phoenix. Model checking is being carried out by automated tools, viz. Z/EVES, Atelier B, and Alloy Analyzer for Z, B, and Alloy specifications respectively. Furthermore, a comparative analysis of different characteristics shown by varied formal approaches has been presented in this thesis. Software architecture plays an important role in the high level design of a system in terms of components, connectors, and configurations. The main building block of software architecture is an architectural style that provides domain specific design semantics. In the analysis of complex architectural style, an attempt has been made in our work to formalize one complex style e.g., C2 (component and connector) using formal specification language Alloy. For consistency checking of modeling notations, the model checker tool e.g., Alloy Analyzer is used. Alloy Analyzer automatically checks properties such as,compatibility between components and connectors, satisfiability of predicates over the architectural structure, and consistency of an architectural style. For modeling and verification of C2 architectural style, one case study on Cruise Control System has been considered. At the end of this study, performance evaluation of different SAT solvers associated with Alloy Analyzer has been performed in order to assess the quality

Naming and discovery in networks : architecture and economics

In less than three decades, the Internet was transformed from a research network available to the academic community into an international communication infrastructure. Despite its tremendous success, there is a growing consensus in the research community that the Internet has architectural limitations that need to be addressed in a effort to design a future Internet. Among the main technical limitations are the lack of mobility support, and the lack of security and trust. The Internet, and particularly TCP/IP, identifies endpoints using a location/routing identifier, the IP address. Coupling the endpoint identifier to the location identifier hinders mobility and poorly identifies the actual endpoint. On the other hand, the lack of security has been attributed to limitations in both the network and the endpoint. Authentication for example is one of the main concerns in the architecture and is hard to implement partly due to lack of identity support. The general problem that this dissertation is concerned with is that of designing a future Internet. Towards this end, we focus on two specific sub-problems. The first problem is the lack of a framework for thinking about architectures and their design implications. It was obvious after surveying the literature that the majority of the architectural work remains idiosyncratic and descriptions of network architectures are mostly idiomatic. This has led to the overloading of architectural terms, and to the emergence of a large body of network architecture proposals with no clear understanding of their cross similarities, compatibility points, their unique properties, and architectural performance and soundness. On the other hand, the second problem concerns the limitations of traditional naming and discovery schemes in terms of service differentiation and economic incentives. One of the recurring themes in the community is the need to separate an entity\u27s identifier from its locator to enhance mobility and security. Separation of identifier and locator is a widely accepted design principle for a future Internet. Separation however requires a process to translate from the identifier to the locator when discovering a network path to some identified entity. We refer to this process as identifier-based discovery, or simply discovery, and we recognize two limitations that are inherent in the design of traditional discovery schemes. The first limitation is the homogeneity of the service where all entities are assumed to have the same discovery performance requirements. The second limitation is the inherent incentive mismatch as it relates to sharing the cost of discovery. This dissertation addresses both subproblems, the architectural framework as well as the naming and discovery limitations