[Up] [SIGAda] [ACM]

ASIS Workshop Minutes


Minutes from the ASIS Workshop at
Ada in Europe 95
on Wednesday, 4 October 1995

Prepared by Sergey Rybin (rybin@lglsun.epfl.ch).

List of participants (I am awfully sorry if I made mistakes when decoding your hand-writting ):

Lars Asplund - asplund@docs.uu.se
Stephane Barbey - barbey@lglsun.epfl.ch
Bernd Bunhstallen - bbug@avlo.tunie.ac.at
Dirk Craeynest - dirk@offis.be
Robert Dewar - dewar@gnat.com
Magnus Ericson - FAX +46 8 750 74 42
Andrew Hall - tld_euro@cerf.net
Johen Hayek - johen_hayek@acm.org
Rainer Kischke - koschke@grimm.informatik.uni-stuttgart.de
Olavi Poutanen - olavip@cs.fut.fi
Sergey Rybin - rybin@lglsun.epfl.ch
Alfred Strohmeier - strohmeier@di.epfl.ch
Eugene Zueff - zueff@such.srcc.msu.su

All the participants agree that ASIS could be a good background for developing the portable and easy-to-integrate Ada toolsets, but now there are some number of open problems around ASIS which are or could be barriers for ASIS adoption in the Ada community.

