Separação de Preocupações no Desenvolvimento de Software

A Separação de Preocupações (do inglês Separation of Concerns, SoC) é um princípio fundamental de design na ciência da computação e na engenharia de software. O conceito estabelece que um problema complexo deve ser dividido em partes distintas — denominadas "preocupações" (aspectos ou questões) — que possam ser analisadas, abordadas ou gerenciadas individualmente, mesmo que façam parte de um mesmo sistema.

O objetivo principal da SoC é reduzir a carga cognitiva do desenvolvedor e a complexidade geral do sistema, permitindo que o foco seja direcionado a apenas um aspecto do problema por vez, sem a interferência de detalhes irrelevantes para aquela tarefa específica.

Formas de Implementação da SoC

A separação de preocupações não se limita apenas à estrutura do código, podendo ser alcançada de diversas maneiras:

• Temporalmente: Sequenciando atividades ao longo do ciclo de vida do software (por exemplo, separando a análise de requisitos da implementação).
• Por Qualidade: Tratando a correção do software separadamente de sua eficiência.
• Por Visão: Analisando o fluxo de dados independentemente do fluxo de controle.
• Por Tamanho (Modularidade): Dividindo o sistema em componentes menores e independentes.

Modularidade e SoC

A modularidade é a aplicação mais comum e reconhecível da SoC na estrutura de código. Em sistemas modulares, cada módulo encapsula uma única preocupação. Esses módulos são projetados, implementados e compreendidos isoladamente antes de serem compostos em um sistema maior. No entanto, a SoC é um conceito mais amplo que a modularidade; por exemplo, a separação entre requisitos funcionais e não funcionais em uma especificação é uma forma de SoC que não exige necessariamente um design modular de código.

Origem e Evolução Histórica

O termo foi cunhado por Edsger W. Dijkstra em seu artigo de 1974, "On the Role of Scientific Thought". Dijkstra argumentou que o pensamento inteligente consiste na disposição de estudar profundamente um aspecto de um assunto em isolamento, para garantir sua consistência, sabendo que se está lidando com apenas uma das facetas do problema. Para ele, tentar abordar múltiplos aspectos simultaneamente não traz ganhos e, muitas vezes, prejudica a organização do pensamento.

Anos mais tarde, a aceitação do conceito cresceu. Em 1989, Chris Reade, em "Elements of Functional Programming", aplicou a SoC ao distinguir a descrição do que deve ser computado (a lógica de negócio) das tarefas administrativas, como a organização da sequência de computação e o gerenciamento de memória. Reade defendeu que, ao automatizar a administração, os resultados tornam-se mais confiáveis e o problema de programação é simplificado.

Contribuições Teóricas

Diversos autores e modelos expandiram a aplicação da SoC:

• Carlo Ghezzi: Em "Fundamentals of Software Engineering", promove a SoC como a principal estratégia para lidar com a complexidade inerente à produção de software. Ghezzi enfatiza que a modularidade permite que os detalhes do módulo sejam resolvidos isoladamente, tratando a integração como uma preocupação distinta.
• Philippe Kruchten: Introduziu o modelo de visão "4+1", que utiliza cinco visões arquiteturais diferentes para abordar grandes arquiteturas de software. Cada visão foca em um aspecto específico, representando uma separação de preocupações baseada em visões.
• Phillip Laplante: Destacou que a SoC pode ser aplicada transversalmente ao design, à codificação, ao tempo e às qualidades do software.