I am having issues identifying whether the database is a controller or boundary (view) in a sequence diagram. I have drawn the following sequence diagram for 'call queueing'. Is it correct?

CodePudding user response：

In short

The database would be part of a control. However, the control is meant for high level use-case logic/coordination whereas the database is low-level implementation of the control. It is not necessarily helpful to mix different levels of abstraction on the same diagram.

Arguments

The Entity Control Boundary decomposition is based on the use case models.

If the database system would be an actor, then the object that relates to the external database would be a boundary. But this would be misleading: database systems are implementation details of your system. Even if the database is shared between several application, it is not an autonomous system that would be of any use without an application that makes use of its content. So: not a boundary.

If the database is not an actor, then it is a component of your "system" (the system is then made of the app and the database). It cannot be a boundary (see above). It cannot be an entity either, since the users don't care about the database. In consequence, it can only be a control.

Controls are more meant for use-case logic (to implement the use case, and coordinate the entities and boundaries). So the database would at best be a part of a control (but control stereotype would be correct).

Moreover, some architectural patterns (e.g. "active recored") would use the database at the entity level. It is then ambiguous if it's really an entity (user's don't care) or if it is still a deported control. In reality you'd need to know the approach you want to take to manage persistent object in your design, before telling for sure.

I'd personally advise not to mix the levels of abstractions, as it makes the diagrams more difficult to understand and less useful.