UML significaLenguaje de Modelado Unificado. Es un lenguaje de modelado estandarizado que consiste en un conjunto integrado de diagramas desarrollado para ayudar a los desarrolladores de sistemas y software a especificar, visualizar, construir y documentar los artefactos de los sistemas de software, así como para modelado empresarial y otros sistemas no de software.

UML representa una colección de las mejores prácticas de ingeniería que se han demostrado exitosas en el modelado de sistemas grandes y complejos. UML es una parte importante del desarrollo de software orientado a objetos y del proceso de desarrollo de software. UML utiliza principalmente notaciones gráficas para expresar el diseño de proyectos de software. El uso de UML ayuda a los equipos de proyectos a comunicarse, explorar posibles diseños y validar el diseño arquitectónico del software. En este artículo, proporcionamos información detallada sobre qué es UML.

Orígenes de UML

El objetivo de UML es proporcionar una notación estándar que pueda ser utilizada por todos los métodos orientados a objetos y seleccionar e integrar los mejores elementos de las notaciones anteriores. UML está diseñado para una amplia gama de aplicaciones. Por lo tanto, proporciona constructos para una amplia variedad de sistemas y actividades (por ejemplo, sistemas distribuidos, análisis, diseño de sistemas y despliegue).

UML nació de la unificación de tres notaciones de modelado orientadas a objetos líderes:

1. Técnica de Modelado de Objetos (OMT) [James Rumbaugh 1991] – más adecuado para el análisis y sistemas de información intensivos en datos.
2. Booch [Grady Booch 1994] – muy fuerte para el diseño e implementación. Grady Booch trabajó extensamente con el idiomaAda y fue un contribuyente principal al desarrollo orientado a objetos de ese lenguaje. Aunque el método Booch era potente, su notación no fue muy popular (muchas formas de nube en sus modelos – no muy ordenadas).
3. OOSE (Ingeniería de Software Orientada a Objetos [Ivar Jacobson 1992]) – caracterizado por un modelo llamado Casos de Uso. Los Casos de Uso son una técnica poderosa para comprender el comportamiento del sistema completo (un área donde el enfoque orientado a objetos había sido tradicionalmente débil).

En 1994, el mundo del software quedó impactado cuando Jim Rumbaugh, creador de OMT, dejó General Electric y se unió a Grady Booch en Rational Software. La colaboración buscaba fusionar sus ideas en un método unificado (el título provisional era “Método Unificado”).

Para 1995, Ivar Jacobson, creador de OOSE, también se unió a Rational, y sus ideas (especialmente el concepto de “Casos de Uso”) se incorporaron al nuevo método unificado – ahora llamado Lenguaje de Modelado Unificado 1. El equipo formado por Rumbaugh, Booch y Jacobson era cariñosamente conocido como los “Tres Amigos”.

UML también fue influenciado por otras notaciones orientadas a objetos en ese momento:

• Mellor y Shlaer [1998]
• Coad y Yourdon [1995]
• Wirfs-Brock [1990]
• Martin y Odell [1992]

UML también incluyó nuevos conceptos que no estaban presentes en otros métodos principales de la época, como mecanismos de extensión y lenguajes de restricción.

Historia de UML

1. Durante 1996, elGrupo de Gestión de Objetos (OMG) emitió la primera Solicitud de Propuesta (RFP), que sirvió como catalizador para que estas organizaciones colaboraran en una respuesta conjunta a la RFP.
2. Rational formó el consorcio UML Partners con varias organizaciones dispuestas a dedicar recursos a una definición sólida de UML 1.0. Las organizaciones que más contribuyeron a la definición de UML 1.0 incluyeron:
   • Corporación de Equipos Digitales
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Esta colaboración produjo UML 1.0, un lenguaje de modelado bien definido, expresivo, potente y de propósito general. Fue presentado a OMG como la respuesta inicial al RFP en enero de 1997.
4. En enero de 1997, IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies y Softeam también presentaron respuestas separadas al RFP ante OMG. Estas empresas se unieron a los Socios de UML para aportar sus ideas, y los socios produjeron conjuntamente una respuesta revisada de UML 1.1. UML 1.1 se centró en mejorar la claridad de los significados de UML 1.0 e incorporar aportaciones de los nuevos socios. Fue presentado a OMG para su consideración y adoptado en otoño de 1997. Las versiones avanzaron desde la 1.1 hasta la 1.5, seguidas por UML 2.0 hasta la 2.5 (la versión actual es UML 2.5).

