Modelagem de Sistema_Aulas_01_a_10

Prévia do material em texto

Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 1
Aula 1 – Paradigmas O.O e a UML
Características e pilares do paradigma orientado a objeto
Análise e projeto orientado a objeto
A UML e seus diagramas
2
Modelagem de sistemas
Processo intelectual e progressivo.
Entendimento e mapeamento de uma realidade
Modelos são usados para representar a realidade
Maquete de um empreendimento imobiliário
Diagramas no desenvolvimento de sistemas
Ajudam aos profissionais a entender a realidade
Modelagem de sistemas
Conjunto de diagramas que representem a estrutura e comportamento do sistema
3
Paradigma Orientado a Objeto
Paradigma = forma de abordar um problema.
Orientado a objeto 
Identificar os objetos do mundo real envolvidos no contexto do sistema e a relação entre esses objetos.
4
Elementos básicos paradigma OO 
Objetos, mensagens, atributos, métodos e classes
5
Pilares da O.O
Encapsulamento: esconder os atributos do acesso indevido de outros objetos.
 Os atributos devem ser acessados por métodos da própria classe
6
Pilares da O.O
Herança: derivar novas classes a partir de outras já existentes - reuso.
A classe descendente herda atributos e métodos da classe ancestral 
Economia: tempo/dinheiro; segurança 
7
Pilares da O.O - Herança
8
Pilares da O.O
Polimorfismo: Alterar o comportamento de uma classe herdada.
Amplia o poder de reaproveitamento da herança 
Alteração (re escrita) de métodos
9
Pilares da O.O - Polimorfismo
10
Pilares da O.O
Visibilidade: O que uma classe pode visualizar da outra.
Garantir o encapsulamento
Classes com métodos privados apenas ?
11
Conclusões Paradigma OO
Conceito de encapsulamento
Classes independentes, que facilita desenvolvimento e manutenção
Herança e polimorfismo.
Permite e facilitam a reutilização, útil para o desenvolvimento e manutenção
 As classes passam a ser componentes portáveis entre as aplicações 
Reusabilidade
Extensibilidade
Favorecem o desenvolvimento de sistemas grandes e complexos
12
UML
Uma resposta ao mercado que precisa de diagramas compatíveis com desenvolvimento OO.
Integração de 3 métodos
OMT (Object Modeling Technique) de Jacobson
OOSE (Object-Oriented Software Engineering) de Rumbaugh
Booch 
Em 1997 é adotada pela OMG (Object Management Group ) como linguagem padrão de modelagem
13
A UML COMO LINGUAGEM PADRãO
Linguagem padrão voltada para:
Visualização: diagramas gráficos
Especificação: Análise, projeto
Construção : integrado a linguagens
Documentação
Independente do método de desenvolvimento usado.
Não é um método, não é uma metodologia, não é um processo
Não determina a ordem e nem quais diagramas devem ser usados no desenvolvimento
14
DIAGRAMAS DA UML – VERSãO 2.4.1
15
16
COMO USAR A UML ?
Como esboço
Foco: comunicação
Expressar ideias
Fomentar a discussão entre desenvolvedores
Como projeto
Foco : completeza
Construção de um projeto completo, usando vários diagramas
Compatível com os modelos iterativos incrementais
PU (RUP)
Metodologias ágeis
17
PROCESSOS ITERATIVOS E A UML
Processo de desenvolvimento
Abordagem para organizar as atividades de construção, implantação e manutenção 
PU (processo Unificado): RUP
Metodologias ágeis: XP e SCRUM
Processos iterativos
Ciclo de vida em mini projetos curtos, preferencia com duração fixa (ex: 3 meses) – são as iterações 
Cada iteração contêm um sub conjunto das funcionalidades do sistema
Baseados em incrementos sucessivos do sistema 
Entre as iterações temos ajustes e feedbacks
18
PROCESSOS ITERATIVOS E A UML
19
Processo com uso de 3 iterações. 
Em cada uma repete-se o conjunto de etapas.
AS ETAPAS
20
Levantamento de Requisitos
Levantamento e mapeamento das necessidades dos usuários
Análise de Requisitos (“Faça a coisa certa”)
Entendimento em detalhes dos requisitos e modelagem da solução lógica sem considerar aspecto físicos. – Domínio do problema
Quais funções o sistema precisa para atender aos requisitos ?
Projeto (“Faça certo a coisa”)
Definição da arquitetura e componentes do sistema, com a visão da tecnologia a usar.
AS ETAPAS
21
Implementação
Codificação na linguagem de programação
Testes
Aferição se atende aos requisitos e qualidade do software
Implantação.
Treinamento, entrega e uso no ambiente dos usuários.
UML E RESULTADOS DE CADA FASE
Levantamento de Requisitos
Diagrama de casos de uso + especificações informais
Diagrama de classe conceitual
Análise de Requisitos
Diagrama de casos de uso + especificações completas 
Diagrama conceitual de classes
Diagrama de Estados
Diagrama de Atividades
22
UML E RESULTADOS DE CADA FASE
Projeto
Diagrama de classes de projeto 
Diagrama de sequencia
Diagrama de estados
Diagrama de componentes
Diagrama de Implantação
23
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 1
Exercícios
1) Como se chama o princípio que diz que: o acesso aos atributos de uma classe devem ser somente pelos métodos da classe e não diretamente por outra classe ?
( ) Herança
( ) Polimorfismo
( ) Entropia
( ) Encapsulamento
( ) Visibilidade 
25
Exercícios
2) Analise as sentenças a seguir:
I. A herança garante reuso e consequente economia de tempo e dinheiro
II. O polimorfismo diz que os atributos devem ter visibilidade privada
III. Sem herança não há como ter polimorfismo.
IV. O encapsulamento visa garantir o desenvolvimento de classes independentes.
Assinale a única alternativa CORRETA
( ) Estão corretos apenas I e III
( ) Estão corretos I, II, III e IV
( ) Estão corretos apenas I e IV
( ) Está correto apenas III
( ) Estão corretos apenas I, III e IV
26
Exercícios
3) No que se refere a UML (Linguagem Unificada de modelagem), assinale a única alternativa INCORRETA.
( ) É independente de processo de desenvolvimento de software
( ) Contém um conjunto de diagramas com diferentes visões
( ) A UML destina-se a visualização, especificação, construção e documentação de sistemas orientados a objeto.
( ) Nasceu da união de métodos usados, na época, pelos principais profissionais do mercado.
( ) Voltada especificamente para a modelagem de requisitos
27
Exercícios
4) Analise as assertivas sobre os processos iterativos
I. São processos onde o ciclo de vida do sistema é dividido em uma série de mini projetos e de curta duração.
II. Cada iteração contém um subconjunto das funcionalidades do sistema. 
III. Em cada iteração temos as atividades de Levantamento de Requisitos, Análise de Requisitos, projeto, implementação, testes e implantação
IV. São modelos ultrapassados e não adequados a UML
( ) Estão corretas apenas I e II
( ) Estão corretas I, II, III e IV
( ) Estão corretas apenas II e IV
( ) Estão corretas apenas I, III e IV
( ) Estão corretas apenas I, II e III
28
Exercícios
5) Como se chama o diagrama que mostra as funcionalidades do sistema e os atores que com elas interagem?
( ) Diagrama de classes
( ) Diagrama de estados
( ) Diagrama de componentes
( ) Diagrama de sequencia
( ) Diagrama de casos de uso
29
Exercícios
6) Assinale a opção que apresenta o diagrama da UML que: mostra o comportamento do ciclo de vida de cada objeto
( ) Diagrama de classes
( ) Diagrama de colaboração
( ) Diagrama de objetos
( ) Diagrama de Implantação
( ) Diagrama de Estado
30
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 2
Aula 2 – Casos de Uso
Conceito e classificação dos requisitos
Objetivo do diagrama de casos de uso
Elementos dos diagramas de casos de uso
Aplicação do diagrama de casos de uso
32
Requisitos
Necessidades dos usuários que o sistema precisa atender
Levantar requisitos : O QUE o sistema deve fazer.
A qualidade da identificação dos requisitos reflete em todo processo de desenvolvimento.
Requisitos errados  sistema que não atende a necessidade
Requisitos Funcionais
Requisitos Não Funcionais
33
Requisitos Funcionais
Apresentam as funcionalidades necessárias para atender as necessidades dos usuários
 Sistema Financeiro
Cadastrar Contas a pagar
Cadastrar Contas a receber
Cadastrar SaldosBancários
Gerar Fluxo de Caixa
34
Requisitos Não Funcionais
Atributos e propriedades do sistema
Como um todo (sistema)
De funcionalidades específicas
 Sistema como um todo
O sistema deve operar com tela touch screen
Impressão de boleto de venda não deve demorar mais que 5 min (performance)
A entrada de funcionários deve ser controlada por leitor digital (interface).
A entrada de funcionários não deve 
35
Diagramas de Casos de Uso
Um dos mais informais e simples diagramas
Finalidades: 
Mostrar funcionalidades do sistema
Validar funcionalidades juntos aos usuários
Ter a certeza de que todos os requisitos foram considerados
Instrumento de comunicação entre a equipe de desenvolvimento.
A visão de casos de uso é do ponto de vista externo, do usuário
Não mostra detalhes de COMO o sistema realizará essas funcionalidades
36
Diagrama de Casos de Uso
37
3 Elementos
Ator
Casos de Uso
Relacionamento
Atores – caso
Entre atores
Entre casos
Atores
O ator é algo com comportamento, que interage diretamente com o sistema. 
Um ator participa (realiza) de um ou mais casos de uso do sistema
Um ator é o papel que o agente desempenha em relação ao sistema.
 
