Vinícius Mussak

Fala galera! Tudo certo?

Continuando a série de posts sobre a certificação 70-486, hoje vamos falar sobre o planejamento da separação dos conceitos (SoC – separation of concerns), que nada mais é do que um princípio que visa a preocupação com cada responsabilidade da aplicação separadas em módulos, onde cada módulo tem uma responsabilidade diferente.

Separação de responsabilidades

Ao separar os módulos, cada um deles pode encapsular a informação que pode ser desenvolvida e atualizada de forma independente. Um exemplo de SoC, é o desenvolvimento N-tier, onde a interface de usuário (UI), as regras de negócio, e o acesso ao banco de dados ficam em camadas diferentes.

Um termo bastante associado com SoC é o baixo acoplamento, que é uma abordagem de arquitetura onde o objetivo é limitar a quantidade de interdependência entre as várias partes de um sistema.

E por quê fazer isso?

Ao reduzir as interdependências, a mudança em uma área da aplicação tem menos probabilidade de afetar outra área. Além disso, com a eliminação das interdependências, você tem um sistema mais granular e com isso ganhamos uma aplicação testável, flexível e com maior manutenibilidade, logo, uma aplicação mais estável.

Métricas de separação de responsabilidades

Já sabemos que SoC é a capacidade de identificar, encapsular e manipular as partes
de um software que são relevantes para uma preocupação especial; até aí tudo bem, agora vamos ver algumas métricas referentes à isso:

• Difusão de responsabilidades em Componentes (CDC – Concern Diffusion over Components):
  • Definição: CDC é uma métrica de projeto que conta o número de “componentes primários” que contribuem com a implementação de uma responsabilidade; também conta o número de componentes que acessam os componentes primários, ao se referirem a eles em declarações de atributos, parâmetros formais, tipos de retorno, declarações levantadas e variáveis locais ou chamando seus métodos.
  • Relevância:  Essa métrica mede o grau com o qual uma responsabilidade de um sistema mapeia os componentes no projeto do software. Quanto mais diretamente uma responsabilidade mapear para os componentes, mais fácil será entender o projeto. Ou seja, menos componentes serão alterados durante as atividades de manutenibilidade ou menos componentes serão modificados durante as atividades de reutilização.
• Difusão de responsabilidades em Operações (CDO – Concern Diffusion over Operations):
  • Definição: CDO conta o número de “operações primárias”, ou seja, as operações cujo objetivo principal é contribuir para a implementação de uma responsabilidade. Ela também conta o número de métodos que acessam as operações primárias, chamando seus métodos ou usando-os em parâmetros formais, tipos de retorno, declarações levantadas e variáveis locais. Os construtores também são contados como operações.
  • Relevância: Essa métrica captura o grau de entrelaçamento e espalhamento no sistema, uma vez que conta o número de operações afetadas por uma determinada responsabilidade. Quanto mais operações forem afetadas pela responsabilidade, mais difícil é entender o projeto. Portanto, é mais difícil reutilizar e mais alterações serão feitas durante as atividades de manutenção.
• Difusão de responsabilidades em linhas de código (CDLOC – Concern Diffusion over LOC):
  • Definição: CDLOC conta o número de pontos de transição para cada responsabilidade pelas linhas de código. O uso dessa métrica requer um processo de sombreamento que divida o código em áreas sombreadas e áreas não-sombreadas. As áreas sombreadas são linhas de códigos que implementam uma certa responsabilidade. Não vou entrar em detalhes sobre o sombreamento para não estender muito e também creio que não seja pedido no exame.
  • Relevância: Quanto mais alta a CDLOC, mais intermisturado estará o código da responsabilidade com a implementação de outras responsabilidades nos componentes; quanto mais baixa a CDLOC, mais localizável será o código. Quanto mais entrelaçado e espalhado for uma responsabilidade, mais difícil será entender o código, mais linhas de código serão afetadas durante as atividades de evolução e mais difícil será reutilizar o código. As medições da CDLOC são relativas às responsabilidades que foram buscadas e o método para contar os pontos de transição. Qualquer pequena variação desses dois fatores resulta em alterações drásticas das medidas.

Galera, dessa vez não tem exemplo de código, e nem repositório no GitHub, o post foi bem teórico, não gosto muito de deixar assim, mas se entrarmos em detalhes nisso, vai dar outra série, e hoje queremos estudar para a certificação 70-486, certo?

Então por hoje é só, qualquer dúvida ou sugestão, estou à disposição! Até mais 😀