MichaelJackson introduced the idea of a ProblemFrame in SoftwareRequirementsAndSpecifications and then
elaborated this idea in his book ProblemFrames. A problem frame is a way of categorizing problems, and MichaelJackson
is producing a catalog of problem frames that is sort of like a catalog of design patterns.
The problem frames discussed in SoftwareRequirementsAndSpecifications are:

	*SimpleInformationSystemFrame
	*SimpleControlFrame
	*JspFrame (JacksonStructuredProgramming)
	*ConnectionFrame
	*WorkpiecesFrame

The book ProblemFrames has a different list:

	*ControlledBehaviorFrame
	*CommandedBehaviorFrame
	*WorkpiecesFrame
	*InformationDisplayFrame
	*TranslatorFrame

Why would you be interested in ProblemFrames? From the book: ''A problem frame is a generalization of a class of problem. If there are many other problems that fit the same frame as the problem you're dealing with, then you can hope to apply the method and techniques that worked for those other problems to the problem you're trying to solve right now.'' and ''The reward for finding a problem frame that fits your problem is that the frame brings with it a method that will be really effective for solving the problem.[...] if the frame fits the method will work.'' 

And a bad fit will result in failure, no matter how effective the method would be on a well-fitting problem.

A problem frame consists in:
	*solution tasks
	*principle parts
		*relationships between them
		*their characteristics

I see problem frames as a dual to patterns, in that they discuss recurring problems (not recurring solutions, as patterns do).

They are also abstract, where patterns tend to be concrete, again from the book:''All useful problem frames are unrealistically simple'' and ''Realistic problems are not that simple'', but their complications stem from being ''MultiFrameProblem''''''s''.

----
This is an idea so simple and transparent that it seems almost trivial
(''like most Jacksonian ideas''), yet I believe that it may be as important as the idea of a PatternLanguage. I also believe it is the key to Jackson's idea that EveryoneShouldBeaMethodologist. 

Everyone (involved in development) should be familiar with the problem frames and the sets of techniques appropriate for each, and how to identify the (possibly overlapping) frames in their problem, and how to combine the techniques apropos for those frames into a working method for the problem in hand.

Maybe a ProblemFrame gives rise to a PatternLanguage?

Thoughts?

--KeithBraithwaite
----
A problem frame defines an architecture with respect to a given class of problems, establishing a context in which a resulting structure is created. So yes, I believe there is a string relationship between a PatternLanguage and a ProblemFrame.

There is no XpFrame or BigDesignUpFrontFrame (and similarly I am unconvinced by the idea of a RefinementFrame or a UsecaseFrame) as these are strictly process rather than architectural concepts: a ProblemFrame characterizes the structure and the appropriate design (meta)model within a particular, well, ProblemFrame! OTOH, ExtremeProgramming, BigDesignUpFront, etc describe the process of approaching and carrying out the development of a system, ie roles, deliverables, phases, etc. Whilst not entirely orthogonal, they are still separated concepts; not identical. For instance, one can use either ExtremeProgramming or BigDesignUpFront to develop something in the WorkpiecesFrame.

-- KevlinHenney

----

One of the five patterns used to describe adaptive programming in the Demeter group at NortheasternUniversity is InventorsParadox.

See http://www.ccs.neu.edu/research/demeter/adaptive-patterns/AOP/

--StanSilver
----
''And a bad fit will result in failure, no matter how effective the method would be on a well-fitting problem.''

That's too strong a statement. A bad fit will result in a lot of other stuff to deal with, including solution stuff that addresses no problem, and problems not fully addressed. Bad fitting clothes are not elegant, and neither are bad fitting methods. But lack of elegance does not always mean failure.

The notion of XpFrame seems misguided. XP is a 'machine' that solves the problem of getting software developed. The basic requirement is one of having the right software at the right time. This is a control problem. We are not talking about the problem the software is supposed to solve, although that's where Jackson's work is focused. Is there something about the environment in which you would use XP that calls for a special kind of control? If so, the proposed XpFrame might be a special case of control frame. But I doubt it. Anyone?

Also, the BigDesignUpFrontFrame, UseCaseFrame and RefinementFrame are similarly misdirected and in no way implied from the text I read.

-- WaldenMathews
----
One of Jackson's conclusion is that a problem solving method that fits lots of problems (it has a loosely fitting ProblemFrame) provides less help than a tight one.

For example, the various refinement methods fitted all problems and provided hardly any help in specific cases.

His second conclusion is that when you have one tightly fitting ProblemFrame you have no difficulty solving the problem. Life gets interesting when you have two or more frames that fit at the same time. Then you have a tough problem!

-- DickBotting