Um método e uma ferramenta para testes baseados em modelos para linhas de produto software

Orientador: Eliane MartinsDissertação (mestrado) - Universidade Estadual de Campinas, Instituto de ComputaçãoResumo: As linhas de produtos de software (LPS) estão ganhando interesse devido à crescente demanda por produtos personalizáveis. Tal se deve, em parte, por que as LPS são um meio eficiente e efetivo de entregar produtos com maior qualidade a um custo menor. Em uma LPS, produtos têm requisitos em comum e também, características específicas a cada um. Testar se um produto implementa os requisitos comuns e específicos é um importante passo para garantir uma boa qualidade. No entanto, o teste de uma LPS é uma tarefa complexa, uma vez que a variedade de produtos que podem ser derivados a partir da combinação de características comuns e específicas é enorme. Mesmo que se escolha apenas alguns produtos selecionados, o esforço para testá-los ainda assim é grande, dado que os produtos variam em termos das características específicas selecionadas. Portanto, reutilizar casos de teste de um produto para o outro para determinar se satisfazem os requisitos funcionais, pode não ser possível. Os testes baseados em modelos (MBT) podem ser úteis neste caso, nos quais um modelo de comportamento pode ser obtido a partir dos requisitos e este modelo pode ser usado para a geração automática de casos de teste. Neste trabalho é apresentada uma abordagem em que os requisitos SPL são centrados em casos de uso. Casos de uso (UC) são um formato popular para representar os requisitos. A partir das descrições de casos de uso escritas em um formato semi-estruturado e contendo a especificação de variabilidade, os modelos de comportamento são gerados automaticamente para um produto sob teste, na forma de um modelo de máquina de estado. Construir uma máquina de estado não é trivial para a maioria dos profissionais, que estão mais habituados com descrições textuais e informais dos requisitos. Em geral, a criação manual de modelos de máquinas de estado a partir de UCs pode ser demorado e propenso a erros. O objetivo é fornecer aos engenheiros de teste um método que os guie na criação dos artefatos necessários para que uma versão preliminar de um modelo de estado seja extraída automaticamente dos requisitos. Este modelo preliminar pode ser refinado para tornar-se adequado para uma ferramenta de geração de casos de teste. Para esse processo de refinamento também são fornecidas algumas diretrizes. Como prova de conceito, desenvolveu-se um protótipo de uma ferramenta, MARITACA, que utiliza técnicas de processamento de língua natural para extrair as máquinas de estado a partir das descrições dos casos de uso. O texto apresenta o uso do método e da ferramenta em um exemplo ilustrativo, obtido da literatura, e em uma família de aplicações distribuídas tolerantes a falhas. Este estudo mostrou a aplicabilidade do método proposto. Uma das preocupações nos testes de SPL é a geração de casos de teste redundantes de um produto para outro. Os resultados, embora preliminares, mostraram que a maioria dos casos de teste gerados para um novo produto não são redundantes, pois envolvem características específicas de cada produtoAbstract: Software product lines (SPL) are gaining interest because of the increasing demand for customizable products. This is partly because SPLs are an efficient and effective means of delivering products with higher quality at a lower cost. In SPL, products have common requirements and also, specific features for each one. Testing whether a product implements common and specific requirements is an important step to ensure good quality of the derived products. However, testing a SPL is a complex task, since the variety of products that can be derived from the combination of common and specific features is huge. Even if only a few specific products are selected, the effort to test them is still significant, since the products vary in terms of the specific features that are selected. Therefore, reusing test cases from one product to another to determine whether they satisfy the functional requirements may not be possible. Model-based testing (MBT) may be useful in this case, in which a behavior model can be obtained from the requirements and this model can be used for automatic test cases generation. This work presents model-based product testing approach (MBPTA) for software product lines, in which requirements are centered on use cases. Use Cases (UC) are a popular format for representing requirements. From the use case descriptions written in the form of a semi-structured format and containing the variability specification, the behavior models are automatically generated for a product under test, in the form of a state machine model. Building a state machine is not a trivial task for most practitioners, who are more familiarized with textual and informal descriptions of requirements. In general, the manual creation of state machine models from UCs can be time-consuming and prone to errors. The goal is to provide the test engineers with a method that guides them in the creation of artifacts necessary to extract a preliminary version of a state model from the requirements. This preliminary model can be refined to become suitable for a test case generation tool. MBPTA also provides guidelines for the refinement process of the preliminary model. As proof of concept, a prototype of a tool was developed, MARITACA, which uses natural language processing techniques to extract state machines from the use case descriptions. The text presents the use of the method and the tool in an illustrative example, obtained from the literature, and in a family of distributed fault-tolerant applications. This study showed the applicability of the proposed method. One of the concerns in SPL testing is the generation of redundant test cases from one product to another. The results, though preliminary, showed that most of the test cases generated for a new product are not redundant because they involve specific features of each productMestradoCiência da ComputaçãoMestra em Ciência da ComputaçãoCAPE

An automated approach to transform use cases into activity diagrams

Use cases are commonly used to structure and document requirements while UML activity diagrams are often used to visualize and formalize use cases, for example to support automated test case generation. Therefore the automated support for the transition from use cases to activity diagrams would provide significant, practical help. Additionally, traceability could be established through automated transformation, which could then be used for instance to relate requirements to design decisions and test cases. In this paper, we propose an approach to automatically generate activity diagrams from use cases while establishing traceability links. Data flow information can also be generated and added to these activity diagrams. Our approach is implemented in a tool, which we used to perform five case studies. The results show that high quality activity diagrams can be generated. Our analysis also shows that our approach outperforms existing academic approaches and commercial tools

