Design – How to Represent Database in Sequence Diagram: Actor or Boundary?

databasedesignentitysequence-diagram

I'm designing a system made of a web application and database. I use the <<Entity>> – <<Control>> – <<Boundary>> stereotypes in my UML diagram.

In the following sequence diagram, I already have an interaction with a system in the cloud. I want now to show also the internal database (on the same server). Shall I represent it as actor or as <<Entity>> ? And if I need to get information from database shall I put boundary object between the database and entity (like cloudBoundary between Student and the cloud system) ?

Best Answer

Short version:

The database plays technically the same role as your cloud system, even if it's local on your server. So you could represent it with an actor (if really you have to choose something).

As the database is external to your system, you'd need of course to have some boundary object(s) (e.g. gateways) to allow the other objects to interact with it.

Explanations

The Entity-Control-Boundary approach is closely related to use case modeling:

The idea of their inventor, Ivar Jacobson, was to derive in a systematic manner the classes required in a system to implement the identified use cases.
The philosophy is therefore that boundary classes represent the link between actors and use cases, that control classes are mapped to some use cases, and that entity classes represent the domain objects.

In a use case model, actors are humans or external system that interact with the system for the purpose of achieving a use case (i.e. an intent of an actor or a business requirement). For this reasons, databases are usually not part of the use case diagrams.

Databases appear if you dig below the use-case surface. The database should not itself be an entity, nor a control, nor a boundary. Even if from a use-case point of view the database could be understood as part of the system under consideration (because it's not an external system involved in the business interactions), technically, it remains an independent component, external to the system that you are developing.

The <<Entity>> stereotype is common enough that it was standardized in UML, totally in line with the ECB understanding:

<<Entity>>: A persistent information component representing a business concept.

Clearly, your database is not an entity according to this understanding. Even if you would develop your own database from scratch as part of the system.

<<Boundary>> and <<Control>> are non standard stereotypes. But if you need to access the external database, you'd need a boundary object acting as connector/gateway.

If you would develop a database from the scratch, as part of your system, then the database itself would be composed of a lot of <<Control>> objects that would manage the flow of information and interactions in relation with the other controls, entities and boundaries (in particular the stream objects that would represent the boundary to the file system).

Related Solutions

UML Sequence Diagrams – Implementation and Use Cases

I would say go as high level as you can while still including all the necessary method calls, etc for your topic. My reasoning for this is that if you're including every single interaction then you might as well just write the code yourself.

Personally, I have always viewed sequence diagrams more or less as "guidance" for the implementer. I've never viewed them as living documents - if the implementation differs from the design I won't go update the diagram (unless it's different because my design was wrong). However, you're right in assuming that it largely depends on the audience.

If you have a team full of experienced developers with knowledge of your product, you should be able to leave a few things out here and there and trust them to fill in the blanks with their best judgement. In my case, I usually confine my sequence diagrams to a particular topic, say "Process XYZ", and only show method calls and object interactions that are relevant to that topic, leaving out things in between that are obvious or are defined in another diagram. If I'm writing a diagram for a junior developer who's learning the project and domain, then I tend to be more specific.

The only reason I would include every single method call and interaction is if you're actually generating the code from the model. For example, I've worked on some embedded systems where we generate our code out of a Rhapsody model, so obviously in that case you should include as much as you can.

UML Sequence Diagram for Queue Processor

As the queue is an important component in the sequence you are presenting, it should most definitely be present with a lifeline.

As the consumer explicitly listens for events from the queue, I would start the diagram with the listen call from the consumer to the queue.
After that, the producer can insert its event into the queue (possibly with an indication that a considerable amount of time can elapse between the listen call and the insertion of the event). At this point, I would use two return arrows. One back to the producer to indicate completion of the insert call, and the other to the consumer to indicate completion of the listen call.
This is under the assumption that the producer and consumer execute asynchronously.

It would look like this:

+---+       +---+       +---+
| P |       | Q |       | C |
+---+       +---+       +---+
  |           |   listen  |
  |           | <|------- |
  |           |           |
  |  insert   |           |
  | -------|> ++          |
  | < - - - - ++  event   |
  |           ++ - - - - >++
  |           |           ++
  |           |           ++
  |           |   listen  ++
  |           | <|------- ++
  |           |           |

To indicate that the consumer is always listening, I have ended the diagram again with a listen call that hasn't returned.