38
Atores com papeis interno e externo
39
Atores
Um ator pode representar setores e departamentos da empresa (contabilidade e contas a pagar), bem como funções desempenhadas na empresa (almoxarifado)
40
Ator como setor e função desempenhada
41
Atores
Um ator pode ser dispositivos eletrônicos, como por exemplo hardware, servidores ou dispositivos lógicos, como por exemplo sistemas, de acordo com a imagem abaixo
42
Ator como setor e função desempenhada
43
Identificando Atores
O primeiro passo para a construção do modelo de casos de uso é a identificação de atores. Perguntas úteis :
Quais órgãos, empresas ou pessoas farão uso deste sistema de informação?
Que sistemas ou equipamentos irão se comunicar com o sistema que será desenvolvido?
Quem deve ser informado de alguma ocorrência no sistema?
A quem pode interessar os requisitos funcionais do sistema?
44
Casos de Uso
Representam, as funcionalidades do sistema (ELIPSES)
o nome do caso de uso deve ser composto de um Verbo no Infinitivo + Complemento verbal
Um caso de uso é um conjunto de cenários.
descreve uma sequência de ações do ator e do sistema.
Sequência de ações = CENÁRIO.
45
Identificação dos casos de uso
Podemos pensar nos casos de uso que representam os objetivos dos atores. 
Estes casos de uso representam os processos da empresa. Perguntas úteis:
Quais as necessidades e objetivos de cada ator em relação ao sistema?
Que informações serão produzidas pelo sistema?
O sistema realizará alguma ação que ocorre de forma regular no tempo?
Existe um caso de uso para atender cada requisito funcional?
46
Identificação de Casos de Uso
Em seguida podemos pensar nos casos de uso que não representam um benefício direto para os atores mas são necessários para o funcionamento do sistema. Tais casos de uso englobam manutenção de cadastros, e manutenção de informações provenientes de outros sistemas.
47
Relacionamento entre Ator e Casos de Uso
48
Indicado por uma linha sólida, 
O Ator interage com o Caso de uso. 
A comunicação é bidirecional ou seja o ator informa dados ao caso de uso e recebe informações por ele processadas
Relacionamento entre Atores
Generalização/especialização, 
Linha sólida com uma seta na extremidade que aponta pata o ator geral, 
49
O ator geral é o Funcionário O ator especialista, o Gerente. 
Relacionamento entre Atores
O ator geral é Usuário. Os atores especializados são Aluno e atendente.
Aluno e Atendente se relacionam com todos os casos de uso associados ao ator Usuário.
50
Apenas o ator Atendente se relaciona com Cancelar Matrícula em
Relacionamento entre Atores
Esta é uma associação útil para definir sobreposição de papéis entre atores, onde: 
O ator especializado interage com o caso de ao qual está associado diretamente e com todos os casos de uso com o qual o ator generalizado se associa. 
Já o inverso não ocorre, o ator generalizado não interage com os casos de uso associados ao ator generalizado.
51
Relacionamento entre Casos de Uso
52
INCLUSÃO (include ou uses): um caso de uso (principal) incorpora o comportamento de outro caso de uso (incluído). 
O caso de Uso incluído é parte integrante do caso de uso principal e 
A fatoração acontece pois outros casos de uso também poderão incorporar o Caso de Uso incluído e assim evitar repetições de fluxos. 
Relacionamento <Include> entre casos 
53
O caso de uso Validar Disciplina agrega o que é comum aos casos de uso Incluir Disciplina e Eliminar Disciplina.
Relacionamento entre Casos de Uso
54
EXTENSÃO (extends): para descrever cenários opcionais em caso de uso, 
Uma variação do comportamento normal.
Através de uma condição, o caso estendido á acionado, executado e retorna ao principal
O caso de uso estendido pode não ser executado.
Relacionamento <extends> entre casos 
55
Relacionamento <extends> entre casos 
56
Relacionamento entre Casos de Uso
57
GENERALIZAÇÂO: quando um caso de uso é semelhante a outro, mas executa algumas funções a mais. 
É pouco usado, pois seu uso confunde-se com o extends - também pode resolver essa questão da variação de comportamento
Nesse caso um comportamento com adição de funcionalidade..
Generalização entre casos de uso
58
Especialização do caso de uso Solicitar Produtos (internet ou telefone)
Existem partes comuns, que estão especificadas em Solicitar Produtos (caso mais geral).
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 2
Estudo de Caso
Em um hotel da cidade, um hóspede pode obter um quarto de 2 formas: através de uma reserva prévia ou obtendo um quarto se houver disponibilidade no ato. Ao reservar são registrados Nome, CPF, Período da estada, quantidade de quartos e de hospedes. Na chegada do hóspede (com ou sem reserva) são registrados, além dos dados acima, os dados (Nome e data de nascimento) dos demais hóspedes. Na saída do hóspede, registra-se a data de saída, bem como apresenta o valor a pagar ao hospede, que informa forma de pagamento (dinheiro, cartão ou cheque). Se pagamento em cheque (banco, agencia, conta e cheque) registra-se os dados do cheque. Se pagamento em cartão, registra-se dados do cartão (administradora, numero cartão e validade). Após saída do hóspede, o recepcionista deve liberar o quarto para limpeza , que ao ser encerrada deve liberar o quarto para uso novamente.
60
Estudo de Caso
O gerente pode retirar um quarto de uso, seja para obra ou qualquer outra ação, podendo retornar o quarto para hospedagem, sempre que desejar. O gerente poderá incluir novos quartos, quando forem construídos.
Sempre que solicitado o gerente deve receber um mapa de ocupação dos quartos (reservas e ocupados) em um período (por ele informado).
Ao final do dia o caixa precisa saber o total recebido em dinheiro e o gerente as reservas canceladas.
Uma reserva pode ser cancelada pelo recepcionista (obedecendo pedido do hóspede) ou automaticamente, se o hóspede não chegar ate as 17h.
Todo atendimento (reservas, checkin e checkout) é feito pelos recepcionistas.
61
1. Identificando Atores
Identificar no texto, os substantivos que indiquem interação com o sistema, seja recebendo dados ou informações
Hóspede – não interage diretamente, mas informa dados e recebe informações de sua hospedagem
Gerente – retira e recoloca quarto de uso; recebe mapa de ocupação; inclui novos quartos; recebe informação das reservas do período
Caixa – recebe informação do total recebido R$ por dia
Recepcionistas – procedimentos de reserva (inclusão e cancelamento), checkin e checkout (incluindo pagamento);
62
1. Identificando Casos de Uso
Para cada ator, identificar funcionalidade associadas
Ator: Gerente 
Incluir quarto
Bloquear quarto por inatividade
Desbloquear quarto da inatividade
Consultar Mapa de Ocupação
Consultar Reservas no Periodo
Ator Caixa 
Consultar recebimentos em espécie
63
1. IdentificandoCasos de Uso
Recepcionista
Reservar Quarto 
Cancelar Reserva
Registrar Entrada do Hospede
Registrar Saída do Hóspede (pagamento e Bloqueio de quarto para limpeza)
Liberar Quarto da Limpeza
Cancelamento automático da reserva – qual ator ?
Cancelar Reservar Automaticamente
Evento temporal – Sistema ou Computador, já que será o relógio deste que vai disparar o evento.
64
1. Identificando Casos de Uso
65
Estudo de Caso
Alteração de Requisito
O hospede deve ser cadastrado, quando fizer primeira reserva ou primeira hospedagem.
Solução
- Criar um caso de uso Cadastrar Cliente, que deve estender os casos de uso Registrar Reserva e Registrar Entrada do Hóspede
66
1. Identificando Casos de Uso
67
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 3
Aula 3 – Especificações de Casos de Uso
Importância da especificação de casos de Uso
Formas de especificação de casos de uso
Técnicas de Especificação de casos de uso
69
Especificações de casos de uso
Fundamental para complementar o diagrama de casos de uso
A UML nada define sobre o texto narrativo.
Descreve o passo a passo do comportamento do caso de uso
Interação entre ator e sistema
Ações do sistema
Vários cenários (principal e alternativos)
3 formatos possíveis:
Resumido
Informal
Completo
70
Especificação – os 3 formatos
Resumido
Resumo de 1 parágrafo contendo o cenário principal (sucesso)
Uso: Análise Inicial de Requisitos 
Informal 
Múltiplos parágrafos cobrindo vários cenários de uso.
Uso: Análise Inicial de Requisitos
Completo
 Todos os cenários (principal e alternativos) são descritos em detalhes, 
Uso: Análise de requisitos e de sistemas
Adequado aos casos de uso relevantes
71
Especificação – os 3 formatos
A especificação de um caso de uso, deve mostrar a interação entre o ator e o sistema (caso de uso em questão), ou seja a “conversa” entre ator e sistema na realização (acontecimento) do caso de uso.
Para mostrar a diferença entre os 3 tipos de especificação, vamos usar como exemplo o caso de uso: Registrar venda
72
Formato Resumido
Caso de Uso: Registrar Venda 
O cliente chega em um ponto de pagamento da loja com os itens que deseja adquirir. O caixa registra cada item desejado. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados. O cliente informa e o caixa registra os dados do pagamento, que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras e sai com os itens adquiridos
73
Formato Informal
Caso de Uso: Registrar Venda 
Cenário Principal (de sucesso)
cliente chega ao ponto de pagamento da loja com os itens a serem adquiridos. O caixa usa o sistema PDV para registrar todos os itens comprados. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados. O cliente informa e o caixa registrar os dados do pagamento, que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras e sai com os itens adquiridos.
74
Formato Informal
Cenários Alternativos
Se o identificador do item adquirido não for encontrado no sistema, esse notifica o caixa e sugere que esse entre manualmente com a identificação do item (que talvez esteja corrompido).
Se o cliente informou pagamento em cartão e a operadora não aprova a transação, informe o cliente e solicite nova forma de pagamento;
Se o sistema não consegue atualiza o estoque, sugere que o caixa registre no formulário de problemas do dia, para balanço ao final do dia.
75
Formato Completo
Nome do caso de Uso: Registrar Venda
Escopo: Sistema de Vendas – PDV
Nível: Usuário
Atores: Caixa
Interessados e Interesses:Caixa: deseja que o sistema seja eficiente, sem erros e de fácil utilização
Cliente: deseja adquirir os produtos desejados de forma rápida, sem muitom esforço e encontrar o que precisa e ao final um comprovante do que comprou
76
Formato Completo
Interessados e interesses
Orgãos fiscais: Deseja cobrar os impostos de cada venda realizada 
Operadoras de cartão: Deseja receber solicitações de autorização de crédito no formato e protocolo corretos.
Pré condição: todos os produtos registrados no sistema e com respectivos preços; caixa autenticado e PDF registrado
Pós condições: Venda salva, impostos calculados, estoques atualizados, autorizações de pagamento registradas, Recibo gerado.
77
Formato Completo
Cenário Principal (ou fluxo básico)
1.Cliente chega ao PDV com os itens que deseja adquirir
2.Caixa inicia uma nova venda
3.Para cada item de venda do cliente, FACA
a) Caixa insere o identificador do item
b) Sistema Localiza o Item
c) Sistema registra apresenta a linha do item de venda, com o identificador, nome e valor unitário do produto
d) Sistema calcula os impostos do item
78
Formato Completo
4. Sistema apresenta o valor total da venda com impostos calculados
5. Caixa informa total ao cliente e solicita pagamento
6. Caixa informa o pagamento do cliente
7. Sistema registra e trata o pagamento do cliente
8. Sistema Finaliza venda e apresenta o recibo da mesma
9. Sistema contabiliza a baixa no estoque de cada item vendido.
79
Formato Completo
Cenários Alternativos (extensões).
2.a. Sistema não inicializa
	1. Caixa inicia a venda em planilha 	manual (contingência) , registrando cada 	item e o pagamento e encerra o caso 
