aula 1 slide

Prévia do material em texto

2017.2
MODELAGEM DE SISTEMAS
AULA 01
INTRODUÇÃO
"uma imagem vale mais que mil palavras“
Todo modelo possui um propósito e
simbologia própria para representação do
negócio
Desenvolver nos alunos
competências voltadas a capacidade
de representação do negócio
através de modelos da UML e ter
visibilidade para construção de
sistemas
CONTEXTUALIZAÇÃO
O valor agregado da tecnologia nas empresas está centrado no potencial dos
sistemas em extrair conhecimento e colaborar para as estratégias e tomadas de
decisão.
Maior aderência maior sucesso nos resultados
A modelagem tem uma importância fundamental na medida em que oferece
suporte para investigação, conferência e validação dos procedimentos
apreendidos durante as etapas de definição.
Quanto mais aderência a realidade do usuário o sistema estiver, maior é o
sucesso nos resultados.
MODELOS
Construímos modelos para comunicar a estrutura e o
comportamento desejado do sistema.
Construímos modelos para visualizar e controlar a
arquitetura do sistema.
Construímos modelos para compreender melhor o sistema
que estamos elaborando, muitas vezes expondo
oportunidades de simplificação e reaproveitamento.
Construímos modelos apara gerenciar os riscos
Modelos e a UML
A UML (Unified Modelling Language), oferece uma diversidade de
modelos para representação das partes físicas e lógicas dos sistemas
em desenvolvimento.
Os modelos são integrados e, a todo o momento pode ser preciso
retornar ao primeiro modelo construído e realizar alguma correção.
Os modelos são próprios para identificação de falta, erro ou
complemento de requisitos.
UML
Os modelos fornecem múltiplas visões do sistema a ser
modelado, analisando-o e modelando-o sob diversos
aspectos, procurando-se assim atingir a completitude da
modelagem.
A capacidade de representação do negócio por meio de
modelos da UML e ter visibilidade para a construção do
sistema são competências que devem ser desenvolvidas no
aluno nesta disciplina.
EMENTA
EMENTA
Conceitos Básicos de Modelagem;
A Linguagem UML;
 O ciclo de vida Iterativo e Incremental;
