| Autor |
Mensagem |
|
|
okara wrote:Eu fico confuso desse jeito.
Se eu for colocar no diagrama tudo que tem na implementação, o modelo não vai ficar poluído ?
Estou construindo um diagrama de classes, mas não quero colocar recursos de Log no modelo por exemplo.
Isso não é relevante para meu modelo de domínio.
Peraí, não falei para colocar tudo no modelo UML, se vc está usando um modelo de domínio, só este estaria no modelo UML, a infra fica fora...
Se você tem uma classe Pessoa no diagrama UML é esperado que você tenha uma classe Pessoa no seu código segundo o diagrama.
okara wrote:E não é mais fácil visualizar diferentes papéis por exemplo da class pessoa com uma notação de herança ao invés de uma composição ?
Para você usar a composição no lugar da herança é necessário aplicar Patterns. Se decidir usar Strategy, use-o no modelo UML e no código. Se decidir por usar herança, use-a no modelo UML e no código. O que eu quero falar é que usar herança no modelo UML e Strategy no código tornam as coisas confusas...
|
 |
|
|
Este é um ótimo exemplo para demonstrar que um value object possui comportamentos (operações de negócio). Este pattern é confundido com o DTO.
|
|
|
|
okara wrote:Mas na UML é melhor representar muitos papéis de uma classe usando herança mesmo ?
Ou usar a composição.
Digo isso pois estou tentando seguir a linha da abstração da UML.
A solução que você vai dar na UML deve ser a mesma que você vai implementar no código. A abstração é a mesma. Não é uma boa idéia trabalhar muito abstratamente na UML ao ponto do código ser completamente diferente.
O que você deve ter em mente é que, se você for tratar todas as variâncias com herança, seu modelo ficará complexo e inflexível. Entre seus papéis, analise o que varia, e veja se a aplicação de um Strategy ou um Decorator ou outros patterns não deixariam seu modelo mais flexível. De qualquer forma, uma simples herança já resolve alguns casos sem comprometer o modelo.
|
|
|
|
pcalcado wrote:Acho que o problema principal em UML como modelagem é que não dá pra validar (esqueçam MDA, Executable UML, etc. por hora). Acho que mesmo considerando que o retrabalho que a falta de roundtripping das ferramentas atuais torna extremamente improdutivo modelar e depois codificar, este é um problema ainda mais grave.
Eu gosto da UML para modelar pela visão geral. Acho que desenhar classes e visualizar associações na fase de análise é mais produtivo do que escrever e ler código. Gosto do diagrama de sequência para descobrir as mensagens que os objetos devem trocar para realizar os requisitos (aí encontro as operações, as responsabilidades). Mas o modelo UML deve parar por aí. Os diagramas de interação da UML modelam interações e não o funcionamento interno da classe. O funcionamento interno da classe é melhor documentado no código.
Basicamente, o modelo UML me responde como os requisitos estão resolvidos por classes que colaboram, sem entrar em detalhes.
pcalcado wrote:Claro que do jeito que o Rodrigo coloca a modelagem me parece num nível que não precisa de tanta validação. Infelizmente as pessoas costumam programar em UML (curiosamente chamando isso de 'projeto' ou 'especificação') e isso é um risco muito alto considerando que não dá pra validar aquele modelo gráfico de maneira precisa e automatizada.
Conversei sobre isso no tópico do seu artigo. O trabalho de modelagem e análise deve se estender ao código. Se a modelagem UML está focada num Domain Model baseado em POJOS, a geração de código e a reversa é bem menos traumática (mas não é 100%). De qualquer forma, o trabalho de modelagem não pára na UML. É importante que o analista implemente no código o funcionamento interno das classes do Domain Model e aplique testes de validação independentes da arquitetura. Isso torna os analistas mais responsáveis, mas ressalto que isso não é uma prática comum nos projetos que observo.
|
|
|
|
cv wrote:Usar UML pra descobrir quais as mensagens que objetos tem que trocar nao me parece la uma boa ideia.
Prefiro usar testes unitarios pra isso, ja que, ao contrario da UML, eles sao mais faceis de manter (apesar de nao necesasriamente tao ou mais faceis de ler), ja que sao compilados assim como o resto do codigo, e sao deterministicos: ou falha ou nao falha. 
Minha escolha geralmente tem sido direcionar o design a partir dos testes (veja mais em TDD e BDD) e usar UML pra comunicar pra equipe mudancas importantes ou pq algumas decisoes foram tomadas de um ou outro jeito.
Aí é uma mistura de prós e contras, mais gosto pessoal e o tipo de projeto. Sobre o gosto pessoal, algumas pessoas são mais "visuais" do que outras. Freud explica. 
A questão do modelo UML ser visual é uma vantagem a considerar. No código você olha uma classe de cada vez, e para entender como uma interação ocorre, você precisa navegar entre muitas delas. Um diagrama de sequência dá uma visão mais macro da interação, assim fica mais fácil criar, delegar e identificar responsáveis.
No código, para enxergar todos os envolvidos numa interação, você precisa navegar entre todos eles. No diagrama de sequência vc consegue enxergar todos os elementos envolvidos na interação logo que abre o diagrama.
Mas cada caso é um caso, a UML tem lá os seus problemas, alguns eu já citei. Eu uso as duas abordagens. Tenho verificado que mapear requisitos de processamentos com pouca interação de atores (como um processamento em lote) é muito mais efetivo usar as práticas do TDD do que escrever casos de uso e modelar com UML. Nesse caso, a documentação dos requisitos e o modelo estão diretamente no código.
|
|
|
|
David,
Para não ter problemas de ponto flutuante você pode usar o BigDecimal. Sobre o mapeamento no hibernate:
http://www.hibernate.org/hib_docs/v3/reference/en/html/components.html
[]s
|
|
|
|
Foguinho, seu diagrama está legal. Se fosse meu aluno receberia nota 10 (sou instrutor de UML).
O único detalhe é que geralmente não demonstro todos os gets e sets na sequência. Você pode esticar uma seta com o texto "popula atributos" mostrando a fonte e o destino. Isso deixa o diagrama válido, mesmo que os atributos mudem. (imagine também a situação de serem 20 atributos!)
O diagrama de sequência mostra como os objetos interagem trocando mensagens para solucionar o que o software tem que fazer. Essa interação não precisa ser detalhada. Quem quiser ver os detalhes vai direto ao código.
OK?
|
|
|
|
brunohansen wrote:Requisito:
Suponhamos que estou desenvolvendo uma aplicação que manipula quadrados. O usuário tem como um de seus objetivos configurar um tamanho, cor, textura e etc.. para que seus quadrados já iniciem desta forma.
"Este objetivo já me leva a pensar em usar um prototipo no meu projeto".
OK! Demonstre o pattern no modelo UML, mas como falei, não é necessário importar classes java na ferramenta UML para demonstrar isso. Uma operação Quadrado.clone():Quadrado é suficiente para demonstrar a solução desse requisito de uma maneira clara e menos amarrada.
brunohansen wrote:UML para mim é uma ferramenta de análise/projeto.
Por exemplo na fase de analise eu utilizaria a uml para fazer um diagrama de classes conceituais(Modelo de dominio) que estara bem proximo dos meus requisitos, alias este modelo representara meu problema real.
Agora na fase de projeto eu utilizaria a uml para fazer um diagrama de classes de projeto que estara bem proximo da estrutura que eu vou implementar. Esta fase transforma seu proplema real em "computavel", ou seja, faz com que ele possa ser resolvido com logica computacional. Nesta fase voce pode ate usar uma tecnica como diminuição do hiato de representação, que faz com que seu projeto se aproxime do seu dominio.
Bruno, seja realista, esse modelo de domínio de uma fase de análise em alto nível, próximo do negócio e principalmente "incodificável" (isto é, abstrações que não se aproximam nem um pouco dos componentes de software reais) não se aplica a muitos projetos. Essa técnica gera artefatos difíceis de manter e aumentam muito a distância entre os requisitos e o código. Seria como uma "camada" a mais na documentação, que encaixa mais na análise de negócio e não de sistema.
O que você chama de projeto é o que eu chamo de análise. Minha visão da análise é descobrir como os requisitos (essencialmente os funcionais) são resolvidos por componentes de software. Nisso o uso da UML faz sentido. Você modela a estrutura estática (os dados e relacionamentos) usando um diagrama de classes e descobre como essas classes colaboram entre sí (através de mensagens) usando diagramas de interação. Por isso disse UML=Ferramenta de Análise. Usar a UML só para documentar é um erro.
cv wrote: Pq nao ver UML como uma ferramenta de comunicacao, assim como a lingua Portuguesa?
OK, mas usar a UML só para comunicação também é limitar a UML. Como falei, uso um diagrama de sequência para descobrir as mensagens que os objetos vão ter que trocar para resolver os requisitos. Não estou fazendo este diagrama só para deixar as idéias claras para a equipe...
brunohansen wrote:Agora se isso tudo é um exagero ou não é uma outra conversa.
Só fiquei um pouco espantado quando você disse que padrões de projeto fornece uma solução para a implementação e UML=Ferramenta de Análise.
Acho que é exatamente esse exagero que sempre entra em discussão quando falamos sobre uso da UML.
Sobre padrões, alguns deles podem aparecer no modelo UML, outros não. Por exemplo, Strategy, State, Singleton, Decorators são bons candidatos a aparecerem no modelo UML, um DataMapper seria um exemplo de pattern que não apareceria no modelo UML, ele estaria só no código. Concorda? É essa a idéia que quis mostrar.
No modelo UML, se estamos usando um Entity, assumimos que tudo está a nossa disposição: não nos preocupamos se é remoto, obtemos os dados das associações sem se importar se o Lazy Load funciona ou se a sessão do Hibernate está aberta ou fechada. Essas não são (não deveriam ser) preocupações em tempo de análise. Logicamente é importante que a arquitetura resolva isso. Arquiteturas fortes permitem um modelo mais abstrato.
É preciso tomar cuidado quando as libraries da implementação estão no modelo UML. Teve uma vez que um analista meu modelou tim-tim-por-tim-tim como uma lista vinda do servidor era populada num JComboBox. Trabalho jogado fora, né? Modelos nesse nível são pesados e potencializam um problema da UML que é a dessincronização com o código (não sei se essa palavra existe).
Como falei, nos últimos projetos meus tenho centralizado o uso da UML em descobrir o funcionamento do Domain Model. Uma ótima leitura é o Domain-Driven Design de Eric Evans. Aliás, no endereço abaixo tem um ótimo resumo:
http://domaindrivendesign.org/book/PatternSummariesUnderCreativeCommons.doc
Também é importante ressaltar que a modelagem não é feita somente no modelo UML, a modelagem continua no código.
(definitivamente, não tenho o dom da brevidade)
|
|
|
|
brunohansen wrote:A questão é se no meu projeto eu descubro que minha classe deve usar o padrão prototipo eu defino um interface qualquer para representar isso ou eu utilizo a inteface clonable fornecida pelo java??
É difícil imaginar uma situação que você necessite demonstrar isso no modelo. Tente imaginar um requisito que te force a usar o pattern prototype... Esse pattern fornece uma solução para a implementação e não para a análise.
De qualquer forma, se uma classe possue uma operação clone() que retorna o próprio tipo da classe não é bem óbvio que na codificação essa operação cloneia a classe? Será que é necessário eu importar a cloneable para demonstrar isso melhor?
É mais válido fazer o modelo se aproximar dos requisitos do que do código. Isso garante que você não vai se aprofundar demais no design. Já ouviu falar na expressão "o analista está programando no Rose?!?". Basicamente é o sintoma do BigDesignUpFront....
UML=Ferramenta de Análise
|
|
|
|
A filosofia que tenho aplicado nos meus últimos projetos é focar a análise com a UML nos elementos do Domain Model (entidades, serviços) e também modelo repositories para representar as buscas necessárias para o sistema funcionar.
O foco da análise é descobrir informações. É partir dos requisitos mapeando como os componentes de software resolvem o problema. Mas essa "descoberta" tem uma baixa profundidade. Exemplo, se na realização do caso de uso descubro que preciso da operação "ClasseA.calcularValor(x, y, z)", no modelo, não entro em detalhes como essa operação funciona internamente. O código é melhor para demonstrar isso.
Concluindo, uso o modelo UML mais para descobrir as responsabilidades das classes e não para definir o seu funcionamento interno...
Escreví um artigo sobre isso para a MundoJava, espero que publiquem em breve...
|
|
|
|
Bruno, no caso do String basta digitar "String" no tipo do atributo. Como String está no java.lang não tem problemas na geração de código.
Particularmente acho uma péssima idéia importar classes da linguagem de implementação no modelo. O modelo é uma abstração, não é um espelho do código. Se o seu modelo está amarrado à classes da implementação é bem possível que o seu design está "indo fundo demais".
A França está ganhando de 2 a 0.
|
|
|
|
Luca,
"programar para uma interface" é explorar o polimorfismo permitindo que o objeto em runtime mude.
"preferir composição à herança" está mais relacionado com algumas inflexibilidades da herança que podem minar a evolução do software...
São princípios diferentes...
|
|
|
|
Amigos(as),
Estou montando um texto e gostaria saber se algum de vocês sabem qual foi o primeiro autor e qual foi a obra que constou o princípio "programe para uma interface, não para uma implementação".
Isso aparece em tudo quanto é lugar, mas gostaria saber se existe uma referência bibliográfica... "o dono da idéia". Capiche?
Abraços!
|
|
|
|
Fabrício, fiz um teste aqui e funcionou sem problemas... quando esticar a seta, nas propriedades da message, verifique se o check-box "Show Inherited Methods" está checado...
|
|
|
|
Rafael Nunes wrote:
rodrigoy wrote:Se você tem o seu banco espelhado em objetos, potencialmente, já seria um Domain Model.
Acredito que não, pois o Domain Model seria formado também por classes de negócios, que realizam processamento de use-cases e que não são obrigatoriamente espelhadas em tabelas.
Isso não responde a minha pergunta. Que situação você teria Entities e Transaction Scripts que não justificam um Domain Model?
|
|
|
|
|
|