• Objects: complex entities supplied with data (properties, attributes) and behavior (functionality, programs, methods). They correspond to the real objects of the surrounding world.  
• Classes: sets of objects sharing properties and behavior.

Property, attribute or variable: data associated to an object or to a class of object.

• Abstraction: Each object in the system serves as model of an abstract "agent" which can carry out tasks, inform and change its state, and "communicate" with other objects in the system,  without having to reveal how these features are implemented. The processes, functions or methods can also be abstracted and when this happens, a range of techniques are required to widen an abstraction.  
• Encapsulation: Also known as "information concealment", this ensures that the objects cannot change the internal state of other objects unexpectedly; only the objects own internal methods can get access to its state. Each type of object exposes an interface to other objects which specifies how other objects can interact with it.  
• Polymorphism: Object references along with the collections may contain different types of objects, and the invocation of a behavior in a reference will produce the right behavior for the real type of the referent. When this happens at run-time, this last feature is called late allocation or dynamic allocation.  
• Inheritance: It organizes and facilitates polymorphism and encapsulation by enabling the objects to be defined and created as specialized types of pre-existing objects. The latter can share (and extend) their behavior without having to re-implement their behavior. This usually happens by grouping together the objects in classes and classes in trees or frames reflecting a common behavior.  
• Method: It is a program associated to an object (or to a class of objects), whose execution takes place by means of a "message".
• Message: a communication aimed at an object, whereby it receives the order to execute one of its methods by means of certain parameters.

• Structural Space: It is the place in which the objects of any class in FlexAB are created (instances of classes). Every class registers its objects within this space, in a tidy and hierarchical way. This space is that of all the FlexAB applications, not only that of one application, since one object can be in several applications.  
• Structural Relationship: Every object within FlexAB must have a spatial location. This means that for each class  the places in which the objects of that class can reside are defined, or can be created. The set of all these places create the structural relationships among objects, and this structure is of the graph type. That is, each object must be the child of at least another object so as to exist within FlexAB. As the structure is that of a tree, an object can be child of more than one parent.
• N-Functional Relationship: Every object within FlexAB can have apart from the Structural Relationship, which is mandatory, N Functional Relationships with other objects. This means that other types of relationships among objects can be defined freely, in view of the application under creation. An object can be the child of a parent A in the Structural Relationship, and the child of a parent (object) B in a relationship which could have been created as Connection Relationship for example.
• Link Relationship: Any object within FlexAB may have apart from the Structural Relationship, which is mandatory, a Link relationship, with other object in the space of the Structural relationships. This link causes the object to be in more than one place in the space, but must be unique.
• Inclusion Relationship: Any class within FlexAB may have other class included. This type of relationship makes, when classes become instantiated, both objects to be treated as one unit, but each of them with its own features. Classes that include other classes inherit their attributes.

• Classes: They group together those objects with Attributes in common. The instances of these classes are created in the Structural Space.  
• Relationship Classes: Structural Relationships are by themselves objects, and may have a class associated to them. These classes have the pecularity of requiring two objects so as to exist, or to instantiate themselves.
• Virtual Classes: They are classes of objects which do not exist in the Structural Space. They cannot have instances.  

• Copy and Paste: This generates a new instance of an object existing in the Structural Space. The object attributes defined as copiable replicate their value in the new instance.  
• Copy and Link: This generates a link in a new parent of an object existing in the Structural Space. Depending on the class of the new parent the attributes in this new instance of the object will be accesssible.  
• New: This generates a new instance of a class in the Structural Space.  
• Erase: It deletes an instance of the Structural Space, or a link of an object.