The Basics

Have you ever wanted to learn more about Unified Modeling Language models? This article will introduce you to two of them, and then show you how to create code and a database with the models. It is excerpted from Enterprise Development with Visual Studio .NET, UML, and MSF, written by John Erik Hansen and Carsten Thomsen (Apress, 2004; ISBN 1590590422).

Contributed by Apress Publishing
Rating:

/ 20
April 06, 2005

Rate this Article:
MEH MEH++

SEARCH ASP FREE

THIS CHAPTER WILL introduce you to enterprise modeling, enterprise development, and enterprise applications. Because we believe in learning by doing, we’ll also use this chapter to let you get your feet wet. We’ll walk you through two short but useful example models: one that you’ll be able to use to create the skeleton for Visual Basic .NET (VB .NET) and/or C# classes and another that you can use to model the database.

So, what is it that you’re about to see and learn? Well, as we already mentioned, we give you a fairly easy introduction to two rather simple Unified Modeling Language (UML) models in this chapter. Then we show you how these models are used for creating some “real” code and a database to be used by the code. We’ve written this chapter with the developer in mind, meaning you can generate code directly from the models you create. The UML models presented in this chapter are far from “complete”¹ and show only the class diagrams (or static structure diagrams as Visio calls them) and a database model. We assume that you’re acquainted with object-oriented programming (OOP). It’s not that we’ll be going into detail about OOP, but we’ll make use of terms such as class attributes, operations, and so on.

Basically, the aim of this chapter is to give you a look at what kind of modeling you can do with Visio. There’s plenty of information for you in the upcoming chapters. In Chapter 2, you’ll learn how to design and plan an enterprise solution, and in Chapters 3 through 5, you’ll learn how you can use the various UML models supported by Visio to model your enterprise solution from a very high-level perspective to a very detailed perspective. So, this chapter will primarily serve as an introduction to the following chapters and, as such, the amount of detail in this chapter will vary.

If you’re fairly new to application or database modeling, or if you’re new to Visio, we suggest you do read this chapter; otherwise, feel free to move on to the next chapter.

Defining Enterprise Applications, Development, and Modeling

The word enterprise seems to be the buzzword these days when speaking of software development. You’ll see many things labeled with the word, but it’s rather hard to actually define what it is. In the context of this book, we care about only enterprise applications, development, and modeling, which we describe in the following sections.

Enterprise Applications

Enterprise applications are generally defined as applications that are built of many smaller applets, components, or programs. They are typically spread across any number of machines, effectively labeling them n-tier applications, because they consist of more tiers (physically or logically separated machines). Quite often, and ever increasingly so, enterprise applications are also physically separated on different networks across a wide area network (WAN) such as the Internet. Although there is no “proper” definition of enterprise applications, this is a good definition to use.

Enterprise Development

So what is enterprise development then? Is it when you’re developing enterprise applications? No, the two are not automatically connected, although they tend to go hand in hand. Enterprise development is when you have a team of developers working on the same solution, mostly on different projects, but sometimes on the same project and sometimes even on the same functionality. Obviously, it takes more to organize enterprise development than other simpler types of development because there are more people involved. All these people must be managed so they don’t perform the same task, or even worse, overwrite changes to the code made by another developer. This is one of those things you can manage by using tools that lock source code, such as Visual SourceSafe (VSS), which is described in Chapter 11.

On a project with one or two developers, you generally know what your tasks are, but more important, you also know what the other developers’ tasks are. This isn’t so with enterprise solutions, because you don’t have the overview of all the projects that make up an enterprise solution. That is the job of a project manager or someone with a similar role. You can read more about the various roles needed to create enterprise applications in Chapter 20.

Enterprise Modeling

Enterprise modeling is when you model your enterprise applications, with modeling literally meaning models of your application and, in most cases, also the enterprise architecture. Enterprise modeling can be a complex task, especially when you factor in everything from working with legacy systems (and legacy people) to politics. However, it isn’t necessarily so. An enterprise task certainly can be a rather large mouthful, but given the right approach, as you’ll learn in the coming chapters, it’s manageable and fairly easy. The keywords are planning and documentation, as you’ll learn in Chapter 2.

Taking a Quick Look at Visio

Visio is Microsoft’s modeling tool, and it’s primarily this tool that we’ll be using throughout the book. Visio is different from most other enterprise modeling tools, such as IBM Rational Rose and IBM Rational XDE, because it can be used for many different kinds of modeling, including UML and database modeling, as you’ll see in this chapter. Visio isn’t a new tool, but as a UML modeling tool, it hasn’t been one of the major players in the market, because of its capabilities, or rather, lack of capabilities. However, the latest version of Visio (the one that is bundled with Visual Studio .NET Enterprise Architect Edition) goes a lot further than any previous version of Visio, which is why we’ve chosen to write about it in this book. It’s by no means the best UML modeling tool around, but we do feel that it’s good in many situations.

