Esse guia define um conjunto de diretrizes para inspeção dos artefatos necessários para realização de um caso de uso. Os artefatos estão subdivididos de acordo com as etapa com a qual ele se relaciona durante o desenvolvimento do caso de uso. Lembrando que essas etapas são consideradas padrões, podendo ser configuradas, alteradas e, até mesmo, novas etapas serem inseridas, de modo a refletir a realidade do projeto.

Especificação Inicial

Durante a análise do progresso da etapa de especificação inicial dentro do RUP, foram identificados quatro artefatos relacionados à sua realização. Nesse momento, a preocupação é identificar o caso de uso e certificar que o mesmo apresenta uma descrição inicial, contendo a descrição das funcionalidades e eventos relacionados ao caso de uso. Os itens abaixo descrevem como verificar se esses artefatos realmente representam a descrição inicial do caso de uso:

Diagrama de Caso de Uso

Basicamente, deve-se verificar se o caso de uso está inserido no diagrama de caso de uso, com as relações com outros casos de uso e atores definidas. Em caso positivo temos que , caso contrário , onde DCU indica o Diagrama de Caso de Uso e uc o caso de uso que está sendo avaliado.

Descrição Funcional

Visa identificar se está definida, no documento de requisitos, uma seção específica para o caso de uso, contendo os principais itens da descrição funcional do caso de uso. Dentre estes itens temos: a descrição detalhada do caso de uso, as entradas permitidas pelo caso de uso, as saídas esperadas, pré-requisitos e pós-requisitos relativos à execução do caso de uso. Para cada item citado, atribuí-se o valor 1 caso o mesmo já tenha sido documentado, caso contrário, atribuí-se o valor 0. O resultado da inspeção da descrição funcional se dá através da fórmula

onde é a função que retorna se o item x foi ou não desenvolvido para realização do caso de uso uc, e é o conjunto de itens que devem estar contidos na descrição funcional do caso de uso.

Fluxo de Eventos

Deverá ser verificado se o fluxo de eventos do caso uso está documentado. É importante observar se o fluxo principal foi definido, se fluxos alternativos e subfluxos são necessários, e se eles estão, ou não, documentados. Atribui-se o valor 1 para os itens desenvolvidos e 0 para os que ainda precisam ser feitos. O resultado da avaliação do fluxo de eventos se dá através da fórmula

onde é a função que retorna se foi ou não desenvolvido para realização do caso de uso uc, e é o conjunto de itens (fluxo principal, fluxo alternativo, subfluxos) que devem ser inspecionados durante a avaliação dos fluxos relacionados ao caso de uso.

Protótipo de Interface

Se houver necessidade de incorporar as funcionalidades do caso de uso em um protótipo inicial, temos que deverá ser verificado se cenários de uso foram definidos, se o projeto de interface do caso de uso foi realizado e se o protótipo contém as interfaces que representarão a funcionalidade do caso de uso. Para cada resposta positiva, temos que deverá ser atribuído o valor 1, em caso negativo será atribuído o valor 0. O resultado da avaliação do protótipo de interface se dá através da fórmula

onde é a função que retorna se x foi ou não desenvolvido para realização do caso de uso uc, e Itens do Protótipo de Interface é o conjunto de itens que devem ser desenvolvidos durante a definição e implementação de um protótipo de interface.

Análise e Projeto

Durante a análise do progresso da etapa de análise e projeto do caso de uso, é necessário avaliar os diversos diagramas UML relacionados à realização da modelagem do caso de uso: diagramas de interação (sequência/colaboração), diagrama de classe, diagrama de atividade (se necessário), diagrama de estado (se necessário). O diagrama de componentes não é considerado nessa etapa, pois se relaciona com a implementação do caso de uso. Além disso, o diagrama de implantação não representa um progresso significativo em relação às funcionalidades que o sistema deve possuir.

Diagrama de Interação

