Herramienta UML - UML tool

Una herramienta UML es una aplicación de software que admite parte o la totalidad de la notación y la semántica asociadas con el Lenguaje de modelado unificado ( UML ), que es el lenguaje de modelado de propósito general estándar de la industria para la ingeniería de software .

La herramienta UML se utiliza ampliamente aquí para incluir programas de aplicación que no se centran exclusivamente en UML, pero que admiten algunas funciones del Lenguaje de modelado unificado, ya sea como complemento , como componente o como parte de su funcionalidad general.

Tipos de funcionalidad

Las herramientas UML admiten los siguientes tipos de funciones:

Diagramación

Diagramar en este contexto significa crear y editar diagramas UML ; es decir, diagramas que siguen la notación gráfica del Lenguaje de modelado unificado.

Los desarrolladores de software generalmente acuerdan el uso de diagramas UML como un medio para dibujar diagramas de, en su mayoría, software orientado a objetos . Cuando los desarrolladores dibujan diagramas de software orientado a objetos, generalmente siguen la notación UML. Por otro lado, a menudo se debate si esos diagramas son necesarios, durante qué etapas del proceso de desarrollo de software deben usarse y cómo (si es que lo hacen) deben mantenerse actualizados. La primacía del código de software a menudo conduce a que los diagramas sean obsoletos.

Ingeniería de ida y vuelta

La ingeniería de ida y vuelta se refiere a la capacidad de una herramienta UML para realizar la generación de código a partir de modelos y la generación de modelos a partir del código (también conocido como ingeniería inversa), mientras mantiene tanto el modelo como el código semánticamente coherentes entre sí. La generación de código y la ingeniería inversa se explican con más detalle a continuación.

Codigo de GENERACION

La generación de código en este contexto significa que el usuario crea diagramas UML, que tienen algunos datos de modelo conectados, y la herramienta UML deriva de la parte de los diagramas o de todo el código fuente del sistema de software. En algunas herramientas, el usuario puede proporcionar un esqueleto del código fuente del programa, en forma de plantilla de código fuente , donde los tokens predefinidos se reemplazan con partes del código fuente del programa durante el proceso de generación del código.

Existe cierto debate entre los desarrolladores de software sobre la utilidad de la generación de código como tal. Ciertamente, depende del dominio del problema específico y hasta qué punto se debe aplicar la generación de código. Hay áreas bien conocidas donde la generación de código es una práctica establecida, no limitada al campo de UML.

La idea de dejar completamente el "nivel de código" y comenzar a hacer "programación" directamente desde el nivel de diagrama UML (es decir, el nivel de diseño) es bastante debatida entre los desarrolladores. Esa es la visión de la arquitectura basada en modelos (MDA). Esta idea no tiene un uso tan generalizado en comparación con otras herramientas de desarrollo de software como compiladores o sistemas de gestión de configuración de software .

Una crítica frecuentemente citada es que los diagramas UML carecen de los detalles necesarios para contener la misma información que se cubre con la fuente del programa: Jack W. Reeves afirma que la encarnación final del diseño se encuentra en el código fuente. (Su declaración a menudo citada de que "el Código es el diseño" se ha malinterpretado en el sentido de que no hay necesidad de artefactos de diseño de software de nivel intermedio y alto, como diagramas UML o documentos de requisitos de software).

Ingeniería inversa

La ingeniería inversa en este contexto significa que la herramienta UML lee el código fuente del programa como entrada y deriva los datos del modelo y los diagramas gráficos UML correspondientes (a diferencia del significado algo más amplio descrito en el artículo " Ingeniería inversa ").

Algunos de los desafíos de la ingeniería inversa son:

  • El código fuente a menudo tiene información mucho más detallada de la que uno quisiera ver en los diagramas de diseño. Este problema se aborda mediante la reconstrucción de la arquitectura del software .
  • Los datos del diagrama normalmente no están contenidos con la fuente del programa, de modo que la herramienta UML, al menos en el paso inicial, tiene que crear algún diseño aleatorio de los símbolos gráficos de la notación UML o usar algún algoritmo de diseño automático para colocar los símbolos en una forma en que el usuario puede entender el diagrama. Por ejemplo, los símbolos deben colocarse en lugares del panel de dibujo en los que no se superpongan. Por lo general, el usuario de dicha funcionalidad de una herramienta UML tiene que editar manualmente esos diagramas generados automáticamente para lograr algo de significado. A menudo tampoco tiene sentido dibujar diagramas de toda la fuente del programa, ya que eso representa demasiados detalles para ser de interés al nivel de los diagramas UML.
  • Hay características de lenguaje de algunos lenguajes de programación , como las plantillas de clases o funciones del lenguaje de programación C ++ , que son notoriamente difíciles de convertir automáticamente a diagramas UML en toda su complejidad.

Intercambio de modelos y diagramas

El intercambio de metadatos XML (XMI) es el formato para el intercambio de modelos UML. XMI no admite el intercambio de diagramas UML , que permite la importación de diagramas UML de un modelo a otro.

Transformación de modelo

Un concepto clave asociado con la iniciativa de arquitectura impulsada por modelos es la capacidad de transformar un modelo en otro modelo. Por ejemplo, uno podría querer transformar un modelo de dominio independiente de la plataforma en un modelo específico de la plataforma Java para la implementación. También es posible refactorizar modelos UML para producir modelos UML más concisos y bien formados. Es posible generar modelos UML a partir de otras notaciones de modelado, como BPMN , que es en sí mismo un perfil UML . El estándar que admite esto se llama QVT para consultas / vistas / transformaciones. Un ejemplo de una solución QVT de código abierto es el lenguaje ATL creado por INRIA .

Ver también

Referencias

enlaces externos