Os diagramas da UML não precisam ser completos

Um diagrama provê uma parcial representação do sistema. Ele ajuda a compreender a arquitetura do sistema em desenvolvimento. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Dessa forma a UML nos permite ignorarmos alguns detalhes de sintaxe na descrição dos diagramas, desde que os diagramas mantenham o foco na especificação, construção, visualização, e documentação dos artefatos de um software

Diagramas de estados são distintos de diagramas de atividades

Os diagramas de atividade e de estado especificam o comportamento de uma entidade só, seja um objeto instância de uma classe, uma operação ou um sistema. Um diagrama começa ao estado inicial que marca o começo da operação ou do sistema, a criação do objeto, etc. A ”execução” vai seguir as transições de estados em estados (de atividade ou de ação). Um diagrama pode não ter de estado final enquanto não a fim prevista à vida do objeto.

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como uma atividade depende uma da outra. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processo computacional. Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

O objetivo do diagrama de estado ilustra os eventos e os estados interessantes de um objeto e o comportamento de um objeto em reposta a um evento, mostrando o ciclo de vida de um objeto, os eventos pelos quais ele passa, as suas transições e os estados em que ele está entre estes eventos.

Cada classe deve poCada classe deve possuir responsabilidades bem definidasssuir responsabilidades bem definidas

Existem muitas atividades e artefatos possiveis na analise e no projeto, bem como um rico conjunto de principios e diretrizes. Num sistema orientado a objetos a habilidade individual mais importante na analise do projeto é a atribuição de responsabilidade dos componentes do software. Pois é esta atividade que deve ser executada, inevitavelmente, e que tem o efeito mais profundo sobre robustez, a facilidade de manutenção e a re-usabilidade dos componentes do software. Num segundo nivel de importancia, mas nao menos importante, identificar os objetos e abstrações adequadas são fundamentais num processo de desenvolvimento de software orientado a objetos.

Mesmo num processo de desenvolvimento onde o desenvolvedor nao executa as atividades de analise ou projeto, o chamado processo de desenvolvimento do tipo “corrida para codificação”, a atribuição de responsabilidades é inevitável.

A ordem de realização das atividades em um processo de software é importante

Para se criar um software de qualidade que atenda as espectativas do cliente é necessário uma descrição do problema e de seus requisitos, o que é problema e o que o sistema tem que fazer. A análise enfatiza uma investigação do problema, de como uma solução é definida. Também é necessário ter uma descrição de alto nivel e descrição detalhada da solução e de como ela atende os requisitos e as restrições. Após todos esses passos de analise, seguir uma boa metodologia de desenvolvimento, escolher adequadamente a tecnologia junto a aplicação de patterns.

Durante a analise orientada a objetos, há uma enfase na descoberta e na descrição do objetos, ou conceitos, do dominio do problema. Por exemplo, no caso de um sistema de informação para biblioteca, alguns conceitos incluem Livro, Biblioteca e Usuário.

Durante o projeto orientado a objeto existe uma enfase na definição de elementos lógicos de software. Estes objetos de softwares tem atributos e metodos. Seguindo o exemplo, o objeto Livro pode ter um atributo título e um metodo imprimir.

Finalmente, durante a construção do programação, os componentes do projeto são implementados, tais como uma classe Livro em C++, Java, C#, etc.

A ordem que estas atividades são realizadas está fortemente ligada a qualidade final do produto entregue ao cliente. Por isso a importancia de realizar numa derminada ordem as atividades.

Diagramas de casos de uso possuem um foco abrangente e de poucos detalhes enquanto diagramas de seqüência possuem um foco mais restrito e detalhado.

Compreender os requisitos, em parte, compreender os processos do dominio externo de uma forma mais abrangente, mostrar como o sistema interage com seu meio ambiente e descrever as operações que o sistema deve cumprir, são funções de um diagrama de caso de uso. Por serem de facil compreensão, tanto por desenvolvedores e por pessoas da área de negócio, são uma excelente ponte entre o desenvolvedor e os usuários do software. Casos de uso não são um artefato exclusivo da orientação a objeto, e por sua vez podem ser usados num projeto que não usa orientação a objeto. Assim a abrangencia de um caso de uso é maior no ponto de vista funcional, deixando os detalhes de implementação serem demonstrados pelos diagramas de sequencia, que representam as interações entre o sistema e seus atores e promove as funcionalidades ou serviços do sistema numa maneira mais restrita.

Um bom sistema possui uma estrutura de classes com baixo acoplamento e alta coesão

