Core AgileDraw

Premise

In information technology systems, data can be identified in two ways, in-motion or stored. Hence, models are required to either define this data's structure (e.g. entity relationship) or to show the point-to-point communication (e.g. messages sent from one program to another, one class/object to another, or one device to another).

Given this premise, the simplest form of modeling could include two shapes (circles and boxes) to depict data in motion (e.g. web browser to server) or "motionless" data (e.g. tables, classes). These shapes can be connected using simple lines to show communication or relationships between them, with minimal text to describe the shapes and lines. In summary, the bare minimum concepts should include circles, boxes, lines and text; in AgileDraw terminology, these are referred to as points, connectors and text.

Semantics

The most basic version of AgileDraw includes 3 components: points (circles, boxes), connectors (lines), and text.

Points

Shape	Depicts	When To Use It
Circle	Movement/Infinity	"Listeners" such as application servers, web server, database server, messaging servers, listener classes...
Boxes	Fixed/Rigidity	Hardware, classes, entities/tables, user interface, or just about anything.

Connectors

Lines show connections between points; these may contain arrows to depict the direction of information flow (e.g. one-way or two-way).

Lines come in two flavors, solid and dashed, as explained next.

Style	Depicts	When To Use It
Solid	Concrete, synchronous, tight association, etc.	Synchronous communication, entity-relationship, etc.
Dashed	Abstract, asynchronous, loose association, etc.	Asynchronous communication, extending abstract class, etc.

Text

Minimal text is used to describe points and connectors. This text can be defined in the language of choice. Some examples of text include: protocol (e.g. HTTP), type of data passed between points, relationships (class, entity), etc.

Examples

The following diagrams demonstrate how AgileDraw can be used to draw basic diagrams using points and connectors.

High-Level Architecture (sketch on whiteboard)

The following diagram uses AgileDraw's Core concepts (points, connectors).

Domain model

Conceptual Class Diagram

AgileDraw Extensions

This level deals with producing sophisticated and appealing models for marketing purposes or "selling" your idea. For example, there might be times when you will want to use the same diagrams in a white paper, on the web site, in presentations, proposals, in your organization's marketing collateral, or for marketing to upper management or other members of your group.

Additional Shapes

Additional shapes commonly found in the world of IT can be used to enhance the basic agile draw diagrams. These shapes include common pictures/icons such as a database drum, a file icon, a cloud, clip art (e.g. people, desktop, laptop, server, PDA, network device, etc.), desktop, server, laptop, and more. The following modified diagram illustrates this point:

Colors and Shades

Colors have psychological meanings behind them and can be used to draw out emotions (e.g. happy) and raise awareness of a certain fact (e.g. danger). Listed below is a table of colors and some meanings behind them -- these are left up to the user of this technique to decipher and use as they please; in other words, you (or your group) can come up with your own set of chosen colors to best convey their meaning amongst yourselves.

Note: these colors and emotions/meanings have been taken from a variety of websites and books (to be listed here shortly).

Color	Possible Emotions/Meanings
Red	Action, confidence, energy, power, danger, warning.
Brown	Order, convention, conservative, stable.
Orange	Endurance, energy, creativity, joy, determination, success, construction.
Gold	Wealth, prosperity.
Yellow	Wisdom, happiness, intellectual energy.
Green	Life, nature, well being.
Blue	Truth, distance.
Purple	Royalty, mystery, imagination.
White	Purity, cleanliness.
Black	Death, stability.
Gray	Security, maturity, neutrality.

The following modified diagrams shows the use of colors gray (neutrality/maturity), red (warning/security), yellow (happiness; perhaps happy users), and so on.

Using shades of colors can either draw attention or represent severity level. For example, in the following model, a lighter shade of red is used for the listener class versus the darker shade for the database -- this sort of technique could be used to illustrate that the database being hacked represents a higher risk for an organization.

Callouts

Callouts can be used to provide a note, comment or other pertinent information about a point or connection. For example, the following illustrations demonstrates how various environment host names can be provided for the points in shown here (e.g. database, messaging server, website).

Shadow

Object with shadows can draw attention to them since they appear to be floating on a surface, as demonstrated in the following diagrams.

Gradients

Gradients are typically comprised of 2 or more colors flowing from one color to another. Gradients can add "pizzazz" to diagrams, as shown in the simple gradient (blue/white) used for our application server, proxy server and messaging server. Gradients come in a variety of types (e.g. linear, radial, axial, ellipsoid, square) with linear being one of the more common ones.

Photos

Photos add a personal touch to diagrams and a sense of friendliness and lighter-weight to otherwise technical diagrams. This is demonstrated in the following diagram.

Domain Specific Icons

Special icons can be used to indicate "something" about a point or connection. These are left up to the users to figure out what works for their project -- however, it is recommended that legends be used on the model to explain what these special icons mean. For example, the following two icons could be used to indicate security and load-balancing related requirements of a certain point:

Triangle – Warning, high-risk, authentication/authorization required, etc.
Star – Favorite, heavily used, etc.

These are illustrated in the modified architecture below.

Transparency

Transparency can be used to show things behind the object the transparency is applied to. For example, in the following illustration, we can see the line running through our controller, service and persistent classes.

3D (x, y and z axis)

TBD.

Best Practices for AgileDraw

Keep it simple - limit number of fonts, colors, shadows, etc. on same diagram (see the general style guidelines at http://www.agilemodeling.com/style/general.htm )
Use text to describe connections and points. Use smaller font for less relevant information (e.g. application server vendor name) and normal/larger font for things meaningful to users and/or marketing.
Diagrams should stand alone, i.e. be self-explanatory (e.g. using legends or text)
Others taken verbatim from Comparison of Diagramming Methods, by Keith Stiern, (1999; found at: http://www.umsl.edu/~sauter/analysis/dfd/DiagrammingMethods.html)
- The context of a diagram must be clear
- Each diagram must present a view of the system that is independent of other views
- diagram's context must be fully understood by its title, title block, a reference to a larger (smaller) context, or some combination thereof.
- Time and version dependencies should also be considered. Care to waste your time writing a new program - from an old database document? A date and time stamp will resolve any confusion. If you can expect a second version to be made (almost always), a version identification will also help.
- If there will be more than one type of diagram for a system, each diagram type must be Orthogonal to all the others. Orthogonal projections show aspects of a system from perspectives that are fully independent of each other.