Unopar

UML é um acrônimo para a expressão Unified Modeling Language. Pela definição de seu nome, vemos que UML é uma linguagem que define uma série de artefatos que nos ajuda na tarefa de modelar e documentar os sistemas orientados a objetos que desenvolvemos.

Ela possui nove tipos de diagramas que são usados para documentar e modelar diversos aspectos dos sistemas.

A maioria dos problemas encontrados em sistemas orientados a objetos tem sua origem na construção do modelo, no desenho do sistema. Muitas vezes as empresas e profissionais não dão muita ênfase à essa fase do projeto, e acabam cometendo diversos erros de análise e modelagem. Isso quando há modelagem, pois nós profissionais da área sabemos que muitas vezes o projeto começa já na fase de codificação.

Leia mais em: O que é UML e Diagramas de Caso de Uso: Introdução Prática à UML http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408#ixzz30Z09S3EC

ste artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos.

Diagramas de Casos de Uso são compostos basicamente por quatro partes:

Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.

Ator: Usuário do sistema, ou melhor, um tipo de usuário.

Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário)

Comunicação: è o que liga um ator com um caso de uso

Vamos criar um cenário de exemplo para vermos a notação de um diagrama de caso de uso:

“A clínica médica Saúde Perfeita precisa de um sistema de agendamento de consultas e exames. Um paciente entra em contato com a clínica para marcar consultas visando realizar um check-up anual com seu médico de preferência. A recepcionista procura data e hora disponível mais próxima na agenda do médico e marca as consultas. Posteriormente o paciente realiza a consulta, e nela o médico pode prescrever medicações e exames, caso necessário”.

Com esse cenário simples podemos começar a criar nosso diagrama. Inicialmente vamos definir nossos atores:

a) Paciente

b) Secretária

c) Médico

Agora vamos definir algumas ações de cada usuário:

a) Paciente

· Solicita Consulta

· Solicita Cancelamento de Consulta

b) Secretária

· Consulta Agenda

· Marca Consulta

· Cancela Consulta

c) Médico

· Realiza Consulta

· Prescreve Medicação

· Solicita Realização de exames

Bom, agora já temos uma relação de atores e ações relacionadas a esses atores. Poderíamos criar um documento textual (como foi feito acima), para registrar nossos atores e funcionalidades. Mas o leitor não concorda que uma imagem vale mais que mil palavras? Pois bem, podemos expressar tudo o que definimos em um desenho simples utilizando os padrões da UML para documentação de casos de uso.

No quadro abaixo segue a definição de algumas figuras do diagrama:

No mercado existem diversos tipos de ferramentas case que auxiliam na construção de diagramas. o leitor fique a vontade de utilizar a ferramenta de sua preferencia. Algumas sugestões seriam as versões trial do Enterprise Architect, ou do Visio.

Podemos agora construir o diagrama:

Como podemos observar esse diagrama composto por desenhos simples descrevem de maneira bem objetiva o que textualmente poderia ficar extenso. Nele vemos as funcionalidades do sistema e as interações dos usuários com elas.

Para melhorar um pouco mais esse diagrama vamos ver o conceito de include>>. Include e extend são relações entre os casos de uso.

Include: seria a relação de um caso de uso que para ter sua funcionalidade executada precisa chamar outro caso de uso.

Extend: Esta relação significa que o caso de uso extendido vai funcionar exatamente como o caso de uso base só que alguns passos novos inseridos no caso de uso extendido.

Tanto um como o outro, são notados como setas tracejadas com o texto include>> ou extend>>.

Sabendo disso podemos modificar o diagrama inserindo um novo caso de uso “Consultar Agenda”, que será utilizado no caso de uso “Marca Consulta”. Pois a secretária, antes de marcar precisa verificar a disponibilidade da agenda do médico certo?

O leitor não concorda que esse tipo de diagrama é extremamente simples e útil? Com ele podemos trabalhar em três áreas muito importantes nos projetos:

1) Definição de Requisitos: Novos casos de usos geralmente geram novos requisitos conforme o sistema vai sendo analisado e modelado;

2) Comunicação com os Clientes: Pela sua simplicidade, sua compreensão não exige conhecimentos técnicos, portanto o cliente pode entender muito bem esse diagrama, que auxilia o pessoal técnico na comunicação com clientes

3) Geração de Casos de Teste: A junção de todos os cenários para um caso de uso pode sugerir uma bateria de testes para cada cenário

Com isso chegamos ao fim desta parte do nosso artigo. Espero que tenham gostado. Por favos peço que deixem seus comentários para que possamos melhorar a qualidade de nossos artigos.

Obrigado a todos.

Leandro Ribeiro