¿Por qué UML?

A medida que el valor estratégico del software aumentaba para muchas empresas, la industria buscaba tecnologías para automatizar la producción de software y mejorar la calidad, al tiempo que reducía los costos y el tiempo de llegada al mercado. Estas tecnologías incluyen la tecnología de componentes, la programación visual, los patrones y los marcos. Las empresas también buscan formas de gestionar la complejidad a medida que aumenta su alcance y escala. En particular, reconocen la necesidad de abordar problemas arquitectónicos recurrentes como la distribución física, la concurrencia, la replicación, la seguridad, el equilibrio de carga y la tolerancia a fallos. Además, el desarrollo de la World Wide Web, aunque ha simplificado algunas cosas, ha agravado estos problemas arquitectónicos. El Lenguaje Unificado de Modelado (UML) fue diseñado para satisfacer estas necesidades.

1. Proporcionar a los usuarios un lenguaje visual de modelado listo para usar, expresivo, para desarrollar y intercambiar modelos significativos.
2. Proporcionar mecanismos de extensibilidad y especialización para ampliar los conceptos centrales.
3. Ser independiente de lenguajes de programación y procesos de desarrollo específicos.
4. Proporcionar una base formal para comprender el lenguaje de modelado.
5. Fomentar el crecimiento del mercado de herramientas orientadas a objetos.
6. Apoyar conceptos de desarrollo de nivel superior, como colaboraciones, marcos, patrones y componentes.
7. Integrar las mejores prácticas.

UML – Visión general

Antes de sumergirnos en la teoría de UML, presentemos brevemente algunos de los conceptos principales de UML.

Lo primero que hay que notar sobre UML es que hay muchos diagramas (modelos) diferentes con los que hay que familiarizarse. La razón de esto es que un sistema puede ser visto desde muchas perspectivas diferentes. El desarrollo de software implica a muchos interesados.

Por ejemplo:

• Analistas
• Diseñadores
• Programadores
• Pruebas
• QA
• Clientes
• Autores técnicos

Todas estas personas están interesadas en aspectos diferentes del sistema, y cada aspecto requiere un nivel diferente de detalle. Por ejemplo, los programadores necesitan comprender el diseño del sistema y ser capaces de traducir ese diseño en código de bajo nivel. En contraste, los autores técnicos se interesan por el comportamiento general del sistema y necesitan comprender la funcionalidad del producto. UML trata de proporcionar un lenguaje suficientemente expresivo para que todos los interesados puedan beneficiarse al menos de un diagrama UML.

A continuación se presenta una breve descripción de cada uno de los 13 diagramas mostrados en la estructura de diagramas de UML 2:

Diagramas estructurales muestran la estructura estática del sistema y sus partes a diferentes niveles de abstracción e implementación, y cómo están relacionadas. Los diagramas estructurales tienen siete tipos:

• Diagrama de clases
• Diagrama de componentes
• Diagrama de despliegue
• Diagrama de objetos
• Diagrama de paquetes
• Diagrama de estructura compuesta
• Diagrama de perfiles

Diagramas comportamentales muestran el comportamiento dinámico de los objetos en el sistema, que puede describirse como una serie de cambios a lo largo de tiempo. Existen siete tipos de diagramas comportamentales:

• Diagrama de casos de uso
• Diagrama de actividades
• Diagrama de máquinas de estado
• Diagrama de secuencias
• Diagrama de comunicación
• Diagrama de visión general de interacciones
• Diagrama de temporización

¿Qué es un diagrama de clases?

Un diagrama de clases es una técnica central de modelado utilizada en casi todos los métodos orientados a objetos. El diagrama describe los tipos de objetos en el sistema y las diversas relaciones estáticas que existen entre ellos.

