TABLE OF CONTENTS

   

List of Figures

List of Tables

1.0  OVERVIEW

2.0  DISCOVERY

2.1  Task 2 Requirements
2.2  Discovery Process

3.0  DATA MANAGEMENT TOOLS EVALUATION

3.1  DMT Definition
3.2  DMT Evaluations

4.0  DMT DEFICIENCIES AND RECOMMENDATIONS

APPENDIX A:  TASK 2 REFERENCE LIST

APPENDIX B:  DMT EVALUATION CRITERIA BOILERPLATE

APPENDIX C:  CALS ACRONYMS AND ABBREVIATIONS

 



 

LIST OF FIGURES

       [ Previous ]           [ Next ]           [ Home ]

 

Figure 2.0-1  Task 2 General Approach

Figure 2.0-2  Task 2, Subtasks 1 and 2 Planned Workflow

Figure 2.0-3  Task 2, Subtasks 3 and 4 Planned Workflow

Figure 3.2-1  OSD CALS Pilot Architecture

 



 

LIST OF TABLES

       [ Previous ]           [ Next ]           [ Home ]

 

Table 2.1-1  CALS DMT Standards-Based Criteria

Table 3.1-1  DMT Classifications/Functional Areas

Table 3.2-1  CALS Pilot Repository Data Management Tools

Table 4.0-1  CALS Data Management Tool Deficiencies and Recommendations

 



 

1.0  OVERVIEW

       [ Previous ]           [ Next ]           [ Home ]

 

The OSD CALS IWSDB Project Task 2 team has been chartered to explore data management in the realm of Continuous Acquisition and Life-Cycle Support (CALS) initiatives headed by the Office of the Secretary of Defense (OSD). Data management in CALS is the creation and handling of data such that the concept of "creating data once and using it many times" is supported by allowing the integration and sharing of data across heterogeneous platforms. As stated in the Statement of Work (SOW):


The underlying objective of data management in CALS is to support the integration of data to a shared data environment that provides functional harmonization and bridging between the government and industry.


In support of this objective, our team has extensively researched Data Management Tools (DMTs) that will enable the creation of a shared data environment supporting CALS Integrated Weapon System Databases (IWSDBs). The research has been driven and steered by an IWSDB Implementation Strategy, a Concept of Data Management Operations, and a DMT evaluation matrix. A Tool Assessment Report includes DMT evaluation matrix criteria established to assist in defining data management for an IWSDB environment and to provide overall direction for the task.


The Task 2 team investigated existing Department of Defense (DoD) projects and federal doctrine, Commercial Off-The-Shelf (COTS) applications, existing Government systems, and many other related papers, articles, and conference synopses in an effort to identify DMTs for DoD-shared database architectures (see Appendix A for a complete list of Task 2 references). All applicable researched subject matter has been related to the topics of data management, repository databases, and information reuse. A few of the existing DoD and federal agency programs investigated include the Joint Continuous Acquisition and Life-Cycle Support (JCALS), the Integrated Computer Aided Software Engineering (ICASE) solicitation functional requirements, Computer Integrated Manufacturing/Defense Information System Agency (CIM/DISA) Defense Data Repository System (DDRS), and the Air Force Integrated Data Strategy (IDS). Cooperative exchange with federal government and select commercial entities provided us with information that assisted in establishing the DMT evaluation criteria matrix that assisted in defining, identifying, and supporting assessment of candidate tools. The selected candidate management tools were evaluated against criteria in the DMT evaluation matrix to determine their level of integratability and effectiveness in creating, accessing, and managing CALS data repositories. Using select candidate tools, a pilot DMT system was hence integrated for further hands-on evaluation and later demonstration of capabilities. Ultimately, these evaluations will support the selection of a suite of CALS DMTs for a weapon system full development life-cycle. The deficiencies noted during our investigative and pilot integration efforts, as well as the citing of recommendations for corrective actions through continued research and development, are presented in the Preliminary Tools Deficiency Report for the OSD CALS IWSDB Project.

 



 

2.0  DISCOVERY

       [ Previous ]           [ Next ]           [ Home ]

 

The preliminary task for this OSD CALS project team was to establish a plan of action for identifying the evaluation criteria and applicable candidate COTS DMTs available in the market place for use in accessing and maintaining CALS IWSDB data. DMT criteria has been used in assessing product capability and interoperability within an IWSDB environment. Figures 2.0-1, 2.0­2, and 2.0-3 illustrate the approach being coordinated to guide the team in conceptualizing, evaluating, and defining candidate tools that are CALS-conformant. This section outlines the initial phases of DMT assessment that contributed to this tool deficiency and recommendations report.

 

2.1  Task 2 Requirements

Task 2 of the OSD CALS project required the identification, evaluation, and recommendation of a suite of integratable COTS DMTs that support a weapons system full life-cycle development. The COTS DMTs should be evaluated against a comprehensive set of functional requirements. In addition, a preliminary pilot of the integrated tool set is required for demonstrating CALS data entry, maintenance, and exchange functionality. This report provides a preliminary synopsis of the DMT deficiencies noted during identification, functional evaluation, and pilot integration efforts. Reference the Tool Assessment Report for a detailed account of individual DMT functionality measured against established evaluation criteria. This deficiency report expands on the functional deficiencies noted in the Tool Assessment Report by addressing interoperability and critical interface and integration issues pertaining to heterogeneous data management application tools that will be integrated across heterogeneous hardware environments. Deficiencies herein focus primarily on integration anomalies, incompatibilities, and other difficulties noted during tool evaluation and pilot integration efforts. This report will also contain recommendations for potential solutions to the noted COTS DMT deficiencies for IWSDB data access and control.


The primary focus of Task 2 is on DMTs in support of life-cycle weapon systems. The weapon system development life-cycle, in general, consists of phased analysis and definition of requirements, preliminary system and logical database design, interface definition, detailed design, system implementation, integration, test, maintenance, and program management. In general, Task 2 has been chartered to locate an integratable suite of DMTs that support the complete development life-cycle, data creation, access, and management for an open systems architecture. The DMTs should adhere to the DMT criteria, support CALS-compliant data exchange, and prevent as much manual intervention as possible while supporting the weapon systems development. As a means of measuring candidate COTS tool capabilities, CALS DMT evaluation criteria have been established. Our findings lead us to believe that the adherence to standards-based portability and open communications criteria, such as the Portable Operating System Interface (POSIX) for computer environments and Government Open System Interconnection Profile (GOSIP), are among the most critical guidelines to which DMTs must comply. As important is the list of key standards listed in Table 2.1-1. A standards-based DMT repository, we believe, will support the data exchange, access, and flexible interface capabilities essential within an ever-changing, ever-improving heterogeneous IWSDB environment.


 




Figure 2.0-1.  Task 2 General Approach


 




Figure 2.0-2.  Task 2, Subtasks 1 and 2 Planned Workflow



 




Figure 2.0-3.  Task 2, Subtasks 3 and 4 Planned Workflow

 

Table 2.1-1.  CALS DMT Standards-Based Criteria


