I’ve been spending quite a bit of time doing systems design with the help of component diagrams this week. I used to draw component diagrams as a bunch of simple boxes with a few interconnecting lines to show “relationships” between sub-components and call them high-level component diagrams. I was therefore quite surprised by - when done properly - how much additional information can be captured in this type of diagram e.g. for our SOA project we can show details of specific interface points between components.

As this is a new project we’re using the top-down approach to design. We have 2 remote teams designing separate but very interconnected parts of a fairly complex SOA system and the teams create and share the component diagrams for the individual pieces to help both sides understand each other’s designs and make sure everybody is on the same page. It’s working well. Design inconsistencies are spotted quickly and misunderstandings are avoided as we peer-review each other’s diagrams. We all prefer drawing boxes and arrows rather than writing copious amounts of text and diagrams are easy to update so the cycle is quick and productivity is high.

For modeling we use Borland Together Architect (finally something that knows UML 2.0!). Deliverables of our design phase can be either JPG exported diagrams or the entire Together Architect workspace as is. This is fantastic as we don’t waste time creating those of-little-value 100-page documents based on some 50Mb template which no one reads anyways and they are outdated the moment you start development.

With Together Architect I can take this whiteboard drawing:

and convert it into this in about 10 minutes:

I have used the following articles as reference during the component design stage:

• UML Component Diagrams - Really this one is all you need. It’s a great article that talks about component diagram best practices, describes some of the nuances in modeling components, describes the various ways to model relationships, etc. Excellent refresher article! Also:
• UML Basics: The Component Diagram (from IBM)
• Sparx Systems UML 2.0 Tutorial

As you start working with component diagrams you’ll quickly realise which things make sense and which don’t. Maybe it’s not necessary to show the DAO classes as a component on every diagram. Maybe indicating only a single type of relationship is good enough for this design and leaves it less cluttered. I believe that there is no right or wrong way of creating these diagrams. Different projects will have different requirements with respect to detail, types of components you want to show etc. As long as everybody on the team has the same understanding of diagram semantics and the diagrams are shared and reviewed across the team your project should get the maximum benefit of this stage of the design.