计算机软件及应用FCSETModelingHandbook

1、FCS- Embedded Training (FCS-ET) Modeling HandbookRelease/Revision:Release/Revision Date:3.02022/2/13Prepared by: Jim CollinsPaul Urban Stephen DiCamilloI-Logix Professional ServicesI-Logix Professional ServicesI-Logix Professional ServicesApproved By:Peter HoffmannI-Logix Professional ServicesTable

2、of Contents1 Introduction11.1 Scope11.2 Document Overview12 Modeling Approach32.1 Fundamentals32.1.1 Service Request-Based System Modeling32.1.2 Documentation of Inter-nodal and Intra-nodal Communication52.1.3 System-of-Systems Operational View Modeling Workflow72.2 Building the FCS-ET Operational V

3、iew Model92.2.1 Static Modeling102.2.2 Dynamic Modeling112.3 Project Structure in Rhapsody182.3.1 Operational View Package182.4 Verification and Validation242.4.1 Verification and Standards Compliance242.4.2 Validation Against Requirements243 Modeling Guidelines283.1 General Guidelines and Drawing C

4、onventions283.2 Essential UML Diagrams293.2.1 Use Case Diagram293.2.2 Structure Diagram313.2.3 Sequence Diagram353.2.4 Activity Diagram383.2.5 Statechart Diagram413.3 Profiles and Customization443.3.1 FCS-ET Profile443.3.2 DoDAF Profile454 Configuration Management464.1 Strategy464.1.1 Dependency on

5、Model Structure474.1.2 Rhapsody Model Elements474.1.3 Rhapsody Project File494.1.4 Mapping Project Structure to Archive494.1.5 Protecting from Loss of Data524.1.6 References524.2 Release Guidelines524.2.1 Labeling524.3 Workflow524.3.1 Versioning555 Change Management565.1 Strategy565.2 Internal Chang

6、e Management Workflow565.3 External Change Management Workflow575.3.1 Failure Incidents575.3.2 Requirements Changes586 Requirements Traceability596.1 Strategy596.2 Workflow606.2.1 Requirements Identification in the Source Documents616.2.2 Requirements Re-organization to Support the Project Structure

7、616.2.3 Importing Requirements into the Rhapsody Model626.2.4 Linking Requirements to Model Elements in Rhapsody636.2.5 Impact Analysis636.2.6 Requirements Traceability Report Generation646.2.7 Exporting the Rhapsody Model to DOORS667 Model Documentation687.1 DoDAF Report Generation687.1.1 DoDAF Ste

8、reotypes:687.1.2 Tags697.2 Generating a DoDAF Report70Appendix 1 Operational Node N2 Chart Derived From Scenarios71Appendix 2 Operational Node Connectivity Description Tiers76Appendix 3 Action Language77A3.1 Basic syntax77A3.2 Assignment and Arithmetic Operators77A3.3 Printing77A3.4 Comparison Opera

9、tors78A3.5 Conditional Statements78A3.6 Incremental Looping Statements79A3.7 Conditional Looping Statements79A3.8 Invoking Operations79A3.9 Generating Events79A3.10 Referring to Event Parameters in Transitions80A3.11 Testing the Port on which an Event Arrives80A3.12 Testing the State of a State Mach

10、ine80Appendix 4 Best Practices for Working with Visual SourceSafe81A4.1 Setting up VSS and Rhapsody to show version numbers in SCC81A4.2 Tips with SourceSafe81A4.3 Working with Rhapsody Project for the First time82Appendix 5 Tips for Requirements Management and Traceability84A5.1 Marking Requirement

11、s in DOORS84A5.2 Setting up the Requirements Gateway Project84A5.3 Exporting Requirements to DOORS85Glossary87References88Attachment I: Non-Disclosure Agreement89Table of FiguresFig. 21 UML/SysML Composite Structure Diagram3Fig. 22 Service Request-Driven Modeling Approach4Fig. 23 Documentation of No

12、de Input/Output by Means of an N2 Chart (DFD Notation)5Fig. 24 Documentation of Inter/Intra-Node Communication Using UML/SysML Notation6Fig. 25 SoS Operational View Modeling Workflow7Fig. 26 Transition from Black-Box View to White-Box View8Fig. 27 Modified Operational View Modeling Workflow for FCS-

13、ET10Fig. 28 N11FcsCommonEtSubsystem Structure Diagram and portion of N2 Chart11Fig. 29 Provided Scenario - Synchronize Training Data Files13Fig. 210 Integrated Scenario - Synchronize Training Data Files13Fig. 211 Populated Operational Nodes after Realization of Messages and Operations14Fig. 212 Allo

14、cation of Messages to Interfaces (Port pN241 of N51AtiaM)15Fig. 213 Protocol State Machine for N241FcsWebServices15Fig. 214 Protocol State Machine for N1111UtManagementSystem16Fig. 215 Protocol State Machine for N1111UtManagementSystem - SynchronizeTrainingDataMode17Fig. 216 Top-Level Project Struct

