pres:gerti:documento_de_arquitetura_de_software

Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

Link para esta página de comparações

Ambos lados da revisão anterior Revisão anterior
Próxima revisão		 Revisão anterior
pres:gerti:documento_de_arquitetura_de_software [14/07/2022 14:35] – [5.1. TCE.Compartilhado] bholiveirapres:gerti:documento_de_arquitetura_de_software [14/07/2022 19:48] (atual) – bholiveira
Linha 1: Linha 1:
-====== 1. Introdução  ======+====== Documento de arquitetura de software ======
 ====== .1. Propósito ====== ====== .1. Propósito ======
    
Linha 167: Linha 167:
    
 A qualidade dos produtos desenvolvidos utilizando essa modelo arquitetural não se limita apenas na verificação e validação das regas e estruturas de dados especificados nos documentos de requisitos. Para garantir a qualidade interna e externa dos produtos de software, foram estabelecidos alguns padrões de codificação, os quais seguem abaixo organizados por visão de qualidade: A qualidade dos produtos desenvolvidos utilizando essa modelo arquitetural não se limita apenas na verificação e validação das regas e estruturas de dados especificados nos documentos de requisitos. Para garantir a qualidade interna e externa dos produtos de software, foram estabelecidos alguns padrões de codificação, os quais seguem abaixo organizados por visão de qualidade:
-{{:pres:gerti:pasted:20220714-142832.png}}+
 ===== 4.1. Qualidade Interna ===== ===== 4.1. Qualidade Interna =====
    
 A qualidade interna do produto de software será determinada quando a estrutura lógica do código, quanto a organização dos métodos e variáveis, quando a capacidade de apreensibilidade do código lido, nomenclatura de métodos e variáveis e quanto ao tamanho das estruturas (quantidade de linhas de código por método e classe).  A qualidade interna do produto de software será determinada quando a estrutura lógica do código, quanto a organização dos métodos e variáveis, quando a capacidade de apreensibilidade do código lido, nomenclatura de métodos e variáveis e quanto ao tamanho das estruturas (quantidade de linhas de código por método e classe). 
-Para estabelecer um padrão de qualidade interna dos produtos de software aderentes à arquitetura de software que trata esse documento, foi definido os seguintes padrões de código: +Para estabelecer um padrão de qualidade interna dos produtos de software aderentes à arquitetura de software que trata esse documento, foi definido os seguintes padrões de código: 
 + 
 ● Estilo de código - o padrão de estilo de código utilizado nos projetos será o padrão determinado pela Microsoft, com alterações definidas pelas estruturas de Style Cop adotadas pela equipe de desenvolvimento da GER-TI. Todo arquivo de classe de projeto deve ter o cabeçalho contendo a propriedade intelectual do TCE-GO, como apresentado na imagem abaixo.  ● Estilo de código - o padrão de estilo de código utilizado nos projetos será o padrão determinado pela Microsoft, com alterações definidas pelas estruturas de Style Cop adotadas pela equipe de desenvolvimento da GER-TI. Todo arquivo de classe de projeto deve ter o cabeçalho contendo a propriedade intelectual do TCE-GO, como apresentado na imagem abaixo. 
 +
 +{{:pres:gerti:pasted:20220714-142832.png}}
  
 Figura 12 - Cabeçalho de Classe  Figura 12 - Cabeçalho de Classe 
