軟件開發(fā)外文翻譯（節(jié)選）

1、<p>　　2700單詞，1.5萬英文字符，4900漢字</p><p>　　4.3.5 Evolution of Shared Information Systems in Software</p><p>　　Development Environments</p><p>　　Software development has different re

2、quirements from database processing. As compared to databases, software development involves more different types of data, fewer instances of each distinct type, and slower query rates. The units of information are larg

3、er, 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.</p><p>　　Desp

4、ite the differences in 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 ther

5、efore not surprising to find comparable evolutionary stages in their architectures.</p><p>　　Here the forces for evolution were:</p><p>　　The advent of on-line computing, which drove the shift f

6、rom batch to interactive processing for many functions.</p><p>　　The concern for efficiency, which granularity of operations, shifting systems to processing of modules to is driving a reduction in the from c

7、omplete processing of incremental development.</p><p>　　The need for management control over the entire software development process, which is driving coverage to increase from compilation to the full life c

8、ycle.</p><p>　　Integration in this area is still incomplete. Data conversions are passive, and the ordering of operations remains relatively rigid. The integration systems can exploit only relatively coa

9、rse system information, such as file and date. Software development environments are under pressure to add capabilities for handling complex dependencies and selecting which tools to use. Steps toward more sophisticatio

10、n show up in the incorporation of metamodels to describe sharing, distribution, data mer</p><p>　　4.4 Integration in the design of buildings</p><p>　　The two preceding examples come from the inf

11、ormation technology fields. 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 matchin

12、g sets of specialized functions. Indeed, distinct subindustries support these specialties. A project generally involves a number of independent, geographically dispersed companies. The diversity of expertise and dispersi

13、on of the indust</p><p>　　The construction community employs divide-and-conquer problem solving, with interactions among the subproblems. This is naturally a distributed approach; teams of independent subcon

14、tractors map naturally to distributed problem-solving systems with coarse-grained cooperation among specialized agents. However, the separation into sub-problems is forced by the need for specialization and the nature of

15、 the industry; the problems are not inherently decomposable, and the subproblems are often interdep</p><p>　　In this setting it was natural for computing to evolve bottom-up. Building designers have exploite

16、d computing for many years for tasks ranging 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 r

17、ise to a number of algorithmic systems directed at aiding in the performance of individual phases of the facility development. However, a large number of tasks in facility developmen</p><p>　　The early stage

18、s of development, involving stand-alone programs 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 foc

19、used on support-supervisory systems, which provided basic services such as data management and information flow control to individual independent applications, much as software development environments did. The story pic

20、ks up from the point of these early integrati</p><p>　　Integrated environments for building design are frameworks for controlling a collection of stand-alone applications that solve part of the building-desi

21、gn problem [Ter92].</p><p>　　They must he</p><p>　　·Efficient in managing problem solving and information exchange</p><p>　　·Flexible in dealing with changes to tools</

22、p><p>　　·Graceful in reacting to changes in information and problem-solving strategies</p><p>　　These requirements derive from the lack of standardized problem-solving proce-</p><p&

23、gt;　　duress they reflect the separation into specialties and the geographical distribution of the</p><p>　　facility-development process.</p><p>　　4..4.1 Repository</p><p>　　Selectio

24、n of tools and composition of individual results requires judgment, experience, and rules of thumb. Because of coupling between subproblems it is not algorithmic, so integrated systems require a planning function. The go

25、al of an integrated environment is integration of data, design decisions, and knowledge. Two approaches emerged: the closely coupled Master Builder, or monolithic system, and the design environment with cooperating tools

26、. These early efforts at integration added elementar</p><p>　　The common responsibilities of a system for distributed problem-solving follow:</p><p>　　Problem partitioning (divide into tasks for

27、 individual agents).</p><p>　　Task distribution (assign tasks to agents for best performance).</p><p>　　Agent control (strategy that assures tasks are performed in organized fashion).</p>

28、<p>　　Agent communication (exchange of information essential when sub-tasks interact or conflict).</p><p>　　Terk [Ter92] surveyed and classified many of the integrated building design environments

29、that were developed in the 1980s. Here's what he found：</p><p>　　Data: mostly repositories: shared common representation with conversions to private representations of the tools.</p><p>　　Co

30、mmunication: mostly shared data, some messaging.</p><p>　　Tools: split between closed (tools specifically built for this system) and open (external tools can be integrated).</p><p>　　Control: m

31、ostly single-level hierarchy; tools at bottom;coordination at top.</p><p>　　Planning:mostly fixed partitioning of kind and processing order;scripts sometimes permit limited flexibility.</p><p

32、>　　So the typical system was a repository with a sophisticated control and planning component. A fairly typical such system, IBDE (F+90), appears in Fig. 4.19.Although the depiction is not typical, the distinguished p

33、osition of the global data shows clearly the repository character. A list of the tools that populate this IBDE follows</p><p>　　ARCHPLAN develops architectural plan from site, budget,</p><p>　　

34、geometric constraints.</p><p>　　CORE lays out building service core (elevators, stairs, etc).</p><p>　　STRYPES configures the structural system (e.g，suspension,</p><p>　　rigid fram

35、e, etc.).</p><p>　　STANLAY performs preliminary structural design and</p><p>　　approximate analysis of the structural system.</p><p>　　SPEX performs preliminary design of structur

36、al components.</p><p>　　FOOTER designs the foundation.</p><p>　　CONSTRUCTION PLANEX generates construction schedule and estimates cost.</p><p>　　4.4.2 Intelligent Control</p>

37、;<p>　　As integration and automation proceed, the complexity of planning and control grows to be a significant problem. Indeed, as this component grows more complex, its structure starts to dominate the repository

38、 structure of the data. The difficulty of reducing the planning to pure</p><p>　　algorithmic form makes this application a candidate for intelligent control.</p><p>　　The Engineering Design Rese

39、arch is exploring the development 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.

40、 Integrated building design is one of the areas they have explored. Figure 4.21(NS91) shows their design for an intelligent extension of the original IBDE system, Soar/IBDE. That figure is easier to understand in two sta

41、ges, so Fig. 4.20 shows the relat</p><p>　　From the standpoint of the designer's general position on intelligent control this organization seems reasonable, as the agent is portrayed as interacting with

42、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). Als

43、o, the intelligent agent may also find that the character of interaction with the global data is special, because it was</p><p>　　of this system will probably need to address the interactions among component

44、s as well as the components themselves.</p><p>　　Figure 4.21 adds the fine structure of the intelligent agent. The agent has six major components. It must be able to identify and formulate subtasks for the s

45、et of external software systems and express them in the input formats of those systems. It must receive the output and interpret it in terms of a global overview of the problem. It must be able to understand the actions

46、of the components as they work toward solution of the problem, in terms of both general knowledge of the task and specific</p><p><b>　　Systems.</b></p><p>　　The most significant aspe

47、ct of this design is that the seven external software systems are interactive. This means that their input and ouput are incremental, so a component that needs to understand their operation must retain and update a histo

48、ry of the interaction. The task becomes vastly more complex when pointer input and graphical output are included, although this is not the case in this case.</p><p>　　4.4.3 Evolution of Shared Information Sy

49、stems in Building Design </p><p>　　Integration in this area is less mature than in databases and software development environments. Nevertheless, the early stages of integrated building or facility environme

50、nts resemble the early stages of the first two examples. The evolutionary shift to layered hierarchies seems to come when many users must select from a diverse set of tools and they need extra system structure to coordin

51、ate the effort of selecting and managing a useful subset. These systems have not reached this stage of devel</p><p>　　In this case, however, the complexity of the task makes it a prime candidate for intellig

52、ent control. This opens the question of whether intelligent control could be of assistance in the other two examples, and if so what form it will take. The single-agent model developed for Soar/IBDE is one possibility, b

53、ut the enrichment of database mediators to make them capable of independent intelligent action (like knowbots) is clearly another.</p><p>　　4.5 ARCIMECTURAL STRUCTURES FOR SHARED INFORMATION SYSYTEMS</p&g

54、t;<p>　　While examining examples of software integration, we have seen a variety of general architectural patterns, or idioms for software systems. In this section we reexamine the data flow and repository idioms

55、to see the variety that can occur within a single idiom.</p><p>　　Current software tools do not distinguish among different kinds of components at this level. These tools treat all modules equally, and they

56、mostly assume that modules interact only via procedure calls and perhaps shared variables. By providing only a single model of component, they tend to blind designers to useful distinctions among modules. Moreover, by su

57、pporting only a fixed pair of low-level mechanisms for module interaction, they tend to blind designers to the rich classes of high-level i</p><p>　　By making the richness of these structures explicit, we fo

