Diagramas UML no desenvolvimento de Software

Aew!!!
depende muito do sistema…
Geralmente eu utilizo o diagrama de Caso de uso para ter uma ideia de como o sistema tem que ser… e o de Classe para desenhar a OO
FLW ^^

Bem eu customo usar Caso de Uso para ter um visão geral do sistema. Agora quando precisar detalhar algumas partes do sistema, uso diagrama de atividades e sequência, em alguns casos uso o de componentes. E também uso o de classes. So que vou desenvolvendo os diagramas a medida que vou desenvolvendo o sistema

Muito obrigado pela dica pessoal,

As vezes perdemos muito tempo apenas "programando" quando na verdade o tempo deve ser melhor aproveitado na analise do sistema, Abraços Pessoal e obrigrado pelas respostas

Pensando em agile, documentos são caros de ser mantidos… imagina manter atualizado um diagrama de classes…
Não que documentar seja ruim, mas tudo tem sua finalidade e não se sinta culpado em jogar fora… usamos bastante como rascunho numa interação para passar pra equipe o que tem q ser feito, geralmente desenhamos numa lousa branca.
Não se esqueça que seu principal objetivo é o software

Abraços

Exatamente, estou totalmente de acordo, simples modificacoes podem custar muito caro, pois tempo é dinheiro e softwares normalmente tem prazo para serem entregues, e modificar diagramas é um problema quando o assunto é tempo, quais os diagramas voces mais usam quando trabalham com metodologias ageis?

Obrigado pelas Respostas

André de Souza

Eu costumo utilizar notações não padronizadas numa folha A4

No meu caso, nenhum.

"

Outra coisa a se considerar eh que UML nao eh a unica maneira de se documentar um projeto. Uma suite de testes de aceitacao automatizados tambem pode servir muito bem a esse proposito, e de brinde voce ainda pode validar boa parte da especificacao automaticamente

Nunca senti falta de UML

"

Olá, expondo minha opinião sobre o assunto, acredito que UML não seja para documentar. Um design OO bem construído se autodocumenta, e se não for o bastante nada que o bom javadoc não resolva.

Acredito que o UML seja uma ferramenta de análise. Parafraseando Rodrigo Yoshima:“A análise é traduzir requisitos em
em componentes do software, descobrindo informações.”

Para corroborar o que eu disse, leia o artigo:

Valeu!

"

Eu só uso UML (não normativa) pra explicar arquiteturas ou pra discutir soluções. Fora isso … sinceramente não serve pra mais quase nada.

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’… :x

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.

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…

Rubem Azenha:

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.

!

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

Não seria Unified?

Tchello:

sergiotaborda:

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

Não seria Unified?

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

…

Rubem Azenha:

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

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.

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