Data Interchange
- Vector Graphics - Graphics Metafile Illustr. - Product Model Def. - Raster Graphics - Logistics - Electronic Commerce	IGES CGM PDES/STEP CCITT G4 LSAR EDI	MIL-D-28000 MIL-D-28003 MIL-D-28002 MIL-STD-1388 ANSI X-12
Open Systems
- Communication - Portability	GOSIP (OSI), TCP/IP POSIX, Ada
Database Access
- Query	SQL	FIPS 127-1
GUI
- UNIX - DOS/WINDOWS/OS-2	X-Windows, Motif MS Windows/Present. Mgr.

 

2.2  Discovery Process

To fulfill our task requirements, the OSD CALS team conducted extensive discovery and research activities to establish DMT evaluation criteria, to identify candidate COTS products, and to identify deficiencies in DMT functionality, as well as in DMT interoperability. The discovery process consisted of researching trade literature, Government and industry standards, existing Government repositories, integrated weapon systems programs, and COTS tool sets for potential contributions to the establishment of a CALS DMT repository suite. The COTS tool sets examined, generally, encompass CASE tools, version control/configuration management (VC/CM) tools, program management/control tools, product data generation tools, Standard for the Exchange of Product Model Data (STEP) tools, and security tools.


Throughout the discovery process, site visits were scheduled for technical interchange with the DoD, federal agency programs, and commercial sites.


The following is a list of federal programs and references examined thus far during our research and pilot development.


• JCALS.

• ICASE Request for Proposal (RFP) functional requirements.

• CALS Test Network (CTN) policies, procedures, and capabilities.

• National Institute of Standards and Technology (NIST) policies, procedures, and capabilities in life-cycle systems development.

• Advanced Research Projects Agency (ARPA) policies, procedures, and capabilities in life-cycle systems development.

• Repository applications based on Federal Information Processing Standards (FIPS) 156 conforming to Information Resource Dictionary Specification (IRDS) standards.

• Electronic Data Interchange (EDI) concepts and applications.

• STEP initiatives and products; Concurrent Engineering Research Center (CERC).

• CIM/DISA DDRS repository.

• IDS.

• F-22.



As planned, the Task 2 team has completed the majority of evaluations and generation of synopses on technical data requested and received. After having documented assessments performed on government programs and having completed synopses on the majority of background data uncovered, we set out to define the essential terms and concepts for the project including the definition of a "repository," a "data management tool suite," and "reusability." These definitions were an important precursor to evaluating software candidates for sighting of deficiencies and recommendations on CALS DMTs.


Furthermore, as a key guideline during the discovery process, we felt it necessary for the team to establish and detail a conceptual IWSDB implementation strategy that describes an IWSDB architecture within which our DMT repository would operate. The intent of the IWSDB Implementation Strategy Plan which was subsequently written by Task 2 members was to provide a detailed, consistent view for the OSD CALS project team on what requirements could influence the implementation of an IWSDB. The evolving IWSDB implementation strategy, along with a concept of DMT operations, provides a framework for DMT integration to an IWSDB architecture and describes how DMTs would work together to support a CALS IWSDB environment. The IWSDB Implementation Strategy Plan, the Preliminary Concept of DMT Operations, along with site, system, and tool investigative synopses all contribute to the subsequent tool selection process and to the eventual sighting of tool deficiencies and subsequent recommendations for improvements.

 



 

3.0  DATA MANAGEMENT TOOLS EVALUATION

       [ Previous ]           [ Next ]           [ Home ]

 

Locating an effective repository of data management tools centers around the classification of information objects residing within the repository and requiring manipulation. The CALS DMT suite should provide development teams with a suite of integratable, reusable tools. Systems and software development teams, management teams from the government, contractor or vendor organizations should be able to access the IWSDB repository regardless of location and the native platform implemented. As such, DMTs should facilitate communication, information and object reuse, and mutual cooperation and concurrency among related project members throughout a weapon system life-cycle. As such, the DMT suite should enable data creation and exchange within a secure, version­controlled, heterogeneous, concurrent access environment. The DMT repository should facilitate IWSDB concurrent life-cycle planning and management, analysis, design, and system implementation decision-making.


 

3.1  DMT Definition

By our definition, DMTs must play a major role in both decisive identification, definition, control, documentation, and implementation of system and data requirements, as well as in life-cycle project management. Also, DMTs are intended to enable the creation, global access, and tracking of a multitude of process designs and interfaced data entities and attributes residing within a data repository (i.e., IWSDB). Tools must ultimately support data standardization activities for ease of implementation and data management in heterogeneous environments across the DoD, contractor, and vendor communities. Government program managers, contractors, and vendors must be able to generate, maintain, and exchange data that conforms to CALS standards. Furthermore, the DMT suite must support functionality such as concurrent engineering in order to enhance the ease, speed, and quality of engineering efforts during systems engineering and development across geographically distributed resources.


In general, DMTs span a wide array of functionality and utility during life-cycle development. Therefore, a unified functional allocation of DMTs was needed. The research and discovery processes led us to organize DMTs into specialized functional areas, based in the capabilities and characteristics of some of the COTS DMTs found during market surveys. Once the functional areas were established, DMT functionality performance criteria were compiled to detail requirements for each functional area used in the evaluation of purported tool capabilities.


Our research lead us to the conclusion that a select suite of DMTs (i.e., COTS and custom) having the necessary functional capabilities required by an IWSDB can be applied to accomplish the desired data management capabilities. The following DMT functional areas were defined as providing coverage for most capabilities needed in an IWSDB reuse environment.


• Directory Services (yellow-pages) - Provides data access and control via a global network-wide data directory. Maps location of data entities within a globally distributed repository of life-cycle data.

• Data Security - Provides security and data protection via security services. Provides access privilege control for user, data, and command/operation access.

• VC/CM - Supports VC and configuration management of repository content, data integrity control, verification, meta modeling, and reporting. Provides for tracking during concurrent engineering creation, replication, and exchange of information.

• Database Management System (DBMS) Services - Provides management and control of the common distributed repository database.

• Data Dictionary - Provides for data dictionary structure/attribute definition preparation for project analysis, design, and implementation.

• Data Modeling - Supports Integrated Computer-Aided Manufacturing Definition (IDEF) and other modeling and translation services. Provides for business case analysis during systems development and for operational data requested during design, implementation, and maintenance phases of system design. Also, may help to provide for repository model representation to end users.

• Project Control - Supports project-task control, resource-data control, and process workflow management during requirements, design, coding, testing, documentation, and re-engineering system development phases. Provides features for analyzing and tracking of requirements, modeling object-oriented and structured systems, modeling entity-relationships in logical database systems, CALS and non-CALS product data generation, performance benchmark modeling, reliability/maintainability modeling, network and systems load modeling and simulation for life-cycle systems design, code generation, testing, documentation, re­engineering/reverse-engineering, and project workflow management.

• Operations and Maintenance - Provides system and communication operations support for system performance, fault detection monitoring and control, and network health control. Provides for incidence tracking and reporting and real-time repository backup.

