UML 05. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan.

Transcrição

1 Faculdade INED UML 05 Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan 1 Referências BARBIERI, Carlos. Análise e Programação Orientada a Objetos - UML BLAHA, Michael; RUMBAUGH, James. Modelagem e Projetos Baseados em Objetos com UML 2. Campus, BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 2. ed. São Paulo: CAMPUS/Elsevier, BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Campus,

2 Abstração Controlar a complexidade pela ênfase em características essenciais e pela supressão de detalhes não é algo concreto, denota a essência principal de alguma coisa. é importante não considerar algo para controlar a complexidade o que não consideramos é a implementação o que consideramos é a interface Exemplo: um estudante universitário é uma pessoa que está matriculada em uma universidade; Exemplo: um curso é oferecido pela universidade. 3 Encapsulamento Colocar tudo da abstração (dados e comportamento) dentro de um container e forçar o acesso às partes internas apenas através da interface pública. agora, aquilo que não queríamos considerar na abstração está escondido; A interface do objeto assegura que toda a comunicação com o objeto seja realizado por um conjunto predefinido de operações; nenhum outro objeto pode acessar ou mudar o valor dos atributos; Abstração é o que se quer, encapsulamento é uma forma boa de fazê-lo facilita mudanças isolando pedaços uns dos outros (reduzindo o acoplamento) 4 2

3 Polimorfismo Habilidade de esconder diferentes implementações atrás de uma única interface. problema O uso de if-then-else ou switch-case, temos que mudar o código sempre que uma nova alternativa surge; A modificação tem que ser feita em todo lugar onde a alternativa deve ser tratada; solução usar operações polimórficas ao comportamento que varia entre os tipos; resultado: não se testa o tipo do objeto, chama-se a operação polimórfica, simplesmente; 5 Polimorfismo 6 3

4 Interfaces conjunto de operações define a interface de uma classe de objetos com o mundo externo; tipo é um subconjunto da interface visível de um objeto; um objeto pode ser vários tipos distintos, ou dito de outra forma, possui as diversas interfaces; 7 Estratégias para identificar conceitos (objetos) Regra fundamental: é melhor ter conceitos demais (muitos conceitos de granularidade pequena) do que conceitos de menos no modelo conceitual; Novos conceitos podem ser descobertos com tempo (quando se está identificando associações ou atributos, por exemplo); Na modelagem de dados para bancos de dados, há um critério de modelagem que diz que algo sobre o qual não precisamos lembrar nada, não precisa entrar no modelo conceitual Com o ponto de visto de persistência, a regra faz sentido Mas na modelagem OO, objetos com apenas comportamento (sem atributos) também são importantes (embora raros) e não devem ser excluídos do modelo; 8 4

5 Achando conceitos através de substantivos - Uma técnica simples para a identificação de conceitos é de isolar os substantivos nas descrições textuais dos Use Cases - Muitos dos substantivos serão conceitos ou atributos Exemplo: Use Case "Comprar Item com Dinheiro Vivo" Alguns desses substantivos são conceitos (objetos), outros são atributos de conceitos: 1. O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar 2. O caixa registra a identificação de cada item. Se houver mais itens, o caixa pode informar a quantidade também. 3. Determina o preço do item e adiciona a informação ao total da transação de Venda. A descrição e preço do item corrente são exibidos. 9 Achando conceitos através de substantivos 4. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV. 5. Calcula e apresenta o total da venda. 6. O caixa informa o total da venda ao cliente. 7. O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda. 8. O caixa registra a quantidade de dinheiro recebida 9. Mostra o valor do troco ao cliente. Gera um recibo impresso 10. O caixa deposita o dinheiro i recebido e extrai o troco a devolver. O caixa entrega o troco e o recibo impresso ao cliente 11. Faz log da venda completada. 12. O cliente sai da loja com os itens comprados 10 5

6 Diagrama de Classes N1 11 Diagrama de Classes N1 12 6

7 Diagrama de Classes N2 O diagrama de classes N2 objetiva: reavaliar novas classes, atributos, t caso necessário; registrar com detalhes a estrutura das classes, com: todos os atributos e seus parâmetros(type, default, etc); todos as operações(métodos) com os seus parâmetros(entrada, saída); evite sobrecarregar com getters and setters; visibilidade/navegabilidade da classe. é o diagrama de projeto físico e sobre ele serão construídos os códigos 13 Diagrama de Classes N2 14 7

8 Diagrama de Classes N2 Fonte: própria. 15 Diagrama de Robutez MVC (model view contoller Modelo de robustez visa a identificação e integração das classes em 3 camadas diferentes: classes de fronteira classes de controle classes de entidades não é oficial da UML pré colaboração usada por metodologistas alternativos(doug rosemberg) e métodos mais lights(iconix) provê excelente ponte entre a análise e o projeto, permitindo o link entre os casos de uso e os diagramas de interação(colaboração/sequência) Passos: projetar o DFT-mapa de navegação de telas de fronteira identificar as classes de fronteira identificar classes de controle, associadas aos casos de uso 16 8

9

10 19 DFD 20 10

11 21 UML Demais diagramas importantes 22 11

12 UML Como fazer? 23 12