\u00a0\u00bfPor qu\u00e9 UML?<\/h2>\n
A medida que las arquitecturas de software crecen en tama\u00f1o y complejidad, tambi\u00e9n aumenta la necesidad de modelos de software. UML es el lenguaje de modelado dominante en la industria del software. Actualmente es un est\u00e1ndar de facto adoptado por el Grupo de Gesti\u00f3n de Objetos, el consorcio de software m\u00e1s grande del mundo. Es dif\u00edcil encontrar un proyecto de software con m\u00e1s de 10 desarrolladores que no utilice UML de alguna manera para especificar su arquitectura.<\/p>\n
Aqu\u00ed hay algunos hechos adicionales sobre el uso de UML en nuestro proceso de desarrollo de software:<\/p>\n
- \n
- El software est\u00e1 volvi\u00e9ndose cada vez m\u00e1s complejo: una versi\u00f3n bastante antigua de Windows XP tiene m\u00e1s de 40 millones de l\u00edneas de c\u00f3digo.<\/li>\n
- Un solo programador no puede gestionar esta cantidad de c\u00f3digo en su totalidad.<\/li>\n
- El c\u00f3digo no es f\u00e1cilmente comprensible para los desarrolladores que no lo escribieron.<\/li>\n
- Necesitamos representaciones m\u00e1s simples para sistemas complejos: el modelado es una forma de manejar la complejidad.<\/li>\n<\/ul>\n
\u00bfQu\u00e9 es un modelo?<\/h2>\n
- \n
- Un modelo es una abstracci\u00f3n de la cosa real, dejando de lado los detalles.<\/li>\n
- \u201cLa colecci\u00f3n de todos los elementos que describen su sistema, incluyendo sus conexiones entre s\u00ed, constituyen su modelo.\u201d (Russ y Hamilton 12).<\/li>\n<\/ul>\n
Cuando usamos UML para crear modelos de un sistema bajo desarrollo antes de codificar el software, estos representan el problema de forma simplificada. Proporcionan una estructura para resolver problemas. Ayudan a comprender c\u00f3mo se puede proceder con el problema actual. Tambi\u00e9n permiten experimentar con m\u00faltiples soluciones. Dado que los modelos se crean antes del desarrollo real del sistema, podemos comprender diferentes posibilidades, problemas, opciones, etc. Esto tambi\u00e9n conduce a una reducci\u00f3n de los costos de desarrollo. Dado que el tiempo no se desperdiciar\u00e1 en pruebas y errores, el producto estar\u00e1 listo en menos tiempo. Los modelos tambi\u00e9n ayudan a gestionar la complejidad del problema, por lo que la planificaci\u00f3n del desarrollo, la asignaci\u00f3n de recursos como m\u00e1quinas, programadores, testers, puede hacerse f\u00e1cilmente.<\/p>\n
\u00bfQu\u00e9 NO es UML?<\/h2>\n
- \n
- UML no es una notaci\u00f3n, sino un lenguaje.<\/li>\n
- UML no es propiedad de nadie. Est\u00e1 abierto para ser usado por cualquiera que desee usarlo. No es propietario.<\/li>\n
- UML no es un proceso ni un m\u00e9todo.<\/li>\n
- UML fomenta el uso de t\u00e9cnicas orientadas a objetos y ciclos de vida de desarrollo de software iterativos.<\/li>\n
- UML no es dif\u00edcil. Es amplio, pero no es necesario conocerlo por completo. Adem\u00e1s, no es necesario usar ni comprender cada peque\u00f1o aspecto de \u00e9l.<\/li>\n
- UML no es costoso en tiempo. Si se utiliza adecuadamente, el uso de UML reduce los costos de desarrollo. Al mismo tiempo, ofrece la ventaja de una comprensi\u00f3n y comunicaci\u00f3n m\u00e1s f\u00e1ciles, mayor productividad y mejor calidad.<\/li>\n
- UML no est\u00e1 limitado. Es lo suficientemente flexible como para permitir un vocabulario m\u00e1s nuevo (conceptos, palabras y t\u00e9rminos), propiedades (informaci\u00f3n adicional sobre las palabras) y sem\u00e1ntica (reglas del lenguaje) que son necesarios para un dominio espec\u00edfico.<\/li>\n<\/ul>\n
Objetivo de UML<\/h2>\n
- \n
- Un lenguaje de modelado visual y no un lenguaje de programaci\u00f3n visual. Aunque algunas herramientas de modelado tienen generadores de c\u00f3digo y algunas pueden realizar la ingenier\u00eda inversa de modelos a partir de c\u00f3digo.<\/li>\n
- Se pretende crear diagramas que puedan apoyar el proceso de desarrollo de software, sin embargo, UML NO es un proceso ni un m\u00e9todo de desarrollo de software. Por tanto, UML es independiente del proceso.<\/li>\n
- Un lenguaje est\u00e1ndar para crear planos de software.<\/li>\n
- Herramienta de comunicaci\u00f3n.<\/li>\n
- Un lenguaje para documentar requisitos, arquitectura, pruebas, planificaci\u00f3n de proyectos, etc.<\/li>\n
- Est\u00e1 destinado a sistemas de software, pero puede modelar otros sistemas.<\/li>\n
- Est\u00e1 destinado a apoyar el proceso de desarrollo orientado a objetos.<\/li>\n
- Puede capturar tanto las estructuras est\u00e1ticas como el comportamiento din\u00e1mico de un sistema.<\/li>\n
- Los diagramas UML pueden ayudar a los interesados a comprender, discutir y acordar los requisitos.<\/li>\n
- Los diagramas UML pueden ayudar a abstraer procesos complejos hasta un nivel m\u00e1s f\u00e1cil de comprender.<\/li>\n
- Los diagramas UML ayudan a facilitar la resoluci\u00f3n de problemas.<\/li>\n<\/ul>\n
\u00bfQu\u00e9 proporciona un lenguaje de modelado?<\/h2>\n
- \n
- Elementos de modelo<\/i><\/b>: Conceptos y sem\u00e1ntica<\/li>\n
- Notaci\u00f3n<\/i><\/b>: Representaci\u00f3n visual de los elementos de modelo<\/li>\n
- Gu\u00edas<\/i><\/b>: Consejos y sugerencias para usar los elementos en la notaci\u00f3n<\/li>\n<\/ul>\n
Breve historia<\/h2>\n
En la d\u00e9cada de 1980, cuando comenzamos a modelar, hab\u00eda muchas metodolog\u00edas diferentes. Y cada metodolog\u00eda ten\u00eda sus propias notaciones. El problema era que si diferentes personas usaban notaciones distintas, en alg\u00fan momento alguien ten\u00eda que hacer una traducci\u00f3n. Muchas veces, un s\u00edmbolo significaba una cosa en una notaci\u00f3n y algo completamente diferente en otra notaci\u00f3n. En 1991, todos empezaron a publicar libros. Grady Booch lanz\u00f3 su primera edici\u00f3n. Ivar Jacobson public\u00f3 la suya, y Jim Rumbaugh lanz\u00f3 su metodolog\u00eda OMT. Cada libro ten\u00eda sus fortalezas y sus debilidades. OMT era muy fuerte en an\u00e1lisis, pero m\u00e1s d\u00e9bil en dise\u00f1o. La metodolog\u00eda Booch era m\u00e1s fuerte en dise\u00f1o y m\u00e1s d\u00e9bil en an\u00e1lisis. Y Objectory de Ivar Jacobson era muy buena en experiencia de usuario, algo que ni Booch ni OMT consideraban realmente en aquel entonces. Booch y Jacobson fusionaron sus dos m\u00e9todos en 1994, y luego Rumbaugh se uni\u00f3 en 1995. UML 1.1 se public\u00f3 en 1997 por parte de OMG, incluyendo aportes de otros, por ejemplo, Yourden. La versi\u00f3n UML v2.x es la m\u00e1s actual.<\/p>\n
Fechas de lanzamiento<\/h3>\n
- \n
- 1995 \u2013 UML 0.8<\/li>\n
- 1996 \u2013 UML 0.9 \u2013 Los Tres Amigos<\/li>\n
- 1997 \u2013 OMG asume el control.<\/li>\n
- 1997 \u2013 OMG UML 1.1<\/li>\n
- 1998 \u2013 OMG UML 1.2<\/li>\n
- 1999 \u2013 OMG UML 1.3<\/li>\n
- 2001 \u2013 OMG UML 1.4<\/li>\n
- 2003 \u2013 OMG UML 1.5<\/li>\n
- 2003 \u2013 OMG UML 2.0 \u2013 Adoptado<\/li>\n
- 2005 \u2013 OMG UML 2.0 \u2013 Final<\/li>\n
- 2006 \u2013 OMG UML 2.1<\/li>\n
- UML2.1.2<\/b>(11\/04\/07) \u2013 Versi\u00f3n actual a partir del 27\/05\/08<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/What-is-UML.png\")
<\/a><\/p>\nLa motivaci\u00f3n de la unificaci\u00f3n de m\u00e9todos por parte de los \u201ctres Amegos\u201d<\/h2>\n
- \n
- Hecho de que los m\u00e9todos individuales evolucionen hacia otros de forma independiente<\/li>\n
- Unificaci\u00f3n de sem\u00e1ntica y notaci\u00f3n para aportar estabilidad al mercado de dise\u00f1o orientado a objetos<\/li>\n
- Anticipaci\u00f3n de que la unificaci\u00f3n mejorar\u00eda los m\u00e9todos individuales anteriores<\/li>\n<\/ul>\n
Socios de UML<\/h3>\n
\n
- \n
- Corporaci\u00f3n Rational Software<\/li>\n
- IBM<\/li>\n
- Hewlett-Packard<\/li>\n
- I-Logix<\/li>\n
- ICON Computing<\/li>\n
- Intellicorp<\/li>\n
- MCI Systemhouse<\/li>\n
- Microsoft<\/li>\n
- ObjecTime<\/li>\n
- Oracle<\/li>\n
- Tecnolog\u00eda Platinum<\/li>\n
- Taskon<\/li>\n
- Texas Instruments\/Sterling Software<\/li>\n
- Unisys<\/li>\n<\/ul>\n<\/blockquote>\n
Entrada de notaci\u00f3n UML para diferentes m\u00e9todos antes de la unificaci\u00f3n<\/h2>\n
UML representa la unificaci\u00f3n de las notaciones Booch, OMT y Objectory, as\u00ed como las mejores ideas de varios otros metod\u00f3logos, como se muestra en la figura siguiente. Al unificar las notaciones utilizadas por estos m\u00e9todos orientados a objetos, el Lenguaje Unificado de Modelado proporciona la base para una norma de facto en el dominio del an\u00e1lisis y dise\u00f1o orientado a objetos, fundada en una amplia base de experiencia de usuarios.<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/UML-Imnput.png\")
<\/a><\/p>\n<\/h3>\n
El papel de la notaci\u00f3n<\/h2>\n
La notaci\u00f3n desempe\u00f1a un papel importante en cualquier modelo: es el pegamento que une el proceso. La notaci\u00f3n tiene tres funciones:<\/p>\n
- \n
- Sirve como el lenguaje para comunicar decisiones que no son evidentes o que no pueden inferirse directamente del c\u00f3digo.<\/li>\n
- Proporciona sem\u00e1ntica suficientemente rica para capturar todas las decisiones estrat\u00e9gicas y t\u00e1cticas importantes.<\/li>\n
- Ofrece una forma lo suficientemente concreta para que los humanos puedan razonar y para que las herramientas la manipulen.<\/li>\n<\/ul>\n
El Lenguaje Unificado de Modelado (UML) proporciona una notaci\u00f3n muy robusta, que evoluciona desde el an\u00e1lisis hasta el dise\u00f1o. Algunos elementos de la notaci\u00f3n (por ejemplo, clases, asociaciones, agregaciones, herencia) se introducen durante el an\u00e1lisis. Otros elementos de la notaci\u00f3n (por ejemplo, indicadores de implementaci\u00f3n de contenci\u00f3n y propiedades) se introducen durante el dise\u00f1o.<\/p>\n
Beneficios de UML<\/b><\/h2>\n
UML puede aplicarse a diversosdominios de aplicaci\u00f3n<\/strong>\u00a0(por ejemplo, banca, finanzas, internet, aeroespacial, salud, etc.) Puede utilizarse con todos los principales objetos y componentes\u00a0m\u00e9todos de desarrollo de software<\/strong>\u00a0y para diversos\u00a0plataformas de implementaci\u00f3n.<\/strong><\/p>\n
- \n
- Sabe exactamente lo que est\u00e1 obteniendo<\/li>\n
- Tendr\u00e1 costos de desarrollo m\u00e1s bajos<\/li>\n
- \u00a0Su software se comportar\u00e1 como usted espera. Menos sorpresas<\/li>\n
- \u00a0Se toman las decisiones correctas antes de que se le entregue c\u00f3digo mal escrito. Menores costos totales<\/li>\n
- Podemos desarrollar sistemas m\u00e1s eficientes en memoria y procesador<\/li>\n
- Los costos de mantenimiento del sistema ser\u00e1n menores. Se producir\u00e1 menos reaprendizaje<\/li>\n
- Trabajar con un nuevo desarrollador ser\u00e1 m\u00e1s f\u00e1cil.<\/li>\n
- La comunicaci\u00f3n con programadores y contratistas externos ser\u00e1 m\u00e1s eficiente.<\/li>\n<\/ul>\n
Vistas UML 4 + 1<\/h2>\n
UML consta de las siguientes cuatro vistas del sistema en desarrollo (v\u00e9ase Fig. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:<\/p>\n
- \n
- Vista de casos de uso:<\/em> muestra la funcionalidad del sistema tal como la perciben los actores externos; se describe mediante diagramas de casos de uso y ocasionalmente mediante diagramas de actividad.<\/li>\n
- Vista l\u00f3gica: <\/em>muestra c\u00f3mo se dise\u00f1a esta funcionalidad dentro del sistema, en t\u00e9rminos de su estructura est\u00e1tica y comportamiento din\u00e1mico; se describe mediante diagramas de clases y objetos (modelo est\u00e1tico) y diagramas de transici\u00f3n de estado, secuencia, colaboraci\u00f3n y actividad (modelo din\u00e1mico)<\/li>\n
- Vista de componentes:<\/em> muestra la organizaci\u00f3n de los componentes de software; se describe mediante diagramas de componentes.<\/li>\n
- Vista de despliegue:<\/em> muestra la configuraci\u00f3n f\u00edsica (despliegue) de los nodos de procesamiento en tiempo de ejecuci\u00f3n dentro de computadoras y dispositivos, y los componentes, procesos y objetos que residen en ellos; se describe mediante diagramas de despliegue.<\/li>\n
- Vista de proceso:<\/em> muestra el aspecto concurrente del sistema en tiempo de ejecuci\u00f3n, como tareas, hilos, procesos e interacciones, y aborda problemas de comunicaci\u00f3n y sincronizaci\u00f3n de estos hilos; se describe mediante diagramas din\u00e1micos (diagramas de transici\u00f3n de estado, secuencia, colaboraci\u00f3n y actividad) y diagramas de implementaci\u00f3n (diagramas de componentes y de despliegue).<\/li>\n<\/ul>\n
![\"4+1](\"https:\/\/www.ibm.com\/developerworks\/rational\/library\/05\/0816_Louis\/figure-2.gif\"\/)
<\/p>\nCada sistema consta de la est\u00e1tico<\/em> y el din\u00e1mico<\/em>modelo. El modelo est\u00e1tico se representa en los diagramas de clases y objetos. Sin embargo, revela poco sobre el comportamiento del sistema. El comportamiento del sistema se captura gr\u00e1ficamente mediante escenarios (es decir, diagramas de casos de uso), diagramas de secuencia, diagramas de transici\u00f3n de estado y diagramas de actividad. Estos constituyen el modelo din\u00e1mico del sistema. El comportamiento del sistema es el comportamiento total de todos los objetos pertenecientes al sistema.<\/p>\n
Si queremos mapear las cinco vistas anteriores a las fases del ciclo de vida iterativo de la figura 3, podr\u00edamos decir lo siguiente:<\/p>\n
- \n
- An\u00e1lisis Orientado a Objetos (OOA), que desarrolla un modelo de los requisitos de los usuarios desde la perspectiva del usuario, se mapea a la vista de caso de uso.<\/li>\n
- Dise\u00f1o Orientado a Objetos (OOD) a\u00f1ade detalles y decisiones de dise\u00f1o (desde la perspectiva del desarrollador) al an\u00e1lisis y se mapea a la vista l\u00f3gica.<\/li>\n
- Finalmente, la implementaci\u00f3n o programaci\u00f3n orientada a objetos (OOP) se mapea a la vista de proceso, despliegue y componente.<\/li>\n<\/ul>\n
Diagramas UML 2<\/b><\/h2>\n
UML tiene varios tipos diferentes de diagramas que pueden utilizarse para describir un modelo desde diferentes puntos de vista. Hay dos categor\u00edas amplias de diagramas y luego se dividen nuevamente en subcategor\u00edas:<\/p>\n
- \n
- Diagramas estructurales \u2013 Eldiagramas estructurales<\/i>representan el aspecto est\u00e1tico del sistema. Estos aspectos est\u00e1ticos representan aquellas partes de un diagrama que forman la estructura principal y por tanto estable. Estas partes est\u00e1ticas se representan mediante clases, interfaces, objetos, componentes y nodos.<\/li>\n
- Diagramas comportamentales \u2013 Cualquier sistema puede tener dos aspectos, est\u00e1tico y din\u00e1mico. Por lo tanto, un modelo se considera completo cuando ambos aspectos se cubren completamente.\n
Los diagramas comportamentales capturan b\u00e1sicamente el aspecto din\u00e1mico de un sistema. El aspecto din\u00e1mico puede describirse m\u00e1s a fondo como las partes cambiantes\/m\u00f3viles de un sistema.<\/div>\n<\/li>\n<\/ul>\n![\"UML](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2022\/02\/02-uml-diagram-types.png\"\/)
<\/p>\nDiagramas estructurales<\/h2>\n
Eldiagramas estructurales<\/i>representan el aspecto est\u00e1tico del sistema. Estos aspectos est\u00e1ticos representan aquellas partes de un diagrama que forman la estructura principal y por tanto estable.<\/div>\nEstas partes est\u00e1ticas se representan mediante clases, interfaces, objetos, componentes y nodos. Los cuatro diagramas estructurales son:<\/div>\n- \n
- Diagrama de clases<\/b> \u2013 diagrama de la estructura est\u00e1tica de las clases y interfaces del sistema y sus relaciones o asociaciones (incluyendo herencia, agregaci\u00f3n y asociaci\u00f3n), incluyendo las operaciones y atributos de las clases. Los modos de presentaci\u00f3n son: Asociaci\u00f3n, Herencia, Dependencia. Este es un diagrama muy com\u00fan en UML.<\/li>\n
- Diagrama de objetos<\/b> \u2013 es un diagrama de la estructura est\u00e1tica de un sistema en un momento o situaci\u00f3n espec\u00edfica (instant\u00e1nea) que ilustra una relaci\u00f3n en un sistema.<\/li>\n
- Diagrama de componentes<\/b> \u2013 es un diagrama que describe la organizaci\u00f3n y las dependencias de los componentes dentro del sistema.<\/li>\n
- Diagrama de estructura compuesta<\/b> \u2013 es un diagrama que explora instancias en tiempo de ejecuci\u00f3n de instancias interconectadas que colaboran a trav\u00e9s de enlaces de comunicaci\u00f3n.<\/li>\n
- Diagrama de paquetes<\/b> \u2013 es un diagrama que muestra c\u00f3mo un sistema se divide en agrupaciones l\u00f3gicas y qu\u00e9 dependencias pueden existir entre estas agrupaciones.<\/li>\n
- Diagrama de despliegue<\/b> \u2013 es un diagrama que describe c\u00f3mo las unidades f\u00edsicas distribuibles (componentes de software desplegables, aplicaciones, servidores, aplicaciones, hardware, etc.) constituyen la arquitectura del sistema distribuido.<\/li>\n<\/ul>\n
Diagramas comportamentales<\/b><\/h2>\n
- \n
- Diagrama de casos de uso<\/b> \u2013 diagrama de los casos de uso (funciones\/servicios de software) y el papel de los actores (usuarios \u2013 tanto humanos como sistemas). Este diagrama est\u00e1 desde la perspectiva del usuario.<\/li>\n
- Diagrama de actividad<\/b> \u2013 es un diagrama de la naturaleza din\u00e1mica de un sistema mediante la modelaci\u00f3n del flujo de control de actividad a actividad. Representa c\u00f3mo un sistema (por ejemplo: objeto\/clase) responde a un evento interno. (nota: los eventos externos se describen mediante un Diagrama de estado). Para la modelaci\u00f3n de procesos de negocio, puedes utilizar este diagrama para modelar la l\u00f3gica de un caso de uso o regla de negocio.<\/li>\n
- Diagrama de estado<\/b> (tambi\u00e9n conocido como Diagrama de estado, Diagrama de m\u00e1quina de estados) \u2013 es un diagrama de c\u00f3mo un sistema (por ejemplo: objeto\/clase) responde a un evento externo. (nota: los eventos internos se describen mediante un Diagrama de actividad).<\/li>\n<\/ul>\n
Diagramas de tipo de interacci\u00f3n<\/b>\u2013 interacciones de las partes organizativas del modelo.<\/p>\n
- \n
- Diagrama de secuencia<\/b> \u2013 es un diagrama de la interacci\u00f3n y el flujo de mensajes entre objetos y el orden relativo de tiempo de los mensajes<\/li>\n
- Diagrama de comunicaci\u00f3n<\/b>(tambi\u00e9n conocido como <\/b>Diagramas de colaboraci\u00f3n de UML1) \u2013 es un diagrama de c\u00f3mo los sistemas colaboran entre s\u00ed para realizar una tarea y las asociaciones que deben existir entre los sistemas. El diagrama de colaboraci\u00f3n es el resultado de tomar el diagrama de secuencia y describir su interacci\u00f3n con el diagrama de clases. En resumen, este diagrama muestra el flujo de mensajes entre objetos y las asociaciones b\u00e1sicas (relaciones) entre clases<\/li>\n
- Diagrama de tiempo<\/b> \u2013 es un diagrama que explora el comportamiento de uno o m\u00e1s objetos durante un per\u00edodo de tiempo determinado.<\/li>\n
- Diagrama de vista general de interacci\u00f3n<\/b> \u2013 es un diagrama de la interacci\u00f3n y el control de flujo entre los diagramas de interacci\u00f3n (diagrama de secuencia, diagrama de comunicaci\u00f3n, diagrama de tiempo, diagrama de vista general de interacci\u00f3n).<\/li>\n<\/ul>\n
Perfil UML<\/h3>\n
El perfil UML no es exactamente un diagrama, sino un perfil para describir extensiones y subconjuntos de UML. Los subconjuntos se describen utilizando el Lenguaje de Restricci\u00f3n de Objetos (OCL). Las extensiones se crean definiendo estereotipos, que son etiquetas que pueden decorar cualquier elemento del modelo. Por ejemplo, podr\u00edamos etiquetar una clase como \u00abpersistente\u00bb y usar la etiqueta para identificar una clase cuyas instancias se almacenan m\u00e1s all\u00e1 de la vida \u00fatil de la ejecuci\u00f3n del sistema. Informalmente \u2014y esto es ideol\u00f3gicamente incorrecto\u2014 un perfil es cualquier conjunto de extensiones y subconjuntos de UML, ya sea que se escriban usando estos mecanismos o no. Formalmente, un perfil es la definici\u00f3n de OCL y estereotipos que describen las reglas, que en UML 2 se capturan en un paquete.<\/p>\n
Diagramas relacionados para el desarrollo de software<\/h3>\n
Entre las diferencias entre las metodolog\u00edas de OOAD y la evoluci\u00f3n de los est\u00e1ndares de UML, los nombres de los diagramas y sus funciones pueden evolucionar con el tiempo. Aqu\u00ed hay algunos ejemplos de diagramas y\/o productos de trabajo que podr\u00edan o no formar parte de UML1 o UML2, pero que podr\u00edan usarse en metodolog\u00edas de OOAD:<\/p>\n
- \n
- Diagrama de contexto del sistema<\/b><\/li>\n
- Diagrama de relaciones entidad (similar al Diagrama de clases) con ERD conceptual, l\u00f3gico y f\u00edsico<\/b><\/li>\n
- An\u00e1lisis de robustez<\/b><\/li>\n<\/ul>\n
Conclusi\u00f3n<\/h2>\n
Hemos examinado los or\u00edgenes y la definici\u00f3n de UML para proporcionar una comprensi\u00f3n simplificada de qu\u00e9 es y qu\u00e9 puede ofrecernos. Tambi\u00e9n hemos analizado c\u00f3mo podemos beneficiarnos de su uso en nuestro pr\u00f3ximo proyecto de desarrollo y explorado brevemente las vistas arquitect\u00f3nicas, modelos y tipos de diagramas disponibles en UML 2. UML no es un proceso, sino una notaci\u00f3n visual est\u00e1ndar abierta para el desarrollo de sistemas intensivos en software. Los componentes necesarios para un proyecto exitoso requieren tres aspectos: una notaci\u00f3n, un proceso y una herramienta:<\/p>\n
\u00a0<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/Triangle-of-Success.gif\")
<\/a><\/p>\n\u00a0<\/p>\n
Solo notaci\u00f3n<\/strong> \u2013 puedes aprender una notaci\u00f3n (por ejemplo, UML)<\/strong>, pero si no sabes c\u00f3mo usarla (proceso<\/strong>), probablemente fracasar\u00e1s.<\/p>\n
Proceso Solo<\/strong> \u2013 Es posible que tengas un gran proceso<\/strong>, pero si no puedes comunicar el proceso (notaci\u00f3n<\/strong>), probablemente fracasar\u00e1s. Y por \u00faltimo<\/p>\n
Sin Soporte de Herramienta<\/strong> \u2013 si no puedes documentar eficazmente los artefactos de tu trabajo (herramienta<\/strong>), probablemente pierdas mucho tiempo y finalmente fracases.<\/p>\n
\u00a0<\/p>\n
Herramienta Automatizada de UML<\/h2>\n
Visual Paradigm<\/a> es una herramienta automatizada que garantiza que tendr\u00e1s \u00e9xito en tus proyectos de software con:<\/p>\n
- \n
- Edici\u00f3n de sintaxis sencilla para minimizar la necesidad de memorizar notaci\u00f3n<\/li>\n
- Soporte para procesos y conjunto de herramientas de desarrollo de software \u00e1giles y populares, y los m\u00e1s f\u00e1ciles<\/li>\n
- Automatizado para agilizar cualquier tama\u00f1o de proyecto, informe de producto y artefacto en tiempo real<\/li>\n<\/ol>\n
Recursos de UML<\/h2>\n
- \n
- Gu\u00eda completa sobre los 14 tipos de diagramas UML \u2013 Cybermedian<\/strong>\n
- \n
- Esta gu\u00eda ofrece una visi\u00f3n general de los 14 tipos de diagramas UML compatibles con la edici\u00f3n comunitaria de Visual Paradigm. Explica c\u00f3mo los diagramas UML ayudan a visualizar sistemas intensivos en software y describe la funcionalidad proporcionada por cada tipo de diagrama. La gu\u00eda tambi\u00e9n destaca la versatilidad de Visual Paradigm para apoyar diversos diagramas UML seg\u00fan las necesidades de modelado11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Aprende modelado UML con las mejores herramientas gratuitas de UML (tanto en l\u00ednea como de escritorio) \u2013 Cybermedian<\/strong>\n
- \n
- Este art\u00edculo discute los beneficios de usar Visual Paradigm para el modelado UML, destacando su soporte para la \u00faltima norma UML 2.x y su amplia gama de tipos de diagramas. Tambi\u00e9n menciona las capacidades de integraci\u00f3n de la herramienta con plataformas de desarrollo populares y su amplia adopci\u00f3n en el \u00e1mbito acad\u00e9mico y la industria12<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Aprender por ejemplo: Diagramas de M\u00e1quina de Estados UML \u2013 Cybermedian<\/strong>\n
- \n
- Este recurso se centra en los diagramas de m\u00e1quina de estados UML y recomienda Visual Paradigm como una herramienta ideal para crear estos diagramas. Proporciona una visi\u00f3n detallada sobre c\u00f3mo los diagramas de m\u00e1quina de estados pueden modelar el comportamiento din\u00e1mico de los sistemas y destaca la integraci\u00f3n de Visual Paradigm con herramientas y plataformas de desarrollo13<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Diagramas UML: Una gu\u00eda completa \u2013 Cybermedian<\/strong>\n
- \n
- Esta gu\u00eda completa explica la importancia de los diagramas UML en el desarrollo de software y c\u00f3mo Visual Paradigm apoya diversos tipos de diagramas UML. Cubre diagramas estructurales, comportamentales e interacci\u00f3n, proporcionando perspectivas sobre c\u00f3mo se puede utilizar Visual Paradigm para crear modelos UML efectivos14<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Herramienta en l\u00ednea gratuita de diagramas UML \u2013 Cybermedian<\/strong>\n
- \n
- Este art\u00edculo presenta Visual Paradigm Online (VP Online) Edici\u00f3n Express, una herramienta en l\u00ednea gratuita para crear diagramas UML. Destaca la facilidad de uso de la herramienta, la ausencia de limitaciones y su compatibilidad con diversos navegadores web, convirti\u00e9ndola en una opci\u00f3n accesible para la creaci\u00f3n de diagramas UML personales y no comerciales15<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Comprender los diagramas de tiempo UML: Una gu\u00eda completa \u2013 Cybermedian<\/strong>\n
- \n
- Esta gu\u00eda explica los diagramas de tiempo UML y su importancia en los sistemas en tiempo real. Discute c\u00f3mo se puede utilizar Visual Paradigm para crear estos diagramas, centr\u00e1ndose en la representaci\u00f3n visual de las restricciones de tiempo y duraci\u00f3n dentro de un sistema16<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- La gu\u00eda completa sobre los diagramas UML 2.5 \u2013 Cybermedian<\/strong>\n
- \n
- Esta gu\u00eda ofrece una visi\u00f3n general de los diagramas UML 2.5 y destaca a Visual Paradigm como una elecci\u00f3n principal para la modelizaci\u00f3n completa. Discute la versatilidad de la herramienta, su interfaz amigable y sus s\u00f3lidas capacidades de generaci\u00f3n de c\u00f3digo, lo que la hace adecuada para profesionales de diversos sectores17<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Una gu\u00eda completa sobre el diagrama de clases UML \u2013 Cybermedian<\/strong>\n
- \n
- Esta gu\u00eda se centra en los diagramas de clases UML y en c\u00f3mo Visual Paradigm apoya su creaci\u00f3n. Discute la amplia adopci\u00f3n de la herramienta en el \u00e1mbito acad\u00e9mico y su uso en el dise\u00f1o y an\u00e1lisis de sistemas y bases de datos. La gu\u00eda tambi\u00e9n menciona la disponibilidad de ejemplos y plantillas para comenzar r\u00e1pidamente con la modelizaci\u00f3n UML18<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Tutorial de diagrama de paquetes UML usando Visual Paradigm \u2013 Cybermedian<\/strong>\n
- \n
- Este tutorial muestra los pasos para crear un diagrama de paquetes UML usando Visual Paradigm. Explica la importancia de los diagramas de paquetes para organizar sistemas grandes y proporciona una gu\u00eda paso a paso para crearlos usando Visual Paradigm19<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- La gu\u00eda completa sobre modelado visual para el desarrollo de software \u00e1gil \u2013 Cybermedian<\/strong>\n
- Tutorial de diagrama de paquetes UML usando Visual Paradigm \u2013 Cybermedian<\/strong>\n
- Una gu\u00eda completa sobre el diagrama de clases UML \u2013 Cybermedian<\/strong>\n
- La gu\u00eda completa sobre los diagramas UML 2.5 \u2013 Cybermedian<\/strong>\n
- Comprender los diagramas de tiempo UML: Una gu\u00eda completa \u2013 Cybermedian<\/strong>\n
- Herramienta en l\u00ednea gratuita de diagramas UML \u2013 Cybermedian<\/strong>\n
- Diagramas UML: Una gu\u00eda completa \u2013 Cybermedian<\/strong>\n
- Aprender por ejemplo: Diagramas de M\u00e1quina de Estados UML \u2013 Cybermedian<\/strong>\n
- Aprende modelado UML con las mejores herramientas gratuitas de UML (tanto en l\u00ednea como de escritorio) \u2013 Cybermedian<\/strong>\n
- Esta gu\u00eda ofrece una visi\u00f3n general de los 14 tipos de diagramas UML compatibles con la edici\u00f3n comunitaria de Visual Paradigm. Explica c\u00f3mo los diagramas UML ayudan a visualizar sistemas intensivos en software y describe la funcionalidad proporcionada por cada tipo de diagrama. La gu\u00eda tambi\u00e9n destaca la versatilidad de Visual Paradigm para apoyar diversos diagramas UML seg\u00fan las necesidades de modelado11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Gu\u00eda completa sobre los 14 tipos de diagramas UML \u2013 Cybermedian<\/strong>\n
- Diagrama de relaciones entidad (similar al Diagrama de clases) con ERD conceptual, l\u00f3gico y f\u00edsico<\/b><\/li>\n
- Diagrama de comunicaci\u00f3n<\/b>(tambi\u00e9n conocido como <\/b>Diagramas de colaboraci\u00f3n de UML1) \u2013 es un diagrama de c\u00f3mo los sistemas colaboran entre s\u00ed para realizar una tarea y las asociaciones que deben existir entre los sistemas. El diagrama de colaboraci\u00f3n es el resultado de tomar el diagrama de secuencia y describir su interacci\u00f3n con el diagrama de clases. En resumen, este diagrama muestra el flujo de mensajes entre objetos y las asociaciones b\u00e1sicas (relaciones) entre clases<\/li>\n
- Diagrama de actividad<\/b> \u2013 es un diagrama de la naturaleza din\u00e1mica de un sistema mediante la modelaci\u00f3n del flujo de control de actividad a actividad. Representa c\u00f3mo un sistema (por ejemplo: objeto\/clase) responde a un evento interno. (nota: los eventos externos se describen mediante un Diagrama de estado). Para la modelaci\u00f3n de procesos de negocio, puedes utilizar este diagrama para modelar la l\u00f3gica de un caso de uso o regla de negocio.<\/li>\n
- Diagrama de objetos<\/b> \u2013 es un diagrama de la estructura est\u00e1tica de un sistema en un momento o situaci\u00f3n espec\u00edfica (instant\u00e1nea) que ilustra una relaci\u00f3n en un sistema.<\/li>\n
- Diagramas comportamentales \u2013 Cualquier sistema puede tener dos aspectos, est\u00e1tico y din\u00e1mico. Por lo tanto, un modelo se considera completo cuando ambos aspectos se cubren completamente.\n
- Diagramas estructurales \u2013 Eldiagramas estructurales<\/i>representan el aspecto est\u00e1tico del sistema. Estos aspectos est\u00e1ticos representan aquellas partes de un diagrama que forman la estructura principal y por tanto estable. Estas partes est\u00e1ticas se representan mediante clases, interfaces, objetos, componentes y nodos.<\/li>\n
- Vista l\u00f3gica: <\/em>muestra c\u00f3mo se dise\u00f1a esta funcionalidad dentro del sistema, en t\u00e9rminos de su estructura est\u00e1tica y comportamiento din\u00e1mico; se describe mediante diagramas de clases y objetos (modelo est\u00e1tico) y diagramas de transici\u00f3n de estado, secuencia, colaboraci\u00f3n y actividad (modelo din\u00e1mico)<\/li>\n
- Vista de casos de uso:<\/em> muestra la funcionalidad del sistema tal como la perciben los actores externos; se describe mediante diagramas de casos de uso y ocasionalmente mediante diagramas de actividad.<\/li>\n
- Notaci\u00f3n<\/i><\/b>: Representaci\u00f3n visual de los elementos de modelo<\/li>\n
- Elementos de modelo<\/i><\/b>: Conceptos y sem\u00e1ntica<\/li>\n