TÉCNICA DE LEITURA PARA INSPEÇÃO DE DIAGRAMAS DE ESTADOS COM BASE EM DIAGRAMAS DE ATIVIDADES ESPECIFICANDO OS CASOS DE USO DO
SOFTWARE
Karen Miyuki Nakazato
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia de Sistemas e Computação, COPPE, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Mestre em Engenharia de Sistemas e Computação.
Orientador: Guilherme Horta Travassos
Rio de Janeiro Setembro de 2013
ii TÉCNICA DE LEITURA PARA INSPEÇÃO DE DIAGRAMAS DE ESTADOS COM BASE EM DIAGRAMAS DE ATIVIDADES ESPECIFICANDO OS CASOS DE USO DO
SOFTWARE
Karen Miyuki Nakazato
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Examinada por:
________________________________________________ Prof. Guilherme Horta Travassos, D.Sc.
________________________________________________ Prof. Toacy Cavalcante de Oliveira, D.Sc.
________________________________________________ Prof. Márcio de Oliveira Barros, D.Sc.
RIO DE JANEIRO, RJ – BRASIL SETEMBRO DE 2013
iii Nakazato, Karen Miyuki
Técnica de Leitura para Inspeção de Diagramas de Estados com base em Diagramas de Atividades Especificando os Casos de Uso do Software / Karen Miyuki Nakazato – Rio de Janeiro: UFRJ/COPPE, 2013.
XII, 149 p.: il.; 29,7 cm.
Orientador: Guilherme Horta Travassos.
Dissertação (mestrado) – UFRJ/COPPE/Programa de Engenharia de Sistemas e Computação, 2013.
Referências Bibliográficas: p. 113-118.
1. Inspeção de Software. 2. Diagrama de Estados. 3. Diagrama de Atividades. 4. Engenharia de Software Experimental. I. Travassos, Guilherme Horta II. Universidade Federal do Rio de Janeiro, COPPE, Programa de Engenharia de Sistemas e Computação. III. Título.
iv Aos meus pais, pela dedicação e exemplo de vida. Aos meus avós pela compreensão. Aos meus irmãos pelo carinho.
v
Agradecimentos
Dedico o meu eterno agradecimento à todos que estiveram ao meu lado nesses anos. A todos que de alguma forma contribuíram para a minha formação não só profissional, mas também pessoal.
Em especial, agradeço aos meus pais Ademir e Nancy pelo apoio e amor incondicional em todos os momentos. Pelo incentivo e o esforço que foram cruciais para o término do mestrado.
À Batchan e Ditchan, meus avós, que me acolheram durante o mestrado, pela compreensão e incentivo.
Aos meus irmãos, Junji e Akio, pelo carinho e companheirismo.
Ao meu orientador, prof. Guilherme Horta Travassos, pela dedicação e apoio na minha pesquisa, sem o qual não seria possível realizar o mesmo trabalho.
Aos professores Márcio Barros e Toacy Cavalcante, por participarem de minha banca de defesa de mestrado.
Aos meus amigos e companheiros da COPPE, alguns já egressos, Victor Vidigal, Arthur Siqueira, Jobson Massollar, Breno França, Rafael de Mello, Rafael Espirito Santo, Leonardo Mota, Wallace Martinho, Paulo Sérgio Medeiros, Vitor Lopes, Rodrigo Spínola, Talita Ribeiro, Thiago de Souza, Verônica Taquette e Ivens Portugal pelos conselhos e excelentes momentos vividos durante esses anos.
À Taísa Guidini Gonçalves, sempre disposta e prestativa.
Aos meus amigos de Campo Grande que me apoiaram e incentivaram, e os amigos do Rio de Janeiro pela receptividade e companheirismo.
Aos alunos que participaram dos estudos que compõem esta dissertação. Ao CNPQ pelo apoio financeiro.
vi Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
TÉCNICA DE LEITURA PARA INSPEÇÃO DE DIAGRAMAS DE ESTADOS COM BASE EM DIAGRAMAS DE ATIVIDADES ESPECIFICANDO OS CASOS DE USO DO
SOFTWARE
Karen Miyuki Nakazato
Setembro/2013
Orientador: Guilherme Horta Travassos
Programa: Engenharia de Sistemas e Computação
Este trabalho apresenta Shiô, uma técnica de leitura para inspecionar diagramas de estados com o apoio de diagramas de atividades que especificam os casos de uso do software. A técnica foi desenvolvida com base em evidência. Seu desenvolvimento se justifica pela necessidade de uma técnica deste tipo para os projetos de software atuais e, ao mesmo tempo, a carência de tecnologias para a inspeção de diagramas de fluxo de atividades envolvendo diagramas de estado, conforme indicado pelos resultados de uma quasi-revisão sistemática (estudo secundário). A primeira versão de Shiô foi avaliada através de dois estudos de viabilidade in-vitro que indicaram sua capacidade em identificar defeitos, principalmente aqueles usualmente não capturados por inspeção ad-hoc, apesar do tempo dispendido pelos inspetores ser maior. Entretanto, estes resultados permitiram evoluir a técnica Shiô, simplificando sua aplicação e aprimorando sua organização visando aumentar sua capacidade para detecção de defeitos nos diagramas de estados.
vii Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.)
A READING TECHNIQUE FOR INSPECTION OF STATE DIAGRAMS BASED ON ACTIVITY DIAGRAMS DESCRIBING SOFTWARE USE
Karen Miyuki Nakazato
September/2013
Advisor: Guilherme Horta Travassos
Department: Computer Science and Systems Engineering
This work introduces Shiô, a reading technique to inspect state diagrams based on activity diagrams describing the software use cases. The technique had been developed through an evidence based methodology. Its development can be justified by the need of such type of techniques for supporting quality in contemporary software projects considering the lack of inspection technologies to support the reading of flow based diagrams as indicated in the result of a quasi-systematic review (secondary study). The first version of Shiô was evaluated by two in vitro feasibility studies, which indicated its capacity of detecting defects, mainly those ones not usually captured by ad-hoc reading, although the increasing of time reading. These results motivated the evolution of Shiô, aiming at to simplify its descriptions and reorganization to improve the capacity of inspectors on identifying defects in state diagrams.
viii
ÍNDICE
1 Introdução ... 1
1.1 Motivação e Contexto: Descrição do Problema ... 1
1.2 Objetivo da Solução Proposta ... 5
1.3 Metodologia de Trabalho ... 6
1.4 Organização do Trabalho ... 8
2 Fundamentação Teórica ... 9
2.1 Introdução ... 9
2.2 Diagrama de Atividades ... 11
2.2.1 Possíveis Usos de Diagramas de Atividades ... 12
2.2.2 Estruturas ... 12 2.3 Diagrama de Estados ... 15 2.3.1 Estruturas ... 16 2.4 Inspeção de Software ... 21 2.4.1 Processo de Inspeção ... 22 2.4.2 Taxonomia de defeitos ... 24
2.4.3 Exemplos de Técnicas de Inspeção ... 24
2.5 Conclusão ... 29
3 Técnicas de Inspeção para Diagramas de Fluxos de Atividades ... 31
3.1 Introdução ... 31
3.2 Planejamento da quasi-Revisão Sistemática ... 32
3.3 Execução da quasi-Revisão Sistemática ... 35
3.3.1 Seleção dos artigos ... 36
3.3.2 Extração das Informações ... 37
3.3.3 Avaliação da Qualidade dos Artigos ... 40
3.4 Resultados encontrados ... 42
3.4.1 Tanriöver e Bilgen (2007) ... 43
3.4.2 Cooper et al. (2007) ... 43
3.4.3 de Mello et al. (2010) ... 44
3.5 Atualização da quasi-Revisão Sistemática ... 45
3.6 Ameaças à validade ... 47
3.7 Conclusão ... 48
4 Técnica de Leitura para inspecionar Diagramas de Estados com referência nos Diagramas de Atividades ... 49
4.1 Introdução ... 49
4.2 Modelos Inspecionados ... 51
4.3 Premissas para Aplicação da Técnica ... 54
4.4 Relação entre diagramas de estados e diagramas de atividades ... 54
4.5 A Técnica Shiô ... 58
4.5.1 Estrutura da Técnica Shiô ... 58
4.5.2 Primeira Versão da Técnica... 65
4.5.3 Relatório de Discrepância ... 69 4.6 Conclusão ... 71 5 Estudos Experimentais ... 72 5.1 Introdução ... 72 5.2 Primeiro Estudo ... 73 5.2.1 Planejamento ... 74 5.2.2 Projeto Experimental ... 75 5.2.3 Instrumentação ... 77
ix
5.2.4 Execução... 77
5.2.5 Análise Preliminar dos Resultados ... 81
5.3 Segundo Estudo ... 88
5.3.1 Planejamento e Projeto Experimental ... 89
5.3.2 Instrumentação e Execução ... 91
5.3.3 Análise Preliminar dos Resultados ... 92
5.4 Análise Qualitativa dos Estudos ... 93
5.5 Lições Aprendidas com os Estudos ... 102
5.6 Ameaças à validade ... 103
5.7 Segunda Versão da Técnica ... 104
5.8 Conclusão ... 109
6 Conclusão e Trabalhos Futuros ... 110
6.1 Considerações Finais ... 110
6.2 Contribuições da Pesquisa ... 111
6.3 Limitações ... 111
6.4 Trabalhos Futuros ... 112
REFERÊNCIAS BIBLIOGRÁFICAS ... 113
APÊNDICE A – Formulários Utilizados nos Estudos ... 119
A.1. Formulário de Consentimento ... 119
A.2. Formulário de Caracterização ... 121
APÊNDICE B – Diagramas utilizados nos Estudos ... 124
B.1. Modelos e Regras de Negócio sobre Conta Utilizados na Inspeções ... 124
B.2 Modelos e Regras de Negócio sobre Movimento Utilizados na Inspeções ... 128
APÊNDICE C – Relatórios de Discrepância Utilizados nos Estudos ... 145
C.1. Relatório de Discrepância da Inspeção Ad-hoc ... 145
C.2. Relatório de Discrepância da Inspeção com a Técnica Shiô ... 146
APÊNDICE D – Questionário de Avaliação da Técnica de Leitura Shiô ... 147
x
ÍNDICE DE FIGURAS
Figura 1-1 Diagrama de atividades que representa a descrição do daso de uso,
conforme MASSOLLAR (2011). ... 5
Figura 1-2 Metodologia de pesquisa adotada. ... 7
Figura 2-1 Diagramas estruturais e comportamentais da UML (Adaptado da OMG, 2011). ... 9
Figura 2-2 Exemplos de Técnicas de Inspeção em Diagramas da UML (Adaptado de TRAVASSOS, 2002). ... 11
Figura 2-3 Exemplo de duas ações. ... 12
Figura 2-4 Exemplo da atividade Separar Produtos. ... 13
Figura 2-5 Nós inicial e final de atividade. ... 14
Figura 2-6 Nó de decisão (Adaptado da OMG, 2011). ... 15
Figura 2-7 Exemplo de estado. ... 16
Figura 2-8 Diagrama de estados para Automóvel, tendo como foco o movimento (Adaptado de SILVA, 2007). ... 17
Figura 2-9 Diagrama de estados para Automóvel no contexto de uma oficina mecânica (Adaptado de SILVA, 2007). ... 17
Figura 2-10 (a) Estado incial (b) Estado final. ... 18
Figura 2-11 Diagrama de estados de Venda. ... 19
Figura 2-12 Modelagem de estados para Automóvel, com estado composto (Adaptado de SILVA, 2007). ... 20
Figura 2-13 Modelagem alternativa para Automóvel, com estado composto (Adaptado de SILVA, 2007). ... 20
Figura 2-14 Modelagem de Automóvel com estado submáquina (SILVA, 2007). ... 21
Figura 2-15 Processo de inspeção de software de FAGAN (de acordo com WONG, 2006). ... 22
Figura 3-1 Artigos distintos retornados pelas máquinas de busca... 36
Figura 4-1 Representação gráfica da Técnica de Leitura de Diagramas de Estados com Diagramas de Atividades dentro do contexto de OORTs. ... 50
Figura 4-2 Diagrama de atividades de Realizar Venda. ... 55
Figura 4-3 Diagrama de estados de Venda. ... 55
Figura 4-4 Visão geral da técnica proposta. ... 58
Figura 4-5 Diagrama de estados de Venda utilizado para ilustrar a aplicação da técnica Shiô. ... 59
Figura 4-6 Diagrama de estados - Passo 1 da Técnica Shiô... 60
Figura 4-7 Diagrama de atividades - Passo 1 da Técnica Shiô ... 61
Figura 4-8 Diagrama de atividades - Passo 2 da Técnica Shiô ... 62
Figura 4-9 Diagrama de atividades - Passo 3 da Técnica Shiô ... 63
Figura 4-10 Diagrama de estados - Passo 3 da Técnica Shiô ... 64
Figura 4-11 Diagrama de atividades - Passo 4 da Técnica Shiô ... 65
Figura 5-1 Quantidade de defeitos encontrados pela inspeção ad-hoc e por Shiô no conjunto de modelos de Conta. ... 84
Figura 5-2 Quantidade de defeitos encontrados pela inspeção ad-hoc e Shiô no conjunto de modelos de Movimento. ... 85
Figura 5-3 Grau de confiabilidade estatística (Gardner e Altman, 1989). ... 97
Figura 5-4 Respostas do questionário de avaliação da técnica referente à adesão da técnica. ... 98
Figura 5-5 Respostas do questionário de avaliação da técnica referente ao grau de dificuldade da técnica. ... 98
Figura 5-6 Respostas do questionário de avaliação da técnica referente ao auxilio da técnica durante a inspeção. ... 98
Figura 5-7 Respostas do questionário de avaliação da técnica referente ao uso em oportunidades futuras de inspeção. ... 99
xi Figura 5-8 Respostas do questionário de avaliação da técnica referente à qualidade do treinamento aplicado... 99 Figura 5-9 Respostas do questionário de avaliação da técnica referente à dificuldade em entender os modelos inspecionados. ... 100 Figura 5-10 Respostas do questionário de avaliação da técnica referente à dificuldade em entender o domínio dos modelos inspecionados... 100 Figura 5-11 Repostas do questionário de avaliação da técnica referente à
complexidade dos modelos inspecionados. ... 101 Figura 5-12 Respostas do questionário de avaliação da técnica referente ao modelo mais fácil de inspecionar. ... 101
xii
ÍNDICE DE TABELAS
Tabela 2-1 Tipos de defeitos de software (Adaptado de TRAVASSOS, 2001). ... 24
Tabela 2-2 Técnicas de Leitura OORTs (Adaptado de TRAVASSOS, 2002). ... 27
Tabela 2-3 Técnicas de Leitura para apoiar o processo de desenvolvimento ProDeS/UML (Adaptado de MARUCCI et al., 2002). ... 28
Tabela 3-1 Máquinas de buscas e quantidade de artigos retornados. ... 36
Tabela 3-2 Informações extraídas dos resultados. ... 38
Tabela 3-3 Artigos incluídos após os critérios de inclusão e exclusão. ... 39
Tabela 3-4 Informações extraídas dos artigos selecionados ... 39
Tabela 3-5 Conceitos com relação à qualidade dos artigos selecionados... 41
Tabela 3-6 Máquinas de buscas e quantidade de artigos retornados na reexecução da quasi-revisão sistemática. ... 45
Tabela 3-7 Informações extraídas de MASSOLLAR et al. (2011). ... 46
Tabela 4-1 Recursos sintáticos do diagrama de atividades explorados na abordagem de (MASSOLLAR, 2011). ... 52
Tabela 4-2 Relação dos conceitos entre a descrição de casos de uso e diagramas de atividades (MASSOLLAR, 2011). ... 52
Tabela 5-1 Objetivos específicos do primeiro estudo. ... 74
Tabela 5-2 Arranjo do primeiro estudo. ... 76
Tabela 5-3 Distribuição dos participantes e dos artefatos da turma da pós-graduação. ... 78
Tabela 5-4 Distribuição dos participantes e dos artefatos da turma da graduação. ... 79
Tabela 5-5 Outliers da turma da pós-graduação. ... 81
Tabela 5-6 Outliers da turma da graduação. ... 82
Tabela 5-7 Dados da inspeção ad-hoc. ... 83
Tabela 5-8 Dados da inspeção com o uso da técnica Shiô. ... 83
Tabela 5-9 Média e desvio padrão de defeitos e tempo no conjunto de Conta. ... 86
Tabela 5-10 Média e desvio padrão de defeitos e tempo no conjunto de Movimento.. 86
Tabela 5-11 Inspetores não outliers por rodada e por conjunto de modelos. ... 88
Tabela 5-12 Objetivos específicos do segundo estudo. ... 89
Tabela 5-13 Arranjo do segundo estudo. ... 90
Tabela 5-14 Distribuição dos participantes e dos artefatos do segundo estudo. ... 91
Tabela 5-15 Inspetores da graduação que encontraram defeitos não encontrados pela inspeção ad-hoc ... 94
1
1 Introdução
Neste capítulo são apresentados o contexto e a motivação para esta pesquisa. Além disso, são definidos os objetivos da pesquisa, a metodologia de pesquisa adotada e a organização do texto desta dissertação.
1.1 Motivação e Contexto: Descrição do Problema
As características gerais do software, incluindo suas funcionalidades e eventuais restrições, são normalmente descritas em forma textual na fase de especificação de requisitos de um projeto de software. Estas características podem ser realizadas por representações de casos de uso que fornecem um formato semiestruturado para essa descrição. Após essa fase e de posse da especificação de requisitos, diferentes modelos de projeto podem ser construídos de acordo com a necessidade do software. Estes modelos, por sua vez, podem ser descritos através de diferentes notações, incluindo a UML (OMG, 2011), que oferece representações apropriadas para diferentes diagramas de projeto relacionados às propriedades estruturais, dinâmicas e comportamentais esperadas para a solução do software.
Portanto, a construção do software envolve a elaboração e utilização de vários modelos em diferentes níveis de abstração e perspectivas. Esta “disjunção conceitual” é importante para apoiar os desenvolvedores a tratar os diferentes aspectos relacionados ao problema e ao software. A junção de todas as representações leva a visualização da solução em software. Assim, se por um lado a multiplicidade de mecanismos e instrumentos de representação facilita a descrição do problema e sua solução, por outro lado, a garantia da qualidade dos artefatos produzidos não é uma tarefa trivial.
Diagramas estruturais (como por exemplo, diagramas de classes que permitem representar as classes e seus relacionamentos) apresentam uma visão da organização estática da solução. As representações e relacionamentos não se alteram ao longo do ciclo de vida do objeto. Por outro lado, diagramas comportamentais (tais como diagramas de atividades, estados ou sequência) descrevem aspectos dinâmicos e comportamentais
2 de um sistema de software, ou seja, descrevem os comportamentos que se alteram ao longo do ciclo de vida do objeto.
Os diferentes diagramas comportamentais têm objetivos e momentos apropriados para sua utilização, como por exemplo, os diagramas de atividades, que se assemelham a fluxogramas. Os fluxogramas são uma das mais antigas ferramentas de modelagem de software existente e foram precursores dos diagramas de atividades da UML 2.
Os diagramas de atividades podem ser utilizados em diferentes contextos e com diferentes propósitos, tais como: modelagem da descrição do caso de uso, modelagem de processo de negócio e modelagem de uma operação complexa que necessita de maiores detalhes, além de servirem para descrever a sequência de ações relacionada a algum comportamento particular de um objeto (BEZERRA, 2006). GUITIÉRREZ et al. (2008) sugerem o uso de diagramas de atividades para representar casos de uso de forma a vislumbrar o comportamento global de um caso de uso, especialmente aqueles relacionados a seus aspectos dinâmicos.
Os diagramas de estados permitem descrever o ciclo de vida de um objeto e os eventos que causam a transição de um estado para outro. O uso deste diagrama está relacionado com a modelagem dinâmica de classes, assim como os diagramas de atividades, porém seu foco é descrever a evolução dos estados de um objeto pertencente a uma determinada classe (SILVA, 2007).
Os diagramas de estados e atividades possuem definições e focos diferentes, porém possuem uma relação dual, visto que os eventos que provocam a transição de estados no primeiro podem representar ações ou atividades no segundo.
Assim os diferentes diagramas são construídos para garantir que os mesmos estão corretos e consistentes. O uso de inspeção é uma alternativa viável, visto que os defeitos encontrados nesta fase não são propagados para as próximas fases do projeto. O custo de correção de um defeito na fase de teste é muito maior quando comparado às fases iniciais do projeto (BOEHM, 1981).
O padrão IEEE 610.12 (IEEE, 1990) define a seguinte terminologia para os seguintes conceitos que serão utilizados nesta dissertação:
Erro: é o defeito cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta; Falta: é um erro no artefato de software que pode causar diversas faltas;
Falha: é o comportamento incorreto do software, ou seja, diferente do esperado pelo usuário, em consequência de pelo menos uma falta;
3 Defeito: é o termo genérico utilizado para erro, falta ou falha.
FAGAN (1976) introduziu o conceito de inspeção de software, que permite a revisão dos artefatos e a garantia de sua qualidade. A utilização da inspeção ao longo do processo, além de representar um mecanismo eficiente e de baixo custo para identificar defeitos, proporciona ganhos em relação à produtividade e qualidade final do produto. Por isso, após a definição e elaboração dos diagramas a serem utilizados no projeto de software, os mesmos devem ser inspecionados a fim de garantir sua consistência com os requisitos do software.
A inspeção ad-hoc é uma das técnicas de inspeção mais conhecidas, onde o inspetor utiliza apenas o seu conhecimento para realizar esta atividade (PETERSSON, 2002). Outra técnica de inspeção conhecida na literatura técnica são os checklists, que consistem em uma série de perguntas que guiam o inspetor na detecção de defeitos. Um exemplo do uso de checklists está na técnica de inspeção por fases (KNIGHT e MEYERS, 1991), onde os mesmos são usados para detectar defeitos e avaliar características de qualidade do artefato. Existem ainda as técnicas de leitura, que oferecem uma sequência de instruções que guiam o inspetor a detectar defeitos. Por exemplo, OO-PBR (MAFRA, 2006) representa uma técnica de inspeção em requisitos, baseada em perspectiva (PBR) (SHULL et al., 2000).
Os problemas identificados através da inspeção podem não representar especificamente defeitos. Em geral, inspetores tendem a indicar um conjunto de problemas que estão associados a sua interpretação do problema e, muitas vezes, sem levar em consideração a mesma perspectiva usada para a criação do artefato. Desta forma, a seguinte nomenclatura foi adotada para classificar os problemas apontados pelos inspetores em decorrência da atividade de inspeção:
Discrepância: representa um problema detectado durante a inspeção, mas ainda não se tem certeza que o mesmo é de fato um defeito ou um falso positivo;
Falso positivo: representa a discrepância informada como resultado da inspeção, mas que não representa um defeito de fato. Na verdade, a tentativa de sua correção no artefato vai introduzir um ou mais defeitos.
O interesse em identificar técnicas de inspeção para diagramas de estados com base em diagramas de atividades está associado ao processo de desenvolvimento que
4 usualmente vem sendo utilizado para construir os projetos de software contemporâneos e que prevê a inspeção dos artefatos produzidos. Por exemplo, na literatura técnica, considerando os modelos descritos em UML, podem ser encontradas técnicas de inspeção que apoiam a inspeção de alguns destes modelos ou realizam a inspeção com base neles, como por exemplo, OORTs (TRAVASSOS et al. 2002), uma família de técnicas de leitura para inspecionar diagramas UML e ActCheck (DE MELLO, 2011) um checklist para inspecionar a especificação de requisitos (casos de uso) descritos através de diagramas de atividades. Nenhuma destas técnicas, entretanto, apoia a inspeção de diagrama de estados com base em diagramas de atividades. Em complemento, o resultado de uma quasi-revisão sistemática da literatura sobre técnicas de inspeção para diagrama de fluxos de atividades revelou que existe carência de tecnologias nesta área, principalmente no que diz respeito à inspeção de diagrama de estados envolvendo comparação com diagrama de atividades.
A especificação de requisitos é fundamental para o projeto de software e, portanto, técnicas de inspeção podem ser utilizadas com o objetivo de ter os requisitos com a qualidade desejada. Portanto, assim que os requisitos são capturados, os mesmos devem ser descritos para a continuidade do projeto. Uma das maneiras de descrevê-los é através de casos de uso em forma textual utilizando um formato padrão, como citado anteriormente. Outra forma para descrever casos de uso é através de diagramas de atividades. Neste caso, a prática proposta por MASSOLLAR (2011) apoia esta atividade, onde cada diagrama de atividades representa a descrição de um caso de uso.
Estes diagramas de atividades são descritos utilizando três estereótipos: Ação do Ator, Ação do Sistema e Resposta do Sistema. Esses estereótipos estão descritos no metamodelo UCModel, que é implementado na ferramenta UseCaseAgent (MASSOLLAR, 2011), usada na construção e avaliação sintática destes diagramas de atividades. A Figura 1-1 apresenta um exemplo de caso de uso descrito através do diagrama de atividades construído utilizando a ferramenta.
5 Figura 1-1 Diagrama de atividades que representa a descrição do daso de uso, conforme
MASSOLLAR (2011).
A partir deste ponto, os diagramas de atividades podem ser revisados com ActCheck e passar para a fase seguinte do projeto, onde os outros modelos UML, incluindo diagramas de estados serão construídos. A partir deste momento, outras técnicas de inspeção para modelos UML são necessárias para garantir que os modelos produzidos estão corretos e consistentes quando comparados com os diagramas de atividade, os quais passam a representar o oráculo do projeto.
1.2 Objetivo da Solução Proposta
Esta dissertação tem o objetivo de apresentar Shiô, uma técnica de leitura para inspeção de diagramas de estados utilizando diagramas de atividades que descrevem os casos de uso do software (requisitos). A técnica complementa a família de técnicas de leitura OORTs (TRAVASSOS et al.2002).
6 O foco principal de Shiô é a identificação, principalmente, de defeitos semânticos (conteúdo) além de apoiar também a identificação de defeitos sintáticos (notação). A técnica orienta o inspetor a seguir uma sequência de passos, com dados de entrada e de saída bem definidos, apresentando uma série de instruções que guiam o inspetor a encontrar os defeitos. Assim, a técnica instrui os inspetores a realizar marcações nos diferentes recursos sintáticos utilizando cores pré-definidas em ambos os diagramas e, em seguida, é feita uma comparação entre os elementos coloridos nos diagramas, de forma a apoiar o inspetor na detecção dos defeitos e sua classificação de acordo com a taxonomia (TRAVASSOS, 2001): omissão, fato incorreto, ambiguidade ou informação estranha.
Os diagramas de atividades que a técnica Shiô utiliza devem estar modelados utilizando a proposta de MASSOLLAR (2011), que faz uso de diferentes estereótipos que classificam as ações dos diagramas. Esses estereótipos são explorados pela técnica para a comparação com os recursos sintáticos dos diagramas de estados. Os diagramas de atividades considerados por Shiô, e modelados conforme informado anteriormente, são consistentes com a UML 2.3 (OMG, 2010). Desta forma, esta versão da técnica não trata os recursos sintáticos tais como: eventos, nós buffer, nós de paralelismo e sincronização de ações, raia, nós objetos, sinais, interrupção, região de expansão e exceção que estão previstos nas versões da UML 2.3 e 2.4.1 (OMG, 2011).
Como os diagramas de atividades representam o oráculo para a inspeção, ou seja, são utilizados como referência para a técnica Shiô, os mesmos devem estar inspecionados para estarem consistentes com a especificação de requisitos. Assim uma alternativa é a revisão prévia dos diagramas com ActCheck, um checklist configurável para inspecionar os diagramas de atividades modelados de acordo com MASSOLLAR (2011).
1.3 Metodologia de Trabalho
A técnica de leitura Shiô foi desenvolvida e avaliada com base em experimentação, seguindo um processo de desenvolvimento de tecnologias de software baseado em evidência (SHULL et al., 2001; MAFRA et al., 2006; SPÍNOLA et al., 2008). A Figura 1-2 apresenta um resumo das atividades realizadas neste trabalho.
7 Figura 1-2 Metodologia de pesquisa adotada.
Segundo MAFRA et al. (2006), para que novas tecnologias de software sejam definidas com base em evidência, estudos secundários devem ser executados, que neste caso correspondem às revisões sistemáticas. Essa atividade foi realizada nesta dissertação, onde foi executada uma quasi-revisão sistemática para identificar técnicas de inspeção para diagramas de fluxos de atividades, onde diagramas de estados e atividades se incluem.
Os resultados obtidos no estudo secundário serviram como base para a elaboração da versão inicial da técnica de leitura. A partir deste ponto, os seguintes estudos primários devem ser executados sequencialmente: estudo de viabilidade, estudo observação, estudo de caso em ciclo de vida e estudo de caso na indústria. O estudo de viabilidade tem o objetivo de determinar a usabilidade e a eficiência da nova tecnologia. Esta atividade foi realizada nesta pesquisa, onde foram executados dois estudos de viabilidade para avaliar a técnica de leitura proposta.
Os resultados dos estudos de viabilidade apontaram que a técnica Shiô encontra defeitos não usualmente identificados por inspeções ad-hoc, porém sua aplicação despende um tempo maior do que na inspeção ad-hoc. Os resultados dos estudos foram usados para evoluir a técnica, visando simplificar sua descrição e reorganizar sua estrutura de aplicação.
Após estes estudos, foi realizada a atualização (reexecução) do estudo secundário, indicando a singularidade de Shiô no contexto de técnicas de leitura envolvendo diagramas de estados e atividades.
8
1.4 Organização do Trabalho
Esta dissertação está organizada em seis capítulos, incluindo este, que introduz o trabalho.
O Capítulo 2 trata da fundamentação teórica, apresentando os diagramas de atividades e diagramas de estados, abordando a sua aplicabilidade e os recursos sintáticos de cada diagrama utilizado pela técnica Shiô. O capítulo ainda trata de inspeção de software, apresentando o processo de inspeção, taxonomia de defeitos utilizada e cita algumas técnicas de inspeção em diagramas UML.
O Capítulo 3 aborda a quasi-revisão sistemática conduzida para identificar técnicas de inspeção relevantes em diagramas de fluxos de atividades na literatura técnica. O protocolo definido é apresentado, os termos utilizados para a busca são expostos, assim como os critérios de inclusão e exclusão. Por fim, o resultado encontrado pela quasi-revisão sistemática é analisado.
O capítulo 4 apresenta a técnica de leitura Shiô que visa inspecionar diagramas de estados utilizando os diagramas de atividades que especificam casos de uso como referência. As premissas definidas para a aplicação da técnica é apresentada, assim como a relação entre os dois diagramas utilizados na inspeção. A estrutura da técnica Shiô e a primeira versão da técnica são apresentadas no fim do capítulo.
O capítulo 5 apresenta os dois estudos conduzidos para avaliar a viabilidade da técnica Shiô. Os objetivos, o perfil dos participantes e os planejamentos dos estudos são apresentados, assim como os resultados e as análises dos dados obtidos também são analisadas. As lições aprendidas e as ameaças à validade dos estudos são apresentadas e a segunda versão da técnica Shiô, obtida com base nos resultados dos estudos, é apresentada no final do capítulo.
Por fim, o capítulo 6 apresenta as conclusões desta dissertação, destacando as contribuições da pesquisa e as limitações do trabalho, além das propostas de pesquisas futuras.
9
2 Fundamentação Teórica
Este capítulo trata dos conceitos utilizados nesta dissertação, tais como: diagramas de atividades, diagramas de estados e inspeção de software. Os recursos sintáticos e a aplicabilidade de cada um dos diagramas são apresentados. Adicionalmente, o processo de inspeção, a taxonomia para classificação de defeitos e exemplos de técnicas de inspeção são descritos.
2.1 Introdução
Em um projeto de software após a fase de especificação de requisitos, inicia-se a fase de design, consistindo na criação dos modelos. Assim, vários modelos são criados, de acordo com a necessidade de cada projeto. A UML apoia a criação de modelos, fornecendo notação específica e dividindo os diagramas em estruturais e comportamentais. A Figura 2-1 ilustra os diferentes diagramas pertencentes à UML.
10 Cada um dos tipos de diagrama apresentados na Figura 2-1 visa representar um determinado aspecto do projeto, tendo em vista que o objetivo dos diagramas é diferente entre si. Diagramas estruturais apresentam uma visão estática da solução, permitindo visualizar, por exemplo, as classes e seus relacionamentos que não se alteram ao longo do ciclo de vida do software. Por outro lado, diagramas comportamentais, por exemplo, diagramas de atividades, estados ou sequência descrevem aspectos dinâmicos e comportamentais de um sistema de software, ou seja, os eventos e comportamentos que ocorrem ao longo do ciclo de vida do software.
Assim, após a escolha e elaboração dos diagramas que serão utilizados no projeto, os mesmos podem ser inspecionados a fim de garantir que estão capturando os requisitos corretos e que estão consistentes entre si. Inspeções de software permitem a revisão dos artefatos e a garantia de sua qualidade, além de representar um mecanismo eficiente e de baixo custo para identificar defeitos (BOEHM, 1981; LAITENBERGER e ATKINSON, 1999). Na literatura técnica existem diferentes técnicas de inspeção que objetivam apoiar a inspeção de diagramas de projetos, como por exemplo, OORTs (TRAVASSOS et al., 2002) que consiste em uma família de técnicas de leitura para inspecionar diagramas UML, e OORTs/ProDeS (MARUCCI et al., 2002), que apresenta um conjunto de técnicas de leitura, baseado em OORTs, que inspecionam artefatos de software pertencentes ao processo de desenvolvimento específico, denominado ProDeS/UML (COLANZI, 1999). Outro exemplo de técnica de inspeção é ActCheck (DE MELLO, 2011), que consiste em um checklist para apoiar a inspeção da especificação de requisitos descrita através de diagramas de atividades.
A Figura 2-2 apresenta os artefatos mais comumente utilizados durante a fase de projeto do software, incluindo a especificação de requisitos, casos de usos e diagramas da UML. Nesta figura, as linhas contínuas que ligam as caixas indicam a existência de uma técnica de leitura, pertencente à família OORTs, enquanto que a linha tracejada representa o checklist ActCheck. Estas técnicas serão apresentadas na seção 2.4.3.
11 Figura 2-2 Exemplos de Técnicas de Inspeção em Diagramas da UML (Adaptado de TRAVASSOS,
2002).
O objetivo principal deste capítulo é apresentar os conceitos necessários para esta dissertação, visto que a técnica de leitura proposta inspeciona diagramas de estados utilizando como referência diagramas de atividades. Desta forma, este capítulo apresenta a aplicabilidade destes diagramas e os seus recursos sintáticos. Além disso, o conceito de inspeção também é apresentado, assim como o seu processo, a taxonomia utilizada e alguns exemplos de técnicas de inspeção.
2.2 Diagrama de Atividades
A UML (Unified Modeling Language) sofre constantes evoluções na sua documentação. Assim, a OMG (Object Management Group) lança novas versões no decorrer do tempo desde a sua aceitação em 1997 (OMG, 2001). A partir da versão 2 (no desenvolvimento deste trabalho na versão 2.4.1), a UML passou por uma grande reestruturação, como por exemplo, o diagrama de atividades estendeu sua capacidade para oferecer suporte à modelagem de fluxos em diversos domínios computacionais e até mesmo físicos (BOCK, 2003).
Como mostrado na Figura 2-1, a UML divide os seus modelos em duas categorias: os de representação da estrutura estática e os de representação do comportamento dinâmico dos sistemas (BOCK, 2003). Assim, os diagramas de atividades se classificam no segundo grupo, pois descrevem os aspectos dinâmicos e comportamentais de um sistema de software.
12 2.2.1 Possíveis Usos de Diagramas de Atividades
BEZERRA (2006) descreve algumas situações em que diagramas de atividades podem ser utilizados:
Modelagem de casos de uso: o diagrama de atividades pode representar a descrição de um caso de uso, pois através dos diferentes recursos sintáticos é possível representar, por exemplo, as ações do fluxo principal, do fluxo alternativo e das exceções;
Modelagem do processo de negócio: os diagramas de atividades podem ser utilizados na modelagem do negócio, visando identificar onde estão os pontos com problemas no fluxo de trabalho;
Modelagem de uma operação complexa: os diagramas de atividades podem ser utilizados para detalhar alguma operação ou regra de negócio mais complexa.
2.2.2 Estruturas
Os diagramas de atividades possuem diversos recursos sintáticos. Nesta seção são apresentados apenas os elementos dos diagramas de atividades que serão utilizados pela técnica de inspeção proposta.
Ação
Uma ação representa a unidade atômica de comportamento do diagrama, aquela que não admite decomposição em outras ações, ou seja, é executada de forma ininterrupta. Sua representação é realizada através de um retângulo com os cantos arredondados com um identificador (SILVA, 2007). Uma ação pode ser conectada com outras ações através de setas que representam o fluxo de controle de uma atividade. A Figura 2-3 ilustra as ações “Enviar pagamento” e “Receber pagamento” que estão conectadas.
13 Atividade
Uma atividade representa um elemento não atômico de modelagem de comportamento. Ela pode ser composta por ações ou por outras atividades. A sua representação, assim como na ação, se dá por um retângulo com os cantos arredondados, com um identificador e uma marca de "tridente", indicando a existência de outro diagrama detalhando as informações (SILVA, 2007). A Figura 2-4 ilustra o exemplo do diagrama de atividades "Processar Venda" composta por ações e pela atividade "Separar Produtos", detalhada em outro diagrama de atividades.
Figura 2-4 Exemplo da atividade Separar Produtos.
As atividades podem possuir pré e pós-condições, que correspondem às condições em que o sistema deve estar antes e após a execução da atividade. A representação é feita através dos estereótipos <<precondition>> e <<postcondition>> respectivamente, logo após o identificador da atividade. A Figura 2-4 ilustra um exemplo de pré e pós-condição do diagrama de atividades "Processar Venda".
14 Fluxo de Controle
O diagrama de atividades possui recursos sintáticos para representar diferentes fluxos de controle, tais como (SILVA, 2007):
Nó inicial: representa o início da execução da atividade. Um diagrama pode apresentar mais de um nó inicial. A sua representação é feita através de um círculo totalmente preenchido, ilustrado na Figura 2-5;
Nó final da atividade: representa o final da execução da atividade. Um diagrama pode apresentar mais de um nó final. A sua representação é feita através de um circulo preenchido com borda dupla, ilustrado pela Figura 2-5;
Figura 2-5 Nós inicial e final de atividade.
Nó de decisão: representa a possibilidade de existirem fluxos alternativos, condicionados por expressões. Este nós equivalem ao conceito de if, if-else e switch das linguagens de programação. A sua representação é feita através de um losango, contendo uma entrada e diversas saídas, onde cada saída possui uma expressão, chamada de condição de guarda, representada entre colchetes. A condição de guarda indica o que deve ocorrer para mudar o fluxo de execução do caso de uso. A Figura 2-6 ilustra o nó de decisão e as condições de guarda "Pedido Aceito" e "Pedido Rejeitado", que estão associadas a diferentes fluxos.
15 Figura 2-6 Nó de decisão (Adaptado da OMG, 2011).
2.3 Diagrama de Estados
Pode ser feita uma analogia entre as representações do diagrama de estados com os objetos do mundo real. Por exemplo, uma jarra está cheia de suco (poderia estar vazia) ou que uma pessoa está cansada (poderia estar descansada). A partir destes exemplos é possível observar que os objetos estão alterando os seus estados quando acontece algum evento, seja ele interno ou externo. Assim, quando um objeto muda de um estado para outro, diz-se que ele realizou uma transição entre estados e que essas transições e todos os estados do objeto constituem o ciclo de vida do objeto. Essa analogia aplicada aos objetos do mundo real pode ser aplicada aos objetos de uma classe, modelada por diagramas de classes (BEZERRA, 2006). Assim, os estados (valores dos atributos) correspondem ao nome dado a cada situação da classe-objeto e as transições se referem às mudanças de um estado para outro (SILVA, 2007).
Desta forma, o diagrama de estados da UML (OMG, 2011) permite descrever o ciclo de vida dos objetos de uma classe, apresentando os eventos que causam a transição de um estado para outro. A notação inicial do diagrama foi proposta por David Harel através de seu trabalho com máquinas de estados finitos, posteriormente estendida por Jim Rumbaugh, Mealy e Moore. (BEZERRA, 2006).
O uso do diagrama de estados normalmente está voltado para a modelagem dinâmica de classes, assim como os diagramas de atividades, porém o foco deste diagrama é descrever a evolução de estados de um objeto da classe (SILVA, 2007).
16 2.3.1 Estruturas
A especificação da UML apresenta diversos recursos sintáticos para os diagramas de estados, porém a mesma abordagem adotada para descrever as características de diagramas de atividades será utilizada nesta seção, onde serão apresentados apenas os elementos que estão presentes nos diagramas de estados e que serão utilizados pela técnica de inspeção proposta.
Estado
Um estado corresponde a uma situação em que um objeto se encontra durante o seu ciclo de vida. Assim, um estado pode ser uma situação na qual o objeto permanece até que ocorra um evento que o faça sair dele ou a execução de uma tarefa, sendo que o final da execução acarretaria a saída da situação.
A representação de estado simples é um retângulo de cantos arredondados, com um identificador que corresponde ao nome do estado. A Figura 2-7 ilustra um exemplo de um estado.
Figura 2-7 Exemplo de estado.
Os estados de um objeto podem variar de acordo com o contexto em que está sendo modelado. Por exemplo, o objeto automóvel no contexto de movimento pode se comportar conforme ilustrado na Figura 2-8. Supondo agora o mesmo objeto automóvel no contexto de uma oficina mecânica (Figura 2-9), os estados neste contexto são totalmente diferentes do diagrama anterior. Assim, um mesmo objeto automóvel pode assumir estados diferentes de acordo com o contexto com o qual o modelo foi construído (SILVA, 2007).
17 Figura 2-8 Diagrama de estados para Automóvel, tendo como foco o movimento (Adaptado de
SILVA, 2007).
Figura 2-9 Diagrama de estados para Automóvel no contexto de uma oficina mecânica (Adaptado de SILVA, 2007).
Os diagramas de estados, assim como os diagramas de atividades, possuem estado inicial e estado final. No diagrama de estados deve existir apenas um estado inicial e a sua representação é feita através de um círculo fechado. O estado final é representado através de um círculo fechado com uma borda dupla e pode existir mais de um estado final em um diagrama de estados (BEZERRA, 2006). A Figura 2-10 (a) ilustra o estado inicial e a Figura 2-10 (b) o estado final. A representação de estado inicial e final do diagrama de estados é igual a representação do diagrama de atividades.
18 Figura 2-10 (a) Estado incial (b) Estado final.
Transição de Estado
Os estados estão associados a outros pelas transições, que são representadas como uma linha direcionada conectando os estados. Quando ocorre uma transição entre estados, diz-se que a transição foi disparada. Vale ressaltar que transição para o mesmo estado é válida. Detalhes de uma transição são descritos através do formato evento [guarda]. Assim, tem-se que (BEZERRA, 2006):
Eventos: uma transição possui um evento associado e este provoca a transição do estado. A Figura 2-11 ilustra o diagrama de estados de "Venda" e apresenta as transições com os eventos "Recebendo produtos", "Pagamento [dinheiro]", "Pagamento [cartão de crédito]", "Saldo insuficiente no cartão de crédito" e "Saldo suficiente no cartão de crédito".
Condição de guarda: expressão que resulta em um valor lógico (verdadeiro ou falso). Assim, o evento associado à condição de guarda só ocorre quando a condição for verdadeira. Vale ressaltar que é importante não confundir condição de guarda de uma transição com um evento de mudança, que também é definido através de uma expressão de valor lógico. A diferença está no fato da expressão da condição de guarda estar sempre apresentada entre colchetes. A Figura 2-11 ilustra dois eventos com diferentes condições de guarda: “[dinheiro]” e “[cartão de crédito]”. O objeto no estado "Aguardando Pagamento" pode ir para o estado "Autorizado o Pagamento" caso o evento "Pagamento" com a condição de guarda [dinheiro] seja verdadeira. Outra possibilidade é a transição entre o estado "Aguardando Pagamento" para "Aguardando Autorização do Cartão de Crédito", caso o evento de “Pagamento” ocorra com a condição de guarda [cartão de crédito] sendo verdade.
19 Figura 2-11 Diagrama de estados de Venda.
Estados Compostos
Segundo SILVA (2007) a utilização dos estados compostos está relacionada à descrição de um diagrama de estados mais complexo e, portanto, com maiores detalhes. Assim tomando o exemplo do automóvel da
Erro! Fonte de referência não encontrada.
, este mesmo diagrama poderia ser modelado como ilustra a Figura 2-12, onde existe o superestado “em movimento” que contém os subestados “acelerando”, “freando” e “em velocidade constante”. A Figura 2-13 representa um modelo alternativo ao da Figura 2-12, onde são acrescentados um estado final e um pseudo-estado inicial no superestado. Entretanto, note que ambos os modelos possuem o mesmo significado.20 Figura 2-12 Modelagem de estados para Automóvel, com estado composto (Adaptado de SILVA,
2007).
Figura 2-13 Modelagem alternativa para Automóvel, com estado composto (Adaptado de SILVA, 2007).
Submáquina
O uso de submáquinas está relacionado também à modelagem de sistemas mais complexos, onde a utilização de estados compostos resulta em um diagrama com muitos elementos, prejudicando a legibilidade do diagrama. Assim, o uso da submáquina surge
21 como solução para este problema, onde os subestados do superestado correspondem a um novo diagrama e o superestado corresponde a submáquina no diagrama de estados (SILVA, 2007).
A Figura 2-14 apresenta a submáquina "em movimento" do objeto Automóvel. Esta modelagem supõe a existência de outro diagrama de estados cujo conteúdo deve ser exatamente o conjunto de subestados de “em movimento” presente na Figura 2-13.
Figura 2-14 Modelagem de Automóvel com estado submáquina (SILVA, 2007).
2.4 Inspeção de Software
O conceito de inspeção de software foi introduzido por (FAGAN, 1976) sendo um tipo particular de revisão de software. Seu principal objetivo é encontrar defeitos no artefato que está sendo inspecionado. Inspeções são consideradas atividades de garantia da qualidade, permitindo que defeitos sejam detectados nas fases iniciais do desenvolvimento e, com isso, evitando sua propagação para fases posteriores do projeto, reduzindo o custo com as atividades de teste e, por consequência, reduzindo o custo total de desenvolvimento (PETERSON, 2002).
Inspeção de software é uma atividade recomendada para a melhoria da qualidade e traz diversos benefícios para um projeto, tais como: redução de esforço (CONRADI et al., 1999), redução do tempo (GILB e GRAHAM, 1993), redução de custo (LAITENBERGER e ATKINSON, 1999) e aumento da produtividade (GILB e GRAHAM, 1993).
Outra forma de detectar defeitos em um sistema é através das falhas reveladas pelos testes, porém os testes ocorrem em um momento posterior às inspeções, quando já
22 se tem grande parte do produto "pronto". Estudos, como de BASILI e SELBY (1987), mostram que os defeitos encontrados por testes e inspeções são de tipos diferentes. Assim, a aplicação de inspeções e testes em um sistema se apresenta como uma abordagem necessária para garantir a entrega do produto desejado com qualidade.
A especificação de requisitos é muito importante em um projeto de software, pois ela descreve todas as funcionalidades do software a ser entregue e fornece uma referência para a validação do produto final. Assim, ter a especificação de requisitos inspecionada e com alta qualidade é um pré-requisito fundamental para um software de alta qualidade (JALOTE, 2005).
Entende-se que inspeções não devem ser realizadas pelo próprio autor do documento, ou seja, pessoas não envolvidas com a criação do documento a ser inspecionado devem realizar a inspeção. Com isso, evita-se o viés do autor em considerar que o artefato produzido está totalmente coerente com a especificação e livre de defeitos.
2.4.1 Processo de Inspeção
Na literatura técnica existem diferentes processos de inspeção com base no processo original proposto por FAGAN (1976). Um exemplo é o processo apresentado por WONG (2006), composto por seis atividades ilustradas na Figura 2-15.
Figura 2-15 Processo de inspeção de software de FAGAN (de acordo com WONG, 2006).
23 Planejamento: organiza e prepara o processo de inspeção, envolvendo tarefas tais como: preparar os artefatos a serem inspecionados, escolher a técnica que será utilizada durante a inspeção, agendar a reunião e selecionar os inspetores e definir seus papéis;
Overview: atividade opcional e recomendada quando o artefato a ser inspecionado é complexo, ou seja, difícil de entender. Nesta atividade, o autor do artefato a ser inspecionado oferece um treinamento aos inspetores para que possam se familiarizar com o documento e o sistema como um todo;
Preparação Individual: os participantes da inspeção tentam compreender o artefato individualmente antes da fase de reunião, realizando sua leitura e indicando as discrepâncias. Segundo WONG (2006), estudos evidenciam que conduzir esta atividade é custoso e que a mesma não é necessária quando a inspeção é realizada individualmente;
Reunião de grupo: o objetivo principal desta atividade é detectar defeitos. As listas de discrepâncias são discutidas e classificadas. Assim como a atividade de preparação individual, esta também é custosa para o projeto. WONG (2006) relata diversos estudos que identificaram uma maior eficiência na detecção de defeitos quando esta é realizada em pequenos grupos ou individualmente, visto que reuniões com uma quantidade muito grande de participantes acarretam em uma dispersão da atenção dos participantes;
Retrabalho: o autor do artefato inspecionado recebe a lista de defeitos e os corrige;
Continuação: avalia a qualidade das correções realizadas no artefato inspecionado. Neste momento o moderador decide se uma inspeção será necessária. Métricas tais como: número total de defeitos, tempo dedicado a preparação individual e a reunião de inspeção e o número de inspetores envolvidos, podem ser usadas para apoiar esta decisão.
24 2.4.2 Taxonomia de defeitos
Na literatura técnica existem diversas taxonomias para classificação de defeitos, diferindo entre si em relação à quantidade de categorias e seus detalhamentos. A taxonomia utilizada nesta dissertação segue, por conveniência, a classificação adotada em TRAVASSOS (2001), que apresenta um conjunto de classes genéricas de defeitos não mutuamente exclusivas, ou seja, um defeito pode pertencer a mais de uma categoria.
Os tipos de defeitos variam de acordo com as necessidades de cada projeto, além de variar de acordo com o artefato inspecionado. A Tabela 2-1 descreve cada classe de defeito e apresenta um exemplo do tipo de defeito em questão.
Tabela 2-1 Tipos de defeitos de software (Adaptado de TRAVASSOS, 2001).
Categoria Descrição Exemplo
Omissão Informações necessárias sobre o sistema que foram omitidas do artefato de software
Algum requisito importante do projeto não foi incluído.
Fato Incorreto Algumas informações no artefato de software contradizem as informações presentes na especificação de requisitos ou o conhecimento geral do domínio
Um requisito descreve um fato que não é verdadeiro, considerando o contexto para qual o sistema está sendo desenvolvido.
Inconsistência Algumas informações no artefato de software estão inconsistentes com outras no artefato.
Dois ou mais requisitos são conflitantes.
Ambiguidade As informações no artefato de software são ambíguas, sendo possível ao desenvolvedor interpretá-las de diferentes maneiras, podendo levar a uma implementação incorreta.
Um requisito tem várias interpretações devido à diferentes termos utilizados para uma mesma característica ou vários significados de um mesmo termo para um contexto particular.
Informação estranha
As informações fornecidas não são necessárias ou nem usadas. São informações adicionais inseridas sem necessidade.
As informações contidas nos requisitos não fazem parte do contexto para qual o sistema está sendo desenvolvido.
2.4.3 Exemplos de Técnicas de Inspeção
A técnica de inspeção escolhida no processo de inspeção influencia diretamente no resultado das inspeções. A inspeção pode ser realizada de forma ad-hoc, ou seja, quando nenhum tipo de técnica ou heurística é fornecida ao inspetor. Este tipo de inspeção utiliza apenas o conhecimento e experiência do inspetor e é também conhecida como “leitura sem técnica” (PETERSSON, 2002). Assim, para que a inspeção ad-hoc
25 tenha um bom resultado, é necessário que os inspetores mais experientes realizem a atividade de inspeção. Entretanto, a alocação de profissionais com alto grau de experiência eleva o custo do projeto, quando comparado com a utilização de profissionais com menos experiência.
Outra forma de inspecionar os artefatos de software é através do uso de checklists, que consistem em uma série de questões que o inspetor deve considerar durante a inspeção, respondendo "sim" ou "não" para cada uma delas (LAITENBERGER et al., 2001). A inspeção utilizando checklist é classificada de forma distinta por diferentes autores. Por exemplo, SHULL et al. (2000) consideram o checklist uma técnica de leitura parcialmente sistemática e não focada. Já PORTER et al. (1995) classificam a inspeção utilizando checklist e ad-hoc como técnicas de leituras não sistemáticas. O uso de checklists nas inspeções tende a auxiliar os inspetores menos experientes nesta tarefa, diferente da inspeção ad-hoc que é totalmente dependente da experiência do inspetor.
Técnica de leitura é outra abordagem conhecida na literatura técnica para inspecionar artefatos de software. Segundo SHULL et al. (2003), as técnicas de leitura consistem em um conjunto de instruções que orientam o inspetor a refletir sobre a informação discrepante, apoiando assim a detecção de defeitos no artefato. Este tipo de inspeção aumenta a eficiência dos inspetores (TRAVASSOS, 2001) e, como com checklists, inspetores menos experientes tendem a obter melhor desempenho quando comparado com inspeções ad-hoc. Diferente da inspeção com checklist e ad-hoc, as técnicas de leitura possuem um comportamento sistemático e intuitivo (HE e CARVER, 2006). É possível encontrar na literatura técnica diferentes técnicas de leitura, tais como:
UBR (Usage-Based Reading): a ideia principal é focar o esforço da inspeção nos defeitos mais críticos do artefato inspecionado. Este tipo de técnica utiliza o ponto de vista do usuário para identificar os defeitos que ele julga ter maior impacto negativo no sistema (THELIN et al., 2001);
DBR (Defect-Based Reading): esta família de técnicas visa a inspeção de documentos de requisitos, onde cenários são descritos para apoiar a identificação de tipos específicos de defeitos (PORTER e VOTTA, 1994; PORTER et al., 1995).
PBR (Perspective-Based Reading): representa uma família de técnicas de leitura contendo diferentes perspectivas: projetista, usuário e testador. Assim, para cada
26 uma das perspectivas, PBR assegura que o inspetor avaliará o documento de requisitos seguindo este ponto de vista. As técnicas orientam durante a inspeção a criação de um documento de apoio representando a abstração de cada perspectiva: diagramas de classes, casos de uso e conjunto de casos de teste, para as perspectivas de projetista, usuário e testador, respectivamente (SHULL et al., 2000).
MBR (Metric-Based Reading): técnica de leitura que visa detectar defeitos em modelos de casos de uso. A técnica assume a premissa de que os valores de algumas métricas e casos de uso podem ser vistos como potenciais indicadores de defeitos. Assim, cada métrica apresenta uma faixa de valores nos quais os valores fora da faixa definida seriam um indicativo de maior probabilidade de ocorrência de defeitos nos modelos de casos de uso (BERNARDEZ et al., 2004).
Diversas técnicas de inspeção foram desenvolvidas utilizando os conceitos de checklist e de técnicas de leitura envolvendo os artefatos de projeto. A seguir, são apresentados alguns exemplos de técnicas de inspeção existentes na literatura técnica. Estas técnicas utilizam de alguma forma os diagramas da UML (OMG, 2011) na inspeção. As técnicas apresentadas são duas técnicas de leitura e um checklist, denominadas: OORTs (TRAVASSOS et al., 2002), OORTs/ProDeS (MARUCCI et al., 2002) e ActCheck (DE MELLO, 2011).
OORTs
OORTs (Object-Oriented Reading Techniques) é uma família de técnicas de leitura, desenvolvida por (TRAVASSOS et al., 1999), que possui o propósito de detectar defeitos nos diagramas OO (Orientados a Objeto) utilizando a notação da UML. OORTs possui sete diferentes técnicas de leitura que apoiam a inspeção dos diagramas de classes, sequência e estados em comparação com a especificação de requisitos e descrição de casos de uso.
OORTs possui dois níveis de inspeção: a inspeção horizontal (verificação) e a inspeção vertical (validação). O primeiro nível de inspeção consiste em comparar documentos na mesma fase do projeto, com o objetivo de identificar se os diagramas descrevem um mesmo sistema, enquanto que a inspeção vertical inspeciona artefatos de diferentes fases do projeto, com o objetivo de verificar se os diagramas são válidos em
27 relação à especificação dos requisitos e os casos de uso. A Tabela 2-2 apresenta as técnicas pertencentes à OORTs, definindo quais são os artefatos inspecionados e a orientação de cada uma das técnicas.
Tabela 2-2 Técnicas de Leitura OORTs (Adaptado de TRAVASSOS, 2002).
Artefatos inspecionados Nível
Diagrama de Sequência x Classes Horizontal Diagrama de estados x Descrição de Classes Horizontal Diagrama de Sequência x Diagrama de Estados Horizontal Diagrama de Classes x Descrição de Classes Horizontal Descrição de Classes x Descrição de Requisitos Vertical
Diagrama de Sequência x Casos de Uso Vertical Diagrama de Estados x Descrição de Requisitos e Casos de Uso Vertical
A estrutura das técnicas de leitura é semelhante, onde cada uma das técnicas apresenta o objetivo e uma sequência de passos para orientar o inspetor a realizar a inspeção. As entradas e saídas de cada passo são descritas, além de fornecer uma série de instruções que orientam o preenchimento de um relatório de discrepância, ajustado para cada nível de leitura.
OORTs/ProDeS
OORTs/ProDeS (MARUCCI et al., 2002) representa um conjunto de técnicas de leitura que visam inspecionar artefatos de software pertencentes ao processo de desenvolvimento específico, denominado ProDeS/UML (COLANZI, 1999). Este processo é baseado no método Fusion (COLEMAN et al., 1994), utiliza a notação da UML nos artefatos gerados e define atividades de testes ao longo de todas as fases do desenvolvimento. ProDeS/UML é composto de 4 fases: engenharia de requisitos, análise, projeto e implementação.
Um estudo de viabilidade foi conduzido com o intuito de verificar a aplicação de OORTs sobre os artefatos gerados pelo ProDeS/UML. Assim, foi possível observar que os artefatos da fase de projeto foram todos praticamente cobertos pelas técnicas de OORTs, mas os artefatos presentes nas fases de engenharia de requisitos e de análise careciam de técnicas de leitura.
28 Os autores propuseram então um conjunto de oito técnicas de leitura para os documentos gerados nestas outras fases do processo de desenvolvimento. As técnicas de leitura foram baseadas em OORTs e, portanto, possuem uma estrutura muito similar à OORTs. A Tabela 2-3 apresenta o conjunto de técnicas de leitura criadas, indicando a fase do processo de desenvolvimento, os documentos inspecionados, o tipo e a orientação de cada uma das técnicas.
Tabela 2-3 Técnicas de Leitura para apoiar o processo de desenvolvimento ProDeS/UML (Adaptado de MARUCCI et al., 2002).
Técnica Fase do Processo
Artefatos Inspecionados Tipo Nível ER1 Engenharia de
Requisitos
Diagrama de Casos de Uso x Especificação dos Casos de Uso x
Documento de Requisitos
Validação Vertical
ER2 Engenharia de Requisitos
Diagrama de Classes do Domínio x Diagrama de Casos de Uso x Especificação dos Casos de Uso
Verificação Horizontal
A1 Análise Diagrama de Classes da Análise x Diagrama de Classes do Domínio x
Documento de Requisitos
Validação Vertical
A2 Análise Modelo de Operações x
Especificação dos Casos de Uso
Verificação Vertical A3 Análise Diagrama de Classes da Análise x
Modelo de Operações
Verificação Horizontal A4 Análise Modelo de Operações x Modelo de
Ciclo de Vida x Documento de Requisitos
Validação Vertical
P8 Projeto Diagrama de Classes da Análise Refinado x Diagrama de Visibilidade x Diagrama de Classes
da Análise x Documento de Requisitos
Validação Vertical
P9 Projeto Descrição de Classes x Modelo de Operações
Verificação Vertical
ActCheck
Este checklist para inspecionar requisitos descritos em diagramas de atividades (DE MELLO, 2011) foi criado com o objetivo de detectar defeitos em diagramas de atividades que utilizam a abordagem de MASSOLLAR (2011). Assume-se que a especificação dos requisitos já foi devidamente inspecionada. A primeira versão de ActCheck contém dois checklists configuráveis a partir de um questionário de
29 caracterização da aplicação. Assim, os checklists para cada projeto só conterão questões pertinentes, ou seja, são retiradas as questões que não fazem parte do escopo do projeto. Os checklists da técnica são denominados checklist A e checklist B. O primeiro contém itens de avaliação específicos para verificação da rastreabilidade entre os diagramas de atividades e a descrição textual dos requisitos. O outro, checklist B, deve ser aplicado após o checklist A e tem como objetivo verificar a consistência interna de um diagrama de atividades e a sua relação com os outros diagramas de atividades referentes a mesma especificação de requisitos.
2.5 Conclusão
Inspeções de software são atividades importantes na detecção de defeitos, principalmente por detectar defeitos na fase inicial do projeto, evitando que os defeitos se propaguem para fases posteriores do desenvolvimento. Caso esses defeitos fossem propagados, o custo para corrigi-los na fase de teste seria muito maior quando comparado ao custo para corrigir durante a fase de design.
Os dois diagramas da UML descritos neste capítulo, diagrama de atividades e diagrama de estados, possuem recursos sintáticos semelhantes em simbologia, porém com foco distinto, visto que o diagrama de estados tem por finalidade modelar o ciclo de vida dos objetos do sistema enquanto que o diagrama de atividades visa modelar as atividades realizadas pelo sistema, ou seja, o comportamento dinâmico. Este capítulo apresentou a sua aplicabilidade e os recursos sintáticos utilizados na técnica de inspeção proposta nesta dissertação.
O Capítulo 3 trata de uma revisão quasi-sistemática da literatura técnica que foi conduzida com o intuito de identificar técnicas de inspeção aplicáveis a diagramas de fluxos de atividades em geral, onde diagramas de atividades e, consequentemente, diagramas de estados se incluem.
Existe uma dualidade entre os diagramas de atividades e os diagramas de estados, visto que os eventos que provocam a transição de estados representam ações ou atividades nos diagramas de atividades. Essa relação semântica entre os recursos sintáticos dos diagramas de atividades e o diagramas de estados serão apresentados no Capítulo 4, que trata propriamente da técnica de leitura proposta e apresenta a sua primeira versão.
As inspeções possuem um processo bem definido, com diferentes papéis envolvidos em diferentes atividades. O processo que foi descrito neste capítulo não é
30 único, mas serve como referência para que organizações criem seus próprios processos, de acordo com as suas necessidades. Assim, para que a organização obtenha todos os benefícios da inspeção, a mesma deve ser aplicada de forma sistemática, seguindo o seu processo definido.
