曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
critical areas of the detailed design and any preliminary code for areas of deep nesting, large numbers of
parameters to be passed, intense and numerous communication paths, etc. (Refer to references cited above.)
Resources are the detailed design, high level language description, source code, and automated complexity
measurement tool(s).
Output products are complexity metrics, predicted error estimates, and areas of high complexity identified
for further analysis or consideration for simplification.
Several automated tools are available on the market which provides these metrics. The level and type of
complexity can indicate areas where further analysis, or testing, may be warranted. Beware, however, these
metrics should be used with caution as they may indicate that a structure, such as a CASE statement, is
highly complex while in reality that complexity leads to a simpler, more straight forward method of
programming and maintenance, thus decreasing the risk of errors.
Linguistic measurements measure some property of the text without regard for the contents (e.g., lines of
code, number of statements, number and type of operators, total number and type of tokens, etc). Halstead's
Metrics is a well known measure of several of these arguments.
Structural metrics focuses on control-flow and data-flow within the software and can usually be mapped into
a graphics representation. Structural relationships such as the number of links and/or calls, number of nodes,
nesting depth, etc. are examined to get a measure of complexity. McCabe's Cyclomatic Complexity metric is
the most well known and used metric for this type of complexity evaluation.
J.5.10 Safe Subsets of Programming languages
Safety specific coding standards are developed which identify requirements for annotation of safety-critical
code and limitation on use of certain language features which can reduce software safety. The purpose of
this section is to provide a technical overview of safety-critical coding practices for developers and safety
engineers, primarily those involving restricting the use of certain programming language constructs.
The use of software to control safety-critical processes is placing software development environments (i.e.
languages, compilers, utilities, etc.) under increased scrutiny. When computer languages are taught, students
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-18
are seldom warned of the limitations and insecurities that the environment possesses. An insecurity is a
feature of a programming language whose implementation makes it impossible or extremely difficult to
detect some violation of the language rules, by mechanical analysis of a program's text. The computer
science profession has only recently focused on the issues of the inherent reliability of programming
environments for safety-critical applications.
This section will provide an introduction on the criteria for determining which languages are well suited for
safety-critical applications. In addition, an overview of a safe subset of the ADA language will be discussed
with the rationale for rejecting language constructs. Reading knowledge of Pascal, ADA, C or another
modern high level block structured language is required to understand the concepts that are being discussed.
There are two primary reasons for restricting a language definition to a subset: 1) some features are defined
in an ambiguous manner and 2) some features are excessively complex. A language is considered suitable
for use in a safety-critical application if it has a precise definition (complete functionality as well), is
logically coherent, and has a manageable size and complexity. The issue of excessive complexity makes it
virtually impossible to verify certain language features. Overall, the issues of logical soundness and
complexity will be the key toward understanding why a language is restricted to a subset for safety-critical
applications.
An overview of the insecurities in the ADA language standard is included in this entry. Only those issues
that are due to the ambiguity of the standard will be surveyed. The problems that arise because a specific
implementation (e.g., a compiler) is incorrect can be tracked by asking the compiler vendor for a historical
list of known bugs and defect repair times. This information should give a user a basis with which to
compare the quality of product and service of different vendors.
Insecurities Common to All Languages
All programming languages have insecurities either in their definition or their implementation. The
evolutionary trend of computer languages shows a trend of newer languages trying to correct the shortfalls of
older generation languages (even though some individuals complain about additional restrictions).
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册下(137)
