[quote=rodrigoy][quote=Taz]
só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…[/quote]
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.
[/quote]
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.
[quote=Taz]
só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”… [/quote]
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]
[quote=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][/quote]
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
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.
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”.
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.
[quote=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.[/quote]
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.
[quote=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” !
[/quote]
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?
[quote=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.[/quote]
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.
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.[/quote]
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.
[quote=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.[/quote]
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.
[quote=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).[/quote]
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.
[quote=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.[/quote]
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.
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.
[quote=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][/quote]
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
: 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.
