UML Activity Diagram with variable number of concu

问题:

I'm struggling with modeling in UML a scenario where variable number of concurrent flows occurs. A good and simple real life scenario would be a POOL ride-sharing service. For first rider whole flow seems easy. However once first rider is in a car and driver picks up second rider, then it becomes difficult to show on diagram, as now rider 1 and rider 2 are concurrent flows, and number of these concurrent flows will always be variable, between 0 and number of maximum seats in a car.

What's the best UML diagram type and technique to model such a behavior? How do I explain and depict variable number of concurrent flows to the audience?

Audience is rather non-technical, being upper management / finance, so I would like to keep specific details about threads/classes/objects out of the picture.

Here is my attempt:

回答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.

An other possiblity is to show the states of the instances using state charts and how they synchronize using event and actions. But in this way the actions you want to show are less visible.

In general multi threading is handled quite implicitely in UML. This has of course some drawbacks and also some benefits. Especially, for ver complex cases where an explicit view to it is desirable for low level design (e.g., for safety critical systems) this is problem. There are some dedicated modelling languages available, e.g., AADL. For most of the business application and esp. very large scale applications the UML way is good or at least absolutely sufficient. As more explicit ways lead to far more complex designs on hingher levels, and that goal is to prevent this.

回答2:

Here is another approach that shows grayed out concurrent flow on activity diagram, but also adds extra activity/state diagram to show driver's perspective. On top of that I added signals as they are supposed to depict asynchronous activities.

However I'm afraid that concurrent flow might still be confusing. In simplest scenario there would be: 1 Server, 1 Driver (driver app) and multiple Riders (rider apps). What's visible on the activity diagram suggests that there are multiple Drivers (driver apps) instead!