Die UML wurde in der Vergangenheit vor allem für die Modellierung betrieblicher Informationssysteme verwendet. Für andere Systemtypen wie eingebettete und/oder zeitkritische Systeme fehlten Sprachelemente, etwa um das Zeitverhalten darzustellen. Frühe Anpassungen wie die UML RT und ähnliche Alternativen wie ROOM ermöglichten die Anwendbarkeit auf diese Systemtypen.
Die UML war ursprünglich als Sprache zur Erleichterung der Kommunikation zwischen Entwicklern und mit Kunden gedacht. Die Diagramme dienten zum Veranschaulichen von Sachverhalten und Dokumente wurde damit illustriert. Fowler bezeichnet dies als UML-as-Sketch. Nur selten waren UML Modelle tatsächlicher, weiter verwendeter Bestandteil in Softwareprojekten. Zum Abschluss vieler Projekte stimmten die Diagramme aus den Dokumenten nicht mehr mit dem Code überein.
UML 1.5-Modelle werden in der praktischen Software-Entwicklung selten als wirkliche Zwischenergebnisse behandelt. Die Code-Generierung aus Modellen findet beispielsweise in nur eingeschränktem Umfang statt. Aus statischen Darstellungen (Klassendiagrammen) werden Code-Rahmen einer objektorientierten Programmiersprache erzeugt. Das Verhalten wird jedoch im Code implementiert. Fowler nennt diese Art der UML Anwendung UML-as-Blueprint.
Schwacher Diagramm-Begriff im Metamodell. Mit der UML 1.5 ist es über das XMI Format zwar möglich, UML-Modelle auszutauschen. Beim Austausch gehen jedoch die grafischen Informationen aus den Diagrammen, wie Position, Größe und Farbe der Elemente, verloren.
Diagramme und Möglichkeiten zur Spezifikation von Echtzeitsystemen fehlten.