Fim do Waterfall = Fim do Analista?

JavaEvangelist Membro desde: 30/04/2007 07:43:01 Mensagens: 425 Online

Mauricio Linhares wrote:

celso.martins wrote:Pois é... nunca achei muito lógico esses papéis distintos. Levando só para o lado da UML, o analista modelaria a solução, mas o programador deveria conhecer a UML para entender o modelo do Analista. Isso subjulgava o programador, dizendo, creio eu, que ele não era capaz de compreender um problema e modelar a solução.

Mas aí é que está o problema. A maior parte dos softwares não pode ser modelada em UML, porque ela é restrita demais em termos de "programação", o máximo que acontece é o analista chegar com um rascunho do que ele imagina, rascunho esse que seria muito bem mais aproveitável se feito pela equipe de desenvolvedores em vez de sair direto de um único "analista". Se fosse possível programar a maior parte dos sistemas só com UML, o Maker já teria tomado o emprego de todo mundo aqui.

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente "traduzam" os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

concordo plenamente com você.

This message was edited 4 times. Last update was at 26/03/2009 09:34:49

Bruno Laturner wrote:
Pergunta: O que você fará com este UML? Ou melhor, de que forma ele está te ajudando a desenvolver?

Acho que já coloquei isso antes:

Acrescentando: UML especializa subconjuntos da notação para áreas de assunto comum.

O UML representa o sistema em diferentes atuações. E é uma linguagem Visual. Visualização é um termo chave.

UML pode representar todo seu sistema para os Analistas, para você mesmo, para os Designers; UML documenta o sistema, a arquitetura de pacotes, a lógica, o dominio...

Na prática, essa visualização, fará grande diferença, quando em um quadro, quem diagrama, percebe o quanto sua visão do projeto estava mal elaborada e refaz ela talvez uma dezenas de vezes até chegar a um bom modelo.

Sabendo que em um projeto, são em maior número os que codificam. Faça um cálculo parecido com isso: N modificações modelo x qtd programadores x qtd de implementações = qtd de re-trabalho.

Para um exército de um homem só, pense em deixar um testamento UML para o proxímo.

IMHO

Infelizmente papel, e diagramas, aceitam tudo.

Mauricio Linhares wrote:
Mas aí é que está o problema. A maior parte dos softwares não pode ser modelada em UML, porque ela é restrita demais em termos de "programação"...

Qual software não pode ser modelado em UML?

Mauricio Linhares wrote:
o máximo que acontece é o analista chegar com um rascunho do que ele imagina, rascunho esse que seria muito bem mais aproveitável se feito pela equipe de desenvolvedores em vez de sair direto de um único "analista".

Dinâmica do time não é escopo da UML, nem mesmo quem modela... O uso de artefatos para "se comunicar" sempre foi uma aberração... uma coisa que se imbutiu nos times sem qualquer lógica ou fundamentação..

http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/

Mauricio Linhares wrote:
Se fosse possível programar a maior parte dos sistemas só com UML, o Maker já teria tomado o emprego de todo mundo aqui.

O Maker não é baseado em fluxograma? Fluxograma não é UML..

Já trabalhei numa fábrica onde a visão do gestor era contratar bons analistas e programadores paguás... afinal, um bom modelo é o que há... Francamente!!!

rodrigoy wrote:Qual software não pode ser modelado em UML?

Você pode "modelar" qualquer sistema em UML, mas isso não garante que a "modelagem" vá servir de alguma coisa além de papel higiênico, porque a UML não vai conseguir tratar de coisas simples como "abra o arquivo, processe, trate as exceções e feche o arquivo independentemente do que acontecer" de forma simples como código. Você vai ter um diagrama de sequência bizarro que é basicamente inútil do ponto de vista da programação.

rodrigoy wrote:O Maker não é baseado em fluxograma? Fluxograma não é UML.

Se fosse possível programar sistemas em UML, geradores de código como o Maker ou os "executable UML" da vida já teriam resolvido todos os problemas do mundo.

UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

rodrigoy wrote:Já trabalhei numa fábrica onde a visão do gestor era contratar bons analistas e programadores paguás... afinal, um bom modelo é o que há... Francamente!!!

Bem, não sei o que é paguá... mas pela colocação na frase imagino que não seja algo bom... =)

Só não imagino como isso funcionaria, pois não consigo visualizar como um bom modelo pode ser transformar num bom sistema sem programadores competentes. Não vejo como garantir a qualidade do que está sendo feito.

Como provavelmente você está falando em waterfall (O analista analisa, o programador programa e o testador testa, entregando todos os requisitos de uma só vez para o cliente), como adaptar modelo e código às mudanças que fatalmente acontecem durante o processo?

Mauricio Linhares wrote:
Você pode "modelar" qualquer sistema em UML, mas isso não garante que a "modelagem" vá servir de alguma coisa além de papel higiênico, porque a UML não vai conseguir tratar de coisas simples como "abra o arquivo, processe, trate as exceções e feche o arquivo independentemente do que acontecer" de forma simples como código. Você vai ter um diagrama de sequência bizarro que é basicamente inútil do ponto de vista da programação.

