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

pcalcado wrote: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)

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.

This message was edited 1 time. Last update was at 13/05/2008 17:37:03

pcalcado wrote:Segundo alguns defensores de MDA nem mesmo este padrão depende de UML - o que eu não concordo.

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.

This message was edited 1 time. Last update was at 13/05/2008 17:35:15

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

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

) capturadas em Index Cards e também protótipos visuais.

rodrigoy wrote:
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.

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 505 Offline

rodrigoy wrote: ... aliado a histórias (também conhecidas como Casos de Uso - tinha que dar o troco né Taz )

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.

Taz wrote: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!?

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.

Taz wrote:
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!!

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

Taz wrote:
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.

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

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 505 Offline

rodrigo wrote:

Taz wrote: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!?

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:

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

(...)

Taz wrote: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.

rodrigoy wrote: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.

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:

http://blog.aspercom.com.br/2008/05/15/product-owner-um-desgracado-ganancioso/

Abraços!

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 505 Offline

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 wrote: 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.

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 505 Offline

rodrigoy wrote: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.

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

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

Taz wrote:
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.

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.

Taz wrote:
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.

Você é contra qualquer tipo de modelagem?