Várias ferramentas de desenvolvimento utilizam mecanismos para centralizar/gerenciar código compartilhado entre diferentes desenvolvedores ou equipes de desenvolvimento. Estes repositórios geralmente deixam muito a desejar em relação aos serviços que oferecem, não só aos desenvolvedores, mas também aos usuários de sistemas já desenvolvidos, que desejam ter atualizações e correções constantes em seus aplicativos. Surge então a necessidade de disponibilizar esses recursos em um ambiente de trabalho realmente cooperado. Este trabalho propõe a modelagem de um repositório de componentes de software, formado por uma área de armazenamento centralizada comum aos desenvolvedores, e com capacidade de gerenciar componentes e agregar serviços extras, administrando seu ciclo de vida de modo integrado. Para tal, várias tecnologias baseadas em Java foram integradas, tais como as seguintes API's: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) e Java Database Connection (JDBC).Para que o modelo aqui proposto possua um nível de funcionalidade adequado, são fornecidos vários serviços pelo repositório, atendendo assim às expectativas tanto de desenvolvedores, como dos usuários finais. Dentre outros, são providos os seguintes serviços: Serviço de Descrição, Serviço de Histórico, Serviço de Controle de Versões, Serviço de Teste OO, Serviço de Padrões de Projeto e Serviço de Invalidação de Componentes. / Software development tools commonly use mechanisms for storing/managing code shared among different developers or development teams. These repositories generally are very poor in relation to the services they provide to developers and also to the users of already developed systems which need to make constant updates and corrections on their applications. There is a need to supply supporting services to software integration through a really cooperated development environment. This work considers the modeling of a software component repository comprising a common storage area to be accessed by developers, possessing capacity to manage components and to add extra services, and managing the development life cycle in an integrated mode. To accomplish this model, some technologies based on Java have been integrated, namely: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) and Java Database Connection (JDBC). For the model considered here to have an adjusted level of functionality, some repository services are supplied so assuring the expectations of developers and final users. Among the services provided, the following must be mentioned: Description Service, History Service, Version Control Service, OO Test Service, Design Patterns Service and Components Invalidation Service.

Contemporary software engineering practice overemphasizes the distinction of software design from software implementation, and designer (“software architect”) from implementor (“computer programmer”). In this contemporary meme, software architects are concerned with large-grained system structures, quality attributes that arise from these structures (security, availability, performance, etc.) and quality attribute tradeoff to satisfy conflicting stakeholder needs; programmers are concerned with low–level algorithms and data structures, program functionality, and with satisfying architectural intent. However, software is unique in that design and implementation are not cleanly separable. While architect and programmer may have many different design concerns, they also have many complementary and interacting concerns; their respective design practices must be well–integrated. Instead, contemporary architecture and programming practices are diverging. Architects are likely to regard programming as a routine production activity, while programmers are likely to regard architecture as a routine management activity; communication is hindered by a lack of shared vocabulary or appreciation of mutual concerns. Instead of effective integration, a gap has opened in software architecture and programming practice. The research reported here defines the architecture/program seam (“the Seam”), a region of overlap in software architecture and programming practice. The Seam emphasizes design concerns centered on achieving predictable runtime behavior. For a behavior to be predictable it must be described in a theory that must ultimately be consistent with basic theories of computation, and each such theory must have objective evidence to demonstrate that theory observations correspond to system observations. The validity of a theory will likely depend on invariants that can be expressed, and enforced, by means of theory–induced design rules. A system that satisfies the design rules of a theory is then regarded as having behavior that is predictable by construction with respect to that theory. Predictability by construction reduces uncertainty, and hence risk in design, and helps designers explain complex design decisions. The research reported here also defines prediction–enabled component technology (PECT) as a foundation technology to support the Seam, and demonstrates a prototype on industrial problems in electric grid substation control, industrial robot control, and desktop streaming audio. The prototype PECT extends a basic component technology of pure assembly (“Pin”) with theory extension points (“reasoning frameworks”) that are used to achieve predictability by construction. Reasoning frameworks for real–time performance and temporal–logic model checking have been developed, with statistical confidence intervals providing evidence of predictive quality for the former, and code–embeddable proof certificates providing evidence for the latter. Finally, the research reported here defines the Seam itself as inducing a new kind of evolutionary design problem, whose solutions require the integration of programming language theory, design theory, specialized theories of system behavior and deep systems expertise.

