Galera, estou com uma duvida, qual a diferença entre:
Diagrama de Sequencia
Diagrama de Classes
Diagramas de Caso de Uso
Tipo como eu sei qual é o melhor para eu usar?
Em qual etapa do desenvolvimento eu preciso usar cada um?
vllw =D
Se aprofunde no assunto que vc vai descobrir…
estou estudando sobre isso! porem ainda não consegui identificar qual é o melhor diagrama para cada etapa de um projeto…
De todos, o diagrama de casos de uso é o menos importante. É a especificação de casos de uso que conta. Podemos dizer que tanto a especificação quanto o diagrama visam delimitar o que cada caso de uso fará e, normalmente, um caso de uso representa uma funcionalidade no sistema (manter clientes, manter produtos, realizar venda, efetuar pagamento, etc).
Casos de uso são a primeira etapa do desenvolvimento. É nele que serão identificadas as classes e os atores que interagem com o sistema.
O diagrama de classes que muitos consideram como o principal diagrama UML é criado a partir da identificação das mesmas na especificação de casos de uso. Ele contempla as principais (veja bem, somente as principais e não todas) as classes que estarão envolvidas no projeto, suas relações entre si e a multiplicidade destas. Além de classes, pode existir a definição de interfaces e enums que forem julgados principais. Cada classe conterá atributos (principais) e métodos (mais relevantes). Estes métodos serão utilizados para a criação do diagrama de sequência, considerando o relacionamento entre as classes. Este é o terceiro, em ordem, a ser desenvolvido.
Enfim, este é um modelo padrão, pode sofrer variações ou, como é comum, ser ignorado e tudo ser feito através de engenharia reversa.
Os diagramas da UML servem para as etapas de análise e design, qual a dúvida, neste ponto?
shenn,
Este assunto é complexo. Depende do processo de desenvolvimento. Existem vários processos de desenvolvimento e a forma de utilizar varia. Um deles é o processo unificado.
Tem um livro que explica muito bem os diagramas da UML e as etapas do processo unificado. Acho que dá para entender como usar os diagramas nas diversas etapas de um processo. É o livro do Craig Larman, Utilizando UML e padrões. Abaixo um link para o livro (on-line):
Então podemos dizer que a etapa inicial (quando o analista conversa com o cliente) é usado o diagrama de casos de uso, levantando os atores e as classes, depois de fazer isso parte pra documentação dos casos de uso…
Sendo que quando esta etapa está finalizada, a proxima etapa é criar os diagramas de classes, onde vai conter as principais funcionalidades do sistema, e a relação entre elas…
E com base no diagrama de classes é que se cria o diagrama de sequencia…
Tipo o diagrama de sequencia não representa praticamente a mesma coisa do diagrama de classes?
al.barbosa
Estarei dando uma olhada o mais breve possivel no livro =D
Sim. Como disse o drsmachado, o importante é a Especificação do caso de uso. É onde você descreve o fluxo principal e os fluxos alternativos. É útil mostrar a especificação ao cliente e verificar se é o que ele quer realmente.
Queria observar que em outros processos de desenvolvimento há outras alternativas para obter os requisitos. Por exemplo no XP pode-se utilizar as histórias do usuário.
Com base no diagrama de classe e também nas especificações dos casos de uso. O diagrama de sequencia contém as colaborações dos objetos em um cenário. É onde você vê as mensagens que são trocadas entre os objetos em sequencia.
Mas o diagrama de classes e de sequencia não precisam ser feitos um depois do outro. Quando você faz o de sequencia, descobre novos métodos que você vai colocando no diagrama de classes.
Sim, mas cuidado para não cair no modelo em cascata, onde precisa finalizar cada etapa completamente para iniciar outra. No processo unificado você faz uma parte dos casos de uso e passa para a análise e projeto (é um processo iterativo).
Não, o diagrama de classes é uma visão estática das classes com atributos e métodos. O diagrama de sequencia é uma visão dinâmica das trocas de mensagens em ordem.
As mesmas classes podem estar presentes em ambos os diagramas, mas são visões diferentes.
opaa vllw meeu a todos que ajudaram =D
consegui esclarecer uma duvidas que eu tinha =D
A idéia inicial da UML é permitir várias visões sobre o mesmo tema, no caso, o software a ser desenvolvido.
Cada um dos 14 (?) diagramas visa permitir a análise em um ponto de vista.
De todos estes, os diagramas de sequência, classes e atividades são os mais utilizados, por darem as visões mais específicas de como as classes interagem (mensagens entre os objetos), quais são as classes e como elas se relacionam entre si (sem considerar quando e como as mensagens são trocadas) e quais fluxos são processados entre os diversos casos de uso (sem considerar as classes).
Já a especificação e o diagrama de casos de uso são complementares ao levantamento de requisitos. Este levantamento tem como função obter o maior número de informações (de preferência 100% precisas) sobre o papel do software no negócio, quais os usuários, de que forma o mesmo irá ser operado, disponibilidade, estrutura física e nível de conhecimento dos possíveis atores.
Estas são regras gerais, pode-se adicionar ou remover coisas, usar em um ou outro modelo de desenvolvimento (como o al.barbosa citou), desde o tradicional (mas nem tão eficaz) cascata ou algum modelo de desenvolvimento ágil (como o SCRUM).
Lembrando, embora seja tratada como ferramenta de documentação, a UML visa modelar e, isso pode causar certa confusão. A documentação nem sempre coincidirá com o que os diagramas apresentam, devido à limitações de ambos e da forma como são empregados.
O modelo em cascata, citado pelo al.barbosa, determina que cada etapa seja feita por completo para que se passe à próxima. Para quem inicia parece ser adequado, pois é meio lógico andarmos um passo de cada vez. Acontece que este modelo não permite voltar à fase anterior para resolver problemas como o esquecimento de um requisito ou regra de negócio, que o cliente omitiu ou esqueceu no levantamento de requisitos.
Os modelos de desenvolvimento ágil, em geral, trabalham com escopos reduzidos, define-se uma entrega (geralmente parte ou todo de um caso de uso ou mais de um) e toda a estrutura desta é elaborada e desenvolvida durante o prazo estipulado, garantindo mais liberdade e agilidade à quem desenvolve. Em qualquer um dos modelos é extremamente necessário dedicação e disciplina, para que não sejam cometidos erros que comprometam a estrutura ou mesmo os prazos definidos para a etapa.