home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
dusink.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
14KB
|
339 lines
Insight in the Reuse Pro cess?
Liesbeth Dusink
TU Delft
Tel: +31-15-783832
Email: betje@twi.tudelft.nl
Abstract
In this paper I take the position that at this moment we do not have insight in the software
engineering process and as reuse is a software engineering process directed towards using existing
(partial) solutions, we do not have insight in the reuse process either. We just do things without
being able to explain why things work, should work, go wrong, etc. The only explanations given
are based on common sense which is not enough from the scientific point of view.
Keywords: science, methods, techniques, process
Workshop Goals: Learning; networking; advance state of theory of reusablep osition pap ers.
Working Groups: reuse process models, reuse maturity models, reuse education,reuse and
OO, reuse and formal methods
Dusink- 1
1 Background (reused)
In 1986 an Ada program library had to be build for the Delft Ada subset Compiler. During this
work we were thinking about facilities to offer tothe users. The step to reuse was made. Because
of the Ada background we concentrated on comp onents-based reuse on code level.
As reuse has two sides _ the form of the reusablecomp onents influences how one can reuse and
the process of reuse influences in which form one wants the components - a two-track research
program was started in which the ideal form of comp onents and the ideal process had to be found
and adapted to each other.
2 Position
Since my first experience with software engineering and ever after I have wondered why all methods
only state the products which have to be delivered. The syntax is described,the semantics get less
attention, and how the products have to be made, how to transform a requirements document to
a structure chart for example, is totally neglected.
When I started to developmy own software engineering method which supports the reuse of existing
artifacts and knowledge, I got a further shock. The existing methods were based on experience
only. No sound theories backed them, noexplanations were given why it should be done in the way
described or why it should work. No sound statistical comparisons were made.
Software engineering research is not yet research in the scientific sense. Software engineering meth-
ods are developed and tools are build based on reasonable sounding arguments only. Afterwards
it is claimed "it works because of the higher productivity", but we all know the Hawthorne effect.
A change can have a positive effect independentof the kind of change. Changing back to the old
procedure has again a positive result. Therefore it is impossible to use this kind of information to
build a unifying theory on software engineering. See [1, 2 , 3 , 4 ] for a discussion about this topic.
Another reason is that if one tries a statistical sound way of measuring the effect, there is the
problem of the metrics. As Fenton[5 ] shows, we do not know what to measure, eg. should we
measure lines of code in a month for productivity or should we measure centimeters documentation.
We also do not know what we measure. What does it say whenwe write so many lines of code?
As I got the feeling that software engineering is problem solving by humans for humans, and that
reuse is problem solving with existing (partial) solutions, I went to cognitive psychology to see
whether theories existed on how people solve and should solve problems to base my own method
on.
It appeared that several kinds of problems existed, i.e. formal problems and non-formal problems
[6], and that software engineering could be classified as solving formal problems. For formal problem
solving several theories existed.
Software engineering can be seen as a special form of problem solving. The splitting of the software
lice cycle into several steps is the division of aproblem into subproblems (a general problem solving
method). The use of program plans [7 , 8, 9,10 ] can be compared with the schemata [11 ]. Functional
fixedness in programming was proved by [12 ].
The human understander is best viewed as an opportunistic processor, capable of exploiting b oth
Dusink- 2
bottom up and top-down cues as they become available [13 ]. This is consistent with the memory
model of the schema theory. We see that software engineers do the same. Generally, it is found
that software engineers first play withthe problem, give partial solutions, go into details, etc. until
they feel grip on the problem (a mental problem model is created) [14]. From then on they first
give a solution in general terms before they specialize [15 ].
All these findings supported the idea that conclusions from cognitive psychology can be used in
software engineering.
My work gives theories based on cognitive psychology, and from the conclusions drawn a process
is derived and necessary characteristics for describing reusable components are derived.
My work has improved the state of the art by giving a process model which is also refined to a
method.
My work has improved the state of the practice as HP has used ideas from it in their reuse project,
the reuse process model as discussed in former workshops has incorporated severalideas.
2.1 Reuse
Without knowledge of problem-related concepts,the memory quickly reaches its limits when trying
to understand code [16 ]. This is because the knowledge can not b e related to existing schemata
and thus has to be stored as separate facts in the short term memory. As the short termmemory
is non-associative and can contain up till 7 items, one sees the relevance of laying relations with
existing knowledge [17 , 6, 16 , 18 ].
There are different approaches when trying to understand co de, a systematic strategy and an ad hoc
strategy [8, 19 ]. In the systematic approach first the total documentation is studied in a systematic
manner. In the ad hoc approach documentation is read at random. The systematic approach can
take too much time for large pieces of program andthe ad ho cstrategy gives poorer results when
adapting a program. Therefor do cumentation has to be in such a way that it is easy to combine
both strategies in an intelligent manner. The documentation has also to be in such a way that the
limits of the memory are not reached very quickly.
In [20 ] mental laziness is remarked as one of the problems with reuse. In [21] some experiments are
done about how to prevent that the habit masters the individual instead of the individual mastering
the habit. It appears that by promoting productive thinking the problem of mental laziness could
be overcome. If a solution is actively verbalized transformation to new situations becomes easier
[11 ]. This improves reuse. The active participation in finding a solution improves the recognition
of the possibility of applying the solution to other areas [11 ].
There are two basically different approaches to understanding a program. The first is the systematic
strategy, where the programmer traces data flow and control flow throughout the program. The
second strategy is the as-needed strategy, where the programmer reads only those part of the
documentation or code as (s)he thinks to be of interest [19 , 8].
Dusink- 3
3 Comparison with Other Work
Maiden and Sutcliffe explain findings from experiments with help of cognitive psychology. They
also base tools on hypothesis from cognitive psychology.
In Bill Curtis' [22 ] collection of articles, one finds a lot of articles which compare methods or
techniques for parts of the life cycle. But, as one of the comments from Curtis states, these
comparisons are mostly not sound on methodological level, no experienced programmers are used
thus the conclusions can not be extrapolated to experienced programmers as it it known that
experienced programmers work different than less experienced programmers.
Fisher and his group have a model on how programmers work, based on cognitive psychology, and
base a series of tools on their model.
One sees that other persons and groups concentrate on the tool side of software engineering. Where
Mayer [23 ] made clear that the syntactic sugar in which concepts are modeled is important for faster
and better understanding of the used concepts. And it is not yet clear what kind of syntactic sugar
is helpful and what kind is not. There are conflicting studies [24 ].
References
[1] G. H. Bradley, "Cognitive Science View of Software Engineering," in Gibbs and Fairley [25 ],
pp. 35-51.
[2] A. N. Habermann, "Report of the Software Engineering Priciples Working Group," in Gibbs
and Fairley [25 ], pp. 369-380.
[3] W. E. Richardson, "Why Is Software Engineering So Difficult?," in Gibbs and Fairley [25 ],
pp. 98-106.
[4] R. H. Thayer and L. A. Endres, "Software Engineering Pro ject Laboratory: The Bridge Be-
tween University and Industry," in Gibbs and Fairley [25 ], pp. 263-291.
[5] N. E. Fenton,SOFTWARE METRICS: A Rigorous Approach. Chapman and Hall, 1991. ISBN
0-442-31355-1.
[6] W. Wickelgren, Cognitive Psychology. Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1979.
[7] R. Rist, "Planning in Programming: Definition, Demonstration, and Development," in Soloway
and Iyengar [26 ], pp. 28-47. (Human/Computer Interaction Series).
[8] D. Littman, J. Pinto, S. Letovsky, and E. Soloway, "Mental Models and Software Mainte-
nance," in Soloway and Iyengar [26], pp. 80-98. (Human/Computer Interaction Series).
[9] C.-C. Yu and S. Robertson, "Plan-Based Representations of Pascal and Fortran Code," in
Soloway et al. [27 ], pp. 251-256. special issue of the ACM/SIGCHI Bulletin.
[10] S. Wiedenbeck, "Processes in Computer Program Comprehension," in Soloway and Iyengar
[26 ], pp. 48-57. (Human/Computer Interaction Series).
[11] R. Mayer, Thinking, Problem-Solving, Cognition. W.H. Freeman and Company, 1983.
Dusink- 4
[12] R. Mayer, "Different Problem-Solving Competencies Established in Learning Computer Pro-
gramming With and Without Meaningful Models," Journal of Educational Psychology, no. 67,
pp. 725-734, 1975.
[13] S. Letovsky, "Cognitive Processes in ProgramComprehension," in Soloway and Iyengar [26 ],
pp. 58-79. (Human/Computer Interaction Series).
[14] R. Guindon and B. Curtis, "Control of Cognitive Processes during Software Design: What
Tools are Needed?," in Soloway et al. [27 ], pp.263-268. special issue of the ACM/SIGCHI
Bulletin.
[15] K. Duncker, "On Problem Solving," Psychological Monographs, vol. 58, p. 270, 1945.
[16] B. Shneiderman, Software Psychology: Human Factors in Computer and Information Systems.
Little, Brown Computer Systems Series, Little, Brown &Company, 1980.
[17] A. Newell and H. A. Simon, Human Problem Solving. Engle Wood Cliffs N.J.: Prentice-Hall,
1972.
[18] G. A. Miller, "The Magical Number Seven_Plus or Minus Two: Some Limits on our Capacity
for Processing Information," Psychological Review, no. 63, pp. 81-97, 1956.
[19] J. Pinto and E. Soloway, "Providing the requisite Knowledge Via Software Documentation,"
in Soloway et al. [27 ], pp. 257-262. special issue of the ACM/SIGCHI Bulletin.
[20] N. Maiden and A. Sutcliffe, "The Abuse of Re-use: Why Cognitive Aspects of Software Re-
usability are Important," in Software Re-use, Utrecht 1989: Proceedings of the Software Re-
use Workshop, 23-24 November 1989, Utrecht, The Netherlands (L. Dusink and P. Hall, eds.),
ch. 10, Springer-Verlag, 1991.
[21] A. Luchins and E. Luchins, "New Experimental Attempts at Preventing Mechanization in
Problem Solving," Penguin Modern Psychology, ch. 6, Penguin Books, 1968.
[22] B. Curtis, ed., Tutorial: Human Factors in Software Development (second edition). IEEE
Computer Society Press/ North-Holland, 1986.
[23] R. E. Mayer, "Comprehension as affected by structure of problem representation," in Curtis
[22 ], pp. 320-326.
[24] S. B. Sheppard, E. Kruesi, and B. Curtis, "The effects of symbology and spatial arrangement
on the comprehension of software specifications," in Curtis [22], pp. 327-334.
[25] N. E. Gibbs and R. E. Fairley, eds., Software Engineering Education: The Educational Needs
of the Software Engineering Community. New York: Springer-Verlag, 1987.
[26] E. Soloway and S. Iyengar, eds.,Empirical Studies of Programmers, papers presented at the
First Workshop on Empirical Studies of Programmers, June 5-6, 1986, Washington, DC.,
Ablex, 1986. (Human/Computer Interaction Series).
[27] E. Soloway, D. Frye, and S. Sheppard, eds., CHI'88 Conference Proceedings, Human Factors
in Computing Systems, May 15-19, 1988 Washington, DC.,, ACM Press, 1988. special issue
of the ACM/SIGCHI Bulletin.
Dusink- 5
4 Biography (reused)
Liesbeth Dusink is a lecturer at Delft University of Technology, chair software engineering, since
1985. She teaches introduction in programming in Modula-2 with VDM, software engineering and
object oriented approach, and software engineering environments. Since 1992 she also works as
research engineer at Cap Gemini Innovation, Rijswijk. At Cap Gemini she designs in VDM and
VDM++ and programs in Ada. At this moment she works on a project for tracking and tracing
of trains. These two jobs together offer a unique combination of theory and practice.
Dusink- 6