• Product Data Generation - Supports the generation/manipulation of data related to the development of a weapon system.



Although a DBMS has been classified as a DMT, it is important to note that a DBMS is an essential support mechanism to the integration of a DMT suite providing a common-point data repository for exchange of data across heterogeneous, interoperable platforms. Therefore, we have included the DBMS among the DMT function descriptions. All candidate COTS DMTs evaluated, subsequently, fall into one of the above functional classifications.


During systems engineering on weapon systems acquisition programs, CALS DMTs should provide access to repository life-cycle data as described in each DMT functional area of capability above. In general, DMTs should provide for the implementation of project­related functional requirements definition and traceability, information modeling, design, product development, and project management. However, in addition to the above functionality specifics, tools are needed that offer controlled user/data access and VC of the CALS repository throughout the enterprise. Tools, as earlier indicated, must also provide secured information access, directory servicing, VC of globally distributed data entities, and project control of life­cycle data.


To further organize our efforts to evaluate DMT candidates, the team mapped each DMT functional area to specific correlated, higher level DMT classification(s). These classifications made organizing DMT evaluated capabilities easier, because some DMT functions are found in a single tool that performs a sole DMT function, while the same function may also be found bundled into a multitude of other tools. For example, a CASE-like tool may offer a group of associated functions including modeling capabilities, while a stand-alone modeling tool offers the same functional coverage. Product classifications subsequently mapped to allocate the aforementioned DMT functional areas of coverage are presented in Table 3.1-1.

 

Table 3.1-1.  DMT Classifications/Functional Areas


TOOL CLASSIFICATION	TOOL FUNCTIONAL AREA(S)
CASE Tools	Data Modeling, Data Dictionary, Project Control
VC/CM Tools	VC/CM, Directory Services, Operations and Maintenance
Project Management Tools	Project Control
DBMSs*	DBMS Support
Security Tools	Data and User Access Security
Product Data Generation Tools	Product Data Generation (including tools needed to produce/maintain CALS MIL-28000 standard data form factors)

*Essentially an IWSDB support mechanism.


 

3.2  DMT Evaluations

The discovery process has unveiled a number of products that have been evaluated for general effectiveness in a CALS repository environment. DMTs from each tool classification have been researched and selected so as to achieve comprehensive coverage of key functionalities. Table 3.2-1 presents a list of candidate DMTs that support most of our defined tool functions. Appendix B presents a listing of the base evaluation criteria used to sort through and evaluate these DMT candidates. A detailed evaluation of these and many more candidate tools is provided in the Tools Assessment Report. Products from this list in Table 3.2-1 have been chosen as implementations of the pilot DMT suite for demonstrating data management of an IWSDB across heterogeneous hardware and software application platforms.


 

Table 3.2-1.  CALS Pilot Repository Data Management Tools

TeamWork	(Cadre, Inc.)
PC Dictionary	(Software Solutions, Inc.)
Design IDEF	(MetaSoft Corp.)
Open Repository	(InfoSpan, Inc.)
IEF	(Texas Instruments, Inc.)
CM-Vision	(Expertware, Inc.)
EDM	(ComputerVision, Inc.)
VueFinder	(Vartec, Inc.)
Artimis Prestige	(Lucas Mgmt.)
Oracle 7	(Oracle Corp.)
PC/DACS	(Mergent Int.)
Watchdog	(Fischer Int.)
STEP Tools	(STEP Tools, Inc.)
ERWin	(LogicWorks, Inc.)
CADLeaf	(Carberry Tech)
CALS View	(IGES Data Analysis)

The pilot demonstration architecture is presented in Figure 3.2-1. The Task 2 team has integrated this representative pilot IWSDB DMT repository composed of a suite of selected COTS DMTs. This pilot DMT repository provides support in each of the specified DMT functional areas as defined at the onset of this report. The plan has been to demonstrate CALS DMT repository interoperability and standards-based functionality in a two-phased effort as follows:


Phase I ­ Integrate and demonstrate the functionality of a COTS DMT suite while demonstrating the concept of standards-based [Integrated Computer Aided Manufacturing Definition (IDEF), STEP, MIL-28000 series, POSIX, GOSSIP, structured query language for database (SQL)] product generation tooling, heterogeniality, database schema, and standardization of data elements. The initial integration incorporated a Relational Database Management System (RDBMS) engine (i.e., Oracle 7.1 - Trusted) as the common data exchange point. That is, each heterogeneous tool has the ability to exchange CALS-conforming data form factors via the common interface to ORACLE. As a later phase, we have targeted the use of the FIPS-156-based IRDS standards as the common repository by which heterogeneous platforms may exchange process and information meta models and subsequently have access to the physical data, given privileged access.


Phase II (follow-on) ­ Integrate and demonstrate the functionality of the IWSDB to advance the concepts presented during Phase I, encompassing the use of a global VC meta model to provide for enterprise-wide concurrent access to the Wide Area Network/Local Area Network (WAN/LAN)-distributed data. Also, add the interactive Electronic Technical Manual (IETM), EDI, Standard Generalized Markup Language (SGML), and Logistics Support Analysis Records (LSAR) IWSDB entities to the architecture for manipulation by their corresponding DMTs.


The pilot demonstration platforms included a SUN Sparc 2, two Sparc 5s, and personal computers (PCs) running a combination of SQL Net, TCP/IP, X Windows, OpenWindows, and Windows for Workgroups, as well as configurations of the COTS DMT applications and supplemental custom tools generated by the team. Note that our targeted pilot integration has been on target for this phase of the repository capability demo. Note, also, that we have already implemented a global version control meta model with custom capabilities as planned for follow­on Phase II tasking.


 


Figure 3.2-1.  OSD CALS Pilot Architecture

 



 

4.0  DMT DEFICIENCIES AND RECOMMENDATIONS

       [ Previous ]           [ Next ]           [ Home ]

 

The ongoing research and pilot integration process has unveiled a number of interoperability, integration, and compatibility issues that are sited as deficiencies. These deficiencies are some of the primary issues that will need attention in the future, so as to produce a seamless, CALS-compliant, interchangeable, and reusable suite of DMTs for management of an IWSDB. Table 4.0-1 sights deficiencies uncovered during our task research on the CALS DMT repository.


 

Table 4.0-1.  CALS Data Management Tool Deficiencies and Recommendations

