外文翻譯-java設(shè)計和zOS的開發(fā)應(yīng)用

1、 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 pro

2、vides 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 dep

3、ends 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

4、 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 system

5、s 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 a

6、pplication. 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 ru

7、n 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 pr

8、ocess, 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 th

9、at 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 respo

10、nsible 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

11、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 m

12、ust 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. Designin

13、g 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 desig

14、ner 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: Av

15、ailability 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 consid

16、erations 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 program

17、ming 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

18、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?Rea

19、sons 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:

20、 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

21、(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

22、 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

23、 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 co

24、llection 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 compose

25、d 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.Use

26、r 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.Ensur

27、e 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

28、 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, test

29、ing, 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

30、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 proc

31、edures. 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 pr

32、ogramming 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 sol

33、ution 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

34、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 o

35、ther 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

36、 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-func

37、tional 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 applicati

38、ons 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

39、 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

40、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 zSer

41、ies 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 variou

42、s 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_

43、 Changeability_ Inter-communicable_ Failure prevention and fault analysis外文翻譯設(shè)計和z/OS的開發(fā)應(yīng)用8.1應(yīng)用程序設(shè)計者和程序員設(shè)計和開發(fā)一個應(yīng)用程序的任務(wù)是不同的，足以對待每一個單獨的教科書。在較大的z / OS的網(wǎng)站，獨立的部門可用于落實各項任務(wù)。本章提供了這些概述工作角色并展示了如何安裝到每一個技能的一個典型應(yīng)用的總體看法發(fā)展在z / OS上的生命周期。應(yīng)用程序設(shè)計者是負(fù)責(zé)確定最佳方案解決方案的一個重要的業(yè)務(wù)需求。任何設(shè)計成功取決于對設(shè)計師，業(yè)務(wù)本身，知識的一部分的認(rèn)識政務(wù)主任在大型機組織的其他作用，如編程和數(shù)

44、據(jù)庫設(shè)計，業(yè)務(wù)，星光大道的硬件和軟件的理解?？傊O(shè)計師一定要對整個項目的全局視圖。在這個過程中涉及的另一個作用是商業(yè)系統(tǒng)分析師。這人與用戶在某一個部門的工作負(fù)責(zé)（會計，銷售，生產(chǎn)控制制造等）來確定業(yè)務(wù)需求的應(yīng)用程序。像應(yīng)用程序設(shè)計，業(yè)務(wù)系統(tǒng)分析員需要的組織，業(yè)務(wù)廣泛的了解政務(wù)主任目標(biāo)，以及信息系統(tǒng)的能力。收集的應(yīng)用程序設(shè)計要求，從業(yè)務(wù)系統(tǒng)分析師和最終用戶。設(shè)計者還決定將哪些IT資源用于支持應(yīng)用程序。應(yīng)用程序設(shè)計，然后寫為應(yīng)用程序員設(shè)計規(guī)范執(zhí)行。應(yīng)用程序程序員負(fù)責(zé)開發(fā)和維護(hù)應(yīng)用程序。也就是說，程序員構(gòu)建，測試，并提供了上運行的應(yīng)用程序，為最終用戶主機?；趹?yīng)用程序設(shè)計人員，政務(wù)主任規(guī)格，構(gòu)造了

45、一個應(yīng)用程序的程序員計劃使用的各種工具。構(gòu)建過程包括多次迭代代碼修改和編譯，應(yīng)用程序生成和單元測試。在開發(fā)過程中，設(shè)計師和程序員必須互動在企業(yè)與其他角色。程序員，例如，往往在一其他程序員誰是團隊建設(shè)相關(guān)的應(yīng)用程序代碼模塊。當(dāng)應(yīng)用程序模塊完成，他們是通過一個測試的過程，可能包括功能性，集成和系統(tǒng)測試。在此之后測試過程中，應(yīng)用程序必須驗收測試由用戶社區(qū)，以確定是否完成的代碼實際上是什么用戶欲望。除了創(chuàng)造新的應(yīng)用程序代碼，程序員負(fù)責(zé)保持和加強公司，星光大道現(xiàn)有的主機應(yīng)用程序。在事實上，這往往是許多應(yīng)用程序員的主要工作大型機今天。雖然許多大型主機設(shè)備仍然可以創(chuàng)建新的方案使用COBOL或PL /我，如J

