Main

FrontPage 6.1

Clovis Lemes Ferreira Junior — Thu, 18 Jul 2013 18:58:42 GMT

<> Este é o wiki do projeto Demoiselle e centraliza várias informações importantes para usuários e desenvolvedores. O projeto Demoiselle é estruturado da seguinte forma: *[[http://demoiselle.sourceforge.net/framework/|Demoiselle Framework]]: Framework arquitetural Java EE. *[[http://demoiselle.sourceforge.net/component/|Demoiselle Component]]: Componentes baseados na arquitetura Java EE. *[[http://demoiselle.sourceforge.net/sample/|Demoiselle Sample]]: Repositório para aplicações de Exemplo com Demoiselle *[[http://demoiselle.sourceforge.net/tools/|Demoiselle Tools]]: Ferramentas para apoio ao desenvolvimento de aplicações *[[http://demoiselle.sourceforge.net/process/|Demoiselle Process]]: Consiste em um conjunto das melhores práticas e estruturas a serem adotadas no desenvolvimento e manutenção de aplicações *[[http://demoiselle.sourceforge.net/infra/|Demoiselle Infra]]: Trata questões relacionadas a instalação do ambiente de desenvolvimento. {{{ Toda contribuição é muito bem-vinda! Um simples relatório de falhas já contribui muito. }}} [[null|]] == Comunidade == *[[Comunidade|Comunidade]]: Saiba mais sobre a organização da Comunidade Demoiselle == Participação == *[[Como contribuir|Como contribuir]]: Procedimentos/orientações para quem deseja contribuir com a evolução do Demoiselle *[[Como utilizar|Como utilizar]]: Informações direcionadas ao uso do Demoiselle no desenvolvimento de soluções == Links Úteis == *[[https://novo.frameworkdemoiselle.gov.br|Portal]]: Central de acesso as informações do Demoiselle *[[https://novo.frameworkdemoiselle.gov.br/web/guest/forum|Fórum]]: Fóruns de discussão *[[http://tracker.frameworkdemoiselle.gov.br|Tracker]]: Submissão/acompanhamento de Bugs, Improvements e New Features *[[http://lists.sourceforge.net/lists/listinfo/demoiselle-users|Lista de discussão]]: Comunicação e troca de experiências entre os usuários do projeto. *[[https://novo.frameworkdemoiselle.gov.br/web/guest/blog|Blog]]: Acompanhe a evolução do Demoiselle lendo os posts *[[https://novo.frameworkdemoiselle.gov.br/aprenda|Tutoriais]]: Aprenda sobre o Demoiselle seguindo os vários módulos *[[http://twitter.com/fwkdemoiselle|Twitter]]: Acompanhe o Demoiselle no Twitter! *[[http://twitter.com/demoiselle_trac|Twitter Tracker]]: Acompanhe as novas issues do Tracker Demoiselle no Twitter!

Template de Nova Funcionalidade 1.7

Test Test — Wed, 17 Jul 2013 13:19:41 GMT

<> Toda proposta de Nova Funcionalidade para o Demoiselle deve se preenchida utilizando o template abaixo: {{{ **1.Identificação** **2.Descrição da proposta** **3.Componentes afetados pela proposta** **4.Contribuições** **5.Informações adicionais** }}} [[http://sourceforge.net/apps/mantisbt/demoiselle/view.php?id=147|#0000147]] Exemplo de Proposta de Nova Funcionalidade

Convenção desenvolvedor/Convenção código/Comentários 3.4

Test Test — Wed, 17 Apr 2013 17:57:18 GMT

<> == Comentários == Os programas em Java podem ter dois tipos de comentários: de implementação e de documentação. Comentários de implementação são aqueles encontrados em C++, os quais são delimitados por /* . . . */, e / /. Comentários de documentação (conhecidos como “doc comments” ou “Javadoc”) são específicos do Java, sendo delimitados por /** . . . */. [[http://java.sun.com/products/jdk/javadoc/writingdoccomments.html|Comentários Javadoc]] podem ser extraídos para arquivos HTML usando-se a [[http://java.sun.com/products/jdk/javadoc/|ferramenta javadoc]]. ** Comentários de implementação são feitos para se descrever com detalhes um código em particular. Já os comentários Javadoc servem para descrever a especificação de um código a partir de uma perspectiva livre de implementação a ser lida por desenvolvedores que não necessariamente tenham o código fonte em mãos. Comentários devem ser usados para dar uma visão geral do código e fornecer informação adicional que não esteja prontamente disponível no próprio código. Comentários devem conter somente informações relevantes para a leitura e entendimento do programa. Por exemplo, informações sobre como determinado pacote é construído ou em qual diretório ele reside não devem ser incluídas como um comentário. Discussões sobre decisões não triviais ou não óbvias são apropriadas, porém evite duplicar informações que já estejam presentes e de maneira clara no código. É muito fácil os comentários redundantes ficarem desatualizados. Em geral, evite quaisquer comentários prováveis de ficarem obsoletos ou desatualizados à medida que o código evolui. A frequência dos comentários por vezes reflete baixa qualidade do código. Quando você se sente forçado a incluir um comentário, considere reescrever o código para deixá-lo mais limpo. Comentários não devem ser colocados em grandes caixas de desenho com asteriscos ou outros caracteres. Comentários nunca devem incluir caracteres especiais tais como form-feed e backspace. === Formatos para implementação de comentários === Os programas podem ter quatro estilos de implementação de comentários: bloco, linha única, trailing e final de linha. ==== Comentário de bloco ==== Comentários de bloco são usados para fornecer descrições de arquivos, métodos, estruturas de dados e algoritmos. Comentários de bloco podem ser usados no início de cada arquivo e antes de cada método. Eles podem também ser usados em outros lugares, tais como dentro dos métodos. Comentários de bloco dentro de uma função ou método devem ser indentados no mesmo nível do código o qual descrevem. Um comentário de bloco deve ser precedido por uma linha em branco para separá-lo do resto do código. Comentários de bloco possuem um asterisco “*” no início de cada linha exceto a primeira. {{{ /* * Eis um comentário de bloco. */ }}} ==== Comentário de linha única ==== Comentários curtos podem aparecer em uma linha simples indentada no nível do código que se segue. Se um comentário não puder ser escrito em uma única linha, este deverá seguir o formato de comentário de bloco (ver item anterior). Um comentário de linha única deverá ser precedido de uma linha em branco. Eis um exemplo de um comentário de linha única em um código Java. {{{ if (condição) { /* Comentário para o tratamento da condição. */ ... } }}} ==== Comentário do tipo trailing ==== Comentários muito curtos podem aparecer na mesma linha de código, mas deverão estar longe o suficiente para separá-los de outras instruções. Se mais de um comentário curto aparecer em um bloco de código, todos eles deverão usar a mesma indentação ou tabulação. Eis um exemplo de comentário do tipo trailing em um código Java: {{{ if (a == 2) { return TRUE; /* caso especial */ } else { return numeroPrimo(a); /* funciona apenas para os ímpares */ } }}} ==== Comentário de final de linha ==== O delimitador de comentário “//” pode ser utilizado para comentar toda uma linha de código ou apenas parte dela, e não deve ser usado em múltiplas linhas consecutivas para comentários de texto. Entretanto, ele pode ser usado em múltiplas linhas consecutivas para comentar seções de código. A seguir exemplos dos três estilos citados:// {{{ if (foo > 1) { // realizar um flip duplo ... } else return false; // Explicar a funcionalidade aqui. }}} Não é recomendado comentar códigos não utilizados, pois o controle de versões possue esta informação {{{ //if (bar > 1) { // // // realizar um flip triplo // ... //} //else // return false; }}} === Comentários de documentação === Comentários de documentação (ou do tipo doc) descrevem classes Java, interfaces, construtores, métodos e campos. Cada comentário doc é definido dentre os delimitadores /**...*/ tendo um comentário por classe ou interface. Este comentário deverá aparecer logo antes das declarações da seguinte forma: ** {{{ /** * Descrição geral da classe. * * @javadoc */ public class Exemplo { ... }}} A primeira linha de um comentário de documentação (/**) não é indentada, e as linhas subsequentes têm cada uma o seu espaço de indentação verticalmente, de forma que os asteriscos fiquem alinhados. ** Comentários de documentação não devem ser colocados dentro de um bloco de definição de método ou construtor, pois o Java os associa com a primeira declaração logo após o comentário. Sendo assim, um comentário de documentação divide-se em duas seções: descrição geral sobre a funcionalidade exercida pelo código em questão e informações especiais para a confecção da documentação pela ferramenta Javadoc. A descrição geral indica a abrangência da classe, interface ou método, indicando funcionalidades e esclarecendo as regras de negócio envolvidas na documentação. Por outro lado, as informações especiais possuem um formato pré-estabelecido. Considere consultar o documento [[http://java.sun.com/products/jdk/javadoc/writingdoccomments.html|How to Write Doc Comments for Javadoc]] para obter maiores detalhes sobre o assunto. De maneira resumida, as marcações no Javadoc são definidas através de um **@nome_tag**, cujo propósito é de melhor estruturar a documentação final gerada. ==== Tags do Javadoc ==== Eis algumas tags pré-definidas para a utilização via Javadoc: |= Nome |= Função| |@author|Nome do autor do código.| |@deprecated|Indica que a o membro em questão (classe, método ou variável) não deve ser usado pois possivelmente será removido em versões futuras.| |@since|Descreve quando o elemento foi adicionado à especificação da API.| |@see|Adiciona um link à seção “Veja também” (“See also”) da documentação.| |@version|Número da versão atual.| |@param|Descreve um ou vários parâmetros de um método, sendo acompanhado por uma descrição.| |@return|Descreve o valor retornado por um método.| |@throws|Indica as exceções verificadas que um dado método dispara.| ==== Utilização de código HTML nos comentários ==== Você pode opcionalmente incluir tags HTML na descrição do comentário Javadoc a fim de possibilitar uma leitura mais facilitada da documentação, uma vez que essa será traduzida para o formato HTML. Por exemplo: {{{ /** * Você pode também incluir uma lista: *

elemento 1
elemento 2
elemento 3

* e hiperlinks : {@link classe#metodo} */ }}} As seguintes tags HTML estão disponíveis no Javadoc: *

...

: definição de um parágrafo de texto; *...: texto em negrito; *...: texto em itálico; *...: texto sublinhado; *...: inclusão de links de hipertexto para documentos externos (arquivos técnicos, descrição de algoritmos, etc); *

: organiza texto em listas de marcadores; *
: quebra de linha no texto. ==== Utilização de comentários no Demoiselle ==== Nos códigos fontes do Framework Demoiselle não serão utilizadas as seguintes tags: **@author, @since e @version**. Tal diretiva visa garantir com que a documentação Javadoc esteja sempre atualizada com os códigos fontes. Além disso, as informações detalhadas sobre versionamento, datas e autoria serão melhores gerenciadas pelo repositório (atualmente Subversion). Não devem ser criados comentários de documentação do tipo Javadoc nas seguintes situações: * métodos oriundos de interfaces implementadas pela classe – tais métodos precisam ser documentados no código da interface; * métodos sendo sobrescritos através de herança – tais métodos precisam estar devidamente documentados na superclasse; * atributos de classe ou de instância – não haverá geração de documentação estruturada para estes, e para isso pode-se utilizar comentário convencional. ==== Exemplos de utilização em declarações ==== Documenta a funcionalidade da classe, interface, enumeração ou anotação explicando seu objetivo e as funcionalidades abrangentes aos seus métodos e atributos. ==== Classe ==== {{{ /** * Authenticator that actually does nothing but raise exceptions. * * @author SERPRO * @see Authenticator */ public class DefaultAuthenticator implements Authenticator { }}} ==== Interface ==== {{{ /** Structure used to handle pagination of data results on both backend (i.e., persistence) and frontend (i.e., presentation) layers in the application. @author SERPRO **/ public interface Pagination { }}} ==== Enumeração ==== {{{ /** * Defines available mailing mechanisms: a local resource or provided by the * application server. */ public enum MailType { }}} ==== Anotação ==== {{{ /** * Identifies a method eligible to be executed automatically during **application initialization**. * *public class Initializer { * * @Startup(priority = 1) * public void initialize() { * ... * } *} *

* The @Startup annotation allows an integer value to be defined, which stands for the method execution * priority when several initializer classes are available in the application. * * @author SERPRO */ @Target(METHOD) @Retention(RUNTIME) public @interface Startup { }}} ==== Exemplos de utilização em atributos e métodos ==== Documenta uma funcionalidade específica concernente ao campo ou método em questão. Para uma documentação de qualidade é importante observar que a primeira sentença do método deve conter uma descrição breve e objetiva terminando em ponto final. {{{ /** * Delegates the injection function to its specific factory. * * @param object the object to search for injections */ public void execute(Object object) { }}} Métodos que estão obsoletos e serão eliminados nas próximas versões da API devem obrigatoriamente ser assinalados com a diretiva @deprecated, tal como no modelo a seguir: {{{ /** * @deprecated * @see #metodoNovo */ @Deprecated public void metodoAnterior() { }}}

Configuração do Ambiente/Java Development Kit (JDK) 1.2

Test Test — Wed, 17 Apr 2013 17:54:33 GMT

<> TODO: ... == Linux == {{{ $ su # apt-get install sun-java6-jdk }}} == Windows == ?? == Mac OS == ??

Como utilizar 1.1

Test Test — Wed, 17 Apr 2013 17:53:46 GMT

[[Configuração do Ambiente|Configuração do Ambiente]] [[Configuração do Ambiente do Framework|Configuração do Ambiente do Framework]] [[Configuração do Ambiente/Ambiente Integrado de Desenvolvimento (IDE)|Configuração do Ambiente/Ambiente Integrado de Desenvolvimento (IDE)]] [[Configuração do Ambiente/Eclipse|Configuração do Ambiente/Eclipse]] [[Configuração do Ambiente/Java Development Kit (JDK)|Configuração do Ambiente/Java Development Kit (JDK)]]

Framework Demoiselle - Como Contribuir 1.4

Test Test — Mon, 08 Apr 2013 19:38:56 GMT

*[[Convenção desenvolvedor|Convenção desenvolvedor]] *[[Convenção desenvolvedor/Convenção código|Convenção desenvolvedor/Convenção código]] *[[Convenção desenvolvedor/Convenção código/Comentários|Convenção desenvolvedor/Convenção código/Comentários]] *[[Convenção desenvolvedor/Convenção código/Declarações|Convenção desenvolvedor/Convenção código/Declarações]] *[[Convenção desenvolvedor/Convenção código/Espaçamento|Convenção desenvolvedor/Convenção código/Espaçamento]] *[[Convenção desenvolvedor/Convenção código/Indentação|Convenção desenvolvedor/Convenção código/Indentação]] *[[Convenção desenvolvedor/Convenção código/Instruções|Convenção desenvolvedor/Convenção código/Instruções]] *[[Convenção desenvolvedor/Convenção código/Java|Convenção desenvolvedor/Convenção código/Java]] *[[Convenção desenvolvedor/Convenção código/Organização de arquivos|Convenção desenvolvedor/Convenção código/Organização de arquivos]] *[[Convenção desenvolvedor/Convenção nomes|Convenção desenvolvedor/Convenção nomes]] *[[Convenção desenvolvedor/Convenção nomes/Maven|Convenção desenvolvedor/Convenção nomes/Maven]] *[[Convenção desenvolvedor/Convenção nomes/Versionamento|Convenção desenvolvedor/Convenção nomes/Versionamento]] *[[Convenção desenvolvedor/Teste unitário|Convenção desenvolvedor/Teste unitário]] *[[Fluxo de contribuição|Fluxo de contribuição]] *[[Fluxo de contribuição/Defeito+Melhoria|Fluxo de contribuição/Defeito+Melhoria]] *[[Fluxo de contribuição/Nova funcionalidade|Fluxo de contribuição/Nova funcionalidade]] *[[Orientações técnicas|Orientações técnicas]] *[[Orientações técnicas/Geração de release|Orientações técnicas/Geração de release]] *[[Orientações técnicas/Geração de release v1|Orientações técnicas/Geração de release v1]] *[[Orientações técnicas/Geração de release v2|Orientações técnicas/Geração de release v2]] *[[Orientações técnicas/Práticas de Testes|Orientações técnicas/Práticas de Testes]] *[[Orientações técnicas/Práticas de programação|Orientações técnicas/Práticas de programação]] *[[Orientações técnicas/Utilização do Subversion|Orientações técnicas/Utilização do Subversion]] *[[Orientações técnicas/Utilização do tracking (MantisBT)|Orientações técnicas/Utilização do tracking (MantisBT)]] *[[Template de Nova Funcionalidade|Template de Nova Funcionalidade]]

Fluxo de contribuição/Nova funcionalidade 2.4

Test Test — Mon, 08 Apr 2013 17:36:23 GMT

<> == Esclarecendo os procedimentos e o fluxo de registro de novas propostas de melhorias para o framework Demoiselle. == === Diagrama de Atividades do Fluxo === {{Proposta_Funcionalidade2.png}} === Definições === **Definições dos Papéis no fluxo da proposta** //Papel da Comunidade// * Qualquer membro da comunidade (registrados ou não), pode apresentar uma nova proposta para o framework Demoiselle. * Utilizar a ferramenta oficial, e os respectivos modelos [[Template de Nova Funcionalidade|(templates)]] , para o registro da proposta. * Prestar os devidos esclarecimentos, quando solicitado. * Acatar as decisões do núcleo. * Pedir revisão ou esclarecimentos relativos à nova proposta. //Papel dos Desenvolvedores Dedicados// * Avaliar todas as propostas encaminhadas * Admitir ou recusar uma proposta * Pedir esclarecimentos aos proponentes (comunidade). * Encaminhar para apreciação do DTC (Conselho Técnico) propostas que não estejam no escopo definido no "//Road-Map//". * Encaminhar para apreciação do DTC as propostas que trarão significativos e relevantes efeitos inter projetos. * Fechar Proposta. * Re-abrir Proposta. * Definir um responsável do núcleo para acompanhar a proposta. * Avaliar os resultados. //Papel do Responsável// * Promover e acompanhar a divulgação da proposta * Abrir e acompanhar o fórum da proposta. * Avaliar os resultados. * Submeter ao núcleo os resultados e as avaliações. * Confirmar/Recusar a proposta. //Papel do Desenvolvedor// * Receber ou atribuir um caso. * Desenvolver ou adaptar codificação para o caso da proposta * Concluir o caso. //Papel do DTC - Demoiselle Technical Council (Conselho Técnico Demoiselle)// * Instância superior onde serão resolvidas as mediações, impasses, e casos não previstos. * Avaliar as propostas que trarão significativos e relevantes efeitos inter projetos. * Avaliar as propostas que não estejam no escopo definido pelo "//Road-Map//". * Zelar pelo bom andamento das propostas e tomar as medidas necessárias. //Papel do DCC - Demoiselle Community Council (Conselho da Comunidade Demoiselle)// * Influenciar nas definições de "//Road-Map// (Planejamento)" * Acompanhar as decisões tomadas pelo Conselho Técnico. * Interagir com o Conselho Técnico. **Definições das Ações no Fluxo da proposta** //Apresentar Proposta (Comunidade)// * Inclusão de uma requisição do tipo “New Feature”, na ferramenta Mantis, obedecendo o [[Template de Nova Funcionalidade|modelo padrão]]. //Esclarecer Proposta (Comunidade)// * Prestar informações, também através da ferramenta Mantis, sobre a proposta apresentada. Dirimindo as dúvidas e questionamentos iniciais sobre o formato e conteúdo da proposta. //Admitir Proposta (Desenvolvedores Dedicados)// * A proposta será dada como admitida, após ser analisada pelo grupo dedicado e considerada viável de desenvolvimento, e se necessário, após todos os pedidos de esclarecimentos terem sido efetuados. Este procedimento ainda não garante que a proposta será desenvolvida ou incluída/adaptada ao Demoiselle. //Solicitar Esclarecimentos (Desenvolvedores Dedicados)// * Após a análise inicial da proposta apresentada, ou mesmo de algum outro retorno, o grupo pode fazer pedidos de esclarecimentos ao proponente da comunidade. Será com base no retorno destas informações que a proposta poderá ser admitida ou não. //Definir Responsável (Desenvolvedores Dedicados)// * Quando a proposta é dada como admitida, o grupo escolherá um de seus membros que será responsável para acompanhar a proposta até o final dos seus trabalhos. O critério de escolha será o de capacidade técnica. //Fechar Proposta (Desenvolvedores Dedicados)// * Esta tarefa ocorre nos seguintes casos ** Recusa da proposta na fase inicial.:: Caso a proposta apresentada seja recusada nesta fase, o registro, na ferramenta de tracking de funcionalidades, será atualizado como fechado, e as justificativas serão apresentadas para o proponente da comunidade.:** Recusa após a admissão.** Se a proposta foi admitida, mas foi avaliada como inviável pelo responsável, após as atividades de divulgação e fórum, o grupo avalia os resultados e o registro na ferramenta de tracking é fechado. ** Ao final do processo de desenvolvimento.:: A proposta será fechada quando todos os procedimentos de desenvolvimento e publicação da nova funcionalidade proposta estejam concluídos. O grupo analisará os resultados e o registro na ferramenta de tracking é fechado.** //Reabrir Proposta (Desenvolvedores Dedicados)// * Intempestivamente, o grupo dedicado pode reabrir uma proposta, desde que seja devidamente justificado o motivo. Nesta ação, a proposta será reconduzida ao estado de admissão. //Abrir Fórum de discussões (Responsável)// * É a tarefa de abrir um novo tópico de discussão, na ferramenta definida como oficial, com o objetivo de coletar informações junto à todos os interessados na proposta. Estas informações também darão subsidio para a elaboração e refinamento da proposta. //Acompanhar Fórum (Responsável)// * Nesta ação, o responsável atuará como mediador do fórum, coletará as informações pertinentes e atualizará a proposta quando necessário. //Divulgar Proposta (Responsável)// * Tomar todas as ações necessárias para que a proposta seja exposta e discutida por todos os possíveis interessados. //Confirmar Proposta(Responsável)// * Após as atividades de refinamento da proposta, resultado das discussões no fórum e na divulgação. Quando a proposta atingir o nível de maturidade que pode ser considerada como viável de desenvolvimento, o responsável mudará o estado do registro na ferramenta de tracking para confirmada. //Fechar Fórum de discussões(Responsável)// * Se todos os trabalhos foram considerados concluídos, ou a proposta foi fechada por ter sido avaliada como inviável, o fórum de discussões deve ser bloqueado para alterações. //Atribuir Caso (Responsável)// * Após a proposta ter sido confirmada, um ou mais casos estarão abertos na ferramenta de tracking. O responsável deverá atribuir cada caso ao respectivo desenvolvedor. //Iniciar Resolução de um caso (Desenvolvedor)// * Ao ser atribuído de um caso (registro na ferramenta de tracking), o desenvolvedor tem a tarefa de executar o desenvolvimento, registrando as informações necessárias nas ferramentas oficiais do Demoiselle. //Concluir Resolução de um caso (Desenvolvedor)// * Ao término de todas as tarefas de desenvolvimento, deve ser alterado o estado do registro na ferramenta de tracking para o estado Resolvido. === Descrição do fluxo da proposta. === * O inicio do processo se dá pela apresentação da proposta, por qualquer contribuidor, através da ferramenta Mantis ([[http://sourceforge.net/apps/mantisbt/demoiselle)|http://sourceforge.net/apps/mantisbt/demoiselle)]], devendo a mesma estar de acordo com as instruções [[Template de Nova Funcionalidade|modelo padrão]] de apresentação de nova proposta. * O grupo denominado Desenvolvedores dedicados, fará uma análise inicial da proposta, podendo ela ser aceita ou não. Se recusada a proposta, o seu caso no Mantis será fechado com as devidas justificativas. Se necessário o núcleo pedirá esclarecimentos sobre a proposta antes do aceite ou recusa, podendo este passo ser repetido quantas vezes isso for necessário. Se a proposta for aceita passará a ser considerada como aceita, o grupo de desenvolvedores dedicados indicará um membro para o acompanhamento da nova proposta. * O proponente poderá, intempestivamente, pedir a revisão de proposta negada. * Os desenvolvedores dedicados devem avaliar se a proposta deve ser encaminhada para análise do Conselho Técnico (DTC), especialmente se não estiver contemplada no Planejamento (Road-Map), ou impacta fortemente em muitos projetos, ou pode gerar uma versão Maior ([[Convenção desenvolvedor/Convenção nomes/Versionamento|Convenção desenvolvedor/Convenção nomes/Versionamento]]). * Caso a proposta seja encaminhada ao DTC, este avaliará se a proposta será implementada ou não. * Na seqüência, o responsável indicado pelos desenvolvedores dedicados, fará a abertura de uma discussão em fórum específico para a proposta, relacionando a mesma com o número do caso no Mantis. Concomitantemente, será aberto um processo de divulgação da proposta para a comunidade em geral. O responsável fará o acompanhamento das atividades, como promotor de divulgação e mediador no fórum. Quando necessário, o responsável poderá submeter ao núcleo os resultados dos trabalhos. O resultado final desta fase, será a proposta oficialmente aceita e com o escopo de solução devidamente esclarecido. Cabe então ao responsável avaliar se será necessário a abertura de casos de melhorias, e atribuir cada um deles a um desenvolvedor. Caso os resultados dos trabalhos indiquem que a proposta está inviável de ser implementada no contexto apresentado, o responsável proporá o fechamento da proposta. * Se aprovada a proposta e com os casos atribuídos, todos os indicados formarão um grupo de trabalho liderado pelo responsável pela proposta. Os trabalhos serão executados de acordo com metodologia de desenvolvimento SCRUM. Ao final desta fase os casos deverão estar com o estado resolvido. * No passo seguinte, o responsável fará o fechamento(bloqueio) do fórum de discussões. * O passo final consiste na avaliação dos resultados e a publicação do código pelo grupo de desenvolvedores dedicados. Todos os casos relacionados com a proposta, cadastrados no Mantis, deverão ser fechados. **O grupo de desenvolvedores dedicados poderá, com as devidas justificativas, reabrir qualquer proposta já apresentada. === Termos === **Comunidade: Qualquer interessado no projeto, que pode ou não estar vinculado ao projeto Demoiselle.** **Desenvolvedores Dedicados: Membros de dedicação exclusiva ao projeto Demoiselle com prerrogativas de decisão sobre a aceitação de uma proposta do ponto de vista técnico.** **Responsável: Membro do núcleo do Demoiselle indicado e encarregado de acompanhar oficialmente uma proposta em todas fases a partir do aceite da proposta e sua indicação.** **Desenvolvedor: Membro da comunidade Demoiselle com atribuições de codificação e com a permissão para tratar um caso (registro na ferramenta de trakking) relatado, efetivando alterações em código-fonte.** **DTC (Demoiselle Technical Council): Conselho Técnico Demoiselle, definido conforme modelo de governança e seu estatuto. Conselho da Comunidade[[:Category:Conselho da Comunidade |]]** **DCC (Demoiselle Community Council): Conselho da Comunidade Demoiselle, definido conforme modelo de governança e seu estatuto. Conselho da Comunidade** === Considerações Finais === O tratamento aqui descrito contempla o fluxo principal de trabalho para tratamento de uma proposta de inclusão ou exclusão de funcionalidade ou componente no projeto Demoiselle, contemplando as situações consideradas como previsíveis no processo. No surgimento de excepcionalidades, a equipe responsável deverá discutir e definir seu tratamento, incrementando este documento com as novas definições. É responsabilidade do DTC (Demoiselle Technical Council) Conselho Técnico Demoiselle, mediar decisões que não foram resolvidas em nível de projeto, sendo esta a instância na qual serão decididas as questões que não foram contempladas no fluxo natural ou onde pode haver dúvidas ou recursos. === Diagrama de Estados do Fluxo === {{Proposta_Funcionalidade_Estados.png}}

Fluxo de contribuição/Defeito+Melhoria 2.3

Test Test — Mon, 08 Apr 2013 17:33:49 GMT

<> == Esclarecendo os procedimentos e o fluxo de registro de pedidos de Melhorias e relatos de Defeitos == === Diagrama de Atividades do Fluxo === {{Melhorias_Defeitos_Atividades3.png}} === Definições === **Definições dos Papéis no fluxo.** //Papel do Relator// * Registrar um pedido de melhoria ou relatar um defeito. * Utilizar a ferramenta oficial, para o registro. * Prestar os devidos esclarecimentos, quando solicitado. * Acatar as decisões. * Pedir revisão ou esclarecimentos relativos à um caso registrado. //Papel dos Desenvolvedores Dedicados// * Avaliar todos os registro de casos cadastrados na ferramenta de tracking . * Confirmar ou desconsiderar um caso. * Pedir esclarecimentos ao relator. * Encerrar um caso. * Reabrir um caso. * Atribuir um desenvolvedor para um caso. * Avaliar os resultados. //Papel do Desenvolvedor// * Receber um caso. * Desenvolver, corrigir, ou adaptar codificação conforme a solução para o caso. * Concluir a resolução do caso. //Papel do DTC - Demoiselle Technical Council (Conselho Técnico Demoiselle)// * Instância onde serão resolvidas as mediações, impasses, e casos não previstos. **Definições das Ações no Fluxo** //Relatar um Caso (Relator)// * Inclusão de uma registro do tipo "Improvement" ou "Bug", na ferramenta de tracking oficial do projeto. //Esclarecer um Caso (Relator)// * Prestar informações, quando solicitado, também através da ferramenta de tracking, sobre o caso registrado. Esclarecendo as dúvidas e questionamentos solicitados. //Confirmar um Caso (Desenvolvedores Dedicados)// * O caso poderá ser confirmado, após ser analisado pelo grupo dedicado e considerado viável de desenvolvimento, e se necessário, após todos os pedidos de esclarecimentos terem sido efetuados. //Solicitar Esclarecimentos (Desenvolvedores Dedicados)// * Após a análise inicial do caso, ou mesmo de algum outro retorno, o grupo dedicado pode fazer pedidos de esclarecimentos ao relator. Será com base no retorno destas informações que a proposta poderá ser confirmado ou não. //Atribuir um Caso (Desenvolvedores Dedicados)// * Quando o registro de um caso é confirmado, o grupo atribuirá o mesmo a um dos desenvolvedores. //Encerrar um Caso (Desenvolvedores Dedicados)// * Após o caso ter sido considerado resolvido, o grupo irá avaliar os resultados, tomar as medidas e procedimentos necessários, e fará o encerramento do caso que resultará no fechamento do mesmo. //Reabrir um Caso (Desenvolvedores Dedicados)// * Intempestivamente, o grupo dedicado pode reabrir um caso que já havia sido fechado ou recusado, desde que seja devidamente justificado o motivo. //Iniciar Resolução de um caso (Desenvolvedor)// * Ao ser atribuído de um caso (registro na ferramenta de tracking), o desenvolvedor tem a tarefa de executar o desenvolvimento, registrando as informações necessárias nas ferramentas oficiais do Demoiselle. //Concluir Resolução de um caso (Desenvolvedor)// * Ao término de todas as tarefas de desenvolvimento, deve ser alterado o estado do registro na ferramenta de tracking para o estado Resolvido. === Descrição do fluxo da proposta. === * O registro de um caso, através da ferramenta de tracking ([[https://sourceforge.net/apps/mantisbt/demoiselle)|https://sourceforge.net/apps/mantisbt/demoiselle)]], do tipo "Improvement" ou "Bug" dará inicio ao processo. * O grupo denominado Desenvolvedores dedicados, fará uma análise inicial do caso, podendo este ser confirmado ou não. Se recusado, o caso será fechado com as devidas justificativas, e com alteração específica no estado. Se necessário o grupo pedirá esclarecimentos sobre o caso antes da confirmação ou recusa, podendo este passo ser repetido quantas vezes isso for necessário. Se o caso for confirmado, o grupo de desenvolvedores dedicados irá atribuir um desenvolvedor para a solução. * O relator poderá, intempestivamente, pedir a revisão do caso. * Os trabalhos de desenvolvimento serão executados de acordo com metodologia de desenvolvimento SCRUM. * O passo final consiste na avaliação dos resultados e a publicação do código pelo grupo de desenvolvedores dedicados. Neste passo é feito o encerramento do caso. **O grupo de desenvolvedores dedicados poderá, com as devidas justificativas, reabrir qualquer caso fechado. **O DTC deve zelar pelo cumprimento do Fluxo e intervir quando necessário ou for consultado. === Termos === **Relator: Qualquer interessado no projeto, que utilize a ferramenta de tracking para registrar um caso.** **Desenvolvedores Dedicados: Membros de dedicação exclusiva ao projeto Demoiselle com prerrogativas de decisão sobre a aceitação de um caso do ponto de vista técnico.** **Desenvolvedor: Membro da comunidade Demoiselle com atribuições de codificação e com a permissão para tratar um caso (registro na ferramenta de trakking) relatado, efetivando alterações em código-fonte.** **DTC (Demoiselle Technical Council): Conselho da Comunidade Demoiselle, definido conforme modelo de governança e estatuto. Conselho da Comunidade[[Conselho da Comunidade|]]** === Considerações Finais === O tratamento aqui descrito contempla o fluxo principal de trabalho para tratamento de um pedido de melhoria ou relato de defeito, contemplando as situações consideradas como previsíveis no processo. No surgimento de excepcionalidades, a equipe responsável deverá discutir e definir seu tratamento, incrementando este documento com as novas definições. É responsabilidade do DCC (Demoiselle Community Council) Conselho da Comunidade Demoiselle, mediar decisões que não foram resolvidas em nível de projeto, sendo esta a instância na qual serão decididas as questões que não foram contempladas no fluxo natural ou onde pode haver dúvidas ou recursos. === Diagrama de Estados do Fluxo === {{Defeitos_Melhorias_Estados.png}}

Convenção desenvolvedor 2.1

Test Test — Mon, 08 Apr 2013 17:30:08 GMT

<> == Objetivos e princípios == Este documento tem como finalidade determinar os padrões e convenções a serem seguidos no desenvolvimento de aplicações em Java pelos desenvolvedores do **[[http://www.frameworkdemoiselle.gov.br/|Framework Demoiselle]]**. Para a leitura deste documento é recomendável o conhecimento prévio da **[[http://java.sun.com/|linguagem Java]]**. Uma padronização na programação precisa ser adotada a fim de manter consistente por todo um projeto e para facilitar subsequentes manutenções corretivas e evolutivas em seu código. Além disso, o uso de componentes de software é facilitado através da adequação aos padrões internacionais. A **Sun Microsystems** publicou em 1997 um padrão de desenvolvimento para a linguagem Java entitulado **[[http://java.sun.com/docs/codeconv/|Java Code Conventions]]**. Tais regras tornaram-se o padrão no mundo do desenvolvimento Java. O presente documento apenas aponta e especifica tais regras levando em consideração o contexto específico do **Framework Demoiselle**. Este documento também baseou-se no documento "Padrões e Convenções para Código Java" elaborado para o **[[http://www.frameworkpinhao.pr.gov.br/|Framework Pinhão Paraná]]**, da **CELEPAR**. == Convenção de idioma == Para a nomeação de artefatos de código e documentação destes na forma de comentários no Framework Demoiselle é recomendada a utilização do **idioma inglês**. Para aplicações específicas, o projetista é livre para nomear classes, variáveis e métodos de acordo com termos específicos à regra de negócio em sua língua original, porém é recomendável adotar a língua inglesa quando da existência de componentes técnicos potencialmente reusáveis desenvolvidos na aplicação. == Caracteres utilizáveis == Em geral a nomeação de classes, parâmetros, atributos e métodos usa as seguintes faixas de caracteres alfanuméricos: a-z, A-Z e 0-9. A utilização de caracteres especiais ("?", "!", "@", "ç", ...) e acentos ("á", "ã", "é", "í", "ó", ...) nos nomes é proibida. O underscore "_" pode ser utilizado para a nomeação de constantes ou de valores enumerados. == Legibilidade == Como em qualquer linguagem, é muito importante fornecer comentários relevantes ao código. Por exemplo, é inútil repetir o nome de um método na forma de uma sentença. A preferência deve sempre ser dada aos identificadores (nomes de atributos, métodos, etc) com comentários sucintos. O princípio importante a ser adotado é a legibilidade do código. Os códigos fontes de um programa interessam tanto ao compilador quanto ao desenvolvedor. Devemos lembrar todas as vezes que o código precisará ser mantido. E essa manutenção, corretiva ou evolutiva, por vezes é efetuada por outra pessoa diferente do desenvolvedor inicial. == Repositório de Fontes == O repositório oficial de fontes, a partir da versão 2, é o [[https://github.com/demoiselle/|GitHub]] os códigos das versões anteriores continuam no SVN [[http://svn.frameworkdemoiselle.gov.br/|http://svn.frameworkdemoiselle.gov.br/]] neste [[http://www.frameworkdemoiselle.gov.br/documentacaodoprojeto/manuais-e-tutoriais/manuais/guia-demoiselle-nimble-com-eclipse-github-groovy|link]] você encontrará um guia para uso do Github. == Convenções para codificação == *[[Convenção desenvolvedor/Convenção código|Convenção de Código]] *[[Convenção desenvolvedor/Convenção nomes|Convenção de Nomes]] *[[Convenção desenvolvedor/Teste unitário|Teste Unitário]] * Log

Comunidade 2.9

Test Test — Mon, 08 Apr 2013 17:19:18 GMT

<> == Organização da Comunidade == === Modelo de Governança === [[Modelo de Governança| Gestão e organização da comunidade Demoiselle]] === Demoiselle Community Council (DCC) === O Conselho da Comunidade é responsável pelas decisões estratégicas. Ele decide o que fazer, quais as metas e os objetivos. [[Estatuto do Conselho da Comunidade DCC| Estatuto]] | [[http://www.frameworkdemoiselle.gov.br/comunidade/colaboradores/colaboradores|Composição]]

Tutorial Laboratório Módulo 2 Persistência 1.5

Test Test — Mon, 08 Apr 2013 17:16:12 GMT

<> **{{Laboratorio.png}}Tutorial – Módulo 02 – Persistência** == LABORATÓRIO 02 – Persistência == Este laboratório tem por objetivo fixar os conceitos da camada de persistência do Framework Demoiselle e orientar o processo de configuração das aplicações. === Objetivos: === * Configurar a camada de Persistência através do Demoiselle Wizard. * Criar a camada de persistência da aplicação //Escola//. ** Interfaces DAO; ** Implementações DAO; ** Filtros de Consulta; * Testar o funcionamento da camada de persistência. === Exercício 2.1 – Configuração do Projeto === 1. Este laboratório utilizará o projeto “**escola**” criado no laboratório anterior. 2. Clique com o botão direito sob o projeto a acione a opção Demoiselle → Configurar Projeto. {{Configurar_projeto.png}} //Figura 1: Configurar Projeto// 3. Na guia “//Hibernate//”, configure os campos conforme seu banco de dados. Este tutorial utilizará como exemplo o HypersonicSQL. * URL: jdbc:hsqldb:hsql://127.0.0.1/escola// {{Configurar_banco_dados.png}} //Figura 2: Configuração da conexão com o banco de dados// Altere as informações: {{{ URL=> jdbc:hsqldb:hsql://127.0.0.1/escola Usuário=>sa }}} 4. Clique no botão //Finish//. O Wizard irá configurar o //hibernate.cfg.xml na pasta de resources do projeto conforme figura abaixo//: {{Hibernate_cfg.png}} //Figura 3: hibernate.cfg.xml// 5. Adicione a dependência do HSQLDB versão 1.8.0.1 no arquivo pom.xml da aplicação (**logo após a tag }profiles>**) conforme abaixo: {{{ ... hsqldb hsqldb 1.8.0.1 ... }}} === Exercício 2.2 – Desenvolvimento da camada de persistência. === **Pacote Bean** ==== 1. Pojo Aluno ==== No pacote //br.gov.demoiselle.escola.bean// Implemente o Pojo de Aluno conforme abaixo: {{{ package br.gov.demoiselle.escola.bean; import java.util.ArrayList; import java.util.Date; import java.util.HashSet; import java.util.List; import java.util.Set; import javax.persistence.Entity; import javax.persistence.Table; import javax.persistence.Column; import javax.persistence.FetchType; import javax.persistence.GeneratedValue; import javax.persistence.Id; import javax.persistence.Temporal; import javax.persistence.TemporalType; import javax.persistence.CascadeType; import javax.persistence.OneToMany; import javax.persistence.GenerationType; import br.gov.framework.demoiselle.core.bean.IPojo; @Entity @Table(name="aluno") @SequenceGenerator(name="AlunoSequence", sequenceName="aluno_seq", allocationSize=1) public class Aluno implements IPojo { private static final long //serialVersionUID// = 1L; @Id @GeneratedValue(generator="AlunoSequence", strategy=GenerationType.//SEQUENCE//) @Column(name="id_aluno") private Long id; @Column(name="nome", length=100) private String nome; @Column(name="pai", length=100) private String pai; @Column(name="mae", length=100) private String mae; @Column(name="nascimento") @Temporal(value=TemporalType.//DATE//) private Date nascimento; @OneToMany(cascade=CascadeType.//ALL//, fetch=FetchType.//LAZY//) private Set enderecos; public Aluno() { enderecos = new HashSet(); } public Aluno(long** id) { this(); this.id = id; } public Long getId() {return id; } public void setId(Long id) { this.id = id; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getPai() { return pai; } public void setPai(String pai) { this.pai = pai; } public String getMae() { return mae; } public void setMae(String mae) { this.mae = mae; } public Date getNascimento() { return nascimento; } public void setNascimento(Date nascimento) { this.nascimento = nascimento; } public Set getEnderecos() { return enderecos; } public List getListaEndereco() { return new ArrayList(enderecos); } public void setEnderecos(Set enderecos) { this.enderecos = enderecos; } } }}} ==== 2. Pojo Endereço ==== No mesmo pacote implemente o Pojo de Endereço: {{{ package br.gov.demoiselle.escola.bean; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.FetchType; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.JoinColumn; import javax.persistence.ManyToOne; import javax.persistence.Table; import br.gov.component.demoiselle.common.pojo.extension.Description; import br.gov.component.demoiselle.common.pojo.extension.EqualsField; import br.gov.component.demoiselle.common.pojo.extension.PojoExtension; import br.gov.framework.demoiselle.core.bean.IPojo; @Entity @Table(name="endereco") @SequenceGenerator(name="EnderecoSequence", sequenceName="Endereco_seq", allocationSize=1) public class Endereco extends PojoExtension implements IPojo { private static final long serialVersionUID = 1L; @EqualsField @Id @GeneratedValue(generator="EnderecoSequence", strategy=GenerationType.SEQUENCE) @Column(name="id_endereco") private Long id; @EqualsField @Description @Column(name="logradouro", length=100) private String logradouro; @Description @Column(name="numero", length=100) private String numero; @Description @Column(name="complemento", length=100) private String complemento; @Description @Column(name="bairro", length=100) private String bairro; @Description @Column(name="cep", length=100) private String cep; @Column(name="municipio", length=100) private String municipio; @Description @Column(name="tipo") private Integer tipo; @Description @ManyToOne(fetch=FetchType.LAZY) @JoinColumn(name="aluno") private Aluno aluno; public Endereco() { } public Endereco(String logradouro, String numero, String complemento, String bairro, String cep, String Municipio, Integer tipo) { super(); this.logradouro = logradouro; this.numero = numero; this.complemento = complemento; this.bairro = bairro; this.cep = cep; this.municipio = Municipio; this.tipo = tipo; } public Long getId() { return id; } public void setId(Long id) { this.id = id; } public String getLogradouro() { return logradouro; } public void setLogradouro(String logradouro) { this.logradouro = logradouro; } public String getNumero() { return numero; } public void setNumero(String numero) { this.numero = numero; } public String getComplemento() { return complemento; } public void setComplemento(String complemento) { this.complemento = complemento; } public String getBairro() { return bairro; } public void setBairro(String bairro) { this.bairro = bairro; } public String getCep() { return cep; } public void setCep(String cep) { this.cep = cep; } public Integer getTipo() { return tipo; } public void setTipo(Integer tipo) { this.tipo = tipo; } public String getMunicipio() { return municipio; } public void setMunicipio(String Municipio) { this.municipio = Municipio; } public Aluno getAluno() { return aluno; } public void setAluno(Aluno aluno) { this.aluno = aluno; } } }}} ==== 3. Associando POJOs ao Hibernate ==== Para associar os POJOS ao hibernate.cfg.xml acione o menu: Demoiselle → Configurar Projeto. * Na guia //Hibernate,// clique no botão **Adicionar Pojo **(figura 4). {{Adicionar_pojo.png}} //Figura 4: Adicionar Pojo// Na Tela seguinte (figura 5) selecione a Classe que deseja associar. {{Selecionar_pojo.png}} //Figura 5: Seleção de POJOs// Acione o botão //Finish// e verifique que o Wizard associou o arquivo //hibernate.cfg.xml// às duas classes selecionadas: {{{ org.hsqldb.jdbcDriver jdbc:hsqldb:hsql://localhost/escola/ sa org.hibernate.dialect.HSQLDialect true true update }}} ==== 4. Implementação dos Pacotes DAO ==== 1. Para geração das classes de acesso a dados (DAO), utilize o Menu → Demoiselle → Editar Projeto: {{Editar_projeto.png}} //Figura 6: Editar Projeto// 2. Na guia //DAOs// acione o botão //Adicionar// para criar o DAO responsável pelo Pojo Aluno. {{Adicionar_dao.png}} //Figura 7: Adicionar DAO// 3. No campo //Pacote// selecione o pacote: //br.gov.demoiselle.escola.persistence.dao}// no campo //Pojo// selecione a classe: br.gov.demoiselle.escola.bean.Aluno//. // Selecione o tipo DAO Hibernate conforme mostrado na figura abaixo: {{Salvar_dao.png}} //Figura 8: Salvar DAO// 4. Acione o botão Salvar. 5. Acione o botão //Finish// e aguarde a criação das classes nos pacotes conforme abaixo: {{Pacote_dao.png}} //Figura 9: Interface para DAO e sua implementação// * A classe **//'IAlunoDAO//**//especifica apenas os métodos de consulta. ** Adicione na interface IAlunoDAO os seguintes métodos, conforme o código abaixo:** {{{ package br.gov.demoiselle.escola.persistence.dao; import java.util.List; import br.gov.framework.demoiselle.core.layer.IDAO; import br.gov.framework.demoiselle.util.page.Page; import br.gov.framework.demoiselle.util.page.PagedResult; import br.gov.demoiselle.escola.bean.Aluno; import br.gov.demoiselle.escola.bean.Endereco; public interface IAlunoDAO extends IDAO { public PagedResult listar(Page pagina); public List listar(); public PagedResult filtrar(Aluno aluno, Page pagina); public Aluno buscar(Aluno aluno); public void alterarEndereco(Endereco endereco); } }}} * A classe **//'AlunoDAO//**' implementará apenas os métodos definidos na interface IAlunoDAO, pois as demais operações (**C**reate **R**ead **U**pdate **D**elete) = Criar, Ler, Atualizar e Excluir, encontram-se implementadas por herança. ** Por enquanto crie os métodos da classe AlunoDAO sem implementação; ** {{{ import java.util.List; import br.gov.framework.demoiselle.persistence.hibernate.HibernateGenericDAO; import br.gov.framework.demoiselle.util.page.Page; import br.gov.framework.demoiselle.util.page.PagedResult; import br.gov.demoiselle.escola.bean.Aluno; import br.gov.demoiselle.escola.bean.Endereco; import br.gov.demoiselle.escola.persistence.dao.IAlunoDAO; public class AlunoDAO extends HibernateGenericDAO implements IAlunoDAO public void alterarEndereco(Endereco endereco) { // TODO Auto-generated method stub } public List listar() { // TODO Auto-generated method stub return null; } public Aluno buscar(Aluno aluno) { // TODO Auto-generated method stub return null; } public PagedResult filtrar(Aluno aluno, Page pagina) { // TODO Auto-generated method stub return null; } public PagedResult listar(Page pagina) { // TODO Auto-generated method stub return null; } } }}} === Exercício 2.3 – Filtros – Uso do Componente === ==== 1. Criar a classe FiltroAluno ==== No pacote br.gov.demoiselle.escola.persistence.dao.filter crie a classe FiltroAluno e inclua os campos ID e NOME para a filtragem conforme exemplo abaixo. {{{ package br.gov.demoiselle.escola.persistence.dao.filter; import br.gov.component.demoiselle.hibernate.filter.Filter; import br.gov.demoiselle.escola.bean.Aluno; public class FiltroAluno extends Filter { private static final long serialVersionUID = 1L; public static final String ID = "id"; public static final String NOME = "nome"; public FiltroAluno(){ setClazz(Aluno.class); addOrder(NOME, ASC); } } }}} Para utilizar o componente Hibernate-Filter, as classes DAOs deverão estender a classe HibernateFilterGenericDAO. ==== 2. Alterar a classe AlunoDAO ==== Modifique a classe AlunoDAO conforme exemplo abaixo: De: {{{ public class AlunoDAO extends HibernateGenericDAO implements IAlunoDAO }}} Para: {{{ public class AlunoDAO extends HibernateFilterGenericDAO implements IAlunoDAO }}} Retire o import: {{{ import br.gov.framework.demoiselle.persistence.hibernate.HibernateGenericDAO; }}} Inclua: {{{ import br.gov.component.demoiselle.hibernate.filter.dao.HibernateFilterGenericDAO; import br.gov.framework.demoiselle.persistence.hibernate.HibernateUtil; import br.gov.demoiselle.escola.persistence.dao.filter.FiltroAluno; }}} ==== 3. Implementar os métodos da classe AlunoDAO ==== Para cada método, conforme o código abaixo: * Listar alunos: {{{ public PagedResult listar(Page pagina) { HibernateUtil.getInstance().getSession().flush(); return findHQL("FROM Aluno ORDER BY nome ASC", pagina); } public List listar() { HibernateUtil.getInstance().getSession().flush(); return findHQL("FROM Aluno ORDER BY nome ASC"); } }}} * Filtrar alunos: {{{ public PagedResult filtrar(Aluno aluno, Page pagina) { HibernateUtil.getInstance().getSession().flush(); return findByExample(aluno, pagina); } }}} * Buscar Aluno: {{{ public Aluno buscar(Aluno aluno) { HibernateUtil.getInstance().getSession().flush(); FiltroAluno filtro = new FiltroAluno(); filtro.addEquals(FiltroAluno.ID, aluno.getId()); List retorno = find(filtro); if (retorno != null && retorno.size() > 0 ) return retorno.get(0); return null; } }}} * Alterar Endereço: {{{ public void alterarEndereco(Endereco endereco) { HibernateUtil.getInstance().getSession().update(endereco); } }}} Sua camada de acesso a dados está implementada e pronta para ser testada! === Exercício 2.4 – Execução e Testes === 1. Para realizar os testes, utilizaremos o banco de dados HSQLDB, que foi incluído como dependência. 2. Para realizar os testes, podemos utilizar o banco de dados HSQLDB disponível no material de treinamento. (repositório SVN do Demoiselle: [[https://demoiselle.svn.sourceforge.net/svnroot/demoiselle/trunk/docs/others/tutorial/tools/hsqldb.zip|https://demoiselle.svn.sourceforge.net/svnroot/demoiselle/trunk/docs/others/tutorial/tools/hsqldb.zip]]); 3. Inicie-o em modo servidor da seguinte forma: * Se ambiente Windows: ** Execute a arquivo: ./hsqldb/run.bat * Se ambiente Linux: ** Execute a arquivo: ./hsqldb/run.sh Mantenha o console aberto enquanto utilizar o banco. {{Console_hsqldb.png}} //Figura 10: Console com inicialização do Hsqldb// * Se utilizar este modo vá para o item 5. 4. Para iniciar o banco através do Eclipse, Inicie-o em modo servidor da seguinte forma: * No ambiente Eclipse, Crie o arquivo server.properties na raiz do projeto: {{Server_properties.png}} //Figura 11: Configuração do banco escola// - texto do arquivo, server.properties: {{{ server.database.0=./db_escola/escola server.dbname.0=escola server.silent=false server.trace=true }}} * Depois, Selecione o Menu: Run → Run Configurations... {{Run_Configurations.png}} //Figura 12: Run configurations// Clique com o botão direito do mouse e depois clique em **New** {{New_configuration.png}} //Figura 13: New configuration// * Nesta tela, clique no Botão **Search** {{Search_class.png}} //Figura 14: Search class// Digite ou procure o item Server, depois clique em **OK**. * Ao voltar na tela Anterior, escolha um nome para Configuração (**Name**) e clique no botão **Apply** e depois **Run**. * Com isto, toda vez que precisar rodar o banco, basta escolher esta configuração. * Resultado na Console do Eclipse: {{{ [Server@173831b]: [Thread[main,5,main]]: checkRunning(false) entered [Server@173831b]: [Thread[main,5,main]]: checkRunning(false) exited [Server@173831b]: Startup sequence initiated from main() method [Server@173831b]: Loaded properties from [/home/80621732915/work_teste/escola/server.properties] [Server@173831b]: [Thread[main,5,main]]: start() entered [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: run() entered [Server@173831b]: Initiating startup sequence... [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.tls=false [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.port=9001 [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.trace=true [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.database.0=./db_escola/escola [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.restart_on_shutdown=false [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.no_system_exit=false [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.silent=false [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.default_page=index.html [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.address=0.0.0.0 [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.dbname.0=escola [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: server.root=. [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: openServerSocket() entered [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: Got server socket: ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9001] [Server@173831b]: Server socket opened successfully in 16 ms. [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: openServerSocket() exiting [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: openDatabases() entered [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: Opening database: [file:./db_escola/escola] [Server@173831b]: Database [index=0, id=0, db=file:./db_escola/escola, alias=escola] opened sucessfully in 171 ms. [Server@173831b]: [Thread[HSQLDB Server @173831b,5,main]]: openDatabases() exiting [Server@173831b]: Startup sequence completed in 190 ms. [Server@173831b]: 2009-08-18 09:45:38.833 HSQLDB server 1.8.0 is online [Server@173831b]: To close normally, connect and execute SHUTDOWN SQL [Server@173831b]: From command line, use [Ctrl]+[C] to abort abruptly [Server@173831b]: [Thread[main,5,main]]: start() exiting }}} O HSQLDB vem com uma ferramenta chamada Database Manager, que é uma interface gráfica que permite navegar pelas tabelas do banco. É muito útil para acompanhar o efeito das operações de persistência. Ela pode ser executada com o comando: {{{ java -cp hsqldb/lib/hsqldb.jar org.hsqldb.util.DatabaseManager }}} 5. Para geração das classes de testes da camada DAO, utilize o Menu → Demoiselle → Editar Projeto: {{Editar_projeto (1).png}} //Figura 15: Editar Projeto// ** Selecione a Aba: Teste Unitário: ** {{Teste_unitario.png}} //Figura 16: Gerar Teste Unitário// ** Clique no botão **Adicionar**, para habilitar a inclusão de um novo teste unitário e os campos do lado direito da tela. ** Depois clique no botão **Pesquisar**, por padrão o Tipo da Interface já estará marcada como DAO, e será deste tipo que iremos criar o teste. {{Selecionar_classe_teste.png}} //Figura 17: Selecionar Classe para Teste// ** Selecione a interface IAlunoDAO, e clique no botão **Finish**.** {{Salvar_teste.png}} //Figura 18: Salvando Classe de Teste// Com a interface selecionada, clique no botão **Salvar**. {{Aplicar_teste.png}} //Figura 19: Aplicando Alterações JUnit//** Na sequência, clique no botão **Aplicar.**** Aguarde a confirmação dos resultados. {{Teste_ok.png}} //Figura 20: Finalizando Alterações JUnit// ** Depois clique no botão **Finish**. O caso de testes deverá ser criado conforme a estrutura abaixo: ** {{Pacote_teste.png}} //Figura 21: Pacote de Classes de Teste// 6. Altere o teste para a inclusão do aluno: {{{ @Test public void testInsertObject() { Aluno obj_Aluno = new Aluno(); obj_Aluno.setNome("Aluno 01"); obj_Aluno.setNascimento(new Date()); obj_Aluno.setMae("Mae do aluno 01"); obj_Aluno.setPai("Pai do aluno 01"); Endereco obj_Endereco = new Endereco(); obj_Endereco.setBairro("Bairro do aluno 01"); obj_Endereco.setCep("01010101"); obj_Endereco.setComplemento("Complementdo ao Aluno 01"); obj_Endereco.setLogradouro("Logra"); obj_Endereco.setAluno(obj_Aluno); obj_Aluno.setEnderecos(new HashSet()); obj_Aluno.getEnderecos().add(obj_Endereco); alunoDAO.insert(obj_Aluno); assertTrue(obj_Aluno.getId() >= 0); Endereco endereco = (Endereco) obj_Aluno.getEnderecos().toArray()[0]; assertNotNull(endereco); assertTrue(endereco.getId() >= 0); } }}} Para este teste serão necessários os seguintes imports: {{{ import java.util.Date; import java.util.HashSet; import br.gov.demoiselle.escola.bean.Aluno; import br.gov.demoiselle.escola.bean.Endereco; }}} 7. Altere o teste de alteração do Aluno: {{{ @Test public void testUpdate() { //Cria um novo aluno Aluno obj_Aluno = new Aluno(); obj_Aluno.setNome("Aluno_criado"); Endereco endereco = new Endereco(); endereco.setLogradouro("Endereco_criado"); endereco.setAluno(obj_Aluno); obj_Aluno.setEnderecos(new HashSet()); obj_Aluno.getEnderecos().add(endereco); alunoDAO.insert(obj_Aluno); long id = obj_Aluno.getId(); //Altera o aluno criado obj_Aluno = alunoDAO.buscar(new Aluno(id)); obj_Aluno.setNome("Aluno_alterado"); endereco = (Endereco) obj_Aluno.getEnderecos().toArray()[0]; endereco.setLogradouro("Endereco_alterado"); alunoDAO.update(obj_Aluno); //Consulta aluno alterado obj_Aluno = alunoDAO.buscar(new Aluno(id)); assertEquals("Aluno_alterado", obj_Aluno.getNome()); endereco = (Endereco) obj_Aluno.getEnderecos().toArray()[0]; endereco.setLogradouro("Endereco_alterado"); assertEquals("Endereco_alterado", endereco.getLogradouro()); } }}} 8. Altere o seguinte método para testar a remoção de Aluno. {{{ @Test public void testRemove() { //Cria um aluno para ser removido Aluno obj_Aluno = new Aluno(); obj_Aluno.setNome("Aluno_criado"); Endereco endereco = new Endereco(); endereco.setLogradouro("Endereco_criado"); endereco.setAluno(obj_Aluno); obj_Aluno.setEnderecos(new HashSet()); obj_Aluno.getEnderecos().add(endereco); alunoDAO.insert(obj_Aluno); long id = obj_Aluno.getId(); //Remove o aluno obj_Aluno = alunoDAO.buscar(new Aluno(id)); assertNotNull(obj_Aluno); alunoDAO.remove(obj_Aluno); //Verifica se foi removido obj_Aluno = alunoDAO.buscar(new Aluno(id)); assertNull(obj_Aluno); } }}} 9. Altere também o teste para o método de consulta. {{{ @Test public void testListarList() { List lista = new ArrayList(); lista = alunoDAO.listar(); for (Aluno varios : lista ) { System.out.println(varios.getId()); } assertTrue(lista.size()>0); } }}} Para este teste serão necessários os seguintes imports: {{{ import java.util.List; import java.util.ArrayList; }}} {{{ * Importante: O teste de Listagem só terá sucesso, se estiver após o teste de inclusão. Ou ainda após a primeira execução dos testes. }}} 10. Os outros testes estarão como //assertTrue//(**false**), e portanto deverão falhar. Para o exercício proposto os testes que foram implementados são suficientes para testar a camada DAO. 11. Após as alterações execute o comando CLEAN do Eclipse. Menu Project-> Clean … {{Clean.png}} //Figura 22: Eclipse Clean// 12. Rode os testes e verifique seus resultados. {{Run_JUnit.png}} //Figura 23: Executar JUnit// Perceba que em os resultado em verde ocorreram com sucesso. {{JUnit_ok.png}} //Última Figura: Testes OK// === Exercício 2.5 – Criação de DAO Stub e Fábrica Customizada === 1. Criar uma nova implementação para a interface IAlunoDAO chamada AlunoDAOStub. Esta classe armazenará os dados em memória. Dica: {{{ public class AlunoDAOStub implements IAlunoDAO { private static List listAluno = new ArrayList(); private static Long idAluno = 0l; private static Long idEndereco = 0l; }}} continue..... 2. Duplique a classe AlunoDAOTest com o novo nome AlunoDAOStubTest., altere apenas a notação do atributo IAlunoDAO conforme abaixo: {{{ public class AlunoDAOStubTest implements IFacade{ @Injection(name="br.gov.demoiselle.escola.persistence.dao.implementation.AlunoDAOStub") private IAlunoDAO alunoDAO; .... }}} 3. Rode os testes e verifique seus resultados. 4. Para a construção da fábrica customizada de Daos crie um pacote factory dentro do pacote persistence: {{{ package br.gov.demoiselle.escola.persistence.factory; }}} 5. Crie a classe EscolaDAOFactory no pacote criado: {{{ public class EscolaDAOFactory extends WebDAOFactory { @SuppressWarnings("unchecked") public IDAO create(InjectionContext ctx) { IDAO newDao = null; String className = ctx.getFieldType().getName(); className = className.replace(".dao.", ".dao.implementation."); className = className.replace(".I", "."); className += "Stub"; try { Class c = Class.forName(className); newDao = (IDAO) c.newInstance(); } catch (Exception e) { throw new RuntimeException(e); } return newDao; } } }}} 6. Volte a classe AlunoDAOStubTest, inclua a anotação @Factory para indicar que esta classe utilizará a fábrica customizada e volte a utilizar apenas o @Injection na atributo alunoDAO {{{ @Factory(factory=EscolaDAOFactory.class) public class AlunoDAOStubTest implements IFacade{ @Injection private IAlunoDAO alunoDAO; ... }}} 7. Rode os testes de unidade e verifique os resultados **Sugestão de Exercício **– Criar os testes restantes. **Créditos** **Laboratório criado por Vanderson Botellho da Silva (SERPRO/SUPST/STCTA)** **Contribuições:** **Emerson Saito (SERPRO/CETEC/CTCTA)** **Flávio Gomes da Silva Lisboa (SERPRO/CETEC/CTCTA)** **Robson Ximenes (SERPRO/CETEC/CTSDR)** **Rodrigo Hjort (SERPRO/CETEC/CTCTA)****Rafael Bomfim**

Tutorial Laboratório Módulo 1 Arquitetura 1.8

Test Test — Fri, 05 Apr 2013 23:03:23 GMT

<> **{{Laboratorio.png}}Tutorial – Módulo 01 – Arquitetura** == LABORATÓRIO 01 – Arquitetura e Configuração == Este laboratório tem por objetivo fixar os conceitos abordados no Módulo 01 do tutorial que trata as questões de arquitetura do Framework Demoiselle e orientar o processo de instalação e configuração do ambiente de desenvolvimento e da aplicações instanciadas por ele. Caso esteja optando por não utilizar a ferramenta MAVEN, utilize o documento Demoiselle-Tutorial-Modulo01-Arquitetura-Anexo-I, ao invés deste. Para o bom andamento deste laboratório, espera-se que o ambiente do desenvolvedor contenha os seguintes softwares: |=Configuração Mínima|= Software|= Versão|= Objetivo| | Compilador Java (JDK)| 1.5.0_17*| Compilação dos projetos| | Eclipse Ganymede| 3.4.2| IDE para desenvolvimento| | AspectJ Development Tools for Eclipse| 1.6.4| Compilação de aspectos| | Maven Integration for Eclipse| 0.9.7*| Integração com projetos Maven| | Servidor de Aplicação Tomcat| 6.0.18| Servidor de aplicação Web| | Demoiselle Wizard| 1.0.2| Gerador de código do Framework Demoiselle| | Jboss Tools| 3.0| Kit de acessórios para desenvolvimento| === Objetivos: === * Criar e configurar projetos via arquétipo Maven; * Criar projeto do tutorial (projeto que terá continuidade nos demais laboratórios); * Configurar projeto via Demoiselle Wizard. {{Updates_Eclipse.png}} === Exercício 1.0 – Instalação e configuração do Ambiente: === # Baixar e instalar a JDK JAVA ([[http://java.sun.com/javase/downloads/index jdk5.jsp|http://java.sun.com/javase/downloads/index jdk5.jsp]]), também é possível utilizar JAVA 6, mas mantendo a compatibilidade com JAVA 5. # Baixar e instalar a IDE Eclipse Ganymede ([[http://www.eclipse.org/ganymede/|http://www.eclipse.org/ganymede/]]). # Inicie o uso do Eclipse. # Já no interface do Eclipse utilize a opção de Software Updates: Menu-> Help-> Software Updates. # # Utilize a opção **Add Site..**. (figura 1) para instalar os seguintes softwares: ## AspectJ Development Tools for Eclipse ([[http://download.eclipse.org/tools/ajdt/34/update|http://download.eclipse.org/tools/ajdt/34/update]]) ## Maven Integration for Eclipse ([[http://m2eclipse.sonatype.org/update/|http://m2eclipse.sonatype.org/update/]]) ## Demoiselle Wizard ([[http://demoiselle.sourceforge.net/wizard/updatesite|http://demoiselle.sourceforge.net/wizard/updatesite]].) ## JBoss Tools ([[http://download.jboss.org/jbosstools/updates/stable|http://download.jboss.org/jbosstools/updates/stable]]) === Exercício 1.1 – Arquétipo Demoiselle === ==== 1. Configuração do repositório Maven: ==== * Abra o Eclipse. ** A primeira vez que plugin do Eclipse (m2) é instalado, o repositório local é criado na pasta .m2, que fica na Pasta do Usuário (USER_HOME). No Windows, normalmente fica em “C:\Documents and Settings\$USER_HOME\.m2\”; no Linux, em “/home/$USER_HOME/.m2/”). //Dica//: A pasta .m2 é protegida, portanto pode não estar visível por padrão. Para acessá-la, se estiver numa máquina Windows, configure a exibição de arquivos ocultos. No Linux, utilize as teclas Ctrl+H para exibir e esconder arquivos ocultos. * No seu repositório local ($USER_HOME/.m2) crie o arquivo **archetype-catalog.xml** e copie o conteúdo abaixo. {{{ br.gov.component.demoiselle.archetypes demoiselle-archetype-webapp-sample 1.0.0 http://demoiselle.sourceforge.net/repository/release }}} ==== 2. Criando um novo projeto ==== * Volte ao Eclipse é acione o menu: File → New → Project... ** Selecione a opção //Maven Project (figura 2):// {{Selecao_projeto_maven.png}} //Figura 2: Seleção de projeto Maven// * Na próxima tela é possível configurar o local onde o projeto será criado. Mantenha sua tela conforme a figura 3 para que o projeto seja criado dentro do Workspace padrão. {{Novo_Projeto_Maven.png}} //Figura 3: Criação de um novo projeto Maven a partir de arquétipo// *//Na tela seguinte (figura 4) são exibidos todos os arquétipos cadastros no archetype-catalog.xml}//**//Selecione no campo Catalog a opção: Default Local}//** Selecione a última versão do arquétipo demoiselle (//demoiselle-archetype-webapp-sample//). **** {{Config_Catalogo_Local_Maven.png}} //Figura 4: Configuração do catálogo local de arquétipos Maven// *** Vá à próxima tela. ** * Informe os dados do seu projeto.*** Group Id: representa a identificação da organização;** ** Artifact Id: representa o nome do projeto;*** Version: versão do projeto;** ** Package: pacote raiz da aplicação.**** {{Finish_Projeto_Maven.png}} //Figura 5: Parâmetros do projeto Maven// * Acione o botão //Finish// para iniciar a criação do projeto. ** Seu projeto deverá ser criado conforme estrutura da figura 6: ** {{Estrutura_Pacotes_Escola.png}} //Figura 6: Estrutura de pacotes do projeto escola// ** O Arquétipo Maven constrói uma aplicação JEE compatível com os seguintes componentes/frameworks:*** JSF Api 1.2.08 *** RichFaces 3.1.2*** Weblets Api 1.1 *** MyFaces Tomahawk 1.1.7*** JSF-Facelets 1.1.14 *** Postgresql 8.0-318*** JasperReports 3.1.0 ==== 3. Adicionando características do Wizard Demoiselle ao projeto: ==== * Clique com o botão direito sob o projeto ** Selecione o menu Demoiselle; ** Selecione: Adicionar/Remover Características Demoiselle (figura 7); {{Adicionar_Caracteristicas_Demoiselle.png}} //Figura 7: Menu adicionar/remover características Demoiselle// ** O projeto receberá o ícone do Framework Demoiselle. ** {{Icone_Demoiselle_Escola.png}} ==== 4. Configuração do servidor de aplicação (Tomcat ou JBoss) ==== * Entre nas propriedades do projeto (Project → Properties); ** Ativar profile Tomcat; *** Entre nas configurações do Maven e informe que o profile ativo: “tomcat”. {{Ativacao_Profile_Tomcat.png}} //Figura 8: Ativação do profile do Tomcat// * Para ativar o profile JBoss informe o valor “jboss” (não será utilizado neste laboratório) {{{ Caso o plugin para uso do Tomcat já esteja configurado avance ao item 5, caso contrário: }}} ** Configuração do plugin tomcat ** * Selecione o menu //Window → Preferences//} ** Na janela de preferências, selecione o item //Server → Runtime Environments//} ** Clique no botão //Add// para adicionar um novo servidor; {{Config_Server_Runtime.png}} //Figura 9: Configuração do server runtime// ** Selecione a versão 6.0 do Apache Tomcat conforme figura 10:** {{Config_Server_Runtime_Tomcat.png}} //Figura 10: Configuração do server runtime// * Marque a opção “//Also create new local server//” para criar o servidor local; ** Vá para a próxima tela (figura 11); ** No campo “//Tomcat installation directory”, informe o local onde o Tomcat foi extraído;// {{Config_Diretorio_Instalacao.png}} //Figura 11: Configuração do diretório de instalação do servidor Web// * Clique no botão //Finish// e feche a janela de preferências; ** Abra a //View Servers// (//Window → Show View → Servers//). Ela deve listar o servidor tomcat conforme figura 12: {{Inclusao_Escola_Tomcat.png}} //Figura 12: Aba Servers// ==== 5. Inclusão do projeto escola ao Plugin Tomcat: ==== * Adicione o projeto escola ao servidor Tomcat (figura 13) {{Add_Escola_Server.png}} //Figura 13: Menu Adicionar/Remover Projetos da aba Server// ==== 6. Configurando a autenticação da aplicação via Realm padrão do tomcat. ==== * No próprio eclipse abra o arquivo //tomcat-users.xml// localizado dentro do projeto “//Servers//” (figura 14) {{Arquivo_Tomcat_Users.png}} //Figura 14: Arquivo tomcat-users.xml// Crie os seguintes usuários e papéis conforme exemplo abaixo {{{ }}} * Inicie o Tomcat e verifique se aplicação foi carregada corretamente. ** Entre na url [[http://localhost:8080/escola/|http://localhost:8080/escola/]]. A página de login deverá ser exibida conforme figura 15: {{Login_Escola.png}} //Figura 15: Página de login padrão do Demoiselle// ** Autentique-se com o usuário //administrador// e senha //administrador//** A tela inicial da aplicação deverá ser exibida conforme figura 16. {{Home_Escola.png}} //Figura 16: Tela inicial padrão da aplicação Demoiselle// **Créditos** **Laboratório criado por Vanderson Botellho da Silva (SERPRO/SUPST/STCTA)** ******Contribuições:** **Emerson Sachio Saito (SERPRO/CETEC/CTCTA)** ******Flávio Gomes da Silva Lisboa (SERPRO/CETEC/CTCTA)** ******Serge Normando Rehem (SERPRO/CETEC/CTSDR)**

Orientações técnicas/Utilização do tracking (MantisBT) 1.7

Test Test — Fri, 05 Apr 2013 22:38:50 GMT

<> == Atendendo casos == === Objetivo === O objetivo principal deste documento é resumir a forma de tratamento de Casos registrados no tracker oficial do Demoiselle hospedado em [[https://sourceforge.net/apps/mantisbt/demoiselle|https://sourceforge.net/apps/mantisbt/demoiselle]]. === Termos === * Caso (Issue): É um registros no Mantis, que pode ser classificado como um Bug, para defeitos, ou Feature Request, para requisição de novas funcionalidades. * Comitador: Membros da equipe Demoiselle que tem permissão para tratar um Caso relatado, efetivando alterações em código-fonte. * Estado (Status) do Caso: Uma das situações possíveis (Anexo I) para um Caso relatado. * Projeto Mantis: Um dos projetos/subprojetos Demoiselle cadastrados no Mantis. * Relator: Qualquer usuário do que reporte um Caso no Mantis. * Responsável: Usuário atribuído ao caso. === Gestão do tratamento de Casos === No planejamento de cada Sprint de 2 semanas, a equipe Demoiselle deverá efetuar uma análise de todos os Casos novos registrados desde a último Sprint. A equipe irá definir quais Casos serão tratados durante o Sprint, planejando as novas versões que precisão ser geradas, considerando todo o Ecosistema Demoiselle (Framework, Wizard, Component e Sample). Preferencialmente a geração de versões de correção do Bug ou atendimento de Feature Requests devem ser sincronizadas com os finais de Sprint. Casos urgentes que demandem solução imediata podem surgir durante os Sprints. Essas situações serão tratadas pontualmente quando ocorrerem, quando a equipe definirá a estratégia de atuação. === Fluxo de tratamento de Casos === ==== Analisando os Casos registrados ==== Objetivo: Efetuar uma primeira revisão nos Casos para que as informações sejam validadas e, se necessários, modificadas. Ao final desta etapa a equipe deve ser capaz de melhor analisar esforço e complexidade para resolução dos Casos em aberto. # Executar Filtro no Mantis, em todos os Projetos, buscando por todos os casos que estão na situação “novo”(new) # Analisar Caso a Caso quanto a: ## Categoria: Verificar se realmente é Bug, Improvment ou Feature Request, caso seja apenas uma dúvida o usuário deve ser instruído a postar sua dúvida no fórum, ou lista. ## Projeto: Se o Caso está associado ao Projeto Mantis correto, neste caso é necessário mover ao projeto adequado. ## Gravidade: Reavaliar a gravidade do Caso está compatível. ## Prioridade: As mais altas devem ser atendidas primeiro. ## Clareza: Se o relato não estiver claro o suficiente, o Caso deve ser colocado no status Retorno (Feedback) solicitando esclarecimentos do Relator. ## Duplicidade: Se existe algum relato semelhante já cadastrado, ou atendido em outra versão do projeto, estabelecer a relação entre os casos(situação Fechado(Closed)). ## Grau de detalhamento: Após esclarecimentos percebesse que o caso precisa ser discutido com mais atenção (situação Admitido(Admited)), ### Um tópico com o título do caso deve ser criado no fórum([[http://sourceforge.net/apps/phpbb/demoiselle)|http://sourceforge.net/apps/phpbb/demoiselle)]] correspondente ao projeto. ### Notícia vinculada informando o início da discussão ### Responsável acompanha o fórum registrando cada decisão no caso ### Conclusão deve ser sintetizada em formato de anotação no próprio caso. ### Notícia vinculada informando o final da discussão ### Percebido que se trata de um novo projeto o mesmo deve ser criado no mantis e o caso deve ser migrado.(A Pertinência é avaliada neste momento) ## Pertinência: Se o Caso de fato é pertinente, e está especificado (situação Confirmado (Confirmed), não sendo pertinente(situação Fechado(Closed)). ## Previsão de resolução: Ao considerar um caso Confirmado, se possível já deve ser indicada a versão que supostamente deverá tratá-lo. Para isso deve-se utilizar o campo “Previsto para a Versão” (Target Version) disponível na Atualização Avançada (Advanced Update) do Caso. Importante: A Versão Destino deve ter sido previamente cadastrada no gerenciamento do Projeto Mantis correspondente. Até que tenha sido de fato disponibilizada, o campo “Liberada” (Released) deverá estar desmarcado. {{{ Possíveis estados de um Caso nesta fase: Novo (New),Adimitido(Admited), Confirmado (Confirmed), Retorno (Feedback). }}} ==== Atendendo um Caso ==== Objetivo: Dar o devido tratamento aos Casos registrados, de forma a melhorar a qualidade do Demoiselle mantendo controle das alterações efetuadas e dando visibilidade e transparência às evoluções do Demoiselle. # Executar Filtro no Mantis, em todos os Projetos, buscando por todos os casos que estão na situação “Comfirmado” (Confirmed) # Atribuir o Caso a um dos Comitadores do Demoiselle(situação Atribuido(Atributted)) # Tratar o Caso de acordo com as práticas definidas pela equipe Demoiselle durante os Sprints # Solucionar o Caso colocando na situação Resolvido (Resolved) e indicando no campo “Corrigido na Versão” a versão que efetivamente resolveu o problema. {{{ Possíveis estados de um Caso nesta fase: Atribuído (Assigned), Resolvido (Resolved). }}} ==== Concluindo um Caso ==== Objetivo: Concluir os Casos registrados quando seu tratamento estiver efetivamente concluído e em Produção. Um Caso só será considerado encerrado quando: a) a versão estável que o corrige estiver oficialmente disponível; b) O Caso não foi considerado pertinente ou não demandou alterações de código (ex: Após análise se detectou que o Caso se tratava apenas de uma dúvida; neste caso o Comitador pode fechar o Caso, desde que registre os devidos esclarecimentos para o Relator). # Encerrar um Caso colocando-o no estado Fechado (Closed). {{{ Possíveis estados de um Caso nesta fase: Fechado (Closed). }}} === Registro de Mudanças (Change Log) Planejamento (Roadmap) === O tratamento aqui descrito permitira um controle efetivo das alterações efetivadas no Ecosistema Demoiselle. Duas funcionalidades do Mantis são aqui destacadas: ==== Registro de Mudanças (Change Log) ==== {{{ São exibidos aqui todas os Casos efetivamente resolvidos para cada Projeto Mantis / Versão. Esta opção é útil para acompanhar a quantidade de Casos resolvidos para cada versão do Demoiselle. }}} Link: [[https://sourceforge.net/apps/mantisbt/demoiselle/changelog_page.php|https://sourceforge.net/apps/mantisbt/demoiselle/changelog_page.php]] ==== Planejamento (Roadmap) ==== {{{ São exibidos aqui todas os Casos previstos para serem corrigidos e também os efetivamente resolvidos para cada Projeto Mantis / Versão. Esta opção é útil para acompanhar o percentual de conclusão dos Casos registrados para cada Versão, servindo também como Roadmap para toda a comunidade tomar conhecimento dos rumos futuros do Demoiselle. }}} Link:[[https://sourceforge.net/apps/mantisbt/demoiselle/roadmap_page.php|https://sourceforge.net/apps/mantisbt/demoiselle/roadmap_page.php]] === Considerações Finais === O tratamento aqui descrito contempla o fluxo principal de trabalho para as situações imaginadas mais comuns. No surgimento de excepcionalidades, a equipe deverá discutir e definir seu tratamento, incrementando este documento com as novas definições.

Orientações técnicas/Recomendacoes Programacao Orientada Testes 1.6

Test Test — Fri, 05 Apr 2013 22:36:49 GMT

<> **Recomendações para uma programação orientada a testes** **Utilização de TDD** A primeira dica é que sejam utilizados os conceitos de TDD para iniciar a implementação pelas classes de testes e a partir delas desenvolver o "esqueleto" inicial das classes principais da aplicação. Entre outros benefícios dessa prática estão a melhor cobertura dos requisitos, melhor estruturação do código, além da garantia de manutenção futura pois as classes de teste farão um tracker para a execução correta da aplicação ([[Orientações técnicas/Conceitos Gerais Testes Unitarios| Vide Conceitos gerais em testes unitários]]). **Refatoramento de código** É interessante que o desenvolvedor sempre revise o código já implementado. A construção de classes de testes para código já existente permite que o desenvolvedor possa estruturar melhor esse código, aumentar sua cobertura de requisitos, remover redundâncias, condicionais desnecessários, entre outras melhorias. Mesmo utilizando o TDD o refatoramento é presente e essencial. **Evitar lixo no código** Essa dica serve para o desenvolvimento como um todo e não somente para implementação de classes de testes. Devemos evitar deixar métodos ou parte deles comentados que não serão mais utilizados. Para isso contamos com a ferramenta de controle de versão que nos indica o que foi modificado entre as versões do mesmo artefato. Uma tendência natural durante o desenvolvimento é que as alterações no código sejam realizadas e por causa do tempo curto do desenvolvedor, esse seja realize sua cobertura nos casos de testes, fazendo com que os testes quebrem e não possibilitem que a aplicação seja compilada. Para que o build passe normalmente comentam os testes sem garantir que o código que foi alterado está correto. Isso é uma prática ruim. O ideal seria para toda alteração do código principal, rodar o caso de teste específico, e sendo o caso atualizar esse caso de teste para a cobertura correta. **Utilização da suíte de testes** Normalmente os testes unitários são realizados no momento da implementação de determinada classe, mas nas alterações futuras nem sempre o teste é executado para garantir que as mudanças na classe não geraram efeitos colaterais indesejados. É importante que sempre os testes sejam executados após qualquer alteração. Preferencialmente seria interessante que a suíte de testes fosse executada de forma automática, por exemplo em um ambiente de integração contínua. **Utilização do framework de testes mais adequado** O demoiselle atualmente conta a utilização do JUnit, Easymock e do JMockit para a realização dos testes unitários. Esses frameworks podem ser utilizados separadamente ou em conjunto dependendo da necessidade. É importante que o desenvolvedor adquira um conhecimento mais aprofundado em cada framework para saber qual deles deverá utilizar em determinada situação de forma mais objetiva evitando um trabalho desnecessário utilizando outro menos indicado.

Orientações técnicas/Quando Usar Framework Testes 1.2

Test Test — Fri, 05 Apr 2013 22:36:12 GMT

<> **Quando usar cada framework de testes durante o desenvolvimento dos testes unitários ?** **JUnit** Para utilização do JUnit integrado ao Eclipse IDE podemos tomar como base o seguinte artigo: [[http://onjava.com/pub/a/onjava/2004/02/04/juie.html|'Como utilizar JUnit com Eclipse']]. Além da documentação disponível no próprio site do projeto JUnit. No caso dos projetos utilizando o framework demoiselle, em particular o demoiselle-crud, o JUnit já é disponibilizado juntamente com o framework, o que dispensa sua instalação prévia. Vale como recomendação de boa prática que seja criado um projeto de testes anexo ao projeto em desenvolvimento. Nesse projeto de testes serão incluídos os casos de teste para cada classe desenvolvida no projeto principal. É interessante que dentro do projeto de testes a estrutura de pacotes do projeto principal seja mantida, para facilitar a navegação pelo desenvolvedor. Outra orientação de boa prática é que o nome das classes de teste sejam o mesmo nome das classes a serem testadas, exceto a terminação do nome com a inclusão da palavra Test. Exemplo: classe a ser testada ClasseGenerica.java, classe de testes ClasseGenericaTest.java. Dentro de cada classe de testes é interessante que o nome de cada caso de teste que representará um teste específico para um método da classe principal, seja um nome de faça referência ao nome do método a ser testado e o tipo de teste que está sendo realizado. Exemplo: {{{ método principal a ser testado: public void insert() caso de teste 1: public void testInsert() caso de teste 2: public void testInsertNullObject() }}} No exemplo acima temos dois casos de testes para o mesmo método insert() da classe principal a ser testada. Fica claro que método está sendo testado e o tipo de teste que está sendo realizado. Outra orientação é a inclusão de comentários no cabeçalho de cada método de testes explicando como o teste será realizado. O JUnit será utilizado para todos os casos de testes do projeto, inclusive os que utilizam o Easymock, Easymock classextendion e o JMockit, ou a combinação deles. **Easymock** No caso das bibliotecas do Easymock existirá um emprego específico do Easymock ou do Easymock Classextension dependendo do foco do teste. Para o caso de haver a necessidade de se mockar uma interface, deverá ser utilizado o Easymock. Já para os casos de haver a necessidade de mockar classes, o classextension será o indicado. A utilização do Easymock em um modo geral será nos casos em que são passadas classes ou interfaces como parâmetros dentro da chamada de métodos das classes sob testes. No caso de serem necessários mocks para classes internas ao método que está sendo testado, o indicado é se utilizar o JMockit para substituir a execução dessa classe. Outro indicador de se utilizar o Easymock é a necessidade de serem mockados somente alguns métodos e seus retornos da classe em questão. O que não acontece com o JMockit quando se trata de interfaces, onde ele força a implementação (ou pelo menos a declaração) de todos os métodos da interface. A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado. Uma limitação para a utilização do Easymock é a impossibilidade de se mockar métodos privados, estáticos e finais das classes. Segue abaixo um exemplo de utilização do Easymock nos testes das classes do demoiselle-crud. A classe sob testes é a MessageDecorator e o método que se deseja testar especificamente dessa classe é o método getLocale() Para essa caso foi criada uma classe CrudMessageDecoratorTest para a realização dos casos de testes. Veja classe abaixo. {{{ public class CrudMessageDecoratorTest extends TestCase { private ICrudMessage crudMessage; /** * Initialize test class creating a mock object from ICrudMessage interface */ @Before public void setUp() throws Exception { crudMessage = EasyMock.createMock(ICrudMessage.class); EasyMock.expect(crudMessage.getLabel()).andReturn("myLabel").anyTimes(); String key = "crud.message.ok"; EasyMock.expect(crudMessage.getKey()).andReturn(key).anyTimes(); EasyMock.expect(crudMessage.getCustomPattern()).andReturn(key.replaceAll("crud.", "app.myMB.")).anyTimes(); Locale loc = new Locale("pt", "Br"); EasyMock.expect(crudMessage.getLocale()).andReturn(loc).anyTimes(); EasyMock.expect(crudMessage.getResourceName()).andReturn("META-INF/crud-messages").anyTimes(); EasyMock.expect(crudMessage.getAppResourceName()).andReturn("messages").anyTimes(); EasyMock.expect(crudMessage.getSeverity()).andReturn(Severity.ERROR).anyTimes(); EasyMock.replay(crudMessage); } @Test public void testGetLocale() { MessageDecorator msgDecorator = new MessageDecorator(crudMessage, "test"); Assert.assertEquals("pt_BR", msgDecorator.getLocale().toString()); } } }}} Notem que no método setUp() da classe de testes foi criado um mock para a interface ICrudMessage utilizando o Easymock. Nele foram ensinados os comportamentos para diversos métodos dessa interface, bem como os retornos esperados. Já no caso de teste testGetLocale() foi passado no construtor do objeto da classe sob testes nosso objeto mock (MessageDecorator msgDecorator = new MessageDecorator(crudMessage, "test");) **JMockit** Como já foi citado anteriormente, a utilização do JMockit se faz interessante quando houver a necessidade de se mockar uma classe que está sendo utilizada internamente ao método da classe sob testes. Ou seja, essa classe não está sendo passada como parâmetro para o método que está sendo testado, porém em um determinado momento de sua execução a chamará, o que por ventura poderá ocasionar um erro dependendo do contexto do teste. Nesses casos o JMockit é recomendado, pois poderemos alterar o comportamento dos métodos que são chamados de classes terceiras que não estão sendo alvo do teste, porém estão dentro do escopo do método da classe sob testes. No caso de uso do JMockit não implica a não utilização do Easymock, pelo contrário, poderemos utilizar um mix das duas soluções em conjunto. Exemplo de utilização do JMockit juntamente com Easymock. A classe sob testes é a ResourceBundleManager e os métodos em testes são getMessage() e getCurrentLoader(). No caso do teste para o getMessage(), internamente a esse método é feito um chamado para o método getCurrentInstance da classe FacesContext. Nesse caso é indicado mockar essa classe e o comportamento do método. Para isso foi utilizado JMokit. Já para se utilizar esse método foi necessário mockar o objeto de retorno do tipo FacesContext. Nesse caso foi utilizado o Easymock para resolver a questão. Veja código abaixo. {{{ public class ResourceBundleManagerTest extends TestCase { private ResourceBundleManager bm = null; public static abstract class MockFacesContext { @Mock public static FacesContext getCurrentInstance() { FacesContext ctx = EasyMock.createMock(FacesContext.class); Application app = EasyMock.createMock(Application.class); ELContext ectx = EasyMock.createMock(ELContext.class); ValueExpression vexp = EasyMock.createMock(ValueExpression.class); EasyMock.expect(vexp.getValue(EasyMock.isA(ELContext.class))).andReturn("test"); EasyMock.replay(vexp); EasyMock.replay(ectx); ExpressionFactory exf = EasyMock.createMock(ExpressionFactory.class); EasyMock.expect(exf.createValueExpression(EasyMock.isA(ELContext.class), EasyMock.isA(String.class),EasyMock.isA(Class.class))).andReturn(vexp); EasyMock.replay(exf); EasyMock.expect(app.getExpressionFactory()).andReturn(exf); EasyMock.replay(app); EasyMock.expect(ctx.getApplication()).andReturn(app); EasyMock.expect(ctx.getELContext()).andReturn(ectx); EasyMock.replay(ctx); return ctx; } } public void setUp(){ bm = new ResourceBundleManager(); } public void testGetMessageFromResourceBundle(){ Mockit.setUpMock(FacesContext.class, MockFacesContext.class); String msg = bm.getMessage("test"); assertEquals("test", msg); } public void testGetCurrentLoader(){ NoLayers nl = new NoLayers(); ClassLoader loader = bm.getCurrentLoader((Object)nl); assertNotNull(loader); } } }}}

Orientações técnicas/JMockit 1.4

Test Test — Fri, 05 Apr 2013 22:27:02 GMT

<> **JMockit** O JMokit também é uma biblioteca utilizada para se escrever objetos mock para testes de classes java. A diferenciação do Easymock, entre outras, se dá pelo fato da possibilidade de utilizando o JMockit modificar comportamentos de classes e métodos estáticos, finais e construtores. Sendo dessa forma mais robusto e abrangente que o Easymock. O JMockit poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor, bem como em conjunto com a utilização do Easymock e do Easymock Classextension. **Instalação** Poderá ser adicionado ao projeto pelo Maven, incluindo as seguintes dependências no pom.xml: {{{ mockit jmockit 0.998 test }}} Também deverão ser configurados os determinados plugins na sessão de build para garantir a correta cópia e utilização do .jar: {{{ maven-dependency-plugin copy generate-test-resources copy mockit jmockit 0.998 jar true ${project.build.directory} ... org.apache.maven.plugins maven-surefire-plugin 2.5 -javaagent:${project.build.directory}/jmockit-0.998.jar }}} Para a instalação manual, deverá proceder o download da versão através dos links disponibilizados na página do projeto [[http://code.google.com/p/jmockit| http://code.google.com/p/jmockit]].Após descompactar, o arquivo jmockit.jar deverá ser adicionado ao classpath e no diretório de output do seu projeto.

Orientações técnicas/Práticas de Testes 3.1

Test Test — Fri, 05 Apr 2013 22:26:31 GMT

<> **Práticas de Testes** *[[Orientações técnicas/Conceitos Gerais Testes Unitarios| Conceitos gerais em testes unitários]] *[[Orientações técnicas/JUnit| JUnit]] *[[Orientações técnicas/Easymock| Easymock]] *[[Orientações técnicas/JMockit| JMockit]] *[[Orientações técnicas/Quando Usar Framework Testes| Quando utilizar cada framework de testes]] *[[Orientações técnicas/Recomendacoes Programacao Orientada Testes| Recomendações para uma programação orientada a testes]]

Orientações técnicas/Práticas de programação 2.0

Test Test — Fri, 05 Apr 2013 22:25:42 GMT

<> == Considerações gerais == O objetivo deste documento é o de fornecer aos desenvolvedores do Demoiselle algumas orientações a serem seguidas em Java visando as melhores práticas de programação. Tais práticas devem ser seguidas a fim de se garantir um bom nível de qualidade para os códigos, em ambos os termos de desempenho e de manutenibilidade destes. === Tamanho razoável dos códigos fontes === Se um arquivo de fonte do Java passa a ser grande, mais do que 500 linhas, tente reduzir o seu tamanho através da refatoração de códigos duplicados em um único método ou pela externalização do código para uma outra classe. === Granularidade dos métodos === Um número razoável de linhas para um método depende de sua complexidade. Um método formado por instruções sequenciais pode ser consideravelmente maior do que um método complexo contendo laços e estruturas condicionais. Se o código sequencial é repetitivo, tal como na inicialização índice a índice de um array, ele pode ser tão longo quanto for necessário. Porém, deve existir uma maneira mais elegante de construi-lo. Um método deve preferivelmente fazer apenas uma coisa, e o seu nome descreve tal funcionalidade. Se ele efetua diversas tarefas, tenha certeza de que estas estejam refletidas no nome do método. Se isso levar a um nome longo e complicado, é aconselhável rever a estrutura interna do seu código. Por exemplo, se você tiver um método com o nome inicializarPaginaDeGestaoELerListaContas(), provavelmente será possível dividi-lo em dois métodos: inicializarPaginaDeGestao() e lerListaContas(). === Utilização dos tipos float e double === Não utilize os tipos de dados primitivos float e double para cálculos onde a precisão dos números decimais é importante. Por causa da representação interna dos tipos de dados float e double [10], o cálculo usando números de pontos flutuantes não podem ser considerados precisos. Dada esta recomendação da IBM [11], não use os tipos simples float ou double para efetuar cálculos de números decimais onde a precisão é importante. Se necessário, a classe BigDecimal pode ser usada no lugar destes tipos. == Fornecendo acesso a variáveis de instância e de classe == Não torne uma variável de instância ou de classe pública sem uma boa razão. Frequentemente variáveis de instância não precisam ser explicitamente atribuídas ou obtidas, isso ocorre automaticamente através de chamadas a métodos. Um exemplo apropriado de variáveis de instância públicas é o caso onde a classe é essencialmente uma estrutura de dados, sem comportamento algum. Em outras palavras, se você tivesse usado uma estrutura ao invés de uma classe (se o Java suportasse "struct"), então é apropriado tornar públicas as variáveis de instância da classe. == Referenciando variáveis e métodos de classe == Evite usar um objeto para acessar uma variável ou método de classe, isto é, caso possuam o modificador static. Ao invés disso use o nome da classe diretamente. Seguem alguns exemplos: {{{ metodoQualquer(); // OK Classe.metodoQualquer(); // OK objeto.metodoQualquer(); // EVITAR! }}} == Constantes == Constantes numéricas (literais) não deverão ser codificadas diretamente, exceto para os casos -1, 0 e 1, os quais podem aparecer em um laço “for” como valores para um contador. == Atribuições de valores == Evite atribuir a diversas variáveis um mesmo valor em uma única instrução. Isso dificulta a leitura. Exemplo: {{{ fooBar.fChar = barFoo.lchar = ‘c’; // EVITAR! }}} Não use operador de atribuição em lugares onde podem ser confundidos facilmente com o operador de igualdade. Por exemplo, considere o caso abaixo: {{{ if (c++ = d++) { ... } }}} o código deveria ser escrito dessa outra forma: {{{ if ((c++ = d++) != 0) { ... } }}} Além disso, não use atribuições embutidas na tentativa de se melhorar o desempenho em tempo de execução. Isso é trabalho para o compilador e, além do mais, raramente auxilia de verdade. Por exemplo: {{{ d = (a = b + c) + r; // EVITAR! }}} Isso deve ser escrito dessa forma: {{{ a = b + c; d = a + r; }}} == Importação de pacotes == Para manter uma boa legibilidade do código, mantenha apenas importações de classes ou outros artefatos Java que estejam de fato sendo referenciados no arquivo em questão. Além disso, recomenda-se não utilizar o nome qualificado de classes internamente no código, optando pelo mecanismo de importação da linguagem Java (cláusula "import"). Procure utilizar o símbolo "*" durante a importação dos elementos de um pacote somente nos casos em que aparecerem mais de 10 artefatos a serem importados, preferindo a importação individual. == Utilização de interfaces ao invés de implementações nas declarações == Onde for possível (quando o objeto que se quer usar implementa uma interface), é melhor declarar a variável como sendo do tipo da interface ao invés do tipo da classe da implementação. Isso é particularmente aplicável às classes de coleções. Por exemplo, é melhor escrever o código abaixo: {{{ List alunos = new ArrayList(); // PREFERIDO }}} ao invés disso: {{{ ArrayList alunos = new ArrayList(); // EVITAR }}} Desta forma é possível alterar posteriormente o tipo de dados real usado com o mínimo de impacto no resto do código (por exemplo, substituir ArrayList por LinkedList). == Utilização do modificador final == Quando uma variável de classe ou de instância não é modificada em momento algum do ciclo de vida do objeto, declare esta variável com o modificador "final". Os parâmetros de um método e as variáveis locais também podem ser declarados com o "final". == Redefinição ou sobrecarga de métodos == Um método redefinido ou ou sobrecarregado (overloaded) deve oferecer a mesma funcionalidade presente na classe ancestral. Tome cuidado para não alterar o significado de um método ao redefini-lo na classe derivada. == Liberação de recursos associados a uma classe == Não confie ao método finalize() de uma classe a liberação de recursos relacionados a uma instância dela. Este método, presente na classe Object, é invocado pela JVM um pouco antes do garbage collector liberar o espaço de memória alocado para a instância. Porém, não há garantia do momento exato da execução do método finalize(), por exemplo, ele pode ser chamado somente na finalização da aplicação e prender os recursos por todo o período de execução desta. Além disso, a execução deste método depende do algoritmo do garbage collector em questão, sendo desta maneira dependente da implementação da máquina virtual usada (ex: Sun, IBM, BEA). == Cautela na utilização do método equals() == Preste muita atenção ao comportamento do método equals(). A implementação padrão dele na classe Object simplesmente compara a identidade dos objetos com o operador de igualdade "==". Algumas classes redefinem este método fornecendo-o um significado de igualdade, tal como a classe String, na qual o equals() realiza a comparação de duas strings caracter a caracter. Por outro lado, outras classes mantêm o comportamento original do método. Segue um exemplo com a classe String: {{{ String s1 = new String("Texto"); String s2 = new String("Texto"); (s1 == s2); // retorna false s1.equals(s2); // retorna true }}} Ao utilizar a classe StringBuffer o resultado é outro: {{{ StringBuffer sb1 = new StringBuffer("Texto"); StringBuffer sb2 = new StringBuffer("Texto"); (sb1 == sb2); // retorna false sb1.equals(sb2); // retorna false }}} == Redefinição do método hashCode() == Sempre redefina o método hashCode() de uma classe se o método equals() dela tenha sido reimplementado. O método hashCode() é usado pelas aplicações que fazem uso de tabelas de hash, tal como nas classes Hashtable ou HashMap, para armazenar os objetos. Para ser capaz de encontrar os objetos armazenados em um contêiner baseado em tabelas de hash, e por consequência usando o método hashCode(), é essencial que esta regra seja respeitada: {{{ Se objeto1.equals(objeto2), então objeto1.hashCode() == objeto2.hashCode(). }}} Do mesmo modo, o código hash de um objeto não deve ser alterado durante o seu ciclo de vida, e desta forma no seu cálculo não podem ser usadas informações prováveis de serem modificadas. Sendo assim, recomenda-se que apenas atributos ditos "final" do objeto sejam usados ao se calcular o seu código hash. == Escolha da implementação de listas e mapas == Priorize a utilização das implementações ArrayList e HashMap sobre Vector e Hashtable a fim de obter melhor desempenho quando acesso sincronizado não for necessário. De fato Vector e Hashtable oferecem métodos ditos "synchronized", porém eles são custosos e mais lentos de serem executados para garantir essa sincroniza ao controlar a concorrência. Na plataforma Java o Collection Framework traz as classes ArrayList e HashMap, cujas funcionalidades são as mesmas desempenhadas respectivamente por Vector e Hashtable, com a ressalva de que seus métodos não são sincronizados. == Escrevendo o tratamento de exceções == Nunca deixe vazio um bloco "catch" em instruções do tipo "try-catch", mesmo em fase dedesenvolvimento. O mínimo que se pode fazer é deixar um comentário explicando porque nada foi feito durante o "catch" ou um marcador (ex: "TODO") para lembrar que aquela parte do código não foi ainda finalizada. Geralmente utilizamos um mecanismo de logging (ex: Log4J), onde pode-se definir um nível (ex: DEBUG, INFO, ERROR) para uma mensagem enviada de dentro do "try-catch". No bloco "finally" do "try-catch", evite levantar outras exceções ou retornar prematuramente. Como por definição o bloco "finally" é executado em qualquer situação, ele o será no caso de um bloco "catch" ter levantado uma exceção. Se o próprio bloco "finally" levantar uma exceção, esta provavelmente irá esconder uma exceção levantada anteriormente no "catch". Do mesmo modo, se houver uma instrução "return" no bloco "finally", o método irá finalizar normalmente pelo "return" mesmo se o bloco "catch" tiver levantado uma exceção. == Práticas gerais na codificação == === Parênteses === O uso livre de parênteses é geralmente considerado uma boa prática, principalmente em expressões que utilizam vários operadores com o objetivo de se evitar problemas de precedência. Mesmo que a precedência do operador parece clara para você, ela pode não ser para outros – não assuma que outros programadores conheçam precedência tão bem quanto você. Seguem exemplos: {{{ if (a == b && c == d) // EVITAR! if ((a == b) && (c == d)) // PREFERIDO }}} === Retorno de valores === Tente fazer com que a estrutura de seu programa reflita a sua real intenção. Por exemplo, o código a seguir: {{{ if (expressaoLogica) { return TRUE; } else { return FALSE; } }}} deveria ser escrito desta outra forma: {{{ return expressaoLogica; }}} Similarmente, este outro código {{{ if (condição) { return x; } return y; }}} deveria ser escrito assim: {{{ return (condição ? x : y); }}} === Operador ternário === Se uma expressão contendo um operador binário aparecer antes do sinal "?" do operador ternário, ela deve estar entre parênteses. Segue um exemplo: {{{ (x >= 0) ? x : -x; }}} === Comentários especiais === Existem tags especiais de tarefas, ditas Task Tags, que servem justamente para indicar, através de comentários simples, que o código que se segue necessita de alguma correção ou conclusão. * **TODO**: para marcar que há uma tarefa pendente de início ou conclusão no código fonte abaixo do comentário; * **FIXME**: para marcar que há algo incoerente no código e que precisa de correção urgente; * **XXX**: para marcar que existe código fora dos padrões, não elegante ou sem garantia de desempenho, porém que funciona. Essas tags geralmente são interpretadas pelo ambiente de desenvolvimento e suas indicações aparecem em visões e janelas apropriadas para que o desenvolvedor possa gerenciar o respectivo código defeituoso ou incompleto. Eis alguns exemplos de utilização dessas tags: {{{ // TODO: Terminar a codificação da leitura do arquivo boolean leuArquivo = Classe.abrirArquivo("teste.properties"); }}} {{{ // FIXME: Verificar erro durante execução do método String resultado = Classe.metodoQualquer(100); }}}

Orientações técnicas/JUnit 1.3

Test Test — Fri, 05 Apr 2013 22:18:31 GMT

<> **JUnit** Para entendermos o JUnit precisamos entender dois conceitos fundamentais utilizados em Testes de Caixa Branca. São eles os conceitos de: Driver e Stub. Driver é um módulo de software utilizado para executar um determinado módulo de teste em um código específico a ser testado. Frequentemente provê os dados de entrada para os testes, controles utilizados para a realização dos testes, monitora a execução dos testes e fornece relatórios de saída com os resultados dos testes realizados. Stub é módulo que simula um componente que ainda não foi desenvolvido e necessita ser utilizado no teste, formalmente definido como uma declaração substituta de parte do programa que será definida em outra ocasião. Em outras palavras, o driver é o veículo utilizado para se realizar os testes e o stub serve de atalho para que os testes não precisem esperar uma determinada implementação para que possam ser realizados. O JUnit é um framework opensource [[http://www.junit.org|http://www.junit.org]], criado por Eric Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java. Ele será utilizado como driver para os testes unitários a serem realizados no software sob testes. Esse framework facilita a criação de código para a automação de testes unitários com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão. **Instalação** Para se instalar o JUnit deve-se baixar o seu .jar da página do projeto [[http://www.junit.org|http://www.junit.org]] e incluir no classpath de seu projeto. No caso de projetos que utilizam o Maven, como é o caso dos projetos demoiselle, deverá ser colocada a seguinte dependência no arquivo pom.xml: {{{ junit junit 4.5 test }}}

Orientações técnicas/Geração de release v1 2.3

Test Test — Fri, 05 Apr 2013 22:12:40 GMT

<> == Liberação de versão (release) com o novo build == Este tutorial explica o processo de liberação de versão (release), subdividido em duas etapas: * **Preparação**: ** Identificar os projetos que estão prontos para serem liberados; ** Atualizar as notas de versão do projeto e consolidá-las no Subversion. * **Execução**: ** Baixar o projeto consolidado diretamente do Subversion; ** Gerar a baseline (tag) no Subversion; ** Gerar e publicar os produtos da baseline: Repositório Maven, Site do Projeto e Pacote para download no SourceForge. === Ferramentas === As seguintes ferramentas são necessárias: * IDE de sua preferência; * Maven >= 2.0.x; * Subversion >= 1.4.x. === Convenções === * SF_PROJECT: Nome do projeto no SourceForge (e.g. component, wizard, sample, framework) * PROJECT: Nome do subprojeto (ex: demoiselle-mail, demoiselle-jsf-ui, escola, auction5) * VERSION: Versão do subprojeto (ex: 1.0.6) * USERNAME: Nome do usuário do SourceForge * PASSWORD: Senha da conta do SourceForge === Preparação === Recomenda-se que a etapa de preparação seja feita com auxílio de uma IDE. * Baixar o projeto: ** Utilizando a IDE, baixe o projeto do repositório Subversion: {{{ https://demoiselle.svn.sourceforge.net/svnroot/demoiselle/${SF_PROJECT}/trunk/${PROJECT} }}} * Identificar no Mantis os projetos prontos para liberação: ** Acesse a aba [[http://sourceforge.net/apps/mantisbt/demoiselle/roadmap page.php|“Planejamento (Roadmap)”]]; ** Identifique os projetos que estão 100% concluídos. * Atualizar o release-notes do projeto com base no [[http://sourceforge.net/apps/mantisbt/demoiselle/roadmap page.php|“Roadmap”]]: ** Acesse o arquivo **release-notes.apt** e certique-se que está coerente com o Roadmap do projeto. Caso não esteja, atualize-o com as informações do Roadmap seguindo o seguinte padrão: {{{ * ../1.1.0 * http://sourceforge.net/apps/mantisbt/demoiselle/view.php?id=148: [Feature] Refatorar mecanismo de injeção. }}} ** Faça o mesmo com o release-notes.apt do site em inglês (se existente);** Efetue o commit para consolidar as modificações do projeto no Subversion. * Configurar o arquivo **settings.xml** do Maven: ** Abra o arquivo settings.xml do repositório Maven local (e.g. ~/.m2/settings.xml); ** Caso não exista, defina uma seção para o projeto: {{{ demoiselle.sourceforge.net ${USERNAME},${SF_PROJECT} ${PASSWORD} 664 775 ... ... }}} **OBS:** Para garantir a confidencialidade de suas informações e segurança do projeto, siga este o passo-a-passo ([[http://maven.apache.org/guides/mini/guide-encryption.html)|http://maven.apache.org/guides/mini/guide-encryption.html)]] para criptografar a sua senha no arquivo 'settings.xml'. Caso você tenha configurado acesso ao SourceForge via **Chaves SSH** (vide guia em [[https://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys)|https://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys)]] a tag contendo a senha pode ser omitida no arquivo **settings.xml**. === Execução === Para evitar incompatibilidade entre as versões dos plug-ins da IDE e as versões das ferramentas de linha de comando, esta seção do passo-a-passo deve ser executada exclusivamente via **linha de comando**. * Criar um diretório vazio para hospedar o projeto. {{{ mkdir temp cd temp }}} * Fazer o checkout do projeto para a pasta local **release**. {{{ svn checkout https://demoiselle.svn.sourceforge.net/svnroot/demoiselle/${SF_PROJECT}/trunk/${PROJECT} release }}} **OBS:** Não reutilize o mesmo diretório local que você escolheu na etapa de **Preparação** utilizando a IDE, pois pode gerar incompatibilidade das versões do Subversion (IDE x linha de comando). * Acessar a pasta **release**. {{{ cd release }}} * Abrir uma conexão com o shell do SourceForge em um **novo terminal**: ** Abra um novo terminal e execute o seguinte comando: {{{ ssh -t @shell.sourceforge.net create }}} * Gerar e publicar a baseline (tag) e seus produtos: ** Volte para o primeiro terminal e execute o seguinte comando para gerar a baseline (tag) no Subversion: {{{ mvn release:prepare -Dusername=${USERNAME} -Dpassword=${PASSWORD} }}} ** Execute o seguinte comando para gerar e publicar os produtos da baseline (e.g. Repositório Maven, Site do Projeto e Pacote para download no SourceForge):** {{{ mvn release:perform -Dusername=${USERNAME} -Dpassword=${PASSWORD} }}} Devido a problemas de conexão ao SourceForge, a geração de release via Maven muitas vezes é interrompida no meio do processo e somos obrigados a executar o comando novamente. Para automatizar esse processo, abra o shell do SF em um terminal (timeout de 4 horas) e execute a instrução abaixo: {{{ while ! mvn -e release:perform; do date; echo "Rodando de novo..."; sleep 60; done }}} * Rotular os arquivos para download no SourceForge: ** Acesse o gerenciador de arquivos do projeto no SourceForge; ** Acesse o arquivo /${PROJECT}/${VERSION}/${PROJECT}**-bin.zip**: *** Coloque a descrição: **Binaries and required libraries**; *** Marque todas as plataformas; ** Acesse o arquivo /${PROJECT}/${VERSION}/${PROJECT}**-src.zip**: *** Coloque a descrição: **Source code files**; * Atualizar os casos no Mantis para o status FECHADO. * Atualizar a versão do projeto no Mantis como liberada e criar a versão seguinte. === Arquétipos === No caso dos arquétipos, é preciso atualizar o seguinte arquivo XML correspondente ao catálogo: {{{ http://demoiselle.sourceforge.net/repository/archetype-catalog.xml }}}