3.a........
Requisitos Especiais:
1. Interface de Usuário com tela sensivel a toque em um monitor de tela plana com pelo menos 23 “
2. Resposta de autorização de crédito, dentro de 30 segundos, em 90% dos casos.
3. A recuperação de falhas de servidores devem ser consistente e robusta.
80
81
	Seção da Especificação	Significado
	Nome	Verbo no infinitivo + Complemento Verbal
	Escopo 	O Nome do Sistema / Projeto 
	Nível	Objetivo do usuário ou sub-função (include, extends e especialização)
	Atores (*)	Atores envolvidos : principal e secundários
	Interessados e Interesses	Quem se importa com esse caso de uso e o que eles desejam?
	Pré condição (*)	O que precisa ser verdade para esse caso de uso acontecer
	Pós condição ou Garantia de sucesso (*)	O que precisa ser verdade quando da finalização bem sucedida desse caso de uso
	Cenário Principal (*)	O cenário de sucesso, um caminho típico , incondicional
	Cenários Alternativos ou extensões (*)	Cenários alternativos, quando o cenário principal tem uma variação do fluxo bem sucedido.
	RequisitosEspeciais	Requisitos não funcionais relacionados
Especificação com Include
82
Especificação com caso de Include
Especificação do Caso Incluir Dependente
Cenário Principal
1. Atendente informa identificação do cliente
2. Sistema localiza dados do cliente informado	
3. Atendente informa dados do dependente
4. Sistema localiza dados do dependente informado – <<Include Pesquisar Dependente >>
5. Sistema registra dados do dependente do cliente informado
83
Especificação com caso de Include
Especificação do Caso Incluir Dependente
Cenários Alternativos	
2.a. Cliente NÃO localizado
Sistema informa “Cliente não registrado no sistema” e retorna ao passo 1 do cenário principal
4.a. Dependente JÁ registrado
sistema informa “Dependente já registrado no sistema ”e retorna ao passo 3 do cenário principal	
84
Especificação com caso de Extends
85
Especificação com Extends
Cenário Principal
1. Atendente informa identificação da mídia
2. Sistema Localiza Locação com a Mídia informada
3. Sistema apresenta Registro da locação com Valor Pagar
4. Atendente informa forma de pagamento
5. Caso forma de pagamento seja 
 DINH: <extends PAGAR EM DINHEIRO> 
 CARTÃO: <extends PAGAR no CARTÃO>
 Fim-Caso
6. Sistema Registra devolução
7. Sistema emite Recibo de Quitação do Pagamento
	
86
Especificação com Extends
Cenários Alternativos
1.a. MÍDIA NÃO localizada
Sistema informa “Mídia não registrado no sistema ou NÃO alugada” e retorna ao passo 1 do cenário Principal
2.a. Locação NÃO localizada (inconsistência de dado
Sistema informa “Locação NÃO registrada para a mídia no sistema” e encerra caso de uso.
3.b. SE Data Corrente > Data Previstade Devolução ENTÃO Calcular Multa 	 <<Extends CALCULAR MULTA POR ATRASO>>
 
87
Considerações Finais
Não use detalhes de implementação
A tecnologia ficará obsoleta e o caso precisará ser revisto
“Usuário insere o seu cartão” – não 
“Usuário informa dados: agencia, conta e senha” - OK
Procure não associar Casos de Uso a telas de sistemas
é cedo para pensarmos em interface, que será objeto da fase de projeto do sistema, embora usuários adorem telas
88
Considerações Finais
Os casos de uso incluídos (chamados por <include>) ou estendidos (chamados por <extends>) também devem ter descrição textual, podendo ser no formato resumido ou informal.
Perguntas que podem ajudar no detalhamento dos cenarios principal e alternativos.
Quando tudo ocorre na normalidade (com sucesso), qual o comportamento do sistema ? – esse será o passo a passo do cenário principal.
89
Considerações Finais
Algo pode acontecer de forma diferenciada, nesse passo ? – indicará um cenário alternativo (relacionado a esse passo).
O que pode dar errado nesse passo ? – da mesma forma que a pergunta acima, essa conduz a identificação de um cenário alternativo.
Quando um passo for muito complicado, ele pode vir a ser um novo caso de uso, que se relacionará com o caso original pelo esteriótipo <include>.
Façam casos de uso enxutos, pois casos longas podem não ser lidos em sua totalidade.
90
Formato em 2 colunas
91
	Ações do ATOR	Ações do SISTEMA
	Cenário Principal	
	1. Atendente informa dados da reserva	 
	 	2. Sistema verifica se cliente Cadastrado - <Include Pesquisa Cliente>
	 	3. Sistema verifica disponibilidade de quarto
	4. Atendente confirma a reserva	 
	 	5. Sistema confirma a reserva
	Cenários Alternativos	
	 	2.a. Cliente não é cadastrado
	 	2.a.1. Sistema Informa cliente não cadastrado
2.a.2 Executa caso de extensão: <Extends> Cadastrar Cliente
2.a.3. Retornar ao passo 3 do Caso de uso
	 	
	 	
	 	3a. Não há disponibilidade
3.a.1. Sistema informa “Não há disponibilidade no período desejado”.
3.a.2. Encerar caso de uso
	 	
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 3
Estudo de Caso
Em um hotel da cidade, um hóspede pode obter um quarto de 2 formas: através de uma reserva prévia ou obtendo um quarto se houver disponibilidade no ato. Ao reservar são registrados Nome, CPF, Período da estada, quantidade de quartos e de hospedes. Na chegada do hóspede (com ou sem reserva) são registrados, além dos dados acima, os dados (Nome e data de nascimento) dos demais hóspedes. Na saída do hóspede, registra-se a data de saída, bem como apresenta o valor a pagar ao hospede, que informa forma de pagamento (dinheiro, cartão ou cheque). Se pagamento em cheque (banco, agencia, conta e cheque) registra-se os dados do cheque. Se pagamento em cartão, registra-se dados do cartão (administradora, numero cartão e validade). Após saída do hóspede, o recepcionista deve liberar o quarto para limpeza , que ao ser encerrada deve liberar o quarto para uso novamente.
93
Estudo de Caso
O gerente pode retirar um quarto de uso, seja para obra ou qualquer outra ação, podendo retornar o quarto para hospedagem, sempre que desejar. O gerente poderá incluir novos quartos, quando forem construídos.
Sempre que solicitado o gerente deve receber um mapa de ocupação dos quartos (reservas e ocupados) em um período (por ele informado).
Ao final do dia o caixa precisa saber o total recebido em dinheiro e o gerente as reservas canceladas.
Uma reserva pode ser cancelada pelo recepcionista (obedecendo pedido do hóspede) ou automaticamente, se o hóspede não chegar ate as 17h.
Todo atendimento (reservas, checkin e checkout) é feito pelos recepcionistas.
94
1. Identificando Casos de Uso
95
Caso de Uso: Reservar Quarto
Cenário Principal
1. Recepcionista informa qtde de quartos, num pessoas por quarto
2. Recepcionista informa período da reserva
3. Sistema verifica disponibilidade de quartos no período
4. Recepcionista informa CPF do hóspede
5. Sistema localiza hóspede
6. Sistema mostra dados da reserva e do hóspede
7. Recepcionista confirma dados da reserva
8. Sistema registra Reserva com status de Reservada
Cenários Alternativos
3.a. Não há disponibilidade de quartos
 1. Sistema informa que não há disponibilidade de quartos
 2. Sistema retorna ao passo 1 do cenário principal.
5.a. Hóspede não registrado
 1. <<Extends Cadastrar Hóspede>>
	
96
Caso: Cancelar Reservas do Dia
Cenário Principal
Para cada reserva a iniciar no dia com status de “reservada” FACA
Sistema cancela a reserva, atualizando o status da reserva para Cancelada.
Cenários Alternativos
a) Não existem reservas a serem canceladas
- Sistema encerra caso de uso
	
97
Caso : Registrar Entrada do hóspede
Cenário Principal
1. Recepcionista informa CPF do hóspede
2. Sistema localiza Hóspede
3. Recepcionista informa período da reserva
4. Sistema localiza Reserva
5. Sistema mostra dados da reserva registrada
6. Recepcionista confirma dados da reserva
7. Sistema atualiza status da reserva para “Hospedado”
8. Sistema registra Entrada do hóspede com data corrente
Cenários Alternativos
2.a. Hóspede não cadastrado
 1. <<Extends Cadastrar Hóspede>>
4.a. Reserva não localizada
 1. <<Extends Reservar Quarto>>
 2. Sistema retorna ao passo 5 do cenário principal
6.a. Recepcionista altera os dados da reserva 
 1. Recepcionista altera algum dado da reserva: Periodo da reserva,
 qtde quartos e pessoas por quarto
 2. Sistema registra alteração de dados da reserva
	
98
1. Identificando Casos de Uso
99
Caso : Registrar Entrada do hóspede
Cenário Principal
1. Recepcionista informa CPF do hóspede e período da reserva
2. Sistema localiza Reserva
3. Sistema mostra dados da reserva registrada
4. Recepcionista confirma dados da reserva
5. Sistema atualiza status da reserva para “Hospedado”
6. Sistema registra Entrada do hóspede com data corrente
Cenários Alternativos
2.a. Reserva não localizada
 1. <<Extends Reservar Quarto>>
