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,
