DSN_XP y el método BOOCH

El método de Booch

DSN_XP en su versión 1.0 encuentra en el estudio de UML los modelos técnicos que eran utilizados por las metodologías que dieron soporte al lenguaje de modelado universal.

Metodología Booch

Fuente de conocimientos DSN_XP

El Método de Booch y su Influencia en DSN_XP 1.0

El desarrollo de software ha evolucionado a lo largo de los años, buscando siempre metodologías que permitan crear sistemas más eficientes, robustos y adaptables. En este contexto, el Método de Booch, con su enfoque en la orientación a objetos, ha dejado una huella significativa. En este artículo, exploraremos este método y su relevancia en el desarrollo de DSN_XP 1.0.

¿Qué es el método de Booch?

El Método de Booch es una metodología de desarrollo de software orientado a objetos creados por Grady Booch en Rational Software Corporation (posteriormente adquirido por IBM). Se centra en cuatro pilares fundamentales:

  • Abstracción: Simplificar la complejidad del sistema mediante la identificación de los aspectos esenciales.
  • Encapsulamiento: Ocultar los detalles de implementación y exponer solo las interfaces necesarias.
  • Modularidad: Dividir el sistema en componentes independientes e interconectados.
  • Jerarquía: Organizar los componentes en una estructura jerárquica para facilitar la comprensión y el mantenimiento.

Componentes Clave del Método

El método se compone de tres elementos principales:

  • Notación: Un lenguaje para representar los modelos del sistema (como UML).
  • Proceso: Las actividades que guían la construcción ordenada de los modelos.
  • Herramientas: Los artefactos que automatizan tareas y ayudan a detectar errores e inconsistencias en los modelos.

Modelos en el Diseño Orientado a Objetos

El diseño orientado a objetos, promovido por Booch, busca crear software resistente al cambio y con una expresión concisa. Se basa en la creación de varios modelos:

  • Modelo Lógico: Representa la estructura conceptual del sistema.
  • Modelo Físico: Describe la implementación física del sistema, incluyendo hardware y software.
  • Modelo Estático: Muestra la estructura del sistema en un momento dado.
  • Modelo Dinámico: Describe el comportamiento del sistema a lo largo del tiempo.

Filosofía y Principios del Diseño según Booch

Booch enfatiza la importancia de una etapa de análisis seguida por una de diseño. El diseño se define como una aproximación disciplinada para resolver un problema, guiando desde los requerimientos hasta la implementación.

Principios clave del diseño:

  • Crear una arquitectura interna clara y sencilla.
  • Equilibrar los requisitos en conflicto.
  • Utilizar modelos para razonar sobre las estructuras y facilitar la toma de decisiones.

Los modelos permiten simular y probar el sistema en condiciones controladas, identificando posibles fallos y realizando ajustes antes de la implementación.

Valores en la Construcción de Sistemas

La construcción de un sistema implica:

  • Satisfacer los requisitos funcionales.
  • Adaptarse a las limitaciones del entorno.
  • Cumplir con los requisitos implícitos y explícitos sobre la forma del artefacto.
  • Respetar las restricciones del proceso de diseño, como el tiempo, el coste y las herramientas disponibles.

El Ciclo de Vida Iterativo e Incremental

Booch recomienda el modelo iterativo e incremental para el ciclo de vida del software. Este enfoque permite refinar la arquitectura a través de iteraciones sucesivas y entregar incrementos funcionales del sistema.

DSN_XP 1.0 y la influencia del método de Booch

DSN_XP 1.0 reconoce la importancia de los modelos técnicos utilizados en las metodologías que dieron origen a UML. Se opone a dos extremos: la anarquía (falta de un ciclo de vida definido) y la dictadura (exceso de rigidez que sofoca la creatividad).

DSN_XP 1.0 promueve un proceso iterativo e incremental, donde se refina la arquitectura orientada a objetos a través de iteraciones sucesivas, incorporando la experiencia de cada iteración. Este enfoque permite converger hacia una solución que cumpla con los requisitos del usuario, siendo a la vez simple, confiable y adaptable.

DSN_XP y las triadas o la Ley del 3

Triadas

Tres dimensiones en una

DSN_XP inicialmente como metodología (estudio del método) profundizó el método científico como la herramienta necesaria para poder sostener todos los argumentos requeridos para la concepción filosófica de nuestro marco de trabajo, en especial en la versión 1.0

Creatividad y el pensar

Cuando empezamos a investigar sobre los factores de la creatividad que existían en los diseños codificados de los programadores, pudimos observar la presencia de lo que denominamos como estructuras mentales de pensamiento conocidas como systematics o el estudio de las dimensiones del pensamiento para DSN_XP.

Al buscar los componentes filosóficos que sintetizan el procedimiento de utilizar un lenguaje de programación para estructurar ideas abstractas y con ello poder captar un escenario y luego procesarlo mediante la relación software/hardware, exigía la presencia de nuevas herramientas para la comprensión del fenómeno ya que implicaba por defecto, el estudio de la mente y el proceso cognitivo más un conjunto de marcos de trabajos relacionados con algoritmos, modelizados, estructuras de control, dependencia de fenómenos no conocidos previamente, etc.

El software como artesanía o receta

Un primer acercamiento al modelo científico fue desplegado gracias a las investigaciones del grupo KYBELE, este hecho nos puso de frente a la necesidad de buscar raíces más profundas en la filosofía para comprender justamente los principios del método de razonamiento y la experimentación, dos momentos dentro del proceso de la creatividad del programador y el denominado modelo básico de programación que nos fuera enseñado en las aulas y que se trataba del modelo codificar y corregir.

Al entrar de lleno entonces en el mundo de la filosofía, entendíamos que definir un marco de trabajo para desarrollar software se volvía un tema más complejo que la definición de un modelo del ciclo de vida del desarrollo de software, esto es así porque desde los inicios de la ingeniería del software, los artefactos de diseño fueron tomados prestados desde otras ciencias y adaptados en conjunto con otras tecnologías.

La raíz del mirar DSN_XP

Teníamos como DSN_XP el objetivo el determinar la eficiencia de la experimentación, como uno de los procesos naturales que sostienen la creatividad y el diseño básico soportado por nuestro modelo, esto nos ponía como método de desarrollo de software, entre las escuelas de diseño más criticadas en la década de transición hacia el 2000, ya que se exigía de la industria del software la predictibilidad del software que fue demostrada en su proceso de inserción gracias a la revolución tecnológica y las supercomputadoras para el cálculo estadístico.
La experimentación, como método intuitivo y personalizado del programador era el resultado de todo un proceso de transformación y avance de la tecnología electrónica aplicada al procesamiento de datos, este proceso de diseño se puede comprender cuando se profundiza en el estudio del software como tecnología y no como ciencia, nuevamente, esta observación ya fue estudiada por KYBELE, pero no resuelve el proceso de aprendizaje basado en el error que implica el modelo de codificar y corregir que se vuelve experimental para el programador.
Esta observación de separar la parte blanda del diseño del software de su parte dura por implementación, implica dentro del estudio filosófico del diseño del software a aquellos conceptos de diseño como la ocultación de información y el encapsulado, fenómenos que la ciencia y sus métodos no soportan por concepto de la presencia del cambio en el modelo (falsación) que pondría en evidencia la robustez de la teoría producto resultante del método científico.
Dada esta restricción en nuestro proceso de investigación del software, recurrimos a la lógica dialéctica para el estudio del diseño de software, en especial, del proceso de impacto en el diseño debido al cambio como producto de un aprendizaje en el proceso de abstracción del problema y su solución. 

Más allá de una dualidad

DSN_XP estudia a las triadas como una estructura mental que permite el proceso de abstracción de forma diferente al proceso dual; el ser humano constantemente recurre a la dualidad para abarcar un concepto o evento, esto es así ya que pensamos en extremos para cuantificar diferencias como medio de abstracción, ejemplo: bueno y malo, día y noche, arriba y abajo, si y no, etc., 

En cualquier cosmología o sistema total, existe una diada básica de lo Absoluto y lo Relativo, donde hay manifestación, lo relativo es triple. Por lo tanto, siempre podemos hablar de cuatro mundos o de tres mundos inmanentes en un mundo.  En la tradición hindú esto está de acuerdo con la doctrina Samkhya de las tres gunas, En cosmología de Bennett, las tres gunas corresponden a función, ser y voluntad.

Sólo existen pocos modelos en los cuales de forma natural se recurren a tres (3) dimensiones en una, por ejemplo: largo, ancho y profundidad, ayer, hoy y mañana y sólido, líquido y gaseoso como los únicos ejemplos de triadas, lejos de este punto se concluye que la mayor parte de abstracciones son de tipo dual o basadas en imágenes, fotografías o registros que no pueden incluir la tercera dimensión porque no es visible para este razonamiento 

El estudio de las estructuras mentales del pensamiento como elemento fundamental para el uso de [Perspectivas] dentro del #TEAMVIEW.

Las triadas permiten obtener el pensamiento inverso que se requiere para modelar algo, en la Ingeniería Software existen varios artefactos basados en la noción de triadas, esta sección justamente se dedica a identificar y analizar dichos artefactos con el pensamiento basado en triadas :o)

El sistema basado en triadas relaciona la acción, la relación misma y el escenario de vida en el que se manifiesta, la orientación a objetos contempla también este aspecto al abstraer un acción como el resultado de un procesamiento de acuerdo a un evento en particular, es por esta razón que preferimos al esoterismo sobre el método tradicional en la investigación científica para el diseño del software, ya que es en base al esoterismo que nos es más transparente explicar los conceptos de la orientación a objetos de forma académica, esto es DSN_XP.


El primer acercamiento formal antes del esoterismo que DSN_XP contactó fue una acercamiento sobre ingeniería de software en un foro de discusión, en el cual preguntábamos sobre una nueva forma de aplicar un método basado en triadas al estudio del software.


Descubrimos que la escuela de pensamiento que soportaba los argumentos de mi compañero de foro denominada Unicismo utiliza una muy interesante combinación sobre las triadas que se explicarán en otro post a futuro, también esto nos llevó a conocer las fuentes de la sabiduría ZEN y el Cuarto Camino :o) 

El unicismo aplica el concepto de triada para describir y comprender un sistema, ya que cualquier sistema está integrado por un propósito, una función activa y una función de conservación de energía para asegurar los resultados. 

Ejemplos triádicos aplicados al estudio ontogenético funcional o enfoque funcionalista:
  • La función activa y la función de conservación de energía de la inteligencia de un árbol impulsan su crecimiento y supervivencia. 
  • La elevación y propulsión hacen que los aviones despeguen y vuelen.
  • La música y la letra de una canción definen su estética.

La naturaleza del software y su triada de computo



La naturaleza del desarrollo de software y su triada de uso



El uso de las triadas en la gestión de proyectos de desarrollo de software


Existen tres fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la calidad del producto final.

Cada fuerza es asociada a una variable de cálculo, el tiempo se convierte en cronograma, los recursos en costos y el alcance en funcionalidades, la resultante se mide en el éxito o fracaso del proyecto.

El equipo de desarrollo es responsable del alcance, el tiempo y los recursos son asignados al cliente, el proceso creativo del software tiene que ser transformado en retorno de inversión de acuerdo al esfuerzo aplicado a una funcionalidad específica.


Existen tres fuerzas básicas detrás del diseño de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la demanda del producto final.

Cada fuerza es asociada a una variable de cálculo, el producto se convierte en esfuerzo, el mercado en ingresos y las administración en costos, la resultante se mide en el éxito o fracaso del producto.

El equipo de desarrollo es responsable del producto, la administración y el mercado son asignados al cliente, el costo de fabricación del software tiene que ser transformado en la optimización de recursos de acuerdo al esfuerzo aplicado a una funcionalidad específica.


Existen tres fuerzas básicas detrás de un proyecto software, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina el entorno de trabajo.

Cada fuerza es asociada a una perspectiva de interés en el éxito del proyecto, el software determina la usabilidad, el business determina el factor de oportunidad y el team determinan el compromiso de cada uno de los miembros del equipo multidisciplinar.

El adecuado proceso de estimación de esfuerzos tiene que ser equilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que un equipo cansado y no motivado repercute en el entorno de trabajo, en la calidad del producto y en la entrega a tiempo de las funcionalidades.


Existen tres fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la usabilidad del producto final.

Cada fuerza es asociada a una fuente de información, el stakeholder provee las necesidades de requerimientos para la toma de decisiones, el usuario provee el conocimiento y el proceso que se desea abstraer, el desarrollador provee las mejoras al proceso y la simplicidad de la herramienta.

Es responsabilidad del equipo de desarrollo el comprender y balancear estos requerimientos en funcionalidades y servicios para el uso correcto del producto.


Existen tres fuerzas básicas detrás de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras dos, la conjugación correcta de las mismas determina la calidad del producto final.

Cada fuerza es asociada a un factor de diseño, las historias de usuario capturan las necesidades del producto por parte de los usuarios (retorno de inversión), los criterios de aceptación capturan las necesidades del stakeholder principal (priorización) y las sentencias de trabajo definen sin ambigüedades las especificaciones del software (esfuerzo).

Es responsabilidad del equipo de desarrollo el verificar que cada historia posea los tres indicadores para una adecuada gestión del proyecto.

La triada de la permacultura

Tenemos el cuidado de la tierra, el cuidado de la gente y la repartición justa

La triada de la actitud

Tenemos el pienso, el quiero y el hago

La triada de la ética

Tenemos el crecer por mi, el crear por los demás y el cocrear por el mundo

La triada de la calidad

Procesos, entendiéndose como el conjunto de actividades en cierta secuencia que permiten alcanzar un objetivo, usualmente si el proceso no se encuentra bien definido o diseñado, estos aspectos tienen su impacto en la medición de la calidad del software.

Personas, es tal vez el elemento más complicado del desarrollo del software ya que son las personas las que interactúan con el producto software y determinan el conjunto de atribuciones externas que en conjunto definen la calidad del producto.

Producto, entendiéndose este como el objeto de análisis de los factores de la calidad de acuerdo a la injerencia de los otros dos elementos a todo el proceso de desarrollo de software.

La triada de los lenguajes en la solución de problemas

Este es un material que hemos tomado prestado de la base de conocimientos de LeanSight y hace referencia a las tres perspectivas que existen en el desarrollo de soluciones y casi de forma específica en el desarrollo de software.

La triada de la planificación ágil

Este es un material que hemos tomado prestado de Roman Picher respecto al Rol de Product Owner y que contempla la perspectiva táctica o el conjunto de actividades para concretar algo para luego contemplar la perspectiva estratégica de la situación y finalmente contemplar la perspectiva de una visión compartida para la organización.