• Nenhum resultado encontrado

Módulo. A.Apresentação

N/A
N/A
Protected

Academic year: 2021

Share "Módulo. A.Apresentação"

Copied!
19
0
0

Texto

(1)
(2)

2

A.

Apresentação

Este é um módulo conceitual, que apresenta os produtos e tecnologias que serão empregados neste livro, introduzindo ainda a arquitetura e métodos que servirão de base para as práticas dos módulos subsequentes.

Módulo

(3)
(4)

4 As oportunidades do eBusiness

A

A

s empresas têm sido desafiadas como nunca a competirem em escala global e, para tal, o domínio das tecnologias Web não é mais algo do qual possam prescindir. Saindo da automação das tarefas rotineiras das áreas de retaguarda para a vanguarda dos negócios, a Web oferece, nos dias de hoje,

muito mais oportunidades do que a maioria das empresas tem conseguido compreender e assimilar.

Neste cenário atual de aceleração da história, os negócios são desafiados primariamente pela famosa previsão de Gordon Moore conhecida com a “Lei de Moore”: a capacidade do hardware continua a

dobrar a cada dois anos, sem aumento dos custos, e com ela também o espaço de inovação do software. Enquanto esta lei durar – e irá por, pelo menos, mais 20 anos - as oportunidades criativas na

área de software continuarão excepcionalmente anabolizadas, um poderoso arsenal competitivo para empresas ágeis e em aprendizado constante que saibam utilizá-lo.

E percebamos bem: software se constrói com outros softwares. Como um produto invisível e abstrato, um programa de computador reúsa e é construído a partir de outras categorias de programas, tais como ferramentas de construção, frameworks e bibliotecas para reúso. E com o próprio ferramental à disposição dos desenvolvedores se expandindo juntamente com os limites criativos de suas aplicações de negócios, deveríamos estar em um ciclo virtuoso, não é mesmo?

Por que, então, continuam falhando tantos projetos de TI? Por que não estamos todos comemorando resultados surpreendentes, potencializados pelo avançado estágio do software?

Fugindo da extensão que uma resposta completa exigiria, vamos nos ater um dos fatores de consenso, resumido por Scott Rosenberg, o fundador do famoso Web-Site www.salon.com: software é difícil porque não se consegue atualizar os profissionais de desenvolvimento na mesma velocidade em que as

possibilidades se atualizam.

“(...) É por isso que não existe Lei de Moore para software. Chips podem dobrar de capacidade a cada ano ou dois; nossos cérebros não.”

Ref. A1.1. Scott Resenberg, em Dreaming in Code [Rosenberg, Scott 2007].

Por motivos como este, empresas cujo foco não seja desenvolvimento de software têm partido para a terceirização quase total desta expertise tecnológica... O problema é que este modelo de distanciamento da tecnologia logo expõe as suas falhas. O ritmo de evolução dos terceiros também é limitado; de qualquer modo será preciso de um bom nível de domínio técnico, para se gerenciar terceirizações no nível adequado de detalhe; e por aí vai... Em suma, logo se descobre que este modelo não elimina o risco - será preciso gerenciá-lo, enfrentando o problema cultural.

Muitos compradores de “Fábricas de Software” estão hoje recebendo verdadeiras aplicações “bomba-relógio” de seus fornecedores, construídas rapidamente para um projeto só, mas difíceis ou impossíveis de serem mantidas que não por seu criador. Com tal nível de variabilidade implementada por cada desenvolvedor terceirizado, mais apropriado seria chamarmos estes modelos de “Artesanatos de Software”.

Arquiteturas pobres, falta de criatividade e de inovação sinérgica entre tecnologia e negócios, são outros fatores sempre presentes, quando a distância cultural entre as pessoas de negócio e as de tecnologia é muito grande. No fim, não há como nos furtarmos à pergunta da Era do Conhecimento: “Como domar novas tecnologias e convertê-las em inovação para os negócios?”

Nasce daí a nossa grande motivação com este livro: prover informações de uma forma prática e atual, contribuindo com informações, padrões e soluções de software que ajudem aos arquitetos e

desenvolvedores de software a resolver problemas corporativos na velocidade dos tempos atuais.

Capítulo

1

A1

Introdução ao jCompany

Developer Suite

(5)

Tirando o máximo do Java EE Open Source

As tecnologias baseadas no Java EE, especialmente em seu ramo Open Source, representam hoje uma

fonte óbvia de inovação pragmática que não deve ser dispensada. No entanto, em sua maioria

esta fonte está disponível em forma bruta, exigindo conhecimento técnico não somente para seu acesso e uso básico, mas principalmente para especializações que permitam sua aplicação contextualizada e otimizada.

O desenvolvimento de uma aplicação corporativa do mundo real carrega consigo muitos problemas que escapam ao radar de um único produto Open Source, e que, portanto, devem ser equacionados no escopo da arquitetura corporativa.

Felizmente, são estas as lacunas que o jCompany Developer Suite procura preencher. Seu uso durante o livro nos possibilitará almejar resultados rápidos e traçar uma estratégia de assimilação gradual, sem abrirmos mão de resultados iniciais minimamente razoáveis. Mas este é o assunto central de todo o livro, sobre o qual nos debruçaremos na prática a partir do próximo módulo. Por hora, voltemos aos nossos pilares de sustentação.

- “Java EE” como mercado comum e plataforma de flexibilidade

O Java EE, como arquitetura tecnológica de base adotada por praticamente toda a indústria (com a notável, mas insuficiente, exceção da Microsoft), tornou-se fundamental para homogeneizar a comunicação, permitindo intercâmbio de componentes, frameworks, processos e padrões, em um

mercado quase universal para fornecedores que antes concorriam em nichos tecnológicos.

