Diagramas UML no desenvolvimento de Software

Geralmente quem fala que UML não serve para nada não passou pela época da guerra dos métodos a uns 12 anos atrás. Seria muito legal se cada literatura que existisse tivesse a sua própria notação para classes, objetos, associações, mensagens, atividades, estados e etc... certo?

Imagina só o Martin Fowler no prefácio do seu renomado 'P of EAA' explicando 'toda vez que você ver um triângulo neste livro se trata de uma classe, já um círculo é um objeto'....

Se você usar a UML só como forma de comunição entre a equipe já está ótimo... UML é uma linguagem, é para se comunicar mesmo! Um outro valor que vejo na UML é no ensino de orientação a objetos, meu curso UML é muito sobre isso. A notação em sí não é importante.

Nas minhas equipes eu valorizo pessoas que sabem resumir idéias e abstrair conceitos através de modelos, sejam UML ou não. Isso ajuda muito a estabelecer uma visão clara, discutir arquiteturas/soluções, planejar/estimar o projeto, definir estratégias de teste e muitas outras coisas. Nem tudo dá para resolver em artefatos dentro do código. São coisas diferentes e em momentos diferentes. Vocês concordam que o conhecimento de modelar coisas (em UML ou não) é importante para o desenvolvimento de software? Se você concorda e quer ensinar a pessoa um pouco sobre modelagem é o fim do mundo usar a notação UML que é um padrão?

(errr... esse mail não é crítica direta a ninguém que escreveu aqui.... valeu?)

Não é uma crítica mas você escreveu logo depois que eu coloquei algumas constraints no uso da UML?

Pega leve heim... rs

Acho que a UML como padrão visual para comunicação ótima. Por isso eu disse que uso pra discutir conceitos (i.e. alguma modelagem) ou explicar alguma arquitetura.

O seu exemplo de ensino de orientação a objetos também é bem válido.

[]s

Em um sistema significamente "grande" utilizo UML até mesmo para me organizar e não "se perder" em inúmeras linhas de código.

This message was edited 1 time. Last update was at 01/02/2010 18:37:30

rodrigoy wrote:Vocês concordam que o conhecimento de modelar coisas (em UML ou não) é importante para o desenvolvimento de software? Se você concorda e quer ensinar a pessoa um pouco sobre modelagem é o fim do mundo usar a notação UML

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

EDIT*: Ops... nem vi que é um tópico ligeiramente antigo...

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3275 Offline

Rubem Azenha wrote:

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?

A representação tem de ser clara pra quem lê entender o que você está falando.

Se pra conseguir isso você precisar de um texto adicional ou de alguma coisa não padronizada, não há problema nenhum. Problema seria alguém tentar entender seu diagrama e ficar na dúvida.

This message was edited 2 times. Last update was at 04/02/2010 09:27:06

!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Rubem Azenha wrote:

rodrigoy wrote:Vocês concordam que o conhecimento de modelar coisas (em UML ou não) é importante para o desenvolvimento de software? Se você concorda e quer ensinar a pessoa um pouco sobre modelagem é o fim do mundo usar a notação UML

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

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

GUJ Master Membro desde: 07/06/2008 14:41:04 Mensagens: 1622 Offline

sergiotaborda wrote:
Usar artefatos não padronizados não faz sentido em UML (o U é de universal, lembra?).

Não seria Unified?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Tchello wrote:

sergiotaborda wrote:
Usar artefatos não padronizados não faz sentido em UML (o U é de universal, lembra?).

Não seria Unified?

Sim

, mas não ha diferença para o argumento.

Algo que é único é universal. Algo que é universal é único.

sergiotaborda wrote:
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).

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.

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

Seria isso: http://www.agilemodeling.com/style/activityDiagram.htm#Swimlanes

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

...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Rubem Azenha wrote:

sergiotaborda wrote:
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).

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.

Pois é. É por isso que roundtrip CASE é péssima ideia.

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

Seria isso: http://www.agilemodeling.com/style/activityDiagram.htm#Swimlanes

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

Notícias, artigos e o maior fórum brasileiro sobre Java