Diagramas UML de aplicativos multithread

Para aplicativos de thread único, eu gosto de usar diagramas de classes para obter uma visão geral da arquitetura desse aplicativo. Esse tipo de diagrama, no entanto, não tem sido muito útil ao tentar entender aplicativos altamente multithread / simultâneos, por exemplo, porque diferentes instâncias de uma classe "vivem" em diferentes threads (o que significa que acessar uma instância é salvo apenas da única tópico em que vive). Conseqüentemente, associações entre classes não significam necessariamente que eu possa chamar métodos nesses objetos, mas, em vez disso, preciso fazer essa chamada no encadeamento do objeto de destino.

A maior parte da literatura que eu desenterrei sobre o tópico, como Projetando Aplicativos Concorrentes, Distribuídos e em Tempo Real com UML, de Hassan Gomaa, teve algumas boas idéias, como desenhar limites de encadeamentos em diagramas de objetos, mas no geral parecia um pouco acadêmico e prolixo demais para seja realmente útil.

Não quero usar esses diagramas como uma visão de alto nível do domínio do problema, mas como uma descrição detalhada de minhas classes / objetos, suas interações e as limitações devido aos limites de threads que mencionei acima.

Gostaria, portanto, de saber:

1. Que tipos de diagramas você achou mais úteis no entendimento de aplicativos multithread?
2. Existem extensões para a UML clássica que levam em consideração as peculiaridades de aplicativos multithread, por exemplo, através de anotações que ilustram
   • alguns objetos podem viver em um determinado encadeamento, enquanto outros não têm afinidade por encadeamento;
   • alguns campos de um objeto podem ser lidos a partir de qualquer thread, mas gravados apenas em um;
   • alguns métodos são síncronos e retornam um resultado, enquanto outros são assíncronos que obtêm solicitações enfileiradas e retornam resultados, por exemplo, por meio de um retorno de chamada em um encadeamento diferente.

O insight mais importante sobre como as execuções de encadeamento acontecem pode ser representado pelo que é conhecido como diagrama de sequência . Aqui está um exemplo da wikipedia

Este diagrama basicamente desenha a lista de eventos, juntamente com uma direção sobre uma única linha vertical, geralmente chamada de linha de vida . Nesse caso, cada encadeamento é proprietário de sua própria linha de vida. O diagrama permite a representação de todos os tipos de eventos, como síncrono, assíncrono etc.

A outra coisa mais importante nesses sistemas são os gráficos de estado ou diagramas de estado. Geralmente, isso se aplica apenas se o modelo é representado como uma máquina de estado. No entanto, na maioria dos sistemas multithread (onde os threads não são triviais), é melhor que eles sejam projetados para funcionar com algoritmos isolados para diferentes estados.

Existem outros tipos de diagrama, como o diagrama de interação e o diagrama de comunicação, mas acho que tentar desenhar o diagrama de sequência e os diagramas de estado trará maior clareza.

Minha resposta é complementar à de Dipan, pois envolve diagramas de sequência UML. Descobri que um estilo que não é 100% puro UML também é bom. Veja os diagramas usados ​​nos padrões de simultaneidade . Alguns são quase do tipo UML (mas este definitivamente não é padrão):

Se você estiver familiarizado com aguardar / notificar na sincronização de encadeamento Java, apreciará o seguinte diagrama de sequência do documento que mencionei:

Para aplicativos multiencadeados usando a mesma classe, o truque pode ser arrastar e soltar a mesma classe em cada modelo que representa um encadeamento. Você seria capaz de ter a mesma classe com visualizações diferentes e navegar no modelo e código clicando na classe, no diagrama ou no código. Eu sei que a mesclagem de modelos não é um conceito conhecido, mas funciona muito bem no Eclipse com Omondo.

Quero dizer que quando eu modelo um aplicativo grande que é composto por mais de um projeto. Crio um modelo para cada projeto e os mesclo em um projeto maior. Toda a modelagem é feita usando diagramas de classes, que é o modelo que obtive ao reverter o projeto completo do código java para a UML. Quero dizer que, no meu exemplo, uso o código existente e o inverto para um único modelo UML e, em seguida, mesclo todo esse código reverso que criou modelos UML em um único modelo grande. Você também pode criar vários modelos em vez de reverter o código existente. Ele funciona nos dois sentidos - na criação sem código ou no estágio de engenharia reversa com o código existente.

Não sei se faz sentido, mas talvez você possa criar um modelo grande, reagrupando submodelos para cada thread, como o que faço com a modelagem de projetos múltiplos? Espero que esta ajuda.