Casos de Uso de Sistema

Finalidade É uma técnica usada para descrever e definir os requisitos funcionais de um sistema. É a especificação de seqüências de ações atender a uma funcionalidade do sistema, interagindo com seus agentes.

Finalidade É uma das maneiras mais comuns de documentar os requisitos do sistema Delimitam o Sistema; Definem a funcionalidade do sistema.

Composição É composto de: Atores; Casos de Uso (Use Cases) e; Relações entre eles. Inclui variantes, rotinas de erro, etc. que o sistema executa para produzir um resultado observável para um ator.

Atores

Atores Representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos use-cases.

<<Ator>> Atores - Notação <<Ator>> Coordenador

Identificando Atores Um Ator pode: Fornecer informações ao sistema Receber informações do sistema Fornecer e Receber informações do sistema

Identificando Atores Exemplos de perguntas que podem auxiliar a identificação dos atores: Quem esta interessado em determinada exigência? Onde na organização o sistema é usado? Quem se beneficiará do uso do sistema? Quem fornecerá ao sistema essas informações, usará essas informações e as removerá? Quem suportará e manterá o sistema? O sistema usa um recurso externo? Uma pessoa representa diversos papéis? Varias pessoas representam o mesmo papel? O sistema interage com um sistema legado?

O que identifica um bom ator? Identificar como ator encontrado interage com sistema. Verificar se atores identificados não tem papeis semelhantes.

Use cases - Casos de usos

Casos de uso - Definição Representa uma seqüência de ações executadas pelo sistema e recebe do ator que lhe utiliza, dados tangíveis de um tipo ou formato já conhecido. Ou ainda...

Caso de uso - Definição Descrição de um conjunto de seqüências de ações, incluindo variantes, que um sistema realiza para produzir um resultado observável com valor para um ator. Representa uma funcionalidade do sistema.

Caso de uso - Notação Solicitar histórico Matricular aluno Verificar pré-requisitos Servir Almoço

Caso de Uso - Exemplo Restaurante Servir almoço Cliente Servir jantar Fornecedor Restaurante Servir jantar Comprar bens

Identificação do Casos de Uso Funcionalidade identificadas no sistema que interagem com atores. Perguntas auxiliares: Quais são as tarefas de cada ator? Qualquer ator criará, armazenará, mudará, apagará ou lerá informações do sistema? Quais casos de uso realizarão essas tarefas? Qualquer ator informará ao sistema sobre mudanças externas súbitas, ou ocorrências internas? Quais serão os casos de uso que realizarão a manutenção e suporte ao sistema? Todas exigências funcionais levantadas podem ser realizadas pelos casos de uso identificados?

O que identifica um bom caso de uso? Normalmente, um comando de utilização representa uma importante peça de funcionalidade que é completa, do inicio ao fim. Um caso de uso realiza algo de valor ao ator. Casos de uso que têm o mesmo ator e usam as mesma entidades geralmente podem ser um único caso de uso.

Descrição dos casos de uso Existem 3 níveis de detalhe, de acordo com as seguintes perspectivas de um sistema: Essência / utilidade; Interface e; Implementação.

Essência / Utilidade Descrição breve independente da interface que o sistema apresenta; Descrição do objetivo ou resultado a produzir; Opcionalmente, indica lista de características e limitações (nível de requisitos).

Interface Descrição de seqüências de funcionamento normais e excepcionais (alternativos), em termos de interações dos atores com elementos da interface; Opcionalmente, acompanhar de desenhos da interface para o usuário e de diagramas dinâmicos;

Interface Indicação de quando é que o caso de uso começa e acaba, quando ocorrem interações com os atores, que objetos são trocados, quem faz o quê (o sistema ou um ator); Pode culminar no manual do usuário.

Implementação Realização do caso de uso por uma colaboração de objetos internos ao sistema; Seqüências de funcionamento detalhadas com (inter)ações internas ao sistema;

Implementação Já não compete ao analista, mais sim ao projetista/implementador; Já não faz parte do modelo de casos de uso, mas sim do modelo de design.

Estruturação dos Casos de Uso

Estruturação dos Casos de Uso Relação de extensão <<extend>>; Relação de inclusão <<include>>; Relação de generalização entre casos de uso; Relação de generalização entre atores; Agrupamento de casos de uso em pacotes.

Relação de extensão Para simplificar a descrição dos casos de utilização, podem-se organizar os casos de utilização em: Casos básicos: casos de utilização de acordo com a definição e; Extensões aos casos básicos: que traduzem partes ou modalidades acrescentadas condicionalmente.

Relação de extensão Os casos de uso “estendidos” descrevem cenários que somente ocorrerão em uma situação específica. Quando um caso de uso B estende um caso de uso A indica que o comportamento do caso de uso A pode ser aumentado com comportamento do caso de uso B. «extend» A B caso básico extensão

Relação de extensão É usado para mostrar comportamentos de exceções e casos especiais que aumentariam a quantidade de casos de uso no modelo.

Relação de extensão - Exemplo Servir uma entrada Servir jantar Servir uma sobremesa Servir à luz de velas «extend»

Relação de inclusão Quando vários casos de uso têm uma sub-sequência de funcionamento comum, é conveniente separar essa parte comum para um novo caso de uso que é incluído pelos primeiros

Relação de inclusão Uma instância do caso de uso A inclui obrigatoriamente o comportamento especificado por B; Evita-se descrever uma mesma seqüência de passos comum a vários casos de uso, concentrando essa seqüência em um caso de uso acessado pelos outros.

(parte comum a outros casos de utilização além de A) Relação de inclusão Quando um caso de uso A inclui um caso de uso B indica que o comportamento do caso de uso A reutiliza o comportamento do caso de uso B. A B (parte comum a outros casos de utilização além de A) «include»

Relação de inclusão - Exemplo Servir almoço Servir jantar Pagar refeição «include»

Casos de Uso - Generalização/Especialização Um caso de uso "filho" (mais especializado) herda o comportamento, significado e atores do caso de uso "pai" (mais genérico) O filho pode adicionar ou substituir comportamento do pai; O filho pode aparecer em qualquer contexto em que o pai pode aparecer;

Casos de Uso - Generalização/Especialização Servir uma refeição Servir almoço Servir jantar Pai Filhos

Atores - Generalização/Especialização É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização (herança). Cliente ClienteEspecial

Exemplo Completo

Agrupamento em pacotes Em um sistema complexo, podem existir muitos casos de uso para visualizar com clareza num único diagrama! Uma solução: um diagrama de casos de uso inicial, com pacotes de casos de uso, e um diagrama de casos de utilização relativo a cada pacote.

Agrupamento em pacotes «extend» Servir almoço Pagar refeição «include» Fornecedor Restaurante Servir uma refeição Servir jantar Servir à luz de velas Servir uma sobremesa Servir uma entrada Comprar bens Cliente

Agrupamento em pacotes Sist. de Gestão de Restaurantes (SGR) Garçom Relação com Fornecedores Relação com Clientes Gerente Cozinheiro

Agrupamento em pacotes SGR – Relação com Clientes Cozinheiro Elaborar menu do dia Fechar a conta Receber a conta Garçom Registar pedido Gerente

Especificação de Caso de Uso

Especificação de Caso de Uso Caso de Uso: Manter Funcionário Descrição: Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro de funcionários no sistema SISFUNC. Ator: Administrador Pré-Condição: - O ator deverá estar cadastrado no sistema com perfil de Administrador. - O funcionário deverá ter entregado toda a documentação solicitada no RH. Pós-Condição: - Cadastro do funcionário mantido no sistema. Requisitos Associados: - Gerar Folha de Pagamento.

Especificação de Caso de Uso 7. Fluxo de Eventos 7.1.Fluxo Principal P1- O caso de uso é iniciado quando o Ator acessa o sistema e seleciona a opção “Consultar Funcionário” no menu principal. P2- O ator informa o CPF do funcionário. (E1) P3- O sistema apresenta a interface “Manter Funcionário”. (A1), (A2). P4- O ator preenche os dados cadastrais do fucionário e seleciona a opção “Incluir”. (E2) P5- O sistema solicita confirmação de inclusão. P6- O ator confirma a inclusão selecionando a opção “OK”. P7- O sistema apresenta a mensagem “Operação realizada com sucesso”. P8- O caso de uso é encerrado.

Especificação de Caso de Uso 7.2.Fluxo Alternativo A.1. Alterar Funcionário. A.1.1. O ator altera os dados cadastrais desejados e seleciona a opção “Alterar”. A.1.2. O sistema solicita a confirmação da alteração. (E2) A.1.3. O ator confirma a alteração selecionando a opção “OK”. (P7) A.2. Excluir Funcionário. A.2.1. O ator seleciona a opção “Excluir”. (E3) A.2.2. O sistema solicita a confirmação da exclusão. A.2.3. O ator confirma a exclusão selecionando a opção “OK”. (P7)

Especificação de Caso de Uso 7.3.Fluxo Excessão E.1. O Sistema apresenta a mensagem “CPF inválido”. E.2. O Sistema apresenta a mensagem “Campo obrigatório não preenchido, favor verificar”. E.3. O Sistema apresenta a mensagem “Perfil não habilitado para realizar esta função”.

Especificação de Caso de Uso 8.Regras de Negócio 8.1.Regra de Aplicação -O campo CPF deverá ser composto de 11(onze) dígitos numéricos no formato (99999999999). -O campo data de nascimento é composto de 08(oito) dígitos numéricos no formato a seguir (dd/mm/aaaa). -O campo endereço é composto de 30(trinta) dígitos. -O campo telefone é composto de 10(Dez) dígitos numéricos no formato a seguir (99) 9999 9999. -O campo CEP é composto de 08(oito) dígitos numéricos no formato a seguir (99999999). -O campo perfil do funcionário é composto de 01(Um) caractere numérico.

Especificação de Caso de Uso 8.Regras de Negócio 8.1.Regra de Negócio O funcionário apenas poderá ser inativado por funcionário com perfil de Administrador. A alterção do cadastro do funcionário apenas será permitida 30 dias após a sua inclusão. O cadastro apenas poderá ser excluído 30 dias após o encerramento do aviso prévio. A exclusão do registro do funcionário deverá ocorrer apenas de forma lógica.

Especificação de Caso de Uso 8.Regras de Negócio 8.1.Regra de Negócio O funcionário apenas poderá ser inativado por funcionário com perfil de Administrador. A alterção do cadastro do funcionário apenas será permitida 30 dias após a sua inclusão. O cadastro apenas poderá ser excluído 30 dias após o encerramento do aviso prévio, conforme CLT. A exclusão do registro do funcionário deverá ocorrer apenas de forma lógica. 9. Informações Suplementares - CLT: Consolidação das Leis do Trabalho.