Este tipo de diagrama tem como objetivo mostrar o comportamento dos vários objetos relacionados, durante a realização do caso de uso. Ele é classificado em dois tipos de diagramas, de acordo com o foco que ele demonstra: diagrama de Sequência (foco na sequência das mensagens trocadas entre os objetos) e diagrama de Colaboração (foco no comportamento de cada objeto dentro do caso de uso). Ambos os diagramas representam os aspectos dinâmicos relativos à modelagem do caso de uso, indicando as interações dos usuários com o sistema, e a troca de mensagens entre as diversas classes relacionadas ao caso de uso para produzir o resultado desejado [8]. A inspeção da existência de um diagrama de sequência e/ou colaboração relacionado ao caso de uso, obedece aos seguintes critérios:

• Deve haver um rastreamento direto entre o caso de uso e o diagrama de interação, ou seja, o diagrama de interação deve pertencer à realização do caso de uso, ou estar imediatamente abaixo do caso de uso na hierarquia do projeto (caso se esteja utilizando alguma ferramenta que permita esse tipo de ligação, ex.: Rational Rose).
• O diagrama deve possuir o mesmo nome de identificação do caso de uso.
• Deve representar as diversas classes de análise envolvidas com a realização do caso de uso e que modelam o comportamento do mesmo.
• Deve representar as classes de controle que monitoram as classes de análise, de forma a obter os resultados desejados.
• Deve conter mensagens que permitem realizar os fluxos de eventos descritos para o caso de uso.

Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Diagrama de Classe

Esse diagrama representa a estrutura das diversas classes relacionadas à realização do caso de uso, indicando também os relacionamentos entre tais classes [8]. A inspeção desse diagrama, visando identificar as diversas classes necessárias para realização do caso de uso, obedece os seguintes critérios:

• Caso o desenvolvimento seja suportado por alguma ferramenta de modelagem, que permita o rastreamento dos diversos diagramas UML, relacionados com a realização de um caso de uso (Ex.: Rational Rose), basta identificar se existe algum diagrama de classes relacionado à realização do caso de uso. Caso não exista esse rastreamento direto, deverá ser observado o diagrama de classes global, que pode incorporar nele, as classes relacionadas com o caso de uso.
• As classes de análise definidas no diagrama de interação devem estar representadas no diagrama de classes contendo: atributos (possíveis parâmetros passados nas mensagens do diagrama de interação, ou ainda atributos relativos a análise do caso de uso), métodos (correspondem as mensagens trocadas nos diagramas de interação e métodos de acesso aos atributos do sistema) e relacionamentos com outras classes (resultantes do comportamento da classe para atingir a funcionalidade do caso de uso).
• As classes de controle definidas no diagrama de sequencia do caso de uso, devem estar representadas no diagrama de classes, contendo os atributos e métodos (mensagens que ela envia) necessários, para controlar a execução do caso de uso.
• As classes de fronteira relacionadas com a prototipação do caso de uso, devem estar representadas no diagrama de classe, contendo atributos, métodos relevantes e relacionamentos com outras classes bem definidos.

Uma observação importante relacionada com a inspeção desse diagrama é que, a localização de uma classe em um pacote ou subsistema, não afeta o progresso funcional do sistema, pois ela continua com as mesmas propriedades, e realizando as mesmas operações. Tem-se também que, as classes podem ser alteradas de modo a adquirir novas funcionalidades relevantes a outros casos de uso. Caso todos critérios, acima definidos, sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Diagrama de Estado

Consiste em uma máquina de estado, contendo estados, transições, eventos e atividades. Endereça a visão dinâmica do sistema. Importante para modelar um objeto com comportamento dinâmico, enfatizando os eventos que resultam em mudança de estado para o objeto.

Quando necessário, ou seja, quando o caso de uso possuir algum objeto relacionado, que contém a necessidade de uma modelagem dos seus diversos estados durante a realização do caso de uso, temos que os seguintes critérios devem ser obedecidos:

