This section presents the services provided by the Application Platform Entity through the API and EEI. The organization of this section follows the breakdown of the service areas as depicted in figure 2-1 .
Note that for most of the services of the DODIIS Profile, the adoption of a standard as part of a specific service area can be somewhat arbitrary. This is especially true for the data interchange services and multimedia services, as there is an obvious overlap between some of their subsequent components. While the data interchange services address the "format" of different types of data and the multimedia services address the "manipulation" of the data, assignment of certain standards into one service area or the other can be arguable since some standards support both data format and manipulation. As such, the reader must recognize that the items of primary importance are the standards and specifications that are cited; the categorization of the standards and specifications is primarily used as a mechanism to facilitate discussion and understanding.
Included in the beginning of each section is a three-column table listing the standards adopted for the service area, where the status column of the table categorizes each standard as one of the following:
Whenever possible developers are expected to use products that adhere to standards that are classified as "Now". In situations where a particular service is not supported by a standard classified as "Now" or situations where there would be considerable cost in converting an existing application to a standard that is classified as "Now", developers should use products that adhere to a standard classified as "Gap". The classification "Future" identifies emerging standards that are expected to prove beneficial to DODIIS and in fact, may eventually replace a standard currently classified as "Now" or "Gap". If standards classified as "Future" are finalized and compliant products do become available, the community should expect the standard to be reclassified as "Now" or "Gap", as appropriate. Until such time, the appropriateness of using products that purport to be compliant with a standard classified as "Future" must be evaluated on a case-by-case basis.
Note that it is not appropriate for system developers or product vendors to claim "compliance" with the DODIIS Profile in that there is no formal process that has been or even can be developed to test for compliance with the guidance promulgated in this document. It is however appropriate to claim that a system or product is consistent with the guidelines promulgated in the DODIIS Profile if the system or product is compliant with specific standards or specifications cited in the DODIIS Profile. For example, an operating system that is Portable Operating System Interface for Computer Environments (POSIX) compliant by virtue of the fact that it has passed the POSIX certification tests is one which is consistent with DODIIS operating system services implementation requirements (see section 2.7.1 ).
Software Engineering Services (see table 2-1 ) cover all open systems environment services related to the support of information systems development. These services include (but are not limited to): Software Life-Cycle Processes (SLCP), Software Engineering Environments (SEE), programming languages, and related language bindings. These services, supported by standards, are required to support the DODIIS goal of application portability. It is therefore appropriate to identify these base service areas as important elements of the DODIIS Profile. The standards identified in this service area provide an effective software engineering environment that supports current DODIIS objectives.
Table 2-1 . Software Engineering Service Standards
The software life-cycle includes a set of activities, methods, practices, and transformations used to develop and maintain software and associated products (e.g., project plans, design documents, code, and design documentation). ISO/IEC provides a framework for the software life-cycle. The framework consists of major processes for a software development, maintenance, or usage project. MIL-STD-498, Software Development and Documentation, has been approved as an interim DOD standard. This standard is considered DOD's implementation of key portions of the ISO/IEC 12207 framework. MIL-STD-498 can be applied in any phase of the systems life-cycle. The term software development is used as an inclusive term encompassing new development, modification, reuse, re-engineering, maintenance, and all other activities resulting in software products.
Integrated Software Engineering Environment (ISEE) tools include processes, methods, systems, and programs that include processes, methods, systems, and programs that assist in the automated development and maintenance of software. These tools include (but are not limited to): requirements specification generation and analysis, design work and analysis, code generation, prototyping, testing, metrics, documentation, and group communication. The interfaces among the tools identified must provide services for storing and retrieving information about systems and exchanging the information between the various tool components.
There are no international or national standards for program support tools at this time. However, the Next Generation Computer Resources project produced a reference model (see National Institute of Standards and Technology [NIST] Special Publication 500-213, dated November 1993) for Project Support Environments (PSEs). The primary goal of the project was to provide an interface standard that can be used by project managers as an aid in procuring or assembling a PSE for a particular project or organization. One of the components of a PSE is a SEE. NIST, in conjunction with European Computers Manufacturers Association (ECMA), has produced a reference model for SEEs (NIST Special Publication 500-211), which is considered suitable to describe, compare, and contrast existing and proposed environment frameworks.
Before selecting software engineering tools, developers should evaluate how the tools will be used in the software development effort and whether the tools support DOD approved software engineering practices. Individual software development plans should consider not only the tools that will support the software development effort, but also how information can be shared among the different support tools.
Consistent with DOD guidelines, Ada is mandated as the primary language for DODIIS development of intelligence applications. This mandate does not include software that is developed and maintained commercially. To obtain an Ada waiver, DODIIS organizations must follow the guidelines documented in Assistant Secretary of Defense Memorandum, dated 17 April 1992, Subject: Delegations of Authority and Clarifying Guidance on Waivers from the Use of the Ada Programming Language. An integral part of the waiver justification process is the completion a functional economic analysis (FEA). The FEA is used to evaluate the cost and benefits of available software solutions. A costing model should be employed to ensure an objective means of comparison. When evaluating alternate development languages, C is designated as the alternate language of choice for DODIIS development and should be considered in the context of any analysis for software solutions. The use of any compliant compiler should be limited to the specific features defined in its respective compliance document and unique language extensions should be avoided to support program portability goals. Shells and script programming is covered separately under Operating System Services, section 2.7, as an extension to POSIX standards.
Ada is a high-level, systems programming language. Attributes for Ada include:
Ada is mandated by DOD policy in DOD Directive 3405.1, Computer Programming Language Policy, 2 April 1987. This directive requires that Ada be used for custom developed software in all DOD systems development. ISO 8652.95 Ada 95 provides the standards for Ada and identifies the technical language specification for Ada (syntax and semantics) as American National Standards Institute (ANSI)/MIL-STD-1815A-1983. Ada compilers used must be validated by the General Services Administration, Federal Software Management Support Center.
The Ada Semantic Interface Specification (ASIS) has been developed to provide an interface between the Ada library and any tool requiring information from the Ada library. This effort provides an opportunity to integrate development support tools such as symbolic debuggers, test tools, design tools, metrics tools, style checkers, and document generators with the Ada development environment. The current ASIS specification is: Ada Semantic Interface Specification, Version 1.1.1 Vendor Independent ASIS (VIA), Ada Joint Program Office, May 1994. Efforts are underway to place ASIS on a path to formal standardization by the International Organization for Standardization (ISO), as part of the Ada-95 standardization efforts.
C is a general purpose procedural language that was developed for the Unix operating system. It offers the controls and data structures of a high-level language and the efficiency of low level languages. These attributes have made it suitable for system programming in the Unix system environment. In fact, the POSIX System Interface Standard is written in terms of the C programming language. C is currently the de facto standard for open systems, and as such will continue to be supported for DODIIS development when Ada is not considered to be the most cost effective solution.
FIPS PUB 160 provides the guidance for using C processors and specifies ANSI X3.159-1989 as the language specification standard for C. FIPS PUB 160 also discourages the use of any unique C language extensions because they would make interchange of programs and future conversions in standards or processors more difficult and costly.
An object oriented superset of C is C++, but there are no standards to support C++ at this time. Standards for C++ are under development by the International Organization for Standardization/International Electrotechnical Commission Joint Technical Committee (ISO/IEC JTC) 1/SC22/WG21. Until such time as standards are defined for C++, its use will be restricted.
Language bindings provide programming language standards with syntax and semantic links to operating system services and other standards such as those specified for data management (see section 2.3.2 ). The specification for Ada specific bindings was approved in late 1992 and is documented in P1003.5. Implementations of the Ada language bindings to P1003.1 must be in conformance with P1003.5a specification for Ada language bindings. The initial Ada bindings will lack specific language features of Ada that have no correlating POSIX service. This is expected to be remedied when POSIX real-time services correlating to Ada language specifications are added to POSIX.1 and the new Ada bindings specification P1003.5b is available. Language bindings are critical for access to POSIX operating system services from programming language implementations without creating unique interfaces that greatly reduce implementation portability. See Appendix B for more information on the various POSIX Committees.
Software Engineering security services provide the means to control access to and integrity of programming objects, such as libraries, development tools, and program code.
At the present time there are no formal standards that describe how security should be integrated within the software development process. However, the draft version of MIL-STD-498, Software Development and Documentation (intended to supersede MIL-STD-2167A) recognizes the importance of identifying security requirements and performing risk management within the software development process.
