An abstract class is one that can have no direct instances.

An abstract class has no direct instances logically, or by definition. But a class is not abstract merely because it happens to have no instances. For example, the class “PersonWhoCanRunAMileInLessThanThreeMinutes” happens to have no instances at present, but there is no logical reason why this should be the case. No doubt careful use of performance-enhancing drugs and twenty years of selective breeding could cause this class to be instantiated. For a class to be abstract it must be logically impossible, not physically impossible, that it be instantiated.

In addition, a class is not abstract merely because it does not correspond to a real-world entity. This mistake is commonly made by novices; it is not unusual to see beginners label classes like “BankAccount” or “Transaction” as abstract because they represent non-physical things. The correct term for these classes, as mentioned earlier, is conceptual.

As an example, consider a computer system that manages information about certain products that a business manufactures. The bulk of information about a product (e.g., price, delivery time, warranty duration) is encapsulated in a class called “Product”. However, we may choose to create classes to represent the specific products we produce, and have them as sub-classes of “Product”. In this case, by definition there are no direct instances of class “Product”, but there will be instances of the sub-classes of “Product”. Because “Product” is never directly instantiated, it is an abstract class.

What is gained by doing this? In short we have gained a measure of simplicity. By gathering most of the important information about the products into a single class (“Product”) we have removed the need to duplicate this information in the different sub-classes of “Product”.

Making “Product” abstract has two important benefits. First, the reader of the model will know immediately that “Product” has a particular role in the system, that of providing structure and simplification. Second, the compiler that generates the final program will know that there can be no direct instances of class “Product”. This means that (i) it does not have to use memory to store the details of the instances, because there are none, and (ii) it is able to prevent the programmer making some trivial mistakes. Consider this definition in Java:

abstract class Product
    {
    //... details go here
    }

    

If the program attempts to create an object of this class later, it can only be because the programmer has made an error. The compiler will flag any such attempt as a compile time error.

An abstract class can have abstract operations. These are operations that are specified, but not implemented. It is up to the subclasses to provide a full implementation of the abstract method.

An abstract class with no-subclasses is more than likely useless. If you find this on your models you have probably made a mistake.

It is possible to indicate that a class is abstract in a class diagram by adding the {abstract} tag beneath the class's name.