 |
A
UML
2 deployment diagram depicts a
static view of the run-time configuration of processing
nodes and the components that run on those nodes. In
other words, deployment diagrams show the hardware for
your system, the software that is installed on that
hardware, and the middleware used to connect the
disparate machines to one another. You want to create a
deployment diagram for applications that are deployed to
several machines, for example a point-of-sales
application running on a thin-client network computer
which interacts with several internal servers behind
your corporate firewall or a customer service system
deployed using a web services architecture such as
Microsoft’s .NET. Deployment diagrams can also be
created to
explore the architecture of embedded systems,
showing how the hardware and software components work
together. In short, you may want to consider creating a
deployment diagram for all but the most trivial of
systems. |
|
Figure 1
presents an example of a fully rendered UML 2 deployment
diagram for the student administration application. The
three-dimensional boxes represent nodes, either software
or hardware. Physical nodes should be labeled with the
stereotype device, to indicate that it’s a
physical device such as a computer or switch. As you
can see I didn’t indicate that WebServer is a
device – it will at least be some sort of software
artifact and very well may be one or more physical
devices as well but my team hasn’t made that decision
yet. Remember, models evolve over time. Connections
between nodes are represented with simple lines, and are
assigned stereotypes such as RMI and message
bus to indicate the type of connection.
Nodes can contain other nodes or
software artifacts. The ApplicationServer node
contains EJBContainer (a software node) which in
turn contains three software components, a deployment
specification, and a software artifact. The software
components use the same notation as
component diagrams (I could have annotated them with
their interfaces although that wouldn’t have added any
value in my opinion). Deployment specifications are
basically configuration files, such as an EJB deployment
descriptor, which define how a node should operate.
They are depicted as two-sectioned rectangles with the
stereotype deployment spec, the top box indicates
the name and the bottom box lists the deployment
properties (if any) for the node. In my opinion the
deployment properties is superfluous as this is the type
of information that is contained in the actual
deployment specification file at run time. Software
artifacts are shown with the visual stereotype of a page
with a folded corner or with the textual stereotype
artifact (or both sometimes, which I also believe is
superfluous). In this case the software artifact is a
fictional persistence framework purchased from
AmbySoft (the vendor is indicated with a UML
property string).
Figure 1. UML 2 deployment
diagram for the university information system.
When you stop and think about it,
the stereotypes that I’ve applied to the connections
aren’t correct. In reality the software on the web
server is communicating via the RMI protocol over the
connection to the software on the application server.
The physical connection between the physical hardware
nodes is at a lower level, perhaps an Ethernet
connection, so in reality I really should have modeled a
connection between the hardware nodes with Ethernet
as a stereotype and a second connection between software
elements with the RMI stereotype. I’d also need
to model a dependency relationship between the software
connection and the hardware connection, perhaps with the
stereotype of over. Although this would be more
accurate it would be a lot of work that I likely
wouldn’t get much benefit from. Remember, agile models
don’t need to be perfect, they need to be
just barely good enough.
I never draw deployment diagrams
following the style show in Figure 1,
except when I’m writing about deployment modeling,
because in my opinion this notation is visually
wasteful. A better example is shown in
Figure 2. Software
elements are now simply listed by their physical
filenames, information that developers are very likely
to be interested in, and thus a more compact diagram is
possible. I’ve also used a drum as a visual stereotype
for the University DB database, making it easier
to distinguish on the diagram. Another difference is
that the concise version shows less details, not as many
tagged values are shown as this information can be
captured in either supporting documentation,
configuration files, or source code. Deployment
diagrams tend to become very large very quickly because
they reflect the physical complexities of your system,
therefore a concise notation becomes critical to your
success.
Figure 2. Concise UML 2
deployment diagram.
How agile are deployment diagrams?
As always, it depends on your goals. Very often
less-detailed
network diagrams, which are arguably deployment
diagrams with extensive use of visual stereotypes, are a
better option. This is particularly true when you are
modeling an environment consisting of a many
interconnected machines. Sometimes a high-level
free-form diagram is a better option because the
notation is much more flexible. The information
contained in Figure 2 can
just as readily be captured in either a network diagram
or a free-form diagram in combination with installation
scripts. When you think about it installation scripts
are effectively “deployment source code”.
To determine whether you need to
create a deployment model, ask yourself this: if you
knew nothing about the system and someone asked you to
install it and/or maintain and support it, would you
want a description of how the parts of the system fit
together? When I ask this question of the project teams
I work with, we almost always decide to develop some
form of deployment model. More important, practice has
shown that deployment modeling is well worth it.
Deployment models force you to think about important
deployment issues long before you must deliver the
actual system.
When determining how to model the deployment
architecture for a system, regardless of the artifacts
chosen, I will typically:
- Identify the scope of the model. Does the
diagram address how to deploy a version of a single
application or does it depict the deployment of all
systems within your organization?
- Consider fundamental technical issues.
What existing systems will yours need to
interact/integrate with? How robust does your system
need to be (will there be redundant hardware to
failover to)? What/who will need to connect to and/or
interact with your system and how will they do it (via
the Internet, exchanging data files, and so forth)?
What middleware, including the operating system and
communications approaches/protocols, will your system
use? What hardware and/or software will your users
directly interact with (PCs, network computers,
browsers, and so forth)? How do you intend to monitor
the system once it has been deployed? How secure does
the system need to be (do you need a firewall, do you
need to physically secure hardware, and so forth)?
- Identify the distribution architecture. Do
you intend to take a fat-client approach where the
business logic is contained in a desktop application
or a thin-client approach where business logic is
deployed to an application server? Will your
application have two tiers, three tiers, or more? Your
distribution architecture strategy will often be
predetermined for your application, particularly if
you are deploying your system to an existing technical
environment.
- Identify the nodes and their connections.
Your distribution strategy will define the general
type of nodes you will have, but not the exact
details. You need to make platform decisions, such as
the hardware and operating systems to be deployed,
including how the various nodes will be connected
(perhaps via RMI and a message bus as in
Figure 2).
- Distribute software to nodes. Both versions
of the deployment diagrams indicate the software that
is deployed on each node, critical information for
anyone involved in development, installation, or
operation of the system.
This artifact description is excerpted from Chapter 10 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
|
|
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
