外文翻译-java设计和zOS的开发应用.doc

Designing and developing applications for z/OS8.1 Application designers and programmersThe tasks of designing an application and developing one are distinct enough to treat each in a separate textbook. In larger z/OS sites, separate departments might be used to carry out each task. This chapter provides an overview of these job roles and shows how each skill fits into the overall view of a typical application development life cycle on z/OS. The application designer is responsible for determining the best programming solution for an important business requirement. The success of any design depends in part on the designers knowledge of the business itself, awareness of other roles in the mainframe organization such as programming and database design, and understanding of the businesss hardware and software. In short, the designer must have a global view of the entire project. Another role involved in this process is the business systems analyst. This person is responsible for working with users in a particular department (accounting, sales, production control, manufacturing, and so on) to identify business needs for the application. Like the application designer, the business systems analyst requires a broad understanding of the organizations business goals, and the capabilities of the information system. The application designer gathers requirements from business systems analysts and end users. The designer also determines which IT resources will be available to support the application. The application designer then writes the design specifications for the application programmers to implement. The application programmer is responsible for developing and maintaining application programs. That is, the programmer builds, tests, and delivers the application programs that run on the mainframe for the end users. Based on the application designers specifications, the programmer constructs an application program using a variety of tools. The build process includes many iterations of code changes and compiles, application builds, and unit testing. During the development process, the designer and programmer must interact with other roles in the enterprise. The programmer, for example, often works on a team of other programmers who are building code for related application modules. When the application modules are completed, they are passed through a testing process that can include functional, integration, and system tests. Following this testing process, the application programs must be acceptance-tested by the user community to determine whether the code actually accomplishes what the users desire. Besides creating new application code, the programmer is responsible for maintaining and enhancing the companys existing mainframe applications. In fact, this is frequently the primary job for many application programmers on the mainframe today. While many mainframe installations still create new programs with COBOL or PL/I, languages such as Java have become popular for building new applications on the mainframe, just as on distributed platforms.8.2 Designing an application for z/OSDuring the early design phases, the application designer makes decisions regarding the characteristics of the application. These decisions are based on many criteria, which must be gathered and examined in detail to arrive at a solution that is acceptable to the user. The decisions are not independent of each other, in that one decision will have an impact on others and all decisions must be made taking into account the scope of the project and its constraints. Designing an application to run on z/OS shares many of the steps followed for designing an application to run on other platforms, including the distributed environment. z/OS, however, introduces some special considerations. This chapter provides some examples of the decisions that the z/OS application designer makes during the design process for a given application. The list is not meant to be exhaustive, but rather to give you an idea of the process involved:_ “Designing for z/OS: Batch or online?” on page 258_ “Designing for z/OS: Data sources and access methods” on page 258_ “Designing for z/OS: Availability and workload requirements” on page 258_ “Designing for z/OS: Exception handling” on page 259 Beyond these decisions, other factors that might influence the design of a z/OS application might include the choice of one or more programming languages and development environments. Other considerations discussed in this chapter include the following: _ Using mainframe character sets in “Using the EBCDIC character set” on page 265. _ Use of an interactive development environment (IDE) in “Using application development tools” on page 267. _ We discuss differences between the various programming languages in Chapter 9, “Using programming languages on z/OS” on page 275. Keep in mind that the best designs are those that start with the end result in mind. We must know what it is that we are striving for before we start to design.8.2.1 Designing for z/OS: Batch or online?When designing an application for z/OS and the mainframe, a key consideration is whether the application will run as a batch program or an online program. In some cases, the decision is obvious, but most applications can be designed to fit either paradigm. How, then, does the designer decide which approach to use?Reasons for using batch or online:_ Reasons for using batch Data is stored on tape. Transactions are submitted for overnight processing. User does not require online access to data._ Reasons for using online: User requires online access to data. High response time requirements.8.2.2 Designing for z/OS: Data sources and access methodsHere, the designers considerations typically include the following:_ What data must be stored?_ How will the data be accessed? This includes a choice of access method._ Are the requests ad hoc or predictable?_ Will we choose PDS, VSAM, or a database management system (DBMS) such as DB2?8.2.3 Designing for z/OS: Availability and workload requirementsFor an application that will run on z/OS, the designer must be able to answer the following questions:_ What is the quantity of data to store and access?_ Is there a need to share the data?_ What are the response time requirements?_ What are the cost constraints of the project?_ How many users will access the application at once?What is the availability requirement of the application (24 hours a day 7 days a week or 8:00 AM to 5:00 PM weekdays, and so on)?8.2.4 Designing for z/OS: Exception handlingAre there any unusual conditions that might occur? If so, we need to incorporate these in our design in order to prevent failures in the final application. We cannot always assume, for example, that input will always be entered as expected.8.3 Application development life cycle: An overviewAn application is a collection of programs that satisfies certain specific requirements (resolves certain problems). The solution could reside on any platform or combination of platforms, from a hardware or operating system point of view. As with other operating systems, application development on z/OS is usually composed of the following phases: _ Design phase Gather requirements. User, hardware and software requirements Perform analysis. Develop the design in its various iterations:High-level designDetailed design Hand over the design to application programmers._ Code and test application._ Perform user tests.User tests application for functionality and usability._ Perform system tests. Perform integration test (test application with other programs to verify thatall programs continue to function as expected). Perform performance (volume) test using production data._ Go productionhand off to operations.Ensure that all documentation is in place (user training, operation procedures)._ Maintenance phaseongoing day-to-day changes and enhancements to application.Figure 8-1 shows the process flow during the various phases of the application development life cycle.Figure 8-2 depicts the design phase up to the point of starting development.Once all of the requirements have been gathered, analyzed, verified, and a design has been produced, we are ready to pass on the programming The programmers take the design documents (programming requirements) and then proceed with the iterative process of coding, testing, revising, and testing again, as we see in Figure 8-3. After the programs have been tested by the programmers, they will be part of a series of formal user and system tests. These are used to verify usability and functionality from a user point of view, as well as to verify the functions of the application within a larger framework (Figure 8-4). The final phase in the development life cycle is to go to production and become steady state. As a prerequisite to going to production, the development team needs to provide documentation. This usually consists of user training and operational procedures. The user training familiarizes the users with the new application. The operational procedures documentation enables Operations to take over responsibility for running the application on an ongoing basis. In production, the changes and enhancements are handled by a group (possibly the same programming group) that performs the maintenance. At this point in the life cycle of the application, changes are tightly controlled and must be rigorously tested before being implemented into production (Figure 8-5). As mentioned before, to meet user requirements or solve problems, an application solution might be designed to reside on any platform or a combination of platforms. As shown in Figure 8-6, our specific application can be located in any of the three environments: Internet, enterprise network, or central site. The operating system must provide access to any of these environments. To begin the design process, we must first assess what we need to accomplish. Based on the constraints of the project, we determine how and with what we will accomplish the goals of the project. To do so, we conduct interviews with the users (those requesting the solution to a problem) as well as the other stakeholders. The results of these interviews should inform every subsequent stage of the life cycle of the application project. At certain stages of the project, we again call upon the users to verify that we have understood their requirements and that our solution meets their requirements. At these milestones of the project, we also ask the users to sign off on what we have done, so that we can proceed to the next step of the project.8.3.1 Gathering requirements for the designWhen designing applications, there are many ways to classify the requirements: Functional requirements, non-functional requirements, emerging requirements, system requirements, process requirements, constraints on the development and on the operationto name a few. Computer applications operate on data, which resides somewhere and which needs to be accessed from either a local or remote location. The applications manipulate the data, performing some kind of processing on it, and then present the results to whomever was asking for in the first place. This simple description involves many processes and many operations that have many different requirements, from computers to software products. Although each application design is a separate case and can have many unique requirements, some of these are common to all applications that are part of the same system. Not only because they are part of the same set of applications that comprise a given information system, but also because they are part of the same installation, which is connected to the same external systems. One of the problems faced by systems as a whole is that components are spread across different machines, different platforms, and so forth, each one performing its work in a server farm environment.An important advantage to the zSeries approach is that applications can be maintained using tools that reside on the mainframe. Some of these mainframe tools make it possible to have different platforms sharing resources and data in a coordinated and secure way according to workload or priority. The following is a list of the various types of requirements for an application. The list is not exclusive; some items already include others._ Accessibility_ Recoverability_ Serviceability_ Availability_ Security_ Connectivity_ Performance objectives_ Resource management_ Usability_ Frequency of data backup_ Portability_ Web services_ Changeability_ Inter-communicable_ Failure prevention and fault analysis外文翻译设计和z/OS的开发应用8.1应用程序设计者和程序员设计和开发一个应用程序的任务是不同的，足以对待每一个单独的教科书。在较大的z / OS的网站，独立的部门可用于落实各项任务。本章提供了这些概述工作角色并展示了如何安装到每一个技能的一个典型应用的总体看法发展在z / OS上的生命周期。应用程序设计者是负责确定最佳方案解决方案的一个重要的业务需求。任何设计成功取决于对设计师，业务本身，知识的一部分的认识政务主任在大型机组织的其他作用，如编程和数据库设计，业务，星光大道的硬件和软件的理解。总之，设计师一定要对整个项目的全局视图。在这个过程中涉及的另一个作用是商业系统分析师。这人与用户在某一个部门的工作负责（会计，销售，生产控制制造等）来确定业务需求的应用程序。像应用程序设计，业务系统分析员需要的组织，业务广泛的了解政务主任目标，以及信息系统的能力。收集的应用程序设计要求，从业务系统分析师和最终用户。设计者还决定将哪些IT资源用于支持应用程序。应用程序设计，然后写为应用程序员设计规范执行。应用程序程序员负责开发和维护应用程序。也就是说，程序员构建，测试，并提供了上运行的应用程序，为最终用户主机。基于应用程序设计人员，政务主任规格，构造了一个应用程序的程序员计划使用的各种工具。构建过程包括多次迭代代码修改和编译，应用程序生成和单元测试。在开发过程中，设计师和程序员必须互动在企业与其他角色。程序员，例如，往往在一其他程序员谁是团队建设相关的应用程序代码模块。当应用程序模块完成，他们是通过一个测试的过程，可能包括功能性，集成和系统测试。在此之后测试过程中，应用程序必须验收测试由用户社区，以确定是否完成的代码实际上是什么用户欲望。除了创造新的应用程序代码，程序员负责保持和加强公司，星光大道现有的主机应用程序。在事实上，这往往是许多应用程序员的主要工作大型机今天。虽然许多大型主机设备仍然可以创建新的方案使用COBOL或PL /我，如Java语言已经成为流行的建设新的应用程序在主机上，就像在分布式平台。8.2设计一个用于z / OS应用程序在早期的设计阶段，应用程序设计人员作出决定关于应用程序的特点。这些决定是基于很多标准，必须收集和详细研究在到达是可以接受的解决方案给用户。该决定是不是相互独立，另外，在这一项决定将会对他人的影响，所有决定都必须作出考虑到该项目和它的约束范围。设计一个应用程序运行在z / OS的股份很多遵循的步骤设计一个应用程序运行在其他平台，包括分布式环境。 z / OS上，不过，介绍了一些特殊的考虑。这本章提供了一些例子，决定在z / OS应用程序使得设计师在给定应用程序的设计过程。这份名单是不意味着要面面俱到，而是给你一个复杂的过程的想法：- “设计用于z / OS：批处理或在线？”258页- “设计用于z / OS：数据来源和访问方法”258页- “设计用于z / OS：可用性和工作量要求”258页- “设计用于z / OS：异常处理”259页超越这些决定，其他因素可能会影响排列设计/操作系统应用程序可能包括一个选择或多种编程语言和开发环境。其他考虑在本章讨论包括以下内容：式开发环境（IDE）在“使用应用程序开发工具“页267。_我们讨论不同的编程语言之间的差异第9章，“使用在z / OS的编程语言”页275。请记住，最好的设计是那些与最终导致启动头脑。我们必须知道它是什么，我们正在努力争取，才开始设计。8.2.1设计用于z/OS:批处理或在线当设计一个应用程序的z / OS和大型机，一个重要的考虑因素是，应用程序将运行批处理程序或在线方案。在某些情况下，决定是显而易见的，但大多数应用程序可以被设计为无论是典范。那么，如何决定是否设计者使用哪种方法？原因使用批处理或在线：使用批处理的原因：- 数据存储在磁带上。- 交易提交过夜处理。- 用户不需要在线访问数据。使用在线的原因：- 用户需要在线访问数据。- 高响应时间要求。8.2.2用于z / OS的设计：数据来源和访问方法在这里，设计师的考虑，一般包括以下内容：- 什么样的数据必须存储？- 数据如何被访问？这包括访问方法的选择。- 的要求是临时或预测的吗？- 我们会选择综合布线，VSAM的，或数据库管理系统（DBMS）如DB2？ 8.2.3设计用于z / OS：可用性和工作量需求对于一个应用程序，将运行在z / OS上，设计者必须能够回答下列问题：- 什么是存储和访问的数据量？- 什么是有需要共享数据？- 什么是响应时间要求？- 什么是该项目的成本限制？- 将有多少用户访问该应用程序在一次？- 什么是应用程序的可用性需求24小时7天一周或上午08点到下午5:00周一至周五等 8.2.4设计用于z / OS：异常处理是否有任何异常情况可能发生？如果是这样，我们必须结合我们在设计这些为了防止在最后的应用程序失败。我们不能总是假定，例如，输入将永远是进入预期。8.3应用开发生命周期：概述一个应用程序的集合是一个满足某些特定要求（解决一些问题）。该解决方案可以驻留在任何平台或平台的组合，从硬件或操作统点的观点。与其他的操作系统，应用程序开发在z /