--::::::::::
--apsetool.doc
--::::::::::
SELECTED TAXONOMIES
from the
E&V REFERENCE MANUAL, VERSION 1.0
July, 1988
Interim Report for Period 6/85 - 3/88
Prepared for:
Ada Software Repository
Prepared by:
Richard Conn
The information in this document is, for the most part,
extracted literally from the E&V___ Reference_________ Manual,______, Version_______
1.0._._.
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
1. INTRODUCTION
From the Executive Summary of the E&V Reference Manual:
"The Ada community, including government, industry, and
academic personnel, needs the capability to assess APSEs
(Ada Programming Support Environments) and their components
and to determine their conformance to applicable standards
(e.g., DOD-STD-1838, the CAIS standard). The technology
required to fully satisfy this need is extensive and largely
unavailable; it cannot be acquired by a single
government-sponsored, professional society-sponsored, or
private effort. The purpose of the APSE Evaluation and
Validation (E&V) task is to provide a focal point for
addressing the need by:
"(1) Identifying and defining specific technology
requirements,
"(2) Developing selected elements of the required
technology,
"(3) Encouraging others to develop some elements,
and
"(4) Collecting information describing existing
elements.
"This information will be made available to DoD components,
other government agencies, industry and academia.
"The purpose of the E&V Reference Manual (this
document) is to provide information that will help users to:
"(1) Gain an overall understanding of APSEs and
approaches to their assessment,
"(2) Find useful reference information (e.g.,
definitions) about specific elements and relationships
between elements, and
"(3) Find criteria and metrics for assessing tools
and APSEs, and techniques for performing such
assessment.
"The latter are to be found (or referenced) in a companion
document called the E&V Guidebook."
1
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
2. APSE DEFINITIONS and ALTERNATIVE NAMES
2.1. PSE___
PSE stands for "Programming Support Environment," and
is defined in the "IEEE Standard Glossary of Software
Engineering Terminology" (dated 1983) as:
"An integrated collection of tools accessed via a
single command language to provide programming
support capabilities throughout the software
life-cycle. The environment typically includes
tools for design, editing, compiling, loading,
testing, configuration management, and project
management."
2.2. APSE____
APSE stands for "Ada Programming Support Environment."
It is a programming support environment for the development
of software written in the Ada computer programming
language.
The "E&V Reference Manual" goes on to describe various
ways of viewing an APSE from various perspectives. It also
describes key attributes of an APSE.
2
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
3. LIFE CYCLE PHASES
The life cycle phases recommended in the "E&V Reference
Manual" are:
- System Concepts
- System Requirements Analysis
- Software Requirements Analysis
- Preliminary Design
- Detailed Design
- Coding and Unit Testing
- CSC Integration and Testing
- CSCI Testing
- System Integration and Testing
- Operational Testing and Evaluation
- Change Requirements
- Global
3.1. System______ Concepts________
3.2. System______ Requirements____________ Analysis________
3
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
3.3. Software________ Requirements____________ Analysis.________.
"Those activities of the life cycle pertaining to the
establishment of system requirements and a complete set of
functional, performance, and interface requirements for each
CSCI."
3.4. Preliminary___________ Design.______.
"Those activities in the life cycle pertaining to the
development of a modular, top-level design of each CSCI from
the software requirements."
3.5. Detailed________ Design.______.
"Those activities in the life cycle pertaining to the
development of a modular, detailed design of each CSCI from
the preliminary design."
3.6. Coding______ and___ Unit____ Testing._______.
"Those activities in the life cycle pertaining to the coding
and testing of each unit comprising the detailed design."
3.7. CSC___ Integration___________ and___ Testing._______.
"Those activities in the life cycle pertaining to the
integration of units of code and the performance of informal
tests on aggregates of integrated units."
3.8. CSCI____ Testing._______.
"Those activities in the life cycle pertaining to the
conduct of formal tests on each CSCI and the
recording/analysis of test results."
4
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
3.9. System______ Integration___________ and___ Testing._______.
"Those activities in the life cycle pertaining to the
successive integration and testing of CSCIs and HWCIs to
validate that the complete system is properly integrated and
satisfies system requirements."
3.10. Operational___________ Testing_______ and___ Evaluation.__________.
"Those activities in the life cycle where the system is
tested and evaluated in surroundings which are as
operationally realistic as possible to determine that the
system will satisfactorily perform the mission for which it
was designed."
3.11. Change______ Requirements.____________.
"Those activities in the life cycle pertaining to the
support (error detection/correction) and enhancement of the
operational CSCIs. Often, this activity will result in a
series of software developments potentially requiring tool
features (besides Global features) different from all
preceding life cycle activities."
3.12. Global.______.
"Represents those general support features which include
common (in implementation and use) software elements or
functions. Global features can be included in each life
cycle activity."
5
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
4. APSE TOOL TAXONOMY
"APSEs are the highest levels of toolset. APSEs should
contain all the tools and toolsets needed to support the
full spectrum of project activities."
4.1. Computer________ Management__________ System.______.
"Those tools needed to access, use, and maintain the
hardware and software which consists of the APSE and the
system on which it runs."
4.1.1. Command_______ Language________ Processor_________
4.1.2. Archive,_______, Backup,______, and___ Retrieval_________ System______
4.1.3. Security________ System______
4.1.4. Job___ Scheduler_________
4.1.5. Resource________ Controller__________
4.1.6. File____ Manager_______
4.1.7. Import/Export_____________ System______
4.1.8. On-Line_______ Assistance__________ Processor_________
4.1.9. Data____ Base____ Manager_______
4.2. Project_______ Management__________ System.______.
"Those tools needed to plan, develop, and maintain an
applications system."
4.2.1. Cost____ Estimator_________
4.2.2. Quality_______ Analyzer________
4.2.3. Scheduler_________
4.2.4. Work____ Breakdown_________ Structure_________
4.2.5. Resource________ Estimator_________
6
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
4.2.6. Tracking________
4.2.7. Configuration_____________ Manager_______
4.2.8. Problem_______ Report______ Analyzer________
4.2.9. Change______ Request_______ Analyzer________
4.3. Compilation___________ System.______.
"Those tools needed to produce and run software systems."
4.3.1. Program_______ Library_______ Manager_______
4.3.2. Syntax-Directed_______________ Editor______
4.3.3. Compiler________
4.3.4. Assembler_________
4.3.5. Linker______
4.3.6. Loader______
4.3.7. Interpreter___________
4.3.8. Runtime_______ Library_______
4.4. Document________ System.______.
"Those tools needed to develop and produce documents."
4.4.1. Document________ Manager_______
4.4.2. Word____ Processor_________
4.4.3. Spell_____ Checker_______
4.4.4. Graphics________ Generator_________
4.4.5. Formatter_________
7
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
4.5. Desktop_______ System.______.
"Those tools needed to do the every-day, administrative
tasks of business."
4.5.1. Spreadsheet___________
4.5.2. Calculator__________
4.5.3. Address_______ Book____
4.5.4. Electronic__________ Mail____
4.5.5. Phone_____ Book____
4.5.6. Electronic__________ Conferencing____________
4.5.7. Calendar________
4.5.8. Dictionary__________
4.6. Static______ Analyzer________ System.______.
"Those tools needed to do analysis of software systems
without actually executing the program(s) being analyzed."
4.6.1. Comparator__________
4.6.2. Data____ Flow____ Analyzer________
4.6.3. Functional__________ Analyzer________
4.6.4. Interface_________ Analyzer________
4.6.5. Traceability____________ Analyzer________
4.6.6. Testability___________ Analyzer________
4.6.7. Test____ Condition_________ Analyzer________
4.6.8. Quality_______ Analyzer________
4.6.9. Complexity__________ Measurer________
4.6.10. Correctness___________ Checker_______
4.6.11. Completeness____________ Checker_______
4.6.12. Consistency___________ Checker_______
4.6.13. Reusability___________ Analyzer________
8
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
4.6.14. Syntax______ and___ Semantics_________ Checker_______
4.6.15. Reachability____________ Analyzer________
4.6.16. Cross_____ Referencer__________
4.6.17. Maintainability_______________ Analyzer________
4.6.18. Invocation__________ Analyzer________
4.6.19. Scanner_______
4.6.20. Structured__________ Walkthrough___________ Tool____
4.6.21. Auditor_______
4.6.22. Error_____ Checker_______
4.6.23. Statistical___________ Analyzer________
4.6.24. Statistical___________ Profiler________
4.6.25. Structure_________ Checker_______
4.6.26. Type____ Analyzer________
4.6.27. Units_____ Analyzer________
4.6.28. I/O___ Specification_____________ Analyzer________
4.6.29. Sizing______ Analyzer________
4.7. Dynamic_______ Analyzer________ System.______.
"Those tools needed to do analysis of software systems while
actually executing the program(s) or some representation of
the system being analyzed."
4.7.1. Requirements____________ Simulator_________
4.7.2. Requirements____________ Prototype_________
4.7.3. Simulation__________ and___ Modelling_________ Tools_____
4.7.4. Design______ Prototype_________
4.7.5. Debugger________
4.7.6. Executable__________ Assertion_________ Checker_______
4.7.7. Constraint__________ Evaluator_________
9
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
4.7.8. Coverage/Frequency__________________ Analyzer________
4.7.9. Mutation________ Analyzer________
4.7.10. Testing_______ Analyzer________
4.7.11. Regression__________ Testing_______ Analyzer________
4.7.12. Resource________ Utilization___________ Analyzer________
4.7.13. Emulator________
4.7.14. Timing______ Analyzer________
4.7.15. Tuning______ Analyzer________
4.7.16. Reliability___________ Analyzer________
4.7.17. Real____ Time____ Analyzer________
4.7.18. Formal______ Verification____________ System______
4.7.19. Symbolic________ Execution_________ System______
10
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
5. ATTRIBUTES of an APSE
"Attributes are the characteristics of tools or "whole
APSEs" which the E&V user evaluates (or validates) to make
assessments and comparisons." At the top level, three main
attributes are of concern:
- Performance: how well does it function?
- Design: how well is it designed?
- Adaptation - how adaptable is it?
- Software-Oriented Criteria
5.1. Performance.___________.
"Performance quality factors deal both with the ability of
the software to function and with error occurrences that
affect software functioning. Low quality factors predict
poor software performance."
5.1.1. Efficiency.__________. "Efficiency deals with utilization of
resources. The extent to which a component fulfills its
purpose using a minimum of computing resources. Of course,
many of the ways of coding efficiently are not necessarily
efficient in the sense of being cost-effective, since
transportability, maintainability, etc., may be degraded as
a result."
5.1.2. Integrity._________. "Integrity deals with software failures
due to unauthorized access. The extent to which access to a
component or associated data by unauthorized persons can be
controlled."
5.1.3. Reliability.___________. "Reliability concerns any software
failure. The extent to which a component can be expected to
perform its intended functions in a satisfactory manner."
5.1.4. Survivability._____________. "Survivability deals with the
continued performance of software (e.g., in a degraded mode)
even when a portion of the system has failed."
5.1.5. Usability._________. "Extent to which resources required to
acquire, install, learn, operate, prepare input for, and
interpret output of a component are minimized."
11
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
5.2. Design.______.
"Design quality factors deal mainly with software failure
and correction. Low quality levels usually result in
repeating a portion of the development process (e.g.,
redesign, recode, reverify); hence the term design."
5.2.1. Correctness.___________. "The extent to which software design
and implementation conform to specifications and standards.
Criteria of correctness deal exclusively with design and
documentation formats. Agreement between a component's
total response and the stated response in the functional
specification (functional correctness), and/or between the
component as coded and the programming specification
(algorithmic correctness)."
5.2.2. Maintainability._______________. "The ease of effort in locating
and fixing software failures. The extent to which a
component facilitates updating to satisfy new requirements
or to correct deficiencies. This implies that the component
is understandable, testable, and modifiable."
5.2.3. Verifiability,_____________, Testability.___________. "Software design
characteristics affecting the effort to verify software
operation and performance. The extent to which a component
facilitates the establishment of verification criteria and
supports evaluation of its performance. This implies that
requirements are matched to specific modules, or diagnostic
capabilities are provided, etc."
5.3. Adaptation.__________.
"Adaptation quality factors deal mainly with using software
beyond its original requirements, such as extending or
expanding capabilities and adapting for use in another
application or environment. Low quality levels predict
relatively high costs for new software use."
5.3.1. Expandability,_____________, Flexibility.___________. "The effort in
increasing software capabilities or performance or to
accommodate changes in requirements. The extent to which a
component allows new capabilities to be added and existing
capabilities to be easily tailored to user needs."
5.3.2. Interoperability.________________. "The effort in coupling software
of one system to software of one or more other systems. The
ability of APSEs to exchange data base objects and their
relationships in forms usable by components and user
programs without conversion. Interoperability is measured
by the degree to which this exchange can be accomplished
without conversion."
12
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
5.3.3. Reusability.___________. "The extent to which a component can
be adapted for use in another application."
5.3.4. Transportability.________________. "The extent to which a component
can be adapted for use in another environment (e.g.,
different host or target hardware, operating system, APSE).
The ability of a component to be installed on a different
APSE without change in functionality. Transportability is
measured in the degree to which this installation can be
accomplished without reprogramming."
5.4. Software-Oriented_________________ Criteria________
5.4.1. Accuracy.________. "Those characteristics of software which
provide the required precision in calculations and outputs."
5.4.2. Anomaly_______ Management,__________, Fault_____ or__ Error_____ Tolerance,_________,
Robustness.__________. "Those characteristics of software which
provide for continuity of operations under and recovery from
non-nominal conditions. The protection of a component from
itself, user errors, and system errors. The ability to
recover and provide meaningful diagnostics in the event of
unforeseen situations. A robust routine will avoid failing
for input values where the desired output is well-defined,
but the intermediate results of a straightforward
implementation may cause the routine to fail."
5.4.3. Application___________ Independence.____________. "Those characteristics of
software which determine its non-dependency on database
system, microcode, computer architecture, and algorithms."
5.4.4. Augmentability.______________. "Those characteristics of software
which provide for expansion of capability for functions and
data."
5.4.5. Autonomy.________. "Those characteristics of software which
determine its non-dependency on interfaces and functions."
5.4.6. Capacity.________. "The upper and lower limits of the
functions implemented by a tool."
5.4.7. Commonality___________ (Data_____ and___ Communication).______________. "Those
characteristics of software which provide for the use of
interface standards for protocols, routines, and data
representations. The set of assumptions made by the
component and made about the component by the remaining
components and the system in which it appears. Software
components have control, data, and service interfaces.
Included in this attribute is conformance to any existing
pertinent interface standards such as the CAIS.
13
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
5.4.8. Communication_____________ Effectiveness._____________. "Those characteristics
of the software which provide for minimum utilization of
communications resources in performing functions."
5.4.9. Completeness.____________. "The extent to which a component
provides the complete set of operations necessary to perform
a function."
5.4.10. Consistency.___________. "Those characteristics of software
which provide for uniform design and implementation
techniques and notation."
5.4.11. Cost.____. "The cost of a complete component or the
costs of features of a component. The cost of a component
may vary depending on delivery with source code or object
code only (for example). Other cost considerations are
installation, user assistance, and maintenance support."
5.4.12. Distributedness._______________. "Those characteristics of
software which determine the degree to which software
functions are geographically or logically separated within
the system."
5.4.13. Document________ Accessibility._____________. "Those characteristics of
software which provide for easy access to software and
selective use of components."
5.4.14. Functional__________ Overlap._______. "Those characteristics of
software which provide common functions to both systems."
5.4.15. Functional__________ Scope._____. "Those characteristics of
software which provide commonality of functions among
applications."
5.4.16. Generality.__________. "Those characteristics of software
which provide breadth to the functions performed with
respect to the application."
5.4.17. Granularity.___________. "The degree to which a component has
separate limited functions that are composible, user
selectable, and communicate through a common data base."
5.4.18. Maturity.________. "The extent to which a component has
been used in the development of deliverable software by
typical users and to which the feedback from that use has
been reflected in modifications to the component."
5.4.19. Modularity.__________. "Those characteristics of software
which provide a structure of highly cohesive components with
optimum coupling. The extent to which a component is
implemented in a hierarchical structure in which
identifiable functions are isolated in separate compilation
units."
14
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
5.4.20. Operability,___________, Communicativeness._________________. "Those
characteristics of software which determine operations and
procedures concerned with operation of software and which
provide useful inputs and outputs which can be assimilated.
The user/component dialog established to control the
execution of the component. This is driven by the set of
assumptions made by the component and made about the
component by the persons who use it."
5.4.21. Power._____. "The extent to which a component has
capabilities, such as default options and wild card
operations, that contribute to the effectiveness of the
user."
5.4.22. Processing__________ (Execution)___________ Effectiveness._____________. "Those
characteristics of the software which provide for minimum
utilization of processing resources in performing functions.
The choice between alternative algorithms based on those
taking the least amount of time."
5.4.23. Proprietary___________ Rights.______. "Restrictions on the release,
distribution, or use of a component. This includes so
called "data rights" restrictions."
5.4.24. Reconfigurability._________________. "Those characteristics of
software which provide for continuity of system operation
when one or more processors, storage units, or communication
links fails."
5.4.25. Rehostability._____________. "The ability of an APSE component
to be installed on a different host or different operating
system with needed reprogramming localized to the KAPSE or
machine dependencies."
5.4.26. Required________ Configuration._____________. "The amount and types of
hardware or software facilities needed for the operation of
a component. This includes primary and secondary storage
and any other required resources."
5.4.27. Retargetability._______________. "The ability of an APSE component
to accomplish its function with respect to another target.
The component may require modification."
5.4.28. Self-Descriptiveness.____________________. "Those characteristics of
software which provide explanation of the implementation of
functions. The technical data, including on-line,
documentation, listings, and printouts, which serve the
purpose of elaborating the design or details of a
component."
5.4.29. Simplicity.__________. "Those characteristics of software
which provide for definition and implementation of functions
in the most non-complex and understandable manner. A simple
15
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
program style is one which makes the program, as a whole,
easy to understand. Other things being equal, the style is
concise and straightforward. It makes use of process,
procedural, and data abstraction, as appropriate, to present
a clear exposition of the intent."
5.4.30. Software________ Production__________ Vehicle(s).__________. "The
methodology(ies), language(s), and technique(s) used to
produce the software related to a component."
5.4.31. Storage_______ Effectiveness._____________. "Those characteristics of
the software which provide for minimum utilization of
storage resources in performing functions. The choice
between alternative source code constructions based on those
taking the minimum number of words of object code or in
which the information-packing ... is high."
5.4.32. System______ Accessibility._____________. "Those characteristics of
software which provide for control and audit of accesses to
the software and data."
5.4.33. System______ Clarity._______. "Those characteristics of software
which provide for clear description of program structure in
a non-complex and understandable manner."
5.4.34. System______ Compatibility._____________. "Those characteristics of
software which provide the hardware, software, and
communication capability of two systems."
5.4.35. Traceability.____________. "Those characteristics of software
which provide a thread of origin from the implementation to
the requirements with respect to the specified development
envelope and operational environment."
5.4.36. Training.________. "Those characteristics of software which
provide transition from current operation and provide
initial familiarization. The extent to which training and
other user help is available from the vendor of a component
or from the component itself, including on-line,
documentation, listings, and printouts, which serve the
purpose of providing operating instructions for using the
component to obtain desired results."
5.4.37. Virtuality.__________. "Those characteristics of software
which present a system that does not require user knowledge
of the physical, logical, or topological characteristics."
5.4.38. Visibility,__________, Test____ Availability.____________. "Those
characteristics of software which provide status monitoring
of the development and operation. The availability of tests
that verify the correctness or effectiveness of a component
function or feature. These tests may also verify proper
response for an incorrect input or technique."
16
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
6. TAXONOMY of APSE FUNCTIONS
This taxonomy is divided at the top level into three
main areas:
- Transformation
- Management
- Analysis
6.1. Transformation.______________.
"Transformation features describe how the subject is
manipulated to accommodate the user's needs. They describe
what transformations take place as input to the tool is
processed."
6.1.1. Editing_______ (Text,_____, Data,____, Graphics)._________. "Selective revision
of computer-resident data."
6.1.2. Formatting__________ (MIL-STD, Table of Contents, Pre-Define
and User-Defined Forms). "Arranging data according to
predefined and/or user-defined conventions."
6.1.3. On-Line_______ Assistance__________ Processing.__________. "User interface that
is part of the input/output process of a programming support
environment (e.g., command assistance, assistance, on-line
tutoring, definition assistance, etc.)."
6.1.4. Sort/Merge.__________. "The process of arranging data in a
specific order (e.g., alphabetical order)."
6.1.5. Graphics________ Generation.__________. "The input, construction,
storage, retrieval, manipulation, alteration, and analysis
of pictorial data (e.g., generation of system architectures,
software designs, financial analysis, maps, graphs, etc.)."
6.1.6. Translation___________ (Requirements, Design, Code Compilation,
Execution and Interpretation). "The conversion from one
language form to another."
6.1.7. Synthesis_________ (Design, Requirements, Code, Decompilation
and Disassembly). "The generation of programs according to
predefined rules from a program specification or
intermediate language."
17
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
6.2. Management.__________.
"Features that aid the management or control of
system/software development."
6.2.1. Information___________ Management__________ (Data Base, Documentation,
Files, Electronic Mail, Electronic Conferencing,
Specifications, Program Library, Test Data, Evaluation
Results, Performance Monitoring). "The organization,
accessing, modification, dissemination, and processing of
information that is associated with the development of a
software system."
6.2.2. Project_______ Management__________ (Cost Estimation, Quality
Specification, Scheduling, Work Breakdown Structure,
Resource Estimation, Tracking, Configuration Management,
Quality Assessment). "The management of a system/software
development project."
6.2.3. Computer________ System______ Management__________ (Command Language
Processing, Input/Output Support, Kernel, Math/Statistics,
Runtime Environment, Import/Export). "The management of
hardware/software architectures to support the life cycle
software engineering environment. Such services include:
creating, scheduling, and removing tasks; switching the
processor among tasks; sending messages between tasks;
providing direct and import/export access; managing
distributed systems; sending files from one host machine to
another on a network, etc."
6.3. Analysis.________.
"The features that provide an examination of a substantial
whole to determine both qualitative and quantitative
properties."
6.3.1. Static______ Analysis________ (Comparison, Spelling Checking, Data
Flow Analysis, Functional Analysis, Interface Analysis,
Traceability Analysis, Testability Analysis, Test Condition
Analysis, Quality Analysis, Complexity Measurement,
Correctness Checking, Completeness Checking, Consistency
Checking, Reuseability Analysis, Syntax and Semantics
Checking, Reachability Analysis, Cross Reference,
Maintainability Analysis, Invocation Analysis, Scanning,
Structured Walkthrough, Auditing, Error Checking,
Statistical Analysis, Statistical Profiling, Structure
Checking, Type Analysis, Units Analysis, I/O Specification
Analysis, Sizing Analysis). "Static analysis features
specify operations on the subject without regard to the
executability of the subject. They describe the manner in
which the subject is analyzed."
18
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
6.3.2. Dynamic_______ Analysis________ (Requirements Simulation,
Requirements Prototyping, Simulation and Modeling, Design
Prototyping, Debugging, Executable Assertion Checking,
Constraint Evaluation, Coverage/Frequency Analysis, Mutation
Analysis, Testing, Regression Testing, Resource Utilization,
Emulation, Timing, Tuning, Reliability Analysis, Real Time
Analysis). "Dynamic analysis features specify operations
that are determined during or after execution takes place.
Dynamic analysis features differ from those classified as
static by virtue of the fact that they require some form of
symbolic or machine execution. They describe the techniques
used by the tool to derive meaningful information about a
program's execution behavior."
6.3.3. Formal______ Verification.____________. "The use of rigorous
mathematical techniques to prove the consistency between an
algorithmic solution and a rigorous, complete specification
of the intent of the solution."
6.3.4. Symbolic________ Execution._________. "The reconstruction of the
logic and computations along a program path by executing the
path with symbolic rather than actual values of data."
6.3.5. Problem_______ Report______ Analysis.________. "The analysis of problem
reports for the purpose of determining the validity of the
reported problem and a corrective action."
6.3.6. Change______ Request_______ and___ Change______ Impact______ Analysis.________. "The
Change Request Analysis is the analysis of change requests
to determine the necessity of the change, technical/economic
impacts, and approach to accomplishing the change. The
Change Impact Analysis is the ability to determine, for a
proposed support/enhancement operation, the impact of
proposed changes to the software system."
19
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
TABLE of CONTENTS_____ __ ________
1. INTRODUCTION .......................................... 1
2. APSE DEFINITIONS and ALTERNATIVE NAMES ................ 2
2.1. PSE .............................................. 2
2.2. APSE ............................................ 2
3. LIFE CYCLE PHASES .................................... 3
3.1. System Concepts .................................. 3
3.2. System Requirements Analysis .................... 3
3.3. Software Requirements Analysis. .................. 4
3.4. Preliminary Design. .............................. 4
3.5. Detailed Design. ................................ 4
3.6. Coding and Unit Testing. ........................ 4
3.7. CSC Integration and Testing. .................... 4
3.8. CSCI Testing. .................................... 4
3.9. System Integration and Testing. .................. 5
3.10. Operational Testing and Evaluation. ............ 5
3.11. Change Requirements. ............................ 5
3.12. Global. ........................................ 5
4. APSE TOOL TAXONOMY .................................... 6
4.1. Computer Management System. ...................... 6
4.2. Project Management System. ...................... 6
4.3. Compilation System. .............................. 7
4.4. Document System. ................................ 7
4.5. Desktop System. .................................. 8
4.6. Static Analyzer System. .......................... 8
4.7. Dynamic Analyzer System. ........................ 9
5. ATTRIBUTES of an APSE ............................... 11
5.1. Performance. ................................... 11
5.2. Design. ......................................... 12
5.3. Adaptation. ..................................... 12
5.4. Software-Oriented Criteria ..................... 13
6. TAXONOMY of APSE FUNCTIONS ........................... 17
6.1. Transformation. ................................. 17
6.2. Management. ..................................... 18
6.3. Analysis. ....................................... 18
ii
Selected Taxonomies
E&V Reference Manual Version 1.0, July 1988
This page intentionally blank
iii
--::::::::::
--apsetool.ptf
--::::::::::
.lm 11
.rm 70
.nap
.de SEC0
.nr c +1
.nr a 0
.sp 2
.ce
@nc. @1 @2 @3 @4 @5 @6 @7 @8 @9
.sp 2
.cl
.cl 0 @nc. @1 @2 @3 @4 @5 @6 @7 @8 @9
.en
.de SEC1
.sp 4
.ne 10
.nr a +1
.nr b 0
@nc.@na.
.ul
@1 @2 @3 @4 @5 @6 @7 @8 @9
.cl 1 @nc.@na. @1 @2 @3 @4 @5 @6 @7 @8 @9
.en
.de SEC2
.sp 1
.nr b +1
@nc.@na.@nb.
.ul
@1 @2 @3 @4 @5 @6 @7 @8 @9
.en
.nr c 0
.de PP
.sp 1
.ti +5
.en
.sp 15
.ce on
SELECTED TAXONOMIES
from the
E&V REFERENCE MANUAL, VERSION 1.0
July, 1988
Interim Report for Period 6/85 - 3/88
.sp 4
Prepared for:
Ada Software Repository
.sp 2
Prepared by:
Richard Conn
.ce off
.sp 4
The information in this document is, for the most part, extracted literally
from the
.ul
E&V Reference Manual, Version 1.0.
.br
.nlheader 3
.he 1 //Selected Taxonomies//
.he 2 /E&V Reference Manual//Version 1.0, July 1988/
.bp 1
.fo //#//
.SEC0 INTRODUCTION
.PP
From the Executive Summary of the E&V Reference Manual:
.PP
"The Ada community, including government, industry, and academic personnel,
needs the capability to assess APSEs (Ada Programming Support
Environments) and their components and to determine their conformance
to applicable standards (e.g., DOD-STD-1838, the CAIS standard). The
technology required to fully satisfy this need is extensive and largely
unavailable; it cannot be acquired by a single government-sponsored,
professional society-sponsored, or private effort. The purpose of the APSE
Evaluation and Validation (E&V) task is to provide a focal point for
addressing the need by:
.li +2
.ri +2
.PP
"(1) Identifying and defining specific technology requirements,
.PP
"(2) Developing selected elements of the required technology,
.PP
"(3) Encouraging others to develop some elements, and
.PP
"(4) Collecting information describing existing elements.
.li -2
.ri -2
.sp 1
"This information will be made available to DoD components, other
government agencies, industry and academia.
.PP
"The purpose of the E&V Reference Manual (this document) is to provide
information that will help users to:
.li +2
.ri +2
.PP
"(1) Gain an overall understanding of APSEs and approaches to their
assessment,
.PP
"(2) Find useful reference information (e.g., definitions) about
specific elements and relationships between elements, and
.PP
"(3) Find criteria and metrics for assessing tools and APSEs, and
techniques for performing such assessment.
.li -2
.ri -2
.sp 1
"The latter are to be found (or referenced) in a companion document called
the E&V Guidebook."
.br
.bp
.SEC0 APSE DEFINITIONS and ALTERNATIVE NAMES
.SEC1 PSE
.PP
PSE stands for "Programming Support Environment," and is defined in the
"IEEE Standard Glossary of Software Engineering Terminology" (dated 1983) as:
.in +5
.rm -5
"An integrated collection of tools accessed via a single command language
to provide programming support capabilities throughout the software
life-cycle. The environment typically includes tools for design, editing,
compiling, loading, testing, configuration management, and project
management."
.rm +5
.in -5
.SEC1 APSE
.PP
APSE stands for "Ada Programming Support Environment." It is a programming
support environment for the development of software written in the
Ada computer programming language.
.PP
The "E&V Reference Manual" goes on to describe various ways of viewing an
APSE from various perspectives. It also describes key attributes of an APSE.
.bp
.SEC0 LIFE CYCLE PHASES
.PP
The life cycle phases recommended in the "E&V Reference Manual" are:
.sp
.in +5
.rm -5
.ti -2
- System Concepts
.sp 1
.ti -2
- System Requirements Analysis
.sp 1
.ti -2
- Software Requirements Analysis
.sp 1
.ti -2
- Preliminary Design
.sp 1
.ti -2
- Detailed Design
.sp 1
.ti -2
- Coding and Unit Testing
.sp 1
.ti -2
- CSC Integration and Testing
.sp 1
.ti -2
- CSCI Testing
.sp 1
.ti -2
- System Integration and Testing
.sp 1
.ti -2
- Operational Testing and Evaluation
.sp 1
.ti -2
- Change Requirements
.sp 1
.ti -2
- Global
.rm +5
.in -5
.SEC1 System Concepts
.SEC1 System Requirements Analysis
.SEC1 Software Requirements Analysis.
"Those activities of the life cycle pertaining to the establishment
of system requirements and a complete set of functional, performance,
and interface requirements for each CSCI."
.SEC1 Preliminary Design.
"Those activities in the life cycle pertaining to the development of
a modular, top-level design of each CSCI from the software requirements."
.SEC1 Detailed Design.
"Those activities in the life cycle pertaining to the development of a
modular, detailed design of each CSCI from the preliminary design."
.SEC1 Coding and Unit Testing.
"Those activities in the life cycle pertaining to the coding and
testing of each unit comprising the detailed design."
.SEC1 CSC Integration and Testing.
"Those activities in the life cycle pertaining to the integration of
units of code and the performance of informal tests on
aggregates of integrated units."
.SEC1 CSCI Testing.
"Those activities in the life cycle pertaining to the conduct of formal
tests on each CSCI and the recording/analysis of test results."
.SEC1 System Integration and Testing.
"Those activities in the life cycle pertaining to the successive
integration and testing of CSCIs and HWCIs to validate that the complete system
is properly integrated and satisfies system requirements."
.SEC1 Operational Testing and Evaluation.
"Those activities in the life cycle where the system is tested and
evaluated in surroundings which are as operationally realistic as possible
to determine that the system will satisfactorily perform the mission
for which it was designed."
.SEC1 Change Requirements.
"Those activities in the life cycle pertaining to the support
(error detection/correction) and enhancement of the operational CSCIs.
Often, this activity will result in a series of software developments
potentially requiring tool features (besides Global features)
different from all preceding life cycle activities."
.SEC1 Global.
"Represents those general support features which include common
(in implementation and use) software elements or functions. Global
features can be included in each life cycle activity."
.bp
.SEC0 APSE TOOL TAXONOMY
.PP
"APSEs are the highest levels of toolset. APSEs should contain all the tools
and toolsets needed to support the full spectrum of project activities."
.SEC1 Computer Management System.
"Those tools needed to access, use, and maintain the hardware and
software which consists of the APSE and the system on which it runs."
.SEC2 Command Language Processor
.SEC2 Archive, Backup, and Retrieval System
.SEC2 Security System
.SEC2 Job Scheduler
.SEC2 Resource Controller
.SEC2 File Manager
.SEC2 Import/Export System
.SEC2 On-Line Assistance Processor
.SEC2 Data Base Manager
.SEC1 Project Management System.
"Those tools needed to plan, develop, and maintain an applications system."
.SEC2 Cost Estimator
.SEC2 Quality Analyzer
.SEC2 Scheduler
.SEC2 Work Breakdown Structure
.SEC2 Resource Estimator
.SEC2 Tracking
.SEC2 Configuration Manager
.SEC2 Problem Report Analyzer
.SEC2 Change Request Analyzer
.SEC1 Compilation System.
"Those tools needed to produce and run software systems."
.SEC2 Program Library Manager
.SEC2 Syntax-Directed Editor
.SEC2 Compiler
.SEC2 Assembler
.SEC2 Linker
.SEC2 Loader
.SEC2 Interpreter
.SEC2 Runtime Library
.SEC1 Document System.
"Those tools needed to develop and produce documents."
.SEC2 Document Manager
.SEC2 Word Processor
.SEC2 Spell Checker
.SEC2 Graphics Generator
.SEC2 Formatter
.SEC1 Desktop System.
"Those tools needed to do the every-day, administrative tasks of
business."
.SEC2 Spreadsheet
.SEC2 Calculator
.SEC2 Address Book
.SEC2 Electronic Mail
.SEC2 Phone Book
.SEC2 Electronic Conferencing
.SEC2 Calendar
.SEC2 Dictionary
.SEC1 Static Analyzer System.
"Those tools needed to do analysis of software systems without actually
executing the program(s) being analyzed."
.SEC2 Comparator
.SEC2 Data Flow Analyzer
.SEC2 Functional Analyzer
.SEC2 Interface Analyzer
.SEC2 Traceability Analyzer
.SEC2 Testability Analyzer
.SEC2 Test Condition Analyzer
.SEC2 Quality Analyzer
.SEC2 Complexity Measurer
.SEC2 Correctness Checker
.SEC2 Completeness Checker
.SEC2 Consistency Checker
.SEC2 Reusability Analyzer
.SEC2 Syntax and Semantics Checker
.SEC2 Reachability Analyzer
.SEC2 Cross Referencer
.SEC2 Maintainability Analyzer
.SEC2 Invocation Analyzer
.SEC2 Scanner
.SEC2 Structured Walkthrough Tool
.SEC2 Auditor
.SEC2 Error Checker
.SEC2 Statistical Analyzer
.SEC2 Statistical Profiler
.SEC2 Structure Checker
.SEC2 Type Analyzer
.SEC2 Units Analyzer
.SEC2 I/O Specification Analyzer
.SEC2 Sizing Analyzer
.SEC1 Dynamic Analyzer System.
"Those tools needed to do analysis of software systems while
actually executing the program(s) or some representation of the system
being analyzed."
.SEC2 Requirements Simulator
.SEC2 Requirements Prototype
.SEC2 Simulation and Modelling Tools
.SEC2 Design Prototype
.SEC2 Debugger
.SEC2 Executable Assertion Checker
.SEC2 Constraint Evaluator
.SEC2 Coverage/Frequency Analyzer
.SEC2 Mutation Analyzer
.SEC2 Testing Analyzer
.SEC2 Regression Testing Analyzer
.SEC2 Resource Utilization Analyzer
.SEC2 Emulator
.SEC2 Timing Analyzer
.SEC2 Tuning Analyzer
.SEC2 Reliability Analyzer
.SEC2 Real Time Analyzer
.SEC2 Formal Verification System
.SEC2 Symbolic Execution System
.bp
.SEC0 ATTRIBUTES of an APSE
.PP
"Attributes are the characteristics of tools or "whole APSEs" which the
E&V user evaluates (or validates) to make assessments and
comparisons." At the top level, three main attributes are of concern:
.sp 1
.in +5
.rm -5
.ti -2
- Performance: how well does it function?
.sp 1
.ti -2
- Design: how well is it designed?
.sp 1
.ti -2
- Adaptation - how adaptable is it?
.sp 1
.ti -2
- Software-Oriented Criteria
.br
.rm +5
.in -5
.sp 1
.SEC1 Performance.
"Performance quality factors deal both with the ability of the
software to function and with error occurrences that affect software
functioning. Low quality factors predict poor software performance."
.SEC2 Efficiency.
"Efficiency deals with utilization of resources. The extent to which
a component fulfills its purpose using a minimum of computing resources.
Of course, many of the ways of coding efficiently are not necessarily efficient
in the sense of being cost-effective, since transportability, maintainability,
etc., may be degraded as a result."
.SEC2 Integrity.
"Integrity deals with software failures due to unauthorized access.
The extent to which access to a component or associated data by
unauthorized persons can be controlled."
.SEC2 Reliability.
"Reliability concerns any software failure. The extent to which a
component can be expected to perform its intended functions in a
satisfactory manner."
.SEC2 Survivability.
"Survivability deals with the continued performance of software
(e.g., in a degraded mode) even when a portion of the system has failed."
.SEC2 Usability.
"Extent to which resources required to acquire, install, learn, operate,
prepare input for, and interpret output of a component are minimized."
.SEC1 Design.
"Design quality factors deal mainly with software failure and correction.
Low quality levels usually result in repeating a portion of the
development process (e.g., redesign, recode, reverify);
hence the term design."
.SEC2 Correctness.
"The extent to which software design and implementation conform to
specifications and standards. Criteria of correctness deal exclusively
with design and documentation formats. Agreement between a component's total
response and the stated response in the functional specification (functional
correctness), and/or between the component as coded and the
programming specification (algorithmic correctness)."
.SEC2 Maintainability.
"The ease of effort in locating and fixing software failures. The
extent to which a component facilitates updating to satisfy new
requirements or to correct deficiencies. This implies that the component
is understandable, testable, and modifiable."
.SEC2 Verifiability, Testability.
"Software design characteristics affecting the effort to verify software
operation and performance. The extent to which a component facilitates the
establishment of verification criteria and supports evaluation of
its performance. This implies that requirements are matched to specific
modules, or diagnostic capabilities are provided, etc."
.SEC1 Adaptation.
"Adaptation quality factors deal mainly with using software beyond its
original requirements, such as extending or expanding capabilities and
adapting for use in another application or environment. Low quality
levels predict relatively high costs for new software use."
.SEC2 Expandability, Flexibility.
"The effort in increasing software capabilities or performance or to
accommodate changes in requirements. The extent to which a component
allows new capabilities to be added and existing capabilities to be
easily tailored to user needs."
.SEC2 Interoperability.
"The effort in coupling software of one system to software of one or more
other systems. The ability of APSEs to exchange data base objects and their
relationships in forms usable by components and user programs without
conversion. Interoperability is measured by the degree to which this
exchange can be accomplished without conversion."
.SEC2 Reusability.
"The extent to which a component can be adapted for use in another application."
.SEC2 Transportability.
"The extent to which a component can be adapted for use in another
environment (e.g., different host or target hardware, operating system,
APSE). The ability of a component to be installed on a different APSE
without change in functionality. Transportability is measured in the
degree to which this installation can be accomplished without reprogramming."
.SEC1 Software-Oriented Criteria
.SEC2 Accuracy.
"Those characteristics of software which provide the required
precision in calculations and outputs."
.SEC2 Anomaly Management, Fault or Error Tolerance, Robustness.
"Those characteristics of software which provide for continuity of
operations under and recovery from non-nominal conditions. The
protection of a component from itself, user errors, and system errors.
The ability to recover and provide meaningful diagnostics in the event of
unforeseen situations. A robust routine will avoid failing for input
values where the desired output is well-defined, but the intermediate
results of a straightforward implementation may cause the routine to
fail."
.SEC2 Application Independence.
"Those characteristics of software which determine its non-dependency
on database
system, microcode, computer architecture, and algorithms."
.SEC2 Augmentability.
"Those characteristics of software which provide for expansion of
capability for functions and data."
.SEC2 Autonomy.
"Those characteristics of software which determine its non-dependency on
interfaces and functions."
.SEC2 Capacity.
"The upper and lower limits of the functions implemented by a tool."
.SEC2 Commonality (Data and Communication).
"Those characteristics of software which provide for the use of
interface standards for protocols, routines, and data representations.
The set of assumptions made by the component and made about the
component by the remaining components and the system in which it appears.
Software components have control, data, and service interfaces.
Included in this attribute is conformance to any existing pertinent
interface standards such as the CAIS.
.SEC2 Communication Effectiveness.
"Those characteristics of the software which provide for minimum
utilization of communications resources in performing functions."
.SEC2 Completeness.
"The extent to which a component provides the complete set of operations
necessary to perform a function."
.SEC2 Consistency.
"Those characteristics of software which provide for uniform design and
implementation techniques and notation."
.SEC2 Cost.
"The cost of a complete component or the costs of features of a component.
The cost of a component may vary depending on delivery with source code or
object code only (for example). Other cost considerations are installation,
user assistance, and maintenance support."
.SEC2 Distributedness.
"Those characteristics of software which determine the degree to which software
functions are geographically or logically separated within the system."
.SEC2 Document Accessibility.
"Those characteristics of software which provide for easy access to software
and selective use of components."
.SEC2 Functional Overlap.
"Those characteristics of software which provide common functions to both
systems."
.SEC2 Functional Scope.
"Those characteristics of software which provide commonality of functions
among applications."
.SEC2 Generality.
"Those characteristics of software which provide breadth to the functions
performed with respect to the application."
.SEC2 Granularity.
"The degree to which a component has separate limited functions that are
composible, user selectable, and communicate through a common data base."
.SEC2 Maturity.
"The extent to which a component has been used in the development of
deliverable software by typical users and to which the feedback from that
use has been reflected in modifications to the component."
.SEC2 Modularity.
"Those characteristics of software which provide a structure of highly
cohesive components with optimum coupling. The extent to which a
component is implemented in a hierarchical structure in which identifiable
functions are isolated in separate compilation units."
.SEC2 Operability, Communicativeness.
"Those characteristics of software which determine operations and
procedures concerned with operation of software and which provide useful
inputs and outputs which can be assimilated. The user/component dialog
established to control the execution of the component. This is driven by
the set of assumptions made by the component and made about the component
by the persons who use it."
.SEC2 Power.
"The extent to which a component has capabilities, such as default options
and wild card operations, that contribute to the effectiveness of the user."
.SEC2 Processing (Execution) Effectiveness.
"Those characteristics of the software which provide for minimum utilization
of processing resources in performing functions. The choice between
alternative algorithms based on those taking the least amount of time."
.SEC2 Proprietary Rights.
"Restrictions on the release, distribution, or use of a component.
This includes so called "data rights" restrictions."
.SEC2 Reconfigurability.
"Those characteristics of software which provide for continuity of
system operation when one or more processors, storage units, or communication
links fails."
.SEC2 Rehostability.
"The ability of an APSE component to be installed on a different host or
different operating system with needed reprogramming localized to the
KAPSE or machine dependencies."
.SEC2 Required Configuration.
"The amount and types of hardware or software facilities needed for the
operation of a component. This includes primary and secondary storage and
any other required resources."
.SEC2 Retargetability.
"The ability of an APSE component to accomplish its function with respect
to another target. The component may require modification."
.SEC2 Self-Descriptiveness.
"Those characteristics of software which provide explanation of the
implementation of functions. The technical data, including on-line,
documentation, listings, and printouts, which serve the purpose of
elaborating the design or details of a component."
.SEC2 Simplicity.
"Those characteristics of software which provide for definition and
implementation of functions in the most non-complex and understandable
manner. A simple program style is one which makes the program, as a whole,
easy to understand. Other things being equal, the style is concise and
straightforward. It makes use of process, procedural, and data
abstraction, as appropriate, to present a clear exposition of the intent."
.SEC2 Software Production Vehicle(s).
"The methodology(ies), language(s), and technique(s) used to produce the
software related to a component."
.SEC2 Storage Effectiveness.
"Those characteristics of the software which provide for minimum utilization
of storage resources in performing functions. The choice between
alternative source code constructions based on those taking the
minimum number of words of object code or in which the
information-packing ... is high."
.SEC2 System Accessibility.
"Those characteristics of software which provide for control and audit of
accesses to the software and data."
.SEC2 System Clarity.
"Those characteristics of software which provide for clear description of
program structure in a non-complex and understandable manner."
.SEC2 System Compatibility.
"Those characteristics of software which provide the hardware,
software, and communication capability of two systems."
.SEC2 Traceability.
"Those characteristics of software which provide a thread of origin from the
implementation to the requirements with respect to the specified
development envelope and operational environment."
.SEC2 Training.
"Those characteristics of software which provide transition from current
operation and provide initial familiarization. The extent to which training
and other user help is available from the vendor of a component or from the
component itself, including on-line, documentation, listings, and
printouts, which serve the purpose of providing operating instructions
for using the component to obtain desired results."
.SEC2 Virtuality.
"Those characteristics of software which present a system that does not
require user knowledge of the physical, logical, or topological
characteristics."
.SEC2 Visibility, Test Availability.
"Those characteristics of software which provide status monitoring of
the development and operation. The availability of tests that verify
the correctness or effectiveness of a component function or feature.
These tests may also verify proper response for an incorrect input or
technique."
.bp
.SEC0 TAXONOMY of APSE FUNCTIONS
.PP
This taxonomy is divided at the top level into three main areas:
.sp 1
.in +5
.rm -5
.ti -2
- Transformation
.sp 1
.ti -2
- Management
.sp 1
.ti -2
- Analysis
.rm +5
.in -5
.sp 1
.SEC1 Transformation.
"Transformation features describe how the subject is manipulated to accommodate
the user's needs. They describe what transformations take place as input to
the tool is processed."
.SEC2 Editing (Text, Data, Graphics).
"Selective revision of computer-resident data."
.SEC2 Formatting
(MIL-STD, Table of Contents, Pre-Define and User-Defined Forms).
"Arranging data according to predefined and/or user-defined conventions."
.SEC2 On-Line Assistance Processing.
"User interface that is part of the input/output process of a programming
support environment (e.g., command assistance, assistance, on-line tutoring,
definition assistance, etc.)."
.SEC2 Sort/Merge.
"The process of arranging data in a specific order (e.g., alphabetical order)."
.SEC2 Graphics Generation.
"The input, construction, storage, retrieval, manipulation, alteration,
and analysis of pictorial data (e.g., generation of system architectures,
software designs, financial analysis, maps, graphs, etc.)."
.SEC2 Translation
(Requirements, Design, Code Compilation, Execution and Interpretation).
"The conversion from one language form to another."
.SEC2 Synthesis
(Design, Requirements, Code, Decompilation and Disassembly).
"The generation of programs according to predefined rules from a program
specification or intermediate language."
.SEC1 Management.
"Features that aid the management or control of system/software
development."
.SEC2 Information Management
(Data Base, Documentation, Files, Electronic Mail,
Electronic Conferencing, Specifications, Program Library, Test Data,
Evaluation Results, Performance Monitoring).
"The organization, accessing, modification, dissemination, and processing of
information that is associated with the development of a software system."
.SEC2 Project Management
(Cost Estimation, Quality Specification, Scheduling,
Work Breakdown Structure, Resource Estimation, Tracking, Configuration
Management, Quality Assessment).
"The management of a system/software development project."
.SEC2 Computer System Management
(Command Language Processing, Input/Output
Support, Kernel, Math/Statistics, Runtime Environment, Import/Export).
"The management of hardware/software architectures to support the life cycle
software engineering environment. Such services include: creating, scheduling,
and removing tasks; switching the processor among tasks;
sending messages between tasks; providing direct and import/export
access; managing distributed systems; sending files from one host
machine to another on a network, etc."
.SEC1 Analysis.
"The features that provide an examination of a substantial whole to determine
both qualitative and quantitative properties."
.SEC2 Static Analysis
(Comparison, Spelling Checking, Data Flow Analysis,
Functional Analysis, Interface Analysis, Traceability Analysis,
Testability Analysis, Test Condition Analysis, Quality Analysis,
Complexity Measurement, Correctness Checking, Completeness Checking,
Consistency Checking, Reuseability Analysis, Syntax and Semantics
Checking, Reachability Analysis, Cross Reference, Maintainability
Analysis, Invocation Analysis, Scanning, Structured Walkthrough,
Auditing, Error Checking, Statistical Analysis, Statistical Profiling,
Structure Checking, Type Analysis, Units Analysis, I/O Specification
Analysis, Sizing Analysis).
"Static analysis features specify operations on the subject without regard
to the executability of the subject. They describe the manner in which
the subject is analyzed."
.SEC2 Dynamic Analysis
(Requirements Simulation, Requirements Prototyping,
Simulation and Modeling, Design Prototyping, Debugging,
Executable Assertion Checking, Constraint Evaluation,
Coverage/Frequency Analysis, Mutation Analysis, Testing,
Regression Testing, Resource Utilization, Emulation, Timing,
Tuning, Reliability Analysis, Real Time Analysis).
"Dynamic analysis features specify operations that are determined during or
after execution takes place. Dynamic analysis features differ from those
classified as static by virtue of the fact that they require some form of
symbolic or machine execution. They describe the techniques used by the
tool to derive meaningful information about a program's execution behavior."
.SEC2 Formal Verification.
"The use of rigorous mathematical techniques to prove the consistency between
an algorithmic solution and a rigorous, complete specification of the intent
of the solution."
.SEC2 Symbolic Execution.
"The reconstruction of the logic and computations along a program path by
executing the path with symbolic rather than actual values of data."
.SEC2 Problem Report Analysis.
"The analysis of problem reports for the purpose of determining the validity
of the reported problem and a corrective action."
.SEC2 Change Request and Change Impact Analysis.
"The Change Request Analysis is
the analysis of change requests to determine the necessity of the change,
technical/economic impacts, and approach to accomplishing the change.
The Change Impact Analysis is the ability to determine, for a proposed
support/enhancement operation, the impact of proposed changes to the
software system."
.bp 2
.pn lower_roman
.sp 4
.ce
.ul
TABLE of CONTENTS
.sp 2
.pc
.bp
.sp 20
.ce
This page intentionally blank
--::::::::::
--hdbk1804.doc
--::::::::::
DRAFT
ADA STYLE GUIDE HANDBOOK
MIL-HDBK-1804
TABLE OF CONTENTS
1.0 SCOPE
1.1 Introduction
1.2 Scope
1.3 Goals
2.0 REFERENCED DOCUMENTS
2.1 Usage
2.2 Referenced Documents
3.0 DEFINITIONS
3.1 Introduction
3.2 Handbook
3.3 Standard
4.0 GENERAL REQUIREMENTS
5.0 SPECIFIC GUIDELINES
5.1 Introduction
5.2 Lexical Elements
5.3 Declarations and Types
5.4 Names and Expressions
5.5 Statements
5.6 Subprograms
5.7 Packages
5.8 Visibility
5.9 Tasks
5.10 Program Structure and Compilation Issues
5.11 Exceptions
5.12 Generic Units
5.13 Representation Clauses and Implementation-Dependent Features
5.14 Input-Output
1. SCOPE.
1.1 Introduction. Ada is a programming language of considerable expressive
power. ANSI/MIL-STD-1815A, Ada Programming Language, provides a thorough
definition of the language. However, it does not offer sufficient guidance on
the appropriate use of Ada's powerful features. This document was developed
to address "program style" issues and is presented as if the reader does not
have a mentor to explain all the whys and wherefores. It is for this reason
the document goes beyond styling techniques in some sections by showing
what is "good and proper" Ada constructs, denoting what to avoid, or why
certain constructs are used in a particular manner (proper software
engineering techniques are also "good style"). Besides, both facets are
needed in the code produced for the next person in line - the maintainer
and/or reuser.
1.2 Scope. Program source code serves two functions: to specify an
algorithm to be performed on a computer, and to communicate this algorithmic
design to other human readers. Program style relates to how well a program
meets the second function. It is a consistent manner of using the features of
a programming language to promote the maintainability, readability and
understandability of a program. This is a matter of the form of the final,
delivered, program source code, as opposed to the process of developing the
code.
1.3 Goals.
a. While some of what constitutes "good style" is subjective and
somewhat arbitrary, it is important that the style of a program be consistent
throughout the program. The primary goal of this guide is to promote such
consistent use of good style across large numbers of Ada programs. The whole
intent of "good style" is to increase the readability of these programs.
Therefore, these guidelines follow from general principles of program
readability and understandability.
b. The program should reflect the natural levels of abstraction in the
problem domain, so that the reader can reasonably comprehend each level
individually. Just as entites in real world applications have structure and
organization, so should Ada software systems. Furthermore, on a gobal level,
the overall software architecture should exhibit clarity and be readilly
comprehended. Ada coding style plays an important role in attainment of
these goals.
c. There are several features in Ada which are unfamiliar to many
programmers. There is thus a tendency to either underuse these features or to
use them inappropriately. A feature of Ada should generally not be ignored,
but neither should it be used in excess. The guidelines highlight the proper
use of Ada features. Keep in mind, there are features in the Ada language
that when used, are considered poor programming and/or software engineering
practices. Most of this knowledge has become apparent through the use of the
language. This guide's intent is to alert the reader of these practices; and
although they are functionally correct, should be avoided. (Words to that
effect will be used).
d. The textual format of a program should be pleasing to the eye and
promote the readability and understandability of the program. The format
should highlight the structure of a program and the role of a program as a
model of the problem domain. Just as the careful layout of a book can enhance
written communication, the careful layout of a program can enhance the
communication of algorithmic design to another human. The consistent use of
formatting style is especially important, because it allows readers to become
accustomed to the familiar layout of the program constructs. An automated
formatting program is particularly helpful, but even in the absence of such a
tool, much can be gained from a common format style.
2. REFERENCED DOCUMENTS
2.1 Usage.
a. This is not a static document. Other references need to be consulted
to provide a valid mix of ideas and "legal" practices when coding Ada. Where
applicable, conformity among the references should be obtained. Instances,
for example, where adopting an ISO or ARTEWG practice does not have a negative
impact, should be encouraged.
b. A listing of other references beside the one given in paragraph 2.2
will not be made. Other documents were referenced; however, to list them
could be construed as an endorsement of the document to the exclusion of
others. Better none than to miss one.
2.2 Reference documents. ANSI/MIL-STD-1815A, Ada Programming Language.
3. DEFINITIONS
3.1 Introduction. The definitions and acronyms provided in Ada Reference
Manual - ANSI/MIL-STD-1815A are applicable for use with this handbook. Since
this handbook is intended to be a companion document to the Ada Programming
Language manual, the definitions and acronyms are not restated here.
3.2 Handbook. The term "Handbook" (capitalization intended) refers to this
document, MIL-HDBK-1804, Ada Style Guide Handbook. This simplification is
used to improve readability.
3.3 Standard. The term "Standard" (capitalization intended) refers to
ANSI/MIL-STD-1815A, Ada Programming Language. This simplification is to
improve readability.
4. GENERAL REQUIREMENTS
NOT APPLICABLE
5. SPECIFIC GUIDELINES
5.1 Introduction. This section contains fourteen major subparagraphs (5.1
through 5.14) corresponding to the fourteen chapters of ANSI/MIL-STD-1815A,
Ada Programming Language. This provides a standard frame of reference for the
discussion of Ada features. Where appropriate, the guide includes examples
and justifications for various guidelines. Some of the major subparagraphs,
themselves, have an "Examples" subparagraph giving additional, longer examples
for the topic. When more than one example is shown, the order of preference
will be with the first example, then the second, etc.
5.1.1 Correlation. Each major subparagraph bears the same title as its
corresponding chapter in the Standard, e.g. Lexical elements is chapter 5.2
in this style guide. In the Standard, the basic definition starts in chapter
2.
5.1.2 Handbook Format.
a. Some constraints are implicity included in this Handbook. The reason
- the explanations are directed towards the Management Information Systems
environment moreso than the real-time, embedded systems environment. (Granted,
Ada was initially intended for the latter). Problems in "style" may occur
when information presented is slanted towards large memory features instead of
constrained, limited memory systems. (Block statements come to mind as an
example). Therefore, for real-time programmers/maintainers, comments starting
with "REAL_TIME" will be included and are directed to their use.
b. Non-numbered paragraphs are editorial comments included to provide
further clarifications. Also, information in this category and begun with
the notation of "NOTE:", are of specific interest and special attention should
be paid to them.
5.1.3 Non-compliance. It should be noted that some compilers contain
restrictions that may not allow compliance with all of the guidelines contained
in Section 5.2 and beyond. An example would be the inability of a system to
allow the use of the underscore. The Standard, chapter 2.1, "Charater Set",
includes the underscore as an allowable special character. Obviously, a
physical impasse is apparent, and as such, should be documented up front in
the program. This is a basic premise of this guide - if you cannot comply
with the guidance, information stating such should appear in the program.
5.1.4 Basic Style Format.
a. The emphasis in style is to have distinct, recognizable parts. That
is, information to be defined should be on one side, information doing the
defining on the other; or, on one line, with the defining components on the
following line(s). The right-left concept comes more into play with the usage
of the assignment operator (see 5.2.2.7). The one-line-next-line concept will
cover the majority of style formating use.
b. The reasons for promoting the one-line-next-line style are reada-
bility and understandability. From the first character on a line to its
associated semicolon, some information contained between the two must be
dominant, some must be subordinate. Whether all the information is on one
line or many does not matter syntactically, it does for readability and
understandability. Therefore, to promote easier end of line comments,
maintainability, as well as readability and understandability, the following
basic style is recommended (exceptions are delineated in other chapter 5
subchapters):
1) Reserved words denoting various elements of an Ada program and
their associated names should be on one line, their subordinate information
on the succeeding line(s), e.g.
procedure
[];
function
[];
2) Type declarations or other reserve word phrases ending with a verb
should be on one line, its subordinate information on the succeeding line(s),
e.g.
type (identifier> is
;
task type is
;
end ;
task body is separate;
:
while loop
end loop ;
3) Objects, strings and similar declarations where the colon
differentiates the identifier from the definition, should be "muliti-lined"
by placing the identifier on one line and the colon and the definition on
the subsequent line(s), e.g.