Introdução
Diagrama de caso de uso é uma ferramenta regimentada pelas normas da UML. Basicamente A linguagem regulamenta uma série de diagramas que vem pra facilitar a criação do modelo do projeto, problema inerente das soluções criadas sob o paradigma de orientação ao objeto. É uma ferramenta para comunicar funções de alto nível do escopo com o escopo do sistema, em outras palavras é um diagrama simples que basicamente mostra o sistema pelos olhos do usuário. Dada a sua simplicidade é uma excelente ferramenta para intermediar a comunicação entre o analista de sistemas e o usuário, cliente ou stakeholder.
É importante ressaltar que todos os diagramas são ferramentas para auxiliar na criação de um bom projeto. Quem trabalha ou pelo menos se aventurou em programação sabe que muitos erros de projeto poderiam ser evitados se fosse obedecido o procedimento descrito tanto aqui quanto em toda a normatização UML. Tarefa essa que não é fácil uma vez que normalmente se começa um projeto pela parte que deveria ser a última, a codificação.
Constituição
Para que o diagrama cumpra seu propósito de facilitar a comunicação entre diferentes níveis de conhecimento técnico, nada mais justo de ele ter uma estrutura relativamente simples. Há neste tipo de diagrama apenas 3 elementos básicos, a saber:
Ator :
- Representa um usuário do sistema. Pode ser uma pessoa ou um outro sistema, desde que esteja fora do sistema em análise. É mandatório que um ator seja relacionado com componentes , classes ou casos de uso. Salva a exceção de herança entre atores.
Caso de uso :
- Nada mais do que a representação de uma função do sistema.Trata-se exclusivamente de uma representação de uma ação pretendida, ou uma função executada pelo sistema, como imprimir boleto, executar ação, salvar. Posto que uma função pode ser estruturada em subfunções, um caso de uso pode ser estruturado. Se houver limites no sistema do diagrama, o caso de uso estará dentro dos limites.
Relacionamentos entre eles :
- Representam relacionamento entra os atores que fazem parte do diagrama, atores e casos de uso ou até mesmo de casos de uso a casos de uso dependendo exclusivamente da necessidade.De Atores para Casos, representa-se a relação no diagrama por uma reta, esta pode ou não conter uma seta em sua extremidade que vai ilustrar a direção do fluxo de dados (observe que se o fluxo for ambi direcional é desnecessário por seta na associação). Se for necessário, uma associação pode possuir descrição, seja para determinar o tipo, importância, velocidade dos dados que por ela trafegarão ou unicamente para dar nome a mesma, vai da necessidade. Podem ser de três, tipos a saber.
- Associação: Dada entre um ator e um caso de uso determina uma função do sistema do ponto de vista do usuário.
- Generalização ou Especialização: Dada entre atores, são uma forma de transportar os casos de uso de um ator para outro, processo que pode ser chamado de herança. Para Casos de uso vale a mesma ideia, salvo que existem dois ou mais casos de uso que possuem funções semelhantes entre si, com diferenças ínfimas, define-se um caso de uso geral com as características compartilhadas e relaciona-o com aos demais casos de uso. Para este caso representa-se o caso de uso geral(indicado por uma seta mais grossa)ligado aos específicos (na extremidade sem seta da reta de relacionamento) .
- Inclusão: Dada entre caso de uso funciona quando existem funções comuns a vários casos de uso, de forma que essas funções são colocadas em um caso de uso específico e os outros se utilizarão dessas funções tal qual uma função de programação pode chamar outras funções. È representado por uma reta tracejada com uma seta que aponta para o caso de uso incluído, de forma que o caso que recebe a inclusão estará na outra extremidade, comumente esse relacionamento possui um estereotipo* com o texto include (<include>).
- Extensão: Dada comumente de casos de uso para casos de uso, descrevem casos condicionais em que um cenário só acontecerá se uma situação predeterminada for satisfeita. Posto isso necessariamente um caso de uso estendido estará ligado um teste que determinara a aplicação do caso estendido ou não. A representação é a mesma do caso Include, com a reta tracejada e o estereotipo* extend (<extend>) no relacionamento.
*Estereotipo: tag que modifica o tipo ou descreve um elemento no modelo em questão. Em outras palavras determina que a situação estereotipada é uma situação exceção ao caso geral.
Documentação de Casos de Uso
A documentação do caso de uso descreve, de maneira tão simples quando o próprio diagrama, a o sistema em questão. O que cada função faz, como os atores interagem com o os casos, os parâmetros que devem ser fornecidos aos casos, suas restrições e validações. Tem por característica ser um documento de formato flexível por não possuir uma definição fixada pela normatização UML. Essa característica auxilia pois o designer pode faze-la da maneira que achar mais adequada para o projeto, podendo até mesmo conter pseudocódigos(portugol, ou o próprio algorítimo do código) protótipos genéricos. A principal necessidade que a documentação deve atender é que ela deve ser escrita em uma linguagem tão simples que tanto o programador quanto o cliente (leia-se leigo em programação) possa interpretar de forma clara.
Exemplos
String Def_Requerimento= “O sistema de gerenciamento deve ser capaz de permitir ou não a criação de paginas como Blog, site ou wiki de forma exclusiva a autores autenticados na base de credenciais”;
Caso Simples
Nome do caso de uso Criar um anova Wiki
Requerimentos relatados Def_Requerimento
Alvo no contexto Um novo ou já existente autor requisita Uma Wiki pessoal pelo perfil Usuario.
Precondições O autor Tem que ser identificado
Condição de sucesso O autor consegue criar sua Wiki
Condição de falha O requerimento da nova Wiki é rejeitado
Ator primário Usuario
Ator secundário Gerenciador de credenciais
Gatilho O autor Requisita ao CMS uma nova Wiki
Fluxo principal 1 O Usuário Solicita ao CMS uma nova Wiki
2 O Usuário entra com os dados do autor
3 Os dados do autor são verificados
4 A nova Wiki é criada
5 Um email é enviado para o autor com as informações da sua Wiki
Exceções
3.1 Os dados do autor não são verificados
3.2 A nova Wiki não é criada
Utilização do Include
Nome do caso de uso Criar um anova Wiki
Requerimentos relatados Def_Requerimento
Alvo no contexto Um novo ou já existente autor requisita Uma Wiki pessoal pelo perfil Usuario.
Precondições O autor Tem que ser identificado
Condição de sucesso O autor consegue criar sua Wiki
Condição de falha O requerimento da nova Wiki é rejeitado
Ator primário Usuário
Ator secundário Gerenciador de credenciais
Gatilho O autor Requisita ao CMS uma nova Wiki
Casos Incluidos Checagem de credencial
Fluxo principal 1 O Usuário Solicita ao CMS uma nova Wiki
2 O usuario entra com os dados do autor
3
Include::Check os dados do autor são checados
Identidade
4 A nova Wiki é criada
5 Um email é enviado para o autor com as informações da sua Wiki
Exceções
3.1 Os dados do autor não são verificados
3.2 A nova Wiki não é criada
Modo Ultra-Sofisticado
Nome do caso de uso Criar um anova Wiki
Requerimentos relatados Def_Requerimento
Alvo no contexto Um novo ou já existente autor requisita Uma Wiki pessoal pelo perfil Administrador.
Precondições O autor Tem que ser identificado
Condição de sucesso O autor consegue criar sua Wiki com perfil de Colaborador
Condição de falha O requerimento da nova Wiki é rejeitado
Ator primário Administrador
Ator secundário Gerenciador de credenciais
Gatilho O Administrador Requisita ao CMS uma nova Wiki com perfil de Colaborador
Casos Incluídos Checagem de credencial
Fluxo principal 1 O Administrador Solicita ao CMS uma nova Wiki
2 o administrador seleciona um perfil de conta
3 O Administrador entra com os dados do autor
4 O Administrador determina sobre qual página o autor terá privilégios de Colaborador
Include::Check os dados do autor são checados
Identidade
4 A nova Wiki é criada
5 Um email é enviado para o autor com as informações da sua Wiki
Exceções
3.1 Os dados do autor não são verificados
3.2 O autor em questão não pode ser colaborador da Wiki
3.2 A nova Wiki Colaborador não é criada
Bibiografia
Domínios online:
www.devmedia.com.br :[1]
www.dsc.ufcg.edu.br:[2]
pt.wikipedia.org:[3]
celodemelo.wordpress.com:[4]
www.ibm.com:[5]
profpv.blogspot.com.br:[6]
Fontes off-line:
Livro Arquivo:Learning uml 2.0.pdf: Learning UML 2.0 by Kim Hamilton, Russell Miles, Publisher O’Reilly , pub date: aprill 2006
Livro Arquivo:Uml 2.0 in a nutshell.pdf: UML 2.0 in a Nutshell by Dan Pilone, Neil Pitman, Publisher: O’Realley, pub date June 2005
Presentation Arquivo:Umlbasics.pdf: UML Basics By Paolo Ciancarini