Introduction Theaeb{@ of servicesar deployed softwad aftwa in the mostfatb@ offspring of the Internet, the World Wide Web, isexponentiakp increatia Inabp{q}}b the Internet is a open environment, where infor maorb sources,communica}}{ links an anksb themselvesma aems a disaselv unpredicta}{} Thus,a effective, affectiv seaec aa selection ofrelevaq services orab@pk isessentia forhuma usersae aersba well. We distinguish threegenera aner cara{p}fi in theCyberspaC{ service providers, service requester,a{ middle agents. Service providers provide some type of service, sucha finding informaorb} or performing somepab@}@v@b doma@ specific problem solving. Requesterauest need provideraovid to perform some service for them. Agentstha helploca{ othersah caers middle addle [6]. Matchmaking is the # Thisreseapv ha been sponsored inpa} by Office ofNa@{ Resea@} gra N-00014-96-16-1-1222, aby DARPAgraD F-30602-98-2-0138. 174 sycara et al. process of findinga aingb{fi@{v provider fora requester througha

Due to the exponential increase of offered services in the most famous offspring of the Internet...

Automated proof assistants provide few facilities for incremental development. Generally, if the underlying structures on which a proof is based are modified, the developer must redo much of the proof. Yet incremental development is really the most natural approach for proofs of programming language properties [5, 12]. We propose “proof weaving”, a technique that allows a proof developer to combine small proofs into larger ones by merging proof objects. We automate much of the merging process and thus ease incremental proof development for programming language properties. To make the discussion concrete we take as an example the problem of proving typesoundness by proving progress and preservation [17] in Coq [3, 7]. However we believe that the methods can be generalized to other proof assistants which generate proof objects, and most directly to those proof assistants which exploit the Curry-Howard isomorphism in representing proof terms as λ-terms [16], e.g. Isabelle and Minlog. We rely on the proof developer to initially prove type-soundness for “tiny ” languages. Each of these languages encapsulates a single well-defined programming feature. For example, a tiny language of booleans can be restricted to the terms True, False, and If and their

Modern integrated development environments (IDEs) provide programmers with a variety of sophisticated tools for program visualization and manipulation. These tools assist the programmer in understanding legacy code and making coordinated changes across large parts of a program. Similar tools incorporated into an integrated proof environment (IPE) would assist proof developers in understanding and manipulating the increasingly larger proofs that are being developed. In this paper we propose some tools and techniques developed for software engineering that we believe would be equally applicable in proof engineering.