TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"Pritchett, William \"Bill\"" <[log in to unmask]>
Date:
Fri, 15 Oct 1999 11:34:45 -0400
Content-Type:
text/plain; charset="iso-8859-1"
MIME-Version:
1.0
Reply-To:
"Pritchett, William \"Bill\"" <[log in to unmask]>
Parts/Attachments:
text/plain (83 lines)
Aside from calculating various functional and object-oriented metrics, the
tool allows a user to, from a large list of language features, choose which
language features the tool will flag (or not flag) and inform the user that
the particular language feature was used.  For example, if your project
prohibits the use of tasking, the user simply clicks on the NO_TASKING
restriction and every instance in the source code where a task or task type
appears the tool reports this back to the user.  It is then up to the user
to take the appropriate action within whatever verification process being
used.  It is also possible, to have profiles of language restrictions that
would correspond to a particular analysis technique.  For example, from the
HRG Report class-wide operations are allowed under Timing Analysis, but
excluded structure-based testing.  There could be a "Structure-based
Testing" profile that would then enable checks for all language features
excluded for this technique.  You can also make project-specific profiles to
tailor restrictions for whatever purpose.  The bottom line is we can check
for usage of almost every language feature that is statically analyzable and
report that back to the user.  I hope this clears up the confusion regarding
the tool.

To learn more about the tool I encourage everyone to attend our reception at
SIGAda this Monday night from 5pm to 7pm in the Seascape room at the Crown
Plaza.  There will be food and beverage provided.

-------------------------------------------------------------
* Bill Pritchett                 |   DCS Corporation        *
* AdaSTAT Development Mgr        |   1330 Braddock Place    *
* Voice: 703-683-8430 x726       |   Alexandria, VA 22314   *
* Fax:   703-684-7229            |                          *
* eMail: [log in to unmask]    |   http://www.dcscorp.com *
-------------------------------------------------------------


> -----Original Message-----
> From: Phil Thornley [SMTP:[log in to unmask]]
> Sent: Friday, October 15, 1999 5:12 AM
> To:   [log in to unmask]
> Subject:      HRG 'Restrictions' on Ada
>
> Team-Ada folks,
>
> Several recent messages have given the impression that the HRG Guide
> imposes restrictions and/or defines a subset:
>
> from Bill Pritchett:
> "The tool, called AdaSTAT, also enforces the language restrictions
> recommended by the Annex H Rapporteur Group."
>
> from Currie Colket:
> "AdaSTAT is built upon ASIS and 1) flags violations of safety-critical
> language
> restrictions,..."
>
> from SY Wong (referring to the AdaSTAT tool):
> "I want to ask them
> the question why they think SIGAda members will be interested in safety
> restrictions when I have to battle the group for many years to define
> a subset without the restricted constructs."
>
> In fact the Guide does neither of these.
>
> The basis of the HRG Guide is that any development of high-integrity
> software will make systematic use of several verification techniques
> ("systematic" should be understood as meaning that the techniques are to
> be applied to all the delivered software). The Guide identifies 15 such
> techniques (10 analysis and 5 testing).
>
> However some language features are not compatible with some verification
> techniques - the Guide identifies these incompatibilities.
>
> So, the user of the Guide first defines their software process then
> determines the restrictions that are necessary to ensure that process is
> not defeated by inappropriate code.
>
> There are therefore as many sets of restrictions, or subsets, as there
> are combinations of the verification techniques. For a tool to "[enforce]
> the language restrictions recommended" by the Guide it must allow the
> user to define the set of verification techniques to be applied.
>
> I would be grateful if someone attending the DCS demonstration could post
> a summary of what the tool actually does.
>
> Phil Thornley

ATOM RSS1 RSS2