(This is a draft of chapters for a VB.NET text. I have added some comments related to C#. Please do not copy or otherwise propagate this material. It is copyrighted.)
· Programming languages have evolved over the years from low-level machine languages to high-level languages that allow development of programs with sophisticated and user-friendly graphical user interfaces.
· A program written in a high-level language must be translated to binary machine language.
This book is about a language. In particular, we will study the Visual Basic.NET programming language. Visual Basic.NET, or VB.NET, is called a programming language because it is designed to write programs, which are instructions that tell a computer what to do to solve a problem.
We all use language every day in many ways. In this book we use the English language to convey information and meaning. We know English has rules: spelling rules, punctuation rules, grammar rules, etc. English is a natural language, which means it evolved over history. That evolution has made the rules quite complex. Just look at the rules for making something plural: car becomes cars, city becomes cities, woman becomes women.
The VB.NET programming language is an artificial language. This means that a group of people carefully designed it. They specified the spelling, punctuation, and grammar rules for the language. The Visual Basic.Net language is small compared to English, and has well-organized rules. Even though these rules use the same ideas as English, they look somewhat different. In this book you will learn about these rules and how to use them to write meaningful "sentences" that the computer can understand and act on.
Visual Basic.NET is not the only programming language. Why study this particular language? To answer this question, let's fill in some background on programming languages in general.
Computers, whether they be big corporate machines servicing thousands of customers over the web, personal computers, laptops, or PDAs (Personal Data Assistants), are all electronic devices. To "speak to" one of these devices, we must use its own language. The English language uses an alphabet with many characters – the letters A through Z (both uppercase and lowercase), digits 0 through 9, and punctuation symbols. The language of the electronic devices uses a binary alphabet with only two symbols, 0 and 1. A binary alphabet is used because these electronic devices can represent 0 and 1 by, respectively, "low voltage" and "high voltage," whereas they could not represent the many characters of the English alphabet. To convey information to a computer in its own language requires translating everything into the computer's binary alphabet. For example, in the most widely used translation scheme, "B" is represented by 01000010 and "b" is represented by 01100010. Words, and even entire computer programs, are represented in the computer by combining such strings of 0s and 1s.
Imagine that you, as an English-only speaker, wish to communicate to someone who speaks only Spanish. Your message must be translated into Spanish so that your listener can understand it. Now, who does this translation? You might do it yourself, or you might hire a professional translator. A similar question arises when you want to communicate with a computer. You have a set of instructions written in English (or at least a restricted form of English). You want the computer to carry out those instructions, but the computer does not understand English instructions. Where does the translation of these instructions into the computer's binary language take place?
In the earliest days of writing computer programs (late 1940s), the programmer had to do this translation. All instructions - and all data on which those instructions operated - had to be written using strings of 0s and 1s, the only language the computer understands. Such machine language programming was tedious in the extreme. Imagine having to get long sequences of 0s and 1s exactly right! By the mid 1950s, the first high-level programming language had been invented. A high-level language allows much more English-like computer instructions, such as
If Temperature > 100 Then Print "Hot"
Even though the high-level language has its own rules, its additional expressive power allows the programmer to concentrate more on the big picture of what needs to be done to solve a problem. But ultimately, a program in a high-level language still has to be translated into its binary machine language equivalent. Another computer program called a compiler or an interpreter does this translation. In effect, the programmer has "hired a professional translator" to allow him or her to communicate with the electronic machine. Program instructions are often called computer code or just code, a term that reminds us that these programming language instructions will ultimately have to be translated – encoded – into binary form.
Many high-level programming languages have been developed, some designed for writing specific kinds of programs and others that are more general. The original BASIC (Beginner's All-purpose Symbolic Instruction Code) programming language was developed in 1963, making it one of the earliest high-level languages. The intention of BASIC, reflected in its name, was to make it an easy language so that programming could be done by virtually anyone. Over the years BASIC has gone through a number of transformations to make it a more modern and powerful language.
(The heritage of C# is from C and Java. As one of the .NET languages it can do whatever the other .NET languages can do. The syntax will be slightly different.)
Visual Basic, introduced in 1991, brought BASIC into the windows programming age. Windows-based programs present the computer user with screens or panes of information known as windows. There are certain standard features that all windows have. For example, the user can resize windows, open and close them, and move them around on the computer screen. In a windows-based program the user can usually cause certain actions to take place by clicking on icons or buttons, picking menu items, and so on. A windows-based program therefore presents the user with a graphical user interface or GUI (pronounced "gooey") as the means for interacting with the program. The ease with which programmers could write GUI programs using Visual Basic made Visual Basic one of the most widely used programming languages in the world. Several versions of Visual Basic appeared during the 1990s, adding additional capabilities to the language. VB.NET, introduced in 2002, is the latest Visual Basic version (see Figure 1.1). So that's how we got here – to VB.NET – but where exactly is "here"?
The key impetus for developing VB.NET is revealed in the name ".NET". VB.NET was developed with an eye toward writing programs for windows-based environments, including the ever-more-pervasive Internet. Let's explore what this means.
First, consider a typical windows program that you run on your personal computer at home, perhaps software to help you compute your personal income tax. (A computer program is often called software to distinguish it from the machine itself, which is called hardware.) The program's graphical user interface (GUI) may take you through a series of windows in which you are asked a question and you respond by typing information, such as your Social Security number or your previous year's income, into a text box. You may click a "radio button" to choose your filing status of single, married, or head of household. You may have toolbar buttons (or pull-down menu choices) that allow you to save your information or print your tax forms, perhaps jump to a section of the program that allows you to itemize deductions, or bring up a window showing some section of the tax law pertinent to the part of the form you are filling in at the time. This entire GUI is arranged before you so as to make your task as simple and efficient as possible.
What you see when you interact with this program is only the user interface – what might be called the presentation layer. It is what the software is designed to display to you, the user, to allow you to interact with it. Behind the scenes, so to speak, is where the real work of computing your taxes is done. Computer programming instructions allow the software to handle various tasks such as computing your allowable student loan deduction, your self-employment tax if you run your own business, and finally your tax bill plus the amount still owed or the amount of your refund. So the heart of the tax package software, the "engine" that makes it all work, is separated from the presentation layer. This "engine" is sometimes called the business logic – it's the part of the software that carries out the real work of this particular problem (completing your tax form). However, the software – both the presentation layer computer instructions and the business logic computer instructions - are housed on your personal machine.
These days, millions of people around the world connect to the Internet from their homes or workplaces. That certainly means there must be a computer at those locations. People can do useful work on those computers, such as word processing, computing their taxes, etc., without ever connecting to the Internet. But they may also use those computers to connect to the Internet to read e-mail, surf the web, order merchandise, or make travel reservations. Let's say you are placing an on-line order. Software on your computer (your Internet browser) again displays a presentation layer with facilities for you to specify the item you wish to purchase, the quantity, shipping address, etc. The merchant's business logic software – the part that actually processes your order – is not on your computer, but on a computer somewhere on the other end of your web connection. There are now two computers involved. There is a geographic, as well as a logical, separation between the presentation layer and the business logic, and your web connection allows information to flow back and forth between the two. The computer at your location is sometimes called the client, and the computer on the other end of the network (Internet) is often referred to as a server since it serves information to the client in the form of e-mail messages or web pages.
This configuration or architecture is called a client/server system. Consider the diagram in Figure 1.2. Some code operates on the client side (your machine) and some operates on the server side (the other machine). The advantage is that there need be only one instance of the server-side code, which is able to work with many instances of client code (one machine running the server code and many users with their individual client browsers connecting to make purchases).
There is actually a spectrum of client-server architectures. In Figure 1.3, the dashed line (the network or web) represents the separation between the client side (above the line) and the server side (below the line). On the left, part (a) shows the presentation layer and the business logic entirely on the client side. This was the case with your tax preparation software, that resided entirely on your machine. Or, you might be using a computer program that works with a large amount of data, and your database might also reside on your (client) computer – part (b) of Figure 1.3. Perhaps software on your machine accesses data stored on, say, your company server; this is represented in part (c) of Figure 1.3. Parts (a), (b), and (c) are sometimes called the "fat client" model because the majority of the work is done on the client.
Part (d) represents the scenario we talked about earlier, where the business logic and data management reside on the server for the on-line merchant while your client machine only displays the presentation layer sent from the server. This is called the "thin client" model because only the presentation layer is on the client.
(a) (b) (c) (d)
VB.NET is part of the Microsoft.NET Framework, which has been designed from the ground up with the Internet in mind, that is, for systems like the ones shown in Figure 1.3. This framework contains all the tools needed for software development for any part of this spectrum, but in particular is designed to facilitate the creation of presentation layers and business logic software that can work with each other across communication channels. Client/server web-based computing is only one instance of "distributed computing", where bits and pieces of computer code exist on geographically disbursed machines, or on machines owned by different companies that frequently do business together. Ideally, users of such distributed systems do not even need to know where these various pieces are located, much as you do not know or care where the web server machine is located when you make your on-line order. Again, the .NET Framework is designed to facilitate the development of distributed software.
In this book, we will primarily be concerned with programs that reside entirely on one computer, as in parts (a) and (b) in Figure 1.3, although we will look briefly at programming for a web environment in Chapter XXX. The programming principles and VB.NET instructions you will learn would carry over directly to programs for Web applications, but the infrastructure to support Web applications may be too complex to set up and use in a classroom environment. In this book, the separation of the presentation layer code and the business logic code – the user interface and the "engine" - will be an important concept because it represents the whole spirit of .NET programming, whether for single-machine windows applications ("win-apps") or for client-server web applications ("web-apps").
So in a nutshell, we are now prepared to answer the question of "why study VB.NET?" Because it is a powerful, high-level programming language equally at home in providing fat-client "win-apps" or thin-client "web-apps" solutions.
Several Big Ideas about programming will infuse the rest of this book. In this section we'll briefly describe these ideas, and you will encounter them again and again.
Our first idea has been mentioned before, namely the separation of a computer program into a presentation layer (user interface) and a business logic "engine". While this separation is required physically in the thin-client computing model, it is also a natural logical separation for windows-based programs that are housed entirely on a single client machine. As a result, many programmers consider it a "best practice" in approaching their programming tasks to separate these two parts of the program.
What the user sees in the GUI – the windows on the screen, the buttons, menus, etc., are the mechanisms by which the user interacts with the rest of the program.. And the "rest of the program" is where the real work gets done that pertains to the particular problem being solved. Of course, the presentation layer and the business logic must exchange information. Figure 1.4 shows the situation.
Each section of the program – the user interface and the business logic - conforms to its own standards. The user interface should be well-designed so that it is both pleasant and easy to use. "Pleasant" means that it should subscribe to good visual design (good use of color schemes, not a distracting jumble of items on the screen, etc.). "Easy to use" means that it should guide the user toward correctly and efficiently accomplishing the task at hand. In the tax preparation software, for example, the user should be led in a logical fashion to provide all the information required to compute the user's income tax. The business logic must conform to the rules of the enterprise that generated the problem to be solved. In the tax preparation software, for example, the current tax laws must govern the program's engine.
One consequence of this separation of "form and function" is that the user interface can be changed without affecting the business logic, and vice versa. The tax preparation software can substitute a new user interface for a user who speaks Spanish instead of English by just replacing the old interface with the new, provided the communication with the business logic works as before. And the business logic can be changed to correspond to changes in tax laws just by replacing the old engine with the new, again provided the communication with the user interface can remain the same. The user interface for next year's users of the tax package will be familiar.
The separation in Figure 1.4 is logical rather than the physical client/server (geographic) separation of Figure 1.2. This is a case where physical reality is emulated or modeled in the way we structure our program. But in fact, the entire purpose of a computer program is to model some segment of reality so as to be able to solve a problem about that reality. A tax software package models the reality of the tax laws, a business inventory control system models the reality of goods flowing into and out of the business, and a weather prediction program models the reality of temperature and air pressure. The computer is a "Universal Machine", one that we – through computer programs – can turn into a model of any reality we wish and can even extend into imaginary realms (for example, computer-generated special effects for movies).
A computer program is written to solve a particular problem. The quality of the program is dependent on how well it models the reality in which the problem is grounded, which means how well it translates the entities and relationships and interactions that are the elements of the problem into their logical counterparts within the program. How is this done? This brings us to our second Big Idea.
Current thinking in computer programming says we can begin to model reality by identifying the important things or entities involved in our problem. A thing could be tangible and physical, something you can see, touch, and feel. A thing could also be intangible, without physical form. So a thing could be a car or a person (tangible), or an invoice or a melody (intangible). Intangible things often have tangible representations – the sheet of paper on which an invoice is printed, or the page on which the musical notes for the melody are written.
When we talk or write about things, whether tangible or intangible, they are represented by the nouns in our sentences:
I washed the car.
The melody is beautiful.
How do we identify the important things in our problem? A problem statement may begin with the barest outline of the problem requirements, so devoid of details as to be wishful thinking. For example, we may learn that the problem to be solved is to "write a program for tax preparation." A much more detailed statement would be necessary in order to answer such questions as: is this for U.S. Federal income tax, for a state income tax, or for some other kind of tax? Should the program serve all taxpayers, or only those who can use the simple forms? Will the program track all income sources or only those from wages? Will it allow the taxpayer to itemize deductions? The original problem requirements statement may have to be refined more than once in order to arrive at a problem specification, a statement that includes all aspects that the program is supposed to manage. A problem specification for our tax problem might be: "Write a program to prepare tax forms for U. S. Federal income tax for all taxpayers. The program should track all income sources, allow for itemized deductions, and in every way conform to current U.S. tax laws."
If we have a thorough and complete problem specification, then simply picking out the nouns in the problem specification is a good way to begin to identify the important things involved in the problem. In the various situations described earlier, we might identify the following things:
Taxes: taxpayers, tax laws, income sources, deductions
Inventory control: goods that are stocked, shipping orders, shipments received
Weather prediction: temperature, barometric pressure, wind
Not only do we need to identify things, we also need to identify their important characteristics or attributes. What exactly do we need to know about a taxpayer or a shipping order, or a temperature? Do we need to know the taxpayer's Social Security number? Certainly. Do we need to know the color of the taxpayer's eyes? No – not in the context of the tax preparation program. Do we need to know the quantity of goods on the shipping order? Yes, in order to keep track of the amount of goods on hand in inventory. What do we need to know about temperature? We need to know what the value of the temperature is (78° F, perhaps) but we also need to know when and where that temperature occurred.
Identifying things and their attributes gives us a good snapshot of the "characters" in our little drama, but they are frozen on stage. In addition to this static information, we need to identify the dynamics that come about as these things interact with one another. The action of reducing the value of a deduction triggers the response of recomputing and increasing the current tax liability. The action of increasing the number of items to ship because of a new shipping order triggers the response of reducing the number of that item in inventory. And the action of a temperature change at a given place triggers a response that may affect the barometric pressure someplace else.
These concepts about the problem – things, attributes, actions, responses – carry rather directly into our conceptual model – the computer program – of the problem. Figure 1.5 shows the terminology we have been using and the corresponding technical terminology in the programming world. While we haven't defined these technical terms yet, just think of them for now as the analogies of their real world counterparts. VB.NET not only allows us to think in terms of objects, member variables, events, and methods, it requires us to do so. VB.NET is an object-oriented programming language.
(conceptual model of the real world)
Figure 1.5 The Real World and the Conceptual Model
We mentioned that certain things in our problem may respond to certain actions. The last Big Idea is that this action/response scenario also carries over directly into VB.NET programming. A program written in VB.NET is an event-driven program, meaning that objects in the program can be made to respond to certain events. For example, you might close a windows-based game program by clicking on an EXIT button. When you click that button, you cause a "click event" to occur on that button. The button is an object in the game program, and has been given instructions to respond to a click event by shutting down the game.
Event-driven programs proceed by a series of events and corresponding responses to those events. Figure 1.6 illustrates event-driven programming. After some start-up activities, the running VB.NET program enters a "wait loop," just sitting there waiting for the next event to occur to one of its objects and to which that object can respond if it has been instructed via computer code to do so. When execution of that code is complete, the program returns to its wait loop until the next event occurs. When no events occur, nothing happens (aside from the background wait loop, which repeatedly looks to see whether an event has just taken place). Eventually a termination event occurs that causes the program to stop.
Figure 1.6 Overall event-driven programming picture
Events are generally caused by the user, who clicks on a button or types into a text box or drags an icon across the screen. Therefore the user, by his or her actions, decides which events will occur and in what order they will occur. Let's assume that the user has generated an event and that the object experiencing that event has been given some code to respond to that event. The program then takes control of what happens next. However, once the activity programmed in response to that event is complete, the user again is in control.
These Big Ideas about programming will be clearer after you have looked at some actual VB.NET programs in later chapters.
· Running a windows-based program
· Identifying features of the GUI
· Recognizing business logic rules
Perform the following activities. You may want to check off each step as you complete it so that you don't lose your place. Space is also provided in which to write your answers to questions.
1. _____ Find the file SalesTax.exe and double-click to run the SalesTax program. This is a completed windows application program written in VB.NET. What you see is the running program, not the VB.NET code that makes it work.
2. _____ What is the program doing ? (The correct answer is not "nothing.")
3. _____ Enter an amount of 10.00 and click the "Compute Total" button.
4. _____ What appears for the Sales Tax?
_____ What appears for the Total?
_____ What do you believe is the tax rate this program is using?
5. _____ Click on the Tax Rate menu. Change the tax rate to 6%.
_____ Click the "Compute Total" button.
_____ What appears for the Sales Tax?
_____ What appears for the Total?
6. _____ The business logic of this program appears to be following two rules. What are they?
7. _____ Which object on the GUI for the Sales Tax program has been given code to respond to an event, and what is the event to which it responds?
8. _____ On the GUI for the Sales Tax program, there is a pull-down menu (Tax Rate), a button (Compute Total), and a text box for the user to enter the amount. In addition, there are 7 label objects on the GUI. Describe what they are.
9. ____ Close the Sales Tax program by clicking on the Close button in the far right of the title bar.
 Visual Basic.NET is a trademark of Microsoft Corporation
 To review and terminology, see Appendix A.
 Technically, as we will see, an event does not activate a response, it sends a message that activates a response.
 Technically, as we will see, a method is not a response, a method produces a response.