外文翻译系统的分析与设计.doc

《外文翻译系统的分析与设计.doc》由会员分享，可在线阅读，更多相关《外文翻译系统的分析与设计.doc（11页珍藏版）》请在三一办公上搜索。

1、系统的分析与设计系统在存储程序的控制下，计算机把数据处理成信息。对系统的定义略加思考，任何一个已知的计算机应用至少包含三个部分，硬件、软件和数据。仅仅编写程序是不够的，因为程序只是系统中的一部分。系统就是为实现一个目标而共同工作的一组部件。例如，考虑一个工资系统，它的目标是为雇员付工资，应包含哪几个部分呢？每天雇员们把他们工作的时数记录在计时卡上，每周末把计时卡收集起来，送给计算中心，在计算中心把计时卡上的数据读给工资程序。当工资程序执行时，程序存取数据文件。最后，打印出工资单，用来分发。为使系统工作，人、处理过程、输入和输出介质、文件、硬件和软件都必须认真地协调。注意，程序只是系统中的一部分

2、。系统分析 因为人们需要信息，所以要开发基于计算机的系统。被称为用户的那些人常常知道需求什么信息，但是他们可能缺乏得到这些信息的计算机的专门知识。计算机技术方面的专业人员，例如程序设计员有这方面的专门知识，但是可能在用户的专业领域内缺少训练。麻烦的是，用户和程序似乎常常讲不同的语言，导致了两者之间的联系障碍。系统分析员是一个专业人员，他能把用户的需求转换成计算机技术术语因此他是用户和技术人员之间的桥梁。像工程师建筑师一样，系统分析员把扎实的技术技能与见识，想象力和一点艺术结合起来去解决问题。 通常，分析员遵循一个意义明确的有条理的过程，至少包括以下几个步骤:1.问题的定义2.分析3.设计4.实

3、现5.维护在每个步骤结尾，研究的结果都要形成文件，提供给用户和程序设计员。 基本的思想是要尽早地抓住和修正错误以及一些未理解之处。 也许通过一个例子说明该过程是最好的方法。设想一个小服装店，成批的购买货物,所货物摆在货架上, 零售给顾客。 一方面,库存太多会造成不必要的开销；另一方面可供挑选的商品太少会使顾客失去购买的信心。 理想上，希望达到一个平衡，货物既充足但又不太多。麻烦的是，随着顾客的购买库存减少了，还有退货以及追加订货等情况，所以货物的清单经常地发生变化。店主喜欢按货物清单购销，刚好在商店售完某种货物之前，再订购这种货。对一项商品，该任务是容易完成的，只要计算一下手头现存的货物数量就

4、行了。遗憾的是商店要经营几百种不同的货物，始终跟踪每一种货物的销售情况是不实际的，也许计算机可以帮这个忙吧！问题定义在系统分析和设计过程中的第一步，是问题的定义。分析员的目标是确定用户需求什么。注意，当这个过程开始时，用户拥有很重要的资料，分析员必须认真地听和学。用户几乎都不是计算机方面的专家，他们大多数人把计算机看成魔术盒，并不关心它是如何工作的。在该阶段上，分析员不必考虑程序、文件或计算机硬件，但他们必须用用户自己的专业术语与用户对话。目的是确保用户和分析员两者都思考同一件事。因此，一份能表达分析员对问题理解程度的清晰的书面报告是必要的。用户应该反复地阅读和修改这份书面报告。此时是在时间、

5、金钱和精力被浪费之前抓出错误和疏漏的好时机。通常,接着初步的问题定义,分析员要进行可行性研究。该研究是整个系统分析和设计一个简略的方案,应力图回答以下三个问题: 1. 问题能解决吗?2. 在用户的环境下问题能解决吗?3.在一个合适的花费上问题能解决吗?如果这些问题中的任何一个得到的是否定回答,那么该系统就不应开发。有了好的问题定义和肯定的可行性研究, 分析员就能着手计划和研究问题的解了。分析当分析开始时，分析员要理解问题，下一步要决定的是为了解决问题必须做什么。用户清楚必须做什么。在分析阶段得到了这方面知识，并正式地形成文件。大多数用户是按着所要完成的功能和要处理的数据元素去思考的，目的是要区

