Implementación de estrategia para manejo de excepciones basada en componentes: las fachadas de seguridad

Los mecanismos de manejo de excepciones fueron concebidos como un marco de trabajo para implementar tolerancia a fallos en sistemas de software. Más de dos tercios del código de una aplicación, está dedicado a la detección y manejo de errores y excepciones. A menudo, los mecanismos de manejo de excepciones, son mal empleados o se abusa de ellos; el diseño de una estrategia efectiva se considera una tarea difícil puesto que: aumenta considerablemente la complejidad de los sistemas, plantea conflictos con algunos de los principios del diseño orientado a objetos, no existen pautas eficientes, entre otras causas. Por tanto, el manejo de errores y excepciones, es uno de los temas más importantes de la arquitectura del software y, uno de los aspectos más cruciales pero menos tenido en cuenta, en el análisis y diseño de sistemas críticos. Aplicando el concepto de proxies dinámicos, se investigan los detalles de implementación de una simple aunque interesante, estrategia basada en componentes para el manejo de excepciones, disponible en la literatura: las fachadas de seguridad; cuya descripción original carece de información pormenorizada. Las fachadas de seguridad constituyen un nuevo enfoque, que introduce una arquitectura y directrices, estableciendo un framework para el manejo de excepcionesException handling mechanisms were conceived as a means for incorporating fault tolerance into software systems. More than two thirds of the application’s code is dedicated to detecting and handling errors and exceptions. These exception handling systems are often misuse and (or) abused. The design of exception handling in an application is seen as a difficult task because: introduce significant complexity, may conflict with many of the goals of object oriented design, suffers from lack of guidelines, among other things. For these reasons the handling of exceptions and errors is one of the major subject of the software architecture and one of the most critical, but overlooked aspect of critical system design and analysis. I will apply the concept of dynamic proxy to implement a simple but interesting exception handling design approach called safety facades, available in the software architecture literature. The article describing security façades is light on details. The security façade form a new approach that introduce and architecture and best practices to build a viable framework for systems with exception handling.Workshop de Ingeniería de Software y Bases de Datos (WISBD)Red de Universidades con Carreras en Informática (RedUNCI

Implementación de estrategia para manejo de excepciones basada en componentes: las fachadas de seguridad

Los mecanismos de manejo de excepciones fueron concebidos como un marco de trabajo para implementar tolerancia a fallos en sistemas de software. Más de dos tercios del código de una aplicación, está dedicado a la detección y manejo de errores y excepciones. A menudo, los mecanismos de manejo de excepciones, son mal empleados o se abusa de ellos; el diseño de una estrategia efectiva se considera una tarea difícil puesto que: aumenta considerablemente la complejidad de los sistemas, plantea conflictos con algunos de los principios del diseño orientado a objetos, no existen pautas eficientes, entre otras causas. Por tanto, el manejo de errores y excepciones, es uno de los temas más importantes de la arquitectura del software y, uno de los aspectos más cruciales pero menos tenido en cuenta, en el análisis y diseño de sistemas críticos. Aplicando el concepto de proxies dinámicos, se investigan los detalles de implementación de una simple aunque interesante, estrategia basada en componentes para el manejo de excepciones, disponible en la literatura: las fachadas de seguridad; cuya descripción original carece de información pormenorizada. Las fachadas de seguridad constituyen un nuevo enfoque, que introduce una arquitectura y directrices, estableciendo un framework para el manejo de excepcionesException handling mechanisms were conceived as a means for incorporating fault tolerance into software systems. More than two thirds of the application’s code is dedicated to detecting and handling errors and exceptions. These exception handling systems are often misuse and (or) abused. The design of exception handling in an application is seen as a difficult task because: introduce significant complexity, may conflict with many of the goals of object oriented design, suffers from lack of guidelines, among other things. For these reasons the handling of exceptions and errors is one of the major subject of the software architecture and one of the most critical, but overlooked aspect of critical system design and analysis. I will apply the concept of dynamic proxy to implement a simple but interesting exception handling design approach called safety facades, available in the software architecture literature. The article describing security façades is light on details. The security façade form a new approach that introduce and architecture and best practices to build a viable framework for systems with exception handling.Workshop de Ingeniería de Software y Bases de Datos (WISBD)Red de Universidades con Carreras en Informática (RedUNCI

Specification languages for embedded systems : a survey

Requirements specification is an important part of the software development process. Use of well developed techniques, tools, and languages during requirements specification is especially crucial for complex embedded software systems. Four langauges appropriate for the specification of software requirements for complex embedded systems (RSL, PAISLey, Statecharts, and SCR) are reviewed in detail here. In addition, other representation languages with features relevant to the embedded software systems domain are mentioned. Conclusions about the current status of embedded systems requirements specification and indications of further research are given

On the engineering of crucial software

The various aspects of the conventional software development cycle are examined. This cycle was the basis of the augmented approach contained in the original grant proposal. This cycle was found inadequate for crucial software development, and the justification for this opinion is presented. Several possible enhancements to the conventional software cycle are discussed. Software fault tolerance, a possible enhancement of major importance, is discussed separately. Formal verification using mathematical proof is considered. Automatic programming is a radical alternative to the conventional cycle and is discussed. Recommendations for a comprehensive approach are presented, and various experiments which could be conducted in AIRLAB are described

Uma ferramenta de análise de robustez para a melhoria da qualidade de sistemas de software

A software product is considered reliable if it can deliver its functions the way they were defined. Robustness is a sub-attribute of reliability and concerns the software's ability to respond specifically to external defects. The exception handling mechanisms should ensure the robustness of the systems. However, in practice it is difficult to achieve such a goal, either by misuse of existing models, either by deficiency of the models themselves. Moreover, it is clear that developers dealing exceptions properly end up having serious problems in productivity, while its neglect although more productive, tends to generate less reliable systems and subsequent rising cost of post-production. Some real disasters were directly related to the neglect of exception handling, for example: the case of the European Ariane 5 rocket that self-destructed soon after launch, and the radar system Brazilian X-4000 which was nominated as one of the causes the crash of Gol Flight 1907 in 2006. In this context, this work presents a static analysis tool exceptional flow eFlowMining, focused on improving the robustness of applications. NET. It allows the developer: view metrics collected on the exceptional behavior; analyze the exceptional flow via a graphical representation as a tree; identify possible bugs between different versions of the same application, and quickly locate the types of exceptions thrown and their their handlers. All information collected is stored in databases to enable searches and comparisons of the analyzes. The evaluation tool was divided into two phases. The first aimed to show the consistency and accuracy of the tool relative to the different programming languages supported by the platform. NET. The second assessed how the tool helped developers identify possible defects between different versions of the same software system.Um produto de software é considerado confiável quando ele consegue entregar suas funcionalidades da forma como elas foram definidas. Robustez é um sub-atributo de confiabilidade e diz respeito à capacidade do software em reagir especificamente a defeitos externos. Os mecanismos de tratamento de exceções deveriam garantir a robustez dos sistemas. Entretanto, na prática é difícil atingir tal objetivo, seja por mau uso dos modelos existentes, seja pela deficiência dos próprios modelos. Além disso, percebe-se que os desenvolvedores que tratam as exceções de maneira adequada acabam tendo problemas sérios de produtividade, ao passo que o seu negligenciamento embora seja mais produtivo, tende a gerar sistemas menos confiáveis e com subseqüente aumento do custo de pós-produção. Alguns desastres reais tiveram relação direta com o negligenciamento do tratamento de exceções, por exemplo: o caso do foguete europeu Ariane 5 que se autodestruiu logo após o lançamento, e do sistema do radar brasileiro X-4000 que foi indicado como uma das causas do acidente aéreo do vôo GOL 1907 em 2006. Nesse contexto, este trabalho apresenta a ferramenta de análise estática do fluxo excepcional eFlowMining, focada na melhoria da robustez de aplicações .NET. Ela permite que o desenvolvedor: visualize métricas coletadas sobre o comportamento excepcional; analise o fluxo excepcional através de uma representação gráfica em forma de árvore; identifique possíveis bugs entre diferentes versões da mesma aplicação; e localize de forma rápida os tipos de exceções lançadas e seus respectivos tratadores. Todas as informações coletadas são armazenadas em bancos de dados a fim de possibilitar consultas e comparações das análises realizadas. A avaliação da ferramenta foi dividida em duas fases. A primeira teve o objetivo de mostrar a compatibilidade e a precisão da ferramenta em relação às diferentes linguagens de programação suportadas pela plataforma .NET. A segunda avaliou como a ferramenta ajudou os desenvolvedores a identificar possíveis defeitos entre diferentes versões do mesmo sistema de software

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çã

Explicit Exception Handling Variability In Component-based Product Line Architectures

Separation of concerns is one of the overarching goals of exception handling in order to keep separate normal and exceptional behaviour of a software system. In the context of a software product line (SPL), this separation of concerns is also important for designing software variabilities related to different exception handling strategies, such as the choice of different handlers depending on the set of selected features. This paper presents a method for refactoring object-oriented product line architecture in order to separate explicitly their normal and exceptional behaviour into different software components. The new component-based software architecture includes variation points related to different choices of exception handlers that can be selected during product instantiations, thus facilitating the evolution of the exceptional behaviour. The feasibility of the proposed approach is assessed through a SPL of mobile applications. Copyright 2008 ACM.4754Atkinson, C., (2002) Component-based Product Line Engineering with UML, , Addison-WesleyBass, L., Clements, P., Kazman, R., (1997) Software Architecture in Practice, , Addison-Wesley Professional, DecemberP. H. S. Brito, C. R. Rocha, F. Castor Filho, E. Martins, and C. M. F. Rubira. A method for modeling and testing exceptions in component-based software development. In Proc. of the 2nd Latin American Symposium on Dependable Computing (LADC 2005), LNCS 3747, pages 61-79, 2005Buschmann, F., (1996) Pattern-oriented software architecture: A system of patterns, , John Wiley & Sons, IncCacho, N., Filho, F.C., Garcia, A., Figueiredo, E., Ejflow: Taming exceptional control flows in aspect-oriented programming (2008) 7th Int. Conf. on Aspect-Oriented Software Development (AOSD'08), pp. 72-83Cheesman, J., Daniels, J., (2000) UML Components, , Addison-WesleyClements, P., Northrop, L., (2002) Software Product Lines: Practices and Patterns, , Addison-WesleyCristian, F., Exception handling (1989) Dependability of Resilient Computers, pp. 68-97. , T. Anderson, editor, Blackwell Scientific PublicationsFerber, S., Haag, J., Savolainen, J., Feature interaction and dependencies: Modeling features for reengineering a legacy product line (2002) LNCS, 2379, pp. 37-60. , Proc. of the Second International Software Product Lines Conference SPLCFigueiredo, E., Evolving software product lines with aspects: An empirical study on design stability (2008) ICSE '08: Proc. of the 30th international conference on Software engineering, pp. 261-270Filho, F.C., Guerra, P.A.D.C., Pagano, V.A., Rubira, C.M.F., A systematic approach for structuring exception handling in robust component-based software (2005) Journal of the Brazilian Computer Society, 10 (3), pp. 5-19Gamma, E., Helm, R., Johnson, R., Vlissides, J., (1995) Design Patterns: Elements of Reusable Software Systems, , Addison-WesleyGayard, L.A., Rubira, C.M.F., de Castro Guerra, P.A., COSMOS*: A COmponent System MOdel for Software Architectures (2008), Technical Report IC-08-04, FebGray, J., Reuter, A., (1993) Transaction Processing: Concepts and Techniques, , Morgan KaufmannKruchten, P., Obbink, J.H., Stafford, J.A., The past, present, and future for software architecture (2006) IEEE Software, 23 (2), pp. 22-30Lippert, M., Lopes, C.V., A study on exception detection and handling using aspect-oriented programming (2000) Proc. of the 22nd international conference on Software engineering (ICSE'00), pp. 418-427Parnas, D.L., Würges, H., Response to undesired events in software systems (1976) Proceedings of the 2nd International Conference on Software Engineering, pp. 437-446Robillard, M.P., Murphy, G.C., Designing robust java programs with exceptions (2000) SIGSOFT Softw. Eng. Notes, 25 (6), pp. 2-10Szyperski, C., (2002) Component Software: Beyond Object-Oriented Programming, , ACM Press and Addison-Wesley, New York, USA, second edition edition, NovemberR. T. Tomita, F. Castor Filho, P. A. de C. Guerra, and C. M. F. Rubira. Bellatrix: An environment with arquitectural support for component-based development (in portuguese). In Proc. of the IV Brazilian Workshop on Component-Based Development, pages 43-48, 200

Architecture-centric Fault Tolerance With Exception Handling

When building dependable systems by integrating untrusted software components that were not originally designed to interact with each other, it is inevitable the occurrence of architectural mismatches related to assumptions in the failure behaviours. These mismatches if not prevented during system design have to be tolerated during runtime. This paper presents an architectural abstraction based on exception handling for structuring fault-tolerant software systems. This abstraction comprises several components and connectors that transform an existing untrusted software element into an idealised fault-tolerant architectural element. The proposed rigorous approach relies on a formal representation for analysing exception propagation, and verifying important dependability properties. Beyond this, the formal models are also used for generating unit and integration test cases that would be used for validating the final software product. The feasibility of the proposed approach was evaluated on an embedded critical case study. © Springer-Verlag Berlin Heidelberg 2007.4746 LNCS7594Abrial, J.-R., (1996) The B-book: Assigning programs to meanings, , Cambridge University Press, New YorkAmnell, T., Behrmann, G., Bengtsson, J., D'Argenio, P.R., David, A., Fehnker, A., Hune, T., Yi, W., Uppaal - Now, Next, and Future (2001) LNCS, 2067, pp. 100-125. , Cassez, F, Jard, C, Rozoy, B, Ryan, M, eds, MOVEP 2000, Springer, HeidelbergAnderson, T., Lee, P.A., (1981) Fault Tolerance: Principles and Practice, , Prentice-Hall, Englewood CliffsBass, L., Clements, P.C., Kazman, R., (2003) Software Architecture in Practice, , 2nd edn. Addison-Wesley, ReadingBertolino, A., Marchetti, E., Muccini, H.: Introducing a reasonably complete and coherent approach for model-based testing. Electr. Notes Theor. Comput. Sci. 116, 85-97 (2005)Binder, R.V., (1999) Testing object-oriented systems: Models, patterns, and tools, , Addison-Wesley Longman Publishing Co, Inc, Redwood City, CA, USABrito, P.H.S., de Lemos, R., Martins, E., Rubira, C.M.F., Verification and validation of a fault-tolerant architectural abstraction (2007) DSN Workshop on Architecting Dependable Systems (WADS, , Edinburgh, Scotland, UK Accepted for publicationBrookes, S.D., Hoare, C.A.R., Roscoe, A.W., A theory of communicating sequential processes (1984) J. ACM, 31 (3), pp. 560-599Castor Filho, F., Cacho, N., Figueiredo, E., Ferreira, R., Garcia, A., Rubira, C.M.F., Exceptions and aspects: The devil is in the details (2006) Proceedings of the 14th ACM SIGSOFT FSE, pp. 152-162. , NovemberCastor Filho, F., da Silva Brito, P.H., Rubira, C.M.F., Specification of exception flow in software architectures (2006) Journal of Systems and Software, , OctoberCastor Filho, F., de Castro Guerra, P.A., Rubira, C.M.F.: An architectural-level exception-handling system for component-based applications. In: de Lemos, R., Weber, T.S., Camargo Jr., J.B. (eds.) LADC 2003. LNCS, 2847, pp. 321-340. Springer, Heidelberg (2003)Clements, P., (2003) Documenting Software Architectures: Views and Beyond, , Addison-Wesley, ReadingCristian, F., Exception handling (1989) Dependability of Resilient Computers, pp. 68-97. , Blackwellda Silva Brito, P.H., de Lemos, R., Filho, F.C., Rubira, C.M.F., Architecturecentric fault tolerance with exception handling (2007), Technical Report IC-07-04. State University of Campinas FebruaryBrito, P.H.S., Rocha, C.R., Castor Filho, F., Martins, E., Rubira, C.M.F.: A method for modeling and testing exceptions in component-based software development. In: Maziero, C.A., Silva, J.G., Andrade, A.M.S., Assis Silva, F.M.d. (eds.) LADC 2005. LNCS, 3747, pp. 61-79. Springer, Heidelberg (2005)de Castro Guerra, P.A., Rubira, C., de Lemos, R., A fault-tolerant software architecture for component-based systems (2003) LNCS, 2677, pp. 129-149. , de Lemos, R, Gacek, C, Romanovsky, A, eds, Architecting Dependable Systems, Springer, Heidelbergde Lemos, R., de Castro Guerra, P.A., Rubira, C.M.F., A fault-tolerant architectural approach for dependable system (2006) IEEE Software, 23 (2), pp. 80-87McMillan, K.L., The SMV system (1992), Technical Report CMU-CS-92-131, Carnegie Mellon UniversityGray, J., Reuter, A., (1993) Transaction Processing: Concepts and Techniques, , Morgan Kaufmann, San FranciscoIssarny, V., Banatre, J.P., Architecture-based exception handling (2001) Proceedings of the 34th Annual Hawaii International Conference on System SciencesJackson, D., Alloy: A lightweight object modelling notation (2002) Software Engineering and Methodology, 11 (2), pp. 256-290Jackson, D., Schechter, I., Shlyahter, H., Alcoa: The alloy constraint analyzer (2000) ICSE '00: Proceedings of the 22nd international conference on Software engineering, pp. 730-733. , ACM Press, New YorkLee, P.A., Anderson, T., Fault Tolerance: Principles and Practice (1990) Dependable computing and fault-tolerant systems, , 2nd edn, Springer, Berlin, New YorkLeuschel, M., Butler, M.J.: Prob: A model checker for b. In: Araki, K., Gnesi, S., Mandrioli, D. (eds.) FME 2003. LNCS, 2805, pp. 855-874. Springer, Heidelberg (2003)Parnas, D.L., Würges, H., Response to undesired events in software systems (1976) Proceedings of the 2nd International Conference on Software Engineering, pp. 437-446. , San Francisco, USA, pp, OctoberRandell, B., System structure for software fault tolerance (1975) IEEE Transactions on Software Engineering, 1 (2), pp. 221-232Reimer, D., Srinivasan, H., Analyzing exception usage in large java applications (2003) LNCS, 2743. , Cardelli, L, ed, ECOOP 2003, Springer, HeidelbergSchneider, S., Treharne, H., Communicating b machines (2002) LNCS, 2272, pp. 416-435. , Bert, D, Bowen, J.P, Henson, M.C, Robinson, K, eds, B 2002 and ZB 2002, Springer, HeidelbergSloman, M., Kramer, J., (1987) Distributed systems and computer networks, , Prentice Hall International (UK) Ltd, Hertfordshire, UKTaylor, R.N., Medvidovic, N., Anderson, K., Whitehead, J.E.J., Robbins, J., A component- and message- based architectural style for GUI software (1995) Proceedings of the 17th International Conference on Software Engineering, pp. 295-304. , AprilWeimer, W., Necula, G., Finding and preventing run-time error handling mistakes (2004) Proceedings of OOPSLA, pp. 419-433. , Vancouver, Canada, pp, Octobe