【正文】 sages and operations in the integrated use case scenario Synchronize Training Data Files. The node ports and interfaces typically are defined during the static modeling phase.Fig. 211 Populated Operational Nodes after Realization of Messages and OperationsFig. 212 shows the operational contracts bound to port pN241 of node N51AtiaM. Message reqRetrieveArchivedData_264 has been allocated to the provided interface iN51_N241 and retRetrieveArchivedData_265 has been allocated to the required interface iN241_N51.Fig. 212 Allocation of Messages to Interfaces (Port pN241 of N51AtiaM) Case Study: Definition of Node StateBased BehaviorFig. 213 shows the protocol state machine of the N241FcsWebServices node related to the Synchronize Training Data Files scenario. This simple state machine relies on Reactions in State to produce the proper outputs for the specific inputs in the scenario.Fig. 213 Protocol State Machine for N241FcsWebServicesAn alternate technique for modeling protocol state machines is shown in Fig. 214.Fig. 214 Protocol State Machine for N1111UtManagementSystemUsing this approach, the toplevel modes of operation for the N1111UtManagementSystem node are captured in a statechart. When initialized, the node enters the “WaitingForMode” state. When the evSynchronizeTrainingData event is received, the node enters the “SynchronizeTrainingDataMode” state. Once that state is done, the node returns to the “WaitingForMode” state.Each mode of operation is captured in a sub state machine. Fig. 215 shows the sub state machine of the “SynchronizeTrainingDataMode” state. This state machine models the messaging protocol as a series of steps that must occur in order.Fig. 215 Protocol State Machine for N1111UtManagementSystem SynchronizeTrainingDataMode Project Structure in RhapsodyA system of systems is typically a huge application whose behavior cannot be specified by a single team. Instead, the behavior of the application is partitioned across several systems that are allocated to different teams. Behavior is further partitioned into subsystems in a recursive fashion, and so on. The project structure within Rhapsody must support this recursive deposition in addition to supporting collaboration across multiple teams. This section describes the structure of the FCSET project using screen shots from the Rhapsody browser. The Modeling Guidelines chapter can be referenced for additional information on the elements shown in these browser screen shots. The toplevel structure of the FCSET project is shown in Fig. 216.Fig. 216 TopLevel Project StructureA set of ponents is used to execute and analyze the model, as described in the Verification and Validation section of this handbook.The Operational View package holds the UML artifacts related to the DoDAF Operational View. The contents of this package are discussed in detail in the remainder of this section.The Systems View package holds the UML artifacts related to the DoDAF Systems View. This package is included as a “placeholder” solely for pleteness. Further deposition of the Systems View package falls beyond the scope of the current contract.Finally, a set of UML profiles customizes the model specifically for the FCSET project and DoDAF. Operational View PackageThe Operational View package contains a Requirements folder along with a Use Cases package, Operational Nodes package, and a Validation package, as shown in Fig. 217.Fig. 217 Operational View Package Structure Requirements FolderThe Requirements folder holds the UML artifacts essential for tracing the requirements captured in Telelogic Doors to elements in the Rhapsody model. See the Requirements Traceability chapter in this handbook for additional information on the contents of this package. Use Cases PackageThe Use Cases package captures the functional requirements of the system by describing interactions between users of the system and the system itself.Fig. 218 Use Cases Package StructureAs can be seen in Fig. 218, the Use Cases package holds all of the external actors that municate with the system. It also holds the use case diagrams. Each use case is placed into its own package. Within that package, an activity diagram may describe the use case in detail (if available) and can allocate behavior to specific operational nodes via swim lanes. The various scenarios through the activity diagram are captured with a set of sequence diagrams. Use cases can be further deposed into sub use cases in a recursive fashion. Operational Nodes PackageThe Operational Nodes package holds the static building blocks of the FCSET project. These building blocks are interconnected via ports and links through which all munication flows using welldefined interfaces. The dynamic behavior of each block is described using statechart diagrams.Fig. 219 shows all of the toplevel operational nodes modeled using Rhapsody blocks. The interconnections between the toplevel operational nodes are captured in a Links folder. An Interfaces packages holds all of the information related to the operational contracts between the nodes. Finally, a set of hierarchical structure diagrams describe the operational nodes and their interconnections in detail.Fig. 219 Operational Nodes Package StructureIn order to understand the hierarchical deposition of the operational nodes, Fig. 220 takes a look inside the N1FcsBattleCommandSystem node. As can be seen in the figure, N1FcsBattleCommandSystem contains three sub nodes: N11FcsCommonEtSubsystem, N12FcsUmsControlSubsystem, and N13FcsCopSubsystem. The interconnections between these sub nodes are captured in a Links folder and the ports on N1FcsBattleCommandSystem are captured in a Ports folder.Fig. 220 N1FcsBattleCommandSystem Node DepositionAs can be seen in Fig. 221, this hierarchical deposition continues down to the leaf operational nodes. In this case, the browser has b