Inheritance is an important concept in object-oriented design. If a class derives from another class, it inherits all the properties of the superclass and can add further properties. Inheritance can take place over any number of levels. A class B, which inherits from a class A, can itself act as a superclass for classes C and D derived from it. Inheritance thus creates a tree of classes and their subclasses.

In addition to the reuse of properties, the inheritance relationship defines an "as-is" relationship. If we assume that the robot example from the References section comes from a factory planning application, then a robot (RobotSystem) is a device (Appliance) in the broadest sense. All devices may have an inventory number and are assigned to a location (Location) in a building. In addition to robots, however, there are many other items of equipment, such as conveyor belts (Conveyor), shelves and much more. The relation "robot is a fixture" is expressed via an inheritance relation between the classes for a robot and for a general fixture. In the diagram, the model would look like this.

An inheritance relationship not only ensures that all subclasses (RobotSystem and Conveyor) derived from a superclass (Appliance) inherit the properties of the superclass and therefore do not have to define them themselves, but it also ensures that all instances of all subclasses are assignable/usable in all places where an instance of the superclass is expected. If you had a reference to a Appliance elsewhere in the system modeled in this way, all instances of RobotSystem and Conveyor could be selected and assigned. Structuring the model in superclasses and subclasses is therefore the simplest and most direct way to control option lists for selections.

Abstract classes

In the example above, the class Device (Appliance) is so general that it cannot be used to create objects and use them in a factory plan. The class is only used to structure the model or as a target type for references to which all possible devices can be assigned. Such a class, of which there can be no instances, is called "abstract". This property can be set when a class is created and controls in the application whether an object can be created at a certain point or not.

Unlike in UML, a TopLogic model does not distinguish between an abstract class and an interface. This has to do with the fact that TopLogic classes cannot have general methods (code), only properties. A property of a TopLogic class is equivalent to a set and get method that sets or queries the value of the property. In this sense, calculated attributes are a special form of methods (without arguments) that can be defined in a TopLogic model. If you take these restrictions into account, you can describe a concrete (non-abstract) TopLogic class with a class in UML and an abstract TopLogic class with a UML interface.

Multiple inheritance

In TopLogic, it is possible for a class to have more than one superclass. In this case, the class inherits the properties of all its superclasses. In models with multiple inheritance, special care must be taken to ensure that a property with the same name is not inherited from more than one superclass.