Presente em mais de 70% do mercado corporativo no Brasil, o Java EE permite uma comunicação técnica entre áreas e profissionais de TI tão necessária quanto é o idioma inglês hoje para o mundo. E o que é melhor: no limite, esta homogeneidade e estímulo à concorrência proveram condições para o

surgimento do movimento Open Source, este por si um advento de valor inestimável para o mercado comprador de software.

- “Tirando o máximo do Java EE” para os negócios

Há uma importante diferença entre “tirar o máximo da tecnologia pela tecnologia”, por exemplo, explorando todas as APIs e frameworks Java EE possíveis e existentes, e “tirar o máximo da tecnologia para os negócios”, que é o sentido que queremos explorar neste livro.

Em nosso caso, desejamos maximizar o retorno do Java EE para os negócios, selecionando e explorando ao máximo aquela parcela de APIs e frameworks que provê a maior taxa de retorno na maior parte dos casos, em um típico raciocínio 20/80 de Paretto.

Vejamos alguns extremos de postura com relação à internalização de inovação que encontramos atualmente:

o Por um lado, existem departamentos de Tecnologia da Informação (TI) que absorvem inovações tecnológicas de forma lenta ou mediana e são até considerados satisfatórios, tolerados pela gestão de suas empresas.

Em parte isso se explica pelos benefícios que a própria Lei de Moore, por si, já promove: a própria evolução orgânica do hardware e a atualização de versões de tecnologias de base permitem às áreas de TI hoje apresentarem algum resultado, o que preserva em muitas a acomodação de “jogar pelo empate”. Um bom exemplo são empresas que preservam gerações obsoletas de aplicações, caras e defeituosas, para além de seu limite de vida razoável (acredite, já nos deparamos com empresas rodando aplicações de mainframe monousuárias, mantidas a preço de ouro, somente por inércia tecnológica!).

o Mas no outro extremo, também muito perigoso, estão os que chamamos de compradores de tecnologia fashion, que costumam ser coadjuvantes dos verdadeiros protagonistas, fornecedores de software que supervalorizam tecnologias emergentes em produtos repletos de “excessos de engenharia” (overenginnering).

Defendemos uma posição mediana. Nosso objetivo de “tirar o máximo do Java EE Open Source” não deve ser confundido com “apreender tecnologia pela tecnologia”, mas como uma busca por absorver aquelas frações de novas tecnologias de software que realmente são um meio oportuno para o fim maior, de viabilizar resultados de negócio diferenciados e criativos.

Mas como poderemos, neste livro, sugerir soluções de negócio criativas?

É simples: não poderemos. Como não discutiremos nenhuma vertical de negócio específica, esta é uma missão nobre que caberá única e exclusivamente ao desenvolvedor nela contextualizado. Mas faremos o que nos é possível: trazer soluções que poupam boa parcela de tempo de desenvolvimento de

(6)

Introdução ao jCompany Developer Suite

negócios. Faremos isso através de reúso de soluções “quase-completas” e “altamente produtivas”, na forma de padrões de alto nível, ou em nível de Caso de Uso.

Estas soluções não chegam a adentrar em nenhuma vertical de negócio específica, mas resolvem uma boa parcela de problemas comuns a todas elas, presentes em camadas que compõem a “parte

arquitetural commodity” da solução.

Com a experiência, começa-se a distinguir mais claramente quais são estas camadas que devem ser reutilizadas e quais são as que devem ser criadas. Na maior parte dos casos, é completa insensatez

despender-se tempo criativo em camadas básicas de arquitetura de software em busca de inovação de negócios, a menos que seu negócio seja software*.

Ao reutilizarmos soluções que especializam e integram APIs Java EE e produtos Open Source com resultado comprovado, através de diretrizes técnicas de mercado, eliminamos tempo de Pesquisa & Desenvolvimento (P&D) em camadas arquiteturais que não deveriam mesmo conter variações “criativas”. E possibilitamos que as preciosas energia e criatividade dos departamentos de TI sejam concentradas

onde deveriam: nas camadas de software que refletem o Core Business da corporação.

- “Open Source” como estratégia de projetos

Para o mundo corporativo, o movimento Open Source é hoje compreendido principalmente como uma

estratégia de projeto, mais do que de redução de custos, como fora em seu início. No estágio atual

do movimento, os técnicos mais informados – e inclusive muitos CIOs - já reconhecem a importância decisiva que o acesso aos códigos fontes reutilizados traz para seus objetivos de projeto, viabilizando integração, adaptação e maximização do reúso em granularidade fina.

Para quem uma vez experimenta a liberdade do Open Source, as APIs proprietárias dos códigos fechados representam verdadeiros “Firewalls de Projeto”. Barram soluções que exigem adaptação e flexibilidade em níveis maiores de detalhe, retardam a correção de bugs e reduzem a taxa de comunicação entre técnicos, entendimento e customização que possam pretender.

Além disso, o movimento do Open Source Software (OSS) já estabeleceu com sucesso uma verdadeira revolução sócio-cultural na área de TI, com seus fóruns de troca de conhecimentos, padrões e técnicas de trabalho em níveis inéditos. Neste aspecto, é um de nossos principais aliados no desafio básico de minimizar o déficit de conhecimento.

jCompany x JAGUAR

Atualmente a Powerlogic fornece atráves do Portal de Software Público Brasileiro

