eiffel/bon-method-website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Imported from archive

Browse Source
This commit is contained in:
Eiffel operator
2026-03-25 07:12:09 -08:00
commit b929708190
75 changed files with 7823 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
www/reversibility_main.htm Normal file
View File

@@ -0,0 +1,63 @@
<html>
<head>
<meta http-equiv="Content-Language" content="sv">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="author" content="Kim Walden">
<title>BON method: reversibilty main</title>
<base target="_self">
<link rel="stylesheet" type="text/css" href="nn4.css">
<style type="text/css">
@import url("normal.css");
</style>
<script type="text/javascript">
<!--
function check() {
if (top.frames.length == 0 || top.frames[0].name != "banner")
top.location.href = "index.htm?reversibility";
}
//-->
</script>
</head>
<body onload="check()" bgcolor="#ffffff" alink="#33cc00" link="#0000ff" vlink="#0000ff">
<h1>Reversibility</h1>
<p>The term reversibility in the context of software development means the
possibility of propagating independent changes made to the resulting source code back
into the design and analysis models of earlier phases, so these can be kept up
to date with what is actually executed.&nbsp; </p>
<p>As any experienced developer knows, going full circle everytime a change is
to be made: first modify the higher level models, then translate these changes
into the corresponding code changes, is totally unfeasible in practice.&nbsp;
And yet, most books and papers on analysis and design of software systems
continue (at best) to pay lip service to the issue of reversibility, before
proceeding to methods and concepts that are completely non-reversible, as if the
world consisted of the toy examples elborated in the texts.</p>
<p>Since maintenance of software systems involve continuous modification of
source code, any method based on concepts that are not unambiguously
translatable to <b>and from </b>the programming constructs used in the code,
will produce high-level models that immediately start to deviate from the real
system.&nbsp; Therefore, the developers will stop trusting the models almost
from day one, and the binders containing the bubble diagrams will stay on the
shelves.&nbsp;&nbsp;&nbsp; Alternatively, a designer group will continue to talk
in terms of the bubbles, while the programmers, who are forced to make things
work in practice, will think in terms of the concepts of their language,
preventing any effective commuication between the two. </p>
<p>In short, we need to use the same basic concepts for analysis and design as
we will in our source code.&nbsp; The object-oriented abstraction has the
potential to serve as such a universal concept.&nbsp;&nbsp; But only if the
models are kept free from mismatching concepts drawn from other paradigms, such
as entity-relationship modeling and/or central emphasis on use cases.</p>
<p>My <a target="_blank" href="computer_annotated.pdf">IEEE Computer article</a>
from 1996 stating the case for reversibility can be found here.</p>
</body>
</html>