At 05:12 PM 10/6/99 +0100, Jason Trenouth wrote:
>On Wed, 06 Oct 1999 16:44:38 +0100, "Peter Hornsby" <[EMAIL PROTECTED]>
>wrote:
>
>> My work is very much concerned with using contextual knowledge in software
>> engineering. I am currently developing a system which uses design
>> information as a source of 'meaning' for code - identifying higher level
>> information about what the code is being used for rather than using formal
>> approaches to (fairly ridigly) specify what a given code fragment /
>> component can be used for.
>
>You might also consider applying the same treatment to code changes as
well as
>fixed pieces of code. That is, you could identify higher information about
>what the changes to code are for.
Capturing why a change has been made to a given code fragment (or design,
or interface) can be very useful. Gerhard Fischer did some work on this
with a system which captured the contextual rationale for network design
within an organisation, identifying particular 'special cases' and how
these were addressed. My approach to the problem you describe would
capture the 'old' code and the 'new' code together with the relevant design
information about what both code fragments are intended to do - hence we
have 2 alternate solutions. Rather than require the developer to do
additional work to get the potential for reuse, I believe that having a
tool operating in the background which captures design information and
makes suggestions to the developer is more useful (and more likely to be
used when we throw it over the wall!).
>Perhaps code changes could be called "delta code"? At the design level one
>might imagine "delta UML" which diagrammatically describes changes to a
>design. I wonder if such a thing has been formulated yet or if it has any
>worth?
A problem I have with UML at the moment (if anyone has a view on this I
would be grateful) is that much of the UML literature says that things
should not be documented which are "obvious". In a software development
environment where people are changing jobs, the skill base is shifting,
what is obvious from one persons' perspective may well be non-obvious from
anothers. So should the imaginary line be drawn at an arbitrary point, or
do guidelines exist for this cut-off point for documentation?
Pete
------------------------------------------------------------------------
Peter Hornsby,
Department of Computer Science
Loughborough University,
Loughborough,
Leicestershire,UK EMAIL:[EMAIL PROTECTED]
LE11 3TU. Tel: +44 (0)1509 222799
Fax: +44 (0)1509 211586
------------------------------------------------------------------------
