TRIZ para Software ( TRIZ for Software)

Analogía de Patrones de Software

 

Introducción

Triz ha llegado a ser muy poderoso para resolver problemas y para crear soluciones innovadoras. Triz es principalmente usado para problemas mecánicos y en la forma actual, no tanto para problemas eléctricos de software. Pero para aplicar TRIZ al software tenemos que aplicar los principios de inventiva. Esos principios de inventiva son usados para resolver un problema algorítmico definiendo una situación ideal, analizando las contradicciones y usando los principios para desarrollar un mejor algoritmo. (Un algoritmo inteligente es como algo equivalente a una construcción inteligente en la Ing. Mecánica).

La traducción desde los Principios de Inventiva al Software es muy difícil de hacer para muchos. Incluso para usuarios expertos en TRIZ.

La traducción hecha por Kevin Rea [Kev-01] ayuda mucho pero solo si uno estas trabajando en un área de aplicación que es el caso de programación concurrente.

Un camino mejor es usar la metodología de Genrich Altschuller analizando las patentes en Ingeniería de Software y desarrollando completamente un nuevo conjunto de Principios de inventiva y Matriz de Contradicciones.

Esto nos abre un camino para poder seguir en nuestra investigación aplicando conceptos de Triz y viendo diversas analogías a este. Las próximas secciones veremos puntos importantes que en el Software resaltan muchos problemas con lo que Triz puede ser una ayuda para romper estas barreras. Asimismo en la otra sección veremos el primer acercamiento a Triz aplicado al software con la respectiva matriz y principios generados por analogías por el autor Darell Mann.

Algoritmos Rápidos

Los Ejemplos que son descritos en la base de datos TRIZ conciernen el desarrollo de algoritmos rápidos y confiables usando recursos limitados (tales como tamaño de memoria y velocidad del procesador). Tenemos que existen un sin número de patentes comerciales donde algunos son exitosos algoritmos o standards que pueden ser comercialmente interesantes, por ejemplo,

Algoritmos	Función
MP3	Procesamiento de Sonido
MPEG	Procesamiento de Video
Algoritmos de Búsqueda Rápida	Google

Tabla 1 - Algoritmos y funciones

Así podemos formarnos una idea, de que tener un conjunto de patentes de software podría ayudarnos a crear una matriz y principios y hacer lo que hizo Altshuller con las patentes.

Un autor llamado Graham Rawlinson concluye que: "TRIZ es muy útil, pero a menudo no acierta con las soluciones derivadas", esto quiere decir que a pesar de que Triz nos ayude a resolver nuestros problemas, no siempre vamos a tener la solución que queríamos o la solución esperada, es decir, no es la “panacea”.

El desarrollo de algoritmos rápidos ha sido sujeto de investigación desde inicios de los sesenta. (Cuando los computadores eran caros y los recursos eran limitados). Aunque muchos de los métodos desarrollados en ese entonces son todavía validos.

Ley de Moore

La ley de Moore expresa que aproximadamente cada dos años se duplica el número de transistores en un circuito integrado. Se trata de una ley empírica, formulada por el co-fundador de Intel, Gordon E. Moore el 19 de abril de 1965, cuyo cumplimiento se ha podido constatar hasta hoy.

Entonces con esa ley se decía que no habría un hardware que pudiera dar solución a los problemas de software que en los cuales se necesitaba de nuevo Hardware para poder realizar las tareas en un modo eficiente, ya que cuando el software probaba que es muy lento, o requiere mucha memoria, simplemente se espera por un nuevo hardware y el problema es resuelto automáticamente.

Crear algoritmos rápidos es importante cuando el Hardware requerido no es todavía disponible dentro un periodo largo de tiempo,

En ingeniería mecánica hay un desafío continuo en crear nuevos productos y tratar con crecientes contradicciones. En muchos productos las limitaciones técnicas han sido (casi) alcanzadas. Por ejemplo, por 100 años los automóviles han manejado bajo motores a combustión, 30 años después el avión comercial Concorde es el avión volando a velocidades supersónicas y así sucesivamente. O sea esto llega cada vez a hacer mas y mas difícil para desarrollar nuevos productos e incrementar la funcionalidad llega a ser pequeño.

Un ejemplo:

Supongamos que un ingeniero mecánico de una empresa automotriz va hacia su jefe y le dice: "Jefe, soy capaz de hacer nuestro motor un 5% más eficiente". Su Jefe probablemente le responda: "Estoy atónito, tomate todo tu tiempo que tu necesites y no olvides escribir una patente".

Ahora si un Ingeniero de Software va hacia su jefe y le dice: " Jefe, yo puedo hacer trabajar nuestro software 5% más rápido", su jefe probablemente responda, " Eso no es de importancia ahora, el próximo mes nosotros obtendremos un nuevo procesador el cual trabaja dos veces más rápido. Vuelve a tu trabajo, que todavía tienes 20 Bugs que resolver antes que termine esta semana, así que no malgastes mas tu tiempo".

Tamaño del Software

Tal como la memoria disponible se incrementa 2 veces en 18 meses, así también las líneas de código. Sin embargo, productos de software están llegando a ser más grandes cada año y más gente necesita desarrollar este software. Es más la moda como sistemas abiertos, subcontratación, re-uso, están disponibles para sobrepasar esto. Todo esto crea situaciones que son más complejas resultando en proyectos fuera de tiempo, software no confiable y clientes insatisfechos.

El principal desafío hoy en día es manejar esta creciente complejidad. Desde comienzos de los noventas hay un fuerte énfasis sobre los procesos de software. Muchas organizaciones están usando la capacidad madura de los modelos u otros frameworks para mejorar sus procesos de desarrollo de software.

Desarrollo de Arquitecturas

Otro camino para tratar con el incremento en la complejidad es crear una arquitectura de software. Una arquitectura de software provee de la estructura técnica para un proyecto. Una buena arquitectura hace que el resto del trabajo sea más fácil, pero una mala arquitectura hacer que el resto del trabajo sea casi imposible.

En la creación de arquitecturas se tiene que tratar con las demandas conflictivas. La arquitectura desempeña requerimientos funcionales y no funcionales. Ejemplos de requerimientos no funcionales son:

· Portabilidad

· Mantención

· Flexibilidad

