BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Modelagem de Domínio: os 7 maus cheiros de informação

Modelagem de Domínio: os 7 maus cheiros de informação

Favoritos

A modelagem de domínio é uma poderosa técnica do arsenal dos profissionais de TI. Mas infelizmente algumas questões a tem feito cair em desuso nos últimos anos, especialmente nos círculos ágeis. Dois problemas reais são o tempo muito grande necessário e e propensão à "parálise na análise" . Aqui apresentamos uma abordagem para a modelagem de domínio que buscar tratar esses problemas.

Discutiremos sinais que aparecem em um modelo de domínio, que demonstram a necessidade de se fazer mais perguntas. Chamamos esses sinais de "cheiros (ou maus cheiros) de informação" (information smells). Eles nos indicam que talvez não haja o entendimento completo das informações importantes do nosso domínio. Os cheiros podem indicar o esquecimento de informações do modelo, ou que nele foram inseridas informações incorretas. Focar nos cheiros de informação nos leva às perguntas que precisamos fazer, o que é um processo rápido. Quando todos os cheiros se dissiparem, ou for decidido que os remanescentes são aceitáveis, interrompemos o processo para evitar a parálise na análise.

O processo começa com a saída do sistema que entrega valor ao usuário. Tratamos então cada cheiro de informação no modelo com base na saída.

Sobre Modelos de Domínio

Um modelo de domínio é uma simplificação de aspectos de uma organização, seus produtos, operações e mercado. É especifico a uma organização e ao modo como ela opera; cria um vocabulário preciso para a organização e o seu contexto. Um modelo de domínio normalmente descreve informações de interesse do negócio. Como a maioria dos sistemas corporativos se foca em coletar, processar e prover dados, é muito útil saber o que é essa informação e ter uma forma clara de categorizá-la. Geralmente um modelo de domínio consiste de entidades de negócio com dados e comportamento associados. São também especificadas as interações de entidades de negócio. Exemplos de modelagem de domínio incluem modelos entidade-relacionamento tradicionais e modelos de objetos.

O exemplo

Usaremos um exemplo fictício, inspirado em diversos casos da vida real, para demonstrar o conceito de cheiros de informação. Um diretor de RH está tentando entender os motivos pelos quais cada desenvolvedor está sendo pago, a fim de evitar ações judiciais relacionadas às faixas salariais entre diferentes grupos demográficos. Durante a discussão em que o time buscava entender uma solicitação feita pelo diretor, surgiu o seguinte rascunho:

As melhores ferramentas para modelagem de domínio são caneta e papel, ou lapiseira e ficha de arquivo; ou ainda um marcador e quadro branco. Essas ferramentas colocam ênfase na troca de informações, em vez de focar em deixar os exemplos ou modelos com visual bonito. Mas para aumentar a legibilidade neste artigo, criamos alguns dos modelos usando uma ferramenta de diagramação:

Há conceitos importantes para se lembrar sobre os cheiros da informação e o que eles dizem quanto ao nosso modelo de domínio:

  • Os cheiros não indicam que há um problema, mas são fortes indicações de que pode haver um problema;
  • Os cheiros da informação não são tão fortes quanto regras, as quais estão sempre corretas;
  • As perguntas que os cheiros de informação revelam devem sempre ser expressadas na forma de "Me dê um exemplo de ..." em vez de "Me diga como...". Estamos procurando exemplos para explorar os detalhes do domínio, em vez de generalizações sobre o domínio que escondem os detalhes.

Então, sem mais delongas, aqui estão os principais cheiros da informação:

  1. Um item está na saída mas não está no modelo;
  2. Um item está no modelo mas não está na saída;
  3. Há dois pedaços de informação em um único lugar;
  4. Uma entidade não está relacionada a nenhuma outra entidade;
  5. Existem relacionamentos um-para-um;
  6. Há muitos relacionamentos muitos-para-muitos;
  7. Funções não-definidas.

A seguir está uma descrição mais detalhada de cada cheiro da informação.

Cheiro de informação #1 - Um item está na saída mas não está no modelo.

