This chapter starts an entirely new topic, which seems quite unrelated to the previous chapters. Applications are programs that do specific things like word processing, spreadsheet creation, or web browsing. Application development is the process of determining what a user needs an application to do, how to accomplish that in a program, and creating the program to meet the user's needs. The user in question may be the general public, or one or more people in a company who have a specific need for an application.
The text tries to explain that developing an application can be considered as two translations. This is better understood by looking at the figure on page 365.
So, in step 1 a request is generated. In step 2, analysts work with users to determine what a program would have to do to meet their needs. In step 3, analysts or programmers create a program. The text says that step 3 involves translating the user requirements from "natural language" to computer language. This is bit misleading. When the author says natural language, he really means the language that the requester speaks, or the language that the analyst speaks. Sorry, but no human language is any more "natural" than any programming language. The distinction is more that step 2 generates a description of what the program must do, and step 3 creates the program. It is common for programming texts to refer to the user's spoken or written language as natural language, so you need to understand what that phrase means. It is also common to refer to the output of step 2 as pseudocode, a symbolic expression of what the program does, as opposed to the actual programming language that the programmer will write.
The text refers to the System Development Life Cycle (SDLC), which it covered in chapter 1, a chapter that is not included in the plan for this class. A summary of the steps in the author's preferred version of the SDLC, the Unified Process, appears on page 366. It is the same summary that appears on page 3. If you do not recognize the basic steps in it, skim chapter 1 for a bit then come back here. What should you get out of the Unified Process diagram?
On page 366, the text talks about system developers using various models, tools, techniques, and processes to create systems. In this section, the text does not discuss the differences between those terms, or between any of the different models, tools, techniques, or processes that exist. In a few pages, it does discuss three types of tools.
Before we start that section, consider figure 10.5 on page 368. On the left side, it shows graphics for five requirements models, which are systematic ways of presenting what a client wants the system to do. In each example, one requirement is illustrated that flows from a customer placing an order to that order being shipped. None are too thrilling or surprising. Note that each illustration is more understandable once you know what it means. A lesson to take from this is that there are many ways to represent what a customer wants to happen in a system, and they are all good, if you understand them. You need to know which of the many modeling methods is to be used in the environment where you will work, so you can make acceptable and understandable documentation.
On the right side of that figure, we see five illustrations of details from design models. A design model depicts what the system being constructed will do. Note that the design model is less understandable if it is not paired with a requirement that makes it clear what is supposed to be happening. In a system development class, we typically study two or more popular models so you can recognize their notation and symbols, and so you can practice using them to become familiar with them. This chapter is an introduction to system development, however, not a course in it.
The text becomes confusing on page 369. All the author is doing is discussing the fact that there are many products we can call development tools, some of which support multiple models, and some of which are dedicated to specific models or languages. What does language have to do with it? The author is talking about programming languages. Languages can be considered tools all by themselves, while development tools that handle syntax problems for you are more automated than tools that simply produce programs from your typed input.
On the bottom of page 369, the author talks about creating programs. A programmer is a person who writes programs. The actual files created by a programmer can be called code or source code files. The code written by the programmer is called source code because it must be converted into another form for a computer to execute/run the instructions in it.
The O'Reilly publishing company, a technical book publisher, estimates that there are over 2500 different programming languages. It is beyond the scope of this chapter to discuss more than a few of them. Instead, the author discusses some common categories that refer partly to the decade in which a language was developed.
Generational Types for Programming Languages:
Other Types of Programming Languages
On page 378, the text begins a section that addresses the idea of compiling, and adds a related concept: the link editor. In the scenario described in the text, our programmer has written a source file in C++. C++ is one of the variants of the C language developed at Bell Labs many years ago. (If you haven't heard of them, follow the link. We owe them for a lot more than just the telephone.) The point about C in this case is that C is a compiled language, which makes heavy use of header and library files. These are files that hold lots of functions (code modules), already converted into executable code, that can be called (used) in any program you write in that language.
The way it works is pretty simple. You state which header and library files to compile with your program, and call the functions you need in the program. Call them? That means to write a line of code using the function. The function you are calling is not actually part of your program until you compile the source code and link it with the appropriate library or header file. (Why do I keep saying that? There is a difference, which is not really important now, but I am trying to be accurate.)
So how does the compiler know how to run the function? It doesn't. The compiler actually writes an intermediate file first, called an object file. The object file translates source code into machine language. It also contains placeholders for each call to an external function (a function that's defined in another file). The object file is handed to a program called the link editor, which looks for calls to functions that are not in the object file yet. The link editor searches each header, library, or other type file named in your code for the missing functions. When the link editor finds a copy of the necessary function, it copies it into the object code file, like a copy and paste operation. (Remember, functions in those external files are already stored in machine language.) After the substitutions are made, the final compile takes place, and you get an executable program.
The kind of linking described above is called static linking (page 386). The text contrasts this to dynamic linking, which keeps the library files separate from the executable files, and calls functions from those files, which are often dynamic link libraries (DLLs). The text tells us that dynamic linking has two main advantages. The first is smaller executable files, but this is an illusion because you still need the DLL files for the program to run. The other advantage is that you can update the DLL files without updating the entire program. This makes sense, but historically it has caused problems because one program would update a DLL that another made calls to as well, and suddenly the necessary functions were missing or incompatible as far as the second program was concerned.
The text talks in a good bit of detail about C and how a good program is structured. This discussion seems quite out of place in this text, since this is not a language class. We will move on to the next related topic.
If a program is written in a language that is not compiled, it is probably meant to be interpreted. Interpreted programs typically run slower than compiled programs because each line of code must be translated to machine language and fed to the processor at run time. In fact, the interpreter reads, translates, and runs each line before it moves on to the next line. If you have ever seen script files or batch files run in Windows, DOS, or UNIX, you have seen examples of interpreted programs. More elaborate interpreted languages can also contain calls to library files, causing them to need link editors as well.
Moving ahead to page 392, the text describes application development tools, generally sold as integrated suites of tools to carry out creation of source code, compiler or interpreter (as needed by the language being supported), a link editor and library files, user interface templates, debugging tools, and a common interface for all the tools in the suite.
The last topic in the chapter is CASE tools, computer-assisted software engineering tools. As the text points out, any application development tool is probably also a CASE tool, but often suites sold as CASE tools also include tools for modeling the user's requirements and the application design, which a more focused language tool might not have.