6、分并联接这些关键的功能和数据元素，随之产生逻辑系统设计。从系统的基本功能入手，关键是始终监视货单中每种商品的现存量。因为顾客购买、换货和退货，所以货单要改变，因此系统必须处理顾客办理的手续。店主希望有选择地查看供应中任意一种短缺商品的清单，如果合理的话，定货补充库存，因此系统必须能和经营管理部门对话。最后，经过经营管理部门的核准，系统应该产生一个重新订货单，准备发送给供应商。已知了系统的基本功能，分析员的下一个任务是分析理解这些功能之间逻辑关系的知识。启动这项工作的一个好方法是描述功能之间的数据如何流动。顾名思义，为了用图解方法描述这些数据流，那么数据流程图就是特别有用的。四种符号：数据的源和

7、目的地用方框表示，输入的数据从源进入系统，而输出的数据流到目的地。数据一进入系统，就被若干进程加工或改变，用圆角的矩形表示这些过程。进程可以是程序、过程以及能够改变或传送数据的任何事件。为了后续处理，数据被存储可以是磁盘文件、磁带文件、数据库、一些笔记或者甚至是人的记忆。最后，数据源、数据目的地、处理过程和数据存储之间的数据流向用箭头表示。货单管理系统的初步的数据流程图。从CUSTOMER（顾客）开始，由此事务进入系统，在这所办理的手续由PROCESSTRANSACTION（事务处理程序）处理。STOCK保存货单中每项商品的数据。为了对新的事务处理起作用，事务处理程序要改变数据。同时，MANA

8、GEMENT（经营部门）可通过COMMUNICATE（通信）存取系统，检查STOCK中的数据，如果需要的话，请求重新订货。订货单一经核准，GENERATEREORDER（产生再订货单程序）就向SUPPLIER（供应商）发出需要的数据，供应商就把货运送到商店。注意，因为订货表现为某种待定的商品或某些商品在清单中的变化，所以把订货作为事务处理。数据流程图描述了逻辑系统。下一步追溯该系统的数据流向了。从数据的目的地SUPPLIER开始。例如，重订货单送给了供货商们，商店可能想要25条工作裤，为了填写订货单，供应商需要商品的说明和再订货的数量，那么，这些数据从什么地方来呢？由于数据是Generate

9、reorder输出的，所以既要有数据输入给它，还要有数据经过它的处理而产生。数据从STOCK流入Generate reorder，因此商品说明和订货数理必定存放在STOCK中。另外一些数据，例如购买的货物品种和数理由CUSTOMER产生。还有一些数据，例如销售价格和订货点由MANAGEMENT产生，或者由它提出要求。例如，某种已知货物的现存量就是由某个处理过程中的某种算法产生出来的。分析员逐步地、有条理地区分了系统要求输入、存储、处理、产生或输出的应该分别是哪些数据元素。为了记录数据元素，分析员必须把每个数据列在数据字典内。简单的数据字典可建立在索引卡片上，但计算机化的数据字典已经变得日益流行

10、了。数据字典是描述和定义数据的一个数据集合，不仅在整个系统的分析与设计过程中有用，而且在实现阶段经常被用来建立数据库。分析阶段的目标是定义系统的主要功能和有条理地确定数据元素。记住，它的目标是把用户的需求转换成技术术语。因为系统是由用户提出的，所以首先要确定用户的需求。用户只是从功能和数据出发考虑系统，他们并不具体设计程序、文件、和硬件，并且在这个初始的带有决定性的分析阶段，分析员必须像用户而不像程序设计员一样去思考问题。这是该阶段的基本要求。数据流程图和数据字典是有用的工具。这些工具为记录用户系统的关键信息提供了一种格式。还有，这些工具可帮助唤醒分析员的记忆。例如，如果分析员没有足够的信息使

