is a metamodel for representing code written in various languages. page 
It started as an interchange model, but within the context of GT is used as analysis target.
Now, the essence is not FAMIX, but a model (any model) that represents the system you are interested in.
A model is an informal or a formal representation of a system, made by an observer, to distinguish features of a system which are significant and to predict the consequences of a disturbance or change on the system.
There is no boundary when it comes to the model. The boundaries come from the importers that produce the objects. Of course, the default parsers / importers are about known languages, but that is just a way to sample the space.
We worked recently on a few example analyses to show what is possible. Here is an example in which we don't really build a complete FAMIX model, but go directly towards the system specific one (for toggles, in this case): Steering Agile Architecture by Example: the Feature Toggles From Open edX .
https://pavel-krivanek.github.io/famix/
Famix is a basic meta-modeling framework for Moose. It provides building blocks from which you can build own custom meta-model that fits your particular needs while you still can benefit from the advantages that Moose offers. site
## Historical perspective
In Moose preceding the versions 7, the FAMIX was a single meta-model that tried to cover the most common properties of all standard languages. This approach has several obvious advantages. With a single meta-model for all languages, you can easily do a software analysis on projects written in them and easily cover very common cases when you have a single project that uses multiple languages at once. The meta-model that provides descriptions of language elements like functions, classes or variables simply uniforms everything into a single frame.
This approach where only one meta-model is used has the single but very important disadvantage: it does not work generally. The FAMIX meta-model described well languages like Java, C#, C, C++ and Smalltalk. However, even in the case of these languages, the description was rough and haven't covered all details it could. For example, in the case of Smalltalk, the FAMIX was not describing entities like slots, traits, shared pools and so on. When you analyzed a model in this language, such details were hidden and slots had to be described only with the concept of instance variables. It was possible to investigate the name of slots, browser their users or computer metrics related to them but by default, FAMIX had no default way of modeling other slot properties like their definition.
The Pharo as one particular Smalltalk implementation slightly changed the language metamodel in version 7 by an introduction of stateful traits. It was not possible to cover it with the FAMIX meta-model. It was impossible to describe languages like SQL, various types of domain specific languages nor data without significant ad-hoc extensions to the FAMIX meta-model.
The need for meta-model unification lead sometimes to bizarre design decisions that had no sense in particular languages. For example, the methods were owned by general type, not by classes that are only a kind of types. The inheritance was described on the level of types too so then it was possible to theoretically have a Java model that has a primitive type int with several methods and inherits from float. For FAMIX it was still a valid model.
The basic meta-model for Moose prior versions 7 was named FAMIX (all characters were uppercase). The name for the new generation of the meta-model based on groups of traits is named simply Famix.
While FAMIX tried to unify the meta-models for various languages, it had to unite the most common concepts. Let's take a look at a simplified fragment of Java meta-model (figure ).
Java and C meta-model fragments
Java meta-model needs to describe methods and classes. Both of the meta-model elements share some behavior (e.g. they can have a link to source) so they inherit from common superclass JavaEntity. The C language does not have classes or methods. On the other hand, it needs to describe the concept of functions that is not used in Java.
The C++ has classes and it the programs can use methods and functions together. Functions and methods are to some extent similar behavioural entities so it makes sense to introduce a common generalization for them.
C++ meta-model fragment
While FAMIX tried to uniform all these languages, its metamodel followed the structure of the C++ metamodel. So when a user analyzed a C program using Moose, the tools provided a lot of data like metrics for classes that had not any sense in the context of the C program.
Next: Standalone Meta-Models