Método simples para entender UML

Olá Galera, parece meio tosca essa pergunta, mas preciso entender UML bem a fundo e o mais rápido possivel, pois tenho um projeto pra desenvolver… Algum link útil ou ferramenta que seje facil de usar? O Netbeans pra UML ajuda?
Valeu a atenção.

ferramentas vc pode utilizar o Jude é uma ferramenta free e de facil utilização só não tem mtos recursos como outras pagas. e neste site vc pode achar bastante coisas relaciondas a UML tbm vc pode procurar mais UML 2.0 ou pelo wikipedia

Segue o link do Visual Paradigm:

http://www.visual-paradigm.com/

é uma ferramenta proprietária, mas você pode fazer o download da comunity edition gratuitamente. Ele é um pouquinho difícl de mexer no começo, mas em compensação é bastante completo.

Um bom início é o meu artigo “UML Não é documentação” que foi publicado na MJ19 e agora está disponível para download:

Tenho um curso também:

Abraços!

UML Distilled
Você vai aprender o suficiente.

[quote=Emerson Macedo]UML Distilled
Você vai aprender o suficiente.[/quote]

Eu li o livro (o começo dele) quando tava na biblioteca da faculdade. Fala que o diagrama de classes deve ser como o sistema deve ser da visão do usuário e não do desenvolvedor. Sendo assim, classes como Controladora e afins são erradas de se inserir no Diagrama de Classes (porque fazem ligações entre classes e coisarada)? Mesma coisa acontece com interfaces e classes abstratas (o nome “interface” e “abstract class” não deveria ir no diagrama)?

Abraço.

Não acho que seja errado, nem acho que deva ser na visão do usuário unicamente. IMO, a ideia é você usar pra te dar uma idéia geral do que vai ser o sistema, ao invés de modelar o sistema detalhadamente. Mas há quem goste de modelar o sistema bem detalhado com UML, o que eu não gosto, pois sincronizar vira quase sempre um inferno.

Sim… isso faz bem parte da visão do Fowler a respeito da UML. Veja também:

Particularmente se você não visa desenhar as interações entre objetos com um diagrama de sequência as outras classes que não fazem parte do Domain Model não fazem sentido serem modeladas com a UML. O modelo não é um espelho do código.

Pois é.
Na minha opinião, o problema de se aprender UML é que os diagramas podem ser feitos de maneiras muito diferentes. Aí posso ter feito de um jeito bem simplificado com um diagrama de casos de uso com 10 use-cases (supondo), enquanto alguns amigos fizeram com 7 e eu achar eu estar errado enquanto estava certo (tanto o meu quanto o deles).
Qual a melhor saída pra isso? Eu estou dando uma olhada nos diagramas da aspercom, pra ter algumas idéias de como tratar essa diferença entre os diagramas (se eu devo copiar ou ficar com os meus (o que eu acho mais certo)).

Esse é um problema com qualquer linguagem, de programação ou não, de múltiplo propósito. UML teme ste problema, Java tem, etc.

Solução? A UML é apenas uma forma de você se comunicar, de expressar um design. Se concentre emc riar um bom design aprendendo OO.

Cara o livro dos criadores da UML “UML gua do usuário” diz tudo

e uma ferramenta excelente é visual paradigma (tem licença comunit)

flw

Heber

http://www.heberfa.com.br

[quote=pcalcado]Esse é um problema com qualquer linguagem, de programação ou não, de múltiplo propósito. UML teme ste problema, Java tem, etc.

Solução? A UML é apenas uma forma de você se comunicar, de expressar um design. Se concentre emc riar um bom design aprendendo OO.[/quote]

Eu concordo com você, mas o problema é saber se, depois de criado o diagrama, saber se ele está certo ou errado.
Se não existir alguém pra falar “Você poderia ter feito assim que estaria mais fácil de entender”, o desenvolvedor vai ficar encalhado pra sempre. No final, vira um tal de senior que faz as coisas erradas.

[quote=Andre Brito]
Eu concordo com você, mas o problema é saber se, depois de criado o diagrama, saber se ele está certo ou errado.
Se não existir alguém pra falar “Você poderia ter feito assim que estaria mais fácil de entender”, o desenvolvedor vai ficar encalhado pra sempre. No final, vira um tal de senior que faz as coisas erradas.[/quote]

Sim, mas o ponto é que isso não é um problema da UML. Você vai ter o mesmo problema com Java ou qualquer outra linguagem -visual ou não.

[quote=pcalcado][quote=Andre Brito]
Eu concordo com você, mas o problema é saber se, depois de criado o diagrama, saber se ele está certo ou errado.
Se não existir alguém pra falar “Você poderia ter feito assim que estaria mais fácil de entender”, o desenvolvedor vai ficar encalhado pra sempre. No final, vira um tal de senior que faz as coisas erradas.[/quote]

Sim, mas o ponto é que isso não é um problema da UML. Você vai ter o mesmo problema com Java ou qualquer outra linguagem -visual ou não.[/quote]

Ah, isso sim. A experiência é a única forma de aprender a modelar bem (quando alguém que já tem certa experiência chega pra você e fala que poderia ser de outra forma para melhorar?)? Exemplos em livros… ok, mas quando surge algo novo pra uma pessoa que recém terminou de ler o livro, ela pode se embananar, certo?

A questão é que Design não é uma ciência exata. Eu posso fazer um Design e mostrar para o Shoes e ele dizer que está errado assim como ele pode fazer um Design e eu dizer que está errado.

Pois é. Isso tem suas desvantagens, mas tem também seus benefícios… e esses são os da orientação a objeto, certo?