Analogía entre el diseño orientado a objetos y las inferencias lógicas utilizadas en el proceso de la investigación científica y los procesos de aprendizaje - OTRAS CARACTERÍSTICAS COMUNES ENTRE EL PROCESO DE LA INVESTIGACIÓN

La lectura de³ revela importantes características comunes entre el proceso de investigación y el diseño orientado a objetos. “La comprensión es, entonces, un acto imaginario o simbólico de producción, en el sentido en que algo queda comprendido o explicado para un sujeto cuando los datos del hecho real pueden ser puestos en correspondencia con representaciones internas que corresponden a los esquemas de producción habituales para esa cultura”. De la misma manera, el diseñador crea un modelo simbólico del sistema que está construyendo, y este modelo es correcto (es verificado), cuando puede ser puesto en funcionamiento con los datos de la realidad (o de la fantasía) desde los cuales se hizo el primer análisis. Por lo tanto, el proceso de construcción de software no es ni más ni menos que un proceso de comprensión y modelización de un determinado conjunto de objetos de la realidad (o la fantasía)⁴ que se desea llevar a un sistema de simulación en una computadora.

En otra parte del mismo texto, el Dr. Samaja describe a los sistemas formales como “simulacros o ‘mapas’ (modelos) que permiten una drástica simplificación y generalización de los mecanismos que –por hipótesis- gobiernan el comportamiento de las cosas de manera que operando luego sobre tales mapas logramos orientarnos en el manejo de los procesos reales”. Esta descripción de los sistemas formales no es ni más ni menos que la descripción de un software realizado en un ambiente de objetos. En la puesta en marcha del sistema sobre los procesos reales, iremos modificando nuestro diseño de manera tal que vayamos reflejando con mayor exactitud la realidad. Posteriormente, y una vez que el sistema está validado, corroborado, podremos modificar variables para proyectar y estudiar comportamientos posibles ante sucesos que no se han dado en el mundo real.

En el diseño orientado a objetos, la tarea de exploración, la construcción de la “precomprensión modelizante” es una etapa fundamental. Curiosamente, dado que esta metodología es relativamente nueva en el mercado de desarrollo de software, muchas veces los líderes de proyecto ven con malos ojos este proceso, porque consideran que la programación es una actividad más “apriorista”: lanzarse a “construir” hipótesis (modelos, programas) y luego verificar si estos coinciden con la realidad. Es habitual la discusión entre gerentes y desarrolladores, porque estos últimos “no han escrito nada”, sólo se detuvieron a diseñar y a comprender el modelo, sólo eso…

Como dijimos anteriormente, el diseño es necesariamente un proceso de simplificación, de reducción. Como bien comenta Borges en Funes, el memorioso, pensar (¿diseñar? ¿modelar? ¿hacer ciencia?) es olvidar diferencias, generalizar, abstraer… “[…] cualquier intento de conocer la realidad está obligado a operar de manera inevitable una drástica reducción de su infinita complejidad mediante una operación que, de manera básica, consiste en proponer cuáles serán los elementos o componentes relevantes que se tomarán en cuenta y qué aspectos de ello serán atendidos a la hora de su descripción” escribe Samaja (op.cit). De la misma manera, un diseñador trabaja como un Anti – Funes: olvida, generaliza, abstrae, para construir su modelo. Como un científico…

Podríamos encontrar otros espacios comunes entre el trabajo de un científico y de un diseñador con respecto a la construcción del objeto modelo, a la formalización y a la experimentación. Pero queremos hacer hincapié en la última etapa del proceso científico, el punto más alto, al cual no todos lo investigadores llegan: la creación o definición de una teoría. ¿Existe algún proceso similar en el diseño de software? Como comentamos en el primer punto, cuando un diseñador se encuentra una y otra vez con sistemas similares que debe modelar, comienza a encontrar un conjunto de clases comunes a todos los sistemas de ese tipo. Es a esto lo que llamamos framework. Cuando un diseñador puede construir un framework para un determinado tipo de sistemas, ha llegado a un punto de comprensión y de modelización que cubre horizontalmente un tipo de problema. A partir de ese framework, futuros diseñadores podrán comprender en forma genérica el marco del problema, simplemente personalizar, modificar levemente el mismo, para que se ajuste a las necesidades específicas del sistema que están realizando.

Y encontramos un paso más en esta búsqueda del “patrón universal”, del “número de Dios”: los patrones de diseño. Estos patrones presentan soluciones a problemas universales, a conflictos de diseño que se encuentran en cualquier sistema que uno está construyendo. Son un conjunto de ideas iluminadoras que cubren todo tipo de problemas. Sólo hay un puñado (no más de 20 pequeños modelos), pero conocerlos le permite al diseñador resolver en forma segura (porque son modelos muy probados) y velozmente cientos de los conflictos habituales de su diseño.

Muchísimos elementos comunes entre el proceso científico y el de diseño quedan por describir. Es intención del autor que este material sirva como punto de partida para una “epistemología” de la informática y de la formalización del proceso de construcción del software. Es una tarea que nos debemos para poder entrar en el Olimpo de las ciencias.