MENESES FILHO, Juarez de Lima. ArCatch: uma solução para verificação estática de conformidade arquitetural do tratamento de exceção. 2016. 81 f. Dissertação (Mestrado em Ciência da Computação)-Universidade Federal do Ceará, Fortaleza, 2016. / Submitted by Jonatas Martins (jonatasmartins@lia.ufc.br) on 2017-08-16T18:55:49Z No. of bitstreams: 1 2016_dis_jlmenesesfilho.pdf: 1440689 bytes, checksum: b5d68cda9ed0ed25ac65cb0ac5aacb9a (MD5) / Approved for entry into archive by Rocilda Sales (rocilda@ufc.br) on 2017-08-17T11:14:12Z (GMT) No. of bitstreams: 1 2016_dis_jlmenesesfilho.pdf: 1440689 bytes, checksum: b5d68cda9ed0ed25ac65cb0ac5aacb9a (MD5) / Made available in DSpace on 2017-08-17T11:14:12Z (GMT). No. of bitstreams: 1 2016_dis_jlmenesesfilho.pdf: 1440689 bytes, checksum: b5d68cda9ed0ed25ac65cb0ac5aacb9a (MD5) Previous issue date: 2016 / Exception handling is a common error recovery technique employed to improve software robustness. However, studies have reported that exception handling is commonly neglected by developers and is the least understood and documented part of a software project. The lack of documentation and difficulty in understanding the exception handling design can lead developers to violate important design decisions, triggering an erosion process in the exception handling design. Architectural conformance checking provides means to control the architectural erosion by periodically checking if the actual architecture is consistent with the planned one. Nevertheless, available approaches do not provide a proper support for exception handling conformance checking. To fulfill this gap, this work proposes ArCatch: an architectural conformance checking solution to deal with the exception handling design erosion. ArCatch provides: (i) a declarative domain-specific language for expressing design constraints regarding exception handling; and (ii) a design rule checker to automatically verify the exception handling conformance. The usefulness and effectiveness of the approach was evaluated in an evolution scenario composed by 10 versions of an existing web-based Java system. Each version was checked against the same set of exception handling design rules. Based on the results and the feedback given by the system’s software architect, the ArCatch proved useful and effective in the identification of existing exception handling erosion problems and locating its causes in the source code. / O tratamento de exceções é uma técnica de recuperação de erros tipicamente empregada na melhoria da robustez de software. No entanto, estudos recentes relatam que o tratamento de exceção é comumente negligenciado pelos desenvolvedores e é a parte menos compreendida e documentada de um projeto de software. A falta de documentação e a difculdade em compreender o design do tratamento de exceção pode levar os desenvolvedores a violarem decisões de design importantes, desencadeando um processo de erosão no design do tratamento de exceção. A verifcação de conformidade arquitetural fornece meios para controlar a erosão arquitetural, verifcando periodicamente se a arquitetura real mantem-se consistente com a arquitetura planejada. No entanto, as abordagens disponíveis não fornecem um suporte adequado para verificação da conformidade do tratamento de exceção. Para preencher essa lacuna, neste trabalho é proposta ArCatch: uma solução de verificação de conformidade arquitetural para lidar com a erosão do design do tratamento de exceção. ArCatch fornece: (i) uma linguagem específica de domínio declarativa para expressar restrições de design relativas ao tratamento de exceção; e (ii) um verificador de regras de design para verificar automaticamente a conformidade do tratamento de exceção. Foi avaliada a utilidade e a eficácia da abordagem proposta em um cenário de evolução composto por 10 versões de um sistema Java web existente. Cada versão foi verificada contra o mesmo conjunto de regras de design de tratamento de exceção. Com base nos resultados e no feedback fornecido pelo arquiteto de software do sistema, a ArCatch provou ser útil e eficaz na identifcação de problemas de erosão do tratamento de exceção existentes e localizar suas causas no código-fonte.