Deficiency	Recommendation
An intensified effort to evaluate the implementation of an X.500 based Directory Services globally distributed meta-model should be considered. Our research has shown that although many COTS DBMSs claim to meet the ANSI standard for SQL, there are minor differences. The vendors enhance the language to differentiate themselves from the rest of the market. This complicates the process of exchanging data schemas across platforms/products. We have found that it is possible that more products support Oracle SQL than ANSI SQL.	Either ANSI SQL standards should be adhered more closely, or an ODBC or SQL translator/wrapper should be implemented to recognize a native SQL environment (i.e., Sybase, SQL, Oracle SQL, Informix SQL, etc.), parse and convert the non-standard SQL segment to a common standard ANSI SQL implementation for heterogeneous execution. We recommend study of these approaches as they relate to the CALS DMT implementation strategy for providing a common DBMS as the central repository for most CALS data created, accessed (SQL-based), and control via data management tools.
Although many COTS CASE tools support the full system development life-cycle, few provide heterogeneous interfaces allowing the ability to share graphical process design models and graphical dictionaries seamlessly.	A modeling methodology that supports integration of reverse-engineering/forward-engineering along with correlated business process modeling should be researched and a pilot established. The re-engineering approach and DMT set should identify a process model, as well as information modeling tools that have the ability to seamlessly integrate with a repository of CASE tools. We could first research the appropriate mapability of methodologies (SA/SD - Yourdon; Real Time -Mellon; OOA/OOD - Booch, etc.) as implemented in the varied upper and lower CASE tools. A means of establishing an interface among heterogeneous modeling tools and CASE tools can be developed as a pilot to facilitate legacy software systems re-engineering using existing new modeling tools interfacing with pre-existing CASE tool technologies. As a practical application, we recommend exercising on an existing legacy software system as a target re-engineering project while defining this new "Re-engineering Methodology." This can serve as a task to convert an existing systems to a client-server implementation, while at the same time refining a methodology for re-engineering legacy software in many applicable environments.
With the exception of InfoSpan, the commercial CASE tool market is extremely limited in its support of FIPS-156 and IRDS. Vendors mentioned they have chosen functionality over compliance.	Currently, there are few repository applications that support FIPS-156 IRDS standards. A more in-depth survey needs to be conducted to define where the COTS industry is headed with this regard and why. In our migration strategy of implementing CALS in stages between now and the year 2010, the implementation of FIPS-156 is important as a hub for meta-data and as a repository for file and selected discrete datum at the regional repository level of IWSDB access. This is important in the development of CALS DMT look and feel for the future. Currently, as uncovered on the current OSD project, commercial repository data dictionary and data modeling tools do not generally support FIPS-156. This new survey should uncover why the industry is so slow to adopt it and what could be done to bridge implementation of a standards-based repository. In addition, we could examine the capability of COTS applications in importing/exporting ANSI IRDS command language files and what the possible alternative are. If the standard is limiting functionality to a large extent, it should be re-evaluated.
Although we have identified a number of products that support IDEF, none support both IDEF and FIPS 156.	With the emergence of the IDEF modeling notations, a CASE product that supports both IDEF and FIPS-156 would be ideal for our applications. Currently, InfoSpan, the only COTS product that supports FIPS-156, does not support IDEF.
Only INFOSPAN is FIPS 156 compliant.	Commercial data dictionaries and data modeling tools need to begin to export ANSI IRDS command language files.
Currently, the FIPS 156 specification for a data dictionary system is passive.	At a minimum, data dictionary guidelines need to be updated to that of an active data dictionary, and ideally the system needs to be dynamic.
No standards are in place to digitally represent the IDEF1X modeling technique. This lack of standardization restricts passing IDEF1X models from one IDEF1X modeling tool to another IDEF1X modeling tool.	Data Modeling tools need to export ANSI IRDS command language files in order to share generated data dictionary information built or meta modeled in IDEFIX command language.
The specification to graphically represent the INFOSPAN schema is by an ER Diagram. When a model is created with the IDEF1X modeling technique and imported into INFOSPAN, primary key information is lost. When information is exported to an IDEF1X modeling tool from INFOSPAN, the attributes associated with relationships are lost. In addition, the translators for importing and exporting between IDEF1X modeling tools and INFOSPAN are very few.	Attribute should possibly be made to meet some normalization standard such that mapping among heterogeneous modeling tools will result in a more portable schema.
It is not totally clear exactly how STEP will be incorporated into an IWSDB. There are several reasons for this, the most prevalent being the relative infancy of STEP. One other problem pertains to whether STEP will be able to efficiently handle legacy data translation to the STEP model base.	One thing that has begun to emerge is the role of STEP as an encompassing standard as opposed to a replacement standard. STEP has to encompass other standards. STEP cannot possibly replace all other standards; in fact, it would be inefficient for STEP to do so. STEP needs to harmonize and envelop, like an umbrella, other data modeling standards including RASTER, VHDL, EDIF, SGML, etc. This will enable the creator/purveyor of IWSDBs to handle the problem of legacy data in an efficient and more elegant manner. In the more complex models, such as an IGES model, it could be easier and more efficient to incorporate a data translator. However, with simpler, more primitive models, it would probably be much more convenient to encompass the original legacy data into the STEP model by means of a "link" or "hook." The implementation of these links/hooks is being addressed by the STEP community.
Currently, there is a deficiency in ability to reliably translate between the object-oriented and relational DBMSs that may act as heterogeneous repositories across the CALS enterprise. We found and demonstrated a STEP tools-based OODBMs translator to the Oracle (only) RDBMS for STEP product model component objects.	Research the integration of OODBMS- and RDBMS-based repository data in an IWSDB. Research the use of translators versus other means of cohabitating these two diverse database structures within the heterogeneous IWSDB environment.

 



 

APPENDIX A ­ TASK 2 REFERENCE LIST

       [ Previous ]           [ Next ]           [ Home ]

 

NOTE:  The following is a cross section of the OSD-CALS project document database referenced for this task deliverable.


Task 2 Reference List

A Classification of CASE Technology

A Comparison of Object-Oriented DBMSs for Engineering Applications

A Data Dictionary Approach to Teaching Information Systems Analysis

A DBMS for Every User

A Distributed Directory Database System for Telecommunications

A Distributed Shared Database System for Concurrent Engineering

AdaNet User's Guide American Standard Code for Information Interchange (ASCII) Version

AdaNet User's Guide X Windows Version

Aerospace Sector Exploits Computer-Aided Design/Computer-Aided Manufacturing/Computer-Aided Engineering (CAD/CAM/CAE)

Air Force Materiel Command (AFMC) IWSDB

AFMC/CALS IDS

An Integrated Data Dictionary to Facilitate Automatic Report Generation in a Network Database

Application Servers at Your Service

ASSET Information and Application

Business Gold National Technology Transfer Centers (NTTC) - On-line User Guide

CALS, R. Smithmidford

CALS, DoD

CALS and Data Security:  Are They Compatible?

CALS Background (1.0)

CALS Bulletin Board System

CALS Contractor Guide

CALS Directory/Data Dictionary Services

CALS ODD/Industry Steering Group Software Position Paper 11/29/88

CALS Europe '91 Part 1:  Europeans' Approach to CALS Policy Remains Divided

CALS Journal Spring 1994

CALS Journal Summer 1993

CALS Journal Winter 1993

CALS SOW

CALS:  An Industry/User Report

Can Computer Crime Be Stopped?

CASE Product Guide

Consultative Committee on International Telegraphy & Telephony (CCITT) Draft Recommendation X.500

Contractor Integrated Technical Information System (CITIS)

Client/Server Computing

Client/Server Breakdown

Concurrent Engineering, Information Modeling, and STEP Tutorial 2/19/93

