Designing UML Diagrams for Technical Documentation
Neil MacKinnon
IBM Toronto Software Laboratory
8200 Warden Avenue
Markham, Ontario L6G 1C7
1-905-413-5883
neilmack@ca.ibm.com
ABSTRACT
This paper presents a framework for improving the presentation of
Unified Modeling Language (UML) diagrams, as applied in
technical documentation produced at the IBM Toronto Software
Laboratory. UML diagrams are a key part of program design. They
can enhance understanding of complex programming concepts, and
assist in problem analysis and solution design. In turn, UML
diagrams can add significant value to documentation, helping the
user to understand not only the solution but also the reasons for
using that particular solution. Too often, however, UML diagrams
are created in isolation by a developer, with little or no thought as to
how they will be presented in documentation, be it online, in a PDF
file, or in a printed book. This compartmentalization does not allow
for the possibility that a diagram that was useful in the design phase
of a project will not necessarily bring value to documentation if its
stated processes or goals are unclear. Poorly designed UML
diagrams can also have a negative impact on both project scheduling
and costs. For example, production delays can arise because of
increased back-and-forth time among developers, writers, and
designers, and translation costs can escalate if a diagram contains
text that must be translated.
This paper presents a method for ensuring a collaborative process
for UML diagram design. It provides specific tasks for each of the
three key roles in developing UML diagrams for documentation:
program developer, technical writer, and graphic designer. It makes
the program developer aware of design principles that might
otherwise be overlooked. It shows the technical writer ways to
improve the design of the diagram, and offers a method for
converting files to a common format that can then be utilized by the
graphic designer. Finally, it provides the graphic designer with a
methodology for quickly producing a clear, error-free final image
that is manageable in size. By following the guidelines presented
here, developers, writers, and designers can work together to
produce clean, concise UML diagrams that will bring value and
clarity to technical information. This clearly defined process will
help eliminate miscommunication, shorten development schedules,
and reduce production and translation costs.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
SIGDOC’03, October 12-15, 2003, San Francisco, California, USA.
Copyright 2003 ACM 1-58113-696-X/03/0010...$5.00.
105
Steve Murphy
IBM Toronto Software Laboratory
8200 Warden Avenue
Markham, Ontario L6G 1C7
1-905-413-3863
srmurphy@ca.ibm.com
Categories & Subject Descriptors: H.5.2
[Information Interfaces and Presentation]: User Interfaces –
Screen design; Standardization; Style guides; Theory and
methods; Training, help, and documentation
General Terms: Design, Documentation, Human Factors,
Standardization
Keywords: Unified Modeling Language, documentation,
graphic design, human factors, visualization, UML diagrams,
guidelines
1. INTRODUCTION
UML diagrams are modeled representations of real-world ideas.
(See Fowler [1]). For program designers, architects, and
developers, UML diagrams are an important tool in the process of
creating well-crafted, useful software. Used properly, the same
UML diagrams that enhance the design and development process
can add value to technical documentation, helping the user to
organize, visualize, and understand complex programming
concepts and business processes. Too often, however, UML
diagrams are not created with documentation in mind.
Diagramming techniques that might work for a developer trying to
explain technical details to fellow developers are not necessarily
appropriate when used for diagrams that will appear in
documentation intended for a much wider audience. Poorly
designed UML diagrams often detract from a technical document,
cluttering the text, confusing the user, and making the document
file size large and unwieldy.
For UML diagrams that will appear in IBM technical
documentation, a collaborative process is required, one that is
designed to assist developers, writers, and graphic designers in
creating clear, concise, and useful UML diagrams that add rather
than detract value from technical documentation. This
collaborative process, tested at the IBM Toronto Lab, consists of a
series of steps for each of those three roles, acting as a quality
assurance checklist for development teams. This series of simple
tasks can ultimately save overhead costs for teams by reducing the
time and resources required to produce quality UML diagrams. By
implementing this simple process, developers and writers can
eliminate much of the “back-and-forth” time spent discussing
their respective requirements with each other and with their
graphic design department. The process outlined in this paper
ensures that all members of the team are working towards the
same goals of clarity, simplicity, and usability in their UML
diagrams. By minimizing the role of the graphic designer, teams
can also reduce the risk of errors being introduced to their UML
diagrams, since the designers will not have to manually re-create
the same diagram in a different format. Instead, graphic designers
will simply convert the diagrams to the desired format using an
automated process, saving time, and minimizing errors.
2. BENEFITS OF A COLLABORATIVE
PROCESS
Most companies, large and small, have numerous guidelines,
rules, house styles, and processes in place that govern the
production of documentation, including graphics. IBM is no
exception. These varied guidelines and processes are designed to
aid the stakeholders in creating accurate, consistent
documentation that brings value to the customer while building
efficiency into the development process. Similarly, the UML
diagram process outlined here, created by the IBM Toronto Lab
UML Diagram Workgroup (involving technical writers, editors,
and graphic designers), improves accuracy, increases efficiency,
and reduces costs. In order to gain the support and “buy-in” of the
various developers, writers, graphic designers, and editors who
will be responsible for implementing the UML diagram process, it
is important that they understand the specific benefits that can be
realized.
2.1 Background
Lack of a uniform style for presenting UML diagrams in technical
documentation was an emerging problem at the IBM Toronto Lab.
The graphic design team was finding it increasingly difficult to
apply appropriate layout and style guidelines. Also, graphic
designers were receiving diagram submissions that had to be fully
re-created, since the submitted file format was not optimal for
inclusion in IBM’s technical documentation.
The graphic design team recognized these problems and engaged
the larger information development community at the IBM
Toronto Lab in an effort to find a solution. The resulting
workgroup needed to find a way to limit the size of individual
diagrams and also reduce the number of submitted diagrams. The
workgroup set out to establish best practices for visually
organizing diagrams, choosing the most appropriate file format,
and reducing translation costs.
As in most organizations, the technical writers in the group were
used to working closely with developers to produce
documentation. (For a discussion of writer/developer teaming, see
Wong [2].) The technical writers provided further information on
UML diagram issues from their interaction with developers and
translation centers. They also detailed issues encountered when
inserting diagrams using the IBM proprietary documentation tool.
In some cases, the writers conducted user testing in coordination
with the Lab’s human factors team to establish ease-of-use
parameters.
The editors ensured that the newly-established process conformed
to IBM house style and IBM terminology guidelines, and that the
Web site containing the new process was easy to use and
understand. The editor was also responsible for performing
consistency checks and gathering user feedback after the guideline
was posted.
106
The combined efforts of the various stakeholders resulted in a
holistic solution to the process of creating UML diagrams. With
this solution, each team utilizes their respective expertise together
in a collaborative process. The greater IBM Toronto Lab
community tested each stage of the process.
2.2 Goals
Without a well-defined process for creating UML diagrams,
images such as the one in Figure 1 can conceivably be submitted
for publication. (Note: This example is based on an actual
diagram submission received by the authors).
Obviously, this diagram is a confusing, oversized jumble of
classes, associations, and multiplicities. Its sheer size makes it
impractical for publication, but even if it could somehow be
scaled to an appropriate size for Web or print delivery, its
complete lack of organized design would render it unusable. This
diagram is an extreme example of what an established
collaborative process can help eliminate.
A collaborative process for UML diagram design can provide the
following benefits to an organization, each of which can have a
positive effect on the bottom line through greater efficiency or
increased customer goodwill:
• Smaller viewable image
• Clearer concepts
• Shorter production schedules
• Reduced translation costs
• Smaller file size
2.2.1 Smaller viewable image
UML diagrams are useful in technical documentation only if they
can be easily understood. If a diagram is too large, it can be rendered
unreadable when scaled for inclusion in a PDF document. Similarly,
a large diagram is less useful when viewed on screen because the
user must scroll to view the entire diagram and cannot see the entire
diagram at one time. Well-designed UML diagrams are scalable
because their content is focused and manageable.
2.2.2 Clearer concepts
The primary goal of technical documentation is to promote
understanding. Diagrams can enhance a reader’s understanding,
but only if they are easy for the reader to absorb. Cluttered images
make the reader work harder to understand a concept, making it
more difficult for the document to achieve its goal. A clean, well-
designed UML diagram is simply easier for the user to follow than
a disorganized collection of boxes and arrows.
2.2.3 Shorter production schedules
From clutter springs confusion. A messy, disorganized diagram
can be not only difficult for the user to decipher but also
confusing for the development team to review, which can slow
down the production process. Clear diagrams mean less back-and-
forth time between developer and writer, time that every writer
will find valuable as deadlines draw near.
 Figure 1: Unwieldy UML diagram
