UML

(Linguagem unificada
de modelagem)
 Modelo de Casos de Uso
-> descritos através de Diagramas de Caso de
uso

Determinação dos usos que o sistema terá

(requisitos funcionais)

● captura os usos ou aplicações completas do sistema

● diz que usos o sistema terá

● serviços a serem desempenhados pelo sistema

 Diagramas de Casos de Uso

Primitivas

● Atores
● Casos de uso

● Relacionamentos
 Modelo de Casos de Uso
Atores → representam papéis desempenhados por
●

pessoas, dispositivos ou outros

softwares
● São representações de entidades externas, tais como:

● Pessoas

● Dispositivos

● Hardwares

● Softwares

● Mas que interagem com o sistema durante sua execução

● A interação se dá através de troca de mensagens

 Atores

Atores implícitos → não aparecem no diagrama

embora estejam presentes

● Participam da execução dos casos de uso

● A supressão destes não prejudica o modelo

(ou a sua inclusão não traz contribuição para o modelo)

● Exemplos: monitor de vídeo, teclado, mouse,

auto-falante, microfone, unidade de disco,

sistema operacional
 Casos de uso

● Descrição dos serviços a serem oferecidos pelo sistema

● Descreve uma aplicação ou uso completo do software

● Não é um componente do sistema mas sim um de seus

empregos possíveis (usos)

→ portanto não deve ser confundido com o conceito
de módulos
● Também não é função
 Relacionamentos
Entre atores
● relações externas ao sistema

● podem, portanto, ser desprezadas

● se desejável, podem ser incluídas → já que fazem parte

do modelo de negócios da empresa

Tipos de relacionamentos entre atores

● Comunicação (ou associação)

● Especialização (ou generalização)

 Relacionamentos
Entre ator e caso de uso

● expressa uma comunicação entre eles

● o ator é externo → não há relacionamento estrutural

● pode existir mais de um relacionamento de um ator com

diferentes casos de uso

● um mesmo caso de uso pode envolver a participação de

mais de um ator
● utilizam-se setas para indicar qual ator ativa o caso de uso
 Relacionamentos entre
casos de uso
→ Nunca serão de comunicação
→ Serão sempre estruturais
● Inclusão
● um caso de uso insere, em seu interior, outro caso de uso

● o elemento inserido deve ser classificado como

'subcaso de uso'
● não representa um serviço completo (é porção de

um serviço)
● isoladamente não teria sentido (sempre será parte de

um caso de uso)
● destina-se ao detalhamento de casos de uso através

da decomposição
● coloca em evidência partes comuns a dois ou mais

casos de uso
 Relacionamentos entre
casos de uso

Inclusão
 Relacionamentos entre
casos de uso
Extensão
● um caso de uso maior é estendido por um caso de

uso menor
● o caso de uso que estende inclui serviços especiais

em um caso de uso maior

● inclui a especificação de uma condição de extensão

● a diferença principal entre os relacionamentos de inclusão

e extensão é o caráter
de excepcionalidade da extensão
 Relacionamentos entre
casos de uso
Generalização
● relação estrutural entre um caso de uso mais geral e

outro mais específico

● o mais específico estende o mais geral

● implica a incorporação (herança) do serviço relativo ao

caso geral no caso específico

● o caso de uso geral é

● uma generalização (abstração) do mais específico

● representa as partes comuns aos específicos

 Decomposição de diagramas
de caso de uso
Um projeto de software pequeno conterá um único
diagrama de casos de uso
● para projetos maiores, é possível a construção de

vários diagramas de casos de uso elaborados a partir

da decomposição de um diagrama principal
 Decomposição de diagramas
de caso de uso
● A decomposição pode ser feita utilizando o conceito
de pacotes (package)
● o pacote é usado para separar ou agrupar elementos

do projeto sem criar necessariamente algum vínvulo

entre os elementos
● os elementos (casos de uso e atores) dentro de um

pacote podem ter relacionamentos

com elementos de outros pacotes
● As dependências devem ser mostradas com segmento

de reta tracejado com uma seta apontando para

o pacote que contém as dependências
 Exemplo
Exemplo de modelagem para um sistema de
controle acadêmico

Modelagem através de 4 fases:

1) Levantamento dos atores

2) Levantamento dos casos de uso principais
3) Definição dos relacionamentos
4) Detalhamento dos casos de uso
 Exemplo
Fase 1: Levantamento dos atores

● O sistema será utilizado na secretaria de um curso

● Somente o pessoal da secretaria terá acesso ao sistema

● Pessoas: chefe da secretaria, secretária, alguns

professores, alguns estagiários

● Apesar de serem pessoas diferentes representam

o mesmo papel no sistema

→ ator Secretaria
 Exemplo
● Alguns documentos precisarão ser impressos
● histórico escolar, diário de classe

→ ator Impressora
● O volume de informações pode ser grande

● alunos, professores, disciplinas

● optou-se por um Sistema Gerenciador de

Banco de Dados
→ ator SGBD
 Exemplo
Fase 2: Levantamento dos casos de uso principais

● Define-se a lista dos grandes serviços que o sistema

deverá oferecer
● corresponde a uma análise de requisitos a partir de

informações coletadas dos clientes

● questionários

● reuniões

● No nosso exemplo, os clientes desejam os

seguintes serviços:
● Cadastramento de todos os alunos matriculados

→ Caso de uso Cadastrar Aluno

● Cadastramento de todos os professores que

ministram disciplinas
→ Caso de uso Cadastrar Professor
 Exemplo
Fase 2: Levantamento dos casos de uso principais

● Registro das disciplinas oferecidas no curso

→ Caso de uso Cadastrar Disciplina
● Registro da matrícula de alunos em disciplinas a

cada semestre
→ Caso de uso Registrar Matrícula
● Emissão da confirmação de matrícula para cada aluno

→ Caso de uso Emitir Confirmação de Matrícula

● Emissão do diário de classe para cada disciplina

→ Caso de uso Emitir Diário de Classe

● Lançamento das notas obtidas pelos alunos em

cada disciplina
→ Caso de uso Registrar Nota
● Emissão do histórico escolar para cada aluno

→ Caso de uso Emitir Histórico Escolar

 Exemplo
Fase 2: Levantamento dos casos de uso principais
 Exemplo
Fase 3: Definição dos relacionamentos

●São estabelecidos os relacionamentos de comunicação

entre os atores e os casos de uso → indicam quais atores
se comunicam com quais casos de uso
Fase 3: Definição dos relacionamentos
Exemplo
 Resumindo
Modelo de casos de usos

● útil na descrição dos requisitos funcionais de um

sistema computacional
● permite especificar o conjunto de funcionalidades

ou serviços que um software deve oferecer

● especifica, também, as relações do sistema com as

entidades externas (atores)

● pode ser apresentado aos clientes para discussões e

revisões → é o contrato entre os clientes e os

desenvolvedores
 Resumindo
Modelo de casos de usos

● fornece uma visão macroscópica dos serviços do sistema

sem induzir a forma de realização (projeto) do software
● é uma visão abstrata das funcionalidades

● é uma ferramenta para o planejamento do

desenvolvimento de sistemas computacionais

 Exercício
Para o sistema especificado em aula, proponha os casos
de uso principais e seus relacionamentos. Apresente os
diagramas de caso de uso que atendam à proposição
acima, bem como indique os atores que vão interagir com
o sistema a ser desenvolvido.
Bibliografia
[1] STADZISZ, Paulo Cézar.
Projeto de software usando a UML. Versão 2002.
CEFET-PR