Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects
|
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 shapes and templates for some common diagramming tasks included with Visio. In addition to software development, Visio contains ready-made templates for a variety of diagramming applications. Not surprisingly, most of them are technical or engineering oriented. Here are the software diagrams available in Visio for Enterprise Architects: 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 group of COM and OLE objects by using shapes that represent interfaces, processes, and process boundaries, among other things. We'll get into the details of the most common shapes used in these diagrams in a moment, but first let's take a look at a quick example to help with the discussion. Notice that the shapes in the diagram below are somewhat self-describing. Using our software development background we can probably read this diagram without any previous exposure to this type of diagram. 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 sort is an object called Customer that uses another object in another component called Order. Within that component, within the same process, the Order object uses the OrderLine object. So even without much background in COM and OLE diagrams, we can read and derive something meaningful from the diagram. Let's take a closer look at the common shapes in this template and how you can use them in your own diagrams.
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 COM Object shape onto the drawing page, new interfaces can be added by dragging the Interface shape onto the drawing. If you drag the tail of the Interface shape over top of the COM Object, the two will connect themselves automatically. A Customer object that gets used by various business components for Shipping, Billing, and Order Entry might have different interfaces for each purpose. In that situation, we could draw the object and its interfaces like this:
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 multi-step process easy to understand. Visio ships with a variation of the Data Flow Diagram (DFD) using the Gane-Sarson notation. It's unlikely that any experience you've had with DFD's will vary greatly from the notation included in Visio. 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 follows:
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 governing how these shapes can be connected and the DFD template in Visio enforces them.
If you violate these rules, Visio will let you know. The DFD template is built with some intelligence indicating what's allowed in a drawing and what isn't. In fact, you'll get error messages if you mess something up. For instance, if we add a process to our example DFD for processing credit cards and we don't give it an output Data Store, Visio will write an error message to the Output window as this screenshot illustrates: Notice the new Process Credit Card shape near the bottom of the diagram. On your screen, the color of the shape's line is now a bold red, indicating some error. In the Output window is written the message:
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 docked window in the lower left of the Visio UI. It's labeled Model Explorer and quite literally, that's what it is - a tree-view-based explorer listing every process, interface, and data store in the diagram. For complicated diagrams, it's a handy feature. We'll see similar devices in other diagram templates. The UML diagram template in particular has a nice Model Explorer, and we'll see much of it as we progress through the book!
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 certainly is quick. There are a couple of problems with prototyping UIs with VB, though. First, users and developers see those prototypes as actual working software and may be less likely to tear it up, since it's a real program regardless of how little functionality it may contain. Second, developers seem to build more functionality into their prototypes making them harder to walk away from once the prototype stage is complete. Effective prototypes are generally throwaway pieces of code. Otherwise, they aren't prototypes and their importance as a design and development tool is minimized. 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 clients or presented to user groups for review and comments. Also, we won't have opened any IDE or other rapid application development package to do it. In addition, when changes are requested, we can quickly and easily add and remove UI items and reposition existing items. This diagram template has the potential for saving quite a bit of design and development time depending on the UI requirements of your applications and involvement of your user groups. 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 buttons, status fields, etc. Let's have a look at a few and see how we can dress up our simple form before we start adding items like text boxes and combo boxes. 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: ( Other common Form-related UI controls are the Corner Resize and Status Field shapes. The Corner Resize (also known as the Grip) is the angled shape you find on forms that allow resizing. The user will click and drag the Corner Resize control and make the form's height and width change. It's easy to add - the control is found near the bottom of the stencil in the next to last row. Similar to the Windows buttons, drag the Corner resize to the lower right corner of the sample form we've already created and drop it when the connector points of the control turn red. Now let's add some Status fields across the bottom. These regions are generally used to display application information like page numbers, current line position, or any other application information that may be useful to the user at a quick glance; Microsoft Word uses Status fields as well as do most other Microsoft applications. To create the Status field, locate the Status field shape on the stencil (third row, third column), drag it onto the sample form, and drop it near the bottom of the form. Again, Visio will help you out by docking for Status field shape onto the Windows Form shape if you get it close. Our example Form now looks like this screenshot: 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. In the Windows UI diagram in Visio, standard Windows menus are represented by a few shapes - the Menu itself, a Top-level menu item, and a Drop-down menu item. By combining the three shapes we can mimic just about any application menu we need to. Let's start by adding the Menu shape to the form we've been building. Make sure you have Visio running and have a Windows User Interface drawing open. We'll be adding to our Sample Windows Form we've been building in this section, so locate that if you've been following along. 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 dockable shapes that will contain menu names like File, Edit, View, etc. Drag the shape onto the Menu shape already on the form and dock it on the left side of the Menu shape. Watch where you dock the top-level menu item - there are several connecting points available in the drawing now. Click on the newly added top-level menu item and type the word File. You'll see a form that looks like this screenshot: Add a few more top-level menu items and you've got a good looking Windows form complete with many common form-level UI controls. 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 Additional tabs and dock it immediately to the right of the Main tab you just created - name it Options. Notice that the Options tab is slightly lower than the Main tab. That's how Visio indicates which tab is active. If you right-click on the Options tab you can select Move Tab to Top. Both tabs will be the same size so you need to right-click on the Main tab and select Move Tab to Back. Now the Options tab is active. You can add controls to the body of the tab control to represent what's visible when the Options tab is clicked. The screenshot below shows the active Options tab with three fictitious options represented by checkboxes. 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 darker line drawn around the button usually indicates defaults. The default button is executed when the user presses the Enter key. To set the Next button as the default on the first page in a wizard, right-click on it and select Selected and Default from the pop-up menu. With the Back button disabled and the Next button set as the default button, our wizard now looks like this screenshot:
Creating Database Model Diagrams
The last Visio diagram we'll review in this chapter is the one I've personally used the most - database model diagrams. These diagrams show tables and their relationships and, optionally, table details like fields, indexes, foreign keys, and other information. In practice, it seems that creating and distributing data models is a common task in the course of building a software application. I won't speculate on why but I imagine that it's easier to illustrate table relationships graphically in a diagram than it is to describe verbally. You may find in your own work that you spend more time on building database model diagrams than any other type of diagram. 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 core of the data model will be a Customer table. We'll also need an Order table for storing order details, an OrderItem table to store what each order contains, and a Product table used to store product details like name and price. 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 duplicated in OrderItem and Product in case the main product price changes after an order has been created. Let's start with a brand-new Visio diagram. If Visio is running close all open diagrams and select File | New then select Database | Data Model Diagram. You'll get an empty drawing page that looks similar to this screenshot: 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 Customer. To add fields click on the Columns line in the Categories list box and you'll see the Properties window change to include a grid. 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 Entity shape we first dragged onto the drawing page. It is populated with a table name, a list of fields, and the primary key field is identified by a bold underline with a PK beside it. Repeat the same process for the remaining tables and you'll get a drawing page that looks like this: 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. Always review what Visio has created for you! 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.
| |||||||||||||||||||||||||||||||||||