Variações Protegidas
Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.Mecanismos de Variações Protegidas· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.Padrão não Fale com EstranhosObjetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.§ Objetos referenciados diretamente – “familiares”§ Objetos referenciados indiretamente – “estranhos”§ Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil· O objeto this· Um parâmetro do método· Um atributo de this· Um elemento de uma coleção que seja de this· Um objeto criado dentro do métodoPor exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.
XP
Extreme Programming, ou XP, é um processo de desenvolvimento de sof-tware voltado para:• Projetos cujos requisitos são vagos e mudam com freqüência;• Desenvolvimento de sistemas orientados a objeto;• Equipes pequenas, preferencialmente até 12 desenvolvedores;• Desenvolvimento incremental (ou iterativo), onde o sistema começa aser implementado logo no início do projeto e vai ganhando novas funci-onalidades ao longo do tempo.Existe uma categoria de processos de desenvolvimento conhecida como Pro-cessos Ágeis de Desenvolvimento, dentro da qual o XP e outros processos seencaixam. Eles compartilham a premissa de que o cliente aprende sobresuas necessidades, na medida em que é capaz de manipular o sistema queestá sendo produzido. Com base no feedback do sistema ele re-avalia as suasnecessidades e prioridades, gerando mudanças que devem ser incorporadasao software. O aprendizado é importante, porque permite que o clientedirecione o desenvolvimento de modo que a equipe produza sempre aquiloque tem o maior valor para o seu negócio.O XP é um processo de desenvolvimento que busca assegurar que o clientereceba o máximo de valor de cada dia de trabalho da equipe de desenvolvi-mento. Ele é organizado em torno de um conjunto de valores e práticas queatuam de forma harmônica e coesa para assegurar que o cliente semprereceba um alto retorno do investimento em software.
terça-feira, 17 de junho de 2008
AULA 29 e 30 - INVENÇÃO PURA, INDIREÇÃO E NÃO FALE COM ESTRANHOS
Invenção Pura
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Problema: A quem atribuir responsabilidades quando as classes do domínio não são adequadas e não se quer violar os princípios da Coesão Alta e do Acoplamento Fraco ? Como criar componentes de software conectáveis ?
- Solução: Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial – que não representa nada no domínio do problema. Tal classe é construída especialmente para melhorar a coesão e diminuir o acoplamento, facilitando a reutilização (uma invenção da imaginação)
Exemplo:
Nesse caso, a solução é criar uma nova classe que é unicamente responsável por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional.
Chamamos esta solução de IntermediárioArmazenamentoPersistente.
Esta classe é uma Invenção Pura.
Beneficios:
-Melhora acoplamento e coesão: a classe venda permanece bem projetada.
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.
Indireção
-Suponha que:
-A aplicação TPV precisa manipular um modem, para transmitir solicitações de autorização de crédito.
-O SO oferece uma API para fazer isso
-A classe ServiçoAutorizaçãodeCrédito é responsável por falar com o modem .Tal classe fica altamente acoplada com a API e o SO.
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-Benefício: Acoplamento fraco – com o objetivo de desacoplar outros componentes ou serviços, introduz-se uma indireção.
-Muitas invenções puras são conseqüências da indireção.
Não fale com estranhos
-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.
-Objetos referenciados diretamente – “familiares”
-Objetos referenciados indiretamente – “estranhos”
-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?
-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio
-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:
-O objeto this (ou self)
-Um parâmetro do método
-Um atributo de self
-Um elemento de uma coleção que é um atributo de self
-Um objeto criado dentro do método
AULA 27 e 28 - PADRÕES GRASP 2ª PARTE POLIMORFISMO
Polimorfismo
- lternativas com base no tipo: variação condicional é comumente encontrada em programas.
- Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
- Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?
- Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
- Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
- Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo
- Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
- Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.
- Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
- Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente.
- lternativas com base no tipo: variação condicional é comumente encontrada em programas.
- Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
- Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?
- Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
- Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
- Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo
- Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
- Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.
- Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
- Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente.
AULA 25 e 26 - PADRÃO MVC
O padrão MVC
O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.
O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.
Camada de apresentação ou visualização - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação.
inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
É a camada de interface com o usuário.
É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.
modela os dados e o comportamento por atrás do processo de negócios
se preocupa apenas com o armazenamento , manipulação e geração de dados
É um encapsulamento de dados e de comportamento independente da apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.
controla e mapeia as ações
Vantagens do modelo MVC :
Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
Torna a aplicação escalável
É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.
Desvantangens do modelo MVC:
Requer uma quantidade maior de tempo para analizar e modelar o sistema
Requer pessoal especializado
Não é aconselhável para pequenas aplicações
Assinar:
Postagens (Atom)