11、数据字典的条目完整化，那么分析员就可能丢失一些内容。也许，数据流程图和数据字典为分析员理解系统的需求提供了最重要的文件，通过查阅这些文件，用户能改正误解或疏忽大意。最终，这些有用的工具对下一步设计阶段，奠定了一个良好的基础。设计当进入设计阶段的时候，已知道必须做什么事。因此可以开始考虑系统如何完成这些事。目标是研究出解决问题的策略。在该阶段上，对写代码或确定精确的数据结构并不感兴趣，而是希望从整体上确定整个系统所需要的程序、文件、过程和其它一些部分。数据流程图确定了系统的必须具有的功能，如何才能实现这些功能呢？一种可能性是为每个处理过程写一个程序；另一种可能性是把两个或更多的处理过程合并在一个

12、程序里，因而有几十种可能的方案。让我们集中在一种选择上并为它提供一些详细的资料。系统流程图用符号表示程序、过程、硬设备及物理系统中的其它部件。流程图表明，通过终端进入系统的事务数据被数据采集程序处理，然后存放在货单文件上。最后，货物清单文件由一个Report and reorder（报告和再订货）程序处理。经营部门用该程序处理数据和核对订货单。请看系统流程图，它指明了若干硬部件，其中包括一台计算机、一个磁盘驱动器、一个数据输入终端、一台打印机和一个显示终端等；还需要两个程序，事务处理程序和报告与再定货程序；除了硬件和程序以外，我们还需要货单文件以及IO设备与软件之间数据流的数据结构。注意，本系

13、统的流程图只说明一种可能的方案。一个好的系统分析员在他选定一个方案之前要研究出若干个可行的方案，以备替换。流程图拟订了系统，突出了系统的主要物理部件。因为数据链接了部件，所以接下来的工作就是确定数据结构。以货物清单文件为例，它包含来自STOCK的所有数据元素，这些数据元素被列在数据字典中。利用这些数据元素能安排文件的数据结构。如何组织文件呢？这取决于如何访问它。例如，在某些应用中数据是在有规律的预定时间内被处理，一般是整段时间收集数据，成批结一起处理。如果可采用批处理的话，那么一个顺序文件结构可能是最好的了。然而，不可能总是等到一批事务都被收集好以后再去处理。例如，设想一个防空预警系统，如果一

14、个不明的飞行物被标定了位置，就必须立即分辨它。因为防空程序下午五时才运行，要等到那时才处理的思想是荒谬的。该种情况要求快速响应，每个事务必须在它发生时得到处理。一般来说，这些事务处理系统要求直接存取文件。我们的货单系统有两个程序，一个事务处理，直接存取货单文件似乎是个合适的方案；另一个为经营部门偶尔分析货物清单数据用，当然批处理就能完成了。货物清单文件应按顺序组织还是直接组织呢？面对着这种选择，一个好的系统分析员应考虑两种方案。一种可能的系统是当事务一发生就接收并处理该事务；另一种可供选择的方案是可整天的收集销售单，商店关门以后，成批地处理。在第一个系统中，这两个程序应处理直接存取文件；在第二

15、个系统中，这两个程序应链接到顺序文件上。处理可直接访问的数据的程序和处理可按顺序一个接一个访问的数据的程序是不同的。数据驱动了系统，所以数据结构的选择决定了程序的结构。注意，程序在系统的意义上被定义和规划。实现系统的主要部分一分析清楚了，就能开始开发这几部分。本系统包括两个程序、若干台设备和大量的数据结构。在实现阶段，每个程序都用在所描述的技术来编排和书写；要建立文件并检查文件的内容；购买、安装和测试新的硬件；另外还要写出操作步骤，并对系统做出评价。所有的部分都准备好了，就调试系统。若用户满意了，系统就交付使用。维护系统交付以后，维护就开始了。当人们使用系统时，他们将提出一些小的改善和提高。有