[pt] Os sistemas radares são amplamente utilizados em aplicações civis e militares, são sistemas complexos que empregam alta tecnologia. Muitos deles são constituídos por um conjunto de elementos que necessitam de um mínimo de coordenação entre as suas funcionalidades. A construção de um protótipo para validar o projeto de um radar demanda recursos financeiros e tempo. Por outro lado, existem muitas características em comum entre os sistemas de diferentes radares. Esta dissertação descreve uma biblioteca de um simulador capaz de representar vários sistemas de radar e que foi projetado de acordo com os princípios básicos sobre radar. O simulador foi desenvolvido baseado em um sistema de componentes flexíveis onde cinco diferentes tipos de radar são descritos e simulados utilizando a biblioteca apresentada. Porém cenários reais são utilizados para comparar e validar as simulacões. / [en] Nowadays Radar systems are becoming complex systems. Many radars are constituted by an array of elements, where a minimum of coordination among the elements functionality is need. The task to build a prototype in order to validate a radar design is an expensive one. On the other hand, there are many common features shared among different radar architectures. This dissertation describes the architecture of a simulator that is able to represent most of the radar systems designed according the basic principles of radars. The simulator is designed following a exible component based architecture and five quite different kind of radars are described and simulated using the presented architecture. Real scenarios are taken into account in the validation of the simulations.

[pt] Sistemas distribuídos frequentemente apresentam um comportamento em tempo de execução diferente do esperado pelo programador. A análise estática, somente, não suficiente para a compreensão do comportamento e para o diagnóstico de problemas nesses sistemas, em razão da sua natureza nao determinística, reflexo de características inerentes como concorrência, latência na comunicação e falha parcial. Sendo assim, torna-se necessário um melhor entendimento das interações entre os diferentes componentes de software que formam o sistema, para que o desenvolvedor possa ter uma melhor visão do comportamento do sistema durante sua execução. Neste trabalho, apresentamos uma ferramenta que faz a reconstrução das interações entre os componentes de uma aplicação distribuída, oferecendo uma visão das linhas de execução distribuídas e permitindo o acompanhamento das sequências de chamadas remotas e a análise das relações de causalidade. Essa ferramenta também faz a persistência do histórico dessas interações ao longo do tempo, correlacionando-as a arquitetura do sistema e aos dados de desempenho. Assim, a ferramenta proposta auxilia o desenvolvedor a melhor compreender cenários que envolvem comportamentos indevido do sistema e a restringir o escopo da análise do erro, facilitando a busca de uma solução. / [en] Distributed systems often present a runtime behavior different than what is expected by the programmer. Static analysis is not enough to understand the runtime behavior and to diagnoses errors. This difficulty is caused by the non-deterministic nature of distributed systems, because of their inherent characteristics, such as concurrency, communication latency and partial failure. Therefore, it’s necessary a better view of the interactions between the system’s software components in order to understand its runtime behavior. In this work we present a tool that rebuilds the interactions among distributed components, presents a view of distributed threads and remote call sequences, and allows the analysis of causality relationships. Our tool also stores the interactions over time and correlates them to the system architecture and to performance data. The proposed tool helps the developer to better understand scenarios involving an unexpected behavior of the system and to restrict the scope of error analysis, making easier the search for a solution.

Várias ferramentas de desenvolvimento utilizam mecanismos para centralizar/gerenciar código compartilhado entre diferentes desenvolvedores ou equipes de desenvolvimento. Estes repositórios geralmente deixam muito a desejar em relação aos serviços que oferecem, não só aos desenvolvedores, mas também aos usuários de sistemas já desenvolvidos, que desejam ter atualizações e correções constantes em seus aplicativos. Surge então a necessidade de disponibilizar esses recursos em um ambiente de trabalho realmente cooperado. Este trabalho propõe a modelagem de um repositório de componentes de software, formado por uma área de armazenamento centralizada comum aos desenvolvedores, e com capacidade de gerenciar componentes e agregar serviços extras, administrando seu ciclo de vida de modo integrado. Para tal, várias tecnologias baseadas em Java foram integradas, tais como as seguintes API's: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) e Java Database Connection (JDBC).Para que o modelo aqui proposto possua um nível de funcionalidade adequado, são fornecidos vários serviços pelo repositório, atendendo assim às expectativas tanto de desenvolvedores, como dos usuários finais. Dentre outros, são providos os seguintes serviços: Serviço de Descrição, Serviço de Histórico, Serviço de Controle de Versões, Serviço de Teste OO, Serviço de Padrões de Projeto e Serviço de Invalidação de Componentes. / Software development tools commonly use mechanisms for storing/managing code shared among different developers or development teams. These repositories generally are very poor in relation to the services they provide to developers and also to the users of already developed systems which need to make constant updates and corrections on their applications. There is a need to supply supporting services to software integration through a really cooperated development environment. This work considers the modeling of a software component repository comprising a common storage area to be accessed by developers, possessing capacity to manage components and to add extra services, and managing the development life cycle in an integrated mode. To accomplish this model, some technologies based on Java have been integrated, namely: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) and Java Database Connection (JDBC). For the model considered here to have an adjusted level of functionality, some repository services are supplied so assuring the expectations of developers and final users. Among the services provided, the following must be mentioned: Description Service, History Service, Version Control Service, OO Test Service, Design Patterns Service and Components Invalidation Service.

