Spring

Blog referente a aula do dia 19/06/2008

Spring

Spring é um framework open source baseado nos princípios de inversão de controle e injeção de dependência já falados aqui neste blog.

No Spring é o "container" que instancia as classes da aplicação JAVA, definindo as dependências entre elas através da configuração de um arquivo XML permitindo assim um baixo acoplamento entre as classes.

Possuidor de uma arquitetura baseada em interfaces , o Spring surge como uma boa alternativa ao complexo uso dos EJB's.

Esse Spring é danado mesmo !!!

Boa semana a todos

Boa sorte na prova

Bibliografia:
http://pt.wikipedia.org/wiki/Spring_Framework

XP - Extreme Programing

Blog referente a aula de 10/6/2008

XP - Extreme Programing

Extreme Programing

É uma metodologia de programação ágil para equipes pequenas que trabalharam no desenvolvimento de softwares com poucos requisitos e com muitas mudanças durante a sua implementação

Geralmente formado por grupos de 12 pessoas.

Surgiu nos anos 80 através do Small Talk, é vc programar de modo eficiente , seguindo alguns critérios de comportamento , tais como:

Programação em Par – ou seja , um programa e o outro acompanha o código dando sugestões ao parceiro sobre algum erro.

O XP se baseia em 4 valores fundamentais:

Feedback:

Nele o cliente reaprende com o sistema e o reavalia, ou seja vc pega programa mostra ao cliente e ele lhe dá o sinal positivo de retorno , se ficou bom ou não.

Comunicação:

Como a equipe é pequena , a comunicação é total e bem vinda, rende muito mais na produção.

Simplicidade

Nada de invenções ou previsões, ou seja implemente apenas o necessário.

Coragem

Ousadia , alterar algo que já esta certo procurando uma maior melhora, correr o risco de estragar algo que já esta funcionando muito bem.

O XP se destina a grupos de programadores pequenos, projetos rápidos , e linhas de código bem volumosas , de 1000 a 250.000 linhas.

Os princípios do XP são comunicação total com o cliente visando o feedback , simplicidade total no programa, nele valoriza-se muito pessoas que sejam aptas e que queiram mudanças , ou seja não tenham medo de mudar e aceitem desafios.

Nele a alta qualidade no desenvolvimento é essencial.

Práticas do XP

Jogo do Planejamento

Planejamento é essencial entre os programadores
Fases Pequenas
O desenvolvimento é feito em iterações semanais , onde desenvolvedores e clientes interagem entre si para o bom desenvolvimento, sendo que o cliente tem papel fundamental , pois ele fica sabendo o que esta acontecendo e o que virá a acontecer no projeto.

Metáfora

Baseia-se em exemplos, em situações , usando-as metaforicamente na solução do dia a dia.
É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

Projeto Simples

Simplicidade é o princípio fundamental do XP, se o cliente o mandar fazer uma aplicação de login com senha 123 , faça apenas o que ele pediu , não se preocupe com restrições , programação fácil deve ser substituída por código simples.

Testes

Primeiro crie os testes unitários , depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

Refatoração

Aproveitar código já existente , atualizando-o visando a sua melhora, processo que permite a melhoria continua da programação, melhora a clareza do código.

Exemplos de refatoração:

- Mudanças de nome de variáveis , classes e etc.
- Pequenas mudanças na arquitetura.

Programação em par

Dois programadores juntos , um digitando e o outro acompanhando o código digitado, geralmente coloca-se um programador inexperiente com um já experiente , onde o menos “maduro” fica no computador digitando o código e o instrutor fica ao seu lado auxiliando-o no seu desenvolvimento , este trabalho coletivo beneficia o trabalho proporcionando um código fonte de melhor qualidade.

Exemplo de programação em par
EX:Sistema de multimídia orientado a objetos.



Propriedade Coletiva

Ninguém é dono do código , propriedade coletiva, tanto que qualquer desenvolvedor da equipe pode mudar e melhorar o código do outro.

Integração Contínua

Sempre que produzir uma funcionalidade , nunca demore muito tempo para integrá-la a versão atual do sistema , procure sempre que terminar sua aplicação integrá-la em tempo real.

Semana de 40 horas

Trabalhar com qualidade , sem horas extras, horas extras são permitidas somente quando trouxerem produtividade a execução do projeto, não existe essa de levar serviço para casa , trabalhe bem e produza bem no seu horário de serviço.

Cliente junto aos desenvolvedores

O cliente participa de todo o processo de execução do sistema , podendo até opinar.
Padronização do código

Código padronizado

Deve se seguir certas normas, pois assim um código digitado por vários desenvolvedores fica integrado , como se fosse feito por um só , sem confusões.

Pequenos releases

Liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente

O código

Padrões de implementação adotados por todo o grupo, tem que ser o mais claro possível e entendido por todos os desenvolvedores.

Até a próxima

Bibliografia:

WIKIPEDIA: http://pt.wikipedia.org/wiki/Programação_extrema

Variações Protegidas

Blog referente a aula do dia 09/06/2008

Variação Protegida

Solução das variações

Problema

Como que se consegue projetos de maneira que , o que você tenha implementado nesses elementos não prejudiquem a '"boa" execução dos outros?

Uma boa solução seria identificar os pontos de variação, atribuir responsabilidades a estes pontos criando uma interface que atue estavelmente entre eles.