During the Workshop the following ASIS open problems were discussed. After the Workshop, additional follow-up comments were provided (these are shown in italics).

  1. ASIS application areas.

    What kinds of tools could really be built on top of ASIS? There are certain doubts and/or unclearnesses concerning some tools which are frequently included in potential ASIS application areas. In particular, debuggers, automated code monitors and timing estimators were indicated during the Workshop as the tools which could hardly be built on the top of ASIS.

    There are a lot of software engineering tools where ASIS would have little value. Real-time debuggers, automated code monitors and timing estimators are three of these. They were included on the list because people had discussed the use of ASIS to support tools in these domains and in some cases, ASIS was used. These are not main-stream application areas for ASIS, thus the list in the ASIS FAQ now becomes:

    code restructuring tools, code browsing and navigation tools, coding style and standards compliance tools, cross-reference tools, data flow analysis tools, dependency tree analysis tools, design tools, document generation tools, invocation (call) tree analysis tools, language-sensitive editing and pretty-printing tools, language translation tools, quality assessment tools, reverse engineering tools, re-engineering tools, safety and security compliance tools, static correctness verifiers, tasking analysis tools, test-case generation and coverage analysis tools, and usage, quality, and complexity metrics tools.

    These are still very important tool areas for which ASIS can be valuable. If there are other tool areas where ASIS can be valuable, ASISWG/ASISRG would appreciate input.

  2. ASIS applications - do they really exist now?

    No one from the workshop participants could say that he knew something about any existing ASIS application or about somebody who was working with some particular ASIS application (except the example from ASIS FAQs). This is why many people may consider that ASIS is simply one more "dead" Ada artifact.

    We have been trying to promote the use of ASIS as part of the system application (vice a tool). We haven't been very successful. So far, the use of ASIS for system applications has been extremely limited with only one highly successful (and publicized) use. IBM (now Loral) did use ASIS very successfully to delog data from a satelite called System 1. It resulted in reduced cost with significantly enhanced future capabilities. We think ASIS can be a valuable technology for many other system applications. Particularily where it is useful to decouple system-to-system interfaces to provide flexibility, reduce cost, and support evolutionary development/acquisition. We hope the use of ASIS for system applications will become more widespread as the use of Ada becomes more widespread. In a sense, the use of ASIS for applications is dependent on the use of Ada for system applications and innovative thinking on using the ASIS technology to support the application's requirements.

    We don't understand the last statement as even if ASIS were not useful for system applications, it is still highly valuable for building CASE tools. We think ASIS will be very much alive as long as Ada is healthy.

  3. Is the level of the ASIS interface high enough to make ASIS to be really easy to use for building Ada tools?

    There exist certain needs for the developing of various general-purpose and specialized interfaces on top of ASIS which could provide a higher level interface than ASIS does for an Ada tool developer. (Maybe, ASIS Secondary Layers [now called toolkits] are the solution to the problem, but there is too little information about them.)

    ASIS is at a relatively low level. It was intended to provide the necessary primitive operations to extract syntactic and semantic information from the Ada Program Library (ASIS83) and the Ada environment (ASIS 95). A public domain secondary layers was developed for ASIS83, called the Program View Layer. It provides higher level abstractions/views to obtain information associated with declarative regions (i.e., symbol scopes), Ada entities (i.e., types, objects, subprograms), Ada entities referenced within an Ada unit, and transfers of control among statements of an Ada program unit. Additional secondary layers/abstractions could be valuable. The ASISWG/ASISRG have viewed that the primary, low-level interfaces are appropriate for the ASIS standard as these are the necessary interfaces. Higher level abstrations can be built in terms of these interfaces just like MOTIF is built on the lower Xlib and Xt intrinsics. Generally interfaces that are identified for secondary layers are excluded from the ASIS specification unless performance could be significantly enhanced by placing the interface in the ASIS specification. If one could make a strong case for including a specific higher level secondary interface which would convince the ASISWG/ASISRG, then it would be included as part of the ASIS specification. We encourage you to come to the next meeting and get involved [2-4 November 1995 in San Diego; contact Steve Blake at blake@alsys.com for details or check out the ASIS Home Page on http://www.acm.org/sigada/wg/asiswg].

    Currently there are no public domain secondary layers for ASIS 95. As ASIS 95 matures, the availability of public domain secondary layers should increase.

  4. Is ASIS really a vendor-independent interface?

    It seems that ASIS contains too many implementation-dependent and implementation-defined features to make it really possible to build portable Ada tools on it. In particular, the supporting of the comments in the source text of the compilation units processed by ASIS and the normalization of the association lists were discussed as aspects which could seriously influence the portability of ASIS-based tools.

    A goal of ASISWG/ASISRG is to make ASIS as implementation/vendor independent as possible. To the most part, such implementation and vendor dependencies have been eliminated from the the interface. The ASIS Workshop cites two cases where there are problems. The first case cites the processing of comments in the source text. ASIS simply provides the means to extract the text of a comment. The use of commentary is not under control of ASIS nor should it be. Vendors supporting PDL use different notations and different placement of comments (i.e., before or after commented entity). It is outside the scope of ASISWG/ASISRG to standardize how commentary should be used to support PDL tools. SIGAda or WG9 should be broached for the creation of a separate group if there is enough interest in this area. As to the second case addressing the normalization of the association lists, We have talked to several people about potential implementation dependent problems with association lists yet we are still unclear as to what the problem is. If you could provide a write up of this problem, we will include it on the agenda for discussion at the next ASISWG/ASISRG meeting. Also if there are any other implementation/vendor dependent issues, this is a good time to bring them our attention. Although ASIS-based tools are not expected to be 100% portable from one Ada environment to another, we have been pleased with the high degree of implementation independence provided by ASIS. It is a goal of ASISWG/ASISRG to provide an interface that minimizes the cost of porting a tool from one Ada environment to another. We will seriously address any thoughts in this area. Again you are encouraged to attend the ASISWG/ASISRG meeting to address your concerns in this area.

ASIS 2.X implementation for the GNAT compiler could give a good impact for ASIS activities, so it is very important to obtain the first workable freeware release of the implementation as soon as possible.

We are also very excited about your work. We are interested in distributing your GNAT ASIS implementation at Tri-Ada and on the ASIS Home Page. Is this possible? [Sergey has replied in the affirmative; it is scheduled to be available by the end of 1995.]

Another aspect which could make a good impact on the progress of ASIS would be the development of the set of the freeware (or low-cost) ASIS applications for some typical problems. These applications could be used both for practical purposes and for the demonstration of the concepts and abilities of ASIS.

The ASIS Home Page already has the ASIS83 specification, secondary interfaces, tutorials (with examples), a conformance suite, and pointers to a complete ASIS application. All this is currently available in the public-domain. Members of the Ada ASIS community are encouraged to provide artifacts which can be made available to the public. We fully anticipate ASIS 95 artifacts will appear once an ASIS 95 specification is available. The first public releaseble draft of the ASIS 95 interface is planned for Tri-Ada'95 in early November.


[Up] [SIGAda] [ACM]

Last update 24 October 1995. Questions, comments to Clyde Roby (CRoby@IDA.Org)