Core Standards Herald CALS Implementation

CS 340 Notes/Tests West Virginia University Dept. of CS

Data Dictionary/Directories, Uhrowczik

Database Concept Paper IWSDB

Dept. of Defense Trusted Computer System Evaluation Criteria (Orange Book)

Development of Product Data Control Model

Document Interchange Reigns at DoD

DoD 8320.1  DoD Data Administration

DoD 8320.1-M-1  Data Element Standardization Procedures

DoD Enterprise Model Vol. I & II

DoD-STD-963  A Data Item Descriptions (DIDs)

EC/EDI, AFCEA Computing Conference and Exposition

EDEX

EDI

Elements of a Realistic CASE Tool Adoption Budget

EXPRESS Language Reference Manual

EXPRESS Part 1:  Product Data Representation and Exchange-Overview

EXPRESS Part 21

EXPRESS Part 41:  Product Data Representation and Exchange

Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases

FIPS 156 Changes

Framework Aids Concurrent Engineering with Configuration Management

Fundamentals of Database Systems, Elmasri/Navathe

Government Concept of Operations (GCO)

GOSIP

Heterogeneous Distributed Database Systems for Production Use

IBM Unfurls ImagePlus Client/Server Plans

ICASE

IDEF Modeling Techniques Workshop

IDEF1X

IDS ALF

IDS Cost Benefit Analysis

IDS Viewgraphs and Misc. Docs.

Information Security for the 1990's

Integrating Security with Fault-Tolerant Distributed Databases

Internet

Interoperability of Multiple Autonomous Databases

Introduction to CE and STEP

JCALS Technical Manual (TM) Prototype Plan

Joint Computer-Aided Acquisition and Logistic Support (CALS) System

Learning to Speak CALS

Making On-Line Service Work for You

Making the Switch (relational for flat files)

Manage Integrated Weapon Systems Database (IWSDB) Control Architecture ABC Foundation Workshop

Managing Computer Security

MIL-HDBK-59B

MIL-STD-1388-2

MIL-STD-1840 Automated Interchange of Technical Information

Modeling Enterprise Information and Enabling Access Using Information Sharing Server

MOSAIC

MountainNet Information and Application

National Data Administration Council (NDAC) Management Plan for Integration of External Data

On-Chip Hardware Supports Computer Security Features

Operating Systems Concepts p425-429

Operating Systems Key Security with Basic Software Mechanisms

ORACLE and Secure Systems:  Questions and Answers

ORACLE's CDE Draws Praise, Suggestions

Parallel Database Systems:  The Future of High-Performance Database Systems

PC Magazine Network Edition

Performance Comparison of Three Modern DBMS Architectures

Preliminary Management Plan for the OSD CALS IWSDB Project

Project Management:  Pulling the Data Together

Promoting Concurrent Engineering Through Information Sharing

PVCS Version Manager Version 5.1:  Administration Guide and Reference

PVCS Version Manager Version 5.1:  Quick Reference

PVCS Version Manager Version 5.1:  Reference Guide

PVCS Version Manager Version 5.1:  User Guide and Reference

Revision Control System (RCS) - A System for VC

SAG

Sandwich Shop Application Protocol

Security-Minded System Design Can Protect Databases

Seeking Security

Subject Matter Expert (SME) STEP Clinic

Software Configuration Management Redefined

Specification and Modeling of Computer Security

Sustained Training (ST) - Developer

STARS/ASSET Catalog 8/11/93

STEP An Enabling Technology for Concurrent Engineering, NTU Satellite Course

STEP Programmers Tool Kit

STEP Software for Worldwide Manufacturing

STEP-Application Protocol Erudition-What are Acquisition Plans (APs) Anyhow?

The Many Faces of Data Vulnerability

Trail Blaze through the Data Flow Jungle

Understanding CALS

Using a PC Database for Material Handling Project Management

 



 

APPENDIX B ­ DMT EVALUATION CRITERIA BOILERPLATE

       [ Previous ]           [ Next ]           [ Home ]

 

  DMT Evaluation Matrix

Data Dictionary


DATA DICTIONARY	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Conforms to FIPS 156.
2. Contains name, definition (size and type), locations (where and how used), and relationships of data.
3. Supports these DDRS data element naming conventions:
Prime word
Class word
Optional modifiers
Location transparency
Size limitations
Characters, hyphens, and spaces only
Hyphen with multiple prime words
Abbreviations/acronyms allowed
Possessive forms, conjunctions, prepositions, or verb allowed
4. Minimizes duplication of data.
5. Creates dynamic data dictionary.
6. Provides indexed dictionary.
7. Handles multiple (CALS-compliant) data types.
8. Integrates to other COTS.
9. Provides VC/CM for metadata.
10. Describes security of user database.
11. Has the capability to customize report generation.
12. Can integrate to popular DBMS.
13. Has security facilities for metadata (or by DBMS).
14. Has data integrity checks.
15. Provides error reporting functions.
16. Provides referential integrity.

  DMT Evaluation Matrix (Continued)

Data Modeling


DATA MODELING	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Uses IDEF 1X modeling notation.
2. States a purpose for each model.
3. States a scope for each model.
4. Describes conventions used by the designers.
5. Supports the following model components:
Entities
Identifier-independent
Identifier-dependent
Relationships
Identifying connection
Non-identifying connection
Categorization
Non-specific relationships
Attributes/Keys
Attributes
Primary keys
Alternate keys
Foreign keys
6. Includes model notes.
7. Provides triggers.
8. Generates physical structures for DBMSs.
9. Has auto indexing capabilities.

 DMT Evaluation Matrix (Continued)

Security


SECURITY	COMPLIANT CRITERIA ( = Meets Requirements)
VENDOR-PRODUCT
1. Provides feature DAC.
2. Provides Mandatory Access Control (MAC).
3. Has an audit trail facility that: Provides audit trail of users. Provides audit trail of dates. Provides audit trail of violations. Provides audit trail of time. Provides audit trail of files opened. Provides audit trail of files closed. Provides audit trail of files created. Provides audit trail of files deleted. Provides audit trail of communication ports.
4. Provides the following encryption schemes: Public Key encryption (using RSA Algorithm). Proprietary Algorithm. Data Encryption Standard (DES) Algorithm.
5. Has a virus protection feature.
6. Is capable of achieving B1 level trust.
7. Has a timing constraint feature that restricts users' access to certain days of the week.
8. Is capable of multi-level security.
9. Provides an object reuse mechanism.
10. Provides an auto-locking mechanism.
11. Provides sensitivity labels.
12. Provides label integrity.
13. Exports labeled information.
14. Can label human-readable output.
15. Provides identification & authentication mechanism.
16. Provides report generation capability of audit information.
17. Provides a manual keyboard locking capability.
18. Provides screen blank capability.
19. Provides floppy boot protection.
20. Has a single sign-on mechanism.
21. Is capable of parallel port lockouts.
22. Is capable of communication port lockouts.
23. Is capable of controlling access to floppy disk drives.
24. Can protect system boot-up files.
25. Has limited amount of time for data access.
26. Has remote dial-in protection.
27. Restricts access to operating system commands.
28. Can disable user access after repeated log-on failures
29. Can automatically log-off user after designated inactivity period.
30. Can deny usage of certain parts of the keyboard.
31. Has minimum password length requirement.
32. Can require passwords to be changed often.
33. Can sound alarm after several invalid log-on attempts.
34. Has extensive on-line help.
35. Has a menu-driven system.
36. Restricts users' access to directories.
37. Restricts users' access to files.
38. Can lock hard disk if booted from floppy.
39. Has an easy installation procedure.
40. Has an easy deinstallation process.
41. Has a smart card interface.
42. Has a graphical user interface capability.
43. Can protect multiple files.
44. Provides direct disk reads and writes blocks.
45. Can suspend user id.
46. Can require multiple passwords.
47. Provides hard disk format protection.
48. Provides capability to log on as a "guest."
49. Provides capability to log on using a log-on floppy disk.
50. Has a maximum password length requirement.
51. Provides full hard disk encryption capability.
52. Provides individual partition encryption capability.
53. Can hide files.
54. Provides a one-time password capability.
55. Can encrypt passwords.
56. Provides protection from Trojan logins.
57. Provides audit log protection.
58. Provides a protected clock for auditing purposes.
59. Provides a comprehensive administrator's and a user's guide.

  DMT Evaluation Matrix (Continued)

Version Control


VERSION CONTROL	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Provides the following check-in features:
Assigns a name to the file.
Assigns a version number to the file.
Assigns and records time/date associated with the file.
Attaches a project to the file.
Attaches related information to the file.
2. Provides check-out features:
Retrieves any version of a file.
Allows only one modifiable copy of any version to be out at any given time.
Locks file that is checked out in a modifiable state.
3. Provides parallel development capability.
4. Notifies users of changes/versions.
5. Generates and retrieves deltas (differences between versions).
6. Stores history of changes.
7. Maintains an audit trail.
8. Has report generation capabilities.
9. Has archiving ability:
Creates archives.
Deletes obsolete archives.
Compresses archives.
Restores archives.
10. Provides searching/browsing mechanism.
11. Invokes applications associated with the file automatically.
12. Handles multiple CALS-compliant data types.
13. Updates copies of data being stored at other locations when data replication is possible in a distributed environment.

  DMT Evaluation Matrix (Continued)

Operation and Maintenance


OPERATION AND MAINTENANCE	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Identifies performance and component problems.
2. Tracks and reports problems.
3. Tracks and reports status of network.
4. Provides real time back-ups of all distributed data.

  DMT Evaluation Matrix (Continued)

Directory Services


DIRECTORY SERVICES	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Conforms to X.500.
2. Has customizing capabilities [user interface, direct access/Application Program Interface (API)].
3. Determines the location of data (repository, database, owner).
4. Determines security level required to access/modify the data.
5. Provides location and number of copies of the data.
6. Gives Identification (I.D.) users accessing the same data.
7. Determines the cost (financial/legal) for accessing data.
8. Calculates acceptable response time for queries.
9. Generates index to related data items.
10. Has index to related processes/applications.
11. Changes notification mechanism.
12 Has acceptable search mechanisms (Boolean, topic, statistical, etc.).
13. Has reporting mechanism for search output, export formats.
14. Has browsing features:
Abstracts for text.
Thumbnails for images.

  DMT Evaluation Matrix (Continued)

Product Data Generation


PRODUCT DATA GENERATION	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Supports the following CALS data types:
Standard Generalized Markup Language (SGML) compliant (MIL-D-28001).
IGES compliant (MIL-D-28000).
Group 4 raster compliant (MIL-D-28002).
Computer Graphics Metafile (CGM) compliant (MIL-D-28003).
2. Allows viewers to pan/zoom/page turn.
3. Supports type B and C SGML.
4. Provides multiple concurrent views.
5. Provides non-destructive translation from non-CALS formats.
6. Provides the following features:
Lines/polylines (fonts/weights/taper).
Spline curves, arcs.
Freehand.
Shapes (circles, ellipses, polygons).
Fills/hatching (definable? CGM).
Dimensioning.
Extrusions.
Surfaces.
Shading/rendering.
Wireframe/hidden line removal.
Multiple concurrent edits.
Multiple layers (per drawing).
Multiple sheets (per drawing).
Plotting/printing.
Zoom.
Software resampling/interpolation.
View modes (angle, clipping planes).
Rotate.
Scale/crop.
Color coding (layers/objects).
Definable color tables.
Invert.
Global changes (text, primitives, objects).
Skew/stretch.
Cut.
Paste, (arrays, rect/circular).
Raster-vector hybrids.
Text annotation.
Format text (font/orientation/path - CGM).
Form blocks/sub-figures.
Select/options.
Group/ungroup.
Undo.
Macros.
User interface requirements.
User-configurable menus.
Grids/snap options.
Accuracy requirements.
What-You-See-Is-What-You-Get (WYSIWYG ).
Digitizing device (support, calibration).
Output device calibration (color, aspect ratio).
Hybrid (raster graphics embedding).
Bookmarks.
Tables.
Graphics embedding.
Page layout control.
Search/find (text, elements/attributes).
Spell check.
Thesaurus.
Grammar check.
Document Type Definition (DDT) definition/modification.
Non-SGML embedding.
7. Meets one of the following IGES classifications:
Class I - Technical Illustration Subset.
Class II - Engineering Drawing Subset.
Class III - Electrical/Electronic Applications Subset.
Class IV - Geometry for NC Manufacturing Subset.
Class V - 3D Piping Application Protocol.
8. Reads, modifies, and creates the following Raster data files:
Type I - Untitled Raster Graphics Data.
Type II - Tiled/Untiled Raster Graphics Data.

  DMT Evaluation Matrix (Continued)

Project Control