16、时在调试和检测阶段一些缺陷被忽略了，那么修改程序，例如，政府通过了一个法律，修改了征收所得税的方法，则工资程序就必须修改。维护延续在系统的整个生命期内。维护的费用和初期的研制费用差不多，甚至更高。良好的计划、实用的文件资料和合适的程序结构都有助于减少维护费用。Systems Analysis and DesignSystemsWorking under control of a stored program, a computer processes data into information. Think about that definition for a minute. Any giv

17、en computer application involves at least three components: hardware, software, and data. Merely writing a program isnt enough, because the program is but one component is in a system.A system is a group of components that work together to accomplish an objective. For example, consider a payroll sys

18、tem. Its objective is paying employees. What components are involved? Each day, employees record their hours worked on time cards. At the end of each week, the time cards are collected and delivered to the computer center, where they are read into a payroll program. As it runs, the program accesses

19、data files. Finally, the paychecks are printed and distributed. For the system to work, people, procedures, input and output media, files, hardware, and software must be carefully coordinated. Note that the program is but one component in a system.Systems AnalysisComputer-based systems are developed

20、 because people need information. Those people, called users, generally know what is required, but may lack the expertise to obtain it. Technical professionals, such as programmers, have the expertise, but may lack training in the users field. To complicate matters, users and programmers often seem

21、to speak different languages, leading to communication problems. A systems analyst is a professional who translates user needs into technical terms, thus serving as a bridge between users and technical professionals.Like an engineer or an architect, a systems analyst solves problems by combining sol

22、id technical skills with insight, imagination, and a touch of art. Generally, the analyst follows a well-defined, methodical process that includes at least the following steps:Problem definitionAnalysisDesignImplementationMaintenanceAt the end of each step, results are documented and shared with bot

23、h the user and the programmers. The idea is to catch and correct errors and misunderstandings as early as possible. Perhaps the best way to illustrate the process is through example.Picture a small clothing store that purchases merchandise at wholesale, displays this stock, and sells it to customers

24、 at retail. On the one hand, too much: stock represents an unnecessary expense. On the other hand, a poor selection discourages shoppers. Ideally, a balance can be achieved: enough, but not too much.Complicating matters is the fact that inventory is constantly changing, with customer purchases deple

25、ting stock, and returns and reorders adding to it. The owner would like to track inventory levels and reorder any given item just before the store runs out. For a single item, the task is easy-just count the stock-on-hand. Unfortunately, the store has hundreds of different items, and keeping track o

26、f each one is impractical. Perhaps a computer might help.Problem DefinitionThe first step in the systems analysis and design process is problem definition. The analysts objective is determining what the user needs. Note that, as the process begins, the user possesses the critical information, and th

27、e analyst must listen and learn. Few users are technical experts. Most see the computer as a “magic box,” and are not concerned with how it works. At this stage, the analyst has no business even thinking about programs, files, and computer hardware, but must communicate with the user on his or her o

28、wn terms.The idea is to ensure that both the user and the analyst are thinking about the same thing. Thus, a clear, written statement expressing the analysts understanding of the problem is essential. The user should review and correct this written statement. The time to catch misunderstandings and

29、oversights is now, before time, money, and effort are wasted.Often, following a preliminary problem definition, the analyst performs a feasibility study. The study, a brief capsule version of the entire systems analysis and design process, attempts to answer three questions:1. Can the problem be sol

30、ved?2. Can it be solved in the users environment?3. Can it be solved at a reasonable cost?If the answer to any one of these questions is no, the system should not be developed. Given a good problem definition and a positive feasibility study, the analyst can turn to planning and developing a problem

31、 solution.AnalysisAs analysis begins, the analyst understands the problem. The next step is determining what must be done to solve it. The user knows what must be done; during analysis, this knowledge is extracted and formally documented. Most users think in terms of the functions to be performed an

32、d the data elements to be manipulated. The objective is to identify and link these key functions and data elements, yielding a logical system design.Start with the systems basic functions. The key is keeping track of the stock-on-hand for each product in inventory. Inventory changes because customer

