Modelagem - Conceitos de Projeto

Herbert Rausch Fernandes

Última atualização: 08/06/2015

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.

Projeto

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,...)

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● Baxio acoplamento (módulos independentes)● Baixa complexidade● Deve-se utilizar uma notação que realmente

condiz com o significado.

Atributos de qualidade

● Funcionalidade

● Usabilidade

● Confiabilidade

● Desempenho

● Facilidade de Suporte

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

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

Por quê usar Padrões?

•Aprender com a experiência dos outrosAlguém já resolveu o seu problema Utilização de soluções testadas e bem documentadasAjuda 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 OOUtilizam eficientemente polimorfismo, herança e

composição

•Padrões de Projeto representam soluções comprovadas para problemas recorrentes em desenvolvimento de software

Por quê usar Padrões?

• Vocabulário comumUso de soluções que têm nome facilita comunicaçãoNível mais alto de abstração

• Ajuda na documentaçãoUso de soluções que têm um nome facilita a documentaçãoConhecimento de padrões de projeto torna mais fácil a

compreensão de sistemas existentes

• Aumento da produtividade

No entanto, Padrões...

•Não apresentam uma solução exataSoluções prontas, que podem ser codificadas diretamente

nas classes e reutilizadas sem adaptação

•Não resolvem todos os problemas de designSão aplicáveis em situações específicas

•Não é exclusivo de orientação a objetos

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

Elementos

• NomeProcura descrever o problema, a solução e as conseqüências em uma ou duas

palavras.

•ProblemaQuando aplicar o padrão e em que condições

•SoluçãoDescrição abstrata de um problema Como usar os elementos disponíveis (classes e objetos) para solucioná-lo

•ConseqüênciasCustos e benefícios de se aplicar o padrãoImpacto na flexibilidade, reusabilidade e eficiência do sistema

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

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

Classificação[3]

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.

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

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.

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.

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

Projeto Orientado a Objetos