A Model-Driven Software Reuse Approach (in portuguese)

Neste caso, o subdomínio de cadastros apresentou um alto grau de confiança, por já existirem
linguagens e ferramentas disponíveis, e que geram código conforme requerido pelo projeto. Por
isso foi colocado no nível D4, onde inicia-se o desenvolvimento dos artefatos de produção. Nas
iterações seguintes, esse subdomínio passou para o nível D5, onde iniciou-se um projeto piloto,
e finalmente D6, onde o mesmo passou a fazer parte do domínio.
Os subdomínios de navegação e busca foram inicialmente colocados no nível D3, ficando
sob investigação, pois a confiança sobre seu sucesso dentro do domínio não era suficiente. Após
algumas iterações, porém, o subdomínio de navegação foi considerado confiável o suficiente
para iniciar a produção, que culminou com sua passagem para o nível D6. Já o subdomínio de
busca, após investigação, foi considerado excluído, passando para o nível D1.
O subdomínio de conteúdo de usuário apresentou um baixo nível de confiança inicial,
e portanto permaneceu no nível D2 para investigação posterior. Assim que todos os outros
subdomínios terem sido investigados e terem sua situação definida, este subdomínio entrou em
investigação, no nível D3. Mas após investigação, concluiu-se que o mesmo também deveria
ser excluído, terminando no nível D1. Ao final dessa evolução, o domínio passa a contar com
os subdomínios de cadastros e navegação.
Após a tomada de decisão para todos os candidatos a subdomínio, o analista do domínio
deve lidar com a sobreposição entre eles. Neste ponto, só é possível determinar se dois
subdomínios irão interferir um com o outro analisando se eles possuem features em comum.
Mesmo que não existam features em comum, pode ser que os artefatos gerados para um
subdomínio interfiram ou tenham impacto nos artefatos de outro subdomínio. E não é possível
determinar isto sem aprofundar-se no projeto e implementação.
Além disso, mesmo que não exista sobreposição de subdomínios em nenhum nível, ainda
assim a automação de um subdomínio pode afetar outros. Por exemplo, a automação de
um determinado subdomínio pode levar a mudanças/refinamentos nos requisitos, features ou
casos de uso, para dar suporte a uma nova linguagem de modelagem ou ferramenta. Dessa
forma, outros subdomínios dependentes dos mesmos requisitos, features ou casos de uso serão
afetados.
Para evitar este problema, a seguinte restrição pode ser aplicada durante a tomada de
decisões: somente um subdomínio pode estar em desenvolvimento a cada vez. Isto significa
que as decisões D4, D5 e D6 são mutuamente exclusivas. Se já existir um subdomínio sendo
desenvolvido ou testado em um projeto piloto, outros não poderão estar na mesma situação.
Isto não vale para a decisão D3, uma vez que não há problemas em se investigar
um subdomínio junto com o desenvolvimento de outro. Podem inclusive existir múltiplos
111