This training covers how to work with the SWQL query language in the item report generation in SystemWeaver. Examples and exercises are provided.
Suitable for class training or self-study.
Approximately 2 hour to half-day course.
- Completed the SystemWeaver Report Generation - Introductory Training.
- Familiarity with SystemWeaver concepts such as Items, Parts and Attributes, and also with the GUI and common operations of the swExplorer.
- Knowledge of XML.
- An installation of the SystemWeaver client (swExplorer).
- A training server (If the course leader has not set up a server for the class, you can set up your own server by following the instructions in Setting up a Test Server).
- An installation of the Script Language Training sqlite training database. See Database for Script Language Training.
The answers to all exercises can be found in the swExplorer ribbon tab Report Training>Answers under SWQL.
Note: This presentation does not cover GUI and view concepts.
The specialized context language for SystemWeaver can be used to generate information in reports and documents for complex scenarios that the basic report generation features cannot handle. It also provides a means of counting items and following parts backwards in the defined context. In addition, it enables you to "merge" different perspectives.
This course does not cover the complete functionality and available options. After completing this course, explore all available features by using the SystemWeaver Help accessed by clicking the ? in the swExplorer or by taking the next course.
SQWL Example Scenarios not Solvable with Basic Report Generation Features
The context language takes a different approach from the basic report generation features:
- Build a context tree
- Navigate the model (context tree)
With contexts, it is possible to build a virtual context tree with only the information of interest. A typical case of usage is to utilize the context tree to separate relevant information from irrelevant information.
"Where is this component used?"
"Which component sends this signal?"
"Which requirements are derived from this requirement?"
To answer the questions above, we must separate the relevant information, such as older versions of the current development project or other development projects, from the current one. This can be done with the context and the virtual context tree built in it.
What is a Context Tree?
A context tree is a filtered collection of data where only the relevant information is present.
SWQL Example 1
From the Architecture, list all E2E Funtions in the E2E Function List using SWQL.
<AddParts owner="main" sid="3EFL" part="archToE2EList" defobj=”E2EList"/>
<AddParts owner="E2EList" sid="3PEN" part="E2EListToE2E” defobj=”E2Es"/>
<ForEachInContext name="architectureTop" group="E2Es">
Building a Context Tree Using <AddParts>
The <Context> tag is the starting point of a context. Before any use of context tags, a context must be defined with the <Context> tag. The <Context> tag builds a virtual tree of parts with <AddParts/>.
The context can be defined anywhere in a report and is valid for the item for which it is defined.
Context Tag Consisting of <AddParts/>
<AddParts> Tag Attributes
The AddParts tag is always applied with at least the four attributes of owner, sid, part and defobj.
The group that owns the parts to be added. Owner can be previously defined as defobj or "main". Main is a default keyword for the entry item. Note: If the report or view has any Parameters defined, there will automatically be contexts defined corresponding to each parameter using the name(s) of the parameter(s).
The SID for the part of interest.
A name for the parts to be added. This can later be used to traverse the virtual context tree with, for instance, <ContextGoForward/> and <ContextGoBack/>.
A name for the group of items, that the parts are linked to.
Using the Context Tree Groups
To get a list of all items into a group of a specific context, use the <ForEachInContext> tag. All contextual go forward/back tags must be enclosed by the <ForEachInContext> tag.
The resulting report would look like this:
Traverse Backwards for Parts in Context Tree
The <ContextGoBackToPart> tag is used to traverse backward in the context tree, following the part-group (predefined in <context>) and specified by part="". This tag results in a list of parts as opposed to items.
Traverse Backwards for Items in Context Tree
The <ContextGoBack> tag is used to traverse backward in the context tree, following the part-group (predefined in <context>) and specified by part="". This tag is the same as <ContextGoBackToPart> except that it results in a list of items as opposed to parts.
Traverse Forward/Down in Context Tree
To move forward in the context tree, use the ContextGoForward (for items) and ContextGoForwardToPart (for parts). The principle is the same here as for ContextGoBack and ContextGoBackToPart tags, except that you move forward/down in the ContextTree instead of backwards.
Tip: To traverse from the part, resulted from <ContextGoForwardToPart>, to the item (defobj); apply <ContextGoForward>.
<AddParts owner="main" sid="IRRS" part="sub" defobj="section"/>
<AddParts owner="section" sid="ISSE" part="sub" defobj="+section"/>
<AddParts owner="section" sid="IRE" part="references" defobj="reference"/>
<ForEachInContext name="context1" group="section">
Prints the name of all reference-parts and reference-items from sections in the document.
- My Reference Part Name
- My Reference
The graphical representations shown in this article are rendered by the Context Visualizer tool. When you have created your context in the report editor, highlight it and then right-click and select Show context visualizer to get a graphical presentation of your context.
You can learn more about this tool and its menu options in the Help.
Exercise 1 - SWQL Context Definitions
- Open Item x04000000000000EC.
Using the meta model shown below, complete the following definitions:
- Print the names of all Design Signals that are sent using <Context>.
- Use <ContextGoBack> to print the Application Component that sends a Design Signal.
- From the ApplicationComponent, use <ContextGoForward> to print the E2E it realizes (Hint: You will have to modify the context).
Tip: To produce an empty row for readability between each context in your definition, use <Text></Text>.
SWQL Example 2
For each component, list the Design Signals that it sends and the components that receive that design signal.
By combining groups of Items, it is possible to ”Move forward” along one part defined into a group and then ”Move back” following another part:
”From Components, follow sendPorts down to DesignSignals,
From Design Signals follow receivePorts up to Components”
Exercise 2 - SWQL Context Definitions
- Open Item x04000000000000EC.
- For each component, list the Design Signals that it sends and the components that receive that design signal.
The resulting output would look something like this:
Design Signal : DesignSignalName
Combining Groups of Items - A Note on "+"
When adding items to the same group more than once, you can modify the behavior of how they are added by including or omitting the ”+” symbol.
The ”+” indicates that you want to perform a union operation, adding all the newly found items to the already existing group, establishing relations to items already existing in that group.
By omitting the ”+”, new items will not be added to the group, but you establish relations to items already existing in that group.
Exercise 3 - SWQL Context Definitions
- Open Item x04000000000000EC.
- For each EndToEnd Function in the EndToEnd Function List, print the Design Signals sent and received by the components that realize the End To End Functions.