Recurso	J2EE Spider	AppFuse	JSenna	E-Gen
Geração incremental
Interface visual
Fácil utilização
Código internacionalizado
Geração de código customizado (templates)
Integração com a ferramenta de desenvolvimento (IDE)
Round-trip engineering

Para entender melhor esse quadro, vamos explicar textualmente alguns conceitos que foram aplicados.

• Geração incremental: consideramos geração incremental o recurso que permite gerar parte do código agora (ex: layout) e parte do código depois (ex: código Java). Além disso, a possibilidade de gerar várias vezes o código Java ou configurações sem atrapalhar customizações manuais realizadas pelo desenvolvedor. A geração incremental é útil para que o desenvolvedor escolha qual parte do sistema que gerar e qual parte que fazer manualmente ou utilizar outra ferramenta, permite também adicionar novas tecnologias no decorrer do projeto;

• Interface visual: neste item, levamos em conta a possibilidade oferecida por cada projeto no que diz respeito à configuração e geração de código através de uma interface visual;

• Fácil utilização: Aqui os projetos foram destacados pela possibilidade de serem utilizados de forma fácil  por desenvolvedores iniciantes ou que buscam produtividade. Uma interface visual influencia diretamente neste item. Mas, além disso, essa interface deve ser simples, direta e com boa usabilidade;

• Código internacionalizado: algumas equipes de desenvolvimento gostam de ter o nome das classes e métodos em inglês, independente do idioma regional (ou o contrário - ter tudo em português por exemplo). Esse recurso considera exatamente isso. Não só a interface do sistema gerado deve ser internacionalizado, mas o código também para ser flexível aos diferentes tipos de necessidades;

• Geração de código customizado (templates): consideramos aqui a possibilidade dos projetos conseguirem gerar código referente a um framework que pertence a agrupamentos específicos (templates), por exemplo: template Java 1.4, template Java 5, template da minha empresa. Dentro de cada template, o código de um mesmo framework é gerado de forma diferente;

• Integração com a ferramenta de desenvolvimento (IDE): foi considerada a integração total com qualquer IDE (Eclipse, NetBeans, IDEA). Para atender a este item, é necessário configurar a geração, gerar códigos, customizar, criar outros arquivos manualmente e testar o projeto usando o mesmo ambiente, sem abrir outras ferramentas que não fazem parte do dia a dia do desenvolvedor;
  

SPIDER versus MDD
Algumas ferramentas de geração de código são Model-Driven Development (MDD) e o SPIDER possui outro conceito. Vamos tentar explicar as diferenças:

No SPIDER você não precisa criar diagramas e não tem dependência com a ferramenta se quiser alterar o código. O SPIDER ajuda você a criar o código do seu projeto e após criar os arquivos eles tem como dono a pessoa: o desenvolvedor. O SPIDER não precisa manter qualquer sincronismo regular com o código. Você pode continuar o seu projeto manualmente, após algumas semanas pode usar o SPIDER novamente, para novos Use Case.
o SPIDER não possui dependência entre o código e a ferramenta, os dois são completamente independentes. Se na metade do projeto você decidir não usar mais o SPIDER, ok. Você pode fazer isso.

Algumas outras ferramentas parecidas tem alguns passos manuais como: muitos "comandos maven", ou entrada de dados usando somente comandos (command line). A abstração do SPIDER é mais elevada e você não precisa "conhecer ou aprender" nada para usar a ferramenta... é muito mais fácil e permite mais features por exemplo: escolher layout (skin) visualmente. Fazer isso em um prompt seria ruim.

As facilidades do SPIDER permitem que você crie projetos muito mais rápido do que com ferramentas MDD ou ferramentas baseadas em comandos.
A qualidade também será boa porque o código gerado é baseado em templates. Você pode usar o seu template com as customizações que quiser.

A documentação e diagrama UML são importantes, mas nós não precisamos delas para configurar o projeto ou criar CRUDs. O SPIDER é mais ágil e consegue criar código (como você quiser) sem usar o conceito de MDD, então você economiza tempo.
Na minha opinião MDD é importante (por exemplo) para modelar um sistema e criá-lo em várias tecnologias diferentes. Se o seu sistema terá somente uma tecnologia (JEE), MDD não é necessário ou não agrega muitas vantagens. Por isso o SPIDER não é uma ferramenta MDD.