33、s purchase, exchange, and return products, so the system will have to process customer transactions. The stores owner wants to selectively look at the inventory level for any product in short supply and, if appropriate, order replacement stock, so the system must be able to communicate with manageme

34、nt. Finally, following management authorization, the system should generate a reorder ready to send to a supplier.Given the systems basic functions, the analysts next task is gaining a sense of their logical relation. A good way to start is by describing how data flow between the functions. As the n

35、ame implies, data flow diagrams are particularly useful for graphically describing these data flows. Four symbols are used. Data sources and destinations are represented by squares; input data enter the system form a source, and output data flow to a destination. Once in the system, the data are man

36、ipulated or changed by processes, represented by round-corner rectangles. A process might be a program, a procedure, or anything else that changes or moves data. Data can be held for later processing in data stores, symbolized by open-ended rectangles. A data store might be a disk file, a tape file,

37、 a database, written notes, or even a persons memory. Finally, data flow between sources, destinations, processes, and data stores over data flows, which are represented by arrows.Preliminary data flow diagram for the inventory system. Start a CUSTOMER. Transactions flow from a customer into the sys

38、tem, where they are handled by Process transaction. A data store, the STOCK, holds data on each item in inventory. Process transaction changes the data to reflect the new transaction. Meanwhile, MANAGEMENT accesses the system through Communicate, evaluating the data in STOCK and, if necessary, reque

39、sting a recorder. Once a reorder is authorized, Generate reorder sends necessary data to the SUPPLIER, who ships the items to the store. Note that, because the reorder represents a change in the inventory level of a particular product or products, it is handled as a transaction.The data flow diagram

40、 describes the logical system. The next step is tracing the data flow. Start with the destination SUPPLIER. Reorders flow to suppliers; for example, the store might want 25 pairs of jeans. To fill the order, the supplier needs the product description and the reorder quantity. Where do these data ele

41、ments come from? Since they are output by Generate reorder, they must either be input to or generated by this process. Data flow into Generate reorder for STOCK; thus, product and reorder quantities must be stored in STOCK.Other data elements, such as purchased and the purchase quantity, are generat

42、ed by CUSTOMER. Still others, for example selling price and reorder point, are generated by or needed by MANAGEMENT. The current stock on-hand for a given item is an example of a data element generated by an algorithm in one of the procedures. Step by step, methodically, the analyst identifies the d

43、ata elements to be input to, stored by, manipulated by, generated by, or output by the system.To keep track of the data elements, the analyst might list each one in a data dictionary. A simple data dictionary can be set up on index cards, but computerized data dictionaries have become increasingly p

44、opular. The data dictionary, a collection of data describing and defining the data, is useful throughout the systems analysis and design process, and is often used to build a database during the implementation stage. The idea of analysis is to define the systems major functions and data elements met

45、hodically. Remember that the objective is translating user needs into technical terms. Since the system starts with the user, the first step is defining the users needs. Users think in terms of functions and data. They do not visualize programs, or files, or hardware, and during this initial, crucia

46、l analysis stage, it is essential that the analyst think like a user, not like a programmer.Data flow diagrams and data dictionaries are useful tools. They provide a format for recording key information about the proposed system. Also, they jog the analysts memory; for example, if the analyst doesnt

47、 have sufficient information to complete a data dictionary entry, he or she has probably missed something. Perhaps most importantly, the data flow diagram and the data dictionary document the analysts understanding of the system requirements. By reviewing these documents, the user can correct misund

48、erstanding or oversights. Finally, they represent an excellent starting point for the next step, design.DesignAs we enter the design stage, we know what the system must do, and thus can begin thinking about how to do it. The objective is to develop a strategy for solving the problem. At this stage,

49、we are not interested in writing code or in defining precise data structures; instead, we want to identify, at a black box level, necessary programs, files, procedures, and other components.The data flow diagram defines the systems necessary functions; how might they be implemented? One possibility is writing one program for each process. Another is combining two or more processes in a si