[pt] O trabalho a seguir apresenta uma proposta de metodologia de gerência de projetos de software aderente a pequenos projetos e fortemente inspirada em metodologias já consagradas como Unified Process e eXtreme Programming. O objetivo é prover um processo ágil, adaptável porém prescritivo. Chegaremos a um processo de fácil implantação e controle e menos dependente da qualidade técnica da equipe de desenvolvimento. A seguir, será apresentado um estudo de caso conduzido em ambiente real, por uma equipe de um pequeno empreendimento que consiste no relato do processo de amadurecimento e implantação do processo proposto, com uma análise do trabalho de implantação de processos de desenvolvimento em empreendimentos emergentes na área de TI. / [en] The following work presents a proposal of software project management methodology applicable to small projects and strongly inspired by already well established methodologies such as the Unified Process and eXtreme Programming. The objective of this proposal is to provide an agile process that is adaptable yet prescriptive. Through this one plans to arrive at a process of easy implementation and control, and less dependent on the technical quality of the development team. Subsequently, a case study will be presented that was conducted in a real environment, on a small enterprise development team. It consists of a report on the maturing and implementation of the proposed process and an analysis of the work of implementing development procedures in emerging enterprises in the IT area.

Made available in DSpace on 2014-12-17T15:47:51Z (GMT). No. of bitstreams: 1 GeamCA_3.pdf: 4100171 bytes, checksum: a5754ac2b6b60fbd217e904c104737e4 (MD5) Previous issue date: 2009-08-11 / This paper proposes a systematic approach to management of variability modelsdriven and aspects using the mechanisms of approaches Aspect-Oriented Software Development (AOSD) and Model-Driven Development (MDD). The main goal of the approach, named CrossMDA-SPL, is to improve the management(ger?ncia), modularization and isolation ou separation of the variability of the LPSs of architecture in a high level of abstraction (model) at the design and implementing phases of development Software Product Lines (SPLs), exploiting the synergy between AOSD and MDD. The CrossMDA-SPL approach defines some artifacts basis for advance the separation clear in between the mandatory (bounden) and optional features in the architecture of SPL. The artifacts are represented by two models named: (i) core model (base domain) - responsible for specify the common features the all members of the SPL, and (ii) variability model - responsible for represent the variables features of SPL. In addition, the CrossMDA-SPL approach is composed of: (i) guidelines for modeling and representation of variability, (ii) CrossMDA-SPL services and process, and (iii) models of the architecture of SPL or product instance of SPL. The guidelines use the advantages of AOSD and MDD to promote a better modularization of the variable features of the architecture of SPL during the creation of core and variability models of the approach. The services and sub-processes are responsible for combination automatically, through of process of transformation between the core and variability models, and the generation of new models that represent the implementation of the architecture of SPL or a instance model of SPL. Mechanisms for effective modularization of variability for architectures of SPL at model level. The concepts are described and measured with the execution of a case study of an SPL for management systems of transport electronic tickets / Este trabalho prop?e uma abordagem sistem?tica para ger?ncia de variabilidades dirigida por Modelos e Aspectos usando os mecanismos das abordagens de Desenvolvimento de Software Orientado a Aspectos (DSOA) e Desenvolvimento Dirigido por Modelos (DDM). O objetivo central da abordagem, denominada CrossMDA-SPL, ? melhorar a ger?ncia, modulariza??o e isolamento das variabilidades da arquitetura de LPSs em um n?vel de abstra??o alto (modelo) nas fases de projeto e implementa??o de dom?nio de desenvolvimento de Linhas de Produto de Software (LPSs), explorando a sinergia entre o DSOA e DDM. A abordagem CrossMDA-SPL define alguns artefatos base para promover a separa??o clara entres as features mandat?rias (obrigat?rias) e opcionais na arquitetura da LPS. Os artefatos s?o representados por dois modelos denominados: (i) modelo do n?cleo (dom?nio base) respons?vel por especificar as features comuns a todos os membros da LPS; e (ii) modelo de variabilidades respons?vel por representar as features vari?veis da LPS. Em adi??o, a abordagem CrossMDA-SPL ? composta por: (i) diretrizes para modelagem e representa??o das variabilidades; (ii) servi?os e processo CrossMDA-SPL; e (iii) modelos da arquitetura da LPS ou inst?ncia do produto da LPS. As diretrizes utilizam as vantagens de DSOA e DDM para promover uma melhor modulariza??o das features vari?veis da arquitetura da LPS durante a cria??o dos modelos do n?cleo e de variabilidades da abordagem. Os servi?os e subprocessos s?o respons?veis pela combina??o autom?tica, atrav?s de processos de transforma??o, entre os modelos de n?cleo e variabilidades, e a gera??o dos novos modelos que representam a implementa??o da arquitetura de LPS ou um modelo de inst?ncia da LPS. Apresentamos mecanismos para uma eficaz modulariza??o de variabilidades para arquiteturas de LPS no n?vel de modelo. Os conceitos s?o mostrados e avaliados com a execu??o de um estudo de caso de uma LPS para sistemas de gerenciamento de bilhetes eletr?nicos de transporte.

