HUMBERTO FERREIRA DA LUZ JUNIOR SOFTWARE PARA AVALIAÇÃO DE CASO DE USO E GERÊNCIA DE CHECKLISTS

HUMBERTO FERREIRA DA LUZ JUNIOR SOFTWARE PARA AVALIAÇÃO DE CASO DE USO E GERÊNCIA DE CHECKLISTS LONDRINA - PARANÁ 2010

HUMBERTO FERREIRA DA LUZ JUNIOR SOFTWARE PARA AVALIAÇÃO DE CASO DE USO E GERÊNCIA DE CHECKLISTS Relatório Final de Estágio Obrigatório apresentado ao Curso de Computação, Departamento de Computação da Universidade Estadual de Londrina, como requisito parcial para a obtenção do título de Bacharel, sob orientação do Prof. Dr. Rodolfo Miranda de Barros. LONDRINA - PARANÁ 2010

HUMBERTO FERREIRA DA LUZ JUNIOR SOFTWARE PARA AVALIAÇÃO DE CASO DE USO E GERÊNCIA DE CHECKLISTS Prof. Dr. Rodolfo Miranda de Barros Universidade Estadual de Londrina Prof. Dr. Mario Lemes Proença Jr. Universidade Estadual de Londrina Prof. Ms. Elieser Botelho Manhas Jr. Universidade Estadual de Londrina

RESUMO Atualmente na Fábrica de Projetos de Software e Tecnologia da Informação e Comunicação (GAIA) do Departamento de Computação da Universidade Estadual de Londrina todos os documentos de apoio às atividades de engenharia de software são hospedados e manipulados no Google Docs, algumas vezes em planilhas e outras como documentos de texto. Essa é uma boa solução para o desenvolvimento distribuído, porém muitas vezes torna o acesso às informações mais difícil, diminui a organização da documentação e não considera o relacionamento entre os documentos já que não foi criada para este fim. Durante o desenvolvimento deste trabalho foi desenvolvida uma aplicação Web que armazena os documentos de avaliação dos casos de uso. Esta ferramenta Web será desenvolvida utilizando a linguagem de programação Java EE 5, assim como também os frameworks EJB 3.0 (utilizado nas camadas de regra de negócio e persistência), Java Server Faces e Richfaces (camada web). Também foram utilizados o servidor de aplicação Jboss AS 5.1.0 e o Sistema Gerenciador de Banco de Dados PostgreSQL 8.4. É importante destacar que este sistema faz parte de um projeto maior que implementa um ambiente de apoio ao processo de desenvolvimento de software e aborda funcionalidades não descritas neste trabalho.

SUMÁRIO 1 INTRODUÇÃO... 8 2 PROCEDIMENTOS METODOLÓGICOS... 11 2.1 MyEclipse IDE... 11 2.2 JBoss Application Server... 11 2.3 JDK 1.5... 11 2.4 Enterprise Javabeans 3.0... 12 2.5 Java Server Faces... 12 2.6 Richfaces... 12 2.7 PostgreSQL... 13 2.8 O Processo de Desenvolvimento... 13 2.8.1GAIA e o seu Processo de Desenvolvimento de Software... 13 3 ESPECIFICAÇÕES DE CASOS DE USO... 17 3.1 Manter Checklist... 17 3.1.1 Descrição... 17 3.1.2 Fluxo Básico... 17 3.1.3 Fluxos Alternativos... 17 3.1.4 Requisitos especiais... 18 3.1.5 Precondições... 18 3.1.6 Pós-condições... 18 3.1.7 Pontos de Extensão... 18 31.8 Local View... 18 3.1.9 Definição dos atributos... 19 3.1.10 Protótipo da Interface... 20 3.2 Manter Histórico... 21 3.2.1 Descrição... 21 3.2.2 Fluxo Básico... 21 3.2.3 Fluxos Alternativos... 21 3.2.4 Requisitos especiais... 22 3.2.5 Precondições... 22 3.2.6 Pós-condições... 22 3.2.7 Pontos de Extensão... 22 3.2.8 Local View... 22 3.2.9 Definição dos atributos... 23 3.2.10 Protótipo da Interface... 24 3.3 Manter Revisão... 25 3.3.1 Descrição... 25

