El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.
En total se cuentan con 13 diagramas diferentes, cuyos primeros 6 están a continuación, y los siguientes 7 están en la segunda parte.
Sirve para visualizar las relaciones entre las clases que involucran el sistema, sus atributos, operaciones (o métodos), y las relaciones entre objetos.
Elementos:
- Clase: Atributos, Métodos y Visibilidad (pública+, privada-, protegida#).
- Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
2. Diagrama de Objetos.
Se puede considerar un caso especial de un diagrama de clase. Los diagramas de objetos usan un sub conjunto de elementos de un diagrama de clase para enfatizar la relación entre las instancias de las clases en algún punto en el tiempo. Estos son útiles para entender los diagramas de clases. Estos no muestran nada diferente en su arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles.
Ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente puede comprender una gran porción de un sistema.
(También te puede interesar: Las 19 Claves del Buen Programador)
4. Diagrama de Estructura Compuesta.
Es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el comportamiento de clasificador contenido. Se describe la forma en que las clases se pueden mostrar como elementos compuestos exponiendo interfaces y conteniendo puertos y partes.
- Parte: Representa un conjunto de una o más instancias que pertenecen a una instancia del clasificador contenida. Una parte se puede quitar de sus padres antes de que el padre se elimine, para que la parte no se elimine al mismo tiempo.
- Puerto: Es un elemento escrito que representa una parte visible externa de una instancia del clasificador contenido. Un Puerto puede especificar los servicios que un clasificador provee así como también los servicios que este requiere de su entorno.
- Interface: es similar a una clase pero con un número de restricciones. Todas las operaciones de la interfaz son públicas y abstractas, y no proveen ninguna implementación predeterminada. Todos los atributos de la interfaz deben ser constantes. Sin embargo, mientras que una clase puede solo heredar de una sola super- clase, puede implementar interfaces múltiples.
- Provista: Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador.
- Delegar: se usa para definir los trabajos internos de los puertos e interfaces externas del componente. Un conector delegar se muestra como una flecha con un estereotipo «delegar». Esto conecta un contrato externo de un componente como se muestra por sus puertos a la realización interna del comportamiento de la parte del componente.
- Colaboración: define un conjunto de roles co- operativos usados colectivamente para ilustrar una funcionalidad específica. Una colaboración debería solo mostrar los roles y los atributos requeridos para lograr sus tareas o funciones definidas.
- Representa: Se dibuja desde una colaboración a un clasificador para mostrar que una colaboración se usa en el clasificador.
- Ocurrencia: Se puede dibujar desde una colaboración a un clasificador para mostrar que la colaboración representa el clasificador.
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema. Esto muestra la configuración de los elementos de hardware (nodos) y muestra cómo los elementos y artefactos del software se trazan en esos nodos.
- Nodo: Elemento de HW o SW
- Instancia de Nodo: Su nombre está subrayado y tiene dos puntos antes del tipo de nodo base.
- Artefacto: Es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso, archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario y más.
- Ejemplos Asociación: una asociación representa una ruta de comunicación entre los nodos.
- Nodo como Contenedor: Un nodo puede contener otros elementos, como componentes o artefactos.
6. Diagrama de Paquetes.
Se usan para reflejar la organización de paquetes y sus elementos. Cuando se usan para representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualización de los espacios de nombres. Los usos más comunes para los diagramas de paquete son para organizar diagramas de casos de uso y diagramas de clase, a pesar de que el uso de los diagramas de paquete no es limitado a estos elementos UML.
- Combinación de Paquetes: Cuando un conector «merge» se usa en un paquete, la fuente de la combinación importa los contenidos importados y anidados del destino. Si existe un elemento dentro del origen y el destino, las definiciones del elemento origen se expandirán para incluir las definiciones del elemento contenidas en el destino. Todos los elementos agregados o actualizados por una combinación se notan por una relación de generalización desde el origen hasta el destino.
- Importación de paquetes: El conector «import» indica que los elementos dentro del paquete destino, que en este ejemplo es una sola clase, se importarán al paquete origen. El espacio de nombre del paquete origen ganará acceso a la Clase/s de Destino; el espacio de nombre del destino no está afectado.
- Conectores Anidados: El conector anidado entre el paquete destino y los paquetes de origen reflejan lo que muestran los contenidos del paquete.
(También te puede interesar: 6 Ejemplos En Los Que Un Bug Se Volvió Una Característica En La Historia Del Software (Misbugs))
Bueno hemos llegado al final de la primera parte de este artículo ¿qué opinas de este lenguaje? ¿es útil, le cambiarías algo? Queremos leer tus opiniones y observaciones así que no dudes en dejarlo en los comentarios.
No vienen todos los que nesesito
ResponderEliminar