TRIZ – Theory of Inventive Problem Solving
en.wikipedia.org
en.wikipedia.org
Christopher Alexander (architect and influencer of GoF's original software Design Patterns) very cleverly re-frames design problems in one of his books [1] as optimization problems, where the designer is tasked with minimizing the tension between two or more conflicting requirements arranged as a graph, and where each requirement interacts positively or negatively with it's neighbours. By representing a design problem this way, it follows that "solving" it amounts to clustering requirements together to form sub-components that interact well together, or redefining the solution/context boundaries to re-frame the problem and minimize the overall tension.
It's interesting how this TRIZ framework arrives at many similar insights about the design problem, and I wonder what you get by mixing the two approaches. A lot of what makes it hard to apply is also what makes Christopher's framework hard to apply, which is clear definition of the requirements in the first place. C-K theory seems to overcome these limitations but I haven't played with it yet.
[1] https://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form
In retrospect this may sound obvious and trivial but taking this simple graph based view of the basis of systems design as the fundamental idea gives concreteness to e.g. lot of software systems practices and unifies them.
[1] - well worth a read. Did you know there was a terribly humane philosophy behind the original design patterns work? This was beautifully described in Peopleware as "Local control of design by those who will occupy the space". E.g. - Alexander advocates for the people who are going to live in and work in the buildings be intimately involved in both the design and the construction of the buildings. Not only does he advocate for this, he explains ways of doing this in practice. This philosophy could be ported to software -- let the users of software systems be involved in the design and construction of the systems. That sounds like far more of an ambitious and genuinely positive idea than the old "visitor pattern" / "singleton [anti]pattern" stuff that springs to mind when one has been subjected to the computer-science-education version of design patterns.
http://fictionbook.ru/static/trials/09/81/13/09811350.html
Main character, a boy called Denis frequently sees problems around him, which allow him to apply his TRIZ skills. The book has explanation and problems, so the reader can try to learn the method.
http://5razvorotov.livejournal.com/1197775.html http://www.u-mama.ru/read/section/reviews/books-for-child/72... http://www.labirint.ru/books/376992/
It might be great as taxonomy of problem solutions, but there is no reliable evidence that it works as a methodology. Reducing research activity to a bunch of codified chess-like moves is a huge temptation. However I haven't seen its adepts producing any unexpected results (in practice, not on some TRIZ textbook puzzle). The solutions were on par with what you'd expect from a person of comparable intelligence, experience and education background otherwise.
A parallel is perhaps biomimetics [1], an active current research area of 'design inspired by life/ biology'. Often, it is controversial if the invention was truely inspired by nature, or just made for good marketing. 'Shark skin' swimsuits were named by marketers after the actual invention [2]. Our experiance with heavier-than-air flight was terrible until we stopped trying to mimic how birds fly.
[1] https://en.wikipedia.org/wiki/Biomimetics [2] http://www.independent.co.uk/news/science/swimsuit-is-not-li...
...but then you realize a lot of the complexity is just hidden behind your definitions for the words in the TRIZ matrix (or in the case of "symbolic AI", in the precise semantic meaning you are assuming for the symbols)
For instance, for a carrot slicing machine you might end up with a solution that uses the forward motion of the whole device in conjunction with an airfoil to create the force to cut the carrot. While plausible, this is not the best solution.
If some of these problems could be fixed, we'd essentially have a hardware description language for mechanical engineering. And with this we could do the same sorts of design automation the semiconductor industry has been doing except for mechanical systems.
[0] http://enterprise.mie.uic.edu/me250/files/1113/4688/4799/woo...