| Autor |
Mensagem |
|
|
wellington_arantes wrote:rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria...
Acho que o seu diagrama de seq. está OK, só falei que não entendí a parte que a própria entidade retorna ela mesma. A interação diz como os componentes conversam para resolver o propósito do caso de uso. Aí sim você estará investigando o funcionamento interno do sistema.
O Caso de Uso é requisito. É O QUE o sistema tem que fazer, e não COMO ele faz, então, não precisa pensar em como ele funciona. Um protótipo ajuda a dar uma "cara" para o caso de uso e resolve muitos outros requisitos. Caso de Uso isoladamente não são suficientes para mapear todos os requisitos. Fórmulas e Cálculos também ficam fora do caso de uso.
Vc já pegou a idéia: O FOCO NO ATOR. O caso de uso resolve o que é importante para o Ator.
A estrutura do seu caso de uso está OK, fora os comentários que vc já entendeu...
|
 |
|
|
Vamos dar só uma melhorada na leitura do seu UC. Prefira usar o termo ator no texto, se por alguma razão o ator mudar você não precisa alterar o texto todo.
Fluxo Principal
- O Ator seleciona a opção de cadastrar o produto [A1];
- O Sistema abre uma nova tela de cadastro de produtos;
- [P1] O Ator entra com os dados do produto;
- O Sistema cadastra o produto;
Fluxo Alternativos
[A1] - Pesquisar produto
- 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. Volta para o passo P1 [A2]
[A2] - Remover produto
? O Ator informa que deseja remover o produto;
? O Sistema remove o produto. (não é o ator que remove, é o sistema)
Você está detalhando demais o caso de uso. Determinados detalhes é melhor deixar a responsabilidade para o seu caprichoso programador (mensagens de quando não existe dados para mostrar como exemplo). Outros detalhes como o botão cancelar estarão num protótipo e o programador deverá se preocupar com isso também.
Caso de uso se foca no Ator e não no Sistema. Casos de uso são requisitos e não possuem detalhes de implementação (note que vc só tem uma elipse).
OK?
|
|
|
|
cu_ringa, passe o seu problema (os requisitos) que podemos te ajudar melhor.... como um imóvel funciona, o que seus filhos tem de diferente?
Abraços!
|
|
|
|
cv wrote:Pq esse surto de 'e se o usuario estiver offline?'
A internet so funciona quando se esta online, e nao vejo ninguem reclamando - pelo contrario, ficar online esta cada vez mais facil, e azar pros que ainda nao se tocaram disso 
A menos que a sua base de usuarios alvo seja extremamente leiga, afastada dos grandes centros ou pobre (que talvez seja a pior base de usuarios pra arrumar), nao faz sentido.
Ainda existem muitas aplicações locais que necessitam ser locais ou por confiabilidade ou porque a infra-estrutura não pode atender uma conexão internet. Atualmente isso ocorre muito no comércio. Ex. Redes de Lojas distribuídas. Nesse cenário uma aplicação local que sincroniza com um servidor via linha discada a noite é a realidade. Pelo menos aqui no BR, conexão internet é de baixa confiabilidade e uma loja não pode parar de vender porque o link está fora do ar. Isso é uma necessidade comum e muito pouco explorada.
|
|
|
|
Não consigo baixar doc. cole o texto. O que falei é que devemos ao máximo alocar regras de negócio para entidades e não para as classes de controle.
OK?
|
|
|
|
Só para complementar o que o Shoes falou, atualmente a gente usa commands para camada de view. Actions do struts como exemplo. Geralmente não modelamos em UML essa camada. Se o sistema se baseia em Commands, aí UML não é uma boa opção para o design.
|
|
|
|
Welligton, tranquilo, todos estamos aqui para aprender... alguns comentários...
O caso de uso é o texto. O diagrama é só para ajudar. Tenho um artigo no curso online grátis que fala um pouco sobre caso de uso CRUD (apesar que geralmente caso de uso assim nem chega a existir). Quando falei sobre caso de uso é o texto que estava me referindo. Nesse post eu escreví um caso de uso simples:
http://www.guj.com.br/posts/list/37661.java#201019
Seu raciocínio está certo, mas geralmente um entity não consegue se criar a sí próprio (vixe). Geralmente temos um repository que serve para buscar entities (faça uma busca aqui no fórum que vc vai achar material, ou acesse o site do www.martinfowler.com, no catalogo de patterns). Este mesmo repository pode ter uma operação add(Entity) que cadastra.
Regras de negócio devem ao máximo serem alocadas aos entities e não para as classes de controle. Aliás, os stereotypes padrão da UML 2.0 são <<boundary>> , <<control>> e <<entity>>.
Você já tem o texto do caso de uso?
|
|
|
|
Eu tenho a versão em inglês e me falaram que a versão em português é 200 páginas menor. Achei isso estranho.
O livro não é "for Dummies" e na minha opinião é bem completo. Realmente a didática da série Head First não é tão "acadêmica", mas é bem interessante a abordagem de ensino deles. Eles tornam o ensino divertido, e isso é bem difícil conseguir. Dá para ler umas 200 páginas numa tacada só sem ficar desinteressado.
|
|
|
|
Seu diagrama aparenta estar OK, mas o diagrama de sequência não precisa ter todos os detalhes. Os diagramas de interação servem para alocar responsabilidades aos participantes, não são uma boa ferramenta para modelar o comportamento interno da classe.
Só estou achando estranho você conseguir obter uma entidade logo a partir do seu construtor. Geralmente essa pergunta é feita para um repository e não para a própria entidade. OK?
Se vc postar o caso de uso seria bom para complementar a minha opinião.
|
|
|
|
A melhor arquitetura é aquela que resolve os requisitos da maneira mais simples possível.
Na sua situação, se os requisitos permitirem, acho que Web seria melhor. Acho que seria bom ser ou tudo web ou tudo swing.
|
|
|
|
Vai do seu projeto.... nenhum diagrama é obrigatório. Você modela o que precisa ser modelado  . Se é simples mesmo, nem o diagrama de comunicação é necessário, nem mesmo uma descrição de caso de uso precisa. Pode acontecer de alguns projetos ter CRUDS enjoados, com regras.
Mas, geralmente cadastros de tabelas básicas são feitos no final do projeto, nas últimas iterações. Aquela fase final que só tem programador júnior na equipe!  As coisas mais arriscadas são resolvidas nas primeiras iterações.
|
|
|
|
É uma boa estratégia, mas leve em conta que a separação deve ser por área de negócio e não por tecnologia. A partir dos requisitos é mais fácil chegar ao código (saber o que o software faz), agora, decifrar o código para chegar nos requisitos é feia a coisa.
Se você tiver usuários chave para entrevistar e chegar aos requisitos facilita. Tendo uma prévia dos requisitos, use diagramas de alto nível primeiro, como o de atividades, para entender o fluxo. Talvez casos de uso não sejam indicados para esse problema.
|
|
|
|
Não ao ponto de programar em UML! A idéia do modelo é só alocar responsabilidades aos componentes, sem se preocupar com o funcionamento interno deles (isso você resolve no código).
Os diagramas de interação da UML são usados para mostrar a colaboração de objetos e não o funcionamento interno dos participantes da interação.
[]s
Rodrigo Y.
|
|
|
|
Nesse caso, fazer qualquer reversa não ajuda muito. Se você souber o que o software tem que fazer (requisitos) é melhor do que ter diagramas. De qualquer forma, o que é esse site? Se for só conteúdo não dá para dizer que é um software...
|
|
|
|
Deixa eu dar os meus $0,02... no caso do struts, abusar do jakarta commons ajuda um pouco. Vcs conhecem o LazyValidatorForm? Segue um exemplinho:
O JSP:
A action:
O struts-config.xml:
Moral da história. Com o LazyForm tudo que está no JSP vai para a Action. Com o copyProperties tudo que está no entity é copiado para o Form. O Lazy form dá uma tipagem mais leve para o form do struts.
|
|
|
|