3.3.2 Fluxo Básico... 25 3.3.3 Fluxos Alternativos... 25 3.3.4 Requisitos especiais... 25 3.3.5 Precondições... 26 3.3.6 Pós-condições... 26 3.3.7 Pontos de Extensão... 26 3.3.8 Local View... 26 3.3.9 Definição dos atributos... 27 3.3.10 Protótipo da Interface... 28 4 DIAGRAMAS... 29 4.1 Diagrama de Arquitetura... 29 4.2 Diagrama de Entidade e Relacionamento... 31 4.3 Diagrama de Classes... 32 4.4 Diagramas de Atividade... 33 4.4.1 Manter Checklist... 33 4.4.2 Manter Revisão... 33 4.4.3 Manter Histórico... 33 5 RELATÓRIO DE TESTES... 34 5.1 Histórico da Revisão... 34 5.2 Introdução... 34 5.2.1 Ambiente... 34 5.3 Critérios de completeza... 35 5.4 Especificação dos testes... 35 5.4.1 Procedimentos de teste... 35 5.5 Casos de teste e Incidentes dos Testes... 39 5.5.1 Página Gerenciar Checklist... 39 5.5.2 Página Responder Checklist... 40 5.5.3 Página Visualizar Checklist... 41 5.5.4 Página Histórico... 41 5.5.5 Página Gerenciar Revisão... 42 5.6 Relatório resumido dos testes... 42 5 DESIGN DAS PÁGINAS... 44 6 CONSIDERAÇÕES FINAIS... 45 7 BIBLIOGRAFIA... 47

LISTA DE FIGURAS FIGURA 2.1: PROCESSO DE DESENVOLVIMENTO 1... 15 FIGURA 3.1: LOCAL VIEW... 18 FIGURA 3.2: PROTÓTIPO DA INTERFACE... 20 FIGURA 3.3: PROTÓTIPO DA INTERFACE... 20 FIGURA 3.4: PROTÓTIPO DA INTERFACE... 20 FIGURA 3.5: LOCAL VIEW... 22 FIGURA 3.6: PROTÓTIPO DA INTERFACE... 24 FIGURA 3.7: LOCAL VIEW... 26 FIGURA 3.8: PROTÓTIPO DA INTERFACE... 28 FIGURA 4.4.1.1: DIAGRAMA DE ATIVIDADE 1... ANEXO FIGURA 4.4.1.2: DIAGRAMA DE ATIVIDADE 2... ANEXO FIGURA 4.4.1.3: DIAGRAMA DE ATIVIDADE 3... ANEXO FIGURA 6.1: DIAGRAMA DE CASO DE USO 1... 45 LISTA DE TABELAS TABELA 3.1: DEFINIÇÃO DOS ATRIBUTOS... 19 TABELA 3.2: DEFINIÇÃO DOS ATRIBUTOS... 23 TABELA 3.3: DEFINIÇÃO DOS ATRIBUTOS... 27

LISTA DE ABREVIATURAS AJAX - Asynchronous Javascript And XML ANSI - American National Standards Institute API - Application Programming Interface CRUD - Create, Retrieve, Update e Delete, que são operações relativas a Cadastro, Busca, Atualização e Exclusão CSS - Cascading Style Sheets EJB - Enterprise Javabeans HTML - HyperText Markup Language IDE - Integrated Development Environment JDK - Java Development Kit JSF - Java Server Faces JSP - Java Server Pages MPS-BR - Melhoria de Processos do Software Brasileiro PDS - Processo de Desenvolvimento de Software PMBOK - Project Management Body of Knowledge POJO - Plain Old Java Objects RUP - Rational Unified Process SGBD - Sistema Gerenciador de Banco de Dados SGBDOR - Sistema Gerenciador de Banco de Dados Objeto Relacional SQL - Structured Query Language UML - Unified Modeling Language V&V - Verificação e Validação XML - Extensible Markup Language

