Diagrama de Caso de Uso

www.luisaosoares.com.br@luisaosoareswww.facebook.com/luisaorcc

Introdução

Diagrama mais abstrato, flexível e informal da UML.

É utilizado no início da modelagem para identificar os requisitos do sistema.

Utilizado como base para criação de outros diagramas.

Com o uso de uma linguagem simples, permite que qualquer pessoa compreenda o comportamento externo do sistema.

Introdução

• Identifica os tipos de usuários que interagem com o sistema, os papéis que eles assumem e as funções requisitadas;

• É apresentado durante reuniões iniciais com os clientes para poder auxiliar na identificação de possíveis falhas;

• Descreve os requisitos funcionais do sistema de maneira consensual entre usuários e desenvolvedores de sistema.

Elementos BásicosAtores Caso de Uso Associação Sistema

CASO DE USO

SISTEMA

Fronteira do sistema(Opcional)

ASSOCIAÇÃO

Atores

• Representam os papéis desempenhados pelos diversos usuários que poderão utilizar ou interagir com os serviços e funções do sistema.

• Pode ser qualquer elemento externo que interaja com o sistema, inclusive um software ou hardware.

• Exemplos típicos: cliente, aluno, supervisor, professor, impressora fiscal, dispositivo de conexão de rede etc.

• Identificando atores de um sistema: Quem utilizará a principal funcionalidade do sistema? Quem (ou o que) tem interesse nos resultados do sistema? Quais dispositivos (hardware) são necessários? Com quais outros sistemas o sistema em foco irá interagir?

Casos de uso

• Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários do sistema;

• São usados para expressar e documentar os comportamentos das funções do sistema;

• Em geral, podemos associar um caso de uso a uma tela (ou página) de um sistema, apesar de isto não ser uma regra;

• Contém um texto descrevendo o serviço (iniciando-se com um verbo);

Cadastrar Produto

Gerar Relatório de

Vendas

Emitir NF-e

Características dos Casos de Uso

• É sempre iniciado por um ator Realizado em nome de um ator que, por sua vez,

deve pedir direta ou indiretamente ao sistema tal realização.

• Um Caso de Uso é completo Deve ser uma descrição completa de um

determinado processo.

• Deve especificar um valor para o atorComo resposta à solicitação do ator, retorna um

valor.

Identificando um Caso de Uso.

• O trabalho diário do sistema pode ser simplificado ou tornado mais eficiente usando novas funções?

• Quais as funções que o ator necessita do sistema?

• O que o ator necessita fazer?

• Quais entradas e saídas, juntamente com sua origem e destino, que o sistema requer?

Associações

São representadas por uma linha que liga o ator ao caso de uso:

Generalização e Especialização • Forma de associação na qual existem dois ou mais casos

de uso com características semelhantes; • Existem pequenas diferenças entre os casos de uso

associados; • Também é possível com atores;

Inclusão

• A execução de um caso de uso obriga a execução de um outro;

• Pode ser comparado à chamada de uma sub-rotina; • Representada por uma reta tracejada com uma seta

apontando para o caso de uso que foi incluído; • Estereótipo com o texto <<include>>:

Exemplo de inclusão

Extensão

• Descreve cenários opcionais de um caso de uso; • Só ocorrerá se uma determinada condição for

satisfeita; • Representada por uma reta tracejada com uma

seta apontando para o caso de uso que recebe a extensão;

• Estereótipo com o texto <<extend>>:

Restrições

• Às vezes, não fica claro a condição que deve ser satisfeita para que um caso de uso seja executado;

• Nesses casos, podemos usar restrições com uma nota explicativa determinando a condição para que o caso de uso seja executado;

• As restrições são compostas por um texto entre chaves:

Restrições

Documentação de casos de uso

• Descrição bastante simples do caso de uso; • Tem como objetivo informar os atores que

interagem com o sistema e as etapas que devem ser executadas pelo ator e pelo sistema para que o caso de uso execute sua função;

• Não há um modelo padrão para especificação de caso de uso;

• Recomenda-se que seja simples e de fácil acesso.

Exemplo de um modelo

• Sistema de Pagamento de Serviços