[pt] Durante a manutenção de sistemas de software, os projetos arquiteturais podem se degradar através dos processos de erosão e descaracterização arquitetural. Estes processos estão usualmente entrelaçados e, consequentemente, sintomas de descaracterização arquitetural favorecem a manifestação posterior de sintomas de erosão e vice-versa. De fato, estudos empíricos recentes revelam que estes sintomas tendem a afetar os mesmos módulos de um sistema. Desta forma, arquitetos devem elaborar estratégias híbridas para uma prevenção simultânea de ambos os processos de degradação arquitetural. Embora as especificações de regras arquiteturais demandem um esforço considerável, estas são frequentemente similares em diversos projetos de uma mesma companhia ou de um mesmo domínio de aplicação. Essa dissertação descreve a linguagem específica de domínio TamDera para: (i) especificar estratégias de regras para permitir prevenção simultânea de ambos os processos de erosão e descaracterização arquitetural, e (ii) prover o reúso tanto hierárquico quanto composicional de regras de projetos em múltiplos contextos. Essa dissertação apresenta a avaliação empírica da linguagem em termos de provisão de suporte para descrição e reúso de regras de projeto em cinco projetos de software. O presente trabalho também apresenta um protótipo que suporta a utilização da linguagem para detecção de sintomas de degradação arquitetural.. Nossos resultados sugerem que arquitetos podem se beneficiar de abordagens que permitam a definição e reúso de regras híbridas para detectar ocorrências de ambos os processos de erosão e descaracterização arquitetural in diversos cenários. / [en] During the maintenance of software systems, their architecture often degrades through processes of architectural erosion and drift. These processes are often intertwined and, as a consequence, a given module in the code becomes the locus of both erosion and drift symptoms. Architects should elaborate strategies for detecting co-occurrences of both degradation symptoms. Strategies for enabling the detection of these symptoms are based on design rules. While the specification of design rules is time-consuming, they are often similar across different software projects. In this context, the contribution of this dissertation is threefold. First, it presents TamDera, an unified domain-specific language for: (i) specifying rule-based strategies to detect both erosion and drift symptoms, and (ii) promoting the hierarchical and compositional reuse of design rules across multiple contexts. Second, a tool implementation for supporting the language usage and rule enforcement is also presented in this dissertation. Third, we evaluated the language in supporting the description and reuse of design rules on five software projects. Our evaluation revealed that architects could be benefited by using TamDera to blend and reuse rules for detecting erosion and drift occurrences in multiple scenarios.

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2017-03-21T18:19:38Z No. of bitstreams: 1 JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2017-03-27T21:23:41Z (GMT) No. of bitstreams: 1 JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5) / Made available in DSpace on 2017-03-27T21:23:41Z (GMT). No. of bitstreams: 1 JulioCesarLeoncioDaSilva_DISSERT.pdf: 1394881 bytes, checksum: 747cd2cfe814ce2f10219f841055abdb (MD5) Previous issue date: 2016-08-25 / Muitas vezes o arquiteto de software respons?vel pela defini??o e avalia??o da arquitetura de software n?o consegue estabelecer quais requisitos n?o-funcionais devem ser priorizados no desenvolvimento de seus sistemas. Com isso, falhas podem ocorrer durante a execu??o do sistema demandando mais tempo e recursos para que seja corrigido. Em muitos casos, com a inexperi?ncia dos arquitetos ou a necessidade de disponibiliza??o r?pida de um sistema, os requisitos n?o-funcionais n?o s?o considerados durante a defini??o da arquitetura de software e tamb?m n?o ? feita a devida documenta??o da arquitetura, tornando dif?cil o acesso e entendimento da arquitetura pelos demais integrantes da equipe e dificultando a manuten??o de componentes/m?dulos da arquitetura e respectivos relacionamentos. Este trabalho buscou levantar junto ?s empresas de software, p?blicas e privadas, quais as principais estrat?gias utilizadas na defini??o e avalia??o da arquitetura, principalmente na obten??o e cumprimento dos requisitos n?o-funcionais, e documenta??o arquitetural. Nosso estudo contou com a participa??o de 17 arquitetos de software para responder o question?rio proposto. Com a realiza??o do question?rio identificamos que os requisitos n?o-funcionais de desempenho e confiabilidade s?o os mais importantes a serem atendidos pela arquitetura e que mesmo com a exist?ncia de algumas abordagens para a avalia??o de arquiteturas, elas n?o parecem estar bem difundidas e/ou utilizadas entre os arquitetos. Ao tratar especificamente o requisito de desempenho, os arquitetos julgaram que em uma an?lise de desempenho de um sistema de software a informa??o mais importante a ser exibida deve ser o tempo de resposta das requisi??es a um determinado cen?rio, acompanhado do tempo de execu??o dos m?todos que fazem parte desse cen?rio. Em rela??o ? documenta??o arquitetural, a maioria dos entrevistados afirmaram utilizar, no m?nimo, algum tipo de documenta??o no momento de cria??o de um sistema de software, destacando-se a utiliza??o de diagramas de classe e de componentes como as formas mais comuns de documenta??o utilizadas pelos arquitetos. Al?m disso, o trabalho prop?e a utiliza??o de um guia que busca auxiliar arquitetos de software na atividade de avalia??o do cumprimento dos requisitos n?o-funcionais pela arquitetura durante a evolu??o do sistema, priorizando o requisito n?o-funcional de desempenho. Ao avaliar a aplica??o do guia, os entrevistados apontaram a abordagem de an?lise de logs para identificar os cen?rios priorit?rios numa avalia??o de desempenho como uma das principais contribui??es do guia e que poderia facilitar na identifica??o e compara??o das vers?es dos seus sistemas. / Usually, the software architect responsible for the software architecture definition and evaluation cannot prioritize which non-functional requirements must be prioritized during the development of their systems. Because of that, failures may happen during the system execution requiring more time and resources to fix them. In many cases, due to the inexperience of architects or the need for rapid deployment of a system, the non-functional requirements are not considered in the software architecture definition phase and its documentation is absent or incomplete, making the software architecture difficult to be understood, modified and envolved by other team members. This work investigates the main strategies and techniques used to document software architectures and to evaluate non-functional requirements by existing software development companies. Our study had the participation of 17 software architects to answer the survey. Our work identified that performance and reliability non-functional requirements are the most important to be addressed by the architecture and even with the existence of some approaches to evaluate architectures, they do not seem to be disseminated and used among architects. The architects judged that in a performance analysis of a software system the most important information to be displayed should be the response time of the system scenarios. Regarding architecture documentation, most interviewees stated that they used some kind of documentation. The use of class diagrams and component diagrams are the most common forms of documentation used by architects. Besides that, we propose a guide to help software architects in the task of achieving such non-functional requirements during the evolution of software systems. The proposed guide prioritizes the non-functional requirement of performance. The logs analysis approach to identify priority scenarios in a performance assessment was pointed out as one of the key contributions of the guide and could facilitate the identification and comparison of the versions of their systems.

[pt] Um dos principais sintomas de declínio da qualidade arquitetural em projetos de software é a manifestação contínua de anomalias de código. Quando estas anomalias não são detectadas e removidas com antecedência, a capacidade de evoluir e manter estes sistemas pode ser comprometida, e, eventualmente, uma reestruturação completa de suas arquiteturas é inevitável. Apesar da existência de diversas técnicas e ferramentas para detecção automática de anomalias de código, a identificação de anomalias que efetivamente causam problemas arquiteturais é ainda uma tarefa desafiadora e não trivial. Ademais, estudos realizados no contexto desta dissertação ostraram que desenvolvedores tendem a refatorar mais frequentemente anomalias que não causam problemas arquiteturais. Em especial, percebeu-se que desenvolvedores priorizam a refatoração de elementos de código que não afetam a arquitetura dos sistemas, como métodos privados ou módulos internos de um componente arquitetural. Neste contexto, o presente trabalho propõe uma abordagem para priorização de anomalias de código. Esta abordagem é composta por heurísticas que exploram diferentes fatores para identificar e ordenar as anomalias detectadas de acordo com suas relevâncias arquiteturais. Tais fatores compreendem desde a quantidade de mudanças realizadas no código ao longo da evolução dos sistemas, até os papéis arquiteturais por ele desempenhados. Foi ainda implementada uma ferramenta para aplicar tais heurísticas de priorização automaticamente em projetos Java. A abordagem proposta foi avaliada em 4 projetos de software de diferentes domínios. Tal avaliação revelou que mantenedores de software poderiam ser beneficiados pelas recomendações de priorização produzidas pela ferramenta, de modo a investir seus esforços de refatoração na solução de problemas arquiteturalmente relevantes. / [en] The progressive manifestation of code anomalies in a software system is a key symptom of its architecture quality decline. When those anomalies are not detected and removed early, the maintainability of software projects can be compromised irreversibly, and, eventually, a complete redesign is inevitable. Despite the existence of many techniques and tools for code anomaly detection, identifying anomalies that are more likely to cause architecture problems remains a challenging task. In fact, studies performed in the context of this dissertation show that even when there is tool upport for detecting code anomalies, developers seem to invest more time refactoring those that are not related to architectural problems. Moreover, we also found that developers frequently prioritize refactoring of code elements that do not contribute to a better adherence to the intended software architecture. In this context, this dissertation proposes a prioritization approach for identifying which anomalies in a system implementation are more harmful to the architecture. The proposed approach is composed of heuristic strategies that exploit several software project factors to identify and rank code anomalies by their architecture relevance. These factors range from the change characteristics to the potential architecture roles of software modules. Furthermore, we implemented tool support for applying our prioritization approach in Java projects. We also evaluated the prioritization approach on 4 software projects from different application domains. Our evaluation revealed that software maintainers could benefit from the recommended rankings for identifying which code anomalies are harming architecture the most, helping them investing their refactoring efforts into solving the architecturally relevant problems.