PROJECT CONTROL	COMPLIANT CRITERIA (  = Meets Requirements)
VENDOR-PRODUCT
1. Open Systems
Shall be capable of generating applications software that is POSIX standard and is defined by FIPS PUB 151-1, POSIX.
2. GOSIP Compliance
Shall adhere to FIPS PUB 146-1, GOSIP.
3. Graphical User Interface
Shall comply with the X Window System standard in FIPS PUB 158, User Interface Component of the Applications Portability Profile.
4. Computer Programming Language (Ada)
Shall support the development and maintenance of software applications in Ada in accordance with FIPS PUB 119, Ada and MIL-STD-1815A, Ada Programming Language.
5. Code Generator (Ada and others)
Produces compilable Ada code frames (skeletons) for program specifications and program bodies from the design specifications that conform with FIPS PUB 119 and MIL-STD-1815A.
Provides bindings for the following:
1. X Protocol
2. Standard SQL (FIPS PUB 127-1) and the integrity enhancement features defined in American National Standards Institute (ANSI) (X3.135-1989).
3. POSIX
Provides the run-time component(s) required to execute SEE-developed applications compliant with FIPS PUB 161, EDI.
Provides:
1. 66% or more source code that conforms with the design specifications.
2. Consistency between the source code and the design specifications by protecting the portions of the source code generated by the source code generation function.
3. Source code needed for the software application developed design specifications. All source code generated for user interface functions should comply with the X Window System standard and open systems standards.
Has a validated compiler that supports:
Free Form source code file name.
1. Compilation into libraries in directories other than the source code.
2. A command line interface.
3. Batch file scripts.
4. Detection and reporting of static constraint errors during compilation.
5. Invocation of the text editor showing the location of compilation errors within the source code.
Provides an editor to allow implementation details to be added to the source code generated from the design specifications.
Provides an Ada compilation order dependency utility capable of automatically recompiling all necessary source code modules affected by a modification.
Has a library manager that provides the following capabilities:
1. Lists all units in the library.
2. Lists all unit dependencies for each unit in the library.
3. Lists all units dependent on each unit.
4. Supports shared libraries.
5. Relocates program libraries without recompilation.
Has a source code formatting program that can be tailored to reformat source code in accordance with user-defined style guides.
Provides a full interactive symbolic debugger.
Has an intelligent linker that includes only called routines from library units into the final executable image.
Provides run-time analysis functions that provide the following:
1. Percentage of execution time utilized by each procedure/function in the program.
2. Elapsed execution time for each procedure/function in the program.
3. Execution path analysis.
Has a symbol cross-reference utility that defines for each symbol:  the filename, unit name, and physical source code line number in the file where it is defined, and each filename and source code physical line number where it is referenced.
6. Standard Structured Query Language
Uses standard SQL as defined in FIPS PUB 127-1, Database Language SQL, and the integrity enhancement features defined in ANSI X3.135-1989, Database Language SQL with Integrity Enhancement, as the interface to each Relational Database Management System (RDBMS).
7. Operating System
Complies with the POSIX standard as defined by FIPS PUB 151-1.
Provides POSIX-compliant operating system software that meets the criteria of Class B2 and the DAC of Class B3 in accordance with DoD 5200.28-STD and Institute of Electrical and Electronic Engineers (IEEE) P1003.6, Security Interface for POSIX.
8. Methodology Support
Provides software tools that support a widely-used software development methodology that conforms to life cycle process.
Supports the following software development methodologies:
1. Functional.
2. Data-driven.
3. Object-oriented.
4. State transition-oriented.
Provides software tools (e.g., combination of tools) to support object-oriented methodologies.
Supports tailoring of each methodology that will provide a flexible approach, on the part of the using organization, to modify and use the selected methodologies.
Captures the output of the tailored (e.g., newly developed) methodologies as assets for reuse.
9. Life cycle Development Process/Workflow Control
Provides the capability to create a customized model of the process/workflow and integrate it into the process/workflow control mechanism.
Automates some portion of the process.
Provides automated guidance to the users.
Provides automated creation of project libraries, communication between development team members, and locking of files from update after baseline.
Supports the following object/component/document production process/workflow capabilities:
1. Is tailorable (for activity definition, scheduling, and personnel assignment) to fit the developing organization's process/workflow.
2.   Routes the object/component/document   from one production activity (e.g., create,   edit, review, produce) to another.
3.   Limits access for each activity to the   appropriate individuals or groups.
4.   Limits type of access for each activity,   i.e., create, edit, review (read only with   electronic comment capability), browse, and   copy.
5.   Generates a baselined version of the object,   component, or document on completion of   the production process/workflow.
10. Information Repository Control and Access
Supports simultaneous development of multiple projects.
Facilitates the maintenance of technical and process information developed.
Has been available for sale as a COTS product for over six months with an installed base of 10 or more sites.
Integrates COTS components within the I-CASE SEE using an open standard interface that facilitates compatibility and the one-time entry of information.
Stores the relationship between the various pieces of information and the rules for using or processing the information.
Supports a multi-user environment that allows users to access user-specified sets of repository data in a concurrent manner consistent with process/workflow controls and configuration management controls.
Supports the creation and updating of information repository data while providing automatic consistency and validation checks with interactive VC consistent with configuration management needs.
Provides data import capabilities.
Minimizes the storage of redundant data in the information repository.
Provides date and time stamp of all objects.
Maintains all information to support the process model for information management.
Makes information entered by one component available for successive components in the life cycle without reentering the data.
Contains all systems information including project libraries, project management, process and data models, and software system models.
Ensures that no erroneous duplicate entries are entered into the information repository.
Extends to contain all additional objects required by components and methodologies added as the environment evolves.
Provides a data import capability compliant with IRDS import standards.
Provides the capability to consolidate information from multiple projects from multiple sites into one project repository on one site.
11. Information Repository Interface
Provides an interface and interface specifications between the information repository and COTS tools.
Shall have commercially available specifications for the interface between tools and the information repository.
12. Viewing Information Repository Contents
Provides standard reports for an abbreviated view of the information repository contents (on-line and off-line).
Provides the capability to produce ad hoc reports at any time using built-in report writer facilities.
Allows the retrieval of objects in the information repository by date and time.
Provides a user interface to the information repository that is compliant with the panel interface portion of FIPS PUB 156.
13. Information Repository Reporting Capabilities
Provides screen or hard copy report output either from a list of standard options or from a menus/icons selection.
Supports the following types of standard reports:
1. All data entities and their attributes plus relationships.
2. Data modeling description, including component parts.
3. Description of couples at a specified interface in a structure chart.
Supports the following Cross-Reference/Where Used Reports:
1. Lists of objects in the information repository under the responsibility of a specified developer.
2. Lists of diagrams in which a specified data entity/object is referenced.
3. Trace of the course of data from source to destination in a family of process modeling diagrams.
4. Lists of entities that support a specified process.
5. Lists of process models in which a specified process appears.
6. Lists of process models in which a data element appears.
7. Lists of data models in which data element or object appears.
8. Lists of modules invoked by a specified module, or all modules that invoke a specified module.
Provides the following Analysis Reports features:
1. Level-to-level balancing in a family of data models.
2. Identification of inconsistent diagrams that specify the missing elements.
3. Object naming, typing, or description inconsistencies across diagrams and information repository contents.
4. Lists of unused objects in the information repository.
5. Consistency and analysis, with identification of missing relationships between objects whose parents are related.
6. Impact analysis for deletion or modification of an object.
Provides explosion report, including a hierarchical table of a specified object and all lower-level objects.
14. Reuse of Information Repository Objects
Provides functions to support reuse of requirements, design, data structures, code, test data, and associated documentation.
Provides the capability to capture, store, and retrieve specific reuse metrics data that include the frequency of examination, extraction, and actual use of reusable objects.
15. Reusable Requirements
Provides the capability to re-number all object components to conform with the work breakdown structure and configuration management controls as they apply within the new application.
Provides the capability to validate and verify the imported portions of the data model as consistent with the existing model in the new application.
Provides a mechanism to ensure the integrity of the data models.
16. Reusable Design
Provides the capability to trace requirements to the logical data model that was used to derive the design objects (physical data model).
17. Reusable Code
Shall manage the reuse of Ada, C, and other codes to the program unit level (packages, subprograms, tasks, and generics).
18. Reusable Test Data
Shall manage the reuse of test-related objects including test cases, test input data, and test scripts.
19. Reusable Object Library
Shall include a library of reusable COTS software objects (e.g., requirements, design, code, and test data) to support application development in Ada, C, and other languages.
20. Interactive Requirements Capture
Supports the capture of the requirements during multidisciplined team analysis sessions for the evolutionary enhancement of the requirements.
Captures requirements interactively and performs verification, completeness, and consistency checking as the requirements information is entered.
Supports the specification of the requirements in a predetermined (user-defined) format.
Maintains all the components of a requirement and their relationships with one another.
Can trace requirements throughout all subsequent phases of development.
Supports the following requirements analysis functions:
1. Compliance with DoD Directive 8320.1, DoD Data Administration, and DoD Manual 8320.1M, DoD Data Administration Procedures Manual.
2. Production of complete object definitions that are consistent with other information previously stored in the information repository.
3. Interfacing, coordination, and validation of information in the diagram to ensure completeness and consistency within the information repository.
Includes a capability to identify subject area clusters automatically through dependency analysis or semiautomatically through affinity analysis.
Extends mandatory labels on diagrams and the enforcement thereof as defined in DoD 5200.28-STD.
21. Graphically Portrayed Requirements
Provide methodology-specific diagramming capabilities.
Provide the capability to generate drawings from the underlying data.
Provide representation of required hardware and software system components.
Allow concurrent viewing of global and detailed system views (in different windows).
Provide zooming, scrolling, and panning capabilities to navigate through the diagram.
Provide a search feature to locate and display objects and related objects.
Provide for the decomposition of requirements.
Provide the capability to add, modify, or delete diagrams.
Provide the capability to move segments of a diagram from one level to a lower level.
Provide the capability to merge lower level diagrams to create a new diagram.
Provide the capability to automatically reformat diagrams.
Ensure that updates to sub-diagrams are reflected in diagrams viewing it.
Perform methodology-specific verification, completeness, and consistency checking for all diagrams to ensure that each diagram is complete and contains all necessary information to:
1. Ensure that diagram component names (all objects and connections between objects) are consistent with the data dictionary entries.
2. Verify syntax validity for every input to ensure that it conforms to a pre-defined set of values and criteria.
3. Ensure that decomposition rules of the specific methodology are not violated.
4. Ensure that diagram connectivity rules are applied (e.g., data flow diagram processes must have both input and output data flows).
5. Ensure that all objects and connections between objects are properly labeled.
6. Perform cross-diagram checking across a family of diagrams related by diagram explosions.
7. Balance parent and child diagrams across all levels of the system.
8. Verify that entities have a one-to-one, one-to-many, or many-to-many association with at least one other entity.
9. Flag all many-to-many associations and provide warning messages associated with them.
10. Ensure that each attribute is associated with at least one entity or relationship.
11. Ensure that redundant attributes are highlighted.
12. Ensure that the cardinality of each relationship has been defined before a final data model can be generated.
13. Identify errors or warning conditions that include narrative error or warning statements.
22. Prototyping Capabilities
Include components that facilitate a visual representation of requirement (e.g., visual programming) prior to proceeding with the development and implementation of the requirements.
Support both rapid prototyping and evolutionary development of the user interface (screens) and reports for the software applications being produced.
Support user interface (screens) development that complies with FIPS PUB 158.
Provide a screen-based report prototyping function that complies with FIPS PUB 158.
Generate Standard SQL statements to interface with the RDBMS.
Provide the following automated rapid prototyping features:
1. A means of analyzing system sizing and timing requirement.
2. Trade-off analysis by showing the effect of different solutions to the same problem.
3. System performance analysis.
4. A prototyping capability to determine the viability of various database design concepts or algorithmic approaches to the requirements.
5. A prototyping capability to facilitate the determination of the effect that requirement changes will have in other areas of the design.
6. Storage of screen and report format statements in the information repository.
7. Generation of a complete Ada code for the user interfaces and reports that complies with FIPS PUB 158.
23. Design
Provides an automated design component where the requirements are mapped to design components or functions to produce a high level system design.
24. Interactive Design Capture
Provides for the allocation of the requirements to the design elements of the system.
Performs verification, completeness, and consistency checking as the design information is entered.
Provides for the decomposition or logical grouping of design components to satisfy the requirements.
Maintains all the components of a design and their relationships with one another.
25. Graphically Portrayed Design
Facilitates the refinement of the high-level functional components into detailed design modules.
Provides a means of graphically displaying logical and physical relationships between design elements.
Ensures that a module can exist as its own entity.
Provides a means of specifying the interface between design components.
Provides a means for modeling data including:
1. Enforcing strong data typing.
2. Enforcing information hiding and precise interface definition by checking for multiple data definitions, invalid parameters, and interface inconsistencies.
3. Supporting cross referencing of data for accessibility and type compatibility.
Provides methodology-specific diagramming capabilities for control flow and data flow to describe the processes of the components and their inter-relationships.
Provides the capability to generate design drawings from the underlying requirements data.
Facilitates representation of required software system components.
Allows concurrent viewing of global and detailed system views (in different windows).
Provides zooming, scrolling, and panning capabilities to navigate through the diagrams.
Provides search feature to locate and display objects and related objects.
Provides for the decomposition of designs.
Provides the capability to add or delete diagrams.
Provides the capability to move segments of a diagram from one level to a lower level.
Provides the capability to merge lower level diagrams to create a new diagram.
Provides the capability to reformat diagrams.
Ensures that updates to sub-diagrams are reflected in diagrams viewing it.
Ensures that diagram component names (all objects and connections between objects) are consistent with the data dictionary entries.
Verifies syntax validity for every input to ensure that it conforms to a pre-defined set of values and criteria.
Ensures that decomposition rules of the specific methodology are not violated.
Ensures that diagram connectivity rules are applied (e.g., data flow diagram processes must have both input and output data flows).
Ensures that all objects and connections between objects are properly labeled.
Performs cross-diagram checking across a family of diagrams related by diagram explosions.
Balances parent and child diagrams across all levels of the system.
Verifies that entities have a one-to-one, one-to-many, or many-to-many association with at least one other entity.
Flags all many-to-many associations and provides warning messages associated with them.
Ensures that each attribute is associated with at least one entity or relationship.
Ensures that redundant attributes are highlighted.
Ensures that the cardinality of each relationship has been defined before a final data model can be generated.
Flags and reports recursive functions for user disposition.
Identifies errors or warning conditions.
Supports the creation of a logical database design.
Provides interactive syntax and type checking to ensure that all diagrams conform to a pre-defined set of values and governing criteria and to prevent entering incorrect or nonsensical information into the information repository.
Provides methodology-specific diagramming capabilities for control flow and data flow to describe the processes of the components and their inter-relationships.
Extends mandatory labels on diagrams and the enforcement thereof as defined in DoD 5200.28-STD.
26. Data Definition Language (DDL) Generation