Relaciones

Existen tres relaciones principales que son importantes:

1. Asociación – indica una relación entre instancias de tipos (por ejemplo, una persona trabaja para una empresa, una empresa tiene múltiples oficinas).
2. Herencia – la adición más obvia a los diagramas ER utilizados en programación orientada a objetos. Tiene una correspondencia directa con la herencia en el diseño orientado a objetos.
3. Agregación – una forma de composición de objetos en el diseño orientado a objetos.

Ejemplo de diagrama de clases

Para obtener más detalles sobre los diagramas de clases, lea el artículo ¿Qué es un diagrama de clases?

¿Qué es un diagrama de componentes?

En el Lenguaje Unificado de Modelado, un diagrama de componentes muestra cómo se conectan los componentes para formar componentes más grandes o sistemas de software. Ilustra la arquitectura de los componentes de software y sus dependencias. Estos componentes de software incluyen componentes de tiempo de ejecución, componentes ejecutables y también componentes de código fuente.

Ejemplo de diagrama de componentes

Para obtener más detalles sobre los diagramas de componentes, lea el artículo ¿Qué es un diagrama de componentes?

¿Qué es un diagrama de despliegue?

Los diagramas de despliegue ayudan a modelar los aspectos físicos de los sistemas de software orientados a objetos. Es un diagrama de estructura que muestra la arquitectura del sistema como el despliegue (distribución) de artefactos de software en destinos de despliegue. Los artefactos representan elementos concretos en el mundo físico que resultan del proceso de desarrollo. Modela la configuración en tiempo de ejecución en una vista estática y visualiza la distribución de artefactos en una aplicación. En la mayoría de los casos, implica modelar configuraciones de hardware y los componentes de software que residen en ellos.

Ejemplo de diagrama de despliegue

Para obtener más detalles sobre los diagramas de despliegue, lea el artículo ¿Qué es un diagrama de despliegue?

¿Qué es un diagrama de objetos?

Un diagrama de objetos es un grafo de instancias, que incluye objetos y valores de datos. Un diagrama de objetos estático es una instancia de un diagrama de clases; muestra una instantánea del estado detallado del sistema en un momento determinado. La diferencia es que un diagrama de clases representa un modelo abstracto compuesto por clases y sus relaciones, mientras que un diagrama de objetos representa instancias en un momento específico, que es inherentemente concreto. El uso de diagramas de objetos es bastante limitado, principalmente para mostrar ejemplos de estructuras de datos.

Diagrama de clases frente a diagrama de objetos – Un ejemplo

Algunas personas pueden encontrar difícil entender la diferencia entre los diagramas de clases UML y los diagramas de objetos UML porque ambos contienen bloques rectangulares con nombres, atributos y enlaces entre ellos, lo que hace que los dos diagramas UML se vean similares. Algunos incluso piensan que son iguales porque en las herramientas UML los símbolos de diagrama de clases y diagrama de objetos se colocan en el mismo editor de diagramas – el diagrama de clases.

Pero en realidad, los diagramas de clases y los diagramas de objetos representan dos aspectos diferentes de la base de código. En este artículo, proporcionamos algunas ideas sobre estos dos diagramas UML, qué son, cómo difieren y cuándo usarlos.

Relación entre el diagrama de clases y el diagrama de objetos

Crea ‘clases’ al programar. Por ejemplo, en un sistema de banca en línea, podrías crear clases como ‘Usuario’, ‘Cuenta’, ‘Transacción’, etc. En un sistema de gestión de aulas, podrías crear clases como ‘Profesor’, ‘Estudiante’, ‘Tarea’, etc. En cada clase hay atributos y operaciones que representan las características y comportamientos de la clase. Un diagrama de clases es un diagrama UML donde puedes visualizar estas clases, sus atributos, operaciones y relaciones entre ellas.

Un diagrama de objetos UML muestra cómo son las instancias de objetos de clases (dibujadas en un diagrama de clases UML) en un estado particular. En otras palabras, un diagrama de objetos UML puede considerarse como una instancia de cómo se utilizan las clases (en un diagrama de clases UML) en un estado específico.

Si no te gustan estas definiciones, echa un vistazo a los ejemplos de diagramas UML a continuación. Creo que entenderás su diferencia en segundos.

Ejemplo de diagrama de clases

El siguiente ejemplo de diagrama de clases representa dos clases: Usuario y Archivo adjunto. Un usuario puede subir múltiples archivos adjuntos, por lo tanto, las dos clases están asociadas mediante una asociación con multiplicidad 0…* en el lado del archivo adjunto.

Ejemplo de diagrama de objetos

El siguiente ejemplo de diagrama de objetos muestra cómo son las instancias de objetos de las clases Usuario y Archivo adjunto cuando Peter (es decir, un usuario) intenta subir dos archivos adjuntos. Por lo tanto, hay dos especificaciones de instancia para los dos archivos adjuntos que se van a subir.

Para obtener más detalles sobre los diagramas de objetos, lea el artículo ¿Qué es un diagrama de objetos?

¿Qué es un diagrama de paquetes?

Un diagrama de paquetes es un diagrama de estructura UML que muestra paquetes y dependencias entre paquetes. Los diagramas de paquetes permiten mostrar diferentes vistas de un sistema, por ejemplo, como una aplicación de múltiples capas (también llamada aplicación de múltiples niveles) – modelo de aplicación de múltiples capas.

Ejemplo de diagrama de paquetes

Para obtener más detalles sobre los diagramas de paquetes, lea el artículo¿Qué es un diagrama de paquetes?

¿Qué es un diagrama de estructura compuesta?

Los diagramas de estructura compuesta son uno de los nuevos artefactos añadidos a UML 2.0. Un diagrama de estructura compuesta es similar a un diagrama de clases y es un tipo de diagrama de componentes principalmente utilizado para modelar un sistema desde una perspectiva microscópica, pero representa la estructura interna de una sola parte en lugar de una clase completa. Es un diagrama de estructura estática que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posible.

El diagrama puede incluir partes internas, puertos a través de los cuales las partes interactúan entre sí o las instancias de la clase interactúan con el mundo exterior, y conectores entre partes o puertos. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para alcanzar un propósito. Cada elemento tiene un papel definido en la colaboración.

Ejemplo de diagrama de estructura compuesta

Para obtener más detalles sobre los diagramas de estructura compuesta, lea el artículo¿Qué es un diagrama de estructura compuesta?

¿Qué es un diagrama de perfil?

Con el diagrama de perfil, puedes crear estereotipos específicos para dominios y plataformas y definir sus relaciones. Puedes crear estereotipos dibujando formas de estereotipos y relacionarlos mediante composición o generalización a través de una interfaz centrada en recursos. También puedes definir y visualizar los valores etiquetados de los estereotipos.

Ejemplo de diagrama de perfil

Para obtener más detalles sobre los diagramas de perfil, lea el artículo¿Qué es un diagrama de perfil en UML?

¿Qué es un diagrama de casos de uso?

Un modelo de casos de uso describe los requisitos funcionales de un sistema en términos de casos de uso. Es un modelo de las funciones deseadas del sistema (casos de uso) y su entorno (actores). Los casos de uso permiten relacionar lo que el sistema debe hacer con cómo el sistema cumple esos requisitos.

Piensa en un modelo de casos de uso como un menú, como el que encuentras en un restaurante. Al mirar el menú, puedes ver qué platos están disponibles, los platos individuales y sus precios. También sabes qué tipo de cocina sirve el restaurante: italiana, mexicana, china, etc. Al mirar el menú, obtienes una sensación general de qué experiencia gastronómica te espera en ese restaurante. El menú en realidad está “imitando” el comportamiento del restaurante.

Debido a que es una herramienta de planificación tan poderosa, los modelos de casos de uso son utilizados por todos los miembros del equipo durante todas las fases del ciclo de desarrollo.

Ejemplo de diagrama de casos de uso

Para obtener más detalles sobre los diagramas de casos de uso, lea el artículo¿Qué es un diagrama de casos de uso?

¿Qué es un diagrama de actividades?

Un diagrama de actividades es una representación gráfica de flujos de actividades y acciones paso a paso con soporte para elección, iteración y concurrencia. Describe el flujo de control del sistema objetivo, por ejemplo, explorar reglas y operaciones comerciales complejas, describir casos de uso y procesos comerciales. En el Lenguaje Unificado de Modelado, los diagramas de actividades están destinados a modelar tanto procesos computacionales como organizativos (es decir, flujos de trabajo).

Ejemplo de diagrama de actividades

Para obtener más detalles sobre los diagramas de actividades, lea el artículo¿Qué es un diagrama de actividades?

¿Qué es un diagrama de máquinas de estado?

Un diagrama de estado es un tipo de diagrama utilizado en UML para describir el comportamiento del sistema basado en el concepto de statechart de David Harel. Los diagramas de estado representan los estados permitidos y las transiciones, así como los eventos que afectan a esas transiciones. Ayuda a visualizar todo el ciclo de vida de un objeto, facilitando así una mejor comprensión de los sistemas basados en estados.

Ejemplo de diagrama de máquina de estados

Para obtener más detalles sobre los diagramas de máquina de estados, lea el artículo¿Qué es un diagrama de máquina de estados?

¿Qué es un diagrama de secuencia?

Un diagrama de secuencia modela la colaboración de objetos según la secuencia temporal. Muestra cómo los objetos interactúan entre sí en un escenario particular de caso de uso. Con capacidades avanzadas de modelado visual, puedes crear diagramas de secuencia complejos con solo unos pocos clics. Además, algunas herramientas de modelado (como Visual Paradigm) pueden generar diagramas de secuencia a partir del flujo de eventos que definiste en las descripciones de casos de uso.

Ejemplo de diagrama de secuencia

Para obtener más detalles sobre los diagramas de secuencia, lea el artículo¿Qué es un diagrama de secuencia?

¿Qué es un diagrama de comunicación?

Similar a un diagrama de secuencia, un diagrama de comunicación también se utiliza para modelar el comportamiento dinámico de un caso de uso. A diferencia de los diagramas de secuencia, los diagramas de comunicación enfatizan más la colaboración entre objetos que la secuencia temporal. Son semánticamente equivalentes, por lo que algunas herramientas de modelado (como Visual Paradigm) permiten generar uno a partir del otro.

Ejemplo de diagrama de comunicación

Para obtener más detalles sobre los diagramas de comunicación, lea el artículo¿Qué es un diagrama de comunicación?

¿Qué es un diagrama de vista general de interacción?

Un diagrama de vista general de interacción se centra en una visión general del flujo de control de la interacción. Es una variante del diagrama de actividad donde los nodos son interacciones o ocurrencias de interacción. El diagrama de vista general de interacción describe las interacciones en las que se ocultan los mensajes y las líneas de vida. Puedes vincular a diagramas «reales» y lograr una alta navegabilidad entre diagramas en el diagrama de vista general de interacción.

Ejemplo de diagrama de vista general de interacción

Para obtener más detalles sobre los diagramas de vista general de interacción, lea el artículo¿Qué es un diagrama de vista general de interacción?

¿Qué es un diagrama de tiempo?

Un diagrama de tiempo muestra el comportamiento de los objetos durante un período de tiempo determinado. Los diagramas de tiempo son una forma especial de diagrama de secuencia. La diferencia entre los diagramas de tiempo y los diagramas de secuencia es que los ejes están invertidos, por lo que el tiempo aumenta de izquierda a derecha, y las líneas de vida se muestran en compartimentos separados dispuestos verticalmente.

Ejemplo de diagrama de tiempo

Para obtener más detalles sobre los diagramas de tiempo, lea el artículo¿Qué es un diagrama de tiempo?

Aprende UML. Dibuja UML.

Obtén la edición Comunitaria de Visual Paradigm – una herramienta UML GRATUITA que te ayuda a aprender UML más rápido y de forma más eficaz. La edición Comunitaria de Visual Paradigm admite todos los tipos de diagramas UML. Su modelador UML galardonado es intuitivo y fácil de usar.

Descarga gratuita

Glosario y terminología UML

• Clase abstracta – Una clase que nunca se instanciará. Nunca existen instancias de esta clase.
• Actor – Un objeto o persona que inicia eventos relacionados con el sistema.
• Actividad: Un paso o acción en un diagrama de actividad. Representa una operación realizada por el sistema o un Actor.
• Diagrama de actividad: Un diagrama de flujo mejorado que muestra pasos y decisiones en un proceso, así como operaciones paralelas, como un algoritmo o un proceso empresarial.
• Agregación – Es parte de otra clase. Se representa con un diamante hueco junto a la clase que lo contiene en el diagrama.
• Artefacto – Un documento que describe la salida de una etapa en el proceso de diseño. La descripción puede ser gráfica, textual o alguna combinación.
• Asociación – Una conexión entre dos elementos en el modelo. Esto podría representar una variable miembro en código, una asociación entre un registro de personal y la persona que representa, una relación entre dos clases de trabajadores, o cualquier relación similar. Por defecto, ambos elementos de una asociación se conocen mutuamente y son iguales. Una asociación también puede ser una asociación navegable, lo que significa que el extremo origen conoce al extremo destino, pero no al revés.
• Clase de asociación: Una clase que representa una asociación entre dos otras clases y añade información a ella.
• Atributo – Una característica de un objeto que se puede utilizar para referenciar otros objetos o almacenar información sobre el estado del objeto.
• Clase base: La clase que define atributos y operaciones heredadas por las subclases mediante una relación de generalización.
• Rama: Un punto de decisión en un diagrama de actividad. Varios transiciones surgen de una rama, cada una con una condición de guarda. Cuando el control llega a la rama, debe ser verdadera exactamente una condición de guarda, y el control sigue la transición correspondiente.
• Clase: Una categoría de objetos similares, todos descritos por los mismos atributos y operaciones, y todos compatibles con la asignación.
• Diagrama de clase – Muestra las clases en el sistema y las relaciones entre ellas.
• Clasificador: Un elemento de UML que tiene atributos y operaciones. Específicamente, Actores, Clases e Interfaces.
• Colaboración: Una relación entre dos objetos en un diagrama de comunicación, indicando que los mensajes pueden pasar de un objeto a otro.
• Diagrama de comunicación – Un diagrama que muestra cómo se realiza una operación, enfatizando los roles de los objetos.
• Componente: Una unidad desplegable de código en el sistema.
• Diagrama de componente: Un diagrama que muestra las relaciones entre diversos componentes e interfaces.
• Concepto – Un sustantivo o concepto abstracto que debe incluirse en el modelo de dominio.
• Fase de construcción – La tercera fase del Proceso Unificado Racional, en la que se construyen múltiples iteraciones funcionales en el sistema construido. Es aquí donde tiene lugar la mayor parte del trabajo.
• Dependencia: Una relación que indica que un clasificador conoce los atributos y operaciones de otro clasificador, pero no está directamente conectado a ninguna instancia del segundo clasificador.
• Diagrama de despliegue: Un diagrama que muestra las relaciones entre diversos procesadores.
• Dominio – La parte del universo de discurso con la que el sistema está involucrado.
• Fase de elaboración – La segunda fase del Proceso Unificado Racional, que permite una planificación adicional del proyecto, incluyendo iteraciones en la fase de construcción.
• Elemento: Cualquier elemento mostrado en el modelo.
• Encapsulamiento – Los datos dentro de un objeto son privados.
• Generalización – Indica que una clase es una subclase de otra (superclase). La flecha hueca apunta hacia la superclase.
• Evento: En un diagrama de estado, esto representa una señal, evento o entrada que hace que el sistema tome acción o cambie de estado.
• Estado final: En un diagrama de estado o diagrama de actividad, esto representa el punto en el que el diagrama finaliza.
• División: Un punto en un diagrama de actividad donde comienzan múltiples hilos de control paralelos.
• Generalización: Una relación de herencia en la que una subclase hereda y añade a los atributos y operaciones de una clase base.
• GoF – Patrones de diseño de los Cuatro Jinetes.
• Alta cohesión – Un patrón evaluativo GRASP que asegura que una clase no sea demasiado compleja y no realice funciones no relacionadas.
• Bajo acoplamiento – Un patrón evaluativo GRASP que mide el grado en que una clase depende o está conectada con otra clase.
• Fase de inicio – La primera fase del Proceso Unificado Racional que trata la conceptualización inicial y el inicio del proyecto.
• Herencia – Una subclase hereda atributos o características de su clase padre (superclase). Estos atributos pueden sobrescribirse en la subclase.
• Estado inicial: En un diagrama de estados o diagrama de actividades, esto representa el punto en el que comienza el diagrama.
• Instancia – Un objeto es una instancia de una clase. La clase actúa como una plantilla para crear objetos. Se pueden crear cualquier número de instancias de la clase.
• Interfaz: Un clasificador que define atributos y operaciones que forman un contrato de comportamiento. Una clase o componente proveedor puede optar por implementar la interfaz (es decir, implementar sus atributos y operaciones). Las clases o componentes cliente pueden entonces depender de la interfaz, utilizando así el proveedor sin conocer ningún detalle de la clase real del proveedor.
• Iteración – Una parte mini-proyecto en la que se agrega alguna pequeña funcionalidad al proyecto. Incluye un ciclo de desarrollo de análisis, diseño y codificación.
• Unión: Un punto en un diagrama de actividades donde múltiples hilos paralelos de control se sincronizan y vuelven a unirse.
• Miembro: Un atributo o operación en un clasificador.
• Fusión: Un punto en un diagrama de actividades donde diferentes caminos de control se unen.
• Mensaje – Una solicitud de un objeto a otro pidiendo al objeto receptor que realice alguna acción. Esto es esencialmente una llamada a un método en el objeto receptor.
• Método – Una función o procedimiento en un objeto.
• Modelo – El artefacto central de UML. Compuesto por diversos elementos organizados en jerarquías con relaciones entre ellos.
• Multiplicidad – Mostrado junto al cuadro de concepto externo en un modelo de dominio e indica la relación cuantitativa entre objetos y otros objetos.
• Navegación: Indica qué extremo de una relación conoce al otro extremo. Una relación puede tener navegación bidireccional (cada extremo conoce al otro) o navegación unidireccional (un extremo conoce al otro, pero no al revés).
• Notación – Documentación gráfica con reglas para crear métodos de análisis y diseño.
• Nota: Un comentario textual agregado a un diagrama para explicar el diagrama con más detalle.
• Objeto – En un diagrama de actividad, un objeto que recibe información de o proporciona información a una actividad. En un diagrama de colaboración o secuencia, un objeto que participa en el escenario descrito en el diagrama. Generalmente: una instancia o ejemplo de un clasificador dado (Actor, Clase o Interfaz).
• Paquete – Un grupo de elementos UML que pertenecen lógicamente juntos.
• Diagrama de paquetes: Un diagrama de clases en el que todos los elementos son paquetes y dependencias.
• Patrón – Una solución al problema de asignación de responsabilidades para las interacciones entre objetos. Es una solución con nombre para un problema común y bien conocido.
• Parámetro: Un parámetro de una operación.
• Polimorfismo – Mismo mensaje, diferentes métodos. También utilizado como un patrón.
• Privado: Nivel de visibilidad aplicado a un atributo o operación, indicando que solo el código dentro del clasificador contenedor puede acceder al miembro.
• Procesador: En un diagrama de despliegue, esto representa una computadora u otro dispositivo programable en el que se puede desplegar código.
• Protegido: Nivel de visibilidad aplicado a un atributo o operación, indicando que solo el código dentro del clasificador contenedor o sus subclases puede acceder al miembro.
• Público: Nivel de visibilidad aplicado a un atributo o operación, indicando que cualquier código puede acceder al miembro.
• Flecha de dirección de lectura – Indica la dirección de una relación en un modelo de dominio.
• Realización: Indica que un componente o clase proporciona una interfaz determinada.
• Rol – Utilizado en un modelo de dominio, es una descripción opcional sobre el papel desempeñado por una entidad.
• Diagrama de secuencia: Un diagrama que muestra la existencia de objetos a lo largo del tiempo y los mensajes intercambiados entre esos objetos a lo largo del tiempo para realizar cierto comportamiento. Diagrama de estado – Un diagrama que muestra todos los estados posibles de un objeto.
• Estado: En un diagrama de estado, esto representa una condición o estado del sistema o sub-sistema: lo que está haciendo en un momento dado, y sus valores de datos.
• Diagrama de estado: Un diagrama que muestra los estados de un sistema o sub-sistema, las transiciones entre estados y los eventos que provocan esas transiciones.
• Estático: Un modificador aplicado a un atributo que indica que solo hay una copia del atributo compartida entre todas las instancias del clasificador. Un modificador aplicado a una operación que indica que la operación es independiente y no opera sobre una instancia específica del clasificador.
• Estereotipo: Un modificador aplicado a un elemento de modelo que indica algo que normalmente no puede expresarse en UML. Esencialmente, los estereotipos permiten definir su propio «dialecto» de UML.
• Subclase: Una clase que hereda atributos y operaciones definidos por una superclase mediante una relación de generalización.
• Carril: Un elemento en un diagrama de actividad que indica qué parte del sistema o dominio es responsable de una actividad particular. Todas las actividades en un carril son responsabilidad del objeto, componente o actor representado por el carril.
• Caja de tiempo – Cada iteración tiene un límite de tiempo fijo con un objetivo específico.
• Transición: En un diagrama de actividad, esto representa el flujo de control de una actividad, rama, fusión, bifurcación o unión a otra. En un diagrama de estado, esto representa un cambio de un estado a otro.
• Fase de transición – La fase final del Proceso Unificado Racional en la que se capacita a los usuarios para utilizar el nuevo sistema y el sistema se pone a disposición de los usuarios.
• Lenguaje Unificado de Modelado – El Lenguaje Unificado de Modelado mejora el análisis y diseño de proyectos de software al permitir relaciones más estrechas entre objetos mediante documentación textual y gráfica.
• Casos de uso: En un diagrama de casos de uso, esto representa una acción realizada por el sistema en respuesta a una solicitud de un Actor.
• Diagrama de casos de uso: Un diagrama que muestra las relaciones entre actores y casos de uso.
• Visibilidad: Un modificador para un atributo o operación que indica qué código puede acceder al miembro. Los niveles de visibilidad incluyen Público, Protegido y Privado.
• Flujo de trabajo – Un conjunto de actividades que producen un resultado específico.

Libros populares de UML

Aquí tienes algunos de los libros de UML más vendidos que puedes leer para aprender UML:

1. UML Distillado: Una guía breve sobre el lenguaje estándar de modelado de objetos
2. UML 2 y el Proceso Unificado: Análisis y diseño orientado a objetos prácticos
3. Aprender UML 2.0
4. Creación de aplicaciones web con UML
5. Manual de referencia del Lenguaje de Modelado Unificado
6. Los elementos del estilo UML™ 2.0
7. UML para programadores Java
8. Esquema de Schaum de UML
9. Guía del usuario del Lenguaje de Modelado Unificado
10. Guía de certificación UML 2: Exámenes fundamentales e intermedios
11. Fundamentos del diseño orientado a objetos en UML
12. Aplicación del modelado orientado a casos de uso con UML: Un ejemplo comentado de comercio electrónico
13. Diseño de sistemas orientados a objetos flexibles con UML
14. Modelado orientado a casos de uso con UML
15. Análisis y diseño de sistemas con UML versión 2.0: Un enfoque orientado a objetos
16. UML 2.0 en una pizca
17. Análisis y diseño orientado a objetos con aplicaciones
18. UML explicado
19. Patrones de diseño: Elementos de software orientado a objetos reutilizable
20. El primer objeto: Desarrollo orientado a modelos ágil con UML 2.0

Enlaces relacionados

1. Herramienta profesional de diseño UML para modelado visual