Diagramas UML by D'Joseph

UML DIAGRAMACIÓN

CONCEPTOS Y

BENEFICIOS DE LA DIAGRAMACIÓN UML

IMPORTANCIA PARA LOS PROYECTOS DE SISTEMAS DE INFORMACIÓN

DIAGRAMA DE ACTIVIDADES DIAGRAMA DE CLASES DE USOS Iuml#1 | Vol.1 may 2020. MARÍA pÁEZ. jOSÉ oRTIZ. aNAHILID PEÑALOZA

ÍNDICE

DIAGRAMACIÓN UML

DEFINICIÓN................................................................................3 CARACTERÍSTICAS......................................................................4 BENEFICIOS................................................................................5 IMPORTANCIA PARA LOS PROYECTOS DE SISTEMAS DE INFORMACIÓN....6

DIAGRAMAS UML

DIAGRAMA DE CLASES

DEFINICIÓN...................................................................................7 SIMBOLOGÍA..................................................................................7 EJEMPLOS DE SU APLICABILIDAD EN PROYECTOS DE SISTEMAS DE INFORMACIÓN.................................................................................7 DIAGRAMAS DE SECUENCIA DEFINICIÓN.....................................................................................8 SIMBOLOGÍA....................................................................................8 EJEMPLOS DE SU APLICABILIDAD EN PROYECTOS DE SISTEMAS DE INFORMACIÓN..................................................................................8 DIAGRAMA ESTADO DEFINICIÓN....................................................................................9 SIMBOLOGÍA..................................................................................9 EJEMPLOS DE SU APLICABILIDAD EN PROYECTOS DE SISTEMAS DE INFORMACIÓN................................................................................9

DIAGRAMA DE ACTIVIDADES DEFINICIÓN.............................................................................10 SIMBOLOGÍA............................................................................10 EJEMPLOS DE SU APLICABILIDAD EN PROYECTOS DE SISTEMAS DE INFORMACIÓN..........................................................................10 DIAGRAMA DE CASOS DE USOS DEFINICIÓN..............................................................................11 SIMBOLOGÍA............................................................................11 EJEMPLOS DE SU APLICABILIDAD EN PROYECTOS DE SISTEMAS DE INFORMACIÓN..........................................................................11

UML

CONCEPTOS Y DEFINICIONES DATO CURIOSO uml

¿QUÉ ES UML?

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos. UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistasprogramadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática.

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándres que dicen cómo se debe representar algo.

UN POCO DE HISTORIA

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los conocía, habían desarrollado otras metodologías. Se asociaron para brindar claridad a los programadores creando nuevos estándares. La colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos y mejoró el producto final. Los esfuerzos de estos pensadores derivaron en la publicación de los documentos UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su propio desarrollo de negocios. Ellos, junto con muchas otras personas y compañías, establecieron los recursos necesarios para desarrollar un lenguaje de modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye información sobre UML 2.0 en la segunda edición de 2005.

¿QUIÉN USA UML?

UML lo suelen usar las empresas o medianos o grandes equipos de desarrollo software con el objetivo de planificar y documentar cómo se construyen los programas informáticos complejos. Los usuarios individuales o pequeños equipos de desarrollo de 2 ó 3 personas no suelen usar herramientas UML. UML es un término que se relaciona mucho con “Ingeniería del software”. Al igual que un proyecto de edificio requiere la participación de un arquitecto y unos plantos, un proyecto software requiere la participación de ingenieros informáticos y una planificación y documentación.

UML

CARACTERÍSTICAS

DOCUMENTACIÓN La documentación es un aspecto integral de una herramienta UML. Diseñar es un proceso de interpretación de una solución de software. Es decir, su naturaleza, es un proceso abstracto que la única forma de determinarlo en forma certera, es una vez se haya confrontado primero con los constructores y después con los usuarios.

Una herramienta UML debe necesariamente proveer un esquema amplio que permita al diseñador comunicar en forma precisa los detalles, incluyendo anotaciones o comentarios. Además de esto, la herramienta UML debe apoyar la generación de informes y listados de los diferentes elementos del diseño.

Naturalmente, existen normas de sintaxis y semántica acerca de las reglas del negocio. El proceso de pensamiento del modelamiento de software utilizando UML, puede desperdiciarse si ciertos procesos de diseño no son capturados apropiadamente y bien documentados.

INGENIERÍA DIRECTA

Una herramienta UML no debe limitarse sólo a una representación pictórica de diagramas, sino que apoyar en forma directa y técnica la construcción de la aplicación en el lenguaje que se utiliza ( Java, C++, ASP, ASPX, PHP). La ingeniería directa, va moviéndose desde los requerimientos, hacia el diseño (modelamiento, procesos) para llegar a la implementación. Nuestra experiencia, frente a la carencia de una herramienta UML es este aspecto, nos llevó a desarrollar RobotDocIRS, con el cual intentamos automatizar la generación de código fuente en forma robusta y pertinente a los intereses de cada proyecto.

DIAGRAMA UML DE APOYO La herramienta UML debe apoyar todos los diagramas de los nueve que componen UML. La herramienta debe soportar la diagramación de casos de uso, permitir definir la visión estática con diagramas de clases y diagramas de objeto, permitir la definición de la visión dinámica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboración y el despliegue de componentes que forman el sistema.

INGENIERÍA INVERSA

Es exactamente lo contrario de Ingeniería Directa. En la ingeniería inversa, la herramienta UML carga todos los archivos de la aplicación o del sistema, se identifican las dependencias entre las distintas clases, y, esencialmente, reconstruye la estructura de todo el requerimiento, junto con todas las relaciones entre las clases. Ingeniería Inversa es una característica normalmente proporcionada por sofisticadas herramientas UML.

Es decir, se pretende utilizar el método como una aproximación práctica que permita generar modelos, utilizando el estándar UML, de aquellos sistemas cuya documentación es escasa, desactualizada o inexistente. (Ver conceptos de Data Mining y de Process Mining) Es necesario mencionar que la Ingeniería Inversa se utiliza para copiar patrones de aplicaciones que atienden un negocio particular, sólo accediendo al sistema como usuario (Es decir, sin tener los códigos). En efecto, al tener los formularios, navegación y reportes de un sistema se puede configurar el desarrollo de una nueva aplicación que realiza procesos similares o iguales que la original.

COLABORACIÓN EN EL MODELAMIENTO

Para el diseño o rediseño de sistemas complejos, puede haber

diferentes equipos participando el trabajo de diseño de diversos subsistemas en paralelo,

debería

colaboración

realizarse diseño

tiene

sobre

solo

que

ser

debidamente

ambiente.

Este

esfuerzo

sincronizado

con

herramienta UML.

BENEFICIOS 1 3

UML

BRINDAR A ARQUITECTOS DE SISTEMAS, INGENIEROS Y DESARROLLADORES DE SOFTWARE LAS HERRAMIENTAS PARA EL ANÁLISIS, EL DISEÑO Y LA IMPLEMENTACIÓN DE SISTEMAS BASADOS EN SOFTWARE, ASÍ COMO PARA EL MODELADO DE PROCESOS DE NEGOCIOS Y SIMILARES. HACER PROGRESAR EL ESTADO DE LA INDUSTRIA PERMITIENDO LA INTEROPERABILIDAD DE HERRAMIENTAS DE MODELADO VISUAL DE OBJETOS. NO OBSTANTE, PARA HABILITA UN INTERCAMBIO SIGNIFICATIVO DE INFORMACIÓN DE MODELOS ENTRE HERRAMIENTAS, SE REQUIERE DE UN ACUERDO CON RESPECTO A LA SEMÁNTICA Y NOTACIÓN.

MAYOR SOPORTE AL CAMBIO ORGANIZACIONAL, COMERCIAL Y TECNOLÓGICO. CON UML TODOS LOS CAMBIOS QUE SE CONSIDERE PARA UN SISTEMA, PUEDEN SER PROBADOS PRIMERO EN PAPEL Y SEGÚN LOS RESULTADOS QUE ARROJEN EN LA PLANIFICACIÓN Y DISEÑO SE CUANTIFICARA EL IMPACTO QUE GENEREN LOS CAMBIOS REALIZADOS ANTES DE APLICARLO DIRECTAMENTE EN EL SISTEMA, PERMITIENDO PROBAR DIFERENTES ALTERNATIVAS Y SELECCIONAR LA MÁS FAVORABLE PARA EL CLIENTE. MAYOR INDEPENDENCIA DEL PERSONAL DE DESARROLLO O PROGRAMADORES. TAMBIÉN PARTE DE UN BUEN DISEÑO DONDE TODO ESTE BIEN DOCUMENTADOS PERMITE QUE EL EQUIPO DE DESARROLLARES ENTIENDAN CON FACILIDAD EL SISTEMAS Y PUEDAN TENER MOVILIDAD EN EL PROYECTO SI VERSE ESTE AFECTADO EN SU CALIDAD, YA QUE CON ANTERIORIDAD SE TIENEN CONOCIMIENTO LA LABOR QUE SE VA A DESARROLLAR Y NO SE IMPROVISARA EN EL PROCESO.