The Visual Studio .NET Enterprise Architect (VSEA) edition is the only version of Visual Studio .NET (VS .NET) that comes with the modeling tool Visio for Enterprise Architects (VEA). The other enterprise edition of VS .NET, Visual Studio .NET Enterprise Developer (VSED), doesn’t include Visio. In fact, the modeling tools really separate VSEA and VSED.

Visio Versions

The Visio for Enterprise Architects (VEA) 2003 software that comes with VSEA is based on Visio 2002 Professional, which you can buy separately. However, you can’t just buy the VS .NET Enterprise Developer edition and Visio 2002 Professional and hope they will give you the same functionality. VEA has everything that Visio 2002 Professional has, but it also provides integration with the VS .NET integrated development environment (IDE) through the UML add-on. This means that you get added functionality, such as reverse engineering of existing projects to UML models.

Since the release of VS .NET 2003, Microsoft Office has also been released in a new edition, Microsoft Office 2003. This also means that a new version of Visio has been released, Visio 2003, but only Visio Professional 2003 has some of the software modeling features that the VEA 2003 software has. You can see a Visio 2003 edition comparison at http://www.microsoft.com/office/visio/prodinfo/editions.mspx.

The latest edition of Visio has more features than VEA and Visio 2002 Professional, as you would expect, but only VEA has the UML add-on that allows code generation and forward engineering from UML diagrams. Visio Professional 2003 allows only reverse engineering of code. So, if you need to create code skeletons from UML diagrams, your only option at the time of writing (early 2004) is to install VEA. However, you can have both VEA and Visio 2003 installed at the same time (but because the installations overlap, Windows Installer is used to configure the active installation when you swap between the two). You can see a version comparison at http://www.microsoft.com/office/visio/prodinfo/compare.mspx.

Note that the documents produced with Visio 2003 are not compatible with previous versions.