58、cus the attention of designers on the need for coherence and consistency of the system's design. Incorporating this information explicitly in a system design should provide a record that simplifies subsequent changes

59、 and</p><p>　　increases the likelihood that later modifications will not compromise the integrity of the design. The architectural descriptions focus on design issues such as the gross structure of the syste

60、m, the kinds of parts from which it is composed, and the kinds of interactions that take place.</p><p>　　The use of well-known patterns leads to a kind of reuse of design templates. These templates capture i

61、ntuitions that are a common part of our folklore: it is now common practice to draw box-and-line diagrams that depict the architecture of a system, but no uniform meaning is yet associated with these diagrams. Many anecd

62、otes suggest that simply providing some vocabulary to describe parts and patterns is a good first step.</p><p>　　By way of recapitulation, we now examine variations on two of the architectural forms that app

63、ear earlier: data flow and repositories</p><p>　　4.5.1 Variations on Data Flow Architectures</p><p>　　The data flow architecture that repeatedly occurs in the evolution of shared information sys

64、tems is the batch sequential pattern. However, the most familiar example of this genre is probably the Unix pipe-and-filter system. The similarity of these architectures is apparent in the diagrams used for systems of th

65、e respective classes, as indicated in Fig. 7.22. Both decompose a task into a (fixed) sequence of computations. They interact only through the data passed from one to another and share no </p><p>　　Very coar

66、se-grained.</p><p>　　Unable to do feedback in anything resembling real time.</p><p>　　Unable to exploit concurrency.</p><p>　　Unlikely to proceed at an interactive pace.</p>

67、<p>　　On the other hand, pipe-and-filter systems are characterized as follows:</p><p>　　Fine-grained, beginning to compute as soon as they consume a few input tokens.</p><p>　　Able to start

68、 producing output right away (processing is localized in the input stream).</p><p>　　Able to perform feedback (though most shells can't express it)</p><p>　　Often interactive.</p><

69、;p>　　4.5.2 Variations on Repositories</p><p>　　The other architectural pattern that figured prominently in our examples was the repository. Repositories in general are characterized by a central shared da

70、ta store coupled tightly to a number of independent computations, each with its own expertise. The independent computations interact only through the shared data, and they do not retain any significant amount of p

71、rivate state. The variations differ chiefly in the control apparatus that controls the order in which the computations are </p><p>　　Figures 4.7 and 7.8 show a database system. Here the control is driven by

72、the types of transactions in the input stream, the access mechanism is usually supported by a specialized programming language, and the granularity is that of a database transaction.Figure4.16 shows a programming-languag

73、e compiler. Here control is fixed (compilation proceeds in the same order each time), the access mechanism may be full conversion of the shared data structure into an in- memory representation or direct acc</p>&l

74、t;p>　　Figure 4.17 shows a repository that supports independent tools. Control may be determined by direct request of users, or it may in some cases be handled by an event mechanism also shared by the tools.Various acc

75、ess methods are available, and the granularity is that of the tool set.</p><p>　　One prominent repository has not appeared here; it is mentioned now for completeness-to extend the comparison of repositories.

76、 This is the blackboard architecture, most frequently used for signal-processing applications in artificial intelligence (Nii, 86) and depicted in Fig. 4.23. Here the independent computations are various knowledge source

77、s that can contribute to solving the problem-for example, syntactic-semantic connection, phoneme recognition, word candidate generation,and signal segment</p><p>　　4.6 SOME CONCLUSIONS</p><p>　　

78、Three tasks arising in different communities deal with collecting, manipulating, and preserving shared information. In each case, changing technologies and requirements drove changes in the architectural form commonly us

79、ed for the systems. We can identify that sequence as a common evolutionary pattern for shared information systems:</p><p>　　Isolated applications without interaction.</p><p>　　Batch sequential p

80、rocessing.</p><p>　　Repositories for integration via shared data</p><p>　　Layered hierarchies for dynamic integration across distributed systems.</p><p>　　4.3.5軟件開發(fā)環(huán)境的共享信息系統(tǒng)的演化</

81、p><p>　　軟件開發(fā)有許多與數(shù)據(jù)庫處理不同的需求。和數(shù)據(jù)庫相比較而言，軟件開發(fā)中出現(xiàn)的據(jù)類型會更多，每一種獨(dú)特的類型的實例可能會更少，查詢速率會更慢。并且信息單元和傳統(tǒng)的數(shù)據(jù)庫中的信息單元相比，會更大，更復(fù)雜，而且之間會具有某種程度的聯(lián)系。但是，軟件開發(fā)中信息的生命卻不比數(shù)據(jù)庫短。</p><p>　　盡管在應(yīng)用領(lǐng)域和支持?jǐn)?shù)據(jù)的特征兩者有許多不同，但是關(guān)于進(jìn)行中操作的共享數(shù)據(jù)收集、排序、檢

