具有可变数量并发流的 UML 活动图

Question

我正在努力在 UML 中建模一个发生可变数量并发流的场景。一个好的和简单的现实生活场景是 POOL 拼车服务。对于第一个骑手，整个流程似乎很容易。然而，一旦第一个乘客在车里，司机接了第二个乘客，那么就很难在图表上显示了，因为现在乘客 1 和乘客 2 是并发流，这些并发流的数量总是可变的，介于 0 和数字之间一辆车的最大座位数。

对这种行为进行建模的最佳 UML 图类型和技术是什么？我如何向观众解释和描述可变数量的并发流？

受众是非技术性的，属于高层管理人员/财务人员，因此我想将有关线程/类/对象的具体细节保留在图片之外。

这是我的尝试：

Answer 1

What you are showing in your diagram is an analysis of the flow for the complete application. This has some exemplary character, showing it for one instance of a rider app, one instance of a server, and one instance of a driver app. You want to show this now for an arbitrary number of rider and driver app instances. And this is design, because the analysis containing several rider instances is the same as for one instance, because there is no interaction between the individual rider app instances (at least it is not given in your example). Same for thedriver instances. This means the concurrency occurs only in the scope of the server design. Here you need to deal with this explicitely. So first of all you should develop a static design dealing with the different client types, i.e., you should have one client facade for the rider app and one for the driver. Each interaction between an client and the server has session object and so on. Further you have a server component, that contains the server logic. Now you need to decide on how the server works with the requests comming from the clients. As it is not beneficial to have in thread per client, you have a thread pool and queues for the requests.

For each server thread you should define an activity, showing how the data is treated, e.g. dequeued, ordered, processed, and this is done by showing it once. When you need to communicate between threads, you can use send and receive message actions, which is are the correct model elements for synchronizing and communicating between activities. Further you should define activieties for the client facades, showing how the data is received from the client app and send to them. There your view should also be focused on instance.

另一种可能性是使用状态图显示实例的状态以及它们如何使用事件和操作进行同步。但这样你想要展示的动作就不那么明显了。

一般来说，多线程在 UML 中是相当隐式处理的。这当然有一些缺点，也有一些好处。特别是，对于非常复杂的情况，其中需要明确的视图来进行低级设计（例如，对于安全关键系统），这是问题。有一些可用的专用建模语言，例如 AADL。对于大多数商业应用程序，尤其是。对于非常大规模的应用程序，UML 方式很好，或者至少绝对足够。随着更明确的方式导致更高级别的设计变得更加复杂，我们的目标就是防止这种情况发生。