软件开发外文翻译（节选）

《软件开发外文翻译（节选）》由会员分享，可在线阅读，更多相关《软件开发外文翻译（节选）（10页珍藏版）》请在毕设资料网上搜索。

1、2700 单词， 1.5 万英文字符， 4900 汉字  4.3.5 Evolution of Shared Information Systems in Software Development Environments Software development has different requirements from  database processing. As compared to databases, software development involves more different types of data, fewer instances o

2、f each distinct type, and slower query rates. The units of information are larger, more complex, and less discrete than in traditional databases. The lifetime of software development information, however, is not (or at least should not be) shorter than database lifetimes. Despite the differences in

3、application area and characteristics of the supporting data, the essential problem of collecting, storing, and retrieving shared data about an ongoing process is common to the two areas. It is therefore not surprising to find comparable evolutionary stages in their architectures. Here the forces for

4、 evolution were:     The advent of on-line computing, which drove the shift from batch to interactive processing for many functions.     The concern for efficiency, which granularity of operations, shifting systems to processing of modules to is driving a reduction in the from co

5、mplete processing of incremental development.     The need for management control over the entire software development process, which is driving coverage to increase from compilation to the full life cycle.   Integration in this area is still incomplete. Data conversions are passive,

6、and the ordering of operations remains relatively rigid. The integration  systems  can exploit  only  relatively coarse  system information, such as file and date. Software development environments are under pressure to add capabilities for handling complex dependencies and

7、selecting which tools to use. Steps toward more sophistication show up in the incorporation of metamodels to describe sharing, distribution, data merging, and security policies. The process-management services of the NIST/ECMA model are not yet well developed, and they will initially concentrate on

8、project-level support. But integration across all kinds of information and throughout the life cycle is on the agenda, and intelligent assistance is often mentioned on the wish list   4.4 Integration in the design of buildings The two preceding examples come from the information technology fiel

9、ds. For the third example we turn to an application area, the building construction industry. This industry requires a diverse variety of expertise. Distinct responsibilities correspond to matching sets of specialized functions. Indeed, distinct subindustries support these specialties. A project gen

10、erally involves a number of independent, geographically dispersed companies. The diversity of expertise and dispersion of the industry inhibit communication and limit the scope of responsibilities. Each new project creates a new coalition, so there is little accumulated shared experience and no spec

11、ial advantage for pair-wise compatibility between companies. However, the subtasks interact in complex, sometimes nonobvious ways, and coordination among specialties (global process expertise) is itself a specialty Ter921.     The construction community employs divide-and-conquer problem s

12、olving, with interactions among the subproblems. This is naturally a distributed approach； teams of independent subcontractors map naturally to distributed problem-solving systems with coarse-grained cooperation among specialized agents. However, the separation into sub-problems is forced by the nee

13、d for specialization and the nature of the industry； the problems are not inherently decomposable, and the subproblems are often interdependent     In this setting it was natural for computing to evolve bottom-up. Building designers have exploited computing for many years for tasks ranging

14、 from accounting to computer- aided design. We are concerned here with the software that performs analysis for various stages of the design activity. The 1960s and 1970s gave rise to a number of algorithmic systems directed at aiding in the performance of individual phases of the facility developmen

15、t. However, a large number of tasks in facility development depend on judgment,experience, and rules of thumb accumulated by experts in the domain. Such tasks cannot be performed efficiently in an algorithmic manner Ter92.     The early stages of development, involving stand-alone programs

16、 and batch sequential compositions, are sufficiently similar to the two previous examples that it is not illuminating to review them. The first steps toward integration focused on support-supervisory systems, which provided basic services such as data management and information flow control to indiv

17、idual independent applications, much as software development environments did. The story picks up from the point of these early integration efforts.     Integrated environments for building design are frameworks for controlling a collection of stand-alone applications that solve part of th

18、e building-design problem Ter92. They must he     Efficient in managing problem solving and information exchange   Flexible in dealing with changes to tools   Graceful in reacting to changes in information and problem-solving strategies     These requirements derive fro

19、m the lack of standardized problem-solving proce- duress they reflect the separation into specialties and the geographical distribution of the facility-development process.  4.4.1 Repository Selection of tools and composition of individual results requires judgment, experience, and rules of thu

20、mb. Because of coupling between subproblems it is not algorithmic, so integrated systems require a planning function. The goal of an integrated environment is integration of data, design decisions, and knowledge. Two approaches emerged: the closely coupled Master Builder, or monolithic system, and t

21、he design environment with cooperating tools. These early efforts at integration added elementary data management and information flow control to a tool set.   The common responsibilities of a system for distributed problem-solving follow:       Problem partitioning (divide into

22、tasks for individual agents).       Task distribution (assign tasks to agents for best performance).       Agent control (strategy that assures tasks are performed in organized fashion).       Agent communication (exchange of information essential when su

23、b-tasks interact or     conflict).  Terk Ter92 surveyed and classified many of the integrated building design environments that were developed in the 1980s. Here's what he found：  Data: mostly repositories: shared common representation with conversions to private representati

24、ons of the tools.     Communication: mostly shared data, some messaging.     Tools: split between closed (tools specifically built for this system) and open (external tools can be integrated).     Control:  mostly  single-level  hierarchy；  tools &nb

25、sp;at  bottom；coordination at top.     Planning:mostly fixed partitioning of kind and processing order；scripts sometimes permit limited flexibility.    So the typical system was a repository with a sophisticated control and planning component. A fairly typical such system, I

26、BDE (F+90), appears in Fig. 4.19.Although the depiction is not typical, the distinguished position of the global data shows clearly the repository character. A list of the tools that populate this IBDE follows     ARCHPLAN  develops architectural plan from site, budget,    

27、geometric constraints. CORE  lays out building service core (elevators, stairs, etc). STRYPES configures the structural system (e.g， suspension, rigid frame, etc.). STANLAY  performs preliminary structural design and approximate analysis of the structural system. SPEX  performs prelim

28、inary design of structural components. FOOTER  designs the foundation. CONSTRUCTION PLANEX  generates construction schedule and estimates cost.   4.4.2 Intelligent Control As integration and automation proceed, the complexity of planning and control grows to be a significant problem.

29、Indeed, as this component grows more complex, its structure starts to dominate the repository structure of the data. The difficulty of reducing the planning to pure algorithmic form makes this application a candidate for intelligent control.   The Engineering Design Research is exploring the de

30、velopment for intelligent IBDE.Center at Carnegie Mellon of intelligent agents that can learn to control external software systems, or systems intended for use with interactive human intervention. Integrated building design is one of the areas they have explored. Figure 4.21(NS91) shows their design

31、 for an intelligent extension of the original IBDE system, Soar/IBDE. That figure is easier to understand in two stages, so Fig. 4.20 shows the relation of the intelligent agent to the external software systems before Fig. 4.21 adds the internal structure of the intelligent agent. Figure 4.20 is cle

32、arly derived from Fig. 4.19, with the global data moved to the status of just another external software system. The emphasis in Soar/IBDE was control of the interaction with the individual agents of IBDE.   From the standpoint of the designer's general position on intelligent control this o

33、rganization seems reasonable, as the agent is portrayed as interacting with whatever software is provided. However, the global data play a special role in this system. Each of the seven other components must interact with the global data (or else it makes no sense to retain the global data). Also, the intelligent agent may also find that the character of interaction with the global data is special,