(http://www.softwarepublico.gov.br) o framework JAGUAR. Este framework é totalmente baseado no jCompany Developer Suite e foi doado a comunidade sob as licenças GPLv2 e GPLv3.

Este livro tem como objetivo orientar o uso dos dois produtos, utilizando primariamente o nome

jCompany. Obs.: capturas de telas poderão exibir logotipos tanto do jCompany quanto do Jaguar, o

que não tem efeito prático no conteúdo. Mais detalhes do JAGUAR podem ser obtidos na comunidade JAGUAR do Portal do Software Público ou em http://www.powerlogic.org.

O jCompany Developer Suite

- Uma breve introdução ao jCompany

Dos produtos Java EE Open Source “como eles existem” até seu “estágio de contextualização ideal”, em qualquer empresa, há um longo caminho a ser percorrido. Quando não se reconhece este fato, por superestimação das tecnologias ou subestimação dos níveis de exigência corporativos de TI, o resultado aparece na forma de arquiteturas medíocres, insuficientes para se evitar mesmo tragédias básicas. O surgimento, em 2003, do jCompany Developer Suite foi uma resposta da Powerlogic a clientes que ansiavam por um “transporte mais rápido” que os ajudasse a cortar caminho nesta jornada, internalizar e otimizar o Java EE Open Source sem perda de “Time-to-Market” e do foco em seus negócios.

* Ainda assim, muitos profissionais mal sintonizados com os objetivos de sua empresa e com os rumos dos negócios na atualidade, gostam de reinventar commodities, como frameworks de base.

(7)

O modelo de licenciamento Open Source 2.0 foi também um grande coadjuvante deste sucesso pois, ao permitir as grandes organizações adquirirem produtos abertos de qualidade comprovada, viabilizou uma terceirização gerenciável da complexidade envolvida, sem perda dos benefícios culturais e da liberdade do Open Source.

Mas um erro básico seria imaginar o jCompany como um simples empacotamento dos projetos Open Source que ele reutiliza. Tais projetos “de base para reuso” são instalados juntamente com a suíte unicamente para comodidade do cliente, que deste modo passa a contar com um ambiente Open Source imediatamente “pronto para uso”, integrado e homologado.

O jCompany em si, como veremos, é composto por uma quantidade razoável de projetos Java EE específicos, plugins Eclipse, métodos e padrões, soluções de integração e gerência de configuração extremamente trabalhosas, dentre vários outros “suplementos” de alto valor agregado, mantidos pela equipe de desenvolvimento dedicada da Powerlogic. Esta equipe é formada por dezenas de

desenvolvedores, profissionais de QA, Web-Design e de Produtação, trabalhando em um ambiente certificado em MPS.Br nível C (CMMI-3) com base em práticas ágeis (SCRUM), condizentes com o mundo Open Source.

Neste modelo, os clientes são convidados a participarem ativamente, de forma colaborativa. Qualquer profissional de clientes se engajar como um desenvolvedor colaborativo (prosumer) através do Portal do Software Público. Neste patamar ele tem acesso ao repositório de fontes oficial do produto, podendo acelerar questões de interesse de sua empresa (naturalmente, mediante aprovação do Product Owner), dentre outros benefícios. Verifique, na comunidade Jaguar, mais informações sobre estas facilidades.

- A busca pela “hiper-produtividade”

O jCompany Developer Suite é uma solução bastante eficaz para o aprimoramento dos resultados quando se trata de desenvolvimento de aplicações de software para Web em escala corporativa. Trata-se de uma suíte de produtos multidimensional que trabalha a problemática da produtividade e

qualidade por diversos ângulos.

Muito embora seja algumas vezes, erroneamente compreendido como “um framework”, o jCompany é na verdade uma solução completa, cuja composição é ilustrada pelo diagrama da Figura A1.1.

Figura A1.1. Dimensões de atuação da suíte do jCompany.

O framework existe através do módulo jCompany Full Stack Framework, com uma alta parcela de contribuição, mas diversos outros módulos importantes e integrados proporcionam a sinergia responsável pelo resultado final diferenciado da suíte jCompany.

Quando comparado ao desempenho de uma solução típica para desenvolvimento Java EE, caracterizada pelo aproveitamento mediano de técnicas de Orientação a Objetos, arquiteturas de software “anêmicas”, ausência de gerência de configuração e uso de IDEs agnósticas (que desconhecem o processo e não podem incentivar “melhores práticas”), o jCompany pode apresentar níveis de

“hiper-produtividade”.

E esta não é hoje uma mera alegação. A Powerlogic tem colhido estes resultados ao longo de 8 (oito) anos de experiência pioneira tendo a tecnologia Java como seu Core Business. No que são hoje mais de centenas de projetos corporativos em produção, o jCompany veio reduzindo prazos da ordem de grandeza de “meses” para “semanas”, e com aumento considerável da qualidade: mais flexibilidade, escalabilidade, performance, usabilidade e estabilidade.

- Qualidade para produtividade sustentável

Sabe-se que a “super ênfase” em produtividade e tempo de resposta ao mercado (time-to-market), sem as mínimas restrições de qualidade, conduz à “síndrome da primeira versão”: Aplicações entregues no prazo, apresentando problemas de estabilidade, performance, não conformidades e dificuldades sérias em sua manutenção, que terminam por cobrar de volta todos os ganhos imaginários de produtividade,

(8)

Introdução ao jCompany Developer Suite

com “juros e correção monetária”. É o que se termina por reconhecer como “pressa”, não como

“produtividade”.

Por este motivo, muitas preocupações do jCompany são inteiramente dedicadas à qualidade, mesmo que ao custo de uma redução de ganho inicial. É o caso, por exemplo, da opção pela arquitetura de base MVC (Model-View-Controller), importante para maior flexibilidade em evoluções e para se manter a complexidade sob controle, mas não necessariamente para se desenvolver “mais rápido”.

Por outro lado, quase todas as preocupações com produtividade do jCompany também consideram o aspecto qualidade.

Por exemplo, antes de usar técnicas de “geração de artefatos”, o jCompany esgota prioritariamente as possibilidades mais sofisticadas da “Orientação a Objetos” (OO). Deste modo, apesar de aumentar a curva de aprendizado, o resultado de produtividade é consistente, preservado nas fases de manutenção. Ao eliminar código, em lugar de proliferá-los mais rapidamente (como na geração de código), a

Orientação a Objetos também diminui a probabilidade de erros.

- Produtividade corporativa em escala industrial

Para uma empresa que possua técnicos com alta proficiência em Java EE, a maneira mais rápida para se construir uma aplicação será, provavelmente, deixando-os “fazerem da forma que sabem”. Deste modo, elimina-se qualquer curva de aprendizado e evitam-se resistências à mudança de cultura.

Porém, esta é uma visão simplista do problema. Devido à imensa variabilidade de soluções possíveis em Java EE, para um mesmo problema, esta liberdade terminará por permitir a proliferação de diversas “arquiteturas individuais”, que dificultam o desenvolvimento em escala. Qualidade flutuante, problemas em requisitos de integração e dificuldades nas fases de manutenção (turn-overs complexos) costumam ser suficientes para se justificar um padrão arquitetural único para a organização.

É inevitável que grandes organizações evitem a “rapidez artesanal”, de alto risco, em prol de uma “produtividade industrial”, sustentável. No médio prazo, este é o único caminho. Neste sentido, o

jCompany se torna um grande catalisador, garantindo uma pauta mínima de qualidade, produtividade e

padronização em um nível de profundidade que, realmente, garante diminuição da variabilidade indesejável de soluções para problemas similares e em camadas de arquitetura. Deste modo, desenvolvedores criativos podem usar a sua criatividade em camadas do negócio.

- Por que o jCompany funciona?

Porque, como qualquer solução para aumento de qualidade e aceleração de processos industriais, o

jCompany atua com seus vários módulos sobre diversos flancos desta problemática, sinergicamente, da

seguinte forma:

o Automação completa (Robôs)

Robôs eliminam por completo a necessidade de trabalho humano, sendo em geral o ápice da otimização. Em software, generalizações de Orientação a Objetos funcionam como robôs industriais, eliminando a necessidade de codificação manual de partes de programas. Esta é a área de atuação do jCompany FS Framework.

o Automação indireta (Ferramentas)

Quando não é possível “robotizar”, a provisão de ferramentas apropriadas pode maximizar o trabalho humano. Em software, como em qualquer processo industrial, ferramentas de apoio para geração de artefatos, construção e liberação de executáveis, edições etc., automatizam tarefas intermediárias, acelerando a codificação manual de programas. É a área de atuação do

jCompany IDE.

o Orientação

Quando o trabalho é meramente intelectual, e mesmo o uso de ferramentas arrojadas não proveja ganhos significativos, a orientação na forma de repasse de experiências e padrões históricos de solução (best-practices) é a forma de se maximizar resultados. Em software, como em qualquer processo industrial, a definição de “padrões de solução” para problemas frequentes, documentação extensiva e roteiros “passo a passo” ativos e inteligentes, podem orientar os profissionais decisivamente na codificação manual de programas. É a área de atuação do

jCompany Patterns & Methods.

o Conferência (Controle de Qualidade)

A “dupla checagem” da qualidade dos produtos intermediários de um processo evita desperdício e inclusive a liberação de resultados indesejáveis ao mercado. Em software, a codificação de Testes de Unidade funciona como uma área de controle de qualidade que permeia o processo,

(9)

garantindo continuamente que a codificação manual de segmentos de programas esteja em conformidade. É a área de atuação do jCompany Test for Developer.

o Infra-Estrutura (Manutenção e Preservação)

Um ambiente de produção que envolva tecnologia nos vários âmbitos citados necessitará de uma contínua monitoria para garantir a “lubrificação”, “fluidez” e “estabilidade” da bancada

tecnológica utilizada. Em software, como em qualquer ambiente de produção industrial, para evitar quedas de rendimento, a infra-estrutura de suporte tecnológico ao processo precisa se manter estável e íntegra ao longo do tempo. É a área de atuação do jCompany Configuration

Management.

jCompany FS Framework

- Arquitetura de Software Corporativa

A Arquitetura de Software é aquela parcela da solução que se encontra pré-definida, implementada e disponível para os desenvolvedores, antes do início da construção de aplicações de negócio. Muito embora seja possível se definir e construir uma arquitetura de software para somente uma aplicação, os maiores ganhos advém de seu reúso em escala, em uma grande organização.

Uma representação de arquitetura exigirá diversos ângulos ou “visões”. A visão que “enxerga” o

jCompany FS Framework, por exemplo, é a “Visão de Componentes” (Component View), que foca nas

camadas de componentes que são embalados juntos no executável da aplicação.

Para os melhores resultados, uma Arquitetura de Software Corporativa não deve se restringir a apenas um esquema conceitual ou documento de direcionamentos, mas trazer implementações concretas em seu nível de atuação. Em um ambiente receptivo a técnicas de Orientação a Objetos (OO), como o Java EE, isso é possível principalmente através de frameworks que “promovam e simplifiquem o uso” da

arquitetura e que também “amplifiquem” os resultados esperados.

- Framework

Um framework é um conjunto de classes que colaboram entre si de modo a prover um reúso abrangente de grandes blocos de comportamento. Por ser reutilizável e customizável de forma refinada através de diferentes técnicas OO, um framework permite um ganho impossível, ou muito difícil, de ser obtido via “chamadas de sub-rotinas”, reúso típico dos ambientes de desenvolvimento de “terceira geração”. Quando concebido com a profundidade e abrangência necessárias, um bom framework será o principal representante da Arquitetura de Software Corporativa, uma manifestação concreta de seus objetivos, contribuindo no dia a dia do desenvolvimento para:

o Definir fronteiras, evitando devaneios desnecessários em blocos não homologados de tecnologias;

o Promover “melhores práticas”, trazendo atalhos que tornem natural esta opção; o Eliminar trabalho repetitivo, generalizando grande parcela das soluções;

o Diminuir a variabilidade indesejável de “soluções diferentes para um mesmo tipo de problema”, trazendo formas prontas de solução, customizáveis;

Com tudo isso, um bom framework se transforma no agente da arquitetura responsável por elevar o

patamar mínimo de qualidade e produtividade para todos os projetos em seu perfil de atuação.

- Framework de Integração

O jCompany FS Framework não é um framework comum, mas um “framework de integração”. Este tipo de framework funciona uma camada acima de outros, chamados framewoks de base, atuando como um “framework de frameworks”. Esta robustez arquitetural é hoje necessária para fazer frente ao grande aumento de complexidade das tecnologias da era do eBusiness, as chamadas tecnologias Web.

Uma das características fortes de um framework de integração como o jCompany FS Framework é exatamente não “reinventar a roda” praticando, em seu nível, a orientação de reúso que prega. Ao incorporar frameworks de base de larga aceitação no mercado e se concentrar somente em

especializações holísticas, de mais alto nível, ele agrega um tremendo valor à arquitetura geral ao

mesmo tempo em que preserva a cultura de mercado.

- Arquitetura de Software com o jCompany FS Framework

A Figura A1.2 exibe um diagrama em camadas que representa o esquema básico da Visão de Componentes da “Arquitetura de Software Corporativa”, conforme sugerida pelo jCompany. A arquitetura em si é representada pelas camadas marcadas com os números (2), (3) e (4).

(10)

Introdução ao jCompany Developer Suite

Figura A1.2. Arquitetura em camadas de uma aplicação Java EE com o jCompany Full Stack Framework.

#1. Infra-Estrutura de Software: Camadas de softwares “de infra-estrutura”, normalmente de domínio da equipe de operação (produção).

Camadas da Arquitetura de Software Corporativa

#2. Frameworks e utilitários de base do mundo Open Source: Reúso essencial de produtos líderes em sua categoria, em cada “camada MVC”, para se evitar a “reinvenção da roda” em um nível mais baixo da arquitetura. Preserva, ainda, a cultura de mercado.

#3. jCompany Full Stack Framework “Core” - Generalização Commodity: Camada de software provida pelo jCompany através de framework que realiza generalizações integradas de insumos Open Source da camada (2) e as disponibiliza para reúso em mais alto nível. Segue orientações arquiteturais e de

implementação de mercado (MVC, Design Patterns, padrões de formulários, gerência de transações, etc.), promovendo “melhores práticas” de interesse comum a diversos projetos de diversas verticais de negócios. Por isso, é chamada de “commodity”.

#4. jCompany Full Stack Framework “Bridge” - Generalização da Empresa: Camada de software cuja estrutura é provida pelo jCompany através de framework de isolamento da camada de baixo, que permite às empresas introduzirem generalizações e customizações próprias de seu contexto. Exemplos típicos são web-design padrão, segurança corporativa, pré-configurações de ‘gateways’ para acessos comuns (Ex.: mainframes) e ajustes gerais de quaisquer padrões do jCompany. É chamada também de “última milha” por ser a última camada da arquitetura.

Camadas do Negócio (Core Business)

#5. Camada de Core Business: Camada que contém os módulos reutilizáveis de negócio e portifólio de aplicações que se beneficiam do ganho de escala e padronização da arquitetura. Deve ser o foco de concentração de profissionais orientados ao negócio, incluindo “criatividade” e diferenciações únicas de cada projeto.

jCompany IDE

- Ambiente Integrado de Desenvolvimento

O módulo jCompany IDE atua no aprimoramento do ambiente de trabalho do desenvolvedor para melhoria de produtividade nas atividades de seu dia a dia, incluindo geração de artefatos “não generalizáveis”, tais como XHTML de formulário, mensagens e rótulos, XML etc.

Do ponto de vista de sua arquitetura interna, o jCompany IDE parte da mesma filosofia de “reúso e especialização” do jCompany FS Framework. Porém, obviamente, neste caso reutiliza uma pilha de utilitários Open Source em tempo de desenvolvimento, como exibido na Figura A1.3.

(11)

Figura A1.3. Arquitetura – Visão de Desenvolvimento. Estratégia similar à Visão de Componentes.

#1. Infra-Estrutura de Software: Camadas de softwares “de infra-estrutura”, incluindo neste caso tanto o Ambiente Integrado de Desenvolvimento e de gerência de configuração: a IDE Eclipse e o Maven 3.x. Repare que os plugins JDT, apesar não fazerem parte da plataforma básica Workbench, são mantidos pela comunidade Eclipse e, por isso, também considerados “infra-estrutura”.

#2. Utilitários de Desenvolvimento - Reúso de Matéria-Prima Open Source: Camada de softwares reutilizados do mundo Open Source, composta principalmente por plug-ins da IDE Eclipse e utilitários Maven de base. São considerados recursos de apoio “genérico”, neutros com relação à arquitetura, padrões e métodos do jCompany.

#3. Utilitários de Desenvolvimento – Plug-ins de Processo: Camada de software composta por plug-ins da IDE e utilitários Maven que conhecem a arquitetura do jCompany FS Framework e ainda os padrões e métodos do jCompany Patterns & Methods. Por este motivo, geram artefatos em conformidade com “melhores práticas”.

#4. Utilitários de Desenvolvimento – Customização da Empresa: Camada de templates que permitem a customização dos projetos e artefatos gerados, de modo a respeitarem eventuais especificidades

introduzidas na camada Bridge da arquitetura (número (4) na Figura A1.2, entre outras).

Os utilitários do jCompany IDE não são componentes para reúso a serem incluídos nos executáveis das aplicações. Por outro lado, aumentam a produtividade dos desenvolvedores nas atividades

necessárias para produzirem códigos e artefatos específicos da sua camada de negócios.

Existem duas áreas chave para onde o módulo jCompany IDE traz produtividade diferenciada, indo além das facilidades genéricas propiciadas pelo Eclipse, pelo Maven e pela camada de reúso Open Source:

o Plugins de Criação “Orientados pelo Processo”, capazes de produzir uma primeira versão de projetos e artefatos envolvidos em Casos de Uso Padrões, que seguem “melhores práticas” previstas na Arquitetura de Software, Padrões e Métodos Corporativos. Por exemplo, os plug-ins de processo do jCompany IDE geram formulários JSF, menus, mapeamento Objeto-Relacional, fluxos de navegação padrões etc., otimizados e minimalistas em qualidade final de produção. o Organização de projetos e dependências segundo o padrão Maven, incluindo repositório

simplificado e rotinas de construção e liberação rápida via MOJOs (Maven Objects), para diversos Application Servers, levando em conta a Arquitetura de Software Corporativa.

Com isto, o módulo jCompany IDE provê um Ambiente Integrado de Desenvolvimento “inteligente”, conhecedor da arquitetura, padrões de alto nível e “melhores práticas” da organização.

Trata-se de um avanço nítido com relação ao que se poderia extrair de IDEs no passado ou do que se pode esperar do Eclipse ou Netbeans com seus plug-ins de edição genéricos, incapazes de reforçar “melhores práticas”.

(12)

Introdução ao jCompany Developer Suite

jCompany Patterns & Methods

- Padrões de Solução em Alto Nível

Uma outra dimensão de atuação do jCompany é o apoio à etapa de especificação de aplicações, que precedem a implementação de código em si. Além da generalização da arquitetura de software e da aceleração da IDE, as orientações nesta área reduzem prazos de concepção de soluções, modelagem e especificação para construção através de padrões de alto nível.

Mesmo para uma equipe de “Analistas-Desenvolvedores” que dispensam modelos formais de especificação, os padrões em alto nível do jCompany Patterns & Methods trarão maior clareza e orientação na elaboração mental da solução.

Este módulo é constituído por dezenas de capítulos de documentação disponíveis no Ajuda On-Line da IDE Eclipse, e ainda por roteiros baseados em Cheat-Sheets, verdadeiros assistentes de processo integrados ao ambiente de desenvolvimento. Eles funcionam como “mentores virtuais”, guiando desenvolvedores, passo a passo, por “caminhos de produtividade e conformidade” para a solução de problemas padronizados.

- Casos de Uso Padrões

O módulo jCompany Patterns & Methods introduz práticas e traz documentações que facilitam a identificação e a especificação de “Casos de Uso Padrões”, inclusive com diversas variações potenciais, expressas em UML na forma de “Extensões” e “Inclusões” padrões, como exemplificado na Figura A1.4.

Figura A1.4. Alguns Casos de Uso, Inclusões e Extensões Padrões do jCompany Patterns & Methods.

Os Casos de Uso Padrões do jCompany partem das ideias de Alistair Cockburn [Cockburn, Alistair 2003], evoluindo radicalmente seus conceitos de “Caso de Uso CRUD” e “Caso de Uso Parametrizado”, tanto conceitualmente como através de uma solução de implementação automatizada.

- Colaborações Padrões

Os Casos de Uso Padrões do jCompany estão definidos em nível lógico. Eles são, por exemplo, úteis mesmo em outros paradigmas tecnológicos que não o Java EE.

Mas o jCompany traz também “padrões de realização de Casos de Uso completos” voltados para especificação para Java EE especificamente, chamados “Colaborações Padrões”. As Colaborações são “estereótipos” de Caso de Uso, representadas de forma pontilhada na UML, que simbolizam

(13)

O módulo jCompany FS Framework implementa diretamente estas Colaborações Padrões definidas através de generalizações OO de alto nível, para a parte Java envolvida. Em seguida o módulo

jCompany IDE gera os artefatos não generalizáveis, como os numerados na Figura A1.5, provendo um

grande índice de automação final.

Figura A1.5. Visão estrutural de uma Colaboração, com artefatos Java EE envolvidos.

Esta sinergia entre projetos lógico, físico e implementação soluciona de forma elegante um clássico problema do desenvolvimento de software: a transição da etapa de Elaboração para Construção.

- Padrões de Agregações de Entidades

O jCompany Patterns & Methods traz ainda padrões OO para o modelo de Domínio (Classes que representam Entidades do Negócio), partindo das conceituações de Eric Evans [Evans, Erick 2004] conhecidas como Domain-Driven Design (DDD), introduzindo aprimoramentos e automações, também neste âmbito.

Através de estereótipos para Agregações de Classes que ditam comportamentos importantes, também generalizados no jCompany FS Framework, o jCompany promove o uso de conceitos importantes de Orientação a Objetos nesta nobre camada da aplicação.

(14)

Introdução ao jCompany Developer Suite

Figura A1.6. Agregação de Entidades com estereótipos que definem padrões da Arquitetura.

- Padrões de Interfaces com o Usuário.

O jCompany Patterns & Methods traz ainda padrões de Interface com o Usuário, voltados para aplicações Web, baseados em padrões de usabilidade e ergonomia clássicos de mercado, padrões W3C e preceitos de Organização & Métodos – especialmente otimizados para viabilizar entradas de dados massivas, típicas do mundo corporativo em Navegadores Web.

Figura A1.7. Padrões de formulário de entrada de dados.

Além de implementações genéricas para padrões de formulário e operações, padrões de leiaute também são definidos e implementados genericamente, trazendo uma proposta visual e de ergonomia para toda a aplicação.

(15)

Figura A1.8. Leiautes altamente personalizáveis, incluindo pele e internacionalização.

jCompany Test for Developer

- Testes de Unidade

O módulo jCompany Test for Developer traz um framework para apoio ao desenvolvimento de Testes de Unidade para arquitetura MVC2-P (Model-View-Controller type 2 with Persistence), baseado

principalmente nos frameworks de base JUnit e EasyMock.

Ele também segue a mesma filosofia de reúso de matéria-prima Open Source do jCompany FS

Framework, porém em escala bem reduzida de complexidade, como ilustrado na Figura A1.9.

Figura A1.9. Arquitetura de Desenvolvimento de Testes de Unidade.

#1. Infra-Estrutura de Software: Camadas de softwares de “infra-estrutura” para rodar Testes de Unidade. Inclui a IDE Eclipse para execução interativa e o Maven para execução batch e coverage.

#2. Arquitetura de Testes de Unidade - Reúso de Matéria-Prima Open Source: Camada de softwares reutilizados do mundo Open Source, composta principalmente por JUnit, EasyMock e utilitário de medição de cobertura dos testes (Coverage).

#3. Arquitetura de Testes de Unidade – Framework de Integração: Framework provendo uma fina camada de especialização e “melhores práticas” de Testes de Unidade para camadas Controle, Modelo, Domínio e Persistência.

Traz também classes “Stubs” (Mocks concretos) para simular objetos complexos de controle, tais como HttpRequest.

(16)

Introdução ao jCompany Developer Suite

Muito embora se trate do módulo da suíte com menor contribuição quando comparado aos demais, o seu bom uso pode ser de grande valor para reforçar qualidade e práticas de refactoring ao longo das

manutenções.

jCompany Configuration Management

- Gerência de Configuração

Dificilmente um profissional iniciante na área de Desenvolvimento de Aplicações de Software corporativo compreenderá porque o módulo jCompany Configuration Management tem o mesmo peso em termos de contribuição que o módulo jCompany IDE, como ilustrado na Figura A1.1.

O fato é que, dentro da disciplina de “Gerência de Configuração”, tão enfatizada em certificações de maturidade tais como CMMI, estão questões chave para manutenção da integridade (e,

consequentemente, da qualidade e produtividade geral) de todos os outros módulos da solução, ao longo do tempo, garantindo:

o Integração dos Itens de Configuração

o Controle de Versões (Integridade Continuada)

Em uma suíte altamente integrada, como vemos na Figura A1.10, todos os componentes envolvidos, em todas as camadas de cada módulo da solução, precisam estar funcionando harmonicamente. Para tanto, necessitam não somente de estarem versões apropriadas, homologadas juntamente com as versões dos demais componentes, mas ainda pré-configurados para funcionamento imediato com pouco esforço.

Figura A1.10. Itens de configuração controlados no jCompany Developer Suite.

Manter uma instalação e controle de versão unificado para um universo de mais de quarenta projetos de origem distinta, e mais de uma centena de “itens de configuração” (projetos, componentes, capítulos de documentação, roteiro Cheat-Sheet, plug-ins etc.), como é o caso do jCompany Developer Suite, é uma tarefa hercúlea. Especialmente quando se passa a contar com uma base instalada que exige manutenções de linhas de base em paralelo.

Em grandes organizações, onde é de se esperar o desenvolvimento de dezenas ou centenas de projetos sobre uma mesma Arquitetura de Software Corporativa, a simples terceirização de boa parte deste trabalho de “embalagem integrada de software Open Source” e do controle de sua Linha de Base, de forma unificada, pode compensar o uso do jCompany e retornar o investimento.

Open Source Application Lifecycle Management

Em uma visão mais ampla de um Processo de Desenvolvimento de Sistemas (PDS), o jCompany

Developer Suite está inserido na fase de Construção. Esta será, portanto, a fase do PDS enfatizada

neste livro, muito embora venhamos a analisar elementos da fase de Elaboração para compreender os padrões de especificação que iremos implementar, tais como Modelo de Classes, de Casos de Uso e Colaborações.

(17)

Mas esta é ainda uma cobertura pequena de ferramental para a automação de um PDS completo. Uma visão holística englobaria gerenciamento de projetos, requisitos, automação e controle da qualidade, segurança, monitoria em produção, atendimento aos usuários (estatísticas de uso, erros, sugestões) etc. etc.

Figura A1.11. Ciclo de vida de gerenciamento de aplicações de software.

Soluções para este tipo de abrangência “topo-de-linha” são conhecidas no mercado como produtos para

Application Lifecycle Management (ALM). Com elas, se torna possível uma gestão integrada via

ferramentas que oferecem rastreamento entre artefatos diversos produzidos e consumidos em cada fase, além de gerenciamento de mudanças com análise de impacto, cálculos de ROI, dentre outros benefícios. Apesar de serem objetos de desejo, as poucas soluções de mercado na área de ALM são ainda de código fechado e incorrem facilmente em licenciamentos milionários. Um outro agravante é o “excesso de peso” que estas suítes tradicionais costumam trazer. Por estes motivos, customizações refinadas logo se manifestam como difíceis, senão impossíveis, de serem realizadas, culminando em implantações parciais (subutilização) ou fracassos completos.

Como alternativa ao código fechado, a Powerlogic dispõe de mais produtos que se integram com o

jCompany para atendimento a outras fases e disciplinas de um PDS, todas com a mesma filosofia de integração e especialização de insumos Open Source, em código aberto.

Não é o objetivo deste livro uma discussão com este nível de abrangência, mas vale à pena apresentarmos este outros produtos:

- jCompany QA Suite

Integra e especializa frameworks e ferramentas líderes do mundo Open Source para a área de Garantia da Qualidade (Quality Assurance – QA), oferecendo produtividade diferenciada na automação da averiguação de qualidade, que inclui testes funcionais, de unidade e estático para averiguação de padrões e convenções de código.

Além disso, provê um ambiente de integração contínua e de trabalho em equipe “pronto para uso”, com controle de versão de executáveis ultra-simplificado, incluindo versionamento a um clique (“one-click versioning”) e liberação a um clique (“one-click deploy”).

O jCompany QA Suite integra os produtos Hudson/Jenkis, Sonar, Maven, Sellenium e SVN em um ambiente suportado e integrado de Gerência de Configuração e Automação.

jCompany Production Suite

É composto por dois produtos:

jCompany Security: Permite a definição do controle de acesso da aplicação de forma

totalmente dinâmica, sem que desenvolvedores declarem ou necessitem de programar políticas básicas de acesso. Ex: “usuários com papel ‘A’ não podem acessar a URL ‘/notafiscal’”, “usuários com papel ‘B’ não podem ver o campo “salario" na URL ‘/funcionario’, “somente usuários com papel “Presidente” e certificado digital ‘X’ podem acessar a URL ‘/demofinanceiro’”. O jCompany Security importa automaticamente todas as URLs de arquivos executáveis (WAR e EAR), permite o cadastro interativo de regras através de uma aplicação e, a partir destas regras, realiza simultaneamente o “conforto visual” (esconder itens de menu, botões, campos dinamicamente) e a segurança efetiva no servidor (JAAS).

(18)

Introdução ao jCompany Developer Suite

jCompany Monitor: Permite a coleta de “cliques” de navegação e transação do usuário (HTTP GETs e

POSTs), contabilizando acessos de forma assíncrona, via JMS, o que garante máxima escalabilidade da solução, mesmo para grandes clusters de Application Servers, sem impacto na performance e

disponibilidade das aplicações. Além da auditoria de história de navegação de todos os usuários, em todas as diversas sessões de uso, monitora ainda a disponibilidade de serviços diversos via agentes de monitoria, tais como disponibilidade do “serviço do SGBD A”, “serviço de correio B”, “serviço JMS C” ou “da aplicação X nos Application Servers D e E”, dentre outras facilidades.

- eCompany Portal Suite

É uma solução de Enterprise Information Portal Web 2.0 com facilidades diversas de Gestão de Conteúdo, Colaboração e Groupware em geral, que agregam informações de toda a suíte de ALM em um único ponto. Além disso, inclui Portlets que podem exibir formulários desenvolvidos com jCompany Developer Suite, integrando segurança e permitindo reorganização da disposição de aplicações para usuários de decisão (gerentes, coordenadores, diretores etc.).

O eCompany Portal embute ainda uma solução de Contact-Center para permitir a recepção e triagem de “incidências de erros, sugestões e pedido de melhorias” por parte de usuários, mantendo estas

ocorrências rastreáveis até seus requisitos originais, produtos e componentes de produto. Trata-se de um sistema completo para identificação, triagem, atendimento e geração de base de conhecimento

rastreável, para bugs, melhorias e quaisquer outros feedbacks dos usuários.

- eCompany Reports

É uma solução para construção, escalonamento e disponibilização de relatórios para Web, baseada no Eclipse BIRT e escalonador Quartz, que permite que sejam

planejadas execuções de relatórios com argumentos pré-definidos e lista de distribuição, de forma batch, de modo a evitar sobrecargas em aplicações on-line.

O eCompany Reports traz um instrumento de flexibilidade para se criar e disponibilizar relatórios customizados externos à aplicação e que ainda assim se integram visualmente à aplicação - trazendo grande produtividade para a produção e manutenção destes artefatos.

O eCompany Reports utiliza o Eclipse BIRT e serviço BIRT Viewer como base. Relatórios BIRT podem incluir gráficos, quebras e indicadores visuais sofisticados, em formato PDF ou HTML.

(19)

Sumário

Neste capítulo, discutimos brevemente os desafios que as organizações vêm enfrentando para absorverem inovações tecnológicas em um ritmo competitivo. Caracterizamos como tentaremos contribuir nesta área e o que queremos dizer por “tirar o máximo do Java EE OpenSource”.

Apresentamos o jCompany Developer Suite (assim como o JAGUAR) como uma solução completa para construção de aplicações Java EE, com base em arquitetura Open Source customizável, em suas diversas dimensões de atuação. Prosseguimos analisando a arquitetura de alto nível de todos os seus módulos: jCompany FS Framework, jCompany IDE, jCompany Patterns & Methods, jCompany Test For Developer e jCompany Configuration Management.

Por fim, vimos como o jCompany se encaixa em uma estratégia mais ampla, de Open Source

Application Lifecycle Management, contextualizando o produto dentro do espectro maior da solução Powerlogic jALM.

Referências

Documentos relacionados

The Republics of Zambia and Zimbabwe, with support of the World Bank in partnership with the KAZA TFCA Secretariat, embarked on the development of the KAZA UNIVISA Pilot Project with

GER KUEHNAST, Joerg [1] 1.. GER WORMUTH,

--- Foi presente o processo de obras número 349/02, de Jorge Fernando Gomes de Pinho, residente no lugar de Dois, freguesia de S. Pedro de Castelões, Município de Oliveira de Azeméis,

A Companhia encerrou o trimestre com uma posição total de caixa de R$2,1 bilhões, considerando caixa e aplicações financeiras de R$1,1 bilhão mais R$1,0 bilhão em recebíveis

[r]

200 ml de água de coco 200 ml de água de coco 1 folha de couve 1 folha de couve Hortelã a gosto Hortelã a gosto Modo de preparo Modo de preparo Bater todos os. Bater todos os

(“Empresa”), relativos ao exercício findo em 31 de Dezembro de 2009, os quais são da responsabilidade do Conselho de Administração. Ao longo do exercício em apreço, o

Mário Jabur Filho, conforme dispõe a legislação vigente, comunica que estarão abertas as inscrições para seleção dos candidatos para preenchimento de vaga para Médico