Centrados em Dados (Primários)

Transcrição

1 Módulo B A.Casos de Uso Centrados em Dados (Primários) Este é um módulo prático que traz tutoriais com passos para implementação de Casos de Uso Padrões do jcompany Developer Suite, incluindo variações típicas (Inclusões e Extensões aos Casos de Uso).

2

3 A6Implementando o Padrão Manter Classe Capítulo 6 Implementando UC001.1 Manter UF- - Analisando a especificação A primeira especificação de Caso de Uso que iremos implementar está definida no diagrama da Figura B6.1. Figura B6.1. Especificação para UC001.1 Manter UF-. Este diagrama simples, com seus estereótipos, é suficiente para nos dizer exatamente tudo o que precisamos saber para codificar este Caso de Uso, com precisão. Isso porque este é um Caso de Uso Padrão definido pelo jcompany e automatizado em grande parte tanto por generalizações presentes na

4 Implementando o Padrão "Manter Classe" arquitetura, através do jcompany FS Framework, quanto por gerações de artefatos via jcompany IDE - Artifact Generator, para a parte específica*. Importante: Caso você não tenha realizado o tutorial de criação de projeto do Capítulo 3, faça agora, antes de iniciar este capítulo. - Obtendo Classes de Domínio em Java Em todos os Casos de Uso Padrões do jcompany, somente as classes que representam Entidades de Domínio precisam existir, como ponto de partida para o restante do desenvolvimento, assistido por roteiros Cheat-Sheets. De posse desta(s) classe(s), todos os demais artefatos Java EE necessários para a finalização do Caso de Uso serão gerados por assistentes de criação dos plugins do módulo jcompany IDE, chamados de Powerlogic jcompany Code Generator. Portanto, tudo o que precisamos para iniciar a construção do nosso primeiro Caso de Uso é a obtenção da classe Java Uf, por alguma de duas formas: Dirigido por Modelo, através de geração via ferramentas CASE. Neste caso, poderiam ser utilizadas estratégias de geração de código (ou MDA) para obtenção da classe a partir de um modelo UML como o da o Figura B6.1. Em nosso caso, inclusive, seria especialmente simples se fazer isto uma vez que nossos modelos já estão no mesmo plano de abstração das classes de construção, utilizando diretamente os nomes e tipos padrões Java. Pode-se utilizar qualquer ferramenta CASE razoável para este fim, mas recomendamos o Enterprise Architect (EA - como uma das melhores opções atuais em custo/benefício. o Criando-se as classes Java diretamente via Eclipse. No caso do projetista e desenvolvedor serem a mesma pessoa, ou na hipótese de não haver expertise em UML ou ferramenta CASE disponível, pode-se utilizar o diálogo do Eclipse para criação destas classes, diretamente - o que faremos em nosso caso. Para a criação da classe Java correspondente à entidade UF, residindo em arquivo chamado Uf.java, devemos seguir os seguintes passos: * Apesar da aparente simplicidade, mesmo este Caso de Uso Padrão inicial, chamado Manter Classe, esconde complexidades e perigos que muitas vezes passam despercebidos, mesmo por um desenvolvedor sênior. Recomendamos que a definição deste padrão seja lida, nos capítulos do Apêndice A, para uma melhor compreensão de tudo o que está envolvido.

5 Capítulo B6 1. Selecione o projeto rhtutorial_commons, posicione no pacote com.empresa.rhtutorial.entidade e use a tecla de atalho Ctrl+N" na treeview vá em "Java->Class". Figura B6.2. Diálogo padrão para criação de Classes, no pacote padrão para Entidades de Domínio Informe o nome Uf (seguindo convenção Java para nomes de classe), marque abstract e herde da classe préexistente AppBaseEntity, disponibilizada quando da criação do projeto, conforme a 2. Figura B6.3. Importante: Estas duas práticas são recomendadas mas não obrigatórias. Suas vantagens serão explicadas mais adiante e então você pode optar conscientemente em usá-las ou não.

6 Implementando o Padrão "Manter Classe" Figura B6.3. Classe Uf, com abstract marcado e superclasse AppBaseEntity (opcional) Digite as propriedades nome e sigla como private e tipo String (como para todas as classes do pacote java.lang, o import é desnecessário), conforme a 3. Figura B6.4. Figura B6.4. Classe Java correspondente à Entidade UF, com comentário Javadoc e práticas recomendadas.

7 Capítulo B6 Como dissemos, a classe acima poderia ser facilmente gerada por qualquer ferramenta CASE razoável a partir de modelagem UML. Mas repare que existem suplementos na especificação da entidade reproduzida na Figura B6.1: o Responsabilidades (responsibilities); o Restrições (constraints); o Tamanhos máximos para as propriedades. Iremos discorrer sobre como implementá-las, nos próximos tópicos. Por hora vamos entender melhor a estrutura básica: no modelo UML não herdamos de AppBaseEntity. De onde, então, tiramos isso? A herança de AppBaseEntity, no nosso caso, herda três propriedades pré-mapeadas altamente recomendadas como padrões corporativos, embora opcionais. Em nossa organização hipotética, desenvolvedores são instruídos para sempre herdarem estas propriedades, de modo que esta parte não precise ser replicada por todas as especificações. Obs.: Não incluímos na especificação, por questão de espaço, mas um DAS (Documento de Arquitetura de Software) contendo padrões corporativos deve existir e estabelecer definições globais como esta, para possibilitar a "especificação por exceção" no dia a dia (Specification by Exception). E que propriedades são herdados globalmente? o versao: Pré-mapeada e com nome de coluna correspondente VERSAO, esta propriedade implementa o padrão JPA para tratamento de concorrência otimista. Com este tratamento, quando qualquer alteração é realizada nos objetos, o próprio JPA incrementa um contador de versões nesta propriedade, e passa a utilizá-lo na where condition, para todos os comandos SQL de Update e Delete gerados. Deste modo, se dois usuários estão alterando o mesmo registro simultaneamente, há garantia de que um não irá sobrepor atualização de outro, caso o segundo não esteja com a versão atualizada dos dados recuperados. Esta é uma técnica altamente recomendada que, se não usada, implica em soluções alternativas bem piores, tais como: 1. Uso de concorrência pessimista (locks no SGBD durante a atualização por um usuário), algo em desuso e que penaliza dramaticamente a performance (mesmo com estratégias de trava em nível de registros dos SGBDs atuais); 2. Implementação manual de técnica similar, pelos desenvolvedores. Ao não usarem esta automação, desenvolvedores deverão codificar este teste nas condições where de seus updates e deletes e em todas elas, para evitar problemas de concorrência;

8 Implementando o Padrão "Manter Classe" 3. Em nossa experiência, quando não se usa o controle de versao do JPA (já existente há anos no Hibernate), na prática os desenvolvedores ignoram este problema e deixam ir para produção aplicações sem tratamento de concorrência. Isto é conhecido como o anti-padrão last commit wins (a última modificação sobrepõe anteriores, mesmo que o usuário corrente ignore uma modificação recente nos dados). Em sistemas de missão crítica, com alto índice de concorrência, este cenário oferece grande risco, e deve ser tratado. o dataultalteracao e usuarioultalteracao: Estas propriedades implementam o que é chamado no jcompany de auditoria pauta mínima. Seus valores são atualizados pelo jcompany para guardar o login do usuário que realizou a última alteração no objeto (registro no SGBD) e também a data/hora desta modificação. Elas se prestam para eventuais averiguações de segurança (auditorias) para rastrear usuários que introduzem informações prejudiciais à empresa, por má fé ou inadvertidamente. Apesar de somente manter o último usuário, costuma ser possível se encontrar o histórico de modificações com a análise de logs dos SGBDs. É um tipo de auditoria mais leve que não exige a criação de classes espelho para auditorias mais frequentes, em técnica conhecida no jcompany como auditoria rígida. A auditoria rígida, que usa um Extension de integração com o framework Open Source Hibernate Envers, deve ser utilizada para classes de maior relevância e que precisem de auditorias mais frequentes pelos usuários finais ou administradores da aplicação. Prosseguindo em nossa implementação do modelo UML para as Entidades: a responsabilidade exibe é um mecanismo padrão de especificação sugerido pelo jcompany, através do qual o projetista indica qual(is) propriedade(s) ele deseja utilizar para representar objetos da Entidade quando aparecerem pelos formulários da aplicação (Ex.: combos, radios, vinculados, ou títulos). A especificação Java prevê um método padrão para esta finalidade chamado tostring (manifestação em formato String, do objeto), utilizado pelo jcompany para este fim (chamamos a este método, também, de lookup do objeto). Portanto, a especificação exibe nos define o que implementar o método tostring de cada Entidade, apropriadamente. - Entendendo as Restrições Invariáveis (Invariant Constraints) As restrições ou validações invariáveis (invariant constraints) são restrições que devem sempre ser atendidas antes da criação ou alteração dos dados de uma agregação de objetos. Elas se contrapõem às validações variáveis, que variam em conformidade com cada Caso de Uso. O melhor local para se especificar restrições invariáveis é no Modelo de Entidades (de Domínio) - até porque o melhor local para se implementá-las é nas classes Java correspondentes. Infelizmente é muito comum encontrar validações invariáveis em formulário ou apêndices de especificações de Caso de Uso. Veremos que o jcompany suporta o padrão Java EE 6 Bean Validation (BV) que por sua vez se baseou no framework Hibernate Validator e permite a implementação de validações invariáveis via programação declarativa. Ou seja, através de anotações que podem ser adicionadas como complemento ao processo de mapeamento Objeto-Relacional. Ao dispensarmos a programação procedimental quando possível, maximizamos o reúso evitando perda de qualidade e produtividade. Veremos ainda que o Java EE 6 introduz uma integração básica entre anotações BV e o JSF 2.0, por exemplo, para que componentes JSF "herdem" declarações BV de obrigatoriedade e tal regra não precise ser declarada de modo redundante em páginas XHTML. O jcompany já antecipava esta integração em versões anteriores, entre componentes JSF 1.2 e o Hibernate Validator, de modo que seus desenvolvedores já se habituaram a evitar este tipo de redundância. Com este aprimoramento no padrão, na versão CDI (ou Jaguar 6.1) e superiores, o jcompany deixa para o App Server a integração básica entre BV e JSF e apenas a complementa, quando utilizando seu componentes especializados do Apache Trinidad. - Gerando Mapeamento para Classes de Lookup/Tabular - Objeto-Relacional I O próximo passo para nossa implementação é gerar uma primeira versão do mapeamento Objeto- Relacional para nossa Entidade Uf.

9 Capítulo B6 Para tanto, iremos utilizar o plugin apropriado do Powerlogic jcompany Code Generator, de número 01, acessível a partir da tecla de atalho control+n, tendo-se a classe alvo editada. 1. Acione control+n para que o diálogo de assistentes padrões do Eclipse se abra com uma relação de categorias. 2. Abaixo da categoria Powerlogic jcompany Code Generator encontram-se diversos assistentes que utilizaremos ao longo dos tutoriais. Acione o primeiro o 01 Mapeamento Objeto-Relacional. Figura B6.5. Acionando control+n sobre a classe Uf, e assistente para Mapeamento Objeto-Relacional. Utilizaremos a maior parte das opções neste momento, para realizar o mapeamento Objeto-Relacional e acrescentar metadados e boas práticas recomendadas para anotações em Entidades. A 3. Figura B6.6 explica as opções básicas do assistente:

10 Implementando o Padrão "Manter Classe" Figura B6.6. Primeiro passo do Assistente de Criação de Mapeamento Objeto-Relacional. #1. Indica para gerador criar uma nova classe com nome padrão <Entidade>Entity, descendente da Entidade, para conter códigos de implementação (tais como hashcode, equals, tostring ou propriedades transientes), em separado de métodos de validação e propriedades advindas do negócio/domínio, que ficam na entidade principal. #2. Indica para que mapeamentos no padrão JPA sejam gerados em métodos getters, e não sobre as propriedades. Este último é o default, por ser mais legível. #3. A opção Auditoria Rígida gera anotações para uso do Envers, framework de auditoria que mantém tabelas auxiliares para conter dados modificados nesta entidade. Veremos mais sobre isto em outros casos de uso. #4. A exclusão lógica acrescenta uma propriedade padrão "sithistoricoplc" na entidade, com valores possível de "A" (Ativo) ou "I" (Inativo), para viabilizar alterações que funcionam como uma exclusão aparente para o usuário. Veremos mais sobre isto em outros casos de uso. #5. A marcação de Versão indica para o gerador criar uma propriedade adicional na classe declarada como private int versao e com mapeamento Com isto, pode-se reutilizar o tratamento de concorrência otimista padrão do JPA. Se a entidade corrente herda de alguma classe o default deste campo é assumido como não gerar. #6. Indica para o gerador criar as propriedades private String usuarioultalteracao e private java.util.date dataultalteracao, nomes padrões e reservados no jcompany, utilizados pelo framework para manter o login do usuário que produziu a última modificação em um objeto (registro no SGBD) e a data/hora desta modificação. Se a entidade corrente herda de alguma classe o default deste campo é assumido como não gerar. Obs.: Neste e no caso anterior, o jcompany supõe que estes tipos de atributos são herdados (reutilizados) ao perceber a herança de AppBaseEntity. Com isso, altera o default para evitar gerá-los novamente. #7. Ativa uma rotina que padroniza termos sugeridos para o SGBD-R (nomes de tabelas e colunas). Ela aparece desabilitada pois necessita algumas configurações que são explicadas nas referências complementares do jcompany (Menu Help->Help Contents-> Powerlogic). #8. A lista em Estereótipo traz classificações do papel que a Entidade a ser mapeada exerce em uma agregação de entidades, segundo padrões arquiteturais do jcompany, auxiliando em boas

11 Capítulo B6 práticas de mapeamentos em cada caso. No caso de Uf, deve-se selecionar estereótipo Tabular, mas o desenvolvedor não perceberá diferenças funcionais se não fizer esta opção. Esta marcação irá levar à geração de uma anotação a mais na que será utilizada para otimizações*. #9. Classe para mapeamento. Caso tenha-se utilizado o control+n com a classe selecionada, ela já virá preenchida neste campo. Caso tenha-se entrado por outro caminho, deve-se selecionar uma classe de Entidade para mapeamento. #10. Proposta de nomenclatura para o nome da Tabela relacional (Table) do SGBD-R. O default é basicamente colocar nomes de classes em maiúsculas e utilizar sublinhado como separador. Pode-se modificar o nome e inclusive é obrigatório fazê-lo quando se deseja coincidir com nomes de tabelas existentes. #11. Traz diferentes estratégias para identificação de objetos, sendo Object-Id / Auto-Increment a preferível. Neste caso, o framework irá gerar mapeamento para uso do padrão recomendado via a propriedade padrão private Long id, com valores gerados automaticamente pelo SGBD- R. #12. Permite que se informe o nome para criação de uma estrutura de Sequence utilizada em alguns SGBDs relacionais, tais como Oracle, para geração de valores de identificação. O Padrão do jcompany é utilizar um Sequence por Tabela e com nome SE_<nome tabela>. Novamente pode-se modificar o nome para coincidir com Sequences existentes ou para se mudar esta estratégia (Ex.: um único sequence para várias tabelas). Para SGBDs que não usem o conceito de Sequence, este campo é desprezado. #13. Propriedades da classe candidatas a serem persistidas. Traz todas exceto as marcadas como propriedades transientes (transient). #14. Define classificações de mapeamentos típicos utilizados no jcompany. Deve-se reparar que, tal como nos estereótipos em nível da Classe, não há intenção aqui de se esgotar os tipos possíveis de mapeamento JPA, mas apenas de apresentar aqueles estereótipos que são distinguidos pelos padrões de arquitetura do framework. Podem-se alterar mapeamentos para outros tipos utilizando plugins como os do projeto Dali e/ou fazendo edição simples das anotações geradas, se preciso for, para cenários diferenciados. #15. Nomes de colunas para as propriedades das classes que, tal como no caso da Tabela, podem ser modificados, especialmente quando acessando uma base já existente. #16. A coluna Obrigatório permite que se marque se a Coluna gerada na Tabela relacional será gerada com NOT NULL (Obrigatório = Sim) ou NULL (Obrigatório = Não). #17. Permite que se selecione uma ou mais colunas para comporem a cláusula do método padrão tostring, que será gerado pelo jcompany concatenando-se estas colunas na ordem em que aparecem (pode depois ser editado, como desejado). O jcompany marca como padrão a primeira coluna do tipo String que encontrar. Como pedido na especificação, usaremos nome e sigla e, portanto, devemos marcar ambas. * Em linhas gerais: o jcompany irá utilizar algumas anotações como esta para realizar interceptações em implementações JPA baseadas no Hibernate, via Hibernate Listener, procurando interceptar e evitar recuperações automáticas a este tipo de classe, já que são mantidas em caching na camada de Controle. As demais estratégias de identificação, com chave composta (natural), não serão abordadas neste livro, mas somente no Volume II Tópicos Avançados desta série. Consulte também a documentação do produto na Ajuda On-Line para apoio em mapeamento de chaves naturais.

12 Implementando o Padrão "Manter Classe" #18. Utilizada em relacionamentos manytoone, onetomany e variações, contém o nome da classe referenciada por propriedades ou coleções. Normalmente esta coluna não precisa ser informada, sendo automaticamente preenchida pelo jcompany. #19. Nome que será utilizado durante a geração de DDL automatizada do jcompany para nomear Chaves Estrangeiras (Foreign Keys) quando mapeando relacionamentos. O JPA assume um nome com base em hashcode interno, mas é recomendável que se informe um nome legível no padrão exigido pelo DBA. #20. Tipo para a coluna a ser gerada na DDL (Data Definition Language) conforme o SGBD relacional. Normalmente não deve ser editado já que os tipos assumidos são adequados. Tamanhos limite (tamanho máximo) de cada coluna, conforme exigido pelo esquema relacional. Para tamanhos com decimais deve ser utilizado o formato [inteiro],[decimais] (Ex.: 11,2 para onze casas no total e duas casas decimais). No nosso exemplo inicial, nome terá 40 caracteres e sigla terá 2, conforme vemos no modelo da #21. Figura B6.6. Após preencher todos os campos conforme o exemplo da 4. Figura B6.6, vá para o próximo passo, com Next, e conclua o Assistente sem modificar nenhuma informação. Após a conclusão, o jcompany irá gerar a classe UfEntity (concreta) descendente de Uf (abstrata), conforme pedimos, e complementar ambas com diversas anotações, métodos getters e setters (padrões da especificação JavaBean), dentre outros.

13 Capítulo B6 Se realizarmos uma engenharia reversa (sincronização) das classes Java obtidas para a ferramenta CASE após esta geração, veríamos que o Modelo de Classes obtido ficaria como o da Figura B6.7. Dica: Ao contrário do que fizemos abaixo para efeito de explanação apenas, é recomendado que o projetista evite modelar os níveis concretos (UfEntity) e do framework (AppBaseEntity ou PlcBaseMapEntity) em seus diagramas, deste modo mantendo-se no seu foco, mais abstrato ou conceitual. Figura B6.7. Organização Final do Modelo de Entidades. Importante 1: A classe AppBaseEntity em si é apenas um Bridge (intermediário) simples, que permite desacoplamento direto com o framework do jcompany. Elas pode ser excluída do template de projetos (INI) e a organização optar por herdar entidades da classe PlcBaseMapEntity, que é quem possui os atributos versao, dataultalteracao e usuarioultalteracao. Importante 2: Ou como foi dito, é também possível não usar herança para entidades e solucionar este problema através de geração de código. Basta não especificar a herança que os plugins de geração de mapeamento objeto-relacional do jcompany automaticamente passam a sugerir a geração complementar das propriedades supra-citadas (além de outras específicas conforme a necessidade em cada padrão). Usaremos herança neste livro, mas o exemplo "rhdemo" que utilizamos no capítulo 3 traz entidades similares sem uso de herança e com atributos de versão e auditoria replicados nas entidades. 5. Vamos agora entender os detalhes do que foi gerado em cada uma das duas classes, Uf e UfEntity, exibidas respectivamente na Figura B6.8 e Figura B6.9.

14 Implementando o Padrão "Manter Classe" Figura B6.8. Classe de Domínio Uf, após geração de Mapeamento Objeto-Relacional com Plugin jcompany. #1. Todas as anotações padrão JPA são geradas. A anotação de herança é gerada uma vez que a declaração de fica no nível descendente. #2. A propriedade que implementa o Object-Id id com mapeamentos correspondentes é gerada. Nota: o jcompany faz manipulações de entidades utilizando o método getid, para Object-ID, ou getidnatural, para chaves naturais. É, portanto, um uso padrão. Caso se opte por alterar o nome da propriedade para outro que não id, deve-se prover getters e setters auxiliares, de adaptação *. #3. A anotações de validação (Ex: NotNull) são geradas com o novo conceito de grupos do padrão Bean Validation, utilizando o grupo genérico "PlcValGroupEntityList". Esta técnica é opcional mas altamente recomendada, pois permitirá que linhas com nome em branco, no formulário, sejam desprezadas! Todas as validações a serem acrescentadas em Entidades do padrão "Tabular", como veremos, devem usar esta técnica. #4. O jcompany utiliza uma extensão do Bean Validation disponibilizada pelo MyFaces, chamada ExtVal, para validar propriedades de uma Entidade de modo condicional (RequiredIf). Em conjunto com a técnica de grupos descrita em "3", consegue-se então garantir validações apropriadas e entradas de dados em formulários de alta produtiviadde, em várias linhas e com desprezo de linhas em branco. #5. As anotações para mapeamento de cada propriedade são geradas segundo o padrão JPA do Java EE 6, utilizando os critérios de tamanho e outros informados. Obs.: no exemplo a anotação "@Column" não foi gerada pois o desenvolvedor não informou nome de coluna específico para a tabela em banco relacional, então o JPA assumirá o seu default. * O Object-Id ou OID é um identificador numérico interno e auto-gerado pelo SGBD, mapeado como a Primary-Key no SGBD, implementa o conceito de chave fictícia ou substituta, que é a estratégia de identificação mais recomendada atualmente,

15 Capítulo B6 #6. Uma anotação especial também indica para que seja verificada duplicidade de nomes, dentre toda a população de objetos da classe, uma regra que não é possível de ser feita no padrão BV no escopo da classe. #7. Finalmente, os getters e setters padrões da especificação JavaBean são gerados para cada propriedade. Figura B6.9. Classe descendente UfEntity gerada para separar implementações do Desenvolvedor das informações de Domínio. #1. Estas anotações iniciadas com o prefixo reservado SPlc (Powerlogic Stereotypes) são do jcompany e definem um estereótipo padrão CDI (somente jcompany 6.x CDI ou Jaguar). O estereótipo "carimba" a classe como uma "Entidade" para ativação de lógicas genéricas do jcompany durante procedimentos de IoC/DI. #2. As anotações que definem um Entity Bean no JPA, bem como tabela de mapeamento, são geradas. #3. O AcessType é anotação JPA, para indicar que anotações estão nas propriedades (field) e não em métodos. #4. Estas anotações iniciadas com o prefixo reservado Plc (Powerlogic) são do jcompany e utilizadas para lógicas de otimização via especializações de Listeners. Em resumo, podem evitar a produção de queries desnecessárias para estas classes, já que são mantidas em caching na camada Controle pelo jcompany. #5. As NamedQueries são um recurso altamente recomendado pelo JPA e utilizado pelo jcompany para maximizar os benefícios da programação declarativa. A NamedQuery com nome padrão [Entidade].querySelLookup é utilizada pelo jcompany para recuperar objetos referenciados e traz unicamente as propriedades de identificação e marcadas como lookup (presentes também no tostring). Deste modo, o jcompany evita recuperações perigosas e dispensa programação manual para preenchimento de formulários e suas referências*. * As NamedQueries, assim como o mapeamento em si, ficam nas Entidades de Domínio, mas somente são utilizadas pela camada de Persistência (DAO).

16 Implementando o Padrão "Manter Classe" #6. A Classe concreta UfEntity sempre herda propriedades e métodos de domínio de Uf e, deste modo, separa programações de baixo nível das programações de domínio*. #7. Método padrão Java tostring é gerado automaticamente, utilizando-se as duas propriedades de lookup marcadas e com separação por hífen. Este método é utilizado pelo jcompany para exposição de valores da classe em objetos gráficos tais como combos e radio, bem como títulos dinâmicos de páginas, em alguns Casos de Uso Padrões que não editem coleções, mas uma agregação de objetos por vez. O desenvolvedor pode alterá-lo para a formatação desejada. 6. Para finalizar, o jcompany também gera uma entrada da Entidade no arquivo "persistence.xml". O JPA 2.0 pode indentificar as classes mapeadas automaticamente mas existem situações específicas, dependendo ainda do App Server, em que explicitar as entidades é necessário. Figura B6.10. Arquivo persistence.xml, acrescido da Entidade recém-mapeada. Fazendo uma revisão de tudo o que geramos, podemos listar: o Mapeamento Objeto-Relacional em si, incluindo um subconjunto principal de opções JPA automatizado pelo framework. Mapeamentos mais específicos e raros podem ser feitos, sem problemas, possivelmente exigindo uma ou outra customização via código procedimental, mas 95% do esforço de mapeamento, segundo nossa experiência prática, estarão resolvidos e atendidos pelo segmento padrão suportado. o Classe descendente para segmentação projeto/implementação, opcional, porém altamente recomendada como DP para simplificação e isolamento de regras de negócio e implementações de domínio em geral. o Anotações específicas do jcompany para uso em otimizações diversas, tais como recuperações eficientes de referências (especialmente importantes para o Caso de Uso Padrão Manter Classe, que se constitui em grande parte de grupos de objetos classificadores). o Método tostring para exibição da classe em componentes visuais e títulos de formulários. o Getters e Setters para propriedades, importações, e outras anotações de menor importância, tal o Registro no arquivo persistence.xml. Por tudo isso, percebemos que o plugin do Powerlogic jcompany Code Generator vai além da tarefa básica de geração de Mapeamento Objeto-Relacional em si, produzindo na verdade uma primeira versão bastante aprimorada para implementação de Entidades de Domínio que segue melhores práticas para aplicações corporativas, automatizadas em grande parte pelo jcompany FS Framework. É o que chamamos de plugins de processo, ou guias pelos padrões da organização. Este tipo de plugin foi discutido no capítulo 3, e é voltado apenas para a criação de uma primeira versão da * O interessante neste caso é que esta separação, apesar de nítida, é realizada no mesmo plano de abstração. Ou seja, é um tipo de separação de conceitos mais OO, que dispensa transformações de modelo em vários planos de abstração é um tipo de separação de conceitos que tende a se preservar com maior eficácia ao longo do tempo.

17 Capítulo B6 solução de forma a evitar erros grosseiros. Na sequência, se forem necessários ajustes e alterações quaisquer das anotações produzidas, deve-se utilizar plugins de edição convencional do Eclipse, homologados e disponibilizados no jcompany para este fim. Importante: Caso o desenvolvedor julgue conveniente, pode disparar um desfaz (undo), retornando a classe a seu estado original e refazendo a criação. O desfaz pode ser disparado no atalho exibido na Figura B6.11. Figura B6.11. Opção de desfazer geração de mapeamento Objeto-Relacional, destacada em amarelo Uma lista de modificações a serem realizadas é apresentada antes da operação. O jcompany irá desfazer somente a última geração feita. Para se desfazer gerações antigas, deve-se editar os artefatos envolvidos e realizar ajustes manualmente. - Implementando Validações de Domínio Validação de Entrada I Antes de implementarmos nosso Caso de Uso em si, devemos ainda complementar nossa Entidade com anotações de validações, para garantir as restrições especificadas pelo projetista. O jcompany implementa o padrão Bean Validation. Para garantir, por exemplo, que sigla tenha tamanho de no mínimo duas posições, ou exatamente duas, basta acrescentar mais anotações, como abaixo. 1. Edite a propriedade sigla e sobre ela. Em seguida, digite control+space. Uma lista de opções de validações declarativas do jcompany aparecem. conforme a Figura B6.12. Figura B6.12. Validações via Anotações do jcompany (a anotação está deslocada para exibir a propriedade). Cada validação é exibida com sua documentação javadoc, o que facilita a rápida inspeção. 2. Após selecionar a validação desejada, conheça as suas opções de declaração (propriedades da anotação) pressionando a tecla shift e sobrepondo o mouse sobre a anotação, conforme a Figura B6.13.

18 Implementando o Padrão "Manter Classe" Figura B6.13. Apertar shift com o cursor do mouse sobre a Anotação exibe suas propriedades. Veja que é possível utilizar a propriedade size para indicar o tamanho exato que desejamos. 3. Informe size=2 para encerrar o trabalho. 4. Em seguida, procure pela que iremos utilizar para garantir que os valores informados serão em letras maiúsculas. Esta segunda anotação fica de exercício para o leitor, que deverá então obter o resultado exibido na Figura B6.14. Repare que usamos uma Enumeração SimpleFormat definida dentro da PlcValSimpleFormat. Figura B6.14. Validações declaradas para a propriedade sigla. Até aqui resolvermos a restrição Siglas devem ser alfanuméricas e maiúsculas e também a restrição de tamanho mínimo de 2 para sigla (além de 1 para nome, implicitamente, já que Estas são validações são em nível de propriedade. Mas e quanto às validações de duplicidade para nome e sigla? Elas são validações que consideramos em nível de classe, já que devem percorrer vários objetos da classe para serem averiguadas. Como iremos resolvê-las? No caso da propriedade nome, o jcompany já irá cuidar para que não tenha valores duplicados, graças à Esta anotação assume um teste de duplicata, e é gerada automaticamente no primeiro campo de uma Entidade mapeada no padrão "Tabular". Na Figura B6.15 explicitamos a propriedade e também o indicador para teste de duplicata. Figura B6.15. Anotação PlcReference com teste de duplicata explícito (apesar de ser default)

19 Capítulo B6 E quanto à duplicidade de sigla? Neste caso, ultrapassamos o limite do que conseguimos fazer via programação declarativa, no escopo de um objeto de domínio, porque a anotação PlcReference atualmente pode ser utilizada em apenas uma única propriedade da entidade, normalmente a "de referência" para o preenchimento das demais. Então, para este teste deve-se programar em camada controle, no MB, esta validação. - Entendendo a Orquestração via Cheat-Sheets (Folhas de Apontamentos) Com nosso Modelo de Domínio (Modelo de Classes para Entidades do Negócio) completo, mapeado e decorado com anotações de validações e otimizações, estamos prontos para iniciar a construção de nosso primeiro Caso de Uso Padrão. Prosseguir para programações de Caso de Uso antes de estarmos certos de explorar todo o potencial de modelagem OO, mapeamento Objeto-Relacional e programação declarativa é um erro que cobra seu preço na forma de queda de qualidade e produtividade. Uma vez que estamos certos de ter esgotado o potencial de solução no nível da Entidade, passaremos a contar com um novo aliado para a confecção do Caso de Uso em si: os Cheat-Sheets ou Folhas de Apontamentos. Este recurso é utilizado pelo jcompany para prover roteiros que conduzem o desenvolvedor do início até o fim da implementação de um Caso de Uso Padrão, utilizando arquitetura MVC2-P. Neste cenário, os Cheat-Sheet são utilizados como orquestradores do processo de construção, guiando o desenvolvedor por passos e plugins apropriados em cada um deles. Tipicamente, um roteiro em Cheat-Sheet do jcompany irá seguir a seguinte estrutura: o Passo 1: Apresentar o Caso de Uso Padrão brevemente, com hiperlinks para definição mais extensa na documentação. o Passo 2: Chamar um plugin de processo específico do jcompany, que irá criar uma primeira versão gerando todos os artefatos não-java ( XHTML, XML, Properties, etc.) envolvidos. Lembre-se que classes Java são generalizadas. O jcompany não gera código Java procedimental, o que preserva a produtividade durante as manutenções! o Passos 3, 4, 5 e 6: Em cada um destes passos, o jcompany abrirá os artefatos gerados ou alterados pela geração no passo 2, para as camadas MVC-P, respectivamente Visão, Controle, Modelo e Persistência. Cada passo abre o artefato através de um plugin de edição homologado para este fim. o Passo 7: O jcompany dispara a construção e liberação do arquivo WAR via Maven, utilizando a liberação completa na primeira chamada (alguns minutos) e a liberação rápida com reinicialização nas subsequentes (alguns segundos). Vamos acionar o nosso primeiro roteiro. 1. Acesse o menu Help -> Cheat-Sheets.... Um diálogo com várias categorias de Cheat-Sheets aparecerá. 2. Selecione jcompany e, dentro da categoria, o roteiro Caso de Uso Manter Classe.

20 Implementando o Padrão "Manter Classe" Figura B6.16. Relação de opções de roteiros do jcompany, com seleção do Manter Classe. 3. Se o primeiro passo estiver fechado, deve-se clicar para expandi-lo*. 4. O primeiro passo traz uma breve introdução e permite, com o clique no botão de ajuda, que se recupere a documentação completa para o padrão a ser desenvolvido, conforme destacado na Figura B6.17. Figura B6.17. Primeiro passo do Cheat-Sheet com destaque para o botão de ajuda. * É possível que um Cheat-Sheet abra com o passo inicial expandido, dependendo do estado em que a última utilização deixou o roteiro. O Eclipse procura manter o último estado do Cheat-Sheet.

21 Capítulo B6 - Gerando Artefatos Não-Java Geração de Artefatos I No segundo passo, o roteiro irá acionar um plugin de processo do jcompany trazendo um Assistente de Criação para o Caso de Uso Padrão com diversas opções que irão resultar na geração, principalmente, de artefatos não Java envolvidos, tais como novos arquivos XHTML e novos registros em XML. Por questões didáticas, neste capítulo vamos apenas introduzir cada janela deste assistente, explorando mais a fundo somente informações que precisaremos para nosso Caso de Uso atual. Em Casos de Uso posteriores, iremos explicar diversas opções adicionais do Assistente de Criação, bem como entender mais a fundo o que ele produz. A primeira página do Assistente é apresentada na 1. Figura B6.18 com preenchimento sugerido para nosso Caso de Uso UC001.1 Manter UF- e explicações sobre o uso de cada campo.

22 Implementando o Padrão "Manter Classe" Figura B6.18. Passo Inicial do Assistente de Criação para Manter Classe. #1. Projeto: Pode-se alterar o projeto corrente (assumido por default) para a geração em módulos, por exemplo. #2. Entidade: Este campo permite que se selecione a Entidade raiz da Agregação envolvida, cujas propriedades serão utilizadas como base para a proposta de um formulário e cujas instâncias serão persistidas, segundo a arquitetura MVC. Deve-se selecionar uma classe concreta, no nosso caso UfEntity. #3. Tipo URL: A URL lógica não endereça nenhum artefato XHTML, que por sua vez ficam abaixo de 'WEB-INF'. Facilita refatorações e melhora níveis de segurança. Já a URL Física endereça artefatos XHTML diretamente, que para isso ficam fora de 'WEB-INF'. A segunda facilita entendimento em fases iniciais de uso. #4. URL: Texto utilizado para compor a URL do(s) formulário(s) gerado(s) pelo jcompany. Para URLs lógicas segue a convenção /f/n/<url><sufixo do padrão>, onde o sufixo pode ser man, mdt, mds, ctl, etc., conforme o padrão do jcompany. Ex.: /f/n/uftab. Já para URLs físicas, a convenção é /f/<endereço físico de um XHTML. Ex.: /f/uf.xhtml. #5. End. Relativo XHTML: É recomendado que se defina um subdiretório, preferencialmente com o mesmo texto da URL, abaixo do qual serão gerados os XHTMLs, deste modo facilitando sua localização. Assim, informar uf para uma URL lógica uf fará com que o XHTML seja gerado abaixo de [apl]/web-inf/fcls/uf/uf.xhtml. Para uma URL física uf, fará com que o XHTML seja gerado em [apl]/uf/uf.xhtml #6. Nome do pacote: Assumido. Nesta versão, não deve ser modificado. #7. Classe de Controle: Nome de classe de controle padrão JSF ManagedBean, obrigatória por conter metadados (anotações) que definem o comportamento do padrão sendo implementado. Faremos regras para camada Controle mais adiante. Portanto, deve-se deixar o padrão "UfMB. #8. Classe de Fachada: Nome de classe de controle padrão Façade, que intermedia chamadas às regras de negócio ou serviços da camada Modelo. Informe uma fachada específica somente se pretender criar novos contratos entre as camadas, adicionais aos contratos de CRUD generalizados pelo jcompany. Se desejado, recomenda-se usar o padrão "<servico>facadeimpl.

23 Capítulo B6 #9. Classe de Modelo: Nome de classe de modelo padrão Repository (serviços auxiliares para a Entidade). O padrão é reusar uma classe genérica do jcompany. Somente altere o nome (e consequentemente acione a criação de uma nova classe) caso preveja a necessidade de implementação de programações nesta camada. Obs.: neste caso a classe deve herdar de PlcBaseRepository. Obs. 1: O jcompany irá criar somente a estrutura básica destas classes (declaração) no projeto/pacote padrão. Como já vimos, o jcompany não gera códigos Java procedimentais, mas trabalha com generalizações OO e programação declarativa para reutilizá-los. Obs. 2: Os sufixos padrões para classes de Controle (Action) e serviço de Modelo (Manager) são definidos em metadados via anotações e podem ser customizados como veremos mais a frente. #10. Classe de Persistência: Nome de classe de camada Persistência seguindo o padrão DAO (serviços de acesso ao mecanismo de persistência). É sempre gerada, mesmo que vazia, por ter um uso típico em casos de uso cadastrais (CRUD). Deve preferencialmente ser chamada de <entidade>dao. Após preencher todos os campos como indicado na 2. Figura B6.18, iremos apertar o botão Next para seguir para a página (segunda página do Assistente), onde preencheremos somente o título, com UF em maiúsculo, "Unidades da Federação", "Manter UF" ou "Gerir UF", conforme desejado. o Título: Título a ser utilizado no Formulário e Item de Menu que serão gerados. Por hora, não explicaremos as diversas opções desta segunda página, que veremos em detalhe nos próximos capítulos. 3. Após informar o título, clique novamente em Next para seguirmos para a terceira página do Assistente.

24 Implementando o Padrão "Manter Classe" Figura B6.19. Terceira página do Assistente de Criação do Caso de Uso Padrão Manter Classe. Esta página nos permite personalizar uma primeira versão de página XHTML, apropriada para nosso Caso de Uso Padrão e que poderá ser estendida posteriormente para conter especificidades. Em nosso Caso de Uso atual vamos apenas entender algumas opções básicas deste passo, já que o padrão assumido nos servirá sem necessidade de intervenções: #1. Tipo de Página XHTML: O jcompany disponibiliza duas opções para a geração da estrutura de um formulário: A opção "Powerlogic/Trinidad" gera tags do jcompany diretamente (plcf), que acionam componentes especializados do Apache Trinidad. Já a opção "RichFaces" gera tags JSF simples e componentes RichFaces quando necessários. Com a primeira obtém-se maior ganho de recursos, mas a segunda pode facilitar o entendimento por quem já conhece RichFaces ou está iniciando em JSF. #2. Usar I18n (Internationalization): Indica para o jcompany gerar os rótulos de cada propriedade no arquivo ApplicationResources.properties e não diretamente na página XHTML. #3. Usar borda na tabela: É uma opção somente útil em tempo de visualização, que exibe borda na tabela HTML que define o contorno do formulário, para auxílio visual apenas. A tabela que define formulários, nas peles do jcompany, não são exibidas com bordas, como padrão. #4. Visualizar Pele: Permite que se escolha uma pele distinta para a visualização, eventualmente uma pele específica da empresa não pré-existente na palheta do combo motivo pelo qual o mesmo pode ser modificado. #5. Visualizar Manutenção: Aciona um modo de visualização (Preview) do formulário no Navegador padrão do usuário. #6. Coluna Usa? : Permite que propriedades da classe sejam retiradas da visualização no formulário. Perceba que o jcompany já assume que propriedades padrões de auditoria pauta mínima não devam aparecer. Dica: Para campos auxiliares transientes no formulário, recomenda-se a criação de propriedades transientes (Ex.: private transient String auxiliar) nas classes concretas. 4. Para nosso propósito atual, podemos concluir o Assistente de Criação clicando em Finish e encerrando o segundo passo do roteiro Cheat-Sheet. Após o alerta de conclusão da geração, o

25 Capítulo B6 próximo passo do roteiro Cheat-Sheet se abrirá automaticamente: Editando Artefatos da Camada de Visualização. - Editando artefatos gerados Edição de Camada Visão I Os passos 3, 4, 5 e 6 dos Cheat-Sheets de geração de Casos de Uso Padrões irão editar artefatos produzidos em cada camada MVC-P, na ordem: View, Controller, Model e Persistence. Em nosso caso específico, na camada Visão, o plugin gerou uma página XHTML, alterou o arquivo de mensagens ApplicationResources_pt_BR.properties e o de menu geralmenu.xhtml para incluir rótulos e uma nova chamada via menu. Os dois primeiros arquivos possuem um formato diferente e, portanto, exigem um editor distinto. Vejamos quais são sugeridos e homologados pelo jcompany: o XHTML: O plugin homologado para edição de XHTMLs é o JBoss Tools, que irá se abrir como padrão. Especificamente para Casos de Uso Manter Classe é gerado apenas um artefato de XHTML com nome padrão [url].xhtml, ou seja: uf.xhtml em nosso exemplo. Importante: se um diálogo de configuração aparecer e você não tiver familiaridade com o jboss Tools JSFEditor, basta marcar "Do not show this dialog again" e "Skip", para usar funcionalidades básicas. Figura B6.20. Editor JBoss Tools homologado para edições de XHTML. #1. Versão textual do XHTML. Possui recursos de auto-complete e ajuda on-line sensitiva ao contexto, bastando que se posicione o cursor sobre um atributo de Tag. #2. O plugin WYSIWYG não esta homologado para a versão jcompany 6. Ele será disponibilizado em atualizações futuras. #3. Visualização de opções (hierarquia de Tag) sensível ao contexto. Ao posicionar em um segmento do documento diversas opções XHTML são apresentadas nesta barra. Basta clicar na Tag" desejada para adicionar novos elementos ao formulário. #4. Seleção de Modo de Edição.

26 Implementando o Padrão "Manter Classe" o Mensagens I18n: O plugin homologado para a edição de arquivos de Properties é o JBoss Tools Properties Editor. Este plugin disponibiliza um filtro para busca por chave e/ou valor. Além disso, alerta o usuário quando há duplicidade de chaves. Figura B6.21. Mensagens de texto editadas. #1. Opções para incluir uma nova mensagem, editar ou excluir uma selecionada. #2. Botões Up e Down para ordenação das chaves. #3. Coluna com as chaves cadastradas exibidas em ordem alfabética. #4. Visualização dos valores de cada chave. o Entrada de Menu: O assistente do jcompany gera uma nova chamada para a URL principal do Caso de Uso gerado (em nosso caso /f/n/uf ) ao final do último bloco de menu que encontrar no arquivo padrão geralmenu.xhtml. Este arquivo é um XHTML padrão bastante simples de entender. - Editando artefatos gerados Edição de Camada Controle I Até a versão do jcompany 5.5.x, uma declaração de fluxo de navegação no arquivo faces-config.xml era obrigatório e portanto gerada, para todos os Casos de Uso Padrão. Em Java EE 6 esta navegação padrão pode ser assumida como default. Uma navegação por convenção é assumida no jcompany para os casos de uso padrões e uma entrada neste arquivo somente é necessária se for desejável configurar uma navegação diferente. Anotações de metadados para a camada Controle que anteriormente também eram geradas em arquivos "package-info.java" são assumidas por default na versão CDI (Jagaur), segundo técnica conhecida por "convenção sobre configuração". Pode-se alterar a convenção através de anotações na classe UfMB. o Declaração de Fluxo de Navegação: Portanto, se for desejado customizar uma navegação, basta editar o arquivo faces-config.xml com o editor visual padrão. Não é o caso de nosso Caso de Uso padrão Manter Classe. Sua navegação é trivial pois o usuário permanece sempre no mesmo formulário e URL.

27 Capítulo B6 Figura B6.22. Editor do Red Hat Studio homologado para edição de arquivos faces-config.xml. #1. Arquivo de configuração JSF para a aplicação, em formato XML e com auxílio em todas as seções. #2. Uma regra de navegação (navigation rule) de desconexão vem pré-configurada para atender ao botão gerado como padrão no rodapé das aplicações #3. A nossa regra de navegação como seria se fosse gerada: com fluxo simples, que apenas mantém o usuário na mesma página. Note que o jcompany introduz sufixos padrões nas URLs (tab, neste caso), que são convenções úteis para identificação simples de padrões pelo framework. Pode-se alterar este padrão de URL, se desejado. #4. Como nos outros editores jboss Tools, abas permitem que se comute para visualização em modo de diagrama ou texto XML. Figura B6.23. Modo gráfico para exibição de fluxos de navegação, representando Desconexão e Mantém UF. o Classe de Controle: O Assistente de Criação cria uma classe UfMB de controle que vem com declarações possíveis de metadados (anotações do jcompany) comentadas. Para customizar uma série de comportamentos, basta descomentá-los. Veremos mais sobre esta classe em capítulos futuros! - Editando artefatos gerados Edição de Camada Modelo/Domínio I Neste passo somente as Entidades serão abertas. Em nosso exemplo, Uf.java e UfEntity.java. Obs.: Na camada de Modelo/Domínio, até a versão 5.5, o jcompany gerava um outro arquivo de metadados, não mais necessário.

28 Implementando o Padrão "Manter Classe" - Editando artefatos gerados Edição de Camada Persistência I Neste passo o jcompany irá abrir para edição o arquivo "persistence.xml" (que contém a entrada para UfEntity, gerada durante o mapeamento objeto-relacional, e uma classe "UfDAO", gerada mas vazia, destinada apenas a conter acessos adicionais à camada de persistência que sejam necessários, além dos acessos padrões que são feitos de modo generalizado pelo jcompany, reutilizando as NamedQueries. Veremos que as classes de DAO serão mais importantes em Casos de Uso Padrões mais avançados, onde conterá declarações para pesquisas no estilo "QBE (Query By Example)", tão utilizadas em componentes do tipo "GRID", utilizados para consulta ou seleção de objetos em classes de grande população (que não é o caso de Uf). - Realizando Liberação Completa via Maven Construção e Liberação I Neste ponto, já estamos de posse de todos os artefatos que precisamos para nosso Caso de Uso finalizados. Eles foram não somente gerados pelo plugin de criação segundo melhores práticas, como ainda revisados e customizados onde necessário, através de plugins de edição. No presente tutorial, ainda não precisamos de nenhuma customização específica, pois o padrão nos atendeu perfeitamente. Mas nos próximos Casos de Uso, mais complexos, iremos explorar várias customizações típicas. O passo de finalização, portanto, se trata simplesmente do disparo de rotina Maven para empacotamento seguido de liberação. Esta rotina irá agrupar nossos projetos em um executável WAR, apropriado para executar no Application Server correntemente configurado - em nosso caso, o Contêiner Web Tomcat 6.x (já que não usaremos EJB). 1. Clique no último passo, certificando-se de que o projeto rhtutorial_parent está em foco. 2. Outra forma de acionar a liberação independente do Cheat-Sheet é disparando-se diretamente a opção de Liberação para Tomcat Completa Desenvolvimento na barra de External Tools. Faça-o, conforme indicado na figura 3. Figura B6.24. Figura B6.24. Acionando Menu External Tools da barra de ícones do Eclipse

29 Capítulo B6 No primeiro acesso será necessário marcar a opção, conforme indicado na Figura B6.25, mas nas subsequentes um atalho será criado, facilitando o disparo. Note que o diálogo de External Tools permite diversas personalizações das rotinas. Figura B6.25. Diálogo do External Tools com diversas tarefas Maven genéricas e opções. #1. A lista exibe tarefas Maven desenvolvidas e/ou homologadas no jcompany. #2. Em Working Directory vemos que a variável ${project_loc} indica como alvo o projeto corrente. Obs.: Esta entrada pode ser duplicada e o projeto "rhtutorial_parent" explicitamente informado, para dispensar a preocupação com foco no projeto correto. Faremos isso no próximo tópico. #3. Em argumentos, diversas opções Maven são usadas. Discutiremos variações de uso em outros capítulos. 4. Após o disparo, observe o resultado na janela Console. O resultado final Ok da construção e liberação deve durar cerca de 1 minuto, em uma máquina com configurações recomendas do

30 Implementando o Padrão "Manter Classe" jcompany, e ser similar ao da Figura B6.26. Este tempo será bem menor nas liberações subsequentes, como veremos no próximo capítulo. Figura B6.26. Relatório final do Maven sobre a liberação completa (primeira vez, mais demorada). 5. Para compreender o resultado desta tarefa, confira o diretório onde se encontra instalado o Tomcat, em [jcompany]\servers\tomcat\, conforme a Figura B6.27. Figura B6.27. Diretórios do Tomcat modificados em destaque. Como funciona? Após gerar o arquivo rhtutorial.war, a rotina Maven expande seu conteúdo na pasta webapps e envia um arquivo de definição de contexto (presente no template INI) para a pasta conf\catalina\localhost. A configuração é a mesma também para ambientes de desenvolvimento Linux. - Definindo atalhos de tarefas Maven específicos para um projeto É comum ocorrerem falhas ao se clicar em Deploy, como resultado da perda de foco no projeto rhtutorial. Neste caso, pode-se clicar no projeto (para forçar o foco) e reabrir o passo do Cheat-Sheet (ou clicar novamente na tarefa do External Tools).

31 Capítulo B6 Figura B6.28. Para liberação, via Cheat-Sheets ou atalho External Tools, o projeto principal deve estar em foco. Este problema pode ocorrer porque, como descrevemos na Figura B6.25, as rotinas Maven do jcompany estão configuradas para pegar o projeto correntemente em foco no Eclipse (${project_loc}). Para fugir deste incômodo, é possível se criar tarefas Maven apontando para cada projeto explicitamente, da seguinte forma: 1. Selecione, dentro do diálogo do External Tools, a tarefa desejada e clique direito, acionando a opção Duplicate, como exibido na Figura B6.29. Figura B6.29. Duplicando uma tarefa do External Tools. 2. Em seguida, altere o nome e troque o Working Directory de ${project_loc} para o projeto específico, selecionando-o através do botão Browser Workspace. 3. Ao final, clique em Apply. A tela deve ficar similar à da Figura B6.30.

32 Implementando o Padrão "Manter Classe" Figura B6.30. Criando tarefas específicas de Liberação com Reinicio, com partes modificadas em amarelo. Obs.: Esta prática pode levar à proliferação de tarefas, mas é útil para quem trabalha com poucos projetos simultaneamente. Preparando Infra-Estrutura para Testes Agora estamos preparados para testar o resultado de nosso desenvolvimento, mas precisamos antes de um SGBD-R disponível e de iniciar o Application Server. - Utilizando o Apache Derby Poderíamos alterar a conexão padrão de pool JDBC que vem no template INI para nos conectar em desenvolvimento com um SGBD-R Oracle ou MySQL, por exemplo. Mas como estamos usando JPA, podemos utilizar uma opção de SGBD-R mais leve e flexível, escrita em Java: o Apache Derby*. O Apache Derby tem qualidade de produção para Mobile e suporta SQL ANSI em suas últimas versões, viabilizando um desenvolvimento robusto e, graças ao JPA/Hibernate, posteriormente portável. O jcompany homologa também um plugin Eclipse para o Apache Derby e já o pré-configura para facilitar a disponibilização imediata de um Banco de Dados local em escopo do projeto. Este banco vem com nome padrão bancolocal. Por fim, o jcompany também traz configurados os arquivos de contexto do Tomcat com pool JDBC para acessar este Banco de Dado local. Com tudo isso, pode-se inicar um desenvolvimento prontamente, sem dependências externas ou de quaisquer configurações sujeitas a problemas... Para ativar o Apache Derby para nosso projeto, precisamos: 1. Adicione a natureza Apache Derby ao projeto, clicando direito no mesmo e acessando Apache Derby > Add Apache Derby Nature * Este SGBD-R possui um trajeto curioso: criado pela empresa Cloudscape, detinha o nome de Cloudscape DB. Esta empresa foi adquirida pela Informix, que por sua vez foi adquirida pela IBM, que doou o produto para o grupo Apache, quando mudou de nome para Apache Derby. Finalmente, na versão 6.0 do Java, está sendo incorporado como solução embutida de SGBD-R.

33 Capítulo B6 Figura B6.31. Adicionando Natureza Apache Derby ao projeto. 2. Em seguida levante o serviço, utilizando a opção Apache Derby -> Start Derby Network Server. Figura B6.32. Iniciando serviço do Apache Derby. 3. Confira a ativação do serviço. O indicador de que um serviço de Banco de Dados Derby está servindo na porta 1527 é uma seta verde que passa a decorar o projeto e uma mensagem (em português, já que o Derby tem tradução embutida para este idioma!) na janela de console. Figura B6.33. Indicadores de serviço de Banco de Dados Derby ativo. 4. Confira o arquivo de conexão de Pool JDBC. O arquivo rhtutorial.xml, conhecido como arquivo de contexto no Tomcat, pré-configurado na aplicação, vem com nome bancolocal e opção de autocriação para que um novo Banco de Dados seja criado, se não existir (o banco é criado na raiz do projeto rhtutorial ). Este arquivo deve ter sido liberado para a pasta conf/catalina/localhost do Tomcat.

34 Implementando o Padrão "Manter Classe" Figura B6.34. Configurações chave de pool para o Derby. Obs.: Pode-se, naturalmente, alterar estas configurações para se utilizar qualquer outro SGBD-R desejado, apenas cuidando para disponibilizar o driver JDBC de acesso na pasta common/lib do Tomcat. - Utilizando o Apache Tomcat Com o Banco de Dados no ar, podemos ativar finalmente o Tomcat, que usaremos durante este livro. 1. Para iniciar o Tomcat, clique no ícone "seta verde",na barra do Eclipse. Figura B6.35. Atalhos para disparo, parada e reinício do Tomcat. O plugin para gerenciamento do Tomcat homologado no jcompany é o Tomcat Sysdeo. Mais adiante veremos como configurá-lo para depuração e hot-deploy (atualização de classes que dispensam o deploy Maven). Um indicador chave de que o serviço do Tomcat está configurado corretamente é a mensagem do conector HTTP na janela de console do Tomcat, como na Figura B6.36. Figura B6.36. Mensagem de serviço HTTP ok. 2. Para executar a nossa aplicação, como está sendo servida na porta 8080, digite no Navegador:

35 Capítulo B6 - Entendendo a Segurança Controle de Acesso I Logo que executarmos a chamada da aplicação, seremos apresentados a uma página de autenticação do jcompany, conforme a Figura B6.37. Figura B6.37. Página de autenticação após a chamada da aplicação. Aqui normalmente começam a surgir várias indagações com relação à customização da aplicação, como por exemplo: 1. Como está definida a segurança? Que usuário utilizo? 2. E se minha aplicação dispensa autenticação (como partes de um serviço de ecommerce), como evito a página de autenticação? E se ela mistura trechos restritos e outros de acesso livre? 3. Como incluir meu Web-Design, logotipo, etc.? Não iremos responder aos itens 2 e 3 no presente capítulo, mas faremos uma breve introdução sobre o item 1, para compreendermos o que vem pré-configurado do ponto de vista da aplicação e Application Server/Contêiner. o Configuração de restrição de segurança padrão Java EE no projeto: Os templates INI já vêm com opções de segurança pré-configuradas no padrão Java EE, declaradas no arquivo web.xml. Basicamente, há uma restrição definida para a página inicial da aplicação que permite acesso somente para usuários com papel (role) Membros. Este é um papel comumente adotado no jcompany para representar Qualquer usuário que possua um login/senha. Para mais informações sobre como configurar uma segurança padrão Java EE no arquivo web.xml, pode-se consultar documentação de tutorial da Oracle no hiperlink: (capitulo 32: Security) o Configuração de Realm em memória no Tomcat: Segundo esta mesma especificação, deve-se definir um Realm no Application Server, que por sua vez definirá a estratégia e a base de armazenamento para Usuários, Senhas e Papéis. Um Realm pode definir o uso de um sistema de

36 Implementando o Padrão "Manter Classe" autenticação de rede, LDAP/Active Directory, ou até de uma base em SGBD-R e/ou Mainframe. Para casos mais complexos, eventualmente, pode-se ter que programar um módulo de login, utilizando para isso o padrão JAAS (Java Authentication and Authorization Service). A forma de configurar um Realm é dependente do Application Server. Para mais informações sobre como configurar um Realm no Tomcat 6.x pode-se consultar o seguinte hiperlink no Web-Site do produto: Resumidamente, para nosso caso, o jcompany traz um Memory Realm do Tomcat, configurado com um usuário para testes, com login admin e senha senha. Este usuário possui os papéis Membros e também AreaTecnica, utilizados em algumas restrições de segurança padrões do jcompany (como acesso ao item de menu Área de TI, que conheceremos). Além disso, este usuário vem com os papéis padrões de administração do Tomcat, manager e admin. Esta configuração pode ser encontrada no arquivo [tomcat]\conf\tomcat-users.xml (Iremos modificá-la, nos próximos tutoriais). o Página XHTML contendo formulário para login padrão. Com esta arquitetura, o Application Server será capaz de realizar a autenticação a partir de um formulário de login que siga também um padrão Java EE, como também é o nosso caso. Sem entrar em maiores detalhes, por hora, vamos prosseguir, nos autenticando com o usuário admin e a senha senha. Entendendo a Aplicação Gerada Neste tópico, vamos conhecer um exemplo de aplicação na forma como vem organizada em templates INI. Em uma aplicação real, certamente realizaríamos ajustes nestes templates para customizar leiautes e pele (look-and-feel) e até mesmo comportamentos de interação para atender a padrões de usabilidade e ergonomia específicos de cada empresa/aplicação. Iremos discutir como fazemos esta customização no módulo D. Por hora, vamos nos concentrar na parte funcional da aplicação e recursos genéricos de usabilidade/ergonomia que o jcompany disponibiliza de forma pronta para uso. - Leiaute Geral O esquema de leiaute padrão está representado na Figura B6.38. Figura B6.38. Página principal com leiaute e apresentação básicos. #1. Topo contendo nome da empresa, título do formulário corrente e sigla da aplicação. O título central muda conforme cada formulário e documento vai sendo editado. #2. Barra de menu Pull-Down, utilizada no leiaute sistema, com várias opções sugeridas como padrão.

37 Capítulo B6 #3. Barra de botões de quiosque, sugerida para destacar funções importantes do negócio (opções de Caso de Uso mais acessadas). #4. Área informativa sugerida, devendo ser editada para conter informações globais de operação da aplicação. #5. Área customizável da barra de rodapé, contendo nome completo da empresa e da aplicação, bem como informações de copyright e de controle da aplicação. #6. Área de cabeçalho gerida pelo jcompany, sugerida como padrão com diversas opções de utilitários. Todas estas áreas podem ser personalizadas, tanto de modo global sobrepondo-se os leiautes genéricos, quanto de modo específico para um formulário, nos arquivos "<caso de uso>layout.xhtml" (como uftablayout.xhtml). Para tanto, será preciso editar XHTMLs que servem de leiaute no padrão Facelets e/ou especializar XHTMLs de componentes (açoes, mensagens) de leiaute genéricos do jcompany. - Personalização de Pele Caso as cores apresentadas na página principal da Figura B6.39 não coincidam com as cores de sua aplicação, não se preocupe: a parte decorativa da aplicação é realizada em peles que podem inclusive ser escolhidas de uma palheta e modificadas para o gosto de cada usuário. Vamos selecionar a pele preto e branco, clicando no menu Prefs/Language -> Personalizar Pele (ou através da opção do utilitário). Experimente variar a seleção por várias peles e, ao final, mantenha a pele de sua preferência neste livro, iremos utilizar principalmente a pele Preto e Branco até o módulo D, quando aplicaremos um Web-Design próprio. Figura B6.39. Seleção da pele Preto e Branco. Lembre-se de clicar em Gravar para confirmação.

38 Implementando o Padrão "Manter Classe" - Personalização de Leiaute Assim como no caso da pele, o próprio leiaute mais abrangente da aplicação pode ser personalizado ao gosto e necessidade de cada usuário, ficando ambos salvos em cookies, o que não causa sobrecarga na aplicação. Para personalizar o leiaute, acesse a opção Prefs/Language -> Personalizar Leiaute (o uso de Layout ou Leiaute pode ser escolhido e modificado no arquivo de mensagens ApplicationResources.properties ). - Personalização de Formulário Normalmente, formulários de entrada de dados são apresentados na seção de corpo (centro) do leiaute principal seção que costuma ser a única a variar em conformidade com a implementação de cada Caso de Uso. Podemos ver um formulário em ação (o que produzimos) via opção Menu Inicial -> Manter UF *, e clicando em "Novo". Com a opção de customização de formulários que podemos acessar via opção Prefs/Language -> Personalizar Formulário, conseguimos alterar a barra de ações (botões) para serem apresentados somente como ícones ou somente com o texto (o default é ambos). Figura B6.40. Formulário com barra de botões "somente com texto". - Gerando Esquema Relacional (DDL) - Geração de DDL I Para conseguirmos operar nosso Caso de Uso inicial, precisaremos criar o esquema relacional no nosso SGBD Apache Derby, que atualmente possui apenas um banco de dados com nome bancolocal, totalmente vazio. Este esquema é definido em linguagem padrão conhecida como DDL (Data Definition Language). Felizmente, o jcompany traz algumas opções de menu abaixo de Área de TI, especialmente disponíveis para usuários com papel (role) AreaTecnica e uma delas irá nos apoiar em gerar DDLs automaticamente a partir do mapeamento Objeto-Relacional da aplicação. 1. Acesse a opção Área de TI -> Esquema DDL Geração e selecione Atualização no combo com rótulo Tipo de Esquema. 2. Clique, em seguida, em Gerar Esquema. O jcompany, através de reúso e especializações em utilitários Hibernate, irá sugerir um esquema DDL, necessário para sincronizar o mapeamento atual da aplicação com o esquema atual do SGBD. Em nosso estágio, isso significa criar a tabela UF e, eventualmente dependendo do SGBD-R e de sua versão, também tabelas auxiliares que utilizadas para geração automática de identificadores. * O formulário se abrirá com mensagens de erro porque não temos ainda tabelas para que funcione adequadamente. Se clicarmos no botão Novo iremos criar linhas de entrada que nos permitirão ver o seu leiaute interno. Em Oracle ou versões novas do Derby, por exemplo, esta segunda tabela não é necessária, sendo utilizados Sequences ou outros esquemas internos como padrão, para geração de Object-Id.

39 Capítulo B6 Figura B6.41. Utilitário para geração de DDL. Obtenção do esquema relacional a partir do mapeamento O-R. #1. Opções para geração do esquema DDL de Criação (independente da existência ou não de estruturas), Atualização (criação ou alteração de esquemas, apenas se necessário e em função de análise do esquema atual no SGBD) ou Exclusão (geração do esquema para exclusão de todas as estruturas existentes). #2. Tipos de estruturas relacionais analisadas/geradas. #3. Opções complementares para quando se utiliza owner ou para trocar delimitador padrão. #4. O esquema pode ser gerado com o comando Gerar Esquema. Importante: Este botão não executa o esquema apenas o gera no campo 5, para conferência e edição! #5. Campo que contém a DDL gerada. Pode ser editado antes de submetido. Pode-se também cortar seu conteúdo e colar para envio a um DBA para organizações que não deem permissão de criação de esquemas DDL em SGBDs de desenvolvimento. A DDL para criação de tabela auxiliar pode não ser gerada, caso a versão do SGBD dispensar. #6. O botão Executar Esquema é o que submete o esquema efetivamente ao SGBD. Neste caso, a submissão irá funcionar porque o usuário pré-configurado no pool de conexões do Tomcat (DBCP) tem privilégios de administrador do Apache Derby (usuário: APP, senha: APP) e, portanto, é autorizado a submeter DDLs. 3. Clique em Executar Esquema para submeter a DDL gerada e, em seguida, confira se não há nada mais a sincronizar (mera confirmação), clicando novamente em Gerar Esquema. Desta vez, nada deverá ser gerado, já que o mapeamento Objeto-Relacional estará síncrono com o esquema do banco de dados. Figura B6.42. Conferência de Atualização de esquema. Após a execução, nada mais é gerado. - Ergonomia de Formulário Padrão para Manter Classe Podemos agora iniciar uma operação típica em nosso primeiro Caso de Uso, Manter UF. 1. Clique no item de menu Menu Inicial -> Manter UF. O formulário se abrirá na parte central de nosso leiaute, agora apresentando linhas em branco para preenchimento, como na

40 Implementando o Padrão "Manter Classe" Figura B6.43. Clicando mais vezes no botão F7-Novo, abrem-se mais linhas para preenchimento. Figura B6.43. Formulário para preenchimento, após clique por alguns vezes no botão 'Novo'. Linhas com nomes não preenchidos serão desprezadas, para conforto do usuário que não precisa se preocupar em excluí-las antes de transmitir. 2. Preencha então o formulário, inclusive saltando algumas linhas, como na figura B6.50.

41 Capítulo B6 Figura B6.44. Preenchimento com linhas desprezadas. 3. Clique em Gravar (ou aperte ctrl+shift+g, no padrão "gmail"). Em uma única submissão à rede e transação do Application Server e SGBD-R, todos os registros (objetos) serão gravados e uma mensagem Registro gravado com sucesso, em azul, será exibida. Figura B6.45. Todos os objetos persistidos em uma única requisição HTTP e transação de SGBD. 4. Apenas para compreensao, realize as duas alterações, a inclusão e a exclusão exemplificados abaixo, e clique novamente em Gravar. Figura B6.46. Uma inserção, uma exclusão e duas alterações realizadas em uma única transmissão! Note que, em uma eventual manutenção, a produtividade de operação da interface desnormalizada, proposta para o formulário, se preserva. É possível excluir, alterar e incluir objetos simultaneamente em uma única transmissão na rede e transação de SGBD-R, de forma bastante produtiva também do ponto de vista de usabilidade! 5. Após o teste da figura B6.52, retorne os nomes dos estados para valores válidos (retirando sufixos 2 ) e grave-os novamente. E se desejarmos imprimir uma relação de UFs? Uma cópia da tela não seria apropriada para uso impresso. Poderíamos até tentar cortar somente a parte do formulário, mas as colunas de marcação de exclusão e marcas de campo obrigatório normalmente são também indesejáveis em um formato de consulta. Antes de pensarmos em fazer um novo Caso de Uso, somente para isso, podemos reutilizar alguns recursos do jcompany. 6. Clique no botão Vis. Documento. Esta opção retira do formulário as opções de aplicação, deixandoo somente com campos do documento de negócio, adequados para impressão.

42 Implementando o Padrão "Manter Classe" Figura B6.47. Formulário sem coluna de exclusão e campos como texto 7. Em seguida, clique no ícone da impressora. Figura B6.48. Leiaute apropriado para impressão. Conseguimos obter um leiaute bastante razoável para impressão, inclusive com campos de entrada substituídos por textos simples de forma dinâmica (DHTML), conforme exibido na figura B6.44. O topo do leiaute de impressão pode ser customizado genericamente, para conter logotipo e formatação específicos, de cada empresa, sobrepondo-se o arquivo "src/main/webapp/fcls/geralimpressao.xhtml". Dica: Você pode clicar no título do formulário no leiaute de impressão, para substituir o texto padrão, antes de imprimi-lo!