Modelando sistemas grandes com UML

Boa tarde,

por muitas vezes tenho visto frameworks interessantes em diversas linguagens e sistemas com arquiteturas interessantes. Vejo utilizarem os padrões de projetos e técnicas úteis de desenvolvimento. São sistemas e frameworks grandes e pra construí-los é necessário planejá-los utilizado a UML e seus diagramas, mas fico com uma dúvida:

Como organizar os diagramas da UML? Pq por muitas vezes eles ficam grandes e acabam ficando dificeis de encontrar as partes.

Alguém saberia responder as seguintes questões:

  1. Existe a necessidade de dividir um diagrama de classes ou de casos de uso para organizar melhor?

  2. Qual a melhor maneira de organizar a documentação de um sistema, apresentando seus diagramas ( diagrama de classes, casos de uso, atividades… ) ?
    Ex:
    Se fosse escrever a documentação no word e ir colando os diagramas, qual seria a melhor forma de fazer isso?

  3. Qual sua experiencia com uml nos seus projetos?

Se você responder apenas uma dessas questões já fico muito grato,

Um abraço

1 curtida

UML pode ser uma boa ferramenta de documentação, mas hoje em dia, ninguém mais defende projetar todo o sistema em UML para depois partir para implementação. Isso porque em 99% dos projetos, as chances dos requisitos mudarem antes mesmo da implementação começar são grandes. De qualquer maneira, se tiver que fazê-lo, eu organizaria eles por casos de uso. Uma ferramenta interessante para gerenciamento de projetos é o Jira, para casa caso de uso, ou user storie você pode anexar documentos, arquivos, etc. Enfim, tentar fazer um único diagrama de classes para o sistema é bobagem também, geralmente, faz-se um diagrama por estória.

Lembre-se da usabilidade e legibilidade.
Ler diagramas muito grandes é maçante e difícil, quanto maior o sistema, maior a complexidade.

Depende o que se pretende fazer.
Um gerenciador de versões é indispensável (CVS, GIT, etc). O maior problema, neste sentido, é garantir que as alterações e mudanças serão colocadas em seus devidos lugares.

Sempre trabalhei com UML para direcionar o desenvolvimento, na maioria das vezes, da forma errada, ou seja, fazendo engenharia reversa.