Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|
|
|
|
|
|
|
|
|
|
1.3 Definições, Acrônimos e Abreviações
2. Orientações Gerais do Modelo de Caso de Uso
2.2 Utilização do relacionamento <<Comunicação>>
2.3 Utilização dos relacionamentos <<Inclusão>> e <<Extensão>>.
2.3.1 Utilização do relacionamento <<Inclusão>>.
2.3.2 Utilização do relacionamento <<Extensão>>.
2.4 Utilização da Generalização de Agente
2.5 Utilização de Diagramas de Interação
2.6 Utilização de Diagramas de Atividades
3. Como Descrever um Caso de Uso
3.1.1 Cada Caso de Uso concreto estará envolvido com pelo menos um Agente
3.1.2 Nome(s) de Agentes Intuitivos e Descritivos
3.1.3 Utilização Consistente de Nome(s) de Agentes
3.3 Breve Descrição do Caso de Uso
3.4 Utilização consistente do imperativo:Will
3.5 Utilização de Termos do Glossário
3.6 Utilização de Termos de "Ação"
3.6.1 Definir onde o sistema é responsável por apresentar a Opção de Ação
3.6.2 Utilização consistente do termo em todo o Caso de Uso
3.7 Separar parágrafos para comportamento do Agente e do Sistema
3.8 Fluxos Alternativos e Sub-Fluxos
3.9 Condições Prévias e Condições Posteriores
3.10 Utilização de sinalizadores de substituição para detalhe ausente (TBD)
3.11 Definição de e Referência a Especificações Suplementares
3.12 Verificação Cruzada com Protótipo/ Design de UI
3.13 Fluxos de Exceção (Opcional)
Diretrizes de Modelagem de Caso de Uso
O objetivo deste conjunto de orientações é assegurar a consistência do Modelo de Caso de Uso. Fornece orientação em como documentar um Caso de Uso e também ajuda geral sobre tópicos relacionados freqüentemente problemáticos para Especificadores de Requisitos e Analistas de Sistemas.
Estas orientações podem ser utilizadas como estão, ou podem ser feitas sob medida, para atender as necessidades da maioria dos projetos.
Consulte Glossário do Rational Unified Process.
Nenhum
Este conjunto de orientações está organizado em duas seções, a primeira descreve nossa maneira preferida de modelar os Casos de Uso e a segunda parte fornece orientações para o conteúdo do modelo de Caso de Uso e para nomear os elementos dentro do modelo.
Os Casos de Uso serão gravados utilizando o gabarito fornecido com o Rational Unified Process, com algumas modificações de estilo e layout para se ajustar aos padrões aplicáveis de documentação do projeto.
A associação entre um Agente e um Caso de Uso é chamada de relação Comunicação. É recomendável que esta associação seja unidirecional. Utilizando esta estratégia de modelagem, nós fazemos distinção entre:
q
Agente Ativo
O Agente é considerado ativo em um par Caso de Agente-Uso quando o Agente está
iniciando (ou acionando) a execução do Caso de Uso. A seta na relação
Comunicação aponta para o
Caso de Uso.
q
Agente Passivo
O Agente é considerado passivo em um par Caso de Agente-Uso quando o Caso de Uso está
iniciando a comunicação. Agentes Passivos geralmente serão sistemas ou dispositivos
externos com os quais nosso sistema precisa se comunicar. A seta na relação
Comunicação aponta para o Agente.
Esta recomendação é feita porque a noção de agentes ativos e passivos inclui valor no leitor do modelo de Caso de Uso.
Na primeira instância, é recomendado que você evite a utilização desses relacionamentos. Esta recomendação é feita porque a utilização incorreta desses relacionamentos tem muito mais potencial para desorganizar e confundir do que para ajudar a simplificar o Modelo de Caso de Uso. A melhor opção é evitar esse tipo de decomposição inicialmente e considerar a utilização desses relacionamentos em uma etapa posterior no processo. Esses relacionamentos podem ser utilizados para:
1. Separar o comportamento que seja comum a dois ou mais casos de uso.
2. Separar o comportamento do caso de uso da base que não seja necessário para o entendimento do objetivo principal do caso de uso, apenas seu resultado é importante.
3. Mostrar que pode haver um conjunto de segmentos de comportamento dos quais um ou vários podem ser inseridos em um ponto de extensão em um caso de uso da base.
Mas, eles devem ser utilizados apenas onde incluem valor ajudando a simplificar e gerenciar o modelo de caso de uso.
A relação de inclusão descreve um segmento de comportamento que é inserido em uma instância de caso de uso que está executando o caso de uso da base. É um mecanismo semelhante, em natureza, a uma sub-rotina e é mais freqüentemente utilizado para separar comportamento comum.
Consulte as orientações para relações de inclusão no Rational Unified Process para obter detalhes adicionais.
A relação de extensão é um relacionamento mais difícil de aproveitar, principalmente porque o caso de uso de extensão não é conhecido pelo caso de uso da base. Como comentário geral, há poucos lugares em que esse relacionamento é útil na maioria dos sistemas de negócios. Tenha em mente, porém, que sempre há exceções às regras e que este mecanismo pode ser útil em determinadas circunstâncias.
Consulte as orientações para relações de extensão no Rational Unified Process para obter detalhes adicionais:
No geral, a Generalização de Agente pode ser utilizada para definir melhor as diferentes funções exercidas pelos usuários do sistema a ser desenvolvido. Isto é útil em aplicativos com diferentes "categorias" de usuários finais. Dessa maneira, apenas a funcionalidade relevante será apresentada a cada categoria de usuários e nós conseguiremos controlar os direitos de acesso com base nesse agrupamento.
Regra prática : Cada caso de uso será iniciado apenas por um Agente. Esta "regra" pode ser substituída, neste caso a descrição do caso de uso deve justificar a decisão.
Exemplo do Domínio de Negócios da Universidade:
Librarian e Professor são exemplos de duas funções (agentes) existentes no
Domínio da Universidade. Essas funções têm algumas tarefas comuns e algumas tarefas que
são exclusivas de sua função nos Negócios. A maneira preferida de modelar isto é
mostrada abaixo.
Consulte as orientações: Generalização de Agente no Rational Unified Process para obter detalhes adicionais.
Em alguns casos, é bom incluir - além do fluxo textual de eventos - um diagrama de Interação para ilustrar o fluxo de eventos de "alto nível" do caso de uso. É recomendável que você faça um diagrama de seqüência para isto no Rational Rose. Inclua apenas a comunicação entre os agentes e os objetos de limite (abrangendo as mensagens de entrada e as de saída) e trate o sistema como uma caixa preta. Utilize objetos de limite com nomes lógicos conforme definido no fluxo de eventos do caso de uso, sem designá-los a classes neste ponto.
Não é necessário que cada caso de uso tenha um diagrama de interação correspondente: É um produto de trabalho opcional.
Onde um diagrama de atividades inclui valor ao ajudar a definir, explicar e concluir o fluxo de eventos no caso de uso, é recomendável que estes sejam modelados no Rational Rose. Uma boa regra prática é considerar Diagramas de Atividades para casos de uso complexos (contendo vários fluxos alternativos e /ou excepcionais). O diagrama de atividades mostra uma árvore de decisão dos fluxos no caso de uso.
Não é necessário que cada caso de uso tenha um diagrama de atividades correspondente: É um produto de trabalho opcional.
Para obter informações gerais e orientações adicionais sobre Casos de Uso , consulte o Rational Unified Process.
Para obter informações gerais e orientações adicionais sobre Agentes , consulte o Rational Unified Process.
Cada caso de uso concreto está envolvido com pelo menos um agente? Se não estiver, há algo errado; um caso de uso que não interage com um agente é supérfluo e você irá removê-lo ou identificar o agente correspondente.
Em alguns casos, mais de um agente pode participar na interação do caso de uso. Certifique-se de que a utilização de vários agentes em um caso de uso seja válida (consulte Generalização de Agente).
Os agentes têm nomes intuitivos e descritivos? Tanto os usuários quanto os clientes entendem os nomes? É importante que os nomes dos agentes correspondam a suas funções. Se não corresponderem, altere-os.
Você deve consultar o Modelo de Caso de Uso para se certificar de que esteja utilizando o nome de agente correto para cada agente em seu caso de uso.
A especificação do caso de uso será gravada utilizando nome(s) de agentes de forma consistente. Tenha cuidado para garantir que a nomenclatura do agente seja clara e não ambígua.
Não se refira genericamente ao "agente"; em vez disso, utilize o nome real utilizado para identificar ou definir exclusivamente o agente. O nome do agente pode ser pensado como a função sendo executada em um conjunto de interações do sistema.
O nome do caso de uso será exclusivo, intuitivo e explicativo para que defina de forma clara e não ambígua o resultado observável de valor obtido do caso de uso.
Uma boa verificação para o nome do caso de uso é pesquisar se clientes, representantes de negócios, analistas e desenvolvedores entendem os nomes e as descrições dos casos de uso. Lembre-se: Você está definindo um resultado observável de valor da perspectiva dos agentes.
Cada nome de caso de uso descreverá o comportamento que o caso de uso suporta. O nome combinará a ação que está sendo executada e o elemento chave que está sendo "acionado". Com mais freqüência, esta será uma simples combinação Verbo/ Nome. O caso de uso deve ser nomeado da perspectiva do agente que aciona o caso de uso. Os exemplos incluem: "Inscrever-se em um curso", "Selecionar um curso a ensinar".
O caso de uso conterá uma breve descrição. Esta descrição terá pelo menos 1 parágrafo e não mais de 3 parágrafos de extensão. A descrição abrangerá uma explicação do objetivo chave, a proposição do valor e conceitos do caso de uso.
Onde inclui valor, um breve exemplo "story" pode ser incluído com a breve descrição que ajuda a fornecer contexto adicional. Este exemplo, geralmente, seguirá o Fluxo Básico e, onde for útil, incluirá valores de dados.
Requisitos do sistema dentro dos casos de uso serão gravados utilizando o imperativo. O termo "Will" foi escolhido em favor de "Shall" e "Must" para descrever os requisitos de forma consistente. A utilização de termos passivos que implicam o requisito é opcional ou indefinida como "should", "possibly", "etc", "might" ou "may" serão evitados.
Todos os Termos de Negócios em um caso de uso serão definidos no Glossário do projeto. Se existir um Termo de Negócios em um caso de uso que não exista no glossário, o termo precisará:
1. Ser incluído no glossário, incluindo uma breve descrição (máx. de um parágrafo).
2. Ser alterado no caso de uso para refletir o Termo de Negócios correto definido no glossário.
O caso de uso determinará explicitamente onde o sistema é responsável por apresentar uma ação como uma opção disponível para o agente selecionar. Na maioria dos casos, as opções disponíveis devem ser apresentadas como parte do fluxo básico e ser referidas como o ponto de entrada na primeira instrução no fluxo alternativo correspondente.
A utilização de termos como New, Modify, Cancel, Delete, OK e Print será consistente em todo o caso de uso: A mesma ação lógica não será mencionada utilizando terminologia diferente. Deverá ser tomado um cuidado especial para garantir que os Termos de Ação utilizados nos Fluxos Alternativos correspondam àqueles utilizados no fluxo básico.
Toda vez que a interação entre o agente e o sistema alterar o foco (entre o agente e o sistema), o próximo segmento de comportamento iniciará com um novo parágrafo. Inicie, primeiro, com um agente e, em seguida, com o sistema.
A sentença deve começar com 'O <nome-do-agente> irá xxxxx' ou 'O sistema irá xxxx'. Sempre informe o nome do agente corretamente, por extenso, em vez de qualquer abreviação.
Cada Fluxo Alternativo e Sub-Fluxo irá definir de forma explícita e clara todos os pontos de entrada possíveis no fluxo e concluirá com todos os pontos de saída possíveis do fluxo.
O fluxo alternativo também informará explicitamente o ponto de saída e onde o agente continua com o próximo - se está retornando a uma etapa específica no fluxo básico ou encerrando.
Onde o fluxo de eventos se torna confuso devido ao comportamento complexo ou onde um único fluxo excede uma página física impressa no comprimento, os sub-fluxos podem ser utilizados para aprimorar a clareza e gerenciar a complexidade. Os sub-fluxos serão gravados movendo um grupo independente, lógico de comportamento detalhado para um sub-fluxo e mencionando esse comportamento no formulário de resumo dentro do fluxo de eventos.
A especificação do caso de uso incluirá um conjunto de condições (também mencionadas como premissas) que supõe-se que sejam verdadeiras antes que o caso de uso seja iniciado (condições prévias) e depois que o caso de uso for encerrado (pós-condições). Observe que o caso de uso pode ser encerrado de várias maneiras e cada "pós-condição" deve ser descrita de acordo.
Onde as informações ainda não estão definidas ou decididas, o caso de uso incluirá uma referência ao problema ou elemento e incluirá o sinalizador de substituição: TBD.
Onde há requisitos adicionais que não podem ser descritos naturalmente durante o fluxo de eventos, eles serão definidos como requisitos suplementares. Aqueles que são específicos de um caso de uso serão definidos na seção Requisitos Especiais da especificação do caso de uso.
Aqueles requisitos que são aplicáveis a todo o sistema, especialmente aqueles de natureza não-funcional, serão definidos em um ou mais documentos de especificação suplementares separados.
Os exemplos incluem:
Confiabilidade: - O sistema deve estar disponível 24 x 7.
- O sistema deve ser executado por 48 h MTBF.
Desempenho: - O sistema deve fornecer uma resposta on-line que não exceda 5 segundos sob as condições de carregamento normais esperadas.
O conteúdo do caso de uso terá verificação cruzada contra o Protótipo/ Design de UI para garantir que nenhum requisito do sistema esteja faltando no caso de uso ou no Protótipo/ Design de UI. As alterações serão acionadas onde forem requeridas para o caso de uso: As alterações no Protótipo de UI serão anotadas como uma discussão para ação futura.
As orientações a seguir são fornecidas para ajudar na descoberta de Fluxos de Exceção:
Para cada etapa no caso de uso, considere o que pode dar errado. Cada exceção exclusiva pode ser capturada como um Fluxo de Exceção. Em alguns casos, um único Fluxo de Exceção será utilizado comumente no caso de uso, por exemplo "Timeout". As informações chave a serem capturadas são o que é o requisito de negócios quando ocorre a exceção, isto é, qual deve ser a experiência dos agentes?