Beim Wort TRIZ erinnert man sich oft an die These: "Ein ideales System ist eines, das es nicht gibt (und dessen Funktion erfüllt ist)." Wie ein guter Administrator, der nicht im Büro erscheint, aber alles richtig funktioniert.
Funktion und System sind kritische Konzepte in TRIZ, sie sprechen sogar von einem funktionalen Denkstil. Richtig, mit diesen Worten verbinde ich mich persönlich sofort mit funktionalen Programmiersprachen.
Lassen Sie uns versuchen zu sehen, wie organisch die Ideen des funktionalen Denkens von TRIZ auf Haskell, einer der rein funktionalen Sprachen für allgemeine Zwecke, dargestellt werden.
Funktion
Funktion - Ein Modell zum Ändern der Eigenschaft eines Funktionsobjekts ("Produkt") durch einen Funktionsträger ("Werkzeug").
Ein Werkzeug ist etwas, mit dem wir arbeiten, d. H. Wir ändern etwas. In der Regel muss es verbessert oder geschaffen werden. Dementsprechend ist es der Träger der Funktion, der normalerweise in allen TRIZ-Argumenten darüber mit dem Wort "System" gemeint ist.
Ein Produkt ist das, was wir mit einem Werkzeug ändern (verarbeiten).
Die Hauptfunktion ist ein Verbrauchereigentum, für das ein technisches System erstellt wird.
Die Funktion selbst wird normalerweise durch ein einfaches Verb definiert, das die Essenz des Prozesses widerspiegelt (kein spezieller Begriff, um die Trägheit des Denkens nicht zu beeinträchtigen). Der Träger und das Objekt der Funktion sind in der Formulierung enthalten.
Zum Beispiel: Ein Hammer bewegt einen Nagel; ein Besen bewegt Müll; die Tasse hält Kaffee; Der Staubsauger bewegt den Staub. Kraftstoff bewegt die Rakete.
Betrachten Sie insbesondere eine Tasse Kaffee.
Eine Tasse hält Kaffee.
Der Träger der Funktion (Werkzeug) ist eine Tasse, der Gegenstand der Funktion ist Kaffee, die Funktion ist zu halten.
-- -- , - hold :: Cup -> Coffee -> Coffee -- hold - "" cup `hold` coffee
Die Haltefunktion muss polymorph sein, da eine Tasse nicht nur Kaffee aufnehmen kann und Kaffee nicht nur in eine Tasse gegossen werden kann:
-- b, b hold :: a -> b -> b -- , thermos `hold` coffee -- , shirt `hold` coffee
Das Werkzeug und das Produkt können sich ändern, und das Wesen ihrer Interaktion, ausgedrückt durch die Funktion, bleibt gleich. Laut Statistik können die meisten Paarfunktionen zwischen Elementen technischer Systeme durch drei Dutzend Verben (Bewegen, Halten, Erhitzen, Absorbieren, Informieren usw.) beschrieben werden. Jeder von ihnen ist aus Sicht der Haskell-Implementierung eine polymorphe Funktion. Wie jedoch der Rest der Verben der natürlichen Sprache.
Umkehrfunktion
In der realen Welt gibt es immer die entgegengesetzte Funktion - die Wirkung des Produkts auf das Instrument (niemand hat Newtons drittes Gesetz aufgehoben).
Zum Beispiel stumpft das zu bearbeitende Metall den Bohrer ab, ein unvorsichtiger Schüler ermüdet den Lehrer und die Datei reduziert den freien Speicherplatz.
Im Kaffeebeispiel erhitzt und verschmiert er die Tasse.
In der Regel schadet uns die Umkehrfunktion (Werkzeugverschleiß, zusätzliche Kosten), aber in anderen Situationen können wir davon profitieren. Erwärmen Sie beispielsweise Ihre Hände in einem kühlen Raum auf einer warmen Tasse.
hold:: a -> b -> b warm :: a -> b -> b cup `hold` coffee coffee `warm` cup
Funktionsketten
In dem Fall, in dem die Anzahl der Elemente des Systems mehr als zwei beträgt (d. H. Tatsächlich immer), werden sie paarweise betrachtet und erhalten Funktionsketten.
In der folgenden Abbildung trägt (bewegt) beispielsweise eine Hand ein Tablett mit einer Tasse, ein Tablett enthält eine Tasse und eine Tasse enthält Kaffee.
((arm `move` wrist) `hold` cup) `hold` coffee
Entfernen Sie Klammern, indem Sie die linke Assoziativität angeben
infixl 9 hold arm `move` wrist `hold` cup `hold` coffee
Die Aufnahme in Haskell kommt der Aufnahme in natürlicher Sprache sehr nahe.
Und die Kette in die entgegengesetzte Richtung: Kaffee heizt die Tasse, die Tasse heizt die Untertasse, Untertasse lädt die Hand.
infixl 9 warm, weight coffee `warm` cup `warm` wrist `weight` arm
Wenn Sie die Hauptfunktion und die Interaktionen zwischen Elementen verstehen, können Sie die Grenzen des Systems optimal auswählen, nur das einbeziehen, was zur Ausführung der Zielaufgabe erforderlich ist (ohne etwas zu verpassen), und das Modell nicht über das Notwendige hinaus komplizieren.
Ein System, das es nicht gibt ...
Wir brauchen eine Funktion oder vielmehr das Ergebnis ihrer Anwendung, und das Werkzeug selbst wird nicht benötigt. Dies ist ein Verbrauchsmaterial, das nur durch die Notwendigkeit angezogen wird.
Kaffee kann von einer Cezve, einer Teekanne, einer Thermoskanne, einer Untertasse sowie einem Tisch und einem Hemd gehalten werden (wenn der Kaffee versehentlich verschüttet wird).
Es würde uns nicht einmal etwas ausmachen, wenn sich der Kaffee selbst halten würde. Wie dies zum Beispiel mit Wasser in Schwerelosigkeit an einer Raumstation geschieht.
Es ist jedoch nicht üblich, sich in TRIZ mit Schleifenformulierungen wie „Kaffee hält Kaffee“ zu befassen, da dies aus praktischer Sicht nutzlos ist - es liefert keine Informationen über die Elemente, mit denen das Ergebnis erzielt wird.
Aus programmtechnischer Sicht ist eine solche rekursive Formulierung insofern schlecht, als es keine Bedingung zum Beenden der Rekursion gibt.
Es ist notwendig, tiefer zu gehen und anzugeben, welche Teile (Subsysteme) die Erfüllung der Funktion gewährleisten.
Die Flüssigkeit nimmt aufgrund der Oberflächenspannungskräfte in Schwerelosigkeit eine kompakte Form an. T.O. Eine angemessenere Beschreibung der Situation wäre: Die Oberflächenschicht enthält das Innenvolumen des Kaffees.
Sie können sich das gesamte Kaffeevolumen als eine Matroschka aus Schichten vorstellen, die sich gegenseitig halten. In diesem Fall wird die Hauptarbeit von der äußeren Schicht erledigt.
-- - , - let coffee = [layer1, layer2, layer3, layer4, layer5] head coffee `hold` tail coffee
Wenn es für uns jedoch wichtig ist, dass sich die Schichten gegenseitig beeinflussen (z. B. hinsichtlich der Lichtabsorption),
man kann ein Fahrrad erfinden und sequentielle Wechselwirkungen explizit beschreiben.
Die rekursive Natur des Phänomens bleibt erhalten, aber wenn wir die Zusammenhänge der Subsysteme verstehen, können wir die Bedingungen für den Austritt aus der Rekursion festlegen und sie in unseren Dienst umwandeln.
-- "", 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"]
Am Ende bekommen wir
Schicht1 -> hält -> Schicht2 -> hält -> Schicht3
Die Rekursivität der Implementierung ist nirgendwo verschwunden, sondern konstruktiv und nicht bedeutungslos besessen.
Das Gleiche kann kurz gesagt durch die Faltung der Liste geschrieben werden:
foldl1 hold ["Layer1","Layer2","Layer3"]
Fazit
Die Vision eines technischen Systems als eine Struktur von Funktionen, die es vereinen und das Wesen und den Zweck von TRIZ bestimmen, hängt stark mit TRIZ mit funktionalen Programmiersprachen zusammen, in denen eine Funktion die Hauptsteuerungsstruktur darstellt.
Der betrachtete Ansatz ist eine gute Hilfe bei der Zerlegung des Problems und der Kontrolle der Komplexität des Modells.