Con la palabra TRIZ, a menudo se recuerda la tesis "un sistema ideal es aquel que no existe (y su función se cumple)". Como un buen administrador que no aparece en la oficina, pero todo funciona correctamente.
La función y el sistema son conceptos críticos en TRIZ, incluso hablan de un estilo funcional de pensamiento. Es cierto que con estas palabras, personalmente me asocio inmediatamente con lenguajes de programación funcionales.
Tratemos de ver cómo se muestran orgánicamente las ideas de pensamiento funcional de TRIZ en Haskell, uno de los lenguajes funcionales puros de propósito general.
Función
Función : un modelo para cambiar la propiedad de un objeto de función ("producto") por un portador de función ("herramienta").
Una herramienta es algo con lo que trabajamos, es decir, Estamos cambiando algo Como regla, es lo que necesita ser mejorado o creado. En consecuencia, es el portador de la función que generalmente se entiende por la palabra "sistema" en todos los argumentos de TRIZ al respecto.
Un producto es lo que cambiamos (procesamos) con una herramienta.
La función principal es una propiedad de consumo, para lo cual se crea un sistema técnico.
La función en sí misma generalmente se define mediante un verbo simple, que refleja la esencia del proceso (no es un término especial, para no interferir con la inercia del pensamiento), el portador y el objeto de la función están incluidos en la formulación.
Por ejemplo: un martillo mueve un clavo; una escoba mueve basura; la taza contiene café; la aspiradora mueve el polvo; El combustible mueve el cohete.
Considere, en particular, una taza de café.
Una taza contiene café.
El portador de la función (herramienta) es una taza, el objeto de la función es el café, la función es sostener.
-- -- , - hold :: Cup -> Coffee -> Coffee -- hold - "" cup `hold` coffee
La función de retención debe ser polimórfica, ya que una taza puede contener no solo café y el café puede verterse no solo en una taza:
-- b, b hold :: a -> b -> b -- , thermos `hold` coffee -- , shirt `hold` coffee
La herramienta y el producto pueden cambiar, y la esencia de su interacción, expresada por la función, sigue siendo la misma. Según las estadísticas, la mayoría de las funciones de pares entre elementos de sistemas técnicos se pueden describir con tres docenas de verbos (mover, mantener, calentar, absorber, informar, etc.). Cada uno de ellos desde el punto de vista de la implementación de Haskell es una función polimórfica. Como, sin embargo, el resto de los verbos del lenguaje natural.
Función inversa
En el mundo real, siempre existe la función opuesta: la acción del producto en el instrumento (nadie canceló la tercera ley de Newton).
Por ejemplo, el metal que se está procesando embota el taladro, un estudiante descuidado cansa al maestro y el archivo reduce el espacio libre en el disco.
En el ejemplo del café, calienta y mancha la taza.
Como regla, la función inversa nos perjudica (desgaste de la herramienta, costos adicionales), pero en otras situaciones podemos beneficiarnos de ella. Por ejemplo, caliéntese las manos en una taza caliente mientras esté en una habitación fresca.
hold:: a -> b -> b warm :: a -> b -> b cup `hold` coffee coffee `warm` cup
Cadenas Funcionales
En el caso de que el número de elementos del sistema sea superior a dos (es decir, de hecho, siempre) se consideran en pares, recibiendo cadenas de funciones.
Por ejemplo, en la figura siguiente, una mano lleva (mueve) una bandeja con una taza, una bandeja sostiene una taza y una taza contiene café.
((arm `move` wrist) `hold` cup) `hold` coffee
Eliminar paréntesis especificando asociatividad izquierda
infixl 9 hold arm `move` wrist `hold` cup `hold` coffee
Grabar en Haskell está muy cerca de grabar en lenguaje natural.
Y la cadena en la dirección opuesta: el café calienta la taza, la taza calienta el platillo, el platillo carga la mano.
infixl 9 warm, weight coffee `warm` cup `warm` wrist `weight` arm
Comprender la función principal y las interacciones entre los elementos le permite elegir de manera óptima los límites del sistema, incluir solo lo que se necesita para completar la tarea objetivo (sin perder nada) y no complicar el modelo más allá de lo necesario.
Un sistema que no existe ...
Necesitamos una función, o más bien el resultado de su aplicación, y la herramienta en sí no es necesaria. Este es un consumible, atraído solo por la necesidad.
El café puede ser sostenido por un cezve, una tetera, un termo, un platillo y una mesa y camisa (si el café se derrama inadvertidamente).
Ni siquiera nos importaría si el café se sostuviera solo. Cómo sucede esto, por ejemplo, con agua en gravedad cero en una estación espacial.
Sin embargo, no es habitual detenerse en formulaciones en bucle como "el café tiene café" en TRIZ, ya que es inútil desde un punto de vista práctico: no proporciona información sobre los elementos mediante los cuales se logra el resultado.
Desde el punto de vista de la programación, una formulación tan recursiva es mala ya que no hay condición para terminar la recursividad.
Es necesario profundizar e indicar qué partes (subsistemas) proporcionan el cumplimiento de la función.
El líquido asume una forma compacta en gravedad cero debido a las fuerzas de tensión superficial. T.O. Una descripción más apropiada de la situación sería: la capa superficial contiene el volumen interno de café.
Puedes imaginar todo el volumen de café como una matryoshka de capas, cada una de las cuales se sostiene entre sí. En este caso, el trabajo principal lo realiza la capa externa.
-- - , - let coffee = [layer1, layer2, layer3, layer4, layer5] head coffee `hold` tail coffee
Sin embargo, si es importante para nosotros que las capas se influyan entre sí (por ejemplo, en términos de absorción de luz),
uno puede inventar una bicicleta y describir interacciones secuenciales explícitamente.
Se preserva la naturaleza recursiva del fenómeno, pero al comprender las interconexiones de los subsistemas, podemos establecer las condiciones para salir de la recursividad y convertirla en nuestro servicio.
-- "", hold :: String -> String -> String hold tool "" = tool hold tool workpiece = tool ++ " -> holds -> " ++ workpiece -- " ". -- -- "" -- selfHold :: [String] -> String selfHold [] = "" selfHold (x:xs) = x `hold` selfHold xs -- selfHold ["Layer1","Layer2","Layer3"]
al final obtenemos
Capa1 -> retenciones -> Capa2 -> retenciones -> Capa3
La recursividad de la implementación no ha desaparecido en ninguna parte, sino que se ha vuelto constructiva y no obsesionada sin sentido.
Lo mismo se puede escribir en resumen, a través de la convolución de la lista:
foldl1 hold ["Layer1","Layer2","Layer3"]
Conclusión
La visión de un sistema técnico como un entramado de funciones que lo unen y determinan la esencia y el propósito de TRIZ está extremadamente relacionado con TRIZ con lenguajes de programación funcionales, en los que una función es la estructura de control principal.
El enfoque considerado es una buena ayuda en términos de descomponer el problema y controlar la complejidad del modelo.