Visual Basic is great in that you can knock up a project with relatively little effort, especially if you use any of the myriad of wizards that Microsoft have so helpfully provided. There is a flip side though. Because we can code VB relatively easily, there's a tendency not to think about project design beforehand, but rather to do the design 'as we go along'... which is just a gentle way of admitting that no design work is going into the project at all. VB programmers can get away with this on small experimental applications, but when they move into more ambitious programs - and most particularly, into multi-tier application development - then it's a serious professional error to rely on such an ad hoc design approach.

Designing even a two-tier client/server application is scary enough though. This is when we really should begin to think about using UML. UML, as you will see throughout the book, provides an object-oriented method by which you, and others in your development team, can create a design for an effective, efficient application.

In this chapter we will cover:

• A definition of UML and why we would want to use it
• A brief introduction to some of the core UML diagrams we'll be using
• An overview of the whole UML design process
• How UML diagrams gradually define the project we're designing
• How Visual Basic and UML work together

From now on I will refer to the Unified Modeling Language as UML.

What UML Is (and what it is not)

As the programming community began to see that object-oriented programming (OOP) solved many of the problems of medium to large project development, it also became clear that there had to be some efficient, effective, uniform method of designing object-oriented projects.

UML is a set of standard models used to design an object-oriented project.

However, while UML does provide a mechanism that helps us to design object-oriented projects, it offers little in the way of help when it comes to coding the project.

UML does not describe the implementation of these models.

So there you have it: UML is a set of standard models to design object-oriented projects - but it is not a description of how to actually implement those models. We will be exploring the full meaning of this definition of UML throughout the book - but it's not a bad place to start.

Before we go any further, you might be considering this question: is UML the only set of standard models to help with OO programming? A brief history of UML will answer this inquiry, and also offer you an idea of the impressive credentials that UML has behind it as a practical tool.

A Brief History of UML

Over the past two decades, several modeling methodologies and languages have emerged, each having its own strength and weakness. The prominent methods have been:

• The Booch method
• Object Modeling Technique (OMT)
• Object-Oriented Software Engineering (OOSE)
• Coad-Yourdon and Fusion

In 1994, the three principal authors of Booch, (Grady Booch), OMT (James Rumbaugh) and OOSE (Ivor Jacobson) started the process of merging the three methods to form a Unified Modeling Language.

The Unified Modeling Language has since been developed by a consortium of companies led by Rational Software Corporation. In November 1997, UML 1.1 was certified as an industry standard by the Object Management Group (OMG).

Members of the OMG include almost all of the major software companies, including Microsoft, IBM, Computer Associates, Oracle, Sun, and Compaq. Such a strong industry alliance ensures that the UML is well accepted and implemented in the computer industry. Currently, many modeling tools such as Rational's Rational Rose support the UML.

What Exactly is a Model?

Let's dig a little deeper now about what UML actually is... so far, we've established that UML is a set of standard models that we use to design object-oriented programming projects. But what do we mean by a model, and what, accordingly, does that mean a modeling language is?

A model is a description of the problem we are set to solve. It simplifies the reality by capturing a subset of entities and relationships in the problem domain.

A problem domain describes not only a particular problem but also the conditions under which the problem occurs. It's therefore a description of a problem and the relevant context of that problem.

A model shows us what the problem is and how we are going to tackle it. We may use diagrams, text, or any other agreed form of communication to present the model.

Models visualize the system we are about to build.

A modeling language, therefore, is a language for describing models. Modeling languages generally use diagrams to represent various entities and their relationships within the model.

UML was created to fulfill these tasks:

• To represent all parts of a project being built with object-oriented techniques
• To establish a way to connect ideas, concepts and general design techniques with the creation of object-oriented code
• To create a model that can be understood by humans and also by computers - so that a computer can generate a major portion of the application automatically

UML accomplishes these tasks by having a series of different models. Each model represents a different view of the project. Some models are built from others, so there is a logical sequence in which the models are built.

Why Use UML?

Before we actually overview some of the details of UML and why it's so powerful, it's worth taking a moment to put everything we've discussed so far in context: why use UML?

I mentioned earlier that without employing a decent design method such as UML, most VB programmers will only really be able to develop programs in an ad hoc manner. This will, more often than not, lead to badly thought through programs and, ultimately, a lot of unsuccessful VB applications. We therefore need to use UML because it's a key to successful project design and development for us.

Many developers quickly feel overwhelmed when they try to build Enterprise level Visual Basic projects. These projects are difficult and complex. They not only require knowledge of how to program several different types of Visual Basic components, but also how to make these components work with server products, such as Microsoft Transaction Server (MTS), SQL Server (or other databases) and Internet Information Server (IIS).

As this book will show you, UML modeling is the key to being able to successfully build an advanced VB project - such as an Enterprise project. You will see how UML models help us to understand our user's requirements, then transform these requirements into a realistic project design, and finally help turn that design into the most efficient Visual Basic code possible... with the least amount of effort. These models will also cut down on overall costs and development time.

While UML is an essential tool for creating Visual Basic projects, it is only a part of a larger puzzle. In addition to understanding UML, a Visual Basic developer must:

• Understand the features of Visual Basic, and how these features integrate with server products
• Know how to apply these VB features to the design of the project
• Know how to turn their design into Visual Basic code

When we first try to put all of these pieces together in a Visual Basic project, we can easily get lost in the maze of components, programming techniques, and constraints of the system. From our very first steps into the world of UML, I will show you how UML models can create order out of this chaos. If you want to learn how to build Visual Basic Enterprise solutions in a rational, sane way, with a high probability of success, then this book is for you.