15、ure18Fig. 217 Operational View Package Structure18Fig. 218 Use Cases Package Structure19Fig. 219 Operational Nodes Package Structure20Fig. 220 N1FcsBattleCommandSystem Node Decomposition21Fig. 221 N1111UtManagementSystem Node Decomposition21Fig. 222 Interfaces Package Structure22Fig. 223 Contents of

16、 the TO_N241_Pkg Interface Package23Fig. 224 Model Deployment using Components24Fig. 225 Recording an Animation Script25Fig. 226 Test Conductor Driver Scenario - Synchronize Training Data Files26Fig. 227 Graphical Test Engine (FCS-ET Targeting Console)27Fig. 31 Use Case Diagram30Fig. 32 Structure Di

17、agram33Fig. 33 Sequence Diagram36Fig. 34 Activity Diagram39Fig. 35 Statechart Diagram42Fig. 41 Connection to Configuration Management Archive47Fig. 42 Visual SourceSafe Archive Reflects Model Hierarchy48Fig. 43 Rhapsody Model Structure50Fig. 44 Windows Files Structure50Fig. 45 CM Repository Structur

18、e51Fig. 46 Including Descendants in Check Out Operation51Fig. 47 Synchronize Operation52Fig. 48 Configuration Items Dialog53Fig. 49 Flow of Users Accessing the Same File54Fig. 51 Internal Change Request Spreadsheet56Fig. 52 External Change Request Spreadsheet56Fig. 53 Internal Change Management Work

19、flow57Fig. 54 External Change Management Workflow58Fig. 61 Requirements for the Operational View59Fig. 62 Requirements Management and Traceability Workflow60Fig. 63 The initial DOORS Project Set of Modules61Fig. 64 The initial DOORS Project Set of Modules61Fig. 65 The Requirements Imported into Rhap

20、sody as Seen in the Gateway62Fig. 66 Anchoring Requirements to Rhapsody Model Elements63Fig. 67 Impact Analysis Using the Rhapsody Gateway64Fig. 68 Traceability Analysis Using the Rhapsody Gateway65Fig. 69 Traceability Analysis Using the Rhapsody Gateway66Fig. 610 The DOORS Project Including Modules

21、 Exported from Rhapsody67Fig. 71 Mapping UML Artifacts to DoDAF Architecture Products68Fig. 72 Setting a DoDAF Stereotype69Fig. 73 Setting DoDAF Project Tags70Fig. A51 Setting the Requirement Attribute for DOORS Objects84Fig. A52 The Rhapsody Requirements Gateway Project Configuration85Fig. A53 Conf

22、iguring the Rhapsody Model Export to DOORS861 Introduction1.1 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 Comb

23、at 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 T

24、raining is expected to be a software-intensive system that is distributed within the FCS System of Systems. It is important that the developed FCS combat systems and subsystems fully support this FCS Training Architecture.A critical area to examine is the correctness and completeness of the architec

25、ture Operational View. To this end, General Dynamics Land Systems (GDLS) has contracted I-Logix Professional Services (IPS) to capture and analyze the Embedded Training Architecture Operational View using an executable UML model. IPS will use I-Logix Rhapsody Developer in C+ to create this model. In

26、 addition to I-Logix 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 (FCS-ET) Modeling handbook provides guidance by summarizing the approach and best practices

27、 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 & Aerospace, Transportation, Telecom, Medical, Industrial Automation and Consumer Electronics industries. As this is a new pro

28、ject with several unique aspects, these best practices are expected to evolve as the project progresses. Consequently, this is a living document and will be updated periodically throughout the project.1.2 Document OverviewThis document is intended to apply to any group needing to accomplish a task s

29、imilar to the stated Scope. While IPS effort involved four co-located engineers, this handbook has been developed with scalability in mind to support larger distributed teams, although the guidance provided here may need extension under certain circumstances.As this documents primary purpose is to c

30、onvey knowledge to the reader, small illustrative examples are used extensively to provide clear and concise guidance.Note that this handbook is not a substitute for training, but complementary to it. In fact, this handbook assumes the reader has basic working knowledge of the UML, I-Logix Rhapsody

31、and its add-on products, Telelogic DOORS, and Microsoft Visual SourceSafe.The remainder of this document is broken into several sections addressing the major components of the model development effort: Modeling Approach Modeling Guidelines Configuration Management Change Management Requirements Trac

32、eability Model DocumentationAlso provided are several appendices, including overviews of the FCS-ET Operational Node Interfaces, Operational Node Hierarchical Structure, a quick reference guide of the I-Logix Rhapsody Action Language, a glossary, additional supporting best practices and tips, and a