2.2.4 Reduced translation costs
Many companies, especially multinational organizations and
companies that sell to overseas markets, produce translated
versions of their documentation. Depending on the number of
languages required, translation costs can make up a substantial
portion of the overall documentation budget. Companies can
recognize significant savings by reducing the amount of text that
must be translated in UML diagrams.
Translation is a costly and time-consuming process. Any UML
diagram that includes English headings or notation must be re-
created for each language to which the document is being
translated. If the diagram must be re-created in 10 other
107
languages, costs and delays will escalate rapidly. Figure 2 shows
an example of a diagram that must be sent for translation simply
because it contains a note that includes one line of translatable
text (that is, “Remote Reference (EJB)”).
Writers and developers must create their UML diagrams with the
goal of eliminating the need to re-create the diagram for each
translated version. In particular, class diagrams and sequence
diagrams can be created using little or no translatable English
because program names can be used throughout. (Use cases, on
the other hand, model interactions between the user and the
computer system and therefore usually require English terms.)

Figure 2: Diagram containing one line of translatable text
2.2.5 Smaller file size
Large diagrams can increase document file size exponentially.
Larger file sizes can mean longer wait times for users attempting
to view documents online or download document files. This
“annoyance factor” should not be underestimated, especially if a
customer is using an older system. Smaller, more concise UML
diagrams can reduce wait times and inconvenience for customers,
which can improve customer satisfaction ratings for the company
that implements this process. As any marketer will attest, working
towards reducing any amount of customer dissatisfaction is a
prudent investment of effort.
3. PROCESS
There are numerous scenarios that might result in the inclusion of
a UML diagram in a particular technical document. A diagram can
be created specifically to enhance the documentation, or the
developer might wish to include an existing diagram that was used
during the product’s design phase. A particularly complex concept
might take pages of explanatory text, yet be crystallized in a
reader’s mind by the timely inclusion of a UML diagram.
The suggestion to include a UML diagram is usually made by
either the developer or the writer, when either one believes that
such a diagram would help illustrate a concept for the user, or
when UML modeling is a required element of the process being
documented. Different types of UML diagrams can be created and
included in documentation depending on the concepts being
discussed; these diagram types include class, sequence, use case,
activity, state, package, and deployment.
To create a UML diagram according to the collaborative process
described here, production teams must first determine the type of
UML diagram that is required for the document in question. Once
the type of diagram has been agreed on, the team can complete the
108
specific steps for creating the diagram that correspond to the three
roles described in the process: developer, writer, and graphic
designer.
3.1.1 Summary
Following is a brief summary of the responsibilities for each role
in creating a UML diagram:
• Developer:
1. Determines or confirms that a UML diagram is
required.
2. Creates the UML diagram according to these
guidelines.
3. Forwards the diagram file to the writer.
• Writer:
1. Determines or confirms that a UML diagram is
required.
2. Ensures that the UML diagram has been created
according to the established guidelines.
3. Converts the diagram file to the appropriate format
(if necessary).
4. Forwards the diagram file and hard copy to the
graphic designer.
• Graphic designer:
1. Converts the submitted diagram file to the required
format (normally GIF or EPS) according to these
guidelines.
2. Compares the converted file to the hard copy,
correcting any errors.
3. Returns the converted file to the writer.
It is important not to underestimate the time required to complete
the tasks in the UML diagram process. Although this process
ultimately increases efficiency and reduces time commitment, it
also requires that each task in the process be understood and
carefully completed. The process should take place concurrently
with documentation development because changes resulting from
the series of steps will take time to implement. If left to the end of
the development cycle, steps might be overlooked or purposely
ignored, ultimately defeating the process’s goals and depriving
organizations of its benefits.
4. SCENARIO: CREATING A CLASS
DIAGRAM
In the following scenario, a class diagram (Figure 3) is required
for inclusion in a technical document. A class diagram describes
the types of objects in a particular system and the various kinds of
static relationships that exist between those objects. Class
diagrams also show the attributes and operations of a class and the
constraints that apply to the way objects are connected. Class
diagrams are among the most commonly used UML diagrams in
the technical documentation produced at the IBM Toronto Lab.
 Figure 3: Class diagram created with no visual design principles applied
