Advanced modeling methods, such as the unified modeling language, extend these documentation capabilities and can be used to describe the entire system without the use of traditional documentary texts.
The use of the Object Oriented models for documentation may be acceptable for commercial developments but is often not possible for military or government contracts. Commercial software developments usually have a shorter lifecycle with more frequent revisions than military applications. Time to market is a major concern with commercial developments, and because their maintenance will be performed in-house, commercial developers can safely sacrifice documentation for speed.
A military system, however, is rarely developed in-house and is often maintained or upgraded by a contractor rather than a developer. In addition, many military developments involve safety-critical systems where careful testing to clearly defined requirements is required for a successful system's implementation. Therefore, sufficient documentation must be available to describe the system requirements for the software tester and maintainer. A written description of the system software requirements that complements the OO models is needed to help testers and maintainers understand the system.
Such a written description is often described to as the Software Requirements Specifications (SRS). The SRS is a key document in the software development process. It captures the essential requirements of the system and provides the basis that is used to test the system. If all SRS requirements are mapped to test cases and all test cases are passed, it is reasonable to assume that the system will meet the intended purpose. Although this goal can be achieved through the use of OO models, conversion of models into plain language can reduce ambiguity and help clearly define the system requirements.
Description of the Object-Oriented Method
Here, we assume a development approach that uses the OO methodology and notation described by James Rumbaugh and augmented by Ivar Jacobson's use case analysis. The discussion here is limited to the requirements analysis phase of the software development lifecycle. The inputs to this phase include the preliminary system architecture in raw terms, i.e., number of processors, preliminary network layout, etc., and a top-level problem statement.
In most military developments, the problem statement is in the form of a system or subsystem specification, but for the problem at hand, we describe the common example of a bank's automated teller machine (ATM). There are many outputs of the requirements analysis activity: metrics, trade studies, prototypes, and so forth, but the primary concern here shall be with use cases, models, and SRSs.
During requirements analysis, the general course of model design is that the problem statement is studied to identify objects or classes of objects and the relationship between objects. A set of scenarios or use cases are developed that help identify objects and describe the behavior of the system. The objects and their relationships are expressed graphically on an object diagram. A State Transition Diagram depicts the permitted states of an object and