The document discusses implementation diagrams in UML, specifically component diagrams and deployment diagrams. It provides details on what each diagram type models (components/relationships for component diagrams and nodes/relationships for deployment diagrams). It also provides examples of a component diagram modeling source code files and dependencies, and a deployment diagram modeling a client-server architecture. Guidelines are given for effectively using these diagram types.
2. R
R
R
Implementation Diagrams
• Both are structural diagrams
• Component Diagrams:
– set of components and their relationships
– Illustrate static implementation view
– Component maps to one or more classes, interfaces, or
collaborations
• Deployment Diagrams:
– Set of nodes and their relationships
– Illustrate static deployment view of architecture
– Node typically encloses one or more components
3. R
R
R
Package
• General purpose mechanism for
organizing elements into groups
• Can group classes or components.
Package Name
4. R
R
R
Component Diagram
• Classes
• Interfaces
• Dependency, generalization, association, and
realization relationships
Special kind of class diagram focusing on
system’s components.
Example.java
5. R
R
R
Interfaces
• Definition:
– Collection of operation signatures and/or attribute defns
– Defines a cohesive set of behaviors
• Realized by:
– Implemented by classes and components
– Implement operations/attributes defined by interface
• Relationships:
– A class can implement 0 or more interfaces
– An interface can be implemented by 1 or more classes
• Notation:
– Lollipop
– Dashed arrow
9. R
R
R
Common Uses:
• Model source code:
– model configuration mgmt
• Model executable releases
– Release is relatively complete and consistent set
of artifacts delivered to user
– Release focuses on parts necessary to deliver
running system
– Component Diagram visualizes, specifies, and
documents the decisions about the physical parts
that define the software.
10. R
R
R
Common Uses: (cont’d)
• Model Physical databases:
– database is concrete realization of schema
– schemas offer an API to persistent information
– model of physical dbases represents storage of that
information in tables of a relational dbase or pages of
an OO dbase.
– Component Diagram can represent this kind of
physical database
• Model Adaptable systems:
– can model static aspects of adaptable systems
– can model dynamic aspects (in conjunction with
behavioral models)
11. R
R
R
Modeling Source Code
• (Forward/Reverse Eng): identify set of
source code files of interest
– model as components stereotyped as files
• Larger systems: use packages to show
groups of source code files
• Model compilation dependencies
among files
12. R
R
R
Modeling Source Code Example
• 5 source code files
– signal.h (header)
– used by 2 other files
(signal.cpp, interp.cpp)
– interp.cpp has compilation
dependency to header file
(irq.h)
– device.cpp compilation
dependency to interp.cpp
Signal.h
{version=3.5}
Signal.h
{version=4.0}
Signal.h
{version=4.1}
<<parent>> <<parent>>
Interp.cpp Signal.cpp
Irq.h
Device.cpp
13. R
R
R
Component Diagram Guidelines
• Use Descriptive Names for Architectural
Components
– Use Environment-Specific Naming Conventions for Detailed Design
Components
– Apply Textual Stereotypes to Components Consistently
– Avoid Modeling Data and User Interface Components
• Interfaces
– Prefer Lollipop Notation To Indicate Realization of Interfaces By
Components
– Prefer the Left-Hand Side of A Component for Interface Lollipops
– Show Only Relevant Interfaces
• Dependencies and Inheritance
– Model Dependencies From Left To Right
– Place Child Components Below Parent Components
– Components Should Only Depend on Interfaces
– Avoid Modeling Compilation Dependencies
14. R
R
R
Common Stereotypes
Stereotype Indicates
<<application>> A “front-end” of your system, such as the collection of HTML pages and ASP/JSPs
that work with them for a browser-based system or the collection of screens and
controller classes for a GUI-based system.
<<database>> A hierarchical, relational, object-relational, network, or object-oriented database.
<<document>> A document. A UML standard stereotype.
<<executable>> A software component that can be executed on a node. A UML standard stereotype.
<<file>> A data file. A UML standard stereotype.
<<infrastructure>> A technical component within your system such as a persistence service or an audit
logger.
<<library>> An object or function library. A UML standard stereotype.
<<source code>> A source code file, such as a .java file or a .cpp file.
<<table>> A data table within a database. A UML standard stereotype
<<web service>> One or more web services.
<<XML DTD>> An XML DTD.
16. R
R
R
Deployment Diagram
• Shows the configuration of:
– run time processing nodes and
– the components that live on them
• Graphically: collection of vertices and
arcs
17. R
R
R
Contents
• Deployment diagrams contain:
– Nodes
– Dependency and association relationships
– may also contain components, each of
which must live on some node.
18. R
R
R
A Deployment Diagram
<<network>> local network
<<processor>>
primary server
<<processor>>
Caching server
<<processor>>
Caching server
<<processor>>
server
<<processor>>
server
<<processor>>
server
Modem bankInternet node
connection
19. R
R
R
Modeling Client-Server
Architecture
• Identify nodes that represent system’s
client and server processors
• Highlight those devices that are
essential to the behavior
– E.g.: special devices (credit card readers,
badge readers, special display devices)
• Use stereotyping to visually distinguish
20. R
R
R
Client-Server System
• Human resource system
• 2 pkgs: client, server
• Client: 2 nodes
– console and kiosk
– stereotyped, distinguishable
• Server: 2 nodes
– caching server and server
– Multiplicities are used
client
<<processor>>
Caching server
Deploys
Http.exe
rting.exe
<<processor>>
server
Deploys
dbadmin.exe
tktmstr.exe
logexc.exe
console
kiosk
server
2..* 4..*
21. R
R
R
Guidelines for Deployment Diagrams
• General [Ambler 2002-2005]
– Indicate Software Components on Project-Specific
Diagrams
– Focus on Nodes and Communication Associations
on Enterprise-Level Diagrams
• Nodes and Components
– Name Nodes With Descriptive Terms
– Model Only Vital Software Components
– Apply Consistent Stereotypes to Components
– Apply Visual Stereotypes to Nodes
• Dependencies and Communication
Associations
– Indicate Communication Protocols Via
Stereotypes
– Model Only Critical Dependencies Between
As you can see in Figure 1 components are modeled as rectangles with two smaller rectangles jutting out from the left-hand side. Components realize one or more interfaces, modeled using the lollipop notation in Figure 1, and may have dependencies on other components – as you can see the Persistence component has a dependency on the Corporate DB component.
Short for Dynamic Link Library, a library of executable functions or data that can be used by a Windows application. Typically, a DLL provides one or more particular functions and a program accesses the functions by creating either a static or dynamic link to the DLL. A static link remains constant during program execution while a dynamic link is created by the program as needed. DLLs can also contain just data. DLL files usually end with the extension .dll,.exe., drv, or .fon.
A DLL can be used by several applications at the same time. Some DLLs are provided with the Windows operating system and available for any Windows application. Other DLLs are written for a particular application and are loaded with the application.
Table 1. Common Stereotypes.
Stereotype Indicates
&lt;&lt;application&gt;&gt;A “front-end” of your system, such as the collection of HTML pages and ASP/JSPs that work with them for a browser-based system or the collection of screens and controller classes for a GUI-based system.
&lt;&lt;database&gt;&gt;A hierarchical, relational, object-relational, network, or object-oriented database.
&lt;&lt;document&gt;&gt;A document. A UML standard stereotype.
&lt;&lt;executable&gt;&gt;A software component that can be executed on a node. A UML standard stereotype.&lt;&lt;file&gt;&gt;A data file. A UML standard stereotype.
&lt;&lt;infrastructure&gt;&gt;A technical component within your system such as a persistence service or an audit logger.
&lt;&lt;library&gt;&gt;An object or function library. A UML standard stereotype.
&lt;&lt;source code&gt;&gt;A source code file, such as a .java file or a .cpp file.
&lt;&lt;table&gt;&gt;A data table within a database. A UML standard stereotype
&lt;&lt;web service&gt;&gt;One or more web services.
&lt;&lt;XML DTD&gt;&gt;An XML DTD.
A node, depicted as a three-dimensional box, represents a computational unit, typically a single piece of hardware, such as a computer, network router, mainframe, sensor, or personal digital assistant (PDA). Components, depicted as rectangles with two smaller rectangles jutting out from the left-hand side (the same notation used on UML Component diagrams), represent software artifacts such as file, framework, or domain component.
2.4 Apply Visual Stereotypes to Nodes
Figure 2 depicts nodes using visual stereotypes, for example the mobile PC is shown as a laptop and the databases are shown using traditional database drum notation. There are no standards for applying visual stereotypes on UML Deployment diagrams – the general rule of thumb is to use the most appropriate clip art that you can find.
Communication associations support one or more communication protocols, each of which should be indicated by a UML stereotype. In Figure 1 you see that the HTTP, JDBC, and web services protocols are indicated using this approach. Table 1 provides a representative list of stereotypes for communication associations – your organization will want to develop its own specific standards.
Table 1. Common stereotypes for communication associations.
Stereotype Implication
AsynchronousAn asynchronous connection, perhaps via a message bus or message queue.
HTTPHyperText Transport Protocol, an Internet protocol.
JDBCJava Database Connectivity, a Java API for database access.
ODBCOpen Database Connectivity, a Microsoft API for database access.
RMIRemote Method Invocation, a Java communication protocol.
RPCCommunication via remote procedure calls.
SynchronousA synchronous connect where the senders waits for a response from the receiver.
web servicesCommunication is via Web Services protocols such as SOAP and UDDI