Systems-of-Systems (SoS) encompass diverse and independent systems that must cooperate with each other for performing a combined action that is greater than their individual capabilities. In parallel, architecture descriptions, which are the main artifact expressing software architectures, play an important role in fostering interoperability among constituents by facilitating the communication among stakeholders and supporting the inspection and analysis of the SoS from an early stage of its life cycle. The main problem addressed in this thesis is the lack of adequate architectural descriptions for SoS that are often built without an adequate care to their software architecture. Since constituent systems are, in general, not known at design-time due to the evolving nature of SoS, the architecture description must specify at design-time which coalitions among constituent systems are feasible at run-time. Moreover, as many SoS are being developed for safety-critical domains, additional measures must be placed to ensure the correctness and completeness of architecture descriptions. To address this problem, this doctoral project employs SoSADL, a formal language tailored for the description of SoS that enables one to express software architectures as dynamic associations between independent constituent systems whose interactions are mediated for accomplishing a combined action. To synthesize concrete architectures that adhere to one such description, this thesis develops a formal method, named Ark, that systematizes the steps for producing such artifacts. The method creates an intermediate formal model, named TASoS, which expresses the SoS architecture in terms of a constraint satisfaction problem that can be automatically analyzed for an initial set of properties. The feedback obtained in this analysis can be used for subsequent refinements or revisions of the architecture description. A software tool named SoSy was also developed to support the Ark method as it automates the generation of intermediate models and concrete architectures, thus concealing the use of constraint solvers during SoS design and development. The method and its accompanying tool were applied to model a SoS for urban river monitoring in which the feasibility of candidate abstract architectures is investigated. By formalizing and automating the required steps for SoS architectural synthesis, Ark contributes for adopting formal methods in the design of SoS architectures, which is a necessary step for obtaining higher reliability levels. / Sistemas-de-sistemas (SoS) englobam sistemas diversos e independentes que cooperam entre si para executar uma ação combinada que supera suas competências individuais. Em paralelo, descrições arquiteturais são artefatos que expressam arquiteturas de software, desempenhando no contexto de SoS um importante papel na promoção da interoperabilidade entre constituintes ao facilitar a comunicação entre interessados e apoiar atividades de inspeção e análise desde o início de seu ciclo de vida. O principal problema abordado nessa tese consiste na falta de descrições arquiteturais adequadas para SoS que estão sendo desenvolvidos sem um devido cuidado à sua arquitetura de software. Uma vez que os sistemas constituintes não são necessariamente conhecidos em tempo de projeto devido à natureza evolucionária dos SoS, a descrição arquitetural precisa definir em tempo de projeto quais coalisões entre sistemas constituintes são possíveis em tempo de execução. Como muitos desses sistemas são desenvolvidos para o domínio crítico de segurança, medidas adicionais precisam ser adotadas para garantir a correção e completude da descrição arquitetural. Visando tratar esse problema, esse projeto de doutorado emprega SosADL, uma linguagem formal criada especialmente para o domínio de SoS que permite expressar arquiteturas de software como associações dinâmicas entre sistemas independentes em que as interações devem ser mediadas para desempenhar uma ação conjunta. Em particular, é proposto um novo método formal, denominado Ark, para sistematizar os passos necessários na síntese de arquiteturas concretas aderentes a essa descrição. Para isso, o método cria um modelo formal intermediário, denominado TASoS, que expressa a arquitetura do SoS em termos de um problema de satisfatibilidade de restrições, possibilitando desse modo a verificação automática de um conjunto inicial de propriedades. O resultado obtido por essa análise pode ser utilizado em refinamentos e revisões subsequentes da descrição arquitetural. Uma ferramenta de apoio denominada SoSy também foi desenvolvida para automatizar a geração de modelos intermediários e arquiteturas concretas, ocultando o uso de solucionadores de restrições no projeto e desenvolvimento de SoS. O método e sua ferramenta foram aplicados em um modelo de SoS para monitoramento de rios em áreas urbanas em que a viabilidade de arquiteturas abstratas foi investigada. Ao formalizar e automatizar os passos necessários para a síntese arquitetural de SoS, é possível adotar métodos formais no projeto arquitetural de SoS, que são necessários para alcançar níveis maiores de confiabilidade.