Linha 181: Linha 184:
 internas, protegidas e por último as provadas, sendo os construtores de classe organizados em primeira posição.  internas, protegidas e por último as provadas, sendo os construtores de classe organizados em primeira posição. 
 ○ Métodos ​- os métodos serão organizados inicialmente por métodos públicos iniciados pelos tipo estáticos, seguidos de métodos internos, protegidos e posteriormente por métodos privados. Seguindo o manual de boas práticas de construção de código, Clean Code, os métodos das classes devem ser estruturados de acordo com a dependência entre si, isto é, os métodos utilizado por um método deve ser alocado logo abaixo desse método, de modo que o código seja auto explicativo, sempre sabendo que o detalhe da execução do método vem após a chamada.  ○ Métodos ​- os métodos serão organizados inicialmente por métodos públicos iniciados pelos tipo estáticos, seguidos de métodos internos, protegidos e posteriormente por métodos privados. Seguindo o manual de boas práticas de construção de código, Clean Code, os métodos das classes devem ser estruturados de acordo com a dependência entre si, isto é, os métodos utilizado por um método deve ser alocado logo abaixo desse método, de modo que o código seja auto explicativo, sempre sabendo que o detalhe da execução do método vem após a chamada. 
 +
 ● Comentário de Bloco ​- o comentário de bloco será permitido para os métodos de interfaces e classes de forma obrigatória para os métodos públicos e facultativo para os métodos privados. Para os métodos de classes que utilizam a especificação por interfaces, o comentário do método pode ser único pela interface, ficando facultativo replicar o comentário no método da(s) classe(s) concreta(s), devendo essas serem sempre atualizadas caso o comentário sofra alterações.  ● Comentário de Bloco ​- o comentário de bloco será permitido para os métodos de interfaces e classes de forma obrigatória para os métodos públicos e facultativo para os métodos privados. Para os métodos de classes que utilizam a especificação por interfaces, o comentário do método pode ser único pela interface, ficando facultativo replicar o comentário no método da(s) classe(s) concreta(s), devendo essas serem sempre atualizadas caso o comentário sofra alterações. 
 +
 ● Comentário de Linha - o comentário de linha de código não poderá ser extenso, devendo se limitar, de forma intuitiva, a explicação do uso da estrutura comentada e seu propósito.  ● Comentário de Linha - o comentário de linha de código não poderá ser extenso, devendo se limitar, de forma intuitiva, a explicação do uso da estrutura comentada e seu propósito. 
 +
 ● Nomenclatura de Variáveis e Métodos - não existe limitação quanto ao tamanho do nome para variáveis e métodos. O nome desses estruturas deve sempre ser intuitivo de modo a facilitar o entendimento do propósito e para que serve a estrutura, dessa forma o nome das mesmas serem auto explicativas. O nome dessas estruturas que utilize mais de uma palavra, para as variáveis deve iniciar com letra minuscula e para métodos com letra maiúscula, e para ambas as palavra subsequentes a primeira deve sempre iniciar com letra maiúscula. As palavras que compõem o nome dessas estruturas deve conter ao menos duas letras, para não ferir o padrão de iniciar maiúsculo da segunda palavras em diante. O nome de métodos deve iniciar sempre com verbo, de forma a indicar a ação executada pela estrutura, como “Obtenha”, “Consulte”, “Salve”, “ExisteLancamento” etc.  ● Nomenclatura de Variáveis e Métodos - não existe limitação quanto ao tamanho do nome para variáveis e métodos. O nome desses estruturas deve sempre ser intuitivo de modo a facilitar o entendimento do propósito e para que serve a estrutura, dessa forma o nome das mesmas serem auto explicativas. O nome dessas estruturas que utilize mais de uma palavra, para as variáveis deve iniciar com letra minuscula e para métodos com letra maiúscula, e para ambas as palavra subsequentes a primeira deve sempre iniciar com letra maiúscula. As palavras que compõem o nome dessas estruturas deve conter ao menos duas letras, para não ferir o padrão de iniciar maiúsculo da segunda palavras em diante. O nome de métodos deve iniciar sempre com verbo, de forma a indicar a ação executada pela estrutura, como “Obtenha”, “Consulte”, “Salve”, “ExisteLancamento” etc. 
 +
 ● Nomenclatura de Classes - toda classe preferencialmente deve ser um TAD, de modo a representa objetos do mundo real. Porem, há possibilidade ser necessário criar classes úteis funcionais para determinada operações típicas, como classes de extensão, classes de verificação de tipos conhecidos, como validação de CPF e CNPJ, entre outras. Para isso essas classes utilitárias, deveram ser alocadas em um pacote intitulado como “Útil” ou “Utilitários”, as quais devem agrupar as funções de mesmo propósito, isto é, a classe útil de verificação de CPF e CNPJ, deve concentrar esses métodos de verificação na mesma classe que poderá ser chamada de “ValidadorUtil” ou “FuncoesUteis”. Já as classes de extensão podem ter o prefixo ou sufixo “Helper”.  ● Nomenclatura de Classes - toda classe preferencialmente deve ser um TAD, de modo a representa objetos do mundo real. Porem, há possibilidade ser necessário criar classes úteis funcionais para determinada operações típicas, como classes de extensão, classes de verificação de tipos conhecidos, como validação de CPF e CNPJ, entre outras. Para isso essas classes utilitárias, deveram ser alocadas em um pacote intitulado como “Útil” ou “Utilitários”, as quais devem agrupar as funções de mesmo propósito, isto é, a classe útil de verificação de CPF e CNPJ, deve concentrar esses métodos de verificação na mesma classe que poderá ser chamada de “ValidadorUtil” ou “FuncoesUteis”. Já as classes de extensão podem ter o prefixo ou sufixo “Helper”. 
 +
 ● Tamanho da estrutura - as classes não tem tamanho máximo fixado, porem, classes acima de 2 mil linhas de código devem ser refatoradas para ● Tamanho da estrutura - as classes não tem tamanho máximo fixado, porem, classes acima de 2 mil linhas de código devem ser refatoradas para
 classes de controle específico, de modo a granular suas operações separando por escopo. Já os métodos, devem ser o mais curto possível, tendo como tamanho máximo 200 linhas de código. Ao analisar uma estrutura, deve contar como sendo uma linha de código estruturas do tipo Linq e do tipo Lambda Expression, e também para tratamento de exceções, estrutura catch, para as tratativas que não ultrapassem 10 linhas de código por tratamento de tipo de exceção. Para operações que requerem loops e condições que atingem uma alta complexidade, estas devem ser quebras em métodos ou alteradas para funções recursisvas.  classes de controle específico, de modo a granular suas operações separando por escopo. Já os métodos, devem ser o mais curto possível, tendo como tamanho máximo 200 linhas de código. Ao analisar uma estrutura, deve contar como sendo uma linha de código estruturas do tipo Linq e do tipo Lambda Expression, e também para tratamento de exceções, estrutura catch, para as tratativas que não ultrapassem 10 linhas de código por tratamento de tipo de exceção. Para operações que requerem loops e condições que atingem uma alta complexidade, estas devem ser quebras em métodos ou alteradas para funções recursisvas. 
  • pres/gerti/documento_de_arquitetura_de_software.1657809348.txt.gz
  • Última modificação: 14/07/2022 14:35
  • por bholiveira