Modelagem de Sistemas Orientada a Objetos

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