The scenario shows how the collaborative UML diagram process
can be put into action. It details the tasks and responsibilities of
the three different roles:
• Developer
• Writer
• Graphic designer
This scenario assumes not only that the document calls for a class
diagram, but also that Rational Rose is the program being used to
create the diagram. (For an in-depth description of visual
modeling using Rational Rose, see Quatrani [3].) Organizations
can adapt this scenario to their own requirements and tools. The
examples provided in the scenario are based on actual diagram
submissions encountered by the authors.
4.1 Developer
The developer is often the person with the most UML expertise of
the three principals. As such, developers can easily and
understandably make the error of assuming that the writer and the
graphic designer – and by extension, the reader – will possess the
same level of understanding and expertise. It is at this point, the
very beginning of the process of creating the UML diagram, that
the collaborative process must be engaged. A basic set of
documentation and design principles must be understood by the
developer before work on the diagram is begun. Like the writer
109
and graphic designer, the developer should create or revise the
diagram with the understanding that it will appear in a technical
document, and should therefore be produced according to both
programming and design principles. Specifically, the developer
must consider the following guidelines:
• Clarify the topic
• Consider all diagram options
• Create the diagram according to visual design principles
4.1.1 Clarify the topic
Upon establishing the need for the UML diagram (in this instance,
a class diagram), the developer must determine what specific
topics are being illustrated. Experienced writers will immediately
realize that this task is not as easy as it sounds. For developers
new to this process, more often seems better; instinct can lead
them to include far more information in a diagram than is
absolutely necessary to illustrate a particular concept or topic.
Instead, the developer should break down the concepts under
discussion, much as a project is broken down into its component
tasks. For example, if a particular association is being illustrated,
a developer must isolate that association, leaving “big picture”
information or related associations to another section of the
document.
4.1.2 Consider all diagram options
A class diagram, or any other UML diagram, might not be the best
choice for illustrating a particular concept. If, for example, a high-
level programming concept encompasses numerous classes,
associations, and relationships, it is possible that a package
diagram might be more appropriate. Consider both the intent of
the diagram and the expertise of the audience.
4.1.3 Create the diagram according to visual design
principles
Visual design principles can make the difference between a useful
diagram and one that is confusing, cluttered, and unwieldy.
Numerous studies and texts illustrate the value of careful visual
design. (See Moore [4], Craig (ed.) [5], Bringhurst [6].) There are
also practical guidelines for improving the readability of technical
diagrams. (See Koning [7].) A developer will not necessarily be as
familiar as a graphic designer with these visual design principles.
Figure 3 shows an example of a UML diagram that was created
without regard to spacing or design principles.
The following checklist provides ways to make a class diagram
more organized, concise, and visually appealing:
a. Eliminate any unnecessary captions or comments. This
is especially important if the document is to be
translated. If text other than “hard-coded” names is
included in the diagram, part or all of the diagram must
be re-created in each language into which it is being
translated, increasing production time and costs.
Note: If developers must include commentary for their
diagram, they should use a mark to indicate a comment,
and then include the text of the comment below the
diagram. No mark can be used that has a particular
meaning in UML diagrams (for example, the asterisk,
“*”). The following symbols can safely be used to
denote a comment in a UML diagram:
boxes that are aligned both horizontally and vertically
more easily than those with no distinguishable axis.
Similarly, connecting lines can become confusing if
they intersect with other connecting lines. A well-
designed diagram should contain very few line
intersections, if any.
f. After aligning the boxes, eliminate unnecessary white
space by ensuring that boxes of equal weight
(“siblings”) are parallel whenever possible. As well as
reducing the size of the image, this alignment again
improves the usability of the diagram because a user is
more likely to understand the logic of a diagram that
contains classes grouped with other classes containing
similar features or functions.
g. Use right angles in connecting lines whenever possible,
and minimize the length of those connecting lines to
further reduce white space. The Toronto Lab graphic
design team observed that right-angled lines connecting
two or more classes are easier to interpret than diagonal
connecting lines, especially in the case of the more
complex diagrams. The lines between classes should be
no longer than is necessary to convey the relationship
and to include related information (for example,
cardinality). Long connecting lines are one of the most
common reasons for large images, and also one of the
easiest to correct
h. After completing the previous seven steps, go back and
repeat them. Corrections or revisions made in later steps
might result in the chance to re-apply earlier steps.
Review and apply the principles of the visual design
checklist until no further revisions can be made.