Made available in DSpace on 2014-12-17T15:47:55Z (GMT). No. of bitstreams: 1 LucasSP_DISSERT.pdf: 4412437 bytes, checksum: 1797ce9cec4016d1d5518d6d933435d2 (MD5) Previous issue date: 2010-12-16 / Many challenges have been imposed on the middleware to support applications for digital TV because of the heterogeneity and resource constraints of execution platforms. In this scenario, the middleware must be highly configurable so that it can be customized to meet the requirements of applications and underlying platforms. This work aims to present the GingaForAll, a software product line developed for the Ginga - the middleware of the Brazilian Digital TV (SBTVD). GingaForAll adds the concepts of software product line, aspect orientation and model-driven development to allow: (i) the specification of the common characteristics and variables of the middleware, (ii) the modularization of crosscutting concerns - both mandatory and concepts variables - through aspects, (iii) the expression of concepts as a set of models that increase the level of abstraction and enables management of various software artifacts in terms of configurable models. This work presents the architecture of the software product line that implements such a tool and architecture that supports automatic customization of middleware. The work also presents a tool that implements the process of generating products GingaForAll / V?rios desafios t?m sido impostos a middleware para suporte a aplica??es de TV digital devido a heterogeneidade e restri??es de recursos das plataformas de execu??o. Nesse cen?rio, o middleware deve ser altamente configur?vel de forma a poder ser customizado para atender aos requisitos das aplica??es e das plataformas subjacentes. Esse trabalho tem como objetivo apresentar o GingaForAll, uma linha de produtos de software desenvolvida para o Ginga o middleware do Sistema Brasileiro de TV Digital (SBTVD). GingaForAll agrega os conceitos de linha de produtos de software, orienta??o a aspectos e desenvolvimento dirigido a modelos de forma a permitir: (i) a especifica??o das caracter?sticas comuns e vari?veis do middleware; (ii) a modulariza??o dos conceitos transversais tanto conceitos obrigat?rios quanto vari?veis atrav?s de aspectos; (iii) a express?o de conceitos como um conjunto de modelos que aumentam o n?vel de abstra??o e permite o gerenciamento de diferentes artefatos de software em termos de modelos configur?veis. Esse trabalho apresenta a arquitetura da linha de produtos de software e uma ferramenta que implementa tal arquitetura e que oferece suporte para customiza??es autom?ticas do middleware. O trabalho tamb?m apresenta uma ferramenta que implementa o processo de gera??o de produtos GingaForAll

