An agent is a widely overused term in computer science today. The term means different things in different contexts. In one context, it may mean entities that are intelligent, while in another it may mean entities that are autonomous or mobile. To our knowledge, there is no clear-cut definition for the term agent.

In the context of Magnetar, we think of an agent as an independent software module that encapsulates some specialized functionality. The execution of an agent in Magnetar is contingent on its environment. Thus, in its simplest form, an agent is a module with methods (implementing specialized behavior) that get invoked by state changes in the execution environment.

An API is a set of method declarations exposed by a software system.

A blackboard is a central component of an architectural pattern called the Blackboard Pattern. This pattern is highly applicable to systems that address problems with non-deterministic solutions. By non-determinism, we mean that there is at least some amount of unpredictability associated with solutions for such problems.

A blackboard architectural pattern consists of:

• a blackboard that stores data,
• a collection of knowledge sources (KS) that act on the data in the blackboard, and
• a controller that controls the triggering of the KSs.

In Magnetar, KSs are modeled as independent agents. The agents communicate solely through the blackboard by publishing data to the blackboard and getting notified of changes. The blackboard pattern has the following advantages:

• The calling sequence for the application need not be pre-defined - This makes is well suited to non-deterministic systems like AI systems.
• Concerns are well separated - The data, the behavior and the controller of the behavior are encapsulated into separate modules.
• Experimentation with different algorithms is possible since the knowledge sources that encapsulate algorithms, can be plugged in and out of the system relatively independently, if they are designed properly.

A CMF is a framework that lets users collaboratively create software products using templates for the corresponding product families. There are many abstract terms in this definition:

• Product families: Families of products are characterized by some commonality in their capabilities or design/implementation or the set of components they use etc. More generally, they target the same domain. For e.g., games like Chess, Go and Chinese Checkers can thought of as part of a family of games called "board games."
• Templates for product families: A template for a product family implements just the commonality among the products in the family. Typically, it consists of several software modules that are parameterized. The parameters to the modules represent the variance among the products. For e.g., a template for board games may have parameters that may have different values for different games - for e.g., the board, the pieces and the games rules - while implementing common behavior such as the code for moving a piece from one position to another and checking if a move keeps a piece within the bounds of the board.
• Create software products: Creating an actual software product from a product family is just the process of supplying the requisite parameters to the product family template. One can specify the instantiation parameters using a standard language like XML or a special language coined for just that product family.
• Collaboratively: By this, we mean that a team of users can co-operate over a network in the creation of a software product from the product family template. Collaboration allows people to combine their likes, dislikes, knowledge and expectations for a system when creating a new software product.

The process of designing and implementing the product family template would involve extensive analysis of the target domain to identify the commonalities among the different products and efficient encapsulation of them. The goal should be to keep the instantiation of a product itself as simple as possible, so that even non-programmers can create software by using the appropriate tools.

An Engine in Magnetar architecture is a component module that performs a specific task in the system. For example, a simulation engine is responsible for implementing the simulation logic in a system. An engine is essentially made up of a blackboard and a number of agents that act on the blackboard.

Each simulation that is combined to form a federation is a federate.

A federation is a combined simulation system created from constituent simulations.

Federated Object Model is an object model that identifies the essential objects, attributes, associations etc. that are exposed by a federation in a HLA compliant simulation system. There is one FOM per federation describing the shared information among the federates.

HLA is a standard technical architecture that is intended to promote interoperability among computer simulations and simulation reuse. It was developed by DoD under the leadership of Defense Modeling and Simulation Office (DMSO).

Terms such as meta-model and meta-meta-model were initially propounded by the Object Management Group (OMG) in their Four-Layer Model Driven Architecture (MDA). It is a relatively common practice to create models for computer-based systems using languages like UML (Unified Modeling Language), OMT ( Object Modeling Template) etc. These models are visual representations of a system and use notations like boxes, lines, etc., in accordance to the grammar prescribed by the corresponding language.

Meta-model is a model describing the model. In essence, it describes the grammar for a model. For example, a UML model contains entities like class diagrams, associations, aggregations etc. A UML meta-model is a language that describes the entities, the constraints on them and the relationships among them. The UML specification essentially acts as a meta-model for UML models. For a more machine-readable meta-model, one could use a UML DTD (Document Type Definition) to describe UML models. A UML DTD is distributed in XML format as part of XMI (eXtensible Metadata Interchange).

Meta-meta-model, as the name suggests, describes a meta-model. The idea of meta-meta-model arose from the realization that one specific modeling language would not be sufficient to model all kinds of systems. A meta-meta-model provides a way to define new modeling languages like UML.

In practice, a typical user doesn't have to be concerned with meta-meta or even meta-model. However, a modeling tool developer who wants to support multiple modeling languages must be able to describe multiple languages using a common format for his tool. OMG's initiative in this area is Meta-Object-Facility (MOF), which is a language to describe languages. XMI is the XML way of describing a MOF model.

Meta-programming is the process of specifying generic software templates from which new software components can be automatically instantiated by providing the requisite configuration parameters. Meta-programming greatly facilitates software reuse by producing "families" of software systems rather than a single system.

That is, a developer writes a framework that can create varying software systems when supplied with different parameters. The meta-programs, commonly written as declarative scripts supply these parameters to the framework and instantiate a specific product from the generic framework. We call them meta-programs because they are little programs about programs.

A module is a unit of decomposition of software that can be separately compiled and independently called from other programs. It typically encapsulates methods and related data structures. Modular design is a powerful technique for engineering software systems as it enhances re-usability, maintainability and flexibility of software.

In OMT terminology (that we use), Object Model refers to the structure of objects in a system. It is graphically represented using class diagrams depicting the classes that the objects in a system belong to and the relationships among them.

Simulation Object Model is an object model that identifies the objects, attributes, associations etc. that are exposed by a federate in a HLA-compliant simulation system. There is one SOM per federate.

In Magnetar architecture, a System is a collection of Engines. A system offers domain-specific functionality to its users by assembling a group of related engine components and configuring their object models for the target domain. For example, a collaborative board game system may consist of a graphics engine, a simulation engine and a network engine with object models that contain objects like Board, Square, Piece, etc.

This has become an industry-wide standard for storing data in human-readable format. Please see the W3C site for more information.