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

Depende.

Se for para fazer um sistema grande, com múltiplos usuários e gerenciamento de conflitos interdepartamentais sim.
Se for escrever um livro, e quiser demonstrar com clareza um projeto ou idéias, sim também.

Agora, para sistemas onde um só usuário tem autonomia, acho melhor um processo ágil. Sem tanta diagramação.

ViniGodoy:

Depende.

Se for para fazer um sistema grande, com múltiplos usuários e gerenciamento de conflitos interdepartamentais sim.
Se for escrever um livro, e quiser demonstrar com clareza um projeto ou idéias, sim também.

Agora, para sistemas onde um só usuário tem autonomia, acho melhor um processo ágil. Sem tanta diagramação.

Agile só funciona para projetos pequenos -> MITO

dedejava:

Oi.
Minha pergunta é essa. Tem muito desenvolvedor que não uso diagramas de casos de uso, de classe, UML e derivados.
Gostaria de saber se os engenheiros atuais e mais ‘descolados’ usam.
Abraço.

Respondendo:

só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…

Taz:

só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa. Caso de uso simplesmente é um requisito atômico que pode ser capturado, analisado, implementado, testado (não necessariamente nesta ordem) e ao mesmo tempo agrega algum valor observável para os usuários.

O uso da UML muitas vezes é para discutir com a equipe ou com os usuários. Um modelo de casos de uso pode enriquecer ou entorpecer essa discussão. Um diagrama de classes é muito bom para discutir o domínio e chegar a um domain model mesmo que seja no papel.

De qualquer forma o uso da UML deve ser homeopático. UML não é documentação. Seja realista com relação à UML.

Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

Taz:

Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

Taz, o Kent Beck não faz diferença entre uma história e um caso de uso. Não vejo porque nós deveríamos fazer. A UML não define padrão para template nem para a narrativa e o diagrama é bem conciso. Se você está usando a prática de maneira correta não vejo porque taxar como burocrático ou dispendioso. Use Case é mais antigo que a UML.

Sei que essa não deve ser a resposta, mas se seu projeto não exige formalidade você pode usar os casos de uso no modo “brief use cases” e o desenvolvimento ficará muito próximo de User Stories.

dedejava:

Oi.
Minha pergunta é essa. Tem muito desenvolvedor que não uso diagramas de casos de uso, de classe, UML e derivados.
Gostaria de saber se os engenheiros atuais e mais ‘descolados’ usam.
Abraço.

Tirando o titulo engenheiro 8), isso fica a cargo do cliente e da equipe que esta desenvolvendo ( vide outras respostas).

Em alguns casos não dá para escapar de uma montanha de diagramas inuteis que no project equivalem a 80% do projeto, isso sem vc escreverf uma linha de código.

Pessoalmente eu prefiro utilizar tais diagramas apenas quando tenho dúvida em algum conceito ou funcionalidade, porém, muitas vezes o código fala por si só.

Bom eu só utilizo os diagramas de casos de uso quando as regras são meio confusas ou de dificil compreensão, acredite apesar da maioria dos casos de usos serem simples ha alguns bem chatos, mas somente nesses casos. Já diagramas de classes quase não uso acho que eles servem principalmente para conhecer o sistema que irá desenvolver ou dar manutenção ou para debater com a equipe e com o cliente, mas acredito que não seja uma coisa essencial.

Ele fala que são iguais? Referências?

rodrigoy:

Sei que essa não deve ser a resposta, mas se seu projeto não exige formalidade você pode usar os casos de uso no modo “brief use cases” e o desenvolvimento ficará muito próximo de User Stories.

IMHO, essa é a resposta: eu e minha equipe usaremos o que acharmos melhor.

Ops… ops… não foi o que eu falei. Até porque, temos tocado projetos bastante grandes com agile development aqui.

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.

Tente implementar um sistema onde há conflitos de interesses entre os setores e você vai perceber o que estou falando. E não precisa ser um sistema grande. Aliás, na prática, nada funciona quanto há esse tipo de conflito.

ViniGodoy:

Tente implementar um sistema onde há conflitos de interesses entre os setores e você vai perceber o que estou falando. E não precisa ser um sistema grande. Aliás, na prática, nada funciona quanto há esse tipo de conflito.

Nem tentaria. Existe um princípio de administração chamado de amplitude de controle que diz que um departamento/funcionário/projeto não pode ter dois chefes. Se vc tem, vc tem um problema gerencial que documentação não resolverá. A melhor caminho é sentar com os dois para resolver o conflito. Se eles não resolverem, escale para os chefes deles…

As vezes o conflito ocorre entre o chefe, que quer mudanças de processo, e o gerente, que vai te boicotar, já que tem medo de perder autonomia/poder. Ou mesmo entre gerente (que quer mudanças) e funcionário (que pensa que será demitido, ou provavelmente vai ser demitido, mas é quem conhece o detalhe do processo).

Não sei se você já passou por isso, mas nessa situação, é realmente muito difícil trabalhar. Pior ainda se você conseguiu esse projeto através de licitação, onde o problema irá ocorrer e você não poderá simplesmente virar as costas e abandonar o barco.

Aí infelizmente, somos obrigados a usar a documentação como arma. Não estou dizendo que apoio a prática, nem que ela é ideal, e nem que isso presta. É mesmo uma constatação triste. E triste também (para mim) foi eu já ter passado por isso, mais de uma vez, no passado.

Taz:

rodrigoy:

Taz, o Kent Beck não faz diferença entre uma história e um caso de uso.

Ele fala que são iguais? Referências?

O ponto é que a formalidade do Use Case pode variar. O Cockburn diz o mesmo. Como disse, caso de uso é um conceito muito mais antigo que a UML. Sou fã do Jacobson por essa contribuição dele. Caso de uso é muito mais uma ferramenta de gestão do que especificação de requisitos.

A solução para esse tipo de problema no Scrum é o Product Owner. O Product Owner deve ter a palavra final. Minha visão é que o Product Owner deve ser um de$graçado ganancio$o. Se você focar em obter ROI do projeto muitas besteiras caem por terra.

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…

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 [telefone removido].
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:

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.

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.

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.

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.

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

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…

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.

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.

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.

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

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

ViniGodoy:

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!

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.

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…

ViniGodoy:

Mas existem projetos sérios com dezenas de programadores.

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

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??

Sem dúvida, e o Longhorn que o diga.

Mas o que eu quis dizer é que existem situações em que justifica ter uma equipe tão grande. Diferentemente do que faz muita softwarehouse por aí, que quer impressionar o cliente, e contrata vários programadores de baixo conhecimento técnico só para cobrar caríssimo, sem que isso seja sequer justificável.

Ah sim, e elas ainda usam a documentação como uma forma de dizer que tem “padrões de qualidade”. Como se papel garantisse algum tipo de qualidade.

(Aliás, o oposto também vale. Tem muita gente usando a desculpa de que é ágil para fazer bagunça e justificar a ausência de processo, o que também não é correto).

Independente do cliente na alemenha alguem será eleito pra fazer a parte cliente on-site, e nao vale dizer que ta faltando pessoal!

Desculpe mas não vejo isso como falha da metodologia ja que ela esta preocupada em entregar software funcional. Isso nao exclui a necessidade de competencia para gerir sua cadeia de processos. Por exemplo, não acho que o tamanho do projeto deva se dar em funcao do numero de pessoas disponiveis e sim em funcao do que é possível ser gerenciado levando em conta as possibilidades. Grandes projetos precisam ser divididos para serem conquistados. Não com o objetivo primario de eliminar burocracia mas de permitir algo passível de ser gerenciado.

Se é uma caracteristica do seu negócio nao vejo porque nao pode ser suportado pelo processo ágil mas se também vocês adotam outra metodologia que lhe servem e permite desenvolver o software de qualidade que precisam ótimo, seria um bom estudo de caso!

O fato de haverem X mil programadores num projeto não traz necessidade de diagramas de classe, interação e etc como especificação formal ou mesmo documentação (apesar de haverem -poucos- casos onde isso seria útil). Como o Moscoso falou um projeto desse tem que ser dividido em projetos menores ara se tornar gerenciável.

Assim como ninuém nunca precisa nsultar um diagrama de classes do Hibernate para ver como ele funciona (para coisas simples uma página de wiki te basta, para coisas complexas a documentação é textual e baseada em exemplos) não é preciso mantêr diagramas em UML.

alexsander.santana:

Em projetos grandes utilizar automatização para geração de código através de MDA, traz muita agilidade ao processo.

Isso foi o que lhe contaram ou você já teve essa experiência?

Seria realmente ótimo se existisse essa figura. Teriam que distribuir uma pessoa para cada um dos 7 sites de desenvolvimento no mundo, que deveriam estar totalmente integradas com o projeto centralizado. Mas com um pouco de esforço acho que poderia ser feito.

Não entendi no contexto, isso o que?

Bom, acho que isso é meio óbvio, não? Dividir para conquistar é um lema de todos os processos sérios, desde os mais burocráticos até os mais simples. O número de pessoas pode não ser o único fator para definir se um projeto é grande ou complexo, mas certamente é um dos fatores.

Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained:
“It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially.”

O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.

Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.

Vini, eu entedi seu arument e concordo, só que para mim a quantidade de softwares que cai nessa exceção é bem menor e não inclui seus exemplos. Sobre Sisemas Operacionais, a Microsoft é um dos grandes nomes por trá de agile nos últimos anos e apesar de eu não conhecer a fundo o processo de desenvolvimento do kernel do Linux eu nunca coheci um projto livre de sucesso que fosse waterfall ou mesmo BDUF. Já trabalhei com telefonia o suficiente para saber que o problema é cultural, não tecnológico (convencer engenheiros a não fazer um mega-projeto numa ferramenta CAD, ops, CASE é algo complicado) e sobre jogos , apesar de não ter experiência,eu tenho um exemplo bem interessante:

http://www.se-radio.net/podcast/2008-04/episode-92-introduction-game-development

É engraçado como o processo de desenvolvimento é descrito, extremamente iterativo e incremental, e como o entrevistado fala que processos burocráticos servem apenas para sotware comercial em grandes empresas.

alexsander.santana:

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??

Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.

O processo de desenvolvimento do kernel do Linux não é nada muito complexo.

Existe um grupo de responsáveis por cada parte (os maintainers) e os desenvolvedores mandam patches, normalmente para uma lista de discussão. As pessoas comentam, mandam sugestões/correções e quem dá a palavra final é o responsável, que no final do processo adiciona o patch ao kernel.

Esse artigo mostra com detalhes como funciona o processo.

dividir o projto em menores para não precisar utilizar tais documentações e uma boa…
mas e em casos onde o projeto e muito integrado como fica?

O maior problema é o custo do software que vai embarcado para o cliente, ou que acompanha o hardware (e não necessariamente é embarcado, mas gravado em memória flash ou outro dispositivo que ficará isolado de uma rede e, portanto, não sujeito a updates automáticos).

Esse software sim, é caríssimo de se modificar. Mas também concordo (e por isso venho tentando convencer o pessoal de adotar mais técnicas ágeis por aqui), que boa parte do processo poderia ser, no mínimo, mais ágil. E que nem todas as etapas do processo precisam necessariamente ser burocráticas.

Os processos ágeis, na minha opinião, foram os primeiros a encarar software realmente como ele é: software. E não a utilizar uma abordagem inspirada na engenharia civil.

Quanto aos exemplos, eu só estava citando casos de software de grande porte, em que se justificava ter vários programadores. Não falava exatamente do fato disso ser aplicável a processos ágeis ou não.

Quanto aos jogos: Eu acho o desenvolvimento de jogos ainda é burocrático demais hoje. Tenho defendido um processo mais interativo e práticas ágeis no desenvolvimento há muito tempo. Mas por lá, também existe uma séria dificuldade cultural. Me deixou feliz saber que a Hoplon, desenvolvedora do Taikodom inspirou-se muito em processos ágeis para melhorar o seu ciclo produtivo. Ainda no GamaSutra surgem artigos de grandes figuras no mundo dos games defendendo um processo muito próximo do RUP. Claro, já existem movimentos no sentido contrário, o que creio que será realmente a tendência futura.

ViniGodoy:

Não entendi no contexto, isso o que?

Suportar essa caracteristica de nao poder atualizar o sw, concordo que é uma situção diferente do “normal” mas processos podem ser estendidos para atender suas necessidades, dizer que agile nao funciona aqui é desconsiderar varios outros principios que ainda seriam util para o desenvolvimento como todo.

ViniGodoy:

Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained:
“It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially.”

O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.

Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.

Nao é facil introduzir Agile numa organizacao justamente pelo fato de nao haver one-size-fits-all e como disse o Phillip agile nao é velocidade. Se algumas coisas precisam ser de um jeito sera que essa coisa inviabiliza estar sob a influencia do paradigma agil?

Se essa coisa é não poder atualizar o software no cliente eu diria que ainda vale muito a pena agora se estamos falando em equipes de 30 programadores aí nao há como suportar devido ao overhead de comunicacao.

pcalcado:

Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.

E sendo UML uma GPL é necessário alterar o código gerado para implementar o que nao foi capturado na linguagem de modelagem. Como isso é suportado pelo MDA sem inviabilizar o processo? Esse é o problema que LOP pretende resolver?

Taz:

rodrigoy:

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa.

Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

Quando você fala “Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML.”… eu concordo com isso.
Não gosto muito de fazer casos de uso porque tenho a mania de colocar muitos casos de uso no sistema. Não sei se é um problema de iniciante, mas tenho que corrigir isso urgentemente.

Não sou engenheiro (ainda), mas eu usaria casos de uso quando o funcionamento da empresa estivesse complicado de entender. Seria correto fazer isso?

Concordo em grau, número e gênero. É similiar ao diploma: alguns não tem e dão um cacet* em quem tem.

Mesmo quando a UML deixa as coisas mais claras entre os desenvolvedores?

Estou gostando da discussão… aprendo bastante com grandes nomes aqui do Forum.
Abraço.

Depende. O que é “complicado”?

O último projeto que participei com Casos de Usos era para refazer o sistema das lojas de uma Telco. Isso é complicado? Depois que uma 3 letrinhas foi expulsa do projeto, o pessoal ficou 2 meses tentando “fechar” os 54 Casos de Usos (idéia maldita de outro fornecedor de 3 letrinhas) com os usuários e tivemos 1 semana para fazer o protótipo com o agravante os Casos de Usos estavam muito mal escritos e só criavam “bate-cabeça”. Isso é complicado!!!

A saída foi criar um mapa de navegação (Diagrama de Estados) do projeto para que a equipe pudesse captar a essência do projeto e detectar pontos de sobreposição e oportunidades de reuso.

Ahhh, e CASOS DE USOS SÃO BEM DIFERENTES DE ESTÓRIAS.

Ministrei um treinamento numa empresa que faz o software das centrais telefônicas da Ericsson. O fato é que nesses ambientes o nível de incerteza é menor: requisitos estáveis e arquitetura estática. Esse tipo de software tem uma grande porcentagem de sucesso usando Waterfall (mas sempre tem aquela correria no fim do projeto). Porém, creio que eles também poderiam se beneficiar muito de um modelo iterativo.

De fato o modelo MDA não presume o uso da UML, porém, por força do mercado, a transformação de modelos das ferramentas que temos hoje se baseiam na UML. De qualquer forma, não creio que só a UML seja suficiente para uma transformação eficiente.

A questão é que o custo de manutenção de um modelo não vale a pena. Geralmente usamos a UML para discutir dentro da equipe. Esses diagramas na maioria das vezes são feitos no papel e depois que as coisas “ficaram claras” o diagrama vai pro lixo.

