Esto es un interludio entre nuestros temas habituales. Esta publicacion esta un nivel por debajo y uno hacia adentro del desarrollo de modelos cuantitativos, un nivel mas abajo a usar un lenguaje de programacion o un marco para automatizar la gestion de activos. Vamos a hablar de la arquitectura a gran escala de los programas y de un metodo para documentarlos minimamente con un impacto minimo en el esfuerzo de implementacion, utilziaremos un minimo ejemplo tambien.
En Ostirion, creemos y aplicamos donde sea posible los principios de la ingenieria de sistemas tal y como se describen en ISO/IEC/IEEE 15288. A veces al pie de la letra, a veces con flexibilidad. Creemos sinceramente que una buena arquitectura puede hacer que una implementacion defectuosas acabe funcionando y que es muy dificil hacer que cualquier implementacion de codigo funcione (con eficacia aceptable) dentro de una mala arquitectura. Esto causa cierta tension con otras aproximaciones mas agiles y hemos sido testigos de las tensiones entre 15288 y SCRUM de primera mano. Hablaremos de estas tensiones y de como relajarlas en un interludio futuro ya que hoy hablaremos de la generacion de diagramas UML de manera automatizada para codigo Python. Un metodo y herramienta eficientes para generar las necesidades minimas de representacion o documentacion o para llamadas propias de "ayuda" al usar codigo fuente abierto sub-documentado.
Las razones para buscar esta automatizacion de los diagramas UML son, en nuestra experiencia, estos tres:
Documentar una base de codigo antigua que se usara como linea base para productos derivados.
Reducir el esfuerzo de documentacion para codigo que se esta generando.
Asegurar que la documentacion en UML representa fielmente el codigo.
Existen multiples herramientas comerciales que simplifican la gestion de la documentacion del codigo utilizando diagramas UML. Estos paquetes comerciales son relativamente caros y presentan sus funciones codigo-a-UML y UML-a-codigo como una herrmaienta secundaria. Un buen ejemplo es la ampliamente utlizada aplicacion Enterprise Architect, donde la funcionalidad de "cogido de ida y vuelta" esta en ma mita del catalogo comercial. Bien podria ser el primero, y de manera un tanto radical, el unico realmente necesario para un desarrollo efectivo. Si no se pueden ver los elementos arquitectonicos del sistema reflejados en el codigo, estos elementos no deberian existir. Si el codigo no exhibe todos los elementos arquitectonicos, algo esta mal implementado. El viaje de ida y vuelta entre cogido y arquitectura es una necesidad.
Este abismo se crea debido a la gran diferencia en los conjuntos de habilidades entre los profesionales que definen el sistema y los profesionales que implementan el codigo. Este hueco hace que mezclar diagramas abstractos e implementacion concreta de codigo sea poco apetecible y que se generen dos facciones durante un proyecto. Como dos serpientes, enfrentadas.
Es dificil para los ingenieros de sistemas entender completamente el codigo y dificil para los desarrolladores mantenerse al dia con la definicion del sistema y los requisitos de documentacion. Sea cual sea el marco y modo de desarrollo, la gestion de sistemas siempre esta en riesgo de disociarse de la solucion de codigo, los cambios dejan de documentarse, emerge la indisciplina sistemica y la calidad y la funcionalidad cae con una perdida consecuente de valor empresarial.
Cuando el precio es un problema, y generalmente lo es, existen herramientas con funciones de codigo-a-UML de codigo abierto. Una herramienta de estas es pyreverse, integrada en el "quitapelusas" pylint. Utilizaremos un cuardeno Jupyter para una demostracion. Si estas usando una sesion que permite instalacion de modulos, instalamos pylint:
!pip install --q pylint El modulo es lo suficientemente pequeño como para no requerir la informacion de pip. La opcion "--q" reduce la verbosidad de las instalaciones pip. Si quieres saber que paquetes estan instalados en el sistema siempre se puede hacer:
!pip listProduce una lista con todos los modulos instalados similar a esta:
Y para comprobar los modulos internos:
help("modules")Que produce:
Comprobemos uno de los modulos internos usando pyrevers, el modulo "datetime" por ejemplo ya que se usa habitualmente en el analis de series temporales y es lo suficientemente simple y lo suficientemente complejo como para ilustrar el tipo the diagramas que podemos obtener automaticamente con las opciones por defecto:
!pyreverse -o png datetimeEl formato es simple, austero, y encaja con nuestros requisitos minimos de documentacion:
Vemos que las clases comunmente utilizadas datetime, time y timedelta con sus herederos y su compositores. El formato al ser como es, sencillo y austero, nos da otro beneficio: requiere un monton de trabajo para hacerlo digerible en un powerpoint o un word. Es tan austero que no tenemos ninguna tentacion de crear documentos separados y desviarnos de un modelo Model Based Systems Engineering. El territorio se transforma en el mapa, de tal manera que ningun cambio en el terriotiro hace al mapa obsoleto.
Esto no es mas que un ejemplo elemental. Podemos extenderlo a los modulos con los que podemos estar trabajando y que esten sub-documentados, utilizando este metodo como pagina de ayuda de emergencia mientras se genera la base de codigo. Se debe evitar generar estos diagramas UML utilizando herramientas que no incluyan el codigo, o esten desconectadas de este. Las herramientas de integracion, tanto comerciales como abiertas estan disponibles. Evita la destruccion de tus puentes.
Si necesita más información, apoyo con la gestión de ingenieria de sistemas o Model-Based Systems Engineering no dude en contactar con nosotros aquí.