8 1 INTRODUÇÃO Qualidade de software de forma mais geral é a satisfação de requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo o software desenvolvido profissionalmente [3]. Para satisfazer todas as características esperadas no software, atividades de verificação e validação são necessárias. Verificação e validação é o nome dado aos processos de verificação e análise que asseguram que o software cumpra com suas especificações e atenda às necessidades dos clientes que estão pagando por ele. A verificação e validação constituem um processo de ciclo de vida completo, começando com as revisões dos requisitos e continuando com as revisões de projeto e as inspeções de código até chegar aos testes de produto. Deve haver atividades de V&V em cada estágio do processo de software. Essas atividades verificam se os resultados das atividades de processo estão conforme o especificado [8]. Dentro da área de conhecimento de Integração do PMBOK, o processo que se preocupa com a verificação e validação é tanto o de Monitoramento e controle do trabalho do projeto, como também o de Realização do controle integrado de mudanças. O primeiro processo inclui a coleta, medição e distribuição das informações de desempenho e a avaliação das medições e tendências para efetuar melhorias no processo. Além disso, uma de suas preocupações é a manutenção de uma base de informações precisas e oportunas a respeito do produto(s) do projeto e suas relativas documentações do início ao término do projeto. Já o segundo é o processo de revisão de todas as solicitações, aprovação e gerenciamento de mudanças em entregas, ativos de processos organizacionais, documentos de projeto e plano de gerenciamento de projeto, dentre as suas atividades está a de revisar, aprovar ou rejeitar todas as ações corretivas e preventivas recomendadas pelo processo de monitoramento e controle de projeto já citados. [9] Segundo Hrvoje & Filjar [2] as empresas de desenvolvimento de software deveriam organizar o trabalho em atividades de desenvolvimento de software de forma que possam obter sucesso no mercado global. Estas atividades variam de acordo com a metodologia de processo de desenvolvimento de software (PDS) utilizada.

9 Um dos PDSs mais tradicionais é o Rational Unified Process (RUP), que é um processo adaptável e iterativo que é centrado na arquitetura e orientado a riscos. Os processos do RUP são organizados em quatro fases: concepção, elaboração, construção e transição. [4] Dentro da fase de concepção os requisitos de negócio fundamentais são descritos por meio de casos de uso preliminares [3], já a fase de elaboração refina e expande os casos de uso preliminares que foram desenvolvidos a partir da fase de concepção. Um caso de uso de acordo com Brooch, G., et al [5] é uma descrição de um conjunto de sequências de ações, inclusive variantes, que um sistema executa para produzir um resultado de valor observável por um ator. Apesar de o RUP ser especialmente adequado à UML, ela é amplamente independente de processo, porém para obter o máximo proveito da UML, é preciso levar em consideração um processo que seja orientado a caso de uso, centrado na arquitetura, iterativo e incremental. Ser orientado a caso de uso quer dizer que eles serão utilizados para o estabelecimento do comportamento do sistema, para a verificação e validação da arquitetura do sistema, para a realização de testes e para a comunicação entre os participantes do projeto. Centrado na arquitetura significa que a arquitetura do sistema é utilizada como principal artefato para a conceituação, a construção, o gerenciamento e a evolução do sistema em desenvolvimento. Iterativo é aquele processo que gera versões executáveis em sequência, enquanto incremental quer dizer que essas versões executáveis serão integradas continuamente. [5] Uma das características principais que definem uma fábrica de software é a capacidade de obter feedback do que já foi realizado para reconhecer e lidar com oportunidades de melhoria do processo [6]. Este feedback é obtido através de métricas do projeto, que são medidas quantitativas do grau em que um sistema, componente ou processo possui um determinado atributo [10] e nos dão um modo sistemático de avaliar qualidade com base em um conjunto de regras claramente definidas [3], desta forma os problemas podem ser corrigidos antes que se tornem mais graves. Dentro da Fábrica de Software há documentos de avaliação que coletam estas métricas, dentre eles estão o documento de revisão de caso de uso e o plano de testes. Estes documentos são gerados iterativamente até que a qualidade mínima exigida seja obtida.