Leandro é analista de sistema, graduado em Tecnologia da Informação. Possui experiência em projetos para os mercados de PBM (Pharmaceutical Benefit Management), Telecomunicações VOIP e Automotivo.

O que você achou deste post?

Gostei (11)

(0)

Poste seu comentário

Christopher Jorge Paes De Barros Silva

Muito bom.

[há +1 ano] - Responder

Erika Andreza

Oi Leandro,seu artigo foi o primeiro que me fez entender melhor sobre diagramas.

Parabéns pela explicação.

Só uma dúvida,se no segundo modelo eu colocasse primeiro solicitar consulta e só depois colocasse marcar consulta- include- consultar agenda,causaria prejuízo ao diagrama?

[há +1 ano] - Responder

[autor] Leandro Ribeiro

Olá Érica, fico feliz que o artigo tenha sido util.

Acredito que a sua colocação pode ser válida, desde que o caso de uso Consulta Agenda esteja vinculado ao ator Secretária. Porém creio que ao fazer isso, podemos sair um pouco de um dos principais propósitos do diagrama de caso de uso que é vincular funcionalidades aos atores e passaremos a notar uma espécie de fluxo (que seria melhor registrar num diagrama de Atividades), pois pensando em fluxo, você está correta, um paciente solicita uma consulta e a secretária verifica a agenda para depois marcar.

Espero que eu tenha sido claro, qualquer dúvida pode escrever mais comentários.

Obrigado!

[há +1 ano] - Responder

Fabricio Pedro

Uma pergunta a comunicação com seta indica qual pessoa usa a função no sistema diretamente?. por exemplo é a secretária que marca a consulta diretamenta, mas ela interage com o sistema e pessoa.

[há +1 ano] - Responder

[autor] Leandro Ribeiro

Olá Fabrício Pedro. Sim a seta indica a comunicação de um ator com um caso de uso em específico. Neste diagrama precisamos deixar bem claro QUEM faz O QUE, e é sempre bom lembrar que nunca devemos indicar COMO faz algo.

A parte em que você cita a interação entre atores não faz parte do escopo do diagrama, porém faz parte do negócio. Por isso colocamos o caso de uso [Marca Consulta] sendo ligado aos atores Paciente e Secretária, pois a Secretária não pode marcar uma consulta sem que um paciente solicite. Para a visão de negócio a solicitação do paciente é relevante, para a visão de sistema é irrelevante, pois quem marca consulta é a secretária.

Obrigado.

[há +1 ano] - Responder

Adilson Ferreira De Lima Silva

Excelente meu camarada, Sou iniciante no curso de sistema de informção. E já aprendi mais aqui, do que com meu professor...rsrs

Só faltou um pequeno exemplo de include.

Abraço

[há +1 ano] - Responder

[autor] Leandro Ribeiro

Adilson, obrigado pelos elogios e pela dica.

Assim que que for possível vou dissecar um pouco mais esse assunto.

Obrigado.

[há +1 ano] - Responder

Denize Do Nascimento

Muito Bom!

Fácil compreensão e prático, parabéns!

[há +1 mês] - Responder

[autor] Leandro Ribeiro

Obrigado Denize.

É sempre bom saber ter um feedback de nossos artigos.

[há +1 mês] - Responder

Justino Cangahi

Este conteúdo foi tão clara para mim e ajudou me a aclarar algumas dúvidas.

muito Obrigado.

[há +1 mês] - Responder

[autor] Leandro Ribeiro

Justino Cangahi, obrigado pelo feedback!

[há +1 mês] - Responder

João James Prestes De Mello

Foi minha 1a. visita ao SITE e com interesse em UML.

Parabéns. Gostei bastante.

[há +1 ano] - Responder

Wesley Yamazack

Olá João, que bom que foi do seu agrado temos muito mais conteúdo no portal! Boa leitura!

Um abraço

[há +1 ano] - Responder

Simone Lopes Da Silva

Qual tópico fica a parte de UML e linguagem de modelagem?

[há +1 mês] - Responder

Wesley Yamazack

Olá Simone, não entendi seu comentário, poderia explicar melhor por favor?

Um abraço

[há +1 mês] - Responder

Gesiel Alves De Andrade

Muito legal essas dicas, estou no primeiro semestre de GTI e é justamente o que estou vendo na aula de modelagem. Valeu pela explicação.

[há 27 dias] - Responder

Nilso Texeira

Mto Bom, bem objetivo.

[há 8 dias] - Responder

Conhece a assinatura MVP?

Publicidade

Serviços

Inclua um comentário

Adicionar aos Favoritos

Marcar como lido/assistido

Incluir anotação pessoal

+Engenharia de software

Leia mais em: O que é UML e Diagramas de Caso de Uso: Introdução Prática à UML http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408#ixzz30Z1CUJj5