82、索這些基本問題，兩者是相同的。因此，對它們體系結(jié)構(gòu)演化的比較就很正常了。</p><p>　　演化的驅(qū)動力包括以下幾個方面:</p><p>　　實時計算的到來促使很多功能從批處理過渡到交互式處理。</p><p>　　對于效率的關(guān)注促使操作粒度的降低，從系統(tǒng)完全處理過渡到模</p><p><b>　　塊增量開發(fā)的處理。</

83、b></p><p>　　對整個軟件開發(fā)過程控制的管理促使管理的覆蓋面從編譯過渡到</p><p><b>　　整個開發(fā)周期。</b></p><p>　　在這個領(lǐng)域的集成仍然是不完全的。數(shù)據(jù)轉(zhuǎn)換是被動的，操作順序仍然是相對固定的。集成系統(tǒng)只能利用相對粗粒度的系統(tǒng)信息，比如文件和日期。軟件開發(fā)環(huán)境在處理復(fù)雜依賴性和工具使用選擇上還有很大壓

84、力。描述共享，分布式，數(shù)據(jù)融合，安全策略的元模型的集成正在走向成熟。NIST/ECMA模型的過程管理服務(wù)目前還不完善，它最初將關(guān)注點放在了項目層次的支持。但是，對各種信息和貫穿整個軟件開發(fā)生命周期的集成方案已經(jīng)被提上日程，智能輔助工具經(jīng)常作為人們夢寐以求的東西被提及。</p><p><b>　　4.4建筑設(shè)計集成</b></p><p>　　前述的兩個例子(即數(shù)據(jù)庫

85、集成和軟件開發(fā)環(huán)境集成)來自信息技術(shù)領(lǐng)域，第三個例子我們轉(zhuǎn)向應(yīng)用領(lǐng)域，建筑構(gòu)筑工業(yè)(BuildingConstruction Industry)。這個行業(yè)需要很多不同的專業(yè)知識。獨(dú)特的責(zé)任用來滿足專門的功能的需要。n然，獨(dú)特的子行業(yè)提供了專門知識。一般一個工程會包括很多獨(dú)立的地理位置分散的公司。專業(yè)技能的多樣性和行業(yè)的分散性阻礙了信息的溝通并限制了職責(zé)的范圍。每一個新的工程都產(chǎn)生一個新的合并，所以在公司之間并沒有積累起來的共享經(jīng)驗和兼容

86、的特殊優(yōu)勢。然而，關(guān)于子任務(wù)以復(fù)雜的，有時不明顯</p><p>　　的方式交互，并且專門知識(全局過程專業(yè)知識)之間的協(xié)調(diào)本身就是專門知識</p><p>　　建筑組織采用了分而治之的問題解決方式，即通過子問題的交互來解決整個問題，這是很自然的一種分布式方案。獨(dú)立的子承包商團(tuán)隊通過在專業(yè)的代理之間的簡單合作，很自然的對應(yīng)到分布式問題求解的系統(tǒng)中。專門化和行業(yè)的屬性的需要推動了問題的分解，

87、但是問題本身不是可分解的，并且子問題經(jīng)常是相互依賴的。</p><p>　　在這種情況下，自下向上的演化對于計算來說非常自然。建筑設(shè)計者對一系列計算的探索，包括從財務(wù)處理到計算機(jī)輔助設(shè)計，己經(jīng)有很多年了。在這里，我們關(guān)心的是能在設(shè)計活動各個階段進(jìn)行分析的軟件。在上個世紀(jì)60年代和70年代，出現(xiàn)了很多算法系統(tǒng)，這些算法系統(tǒng)定位在輔助工具開發(fā)中的獨(dú)立階段的性能的分析和評估。然而，在工具開發(fā)中大量的任務(wù)依賴于專業(yè)領(lǐng)域中

88、專家積累的判斷能力、經(jīng)驗和拇指規(guī)則。這樣的任務(wù)不可能以算法的方式被有效的執(zhí)行。</p><p>　　開發(fā)的早期階段，包括獨(dú)立程序和批序列組合，與前面兩個例子足夠的相似，在這里我們不去回顧這兩個例子。供應(yīng)A督系統(tǒng)邁出了集成的第一步，這種系統(tǒng)提供基本的服務(wù)，比如針對個人獨(dú)立應(yīng)用的數(shù)據(jù)管理和信息流控制，和軟件開發(fā)環(huán)境有些相似。從此集成開始迅速發(fā)展。</p><p>　　建筑設(shè)計集成環(huán)境是一個控制

89、獨(dú)立應(yīng)用集合的框架，這些獨(dú)立應(yīng)用用來解決建筑設(shè)計中部分問題。他們必須:</p><p>　　在管理問題求解和信息交換上是有一效的;</p><p>　　并且有足夠的靈活性來適應(yīng)工具的變化:</p><p>　　還能很好的對信息和問題求解策略的變化做出響應(yīng)。</p><p>　　這些需求來源于標(biāo)準(zhǔn)問題求解過程的缺乏，它們反映了專業(yè)和工具開發(fā)過程

90、中地理分布的分離。</p><p><b>　　4.4.1知識庫</b></p><p>　　工具的選擇和單個結(jié)果的組合需要判斷能力、經(jīng)驗和拇指規(guī)則。因為子問題足禍合的，所以過程很難用算法表示，這樣集成系統(tǒng)需要有規(guī)劃功能。一個集成環(huán)境的目標(biāo)是數(shù)據(jù)、設(shè)計決策、知識的集成。解決方案有兩種:緊密禍合的土構(gòu)建器或者單片機(jī)系統(tǒng)，再就是使用協(xié)作工具設(shè)計環(huán)境。針對集成的早期努力使得

91、基本數(shù)據(jù)管理和信息流控制工具加入到了可使用的工具集中。</p><p>　　針對分布式的問題求解的系統(tǒng)必須具備以下功能:</p><p>　　問題分解(將任務(wù)分解為獨(dú)立的代理者)。</p><p>　　任務(wù)分配(以最佳的性能將任務(wù)分配給代理者)。</p><p>　　代理控制(保證任務(wù)以有組織的方式被執(zhí)行的策略)。</p>&l

92、t;p>　　代理通信(當(dāng)子任務(wù)交互或沖突時，信息的交換)。</p><p>　　調(diào)查和分類了許多在上個世紀(jì)80年代開發(fā)的集成建筑及計環(huán)境。他發(fā)現(xiàn):</p><p>　　數(shù)據(jù);通常是知識庫;能將只享的通用的表示方式轉(zhuǎn)化成工具</p><p><b>　　專有表示方式。</b></p><p>　　通信:通常是共享數(shù)據(jù)

93、，消息。</p><p>　　工具:分為內(nèi)部的(專門為系統(tǒng)設(shè)計的工具)和開放的(可以</p><p>　　‘被集成的外部工具)。</p><p>　　控制:大部分是單級別的層次結(jié)構(gòu)，工具位于底層，在頂層進(jìn)</p><p><b>　　行協(xié)調(diào)。</b></p><p>　　規(guī)劃:主要針對類別和處理順

94、序的固定分解:腳本有時允許有</p><p><b>　　限的靈活性。</b></p><p>　　所以典型的系統(tǒng)是一個知識庫，擁有一個成熟的控制和規(guī)劃構(gòu)件。一個相當(dāng)?shù)湫偷南到y(tǒng)，IBDE如圖4.19所示。雖然它的描述并不是通用，但是，全局?jǐn)?shù)據(jù)的顯著位置還是清楚的顯示出了知識庫的特點。IBDE中的工具如下所示:</p><p>　　ARCHPLA

95、N從地點，預(yù)算，幾何約束設(shè)計出體系結(jié)構(gòu)規(guī)劃。</p><p>　　CORE列出了建筑核心服務(wù)(電梯，樓梯等)。</p><p>　　STRYPES配置結(jié)構(gòu)化的系統(tǒng)(比如，懸架，固定框架等)。</p><p>　　STAN LAY執(zhí)行基本的結(jié)構(gòu)設(shè)計和大概的結(jié)構(gòu)系統(tǒng)分析。</p><p>　　SPEX進(jìn)行結(jié)構(gòu)化構(gòu)件的初步設(shè)計.</p>