– O sistema será responsável por gerenciar os pagamentos dos serviços prestados por empresas e freelancers. O pagamento do serviço poderá ser efetuado apenas pelo usuário que possuir o perfil específico para esta função. Ao ser realizado qualquer serviço e pagamentos, o sistema gera e envia uma mensagem de e-mail aos prestadores do serviço.

Pagamento de Serviço

Cenário Principal de Sucesso:1. O usuário acessa o sistema2. O usuário pesquisa o serviço a ser pago3. O sistema apresenta as informações do serviço4. O usuário inicia o processo de pagamento5. O sistema envia a confirmação do pagamento ao prestador do serviço6. O sistema encerra o processo de pagamento

Extensões:1a. Usuário não autorizado 1a.1 O usuário não possui perfil para realizar pagamentos 1a.2 O usuário é direcionado ao passo 6.3a. Serviço não finalizado 3a.1 O sistema apresenta que o serviço não foi finalizado 3a.2 O usuário é direcionado ao passo 6.

Descrição

Diagrama

Diagrama

Diagrama de Caso de Uso• Exemplo de Caso de Uso para sacar dinheiro

Estrutura da classe• Uma classe em UML possui três partes:

– Nome da Classe– Atributos– Operações

• Podemos abreviar a declaração da classe, caso não influencie o entendimento do diagrama:

22

Atributos• Um atributo é formado por:

visibilidade nome : tipo [multiplicidade] = valor inicial {propriedades}

23

Operações• Uma operação é formada por:

visibilidade nome (parâmetros) : tipo de retorno {propriedades}

• O parâmetro de um método é formado por:nome : tipo [multiplicidade] = valor inicial

24

Visibilidade• Podemos definir as seguintes visibilidades em atributos e

operações:

- private~ default# protected+ public

25

Atributos e operações estático• Podemos definir atributos e operações como sendo estáticos,

ou seja, são referentes a classe e não aos seus objetos.

26

Comentário• Os comentários ou notas são utilizados para adicionar mais

informações ao diagrama.

27

Comentário• O comentário pode ser utilizado em qualquer diagrama,

podendo ou não ser vinculado a algum elemento.

• Utilizamos também o comentário para definir alguma regra de restrição, para isto precisamos adicionar { } entre a restrição:

28

Associações• Utilizado para representar o relacionamento entre classes, as

associações podem ser:– Associação– Agregação– Composição– Classe de associação

• As classes que fazem parte de um relacionamento também são chamadas de TODO (responsável pelo relacionamento) e PARTE (usado pelo relacionamento).

29

Associação• Relacionamento simples entre duas classes:

30

Agregação• Informa que uma classe faz parte de outra classe, mas não de

forma exclusiva.

31

Composição• Informa que uma classe faz parte de outra classe de forma

exclusiva.

32

Agregação x Composição• A diferença entre ambos é:

Agregação – se excluir a classe responsável pelo relacionamento, não deve excluir a classe que ele possui relacionamento.

Composição – se excluir a classe responsável pelo relacionamento, então deve excluir a classe que ele possui relacionamento.

33

Classe de associação• Utilizamos para realizar o relacionamento entre duas classes:

• ou

34

• Podemos também ter uma associação para mesma classe:

Associação

35

Navegabilidade• Podemos informar qual a direção do relacionamento:

36

Multiplicidade• A multiplicidade é utilizada para definir a quantidade de

objetos devem ser criados:0 .. 1 (zero ou um)1 (um)* (zero ou muitos)

37

Multiplicidade• Quando utilizamos atributos para informar coleção de

objetos, podemos também adicionar propriedades na multiplicidade:{ordered} - Ordenado{unordered} - Não ordenado{unique} - Único{nonunique} - Não único{bag} - Conjunto não ordenado e não único

38

Criando um diagrama de Classes• No item Diagramas -> Novo -> Diagrama...

• Selecione a opção Diagrama de Caso de Uso

39

Criando um diagrama de Classes• Ao clicar em Finalizar teremos a seguinte tela:

40

1) Área para criação do diagrama de Caso de Uso2) Paleta com os itens que podem ser adicionados no diagrama de Caso de Uso

Exemplo• Crie o diagrama de classes UML para a seguinte figura:

41

Inicio FimPedido Pagamento Entrega

Resposta exemplo prático

42

Exemplo prático