10 Devido à importância destes documentos surge a necessidade de automatizar esse processo, de forma que a criação e manutenção dos documentos seja facilitada e que também agilize a coleta de métricas para as próximas iterações do mesmo projeto, como também para outros projetos de software. Este trabalho esta dividido da seguinte forma: no Capítulo 2 estão descritos os procedimentos metodológicos incluindo as ferramentas de desenvolvimento utilizadas como também o processo de desenvolvimento de software adotado, no capítulo 3 são apresentados os três casos de uso implementados neste trabalho, no capítulo 4 são encontrados os diagramas criados no projeto, no capítulo 5 é descrita a situação corrente do trabalho, o capítulo 6 realiza as considerações finais e no último capítulo (7) é apresentada a bibliografia na qual esta dissertação se apoiou.

11 2 PROCEDIMENTOS METODOLÓGICOS subseções seguintes: As ferramentas e tecnologias utilizadas neste trabalho estão descritas nas 2.1 MyEclipse IDE O MyEclipse é uma IDE java construída sobre a plataforma Eclipse que integra soluções proprietárias e open source no ambiente de desenvolvimento [12]. Dentre as vantagens agregadas pelo MyEclipse estão o suporte ao JSF e principalmente à engenharia reversa que ele faz sobre o projeto físico do banco de dados, gerando as classes de persistência e suas respectivas operações de manipulação do banco de dados, de forma que apenas algumas adaptações sejam necessárias nestas classes java. Atualmente este ambiente de desenvolvimento se encontra na versão 8.6, que foi lançada recentemente. Porém no desenvolvimento deste trabalho a versão 8.5 foi a selecionada para ser utilizada no projeto. 2.2 JBoss Application Server O JBoss Application Server (ou JBoss AS) é o servidor de aplicação Java mais utilizado no mundo atualmente. Ele é uma plataforma java EE para desenvolvimento e implantação de aplicações java empresariais para a web. Alguns dos serviços disponibilizados por ele estão a clusterização, caching, e persistência. Uma variedade de configurações muito grande é disponibilizada de modo que se aumente sua segurança e escalabilidade com facilidade. [11] A vantagem de sua utilização é a de poder utilizar os frameworks Enterprise Javabeans (EJBs) e Java Server Faces (JSF) sem a necessidade de configuração adicional. A única necessidade de configuração no JBoss AS é o arquivo data-source, que contém as configurações de conexão com o banco de dados. 2.3 Java Development Kit 1.5 A versão JDK 1.5 apresenta novas extensões para a linguagem de programação Java. Possui um número de classes muito maior do que as versões anteriores (mais de

12 3500), além disso, inclui diversas alterações significativas à própria linguagem, tornando-a mais fácil para os programadores e fornecendo novos recursos já populares em outras linguagens. 2.4 Enterprise Javabeans 3.0 A tecnologia Enterprise Javabeans (EJB) é a arquitetura de componente do lado do servidor para a plataforma Java. A tecnologia EJB permite um desenvolvimento rápido e simplificado de aplicações distribuídas, transacionais, seguras e portáveis baseadas na tecnologia java. [10] O EJB 3.0 permite persistir dados no banco de dados sem o uso de SQL, trabalhando sempre com objetos java simples (POJOs) e utilizando session beans (também conhecidos como façades) para implementar as operações CRUD (Create, Retrieve, Update e Delete) de persistência. Essas classes podem implementar inclusive outras características das tabelas de bancos de dados, como por exemplo a de autogerar o identificador das tabelas e também a possibilidade de buscar um objeto de uma tabela e junto com ele todos os outros objetos de outras tabelas que tenham relacionamento com ele. 2.5 Java Server Faces Java Server Faces (JSF) é um framework java que traz o desenvolvimento rápido de interfaces web de usuário. Ele gerencia regras de navegação, validação e conversão de campos de formulários. [15] O JSF ainda é capaz ainda de se integrar ao EJB, mesmo que esta integração não seja com perfeição, já que é requerido mais código do que deveria ser necessário. O framework JBoss Seam foi criado para resolver este problema e unir o JSF e o EJB a um único bloco, porém este framework não é abordado nem utilizado neste trabalho. 2.6 Richfaces Richfaces é uma biblioteca de componentes para JSF e um framework avançado para integrar o AJAX às aplicações de negócio. Entres suas vantagens está o mecanismo chamado skinnability que permite que você altere o visual da sua aplicação

