Diagramas para el modelado de procesos de negocio


Definición


Entre los conceptos fundamentales de orientación a objetos se encuentran los siguientes:

  • Un modelo es una abstracción del problema que se intenta resolver.
  • Un dominio es el mundo de donde proviene el problema.
  • Un modelo consiste de objetos que interactúan entre sí enviándose mensajes.
  • Cada objeto posee características propias (atributos) y operaciones que puede realizar (métodos); los valores asignados a un objeto en determinado momento determinan su estado.
  • Una clase es un molde para describir un objeto que agrupa características (atributos) y comportamientos (métodos).
  • Los objetos son instancias de Clases.

Diagramas


A continuación, se enumeran los 5 diagramas que forman la base de UML, y dictan la manera en que es diseñado un sistema:

1.    Modelado del Dominio
2.    Caso de uso
3.    Objetos
4.    Colaboración          
5.    Componentes

Modelo de Dominio


Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.
Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.
El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterráneo de una ciudad cualquiera.
Resultado de imagen de modelado del dominio"

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una máquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más máquinas de venta así como empleados de limpieza, seguridad y operaciones.
Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuánto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.
El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

Caso de uso.


Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario. Es una herramienta valiosa dado que es una técnica de aciertos y errores para obtener los requerimientos del sistema, justamente desde el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema usando actores y casos de uso. Los casos de uso son servicios o funciones provistas por el sistema para sus usuarios.

Resultado de imagen de caso de uso 

Símbolos de los casos de uso


Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del Sistema.



Caso de uso: Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema.
Actor: Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con líneas conectoras. Los actores son similares a las entidades externas; existen fuera del sistema. El término actor se refiere a un rol específico de un usuario del sistema. (Cevallos, 2018)

Diagrama de componentes


El diagrama de componentes es uno de los principales diagramas UML. Está clasificado como diagrama de estructura y, como tal, representa de forma estática el sistema de información. Habitualmente se utiliza después de haber creado el diagrama de clases, pues necesita información de este diagrama como pueden ser las propias clases.
Este diagrama proporciona una vista de alto nivel de los componentes dentro de un sistema. Los componentes pueden ser un componente de software, como una base de datos o una interfaz de usuario; o un componente de hardware como un circuito, microchip o dispositivo; o una unidad de negocio como un proveedor, nómina o envío.
Algunos usos de este tipo de diagrama es el siguiente:
  • Se utilizan en desarrollo basado en componentes para describir sistemas con arquitectura orientada a servicios.
  • Mostrar la estructura del propio código.
  • Se puede utilizar para centrarse en la relación entre los componentes mientras se ocultan los detalles de las especificaciones.
  • Ayudar a comunicar y explicar las funciones del sistema que se está construyendo a los interesados o stakeholders.

Diagrama de componentes

Mientras que otros diagramas UML describen la funcionalidad de un sistema, los diagramas de componentes se utilizan para modelar los componentes que ayudan a hacer esas funcionalidades, representando la forma en la que estos se organizan y sus dependencias.
En esta entrada dedicada al diagrama de componentes veremos qué es un diagrama de componentes, los símbolos de este diagrama y cómo dibujar uno de forma muy sencilla. Al final del artículo podrás encontrar unos cuantos diagramas
Para su construcción se debe plantear en primer lugar identificar los componentes que utilizará el sistema de información, así como las distintas interfaces. Una forma típica y común para una primera aproximación en sistemas sencillos es utilizar un componente central al que los demás componentes se unen, y que se utiliza como componente gestor del sistema.

Elementos del diagrama de componentes


El diagrama de componentes está formado por tres elementos: Componente, Interfaz y Relación de dependencia.

Componente


Un componente es un bloque de unidades lógicas del sistema, una abstracción ligeramente más alta que las clases. Se representa como un rectángulo con un rectángulo más pequeño en la esquina superior derecha con pestañas o la palabra escrita encima del nombre del componente para ayudar a distinguirlo de una clase.
Un componente puede representar dos tipos de elementos: componentes lógicos (como por ejemplo componentes de negocio o proceso) o componentes físicos (como componentes .NET, EJB…). Por ejemplo, en una aplicación desarrollada en java habrá, con total seguridad, varios componentes “.java”, que son componentes lógicos del sistema.
Es representado a través de un rectángulo que tiene, a su vez, dos rectángulos a la izquierda, tal y como se muestra en la siguiente imagen:
Otra notación, utilizada en las últimas versiones de UML consiste en un rectángulo con un rectángulo más pequeño en la esquina superior derecha con pestañas.

También es posible utilizar el diagrama de paquetes para hacer un conjunto de varios módulos. Con esto se consigue representar la unión de esos módulos para un fin concreto. (Magazine pro, 2019)

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. 

Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.
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. (Sosa, 2007)




Diagramas de objetos.


Un diagrama de objetos UML representa una instancia específica de un diagrama de clases en un momento determinado en el tiempo. Cuando se lo representa visualmente, verás muchas similitudes con el diagrama de clases.
Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos, las tres cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría tener con este banco en particular. Los atributos de clase son diferentes para cada tipo de cuenta.
No obstante, los diagramas de objetos no se limitan a casos de uso bancarios, ya que se puede crear fácilmente un diagrama de objetos para árboles genealógicos, departamentos corporativos o cualquier otro sistema con partes interrelacionadas.


Elementos del diagrama de objetos

Los diagramas de objetos son sencillos de crear: se componen de objetos, representados por rectángulos, conectados mediante líneas.

Objetos

Los objetos son instancias de una clase. Por ejemplo, si "coche" es una clase, un Altima 2007 de Nissan es un objeto de una clase.

Títulos de clases

Los títulos de clases son los atributos específicos de una clase dada. En el diagrama de objetos de árbol genealógico, los títulos de clases incluyen nombre, género y edad de los integrantes de la familia. Se pueden listar títulos de clases como elementos en el objeto o incluso en las propiedades del propio objeto (como el color).

Los atributos de clases se representan por medio de un rectángulo con dos pestañas que indica un elemento de software.

Enlaces

Los enlaces son líneas que conectan dos figuras de un diagrama de objetos entre sí. El diagrama de objetos corporativo siguiente muestra cómo los departamentos están conectados al estilo del organigrama tradicional. (LucidChart, 2019)




Bibliografía


Cevallos, K. (21 de AGOSTO de 2018). INGENIERIA DEL SOFTWARE. Obtenido de INGENIERIA DEL SOFTWARE: https://ingsotfwarekarlacevallos.wordpress.com/2015/06/04/uml-casos-de-uso/
LucidChart. (2019). Lucid Software Inc. Obtenido de Lucid Software Inc.: https://www.lucidchart.com/pages/es/diagrama-de-objetos-uml
Magazine pro. (2019). diagramasuml.com. Obtenido de diagramasuml.com: https://diagramasuml.com/componentes/

Sosa, H. E. (2007). diagramasumlerickolmososati102.weebly.com. Obtenido de diagramasumlerickolmososati102.weebly.com: https://diagramasumlerickolmososati102.weebly.com/diagramas-de-colaboracioacuten.html

Comentarios

Entradas populares de este blog