4.a. Recepcionista altera os dados da reserva 
 1. Recepcionista altera algum dado da reserva: Periodo da reserva,
 qtde quartos e pessoas por quarto
 2. Sistema registra alteração de dados da reserva
VERSAO MELHORODA – OTIMIZANDO PASSOS
	
100
1. Identificando Casos de Uso
101
Extends : Cadastrar Hospede
Cenário Principal
1. Sistema mostra CPF do Hóspede 
2. Recepcionista informa dados (nome, endereço completo e telefone) do hóspede 
3. Sistema Registra dados do hóspede
	
102
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 4
Aula 4 – Diagrama de Classes
Conceitos e Elementos
Relacionamento entre classes
Aplicação do diagrama de classes
104
Conceitos do Diagrama de Classes
Mais popular e conhecido da UML
Refinamentos ao longo do PDS
Observação do mundo real–domínio do problema–Diagrama Conceiual de classes
Nível de projeto – Diagrama de classes de PROJETO, com visão do desenvolvimento.
O diagrama de classes
 descreve os tipos de objetos que interagem para realizar as funcionalidades do sistema e os relacionamentos entre eles.
Propriedades e operações de uma classe e restrições a forma como há o relacionamento
105
Evolução no diagrama de classes
Modelo conceitual (análise)
Classes do negócio 
funcionalidades dos casos de uso
Atributos (sem tipos e visibilidade) característicos
Relacionamentos (associação)
Modelo de classes de Projeto (Projeto)
Multiplicidade 
Relacionamentos – análise semântica
Novos atributos
Métodos
Visibilidade e tipos dos atributos
Classes de projeto (persistência,camadas..)
106
A Classe
3 compartimentos
Nome da classe
Atributos
Operações (métodos)
107
Objeto
Classe: Molde de objetos afins, com as mesmas características (atributos e métodos)
Objeto: Instância de uma classe
108
Elementos do Diagrama de Classes
109
Atributos e Métodos - declaração
Atributos: visibilidade Nome: tipo
Métodos: visibilidade Nome (Lista de parâmetros) : tipo
110
Associações entre classes
111
Mais Simples
1, 2 ou mais classes não correlatas,independentes
Ao final do relacionamento, as classes permanecem com suas vidas 
Associações entre classes
112
Associações Exclusivas
113
Multiplicidade
114
Quantos objetos de cada classe podem estar envolvidos nos relacionamentos.
Multiplicidade
115
	Multipl	Significado
	1	Exatamente 1 (um)
	1..*	Um ou vários (muitos)
	0..*	Nenhum (zero) ou vários (muitos)
	*	Muitos. A leitura é Nenhum (zero) ou vários (muitos)
	0..1	Nenhum (zero) ou 1 (um)
	m..n	Faixa de valores. Exemplo : 1 a 3 , 4 a 7 ou 6 a 11
Visibilidade – Atributos e métodos
116
	Visibilidade	Comentários
	 + Publico	 Qualquer classe pode usar o método ou atributo
	 - Privado	 Apenas a própria classe pode usar o método ou o atributo
	 ~ Pacote	 Apenas classes dentro do pacote podem usar o método ou atributo
	 # Protegido	 Apenas as subclasses (herança), ou classe especializada pode usar o atributo ou método
Encapsulamento – atributos privados
SÓ métodos privados ?
Generalização / especialização – visibilidade protegida na classe mãe = herdar
Classes de Associação
117
Herança
118
Agregação e Composição.
119
Relacionamentos Todo-Parte
Agregação tem semântica mais forte
Apenas 1 todo participa – as partes pertencem a apenas 1 TODO
Se o TODO foi excluído , as partes o são (vidas coincidentes).
Dependência
120
A dependência entre 2 classes existe se: mudanças na definição de uma classe pode demandar mudanças na definição da outra
No relacionamento abaixo Disciplina depende (é dependente de) de Estudante
Observe o método Incluir da classe Disciplina, ela usa como parâmetro o objeto aluno, que é da classe Estudante
Nome Relacionamento e Papeis
121
Navegabilidade
122
O CLIENTE sabe quais são seus endereços
Mas o ENDEREÇO não sabe a quais clientes pertence.
A classe Cliente poderá enviar mensagens a classe Endereços, mas o contrário não. 
Esse e uma notação semântica que ajuda muito na implementação.
Notas e comentários
123
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 04
Estudo de Caso
Em um hotel da cidade, um hóspede pode obter um quarto de 2 formas: através de uma reserva prévia ou obtendo um quarto se houver disponibilidade no ato. Ao reservar são registrados Nome, CPF, Período da estada, quantidade de quartos e de hospedes. Na chegada do hóspede (com ou sem reserva) são registrados, além dos dados acima, os dados (Nome e data de nascimento) dos demais hóspedes. Na saída do hóspede, registra-se a data de saída, bem como apresenta o valor a pagar ao hospede, que informa forma de pagamento (dinheiro, cartão ou cheque). Se pagamento em cheque (banco, agencia, conta e cheque) registra-se os dados do cheque. Se pagamento em cartão, registra-se dados do cartão (administradora, numero cartão e validade). Após saída do hóspede, o recepcionista deve liberar o quarto para limpeza , que ao ser encerrada deve liberar o quarto para uso novamente.
125
Estudo de Caso
O gerente pode retirar um quarto de uso, seja para obra ou qualquer outra ação, podendo retornar o quarto para hospedagem, sempre que desejar. O gerente poderá incluir novos quartos, quando forem construídos.
Sempre que solicitado o gerente deve receber um mapa de ocupação dos quartos (reservas e ocupados) em um período (por ele informado).
Ao final do dia o caixa precisa saber o total recebido em dinheiro e o gerente as reservas canceladas.
Uma reserva pode ser cancelada pelo recepcionista (obedecendo pedido do hóspede) ou automaticamente, se o hóspede não chegar ate as 17h.
Todo atendimento (reservas, checkin e checkout) é feito pelos recepcionistas.
126
1. Identificando Casos de Uso
127
Identificando Classes
Precisa reter, no sistema, dados de algum ator?
Não. Nenhum ator é relevante para o domínio do problema enquanto retenção de seus dados
Que casos de uso dão origem a classes ?
Incluir quarto e outros – Quarto
Cadastrar hóspede – Hóspede
Reservar Quarto o outros – Reserva
Registrar Entrada do Hóspede / Registrar Saída do Hóspede - Hospedagem
Pagar Cheque, Pagar Dinheiro, Pagar Cartão – Pagamento, Pag Cartão, Pag Cheque e Pag Dinheiro.
128
Identificando Atributos
3. Que atributos identificam cada classe ?
Quarto: Num Quarto, Max Pessoas
Hóspede: CPF, Nome, Data Nasc
Reserva: Data Reserva, Data Inicial, Data Final, Qtde Pessoas, Qtde Quartos
Hospedagem: Data Cheg, Data Saida
Pagamento: Forma Pagamento, Valor Pagamento
Dinheiro : Valor Pago, Troco
Cheque : Banco, Agencia, Conta, Chequ
Cartão: Adm, Num Cartão, Val Cartão, Parcelas
129
Identificando Métodos evidentes
4. Algum caso de uso dá origem a métodos de uma classe?
Quarto: Incluir quarto, Bloquear Quarto, desbloquear quarto, liberar quarto da limpeza.
Reserva: Incluir Reserva, Cancelar reserva, cancelar reservas do dia, consultar reservas canceladas.
Hóspede: Cadastrar
Hospedagem: Registrar entrada, registrar saída
Pagamento: ? – nada evidente
Pag Dinheiro – Consultar recebimento especie
Pag Cartão - ? Nada evidente
Pag Cheque - ? Nada evidente
130
1ªversão:Diagrama Conceitual Classes
131
Refinamento 1: DCC
132
Refinamento 2: DCC
133
Refinamento 2: DCC
134
Refinamento 2: DCC
135
Refinamento 2: DCC
136
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 5
Aula 5 – Diagramas de Interação
Os Diagramas de interação
Conceitos e elementos do diagrama de sequencia
Aplicação do diagrama de sequencia
138
Diagramas de Interação
Os diagramas de interação mostram como as classes (na verdade os objetos) trocam mensagens, ou seja interagem para oferecer funcionalidades (realizar um casos de uso). 
Uma mensagem representa a solicitação que um objeto requisitante faz a um objeto receptor para que esse execute uma das operações definidas em sua classe.
Os diagramas de interação, de uma forma geral, mostram como as classes colaboram em determinados comportamentos
139
Diagramas de Interação
140
	Tipo	Pontos Fortes	Pontos Fracos
	Sequencia	Mostra com clareza a sequencia temporal das mensagens
 Amplo conjunto de opções de notação	A cada novo objeto, o diagrama cresce para direita, consumindo espaça na horizonta e se muitos objetos participam, dificulta o desenho e leitura
	Comunicação	Economia de espaço ao modelar – flexibilidade ao adicionar novos objetos, em qualquer direção do desenho.	Difícil em perceber a sequencia das mensagens, sendo necessária a numeração sequencial das mesmas
 Menos opções de notação
O tripé da análise e projeto
141
Diagramas de Interação
Ao elaborarmos o diagrama de interação (sequencia) , podemos realizar melhorias:
nas especificações de casos de uso, 
no diagrama de casos de uso e
 principalmente no diagrama de classes, onde além de novos métodos para as classes já existentes, poderemos também modelar novas classes e até mesmo atributos. 
