Diferenças

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

--- pres:gerti:documento_de_arquitetura_de_software [14/07/2022 14:24] – criada bholiveira
+++ pres: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 ======
@@ Linha 32: / Linha 32: @@
 As soluções de software serão criadas com base no seguinte modelo arquitetural de projetos que segue:
+{{:pres:gerti:pasted:20220714-142530.png}}
 Figura 1 - Arquitetura de Pacotes
 Essa infraestrutura de informação está consolidada na solução TCE.Compartilhado, a qual servirá como especificação de objetos de negócio a partir da herança da classe abstrata “ObjetoPersistido.”, também especifica o contrato padrão das interfaces de repositório e de serviço, bem como as classes de implementação padrão de repositório e de serviço, “RepositorioGenerico” e “ServicoPadrao”, respectivamente.
 A implementação padrão do repositório realiza as principais operações de CRUD com o banco de dados, como apresentado no diagrama abaixo:
+{{:pres:gerti:pasted:20220714-142547.png}}
 Figura 2 - Diagrama de Classes - Repositório
 Já a implementação padrão do serviço além de realizar as principais operações de CRUD, executa nas operações padrão de manipulação dos objetos (DTOs), as validações padrão, definidas na classe padrão de validação, “ValidadorPadrao”. Por esse motivo, todo serviço que herde da implementação padrão do serviço, deverá ter uma classe de validação, que herde da implementação padrão dos validadores, “ValidadorPadrao”.
 A implementação padrão de validação de objetos, utiliza o framework FluentValidation, o qual possui várias funções de validação de objetos, customizadas nesta implementação padrão.
+{{:pres:gerti:pasted:20220714-142600.png}}
 Figura 3 - Diagrama de Classes - Serviço
 A UI realiza as operações com o sistemas utilizando DTOs.Cada DTO
 contem atributos e operações de acordo com as permissões de uso do usuário, seja
@@ Linha 57: / Linha 65: @@
 MVC, porem o Model será implementada pela camada de Interfaces Fábricas
 (InterfacesFabricas), através da manipulação de objetos DTO.
+{{:pres:gerti:pasted:20220714-142615.png}}
 Figura 4 - Fluxo MVC
 Os controladores executam as operações através dos serviços implementados, fazendo a chamada sempre via contrato (interface). Por esse motivo, as UIs não conhecem a implementação concreta dos serviços, as chamadas dos contratos serão realizadas via fábrica (fábrica genérica ou fábrica específica) ou via Web Service.
 As Views da UI, não terão qualquer implementação de regra de negócio, devendo se limitar apenas no tratamento de apresentação dos dados ao usuário e converter as informações de entrada do usuário em objetos de transito , DTO, para que esse seja enviado na chamada da funcionalidade pelo serviço. Os serviços são responsáveis de validar as informações transitadas (DTOs), verificar as regras e controles de acesso, e executar as operações solicitadas pelo usuário através das UIs.
@@ Linha 64: / Linha 75: @@
 Essa camada é responsável por definir os contratos de operações dos serviços - interfaces de serviço, os objetos de transito (DTOs) e as fábricas de objetos e de operações.
 O projeto TCE.Compartilhado, utilizado como base de implementação para os demais produtos de software do TCE-GO, disponibiliza a fábria de instanciação de serviços em chamadas locais, a partir da fabrica genérica. Essa fábrica instancia de forma referencial, via reflexão, as implementações padrão dos serviços especificados pelos pacotes de Interfaces Fábricas dos projetos.
+{{:pres:gerti:pasted:20220714-142633.png}}
 Figura 5 - Diagrama de Sequência - Fábrica Genérica
 ==== 3.2.3. Serviço (“Servico”) ====
@@ Linha 112: / Linha 126: @@
 Partindo de uma visão top-down, cada produto de software concebido nesse modelo arquitetural, torna-se um componente de negócio que compõem a Suíte de Produtos do TCE-GO. Podemos afirmar isso, por que cada produto implantado localmente em uma solução ou disponibilizado de forma remota, está acessível a outro projeto, por meio da chamada dos serviços disponíveis no componente de negócio. Como os serviços e a infraestrutura de acesso a esses serviços, são baseadas no estilo arquitetural SOA, que estabelece a centralização das funcionalidades através do uso de Serviços de Software.
 Com base nessa análise top-dow, podemos visualizar a suíte de produtos do TCE-GO da forma representada no diagrama que segue:
+{{:pres:gerti:pasted:20220714-142656.png}}
 Figura 6 - Diagrama de Componentes - Integração dos Produtos
 ===== 3.4. Padrões =====
 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}}
 Figura 7 - Padrão Estrutural de Projetos
 Deve ser observado o padrão de nomenclatura dos projetos de cada solução (produto de software) implementada baseada nesse modelo arquitetural. Todos os projetos deve ter como prefixo, o nome “TCE.”. Esse prefixo é utilizado como identificador dos produtos que utilizam a arquitetura definida nesse documento. A partir desse identificador, e utilizando o padrão de projeto Factory Method Pattern, os serviços e repositórios disponíveis em cada produto da suíte ficarem acessíveis em qualquer produto, utilizando a função “Crie”, da Fábrica Genérica (“FabricaGenerica”), a partir da chamada via contrato (Interface).
 O padrão estrutural dos pacotes por projeto, seguirá o exemplo apresentado nos itens abaixo:
 ● 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”.
+{{:pres:gerti:pasted:20220714-142713.png}}
 Figura 8 - Padrão do Projeto InterfacesFabricas
 ● 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}}
 Figura 9 - Padrão do Projeto Servico
 ● 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}}
 Figura 10 - Padrão do Projetos de Testes
 ● Camada UI: todos os projeto UI, independente do tipo Web, Desktop ou Console terão o identificado no nome do projeto que identifica que o projeto é UI e qual o padrão utilizado, por exemplo: se for um projeto UI Web MVC, utilizando o produto Informa, o nome do projeto será “TCE.Informa.UI.MVC”. Se o produto Informa tiver uma interface UI Desktop, o nome do projeto seria “TCE.Informa.UI.Desk”. E se tivesse uma interface Console Application, o nome do projeto seria “TCE.Informa.UI.Console”. Os projetos UI Web seguindo o modelo MVC, devem respeitar a organização estrutural apresentada na figura abaixo.
+{{:pres:gerti:pasted:20220714-142813.png}}
 Figura 11 - Padrão do Projetos UI MVC
 ====== 4. Sistemática 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:
 ===== 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).
 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.
+{{:pres:gerti:pasted:20220714-142832.png}}
 Figura 12 - Cabeçalho de Classe
 ● Estrutura do código - a estrutura interna das classes serão organizadas inicialmente pelas variáveis, propriedades, métodos e por último as classes internas a classe, sendo essa última deve se restringir apenas ao escopo da classe que o contem, caso essa regra não seja atendida, a classe interna deverá ser retirada da classe mãe e ser incluída em um arquivo de classe separadamente. Partindo de uma visão macro das estruturas das classes, as varáveis, propriedades e métodos serão organizadas da seguinte forma: inicialmente as variáveis e estas se organizado com base no nível de acesso (private, internal, protected e public), posterior mente as propriedades e métodos, organizados com base no nível de acesso de cada estrutura, inicialmente pelo acesso, público estático, em seguida o acesso público não estático, seguido pelo acesso interno, protegido e por ultimo pelo privado. A organização entre as estruturas do mesmo tipo são apresentados abaixo:
 ○ Variáveis - as variáveis de escopo da classe serão organizadas na seguinte ordem: variáveis constantes serão as primeiras iniciadas a partir das públicas, seguida das internas, posteriormente as protegidas e por fim as privadas. Já as variáveis diferente de constantes serão ordenadas após as constantes em ordem de acesso iniciadas a partir das públicas, seguida das internas, posteriormente as protegidas e por fim as privadas.
@@ Linha 147: / Linha 184: @@
 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.
 ● 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.
 ● 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”.
 ● 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.