Quando nos referimos a um sistema de classes com baixo acoplamento estamos medindo a interligação entre diferentes classes em um sistema [12 pág. 18], ou seja, quanto uma classe conhece e dependente de outra. Classes com baixo acoplamento são mais fáceis de serem entendidas, testadas, reusadas e mantidas, porque podem ser isoladas e trabalhadas individualmente. Além de todas as vantagens, um sistema com classes de baixo acoplamento promove o paralelismo na implementação do sistema, diminuindo o tempo de desenvolvimento e aumenta a produtividade da equipe.

Por outro lado, um caso extremo de baixo acoplamento é quando não existe ou existe muito pouco acoplamento entre as classes. Isso não é desejável porque uma metáfora central da tecnologia de objetos é um sistema composto de objetos conectados que se comunicam através de mensagens. Se o acoplamento baixo é aplicado em excesso, leva a um projeto fraco, porque conduz a uns poucos objetos ativos, sem coesão, inchados e complexos que efetuam todo trabalho. Ao mesmo tempo existirão muitos objetos praticamente passivos, com acoplamento zero, que funcionem como simples repositórios de dados.

Já quando falamos em coesão estamos medindo o quão relacionadas ou focadas estão as responsabilidades da classe [12 pág. 19]. Uma classe com baixa coesão assume responsabilidades que pertencem a outro contexto, com isso torna-se mais difícil de ser entendida, reusada e mantida. Classes de coesão baixa representam, geralmente, uma abstração de grande granularidade ou, então, assumiriam responsabilidades que deveriam ter sido delegadas a outros objetos.

Grady Booch descreve a coesão funcional alta como algo que existe quando os elementos de um componente (tal como uma classe) “trabalham todos em conjunto, para fornecer algum comportamento bem-delimitado” [14].

Uma série de benefícios é relacionada com a coesão alta, como a clareza e a facilidade de compreensão do projeto aumenta, a manutenção e as melhorias são simplificadas, freqüentemente o baixo acoplamento é favorecido, e a granularidade de funcionalidades altamente relacionadas suporta o aumento do potencial de reutilização, porque uma classe altamente coesiva pode ser usada para uma finalidade muito especifica.

Como exemplo, considere o seguinte diagrama de classe parcial de uma aplicação de venda. Suponha que necessitamos criar uma instância de Pagamento de associá-la a Venda.

Qual classe deveria ser responsável por criar Pagamento? Se a classe POST for responsável em criar o Pagamento, a instância de POST poderia, então, enviar uma mensagem acrescentar pagamento para Venda, passando junto um novo Pagamento como parâmetro

Esta atribuição de responsabilidade acopla a classe POST a conhecimento da classe Pagamento. Neste exemplo isolado, isso é aceitável, porém se continuarmos a fazer a classe POST responsável por realizar algum trabalho ou a maior parte dele, o qual esta relacionada cada vez mais operações do sistema, ela se tornará progressivamente mais carregada com tarefas e perderá sua coesão e conseqüentemente o acoplamento será desfavorecido.

Uma solução alternativa para criar Pagamento e associá-lo à Venda é mostrada na próxima figura:

No que diz respeito ao acoplamento, o segundo exemplo ilustrado é preferível porque é mantido um acoplamento geral mais fraco. Sob o ponto de vista da coesão o segundo exemplo favorece uma coesão mais alta em POST.

Por fim, tanto o acoplamento baixo como a coesão alta são princípios a serem levados em conta em todas a decisões do projeto como padrões de avaliação, ou seja, padrões que um projetista avalia em todas as decisões de projeto.

Overriding (sobreposição)

Na programação orientada a objetos é a característica da linguagem que permitir uma subclasse implementar um método existente na superclasse. A implementação da subclasse sobrepõe o método, com mesmo nome e mesma assinatura, da classe pai. Por exemplo:

public class SuperClasse

{

public void imprimir()

{

// faz alguma coisa.

}

}

public class SubClasse extends SuperClasse

{

// este método sobrepoe o metodo definido na classe SuperClasse.

public void imprimir()

{

// faz alguma coisa.

}

}

Overloading (sobrecarga)

Se dois métodos de uma classe têm o mesmo nome, mas diferente assinatura (parâmetros de tipos diferentes) então dizemos que esse método foi sobrecarregado. O overloading é um truque de compilação que permitir usar o mesmo nome de método para executar diferentes ações dependendo dos parâmetros. Por exemplo:

public class TesteOverloading {

public void somar(int x, int y)

{

System.out.println(“soma de inteiros = ” + (x + y));

}

public void somar(double x, double y)

{

System.out.println(“soma de decimais = ” + (x + y));

}

}

Generalização e Herança

Generalização e herança são abstrações poderosas para compartilhar similaridades entre classes e ao mesmo tempo preservar suas diferenças.

Generalização é o relacionamento entre uma classe e um ou mais versões refinadas (especializadas) desta classe. A classe sendo refinada é chamada de superclasse ou classe base, enquanto que a versão refinada da classe é chamada uma subclasse ou classe derivada. Atributos e operações comuns a um grupo de classes derivadas são colocadas como atributos e operações da classe base, sendo compartilhados por cada classe derivada. Diz-se que cada classe derivada herda as características de sua classe base. Algumas vezes, generalização é chamada de relacionamento is-a (é-um), porque cada instância de uma classe derivada é também uma instância da classe base.

Generalização e herança são transitivas, isto é, podem ser recursivamente aplicadas a um número arbitrário de níveis. Cada classe derivada não apenas herda todas as características de todos seus ancestrais como também pode acrescentar seus atributos e operações específicas [10].

A generalização é um conceito aplicado no momento de criação das classes. Ela é usada na intenção de evitar que classes que possuam atributos ou métodos semelhantes sejam repetidamente criadas. Como exemplo pode-se observar as classes 'aluno' e 'professor', onde ambas possuem atributos como nome, endereço e telefone. Nesse caso pode-se criar uma nova classe chamada, por exemplo, 'pessoa', que contenha as semelhanças entre as duas classes, fazendo com que aluno e professor herdem as características de pessoa, desta maneira pode-se dizer que aluno e professor são subclasses de pessoa.

Encapsulamento

A capacidade que um objeto tem de impedir que outros objetos tenham acesso aos seus dados é denominado de encapsulamento. O encapsulamento é a técnica empregada para garantir a ocultação de informação na qual a interface e implementação de uma classe são separadas sintaticamente. Com isso, somente os métodos pertencentes a um objeto podem ter acesso aos dados encapsulados. O encapsulamento encoraja a modularidade do programa e permite que decisões de projetos fiquem “escondidas” dentro da implementação de modo a restringir possíveis interdependências com outras classes, exceto por meio da sua interface [6].

Assim como abstração, o conceito de encapsulamento não é exclusivo da abordagem de orientação a objetos. Entretanto, a habilidade de se combinar estrutura de dados e comportamento em uma única entidade torna o encapsulamento mais elegante e mais poderoso do que em linguagens convencionais que separam estruturas de dados e comportamento [11].

Um bom exemplo de encapsulamento seria um disco rígido. A interface do disco rígido deixa acessível ao computador (cliente) suas funções de leitura e escrita, os dispositivos mecânicos e eletromagnéticos que o HD utiliza para realizar tais operações não fica acessível ao seu cliente estando assim encapsulados.

Os exemplos a seguir foram escritor utilizando a linguagem Java. Entretanto, a idéia aplica-se a qualquer linguagem de programação OO. Atente ao fato de que cada linguagem de programação define os literais de palavra reservada para definir seus modificadores de acesso.

Sem encapsulamento:

class NaoEncapsulado {

//implicitamentamente há modificador, mas não é o mais restritivo.

int semProtecao;

}

public class TesteNaoEncapsulado {

public static void main(String[] args) {

NaoEncapsulado ne = new NaoEncapsulado(); //ne é uma instância de NaoEncapsulado

ne.semProtecao = 10; //acesso direto ao atributo

System.out.println("Valor sem proteção: " + ne.semProtecao); //acesso direto ao atributo

}

}

Com encapsulamento:

class Encapsulado {

//private é um modificador de acesso de restrição máxima

private int comProtecao;

public void setComProtecao(int comProtecao) {

this.comProtecao = comProtecao;

}

public int getComProtecao() {

return this.comProtecao;

}

}

public class TesteEncapsulado {

public static void main(String[] args) {

Encapsulado e = new Encapsulado(); //"e" é uma instância de Encapsulado

//acesso direto a um atributo protegido implicará em erro de compilação.

e.comProtecao = 10;

//deve-se acessar o atributos de forma indireta, encapsulado.

e.setComProtecao(10);

System.out.println("Valor com proteção: " + e.getComProtecao());

}

}

Polimorfismo

Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura), mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da superclasse. A decisão sobre qual o método que deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução, através do mecanismo de ligação tardia [7].

Quando o método a ser invocado é definido durante a compilação do programa, o mecanismo de ligação prematura (early binding) é utilizado.

Para a utilização de polimorfismo, a linguagem de programação orientada a objetos deve suportar o conceito de ligação tardia (late binding), onde a definição do método que será efetivamente invocado só ocorre durante a execução do programa. O mecanismo de ligação tardia também é conhecido pelos termos dynamic binding ou run-time binding [8].

Na programação, o polimorfismo permite uma extensão continuada do design. Quando novas classes são criadas, elas podem adicionar novos comportamentos a uma função já existente [2].