System-of-Systems (SoS) refer to complex, large-scale, and sometimes critical software-intensive systems that has raised as a promising class of systems in several application domains. In parallel, software architectures play a significant role in the development of software-intensive systems, dealing with both functional and non-functional requirements. In particular, systematic processes to design SoS software architectures can tackle challenges from SoS development, including to handle collaboration of independent constituent systems with different owners, missions, and interests. Despite the relevance and necessity of software-intensive SoS for diverse application domains, most of their software architectures have been still developed in an ad hoc manner. In general, there is a lack of structured processes for architecting SoS, hindering the secure adoption of SoS, reducing possibilities of sharing common architectural solutions, and negatively impacting in the success rate for these systems. This thesis presents SOAR (\\General Process for Acknowledged SoS Software Architectures\") that supports the establishment of architectural design processes for acknowledged SoS. Conceived to provide different levels of support according to each SoS development context, it comprises a high level kernel that describes what must be done when architecting SoS and also three practices with specific activities and work products to guide how to perform architectural analysis, synthesis, and evaluation. To evaluate SOAR, three surveys, a viability study, and an experiment were conducted. Results achieved in these evaluation studies indicate that SOAR can positively support the instantiation of architecting processes for acknowledged SoS and, as a consequence, contribute to the development and evolution of these complex, software-intensive systems. / Sistemas-de-sistemas ou SoS (do inglês, \"Systems-of-Systems\"), são sistemas complexos de larga escala e, algumas vezes, críticos e intensivos a software que têm se mostrado uma classe de sistemas promissora em vários domínios de aplicação. Em paralelo, arquiteturas de software têm um papel importante no desenvolvimento de sistemas intensivos a software, tratando requisitos funcionais e não-funcionais. Processos sistemáticos para o design de arquiteturas de software de SoS podem lidar com desafios do desenvolvimento desses sistemas, incluindo a promoção da colaboração de sistemas constituintes independentes, envolvendo diferentes proprietários, missões e interesses. Embora SoS intensivos a software sejam relevantes e necessários em diversos domínios de aplicação, a maior parte de suas arquiteturas tem sido desenvolvidas de forma ad hoc. Há uma ausência de processos estruturados para arquitetar SoS, dificultando a adoção segura de SoS, reduzindo possibilidades de compartilhamento de soluções arquiteturais para problemas comuns e impactando negativamente no sucesso desses sistemas. Esta tese apresenta um processo geral para SoS reconhecidos chamado SOAR (do inglês, \"General Process for Acknowledged SoS Software Architectures\") que dá suporte ao estabelecimento de instâncias de processos para o design arquitetural desses sistemas. Concebido para prover diferentes níveis de suporte de acordo com o contexto de desenvolvimento de cada SoS, o SOAR é constituído por um kernel de alto nível que descreve o que precisa ser feito para arquitetar SoS e também por três práticas que descrevem atividades e produtos de trabalho para guiar como conduzir a análise, a síntese e a avaliação arquitetural. Na avaliação do SOAR, foram realizados três surveys, um estudo de viabilidade e um experimento. Os resultados obtidos indicam que o SOAR pode oferecer um suporte positivo na instanciação de processos para o design de SoS reconhecidos e, como consequência, contribuir para o desenvolvimento e a evolução destes sistemas complexos intensivos a software.

Arquiteturas de referência são construídas por combinarem as melhores praticas, padrões, plataformas e componentes para a construção e padronização de sistemas de software de um determinado domínio. De fato, diversas arquiteturas de referência podem ser encontradas para o domínio de sistemas embarcados, motivadas principalmente pela importância e complexidade crescentes que esses sistemas de software vêm apresentando. Dentre as atividades para elaboração de uma arquitetura de referência, a descrição apropriada dessa arquitetura é essencial para permitir que ela seja de fato utilizada. Contudo, não há na literatura um consenso sobre qual a melhor maneira de descrever arquiteturas de referência do domínio de sistemas embarcados, os tipos de informação que devem ser capturados ou ainda o conjunto de pontos de vista que pode ser construído. Visando sistematizar e padronizar a representação de arquiteturas de referência de sistemas embarcados, este trabalho propõe o método ProSA-Re. O método baseia-se nos resultados de uma revisão sistemática conduzida sobre o assunto e estabelece um conjunto de atividades e diretrizes para a construção da representação de arquiteturas de referência de sistemas embarcados. O método também esclarece o ciclo de vida de arquiteturas de referência, de modo a auxiliar na manutenção e na evolução das representações construídas com o seu apoio. Para ilustrar o ProSA-Re, uma representação da arquitetura de referência de sistemas multiagentes locais foi elaborada. Em seguida, a realização de uma avaliação com especialistas da área de arquitetura de software e um estudo de caso com usuários dessa representação permitiram a identicação de vantagens e limitações desse método. Espera-se que os resultados alcancados nesta dissertação possam contribuir para o reúso do conhecimento arquitetural e o desenvolvimento mais eficiente de sistemas de software do domínio de sistemas embarcados / Reference architectures combine the best practices, standards, platforms, and components to standardize software systems of a given domain. In this sense, reference architectures can be found for embedded systems, motivated by the increasing importance and complexity that these systems must cope with. In particular, the representation of the reference architecture is an essential activity for it to be used in practice. However, there is no consensus in the literature on what is the best way to describe reference architectures of embedded systems, including what types of information should be captured in those descriptions and also the set of viewpoints that could be adopted. Thus, this work establishes ProSA-Re, a method for systematizing and standardizing the representation of reference architectures of embedded systems. ProSA-Re considers the results of a systematic review on this subject and species a set of viewpoints, concerns, tasks, and guidelines to describe reference architectures of embedded systems. ProSA-Re also supports the reference architectures\' life cycle by clarifying the evolution of architectural descriptions built with it. To illustrate the method, a representation for the reference architecture of situated multiagent systems was built. Then, a case study was conducted to evaluate the resulting representation and specialists were consulted to evaluate the method description. We hope with this method to further improve the reuse of architectural knowledge, thus contributing for the development of software systems in this domain

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-05-08T17:28:24Z No. of bitstreams: 1 IZABELA VANESSA DE ALMEIDA MELO - DISSERTAÇÃO PPGCC 2015..pdf: 3198472 bytes, checksum: 824f30587ab3b750011a08d2e5d6019a (MD5) / Made available in DSpace on 2018-05-08T17:28:24Z (GMT). No. of bitstreams: 1 IZABELA VANESSA DE ALMEIDA MELO - DISSERTAÇÃO PPGCC 2015..pdf: 3198472 bytes, checksum: 824f30587ab3b750011a08d2e5d6019a (MD5) Previous issue date: 2015-09-10 / Desde os anos 90 a comunidade científica desempenha esforços para estudar e evoluir aspectos relacionados à Arquitetura de Software, aumentando seu volume de publicação a partir de 1999. O aumento significativo das publicações nos últimos anos demonstra a importância e preocupação que a academia tem com relação a essa área. Porém, a partir da troca de experiência entre pesquisadores e profissionais da área, percebe-se que a indústria não parece conhecer/utilizar o que é proposto pela academia. O contexto teórico sobre arquitetura de software, documentação arquitetural e verificação de conformidade arquitetural já é conhecido no meio acadêmico. Porém, qual é o contexto deles dentro da indústria? Como os profissionais definem o termo "arquitetura desoftware"? Como os profissionais realizam (se realizam) a documentação arquitetural? Como realizam (se realizam) a verificação de conformidade arquitetural? O que eles pensam sobre ferramentas de apoio à verificação de conformidade arquitetural? Para responder essas questões, realizamos um estudo qualitativo dividido em 3 etapas. Primeiro, aplicamos um survey exploratório com o objetivo de entender o ambiente prático para ter uma noção sobre o contexto em foco. Enviamos o questionário para 149 profissionais e 4 grupos de discussão, obtendo uma taxa de resposta de 24,1%. Na segunda etapa entrevistamos 14 profissionais voluntários que responderam o survey exploratório (taxa de resposta de 40%). O objetivo desta etapa foi nos aprofundarmos no contexto em foco. Por fim, nossa última etapa consistiu de um survey confirmatório. Enviamos o questionário para os usuários do GitHub que possuem endereços de e-mail visíveis e tem mais de 100 seguidores (obtivemos uma taxa de resposta de 7,74%). Como resultados principais, observamos que não há uma única definição para o termo "arquitetura de software", dependendo de fatores desde a experiência do profissional até a empresa em que trabalham. Além disso, existem documentações arquiteturais, mas, a sua maioria não é rigorosa, formal e não é atualizada. Nem todos realizam verificação de conformidade arquitetural, e, quando realizam, normalmente é feita de forma manual. Os principais motivos para a não documentação e/ou verificação são falta de tempo ou falta de necessidade. Porfim, as ferramentas de apoio à verificação de conformidade arquitetural não são muito utilizadas e/ou conhecidas. / Since the 90’s a big effort has been applied in the academy to study and evolve aspects related to Software Architecture, increasing the amount of publications from 1999 to the present-day. The significant rise in the number of publications in the last few years shows how much importance and concern academia gives to this particular area. However, after discussing what has been experienced by researchers and professionals of this area, it is possible to notice that the industry does not know/use what is proposed in the academy. The theoretical context about software architecture, architectural documentation and architectural conformance checking is already known. However, what about the practical/industrial context? How do the professionals define “software architecture”? How do they document (if they do) the architecture? How do they perform (if they do) architectural conformance checking? What do they think about support tools for architectural conformance checking? Aiming to answer these questions, we performed a 3-step qualitative study. Firstly, we applied an exploratory survey with the goal of understanding the practical environment and having a better notion about the context of our study. We sent the survey to 149 professionals and 4 discussion groups, getting 24.1% of response rate. In the second phase we interviewed 14 volunteered professionals who responded the exploratory survey (response rate of 40%). In this phase we wanted to deeply understand the context of your study. Finally, the last phase consisted of a confirmatory survey which goal was to confirm our findings. We sent the survey to GitHub users with public e-mails and more than 100 followers, getting 7.74% of response rate. As main results we observed that there is not a single definition of“software architecture” and that it depends on several factors, as the professional’s experience and the company in which he/she works. The architecture is sometimes documented but, most of the time, the documentation is incomplete, informal and outdated. In many cases, architectural conformance checking is not performed or it is performed manually. The main reasons for not documenting or verifying the architecture are lack of time and/or need. Finally, the support tools for architectural conformance checking are not often used and not well known.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-06-14T14:46:42Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) completa.pdf: 3521353 bytes, checksum: 5e3d6b5f886f0a1f26221fd82af32df8 (MD5) / Made available in DSpace on 2016-06-14T14:46:42Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) completa.pdf: 3521353 bytes, checksum: 5e3d6b5f886f0a1f26221fd82af32df8 (MD5) Previous issue date: 2010-03-05 / Engenharia de Requisitos (ER) e Projeto de Arquitetura de Software (PAS) são atividades iniciais de um processo de desenvolvimento de software. Desde que sistemas de software atuais apresentam uma crescente complexidade, diversidade e longevidade, o desenvolvimento destes sistemas deve considerar o uso de apropriados métodos e linguagens de modelagens para ER e PAS. Um grande desafio, neste contexto, é o desenvolvimento de métodos sistemáticos para projetar arquiteturas que satisfaçam especificações de requisitos. Além disso, com o uso de processos iterativos e incrementais de desenvolvimento de software considerados como um padrão de fato, uma forte integração entre atividades de ER e PAS podem facilitar a rastreabilidade e a propagação de mudanças entre os modelos produzidos nestas atividades. No entanto, muitos passos para gerar modelos de arquitetura a partir de modelos de requisitos são feitos por intuição ou conhecimento na arquitetura. Esta tese apresenta STREAM (Strategy for Transition between Requirements models and Architectural Models – Estratégia para Transição entre modelos de requisitos e modelos arquiteturais) que é um processo sistemático baseado em transformações de modelos para gerar modelos arquiteturais a partir de modelos de requisitos incluindo regras de transformações horizontais e verticais. As regras horizontais são aplicadas nos modelos de requisitos resultando em modelos intermediários próximos de modelos arquiteturais. Transformações verticais mapeam estes modelos intermediários em modelos arquiteturais. As atividades relacionadas ao projeto arquitetural envolvem seleção e aplicação de padrões arquiteturais que melhor satisfaçam aos requisitos não funcionais. Em nosso trabalho, modelos de requisitos são descritos usando i* (iStar), uma linguagem de modelagem orientada a objetivos definida em termos de atores estratégicos e dependências sociais entre eles. Enquanto que modelos arquiteturais são descritos usando linguagem de descrição arquitetural Acme que fornece um framework estrutural simples para representar arquitetura. Requisitos não funcionais são usados para selecionar entre soluções arquiteturais e determinar os padrões arquiteturais que são aplicados. Dois casos de estudos são usados para mostrar a viabilidade da nossa abordagem: sistema de recomendação Web e um sistema de informação Web. / Requirements engineering (RE) and software architecture design (SAD) are initial activities of a software development process. Since current software systems present increasing complexity, diversity and longevity, their development must consider the use of proper methods and modeling languages both for RE and SAD. A great challenge, in this context, is the development of systematic methods for designing architectures that satisfy requirements specifications. Besides, with the widely use of iterative and incremental software development processes as the de facto standard, a strong integration between RE and SAD activities can facilitate traceability and the propagation of changes between the models produced in these activities. However, many steps toward generating architecture models from requirements models are driven by intuition and architectural knowledge. This thesis presents STREAM (Strategy for Transition between Requirements models and Architectural Models) that is a systematic process based on model transformations to generate architectural models from requirements models and includes horizontal and vertical transformations rules. The horizontal transformations are applied to the requirements models resulting in intermediary requirements models closer to architectural models. Vertical transformations map these intermediary models into architectural models. The activities related to architectural design involves the selection and application of architectural patterns that best satisfy non-functional requirements. In our process, requirements models are described using the i* (iStar), a goal oriented modeling language defined in terms of strategic actors and social dependencies among them. Whereas architectural models are described using the Acme ADL which provides a simple structural framework for representing architectures. Non-functional requirements are used to select among architectural solutions and determine the architectural patterns that are applied. Two real case studies are used to show the feasibility of our process: a web-based recommendation system and a web-based information system.

