Como transformar requisitos escritos em linguagem natural em uma arquitetura de software sólida e comunicável? Este material didático percorre o caminho completo: da dissecação de requisitos em substantivos e verbos, passando pela anatomia de classes UML e seus relacionamentos, até a aplicação do C4 Model como ferramenta de comunicação arquitetural em diferentes níveis de abstração. Baseado na aula do Prof.
Alexandre Gomes (UDF), o conteúdo integra conceitos de modelagem orientada a objetos com práticas modernas de documentação de arquitetura. A engenharia de software enfrenta um desafio perene: traduzir requisitos de negócio — escritos em linguagem natural, ambíguos e focados no problema — em código-fonte, que é rígido, determinístico e focado na solução. Sem um modelo intermediário que funcione como ponte entre esses dois mundos, a tradução direta frequentemente produz falhas de arquitetura que se propagam por todo o ciclo de vida do sistema (LARMAN, 2004).
Leia no AINotícia: Agenda Cultural: Shows, Teatro e Humor Agitam o Alto Tietê Neste Fim de Semana
A disciplina de modelagem estrutural existe precisamente para preencher esse abismo, oferecendo abstrações visuais que não são o sistema final, mas constituem o mapa vital para construí-lo sem desvios. Este artigo detalha o percurso metodológico apresentado na disciplina de Modelagem Estrutural de Soluções, que organiza a tradução de requisitos em quatro etapas progressivas: a construção do mapa de domínio a partir do texto bruto, a formalização em classes UML com atributos e relações, o encapsulamento em componentes escaláveis, e, por fim, a comunicação da arquitetura resultante por meio do C4 Model em diferentes níveis de abstração (BROWN, 2018). O mapa de domínio — também chamado de modelo de domínio ou modelo conceitual — é o primeiro artefato visual produzido nesse percurso.
Trata-se de uma representação gráfica dos conceitos-chave de um domínio de negócio, seus atributos essenciais e os relacionamentos entre eles, sem nenhum compromisso com detalhes de implementação. Diferentemente de um diagrama de classes técnico, o mapa de domínio utiliza o vocabulário do próprio negócio: se os usuários falam em "paciente", "consulta" e "prontuário", são exatamente esses os termos que aparecem no mapa.
Seu propósito é criar um entendimento compartilhado entre analistas, desenvolvedores e stakeholders antes que qualquer decisão de arquitetura seja tomada (LARMAN, 2004). É, em essência, a fotografia do "universo do problema" que antecede o "universo da solução". 1 Leia também: europa league
O abismo entre o negócio e o código Considere um requisito típico: "precisa calcular frete baseado em peso e destino". Essa frase, perfeitamente compreensível para um analista de negócios, carrega ambiguidades que o código não tolera: o que é "frete"? É uma entidade, um cálculo, ou ambos?
" Peso" refere-se a gramas, quilogramas ou libras? "
Destino " é uma string, um objeto complexo com coordenadas geográficas, ou uma referência a uma tabela de CEPs?
Do lado oposto, o código-fonte correspondente — uma classe CalculadoraDeFrete com um método calcular(peso: Peso, destino: Destino): Valor — é preciso demais para ser discutido com stakeholders não técnicos. O analista de negócios pergunta "como calcula o frete?
"; o desenvolvedor responde com tipos, parâmetros e retornos. Essa assimetria não é um defeito de comunicação: Mais de noticia
é uma propriedade intrínseca dos dois domínios. Requisitos em linguagem natural são, por definição, ambíguos, informais e focados no problema; código-fonte é, por construção, rígido, determinístico e focado na solução (LARMAN, 2004). A modelagem estrutural propõe um vocabulário intermediário — diagramas e notações formais — que permite a ambas as partes (negócio e engenharia) convergirem para um entendimento compartilhado antes que uma linha de código seja escrita.
2 Dissecação de requisitos: substantivos e verbos A primeira técnica concreta para construir o mapa de domínio é a análise linguística de requisitos — a chamada "análise nome-verbo" (LARMAN, 2004). O modelador percorre os textos de requisitos, casos de uso e entrevistas com stakeholders, sublinhando dois grupos gramaticais distintos.
Tomando como exemplo a frase "o paciente (cão ou gato) precisa agendar uma consulta com o veterinário, que prescreve medicamentos": Os substantivos — paciente, consulta, veterinário — são candidatos a entidades no mapa de domínio, isto é, retângulos com nome e atributos que representam conceitos do negócio. Os verbos — agendar, prescrever — são candidatos a associações (linhas de relacionamento entre entidades) ou a operações futuras quando o mapa evoluir para classes UML. Leia também: carabobo
O resultado dessa varredura é o rascunho inicial do mapa de domínio: um diagrama com as entidades identificadas, conectadas por relacionamentos nomeados a partir dos verbos encontrados. Contudo, nem todo substantivo se torna uma classe, nem todo verbo se torna um método. É necessário filtrar sinônimos e falsas entidades:
"medicamento", no contexto acima, pode ser apenas um atributo textual de uma prescrição, e não uma classe complexa com comportamento próprio. A regra fundamental é: se o conceito possui atributos independentes e comportamento que justifique encapsulamento, ele é uma classe; caso contrário, é um atributo de outra classe ou simplesmente um valor (LARMAN, 2004). 3 Anatomia de uma classe UML
Uma vez identificadas as entidades do domínio, cada uma é formalizada como uma classe UML, composta por três compartimentos. O primeiro contém o nome da classe, que representa o conceito do domínio e é sempre um substantivo (por exemplo, Consulta ). O segundo compartimento lista os atributos — o estado interno do objeto —, cada um com seu modificador de visibilidade e tipo: - dataHora: DateTime indica um atributo privado, enquanto + status:
String indica um atributo público. O terceiro compartimento apresenta as operações — o comportamento do objeto —, derivadas dos verbos identificados nos requisitos: + confirmar(): void para protegido (protected). Essa notação implementa diretamente o princípio de encapsulamento: atributos devem ser ocultos por padrão (privados), expondo apenas a interface pública estritamente necessária (FOWLER, 2003).
4 Relacionamentos UML: a matriz de diagnóstico Classes não existem isoladamente — elas se relacionam. A UML define quatro tipos fundamentais de relacionamento, cada um respondendo a uma pergunta diagnóstica específica, conforme sistematizado na tabela a seguir. |