Todos os itens da saída precisam estar no modelo de domínio. A saída é simplesmente uma visão dos dados no modelo. Todo pedaço da informação mostrado na saída precisa ser um atributo ou método do modelo. No exemplo acima (traduzindo), Departamento, Salário Médio, Função, Salário, Sexo e Raça estão faltando no modelo de domínio. Para resolver esse mau cheiro, adicione-os como atributos ou métodos. Se não há uma entidade apropriada para pode conter esse atributos, crie uma nova entidade.

Cheiro de informação #2 - itens no modelo, que não estão na saída

Itens que estão no modelo mas não na saída são exemplos de itens colocados no modelo sem necessidade. Os analistas pensam incorretamente que precisam de um valor; "empurram" valores para dentro do modelo. Isso é perigoso, pois se acaba tendo um esforço de desenvolvimento adicional para inserir e manter esse valor. Para resolver este mau cheiro, os analistas devem perguntar ao usuário se precisam mesmo dessa informação. (O método SSADM chama esse problema de "Infomation Sink".)

Cheiro de informação #3 - dois pedaços da informação no mesmo lugar (1NF)

Manter duas partes da informação em um mesmo lugar cria problemas. O nome "John Smith" (veja figura acima) poderia ser armazenado como nome e sobrenome. É um mau cheiro? A pergunta chave seria se se deseja analisar ou processar os dois dados independentemente ou não. Isso também é conhecido como uma violação da "Primeira Forma Normal" ou 1NF.

Embora a 1NF seja uma regra de design, pode levar a descobrir que dois pedaços de dados variados são referenciados como um só. Violações da primeira forma normal são identificadas olhando como dados reais são normalmente referenciados pelo nome. Outro exemplo é a Raça que contém "Jedi" que é uma crença/religião e "IC1", que é uma classificação étnica usada pela polícia do Reino Unido.

Cheiro de informação #4 - falta de relacionamento

Todos objetos de negócio no sistema devem estar conectados. Quando não é possível identificar um relacionamento entre dois objetos de negócio, devem ser feitas as seguintes perguntas ao usuário: "Qual a relação entre esses dois itens? É um relacionamento direto, ou é feita através de outra coisa?" Este é um cheiro poderoso. Analisá-lo na maioria das vezes leva a conhecimento perdido. Em sistemas corporativos frequentemente é a estrutura organizacional que está ausente no modelo.

Cheiro de informação #5 - relacionamento um-para-um. São a mesma coisa?

Sempre que se deparar com um relacionamento um-para-um, há duas possíveis explicações: 1) O analista de negócio usou mais de um termo para a mesmo entidade e os dois objetos devem na verdade ser um só; 2) O relacionamento um-para-um deve na verdade ser um um-para-muitos mas ainda não se sabe o porquê. Por exemplo, um carro e um chofer pode ser um relacionamento um-para-um mas quando se analisa mais a fundo, descobre-se que somente um chofer pode dirigir um carro ao mesmo tempo (claro!). Muitos chofers podem dirigir o mesmo carro em horas diferentes. A informação perdida neste caso foi a natureza temporal do relacionamento.

Cheiro de informação #6 - muitos para muitos (informação perdida)

Relacionamentos muitos-para-muitos ocasionalmente representam um relacionamento válido. Na maioria das vezes, indicam um objeto de negócio do tipo "elo perdido" . No design de sofware relacional, relacionamentos muitos-para-muitos são substituídos por entidades de ligação, que algumas vezes são objetos de negócio que possuem informações sobre o relacionamento em si. No exemplo ilustrado acima, um empregado pode ter diferentes títulos de trabalho em períodos diferentes (temporal), ou pode gastar parte de seu tempos em mais de um papel. Mais uma vez, o cheiro ajuda a rastrear potenciais informações perdidas.

Cheiro de informação #7 - funções não-definidas (informações perdidas)

