Los mismos autores de este lenguaje dicen: con el 20% de UML se puede describir el 80% de un proyecto desarrollo. Efectivamente, como desarrolador se tiene que tener la capacidad para seleccionar los diagramas adecuados que describan el proyecto. Indudablemente no serán los mismos diagramas para el sistema de control del aeropuerto que para la página web de mis perros.

Por otro lado, no debe olvidarse que realizar uno de estos diagramas insume tiempo. Mas allá que el o los diagramas deben realizarse correctamente, el desarrollador debe considerar cuanto tiempo inverte en estas actividades. Indudablemente hay que hacer algunos (una buena cantidad), pero nunca debe olvidarse que lo contratan para desarrollar un software, no para hacer dibujitos. 

Estos diagramas se pueden organizar en dos grupos:

Los que describen el comportamiento del negocio, del sistema, de un  aspecto en particular, ...

• Diagrama de Actividad (Activity Diagram): Representa los procesos de negocio o la lógica de un sistema complejo. Incluye, opcionalmente, el flujo de datos. el nivel de abstracción suele ser bastante alto, pero pueden realizarse diagramas de actividad exploratorios cuando la lógica que se trata es compleja.
• Diagrama de Estados (State Machine Diagram): Describe los estados de un objeto así como la transición entre estados. Muy útil para los desarrolladores.
  
• Diagrama de Casos de Uso (Use Case Diagram): Muestra casos de uso individuales, actores y las relaciones entre ellos. El Proceso Unificado dice está dirigido por los casos de uso, esto significa que este diagrama (en el nivel de abstracción que sea) es la base del lenguaje de modelado y representación.
• Diagrama de Comunicación (Communication Diagram): Muestra las relaciones entre instancias de las clases y el flujo de mensajes entre ellas, antes (UML 1.0) se llamaba Diagrama de Colaboración. La cuestión tiene que ser realmente complicada para tener que utilizar estos diagramas.
• Diagrama de Interacción (Interaction Overview Diagram): Es una variante del Diagrama de Actividad, muestra un panorama general del flujo de control dentro del sistema o proceso de negocio.
• Diagrama de Secuencia (Sequence Diagram): Muestra la secuencia de la lógica, el órden en que se suceden los mensajes. Importante, especialmente cuando se trabaja en ambientes altamente compartidos.
  
• Diagrama de Tiempo (Timing Diagram): Muestra el cambio de estado de un objeto a través del tiempo en respuesta a eventos externos.

Nota: Los últimos cuatro diagramas también se clasifican como Diagramas de Interacción, dado enfatizan la interacción entre los objetos. Sin embargo no deja de ser un aspecto del comportamiento.

Los que describen la estructura, la forma, la organizaicón, ...

• Diagrama de Clases (Class Diagram): Muestra una colección de clases, sus tipos, sus contenidos y sus relaciones. Importantísimo representa el modelo de datos, y en consecuencia su persistencia en alguna forma de almacenamiento.
  
• Diagrama de Estructura (Composite Structure Diagram): Muestra la estructura interna de ua clase, componente o caso de uso. Especialmente debe indicar los puntos de interacción con otras partes del sistema.
• Diagrama de Componentes (Component Diagram): Describe los elementos que componen un sistema. Debe detallar los elementos o componentes, las interacciones y realaciones así cmo las interfaces públicas.
• Diagrama de Despliegue (Deployment Diagram): Muestra la arquitectura de ejecución de un sistema. Incluye nodos, entornos de hardware y software.
• Diagrama de Objetos (Object Diagram): Describe los objetos y sus relaciones en algún monento. Generalmente se usa en casos especiales para diagramas de clase o de comunicaciones.
  
• Diagrama de Paquetes (Package Diagram): Describe como los elementos del modelo se organizan en "paquetes", debe indicar la dependencia entre paquetes.

UML es ha establecido como el estandar en la industria de desarrollo de software. Es cierto que puede utilizarse otro típo de lenguaje, pero eso reduce la cantidad de personas que pueden leer (entender) el desarrollo.

No debe confundirse el lenguaje de modelado con la metodología del proceso de desarrollo. El lenguaje de modelado, es el conjunto de símbolos y reglas que utilizamos para comunicarnos; la metodología del proceso de desarrollo es una guía de actividades que pueden seguirse en el ciclo de vida de un proyecto de desarrollo de software. De hecho la metodología incluye un lenguaje.

Si yo fuese la única persona que desarrolla software en este mundo, no haría falta lenguaje dado que no tendría que comunicarme con nadie, que locura. Así como el entrenador de elefantes tiene unas 25 ordenes para comunicarse con estos animalitos, los desarrolladores de software necesitamos una forma para comunicarnos. Esta forma tiene que superar la barrera de los idiomas, por esa razón es que se utilizan dibujos (en general todos los podemos entender), símbolos unificados en todos los idiomas (como por ejemplo los símbolos matemáticos), etc.

UML, es unificado porque en algún momento los grandes escritores de lenguajes de modelado se pusieron de acuerdo en "unificar" todo lo que ellos hacián. Es mejor ser el dueño de un porcentaje de algo y no del cien por ciento de nada. A partir de ese acuerdo, tanto los autores como muchísimas personas ganaron bastante (y lo siguen haciendo) con este tema. Sin embargo, es un hecho que el software como ingeniería necesita de reglas claras y este aporte fortalece a la industria.

De ninguna manera se puede decir que UML es mejor o peor que otros lenguajes, lo que si puedo afirmar es que es "actual".