ModelSistemasRevisão

Prévia do material em texto

Modelagem de 
Sistemas
Marcelo Vasques de Oliveira
RAV (1 a 5)
Revisão AV (aulas 1 a 5)
2
Aula 1
–Características e pilares do paradigma orientado a 
objeto
–Análise e projeto orientado a objeto
–A UML e seus diagramas
Aula 2
–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
Revisão AV (aulas 1 a 5)
3
Aula 3
– Importância da especificação de casos de Uso
–Formas e técnicas de especificação de casos de uso
Aula 4
–Conceitos e Elementos do diagrama de classes
–Relacionamento entre classes
–Aplicação do diagrama de classes
• Aula 5
–Os Diagramas de interação
–Conceitos e elementos do diagrama de sequencia
–Aplicação do diagrama de sequencia
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
4
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.
5
Conclusões Paradigma OO
• Conceito de encapsulamento
• Classes independentes, 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 
Reusabilidade e Extensibilidade
• Favorecem desenvolvimento de sistemas grandes e 
complexos
6
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 
• 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
7
DIAGRAMAS DA UML – VERSãO 2.4.1
8
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) e Metodologias ágeis
9
PROCESSOS ITERATIVOS E A UML
10
• Processo com uso de 3 iterações. 
• Em cada uma repete-se o conjunto de etapas.
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 Saldos Bancários
–Gerar Fluxo de Caixa
11
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 
12
Diagramas de Casos de Uso
• Um dos mais informais e simples diagramas
• Finalidades: 
–Mostrar funcionalidades do sistema
–Validar funcionalidades juntos aos usuários
–Todos os requisitos estão considerados ?
– Instrumento de comunicação entre a equipe de 
desenvolvimento.
• A visão do ponto de vista externo, do usuário
• Não mostra detalhes de COMO o sistema realizará 
essas funcionalidades
13
14
15
Especificação de casos de uso – 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
16
1. Identificando Casos de Uso
17
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
18
Caso : Registrar Entrada do hóspede
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
19
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 e Métodos
–Visibilidade e tipos dos atributos
–Classes de projeto (persistência,camadas..) 20
Atributos e Métodos - declaração
• Atributos: visibilidade Nome: tipo
• Métodos: visibilidade Nome (Lista de 
parâmetros) : tipo
21
Associações entre classes
22
• 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
23
Associações Exclusivas
24
Multiplicidade
25
• Quantos objetos de cada classe podem estar 
envolvidos nos relacionamentos.
Multiplicidade
26
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
Classes de Associação
27
Herança
28
Agregação e Composição.
29
• 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
30
• 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
31
Navegabilidade
32
• 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.
O tripé da análise e projeto
33
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..
34
Decisões em Diagrama de Sequencia
35
Decisões em Diagrama de Sequencia
36
Repetições em Diagrama de Sequencia
37
Criação e Destruição de Objetos
38
Tipos de Mensagens
39
Reservar Quarto
40
Cancelar Reservas Dia
41
Diagrama de classes
42
Modelagem de 
Sistemas
Marcelo Vasques de Oliveira
RAV (6 a 10)
Revisão AV(aulas 7 a 9)
2
Aula 7
–Diagrama de Estados
Aula 8
–Diagrama de Atividades
Aula 9
–Diagrama de Componentes e Implantação
Aulas 6 e Aula 10
–Estudo de caso 
• 6 (Casos de uso, classes e sequencia) 
• 10 (Estados, atividade, componentes e implantação)
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
3
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.
4
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.
5
Pseudos estados: Inicial e final
• Inicial: Pseudo estado do objeto no momento 
de sua criação (instanciado na memória(
• Só há um estado INICIAL em um DTE, 
mostrando o inicio de sua leitura 
• Pseudo estado no fim do ciclo de vida 
• É um estado opcional, e pode-se ter mais um. 
6
Transição
7
8
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)
9
Otimizando o Caso Hotel
10
• 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
11
• 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
12
• Regra: Todos os 
estados dentro de 
um estado 
composto herdam 
suas transições.
Elementos do Diagrama de Atividades
• Atividade: retângulo com bordas arredondadas
13
• 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
14
15
16
17
18
19
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, 
20
21
22
Aplicações mais usuais do Diagrama
• Modelagem de processos de negócios e 
Fluxos de trabalho
• Modelagem da lógica de um caso de uso 
complexo
• Modelagem da lógica de uma operação 
complexa
• Modelar a lógica de algoritmos paralelos para 
programas concorrentes
23
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 
 24
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
 2. Retornar ao passo 3 do cenário principal
 
25
26
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 interfaces que são reutilizáveis 
e substituíveis. 
• Especifica a arquitetura do software
27
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. 
28
Exemplo de um componente com
• 2 interfaces providas : Validar Usuário e 
Validar Senha
• 1 interface requerida: Conexão
29
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
30
Realização
• O componente que fornece a interface é 
conectado a ela pelo relacionamento de 
Realização (entre o componente Fornecedor e 
a Interface). 
31
Conector de montagens
• Estabelece uma ligação entre componentes 
em que uma interface requerida por um é 
fornecida por outro 
32
33
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, 
34
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).
35
Nó – componentes e relações
36
Esteriótipos de um nó.
37
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)
38
39
40
Modelagem de 
Sistemas
Marcelo Vasques de Oliveira
Atividades
Os diagramas 1 e 2 são equivalentes ?
42
1
2
Os diagramas 1 e 2 são equivalentes ?
43
1
2
Assinale a opçao INCORRETA
a) ( ) O diagrama de estados deve ser realizado para cada 
classe que tenha ao menos 2 estados.
b) ( ) O diagrama de componentes mostra a relação entre 
as partes do sistema (componentes), que devem ser 
independentes e estensiveis
c) ( ) O diagrama de implantação envolve a topologia do 
sistema, descrevendo a estrutura do hardware
d) ( ) Diagramas de componentes e de estados podem ser 
integrados, mostrando em que nó cada componente 
executa.
e) ( ) O diagrama de atividades pode expressar melhor 
uma descrição longa de caso de uso 44