| Autor |
Mensagem |
|
|
Estou bem tendencioso a usar EJB para Swing... pelo que lí a solução Remote do Spring com RMI (que é o caso), não suporta transação.
http://www.springframework.org/docs/reference/remoting.html
Quando pensamos no Swing, algumas vezes os Domain objects precisam ficar locados e com sessão aberta enquanto a tela viver. Aí, não estou conseguindo ver uma solução que fuja de Entity e Statefull. 
A não ser que alguém aí tenha um coelho na cartola... 
|
 |
|
|
Olá Spranta, vamos lá...
Antes de mais nada, gostaria acrescentar que se existe um componente X que faz isso ou aquilo, o caso de uso é completamente cego a esse respeito. Pouco importa para o caso de uso o que acontece dentro do sistema!
O caso de uso é a visão do usuário a respeito do sistema. O caso de uso mapeia o problema e não a solução. O caso de uso mostra o que o sistema faz, e não como ele faz. O caso de uso é um objetivo do ator, não tarefas do sistema.
Tendo isso em vista, enxergo que você possui só dois casos de uso:
- Manter Funcionario
- Manter Cliente (se o objetivo de Manter Contato só ocorre dentro de Manter Cliente esses dois são um objetivo só).
A ASPERCOM tem um curso on-line grátis sobre Casos de Uso com um estudo de caso, tarefas práticas e muito mais. Se quiser é só acessar:
www.aspercom.com.br
|
|
|
|
Horácio wrote:
Dum vitant stulti vitia, in contraria currant /
O tolo, ao tentar evitar o erro, acaba fazendo o contrário.
Já que está citando personagens da turma da mônica, o Humberto diria:
Humberto wrote:
hum...hum... hum..
|
|
|
|
cv, aí na fábrica do Fowler vcs estão aplicando sempre XP, ou outras metodologias ágeis? Rola alguns projetos num Unified Process mais tradicional? (casos de uso, design, implementação, teste)
Pergunto isso porque o maior entrave para usar metodologias ágeis aqui no Brasil é o cliente (digo isso em fábrica de software, que é onde trabalhei nos últimos 6 anos). O cliente não quer trabalhar fácil, e muitas vezes nem iterativamente.
Queria saber como são os contratos aí no UK...
|
|
|
|
Não, não, vc não entendeu... eu não aconselho estabelecer o relacionamento.
Bom, não existe receita de bolo, vou te passar um overview. Se tiver bons requisitos na mão inicie pensando na parte estática do sistema: classes de negócio ou de domínio, como vc citou, aquelas que persistem. Não pense nos métodos de negócio ainda. Você vai descobri-los mais tarde.
É bem interessante pensar nessa modelagem da maneira como discutimos aqui.
http://www.guj.com.br/posts/list/33027.java
Ok, já sabemos como o negócio funciona, mas não sabemos como a aplicação funciona. Nesse momento pesquise como seus usuários vão interagir com o sistema. Se tiver os casos de uso ou algo que o valha facilita.
Sabendo como o usuário usa o sistema, coloque-o no diagrama de sequencia (ator), a tela (boundary class), o controle (ou service). Aí é só começar a interagir. O ator faz isso na tela a tela vai buscar não sei o que não sei aonde e retorna alguma coisa para o ator que faz aquilo na tela e a tela vai processar não sei o que não sei aonde e por aí vai....
Viu só... você consegui modelar o sistema de um jeito fácil e prático, sem esticar setas desnecessárias... para não perder tempo gere o código e prossiga até ter o release.
(enfatizo que este é um modo de fazer, o jeito que eu faço, alguns podem dizer que dá para fazer as interações antes de pensar na parte estática)
Use a UML para analisar o sistema. Dependência você usa quando quiser enfatizar uma dependência. Se você quiser esticar seta para todas as dependências que há no sistema você morre louco!
(desculpe, este é um post de sexta-feira a tarde)
|
|
|
|
Robert wrote:Usar um processo agil nao exclui a necessidade de criar diagramas, modelos, etc, sempre que necessario, deve-se fazer modelos para melhor entender o sistema.
So que na XP por exempo, a atividade principal e CODIFICAR, nao modelar, como no RUP.
Robert, aí é que vc se engana. Não é que a atividade principal do XP é codificar. Para falar a verdade a maneira de se modelar é que é diferente. Eles usam um modelo mental, ou um modelo rascunhado, ou até mesmo a questão de você fazer os testes antes de codificar é considerado o modelo.
Até mesmo o pair programming pode ser considerado uma atividade de modelagem (um pensa no operacional o outro pensa na tática). Tudo isso é para compensar a especificação mais leve que o processo prega.
Muitos metodologistas defendem que os processos ágeis não são gambiarra e nem mesmo 100% desprovidos de documentação. Como já falei, não gosto quando XP vira desculpa para sair fazendo as coisas sem processo nenhum.
|
|
|
|
Daniel, é verdade, bom, podemos usar o AUP nesse caso que a customização já está feita..... Mas sobre o que você falou das empresas exigirem o RUP não é fato isolado. Rola direto!!!
Geralmente o gestor que está comprando o projeto acha que estará mais seguro se o processo for distribuido por uma empresa (IBM). Bom, cada louco com a sua mania....
|
|
|
|
louds wrote:
Por falar nisso, para editar melhor papel mesmo, pq o melhor para mudar a maioria dos diagramas é desenhar eles novamente incluindo os novos conceitos - ajuda a revisar e verificar se está bom. Claro que se vc estiver usando uma ferramenta CASE que custa mais por mês que seu salário não rola toda essa produtividade.
Uma licença do EA custa US$ 300,00. Cara, vc tá ganhando mal.... 
Fora a piada, bom, dá para fazer no papel e dá para fazer na ferramenta, agora dizer que revisar um diagrama refazendo no papel é mais produtivo que fazer na ferramenta aí é forçar a barra. Imagine que você precise da classe Pedido em 10 diagramas. Será que é mais fácil fazer esses 10 diagramas no papel? Na ferramenta é arrastar e soltar.
Não leve o Scott Ambler tão a sério. Se o seu cliente exige os diagramas como artefato compre uma ferramenta. Mesmo que os diagramas não valham mais nada no fim do projeto, para entregar pro seu cliente ele ficaria mais contente em receber um ModeloWeb, não uma foto de um diagrama em papel.
|
|
|
|
cv wrote:Mas, se vc vai ajustar RUP pra ser agil, pq nao usar um processo agil logo duma vez?
Acredito que nenhum processo é "out-of-the-box". Seguir qualquer processo à risca mesmo que seja XP pode te transformar num "tradicionalista". Certo? 
Você aplica as metodologias exatamente do jeito que a literatura manda? Você não faz algumas adaptações (mesmo que pequenas)?
|
|
|
|
pcalcado wrote:No caso aqui o maior problema na verdade é lazy loading, esta sim é uma decisão arquitetural difícil de remover.
Nem me fale... esses frameworks como o Hibernate resolveram um problemão... implementar Proxies (como exemplo) é uma pentelhação. Realmente no caso de um downgrade tão violento assim daria vontade até de pular fora do projeto... 
pcalcado wrote:
rodrigoy wrote:
Acho a abordagem de vcs muito acertada. Como eles demonstram a apresentação ou os boundaries (conversa ApAp <-> Domain).
Hm.. não entendi, foi uma pergunta?
É, é uma pergunta. Como os seus designers do projeto passam a ligação entre as boundary classes e o domain? Fazem um SD?
Comentei que a abordagem é acertada pois sempre temos um problema quando o designer entrega o modelo UML diretamente para a codificação. Da forma que vocês estão trabalhando o modelo (que no caso é o próprio código) é testável, coisa que a UML não é (não me venham com diagrama de objetos). Não é uma crítica à UML, mas sim aos designers. Eles devem aplicar a boa prática de continuamente testar o software e não se esconder atrás do modelo.
pcalcado wrote:
Em geral. Nunca vi o modelo 9a) funcionar (b) produzir algo de qualidade. O modelo talvez funcione se seguido a risca os princípios de Engenharia de Sofwtare mas eu sou do time que acha que Engenharia de Sofwtare (metodologia do SEI criada na OTAN) só serve, e mesmo assim talvez, apra projetos muito grandes geralmente onde o ahrdware é mais importante que o software e vai ser desenvolvido em apralelo.
Para gestão de informação essas práticas nunca me mostraram resultados reais, eu só vejo 9em projetos que participei ou não) desculpas sobre porque a metodologia não dá certo e promessas que da próxima vez vai ser diferente.
Outro dia tive que ouvir um " a documentação está defasada em relação ao código porque brasileiro não tem cultura de fazer design". Como se desse certo em algum outro país... 
Tem que levar em consideração que é difícil achar um gestor que saiba aplicar a metodologia certa no projeto certo (geralmente ele adota o WUP - Waterfall Unified Process). Faço uma crítica muito grande aos gestores de projetos de software em geral.
Documentação é uma palavra que não posso mais ouvir. Já acompanhei duas implantações de CMM. Não ví ganho nenhum na implantação da certificação (fora a churrascada grátis quando pegamos o "selo"), o processo ficou pesadíssimo e Cataratas do Iguaçu. Ví um repositório com 500mb de documentação.
Eu gosto de modelar usando a UML, mas uso a UML como ferramenta de análise. A UML é para descobrir informações. É o que tento explicar para os meus alunos. Não sou "xiita" ao ponto de jogar fora os diagramas (Fowler). Estou para fazer uns testes. Imagino que se o designer se focar em modelar em UML somente o Domain Model suas ligações com as Boundaries os problemas na sincronização do código com o modelo podem ser bem minimizadas, fora que esse designer seria independente de plataforma, arquitetura e etc... (mas é só um teste, acredito que para uma fábrica hibrida JAVA/.NET isso pode ser bom, o designer se encaixa em qualquer projeto sem conhecer as entranhas da arquitetura).
|
|
|
|
Olha, depende do que você quer demonstrar com o modelo. Para te falar a verdade, se está bem compreendido como funciona as duas classes vejo bem pouca aplicação no estabelecimento desse relacionamento no seu modelo UML.
A meu ver, a maneira como um Control se relaciona com um Entity (ou coisa que o valha como o seu DAO) é melhor demonstrada num diagrama de interação (como o de sequência que é o mais popular).
Mas usar a UML só para fazer demonstração de conceitos (documentação)é a mesma coisa que ir para a Disney só para tirar a foto com o Mickey (essa foi muito ruim)
Dá uma olhada no link abaixo:
http://www.aspercom.com.br/ead/file.php/1/Arquivos/UML_Mitos_e_Erros.ppt
|
|
|
|
wagner.gs wrote:Pessoal,
Estou começando a implementar uma aplicação e tenho pesquisado sobre desenvolvimento voltado a testes. Surgiu então uma dúvida: se temos que cobrir toda a aplicação com testes, devo fazer testes pra DTOs 'burros', ou devo fazer os testes apenas para classes q implementam alguma regra de negócio, ou ainda, meus DTOs burros não são a melhor solução?
Obrigado!
bom senso... bom senso... desenvolvimento de software se baseia em bom senso...
|
|
|
|
pcalcado wrote:
Assumindo que a grid seja um objeto em memória, não há problemas, mas se grid for um daqueles "adoráveis" componentes que trazem uma tabela para um formulário vai depender de quando seu caso de uso termina. De qualquer forma o grid e seus mecanismos possuem um potencial de reutilização baixo e pode fazer algumas suposições sobre como vai ser executado (geralmente componentes de Apresentação e Aplicações têm esta característica).
Fundamentei o exemplo na situação do Domain Object "Cliente" não ter uma operação salvar() pois ele usa o autosave do container. Nesse meu exemplo o que o botão salvar chamaria?
pcalcado wrote:
Arquiteturas são por definição decisões que são difíceis de serem alteradas, mas supondo que o sejam não consigo pensar num modelo masi livre da arquitetura do que este. Veja o domain model proposto, eel não depende em nada de Hibernate, JDO, JDBC, Spring... o que ele precisa são serviços que devem ser supridos por alguém como transações e persistência. Onde você acredita que possa haver dependência?
Digamos o seguinte: se eu não colocar as operações "salvar()" nas minhas Domain Classes faço isso porque a minha arquitetura permite o "autoSave". Correto? Estou partindo da abstração que os objetos se salvam sozinhos quando "mexidos". E se eu dar um downgrade na minha arquitetura para uma que não permite isso?
(é um casinho meio estúpido, nem precisa responder, mas é só para exemplificar que o Domain Model não é realmente dependente da arquitetura, mas é dependente das facilidades que a arquitetura proporciona). Isso dá margem para escrever "Refactoring Domain Model", ha ha ha ha...
pcalcado wrote:
Eu não sou contra Repositorios com metodos de pesquisa, foi apenas uma sugestão apra que você pudesse ter uma interface única para todos os seus repositórios.
De qualquer forma, ter apenas um método não significa que um objeto é burro. A função do repositório é aplicar a especificação nos seus objetos (que acaba sendo implementado por um DAO aplicando um QueryObject na persistência), ele tem diversas responsabilidades.
OK! É precisamos tomar cuidado com essas decisões.... Imagine se os seus "analistas/designers" que estão lá longe no seu projeto decidam só usar QueryObject  (afinal a análise fica mais simples, o programador é que se vire para implementar).
pcalcado wrote:
Sim e não, mas isso tem mais a ver com metodologia e processo.
Deixa eu explicar o que estou tentando fazer com meus analistas e programadores (sim, meu projeto atual tem uma diferença enorma -geograficamente falando, inclusive- entre analistas/projetistas e programadores). Eu tenho 6 analistas que vão trabalhar basicamente com o domain model e testes unitários. Basicamente eles fariam isso (se o modelo de fábrica de sofwtare funcionasse, como não funciona eles vão fazer muito mais, mas este é o papel original).
Como eles vão produzir um Domain Model pronto e testado, totalmente baseado em Repository, Specification, Service e tudo mais, cabe aos programadores e a mim como arquiteto a implementação dos serviços que dão suporte ao Domain Model. Assim nós criamos os DAOs segundo a especificação de contrato dos repositórios deles, fazemos os services serem expostos como EJBs e WebServices e por aí afora.
Ter o Domain Model como POJOs de negócio usando padrões de domínio permite testar regras d enegócio o tempo todo.
Acho a abordagem de vcs muito acertada. Como eles demonstram a apresentação ou os boundaries (conversa ApAp <-> Domain).
Você critica o funcionamento de fábricas em geral ou particularmente a sua?
|
|
|
|
okara wrote:
Mas você ter um repositorio muito inteligente não dispensaria o uso de um objeto Manager (gerenciador) ?
É essa minha dúvida.
O repositório é uma interface. Quem é o manager? Não entendi a sua pergunta...
|
|
|
|
O uso da transação com autosave é realmente muito bom, mas também acho que é confuso para nossas mentes que trabalham linearmente com o processo onde no fim "as coisas são salvas" e quem manda salvar é alguém. Determinados requisitos necessitam que as coisas sejam salvas no momento determinado pelo usuário. Nesse caso, tenho dúvidas da aplicação do autosave.
Digo isso pelo seguinte: imagine um cliente desconectado (Swing). Obtive do servidor uma lista de clientes para alterar o nome numa grid, mas só deve mudar mesmo quando eu clicar no salvar. Nesse caso, o salvar é explicito. Essa arquitetura resolveria? (essa é uma das razões para a minha preocupação com a transação)
Outra coisa é que não sei ao certo se é uma boa idéia deixar o Domain Model dependente da arquitetura. Será que não pode ocorrer um "downgrade" da arquitetura que pode me dar problemas? (só pensamentos my friend)
Vejo que a aplicação do QueryObject é bem específica para aquelas buscas por diversos parâmetros que podem ser opcionais. Não se aplica a tudo. Se for pensar assim os repositories só teriam uma operação o que semanticamente os deixariam "bem burros". Eu aplico QueryObject em "buscas com parâmetros diferenciados". Não sei se existem soluções mais fáceis, mas a implementação do QueryObject também causava náuseas nos programadores quando começava a se falar nos relacionamentos.
Pensando um pouco nos impactos gerados no processo:
Você concordaria comigo que o trabalho do "analista, designer ou o que for" é chegar no Domain Model? A partir dali os "programadores, codificadores ou o que for" poderiam tocar com uma grande parte dos requisitos garantidos? (lógicamente é preciso ter uma arquitetura definida que atenda esse nível de abstração).
|
|
|
|
|
|