Alguns alertas sobre o ICONIX
Silva & Videira (2001) e Borillo (2000) destacam os alertas do ICONIX por
advertirem sobre problemas e dúvidas comuns em times de desenvolvimento de
software. Os alertas estão relacionados com cada técnica, como a seguir:
• Alertas do modelo de domínio:
(1) não perder muito tempo com verificação gramatical;
(2) não adicionar multiplicidade muito cedo ao projeto;
(3) endereçar agregação e composição apenas na fase do projeto detalhado;
(4) não desenhar um diagrama com mais de 7-9 classes;
(1) não perder muito tempo com verificação gramatical;
(2) não adicionar multiplicidade muito cedo ao projeto;
(3) endereçar agregação e composição apenas na fase do projeto detalhado;
(4) não desenhar um diagrama com mais de 7-9 classes;
• Alertas do modelo de use case:
(1) não tentar escrever casos de uso antes de saber o que os usuários realmente fazem;
(2) não desperdiçar tempo construindo modelos elegantes de casos de uso que não servem para
(1) não tentar escrever casos de uso antes de saber o que os usuários realmente fazem;
(2) não desperdiçar tempo construindo modelos elegantes de casos de uso que não servem para
construir o projeto;
(3) não perder tempo discutindo se vai usar includes ou extends;
(4) não usar templates textuais de caso de uso longos ou complexos;
(3) não perder tempo discutindo se vai usar includes ou extends;
(4) não usar templates textuais de caso de uso longos ou complexos;
• Alertas da análise de robustez:
(1) não tentar fazer um projeto detalhado do diagrama de robustez;
(2) não perder tempo aperfeiçoando o diagrama de robustez à medida que o projeto evolui;
(1) não tentar fazer um projeto detalhado do diagrama de robustez;
(2) não perder tempo aperfeiçoando o diagrama de robustez à medida que o projeto evolui;
• Alertas do diagrama de seqüência:
(1) não tentar alocar comportamento aos objetos antes de saber realmente o que os objetos são;
(2) não iniciar o diagrama de seqüência antes de completar o diagrama de robustez associado;
(3) não focar a atenção na configuração de métodos get e set em
(1) não tentar alocar comportamento aos objetos antes de saber realmente o que os objetos são;
(2) não iniciar o diagrama de seqüência antes de completar o diagrama de robustez associado;
(3) não focar a atenção na configuração de métodos get e set em
vez de focalizar a atenção em métodos reais.
0 comentários:
Postar um comentário