Utilizando Uml no ciclo de vida Concepção, Elaboração,
Construção e Transição; Diagramas UML 2.0 no ciclo de
vidado desenvolvimento de software.
CONTEÚDOS
UNIDADE 1 
Conceitos Básicos de Modelagem 
1.1. A Importância da Modelagem
1.2. Princípios de Modelagem
1.3. Análise e Projeto Orientados a Objeto
UNIDADE 2 - A Linguagem UML (Unified 
Modeling Language)
2.1 Introdução a UML
2.2 Visões da UML
2.3 Síntese Geral dos Diagramas UML
2.4 Ferramentas CASE (Computer-Aided Software
Engineering) baseadas na UML
2.5 Perspectivas e Desafios
UNIDADE 3 - O Ciclo de Vida Iterativo e 
Incremental
3.1 Apresentação
3.2 Etapas e Disciplinas
3.3 Técnicas e modelos aplicados
3.4 Definição das iterações
UNIDADE 4 - Utilizando UML no Ciclo de 
Vida
4.1 Fase - Concepção (ênfase no escopo 
do sistema)
4.1.1 Diagrama de Caso de Uso
Apresentação
Notação
Aplicação
Descrição de Caso de Uso
4.1.2 Diagrama de Classe - Modelo de 
domínio
Apresentação
Notação
Aplicação
4 .1.3 Diagrama de Objetos
Apresentação
Notação
Aplicação
4.1.2 Diagrama de Pacotes
Apresentação
Notação
Aplicação
4.2 Fase - Elaboração (ênfase na 
arquitetura do projeto)
4.2.1 Modelo de Classes de Projeto 
Definição da Visibilidade entre Objetos
4.2.2 Diagramas de Interação
Diagrama de Sequencia
Diagrama de Comunicação
Diagrama de Visão Geral da Interação
Diagrama de Temporização
4.2.3 Diagrama de Estado
Apresentação
Notação
Aplicação
4.2.4 Diagrama de Atividades
Apresentação
Notação
Aplicação
4.3 Fase Construção - ênfase no 
desenvolvimento 
4.3.1 Diagrama de Componentes
Apresentação
Notação
Aplicação
4.4 Fase Transição - ênfase na 
implantação
4.4.1 Diagrama de Implantação
Apresentação
Notação
Aplicação
UNIDADE 5 - Exercícios Propostos
AVALIAÇÃO
O processo de avaliação oficial será composto de três
etapas: Avaliação 1 (AV1), Avaliação 2 (AV2) e Avaliação 3
(AV3). Sendo AV2 e AV3 unificadas a partir de um banco de
questões proposto pelos professores da Estácio de todo o
Brasil;
AV1 - 06/10/2017
AV2 – 24/11/2017
AV3 – 01/12/2017
SOFTWARE
http://astah.net/editions/community
BIBLIOGRAFIA BÁSICA
LARMAN, Craig. Utilizando UML e Padrões – Uma
Introdução à Análise e ao Projeto Orientados a Objetos e
ao Processo Unificado. 3ª Edição. Porto Alegre: Artmed,
2007.
FOWLER, Martin. UML Essencial - Um Breve Guia Para a
Linguagem-Padrão. 3ª Edição. Porto Alegre: Artmed, 2005.
FURLAN, José Davi. Modelagem de Objetos Através da
UML - The Unified Modeling Language. Makron Books,
1998.
BIBLIOGRAFIA COMPLEMENTAR
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - Guia do Usuário. 2ª
Edição. Rio de Janeiro: Elsevier, 2005.
MEDEIROS, E.; Desenvolvendo Software com UML 2.0 : definitivo. São
Paulo: Pearson Makron Books, 2004.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto -
Soluções Reutilizáveis de Software Orientado a Objetos. 1ª Edição.
Porto Alegre: Bookman, 2000.
Bezerra, Eduardo; Princípios de análise e projeto de sistemas com
UML, 2/E. 2ª Edição. Campus, 2006.
WAZLAWICK, Raul; Análise e Projeto de Sistemas de Informação
Orientados a Objetos. 1ªEdição. Elsevier, 2004.
MATERIAL DE APOIO
Craig Larman, Utilizando UML e Padrões, editora: Artmed, edição: 3, ano:2007
◦ capítulo: Capítulo 2 Iterativo, Evolutivo e Ágil, nº de páginas: 24
◦ capítulo: Capítulo 40 Mais Sobre Desenvolvimento Iterativo e Gestão de Projetos Ágeis, nº de páginas: 9
Martin Fowler, UML Essencial, editora: Artmed, edição: 3, ano:2005
◦ capítulo: Capítulo 1: Introdução, nº de páginas: 14
◦ capítulo: Capítulo 3: Diagramas de Classes: Os Elementos Básicos, nº de páginas: 15
◦ capítulo: Capítulo 4: Diagramas de Sequência, nº de páginas: 10
◦ capítulo: Capítulo 5: Diagramas de Classes: Conceitos Avançados, nº de páginas: 17
◦ capítulo: Capítulo 6: Diagramas de Objetos, nº de páginas: 2
◦ capítulo: Capítulo 7: Diagramas de Pacotes, nº de páginas: 6
◦ capítulo: Capítulo 8: Diagramas de Instalação, nº de páginas: 2
◦ capítulo: Capítulo 9: Casos de Uso, nº de páginas: 6
◦ capítulo: Capítulo 10: Diagramas de Máquina de Estados, nº de páginas: 8
◦ capítulo: Capítulo 11: Diagramas de Atividades, nº de páginas: 11
◦ capítulo: Capítulo 12: Diagramas de Comunicação, nº de páginas: 3
◦ capítulo: Capítulo 13: Estruturas Compostas, nº de páginas: 2
◦ capítulo: Capítulo 14: Diagramas de Componentes, nº de páginas: 2
MATERIAL DIDÁTICO
CONCEITOS
A EVOLUÇÃO DAS METODOLOGIAS SURGIU DEVIDO A FALTA DE 
MÉTODOS E TÉCNICAS QUE GERAVAM MUITOS ERROS E 
DEPENDÊNCIA AOS DESENVOLVEDORES
“Uma imagem vale mais que mil palavras”
MODELO
CONCEITOS BÁSICOS
Um modelo representa melhor o negócio do que vários escritos de especificação. Um
modelo oferece facilidade de comunicação entre as partes (usuário e técnico),
documentação para garantir a continuidade e apoio na implementação.
Princípios de Modelagem: Todo modelo possui um propósito e simbologia própria para
representação do negócio. Deve-se conhecer a forma de expressão do modelo para que
a comunicação seja estabelecida corretamente e a leitura seja fiel ao contexto
apresentado.
Atividades de Análise e Projeto: As atividades de análise e projeto de sistema
compreende das disciplinas aplicadas na Engenharia de Sw: Gerência de projetos,
Levantamento de requisitos, análise, projeto, implementação, teste, implantação. É
importante que sejam conhecidas para verificar o modelo a ser usado em cada uma.
Análise e Projeto Orientados a Objeto: A análise e projeto Orientadosa objeto utilizam
as mesmas disciplinas. A diferença acontece na estrutura da programação e análise.
ENGENHARIA DE SOFTWARE
Pressman (2011)
• Software de sistema: atender às necessidades de outros programas;
• Software de aplicação: solucionar necessidades específicas de negócio (atividade fim);
• Software científico ou de engenharia: algoritmos que visam processamento numérico pesado (custoso
computacionalmente), utilizado em diversas áreas de pesquisa e simulações;
• Software embutido: programas que residem em um produto ou sistema, utilizados para controlar as atividades do
equipamento, como o software que controla o funcionamento de um ar condicionado digital.
• Software para linha de produtos: também conhecido como softwares generalistas ou de prateleira, são programas que
podem suprir as necessidades de diversos clientes diferentes, por exemplo, softwares de criação de planilhas eletrônicas,
editores de textos, entre outros;
• Aplicações para a web: também conhecidas como “WebApps”, são programas que são executados em um servidor
conectado à rede e que pode ser acessado e utilizado por diferentes usuários, desde que possuam acesso;
• Software de inteligência artificial: algoritmos não numéricos utilizados para a resolução de problemas complexos, com
aplicações em redes neurais artificiais, robótica, jogos, entre outras.
ENGENHARIA DE SOFTWARE
Dependência tecnológica das empresas
Redução de custos com manutenção e erros
Produzir software de qualidade
Segundo Sommerville (2007) define o termo “engenharia de
software” como:
“Uma disciplina de engenharia relacionada com todos os
aspectos da produção de software, desde os estágios iniciais de
especificação do sistema até sua manutenção, depois que este
entrar em operação”.
PROCESSO DE SOFTWARE O QUE É?
Atividades:
• Comunicação: visa a compreensão dos objetivos dos interessados, definindo os requisitos
para o desenvolvimento do produto;
• Planejamento: tem como objetivo a criação de um mapa (também conhecido como plano de
projeto de software) que contém a descrição das tarefas, possíveis riscos, cronograma de
execução, os recursos demandados e o resultado esperado;
• Modelagem: criação de modelos (esboços) para representar o produto que deseja
desenvolver, fazendo assim com que as necessidades do produto final possam ser melhor
entendidas e o projeto de software possa ser melhor definido antes do início do
desenvolvimento, reduzindo assim os custos de mudanças (quanto mais cedo se identificar
uma mudança, menor o custo de reparo);
• Construção: desenvolvimento do código do software, assim como o teste dos mesmos;
• Emprego: entrega do produto ao cliente, seja este totalmente finalizado ou parcial.
Processo de Software
Disciplinas de Engenharia envolvidas no processo de software:
• Gerência de projeto: planejamento das funções a serem executadas;
• Levantamento de requisitos: levantar conhecimento sobre o negócio do cliente, identificando suas necessidades;
• Análise: detalhamento dos requisitos e definição lógica dos procedimentos;
• Projeto: definição física dos procedimentos, inclusive abrangendo os recursos tecnológicos a serem utilizados;
• Implementação: construção do sistema (códigos);
• Teste: validação do sistema, verificando se os requisitos levantados foram devidamente desenvolvidos, se atendem às
expectativas do cliente e se o sistema funciona sem erros;
• Implantação: disponibilizar o produto ao cliente (usuário), inclusive treinamentos e carga de dados;
• Manutenção: efetuar os ajustes necessários em caso de erros no programa, no levantamento de requisitos ou até mesmo no
desenvolvimento de novas funcionalidades, conforme necessidade do cliente; e a
• Qualidade: efetuar medidas para a verificação e busca pela excelência do sistema.
EVOLUÇÃO DA ENGENHARIA DE SW
Criação do HW
Desenvolvimento 
imediatista
Procura maior 
do que a oferta
Insatisfação dos 
usuários
Engenharia de SW
Como tudo começou...
EVOLUÇÃO DA ENGENHARIA DE SW
Por que surgiu?
Para instituir padronização na forma de desenvolvimento de softwares, pois era
desenvolvido de forma imediatista, baseado no conhecimento dos técnicos, sem
garantia de continuidade.
O que é?
É a definição de métodos, técnicas e ferramentas que devem ser aplicados para
ordenar o desenvolvimento e se obter maior qualidade.
EVOLUÇÃO DA ENGENHARIA DE SW
Para isso definiram as disciplinas e os ciclos de vida.
Disciplinas são as atividades necessárias para realizar o desenvolvimento.
Gerência de Projeto, Levantamento de Requisitos, Análise, Projeto,
Implementação, Teste, Implantação, Manutenção e Qualidade.
Ciclo de vida define a fase necessária para realizar o desenvolvimento.
Cascata, Prototipagem,
Espiral, Iterativo e Incremental.
EVOLUÇÃO DA ENGENHARIA DE SW
Disciplinas
Gerência de Projeto
• Planejamento das funções a serem desenvolvidas;
• Controle para acompanhar se o planejado está de acordo com o
executado.
Levantamento de Requisitos
• Conhece o negócio do usuário;
• Identifica as necessidades do usuário, sejam elas funcionais ou não
funcionais.
EVOLUÇÃO DA ENGENHARIA DE SW
Disciplinas
Análise
Realiza o detalhamento dos requisitos.
Define os procedimentos dentro de uma visão lógica.
Projeto
Define os procedimentos dentro de uma visão física, desenhando as telas,
propondo a navegação e inserindo os recursos tecnológicos necessários
para melhor atender aos usuários.
EVOLUÇÃO DA ENGENHARIA DE SW
Disciplinas
Implementação
Construção do sistema – desenvolvimento dos programas.
Teste
Validação e verificação dos resultados obtidos. Não basta somente estar
correto, livre de erros, é preciso atender às expectativas e necessidades
do usuário.
EVOLUÇÃO DA ENGENHARIA DE SW
Disciplinas
Implantação
Tornar disponível o produto ao usuário. Nesta disciplina são realizados os
treinamentos e carga dos dados.
Manutenção
Realizar ajustes por: Erro de construção; Erro de levantamento de
requisitos; Novas necessidade.
EVOLUÇÃO DA ENGENHARIA DE SW
Disciplinas
Qualidade
Adoção de métricas para apuração de medidas que busquem a excelência
do produto.
Esta disciplina atualmente é uma tarefa prioritária nas empresas.
EVOLUÇÃO DA ENGENHARIA DE SW
Ciclo de vida
Cascata
 Dividido em 5 etapas: Levantamento de requisitos, Análise, Projeto,
