CBSE 2014

Modeling Components with UML

 Bibliography
• Modelling components in UML
– Main text:
• Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006 ,
chapter 12 (Managing and Reusing Your System's Parts:
Component Diagrams)
– Additional readings:
• Documenting Component and Connector Views with UML 2.0,
Technical Report CMU-SEI-2004-TR-008,
http://www.sei.cmu.edu/library/abstracts/reports/04tr008.cfm
• Kim Hamilton, Russell Miles, Learning UML 2.0, OReilly, 2006 ,
chapter 11 (Modeling a Class's Internal Structure: Composite
Structures)
 UML Components
• These slides are based on the text: Kim Hamilton, Russell Miles, Learning UML 2.0,
OReilly, 2006 , chapter 12
• 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.
 UML Components
• 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, components can
have ports and show internal structure. It's common for a
component to contain and use other classes or components to
do its job.
– To promote loose coupling and encapsulation, components are
accessed through interfaces.
 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

• You can show that a component is actually

a subsystem of a very large system by
replacing <<component>> with
<<subsystem>>

Fig. 12.2 and 12.3 from [UML2]

 Provided and required interfaces
• Components need to be loosely coupled so that they can be
changed without forcing changes on other parts of the system.
• 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.
 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.
Ball and socket notation for interfaces

Fig. 12.4 from [UML2]

Stereotype notation for interfaces

Fig. 12.5 from [UML2]

 Listing component interfaces

This notation additionaly has an <<artifacts>> section listing the

artifacts or physical files manifesting this component

Fig. 12.6 from [UML2]

Showing components working together
If a component has a required interface, then it needs another class or
component in the system that provides it.

At a higher level view, this is a dependency relation between the components

Fig. 12.7, 12.8 and 12.9 from [UML2]

Example- component diagram presents system
architecture

Fig. 12.10 from [UML2]

 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.
There are 3 ways to depict this:

Fig. 12.12 , 12.13, 12.14 from [UML2]

 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.
• The topics of a class's internal structure and ports in the context of
composite structures are presented here first (based on Chapter 11
from [UML2] .
 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
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

Object diagram presents

unintended but valid
object structure

Fig. 11.3 and 11.4 from [UML2]

 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

Fig. 11.6 from [UML2]

 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

Fig. 11.9 from [UML2]

 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

Fig. 11.14 from [UML2]

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.

Fig. 11.15 from [UML2]

Ports and internal structure of
components

Fig. 12.15 and 12.16 from [UML2]

 Delegation connectors

Delegation connectors show how interfaces correspond to internal parts

Delegation connectors can also connect interfaces of internal parts with ports

Fig. 12.17 and 12.18 from [UML2]

 Assembly connectors

Assembly connectors show that a component requires an interface that

another component provides
Assembly connectors are used when showing composite structure of components
Fig. 12.19 from [UML2]
Black-box and white-box views

Fig. 12.20 from [UML2]