Aula 30 - Spring

Spring

Spring possui uma arquitetura baseada em interfaces e POJOS (Plain Old Java Objescts), oferendo aos POJOS características como mecanismos de segurança e controle de transações. Também facilita testes unitários e surge como uma alternativa à complexidade existente no uso de EJBs.
Ele foi criado para endereçar a complexidade de desenvolvimento de aplicativos enterprise.
Uma assunto legal para endentemos melhor Spring saber também que é Framework é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de software.
Frameworks são projetados com a intenção de facilitar o desenvolvimento de software, habilitando designers e programadores a gastarem mais tempo determinando as exigências do software do que com detalhes de baixo nível do sistema.

Bibliografia: Conhecimento apresentado na sala de aula pelo Professor João Bosco e www.javafree.org/wiki/Spring

Aula 29 - XP – Extreme Programing

XP – Extreme Programing

É uma metodologia de desenvolvimento de software, nascida nos EUA ao final da década de 90 e a parti desse momento que ela surgiu ela esta fazendo muito sucesso.
Mas que é XP – Extreme Programing?
Ou seja, e uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos realização de vários pequenos ajustes durante o desenvolvimento de software.

Extreme Programming, ou XP, é um processo de desenvolvimento de software 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 a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.

Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
Vejamos alguns valores XP deles:

- Comunicação: O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes.

- Coragem: Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com freqüência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriada de resolvê-los. Embora isso seja natural, gera uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.

- Feedback: Algumas pessoas seriam capazes de caminhar na beirada de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software são iniciativas freqüentemente caras, arriscadas e com um histórico repleto de falhas, o que as leva a simples conclusão de que provavelmente o projeto em que estão envolvidas também enfrentará falhas e problemas, como é habitual na área de software.

- Simplicidade: Programar apenas o que é necessário hoje.

Bibliografia: Apostila,pt.wikipedia.org/wiki/Programação_extrema

Aula 28 - Variação Protegida

Variação protegida

Solução:

Identificar pontos de variação, ou seja, atribuir responsabilidade para criar interface estável em torno deles.

Pois este padrão tem um princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas.

Pois um pode citar alguns de seus mecanismos de VP que são:

Projetos dirigidos por dados: eles são usados para mudar o comportamento do sistema ou talvez impondo padrões em tempo de execução. Ex – XML e WEB-XML.

Pesquisa de serviço: Inclui técnicas como o uso de serviços de atribuição de nomes, um bom exemplo disso é o SOA (Analise Orientada a Serviços).

Projetos dirigidos por interpretador: são projetos baseados em regras de uma fonte externa, ou seja, é uma máquina virtual onde se coloca regras dentro dela e ela toma decisões em cima daquelas regras.

Projetos reflexivos ou meta-dados: funciona como uma substituição de métodos.

Acesso uniforme: ele valida as denominações dos tipos no código de qualquer maneira.

Pois existem também os agentes que são conhecidos como brokess e as máquinas virtuais.

Bibliografia: Livro: UTILIZANDO UML E PADRÕES - Craig Larman

Aula 27 - Indireção - Exemplo

Indireção


Um exemplo que podemos mostra:
Comunicação entre a classe Serviço de Autorização de crédito e o modem (dispositivo): criar a classe modem







Bibliografia: Apostila.

Aula 27 - Indireção

Indireção

Ola galera!

Então o tema que vamos falar agora vai ser sobre Indireção.
Indireção?

Suponha que a sua aplicação precisa manipular um modem para ter autorização de credito
Será que essas operações deveriam estar nas classes de domínio?
Na indireção você consegue evitar o acoplamento direto da seguinte forma atribuir a responsabilidade a um objeto intermediaria que faz a mediação entre os outros componentes, ou serviços.

Bibliografia: Fonte matéria mostrada em sala de aula e apostila

Aula 26 - Invenção Pura

Invenção Pura

É processo unificado que usa classes de domínio para programar.
Que suporta acoplamento fraco, reutilização, coesão alta. Pois ela atribui as responsabilidades principalmente ao especialista pode levar os problemas com acoplamento e coesão.

Problema se consiste em atribuir a responsabilidades quando as classes do domínio não são adequadas não se querem violar os princípios da Coesão Alta e do Acoplamento Fraco? Como criar componentes de software conectava?

Solução seria você atribuir um conjunto de responsabilidades altamente coeso a uma classe arterial-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).

Mas por lado a invenção Pura com ela você ter uma melhora no acoplamento e coesão, cria-se objetos mais genéricos e reutilizáveis e um ponto bem legal que ela é considerada como parte da camada de serviços de alto nível de Orientação a Objeto em uma arquitetura.

Bibliografia: Apostila GRASP

Aula 25 - Inversão de Controle e Injeção de Dependência

Inversão de Controle e Injeção de Dependência

É estamos chegando à reta final!

Agora iremos falar sobre a Inversão de Controle e Injeção de Dependência.

Injeção de Dependência ele é utilizado quando é necessário manter baixo o nível de acoplamento entre diferentes módulos de um sistema, pois nisso os módulos não são definidas programaticamente, mas sim pela configuração de uma infra-estrutura de software (container) que é responsável por injetar em cada componente suas dependências declaradas.
É um padrão que serve para resolver seguintes problemas como desacoplar os componentes de uma aplicação.

Um exemplo disso seria:

Imagine uma aplicação contendo apenas dois componentes: Titulo pulcio e preciifcador. Nessa aplicação, existe uma interface TituloPublico, que descreve operações que podem ser realizadas com TiuloPublico, como vender, comprar, etc. Para essa interface, existe um conjunto de classes que programam essa interface, tais como CDB, etc. Existe também uma interface chamada Precificador. A responsabilidade dessa interface é determinas um preço um determinado título. Essa divisão entre TituloRendaFixa e Precificador corresponde a um padrão de projeto chamado Estratégia, em que criamos uma hierarquia de classes separada para os algoritmos que manipulam os objetos de uma outra hierarquia de classes. Nesse exemplo, a interface Precificador descreve as várias estratégias possíveis de serem utilizadas no cálculo de preço de um determinado título. Como exemplo de algoritmos de precificação diferentes tem: preço de mercado, preço na curva, etc.
Veja que descrevemos tanto TituloRendaFixa como Precificador como interfaces. Uma classe que programe a interface TituloRendaFixa, como a classe TituloNTN não precisa depender diretamente de uma outra classe que programa a interface Precificador, como a classe PrecificadorMercado. TituloNTN deve ser dependente apenas da interface Precificador. A classe PrecificacorMercado também deve ser apenas dependente da interface TituloRendaFixa. Essa técnica de evitar dependências entre classes corresponde a um princípio de projeto, uma boa prática de projeto denominada “Inversão de Dependência”, que não deve ser confundida com “Inversão de Controle”.
Se, no modelo estático, não há dependências entre classes, no modelo de execução, em algum momento, um objeto da classe TituloNTN terá de receber uma referência para um objeto da classe PrecificadorMercado. Esse é o problema que a “Inversão de Controle” resolve: como injetar as dependências entre os objetos (classes), em tempo de execução? Como se trata de injetar dependências entre os objetos em tempo de execução, alguns preferem denominar o pattern “Injeção de Dependência”.

Fonte: Exemplo visto neste site www.alessandroribeiro.com/

Mas também temos Inversão de Controle é onde a seqüência de chamadas dos métodos não é determinada pelo programador. Este controle é delegado a uma infra-estrutura de software muitas vezes chamada container. Esta é uma característica comum aos frameworks.

A diferença entre os dois seria que a Inversão de Controle que da o primeiro sinal, ou seja, ela chama sendo então que você não precisa localizar ela para chamar e Injeção de dependência estimula o uso de abstrações em vez de uma classe concreta.

Bibliografia: Exemplos do site www.alessandroribeiro.com e material exibido na sala de aula.

Aula 24 - Padrão Polimorfismo

Padrão Polimorfismo


E capacidade de um objeto decidir qual método aplicara a si mesmo, dependendo de onde se encontra na hierarquia de herança, e chamada de polimorfismo. O polimorfismo funciona como uma ligação adiada, ou seja, compilador não gera o código para chamar um método com um objeto, o compilador gera o código para calcular qual método chamara,usando assim informação de tipo do objeto.

Os benefícios dele são:

- Ter uma 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 em que o novo servidor suporte as operações polimórficas esperadas pelo cliente.





Bibliografia: Apostila Padrões GRASP.

Aula 23 Padrão MVC

MVC

È um Padrão de arquitetura MVC é uma combinação de padrões centradas no padrão Observer.
O Padrão MVC que significa Model – View – Controller (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 desde padrão foi desenvolvida para mapear as tarefas tradicionais de entrada, processamento e saída para o modelo de interação com o usuário. Nesse padrão MVC ele representa os dados de aplicação e as regras do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.


Ele consiste de três participantes que são:

* Model: 1 – modificar a view quando sofrer a alteração “Padrão observer”.
2 – armazenar o estado da aplicação
3 – responsável por armazenar regras de negócios

* View: 1 – enviar os dados para frame, ou seja, mostrar os dados.
2 - receber os dados do frame, mas não só os dados, mas também as ações.
3 - ao ser notificado solicita o controller a atualização de dados.

* Controller: 1- tratar os eventos da view. “Todos os casos de usos no sistema”.
2 – selecionar o que mostra na view.



Bibliografia: Apostila Mt Digital 2008 e opiniões próprias.

Aula 22 - Command

Padrão Command

O polimorfismo nos permite encapsular uma solicitação como um objeto: estabelecer a assinatura de um método a chamar e variar a implementação desse método.
Pois o padrão command nos permite encapsular uma solicitação, ou seja, um request como um objeto, com isso permitindo assim que clientes usem diversas solicitações diferentes, filas, façam logs e suportem operações de rollback.
Este padrão e conhecido também como action ou Transaction

Podemos ultilizar este Padrão Command quando você precisar usar as seguintes maneiras de aplicação:


- Parametrizar objetos por uma ação a ser executada
- Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command
Poder ter o ciclo de vida independente da requisição do cliente.
- Suporte para desfazer operações. A operação "execute" do Command, pode armazenar.
Estados para reverter seus efeitos no próprio comando. Basta acrescentar na interface
Command uma operação chamada "Unexecute", que terá a responsabilidade de desfazer a.
Operação realizada pelo "execute". Os comandos realizados podem ser armazenados em lista
Histórica.
- Estruturar um sistema em torno de operações de alto nível, como transações, por exemplo. Uma transação encapsula um conjunto de mudanças nos dados. O padrão
Command provê uma maneira de modelar transações. O Command tem uma interface comum,
Assim podemos chamar todas as transações do mesmo jeito.
- Reduzir acoplamento entre as requisições dos clientes e os objetos que as executam.

Bibliografia: Conteudo na sala de aula.

Aula 21 - Observer

Observer

Dependência de um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente.

Vejamos bem este padrão pelo o nome já diz ele observa as mudanças ocorridas pelas classes e notificam os objetos sobre as mudanças que aconteceram.
Pois no observer temos que ter cuidado com o relacionamento (bidirecional) implica alto acoplamento que isso pode ser um do risco que Observer tem.
Mas por outro lado o Observer nos permite delinear a responsabilidade entre objetos de negócios e um Gui, o que nos possibilita estabelecer um projeto MVC, que permite criar camadas fracamente acopladas.

Algumas Vantagens:

· Tanto observadores quando sujeitos observados podem ser reutilizados e tiver sua interface implementação alteradas sem afetas o sistema
· O acoplamento forte implicado pelo relacionamento bidirecional é reduzido com o uso de interfaces classes abstratas


Desvantagens

· O Abuso pode causar serio impacto na performance.
· Sistemas onde todos notificam todos a cada mudança ficam inundados de requisições, ou seja, tempestade de eventos.

Bibliografia: Aposila e conteudo mostra em sala de aula.

Aula 20 - Padrão Singleton

Padrão singleton

E um padrão que garante a existência de apenas uma instancia de uma classe, mantendo um ponto global de acesso.

Algumas Vantagens do Singleton:

Pode vir a possuir subclasses , devido à utilização de métodos estáticos.

- Acesso a vários objetos

Desvantagens

- A sua implementação depende da linguagem utilizada

- Difícil de ser implementar em um ambiente distribuído

- Difícil de implementar em ambiente multithreaded

- De difícil teste , pois pode haver momentos em que suas aplicações dependam de uma instância extra.

Um exemplo de aplicação em Java em Singleton usado log de dados

public class SingletonLog {

// Construtor privado. Suprime o construtor publico padrao.

private SingletonLog() {

// Leitura da configuração de log. Normalmente descrita em um arquivo.

}

// Faz o log de eventos da aplicacao

public void doLog(String eventDescription) {

}

//Retorna a instancia unica da classe SingletonLog

public static SingletonLog getInstance()

{

return SingletonLogHolder.instance;

}

//Classe auxiliar para criacao da instancia. Evita problemas de sincronizacao de threads. private static class SingletonLogHolder {

private static SingletonLog instance = new SingletonLog(); }}

