DOCSLIB.ORG

Bridging the Gap Between Object-Oriented and Logic Programming Timothy Koschmann Southern Illinois University Carbondale

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Bridging the Gap Between Object-Oriented and Logic Programming Timothy Koschmann Southern Illinois University Carbondale Southern Illinois University Carbondale OpenSIUC Publications Department of Medical Education 7-1988 Bridging the Gap between Object-oriented and Logic Programming Timothy Koschmann Southern Illinois University Carbondale Martha Walton Evans Illinois Institute of Technology Follow this and additional works at: http://opensiuc.lib.siu.edu/meded_pubs ©1988 IEEE. Published in IEEE Software, Vol. 5, Issue 4 (July 1988) at 10.1109/52.17800 Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder. Recommended Citation Koschmann, Timothy and Evans, Martha W. "Bridging the Gap between Object-oriented and Logic Programming." (Jul 1988). This Article is brought to you for free and open access by the Department of Medical Education at OpenSIUC. It has been accepted for inclusion in Publications by an authorized administrator of OpenSIUC. For more information, please contact [email protected]. .. ... .. .. -. .. .. .. .. ~~ . .--. LANGUAGE INTERFACE between Logic Programming Timothy Koschmann, Xerox A/ Systems Mardha Walton EvenS. lllinois lnstitute of Technology ajectaiented and n recent years, many programmers chronological backtracking and pattern have begun to experiment with alter- matching viaunification. Prolog'sdeclara- Iogk progkamming native programming styles. Object- tive style provides a natural way to repre- each have dvantqges. oriented and logic programming have at- sent rule-based knowledge. Unfor- tracted growing interest among software tunately, Prolog also has deficiencies: Its lhis interface bridges designers, particularly among those work- declarative style is clumsy for tasks that are the two Wles, ing on knowledge-based applications. implicitly procedural in nature, such as lettingyou take equal Both styles of programming offer real prompting a user for a series of pieces of advantages over traditional programming information. Also, because Prolog isa rela- advan&ge ofboth. methods. tively new language in the US, it does not Object-oriented programming is partic- yet have a library of routines for graphics, ularly useful for problems in which data manipulating windows, creating menus, objects can be categorized hierarchically. or monitoring mouse events. The notions of inheritance and data en- The best solution would seem to be one capsulation encourage astructured imple- where you could use object-oriented and mentation style and enhance the main- logic programming in a common applica- tainability of programs. But object- tion, using each forwhat it does best. This oriented environments lack generalized is the philosophy behind the notion of facilities for deductive retrieval and pat- multiparadigm programming.' The ques tern matching, functions that are basic to tion that must be addressed is how you most knowledge-based applications. combine object-oriented and logic pro On the other hand, logic programming gramming so the best features of each par- languages like Prolog have built-in facili- adigm are preserved. (The box on p. 39 ties for deductive retrieval through describes each style.) 36 074Ck7459/88/0700/0036/!$01 .oO 0 1988 IEEE IEEE Software One strategymight be to implement one outside the Prolog database. cause both sets of microcode are resident paradigm in the other, either by imple- You may use each layer independently. at all times, there is no special overticad as- menting objects in an existing logic en- For example, in some applications, there sociated with decoding Prolog instruc- vironment or by implementing a Prolog- may be no need for clause objects or Pro- tions versus Lisp instructions. To the pro- like search facility in an object-oriented log methods - but the ability to manipu- grammer, Lisp and Prolog appear to be environment. Both approaches have been late Loops objects from the Prolog en- two separate worlds, each with its own tried: vironment may still be valuable. name spaces and syntactical rules. Access There are several ways to implement My colleagues and I at Xerox AI Systems to the Lisp world from Prolog is achieved objects in a logic programming frame- used the interface to implement Rotamer, through built-in predicates that let you in- work. For example, Malpas has described a fairly complex knowledge-based applica- voke Lisp functions while in Prolog and a technique for implementing classes, in- ti~n.~Rotamer uses a truth-maintenance capture the returned results. stances, methods, and inheritance in Pro- system (implemented with Prolog meth- The Xerox Quintus Prolog/I.isp inter- log.? ods) to cache information acquired in the face was readily extensible to provide a The Xerox Palo Alto Research Center course of exploring a large search space. Prolog/Loops interface. The principle of has tried the opposite approach of provid- Our earlyconcernswere that the overhead data encapsulation that underlies object- ing logical variables and backtracking caused by the calling between Lisp and or i e n te d programming d ra rn a t i ca I1 y search in an object-based system: The Prolog would lead to major performance simplified the task ofwriting an interface Common Log system was designed to pre to the Loops system. In Loops, everything vide the features of a Prolog-like language is represented as objects. All communi- implemented on top of the Common Lisp cation to and from Loopsobjects, with the Object Specification. Our earlyconcerns were exception of some low-level data-access There is a third approach: an interface that the ovechead routines, occurs through the message between an existing object-based system between Lisp and Prolog sending mechanism. and a logic-basedsystem. Abbott calls such Therefore, only a little coding i I re- an interface a Boolean bridge.3 There are would cause mdor perfiormance prublems. quired to provide the Prolog progr? mmer two advantages to creating such a bridge: the full range of capabilities to maiipulate First, you can access all the support tools of These fears were the Loopsobjectsavailable to the Lispprtr both environments. Second, there is no gloundless. grammer. A set of predicates is required so degradation of performance due to one the Prolog programmer can retrieve the language being implemented top of contents of an object’s slots, insert new another. values into the slots of a specified object, problems. These fears proved to be This article describes an interface that and send messages to an object. This func- groundless. On the Xerox Lisp Machine, was developed between Loops4and Xerox tionality is provided through three Prolog the cost in machine cycles for a call to a Quintus Prolog. Loops is an extension to procedures: get_value/3, put_value/3, Lisp function from Prolog is only slightly the Xerox AI Environment to support ob and send_message/4. ject-oriented programming; Xerox Quin- more expensive than a simple function Using the Loops access predicates, the tus Prolog is a version of Prolog that runs call in Lisp. Prolog programmer can easily create ob on Xerox Lisp Machines. jects, manipulate the contents of object The interface has three layers. At the AccessingLoopsfrom slots, and execute object methods. For ex- lowest level, a set of Prolog predicatesgives Prolog ample, you could use the following Prolog the Prolog programmer access to Loops Figure 1 shows how Prolog is imple- procedure to perform a slot-value substi- objects. This lowest level is the bridge from mented on the Xerox Lisp Machine. In tution in a Loops object: Prolog to Loops. At the next level, pro- this implementation, Prolog and Lisp gramming tools in the Loops environ- each have their own set ofmicrocode. The substitute-slot-value (Object,Slot, ment letobjectmethodsbedefinedinPro- microcode sets are stored in two different Old-value,New-value) :- get-value (Object,Slot,Old-value), log. At the highest level, the Prolog banksofcontrol-store chips. In asense, the put-valur(Object,Slot,New-value). programmer may treat Prolog clauses as Lisp Machine becomes a Prolog Machine Loops objects that can be manipulated when it is executing Prolog microcode. Be- The first goal checks to see if the value July 1988 37 - - . ... .- - .. .. ... ... .-. interface must allow calls to Prolog proce- that would let the methods he invoked via dures from the Lisp world. the Loops message-sending mechanism. Ideally, it should be transparent to the Prolog procedures as sender whether the method is defined in methods Lisp or Prolog. Loops was initially designed to offer the features of a Smalltalk-likelanguage to the Message-sending mechanism. Xerox Lisp programmer. It provides facilities to Quintus Prolog provided a way through a define classes and methods and to create Lisp function named PROILK to facilitate instances. Loops comes with a generous the creation of Prolog queries from Lisp. collection of system-defined classes and a If a Imops programmer wanted to invoke set of elegant programming tools. These the Prolog procedure foo/3, using the tools include ones that display and function call manipulate class hierarchies. You can in- (PROLOG 'foohdr (IJST 'argl *VALUE* Figure 1. Lisp and Prolog methods. voke most common programming opera- 'arg3)) tions with a mouse. would have the same effect the Prolog In the Loopsenvironment, object meth- as stored in aslot matches the targetvalue. If ods are invoked by sending a message to query this goal succeeds, the second goal will al- the object. The syntax for sending a mes foobx(arg1,X,arg3). ways succeed and will install the new value sage is The interface treats the Prolog proce- in the slot as a side effect.
Load more

