[CEFETMG][ESw] Aula 6 - Conceitos de projeto

212 visualizações

Publicada em

Modelagem de Projeto de Software

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
212
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

[CEFETMG][ESw] Aula 6 - Conceitos de projeto

  1. 1. Modelagem - Conceitos de Projeto Herbert Rausch Fernandes Última atualização: 08/06/2015
  2. 2. Projeto “Escrever um trecho de código inteligente que funciona é uma coisa; projetar algo que possa dar suporte a negócios duradouros é outra totalmente diferente.” C. Ferguson.
  3. 3. Projeto
  4. 4. Projeto e Qualidade ● O projeto deve implementar todos os requisitos explicitos na análise do modelo; ● O projeto deve ser legível e entendido por todos os envolvidos na execução; ● O projeto deve ser uma figura completa do software (dados, funções, comportamentos,...)
  5. 5. Diretrizes de Qualidade ● O projeto deve apresentar a arquitetura; ● Precisa ser modular; ● Apresentar o sistema em diferentes perspectivas (dados, arquitetura, interfaces) ● Utilizar estrutura de dados apropriadas ● Baixo acoplamento (módulos independentes) ● Baixa complexidade ● Deve-se utilizar uma notação que realmente condiz com o significado.
  6. 6. Atributos de qualidade ● Funcionalidade ● Usabilidade ● Confiabilidade ● Desempenho ● Facilidade de Suporte
  7. 7. Padrão de Projeto[1] “descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo da sua solução para aquele, de tal maneira que seja possível usar essa solução milhões de vezes.” Christopher Alexander sobre padrões em arquitetura de construções
  8. 8. Padrão de Projeto[2] “Os padrões de projeto são descrições de objetos objetos que se comunicam e classes que são customizadas para resolver um problema problema de projeto genérico em um contexto contexto específico.” Gamma, Helm, Vlissides & Johnson, sobre padrões de projeto em software
  9. 9. Por quê usar Padrões? •Aprender com a experiência dos outros Alguém já resolveu o seu problema Utilização de soluções testadas e bem documentadas Ajuda um novato a agir mais como um experiente •Melhora a qualidade do software •A orientação a objetos, por si só, não garante sistemas reusáveis e extensíveis Normalmente utilizam boas práticas de OO Utilizam eficientemente polimorfismo, herança e composição •Padrões de Projeto representam soluções comprovadas para
  10. 10. Por quê usar Padrões? • Vocabulário comum Uso de soluções que têm nome facilita comunicação Nível mais alto de abstração • Ajuda na documentação Uso de soluções que têm um nome facilita a documentação Conhecimento de padrões de projeto torna mais fácil a compreensão de sistemas existentes • Aumento da produtividade
  11. 11. No entanto, Padrões... •Não apresentam uma solução exata Soluções prontas, que podem ser codificadas diretamente nas classes e reutilizadas sem adaptação •Não resolvem todos os problemas de design São aplicáveis em situações específicas •Não é exclusivo de orientação a objetos
  12. 12. Como selecionar um Padrão? •Entenda as soluções •Estude o relacionamento entre os padrões •Estude as similaridades entre os padrões •Conheça as principais causas de retrabalho •Considere o que pode mudar
  13. 13. Elementos • Nome Procura descrever o problema, a solução e as conseqüências em uma ou duas palavras. •Problema Quando aplicar o padrão e em que condições •Solução Descrição abstrata de um problema Como usar os elementos disponíveis (classes e objetos) para solucioná-lo •Conseqüências Custos e benefícios de se aplicar o padrão Impacto na flexibilidade, reusabilidade e eficiência do sistema
  14. 14. Classificação[1] Podem ser classificados por propósito •Padrões de Criação Abstraem o processo de criação de objetos a partir da instanciação de classes •Padrões Estruturais Tratam da forma como classes e objetos estão organizados para formar estruturas maiores •Padrões Comportamentais Preocupam-se com algoritmos e responsabilidades dos objetos
  15. 15. Classificação[2] Podem ser subclassificados por escopo •Padrões de Classes Tratam de relações entre classes e subclasses (herança) São estáticos, definidos em tempo de compilação •Padrões de Objetos Tratam das relações entre objetos, que podem mudar em tempo de execução
  16. 16. Classificação[3]
  17. 17. Modularidade ● Software monolitico: Um grande programa implementado em um único módulo pode apresentar diversos problemas; ● Na maioria das vezes, deve-se quebrar o problema em diversos modulos mais fáceis de ser entendido e solucionado, em consequencia, reduz o custo de desenvolvimento do software.
  18. 18. Encapsulamento ● Reduz efeitos colaterais; ● Limita o impactos globais em decisões locais; ● Desencoraja o uso de dados globais; ● resulta em um software de alta qualidade
  19. 19. Independência Funcional Coesão ● Indica a força funcional de um modulo; ● Módulos coesos de uma tarefa requer pouca interação com outros módulos. ● Um módulo coeso, no melhor caso, deve-se fazer uma única tarefa. Acoplamento ● É o grau que um módulo depende de outros; ● Quanto menor o acomplamento menor é a complexidade do software.
  20. 20. Refatoração ● É o processo de alterar o código sem alterar o seu comportamento externo. ● Visa melhorar as estruturas internas do software ○ Diminuir a redundância; ○ Remover elementos que não são utilizados; ○ Melhorar algoritmos inefecientes; ○ Melhorar as estruturas de dados utilizados; ○ Quando há uma melhor arquitetura para resolver o probelma.
  21. 21. Projeto Orientado a Objetos ● Projeto de Classes ○ Classes de Entidades Classes que representam os dados a serem persistidos. ○ Classes de fronteiras Tem a responsabilidade de gerenciar como os objetos das classes de entidade são apresentados ao usuários. ○ Classes de controle Tem a responsabilidade de: ● criar e atualizar objetos de entidades; ● instanciação de objetos de fronteiras para receber os dados dos objetos de entidade; ● fazer a comunicação entre conjuntos de objetos.n complex communication between sets of objects; ● validação dos dados. ● Herança ● Mensagens ● Polimorfismo
  22. 22. Projeto Orientado a Objetos

×