Meu UML está errado?

Assuntos Gerais Agile
#1

EXPLICANDO

Já li aqui no fórum muito informação sobre uml, mais mesmo assim ainda não me convenci de utilizar da maneira proposta pela maioria, acho que ainda não abastrair o suficiente.

Tenho trabalhado em um projeto que se utiliza no backend java e no frontend Adobe Flex, como o projeto é de pequeno a médio porte pois terá módulos como compras, vendas, financeiro e produção estamos analisando como será organizado o sistema, a minha maior preocupação é com o UML

Vamos a prática, neste projeto, já decidimos que usaremos alguns conceitos:

Camada de Persistencia
conceito de DAO usando como framework o hibernate junto com o Spring ORM

Camada de Business
conceito de DDD, como acredito que business é a lógica do me sistema é aqui também que utilizo do DDD e implemento meu dominio , ou seja, minhas entity, repository e service… além disso utilizo Spring Annnotation para IOC e AOP (utilizo para log e auditoria).

Camada Apresentação
como já falei uso adobe Flex… e não entra muito na questão aonde quero perguntar…

só expliquei com detalhe para não ter depende na reposta já que estou especificando uma situação

PERGUNTANDO

eu pensei em fazer meu uml da seguinte maneira, meu Caso de usos é para comunicação inicial com o cliente, cada caso de uso é um módulo desses que falei, meus casos de uso seria assim:

Controlar Compras
Controlar Produtos
Controlar Estoque
Controlar Financeiro
Controlar Vendas…

é diferente do que tenho visto, normalmente é incluir, alterar, excluir,imprimir em uma cacetada de casos de uso, eu generalizo e muito. :lol: mais acho que não perco nada com isso.

pode-se dizer que estou errado? o que seria certo e prático?

já no meu diagrama de Classes que vem a maior dúvida, imagina que tivesse um fornecedor por exemplo, eu teria as seguintes classes, FornecedorEntity, FornecedorService e impl, FornecedorRepository, FornecedorDAO… é muito massante e pouco sugestivo, não acredito que usar diagrama de classes assim seja muito útil, imagino que minhas Entity e seus métodos (que podemos ± considerar sua service é o que nos importa) usando a uml como documentação, o que importa é que o fornecedor tem os seguinte atributos e métodos, não me interessa que ele passa por uma repository, dao, service… sei lá, acho que estou sendo prático demais, querendo resumir muito, ou estou querendo que fosse menos trabalhaso.

bem, enfim o que acham? vlw pela ajuda, como deu para perceber estou meio perdido

#2

[quote=Janfelove]
eu pensei em fazer meu uml da seguinte maneira, meu Caso de usos é para comunicação inicial com o cliente, cada caso de uso é um módulo desses que falei, meus casos de uso seria assim:

Controlar Compras
Controlar Produtos
Controlar Estoque
Controlar Financeiro
Controlar Vendas… [/quote]

Então…realmente, a uml é para comunicação entre os individuos inclusive com vc mesmo. Levando em conta o que vc escreveu acima eu acho que até dá para passar, o problema que eu vejo é que parece estar em um nível muito alto fazendo com que a idéia de UseCase fique descaracterizada, tanto que talvez se vc utilizasse alguns sinais de fluxo para descrever processos ficasse mais adequado. Vamos pegar “Controlar Compras”, para passar a idéia disto provavelmente iria surgir bem mais que UM caso de uso, mesmo que fosse uma idéia bem simplificada. A pergunta que surge é a seguinte: Os casos de uso que coloquei e descrevi realmente passa a idéia de como as coisas são? Tem coisas que fica tão simplificada que ninguem entende o que está acontecendo o inverso também é verdadeiro.

Diagrama de classes: Vc não precisa colocar as classes FornecedorService e impl, FornecedorRepository, etc…isso depende da fase e do que vc quer transmitir em termos de informação. Se vc estiver na fase de análise o seu modelo irá conter apenas as classes dos objetos que foram encontrados no domínio do problema como por exemplo: Pessoa, Carro, Vaga, Conta etc… muitas vezes, nesta fase as classes ainda não tem nem atributo e nem operações. Agora se vc já estiver na fase de implementação e QUER passar detalhes da arquitetura adotada e outras coisas que não estão presentes no domínio do problema vc inclui tais classes como LoginFacade, ContaFacade, etc…, ou seja, acho que neste ponto vc está correto também.

O que vale é o bom senso e o cuidado de não simplificar demais e nem complicar demais, como vc mesmo disse para alguns não interessa se existem DAO, Factory, Repository etc… mas no entanto um arquiteto, desenvolvedor etc…iria achar isso muito interessante elevando o nível do entendimento sobre o projeto.

Espero ter ajudado…

flws

#3

ajudou sim, concerteza! vlw

no caso dos casos de uso o objetivo é mostrar o que o sistema faz e não como, assim como é o objetico da análise de requisitos funcionais, a única diferença seria o modelo de apresentação do mesmo, um escrito e outro desenhado, neste caso acho que não estou usando o caso de uso corretamente, talvez fazer como vc disse, apenas um fluxo da comunicação e dependencias entre módulos seria a solução inicial.

sobre o diagrama de classe, realmente analisei apenas como comunicação inicial, com o objetivo de analisar apenas o domínio, ou seja, Fornecedor, Produto, TipoProduto, UnidadeMedida… mas analisando de uma outra maneira também acho que seria interessante usar para comunicação dos arquitetos e desenvolvedores, principalmente para quem chegar novo que já vai ter toda documentação para adiantar o processo de aprendizagem, mesmo assim tenho minhas dúvidas, já que mesmo que eu coloque todas essas classes no meu UML ainda não vai estar refletindo meu projeto, usamos alguns frameworks e ferramentas do tipo Maven, HIbernate, Spring’s , Blazeds, e esses framework atinge diretamente meu processo de desenvolvimento e arquitetura, acho que esse é o meu bloqueio para fazer dessa forma, por mais que detalhasse não iria conseguir mostrar toda a arquitetura

#4

Essa foi a parte que mais me chamou atenção:

[quote=Janfelove]
… a minha maior preocupação é com o UML [/quote]

Qual é a finalidade de UML no seu projeto exatamente? São artefatos exigidos pelo cliente? São para ajudar os desenvolvedores a entender os requisitos? São para clarificar a arquitetura?

Quando UML é uma preocupação maior que o software em si, este não é um bom sinal…

#5

Hoje São para ajudar os desenvolvedores a entender os requisitos, mais gostaria também que fosse para clarificar a arquitetura.

Realmente concordo com vc sobre a importancia, inclusive já estamos começando a desenvolver e isso que mais me preocupa, como o prazo é impossivel de cumprir muitas das vezes passa direto, somos novos na empresa e estamos tentando mudar isso, mais é muito dificil, aliás como desenvolver antes de saber o que tem que fazer, só depender da ciratividade sempre esquece algo e principalmente teremos problema de lógica.

#6

Não é a questão do UML está certo ou está errado. O furo está em um problema mais básico: complexidade desnecessária. Veja: você ainda mal começou, mas diz que é de pequeno a médio porte (e se for apenas pequeno?), diz que vai separar em camadas (e se sua aplicação for tão simples que isso não é requerido?), diz que vai usar todos os sufixos imagináveis pras suas classes (não dá pra diminuir a separação?).

A descrição dos seus casos de uso é inadequada porque é ambígüa. Me diga: o que significa “Controlar Compra”? É uma câmera que fica monitorando as sacolas do cliente para que elas não se percam? É um serviço anti-fraude que verifica se a compra não ultrapassa o limite de crédito? É uma aplicação que notifica o fornecedor quando o estoque está abaixo do limite? O que estou querendo dizer é: um caso de uso “Controlar algo” significa tudo e nada ao mesmo tempo!

Falta também o ator do caso de uso, não tê-lo implica que você não sabe o limite do seu sistema.

UML não é documentação, mesmo que 90% das pessoas digam o contrário. Você não precisa de todas as classe com aqueles sufixos. Se na UML não precisar, não põe. Se no código não precisar, não codifique. Duas coisas ajudam a evitar essa armadilha:

  1. Faça os casos de testes primeiro. E use o mais simples. Não use o RSpec só porque o Fábio Kung disse que é bom (nada contra o RSpec, hein?). Use o JUnit mesmo, que já vem no Eclipse e no Netbeans por padrão. Use um outro apenas se sentir necessidade de algo a mais.

  2. Não separe pacotes por programa.dao, programa.entity, programa.service… Faça diferente, separe por programa.cliente, programa.fornecedor, programa.venda… onde cada pacote terá o seu entity, dao, service e por aí vai. Isso força a pensar no seu domínio primeiro, não nos “patterns”. E o melhor, você pode criar métodos com escopo package para aqueles métodos onde só o DAO chama, por exemplo.

Bom, é isso aí.

#7

exatamente, você não vai conseguir modelar em UML, todos os detalhes que estão no código fonte…
acho UML uma boa pedida pra promover comunicação entre as equipes
ou para discutir alguma questão de arquitetura…mais que isso, você vai acabar tornando seu projeto
bem burocrático…
IMHO, acho mais interessante focar esforços no código fonte…

#8

Falar de UML e não falar de tudo que envolve o desenvolvimento de software me parece impossivel, por isso:

[Quote]Não é a questão do UML está certo ou está errado. O furo está em um problema mais básico: complexidade desnecessária. Veja: você ainda mal começou, mas diz que é de pequeno a médio porte (e se for apenas pequeno?), diz que vai separar em camadas (e se sua aplicação for tão simples que isso não é requerido?), diz que vai usar todos os sufixos imagináveis pras suas classes (não dá pra diminuir a separação?).[/Quote]

vou te explicar melhor o porque eacho que é pequeno a médio porte. Hoje a empresa tem mais de 5 anos de vida, no total tem mais de 7 produtos para desktop feito em vb6 e provavelmente mais de uma dezena de sites em php, a empresa começou crescer muito a 2 anos atras e hoje tem quase 40 clientes que pagam manutenção mensal, o problema que os 7 produtos estáo sentro de um só, nõ foi dividido em classes é um grande saco cheio de coisas misturadas, ou seja, não teve quem organizasse, cresceu sem está esperando. Hoje tem uma grande dificuldade de encontrar algum desenvolvedor em vb6, já que toda faculdade ensina JAVA, a idéia é pegar esse 7 produtos e separar, mais fazer em vb6 e java teria quase o mesmo trabalho, já que teria que reestruturar o código, como arrumamos um paitrocinador vamos fazer um em desses produtos em java, mais a nossa preocupação é com reusabilidade de código, trabalhar em módulos, por exemplo, financeiro todos os nosso produtos vão ter, por isso um módulo que todos os produtos vão acessar, é o financeiro só, mais todos tem, por isso, pensando no futuro a complexibilidade é grande, até mesmo para aproveitar a oportunidade de fazer um projeto em java, já que a maioria aqui faz faculdade e conhece melhor java que vb6.

[Quote]“A gota d’água! De tanto mergulhar no Java EE, agora quero saber como é programar em PHP.” [/Quote]

eu sou ao contrário, estou saindo do simples e desorganizado do PHP e VB6 para uma ferramenta melhor e seus frameworks, não quero mais recriar a roda, não quero mais ter os meus padrões, se alguém pensou em conceitos como DAO, DDD, divisão em camadas, MVC, UML concerteza sabem melhor do que eu sobre organização, reusabilidade de classes, etc… nada contra o php ou vb6 em si, só que junto com eles não vem uma metodologia a ser seguida, tudo é solto demais e isso hoje já me dá medo, principalmente na manutenção.

[quote] exatamente, você não vai conseguir modelar em UML, todos os detalhes que estão no código fonte…
acho UML uma boa pedida pra promover comunicação entre as equipes
ou para discutir alguma questão de arquitetura…mais que isso, você vai acabar tornando seu projeto
bem burocrático…
IMHO, acho mais interessante focar esforços no código fonte…[/quote]

Acho que é isso, vou usar apenas como documentação para levantar requisitos, até mesmo que não estou vendo outro motivo para se utilizar, no meu caso é claro.

#9

RESUMINDO, um sistema nesse modelo, com 4 pessoas, vcs indicariam usar UML?

#10

Eu indicaria sim! Caso vcs venham a decidir pelo uso vem a seguinte perguntinha: Vocês se COMPROMETEM a fazer isso?

flws

#11

sim, é o que queremos, mais acho que analisando melhor seria mais para ajudar a levantar os requisitos e não para refletir a arquitetura, acho que para o nosso caso um diagrama de classe somente com os dominios já daria para se comunicar legal, talvez nem fosse necessário os casos de uso, já que esses que eu fiz nã refletem nada, :slight_smile:

quem diaria, eu falei isso, se me perguntarem agora vou responder “DEPENDE” :lol:

A verdade é que pelo que percebi poucos usam realmente tudo que a UML oferece, e me fica uma outra dúvida, a UML só se torna essencial e indispensável quando o projeto é grande? quando tem mais de 40 cabeças no projeto e tudo tem que ser bem burocrático?

neste caso acho que a maior dúvida começa realmente nas salas de aula, quando um professor de faculdade vai nos apresentar UML ele fala que é essencial, não podemos começar a desenvolver antes que UMLs como D.Classes C.Uso e D.Sequencia estejam prontos… mais o que vejo que muitos pulam essa parte por acharem que é muito burocrático, pouco prático ou sei lá que motivo…

#12

Eu estava lendo esse post no blog do Phillip Calçado, talvez ajude:

http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/

#13

[quote]Eu estava lendo esse post no blog do Phillip Calçado, talvez ajude:

http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/[/quote]

Vlw pelo link, realmente muito esclarecedor

#14