Component Diagrams - UML

Components are a slightly fuzzy concept in the UML, because both classes and components can be used to model the same thing. For example, to quote Rum - baugh (one of the UML founders):

The distinction between a structured class and a component is somewhat vague and more a matter of intent than firm semantics. [RJB04]

And to quote the UML specification [OMG03b]:

Acomponent represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and. required interfaces.

Again, this idea can be modeled with a regular UML class and its provided and required interfaces. Recall that a UML class can be used to model any level of software element, from an entire system to subsystem to small utility object.

But when one uses a UML component, the modeling and design intent is to emphasize

  1. that the interfaces are important, and
  2. it is modular, self - contained and replaceable. The second point implies that a component tends to have little or no dependency on other external elements (except perhaps standard core libraries); it is a relatively stand - alone module.

UML components are a design - level perspective; they don't exist in the concrete software perspective, but map to concrete artifacts such as a set of files.

A good analogy for software component modeling is a home entertainment system; we expect to be able to easily replace the DVD player or speakers. They are modular, self - contained, replaceable, and work via standard interfaces.

For example, at a large - grained level, a SQL database engine can be modeled as a component; any database that understands the same version of SQL and supports the same transaction semantics can be substituted. At a finer level, any solution that implements the standard Java Message Service API can be used or replaced in a system.

Since the emphasis of component - based modeling is replaceable parts (perhaps to upgrade for better non - functional qualities, such as performance), it's a general guideline to do component modeling for relatively large - scale elements, because it is difficult to think about or design for many small, fine - grained replaceable parts. Figure illustrates the essential notation.

Figure 38.2 UML components

The topic of dedicated component - based modeling and development is a large, specialized subject, outside of the scope of this introduction to OOA/D.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics