I am designing a Deployment diagram and a Component diagram for an existing Java EE application.

The app has integration with 3 external systems through soap web services and ftp.

I am including these systems in the Component diagram but I'm not sure if I should include them in the deployment diagram. Should I? I could not find if the standard for UML says anything about this.

If I have to include them, what would the stereotype be for those nodes?



In the UML specification, Section 11 describes component diagrams and Section 19 describes deployment diagrams. There's nothing that says that you can or can't include external systems, services, or components on either diagram type.

Personally, I would probably do the opposite of what you are doing. I would include external services on the deployment diagram and not on the component diagram.

The intention of the deployment diagram is to "capture relationships between logical and/or physical elements of systems and information technology assets assigned to them". The users of a deployment diagram include the people responsible for the physical infrastructure of the system. For these people, knowing that the system interacts with external services can be useful, especially if there are specific network ports that need to remain open in firewalls or ensure that physical resources that contain specific artifacts remain accessible to the outside world.

On the other hand, a component is a "modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment". The information here is more important to mapping requirements to pieces of the software system, planning for reuse, the specific interfaces between pieces of the system, providing a graphical overview of elements that may be decomposed in more detail in other views of the system. These are of more interest to software developers and architects who may not care as much about the specific nature of the services and where they live, but rather what is part of the system under development and how these pieces interact.

However, you should make the diagrams make sense to you. Maybe, for your audience, showing the external systems on deployment and component diagrams makes communication easier. UML is a communication tool - it provides a common language to communicate the design of a software system. My preference is to embrace many of the agile modeling techniques and stick to the standard notations and spirit of the language, but think about who am I making the diagram for and what will help them do their job.

  • 1
    I would think that leaving external services out of the component diagram makes it harder to reason about all interfaces Provided and Required by your component. Maybe in a sub-architecture view where you have drilled down it is probably not important, but at the highest level of your system view I think it is a good idea to show it – maple_shaft Oct 28 '16 at 12:11
  • 1
    @maple_shaft That makes sense, too. For me, I tend to use deployment diagrams as that high level view. From there, I'll drill into component diagrams as the next level of detail, followed by other models - class, object, activity, etc. There may be multiple levels of component and lower, as well, depending on complexity. – Thomas Owens Oct 28 '16 at 12:27
  • @maple_shaft That's exactly why I thought it would be convenient to show the external sevices as components, so I could show what interfaces they provide and which of my components require those interfaces. But since they are not part of our application, I was not sure if I should include them in the component diagram. – David Lizárraga Oct 29 '16 at 11:37
  • @ThomasOwens Thanks for your very didactic answer. It makes sense too, I specially like the part about showing the services in the deployment diagram as it can be useful for other people. What made me think I should not show them in the deployment diagram was that they are third party services, not inside our infrastructure. The app is already created, but we did not have those two diagrams yet. When completed, we'll present them to the client so I'm guessing the more info we put on them the better. Maybe I include them in both diagrams, but I will still think about it a little more. – David Lizárraga Oct 29 '16 at 11:37

While ThomasOwens leaves a fantastic answer here, I have a differing opinion to the question asked, however I also won't say he is incorrect. After all, as he had already pointed out, the diagram should have maximum communicative benefit while staying as focused as possible.

There are a number of types of Deployment diagrams that one might want to make and each kind can be used to show a unique view of the system. Deployment diagrams can be used to show the physical manifestation of components in a system, a specification for artifacts to deployment targets, and yes even the physical or logical infrastructure of a system.

External services and FTP connections like Thomas Owens said MIGHT be important to communicate the logical infrastructure of your system (Eg. firewalls, FTP client software packages, etc...) however unless you considered these services or FTP drop locations as part of your logical infrastructure then I wouldn't show them as Nodes in your diagram. What I typically do is draw the border around my logical infrastructure then have a nebulous box just to put a name to something on the other end of that communication path.

I prefer however to show external services and the like in component diagrams. Components within a system typically operate within a greater system (Eg. Enterprise, Internet, Client Intranet over VPN, etc...) so I view elements like this as external components with a well defined interface. Since components can both Provide and Require interfaces to other components, one really should demonstrate external system component interfaces so that it is clear what YOUR component Requires. Documenting this allows Architects and Developers to more easily reason about the components they must build.

In the end though, there are no hard and fast rules for these kinds of things, and as always, stay within the loose guidelines where you can until they don't benefit you. A diagram should be a tool to aid in the communication of a system so the most important thing is to ensure that your audience finds all the answers they need and gets everything they want out of your diagrams.

  • Thanks for the answer. I consider this one also a perfectly valid answer, although in my specific case we ended up putting the external services in the deployment diagram :) – David Lizárraga Nov 9 '16 at 11:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.