SoftEng °æ (¾«»ªÇø)

·¢ÐÅÈË: ssos (´æÔÚÓëÐéÎÞ), ÐÅÇø: SoftEng
±ê  Ìâ: Problem Structures in Software Engineering 
·¢ÐÅÕ¾: ¹þ¹¤´ó×϶¡Ïã (2000Äê08ÔÂ30ÈÕ12:18:47 ÐÇÆÚÈý), Õ¾ÄÚÐżþ

Problem Structures in Software Engineering
Michael Jackson
Software Development Consultant, London
An inability to discuss problems explicitly has been a glaring deficiency of
 much software practice
and theory. Again and again writers on development method -- whether theoret
icians or practitioners --
have claimed to offer an analysis of a problem when in fact they offer only 
an outline of a solution,
leaving the problem unexplored and unexplained. One reason for this default 
is that software
engineering problems are concerned with the interaction between the informal
 physical and human
world on one side and the formal world of the computer and its programs on t
he other. The problem
is in the world; the computer furnishes the solution.
These lectures describe an approach to grappling with the essentially inform
al nature of the task of
problem structure and analysis. Accordingly, they will emphasise informal an
d intuitive aspects of the
task rather than mathematical aspects. Many examples, some very small, some 
of more realistic size,
will be presented and discussed interactively in class. Much of the lecture 
content is already implicitly
familiar to most participants, but deserves a more explicit articulation.
The central theme of the approach is the use of problem frames. A problem fr
ame characterises a class
of problem, chiefly in terms of the structure and characteristics of its con
text in the world, and of the
relationship between that context and the hardware/software machine to be bu
ilt.
Problem frames can offer useful help in two ways. First, by identifying the 
appropriate software
development tasks. Each frame is associated with a 'frame concern' ­­ the ce
ntral concern that must be
addressed before the problem can be said to have been analysed and understoo
d. This means,
especially, that the frame stipulates what should be described, how descript
ions should be fitted
together and manipulated, and even what languages should be used. One size c
ertainly does not fit all.
Additional particular concerns may be common to many frames, or characterist
ic of particular
properties of the problem context. Anticipating and addressing these concern
s can give strong
guidance in smaller­scale development structure.
Second, frames can provide significant guidance in structuring and decomposi
ng problems on a larger
scale. Realistic, problems can be mastered only if they are decomposed into 
subproblems. Experience
teaches that effective decomposition is not easy. The result is often disapp
ointing: the subcomponents
themselves prove more complex than they should be, their interactions even i
ncreasing rather than
reducing the complexity of the original problem. The failure of the decompos
ition is recognised, but
too late: too much effort has already been spent to allow a fresh start. Pro
blem frames can provide a
taxonomy and a repertoire of subproblem classes for which development method
s are understood,
and can therefore help towards effective problem decomposition.
Recommended reading
[1] Michael Jackson; Software Requirements & Specifications: A Lexicon of Pr
actice, Principles and
Prejudices; Addison­Wesley, 1995.
[2] Daniel Jackson and Michael Jackson; Problem Decomposition for Reuse; Sof
tware Engineering
Journal Volume 11 Number 1 pages 19­30, January 1996.
[3] Michael Jackson; Problem Analysis Using Small Problem Frames; Proceeding
s of WOFACS '98,
South African Computer Journal 22, pp47­60, March 1999.
[4] Michael Jackson; The Real World; in Proceedings of a Symposium to celebr
ate the work of C A R
Hoare; 2000. 
--

   
<<Éç»áÆõÔ¼ÂÛ>>ÊÇÒ»±¾ºÃÊé,Ó¦µ±¶à¶Á¼¸±é
·çζµÄÖâ×ÓζµÀ²»´í,ÎÒ»¹ÏëÔÙ³ÔËü      

¡ù À´Ô´:¡¤¹þ¹¤´ó×϶¡Ïã bbs.hit.edu.cn¡¤[FROM: 202.118.244.254]
[°Ù±¦Ïä] [·µ»ØÊ×Ò³] [Éϼ¶Ä¿Â¼] [¸ùĿ¼] [·µ»Ø¶¥²¿] [Ë¢ÐÂ] [·µ»Ø]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
Ò³ÃæÖ´ÐÐʱ¼ä£º5.998ºÁÃë