Essas alterações são normais, sadias pois a medida que vamos evoluindo e nos aprofundando no sistema, aumentamos nossa compreensão e capacidade de modelar o sistema mais adequadamente.
142
Sequencia x Classes
O objeto Controlador envia uma mensagem de nome Procurar Cliente() ao objeto Cliente
A mensagem em um diagrama de sequencia representa um método que pertence a classe do objeto que recebe a mensagem..
143
Bases para Diagrama de Sequencia
144
Caso de Uso: Emitir Saldo Conta
Cenário Principal
1. Correntista Informa Agencia e Conta corrente
2. Sistema valida Agencia e Conta
3. Correntista Informa senha de acesso
4. Sistema valida senha de acesso
5. Sistema calcula saldo do dia corrente, com base nas movimentações da conta e saldo anterior.
6. Sistemas apresenta saldo ao correntista
Diagrama de Sequencia 
145
Decisões em Diagrama de Sequencia
146
Decisões em Diagrama de Sequencia
147
Repetições em Diagrama de Sequencia
148
Criação e Destruição de Objetos
149
Tipos de Mensagens
150
Responsabilidade das classes
151
Uma mensagem no modelo de interações, é a atribuição de responsabilidade a uma classe. 
A modelagem de interações é um útil para decompor as responsabilidades do sistema e aloca-las a classes
A identificaçãode classes e atribuição de responsabilidades é complexa. 
A melhor solução dependerá da expertise do modelador e da aplicação de princípios
A coesão e o acoplamento são 2 desses princípios.
Coesão e Acoplamento
152
A coesão indica o quão relacionadas (afins) são as responsabilidades de uma classe. 
Um bom projeto indica uma alta coesão, ou seja as responsabilidades de uma classe devem ser fortemente relacionadas entre si. 
Acoplamento diz respeito a quão dependentes são umas classes das outras. O acoplamento deve ser baixo, ou seja pouca dependência.
Padrões de Projeto
153
Padrão é uma solução, já usada em projetos anteriores, que deve ser usada e ajuda a dar soluções eficientes em nossos projetos. 
Existe um padrão que diz que:
o método deve ser colocado na classe que conhece a informação (tratada pelo método). 
Esse padrão chama-se “padrão especialista”
Existem outros padrões, classificados em diferentes tipos a serem considerados, que podem ser objeto de uma pesquisa, para expansão dos conhecimentos nesse sentido.
Desenvolvimento em camadas
154
Dividir responsabilidades e separar código.
Inclusão de classes (de projeto), nos diagramas de classe e sequencia
Interface (<boundary>) – serve de comunicação entre atores e sistema
Controle (<control>) – serve de intermediação entre as classes de interface e as demais classes
Entidade (<entity>) – classes do domínio do problema, que detém o conhecimento do negócio.
Desenvolvimento em camadas
155
Procedimento padrão
1. ator solicita a ação desejada, pela interface do cenário de uso.
2. O classe de interface encaminha o pedido a classe de controle
3. A classe de controla traduz o pedido e solicita a respectiva entidade que execute determinada operação.
4. A sequencia de retornos acontece ate que pela interface om usuário tem a sua resposta.
Diagrama com classes de Projeto
156
Diagrama com classes de Projeto
157
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividade 05
Estudo de Caso
Em um hotel da cidade, um hóspede pode obter um quarto de 2 formas: através de uma reserva prévia ou obtendo um quarto se houver disponibilidade no ato. Ao reservar são registrados Nome, CPF, Período da estada, quantidade de quartos e de hospedes. Na chegada do hóspede (com ou sem reserva) são registrados, além dos dados acima, os dados (Nome e data de nascimento) dos demais hóspedes. Na saída do hóspede, registra-se a data de saída, bem como apresenta o valor a pagar ao hospede, que informa forma de pagamento (dinheiro, cartão ou cheque). Se pagamento em cheque (banco, agencia, conta e cheque) registra-se os dados do cheque. Se pagamento em cartão, registra-se dados do cartão (administradora, numero cartão e validade). Após saída do hóspede, o recepcionista deve liberar o quarto para limpeza , que ao ser encerrada deve liberar o quarto para uso novamente.
159
Estudo de Caso
O gerente pode retirar um quarto de uso, seja para obra ou qualquer outra ação, podendo retornar o quarto para hospedagem, sempre que desejar. O gerente poderá incluir novos quartos, quando forem construídos.
Sempre que solicitado o gerente deve receber um mapa de ocupação dos quartos (reservas e ocupados) em um período (por ele informado).
Ao final do dia o caixa precisa saber o total recebido em dinheiro e o gerente as reservas canceladas.
Uma reserva pode ser cancelada pelo recepcionista (obedecendo pedido do hóspede) ou automaticamente, se o hóspede não chegar ate as 17h.
Todo atendimento (reservas, checkin e checkout) é feito pelos recepcionistas.
160
1. Identificando Casos de Uso
161
Refinamento 2: DCC
162
Reservar Quarto
163
Reservar Quarto
164
Cancelar Reservas Dia
165
Cancelar Reservas Dia
166
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 6
Aula 6 – Diagramas de Interação
Aplicação dos diagramas através de estudo de caso
 Casos de Uso (diagrama e especificações)
 Diagrama de classes
 Diagrama de sequencia 
168
Estudo de Caso
A empresa FAIXA AMARELA Ltda, confecciona faixas de anúncios e encomendou um sistema que controle suas atividades 
Controle e acompanhamento dos pedidos
Cadastramento de seus clientes 
O cliente, faz seu pedido e os dados são registrados:
Cliente: nome, cpf, endereço completo, tel_fixo, Tel_cel;
Pedido: Data do Pedido, altura e largura da faixa, texto a ser escrito na faixa, cor da faixa (amarela, preta ou branca), cor do texto (Branco, Preto, Azul ou vermelho), Previsão de entrega, Valor do Serviço e Valor do sinal (50% do total)
169
Estudo de Caso
O valor do serviço é calculado
Valor da faixa = Custo_Material + Custo_desenho + % Lucro
Custo_Material = área x 20,00
Custo_Desenho = número de letras * 0,70
% de Lucro = 20 % (Custo_Material + Custo_desenho)
O Prazo de entrega é calculado com base no trabalho de 5 dias por semana e produção diária de 8 faixas no máximo. O prazo deve começar a ser contabilizado, após a confirmação do pagamento do sinal
O sistema deve calcular o prazo de entrega e o valor do serviço;
170
Estudo de Caso
Para cada encomenda deve ser emitido um recibo, em 2 vias, contendo os dados do pedido e pagamento (valor do sinal e a pagar na entrega). 
O sistema (acesso da diretoria) deve controlar o pagamento do sinal, quando o serviço é iniciado e a data de entrega calculada. O sistema deve controlar o pagamento na entrega.
O sinal pode ser pago por depósito bancário e o pagamento do saldo deve ser pago contra entrega, em dinheiro, cheque ou cartão de débito.
171
Estudo de Caso
O produto somente é entregue mediante o pagamento do saldo. A entrega deve ser controlada.
O sistema deve prover uma consulta (disponível apenas a diretoria), de cada pedido feito no período, informando: data do pedido, data de entrega, Valor Serviço, Valor Sinal, Sinal Pago (S/N), Serviço Finalizado (S/N), Serviço Pago (S/N) e Status Pedido. (S/N) = Sim ou Não. 
O Pedido ao longo do seu ciclo de vida pode ter vários estados , que o sistema deve controlar.
 
172
Estudo de Caso
Ao ser inserido, o status é EM ESPERA. 
Com o sinal pago, o status é PRONTO PARA PRODUÇÃO
Ao iniciar a produção da faixa, o status é EM PRODUÇÃO. 
Ao ser finalizado o status passa a ser PRONTO. 
Ao ser entregue o status passa a ser ENTREGUE. Para ser considerado ENTREGUE o pedido tem que ter o saldo de pagamento confirmado. 
173
Estudo de Caso
O sistema deve emitir um informe a todo cliente que não faz pedido há mais de 6 meses (com base na data corrente). 
Num mesmo pedido podem ser encomendadas mais de 1 faixa, até 5 no máximo (mas essa regra pode alterar a qualquer momento).
 
174
Procedimento da solução
1) Diagramação da 1ª. Versão do diagrama de casos de uso
Identificação das principais funcionalidades do sistema
2) Especificação textual de casos de uso relevantes
3) Refinamento do diagrama de casos de uso
Identificação de includes ou extends que otimizem a solução
4) Identificação das classes do negócio
5) Diagrama Conceitual de Classes
6) Diagrama de sequencia dos casos de uso de relevância.
175
1ª. Versão diagrama de casos de uso
176
1ª. Versão diagrama de casos de uso
177
	Caso de Uso	Breve descrição
	Registrar Pedido	Registrar os pedidos de faixas
	Registrar Fim produção do pedido	Sinaliza que a produção da faixa chegou ao fim, devendo haver mudança do estado do pedido, nesse momento.
	Registrar Entrega do Pedido	Sinaliza que o pedido foi entregue ao cliente, devendo haver mudança do estado do pedido, nesse momento.
Caso de Uso: Registrar Pedido
178
Pré Condição: --
Pós condição: Pedido registrado e Cliente registrado
Cenário Principal
...
....
...
..
Cenários Alternativos
...
...
...
Cenário Principal - Registrar Pedido 
179
1.Usuário informa Id do Cliente
2.Sistema Localiza Cliente com Id do Cliente
3.Sistema exibe nome , email e telefones do cliente
4.Para cada faixa do pedido FACA
a) Usuário informa dados da faixa 
b) Sistema Calcula valor da faixa 
c) Sistema acumula valor do pedido
5. Sistema apresenta valor total do pedido
6. Sistema aponta EM ESPERA para status do pedido.
7. Sistemaregistra pedido
8. Sistema emite boleto do pedido (*) 
Cenários Alternativos - Registrar Pedido 
180
Cenários Alternativos
2.a. Cliente não localizado
	1. Sistema Informa Cliente não localizado
	2. Sistema retorna ao passo 1 do cenário principal.
Caso de Uso: Cadastrar Cliente
181
Cenário Principal
1. Usuário informa Id do Cliente
2. Sistema Localiza Cliente com Id do Cliente
3. Usuário informa dados do cliente (1)
4. Sistema registra dados do cliente
Cenários Alternativos 
2.a. Cliente já cadastrado
 1. Sistema emite mensagem “Cliente já está cadastrado”
 2. Sistemas retorna ao passo 1 do cenário principal 
Caso de Uso: Confirmar Recebimento Sinal
182
Cenário Principal
1. Usuário informa Id do Pedido
2. Sistema Localiza Pedido com Id do Pedido
3. Sistema exibe dados do pedido
4. Usuário informa Data e valor do sinal
5. Sistema valida dados do sinal
6. Sistema aponta PRONTO PARA PRODUCAO para status do pedido.
7. Sistema calcula data de entrega do pedido
8. Sistema altera dados do pedido.
Caso de Uso: Confirmar Recebimento Sinal
183
 Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
