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:
The book
ProblemFrames has a different list:
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
MultiFrameProblems.
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