†, ‡, , , , , . , , .

b. Show only those operations for each class that are

crucial to the concept being illustrated, and suppress all
other non-essential operations. This will enable the
developer to minimize the size of boxes, and reduce the
overall size of the diagram.
c. Eliminate any blank space that might appear in boxes
that represent the various classes in the diagram. Blank
space does nothing to enhance the diagram, and simply
increases the size of the image area and the file.
d. Remove any unnecessary package information
contained in the class diagram. It is a common error to
include more information than is necessary for a
particular class, relationship, or association. Package
information should be confined to high-level package
diagrams.
e. Align boxes to minimize the width of the diagram as a
whole, and to minimize the number of intersecting lines. Figure 4: Diagram designed according to new process
This basic design principle is often overlooked by
developers, who tend to focus on the content of the
diagram rather than on the layout. Users can interpret

110
After these visual design principles are applied, the diagram will
be smaller, more concise, and easier for the user to follow.
Compare Figure 4 with the original diagram.
These same principles apply if an existing class diagram is
included in the documentation, rather than an original diagram.
Ensure that it adheres to each of the parameters listed above, even
if it means substantially re-creating the diagram. The goal is to
provide the user with the specific information required at that
point in the document, and only that information. This will often
mean cutting much of the content of a design-phase diagram, but
again, the requirements of the document are the overriding
concern.
After making any necessary adjustments within Rational Rose,
save the MDL file to a local hard drive and forward a copy to the
technical writer.
4.2 Writer
The technical writer acts as a quality assurance checkpoint for the
developer, and as an editor to remove unnecessary information,
and then conducts another series of quality checks that
complements the developer’s work. As well as ensuring that the
class diagram meets design requirements, the writer must also
ensure that the file is saved in the appropriate format prior to
forwarding it to the graphic designer. To ensure the appropriate
diagram design and file format, the writer must complete the
following steps:
• Confirm that the diagram is necessary
• Determine the appropriate diagram type
• Reduce diagram complexity
• Edit the diagram
• Convert the MDL file to an appropriate format
4.2.1 Confirm that the diagram is necessary
The technical writer acts as the user’s advocate in the UML
diagram design. The writer must suggest or confirm the usefulness
of the diagram and ensure that it does indeed enhance the
document. Usefulness can be determined by asking the following
questions:
a. Can text convey any of the information equally
well or better than the diagram?
b. Does the diagram enhance the explanation of the
concept being discussed, or merely replicate the
description provided in the text?
4.2.2 Determine the appropriate diagram type
The writer is usually more familiar than the developer with
the entire technical document. This sense of context can help
the writer determine if the particular context calls for a class
diagram, another UML diagram, or even a high-level concept
diagram. The writer should work with both the developer and
the graphic designer to clarify purpose and examine graphic
options.
111
4.2.3 Reduce diagram complexity
The writer can objectively determine whether the diagram is
overly large or complex. If the developer has included more
information than is necessary to explain the particular concept, the
writer must look for ways to trim the superfluous information. The
diagram should only illustrate the specific concept being
discussed, and should do so concisely. It is also the writer’s
responsibility to ensure that the developer has adhered to the
visual design standards and the developer’s class diagram steps by
asking the following questions:
a. Can any white space within the diagram be eliminated?
b. Are connecting lines between diagram boxes
unnecessarily long?
c. Are any boxes within the diagram unnecessarily large?
d. Can any boxes be combined?
e. Is the diagram presented within a grid pattern, with
boxes aligned horizontally and along margins?
f. Does the diagram contain any translatable caption or
legend that can be moved outside the image?
4.2.4 Edit the diagram
The writer must check the diagram for accuracy and consistency
standards (for example, capitalization, highlighting, spelling), and
ensure that it conforms to the organization’s in-house style and
standards, and intellectual property guidelines. (Note: Some
organizations, especially larger ones, may employ technical
editors to review documentation; however, the writer should
generally act as a first-line editor in this instance because it is the
writer’s responsibility to coordinate with and educate the
developer regarding the UML design process.)
4.2.5 Convert the MDL file to an appropriate format
The model MDL file produced by Rational Rose® is not a file
type that can be manipulated easily by graphic designers. The
writer must ensure that the MDL file produced by Rational Rose
is converted to an appropriate format for the graphic designer to
work with. Using a free program called RoseGraph
(http://www.rationalrose.com/addins/rosegraph.htm), the writer
can convert the MDL image to a common image format
(Microsoft® Windows® Metafile format—WMF) that can be
utilized by the graphic designer.
If the writer does not have a copy of RoseGraph installed, Adobe
Acrobat Distiller can be used to convert the MDL file to PDF
files, which can then be converted by the graphic designer to GIF
or EPS files. (Note: Writing teams might enlist one member to
generate PDF files for the rest of the team.)
The writer will then forward the PDF or WMF file, as well as a
print copy of the original MDL file, to the graphic designer for
conversion to EPS or GIF files, as required. (The graphic designer
requires the print copy of the diagram for proofreading purposes.)
Writers should be aware that there can be instances of text overlap
and line and arrowhead style changes introduced to the converted
diagram because a vector image’s information is not always
parsed correctly when converting from Rational Rose’s MDL file
format to Adobe’s PDF file format.
4.3 Graphic Designer
The graphic designer is responsible for converting the submitted
WMF or PDF file to an appropriate graphics file format to be used
for documentation. Although the graphic designer will likely
possess the most expertise regarding images and visual design of
the three roles, the process is aimed at minimizing the graphic
designer’s involvement at this point in the development cycle as
much as possible so that production schedules, and subsequently,
costs, don’t increase. That is why it was crucial for the graphic
designer to provide visual design instructions that could
subsequently be referenced by developers and writers. However,
the graphic designer should certainly suggest improvements if the
diagram does not conform to one or more of the design principles
outlined above.
4.3.1 Convert the submitted file to GIF or EPS
format (if required)
If the writer has submitted a PDF or WMF file for conversion, the
graphic designer should convert it to a production-ready format.
The graphic designer must complete the following steps:
a. Ensure that a PDF or WMF file has been received from
the writer, as well as a printed copy of the UML
diagram.
b. Open the PDF or WMF file in Adobe Illustrator or
another graphics tool and correct any parsing errors.
Note: A vector image’s information is not always parsed
correctly when converting from Rational Rose’s MDL
file format to Adobe’s PDF format. Graphic designers
should be aware that there could be instances of text
overlap and line and arrowhead style changes
introduced to the converted diagram. See Figure 5.
Figure 5: Diagram with parsing errors
c. Delete any footer information at the bottom of the
diagram (which appears only in PDF files), and then
save the changes.
d. Export the image to GIF or EPS format.
e. Proofread the converted file, comparing it with the
printed copy of the class diagram that was forwarded by
the writer. Correct any errors.
f. Return the converted file to the writer within the stated
time period.
112
5. CONCLUSION
Many of the steps and guidelines presented in this paper might
seem self-evident: aligning boxes, drawing straight lines, reducing
white space – all might seem like obvious steps in producing
UML diagrams. To some developers, these steps are obvious. To
many writers they are obvious as well. All too often, however,
there is at least one weak link in the chain of diagram
development, one point where design principles fall by the
wayside, one person who overlooks what might seem obvious to
someone else. This UML diagram process establishes a protocol
to be followed so that none of the principal roles is left to work in
isolation. The checklist of steps ensures that what is understood
by one member of the team is understood by all. By implementing
these simple guidelines, organizations can achieve surprising
results: improved customer satisfaction, shortened production
schedules, and reduced costs.
6. REFERENCES
[1] Fowler, M. & Scott, K. (1997). UML Distilled: Applying the
Standard Modeling Language. Addison-Wesley, Reading,
Massachusetts.
[2] Wong, K. & Tilley, S. Connecting technical communicators
with technical developers. Proceedings of the 20th Annual
International Conference on Documentation, SIGDOC, 2002,
pp 258-262.
[3] Quatrani, T. (1998). Visual Modeling with Rational Rose
and UML. Addison-Wesley, Reading, Massachusetts.
[4] Moore, P. & Fitz, C. Gestalt: Theory and instructional
design. Journal of Technical Writing and Communication,
1993.
[5] Craig, J., Bevington, W., Meyer, S., editors. (1999).
Designing with Type: A Basic Course in Typography,
Watson-Guptill Publications.
[6] Bringhurst, R. (1992). The Elements of Typographic Style.
Hartley & Marks, Washington.
[7] Koning, H., Dormann, C., van Vilet, H. Practical Guidelines
for the Readability of IT-architecture Diagrams. Proceedings
of the 20th Annual International Conference on
Documentation, SIGDOC, 2002, pp 90-93.
7. TRADEMARKS
IBM and WebSphere are registered trademarks of International
Business Machines Corporation in the United States, other
countries, or both.
Rational and Rational Rose are registered trademarks of
International Business Machines Corporation and Rational
Software Corporation, in the United States, other countries, or
both.
Microsoft and Windows are registered trademarks of Microsoft
Corporation in the United States, other countries, or both.
Other company, product, and service names may be trademarks or
service marks of others.