Browse DevX
Sign up for e-mail newsletters from DevX


UML for the Software Developer, Part 4: Deployment Diagrams : Page 3

Deployment diagrams act as the link and reference point between how the system is built and where it is displayed. Learn how capacity planning, n-tier development, and coordination of tasks between different teams can all benefit from these diagrams.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

The stage step adds the in-house developed components to the pre-stage diagram. Each component represents a set of classes similar to the ones that we added in the previous articles. Each component is a separate function in the system using the "Separation of Concerns" pattern from the last article. (See sidebar "Patterns")
Figure 3. Staging Step: In this deployment diagram the components for both the third-party software and in-house software are displayed. I have taken the attributes off the node since they were already captured in the first deployment diagram.
Author's Note: In this context, "Separation of Concerns" is the functional integrity of the component. Each component has one, and only one, function within the system, but may have multiple methods that are exposed. In typical OO development each component is defined by an interface that is the only way to interact with other components in the system. In reality, this is not always easy to achieve but ultimately every component should be developed in this fashion. The use of an interface to communicate with other components in a system is useful in maintaining the component—allowing the implementation to be changed without affecting any other component. This is referred to as "loosely coupled." The classes of a component should be seen as a cohesive pattern that implements the component's functionality. This is referred to as "high cohesion" or "connascence" in Fundamentals of Object-Oriented Design by Meiler Page-Jones.

In the staging diagram for Richmen Inc., I added components for the in-house developed pieces of the project. The Portfolio Calculator, PortfolioTradeIntegrator, PortfolioDBInterface, and BrokerEntry were built by development and stereotyped as executables. For reference I added a language attribute to the executable stereotype. There is also a configuration file called BrokerEntry.Config that contains configuration information for the client side of the project. I didn't add a web.config file because it is one more detail that can be safely ignored here.

The nodes in the diagram have also changed. I added a new node called PortfolioServer. The connections between the nodes have changed as well. Client is connected through PortfolioServer to QuoteServer and TradeEntryServer. This doesn't invalidate the other deployment diagram, but think of it as a different view of deployment.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date