Академический Документы
Профессиональный Документы
Культура Документы
I. Introduction
3. Assembly Languages
Characteristics of Java
Java has become enormously popular. Java’s rapid rise and wide acceptance can
be traced to its design and programming features, particularly its promise that you can
write a program once and run it anywhere. As stated in the Java-language white paper
by Sun, Java is simple, object-oriented, distributed, interpreted, robust, secure,
architecture-neutral, portable, high-performance, multithreaded, and dynamic.
1. Java is Simple
No language is simple, but Java is a bit easier than the popular object-oriented
programming language C++, which was the dominant software-development
language before Java. Java is partially modeled on C++, but greatly simplified and
improved. For instance, pointers and multiple inheritance often make programming
complicated. Java replaces the multiple inheritance in C++ with a simple language
construct called an interface, and eliminates pointers.
Java uses automatic memory allocation and garbage collection, whereas C++
requires the programmer to allocate memory and collect garbage. Also, the number of
language constructs is small for such a powerful language. The clean syntax makes
Java programs easy to write and read .Some people refer to java as “C++--” because it
is like C++ but with more functionality and fewer negative aspects.
2. Java Is Object-Oriented
You need an interpreter to run Java programs. The programs are complied into
the Java Virtual Machine code called bytecode . The bytecode is machine-independent
and can run on any machine that has a Java interpreter, which is part of the Java
Virtual Machine (JVM).
Most compliers, including C++ compliers, translate programs in a high-level
language to machine code. The code can only run on the native machine. If you run
the program on other machines, it has to be recompiled on the native machine. For
instance, if you compile a C++ program in the Windows platform. With Java, you
compile the source code once , and the bytecode generated by a Java compiler can run
on any platform with a Java interpreter. The Java interpreter translates the bytecode
into the machine language of the target machine.
5. Java Is Robust
7. Java Is Architecture-Neutral
8. Java is Portable
Because Java is architecture-neutral, Java programs are portable. They can be run
on any platform, without being recompiled. Moreover, there are no platform-specific
features in the Java language. In some languages, suck as Ada, the largest integer
varies on different platforms. But in Java, the range of the integer is the same on every
platform, as is the behavior of arithmetic. The fixed range of the numbers makes the
program portable.
9. Java’s Performance
CPU speed has increased dramatically in the past few years, and this trend will
continue. There are many ways to improve performance. Users of the earlier Sun Java
Virtual Machine certainly noticed that Java was slow. However, the new JVM is
significantly faster. The new JVM uses the technology known as just-in-time
compilation. It complies bytecode into native machine code, stores the native code,
and reinvokes the native code when its bytecode is executed. Sun recently developed
the Java HotSpot Performance Engine, which includes a compiler for optimizing the
frequently used code. The HotSpot Performance Engine can be plugged into a JVM to
dramatically boost its performance.
Java was designed to adapt to an evolving environment. New class can be loaded
on the fly without recompilation there is no need for developers to create, and for
users to install, major new software versions. New features can be incorporated
transparently as needed.
Software Life Cycle
A fundamental concept in software engineering is the software life cycle.
Software, like many other products, goes through a cycle of repeating phases(see
Figure 5A-1).
Software is first developed by a group of developers/programmers. Usually, it is
in use for a while before modifications are necessary. Modification is often needed
due to errors found in the software, changes in the rules or laws, or changes in the
company itself. The software should be modified before further use. These two steps,
use and modify, continue until the software becomes obsolete. By “obsolete,” we
mean the software loses its validity because of inefficiency, obsolescence of language,
major changes in the company, or other factors. Some examples of software
developments that normally go through this cycle are student registration systems,
billing systems, and accounting systems.
START
Yes
Obsolete
?
No
Stop
The development process in the software life cycle involves four phases:
analysis, design, implementation, and testing. Figure 5A-2 shows these phases as part
of the development process.
System Development
A software package may be designed for a generic user or a specific user. For
example, an accounting package may be created for use by any firm. On the other
hand, a customized banking package may be created for a specific bank. The user of
the package must be clearly defined.
After the user has been identified, the analyst clearly defines the needs. In this
step, the best answer comes from the user. The user, or the representative of the user,
clearly defines his/her expectations of the package.
Based on the needs of the user, the analyst can exactly define the requirements
for the system. For example, if a package is to print checks at the end of the month for
each employee, what level of security and accuracy should be implemented?
Finally, after the requirements are defined in clear terms, the analyst can choose
the appropriate methods to meet those requirements.
The design phase defines how the system will accomplish what was defined in
the analysis phase. In the design phase, the systems are determined, and the design of
the files and/or the databases is completed.
Today, the design phase users a very well-established principle called modularity.
The whole package is divided into small modules. Each module is designed and tested
and is linked to other modules through a main program.
The design phase uses several tools, the most common being a structure chart. A
structure chart shows how to break your package into logical steps; each step is a
separate module. The structure chart also shows the interaction between all the parts
(modules).
In the implementation phase, you create the actual programs.
This phase uses several tools to show the logical flow of the programs before the
actual writing of code. One tool, still popular, is the flowchart. A flowchart uses
standard graphical symbols to represent the logical flow of data through a module.
The second tool used by programmers is pseudocode. Pseudocode is part English
and part program logic that describes, in precise algorithmic detail, what the program
is to do. This requires defining the steps in sufficient detail so that conversion to a
computer program can be accomplished easily.
After production of a flowchart, pseudocode, or both, the programmer actually
writes the code in a language specific for the project. The choice of the language is
based on the efficiency of the language for that particular application.
Once the programs have been written, they must be tested. The testing phase can
be a very tedious and time-consuming part of program development. The
programmers are completely responsible for testing their programs. In large
development project, there are often specialists known as test engineers who are
responsible for testing the system as a whole——that is , for testing to make sure all
the programs work together.
These are two types of testing: black box and white box. Black box testing is
done by the system test engineer and the user. White box testing is the responsibility
of the programmer.
Black box testing gets its name from the concept of testing a program without
knowing what is inside it and without knowing how it works. In other words, the
program is like a black box that you can’t see into.
Simply stated, black box test plans are developed by looking only at the
requirements statement. This is why it is so important to have a good set of
requirements. The test engineer uses these requirements and his or her knowledge of
systems development and the user working environment to create a test plan. This
plan will then be used when the system is tested as a whole. You should ask to see
these test plans before you write you program.
Whereas black box testing assumes that nothing is known about the program,
white box testing assumes that you know everything about the program. In this case,
the program is like a glass house in which everything is visible.
White box testing is the responsibility of the programmer, who knows exactly
what is going on inside the program. You must make sure that every instruction and
every possible situation have been tested. That is not a simple task!
Experience will help a programmer design good test data, but one thing that she
can do from the start is to get in the habit of writing test plan. She should start her test
plan when she is in the design stage. As she builds her structure chart, she should ask
herself what situations, especially unusual situations, she needs to test for and make a
note them immediately. She may not remember an hour later.
When she is writing her flowcharts or pseudocode, she should review them with
an eye toward test cases and make notes of the cases she needs.
When it comes time to construct her test cases, she should review the notes and
organize them into logical sets. Except for very simple student programs, one set of
test data will not completely validate a program. For large-scale development project,
20, 30, or more test cases may need to be run to validate a program.
Finally, while she is testing, she will think of more test cases. Again, she should
write them down and incorporate them into her test plan. After her program is finished
and in production, she will need the test plans again when she modifies the program.