¿UML murió y nadie se dio cuenta?



UML, te extrañaremos El



lenguaje de modelado unificado (UML) , desarrollado por Rational Software y adoptado como estándar por el Object Management Group (OMG) en 1997, tenía la intención de estandarizar muchos tipos diferentes de notaciones gráficas adoptadas por la industria del desarrollo de software. .



Mi historia de relación con UML comenzó hace casi una década, cuando me convertí en un evangelista de este lenguaje como puente entre TI y negocios . Nunca he estado completamente convencido del valor de UML como notación para modelar productos de software específicos; mi objetivo era usar UML para describir las propiedades estructurales y de comportamiento requeridas que se esperaban del sistema diseñado.



La revelación para mí fue la semántica formal asociada con los diagramas de actividad UML. No podía soportar los diagramas de Visio informales debido a las muchas ambigüedades en ellos. Por ejemplo, ¿qué significan las dos flechas que salen del rectángulo: selección o división de la secuencia en dos rutas paralelas? Un ejemplo similar: ¿dos flechas que apuntan al mismo rectángulo significan que la acción comienza inmediatamente después de que el primer hilo llega al rectángulo? ¿O tal vez sea OR, XOR o AND? En general, entiendes el punto. UML resuelve este problema introduciendo una semántica clara e inequívoca.





El juego fue injusto desde el principio: no hay una respuesta correcta.



Realmente puse mi corazón y mi alma en el UML:



  • Dibujé diagramas para mis propias soluciones desde 2004 hasta 2015 para siete empleadores y clientes diferentes utilizando casi exclusivamente UML.
  • UML ( -) .
  • , UML. Haskell GraphViz UML.


Unos años después, alrededor de 2015, me di cuenta de que prácticamente había dejado de usar UML, al igual que el resto de mis colegas, así como casi todos los clientes de Fortune 500 que he consultado últimamente. ¿Qué sucedió?



Sé que fue la muerte por mil cortes. Y no, UML no ha matado a la comunidad empresarial debido a su complejidad o rigor. Por el contrario, a los empresarios les encantaba la capacidad de comunicarse de forma clara e inequívoca con algunos símbolos nuevos. La gente de TI elevó el UML (hice esto en un momento), y también hicieron que cayera.



Pero el UML en sí no fue la víctima. Francamente, el UML es solo una pérdida colateral. La verdadera masacre fue en el área de desarrollo de requisitos, que incluye inteligencia empresarial y diseño. Agile se convirtió en el asesino y las historias de usuarios fueron sus flechas envenenadas.



En el modelo, donde las historias de los usuarios se introducen en la entrada y se recibe una demostración (o una versión de producción de funciones) en la salida, no hay más espacio para un análisis estructural significativo de las tareas.



En el mundo feliz de hoy, la comprensión se cristaliza directamente en un código listo para producción. Incluso el modelado de negocios, de hecho, ha sido eliminado por una disciplina ágil relacionada: el diseño dirigido por dominios (DDD). Los contextos delimitados encapsulan (barren debajo de la alfombra) la complejidad para que una empresa pueda escalar a "equipos de dos pizzas". Las empresas que utilizan BDD y requieren que sus equipos escriban las especificaciones de Pepino tienen la ventaja aquí, pero muy pocas empresas lo hacen.



El paradigma moderno es que todavía no seremos capaces de comprender el problema. Los gurús de la transformación digital nos dicen que debemos implementar productos en producción para que los propios usuarios puedan saber cuáles son los requisitos comerciales y no formularlos ellos mismos a priori. Gracias a esto, podemos hacer varios intentos para hacerlo bien. Sí, en este paradigma hay que cometer errores rápidamente y con frecuencia.



Debería haberse dado cuenta a estas alturas de que esto no es un defecto de UML. Simplemente abandonamos el análisis empresarial y las especificaciones formales, por lo que nos enfrentamos a una nueva pregunta: ¿qué usar en lugar de UML?





Un ejemplo de diagrama de masala



Si bien algunos utilizan técnicas de modelado ligeras como C4 , la mayoría de los diagramas que se utilizan hoy en día son del tipo al que me refiero con cierto desdén como "diagramas de masala" . Después de todo, ¿por qué no llamar a los diagramas que yo mismo hago? ¿Por qué Masala? Porque son informales; cubren simultáneamente varias dimensiones, pueden ser estructurales y de comportamiento, lógicas y físicas. A menudo son una mezcla de representaciones de un modelo arquitectónico 4 + 1 .





Cómo preparar un diagrama de Masala



Los sistemas de millones de dólares de los que dependen nuestras vidas y nuestras finanzas se crean, financian e implementan en su totalidad a partir de estos diagramas de masala, que a menudo contienen nada más que algunas epopeyas e historias de usuarios.



"Autor, bueno, ¡la arquitectura del sistema hipotecario de mi banco ciertamente no fue diseñada sobre la base de estos horribles modelos masala suyos!"


No puede ser verdad, ¿verdad? De hecho, si su banco no utiliza CICS y la solución se vendió el año pasado, existe una alta probabilidad de que se haya construido sobre la base de los mismos diagramas de masala.



¿Se ha vuelto loco el mundo? No, simplemente renunciamos a la ingeniería de software. Ahora es solo una apuesta de código . No estoy diciendo que quienes escriben software no sean ellos mismos ingenieros; la mayoría de las veces, no lo es. El caso es que a nivel organizacional, el software ya no se diseña , como se hace en otras áreas, por ejemplo, en la ingeniería mecánica. Boeing nunca encargaría un motor a reacción de Rolls Royce basándose en un diagrama de masala tan informal.



Sin embargo, los diagramas de masala tienen su propio propósito. Cuando se usan donde pertenecen, son hermosos. Verá, estas no son especificaciones . Su objetivo es evocar emociones. Los diagramas de Masala son valiosos cuando necesitas alegrar el corazón del líder a quien están destinados.



No importa cuánto discuta con mis amigos del campo Agile, no puedo permanecer ciego ante la felicidad de la gente. Mis clientes y colegas no solo piden más diagramas de masala , sino que insisten en que los haga aún más masala (¡para combinar más dimensiones arquitectónicas en ellos!). ¿Por qué resistirse a esto?



UML todavía permanece en mi corazón y continúo estructurando soluciones usando varias dimensiones, pero en forma de datos / tablas puros. Y cuando se trata de notación gráfica, saco mi licuadora y una sartén de 5 litros y empiezo a hacer una tabla de masala maravillosa para mis clientes favoritos.






Publicidad



Los servidores Epic son VDS para alojar sitios desde una pequeña tienda en línea en Opencart hasta proyectos serios con una gran audiencia. ¡Cree sus propias configuraciones de servidor en un par de clics!



Únete a nuestro chat de Telegram .






All Articles