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:33] – 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 133: Linha 133:
    
 Os projetos implementados baseados nessa arquitetura deverão seguir o padrão de nomenclatura dos projetos, o padrão estrutural de projetos (pacotes) da solução, bem como a organização estrutural dos pacotes interno dentro de cada projeto, como apresentado nas figuras abaixo:  Os projetos implementados baseados nessa arquitetura deverão seguir o padrão de nomenclatura dos projetos, o padrão estrutural de projetos (pacotes) da solução, bem como a organização estrutural dos pacotes interno dentro de cada projeto, como apresentado nas figuras abaixo: 
 +
 {{:pres:gerti:pasted:20220714-142704.png}} {{:pres:gerti:pasted:20220714-142704.png}}
  
Linha 141: Linha 142:
 ● Camada Interfaces Fábricas (InterfacesFabricas): a organização das subpastas de segundo e terceiro nível, organizadas com base no ● Camada Interfaces Fábricas (InterfacesFabricas): a organização das subpastas de segundo e terceiro nível, organizadas com base no
 propósito de cada pacote, deverá obedecer a organização dos pacotes da camada de Negócio, localizada por padrão no projeto de Serviço, no pacote “Negocio”.  propósito de cada pacote, deverá obedecer a organização dos pacotes da camada de Negócio, localizada por padrão no projeto de Serviço, no pacote “Negocio”. 
 +
 {{:pres:gerti:pasted:20220714-142713.png}} {{:pres:gerti:pasted:20220714-142713.png}}
  
Linha 146: Linha 148:
  
 ● Camada Serviços (Servico): a estrutura de pacotes utilizado no sub pacote de Negócio, também serão organizadas as classes contidas nos pacotes de “Conversores”, “Repositorio/Interfaces”, “Repositorio/Mapeadores”, “Repositorio/Repositorios”, “Servico” e “Validadores”, como apresentado na figura abaixo. ● Camada Serviços (Servico): a estrutura de pacotes utilizado no sub pacote de Negócio, também serão organizadas as classes contidas nos pacotes de “Conversores”, “Repositorio/Interfaces”, “Repositorio/Mapeadores”, “Repositorio/Repositorios”, “Servico” e “Validadores”, como apresentado na figura abaixo.
 +
 {{:pres:gerti:pasted:20220714-142720.png}} {{:pres:gerti:pasted:20220714-142720.png}}
  
Linha 151: Linha 154:
  
 ● Camada de Testes: o nome dos projetos de teste deve conter antes do nome da camada a qual será testada o prefixo “Testes”. Por padrão, os projetos de teste inicialmente serão dois, os de teste da camada de repositório e o da camada de serviço. Não obstante a isso, caso o produto de software realize integração com produtos de terceiros, nesse projeto terá outro projeto de testes cujo sufixo será “Integracao” (Integração), que será responsável por verificar as chamadas integradas dos serviços do projeto do TCE com os serviços de terceiros. Para projetos que vierem a ter teste de UI automatizado, o projeto de testes deverá respeitar o mesmo padrão de nomenclatura, por exemplo para o projeto TCE.Informa, o nome seria “TCE.Informa.Testes.UI.MVC”. Os projetos de teste de repositório deverá sempre testar a comunicação e operações reais com o banco de dados em ambiente de homologação. Já os projetos de testes de serviço, poderá mocar o repositório e outras estruturas de dados ou serviços que fogem da competência da equipe da GER-TI garantir a funcionalidade. A API de moque de objetos utilizadas pelo TCE-GO, será o RhinoMocks. ● Camada de Testes: o nome dos projetos de teste deve conter antes do nome da camada a qual será testada o prefixo “Testes”. Por padrão, os projetos de teste inicialmente serão dois, os de teste da camada de repositório e o da camada de serviço. Não obstante a isso, caso o produto de software realize integração com produtos de terceiros, nesse projeto terá outro projeto de testes cujo sufixo será “Integracao” (Integração), que será responsável por verificar as chamadas integradas dos serviços do projeto do TCE com os serviços de terceiros. Para projetos que vierem a ter teste de UI automatizado, o projeto de testes deverá respeitar o mesmo padrão de nomenclatura, por exemplo para o projeto TCE.Informa, o nome seria “TCE.Informa.Testes.UI.MVC”. Os projetos de teste de repositório deverá sempre testar a comunicação e operações reais com o banco de dados em ambiente de homologação. Já os projetos de testes de serviço, poderá mocar o repositório e outras estruturas de dados ou serviços que fogem da competência da equipe da GER-TI garantir a funcionalidade. A API de moque de objetos utilizadas pelo TCE-GO, será o RhinoMocks.
 +
 {{:pres:gerti:pasted:20220714-142758.png}} {{:pres:gerti:pasted:20220714-142758.png}}
  
Linha 163: 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 177: 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. 
Linha 207: Linha 219:
 O TCE-GO possui projetos anteriores a arquitetura descrita nesse documento, chamados pela equipe da GER-TI de produtos legados. Como a demanda de migração desses projetos para essa arquitetura se dá de forma gradual, algumas estruturas de negócio do TCE-GO, foram migradas de forma pontual para a arquitetura descrita nesse documento, e foram incluídas nesse projeto, de forma temporária. Essas estruturas serão incluídas nos projetos que as mantem, quando esses projetos forem migrados para a arquitetura descrita nesse documento.  O TCE-GO possui projetos anteriores a arquitetura descrita nesse documento, chamados pela equipe da GER-TI de produtos legados. Como a demanda de migração desses projetos para essa arquitetura se dá de forma gradual, algumas estruturas de negócio do TCE-GO, foram migradas de forma pontual para a arquitetura descrita nesse documento, e foram incluídas nesse projeto, de forma temporária. Essas estruturas serão incluídas nos projetos que as mantem, quando esses projetos forem migrados para a arquitetura descrita nesse documento. 
 Essa abordagem de desenvolvimento será utilizada sempre que situações de necessidade exigirem essa migração parcial, para beneficiar um ou vários projetos da suíte de produtos do TCE-GO.  Essa abordagem de desenvolvimento será utilizada sempre que situações de necessidade exigirem essa migração parcial, para beneficiar um ou vários projetos da suíte de produtos do TCE-GO. 
 +
 {{:pres:gerti:pasted:20220714-142910.png}} {{:pres:gerti:pasted:20220714-142910.png}}
  
  • pres/gerti/documento_de_arquitetura_de_software.1657809220.txt.gz
  • Última modificação: 14/07/2022 14:33
  • por bholiveira