Project Standards
| The purpose of this section is to identify project- related issues that must be addressed before initiating any Java software development effort. The decisions made during this phase will determine the working environment for the Java developer. Delivery ExpectationsBefore any coding begins, you must know the answers to two questions:
The answers to these questions affect all Java-related product choices and development methodology decisions. The project objectives are derived through a business diagnosis study, which concludes with a recommendation that one or more business processes can be improved. This task is typically conducted with business analysts who understand the value proposition of the business domain under investigation. Note Only when you understand the value proposition of a business domain can you actually determine whether the proposition is being delivered efficiently . Once it is determined that a business process can be improved, a project team is formed to begin to assess what kind of business process re-engineering effort is required: social, technical, or a combination of the two. This effort is typically referred to as the Project Inception phase, where the objectives (mission) and feasibility of the project are reconciled. It is imperative for the project objectives to be declared in a clear and concise manner to avoid any misinterpretations by the recipient community who will be giving the green light to go ahead with the project. If the project is feasible , one of the deliverables of the Project Inception phase should be an initial draft of a project plan that explains at a very high level the tasks required to implement the objectives, as well as a ballpark timeline as to when the respective tasks and overall project will be completed. The actual timeline of the project is affected by two factors:
Note For a comprehensive review of methodologies that are best suited for Java software development, please see Chapter 2, "J2EE Software Development Methodologies." In essence the software methodology should be qualified by the business delivery requirements, and hence must be considered and selected before development starts. It is extremely valuable to follow an application development methodology from the beginning of a project because it is much more difficult to adopt a new methodology in the middle of a project. Only the new parts of the project will be following the methodology, whereas the other parts are under a different methodology, or are simply the result of ad hoc programming without any methodology. Note A process that accomplishes 90% of what you want and which everyone follows is better than one that achieves 100% of what you want and which no one follows . Java-Oriented Software ProductsMany factors come into play when choosing software products for a project. Primary among these factors is your company's existing environment and standards, and hence you may not have a choice in the product you use. Some of the other major factors include the following:
Note For a detailed list of J2EE project attributes, please see Chapter 1, "Understanding the Java 2 Platform, Enterprise Edition." When researching a product, ask colleagues for personal recommendations and join newsgroups to gather other opinions regarding a product. Find out, from the vendor or your other sources, about successful implementations where a product was used. If you still have questions about a product that is critical to your project, establish a working relationship with a training company specializing in the product. The trainers generally know the technology and can provide insights into its proper usage that you would obtain only through trial and error. Initially, it is good practice to list the types of products you will be considering within your Java development effort:
Note Please refer to the product vendors to verify the current version and release of these software products. After you have identified the products that will potentially be used in your development effort, gather the following information for each product:
This information will enable you to make intelligent choices about which versions of the products to use. In most cases, an evaluation copy of the product can be downloaded. You should contact the sales account managers from the product company to bring in the systems engineers to present or demonstrate the prospective products and show how the vendor's products all work together. You should be able to identify any compatibility issues, either now or in the near future, that could affect your delivery date. More importantly, you should be able to determine whether a vendor's planned release date, with a potential schedule slip, has an impact on your own critical path . Source Code Control and Software Build SystemsChoosing a software build and source control system are two very important decisions when starting a project. Many projects have these options determined by corporate standards. If you do not already have a source code control system and a software build process, do not underestimate the work involved in getting them in place and do not underestimate the negative impact on your project if you do a poor job. That said, allocate enough resources to create an easy-to-follow system for building and maintaining your source code. Your source code control system should work hand-in-hand with the procedures for performing system builds. When you have a working system, make sure to create instructions on how to set up and use the system. Provide cookbook instructions covering the day-to-day operations for developers. Also, create a dummy area in your source control system where developers trying to learn the system can practice without doing real damage. The idea is to simplify compiling and testing as much as possible for the developers. This issue is directly addressed by Integrated Development Environments (IDEs) for Java. For example, the Together ControlCenter design tool includes built-in support for building and packaging the application for a particular platform. If the command-line compiler is being used from the Java SDK, scripts or make files should be developed to ensure that the environment being used for the build is under version control. The development environment and version control systems are discussed later in this chapter. If you end up requiring the developers to use the make utility, provide build templates and a working demo. Be sure you cover other than the most trivial cases, as make 's error messages (or lack there of) are notoriously cryptic. A trivial application is one that contains all of its source code in a single directory. Enterprise applications are not trivial. Hence, the make file template must provide access to all the tools and libraries required by the developer. Directory Structures and Environment VariablesThe first step in software development, after at least an initial high-level detailed design, should be the creation of an environment for programming, compiling, testing, and running your applications. An environment at the most basic level consists of directories, control parameters (commonly called environmental variables), and programs. The programs are the software products you have chosen . These are usually installed in their own directory structures, with their own sets of environment variables. It is your task to create a development and runtime environment around these products. The directory structure should accommodate both the system and the individual developer's needs. The directories of the individual developers should mirror those of the project wherever possible. The importance of normalizing the directory structures is twofold:
Most source control systems will enable the developer to set his own working directory on his machine, and this can vary from one developer's machine to another. However, the directory structure under that working directory for a specific project should be mirrored against the structure in the source control system. Figure 4.1 shows a developer's configuration containing most of the necessary directories. Figure 4.1. The Java developer benefits from a logical and structured directory layout. You should note the following points about Figure 4.1:
It is important to become familiar with the development environment and the respective environment variables that can be used to customize your environment. The most important environment variables are PATH and CLASSPATH :
Note The version of the Java SDK also defines what core libraries are available. It is important that these variables do not contain references to obsolete or improper versions of the software. The following list provides instructions to identify the Java development environment on a Windows system:
set classpath Figure 4.3. Validating the version of the Java SDK and the type of JVM being used. Figure 4.4 shows the output from executing this command. Figure 4.4. Checking your CLASSPATH listings. Tip You can also verify the PATH and CLASSPATH settings by echoing the variables in your respective operating systems. Identifying the classes the Java Virtual Machine ( JVM ) uses when running a Java application is not so easy. You can use the -verbose switch on the JVM to list all classes that are being used. You then have to sift through the output to check the environmental setup. Because many projects have PATH and CLASSPATH variables pointing to every conceivable product and version of that product, its actually good practice to create operating system scripts that will set your environment variable settings on demand. Tip Know your development environment and only include the variable settings that you need. This means that you should know what Java SDK you intend to use and verify the PATH is set appropriately, and know what classes and JAR s you intend to use and verify the CLASSPATH is set appropriately. Typically, with proper size development, three environments should be set up: development environment, test and validation environment, and production environment. In the development environment, developers would develop on their own desktop or laptop. The database and application server used could be running locally in the developer's desktop/laptop or remotely in the development machine. Many companies have chosen to use Windows as the development environment on the developer's desktop/laptop. If a remote application server or database is used, they would be running in Windows or Unix. This is where unit testing should be performed. The test and validation environment should closely mirror the production environment in terms of hardware, OS, database and application server, and so on. This is where integration testing and validation is done. Typically, load testing and performance tuning is performed in this environment. The configuration of products used in the test environment are then very similar to the production environment. The Runtime Environment for Java Software DevelopmentYour project's software and application environment to a large part determines your runtime environment. However, there are other important considerations such as product configuration, performance tuning, security, networking, and so on. Because many of the runtime issues have to be considered and reconsidered throughout the lifetime of the project it is important that you start out as simple as possible and stage the introduction of complexities as you continue with your development. Java Namespaces and Directory StructureNamespaces, with their hierarchical framework, were invented to avoid naming ambiguities . A result of their hierarchical structure, they allow logical groupings of related parts. Namespaces are usually chosen to provide a functional decomposition of parts. In the end, the functional decomposition resolves the naming ambiguities. On the other hand, there are many classes in Java that have a very well-known API. Although namespaces will resolve conflicts, avoid using class names such as Vector, Hashtable, and so on, as they will only make the code harder to maintain. Note A company's organizational tree, with its company name, divisions, departments, and so on, is an example of a functional decomposition. In Java, namespaces are implemented using the package keyword. Every Java program file starts with a package statement. Note If the package name is omitted the default package is implicitly used. The package statement is composed of one or more strings delimited by a period ( . ). For example, java.awt. color is the package name for classes that control color in the Java Abstract Windows Toolkit. For most business applications, namespaces reflect the organization of a company. The company name is usually near the top of the namespace. Next are the departments, divisions, and projects. The remainder of the namespace usually describes the application and its functional components. In Java, the package name in a Java source file determines the relative on-disk location of the Java class files generated by the Java compiler. The Java compiler's -d option determines the root directory of the class file output. The hierarchy defined by the package name is used to store the class files. For example, the class files for a Java source file with a package name com.mycompany.tools resides in the directory com/mycompany/tools relative to the project's root directory. The full path of the parent directory of the com directory, for this example, would appear in the CLASSPATH . Note Sun recommends that you start the namespace with your company's Internet address in reverse order. For example, if your company's Internet address were mycompany.com , the first two elements of the package name would be com.mycompany . The Java package name also determines the relative runtime directory structure for Java class files. The relative runtime directory structure is identical to that created by the Java compiler. A Java program runs under the environment of the JVM. The JVM uses class files generated by the Java compiler. The class files are found either from the CLASSPATH environment variable or from the -classpath command line option. Either way, the JVM finds its classes in a directory tree whose structure is dictated by the Java namespace. There is another way the package name can be used to organize your Java environment. Although the package name does not impose any specific restrictions on the location of your Java source files, the way the Java compiler and the Javadoc utility work strongly suggests that source files reside in a directory with the same structure as the Java namespace. When Java source files are stored in a directory tree reflecting the package name hierarchy, it can perform dependent compilation. That is, it can find dependent source files, compare them with existing class files, identify those that are out-of-date and if necessary, recompile sources. The Java compiler can only use its make-like feature when Java sources are stored by their package names. In addition, the Javadoc utility only works properly if the source is stored according to the package name hierarchy. Note Be sure to place all non-inner classes in a separate file and use the class name as the file name. See the "Java Style Guidelines" in the next section. Also, see pages 170-171 in Core Java 2 Volume 1 by Horstmann and Cornell. In summary, namespaces resolve naming conflicts, logically separate Java files into functional units, determine the compile and runtime relative class file locations, and determine the relative location of the Java source files. Let's look at an example of how to use namespaces in an application. We want to build a foreign exchange application for a financial services company. The company name is FXBank and its Web site is fxbank.com. FXBank has a corporate standards group that has developed a number of common services (such as security, application logging, common functions, and constants) for all software projects within the bank. Our project name is unique within the company. Our project has developed a number of classes shared by programs within the project. We are working on the foreign exchange application that enables traders to book trades. During development, we have discovered that classes and methods , while not usable by the rest of the project, are referenced throughout our application. The Sun standard suggests that our package name begins with com.fxbank. The project name is Xtrader. The application we are writing is a trading kiosk or Kiosk for short. The package name at the application level is com.fxbank.xtrader.kiosk [i] . By following our recommendations, the namespace layout for package names, classes, and source files are the same. Figure 4.5 shows the namespace represented as a directory structure. Figure 4.5. The namespace represented as a directory structure. In this directory structure,
The data and configuration files should be stored in a hierarchy dictated by the Java package names. If you are using data or configuration files that need to be available at runtime, those files can be placed in your CLASSPATH . [ii] Tip These files should be copied from your config or data directories during application build. Don't keep them in the classes directory tree because during cleanup you generally delete all the files in these directories. Java programs have access to all files, not just class files, in their CLASSPATH . The following code snippets demonstrate how to read files from your CLASSPATH . The first snippet, given in Listing 4.1, opens a file, reads the first line, and then displays the result. Listing 4.2 demonstrates how to load a Java properties file into your program and then how to read the property value with a key of "database" . Both code snippets require that the file, test.config , be in the same directory as the class that is reading the file. Listing 4.1 Reading a File in the CLASSPATH BufferedReader br = new BufferedReader(new InputStreamReader( this.getClass().getResourceAsStream("test.config"))); System.out.println(br.readLine()); br.close(); Listing 4.2 Reading a Properties File in the CLASSPATH BufferedInputStream bis = new BufferedInputStream( this.getClass().getResourceAsStream("test.config")); Properties prop = new Properties(); prop.load(bis); System.out.println(prop.get("database")); bis.close(); In summary, choose a namespace that represents your organization and application and apply that pattern as a standard. |
For information about how to set up a WebLogic Server Java environment, 
EAN: 2147483647
Pages: 360