UML Tutorial for Beginners
Blog containing resources for uml like lecture notes, lecture videos, lab manual, uml diagrams, objective bits, important questions and more.

04/10/2013 Categories: Architectural Modeling. No Comments on Component Diagrams



Component diagrams are one of the two kinds of diagrams for modeling the physical aspects of object-oriented software systems. A component diagram shows the organization and dependencies among a set of components. We use component diagrams to model the static implementation view of a software system.




Common Properties


A component is just a special kind of a diagram and shares the same common properties as the other diagrams like: a name and graphical contents. What distinguishes a component diagram from the rest of the diagrams is its content.




Component diagram commonly contain:

  • Components
  • Interfaces
  • Dependency, generalization, association and realization relationships.

Like all other diagrams, component diagrams may contain notes and constraints. Component diagrams may also contain packages.


Common Uses


When modeling the static implementation view of a system, we will typically use component diagrams in one of four ways:

  1. To model source code.
  2. To model executable releases.
  3. To model physical databases.
  4. To model adaptable systems.


Common Modeling Techniques


Modeling source code


To model a system’s source code:

  • Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotypes as files.
  • For larger systems, use packages to show groups of source code files.
  • Consider using tagged values indicating such information as the version number of the source code file, its author, and the date it was last changed.
  • Model the compilation dependencies among these files using dependencies.




Modeling an executable release


To model an executable release:

  • Identify the set of components you’d like to model.
  • Consider the stereotype of each component in this set.
  • For each component in this set, consider its relationship to its neighbors. Most, often this will involve interfaces that are realized by certain components and then imported by others.




Modeling a physical database


To model a physical database:

  • Identify the classes in your model that represent your logical database schema.
  • Select a strategy for mapping these classes to tables. You have to also consider the physical distribution of your databases.
  • To visualize, specify, construct and document your mapping, create a component diagram that contains components stereotyped as tables.
  • Where possible, use tools to help you transform your logical design into a physical design.




Modeling adaptable systems


To model an adaptable system:

  • Consider the physical distribution of the components that may migrate from node to node. We can specify the location of a component instance by marking it with a location tagged value.
  • If you want to model the actions that cause a component to migrate, create a corresponding interaction diagram that contains component instances. We can illustrate a change of location by drawing the same instance more than once, but with different values for its location tagged value.



Related Links:

Note: Do you have a question on this article or have a suggestion to make this article better? You can ask or suggest us by filling in the below form. After commenting, your comment will be held for moderation and will be published in 24-48 hrs.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll Up