Deep Dive: Build a Song Request Deployment Engine Diagram
Now that you know all of the elements that comprise a UML deployment diagram. Let's take a look at a real life use case scenario.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

large

Here we have a music request service, this service is going to allow users to log in and then build playlists based on different songs that they want to pick out. This is a real-world application that I'm currently building now as we speak, I thought this would be a nice time to be able to see the deployment diagram that I built. This would be a challenging system to write by hand, with a simple type of diagram we can easily see how everything fits together.

Let's start off with the very top left node, we have a regular web service, this is going to be the user interface for the entire system. We can see that it needs to be on some type of device, that's the artifact. I added some additional details so we have an operating system of Linux and then we have a component inside that's going to leverage angular.

This has a few dependencies. It has a dependency on the API itself, which is going to be the backend that manages all of the data and the majority of the business logic, then it also has a dependency on the authentication system.

So it's going to connect to two different systems

  • One manages the process of logging in, checking if a user is registered and if they're allowed to be on the system
  • One manages the backend and I placed a couple of other artifacts that are protocols (JSON and restful API)

If you were to show this to me, I could see that you had an angular front end communicating with a Rails API and an authentication system. I'd then have some clues on how to build the system.

Talking about dependencies, this is a great example to analyze how dependencies work in software. We have Angular front end (we've covered its dependencies) but the authentication system technically has no set of dependencies. The reason for that is because of the way dependencies work in general. Dependency really means the system would not be able to function properly without whatever it's depending on.

The Angular front end needs dependencies, imagine if you went to it and it had no data, you couldn't log in. The authentication system, on the other hand, does not care about the angular front end, you could swap it out with a re-act front end and it would not care in the least. It simply takes in requests and gives responses, it does not depend on those other systems.

A system between node is the rails API. Technically it doesn't care or depend on the front end either. It simply is an API that takes in requests and then gives responses. However, it does have a dependency on the authentication system, the reason is that sometimes the responses are coming in and it is going to communicate with that auth system to ensure that it was a valid request.

That is a very common pattern you'll see where you'll have a javascript front end with a rails back end, many times between the two there will be some type of authentication system.

Each of these nodes is very similar in regards to its structure. It has a set of artifacts and components inside. You can use notes and comments to give more description for the developers, I noted that this is going to use JWT tokens for auth communication.

If I hand this to a Rails developer, this will give them a set of instructions on what to build.