Recommended publications
  • Objects and Classes in Python Documentation Release 0.1
    Objects and classes in Python Documentation Release 0.1 Jonathan Fine Sep 27, 2017 Contents 1 Decorators 2 1.1 The decorator syntax.........................................2 1.2 Bound methods............................................3 1.3 staticmethod() .........................................3 1.4 classmethod() ..........................................3 1.5 The call() decorator.......................................4 1.6 Nesting decorators..........................................4 1.7 Class decorators before Python 2.6.................................5 2 Constructing classes 6 2.1 The empty class...........................................6 3 dict_from_class() 8 3.1 The __dict__ of the empty class...................................8 3.2 Is the doc-string part of the body?..................................9 3.3 Definition of dict_from_class() ...............................9 4 property_from_class() 10 4.1 About properties........................................... 10 4.2 Definition of property_from_class() ............................ 11 4.3 Using property_from_class() ................................ 11 4.4 Unwanted keys............................................ 11 5 Deconstructing classes 13 6 type(name, bases, dict) 14 6.1 Constructing the empty class..................................... 14 6.2 Constructing any class........................................ 15 6.3 Specifying __doc__, __name__ and __module__.......................... 15 7 Subclassing int 16 7.1 Mutable and immutable types.................................... 16 7.2
    [Show full text]
  • Functional and Logic Programming - Wolfgang Schreiner
    COMPUTER SCIENCE AND ENGINEERING - Functional and Logic Programming - Wolfgang Schreiner FUNCTIONAL AND LOGIC PROGRAMMING Wolfgang Schreiner Research Institute for Symbolic Computation (RISC-Linz), Johannes Kepler University, A-4040 Linz, Austria, [email protected]. Keywords: declarative programming, mathematical functions, Haskell, ML, referential transparency, term reduction, strict evaluation, lazy evaluation, higher-order functions, program skeletons, program transformation, reasoning, polymorphism, functors, generic programming, parallel execution, logic formulas, Horn clauses, automated theorem proving, Prolog, SLD-resolution, unification, AND/OR tree, constraint solving, constraint logic programming, functional logic programming, natural language processing, databases, expert systems, computer algebra. Contents 1. Introduction 2. Functional Programming 2.1 Mathematical Foundations 2.2 Programming Model 2.3 Evaluation Strategies 2.4 Higher Order Functions 2.5 Parallel Execution 2.6 Type Systems 2.7 Implementation Issues 3. Logic Programming 3.1 Logical Foundations 3.2. Programming Model 3.3 Inference Strategy 3.4 Extra-Logical Features 3.5 Parallel Execution 4. Refinement and Convergence 4.1 Constraint Logic Programming 4.2 Functional Logic Programming 5. Impacts on Computer Science Glossary BibliographyUNESCO – EOLSS Summary SAMPLE CHAPTERS Most programming languages are models of the underlying machine, which has the advantage of a rather direct translation of a program statement to a sequence of machine instructions. Some languages, however, are based on models that are derived from mathematical theories, which has the advantages of a more concise description of a program and of a more natural form of reasoning and transformation. In functional languages, this basis is the concept of a mathematical function which maps a given argument values to some result value.
    [Show full text]
  • Csci 658-01: Software Language Engineering Python 3 Reflexive
    CSci 658-01: Software Language Engineering Python 3 Reflexive Metaprogramming Chapter 3 H. Conrad Cunningham 4 May 2018 Contents 3 Decorators and Metaclasses 2 3.1 Basic Function-Level Debugging . .2 3.1.1 Motivating example . .2 3.1.2 Abstraction Principle, staying DRY . .3 3.1.3 Function decorators . .3 3.1.4 Constructing a debug decorator . .4 3.1.5 Using the debug decorator . .6 3.1.6 Case study review . .7 3.1.7 Variations . .7 3.1.7.1 Logging . .7 3.1.7.2 Optional disable . .8 3.2 Extended Function-Level Debugging . .8 3.2.1 Motivating example . .8 3.2.2 Decorators with arguments . .9 3.2.3 Prefix decorator . .9 3.2.4 Reformulated prefix decorator . 10 3.3 Class-Level Debugging . 12 3.3.1 Motivating example . 12 3.3.2 Class-level debugger . 12 3.3.3 Variation: Attribute access debugging . 14 3.4 Class Hierarchy Debugging . 16 3.4.1 Motivating example . 16 3.4.2 Review of objects and types . 17 3.4.3 Class definition process . 18 3.4.4 Changing the metaclass . 20 3.4.5 Debugging using a metaclass . 21 3.4.6 Why metaclasses? . 22 3.5 Chapter Summary . 23 1 3.6 Exercises . 23 3.7 Acknowledgements . 23 3.8 References . 24 3.9 Terms and Concepts . 24 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Note: This chapter adapts David Beazley’s debugly example presentation from his Python 3 Metaprogramming tutorial at PyCon’2013 [Beazley 2013a].
    [Show full text]
  • The Use of UML for Software Requirements Expression and Management
    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
    [Show full text]
  • Metaclasses: Generative C++
    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
    [Show full text]
  • Meta-Class Features for Large-Scale Object Categorization on a Budget
    Meta-Class Features for Large-Scale Object Categorization on a Budget Alessandro Bergamo Lorenzo Torresani Dartmouth College Hanover, NH, U.S.A. faleb, [email protected] Abstract cation accuracy over a predefined set of classes, and without consideration of the computational costs of the recognition. In this paper we introduce a novel image descriptor en- We believe that these two assumptions do not meet the abling accurate object categorization even with linear mod- requirements of modern applications of large-scale object els. Akin to the popular attribute descriptors, our feature categorization. For example, test-recognition efficiency is a vector comprises the outputs of a set of classifiers evaluated fundamental requirement to be able to scale object classi- on the image. However, unlike traditional attributes which fication to Web photo repositories, such as Flickr, which represent hand-selected object classes and predefined vi- are growing at rates of several millions new photos per sual properties, our features are learned automatically and day. Furthermore, while a fixed set of object classifiers can correspond to “abstract” categories, which we name meta- be used to annotate pictures with a set of predefined tags, classes. Each meta-class is a super-category obtained by the interactive nature of searching and browsing large im- grouping a set of object classes such that, collectively, they age collections calls for the ability to allow users to define are easy to distinguish from other sets of categories. By us- their own personal query categories to be recognized and ing “learnability” of the meta-classes as criterion for fea- retrieved from the database, ideally in real-time.
    [Show full text]
  • Metaclass Functions: Generative C++
    Metaclass functions: Generative C++ Document Number: P0707 R4 Date: 2019-06-16 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: “Metaclass” functions .......................................................................................................................6 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 FAQs ................................................................................................................................................................. 41 R4: • Updated notes in §1.3 to track the current prototype, which now also has consteval support. • Added using metaclass function in the class body. Abstract The only way to make a language more powerful, but also make its programs simpler, is by abstraction: adding well-chosen abstractions that let programmers replace manual code patterns with saying directly what they mean. There are two major categories: Elevate coding patterns/idioms into new abstractions built into the language. For example, in current C++, range-for lets programmers directly declare “for each” loops with compiler support and enforcement.
    [Show full text]
  • Middlesex University Research Repository
    Middlesex University Research Repository An open access repository of Middlesex University research http://eprints.mdx.ac.uk Clark, Tony (1997) Metaclasses and reflection in smalltalk. Technical Report. University of Bradford. Available from Middlesex University’s Research Repository at http://eprints.mdx.ac.uk/6181/ Copyright: Middlesex University Research Repository makes the University’s research available electronically. Copyright and moral rights to this thesis/research project are retained by the author and/or other copyright owners. The work is supplied on the understanding that any use for commercial gain is strictly forbidden. A copy may be downloaded for personal, non-commercial, research or study without prior permission and without charge. Any use of the thesis/research project for private study or research must be properly acknowledged with reference to the work’s full bibliographic details. This thesis/research project may not be reproduced in any format or medium, or extensive quotations taken from it, or its content changed in any way, without first obtaining permission in writing from the copyright holder(s). If you believe that any material held in the repository infringes copyright law, please contact the Repository Team at Middlesex University via the following email address: [email protected] The item will be removed from the repository while any claim is being investigated. Metaclasses and Reection in Smalltalk A N Clark Department of Computing University of Bradford Bradford West Yorkshire BD DP UK email ANClarkcompbradacuk
    [Show full text]
  • Belgium a Logic Meta-Programming Framework for Supporting The
    Vrije Universiteit Brussel - Belgium Faculty of Sciences In Collaboration with Ecole des Mines de Nantes - France 2003 ERSITEIT IV B N R U U S E S J I E R L V S C S I E A N R B T E IA N VIN TE CERE ECOLE DES MINES DE NANTES A Logic Meta-Programming Framework for Supporting the Refactoring Process A Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science (Thesis research conducted in the EMOOSE exchange) By: Francisca Mu˜nozBravo Promotor: Prof. Dr. Theo D’Hondt (Vrije Universiteit Brussel) Co-Promotors: Dr. Tom Tourw´eand Dr. Tom Mens (Vrije Universiteit Brussel) Abstract The objective of this thesis is to provide automated support for recognizing design flaws in object oriented code, suggesting proper refactorings and performing automatically the ones selected by the user. Software suffers from inevitable changes throughout the development and the maintenance phase, and this usually affects its internal structure negatively. This makes new changes diffi- cult to implement and the code drifts away from the original design. The introduced structural disorder can be countered by applying refactorings, a kind of code transformation that improves the internal structure without affecting the behavior of the application. There are several tools that support applying refactorings in an automated way, but little help for deciding where to apply a refactoring and which refactoring could be applied. This thesis presents an advanced refactoring tool that provides support for the earlier phases of the refactoring process, by detecting and analyzing bad code smells in a software application, proposing appropriate refactorings that solve these smells, and letting the user decide which one to apply.
    [Show full text]
  • On the Interaction of Object-Oriented Design Patterns and Programming
    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
    [Show full text]
  • Logic Programming Lecture 19 Tuesday, April 5, 2016 1 Logic Programming 2 Prolog
    Harvard School of Engineering and Applied Sciences — CS 152: Programming Languages Logic programming Lecture 19 Tuesday, April 5, 2016 1 Logic programming Logic programming has its roots in automated theorem proving. Logic programming differs from theorem proving in that logic programming uses the framework of a logic to specify and perform computation. Essentially, a logic program computes values, using mechanisms that are also useful for deduction. Logic programming typically restricts itself to well-behaved fragments of logic. We can think of logic programs as having two interpretations. In the declarative interpretation, a logic pro- gram declares what is being computed. In the procedural interpretation, a logic program program describes how a computation takes place. In the declarative interpretation, one can reason about the correctness of a program without needing to think about underlying computation mechanisms; this makes declarative programs easier to understand, and to develop. A lot of the time, once we have developed a declarative program using a logic programming language, we also have an executable specification, that is, a procedu- ral interpretation that tells us how to compute what we described. This is one of the appealing features of logic programming. (In practice, executable specifications obtained this way are often inefficient; an under- standing of the underlying computational mechanism is needed to make the execution of the declarative program efficient.) We’ll consider some of the concepts of logic programming by considering the programming language Prolog, which was developed in the early 70s, initially as a programming language for natural language processing. 2 Prolog We start by introducing some terminology and syntax.
    [Show full text]
  • OMG Unified Modeling Languagetm (OMG UML), Infrastructure
    Date : August 2011 OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.4.1 OMG Document Number: formal/2011-08-05 Standard document URL: http://www.omg.org/spec/UML/2.4.1/Infrastructure Associated Normative Machine-Readable Files: http://www.omg.org/spec/UML/20110701/Infrastucture.xmi http://www.omg.org/spec/UML/20110701/L0.xmi http://www.omg.org/spec/UML/20110701/LM.xmi http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi Version 2.4.1 supersedes formal/2010-05-04. Copyright © 1997-2011 Object Management Group Copyright © 2009-2010 88Solutions Copyright © 2009-2010 Artisan Software Tools Copyright © 2001-2010 Adaptive Copyright © 2009-2010 Armstrong Process Group, Inc. Copyright © 2001-2010 Alcatel Copyright © 2001-2010 Borland Software Corporation Copyright © 2009-2010 Commissariat à l'Energie Atomique Copyright © 2001-2010 Computer Associates International, Inc. Copyright © 2009-2010 Computer Sciences Corporation Copyright © 2009-2010 European Aeronautic Defence and Space Company Copyright © 2001-2010 Fujitsu Copyright © 2001-2010 Hewlett-Packard Company Copyright © 2001-2010 I-Logix Inc. Copyright © 2001-2010 International Business Machines Corporation Copyright © 2001-2010 IONA Technologies Copyright © 2001-2010 Kabira Technologies, Inc. Copyright © 2009-2010 Lockheed Martin Copyright © 2001-2010 MEGA International Copyright © 2009-2010 Mentor Graphics Corporation Copyright © 2009-2010 Microsoft Corporation Copyright © 2009-2010 Model Driven Solutions Copyright © 2001-2010 Motorola, Inc. Copyright © 2009-2010 National
    [Show full text]