http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net
Estou com uma dúvida para criação de diagramas de sequencia que não encontro solução em lugar algum!
Qual a melhor maneira de modelar a invocação de métodos em interfaces?
Em frameworks como Spring em que a classe possui como atributo uma interface e é invocado um método da mesma.
Mas o método efetivamente que implementa aquela chamada é o método da classe que implementa a interface, por injeção de dependência.
Como modelo essas chamadas? Passo a chamada para a interface (que é o que será codificado) ou direto para a implementação?

Obrigado, guilherme maranhao]]> http://www.guj.com.br/posts/preList/97823/526346.java http://www.guj.com.br/posts/preList/97823/526346.java GMT Considere também o fato de que a interface é quem diz o que acontece, a implementação diz como. Portanto, num diagrama de sequência, basta a interface.

[]s]]> http://www.guj.com.br/posts/preList/97823/526369.java http://www.guj.com.br/posts/preList/97823/526369.java GMT Mas na sequencia do diagrama, preciso representar as interações e chamadas desse método da interface, que na verdade é implementado por uma outra classe.
Como eu representaria? Modelaria essas interações sendo implementadas pela interface? acredito que não....
preciso mostrar a execução do método da interface.
o que vc sugere?


obrigado]]> http://www.guj.com.br/posts/preList/97823/526502.java http://www.guj.com.br/posts/preList/97823/526502.java GMT http://www.guj.com.br/posts/preList/97823/526859.java http://www.guj.com.br/posts/preList/97823/526859.java GMT
obrigado, guilherme]]> http://www.guj.com.br/posts/preList/97823/526904.java http://www.guj.com.br/posts/preList/97823/526904.java GMT
Ter ambiguidade entre artefatos é muito ruim.

E outra, não é a UML que vai manter os programadores na linha. ]]> http://www.guj.com.br/posts/preList/97823/527056.java http://www.guj.com.br/posts/preList/97823/527056.java GMT
Exato. DRY não diz respeito apenas a código.]]> http://www.guj.com.br/posts/preList/97823/527161.java http://www.guj.com.br/posts/preList/97823/527161.java GMT http://www.guj.com.br/posts/preList/97823/527232.java http://www.guj.com.br/posts/preList/97823/527232.java GMT Lembrando que ferramentas para esse propósito é a grande aposta de engenheiros de software, MDA, EA...
não estou defendendo essa opinião. concordo, com o meu pouco conhecimento, que o papel do implementador é fundamental.
O que vcs acham?
]]> http://www.guj.com.br/posts/preList/97823/527250.java http://www.guj.com.br/posts/preList/97823/527250.java GMT http://www.guj.com.br/posts/preList/97823/527274.java http://www.guj.com.br/posts/preList/97823/527274.java GMT
As vezes eu uso geração de código do modelo UML para poupar tempo após uma leve modelagem inicial. Não significa que sempre tem que ser assim.]]> http://www.guj.com.br/posts/preList/97823/527347.java http://www.guj.com.br/posts/preList/97823/527347.java GMT Lembrando que ferramentas para esse propósito é a grande aposta de engenheiros de software, MDA, EA...
não estou defendendo essa opinião. concordo, com o meu pouco conhecimento, que o papel do implementador é fundamental.
O que vcs acham?
[/quote]

Que sucesso? Aposta de quais enenheiros de software?

[quote=rodrigoy]Nem tanto o céu, nem tanto a terra... Talvez a MDA seja específica demais, rigorosa demais e a OMG a tenha levado como sempre como se fosse a bala de prata e a última bolacha do pacote. Porém, transformação de modelos e geração de código são ferramentas que podem ser usadas baseadas na idéia da MDA.
[/quote]

Na verdade MDA que se baseia (e tenta padronizar) nessas idéias.

[quote=rodrigoy]
As vezes eu uso geração de código do modelo UML para poupar tempo após uma leve modelagem inicial. Não significa que sempre tem que ser assim.[/quote]

Ótimo para gerar código não não-testado e não confiável. Fora que a maioria das ferramentas não consegue gerar muito mais que classes semi-vazias.

Eu gosto de abordagens tipo a do Together, com visualização utilizada como ferramenta durante o desenvolvimento.

]]> http://www.guj.com.br/posts/preList/97823/527979.java http://www.guj.com.br/posts/preList/97823/527979.java GMT Eu gosto de abordagens tipo a do Together, com visualização utilizada como ferramenta durante o desenvolvimento.
[/quote]

Taí... Tive experiência de trabalhar 6 meses num projeto onde nossa ferramenta para, digamos assim, "modelagem", era o Together, e esse lance de fazer um diagrama de domínio, por exemplo, e ver o código resultante dele ali na hora, em outra janela, e poder refinar este código e vê-lo também refletido no diagrama, era bem legal e útil.

Dava pra ir conversando com o analista de negócio (que não entendia nada de código Java, mas compreendia bem diagramas de UML), escrevendo código e modelando junto com ele. O resultado era bom. E, melhor, eu não tinha que programar duas vezes.

Isso, sim, me parece mais nem tanto o céu nem tanto a terra.
]]> http://www.guj.com.br/posts/preList/97823/528067.java http://www.guj.com.br/posts/preList/97823/528067.java GMT
Uso a UML para modelar, o modelo pode ser quadro branco... o importante é o ato de modelar, e talvez, deveria ser descartável.

Claro que em um quadro branco, usamos todo tipo de símbolo gráfico inventado no momento para complementar a idéia, ou seja, sem formalismo.

Outro uso interessante da UML seria ensinar praticas e métodos, uma vez entendido os mecanismos, podem ser trocados por um processo mais mental ou direto no código...

No entanto, concordo que código também é um modelo.]]> http://www.guj.com.br/posts/preList/97823/535406.java http://www.guj.com.br/posts/preList/97823/535406.java GMT No entanto, concordo que código também é um modelo.[/quote]

Código não é [b]um[/b] modelo, código (na maioria das tecnologias mainstream) é [b]o[/b] modelo. UML é, como já dito aqui e como o Beck escreveu na sua citação, uma boa ferramenta de comunicação. Ela serve para explicar o modelo, não é o modelo.]]> http://www.guj.com.br/posts/preList/97823/535475.java http://www.guj.com.br/posts/preList/97823/535475.java GMT
Ok, não precisa pedir minha cabeça.

Este post contribui com o tema: [url]http://blog.fragmental.com.br/2008/08/09/analista-pedreiro[/url]]]> http://www.guj.com.br/posts/preList/97823/535657.java http://www.guj.com.br/posts/preList/97823/535657.java GMT