4.a. Valor do sinal inferior a 50% do pedido
 1. Sistema emite mensagem “O valor do sinal deve ser equivalente a 50% do valor do 
 pedido”
 2. Sistema retorna ao passo 4 do cenário principal. 
Caso de Uso: Registrar Início da produção
184
1. Usuário informa Id do Pedido
2. Sistema Localiza Pedido com Id do Pedido
3. Sistema exibe dados do pedido
4. Usuário informa Data de inicio da produção
5. Sistema calcula data de fim da produção e entrega
6. Sistema apresenta data de fim da produção e data de entrega
7. Sistema aponta EM PRODUCAO para status do pedido.
8. Sistema altera dados do pedido.
Caso de Uso: Registrar Início da produção
185
1 Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
Caso de Uso: Registrar Fim da produção
186
Cenário Principal
1. Usuário informa Id do Pedido
2. Sistema Localiza Pedido com Id do Pedido
3. Sistema exibe dados do pedido
4. Usuário informa Data de fim da produção
5. Sistema calcula data de entrega
6. Sistema apresenta data de entrega
7. Sistema aponta PRONTO para status do pedido.
8. Sistema altera dados do pedido.
Caso de Uso: Registrar Fim da produção
187
Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
Caso de Uso: Registrar entrega do pedido
188
Cenário Principal
1. Usuário informa Id do Pedido
2. Sistema Localiza Pedido com Id do Pedido
3. Sistema exibe dados do pedido
4. Usuário informa Data real de entrega 
5. Sistema apresenta data real de entrega
6. Sistema aponta ENTREGUE para status do pedido.
7. Sistema altera dados do pedido.
Caso de Uso: Registrar entrega do pedido
189
Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
Caso de Uso: Consultar cliente sem pedido
190
 Cenário Principal
Para cada cliente cadastrado faça 
Sistema localiza Pedidos do Cliente
Para cada pedido do cliente faça
Se (Data Corrente – Data Pedido) > 180 então exibir dados Pedido (1)
Fim_para
Fim_para
(1) Nome Cliente, email Cliente, Telefone Cliente, Data Ultimo Pedido
Caso de Uso: Consultar Pedido no período
191
 
Cenário Principal
Usuário informa data Inicial e final
Para cada Pedido com data pedido>-Data Inicial e Data Pedido<=Data Final faça
Buscar Dados Cliente
Exibir dados Pedido (1)
Fim_para
(1)– Nome Cliente, email Cliente, Telefone Cliente, Data Pedido, Valor Pedido, Data Entrega
Refinamento do diagrama de casos de uso
192
Observe que nos casos de uso 
Confirmar Recebimento do Sinal, 
Registrar Início da Produção. 
Registrar Fim da Produção e 
Registrar Entrega do Pedido, 
Temos os dois trecho repetidos: o primeiro no cenário principal e segundo no cenário alternativo
Trechos repetidos nos casos de uso
193
Cenários Principal 
1. Usuário informa Id do Pedido
2. Sistema Localiza Pedido com Id do Pedido
3. Sistema exibe dados do pedido
Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
Alterações nas especificações
194
As especificações dos casos de uso precisam ser modificadas para compatibilizar com diagramas. 
Observe que no local das 3 linhas que havia anteriormente na especificação do caso de uso Confirmar Recebimento do Sinal, passamos a ter uma única linha com a inclusão do novo caso de uso (<<Incluce>> Pesquisar Pedido), 
E o cenário alternativo de Confirmar Recebimento de sinal passa a ser o cenário alternativo do <<include>> Pesquisar Pedido
Caso de uso: Confirmar Recebimento sinal
195
Cenário Principal
1. <<Include>> Pesquisar Pedido
2. Usuário informa Data e valor de pagamento do sinal.
3. Sistema aponta PRONTO PARA PRODUCAO para status do pedido.
4. Sistema calcula data de entrega do pedido
5. Sistema altera dados do pedido.
FIM- caso de uso  
Caso de uso: Confirmar Recebimento sinal
196
Cenários Alternativos 
4.a. Valor do sinal inferior a 50% do pedido
 1. Sistema emite mensagem “O valor do sinal deve ser equivalente a 50% do valor do pedido”
 2. Sistema retorna ao passo 4 do cenário principal
Caso de uso: Pesquisar Pedido (include)
197
Cenário Principal
Usuário informa Id do Pedido
Sistema Localiza Pedido com Id do Pedido
Sistema exibe dados do pedido
 
Cenários Alternativos 
2.a. Pedido não localizado
 1. Sistema emite mensagem “Inconsistência de dados, Pedido não localizado”
 2. Sistema retorna ao passo 1 do cenário principal
.
Diagrama de casos de uso - refinado
198
Diagrama Conceitual de Classes
199
O diagrama conceitual de classes pode ser extraído dos casos de uso. 
Casos de uso podem ser classes
Casos de uso podem ser métodos
Casos de uso: Cadastrar Cliente
Classe Cliente
Casos de uso: Demais 
Classe Pedido
As 2 classes se relacionam por associação
Diagrama Conceitual de Classes
200
O relacionamento entre as classes é associação
Papel: Cliente FAZ Pedido
A cardinalidade do relacionamento
1 Cliente faz * Pedidos
1 Pedido é de 1 Cliente
Atributos
201
Um erro muito comum em diagrama de classes é a confusão que se faz com tabelas (de bancos de dados relacionais), usando os conceitos de chave primária e chave estrangeira em relacionamentos 1:* ou *..*. 
Esse conceito não existe em diagrama de classes. Classe e tabela são bem distintos nesse sentido. 
A classe deve conter apenas os atributos que pertençam a ela, que a identifiquem enquanto classe.
Analisando os atributos do pedido
202
Dados do pedido: tamanho da faixa (altura e largura), texto a ser escrito na faixa, cor da faixa (amarela, preta ou branca), cor do texto (Branco, Preto, Azul ou vermelho)
Cada pedido pode conter até 5 faixas, o que significa dizer que os dados do pedido, acima, terão que ser armazenados 5 vezes ou mais (caso cresça no futuro). 
Analisando os atributos do pedido
203
Isso acarreta uma anomalia de armazenamento de atributos, pois teríamos que ter 5 vezes cada dado de 1 faixa, que poderiam não ser usados sempre, causando desperdício de armazenamento e uma estrutura pouco ortodoxa.
Percebe-se uma nova classe, chamada FAIXAS PEDIDO, que estaria relacionada com a classe PEDIDO. 
Tal solução resolve problema da quantidade de faixas por pedido, pode aumentar ou diminuir. 
Diagrama Conceitual de classes final
204
Agregação ou composição?
205
Adicionando os atributos
Analisando especificações de casos de uso
206
A análise de especificações de casos de uso, nos indicam a necessidade de novos atributos 
	Caso de Uso	Atributos sugeridos
	Confirmar Recebimentode Sinal	Data Pago Sinal
Valor Pago Sinal
	Registrar Início de Produção 
Registrar Fim de Produção	Data Inicio Produção
Data Fim Produção
Data Entrega
	Registrar Entrega do Pedido	Data Real Entrega
Responsabilidade das classes
207
A análise de especificações de casos de uso, nos indicam a necessidade de novos atributos 
	Caso de Uso	Atributos sugeridos
	Confirmar Recebimento de Sinal	Data Pago Sinal
Valor Pago Sinal
	Registrar Início de Produção 
Registrar Fim de Produção	Data Inicio Produção
Data Fim Produção
Data Entrega
	Registrar Entrega do Pedido	Data Real Entrega
208
Adição de atributos
209
Responsabilidade das classes
Adição de métodos, analisando os casos de uso
210
Registrar Pedido-Cenário: Principal
Novos Métodos
Cliente
Pedido
Faixas Pedido
211
Consultar Pedidos Período-Cenário: Principal
212
Consultar Clientes Sem Pedido - Principal
213
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 7
Aula 7 – Diagrama de Transição de Estado
Entender os conceitos e elementos do diagrama de transição de estados (DTE)
Aplicar a construção do diagrama de estados.
215
O Estado de um Objeto
O estado de um objeto é determinado pelos valores de seus atributos, em dado momento.
Garantia do encapsulamento: apenas os métodos da classe podem alterar os seus seus próprios atributos. Dessa forma apenas os métodos da própria classe devem alterar o seu estado.
Ciclo de vida do objeto: tempo que o objeto permanece vivo e ativo – vários estados
216
O Estado de um Objeto
Pela análise das transições de estados é possível identificar as operações que precisam ser realizadas para responder aos eventos. E tais operações estarão mapeadas em métodos da classe a que o objeto pertence.
O Diagrama da UML que ajuda na análise das transições entre os estados de um objeto é o DTE ou DE.
217
Diagrama de Transição de Estados
DTE descreve: 
o ciclo de vida de objetos de uma classe, 
os eventos que causam as transições entre estados e 
as operações resultantes
Mostra o comportamento de objetos de uma única classe.
DTE – 1 para cada classe com 2 ou mais estados
218
Estado
Segundo a definição de UML Guia de Usuário[Booch, Rumbauch e Jaconson, 2006], estado é uma condição ou situação na vida de um objeto durante o qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Um objeto permanece em um estado por um tempo finito.
219
Evento
Um evento é a ocorrência (interna ou externa) de um estímulo gerado para o objeto, capaz de mudar o seu estado atual.
Uma transição indica um movimento de um estado para o outro, pela ocorrência de um evento.
220
Pseudo estado: Inicial
Denota o estado (pseudo estado) de um objeto no momento de sua criação, no momento em que ele é instanciado na memória. Só há um estado INICIAL em um DTE, mostrando o inicio de sua leitura 
221
Pseudo estado: Final
Denota o estado (pseudo estado) do fim do ciclo de vida de um objeto. É um estado opcional, no DTE, e também pode-se ter mais um. 
222
223
224
Conclusões do DTE
Os estados determinam e delimitam as operações passíveis com aquele objeto. 
Um hóspede não pode chegar ao hotel e hospedar-se sem que tenha feito uma reserva: sem transição entre Disponível e Ocupado. 
Somente existe transição para o estado de Ocupado, estando no estado Reservado. 
225
Conclusões do DTE
Como acabamos com a obrigação de reservar um quarto para pode ocupa-lo ?
226
Detalhando a transição 
Cada transição possui três partes: 
Assinatura do gatilho, é um único evento que demanda a mudança de estado. Usamos apenas assinatura do gatilho (Cliente Faz Reserva, Cliente Faz Checkin e etc), ou seja o evento que ocasiona a transição de estado. A ausência, denota que a transição é feita imediatamente.
227
Detalhando a transição 
Cada transição possui três partes: 
Sentinela: se estiver presente, é uma condição que deve ser verdadeira para que a transição ocorra. Se ausente, indica que a transição sempre acontece. Representada entre colchetes [..], com a condição dentro.
Atividade é um comportamento executado durante a transição. A ausência diz que nada é feito durante a transição. 
228
Detalhando a transição 
Assinatura do gatilho: Saque de R$
Sentinela: [Saldo < 0]
Atividade: Aguardar depósito
Leitura: ao realizar um “Saque de R$” e o saldo ficar < ZERO, a conta transita para estado de Bloqueada, onde “aguarda um depósito”, que torne o saldo zerado ou positivo (maior ou igual a zero).
229
Otimizando o DTE
Ajudam a otimizar e reduzir a quantidade de estados e complexidade do DTE.
Ações de Entrada e Saída (entry / exit)
Atividades (do)
Transição interna (evento)
230
Ações de Entrada e Saída
Ações realizadas dentro do estado, assim que entra (entrada) e antes de sair (saída), independente da transição. 
A cláusula ENTRY (ação de entrada)
A cláusula EXIT (ações de saída).
A clausula ENTRY - ação no momento em que o objeto entra no respectivo estado
A cláusula EXIT - ação sempre que o objeto sai de determinado estado.
231
Transição Interna
Os estados pode reagir a eventos, que não ocasionam transição, usando atividades internas. 
São eventos que precisam ser tratados, mas que não ocasionam transição de estado. 
 
