2. Component Diagram
• Component diagram menggambarkan struktur dan
hubungan antar komponen piranti lunak, termasuk
ketergantungan (dependency) diantaranya.
• Komponen piranti lunak : modul berisi code, baik berisi
source code maupun binary code, baik library maupun
executable, baik yang muncul pada compile time, link
time maupun run time.
• Umumnya komponen terbentuk dari beberapa class dan
atau package, tapi dapat juga berupa interface, yaitu
kumpulan layanan yang disediakan sebuah komponen
untuk komponen lainnya.
3. Component Diagram
- Bersifat statis
- Merancang produk
- Memperlihatkan organisasi serta
kebergantungan pada komponen-
komponen yang telah ada sebelumnya
- Berhubungan dengan diagram kelas.
4. Component Diagram
• Menggambarkan alokasi semua class dan object kedalam
komponen dalam desain fisik system software, termasuk
pengaturan dan kebergantungan antar komponen software
• Component dapat terdiri dari
– logical component, seperti business component, process
component, dll
– Physical component (software arsitektur) , seperti Com+, dot
NET,CORBA, dll
• Component digambarkan
dengan bentuk pada UML versi 1.*:
• Pada UML versi 2 digambarkan dengan bentuk
atau atau atau
5. •
• Stereotypes yang dapat digambarkan pada bentuk component
<<application>>,kumpulan aplikasi system
<<executable>>,component yang jalan di client
<<file>>, data file
<<infrastructure>>, technical component didalam system
<<source code>>, source file <<database>>
<<table>>, table data dalam sebuah database <<document>>
<<UI>>, User interface (screen, pages, report) <<library>>
dll <<web service>>
<<XML DTD>>
6. Component Diagram
Dependencies
• dimodelkan dengan garis terputus dengan panah terbuka
• gambarkan dependencies dari kiri ke kanan
Contoh:
<<ASP>> Source Code bergantung pada
<<database>> MySQL
• Dimungkinkan sebuah component dependencies pada interfaces
component lainnya
Contoh:
Inheritance
• inheriting/child component diletakkan dibawah parent component, dengan
arah panah menuju ke parent component
• dimodelkan dengan garis dengan panah tertutup
Contoh:
7. Interfaces - Component Diagram
• Interfaces adalah kumpulan >=1 methode dan >=0 attribute yang dapat
dipakai pada class tanpa menjadi behavior suatu class.
• Jenis interface ada 2 macam yaitu :
– Provide, digambarkan dengan bentuk lollipop
Pada UML 1.* bisa juga digambarkan dengan garis terputus dengan
panah tertutup
– Required, digambarkan dengan bentuk socket
• Penggambaran
interfaces dapat juga
dilakukan dengan
menambah bagian
component seperti
contoh dibawah ini
Bentuk grafik
8. Component Diagram
port
• adalah bentuk object yang menjelaskan interaksi antara object dan
lingkungannya
• digambarkan sebagai kotak kecil di pinggiran component <<component>>
Assembly connector Order
• Penghubung antara
2/lebih component
dimana
sebuah/beberapa
component provides
interfaces dan
component lain required
interfaces
• Digambarkan dengan
gabungan bentuk
interfaces
contoh:
9. Penggunaan Component Diagrams
• When you model the static implementation view
of a system, you'll typically use component
diagrams in one of four ways
– To model source code
– To model executable releases
– To model physical databases
– To model adaptable systems
10. Modeling Source Code
• Either by forward or reverse engineering, identify
the set of source code files of interest and model
them as components stereotyped as files.
• For larger systems, use packages to show
groups of source code files.
• Model the compilation dependencies among
these files using dependencies. Again, use tools
to help generate and manage these
dependencies.
12. Modeling an Executable Release
• Executable Release
– main executable (usually, a .exe file)
– libraries (commonly .dll files if you are working
in the context of COM+, or .class and .jar files if
you are working in the context of Java)
– Databases
– help files, and resource files
13. 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. (such as executables, libraries,
tables, files, and documents)
– For each component in this set, consider its
relationship to its neighbors
15. 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. Use one of three strategies :
• Define a separate table for each class
• Collapse your inheritance lattices so that all instances
of any class in a hierarchy has the same state
• Separate parent and child states into different tables
16. Modeling a Physical Database
– 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
18. Modeling Adaptable Systems
• To model an adaptable system
– Consider the physical distribution of the components
that may migrate from node to node can specify the
location of a component instance by marking it with a
location tagged value, which you can then render in
a component diagram (although, technically
speaking, a diagram that contains only instances is
an object diagram).
– If you want to model the actions that cause a
component to migrate, create a corresponding
interaction diagram that contains component
instances.
20. Forward and Reverse Engineering
• When you forward engineer a class or a
collaboration, you really forward engineer to a
component that represents the source code,
binary library, or executable for that class or
collaboration
• when you reverse engineer source code, binary
libraries, or executables, you really reverse
engineer to a component or set of components
that, in turn, trace to classes or collaborations.
21. Predefined Component Diagram
Stereotypes
• File
– Usually a source code file
• Binary / Library
– Usually a compiled segment directly linkable into other
compilations
• Executable
– Usually a directly executable module
• Table
– Usually a database table
• Page
– Usually a Web page
• Document
– Usually a documentation file (as opposed to compilable code)
26. Component Diagram
• Shows an
encapsulated class
and its interfaces,
ports, and internal
structure consisting of
nested components
and connectors
• Addresses the static
design
implementation view
of a system
31. Component and Composite
Structure Diagrams
• A component diagram shows the
internal parts, connectors, and ports
that implement a component
• A composite structure diagram shows
the internal structure of a class or a
collaboration
• The difference between component and
composite structure is small and we will
treat them both as component diagrams
32. Terms and Concepts
• An interface is a collection of operations that specify
a service that is provided by or requested from a
class or component
• A component is a replaceable part of a system that
conforms to and provides the realization of a set of
interfaces
• A port is a specific window into an encapsulated
component accepting messages to and from the
component conforming to specified interfaces
33. Terms and Concepts (con’t)
• Internal structure is the implementation of a
component by means of a set of parts that are
connected together in a specific way
• A part is the specification of a role that composes
part of the implementation of a component.
– In an instance of the component, there is an instance
corresponding to the part
• A connector is a communication relationship between
two parts or ports within the context of a component
34. Components
• A component is a replaceable part of a
system that conforms to and provides
the realization of a set of interfaces
• Graphically, a component is rendered
as a rectangle with a small two-pronged
icon in its upper right corner
35. Components and Interfaces
• An interface is a collection of operations
that are used to specify a service of a
class or a component
• An interface that a component realizes
is called a provided interface
– An interface that the component provides
as a service to other components
36. Components and Interfaces
• An interface that a component uses is called
a required interface
– An interface that the component conforms to when
requesting services from other components
• A given interface may be provided by one
component and required by another
• A component that uses a given interface will
function properly no matter what component
realizes that interface
38. Binary Replaceability
• The basic intent of every component-
based operating system facility is to
permit the assembly of systems from
binary replaceable parts
– Can create a system out of components
and then evolve that system by adding new
components and replacing old ones
39. Characteristics of A
Component
• It is replaceable
• It is part of a system
• It conforms to and provides the realization of a set
of interfaces
• Component diagrams can be used for both logical
and physical modeling
– Component diagrams are often used for physical
modeling of the software architectures of systems
40. Organizing Components
• Can organize components by grouping
them in packages in the same manner
in which one organizes classes
• Can organize components by specifying
dependency, generalization, association
(including aggregation), and realization
relationship among them
41. Ports
• A port is an explicit window into an
encapsulated component
• A port has identity
• Ports permit the interfaces of a component to
be divided into discrete packets and used
independently
• A port is shown as a small square straddling
the border of a component
– It represents a hole through the encapsulation
boundary of the component
42. Ports (con’t)
• Both provided and required interfaces may be
attached to a port
– A provided interface represents a service that can
be requested through that port
– A required interface represents a service that the
port needs to obtain from some other component
• Each port has a name so that it can be
uniquely identified given the component and
the port name
• Ports are part of a component
44. Internal Structure
• The internal structure of a component is
the parts that compose the
implementation of the component
together with the connections among
them
• A part is a unit of the implementation of
a component
– A part has a name and a type
47. Connector
• A wire between two ports is called a
connector
• Show connectors in two ways
– If two components are wired explicitly,
draw a line between them or their ports
– If two components are connected because
they have compatible interfaces, use a
ball-and-socket notation
• A delegation connector wires internal
ports to external ports of the overall
component
49. Component Diagrams
• A component diagram shows an
encapsulated class and its interfaces,
ports, and internal structure consisting
of nested components and connectors
• Component diagrams address the static
design implementation view of a system