96、<p>　　FOOTER設(shè)計了基礎(chǔ)。</p><p>　　CONSTRUCTION PLANEX產(chǎn)生構(gòu)造進(jìn)度表，并預(yù)算成木。</p><p><b>　　4.4.2智能控制</b></p><p>　　隨著集成和自動化不斷發(fā)展，規(guī)劃和控制的復(fù)雜性成為一個顯著問題。確實，隨著構(gòu)件變得越來越復(fù)雜，它的結(jié)構(gòu)決定了數(shù)據(jù)的知識庫結(jié)構(gòu)。將規(guī)劃

97、簡化成純算法的形式變得非常困難，這樣使得建筑設(shè)計集成成為智能控制的一種選擇。</p><p>　　位于CMU的工程設(shè)計研究中心正在探索智能代理者的開發(fā)，這種代理者能夠?qū)W習(xí)控制外部軟件系統(tǒng)，或者交互式人工千預(yù)的系統(tǒng)。集成的建筑設(shè)計是他們研究的一個領(lǐng)域。顯示了他們對最初的IBDE系統(tǒng)即Soar/IBDE的一個智能擴(kuò)展設(shè)計.這個圖用兩個階段來表</p><p>　　示的話也許更容易理解，圖4.2

98、0顯示了智能代理者和外部軟件系統(tǒng)的關(guān)系，而圖4.21在圖4.20的基礎(chǔ)上加上了智能代理者的內(nèi)部結(jié)構(gòu)。可以很清楚地看出圖4.20是從圖4.19導(dǎo)出的，它將全局?jǐn)?shù)據(jù)作為另一個外部軟件系統(tǒng)的狀態(tài)。Soar/IBDE強(qiáng)調(diào)與IBDE的獨(dú)立代理者交互的控制。</p><p>　　從設(shè)計者關(guān)于智能控制一般角度上看，這種組織結(jié)構(gòu)好像很合理，因為代理者被描述成可以和任何提供的軟件交互。然而，全局?jǐn)?shù)據(jù)在這個系統(tǒng)中扮演著非常特殊的角色

99、。七個其他的構(gòu)件必須通過全局?jǐn)?shù)據(jù)交互(不然，保留全局?jǐn)?shù)據(jù)沒有任何意義)。同樣，智能代理者可能也會發(fā)現(xiàn)使用全局?jǐn)?shù)據(jù)的交互是很特殊的，因為全局?jǐn)?shù)據(jù)被設(shè)計成知識庫來使用，交互不是通過人工方式進(jìn)行的。系統(tǒng)未來性能的提高將需要解決構(gòu)件間的交互和構(gòu)件本身的交互的問題。</p><p>　　圖4.21加入了智能代理者的詳細(xì)給構(gòu)。代理者擁有七個主要構(gòu)件。代理者必須能夠為外部軟件系統(tǒng)集合識別和闡明子任務(wù)，并以這些軟件的輸入格式表示

100、了任務(wù)。它必須接受外部軟件的輸出，并從問題的全局角度解釋它們。代理者還必須能夠理解構(gòu)件在問題求解時的行為，這既需要任務(wù)的一般性知識，也需要外部軟件系統(tǒng)集合能力的特殊知識。</p><p>　　這種設(shè)計最重要的方面是，七個外部軟件系統(tǒng)是交互的。這意味著它們的輸入和輸出是增量的，因此，如果構(gòu)件需要理解它們的操作，必須保留和更新交互歷史。雖然我們這里不討論這些，但是如果任務(wù)包括指針輸入和圖形輸出的話，任務(wù)將會變得非常復(fù)

101、雜。</p><p>　　4.4.3建筑設(shè)計的共享信息系統(tǒng)的演化</p><p>　　在建筑設(shè)計領(lǐng)域的集成沒有數(shù)據(jù)庫和軟件開發(fā)環(huán)境集成那么成熟。然而，集成的建筑或工具環(huán)境的早期階段又與前兩個例子的早期階段非常相似。當(dāng)很多用戶必須在不同工具集中選擇時，當(dāng)用戶需要額外系統(tǒng)結(jié)構(gòu)來協(xié)調(diào)選擇和管理有用工具子集時，趨向?qū)哟谓Y(jié)構(gòu)的演化將會到來。但是，這些系統(tǒng)還沒有到達(dá)這樣的發(fā)展階段，所以我們不知道它們的