OBJECTIVES

In this chapter you will study:

• One-dimensional arrays;

• Two-dimensional arrays;

• Searching arrays; and

• Passing arrays as arguments.

This chapter shows you how to work with arrays. You will learn how to define and manipulate both single and multidimensional arrays. In this chapter, as in others, we will develop real working programs to illustrate using Java arrays.

NOTES

1. COBOL uses the terms single-level table; Java uses one-dimensional array.

2. In keeping with the spirit of Java, here we will use array and dimension.

This chapter begins with the declaration and population of one-dimensional arrays, then illustrates how to declare and populate two-dimensional arrays. The examples use both numeric and string data values.

The chapter also describes how to search an array using Java and how to pass arrays as arguments to methods.

You will see that, although internally Java treats array processing somewhat differently than COBOL, Java array handling looks a lot like COBOL table processing to the programmer. Of course, we will continue to point out significant differences between Java and COBOL and the pitfalls to avoid when writing Java from a COBOL programmer's perspective.

This chapter assumes you understand the following:

COBOL:

Defining one & two level tables

Initializing one & two level tables

Table lookup techniques

Using subscripts and indexes

Perform-varying statement

Java:

OO concepts (Chapter 2)

Java program structure (Chapter 3)

Defining data (Chapter 4)

Decision making (Chapter 6)

Looping (Chapter 7)

DECLARING ONE-DIMENSIONAL ARRAYS

We begin our discussion of one-dimensional arrays by looking at loan processing for the Community National Bank (CNB).

OBJECTIVES

In this chapter you will study:

• Object persistence;

• Sequential file access;

• SQL database access;

• Object serialization; and

• Network access.

This chapter introduces you to Java data access techniques using classes supplied in three packages: java. io, java. sql, and java. net. You are undoubtedly familiar with reading and writing files using COBOL. Java, however, takes a somewhat different approach, and therefore you will not find the clear parallels between COBOL and Java in this chapter that you have seen in the previous chapters.

Here we develop programs to demonstrate sequential file input-output (I-O) and database access. In addition we demonstrate a technique called object serialization used by Java to store intact objects in files for later retrieval. Although a demonstration of network access is beyond the scope of this book, we will present an overview.

The chapter begins with a brief description of the I-O classes contained in the java. io package and their hierarchy. Then, a relatively simple sequential file I-O demonstration is presented. Next we repeat the example using a relational database. Object persistence is then discussed and illustrated using Java's Object Serialization classes. The chapter concludes with a discussion of network access using classes in the java. net package.

OBJECTIVES

In this chapter you will study:

• Exceptions;

• Data types;

• Type casting;

• Wrapper classes;

• Arithmetic operators;

• The Math class; and

• The NumberFormat class.

The purpose of this chapter is to introduce you to Java computation. The basic arithmetic operators add, subtract, multiply, and divide (+, -, *, /) are the same as those we use in COBOL's COMPUTE statement. However, Java operations such as exponentiation (raising a value to a power) and rounding are accomplished using methods in the Math class. Java also has operators that enable us to write computation shortcuts if we wish.

Also, you will recall from Chapter 4 that Java is very particular about data types. This sensitivity is raised to a higher level when we do computation, as discussed more thoroughly in this chapter.

The chapter begins with a discussion of Java exceptions. An exception is Java's way of informing us of some condition that occurs while our program is running. While doing computation, for example, this could be an error like dividing by zero. Exceptions are not limited to arithmetic, however. You will see how exceptions are used to signal us about any condition, ranging from computation errors to hardware problems. In this chapter we will illustrate the use of custom exceptions using the familiar CheckingAccount class developed in Chapter 3.

OBJECTIVES

In this chapter you will study:

• while loop;

• do loop;

• for loop;

• Nested loops;

• break statement; and

• continue statement.