· Extensibilidad

· Reusabilidad

Estos requerimientos no-funcionales son también conocidos como Soft Intents. En algunas áreas de aplicación un grafico de softgoal interdependencia es usado para visualizar estos conflictos. La mayoría de las soluciones son ajustadas a la "medida" entre estas demandas conflictivas. Difícilmente incluso todas estas demandas son completadas.

TRIZ podría ser muy útil en resolver estas peticiones conflictivas (Contradicciones) en una manera más satisfactoria. Desde que las arquitecturas son también usadas en otros campos como ing. Mecánica nosotros podemos aprender desde la aplicación de TRIZ en este campo.

Modas de una evolución tecnológica

Debido a que rápidamente se incrementan las capacidades del software es difícil decir cómo serán estos en el futuro. Es difícil imaginar que es posible en el futuro y que será exitoso.

Triz se enfoca en la evolución tecnológica y esto podría ser usado para identificar las posibilidades de futuro. Combinado con modas comerciales, esto ayuda en definir productos exitosos en una temprana edad.

Triz para el Software

La utilización de los ordenadores como instrumentos de ayuda a las diferentes actividades humanas ha cobrado tal importancia que hoy resulta casi inconcebible subsistir en un mundo tan competitivo sin su uso. Se puede decir que su aplicación ha cubierto todas las esferas de la actividad humana, siendo previsible que el uso de ordenadores vaya en aumento cada vez más.

Estos datos son suficiente argumento para sostener la importancia que tiene la investigación sobre el mejor uso de tales instrumentos mediante la elaboración de aplicaciones para estas.

Puede TRIZ ser aplicado para el diseño y creación de software? parece ser una cuestión que se plantea por un número cada vez mayor de empresas. Se propone en este documento indagar sobre el terreno y hacer sugerencias en cuanto a lo que un "TRIZ de Software” puede hacer.

Teniendo en cuenta los distintos autores (Darrel Mann, entre otros) al respecto, parece probable suponer que la sugerencia será, sí, TRIZ puede ser aplicado a software. No obstante a habida cuenta de algunos debates de TRIZ y software, parece que la respuesta positiva no es tan evidente.

Uno de los autores (Ikovenko[1]) habla en torno a este tema en el TRIZ Centrum conferencia en 2003 y llegó a la conclusión de que, básicamente, desde el desarrollo de software se encuentra aún en una etapa temprana de su evolución, en otras palabras, que el desarrollo de software es un arte y no una ciencia en si. Por lo que no era todavía probable que se prestara para al tratamiento de TRIZ, ya que no era considerado una ciencia como tal.

Mas franco aún fue Karasik[2], fue más vehemente en su despido de las posibilidades de aplicar TRIZ para problemas de software, “siendo un equipo un científico y un ingeniero un software” los 40 principios no serán aplicables a ingeniería de software bajo ninguna circunstancia.

El trigger para Karasik para incurrir en tal afirmación de primer orden fue la investigación

Publicada acerca de la lista de los 40 Principios de Inventiva para Software de Rea[3].haciendo una analogía de la situación es que los 40 Principios de Inventiva - o la mayoría de ellos por lo menos - se puede observar en el diseño de software, considerada absurda para el.

Sobre la base anterior de experiencias y el extenso análisis de las patentes realizadas durante el programa de investigación para la actualización de TRIZ, es nuestra firme convicción de que tiene TRIZ algo de importancia para ofrecer a ingenieros de software.

Sin embargo a diferencia de las materias ciencias duras: mecanica, hidráulica, etc. lo que ya podemos ver es que el sesgo y la orientación de las distintas herramientas de TRIZ es muy diferente a la de software que en otros campos de aplicación. Por lo que el autor (Darrel mann) con el fin de explorar los prejuicios que, sin embargo, en primer lugar hay que estudiar el contexto y los límites de lo que es y lo que no es un problema 'software'. Una buena forma de comenzar esta exploración, según Mann, entonces, es mediante la Ley de Sistema de Integridad TRIZ[4] (modificada) y ver cómo esto podría ser aplicado a sistemas informáticos. Es decir si un problema de software puede ser situado bajo esta perspectiva, así como las demás áreas lo han hecho, estos últimos no tendrían ningún impedimento para ser aplicado a través de TRIZ.

Imagen 1 - Imagen de referencia

La primera pregunta que surge después de pensar en este modelo, es aplicable a software? La respuesta es sí, podemos aplicar recursivamente el modelo en varios niveles jerárquicos .En el nivel del software subrutina, por ejemplo, podríamos pensar en el 'motor' como los algoritmos que figuran en la rutina, la transmisión como la llamada a la subrutina, la herramienta como los resultados calculados por la rutina y el control, las diferentes líneas de código en el software que asegurarse de que las cosas sucedan en la secuencia correcta y con la lógica deseada. El ‘campo (interface)' es un poco más grande, pero si pensamos en él como un "campo de la comunicación” la lógica sigue intacta. La misma analogía se puede aplicar en forma progresiva a los niveles jerárquicos más altos en que nos fijamos en los sistemas desde la perspectiva del sistema operativo, idioma, etc. Ya sea cualquier nivel que veamos, en última instancia el "sistema" tiene que interactuar con algo fuera de la sistema (‘campo (interface)'). Siendo esto cosa fuera del sistema ser otra rutina de programa o el usuario mismo.

Problemas de Software

Los 'Problemas de Software' quizás a diferencia de los sistemas o ciencias convencionales es que sólo empezarán a ocurrir cuando se examinan los vínculos entre el software y el mundo exterior. Por lo tanto la única práctica, entonces, cuando nos encontramos en la identificación de modelos funcionales que contienen relaciones negativas es cuando llegamos a la interfaz con el mundo exterior. Ya que un fragmento de código no interacciona «Inadecuadamente» con otro, pero un pedazo de código muy a menudo interactúa inadecuadamente con una pieza de hardware o con un usuario.

Es probable que esto significa que vamos a estar pensando en como TRIZ como herramienta en la resolución de problemas, en un instrumento algo a un diferente nivel de detalle en el punto de inicio de un modelo de análisis de la función.

Triz para Software

Bajo los aspectos mencionados anteriormente, Darrell Mann, lo obtuvo. Bajo los mismos procedimientos y analogías efectuadas a los 40 principios de TRIZ es posible resolver un problema de software mediante TRIZ.