Although Visio is a stand-alone product in the Microsoft Office family line of software, it’s also a professional tool for software architects, among others, which is really why you’re reading this. If you’re familiar with Visual Basic (VB) 6.0, you might be familiar with Visual Modeler, the rudimentary UML tool that came with VB Enterprise Edition (and was even available as a separate download for VB 5.0). This tool, which was licensed from Rational Software, has been replaced with VEA in VS .NET. Visual Modeler (which we guess, by the best of opinions, was a decent tool) was really just a “lite” version of Rational Rose from Rational Software²(http://www.rational.com). Chapter 12 will give you a detailed introduction to Visio. We’ll compare Visio to IBM Rational products in Chapter 19.

NOTE If your customer doesn’t own a copy of Visio, they can download the Visio Viewer that works with Microsoft Internet Explorer 5.0 or later from http://www.microsoft.com/downloads/details.aspx? FamilyID=3fb3bd5c-fed1-46cfbd53da23635ab2df&DisplayLang=en. This also applies for those parts of your organization that only need to read Visio diagrams and not create them. However, they could use the Web Publish facility. You can also download a trial version of Visio 2003 from http://www.microsoft.com/office/visio/prodinfo/trial.mspx.

This article is excerpted from Enterprise Development with Visual Studio .NET, UML, and MSF by John Erik Hansen and Carsten Thomsen (Apress, 2004; ISBN 1590590422). Check it out at your favorite bookstore today. Buy this book now.

Modeling a Logon Process

For the first short, get-up-to-speed-fast, hands-on example in this chapter, we’ve decided to model a process that many people create the code for during their career: a logon process. For the modeling of the logon process, you need VEA 2003. Basically, you model the class in Visio, and later you generate the code in VB .NET or C#. You can then include the generated output in a VS .NET project.

Creating the VB .NET Class

Let’s get started with creating the class on the class diagram in our UML model. In Exercise 1-1, you will start a new UML diagram and add a class to it.

EXERCISE 1-1

Open VEA.
To create a new UML model, select File -> New -> Software -> UML Model Diagram. It doesn’t matter whether you select the UML Model Diagram (Metric) or the UML Model Diagram (US units). It’s only a matter of page settings and it has nothing to do with different models. Note that one of the two might not appear on your system, depending on what you selected during setup.
Create a class by dragging the Class icon from the UML Static Structure tab in the Shapes window, usually located on the left side at the top. VEA should now look like Figure 1-1.

TIP The diagram view will probably be so small it will be hard to read when you first open it. However, you can change that by selecting a menu command in the View -> Zoom menu. There’s also a list box on the toolbar for this purpose.

Figure 1-1. VEA open with a new UML model diagram

You have the class diagram (static structure diagram) that you’ll be working with. Now it’s time to add attributes (variables and properties) and operations (procedures, event handlers, constructors, and destructors). You also need to give the class a name representing the functionality of the class. Exercise 1-2 shows how to do this.

EXERCISE 1-2

Open the UML Class Properties dialog box by right-clicking the class (Class1) on the diagram and selecting Properties from the pop-up menu. You can also double-click the class.
Name the class Logon by typing it in the Name text box, as shown in Figure 1-2.

Figure 1-2. The UML Class Properties dialog box

3. Select the Attributes category in the Categories list.

4. Create a new attribute by clicking the New button.

5. Type m_userID in the Attribute column.

6. Select VB::String from the Type list.

   7. Repeat steps 4 through 6, giving the second new attribute the
        name m_password. The UML Class Properties dialog box should
        now look like Figure 1-3. Note that attributes are private by
        default.

Figure 1-3. The UML Class Properties dialog box showing attributes

Coding Conventions

Although this chapter isn’t about coding conventions, and it doesn’t even contain a lot of code, we want to get the message across, before you start e-mailing us about our coding conventions. We use the following Microsoft-endorsed and/or recommended guidelines:

http://www.gotdotnet.com/team/vb/VBSampleGuidelines.htm
http://msdn.microsoft.com/library/default.aspurl=/library/en -us/ cpguide/html/cpconwhatiscommonlanguagespecification.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ cpgenref/html/cpconvaluetypeusageguidelines.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ vsent7/html/vxconcodingtechniques.asp

We’re aware that some of these documents overlap, but they will give you an idea of why and how we name our classes, constants, variables, and so on.

NOTE VEA 2003 comes with a complete set of data types supported by the four programming languages you get with the VSEA edition: C#, C++, J#, and VB .NET. You can also choose from the Interface Definition Language (IDL) data types, which means you might avoid having separate models for different target languages. However, the IDL data types don’t support all the data types in the three mentioned programming languages. On the other hand, IDL does support data types that are supported in only some of the three programming languages. One such example is unsigned data types, which aren’t supported in VB .NET. One thing you can do is to use IDL data types for all the generic data types, and then use more language-specific ones when they are necessary.

Now that you’ve named the class and created the attributes for it, you need to create the operations for it. Exercise 1-3 demonstrates how to specify operations and their parameters.

EXERCISE 1-3

Open the UML Class Properties dialog box (if it isn’t already open).
Select the Operations category from the Categories list.
Create a new operation by clicking the New button.
Type Logon in the Operation column.
Select VB::Boolean from the Return Type list.
Click the Properties button while the Logon operation is selected to open the UML Operation Properties dialog box.
Select the Code Generation Options category from the Categories list.
Select Procedure from the Operation Kind list.
Select the Parameters category from the Categories list.
Create a new parameter by clicking the New button.
Type userID in the Parameter column.
Select VB::String from the Type list, and ensure “in” is selected in the Kind column.
Repeat steps 10 through 12, creating a new input parameter with the name password. The UML Operation Properties dialog box should now look like Figure 1-4.

Figure 1-4. The UML Operation Properties dialog box showing parameters

14. Click OK.

15. Select the Code Generation Options category from the
Categories list.

16. Select Visual Basic from the Target language list.

17. Click OK. You return to the class diagram, which is updated to
        reflect the changes you’ve made. (You may need to select
        View -> Zoom to adjust the class size on the diagram.) The class
        has a new name, Logon, and the attributes and operations are
        displayed, divided by a horizontal line, as shown in Figure 1-5.

Figure 1-5. The Class diagram with the updated class

Now that you’ve actually completed the class skeleton for the example, let’s take a moment to recap what you did to get to this point:

Created a new UML model diagram
Added a class to the diagram
Created two attributes (private variables) for the class
Created a public operation (procedure) with two input parameters
Specified the target programming language as Visual Basic

Now you just need to save the UML model, following the steps in Exercise 1-4.

EXERCISE 1-4

Select File -> Save.
Browse to the location you want to save the model in and type a name in the Save As dialog box. Save the model with this name and path for easy access

in later exercises and chapters: \EDWVSNETUMLMSF\Chapter 01\ VB .NET\Logon.vsd.

3. Click OK.

Generating the VB .NET Code for the Logon Class

Now that you’ve created the skeleton model for the Logon class, it’s time to see the actual code that VEA generates from the model, which is what it’s ultimately all about—generating and maintaining the code for your application. Exercise 1-5 shows how to generate the VB .NET code.

EXERCISE 1-5

Select the Logon class.
Select UML -> Code -> Generate. This brings up the Generate dialog box.
Make sure Visual Basic is selected in the Target language list.
Select the Logon class in the Select classes for code generation tree view.
Select the location you want the generated output placed in by typing the path in the Location text box or by browsing to the location after clicking the Browse button. Save the output with this name and path for easy access in later exercises: \EDWVSNETUMLMSF\Chapter 01\VB .NET\ TopPackage\Logon.vb. The Generate dialog box should now look like Figure 1-6. Note that when you select the VB .NET folder, VEA assumes the Top Package folder underneath it.

Figure 1-6. The Generate dialog box

6. Click OK. You might be prompted to create a nonexistent folder.
If so, click Yes.

NOTE The Top Package subfolder comes from the Model Explorer, which is usually shown on the left side of the Visio workspace, as you can see in Figure 1-7. We won’t be covering packages now, but a UML package in VEA resembles a namespace in .NET (that is, a logical grouping).

In Figure 1-6, you can see the code-generation options for the Logon class in the Generate dialog box. Once you click OK in the Generate dialog box, the code is generated and output to the specified location. The Output window shows if any errors were encountered during the code generation.

In Figure 1-7, you can see the Top Package UML package selected in the Model Explorer. You can give your package any name by double-clicking the package. This will bring up the UML Package Properties dialog box.

Figure 1-7. The Model Explorer with Top Package selected

Figure 1-8 shows the Output window after the VB .NET code is generated for the Logon class. In our case, there weren’t any semantic errors.

Figure 1-8. The Output window showing semantic errors after code generation

NOTE Semantic errors are programmatic errors such as incompatible data types. If you pick a data type as the return type for an operation that’s not supported in the target programming language, you’ll see a semantic error in the Output window.

Now let’s take a look at the generated code. Go to the output location you specified in the Generate dialog box and double-click the Logon.vb file. If your VS .NET installation is working properly, and you haven’t specified that VS .NET should open the last loaded solution when opening,³ the code file is opened in the VS .NET IDE, and it should look similar to the one shown in Figure 1-9.

Figure 1-9. The generated VB .NET code for the Logon class

Figure 1-9 shows the generated output for the Logon class from the UML model as VB .NET code. If you’re familiar with VB .NET or even VB, there shouldn’t be any surprises in the generated code. However, we’ll just run through the code listing, pointing out what the various code lines correspond to in the UML model:

Lines 4 and 15 define the class boundary.
Lines 6 and 8 are the two class attributes or member variables.
Lines 10 through 13 are the Logon procedure, declared as a Function, because you specified a return type (Boolean). The two input parameters have been declared with ByVal, which effectively means they’re input parameters, because changes to the values of a parameter declared with ByVal won’t be reflected in the caller of the operation.

TIP To turn on line numbers in Visual Studio, select Tools -> Options -
> Text Editor/Basic and check the Line Numbers option.

We’re aware this isn’t a lot of code, and that for such a small class it would be easier to create it the normal way. However, many useful applications do start out as small, simple, and unplanned applications, don’t they?

Creating the C# Class

You’ve created the VB .NET class, and since the content of the C# class is the same, you need to change only a few things in the class model. The differences are the data types you used for the attributes and the operation and the target programming language. Exercise 1-6 demonstrates how to change from VB .NET to C#.

EXERCISE 1-6

Open the previously saved Logon.vsd UML model in VEA (if it isn’t already open).
Open the UML Class Properties dialog box for the Logon class.
Select the Code Generation Options category from the Categories list.
Select C# from the Target language list.

5. Click OK.

Now you’ve changed the target programming language, but didn’t we just state that you need to change the data types for the new target programming language? Yes, we did. However, the data types chosen for the VB .NET class were common type system (CTS) compatible, meaning they exist in all .NET programming languages. Well, this isn’t quite true, but for data exchange between classes in different .NET languages to work, the exposed data types must be CTS compatible. You used the Boolean and String VB .NET data types, and they certainly have counterparts in C#. Generally, you won’t find a problem when going from VB .NET to C#. A problem is more likely to arise when you go in the other direction—if you select an unsigned data type in C# and want the corresponding data type in VB .NET. VB .NET doesn’t directly handle unsigned data types;⁴therefore, VEA won’t be able to convert those data types for you.

If you feel confident that you can generate the C# code for the Logon class now, feel free to jump to the next section. However, for the purpose of having two different models saved in different locations and with the correct data types, follow along with Exercise 1-7.

EXERCISE 1-7

Open the UML Class Properties dialog box for the Logon class.
Select the Attributes category from the Categories list.
Select C#::string from the Type list for the m_userID and m_password attributes.
Select the Operations category from the Categories list.
Select C#::bool from the Return Type list for the Logon operation.
Click the Properties button while the Logon operation is selected to show the UML Operations dialog box.
Select the Parameters category from the Categories list.
Select C#::string from the Type list for the userID and password parameters.

9. Click OK twice.

The changes you’ve made to the Logon class should now be reflected on the diagram. Save the new model to this name and path for easy access in later exercises and chapters: \EDWVSNETUMLMSF\Chapter 01\C#\Logon.vsd.

Generating the C# Code for the Logon Class

Now that you have modified the Logon class for C#, it’s time to see the code that VEA generates from the model. Exercise 1-8 shows how to generate the C# code.

EXERCISE 1-8

Select the Logon class.
Select UML -> Code -> Generate. This brings up the Generate dialog box.
Make sure C# is selected in the Target language list.
Select the Logon class in the Select classes for code generation tree view.
Select the location you want the generated output placed in by typing the path in the Location text box or by browsing to the location after clicking the Browse button. Save the output with this name and path for easy access in later exercises and chapters: \EDWVSNETUMLMSF\ Chapter 01\C#\TopPackage\Logon.cs.

6. Click OK. You might be prompted to create a nonexistent folder.
If so, click Yes.

Let’s take a look at the generated C# code. Go to the output location you specified in the Generate dialog box and double-click the Logon.cs file. The code file is now opened in the VS .NET IDE, and it should look like the one shown in Figure 1-10.

Figure 1-10. The generated C#code for the Logon class

Figure 1-10 shows the generated output for the Logon class from the UML model as C# code.

Code Generation Summary

As you’ve seen from the previous exercises, the code generated by VEA is nothing more than a skeleton of the class(es) you have in your UML model. However, you can add significantly more to your diagrams and have it reflected in the generated code. Specifically, we’re thinking about documentation here, in the form of comments in the code, initial attribute values, visibility, scope, multiplicity in the form of collections and arrays, and so on.

Modeling a Database

The Logon class you created in the previous section needs to do some database lookup in order to validate the user that is trying to log on. Therefore, you need a database, which you’ll be modeling in this section. In standard UML, you normally model a database as a class diagram, giving it a Table stereotype. (We’ll talk more about stereotypes in later chapters.) VEA doesn’t support the generation of Data Definition Language (DDL) scripts from class diagrams, which means you can’t do it that way. However, VEA (and the standard versions of Visio) has a perhaps better way of dealing with databases: the database model diagram.

Creating the Database Model Diagram

VEA offers database modelers several options, including entity-relationship (ER) and Object Role Modeling (ORM) diagrams. However, in this book, we’ll be using the database model diagram.

ER and ORM Diagrams

Entity-relationship (ER) diagrams (sometimes called ERDs) were introduced in the mid-1970s, originally by Dr. Peter Chen. They’re used for conceptual modeling of relationships between entities, just as their name suggests. The fact that ER diagrams are used for conceptual modeling makes them different from the database model diagrams used in this book. The idea with ER diagrams is that anyone involved in a project should be able to understand an ER diagram. ER diagrams consist of different entity types, relationships, attributes, and types.

The entities are real-life objects, such as users, and sometimes they’re more abstract than that, but they must be meaningful to the business. The attributes are used to describe the entities, and the relationships are used between entities.

One problem with ER diagrams is that there’s no real standard, although most people use ER diagrams with only small variations. One notation that seems to have been standardized is the crow’s feet notation, which is generally used to show cardinality of relationships between entities, using 0 (zero or more entity instances), 1 (one or more entity instances), or n (several entity instances). See Figure 1-11 for an example.

Figure 1-11. Crow's feet notation on a simple ER diagram

Object Role Modeling (ORM) is a method for designing database models at the conceptual level, meaning you’re using terms and diagrams that can be understood by the user. A comparison to UML with regards to visual software communication is in order, because that’s what it is: an easy way of visually communicating a database model at a level that’s understood by all parties in a project. ORM diagrams are different from the database model diagrams we use in this book in the way they communicate their content. Check out the ORM Web site (http://www.orm.net) for more information.

In Exercise 1-9, you’ll start a new database model diagram and add a table entity to it.

EXERCISE 1-9

Open VEA (if it isn’t already open).
Create a new database model by selecting File -> New -> Database -> Database Model Diagram. VEA should now look like Figure 1-12.

Figure 1-12. VEA open with a new database model diagram

   3. Create an entity by dragging the Entity icon from the Entity
        Relationship tab in the Shapes window (usually located on the
        top left—see Figure 1-12).

   4. Double-click the new entity (Table1) on the diagram to see the
        properties for it. You can also right-click the entity and select
        Properties from the pop-up menu. Now the Database Properties
        window is shown at the bottom of the Visio workspace, as in
        Figure 1-13. This is where you can set the properties, such as
        the name, for the entity that is selected on the database
        model diagram.

Figure 1-13. The Database Properties window open in the
Visio workspace

Now that you’ve added the table⁵entity to the diagram, it’s time to set the properties of the table. Exercise 1-10 shows how to do this.

EXERCISE 1-10

Name the table entity User in the Physical name text box in the Database Properties window. When you start typing, you’ll notice that the text in the Conceptual name text box is synchronized with the contents of the Physical name text box. However, this only happens if you’ve selected the Sync names when typing check box, which is next to the Physical name text box.
Select the Columns category from the Categories list.
Type ID in the Physical Name column and select Row ID from the Data Type list. Make sure that Portable data type is selected as the Show option (see Figure 1-14).
Select the Req’d (Required) and PK (Primary Key) columns.
Repeat steps 3 and 4, creating two new columns named Name and Password of data type VarChar (variable length string). Make sure you select the Req’d column. The Database Properties window should now look like Figure 1-14.

Figure 1-14. The Database Properties window open on the Columns category page

NOTE In our example, the physical name and the conceptual name are the same, and we think it’s wise to keep it that way. However, you can choose to have two different names for the table entity: one that’s used in the database and one that’s used in your diagrams. You would do this if you have a conceptual name with spaces or other characters that are not supported by the naming scheme implemented by the database on which you’re creating the table.

In Figure 1-14, you can see the Database Properties window open on the Columns category page. There is one small problem with the two VarChar columns (Name and Password)—they’ve automatically been set to a maximum length of 10 characters, which isn’t enough in our table. Therefore, you need to change the maximum length to 50 to accommodate a longer name and password in the table. As you can also see from Figure 1-14, the data type is named SBCS VarChar(10). SBCS stands for Single Byte Character System, which refers to the standard Western character sets that require only one byte for storing a character. However, if you need to store characters from other character sets such as Japanese or Chinese, which use two bytes of storage per character, you need to use the Double Byte Character System (DBCS).

In Exercise 1-11, you’ll adjust the length of two table columns.

NOTE We’re aware that 50 characters for a password might seem a bit excessive, but from a user’s point of view, it’s better to have too much space than too little. For this example, just follow the exercise instructions, which demonstrate how to change the size of a column.

EXERCISE 1-11

Select the Name column and click the Edit button. This brings up the Column Properties dialog box.
Select the Data Type tab, as shown in Figure 1-15.

Figure 1-15. The Column Properties dialog box showing the Data Type tab

3. Type 50 in the Length text box.

4. Click OK.

5. Repeat steps 1 through 4 for the Password column.

Figure 1-15 shows the Data Type tab of the Column Properties dialog box. You can see the data type properties for the Name column. We’ve set the length to 50 to accommodate a longer name than the default of 10.

Once you’ve changed the column lengths for the two columns, the Database Properties window should look like Figure 1-16. You can see that the column lengths have been changed to 50, because of the changes you made in the Column Properties dialog box.

Figure 1-16. The Database Properties window with updated column lengths

NOTE If you need to know more about databases in general and database programming with C# or VB .NET, we can recommend these titles from Apress: Database Programming with VB .NET, Second Edition, written by Carsten Thomsen, ISBN: 1-59059-032-5; and Database Programming with C#, written by Carsten Thomsen, ISBN: 1-59059-010-4.

All the columns are now in place, with the ID column as the unique row ID, which we can later use for joining with other tables. We can also use Name as a unique value column, but in keeping with the way we apply the database normalization forms to our database schemas, this is how we proceed. The ID column has already been designated as the primary key of our table, meaning all values in this column must be unique and null values are disallowed.

Since the Name column is an excellent candidate for searching for a user when performing a lookup from the Logon process, it’s a good idea to create an index on this column. An index will generally facilitate a faster lookup. Exercise 1-12 shows how to add an index.

Select the Indexes category from the Categories list.
Click the New button, which brings up the New Index dialog box.
Type IX_Name in the Non-unique index name text box.
Click OK. The Database Properties window, with the Indexes page open, should now look like Figure 1-17.

Figure 1-17. The Database Properties window showing the Indexes page

5. Select the Name element of the Available columns list, and
click the Add button to add the Name column to the index.

   6. Select Unique index only from the Index type list. The IX_Name
      index now consists of the Name column, and the index is a
        unique index. (There are other options on the Index type list,
        but which unique index option is the best is database-specific.)
        The index is shown on the diagram as U1 next to the Name
        column.

7. That’s all you need for this simple database, so save it to
\EDWVSNETUMLMSF\Chapter 01\Database.vsd.

Generating the Database

Once you have your database model in place, it’s really very simple to have the physical database generated. However, you do need to know which type of database you want to create and where it’s located. Depending on the choice of database, you might also need to know the user ID and password for the database (hmm. . .user ID and password sound familiar). After you’ve selected the database type, you need to check the database model for problems that might prevent VEA from generating the database.

In Exercise 1-13, you’ll generate the database model, and then check it for errors.

EXERCISE 1-13

Select Database -> Options -> Drivers. This brings up the Database Drivers dialog box, which shows all the installed ODBC drivers on your system.
Select Microsoft Access from the list and click OK.
Select Database -> Model -> Error Check.

The Output window, which is now shown in the VEA workspace, displays the results of the error check, as shown in Figure 1-18. You can see that the logical validation went fine, but the physical validation didn’t. This means that VEA won’t be able to generate the Microsoft Access database, because there’s a problem with the ID column.

Figure 1-18. The Output window showing database model error-check messages

In Figure 1-18, you can see that the physical validation against the Microsoft Access ODBC driver went wrong. The ID column has no precision specified. Wait a minute, didn’t you tell VEA to use the Row ID data type and not CHAR, as it now seems to be? You did, but this is one of the cases where VEA has a problem with the selected portable data type when it comes to generating it in the physical database. But you don’t need to worry, because if you know just a little about Microsoft Access, you also know that the physical data type you’re after is the AutoNumber one. This data type generates a unique number for each new row inserted into the table, starting with 1 and incrementing by one, by default.

In Exercise 1-14, you will change the data type for the ID column.

EXERCISE 1-14

Open the Database Properties window by clicking the Database Properties tab at the bottom of the Visio workspace.
Change the data type for the ID column to Counter (auto).
Select Database -> Model -> Error Check.

Now both the logical and physical validation against the Microsoft Access ODBC driver succeeds, as you can see from the Output window. Way to go! Now let’s get that database on the road. In Exercise 1-15, you’ll use the Generate Wizard to generate the database.

EXERCISE 1-15

Select Database -> Generate. This brings up the Generate Wizard, as shown in Figure 1-19.

Figure 1-19. The opening page of the Generate Wizard

2. Select the Generate new database option.

   3. Click Next. Now the second page of the Generate Wizard
        displays, as shown in Figure 1-20. This is where you specify the
        type and physical location of the database.

Figure 1-20. The second page of the Generate Wizard

4. Make sure Microsoft Access is selected in the Installed Visio
drivers list.

5. Select the Create MDB file option.

6. Click the New button. The Create New Data Source dialog box
appears.

7. Select the System Data Source option and click Next.⁶

8. Select Microsoft Access Driver from the list and click Next.

9. Click Finish. The ODBC Microsoft Access Setup dialog box is now
shown.

10. Type Chapter 1 Database in the Data Source Name text box.

11. Click the Create button. This brings up the New Database dialog
box, which is really nothing more than the well-known Save As
dialog box.

12. Browse to the \EDWVSNETUMLMSF\Chapter 01 folder and type
Database in the Database Name text box.

13. Click OK.

14. Click OK in the confirmation dialog box.

15. Click OK in the ODBC Microsoft Access Setup dialog box.

16. Click Next.

17. Click OK in the Connect Data Source dialog box, because you
haven’t specified a user name or a password for the database.

18. Click Next on the database table review page.

19. Click Finish.

After completing the exercise, you’re asked if you want to see the generated DDL script. Click Yes to open up the Visio Code Editor with the DDL script.

In Figure 1-21, you can see the DDL script for the Microsoft Access database you just created. You don’t actually need the script, because the database was also created. However, it’s good practice to have a script for all database objects your application relies on, because it’s important to be able to re-create a database structure quickly in case of an emergency, such as if the database becomes corrupt and can’t be fixed. You might also want to have the DDL script for testing purposes.

Figure 1-21. The Visio Code Editor with the Microsoft Access DDL script

If you have Microsoft Access 2000 or later installed on your system, you can open the database to see that the User table has been created with the columns specified and the correct data types.

Reverse Engineering a Database

Reverse engineering is, as the name suggests, the reverse of forward engineering or code generation from a UML model. So, reverse engineering is when you create a UML model from an existing VS .NET project or even from an existing database. With VSEA, you do any reverse engineering from within the VS .NET IDE. With stand-alone Visio 2000 Professional and Enterprise Editions, Visio 2002 Professional Edition, and the Visio 2003 Professional Edition, you can do it from within Visio.

As an example, let’s try reverse engineering a database table. We’ll reverse engineer the Customers table from the Microsoft Access Northwind example database,⁷but you can just as easily choose to reverse engineer a copy of the Customers table from your own organization. In Exercise 1-16, make sure you replace the Microsoft Access Northwind bits with the setup for your desired data source.

EXERCISE 1-16

Open VEA (if it isn’t already open).
To create a new database model, select File -> New -> Database -> Database Model Diagram.
Start the reverse engineering by selecting Database -> Reverse Engineer. This brings up the Reverse Engineer Wizard, as shown in Figure 1-22.

Figure 1-22. The Reverse Engineer Wizard

   4. If you already have an ODBC DSN for the data source you want
        to reverse engineer a table from, select it from the Data
        Sources list and skip to step 13. If not, click the New button to
        create one. The Create New Data Source dialog box is now
        shown.

5. Select the System Data Source option and click Next.⁸

6. Select Microsoft Access Driver from the list and click Next.

7. Click Finish. The ODBC Microsoft Access Setup dialog box is now
shown.

8. Type Northwind in the Data Source Name text box.

   9. Click the Select button. This brings up the Select Database
        dialog box, which is really nothing more than the well-known
        Open File dialog box.

10. Browse to the Northwind.mdb database file on your system, or
        type in the name and path in the Database Name text box. It’s
        usually located in the Program Files\Microsoft Office\Office11
        \Samples folder (if you have Microsoft Office 2000 or Microsoft
        Office XP installed).

11. Click OK.

12. Click OK in the ODBC Microsoft Access Setup dialog box.

13. Click Next.

14. Click OK in the Connect Data Source dialog box, unless you
have specified a user name or a password for the database.

15. Remove the selection from the Views option on the database
objects review page of the Reverse Engineer dialog box and click
Next.

16. Select the Customers table on the database tables review page,
as shown in Figure 1-23.

Figure 1-23. The database tables review page of the Reverse Engineer Wizard

17. Click Finish. Your database model diagram is now updated with
the reverse-engineered Customers table, as shown in Figure 1-24.

Figure 1-24. The reverse-engineered Customers table on a class diagram

Summary

This chapter introduced you to enterprise modeling by means of one UML model that was used for generating a class (Logon) in VB .NET and C#, as well as a database model that was used for generating a small database with just one table (User) in Microsoft Access.

These two simple models were described in detail, and you saw how the two models were created and how the actual code and database were generated from within VEA. You also saw how you can reverse engineer an existing database into a database model diagram.

So why would you really want to use modeling for your enterprise solutions? Well, modeling is quick, and it saves a lot of the drudgery of repeated typing because of DDL scripts and the code skeleton generation. Modeling also serves as part of the solution documentation. Another important reason is that you reduce the risk of errors when data names and data types are transcribed between designs, databases, and application code.

The next chapter presents some guidelines for how to design and plan your projects and solutions.

1. A UML model is never really complete, meaning you can always find
    things that can be expressed in a more detailed way. Our intention
    in stating that a model can be complete or incomplete is that you
    can say it’s complete when all parties involved are satisfied that
    the information they want is contained in the model in the desired
    details. In other words, when it’s good enough to proceed to the
    next stage.

2. Rational Software was acquired by IBM, and the company is now
called IBM

3. If you have specified that VS .NET should open the last loaded
solution when opening, you can change that from the Options
dialog box, or you can manually open the generated code file.

4. The next version of VS .NET, code-named Whidbey, should be able
to handle unsigned data types. It is scheduled to be released
sometime in 2004.

5. Table is a physical database term, and entity is a conceptual
database term. You should keep this in mind, because Visio
sometimes seems to mix the two.

6. You can just as easily choose one of the other options, but for the
sake of this example, please follow the exercise.

7. The Northwind sample database comes with most versions of
Microsoft Access, but it’s also an optional setup part of Microsoft
SQL Server 2000.

8. You can just as easily choose one of the other options, but for the
sake of this example, please follow the exercise.