Objeto

Oficialmente, objeto significa a instancia de uma classe [2]. Mas podemos encontrar uma série de definições para objetos: “um objeto tem o estado, comportamento, e identidade; a estrutura e o comportamento de objetos similares são definidos em sua classe comum; os termos instancia e objeto são permutáveis” [4].

Objetos têm dois propósitos: promover o entendimento do mundo real e suportar uma base prática para uma implementação computacional. Não existe uma maneira “correta” de decompor um problema em objetos; esta decomposição depende do julgamento do projetista e da natureza do problema. Todos objetos têm identidade própria e são distinguíveis [1].

Todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto é um atributo implícito do objeto. Este conceito é suportado na maior parte das linguagens de programação orientada a objeto [1].

O termo objeto foi aplicado formalmente pela primeira vez na linguagem de programação Simula, e nessa linguagem objetos tipicamente existem para simular alguns aspectos da realizada [4].

Classe

Em termos gerais uma classe denota classificação e também tem um novo significado nos métodos de orientação a objetos. No contexto OO, a classe é a especificação da estrutura (atributos), comportamento (métodos), e herança (classes pai, ou estrutura recursiva e comportamento) para objetos [3]. Uma classe de objetos descreve um grupo de objetos com propriedades similares, comportamento similar, relacionamentos comuns com outros objetos e uma semântica comum. Por exemplo, Pessoa e Companhia são classes de objetos. Cada pessoa tem um nome e uma idade; estes seriam os atributos comuns da classe. Companhias também podem ter os mesmos atributos nome e idade definida. Entretanto, devido à distinção semântica elas provavelmente estariam agrupados em outra classe que não Pessoa. Como se pode observar, o agrupamento em classes não leva em conta apenas o compartilhamento de propriedades [1].

Classes e Objetos

Se observarmos nosso meio, quase tudo o que nos cerca podemos chamar de objetos. Até mesmo muitas das tarefas e ações que fazemos são executadas sobre objetos ou, são tarefas que se relacionam a objetos. Carros, livros, copos, roupas, dinheiro... Por vezes os objetos são compostos por outros objetos... Nós humanos pensamos e lidamos com objetos naturalmente. Para quase todos objetos podemos atribuir, ou reconhecer, características, como: cor, tamanho, forma etc. Para outros objetos podemos inclusive atribuir comportamentos, ou funções, como locomoção, alimentação e outras várias.

Um modelo de objetos busca capturar a estrutura estática de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operações que caracterizam cada classe de objetos. É através do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invés de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representação mais próxima do mundo real [1].

A tecnologia da orientação a objetos permite aos designers de sistemas construir estruturas com somente de dados, dados-e-funções, ou somente funções [2]. Dessa forma reduzindo custo, diminuindo o acoplamento e permitindo um maior reaproveitamento de código.

Usando a abordagem de entendimento por exemplos, vamos imaginar que estamos diante de um monitor de computador (ou de um console de vídeo game) que mostre, por exemplo, uma tartaruga numa determinada ação, correndo, ou melhor, vagarosamente se locomovendo. Obviamente que esta deve ser uma tartaruga virtual. Vamos chamá-la de um objeto virtual, algo que foi programado, ou seja, descrito através de um software que animava e propiciava aparência (cor e forma) a este objeto, a esta tartaruga virtual.

Com base no descrito acima e, considerando que o programador usou a abordagem de orientação a objetos no desenvolvimento do seu programa, este programador descreveu em software os estados (as características) e comportamentos (as tarefas) possíveis de uma tartaruga virtual [1].

Referência Bibliográfica

[1] http://www.dca.fee.unicamp.br/cursos/POOCPP/node9.html

[2] Cockburn, Alistair, Surving Object-Oriented Projects – The Agile Software Development

[3] http://www.ipipan.gda.pl/%7Emarek/objects/faq/oo-faq-S-1.3.html#S-1.3

[4] Booch, Grady. Object-Oriented Design With Applications. Benjamin Cummings.

[5] http://dfm.ffclrp.usp.br/~evandro/ibm1030/intro_classe/clas_obj.html

[6] Vicenzi, Amauri Marcelo Rizzo. Tese do instituto de Ciências Matemáticas da Computação – ICMC-USP, maio 2004

[7] http://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/index.html

[8] http://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/latebind.html

[10] http://www.dca.fee.unicamp.br/cursos/POOCPP/node15.html

[11] http://www.dca.fee.unicamp.br/cursos/POOCPP/node7.html

[12] Hohmann, Luke. Beyond Software Archtecture – Creating and Sustainning Winning Solutions

[13] Larman, Graig. Yutilizando UML e Padrões – Uma introdução à análise de ao projeto orienteado a objetos.