232
Atividades 
Em geral, objeto fica ocioso em um estado até que um evento ocorra. 
Porém pode ser que você deseje que um objeto permaneça realizando uma tarefa até que determinado evento ocorra. 
executa uma atividade enquanto está nesse estado. A cláusula DO indica que há uma atividade naquele estado.
233
Otimizando o Caso Hotel
234
Eliminar o estado EM LIMPEZA, e criar uma Ação de Saída (Exit) do estado OCUPADO e assim reduziremos o número de estados. 
Superestados
235
Um superestado ajuda a simplificar a modelagem de comportamentos complexos, sendo composto de vários estados . 
Um superestado é composto de subestados e é chamado de estado composto. 
Um estado composto pode ser sequencial ou concorrente
Superestados
236
Regra: Todos os estados dentro de um estado composto herdam suas transições.
Passo a passo para construir o DTE
237
1. Identifique os estados relevantes da classe
2. Analise possíveis eventos (mudança estado)
	Para cada evento, identifique transição
3. Para cada estado: 
	identifique as transições de um evento
	identifique os eventos internos e ações
4. Para cada transição 
	verifique condições de guarda e ações.
5. Para cada condição de guarda e para cada ação, 
	identifique os atributos e ligações
6. Defina o estado inicial e os eventuais estados finais. 
7. Desenhe o diagrama
Contribuições :DTE ao diagrama de classes
238
O DTE é feito com base nas especificações de casos de uso, nos diagramas de interação e nos diagramas de classes. 
Novos atributos e métodos podem ser descobertos ao elaboramos DTE e são adicionados ao diagrama de classes.
Pode ser necessária a atualização de métodos de uma classe para refletir o comportamento nos respectivos estados
Por exemplo, o comportamento do método sacar() da classe ContaBancária varia em função do estado no qual esta classe se encontra: saques não podem ser realizados em uma conta BLOQUEADA.
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividades
Estudo de Caso
O Pedido pode ter vários estados 
Ao ser inserido, o status é EM ESPERA. 
Com o sinal pago, o status é PRONTO PARA PRODUÇÃO
Ao iniciar a produção da faixa, o status é EM PRODUÇÃO. 
Ao ser finalizado o status passa a ser PRONTO. 
Ao ser entregue o status passa a ser ENTREGUE. Para estar ENTREGUE o pedido tem que ter o saldo de pagamento confirmado. 
240
Estudo de Caso
241
Estudo de Caso
E se o pedido puder ser cancelado enquanto não entrar em produção
242
Estudo de Caso
243
Atividade
Questão 3: (Eletrobrás) Observe o diagrama de transição de estados a seguir. Suponha que, num dado momento, o sistema se encontra no Estado0 e que ocorra a seguinte sequencia de eventos: e c b a a 
 
O estado do sistema após a ocorrência desses eventos, será ?
( ) Estado0
( ) Estado3
( ) Estado1( ) Estado4
( ) Estado final
244
Estudo de Caso
245
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 8
Aula 8 – Diagrama de Atividades
Entender os conceitos e elementos do diagrama de atividades
Entender as situações em que o uso do diagrama de atividades é útil.
Aplicar a construção de diagrama de atividades
247
Fluxograma o percursor
O diagrama de atividades, inspirado nos fluxogramas, apresenta uma formatação diferenciada, com novos elementos (conforme definido na UML) e novas possibilidades. A principal diferença, que faz o diagrama de atividade mais versátil que os fluxogramas é a possibilidade de representar atividades que ocorrem em paralelo.
248
249
Elementos do Diagrama de Atividades
Atividade: retângulo com bordas arredondadas
250
Transição: Setas contínuas que representam o fluxo de trabalho entre atividades
Decisões e Condições de guarda
Decisões: Losango, usado para controlar os desvios (caminhos) do fluxo de controle. 
Condição de guarda: condições associadas a transições. indicando que a atividade que sucede será executada se condição=V
251
Pontos de merge
Desvios: a decisão, que divide em 2 ou mais caminhos (fluxos de atividades). 
Tem 1 fluxo de entrada e N fluxos de saída.
Intercalações: Local onde 2 ou mais caminhos (fluxos de atividades) se juntam e continuam como apenas 1 fluxo. 
É usado o mesmo losango da decisão. 
Os caminhos foram separados pelo Desvio. 
Tem N fluxos de entrada e 1 fluxo de saída.
252
253
254
255
Processamento em Paralelo
Processamento em paralelo: Bifurcação e União (ou Junção): barras horizontais que sincronizam atividades que vão ocorrer em paralelo. 
As atividades que ocorrem em paralelo são Processar Pedido e Faturar Pedido
256
257
Processamento em Paralelo
A programação em paralelo em algoritmos concorrentes é pouco comum no mundo comercial, sendo mais usada em software básico (S.O)
O poder do paralelismo do diagrama de atividade é mais usado para representar processos de negócio ou fluxos de trabalho.
258
259
Processamento em Paralelo
A partir bifurcação, os fluxos de atividades que vão ocorrer em paralelo
O fluxo que inicia com Atividade 1
O fluxo que inicia com Atividade 2 
O fluxo que inicia com Atividade 3
Os 3 fluxos ocorrem em paralelo e cada um terá um tempo diferente e independente
Sincronizar os 3 fluxos ao final, Junção (join), 
260
Processamento em Paralelo
Os fluxos de atividades que ocorrem em paralelo serão sincronizados 2 vezes: no inicio pela barra de sincronização chamada bifurcação e ao final pela barra de junção.
A barra de bifurcação recebe 1 transição de entrada e gera N fluxos de saída, que iniciam juntos
A barra de junção recebe N fluxos de controle e gera 1 transição de saída, que somente será executada quando todos os fluxos de entrada chegarem na junção.
261
262
Raias de Natação
Forma de particionamento, exibindo os agentes que realizam cada atividade do diagrama
Os agentes podem ser
departamentos ou setores da empresa (financeiro, contabilidade, criação, propaganda e etc), 
funções ou cargos de pessoas nas empresas (gerente, operação, atendente e etc), 
papeis nas empresas (fornecedor, cliente, segurado, seguradora e etc).
263
Raias de Natação
Para o caso do diagrama de atividades representar a lógica de casos de uso ou de métodos complexos de uma classe, as raias podem representar: objetos, componentes e atores.
264
265
Sub atividades 
As atividades, quando complexas, podem ser decompostas em sub atividades. 
A atividade decomposta terá um diagrama especificando as suas sub-atividades e no diagrama principal terá uma representação diferenciada – com símbolo do ancinho, 
266
267
Sub atividades 
A seguir, Detalhamento de “Entregar Pedido”. 
há um desvio para executar o que está especificado no diagrama abaixo, desde o Inicio até o Fim. 
Ao final da execução do diagrama “Entregar Pedido” o fluxo volta ao diagrama acima para o ponto imediatamente seguinte a atividade “entregar Pedido”, que é a barra de junção.
O nome do diagrama (canto superior esquerdo, após a palavra ACT) = nome da atividade do ancinho.
268
269
Para que usar Diagrama de Atividades
O uso de diagrama de atividades não ocorre em larga escala. Pois:
primeiro: documentar sistemas não é prática usual aqui no Brasil, 
segundo – em sistemas desenvolvidos sob o paradigma OO o particionamento do sistema é por classes e não por funcionalidades (como seria nos paradigmas estruturado e essencial); como o diagrama de atividades descreve comportamento está mais relacionado a funcionalidades. 
270
Aplicações mais usuais do Diagrama
Modelagem de processos de negócios e Fluxos de trabalho
Essa utilização é que mais tira proveito do fato do diagrama de atividade permitir representar fluxos de controle paralelos, já que em muitos processos de negócio e em fluxos de trabalho costumam acontecer em paralelo. 
271
Aplicações mais usuais do Diagrama
Modelagem da lógica de um caso de uso complexo
A especificação de casos de uso complexos demandam muito esforço e por vezes, por sua extensão, são difíceis de serem visualizados como um todo (ocupando mais de 1 folha)
Restrição: o usuário final (especialista do domínio do problema), geralmente leitor das especificações de casos de uso, poderia não acompanhar o diagrama com facilidade. 
272
Aplicações mais usuais do Diagrama
Modelagem da lógica de um caso de uso complexo
 A vantagem é que os cenários principal e alternativos podem ser representados no mesmo diagrama, facilitando a visão do caso de uso como um todo. 
