<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Software renovation: Refactoring vs Restructuring</title>
<link rel="stylesheet" type="text/css" href="../CSS/main.css">
</head>

<body>

<basefont face="Times" size="3">
<table border="0" width="100%" id="table1" cellspacing="1" cellpadding="4"  >
<tr>
<td rowspan="2" width="40%">

<p align="center"><img border="0" src="/Images/splogo.gif" width="45"  ><font face="Bernard MT Condensed" color="#FF0000" size="7">
<font color="#FF0000"><a href="/index.shtml">Softpanorama</a></font></font></p>

<center>

<font size="2" face="Arial"><b>May the source be with you, but remember the <a href="/SE/kiss.shtml">KISS principle</a> ;-) </b></font></center>
</td>
<td align="center">

<b><a href="/index.shtml"><font size="2">Home</font></a></b></td>
<td align="center">

<b><a href="/switchboard.shtml"><font size="2">Switchboard</font></a></b></td>
<td align="center">

<b><a href="/Admin/index.shtml"><font size="2">Unix Administration</font></a></b></td>
<td align="center">

<b><a href="/Commercial_linuxes/RHEL/index.shtml"><font size="2">Red Hat</font></a></b></td>
<td align="center">

<b><a href="/Net/index.shtml"><font size="2">TCP/IP Networks</font></a></b></td>
<td align="center">

<b><a href="/Skeptics/Political_skeptic/Neoliberalism/index.shtml"><font size="2">Neoliberalism</font></a></b></td>
<td align="center">

<b><a href="/Social/Toxic_managers/index.shtml"><font size="2">Toxic Managers</font></a></b></td>
</tr>
<tr>
<td colspan="7" align="center">

<b><font size="2">(slightly skeptical) Educational society promoting &quot;<a href="/Back_to_basics/index.shtml">Back to basics</a>&quot; movement against IT overcomplexity 
and&nbsp; <a href="Commercial_linuxes/RHEL/index.shtml">bastardization of classic Unix</a></font></b></td>
</tr>
</table>
<hr width="100%" noshade size="5" color="#FF0000">
<center>
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Top_banner2021 -->
<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="3389635737"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
     (adsbygoogle = window.adsbygoogle || []).push({});
</script></center>


<h1>Software renovation: Refactoring vs Restructuring</h1>

<table border="1" width="100%" bgcolor="#FFFFCC">
   <tr>
      <td width="12%" align="center">

      <p align="center"><a href="#News">News</a></p>
      </td>
      <td width="12%" align="center">

      <p align="center"><b><a href="index.shtml">Software Engineering</a></b></p>
      </td>
      <td width="12%" align="center">

      <p align="center"><a href="#Recommended_Links">Recommended Links</a></p>
      </td>
      <td width="12%" align="center"><b><a href="architecture.shtml">Real Insights into Architecture Come Only From Actual Programming</a></b></td>
      <td width="13%" align="center"><b><a href="program_understanding.shtml">Understanding</a></b> </td>
      <td width="13%" align="center"><a href="#Bibliography">&nbsp;</a><b><a href="../Algorithms/Decompilation/program_slicing.shtml">Program 
      Slicing </a></b></td>
      <td width="13%" align="center"><a href="../Copyright/index.shtml"><b>&nbsp;</b></a><b><a href="../Algorithms/Decompilation/decompilation_of_control_structures.shtml">Control 
      Flow Decompilation</a></b></td>
      <td width="13%" align="center">&nbsp;<b><a href="#Dif_Testing">Differential Testing</a></b></td>
   </tr>
   <tr>
      <td width="12%" align="center"><b>
      <a href="../Algorithms/Decompilation/peephole_refactoring_and_program_flow_decompilation.shtml">Peephole Refactoring </a></b>
      </td>
      <td width="12%" align="center"><b><a href="literate_programming.shtml">Literate Programming</a></b></td>
      <td width="12%" align="center"><a href="conway_law.shtml">Conway Law</a></td>
      <td width="12%" align="center"><a href="brooks_law.shtml">Brooks law</a></td>
      <td width="13%" align="center"><b><a href="quotes.shtml">SE quotes</a></b></td>
      <td width="13%" align="center"><b><a href="humor.shtml">Humor</a></b></td>
      <td width="13%" align="center"><a href="#Random_Findings">Random Findings</a></td>
      <td width="13%" align="center"><a href="#Etc">Etc</a></td>
   </tr>
</table>


<table border="0" width="178" height="620" align="right" cellspacing="4" bgcolor="#FFFFFF">
   <tr>
      <td>

      <table border="1" width="174" height="616" align="center" bgcolor="#FF0000">
         <tr>
            <td>
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Upper skyscaper -->
<ins class="adsbygoogle"
     style="display:inline-block;width:160px;height:600px"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="0371843916"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
            </td>
         </tr>
      </table></td>
   </tr>
</table>

<p>In 1976, Belady and Lehman formulated their ‘<i><b>Laws of Program Evolution Dynamics</b></i>’. </p>
<ul>

   <li>First, <em>a software system that is used will undergo 
continuous modification. </em></li>

   <li>Second, <em>the unstructuredness (entropy) of a system increases with time</em>, unless specific work is done to improve 
the system’s structure. </li>
</ul>

<p>This activity of improving legacy software systems is called system renovation. It aims at making existing systems more comprehensible, 
extensible, robust and reusable</p>