This chapter shows you how to write Java loops. You will learn how to write loops that mirror the familiar COBOL PERFORM statement including the PERFORM—UNTIL, PERFORM—VARYING—UNTIL and PERFORM—VARYING—UNTIL—AFTER. You will see that Java has three different types of loops: while, do, and for. We will use each of these to duplicate the work done by the COBOL PERFORM statement. In addition, we will review loops that test for the terminating condition at the beginning and at the end of the loop. We will also demonstrate writing nested loops in Java.

The chapter begins with the simple COBOL PERFORM—UNTIL statement and shows you how to accomplish the same thing in Java. Then we work with the PERFORM—VARYING—UNTIL and finally the PERFORM—VARYING—UNTIL—AFTER statement. Working programs are developed to illustrate the Java loop statements in action. At the end of the chapter, we design and develop a small program for the Community Naitonal Bank to compute a loan amortization, using some of the Java looping statements.

This chapter assumes you understand the following:

COBOL:

Perform-until

Inline perform (COBOL-85)

Perform-varying-until

Perform-varying-until-after

With test after (COBOL-85)

Java:

OO concepts (Chapter 2)

Java program structure (Chapter 3)

Defining data (Chapter 4)

Arithmetic (Chapter 5)

Decision making (Chapter 6)

LOOP STRUCTURE

We write program loops to repeat a sequence of instructions.

OBJECTIVES

In this chapter you will study:

• Conditions;

• Logical operators;

• if … else structure;

• Case structure;

• Java switch; and

• Java break.

In this chapter you will learn how to implement the selection and case structure using Java. You will see how to write if and switch statements. Java and COBOL if statements are very similar and therefore straightforward. However, switch is a distant cousin of the COBOL EVALUATE verb and has some similarities, but it also has many important differences, which will be discussed and illustrated in this chapter.

We will first examine the Java logical operators, conditions, and the if statement. This discussion includes the emulation of COBOL condition names using Java. Next we present the switch statement and explain its use. The chapter concludes with the development of a new method, computeServiceCharge(), for Checking Account. This method is first written using nested if statements, then written again using switch.

The chapter assumes you understand the following:

COBOL

Condition names

Logical operators

IF—ELSE—END—IF

EVALUATE

CONTINUE

Java

OO concepts (Chapter 2)

Java program structure (Chapter 3)

Defining data (Chapter 4)

Computation (Chapter 5)

SERVICE CHARGES AT COMMUNITY NATIONAL BANK

The Community National Bank system computes a service charge for each checking account each month.

OBJECTIVES

In this chapter you will study:

• The history of OO;

• What it means to be object-oriented; and

• Key object-oriented concepts.

This chapter is devoted to the introduction of the key concepts essential to your understanding of the OO paradigm in general and writing OO code in particular. This chapter describes the primary OO concepts: objects, classes, inheritance, encapsulation, polymorphism, and dynamic binding. A basic understanding of these ideas will enable you to begin writing Java programs and developing object-oriented systems.

Several examples are used throughout the chapter to illustrate the concepts. In most cases, the examples are based on everyday things with which you are already familiar. A case study (The Community National Bank Case) is introduced at the beginning of the chapter and will be used to illustrate OO concepts. The case study will continue to be used throughout the remainder of the book.

NOTES

1. OO development is a different way of thinking about the development of systems—it is not simply a programming technique.

2. Although programming languages were the first to utilize the ideas of OO, the concepts of OO are prevalent throughout all phases of development—analysis, design, and programming.

3. It is very important that you understand the basics of OO before attempting to write a Java program.

OBJECTIVES

In this chapter you will study the following:

• An overview and history of Java;

• Some unique characteristics of Java;

• Reasons for learning Java; and

• An overview of the book

So, you want to learn Java. Why? You probably want to for one or all of the following reasons:

• As a COBOL programmer you feel a need to update your skills;

• Java is hot and so are the jobs for Java programmers;

• Object technology is hot and Java fits perfectly with the object-oriented development your boss is requiring you to learn; and