UML: The Key to Success

You may well be beginning to form a vague idea of how UML can help with our projects, but you may also be wondering how other areas of project management tie in with using UML.

There is a remarkably strong connection between UML and project management - please consider these three points:

• A successful object-oriented Visual Basic project is built on a foundation of good project management
• The foundation of good project management is thoroughly designing your project
• The foundation for good object-oriented design is UML

We shall discuss the concept of project management in detail in the next chapter. However, I wish to emphasize at this point that ultimately a successful VB project depends on using UML.

The Project Development Process

Although UML is the key to developing a project, it does not necessarily help in defining the actual process that we will be following. As you will see, project development is a circuitous, iterative process. It can essentially be divided into the following phases:

• Requirements Analysis
• Analysis
• Design
• Implementation - Coding and Testing

The analysis and design phases, especially, involve the use of UML diagrams.

VB and UML

The UML models and diagrams are powerful tools that we can use to build complex projects. Unfortunately, translating theory into reality sometimes is not so easy. UML was designed for languages that are completely object-oriented, and for users who are well versed in the theoretical aspects of software engineering.

Visual Basic approaches OOP from a slightly different approach from languages such as C++. Visual Basic users tend to be less interested in theory and more interested in application. Our presentation of UML will be geared to both the Visual Basic language and application development. To accomplish this, we will keep the explanations of UML simple and show how to apply each model to building a VB project. We will occasionally bend the models a little bit, but in the end, we will have a method that is specifically geared towards Visual Basic. Before we can move on there are two important questions that need to be answered:

• Does the Visual Basic programming language possess enough object-oriented features to be used with an object-oriented modeling language such as UML?
• Do Visual Basic Projects require good management practices such as modeling the project with UML?

Is Visual Basic an Object-Oriented Language?

The object-oriented programmer sees a software system as a set of objects that interact with each other.

An object is an abstraction of an entity in a problem domain. As in the real world, objects are related to each other and they also communicate with each other.

Whether Visual Basic can be considered an object-oriented language is a rather controversial topic. I will give you several arguments, which I hope will convince you that Visual Basic is object-oriented enough to make OOP projects, and that these projects can best be built using UML.

Technically speaking, an object-oriented language must include inheritance. As Visual Basic does not include inheritance, by this definition it is not object-oriented. Is this the end of the discussion? For some people it is, but I don't feel the discussion should end there.

Inheritance is a powerful tool that allows us to build many similar objects from one base class. For example, I can create a Dog, Cat and Rat object from a common Animal class. The Animal class will have properties such as Height, Weight, Color and methods such as Walk, Sleep, and Run. This relationship is called an is a relationship. A Dog is an Animal. A Cat is an Animal. Unfortunately, in VB we cannot make one base class (such as Animal) and use the identical class to create a Dog, Rat and Cat object.

However, we can get around Visual Basic's lack of inheritance by using object hierarchies. The lack of inheritance in the Visual Basic language does not prevent us from making objects that have an is a relationship, it is just more difficult to do so. Inheritance can have some problems, such as when an existing method or property in a base class has to be changed. Inheritance is often misused and is not the solution to every problem. While it would be nice to have inheritance in Visual Basic, it does not prevent us from making object-oriented components.

To demonstrate this let us focus on what these components are supposed to do, rather than the methods we use to build our object-oriented components. An object-oriented language must be able to build components that have the following properties:

• The component performs a specific task properly, efficiently and reliably
• The component is robust enough to work even under stressful or unexpected circumstances
• The component is maintainable and reusable
• The component can be built within budget, in a manner that is efficient and allows on-time delivery
• The component is completely self-contained (we can change the component without affecting the system the component is in)
• The component can perform different functions depending on how it is being used

Visual Basic components designed with UML models, and working under an Enterprise system that includes MTS, can be built with every one of those properties. I'm not going to say we will do this in the same manner as we would in a C++ program - I'll admit that sometimes we do have to get really creative to get VB components to do these things. Yet a properly designed VB component can do everything a component built from a true object-oriented language can do.

Because VB components can fulfill the requirements of an object-oriented component, I will treat Visual Basic as if it were an object-oriented language. You can form your own opinion. Hopefully, I have not offended you by saying that Visual Basic is object-oriented.

If you would like to learn more about objects and OOP, then I recommend you read "Beginning Visual Basic 6 Objects", (Wrox Press) for an introduction to object-oriented programming, and "Professional Visual Basic 6 Business Objects", also published by Wrox Press, for a more advanced discussion on using objects with VB6 in a business environment.

Do Visual Basic Projects Really Need UML?

Having presented my case for VB being sufficiently object-oriented to use UML, I will return to a key question: do VB programmers really need UML? I keep coming back to this question - because it's so important. I've already criticized the ad hoc design methods of many programmers, and stressed how essential it is to have a decent design approach behind all your projects. UML is perfect for that.

But now consider the following:

Project management is the most essential part of a successful Visual Basic project.

Regardless of the language used, most software projects are failures. A quick look at the statistics shows that one-third of all corporate software projects are cancelled before completion, and five out of six completed projects are unable to deliver the desired features. It doesn't have to be this way. This entire book focuses on showing you a coherent, clear way to manage an object-oriented Visual Basic project using UML. If you follow the methods outlined in this book, you can almost guarantee the success of your projects.