Investigacion -Técnicas de modelado en UML

Vista previa del material en texto

Técnicas de modelado en UML
Diagrama de Casos de Uso
El diagrama de casos de uso pertenece a este último grupo, pero se trata de un modelo particular, porque muestra el comportamiento que se espera de un sistema o software en un caso de uso concreto. En comparación con el resto de los diagramas de comportamiento en UML, el diagrama de casos de uso es bastante estático, ya que solo puede emplearse para describir acciones y objetivos, pero no la secuencia exacta de procesos y acciones.
Elementos y estructura del diagrama de casos de uso 
Para garantizar que el diagrama de casos de uso sea comprensible para todo el mundo de un vistazo, se utilizan elementos estandarizados para elaborarlo. En primer lugar, hay tres elementos principales:
· Actor: tanto si es una persona, como un sistema, se representa con el dibujo de una figura humana esquemática. 
· Sistema: el sistema al que se refiere el caso de uso tiene forma de rectángulo. 
· Caso de uso: se muestra como una elipse que suele incluir un texto describiendo brevemente el proceso.
La relación entre estos elementos se representa con unas líneas de conexión llamadas asociaciones. Una línea recta entre el actor y el caso de uso evidencia que el actor y el caso de uso descrito en la elipse están relacionados. Una línea discontinua establece una relación entre diferentes casos de uso.
Diagrama de casos de uso en la práctica
En el diagrama de casos de uso, las funciones del sistema en cuestión se representan desde el punto de vista del usuario. Este actor no tiene que ser necesariamente un usuario humano, sino que el rol también puede atribuirse a un sistema externo que accede a otro sistema. 
Capacidad de extensión de los modelos UML
Si bien la asociación <<include >> requiere que ambos casos de uso se realicen, en el caso de la asociación <<extend>> esto depende de ciertas condiciones que se representan como el llamado punto de extensión en el diagrama de casos de uso en UML.
¿Nos permitiría crear sistemas escalables y fáciles de mantener a largo plazo?
El Diagrama de Casos de Uso en UML es una herramienta valiosa para capturar y comunicar los requisitos funcionales de un sistema. Si se utiliza correctamente, puede contribuir a la creación de sistemas escalables y fáciles de mantener a largo plazo.
Es importante destacar que el Diagrama de Casos de Uso es solo una parte del proceso de modelado y diseño de sistemas.
Diagrama de Clases
El diagrama de clases es un diagrama puramente orientado al modelo de programación orientado a objetos, ya que define las clases que se utilizarán cuando se pase a la fase de construcción y la manera en que se relacionan las mismas. Se podría equiparar, salvando las distancias, al famoso diagrama de modelo Entidad-Relación (E/R), no recogido en UML, tiene una utilidad similar: la representación de datos y su interacción.
Para representar la clase con estos elementos se utiliza una caja que es dividida en tres zonas utilizando para ello líneas horizontales:
· La primera de las zonas se utiliza para el nombre de la clase. En caso de que la clase sea abstracta se utilizará su nombre en cursiva. 
· La segunda de las zonas se utiliza para escribir los atributos de la clase.
Tanto los atributos como las funciones incluyen al principio de su descripción la visibilidad que tendrá. Esta visibilidad se identifica escribiendo un símbolo y podrá ser:
(+) Pública. Representa que se puede acceder al atributo o función desde cualquier lugar de la aplicación. 
(-) Privada. Representa que se puede acceder al atributo o función únicamente desde la misma clase. 
(#) Protegida. Representa que el atributo o función puede ser accedida únicamente desde la misma clase o desde las clases que hereden de ella (clases derivadas).
Relaciones
Una relación identifica una dependencia. Esta dependencia puede ser entre dos o más clases (más común) o una clase hacía sí misma (menos común, pero existen), este último tipo de dependencia se denomina dependencia reflexiva.
Las relaciones en el diagrama de clases tienen varias propiedades, que dependiendo la profundidad que se quiera dar al diagrama se representarán o no. Estas propiedades son las siguientes:
· Multiplicidad. Es decir, el número de elementos de una clase que participan en una relación. Se puede indicar un número, un rango… Se utiliza n o * para identificar un número cualquiera. 
· Nombre de la asociación. En ocasiones se escriba una indicación de la asociación que ayuda a entender la relación que tienen dos clases. 
Tipos de relaciones
· Asociación
Este tipo de relación es el más común y se utiliza para representar dependencia semántica. Se representa con una simple linea continua que une las clases que están incluidas en la asociación.
· Agregación
Es una representación jerárquica que indica a un objeto y las partes que componen ese objeto. Es decir, representa relaciones en las que un objeto es parte de otro, pero aun así debe tener existencia en sí mismo.
· Composición
La composición es similar a la agregación, representa una relación jerárquica entre un objeto y las partes que lo componen, pero de una forma más fuerte. En este caso, los elementos que forman parte no tienen sentido de existencia cuando el primero no existe.
· Dependencia
Se utiliza este tipo de relación para representar que una clase requiere de otra para ofrecer sus funcionalidades. Es muy sencilla y se representa con una flecha discontinua que va desde la clase que necesita la utilidad de la otra flecha hasta esta misma.
· Herencia. 
Otra relación muy común en el diagrama de clases es la herencia. Este tipo de relaciones permiten que una clase (clase hija o subclase) reciba los atributos y métodos de otra clase (clase padre o superclase). Estos atributos y métodos recibidos se suman a los que la clase tiene por sí misma. Se utiliza en relaciones «es un».
¿Nos permitiría crear sistemas escalables y fáciles de mantener a largo plazo?
El Diagrama de Clases proporciona una representación visual de la estructura del sistema, promueve la modularidad, la reutilización de código y la definición clara de responsabilidades. Estos aspectos contribuyen a la creación de sistemas escalables y fáciles de mantener a largo plazo al facilitar la comprensión, la evolución y la actualización del sistema.
Diagrama de Objeto
El diagrama de objetos fue definido en la ahora obsoleta especificación UML 1.4.2 como «Un gráfico de instancias, incluyendo objetos y valores de datos. Cada diagrama de objetos representa una instancia de un diagrama de clase; muestra una fotografía del estado detallado de un sistema en un punto específico del tiempo«. Esta misma especificación también afirma que el diagrama de objetos es «un diagrama de clase con objetos y no clases»
Elementos del diagrama de objetos
El diagrama de objetos se compone, principalmente, de los siguientes elementos
· Objetos: Cada objeto se representa con un rectángulo con su nombre y el de su clase en la parte superior subrayados y separados por dos puntos. En caso de ser un objeto anónimo no se escribe su nombre, dejando solo el de la clase.
Representación de un objeto
· Atributos: De igual forma que el diagrama de clases se muestra en un compartimento en la parte inferior del nombre del objeto. A diferencia de las clases, los atributos pueden tener valores asignados a ellos: 
Representación de un atributo
· Vínculos: Son asociaciones entre dos objetos y se representan con los mismos elementos que en el diagrama de clases. Por ejemplo, una asociación:
Asociación entre dos objetos
Diagrama de Componentes
Los diagramas de componentes UML representan las relaciones entre los componentes individuales del sistema mediante una vista de diseño estática. Pueden ilustrar aspectos de modelado lógico y físico.
En el contexto del UML, los componentes son partes modulares de un sistema independientes entre sí, que pueden reemplazarse con componentes equivalentes. Son autocontenidos y encapsulan estructuras de cualquier grado de complejidad. Los elementos encapsulados solo secomunican con los otros a través de interfaces. Los componentes no solo pueden proporcionar sus propias interfaces, sino que también pueden utilizar las interfaces de otros componentes, por ejemplo, para acceder a sus funciones y servicios. A su vez, las interfaces de un diagrama de componentes documentan las relaciones y dependencias en una arquitectura de software.
Los componentes suelen encapsular clases y, por lo tanto, también se los conoce como subformas o especializaciones de clases. Al igual que las clases, tienen una estructura compuesta y pueden definirse en más detalle por medio de atributos, métodos y operaciones, por ejemplo. Los componentes pueden ser una compilación de clases y, por ejemplo, ser implementados simultáneamente por varias clases en tiempo de ejecución. Aunque los componentes se equiparan a menudo con las clases, no son lo mismo. Si bien los componentes suelen requerir interfaces para la interacción, una clase también puede acceder directamente a un método.
¿Para qué se utilizan los diagramas de componentes UML?
Un diagrama de componentes proporciona una visión general del sistema y documenta la organización de los componentes del sistema y sus relaciones y dependencias mutuas. Los diagramas de componentes proporcionan una visión orientada a la ejecución, es decir, dan al desarrollador información sobre si un sistema funciona de forma coherente y cumple sus tareas y objetivos.
Los objetivos y propósitos más importantes de este tipo de diagrama son el modelado de sistemas de software basados en componentes, la especificación de arquitecturas de software y la división de sistemas en subsistemas (por ejemplo, interfaz gráfica de usuario/IGU, ámbito empresarial y capa de persistencia con base de datos relacional). Asimismo, se asignan tareas y funciones concretas a las subáreas y sus interfaces dentro del sistema.
Los diagramas de componentes UML son básicos para la comunicación con el cliente en el plano económico, porque, con ellos, los proyectos y planes son más tangibles y comprensibles y pueden explicarse mejor, ya que expresan los datos de manera sencilla. Los diagramas de componentes también facilitan la gestión del desarrollo de programas informáticos, por ejemplo, combinando clases en componentes manejables.
¿Qué elementos tiene un diagrama de componentes?
El lenguaje de modelado UML utiliza una notación normalizada para crear los diagramas de componentes, que se basa en su propio conjunto de caracteres y símbolos. La siguiente tabla explica los elementos más importantes para los diagramas de componentes UML 2.0:
Creación de un diagrama de componentes, con ejemplo
En nuestro ejemplo de un diagrama de componentes, mostramos cómo visualizar la estructura y la funcionalidad de un software de correo electrónico. Este modelo de componentes ilustra cómo sus tres módulos básicos interactúan a través de interfaces:
· Gestión del correo electrónico (1)
· Bandeja de entrada de correo electrónico (2)
· Bandeja de salida de correo electrónico (3)
La gestión del correo electrónico (1) es el centro de control del sistema, e interactúa con los usuarios y otros módulos de software a través de varias interfaces y puertos de servicio. Para que el usuario pueda supervisar si el sistema funciona correctamente, se proporcionan una interfaz y un puerto de servicio (management port) para administrarlo. La flecha discontinua “Use” indica que el usuario depende de esta interfaz para las tareas administrativas.
Los sistemas y componentes fuera de la arquitectura modelada se pueden integrar en el sistema a través de la interfaz “Get E-Mail”. Las funciones y los datos requeridos por el módulo Bandeja de salida de correo electrónico (3) son proporcionados por el módulo de gestión a través de la interfaz “Enviar correo electrónico”. El módulo de gestión también hace uso de servicios y funcionalidades mediante la interfaz “Recibir correo electrónico” del módulo Bandeja de entrada de correo electrónico (2). Gráficamente, las conexiones entre los componentes se ilustran con los símbolos de piruletas (lollipops) y enchufes (sockets) de las interfaces.
El gráfico de ejemplo muestra los componentes del sistema en una vista llamada de caja negra, que oculta el funcionamiento interno de estos para ofrecer una visión general más clara. En la vista de caja blanca, los diagramas de componentes muestran la estructura interna de los componentes. Por ejemplo, el componente de gestión (1) podría estar equipado con los subcomponentes funcionales “Frontend” y “Administración del sistema”, que ayudan al administrador a gestionar el sistema.
Diagrama de Despliegue
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.
¿Qué es y para qué sirve el diagrama de despliegue?
En ese sentido, el diagrama de despliegue es un tipo de diagrama UML que sirve para representar la relación de un sistema, utilizando nodos para realizar la expresión gráfica del mismo. Son de gran utilidad para representar sistemas de hardware y software y poder observar cómo se vería su relación de forma real.
Elementos de un diagrama de despliegue
Aunque está recomendado para personas que tengan conocimiento en programación, dibujar diagramas de despliegue es relativamente sencillo. Si estás iniciando en este mundo, puede que te resulte de gran ayuda conocer los elementos para dibujar un diagrama de despliegue.
Nodo
Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de una caja en tres dimensiones, como a continuación.
Instancia de Nodo
Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los dos puntos. El siguiente diagrama muestra una instancia nombrada de una computadora.
Estereotipo de Nodo
Un número de estereotipos estándar se proveen para los nodos, nombrados «cdrom», «cd-rom», «computer», «disk array», «pc», «pc client», «pc server», «secure», «server», «storage», «unix server», «user pc». Estos mostrarán un icono apropiado en la esquina derecha arriba del símbolo nodo.
Artefacto
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario y más.
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo «artifact» y un icono de documento, como a continuación.
Asociación
En el contexto del diagrama de despliegue, una asociación representa una ruta de comunicación entre los nodos. El siguiente diagrama muestra un diagrama de despliegue para una red, mostrando los protocolos de red como estereotipos y también mostrando multiplicidades en los extremos de la asociación.
Nodo como contenedor
Un nodo puede contener otros elementos, como componentes o artefactos. El siguiente diagrama muestra un diagrama de despliegue para una parte del sistema embebido y muestra un artefacto ejecutable como contenido por el nodo madre (motherboard).
Diagrama de Colaboración
El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.
¿Qué es un diagrama UML de colaboración?
Los diagramas de colaboración también se conocen como diagramas de comunicación. Pueden demostrar cómo se comunican los objetos para ejecutar las acciones específicas o un aspecto de un caso de uso. Los diseñadores pueden usar diagramas de colaboraciónpara explicar e identificar los roles de los objetos que realizan un flujo específico de eventos en un caso de uso. Son la principal fuente de información utilizada para establecer roles e interfaces de clase.
Escenarios de aplicación para diagramas de colaboración
Estos son algunos ejemplos de situaciones en las que los diagramas de colaboración pueden resultar beneficiosos:
· Crear una vista amplia de un grupo de objetos que colaboran entre sí, especialmente dentro de un sistema en tiempo real.
· Asignar la capacidad a las clases explorando los atributos del comportamiento de un sistema.
· Modelar colaboraciones, procesos u organización jerárquica en la arquitectura de un sistema.
· Proporcionar una descripción de los objetos que operan juntos dentro de un marco orientado a objetos.
· Para mostrar múltiples posibilidades y alternativas para el mismo caso de uso.
· Para ilustrar la ingeniería de avance y retroceso.
· Capturar la información que pasa entre los objetos.
· Para visualizar la lógica de un sistema complejo.
Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La comunicación muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.
Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales están menos claras.
Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones. 
Beneficios de un diagrama de colaboración
· Refuerza los aspectos estructurales de un sistema de interacción que es cómo se conecta la línea de vida.
· Los mensajes transmitidos en secuencia se muestran mediante la numeración jerárquica de cada mensaje.
· Permite centrarse en los elementos estructurales y no en el flujo del mensaje como se indica en los diagramas de secuencia.
Símbolos y componentes del diagrama de colaboración
Enlaces: Los enlaces conectan objetos y actores. Estos son casos de asociaciones y cada enlace dentro del diagrama de clases se relaciona con una conexión.
Actor: Normalmente, existe una instancia del actor en el comienzo de la interacción. Si hay varias instancias de actores presentes en el mismo diagrama, concéntrate en mantenerlas en el exterior del diagrama.
Objeto: Se representa mediante un símbolo de objeto que muestra su nombre y subraya su clase, diferenciado por dos puntos.
Mensaje: Un mensaje es una interacción entre objetos que transmiten información con el objetivo de continuar con la acción. Un mensaje se muestra en los diagramas de colaboración como una flecha etiquetada, ubicada cerca de un enlace.
Diagrama de Secuencia
Un diagrama de secuencia es un tipo de diagrama de interacción en UML que representa el intercambio de mensajes entre diferentes objetos de un sistema para cumplir una funcionalidad. Define el comportamiento dinámico del sistema de información y se usa comúnmente para definir cómo se realiza un caso de uso, a menudo junto con un diagrama de casos de uso. 
El diagrama está construido a partir de dos dimensiones, y cada objeto tiene una columna, con mensajes intercambiados entre ellos representados por flechas. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama hasta la parte inferior. 
El diagrama se puede usar para comprender cómo interactúan los objetos de las clases mediante el intercambio de mensajes y, a menudo, se usa para comprender mejor el diagrama de clases. El diagrama se puede diseñar para que sea modular, reutilizable, ampliable y capaz de gestionar los cambios.
En resumen, el diagrama de secuencia si puede ser una herramienta útil para crear sistemas escalables y fáciles de mantener a largo plazo, siempre y cuando se tenga en cuenta el modularidad, la reutilización de componentes y la gestión de cambios.
Diagrama de Actividad
Un diagrama de actividad es un tipo de diagrama de comportamiento en UML que representa el flujo de actividades en un sistema o proceso. Es esencialmente una versión avanzada de un diagrama de flujo que modela el flujo de una actividad a otra. 
El diagrama se construye a partir de nodos y aristas, con nodos que representan acciones o decisiones y aristas que representan el flujo de control entre ellas.
 El diagrama se puede utilizar para describir cómo se coordinan las actividades para proporcionar un servicio en diferentes niveles de abstracción y cómo los eventos en un solo caso de uso se relacionan entre sí. 
El diagrama también se puede usar para modelar procesos comerciales y presentar problemas complejos de manera clara. Los beneficios de usar un diagrama de actividad incluyen hacer que el sistema sea más fácil de entender, mantener y modificar, y ahorrar tiempo y esfuerzo en el proceso de desarrollo.
No se puede determinar si el diagrama de actividad permite crear sistemas escalables y fáciles de mantener a largo plazo sin tener en cuenta otros factores. En resumen, el diagrama de actividad puede ser una herramienta útil para comprender el comportamiento dinámico de un sistema, pero no para sistemas escalables y fáciles de mantener a largo plazo sin tener en cuenta otros factores suficientes.
Diagrama de Estados
El objetivo de los diagramas de estado es describir el comportamiento de un sistema con la máxima precisión. Se utilizan para optimizar cualquier proceso de desarrollo donde sea útil visualizar los estados del objeto y las condiciones para que se produzca la transición de un estado a otro. Suelen emplearse, por ejemplo, en el diseño de sistemas embebidos (en inglés, embedded systems), donde las señales automatizadas y los procesos en segundo plano deben estar perfectamente coordinados.
Estructura y componentes
Aunque los diagramas de estado UML se basan solo en unos pocos elementos, combinarlos de manera inteligente nos permite representar fácilmente secuencias de estado complejas.
Los estados son el componente principal de un diagrama de estado. Cada estado real se muestra siempre en un rectángulo de esquinas redondeadas. Por ejemplo, una puerta puede tener dos valores de estado:
Los dos posibles estados de una puerta: puede estar abierta o cerrada, pero no ambas cosas al mismo tiempo.
Transición externa: cambio de estado
La transición que figura en el siguiente ejemplo se considera externa y tiene como resultado que el objeto cambie de estado (entry/exit).
Cuando se activa la alarma, el objeto cambia de estado: si hace un momento la alarma estaba activada, ahora está desactivada. 
Mediante los eventos es posible describir con más detalle las condiciones bajo las cuales se abandona un estado para pasar al siguiente. En el caso de la transición del estado inicial al primer estado real, no es necesario, pero se puede añadir más información de manera opcional.
Un evento desencadenante debe cumplir las siguientes tres condiciones:
entry: el evento se activa automáticamente cuando se desencadena un estado, es decir, en todas las transiciones entrantes. 
exit: el evento se desencadena cuando se abandona un estado, es decir, en todas las transiciones salientes. 
do: el evento se desencadena una y otra vez si no se cambia de estado. 
Los eventos también sepueden indicar mediante una flecha de transición.
Pseudoestados
Estado inicial: sin transición entrante y con una transición saliente que revela cuál es el estado al principio de la secuencia. 
Estado final: sin transición saliente; fin de la secuencia de comportamiento. 
Bifurcación: división en varios estados paralelos. Sincronización (en inglés, join): sincronización de varios estados paralelos. 
Unión: nodo de unión de varias transiciones en serie. 
Elección: nodo desde el cual pueden iniciarse diversas transiciones sobre la base de una decisión previa. 
Punto de entrada: síntesis de transiciones similares que entran en un estado compuesto. 
Punto de salida: síntesis de transiciones similares que se originan en un estado compuesto. 
Historial superficial: almacenamiento del último subestado activo de un estado compuesto. 
Historial profundo: almacenamiento del último subestado activo de todos los niveles jerárquicos de un estado compuesto.
¿Nos permitiría crear sistemas escalables y fáciles de mantener a largo plazo?
Evaluar el potencial de un diagrama de estados para crear sistemas escalables y fáciles de mantener a largo plazo depende de varios factores. Aunque el diagrama de estados es una herramienta útil para modelar el comportamiento de un sistema, su eficacia en términos de escalabilidad y mantenibilidad puede verse influenciada por otros aspectos del proceso de desarrollo de software.
Bibliografía
(24 de Julio de 2020). Obtenido de https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/diagrama-de-casos-de-uso/
DiagramasUml. (s.f.). Obtenido de https://diagramasuml.com/objetos/
DiagramasUML. (s.f.). Obtenido de https://diagramasuml.com/diagrama-de-clases/
IONOS. (s.f.). Obtenido de https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/diagrama-de-componentes/
ionos. (20 de Julio de 2020). Obtenido de https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/diagrama-de-estado-uml/