Implementação, Teste e Implantação.
 Cada etapa só inicia com o término da anterior;
 A entrega é realizada quando totalmente finalizado;
 Vulnerável a mudança de requisito;
 Fácil gerência.
EVOLUÇÃO DA ENGENHARIA DE SW
Ciclo de vida
Prototipagem
 Usuário recebe produto antecipadamente, mas muitas vezes incompletos;
 Gera insatisfação;
 Gera retrabalho;
 Utilizados como experiência;
 Aplicados a validação.
Prototipagem
Coleta de 
Requisitos
Projeto 
Rápido
Construção 
do protótipo
Avaliação 
do protótipo
Refinamento 
do protótipo
Engenharia 
do produto
Modelo de Ciclo Vida de Prototipação 
(adaptado de PRESSMAN 1992)
EVOLUÇÃO DA ENGENHARIA DE SW
Ciclo de vida
Espiral
 Desenvolvimento em partes;
 Possui quatro atividades: planejamento, análise de riscos, engenharia e
avaliação do usuário;
 Controle difícil;
 Requer uma boa análise de risco;
 Faltou cultura e conhecimento na adoção;
 Altamente dependente da Tecnologia.
EVOLUÇÃO DA ENGENHARIA DE SW
Ciclo de vida
Iterativo e Incremental
 Baseado no modelo espiral;
 Desenvolvimento em partes;
 Possui quatro etapas: concepção, elaboração, construção e transição,
