This video discusses the Unified Modeling Language (UML), its importance, and how to use it effectively. The speaker emphasizes the importance of understanding UML diagrams, regardless of one's background in computer science, while cautioning against over-documenting and misinterpreting UML symbols.
[Música] bien en este día vamos a conversar sobre los antecedentes del ml que al día de hoy es el lenguaje de referencia para poder modelar dibujar diseñar etcétera este lenguaje cuando se usa de manera apropiada es una buena práctica como sabemos el ml es sumamente importante seas informático o no al menos saber interpretar sus diagramas si bien hay veces que caemos en el problema de complicar las cosas es decir creamos muchas más diagramas que los necesarios en otras palabras usamos el u ml para documentar demasiado muchas veces cosas que nadie va a utilizar es importante destacar que en ml no siempre se usa para detallar el 100% de detalles de una futura implementación principalmente porque su elaboración consume mucho tiempo en otras palabras el ml no sólo es importante para los informáticos sino que es pensando también en quienes no han estudiado informática para los autodidactas pero en alguna medida trabajan con ellos y necesitan conocer sus dibujos o para los que subcontratan software y no son informáticos o para cualquier otro que necesita entender minímamente un diseño software o transmitir sus ideas sobre el mismo por ejemplo leer los diagramas de ciertas normas iso tal como vemos este ejemplo pero recordemos que también está pensado para nosotros que trabajamos en el área de la informática ya que cada vez que nos pongamos en contacto con nuestra contraparte de la aplicación no deben existir problemas de comunicación y con este lenguaje no debe haber problemas a la hora de interpretar o dibujar te haga más el lenguaje de modelado universal es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema el lenguaje unificado de modelado o ml de unified modeling language no es ni un método ni una metodología ni un ciclo de vida ni similar ml es sólo un lenguaje gráfico símbolos que cuando los vemos todos interpretamos lo mismo para representar partes de un sistema de software diseño comportamiento arquitectura etcétera con los diagramas que nos provee el ml así por ejemplo cuando alguien quiere representar una clase dibuja un cuadrado y todos sabemos a qué se refiere cuando dibuja una flecha cuya punta es un triángulo todos sabemos que es herencia y así sucesivamente esto tiene su lógica razón de ser nos vale para comunicarnos e interpretar todos lo mismo al ver esos diagramas o ml el problema viene cuando a veces hay quien olvida que es ml o lo desconoce y saca el vicio u otro programa similar y da rienda libre a su capacidad artística dibujando cuadrados cuando quiere crear archivos y que luego otros interpretan como una clase ml para eso nos sirve este lenguaje para ponernos de acuerdo en cómo vamos a trabajar los peores errores y peligros vienen cuando alguien usa inconscientemente los mismos símbolos de los diagramas ml pero queriendo decir otras cosas pasa mucho con las flechas se dibuja una flecha cualquiera queriendo decir asociación entre objetos paso de mensajes pero se usa la flecha de herencia y al final se implementa cualquier cosa esto puede llevar al caos dentro del equipo de desarrollo muy cierto y llevándolo al extremo más simplista del mundo como mínimo habría que conocer dos flechas solamente dos la que termina en triángulo gerencia y la que no asociación saber que una clase debe ir en un cuadrado sin esquinas redondeadas y que un objeto es un cuadrado con el nombre de la clase subrayado y dos puntos delante del mismo y no ponerse a dibujar una cosa por otra y de los diagramas ml saber dibujar bien dos los diagramas ml de clases y de secuencia con eso es bastante para la parte del desarrollo del software en síntesis el ml nos sirve para visualizar el sistema especificar el sistema construir aplicaciones documentar sistemas diseñar software también debemos saber que existen diagramas de estructura y diagramas de comportamiento el ml en su plenitud es un lenguaje gráfico muy extenso la última versión que se tiene es la 2.5 tiene más de 15 diagramas vml divididos en los tipos que mencionó antes allison pero en la práctica no vamos a necesitar todos esos pero si necesitas saber qué sml y un mínimo que no será de más de 10 símbolos conocer ese mínimo seamos informáticos o no saber dibujar un diseño o cómo se va a comportar el sistema entender y que se entienda y evitar que se te malinterprete hace ya unos cuantos años en 1994 steve book y jon daniels unas personas apenas conocidas hoy en el mundo del desarrollo y la ingeniería del software escribieron un libro muy interesante el designing object systems que entre otros pretendía aclarar cómo usar correctamente los diagramas típicamente usados en diseño aquel libro sería aún más desconocido de lo que es si no fuese porque fowler que digamos es un autor mucho más popular en la parte del ingeniería del software lo utilizó como base para argumentar en su popular libro ml de styler quizá uno de los mejores libros de vl hay que entender que los diagramas de ml son una buena práctica siempre que no se pase de documentado porque al final la mayoría de esa documentación en exceso no se utilizará y nadie la implementará tal como ya se dijo anteriormente si yo he leído ese libro y para exponerlo de forma resumida steve rooke y jon daniels hacían referencia a tres perspectivas las tres maneras en las que se puede usar un diagrama u ml y que no son siempre detallando al máximo cada detalle de lo que supuestamente luego se implementará uno la conceptual diagramas con conceptos del dominio del negocio y que son independientes del lenguaje muy útiles para que todo el equipo unifique ideas 2la de especificación diferente al anterior más detalle pero sólo observamos las interfaces del software esa importante diferencia en el mundo o entre interfaz y su implementación no su implementación 3 diferenciado de los anteriores la de implementación que muestra al detalle la implementación [Música] bien [Música]
