...
| Numbered Headings | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
IntroduçãoEste documento é o balizador do controle de qualidade de artefatos produzidos no 3PUP. Ele contém critérios de qualidade a serem seguidos para construção de interfaces de usuário, código-fonte e processo de testes do sistema a ser entregue.
Interface de UsuárioEsta seção cobre critérios de qualidade esperados para as interfaces de usuário do sistema. Como interface de usuário podem ser consideradas telas da aplicação, dispositivos de acionamento óptico, som, movimento ou qualquer outra interface de entrada ou saída de informação do sistema. Telas do SistemaO objetivo do controle de qualidade para as telas do sistema é manter uma aparência, comportamento e usabilidade consistentes ao longo de toda a aplicacao. Os critérios para checagem de qualidade das telas do sistema são (1): CHECKLIST 1: Checklist para verificação de telas de sistema
Código-FonteEsta seção apresenta os critérios de qualidade para o código-fonte e regras de compilação (ex. geração de warnings em código-fonte) do sistema.
Regras de CodificaçãoA Integrated Development Environment (IDE) para o ambiente é o EclipseIDE, na sua distribuição Juno. Opcionalmente, o JBoss Developer Studio e o SpringSource, ambas variantes do EclipseIDE são suportadas. O objetivo do controle de qualidade para as regras de codificação no ambiente de desenvolvimento é fazer com que todos os envolvidos no desenvolvimento do sistema produzam código-fonte no mesmo formato e estrutura de escrita, de forma que exista uma isonomia do código-fonte ao longo de todo o processo de desenvolvimento e manutenção, a qual seja independente de preferências pessoais, vícios de programação, habilidades e experiência do desenvolvedor entre outros fatores comportamentais sucetíveis à gostos pessoais. Independente da variante da IDE, as regras de configuração do ambiente de desenvolvimento devem seguir as premissas abaixo: CompilaçãoAs regras de configuração do compilador da IDE devem possuir as seguintes entradas:
Para ser consistente com o padrão de qualidade do projeto, as regras compilação da IDE do desenvolvedor devem seguir as configurações acima. Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor devem ser idênticas às acima. Limpeza de Código-Fonte (Clean Up)A limpeza de código-fonte diz respeito aos padrões para eliminação de conteúdo desnecessário ou incorreto dentro do código-fonte do sistema, tais como espaços em branco, falta de modificadores final em variáveis, ausência ou uso incorreto de de anotações @Overide, @SupressWarings e entre outras, além de conversões desnecessárias, importações de dependências desnecessárias ou em nível de profundindade (*) desapropriados, linhas em branco, tabulações e identações incorretas, entre outrosetc... As regras de configuração para limpeza de código-fonte da IDE são assim definidas:
Para aplicar as regras de limpeza de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, via menu Window :
Ao final da configuração, a tela deve estar igual a imagem abaixo:
Modelos de Código-Fonte (Code Templates)Modelos de código-fonte dizem respeito à padrões para estruturas como blocos de código-fonte, conteúdos padrões para métodos get e set, para construtores, para tratamento padrão de erros, entre outros. Também define padrões para escrita de comentários em código-fonte, como cabecalhos de arquivo, Javadoc para classes, variáveis, métodos, sobreescrita de métodos, delegação de chamadas, entre outros. As regras de codificação para modelos de código-fonte, incluindo os comentários, são definidas no arquivo abaixo:
Para aplicar as regras de modelos de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, no menu Window > Preferences > Java > Code Style > Code Templates, opção Import. E, certifique-se que a opção Automatically add comments for new methods and types na tela relacionada, conforme abaixo:
Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras modelos de código-fonte da IDE do desenvolvedor devem seguir as configurações acima. Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor, bem como as estruturas finais geradas a partir destes modelos (ex. o conteúdo de um metoto getter) devem continuar consistentes com este padrão. Formatação de Código-Fonte (Formatter)As regras de formatação de código-fonte dizem respeito à padronização da estrutura de apresentação dos fontes do sistema. Enquanto as regras de limpeza de código discutidas anteriormente buscam ajustar o código-fonte em relação a um padrão, as regras de formatação definem este padrão. Regras como tamanho da linha de codigo-fonte, uso de espaços x tabulação, alinhamento de campos de classes, locais dos sinais de chaves de abertura de fechamento de blocos de código-fonte, uso de linhas em branco para espaçamento, identação, regras para declaração de comentários, entre várias outras. As regras para formatação de código-fonte, incluindo os comentários, são definidas no arquivo abaixo:
Para aplicar as regras de formatação de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, no menu Window > Preferences > Java > Code Style > Formatter, opção Import, conforme abaixo:
Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras formatação de código-fonte da IDE do desenvolvedor devem seguir as configurações acima. Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor, bem como as estruturas finais geradas a partir desse formato (ex. identação) devem continuar consistentes com este padrão.
Organização de Dependências (Organize Imports)A importação de dependências de pacotes e classes em Java é recurso imprescindível para o desenvolvimento de aplicações. Entretanto, a utilização incorreta de importações deriva para problemas de dependências no sistema, tais como uso de arquivos JAR desnecessários, verbosidade excessiva em código-fonte e alta acoplabilidade (pacotes que dependem indevidamente de outros pacotes) no sistema. Com o intuito de evitar ao máximo tais problemas no projeto, as regras para organização de dependências (imports) de código-fonte, são definidas no arquivo abaixo:
Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras organização de dependências da IDE do desenvolvedor devem seguir as configurações acima. Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor devem ser idênticas às acima.
Análise de Código-FonteAlém das regras de codificação utlizadas na IDE, duas ferramentas extras são utilizadas para o processo de montagem (build) da aplicação. São elas o PMD e o Checkstyle. PMDO PMD é um analisador de código-fonte. Ele localiza falhas de programação como variávies não utilizadas, blocos de tratamento de erros vazios, criação desnecessária de objetos e uma gama de outros elementos. Ele tem suporte para linguagem Java e Javascript e formatos XML e XSL. Adicionalmente, inclui suporte para deteção de "copy-and-paste" (CPD) de código-fonte, uma prática que pode ser nociva também. O CPD está disponível para Java, C, C++, C#, PHP, Ruby, Fortran, JavaScript. O PMD é altamente configurável e pode ser integrado de diversas forms nos processos de desenvolvimento. As regras de configuração da ferramenta PMD definidas para este projeto estão no arquivo de configuração da ferramenta, que pode ser acessado abaixo:
Estas regras precisam ser aplicadas nos três ramos integração contínua do projeto, Desenvolvimento, Homologação e Produção, via ferramenta de automação de build, e serem publicadas como artefato de construção. Para ser considerado aprovado o código-fonte em relação ao PMD, nenhum erro deve ser reportado no relatório de análise. CheckstyleO Checkstyle é uma ferramenta de desenvolvimento que ajuda os programadores Java a produzirem código-fonte aderente a um determinado padrão de escrita. Regras como identação, tabulação, tamanho de linhas, sintaxe de variáveis e métodos e uma série de outros elementos podem ser definidas. Ele é altamente configurável e pode suportar diferentes padrões, como o Sun Code Conventions.
Revisão de Código-FonteA revisão de código-fonte é parte da etapa de construção, ocorrendo imediateamnte após a programação e imediatamente antes do disparo dos testes. O objetivo da revisão de código-fonte é fazer uma análise do que foi codificado para garantir que nada tenha passado despercebido antes de iniciar as baterias de teste, os quais seriam perdidos ou gerariam altos índices de falha caso tal processo não tenha sido realizado. A revisão de código-fonte é uma atividade que deve ser desenvolvida obrigatoriamente por outra pessoa que não o codificador do programa. Pode ser outro desenvolvedor (conceito de programação em par) o mesmo o projetista ou arquiteto, dependendo da complexidade e outros fatores do artefato associado. Lista de Verificação de Código-FonteAs verficações que devem ser efetuadas no processo de revisão de código-fonte são assim sumarizadas: CHECKLIST 2: Checklist para Teste de Revisão de Código-Fonte.
Painel | | title | Nomenclatura||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TODO: Pablo montar expressão regular no formato: obrigatório verbo seguido de opcional substantivo seguido de opcional adjetivo e substantivo, etc... |
| Bloco de código |
|---|
Substantivo[Preposicao((Substantivo|SubstantivoConjuncaoSubstantivo)|(Adjetivo|AdjetivoConjuncaoAdjetivo)|(SubstantivoAdjetivo|SubstantivoAdjetivoConjuncaoSubstantivoAdjetivo))]* |
Exemplos:
- Cliente
- ClienteAtivo
- ClienteDoMarketing
- ClienteAtivoDoMarketing
- ClienteAtivoDoMarketingDeEmpresasDoRamoAutomobilisticoAtual
- ClienteAtivoDoMarketingEFinanceiroDeEmpresasDoRamoAutomobilisticoAtual
Nomes de Métodos
Sintaxe (apenas possui um verbo inicial frente à sintaxe de classes, o qual inicia-se em minúsculo):
| Bloco de código |
|---|
verboSubstantivo[Preposicao((Substantivo|SubstantivoConjuncaoSubstantivo)|(Adjetivo|AdjetivoConjuncaoAdjetivo)|(SubstantivoAdjetivo|SubstantivoAdjetivoConjuncaoSubstantivoAdjetivo))]* |
Exemplos:
buscar()
buscarPedido()
buscarPedidoDeUso()
buscarPedidoDeUsoDosClientes()
buscarPedidoDeUsoDosClientesAtivos()
buscarPedidoDeUsoDosClientesNovos()
buscarPedidoDeUsoDosClientesCorporativos()
buscarPedidoDeUsoDosClientesCorportativosPorNome(String nome)
Nomes de Variáveis
Sintaxe (idêntica à sintaxe de classes, porém iniciando-se em minúsculo):
| Bloco de código |
|---|
substantivo[Preposicao((Substantivo|SubstantivoConjuncaoSubstantivo)|(Adjetivo|AdjetivoConjuncaoAdjetivo)|(SubstantivoAdjetivo|SubstantivoAdjetivoConjuncaoSubstantivoAdjetivo))]* |
Exemplos:
- cliente
- clienteAtivo
- clienteDoMarketing
- clienteAtivoDoMarketing
- clienteAtivoDoMarketingDeEmpresasDoRamoAutomobilisticoAtual
- clienteAtivoDoMarketingEFinanceiroDeEmpresasDoRamoAutomobilisticoAtua
Operadores Relacionais de Quantificação
Em construção.
Esta seção visa normatizar a nomenclatura de classes, variáveis e, principalmente, métodos quando operadores relacionais de quantificação, tais como:
- buscarClientesCorporativosOndeNomeIniciaCom(parteDoNome);
- buscarClientesCorporativosOndeNomeTerminaCom(parteDoNome);
- buscarClientesCorporativosOndeNomeContem(parteDoNome);
- buscarClientesCorporativosOndeIdadeMaiorQue(idadeMinima);
- buscarClientesCorporativos(nomeIniciaCom);
- buscarClientesCorporativosOndeNomeIniciaComOuIdadeMaiorQue(parteDoNome, idadeMinima);
Observe nestes exemplos (que são apenas idéias iniciais) os casos 1 e 5. Ambos possuem a mesma semântica, porém com construção - sintaxe - diferente. Cada um possui virtudes e fraquezas. Enquanto o caso primeiro favorece a clareza da API e a construção de testes testes unitários com melhor legibilidade, o quinto favorece a flexibilidade da refatoração interna sem dependências externas (ex.substituir o parâmetro "nomeIniciaCom" por "nomeTerminaCom" não implica em refatoração de código no resto do programa - embora obviamente a semântica seria afetada seriamente).
A tendência é que o padrão 3PUP siga o primeiro caso, porém isso exigirá ainda amplo estudo.
Outras Informações
- Este padrão favore a formação de nomes semelhantes à linguagem natural, facilitando a tradução de regras de negócio em "português estruturado" e por consequência, código-fonte um-para-um com tais regras.
- Nomes longos devem ser evitados sempre que possível, através da decomposição de estruturas de código o que, por consequência, irá promover a redução da complexidade do código-fonte.
- Para casos que os nomes não podem ser decompostos, é possível utilizar conjunções como "Ou" e "E". Observe o exemplo abaixo:
| Bloco de código | ||
|---|---|---|
| ||
buscarPedidoDeUsoDosClientesCorporativosPorNomeEPorDataDeNascimento(String nome, Date dataDeNascimento)
buscarPedidoDeUsoDosClientesCoporativosPorNomeOuPorDataDeNascimento(String nome, Date dataDeNascimento) |
- Neste exemplo, o simples uso de polimorfismo não resolveria esta situação, ou seja um método
buscarPedidoDeUsoDosCliente(String nome, Date dataDeNascimento)
buscarPedidoDeUsoDosClientesCorporativosPorNomeEPorDataDeNascimento(String nome, Date dataDeNascimento)
buscarPedidoDeUsoDosClientesCoporativosPorNomeOuPorDataDeNascimento(String nome, Date dataDeNascimento)
- seria invariavelmente ambíguo!
- Observa-se que este padrão de nomes é consistente e permite construções extremamente complexas.
- Cita-se assim como exemplo o framework Grails, com atenção para
- a biblioteca Gorm de mapeamento objeto-relacional que utiliza este mesmo padrão para geração em tempo de execução de métodos de pesquisa na camada de persistencia (ex. Book.findByTitleLikeOrReleaseDateLessThan(...)).
- A outra vantagem inerente é a relação direta desses nomes com as features do sistema, que seguem o padrão AAROO ("Ator" realiza "Ação" para produzir um "Resultado" sobre um "Objeto" para atingir um "Objetivo" de negócio"), tal como exemplo "Gestor (é o ator) buscar (é a ação)
- pedidos de uso (é o resultado) dos clientes corporativos (é objeto, no caso uma lista) por nome para exportação em PDF (é o objetivo de negócio)"
- , que poderia ser traduzido no método de fachada:
| Bloco de código |
|---|
List<PedidoDeUso> pedidosDeUso = buscarPedidoDeUsoDosClientesCorporativosPorNome(nomeDoClienteCorporativo); |
Testes
| Nota |
|---|
Esta seção não foi finalizada, dado o sistema não ter, segundo o Documento de Visão de Projeto, critérios para construção e execução de testes. As informações colocadas aqui são oriundas de outros projetos e estão a título de conhecimento apenas. |
Testes para validar os critérios de aderência do sistema em relação aos seus requisitos são partes essenciais de um processo de controle de qualidade para desenvolvimento de sistemas.
Neste cenário, o Modelo V é uma referência de mercado, e é utilizado em conjuto com o Processo 3PUP da fábrica de software Redhat de Porto Alegre no seguinte formato:
Camada do Sistema | Teste | Produto testado | Demandante | Criador | Executor | Aprovador | Local | Etapa da Feature | Bloqueia |
|---|---|---|---|---|---|---|---|---|---|
Requisitos do Sistema | Testes de Aceitação | Interfaces de Usuário | Usuário | Projetista | Usuário | Usuário | Ambiente de Homologação | 95% - Em Homologação | Aprovar Homologação |
Especificações Técnicas | Teste de Sistema (ou Teste Funcional) | Interfaces de Usuário | Projetista | Projetista | Projetista | Projetista | Ambiente de Homologação | 95% - Em Homologação | Aprovar Homologação |
Arquitetura, Módulos e Pacotes | Teste de Integração | Módulos e Pacotes | Projetista | Arquiteto | Projetista | Projetista | Ambiente de Desenvolvimento | 65% - Em Construção | Aprovar Construção |
Classes e Métodos | Testes Unitários | Classes e Métodos de classe | Projetista | Desenvolvedor | Outro desenvolvedor | Projetista | IDE | 65% - Em Construção | Aprovar Construção |
Testes de Unidade
Os testes de unidade, também conhecidos testes unitários representam o menor elemento testável do sistema. Eles objetivam identificar erros em relação à codificação de classes, métodos e outros recursos mínimos da aplicação.
Os testes de unidade e seus valores de aceitação (ex. esqueletos de classes, métodos e valores) são definidos pelo projetista do módulo do sistema e são codificados pelo desenvolvedor atribuído à feature. E, para execução do teste unitário, necessariamente outro desenvolvedor, que não o codificador da classe/método/recurso deve ser o responsável, a fim de evitar vícios de trabalho.
Os seguintes elementos devem ser verificados em um teste de unidade:
CHECKLIST 4: Checlist para aprovação da construção:
Número | Elemento | Item | Teste a ser realizado | Mecanismo de teste | Status |
|---|---|---|---|---|---|
| 1 | Método público | Teste unitário primário | O método possui um teste unitário associado e este executa com sucesso ? | Biblioteca JUnit |
|
Método público | Testes unitários secundários | Se aplicável, o método possui testes unitário secundários associados e todos eles executam com suceso ? | Biblioteca JUnit |
|
Testes de Integração
A fazer.
Testes de Sistema (Funcionais)
A fazer.
Testes de Aceitação (realiado pelo Usuário)
A fazer.
Mais Informações
Nada consta.
Referências
Nada consta.
Anexos
| Anexos |
|---|