Engenheiros ainda usam diagramas de casos de uso e diagramas de classe?

Forum Spammer Membro desde: 10/07/2006 10:37:23 Mensagens: 1590 Offline

acho besteira usar estes diagramas em projetos muito pequenos e não extenciveis ou pouco extenciveis mas acho primordial usar em projetos grandes e extenciveis... trabalho em um projeto gigantesco que a muito pouco diagramas... e isto as vezes gera confusões, dificuldade de entendimento de processos e do funcionamento de certas funções e duplicidade de algumas classes... pois é imprecendivel um diagrama de Caso de Uso para entender como determinado escopo do sistema vai interagir e quem são os atores e suas ações... isto faz com que vc entenda o sistema... e tbm é importante diagramas de classes por varias coisas como evitar classes duplicadas... qdo a um projeto de uns 30 programadores e varios recebem uma tarefa sobre o mesmo modulo concorrentemente... sem um diagrama de classe e uma ordem a fazer as coisas fica realmente uma bagunça o projeto... e tbm tal diagrama facilita a compreensão da interação dos objetos no sistema... porem é algo muito custoso para ser implementado em sistemas pequenos ou com poucos desenvolvedores envolvidos... mas em grandes sistemas o esforço compensa... mas um diagrama que acho que não deveria faltar em CRUD nenhum é o diagrama de ER (entidade relacionamento) em um crud seu interagir com o banco é muito frequente... se vc não souber a estrutura do banco não tem como fazer nada...

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 495 Offline

rodrigoy wrote:

