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.

by Mark Goetsch

June 1, 2005

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.

In this article I'll use component diagrams to link the class diagrams I discussed in earlier articles (see part 1, "Building Classes," part 2, "Mastering Associations," and part 3, "Aggregating") with the "Deployment Diagrams" in Part 4.

It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com.
Already a member?

To become a member of DevX.com create your Member Profile by completing the form below.
Membership is free!

Already registered? Sign In

E-mail (User Name)

Create a Password

Re-enter Password

First Name

Last Name

Company

Company Size

Address

City

State/Province

Country

Postal Code/Zip

Job Function

Phone

Note: Extension number is optional, but may be included by adding an "x" before the extension number.

By registering you will also be signed up for the Enterprise Development Daily newsletter.
After registering you may choose to opt-out by clicking on the "Manage Profile" link.

Cancel