6.037, IAP 2019—Project 4 1 MASSACHVSETTS INSTITVTE OF

Total Page:16

File Type:pdf, Size:1020Kb

Load more

6.037, IAP 2019|Project 4 1 MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Computer Science 6.037|Structure and Interpretation of Computer Programs IAP 2019 Project 4 Release date: 24 January, 2019 Due date: 1 February, 2019 at 2300h Code to load for this project: • The code for the evaluator: oo-eval.scm • There are also some files which your finished evaluator will be able to run: oo-util.scm, oo-types.scm, and oo-world.scm. You will not need these files at first. • All of these files can be retrieved from the course web site. You should begin working on the assignment once you receive it. It is to your advantage to get work done early, rather than waiting until the night before it is due. You should also read over and think through each part of the assignment (as well as any project code) before you sit down at the computer. It is generally much more efficient to test, debug, and run a program that you have thought about beforehand, rather than doing the planning \online." Diving into program development without a clear idea of what you plan to do generally causes assignments to take much longer than necessary. Word to the wise: This project can take a lot of time. You'll need to understand the general ideas of object-oriented programming and the implementation provided of an object-oriented pro- gramming system as discussed in lecture. You'll also need to have a firm grasp of the metacircular evaluator from the previous project, of which oo-eval.scm is a derivative. In truth, this assign- ment is much more an exercise in reading and understanding a software system than in writing programs, because reading significant amounts of code is an important skill that you must master. We strongly urge you to study the code before you try the programming exercises themselves | starting to program without understanding the code is a good way to get lost, and will virtually guarantee that you will spend more time on this assignment than necessary. In this project we will apply the concepts of object orientation to the evaluator which we built in the previous project. Rather than construct an object system on top of the language, like the code handout from lecture 6 did, we will instead build it into the language itself, adding additional special forms and data structures to make the concepts of \classes" and \objects" into first-class types and objects in the language. That is, while m-eval's goal was to mimic Scheme's semantics as closely as possible so that it could run itself, oo-eval intentionally adds entirely new syntaxes which will allow us to write simple code for oo-eval which would be considerably more complex in ordinary Scheme. Once you have finished implementing this Scheme variant, you will be able to run, and improve upon, the provided object-oriented text adventure game which uses the new syntax and semantics. One key thing to be careful of { symbols in DrRacket are case sensitive. For readability, we have tried to use upper case for names of object types and for names of methods. 6.037, IAP 2019|Project 4 2 The story so far. Cons of the Dead Later reports could never clearly nail down the exact source of the plague, but they all agree that late Saturday night of the 2018 Mystery Hunt puzzle-solving competition1, something snapped in some poor hunter. Instead of solving puzzles, he blindly went in search of more brains. The disease spread quickly through the ranks of the hunters, with one biting another until they were all shambling mockeries of their former selves. You were working late in lab, unplugged from the world and tooling away, blissfully unaware that anything was amiss, until Alyssa P. Hacker burst in and slammed the door shut. \Zombies!" she shouted. You looked through the window in the door and saw a slightly decomposing Ben Bitdiddle trying to figure out how to operate the numeric keypad on the combo lock. \That won't hold him for long, and there are more of them coming! Quick, help me barricade the door!" You both pile up printers, desks, and extra workstations against the door. \Now what?" you ask. Alyssa pulls a USB flash drive our of her pocket. \We hope the trouble I went through to get this was worth it. I hope you've got some food; this is going to be a long night." You nod, looking at the pile of snacks and soda you had brought with you. You were planning for an all-nighter, but not one like this. Can software save your mortal soul? Alyssa sits down at a computer and plugs in the drive. \Ben and I had been working for the last few hours on trying to determine the cause of the outbreak, with hopes we could solve it before it spread further. We hoped we might get lucky and find a way to restore these people before the National Guard shows up and starts roasting zombies. \We worked in separate locations (for improved fault tolerance) and the zombies found him first. The timing was particularly bad{ he had just Zephyred me that he'd had a break-through in the simulation he had written! And since he hadn't committed his changes yet to our git repository, I had no choice but to sneak through the zombie-infested halls over to where he was working and grab what I could off his computer." Alyssa looks through the contents of the drive and sighs, \Most of his code has been overwritten by nonsense words, probably as his mind faded away. I'll extract what I can..." After a few minutes, Alyssa looks at you, worried. \Ben wrote an object-oriented world simulator, so he could model various scenarios. I've recovered most of the code for his game world. But, this code isn't normal Scheme. It appears to have syntax for creating classes, instantiating objects, and so on. I know Ben had been working on adding an object system to his own personal scheme evaluator (b-eval), but that's in the part of his files that were corrupted." She sits back, dejected. You exclaim, \But I just finished writing a Scheme evaluator for 6.037! I can extend that to add an implementation of an object-oriented system in no time. Then we can run Ben's simulation and see what he discovered!" Test for success Alyssa tells you that Ben's object system has some complexity to it, but if you start with the basics and test each piece as you go, you should be able to build up to what you need, a layer at a time. 1http://web.mit.edu/puzzle/www/ 6.037, IAP 2019|Project 4 3 She says, \I'll help guide you as much as I can, including producing some test cases for you, but I need to focus on seeing if there are any patterns in this gibberish." She points at her screen. \Maybe Ben's zombie-addled subconscious had something to say{ I'll see if I can decipher any more code." If you just load and run oo-eval.scm, you'll find that it runs some test cases and produces an error message. This is because the file loads a series of test definitions, and then applies the run-all-tests procedure. You can comment-out that call if you like and run the individual tests as you go, but do occasionally run all the tests to make sure you don't have any regressions. \Think of this as test-driven development. except with the threat of zombies. That's not usually part of this methodology." She adds that though her tests will help, you still need to consider the requirements at each step and do your own testing in addition to what she cooks up. Getting started You start thinking about what you'll need to add to your evaluator: data abstractions internal to oo-eval for managing classes and instances, as well as the special forms or primitive procedures you'll expose to the oo-eval user to create classes, instantiate them, and invoke methods on the resulting instances. Alyssa interrupts your train of thought. \Hey, look at this. I was able to recover part of an older version of Ben's evaluator with his object system implementation. I should warn you, though{ he'd been feeling a little meta lately." Ben had decided on a simple implementation for instances: a tagged list of the symbol instance and an association list2 of all the instance's local state (slot names and current values). He would always include a special slot named :class which would refer to the class the instance was made from. A snippet of Ben's code looks like this: (define (instance? obj) (tagged-list? obj 'instance)) (define (instance-state inst) (second inst)) (define (instance-class inst) (read-slot inst ':class)) ; Given an object instance and slot name, find the slot's current value (define (read-slot instance slotname) (let ((result (assq slotname (instance-state instance)))) (if result (cadr result) (error "no slot named" slotname)))) 2A list of two-element lists, each containing a name and a value. 6.037, IAP 2019|Project 4 4 ; Create an object instance from a class ; Store list of slots' data (including class as :class) in a tagged-list ; All slots other than :class start out with the value 'uninitialized ; Need to call the constructor if there is one (define (make-instance class .
Recommended publications
  • Objects and Classes in Python Documentation Release 0.1

    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
  • The Pros of Cons: Programming with Pairs and Lists

    The Pros of Cons: Programming with Pairs and Lists

    The Pros of cons: Programming with Pairs and Lists CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College Racket Values • booleans: #t, #f • numbers: – integers: 42, 0, -273 – raonals: 2/3, -251/17 – floang point (including scien3fic notaon): 98.6, -6.125, 3.141592653589793, 6.023e23 – complex: 3+2i, 17-23i, 4.5-1.4142i Note: some are exact, the rest are inexact. See docs. • strings: "cat", "CS251", "αβγ", "To be\nor not\nto be" • characters: #\a, #\A, #\5, #\space, #\tab, #\newline • anonymous func3ons: (lambda (a b) (+ a (* b c))) What about compound data? 5-2 cons Glues Two Values into a Pair A new kind of value: • pairs (a.k.a. cons cells): (cons v1 v2) e.g., In Racket, - (cons 17 42) type Command-\ to get λ char - (cons 3.14159 #t) - (cons "CS251" (λ (x) (* 2 x)) - (cons (cons 3 4.5) (cons #f #\a)) Can glue any number of values into a cons tree! 5-3 Box-and-pointer diagrams for cons trees (cons v1 v2) v1 v2 Conven3on: put “small” values (numbers, booleans, characters) inside a box, and draw a pointers to “large” values (func3ons, strings, pairs) outside a box. (cons (cons 17 (cons "cat" #\a)) (cons #t (λ (x) (* 2 x)))) 17 #t #\a (λ (x) (* 2 x)) "cat" 5-4 Evaluaon Rules for cons Big step seman3cs: e1 ↓ v1 e2 ↓ v2 (cons) (cons e1 e2) ↓ (cons v1 v2) Small-step seman3cs: (cons e1 e2) ⇒* (cons v1 e2); first evaluate e1 to v1 step-by-step ⇒* (cons v1 v2); then evaluate e2 to v2 step-by-step 5-5 cons evaluaon example (cons (cons (+ 1 2) (< 3 4)) (cons (> 5 6) (* 7 8))) ⇒ (cons (cons 3 (< 3 4))
  • Csci 658-01: Software Language Engineering Python 3 Reflexive

    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].
  • The Use of UML for Software Requirements Expression and Management

    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.
  • Metaclasses: Generative C++

    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,
  • Meta-Class Features for Large-Scale Object Categorization on a Budget

    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.
  • Metaclass Functions: Generative C++

    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.
  • Middlesex University Research Repository

    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
  • Java for Scientific Computing, Pros and Cons

    Java for Scientific Computing, Pros and Cons

    Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language.
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications

    A Metaobject Protocol for Fault-Tolerant CORBA Applications

    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
  • On the Interaction of Object-Oriented Design Patterns and Programming

    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.
  • OMG Unified Modeling Languagetm (OMG UML), Infrastructure

    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