I have tried many stereotypes, but have landed on the following that handle most situations. I have been using these to diagram solution architectures for two decades. We use these sparingly because most times a dependency is obvious enough based on its placement or unnecessary to indicate at this level of diagram. A line connects those other components to the lollipops to show that the components are using the interfaces.ĭependency. A dotted arrow indicates that the component where the arrow originates is dependent on the component to which the arrow terminates.A lollipop sticks out the side of a component when a component is providing an interface for other components.Components can be nested to show sub-components. Each box represents an architecturally significant component of the solution architecture.Plus, your users become more adept at understanding the diagrams over time because the notation is always the same.īefore I dig into more details about the notation, here is a quick 1-2-3 overview, along with an example.
Readers can understand them without any introduction, and a quick overview of a few elements of the notation can improve their comprehension even further. UML Component Diagram NotationĪs I mentioned, we stick to the essential elements of the UML component diagram notation to keep it simple for the people viewing the diagrams. We use the component diagram to depict the architecturally significant components of a solution architecture and how they are wired together. Structure diagrams show what the elements of the system are (as opposed to behavior diagrams which show what the system does). A component diagram is one of the seven structure diagrams in UML.
Check the UML benefits in my Activity Diagram article if you want a refresher on why we leverage the Unified Modeling Language notation. We stick to basic UML component model notation to create clear component designs. A component diagram depicts how you wire components together to form larger components or software systems.
0 kommentar(er)
