Posted by: 2stepsback | October 28, 2005

XML ideas: Porting made easier

Porting from one technology to another is almost inevitable after 5-10 years. The languages may differ vastly. However, the architecture may remain the same. Using XML, we could standardize the format for description of an application which could make porting a little bit easier. Let us give the scheme a nice-looking name: Common Architecture Description Language.
We could have a top level descriptor file for system description purposes and each element pointing to lower levels of architecture-describing files using a javadoc-like structure. Think of it as series of hierarchically organized newsfeeds, each feed describing a part or component of the system to a certain level of detail. And when we drill-down to lower levels in the architecture we reach the names of the source code files which will perform defined functions.
The code architecture will roughly start with modules at the top. For simplicity, let us take the case of a small application like say, Apache Ant, it will contain the names of the modules, a brief description of each module, the name of the library file(in this case, the Jar file). The functional architecture documentation may be differently organized than the code architecture. Apart from the obvious minimum requirements of functional description, the functional documentation can contain mention of external libraries used and their functionality, treated as a blackbox in general.
Coming back to Ant, the top-level file would look something like:
<application>
<introduction>
<app-name>Ant</app-name>
<app-version>1.6.2</app-version>
<app-description>Another Neat Tool</app-description>
</introduction>
<module-list>
<module>
<name>BCEL</name>
<desc>Byte Code Engineering Library</desc>
</module>
<module>
<name>Log4j</name>
<desc>Apache Java Logging Library</desc>
</module>
…..
</module-list>
…..
<input-list>
…..
</input-list>

<reports-list>
…..
</reports-list>

</application>

And there could be a file for each module like BCEL.xml

<module>
<name>BCEL</name>
<desc>Byte Code Engineering Library</desc>

<library>
<name>ant-apache-bcel.jar</name>
<path>http://bcel.apache.org/</path&gt;

<classlist>
<class>
<name>FullAnalyzer</name>
<internalpath>org.apache.tools.ant.util.depend.bcel.FullAnalyzer</internalpath>
<desc>Analyzes something fully</desc>
</class>
…..
</classlist>

<functionlist>
<function>
<name>FullAnalyzer()</name>
<arguments>
<arg type=”int”>nLines</arg>
<arg type=”long”>nBytes</arg>
</arguments>
<internalpath>FullAnalyzer.FullAnalyzer()</internalpath>
</function>
…..
</functionlist>
</library>

</module>

And so on. This is just the idea. The actual standard, if implemented (I do not know if there already is one) will obviously be much more well thought-out and elaborate. If you notice, the tag-names are roughly language-independent which means that a well-designed format for the above purpose can document any system. And then a well-written program can read from this set of XML files and generate a nice-looking documentation. That is exactly what javadoc does. The fun part is when this document set can be automatically generated from code. Then, you could have a Grokker-like tool which makes atttractive graphics (SVG can be used) to explain the system. with this tool at your disposal, you do not need to take the pains to make presentations on the architecture and the document set being readily available, you can appproach the task of porting more efficiently – basically, the aim should be that several developer meetings which just explain the purpose of each module of the existing system can be done away with and substituted by quick and system-wide learning. You could have people making out the functionality by just looking at the documents generated from these XML files. Another related idea that strikes is that is would be great is documentation in all languages be done in the same format, thereby allowing one tool and one format for all languages. That too, would make porting really easy.

However, a little experience with porting makes one realize that often, major functionality and design changes are made when moving from one language to the next. To handle that scenario, to the best of my knowledge, Word processsor documents and spreadsheets (and presentations) are considered (often rightly) the best tools, and not a Common Architecture Description Language. Yet I feel that if a proper framework evolves around this kind of a language, it will still be easier to add new functionality of remove something existing or modify it.

P.S. Is all this dealt with in UML?
Update: November 7, 2005: Have a look at the SEI page on ADLs and more precisely, at ADML .

Advertisements

Categories

%d bloggers like this: