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.