• Caso exista a ferramenta de modelagem que permita manter o relacionamento do caso de uso com sua realização, basta identificar, para os objetos que necessitam, se existe o diagrama de estado correspondente.
• Deve existir um diagrama de estado, para cada objeto relativo ao caso de uso, que necessite de uma modelagem dos seus estados, ou seja, apresente um comportamento bastante dinâmico, derivado da realização do caso de uso.
• Alguns desses estados devem representar o comportamento do objeto no caso de uso, ou seja, estados oriundos da realização do caso de uso.

Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Diagrama de Atividade

Tipo especial de diagrama de estado, que mostra um fluxo de atividades dentro do sistema. Endereça a visão dinâmica do sistema. Importante para modelagem de uma função de um sistema, focalizando o fluxo de controle entre objetos. Quando necessário, ou seja, quando o caso de uso possuir um objeto com alguma operação complexa que necessite ser modelada, temos que os seguintes critérios devem ser observados:

• Caso exista a ferramenta de modelagem que permita manter o relacionamento do caso de uso com sua realização, basta identificar se existe o diagrama de atividade correspondente à realização de alguma operação complexa dentro do caso de uso, ou se não há necessidade de representar esse diagrama para nenhuma operação, oriunda das funcionalidades do caso de uso.
• Quando houver necessidade, a sequência de atividades para realização de uma determinada operação, envolvida com o caso de uso, deve estar modelada em um diagrama de atividade

Caso esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Implementação

Verifica se o diagrama de componentes do sistema, contém as classes derivadas do caso de uso, observa se as classes definidas foram codificadas, se testes de unidade sobre essas classes já foram realizadas e se a versão executável do sistema (se houver) disponibiliza para uso, as funcionalidades previstas no caso de uso. Abaixo seguem os critérios de avaliação da realização dos artefatos relacionados, para um determinado caso de uso.

Diagrama de Componente

• Deve haver um mapeamento direto das classes derivadas do caso de uso com os componentes existentes no diagrama de componentes
• Bibliotecas de interface, classes de fronteira e comunicação devem estar representadas

  Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Código Fonte

• Visa identificar se as classes derivadas do caso de uso foram implementadas com as funcionalidades (atributos e métodos) definidas durante a realização da análise e projeto do caso de uso

  Caso o critério acima seja avaliado positivamente, temos que , caso contrário, onde uc é o caso de uso em avaliação.

Teste de Unidade

• Representa a porcentagem de classes derivadas do caso de uso que já realizaram seus testes de unidade, ou seja

Interface

• Verifica se as funcionalidades definidas pelo caso de uso estão disponíveis para uso na interface do sistema

  Caso o critério acima seja avaliado positivamente, temos que , caso contrário, onde uc é o caso de uso em avaliação.

Teste

Consiste em inspecionar se o caso de uso está integrado ao sistema, de modo que, testes de sistema foram planejados, projetados, scripts de teste foram implementados e executados, verificando também a porcentagem de testes que foram realizados com sucesso.

Plano de Teste

• Consiste em verificar se os casos de teste para o caso de uso foram identificados e agrupados
• Se os riscos inerentes foram levantados
• Se estratégias de teste foram definidas
• Se os critérios de avaliação foram estabelecidos
• Se os recursos de teste foram identificados e o cronograma de teste já foi detalhado e documentado

  Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Projeto de Teste

• Verifica se os casos de teste identificados foram descritos
• Se os procedimentos de teste foram estruturados
• Se métricas de avaliação dos testes foram descritas

  Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Implementação do Teste

• Verifica se os scripts de teste dos casos de teste anteriormente identificados foram gravados ou programados
• Se o conjunto de dados externos (necessários para os testes) foram criados e mantidos
• Se os pacotes e classes de teste relativos aos casos de teste envolvidos foram projetados e implementados.

  Caso todos esses critérios sejam avaliados positivamente, temos que , caso contrário , onde uc é o caso de uso em avaliação.

Execução do Teste

• Indica a porcentagem dos casos de teste sobre o caso de uso que foram realizados com sucesso, ou seja, a porcentagem dos casos de teste cujas métricas de avaliação definidas no plano de teste indicaram uma realização satisfatória. Desse modo, temos que