@@ Linha 177: / 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.
 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}}
 Figura 13 - Estrutura do projeto TCE.Compartilhado
 O projeto TCE.Compartilhado foi desenvolvido na primeira versão da proposta de arquitetura dos softwares do TCE-GO. Essa versão diferente da proposta desse documento, os pacotes Negócio, Repositório e Serviço eram projetos separados. Na proposta desse documento, esses três projetos são organizados em um único projeto, e suas estruturas são organizadas em pacotes separados com os nomes do que antes eram projetos, pacotes de Negócio, Repositório e Serviços, como podemos visualizar na Figura 7 e na Figura 9.
 ===== 5.2. TCE.Componentes =====
@@ Linha 185: / Linha 230: @@
 Atualmente, esse projeto define o padrão do pacote visual UI MVC, para projetos Web que utilizam a tecnologia Asp.Net MVC na versão 4.5 e 5. Esse componente visual está presente em vários projetos, em que um dos componentes mais utilizado é o componente de Login e o componente de Categoria Download.
 Estruturação da arquitetura proposta nesse documento, incluído os projetos de infraestrutura e componentização, está demonstrada na figura abaixo:
+{{:pres:gerti:pasted:20220714-142933.png}}
 Figura 14 - Arquitetura da Informação - Suíte de Produtos
+{{:pres:gerti:pasted:20220714-142949.png}}
 Figura 15 - Arquitetura de Pacotes
 ====== 6. Camadas ======
@@ Linha 205: / Linha 257: @@
 Nessa camada no pacote Dto, serão especificadas as classes de Objetos de Transferência de Dados, os quais devem ser utilizados pela camada de apresentação UI, para apresentar e obter as informações dos usuários para as chamadas e operações dos serviços. Todos os DTOs devem herdar da classe abstrata definida pelo projeto TCE.Compartilhado, os quais serão serializáveis para realizarem operações remotas de serviços remotos.
 Em projetos UI Web, implementados em Asp.Net MVC 4, estabelecemos um padrão organizacional dos componentes de cada estrutura como é sugerido por esse padrão. Nesses projetos o pacote Controllers contem todas as classes de controladores das Views, sendo que o nome de cada controlador, separado o sufixo “Controller”, terá uma subpasta no pacote Views, na qual terá suas Views e suas PartialViews. As Views w PartialViews contem estruturas de estilo e de script, as quais serão organizadas no pacote Componentes, na subpasta “tela”, em que cada pasta de View terá uma pasta de Componente, que contem os arquivos de estilo (.css) e o arquivo de script (.js). Nesse projeto, as fontes utilizadas são organizadas no pacote Content na subpasta “fonts”, e o estilo e script que manipula será implementado e definido pelo componente contido na pasta “custom”, localizado no pacote Componentes. Todas as imagens manipuladas pelo projeto serão organizadas na pasta Imagens, como apresentado na imagem abaixo:
+{{:pres:gerti:pasted:20220714-143012.png}}
 Figura 16 - Estrutura Projeto MVC
 ===== 6.3. Serviço =====
@@ Linha 225: / Linha 280: @@
 Esses objetos são completos, com todos os atributos de negócio, logo não tem a restrição quanto ao controle de acesso, visto que o controle de acesso é realizado pela camada de serviço, na consulta e operações da UI ou de outros serviços.
 As propriedades que representam entidades de classes persistidas não devem ser criadas como sendo do tipo “virtual”, devido o Entity Framework por padrão realizar a carga no relacionamento quando não definido como No Lazy Load. Para que as consultas no banco de dados não carreguem informações desnecessárias, a consulta em que o objeto possui relacionamento com outras entidades, caso o desenvolvedor deseje que o repositório carregue a instância correspondente no relacionamento, este deverá fazer na função de consulta personalizada ou sobrescrever a consulta padrão que deseja carregar o objeto relacionado. Para isso a consulta deverá carregar o objeto dando um Include, na referencia ou fazer um Load após a consulta, sendo o primeiro uma função na referencia da entidade através da expressão lamda (System.Data.Entity), e o segundo uma função do Entity Framework, como apresentado abaixo:
+{{:pres:gerti:pasted:20220714-143030.png}}
 Figura 17 - Exemplo Load Entidade Relacionada
+{{:pres:gerti:pasted:20220714-143037.png}}
 Figura 18 - Exemplo Include Entidade Relacionada
 ====== 7. Ferramentas e Tecnologias ======