utilizando as disciplinas;
 Controle difícil;
 Fácil para mudança de requisito;
 Entregas parciais;
CONCEITOS BÁSICOS
MODELO:
◦Simplificação ou representação da realidade, modelamosdados, funções e comportamentos
Objetivos da modelagem:
◦Compreender melhor o sistema em desenvolvimento
◦Visualizar o sistema
◦Documentar as decisões tomadas
◦Especificar comportamento ou a estrutura do sistema
PRINCÍPIOS BÁSICOS DA MODELAGEM
A escolha do modelo é determinada de acordo com sua
finalidade de acordo com a forma como um problema é
visto e como uma solução é definida
Cada modelo poderá ser expresso em diferentes níveis de
precisão
Os melhores modelos estão relacionados a realidade
Nenhum modelo único é suficiente o ideal é que existam
outros modelos para explanar melhor o contexto
IMPORTÂNCIA DA MODELAGEM
Facilita a tomada de decisões quanto à abordagem a ser
utilizada na RESOLUÇÃO de problemas com o uso de
SOFTWARE
A UML
Diagrama de Componente
Diagrama de Sequência
Diagrama de Implantação
Diagrama de Classe de Projeto
Diagrama de Estado
Diagrama de Atividade
Análise de Viabilidade
Diagrama de Classe
Diagrama de Colaboração
Caso de Uso
NewState
VENDIDO
DISPONÍVEL
MANUTENÇÃO
ALUGADA REVISÃO
DISPONÍVEL
MANUTENÇÃO
ALUGADA REVISÃO
/ALUGAR 
CARRO
 / DEVOLVER 