Made available in DSpace on 2014-12-17T15:47:59Z (GMT). No. of bitstreams: 1 EbertonSM_DISSERT.pdf: 4801479 bytes, checksum: 4ff5d2fe556a6d3554decf638f20261c (MD5) Previous issue date: 2010-08-02 / Aspect-Oriented Software Development (AOSD) is a technique that complements the Object- Oriented Software Development (OOSD) modularizing several concepts that OOSD approaches do not modularize appropriately. However, the current state-of-the art on AOSD suffers with software evolution, mainly because aspect definition can stop to work correctly when base elements evolve. A promising approach to deal with that problem is the definition of model-based pointcuts, where pointcuts are defined based on a conceptual model. That strategy makes pointcut less prone to software evolution than model-base elements. Based on that strategy, this work defines a conceptual model at high abstraction level where we can specify software patterns and architectures that through Model Driven Development techniques they can be instantiated and composed in architecture description language that allows aspect modeling at architecture level. Our MDD approach allows propagate concepts in architecture level to another abstraction levels (design level, for example) through MDA transformation rules. Also, this work shows a plug-in implemented to Eclipse platform called AOADLwithCM. That plug-in was created to support our development process. The AOADLwithCM plug-in was used to describe a case study based on MobileMedia System. MobileMedia case study shows step-by-step how the Conceptual Model approach could minimize Pointcut Fragile Problems, due to software evolution. MobileMedia case study was used as input to analyses evolutions on software according to software metrics proposed by KHATCHADOURIAN, GREENWOOD and RASHID. Also, we analyze how evolution in base model could affect maintenance on aspectual model with and without Conceptual Model approaches / O Desenvolvimento de Software Orientado a Aspectos (DSOA) ? uma t?cnica que complementa o Desenvolvimento de Software Orientado a Objetos (DSOO) modularizando diversos conceitos que as abordagens para suporte ao DSOO n?o conseguiam modularizar adequadamente. No entanto, o estado da arte atual do DSOA sofre com a evolu??o de software, principalmente porque as defini??es de aspectos podem deixar de funcionar corretamente quando elementos do Modelo Base evoluem. Uma abordagem promissora para tratar este problema ? a defini??o de pontos de corte (pointcuts) baseados em modelos (model based-pointcuts), onde pontos de corte s?o definidos em termos de elementos de um Modelo Conceitual que s?o menos suscept?veis a evolu??o que elementos do Modelo Base. Com base nessa estrat?gia, este trabalho define um Modelo Conceitual em um alto n?vel de abstra??o onde se podem definir padr?es de software e de arquiteturas que atrav?s de t?cnicas de Desenvolvimento Dirigido a Modelos (Model Driven Development -MDD) podem ser instanciados e compostos em linguagens de descri??o arquitetural que suportem a modelagem de aspectos em n?vel de arquitetura. A abordagem MDD empregada permite ainda a propaga??o de conceitos descritos no Modelo Conceitual para outros n?veis de abstra??es como o de projeto com o uso de regras de transforma??o MDA (Model Driven Architecture). Este trabalho tamb?m mostra o plug-in para a plataforma Eclipse chamado de AOADLwithCM que foi implementado para dar suporte ao processo de desenvolvimento abordado. Esse plug-in foi utilizado para implementar um estudo de caso baseado no Sistema MobileMedia. Tal estudo de caso ilustra passo-a-passo a t?cnica que utiliza um Modelo Conceitual no DSOA para minimizar problemas de evolu??o (mais especificamente a Fragilidade de Pontos de Corte). O MobileMedia tamb?m foi usado como fonte para an?lise da abordagem sob m?tricas de software propostas por KHATCHADOURIAN, GREENWOOD e RASHID, e sob a perspectiva de manutenabilidade de software com e sem o Modelo Conceitual

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T22:55:43Z No. of bitstreams: 1 CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5) / Made available in DSpace on 2018-08-31T22:55:43Z (GMT). No. of bitstreams: 1 CATUXE VARJÃO DE SANTANA OLIVEIRA - PPGCC DISSERTAÇÃO 2013..pdf: 11354934 bytes, checksum: 6a23f31ef43ba211aeaa89eb36061a43 (MD5) Previous issue date: 2013-03-15 / A escrita de especificações formais por contratos é uma maneira confiável e prática de construir softwares, em que desenvolvedores e clientes mantêm um acordo contendo direitos e obrigações a serem cumpridos. Essas responsabilidades são expressas basicamente através de pré-condições, pós-condições, e invariantes. Como exemplo de linguagem de especificação por contrato tem-se Java Modeling Language (JML) específica para programas Java. Apesar de a especificação formal melhorar a confiabilidade do software, deve-se haver certificação de que a implementação está em conformidade com a especificação definida. Verificação de conformidade em programas com contratos é geralmente realizada através de análises manuais ou verificação dinâmica, e em fases tardias do processo de desenvolvimento do software, ou seja, quando o produto final encontra-se disponível para o cliente. Nesta situação, o tempo despendido para detectar não-conformidades pode ser muito longo, ocasionando, consequentemente, atrasos no cronograma e aumento nos custos. Neste trabalho, propomos uma abordagem para checar conformidade entre código fonte e especificação formal por contratos através da geração e execução de testes. Testes de unidade são gerados automaticamente, resultando em casos de testes com sequências de chamadas aos métodos e construtores. Os contratos são transformados em assertivas que funcionam como oráculo para os testes. Esta abordagem não garante corretude total do software, mas aumenta a confiança quando uma não-conformidade é encontrada e, além disso, encoraja o uso de especificação por contratos. Nós implementamos JMLOK, uma ferramenta que executa os passos desta abordagem automaticamente no contexto de programas Java especificados com Java Modeling Language (JML). JMLOK foi avaliada em grupos de programas Java/JML, incluindo um módulo do projeto JavaCard. Todas as unidades experimentais totalizam 18 KLOC e 5K de linhas de especificação JML. Todo o processo consumiu menos que 10 minutos de execução e gerou como resultado a detecção de 29 não-conformidades. As causas das ocorrências das não-conformidades foram analisadas manualmente e classificadas em categorias de falhas. / Writing formal specifications by contracts is a practical and reliable way to build softwares in which developers and clients keep an agreement with rights and obligations to be fulfilled. These responsibilities are expressed basically by pre-conditions, post-conditions and invariants. As example of specification language by contract there is Java Modeling Language (JML) that is specific to Java programs. Although formal specification improves software rehabihty, it should exist certification of conformance with defined specification. Verify conformance between programs and contracts is usually performed by manual analysis or dynamic verification, and in late stages of software development process, that is, when the final product is available to client. In this situation, the time required to detect nonconformances could be so long, causing, consequently, schedule delays and increased costs. In this work, we propose an approach to check conformance between source code and contract formal specification through testing generation and execution. Unit tests are generated automatically resulting in test cases with call sequences of methods and constructors. The contracts are translated in assertions that work like test oracle. We have implemented JMLOK, a tool performs the approach steps automatically in the context of Java programs specified with Java Modeling Language (JML). JMLOK was evaluated in Java/JML programs groups, including a module of the JavaCard project. All the experimental units totalize 18 KLOC and 5K lines of JML specification. All process took less than 10 minutes of running and generated as result 29 nonconformances. The causes of nonconformances occurring were analyzed manually and classified in categories of fails.

[pt] Consciência de software (software awareness) tornou-se um requisito importante na construção de sistemas com capacidade de autoadaptação. Para que aplicações de software possam melhor se adaptar a mudanças nos diversos ambientes em que operam, ter consciência (no sentido de perceber e entender esses ambientes e a seu próprio funcionamento nestes ambientes) é fundamental. Entretanto, mesmo em um nível básico aplicado a software, consciência é um requisito difícil de definir. Nosso trabalho propõe a organização de um catálogo para o requisito de consciência de software, com mecanismos para instanciação e uso do conhecimento armazenado neste catálogo na modelagem e implementação de software para problemas onde a autoadaptação, e por consequência consciência, sejam requisitos chave. / [en] Software awareness has become an important requirement in the construction of self-adaptive systems. As such, the software should better adapt to changes in the various environments in which they operate, be aware of (in the sense of perceiving and understanding) these environment and be aware of its own operation in these environments. However, even at a basic level applied to software, awareness is a requirement difficult to define. Our work proposes the creation of a catalog to the awareness requirement through non-functional requirements patterns (NFR patterns). We also propose mechanisms for enabling the instantiation and use of the knowledge about awareness, represented in this catalog.

Made available in DSpace on 2016-06-02T19:05:51Z (GMT). No. of bitstreams: 1 3769.pdf: 7885518 bytes, checksum: 7723f0868651af930744610d4adb9ccb (MD5) Previous issue date: 2011-05-30 / Financiadora de Estudos e Projetos / Embedded systems have been used in a myriad of devices that are present in our daily lives, thereby the market for such sort of system has increased significantly over the last few years. These systems were once associated with low-level code, however, this is an outdated view of embedded systems technology. Although the current embedded systems are mostly composed of software, no systematic reuse technique is used in throughout their development. Thus, since previous successful experiences are not reused, forcing the developer to create some of the involved elements from the scratch, there is a considerable delay in the production of these systems. Due to the ever increasing complexity of embedded systems it is necessary to apply reuse techniques in order to lessen the effort needed to develop such systems. Within this context, software product lines (SPL) are reuse techniques that allow the creation of several systems belonging to a certain domain. SPL can be used to generate products of a specific domain that share common features but are each different in a specific way. Model-driven development is another reuse technique whose main objective is to reduce the semantic distance between the domain problem and its solution/implementation; thus, the developer does not need to direct interact with the solution source code, being able to focus on models and transforming those models in source code or yet other models. Based on these techniques, a process for the development of SPL in the domain of mobile robots was developed. In order to properly use the proposed process, a SPL called LegoMobileRobots Software Product Line (LMRSPL) was devised. Moreover, a domain specific language (DSL) was also developed. This DSL, called F2MoC, assists the application engineer in instantiating LMRSPL members. / Sistemas embarcados são utilizados em vários dispositivos que fazem parte da vida cotidiana, de modo que o mercado de tais sistemas tem crescido de maneira expressiva. Esses sistemas sempre foram associados com código de baixo nível, no entanto, essa visão está desatualizada. Nas aplicações embarcadas correntes o software é a principal parcela, embora nenhuma técnica sistemática de reuso seja utilizada para sua concepção. Desse modo ocorre um atraso considerável na produtividade dos sistemas, uma vez que experiências anteriores bem sucedidas não são reaproveitadas, sendo necessário que o desenvolvedor comece do zero toda vez que um software for desenvolvido. Com a crescente complexidade dos sistemas embarcados é necessário utilizar técnicas de reuso para diminuir o atrasado da produção de tais sistemas. Nesse contexto, Linha de Produtos de Software (LPS) é definida como uma técnica de reuso que permite a construção de vários sistemas pertencentes a um mesmo domínio. LPS é aplicável para a geração de produtos específicos de um domínio, mas que possuem um conjunto de características comuns e pontos de variabilidades bem definidos. O Desenvolvimento de Software Orientado a Modelos (do inglês Model-Driven Development - MDD) é outra técnica de reuso na qual tem como principal objetivo reduzir a distância semântica entre o problema do domínio e solução/implementação, fazendo com que o engenheiro não precise interagir diretamente como o código-fonte, podendo se concentrar em modelos que possuem maiores níveis de abstração e posteriormente realizar transformações Model-To-Code e/ou Model-To-Model. A partir dessas técnicas de reuso é introduzido um processo para o desenvolvimento de linhas de produtos de software no domínio de Robôs Moveis. A fim de utilizar o processo proposto foi desenvolvida uma LPS intitulada LegoRobosMoveis Linha de Produtos de Software (LRMLPS). Adicionalmente, foi desenvolvida uma linguagem especifica de domínio denominada F2MoC que auxilia o engenheiro de aplicação na instanciação automática de membros da LRMLPS.

Advances in Information and Communication Technologies (ICT) can provide competitive advantages for organizations. The search for innovations by organizations demand better solutions for the constant technology and market advancements and the guarantee of quality and satisfaction to its customers. In this sense, organizations need that the Strategic Planning (PE) and ICT be integrated, coherent and with synergy to ensure the survival of organizations. The PETIC Methodology is a form of PE that safely help managers identify the maturity and consequent improvement of ICT processes required in company management. The growing number of case studies of PETIC in organizations has shown a difficulty to locate and classify PETIC Artifacts produced during these case studies. In this context, the use of classificatory structures (taxonomies) has been successfully applied to the classification and retrieval of information. This work proposes a taxonomy to support methodology PETIC called TAXOPETIC. Among the various technical approaches to build a taxonomy, we opted for the use of approaches Aganette et al. (2010) and Bayona-Oré et al. (2014). After the construction of TAXOPETIC, we performed a comparative study between these used approaches. In this paper, we present the reasons of choosing Bayonne-Oré et al approach. (2014). To test the TAXOPETIC structure, a software product called TAXOPETICWeb was built. Among the results, it was evident that the non-use of TAXOPETICWeb tool disables the centralized and classified access to Artifacts PETIC legacy. The TAXOPETICWeb enables the storage of all rated PETIC artifacts and, through the defined metadata tags, allows the most efficient location and categorizes the artifacts stored in PETIC TAXOPETICWeb. / Os avanços das Tecnologias da Informação e Comunicação (TIC) podem proporcionar diferenciais competitivos para as organizações. A busca de inovações pelas organizações exige melhores soluções para o avanço constante da tecnologia e do mercado e a garantia de qualidade e satisfação aos seus clientes. Nesse sentido, as organizações necessitam que o Planejamento Estratégico (PE) e as TIC estejam integrados, coerentes e com sinergia para garantir a sobrevivência das organizações. A Metodologia PETIC é uma forma de PE que, de forma segura, ajuda gestores na identificação da maturidade e consequente melhoria dos processos de TIC, necessários na gestão da empresa. O crescente número de estudos de caso da PETIC em organizações tem evidenciado uma dificuldade de localizar e classificar os Artefatos PETIC, produzidos durante esses estudos de caso. Nesse contexto, a utilização de estruturas classificatórias (taxonomias) tem sido aplicada com sucesso para a classificação e a recuperação de informações. Este trabalho propõe uma taxonomia para dar suporte à Metodologia PETIC, denominada TAXOPETIC. Dentre as diversas abordagens técnicas para a construção de uma taxonomia, optou-se pelo uso das abordagens de Aganette et al. (2010) e Bayona-Oré et al. (2014). Após a construção da TAXOPETIC, foi realizado um estudo comparativo entre essas abordagens utilizadas. Neste trabalho, são apresentados os motivos pela escolha da abordagem de Bayona-Oré et al. (2014). Para testar a estrutura da TAXOPETIC, foi construído um produto de software chamado TAXOPETICWeb. Entre os resultados, ficou evidenciado que a não utilização da ferramenta TAXOPETICWeb impossibilita o acesso centralizado e classificado do Artefatos PETIC legados. A TAXOPETICWeb possibilita o armazenamento classificado de todos os Artefatos PETIC e, por meio dos metadados e tags definidos, permite a localização mais eficiente e categoriza dos Artefatos PETIC armazenados na TAXOPETICWeb.