[14] Booch, G. Object Solutions: Managing the Object-Oriented Projetc.

Supermercado Compre Bem do Largo do Cambuci

Nada pode ser mais sujo e desorganizado que o supermercado Compre Bem localizado no Lago do Cambuci, em São Paulo.

O espaço é muito desorganizado e sujo. O produtos nas prateleiras estão sempre com poeira. Eu já vi, mais de uma vez, baratas andando entre os produtos. Os legumes, frutas e verduras são de péssima qualidade e sujos.

O atendimento é péssimo. Funcionários sem paciência com os clientes e com má vontade. Já presenciei diversas cenas de descaso com clientes. Um vez no setor de frios esperei uns 2 minutos para ser atendido, os funcionários estavam de papo no depósito atrás do balcão e simplesmente esqueceram que estavam trabalhando.

Como odeio fazer compras nesse lugar. A impressão que tenho, é que esse Compre Bem é o resto do estoque e de funcionários da cadeia. Pois já comprei em outros Compre Bem, e este é o único com esses problemas.

dica de leitura

A ferro e fogo - Josué Guimarães

Vergonha! Esse é o meu sentimento no monento. O que atorcida do gremio esta fazendo no beira-rio é triste. Jogar fogo nos banheiros e tulmutuar o jogo. Uma vergonha.

dentro tinha uma ovo repartido ao meio... guisado, presunto e queijo... um monstro de 30 cm que teima em revirar meu estomago.

pastel filha da p...

já nem durmo mais direito... o meu time só me dá dor de cabeca.

Perder para o Figueirese. Tá certo... jogamos com o time cheio de reservas. Mesmo assim perder para um timinho de SC... faça me o favor.

já esta tracado o plano. O colorado chegara a final da libertadores com o Chivas do Mexico, e é claro, perderá. Como os mexicanos nao sao filiados na conmebol, nao podem participar da disputa do titulo mundial no japao.

O colorado vai para final no japao e perdera a final para o Barcelona. haha 2 gols de Ronaldinho Gaucho.

Vice da libertadores e vice mundial. d+!!!!

secar

secar é uma arte que exige muita concentracao e técnica. Mas ultimamente mesmo usando as tecnicas dos maiores mestres tá complicado secar o colorado. Mas nao vou desitir, ainda falta a semi-final e a final.

rádio argentina

para quem gosta de ouvir futebol no rádio, uma dica para acompanhar o futebol argentino na net é a Rádio Continetal.

http://www.continental.com.ar/

Nao consigo me adapter com o desenvolvimento de sistemas para desktop. A maior dificuldade é criar uma interface grafica, arrastar componentes, organizar e adequar os componentes visuais dentro da tela. É uma dureza!!!

Para fugir dos APIs graficas do Java (basicamente Swing e AWT) estou testando a versao embed do tomcat. Num primeiro momento esta me parecendo facil de trabalhar com esses container web. Este artigo http://www.vsj.co.uk/java/display.asp?id=319 da algumas dicas de como usar o tomcat embed.

artigo interessante

Create Desktop Applications with Java-Based Web Technologies

http://www.onjava.com/pub/a/onjava/2003/09/17/macosxjava.html

dica de leitura

A Metamorfose (Die Verwandlung em alemão), é um conto escrito por Franz Kafka, publicado pela primeira vez em 1915.

dicas de leitura

A Sangue Frio, Truman Capote.

Cem Anos de Solidão, García Máquez.

Paradiso, Lezama Lima

Nem tudo está sendo ruim hoje. O Gremio ganhou do Santo André, 1x0. O jogo foi nervoso. O Gremio não jogou muito bem. Propos um estilo de jogo bem proprio da historia do Tricolor, muita marcassão e vontade. Não lembro de uma chance de gol clara do Santo André.

Todo brasileiro gosta de criticar técnicos da seleção brasilieira, todo mundo quer escalar o time. Um técnico da seleção não deve viver em paz. Imaginem o que o Parreira não deve escutar todos os dias: "pô, como vc não escala o fulano...", "porque vc não tira do time o siclano", "bah Parreira, tem que convocar este aqui e aquele ali....".

Nos últimos dias tá todo mundo reclamando da não convocação do Ronaldo. Eu por exemplo, acho que o Ronaldo e o Ronaldinho são os únicos jogadores intócaveis da Seleção. Mas o Parreira deve ter seus motivos. Ele não iria descartar um jogador como o Ronaldo apenas por birra.

Da-le Grêmio!!!

