O documento introduz os conceitos fundamentais da linguagem UML (Unified Modeling Language) para modelagem de sistemas de software. Apresenta casos de uso para modelagem de processos de negócios, como o processo de vendas, e descreve os elementos que compõem a documentação de casos de uso, tais como pré-condições, fluxos de eventos e pós-condições.

1. Introdução à UML
Profa. Adriane Carvalho

2. O que é a UML?
• A UML é a linguagem padrão para visualizar,
especificar, construir e documentar os
artefatos de um sistema intensamente
baseado em software
• Pode ser usada com todos os processos,
durante todo o ciclo de desenvolvimento, e
com diferentes tecnologias de
implementação

3. Ferramenta de Comunicação
Permite para capturar objetos e a lógica de negócios
Usada para analisar e projetar sistemas

4. Caso de Uso de Negócio
Análise de Caso de Uso é uma técnica utilizada para capturar processos
de negócios do ponto de vista do cliente

5. Um Modelo de Caso de Uso de
Negócio
Processo de Vendas
Comprar itens
Fazer consulta
de Preço
Caixa Cliente
Pedir troca

6. Conceitos Fundamentais
• Os Casos de Usos podem ser organizados pela
especificação de relacionamentos de
generalização,
generalização inclusão e extensão existentes
extensão,
entre eles.
• Generalização significa que o Caso de Uso ou ator
herda o comportamento e o significado do uso do
pai.
– É usado quando tem um que é semelhante a outro,
mas faz um pouco mais. Isso nos dá uma outra maneira
de capturar cenários alternativos.

7. Conceitos Fundamentais
• Um relacionamento de inclusão entre casos de
uso significa que o caso de uso base incorpora
explicitamente o comportamento de um outro
caso de uso.
– Pode ser usado quando parte do comportamento que
é semelhante em mais de um caso de uso e você não
quer ficar copiando a descrição deste comportamento

8. Conceitos Fundamentais
• Um relacionamento estendido significa que o Caso
de Uso base incorpora implicitamente o
comportamento de um outro Caso de Uso.
– É semelhante a generalização. O Caso de Uso
estendido pode acrescentar comportamentos para o
caso de uso base
– Os pontos que estão sendo estendidos devem ser
relacionados na linha que liga os dois Casos de Uso

9. Conceitos Fundamentais
• Onde usar cada caso?
– Use inclusão quando estiver se repetindo
em dois ou mais Casos de Uso separados
e você deseja evitar a repetição
– Use generalização quando você estiver descrevendo
uma variação em comportamento normal e você
deseja descrevê-la sem muito rigor
– Use extensão quando você estiver uma variação em
comportamento normal e deseja utilizar a forma mais
controlada, explicando os pontos de extensão no uso-
base

10. Documentação dos Casos de Uso
• Documentação resumida com o
propósito do Caso de Uso
• Descrição dos fluxos primário e
alternativo de eventos que ocorrem
quanto do Caso de Uso de Negócio é
iniciado
• Deve espelhar o diálogo entre o Ator
de Negócio e o Caso de Uso de
Negócio
• Deve ser utilizada uma linguagem de
alcance do cliente

11. Fluxos de Eventos do Caso de Uso
• Descreve apenas os eventos pertinentes ao Caso
de Uso de Negócio, e não o que acontece em
outros Casos de Uso de Negócio
• Deve evitar termos vagos, como por exemplo:
“etc.” e “outros”
• O fluxo de eventos deve descrever:
– Como e quando o Caso de Uso de Negócio começa e
termina
– Quando o Caso de Uso de Negócio interage com os
Atores de Negócio
– Qual informação é trocada entre o Ator de Negócio e
o Caso de Uso de Negócio

12. Detalhamento da Documentação
• Pré-condição: restrições que devem ser
atendidas ao se iniciar um Caso de Uso
de Negócio
• Pós-condição: resultado a ser atingido
ao final do Caso de Uso de Negócio

13. Formas de Detalhamento
• ID e Nome do caso de uso de negócio
• Sumário
• Atores do Negócio
• Pré-condições
• Descrição Detalhada
• Pós-condições
• Exceções/Cursos alternativos
• Interface
• Requisitos não funcionais
• Use Cases relacionados

14. Fonte: ITO, MARTINI, IOCHIDA, 2006

15. Descrição de um caso de uso
Monitorar o Diabetes
Fluxo Básico:
A atendente do CMD controla a glicemia
O paciente entra em contato com a CMD periodicamente e a atendente solicita que o
paciente informe o resultado da glicemia medida. O paciente informa o valor apontado
pelo equipamento. A atendente anota no formulário de ocorrências do paciente a data,
horário, valor do nível apontado pelo equipamento.
A atendente do CMD informa os procedimentos a serem seguidos
Diante dos resultados, condições gerais informadas e procedimentos solicitados pelo
médico, a atendente indica os procedimentos que devem ser seguidos pelo paciente,
através da consulta ao sistema de apoio à decisão. Estes procedimentos devem ser
reforçados pela importância e estado clínico do paciente.
A atendente encerra contato
A atendente finaliza o contato de controle de diabetes com procedimentos elaborados
pelo departamento educacional e se despede do Paciente.

16. Descrição de um caso de uso
Monitorar o Diabetes
Fluxos Alternativos:
O paciente deseja fornecer sugestões.
O paciente querendo sugerir algo a atendente transfere a sua chamada para o setor de
Ouvidoria da CMD, através do caso de uso de negócio <Acompanhar execução de
serviços>.
O médico é informado de intercorrência
Após encerrar o contato e em casos de emergência o médico é avisado que o seu
paciente necessita um contato imediato (por telefone), ou foi agendado para consulta
antecipada, ou foi para uma unidade de pronto atendimento.
O paciente não entra em contato
Após dois dias de ausência de contato do paciente a atendente deve verificar o que está
acontecendo. Se a atendente não encontrar o paciente, deverá tentar novo contato após 1
hora e em até três vezes no dia. Neste caso, a atendente deverá atualizar o formulário de
controle do paciente com a data e horário da tentativa, além do status de não encontrado.
Caso não consiga falar com o paciente por uma semana, a atendente deverá contatar o
médico avisando do ocorrido.