Agora chegou a hora de avaliar melhor, explicar a fundo e PRATICAR, afinal, só conseguimos aprender direito se treinarmos certo?
Hoje vamos falar a fundo sobre o Diagrama de Casos de Uso para alguns desenvolvedores, "engenheiros" e funções o caso de uso é tão genérico que fazer caso de uso é perda de tempo mas não é verdade o caso de uso apesar de genérico é uma "bússola" para entender o sistema.
O diagrama de Casos de Uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais fléxivel e informal. Ele costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e Análise de Requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas.
Por mais abstrato que seja ele é de grande ajuda para auxiliar o engenheiro de software a dar um ‘rumo’ ao sistema.
Veja o nosso pequeno exemplo que mostra um caso de uso da funcionalidade de administrar novidades de um sistema:
Este diagrama tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar com como essas funções serão implementadas. O Diagrama de Casos de Uso é de grande auxílio na etapa de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características, funções e serviços do sistema desejados pelo usuário. O Diagrama de Casos de Uso tenta identificar os tipos de usuários que irão interagir com o sistema, quais papéis esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico.
Por utilizar uma linguagem informal e apresentar uma visão geral do comportamento do sistema a ser desenvolvido, o Diagrama de Casos de Uso pode e deve ser apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o comportamento do sistema, facilitar a compreensão dos usuários e auxiliar na identificação de possíveis falhas de especificação é recomendado que junto com o caso de uso o cliente tenha acesso a um protótipo para que assim um complemente o outro.
Atores
O Diagrama de Casos de Uso concentra-se em dois itens principais: Atores e Casos de Uso. Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema; eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Resumindo tudo isso que falei um Ator pode ser qualquer elemento externo que interaja com o sistema.
Os atores são representado por símbolos de bonecos que eu sei desenhar, é eu sei desenhar apenas aqueles bonequinhos de pauzinho sabe? Então, esses são os atores, em alguns livros e artigos os chamam de “bonecos magros” mas da na mesma pois pra mim são uns alienígenas veto rizados, rsrs.
E os casos de uso que refere-se aos serviços, tarefas ou funções que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório, cadastrar a venda de um produto qualquer, administrar usuários, emitir boleto bancário e etc... Os casos de uso são utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.
Não existe regra para definir ao que se refere exatamente um caso de uso por exemplo, posso fazer um caso de uso que represente uma tela do sistema, ou uma ação especifica do usuário ou ainda várias ações, o indicado é criar algo que fique claro as funções do sistema por exemplo, veja esse diagrama de caso de uso para um modulo de novidades
Um usuário com uma ação “administra novidades” e nessa função existem várias ações. Para reforçar melhor a idéia do caso de uso ele basicamente oferece instruções gerais de como será seu funcionamento, quais atividades deverão ser executadas, qual eventos forçará sua execução, quais Atores os poderão utilizar, quais suas possíveis restrições entre outras.
Documentação de Casos de Uso
A documentação de um Caso de Uso costuma descrever por meio de uma linguagem bastante simples, a função em linhas gerais do Caso de Uso, quais Atores interagem com o mesmo, quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir.
No entanto, não existe um formato específico de documentação para Casos de Uso definido pela UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de documentação de um Caso de Uso é bastante flexível, permitindo que se documente o caso de Uso da forma que se considerar melhor, até mesmo através do uso de pseudo-código ou da utilização do código de alguma linguagem de programação propriamente dita, embora isto fuja bastante do objetivo principal do Diagrama de Casos de Uso, que é utilizar uma linguagem simples que até mesmo usuários leigos possam entendê-la.
Por esse motivo não é recomendado utilizar pseudo-código na documentação de Casos de Uso, isto é mais adequado em outros diagramas como o Diagrama de Atividades, por exemplo.
Vamos mostrar um breve exemplo de Documentação de Caso de Uso do administrar novidades OK? Apenas para inserir novidade.
Documentação do Caso de Uso Inserir novidade
A documentação em si parece ser bem simples mas devemos prestar atenção na parte que mostra Caso de Uso Geral e colocamos como valor Administrar novidades, isso acontece pq esse caso de uso é o Insere novidades que fica abaixo do Administrar novidades (veja na imagem), esse é chamado de caso de uso especializado que herda as características do Caso de uso geral.
O campo ator principal identifica o ator que mais interage com o Caso de Uso ou que está mais interessado nos resultados produzidos pelo mesmo. Ainda existe o Ator secundário que são aqueles que interagem em um nível menor com o Caso de Uso ou que não tem tanto interesse em seus resultados.Existe também o Resumo que apresenta um breve resumo explicando seu objetivo. Em seguida são descritas as possíveis pré-condições para que o Caso de Uso seja executado ou concluído, existe tambem as pós-condições, ou seja, tarefas que devem ser realizar depois que as etapas do Caso de Uso tiverem sido concluídas. Na documentação deste Caso de Uso as ações tomadas pelo Ator Usuario aparecem no lado esquerdo e as do sistema no lado direito. Em seguida, a documentação apresenta as ações realizadas quando o serviço representado pelo Caso de Uso for solicitado. As ações são divididas em ações realizadas pelo Ator que interage com o sistema e em ações realizadas pelo próprio sistema, numeradas em ordem sequencial. Finalmente é apresentada uam lista de possíveis restrições e validações do Caso de Uso, com o objetivo de tornar o processo mais consistente.
Alguns autores sugerem ainda o acréscimo de FLuxos Alternativos ou Cenários Alternativos, como uma maneira de prever ações que devem ser realizadas quando da ocorrência de possíveis exceções. Nestes casos deve-se determinar o FLuxo ou Cenário Principal que será normalmente executado e cada um dos possíveis fluxos ou cenários alternativos, dependendo do número de exceções que possam vir a ocorrer no Caso de Uso em questão.
Associações
As associações representam as interações ou relacionamentos entre os Atores que fazem parte do diagrama, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Os relacionamentos entre casos de uso recebem nomes especiais, como Inclusão, Extensão e Generalização. Todos esses relacionamento serão examinados aqui.
A associação entre um Ator e um Caso de Uso é representada por uma reta ligando o Ator ao Caso de Uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade de Associação, o que demonstra o sentido em que as informações trafegam, ou seja, se estas são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (neste ultimo caso a reta não possue setas demonstrando que as informações são transmitidas nas duas direções). Além disso uma associação pode possuir uma descrição própria, quando há necessidade de esclarecer a natureza da informação que está sendo transmitida, ou para das um nome à Associação, se isto for considerado necessário.
A imagem abaixo representa uma Associação entre um Ator e um Caso de Uso;
Examinando essa associação percebemos que o Ator Cliente utiliza, de alguma forma, o serviço Abertura de Conta, representado pelo Caso de Uso e que a informação referente a este processo trafega nas duas direções.
Especialização/Generalização
O relacionamento de Especialização/Generalização é uma forma de Associação entre Casos de Uso no qual existem dois o mais Casos de Uso com características semelhantes, apresentando pequenas diferenças entre si. Quando isso acontece definimos um Caso de Uso Geral que descreve as características compartilhadas por todos os Casos de Uso em questão e então relacioná-lo com os outros casos de uso envolvidos.
A associação de Generalização/Especialização é representada por uma reta com uma seta mais grossa, que indica qual o Caso de Uso Feral (para o qual a seta aponta) e quais os Casos de Uso Especializados(os que estão na outra extremidade da seta) veja um exemplo abaixo;
Embora não seja comum a especialização pode ser aplicada a atores tambem e funciona da mesma forma.
Inclusão
A Associação de Inclusão costuma ser utilizada quando existe um serviço, situação ou torina comum a mais de um Caso de Uso. Quando isso acontece, a documentação dessa rotina é mcolocada em um Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma sequência de passos em vários Casos de Uso. Uma inclusão em um caso de uso comporta-se da mesma forma que uma chamada de função na programação. Uma associação de inmclusão é representada por uma reta tracejada contendo uma seta em uma de suas extremidades que aponta para o Caso de Uso incluído no caso de uso posicionado na outra extremidade da reta. As associações de inclusão costumam apresentar também um EStereótopo contendo o texto “include”, entre dois sinais de menor (<) e dois de maior (>). Os Estereotipos serão melhor detalhados em breve. Veja um exemplo de inclusão abaixo;
Nessa imagem percebemos que feito qualquer ação (Saque ou depósito) é necessário registrar o movimento.
Extensão
Associação de Extensão são utilizadas para descrever cenários opcionais de um Caso de Uso. Os Casos de uso estendidos descrevem cenários que somente ocorrerão em uma situação específica, se uma determinada condição for satisfeita.
As associações de Extensão indicam a necessidade de um teste para determinar se é necessário executar também o Caso de Uso estendido ou não. Relacionamentos de Extensão representam eventos que não ocorrem sempre, o que não significa que eles sejam incomuns. As associações de Extensão possuem uma representação semelhante a de inclusão, utilizando também a reta tracejada diferenciando-se pelo fato da seta apontar para o Caso de Uso que utiliza o Caso de Uso estendido e por possuir um Estereótipo contendo o texto “extend” ao invés de “include” a imagem abaixo representa muito bem uma extensão:
O certo no banco é que quando vc va cancelar a conta fique com saldo igual a zero ou seja, não esteja nem devendo para o banco e também não tenha dinheiro, então para encerrar a conta é necessário se o saldo positivo sacar o dinheiro e se negativo “pagar” depositar dinheiro.
Hoje vamos falar a fundo sobre o Diagrama de Casos de Uso para alguns desenvolvedores, "engenheiros" e funções o caso de uso é tão genérico que fazer caso de uso é perda de tempo mas não é verdade o caso de uso apesar de genérico é uma "bússola" para entender o sistema.
O diagrama de Casos de Uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais fléxivel e informal. Ele costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e Análise de Requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas.
Por mais abstrato que seja ele é de grande ajuda para auxiliar o engenheiro de software a dar um ‘rumo’ ao sistema.
Veja o nosso pequeno exemplo que mostra um caso de uso da funcionalidade de administrar novidades de um sistema:
Este diagrama tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar com como essas funções serão implementadas. O Diagrama de Casos de Uso é de grande auxílio na etapa de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características, funções e serviços do sistema desejados pelo usuário. O Diagrama de Casos de Uso tenta identificar os tipos de usuários que irão interagir com o sistema, quais papéis esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico.
Por utilizar uma linguagem informal e apresentar uma visão geral do comportamento do sistema a ser desenvolvido, o Diagrama de Casos de Uso pode e deve ser apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o comportamento do sistema, facilitar a compreensão dos usuários e auxiliar na identificação de possíveis falhas de especificação é recomendado que junto com o caso de uso o cliente tenha acesso a um protótipo para que assim um complemente o outro.
Atores
O Diagrama de Casos de Uso concentra-se em dois itens principais: Atores e Casos de Uso. Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema; eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Resumindo tudo isso que falei um Ator pode ser qualquer elemento externo que interaja com o sistema.
Os atores são representado por símbolos de bonecos que eu sei desenhar, é eu sei desenhar apenas aqueles bonequinhos de pauzinho sabe? Então, esses são os atores, em alguns livros e artigos os chamam de “bonecos magros” mas da na mesma pois pra mim são uns alienígenas veto rizados, rsrs.
E os casos de uso que refere-se aos serviços, tarefas ou funções que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório, cadastrar a venda de um produto qualquer, administrar usuários, emitir boleto bancário e etc... Os casos de uso são utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.
Não existe regra para definir ao que se refere exatamente um caso de uso por exemplo, posso fazer um caso de uso que represente uma tela do sistema, ou uma ação especifica do usuário ou ainda várias ações, o indicado é criar algo que fique claro as funções do sistema por exemplo, veja esse diagrama de caso de uso para um modulo de novidades
Um usuário com uma ação “administra novidades” e nessa função existem várias ações. Para reforçar melhor a idéia do caso de uso ele basicamente oferece instruções gerais de como será seu funcionamento, quais atividades deverão ser executadas, qual eventos forçará sua execução, quais Atores os poderão utilizar, quais suas possíveis restrições entre outras.
Documentação de Casos de Uso
A documentação de um Caso de Uso costuma descrever por meio de uma linguagem bastante simples, a função em linhas gerais do Caso de Uso, quais Atores interagem com o mesmo, quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir.
No entanto, não existe um formato específico de documentação para Casos de Uso definido pela UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de documentação de um Caso de Uso é bastante flexível, permitindo que se documente o caso de Uso da forma que se considerar melhor, até mesmo através do uso de pseudo-código ou da utilização do código de alguma linguagem de programação propriamente dita, embora isto fuja bastante do objetivo principal do Diagrama de Casos de Uso, que é utilizar uma linguagem simples que até mesmo usuários leigos possam entendê-la.
Por esse motivo não é recomendado utilizar pseudo-código na documentação de Casos de Uso, isto é mais adequado em outros diagramas como o Diagrama de Atividades, por exemplo.
Vamos mostrar um breve exemplo de Documentação de Caso de Uso do administrar novidades OK? Apenas para inserir novidade.
Documentação do Caso de Uso Inserir novidade
| Nome do Caso de Uso | Inserir novidade |
| Caso de Uso Geral | Administar novidades |
| Ator principal | Usuario |
| Resumo | Este caso de uso descreve as etapas percorridas por um usuario para inserir uma novidade |
| Pré-condições | Ser um usuario do sistema com permissão para utilizar esse modulo |
| Ações do Ator | Ações do sistema |
| 1. Preencher campos | |
| 2. Receber dados de novidade | |
| 3. Validar campos | |
| 4. tratar imagem | |
| 6. definir tempo de transição dos slides | |
| 7. Verificar se tempo é valido e registrar | |
| Restrições/Validações | 1. A imagem inserida deve ter extensão jpg, gif ou png. 2. Titulo e descrição são obrigatórios 3. Titulo deve ter no máximo 90 caracteres 4. Descrição deve ter no máximo 160 caracteres 5. Não permitir tags html |
A documentação em si parece ser bem simples mas devemos prestar atenção na parte que mostra Caso de Uso Geral e colocamos como valor Administrar novidades, isso acontece pq esse caso de uso é o Insere novidades que fica abaixo do Administrar novidades (veja na imagem), esse é chamado de caso de uso especializado que herda as características do Caso de uso geral.
O campo ator principal identifica o ator que mais interage com o Caso de Uso ou que está mais interessado nos resultados produzidos pelo mesmo. Ainda existe o Ator secundário que são aqueles que interagem em um nível menor com o Caso de Uso ou que não tem tanto interesse em seus resultados.Existe também o Resumo que apresenta um breve resumo explicando seu objetivo. Em seguida são descritas as possíveis pré-condições para que o Caso de Uso seja executado ou concluído, existe tambem as pós-condições, ou seja, tarefas que devem ser realizar depois que as etapas do Caso de Uso tiverem sido concluídas. Na documentação deste Caso de Uso as ações tomadas pelo Ator Usuario aparecem no lado esquerdo e as do sistema no lado direito. Em seguida, a documentação apresenta as ações realizadas quando o serviço representado pelo Caso de Uso for solicitado. As ações são divididas em ações realizadas pelo Ator que interage com o sistema e em ações realizadas pelo próprio sistema, numeradas em ordem sequencial. Finalmente é apresentada uam lista de possíveis restrições e validações do Caso de Uso, com o objetivo de tornar o processo mais consistente.
Alguns autores sugerem ainda o acréscimo de FLuxos Alternativos ou Cenários Alternativos, como uma maneira de prever ações que devem ser realizadas quando da ocorrência de possíveis exceções. Nestes casos deve-se determinar o FLuxo ou Cenário Principal que será normalmente executado e cada um dos possíveis fluxos ou cenários alternativos, dependendo do número de exceções que possam vir a ocorrer no Caso de Uso em questão.
Associações
As associações representam as interações ou relacionamentos entre os Atores que fazem parte do diagrama, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Os relacionamentos entre casos de uso recebem nomes especiais, como Inclusão, Extensão e Generalização. Todos esses relacionamento serão examinados aqui.
A associação entre um Ator e um Caso de Uso é representada por uma reta ligando o Ator ao Caso de Uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade de Associação, o que demonstra o sentido em que as informações trafegam, ou seja, se estas são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (neste ultimo caso a reta não possue setas demonstrando que as informações são transmitidas nas duas direções). Além disso uma associação pode possuir uma descrição própria, quando há necessidade de esclarecer a natureza da informação que está sendo transmitida, ou para das um nome à Associação, se isto for considerado necessário.
A imagem abaixo representa uma Associação entre um Ator e um Caso de Uso;
Examinando essa associação percebemos que o Ator Cliente utiliza, de alguma forma, o serviço Abertura de Conta, representado pelo Caso de Uso e que a informação referente a este processo trafega nas duas direções.
Especialização/Generalização
O relacionamento de Especialização/Generalização é uma forma de Associação entre Casos de Uso no qual existem dois o mais Casos de Uso com características semelhantes, apresentando pequenas diferenças entre si. Quando isso acontece definimos um Caso de Uso Geral que descreve as características compartilhadas por todos os Casos de Uso em questão e então relacioná-lo com os outros casos de uso envolvidos.
A associação de Generalização/Especialização é representada por uma reta com uma seta mais grossa, que indica qual o Caso de Uso Feral (para o qual a seta aponta) e quais os Casos de Uso Especializados(os que estão na outra extremidade da seta) veja um exemplo abaixo;
Embora não seja comum a especialização pode ser aplicada a atores tambem e funciona da mesma forma.
Inclusão
A Associação de Inclusão costuma ser utilizada quando existe um serviço, situação ou torina comum a mais de um Caso de Uso. Quando isso acontece, a documentação dessa rotina é mcolocada em um Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma sequência de passos em vários Casos de Uso. Uma inclusão em um caso de uso comporta-se da mesma forma que uma chamada de função na programação. Uma associação de inmclusão é representada por uma reta tracejada contendo uma seta em uma de suas extremidades que aponta para o Caso de Uso incluído no caso de uso posicionado na outra extremidade da reta. As associações de inclusão costumam apresentar também um EStereótopo contendo o texto “include”, entre dois sinais de menor (<) e dois de maior (>). Os Estereotipos serão melhor detalhados em breve. Veja um exemplo de inclusão abaixo;
Nessa imagem percebemos que feito qualquer ação (Saque ou depósito) é necessário registrar o movimento.
Extensão
Associação de Extensão são utilizadas para descrever cenários opcionais de um Caso de Uso. Os Casos de uso estendidos descrevem cenários que somente ocorrerão em uma situação específica, se uma determinada condição for satisfeita.
As associações de Extensão indicam a necessidade de um teste para determinar se é necessário executar também o Caso de Uso estendido ou não. Relacionamentos de Extensão representam eventos que não ocorrem sempre, o que não significa que eles sejam incomuns. As associações de Extensão possuem uma representação semelhante a de inclusão, utilizando também a reta tracejada diferenciando-se pelo fato da seta apontar para o Caso de Uso que utiliza o Caso de Uso estendido e por possuir um Estereótipo contendo o texto “extend” ao invés de “include” a imagem abaixo representa muito bem uma extensão:
O certo no banco é que quando vc va cancelar a conta fique com saldo igual a zero ou seja, não esteja nem devendo para o banco e também não tenha dinheiro, então para encerrar a conta é necessário se o saldo positivo sacar o dinheiro e se negativo “pagar” depositar dinheiro.
UFÁ! Pensei que seria menor o caso de uso mas finalmente terminamos essa parte.
Bem no próximo post vamos falar de diagrama de classes, até la!
Nenhum comentário:
Postar um comentário