A última rodada da séria A e B foi de 100% de aproveitamento para os gaúchos. A dupla Gre-nal e Caju ganharam seus jogos. Grêmio e Inter baterem os catarinenses Criciúma e Figueirense em Santa Catarina. O Inter com muita sorte venceu o fraco Figueirense, 1x2. O Grêmio com muita raça venceu o grande Criciúma por 0x2. Com grande atuação do craque Anderson e do goleiro Galatto, o Grêmio mostrou para Criciúma como uma equipe de futebol deve jogar.

Já no lado da Beira-rio, o colorado usou a vantagem de um jogador a mais, e conseguiu vencer com dois gols de Jorge Vagner. Os dois gols marcados no segundo tempo, o primeiro aos 2 e o segundo aos 40 minutos. O gol do Figueirense também foi marcado aos 31 do segundo tempo. Com a vitória Inter assume a 9ª colocação.

O Grêmio com esquema de muita marcação massacrou o Criciúma. Com gols de Saulo (contra) e Samuel, o Grêmio entrou no zona de classificação da série B e ocupa a 8ª posição. Uma posição na frente do Inter.

A vitória fora de casa trouxe esperança para a nação azul e afastou o perigo de rebaixamento. Penso que a vitória em Criciúma foi o primeiro passo do Grêmio em busca do título. Da-le Grêmio!

Bah, este site tá uma carroça Levou quase 5 minutos para eu conseguir chegar aqui no editor.

To aqui de bobeira aqui em casa. Sem muita coisa pra fazer. Resolvi escrever algumas bobeiras.

É foda, levou tanto tempo pra carregar este site que perdi as idéias.

Criando um banco de dados no MySQL

CREATE DATABASE mydatabase;

GRANT ALL ON mydatabase.* TO mydatabase@"%" IDENTIFIED BY "mydatabase";

GRANT ALL ON mydatabase.* TO mydatabase@localhost IDENTIFIED BY "mydatabase";

Deploy de um aplicação no OC4J

1 - gerar o arquivo .ear

2- editar o arquivo %OC4J_HOME%\oc4j-config\default-web-site.xml

3- inserir a linha:

<web-app application="ssof" name="ssof"
root="/ssof" load-on-startup="false"/>

4- executar:

java -jar C:\jdev9052\j2ee\home\admin.jar ormi://localhost:23891
admin welcome -deploy -file
D:\projects\mywork\ssof\deploy\ssof.ear -deploymentName ssof
-bindWebApp /ssof



Feito.

Escrever é uma coisa quem vem fascinando minha vida. Essa forma de expressar idéias, pensamentos e sentimentos é algo novo. Algo que esta se tornando um prazer. Também gosto de contar, através das letras, quais foram os momentos que marcaram minha vida, meus sonhos e desejos.

Exportar/importar as mensagens do Oracle Application.

Exportar:

Inglês:
export NLS_LANG="American_America.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y DOWNLOAD $FND_TOP/patch/115/import/afmdmsg.lct xpmsgport_us.ldt FND_NEW_MESSAGES

Espanhol:
export NLS_LANG="SPANISH_SPAIN.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y DOWNLOAD $FND_TOP/patch/115/import/afmdmsg.lct xpmsgport_e.ldt FND_NEW_MESSAGES

Português:
export NLS_LANG="BRAZILIAN PORTUGUESE_BRAZIL.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y DOWNLOAD $FND_TOP/patch/115/import/afmdmsg.lct xpmsgport_ptb.ldt FND_NEW_MESSAGES

Importar:

Inglês:
export NLS_LANG="American_America.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y UPLOAD $FND_TOP/patch/115/import/afmdmsg.lct xxpmsgport_us.ldt

Espanhol:
export NLS_LANG="SPANISH_SPAIN.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y UPLOAD $FND_TOP/patch/115/import/afmdmsg.lct xxpmsgport_e.ldt

Português:
export NLS_LANG="BRAZILIAN PORTUGUESE_BRAZIL.WE8ISO8859P1"
FNDLOAD user/passwd 0 Y UPLOAD $FND_TOP/patch/115/import/afmdmsg.lct xxpmsgport_ptb.ldt

Mensagem de falha na validação de uma sessão.

"Falha na Validação da Sessão. Pode ser por causa da expiração da sessão ou porque você informou uma combinação de Nome de Usuário/Senha Inválida. Tente estabelecer login novamente. Se você ainda não tiver se registrado, Registre-se antes de tentar novamente. Se tiver problemas, entre em contato com o Administrador do Sistema. "

desenvolver um framework.