Eu também uso a UML na concepção ágil. Também são diagramas feitos no papel e servem para que fique claro o tamanho funcional do software, aliado a histórias (também conhecidas como Casos de Uso - tinha que dar o troco né Taz :lol: ) capturadas em Index Cards e também protótipos visuais.

rodrigoy:

De fato o modelo MDA não presume o uso da UML, porém, por força do mercado, a transformação de modelos das ferramentas que temos hoje se baseiam na UML. De qualquer forma, não creio que só a UML seja suficiente para uma transformação eficiente.

Alguns slides de workshops e outros treinamentos de MDA que eu li recomendam inclusive a criação de um metamodelo intermediario antes do produto final da transformação, para que o processo de transformação não se prenda a um metamodelo especifico.

hehehe… olha vc provocando…

Se, HOJE, todo mundo chama de estória, pq ser diferente?

Sim, “UC (Use Case) é mais antigo que a UML”. Mas, HOJE, OFICIALMENTE, UC faz parte da UML e é aquilo que está definido na OMG (http://www.omg.org/docs/formal/07-11-02.pdf). Que tal chamarmos de UC o que HOJE, OFICIALMENTE, entende-se como UC!?

Ou vc não ensina para seus pupilos que uma linguagem de domínio não deve ter ambiguidade? Veja que esse tipo de discussão é completamente relevante seja quando falamos de um domínio de negócio, seja quando falamos de processos de software!!

E torna-se ainda mais relevante pq estamos discutindo a utilidade ou não de uma ferramenta em detrimento de outra. Acho que vc não quer admitir que UCs já morreram (saudosismo!?) e chama de “light UC” o que deveria chamar de user story.

Já te falei que a especificação da UML não entra no mérito da narrativa, a parte que você reclama da formalidade (acredite eu conheço um pouquinho dessa especificação). Posso usar UC sem usar o diagrama. A questão é que talvez histórias juntem objetivos dos usuários a features simples, o que não acontece com casos de uso.

Vai falar isso para o Kent Beck!!! Casos de Uso são mais antigos que histórias também!

UCs já morreram?! De onde você tirou essa? Praticamente 90% das empresas que tenho contato usam UCs. Taz, pra mim não interessa o nome. Os dois tem o mesmo objetivo. Se eu gerencio usando Index Cards o que consta nos cartões são funcionalidades que agregam valor aos usuários. Mais uma vez: não vejo diferenças entre UCs e Stories porque UCs não precisam ser formais. A questão não é saudosismo. Pra mim é não se render a essas modinhas. O conceito foi cunhado pelo Jacobson e precisamos dar mérito.

Você não estão confundindo diagramas de caso de uso com caso de uso?

Calma povo

Já te falei que a especificação da UML não entra no mérito da narrativa …

E o que quer dizer isso?

UML - Guia do Usuário (Jacobson, Booch, Rumbaugh) (em português) -pág 222:

quote Você pode especificar o comportamento de um UC pela descrição do fluxo de eventos no texto de maneira suficientemente clara para que alguém de fora possa compreendê-lo facilmente. Ao escrever o fluxo de eventos, você deverá incluir como e quando o UC inicia e termina, quando o UC interage com atores e quais objetos são transferidos e o fluxo básico e fluxo alternativo do comportamento.

Por exemplo, no contexto de um sistema de caixa eletrônico, você poderá descrever o UC ValidateUser da seguinte maneira:

Fluxo de eventos principal: …

Fluxo excepcional de eventos 1: …

Fluxo excepcional de eventos 2: …

Fluxo excepcional de eventos 3: …

(…)[/quote]

Taz:

E o que quer dizer isso?

UML - Guia do Usuário (Jacobson, Booch, Rumbaugh) (em português) -pág 222:

(…) Você pode especificar o comportamento de um UC pela descrição do fluxo de eventos

Quer dizer que você PODE e não que DEVE SEMPRE usar descrição do fluxo. Infelizmente não estou com meu livro aqui, mas tanto o Jacobson, o Larman e o Cockburn dizem que uma breve descrição pode ser suficiente para um caso de uso.

Não olhe para o conceito do jeito que o mercado aplica. Já ví caso de uso com 167 páginas. Já ví 16 horas para escrita de um caso de uso num cronograma. Não se anime tanto que com as histórias não vai ser diferente. Daqui a pouco teremos templates para escrita de histórias com papel cartão e “campinhos” obrigatórios para preencher com folha de horas anexa.

Amigos, sei que isso não é exatamente o que o tópico trata, mas como citei sobre o assunto neste tópico, escreví sobre esse tal desgraçado ganancioso no meu blog:

Abraços!

Eu encaro o que foi escrito no livro como uma FORTE SUGESTÃO, assim como o “mercado”. Isso é algo parecido com “Se é pra usar UC, faça dessa maneira…”. Mas obviamente, pessoas diferentes podem achar interpretações mais convenientes para as palavras.

rodrigoy:

Daqui a pouco teremos templates para escrita de histórias com papel cartão e “campinhos” obrigatórios para preencher com folha de horas anexa.

Isso parece com algum “template” que contém “campinhos obrigatórios para preencher com folha de horas anexa”? Ou com Casos de Usos de 200 páginas?

http://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310320

http://opensource.atlassian.com/projects/hibernate/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10010

Repare na simplicidade e na atomicidade dos requisitos, afinal, continuamos falando de software.

Taz, concordo com você que especificar requisitos em artefatos fora do código não é uma boa idéia (ao menos que esses artefatos sejam executáveis como o FIT). Aliás, vejo uma forte tendência para especificar requisitos usando essas ferramentas no lugar dos próprios cards.

Não concordo com seus exemplos pois são projetos internos de tecnologia (frameworks). Nesse tipo de projeto o gap de entendimento é praticamente zero. Além disso, nada me impede de especificar uma história de maneira mais formal também se necessário.

Será que só empresas que desenvolvem frameworks utilizam ferramentas como Jira/Trac/Bugzilla?

Como assim “gap de entendimento”? Explique melhor. IMHO, seja software comercial, seja framework, tudo no fim das contas é software e possui a mesma dinâmica.

Hoje eu uso Trac e sou feliz por me ver livre dos UCs. E é por isso que vc percebe uma tendência na direção de ferramentas de issue tracking.

Eu uso o Trac. Apesar de ser raro às vezes escrevo casos de uso lá em reuniões com o cliente.

Quando alguém abre um bug no Hibernate e cita “Criteria API” tanto o cara que abre o bug como o cara que vai pegar o bug sabe o que é isso. O dia que você pegar uma história ou UC que citar algo como “Puncão de Port - a - cath” você saberá o que é GAP de entendimento. Iria ser muito fácil desenvolver software se tudo possui a mesma dinâmica. Esse software da Punção, se você era um perfil etário numa infusão não é um bug, talvez algumas criancinhas morram. Construir prédio possui tudo a mesma dinâmica. Construir software não.

Você é contra qualquer tipo de modelagem?

Exatamente!!! Vc acaba de provar que A DINÂMICA É A MESMA. O “gap de entendimento” existe para um projeto que usa Hibernate ou para um projeto que usa o conceito de “Punção não sei das quantas”. Eu levaria uma ou duas semanas (será?) para entender a terminologia de um sistema hospitalar, assim como uma pessoa que nunca trabalhou com Hibernate demoraria uma ou duas semanas (será?) para entender o que é Criteria e dominar a terminologia . Depois de algum tempo em contato com a terminologia da aplicação e do framework o desenvolvedor pode tanto entender o que o significa uma “Punção de try-catch” no ticket #200 como pode abrir novas requisições de melhorias para equipe do Hibernate.

Releia os meus posts…

rodrigoy:

Taz:

só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa. Caso de uso simplesmente é um requisito atômico que pode ser capturado, analisado, implementado, testado (não necessariamente nesta ordem) e ao mesmo tempo agrega algum valor observável para os usuários.

Não no detalhamento (descrição), mas acredito que existe um formalismo sim, como você mesmo citou: resultado observável, atômico, na perspectiva do ator. (Interação ator sistema).

Não sei se Historia possui essa semântica, acredito que seja menos restritiva, mas pode ser substituída por UC com vantagens.

O valor de um UC de verdade - CRUD não é UC e UC representa uma solução para requisitos (não de implementação) - já esta bem reconhecido. Inclusive eh um dos pilares do RUP.

Taz:

só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…

Apenas porque duas coisas estão relacionadas - UML e sistemas fracassados - não implica necessariamente que uma seja conseqüência da outra. Temos apenas uma relação, não revela mais nada. 

Elevar o Nível de Abstração ajuda controlar complexidade. Se as abstrações criadas, com diagramas UML, estão sendo perda de tempo, o problema normalmente está na escolha das abstrações que vão realmente ajudar.

Não estamos falando de documentação, mas sim de modelos.

Como todos sabem - UML sozinha não ajuda - é necessário um método.
Considerações que podem contribuir:

[list]Diagramas precisam de contexto/objetivo/nível de abstração. Um diagrama como, por exemplo, de classes, sem especificar seu objetivo, não diz quase nada. Devemos especificar sua abstração, por exemplo: modelo conceitual focando na decomposição de domínio para divisão de subsistemas no Caso de Uso XX. O diagrama mostra uma abstração, ou seja, o que não aparece não significa que não exista. (também neste exemplo, a UML não é documentação, apenas uma ferramenta para dividir sistemas)[/list]

[list]Um dos principais usos da UML é mostrar a espinha dorsal da arquitetura, ou seja, suas principais abstrações e relacionamentos para padronização e organização do sistema. Neste caso, registrando também as principais decisões arquiteturais, as lições aprendidas.[/list]

[list]Muitos diagramas são idênticos ao código, neste caso, a abstração é pequena e talvez não justifique UML. Ainda neste caso, ferramentas podem mostrar as dependências (classe, pacote, subsistema) de forma gráfica, analisando diretamente o código.
[/list]

Gustavo Serafim:

[list]Muitos diagramas são idênticos ao código, neste caso, a abstração é pequena e talvez não justifique UML. Ainda neste caso, ferramentas podem mostrar as dependências (classe, pacote, subsistema) de forma gráfica, analisando diretamente o código.
[/list]

Relembrando os velhos tempos : que diagrama hoje em dia não vai ser próximo, mas muito próximo mesmo, de 1-para-1 com código? E as ferramentas que fazem isso trabalham com modelos executáveis (i.e. código) e ainda temos ferramentas como JDepend, PMD e amigos que fazem isso sem sequer saber o que é UML.

Eu quis dizer isso. Existem ferramentas para elevar a abstração e mostrar dependências de pacotes e classes com ou sem UML. Algumas utilizam UML, aproveitando a semântica já conhecida. Assim, muitos diagramas são dispensados para analise de código e algumas tomadas de decisões arquiteturais.

Claro que essas ferramentas não analisam o negócio. O que é uma agregação para um negócio, pode ser uma composição para outro, ou até mesmo apenas uma associação. Isso influencia diretamente a arquitetura corporativa.

A UML ainda é a melhor maneira de validar essas abstrações (associações, heranças, conceitos) com o usuário, deixando o código, no final, mais aderente ao negócio.

Gostaria de sugerir uma ferramenta para sua lista que tive oportunidade de usar: discoverer , Screenshot

Com o código pronto eu concordo.

Seguindo meu exemplo anterior, se for necessário projetar de forma incremental componentes de negócio corporativos, garantindo que os conceitos tratados fiquem em conformidade com o negócio?

Neste caso, para um acoplamento fraco na perspectiva do negócio, os componentes de negócio são identificados decompondo-se o domínio da aplicação (modelo de classe conceitual) observando os objetos principais (conceitos mais fortes do negócio) e o tipo de associação (agregação, herança…) entre os objetos relacionados.

Nem sempre e possível validar esses conceitos com usuário somente com o código. O uso de Agregação ou Associação, por exemplo, não altera o código, mas é importante para a arquitetura ("fatiar componentes’, responsabilidades em uma integração).

Criar esses componentes de negocio, ou seja, abstrair os objetos, envolve uso de ferramentas como, por exemplo, a UML. Contudo, como você sabe, manter modelos como documentação normalmente não e viável.

A UML é tão eficaz em resolver o que ela se propõe a fazer quanto o Java!
Falar que a UML é “perda de tempo”, ou “papel inútil” é uma afirmação um tanto quanto “burra” !
A UML, desde que utilizada de maneira correta e por quem sabe, é de grande valia, ajudando a reduzir tempo, custo e aumentando a qualidade de qualquer projeto.
Claro que não precisa utilizar todos os diagramas da especificação.
Afirmar que Casos de Uso são histórias que não agregam nada a um projeto, é uma típica resposta de pessoas bitoladas que não sabem abstrair as necessidades de um projeto, tentando resolver tudo sempre com o olhar de quem domina uma linguagem muito bem, mais não entende nada de planejamento.
Casos de Uso, assim como a UML, tem o objetivo principal de manter o conhecimento em modelos, e não em pessoas.
Assim como as metodologias ágeis, a UML tem e sempre terá um papel muito importante no mundo orientado a objetos.

To com o povo dos ultimos posts ai…

Acho que o pessoal que usa diagramas, usa a fundo e querem por tudo em “desenhos”… Já o pessoal que não usa, larga mão mesmo… !!!

Tem que saber equilibrar!!!

Uma coisa que ja falaram ai, esse monte de diagrama ajudam a definir um modelo, e não o código diretamente.

Sou a favor de usar UML para se ter uma visão ampla do que esta sendo feito e pra onde as coisas estão indo, alem da fonte de doucmentação essencial para o futuro.

Agora, usar todos os diagramas UML a fundo até chegar ao ponto de gerar o código é um exagero…

Ao meu ver, UML te ajuda a definir o modelo do projeto e quais os principais pontos a serem analisadose ponto.

Como o gerente aki mesmo diz, “Ficar masturbando muito uma coisa acabada melando!. Pegou a idéia de como vai ser… vai em frente”.

Fui !

A melhor maneira de validar qualquer coisa em tecnologia é com um modelo executável. UML não executa, não tem bug, não dá erro e, principalmente, não pode ser testada. Se existir qualquer métrica que você extrai de um modelo UML e não extrai do código (o contrário é verdade, BTW) não deve valer de muito já que -como UML não faz nada- ocê vai ter que transformar UML em código e perder esta característica da mesma forma.

Modelos visuais são muito úteis para comunicação mas em especificação eles agregam pouco valor.

Arquitetura executável. E “componentes de negócio” (como vendidos no UML Components e pelo CCE/PUC-Rio) já falharam na indústria há mais de dez anos.

Não há motivo para exstir um modelod e classe conceitual em primeiro lugar, se suas classes Java/C#/Ruby não refletem eu negócio vcê tem um problema (Domain Driven Design, Eric Evans). Associação e composição não possuem sintaxe mas possuem código sim, de controle de ciclo de vida. Elas são verificadas através de testes unitários.

Gustavo Serafim:

Criar esses componentes de negocio, ou seja, abstrair os objetos, envolve uso de ferramentas como, por exemplo, a UML. Contudo, como você sabe, manter modelos como documentação normalmente não e viável.

Não há porque envolver. Modelos executáveis te dão as mesmas métricas e com muito mais segurança. Quando desenvolver software envolvia transformar modelo de negócios em lógico e depois em físico isso era interessante mas há algum tempo desenolver software é criar um modelo físico que se arece ao máximo possível com o modelo de negócios, sem transformações intermediárias.

Eu não estou dizendo “não use UML”, estou dizendo para usar como ferramenta de comunicação e não especificação.

sapulha:

A UML é tão eficaz em resolver o que ela se propõe a fazer quanto o Java!
Falar que a UML é “perda de tempo”, ou “papel inútil” é uma afirmação um tanto quanto “burra” !

E qual sua crítica aos uros métodos de modelagem como TDD, Domain Driven Design e demais?

Um modelo UML não é executável, logo não pode ser verificado, se importa de explicar como essa validação é feita, esecialmente ocando o caso de uma regressão?

sapulha:

Afirmar que Casos de Uso são histórias que não agregam nada a um projeto, é uma típica resposta de pessoas bitoladas que não sabem abstrair as necessidades de um projeto, tentando resolver tudo sempre com o olhar de quem domina uma linguagem muito bem, mais não entende nada de planejamento.
Casos de Uso, assim como a UML, tem o objetivo principal de manter o conhecimento em modelos, e não em pessoas.
Assim como as metodologias ágeis, a UML tem e sempre terá um papel muito importante no mundo orientado a objetos.

Sugiro que você leia mais sobre os assuntos tratados neste tópico. Desculpe, mas parece que o ‘bitolado’ não é quem está propondo alternativas ao processo ineficiente de utilizar UML como especificação formal e sim quem não consegue enxergar que existem outras linguagens e técnicas para isso.

pcalcado:

A melhor maneira de validar qualquer coisa em tecnologia é com um modelo executável. UML não executa, não tem bug, não dá erro e, principalmente, não pode ser testada. Se existir qualquer métrica que você extrai de um modelo UML e não extrai do código (o contrário é verdade, BTW) não deve valer de muito já que -como UML não faz nada- ocê vai ter que transformar UML em código e perder esta característica da mesma forma.

Modelos visuais são muito úteis para comunicação mas em especificação eles agregam pouco valor.

Para validar conceitos a melhor estratégia e a gráfica (UML não tem que ser formal).
Você pode gerar os diagramas usando o código se preferir, mas perde semântica como, por exemplo, agregações e composição. (podem ser acrescentadas depois no modelo se preferir).

Não estou falando em comprar componentes em um mercado , mas organizar o código em subsistemas. Decomposição de domínio e uma técnica presente em varias abordagens atuais como , por exemplo, identificação de alguns tipos de serviços, o baixo acoplamento também.

Manter um modelo desses realmente é muito trabalho. Mas para analisar conceitos eles são muito úteis. Analisar, validar, não especificar um sistema. Contudo, em algumas abordagens são usados para gerar as classes de negócio, depois são descartados, assim podemos economizar tempo.

pcalcado:

Modelos executáveis te dão as mesmas métricas e com muito mais segurança. Quando desenvolver software envolvia transformar modelo de negócios em lógico e depois em físico isso era interessante mas há algum tempo desenolver software é criar um modelo físico que se arece ao máximo possível com o modelo de negócios, sem transformações intermediárias.

Eu não estou dizendo “não use UML”, estou dizendo para usar como ferramenta de comunicação e não especificação.

Não entendi, estou defendendo usar diretamente o código para essas análises. Agora, projetar dependências de subsistemas, pacotes e integrações eu prefiro usar abstrações UML.

Gustavo Serafim:

Para validar conceitos a melhor estratégia e a gráfica (UML não tem que ser formal).
Você pode gerar os diagramas usando o código se preferir, mas perde semântica como, por exemplo, agregações e composição. (podem ser acrescentadas depois no modelo se preferir).

Me diz como uma estratégia gráfica Não executável e não verificável automaticamente (i.e. UML) é melhor que uma estratégia executável, veríficável e quen, quando necessário, pode ser transformado em gráficos (i.e. sua linguagem de programação favorita).

Eu sei exatamente do que você está falando e é exatamente isso que já falhou há anos. SOA é uma tentativa de racionalizar a técnica, que az sentido, mas falar em desenvlver “componentes de negócio” é voltar para 2000 e pouquinho.

Não, como eu falei manter um modelo de classes não dá trabalho a mais alum, basta você ter um modelo apenas -o executável- e não trinta ontos de vista diferentes para a mesma coisa. Seu código é seu modelo.

Gustavo Serafim:

Não entendi, estou defendendo usar diretamente o código para essas análises. Agora, projetar dependências de subsistemas, pacotes e integrações eu prefiro usar abstrações UML.

Ok, preferência é algo que não se discute mas como falei antes em qualquer plataforma moderna (i.e. com menos de dez anos) dividir projeto e implementação é criar uma barreira que não existe mas -há uma década.

Existem engenheiros que só fazem diagramas? Acho que a maioria hoje em dia desenvolve um pouco do código, além de fazer os diagramas UML e aqueles de tempo.

Ixiiii entrou em loop…

Sim… os ruins que trabalham em empresas ruins!

O compilador: não valida conformidade dos conceitos com o negócio; não valida coesão e acoplamento nos diversos níveis de encapsulamento (método, classe, pacote, componente e ser preferir: serviço); não valida o efeito acumulativo de integrações com acoplamento forte no nível do negócio.

Uma abordagem gráfica ajuda analisar essas questões.

Eu não tenho referencias estatística para falar que essa abordagem falhou, talvez a abordagem apenas evoluiu. Gostaria de entender o contexto da sua conclusão.

Você não dividiria sua aplicação - em sistemas para grandes corporações - para controlar complexidade (efeito acumulativo) com interfaces bem definidas? Criaria outro sistema para controlar a complexidade ou não vê necessidade?

Manter muitas vistas? Acho que você está criticando uma metodologia burocrática ou processos de referencias - que as pessoas olham as descrições no template e acham que sabem usar - não a utilidade da UML.

Exemplo apenas ilustrativo e exagerado:
Algumas pessoas conseguem pensar estratégias em um jogo de xadrez somente olhando uma notação descritiva…, outras usam uma forma gráfica para facilitar:

Não estou criticando como você desenvolve - já fui testemunha da sua capacidade de entrega -, mas as abstrações estão cada vez mais importantes em grandes corporações. Neste sentido que defendo a UML, não metodologias burocráticas de quem não sabe o que está fazendo.

Gustavo Serafim:

O compilador: não valida conformidade dos conceitos com o negócio; não valida coesão e acoplamento nos diversos níveis de encapsulamento (método, classe, pacote, componente e ser preferir: serviço); não valida o efeito acumulativo de integrações com acoplamento forte no nível do negócio.

Uma abordagem gráfica ajuda analisar essas questões.[/code]

Testes unitários e especificações executávels (procure por RSpec, FIT ou EasyAccept) não apenas ajudam como validam isso de forma muito mais real, jã qu elas agem diretamente no código e não em uma tradução imperfeita e não verificável.

Quantas empresas você conhece que usam CORBA?

Melhor, porque grandes players como o Google simplesmente abandonaram as versões WS-* dos seus serviços?

Porque em vez de dividir a aplicação em módulos nós não dividimos a aplicação monstro em pequenas aplicações especializadas no que elas tem que fazer? É mais fácil de escalar, implantar e, especialmente,manter já que cada uma viveria separada das outras, se comunicando apenas através de interfaces bem definidas, usando seja lá o que for que você ache interessante (como WS-* ou REST).

Ah, outra coisa, esse negócio de “os componentes de negócio” não vingaram é quase uma coisa específica do Java, componentes de negócio em outros ambientes (como os plugins do Rails) vão muito bem obrigado

Maurício Linhares:

Porque em vez de dividir a aplicação em módulos nós não dividimos a aplicação monstro em pequenas aplicações especializadas no que elas tem que fazer? É mais fácil de escalar, implantar e, especialmente,manter já que cada uma viveria separada das outras, se comunicando apenas através de interfaces bem definidas, usando seja lá o que for que você ache interessante (como WS-* ou REST).

Nessa abordagem, dividir em pequenas aplicações, com qual o critério? Decomposição de domínio? Como considerar o negócio na divisão para não ter regras duplicadas, regras comuns entre elas ou muito tráfico de rede?

Qual sua definição de aplicação, mesmo EAR, mesmo datasource?

Exemplo:

Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não. (Acho que saímos do Assunto)

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não.

E eu estou falando de componentes de negócio, que era aonde estava inserido o comentário do Phillip também.

Gustavo Serafim:

Imagine uma empresa grande com muitos sistemas que usam serviços de funcionário e vendas.

Se uma aplicação possuir em sua implementação esses dois conceitos importantes (funcionário e vendas) você disponibilizaria os serviços desses conceitos - que possuem muitas regras de negócio corporativas - no mesmo backend?

Não seria melhor (para corporação não para o projeto) que estivessem isolados logicamente - interfaces protegendo a implementação, backend diferentes - em subsistemas, ou seja, deixando os dois serviços com acoplamento mais fraco?

Eu sei que depende do caso, por isso tentei montar um cenário.

Como você já disse, depende do caso.

Sistemas realmente independentes deixam a implementação muito mais protegida e ajudam ainda em uma coisa muito especial, eles vão ser desenvolvidos em torno dos serviços que eles vão oferecer de verdade as outras aplicações, você não vai ter features mirabolantes ou desnecessárias, tudo vai ser feito em cima da responsabilidade de cada um. Além disso, montar novos serviços em cima dos que já existem fica ainda mais simples, é só você olhar como funcionam os mashups na internet hoje, alguém faz um serviço simples que faz muito bem alguma coisa e outros implementam funcionalidades avançadas ou para nichos específicos.

As aplicações “enterprise” deveriam aprender um pouco mais em como a internet funciona, porque eles estão se dando bem com isso.

Como o Mauricio falou, eu nao estou falandod e compilador, estou falando de testes que executam especificacoes.

Não existem estatísticas -confiáveis- de falha ou adoção mas basta você olhar quem usa componentes desta forma e qual a literatura produzida sobre isso na última década.

Isso não é resolvido apenas com componentes do estilo UML components. Ultimamente (desde 2002?) usamos serviços para isso ou mesmo componentes que Não seguem todas as 2000 regras do Cheesman. Uma coisa não implica na outra.

Se eu tenho um modelo UML que não é executável e tenho que gerar um modelo executável (i.e. código) dele eu tenho modelos duplicados, a menos que eu jogue o modelo UML fora (ou o código…).

Foi exatamente o que o maurício sugeriu, Gustavo, só qu sem “coponentes de negócios” e sim com serviços.

Não estamos falando de EJB, CORBA… Estamos falando de divisão de sistemas, como interfaces distribuídas ou não. (Acho que saímos do Assunto)

Creio que os dois estão enganados aqui. Maurício, os componentes do Rails não têm nada a ver com componentes de negócio, eles ou oferecem funcionalidades isoladas ou oferecem requisitos não-funcionais.

pcalcado:

Gustavo Serafim:

O compilador: não valida conformidade dos conceitos com o negócio; não valida coesão e acoplamento nos diversos níveis de encapsulamento (método, classe, pacote, componente e ser preferir: serviço); não valida o efeito acumulativo de integrações com acoplamento forte no nível do negócio.

Uma abordagem gráfica ajuda analisar essas questões.

Como o Mauricio falou, eu nao estou falandod e compilador, estou falando de testes que executam especificacoes.

Você está subestimado meu comentário.

Estou falando em definir os conceitos certos observando o negócio (abstrações focando em responsabilidade, heranças verdadeiras, cuidando do espaço estado no caso de polimorfismo, tipos relacionamentos corretos, manter o estado consistente do objeto).

Efeito acumulativo de integrações com acoplamento forte no nível do negócio, só e possível analisar olhando para o negócio.

Ou seja, analise/entendimento do negócio necessário para codificar os testes, codificar o domínio e algumas decisões arquiteturais importantes. É nesse entendimento/validação do entendimento que a UML pode ajudar. E o próprio código é a documentação.

Muitos conceitos importantes foram reproduzidos nessa nova literatura com outros nomes e em alguns casos até com o mesmo nome. A parte que não funcionou saiu por seleção natural. Nenhuma abordagem é perfeita, logo é complicado dizer que essa não funcionou.

Quando eu falei em seguir todas as regras?

Modelos duplicados é um conceito interessante e fico atento com isso. Por isso costumo gerar algumas estruturas de código usando UML. E, algum nível de duplicação é aceitável, mas muito pouco. Tem que agregar valor de forma clara o modelo UML, mas não manter diagramas.

A Vale, por exemçlo, exigia vários diagramas em contrato, concordo que nesse caso e só documentação inútil.

Estou usando o termo “componente de negócio” de forma mais ampla. Nunca segui exatamente os conceitos do curso da PUC ou do livro que ela indicava, nem na minha primeira leitura (que tem muito tempo!), eu já tinha outras influências na época.

Você tem muitas reservas com esse termo, por isso, eu parei de usar - componente de negócio - nos meus comentários, passei usar subsistema (mais neutro). Serviços básicos/negócio realmente ficam melhor. Até por isso usei um exemplo com o termo serviço.

Só concordo com o Maurício se ele trocar “Sistema” por “backend” ou “subsistema”.

Bem, isso eu não posso fazer, subsistema pra mim é um sistema que fica dentro de outro e é exatamente esse tipo de abordagem que eu não acredito que seja a ideal

Acho que os sistemas devem ser independentes ao máximo no que eles fazem, eles não devem estar contidos em outros, mas sim fazer uso de outros. Mais uma vez, veja o conceito de mashups, é exatamente o que eu quero exemplificar aqui e eu não consigo imaginar mashups como “sub-sistemas”.

Imagine que você tem uma loja, sua loja tem pedidos, que contém itens (que são os seus produtos sendo vendidos) e você precisa controlar o que foi pago ou nãoe quando foi pago, você resolve então usar o ActiveMerchant pŕa fazer isso, isso não seria um componente de negócio?

Outro exemplo é o Freemium, que vai ma mesma idéia só que em vez de ordens e produtos existem as inscrições. Se isso faz parte do meu negócio (não dá pra imaginar um serviço que “se vende” sem ser por inscrições) e o plugin implementa isso, ele não se torna um componente de negócio?

Eu não entendi qual é o público alvo do seu modelo UML.

Para stakehoelders eu ainda acho mais adequado o uso de DSLs textuais como mencionado pelo Mauricio, criadas a partir de estorias ou casos de uso (td bem, uma pontinha UML), tanto faz.

Acho que todos nós concordamos quanto a utilidade para comunicação entre programadores (como falei para o cliente eu prefiro outra abordagem), mas eu não iria além de rascunhos e wikis. Qualquer transformação inversa/reversa exigira intervencao e aí você estara mantendo dois modelos.

Eu diria que o código é o modelo, documentação está em parte nos testes.

Não, Gustavo, você que subestimou o meu qundo vinculou com modelos executáveis. Recomendo que você d6e uma lida sobre Domain-Driven Design e Test-Driven Development para entender como fazer a “análise” diretamente em um modelo executável e ao mesmo tempo validar este modelo automaticamente usando uma técnica de design que cria baixo acoplamento.

Programação procedural trouxe muitos conceitos importantes. Assembly trouxe muitos conceitos importantes. Java 1.0 trouxe muitos conceitos importantes. Só por isso você o usaria?

Então qual o problema das abordagens mencionadas, por exemplo, pelo Maurício?

A literatura que sugeri acima mostra - e não ésó ela, são apenas exemplos- que voc6e pode dispensar o UML para praticamente tudo, exceto talvez comunicação visual.

Se a CVRD solicitasse que todos os programadores fossem canhotos, torcedores do Madureira e usassem camisa verde todas as consultorias de três letrinhas iriam seguir as ordens sem pensar meia vez

Um subsistema não é um componente, nem um serviço. Um subsistema pode ser componentizado mas componente (e serviço) indica uma acoplamento muito menor que um subsistema teria. Um subsistema não vive sem o sistema, um componente ou um serviço vivem.

Maurício Linhares:

Imagine que você tem uma loja, sua loja tem pedidos, que contém itens (que são os seus produtos sendo vendidos) e você precisa controlar o que foi pago ou nãoe quando foi pago, você resolve então usar o ActiveMerchant pŕa fazer isso, isso não seria um componente de negócio?

Outro exemplo é o Freemium, que vai ma mesma idéia só que em vez de ordens e produtos existem as inscrições. Se isso faz parte do meu negócio (não dá pra imaginar um serviço que “se vende” sem ser por inscrições) e o plugin implementa isso, ele não se torna um componente de negócio?

São funcionaldiades isoladas, Maurício, que dependem de configuração e customização. Eles são acoplados com regras de negócio e daí surgem as aplicações. É como se eu crio um site de busca e uso uma search engine como o Lucene, ele faz 99% do que meu site é só que não é um componente de negócios, é infra-estrutura. Eu ainda preciso dizer para ele como meu negócio se parece e aí eu crio um componente de negócio. Resumindo: componentes de negócio COTS devem estar prontos out-of-the-box.

Este tipo de componente não é incomum, aliás, a diferença em Rails é que eles são livres. Quando comentei sobre componentes Rails na outra thread não era sobre os componentes em específico e sim sobre a estrutura e ecossistema. Contruir componentes instance-based em 2008 é algo bem complicado.

Eu entendo o que o Gustavo está falando porque, além de termos trabalhado juntos e sermos amigos lemos um livro muito interessante (apesar de super-defasado) chamado UML Components, que prega uma metodologia para componentes de negócio.

sapulha:

Afirmar que Casos de Uso são histórias que não agregam nada a um projeto, é uma típica resposta de pessoas bitoladas que não sabem abstrair as necessidades de um projeto, tentando resolver tudo sempre com o olhar de quem domina uma linguagem muito bem, MAIS não entende nada de planejamento.
Casos de Uso, assim como a UML, tem o objetivo principal de manter o conhecimento em modelos, e não em pessoas.
Assim como as metodologias ágeis, a UML tem e sempre terá um papel muito importante no mundo orientado a objetos.

Cara que escreve MAIS em vez MAS nem merece resposta…

pcalcado:

Um subsistema não é um componente, nem um serviço. Um subsistema pode ser componentizado mas componente (e serviço) indica uma acoplamento muito menor que um subsistema teria. Um subsistema não vive sem o sistema, um componente ou um serviço vivem.

Maurício Linhares:

Bem, isso eu não posso fazer, subsistema pra mim é um sistema que fica dentro de outro […]

Pra facilitar troca de idéias, segue os conceitos que estou usando:

Definição de subsistema: Possui a semântica de um pacote, de modo que possa conter outros elementos, de modo que tenha comportamento. O comportamento do subsistema é definido por classes ou outros subsistemas contidos nele. Um subsistema compreende uma ou mais interfaces, que definem o comportamento que ele pode apresentar. (O subsistema vive de forma independente sim, ele uma forma de abstração. Sistema é um conceito também muito genérico.)

No vejo como poderia ser mais genérico essa definição e o seu uso. Fica aderente com: serviços; componente de infra; componente de negócio.

Definição componentes de negócio: um subsistema que contém regras de negócio e seus dados. (Também genérico, poderia ser um serviço básico (ou algo parecido com serviços corporativos na definição de Erl), não estou restringindo com o Livro usado no curso da Puc).

Usei esses termos para simplificar, pois senão teríamos que discutir muitos detalhes para formar uma simples idéia.

Como tenho usado a UML:

No auxilio de tomada de decisões quando estamos falando de abstrações maiores que classe (código está diretamente relacionado com classe) como, por exemplo, subsistemas, serviços, pacotes. (A UML ajuda tomar decisões). E também na documentando as principais abstrações da arquitetura.

No sentido de rascunho, desenhamos os conceitos (ou gerando diagramas com o código com alguns ajustes se preferir) para validar com o processo de negócio que está sendo “automatizado” e/ou com o usuário. Em alguns casos no próprio mapeamento do processo de negócio. E talvez, gerando algum código se for possível.

Já conheço o benefício de especificação diretamente nos testes, no entanto, para analise, algumas abstrações são úteis. Como você sugeriu, vou pesquisar como os testes podem ajudar em tomadas de decisão. (Já citei algumas necessidades, por exemplo, avaliar dependência circular e distribuição de responsabilidades).

A definição de sistema também é genérica, por isso procurei entender melhor a idéia do Maurício, mas não descordei diretamente.

Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter componentes, sistemas ou outros serviços. Muitos autores divergem como seria um backend para um serviço, mas o importante que ele representa alguma instancia do negócio digitalmente, portanto não podem ficar inconsistentes e são, ou deveriam ser únicos.

Quanto aos componentes de negócio como backend, sabemos que subsistemas que encapsulam conceitos de negócio e suas regras unicamente e sem redundância corporativa, não existem, e é inviável. (Serviços compostos ajudam encapsular essas redundâncias.) Mas deveria ser uma meta arquitetural para desenvolvimento, alguns autores citam como abordagem a Decomposição de domínio. O objetivo final é apoiar a automatização de processos de negócio - pensar corporativamente - pois empresas são coleções de processos de negócio.

Acho que poderíamos criar um tópico com isso.

Como mj;a mencionei algumas vezes aqui nesta thread isso pode ser feito por códigio sem qualquer problema. Na verdade, se você possui um modeo de análise que difere do modelo de implementação eu diria que voê tem um problema, e grave.

Desculpe mas eu não entedi absolutamente coisa alguma. Pode explicar de outra forma?

Cara desculpa fugir do aspecto técnico da thread, mas faz tempo que não vejo alguém falando tão “burocraticamente” sem dizer nada, parece muito um povo da IBM falando, enchem de termos e nomes bonitos pra justificar as coisas ruins que fazem rs

[size=18]A UML e seu Lugar no Processo de Software[/size]

A UML não é um modelo de processo de software ou uma metodologia de desenvolvimento de sistemas; ela é uma notação, um mecanismo para “apontar o problema” e forma a expor a essência do domínio de um aplicativo.

Marcio Duran:

[size=18]A UML e seu Lugar no Processo de Software[/size]

A UML não é um modelo de processo de software ou uma metodologia de desenvolvimento de sistemas; ela é uma notação, um mecanismo para “apontar o problema” e forma a expor a essência do domínio de um aplicativo.

Estamos presenciando um momento único, essa foi a mensagem mais sensata do gato félix no GUJ até hoje.

Cara desculpa fugir do aspecto técnico da thread, mas faz tempo que não vejo alguém falando tão “burocraticamente” sem dizer nada, parece muito um povo da IBM falando, enchem de termos e nomes bonitos pra justificar as coisas ruins que fazem rs

:?: … ++

Realmente não ficou legal, tentei ser muito sintético. Vou reescrever.

Burocraticamente?
Acho que fui formal ou vocabulário de conceitos diferente, mas isso é diferente de não “dizer nada”.

Maurício Linhares:

Estamos presenciando um momento único, essa foi a mensagem mais sensata do gato félix no GUJ até hoje.

:thumbup: "Estou lislongiado, pela observação do mais célebre entre os Moderadores "

Qual definição de sistema que você usa? Um frontend + backend? Como o termo sistema é muito genérico, depende da cultura da empresa, é comum que vários conceitos importantes - que deveriam ser isolados - ficarem no mesmo sistema. (exemplo) É interessante considerar - no caso de SOA - um sistema como uma camada de apresentação, e serviços/componentes como um backend compartilhado por vários sistemas (esses serviços são orquestrados por serviços orientados ao possesso ou por uma camada de aplicação).

Detalhando melhor:

Contexto

As empresas são grandes coleções de processos de negócio. Por isso, basicamente, estou falando de serviços para automação de processos de negócio com ferramentas BPMS, serviços básicos para encapsular as regras/dados do negócio e encapsular sistemas legado.

Para um projeto de desenvolvimento de sistema com qualidade não é necessária essa estratégia SOA. Não existe SOA para um sistema apenas. SOA resolve problemas corporativos visando flexibilidade.

Definição de serviço

Um serviço encapsula um ou mais backends. Na definição de backend, podemos ter subsistemas, componentes, sistemas ou outros serviços.

Existem muitas definições de backend no contexto de SOA, mas o importante é que ele representa uma instancia do negócio digitalmente (regras de negócio ou atividade do processo de negócio automatizado), portanto não podem ficar inconsistentes, seria melhor que fossem únicos e independentes.

Componentes de negócio com seus problemas e serviços

E comum tratarmos o backend de serviços básicos (ou algo parecido com serviços corporativos na definição de Erl) como componente de negócio.

O objetivo do componente de negócio é proteger as regras de negócio, evitando, sobretudo, a duplicidade - ou seja, primando para que, quando da modificação de alguma regra, seja possível obter um único ponto de alteração -, os componentes de negócio (subsistemas) são normalmente identificados decompondo-se o domínio, e disponibilizados como um recurso corporativo.

Na prática, a implementação de tal ponto singular, não é simples e muitos casos inviável. Dois motivos básicos para essa conclusão:

Primeiro, seria necessário uma harmonização dos conceitos da empresa. Exemplo, todos os sistemas deveriam entender o conceito de negócio ?produto? da mesma forma, mas em função do legado e da falta de análise, temos em um ambiente corporativo com várias semânticas para o mesmo conceito, no caso de ?produto?, poderia significar coisas diferentes em sistemas/serviços diferentes. Harmonizar e unificar esses conceitos e em muitos casos inviável.

Segundo, existe duplicação de conceitos em sistemas diferentes, replicando muito as regras de negócio. A duplicação de regras é muito comum, em função: do legado; da forma de desenvolvimento sem considerar o processo de negócio (que traz uma visão interdeparmental); integração baseada em bases de dados corporativos; e outras questões… (Conceitos importantes com relacionamento forte (agregação ou composição) separados em sistemas diferentes, também é um problema para evitar replicação de código).

Os serviços básicos (componentes de negócio ou não) como suas inevitáveis duplicações de conceitos/regras e inconsistências, normalmente são encapsuladas/controladas em serviços compostos e em serviços orientados a processo de negócio.

Conclusão

Mesmo com todas as dificuldades os componentes de negócio isolados e pouco acoplados deveriam ser uma meta/um norte para arquitetura. Por isso a importância de técnicas decomposição do domínio e decomposição do processo de negócio para identificação de serviços em sistemas como a estratégia SOA.

Trabalho em uma empresa que tem hoje 200 sistemas em desenvolvimento (automatizando partes diferentes de uma grande processo de negocio, exemplo “vender seguro”, compartilhando com isso muitos serviços que possuem muitas regras), o efeito acumulativo de conceitos e regras duplicadas, são refletidos em pouca flexibilidade para o negócio, ou seja, dificuldade para assimilar mudanças. SOA ajuda efetivamente controlar essas questões.

Na prática é muito difícil que uma equipe comprometida com os resultados do projeto tenha tempo ou interesse de usar essa estratégia SOA, que não traz muitos benefícios imediatos para o projeto (talvez reuso), apenas traz benéficos significativos se pensarmos corporativamente e no efeito acumulativos da abordagem. Por isso governanca é importante para SOA.

Gustavo Serafim:

[…]
Conclusão

Mesmo com todas as dificuldades os componentes de negócio isolados e pouco acoplados deveriam ser uma meta/um norte para arquitetura. Por isso a importância de técnicas decomposição do domínio e decomposição do processo de negócio para identificação de serviços em sistemas como a estratégia SOA.

Trabalho em uma empresa que tem hoje 200 sistemas em desenvolvimento, o efeito acumulativo de conceitos e regras duplicadas, são refletidos em pouca flexibilidade para o negócio, ou seja, dificuldade para assimilar mudanças. SOA ajuda efetivamente controlar essas questões.

Na prática é muito difícil que uma equipe comprometida com os resultados do projeto tenha tempo ou interesse de usar essa estratégia SOA, que não traz muitos benefícios imediatos para o projeto (talvez reuso), apenas traz benéficos significativos se pensarmos corporativamente e no efeito acumulativos da abordagem. Por isso governanca é importante para SOA.

Além de não concordar com pontos em suas definições eu não entendi exatamente sua conclusão. O que você concluiu, que serviços e componentes são a mesma coisa?

pcalcado:

Além de não concordar com pontos em suas definições eu não entendi exatamente sua conclusão. O que você concluiu, que serviços e componentes são a mesma coisa?

A conclusão teve a pretensão de passar a idéia que componentes de negócio são uma boa base, uma maneira de organizar a casa para serviços (organizar no sentido de evitar replicação de regras e de manter pouco acoplado os conceitos chaves para empresa, garantindo uma evolução minimamente independente).

Todo componente pode ser considerado um serviço básico, mas acredito que o contrário não é verdadeiro. Componente de negócio é mais especializado, trata diretamente da organização (dependência, evitar duplicação de regras) dos conceitos corporativos.

Teve também a pretensão de mostrar que deveriam ser apenas um norte arquitetural, mas não uma obrigação em função dos problemas que foram mostrados. Abstrações maiores de serviços (serviços compostos, de negócio dependendo do autor) podem ajudar em casos em que não é possível usar os conceitos de componentes de negócio.

Hm… e por que eu deveria pensar em componentes ao invés de partir para serviços de vez?

Não. Se você ler Peter Herzum/Oliver Sims vai ver que mesmo CBD possui os mesmos conceitos de ‘servico básico’ e um componente pode assumir diversas granularidades nesta dimensão. CBD possui conceitos de componentes granulares, orquestração de processos, roteamento e quase tudo que se pensa que surgiram com serviços. Basicamente SOA se resume à utilizar apenas componentes type-based e remotos.

Eu já tentei correlacionar CBD com SOA e falhei miseravelmente, 90% dos conceitos presentes em SOA são um subconjunto de CBD.

Concordo. É mais interessante usar apenas o termo “serviço”.

Na classificação de serviços, por exemplo, temos vários tipos, de autores diferentes, e com diferenças semânticas muitas vezes sutis. Por isso acho útil relacionar com conceitos mais estáveis, no caso componente de negócio, ou definir um vocabulário comum para facilitar trocas de idéias.

pcalcado:

Eu já tentei correlacionar CBD com SOA e falhei miseravelmente, 90% dos conceitos presentes em SOA são um subconjunto de CBD.

Phillip, tenho observado que - verdadeiramente - separar a lógica do processo de negócio da lógica da aplicação, e considerar serviços orientados a processo - obtidos com metodologias de decomposição de processo - como um vocabulário comum na comunicação e automatização dos processos negócio, é a única evolução real…

Não encontrei esses conceitos, de forma clara, em CBD…

Procura a literatura que te falei. Até BPM tem lá.

Aiás, Gustavo, agora que vi que você escreveu sobre isso numa revista. Como o site da editora não é acessado da Australia eu não conseui ler o artigo, se puder me manda o pdf por email.

Phillip, fiquei sabendo que foi publicado tem pouco tempo… Ele relaciona SOA e CBD, mas procura ter definições essenciais. Não é voltado para um público de desenvolvedores avançado. Criticas são bem vindas. Artigo.

Que tal voltarmos aos Casos de Usos?

Eu também gostaria.
Tá começando a ficar chato fazer aqueles casos de uso nas aulas.

Gustavo, primeiro de tudo parabéns pela perseverança nos posts. Tive uma experiência muito parecida com a sua e faço minhas as suas palavras: "

Apesar do Phillip considerar o livro do Cheesman defazado, ele foi o único que evoluiu de forma concreta as compilações do Szyperski. Apresentou um processo de desenvolvimento de sistemas baseado em componentes que realmente permite aos arquitetos de software trabalharem a visão corporativa e a colocar em prática o verdadeiro reuso.