Bibliografia: pt.wikipedia.org/wiki/Singleton.

Aula 19 - Padrão GOF(Gang of Four).

Padrão gof

Para endentemos bem este padrão temos que primeiramente sabe o que é padrão?

Padrão podemos dizer que é maneira de documentada de alcançar um objetivo qualquer, ou seja, padrões são comuns em varias áreas da engenharia.
Pois na para área de informática em desenvolvimento temos que endenter bem esta estudo sobre padrão Gof.

Pois cada padrão descreve um problema que ocorrem repetidas vezes em nosso ambiente, então descreve o núcleo da solução para aquele problema, de tal maneira que pode ser usado uma solução milhões de vezes sem nunca faze-la da mesma forma duas vezes.
Pois a necessita de aprender este padrão e muito importante a através do conhecimento que você pode adquirir sobre ele, porque em alguns casos você precisara resolver certos problemas em que se tiver um conhecimento amplo e certo neste assunto você consegue identificar problemas comuns em engenharia de software e utilizar soluções testadas e bem documentadas.
E tem muito, mas com isso você pode desenvolver software de melhor qualidade.
Mas por outro também você adquiri um amplo conhecimento sobre polimorfismo, herança, modular idade, composição e abstração com esta base você consegue desenvolver software de uma qualidade excelente.

Padrão Adapter

Converter a interface de uma classe em outra interface esperada pelos clientes. Abater permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces.

Bibliografia: Apostila,www.javafree.org, conteudo mostrado em sala de aula.

Aula 16,17 e 18 - Padrão Controlador

Padrão Controlador

Este padrão atribui a responsabilidade de tratar um evento do sistema para uma classe controladora, pois ele e representado como um sistema como um todo, ou seja, controlador fachada, um negocio ou organização com um todo, uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa e por ultimo um tratador que pode ser conhecido como “handler”, ou seja, ele é um artificial para todos os eventos de um caso de uso que resumidamente quer dizer um controlador do caso de uso.
Também no padrão Controlador seus benefícios são maior chance de reuso e outro seria melhor controle sobre o estado do caso de uso. Mas também por outro lado temos que ter cuidados para utilizar este padrão como não sobrecarregar controlador com um numero excessivo de eventos, responsabilidades ou atributos, pois para evitar isso temos que adicionar, mas controladores ou delegar responsabilidades;
Outro ponto interresante seria evitar que o controlador seja representado como papeis de seres humanos, ou seja, que ocupa espaço ou faço coisa que esta delegada para os seres humanos, pois se isso acontecer o risco de baixa coesão; responsabilidades devem ser delegadas para objetos contendo a informação necessária como o padrão Especialista.