!
Concordo… mas as vezes eu acho que eu tenho que usar algumas ‘notações não padronizadas’ pra representar alguns conceitos básicos quando eu utilizo UML. Por exemplo, num diagrama de classes ou atividades, qual a maneira correta de demonstrar que as classes X, Y e Z fazem parte de uma tier do sistemas? Ou que as classes A, B e C fazem parte de um módulo do sistema? Uma vez me falaram pra usar “UML em Cores”, mas acho que não é uma coisa muito padronizada não.
Talvez exista uma forma padrão de representar esses conceitos e eu que não conheço muito bem 
Mas eu ainda acho mais vantagem conhecer bastante de design/arquitetura orientada a objetos, patterns, boas práticas, divisão em tiers, divisão em modulos, etc, do que conhecer em detalhes toda a “sintaxe” da UML - uma vez que UML serve pra representar algo e para comunicação, não adianta nada representar perfeitamente um sistema com um design ruim
[/quote]
No diagrama de classes a forma padrão é usar um package. As pessoas confundem isso porque acham que o package significa o pacote java, mas não é isso. No diagrama de atividade vc usa um lane (tb chamado partição).
No diagrama de classes se não quiser usar o package ou já o estiver usado para representar pacotes java (namespace) vc pode simular lanes usando traços separadores.
Usar artefatos não padronizados não faz sentido em UML (o U é de universal, lembra?). O que faz sentido é desenhar bonecos que usam a maior parte da uml e mais algumas coisas , mas são bonecos , não uml.
Em documentação escrita (aka word) os bonecos são meras ilustrações do texto. É o texto que deve refletir o que se pretende e não o boneco. Não existe nenhuma regra dizendo que sempre deve ser usada uml para fazer estes bonecos, e com certeza no manual do usuário não deve ser usada (pelo menos não de forma pura).
Conversar usando bonecos no papel ou num quadro é arroz com feijão para qq engenheiro. Os de software não são diferentes. mas na hora de redigir documentos é preciso seguir padrões (de preferencia universais).
Não seria Unified?
[quote=Tchello][quote=sergiotaborda]
Usar artefatos não padronizados não faz sentido em UML (o U é de universal, lembra?).
[/quote]
Não seria Unified?[/quote]
Sim :oops: , mas não ha diferença para o argumento. :lol: Algo que é único é universal. Algo que é universal é único.
Legal… http://en.wikipedia.org/wiki/Package_(UML)
Só atrapalha um pouco as ferramentas UML que fazem geração de código a partir de diagramas (ou código a partir de diagramas) usam as packages do UML como packages do java. Pelo que você falou e pela wikipedia, nem sempre teremos um relacionamento 1 para 1.
Seria isso: http://www.agilemodeling.com/style/activityDiagram.htm#Swimlanes
…
[quote=Rubem Azenha][quote=sergiotaborda]
No diagrama de classes a forma padrão é usar um package. As pessoas confundem isso porque acham que o package significa o pacote java, mas não é isso. No diagrama de atividade vc usa um lane (tb chamado partição).
[/quote]
Legal… http://en.wikipedia.org/wiki/Package_(UML)
Só atrapalha um pouco as ferramentas UML que fazem geração de código a partir de diagramas (ou código a partir de diagramas) usam as packages do UML como packages do java. Pelo que você falou e pela wikipedia, nem sempre teremos um relacionamento 1 para 1.
[/quote]
Pois é. É por isso que roundtrip CASE é péssima ideia.
Exactamente.
uml é padrão de análise. mas no fundo pra prensar cada um usa o que quiser… o importante é que no final usem a cabeça 
Também acho que o valor da UML está mais na questão de unificar a comunicação mesmo… o livro do Fowler “UML Distilled” é uma ótima para quem deseja se familiarizar com o essencial.
abraços