De esta manera a continuación se expondrá las ideas y procedimientos para efectuar tal resultado.

Darrel Mann propone la siguiente estructura, de desarrollo y análisis del problema.

Definición:

1. Resultado Ideal Final.

2. Explorar el problema.

3. Subversión análisis.

4. Matriz de contradicciones.

Generación de Solución:

1. Principios Inventivos.

2. Tendencias/Evolución Potencial.

Nota: Si bien la estructura anterior de procedimiento fue propuesta por Mann puede ser aplicada bajo cualquier ciencia; solo la matriz y los principios inventivos conforman obra de Mann y su utilización es única para “Problemas de Software”.

Definición

Para esta primera aproximación Mann, baso su propuesta bajo dos perspectivas esenciales, en primer lugar bajo la utilización de siete pilares de exploración del problema y en segundo lugar las contradicciones en relación con los factores y/o parámetros que la conforman.

Siete Pilares de “TRIZ para Software”

Esta aproximación responde a las características y entendimiento del problema en cuestión. Es decir apoya a situarse en el problema y observar las características de este último, de manera que al momento de encontrar una solución a través de los principios inventivos por medio de la matriz de contradicciones resulte la más apropiada.

• Idealidad: atenta a encontrar cada vez mayor acerca de lo bueno, la disminución de lo malo.(“Si mismo”,autorepararse,autodaptarse,etc)

· Emergente: producir un a solución o atentar o situación relevante en el contexto de la situación del problema.

• Funcional: en el contexto de un software, esta existe para el software proporcionar una función útil, ya sea a otras piezas de software o de una pieza de hardware o un ser humano indep. del producto como tal.
• Contradicción: La contradicción de la eliminación de estrategias se puede utilizar para acelerar la evolución de cualquier sistema. Las contradicciones tienden a ocurrir en las interfaces entre software y el mundo exterior en su totalidad mas que en lugar de «dentro» del software.
• Recursos: Todo dentro y alrededor de un sistema que no se utiliza al máximo de su potencial es un recurso.
• Espacio/Tiempo/Interface: la comprensión efectiva de un problema requiere conocimiento de cómo un sistema se ve afectado por efectos espaciales, temporales y cuestiones interfaciales.
• Recursion: se refiere al fenómeno según el cual ciertos fenómenos de sistema se repiten en los diferentes niveles jerárquicos.

Subversión Análisis

Atenta a generar los errores que pudiera tener el sistema y de esta manera “Si el fallo ocurre, entonces los recursos necesarios para hacerlo suceder deben estar presentes en el sistema”

Por lo que Subversión es el análisis sobre la búsqueda de esos recursos, se trata de «inventar fracaso";¿Qué podría ir mal, irá mal, ¿Qué podría ir mal en el futuro, va a salir mal. Para así dar paso a las contradicciones y resolver el problema en cuestión.

1. Identificar el Problema- donde y cuando.
2. Amplificar el problema.(como hacer que ocurra todo el tiempo)
3. Formula el problema invertido.
4. Identificar los componentes necesarios.
5. Identificar los recursos en el sistema.

Matriz de Contradicciones

El clásico TRIZ Contradicción Matrix ha sido objeto de actualizaciones muchas veces en los últimos tiempos, primero a través de la publicación de “Matrix 2003[5]” (para negocios) y, a continuación, más recientemente, un matriz de problemas empresariales. A pesar de pasar por varios pasos hacia
lo que es relevante para los problemas que enfrentan los ingenieros de software y la búsqueda de muchas las patentes de software que había algo que aportar a la construcción de la herramienta, Matrix 2003 contiene mucho de lo que se consideró fuera de poner a los usuarios de software. De ahí que en 2003 se decidió que era necesario crear una matriz a medida para problemas de software. Esto matriz ya se ha concluido, y se convertido a disposición del público por primera vez cuando el libro "TRIZ para ingenieros de software" se público.

La tabla de continuación ilustra los parámetros que componen las partes de la nueva Matriz.

Size (Static)

Size (Dynamic)

Amount of Data

Interface

Speed

Accuracy

Stability

Ability to Detect/Measure

Loss of Time

Loss of Data

Harmful Effects Generated By System

Adaptability/Versatility

Compatibility/Connectability

Ease Of Use

Reliability/Robustness

Security

Aesthetics/Appearance

Harmful Effects On System

System Complexity

Control Complexity

Automation

Parámetros de la nueva, Software Matrix

El método de funcionamiento de la nueva Matriz es exactamente el mismo que el utilizado en las demás Matrices; el usuario tiene que identificar lo que ellos desean mejorar en su sistema, entonces que es lo que les impide hacer la mejora. Desde aquí es necesario entonces traducir los detalles del conflicto (el par mejora y empeoramiento) de la Matriz de la lista de parámetros con mi problema que corresponde mas estrechamente con los detalles. A partir de ahí, la matriz apreciara los más probable principios de inventiva utilizados por otros para solucionar el desafío con éxito del par conflictos.

Esta nueva Matriz es el resultado del estudio de alrededor de 40000 patentes de software y el diseño soluciones. No obstante el número está limitado por el hecho de que actualmente sólo los EE.UU. es la concesión de software las patentes.

Un ejemplo sencillo, sin embargo, ha de servir al doble propósito de demostrar cómo la matriz fue compilada (patentes) y cómo un usuario puede hacer uso de la herramienta.

US6, 785.819

Esta patente se concedió a Mitsubishi Denki Kabushki Kaisha el 31 de agosto de 2004 (en realidad algún tiempo después de la Matriz de trabajo se completó). Los antecedentes de la patente como descrito en la divulgación es el siguiente (extracto):

