【正文】 eway 64Fig. 68 Traceability Analysis Using the Rhapsody Gateway 65Fig. 69 Traceability Analysis Using the Rhapsody Gateway 66Fig. 610 The DOORS Project Including Modules Exported from Rhapsody 67Fig. 71 Mapping UML Artifacts to DoDAF Architecture Products 68Fig. 72 Setting a DoDAF Stereotype 69Fig. 73 Setting DoDAF Project Tags 70Fig. A51 Setting the Requirement Attribute for DOORS Objects 84Fig. A52 The Rhapsody Requirements Gateway Project Configuration 85Fig. A53 Configuring the Rhapsody Model Export to DOORS 86 Error! No text of specified style in document.1 Introduction ScopeAs part of the System Design and Development (SDD) Phase of the Future Combat Systems program, the Future Combat Systems LSI has developed an architecture document that describes the Embedded Training Architecture for the Future Combat Systems (FCS)equipped portion of the Unit of Action (UA). This document describes the architecture development process for the FCS Training Architecture, the relationship to other FCS architectures, and the operational, systems, and technical views to support the FCS training concept. Embedded Training is expected to be a softwareintensive system that is distributed within the FCS System of Systems. It is important that the developed FCS bat systems and subsystems fully support this FCS Training Architecture.A critical area to examine is the correctness and pleteness of the architecture Operational View. To this end, General Dynamics Land Systems (GDLS) has contracted ILogix Professional Services (IPS) to capture and analyze the Embedded Training Architecture Operational View using an executable UML model. IPS will use ILogix Rhapsody Developer in C++ to create this model. In addition to ILogix Rhapsody, Telelogic Doors will be used for requirements management, and Microsoft Visual Source Safe will be used for configuration management.This Future Combat Systems – Embedded Training (FCSET) Modeling handbook provides guidance by summarizing the approach and best practices followed on this project. The initial release of this handbook contains the best practices that evolved over years of field experience on dozens of projects in the Military amp。190。190。 Jim CollinsPaul Urban Stephen DiCamilloILogix Professional ServicesILogix Professional ServicesILogix Professional ServicesApproved By:190。190。190。 190。190。190。 190。190。190。 Table of FiguresFCS Embedded Training (FCSET) Modeling HandbookRelease/Revision:Release/Revision Date:2022/9/14Prepared by: 190。190。190。190。190。190。190。190。190。190。190。190。190。 Modeling Guidelines Model DocumentationAlso provided are several appendices, including overviews of the FCSET Operational Node Interfaces, Operational Node Hierarchical Structure, a quick reference guide of the ILogix Rhapsody Action Language, a glossary, additional supporting best practices and tips, and a set of references.2 Modeling ApproachThis section describes a modeldriven approach to the specification of the SystemofSystems (SoS) architecture of the Future Combat Systems Embedded Training (FCSET) using the Department of Defense Architectural Framework (DoDAF).First, an introduction to the chosen approach is given. Then, a description of how the approach is implemented in the modeling process for FCSET is provided. Finally, the resulting Rhapsody project structure is outlined along with a discussion on how the project is verified and validated. Fundamentals Service RequestBased System ModelingThe service requestbased system modeling approach specifically supports the design of networkcentric architectures. Its main characteristics are that the internode and intranode munication is based on message exchanges (service requests) rather than on the definition of data/control flows. The approach is UML/SysMLbased and uses the UML notation of required and provided interfaces.In the approach, the system structure is described by means of UML/SysML posite structure diagrams, using blocks (SysML: Assemblies) as basic structure elements and ports as “named connection points”.Fig. 21 UML/SysML Composite Structure DiagramThere are two different kinds of ports (see Fig. 21). Delegation or relay ports forward requests to other ports. Behavioral ports are the parts of the block that actually implement the services.Each port can have provided and/or required interfaces. A provided interface (denoted by a lollipop symbol) specifies a set of messages received at that port from elements outside the current block. A required interface (denoted by a socket symbol) specifies a set of messages sent from that port to elements outside the current block. Thus, by characterizing an interface as required or provided, the direction of the constituent messages at the port is defined. With regard to the naming of interfaces the following convention is used in this document:iServiceProvidingNode_ServiceRequestingNodeThe mechanics of the service requestdriven system modeling approach is shown in Fig. 22. The message exchange between two blocks is visualized in the upper part of Fig. 22 by means of a sequence diagram. Service requests are sent as events, and the actual provisions of those services are shown as reflexive operations (“messages to self”) at the lifeline of the receiving block. Both the service request messages and the associated service operations may have parameters. Typically, parameters are added at a later stage, when details with regard to the respective services are known.Fig. 22 Service RequestDriven Modeling ApproachThe resulting structure diagram is shown below the sequence diagram. In the operation partment of each block, the received messages are listed as public and the provided services are listed as private (padlock icon). Both blocks have