inteira modificando apenas uma linha de um arquivo, além disso ele também possui uma grande comunidade para suporte. [13] 13 2.7 PostgreSQL O PostgreSQL é um sistema gerenciador de banco de dados objeto relacional (SGBDOR) desenvolvido como projeto de código aberto. Sua vantagem é que além de ser gratuito, ele não possui limite no tamanho máximo do banco de dados, sua implementação está dentro do padrão ANSI-SQL92/99, possui suporte completo a sub-queries e diversas funcionalidades mais complexas que o deixa no mesmo nível de diversos SGBDs pagos. [14] 2.8 O Processo de Desenvolvimento O processo de desenvolvimento de software compreende um conjunto de atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de produzir softwares que atendam aos requisitos especificados pelos usuários (clientes). A equipe de desenvolvimento de software possui uma missão: entregar software de qualidade, dentro do prazo e custo, que atenda aos requisitos do negócio e que seja flexível para acomodar as mudanças futuras nas necessidades dos usuários. O processo tem que ser customizável para não engessar a equipe numa forma de trabalho burocrática. 2.8.1 GAIA e o seu Processo de Desenvolvimento de Software Uma fábrica de software é uma organização que provê serviços de desenvolvimento de sistemas com alta qualidade, baixo custo e de forma rápida, utilizando um processo de desenvolvimento de software bem definido e tecnologia de ponta, além de algumas formas de feedback para reconhecer e lidar com oportunidades de melhoria do processo [16]. Basicamente, as Fábricas de Software podem ser classificadas em Fábricas de Programas, Fábricas de Teste e Fábricas de Projetos. As Fábricas de Programas caracterizam-se por atuarem em apenas uma porção do processo produtivo do software. Seu objetivo é codificar e testar programas conforme um acordo de níveis de serviços com

14 o cliente ou usuário. As Fábricas de teste atuam no teste do software verificando e validando se a codificação está em conformidade com a especificação de requisitos. E as Fábricas de Projetos, por sua vez, atuam com um pouco mais de abrangência no processo de produção, englobando além das atividades inerentes à Fábrica de Programas e à Fábrica de Testes, fases como modelagem de negócio, requisitos, análise e design. Tem-se também, a chamada Fábrica de Projetos de Software ou Fábrica de Projetos Ampliada que, além da abrangência da Fábrica de Projetos, atua também na arquitetura da solução. Seu objetivo é a conceituação do software, preocupando-se em projetar uma solução em que o software se caracteriza apenas como um dos componentes. O processo de desenvolvimento de software compreende um conjunto de atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de produzir softwares que atendam aos requisitos especificados pelos usuários ou clientes. A Fábrica GAIA utiliza um processo de desenvolvimento baseado no Processo Unificado, iterativo e incremental [17], direcionado a casos de uso e centrado na arquitetura. A partir de uma perspectiva de gerenciamento baseada no PMBOK [18], o Processo de Desenvolvimento de Software da GAIA é dividido em seis fases, cada uma concluída por um marco principal. A Fig. 2.1 apresenta este Processo e a forma como a Gerência de Comunicação atua com o Processo GAIA, ou seja, em paralelo a este Processo. Cada fase do processo é composta por atividades, sendo que cada uma destas atividades são descritas por um fluxo de trabalho composto por tarefas a serem realizadas pelos atores do processo, gerando artefatos (atas, documentos, código fonte, planos de testes).