IMPORTANCIA

PARA PROYECTOS DE SISTEMAS DE INFORMACIÓN Hoy en día, UML ("Unified Modeling Language") esta consolidado como el lenguaje estándar en el análisis y diseño de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código.En otros términos, así como en la construcción de un edificio se realizan planos previo a su construcción, en Software se deben realizar diseños en UML previa codificación de un sistema, ahora bien, aunque UML es un lenguaje, éste posee más características visuales que programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e

intercomunicarse

fácilmente,

estos

integrantes

siendo

los

analistas,

diseñadores, especialistas de área y desde luego los programadores.

COMPLEJIDAD

Entre más

Hoy en día, entre los lenguajes

complejo es el sistema que se desea

orientados a objetos más utilizados se

crear más beneficios presenta el uso de

encuentran Java y C#, además de otros

UML ("Unified Modeling Language"), las

más antiguos como C++ y SmallTalk,

razones

sin

aunque el programar en todos estos

embargo, existen dos puntos claves : El

lenguajes requiere experiencia previa

primero se debe a que mediante un

sobre la sintaxis y bloques específicos,

plano/visión global resulta más fácil

el paradigma empleado en todos ellos es

detectar las dependencias y dificultades

el mismo : Objetos.

esto

son

evidentes,

implícitas del sistema, y la segunda razón radica en que los cambios en una

Lo anterior permite que un

etapa inicial (Análisis) resultan más

análisis

fáciles de realizar que en una etapa

independiente del lenguaje en el que

final de un sistema como lo seria la fase

finalmente

intensiva de codificación.

Sistema misma

Puesto que UML es empleado en el

UML sea

sea

realizado

implementando

característica

que

permite

complejidad, era de esperarse que su

análisis y diseño de un sistema.

radica

otro

personal no familiarizado en lenguajes

análisis para sistemas de mediana-alta base

(Java,C#,C++,SmallTalk),

programación

participen

paradigma

empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.

CONCEPTOS/ DIAGRAMAS Entre los conceptos fundamentales de

orientación

encuentran

objetos

los

siguientes

:Un modelo es una abstracción del problema

que

intenta

resolver.Un dominio es el mundo de donde

proviene

problema

.Un modelo consiste de objetos que interactúan

entre

mensajes.Cada

sí

enviándose

objeto

posee

características propias (atributos) y operaciones

que

puede

realizar

(métodos); las valores asignados a un objeto

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.A continuación se enumeran los 9 diagramas que forman la base de UML, y dictan la manera en que es diseñado un sistema :UsoCasoClasesObjetosSecuen ciaColaboraciónDe Estado (Statechart)ActividadCom ponentesEjecución (Deployment)

DIAGRAMAS UML

l diagrama de clases es uno de los diagramas incluidos en UML 2.5 clasificado dentro de los diagramas de estructura y, como tal, se utiliza para representar los elementos que componen un sistema de información desde un punto de vista estático. Es importante destacar que, por esta misma razón, este diagrama no incluye la forma en la que se comportan a lo largo de la ejecución los distintos elementos, esa función puede ser representada a través de un diagrama de comportamiento, como por ejemplo un diagrama de secuencia o un diagrama de casos de uso.

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 EntidadRelación (E/R), no recogido en UML, tiene una utilidad similar: la representación de datos y su interacción. Ambos diagramas muestran el modelo lógico de los datos de un sistema.

ELEMENTOS DEL DIAGRAMA DE CLASE Clases: Las clases son el elemento principal del diagrama y representa, como su nombre indica, una clase dentro del paradigma de la orientación a objetos. Este tipo de elementos normalmente se utilizan para representar conceptos o entidades del “negocio”. Una clase define un grupo de objetos que comparten características, condiciones y significado. La manera más rápida para encontrar clases sobre un enunciado, sobre una idea de negocio o, en general, sobre un tema concreto es buscar los sustantivos que aparecen en el mismo. Por poner algún ejemplo, algunas clases podrían ser: Animal, Persona, Mensaje, Expediente… Es un concepto muy amplio y resulta fundamental identificar de forma efectiva estas clases, en caso de no hacerlo correctamente se obtendrán una serie de problemas en etapas posteriores, teniendo que volver a hacer el análisis y perdiendo parte o todo el trabajo que se ha hecho hasta ese momento.Bajando de nivel una clase está compuesta por tres elementos: nombre de la clase, atributos, funciones. Estos elementos se incluyen en la representación (o no, dependiendo del nivel de análisis).Para representar la clase con estos elementos se utiliza una caja que es dividida en tres zonas utilizando para ello lineas horizontales.

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 se representan con una linea que une las clases, esta línea variará dependiendo del tipo de relación.

SIMBOLOGÍA

as cosas que existen y que nos rodean se agrupan naturalmente en categorías. Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta clase se encuentran: "acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”.

Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que representan las asociaciones o maneras en que las clases se relacionan entre si.

EJEMPLO

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.Se representa con una línea que tiene un rombo en la parte de la clase que es una agregación de la otra clase (es decir, en la clase que contiene las otras). 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. Es decir, cuando el elemento que contiene los otros desaparece, deben desaparecer todos ya que no tienen sentido por sí mismos sino que dependen del elemento que componen. Además, suelen tener los mismos tiempo de vida. Los componentes no se comparten entre varios elementos, esta es otra de las diferencias con la agregación.Se representa con una linea continua con un rombo relleno en la clase que es compuesta.

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”.

DIAGRAMAS UML

DIAGRAMAS DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es describir el comportamiento dinámico del sistema de información haciendo énfasis en la secuencia de los mensajes intercambiados por los objetos.

n diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del diagrama hacia la inferior. Normalmente, en relación al tiempo sólo es importante la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podría introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su colocación debería poseer la mayor claridad posible.Cada objeto tiene asociados una línea de vida y focos de control. La línea de vida indica el intervalo de tiempo durante el que existe ese objeto. Un foco de control o activación muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operación, ya sea directamente o mediante un procedimiento concurrente. Un diagrama de secuencias muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo, en el cual se indicaran los módulos o clases que formaran parte del programa y las llamadas que se hacen cada uno de ellos para realizar una tarea determinada, por esta razón permite observar la perspectiva cronológica de las interacciones. Es importante recordar que el diagrama de secuencias se realiza a partir de la descripción de un caso de uso.

OBJETO Y LÍNEA DE VIDA

SIMBOLOGÍA MENSAJE

n objeto se representa como una línea vertical discontinua, llamada línea de vida, con un rectángulo de encabezado con el nombre del objeto en su interior. También se puede incluir a continuación el nombre de la clase, separando ambos por dos puntos.Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la línea comienza en el punto que representa ese instante y encima se coloca el objeto. Si el objeto es destruido durante la interacción que muestra el diagrama, la línea de vida termina en ese punto y se señala con un aspa de ancho equivalente al del foco de control.En el caso de que un objeto existiese al principio de la interacción representada en el diagrama, dicho objeto se situará en la parte superior del diagrama, por encima del primer mensaje. Si un objeto no es eliminado en el tiempo que dura la interacción, su línea de vida se prolonga hasta la parte inferior del diagrama.La línea de vida de un objeto puede desplegarse en dos o más líneas para mostrar los diferentes flujos de mensajes que puede intercambiar un objeto, dependiendo de alguna condición.

n mensaje se representa como una flecha horizontal entre las líneas de vida de los objetos que intercambian el mensaje. La flecha va desde el objeto que envía el mensaje al que lo recibe. Además, un objeto puede mandarse un mensaje a sí mismo, en este caso la flecha comienza y termina en su línea de vida.La flecha tiene asociada una etiqueta con el nombre del mensaje y los argumentos. También pueden ser etiquetados los mensajes con un número de secuencia, sin embargo, este número no es necesario porque la localización física de las flechas que representan a los mensajes ya indica el orden de los mismos. Los mensajes pueden presentar también condiciones e iteraciones. Una condición se representa mediante una expresión booleana encerrada entre corchetes junto a un mensaje, e indica que ese mensaje sólo es enviado en caso de ser cierta la condición. Una iteración se representa con un asterisco y una expresión entre corchetes, que indica el número de veces que se produce.(Nota.Esta notación es la más habitual, pero MÉTRICA Versión 3 no exige su utilización).

FOCO DE CONTROL O ACTIVACIÓN DIAGRAMA DE SECUENCIA PARA EL CASO DE USO: PRESTAR UN EJEMPLAR DE UNA APLICACIÓN ENCARGADA DE LOS PRÉSTAMOS Y RESERVAS DE UNA BIBLIOTECA:

e representa como un rectángulo delgado superpuesto a la línea de vida del objeto. Su largo dependerá de la duración de la acción. La parte superior del rectángulo indica el inicio de una acción ejecutada por el objeto y la parte inferior su finalización.

Los diagramas de clases representan información estática de sistema, pero ya en un sistema funcional, los objetos interactúan entre sí con el tiempo, esto se puede representar mediante un diagrama de secuencias.El objetivo de UML es ser capaz de describir el comportamiento de un sistema, subsistema u operación particular mediante un diagrama de secuencia el cual muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso, esto facilita como se distribuyen las tareas entre los componentes.

DIAGRAMAS UML E

l diagrama de estado se usa para dar forma al comportamiento de un objeto, de una clase. Se representa la secuencia de estados que un objeto de la clase tiene durante su vida, según las acciones que van sucediendo.

DIAGRAMA ESTADO

Además de la estructura estática y del comportamiento dinámico, las vistas funcionales se pueden utilizar para describir a los sistemas. Las vistas funcionales ilustran la funcionalidad que proporciona un sistema. Los casos de uso son las descripciones funcionales del sistema. Normalmente, son modelados en la etapa de análisis de requisitos para describir y capturar cómo los actores podrían utilizar un sistema. Los diagramas de casos de uso deberían capturar solamente cómo un actor puede usar un sistema, pero no cómo debe ser construido dicho sistema. Una máquina de estados es cualquier dispositivo que almacena el estado de un objeto en un momento dado y puede cambiar el estado o causar otras acciones según la entrada que reciba. Estados se refiere a las diferentes combinaciones de información que un objeto puede mantener, no la forma en que el objeto se comporta. Para comprender los diferentes estados de un objeto, podrías visualizar todos los estados posibles y mostrar cómo un objeto llega a cada estado, y puedes hacerlo con un diagrama de estados UML.Cada diagrama de estados generalmente empieza con un círculo oscuro que indica el estado inicial y termina con un círculo de contorno blanco que denota el estado final. Sin embargo, a pesar de tener puntos de inicio y finalización definidos, los diagramas de estado no necesariamente son la mejor herramienta para plasmar un desarrollo general de eventos. En lugar de ello, ilustran tipos específicos de comportamiento —en particular, cambios de un estado a otro.Los diagramas de estado representan principalmente estados y transiciones. Los estados se representan con rectángulos de esquinas redondeadas que se etiquetan con el nombre del estado. Las transiciones se marcan con flechas que fluyen de un estado a otro, mostrando cómo cambian los estados. A continuación podrás ver estos dos elementos en acción en un diagrama básico para la vida estudiantil. Nuestra herramienta de diagramas UML puede ayudarte a diseñar cualquier diagrama personalizado de máquina de estados De forma similar a la mayoría de los diagramas UML, los diagramas de estado tienen diferentes usos. Las aplicaciones principales son las siguientes:Representar objetos basados en eventos en un sistema reactivo.Ilustrar escenarios de casos de uso en un contexto de negocios.Describir cómo se mueve un objeto a través de diversos estados a lo largo de su existencia.Mostrar el comportamiento general de una máquina de estados o el comportamiento de un conjunto relacionado de máquinas de estados.Crear diagramas es rápido y sencillo con Lucidchart. Puedes incluir muchas figuras diferentes en un diagrama de estados, particularmente si eliges combinarlo con otro diagrama. Esta lista resume las figuras más comunes que puedes encontrar.Estado compuesto:Un estado que contiene subestados anidados. Ve el ejemplo siguiente de diagrama de estados de universidad. “Inscripción” es el estado compuesto en este ejemplo porque comprende diversos subestados en el proceso.Pseudoestado de opciónUn símbolo de diamante que indica una condición dinámica con resultados potenciales ramificados.

Evento:Una instancia que activa una transición, etiquetada arriba de la flecha de transición aplicable. En este caso, "fin de clases" es el evento que activa el final del estado “Siendo instruidos” y el inicio del estado “Exámenes finales”.Punto de salida:El punto en el cual un objeto escapa el estado compuesto o máquina de estados, el cual se indica por medio de un círculo cruzado con una X. El punto de salida generalmente se usa si el proceso no está completado, pero tiene que ser escapado por algún error u otro problema. Primer estado: Un marcador para el primer estado en el proceso, que se muestra mediante un círculo oscuro con una flecha de transición. Protección:Una condición booleana que permite o detiene una transición. Se escribe arriba de la flecha de transición. Estado:Un rectángulo de esquinas redondeadas que indica la naturaleza actual de un objeto. Subestado: Un estado contenido dentro de la región de un estado compuesto. En el diagrama de máquina de estados de universidad mostrado a continuación, “Abierto para inscripción” es un subestado en el estado compuesto más grande de “Inscripción”. Terminador: Un círculo con un punto en el interior que indica que un proceso está terminado.TransiciónUna flecha que corre de un estado a otro, que indica un estado cambiante. Comportamiento transicionalUn comportamiento que resulta cuando un estado pasa por una transición. Se escribe arriba de la flecha de transición.DisparadorUn tipo de mensaje que mueve activamente un objeto de estado en estado. Se escribe arriba de la flecha de transición. En este ejemplo, “Problema con la reservación” es el disparador que enviaría a la persona a la agencia de viajes del aeropuerto en lugar de al siguiente paso en el proceso.

EJEMPLO DE DIAGRAMA DE ESTADO EN UNIVERSIDAD Este diagrama de estados muestra el proceso de inscripción y clases en una universidad. El estado compuesto “Inscripción” se compone de diversos subestados que guían a los estudiantes a través del proceso de inscripción. Una vez que los estudiantes se han inscrito, pasan al estado “Siendo instruidos” y finalmente a “Exámenes finales”:

DIAGRAMAS DE ACTIVIDADES U

n diagrama de actividades muestra el flujo de actividades, siendo un actividad una ejecución general entre los objetos que se está ejecutando en un momento dado dentro de una máquina de estados, el resultado de un actividad es una acción que producen un cambio en el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras operaciones, envío de señales, creación o destrucción de objetos o simples cálculos. Gráficamente un diagrama de actividades será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido. El diagrama de actividades de UML está compuesto por los siguientes elementos: Actividades, flujos de control, nodo inicial y nodo final. Actividad: La actividad es una conducta parametrizada representada como flujo coordinado de acciones .El flujo de ejecución que representa la funcionalidad deseada se modela utilizando nodos de actividad conectados por flujos de control. Un nodo puede ser la ejecución de un comportamiento subordinado, como un cálculo aritmético, una llamada a una operación o la manipulación del contenido del objeto. Los nodos de actividad también incluyen flujo de construcciones de control, como sincronización, decisión y control de concurrencia. Las actividades pueden formar jerarquías de invocación invocando otras actividades y en última instancia resolviendo acciones individuales. En un modelo orientado a objetos, las actividades generalmente se invocan indirectamente como métodos vinculados a operaciones que se invocan directamente.Las actividades son representadas mediante un rectángulo con los bordes redondeados, que incluye en su interior el nombre de la actividad .También se puede representar una actividad que incluye un subdiagrama de actividades, disminuyendo de esta la granularidad de la representación.Las actividades que no tienen más descomposición se denominan acciones. Estas acciones a veces son representadas mediante pseudocódigo, aunque no es algo muy común.Las actividades son nombradas utilizando los verbos del modelo de negocio, algunos ejemplos de estas actividades podrían ser: Buscar Objeto, Actualizar lista, Hacer pago… Flujo entre actividades.: El flujo entre actividades es una clase abstracta para las conexiones dirigidas a lo largo de las cuales los tokens u objetos de datos fluyen entre los nodos de actividad . Incluye flujos de control y flujo de objetos . La fuente y el objetivo de un borde deben estar en la misma actividad que el borde.Los flujos entre actividades se representan mediante una flecha con la punta abierta que simboliza el orden de ejecución de las actividades, a veces se incorpora un nombre en esta flecha que ayuda a que se entienda mejor.Estos flujos de actividades pueden usar condiciones para su actuación, estas condiciones se representan mediante un rombo, con la condición escrita entre corchetes.Este elemento también recibe el nombre de nodo de decisión.El caso contrario es el llamada nodo de fusión, que recibe 2 o más flujo y emite 1.

DIAGRAMAS UML E

l diagrama de actividades un diagrama UML de comportamiento que muestra el flujo de control o el flujo de objetos, con especial énfasis en la secuencia y las condiciones de este flujo.Estos diagramas son utilizados para describir cualquier tipo de procesos, es especialmente común para modelar de forma gráfica los diferentes casos de uso, transacciones o procedimientos que haya en un sistema de información. En resumen, son utilizados para representar la forma en la que un sistema hace una implementación. Los diagramas de actividades muestran una secuencia de acciones, un flujo de trabajo que va desde un punto inicial hasta un punto final.

Estas dos variables pueden ser combinadas, haciendo que un nodo reciba varios flujos y, a su vez, emita también varios flujos. Nodo inicial y nodo final: El nodo inicial es un nodo de control en el que se inicia el flujo cuando se invoca la actividad. Solo existirá uno por diagrama.Las actividades pueden tener más de un nodo inicial. En este caso, al invocar la actividad se inician varios flujos, uno en cada nodo inicial. Hay que tener en cuenta que los flujos también pueden comenzar en otros nodos, por lo que los nodos iniciales no son necesarios para que una actividad comience la ejecución.Los nodos iniciales se muestran como un pequeño círculo relleno. El nodo final de actividad es un nodo final de control que detiene todos los flujos en una actividad . La actividad final se introdujo en UML 2.0, hasta entonces no existía.Una actividad puede tener más de un nodo final de actividad. El primero alcanzado detiene todos los flujos en la actividad. Un token que llega a un nodo final de actividad finaliza la actividad. En particular, detiene todas las acciones de ejecución en la actividad y destruye todos los tokens en los nodos de objetos, excepto en los nodos del parámetro de actividad de salida. Los nodos finales de actividad se muestran como un círculo sólido con un círculo hueco dentro.

EJEMPLO

DIAGRAMAS UML

DIAGRAMAS DE CASOS DE USOS U

n caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.Los casos de uso se utilizan básicamente en el Proceso de modelado de sistemas, partiendo de una percepción o perspectiva que nos plantea el paradigma de la orientación a objetos, y en este caso el análisis y diseño orientados a objetos.Forman parte del Lenguaje Unificado de Modelado UML por sus siglas en ingles (Unified Modeling Languaje) el cual a su vez se compone de muchas otras herramientas, básicamente diagramas como:

EJEMPLO DE DIAGRAMA DE CASOS DE USO EN UN SISTEMA

Diagramas de Clase, Diagramas de Secuencia, Colaboración, Transición de Estados, Diagramas de Actividad, Componentes, Deployment, entre otros. Todas ellas usadas a lo largo de las etapas o ciclo de vida del proceso de desarrollo.La aplicación principal de los casos de uso es en el proceso de análisis y diseño pero de manera particular en la definición de requerimientos del usuario. Es una excelente herramienta de comunicación debido a la sencillez de su elaboración así como su comprensión. Los casos de uso son un tipo de requerimientos utilizados para especificar funcionalidad, especialmente en sistemas con un alto grado de interacción hombre/máquina (y pueden ser utilizados hasta en sistemas de batch). En esencia los casos de uso describen los intercambios entre el sistema que se está describiendo y las personas o sistemas externos que interactúan con el primero, por lo tanto son muy útiles para describir funcionalidades a varios tipos de usuarios y con muchas interfaces.Los casos de uso son útiles para capturar requerimientos, ayudar a definir la arquitectura, establecer las pautas para el diseño y las pruebas funcionales. Los CU son una guía de los elementos que serán incluidos en los documentos de usuarios para las aplicaciones, así como la forma en como éstos deben ser empleados. Los CU también establecen las bases para los protocolos de comunicación entre aplicaciones y el diseño de las interfaces gráficas, entre otros.La validez de los casos de uso viene dada cuando los usuarios e involucrados del sistema aceptan el funcionamiento propuesto en los CU, siempre que la redacción de los mismo sea buena, no dejando cabida a ambigüedades.Entonces los casos de uso deben ser útiles y ofrecer valor tanto al equipo de usuarios e involucrados como a los desarrolladores del proyecto.

GLOSARIO DE TÉRMINOS FAMILIARÍZATE CON EL VOCABULARIO DE UML, CON ESTA LISTA EXTRAÍDA DEL DOCUMENTO UML 2.4.1, CUYA FINALIDAD ES AYUDAR A QUIENES NO SON MIEMBROS DE OMG A ENTENDER LOS TÉRMINOS COMÚNMENTE USADOS: COMPATIBILIDAD CON SINTAXIS ABSTRACTA LOS USUARIOS PUEDEN MOVER MODELOS A TRAVÉS DE DIFERENTES HERRAMIENTAS, INCLUSO SI USAN DIFERENTES NOTACIONES. METAMODELO DE ALMACÉN COMÚN (CWM) INTERFACES ESTÁNDARES QUE SE USAN PARA PERMITIR EL INTERCAMBIO DE METADATOS DE ALMACÉN E INTELIGENCIA DE NEGOCIOS ENTRE HERRAMIENTAS DE ALMACÉN, PLATAFORMAS DE ALMACÉN Y REPOSITORIOS DE METADATOS DE ALMACÉN EN ENTORNOS HETEROGÉNEOS DISTRIBUIDOS. COMPATIBILIDAD CON SINTAXIS CONCRETA LOS USUARIOS PUEDEN CONTINUAR USANDO UNA NOTACIÓN CON LA QUE ESTÉN FAMILIARIZADOS A TRAVÉS DE DIFERENTES HERRAMIENTAS. NÚCLEO EN EL CONTEXTO DE UML, EL NÚCLEO COMÚNMENTE SE REFIERE AL &QUOT;PAQUETE CENTRAL&QUOT;, QUE ES UN METAMODELO COMPLETO PARTICULARMENTE DISEÑADO PARA UNA ALTA REUTILIZACIÓN. UNIDAD DE LENGUAJE CONSISTE EN UNA COLECCIÓN DE CONCEPTOS DE MODELADO ESTRECHAMENTE VINCULADOS QUE PROPORCIONA A LOS USUARIOS LA CAPACIDAD DE REPRESENTAR ASPECTOS DEL SISTEMA EN ESTUDIO SEGÚN UN PARADIGMA O FORMALISMO EN PARTICULAR. NIVEL 0 (L0) NIVEL DE CUMPLIMIENTO INFERIOR PARA LA INFRAESTRUCTURA UML - UNA SOLA UNIDAD DE LENGUAJE QUE HACE POSIBLE EL MODELADO DE TIPOS DE ESTRUCTURAS BASADAS EN CLASES QUE SE ENCUENTRAN EN LOS LENGUAJES MÁS POPULARES DE PROGRAMACIÓN ORIENTADOS A OBJETOS.

META OBJECT FACILITY (MOF) UNA ESPECIFICACIÓN DE MODELADO DE OMG QUE BRINDA LA BASE PARA LAS DEFINICIONES DE METAMODELOS EN LA FAMILIA DE LENGUAJES MDA DE OMG. METAMODELO DEFINE EL LENGUAJE Y LOS PROCESOS A PARTIR DE LOS CUALES FORMAR UN MODELO. CONSTRUCCIONES DE METAMODELOS (LM) SEGUNDO NIVEL DE CUMPLIMIENTO EN LA INFRAESTRUCTURA UML - UNA UNIDAD ADICIONAL DE LENGUAJE PARA ESTRUCTURAS MÁS AVANZADAS BASADAS EN CLASES, USADAS PARA CONSTRUIR METAMODELOS (POR MEDIO DE CMOF), TALES COMO EL UML MISMO. UML SOLO TIENE DOS NIVELES DE CUMPLIMIENTO. ARQUITECTURA DIRIGIDA POR MODELOS (MDA) UN ENFOQUE Y UN PLAN PARA LOGRAR UN CONJUNTO COHERENTE DE ESPECIFICACIONES DE TECNOLOGÍA DIRIGIDA POR MODELOS. LENGUAJE DE RESTRICCIONES PARA OBJETOS (OCL) UN LENGUAJE DECLARATIVO PARA DESCRIBIR REGLAS QUE SE APLICAN AL LENGUAJE UNIFICADO DE MODELADO. OCL COMPLEMENTA A UML PROPORCIONANDO TÉRMINOS Y SÍMBOLOS DE DIAGRAMAS DE FLUJO QUE SON MÁS PRECISOS QUE EL LENGUAJE NATURAL, PERO MENOS DIFÍCILES DE DOMINAR QUE LAS MATEMÁTICAS. OBJECT MANAGEMENT GROUP (OMG) ES UN CONSORCIO SIN FINES DE LUCRO DE ESPECIFICACIONES PARA LA INDUSTRIA DE LA COMPUTACIÓN, CUYOS MIEMBROS DEFINEN Y MANTIENEN LA ESPECIFICACIÓN UML. UML 1 PRIMERA VERSIÓN DEL LENGUAJE UNIFICADO DE MODELADO. LENGUAJE UNIFICADO DE MODELADO (UML) UN LENGUAJE VISUAL PARA ESPECIFICAR, CONSTRUIR Y DOCUMENTAR LOS ARTEFACTOS DE LOS SISTEMAS. XMI UNA ESPECIFICACIÓN BASADA EN XML DE FORMATOS DE INTERCAMBIO DE MODELOS CORRESPONDIENTES.

DISEÑO: MARÍA PÁEZ REDACCIÓN INVESTIGADA: JOSÉ ORTÍZ, ANAHILID PEÑALOZA DOCENTE: LUIS E. APONTE COLEGIO NTRA SRA DE LA CONSOLACIÓN MAYO; 2020.