Triz - Patrones de Software

UNIVERSIDAD TÉCNICA FEDERICO SANTAMARIA
Departamento de Informática

Triz para Software
Analogía de Patrones de Software
Patricio Esquivel 2151024-6
Francisco Riveros E. 2273036-3
Andro Vlahovic 2273037-1

Profesor : Lautaro Guerra

6/23/2008

2 Triz para Software

Indice
Introducción ....................................................................................................................... 4
Algoritmos Rápidos ...................................................................................................... 4
Ley de Moore................................................................................................................. 5
Tamaño del Software ..................................................................................................... 6
Desarrollo de Arquitecturas ............................................................................................ 6
Modas de una evolución tecnológica .............................................................................. 7
Triz para el Software .......................................................................................................... 7
Problemas de Software ................................................................................................... 9
Triz para Software.......................................................................................................... 9
Definición .................................................................................................................... 10
Siete Pilares de “TRIZ para Software” ......................................................................... 10
Subversión Análisis ...................................................................................................... 10
Matriz de Contradicciones ............................................................................................ 11
Generación de Solución................................................................................................ 13
Secuencia de uso (frecuencia) de los Principios de Inventiva ........................................ 15
Idealidad y Tendencias ............................................................................................. 16
Diseñando Patrones de Software con Triz ........................................................................ 17
Contradicciones Espacio-Tiempo ................................................................................. 18
Diseño de Patrones y TRIZ .............................................................................................. 19
1. Adapter Pattern y el principio Mediador (Mediator Principle) ................................ 19
1.3 Adaptación por herencia ..................................................................................... 19
1.2 Adaptación por Composición.............................................................................. 20
2. Composite and Iterator Pattern y el principio de Universalidad (Universality
Principle) ..................................................................................................................... 21
3. Decorator Pattern y los principios de Agrupamiento y/o Membranas Flexibles ...... 21
4. Facade Pattern y el principio de la consolidación ................................................... 21
5. Flyweight Pattern y el principio de transición hacia una nueva dimensión ............. 22
6. Proxy Patterm y los principios de Cambio de parámetro y/o transición de fase ..... 22
Ejemplos de Patrones ....................................................................................................... 23
Proxy pattern................................................................................................................ 23
Decorator Pattern ......................................................................................................... 23
Facade Pattern.............................................................................................................. 24
Bridge Pattern .............................................................................................................. 25
Composite Pattern ........................................................................................................ 26


Adapter Pattern ............................................................................................................ 27
Conclusiones .................................................................................................................... 27
Referencias ...................................................................................................................... 28
Anexos............................................................................................................................. 29
Patentes en el software ................................................................................................. 31


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.

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.


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
Rea3.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 TRIZ4 (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

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.


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

5
Mann, D.L., Dewulf, S., Zlotin, B., Zusman, A., „Matrix 2003: Updating The TRIZ Contradiction Matrix‟,
CREAX Press, Belgium, July 2003.


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 25. Self-Service
2. Extraction 26. Copying
3. Local Quality 27. Cheap/Short Living
4. Asymmetry 28. Another Sense
5. Combination 29. Fluidity
6. Universality 30. Thin & Flexible
7. „Nested Doll‟ 31. Holes
8. Counterbalance 32. Colour Changes
9. Prior Counter-Action 33. Homogeneity
10. Prior Action 34. Discarding and Recovering
11. Prior Cushioning 35. Parameter Changes
12. Remove Tension 36. Paradigm Shift
13. „The Other Way Round‟ 37. Relative Change
14. Loop 38. Enrich
15. Dynamics 39. Calm
16. Slightly Less/Slightly More 40. Composite Structures
17. Another Dimension
18. Vibration
19. Periodic Action
20. Continuity of Useful Action
21. Hurrying
22. „Blessing in Disguise‟
23. Feedback
24. Intermediary
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 Volumen de un objeto estático
e información" (Característica del sistema 8)
"incremento de tiempo Tiempo de acción de un objeto
necesario para encontrar estacionario ( Característica del
una respuesta" 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
{
{
super.operacion();
}
}
public interface Implementador
{
public abstract void operacion();
}
public class ImplementacionA implements Implementador
{
{
System.out.println("implementacion A");
}
}
public class ImplementacionB implements Implementador
{


{
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.

Triz - Patrones de Software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Triz - Patrones de Software

Ähnlich wie Triz - Patrones de Software (20)

Triz - Patrones de Software