Category Archives: Projetos

Introdução à arquitetura e design de software sobre a plataforma Java

Introdução à arquitetura e design de software – uma visão sobre a plataforma Java

Introdução à arquitetura e design de software sobre a plataforma Java.

Recomendo a leitura do Livro ” Introdução à arquitetura e design de software – uma visão sobre a plataforma java” de Paulo Silveira, Guilherme silveira, Sérgio Lopes, Guilherme Moreira, Nico Steppat e Fabio Kung. (“ ELSEVIER – Campus – Caelum ”) Prefácio de Jum Webber.

Continue reading Introdução à arquitetura e design de software sobre a plataforma Java

Multitenancy

Multitenancy refere-se a um princípio de arquitetura de software onde uma única instância do software executado em um servidor, servindo múltiplas organizações de clientes (lojistas). Multitenancy é contrastado com uma arquitetura multi-instância onde instâncias de software independentes (ou sistemas de hardware) são criados para organizações clientes diferentes. Com uma arquitetura multitenant, um aplicativo de software é projetado para praticamente partição seus dados e configurações, e cada organização cliente trabalha com uma instância de aplicativo virtual personalizado.

Multitenancy também é considerado como um dos atributos essenciais de computação em nuvem .

O princípio da multitenancy não é universalmente aceito e apoiado dentro da indústria de software, e isso pode ser uma fonte de diferenciação competitiva.

Fonte: http://en.wikipedia.org/wiki/Multitenancy

 

Kettle ou Pentaho Data Integration?

Pentaho Data Integration (PDI), também conhecido como Kettle, é uma ferramenta de código aberto, desenvolvida em Java, para Extração, Transformação e Carga (ETL) de dados, ferramenta esta integrante da suíte Pentaho de Business Inteligence (BI).
Todos os processos são criados com uma ferramenta gráfica, que pode ser usada independentemente ou integrada à outras ferramentas do Pentaho.
Dentre as diversas funções, o Pentaho Data Integration, como ferramenta de ETL, pode ser usado principalmente para:
  • Extração: coletar dados de diversas fontes. Podem ser arquivos de diferentes formatos ou das mais distintas bases de dados;
  • Transformação: mover e modificar dados, limpando, denormalizando, agregando e enriquecendo esses dados durante o processo;
  • Carga: armazenar os dados em seu destino final.  Também podem ser arquivos de diversos formatos ou um outro banco de dados.   Normalmente são armazenados em um Data Warehouse.

Tutorial Kettle – Pentaho Data Integration

Pentaho Data Integration (PDI, também chamado Kettle) é um componente da suíte do Pentaho responsável pelos processos de Extração, Transformação e Carga (ETL). Apesar de ferramentas de ETL serem usadas em projetos de data warehouse, PDI pode também ser usado para:
* Migração de dados entre aplicações/banco de dados
* Exportar dados de banco de dados para arquivos texto
* Carregar massivamente dados em banco de dados
* Data Cleansing – disciplina de qualidade/limpeza de dados de data warehouse
* Integração de aplicações.
PDI é fácil de usar. Todos os processos são criados com uma ferramenta gráfica onde você especifica o que fazer sem escrever nenhuma linha de código. Por conta disso você pode dizer que PDI é orientado a metadado.
O PDI pode ser usado como uma aplicação independente ou como parte da suíte do Pentaho. Como uma ferramenta de ETL, é a mais popular ferramenta open source disponível. PDI suporta um vasto conjunto de formatos de entrada e saída de dados, incluindo arquivos texto, arquivos .xls (Excel) além de banco de dados comerciais e open source. Além disso, a capacidade de transformação de dados do PDI permite que você manipule dados com pouquíssimas limitações.
 

Através de um simples exemplo “Hello World”, esse tutorial mostrará como é fácil trabalhar com o PDI e mostrará também o básico, preparando você para outras transformações mais complexas.
Continue reading Tutorial Kettle – Pentaho Data Integration

A análise de sistemas na construção de softwares

Quando se fala em desenvolvimento de softwares, para quem tem bons conhecimentos de programação (ou não), é simples dizer a palavra “mágica” que quase sempre já está na ponta da língua: “Eu tenho a solução!”, afirmam. Contudo, isso é um grande equívoco que profissionais/empresas cometem.

O que alguns profissionais não entendem é que nem sempre o cliente sabe o que quer ou nem sempre consegue expressar o que pensa. E em muitos casos, expressam totalmente o contrário do que realmente queriam passar. É fácil entender isso, levando em consideração pontos tais como: falta de conhecimento de tendências, falta de sensibilidade, falta de conhecimento técnico, entre outros fatores que podemos enumerar. E, consequentemente, há um gasto excessivo de investimento e mão de obra e frustrações dos dois lados são inevitáveis.