Escrever um framework de sistemas corporativos é um grande sonho em minha vida. São vários anos pensando e estudando tecnologias da informação, para tentar, da melhor forma possível, montar uma estrutura de desenvolvimento para aplicações corporativas. Diariamente, me pego pensado em criar o componente X, a classe Y, o método A, o atributo B, etc.
Podem me achar um pouco pirado, achar que é bobagem eu perder meu tempo ou até mesmo falar que quero re-inventar a roda, mas esse é um sonho, e cada um pode ter o seu. No meu caso, desenvolver o framework, será uma realização profissional pra mim. Penso que todo o profissional, não importa a área, gostaria de realizar um projeto em sua carreira.
Acho que agora estou no caminho certo. As idéias começaram a ficar mais claras e objetivas. Um exemplo disso é o ssof. Estou me dedicando muito nesse projeto.
Também não sou tão louco de querer fazer tudo, algumas tecnologias free do mercado pretendo usar, como struts, por exemplo. Tem muita coisa boa por ai que precisam ser aproveitadas.

Quanta novidade surgindo.

É f... a cada dia que passa a quantidade de novidades que surgem no mercado Java é impressionante, frameworks, APIs, patterns, etc., etc, etc, etc.
As vezes da vontade de jogar tudo fora e começar tudo novamente, da vontade até de chorar.
Tô com essa dificuldade no meu projeto. Saio navegando pela net a procura de artigos e idéias, e a todo momento acho um novidade. Da vontade de escrever todo o código novamente.
Hoje mesmo, navegando pelo site da IBM e The server side, achei uma série de artigos sobre sigle sing-on e SAML. Uma idéia melhor que a outra.
Como não da para deixar para trás o que já fiz, é melhor eu acabar de ler os artigos e tentar pincelar algumas idéias.

Mini Web cache

Mini Web cache
Hoje precisei implementar um Web cache. - falando assim até parece que foi algo extraordinário. Algo bem simples, mas tá funcionando. Um dos clientes pediu essa implementação, pois a performance de acesso ao seu Web services não estava lá essas coisas....
Como eu já disse, foi algo simples. Uma classe com um atributo hash estático e privado que funciona como meu cache. Implementei dois métodos de acesso a essa hash, um add e um get. O primeiro insere um objeto no cache, e o segundo lê um objeto do cache.Agora estou trabalhando num mecanismo para limpar os objetos que não serão mais usados - senão, haja memória. Ainda não sei muito bem como será, mas imagino em criar um thread que de tempos em tempos leia e remove os objetos sem utilidade.

O código ficou mais ou menos assim:

public class SessionCache
{
private static Hashtable globalCache = new Hashtable();

/**
* <p>Insere um objeto no cache do usuário.
*/
public static void add(String name, Object value)
{
String sessionId = RequestCtx.getUserId().toString() +
RequestCtx.getAccountId().toString() +
RequestCtx.getResponsibilityId().toString() +
ServletSessionManager.getIcxSessionTicket();

Hashtable uc = (Hashtable)globalCache.get(sessionId);
if (uc == null)
uc = new Hashtable();
uc.put(name, value);
globalCache.put(sessionId,uc);
}

/**
* <p>Pega um objeto do cache ou null se o objeto não existir.
*/
public static Object get(String name)
{
Object value = null;
String sessionId = RequestCtx.getUserId().toString() +
RequestCtx.getAccountId().toString() +
RequestCtx.getResponsibilityId().toString() +
ServletSessionManager.getIcxSessionTicket();
Hashtable uc = (Hashtable)globalCache.get(sessionId);
if (uc != null)
value = uc.get(name);

return value;
}
}

ssof - single sing-on free

Vou começar a escrever sobre o meu projeto, o ssof. Tentarei aqui explicar uma pouco das minhas idéias.

A principal motivação que me levou a começar a desenvolver esse projeto, foi de não ter encontrado nenhuma ferramenta free para single sing-on. Estava trabalhando num projeto de integração de sistemas no meu trabalho, e precisa de uma componente de login único.

O ssof é um framework que fornece um serviço autenticação e controle de acesso a funcionalidades de aplicações. Ele será construído nos padrões de Web sevices da indústria - a idéia aqui é utilizar SOAP, ou quem sabe numa segunda versão utilizar o padrão SAML. O ssof estará apto para suportar single sing-on para aplicações independentes da plataforma na qual for construída.

O site do projeto ainda não está pronto, por esse motivo ainda está na incubadora do Java.net, mas quem quiser acessar, ai vai o link: http://ssof.dev.java.net.

TGA

TGA, Teoria geral de administração. Primeira aula foi hoje. O professor parece ser bom e matéria tb. Tivemos um pouco da história da administração, mas o foco mesmo foi nas teorias da administração. São quatro teorias.