“Recientemente, los sistemas informático que utiliza LAN se están adoptando en las organizaciones. Comúnmente, una pluralidad de LAN ubicadas en diversos lugares en una organización de la red entre oficinas están conectadas por completo para formar una intranet. La extensión de más, una extranet que incluye la organización aliada a las empresas a formar una red total también se está convirtiendo en generalizada. Hay varias formas de conectar una pluralidad de LAN ubicadas en diversos lugares. Para dar un ejemplo, hay un caso de utilizar a bajo costo a Internet en lugar de una línea arrendada. En este caso, el acceso desde el exterior debe ser regulado, por lo que un servidor de seguridad general, se recurre a una frontera de fuera y dentro de la red. Esto ayuda a aumentar el factor de seguridad dentro de la LAN. El firewall es una técnica que sólo permite el acceso desde el exterior a una ubicación específica o para una aplicación específica de la LAN………. En un sistema de red informática, los servicios bajo un entorno LAN como el uso compartido de archivos, impresión a la impresora común, o el uso de la CPU del servidor no puede ser aprobado debido al firewall. En consecuencia, en los casos en que se desea obtener un ciertos datos o un programa a partir de otros ubicación, a continuación, uno sólo puede confiar en alguien en el otro lugar para datos requeridos utilizando un canal independiente, o sólo puede basarse en un método de envío de medios de comunicación como una cinta “.

El problema de este modo identificados por los inventores es un conflicto entre los deseos paralelo a mejorar la capacidad de transferencia de datos y mantener la seguridad.

Traduciendo estos requisitos en los términos de la Matriz de Software, se pone en manifiesto el conflicto en la pareja ilustrada a continuación:

US6, 785,819 conflicto traducido en términos de, The Software Matriz.

Los inventores de la patenten ocuparon un Agente de software para lograr la solución.(en la figura se puede apreciar a través del principio 24,que es Intermediario, por lo que ahora cualquier problema de esta índole concurre a esta patente de Agentes).

Generación de Solución

La primera cosa que decir sobre el tema de los principios de inventiva es que el autor (Darrel Mann) confirmó la existencia de los mismos 40 principios como los que se encuentran en el TRIZ clásico. Como se dio en el caso con la técnica de conversión a los principios de gestión, se tuvieron que modificar algunos de los términos del principio para que las descripciones se adaptaran de mejor manera al contexto de software, pero más allá de eso, se han mantenido las mismas.

Esto último se apoya ya que no ha habido a la fecha ingenieros de software que hayan identificado estrategias de inventiva que no encajen en los principios existentes. La lista de principios que presenta la modificación de los títulos se ilustra a continuación:

1. Segmentation 2. Extraction 3. Local Quality 4. Asymmetry 5. Combination 6. Universality 7. ‘Nested Doll’ 8. Counterbalance 9. Prior Counter-Action 10. Prior Action 11. Prior Cushioning 12. Remove Tension 13. ‘The Other Way Round’ 14. Loop 15. Dynamics 16. Slightly Less/Slightly More 17. Another Dimension 18. Vibration 19. Periodic Action 20. Continuity of Useful Action 21. Hurrying 22. ‘Blessing in Disguise’ 23. Feedback 24. Intermediary

25. Self-Service 26. Copying 27. Cheap/Short Living 28. Another Sense 29. Fluidity 30. Thin & Flexible 31. Holes 32. Colour Changes 33. Homogeneity 34. Discarding and Recovering 35. Parameter Changes 36. Paradigm Shift 37. Relative Change 38. Enrich 39. Calm 40. Composite Structures

40 Principios de Inventiva.

También conviene señalar a este respecto es el hallazgo adicional de la investigación hecha por Mann, que la mayoría de los problema de software las soluciones parecen fusionar las ideas de varios principios.

Para efectos prácticos de ejemplificación se muestran solo algunos principios respecto a su analogía clásica hacia la de software. (no obstante se anexan al final en un tabla todos los principios con su descripción de inglés)

1. Segmentation

Software Analogy: Dividir un sistema en componentes autónomos.

5. Combination

Software Analogy: Hacer ejecutar procesos en paralelo.

7. Nesting (Matrioshka)

Software Analogy: Heredar la funcionalidad de otros objetos de sus respectivas clases dentro de una clase base.

18.Vibration

Software Analogy: cambiar el ritmo de ejecución de un algoritmo en el contexto de tiempo, hasta lograr. el resultado deseado.

Secuencia de uso (frecuencia) de los Principios de Inventiva

El análisis aquí descrito se basa en los mismos 40000 soluciones de software utilizado para compilar la Matriz de software. El método de presentar nuestras conclusiones es exactamente el mismo que recientemente se ha utilizado para la actualización de la matriz técnica y de. El software Principio de frecuencia de secuencia, es el siguiente:

Secuencia de frecuencia de los 40 Principios de Inventiva.

En comparación con la matriz clásica de triz, es la siguiente (por efectos de procesador de textos, la tabla quedo en la página siguiente):

La columna cambio (change) indica que se han producido algunos cambios muy importantes que han tenido lugar entre la matriz clásica y la nueva matriz de software. En menor medida también ha habido algunos cambios en. Los mayores subidas en la lista la oferta muestran de manera más interesante las diferencias entre estrategias de resolución de conflictos de software y problemas técnicos:

Las subidas de los Principios 37 ( «Cambio relativo" en nuestra aplicación de software) y 7 ( 'Muñeca Rusa ') son más indicativos de la facilidad con que estas dos estrategias pueden ser desplegadas en un contexto de software. Agrupamiento (Muñeca rusa) en particular, puede ser algo que añade una considerable complejidad en un sistema físico, pero en una pieza de software el uso de esta estrategia se limita solamente a exigir la creación de nuevas líneas de código. El aumento del principio “Cambio relativo” es también debido a la facilidad con que este estrategia puede ser desplegado en un entorno digital.

En cuanto a los Principios que caen en la lista, parece claro que hay algunos de los Principios que son más difíciles de interpretar en el contexto de software. Por ejemplo el Principio 18 («vibraciones»), 30 (”Flexible y delgado”), 31 ('Holes') y 36 («la fase de transición»). Si bien todos los ejemplos de software de estos principios pueden ser encontrados, su existencia es poco frecuente y, a veces, la imaginación necesaria es muy alta. El análisis detallado de la secuencia de prioridad se ilustra en mostrada anteriormente, de hecho, muestran que hay una gran diferencia en la frecuencia del uso de los 16 principales principios en comparación con el 24 inferiores.

Comparación entre la matriz de Software y la Clásica.

Idealidad y Tendencias

Pasando de contradicciones, otro instrumento importante en el contexto del software parece ser La Idealidad y las Tendencias parte de TRIZ.

Una gran parte de la investigación subyacente para TRIZ-Software de ha examinado los patrones que existen en la evolución del software como los sistemas de salto discontinua de una manera de hacer las cosas a otro. Esto se debe a que esperamos que el conocimiento de esas tendencias nos permitirá acelerar considerablemente la evolución de las actuales sistemas de la misma manera que está empezando a suceder con los sistemas técnicos que estamos participando.

Si bien este punto escapa al desarrollo de la investigación, nos pareció interesante mencionarlo ya que forma de una herramienta de gran apoyo para triz, especialmente para problemas de software. Ya que permite observar las tendencias a futuro de en un área tan volátil como la informática que permanece en constante evolución. De esta manera al momento de utilizar los principios observaremos nuestra tendencia de acuerdo a nuestra solución propuesta.

Radar de Comparación, Actual y Potencial de Tendencias.

Diseñando Patrones de Software con Triz

Triz como ya mencionamos anteriormente, aparte de ser ocupado para la física, química, y otras ciencias, también puede ser aplicado a los procesos de negocios y a los procesos de software. Es así como el análisis de Triz y los patrones de diseño, visualizamos ciertas analogías que pueden ser estructuradas para mejorar y ayudar a los ingenieros de software.

Para entrar en contexto un patrón de diseño es:

• una solución estándar para un problema común de programación

• una técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios

• un proyecto o estructura de implementación que logra una finalidad determinada

• un lenguaje de programación de alto nivel

• una manera más práctica de describir ciertos aspectos de la organización de un programa

• Conexiones entre componentes de programas

• La forma de un diagrama de objeto o de un modelo de objeto.

Así describiremos un subconjunto de los 23 patrones de diseño que fueron desarrollados por los Gang of Four [1] como instancias de los principios de resolución de problemas encontrados por la teoría TRIZ de Genrich Altshuller´s. Nosotros podemos ver en un análisis temprano, las similaridades entre los patrones de diseño y Triz, esto es que ambos sistemas son un conjunto de heurísticas, derivados desde observaciones de soluciones exitosas para problemas comunes.

Luego de un profundo análisis, nosotros podemos encontrar fuertes links entre los patrones estructurales del grupo de los Gang of Four y un conjunto especifico de principios de TRIZ.

Contradicciones Espacio-Tiempo

Los científicos de la computación tienen dos bien conocidas fuerzas que son el espacio y el tiempo (dos características de los sistemas). Así el problema general es que tal como la característica del sistema del tiempo decrece (se mejora), la característica del sistema de espacio se incrementa (se empeora). En cambio, tal como la característica del sistema del espacio decrece (mejora), la característica del sistema de tiempo decrece (se empeora).

Un ejemplo ilustrativo de contradicciones de espacio-tiempo:

Se encuentra un problema con las bases de datos que mientras más información ellos guardan, más lento el sistema se pone.

Sin embargo, mientras más información ellos tienen, más comúnmente podemos encontrar la información que nosotros queremos, debido a una pregunta realizada.

Si identificamos en la matriz de contradicciones de 39x 39 TRIZ sería lo siguiente:

Problemas	Principios de Triz
"el acceso a mas respuestas e información"	Volumen de un objeto estático (Característica del sistema 8)
"incremento de tiempo necesario para encontrar una respuesta"	Tiempo de acción de un objeto estacionario ( Característica del sistema 16)

La intersección de tiempo de acción de un objeto estacionario a lo largo del eje horizontal (se empeora) y volumen de un objeto estático (se mejora) nos indica 3 potenciales soluciones desde los 40 principios:

· 35 - Transformación de Propiedades

· 34 - Rechazo y regeneración de las partes

· 38 - Oxidación acelerada.

El principio 34 incluye: " Después de completar esta función o llegar a ser útil, un elemento del objeto es rechazado (descartado, disuelto, evaporado, etc.) o modificado durante el proceso de trabajo". Esta descripción contiene la esencia de la definición de CACHE, el cual es una solución común a un problema inicial con base de datos.

Examinando el problema general de mas y mas tiempo (empeora) tomando un orden a través de una sobre-abundancia de información (se mejora), la solución de TRIZ encuentra muy bien descrito en el principio 34 la idea de un FAQ, o una lista de Preguntas frecuentemente hechas - otro ejemplo de un CACHE.

Diseño de Patrones y TRIZ

1. Adapter Pattern y el principio Mediador (Mediator Principle)

El patrón adaptador, como su propio nombre nos puede hacer ver, se usa para convertir el interface de una clase a la de otra, entendiendo en este caso interface como el conjunto de métodos que ofrece una clase para su manipulación por código, no la herramienta que usa el usuario final de nuestra aplicación. Lo que haremos será escribir métodos con nuestra interface deseada que deleguen el trabajo en los de la interface ya existente.

Las razones para querer hacer algo así pueden ser de muy distinta naturaleza, y pueden ir desde:

Querer integrar una clase ya existente pero que no podemos modificar en una nueva jerarquía de clases, que por ejemplo implemente una nueva interfaz, podemos querer limitar el interface de una clase.

Querer hacerlo simplemente porque la convención de nombres usada en la clase original, que tampoco podemos o queremos cambiar, no se ajusta a la nuestra.

§ Esta última razón puede parecer un poco absurda pero puede ser bastante frustrante recibir miles de errores de compilación por trabajar con métodos del estilo GetName en lugar de getName.

o Esta adaptación se puede hacer de dos formas :

Adaptación por herencia

Adaptación por composición.

1.3 Adaptación por herencia

Aquí haremos que la clase que implementa la nueva interface extienda de la original y añadiremos a esta los métodos que consideremos oportunos.

Por ejemplo:

public class Usuario{ protected String nombre; protected String password; . . . public Usuario (String nombre, String password){ . . . } public String GetNombre (){ return nombre; } public String GetPassword (){ return password; } . . . }

Según las convenciones de programación, nos damos cuenta de que esas dos G de Getxxx darán muchos problemas. Entonces suponiendo que esta clase ya esta en sistemas productivos y por tanto no podemos hacer algo tan simple como cambiar esa letra, optamos por extender esa clase, de forma que el sistema siga trabajando correctamente con las clases antiguas, para así evitarnos errores de compilación innecesarios.

public class BuenUsuario extends Usuario{ public BuenUsuario (String nombre, String password){ super (nombre, password); } public String getNombre (){ return GetNombre(); } public String getPassword (){ return GetPassword(); } }

Al hacerlo así, nos aprovechamos aparte de las ventajas de la herencia, haciendo que los métodos de otras clases que usen la clase usuario puedan seguir funcionando sin retocarlos.

1.2 Adaptación por Composición

Esta ocurre en algunos casos donde no podemos usar la herencia, ya sea porque queremos integrar esa clase en una jerarquía nueva y ya estemos heredando de otra clase, o ya sea por causa de modificadores de acceso como private o final que impidan que se hereden algunas características de la clase, o simplemente que no queramos que la nueva clase tenga el interface completo de la original. En ese caso tendremos que usar la composición, es decir, incluir la clase a adaptar como un atributo de la adaptadora.

2. Composite and Iterator Pattern y el principio de Universalidad (Universality Principle)

Como desarrollador se tienen variadas listas para utilizar. Cada una de éstas pueden estar y lo más probable es que así sea, en distintos formatos. Es útil para crear una interfaz a través de la cual los objetos en las diferentes listas puedan sea accesados. Una segunda interfaz es creada para moverse a través de las listas (en el formato entregado por la interfaz de la lista). Esta interfaz, a través de la cual los objetos de la lista son accesados, es llama iterator (iterador). La representación (implementación) de la lista no es de ninguna consecuencia, el retorno de la siguiente lista de objetos de importancia primaria.

PRINCIPIO 6 - UNIVERSALIDAD

Promueve uniformidad de función, uso uniforme de un objeto para distintos propósitos, o la aplicación de los mismos requerimientos o características para distintos objetos, situaciones o acciones.

3. Decorator Pattern y los principios de Agrupamiento y/o Membranas Flexibles

El decorator pattern dinámicamente agrega funcionalidad a un objeto. Usando éste patrón, es una forma de evitar crear subclases (clases hijas) para proveer funcionalidad extendida. Este patrón comienza con una superclase de un componente particular, C. El objeto actual que vamos a “decorar”, es una subclase de C, el que llamaremos c. El objeto decorador, d, en realidad referencia valores en c. Una subclase del decorador en realidad crea la funcionalidad adicional provista por la clase decorador.

PRINCIPIO 7 – AGRUPAMIENTO

Aplica cuando un objeto cabe dentro o pasa a través de otro.

PRINCIPIO 30 – MEMBRANAS FLEXIBLES

Receta el reemplazo de las construcciones tradicionales con construcciones de peliculas delgadas o membrana flexibles. Además, un objeto puede ser aislado de su ambiente con una película delgada.

4. Facade Pattern y el principio de la consolidación

Dada una colección de interfaces, un cliente (usuario) debería sólo tener que tratar con un sistema de interfaz unificada cuando trata de acceder a los datos. La interfaz de mayor nivel es el llamado patrón fachada. Es una implementación directa de la Ley de Remeter, la que encapsula el principio de mínimo conocimiento (“los amigos solo hablando con amigos”).

PRINCIPIO 5 – CONSOLIDACION

Entrega funciones o partes de un sistema a una relación que crea nuevos resultados. Un ejemplo es combinar la habilidad para reproductor de reproducir múltiples formatos (DVD, mp3, etc).

5. Flyweight Pattern y el principio de transición hacia una nueva dimensión

Existen momentos en los que uno necesita tener, literalmente, miles de instancias de un objeto. Cada objeto es relativamente simple, usualmente llamando a unos pocos métodos. Un ejemplo de esto, podría ser un procesador de palabras basado en web que talvez tiene 2560 lugares para poder ubicar caracteres. Caracteres cualquiera pueden aparecer o desaparecer (dos métodos). El patrón flyweight entrega un administrador para organizar cada uno de los pequeños objetos (configurando los caracteres en 80 por columna y 32 por fila por cada página). Los objetos carácter son responsables de su propia administración. (Mostrando o no una letra, número, símbolo o estando en blanco).

PRINCIPIO 17 – TRANCISION HACIA UNA NUEVA DIMENSION

Sugiere cambiar la orientación de un sistema agregando una dimensión. Esta nueva dimensión puede poner menor tensión en una dimensión ya existente, o puede agregar una dimensión de control.

6. Proxy Patterm y los principios de Cambio de parámetro y/o transición de fase

El patrón Proxy es usado para controlar el acceso a un objeto. Como ejemplo, hay momentos en lo que un usuario querrá solicitar que una imagen sea mostrada. Si el tamaño de ésta es un poco grande, entonces debería tomar un tiempo no mínimo en aparecer (quizás una animación flash). Prácticas de buena usabilidad recomendarían que un pequeño cartel animado que diga “Cargando” aparezca mientras se carga en memoria para reproducirse un gran archivo flash. Introduzca el patrón comentado para poder realizar esto, poner un cartel de “cargando” mientras la imagen está lista para ser mostrada, y luego mostrarla.

PRINCIPIO 35 – CAMBIOS DE PARAMETRO

Sugiere cambiar el estado físico de un objeto (de gas a líquido por ejemplo). Cambiar la concentración o consistencia. Cambiar el grado de flexibilidad. Cambiar la temperatura.

PRINCIPIO 36 – TRANSICION DE FASE

Sugiere usar el fenómeno que ocurre durante el cambio de fase (cambio de volumen, ganancia o pérdida de calor)

Ejemplos de Patrones

Proxy pattern

Se desea guardar una lista de usuarios registrados, pero no sé exactamente donde. La idea es que dependiendo del valor de un checkbox ( en el que el usuario elige si está conectado a internet o no ), debo mandar los datos a servidor ( en formato XML ) o guardarlos en disco en un Shared Object

Esta es una misión para el Patrón Proxy, debido a que se quiere aislar el proceso de guardar los datos del resto del programa, simplemente hacerlo y olvidarse de cómo o dónde se guarda.

Eso es lo que hace este patrón. El proxy guarda una referencia a un objeto, que es quien realmente se encargará de ejecutar la acción. Pero es el proxy el que crea ese objeto, por lo que puede crear una instancia de una u otra clase dependiendo de ciertas condiciones en tiempo de ejecución

Por tanto, todas las clases que puedan ser instanciadas por el proxy, deben implementar el mismo interfaz. Y dependiendo del tipo de proxy, puede ser una buena idea que incluso él mismo implemente ese interfaz, para que se pueda eliminar si es necesario.

Decorator Pattern

Supongamos que tenemos una clase existente Ventana y queremos añadirle funcionalidad para que muestre un borde alrededor. Podemos crear una subclase VentanaConBorde que herede de Ventana.

Hasta aquí todo bien, pero supongamos que surge la necesidad de crear una ventana que muestre un pequeño botón de ayuda con un signo de interrogación (?) en su parte superior. Entonces tenemos las siguientes opciones:

· Crear otra subclase de Ventana: VentanaConBotónDeAyuda.

Problema: No cubre la necesidad de tener ventanas con bordes y botón de ayuda a la vez.

· Crear una subclase de VentanaConBorde: VentanaConBordeYBotonDeAyuda.

Problema: No tenemos una ventana con botón de ayuda y sin borde.

· Crear clases para todas las combinaciones posibles de funcionalidades.

Problema: Con este ejemplo tendríamos cuatro clases: Ventana, VentanaConBorde, VentanaConBotonDeAyuda y VentanaConBordeYBotonDeAyuda; con tres funcionalidades tendríamos ocho clases y con cuatro, ¡dieciséis!

El patrón Decorator soluciona este problema de una manera mucho más sencilla y extensible. Se crea a partir de Ventana la subclase abstracta VentanaDecorator y, heredando de ella, BordeDecorator y BotonDeAyudaDecorator. VentanaDecorator encapsula el comportamiento de Ventana y utiliza composición recursiva para que sea posible añadir tantas "capas" de Decorators como se desee. Podemos crear tantos Decorators como queramos heredando de VentanaDecorator.

Flyweight Pattern

Crear una clase PelotaFlyweight, que contendrá la información común (radio y color) y otra clase PelotaConcreta, que contendrá las coordenadas concretas de cada pelota y una referencia a un objeto de tipo PelotaFlyweight.

Al crearse instancias de PelotaConcreta, se les deberá proveer de referencias a la instancia de PelotaFlyweight adecuada a nuestras necesidades.

En este caso solamente tendríamos una instancia de PelotaFlyweight, puesto que hemos dicho que todas nuestras pelotas tienen el mismo radio y color, pero pensando en un ejemplo en el que tuviéramos varios grupos de pelotas, y dentro de cada uno de los cuales se compartieran el radio y el color, se puede utilizar Flyweight conjuntamente con el patrón Factory, de tal modo que este último, en el momento en que se le soliciten instancias de PelotaConcreta con determinadas características (mismo radio y color que el solicitado), compruebe si ya existe un PelotaFlyweight con ese radio y color, y devuelva esa referencia o, en caso de que no exista, la cree y la registre.

Facade Pattern

class UserfriendlyDate {     GregorianCalendar gcal;     public UserfriendlyDate(String isodate_ymd) {         String[] a = isodate_ymd.split("-");         gcal = new GregorianCalendar(Integer.valueOf(a[0]).intValue(),               Integer.valueOf(a[1]).intValue()-1 /* !!! */, Integer.valueOf(a[2]).intValue());     }     public void addDays(int days) { gcal.add(Calendar.DAY_OF_MONTH, days); }     public String toString() { return new Formatter().format("%1$tY-%1$tm-%1$td", gcal).toString();} } /** Cliente */ class FacadePattern {     public static void main(String[] args)     {          UserfriendlyDate d = new UserfriendlyDate("1980-08-20");           System.out.println("Date: "+d);           d.addDays(20);           System.out.println("20 days after: "+d);     } }

Bridge Pattern

public class Abstraccion

{

        private Implementador implementador;

        public void setImplementador(Implementador implementador)

        {

                this.implementador = implementador;

        }

        public Implementador getImplementador()

        {

                return implementador;

        }

        public void operacion()

        {

                implementador.operacion();

        }

}

public class AbstraccionRefinada extends Abstraccion

{

        public void operacion()

        {

                super.operacion();

        }

}

public interface Implementador

{

        public abstract void operacion();

}

public class ImplementacionA implements Implementador

{

        public void operacion()

        {

                System.out.println("implementacion A");

        }

}

public class ImplementacionB implements Implementador

{

        public void operacion()

        {

                System.out.println("implementacion B");

        }

}

public class PruebaBridge

{

        public static void main(String arg[])

        {

                Abstraccion abstraction = new AbstraccionRefinada();

                abstraction.setImplementador(new ImplementacionA());

                abstraction.operacion();

Composite Pattern

Imaginemos que necesitamos crear una serie de clases para guardar información acerca de una serie de figuras que serán círculos, cuadrados y triángulos. Además necesitamos poder tratar también grupos de imágenes porque nuestro programa permite seleccionar varias de estas figuras a la vez para moverlas por la pantalla.

En principio tenemos las clases Círculo, Cuadrado y Triángulo, que heredarán de una clase padre que podríamos llamar Figura e implementarán todas la operación pintar(). En cuanto a los grupos de Figuras podríamos caer en la tentación de crear una clase particular separada de las anteriores llamada GrupoDeImágenes, también con un método pintar().

Problema.

Esta idea de separar en clases privadas componentes (figuras) y contenedores (grupos) tiene el problema de que, para cada uno de los dos atributos, el método pintar() tendrá una implementación diferente, aumentando la complejidad del sistema.

El patrón composite da una solución elegante a este problema, de la que además resulta en una implementación más sencilla.

A la clase Figura la llamaríamos Gráfico y de ella extenderían tanto Círculo, Cuadrado y Triángulo, como GrupoDeImágenes. Además, ésta última tendría una relación todo-parte de multiplicidad * con Gráfico: un GrupoDeImágenes contendría varios Gráficos, ya fuesen éstos Cuadrados, Triángulos, u otras clases GrupoDeImágenes.

Así, es posible definir a un grupo de imágenes recursivamente. Por ejemplo, un objeto cuya clase es GrupoDeImágenes podría contener un Cuadrado, un Triángulo y otro GrupoDeImágenes, este grupo de imágenes podría contener un Círculo y un Cuadrado. Posteriormente, a este último grupo se le podría añadir otro GrupoDeImágenes, generando una estructura de composición recursiva en árbol, por medio de muy poca codificación y un diagrama sencillo y claro.

Adapter Pattern

El patrón adaptador, como su propio nombre nos puede hacer ver, se usa para convertir el interface de una clase a la de otra.

Implementación:

En otras palabras, un adaptador es típicamente implementado utilizando herencia múltiple, al crear una subclase del adaptador que herede los métodos privados y, permitiendo que herede además, la interfaz pública de las clases que definen la interfaz requerida.

Conclusiones

Se ha demostrado con este informe que la mayoría de las patentes de software y la implementación de nuevos principios pueden ayudar a formar una nueva matriz y generar la base para una nueva investigación para una Matriz totalmente limpia solo para software. Es así como el autor Darell Mann ha introducido una investigación importante respecto a este tema, por lo que un próximo trabajo estaría en crear y formar Triz para el software implementando nuevas matrices y generando nuevas soluciones con patentes de software innovadoras.

Referencias

• http://www.systematic-innovation.com

• Ikovenko, S., ‘Laws Of Engineering System Evolution In Software Development’,keynote paper at TRIZ Centrum, 3rd European TRIZ-Conference, ETH Zurich, March 2003.



• Karasik, Y., editorial comment, Anti-TRIZ Journal, Vol.2, No.2, and private email correspondence, 8 September 2004.



• [Kev-01] Rea, K., ‘TRIZ and Software - 40 Principle Analogies, Partes 1 and 2’, TRIZ Journal, Septiembre y Noviembre 2001.



• Mann, D.L., ‘Hands-On Systematic Innovation’, CREAX Press, June 2002.



• Espejo, R., Harnden, R., ‘The Viable System Model’, John Wiley & Sons, New York, 1989.



• Mann, D.L., ‘Hands-On Systematic Innovation For Business & Management’, IFR Press, August 2004.



• Mann, D.L., ‘TRIZ For Software Engineers’, IFR Press, October 2004.



• Mann, D.L., Dewulf, S., Zlotin, B., Zusman, A., ‘Matrix 2003: Updating The TRIZ Contradiction Matrix’, CREAX Press, Belgium, July 2003.



• Mann, D.L., ‘Comparing The Classical And New Contradiction Matrix, Part 2 – Zooming In’, TRIZ Journal, July 2004.



• Paulk, M.C., Weber, C.V., Garcia, S.M., Chrissis, M.B., Bush, M., ‘Key Practices Of The Software Maturity Model’, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania.



• Mann, D.L., Dewulf, S., ‘Evolutionary Potential In Technical And Business Systems’, TRIZ Journal, June 2002.



• Mann, D.L., ‘Ideality And Self-X’, paper presented at 1st ETRIA TRIZ Future Conference, Bath, November 2001.



• Rea, K., ‘Applying TRIZ to Software Problems’, TRIZ Journal, October 2002.

Anexos

Resumen, Analogía 40 principios de Inventiva TRIZ (1-20).

Resumen, Analogía 40 principios de Inventiva TRIZ (21-40).

Patentes en el software

Patentar una idea o un producto no es algo nuevo, es más, ésta se lleva a cabo hace mucho tiempo, si bien en algunos casos puede ser vista como una medida arbitraria, también premiar de alguna forma al inventor de un producto u objeto que añada funcionalidad a alguno existente, o éste tenga funcionalidad por si sólo.

Una patente, al igual que un derecho de autor (copyright), entrega a un autor un derecho exclusivo o monopólico respecto a su creación o invención intelectual.

El problema nace al afirmar que está sujeto a patente y que no.

Por ejemplo, el autor de un libro tiene el derecho de autor respecto a éste, ese derecho le otorga protección literaria como artística sobre su obra, pero es de un índole más estético. Con esto nos referimos a que el uso de frases o el argumento de la obra está protegido, tanto para su copia como reproducción, pero no así el género de ésta. Osea, puede tener derecho sobre su obra, pero no sobre el género “crimen/suspenso”, esto permite que existan más escritores que se dediquen a escribir obras de ésa índole, y protege al autor de una copia.

Dentro de las cosas no patentables están por ejemplo; variedades vegetales o animales, inventos en biotecnología y microbiología, productos farmacéuticos y medicamentos esenciales en la lista de la OMS, descubrimientos, teorías científicas ni métodos matemáticos, descubrimiento de materias existentes en la naturaleza, etc.

El software cae en el medio de la polémica, y es a su vez un caso emblemático.

Si bien existen miles de patentes de software, existe un gran número de detractores de éstas, haciendo que en Europa se lleve discutiendo durante varios años el si es posible o no patentar el software.

Respecto al tema que nos atañe, si bien existen grandes cantidades de productos de software patentados, también existe un número mayor de productos que no lo están, siendo un tema complicado y delicado la patentabilidad o no.

Existen a nivel internacional distintas oficinas que conceden patentes y las administra.

Entre éstas está la Oficina Europea de Patentes (OEP), quien presenta una gran cantidad de detractores respecto a nuestro tema. En el caso de Estados Unidos, la práctica de patentar software es realizada comúnmente.

Finalmente en éste sentido, si bien existe una gran controversia, respecto a la patentabilidad o no del software, en éstos momentos, existen una gran cantidad de patentes, lo que permitiría avanzar en el análisis de éstas, trabajo ya iniciado por Darrel Mann, y formular finalmente una teoría de TRIZ pero aplicada directamente al desarrollo o la búsqueda de innovación en el software.

---

[1] Ikovenko, S, “Laws of Engineering System Evolution In Software Development”,·3rd European TRIZ- Conference, ETH Zurich, March 2003.

[2] Karasik, Y., editorial comment, Anti-TRIZ Journal, Vol.2, No.2, and private email correspondence, 8 September 2004.

[3] Rea, K., ‘TRIZ and Software - 40 Principle Analogies, Parts 1 and 2’, TRIZ Journal, September and November 2001.

[4] Mann, D.L., ‘Hands-On Systematic Innovation’, CREAX Press, June 2002.

[5] Mann, D.L., Dewulf, S., Zlotin, B., Zusman, A., ‘Matrix 2003: Updating The TRIZ Contradiction Matrix’, CREAX Press, Belgium, July 2003.