Common Visio Software Diagrams
Common Visio Software Diagrams
Now that we've had a quick look around the Visio environment, we're ready to tackle some of the interesting software-oriented diagram templates shipped with Visio. There are many basic
For our purposes in this chapter, we'll be focusing on a set of Software diagrams that includes the following templates:
We'll also take a look at the following template from the set of Database diagrams:
In the Chapter 8. Now, however, let's take each of the above diagram templates one at a time and describe the basics of creating diagrams of each type.
Creating COM and OLE Diagrams
Windows developers will probably grasp the intent of a COM and OLE diagram immediately. The purpose of such a diagram is to illustrate the relationship or interaction of a
If you surmised that this is a simple representation of an application that works with customer and order data you are correct. Each of the two boxes represents a boundary of some sort. The thicker line between them represents a process boundary. On one side of the process boundary in a component of some
The shape itself is easy to use. It literally is a series of smaller, rectangular shapes grouped together. Each rectangle represents a function or method supported by the interface. When you drag the shape onto the drawing page, you'll be prompted to specify how many rows you wanl in the Vtable .
If, as in this screenshot, you select 4 (the maximum is 16), Visio will draw a Vtable shape consisting of four rectangles grouped together. You can then click on each region inside the Vtable and add your method details.
It is possible, of course, for an object to have many interfaces. Visio makes creating such an object easy. After dragging a
shape onto the drawing page, new interfaces can be added by dragging the
shape onto the drawing. If you drag the tail of the
shape over top of the
, the two will connect
object that gets used by various business
The Order object in this diagram is most likely implemented within one physical component and the Payments object is probably implemented in another component. Although the Boundary shape doesn't contain implementation details, it does make clear the separation between the Order and Payment objects.
There are several benefits to these kinds of diagrams:
Creating Data Flow Diagrams
Data Flow diagrams are used to illustrate the flow of data from one process to another. They don't really offer much detail about particular processes like running a credit check or creating an inventory record; rather they are good at making the flow of data through a
DFD's consist of processes, data stores, and the flows of data between them. Processes are any activity that transforms data. Data stores are any place information resulting from a process transformation can be stored. Data flows are a notation illustrating the movement, or flow, of data from a data store to a process.
Let's have a look at an example first, and then dig into the details of how the diagram is constructed. Consider a simple order processing system for an online merchant. To properly create and fill orders there's quite a bit of information that has to be gathered, recalled from, or written to a database. We won't cover the entire process from beginning to end, of course, but it will serve as a decent example for our DFD discussion. The steps in an order entry application might be listed as
The diagram depicting this series is steps are rather simple.
Notice how data flows from the shape representing the Customer into the Process Order step. Data flows from the Products and Customers data stores for looking up product and customer details. The primary flow of data out of Process Order is into the Orders data store - a new order is created. Each of the shapes used in a DFD is rather simple. Let's have a look at the four shapes.
There are some rules
Notice the new
Process Credit Card
shape near the bottom of the diagram. On your screen, the
Process Credit Card[Process]:A process must export data via a data flow.
Any other error you might generate by violating DFD rules will always be written to the Output window.
Let's cover one last point regarding the DFD before we move on. In the screenshot above, there's a new
Creating Enterprise Applications
Sometimes it is necessary to describe how an application will be implemented or deployed and give some indication of the types of machines that will either host application server components or run client components. The Enterprise Application diagram template was designed with this scenario in mind. Distributed applications with complicated and varied deployment platforms are good candidates for Enterprise Application diagrams.
The diagram itself is built from a template consisting of a series of shapes designed to look like hardware you might encounter in many larger applications - mainframes, servers, workstations, laptops, among others. The diagram also contains a few shapes we've already seen like the Boundary and Interface from the COM and OLE diagram. Enterprise Application diagrams get their complexity from the scope of the applications they are illustrating. The building blocks of the diagram itself are very simple. For that reason we'll take an example and discuss its construction rather than taking each shape one at a time.
Consider a distributed application designed to support a mobile sales staff. Sales personnel will be working from the road placing orders, looking up product data, and checking on shipping status for various customers. This type of application is very common in larger manufacturing companies. If we include the mobile sales staff, represented by laptops and an internal group of users represented by workstations, we can illustrate how this application will be deployed and the various platforms it requires.
Notice that the level of detail pertaining to each platform or group isn't high. We can, however, take away from this diagram an understanding of the types of machines involved in this application and their relationships to one another. Of course, there are many important pieces of information missing, like communication protocols, but that isn't the intent of Enterprise Application diagrams. You could always add that level of detail, but the primary purpose of this diagram is to communicate the big picture.
Windows Interface Diagrams
One of the more interesting diagram templates shipped with Visio is the Windows Interface Diagram. The purpose of this diagram is to prototype Windows interfaces before development. During the early stages of most development projects, it's very useful to present UI designs to user groups for feedback. Not only does UI prototype generate good feedback on UI layout and usability, but the process also forces users to think about their needs in terms that are more realistic. Instead of some abstract idea of what an application might look like when the software is finally delivered, users armed with prototype UI layouts will have thought through how they intend to use the software and hopefully have identified problem areas and made suggestions for improvements.
Some developers use VB itself for laying out sample Windows forms. It
OK, hopefully the case is made for prototyping your UI designs. So how do we do it? The Windows UI template included with Visio contains just about any UI control you can think of for building interface prototypes. Sticking with the pattern of showing an example and breaking it down, here's what a UI prototype development in Visio might look like:
After just a few minutes of working with the Windows UI template in Visio, we can produce a simple Windows form, professional enough to include in documentation sent to
Having seen a simple example, let's have a look at some of the UI diagram shape in more detail. We won't cover them all, of course, just the most common and more interesting shapes. Let's consider the simple Windows Form shape first.
Windows Form Shape
If you are working on designing dialog boxes, the Form shape is probably where you'll start with each form you layout. Although it's not necessary to place all UI controls into a Form shape container like our first example above, doing so helps create a realistic look and feel for your prototypes. To create a simple Windows form, start Visio and select File New Software Windows User Interface . Your Visio application will look like this - notice the large group of shapes in the stencil that is added to your new drawing.
Now, grab the Blank Form shape (first row on the Windows User Interface stencil, third column) and drag it onto the drawing page. You'll get a Windows form with an editable caption - it says Enter Title Here by default. Double-click on the caption area of the form and type Sample Windows Form . You should then have a form that looks like this:
Now that you have a form going, you can add all kinds of UI controls to the form. There are, however, a few controls that you might want to pay attention to that are common to most Windows forms - form
A very common UI control you'll likely find on a Windows form is a button to minimize, maximize, or close the form. The standard buttons on the upper right of many forms. Visio let's you drag a Windows button onto the drawing page and select which type of button it represents - Restore , Minimize , Maximize , Close , or Help . Let's add a Close and a Help button to the sample that we just started creating. From the stencil, find the shape labeled Windows buttons . Click and drag that shape onto the drawing page. Try to drag the shape onto the upper right corner of the Form shape so that the connector turns red, indicating the button will be docked onto the Form shape. When you release the dragged shape, you'll see this dialog:
If you want a Close button, as we do now, just press OK and Visio will create a new Windows button with a small X : ( ). Now, create another Windows button to represent Help . Drag the Windows buttons shape back onto the existing form and try to arrange it close to our Close button - they will dock together. When the Custom Properties box appears this time, select the Help button type. If all goes well, you'll have a form resembling this screenshot:
Other common Form-
Now let's add some
fields across the bottom. These
You can resize the Status field controls to be as wide or as narrow as you like, depending on your application's needs.
So, we've got some of the basics of building a Windows form done, but how about adding some more exciting UI controls? The template in Visio supports quite a few commonly used UI controls that we'll probably be using in our applications:
Let's start with the Menu controls and their Visio shapes.
diagram in Visio, standard Windows
In the stencil for this drawing in the second row, first column, is a shape that represents a Windows menu. It's really just a long, resizable rectangle shaded to match the standard Windows form color. Click and drag the Menu shape onto the sample form and try to dock it near the top of the form, below the title bar. The upper left and right corner of the form (not the title bar) supports docking so if you get one end or the other of the Menu shape close, you'll see a connection point turn red when it's lined up enough to be docked. Depending on how wide your form is, you may have to shorten the length of your Menu shape. If all goes well, you'll have a form with an empty menu.
To add top-level menu items, find the shape in the stencil labeled
Top-level menu item
. These are
Add a few more top-level menu items and you've got a good looking Windows form complete with many common
If you are interested in illustrating some of the menu items themselves (what you see when the menu is expanded when you click on the top-level menu item), locate the Drop-down menu item shape on the stencil (next to the Top-level menu item shape). Drag that shape immediately below the File top-level menu item already on the form. Since the first menu item on the File menu is commonly New , click on the Drop-down menu item and type the word New. Add a new Drop-down menu item shape below the New menu item and label it Open. Add others for Save , Save As... and Exit . You'll now have a form that looks like this:
Interestingly the Drop-down menu item isn't resizable the way the Top-level menu item shape is, but the drop-down items do have some properties that may be useful. Right-click on any of the drop-down items you just added and select Menu Item Properties . You'll see a dialog like this:
The Menu Item Style dropdown contains several values that might be useful depending on how much detail you need in your menu items. The values include:
Another common UI control that's useful to diagram before building is a Tab control. Fortunately, the UI template in Visio supports prototyping tab controls also. In fact, it's the first control listed in the stencil. To build a Tab control, drag the Tab shape onto the drawing page. At this point, we're still using the Sample Windows Form we've been building up to this point. The Drop-down menu shapes have been removed to free up some room on the form itself. When you've dropped the Tab control you can resize it to be somewhat centered on the form. Now, click on the Tab Control and type it's name - we'll use Main for our example.
If your tab control consists of more tabs, you can drag the shape labeled
and dock it immediately to the right of the
tab you just created - name it
Notice that the
tab is slightly lower than the
tab. That's how Visio indicates which tab is active. If you right-click on the
tab you can select
Move Tab to Top
. Both tabs will be the same
The last item we'll discuss in this section is the Wizard control that the Visio Windows Interface stencil supports. Clearly there are more UI controls available in the template, but most of them, such as text boxes or radio buttons, are familiar to most developers already in terms of their usage and placement.
The Wizard UI shape is incredibly useful. We've all used wizards at one time or another in Windows, and it's likely most of us have built them as well. So we all know that a wizard is generally multi-step process controlled by three buttons - Back , Next , and Cancel . Some kind of content for data entry or other purposes is displayed in the body of the wizard form. As you move through the wizard, the Next buttons takes you to a following page, while the Back button takes you to a previous page, and the Cancel button exits the wizard. Building a good wizard isn't exactly simple, so working out the details of what data is displayed on which pages of the wizard is a good idea. Let's have a look at a hypothetical wizard UI.
For starters, drag the Wizard UI ( Simple ) onto the drawing page. You see the shell of a standard Wizard UI with three main regions. There's one on the left of the form shaded green used to display information or graphics that generally don't change with each Back or Next button click; a main working area that contains text and other UI controls that change with each Back and Next button click; and an area for buttons on the lower left of the form. You can add text to either of the regions above the buttons by clicking on the region and typing. It does take some trial and error, though, to get the right region. The Wizard UI shape itself is actually a grouping of several other shapes so you'll probably have to experiment to get it right. We can add some text to the regions by first selecting the Text tool from the standard toolbar:
Now if we add some text to both regions, it can look like this:
Of course, you can also drag any shapes onto the Wizard UI you find necessary.
Since the buttons at the bottom of the form are so important for controlling the behavior of the wizard, the Visio template comes with some extra functionality for controlling how the buttons are drawn. In the course of running the Wizard both the Back and Next buttons may or may not be enabled. For instance when a user is on the first step in the wizard, there's no point in enabling the Back button - there's nowhere to go. To disable the Back button, right click on it and select Disable Button. The button will be displayed on the form as if it was a disabled Windows application button. The same can be done to the Next and Cancel buttons.
We also have the ability to set the default button on the wizard form. In Windows, a
Creating Database Model Diagrams
The last Visio diagram we'll review in this chapter is the one I've
Visio can build database model diagrams from scratch or it can reverse engineer an existing database model and produce a diagram after the database has already been created. As a design tool, it's very useful; as a documentation tool, it's also very useful. Let's have a look at building a simple data model, then we'll run through reverse engineering an existing SQL Server database.
Creating a Simple Data Model
Let's build a simple data model used to track customers and their orders for a hypothetical web application. The
Here's a listing of the tables and their contents:
It's a simple data model that is somewhat normalized. That's not the focus of this section so I won't make any normalization comments, other than this one: Price is
Let's start with a
In the stencil, there are really just two main working shapes in this template - Entity and Relationship . The others aren't unimportant, but these two do most of the work. The Entity shape represents tables. To create a new table in the diagram, drag the Entity shape onto the drawing page. By default, Visio will display the new table and populate a docked Window underneath the drawing page with table information. If you don't see a Database Properties window near the bottom of the Visio form, right-click on the Entity shape you just created and select Database Properties . You should see something similar to the following screenshot (notice the page zoom setting has also changed here):
In the Database Properties Window, we can adjust quite a few properties of this table. Calling the Window Database Properties is a little misleading. We are actually looking at the properties of a single table. Notice the list of categories in the listbox on the right. As you click on Categories , the remaining region to the right of the window will change.
Let's start by naming the table
. To add fields click on the
You can add fields by typing directly into the grid in the first row or you can press the Add button. Add a new field called CustomerID , make it required, and set its type to VarChar . The default size is 10 and that's fine for our purposes now. If you want to change the size, or other characteristics of the field, you can press the Edit button and get a dialog that looks like this:
Size and data types are on the Data Type tab, by the way. You can explore the other options in this dialog.
Continue accepting the defaults Visio gives you and add the rest of the Customer fields so you have a grid that looks similar to the following:
The last step is to identify a Primary ID for this table. In our case, that's easy - the CustomerID field. Click on the Primary ID line in the Categories list box. Select the CustomerID from the list of available columns and add it to the Primary ID columns. Your window will look like this:
Now have a look at the
shape we first dragged onto the drawing page. It is
Now that the tables are defined, we have to relate them together. In Visio, it's simple. The second of our most commonly shapes is the relationship. As you might expect, the relationship shape represents actual database relationships - one to one, one to many, and many to many.
Let's draw a relationship between Customer and Order first. By definition, a Customer can have many orders, but an Order record can only belong to one Customer . Click and drag the Relationship connector onto the drawing page. Drag the end of the connector with the arrowhead into the middle of the Customer table. The table should become highlighted in red. That means you've connected the line to the Entity shape so they'll move together. You've also started giving the template information on how to build the relationship. Click and drag the other end of the line into the middle of the Order table. The same thing should happen - a red highlighted Entity shape. Without actually connecting the shapes together with the Relationship connector , what we're about to discuss won't work correctly. Make sure you've got the connector drawn correctly - to confirm this, select the connector and check that both ends are colored red, indicating they are glued. You should have something that looks like this:
Our two tables are basically the same. The only difference is the FK1 listed in front of the CustomerID field in the Order table. That indicates the CustomerID field is a foreign key back to the Customer table. That relationship will tell us which customer a particular order belongs to.
Repeat the same process for the rest of the tables and you'll end up with a group of tables and relationships that looks like this:
It's common to have to correct what Visio does when naming foreign keys. The application does a reasonably good job, but don't trust it blindly.
In Chapter 8 we'll take a deeper look into the database modeling, and see how to actually generate database tables from these diagrams, and also how to reverse engineer database structures into diagrams like the above.