Limitação: os casos de uso são descritos na visão dos atores e o diagrama de atividades especificam as atividades do sistema- as interações do ator para informar dados serão atividades
273
Aplicações mais usuais do Diagrama
Modelagem da lógica de uma operação complexa
	Embora não seja muito usual, métodos de classes podem ter uma lógica complexa, especialmente em classes de controle e nesse caso o diagrama de atividades podes ser útil para ajudar no entendimento dessa lógica.
274
Aplicações mais usuais do Diagrama
Modelar a lógica de algoritmos paralelos para programas concorrentes
Pode-se valer dos elementos (separações e junções) usados pelo diagrama de atividades para representar o processamento paralelo
275
Modelagem lógica de caso de uso complexo
Caso de Uso: Registrar Pedido
Cenário Principal
1, Usuário informa Id do Cliente
2. Sistema Localiza Cliente com Id do Cliente
3. Sistema exibe dados do cliente
4. Usuário informa dados do pedido 
5. Sistema Calcula valor do serviço (2) 
6. Sistema aponta EM ESPERA para status do pedido.
7. Sistema registra pedido
8. Sistema emite boleto do pedido 
 
276
Modelagem lógica de caso de uso complexo
Caso de Uso: Registrar Pedido
Cenários Alternativos 
2.a. Cliente não localizado
 1. Extends Cadastrar Cliente
 
277
Modelagem lógica de caso de uso complexo
Caso de Uso: Registrar Pedido
Cenários Alternativos 
2.a. Cliente não localizado
 1. Extends Cadastrar Cliente
 
278
279
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividades
Diagrama de Atividade – sinistro de veiculo
O segurado aciona seguro para conserto de automóvel colidido
A seguradora cuida do recolhimento do automóvel levando-o para uma de suas oficinas autorizadas. Se perda total, o valor e pago ao cliente e o processo encerrado.
Caso o automóvel tenha conserto é cobrada a franquia , paga pelo cliente, enquanto o carro é consertado 
281
282
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 9
Aula 9 – Diagramas de Implementação
Discriminar o diagrama de Componentes e seus elementos
Discriminar o diagrama de implantação e seus elementos
Relacionar os 2 diagramas
Aplicar, através de exemplos, a construção dos 2 diagramas
284
Diagrama de Componentes
Útil para modelagem da arquitetura física de um software, 
Apresenta os componentes físicos, suas interfaces e dependências.
Permite o desenvolvimento baseado em componentes, onde um software é dividido em componentes e interfacesque são reutilizáveis e substituíveis. 
Especifica a arquitetura do software
285
Analogia
Sistema de home theater 
componentes podem ser facilmente conectados e substituídos a qualquer momento: projetor, receiver, caixas de som (frontal, lateral, subwoofer). 
Se componente queimar, é substituído por um igual ou equivalente (mesma interface).
Análogo ao conceito de componentes de software 
286
Componente
A UML define componente como:
Um componente representa uma parte modular de um sistema que encapsula seu conteúdo e cuja manifestação é substituível dentro de um ambiente. 
Define seu comportamento em termos de interfaces fornecidas e requeridas (conexão com demais componentes).
287
Componente
Caixa preta, onde são especificadas as interfaces para que outros componentes possam usar seus serviços sem conhecer detalhes de como os serviços implementados. 
O componente encapsula (protege) o seu conteúdo 
e seu comportamento é definido em função de prover e requerer serviços, através de suas interfaces.
288
Componente
O desejo é que o componente possa ser independente e intercambiável. 
Em um sistema baseado em componentes, cada componente tem uma finalidade, ou seja, presta um serviço e para tal demanda o uso de outros componentes. 
289
Sistema com um conjunto de componentes
A ideia é construir sistemas, como um conjunto de componentes, que são partes substituíveis.
E que esses componentes possam ser reutilizados em muitos sistemas.
Os componentes devem ter interfaces que propiciem grande flexibilidade e adaptação a muitos sistemas.
Componentes podem ser criados de outros componentes.
290
O Que pode ser um componente
Página HTML
Código fonte em linguagem
Código executável
DLL
Servlet
Máquina JAVA
291
Interface de um componente
Elementos que definem um conjuntos de operações que outros elementos, como classes ou componentes, devem implementar.
Existem dois tipos de interfaces
Interfaces fornecidas: descrevem os serviços oferecidos a outros componentes. Um componente pode declarar quantas interfaces fornecidas forem necessárias. 
292
Interface de um componente
Interfaces requeridas: são as interfaces usadas pelo componente, quando solicita serviços de outros componentes. Um componente pode ter várias interfaces requeridas. 
293
Interface de um componente
Um mesmo componente pode tanto fornecer como requerer interfaces.
O relacionamento entre os componentes e as interfaces é a essência dos sistemas
294
Componentes e Interface
 O usuário do serviço de um componente deve conhecer bem a sintaxe de suas interfaces
Pelo nosso exemplo, as interface são as conexões possíveis entre o receiver do home Theather e dispositivos (projetor, DVD e etc_
Para usarmos um DVD precisamos saber as possíveis conexões: HDMI, DVI e etc. 
Para usar um componente precisamos saber as possíveis interfaces.
295
Componentes e Interface
2 maneiras de representar o relacionamento entre componentes e interface.
Opção 1: o componente que usa a interface se conecta ao outro componente por meio do relacionamento de dependência
296
Componentes e Interface
Opção 2: O componente que fornece a interface é conectado a ela pelo relacionamento de Realização (entre o componente Fornecedor e a Interface). 
297
Conector de montagens
Estabelece uma ligação entre componentes em que uma interface requerida por um é fornecida por outro 
298
Conector de montagens
ImageObserver é uma interface
Componente.py Implementa (fornece essa interface)
Imagem.py depende da interface
299
Exemplo de um componente com
2 interfaces providas : Validar Usuário e Validar Senha
1 interface requerida: Conexão
300
Dependência
Um componente pode utilizar serviços ou depender de alguma outra forma de outros componentes do sistema 
Componente 1 depende de componente 2
301
Componentes x classes
Pode ser utilizado para demonstrar as classes que estão sendo implementadas ou manipuladas por um componente.
302
303
Flexibilidade da solução.
A solução permite flexibilidade em mudanças.
Se for alterar a técnica de criptografia ou ampliar as possiblidades com novas técnicas, basta substituir ou adicionar novos componentes.
Se quisermos trocar o firewall, basta substituir o respectivo componente. 
Se mudarmos o SGBD , basta substituir o respectivo componente
304
Diagrama de Implantação
Mostra o layout físico de um sistema, revelando quais partes do software são executadas em quais partes do hardware (FOWLER). 
Enfoca a estrutura física sobre a qual o software vai executar. 
Define como as máquinas estarão conectadas e através de quais protocolos se comunicarão.
Elementos: os nós e as conexões entre eles. 
305
Elementos do Diagrama de Implantação
Nó: recurso computacional de um sistema, como servidores, impressoras, terminais remotos, computadores pessoais, software, banco de dados dentre outros. 
Em geral o nó é identificado por um nome, 
306
Elementos do Diagrama de Implantação
Em diagramas de implantação, a existência de componentes dentro de um nó, pode ocorrer.
Possibilita definir a configuração do nó: capacidade de processamento, memórias principal e (discos).
307
Nó – componentes e relações
308
Esteriótipos de um nó.
309
Caminhos de comunicação - conexões
Os nós são conectados por conexões, que é um relacionamento de associação, 
Nesse caso a associação representa uma conexão física entre os nós.
Multiplicidade (1..*), papel e nome do relacionamento (TCP/IP)
310
Exemplo de Diagrama de Implantação
311
312
313
314
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Atividades
Sobre o diagrama de componentes, analise:
Ele apresenta os componentes que irão compor o software bem com a dependência entre eles
A dependência entre os componentes denota que um componente precisa do outro para executar as suas funcionalidades
A reutilização de componentes entre vários sistemas é um desejo da equipe de desenvolvimento
Um componente pode ter apenas interfaces requeridas
Assinale a única alternativa correta.
316
( ) estão corretas apenas I, II e III
( ) estão corretas apenas I, II e IV
( ) Estão corretas I, II, III e IV
( ) Estão corretas apenas I e II
( ) está correta apenas I 
317
Com base nos diagramas de componentes e implantação, analise.
I. O diagrama de implantação modela os aspectos físicos, mostrando a organização do hardware.
II. Um componente deve ser adaptável a um sistema através de sua interface.
III. O diagrama de componentes mostra as dependências entre os elementos do hardware que sustentará o software.
IV – O diagrama de implantação pode conter componentes em seus nós.
Assinale a ÚNICA opção correta, 
318
( ) estão corretas apenas I, II e IV
( ) estão corretas apenas I, II e II
( ) Estão corretas I, II, III e IV
( ) Estão corretas apenas I e II
( ) está correta apenas I 
319
Sobre o diagrama de implantação,   é INCORRETO afirmar:
( ) É direcionado para a distribuição, entrega e instalação das partes que formam o sistema físico.
( ) É um conjunto de nós conectados, onde um nó é única e exclusivamente uma estação ou servidor.
( ) Os elementos são os nós e as conexões.
( ) Envolvem a topologia do sistema, descrevendo a estrutura do hardware.
( ) Pode ser integrado ao diagrama de componentes, mostrando que componentes executam em que nó.	
320
Modelagem de Sistemas
Marcelo Vasques de Oliveira
Aula 10
Aula 10 – Estudo de caso aula 6
Diagrama de estados
Diagrama de atividades
Diagrama de classes de projeto
Diagrama de componentes
Diagrama de implantação
322
Diagrama de Estados
Base: diagrama conceitual de classes
323
Diagrama de Estados
Cliente – Os objetos da classe cliente tem apenas 1 estado em todo ciclo de vida  não há necessidade de DTE.
Pedido: possuem vários estados ao longo do ciclo de vida, em função da fase em que o pedido se encontra  precisa de DTE.
Itens Pedido – é classe que compõe a classe Pedido e depende do estado de pedido  não há necessidade de DTE.
324
Diagrama de Estados
Conclusão: