UML (Lenguaje de modelado unificado)
Los diagramas de clase UML son diagramas que muestran las clases, sus atributos y operaciones, así como los diversos tipos de relaciones que existen entre las clases. Es un lenguaje gráfico estándar para modelar software orientado a objetos.
Historia
Fue desarrollado a mediados de la década de 1990 como un esfuerzo de colaboración por James Rumbaugh, Grady Booch e Ivar Jacobson, cada uno de los cuales había desarrollado su propia notación. La «U» significa «unificado», ya que sus tres desarrolladores combinaron las mejores características de los idiomas que habían desarrollado previamente. El custodio del estándar UML es el Object Management Group (OMG).
Algunos tipos de Diagramas que incluye UML son:
■Diagramas de clases, que describen las clases y sus relaciones.
■Diagramas de interacción, muestra el comportamiento de cómo los objetos interactúan entre sí.
■Diagramas de estado y diagramas de actividad, muestran cómo se comportan los sistemas.
■Diagramas de componentes y despliegues, muestran cómo los diversos componentes de los sistemas están organizados de manera lógica y física.
Algunas características de UML son:
■Los diagramas que cree con ellos están destinados a interconectarse para formar un modelo unificado.
■Tiene una semántica detallada, que describe matemáticamente el significado de muchos aspectos de sus anotaciones.
■Tiene mecanismos de extensión, que permiten a los diseñadores de software representar conceptos que no son parte del núcleo de UML.
■Tiene un lenguaje textual asociado llamado Object Restraint Language (OCL) que le permite establecer formalmente varios hechos sobre los elementos de los diagramas.
Metodología «,» Método «y» Proceso » : Se utiliza para ponerse de acuerdo en una empresa de que todos utilicen los mismos términos para entender de mejor manera.
¿Por qué usar un lenguaje de modelado estándar?
Porque los diagramas proporcionan abstracción. Un modelo puede llevar a los ingenieros de software a tener conocimientos sobre el sistema; pueden analizar el modelo (manualmente o usando herramientas) para descubrir problemas y otras propiedades de este. Los diagramas también pueden ayudar a comunicarse con el cliente y usuario.
Fundamentos de los diagramas de clase UML
Los símbolos principales que se muestran en los diagramas de clase son:
■Clases, que representan los tipos de datos en sí.
■Asociaciones, que muestran cómo las instancias de clases hacen referencia a instancias de otras clases.
■Atributos, que son datos simples encontrados en instancias.
■Operaciones, que representan las funciones realizadas por las instancias.
■Generalizaciones, que se utilizan para organizar las clases en jerarquías de herencia.
Clases
Asociaciones y multiplicidad
Se utiliza una asociación para mostrar cómo las instancias de dos clases se referenciarán entre sí. La asociación se dibuja como una línea entre las clases.
Asociaciones de etiquetado
Cada asociación se puede etiquetar, para hacer explícita la naturaleza de la asociación. Hay dos tipos de etiquetas, nombres de asociación y nombres de roles.
El nombre de una asociación debe ser un verbo o frase verbal, y se coloca al lado del medio de la asociación. Una clase se convierte en el sujeto y la otra clase se convierte en el objeto del verbo. Por ejemplo, la asociación entre Empleado y Empresa se llama worksFor. Puede leer la asociación en una dirección como «un empleado trabaja para una empresa».
Otra forma de etiquetar una asociación es usar un nombre de rol. Los nombres de roles se pueden adjuntar a uno o ambos extremos de una asociación. Un nombre de rol actúa, en el contexto de la asociación, como un nombre alternativo para la clase a la que está adjunto.
Analizando y validando asociaciones
Es muy común cometer errores al crear asociaciones; es particularmente fácil equivocarse en la multiplicidad. Por lo tanto, debe acostumbrarse a leer cada asociación en ambas direcciones para verificar que tiene sentido. Lo más importante, siempre debe preguntarse si una multiplicidad menos restrictiva también podría tener sentido en algunas circunstancias. Por menos restrictivo, nos referimos al uso de «muchos» u «opcional» en lugar de «uno» u otro número en específico.
El patrón de multiplicidad más común es uno a muchos. El siguiente más común es muchos a muchos. Juntos, estos dos patrones representan la gran mayoría de las asociaciones.
Clases de asociación (Relación entre dos objetos)
Debe nombrarse usando un sustantivo que refleje el significado de la asociación; el nombre de la asociación ya no es necesario.
Asociaciones reflexivas
Es posible que una asociación conecte una clase consigo misma. Ejemplos: Un curso puede requerir que se tomen primero otros cursos de requisitos previos. Si dos cursos cubren casi el mismo material, tomar uno de ellos puede impedir que un estudiante tome el otro, y viceversa, se dice que dichos cursos son mutuamente excluyentes.
La primera asociación es asimétrica, ya que los roles de las clases en cada extremo son claramente diferentes. El segundo, por otro lado, es simétrico. Para aclarar el significado, debe etiquetar una asociación reflexiva asimétrica utilizando nombres de roles en lugar de un nombre de asociación.
Enlaces como instancias de asociaciones
Un objeto es una instancia de una clase, entonces un enlace es una instancia de una asociación. Cada enlace conecta dos objetos.
Direccionalidad en asociaciones
Las asociaciones y enlaces son por defecto bidireccionales. Es decir, si un objeto Driver está vinculado a un objeto Car, entonces el Coche también está implícitamente vinculado a ese Driver. Si conoce el automóvil, puede averiguar su conductor, o si conoce al conductor, puede averiguarlo.
Es posible limitar la navegabilidad de los enlaces de una asociación agregando una flecha en un extremo.
Generalización
Recordará que se representan con un pequeño triángulo que apunta a la superclase. Deben seguir la regla isa y varias otras reglas también. Es una relación de herencia.
Evitar generalizaciones innecesarias
Un error común cometido por los principiantes es exagerar la generalización. Es común realizar clases que no tiene nada de diferente y pueden ser una misma clase ya que realizan una función parecida, no hay algo que las diferencien.
Manejo de múltiples conjuntos de generalización
Un conjunto de generalización es un grupo etiquetado de generalizaciones con una superclase común; la etiqueta describe los criterios utilizados para especializar la superclase en dos o más subclases. Es más claro unir todas las generalizaciones en un conjunto usando un solo triángulo abierto. Coloca la etiqueta al lado del triángulo abierto. La herencia múltiple generalmente agrega demasiada complejidad. Si embargos la herencia múltiple no existe en Java.
Evitar que los objetos cambien de clase
Otro problema que puede surgir al crear generalizaciones es evitar la necesidad de que los objetos cambien de clase. En general, un objeto nunca debería necesitar cambiar de clase. En la mayoría de los lenguajes de programación, cambiar de clase simplemente no es posible; por lo tanto, debe destruir completamente el objeto original y crear una nueva instancia de la segunda clase.
Diagramas de objetos
Un diagrama de objetos muestra un ejemplo de configuración de objetos y enlaces que pueden existir en un punto particular durante la ejecución de un programa. Los objetos se representar en rectángulos igual que una clase, pero la clase va subrayada y con dos puntos.
Un enlace entre dos objetos se muestra como una línea simple. Puede imaginar que cada uno de los dos objetos contiene un puntero al otro objeto unido por el enlace. Una asociación representa todos los enlaces entre dos clases que pueden existir. Se pone símbolo de multiplicidad en las asociaciones, pero nunca en los enlaces.
Decimos que un diagrama de objeto dado es generado por un diagrama de clase. Esto significa que contiene instancias y enlaces de las clases y asociaciones presentes en el diagrama de clases. Un diagrama de clase puede generar un número infinito de diagramas de objetos.
Probabilidades y extremos sobre diagramas de objetos
Los diagramas de objeto a veces se llaman diagramas de instancia. La mayoría de las herramientas para dibujar diagramas UML no proporcionan facilidades para dibujar diagramas de objetos. Esto se debe a que los diagramas de clases contienen una vista abstracta del sistema que es mucho más rica en información y siempre es necesaria, mientras que los diagramas de objetos se usan con menos frecuencia y solo para analizar escenarios específicos.
Asociaciones versus generalizaciones en el contexto de diagramas de objetos
■Una asociación describe una relación que existirá entre instancias en tiempo de ejecución.
■Una generalización describe una relación entre clases en un diagrama de clases.
Un diagrama de objeto nunca puede contener una generalización, y solo puede contener enlaces generados por asociaciones, no las asociaciones en sí.
Cuando muestra un diagrama de objeto generado por una asociación, muestra instancias de ambas clases unidas por esa asociación. Por otro lado, cuando muestra un diagrama de objetos generado por una jerarquía de herencia, muestra una sola instancia de una de sus clases concretas. Esa instancia única contendrá valores de los atributos definidos en su clase, así como aquellos atributos heredados de las superclases.
Cuando es un diagrama de objeto generado por una asociación, muestra las instancias de ambas clases unidad por esa asociación. Cuando es un diagrama de objetos generado por una jerarquía de herencia, muestra una sola instancia en una de sus clases concretas. La instancia única va a tener los valores de los atributos de la propia clase así como los atributos heredados de la superclase.
Funciones más avanzadas de diagramas de clases.
Agregación (Puede tener)
Es cuando un objeto tiene a otro objeto. El lado «completo» de la relación a menudo se denomina ensamblaje o agregado. Las agregaciones se especifican usando un símbolo de diamante, que se coloca al lado del agregado.
Como regla general, puede marcar una asociación como una agregación si se cumple lo siguiente:
■Puede indicar que las partes ‘son parte de’ el agregado, o que el agregado ‘está compuesto de’ las partes.
■Cuando algo posee o controla el agregado, entonces ellos también poseen o controlan las partes.
Composición (Contiene)
Es cuando un objeto contiene al otro objeto y el objeto contenido no puede existir sin la existencia del objeto que lo contiene.
Si se destruye el agregado, también se destruyen las partes. Se muestra una composición usando un diamante sólido (relleno), en lugar de uno abierto. Las partes de una composición nunca pueden tener vida propia; existen solo para servir al agregado.
En cierto sentido, podemos decir que la propagación es a la agregación como la herencia es a la generalización. Sin embargo, la principal diferencia es que la herencia es un mecanismo implícito, mientras que la propagación debe programarse cuando sea necesario.
Interfaces
Una interfaz es similar a una clase, excepto que carece de variables de instancia y métodos implementados. Normalmente contiene solo métodos abstractos, aunque también puede contener variables de clase. Podemos decir que una interfaz describe una parte del comportamiento visible de un conjunto de objetos. En UML se representa de dos maneras:
■Como un pequeño círculo (como una piruleta), etiquetado con el nombre de la interfaz.
■Como un rectángulo de clase, con la expresión «interfaz» en la parte superior y (opcionalmente) una lista de operaciones admitidas.
Un estereotipo es una forma de usar algo de la notación UML estándar (aquí un cuadro de clase) para representar algo especial (aquí una interfaz). Tenga en cuenta que los símbolos «y» se llaman guillemets; preferiblemente deben escribirse usando los caracteres especiales disponibles en la mayoría de las fuentes, no usando pares de signos menores o mayores que.
Restricciones, notas y texto descriptivo.
Hay tres formas en que puede agregar información adicional a un diagrama UML:
■Texto descriptivo y otros diagramas: Puede resaltar y expandir características importantes, y explicar por qué se tomaron ciertas decisiones.
■Notas. Una nota es un pequeño bloque de texto incrustado en un diagrama UML. La caja tiene una «esquina doblada». La nota puede explicar un detalle y actúa como un comentario en un lenguaje de programación.
■Restricciones. Una restricción es como una nota, excepto que está escrita en un lenguaje formal que puede ser interpretado por una computadora. En un diagrama UML, una restricción se muestra entre llaves.
Los fundamentos del lenguaje de restricción de objetos (OCL)
OCL es un lenguaje formal diseñado para mejorar las capacidades de modelado de UML. OCL es un lenguaje de especificación, no un lenguaje de programación completo. Las declaraciones de OCL simplemente especifican hechos lógicos (restricciones) sobre el sistema que deben permanecer verdaderos.
Una restricción no puede tener ningún efecto secundario; solo puede calcular un resultado booleano y no puede modificar ningún dato.
Métodos formales, lógica de primer orden, Z y OCL
Un método formal es un enfoque de ingeniería de software en el que todo está especificado en lógica, y se utilizan técnicas matemáticas para verificar la lógica. El tipo de lógica que se usa normalmente se llama lógica de primer orden.
Antes se usaba una notación llamada cálculo de predicados Z que es una sintaxis para la lógica y la teoría de conjuntos diseñada en la Universidad de Oxford para la especificación de software. Pero con el tiempo se creo OCL que fue desarrollado por IBM como una notación lógica que incorpora poderosas abstracciones y, al mismo tiempo, lee más como los lenguajes de programación a los que los ingenieros de software están acostumbrados. Z esta siendo reemplazado por OCL.
Las declaraciones OCL más simples se pueden construir a partir de los siguientes elementos:
■Referencias a nombres de roles, nombres de asociaciones, atributos y resultados de operaciones.
■Los valores lógicos verdadero y falso
■Operadores lógicos como y, o, =,>, <o <> (no es igual)
■Valores de cadena como: ‘una cadena’
■Enteros y números reales (este último tiene un punto decimal)
■Operaciones aritméticas *, /, +, –
Las expresiones OCL no tienen que escribirse directamente en un diagrama. Para evitar el desorden, puede escribirlos por separado y especificar un contexto para cada expresión, como se indica a continuación: context LineSegment inv:
startPoint <> endPoint
En esta expresión, inv significa que la declaración es una invariante (siempre verdadera) de la clase LineSegment.
Aspectos de los diagramas de clase UML que no hemos cubierto
■Calificadores. Estos son atributos que se muestran en un cuadro especial al final de una asociación. El valor del atributo es un identificador único, controlado por la clase a la que está adjunto.
■Una notación (un cuadro discontinuo que se superpone en la parte superior izquierda de una clase) para representar plantillas como las que se encuentran en C ++ o ahora Java 1.5. También se conocen como clases parametrizadas o clases genéricas.
■Mostrar dependencias entre clases utilizando una línea discontinua. Las dependencias pueden incluir una clase llamando a los métodos en otra, o ser amigo de otra (permitiendo el acceso a sus métodos privados).
■El metamodelo UML: un diagrama de clase que describe los elementos del propio UML.
■Asociaciones ternarias o N-arias. Estas son asociaciones que involucran más de dos clases. Siempre es posible convertirlos en una serie de asociaciones binarias. Por lo tanto, no recomendamos usarlos.
Un diagrama de clase para genealogía
Diagramas de clase versus diagramas de entidad-relación (ERD)
En los ERD, las «entidades» son similares a las clases y las «relaciones» son similares a las asociaciones. Las relaciones se muestran utilizando un símbolo de diamante grande, que es una de las características que los hace sustancialmente más voluminosos que los diagramas de clase. Además, los ERD estándar no muestran operaciones. Los ERD tradicionales tampoco mostraron herencia, pero los ERD extendidos (EERD) sí. Todavía es utilizado en la comunidad de base de datos.
El proceso de desarrollar diagramas de clase.
Modelos del dominio, versus modelos del sistema.
Diagramas de clases informales: Es in modelo de dominio exploratorio, donde se representa lo que ha aprendido sobre diversas entidades y relacione en el dominio, ayudan a entender mejor ese dominio. Pero no están destinados a modelar el software que se va a desarrollar. Es como un borrador básico para entender mejor el dominio.
Modelo de dominio del sistema: Durante el análisis de requisitos o las primeras etapas de diseño, deberá desarrollar un modelo que también contenga clases de dominio, asociaciones y atributos. Pero esta vez, el modelo representa datos que en realidad serán manipulados y almacenados por el sistema.
Las instancias generalmente se cargan y guardan en la base de datos a medida que se ejecuta el programa. Sin embargo, omite muchas clases necesarias para construir un sistema completo; de hecho, puede contener menos de la mitad de las clases del sistema.
Modelo de dominio exploratorio: desarrollado en análisis de dominio para aprender sobre el dominio. No modela solo cosas que realmente se implementarán
Modelo de dominio del sistema: modela aquellos aspectos del dominio representado por el sistema.
Modelo del sistema: incluye clases utilizadas para construir la interfaz de usuario y la arquitectura del sistema. Contiene elementos que no representan cosas en el dominio, pero que son necesarios para construir un sistema completo
Una secuencia sugerida de actividades.
Seguir un enfoque intermedio, que no es desorganizado ni demasiado rígido, parece ser lo mejor. Es necesario tener un punto de partida, y ese punto de partida debe identificar un conjunto inicial de clases. Secuencia sugerida para trabajar:
■Identificar un primer conjunto de clases candidatas.
■Comenzando con las clases más importantes, agregue las asociaciones y atributos que claramente serán necesarios.
■Resolver las generalizaciones más claras.
■Haga una lista de las principales responsabilidades de cada clase. Estas son declaraciones simples de funciones que debe realizar cada clase.
■Según las responsabilidades, decida las operaciones específicas que se necesitan.
■Repita todo el proceso, examinando el modelo para ver si necesita agregar o eliminar algo. Repita este paso según sea necesario hasta que el modelo sea satisfactorio.
Identificando clases
Hay dos formas de identificar clases:
■Cuando desarrolla un modelo de dominio, tiende a descubrir clases. Se pueden encontrar en material de origen, como descripciones de requisitos, notas de entrevistas o los resultados de sesiones de lluvia de ideas.
■Cuando trabaja en la interfaz de usuario o en la arquitectura del sistema, tiende a inventar las clases necesarias para resolver un problema de diseño en particular.
Una técnica simple para descubrir el conjunto inicial de clases de dominio para un sistema es mirar el material fuente, como una descripción de los requisitos. De esto, extrae los sustantivos y las frases nominales. Del conjunto inicial de nombres de clase, debe asegurarse de que no haya sustantivos o frases nominales que:
■Son redundantes (es decir, dos nombres para la misma clase).
■Representar claramente las instancias (aunque es posible que deba incluirse su clase).
■Son términos vagos o muy generales, que no transmiten información específica sobre el software propuesto.
Identificar asociaciones y atributos.
La mejor manera de comenzar es escoger las clases que se creen más importantes. Para cada uno de estos, decida sobre los datos claros y obvios que debe contener y sus relaciones con otras clases. Luego trabaje hacia afuera hacia las clases que son menos importantes. A medida que agrega una asociación o atributo, asegúrese de que sea relevante para la aplicación, que será necesario para implementar algún requisito.
Consejos para identificar y especificar asociaciones válidas
Para saber si debe existir una asociación, pregúntese si una clase posee, controla, está conectada, está relacionada, es parte, tiene como partes, es miembro o tiene como miembros alguna otra clase en su modelo. Las asociaciones en modelos de dominio normalmente se almacenarán en una base de datos. Entonces, si no cree que la información capturada por una asociación deba almacenarse, entonces tal vez la asociación debería eliminarse.
Consejos sobre cómo identificar y especificar atributos válidos
Los atributos se pueden identificar mirando la descripción del sistema y buscando información que debe mantenerse sobre las instancias de cada clase. Varios de los sustantivos que puede haber identificado originalmente, pero rechazado como clases, ahora pueden convertirse en atributos. Atributo debe ser singular.
Identificar generalizaciones e interfaces.
Hay dos formas de identificar generalizaciones: de abajo hacia arriba y de arriba hacia abajo. El enfoque ascendente agrupa clases similares, creando una nueva superclase, mientras que el enfoque descendente divide una clase compleja, creando nuevas subclases.
Para utilizar el enfoque de abajo hacia arriba, busca clases que tengan características en común. En general, si encuentra dos o más clases que tienen atributos, asociaciones u operaciones similares, entonces debería considerar crear una superclase común.
NOTA: Una instancia solo puede ser de una clase.
Asignación de responsabilidades a las clases.
Una responsabilidad es algo que el sistema debe hacer. En general, es importante distribuir las responsabilidades entre las clases para que ninguna clase tenga una participación injusta y, por lo tanto, se vuelva excesivamente compleja.
Hay varias categorías de responsabilidades que se pueden encontrar en una amplia variedad de clases:
■Establecer y obtener los valores de los atributos. Es una buena práctica hacer que los atributos sean privados y crear métodos públicos cuando sea necesario para permitir el acceso a ellos.
■Crear e inicializar nuevas instancias. A menudo, la responsabilidad principal de crear una instancia de una clase se le asigna a otra clase. (Esa otra clase tiene que llamar al constructor de la clase que se está instanciando).
■Carga y almacenamiento desde el almacenamiento persistente.
■Destrucción de instancias. Al igual que el proceso de creación de instancias, esto a menudo también requiere colaboración con otras clases.
■Agregar y eliminar enlaces de asociaciones
■Copiar, convertir, transformar, transmitir o emitir. Muchas aplicaciones tienen responsabilidades de este tipo, que requieren cambiar la información a otra forma.
■Calcular resultados numéricos, como la multa en un libro de biblioteca vencido.
■Navegación y búsqueda.
■Trabajo especializado que necesita la aplicación particular que no se ajusta a ninguna de las categorías anteriores.
Técnica de Papel y Lápiz: Muchas veces es más rápido utilizar papeles pequeños ya que se pueden pegar en una pizarra y permite que se puedan cambiar clases más fácilmente y no estar dibujando los diagramas cada vez que se hace un cambio. También al ser los papelitos tan pequeños limita a no hacer una clase extensa.
Operaciones de identificación
Se necesitan operaciones para realizar las responsabilidades de cada clase: puede haber varias operaciones por responsabilidad, pero una estará a cargo.
La operación que se encarga de cumplir con la responsabilidad normalmente se declarará pública. Se convierte en parte de la interfaz de todo el subsistema. Otros métodos que colaboran para realizar la responsabilidad serán lo más privados posible.
Implementación de diagramas de clase en Java
■Los atributos generalmente se implementan como variables de instancia. Debe elegir una clase adecuada, pero normalmente será una clase de la biblioteca estándar de Java, como String.
■Las generalizaciones se implementan usando la palabra clave extend, y las interfaces se implementan usando la palabra clave implements.
Referencia
C. Lethbridge, T., & Laganière, R. (2005). Object-Oriented Software Engineering (2nd ed., pp. 169-219). Uk: McGraw-Hill Education.
Blog Personal 