A primeira, administração científica. Taylor propoe a analisa das tarefas dos trabalhadores. O objetivo é diminuir os esforço e aumentar a produtividade. Foi citado como exemplo o fato de um pedreiro que está construindo uma parede. Ele precisa abaixar-se para pegar cada tijolo. Agora, se trouxermos a pilha de tijolos mais próxima do trabalhador, o seu esforço diminuirá e sua produtividade aumentará, e por conseqüência, o lucro da empresa tb aumentará, hehehehehe. Esta teoria foi a mais comentada. O professor até propôs um debate na turma... sem muito sucesso, a galera não estava nem ai com a aula, rsrsrsrsrs.

A segunda teoria é a teoria da abordagem administrativa. Esta teoria propõe a administração da alta gerencia, ou seja, a administração de cima para baixo em uma empresa. Tem 5 pontos chave: planejamento, organização, direção, coordenação e controle. Estrutura-se a gerencia e a diretoria para depois organizar os operários.

A terceira teoria - gostei muito dessa - é a teoria da abordagem do comportamento humano. Para entender melhor essa teoria tem até uma historinha legal. A GE, fabricante de lâmpadas, queria vender seu produto, mas para isso precisa convencer as pessoas da importância da luminosidade no ambiente de trabalho. Numa linha de montagem de uma fábrica americana, a GE aumentou a quantidade de luz. Nesse período perceberam que a produtividade dos funcionário aumentará junto com a luz. Para finalizar com chave de ouro, a GE propos diminuir a intensidade da luz durante o mesmo período. Para surpresa de todos, a produtividade continuou aumentando, ou seja, nada tinha a ver com a luz, e sim com a importância e o status, que durante a pesquisa, os funcionários daquela linha de produção haviam recebido. Esta terceira teoria esta fundamenta na ralação humana, preocupação com o empregado, consideração com as atitudes dos empregados, identificação das necessidades do homem e como estas são satisfeitas.

A quarta e última não entendi muito bem, ou melhor, não entendi nada. É melhor perguntar para o professor na próxima aula.

Cadastro da entidade Principal

Finalizei o cadastro da entidade Principal do meu projeto (SSOF). As telas ficaram meio toscas, mas funcionam. São duas telas: a primeira um lista mostrando todos os Principals cadastrados, e a segunda é a tela de manutenção (INSERT e UPDATE).

To um pouco lento. Preciso acelerar mais.

Vou atacar o cadastro de Sequences agora.

T+.

Meu site

Acho que pode uma ser uma idéia boa. No meu site, criar um área com os meus projetos.

Fim das férias

Tudo que é bom acaba rápido. Essa é a vida. As férias acabaram. A guerra continua.

SSOF - Sigle Sing On Free

O tal sistema de autenticação que citei numa mensagem acima se chama ssof. Sei lá porque dei este nome. Eu imaginava criar alguma coisa livre e open source - Sigle Sing On Free. Abri um projeto para desenvolve-lo no Java.net. Estou esperando aprovação para publica-lo.

Ressaca braba

Velhinho, to numa ressaca. Sai ontem com alguns amigos. Fui no Bar Brahma. Bebi muito. Tudo tá girando.

Tentando montar a grade de matérias na faculdade.

To aqui na faculdade. Par variar, deixai para o último dia das minhas férias para falar com a coordenadora do meu curso e montar a grade de matérias. Adivinhe a surpresa que tive quando cheguei na faculdade? A professora não estava! Eu esqueci que ela não vem nas sextas.

Terei que voltar na segunda.

Sistema de autenticação.

Criar um sistema de autenticação independente de plataforma e linguagem. Um sistema que permita diferentes usuários de outros sistemas utilizarem o mesmo ponto de autenticação e validação de sessão.

O estrutura do modelo de dados é a seguinte: criar uma tabela de usuários internos, que contenha todos os usuários de todos os sistemas terceiros externos cadastrados. Este cadastro central possuirá uma coluna de identificação de cada usuário (índice único). Uma segunda tabela será criada para registrar os sistemas externos envolvidos, o usuário externo e usuário interno. Um de-para entre as colunas do usuário externo e usuário interno. Os campos Sistema Externo mais Usuário Externo, formam um índice único.

Este sistema de autenticação, fornecera mecanismos de chamadas externas para autenticação e validação de sessão.

Os objetos que imagino serem parte desse sistema são: a sessão e um repositório. A sessão será o objeto responsável em armazenar as informações de um usuário que está ou esteve conectado. Uma sessão contém o nome do usuário, a data do login e data do logoff. No objeto sessão tb teremos os métodos de manipulação da sessão, como criar e expirar a sessão. O repositório será o componente responsável em gerenciar as sessões do usuário. O acesso ao repositório e as sessões será feito através de um componente que terá a função de proxy no sistema. Recebendo requisições para leitura e manipulação da sessão.