W przypadku aplikacji jednowątkowych lubię korzystać ze schematów klas, aby uzyskać przegląd architektury tej aplikacji. Ten typ diagramu nie był jednak bardzo pomocny, gdy próbowano zrozumieć mocno wielowątkowe / współbieżne aplikacje, na przykład ponieważ różne instancje klasy „działały” w różnych wątkach (co oznacza, że dostęp do instancji jest zapisywany tylko z jednej wątek, w którym żyje). W związku z tym powiązania między klasami niekoniecznie oznaczają, że mogę wywoływać metody na tych obiektach, ale zamiast tego muszę wywoływać to w wątku obiektu docelowego.
Większość literatury, którą odkopałem na ten temat, na przykład Projektowanie aplikacji współbieżnych, rozproszonych i czasu rzeczywistego za pomocą UML autorstwa Hassana Gomyi, miało kilka fajnych pomysłów, takich jak rysowanie granic wątków w diagramach obiektów, ale ogólnie wydawało się to zbyt akademickie i trudne do zrobienia być naprawdę przydatnym.
Nie chcę używać tych diagramów jako ogólnego widoku problematycznej domeny, ale raczej jako szczegółowy opis moich klas / obiektów, ich interakcji i ograniczeń wynikających z granic wątków, o których wspomniałem powyżej.
Chciałbym zatem wiedzieć:
- Jakie rodzaje diagramów są najbardziej pomocne w zrozumieniu aplikacji wielowątkowych?
- Czy są jakieś rozszerzenia klasycznego języka UML, które uwzględniają specyfikę wielowątkowych aplikacji, np. Za pomocą adnotacji ilustrujących
- niektóre obiekty mogą żyć w pewnym wątku, podczas gdy inne nie mają powinowactwa do wątku;
- niektóre pola obiektu mogą być odczytywane z dowolnego wątku, ale zapisywane tylko z jednego wątku;
- niektóre metody są synchroniczne i zwracają wynik, podczas gdy inne są asynchroniczne, które powodują umieszczanie żądań w kolejce i zwracają wyniki, na przykład poprzez wywołanie zwrotne w innym wątku.