OK... UML nunca foi uma linguagem de programação (a não ser pelos devaneios da MDA, que um dia no passado defendí). Um modelo sempre foi e sempre será uma simplificação. Os detalhes estão no código.

Eu vejo aplicabilidade da UML na maioria dos sistemas que desenvolvo, porém, sempre como rascunho. Especificação firme nunca, a não ser que seja algo executável como JBPM...

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Mauricio Linhares wrote:
UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

Você programa Design patterns
Você programa Metadados
você programa o MVC
você programa a Arquitetura
você programa o Deployment
você programa o Container
Você programa a UML ?, a única coisa que vai lhe dar visão para a sua possível implementação, é única e exclusivamente a UML.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

[]s

This message was edited 1 time. Last update was at 26/03/2009 18:25:11

Marcio Duran wrote:Você programa a UML ?, a única coisa que vai lhe dar visão para a sua possível implementação, é única e exclusivamente a UML.

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja "única e exclusivamente".

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

victorwss wrote:

Marcio Duran wrote:Você programa a UML ?, a única coisa que vai lhe dar visão para a sua possível implementação, é única e exclusivamente a UML.

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja "única e exclusivamente".

A evolução do desenvolvimento de software em que na sua época não existia o pensamento de plataforma e onde você não encapsula codigos com regras de negócio isso tudo se expandiu para novos contexto de frameworks e assim por diante, não é possível você ter melhor mapeamento desses artefatos sem as anotações da UML, que lhe promove a geografia de onde esse objetos que estão implementados fazem sentido na sua aplicação.

victorwss wrote:

Marcio Duran wrote:Você programa a UML ?, a única coisa que vai lhe dar visão para a sua possível implementação, é única e exclusivamente a UML.

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja "única e exclusivamente".

Impossível não era, mas pelo que diz o pessoal que já programava profissionalmente nessa época, era quase.

No início da década de 90 havia o UON (Constantine, Weiss e Page-Jones), que, segundo Page-Jones, não conseguiu atender de forma satisfatória o objetivo de ser uma notação que abrangesse todas as construções encontradas nos sistemas orientado a objeto. Depois vieram a EUON, OODN, mas que também nunca tiveram uma aceitação em massa na comunidade de desenvolvedores.

Page-Jones wrote:
"Now back to UML. It is a language with a semi-formal semantic specification that includes abstract syntax, well-formedness rules, and dynamic semantics. The UML can capture the structure of object-oriented systems at a level above that of individual lines of code, and it can be expressed in diagrams that span the gamut include, for instance, the class diagram (which features the constructs of inheritance, semantic association, composition, and aggregation), the sequence diagram, the collaboration diagram, and the state diagram.
A good design notation should show overall system structurein a graphic form...."
Nota de rodapé: My take: With only a few exceptions, they've done a very good job, because it's hard to meet all of these (sometimes opposing) goals.......

Não é a solução definitiva. Não é perfeita. Mas foi o mais próximo conseguiram chegar, até o momento.

Acredito que a má fama da UML seja devido a carência de ferramentas de integração com as IDEs. Estas ferramentas deveriam manter o diagrama atualizado com as modificações do código (realmente, é chato demais ficar replicando as alterações no código no diagrama). Já utilizei o OMONDO e meu eclipse ficou tão pesado que acho que eu precisaria de um "deca-core" para rodar. Sem contar que os diagramas gerados na engenharia reversa ficam confusos demais e a tentativa de acerto é, literalmente, um parto. Posso não ter conseguido usar a ferramenta direito. Fiquei cerca de um mês insistindo, pois acreditava que se conseguisse usar da forma como é proposto pelos criadores do plugin a maioria dos meus problemas com a atualização UML-Código estariam resolvidos. Mas, infelizmente, não consegui. Não sei se foi culpa do plugin ou minha.

Abraços.

Mauricio Linhares wrote:
UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

Eu acho que é na comunicação que está a eficiência da UML. Concordo que para desenvolver seja quase inútil, já que você está com o sistema no sangue . Mas se o projeto for para mão de outra pessoa, acho que seria bom ter os diagramas. Facilitaria o entendimento.

E se esse projeto voltar com a documentação da equipe original e da equipe por onde ficou algum tempo, vai ajudar a conhecer as alterações que a outra equipe realizou e a lembrar as hierarquias, os relacionamentos, as atividades, etc.

This message was edited 1 time. Last update was at 27/03/2009 00:40:31

Acrescentando: Teste a priori. Em Desenvolvimento Dirigido por Testes, apoiado pelo PU, os testes são escritos primeiro.

Desenvolvimento Iterativo não é atuação Cawboy do programador. Desculpe-me a franquesa.

Não vejo como a UML não seja utilizada Em uma decente A/POO a UML é muito importante, embora, não seja um bala de prata.

A UML é vasta, muito ampla, e se você quiser ir a fundo com especificações do tipo: abra o arquivo, feche o arquivo, dá pra fazer sim. Mas no modelo Iterativo são deixadas as partes especulativas de um sistema.

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