<p>Legacy systems are software systems that resist change. Making modification are costly. For pricing purposes there are usually three 
category of project</p>
<ol>

   <li><b>With codebase of any single isolated software component less then 1K lines of code</b>. You usually can provide reasonable 
   estimate of the cost and timeframe.&nbsp; Recoding&nbsp; in a new language often represents a viable approach (PL/1 to Java, Perl 
   to Python, etc) </li>

   <li><b>With codebase less then 10K lines of code</b>. You usually underestimate the cost and time two times. If this is the case 
   of OO codebase double this estimate again ;-) Recoding in new language still represent a viable option, but increasingly less so. 
   And it tend dramatically increase costs.&nbsp;
   <blockquote>
      <b><a name="22098046">I had a pile of C++ dropped in my lap 2 years ago.</a> (Score:3, Informative)</b> by
      <a target="_blank" href="http://slashdot.org/~Richard+Steiner">Richard Steiner (1585)</a> &lt;<a href="/cdn-cgi/l/email-protection#4d3f3e39282423283f0d3b243e24632e2220"><span class="__cf_email__" data-cfemail="3b49484f5e52555e497b4d52485215585456">[email&#160;protected]</span></a>&gt; 
      on Friday January 18, @02:02PM (<a target="_blank" href="http://ask.slashdot.org/comments.pl?sid=422996&no_d2=1&cid=22098046">#22098046</a>)
      <small><a title="http://www.visi.com/~rsteiner" href="http://www.visi.com/~rsteiner">Homepage</a>
      <a title="Friday August 04 2006, @12:01PM" href="http://slashdot.org/~Richard+Steiner/journal/">Journal</a> </small>

      <p>My main tool for figuring it all out was to use <a title="sourceforge.net" href="http://ctags.sourceforge.net/">exuberant ctags</a> 
      [sourceforge.net] to create a tags file, and <a title="nedit.org" href="http://www.nedit.org/">Nedit</a> [nedit.org] to navigate 
      through the source under Solaris, with a little grep thrown in. I also used gdb with the
      <a title="gnu.org" href="http://www.gnu.org/software/ddd/">DDD</a> [gnu.org] front-end to do a little real-time snooping. </p>

      <p>I&#39;ve since added both <a title="sourceforge.net" href="http://cscope.sourceforge.net/">cscope</a> [sourceforge.net] and
      <a title="sourceforge.net" href="http://freescope.sourceforge.net/">freescope</a> [sourceforge.net], as well as the old
      <a title="sourceforge.net" href="http://sourcenav.sourceforge.net/">Red Hat Source Navigator</a> [sourceforge.net] for good measure.</p>

      <p>I used to work at a company with a lot of Pascal and C code... It was extremely common (as in, all but a few) for programs 
      to be written entirely in <b>one</b> code file. These files would go on for 20,000 lines or more. So many lines in fact that after 
      the compiler had imported the header files at the top of the file that they would be over 65,000 lines long and the debugger would 
      crap out because it had exceeded the int that it used for line number counting. </p>
   </blockquote>
   </li>

   <li><b>With codebase over 100K lines of code. </b>Those projects can succeed if team is strong and highly dedicated. and it there 
   is no read take involved. If not they are doomed.
   <blockquote>

      <p><em>A few years back I had to maintain a large module written in C#. I had about 200K lines of code, 50 classes, zero documentation, 
      zero comments, zero error logging support, and I was expected to find and fix bugs and add functionality the day after the module 
      was handled over.</em><br>
      <br>
      So if you were never in this position, just STFU. Yeah, the code is there, but [what] is this flag for? Is this part really used, 
      or is obsolete? What are the side-effects of using that method? And so on...</p>

      <p>Eventually, I learned it, especially after some intensive debugging sessions, but it was frustrating to say the least. I would 
      have loved to have some aiding tools.</p>
   </blockquote>
   </li>

   <li><b>With codebase over 100K lines of code.</b>&nbsp; This is the level of code complexity typical for modern interpreters from 
   languages like Python and Perl with their huge libraries. The success is not given, no matter what you try and what approach you 
   choose.&nbsp; </li>
</ol>

<p>The key part of the work is investigative work to understand the thought processes of original developers.&nbsp; The involves tracing 
code in the debugger, which usually is more productive the static analysis.&nbsp; I&#39;ve always found that stepping through the debugger 
at runtime is a decent way to start making sense of a large code base. Just set a breakpoint at a point of interest, fire up the application, 
and use it as a starting point of exploring the codebase.&nbsp; This is typically how malware is analyzed.&nbsp;&nbsp; After a couple 
weeks or a month usually the technical architect of the project can start to create the map of the key components, creating a subset 
of those which can be called &quot;The most scary components/sections of the code&quot;&nbsp; Is case of OO&nbsp; codebase (which is a very small 
portion of legacy code but still happens) it can be harder to reverse-engineer the&nbsp; logic because it&#39;s distributed among various 
classes. A debugger that lets you step through running code is almost essential in this case.</p>
<blockquote>

   <p>I would suggest a slight variation on the theme. <em>Fire up the application, start it on one of its typical tasks, and then interrupt 
   it in the debugger to catch it.</em> While the process is stopped mid-flight, take note of the call stack to see which classes and 
   methods are being used. Maybe step through a few calls, then let the program run some more. </p>

   <p><em>By doing this repeatedly, you will quickly get a sense for which parts of the code see the most action, and would provide 
   the most obvious places to start studying the code base, and provide the best bang-for-buck return on your time.</em></p>
</blockquote>

<p><em>NOTE:</em> <b>This approach doesn&#39;t work for a code base with over 100K of lines of atrociously written code. You will just drown 
in it. </b>&nbsp;&quot;Large&quot; projects might have 250 source code files and thousands of functions or classes and likely a dozen or so interacting 
executable programs. Just printouts of source code that fill several bookcase shelves. </p>

<p>In large case tests are very good means that help to understand the code base. Writing a test framework with the battery of tests 
for each subsystem that interests you&nbsp; helps to understand what particular parts of the code actually do. And they when you need 
to change something you can be more sure that you didn&#39;t break anything.</p>

<p>Mitch Rosenberg of InfoVentions.net, Inc. claims that the following law exist (he calls it code or data archaeology law):</p>
<blockquote>

   <p><i>Everything that is there is there for a reason, and there are 3 possible reasons:</i></p>
   <ol>

      <li><i>It used to need to be there but no longer does</i></li>

      <li><i>It never needed to be there and the person that wrote the code had no clue</i></li>

      <li><i>It STILL needs to be there and YOU have no clue</i></li>
   </ol>

   <p><i>The corollary to this &quot;law&quot; is that, until you know which was the reason, you should NOT modify the code (or data).</i></p>
</blockquote>

<p>In other words large part of the work is simply <b>software architecture recovery</b>, the extraction of architectural information 
from lower level representations of a software system.. </p>

<p>Architecture recovery became even more necessary as typically those systems do not often have the reliable&nbsp; architectural documentation, 
and when some documentation exists it is typically reflects the version that is many versions below the current version of the system. 
Systems like <a href="http://doxygen.nl/">Doxygen</a> should definitely be used at this phase. If its in a language that Doxygen can 
understand, that&#39;s the tool I would HIGHLY recommend. You can
<a class="elRef" href="http://doxygen.nl/manual/starting.html#extract_all">configure</a> doxygen to extract the code structure from 
undocumented source files. This is very useful to quickly find your way in large source distributions. </p>

<p>Along with dynamic analysis via debugger,&nbsp; static analysis also needs to be performs. Call graph is an important element here 
(<font color="#FF0000"><b><i>For C and C++ Doxygen </i></b><i><b>&nbsp;generates caller and callee graphs for all functions.)</b></i></font> 
But even such a simple task as creation of cross reference tables of variables used and slow and painful work of understanding their 
meaning and interactions cn greatly help.&nbsp;&nbsp; </p>

<p><a href="../Algorithms/Decompilation/program_slicing.shtml">Slicing</a> and slicing tools are also very important elements of static 
analysis of the code.&nbsp; See old butstill good <a href="slicing_tool.html">The Wisconsin Program-Slicing Tool, Version 1.0.1 </a>
</p>

<p>But dynamic analysis via debugger is the key, especially in the mess that an OO system for which key developer left many years ago 
typically represents. In this case the dynamic analysis becomes an essential technique to comprehend the system behavior, object interactions, 
and hence to reconstruct its architecture. In this work, the criteria used to determine how source code entities should be clustered 
in architectural elements are mainly based on the dynamic analysis of the system, taking into account the occurrences of interaction 
patterns and types (classes and interfaces) in <a title="Use-case analysis" href="https://en.wikipedia.org/wiki/Use-case_analysis">use-case 
realizations</a>.</p>
<hr>
<table border="1" width="100%" height="350">
   <tr>
      <td width="100%" align="center" colspan="5" rowspan="4">
      <center>
      <b>Top Visited</b></center>
      <iframe src="/topupdates.shtml" width="100%" height="320">

      <p>Your browser does not support iframes.</p>
      </iframe>
      </td>
      <td bgcolor="#FFFF00" align="center"><b><a href="switchboard.shtml">Switchboard</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b><a href="/index.shtml#Latest">Latest</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b>
      <a href="https://www.google.com/search?q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:y&sa=X&ei=aML0TaHgO4fUgAedxtjzCw&ved=0CAsQpwUoBQ&biw=1256&bih=801&cad=cbv#q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:w&sa=X&ei=csL0TYHsI4LagAeKu7DPCw&ved=0CAwQpwUoAw&fp=fb58e14853731932&biw=1256&bih=801">
      Past week</a></b></td>
   </tr>
   <tr>
      <td bgcolor="#FFFF00" align="center"><b>
      <a href="https://www.google.com/search?q=site:www.softpanorama.org&hl=en&lr=&tbo=1&prmd=ivns&source=lnt&tbs=qdr:m&sa=X&ei=IMD0TdjLHMXUgQe9t6zfCw&ved=0CA0QpwUoBA">
      Past month</a></b></td>
   </tr>
</table
<hr noshade color="#FF0000" size="5">




<hr>

<h2><a name="NEWS_TOC">NEWS CONTENTS</a></h2>
<ul>
<li>20191015 : <a href="#n20191015X_learning_doxygen_for_source_code_documentation">Learning doxygen for source code  documentation</a> <i> by Arpan Sen</i>  ( Jul 29, 2008 , <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/">developer.ibm.com</a> ) </li>
<li>20191015 : <a href="#n20191015X_welcome_to_ieee_xplore_2_0_structural_epochs_in_the_complexity_of_software_over_time">Welcome to IEEE Xplore  2.0 Structural Epochs in the Complexity of Software over Time</a> <i></i>  ( <a target="_blank" href="http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=4548410&isnumber=4548393">Welcome to IEEE Xplore  2.0 Structural Epochs in the Complexity of Software over Time</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_from_legacy_to_component_software_renovation_in_three_steps">From Legacy to Component Software Renovation in Three Steps</a> <i></i>  ( <a target="_blank" href="http://www.cs.vu.nl/~daan/cwicap/">From Legacy to Component Software Renovation in Three Steps</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_interactive_software_development_and_renovation">Interactive Software Development and Renovation</a> <i></i>  ( <a target="_blank" href="http://dbs.cwi.nl:8080/cwwwi/owa/cwwwi.print_themes?ID=11">Interactive Software Development and Renovation</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_source_recovery_home_transparence">Source Recovery Home (Transparence)</a> <i></i>  ( <a target="_blank" href="http://www.source-recovery.com/">Source Recovery Home (Transparence)</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_roadmap_html_browser_based_source_navigation_and_understanding">Roadmap  HTML browser-based     source navigation and understanding. </a> <i></i>  ( <a target="_blank" href="http://www.source-recovery.com/products/roadmap-home.htm">Roadmap <font face="Arial" size="2">HTML browser-based     source navigation and understanding.</font></a>,  ) </li>
<li>20191015 : <a href="#n20191015X_companies_offering_decompilation_services">Companies offering Decompilation  Services</a> <i></i>  ( <a target="_blank" href="http://archive.csee.uq.edu.au/~csmweb/decompilation/company.html#src">Companies offering Decompilation  Services</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_a2c_software_renovation_from_assembler_370_to_cobol">A2C Software Renovation: from Assembler/370 to COBOL</a> <i></i>  ( <a target="_blank" href="http://www.cs.kun.nl/~hans/A2C/blurb.html">A2C Software Renovation: from Assembler/370 to COBOL</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_software_pdf">Software.pdf</a> <i></i>  ( <a target="_blank" href="http://www.cwi.nl/cwi/about/annual-reports/1996/AR/PDF/Software.pdf">Software.pdf</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_software_renovation_by_arie_van_deursen">Software Renovation by Arie van Deursen</a> <i></i>  ( <a target="_blank" href="http://www.ercim.org/publication/Ercim_News/enw36/van_deursen.html">Software Renovation by Arie van Deursen</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_origin_tracking_and_software_renovation">Origin Tracking and Software Renovation</a> <i></i>  ( <a target="_blank" href="http://www.dagstuhl.de/DATA/Reports/9710/node13.html">Origin Tracking and Software Renovation</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_semi_automatic_grammar_recovery_researchindex">Semi-automatic Grammar Recovery (ResearchIndex)</a> <i></i>  ( <a target="_blank" href="http://citeseer.nj.nec.com/297502.html">Semi-automatic Grammar Recovery (ResearchIndex)</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_scaffolding_for_software_renovation">Scaffolding for Software Renovation</a> <i></i>  (  ) </li>
<li>20191015 : <a href="#n20191015X_an_architecture_for_automated_software_maintenance">An Architecture for Automated Software Maintenance</a> <i></i>  ( <a target="_blank" href="http://www.objectz.com/cobolworld/ivory/asm.html">An Architecture for Automated Software Maintenance</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_time_for_triage_says_y2k_software_renovation_firm_gary_norths_y2k_links_and_forums">Time for Triage, Says Y2K Software Renovation Firm - Gary Norths  Y2K Links and Forums - Mirror- Compliance</a> <i></i>  ( <a target="_blank" href="http://www.teotwawki.com/north/1098.htm">Time for Triage, Says Y2K Software Renovation Firm - Gary North&#39;s  Y2K Links and Forums - Mirror- Compliance</a>,  ) </li>
<li>20191015 : <a href="#n20191015X_cc2e_com_2436">cc2e.com/2436</a> <i></i>  ( <a target="_blank" href="http://www.cc2e.com/2436" target="_blank">cc2e.com/2436</a>,  ) </li>
</ul>
<h2><a name="News">Old News</a> ;-) </h2>

<center><table border="0" width="100"><tr>
<td align="center"><a href="#NEWS_TOC"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_learning_doxygen_for_source_code_documentation" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_welcome_to_ieee_xplore_2_0_structural_epochs_in_the_complexity_of_software_over_time"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4>[Oct 15, 2019] <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/">Learning doxygen for source code  documentation</a> by Arpan Sen</h4>

<blockquote>
<h6>Jul 29, 2008 |  <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/">developer.ibm.com</a></h6>
 
   Maintaining and adding new features to legacy systems developed using Maintaining and adding new features to legacy systems developed 
   using <code>C/C++</code> is a daunting task. There are several facets to the problem -- understanding the existing class hierarchy 
   and global variables, the different user-defined types, and function call graph analysis, to name a few. This article discusses several 
   features of doxygen, with examples in the context of projects using <code>C/C++</code> .

   <p>However, doxygen is flexible enough to be used for software projects developed using the Python, Java, PHP, and other languages, 
   as well. The primary motivation of this article is to help extract information from <code>C/C++</code> sources, but it also briefly 
   describes how to document code using doxygen-defined tags. </p>

   <p><b>Installing doxygen</b> </p>

   <p>You have two choices for acquiring doxygen. You can download it as a pre-compiled executable file, or you can check out sources 
   from the SVN repository and build it. You have two choices for acquiring doxygen. You can download it as a pre-compiled executable 
   file, or you can check out sources from the SVN repository and build it.
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list1">Listing 1</a> shows the latter process.
   </p>

   <h5>Listing 1. Install and build doxygen sources</h5>

   <pre>
                
bash&#8209;2.05$ svn co https://doxygen.svn.sourceforge.net/svnroot/doxygen/trunk doxygen&#8209;svn

bash&#8209;2.05$ cd doxygen&#8209;svn
bash&#8209;2.05$ ./configure –prefix=/home/user1/bin
bash&#8209;2.05$ make

bash&#8209;2.05$ make install
</pre>
   Show more Note that the configure script is tailored to dump the compiled sources in /home/user1/bin (add this directory to the PATH 
   variable after the build), as not every UNIX® user has permission to write to the /usr folder. Also, you need the Note that the configure 
   script is tailored to dump the compiled sources in /home/user1/bin (add this directory to the PATH variable after the build), as 
   not every UNIX® user has permission to write to the /usr folder. Also, you need the Note that the configure script is tailored to 
   dump the compiled sources in /home/user1/bin (add this directory to the PATH variable after the build), as not every UNIX® user has 
   permission to write to the /usr folder. Also, you need the Note that the configure script is tailored to dump the compiled sources 
   in /home/user1/bin (add this directory to the PATH variable after the build), as not every UNIX® user has permission to write to 
   the /usr folder. Also, you need the <code>svn</code> utility to check out sources. <b>Generating documentation using doxygen</b> 
   To use doxygen to generate documentation of the sources, you perform three steps. To use doxygen to generate documentation of the 
   sources, you perform three steps. <b>Generate the configuration file</b> At a shell prompt, type the command doxygen -g At a shell 
   prompt, type the command doxygen -g <code>doxygen -g</code> . This command generates a text-editable configuration file called <i>
   Doxyfile</i> in the current directory. You can choose to override this file name, in which case the invocation should be doxygen 
   -g &lt;_user-specified file=&quot;file&quot; name_=&quot;name_&quot;&gt; <code>doxygen -g &lt;user-specified file name&gt;</code> , as shown in
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list2">Listing 2</a> .

   <h5>Listing 2. Generate the default configuration file</h5>

   <pre>
                
bash&#8209;2.05b$ doxygen &#8209;g
Configuration file &#39;Doxyfile&#39; created.
Now edit the configuration file and enter
  doxygen Doxyfile
to generate the documentation for your project
bash&#8209;2.05b$ ls Doxyfile
Doxyfile
</pre>
   Show more <b>Edit the configuration file</b> The configuration file is structured as The configuration file is structured as
   <code>&lt;TAGNAME&gt;</code> = <code>&lt;VALUE&gt;</code> , similar to the Make file format. Here are the most important tags:
   <ul>

      <li><code>&lt;OUTPUT_DIRECTORY&gt;</code> : You must provide a directory name here -- for example, /home/user1/documentation -- for 
      the directory in which the generated documentation files will reside. If you provide a nonexistent directory name, doxygen creates 
      the directory subject to proper user permissions.</li>

      <li><code>&lt;INPUT&gt;</code> : This tag creates a space-separated list of all the directories in which the <code>C/C++</code> source 
      and header files reside whose documentation is to be generated. For example, consider the following snippet:

      <pre>
INPUT = /home/user1/project/kernel /home/user1/project/memory
</pre>
      Show more In this case, doxygen would read in the <code xmlns="http://www.w3.org/1999/xhtml">C/C++</code> sources from these two 
      directories. If your project has a single source root directory with multiple sub-directories, specify that folder and make the
      <code>&lt;RECURSIVE&gt;</code> tag Yes . </li>

      <li><code>&lt;FILE_PATTERNS&gt;</code> : By default, doxygen searches for files with typical <code>C/C++</code> extensions such as
      <i>.c, .cc, .cpp, .h,</i> and <i>.hpp.</i> This happens when the <code>&lt;FILE_PATTERNS&gt;</code> tag has no value associated with 
      it. If the sources use different naming conventions, update this tag accordingly. For example, if a project convention is to use
      <i>.c86</i> as a <code>C</code> file extension, add this to the <code>&lt;FILE_PATTERNS&gt;</code> tag.</li>

      <li><code>&lt;RECURSIVE&gt;</code> : Set this tag to Yes if the source hierarchy is nested and you need to generate documentation for
      <code>C/C++</code> files at all hierarchy levels. For example, consider the root-level source hierarchy /home/user1/project/kernel, 
      which has multiple sub-directories such as /home/user1/project/kernel/vmm and /home/user1/project/kernel/asm. If this tag is set 
      to <i>Yes</i> , doxygen recursively traverses the hierarchy, extracting information.</li>

      <li><code>&lt;EXTRACT_ALL&gt;</code> : This tag is an indicator to doxygen to extract documentation even when the individual classes 
      or functions are undocumented. You must set this tag to Yes .</li>

      <li><code>&lt;EXTRACT_PRIVATE&gt;</code> : Set this tag to Yes . Otherwise, private data members of a class would not be included in 
      the documentation.</li>

      <li><code>&lt;EXTRACT_STATIC&gt;</code> : Set this tag to Yes . Otherwise, static members of a file (both functions and variables) would 
      not be included in the documentation.</li>
   </ul>
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list3">Listing 3</a> shows an example of a Doxyfile.

   <h5>Listing 3. Sample doxyfile with user-provided tag values</h5>

   <pre>
                
OUTPUT_DIRECTORY = /home/user1/docs
EXTRACT_ALL = yes
EXTRACT_PRIVATE = yes
EXTRACT_STATIC = yes
INPUT = /home/user1/project/kernel
#Do not add anything here unless you need to. Doxygen already covers all 
#common formats like .c/.cc/.cxx/.c++/.cpp/.inl/.h/.hpp
FILE_PATTERNS = 
RECURSIVE = yes
</pre>
   Show more <b>Run doxygen</b> Run doxygen in the shell prompt as Run doxygen in the shell prompt as <code>doxygen Doxyfile</code> 
   (or with whatever file name you&#39;ve chosen for the configuration file). Doxygen issues several messages before it finally produces 
   the documentation in Hypertext Markup Language (HTML) and Latex formats (the default). In the folder that the <code>&lt;OUTPUT_DIRECTORY&gt;</code> 
   tag specifies, two sub-folders named <i>html</i> and <i>latex</i> are created as part of the documentation-generation process.
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list4">Listing 4</a> shows a sample doxygen run log.

   <h5>Listing 4. Sample log output from doxygen</h5>

   <pre>
                
Searching for include files...
Searching for example files...
Searching for images...
Searching for dot files...
Searching for files to exclude
Reading input files...
Reading and parsing tag files
Preprocessing /home/user1/project/kernel/kernel.h
 
Read 12489207 bytes
Parsing input...
Parsing file /project/user1/project/kernel/epico.cxx
 
Freeing input...
Building group list...
..
Generating docs for compound MemoryManager::ProcessSpec
 
Generating docs for namespace std
Generating group index...
Generating example index...
Generating file member index...
Generating namespace member index...
Generating page index...
Generating graph info page...
Generating search index...
Generating style sheet...
</pre>
   Show more <b>Documentation output formats</b> Doxygen can generate documentation in several output formats other than HTML. You can 
   configure doxygen to produce documentation in the following formats: Doxygen can generate documentation in several output formats 
   other than HTML. You can configure doxygen to produce documentation in the following formats:
   <ul>

      <li>UNIX man pages: Set the <code>&lt;GENERATE_MAN&gt;</code> tag to Yes . By default, a sub-folder named <i>man</i> is created within 
      the directory provided using <code>&lt;OUTPUT_DIRECTORY&gt;</code> , and the documentation is generated inside the folder. You must 
      add this folder to the MANPATH environment variable.</li>

      <li>Rich Text Format (RTF): Set the <code>&lt;GENERATE_RTF&gt;</code> tag to Yes . Set the <code>&lt;RTF_OUTPUT&gt;</code> to wherever you 
      want the .rtf files to be generated -- by default, the documentation is within a sub-folder named <i>rtf</i> within the OUTPUT_DIRECTORY. 
      For browsing across documents, set the <code>&lt;RTF_HYPERLINKS&gt;</code> tag to Yes . If set, the generated .rtf files contain links 
      for cross-browsing.</li>

      <li>Latex: By default, doxygen generates documentation in Latex and HTML formats. The <code>&lt;GENERATE_LATEX&gt;</code> tag is set 
      to Yes in the default Doxyfile. Also, the <code>&lt;LATEX_OUTPUT&gt;</code> tag is set to Latex, which implies that a folder named
      <i>latex</i> would be generated inside OUTPUT_DIRECTORY, where the Latex files would reside.</li>

      <li>Microsoft® Compiled HTML Help (CHM) format: Set the <code>&lt;GENERATE_HTMLHELP&gt;</code> tag to Yes . Because this format is not 
      supported on UNIX platforms, doxygen would only generate a file named <i>index.hhp</i> in the same folder in which it keeps the 
      HTML files. You must feed this file to the HTML help compiler for actual generation of the .chm file.</li>

      <li>Extensible Markup Language (XML) format: Set the <code>&lt;GENERATE_XML&gt;</code> tag to Yes . (Note that the XML output is still 
      a work in progress for the doxygen team.)</li>
   </ul>
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list5">Listing 5</a> provides an example of a Doxyfile 
   that generates documentation in all the formats discussed.

   <h5>Listing 5. Doxyfile with tags for generating documentation in several formats</h5>

   <pre>
                
#for HTML 
GENERATE_HTML = YES
HTML_FILE_EXTENSION = .htm

#for CHM files
GENERATE_HTMLHELP = YES

#for Latex output
GENERATE_LATEX = YES
LATEX_OUTPUT = latex

#for RTF
GENERATE_RTF = YES
RTF_OUTPUT = rtf 
RTF_HYPERLINKS = YES

#for MAN pages
GENERATE_MAN = YES
MAN_OUTPUT = man
#for XML
GENERATE_XML = YES
</pre>
   Show more <b>Special tags in doxygen</b> Doxygen contains a couple of special tags. Doxygen contains a couple of special tags. <b>
   Preprocessing C/C++ code</b> First, doxygen must preprocess First, doxygen must preprocess <code>C/C++</code> code to extract information. 
   By default, however, it does only partial preprocessing -- conditional compilation statements ( <code>#if #endif</code> ) are evaluated, 
   but macro expansions are not performed. Consider the code in
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list6">Listing 6</a> .

   <h5>Listing 6. Sample C code that makes use of macros</h5>

   <pre>
                
#include &lt;cstring&gt;
#include &lt;rope&gt;

#define USE_ROPE

#ifdef USE_ROPE
  #define STRING std::rope
#else
  #define STRING std::string
#endif

static STRING name;
</pre>
   Show more With With With With <code>&lt;USE_ROPE&gt;</code> defined in sources, generated documentation from doxygen looks like this:

   <pre>
Defines
    #define USE_ROPE
    #define STRING std::rope

Variables
    static STRING name
</pre>
   Show more Here, you see that doxygen has performed a conditional compilation but has not done a macro expansion of Here, you see 
   that doxygen has performed a conditional compilation but has not done a macro expansion of Here, you see that doxygen has performed 
   a conditional compilation but has not done a macro expansion of Here, you see that doxygen has performed a conditional compilation 
   but has not done a macro expansion of <code>STRING</code> . The <code>&lt;ENABLE_PREPROCESSING&gt;</code> tag in the Doxyfile is set by 
   default to <i>Yes</i> . To allow for macro expansions, also set the <code>&lt;MACRO_EXPANSION&gt;</code> tag to Yes . Doing so produces 
   this output from doxygen:

   <pre>
Defines
   #define USE_ROPE
    #define STRING std::string

Variables
    static std::rope name
</pre>
   Show more If you set the If you set the If you set the If you set the <code>&lt;ENABLE_PREPROCESSING&gt;</code> tag to <i>No</i> , the 
   output from doxygen for the earlier sources looks like this:

   <pre>
Variables
    static STRING name
</pre>
   Show more Note that the documentation now has no definitions, and it is not possible to deduce the type of Note that the documentation 
   now has no definitions, and it is not possible to deduce the type of Note that the documentation now has no definitions, and it is 
   not possible to deduce the type of Note that the documentation now has no definitions, and it is not possible to deduce the type 
   of <code>STRING</code> . It thus makes sense always to set the <code>&lt;ENABLE_PREPROCESSING&gt;</code> tag to Yes . As part of the documentation, 
   it might be desirable to expand only specific macros. For such purposes, along setting As part of the documentation, it might be 
   desirable to expand only specific macros. For such purposes, along setting As part of the documentation, it might be desirable to 
   expand only specific macros. For such purposes, along setting <code>&lt;ENABLE_PREPROCESSING&gt;</code> and <code>&lt;MACRO_EXPANSION&gt;</code> 
   to Yes , you must set the <code>&lt;EXPAND_ONLY_PREDEF&gt;</code> tag to Yes (this tag is set to <i>No</i> by default) and provide the 
   macro details as part of the <code>&lt;PREDEFINED&gt;</code> or <code>&lt;EXPAND_AS_DEFINED&gt;</code> tag. Consider the code in
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list7">Listing 7</a> , where only the macro <code>
   CONTAINER</code> would be expanded.

   <h5>Listing 7. C source with multiple macros</h5>

   <pre>
                
#ifdef USE_ROPE
  #define STRING std::rope
#else
  #define STRING std::string
#endif

#if ALLOW_RANDOM_ACCESS == 1
  #define CONTAINER std::vector
#else
  #define CONTAINER std::list
#endif

static STRING name;
static CONTAINER gList;
</pre>
   Show more <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list8">Listing 8</a> shows the configuration 
   file.

   <h5>Listing 8. Doxyfile set to allow select macro expansions</h5>

   <pre>
                
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
EXPAND_AS_DEFINED = CONTAINER

</pre>
   Show more Here&#39;s the doxygen output with only Here&#39;s the doxygen output with only Here&#39;s the doxygen output with only Here&#39;s the 
   doxygen output with only <code>CONTAINER</code> expanded:

   <pre>
Defines
#define STRING   std::string 
#define CONTAINER   std::list

Variables
static STRING name
static std::list gList
</pre>
   Show more Notice that only the Notice that only the Notice that only the Notice that only the <code>CONTAINER</code> macro has been 
   expanded. Subject to <code>&lt;MACRO_EXPANSION&gt;</code> and <code>&lt;EXPAND_AS_DEFINED&gt;</code> both being <i>Yes</i> , the <code>&lt;EXPAND_AS_DEFINED&gt;</code> 
   tag selectively expands only those macros listed on the right-hand side of the equality operator. As part of preprocessing, the final 
   tag to note is As part of preprocessing, the final tag to note is As part of preprocessing, the final tag to note is <code>&lt;PREDEFINED&gt;</code> 
   . Much like the same way you use the <code>-D</code> switch to pass the G++ compiler preprocessor definitions, you use this tag to 
   define macros. Consider the Doxyfile in <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list9">Listing 
   9</a> .

   <h5>Listing 9. Doxyfile with macro expansion tags defined</h5>

   <pre>
                
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
EXPAND_AS_DEFINED = 
PREDEFINED = USE_ROPE= \
                             ALLOW_RANDOM_ACCESS=1
</pre>
   Show more Here&#39;s the doxygen-generated output: Here&#39;s the doxygen-generated output: Here&#39;s the doxygen-generated output: Here&#39;s the 
   doxygen-generated output:

   <pre>
Defines
#define USE_CROPE 
#define STRING   std::rope 
#define CONTAINER   std::vector

Variables
static std::rope name 
static std::vector gList
</pre>
   Show more When used with the When used with the When used with the When used with the <code>&lt;PREDEFINED&gt;</code> tag, macros should 
   be defined as &lt;_macro name_=&quot;name_&quot;&gt;=&lt;_value_&gt; <code>&lt;macro name&gt;=&lt;value&gt;</code> . If no value is provided -- as in the case of simple
   <code>#define</code> -- just using &lt;_macro name_=&quot;name_&quot;&gt;=&lt;_spaces_&gt; <code>&lt;macro name&gt;=&lt;spaces&gt;</code> suffices. Separate multiple 
   macro definitions by spaces or a backslash ( <code>\</code> ). <b>Excluding specific files or directories from the documentation 
   process</b> In the In the <code>&lt;EXCLUDE&gt;</code> tag in the Doxyfile, add the names of the files and directories for which documentation 
   should not be generated separated by spaces. This comes in handy when the root of the source hierarchy is provided and some sub-directories 
   must be skipped. For example, if the root of the hierarchy is src_root and you want to skip the examples/ and test/memoryleaks folders 
   from the documentation process, the Doxyfile should look like
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list10">Listing 10</a> .

   <h5>Listing 10. Using the EXCLUDE tag as part of the Doxyfile</h5>

   <pre>
                
INPUT = /home/user1/src_root
EXCLUDE = /home/user1/src_root/examples /home/user1/src_root/test/memoryleaks

</pre>
   Show more <b>Generating graphs and diagrams</b> By default, the Doxyfile has the By default, the Doxyfile has the <code>&lt;CLASS_DIAGRAMS&gt;</code> 
   tag set to Yes . This tag is used for generation of class hierarchy diagrams. The following tags in the Doxyfile deal with generating 
   diagrams:
   <ul>

      <li><code>&lt;CLASS_DIAGRAMS&gt;</code> : The default tag is set to Yes in the Doxyfile. If the tag is set to No , diagrams for inheritance 
      hierarchy would not be generated.</li>

      <li><code>&lt;HAVE_DOT&gt;</code> : If this tag is set to Yes , doxygen uses the dot tool to generate more powerful graphs, such as 
      collaboration diagrams that help you understand individual class members and their data structures. Note that if this tag is set 
      to Yes , the effect of the <code>&lt;CLASS_DIAGRAMS&gt;</code> tag is nullified.</li>

      <li><code>&lt;CLASS_GRAPH&gt;</code> : If the <code>&lt;HAVE_DOT&gt;</code> tag is set to Yes along with this tag, the inheritance hierarchy 
      diagrams are generated using the <code>dot</code> tool and have a richer look and feel than what you&#39;d get by using only <code>
      &lt;CLASS_DIAGRAMS&gt;</code> .</li>

      <li><code>&lt;COLLABORATION_GRAPH&gt;</code> : If the <code>&lt;HAVE_DOT&gt;</code> tag is set to Yes along with this tag, doxygen generates 
      a collaboration diagram (apart from an inheritance diagram) that shows the individual class members (that is, containment) and 
      their inheritance hierarchy.</li>
   </ul>
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list11">Listing 11</a> provides an example using 
   a few data structures. Note that the <code>&lt;HAVE_DOT&gt;</code> , <code>&lt;CLASS_GRAPH&gt;</code> , and <code>&lt;COLLABORATION_GRAPH&gt;</code> 
   tags are all set to <i>Yes</i> in the configuration file.

   <h5>Listing 11. Interacting C classes and structures</h5>

   <pre>
                
struct D {
  int d;
};

class A {
  int a;
};

class B : public A {
  int b;
};

class C : public B {
  int c;
  D d;
};
</pre>
   Show more <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#fig1">Figure 1</a> shows the output from 
   doxygen.

   <h5>Figure 1. The Class inheritance graph and collaboration graph generated using the dot tool</h5>
   <b>Code documentation style</b> So far, you&#39;ve used doxygen to extract information from code that is otherwise undocumented. However, 
   doxygen also advocates documentation style and syntax, which helps it generate more detailed documentation. This section discusses 
   some of the more common tags doxygen advocates using as part of So far, you&#39;ve used doxygen to extract information from code that 
   is otherwise undocumented. However, doxygen also advocates documentation style and syntax, which helps it generate more detailed 
   documentation. This section discusses some of the more common tags doxygen advocates using as part of <code>C/C++</code> code. For 
   further details, see resources on the right. Every code item has two kinds of descriptions: one brief and one detailed. Brief descriptions 
   are typically single lines. Functions and class methods have a third kind of description known as the Every code item has two kinds 
   of descriptions: one brief and one detailed. Brief descriptions are typically single lines. Functions and class methods have a third 
   kind of description known as the Every code item has two kinds of descriptions: one brief and one detailed. Brief descriptions are 
   typically single lines. Functions and class methods have a third kind of description known as the <i>in-body description,</i> which 
   is a concatenation of all comment blocks found within the function body. Some of the more common doxygen tags and styles of commenting 
   are:
   <ul>

      <li>Brief description: Use a single-line <code>C++</code> comment, or use the <code>&lt;\brief&gt;</code> tag.</li>

      <li>Detailed description: Use JavaDoc-style commenting <code>/** test */</code> (note the two asterisks [ <code>*</code> ] in 
      the beginning) or the Qt-style <code>/*! text */</code> .</li>

      <li>In-body description: Individual <code>C++</code> elements like classes, structures, unions, and namespaces have their own 
      tags, such as <code>&lt;\class&gt;</code> , <code>&lt;\struct&gt;</code> , <code>&lt;\union&gt;</code> , and <code>&lt;\namespace&gt;</code> .</li>
   </ul>
   To document global functions, variables, and enum types, the corresponding file must first be documented using the To document global 
   functions, variables, and enum types, the corresponding file must first be documented using the <code>&lt;\file&gt;</code> tag.
   <a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/#list12">Listing 12</a> provides an example that discusses 
   item 4 with a function tag ( <code>&lt;\fn&gt;</code> ), a function argument tag ( <code>&lt;\param&gt;</code> ), a variable name tag ( <code>
   &lt;\var&gt;</code> ), a tag for <code>#define</code> ( <code>&lt;\def&gt;</code> ), and a tag to indicate some specific issues related to a 
   code snippet ( <code>&lt;\warning&gt;</code> ).

   <h5>Listing 12. Typical doxygen tags and their use</h5>
   <blockquote>

      <pre>
                
/&#8727;! \file globaldecls.h
      \brief Place to look for global variables, enums, functions
           and macro definitions
  &#8727;/

/&#8727;&#8727; \var const int fileSize
      \brief Default size of the file on disk
  &#8727;/
const int fileSize = 1048576;

/&#8727;&#8727; \def SHIFT(value, length)
      \brief Left shift value by length in bits
  &#8727;/
#define SHIFT(value, length) ((value) &lt;&lt; (length))

/&#8727;&#8727; \fn bool check_for_io_errors(FILE&#8727; fp)
      \brief Checks if a file is corrupted or not
      \param fp Pointer to an already opened file
      \warning Not thread safe!
  &#8727;/
bool check_for_io_errors(FILE&#8727; fp);
</pre>
      Show more

      <p>Here&#39;s how the generated documentation looks:</p>

      <pre>
Defines
#define SHIFT(value, length)   ((value) &lt;&lt; (length))  
             Left shift value by length in bits.

Functions
bool check_for_io_errors (FILE &#8727;fp)  
        Checks if a file is corrupted or not.

Variables
const int fileSize = 1048576;
Function Documentation
bool check_for_io_errors (FILE&#8727; fp)
Checks if a file is corrupted or not.

Parameters
              fp: Pointer to an already opened file

Warning
Not thread safe!
</pre>
      Show more <b>Conclusion</b>

      <p>This article discusses how doxygen can extract a lot of relevant information from legacy <code>C/C++</code> code. If the code 
      is documented using doxygen tags, doxygen generates output in an easy-to-read format. Put to good use, doxygen is a ripe candidate 
      in any developer&#39;s arsenal for maintaining and managing legacy systems.</p>
   </blockquote>
   <!--TAGS: .  -->

</blockquote>


</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_learning_doxygen_for_source_code_documentation"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_welcome_to_ieee_xplore_2_0_structural_epochs_in_the_complexity_of_software_over_time" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_from_legacy_to_component_software_renovation_in_three_steps"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=4548410&isnumber=4548393">Welcome to IEEE Xplore 
2.0 Structural Epochs in the Complexity of Software over Time</a></h4>
<blockquote>

   <p>A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open 
   source software products through their different releases. The analysis found that, as these software products evolved, a large proportion 
   of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural 
   elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring 
   efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, 
   design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then 
   mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software 
   applications at the design or architectural level could be necessary. </p>
</blockquote>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_welcome_to_ieee_xplore_2_0_structural_epochs_in_the_complexity_of_software_over_time"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_from_legacy_to_component_software_renovation_in_three_steps" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_interactive_software_development_and_renovation"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.cs.vu.nl/~daan/cwicap/">From Legacy to Component Software Renovation in Three Steps</a> -- junk 
???</h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_from_legacy_to_component_software_renovation_in_three_steps"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_interactive_software_development_and_renovation" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_source_recovery_home_transparence"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://dbs.cwi.nl:8080/cwwwi/owa/cwwwi.print_themes?ID=11">Interactive Software Development and Renovation</a></h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_interactive_software_development_and_renovation"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_source_recovery_home_transparence" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_roadmap_html_browser_based_source_navigation_and_understanding"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.source-recovery.com/">Source Recovery Home (Transparence)</a></h4>
<ul>

   <li>

   </em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_source_recovery_home_transparence"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_roadmap_html_browser_based_source_navigation_and_understanding" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_companies_offering_decompilation_services"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.source-recovery.com/products/roadmap-home.htm">Roadmap <font face="Arial" size="2">HTML browser-based 
   source navigation and understanding.</font></a></h4>
   </li>
</ul>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_roadmap_html_browser_based_source_navigation_and_understanding"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_companies_offering_decompilation_services" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_a2c_software_renovation_from_assembler_370_to_cobol"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://archive.csee.uq.edu.au/~csmweb/decompilation/company.html#src">Companies offering Decompilation 
Services</a></h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_companies_offering_decompilation_services"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_a2c_software_renovation_from_assembler_370_to_cobol" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_software_pdf"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.cs.kun.nl/~hans/A2C/blurb.html">A2C Software Renovation: from Assembler/370 to COBOL</a></h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_a2c_software_renovation_from_assembler_370_to_cobol"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_software_pdf" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_software_renovation_by_arie_van_deursen"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.cwi.nl/cwi/about/annual-reports/1996/AR/PDF/Software.pdf">Software.pdf</a> -- software renovation</h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_software_pdf"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_software_renovation_by_arie_van_deursen" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_origin_tracking_and_software_renovation"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.ercim.org/publication/Ercim_News/enw36/van_deursen.html">Software Renovation by Arie van Deursen</a></h4>
<blockquote>

   <p><b>In 1976, Belady and Lehman formulated their 'Laws of Program Evolution Dynamics'. First, a software system that is used will 
   undergo continuous modification. Second, the unstructuredness (entropy) of a system increases with time, unless specific work is 
   done to improve the system's structure. This activity of improving legacy software systems is called system renovation. It aims at 
   making existing systems more comprehensible, extensible, robust and reusable.</b>
<p>
   Due to the fact that a typical industrial or governmental organization has millions of lines of legacy code in continuous maintenance, 
   well-applied software renovation can lead to significant information technology budget savings. For that reason, in 1996 Dutch bank 
   ABN AMRO and Dutch software house Roccade commissioned a renovation research project. The research was carried out by CWI, the University 
   of Amsterdam, and ID Research. The goals of the project included the development of a generic renovation architecture, as well as 
   application of this architecture to actual renovation problems.
<p>
   Of the various facets of software renovation - such as visualization, database analysis, domain knowledge, and so on - an enabling 
   factor is the analysis and transformation of legacy sources. Since such source code analysis has much in common with compilation 
   (in which sources are analyzed with the purpose of translating them into assembly code), many results from the area of programming 
   language technology could be reused. Of great significance for software renovation are, for example, lexical source code analysis, 
   parsing, dataflow analysis, type inference, etc.</p>

   <p><b>Program Transformations</b></p>

   <p>Software renovation at the source code level includes automated program transformations for the purpose of step-by-step code improvement. 
   In this project, we successfully applied transformations to COBOL programs, dealing with goto elimination, dialect migration (between 
   COBOL-85 and COBOL-74) and modifications in the conventions for calling library utilities.</p>

   <p>To make this possible, we developed a COBOL grammar, instantiated the ASF+SDF Meta-Environment with this grammar to obtain a COBOL 
   parser and pretty printer, and designed term rewriting rules describing the desired transformations. The resulting system is capable 
   of automatically performing the desired transformations on hundreds of thousands of lines of code, yielding a fully automatic transformation 
   factory. </p>
</blockquote>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_software_renovation_by_arie_van_deursen"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_origin_tracking_and_software_renovation" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_semi_automatic_grammar_recovery_researchindex"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.dagstuhl.de/DATA/Reports/9710/node13.html">Origin Tracking and Software Renovation</a></h4>
<blockquote>

   <p>Legacy systems are software systems that resist change. Software renovation is an activity aiming at improving legacy systems 
   such that become more adaptable, or at actually carrying out required mass modifications. A typical renovation is the year-2000 problem. 
   Tools for carrying out year-2000 conversions look for initial date infections (seeds, such as suspicious keywords), propagate these 
   through MOVEs and CALLs, try to reduce the number of infections found, and then (semi)-automatically modify the code using a widening 
   or windowing approach.</p>

   <p>Of great importance for year-2000 conversions and software renovation is an accurate data flow analysis tool that can be easily 
   connected to all source languages used in the system to be renovated. In the context of the ASF+SDF formalism, the DHAL Data Flow 
   High Abstraction Language has been proposed. Languages are easily mapped to DHAL and on top of DHAL several elementary data flow 
   operations such as goto elimination and alias propagation have been defined. </p>

   <p>Origin tracking is a general technique concerned with linking back analysis results, obtained for example from DHAL operations 
   to the original source code. For transformations expressed in a functional style (using, e.g., term rewriting), origin information 
   can be maintained automatically. For each reduction, origin annotations in the reduct are constructed in a way that depends on the 
   form of the rewrite rule applied. We discuss several approaches (syntax-directed, common subterms, collapse-variables, any-to-top, 
   non-linear rules), as well as their use in typical specifications occurring in a renovation setting.</p>
</blockquote>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_origin_tracking_and_software_renovation"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_semi_automatic_grammar_recovery_researchindex" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_scaffolding_for_software_renovation"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://citeseer.nj.nec.com/297502.html">Semi-automatic Grammar Recovery (ResearchIndex)</a></h4>
<blockquote>

   <p><b><i>6.5</i></b>: <a target="_blank" href="http://citeseer.nj.nec.com/300448.html">How to Implement the Future? - C. Verhoef</a>
   <font face="Arial,Helvetica,Geneva" size="-1"><font color="#000000">H</font></font>
   <a target="_blank" href="http://citeseer.nj.nec.com/correct/300448"><font color="#6f6f6f">(Correct)</font></a><br>
   <b><i>4.9</i></b>: <a target="_blank" href="http://citeseer.nj.nec.com/297502.html">Semi-automatic Grammar Recovery - R. Lämmel, 
   C. Verhoef</a> <font face="Arial,Helvetica,Geneva" size="-1"><font color="#000000">H</font></font>
   <a target="_blank" href="http://citeseer.nj.nec.com/correct/297502"><font color="#6f6f6f">(Correct)</font></a><br>
   <b><i>1.8</i></b>: <a target="_blank" href="http://citeseer.nj.nec.com/122732.html">Research Issues in the Renovation of Legacy Systems 
   - Arie van Deursen, Paul Klint.. (1999)</a> </p>
</blockquote>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_semi_automatic_grammar_recovery_researchindex"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_scaffolding_for_software_renovation" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_an_architecture_for_automated_software_maintenance"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4>Scaffolding for Software Renovation</h4>
<blockquote>

   <p><b>Alex Sellink and Chris Verhoef</b><br>
   <i>University of Amsterdam</i></p>

   <p>We discuss an approach that explores the use of scaffolding of source code to facilitate its renovation. We show that scaffolding 
   is a useful paradigm for software renovation. We designed syntax and semantics for scaffolding, that enables all relevant applications 
   of scaffolding.</p>

   <p>The automatic generation of extensions to a normal grammar, so that the resulting extension grammar can parse code with scaffolding, 
   is discussed. We used the scaffolding paradigm itself to implement the generation process, thereby showing that our approach towards 
   scaffolding is also useful in software development. Finally, we discuss real-world applications of scaffolding for software renovation, 
   in both our own work and work from people in the reengineering IT industry.</p>

   <p>Keywords: Reengineering, System renovation, Software renovation factories, Language description development, Grammar reengineering, 
   Scaffolding, Computer aided language engineering (CALE)</p>

   <p><font size="2"><b>Proceedings of the Conference on Software Maintenance and Reengineering</b></font><br>
   <font size="2"><i>Copyright (c) 1998 Institute of Electrical and Electronics Engineers, Inc. All rights reserved.</i></font></p>
</blockquote>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_scaffolding_for_software_renovation"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_an_architecture_for_automated_software_maintenance" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_time_for_triage_says_y2k_software_renovation_firm_gary_norths_y2k_links_and_forums"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.objectz.com/cobolworld/ivory/asm.html">An Architecture for Automated Software Maintenance</a></h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_an_architecture_for_automated_software_maintenance"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_time_for_triage_says_y2k_software_renovation_firm_gary_norths_y2k_links_and_forums" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#n20191015X_cc2e_com_2436"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.teotwawki.com/north/1098.htm">Time for Triage, Says Y2K Software Renovation Firm - Gary North&#39;s 
Y2K Links and Forums - Mirror- Compliance</a></h4>

</em></b></i><center><table border="0" width="100"><tr>
<td align="center"><a href="#n20191015X_time_for_triage_says_y2k_software_renovation_firm_gary_norths_y2k_links_and_forums"><img border="0" src="/Images/up.png" width="16" height="16"></a></td>
<td align="center"><a name="n20191015X_cc2e_com_2436" href="#NEWS_TOC"><img border="0" src="/Images/home.gif" width="16" height="18"></a></td>
<td align="center"><a href="#NEWS_TOC"><img border="0" src="/Images/down.png" width="16" height="16"></a></td>
</tr></table></center>

<h4><a target="_blank" href="http://www.cc2e.com/2436" target="_blank">cc2e.com/2436</a></h4>
<blockquote>

   <p><b>Contents</b></p>
   <ul>

      <li>

      <p><a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec1#ch24lev1sec1">Kinds of Software Evolution</a>
      <a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec1#ch24lev1sec1">page 564</a></p>
      </li>

      <li>

      <p><a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec2#ch24lev1sec2">Introduction to Refactoring</a>
      <a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec2#ch24lev1sec2">page 565</a></p>
      </li>

      <li>

      <p><a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec3#ch24lev1sec3">Specific Refactorings</a>
      <a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec3#ch24lev1sec3">page 571</a></p>
      </li>

      <li>

      <p><a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec4#ch24lev1sec4">Refactoring Safely</a>
      <a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec4#ch24lev1sec4">page 579</a></p>
      </li>

      <li>

      <p><a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec5#ch24lev1sec5">Refactoring Strategies</a>
      <a href="software_renovation.shtml?xmlid=0735619670/ch24lev1sec5#ch24lev1sec5">page 582</a></p>
      </li>
   </ul>

   <p><b>Related Topics</b></p>
   <ul>

      <li>

      <p>Tips for fixing defects: <a href="software_renovation.shtml?xmlid=0735619670/ch23lev1sec3#ch23lev1sec3">Section 23.3</a></p>
      </li>

      <li>

      <p>Code-tuning approach: <a href="software_renovation.shtml?xmlid=0735619670/ch25lev1sec6#ch25lev1sec6">Section 25.6</a></p>
      </li>

      <li>

      <p>Design in construction: <a href="software_renovation.shtml?xmlid=0735619670/ch05#ch05">Chapter 5</a></p>
      </li>

      <li>

      <p>Working classes: <a href="software_renovation.shtml?xmlid=0735619670/ch06#ch06">Chapter 6</a></p>
      </li>

      <li>

      <p>High-quality routines: <a href="software_renovation.shtml?xmlid=0735619670/ch07#ch07">Chapter 7</a></p>
      </li>

      <li>

      <p>Collaborative construction: <a href="software_renovation.shtml?xmlid=0735619670/ch21#ch21">Chapter 21</a></p>
      </li>

      <li>

      <p>Developer testing: <a href="software_renovation.shtml?xmlid=0735619670/ch22#ch22">Chapter 22</a></p>
      </li>

      <li>

      <p>Areas likely to change: &quot;<a href="software_renovation.shtml?xmlid=0735619670/ch05lev1sec3#ch05lev2sec16">Identify Areas Likely 
      to Change</a>&quot; in <a href="software_renovation.shtml?xmlid=0735619670/ch05lev1sec3#ch05lev1sec3">Section 5.3</a></p>
      </li>
   </ul>

   <p><b>Myth:</b> a well-managed software project conducts methodical requirements development and defines a stable list of the program&#39;s 
   responsibilities. Design follows requirements, and it is done carefully so that coding can proceed linearly, from start to finish, 
   implying that most of the code can be written once, tested, and forgotten. According to the myth, the only time that the code is 
   significantly modified is during the software-maintenance phase, something that happens only after the initial version of a system 
   has been delivered.</p>
   <blockquote>

      <p>All successful software gets changed.</p>

      <p>-Fred Brooks</p>
   </blockquote>

   <p><b>Reality:</b> code evolves substantially during its initial development. Many of the changes seen during initial coding are 
   at least as dramatic as changes seen during maintenance. Coding, debugging, and unit testing consume between 30 to 65 percent of 
   the effort on a typical project, depending on the project&#39;s size. (See
   <a href="software_renovation.shtml?xmlid=0735619670/ch27#ch27">Chapter 27</a>, &quot;<a href="software_renovation.shtml?xmlid=0735619670/ch27#ch27">How 
   Program Size Affects Construction</a>,&quot; for details.) If coding and unit testing were straightforward processes, they would consume 
   no more than 20–30 percent of the total effort on a project. Even on well-managed projects, however, requirements change by about 
   one to four percent per month (Jones 2000). Requirements changes invariably cause corresponding code changes-sometimes substantial 
   code changes.</p>

   <p>Another reality: modern development practices increase the potential for code changes during construction. In older life cycles, 
   the focus-successful or not-was on avoiding code changes. More modern approaches move away from coding predictability. Current approaches 
   are more code-centered, and over the life of a project, you can expect code to evolve more than ever.</p>
</blockquote>

</em></b></i><h2><a name="Recommended_Links">Recommended Links</a></h2>
<table border="0" width="100%" height="220">
<tr>
<td width="100%" align="center">	

<h3>Google matched content</h3>
<script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script><script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle"
     style="display:block"
     data-ad-format="autorelaxed"
     data-ad-client="ca-pub-4031247137266443"
     data-ad-slot="1626659014"></ins>
<script>
     (adsbygoogle = window.adsbygoogle || []).push({});
</script>
</td>
</table>
<h3>Softpanorama Recommended</h3>


<h3><a name="Top_articles">Top articles</a></h3><h3><a name="Sites">Sites</a></h3>

<p><a target="_blank" href="https://developer.ibm.com/articles/au-learningdoxygen/">Learning doxygen for source code documentation – IBM Developer</a> 
By Arpan Sen; July 29, 2008</p>

<p><a target="_blank" href="https://stackoverflow.com/questions/10952689/code-ported-from-one-to-another-language-licensing">Code ported from one to 
another language - licensing - Stack Overflow</a></p>

<p><a target="_blank" href="https://en.wikipedia.org/wiki/Porting">Porting - Wikipedia</a></p>
<hr>
<hr noshade color="#FF0000" size="5">

<h2><a name="Etc">Etc</a></h2>

<p><b>Society</b></p>
<blockquote>

<p><b><a href="/Skeptics/groupthink.shtml"><font size="2">Groupthink</font></a><font size="2"> :
<a href="/Skeptics/Political_skeptic/Two_party_system_as_poliarchy/index.shtml">Two Party System 
as Polyarchy</a> : 
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Corruption_of_regulators/index.shtml">
Corruption of Regulators</a> :
<a href="/Social/Bureaucracy/index.shtml">Bureaucracies</a> :
<a href="/Social/Toxic_managers/Micromanagers/understanding_micromanagers.shtml">Understanding Micromanagers 
and Control Freaks</a> : <a href="/Social/Toxic_managers/index.shtml">Toxic Managers</a> :&nbsp;&nbsp;
<a href="/Skeptics/Pseudoscience/harvard_mafia.shtml">Harvard Mafia</a> :
<a href="/Social/Toxic_managers/Communication/diplomatic_communication.shtml">Diplomatic Communication</a> 
: <a href="/Social/Toxic_managers/surviving_a_bad_performance_review.shtml">Surviving a Bad Performance 
Review</a> : <a href="/Skeptics/Financial_skeptic/index.shtml">Insufficient Retirement Funds as 
Immanent Problem of Neoliberal Regime</a> : <a href="/Skeptics/index.shtml">PseudoScience</a> :
<a href="/Skeptics/Political_skeptic/index.shtml">Who Rules America</a> :
<a href="/Skeptics/Political_skeptic/Neoliberalism/index.shtml">Neoliberalism
</a>&nbsp;: <a href="/Skeptics/Political_skeptic/Elite_theory/iron_law_of_oligarchy.shtml">The Iron 
Law of Oligarchy</a> : </font><a href="/Skeptics/Political_skeptic/libertarianism.shtml">
<font size="2">Libertarian Philosophy</font></a></b></p>
</blockquote>

<p><b>Quotes</b></p>
<blockquote>

<p><b><font size="2" face="Arial"> 
<a href="/Skeptics/Quotes/war_and_peace_quotes.shtml">War and Peace</a> </font>
<font face="Arial"><font size="2">: <a href="/Skeptics/Quotes/financial_quotes.shtml">Skeptical 
Finance</a> : <a href="/Skeptics/Quotes/famous_galbraith_quotes.shtml">John 
Kenneth Galbraith</a> :<a href="/Skeptics/Quotes/talleyrand_quotes.shtml">Talleyrand</a> :
<a href="/Skeptics/Quotes/oscar_wilde_quotes.shtml">Oscar Wilde</a> :
<a href="/Skeptics/Quotes/bismarck_quotes.shtml">Otto Von Bismarck</a> :
<a href="/Skeptics/Quotes/keynes_quotes.shtml">Keynes</a> :
<a href="/Skeptics/Quotes/george_carlin.shtml">George Carlin</a> :
<a href="/Skeptics/skeptical_quotes.shtml">Skeptics</a> :
<a href="/Skeptics/Quotes/propaganda.shtml">Propaganda</a>&nbsp; : <a href="/SE/quotes.shtml">SE 
quotes</a> : <a href="/Lang/quotes.shtml">Language Design and Programming Quotes</a> :
<a href="/Bulletin/quotes.shtml">Random IT-related quotes</a> :&nbsp;
<a href="/Skeptics/Quotes/somerset_maugham.shtml">Somerset Maugham</a> :
<a href="/Skeptics/Quotes/marcus_aurelius.shtml">Marcus Aurelius</a> :
<a href="/Skeptics/Quotes/kurt_vonnegut_quotes.shtml">Kurt Vonnegut</a> :
<a href="/Skeptics/Quotes/eric_hoffer.shtml">Eric Hoffer</a> :
<a href="/Skeptics/Quotes/churchill_quotes.shtml">Winston Churchill</a> :
<a href="/Skeptics/Quotes/napoleon_quotes.shtml">Napoleon Bonaparte</a> :
<a href="/Skeptics/Quotes/ambrose_bierce.shtml">Ambrose Bierce</a> :&nbsp;
<a href="/Skeptics/Quotes/bernard_shaw.shtml">Bernard Shaw</a> : </font>
<a href="/Skeptics/Quotes/mark_twain_quotes.shtml"><font size="2">Mark Twain Quotes</font></a></font></b></p>
</blockquote>

<p><b>Bulletin:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="http://softpanorama.biz/Bulletin/Sp2013_v25/bulletin25_12.shtml">
<font size="2">Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient 
markets hypothesis</font></a><font size="2"> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Bulletin/political_skeptic2013.shtml">
Political Skeptic Bulletin, 2013</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Unemployment/Bulletin/unempoyment2010.shtml">
Unemployment Bulletin, 2010</a> :
<a href="http://softpanorama.biz/Bulletin/Sp2011_v23/bulletin23_10.shtml">&nbsp;Vol 23, No.10 
(October, 2011) An observation about corporate security departments</a> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Fifth_column/Color_revolutions/Euromaydan/Bulletin/euromaydan14_06.shtml">
Slightly Skeptical Euromaydan Chronicles, June 2014</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Casino_capitalism/12_Apostols_of_deregulation/Greenspan/Bulletin/greenspan_bulletin2008.shtml">
Greenspan legacy bulletin, 2008</a> :
<a href="/Bulletin/Sp2013_v25/bulletin25_10.shtml">Vol 25, No.10 (October, 2013) Cryptolocker Trojan 
(Win32/Crilock.A)</a> :
<a href="/Bulletin/Sp2013_v25/bulletin25_08.shtml">Vol 25, No.08 (August, 2013) Cloud providers 
as intelligence collection hubs</a> : 
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2010.shtml">
Financial Humor Bulletin, 2010</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Inequality/Bulletin/inequality2009.shtml">
Inequality Bulletin, 2009</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2008.shtml">
Financial Humor Bulletin, 2008</a> :
<a href="http://softpanorama.biz/Copyright/Bulletin/copyleft_problems2004.shtml">Copyleft Problems 
Bulletin, 2004</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2011.shtml">
Financial Humor Bulletin, 2011</a> :
<a href="http://softpanorama.biz/Skeptics/Financial_skeptic/Energy/Bulletin/energy_bulletin2010.shtml">
Energy Bulletin, 2010</a> : <a href="http://softpanorama.biz/Malware/Bulletin/malware2010.shtml">
Malware Protection Bulletin, 2010</a> : <a href="/Bulletin/Sp2014_v26/bulletin26_01.shtml">Vol 26, 
No.1 (January, 2013) Object-Oriented Cult</a> :
<a href="http://softpanorama.biz/Skeptics/Political_skeptic/Bulletin/political_skeptic2011.shtml">
Political Skeptic Bulletin, 2011</a> :
<a href="/Bulletin/Sp2011_v23/bulletin23_11.shtml">Vol 23, No.11 (November, 2011) Softpanorama classification 
of sysadmin horror stories</a> : <a href="/Bulletin/Sp2013_v25/bulletin25_05.shtml">Vol 25, No.05 
(May, 2013) Corporate bullshit as a communication method</a>&nbsp; : </font><a href="/Bulletin/Sp2013_v25/bulletin25_06.shtml">
<font size="2">Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law</font></a></font></b></p>
</blockquote>

<p align="left"><b>History:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="/History/index.shtml"><font size="2">Fifty glorious years (1950-2000): 
the triumph of the US computer engineering</font></a><font size="2"> :
<a href="/People/Knuth/index.shtml">Donald Knuth</a> : <a href="/People/Knuth/taocp.shtml">TAoCP 
and its Influence of Computer Science</a> : <a href="/People/Stallman/index.shtml">Richard Stallman</a> 
: <a href="/People/Torvalds/index.shtml">Linus Torvalds</a>&nbsp; :
<a href="/People/Wall/index.shtml">Larry Wall </a>&nbsp;:
<a href="/People/Ousterhout/index.shtml">John K. Ousterhout</a> : <a href="/History/ctss.shtml">
CTSS</a> : <a href="/History/multix.shtml">Multix OS</a> <a href="/History/Unix/index.shtml">Unix 
History</a> : <a href="/People/Shell_giants/introduction.shtml">Unix shell history</a> :
<a href="/Editors/Vimorama/history.shtml">VI editor</a> :
<a href="/Scripting/Piporama/history.shtml">History of pipes concept</a> :
<a href="/Solaris/solaris_history.shtml">Solaris</a> : <a href="/History/dos_history.shtml">MS DOS</a> 
:&nbsp; <a href="/History/lang_history.shtml">Programming Languages History</a> :
<a href="/Lang/pl1.shtml">PL/1</a> : <a href="/Lang/simula67.shtml">Simula 67</a> :
<a href="/Lang/Cilorama/history.shtml">C</a> :
<a href="/People/Stallman/history_of_gcc_development.shtml">History of GCC development</a> :&nbsp;
<a href="/People/Scripting_giants/scripting_languages_as_vhll.shtml">Scripting Languages</a> :
<a href="/Scripting/Perlbook/Ch01/perl_history.shtml">Perl history&nbsp; </a>&nbsp;:
<a href="/History/os_history.shtml">OS History</a> : <a href="/Mail/history.shtml">Mail</a> :
<a href="/DNS/history.shtml">DNS</a> : <a href="/Net/Application_layer/SSH/ssh_history.shtml">SSH</a> 
: <a href="/History/cpu_history.shtml">CPU Instruction Sets</a> :
<a href="/Hardware/Sun/history_of_sparc.shtml">SPARC systems 1987-2006</a> :
<a href="/OFM/Paradigm/Ch03/norton_commander.shtml">Norton Commander</a> :
<a href="/Windows/Norton_utilities/history.shtml">Norton Utilities</a> :
<a href="/Windows/Ghosting/ghost_history.shtml">Norton Ghost</a> :
<a href="/Office/Frontpage/history.shtml">Frontpage history</a> :
<a href="/Malware/Malware_defense_history/index.shtml">Malware Defense History</a> :
<a href="/Utilities/Screen/history.shtml">GNU Screen</a> : </font>
<a href="/OSS/oss_early_history.shtml"><font size="2">OSS early history</font></a></font></b></p>
</blockquote>

<p><b>Classic books:</b></p>
<blockquote>

<p><b><font face="Arial"><a href="/Bookshelf/Classic/peter_principle.shtml"><font size="2">The Peter 
Principle</font></a><font size="2"> : <a href="/Bookshelf/Classic/parkinson_law.shtml">Parkinson 
Law</a> : <a href="/Bookshelf/Classic/nineteen_eighty_four.shtml">1984</a> :
<a href="/Bookshelf/Classic/tmmm.shtml">The Mythical Man-Month</a> :&nbsp;
<a href="/Bookshelf/Classic/polya_htsi.shtml">How to Solve It by George Polya</a> :
<a href="/Bookshelf/Classic/taocp.shtml">The Art of Computer Programming</a> :
<a href="/Bookshelf/Classic/teops.shtml">The Elements of Programming Style</a> :
<a href="/Bookshelf/Classic/unix_haters_handhook.shtml">The Unix Hater’s Handbook</a> :
<a href="/Bookshelf/Classic/jargon_file.shtml">The Jargon file</a> :
<a href="/Bookshelf/Classic/true_believer.shtml">The True Believer</a> :
<a href="/Bookshelf/Classic/programming_pearls.shtml">Programming Pearls</a> :
<a href="/Bookshelf/Classic/good_soldier_svejk.shtml">The Good Soldier Svejk</a> : </font>
<a href="/Bookshelf/Classic/power_elite.shtml"><font size="2">The Power Elite</font></a></font></b></p>
</blockquote>

<p><b>Most popular humor pages:</b></p>
<blockquote>

<p><font face="Arial"><b><a href="/Bulletin/Humor/Slackerism/it_slacker_manifest.shtml">
<font size="2">Manifest of the Softpanorama IT Slacker Society</font></a><font size="2"> :
<a href="/Bulletin/Humor/Slackerism/ten_commandments_of_software_slackerism.shtml">Ten Commandments 
of the IT Slackers Society</a> : <a href="/Bulletin/Humor/index.shtml">Computer Humor Collection</a> 
: <a href="/Bulletin/Humor/bsd_logo_story.shtml">BSD Logo Story</a> :
<a href="/Bulletin/Humor/cuckoo_egg.shtml">The Cuckoo&#39;s Egg </a>:
<a href="/Bulletin/Humor/slang.shtml">IT Slang</a> : <a href="/Lang/Cpp_rama/humor.shtml">C++ Humor</a> 
: <a href="/Bulletin/Humor/Archive/humor059.shtml">ARE YOU A BBS ADDICT?</a> :
<a href="/Bulletin/Humor/Archive/humor092.shtml">The Perl Purity Test</a> :
<a href="/Bulletin/Humor/Archive/humor065.shtml">Object oriented programmers of all nations</a> 
: <a href="/Skeptics/Financial_skeptic/Humor/financial_humor.shtml">Financial Humor</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2008.shtml">Financial Humor Bulletin, 
2008</a> : <a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2010.shtml">Financial 
Humor Bulletin, 2010</a> : <a href="/Editors/humor.shtml">The Most Comprehensive Collection of Editor-related 
Humor</a> : <a href="/Lang/programming_languages_humor.shtml">Programming Language Humor</a> :
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Systemic_instability_of_financial_sector/TBTF/Goldman_Sachs/humor.shtml">
Goldman Sachs related humor</a> :
<a href="/Skeptics/Financial_skeptic/Casino_capitalism/Twelve_apostles_of_deregulation/Greenspan/greenspan_humor.shtml">
Greenspan humor</a> : <a href="/Lang/Cilorama/humor.shtml">C Humor</a> :
<a href="/Scripting/humor.shtml">Scripting Humor</a> :
<a href="/Bulletin/Humor/real_programmers_humor.shtml">Real Programmers Humor</a> :
<a href="/WWW/humor.shtml">Web Humor</a> : <a href="/Copyright/humor.shtml">GPL-related Humor</a> 
: <a href="/OFM/ofm_humor.shtml">OFM Humor</a> :
<a href="/Skeptics/Political_skeptic/humor.shtml">Politically Incorrect Humor</a> :
<a href="/Security/IDS/humor.shtml">IDS Humor</a> : <a href="/Bulletin/Humor/linux_sucks.shtml">
&quot;Linux Sucks&quot; Humor </a>: <a href="/Links/Russian/Culture/Music/russian_musical_humor.shtml">Russian 
Musical Humor</a> : <a href="/Bulletin/Humor/best_russian_programmer_humor.shtml">Best Russian Programmer 
Humor</a> : <a href="/Bulletin/Humor/Archive/humor070.shtml">Microsoft plans to buy Catholic Church</a> 
: <a href="/People/Stallman/rms_related_humor.shtml">Richard Stallman Related Humor</a> :
<a href="/Admin/humor.shtml">Admin Humor</a> : <a href="/People/Wall/perl_related_humor.shtml">Perl-related 
Humor</a> : <a href="/People/Torvalds/linus_torvalds_related_humor.shtml">Linus Torvalds Related 
humor</a> : <a href="/Skeptics/humor.shtml">PseudoScience Related Humor</a> :
<a href="/Net/net_humor.shtml">Networking Humor</a> :
<a href="/Scripting/Shellorama/humor.shtml">Shell Humor</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2011.shtml">Financial Humor Bulletin, 
2011</a> : <a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2012.shtml">Financial 
Humor Bulletin, 2012</a> :
<a href="/Skeptics/Financial_skeptic/Humor/Bulletin/financial_humor2013.shtml">Financial Humor Bulletin, 
2013</a> : <a href="/Lang/Javarama/humor.shtml">Java Humor</a> : <a href="/SE/humor.shtml">Software 
Engineering Humor</a> : <a href="/Solaris/humor.shtml">Sun Solaris Related Humor</a> :
<a href="/Education/humor.shtml">Education Humor</a> : <a href="/Admin/Tivoli/ibm_humor.shtml">IBM 
Humor</a> : <a href="/Lang/Asmorama/humor.shtml">Assembler-related Humor</a> :
<a href="/Editors/Vimorama/vim_humor.shtml">VIM Humor</a> : <a href="/Malware/humor.shtml">Computer 
Viruses Humor</a> : <a href="/Bulletin/Humor/Archive/humor034.shtml">Bright tomorrow is rescheduled 
to a day after tomorrow</a> : <a href="/Bulletin/Humor/classic_computer_humor.shtml">Classic Computer 
Humor</a> </font></b></font></p>
</blockquote>

<p align="left"><b><a href="/Bulletin/Humor/last_but_not_least.shtml">The Last but not Least</a> </b> <em>Technology is dominated by 
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. 
Ph.D</em></p>

<hr size="5" noshade color="#FF0000"><font face="Verdana" size="1">

<p><i><b>Copyright © 1996-2021 by </b></i><b><i>Softpanorama Society</i></b>. <a target="_blank" href>www.softpanorama.org</a> 
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (<a target="_blank" href="http://www.un.org/Depts/dhl/sflib/">SDNP</a>) 
without any remuneration. This document is an industrial compilation designed and <b>created exclusively 
for educational use</b> and is distributed under the <a href="/license.shtml">Softpanorama Content License</a>. 
Original materials copyright belong 
to respective owners. <i><b>Quotes are made<font color="#FF0000"> for educational purposes only</font> 
in compliance with the fair use doctrine. </b></i> 
</p>

<p><em><b>FAIR USE NOTICE</b> </em>This site contains 
		copyrighted material the use of which has not always been specifically 
		authorized by the copyright owner. We are making such material available 
		to advance understanding of computer science, IT technology, economic, scientific, and social  
		issues. We believe this constitutes a 'fair use' of any such 
		copyrighted material as provided by section 107 of the US Copyright Law according to which 
such material can be distributed without profit exclusively for research and educational purposes.</p>

<p><b>This is a Spartan WHYFF (We Help You For Free) 
site written by people for whom English is not a native language.</b> Grammar and spelling errors should 
be expected. <b>The site contain some broken links as it develops like a living tree...</b></p>

<table border="0" width="100%">
<tr>
<td>

<p align="center"><font face="Verdana" size="1">
<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
<img alt="" border="0" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" width="1" height="1">
</font></td>
<td><font face="Verdana" size="1">You can use PayPal to to buy a cup of coffee for authors 
of this site </font></td>
</tr>
</table>

<p><b>Disclaimer:</b> </p>

<p><i>The statements, views and opinions presented on this web page are those of the author (or 
referenced source) and are 
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.</i> <i>We do not warrant the correctness 
of the information provided or its fitness for any purpose. </i>The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be 
tracked by Google please disable Javascript for this site. <em>This site is perfectly usable without 
Javascript.</em> 
</font></p>


<p><i>Last modified: <!--webbot bot="Timestamp" s-type="EDITED" s-format="%B %d, %Y" startspan -->June 03, 2021<!--webbot bot="Timestamp" i-checksum="14008" endspan --></i> </p>

</body>

</html>