The Model Driven Development (MDD) is a paradigm of development of software products, whose objective is to put the models as the main artifact of the development process, instead of putting the source code. In recent years, researches in Software Engineering area have created and adjusted definitions, methods and structures for the achievement of this paradigm. However, the models of the software development process, as well as testing activities involved in these models are not adequate and do not allow the effective use of this paradigm. In order that the Software Engineering area has as it main goal, the development of software products with quality, it is also necessary that these models of the development process involves increasingly approaches to software testing, with the intent to commit them from the early stages, aiming to identify and correct the errors as soon as possible, adding quality to the software. An approach that uses models in software testing is the Model Driven Testing (MDT), which one makes use of the MDD practices, through the automatic generation of test artifacts according to the rules of predefined transformation from development models. Thus, this work presents the Qualitas, a model for the development of model-driven software, which allows the use of both models in the effective integration of MDD and MDT. The model seeks to promote a greater control of the stages and activities of the software development process, but also to add quality to software products developed. A review and an experimental study of Qualitas was performed through the implementation of activities related to the Federal University of Sergipe (UFS) Neonatal Screening System of the University Hospital (HU) functionality, highlighting the advantages and limitations of the model presented. / O Model Driven Development (MDD) é um paradigma de desenvolvimento de produtos de software, cujo objetivo é colocar os modelos como o artefato central do processo de desenvolvimento, ao invés do código-fonte. Nos últimos anos, pesquisas na área de Engenharia de Software têm criado e adaptado definições, métodos e estruturas para a realização desse paradigma. No entanto, os modelos de processo de desenvolvimento de software, bem como as atividades de testes envolvidas nestes modelos não são adequados e não permitem o uso efetivo desse paradigma. Tendo em vista que, a área de Engenharia de Software possui como objetivo principal o desenvolvimento de produtos de software com qualidade, é necessário também que estes modelos de processo de desenvolvimento envolvam cada vez mais abordagens de teste de software, com o intuito de realizá-los desde as fases iniciais software, visando que os erros sejam identificados e corrigidos quanto mais cedo possível, agregando qualidade ao software. Uma abordagem que faz uso de modelos no teste de software é o Model Driven Testing (MDT), a qual faz uso de práticas do MDD, através da geração automática de artefatos de teste de acordo com as regras de transformação prédefinidas a partir de modelos de desenvolvimento. Desta forma, este trabalho apresenta o Qualitas, um modelo de processo para o desenvolvimento de software orientado a modelos, que possibilite tanto o uso de modelos quanto a efetiva integração do MDD e MDT. O modelo busca promover um maior controle das etapas e atividades do processo de desenvolvimento de software, como também agregar qualidade aos produtos de software desenvolvidos. Uma avaliação e um estudo experimental do Qualitas foi realizada através da implementação de funcionalidades relacionadas ao Sistema de Triagem Neonatal do Hospital Universitário (HU) da Universidade Federal de Sergipe (UFS), destacando as vantagens e mostrando as limitações do modelo.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-09-28T14:01:43Z No. of bitstreams: 1 DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5) / Made available in DSpace on 2018-09-28T14:01:43Z (GMT). No. of bitstreams: 1 DIEGO TAVARES CAVALCANTI - DISSERTAÇÃO PPGCC 2012..pdf: 11733349 bytes, checksum: 59909ce95d6ea71dea6e9686d3d20c33 (MD5) Previous issue date: 2012-11-26 / Localizar e corrigir defeitos são tarefas comuns no processo de manutenção de software. Entretanto, a atividade de localizar entidades de código que são possivelmente defeituosas e que necessitam ser modificadas para a correção de um defeito, não é trivial. Geralmente, desenvolvedores realizam esta tarefa por meio de um processo manual de leitura e inspeção do código, bem como de informações cadastradas em relatórios de defeitos. De fato, é necessário que os desenvolvedores tenham um bom conhecimento da arquitetura e do design do software a fim de realizarem tal tarefa. Entretanto, este conhecimento fica espalhado por entre a equipe e requer tempo para ser adquirido por novatos. Assim, é necessário o desenvolvimento de técnicas que auxiliem na tarefa de análise de impacto de relatórios de defeitos no código, independente da experiência do desenvolvedor que irá executá-la. Neste trabalho, apresentamos resultados de um estudo empírico no qual avaliamos se a análise automática de vocabulários de relatórios de defeitos e de software pode ser útil na tarefa de localizar defeitos no código. Nele, analisamos similaridade de vocabulários como fator para sugerir classes que são prováveis de serem impactadas por um dado relatório de defeito. Realizamos uma avaliação com oito projetos maduros de código aberto, desenvolvidos em Java, que utilizam Bugzilla e JIRA como seus repositórios de defeitos. Nossos resultados indicam que a análise de ambos os vocabulários é, de fato, uma fonte valiosa de informação, que pode ser utilizada para agilizar a tarefa de localização de defeitos. Para todos os sistemas estudados, ao considerarmos apenas análise de vocabulário, vimos que, mesmo com um ranking contendo apenas 8% das classes de um projeto, foi possível encontrar classes relacionadas ao defeito buscado em até 75% dos casos. Portanto, podemos concluir que, mesmo que não possamos utilizar vocabulários de software e de relatórios de defeitos como únicas fontes de informação, eles certamente podem melhorar os resultados obtidos, ao serem combinados com técnicas complementares. / Locating and fixing bugs described in bug reports are routine tasks in software development processes. A major effort must be undertaken to successfully locate the (possibly faulty) entities in the code that must be worked on. Generally, developers map bug reports to code through manual reading and inspection of both bug reports and the code itself. In practice, they must rely on their knowledge about the software architecture and design to perform the mapping in an efficient and effective way. However, it is well known that architectural and design knowledge is spread out among developers. Hence, the success of such a task is directly depending on choosing the right developer. In this paper, we present results of an empirical study we performed to evaluate whether the automated analysis of bug reports and software vocabularies can be helpful in the task of locating bugs. We conducted our study on eight versions of six mature Java open-source projects that use Bugzilla and JIRA as bug tracking systems. In our study, we have used Information Retrieval techniques to assess the similarity of bug reports and code entities vocabularies. For each bug report, we ranked ali code entities according to the measured similarity. Our results indicate that vocabularies are indeed a valuable source of information that can be used to narrow down the bug-locating task. For ali the studied systems, considering vocabulary similarity only, a Top 8% list of entities has about 75% of the target entities. We conclude that while vocabularies cannot be the sole source of information, they can certainly improve results if combined with other techniques.