• Crie um diagrama de classes UML para o sistema de Agendamento de Entrega de Produtos:

– O sistema deve permitir o agendamento de uma visita por parte de um funcionário, ao cliente de nossa empresa. Esta visita deverá ser realizada em hora e local definido pelo cliente para poder lhe entregar os produtos que foram comprados em nossa loja.

43

Resposta exemplo prático

44

Dependência• Utilizado para informar que uma classe depende de outra

classe para executar alguma operação:

45

Dependência• Palavras - chave de dependência:

<<call>><<create>><<dependency>><<use>>

46

Associação x Dependência• A diferença básica entre ambos:

– Associação temos um atributo da classe relacionada.

– Dependência utilizamos a classe relacionada, para passar um parâmetro, chamar um método, criar um objeto, etc.

47

Associação x Dependência• Exemplo:

48

Classe Abstrata• Utilizado para informar que uma classe não implementa todos

os seus métodos.

49

Herança• Utilizamos herança quando queremos declarar subclasses,

permitindo reutilizar os códigos já declarados na superclasse.

50

Interface• Utilizamos interface para definir as operações básicas que

uma classe de seu tipo precisa implementar.

51

Interface• Exemplo:

52

Pacote• Utilizamos para organizar as classes:

53

Template• É uma classe parametrizada para definir conjuntos fortemente

tipados.

54

Enumeration• Utilizado para criar um conjunto fixo de valores:

55

Exemplo prático• Crie um diagrama de classe em UML para o Sistema de Envio

de Produtos:– O sistema deve controlar a ordenação do envio dos produtos por

preço ou por endereço do cliente. De acordo com a quantidade de produtos, também precisamos alocar um veiculo que pode ser uma Van ou uma Caminhonete.

– Também precisamos controlar o status do envio que pode ser, aguardando pagamento, buscando em estoque, saída para entrega ou entregue.

56

Resposta exemplo prático

57

O que colocar no diagrama de classes• Concentre-se nas áreas principais do sistema.• O necessário para que as pessoas envolvidas possam

entender.• Mantenha as notações simples.• Gere um diagrama de classe flexível, facilitando futuras

atualizações.• Desenvolva o diagrama baseado na metodologia adotada,

podendo ser um diagrama de negocio, diagrama especifico por áreas do sistema ou diagrama com todas as classes envolvidas no sistema.

58

O que não colocar no diagrama de classes

• Para não aumentar a complexidade de um diagrama de classes, normalmente não adicionamos no diagrama:– Classes que representam telas.– Classes de conexão e acesso ao banco de dados.– Classes de API’s da linguagem ou de terceiros.

• Não tente usar todas as notações disponíveis no mesmo diagrama.

• Não desenhe modelos para tudo, a menos que seja realmente necessário.

59

Ferramentas IDE• Eclipse UML - http://www.eclipseuml.com• Jude - http://jude.change-vision.com• NetBeans – http://www.netbeans.org• Magic Draw - http://secure.nomagic.com • Microsoft Office Visio -

http://office.microsoft.com/pt-br/visio/default.aspx • Poseidon - http://www.gentleware.com

• Enterprise Architect - http://www.sparxsystems.com.au/

60

Adicionando o plug-in de UML no NetBeans

• No menu Ferramentas → Plug-ins– Selecione em Plug-ins disponíveis → UML

61

1

2

Certificações UML• OCUP – OMG Certified UML Professional

http://www.omg.org/uml-certification/exam_info.htm

62

Referencia bibliografica• [Booch, Rumbaugh e Jacobson, I.]

Grandy Booch, James Rumbaugh e Ivar Jacobson, UML: Guia do Usuário, 3ª Ed. Campus, 2005.

• [Fowler]Martin Fowler, UML Essencial, 3ª Ed. Bookman, 2005.

• [Guedes]Gilleanes T. A. Guedes, UML: Uma abordagem pratica, 3ª Ed. Novatec, 2008.

• [Cardoso]Caíque Cardoso, UML na prática: do problema ao sistema, Ed. Ciência Moderna, 2003

• UML - http://www.uml.org• Wikipédia – http://www.wikipedia.org

63

Obrigado!

http://www.slideshare.net/rodrigocasca/uml-criando-diagramas-eficientes

64