| Autor |
Mensagem |
|
|
A gente discutiu um pouco a respeito disso na lista:
http://br.groups.yahoo.com/group/UML-BR/
Esse diagrama de domínio "nível 1" que você chama, seria um diagrama de classes de negócio. Se pegar no (R)UP, é um artefato que o Analista de Negócios faz. Geralmente é um diagrama bem desse jeitão que você falou: classes com espaço no nome, atributos sem tipagem, associações sem papéis e navegabilidade. Enfim, é um diagrama com classes "incodificáveis".
Pelo que vejo (IMHO), analista de negócio não sabe nada de OO, dessa forma, não deveria se meter a fazer diagrama de classes. Esse diagrama vira um artefato terrível de se manter e agrega muito pouco ao projeto. Um diagrama de classes só se faz necessário quando você quer investigar dados e associações de uma maneira que isso gere código para você agilizar a coisa. Se ficar muito no conceitual e se for incodificável é perda de tempo.
Domain Logic Patterns auxiliam muito a usar a UML dessa maneira que falei.
|
 |
|
|
Clique com o botão direito na generalização... selecione "Tree Style"... voilá... gol...
Semanticamente é a mesma coisa...
|
|
|
|
O artigo mais importante a respeito desse assunto é:
http://www.martinfowler.com/eaaDev/OrganizingPresentations.html
|
|
|
|
Fala luciano, usei o OpenUP e o EPF...
www.eclipse.org/epf
Tem uns videos de demonstração legais de como customizar o OpenUP para o Scrum...
|
|
|
|
Diagrama de implantação serve para mostra a distribuição física da aplicação (geralmente distribuída). Ele mostra uma estrutura de componentes, como eles são "fechados" e onde devem ser instalados. Imagine que sua instalação, o webserver, o appserver e o cliente possuem necessidades de configuração de máquina e/ou etc... você demonstra isso num diagrama de implantação.
É um diagrama com pouco uso prático...
|
|
|
|
É 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.
|
|
|
|