Submitted by Cláudia Bueno (claudiamoura18@gmail.com) on 2015-12-04T17:46:01Z No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2015-12-07T11:12:37Z (GMT) No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-12-07T11:12:37Z (GMT). No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2015-09-11 / The SoftwareTechnicalDebtaimstocalculatecostsfromthefailuretocomplywithqua- lity standardsinthedevelopmentprocess,suchaslackofdocumentation,baddevelop- ment practicesanddisobediencetospecificcodingrulesofaproject.Oneoftheconcerns of organizationsandsoftwareengineersistoensuresuchqualitystandards,however,the humane wayofdoingthiscontrolallowsmistakeswhichconsequentlycausesTechnical Debt, whichintheshorttermarenotaproblem,butinthelongruncandestroyentire softwarestructures.Basedonthisproblem,itwillbeproposedanapproachforcalcu- lating theDesignTechnicalDebtofapplicationsdevelopedinJava.Themethodsused for thispurposeinvolvedataminingofopensourcecoderepositories,defecttracking softwaredatabases,timecorrectionestimativeofdesignrulesviolationandarchitectural compliance check. / A estimativadeDívidaTécnicadeSoftwaretemcomoobjetivocalcularoscustosdonão- cumprimento depadrõesdequalidadenoprocessodedesenvolvimento,taiscomofaltade documentação, máspráticasdedesenvolvimentoedesobediênciaàsregrasdecodificação específicas deumprojeto.Umadaspreocupaçõesdeorganizaçõeseengenheirosde softwareégarantirtaispadrõesdequalidade,noentanto,aformahumanadefazereste controle permiteerrosque,consequentemente,ocasionamDívidaTécnica,queemcurto prazo nãosãoumproblema,masemlongoprazopodedestruirestruturasdesoftware inteiras. Combasenesteproblema,serápropostaumaabordagemparaocálculodaDívida Técnica deDesigndeaplicaçõesdesenvolvidasemJava.Osmétodosutilizadosparaeste fim envolvemamineraçãodedadosderepositóriosdecódigoaberto,bancosdedados de softwarederastreamentodedefeitos,estimativadotempodecorreçãodeviolaçãode regrasdedesigneverificaçãodeconformidadearquitetural.