Commit 61e6e95e authored by Daniel Ratiu's avatar Daniel Ratiu
Browse files

improvements of the help

refs 865
parent 0838e27f
......@@ -6,7 +6,7 @@
@author becker
@author $Author$
@version $Rev$
@ConQAT.Rating YELLOW Hash: E66F5CAAF3C0656199D508C575014686
@ConQAT.Rating YELLOW Hash: 81A9F2893F6B184E7E733846EDFCDAFE
-->
<html>
......@@ -20,7 +20,7 @@
<h3><font color="#336699">Creating a Glossary</font></h3>
To model the problem domain, a glossary can be created. The glossary is automatically linked to the requirements specifications. Using the glossary it is easily visible whether the agreed vocabulary is used in all descriptions.
A glossary is used to capture the vocabulary of the problem domain. Once created, the glossary is automatically linked to the requirements specifications. Using the glossary it is easily visible whether the agreed vocabulary is used in all descriptions.
<br><br>
To create a new glossary, select <i>Glossary</i> in the context menu of a requirements analysis.
<br><br>
......
......@@ -58,10 +58,10 @@ Requirements consist of four respectively five sections:
<br><br>
For further description of the entry you can add pictures. To add a picture click on the <i>Add</i> button and choose an image file in the dialog.
You can add as many pictures as you want.
Each image has a description field which can be used to give information about the picture and to number the pictures.
If you click on an added picture, it should be displayed in full resolution in your systems picture viewer. <br>
When you add a picture it is copied into the <i>images</i> folder in the <i>AF3-Project-Directory</i>, next to your .af3_20 file.
If you want to send the model file to someone else, you should also send the <i>images</i> folder.
Each image has a description field which can be used to give information about the picture and to number the pictures.
If you click on an added picture, it should be displayed in full resolution in your systems picture viewer. <br>
<br><br>
Requirements can be connected with each other using different relation types. The connection is set in the section <i>Related Requirements</i>.
......@@ -107,7 +107,9 @@ select <i>Formal Specification</i>.
<br><br>
Within a formal specification different kind of models like component architectures, state machines, etc. can be used.
For more information see <i>Modeling and simulation</i>. Formal specifications can be the tested automatically with test suites and can be refined to the architecture level, for both see <a href="model_testing.html">Test Model</a>.
For more information see <i>Modeling and simulation</i>. Formal specifications can be used as input for the generation of test cases
<a href="model_testing.html">Model-based Testing</a>. The conformance of the architecture implementation with the formalized requirements
can be tested as described in <a href="refinement_testing.html">Refinement Testing</a>.
<br><br>
<img src="./pictures/MIRA.FormalSpecification.png">
......@@ -169,7 +171,7 @@ The button <i>Export in ReqIF standard</i> opens a dialog, where all textual req
<h3><font color="#336699">Verification</font></h3>
MIRA contains automated verification and there is the possibility to save the results of manual checks.
MIRA offers support for automatic verification of requirements. Furthermore, it also offers the possibility to save the results of manual checks.
<br><br>
......@@ -191,11 +193,11 @@ The list is extracted from a XML-Template, which can be modified. At the moment,
<h3><font color="#336699">Connection of use case and component architecture</font></h3>
In the section <i>Detail</i> of a use case a simple connection between use case and component architecture can be done:
In the section <i>Detail</i> of a use case, a simple connection between use case and component architecture can be done:
<ul>
<li>connecting the scope of the use case with component of the component architecture</li>
<li>connecting the trigger of the use case with input of the component architecture</li>
<li>connecting the pre-condition, min. guarantee, success guarantee of the use case with status of the state automaton of the component architecture</li>
<li>setting the scope of the use case to be a component of the component architecture</li>
<li>connecting the trigger of the use case with an input port of the component architecture</li>
<li>connecting the pre-condition, min. guarantee, success guarantee of the use case with states of a state automaton of the component architecture</li>
</ul>
When the scope of a use case is connected with a component, then the reference to this use case is also listed below the component. So you can easily see which use cases belong to one component.
......
......@@ -6,7 +6,7 @@
@author rosenberger
@author $Author$
@version $Rev$
@ConQAT.Rating GREEN Hash: 9DD3773C884477C704290683776FE580
@ConQAT.Rating YELLOW Hash: C3C8034EED1917C2F6708406161FA6BD
-->
<html>
......@@ -48,8 +48,8 @@ Those can be added to the message sequence chart via drag-and-drop - as seen in
<h4><font color="#336699">Connecting MSC Entities</font></h4>
<i>MSC Entities</i> represent different instances which will interact with each other. They can be connected by holding the <i>Ctrl-Button</i> on your keyboard while clicking on one <i>MSC Entity</i> and dragging with the mouse to another <i>MSC Entity</i>.
The result of this action is a <i>Message</i> between the two entities that has an <i>Exit</i> and an <i>Entry</i>. All of these objects can be renamed in the <i>Properties</i> section.
<i>MSC Entities</i> represent different instances which interact with each other. They can be connected by holding the <i>Ctrl-Button</i> on your keyboard while clicking on one <i>MSC Entity</i> and dragging with the mouse to another <i>MSC Entity</i>.
The result of this action is a <i>Message</i> between the two entities that has an <i>Exit</i> and an <i>Entry</i>. All these objects (entities, messages, ...) can be renamed in the <i>Properties</i> section.
<br><br>
<img src="./pictures/MSC.conect_MSC_Entities.png">
......@@ -59,9 +59,9 @@ The result of this action is a <i>Message</i> between the two entities that has
A <i>Loop</i> defines a certain repetition of <i>Messages</i>. Conditions for start and end of the loop can be set in the properties section.
<br><br>
A <i>Condition</i> defines a predicate. For <i>Conditions</i> a condition expression can be set in the properties section.
A <i>Condition</i> is a predicate that the system must satisfy at a certain time moment. For <i>Conditions</i> a condition expression can be set in the properties section.
<br><br>
Both can be added to your message sequence chart by pulling it into the <i>MSC Specification</i>, resizing it and bringing it in the appropriate position.
Both conditions and loops can be added to your message sequence chart by pulling them into the <i>MSC Specification</i>, resizing them and bringing them in the appropriate position.
<i>Loops</i> and <i>Conditions</i> can be associated with more than one <i>MSC Entity</i>.
<br><br>
The following picture shows an example for a <i>MSC Specification</i> including every object mentioned in the above sections:
......
......@@ -6,7 +6,7 @@
@author becker
@author $Author$
@version $Rev$
@ConQAT.Rating GREEN Hash: D341E0D5DAD6CA28C62F8ACBC76E9E7C
@ConQAT.Rating YELLOW Hash: BC065F8971699465C495D483354CECA9
-->
<html>
......@@ -18,7 +18,7 @@
<h2><u><font color="#336699">Defining a Data Dictionary</font></u></h2>
AutoFOCUS supports user defined data types. You can define Functions and Enumerations.
AF3 supports the definition of data types (e.g. enumerations) and functions by using the data-dictionary.
If your project has no Data Dictionary yet, please add it in the context menu of your project.
<br><br>
......
......@@ -5,7 +5,7 @@ Getting started help page.
@author becker
@author $Author$
@version $Rev$
@ConQAT.Rating YELLOW Hash: E51574776F7F25A6F3647EE2E057A9CC
@ConQAT.Rating YELLOW Hash: 2589E5F06909F04865A67A03742D317E
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
......@@ -109,16 +109,16 @@ for architecture, behaviour and platform</li>
<img src="gettingStarted/img/sim.png" alt="" width="200" height="200" border="1" /><br/>
<br/>
<p style="margin-left:50px">
<a href="code_specification.html">Code Specifications</a><br />
<a href="component_architecture.html">Component Architectures</a><br />
<a href="data_dictionary.html">Data Dictionary</a><br />
<a href="mode_automaton.html">Mode Automatons</a><br />
<a href="component_architecture.html">System Architecture Modeling</a><br />
<a href="data_dictionary.html">Data Modeling</a><br />
Behaviour Modeling:<br />
<a href="code_specification.html">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Code Specifications</a><br />
<a href="state_automaton.html">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- State Automata</a><br />
<a href="mode_automaton.html">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Mode Automata</a><br />
<a href="platform_architecture.html">Hardware Architecture Modeling</a><br />
<a href="simulation_with_af3.html">Simulation</a><br />
<a href="operatorpanels.html">Operator Panels</a><br />
<a href="platform_architecture.html">Platform Architecture</a><br />
<a href="simulation_with_af3.html">Simulation</a><br />
<a href="state_automaton.html">State Automatons</a><br />
</p>
</td>
</tr>
......@@ -131,7 +131,7 @@ for architecture, behaviour and platform</li>
<li>Flexible generation of C, Java, etc code</li>
<li>Deployment on different hardware platform <br />
<br />
<li>Generation of platform specific code <br />
<br />
<img src="gettingStarted/img/codedepl.png" alt="" width="200" height="200" hspace="80" border="1" /><br />
<br />
......@@ -139,8 +139,8 @@ for architecture, behaviour and platform</li>
</ul>
<p style="margin-left:50px">
<a href="code_generation.html">Code Generation for Components and Deployments</a><br />
<a href="deployment.html">Deployments</a><br />
<a href="code_generation.html">Code Generation</a><br />
<a href="deployment.html">Deployments Definition</a><br />
</p>
</td>
......@@ -156,10 +156,11 @@ and Yices SMT solver</li>
<img src="gettingStarted/img/WAF3verification.png" alt="" width="200" height="200" hspace="80" border="1" /><br />
<br/>
<p style="margin-left:50px">
<a href="model_markers_view.html">On the Fly Checking of Constraints</a><br />
<a href="model_markers_view.html">On the Fly Constraints Checking</a><br />
<a href="model_checking_with_af3.html">Model Checking</a><br />
<a href="non_determinism_analysis.html">Nondeterminism Analysis</a><br />
<a href="model_testing.html">Model Based Testing</a><br />
<a href="refinement_testing.html">Refinement Testing</a><br />
</p>
</td>
......
......@@ -6,7 +6,7 @@
@author li
@author $Author$
@version $Rev$
@ConQAT.Rating GREEN Hash: 499D90CBFD2C61350E3BD245A2921541
@ConQAT.Rating YELLOW Hash: 18E74D9E70BCD6FEBE1DCD6B11271E50
-->
<html>
......@@ -116,6 +116,10 @@ The ports, which are highlighted in blue rectangles, should associate with the p
<br>Figure 6: Example of a mode component structure.
<br><br>
<!--
MODE DIAGRAMS DO NOT HAVE DATA YET
<h4><font color="#336699">Data State Variables</font></h4>
Data State Variables (DSVs) are internal variables that can be accessed in all modes of the corresponding mode automaton.
......@@ -127,6 +131,8 @@ To edit such a variable to a mode automaton, click the <i>Mode Data</i> tab in y
<br><br>
The way to edit the variable is described in <a href="state_automaton.html"><i>State Automaton</i></a>. Please check there for more information about Data State Variable.
--->
<br><br>
......
para<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of the Semantic Inspector View.
......@@ -6,23 +6,24 @@ para<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
@author becker
@author $Author$
@version $Rev$
@ConQAT.Rating GREEN Hash: C81C721A8E154D8755281C247DF17645
@ConQAT.Rating YELLOW Hash: 611638FA00651E79FB4BB89458CFC74F
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Test model with AF3</title>
<title>Model-based Testing with AF3</title>
</head>
<body>
<h2><u><font color="#336699">Test model with Auto FOCUS 3</font></u></h2>
<h2><u><font color="#336699">Model-Based Testing</font></u></h2>
<font color="#000000" style="font-family:Verdana, Geneva, sans-serif" size="2px">
<h3><font color="#336699">Introduction</font></h3>
AF3 integrates a model-based testing framework with the following features:
<ul>
<li><b>Generate test suites from models with the given coverage criteria or input profiles</b></li>
<li><b>Simulate the model with a selected test case.</b></li>
<li><b>Simulate the model by using a test case as input.</b></li>
<li><b>Update the test suite if the model is changed.</b></li>
</ul>
......@@ -92,96 +93,5 @@ AF3 integrates a model-based testing framework with the following features:
<li> <b>Step 3</b> - A new test suite will be created by AF3 with the same inputs and re-computed outputs.
</ul>
<h3><font color="#336699">Refinement Tests</font></h3>
With a refinement specification it can be tested whether a concrete (implemented) component shows the same behavior as an abstract component or a functional specification.
Steps to create a refinement test suite:
<ul>
<li> <b>Step 1</b> - Right click on the concrete component in the model navigator and select "Refinement Specification"
to create a refinement specification for it.
<br>
<br>
<img src="./pictures/Testing.Refinement.create_refinement_specification.png">
<br>
<br>
The refinement specification should then automatically be opened.
<li> <b>Step 2</b> - In the opened refinement specification click on the "Choose” button and select in the following dialog
the abstract component of which the concrete component should be a refinement.
<br>
<br>
<img src="./pictures/Testing.Refinement.choose_abstract_button.png">
<br>
<img src="./pictures/Testing.Refinement.choose_abstract_dialog.png">
<br>
<br>
After choosing the abstract component the representation and interpretation functions for the refinement specification are automatically generated. Their purpose is to specify the mapping of the input and output ports from the abstract to the
concrete component and the other way round (see picture below). If necessary they can transform the values.
<br>
<br>
<img src="./pictures/Testing.Refinement.picture_functions.png">
<br>
<br>
<li> <b>Step 3</b> Expand the refinement specification in the model navigator to see the functions node. Expand again the functions node to
see the refinement and interpretation functions.
<br>
<br>
<img src="./pictures/Testing.Refinement.functions.png">
<br>
<br>
If you double click on the functions node it is opened in the editor and you can see
the input and output ports which the representation and interpretation functions have.
<li> <b>Step 4</b> Create a behavior specification (e.g. code specification, automaton specification etc.) for the representation and
interpretation functions, like for a normal component. The behavior of the function should map its input ports to its output ports.
A simple example for such behavior definition is the following code specification, which directly maps Input1 of the abstract component to Input1
of the concrete component.
<br>
<br>
<img src="./pictures/Testing.Refinement.code_spec.png">
<br>
<br>
<li> <b>Step 4 b</b> Instead of using the abstract input you can also assign random values to certain inputs ports of the concrete component
for which the values cannot be derived from the abstract input. To use random input for one input port check the "Use random value" checkbox for
the port in the refinement specification editor.
<br>
<br>
<img src="./pictures/Testing.Refinement.random_input.png">
<br>
<br>
Then additional input fields will be shown in which you can specify details for the random value creation.
<li> <b>Step 5</b>
After specifying all port mappings or setting the input ports to random values you can now test if the concrete component is a correct
refinement of the abstract component. To run the test right click of the refinement specification in the model navigator and select
"Test Refinement".
<br>
<br>
<img src="./pictures/Testing.Refinement.test_refinement.png">
<br>
<br>
In the following dialog you have to choose a test suite of the abstract component. The input values of the abstract test suite will be used
as input for the refinement test and the interpreted output will be compared to the output of the abstract test suite.
After choosing the abstract test suite a refinement test suite will be generated:
<br>
<br>
<img src="./pictures/Testing.Refinement.refinement_test_suite.png">
<br>
<br>
It shows the test values in the following order: abstract input, concrete input (result of the representation function or random values),
concrete output, abstract output compared with the interpreted output(listed as "simulated value" if different).
If the compared outputs do not match in one test step, it and the parent test case and test suite will be marked with an error symbol.
<br>
<br>
The test cases in the refinement test suite can be also simulated on the model, like described in <a href ="#simulate">"Simulate Test Case"</a>.
</ul>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of the Semantic Inspector View.
@author becker
@author $Author: hoelzl $
@version $Rev: 4470 $
@ConQAT.Rating YELLOW Hash: 0CEE3344CA21C64C4E002F2FAF41749F
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Refinement Testing</title>
</head>
<body>
<h2><u><font color="#336699">Refinement Testing</font></u></h2>
<font color="#000000" style="font-family:Verdana, Geneva, sans-serif" size="2px">
<h3><font color="#336699">Introduction</font></h3>
A concrete (implemented) component refines an abstract component if the concrete component shows the same behavior as an abstract component.
AF3 provides means for checking the refinement with the help of model based testing. Basically, a test suite is generated based on the abstract
component specification and these tests are then transported to the implementation level and used to check whether the implementation complies
with the abstract specification.
<h3><font color="#336699">Testing the Refinement</font></h3>
Steps to create a refinement test suite:
<ul>
<li> <b>Step 1</b> - Right click on the concrete component in the model navigator and select "Refinement Specification"
to create a refinement specification for it.
<br>
<br>
<img src="./pictures/Testing.Refinement.create_refinement_specification.png">
<br>
<br>
The refinement specification should then automatically be opened.
<li> <b>Step 2</b> - In the opened refinement specification click on the "Choose" button and select in the following dialog
the abstract component of which the concrete component should be a refinement.
<br>
<br>
<img src="./pictures/Testing.Refinement.choose_abstract_button.png">
<br>
<img src="./pictures/Testing.Refinement.choose_abstract_dialog.png">
<br>
<br>
After choosing the abstract component the representation and interpretation functions for the refinement specification are automatically generated. Their purpose is to specify the mapping of the input and output ports from the abstract to the
concrete component and the other way round (see picture below). If necessary they can transform the values.
<br>
<br>
<img src="./pictures/Testing.Refinement.picture_functions.png">
<br>
<br>
<li> <b>Step 3</b> Expand the refinement specification in the model navigator to see the functions node. Expand again the functions node to
see the refinement and interpretation functions.
<br>
<br>
<img src="./pictures/Testing.Refinement.functions.png">
<br>
<br>
If you double click on the functions node it is opened in the editor and you can see
the input and output ports which the representation and interpretation functions have.
<li> <b>Step 4</b> Create a behavior specification (e.g. code specification, automaton specification etc.) for the representation and
interpretation functions, like for a normal component. The behavior of the function should map its input ports to its output ports.
A simple example for such behavior definition is the following code specification, which directly maps Input1 of the abstract component to Input1
of the concrete component.
<br>
<br>
<img src="./pictures/Testing.Refinement.code_spec.png">
<br>
<br>
<li> <b>Step 4 b</b> Instead of using the abstract input you can also assign random values to certain inputs ports of the concrete component
for which the values cannot be derived from the abstract input. To use random input for one input port check the "Use random value" checkbox for
the port in the refinement specification editor.
<br>
<br>
<img src="./pictures/Testing.Refinement.random_input.png">
<br>
<br>
Then additional input fields will be shown in which you can specify details for the random value creation.
<li> <b>Step 5</b>
After specifying all port mappings or setting the input ports to random values you can now test if the concrete component is a correct
refinement of the abstract component. To run the test right click of the refinement specification in the model navigator and select
"Test Refinement".
<br>
<br>
<img src="./pictures/Testing.Refinement.test_refinement.png">
<br>
<br>
In the following dialog you have to choose a test suite of the abstract component. The input values of the abstract test suite will be used
as input for the refinement test and the interpreted output will be compared to the output of the abstract test suite.
After choosing the abstract test suite a refinement test suite will be generated:
<br>
<br>
<img src="./pictures/Testing.Refinement.refinement_test_suite.png">
<br>
<br>
It shows the test values in the following order: abstract input, concrete input (result of the representation function or random values),
concrete output, abstract output compared with the interpreted output(listed as "simulated value" if different).
If the compared outputs do not match in one test step, it and the parent test case and test suite will be marked with an error symbol.
<br>
<br>
The test cases in the refinement test suite can be also simulated on the model, like described in <a href ="#simulate">"Simulate Test Case"</a>.
</ul>
</body>
</html>
\ No newline at end of file
......@@ -6,7 +6,7 @@ Contracts-based Specification for Components.
@author becker
@author $Author: becker $
@version $Rev: 3250 $
@ConQAT.Rating YELLOW Hash: 8D8BC9D602CDE0AEB127BA08E7783E98
@ConQAT.Rating YELLOW Hash: FA12DF4BC6A460BFCD04BAF3E1968D0C
-->
<html>
......@@ -16,17 +16,17 @@ Contracts-based Specification for Components.
</head>
<body>
<h2><u><font color="#336699">Creating a Patterns based Specification for a Component</font></u></h2>
<h2><u><font color="#336699">Creating Contracts based Specifications for Components</font></u></h2>
Components are used both as secification of requirements as well as for modeling the architecture.
Components are used both as specification of requirements as well as for modeling the architecture.
Whenever we use components, we can specify their black-box behavior with the help of contracts.
In AF3 we distinguish among four kinds of contracts:
<ul>
<li><b>Assumptions</b> represent invariants over the input ports of a component. Simply said, assumptions are what a certain component
expects as valid input from the environment (e.g. a certain input port has values between some range or that
expects as valid input from the environment (e.g. a certain input port has values within a certain range;
some input port has a value that is always bigger than the value of another port).</li>
<li><b>Guarantees</b> represent invariants over the output ports of a component. Guarantees are conditions that a certain component
promises to the environment. </li>
promises to its environment. </li>
<li><b>Basic Contracts</b> represent logical expressions of the form "if inputs satisfy assumption A then component outputs will satisfy the guarantee G
(after a certain number of steps)"</li>
<li><b>Advanced Contracts</b> represent complex conditions about the relation between the inputs of a component and the outputs
......@@ -34,7 +34,7 @@ promises to the environment. </li>
</ul>
A temporal logics specification is made of one or more contracts (assumptions, guarantees, basic/advanced contracts).
The main place where the assumptions, guarantees and basic contracts are defined during the specification phase is the "Contracts View".
The main place where the assumptions, guarantees and basic contracts are defined during the specification phase is the "Contracts Specification" view.
<br><br>
<img src="./pictures//Model.Checking.Contracts.Specification.View.png">
......
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of AF3-Workflow.
@author becker
@author $Author$
@version $Rev$
@ConQAT.Rating GREEN Hash: AF9EA639EB8F1EFFFCF0ACA8037A39A3
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>The Workflow of AutoFOCUS3 (AF3)</title>
</head>
<body>
<h2><u><font color="#336699">The Workflow of AutoFOCUS3</font></u></h2>
<h3><u><font color="#336699">Overview</font></u></h3>
</body>
</html>
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment