Estou tentando iniciar um modelo no Enterprise Architect, só que não estou conseguindo utilizar as classe base do Java como String.
Alguem sabe se tem como adicionar uma biblioteca, ou seja, alguem sabe como eu faço para utilizar as classes fornecidas pelo java dentro do EA?
Se algume puder ajudar…
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.
Concordo que o projeto não deve estar preso a implementação, mas sera que tem como fazer algo generico não simplista que pode ser implementado em qualquer linguagem?
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…
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??
Acho que tem um plugin do E.A. para isso, acho legal sim, importar as classes da linguagem que você tá usando no projeto, se você tá fazendo um diagrama de classe e colocar um atributo Colecao do tipo java.util.Collection, fica completamente estranho.
[quote=brunohansen]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??
[/quote]
É 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
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”.
Esse pattern fornece uma solução para projeto, como conseguencia seu projeto vai refletir na sua implementação.
Padrões de Projeto antes de tudo fornecem soluções para projeto, e não fornece uma solução para análise. Se pensarmos que a fase de análise tem um objetivo totalmente diferente da de projeto.
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.
Coisas como essa voce encontra em varios livros como Utilizando UML e padrões 2 ed LARMAN.
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.
Pq nao ver UML como uma ferramenta de comunicacao, assim como a lingua Portuguesa? 
Pq nao ver UML como uma ferramenta de comunicacao, assim como a lingua Portuguesa? ;)[/quote]
Podemos realmente ver sim.
Podemos dizer que o limite da usabilidade da UML é o limite da nossa criatividade! hauahuha 
Acho que restingi na hora a análise/projeto por estar muito assustado com: UML=Ferramenta de Análise.
[quote=brunohansen]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”.
[/quote]
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.
[quote=brunohansen]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.
[/quote]
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.
OK, mas usar a UML só para comunicação também é limitar a UML. Como falei, uso um diagrama de sequência para [color=red][size=18]descobrir[/size][/color] 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…
[quote=brunohansen]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.
[/quote]
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)
OK, mas usar a UML só para comunicação também é limitar a UML. Como falei, uso um diagrama de sequência para [color=red][size=18]descobrir[/size][/color] 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…[/quote]
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.
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.
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.
[quote=cv]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.[/quote]
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. :lol:
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.
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.
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.
Agora chuveu um monte de dúvidas em relação as fases de projeto e análise.
Para mim a fase de análise vai ser onde vc vai identificar os requisitos funcionais, requisitos não funcionais e pode até montar um modelo de dominio representando seu problema (Assim você pode obter uma vi~soa melhor do negocio).
E a fase de projeto voce vai começar a definir seus componentes de softwares vai definir uma estrutura para lhe dar flexibilidade caso vc precise. e etc… Vc vai definir uma estrutura para seu projeto independente de infra estrutura, voce vai usar seus padrões de projeto etc… Projetar não significa que vc vai implementar.
Pelo menos foi essa visão que eu tive qdo li LARMAN
Essa visão que eu tenho hj é uma visao errada??
Estou meio bolado o Rodrigo me parece que modela o projeto dele na fase de analise. E vc shoes vc não projeta??
Mas como manter isso ?
Não é difícil manter dois diagramas:
Estou fazendo a análise de um projeto e estou apenas eleborando os diagramas em um nível conceitual.
Tanto os casos de uso, como o diagrama de classes e o diagrama de atividades para representar o fluxo dos processos.
Estou usando o EA.
Mas estou em dúvida se vou criar diagramas em níivel de projeto.
Estou pensando apenas em fazer um roteiro genérico e uma doumnetação não visual como o JavaDoc.
O que vc acham ?
[quote=brunohansen]Agora chuveu um monte de dúvidas em relação as fases de projeto e análise.
Para mim a fase de análise vai ser onde vc vai identificar os requisitos funcionais, requisitos não funcionais e pode até montar um modelo de dominio representando seu problema (Assim você pode obter uma vi~soa melhor do negocio).
E a fase de projeto voce vai começar a definir seus componentes de softwares vai definir uma estrutura para lhe dar flexibilidade caso vc precise. e etc… Vc vai definir uma estrutura para seu projeto independente de infra estrutura, voce vai usar seus padrões de projeto etc… Projetar não significa que vc vai implementar.
Pelo menos foi essa visão que eu tive qdo li LARMAN
Essa visão que eu tenho hj é uma visao errada??
Estou meio bolado o Rodrigo me parece que modela o projeto dele na fase de analise. E vc shoes vc não projeta??[/quote]
Estou com o livro do Larman aqui (2nd edition). Não vejo em nenhum lugar ele citar que existe uma fase de projeto :? , bom, ele também não fala sobre fase de análise também 
. Estamos confundindo fases e disciplinas se estamos todos discutindo em cima do UP.
Este livro é fundamentado no UP tradicional, as disciplinas são:
Modelagem de Negócio (pouco utilizada)
Requisitos
Design
Implementação
(Gerenc. de Projeto)
Teste
Bom, esqueça. Abstraindo o Larman, a construção de software, segundo qualquer processo é:
É meio gozação, mas é só uma maneira de explicar. De todas essas tarefas, temos inúmeras maneiras de endereçar essas descobertas. E essas maneiras tem muitos nomes e técnicas. :shock:
A conversa tomou um rumo onde eu, o Shoes e o cv comentamos a aplicabilidade da UML na tarefa 2, independente do nome que você dá para isso. Ao invés da UML, você pode usar cartões CRC, testes, palitos de fósforo 
ou o próprio código para resolver isso.
Não estamos falando sobre as fases, estamos falando especificamente sobre essa tarefa 2 - Descobrir como componentes de software resolvem o que o software tem que fazer.
È realmente não é fase pois fase é concepção, elaboração …
É disciplina.
Ele fase especificamente de projeto vc pode até consultar a pagina 44 no grafico de disciplinas no tempo.
Ele menciona requisitos tambem… que eu acho que tem cara de análise.
Estou meio atrasdo agora mais se puderem gostaria de comentar mais sobre essas coisas