Lecture 7
Lecture 7
Lecture 7
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
CONCEPTS REVIEW
• Component
• Required Interface
• Provided Interface
• Port
• Dependency
• Assembly Connector
• Delegation Connector
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
EXAMPLE: A COMPONENT, BLACK-BOX
VIEW
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
MODELING A COMPONENT’S RELATIONSHIPS
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
FOGURE 3: A COMPONENT DIAGRAM THAT SHOWS HOW THE ORDER SYSTEM COMPONENT DEPENDS ON
OTHER COMPONENTS
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
Figure shows that the Order System component depends both on the
Customer Repository and Inventory System components. Notice in this
Figure the duplicated names of the interfaces CustomerLookup” and
ProductAccessor.” While this may seem unnecessarily repetitive in this
example, the notation actually allows for different interfaces (and differing
names) on each component depending on the implementation differences
(e.g., one component provides an interface that is a subclass of a smaller
required interface)
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
EXAMPLE: A COMPONENT WHITE-BOX VIEW
SHOWING A COMPONENT’S INTERNAL STRUCTURE
To show a component’s inner structure, you merely draw the component
larger than normal and place the inner parts inside the name
compartment of the encompassing component. Figure 4 show’s the
Store’s component inner structure.
Using the example shown in Figure 4, the Store component provides the
interface of OrderEntry and requires the interface of Account. The Store
component is made up of three components: Order, Customer, and
Product components. Notice how the Store’s OrderEntry and Account
interface symbols have a square on the edge of the component.
This square is called a port. In a simplistic sense, ports provide a way to
model how a component’s provided/required interfaces relate to its
internal parts. (Note: In actuality, ports are applicable to any type of
classifier (i.e., to a class or some other classifier your model might
have).
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
Figure 4: This component’s inner structure is
composed of other components
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
By using a port, our diagram is able to de-couple the internals of the Store
component from external entities.
In Figure 4, the OrderEntry port delegates to the Order component’s
OrderEntry interface for processing. Also, the internal Customer
component’s required Account interface is delegated to the Store
component’s required Account interface port.
By connecting to the Account port, the internals of the Store component
(e.g. the Customer component) can have a local representative of some
unknown external entity which implements the port’s interface. The
required Account interface will be implemented by a component outside
of the Store component.
(Note: Typically, when you draw a dependency relationship between a
port and an interface, the dependent (requiring) interface will handle all
the processing logic at execution time. However, this is not a hard and
fast rule — it is completely acceptable for the encompassing component
(e.g., the Store component in our example) to have its own processing
logic instead of merely delegating the processing to the dependent
interface.)
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
You will also notice in Figure 4 that the interconnections between
the inner components are different from those shown in Figure 3.
This is because these depictions of internal structures are really
collaboration diagrams nested inside the classifier (a
component, in our case), since collaboration diagrams show
instances or roles of classifiers.
The relationship modeled between the internal components is
drawn with what UML calls an assembly connector.”
An assembly connector ties one component’s provided interface
with another component’s required interface. Assembly
connectors are drawn as lollipop and socket symbols next to
each other. Drawing these assembly connectors in this manner
makes the lollipop and socket symbols very easy to read.
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
EXAMPLE: A COMPONENT WITH PORTS
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
COMPONENT DIAGRAMS EXAMPLES
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
https://online.visual-paradigm.com/diagrams/tutorials/component-diagram-tutorial/
https://www.ionos.com/digitalguide/websites/web-development/uml-component-diagram/
EXAMPLE 1: ONLINE SHOPPING SYSTEM
The diagram shows "white-box" view of the internal structure of three related subsystems -
WebStore, Warehouses, and Accounting.
WebStore subsystem contains three components related to online shopping - Search
Engine, Shopping Cart, and Authentication.
Accounting subsystem provides two interfaces - Manage Orders and Manage Customers.
Warehouses subsystem provides two interfaces Search Inventory and Manage Inventory used by
other subsystems.
//www.uml-diagrams.org/examples/online-shopping-uml-component-diagram-example.html
EXAMPLE 2: WEB BASED MEAL ORDERING
EXAMPLE 3: TICKET SELLING SYSTEM
EXAMPLE 4: EMAIL PROGRAM
This component model illustrates how three basic modules interact via interfaces:
• email management (1)
• incoming email (2)
• outgoing email (3)
Email management (1) is the control center of this system, interacting with users and other
software modules via multiple interfaces and service ports. To enable users to monitor whether
everything is running smoothly, an interface and a service port (management port) are
provided for system administration. The “use arrow” with the dashed line indicates that the user
is dependent on this interface to perform their administration tasks.
Systems and components outside the modelled architecture can be connected to the system via
the provided interface labelled “Retrieve email”. Functions and data required by the outgoing
email module (3) are provided by the management module via the implemented and provided
interface labelled “Send email”. The management module also uses services and functions via
the “Receive email” interface for the incoming email module (2). Graphically, the connections
between components are represented with ball-and-socket joints for the interfaces.
This component diagram illustrates how the three main modules of an email software interact with each other via
interfaces and ports. It clearly illustrates the key functions of the email management module in the overall
system.
The example diagram shows the system components in a black-box view which
disregards the inner workings to provide a clearer overview. In a white-box view, a
component diagram will show the inner structure of components. For example, the
management component (1) could contain the functional sub-
components “frontend” and “system administration” which help the administrator
with system management
The white-box view shows the inner structure and clarifies which sub-components are included in the main
component “email management”. The modules “system administration” and “frontend” extend the range of
functions and are intended to support an administrator in ensuring efficient administration of the email system.