MANAGING AND REUSING YOUR SYSTEM'S

PARTS: COMPONENT DIAGRAMS

Lecture 6
1
Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006 ,( chapter 12)
 UML COMPONENTS
• Components are used in UML to organize a system into manageable, reusable, and swappable
pieces of software.
• UML component diagrams model the components in your system and as such form part of the
development view
• The development view describes how your system's parts are organized into modules and
components and is great at helping you manage layers within your system's architecture.

2
 Good candidates for components are items that perform a key functionality and will
be used frequently throughout your system. Software, such as loggers, XML
parsers, or online shopping carts, are components you may already be using. These
happen to be examples of common third-party components, but the same principles
apply to components you create yourself.
 In UML, a component can do the same things a class can do: generalize and
associate with other classes and components, implement interfaces, have
operations, and so on. Furthermore, as with composite structures. they can have ports
and show internal structure.
 The main difference between a class and a component is that a component
generally has bigger responsibilities than a class. For example, you might create a
user information class that contains a user's contact information (her name and
email address) and a user management component that allows user accounts to be
created and checked for authenticity.
 Furthermore, it's common for a component to contain and use other classes or
components to do its job. Since components are major players in your software
design, it's important that they are loosely coupled so that changes to a component
do not affect the rest of your system. To promote loose coupling and encapsulation,
components are accessed through interfaces.
3
 UML NOTATION FOR COMPONENTS
• A component is drawn as a rectangle with the <<component>> stereotype and an optional
tabbed rectangle icon in the upper righthand corner.

• In earlier versions of UML, the component symbol was a larger version of the tabbed
rectangle icon
• Figure 12-2 shows a ConversionManagement component used in the CMS that converts
blogs to different formats and provides feeds such as RSS feeds.
 You can show that a component is actually a subsystem of a very large system by
replacing <<component>> with <<subsystem>>, as shown in Figure 12-3. A subsystem is
a secondary or subordinate system that's part of a larger system.
 UML considers a subsystem a special kind of component and is flexible about how you
use this stereotype, but it's best to reserve it for the largest pieces in your overall
system, such as a legacy system that provides data or a workflow engine in the CMS.

4
 PROVIDED AND REQUIRED INTERFACES OF A COMPONENT
 Components need to be loosely coupled so that they can be changed without
forcing changes on other parts of the system this is where interfaces come in.
 Components interact with each other through provided and required
interfaces to control dependencies between components and to make
components swappable.
 A provided interface of a component is an interface that the component
realizes. Other components and classes interact with a component through
its provided interfaces. A component's provided interface describes the
services provided by the component.
 A required interface of a component is an interface that the component
needs to function. More precisely, the component needs another class or
component that realizes that interface to function. But to stick with the goal
of loose coupling, it accesses the class or component through the required
interface. A required interface declares the services a component will need.
6
UML NOTATION FOR PROVIDED AND REQUIRED INTERFACES

• There are three standard ways to show provided and

required interfaces in UML:
– ball and socket symbols
– stereotype notation
– text listings.

7
BALL AND SOCKET NOTATION FOR
INTERFACES

Fig. 12.4 from [UML2] 8

 You can show a provided interface of a component using the ball symbol . A required
interface is shown using the counterpart of the ball the socket symbol drawn as a semicircle
extending from a line.
 Write the name of the interface near the symbols. Figure 12-4 shows that the
ConversionManagement component provides the FeedProvider and DisplayConverter
interfaces and requires the Data Source interface.
 The ball and socket notation is the most common way to show a component's interfaces,

9
STEREOTYPE NOTATION FOR INTERFACES

Fig. 12.5 from [UML2] 10

 You can also show a component's required and provided interfaces by
drawing the interfaces with the stereotyped class notation . If a
component realizes an interface, draw a realization arrow from the
component to the interface. If a component requires an interface, draw
a dependency arrow from the component to the interface, as shown in
Figure 12-5. This notation is helpful if you want to show the operations
of interfaces. If not, it's best to use the ball and socket notation, since it
shows the same information more compactly.

11
LISTING COMPONENT INTERFACES

Fig. 12.6 from [UML2] 12

 The most compact way of showing required and provided
interfaces is to list them inside the component.
 Provided and required interfaces are listed separately, as
shown in Figure 12-6. This notation additionally has an
<<artifacts>> section listing the artifacts or physical
files manifesting this component.
 An artifact in the Unified Modeling Language (UML) is the
specification of a physical piece of information that is
used or produced by a software development process, or
by deployment and operation of a system.

13
 SHOWING COMPONENTS WORKING TOGETHER
 If a component has a required interface, then it needs another class or
component in the system to provide it. To show that a component with a
required interface depends on another component that provides it, draw a
dependency arrow from the dependent component's socket symbol to the
providing component's ball symbol, as shown in Figure 12-7.

Fig. 12.7: The ConversionManagement component requires the DataSource

interface, and the BlogDataSource component provides that interface

14
 As a presentation option for Figure 12-7, your UML tool may let you get
away with snapping the ball and socket together (omitting the
dependency arrow), as shown in Figure 12-8. This is actually the
assembly connector notation,

12.8 :Presentation option that snaps the ball

and socket together

15
 You can also omit the interface and draw the dependency
relationship directly between the components, as shown in
Figure 12-9.

12.9 :You can draw dependency arrows directly between

components to show a higher level view

16
EXAMPLE- COMPONENT DIAGRAM PRESENTS SYSTEM ARCHITECTURE

Figure 12-10. Focusing on the key components and interfaces in 17

your system
 Remember that interfaces help components stay loosely coupled, so
they are an important factor in your component architecture. Showing
the key components in your system and their interconnections through
interfaces is a great way to describe the architecture of your system,
and this is what the first notation is good at, as shown in Figure 12-10.

18
CLASSES THAT REALIZE A COMPONENT
 A component often contains and uses other classes to implement its functionality. Such classes are
said to realize a component.
 You can show realizing classes by drawing them (and their relationships) inside
the component. Figure 12-12 shows that the BlogDataSource component
contains the Blog and EnTRy classes. It also shows the aggregation relationship
between the two classes.

Fig. 12.12: The Blog and Entry classes realize the BlogDataSource
component 19
 12.13: Alternate view, showing the realizing
classes outside with the dependency 12.14 :You can also list the
relationship realizing classes inside the
component

 The final way to show realizing classes is to list them in a <<realizations>>

compartment inside the component, as shown in Figure 12-14.
20
 PORTS AND INTERNAL STRUCTURE
• There is heavy overlap between certain topics in component diagrams and composite
structures.
• The ability to have ports and internal structure is defined for classes in composite
structures.
• Components inherit this capability and introduce some of their own features, such as
delegation and assembly connectors.

21
Fig. 12.15 and 12.16 from [UML2] 22
PORTS
A port is a point of interaction between a class and the outside world.
It represents a distinct way of using a class, usually by different types of clients.

For example, a Wiki class could have two distinct uses:

•Allowing users to view and edit the Wiki
•Providing maintenance utilities to administrators who want to perform actions such as rolling back the Wiki
if incorrect content is provided

Each distinct use of a class is represented with a port, drawn as a small rectangle on the boundary of the
class

23
It's common for classes to have interfaces associated with ports.
You can use ports to group related interfaces to show the services
available at that port.

24
 COMPOSITE STRUCTURES
• Composite structures show:
– Internal structures
• Show the parts contained by a class and the relationships between the
parts; this allows you to show context-sensitive relationships, or
relationships that hold in the context of a containing class
– Ports
• Show how a class is used on your system with ports
– Collaborations
• Show design patterns in your software and, more generally, objects
cooperating to achieve a goal
• Composite structures provide a view of your system's parts and form part of the logical
view of your system's model

25
WHEN CLASS DIAGRAMS WON’T WORK
Class diagram shows that BlogEntry contains objects of
type Introduction and MainBody through composition.
Also, you would like that your diagram reflects that a blog entry's
introduction has a reference to its Main body

26
Object diagram presents unintended but valid object structure

27
 PARTS OF A CLASS

 When showing the internal structure of a class, you draw its parts, or items contained by
composition, inside the containing class.
 Parts are specified by the role they play in the containing class A part is a set of instances that
may exist in an instance of the containing class at runtime

28
 CONNECTORS

 Relationships between parts are shown by drawing a connector between them.

 A connector is a link that enables communication between parts: it means that
 runtime instances of the parts can communicate.

29
 DELEGATION CONNECTORS
 A delegation connector is a connector that links the external contract of a component (as specified by
its ports) to the realization of that behavior. It represents the forwarding of events (operation requests
and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports
on parts will be passed on to those targets for handling.
 A component's provided interface can be realized by one of its internal parts.
Similarly, a component’s required interface can be required by one of its parts. In
these cases, you can use delegation connectors to show that internal parts realize
or use the component's interfaces.
 Delegation connectors are drawn with arrows pointing in the "direction of traffic,"
connecting the port attached to the interface with the internal part. If the part
realizes a provided interface, then the arrow points from the port to the internal
part.
 If the part uses a required interface, then the arrow points from the internal part to
the port. Figure 12-17 shows the use of delegation connectors to connect
interfaces with internal parts.
30
31
 You can think of the delegation connectors as follows: the port
represents an opening into a component through which
communications pass, and delegation connectors point in the
direction of communication.
 So, a delegation connector pointing from a port to an internal part
represents messages being passed to the part that will handle it.
 If you're showing the interfaces of the internal parts, you can connect
delegation connectors to the interface instead of directly to the part.
This is commonly used when showing a component that contains
other.
 Figure 12-19 demonstrates this notation. The ConversionManagement
component has a Controller and a BlogParser component. The
ConversionManagement component provides the FeedProvider
interface, but this is actually realized internally by the Controller part.

32
Figure 12-18. Delegation connectors can also connect interfaces of internal
parts with ports
33
 ASSEMBLY CONNECTOR
 An assembly connector is a connector between two or more parts or ports
on parts that defines that one or more parts provide the services that other
parts use.
 Assembly connectors show that a component requires an interface
that another component provides. Assembly connectors snap together
the ball and socket symbols that represent required and provided
interfaces. Figure 12-19 shows the assembly connector notation
connecting the Controller component to the BlogParser
component.

34
Figure 12-19. Assembly connectors show components working together through interfaces

35
 BLACK-BOX AND WHITE-BOX VIEWS
 There are two views of components in UML: a black-box view and a white-box
view. The black-box view shows how a component looks from the outside,
including its required interfaces, its provided interfaces, and how it relates to
other components. A black-box view specifies nothing about the internal
implementation of a component. The white-box view, on the other hand, shows
which classes, interfaces, and other components help a component achieve its
functionality.
 A white-box view is one that shows parts inside a component, whereas a black-
box view doesn't, as shown in Figure 12-20.
 When modeling your system, it's best to use black-box views to focus on large-
scale architectural concerns. Black-box views are good at showing the key
components in your system and how they're connected.
 White-box views, on the other hand, are useful for showing how a component
achieves its functionality through the classes it uses.
 Black-box views usually contain more than one component, whereas in a white-
box view, it's common to focus on the contents of one component
36
Figure 12-20. Black-box component views are useful for showing the big picture of
the components in your system, whereas white-box views focus on the inner
workings of a component 37