Diagramas de Sequencia - Mensagens para interfaces

Debugger Membro desde: 08/06/2005 17:24:33 Mensagens: 51 Offline

Olá pessoal,

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

This message was edited 1 time. Last update was at 23/07/2008 17:13:21

Será que você precisa realmente representar a objeto que vai ser injetado? Se o objetivo de injetar a dependência é te dar flexibilidade, pra que você vai precisar representar a instância, sendo que essa pode variar?
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

Debugger Membro desde: 08/06/2005 17:24:33 Mensagens: 51 Offline

Entendo o que vc quer dizer.
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

Talvez você esteja entrando num nível de detalhe mais profundo de implementação. Se esse for seu caso, vá em frente. Só tome cuidado pra não programar 2 vezes: 1 na UML e depois no código fonte.

Debugger Membro desde: 08/06/2005 17:24:33 Mensagens: 51 Offline

De fato. mas preciso que alguns níveis de implementação fiquem no projeto para manter a padronização dos códigos entre os implementadores. Mas detalhes mínimos de tecnologia podem ser abstraidos.

obrigado, guilherme

Diagramas de Sequência mostram a interação entre objetos. Leia isso como "a maneira que os objetos trocam estímulos". É uma péssima idéia usar isso para mostrar o comportamento interno do objeto. A UML é mais high-level. Não é uma linguagem de implementação. Se você quiser detalhes vá ao código.

Ter ambiguidade entre artefatos é muito ruim.

E outra, não é a UML que vai manter os programadores na linha.

rodrigoy wrote:Ter ambiguidade entre artefatos é muito ruim.

Exato. DRY não diz respeito apenas a código.

E lembrando que UML é uma ótima maneira de comunicar e discutir coisas mas umas péssima linguagem para modelar funcionamento já que não é executável.

Debugger Membro desde: 08/06/2005 17:24:33 Mensagens: 51 Offline

Como então seria o sucesso de ferramentas de geração automática de códigos sem um detalhamento nos diagramas de sequencia?
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?

Eu não diria que essas ferramentas são um sucesso. Pelo contrário, são/foram um fracasso.

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.

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.

Guilherme_82 wrote:Como então seria o sucesso de ferramentas de geração automática de códigos sem um detalhamento nos diagramas de sequencia?
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?

Que sucesso? Aposta de quais enenheiros de software?

rodrigoy wrote: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.

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

rodrigoy wrote:
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.

Ó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.

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 221 Offline

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

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.

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 46 Offline

Para contribuir com o tema, segue citação: "No tempo que levaria criando o código para um design, você pode comparar três designs usando imagens" - Kent Beck, em Extreme Programming Explained

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.

Gustavo Serafim wrote:
No entanto, concordo que código também é um modelo.

Código não é um modelo, código (na maioria das tecnologias mainstream) é o 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.