Beck (Extreme Programming Explained, 2nd Edition wrote:
Ivar Jacobson, Magnus Christerson, Parik Jonsson, and Gunnar Overgaard , Object-Oriented Software Engineering: A Case Driven Approach, Addison-Wesley, 1992; ISBN 0201544350.
My source for driving development from stories (use cases).

Ok. Vamos analisar as duas referências que ele faz a "use cases" no livro dele. Já as referências a "stories" são incontáveis.

Referência 1 (Capítulo 7):

Feedback also works at the scale of weeks and months. The customers and testers write
functional tests for all the stories (think "simplified use cases") implemented by the system.

Referência 2 (Bibliografia):

Ivar Jacobson, Object-Oriented Software Engineering: A Case Driven Approach, Addison-
Wesley, 1992; ISBN 0201544350.
My source for driving development from stories (use cases).

Entendo que as duas referências que ele faz são meramente com a finalidade de orientar o leitor sobre o conceito de "stories" e não de afirmar que stories = use cases. Aliás, se vc analisar a primeira, pode interpretar como uma crítica o "think simplified use cases". Obviamente, aqui ele refere-se ao rigor formalista da técnica.

Sem querer desmerecer o Jacobson (e concordo com vc que ele criou um método bastante interessante para lidar com requisitos), mas ele mesmo admite que foi mal-compreendido pelas pessoas que tentavam aplicar a técnica. Além disso, outros agilistas como Scott Ambler "descem a lenha" em Use Cases.

Resumo: stories != use cases

Taz wrote:
Entendo que as duas referências que ele faz são meramente com a finalidade de orientar o leitor sobre o conceito de "stories" e não de afirmar que stories = use cases.

http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison wrote:
What's the difference between a UserStory and a UseCase?

Kent Beck: The idea of specifying the behavior of the system from an outside perspective, and using those specifications throughout the life of the system is the same. The execution is quite different.

Taz, como você sabe, o mercado tem uma força enorme de deturpar as coisas. A idéia é a mesma, porém, a forma que é utilizado no mercado é que é diferente. Você poderia dizer que stories != formal use cases. Aí sim eu concordaria. Determinadas histórias podem requerer uma formalidade maior. Sim, o Beck critica o modo formal.

Taz wrote:
Sem querer desmerecer o Jacobson (e concordo com vc que ele criou um método bastante interessante para lidar com requisitos), mas ele mesmo admite que foi mal-compreendido pelas pessoas que tentavam aplicar a técnica.

Ele diz isso com relação ao UP como um todo não com a técnica de use cases especificamente. Ele se vangloria bastante dos use cases ser a técnica a mais utilizada no mundo.

Taz wrote:
Além disso, outros agilistas como Scott Ambler "descem a lenha" em Use Cases.

O Ambler não gosta de Use Case-Driven e não dos casos de uso em geral. Mesmo que você não faça diagramas, mesmo que não escreva nenhum texto os casos de uso vão continuar a existir. Nenhum sistema funciona sem estímulos externos e execução atômica de procedimentos.

De qualquer forma essa discussãozinha é pouco produtiva. Só quero que vc entenda que casos de uso não precisam ser formais. Falo muito sobre isso em meus cursos.

This message was edited 1 time. Last update was at 12/05/2008 12:48:15

@luistiagos

extenciveis? imprecendivel? Não seria extensíveis? imprescindível? Ia perder fácil no programa do Luciano Hulk.

Tirando a brincadeira de lado, não concordo com a sua opinião. Baseia-se numa visão estreita de mundo em que só existem duas opções possíveis e antagônicas, de um lado o desenvolvimento caótico e problemático (mau), de outro o desenvolvimento burocrático e previsível (bom).

Não vai demorar muito e você vai perceber que existem mais coisas entre o céu e a terra do que sonha sua vã filosofia. Exemplo 1: documentação em excesso não garante qualidade. Exemplo 2: waterfall não garante programas extensíveis. Exemplo 3: deixar os testes no final é garantia de que eles não serão feitos adequadamente. E por aí vai.

Sinceramente, a discussão está interessante, mas acho que estamos discutindo o sexo dos anjos.

Primeiro, porque nenhum modelo propõe-se a ser 100% formal. Especialmente se tratando da especificação de Use Cases. Isto é, na maior parte dos processos (incluindo o Processo Unificado), o documento que dá o formato de um Use Case pode ser tão simples quanto uma história, e nem precisa ser tão formal quanto o proposto pelo Cockburn - embora processos formais geralmente considerem isso aconselhavel, esse modelo não é imposto.

Da mesma forma, as práticas ágeis dão sempre a flexibilidade da equipe de desenvolvimento utilizar um método mais formal, se isso for mais adequado. É o que fazemos aqui, quando lidamos com clientes de outros países. Mas, no caso do desenvolvimento ágil, a orientação geral é simplificar. Ou seja, o aconselhável aqui é ir no sentido oposto e obter um processo simples.

Acho que essa é a lição importante de ambos os processos.

Dizer simplesmente "use cases são histórias" é uma simplificação perigosa. Mas também afirmar que "use cases não são histórias" é uma generalização incorreta.

JavaGuru Membro desde: 21/02/2008 10:01:31 Mensagens: 248 Offline

Eu vejo os diagramas como um aliado seu, vc monta o diagrama descrevendo aquela funcionalidade cabulosa do projeto e apresenta ao cliente, depois de ele ter concordado e vc implementado ele não tem como reclamar dizendo que não era isso que ele queria... Mas uma coisa que eu acho prática é ter uma pessoa só pra fazer os diagramas, o que soh acontece em grandes empresas, geralmente quem desenvolve, faz a analize de requisitos, diagramas, cronogramas etc etc etc...

This message was edited 1 time. Last update was at 12/05/2008 13:47:57

ViniGodoy wrote:
O que eu falei é que uma das premissas do Agile é que o usuário sabe o que quer ou, pelo menos, tem autonomia total de decisão. E, infelizmente, em alguns sistemas o analista acaba agindo como mediador e, infelizmente também, temos que usar a documentação como arma - o que justamente o agile quer evitar.

A premissa do Agile não é o usuário saber o que quer mas permitir que as decisoes sejam tomadas no "last-responsible-moment".

Ao invés disso o que se vê é projetos onde analistas de sistemas são alocados pra fazer BDUF achando que isso vai suprir a necessidade do cliente como parte do desenvolvimento. Quando comeca a implementação os analistas de sistemas são descartados e o que resta são diagramas e schemas com o deadline pra ontem.

Com o papel inutil do analista de sistemas sendo substituído por uma interação diretamente com o cliente (sob a figura do product owner) as reuniões são mais frequentes e ao invés de contemplar figurinhas desenhadas o foco passa a ser o entendimento do que deve ser implementado naquela iteração, nem que pra isso seja necessário desenhar alguns digramas UML num quadro branco ou num papel de pao.

JavaEvangelist Membro desde: 23/10/2007 10:08:29 Mensagens: 470 Offline

luistiagos wrote:acho besteira usar estes diagramas em projetos muito pequenos e não extenciveis ou pouco extenciveis mas acho primordial usar em projetos grandes e extenciveis... trabalho em um projeto gigantesco que a muito pouco diagramas... e isto as vezes gera confusões, dificuldade de entendimento de processos e do funcionamento de certas funções e duplicidade de algumas classes... pois é imprecendivel um diagrama de Caso de Uso para entender como determinado escopo do sistema vai interagir e quem são os atores e suas ações... isto faz com que vc entenda o sistema... e tbm é importante diagramas de classes por varias coisas como evitar classes duplicadas... qdo a um projeto de uns 30 programadores e varios recebem uma tarefa sobre o mesmo modulo concorrentemente... sem um diagrama de classe e uma ordem a fazer as coisas fica realmente uma bagunça o projeto... e tbm tal diagrama facilita a compreensão da interação dos objetos no sistema... porem é algo muito custoso para ser implementado em sistemas pequenos ou com poucos desenvolvedores envolvidos... mas em grandes sistemas o esforço compensa... mas um diagrama que acho que não deveria faltar em CRUD nenhum é o diagrama de ER (entidade relacionamento) em um crud seu interagir com o banco é muito frequente... se vc não souber a estrutura do banco não tem como fazer nada...

Não existem projetos gigantescos e sim mal gerenciados, como é o caso quando existem 30 programadores trabalhando juntos!

Mas aí é que está. Existe um product owner, que é o sujeito que tem autonomia sobre o sistema e pode tomar decisões sozinho.
Na implantação de sistemas coorporativos, sobretudo quando existe modificações de processos e mudanças estruturais não só no sistema, mas na forma com que a empresa espera realizar o seu negócio, essa figura nem sempre existe da forma que a metodologia ágil prega.

Implantar sistemas assim tem várias complicações, que não estão presentes na maior parte dos sistemas. Entre elas, gerenciar conflitos, usuários que te boicotam com medo de uma demissão, boicote de gerentes, etc. Por isso também, cobra-se milhões em projetos assim.

cmoscoso wrote:Não existem projetos gigantescos e sim mal gerenciados, como é o caso quando existem 30 programadores trabalhando juntos!

Não? O que dizer de centrais telefônicas, jogos, sistemas operacionais grandes (como o Windows), ou sistemas como SAPs?
Tudo mal gerenciado? Talvez você ainda não tenha participado de um projeto de grande magnitude. Mas existem projetos sérios com dezenas de programadores.

This message was edited 1 time. Last update was at 12/05/2008 15:08:43

ViniGodoy wrote:
Na implantação de sistemas coorporativos, sobretudo quando existe modificações de processos e mudanças estruturais não só no sistema, mas na forma com que a empresa espera realizar o seu negócio, essa figura nem sempre existe da forma que a metodologia ágil prega.

Que forma você se refere especificamente que a metodologia prega?

This message was edited 1 time. Last update was at 12/05/2008 15:14:05

ViniGodoy wrote:Não? O que dizer de centrais telefônicas, jogos, sistemas operacionais grandes (como o Windows), ou sistemas como SAPs?

É isso que você faz no seu dia-a-dia?

ViniGodoy wrote:
Talvez você ainda não tenha participado de um projeto de grande magnitude.

Pode ser. Ou talvez sua idéia de projeto esteja limitada à uma visão monolitica.

Nesse caso se faz valer uma boa gerência seja para a dificil tarefa de conciliar tantos interesses diversos seja para ajudar a ampliar o horizonte!

cmoscoso wrote:É isso que você faz no seu dia-a-dia?

Não. Mas, como eu falei, nós aqui no meu setor usamos o Extreme Programming, que é um processo ágil. Aliás, eu sou 100% a favor de processos ágeis.

Mas setor aqui do lado tem mais de 30 pessoas que fazem software de centrais telefônicas, aqui na Siemens. Além deles tem o pessoal do firmware, mas como estamos falando de processos de software, não entremos nesse quesito.

Acho muito difícil imaginar um processo menos burocrático, já que a equipe é grande, os requisitos vem da Alemanha e muitas vezes a visão do cliente se baseia em pesquisas estatísticas sobre o mercado consumidor. Além disso, há custos envolvendo também hardware e um erro de dimensionamento do software da central pode se tornar muito caro.

A correção do software no cliente, uma vez que é produzido e distribuída em escala, num equipamento que muitas vezes não aceita updates automáticos, também não é simples como no caso de software de prateleira. Só para se ter uma idéia, existe um outro departamento inteiro só focado em testes e rigorosas especificações de qualidade.

No caso dos processos ágeis usamos um pressuposto, que é válido para a absurda maioria dos sofwares, que é o de que modificar programas é relativamente fácil e barato. O que não é válido para o pessoal aqui do lado, mas é bastante válido em meu setor.

cmoscoso wrote:Pode ser. Ou talvez sua idéia de projeto esteja limitada à uma visão monolitica.

Veja bem. Estou mesmo falando apenas situações bem específicas, onde acho que o processo mais burocrático em regime de mini-waterfall se encaixa melhor do que o processo ágil. Para as demais situações, e creio que sejam a absurda maioria, também sou partidário do desenvolvimento ágil.

Não me anima nem um pouco sair do processo ágil para voltar a enfrentar longas etapas de diagramação, descrições de casos de uso, diagramas de sequência, páginas e páginas de textos...

JavaEvangelist Membro desde: 23/10/2007 10:08:29 Mensagens: 470 Offline

ViniGodoy wrote:
Mas existem projetos sérios com dezenas de programadores.

Projetos sérios também falham, não é brincadeira!

Smalltalk Membro desde: 12/05/2008 16:02:43 Mensagens: 2 Offline

A discussão parece bem interessante e gostaria de comentar.
Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.
Como fazer isso sem utilizar diagramas UML??