[pt] Sistemas de componentes têm como característica possibilitar a construção de aplicações através da composição de artefatos de software disponíveis. Interações podem ocorrer entre diversos componentes que podem estar distribuídos em diversas máquinas. À medida que aplicações distribuídas aumentam de tamanho, as interações existentes entre os diversos nós que a compõem vão se tornando mais complexas. Assim, torna-se importante para essas aplicações a existência de uma forma de monitorar as interações entre os componentes, com o intuito de identificar falhas e gargalos de processamento e comunicação no sistema. Este trabalho apresenta uma arquitetura capaz de oferecer mecanismos extensíveis para coleta de informações do ambiente de execução desses sistemas, e das interações realizadas entre os seus componentes. São implementadas formas de publicação dessas informações obtidas e testes comparativos para quantificar como a arquitetura desenvolvida onera o desempenho da aplicação. / [en] Component-based systems are characterized by the construction of applications through the composition of available software artifacts. Interactions may occur between different components that can be distributed through several machines. As distributed applications increase in size, the interactions between the various nodes that comprise them become more complex. Therefore it is important for distributed component systems to monitor the interactions between components in order to identify failures and bottlenecks in processing and communication. This dissertation presents an architecture capable of offering extensible mechanisms for monitoring the execution environment of distributed components, and the interactions between their components. It also presents a flexible mechanism for publication of the collected information, and some comparative test to measure the performance penalty imposed by the infrastructure to the application.

Várias ferramentas de desenvolvimento utilizam mecanismos para centralizar/gerenciar código compartilhado entre diferentes desenvolvedores ou equipes de desenvolvimento. Estes repositórios geralmente deixam muito a desejar em relação aos serviços que oferecem, não só aos desenvolvedores, mas também aos usuários de sistemas já desenvolvidos, que desejam ter atualizações e correções constantes em seus aplicativos. Surge então a necessidade de disponibilizar esses recursos em um ambiente de trabalho realmente cooperado. Este trabalho propõe a modelagem de um repositório de componentes de software, formado por uma área de armazenamento centralizada comum aos desenvolvedores, e com capacidade de gerenciar componentes e agregar serviços extras, administrando seu ciclo de vida de modo integrado. Para tal, várias tecnologias baseadas em Java foram integradas, tais como as seguintes API's: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) e Java Database Connection (JDBC).Para que o modelo aqui proposto possua um nível de funcionalidade adequado, são fornecidos vários serviços pelo repositório, atendendo assim às expectativas tanto de desenvolvedores, como dos usuários finais. Dentre outros, são providos os seguintes serviços: Serviço de Descrição, Serviço de Histórico, Serviço de Controle de Versões, Serviço de Teste OO, Serviço de Padrões de Projeto e Serviço de Invalidação de Componentes. / Software development tools commonly use mechanisms for storing/managing code shared among different developers or development teams. These repositories generally are very poor in relation to the services they provide to developers and also to the users of already developed systems which need to make constant updates and corrections on their applications. There is a need to supply supporting services to software integration through a really cooperated development environment. This work considers the modeling of a software component repository comprising a common storage area to be accessed by developers, possessing capacity to manage components and to add extra services, and managing the development life cycle in an integrated mode. To accomplish this model, some technologies based on Java have been integrated, namely: Enterprise Java Beans (EJB), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), Java Messaging Service (JMS), Java Transaction (JTA), Java Transaction Service (JTS) and Java Database Connection (JDBC). For the model considered here to have an adjusted level of functionality, some repository services are supplied so assuring the expectations of developers and final users. Among the services provided, the following must be mentioned: Description Service, History Service, Version Control Service, OO Test Service, Design Patterns Service and Components Invalidation Service.

Conselho Nacional de Desenvolvimento CientÃfico e TecnolÃgico / A aplicaÃÃo de nuvens computacionais para oferecer serviÃos de ComputaÃÃo de Alto Desempenho (CAD) à um assunto bastante discutido no meio acadÃmico e industrial. Esta dissertaÃÃo està inserida no contexto do projeto de uma nuvem computacional para o desenvolvimento e execuÃÃo de aplicaÃÃes de CAD baseadas em componentes paralelos, doravante denominada nuvem de componentes. Um dos principais desafios na sua utilizaÃÃo consiste no suporte à programaÃÃo paralela, tarefa bastante suscetÃvel à erros, pois tais erros podem levar, ao longo do desenvolvimento, a problemas de sincronizaÃÃo de processos, que podem causar abortamento da execuÃÃo e a produÃÃo de dados incorretos, bem como a problemas relacionados ao uso ineficiente dos recursos computacionais. à importante que tais problemas sejam tratados no caso de aplicaÃÃes de longa duraÃÃo cujo respeito a um cronograma para obtenÃÃo de resultados à crÃtico, aplicaÃÃes estas bastante comuns no contexto de CAD. Uma possÃvel soluÃÃo para tais problemas consiste na verificaÃÃo do comportamento e das propriedades dos componentes na nuvem, antes que seja feita a sua execuÃÃo, tornando possÃvel que os usuÃrios dos componentes da nuvem saibam se um componente pode ser utilizado com seguranÃa em sua aplicaÃÃo. Nesse cenÃrio, o uso de mÃtodos formais surge como uma alternativa atraente. A contribuiÃÃo desta dissertaÃÃo consiste em um processo de derivaÃÃo e verificaÃÃo de propriedades de componentes na nuvem. Tal processo envolve a especificaÃÃo formal do comportamento dos componentes por meio de contratos descritos pela linguagem Circus. EntÃo, atravÃs de um processo de refinamento e traduÃÃo tendo como ponto de partida o contrato, chega-se à implementaÃÃo de um componente para execuÃÃo sobre uma plataforma de computaÃÃo paralela. AtravÃs desse processo, torna-se possÃvel oferecer garantias aos desenvolvedores em relaÃÃo ao comportamento dos componentes no contexto de suas aplicaÃÃes. Para a prova de conceito, o processo à aplicado sobre a especificaÃÃo "papel-e-caneta" de dois benchmarks do NAS Parallel Benchmarks, IS e CG, bastante difundidos na Ãrea de CAD. / The use of cloud computing to offer High Performance Computing (HPC) services has been widely discussed in the academia and industry. In this respect, this dissertation is included in the context of designing a cloud computing platform for the development of component-based parallel computing applications, referred as cloud of components. Many important challenges about using the cloud of components relate to parallel programming, an error-prone task due to synchronization issues, which may lead to abortion and production of incorrect data during execution of applications, and the inefficient use of computational resources. These problems may be very relevant in the case of long running applications with tight timelines to obtain critical results, quite common in the context of HPC. One possible solution to these problems is the formal analysis of the behavior of the components of an application through the cloud services, before their execution. Thus, the users of the components may know if a component can be safely used in their application. In this scenario, formal methods becomes useful. In this dissertation, it is proposed a process for specification and derivation of parallel components implementation for the cloud of components. This process involves the formal specification of the components behavior through contracts described using the Circus formal specification language. Then, through a refinement and translation process, which takes the contract as a start point, one may produce an implementation of a component that may execute on a parallel computing platform. Through this process, it becomes possible to offer guarantees to developers about the components behavior in their applications. To validate the proposed idea, the process is applied to contracts that have been described based on two benchmarks belonging to the NAS Parallel Benchmarks, widely adopted in HPC for evaluate the performance of parallel programming and computing platforms.

Orientador: Cecilia Mary Fischer Rubira / Tese (doutorado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-10T07:04:57Z (GMT). No. of bitstreams: 1 LimaFilho_FernandoJoseCastorde_D.pdf: 5063998 bytes, checksum: 8bfec9185fab14cb08c2a8b2ce7391a9 (MD5) Previous issue date: 2006 / Resumo: 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 not / Doutorado / Doutor em Ciência da Computação

Made available in DSpace on 2014-06-12T15:49:28Z (GMT). No. of bitstreams: 1 license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2009 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Um grande desafio da Engenharia de Software Baseada em Componentes (ESBC) é a qualidade dos componentes utilizados em um sistema. A confiabilidade de um sistema baseado em componentes depende da confiabilidade dos componentes dos quais ele é composto. Na ESBC, a busca, seleção e avaliação de componentes de software é considerado um ponto chave para o efetivo desenvolvimento de sistemas baseado em componentes. Até agora a indústria de software tem se concentrado nos aspectos funcionais dos componentes de software, deixando de lado uma das tarefas mais árduas, que é a avaliação de sua qualidade. Se a garantia de qualidade de componentes desenvolvidos in-house é uma tarefa custosa, a garantia da qualidade utilizando componentes desenvolvidos externamente os quais frequentemente não se tem acesso ao código fonte e documentação detalhada se torna um desafio ainda maior. Assim, esta Tese introduz um Framework de Qualidade de Componentes de Software, baseado em módulos bem definidos que se complementam a fim de garantir a qualidade dos componentes de software. Por fim, um estudo experimental foi desenvolvido e executado de modo que se possa analisar a viabilidade do framework proposto