CARRO
 / CADASTRAR 
SITUAÇÃO
/CADASTRAR SITUAÇÃO
/CADASTRAR 
SITUAÇÃO
NewState3
:FORM : CLIENTE:CARRO :ALUGUEL
 : Administração
LER()
LER()
INCLUIR()
[CARRO DISPONÍVEL & CLIENTE 
SEM REGISTRO DE LISTA NEGRA]
VERIFICAR LISTA NEGRA()
INFORMAR DADOS 
PESSOAIS E CARRO
LANÇAMENTO DE 
NOTAS
ALUNOS
PROFESSORES
TURMAS Placa
Cor
Modelo
CLIENTE
Código
Nome
e-mail
VEÍCULOS
LER()
LER()
GARÇON COZINHA
ANOTA PEDIDO
ELABORAR 
COMIDA
GERENTE DE 
TRANSAÇÃO
:FORM
2: LER
1: INFORMA 
DATA VALIDADE
:CARDÁPIO
3: INCLUIR
4: OBTER 
(CARDAPIO)
O NEGÓCIO
Modelos
A UML
Não se utiliza obrigatoriamente 
todos os modelos em todos os projetos.
Deve-se utilizar o que melhor 
representar o contexto do negócio.
Levantamento de requisitos
É a etapa de compreensão do problema aplicada ao
desenvolvimento de software.
O principal objetivo do levantamento de requisitos é que o
usuários e desenvolvedores tenha a mesma visão do
problema a ser resolvido
Nessa etapa, os desenvolvedores, juntamente dos clientes,
tentam levantar e definir as necessidades dos futuros
usuários do sistema a ser desenvolvido(requisitos)
Requisitos funcionais
Definem as funcionalidades do sistemas
◦“o sistema deve permitir que cada professor realize o
lançamento de notas das turmas nas quais lecionou”
◦“o sistema deve permitir que um aluno realize sua
matrícula nas disciplinas oferecidas em um semestre
letivo”
◦“os coordenadores de escola devem poder obter o
número de aprovações, reprovações e trancamentos em
cada disciplina oferecida em um determinado período”
Requisitos não-funcionais
Declaram características de qualidade que o sistema deve
possuir e que estão relacionadas às suas funcionalidades
◦ Confiabilidade: tempo médio entre falhas, recuperação de
falhas
◦ Desempenho: tempos de resposta esperados
◦ Portabilidade: restrições as plataformas de hw
◦ Segurança: restrições do sistema em relação a acessos não-
autorizados
◦ Usabilidade: facilidade de uso, necessidade ou não de
treinamento dos usuários
Requisitos normativos
Declaração de restrições impostas sobre o desenvolvimento
do sistema como adequação a prazos, custos, plataforma
tecnológica, aspectos legais, regras de negócio, políticas de
funcionamento específicas do domínio do problema
Análise
Corresponde a quebrar o sistema em seus componentes e
estudar como tais componentes interagem com o objetivo
de entender como esse sistema funciona
Os modelos construídos na fase de análise devem ser
cuidadosamente validados e verificados, através da
validação e verificação dos modelos, respectivamente
DIAGRAMA DE CASO DE USO
Modelo aplicado para representar os requisitos de sistema.
O que são requisitos?
São as necessidades dos usuários, as funcionalidades necessárias para
realizar o negócio.
Quais são os tipos?
Funcionais: ligados a produção da aplicação.
Não-funcionais: necessidades de ambiente e estrutura operacional
(operacionalidade, ambiente operacional, etc.);
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
Nome caso de uso
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
Nome caso de uso
Deve:
• ser identificado por verbo, pois tem a
conotação de ação;
• ter o significado claro traduzindo facilmente a
necessidade;
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
Nome caso de uso
Exemplo
Vender Produto
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
ATOR é a representação do responsável por realizar o
caso de uso.
Nome ator
Nome caso de uso
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
ATOR é a representação do responsável por realizar o
caso de uso.
Nome ator
Nome caso de uso
Podem ser: 
• Pessoas, Setores, órgãos
governamentais, e etc.
• Outros Sistemas.
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
ATOR é a representação do responsável por realizar o
caso de uso.
Nome ator
Nome caso de uso
Exemplo 
Vendedor
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
ATOR é a representação do responsável por realizar o
caso de uso.
INTERAÇÃO CASO DE USO-ATOR representa a
realização.
Nome ator
Nome caso de uso
Nome caso de uso
Nome ator
Simbologia
DIAGRAMA DE CASO DE USO
CASO DE USO é a representação dos requisitos de
sistema.
ATOR é a representação do responsável por realizar o
caso de uso.
INTERAÇÃO CASO DE USO-ATOR representa a
realização.
Nome ator
Nome caso de uso
Nome caso de uso
Nome ator
Exemplo 
Vendedor
Vender Produto
Simbologia
DIAGRAMA DE CASO DE USO
<include> estabelece a ligação obrigatória entre os casos de uso. SEMPRE o
caso de uso será executado.
INTERAÇÃO Caso de Uso – Caso de Uso
Simbologia
DIAGRAMA DE CASO DE USO
<include> estabelece a ligação obrigatória entre os casos de uso. SEMPRE o
caso de uso será executado.
INTERAÇÃO Caso de Uso – Caso de Uso
Vendedor
Vender Produto
<include>
Emitir Nota Fiscal
Simbologia
DIAGRAMA DE CASO DE USO
<include> estabelece a ligação obrigatória entre os casos de uso. SEMPRE o
caso de uso será executado.
INTERAÇÃO Caso de Uso – Caso de Uso
<extend> estabelece a ligação opcional entre os casos de uso. O caso de uso
será executado em atendimento a uma regra de negócio.
Vendedor
Vender Produto
<include>
Emitir Nota Fiscal
Simbologia
DIAGRAMA DE CASO DE USO
<include> estabelece a ligação obrigatória entre os casos de uso. SEMPRE o
caso de uso será executado.
INTERAÇÃO Caso de Uso – Caso de Uso
<extend> estabelece a ligação opcional entre os casos de uso. O caso de uso
será executado em atendimento a uma regra de negócio.
Vendedor
Vender Produto
<include>
Emitir Nota Fiscal
Cadastrar Cliente
<extend>
Simbologia
DIAGRAMA DE CASO DE USO
Representa a classificação de um determinado ator.
Deve ser usada quando:
Temos mais de um ator realizando a mesma tarefa e, algumas tarefas 
diferenciadas.
Funcionário
Vendedor Gerente
Simbologia
GENERALIZAÇÃO DE ATOR
DIAGRAMA DE CASO DE USO
Simbologia
GENERALIZAÇÃO DE ATOR
Representa a classificação de um determinado ator.
Deve ser usada quando:
Temos mais de um ator realizandoa mesma tarefa e, algumas tarefas 
diferenciadas.
Funcionário
Vendedor Gerente
Vender Produto
<include>
Emitir Nota FiscalCadastrar Cliente
<extend>
Autorizar 
pagamento 
comissão
DIAGRAMA DE CASO DE USO
Concentra em um caso de uso um conjunto de procedimentos que serão
utilizados por vários outros casos de uso que possuem outras particularidades.
Simbologia
GENERALIZAÇÃO DE CASO DE USO
ATENDENTE 
GRADUAÇÃO
Cadastrar Alunos 
Graduação
ATENDENTE 
MESTRADO
Registrar 
Alunos
Cadastrar Alunos 
Mestrado 
FIM