As aplicações serão implementadas na última notação da tecnologia Java/JEE.
À estas regras básicas adiciona-se princípios específicos.
Os comentários das classes, métodos e variáveis deverão estar no formato Javadoc.
Os comentários de um método devem sempre mencionar as tags Javadoc:
@param
@return
@throws
devem estar de acordo com o código e possuir uma breve descrição do método.
O nome da aplicação será mencionado no nome dos pacotes no formato “gov.tjpr.<projeto>” onde <projeto> é o nome da aplicação.
Agrupar as diferentes camadas da aplicação em pacotes da maneira seguinte :
• gov.tjpr.<projeto>.client
• gov.tjpr.<projeto>.service
• gov.tjpr.<projeto>.enterprise
• gov.tjpr.<projeto>.persistence
• gov.tjpr.<projeto>.entity
Cada um dos pacote precedentes sera dividido seguidamente separando em módulos verificados na análise e confirmados na construção:
• gov.tjpr.<projeto>.client.<módulo_1>
• gov.tjpr.<projeto>.client.<módulo_2>
• gov.tjpr.<projeto>.service.<módulo_1>
• gov.tjpr.<projeto>.service.<módulo_2>
• ...
Mas se uma aplicação comportar somente um módulo, pode-se evitar indicá-lo no nome dos pacotes.
Os pacotes correspondentes à um módulo no nível da camada cliente que implementam o IHM através do Struts RF05 serão organizados da maneira seguinte:
• gov.tjpr.<projeto>.client.<módulo_1>.action : conterá as classes de ações
• gov.tjpr.<projeto>.client.<módulo_1>.form : conterá as classes de formulários “caso” sejam implementados (por padrão será utilizado o DynaActionForm mapeado)
Os relatórios do JasperReports, *.jrxml, deverão estar no pacote
• gov.tjpr.<projeto>.client.<módulo_1>.report.jasper : conterá os relatórios
Os pacotes gov.tjpr.<projeto>.service.<módulo_1> conterão as classes de serviços da camada de serviço (idem para a camada enterprise). Por padrão na raiz deste pacote existirá a interface dos serviços (visando a reutilização e desacoplamento) e dentro existirá o pacote gov.tjpr.<projeto>.service.<módulo_1>.impl com a implementação dos serviços do módulo em questão.
Os pacotes gov.tjpr.<projeto>.entity.<módulo_1> conterão as classes das entidades de negócio.
Os pacotes gov.tjpr.<projeto>.persistence.<módulo_1> conterão as classes DAO e os arquivos de configuração do Hibernate (1 arquivo por classe de entidade caso seja necessário). Na raiz deste pacote estará a interface do serviço de persistência. Dentro dele existirá um pacote hibernate com a implementação da persistência, no caso o hibernate. Dentro do pacote da implementação da persistência com hibernate haverá ainda um pacote mappings com os mapementos das entidades e/ou queries que serão realizadas através do hibernate.
Para a persistência da entidade gov.tjpr.<projeto>.entity.<módulo_1>.Cliente.java deverá existir:
i.e. persistence: gov.tjpr.<projeto>.persistence.<módulo_1>.ClienteDAO.java
i.e. hibernate: gov.tjpr.<projeto>.persistence.<módulo_1>.hibernate.ClienteDAOImpl.java
i.e. hbm: gov.tjpr.<projeto>.persistence.<módulo_1>.hibernate.mapping.Cliente.hbm.xml (caso existam queries desta entidade, o mapeamento objeto-relacional será resolvido com as anotações)
Na escrita de um método de ação, os parâmetros deverão ser nomeados mapping, form, request, response (respectivamente na ordem padrão do método execute()).
O nome de de uma classe de formulário do Struts deverá ter como sufixo Form. Lembrando que por padrão sempre deverá ser utilizado o DynaActionForm do Struts, exceto casos específicos e justificados.
O nome de de uma classe de serviço deverá ter como sufixo Service.
O nome da classe de implementação será o mesmo com o sufixo Impl.
i.e. Interface: ClienteService
i.e. Implementação: ClienteServiceImpl
O nome de uma classe de persistência deverá ter como sufixo DAO.
O nome da classe de implementação será o mesmo com o sufixo Impl.
i.e. Interface: ClienteDAO
i.e. Implementação: ClienteDAOImpl
O nome de uma classe de persistência deverá ter o nome da entidade de negócio que ele gerencia a persistência.
i.e. ClienteDAO gerencia a entidade cliente.
O nome de um método do persistência cujo objetivo seja retornar um ou mais objetos (leitura por exemplo) terá como prefixo select.
O nome de um método do persistência cujo o objetivo seja cadastrar um objeto persistente terá como prefixo insert.
O nome de um método do persistência cujo objetivo seja atualizar um objeto persistente terá como prefixo update.
O nome de um método do persistência cujo objetivo seja excluir um objeto persistente terá como prefixo delete.
Regras de Escrita do Código Java
As convenções de escrita e as regras de nomenclatura garantem uma boa parte da manutenibilidade porque facilitam definição da aplicação e favorecem amplamente o diálogo entre analistas e desenvolvedores. Por isso, devem ser respeitadas desde a fase de análise. Deve-se respeitar por padrão as convenções de código Java descritas no site da Sun.À estas regras básicas adiciona-se princípios específicos.
Comentários
O código fonte deverá ser sistematicamente comentado ao nível de classes e métodos.Os comentários das classes, métodos e variáveis deverão estar no formato Javadoc.
Os comentários de um método devem sempre mencionar as tags Javadoc:
@param
@return
@throws
devem estar de acordo com o código e possuir uma breve descrição do método.
Organização dos pacotes
Todos os pacotes deverão começar por “gov.tjpr“O nome da aplicação será mencionado no nome dos pacotes no formato “gov.tjpr.<projeto>” onde <projeto> é o nome da aplicação.
Agrupar as diferentes camadas da aplicação em pacotes da maneira seguinte :
• gov.tjpr.<projeto>.client
• gov.tjpr.<projeto>.service
• gov.tjpr.<projeto>.enterprise
• gov.tjpr.<projeto>.persistence
• gov.tjpr.<projeto>.entity
Cada um dos pacote precedentes sera dividido seguidamente separando em módulos verificados na análise e confirmados na construção:
• gov.tjpr.<projeto>.client.<módulo_1>
• gov.tjpr.<projeto>.client.<módulo_2>
• gov.tjpr.<projeto>.service.<módulo_1>
• gov.tjpr.<projeto>.service.<módulo_2>
• ...
Mas se uma aplicação comportar somente um módulo, pode-se evitar indicá-lo no nome dos pacotes.
Os pacotes correspondentes à um módulo no nível da camada cliente que implementam o IHM através do Struts RF05 serão organizados da maneira seguinte:
• gov.tjpr.<projeto>.client.<módulo_1>.action : conterá as classes de ações
• gov.tjpr.<projeto>.client.<módulo_1>.form : conterá as classes de formulários “caso” sejam implementados (por padrão será utilizado o DynaActionForm mapeado)
Os relatórios do JasperReports, *.jrxml, deverão estar no pacote
• gov.tjpr.<projeto>.client.<módulo_1>.report.jasper : conterá os relatórios
Os pacotes gov.tjpr.<projeto>.service.<módulo_1> conterão as classes de serviços da camada de serviço (idem para a camada enterprise). Por padrão na raiz deste pacote existirá a interface dos serviços (visando a reutilização e desacoplamento) e dentro existirá o pacote gov.tjpr.<projeto>.service.<módulo_1>.impl com a implementação dos serviços do módulo em questão.
Os pacotes gov.tjpr.<projeto>.entity.<módulo_1> conterão as classes das entidades de negócio.
Os pacotes gov.tjpr.<projeto>.persistence.<módulo_1> conterão as classes DAO e os arquivos de configuração do Hibernate (1 arquivo por classe de entidade caso seja necessário). Na raiz deste pacote estará a interface do serviço de persistência. Dentro dele existirá um pacote hibernate com a implementação da persistência, no caso o hibernate. Dentro do pacote da implementação da persistência com hibernate haverá ainda um pacote mappings com os mapementos das entidades e/ou queries que serão realizadas através do hibernate.
Para a persistência da entidade gov.tjpr.<projeto>.entity.<módulo_1>.Cliente.java deverá existir:
i.e. persistence: gov.tjpr.<projeto>.persistence.<módulo_1>.ClienteDAO.java
i.e. hibernate: gov.tjpr.<projeto>.persistence.<módulo_1>.hibernate.ClienteDAOImpl.java
i.e. hbm: gov.tjpr.<projeto>.persistence.<módulo_1>.hibernate.mapping.Cliente.hbm.xml (caso existam queries desta entidade, o mapeamento objeto-relacional será resolvido com as anotações)
Regras de Nomenclatura
O nome de uma classe de ação do Struts terá como sufixo Action.Na escrita de um método de ação, os parâmetros deverão ser nomeados mapping, form, request, response (respectivamente na ordem padrão do método execute()).
O nome de de uma classe de formulário do Struts deverá ter como sufixo Form. Lembrando que por padrão sempre deverá ser utilizado o DynaActionForm do Struts, exceto casos específicos e justificados.
O nome de de uma classe de serviço deverá ter como sufixo Service.
O nome da classe de implementação será o mesmo com o sufixo Impl.
i.e. Interface: ClienteService
i.e. Implementação: ClienteServiceImpl
O nome de uma classe de persistência deverá ter como sufixo DAO.
O nome da classe de implementação será o mesmo com o sufixo Impl.
i.e. Interface: ClienteDAO
i.e. Implementação: ClienteDAOImpl
O nome de uma classe de persistência deverá ter o nome da entidade de negócio que ele gerencia a persistência.
i.e. ClienteDAO gerencia a entidade cliente.
O nome de um método do persistência cujo objetivo seja retornar um ou mais objetos (leitura por exemplo) terá como prefixo select.
O nome de um método do persistência cujo o objetivo seja cadastrar um objeto persistente terá como prefixo insert.
O nome de um método do persistência cujo objetivo seja atualizar um objeto persistente terá como prefixo update.
O nome de um método do persistência cujo objetivo seja excluir um objeto persistente terá como prefixo delete.