33、set of references.2 Modeling ApproachThis section describes a model-driven approach to the specification of the System-of-Systems (SoS) architecture of the Future Combat Systems - Embedded Training (FCS-ET) using the Department of Defense Architectural Framework (DoDAF).First, an introduction to the

34、 chosen approach is given. Then, a description of how the approach is implemented in the modeling process for FCS-ET is provided. Finally, the resulting Rhapsody project structure is outlined along with a discussion on how the project is verified and validated.2.1 Fundamentals2.1.1 Service Request-B

35、ased System ModelingThe service request-based system modeling approach specifically supports the design of network-centric architectures. Its main characteristics are that the inter-node and intra-node communication is based on message exchanges (servicerequests) rather than on the definition of dat

36、a/control flows. The approach is UML/SysML-based and uses the UML 2.0 notation of required and provided interfaces.In the approach, the system structure is described by means of UML/SysML composite structurediagrams, using blocks (SysML: Assemblies) as basic structure elements and ports as “named co

37、nnection 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

38、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

39、 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:i_The mechanics of the service request-driven system modeling approach is shown in Fig. 22

40、. 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 th

41、e 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 Request-Driven Modeling ApproachThe resulting structure diagram is shown below the seq

42、uence diagram. In the operation compartment of each block, the received messages are listed as public and the provided services are listed as private (padlock icon). Both blocks have a required and provided interface. The respective interface classes and their operations are shown below the structur

43、e diagram.2.1.2 Documentation of Inter-nodal and Intra-nodal CommunicationThe benefits of a service request-driven system modeling approach-specifically, the definition of required and provided interfaces-become obvious when it comes to the documentation of complex, network-centric, system-of-system

44、s architectures. A commonly used artifact for the documentation of inter-nodal and intra-nodal communication is the N-squared (N2) chart. Fig. 23 shows an example. The N2 chart is structured by locating the basic nodes of communication on the diagonal, resulting in an NxN matrix for a set of N nodes

45、. 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 res

46、pective 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 FCS-ET modeling project N2 charts

47、are chosen for the DoDAF compliant documentation. For example, The inter-nodal operational information matrix (DoDAF OV3 view), and The inter-nodal/intra-nodal, system-to-system interface descriptions (DoDAF SV1 and SV6 views)Fig. 24 Documentation of Inter/Intra-Node Communication Using UML/SysML No

48、tation2.1.3 System-of-Systems Operational View Modeling WorkflowEssentially, a DoDAF compliant modeling approach consists of two steps. First the operational view model is generated. Then the operational view model is morphed into a system view model by clustering operational nodes into system nodes

49、, which then are further decomposed. Fig. 25 details the workflow and the associated work products of a system-of-systems operational view modeling process. The process starts with the definition of high-level use cases, graphically represented in a use case diagram. The operational view model is bu

50、ilt incrementally on the basis of the following analysis performed on each individual use case.Fig. 25 SoS Operational View Modeling WorkflowFor each use case the underlying functional flow needs to be identified. This functionality is captured in the black-box activity diagram (Fig. 26). Swim lanes

51、 in this activity diagram are the external actors and the SoS. The flow of activities (operational contracts (OpCons) represent the interactions between these swim lanes.Once the functionality is sufficiently understood, the operational nodes structure is defined and captured in a structure diagram.

52、 There is no link between the nodes at this stage.The next step is the allocation of the black-box SoS activities to the operational nodes. First, the SoS swim lane in the black-box activity diagram is decomposed into OpNode swim lanes. Then, the activities are moved into respective node swim lanes

53、without disconnecting their links (Fig. 26). The flow of activities in this white-box activity diagram represents the interactions between the operational nodes.Fig. 26 Transition from Black-Box View to White-Box ViewIn the next step use case scenarios are defined and described by means of sequence

54、diagrams with the SoS nodes and actors as lifelines. In these sequence diagrams the message exchange (service requests) between nodes as well as the resulting activities at respective nodes are captured. By mapping these use case scenarios to the operational architecture (Rhapsody: realization), the

55、 associated ports, links, and interfaces are defined for each involved operational node.A message may initiate a state/mode change at the receiving node. The respective node state-based behavior is captured in a statechart diagram. The statechart diagram is extended incrementally for each use case s

56、cenario.The mapping of a use case scenario to the operational architecture is verified/validated through model execution as described in the Verification and Validation section of this document.2.2 Building the FCS-ET Operational View ModelThe following sections describe in detail how the operationa

57、l view model of FCS-ET will be built. Essentially, the workflow outlined in section 2.1.3 will be followed. Basic information for the modeling is provided by the SDD document 0 and the OV3 matrix 0. But, the provided information proved to be insufficient.In 0, four high level use cases are defined:Use Case 1: Conduct Multi-Mode (LVC) TrainingUse Case 2: Conduct Operational RehearsalUse Case 3: Conduct Battle-Focused Unit Training ManagementUse Case 4: Conduct Individual Self Development Training ManagementFor use case 1