【正文】 a required and provided interface. The respective interface classes and their operations are shown below the structure diagram. Documentation of Internodal and Intranodal CommunicationThe benefits of a service requestdriven system modeling approach–specifically, the definition of required and provided interfaces–bee obvious when it es to the documentation of plex, networkcentric, systemofsystems architectures. A monly used artifact for the documentation of internodal and intranodal munication is the Nsquared (N2) chart. Fig. 23 shows an example. The N2 chart is structured by locating the basic nodes of munication on the diagonal, resulting in an NxN matrix for a set of N nodes. For a given node, all outputs are located in the row of that node and inputs are in the column of that node.Fig. 23 Documentation of Node Input/Output by Means of an N2 Chart (DFD Notation)Fig. 24 shows the UML/SysML equivalent notation for Fig. 23. The upper part depicts the N2 chart with the respective required/provided interfaces. For each node a more detailed description can be achieved by replacing the interface names in the chart with the assigned messages and associated parameters. N2 charts are generated from the data in the model repository. In the FCSET modeling project N2 charts are chosen for the DoDAF pliant documentation. For example, via the provided use case 1 and use case 3 scenariosIt was decided to apply the scenariobased approach as it facilitates the later verification and validating of the network through model execution. An N2 chart was generated from the use case 1 and use case 3 sequence diagrams (see Appendix 1) and the information verified by crosschecking it with the OV3 information. The interface definition will also be based on this N2 chart.Fig. 28 shows an example of the static structure of the FCSET operational view model for the N11FcsCommonEtSubsystem node together with a section of the N2 chart from which links and interfaces were derived.N1131SafBlueControlSubsystemN1132SafRedNeutralControlSubsystemN1133SafEngineN114EmbeddedSimulationComputationN115EmbeddedDataRepositoryN116OcOtSubsystemN1131SafBlueControlSubsystemN1131iN1133_N1131N1132SafRedNeutralControlSubsystemN1132iN1133_N1132N1133SafEngineiN1131_N1133iN1132_N1133N1133iN114_N1133iN116_N1133N114EmbeddedSimulationComputationiN1131_N114iN1132_N114iN1133_N114N114iN115_N114N115EmbeddedDataRepositoryiN114_N115N115N116OcOtSubsystemiN1133_N116iN114_N116N116Fig. 28 N11FcsCommonEtSubsystem Structure Diagram and portion of N2 Chart Dynamic ModelingDynamic modeling describes the process of adding behavior to the static model. This is achieved by mapping use case scenarios to the operational architecture.It starts with the definition of integrated use case scenarios. In an integrated use case scenario the information from the provided OV6 diagrams and the OV3 matrix 0 is bined into a coherent set of information.In Rhapsody, sequence diagrams may be generated in two modes: analysis mode or design mode. Sequence diagrams generated in the analysis mode are purely graphical. Any message or operation defined in this mode is just text. In the design mode messages and operations are automatically put into the operation field of the receiving block. It is possible to switch from the analysis mode to the design mode. This transition is called realization.The definition of an integrated use case scenario will be done in analysis mode. Once an integrated use case scenario is generated and approved, it will be mapped to the operational network via realization. After the realization of messages and operations, the mapped messages are allocated to respective node interfaces.A message may initiate a state/mode change or some actions at the receiving node. This should be reflected in the node statechart diagram. However, none of the use case descriptions provide enough information to build a respective statechart diagram. Therefore, it is suggested to confine node statebased behavior to the definition of protocol state machines, which reflect only the input/output behavior of a node.The mapping of an integrated use case scenario to the operational architecture will be verified/validated through model execution.The following sections demonstrate the different steps of the outlined workflow for a specific use case scenario. Case Study: Definition of an Integrated Use Case ScenarioThe scenario Synchronize Training Data Files of use case3 Conduct Battle Focused Unit Training Management was chosen to demonstrate the different steps of the dynamic modeling workflow. Fig. 29 shows the provided sequence diagram. Details regarding the messages 34, 264, 265, 38, 29, and 176 were taken from the provided OV3 documentation 0.Fig. 210 depicts the sequence diagram of the derived integrated use case scenario. The message names reflect the actual service requests. Operations that result from service requests are shown at the respective lifeline (. N51AtiaM) as reflexive messages. Data were added as arguments to messages when they were considered essential from the information flow point of view, . retRetrieveArchivedData_38 (data=UnitData)Note: Because there is no information on the format of the data passed within messages, all data types will be implemented using simple enumerations. For example, in the message above, an enumeration called RepositoryData was created which contains a literal called UnitData. In the future, these enumerations can be replaced with actual data types once their format is known.Fig. 29 Provided Scenario Synchronize Training Data FilesFig. 210 Integrated Scenario Synchronize Training Data Files Case Study: Mapping the Use Case Scenario into the OV ArchitectureFig. 211 shows the populated operational nodes after the realization of the messages an