É provável que você já deve ter se deparado com vários casos parecidos. Na prática, é bem comum no início do projeto uma conversa informal com o cliente e depois de quase tudo pronto ele dizer que não era bem aquilo que se esperava. Outro caso, é a mudança contínua das iterações do projeto para atender ao nível “alto” de satisfação do cliente (que nunca está satisfeito).

A verdade sobre esses fatores são muitas. A começar pelo preço de custo/benefício, “tempo” e a pressão dos gestores em sua equipe para construírem softwares com tempo cada vez menor, e, contudo, a falta de planejamento sério e de chegar a um nível maduro de entendimento do que realmente o cliente espera do produto final.

Conseguir bons requisitos não é tarefa fácil, e, nem tão pouco, empresas estão interessadas em investir neste tipo de profissional. Investir neste processo, gasta-se um tempo de planejamento, mas algo necessário, ou seja, levando-se pelo ponto de vista maduro, é algo que se ganha lá na frente da iteração do projeto.

Estudos indicam que requisitos detectados depois do software implementado ou erros em sua análise são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro. A ilustração abaixo mostra a realidade na construção de softwares e podemos até dizer (desconsiderando alguns passos) que em determinados tipos de serviços mais informais, isso também acontece.

Essa é uma realidade não apenas no desenvolvimento de softwares, mas é algo corriqueiro e que acontece em nosso cotidiano. Para isso, basta precisarmos de um serviço específico de uma determinada área que desconhecemos, um tipo de conserto de um aparelho, etc. Nestas situações, recebemos muitas opiniões e “conselhos” do que realmente não se deve fazer. Mas, em alguns casos, encontramos algum bom profissional que realmente está atento a nossa necessidade e provê uma solução ao problema.

“Um bom profissional sabe comunicar o seu jargão técnico com o jargão informal do seu cliente.”

Outro ponto que alguns profissionais (mesmo os melhores) não entendem, é o fato que o cliente não é obrigado a saber/entender de um determinado assunto ou uma necessidade. Isso eu chamo de visão, ou seja, alguns profissionais têm (e conquistam o cliente), outros não. Saliento a importância em dar à atenção ao cliente e se dedicar em ouvir sua história de forma a entender o que ele quer e para que ele quer.

Especificamente falando de softwares, a análise é fundamental, pois em sua construção, um dos maiores desafios no desenvolvimento é o da construção do sistema certo, que preencha as necessidades dos usuários a um preço razoável. E para que isso aconteça, é preciso atingir boa comunicação e boa compreensão do mundo dos usuários (é onde entra a Análise de Sistemas). Este artigo é uma abordagem bem superficial de uma análise de softwares, onde há várias iterações, bem como sua documentação, no qual a documentação dos requisitos e de casos de uso é uma forma “contratual” entre a equipe de desenvolvimento e o cliente a respeito do software que será desenvolvido. Mas, o artigo aborda um ponto de vista que se deve ter na hora de construir software de qualidade.

Por outro lado, posso afirmar que o grande desafio do analista não se limita apenas em implementar melhores soluções tecnológicas, mas sim em mudar a cultura de uma empresa. Estudar, se dedicar e se especializar no que faz é parte da vida do profissional, mas, saber lidar com essas situações divergentes é o que faz o grande diferencial do profissional e o sucesso no que se faz.

Fonte: http://www.rafaelamaral.com.br

Livro: Introdução à arquitetura e design de software uma visão sobre a plataforma java

Recomendo a leitura do livro “Introdução à arquitetura e design de software uma visão sobre a plataforma java” muito bom para conhecer melhor o papel do arquiteto de software, explica como funciona as partes que envolvem o processo bem como Design, Implementação e Arquitetura.Muito estou lendo e estou gostando muito! abs.

Singleton – Padrão de Projeto com Microsoft .NET C Sharp

 

Introdução

Padrão de Projeto ou em inglês Design Patterns, é uma forma organizada de criar soluções reutilizáveis para os problemas recorrentes do dia a dia de um projetista ou programador.

Por que usar Padrão de Projeto?

É possível desenvolver software sem utilizar padrões de projetos, e o fato de usar não característica um código ou software de qualidade. Padrão de projeto é somente um dos vários detalhes que compõem o desenvolvimento de um software. Usar padrões de projetos é uma escolha que cabe a cada desenvolvedor/time. Existem casos onde as empresas desenvolvem seus próprios padrões e suas framework de trabalho.

O conceito padrão de projeto foi criado na década de 70 pelo arquiteto e matemático Christopher Alexander um australiano que foi um dos principais críticos da arquitetura moderna. Alexander definiu dois pontos fundamentais para criação de um padrão, apontando as características e formato básico que um “objeto” deve conter para ser classificado como padrão:

Continue reading Singleton – Padrão de Projeto com Microsoft .NET C Sharp