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.

Made available in DSpace on 2014-12-17T15:47:53Z (GMT). No. of bitstreams: 1 DanielCS_DISSERT.pdf: 2517555 bytes, checksum: 7a87d4943b3ba068ea03a2691bda7bff (MD5) Previous issue date: 2011-02-17 / The process for choosing the best components to build systems has become increasingly complex. It becomes more critical if it was need to consider many combinations of components in the context of an architectural configuration. These circumstances occur, mainly, when we have to deal with systems involving critical requirements, such as the timing constraints in distributed multimedia systems, the network bandwidth in mobile applications or even the reliability in real-time systems. This work proposes a process of dynamic selection of architectural configurations based on non-functional requirements criteria of the system, which can be used during a dynamic adaptation. This proposal uses the MAUT theory (Multi-Attribute Utility Theory) for decision making from a finite set of possibilities, which involve multiple criteria to be analyzed. Additionally, it was proposed a metamodel which can be used to describe the application s requirements in terms of the non-functional requirements criteria and their expected values, to express them in order to make the selection of the desired configuration. As a proof of concept, it was implemented a module that performs the dynamic choice of configurations, the MoSAC. This module was implemented using a component-based development approach (CBD), performing a selection of architectural configurations based on the proposed selection process involving multiple criteria. This work also presents a case study where an application was developed in the context of Digital TV to evaluate the time spent on the module to return a valid configuration to be used in a middleware with autoadaptative features, the middleware AdaptTV / O processo para a escolha dos melhores componentes a serem usados na constru??o de sistemas tem se tornado cada vez mais complexo; isso se torna mais cr?tico quando precisamos considerar v?rias combina??es de componentes a serem escolhidos no contexto de uma configura??o arquitetural. Essa preocupa??o ocorre, principalmente, quando lidamos com sistemas que envolvem requisitos cr?ticos, como por exemplo, as restri??es temporais nos sistemas multim?dia distribu?dos, a largura de banda da rede nas aplica??es m?veis ou at? mesmo a confiabilidade em sistemas de tempo real. Este trabalho prop?e um processo de sele??o din?mica de configura??es arquiteturais baseado nos requisitos n?o funcionais do sistema, os quais poder?o ser utilizados durante uma adapta??o din?mica. A presente proposta utiliza a teoria MAUT (Multi-Attribute Utility Theory) para a tomada de decis?o a partir de um conjunto finito de possibilidades, as quais envolvem m?ltiplos crit?rios a serem analisados. Adicionalmente, foi proposto um metamodelo capaz de descrever as necessidades da aplica??o, em termos dos requisitos n?o funcionais e seus respectivos valores esperados, para que as mesmas possam ser interpretadas pelo processo a fim de realizar a sele??o da configura??o desejada. Como prova de conceito, foi implementado um m?dulo que realiza a escolha din?mica das configura??es, o MoSAC. Esse m?dulo foi implementado utilizando a abordagem de desenvolvimento baseado em componentes (DBC) realizando a sele??o das configura??es arquiteturais baseado no processo de sele??o proposto neste trabalho envolvendo m?ltiplos crit?rios. Esse trabalho tamb?m apresenta um estudo do caso onde foi desenvolvido uma aplica??o no contexto de TV Digital para avaliar o tempo que o m?dulo gasta para retornar uma configura??o v?lida a ser utilizada em um middleware com caracter?sticas autoadaptativas; para isso foi utilizado o middleware AdaptTV

Made available in DSpace on 2014-12-17T15:48:11Z (GMT). No. of bitstreams: 1 RomeuFO_DISSERT.pdf: 4788717 bytes, checksum: 385df6854e63e9219358e4b7d5fe1ee8 (MD5) Previous issue date: 2014-02-26 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / In the context of Software Engineering, web accessibility is gaining more room, establishing itself as an important quality attribute. This fact is due to initiatives of institutions such as the W3C (World Wide Web Consortium) and the introduction of norms and laws such as Section 508 that underlie the importance of developing accessible Web sites and applications. Despite these improvements, the lack of web accessibility is still a persistent problem, and could be related to the moment or phase in which this requirement is solved within the development process. From the moment when Web accessibility is generally regarded as a programming problem or treated when the application is already developed entirely. Thus, consider accessibility already during activities of analysis and requirements specification shows itself a strategy to facilitate project progress, avoiding rework in advanced phases of software development because of possible errors, or omissions in the elicitation. The objective of this research is to develop a method and a tool to support requirements elicitation of web accessibility. The strategy for the requirements elicitation of this method is grounded by the Goal-Oriented approach NFR Framework and the use of catalogs NFRs, created based on the guidelines contained in WCAG 2.0 (Web Content Accessibility Guideline) proposed by W3C / No contexto de Engenharia de Software, a Acessibilidade Web vem ganhando cada vez mais espa?o, se firmando como um importante atributo de qualidade. Esse fato se deve a iniciativas de institui??es como a W3C (World Wide Web Consortium) e ao surgimento de normas e leis como a Section 508 que fundamentam a import?ncia de elaborar sites e aplica??es Web acess?veis. Apesar dessas melhorias, a falta de acessibilidade na web ainda ? um problema persistente, e pode est? relacionada ao momento ou a fase em que este requisito ? tratado dentro do processo de desenvolvimento. Tendo em vista que a Acessibilidade Web geralmente ? considerada como um problema de programa??o ou tratada quando o aplicativo j? est? totalmente desenvolvido. Dessa forma, considerar a acessibilidade j? durante as atividades de an?lise e especifica??o de requisitos se mostra uma estrat?gia para facilitar o andamento do projeto, evitando retrabalho em fases avan?adas do desenvolvimento de software por causa de poss?veis erros, falhas ou omiss?es na elicita??o. O objetivo desta pesquisa ? desenvolver um m?todo e uma ferramenta para apoiar a elicita??o dos requisitos de acessibilidade web. A estrat?gia de elicita??o presente neste m?todo ? fundamentada atrav?s da abordagem orientada a metas do NFR Framework e na utiliza??o de cat?logos de RNFs, criados com base nas diretrizes contidas no WCAG 2.0 (Web Content Accessibility Guideline) proposto pela W3C