V 1.0 Projeto DPES-FNDE 21/03/2007
Índice 1 HISTÓRICO DE ATUALIZAÇÃO...4 2 APRESENTAÇÃO...5 3 VISÃO GERAL...6 4 <<FACADE>> E <<FACTORY>>...7 5 DIAGRAMA DE SEQÜÊNCIAS E <<TELA>>... 10 6 ETAPAS DE ANÁLISE E PROJETO... 11 6.1 AVALIAR A VIABILIDADE... 11 6.1.1 Casos de Uso... 11 6.1.2 Requisitos... 11 6.1.3 Protótipos... 12 6.2 ELABORAR DIAGRAMAS DE CLASSES PRELIMINARES... 12 6.2.1 Identificar as classes de negócio envolvidas, através da elaboração de diagramas de classes das entidades que irão compor o negócio... 13 6.2.2 Identificar atributos e relacionamentos das classes envolvidas... 13 6.2.3 Identificar os métodos necessários para realização dos cenários dos Casos de Uso, através da elaboração de diagramas de classes das classes que irão operacionalizar as funcionalidades do sistema.... 13 6.2.4 Elaborar os diagramas de dados com base nos diagramas de classes das entidades que irão compor o negócio.... 13 6.3 VALIDAR CONFORMIDADE COM A ARQUITETURA DE REFERÊNCIA... 13 6.3.1 Validar os diagramas de classes preliminares... 13 6.4 VALIDAR CONFORMIDADE COM O ADMINISTRADOR DE DADOS... 13 6.4.1 Validar os diagramas dados com o Administrador de dados, pois qualquer alteração nesses diagramas pode significar uma alteração no diagrama de classes com as entidades do negócio e será com base nesses diagramas que serão feitos os Mapeamentos Objeto Relacional. 13 6.5 ELABORAR DIAGRAMA DE CLASSES A NÍVEL DE PROJETO... 13 7 CRIAÇÃO DE UM PROJETO DE MODELAGEM DE DADOS NO TOGETHER 2006 14 7.1 CRIAÇÃO DE UM DIAGRAMA DE DADOS NO TOGETHER 2006... 18 8 RASTREANDO UM REQUISITO A UM DIAGRAMA... 18 ANEXO I- VERIFICAÇÃO DE CONFORMIDADE COM ARQUITETURA DE REFERÊNCIA 21 1 APRESENTAÇÃO... 21 2 PRÉ-REQUISITOS... 21 3 REFERÊNCIAS... 21 4 RESPONSÁVEL... 21 5 DESCRIÇÃO DO PROCEDIMENTO... 21 6 RESULTADOS... 22 ANEXO II- MAPEAMENTO O/R... 24 1 APRESENTAÇÃO... 24 2 INTRODUÇÃO AO XDOCLET... 24 3 USO DO ANT... 26 3.1 EXECUÇÃO... 26 4 IMPLEMENTANDO O MAPEAMENTO OR... 26 4.1 CLASSE/ENTIDADE... 27 2
4.1.1 Representação no modelo de classes:... 27 4.1.2 Exemplo de código mapeado:... 27 4.1.3 Exemplo ER:... 27 4.1.4 Observações:... 27 4.1.5 Identificador... 27 4.1.6 Associação muitos-para-um... 28 4.1.7 Relacionamento um-para-um... 29 4.1.8 Componente... 29 4.1.9 Subclasse... 31 4.1.10 Descriminador... 31 4.1.11 Subclasse joined... 32 4.1.12 Collections (Set, List e Bag)... 32 4.1.13 Map... 33 4.1.14 Relacionamento um-para-muitos... 34 4.1.15 Relacionamento muitos-para-muitos... 34 5 FERRAMENTAS DO HIBERNATE... 35 6 REFERÊNCIAS... 36 7 OBJETIVO... 36 8 PRÉ-REQUISITOS... 36 9 REFERÊNCIAS... 36 10 RESPONSÁVEL... 36 11 DESCRIÇÃO DO PROCEDIMENTO... 36 ANEXO III- UTILIZANDO O ANT NO JBUILDER/TOGETHER... 38 1 ACESSANDO O ANT VIEW... 38 2 CONHECENDO O ANT VIEW... 39 3
1 Histórico de Atualização Data Atividade Autor Versão 28/02/2007 Criação do documento André Sousa (Borland) 1.0 05/03/2007 Criação do documento Pedro Garcia (Borland) 1.0 21/03/2007 Revisão do documento Pedro Garcia (Borland) 1.0 01/06/2007 Alteração do documento Pedro Garcia (Borland) 1.0 4
2 Apresentação O objetivo geral da disciplina de projeto é transformar os requisitos funcionais e requisitos não funcionais, descritos pelos casos de uso, em uma especificação que descreva como construir o sistema. Os resultados obtidos através da análise preliminar dos requisitos são adaptados para as restrições impostas pelos requisitos não funcionais e pelo ambiente de implementação. Estas restrições se baseiam na arquitetura de referência, camadas e módulos, seguindo ou adaptando os padrões definidos. As camadas podem ser sustentadas por frameworks internos (corporativo, departamental e projeto) e externos (open-source e comercial), que suportam a construção e execução de componentes. O projeto refina a especificação realizada na análise preliminar e cobre de forma completa os requisitos mapeados, findando com a criação da rastreabilidade entre os diagramas produzidos no Together e os requisitos presentes no CaliberRM. A disciplina de projeto interage com a área de administração de dados, mais especificamente com a atividade descrita em Mapeamento O/R, onde o diagrama de dados validado ao final da analise preliminar e utilizado como fonte de dados para o mapeamento dos objetos criados no diagrama de classes das entidades persistentes. Os artefatos gerados ou alterados na execução do fluxo da disciplina projeto formam a base para execução do fluxo da disciplina de construção, da iteração correspondente. Estas diretrizes orientam a execução destas atividades, indicando as melhores práticas. O projeto evolui o modelo de análise, aplicando as estruturas, regras e padrões da arquitetura candidata, ou seja, refinando-o. Os artefatos gerados na atividade de análise de comportamento são agora traduzidos em um modelo que será a base para as atividades da disciplina de Construção. Nesse momento deverão ser definidas as interfaces de acesso aos futuros componentes e também as classes de criação destas interfaces. Especificamente: as interfaces facade e classes factory. Serão pelo menos dois os estereótipos utilizados pela equipe de projetos: <<Factory>> <<Facade>> O modelo gerado pela atividade de análise representa as grandes entidades do sistema e agora estas entidades serão agrupadas em torno de funcionalidades específicas com o intuito de prover os meios de acesso ao sistema sem ter que se preocupar com a implementação destas classes ou componentes. Nesta etapa, também poderão ser gerados os diagramas de seqüência e outros diagramas que tornem mais fácil o trabalho da equipe de construção. 5
3 Visão Geral Os diagramas de projeto são uma ferramenta importante para a comunicação e visualização da estrutura do sistema. Deve-se lembrar que projeto não é a tarefa de criação de diagramas, mas atividade de determinar as soluções relevantes para o projeto. Os diagramas devem então trazer as informações em nível necessário para a disciplina de construção e não se sobrecarregarem com informações excessivas ou níveis de detalhes muito baixos. Os diagramas de classes devem ser organizados de forma a descobrir as estruturas de dados e distribuição de responsabilidades. O nível de detalhamento do diagrama de projeto varia de acordo com a necessidade de informação necessária para cobrir todos os mecanismos de projeto relevantes ou característicos da aplicação. A utilização de diagramas de seqüência e/ou colaboração durante o projeto é importante para a distribuição dos métodos entre os elementos, estes, porém, devem considerar que: o Os diagramas não são a forma de indicar o fluxo de execução, esta prática leva a dependência temporal e baixo reuso. A implementação não deve seguir a estruturação de casos de uso, mas deve procurar o mecanismo mais adequado para reuso e projeto flexível. o O Excesso de diagramas de seqüência deixa o projeto lento e incompreensível. Este recurso deve ser usado somente para elucidar situações complexas e não exaustivamente, sobre pena de ser ignorado na implementação e gerar excesso de trabalho nas atividades de projeto, ocultando as decisões realmente relevantes de projeto. A equipe de projetos inicia esta etapa do processo com o diagrama de classes em cores; até o presente momento este diagrama de classes é bem próximo de um modelo de entidades e relacionamentos. É papel do projetista, expor este modelo de um modo mais elegante e que possa ser reutilizado no futuro por outros sistemas. Serão duas as principais atividades desta etapa: Finalização dos diagramas de classes Geração das Facades e Factories ; Geração dos diagramas de seqüência. Mas como exatamente isto será útil para a equipe de construção? Até o momento não foi informado nenhum detalhe especifico da implementação e como se sabe, alguns detalhes são fundamentais para que a implementação aconteça. O mecanismo básico de comunicação entre as equipes deverão ser os estereótipos e, para descrever tais estereótipos, o processo disponibiliza um catálogo (ver Catálogo de Estereótipos no Guia de Análise de projetos). Além disso, é ainda mais importante, existirem documentos com a realização dos estereótipos definidos no catálogo para cada uma das arquiteturas dominadas que são descritas nos site de arquitetura (ver http://arqui.fnde.gov.br). Os documentos de arquitetura descrevem como os estereótipos devem ser realizados em determinada arquitetura. Por exemplo, nestes documentos estarão claramente definidos COMO um estereótipo <<Tela>> é implementado no Struts e como um <<Moment-Interval>> é feito utilizando-se o Hibernate. 6
Deste modo, foi possível definir uma linha bem clara entre onde se inicia cada etapa e termina a outra sem que houvesse conflito de interesses. Caso você seja um projetista, saberá exatamente o que tem que fazer: projetar as interfaces facade e classes factory e gerar os diagramas de seqüência. Se você for um desenvolvedor, receberá os diagramas com os estereótipos definidos e, com o auxílio do documento de arquitetura correto, conseguirá também resolver todos os detalhes. Uma vez que as facade e factory estejam concluídos, será necessário gerar os diagramas de seqüência. 4 <<Facade>> e <<Factory>> As interfaces facade serão os principais pontos de acesso ao sistema. Todos os diagramas de seqüência serão gerados com referencia às facades. Ver todos os detalhes de uma facade no Catálogo de Estereótipos no Guia de Análise de projetos. Nela também serão criadas as rastreabilidades com os casos de uso implementados em cada uma de suas operações (Métodos). Estas interfaces deverão ter os contratos muito bem definidos; por contrato muito bem definido entende-se: TODOS os tipos de entrada estão definidos; TODOS os tipos de saída estão definidos; Caso exista um método de acesso getpessoa, o mesmo deveria ter o seguinte formato: Pessoa getpessoa(integer idpessoa)e NÃO Object getdeputado(object pessoa) No exemplo acima, a interface definiu claramente os tipos de dados que entram e saem do método. Com isto a equipe de construção saberá claramente quais objetos precisam ser montados para o retorno do método. Tente não utilizar tipos muito abstratos como Object, Iterator, etc... E nos caso onde não for possível especificar um tipo que não seja abstrato como uma Collection, por exemplo, utilize o Javadoc para informar o tipo que esta sendo retornado. Mas como identificar quais e como serão os seus facades? Não é uma pergunta muito fácil de ser respondida; depende basicamente de certo conhecimento do negócio para entender o que precisa ser exportado e compartilhado entre os sistemas. Desta necessidade, poderá surgir outro estereótipo, o <<DTO>>, que é um objeto para a transferência de dados entre as camadas. Muitas vezes, o próprio objeto real indicado por um dos quatro arquétipos (<<Descritption>>, <<Party/Place/Thing>>, <<Role>>, <<Moment-Interval>>) poderá ser o próprio DTO; contudo, algumas vezes será interessante aglutinar um conjunto de dados em uma casquinha que englobe diversos outros objetos. Neste caso, será criado um <<DTO>> adicional com esta finalidade, como mostra o exemplo abaixo. Muitas vezes um DTO, para facilitar o seu uso, terá métodos de acesso, ou seja, getters, para que não seja necessário acessar diretamente os objetos nele encapsulados. As facades não deverão ser modificadas indiscriminadamente por qualquer membro da equipe, assim sendo, devem ser consideradas READONLY deste ponto 7
em diante. Dessa forma, uma vez que o projetista definir claramente o conjunto de funcionalidades de uma facade, ela não deverá ser alterada e caso exista a necessidade de uma correção, o projetista deverá ser informado e providenciar a alteração. O fato de centralizar a manutenção da facade no projetista se da pela necessidade de manter a rastreabilidade com os requisitos. Mas, se a facade é apenas uma interface como será sua realização? Qual será a classe ou ainda quais serão as classes que realizam esta interface? Neste momento, não é papel do projetista definir isto. Estes detalhes, que são específicos de implementação, estarão descritos no documento de arquitetura e é papel da equipe de construção se preocupar com isto. Entretanto, é papel do projetista criar as classes factory para as interfaces. Estas fábricas serão responsáveis pela criação da classe ou classes concretas responsáveis pela realização da interface. O projetista criará uma classe com métodos bem definidos e com o retorno do tipo da facade. Suponha um sistema que controle estoque de itens produzidos que serão futuramente vendidos (o diagrama abaixo veio da etapa de Análise): O projetista, ao receber este diagrama, imagina que seria interessante criar uma facade para os itens de Catálogo, Venda e Estoque. E resolve criar um DTO para encapsular esta funcionalidade. 8
No exemplo acima, o diagrama de análise foi evoluído, veja as vantagens da UML em cores e da abordagem de Facade e Factory: Quem está acessando este componente não tem ciência de como será implementado os métodos descritos na interface; se amanhã for completamente alterado, os dependentes não serão afetados; A UML em cores força a granularidade do modelo de classes de tal sorte que você possa reutilizar os seus pequenos pedaços no futuro. No exemplo acima, caso um item de estoque tenha que ser transferido para uma outra filial, bastaria termos outro Moment-Interval para tratar a transferência, mas a facade poderia ser reutilizada sem problemas; de algum modo a UML em cores lembra à 3FN (Terceira Forma Normal do Modelo Relacional); A criação da interface foi delegada para a factory. O projetista sabe que poderá confiar nesta classe para acesso a sua interface e que isso pode ser reutilizado no futuro por outros sistemas, pois bastará o uso da factory para garantir o reuso. Se isso será implementado através de SessionBeans, WebService ou qualquer outra tecnologia, não é relevante neste momento (lembre-se que o documento de arquitetura terá todos estes detalhes muito bem definidos). A rastreabilidade dos Casos de Uso também serão feitas através das facades. Deverá(ão) ser ligado o(s) Caso(s) de Uso realizado(s) por aquela interface, dessa forma cada método da facade estará ligado a pelo menos um caso de uso. 9
5 Diagrama de Seqüências e <<Tela>> Os diagramas de seqüência deverão ser gerados sempre que necessários para os Casos de Uso cuja complexidade seja alta e eles terão um formato parecido com o seguinte diagrama: O objeto tela, com o estereótipo <<tela>> representa toda a parte visual. Na implementação MVC, representaria o VC. Os outros dois objetos factory e facade são instancias de um factory e de uma facade respectivamente. Algumas interações podem ser mais complexas e incluir 3 instâncias de cada um destes objetos (por exemplo). 10
6 Etapas de Análise e Projeto A seguir estão descritas as atividades ilustradas no Guia de Análise de projeto. 6.1 Avaliar a viabilidade É essencial avaliar o projeto antes de firmar qualquer comprometimento. Para isso é necessário avaliar os seguintes artefatos de entrada: 6.1.1 Casos de Uso Devem ser utilizados para avaliar o tamanho do projeto. 6.1.2 Requisitos Devem ser utilizados para avaliar a complexidade da proposta. 11
6.1.3 Protótipos Devem ser utilizado para auxiliar na avaliação da complexidade do projeto. 6.2 Elaborar Diagramas de Classes preliminares Antes de iniciar o projeto propriamente dito é essencial identificar as operações e entidades envolvidas através da analise dos artefatos descritos acima e 12
com a validação de conformidades com a arquitetura e com o administrador de dados. 6.2.1 Identificar as classes de negócio envolvidas, através da elaboração de diagramas de classes das entidades que irão compor o negócio. Devem ser identificadas as principais classes do sistema e seus respectivos estereótipos. Nesse ponto deve ser utilizada a UML em Cores para destacar os estereótipos aplicados em cada entidade. 6.2.2 Identificar atributos e relacionamentos das classes envolvidas Deverão ser identificados os principais atributos e o relacionamento entre as classes, principalmente as que representam entidades. 6.2.3 Identificar os métodos necessários para realização dos cenários dos Casos de Uso, através da elaboração de diagramas de classes das classes que irão operacionalizar as funcionalidades do sistema. Deverão ser identificados todos os métodos de negocio das facades. 6.2.4 Elaborar os diagramas de dados com base nos diagramas de classes das entidades que irão compor o negócio. 6.3 Validar conformidade com a Arquitetura de Referência 6.3.1 Validar os diagramas de classes preliminares Deverão ser validados os diagramas com a arquitetura. Nesse ponto é muito importante identificar pontos nos diagramas que possam causar gargalos durante a construção, ou seja, os métodos de negócio e as entidades devem possuir uma estrutura que facilite a sua utilização e não exija da construção a implementação de estruturas de apoio desnecessárias ao sistema. 6.3.1.1 Persistência Validar as entidades de negócio e seus relacionamentos com o administrador de dados e verificar se elas se encontram na forma mais otimizada para o banco e para o framework de persistência adotado. 6.3.1.2 Divisão correta das camadas Validar se os artefatos estão de acordo com a divisão das camadas adotadas pelo FNDE. 6.4 Validar conformidade com o Administrador de Dados 6.4.1 Validar os diagramas dados com o Administrador de dados, pois qualquer alteração nesses diagramas pode significar uma alteração no diagrama de classes com as entidades do negócio e será com base nesses diagramas que serão feitos os Mapeamentos Objeto Relacional. 6.5 Elaborar Diagrama de Classes a nível de projeto Nesse ponto os diagramas de classes preliminares deverão ser encaixados na estrutura existente, ou seja, deverão ser verificados quais sistemas existentes 13
serão utilizados para implementação do novo sistema e quais entidades já existem e como serão utilizadas. Além disso, será necessário mapear as entidades utilizando o Mapeamento Objeto Relacional e criar os JUnits para realização, no futuro, de testes unitários. Deverão ser atribuídos às operações de negócio, objetos de entrada e retorno, ou seja, nesse momento serão criados os DTOs e outros estereótipos utilizados para a troca de informações entre as camadas do sistema. Concluída as alterações nos diagramas estes devem ser rastreados através do Together com os requisitos presentes no CaliberRM. Depois de finalizar esta fase o projeto deverá seguir para a fase de construção. 7 Criação de um Projeto de Modelagem de dados no Together 2006 Para criar um novo projeto no Together, siga os passos abaixo: 1. No menu File New Project; 14
2. Selecione a opção Data Modeling Project 15
3. Informe o nome e o local onde o projeto será criado; 16
4. Informe o SGBD e o nome do schema que será criado e clique em Finish; 17
7.1 Criação de um diagrama de dados no Together 2006 Para criar um diagrama de dados no Together 2006 siga os passos a seguir: 1. Com o segundo botão do mouse selecione New Diagram ER Physical Diagram; 2. Informe o nodo do diagrama e repare que o novo diagrama estará aberto no editor ao lado; 8 Rastreando um requisito a um diagrama Para criar a rastreabilidade entre uma operação e um requisito siga os passos a seguir: 18
1. Selecione a operação que deseja rastrear e com o segundo botão do mouse selecione Requirements Manage Traces; 2. Selecione os requisitos desejados adicionando-os com o botão Add e clique em OK; 19
20
Anexo I- Verificação de Conformidade com Arquitetura de Referência 1 Apresentação Descrever o procedimento a ser executado para se definir ou adequar à arquitetura candidata do sistema. 2 Pré-Requisitos 1. Conjunto de casos de uso homologados pelo Cliente e liberados pelo Gerente de Projetos; 2. Baseline do tipo Especificação estabelecida para a iteração. 3 Referências 1. Estrutura de Diretórios; 2. Documento de Arquitetura (http://arqui.fnde.gov.br). 4 Responsável Arquiteto. 5 Descrição do Procedimento 1. Verificar se é a primeira iteração do sistema; 2. Se o sistema está na primeira iteração: 2.1. Identifique as restrições do projeto. Exemplos de restrições são: - Sistema Operacional - Linguagem de Programação - Middleware - Sistema Gerenciador de Banco de Dados - Sistemas Legados - Padrões e Políticas Corporativos - Frameworks - Necessidades de Distribuição - Outros requisitos não funcionais (tais como performance, manutenibilidade, segurança etc) devem estar, sempre que possível, medidos quantitativamente. Exemplo: o sistema deve responder em no máximo 1s as solicitações, estar em conformidade com o padrão Java EE 1.4 e sua versão inicial deverá ser mantida por 2 anos. Estas restrições devem ser documentadas como requisitos não funcionais. 21
2.2. Identifique as experiências anteriores que serão aproveitadas: - Versões anteriores do sistema ou Arquiteturas semelhantes que foram bem-sucedidas. - Padrões de projeto que serão usados. Estas escolhas devem ser adicionadas ao documento de arquitetura. Se novos estereótipos forem definidos, devem ser adicionados ao catálogo de estereótipos. 2.3. Verifique se a arquitetura está dominada. Uma arquitetura está dominada se: 2.3.1. Todos os estereótipos do catálogo de estereótipos estão materializados no documento de arquitetura; 2.3.2. Existem casos de teste que indicam a viabilidade desta arquitetura; 2.3.3. Foi aprovada pelo arquiteto; 2.4. Informar ao Gerente do Projeto que a arquitetura candidata foi definida para o sistema; 3. Se o sistema NÃO está na primeira iteração: 3.1. Verificar, dentro do conjunto de Casos de Uso da iteração atual, se algum deles impacta ou corrompe a arquitetura definida nas iterações anteriores; 3.2. Se houver impacto: 3.2.1. Implementar e documentar as alterações imprescindíveis para adequar a arquitetura; 3.2.2. Informar ao Gerente do Projeto que a arquitetura candidata definida para o sistema foi modificada para atender às novas funcionalidades descritas pelos Casos de Uso; 4. Solicitar ao Analista de Sistemas a inserção ou atualização da descrição da arquitetura do sistema em seu Sumário Executivo contemplando, pelo menos, as seguintes informações: 4.1. Plataforma; 4.2. Linguagem de programação; 4.3. SGBD; 4.4. E os demais aspectos relevantes. 6 Resultados 1. Se o sistema está na primeira iteração: 1.1. Arquitetura do sistema definida 2. Se o sistema não está na primeira iteração: 2.1. Arquitetura do sistema modificada, se necessário; 3. Descrição geral da arquitetura do sistema inserida ou atualizada no Sumário Executivo; 22
4. Gerente do projeto informado da definição da arquitetura. 23
Anexo II- Mapeamento O/R 1 Apresentação O objetivo deste documento é mostrar como gerar o mapeamento objetorelacional para o Hibernate usando tags XDoclet e Ant. Este documento inclui como mapear cada elemento. As questões de performance, segurança e outras questões do uso do Hibernate estão fora do escopo deste documento. 2 Introdução ao XDoclet O XDoclet é uma ferramenta para se adicionar meta-informações ao código fonte, possibilitando que um componente seja desenvolvido em um único arquivo e que a partir de comentários especiais sejam gerados todos os descritores e outros arquivos necessários para implantar o componente. O uso do XDoclet se resume em duas partes fundamentais: os comentários que devem ser inseridos no código como Javadocs e tarefas do Ant que irão ler estes comentários e gerar o código necessário, conforme descrito no capítulo Uso do ANT deste documento. Por exemplo, para gerar a configuração do Hibernate e os mapeamentos necessários, usaríamos uma classe comentada como abaixo: * @hibernate.class table="cidade" public class Cidade { private Integer id; private Uf uf; private String nome; * @hibernate.id column="idecidade" * generator-class="native" * unsaved-value="0" public Integer getid() { return id; } * @hibernate.property column="nomcidade" length="80" public String getnome() { return nome; } * @hibernate.many-to-one column="ideuf" foreign-key="fkcidade_uf" * @hibernate.column name="ideuf" not-null="true" public Uf getuf() { return uf; } public void setid(integer i) { 24
} this.id = i; public void setnome(string s) { this.nome = s; } } public void setuf(uf uf) { this.uf = uf; } E um target do Ant como abaixo: <target name="xdoclet.hibernate"> <mkdir dir="${src.hibernate.home}" /> <hibernatedoclet destdir="${src.hibernate.home}"> <fileset dir="${src.java.home}" includes="**.java"/> <hibernate version="2.0" /> <hibernatecfg dialect="${hibernate.dialect}" datasource="${hibernate.datasource}" showsql="${hibernate.showsql}" /> </hibernatedoclet> </target> E o mapeamento objeto-relacional para esta classe: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping> <class name="cidade" table="cidade" dynamic-update="false" dynamic-insert="false" > <id </id> name="id" column="idecidade" type="java.lang.integer" unsaved-value="0" > <generator class="native"></generator> <property name="nome" type="java.lang.string" update="true" insert="true" access="property" column="nomcidade" length="80" /> <many-to-one name="uf" class="uf" cascade="none" 25
</class> </hibernate-mapping> outer-join="auto" update="true" insert="true" access="property" foreign-key="fkcidade_uf" > <column name="ideuf" not-null="true" /> </many-to-one> 3 Uso do ANT 3.1 Execução Apesar de possuir diversas referências ao produto, este documento não visa explicar o funcionamento do Apache Ant. Maiores detalhes sobre o seu funcionamento, além de um exemplo para criação de um script, podem ser obtidos no site do produto http://ant.apache.org. Antes de executar o Ant é necessário copiar para sua estação as bibliotecas Xdoclet, e incluir as tags necessárias, conforme explicado no capítulo Implementando o Mapeamento OR deste documento. Para executar o Ant, basta entrar no prompt de comando, navegar até o diretório do projeto e invocar o ant passando como parâmetro o nome do target (alvo) a ser executado, como abaixo: ant xdoclet Ou utilizando o Ant View da IDE. Isso irá gerar todos os mapeamentos do Hibernate através da tarefa xdoclet. O alvo xdoclet deve estar definido no arquivo build.xml, criado pela Unidade de Construção, e deve, direta ou indiretamente, disparar a tarefa xdoclet.modules.hibernate.hibernatedoclettask. 4 Implementando o Mapeamento OR Para mostrar como produzir o mapeamento objeto-relacional, abordaremos cada elemento do diagrama de classes e mostraremos como ele pode ser mapeado usando o plug-in do XDoclet para Hibernate, além de alguns outros elementos que devem complementar o mapeamento. 26
4.1 Classe/Entidade 4.1.1 Representação no modelo de classes: Classe1 4.1.2 Exemplo de código mapeado: * * @hibernate.class table= "TB_CLASSE1" * public class Classe1 {...} 4.1.3 Exemplo ER: TB_CLASSE1 4.1.4 Observações: Toda classe deve possuir um identificador mapeado. 4.1.5 Identificador 4.1.5.1 Representação no modelo de classes: Classe1 -chave:int -getchave:int -setchave:void 4.1.5.2 Exemplo de código mapeado: * @hibernate.id generator-class="native" unsaved-value="0" column="chave1" public int getchave() { return chave; 27
} 4.1.5.3 Exemplo ER: TB_CLASSE1 chave1 4.1.5.4 Observações: O parâmetro generator-class é obrigatório e indica como devem ser geradas as chaves. Os valores possíveis são: uuid.hex, uuid.string, increment,assigned, native, identity, sequence, hilo, seqhilo e foreign. Uma listagem com a descrição dos geradores suportados pode ser encontrada na documentação oficial do Hibernate [HBM], capítulo 5.1.4, onde também podem ser encontrados os parâmetros opcionais ou requeridos por cada gerador. 4.1.6 Associação muitos-para-um Essas associações são extremamente desaconselhadas pela equipe de arquitetura. 4.1.6.1 Representação no modelo de classes: Classe4 Classe3 -lnkclasse3:classe3 0..* 0..1 -getlnkclasse3:classe3 -setlnkclasse3:void 4.1.6.2 Exemplo de código mapeado: *@hibernate.many-to-one column="idclass3" foreign-key= FK_IDCLASS3 public Classe3 getlnkclasse3() { return lnkclasse3; } 4.1.6.3 Exemplo ER: TB_CLASSE4 somerelation TB_CLASSE3 28
4.1.7 Relacionamento um-para-um 4.1.7.1 Representação no modelo de classes: Classe3 Classe5 -lnkclasse5:classe5 0..1 0..1 -getlnkclasse5:classe5 -setlnkclasse5:void 4.1.7.2 Exemplo de código mapeado: * @hibernate.one-to-one public Classe5 getlnkclasse5() { return lnkclasse5; } 4.1.7.3 Exemplo ER: TB_CLASSE3 Z somerelation TB_CLASSE5 4.1.7.4 Observações: Existem duas maneiras de se criar um relacionamento um-para-um usando Hibernate. A primeira é ter um relacionamento um-para-muitos com uma restrição unique. Comumente, o mapeamento indica isso usando o atributo unique= true da associação one-to-many. A segunda opção é compartilhar uma chave primária. Nesse caso, o mapeamento de cada classe deve conter o mapeamento one-to-one, em uma delas com o atributo constrained= true e com o gerador de chaves foreign para o identificador. Mais informações sobre os relacionamentos um-para-um podem ser encontradas na documentação oficial do Hibernate [HBM], capítulo 5.1.11. 4.1.8 Componente 4.1.8.1 Representação no modelo de classes: Pessoa -chave:int -nome:string -Aniversario:Data 1 1 Data -dia:int -mes:int -ano:int 4.1.8.2 Exemplo de código mapeado: 29
*@hibernate.class table="tb_pessoa" public class Pessoa { private Data Aniversario; } * @hibernate.component prefix= nasc_ public Data getaniversario() { return Aniversario; } public class Data { private int dia; private int mes; private int ano; * @hibernate.property public int getdia() { return dia; } * @hibernate.property public int getmes() { return mes; } } * @hibernate.property public int getano() { return ano; } 4.1.8.3 Exemplo ER: TB_PESSOA chave nome nasc_dia nasc_mes nasc_ano 4.1.8.4 Observações: Os componentes também podem ser dinâmicos usando um map, fazer parte de um identificador ou serem uma coleção de objetos dependentes. Para os casos mais específicos de componentes, as opções da tag do XDoclet não são suficientes e o mapeamento deve ser feito manualmente para o componente, como indicado na documentação oficial do Hibernate [HBM], capítulo 7. 30
4.1.9 Subclasse 4.1.9.1 Representação no modelo de classes: Pessoa -chave:int -nome:string PessoaFisica -cpf:string 4.1.9.2 Exemplo de código mapeado: * @hibernate.subclass discriminator-value="f" public class PessoaFisica extends Pessoa {...} 4.1.9.3 Exemplo ER: TB_PESSOA chave nome tipo cpf 4.1.9.4 Observações: Nas linhas onde a coluna tipo indicar um tipo diferente de PessoaFisica, o valor da coluna cpf será null. A coluna tipo é um descriminador, e pode ser mapeado como abaixo. O Valor que a coluna irá assumir para cada classe pode ser definido através do atributo discriminator-value da tag hibernate.subclass, sendo que o valor padrão é o nome qualificado da classe. 4.1.10 Descriminador 4.1.10.1 Representação no modelo de classes: Não há. 4.1.10.2 Exemplo de código mapeado: * @hibernate.class table="tb_pessoa" * @hibernate.discriminator column="tipo" public class Pessoa {...} 4.1.10.3 Exemplo ER: TB_PESSOA chave nome tipo cpf 31
4.1.10.4 Observações: Apesar de ser simples, esta opção pode deixar de ser performaticamente vantajosa se a árvore de herança for muito grande, devido à grande quantidade de buracos na tabela. Nestes casos, pode ser melhor utilizar uma subclasse joined, com cada classe em uma tabela separada. 4.1.11 Subclasse joined 4.1.11.1 Representação no modelo de classes: Pessoa -chave:int -nome:string PessoaJuridica -cnpj:string 4.1.11.2 Exemplo de código mapeado: * @hibernate.joined-subclass table="tb_pessoajuridica" * @hibernate.joined-subclass-key column="fk_pessoa" public class PessoaJuridica extends Pessoa {...} 4.1.11.3 Exemplo ER: TB_PESSOA chave tipo nome herda 1 TB_PESSOAJURIDICA FK_PESSOA.chave(FK) cnpj 4.1.11.4 Observações: Para árvores de herança muito pequenas ou que adicionem pouco estado, pode ser mais vantajoso usar o mapeamento subclass visto no item anterior, por ele evitar um join a custo de espaço na tabela. 4.1.12 Collections (Set, List e Bag) 4.1.12.1 Representação no modelo de classes: BilheteDeLoteria -chave:int -dataemissao:calendar -numerosmarcados:set Set de Integers... 4.1.12.2 Exemplo de código mapeado: * @hibernate.set table="bilhetes_ NUMEROS" * @hibernate.collection-key column="bilheteid" * @hibernate.collection-element column="numero" type="integer" 32
... 4.1.12.3 Exemplo ER: TB_BILHETES bilheteid. dataemissao BILHETES_NUMEROS numero bilheteid(fk) 4.1.12.4 Observações: O mapeamento de coleções deve refletir a semântica desejada e sempre deve ser feito usando as interfaces (Set ou List). Existem diversas considerações de performance e outras nuâncias que devem ser levadas em conta ao projetar os mapeamentos de coleções. Tais considerações podem ser encontradas na documentação oficial do Hibernate [HBM], capítulo 6. 4.1.13 Map 4.1.13.1 Representação no modelo de classes: Glossario -chave:int -assunto:string -conteudo:map Map de Palavras (String) para Significado (String) 4.1.13.2 Exemplo de código mapeado:... * @hibernate.map table="conteudo" * @hibernate.collection-key comlumn="glossarioid" * @hibernate.collection-index comumn="termo" * @hibernate.collection-element column="significado" type= string public Map getconteudo() { return conteudo; }... 4.1.13.3 Exemplo ER: TB_GLOSSARIO glossarioid assunto. CONTEUDO glossarioid(fk) termo significado 4.1.13.4 Observações: 33
4.1.14 Relacionamento um-para-muitos 4.1.14.1 Representação no modelo de classes: Departamento -departamentoid:int -nome:string -lnkfuncionarios:set 1 0..* Funcionario -funcionarioid:int -nome:string...... 4.1.14.2 Exemplo de código mapeado: * @hibernate.set * @hibernate.collection-key column="departamentoid" * @hibernate.collection-one-to-many class="exemplo.funcionario" public Set getlnkfuncionarios() { return lnkfuncionarios; } 4.1.14.3 Exemplo ER: TB_DEPARTAMENTO departamentoid nome. TB_FUNCIONARIO funcionarioid departamentoid(fk) nome 4.1.14.4 Observações: Note que no exemplo de código mapeado acima é necessário colocar no atributo class o pacote onde a classe Funcionario reside (pacote exemplo ). 4.1.15 Relacionamento muitos-para-muitos 4.1.15.1 Representação no modelo de classes: Grupo -GID:int -nome:string -lnkusuario:list 0..* 0..* Usuario -UID:int -nome:string -lnkrevgrupo:list... 4.1.15.2 Exemplo de código mapeado: * @hibernate.bag table="grupo_usuario" * @hibernate.collection-key column="uid" * @hibernate.collecton-many-to-many class="exemplo.grupo" column="gid" public List getlnkrevgrupo() { return lnkrevgrupo; 34
}... * @hibernate.bag inverse="true" * @hibernate.collection-key column="uid" * @hibernate.collection-many-to-many class="exemplo.usuario" column="gid" public List getlnkusuario() { return lnkusuario; }... 4.1.15.3 Exemplo ER: GRUPO GID nome many-to-many USUARIO UID nome GRUPO GID nome. GRUPO_USUARIO GID(FK) UID(FK). USUARIO UID nome 4.1.15.4 Observações: Neste exemplo, foi usado um mapeamento bidirecional. Mais opções dos mapeamentos bidirecionais podem ser encontradas na documentação oficial do Hibernate [HBM]. 5 Ferramentas do Hibernate O Hibernate inclui em sua distribuição um conjunto de ferramentas para auxiliar no desenvolvimento do mapeamento. A ferramenta SchemaExport gera o script DDL para o esquema do banco de acordo com o que foi mapeado. O uso desta ferramenta é recomendado para que não haja erros causados pela disparidade entre o banco e mapeamento. Esta tarefa é definida por uma tarefa do Ant, e pode ser invocada pelo prompt de comando, como abaixo: ant hibernate.schemaexport O alvo hibernate.schemaexport deve estar definido no arquivo build.xml e associado com a tarefa net.sf.hibernate.tool.hbm2ddl.schemaexporttask. Cabe ressaltar que a utilização do SchemaExport deve ser feita apenas uma única vez por projeto, durante a primeira iteração. 35
6 Referências Documentação oficial do Hibernate: [HBM] http://www.hibernate.org/hib_docs/reference/en/html/ Tag do XDoclet para Hibernate [XHBM] http://xdoclet.sourceforge.net/xdoclet/tags/hibernate-tags.html [XHBM2] http://xdoclet.codehaus.org/ Documentação do Ant [Ant] http://ant.apache.org/manual/index.html 7 Objetivo Descrever o procedimento a ser executado para a implementação do mapeamento objeto-relacional. 8 Pré-Requisitos 1. Modelo de Classes do projeto em cores; 2. Interfaces facade e classes factory já incluídas no Modelo de Classes do projeto. 9 Referências 1. Estrutura de Diretórios. 10 Responsável Administrador de Dados 11 Descrição do Procedimento 1. Se for a primeira iteração: 1.1. Acessar e analisar o Modelo de Classes do Projeto; 1.2. Implementar o Mapeamento Objeto-Relacional: 1.2.1. Abrir os arquivos.java que representam o Modelo de Classes; 1.2.2. Incluir os comentários em Xdoclet que irão permitir a geração dos arquivos XML do Hibernate, respeitando-se os padrões; 1.2.3. Executar o procedimento (script Ant) responsável pela geração dos arquivos XML, utilizados pelo Hibernate, a partir das classes modificadas (arquivos.java ); 1.2.4. Realizar no Banco de Dados as alterações correspondentes; 2. Se não for a primeira iteração 2.1. Acessar e analisar o Modelo de Classes do Projeto; 36
2.2. Atualizar o Modelo de Classes do projeto: 2.2.1. Abrir os arquivos.java que representam o Modelo de Classes; 2.2.2. Incluir os comentários em Xdoclet que irão permitir a geração dos arquivos XML do Hibernate; 2.2.3. Executar o procedimento (script Ant) responsável pela geração dos arquivos XML, utilizados pelo Hibernate, a partir das classes modificadas (arquivos.java ) 2.2.4. Realizar no Banco de Dados as alterações correspondentes; 37
Anexo III- Utilizando o Ant no JBuilder/Together Tanto o JBuilder quanto o Together possuem suporte ao Ant e para tirar proveito dessa incrível ferramenta vamos dar uma breve introdução sobre como tirar proveito dessa ferramenta nas IDEs. 1 Acessando o Ant View É através do Ant View que você poderá executar os targets do Ant e para acessá-lo basta acessar o menu Window>Show View>Ant como mostra a figura abaixo. 38
2 Conhecendo o Ant View A figura abaixo mostra o Ant View e a seguir estão as descrições das funções do Ant View. Ilustração 1 - Ant view Ilustração 2 - Ant view com um arquivo de build Ícone Função Adiciona um arquivo de build existente na workspace no AntView. Pesquisa por arquivos de build e os adiciona no AntView. Oculta todos os targets privados do build. Executa o target selecionado. Remove o build selecionado do Ant View. Remove todos os build do Ant View. Tabela 1 - Funções do Ant View. 39