COMPILADO Modelagem de Sistemas COMPLETO AULAS RESUMOS REVISAO PROVAS AV1 AV2 AV3 SaibaMais EXTRAS Graduacao Dados Programacao Gestao Tecnologia da Informacao

Prévia do material em texto

MODELAGEM DE SISTEMAS – AULA01
APRESENTAÇÃO – CLAUDIA ABREU PAES
Rio de Janeiro, 01 de AGOSTO de 2011.
SUMÁRIO
1. Objetivo da disciplina
2. Apresentação da Metodologia de trabalho
3. Evolução da Engenharia de Sw
4. Produzir modelos é bom?
OBJETIVO
• Conhecer a metodologia da disciplina.
• Conhecer os recursos utilizados durante o semestre.
• Conhecer o mapa conceitual, demonstrando o 
relacionamento entre os assuntos que serão 
abordados.
• Conhecer a evolução da Engenharia de SW.
• Reconhecer a importância do uso da modelagem para 
desenvolvimento das atividades de análise e projeto.
METODOLOGIA DE DESENVOLVIMENTO DA 
DISCIPLINA
A modalidade implica em ....
✓ Flexibilidade
✓ Autonomia
✓ Disciplina
METODOLOGIA APLICADA A DISCIPLINA
Forma de trabalho
✓ Estabeleça um horário semanal para dedicação, mas
tente entrar todos os dias para participar das
novidades.
✓ Aulas disponibilizadas semanalmente: leia os
conteúdos e realize as atividades sugeridas.
✓ Participação nos fóruns é fundamental!
✓ Direcione as dúvidas em locais apropriados e
específico ao professor em questão.
METODOLOGIA DE DESENVOLVIMENTO DA 
DISCIPLINA
Cálculo das avaliações
São disponibilizadas 3 avaliações.
Média final será calculada com as duas maiores notas e
não devem ser inferior a 4.0.
Não é obrigatória a realização das 3 provas!
RECURSOS UTILIZADOS
Plano de ensino: documento que apresenta os tópicos
designados ao desenvolvimento da disciplina;
Mapa conceitual: Representação gráfica da estrutura de
ligação dos conceitos.
Atividade estruturada: Exercício proposto para construção
de conhecimento, com autonomia e orientação do
professor, privilegiando a articulação entre a teoria e a
prática, a reflexão crítica e o processo de auto-
aprendizagem.
MAPA CONCEITUAL
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 o faseamento necessário 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(def. do Escopo)
• 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 de
Desenvolvimento de Software(Levantamento de
requisitos, Análise, Projeto, Implementação, Teste
e Implantação);
✓ Controle difícil;
✓ Fácil para mudança de requisito;
✓ Entregas parciais;
EVOLUÇÃO DA ENGENHARIA DE SW
setorial
integrado
compartilhado
centralizado
Visão Resultados...
CONCEITOS BÁSICOS DE MODELAGEM
A Importância da Modelagem
É comum ouvir dizer que “Uma imagem vale mais que mil
palavras”. Em desenvolvimento de sistemas não podia ser
diferente. 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(muito
importante) e,
✓ apoio na implementação.
CONCEITOS BÁSICOS DE MODELAGEM
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.
CONCEITOS BÁSICOS DE MODELAGEM
Próxima aula
Será apresentada a UML (Unified Modelling Language),
linguagem de representação utilizada no desenvolvimento
de softwares e, seus modelos que serão conhecidos no
escopo desta disciplina.
MODELAGEM DE SISTEMAS – AULA02
UML – CASO DE USO – CLAUDIA ABREU PAES
Rio de Janeiro, 01 de AGOSTO de 2011.
SUMÁRIO
1. A UML
1.1 Conceitos e Representações
2. Diagrama de Caso de Uso
2.1 Conceito
2.2 Simbologia
2.3 Exemplo
A UML
UML (Unified Modelling Language)
✓ Linguagem de modelagem que irá se associar ao processo
para formar método.
✓ Representação desenvolvida a partir da aplicação de técnicas
com características próprias para atender a natureza da
aplicação em estudo.
✓ Técnicas possuem uma comunicação direta e se completam.
Para utilizar a UML deve-se quebrar paradigmas e ter uma
visão sistêmica e funcional abrangente.
A UML
Aplicação
A UML foi definida para ser utilizada na Metodologia
Orientada a Objetos, o que significa que ela possui recursos
para representação dos conceitos propostos pela
metodologia.
É possível utilizar em outras metodologias!!!!
Objetivo
Ser independente da linguagem de programação e
processo de desenvolvimento.
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álisede 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
:FOR
M
2: LER
1: 
INFORMA 
DATA 
VALIDADE
:CARDÁPIO
3: 
INCLUIR 4: OBTER 
(CARDAPI
O)
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.
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 realizando a mesma tarefa e, 
algumas tarefas diferenciadas.
Funcionário
Vendedor Gerente
Vender 
Produto
<include>
Emitir Nota 
Fiscal
Cadastrar 
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 
APLICAÇÃO PRÁTICA
Passos para construção:
1. Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os
requisitos;
2. Crie uma lista de atores e requisitos;
3. Inicie a construção do modelo verificando quem é o
responsável por realizá-lo: ator ou outro caso de
uso.
4. Sendo o ator: represente o modelo.
5. Sendo outro caso de uso verifique se essa
interação é de <include> ou <extend>.
6. Verifique se existe generalização.
Vamos lá!
ESTUDO DE CASO
Estacionamento “Praça da Estácio”
Diariamente o estacionamento “Praça da Estácio” recebe vários clientes
para aluguel de suas vagas e possui uma rotina destinada ao bom
atendimento.
O gerente do estacionamento cadastra todas as vagas com sua devida
localização e situação. No caso de algum impedimento, goteira e obra,
por exemplo, as vagas são interditadas para uso.
O veículo é identificado (Placa, Cor e modelo) na entrada e registrado
pelo atendente, que emite um comprovante e cadastra o cliente que for
recebido pela 1ª vez. A locação da vaga registra data e hora de entrada,
identifica o manobrista e atendente e, bloqueia a vaga.
ESTUDO DE CASO
Estacionamento “Praça da Estácio”
A liberação é efetivada a partir da solicitação do cliente, que entrega ao
atendente o seu comprovante de locação, realiza o pagamento e recebe
uma autorização de saída. São registradas data e hora de saída e a
vaga é liberada para um próximo cliente.
O manobrista retira o carro da vaga e entrega-o ao cliente.
UML
Próxima aula
Será apresentada a ferramenta astah* para criação dos
modelos e desenvolvido o exercício a partir do estudo de caso
“Sistema de Gestão de Hotel Estacio”.
Não deixem de fazer até lá para que possam
acompanhar!!!
MODELAGEM DE SISTEMAS – AULA03
CASO DE USO: PRÁTICA – CLAUDIA ABREU PAES
SUMÁRIO
1. Apresentação ferramenta astah*
2. Aplicação prática: Caso de Uso
1. APRESENTAÇÃO FERRAMENTA astah
Para baixar:
http://astah.change-vision.com/en/product.html
Escolha a versão Community: Best for educational use
Instale e execute
http://astah.change-vision.com/en/product.html
Tela de apresentação
1. APRESENTAÇÃO FERRAMENTA astah
Clique em Novo para iniciar o 
trabalho.
1. APRESENTAÇÃO FERRAMENTA astah
1. APRESENTAÇÃO FERRAMENTA astah
Clique em Diagram para 
escolher o modelo para 
construção.
1. APRESENTAÇÃO FERRAMENTA astah
1. APRESENTAÇÃO FERRAMENTA astah
Escolha o modelo para 
construção.
1. APRESENTAÇÃO FERRAMENTA astah
1. APRESENTAÇÃO FERRAMENTA astah
Escolha o símbolo 
correspondente ao conceito 
que desejar representar.
1. APRESENTAÇÃO FERRAMENTA astah
Para utilizá-lo,clique 
no símbolo
1. APRESENTAÇÃO FERRAMENTAastah
Em seguida clique no 
espaço em branco.
1. APRESENTAÇÃO FERRAMENTA astah
Digite o nome do 
elemento.
1. APRESENTAÇÃO FERRAMENTA astah
Caso de uso.
1. APRESENTAÇÃO FERRAMENTA astah
Iteração caso de uso -
ator.
1. APRESENTAÇÃO FERRAMENTA astah
Iteração Caso de uso-
Caso de uso: Include.
1. APRESENTAÇÃO FERRAMENTA astah
Iteração Caso de uso-
Caso de uso: Extend.
1. APRESENTAÇÃO FERRAMENTA astah
Generalização
1. APRESENTAÇÃO FERRAMENTA astah
2. APLICAÇÃO PRÁTICA: CASO DE USO
Passos para construção:
1. Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os
requisitos;
2. Crie uma lista de atores e requisitos;
3. Inicie a construção do modelo verificando quem é o
responsável por realizá-lo: ator ou outro caso de
uso.
4. Sendo o ator: represente o modelo.
5. Sendo outro caso de uso verifique se essa
interação é de <include> ou <extend>.
6. Verifique se existe generalização.
Vamos lá!
2. APLICAÇÃO PRÁTICA: CASO DE USO
Passos para construção:
1. Leia atentamente o estudo de caso e identifique
os requisitos e os responsáveis por realizar os
requisitos;
Sistema de Gestão de Hotel Estacio
O cadastro do hospede (nome, procedência, endereço,
contato, previsão de permanência) é realizado pelo setor
de recepção que também controla a alocação de
quarto/apartamento (número do quarto ou apartamento) e
abertura de uma conta corrente para o hospede (senha,
número da conta, nome do hospede).
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
Ao setor de serviço de copa cabe a responsabilidade pelos
lançamentos, na conta do hospede, das despesas que o
mesmo efetuar com bebidas e comidas (data, tipo da
despesa e valor). A atendente de telefonia é responsável
pelo lançamento, na conta do cliente, das chamadas
interurbanas que o mesmo venha a fazer (data, local
chamado, duração e tarifa). As chamadas locais não são
computadas. O setor de lavanderia é responsável pelos
lançamentos, na conta do hospede, dos serviços que o
mesmo venha a solicitar àquele setor (data, tipo de serviço,
valor).
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
A gerência pode, a qualquer instante, ter acesso às
informações de cadastro e gastos realizados pelo hospede.
A gerência é responsável pelo cadastro e atualização das
tabelas de serviços, menus e diárias.
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
O hospede pode a qualquer instante consultar o saldo de
sua conta.
O setor de recepção é responsável pela extração do extrato
final da conta e fechamento da mesma quando o hospede
finaliza sua estadia.
2. APLICAÇÃO PRÁTICA: CASO DE USO
Passos para construção:
1. Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os
requisitos;
2. Crie uma lista de atores e requisitos;
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
O cadastro do hospede (nome, procedência, endereço,
contato, previsão de permanência) é realizado pelo setor
de recepção que também controla a alocação de
quarto/apartamento (número do quarto ou apartamento)
e abertura de uma conta corrente para o hospede (senha,
número da conta, nome do hospede).
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
Ao setor de serviço de copa cabe a responsabilidade pelos
lançamentos, na conta do hospede, das despesas que o
mesmo efetuar com bebidas e comidas (data, tipo da
despesa e valor). A atendente de telefonia é responsável
pelo lançamento, na conta do cliente, das chamadas
interurbanas que o mesmo venha a fazer (data, local
chamado, duração e tarifa). As chamadas locais não são
computadas. O setor de lavanderia é responsável pelos
lançamentos, na conta do hospede, dos serviços que o
mesmo venha a solicitar àquele setor (data, tipo de
serviço, valor).
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
A gerência pode, a qualquer instante, ter acesso às
informações de cadastro e gastos realizados pelo hospede.
A gerência é responsável pelo cadastro e atualização das
tabelas de serviços, menus e diárias.
2. APLICAÇÃO PRÁTICA: CASO DE USO
Sistema de Gestão de Hotel Estacio
...
O hospede pode a qualquer instante consultar o saldo de sua
conta.
O setor de recepção é responsável pela extração do extrato
final da conta e fechamento da mesma quando o hospede
finaliza sua estadia.
2. APLICAÇÃO PRÁTICA: CASO DE USO
Passos para construção:
1. Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os
requisitos;
2. Crie uma lista de atores e requisitos;
3. Inicie a construção do modelo verificando quem
é o responsável por realizá-lo: ator ou outro
caso de uso.
4. Sendo o ator: represente o modelo.
5. Sendo outro caso de uso verifique se essa
interação é de <include> ou <extend>.
2. APLICAÇÃO PRÁTICA: CASO DE USO
2. APLICAÇÃO PRÁTICA: CASO DE USO
Passos para construção:
1. Leia atentamente o estudo de caso e identifique os
requisitos e os responsáveis por realizar os
requisitos;
2. Crie uma lista de atores e requisitos;
3. Inicie a construção do modelo verificando quem é o
responsável por realizá-lo: ator ou outro caso de
uso.
4. Sendo o ator: represente o modelo.
5. Sendo outro caso de uso verifique se essa
interação é de <include> ou <extend>.
6. Verifique se existe generalização.
2. APLICAÇÃO PRÁTICA: CASO DE USO
2. APLICAÇÃO PRÁTICA: CASO DE USO
PRÓXIMA AULA
Será apresentado o segundo modelo proposto na UML: o
Diagrama de Classe.
Vamos conhecer a simbologia e a aplicação.
MODELAGEM DE SISTEMAS – AULA04
DIAGRAMA DE CLASSE– CLAUDIA ABREU PAES
SUMÁRIO
1. Diagrama de Classe
1.1 Conceito
1.2 Simbologia
1.3 Exemplo
DIAGRAMA DE CLASSE
Modelo aplicado para representar as informações
necessárias para realização das funcionalidades do sistema
em estudo a partir do conceito de CLASSE.
Exemplo:
O que é CLASSE?
DIAGRAMA DE CLASSE
Antes é preciso saber o que é OBJETO.
Exemplo: Em um negócio de vendas, quais os elementos
movimentam a execução do negócio?
CLIENTE?
DIAGRAMA DE CLASSE
Antes é preciso saber o que OBJETO.
Exemplo: Em um negócio de vendas, quais os elementos
movimentam a execução do negócio?
CLIENTE?
PRODUTO?
DIAGRAMA DE CLASSE
Antes é preciso saber o que OBJETO.
Exemplo: Em um negócio de vendas, quais os elementos
movimentam a execução do negócio?
CLIENTE?
PRODUTO?
VENDA?
DIAGRAMA DE CLASSE
Antes é preciso saber o que OBJETO.
Exemplo: Em um negócio de vendas, quais os elementos
movimentam a execução do negócio?
CLIENTE?
PRODUTO?
VENDA?
SIM!!!
SÃO OBJETOS 
DO NEGÓCIO.
DIAGRAMA DE CLASSE
Então ...
OBJETO: todo elemento que representa ou compõe algum
conceito dentro de nosso projeto.
CLASSE: conjunto de objetos com atributos e comportamentos
representados por métodos. Ex.: Classe CLIENTES representa
todos os clientes da empresa.
ATRIBUTO: característica ou identificação do objeto. Ex.: nome, 
cpf, email, ...
MÉTODOS: operações realizadas para um objeto. Ex.: lerNome()
CLASSE é a representação dos dados do sistema.
Simbologia
Para identificar uma classe devemos 
analisar se o objeto:
• possui vida própria;
• possui mais de um atributo;
• deseja-se acompanhar existência;
DIAGRAMA DE CLASSE
Simbologia
Nome da classe: deve
representar o conjunto.
DIAGRAMA DE CLASSE
CLASSE é a representação dos requisitos de sistema.
Simbologia
Nome da classe: deve
representar o conjunto.
Atributos: característica
ou identificação do
objeto.
DIAGRAMA DE CLASSE
CLASSE é a representação dos requisitos de sistema.
Simbologia
Nome da classe: deve
representar o conjunto.
Atributos: característica
ou identificação do
objeto.
Métodos: operações realizadas
para objeto da classe.
DIAGRAMA DE CLASSE
CLASSE é a representação dos requisitos de sistema.
ASSOCIAÇÃO ligação estabelecida entre as classes, por
necessidade de comportamentos do negócio analisado.Simbologia
DIAGRAMA DE CLASSE
ASSOCIAÇÃO ligação estabelecida entre as classes, por
necessidade de comportamentos do negócio analisado.
Simbologia
PAPEL nome da associação, tornando claro no diagrama
o ligação estabelecida.
DIAGRAMA DE CLASSE
ASSOCIAÇÃO ligação estabelecida entre as classes, por
necessidade de comportamentos do negócio analisado.
Simbologia
PAPEL nome da associação, tornando claro no diagrama
o ligação estabelecida.
MULTIPLICIDADE define o número de vezes em que o
objeto participa da associação.
DIAGRAMA DE CLASSE
Simbologia
MULTIPLICIDADE
Deve ser representada utilizando os dois sentidos de
leitura, sempre associado a um objeto com o resultado na
outra classe e levando em consideração os
comportamentos desejados do negócio que está sendo
analisado.
DIAGRAMA DE CLASSE
Simbologia
MULTIPLICIDADE
A representação de multiplicidade possui o seguinte
esquema:
Li ... Ls, onde: Li define o Limite inferior
Ls define o Limite superior
Li e Ls poderão ter valores numéricos de 0 a n e
Ls poderá também ter a representação * que tem como
significado infinito/muitos.
DIAGRAMA DE CLASSE
Simbologia
CLASSE ASSOCIATIVA
Classe que representa os objetos resultados de uma
associação, com atributos, características e operações
próprias.
DIAGRAMA DE CLASSE
Simbologia
RESTRIÇÕES
Complementam o modelo com informações não
representadas.
DIAGRAMA DE CLASSE
Simbologia
AGREGAÇÃO POR REFERÊNCIA
Define o conceito <compõe> e associa os objetos
indicando que existe referência para várias participações.
DIAGRAMA DE CLASSE
Simbologia
AGREGAÇÃO POR VALOR
Define o conceito <estar inserido> associando os objetos
indicando que existe referência para apenas uma
participação e estabelece uma dependência entre as classes
associadas.
DIAGRAMA DE CLASSE
DIAGRAMA DE CLASSE
Passos para desenvolvimento
1. Identificar no diagrama de caso de uso os objetos que
possuem identificação própria e precisam ter essas
informações guardadas para atendimento dos requisitos
de sistema: Essas são as classes.
2. Identificar a ligação que existe entre os objetos.
3. Estabelecer as associações na melhor forma de
representação da natureza do negócio.
ESTUDO DE CASO
Estacionamento “Praça da Estácio”
Diariamente o estacionamento “Praça da Estácio” recebe vários clientes
para aluguel de suas vagas e possui uma rotina destinada ao bom
atendimento.
O gerente do estacionamento cadastra todas as vagas com sua devida
localização e situação. No caso de algum impedimento, goteira e obra,
por exemplo, as vagas são interditadas para uso.
O veículo é identificado (Placa, Cor e modelo) na entrada e registrado
pelo atendente, que emite um comprovante e cadastra o cliente que for
recebido pela 1ª vez. A locação da vaga registra data e hora de entrada,
identifica o manobrista e atendente e, bloqueia a vaga.
ESTUDO DE CASO
Estacionamento “Praça da Estácio”
A liberação é efetivada a partir da solicitação do cliente, que entrega ao
atendente o seu comprovante de locação, realiza o pagamento e recebe
uma autorização de saída. São registradas data e hora de saída e a
vaga é liberada para um próximo cliente.
O manobrista retira o carro da vaga e entrega-o ao cliente.
ESTUDO DE CASO
Próxima aula
Serão apresentados os conceitos complementares ao
diagrama de classe e a criação do modelo a partir do estudo
de caso “Sistema de Gestão de Hotel Estacio” como forma de
fixação do conteúdo.
Não deixem de fazer até lá para que possam
acompanhar!!!
DIAGRAMA DE CLASSE
MODELAGEM DE SISTEMAS – AULA05
DIAGRAMA DE CLASSE– CLAUDIA ABREU PAES
SUMÁRIO
1. Diagrama de Classe
1.1 Simbologia
1.2 Passos para construção
1.3 Aplicação prática: CLASSE
Simbologia
AUTO ASSOCIAÇÃO
Define quando um objeto de uma classe está relacionado
com outro objeto da mesma classe para atender a algum
comportamento. A multiplicidade é estabelecida
normalmente.
DIAGRAMA DE CLASSE
Simbologia
GENERALIZAÇÃO / ESPECIALIZAÇÃO
Generalização representa os vários tipos de um objeto em
uma única classe.
DIAGRAMA DE CLASSE
Simbologia
Especialização representa os vários tipos de um objeto em
uma classe distinta relacionando seus próprios atributos e
comportamentos.
Atributos e comportamentos comuns
são relacionados na classe mãe.
DIAGRAMA DE CLASSE
DIAGRAMA DE CLASSE
Passos para desenvolvimento
1º Passo - Buscar no escopo do projeto os conjuntos de objetos
que tenham identificação própria. (Analisar os casos de uso de
cadastro, por exemplo);
2º Passo - Analisar os atributos das classes para identificar
aqueles que indicam outras classes. Esta identificação gera a
associação entre as classes;
3º Passo - Buscar conjuntos de objetos inseridos no contexto do
estudo que servem para controlar e acompanhar as atividades do
projeto;
DIAGRAMA DE CLASSE
Passos para desenvolvimento
4º Passo - Relacionar atributos destas classes;
5º Passo – Criar novas classes e associações considerando as
formas normais:
Primeira Forma Normal: Uma relação está na primeira forma
normal se todos os seus atributos são monovalorados.
Segunda Forma Normal: a relação estiver na primeira forma
normal; e todos os atributos primos dependerem funcionalmente
de toda a chave primária.
Terceira Forma Normal: a relação estiver na segunda forma
normal; e todos os atributos primos dependerem não
transitivamente de toda a chave primária.
DIAGRAMA DE CLASSE
Passos para desenvolvimento
6º Passo – Criar novas classes e associações identificando
atributos que definem vários objetos da classe.
7º Passo - Definir as multiplicidades;
8º Passo - É sabido que o diagrama de classe deve dar suporte à
realização dos casos de uso. Verificar se o diagrama de classe
possui atributos para atender a todos os procedimentos. Se não
estiver, complementar o diagrama de classe.
9º Passo - O caso de uso também deverá criar e manter as
informações do diagrama de classe. Verificar se todas as classes e
atributos estão sendo contemplados na realização dos casos de
uso. Se não estiver, complementar o diagrama de caso de uso.
Sistema de Gestão de Hotel Estacio
O cadastro do hospede (nome, procedência, endereço,
contato, previsão de permanência) é realizado pelo setor
de recepção que também controla a alocação de
quarto/apartamento (número do quarto ou apartamento) e
abertura de uma conta corrente para o hospede (senha,
número da conta, nome do hospede).
APLICAÇÃO PRÁTICA: CLASSE
Sistema de Gestão de Hotel Estacio
...
Ao setor de serviço de copa cabe a responsabilidade pelos
lançamentos, na conta do hospede, das despesas que o
mesmo efetuar com bebidas e comidas (data, tipo da
despesa e valor). A atendente de telefonia é responsável
pelo lançamento, na conta do cliente, das chamadas
interurbanas que o mesmo venha a fazer (data, local
chamado, duração e tarifa). As chamadas locais não são
computadas. O setor de lavanderia é responsável pelos
lançamentos, na conta do hospede, dos serviços que o
mesmo venha a solicitar àquele setor (data, tipo de serviço,
valor).
APLICAÇÃO PRÁTICA: CLASSE
Sistema de Gestão de Hotel Estacio
...
A gerência pode, a qualquer instante, ter acesso às
informações de cadastro e gastos realizados pelo hospede.
A gerência é responsável pelo cadastro e atualização das
tabelas de serviços, menus e diárias.
APLICAÇÃO PRÁTICA: CLASSE
Sistema de Gestão de Hotel Estacio
...
O hospede pode a qualquer instante consultar o saldo de
sua conta.
O setor de recepção é responsável pela extração do extrato
final da conta e fechamento da mesma quando o hospede
finaliza sua estadia.
APLICAÇÃO PRÁTICA: CLASSE
APLICAÇÃO PRÁTICA: CLASSE
APLICAÇÃO PRÁTICA: CLASSE
APLICAÇÃO PRÁTICA 02: CLASSE
Barrichelo’s Kart
Barrichelo’s Kart é uma promotora de corridas de Kart,
localizada em um grande shopping center, na zona sul da cidade do Rio
de Janeiro.
Ao longo de seus 6 meses de operação, Barrichelo’s Kart já realizou
mais de 1.000 corridas em sua pista. Segundo o gerente da promotora,
um dos fatores que garantiu o sucesso daempresa é a manutenção de
três listas de melhores corredores. A primeira lista apresenta os
melhores corredores da semana. A segunda lista apresenta os
melhores corredores do mês. Finalmente, a terceira lista apresenta os
melhores corredores desde o início da empresa. O gerente explica que
o melhor corredor da semana recebe, como prêmio, uma corrida grátis
na semana seguinte.
APLICAÇÃO PRÁTICA 02: CLASSE
Barrichelo’s Kart
O gerente da promotora decidiu investir em um
sistema informatizado. O sistema deve controlar os
corredores, os carros que foram utilizados, o tempo de
corrida, o número de batidas e infrações, além das listas de
melhores corredores.
O sistema deve possuir um cadastro de corredores,
indicando seu nome, endereço completo, telefone de
contato, data de nascimento, peso e altura. O sistema deve
conter também um cadastro de carros que podem ser
utilizados nas corridas.
APLICAÇÃO PRÁTICA 02: CLASSE
Barrichelo’s Kart
A cada nova corrida, o sistema deve registrar seus
participantes – cada corrida pode ter até 6 participantes -,
o carro utilizado por cada participante, sua ordem de
partida, seus tempos, batidas e infrações. Ao fim de cada
corrida, o sistema deve emitir um relatório com a
classificação de cada corredor, indicando seu carro, tempo
de corrida e infrações.
APLICAÇÃO PRÁTICA 02: CLASSE
Ao fim de cada dia, o sistema deve emitir os
relatórios de melhor da semana, do mês e desde o início da
empresa. Ao fim da semana, o sistema deve selecionar o
melhor corredor da semana e enviar por email um convite
de corrida grátis.
APLICAÇÃO PRÁTICA 02: CASO DE USO
APLICAÇÃO PRÁTICA 02: CLASSE
Próxima aula
Estaremos fazendo a revisão para AV1.
DIAGRAMA DE CLASSE
MODELAGEM DE SISTEMAS – AULA06
DESCRIÇÃO DE CASO DE USO – CLAUDIA ABREU PAES
SUMÁRIO
1. Conceitos
2. Estrutura 
3. Aplicação
DESCRIÇÃO DE CASO DE USO
A Descrição de caso de uso é a representação textual dos casos
de uso. Deve ser utilizada para complementar o modelo, pois
muitas regras de negócio estão implícitas ao caso de uso. Este
recurso ajuda a validar se a compreensão dos requisitos foi
plena.
A descrição registra a funcionalidade lógica e é o documento
comprobatório de nosso levantamento, onde o usuário poderá
validar o nosso entendimento.
DESCRIÇÃO DE CASO DE USO
A descrição de caso de uso é desenvolvida para cada caso de
uso. As interações devem ser citadas na abrangência da
descrição, mas não deve definir dois casos de uso em uma só
descrição. Quanto mais clara a definição melhor o
entendimento.
ATENDENTE
Liberar Veículo
Emitir Autorização de 
saída
<usa>
DESCRIÇÃO DE CASO DE USO
A descrição poderá ser desenvolvida de duas formas:
Descrição não Expandida e Descrição Expandida.
Formação: Cabeçalho + descrição
Nome: <Nome do Caso de Uso>
C
a
b
e
ç
a
lh
o
Objetivo: Descrever o objetivo de forma sucinta
Pré-condição: Regras que devem estar cumpridas antes da realização do caso de uso.
Pós-condição: São regras cumpridas pelo caso de uso que liberam procedimentos futuros.
DESCRIÇÃO DE CASO DE USO
Descrição não Expandida prevê a apresentação sucinta dos
procedimentos, como um pequeno relato apresentando os
objetivos a serem atingidos. Deve ser utilizada quando o Caso
de Uso for de conhecimento completo de todos, não possuir
exceções ou, utilizar mecanismos de outro caso de uso.
DESCRIÇÃO DE CASO DE USO
Exemplo “Estacionamento Praça da Estácio”:
Utilizando o Caso de Uso “Emitir autorização de saída”:
Nome: Emitir Autorização de saída
Objetivo: Gerar comprovante de quitação do aluguel da vaga.
Pré-condição: estar com a locação fechada.
Pós-condição: não há
DESCRIÇÃO DE CASO DE USO
Exemplo “Estacionamento Praça da Estácio”:
Utilizando o Caso de Uso “Emitir autorização de saída”:
...
Descrição
Emitir autorização de saída, Formulário 005, a partir das
informações de fechamento de locação.
DESCRIÇÃO DE CASO DE USO
Descrição Expandida prevê a apresentação detalhada dos
procedimentos, apresentando os objetivos a serem atingidos
passo-a-passo e com referência a responsabilidade se ator ou
sistema.
Devemos considerar a descrição em duas partes: Fluxo Normal
e Fluxo Alternativo. + cabeçalho
DESCRIÇÃO DE CASO DE USO
Fluxo Normal é o passo-a-passo dos procedimentos sem desvio.
Uma lista de procedimentos considerando os passos freqüentes
e sem exceção.
Fluxo Alternativo é o passo-a-passo dos procedimentos de
exceção e condições alternativas para determinado passo do
Fluxo Normal. Não são todos os passos citados no Fluxo Normal
que terá citação no Fluxo Alternativo.
DESCRIÇÃO DE CASO DE USO
GERENTE
Atualizar
Preços
Interditar
Vagas
ATENDENTE
Liberar 
Veículo
Emitir 
Liberação 
de Veículo
Cadastrar 
Veículo
Registrar 
Locação
Emitir 
Comprovante 
de Locação
<usa>
<estende>
<usa>
Exemplo “Estacionamento Praça da Estácio”:
Utilizando o Caso de Uso “Registrar Locação”:
DESCRIÇÃO DE CASO DE USO
Na Descrição Expandida, para consumar uma descrição
consistente é necessário um projeto de interface, mesmo que
não possua todas as configurações visuais. O importante é
representarmos a funcionalidade básica e não os detalhes de
programação.
DESCRIÇÃO DE CASO DE USO
PLACA:
CLIENTE:
VAGAS:
Confirmar Cancelar

1º passo: IDEALIZAR A INTERFACE
DESCRIÇÃO DE CASO DE USO
2º passo: CABEÇALHO
NOME......... : Registrar Locação
DESCRIÇÃO.: O atendente identifica o veiculo em sua entrada no
estacionamento e cadastra sua ocupação da vaga.
Pré-Condição: Ter acesso a interface.
Pós-Condição: VAGA estará bloqueada.
DESCRIÇÃO DE CASO DE USO
FLUXO NORMAL
1. Sistema Apresenta Tela de Locação.
2. Vendedor Informa Placa de VEÍCULO.
3. Sistema obtém dados de VEÍCULO.
4. Sistema obtém dados de CLIENTE.
5. Sistema apresenta dados de CLIENTE.
6. Sistema obtém dados de VAGA.
3º passo: Descrever FLUXO NORMAL
PLACA:
CLIENTE:
VAGAS:
Confirmar Cancelar

DESCRIÇÃO DE CASO DE USO
7. Sistema apresenta lista de VAGA.
8. Vendedor escolhe VAGA.
9. Vendedor clica CONFIRMA.
10. Sistema altera VAGA.
11. Sistema Inclui “Emitir Comprovante de Locação”
12. Sistema Encerra Caso De Uso.
PLACA:
CLIENTE:
VAGAS:
Confirmar Cancelar

DESCRIÇÃO DE CASO DE USO
FLUXO ALTERNATIVO
3. Sistema obtém dados de VEÍCULO.
3.1 Não há registro de VEÍCULO
3.1.1 Sistema estende “Cadastrar Veículo”.
3.1.2 Sistema retorna para item 4.
4º passo: Descrever FLUXO ALTERNATIVO
DESCRIÇÃO DE CASO DE USO
4. Sistema obtém dados de CLIENTE.
4.1 Não há registro de CLIENTE
4.1.1 Sistema estende “Cadastrar Cliente”.
4.1.2 Sistema retorna para item 5.
5. Vendedor clica Cancela.
5.1 Sistema retorna para item 1.
4º passo: Descrever fluxo normal
DESCRIÇÃO DE CASO DE USO
OBSERVAÇÕES:
Não possuímos no nosso Diagrama o Caso de Uso
“Cadastrar Cliente”, item 4.1.1 da descrição. A
necessidade surgiu durante a especificação. Quando isto
ocorre é necessário voltarmos ao diagrama e incluir este
novo caso de uso;
Mais uma vez deve ser comentado que a cada
modelo/técnica utilizada deve-se estar pronto a
recomeçar, pois é possível sempre estar
descobrindo falhas ou complementos.
DESCRIÇÃO DE CASO DE USO
GERENTE
Atualizar
Preços
Interditar
Vagas
ATENDENTE
Liberar 
Veículo
Emitir 
Liberação de 
Veículo
Cadastrar 
Veículo
Registrar 
Locação
Emitir 
Comprovante 
de Locação
<usa>
<estende>
<usa>
Cadastrar 
Cliente
<estende>
DESCRIÇÃO DE CASO DE USO
A especificação de caso de uso também disponibiliza um recurso
para informações adicionais do tipo, vagas bloqueadas terão
código “B”. Para isto, retornamos a especificação e incluímos um
COMENTÁRIO entre asteriscos imediatamente após o passo
desejado;
Outra informação relevante para ser incluída em comentário é a
tecla utilizada para fim, quando for o caso;
...
DESCRIÇÃO DE CASO DE USO
FLUXO NORMAL
1. Sistema Apresenta Tela de Locação.
*** Para finalizar tecle <ESC> ***
2. Vendedor Informa Placa de VEÍCULO.
3. Sistema obtém dados de VEÍCULO.
4. Sistema obtém dados de CLIENTE.
5.Sistema apresenta dados de CLIENTE.
6. Sistema obtém dados de VAGA.
7. Sistema apresenta lista de VAGA.
8. Vendedor escolhe VAGA.
9. Vendedor clica CONFIRMA.
10. Sistema altera VAGA.
***----------------------------------------------------***
*** VAGA deverá ser bloqueada com status=”B” ***
***----------------------------------------------------***
11. Sistema Inclui “Emitir Comprovante de Locação”
12. Sistema Encerra Caso De Uso.
...
DESCRIÇÃO DE CASO DE USO
Portanto, deve-se preocupar em apresentar os detalhes
necessários para:
• Usuário aferir o atendimento do requisito;
• Avaliar as restrições;
• Dar segurança ao projeto no sentido do programador ter
entendimento completo;
• Documentação;
DESCRIÇÃO DE CASO DE USO
REGRAS
Para descrever um caso de uso é preciso a aplicação de regras, 
pois assim é definido um padrão de entendimento entre o 
usuário e o técnico. Dentre as regras podemos destacar: 
• Estabelecer o diálogo entre o usuário e o sistema. 
• Adotar sentenças curtas, 
• Os passos devem ser numerados, sequenciados logicamente; 
• A primeira e a última sentença são comandadas pelo sistema;
• Deve-se utilizar um padrão de linguagem;
DESCRIÇÃO DE CASO DE USO
• Descrição não representa condição e repetição;
• Descrição não representa controles técnicos (críticas, fim de 
leitura);
• Não é preciso fluxo alternativo para todas as sentenças 
relacionadas no fluxo normal. Apresentar somente quando 
necessário.
DESCRIÇÃO DE CASO DE USO
• Podem-se utilizar comentários para complementar a 
informação “*** comentários”;
• Para representar os INCLUDES utilizar <INCLUIR>;
• Para representar os EXTENDS utilizar <ESTENDER>.
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Dado o seguinte diagrama de caso de uso e diagrama de 
classe de um sistema de locação de carros. 
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Interface
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Segue a DESCRIÇÃO EXPANDIDA
Nome: Alugar Veículos
Descrição: Registra o aluguel do veículo do cliente.
Pré-condição: Veículo deve estar cadastrado e disponível
Pós-Condição: Locação definida
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Fluxo Normal:
1. Sistema apresenta tela;
2. Sistema apresenta lista de modelos;
*** Somente os disponíveis
3. Sistema apresenta lista de cor;
4. Ator escolhe modelo;
5. Sistema apresenta dados do veículo;
6. Sistema apresenta lista de Clientes;
7. Ator escolhe Nome do Cliente
8. Ator informa data de aluguel e número de dias;
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Fluxo Normal:
1. Sistema apresenta tela;
2. Sistema apresenta lista de modelos;
*** Somente os disponíveis
3. Sistema apresenta lista de cor;
4. Ator escolhe modelo;
5. Sistema apresenta dados do veículo;
6. Sistema apresenta lista de Clientes;
7. Ator escolhe Nome do Cliente
8. Ator informa data de aluguel e número de dias;
E
N
T
R
A
D
A
S
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
9. Sistema calcula data devolução;
10. Ator confirma operação;
***Clica ok
11. Sistema <inclui> “Emitir Contrato”;
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
9. Sistema calcula data devolução;
10. Ator confirma operação;
***Clica ok
11. Sistema <inclui> “Emitir Contrato”;
P
R
O
C
E
S
S
A
M
E
N
T
O
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
12. Sistema cria locação;
13. Sistema Atualiza veículo
***Situação = indisponível
14. Sistema encerra caso de uso
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
12. Sistema cria locação;
13. Sistema Atualiza veículo
***Situação = indisponível
14. Sistema encerra caso de uso
S
A
Í
D
A
S
DESCRIÇÃO DE CASO DE USO
EXERCÍCIO
Revendo os modelos já produzidos...
2. Sistema apresenta lista de modelos;
*** Somente os disponíveis
DESCRIÇÃO DE CASO DE USO
2. Sistema apresenta lista de modelos;
*** Somente os disponíveis
EXERCÍCIO
Revendo os modelos já produzidos...
DESCRIÇÃO DE CASO DE USO
2. Sistema apresenta lista de modelos;
*** Somente os disponíveis
EXERCÍCIO
Revendo os modelos já produzidos...
Próxima aula
Diagramas de Interação.
DESCRIÇÃO DE CASO DE USO
MODELAGEM DE SISTEMAS – AULA07
DIAGRAMAS DE INTERAÇÃO – CLAUDIA ABREU PAES
SUMÁRIO
1. Conceitos
2. Diagrama de Sequencia
3. Diagrama de Sequencia de Sistema
4. Diagrama de Colaboração
DIAGRAMAS DE INTERAÇÃO
Conceitos
O Diagrama de Interação apresenta a relação entre os objetos e a
troca de mensagens que são necessárias para efetivar a realização
do comportamento.
O Diagrama de Interação representa um único caso de uso e deve
ser usado quando se deseja visualizar os comportamentos
utilizados pelos vários objetos dentro do caso de uso.
Diagramas de interação são apresentados sob duas formas na
UML através do Diagrama de Seqüência e Diagrama de
Colaboração.
DIAGRAMA DE SEQÜÊNCIA
Representa a seqüência lógica dos comportamentos dentro do 
caso de uso. Portanto a leitura é realizada de cima para baixo e, 
da esquerda para direita.
Os elementos utilizados para compor o diagrama são os
seguintes:
Um diagrama de sequência para cada fluxo desenvolvido (cada 
caso de uso)
DIAGRAMAS DE INTERAÇÃO
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
GERENTE
:nome objeto
:nome objeto
Ator
Objeto
Linha da vida
“ *(asterisco) “= iteração = muitas 
representações
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
:item de 
pedido
:item de 
estoque
Retorno
Mensagem
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
Verificar ( )
:item de 
pedido
:item de 
estoque
Retorno
Método
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
Mensagens condicionais
[Tpaluno=”M”]
:objeto 1
[Tpaluno=”G”]
:objeto 2 :objeto 3
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
* Verificar ( )
:item de 
pedido
:item de 
estoque
Retorno
Iteração
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
[ Pedido Válido]
Verificar ( )
:item de 
pedido
:item de 
estoque
Retorno
Condição de guarda
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
[ Pedido Válido]
Verificar ( )
:item de 
pedido
:item de 
estoque
Retorno
Caixa de ativação
DIAGRAMA DE SEQÜÊNCIA - SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
[ Pedido Válido]
Verificar ( )
:item de 
pedido
:item de 
estoque
Retorno
Auto Delegação
Muitas interações = Auto delegação = buscar 
informações dentro do próprio objeto
FLUXO NORMAL
1. Sistema Apresenta Tela de Locação.
2. Vendedor Informa Placa de VEÍCULO.
3. Sistema obtém dados de VEÍCULO.
4. Sistema obtém dados de CLIENTE.
5. Sistema apresenta dados de CLIENTE.
6. Sistema obtém dados de VAGA.
PLACA:
CLIENTE:
VAGAS:
Confirmar Cancelar