15 Figura 2.1: Processo de Desenvolvimento 1 Análise Inicial: reunião com o cliente para entendimento do problema e definição do escopo. O número de reuniões é definido pela equipe de analistas, visto que, por política organizacional [19], a GAIA investe na qualidade deste escopo, minimizando ao máximo problemas de falta de entendimento, insatisfações futuras do cliente pelo fato do sistema não atender suas necessidades, evitando com isso o retrabalho. O resultado deste investimento é a minimização dos riscos do projeto. Para cada reunião é gerada uma ata que deve ser assinada por todos os participantes, firmando o comprometimento de todos os envolvidos e para que os assuntos tratados sejam disponibilizados eletronicamente a todos os demais integrantes do desenvolvimento deste produto. Ao término desta etapa, tem-se uma proposta para o cliente, incluindo o escopo que é representado por uma Work Breakdown Structure (WBS), premissas, riscos, o prazo (em meses) para o desenvolvimento e o custo do projeto. Para estabelecimento dos prazos e custos utiliza-se um banco de dados histórico do desempenho da equipe em projetos similares; Análise e Planejamento: Após a aprovação da proposta, deve-se iniciar o planejamento do projeto, por meio da definição dos casos de uso e das respectivas especificações, dos riscos e prioridades de desenvolvimento, da expansão da WBS, da alocação de pessoas, da elaboração do cronograma, do estabelecimento de pontos de controle, do número de iterações e de quais casos de uso serão desenvolvidos em cada iteração. É gerado um artefato intitulado Plano de Projeto. Vale ressaltar que esta fase do processo de desenvolvimento da GAIA ocorre de maneira iterativa, ou seja, após

16 definirmos e iniciarmos a primeira iteração, no término da mesma, caso o desenvolvimento deva continuar, esta fase é disparada novamente. Nesta fase também ocorre o estabelecimento do grau de severidade para a aprovação ou não dos resultados das atividades pelo projeto. O grau de rigorosidade implica diretamente no controle da qualidade do projeto, ou seja, quanto menor a grau de rigorosidade, mais rígido é o processo de garantia de qualidade do projeto; Monitoramento e Controle: Paralelamente a Análise e Planejamento, deve-se iniciar o monitoramento e controle do projeto, buscando verificar se o que está sendo feito está de acordo com o planejado, tomando ações corretivas quando necessário. Esta verificação deverá ser feita nos pontos de controle indicados no artefato Plano de projeto; Execução: Nesta fase ocorre a especificação e a implementação dos respectivos casos de uso e os testes unitários. A especificação dos casos de uso deve ser verificada e validada. Caso ocorra uma quantidade igual ou superior de não conformidades aceitáveis para o projeto em questão, a iteração deve ser cancelada e um novo planejamento deve ser estabelecido levando-se em consideração os atrasos e as consequências dos mesmos. Após uma análise do resultado dos testes, decide-se, baseado também no grau de rigorosidade, por corrigir as não conformidades encontradas e realizar novamente os testes e partirmos para a próxima fase intitulada Entrega ou cancelarmos a iteração e voltarmos para a fase de Análise e Planejamento; Entrega: Esta fase está responsável por executar os testes de integração que, caso registre um resultado positivo, iniciará a entrega e implantação da parte do produto desenvolvida até a presente iteração. Se o projeto ainda não terminou, a fase de Análise e Planejamento é iniciada novamente. Do contrário, a fase de Finalização é iniciada; Finalização: Nesta faze é realizada um reunião de término do projeto, na qual são levantadas as lições aprendidas, sendo as mesmas registradas em ata para futuras consultas e melhorias no processo de desenvolvimento. É gerado um documento indicando o recebimento do produto pelo cliente e o término do projeto. Todas as fases do processo foram definidas com o propósito de ser o mais simples possível, porém mantendo o formalismo para garantir a qualidade do desenvolvimento nas nuvens.

