Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
Thanks!
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.
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.
