Sơ đồ UML của các ứng dụng đa luồng

Đối với các ứng dụng đơn luồng, tôi muốn sử dụng sơ đồ lớp để có cái nhìn tổng quan về kiến ​​trúc của ứng dụng đó. Tuy nhiên, loại sơ đồ này không hữu ích khi cố gắng hiểu các ứng dụng đa luồng / đồng thời, vì các phiên bản khác nhau của một lớp "sống" trên các luồng khác nhau (có nghĩa là việc truy cập một thể hiện chỉ được lưu từ một ứng dụng chủ đề nó sống trên). Do đó, các liên kết giữa các lớp không nhất thiết có nghĩa là tôi có thể gọi các phương thức trên các đối tượng đó, nhưng thay vào đó tôi phải thực hiện cuộc gọi đó trên luồng của đối tượng đích.

Hầu hết các tài liệu tôi đã tìm hiểu về chủ đề như Thiết kế đồng thời, phân tán và ứng dụng thời gian thực với UML của Hassan Gomaa có một số ý tưởng hay, chẳng hạn như vẽ ranh giới luồng vào sơ đồ đối tượng, nhưng nhìn chung có vẻ hơi hàn lâm và khó hiểu thực sự hữu ích

Tôi không muốn sử dụng các sơ đồ này như một chế độ xem cấp cao của miền vấn đề, mà là mô tả chi tiết về các lớp / đối tượng của tôi, các tương tác của chúng và các giới hạn do ranh giới luồng tôi đã đề cập ở trên.

Do đó tôi muốn biết:

1. Những loại sơ đồ nào bạn thấy hữu ích nhất trong việc hiểu các ứng dụng đa luồng?
2. Có bất kỳ phần mở rộng nào cho UML cổ điển có tính đến đặc thù của các ứng dụng đa luồng không, ví dụ như thông qua các chú thích minh họa rằng
   • một số đối tượng có thể sống trong một luồng nhất định trong khi các đối tượng khác không có ái lực luồng;
   • một số trường của một đối tượng có thể được đọc từ bất kỳ chủ đề nào, nhưng chỉ được viết từ một;
   • một số phương thức là đồng bộ và trả về một kết quả trong khi các phương thức khác không đồng bộ nhận các yêu cầu được xếp hàng và trả về kết quả chẳng hạn thông qua một cuộc gọi lại trên một luồng khác.

Cái nhìn sâu sắc quan trọng nhất về cách thực hiện luồng xảy ra có thể được mô tả bằng cái được gọi là sơ đồ trình tự . Đây là một ví dụ từ wikipedia

Sơ đồ này về cơ bản vẽ danh sách các sự kiện cùng với hướng trên một đường thẳng đứng thường được gọi là huyết mạch . Trong trường hợp này, mỗi luồng là một chủ sở hữu của dòng đời riêng của nó. Sơ đồ cho phép đại diện cho tất cả các loại sự kiện như đồng bộ, không đồng bộ, v.v.

Điều quan trọng nhất khác trong các hệ thống như vậy là biểu đồ trạng thái hoặc biểu đồ trạng thái. Thông thường, điều này chỉ áp dụng nếu mô hình được biểu diễn dưới dạng máy trạng thái. Tuy nhiên, trong hầu hết các hệ thống đa luồng (trong đó các luồng không tầm thường), tốt nhất là chúng được thiết kế để hoạt động với các thuật toán biệt lập cho các trạng thái khác nhau.

Có các loại sơ đồ khác như sơ đồ tương tác và sơ đồ truyền thông nhưng tôi nghĩ cố gắng vẽ sơ đồ trình tự và sơ đồ trạng thái sẽ mang lại sự rõ ràng tối đa.

Câu trả lời của tôi là bổ sung cho Dipan ở chỗ nó liên quan đến các sơ đồ trình tự UML. Tôi thấy rằng một phong cách không phải là 100% UML thuần túy cũng vậy. Hãy xem các sơ đồ được sử dụng trong các mẫu tương tranh . Một số gần giống như UML (nhưng cái này chắc chắn không chuẩn):

Nếu bạn quen với chờ / thông báo trong đồng bộ hóa luồng Java, bạn sẽ đánh giá cao sơ ​​đồ trình tự sau từ tài liệu tôi đã đề cập:

Đối với các ứng dụng đa luồng sử dụng cùng một lớp, mẹo có thể là kéo và thả cùng một lớp vào mỗi mô hình đại diện cho một luồng. Bạn sẽ có thể có cùng một lớp với các khung nhìn khác nhau và điều hướng trong mô hình và mã bằng cách nhấp vào lớp, sơ đồ hoặc mã. Tôi biết rằng hợp nhất mô hình không phải là một khái niệm nổi tiếng nhưng nó hoạt động thực sự tốt trong Eclipse với Omondo.

Ý tôi là khi tôi mô hình hóa một ứng dụng lớn được tạo bởi nhiều dự án. Tôi tạo một mô hình cho mỗi dự án và sau đó hợp nhất chúng trong một dự án lớn hơn. Tất cả các mô hình được thực hiện bằng các sơ đồ lớp, đây là mô hình tôi có được khi đảo ngược toàn bộ dự án từ mã java sang UML. Ý tôi là trong ví dụ của tôi, tôi sử dụng mã hiện có và đảo ngược nó thành một mô hình UML duy nhất và sau đó hợp nhất tất cả mã ngược này đã tạo ra các mô hình UML thành một mô hình lớn duy nhất. Bạn cũng có thể tạo nhiều mô hình thay vì đảo ngược mã hiện có. Nó hoạt động cả hai cách mà lúc sáng tạo mà không có mã hoặc ở giai đoạn kỹ thuật đảo ngược với mã hiện có.

Tôi không biết nó có hợp lý không nhưng bạn có thể tạo một mô hình lớn, tập hợp lại các mô hình con cho từng luồng như những gì tôi làm với mô hình đa dự án không? Hy vọng điều này giúp đỡ.