17 3 ESPECIFICAÇÕES DE CASOS DE USO Nesta seção são apresentadas as especificações de caso de uso desenvolvidas durante a análise de requisitos. Um modelo de caso de uso consiste no conjunto de todos os casos de uso para o sistema, ou uma porção do sistema, junto com o conjunto de todos os atores que interagem com estes casos de uso, descrevendo assim a funcionalidade completa do sistema. Ele fornece um modelo das funções planejadas do sistema e seu ambiente, e pode servir como um contrato entre o cliente e os desenvolvedores. 3.1 Manter Checklist 3.1.1 Descrição Caso de uso para cadastro, edição e remoção de checklists. Estas checklists nada mais são do que perguntas utilizadas para verificação e validação. 3.1.2 Fluxo Básico Este caso de uso é disparado pelo gerente de projeto que desejar inserir uma nova checklist à base de dados. Primeiramente os dados da nova checklist a ser inserida devem ser preenchidos no formulário. A seguir as perguntas associadas àquele checklist criado devem ser inseridas. Finalmente o botão de envio dos dados deve ser pressionado. Neste momento ocorre a validação dos dados, se a validação ocorrer com sucesso a checklist será salva na base de dados, caso contrário irá para o primeiro fluxo alternativo. 3.1.3 Fluxos Alternativos Formulário não é validado com sucesso : caso algum dos campos do formulário não seja preenchido corretamente, a mesma página será exibida novamente para que o ator faça a correção e possa realizar a submissão com sucesso. Ator deseja editar os dados de uma checklist: neste caso o ator seleciona uma das checklists disponíveis exibidas em formato de tabela, utilizando opcionalmente um dos filtros de busca, e clica na opção de edição da checklist correspondente. A seguir o

usuário edita os dados do formulário (incluindo o questionário da checklist) e os submete clicando em um botão. 18 Ator deseja excluir uma checklist: neste caso o ator seleciona uma das checklists exibidas em formato de tabela, utilizando opcionalmente um dos filtros de busca, e clica na opção de exclusão da checklist correspondente. Ator deseja apenas visualizar os dados de uma checklist: neste caso o ator seleciona uma das checklists exibidas em formato de tabela, utilizando opcionalmente um dos filtros de busca, e clica na opção de edição da checklist correspondente. Uma janela irá surgir com todos os dados da pergunta solicitada. 3.1.4 Requisitos especiais Este caso de uso não possui requisitos especiais. 3.1.5 Precondições Este caso de uso não possui pré-condições. 3.1.6 Pós-condições Este caso de uso não possui pós-condições. 3.1.7 Pontos de Extensão Este caso de uso não possui pontos de extensão. 31.8 Local View Figura 3.1: Local View

19 3.1.9 Definição dos atributos Nome da Tipo Limitações Descrição Interface Obrigatório variável idpergunta Integer - Identificador da pergunta s/interface, será Sim gerado automáticamente. enunciado String Até 200 Enunciado da pergunta Inputtext Sim caracteres. tipo char 1 caracter. Tipo da pergunta (múltipla escolha ou Dropbox Sim dissertativa) alternativas String[] Até 100 Alternativas de resposta (caso múltipla escolha) Datatable Não caracteres. resposta String Até 100 Resposta correta da múltipla escolha ou da Inputtext Sim caracteres. dissertativa data_hora Date - Horário em que a resposta foi submetida s/interface, será Sim gerado automáticamente. Tabela 3.1: Definição dos Atributos

20 3.1.10 Protótipo da Interface Protótipo para adicionar checklist: Figura 3.2: Protótipo da Interface Protótipo para adicionar perguntas dissertativas: Figura 3.3: Protótipo da Interface Protótipo para adicionar perguntas dissertativas: Figura 3.4: Protótipo da Interface