1. O princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas. Ela atua contra essas variações.
   
   Posso dizer como desenvolvedor “verde” ainda que para se obter uma boa VP no começo segue-se alguns princípios como encapsular dados, interfaces e um bom uso do polimorfismo, só que com o tempo e amadurecimento , se aprendem novos mecanismos para proteção contra variações:
   
   Segue abaixo alguns mecanismos de VP
   
   Projetos dirigidos por dados (data-driven designs)
   
   Este projetos englobam técnicas de inserção em código , leitura de valores , inspeção de caminhos de classe , 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: Ex:(SOA) – Analise Orientada a Serviços
   
   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).
   
   Proporciona ao cliente uma proteção contras as variações que possam ocorrer na localização dos serviços.
   
   Projetos dirigidos por interpretador:
   
   Um bom exemplo é a JVM, são projetos baseados em regras de uma fonte externa, ou seja é uma máquina virtual onde coloca-se regras dentro dela e ela toma decisões em cima daquelas regras.
   
   Projetos reflexivos:
   
   Ao meu entender funciona da seguinte maneira, funciona como uma substituição de métodos, ou seja , o fato de se apagar um método de uma aplicação não trava o sistema, pois ele é substituído por um método existente.
   
   Acesso Uniforme:
   
   Existente somente em algumas linguagens.
   
   Como posso explicar isso !!!, bom ao meu entender ele valida as denominações dos tipos no código de qualquer maneira , ou seja , vejamos o exemplo abaixo para uma melhor explicação.
   
   Ex: avião.decolar;
   
   “Decolar” no caso acima é aceito de duas formas , tanto como método quanto atributo e é aí que entra o entendimento do acesso uniforme, ele aceita as duas formas.
   
   O C# é um bom exemplo de acesso uniforme , pois ele aceita essa forma de definição.
   
   Princípio da substituição de LISKOV
   
   Introduzido por Bárbara Liskov é resumida da seguinte forma:
   
   Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
   
   Essa visão de subtipo é baseada na noção de substituição, ou seja , se B é um subtipo de A, então os objetos do tipo A, em um programa, podem ser substituídos pelos objetos de tipo B sem que seja necessário alterar as propriedades deste programa.

Uma ótima semana a todos e boa sorte na prova de segunda !!!!!

Bibliografia

Livro: UTILIZANDO UML E PADRÕES - Craig Larman

http://pt.wikipedia.org/wiki/Princípio_da_substituição_de_Liskov

Indireção

Blog referente a aula do dia 02/06/2008

Bom dia caros visitantes, hoje falarei sobre um padrão muito interessante , interessante pelo fato de que ele facilita e muuuuiiiiiiitooooo a vida de um desenvolvedor, projetista,analista e etc...

No episódio de hoje !!!

Indireção

O problema surge justamente em saber a qual objeto atribuir a responsabilidade de ser o mediador evitando a ocorrência de acoplamento direto entre os objetos.

Uma boa e inteligente solução para este tipo de problema seria a criação de um mediador, ou seja , cria-se um objeto intermediário para controlar outros componentes causando uma indireção entre eles.

Em outras palavras , o padrão Indireção atribui responsabilidade a um objeto intermediário para ser o mediador entre outros componentes, evitando assim que eles sejam diretamente acoplados.
Um bom exemplo disso seria como na Invenção Pura, a utilização do Armazenamento Persistente que atua como um intermediário entre a venda e o banco de dados.

Uma das maiores motivações para a indireção é o acoplamento fraco, onde um intermediário é usado para desacoplar os componentes.

A Indireção serviu como padrão modelo para muitos outros padrões, o adapter é um deles , até Invenções Puras são criadas através do padrão indireção.

Uma de suas vantagens é o fraco acoplamento entre suas classes.

Boa semana a todos !!!

Bibliografia:

http:// groups.msn.com/cafedotnet/grasppadresssoftware.msnw

Livro - UTILIZANDO UML E PADRÕES - Craig Larman

Invenção Pura !!!!!

Blog referente a aula do dia 26/05/2008

Solução

Consiste em inventar uma classe que suporte a coesão alta , acoplamento fraco e a reutilização, é uma classe fruto da imaginação, inventada de momento, o que acaba por tornar o projeto muito puro.

O problema se origina de maneira ao se atribuir responsabilidades apenas as classes de domínio, acaba por ocasionar problemas com coesão e acoplamento, ou pior tornam a classe impossível de ser reutilizada.

Veja um exemplo:

Pelo que entendi , a classe venda de acordo com o padrão especialista seria o responsável por salvar as suas próprias instancias em um banco de dados, só que é importante salientar que:

Seriam necessárias dúvidas operações de suporte relacionadas a banco de dados, nenhuma delas relacionadas a venda , o que tornaria a classe "Venda" não coesa.

Além disso a classe venda precisa ser acoplada ao banco de dados relacional aumentando assim o seu acoplamento.

Sendo assim , mesmo que o padrão especialista concorde que venda é a classe essencial para salvar a si mesma em um BD, ela leva todos os problemas que pedem que seja inventado algo e é aí que entra a invenção pura.

Uma solução seria criar uma classe exclusiva, exclusiva no sentido de ser utilizada somente para salvar os dados em um banco de dados relacional através de armazenamento persistente.

Peraí , mas o que vêm a ser "Armazenamento Persistente"??

Nada mais é do que algo criado por conveniência para auxiliar o desenvolvedor.

Segues abaixo alguns dos problemas resolvidos por invenção pura:

- A classe fica bem projetada com alta coesão e acoplamento fraco.

A classe armazenamento persistente por ser usada como auxilio ao desenvolvedor torna-se apta as ser utilizada várias vezes.

Por hoje é só pe-pe-pessoal, hehehe

Até semana que vêm.

BIBLIOGRAFIA:

http://groups.msn.com/cafedotnet/graspadress

UTILIZANDO UML E PADRÕES - Craig Larman

Inversão de Controle e Injeção de Dependência - 26-05-2008

Referente a aula 25 do dia 26/05/2008

Vamos aprender mais ???

heheheheh

Hoje nós iremos aprender um pouco sobre dois assuntos muito importantes !!!

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

Inversão de controle – Também chamado de princípio de hollywood, ou seja “não nos chame , nós chamamos vc” . Um exemplo disso é o Template Method.

É uma forma de controlar e desenvolver aplicações de forma a deixa-las mais simples e mais limpas . Digamos que ele seja usado para dar uma certa “elegância” ao código.

Injeção de dependência – É uma técnica utilizada pra instanciar classes concretas, se fazer um acoplamento entre elas. Projetos que usam este tipo de injeção beneficiam muitos containeres de injeção de dependência.
É um padrão utilizado quando é necessário manter o baixo nível de acoplamento entre os módulos do sistema.
Neste tipo de Padrão as dependências entre os módulos não são definidas pelo programador e sim pelo container, este sim é responsável por injetar os componentes. Este padrão se relaciona com o padrão inversão de controle , mas isso não quer dizer que os dois tenham propósitos idênticos ou sejam a mesma coisa.

Olha , gostei muito desse assunto , espero que os próximos assuntos não sejam tão chatos e complexos como os anteriores.

heheheh

Ta pensando o quê !!!!, pensa que ser um bom desenvolvedor é fácil !!!!

Rala meu filho !!!!, rala !!!

heheheheh

Até o próximo blog !!!

BIBLIOGRAFIA:

http://pt.wikipedia.org/wiki/Inversão_de_controle

Padrão GRASP Polimorfismo

Blog referente a aula do dia 26/05/2008

Padrão GRASP Polimorfismo

Ao falarmos de padrão Polimorfismo , ele já nos aparece como uma solução para um determinado problema.

Como tratar alternativas baseadas no tipo ? como criar plugins ??

Solução: Quando alternativas ou comportamentos relacionados variam com o tipo, é só atribuir responsabilidades aos tipos usando operações polimórficas.

Um bom exemplo:


Ao meu ver , na programação orientada a objetos , o polimorfismo permite que classes mais abstratas representem o mesmo comportamento de classes concretas que referenciam , sendo assim um método pode apresentar várias formas.
O polimorfismo de torna muito importante pois permite que a semântica de uma interface seja efetivamente separada da implementação que a representa.

Os benefícios do polimorfismo , são muitos , mas o principal é a sua clareza e facilidade de manutenção do código.

Exemplo:

public void mostrarCalculo (int operacao, double x, double y)
{ System.out.print("O resultado é: "); switch (operacao) { case SOMA: System.out.print(""+(x+y)); break; case SUBTRACAO: System.out.print(""+(x-y)); break; //... outras operacoes default: throw new UnsupportedOperationException() }}

Além do código ser maior e mais difícil de ler, essa implementação tem outros problemas. Provavelmente esse não será o único método a utilizar operações matemáticas e, portanto, pode-se esperar não um, mas vários switchs como esse pelo código. O que acontece, então, se uma nova operação for adicionada ao sistema? Será necessário que todos os switchs sejam encontrados e substituídos. Com o polimorfismo, a modificação restringiria-se apenas a criação de uma nova classe.

Bom fds a todos !!!

Até o próximo blog.

BIBLIOGRAFIA:

http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/proj1/proj5.htm

UTILIZANDO UML E PADRÕES - Craig Larman

Padrão MVC

Blog referente a aula 23 do dia 12/05/2008

Padrão MVC

Para começar podemos dizer que MVC é um padrão de arquitetura de software, com o aumento da complexidade das aplicações torna-se viável separação entre os dados e o layout e o Model-View-Controler separa perfeitamente as tarefas de acesso aos dados e a lógica do negócio.

No meu entender um domínio pode ser considerado como a melhor representação do Model , por exemplo Aluno-Professor e Turma fazem parte de um sistema acadêmico.

Muitas aplicações usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar dados. MVC não cita especificamente a camada para acesso aos dados, porque subentende-se que estes métodos estariam encapsulados pelo Model.

Também é no model que ficam armazenadas as regras de negócio.

Neste Padrão é comum dividir a aplicação em camadas separadas: apresentação , domínio e acesso a dados. Em MVC a camada de apresentação também é separada pela View e pela Controler.

View – uma View nada mais é do que uma alternativa para observação de dados de uma ou mais entidades , entidades essas que formam a base de dados.

O View renderiza o model em uma forma específica para a iteração , geralmente uma interface de usuário.

Elas nos possibilitam muito mais do que uma visualização dos dados , as Views também podem ser utilizadas em aplicações.

As Views são responsáveis por enviar dados para o Frame ou seja ela mostram os dados no Frame e recebem também os dados do frame.

A View guarda os seus dados na forma de uma tabela virtual armazenando também em cache , pois todas as aplicações executadas ou não são armazenadas em cachê.

O controler processa e responde a eventos , geralmente ações do usuário , ele geralmente provoca alterações no model.

Até o próximo Blog

BIBLIOGRAFIA:

http://pt.wikipedia.org/wiki/MVC

UTILIZANDO UML E PADRÕES - Craig Larman

Padrão Command

Padrão Command

Referente a aula 22 do dia 5/5/2008

O polimorfismo nos permite encapsular uma informação ou um comando como um objeto.

Permite estabelecer a assinatura de um método muitas vezes pela utilização de um execute ( ) ou um perform ( ).

Isso acaba permitindo encapsular uma informação como um objeto. Um exemplo clássico da importância da utilização do padrão command é a utilização de telas de menu, pois quando o configuramos , temos que configurar os menus com ações que o usuário queira que eles façam assim que for clicado o botão , ou seja quando for executar um comando de salvar ou carregar.

Uma forma de fazermos com que nossa classe utilize um de nossos métodos quando o usuário clicar é usando o polimorfismo , ou seja tornando o nome da operação fixo , variando assim a sua implementação.

Por isso quando se trata de uma aplicação onde serão usados muitos menus independentes, a melhor solução a ser utilizada seria o padrão command.

Um método que o item menu chama quando um usuário o chama é o actionperformed ( ) , mas podemos vir a pensar nele como um execute ( ).

Quando criamos um objeto JmenuItem, podemos fornecer-lhe um comando para executar quando o usuário selecionar o item, nossa intenção em usar o action performed é criar um método que toma uma ação que satisfaça o comando do usuário , geralmente nesses casos , faz-se o uso de uma classe anônima.

Até a próxima !!!!!

http://www.javafree.org/news/view.jf?idNew=1246

http://www.javafree.org/news/view.jf?idNew=1246

http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm

Padrão Observer

Blog referente a aula 21 do dia 28

Padrão Observer

Defini uma dependência entre objetos , para que assim ,quando um destes objetos mudar de estado , todos os seus dependentes mudem junto automaticamente.

Vejamos , os objetos aqui no caso são observadores , ou seja , eles observam as mudanças ocorridas nas classe e notificam os objetos sobre as mudanças , mudando todo o seu estado automaticamente.

Mas como todos os padrões que nós já vimos aqui , o Observer também apresenta problemas , pois como faríamos para garantir que os objetos de dependem de outro objeto acompanhem as mudanças
daqueles objetos, e principalmente fazer com que o objeto de interesse atualize os outros objetos quando a mudança ocorrer.

Só que todo esse processo pode ocasionar risco , um deles seria o relacionamento bidirecional entre os objetos , relacionamento esse que pode ocasionar o alto acoplamento.

Uma das grandes vantagens do padrão Observer é a possibilidade de reutilização de seus objetos, sendo que o seu alto acoplamento é diminuído com a utilização de classes abstratas.

Como desvantagem , o abuso em sua em sua utilização pode causar grandes problemas a interface da classe, o que deixa os sistemas cheios de requisições causando uma tempestade de eventos.

Uma excelente semana a todos e até o próximo blog!!!!!

BIBLIOGRAFIA:

http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/observer.htm

http://www.mundooo.com.br/php/modules.php?name=News&file=article&sid=798

Padrão Singleton

Aula 22 referente a aula do dia 22 de abril de 2008

Padrão Singleton

Possui a função de garantir que uma classe possua uma única instância, possui uma boa semelhança em relação ao padrão criador dos Padrões GRASP.

Outro objetivo desse padrão é prover um ponto de acesso a classe, se bem que temos que refletir sobre os problemas que podem ocorrer , primeiramente , como iremos controlar o número de instâncias da classe em questão , ou de qualquer outras classes, como armazená-las e principalmente como definir o acesso a elas?

É por isso que temos que utilizar o método synchronized, para evitar que dois objetos tentem criar as instancias ao mesmo tempo.

Vantagens do Singleton

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

- Acesso a vários objetos

Desvantagens

- A sua implementação depende da linguagem utilizada
- Difícil de se 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.

Bom , por enquanto é só , pessoal , espero que tenha conseguido clarear bem a idéia do que vem a ser o padrão Singleton.

Bom final de semana a todos e até a próxima.

BIBLIOGRAFIA:

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

http://www.portugal-a-programar.org/forum/index.php?topic=14965.0

Padrões GOF

Aula 19 do dia 14/04/2008

Padrões GOF

Primeiramente , devemos nos perguntar , o que é um Padrão ?

È uma maneira de alcance de objetivo , seja esta de forma documentada ou testada.

Como no bimestre que se passou , falamos de padrões GRASP , daremos continuidade ao nosso estudo ,falando dos padrões GOF (Gang of Four).

Cada padrão nos mostra um problema que acontece várias vezes , so que ele nos dá a possibilidade de confecção de uma solução base que poderá ser utilizada em vários outros objetos, ou seja, através dele nós podemos confeccionar uma solução padronizada , que poderá ser reutilizada várias vezes.

Eu penso que para um leigo qualquer na área as informações fornecidas acima não fazem nenhuma diferença , mas para um desenvolvedor que procura ascensão na área , padrões GOF dão ao profissional na área de TI , um salto em sua carreira , ajudam um desenvolvedor calouro a pensar como um especialista, auxiliam na documentação de sistemas já desenvolvidos ou que venham a ser desenvolvidos e o melhor , facilita bastante na aprendizagem.

Os padrões proporcionam ao desenvolvedor uma melhor organização dos seus sistemas , pois possibilitam o uso de soluções com nome , facilitando assim o entendimento.

Elementos de um padrão

São os que se seguem abaixo:

- Nome: Nome do Padrão a ser estabelecido.
- Problema: Quando se deve aplicar um padrão , e sobre quais condições devemos utilizá-lo.
- Solução.
- Conseqüências.

Padrão Adapter

Sua função é tornar classes com interfaces diferentes compatíveis.
* Momento JAVA – Vamos recordar um assunto que todos nós conhecemos do 3º termo em JAVA , falaremos de interface.
* Interfaces são coleções de métodos que permitem que objetos de uma classe acessem objetos de outras classes.
Este padrão cria uma classe que se adapte as necessidades de outra classe.

Quanto ao tipo de adaptador , existem dois tipos:

Adaptador de objetos e adaptador de classes e como foi pedido no laboratório tentarei confeccionar um exemplo de cada um deles.
Adaptador de Classe

Public class Professor {
Destino [] destino = new Destino [2];
public void concluirDestino ( ) {
destinos[0] = new DestinoEmCurso ( );
destinos[1] = new Adaptador ( );
// ...
}
Public void concluiDestino ( ) {
for (int i = 1; i < destino.length; i++) {
alvo.operacao( );
}
}
}



ADAPTADOR

Public class Adaptador extends ClasseAtual implements Destino
Public void execução ( ) {
String texto = metodoUtilUm(“Aula Ministrada.”);
}
}


Public class ClasseAtual {
Public void metodoUtilUm(String texto) {
System.out.println(texto);
}

}

Bibliografia:

http://padroes-de-projeto-de-software.cartilha.regularize.com.br/list/18/cartilha/post/85/

Boa semana a todos , até a próxima

Padrão Controlador

Referente a aula do dia 25/3/2008

Padrão Controlador

Controlador Problema: Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?

O princípio da separação Modelo-Visão pode ser enunciado em duas partes:- Não conecte diretamente objetos pertencentes à interface com o usuário (visão) com objetos não pertencentes à interface com o usuário (IU).

- Permitir o desenvolvimento separado das camadas de apresentação e negócio.

- Minimizar o impacto na camada de negócio das alterações nos requisitos da interface com o usuário.

- Permitir a existência de múltiplas visões simultâneas para uma mesma camada de negócios (por exemplo, a visualização de dados de vendas na forma tabular ou através de um gráfico de pizzas). O objeto Controlador responde a uma questão básica no projeto de sistemas OO: Como conectar a camada de apresentação à camada da lógica do negócio?O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.

- Um objeto Controlador para todo o sistema- Um objeto Controlador por Caso de Uso (ou por cenário de Caso de Uso) Os benefícios do padrão controlador são:

- Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio

- Oportunidade para controlar o estado do caso de uso.

Bom foi mais ou menos o que eu entendi , admito que em certos momentos não resumi muito , por que tenho que admitir que senti um pouco de dificuldade em explicar este padrão , espero que mesmo assim tenha conseguido passar um pouco de que eu entendi.

Até o próximo blog

Marcos Vinicius

Alta Coesão

Blog referente a aula do dia 24/3/2008

Padrão GRASP Alta Coesão

A abordagem desse assunto nos leva a seguinte pergunta sempre que nos deparamos com classes complexas.

Como gerenciar a complexidade ?

A Coesão mede quão focadas ou relacionadas estão os módulos de uma classe.

Características de uma classe com baixa coesão.

- Difícil de entender

- De difícil reuso

- De difícil manutenção

- Assumi responsabilidades demais , ou seja , causa uma sobrecarga na classe.

E qual seria a solução ???

Atribuir responsabilidades aos métodos mantendo-se a coesão.

Como nós já sabemos , quanto maior a coesão mais baixo o acoplamento e isso é a melhor solução no caso.

Tipos de Coesão

Coesão Coincidental

Nela não existe nenhuma coesão entre os módulos , eles se agrupam por coincidência

public class Angu{

public void acharPadrão ( ){

}

public void calcularMedia ( ){

}

public void obterArquivo ( ){

}

Lógica

Este Padrão tem que ser respeitado assim como o baixo acoplamento, a alta coesão deve ser mantida dentro do método.

Coesão Temporal

Os módulos estão coesos , por algum evento temporal.

Ex: inicializar , finalizar.

Um outro exemplo é o famoso arquivo "INI" do Windows, vc coloca tags nesse arquivo INI que configura tudo, isso é um exemplo de coesão temporal.

Coesão de Comunicação

Nessa coesão os métodos agem sobre o mesmo dado , mas isso não significa que sejam métodos coesos, portanto não deveriam estar juntos.

Coesão sequencial

Essa aí não é tão ruim , mas esta longe de ser a melhor

Ocorre da seguinte maneira , nela os módulos estão juntos apenas pq a saída de um é a entrada do outro.

Coesão Funcional

Nela os módulos estão coesos de tal forma a trabalhar num mesmo objetivo, ou seja todos os métodos estão focados em um único objetivo.

Coesão Procedural

Esta envolvida com agrupamento de módulos, faz com que os módulos se agrupem por procedimentos, mesmo não sendo coesos.

Agora que vimos um pouco sobre alta coesão , vamos falar um pouco sobre as suas consequencias

- Melhora o reuso da classe

- Melhora o entendimento da classe

- Nela vc regula a forma de granularidade da aplicação

Bom , isso foi tudo o que eu entendi até agora , com isso nós encerramos os Padrões GRASP, espero que tenha sido útil a alguém o que eu escrevi , e fico no aguardo de comentários !!!!!

Bom fds a todos

boa prova para todos nós !!!!

Blog referente a aula do dia 17/03

Acoplamento de controle

Ele ocorre quando se quer passar flags de controle entre objetos de forma que um objeto controle o outro objeto.

O objeto A envia uma mensagem ao objeto B e B usa o parametro para decidir o que fazer , a classe varia conforme o parametro passado para ela.

Nesse tipo de acoplamento uma classe tem o poder de controlar o comportamento da outra classe , ou seja a classe Alpha controla todo o comportamento da classe Beta, mas o que nós na verdade queremos é acabar com essa dependencia entre as classes, mas como nós fazemos isso ???

Simples , é só decompor a operação em multiplas operações primitivas.

Acoplamento de dados globais

Ocorre quando dois ou mais objetos compartilham os mesmo dados

Acoplamento de dados internos ( considerado o pior acoplamento)

Ocorre quando um objeto altera os dados globais de um outro objeto ou seja , a classe A altera a instancia de B alterando assim todo o estado de B.

Como se resolve esse problema ?

Usando - se uma variável private e um par de métodos acessores e mutatórios para controlar , principio do encapsulamento.

Bom feriado a todos !!!!!

até a próxima !!!!!!

Blog referente a aula 10 do dia 10/03/08
Baixo acoplamento
Primeiramente o que vêm a ser acoplamento ??
Nada mais é do que a medida da dependência de uma classe em relação a outra.
Baseado nessa resposta podemos definir como baixo acoplamento a não dependência de uma classe sobre outra.
Quando existe uma dependência bem destacada entre duas classes , nós podemos dizer que entre elas existe um acoplamento forte.
Acoplamento forte ocorre muito em herança , associação , agregação , pois elas nada mais são do que relacionamentos de dependência entre duas classes.
Geralmente o Acoplamento forte apresenta alguns tipos de problemas que irei listar abaixo:
1º - É de difícil entendimento , ou seja , nesse caso para se entender uma classe seria preciso entender todas as outras.
2º - Mais difícil de se reutilizar , pois para que se possa reutiliza-lo eu tenho que mudar a classe para um outro lugar , sendo assim eu teria que levar todas as outras classes junto.
3º - De difícil manutenção, ou seja a mudança em uma classe acaba se propagando para as outras classes.
Vendo todos esses problemas , qual seria a solução mais acertada para eles ?
Se alguém respondeu que é minimizando o acoplamento , acertou em cheio.
Diminuindo-se o acoplamento, diminui-se simultaneamente o problema da dependência entre as classes, e lembre-se de que em um diagrama pode ocorrer conflito entre padrões , mas já fique sabendo que sempre que isso acontecer , não perca tempo, opte sempre pelo baixo acoplamento.
Tipos de Acoplamento
- Acoplamento de dados
- Acoplamento de controle
- Acoplamento de dados globais
- Acoplamento de dados internos

Espero que tenha sido bem proveitoso este aprendizado

Até o próximo blog

Boa semana a todos !!!

PADRÃO CRIADOR - PARTE 2

Blog referente a aula 9 ministrada no dia 3/3/2008

By Marcos Vinicius

Padrão Criador – Parte 2

Vejamos a figura abaixo:




Como podemos ver logo acima ,trata-se de um diagrama de classes , onde lógicamente podemos contabilizar 4 classes, colocaremos em código todas as classes do diagrama caracterizando assim o seu criador.

Mas , por onde devemos começar ??

Fácil , aprendi uma importante dica , nós sempre começamos pela classe menos acoplada , ou seja aquela que é menos dependente.

Agora fica fácil determinar por onde começar , como podemos ver na figura acima das quatro classes a menos dependente é Produto , pois ela não depende de nenhuma outra classe , ao contrário de ItemVenda que depende de Produto , Venda que depende de ItemVenda e por ultimo a classe Main que pelo que eu entendi em aula depende de todas as outras 3 classes.

Bom , vamos começar então pela classe produto , que no nosso caso é a menos dependente.

Como ela ficaria em código ??

Confira abaixo:

CLASSE PRODUTO:

Public class Produto // declaração da classe Produto
{
// Quais seriam os atributos de produto ???
// Poderiam ser código do produto , descrição do produto e valor.

private integer idProduto;
private String descrição;
private Double valorUnitário;

// a seqüência abaixo seriam os nossos métodos assessores e multatórios GET e SET.

/*Antes de continuarmos preciso relembrar um pouco das funções de GET e SET, eles são usados para transformar atributos privados e atributos públicos , para que assim possam ser vistos por outras classes , mas principalmente são utilizados para dar controle a aplicação.*/

public string getDescrição(){

return descrição;
}

public void setDescrição (String valor){
descrição = valor;
}

CLASSE ITEMVENDA:

public class ItemVenda {

// Quais os atributos de ItemVenda ??

private Double qtde;
private Produto p;

// abaixo seguem os métodos assessores e mutatórios.

public void set p (produto p){
this.p = p; // lembre que o “p”em questão tem que ser o mesmo que esta no parâmetro.
}

public class Venda {

// Por se tartar de uma classe que executará vários itens , um array viria bem acalhar , mas o array apresenta problemas com relação a tamanho , portanto utilizaremos aqui uma coleção.

Private Set ItemVenda.list = new hashSet( );

// onde a coleção é caracterizada pelos sinais de maior e menor sobre a classe ItemVenda.

Agora fica a pergunta , de onde saiu esse hashSet???

Bom , desculpe a sinceridade , mas até a aula de ontem era novidade para mim , bom , como “Set” é uma classe e não pode ser instanciada , o hashSet é utilizado para que se possa instancia-la.

private Date dataVenda;
private Integer idVenda;

// agora depois de tudo o que foi feito é que eu poderei criar ItemVenda !!!!

public criarItemVenda (Produto p, Double qtde)
{
ItemVenda i = new ItemVenda( ); // o “i” no caso é uma variável de instancia atribuída

i.setP (p);
i.setQtde (qtde);
itemVendaList.add (i);
} // cria um item de venda e a adiciona a coleção.

Continuando a aula do dia 03/03/2008 , como de costume fomos ao laboratório para as aulas práticas onde mais uma vez me impressionei com o poder da ferramenta NETBEANS.

O seu poder compilação é fantástico , temos até a possibilidade de reforçar a nossa lógica , onde através do processo “DEBUG FILE” podemos percorrer a aplicação podendo assim conhecer o passo a passo de toda a execução, é até uma forma de atualização e melhoria de nossos conhecimentos em lógica, não espero a hora de terminar de baixa-la para assim descobrir mais de seus segredos.

Bom , por hoje é só pepepessoal !!! hehehe

Espero que tenham gostado dessa postagem , estava bem mais inspirado hoje !!!

Boa semana a todos !!!!!

Até o próximo blog!!!

GRASP - Padrão Criador - Aula 7

BLOG referente a aula 7 do dia 25/2/2008 – Padrão GRASP Criador.


Boa tarde !!!!!

Bom , conforme combinado semana passada continuarei a explicar os conceitos explicados em aula , vou tentar passar a minha visão sobre o que me foi entendido.

Já começamos a falar do padrão Criador ressaltando um problema característico.

A quem pertence a responsabilidade em criar novas instâncias de uma classe ??

É tão obvio que nem precisa de resposta , visto o nome do padrão , certo ? Ao padrão criador é atribuída essa responsabilidade , é ele quem cria as instancias da classe.

Vamos tomar como exemplo a classe BETA e a classe ALPHA , vejamos que para que beta seja dado como criador da classe ALPHA é preciso que se aplique pelo menos duas das condições abaixo:

- BETA agrega os objetos da classe ALPHA
- BETA contém os objetos da classe ALPHA
- BETA registra as instancias da classe ALPHA
- BETA usa muitos objetos da classe ALPHA
- BETA possui os dados usados para iniciar ALPHA

Se pelo menos duas das condições acima tornarem-se verdadeiras então BETA se consolidará como criador de ALPHA.

Vejamos o exemplo abaixo:

De acordo com a figura acima , quem deveria criar uma instancia de LinhaDetalheVenda deveria ser a classe Venda , pois a mesma agrega as instâncias de LinhaDetalheVenda.

Chegando a essa conclusão temos o seguinte diagrama:

Onde como podemos ver , a classe Venda tornou-se criadora dos objetos da classe LinhaDetalheVenda.

O objetivo mais comum do padrão Criador é encontrar um criador de que tenha necessidade em se conectar com o objeto criado e essa conexão se faz pelo princípio da agregação que se baseia no conceito todo-parte ou montante-parte , como um Avião que agrega uma asa ou um corpo agrega um braço.

Geralmente a criação é um trabalho meio árduo , complexo pois na maioria das vezes é utilizado para melhorar aplicações já existentes melhorando assim a sua apresentação , o que evita o efeito espaguete , como falado em aula.

Bom , sei que parece que não me expressei muito hoje , mas é que este assunto é pequeno mesmo , espero ter me expressado corretamente , aguardo comentários , pois toda e qualquer forma de crítica vinda será considerada como construtiva.

Abraço a todos !!!!

Até o próximo blog.

21/2/2008

Esta postagem é referente a 5ª aula do dia 18/2/2008

Introdução ao GRASP - 1ª Parte:

Estou de volta !!!!!
Mais uma semana de aula , e como aconteceu na semana passada vou tentar passar um pouco de meu entendimento sobre o que foi passado na 5ª aula.

Vamos começar uma introdução sobre o GRASP.
Pêra aí , o que é GRASP ????
Poxa vida!!! ,eu nem começo a explicação e já vou falando grego !!!
Calma !, GRASP nada mais é do que um conjunto de padrões que tem por objetivo atribuir responsabilidades aos objetos.
Mas que responsabilidades ???
São as obrigações dos objetos em relação ao seu comportamento perante a outros objetos.
Podem ser de dois tipos:
Obrigação em conhecer: é a obrigação que um objeto tem em conhecer os objetos com o qual se relaciona assim como os seus comportamentos.
Bom , vou me arriscar e dar um exemplo meu mesmo , me corrijam se eu tiver errado.
Ex: “A classe compra é responsável por conhecer o seu total”.
Obrigação em fazer: Esse é bem mais fácil , é a parte criativa e operacional do processo, nela se cria um objeto , ou pode-se encadear uma ação em outros objetos
Segue abaixo mais um exemplo!!!
Ex: Um empréstimo é responsável por criar TiposDeEmprestimo”.

Pude concluir que essas responsábilidades as quais o assunto se refere são obrigações de um tipo ou de uma classe e que podem possuir diferentes tipos de granularidades.

São duas

Granularidade Baixa - Nela uma responsabilidade pode envolver um único método.

Ex: Criar uma linha de detalhe.

Granularidade Alta - Nela uma responsabilidade pode envolver várias classes e métodos.

Ex: Responsabilidade de fornecer um acesso a um BD.

OBS: é importante salientar algo , é muito importante não confundir responsabilidade com método , pois são duas coisas diferentes , os métodos são usados apenas para implementar as responsabilidades.

Falando em métodos , existem aqueles que agem por sí sós ou ajudam outros métodos.

Exemplo: A classe venda pode definir um ou mais métodos para conhecer seu total. Para conseguir esse objetivo a Venda pode enviar uma mensagem obterSubTotal para cada objeto LinhaDeItemDeVenda.
Fonte: Material do Professor Bosco

Responsabilidades e Diagramas de iteração

Essa parte não foi tão difícil de entender , se eu estiver certo os diagramas de iteração nos orientam quanto as atribuições das responsabilidades aos objetos.

O diagram acima mostra que os objetos da classe venda são responsáveis por criar linhas de detalhe de venda e que devem colaborar com os objetos da classe LinhaDetalheVenda.

Padrões

Padrões descrevem um problema que ocorre frequentemente , então eles descrevem uma forma de solução padrão , solução essa que poderá ser utilizada em vários tipos diferentes de problemas , mas veja que o que se reutiliza são apenas as classes e as suas colaborações.

Curiosidade: Os Padrões GRASP são de Larman , que se não me engano é o autor do livro que adotaremos neste semestre , "é pelo jeito o Larman não é fraco não".

Bom já falei muito dos padrões , mas acho melhor eu parar de enrolar um pouco e começar falando do primeiro padrão que é:

Especialista na informação:

Nada mais é do que a classe que possui a informação necessária para safizfazer a necessidade imposta.

Geralmente é procurada no modelo de projetos.

Bom , mas uma vez espero ter passado com clareza minhas conclusões

Semana que vêm continuarei com a segunda parte sobre este importante assunto

um bom fds a todos !!!!!!

abraço !!!!

Uma introdução a POO(Projeto Orientado a Objeto) na minha visão

By Marcos Vinicius

Maravilha , finalmente estou chegando ao ponto de bala , sexto termo onde começarei a por a mão na massa , ver as tendências de mercado , me aprofundar mais em JAVA e principalmente em UML.
Como pude concluir a matéria em questão ministrada pelo professor João Bosco é uma continuação da rotina de um projeto , pelo que puder entender em UML eu aprendi a fazer os diagramas , já a fase de projeto é como uma tradução do que esta no diagrama para o código propriamente dito.

A fase de projeto que é a nossa área de estudo no momento nada mais é do que colocar no código fielmente toda a análise dos requisitos contidas nos diagramas, tanto a fase de analise quanto a de projeto estão sujeitas a várias mudanças , mudanças essas que podem ser feitas nas implementações até que se estabilize a iteração.

O projeto baseado em objetos é feito em cima dos diagramas de colaboração e de seqüência , mas primeiramente para um melhor entendimento é preciso se perguntar , para que a utilização deles ?

Primeiramente eu entendo que se um sistema nada mais é do que vários objetos , esses mesmos objetos precisam se comunicar , é aí que entram os diagramas de iteração. É nesses diagramas onde ocorre a troca de mensagens entre os objetos , uma forma de ilustração de como os objetos colaboram entre si com o objetivo de atender os requisitos feitos na análise.

Agora vou falar um pouco dos diagramas de iteração , são dois:

Diagrama de Colaboração – Bom não tenho nada contra a preferência de ninguém , mas eu particularmente prefiro o diagrama de seqüência , pois é bem mais ordenado que o de colaboração , o D.C apesar de ser bem ilustrado não apresenta nenhum tipo de ordenação e sua leitura é bem mais complexa , eu mesmo como aprendiz passaria bem longe dele , mas isso é só uma opinião pessoal minha , a única vantagem que eu vejo nele em relação ao de seqüência é a sua flexibilidade em relação a espaço.

Segue abaixo um exemplo um pouco mais complexo que o apresentado na aula:

Fonte: www.netbeans.org/images/diagram

Diagrama de seqüência: Apesar de não ter muita experiência ainda em diagramas , eu já gosto mais deste , pois a sua organização em raias facilita mais o entendimento e é bem mais simples de se entender , não tem erro , o seu fluxo vai de cima para baixo , da esquerda para a direita , sendo que o seu único problema ao contrario do diagrama de colaboração é o grande consumo de espaço.

Segue abaixo um outro exemplo de diagrama de seqüência , diferente ao apresentado na aula:


Fonte: http://www.ime.usp.br/~kon/MAC5715/2002/DesignFest/M2/diagramaDeSequenciaDeEscolheSessao.jpg

Bom , vou tentar mesmo que errando explicar este diagrama .

A mensagem obterSessoes é enviada para uma instancia de ControladordeSessões só que ao contrário do exemplo da aula , essa mensagem é enviada por um ator “Interface do Jogador”.
O objeto ControladorDeSessões envia uma mensagem obterSessões para o objeto ServidorDeSessões ,este por sua vez envia uma mensagem de retorno “Lista de sessões” ao objeto ControladorDeSessões que por sua vez envia esta mesma mensagem “Lista de sessões” ao ator do sistema “Interface do Jogador” e assim por diante os objetos vão se comunicando através das mensagens enviadas.

Obs: Se houver erro na minha tentativa de explicação , aceito opiniões na boa !!!

Bom já expliquei mais ou menos como funcionam os diagramas , agora vêm a parte de como confeciona-los , e como tudo na vida é baseado em regras , aqui vão umas boas regras para uma boa confecção de um diagrama:

Primeiramente , um diagrama precisa ser bem detalhado , fiel ao que esta sendo proposto no projeto , não pode apresentar falhas e nem brechas , deve consumir cerca de 10% do tempo necessário para iteração e deve ser feito por duas pessoas de preferência , pois como foi dito em sala duas cabeças pensam melhor do que uma, dependendo do tipo de projeto até mais cabeças pensantes seriam bem vindas.

Representando as ilustrações no diagrama:

Como foi visto nos exemplos anteriores , os diagramas possuem classes e instancias, vou representa-las a seguir:

Classe: é representada por um retângulo com o nome da classe em sublinhado.

Instância: é representada por um retângulo com o nome da classe em sublinhado precedido de dois pontos.

Mensagens :

Mensagem de retorno: representa uma resposta de um objeto dentro do diagrama de iteração, sendo essa mesma mensagem omitida se for considerada óbvia ou não muito importante.

São indicadas por setas ,essas indicam o fluxo da mensagem dentro do diagrama:

Seta contínua: Mensagem
Seta tracejada: Retorno

Existe um outro tipo de mensagem chamada SELF , onde um objeto "Compra" por exemplo envia uma mensagem para ele mesmo.

Terminando o assunto até esta 4ª aula chegamos a um diagrama bem curioso , no qual existe uma iteração entre um objeto sobre uma coleção de métodos.

Exemplo:

Fonte: Material de aula do professor João Bosco

Bom , para quem leu e gostou , isso é o que me foi entendido até agora , não deixem de entrar , pois semana que vêm tem mais novidades

abraços a todos !!!!!