Uma proposta para rastreabilidade no desenvolvimento de software

Orientador: Mario JinoTese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de ComputaçãoResumo: Rastreabilidade tem sido um tópico de pesquisa no desenvolvimento de software por pelo menos 40 anos, sendo adicionada a muitos padrões, como o DOD-STD-2167A e o IEEE 830-1998. Este último, por exemplo, afirma que uma boa especificação de requisitos de software deve ser rastreável. A rastreabilidade fornece muitos benefícios para projetos de software, tais como: identificação das razões para decisões de design, prevenção de problemas de dependência, identificação de responsabilidades em um projeto, estimação de impacto e de custo de modificações, e medição do progresso de desenvolvimento. Sucintamente, a rastreabilidade permite a geração de um produto de melhor qualidade. Dois principais focos surgiram na literatura nos últimos anos: desenvolvimento baseado em modelo e geração automática de rastros. O primeiro trata da modelagem de rastreabilidade, definindo relações e elementos de um projeto; o segundo trata da descoberta automática de relações entre elementos. Vários conceitos foram definidos até agora, como rastreabilidade bidirecional, rastreabilidade de especificações pré e pós-requisitos, rastreabilidade horizontal e vertical, e rastreabilidade explícita e implícita. Embora haja um consenso geral sobre a maioria dos conceitos relacionados a rastreabilidade, há uma falta de consenso sobre como, e o quê, deve ser rastreado; não há consenso sobre: quais relações são relevantes para os projetos de desenvolvimento de software, quais elementos devem ser rastreados, como as mudanças nos elementos de um projeto afetam as relações existentes, ou como atualizar as relações dadas certas mudanças. Os modelos de rastreabilidade visam responder a essas questões fornecendo um padrão para ser usado como uma guia em projetos de desenvolvimento de software; entretanto, não há consenso sobre o que um modelo deve conter. Existe uma variedade de modelos, cada um considerando diferentes tipos de relações, elementos, e possuindo diferentes focos. Além disso, a maioria dos modelos possui problemas que tornam o seu uso difícil, ou até mesmo impossível; por exemplo, existem modelos que não descrevem - suficientemente ou em nada - as ligações de rastreabilidade que propõem. Este trabalho visa a ajudar nesta questão, fornecendo uma contribuição dupla: um modelo de referência para criar e avaliar modelos de rastreabilidade, e um metamodelo abrangente, construído em cima do modelo de referência, para adicionar rastreabilidade a projetos de desenvolvimento de software. Nosso Modelo de Referência para rastreabilidade define os elementos básicos em um modelo de rastreabilidade e define conjuntos básicos de: ações, tipos de ligações, tipos de artefatos, e processos. Propriedades necessárias para o conjunto de tipos de ligações e o conjunto de tipos de artefatos também são fornecidas. Nosso Metamodelo para rastreabilidade é composto por: um modelo conceitual descrevendo e organizando os elementos de rastreabilidade; um conjunto de tipos de artefatos representando as atividades definidas no Modelo de Referência, além de um conjunto de tipos de artefatos criados para registrar decisões de design; um conjunto de tipos de ligações que modelam diferentes relações de rastreabilidade; e um conjunto de processos para garantir a consistência de projetosAbstract: Traceability has been a topic of research in software development for at least 40 years, being added to many standards, such as the DOD-STD-2167A and the IEEE 830-1998. The latter, for instance, states that a good software requirements specification should be traceable. Traceability provides many benefits to software projects, such as: identification of the reasons for design decisions, avoidance of dependency issues, identification of accountability in a project, estimation of impact and cost of modifications, and measurement of development progress. Succintly, traceability allows the generation of a better quality product. Two main focuses have emerged in the literature in recent years: model-based development and automated trace generation. The former concerns modeling traceability by defining relations and elements in a project; the latter concerns automatic discovery of relations between elements in a project. Several concepts have been defined so far, such as bidirectional traceability, pre and post-requirements specification traceability, horizontal and vertical traceability, and explicit and implicit traceability. While there is general consensus on most concepts related to traceability, there is a lack of consensus on how, and what, should be traced; there is no consensus on which relations are relevant for software development projects, which elements should be traced, how changes in elements of a project affects existing relations, or how to update relations given certain changes. Traceability models aim to answer these questions by providing a standard to be used as a guide in software development projects; however, there is no consensus on what a model should contain. There is a variety of models, each considering different types of relations, elements, and having distinct focuses. Also, the majority of models have issues which makes them difficult or even impossible to use; for instance, there are models which do not describe - sufficiently or at all - traceability links which they propose. This work aims to help in this issue by providing a twofold contribution: a reference model for creating and evaluating traceability models, and a comprehensive metamodel, built on top of the reference model, to add traceability to software development projects. Our Reference Model for traceability defines the basic elements in a traceability model and defines basic sets of: actions, link types, artifact types, and processes. Necessary properties for the sets of link types and artifact types are also provided. Our Metamodel for traceability is composed of: a conceptual model describing and organizing the elements of traceability; a set of artifact types representing the activities of the Reference Model, plus a set of artifact types created to record design decisions; a set of link types modeling different traceability relations; and a set of processes to ensure project consistencyDoutoradoEngenharia de ComputaçãoDoutor em Engenharia Elétrica1142618CAPE