21 3.2 Manter Histórico 3.2.1 Descrição Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um histórico dos testes realizados em projetos de software. 3.2.2 Fluxo Básico O caso de uso é disparado pelo analista de sistemas que armazena no histórico uma ficha que está sendo persistida (de Revisão ou Checklist por exemplo). O ator preenche os dados requeridos (ver tabela na seção 8) e clica em salvar. Após isto ocorre a validação do formulário, se o formulário não for validado corretamente o sistema entrará no fluxo alternativo 2.2.2, caso contrário os dados serão persistidos na base de dados. 3.2.3 Fluxos Alternativos Alterar um histórico cadastrado: o ator pode alterar um histórico de uma revisão ou checklist já cadastrada através de uma tabela exibida na tela, clicando em seu respectivo botão de edição. Os dados deverão ser modificados, então validados e salvos. Se os dados não forem validados corretamente o fluxo irá para 2.2.2. Formulário não validado: após a não validação a página será reexibida para a correção do preenchimento do formulário. Após a correção os dados serão validados novamente. Excluir um histórico cadastrado: o ator pode excluir um histórico já cadastrado através de uma tabela exibida na tela, clicando em seu respectivo botão de exclusão. Será mostrado um aviso informando que essa operação não poderá ser desfeita, oferecendo a opção de confirmar e de cancelar, selecionando-se a opção de Confirmar o sistema exclui o procedimento de teste selecionado.

22 3.2.4 Requisitos especiais Este caso de uso não possui requisitos especiais. 3.2.5 Precondições Antes da execução deste caso de uso o sistema deverá ter executado ao menos um dos seguintes casos de uso: Manter Casos de Teste; Manter Procedimentos de Teste; Manter Relatório Resumido; Manter Checklist; Manter Atas; Manter Revisão. 3.2.6 Pós-condições Este caso de uso não possui pós-condições. 3.2.7 Pontos de Extensão Este caso de uso não possui pontos de extensão. 3.2.8 Local View Figura 3.5: Local View

23 3.2.9 Definição dos atributos Nome da variável Tipo Limitações Descrição Interface Obrigatório iddocumento Integer - Id do documento em sua respectiva tabela (chave estrangeira) tipodocumento Char 1 caracter Indica a que tipo de documento o histórico se refere. idhistorico Integer - Id do histórico - Sim - Sim data Date - Data em que foram feitas alterações Calendar Sim versão String 1 a 10 caracteres Versão corrente do teste Campo de descrição String 1 a 100 caracteres Descrição do teste feito Campo de autor String 1 a 40 caracteres Autor do teste Campo de Tabela 3.2: Definição dos Atributos texto texto texto Sim Sim Sim

24 3.2.10 Protótipo da Interface Figura 3.6: Protótipo da Interface

25 3.3 Manter Revisão 3.3.1 Descrição Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um histórico dos testes realizados em projetos de software. 3.3.2 Fluxo Básico O caso de uso é disparado pelo analista de sistemas que armazena no histórico uma ficha que está sendo persistida (de Revisão ou Checklist por exemplo). O ator preenche os dados requeridos (ver tabela na seção 8) e clica em salvar. Após isto ocorre a validação do formulário, se o formulário não for validado corretamente o sistema entrará no fluxo alternativo 2.2.2, caso contrário os dados serão persistidos na base de dados. 3.3.3 Fluxos Alternativos Alterar um histórico cadastrado: o ator pode alterar um histórico de uma revisão ou checklist já cadastrada através de uma tabela exibida na tela, clicando em seu respectivo botão de edição. Os dados deverão ser modificados, então validados e salvos. Se os dados não forem validados corretamente o fluxo irá para 2.2.2. Formulário não validado: após a não validação a página será reexibida para a correção do preenchimento do formulário. Após a correção os dados serão validados novamente. Excluir um histórico cadastrado: o ator pode excluir um histórico já cadastrado através de uma tabela exibida na tela, clicando em seu respectivo botão de exclusão. Será mostrado um aviso informando que essa operação não poderá ser desfeita, oferecendo a opção de confirmar e de cancelar, selecionando-se a opção de Confirmar o sistema exclui o procedimento de teste selecionado. 3.3.4 Requisitos especiais Este caso de uso não possui requisitos especiais.