46、ava語言已經(jīng)成為流行的建設(shè)新的應(yīng)用程序在主機上，就像在分布式平臺。8.2設(shè)計一個用于z / OS應(yīng)用程序在早期的設(shè)計階段，應(yīng)用程序設(shè)計人員作出決定關(guān)于應(yīng)用程序的特點。這些決定是基于很多標(biāo)準(zhǔn)，必須收集和詳細(xì)研究在到達(dá)是可以接受的解決方案給用戶。該決定是不是相互獨立，另外，在這一項決定將會對他人的影響，所有決定都必須作出考慮到該項目和它的約束范圍。設(shè)計一個應(yīng)用程序運行在z / OS的股份很多遵循的步驟設(shè)計一個應(yīng)用程序運行在其他平臺，包括分布式環(huán)境。 z / OS上，不過，介紹了一些特殊的考慮。這本章提供了一些例子，決定在z / OS應(yīng)用程序使得設(shè)計師在給定應(yīng)用程序的設(shè)計過程。這份名單是不意味著要

47、面面俱到，而是給你一個復(fù)雜的過程的想法：- “設(shè)計用于z / OS：批處理或在線？”258頁- “設(shè)計用于z / OS：數(shù)據(jù)來源和訪問方法”258頁- “設(shè)計用于z / OS：可用性和工作量要求”258頁- “設(shè)計用于z / OS：異常處理”259頁超越這些決定，其他因素可能會影響排列設(shè)計/操作系統(tǒng)應(yīng)用程序可能包括一個選擇或多種編程語言和開發(fā)環(huán)境。其他考慮在本章討論包括以下內(nèi)容：式開發(fā)環(huán)境（IDE）在“使用應(yīng)用程序開發(fā)工具“頁267。_我們討論不同的編程語言之間的差異第9章，“使用在z / OS的編程語言”頁275。請記住，最好的設(shè)計是那些與最終導(dǎo)致啟動頭腦。我們必須知道它是什么，我們正在努力

48、爭取，才開始設(shè)計。8.2.1設(shè)計用于z/OS:批處理或在線當(dāng)設(shè)計一個應(yīng)用程序的z / OS和大型機，一個重要的考慮因素是，應(yīng)用程序?qū)⑦\行批處理程序或在線方案。在某些情況下，決定是顯而易見的，但大多數(shù)應(yīng)用程序可以被設(shè)計為無論是典范。那么，如何決定是否設(shè)計者使用哪種方法？原因使用批處理或在線：使用批處理的原因：- 數(shù)據(jù)存儲在磁帶上。- 交易提交過夜處理。- 用戶不需要在線訪問數(shù)據(jù)。使用在線的原因：- 用戶需要在線訪問數(shù)據(jù)。- 高響應(yīng)時間要求。8.2.2用于z / OS的設(shè)計：數(shù)據(jù)來源和訪問方法在這里，設(shè)計師的考慮，一般包括以下內(nèi)容：- 什么樣的數(shù)據(jù)必須存儲？- 數(shù)據(jù)如何被訪問？這包括訪問方法的選擇

49、。- 的要求是臨時或預(yù)測的嗎？- 我們會選擇綜合布線，VSAM的，或數(shù)據(jù)庫管理系統(tǒng)（DBMS）如DB2？ 8.2.3設(shè)計用于z / OS：可用性和工作量需求對于一個應(yīng)用程序，將運行在z / OS上，設(shè)計者必須能夠回答下列問題：- 什么是存儲和訪問的數(shù)據(jù)量？- 什么是有需要共享數(shù)據(jù)？- 什么是響應(yīng)時間要求？- 什么是該項目的成本限制？- 將有多少用戶訪問該應(yīng)用程序在一次？- 什么是應(yīng)用程序的可用性需求24小時7天一周或上午08點到下午5:00周一至周五等 8.2.4設(shè)計用于z / OS：異常處理是否有任何異常情況可能發(fā)生？如果是這樣，我們必須結(jié)合我們在設(shè)計這些為了防止在最后的應(yīng)用程序失敗。我們不能總是假定，例如，輸入將永遠(yuǎn)是進(jìn)入預(yù)期。8.3應(yīng)用開發(fā)生命周期：概述一個應(yīng)用程序的集合是一個滿足某些特定要求（解決一些問題）。該解決方案可以駐留在任何平臺或平臺的組合，從硬件或操作統(tǒng)點的觀點。與其他的操作系統(tǒng)，應(yīng)用程序開發(fā)在z /