DIAGRAMAS DE INTERAÇÃO
DIAGRAMA DE SEQÜÊNCIA – EXEMPLO
7. Sistema apresenta lista de VAGA.
8. Vendedor escolhe VAGA.
9. Vendedor clica CONFIRMA.
10. Sistema altera VAGA.
11. Sistema Inclui “Emitir Comprovante de Locação”
12. Sistema Encerra Caso De Uso.
PLACA:
CLIENTE:
VAGAS:
Confirmar Cancelar

DIAGRAMAS DE INTERAÇÃO
DIAGRAMAS DE INTERAÇÃO
DIAGRAMA DE SEQÜÊNCIA – EXEMPLO
DIAGRAMAS DE INTERAÇÃO
DIAGRAMA DE SEQÜÊNCIA DE SISTEMAS (DSS) – EXEMPLO
DIAGRAMA DE COLABORAÇÃO
Apresenta objetos e classes envolvidas no cenário e a ligação
entre eles apresentando a forma de navegação e visibilidade.
Os elementos utilizados para compor o diagrama são os
seguintes: objeto
DIAGRAMAS DE INTERAÇÃO
DIAGRAMAS DE INTERAÇÃO
:objeto1 :objeto2
:objeto1 :objeto2
mensagem() 
retorno() 
mensagem() 
Ligação
Mensagem
DIAGRAMA DE COLABORAÇÃO – SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
:objeto1 :objeto2
1:mensagem() 
2:retorno() 
mensagem() 
1. A primeira mensagem não é numerada;
2. A ordem e o alinhamento são mostrados com um esquema 
de numeração cardinal.
Sequencia
DIAGRAMA DE COLABORAÇÃO – SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
:OBJETO
2:mensagem()
1:mensagem() Auto Delegação
:OBJETO :OBJETO(new)
<<create>>
1:mensagem () 
Criação de instância
DIAGRAMA DE COLABORAÇÃO – SIMBOLOGIA
DIAGRAMASDE INTERAÇÃO
:OBJETO :OBJETO(new)
Mensagens condicionais -
Guarda
1[condição]:mensagem () 
:OBJETO :OBJETO(new)
Iteração
1:*mensagem () 
DIAGRAMA DE COLABORAÇÃO – SIMBOLOGIA
DIAGRAMAS DE INTERAÇÃO
DIAGRAMA DE COLABORAÇÃO – EXEMPLO
Todo diagrama de interação é representado 
por caso de uso
Diagrama de sequencia tem uma visão 
sequenciada, da esquerda para direita e de 
cima para baixo
Diagrama de sequencia de sistema representa 
a ligação entre o mundo externo e o sistema
O diagrama de colaboração representa a 
ligação entre os objetos, para saber qual 
objeto envia mensagem para qual, como os 
objetos interagem
A diferença básica é que no Diagrama de Sequência(visualiza as
informações) conseguimos visualizar claramente a seqüência da
troca de mensagens entre os objetos, sendo válido para avaliação
da consistência das operações e, no Diagrama de
Colaboração(visão dos métodos de uma determinada classe) esta
sequência não fica totalmente clara, mas é possível interpretar
todas as mensagens recebidas pelos objetos, sendo muito válido
para definição de parâmetros, planejamento de desenvolvimento
e outros aspectos para o projeto em si.
DIAGRAMAS DE INTERAÇÃO
Próxima aula
Aula prática:
Descrição de caso de uso e diagrama de interação.
DIAGRAMAS DE INTERAÇÃO
MODELAGEM DE SISTEMAS – AULA08
PRÁTICA DESCRIÇÃO E INTERAÇÃO – CLAUDIA ABREU PAES
SUMÁRIO
1. Apresentação Estudo de caso - Hotel
2. Descrição de caso de uso
3. Diagrama de Sequencia
4. Diagrama de Sequencia de Sistema
5. Diagrama de Colaboração
Sistema de Gestão de Hotel Estacio
O cadastro do hospede (nome, procedência, endereço,
contato, previsão de permanência) é realizado pelo setor
de recepção que também controla a alocação de
quarto/apartamento (número do quarto ou apartamento) e
abertura de uma conta corrente para o hospede (senha,
número da conta, nome do hospede).
ESTUDO DE CASO
Sistema de Gestão de Hotel Estacio
...
Ao setor de serviço de copa cabe a responsabilidade pelos
lançamentos, na conta do hospede, das despesas que o
mesmo efetuar com bebidas e comidas (data, tipo da
despesa e valor). A atendente de telefonia é responsável
pelo lançamento, na conta do cliente, das chamadas
interurbanas que o mesmo venha a fazer (data, local
chamado, duração e tarifa). As chamadas locais não são
computadas. O setor de lavanderia é responsável pelos
lançamentos, na conta do hospede, dos serviços que o
mesmo venha a solicitar àquele setor (data, tipo de serviço,
valor).
ESTUDO DE CASO
Sistema de Gestão de Hotel Estacio
...
A gerência pode, a qualquer instante, ter acesso às
informações de cadastro e gastos realizados pelo hospede.
A gerência é responsável pelo cadastro e atualização das
tabelas de serviços, menus e diárias.
ESTUDO DE CASO
Sistema de Gestão de Hotel Estacio
...
O hospede pode a qualquer instante consultar o saldo de
sua conta.
O setor de recepção é responsável pela extração do extrato
final da conta e fechamento da mesma quando o hospede
finaliza sua estadia.
ESTUDO DE CASO
ESTUDO DE CASO
Hospedar 
Cliente
ESTUDO DE CASO - DESCRIÇÃO
PASSO 1 - Definir o Cabeçalho
PASSO 1 - Definir o Cabeçalho
Nome: Hospedar cliente
Objetivo: Registrar entrada do hóspede no hotel
Pré-condição: Quartos disponíveis.
Pós-condição: Conta corrente aberta para consumo.
Autorizada permanência do cliente nas áreas do hotel.
ESTUDO DE CASO - DESCRIÇÃO
PASSO 2 - Definir a interface
ESTUDO DE CASO - DESCRIÇÃO
Hotel Estácio
HÓSPEDE
Nome: 
Endereço: Contato:
Procedência: Previsão permanência: 
HOSPEDAGEM
Quarto:
Data de chegada ____/____/____ Data de saída: ____/____/____
SAIRCONFIRMANOVO CLIENTE
PASSO 2 - Definir a interface
ESTUDO DE CASO - DESCRIÇÃO
Hotel Estácio
HÓSPEDE
Nome: 
Endereço: Contato:
Procedência: Previsão permanência: 
HOSPEDAGEM
Quarto:
Data de chegada ____/____/____ Data de saída: ____/____/____
SAIRCONFIRMANOVO CLIENTE
PASSO 3 – Identificar procedimentos fluxo normal
ESTUDO DE CASO - DESCRIÇÃO
1. Sistema Apresenta Tela de Hospedagem
2. Sistema apresenta lista de HÓSPEDES já cadastrados
3. Recepção escolhe HÓSPEDE 
4. Sistema obtém dados HÓSPEDES e apresenta informações: 
endereço e contato
5. Sistema apresenta lista de PROCEDÊNCIA cadastrada
6. Recepção escolhe PROCEDÊNCIA 
7. Recepção informa DIAS DE PERMANÊNCIA
PASSO 4 – Descrição procedimentos fluxo normal
ENTRADA
ESTUDO DE CASO - DESCRIÇÃO
8. Sistema apresenta lista de QUARTOS cadastrados e disponíveis
9. Recepção escolhe QUARTOS
10. Sistema apresenta data de chegada como a data do dia 
11.Sistema apresenta data de saída calculando a data de chegada 
acrescida dos dias de permanência
12.Recepção clica CONFIRMA
PASSO 4 – Descrição procedimentos fluxo normal
ENTRADA/PROCESSAMENTO
ESTUDO DE CASO - DESCRIÇÃO
13. Sistema <INCLUDE> “Alocar Quarto”
14. Sistema <INCLUDE> “Abrir conta corrente”
15. Sistema inclui informações de HOSPEDAGEM
16. Sistema encerra caso de uso
PASSO 4 – Descrição procedimentos fluxo normal
SAÍDAS
ESTUDO DE CASO - DESCRIÇÃO
Hotel Estácio
HÓSPEDE
Nome: 
Endereço: Contato:
Procedência: Previsão permanência: 
HOSPEDAGEM
Quarto:
Data de chegada ____/____/____ Data de saída: ____/____/____
SAIRCONFIRMANOVO CLIENTE
PASSO 5 – Identificar procedimentos fluxo Alternativo
ESTUDO DE CASO - DESCRIÇÃO
PASSO 5 – Identificar procedimentos fluxo Alternativo
1. Sistema Apresenta Tela de Hospedagem
2. Sistema apresenta lista de HÓSPEDES já cadastrados
3. Recepção escolhe HÓSPEDE 
4. Sistema obtém dados HÓSPEDES e apresenta informações: endereço e contato
5. Sistema apresenta lista de PROCEDÊNCIA cadastrada
6. Recepção escolhe PROCEDÊNCIA 
7. Recepção informa DIAS DE PERMANÊNCIA
8. Sistema apresenta lista de QUARTOS cadastrados e disponíveis
9. Recepção escolhe QUARTOS
10. Sistema apresenta data de chegada como a data do dia 
11. Sistema apresenta data de saída calculando a data de chegada acrescida dos dias de 
permanência
12.Recepção clica CONFIRMA
ESTUDO DE CASO - DESCRIÇÃO
PASSO 6 – Descrever procedimentos fluxo Alternativo
3. Recepção escolhe HÓSPEDE 
3.1 Novo hóspede
3.1.1 Recepção clica “Novo Cliente”
3.1.2 Sistema <EXTEND> “Cadastrar Hóspede”
3.1.3 Sistema retorna 4
ESTUDO DE CASO - DESCRIÇÃO
PASSO 6 – Descrever procedimentos fluxo Alternativo
3. Recepção escolhe HÓSPEDE 
3.1 Novo hóspede
3.1.1 Recepção clica “Novo Cliente”
3.1.2 Sistema <EXTEND> “Cadastrar Hóspede”
3.1.3 Sistema retorna 4
8. Sistema apresenta lista de QUARTOS cadastrados e disponíveis
8.1 Não existem quartos disponíveis
8.1.1 Sistema apresenta mensagem “Quartos indisponíveis no momento”
8.1.2 Sistema retorna 2
ESTUDO DE CASO - DESCRIÇÃO
PASSO 6 – Descrever procedimentos fluxo Alternativo
3. Recepção escolhe HÓSPEDE 
3.1 Novo hóspede
3.1.1 Recepção clica “Novo Cliente”
3.1.2 Sistema <EXTEND> “Cadastrar Hóspede”
3.1.3 Sistema retorna 4
8. Sistema apresenta lista de QUARTOS cadastrados e disponíveis
8.1 Não existem quartos disponíveis
8.1.1 Sistema apresenta mensagem “Quartos indisponíveis no momento”
8.1.2 Sistema retorna 2
12. Recepção clica CONFIRMA
12.1 Recepção desiste
12.1.1 Recepção clica SAIR
12.1.2 Sistema retorna 2
ESTUDO DE CASO - DESCRIÇÃO
DIAGRAMAS DE INTERAÇÃO
Representam a troca de mensagens entre objetos:
• Sequencia
• Sequencia de Sistemas
• Colaboração
ESTUDO DE CASO - INTERAÇÃO
ESTUDO DE CASO - SEQUENCIA
PASSO 1 – Representar os objetos e as linhas da vida
ESTUDO DE CASO - SEQUENCIA
PASSO 1 – Representar os objetos e as linhas da vida
É possível ir criando na medida 
em que os objetos vão 
aparecendo na análise do caso 
de uso.
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
1. Sistema Apresenta Tela de Hospedagem2. Sistema apresenta lista de HÓSPEDES já cadastrados
3. Recepção escolhe HÓSPEDE 
4. Sistema obtém dados HÓSPEDES e apresenta informações: 
endereço e contato
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
1. Sistema Apresenta Tela de Hospedagem
2. Sistema apresenta lista de HÓSPEDES já cadastrados
3. Recepção escolhe HÓSPEDE 
4. Sistema obtém dados HÓSPEDES e apresenta informações: endereço 
e contato
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
5. Sistema apresenta lista de PROCEDÊNCIA cadastrada
6. Recepção escolhe PROCEDÊNCIA 
7. Recepção informa DIAS DE PERMANÊNCIA
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
8. Sistema apresenta lista de QUARTOS cadastrados e disponíveis
9. Recepção escolhe QUARTOS
10. Sistema apresenta data de chegada como a data do dia 
11.Sistema apresenta data de saída calculando a data de chegada acrescida dos 
dias de permanência
12.Recepção clica CONFIRMA
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
13. Sistema <INCLUDE> “Alocar Quarto”
14. Sistema <INCLUDE> “Abrir conta corrente”
15. Sistema inclui informações de HOSPEDAGEM
16. Sistema encerra caso de uso
ESTUDO DE CASO - SEQUENCIA
PASSO 2 – A partir da descrição de caso de uso informar
mensagens
ESTUDO DE CASO - SEQUENCIA
PASSO 3 – Incluir os métodos no diagrama de caso de classe
ESTUDO DE CASO – DSS
Representa as entradas e saídas
ESTUDO DE CASO – DSS
Representa as entradas e saídas
ESTUDO DE CASO – DSS
Representa as entradas e saídas
ESTUDO DE CASO – COLABORAÇÃO
Representa troca de mensagens sem sequencia.
:formulário
escolherHosppede()
escolherProcedencia()
InformarDiasPermanencia()
clicaCONFIRMA()
:Hóspedes
4: *ler()
listaHospedes
1: apresentaInformações()
2: apresentaDataChegada()
3: calculaDataSaída ()
5: *ler()
listaProcedência
:Procedência
6: [disponíveis]*ler()
listaQuartos
:Quartos
7: Incluir()
:Hospedagem
8: <include>
alocarQuarto
9: <include>
abrirCCorrente
Próxima aula
Diagrama de Estado
Diagrama de Atividade
ESTUDO DE CASO
MODELAGEM DE SISTEMAS – AULA09
DIAGRAMA DE ESTADO E ATIVIDADE – CLAUDIA ABREU PAES
SUMÁRIO
1. Diagrama de Estado
1.1 Conceito
1.2 Simbologia
1.3 Aplicação
2. Diagrama de Atividade
2.1 Conceito
2.2 Simbologia
2.3 Aplicação
DIAGRAMA DE ESTADO
O Diagrama de Estado na UML é utilizado para apresentar
os estados, a mudança de estado e o processo que faz
mudar o estado de um Caso de Uso ou de uma Classe.
Esta é mais uma técnica para validarmos o tratamento das
restrições sistêmicas impostas pelos requisitos.
DIAGRAMA DE ESTADO
Simbologia
Início
Fim
DIAGRAMA DE ESTADO
Simbologia
Início
Estado
Fim
Posição do 
objeto após a 
ocorrência da 
transição.
DIAGRAMA DE ESTADO
Simbologia
Início
Estado
Fim
Procedimento 
desenvolvido 
até que ocorra 
a transição.
Atividade
DIAGRAMA DE ESTADO
Simbologia
Início
Estado
Ocorrência 
para mudança 
de estado.
Atividade
Transição
Fim
DIAGRAMA DE ESTADO
Simbologia
Estado
Fim
Fato ocorrido 
para provocar 
a transição
Atividade
Transição
Início
Evento
DIAGRAMA DE ESTADO
Simbologia Início
Estado
Fim
Condição lógica. 
Transição guardada 
ocorre somente se a 
guarda for “verdade”.
Atividade
Transição
Guarda
Evento
DIAGRAMA DE ESTADO
Simbologia Início
Estado
Fim
Procedimento 
responsável por 
alterar o status.
Atividade
Transição
Guarda
Evento
Ação
DIAGRAMA DE ESTADO
Simbologia – Auto transição
Quando houver uma transição que retorna ao mesmo
estado.
DIAGRAMA DE ESTADO
Simbologia – Super Estados
Quando um conjunto de atividades define ao final o mesmo
estado.
DIAGRAMA DE ESTADO
Simbologia – Estados Concorrentes
Quando um objeto de uma mesma classe pode ter mais de
um estado ao mesmo tempo para que ao final tenha um só
estado.
DIAGRAMA DE ESTADO
Diagrama de Estado – Caso de Uso
Importante para:
• Identificar o atendimento às restrições;
• Analisar a ordem das ocorrências das mudanças de
estado;
Para exemplificar podemos utilizar o Caso de Uso
“Registrar Locação”.
DIAGRAMA DE ESTADO
Diagrama de Estado – Caso de Uso
Imagine o estado do Caso de Uso a cada execução e
restrição a ser seguida e dê início a construção do
diagrama.
DIAGRAMA DE ESTADO
Diagrama de Estado – Caso de Uso
Aguardando Entrada 
Verificando cadastro 
AguardandoCadastro 
do veículo 
Entrar nova locação
Entrar informações veículo [veículo 
não cadastrado]/Cadastrar Veículo
Apresentar informações 
veículo [veículo 
cadastrado]
Cadastrando Locação 
AguardandoCadastro 
do cliente 
Aguardando 
Confirmação 
Entrar Informação 
Cliente/
Cadastrar Cliente
Finalizar Locação/
Emitir Comprovante
Confirmar Locação 
[confirma]
Apresentar informações 
veículo 
Confirmar Locação 
[cancela]
Aguardando 
Comprovante 
Liberar Estacionamento
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
Não são todas as classes que passaram por mudança de 
estado. 
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
Não são todas as classes que passaram por mudança de 
estado. 
No exemplo “Estacionamento Praça da Estacio” 
podemos observar que a classe VAGA possui mudança 
de estado e, portanto podemos construir um diagrama 
para ela:
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
Passos para construção:
1. Identifique os estados possíveis: liberada, bloqueada, 
interditada.
2. Relacione as mudanças de/para;
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
Supondo que fosse possível também o estado de
CANCELADA !!!!
Pode-se cancelar a partir do estado DISPONÍVEL ou
INTERDITADA. Como 
fazer?
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
... Ligar os dois estados a um estado de CANCELADO ...
DIAGRAMA DE ESTADO
Diagrama de Estado – Classe
... Ou representa-se um super Estado...
DIAGRAMA DE ATIVIDADE
O diagrama de atividade permite escolher a ordem pela qual
as coisas devem ser feitas, isto é, indica meramente as regras
essenciais de seqüência que necessitam ser seguidas - esse
é um aspecto fundamental para diferenciar um diagrama de
atividade de um fluxograma.
Fluxogramas são limitados a processos seqüenciais enquanto
que Diagramas de Atividade podem manipular processos
paralelos.
DIAGRAMA DE ATIVIDADE
O ponto forte do diagrama de atividade reside no fato de
suportar e encorajar comportamento paralelo, tornando-se
uma boa técnica para a modelagem de fluxo de trabalho e
programação para multiprocessamento.
Quando usar:
• Para representar o processo;
• Para representar cada Caso de Uso complexo;
DIAGRAMA DE ATIVIDADE
• Agrupam atividades relacionadas às
responsabilidades que cumprem;
• Mostrar em qual parte da
organização um trabalho é
executado;
• Mostrar explicitamente onde são
executadas ações (em qual objeto).
RAIA
DIAGRAMA DE ATIVIDADE
Representa
o início do
diagrama.
Início
DIAGRAMA DE ATIVIDADE
Início
Atividade
Tarefa que precisa
ser feita. Representa
um método sobre
uma classe.
DIAGRAMA DE ATIVIDADE
Início
Atividade
Representa comportamento
condicional que a partir de
uma única entrada poderá
gerar algumas saídas.
Decisão
DIAGRAMA DE ATIVIDADE
Início
Atividade
Representa comportamento
condicional que a partir de
várias entradas poderá
gerar apenas uma saída.
Decisão
Intercalação
DIAGRAMA DE ATIVIDADE
Início
Atividade
Transições seguintes
são efetuadas em
paralelo independente
da seqüência.
Decisão
Intercalação
Separação
DIAGRAMA DE ATIVIDADE
Início
Atividade
Decisão
Intercalação
Separação
Transição seguinte efetuada
somente quando todos os
estados nas transições de
entrada tenham completado
suas atividades.
Junção
DIAGRAMA DE ATIVIDADE
Início
Atividade
Decisão
Intercalação
Separação
Junção
Fim
DIAGRAMA DE ATIVIDADE
DIAGRAMA DE ATIVIDADEDesafio
✓ reservado
✓ em aberto
✓ fechado
DIAGRAMA DE ESTADO / ATIVIDADE
DIAGRAMA DE ESTADO / ATIVIDADE
Desafio
DIAGRAMA DE ESTADO
Desafio
DIAGRAMA DE ESTADO
Desafio
DIAGRAMA DE ATIVIDADE
Desafio
Dividir em Raias
Gerente – Recepção – Serviços - Hóspede
Próxima aula
Modelo de Projeto
Diagramas de Implementação
ESTUDO DE CASO
MODELAGEM DE SISTEMAS – AULA10
CLASSE DE PROJETO / DIAGRAMAS IMPLEMENTAÇÃO – CLAUDIA ABREU PAES
SUMÁRIO
1. Classe de Projeto
1.1 Conceito
1.2 Criação modelo E-R
1.3 Representação
2. Diagrama de Implementação
2.1 Diagrama de Componentes
2.2 Diagrama de Implantação
As Classes de Projeto representam o diagrama de
classe na perspectiva de Implementação, que aborda
aspectos do tipo métodos, tipo dos atributos,
navegabilidade e dependência.
São diagramas derivados a partir do diagrama de
classe – modelo de domínio.
CLASSE DE PROJETO
Notação para mostrar detalhes de projeto em
diagramas de estrutura estáticos.
VEÍCULOS
CÓDIGO: int
DESCRIÇÃO: string
NUM_CREDITOS
LER ()
FORM-A
PLACA: string
COR: string
MODELO: string
PROC_OK ()
CAPTURA
CLASSE DE PROJETO
A construção dos diagramas de classe de projeto
depende de:
DIAGRAMAS DE INTERAÇÃO: Identifica as classes de
software que participam da solução;
MODELO CONCEITUAL: Acrescenta detalhes às
definições de classe;
CLASSE DE PROJETO
MODELO CONCEITUAL
Apresenta conceitos do domínio do problema.
X
CLASSES DE PROJETO
Apresenta definições para entidades de software
CLASSE DE PROJETO
APLICAÇÃO
Apresenta classes, associações e atributos,
interface com suas operações e constantes,
métodos, tipos de atributos, visibilidade de
atributo, navegação entre objetos e
dependência;
CLASSE DE PROJETO
VEÍCULOS
Placa
Cor
Modelo
CLIENTE
Código
Nome
e-mail
0-n
VAGAS
Situação
0-n 1-n
LOCAÇÃO
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
0-n
MODELO CONCEITUAL
CLASSE DE PROJETO
Exemplo
DIAGRAMA DE SEQUÊNCIA
:FORM-A :VEICULO
PLACA,
COR,
MODELO
:CLIENTE
LER()
:VAGAS
*LER()
LISTA
VAGA
:LOCAÇÃO
LER()
ATUALIZAR()
INCLUIR()
CLASSE DE PROJETO
Exemplo
CLASSE DE PROJETO
LOCAÇÃO
Situação
LER()
ATUALIZAR()
VAGAS
VEÍCULOS
Placa
Cor
Modelo
CLIENTE
Código
Nome
e-mail
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
FORM-A
Placa
Cor
Modelo
Vaga
CAPTURA
IDENTIFICA
LER()
INCLUIR()
LER()
CLICA_OK()
CLASSE DE PROJETO
Exemplo
VISIBILIDADE
É a capacidade de um objeto “ver” um outro objeto
reter uma referência para este outro.
Para um objeto A enviar uma mensagem a um outro
objeto B, o objeto B deve ser visível para A;
Existem quatro maneiras pelas quais a visibilidade
pode ser conseguida:
CLASSE DE PROJETO
VISIBILIDADE
1. por atributo: B é um atributo de A;
VEÍCULOS
Placa
Cor
Modelo
CLIENTE
Código
Nome
e-mail
LER()
LER()
A classe VEÍCULO terá um 
atributo que identifica um 
objeto CLIENTE
CLASSE DE PROJETO
VISIBILIDADE
2. por Parâmetro: B é um parâmetro de um método de A;
VEÍCULOS
Placa
Cor
Modelo
FORM-A
LER()CLICA_OK()
Placa
Cor
Modelo
Vaga
LER(Placa,Cor,Modelo)
CLASSE DE PROJETO
VISIBILIDADE
3. Localmente declarada: B é declarado como um objeto 
local em um método de A;
FORM-A
CLICA_OK()
Placa
Cor
Modelo
Vaga
Lista de cliente
CLIENTE
Código
Nome
e-mail
LER()
CLASSE DE PROJETO
VISIBILIDADE
4. Global: B é, de alguma forma, globalmente visível;
O método é usar o padrão Singleton.
PADRÃO SINGLETON
Define-se um método para obter um única 
instância.
CLASSE DE PROJETO
NAVEGABILIDADE
É uma propriedade do papel da associação indicando a
navegação unidirecional através da associação dos
objetos da origem para a classe-alvo.
VEÍCULOS
Placa
Cor
Modelo
FORM-A
LER()CLICA_OK()
Placa
Cor
Modelo
Vaga
CLASSE DE PROJETO
DEPENDÊNCIAS
Indica que um elemento de um objeto
tem conhecimento de outro
elemento por curto prazo.
Associada a visibilidade por
parâmetro global e
declarada localmente.
Representada por uma linha tracejada.
CLIENTE
VEÍCULOS
Placa
Cor
ModeloFORM-A
Placa
Cor
Modelo
Vaga
LER()
LER()
CLICA_OK()
Código
Nome
e-mail
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
1. A partir dos Diagramas de Interação, identifique todas as
classes participantes da solução de software
VEÍCULOSCLIENTE
VAGAS
LOCAÇÃO
FORM-A
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
2. Desenhe-as em um Diagrama de Classe
VEÍCULOSCLIENTE
VAGAS
LOCAÇÃO
FORM-A
CLASSE DE PROJETO
CLIENTE
Código
Nome
e-mail
VEÍCULOS
Placa
Cor
Modelo
FORM-A
Placa
Cor
Modelo
Vaga
LOCAÇÃO
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
VAGAS
Situação
PROCESSO DE CRIAÇÃO
3. Duplique os atributos dos conceitos associados do
modelo conceitual
CLASSE DE PROJETO
VEÍCULOS
Placa
Cor
Modelo
FORM-A
Placa
Cor
Modelo
Vaga
LOCAÇÃO
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
VAGAS
Situação
LER()
LER()
ATUALIZAR()
CLICA_OK()
CLIENTE
Código
Nome
e-mail
LER()
INCLUIR()
PROCESSO DE CRIAÇÃO
4. Acrescente os métodos através da análise dos
Diagramas de Interação
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
5. Acrescente informação sobre tipos aos atributos e
métodos
Tipo de atributo
Tipo de retorno do método
VAGAS
Situação:int;
LER():lista
ATUALIZAR()
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
6. Acrescente associações necessárias para suportar
visibilidades de atributos requeridas.
CLIENTE
Código
Nome
e-mail
VEÍCULOS
Placa
Cor
Modelo
FORM-A
Placa
Cor
Modelo
Vaga
LOCAÇÃO
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
VAGAS
Situação
LER()
LER()
ATUALIZAR()CLICA_OK()
LER() INCLUIR()
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
7. Acrescente flechas de navegabilidade, para indicar a
direção da visibilidade de atributo.
CLIENTE
Código
Nome
e-mail
VEÍCULOS
Placa
Cor
Modelo
FORM-A
Placa
Cor
Modelo
Vaga
LOCAÇÃO
Dt.Entrada
Hr.Entrada
Dt.Saída
Hr.Saída
VAGAS
Situação
LER()
LER()
ATUALIZAR()CLICA_OK()
LER() INCLUIR()
CLASSE DE PROJETO
PROCESSO DE CRIAÇÃO
8. Acrescente linhas de relacionamentos de dependência
CLIENTE
Código:int
Nome:String
e-mail:String
VEÍCULOS
Placa:int
Cor:int
Modelo:int
FORM-A
Placa:int
Cor:int
Modelo:int
Vaga:int
LOCAÇÃO
Dt.Entrada:date
Hr.Entrada:date
Dt.Saída:date
Hr.Saída:date
VAGAS
Situação:int
LER()
LER()
ATUALIZAR()CLICA_OK()
LER() INCLUIR()
CLASSE DE PROJETO
DIAGRAMA DE IMPLEMENTAÇÃO
A arquitetura física descreve a decomposição do hardware
e software que cercam a implementação de um sistema.
Na UML, aspectos de implementação física são modelados
através de diagramas de implementação:
• Diagrama de componentes
• Diagrama de Implantação
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE COMPONENTES
Componentes modelam coisas físicas que podem residir
em um nó, como: executáveis, bibliotecas, tabelas, arquivos
e documentos.
Assim como na análise, para a implementação de um
software é necessário estabelecer qual a modelagem física
do sistema executável.
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE COMPONENTES
Um diagrama de componentes mostra as dependências
entre componentes de software, incluindo componentes de
código fonte, componentes de código binário e
componentes executáveis.
Um diagrama de componente é um grafo de componentes
conectado por relacionamentos de dependência.
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE COMPONENTES
NOTAÇÃO
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE COMPONENTES
NOTAÇÃO
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE IMPLANTAÇÃO
São utilizados para:
✓ modelagem da visão estática de funcionamento de um
sistema. Essa visão é direcionada para a distribuição,
entrega e instalação das partes que formam o sistema
físico.
✓ visualizar, especificar e documentar sistemas embutidos,
cliente/servidor e distribuídos.
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE IMPLANTAÇÃO
Envolvem a topologia do sistema, descrevendo a estrutura de
hardware.
Esses diagramas mostram:
• a configuração de nós de processamento em tempo de
execução e os componentes que neles existem.
• Componentes que não existem em tempo de execução
não aparecem nestesdiagramas.
São diagramas úteis também para a engenharia reversa.
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE IMPLANTAÇÃO
NÓ
Um diagrama de implantação é um grafo de nós conectados
por associações de comunicação.
Um nó é um objeto físico que representa um recurso
computacional.
“NÓs” geralmente são computadores como processadores,
e dispositivos, como impressoras, leitoras de cartão,
dispositivos de comunicação, etc.
DIAGRAMA DE IMPLEMENTAÇÃO
DIAGRAMA DE IMPLANTAÇÃO
COMPOSIÇÃO UML
Diagramas 
de Casos de 
Uso
Diagramas 
de 
Componente
Diagramas de 
Implantação
Diagramas 
de Interação
Contratos 
para 
Métodos e 
Operações
Diagrama 
de Classes 
de Projeto
casos de 
usos de 
projeto
Comportamento 
dos Objetos
Classe 
de 
domínio
Estados de 
Projeto
Diagrama 
de Estados 
para classe
Modelo de 
Projeto
Implementação 
/ Arquitetura 
Para obter sucesso em nosso desenvolvimento é
necessário utilizarmos modelos adequados a critérios
de qualidade:
➔ BAIXA MANUTENIBILIDADE
➔ GRANDE INTERATIVIDADE
➔ BOA PERFORMANCE
➔ ECONOMIA / SEGURANÇA
➔ DISPONIBILIDADE / ESTABILIDADE
CONCLUSÃO
Revisão AV2.
PRÓXIMA AULA
MODELAGEM DE SISTEMAS 
REVISÃO AV1– CLAUDIA ABREU PAES
SUMÁRIO
1. Metodologia RUP
2. Diagrama de Caso de Uso
3. Diagrama de Classe
4. Aplicação prática
METODOLOGIA RUP
Otimiza o processo, 
pode ser desenvolvida em partes
Programação em pares (duas pessoas no mesmo nível)
Semana de 40Horas
Equipe distribuída no mesmo ambiente
DIAGRAMA DE CASO DE USO
Ciclo de vida Iterativo e Incremental
Dividido em 4 etapas x Disciplinas que utiliza
Etapas
Concepção(escopo), Elaboração(arquitetura), Construção(operação) e Transição(versão)
Disciplinas
Levantamento de requisitos, análise, projeto, implementação, teste e implantação
Cria-se a arquitetura do sistema próxima etapa é a construção
Na etapa de transição vai aferir a qualidade, aprovar a parte desenvolvida
Cada fase tem um marco
Cada parte passa por todas as etapas
DIAGRAMA DE CLASSE
Usado para representar os dados - tem simbologia própria 
Simbologia de classe(conjunto de objetos) todo elemento observado
Associação estabelece a ligação dos objetos às classes
Multiplicidade define a quantidade de vezes que o objeto pode estar representado na 
ligação. É definida por limite inferior(mínimo) e superior(máximo)
Classe associativa , quantidade=atributo da ligação entre pedido e produto, itens de 
pedido = histórico de todos os itens comprados
Representação da generalização = cliente pessoa física ou jurídica, implementa o 
processo de herança(todos os objetos subordinados herdam atributos e métodos da 
classe generalizada). 
APLICAÇÃO PRÁTICA
Estudo de Caso “ESTACIO-ARTE”
A ESTACIO-ARTE é uma galeria de arte que se encarrega da venda
de quadros que estão expostos. O “Marchand” (gerente da
exposição) abre uma exposição informando a data de início e
término e, seleciona os quadros para participar. Novos quadros
são cadastrados e, os que já estiverem cadastrados são apenas
liberados para a exposição em questão. As negociações com os
artistas são realizadas antes do cadastro.
APLICAÇÃO PRÁTICA
Estudo de Caso “ESTACIO-ARTE”
A partir de uma solicitação de compra de quadro pelo cliente, um
vendedor verifica se o quadro já não foi vendido. A compra é
realizada e a partir de informações fornecidas pelo cliente (nome,
endereço, telefone. Caso o cliente não possua número de
telefone disponível, deve ser informado o número da carteira de
identidade.) é emitida uma nota fiscal de venda. O quadro não é
retirado da exposição, simplesmente ele passa a ser registrada
como vendido.
APLICAÇÃO PRÁTICA
Estudo de Caso “ESTACIO-ARTE”
Caso a compra do cliente exceda R$ 50.000,00 a Arte-Hoje
concede um desconto de 5% sobre o valor total da nota.
Ao final de cada exposição o Marchand providencia uma relação
com todos os quadros expostos, vendidos ou não, para a
Associação de Artistas do Estado do Rio de Janeiro.
Também ao final da exposição são gerados por ele:
• Um relatório, enviado à contabilidade, com a receita global da
exposição.
• Guias de entrega para os compradores dos quadros. Estas guias
possuem a relação dos quadros comprados, preço, nome do
comprador e endereço deste.
APLICAÇÃO PRÁTICA
Caso de Uso 
APLICAÇÃO PRÁTICA
Classe
Próxima aula
Descrição de caso de uso.
REVISÃO AV1
MODELAGEM DE SISTEMAS – RAV2
Aula de revisão AV2 – CLAUDIA ABREU PAES
SUMÁRIO
Apresentação geral dos assuntos abordados na 
disciplina
➢ Evolução
▪ Primeiro incentivo ao HW, em seguida
sistemas operacionais.
▪ Inicio desenvolvimento setorizado
▪ Aumento da demanda na produção de software
– Crise de software
▪ Definiu-se a Engenharia de SW
ENGENHARIA DE SOFTWARE
▪ Utilizam as disciplinas da Engenharia de SW
Gerência de projetos / Levantamento de requisitos
Análise / Projeto / Implementação
Teste / implantação
• Define as etapas a seguir
➢ Ciclo de Vida
ENGENHARIA DE SOFTWARE
➢ Ciclo de Vida
Aspectos \ Ciclo cascata prototipagem espiral
iterativo e 
incremental
gerência fácil moderada difícil difícil
entrega de 
produto
tardia imediatista antecipada
tratamento de 
riscos
baixa 
relevância
não 
considerado
importante importante
mudança de 
requisitos
Difícil Fácil
Método 
desenvolvimento
Total em parte em parte
ENGENHARIA DE SOFTWARE
➢ Importância da Modelagem
▪ Facilita a comunicação com o usuário.
▪ Oferece suporte a equipe de desenvolvimento.
▪ Compõe uma documentação.
ENGENHARIA DE SOFTWARE
DIAGRAMA DE CASO DE USO
➢Representa as funcionalidades do sistema.
DIAGRAMA DE CLASSE
➢Representa as informações do sistema.
DIAGRAMA DE CLASSE
➢Representa as informações do sistema.
DIAGRAMA DE CLASSE
➢Representa as informações do sistema.
DESCRIÇÃO DE CASO DE USO
➢Representação textual dos casos de uso.
▪ Tipos: Expandida e não expandida.
▪ Desenvolvida para cada caso de uso e para cada
fluxo.
▪ Utiliza um cabeçalho comum para identificação.
Nome: <Nome do Caso de Uso>
C
a
b
e
ç
a
lh
o
Objetivo: Descrever o objetivo de forma sucinta
Pré-condição: Regras que devem estar cumpridas antes da realização do caso de uso.
Pós-condição: São regras cumpridas pelo caso de uso que liberam procedimentos futuros.
DESCRIÇÃO DE CASO DE USO
➢Representação textual dos casos de uso.
FLUXO NORMAL
1. Sistema Apresenta Tela de Locação.
2. Vendedor Informa Placa de VEÍCULO.
3. Sistema obtém dados de VEÍCULO.
4. Sistema obtém dados de CLIENTE.
5. Sistema apresenta dados de CLIENTE.
6. Sistema obtém dados de VAGA.
7. Sistema apresenta lista de VAGA.
8. Vendedor escolhe VAGA.
9. Vendedor clica CONFIRMA.
10. Sistema altera VAGA.
11. Sistema Inclui “Emitir Comprovante de Locação”
12. Sistema Encerra Caso De Uso.
DESCRIÇÃO DE CASO DE USO
➢Representação textual dos casos de uso.
FLUXO ALTERNATIVO
3. Sistema obtém dados de VEÍCULO.
3.1 Não há registro de VEÍCULO
3.1.1 Sistema estende “Cadastrar Veículo”.
3.1.2 Sistema retorna para item 4.
4. Sistema obtém dados de CLIENTE.
4.1 Não há registro de CLIENTE
4.1.1 Sistema estende “Cadastrar Cliente”.
4.1.2 Sistema retorna para item 5.
5. Vendedor clica Cancela.
5.1 Sistema retorna para item 1.
DESCRIÇÃO DE CASO DE USO
➢Representação textual dos casos de uso.
REGRAS
• Estabelecer o diálogo entre o usuário e o sistema. 
• Adotar sentenças curtas, 
• Os passos devem ser numerados, sequenciados logicamente; 
• A primeira e a última sentença são comandadas pelo sistema;
• Deve-se utilizar um padrão de linguagem;
• Descrição não representa condição e repetição;
DESCRIÇÃO DE CASO DE USO
➢Representação textual dos casos de uso.
REGRAS
• Descrição não representa controles técnicos (críticas, fim de 
leitura);
• Não é preciso fluxo alternativo para todas as sentenças 
relacionadas no fluxo normal. Apresentar somente quando 
necessário.
• Podem-se utilizar comentários para complementar a informação 
“*** comentários”;
• Para representar os INCLUDES utilizar <INCLUIR>;