Proposto na aula de Modelagem de Sistema de Informação do curso de mestrado em informática da UniRio, esse blog tem como objetivo apresentar o desenvolvimento da ferramenta SisGrup - Sistema de Suporte a Grupo de Pesquisa.
sexta-feira, 29 de maio de 2009
Diagramas de sequência
O diagrama abaixo representa o cenário de cadastro de uma pessoa como um membro em um grupo, no qual o usuário do sistema seleciona um grupo em uma lista e o sistema verifica que o usuário não está cadastrado e cria as instancias para o cadastro.
Olá pessoal, Me parece que o diagrama de sequência de vocês está na verdade modelando robustez (sem os estereótipos). De qualquer forma, também acho VÁLIDO!
Algumas observações: 1-Uma classe "boundary" NÃO DEVE interagir diretamente com uma classe de domínio (ROSEMBERG, 2007). Isso, por exemplo causou um problema no diagrama de vocês. O método identificaPessoa() já faz verificaMembro() e criaMembro(), enquando na verdade deveria haver uma classe de controle intermediária, orquestrando tudo isso. 2-Métodos sublinhados, e índice numerado sem hierarquia (1.1, 1.1.2, 1.2.3.4), são usados somente até a UML 1.4. Acho que vocês moderam o Diagrama no StarUML que ainda está desatualizado.
Meninos Muito legal o diagrama de vocês. Só paa elucidar melhor, acho que vocês poderiam colocar o ator na representação, enviando uma msg para o boundary. Abraços Capra
Oi meninos! ficou claro o diagrama de vocês! Uma única questão sobre o diagrama... como vocês não colocaram a descrição no retorno, não vi relevância.... bjs!
Salve pessoal! Vou fazer coro a 2 comentários já postados: acho que falta o ator no início da sequência de ações e colocar os retornos identificados com números ficou irrelevante. No mais, parabéns! Abs.
Meninos, copiando os amiguinhos =D - Acho legal representar o ator - Os números nas mensagens de retorno não são necessários. Isso é imposto pela ferramenta (a cada mensagem ela já informa o número e vocês não conseguem retirar??) Beijos
Eu sou a favor e contra também. Acho que o ator antes da fronteira é o ideal; e sobre o retorno dos métodos, acho desnecessário, pois vc não utiliza o retorno nos demais métodos. Poderia sujar o diagrama. Se fosse num diagrama mais complexo, poderia auxiliar muito o entendimento, mas ficou muito legal.
Olá boa noite. Senti falta da descrição das setas de retorno ao invés de números. Creio que a descrição tornaria o diagrama mais claro de entender. Uma dúvida: a classe boundary refere-se a classe ParticpaçãoEvento do diagram de objetos? Abçs
Olá pessoal,
ResponderExcluirMe parece que o diagrama de sequência de vocês está na verdade modelando robustez (sem os estereótipos). De qualquer forma, também acho VÁLIDO!
Algumas observações:
1-Uma classe "boundary" NÃO DEVE interagir diretamente com uma classe de domínio (ROSEMBERG, 2007). Isso, por exemplo causou um problema no diagrama de vocês. O método identificaPessoa() já faz verificaMembro() e criaMembro(), enquando na verdade deveria haver uma classe de controle intermediária, orquestrando tudo isso.
2-Métodos sublinhados, e índice numerado sem hierarquia (1.1, 1.1.2, 1.2.3.4), são usados somente até a UML 1.4. Acho que vocês moderam o Diagrama no StarUML que ainda está desatualizado.
é isso gente,
Abração
Fábio Gabriel.
Meninos
ResponderExcluirMuito legal o diagrama de vocês.
Só paa elucidar melhor, acho que vocês poderiam colocar o ator na representação, enviando uma msg para o boundary.
Abraços
Capra
Oi meninos! ficou claro o diagrama de vocês! Uma única questão sobre o diagrama... como vocês não colocaram a descrição no retorno, não vi relevância....
ResponderExcluirbjs!
Salve pessoal!
ResponderExcluirVou fazer coro a 2 comentários já postados: acho que falta o ator no início da sequência de ações e colocar os retornos identificados com números ficou irrelevante.
No mais, parabéns!
Abs.
Meninos, copiando os amiguinhos =D
ResponderExcluir- Acho legal representar o ator
- Os números nas mensagens de retorno não são necessários. Isso é imposto pela ferramenta (a cada mensagem ela já informa o número e vocês não conseguem retirar??)
Beijos
Não vai ter descrição no retorno dos fluxos ? É só para deixar mais claro e evitar possíveis divergências.
ResponderExcluirPessoal,
ResponderExcluirSó senti falta da descrição dos retornos.
abraços
Senti falta do retorno de fluxos.
ResponderExcluirPaula
Eu sou a favor e contra também. Acho que o ator antes da fronteira é o ideal; e sobre o retorno dos métodos, acho desnecessário, pois vc não utiliza o retorno nos demais métodos. Poderia sujar o diagrama. Se fosse num diagrama mais complexo, poderia auxiliar muito o entendimento, mas ficou muito legal.
ResponderExcluirOlá boa noite. Senti falta da descrição das setas de retorno ao invés de números. Creio que a descrição tornaria o diagrama mais claro de entender. Uma dúvida: a classe boundary refere-se a classe ParticpaçãoEvento do diagram de objetos? Abçs
ResponderExcluirOi, Pessoal,
ResponderExcluira menos das setas de retorno. Acho que está muito bom.
HJdM