Todo método no modelo deve ser definido. Tudo que for referenciado dentro do método deve fazer parte do modelo de negócio. Tome como exemplo o método getAge

  • getAge calcula a idade em anos.
  • getAge = (today() - Employee.date of birth) / 365

A data de nascimento e a função que calcula a data atual estão perdidas e precisam ser adicionadas ao modelo de negócio.

Resumindo, o processo funciona assim:

  1. Identificar a saída que entregará valor ao usuário;
  2. Se ainda não há um modelo de domínio que suporte a saída, crie um modelo;
  3. Checar todos os cheiros até que não sobre nenhum no modelo;
  4. Parar.

Essa abordagem pode ser ordens de magnitude mais rápida e mais focada que a modelagem de domínio tradicional.

Exemplo passo a passo

Para fechar, vejamos um exemplo criado incrementalmente, passo a passo. Começamos com um relatório pedido pelo diretor do RH.

Cheiro 1 - Um item que está na saída mas não está no modelo.

Temos itens na nossa saída que não existem em no modelo de domínio, então os adicionamos:

Note que o salário médio é calculado com base em outros dados; então o chamamos de getAverageSalary para nos lembrar ele é um atributo calculado.

Cheiro 2 - Um item está no modelo mas não na saída

Alguém se empolgou e adicionou a data de nascimento à entidade Empregado

Perguntamos ao diretor de RH se era mesmo necessária a data de nascimento no relatório. Disseram que não, mas gostariam da idade no relatório.

Cheiro 3 - Há dois pedaços de informação em um mesmo lugar

O nome completo é composto pelo nome e sobrenome. Perguntamos ao diretor do RH se desejam que os nomes sejam separados para se distinguir pessoas da mesma família (O nome de família pode ser usado para identificar grupos culturais, por exemplo). Ele não gostou da ideia.

Cheiro 4 - Um entidade não está relacionada com nenhuma outra

Todas as entidades no modelo devem estar ligadas. Perguntamos para os especialistas no negócio se as entidades são ligadas diretamente umas com as outras ou através de alguma outra coisa. Por exemplo, o empregado está ligado diretamente ao departamento ou está em um time e o time está ligado ao departamento?

Cheiro 5 - Relacionamento um-para-um

Como relacionamentos um-para-um costumam constituir um mau cheiro, perguntamos aos especialistas no negócio sobre eles: "Poderia nos dar um exemplo de um empregado com mais de um departamento e um exemplo de departamento com mais de um empregado?"

Ao aplicar esta técnica rigorosamente pode-se gerar perguntas aparentemente bobas mas que na verdade são de bastante valor. Um exemplo: "Poderia me dar um exemplo de empregado com mais de um sexo, ou mais de uma raça?". As perguntas devem se manter abertas até se achar um exemplo para elas. Funcionam como indicadores de risco para avaliar se um sistema pode sofrer alterações.

Cheiro 6 - Relacionamentos muitos para muitos

Relacionamentos muitos-para-muitos podem indicar perda de informações. Perguntamos ao especialista de negócio o que essa informação perdida poderia ser. Neste caso, o tempo de trabalho de um empregado pode ser alocado entre um ou mais departamentos:

Para questões de função (ou papel), sexo e raça, o especialista de negócio não consegue pensar em mais nenhuma informação de valor. Então o cheiro permanece, com perguntas abertas que indicam o risco de mudança.

Um website especializado resolveu o problema do relacionamento muitos-para-muitos do sexo, incluindo classificações para cada uma das opcões (masculino, feminino, transsexual feminina, transexual masculino, intersexual). As informações perdidas poderiam ser a data em que o indivíduo decidiu realizar a operação, ou quando a operação foi realizada e o impacto que isso teve nos bônus e aumentos de salários subsequentes.

Cheiro 7 - Funções não definidas

Perguntamos ao especialista no negócio como calcular as funções getAverageSalary e getAge:

Isto leva a criação de de allocation.cost e employee.dateOfBirth, que são adicionados ao modelo.

Não há mais cheiros que sem resolução ou que tiveram seu tratamento adiado. Então podemos parar nosso processo de modelagem de domínio!

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT