| Autor |
Mensagem |
|
|
É bem comum que seus pojos possuam algum id no mapeamento. O session do hibernate possui uma operação load(class, serializable) que serve para obter uma entidade por id.
Veja se isso serve. Geralmente chamo esse load através de um cara que chamo de Repository que é uma abstração dessas operações do session (save, update, delete, load).
OKys?
|
 |
|
|
brunohansen wrote:
....
1.1.2 O Ator informa os dados de busca;
1.1.3 Sistema mostra os produtos encontrados;
....
1.2.1 Sistema possibilita que o ator pesquise o produto a ser excluido;
1.2.2 O Ator informa os dados de busca;
1.2.3 Sistema mostra os produtos encontrados;
Você não acha que a busca de produtos seria a mesma tanto para alterar quanto para excluir? Mas isso é só um detalhe. Aquela parte dos "eventos" também não é "tradicional".
|
|
|
|
Se esse é a sua versão definitiva, na minha opinião, não gosto de numerar. Outro ponto, você está descrevendo cenários e não casos de uso. Note que seus "fluxos alternativos" são um exemplo de utilização completa.
Bom, Bruno, casos de uso possuem diversos estilos de escrita. Isso varia de projeto para projeto. Atualmente estou usando Casos de Uso mais para mapear objetivos "de grande valia" para o usuário, isto é, CRUD estão fora. Para cruds não uso nem protótipo de tela e nem diagrama de navegação (como o Taz falou). Um simples texto numa lista de requisitos é suficiente:
FEAT 331: Permitir o cadastro de produtos;
http://www.agilemodeling.com/essays/fdd.htm
Razão: CRUD possui um risco tão baixo que não vale a pena. Caso de Uso é uma boa ferramenta para mapear objetivos que são arriscados para o projeto. Possivelmente esses objetivos terão um caso de teste derivado do caso de uso que valide esse objetivo. Além disso, esses casos de uso são os que realmente necessitam de uma investigação mais aprofundada em análise e arquitetura (aí é que entra mais UML).
Vou repetir o meu lema: Bom senso... o desenvolvimento de sistemas se baseia em bom senso...
De qualquer modo, nesse tópico, evoluí a discussão mais para elucidar a aplicação da técnica para quem está começando...
OK?
|
|
|
|
Exato, é a eterna questão do CRUD Use Cases, sobre sua aplicabilidade ou não. Foi o que falei no post abaixo:
http://www.guj.com.br/posts/preList/37595/202235.java#202235
Usei esse post mais para demonstrar a técnica.
|
|
|
|
brunohansen wrote:Fala Rodrigo olhando o caso de uso que você reescreveu me surgiu algumas dúvidas
Bruno, esse templatezinho que tenho instruído o pessoal é algumas adaptações que fiz na maneira que o Cockburn descreve no livrro Writting Eff. Use Cases.
Para falar a verdade, no fluxo [A1] faltou um primeiro passo:
- O Ator informa que deseja buscar um produto;
(Acho que isso vai dar mais sentido)
O caso de uso possui um fluxo básico, é a maneira mais comum do ator atingir o objetivo. Dessa maneira comum, surgem jeitos alternativos do ator atingir o objetivo ou por alguma razão o objetivo não pode ser alcançado.
A leitura do caso de uso nos diz que onde no fluxo básico [A1] ocorre. Isso facilita a decomposição de cenários que podem ser os seus Casos de Teste. O que chamamos de cenário 0 (zero) é o próprio fluxo básico:
- O Ator seleciona a opção de cadastrar o produto;
- O Sistema abre uma nova tela de cadastro de produtos;
- O Ator entra com os dados do produto;
- O Sistema cadastra o produto;
Como temos um fluxo alternativo, temos o cenário 1 (pesquisar produto):
- O Ator informa que deseja buscar um produto; (o passo que esqueçí)
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto.
- O Ator entra com os dados do produto;
- O Sistema cadastra o produto;
No fluxo alternativo [A2] que ocorre dentro de [A1], temos mais um cenário (remover produto):
- O Ator informa que deseja buscar um produto; (o passo que esqueçí)
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto;
? O Ator informa que deseja remover o produto;
? O Sistema remove o produto.
A indicação do ponto onde ocorre o fluxo alternativo é importante para a decomposição de cenários de maneira quase automatizada (algumas ferramentas ajudam nessa tarefa).
A lição 4 do curso on-line grátis da ASPERCOM explica isso melhor...
OK?
|
|
|
|
Heero, quando se fala no diagrama de sequência o mais comum é esse tipo de discussão. O que você precisa ter em mente é que o diagrama de sequência é um diagrama de interação, isto é, ele mostra como os componentes trocam mensagens para resolver um requisito (que geralmente é um caso de uso).
Essa resposta é você quem vai ter que investigar. Minhas dicas são: foque o diagrama na comunicação entre os componentes, se seu diagrama descobrir as operações public que resolvem a interação já está muito bom...
Não use o diagrama de sequência para demonstrar a implementação interna do componente. Só isso...
|
|
|
|
|
Tá muito ruim de ler... poste os arquivos como attach....
|
|
|
|
|
ha ha ha ha ha
|
|
|
|
Bom senso... o desenvolvimento de sistemas se resume a bom senso...
O risco da tal action dar problema é pequeno, digo ainda que é um código onde o teste é mais importante na tela do que na classe de teste.
|
|
|
|
O negócio para saber administrar é ter um estilo de vida compatível com o que você ganha. Se vc ganha 3.000 ainda não dá para andar de Audi A3.
O negócio é saber controlar. Faça uma planilhinha excell com o seu planejamento anual, e depois acompanhe a cada 15 dias se seu planejamento está indo bem, fazendo uma conciliação bancária. É importante você saber aonde seu dinheiro está indo, aí você vai ver as besteiras que faz. Vc sabe que eu sei exatamente aonde foi cada centavo que ganhei desde 1997? Pois é, depois que você começa a saber aonde vai o dinheiro essa planilha acaba te cobrando...
Outra coisa importante. Aproveitem enquanto vocês são jovens. Faça uma previdência privada. Pegue uma parte do seu salário e faça de conta que ele nem existe, coloque como débito automático. Faça um VGBL, PGBL agora. Eu começei o meu quando tinha 21 anos, devia ter começado com 18. Vou me aposentar com 51 anos ganhando um bom dinheiro. Se você com 20 anos paga 150 reais, com 50 anos e sem risco vc já juntou meio milhão no mínimo.
|
|
|
|
Rodrigo, meu xará... valeu pelas respostas... tenho mais uma dúvida então...
O que eu ganho usando o EntityManager? É só para dizer que estou usando EJB3?
|
|
|
|
Daniel Quirino Oliveira wrote:Sincronizar mudanças "na mão" acho ruim também (questão de gosto), principalmente para alguém tão descuidado e esclerosado como eu.
Eu também... isso tem nome... TDAH...
Annotations também tem o schemaexport?
Com annotations é obrigatório o uso do EntityManager?
Tem algum tipo de mapeamento que o annotations não faz?
|
|
|
|
Pessoal, estou acostumado a usar o Hibernate usando o XDOCLET/ANT para gerar os HBMs. Tem as suas limitações, o XML gerado é pavoroso, mas funciona muito bem e já estou acostumado.
Queria saber se o Annotations de Entity já está bem maduro e se o pessoal já está usando bastante e sem problemas.
Além do XDOCLET/Annotations tem mais alguma ferramenta que vocês usam e recomendam?
Aproveitem para responder a pesquisa...
Valeus!
|
|
|
|
Pacotes servem para organizar as coisas no projeto e também facilitam o fechamento do deployment (criação do jar de distribuição). A sugestão do Daniel é bastante utilizada.
Particularmente, eu não gosto desse br.com.xxxx na frente (apesar de ser uma recomendação, creio que da própria Sun). Mas sabe de uma coisa, o nome da empresa que possui o software não é constante, empresas mudam de nome, ou são compradas. Organizar o empacotamento baseado nas funcionalidades é uma boa...
Aqui na fábrica adotamos o padrão:
[nomeDoCliente].[nomeDoSistema].[subSistema].[camada]
nomeDoCliente e subSistema é opcional, o nome da camada deixamos um pouco menos verboso e chamamos de:
domain (entity, value-objects, services, repositories)
app (façades, registries, help classes)
view (actions, boundary classes em geral)
Ex.:
hotmotors.atendimento.domain
toyota.estoque.importacao.domain
Espero ter ajudado...
|
|
|
|
Vou dar os meus 2 cents, acho que posso dar a minha opinião já que estou passando "para o outro lado".
Já sou empresário a algum tempo, mas nos últimos 2 anos investi bastante tempo na minha empresa de treinamentos. E como a galera falou aqui, NÃO é fácil! Acho que tem uma pesquisa que diz que 80% das empresas fecham no primeiro ano de atividade. A responsabilidade é grande, mas o problema não é cuidar dos seus colaboradores a responsabilidade é cuidar dos seus clientes. No momento, posso dizer para vocês que trabalho de 12 a 16 horas por dia, no sábado também.
Agora tem o lado bom: você faz o que VOCÊ quer, são as suas regras, se der errado a responsabilidade é só sua. Outra coisa boa é que você não perde a motivação, você vê que o seu rendimento é 1000 vezes maior como empresário do que quando é empregado. Algumas vezes as coisas dão certo por sorte.
Opiniões de livros:
1. Pai Rico, Pai Pobre: é marketeiro sim, mas os conceitos são válidos e é uma leitura rápida. Acho que eu lí em 1 ou 2 dias.
2. Anxiomas de Zurique: para brasileiro é leitura obrigatória, pois não nos é ensinado nada sobre RISCO nas universidades. Brasileiro sai da escola para arrumar um bom emprego.
3. O Monge e o Executivo: é marketeiro, pra mim que já estudei bastante de teologia foi praticamente insuportável descobrir só na página 60 que o autor iria falar sobre o modelo de liderança de Cristo. Charles Swindoll já escreveu sobre isso 20 anos atrás (só que num livro que não é marketeiro).
4. Um Mundo sem Empregos: eu gosto, dá uma visão que acontece muito na nossa área (terceririzações, contrados PJ e etc...). Concordo muito com o autor que diz há muito trabalho, mas pouco emprego...
Só para mostrar um pouco de cultura inútil, há paralelos espetaculares entre finanças/economia e projetos de software. Na minha opinião o Agile Manifesto é a aplicação da Teoria da Reflexividade (George Soros) no desenvolvimento de software.
Bom, no geral, nenhuma leitura é ruim... depende da mente de quem lê...
|
|
|
|