- Go to the Neo4 browser and run the following query to view the generated graph.
match (n)-[r]->(m) return n,r,m
Figure 10: Run query to get all nodes and edges in the graph.
The top of the graph shows a color index of the different types of nodes and relationships in the graph, e.g. Activity, Block, ConstraintBlock, DataType, Interaction, InterfaceBlock, etc. These represent the concept areas of SysML that are being covered by the SysML -> Graph generation process. All the key concepts from the 9 areas of SysML are being covered. - After re-arranging the nodes, the graph will look similar to as shown in Figure 11 below. The top-level blue nodes are the packages and their sub-packages. The main packages under the System package are (L-R): Structure, Interactions, Stereotypes, Requirements, Use Cases, Activities, State machines.
Figure 11: Partial rearrangement of nodes to show the top-level package structure (blue nodes)
Run the following query to get the package structure in the model:
match(p:Package) return p
Figure 12: Get all packages in the model
Run the following query to get all blocks in the model: match(b:Block) return b
This fetches all the blocks in the model and their inter-relationships, including generalization (inheritance), part/reference/shared properties, and full ports. All the blocks inherit from the System Block. The UAV block is the top-level structural element and it has several part properties.
Figure 13: Get all blocks. Relationships are shown since Auto-Complete is ON (bottom RHS)
Run the following query to get all the requirements in the model - match (r:Requirement) return r
Figure 14: Get all requirements in the model
Run the following query to get all the immediate child requirements for a given requirement
match(r:Requirement{name:"cUAV Specification"})-[:Containment]->(rc:Requirement) return r,rc
Figure 15: Get all child requirements of a given requirement
Get all relationships (ingoing and outgoing) for a given requirement - match(r:Requirement{name:"cUAV Specification"})-[rel]-(n) return r,rel,n
Figure 16: Get all relationships for a given requirement
Run the following query to get all inheritance (generalization) relationships between blocks. Note: Turn off Auto-Complete to see only Generalization relationships.
match(b:Block)-[r:Generalization]->(p:Block) return b,r,p
Figure 17: Get all generalization relationships between blocksRun the following query to get all value properties of all blocks. Turn on Auto-Complete to see the Generalization relationships. It shows the UAV block has its own value properties but will also inherit value properties from the System block -
match(b:Block)-[r:ValueProperty]->(t) return b,r,t
Figure 18: Get all generalization relationships between blocks
Run the following query to get all full and proxy ports of all blocks. Turn on Auto-Complete if you want to see relationships between the blocks (e.g. PartProperty) - match(b)-[r:FullPort|ProxyPort]->(t) return b,r,t
Figure 19: Get all full and proxy ports of all blocks
Run the following query to get all constraint properties of all blocks - match(b:Block)-[r:ConstraintProperty]-(t) return b,r,t
Figure 20: Get all relations for the UAV blockRun the following query to get all relationships—outgoing and incoming—for a specific block (e.g. UAV). Turn off Auto-Complete of relations
match(b:Block{name:"UAV"})-[r]-(t) return b,r,t
Run the following query to check if there are any orphaned requirements, i.e. requirements that do not have any incoming or outgoing relations. There are none at this point.
match(r:Requirement) where size((r)-[]-())=0 return r
Figure 22: Get all orphaned requirementsYou can try creating a new isolated requirement using the command below and then re-run the query above.
create(r:Requirement{name:”Test”})
Run the following query to get all the behaviors (activities, state machines, and interactions) associated with all the blocks.
match(b:Block)-[r]-(f) where(f:Activity OR f:StateMachine OR f:Interaction) return b,r,f
The example MagicDraw and Rhapsody models differ on how behaviors are modeled in them and hence the results of the query will be different depending upon if the graph was generated from a MagicDraw SysML model or Rhapsody SysML model. See Figure 23 for MagicDraw results and Figure 24 for Rhapsody results.
Only the UAV block has associated behaviors in the model. We have associated behaviors to the UAV SysML block in two different ways that represent typical modeling usage:
Block element contains the behavior element. This is the case when the behavior is modeled as an owned behavior (or classifier behavior) of the block.
- Behavior is assigned to the block through a dependency relationship, typically allocate.
Rhapsody does not allow us to model all behaviors using both the approaches, e.g. state machines must be owned by a block and cannot be owned by a package and allocated to a block. Hence, the Rhapsody and MaigcDraw models are different.
Figure 23: Get all behaviors of all blocks (MagicDraw model result)
Figure 24: Get all behaviors of all blocks (Rhapsody model result)
Run the following query to get all the use cases in the model. Turn on Auto-Complete to view the Generalization relationships between use cases.
match(u:UseCase) return u
Run the following query to get applied stereotypes and tag values for the UAV block. If you select the relationship, you can see the values of the tags (target_life, budget, and owner) populated for the UAV block.
match(b:Block{name:"UAV"})-[r]->(s:Stereotype) return b,r,s
Figure 26: Get applied stereotypes and tag values for the UAV block
General
Content
Integrations