From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5716f1b70af0ef9d X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!out01a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!uns-out.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!API-DIGITAL.COM-a2kHrUvQQWlmc!not-for-mail Date: Sat, 01 Sep 2007 15:33:46 -0500 From: "Marc A. Criley" User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ANNOUNCE: Avatox 1.8 is now available References: <1278164.6P7X0PHotG@linux1.krischik.com> <1272606.X88MrAQ2va@linux1.krischik.com> In-Reply-To: <1272606.X88MrAQ2va@linux1.krischik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <251dc$46d9cc72$433a558c$31832@API-DIGITAL.COM> X-Complaints-To: abuse@usenetserver.com Organization: UseNetServer.com X-Trace: 251dc46d9cc72e69ff02931832 Xref: g2news2.google.com comp.lang.ada:1656 Date: 2007-09-01T15:33:46-05:00 List-Id: Martin Krischik wrote: > Marc A. Criley wrote: > >> AXF is seen as a first step--First let's get the Ada into a more >> malleable form that can be processed by XML tools and technologies. >> Then it becomes more amenable to content extract and transformation, >> with Avatox generating "AXFPoint" (AXF Points Of INformation for >> Transformation) elements to to assist with transformations by providing >> information beyond that of the basic ASIS-derived semantic information. >> >> In other words, AXF -> UMI would be easier than Ada -> UMI because >> you've lessened the "impedance mismatch" between the source and target. >> In addition, if you want to change the way Ada constructs are mapped >> to UMI (or any other target), or if you need to adapt to a revised UMI, >> it's almost always going to be much simpler to alter an XML >> processor--especially if it's stylesheet based--than the Ada-to-XML >> generator. > > So: > > .adb ==Avatox==> .axf ==XXX==> .xmi ==xmi2code==> .adb > > is easier then > > .adb ==Avatox==> .xmi ==xmi2code=> .adb Actually, yes :-) The reason is that adb => AXF is an almost mechanical translation, AXF being an XML representation of the ASIS-derived structure of the source program. And not least, Avatox is pretty much done. Going directly from Ada to XMI, however, is a much more analytical problem, requiring the mapping of Ada constructs to XMI equivalents. And from what I've experienced with Source Code 2 Design Model converters (for any language) they don't do a great job. I mean, what comes out is a pretty prosaic representation of the _code_ as UML (or whatever) artifacts. You would not have diagrammed the system this way, and to try to employ some higher level intelligence in the converter to recognize programming idioms and abstractions and then map _those_ to "better" XMI requires a lot more work (and the fact that I don't see it in commercial tools tells me that it requires a LOT more work). Also, AXF retains _all_ the information in the original source, including comments, line/column extents (which gives you the original whitespace), etc. Going from source code to model you tend to start omitting things because of the differing levels of abstraction. > Only we would need XXX ;-). Yes, which could be built incrementally. Instead of trying to go straight from AXF (or Ada source) to XMI, you can do some filtering, some simple transformations, some more filtering, some pattern recognition, some transformations, and eventually end up with XMI. In this case you then have: .adb ==[Avatox+AXF2XMI]==> .xmi ==xmi2code=> .adb And there you go! Have at it! :-) -- Marc A. Criley -- McKae Technologies -- www.mckae.com -- Avatox - DTraq - XIA - XML EZ Out