• You are a naturally curious person who wants to see what this Java stuff is all about.

Whatever your reasons, we're glad you're here!

In this book, we place the emphasis on learning Java from a COBOL perspective. Of the several million COBOL programmers worldwide, a significant number are, or soon will be, learning Java. We have designed this book to help you with that task. We will take what you know about COBOL and apply as much of it as possible to learning Java. But first, let's learn a little about Java in general, nontechnical terms and about object-oriented development. Chapters 1 and 2, respectively, have been set aside for these purposes.

Why voice? Business communication is mostly about paperless paperwork, right? Computer workers like you and I stare intently at the computer screen for long hours, and by the end of the day are ready to kill the computer.

“A picture is better than a thousand words” applies only when it is not a picture of a thousand words that we read on our computer screens every day. Voice components bring some relief to our eyes and allow us to listen to text pages and even to talk back. (We talk more about speech recognition systems in Chapter 12.)

This chapter is about integration with voice components based on free, downloadable Java libraries. Voice components make even more sense in devices with small screens, or no screens at all.

The news watch is an example in which the voice component would be highly appreciated. Imagine a talking watch that delivers the news. Someone could use the screen option in a crowded place and the voice option in a better environment—for example, outdoors.

We add a voice component to the news watch at the end of this chapter. Right now, we take a closer look at synthesis technology.

WHAT IS THE BASE FOR CREATING A VOICE COMPONENT?

The free text-to-speech (FreeTTS) library was built by the Speech Integration Group of Sun Microsystems Laboratories as the first, though not complete, implementation of the Java speech application program interface (JSAPI) [1].

This chapter turns the smallest Java Virtual Machine (JVM) running on a smart card into a powerful key that can open all doors.

WHAT IS A SMART CARD?

Imagine a regular plastic card (often called “plastic”) with either a microprocessor and/or a memory chip embedded into the card. The microprocessor can manipulate information on the card, whereas a memory chip (e.g., the one in a prepaid phone card) can undertake only a predefined operation performed by a card reader.

Smart cards, unlike magnetic-stripe cards, do not require remote access at the time of the transaction; they can carry all the necessary functions and information right on the card. Today, there are three categories of smart cards: microprocessor, memory, and optical memory.

Microprocessor cards have an 8-bit processor, 16 KB of read-only memory, and 512 bytes of random access memory. Their processing power is similar to the first personal computers. These cards can perform cryptography algorithms and are used to access, hold, and otherwise manage digital money; provide secure access to computer and phone networks; secure set-top boxes; and perform other functions.

Memory cards, which can hold up to 1 to 4 KB of data, represent the bulk of the 600 million smart cards sold last year, primarily for prepaid, disposable card applications like prepaid phone cards. Card readers (also known as card-accepting devices) perform fixed operations (e.g., add, subtract, and delete) on memory cards.

Optical memory cards have a piece of (optical) compact disk glued on their surface. Up to 4 MB of data can be stored on the card, once and forever.

This chapter is about speech technologies and related APIs: VoiceXML, SALT, Java Speech API, and MS Speech SDK. It looks into unified scenarios with audio/video interface (AVI) definitions, considers design and code examples, and introduces important skills for a new world of wired and wireless speech applications.

WHAT IS A NATURAL USER INTERFACE?

Is a natural user interface (NUI) another set of tags and rules covered by a nice name? Absolutely not!

This time, end users—not a standards committee—make the determination on what they prefer for their methods of interaction. An NUI allows end users to give their preferences at the time of the service request, and to change them flexibly.

Are you a “computer” person?

My guess is that you are, because you are reading this book. “Computer literate” folks like you and me enjoy exploring the capacities of computer programs via traditional interfaces. Even so, there are times, such as when we are on vacation, on the go, and in the car, when we prefer “hands-free” conversation rather than using keyboards to access computerized services.

One person prefers handwriting, and someone else is comfortable with typing. One would like to forget keywords and use commonsense terminology instead. Can a computer understand that “find” is the same as “search,” and “Bob” is actually “Robert”? Can it understand that someone has chosen a foreign (non-English) language to interact with it?

“Write once and run everywhere” is one of the most important promises made by Java technology. Java Virtual Machines running on different platforms support this promise. With Microsoft's .NET initiative also you can write a program in C, C++, C#, Visual Basic, Perl, and so on. Then you can convert the program (with Visual Studio .NET) into the Microsoft intermediate language (MSIL) binary code that can be executed on any Windows platform by a virtual machine called the Common Language Runtime (CLR).

Unfortunately, the problem has many sides, and no technology by itself can help in every direction. Again, this is about the right development process coupled with the right technologies. What are the factors, other than language and compatibility problems, that prevent us from writing once?

When we try to use an existing service or application with a new environment, we find out that it does not fit. When business requires change and we want to adapt an existing product to that change, we find that there are no adaptation mechanisms in place. We realize that the basic properties, methods, and operations of the application are too specific to and too tight with the existing environment. The product has to be redone, often from scratch.

This chapter reveals the dependencies between a natural user interface (NUI) and knowledge technologies; discusses architecture, design, and code samples that integrate knowledge technologies into enterprise applications; and gives the keys to a new breed of software— “Softology,” a mix of software and ontological engineering.

We talked about NUIs in the previous chapter and agreed that they are not a trivial pursuit. We discussed at length a small part of an NUI—current speech technologies—and ended up with the conclusion that they can do a decent job when using machine-directed dialogs with multiple choices but are not quite ready to understand natural language spoken by a person.

We face similar difficulties with machine translation from foreign languages. I worked with multiple language translation programs that produced nonsense text filled with the right words.

WHY ARE COMPUTERS STUPID? WHAT IS MISSING?

Can tasks such as machine vision, speech recognition, and foreign language translation, which all seem very different, have a common solution?

The first common denominator is easy to find: all these tasks belong to the field of data interpretation. The next move is to find common steps for all three activities. What do people do when they are engaged in image or speech recognition, when they translate text from Hebrew to English? Why can't we build a program to perform similar steps?

The very first step is to recognize a business (social) domain area in which the data belong.

SOFTWARE ARCHITECTURE—THE CENTER PLACE OF SOFTWARE DEVELOPMENT

Software architecture is the highest level of a software system definition that can include subsystems with their own architectures. The main question is how deep one should go into the nested abstractions to define software architecture. The general answer is to stop right before implementation details that can be considered “private” parts of the design. More visible and exposed “public” containers, components, and connectors of the system with their run-time behavior and relationships comprise software architecture.

Software architecture has its own worlds of “what,” “why,” and “how”. The what world is mostly inhabited by industry standards, tools, and modules. The how world is about development process, design patterns, and architectural styles. The why world is a map between requirements criteria and the worlds of what and how. Design patterns [1, 2] and architectural styles [3] are very close by their nature but different in their scope and manners. Both are symbol names and concepts that describe approaches to common development problems.

Multiple architectural views work as light projectors helping us to see the systems from different sides by eyes of different parties interested in the product.

ARCHITECTURAL ELEMENTS, STYLES, VIEWS, AND LANGUAGES

Most of today's enterprise applications are built with object-oriented architecture, in which system components encapsulate data and behavior and communicate via messages.

Components, containers, and connectors are basic elements of the architecture.

In this appendix, you will find practical examples of how to:

• Start a collaborative service

• Read/write geographical data

• Use Java Naming and Directory Interface (JNDI) for multiple types of data sources, including domain name servers

• Share a screen with multiple users (great for troubleshooting and demos!)

• Use Java Media Framework (JMF) and Java Message Service (JMS)

• Create speech recognition and text-to-speech (TTS) applications in C#

• Spam and Spam Killers

• Improving efficiency and reliability of your email server

• Create a distributed knowledge systema and join educational/knowledge alliances.

These are the main targets, but the list can go on and on. You will find basic source examples in this appendix, and you can download more from this book's support Web sites at Cambridge University Press (www.cup.org/titles/ 0521525837.htm) and ITSchool, Inc.(www.JavaSchool.com).

GETTING INTO COLLABORATIVE SERVICES

Ben was always good with computers; some cosmic adventure games even followed him in his dreams. He was also very open to sharing or (using the impressive word) “collaboration.” He opened his first collaborative Web site when he was very young. He often had to stay home sick, and the site helped him to keep in touch with his kindergarten class. All his teachers and friends received his invitation-links to the site, except for Peter, a boy who never shared his piece of cake with anyone.

This appendix is a reference to Java, including the JDK1.5 and C# languages. In previous chapters, we discussed integration-ready and knowledge-connected environments that allow for writing application scenarios. In spite of the fact that most examples that support this method are made in Java, similar environments can be created with other languages. Life outside of Java is not as much fun, but it is still possible.

This appendix provides examples in which the same function is implemented not in Java but in its easiest replacement—the C# language.

This lucky child inherited good manners, elegance, style, and even some clothing from its stepfather while enjoying its mother's care and her rich, vast NETwork.

Java and C# are similar in their language structure, functionality, and ideology. Learning from each other and growing stronger in the healthy competition the siblings perfectly serve the software world.

JAVA VIRTUAL MACHINE AND COMMON LANGUAGE RUN-TIME

Java compilation produces a binary code according to the Java language specification. This binary code is performed on any platform in which a Java Virtual Machine (JVM) is implemented. The JVM interprets this binary code at run-time, translating the code into specific platform instructions.

C# compilation (through Visual Studio.NET) can produce the binary code in Common Intermediate Language (CIL) and save it in a portable execution (PE) file that can then be managed and executed by the Common Language Runtime (CLR).

Collaborative engineering is an important subject that is currently missing in schools, although some courses include a few of its aspects. I doubt I can cover it all at once, but I will try my best to integrate development technology and the development process under one roof, where integration-ready systems can be created.

Technology tends to fragment: to focus on pieces and omit the glue. The development philosophy that I associate with the terms of collaborative engineering helps keep a better balance between a narrow focus on particular components and their multiple connections to the rest of the world. The practice of collaborative engineering also assists in establishing a repeatable—yet flexible and constantly improving—development process. This is the foundation for integration-ready systems development.

What is collaborative engineering all about? It is about the development process in its organization, management, and methodology, integrated with innovative development technologies. I have had the privilege of teaching corporate developers and architects in the United States and overseas. Many times, I have had the amazing feeling that some of my brightest students, experienced developers, knew all the pieces of the puzzle and still could not start putting them together.

For example, almost every programmer knows one of the main design rules: Separate business from presentation logic. However, there are still more cases that break this rule than cases that follow it. One of the hardest questions is how to apply the rule properly.

One might think that the software industry is performing very well because it is armed with object-oriented approaches, Web services, Java and NET technologies, and so forth. Unfortunately, this is not true.

There may be something wrong with the way we write programs. The process has not changed much during the past twenty years, except that applications and tools are getting bigger. Yet are they better and more scalable? Do they require any common sense? Can they be reused in different circumstances?

If these things were true, I do not think we would be rewriting the address book, schedule, order, and inventory applications over and over again instead of moving to new, untouched tasks. We would be able to accumulate the professional knowledge gained by millions of knowledge workers (everyone who manages information flow on a daily basis) instead of routinely losing it, as we do today. We would also not be facing the current IT crisis.

We could even have had more precise and direct access to the market's supply and demand, which would have reduced the glaring inefficiencies of the software marketplace of the 1990s. A big change is required to return investors' confidence to IT, and, hopefully, the change is coming.

Yes, technology can help economic stability if applied with precision. Sometimes I wonder why big companies are constantly growing bigger while small ones tend to disappear.