UML for the Software Developer, Part 5: Component Diagrams

Their ability to show interdependencies between applications' components make component diagrams invaluable. They can however be surprisingly complex. Find out how to use the right architectural patterns within your component diagrams to make them manageable.

WEBINAR:

On-Demand

ccording to Clemens Szyperski (author of "Component SoftwareBeyond Object-Oriented Programming,"), software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. He continues to add that a software component can be deployed independently, is a unit of third-party composition and has no (externally) observable state. In UML we use component diagrams to break down systems into understandable chunks that show the dependencies between components.

Component diagrams in UML capture the essence of how components interrelate with each other. Each diagram consists of only three different elements: components, interfaces, and dependencies. Components are composed of interfaces to other components as well as dependencies, which show how the components depend upon each other.

Component diagrams differ from class diagrams in how software is represented. In a class diagram the implementation of the classes is source code (which is why code can be directly generated from a class diagram). In component diagrams executable code is represented, which is closer to the deployment diagrams I looked at in the part 4.

Class diagrams show relationships that represent the association between classes from the simple bidirectional association to the more complex compositions and aggregations shown in "Mastering Associations." Component diagram rely on dependencies for component relationships. Dependencies differ from the class associations because associations are references from one class to another and can be bidirectional whereas dependencies demonstrate the dependence of one component on another component. If a component with a dependency is missing, the missing component is added to the Global Assembly Cache (GAC) but nothing else is inferred.

Figure 1. The Different Component Elements: Each component in the example has a stereotype that represents what type of component it is and tags describing the vendor (proprietary is the same as in-house), the language (where applicable), and the version of the component. Dependencies point from the dependent class to the class that it depends upon. The interface will usually have a name, which in some cases will be a method call.

In class diagrams interfaces are treated as separate classes, which are implemented through their associations with other classes. In component diagrams the interfaces are an integral part of the component and are not always displayed.

Figure 2 is one of the component diagrams for Richmen, Inc., a fictional company used through this series of articles. The diagram is complicated even with only a small number of components. In systems where there are 100+ or even 1,000+ components the complexity of component diagrams is mind-boggling. Validating the diagram for any architectural problems is almost impossible. PortfolioVision depends upon both Portfolio and QuoteData. In the context of the other four components is this good or bad? Are there any obvious architectural problems?

Fortunately there is an easy and organized way to view a component diagram. In the following section I will show this solution using architectural patterns.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

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