|
From: <ag...@us...> - 2010-03-05 15:32:21
|
Revision: 661
http://scstudio.svn.sourceforge.net/scstudio/?rev=661&view=rev
Author: agmy
Date: 2010-03-05 15:32:12 +0000 (Fri, 05 Mar 2010)
Log Message:
-----------
Resolution of pictures in documentation (acyclic, nonlocal choice, fifo) changed to 80 px/inch
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/acyclic/pictures/acyclic.png
trunk/doc/help/acyclic/pictures/cyclic_result.png
trunk/doc/help/acyclic/pictures/cyclic_simple.png
trunk/doc/help/fifo/fifo.html
trunk/doc/help/fifo/pictures/fifo1.png
trunk/doc/help/fifo/pictures/fifo2.png
trunk/doc/help/fifo/pictures/label_channel_fifo.png
trunk/doc/help/fifo/pictures/nonfifo1.png
trunk/doc/help/fifo/pictures/simple_non_fifo.png
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/localchoice/pictures/simple_nonlocal.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCA.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCB.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_implied.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_result.png
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-03-05 12:21:53 UTC (rev 660)
+++ trunk/doc/help/acyclic/acyclic.html 2010-03-05 15:32:12 UTC (rev 661)
@@ -9,10 +9,10 @@
<BODY>
<H1>Acyclic property</H1>
<P> Acyclic property ensures that there is no cyclic dependency among events in a MSC. Such an dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such MSC design can be seen on the following figure:</P>
-<IMG SRC="pictures/cyclic_simple.png" WIDTH="187" HEIGHT="293" BORDER="0" ALT="Cyclic MSC" TITLE="Cyclic MSC">
+<IMG SRC="pictures/cyclic_simple.png" BORDER="0" ALT="Cyclic MSC" TITLE="Cyclic MSC">
<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
<P> Result of SCStudio on such design highlights the cyclic dependency:</P>
-<IMG SRC="pictures/cyclic_result.png" WIDTH="187" HEIGHT="293" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
+<IMG SRC="pictures/cyclic_result.png" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
<P> A more tricky example of an acyclic design:</P>
-<IMG SRC="pictures/acyclic.png" WIDTH="187" HEIGHT="293" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
-</BODY>
\ No newline at end of file
+<IMG SRC="pictures/acyclic.png" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
+</BODY>
Modified: trunk/doc/help/acyclic/pictures/acyclic.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/acyclic/pictures/cyclic_result.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/acyclic/pictures/cyclic_simple.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-03-05 12:21:53 UTC (rev 660)
+++ trunk/doc/help/fifo/fifo.html 2010-03-05 15:32:12 UTC (rev 661)
@@ -24,7 +24,7 @@
instance <I>q</I> receives message <I>m2</I> before <I>m1. </I>Because
we are having a FIFO channel between instances <I>p</I> and <I>q</I>,
this is not possible and leads to a deadlock.</P>
-<img src="pictures/simple_non_fifo.png" width="304" height="180" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
<P>A more formal definition follows:</P>
<P>BMSC is FIFO if for all receive events c, d and their matching send events
@@ -33,16 +33,16 @@
to the same channel.</P>
<P>Tricky examples of FIFO MSCs:</P>
-<img src="pictures/fifo1.png" width="228" height="304" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<img src="pictures/fifo2.png" width="228" height="304" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
<P>An example of a non-FIFO design can be seen on the following figure:</P>
-<img src="pictures/nonfifo1.png" width="228" height="304" border="0" alt="non-FIFO MSC design" title="non-FIFO MSC design">
+<img src="pictures/nonfifo1.png" border="0" alt="non-FIFO MSC design" title="non-FIFO MSC design">
<H3>FIFO channel for every pair of instances and labels</H3>
<P>In this case we can have more than one FIFO channel between two processes. For every label there is one channel. Everything what has satisfied FIFO property in the previous case, will satisfy also in this case. The difference can be seen on the following FIFO example:</P>
-<img src="pictures/label_channel_fifo.png" width="304" height="180" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/label_channel_fifo.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
<P>Messages <I>m2</I> and <I>m1</I> are not in the same channel, therefore they may arrive in
any order.</P>
Modified: trunk/doc/help/fifo/pictures/fifo1.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/pictures/fifo2.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/pictures/label_channel_fifo.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/pictures/nonfifo1.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/pictures/simple_non_fifo.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-03-05 12:21:53 UTC (rev 660)
+++ trunk/doc/help/localchoice/localchoice.html 2010-03-05 15:32:12 UTC (rev 661)
@@ -11,15 +11,15 @@
<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches MSC A or MSC B) are possible and the branches are initiated by different instances (MSC A is initiated by instance p, MSC B is initiated by instance q). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
<DIV class="gallery vary">
<table><caption align="bottom">HMSC</caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal.png" WIDTH="492" HEIGHT="246" BORDER="0" ALT="HMSC specification with a branching node" title="HMSC specification with a branching node">
+<IMG SRC="pictures/simple_nonlocal.png" BORDER="0" ALT="HMSC specification with a branching node" title="HMSC specification with a branching node">
</tr></td></table>
<table><caption align="bottom">MSC A</caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_MSCA.png" WIDTH="264" HEIGHT="297" BORDER="0" ALT="MSC A" TITLE="MSC A">
+<IMG SRC="pictures/simple_nonlocal_MSCA.png" BORDER="0" ALT="MSC A" TITLE="MSC A">
</tr></td></table>
<table><caption align="bottom">MSC B</caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_MSCB.png" WIDTH="264" HEIGHT="297" BORDER="0" ALT="MSC B" TITLE="MSC B">
+<IMG SRC="pictures/simple_nonlocal_MSCB.png" BORDER="0" ALT="MSC B" TITLE="MSC B">
</tr></td></table>
</DIV>
@@ -34,10 +34,10 @@
<DIV class="gallery vary">
<table><caption align="bottom">Result of SCStudio</caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_result.png" WIDTH="330" HEIGHT="200" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio">
+<IMG SRC="pictures/simple_nonlocal_result.png" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio">
</tr></td></table>
<DIV class="gallery vary">
<table><caption align="bottom">Implied behavior</caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_implied.png" WIDTH="240" HEIGHT="297" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior">
+<IMG SRC="pictures/simple_nonlocal_implied.png" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior">
</tr></td></table>
-</BODY>
\ No newline at end of file
+</BODY>
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCA.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCB.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal_implied.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal_result.png
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ob...@us...> - 2010-03-09 22:55:51
|
Revision: 677
http://scstudio.svn.sourceforge.net/scstudio/?rev=677&view=rev
Author: obouda
Date: 2010-03-09 22:55:43 +0000 (Tue, 09 Mar 2010)
Log Message:
-----------
Frontend help
Modified Paths:
--------------
trunk/doc/help/CMakeLists.txt
trunk/doc/help/help.css
trunk/doc/help/scstudio.hhc
trunk/doc/help/scstudio.hhp
Modified: trunk/doc/help/CMakeLists.txt
===================================================================
--- trunk/doc/help/CMakeLists.txt 2010-03-09 22:53:38 UTC (rev 676)
+++ trunk/doc/help/CMakeLists.txt 2010-03-09 22:55:43 UTC (rev 677)
@@ -10,6 +10,7 @@
DEPENDS
help.css
algorithms.html
+ frontend.html
localChoice/localchoice.html
membership/membership.html
fifo/fifo.html
Modified: trunk/doc/help/help.css
===================================================================
--- trunk/doc/help/help.css 2010-03-09 22:53:38 UTC (rev 676)
+++ trunk/doc/help/help.css 2010-03-09 22:55:43 UTC (rev 677)
@@ -18,4 +18,11 @@
}
caption {
font-size: 0.7em;
-}
\ No newline at end of file
+}
+img.big {
+ margin: 1em;
+}
+code {
+ font-size: 1.2em;
+}
+
Modified: trunk/doc/help/scstudio.hhc
===================================================================
--- trunk/doc/help/scstudio.hhc 2010-03-09 22:53:38 UTC (rev 676)
+++ trunk/doc/help/scstudio.hhc 2010-03-09 22:55:43 UTC (rev 677)
@@ -9,6 +9,10 @@
</OBJECT>
<UL>
<LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Frontend">
+ <param name="Local" value="frontend.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
<param name="Name" value="Algorithms">
<param name="Local" value="algorithms.html">
</OBJECT>
Modified: trunk/doc/help/scstudio.hhp
===================================================================
--- trunk/doc/help/scstudio.hhp 2010-03-09 22:53:38 UTC (rev 676)
+++ trunk/doc/help/scstudio.hhp 2010-03-09 22:55:43 UTC (rev 677)
@@ -2,9 +2,9 @@
Compatibility=1.1 or later
Compiled file=scstudio.chm
Contents file=scstudio.hhc
-Default topic=algorithms.html
+Default topic=frontend.html
Display compile progress=No
-Language=0x409 Angli\xE8tina (Spojen\xE9 st\xE1ty)
+Language=0x409 Anglictina (Spojene staty)
Title=Sequence Chart Studio
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ob...@us...> - 2010-03-10 09:40:00
|
Revision: 679
http://scstudio.svn.sourceforge.net/scstudio/?rev=679&view=rev
Author: obouda
Date: 2010-03-10 09:39:54 +0000 (Wed, 10 Mar 2010)
Log Message:
-----------
Addition to r677 - help files actually added
Added Paths:
-----------
trunk/doc/help/frontend.html
trunk/doc/help/pictures/
trunk/doc/help/pictures/frontend.png
trunk/doc/help/pictures/icon_select_add_instances.png
trunk/doc/help/pictures/icon_select_add_messages.png
trunk/doc/help/pictures/icon_select_instances.png
trunk/doc/help/pictures/icon_select_messages.png
Added: trunk/doc/help/frontend.html
===================================================================
--- trunk/doc/help/frontend.html (rev 0)
+++ trunk/doc/help/frontend.html 2010-03-10 09:39:54 UTC (rev 679)
@@ -0,0 +1,37 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html>
+<head>
+<title>SCStudio frontend</title>
+<link href="help.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<h1>Frontend</h1>
+<p>Currently, the SCStudio frontend is accessible as a Microsoft Visio addon.
+Thus, Microsoft Visio 2003 or 2007 must be installed prior to installing
+SCStudio.</p>
+<p>When an MSC document is opened, the Sequence Chart Studio toolbar and menu Check
+are available:</p>
+<img class="big" src="pictures/frontend.png" alt="SCStudio toolbar and menu in MS Visio">
+
+<p>The first toolbar button
+<img src="pictures/icon_select_instances.png" alt="Select instances button">
+selects all instances in the current page of active document. The second button
+<img src="pictures/icon_select_messages.png" alt="Select messages button">
+selects all messages in the current page of active document. These functions are
+also available via menu
+<code>Check → Drawing → Select → All Instances</code>, or
+<code>All Messages</code>, respectively. Keyboard shortcuts are assigned to
+these functions, too: <code>Ctrl+Alt+I</code> for selecting all instances and
+<code>Ctrl+Alt+M</code> for selecting all messages.</p>
+<p>While holding <code>Ctrl</code> or <code>Shift</code>, the first two buttons
+alter their face and functionality, however:
+<img src="pictures/icon_select_add_instances.png" alt="Add instances to selection button">
+<img src="pictures/icon_select_add_messages.png" alt="Add messages to selection button">
+In that case, they <em>add</em> all
+instances (or messages) to the current selection instead of making a new
+selection.</p>
+
+
+
+</body>
+</html>
Added: trunk/doc/help/pictures/frontend.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/pictures/frontend.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/pictures/icon_select_add_instances.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/pictures/icon_select_add_instances.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/pictures/icon_select_add_messages.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/pictures/icon_select_add_messages.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/pictures/icon_select_instances.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/pictures/icon_select_instances.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/pictures/icon_select_messages.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/pictures/icon_select_messages.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ob...@us...> - 2010-04-25 14:42:32
|
Revision: 724
http://scstudio.svn.sourceforge.net/scstudio/?rev=724&view=rev
Author: obouda
Date: 2010-04-25 14:42:25 +0000 (Sun, 25 Apr 2010)
Log Message:
-----------
Reorganized Frontend help
Modified Paths:
--------------
trunk/doc/help/frontend.html
trunk/doc/help/help.css
trunk/doc/help/scstudio.hhc
Added Paths:
-----------
trunk/doc/help/frontend/
trunk/doc/help/frontend/automatic-drawing.html
trunk/doc/help/frontend/pictures/
trunk/doc/help/frontend/pictures/add_instances_options.png
trunk/doc/help/frontend/pictures/frontend.png
trunk/doc/help/frontend/pictures/icon_select_add_instances.png
trunk/doc/help/frontend/pictures/icon_select_add_messages.png
trunk/doc/help/frontend/pictures/icon_select_instances.png
trunk/doc/help/frontend/pictures/icon_select_messages.png
trunk/doc/help/frontend/shape-selection.html
trunk/doc/help/frontend/shortcuts.html
Removed Paths:
-------------
trunk/doc/help/pictures/
Added: trunk/doc/help/frontend/automatic-drawing.html
===================================================================
--- trunk/doc/help/frontend/automatic-drawing.html (rev 0)
+++ trunk/doc/help/frontend/automatic-drawing.html 2010-04-25 14:42:25 UTC (rev 724)
@@ -0,0 +1,38 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html>
+<head>
+<title>Automatic Drawing – SCStudio frontend</title>
+<link href="../help.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<h1>Automatic drawing</h1>
+<p>With all required shapes available in the BMSC and HMSC stencils, it is possible
+to draw virtually any MSC diagram. In practice, there are many stereotypes, however.
+SCStudio helps the user draw some frequently used patterns by several automatic
+drawing functions.</p>
+
+<h2 id="add_instances">Add Instances</h2>
+<p>The first of them is the <code>Add Instances</code> function accessible via menu
+<code>Check → Drawing → Add Instances</code>, or <code>Ctrl+Alt+F</code>
+keyboard shortcut. It is available in the context (right-click) menu of the document, too.
+The function draws a given number of instances on the active
+page of the document, with constant or dynamic space between each two of them.</p>
+<p>When invoked, the following dialog appears:</p>
+<img class="big" src="pictures/add_instances_options.png" alt="Add Instances options dialog">
+<p>The first two fields set the number of instances to be drawn and their length.
+Next two fields set the starting point from which to start drawing. If the cursor
+was in the document drawing area in the time of Add Instances invocation (that is,
+the keyboard shortcut or context-menu was used), the start position fields are
+filled with the cursor position, i.e. drawing will start from the point where
+the cursor was.</p>
+<p>In the Options panel, if the Total width switch is chosen, all the instances
+will be drawn in the place of a width given, so the gaps between instances will be
+calculated to fit this area. On the contrary, the Spacing switch sets constant gaps
+between the instances not limiting the total width.</p>
+<p>All numbers in the dialog are in units of the current page of the document.</p>
+
+<h2 id="message_sequence">Message Sequence</h2>
+<p><i>Under development…</i></p>
+
+</body>
+</html>
Copied: trunk/doc/help/frontend/pictures/add_instances_options.png (from rev 723, trunk/doc/help/pictures/add_instances_options.png)
===================================================================
(Binary files differ)
Copied: trunk/doc/help/frontend/pictures/frontend.png (from rev 723, trunk/doc/help/pictures/frontend.png)
===================================================================
(Binary files differ)
Copied: trunk/doc/help/frontend/pictures/icon_select_add_instances.png (from rev 723, trunk/doc/help/pictures/icon_select_add_instances.png)
===================================================================
(Binary files differ)
Copied: trunk/doc/help/frontend/pictures/icon_select_add_messages.png (from rev 723, trunk/doc/help/pictures/icon_select_add_messages.png)
===================================================================
(Binary files differ)
Copied: trunk/doc/help/frontend/pictures/icon_select_instances.png (from rev 723, trunk/doc/help/pictures/icon_select_instances.png)
===================================================================
(Binary files differ)
Copied: trunk/doc/help/frontend/pictures/icon_select_messages.png (from rev 723, trunk/doc/help/pictures/icon_select_messages.png)
===================================================================
(Binary files differ)
Added: trunk/doc/help/frontend/shape-selection.html
===================================================================
--- trunk/doc/help/frontend/shape-selection.html (rev 0)
+++ trunk/doc/help/frontend/shape-selection.html 2010-04-25 14:42:25 UTC (rev 724)
@@ -0,0 +1,30 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html>
+<head>
+<title>Shape Selection – SCStudio frontend</title>
+<link href="../help.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<h1>Shape Selection</h1>
+<p>On top of standard Visio functions for selecting shapes (such as <code>Ctrl+A</code>
+shortcut for selecting all shapes), SCStudio offers several useful selection functions.</p>
+<p>The first toolbar button
+<img src="pictures/icon_select_instances.png" alt="Select instances button">
+selects all instances in the current page of active document. The second button
+<img src="pictures/icon_select_messages.png" alt="Select messages button">
+selects all messages in the current page of active document. These functions are
+also available via menu
+<code>Check → Drawing → Select → All Instances</code>, or
+<code>All Messages</code>, respectively. Keyboard shortcuts are assigned to
+these functions, too: <code>Ctrl+Alt+I</code> for selecting all instances and
+<code>Ctrl+Alt+M</code> for selecting all messages.</p>
+<p>While holding <code>Ctrl</code> or <code>Shift</code>, the first two buttons
+alter their face and functionality, however:
+<img src="pictures/icon_select_add_instances.png" alt="Add instances to selection button">
+<img src="pictures/icon_select_add_messages.png" alt="Add messages to selection button">
+In that case, they <em>add</em> all
+instances (or messages) to the current selection instead of making a new
+selection.</p>
+
+</body>
+</html>
Added: trunk/doc/help/frontend/shortcuts.html
===================================================================
--- trunk/doc/help/frontend/shortcuts.html (rev 0)
+++ trunk/doc/help/frontend/shortcuts.html 2010-04-25 14:42:25 UTC (rev 724)
@@ -0,0 +1,19 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html>
+<head>
+<title>SCStudio Visio addon keyboard accelerators</title>
+<link href="../help.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<h1>Visio addon keyboard accelerators</h1>
+<p>The following keyboard accelerators are defined by SCStudio Visio addon:</p>
+<table>
+<col width="100"> <col>
+<tr><td><code>Ctrl+Alt+I</code></td><td><a href="shape-selection.html">Select all instances</a></td></tr>
+<tr><td><code>Ctrl+Alt+M</code></td><td><a href="shape-selection.html">Select all message</a></td></tr>
+<tr><td><code>Ctrl+Alt+F</code></td><td><a href="automatic-drawing.html#add_instances">Add instances</a></td></tr>
+<tr><td><code>Ctrl+Alt+S</code></td><td><a href="automatic-drawing.html#message_sequence">Message sequence</a></td></tr>
+</table>
+
+</body>
+</html>
Modified: trunk/doc/help/frontend.html
===================================================================
--- trunk/doc/help/frontend.html 2010-04-23 23:57:59 UTC (rev 723)
+++ trunk/doc/help/frontend.html 2010-04-25 14:42:25 UTC (rev 724)
@@ -11,59 +11,17 @@
SCStudio.</p>
<p>When an MSC document is opened, the Sequence Chart Studio toolbar and menu Check
are available:</p>
-<img class="big" src="pictures/frontend.png" alt="SCStudio toolbar and menu in MS Visio">
+<img class="big" src="frontend/pictures/frontend.png" alt="SCStudio toolbar and menu in MS Visio">
-<h2>Shape Selection</h2>
-<p>On top of standard Visio functions for selecting shapes (such as <code>Ctrl+A</code>
-shortcut for selecting all shapes), SCStudio offers several useful selection functions.</p>
-<p>The first toolbar button
-<img src="pictures/icon_select_instances.png" alt="Select instances button">
-selects all instances in the current page of active document. The second button
-<img src="pictures/icon_select_messages.png" alt="Select messages button">
-selects all messages in the current page of active document. These functions are
-also available via menu
-<code>Check → Drawing → Select → All Instances</code>, or
-<code>All Messages</code>, respectively. Keyboard shortcuts are assigned to
-these functions, too: <code>Ctrl+Alt+I</code> for selecting all instances and
-<code>Ctrl+Alt+M</code> for selecting all messages.</p>
-<p>While holding <code>Ctrl</code> or <code>Shift</code>, the first two buttons
-alter their face and functionality, however:
-<img src="pictures/icon_select_add_instances.png" alt="Add instances to selection button">
-<img src="pictures/icon_select_add_messages.png" alt="Add messages to selection button">
-In that case, they <em>add</em> all
-instances (or messages) to the current selection instead of making a new
-selection.</p>
+<p>SCStudio functions extending Visio are divided into the following categories:</p>
+<ul>
+<li><a href="frontend/shape-selection.html">Shape selection</a></li>
+<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
+</ul>
+<p>Many SCStudio functions define their own keyboard accelerators.
+See the <a href="frontend/shortcuts.html">Keyboard accelerators</a> section to
+list all of them.</p>
-<h2>Automatic drawing</h2>
-<p>With all required shapes available in the BMSC and HMSC stencils, it is possible
-to draw virtually any MSC diagram. In practice, there are many stereotypes, however.
-SCStudio helps the user draw some frequently used patterns by several automatic
-drawing functions.</p>
-
-<h3>Add Instances</h3>
-<p>The first of them is the <code>Add Instances</code> function accessible via menu
-<code>Check → Drawing → Add Instances</code>, or <code>Ctrl+Alt+F</code>
-keyboard shortcut. It is available in the context (right-click) menu of the document, too.
-The function draws a given number of instances on the active
-page of the document, with constant or dynamic space between each two of them.</p>
-<p>When invoked, the following dialog appears:</p>
-<img class="big" src="pictures/add_instances_options.png" alt="Add Instances options dialog">
-<p>The first two fields set the number of instances to be drawn and their length.
-Next two fields set the starting point from which to start drawing. If the cursor
-was in the document drawing area in the time of Add Instances invocation (that is,
-the keyboard shortcut or context-menu was used), the start position fields are
-filled with the cursor position, i.e. drawing will start from the point where
-the cursor was.</p>
-<p>In the Options panel, if the Total width switch is chosen, all the instances
-will be drawn in the place of a width given, so the gaps between instances will be
-calculated to fit this area. On the contrary, the Spacing switch sets constant gaps
-between the instances not limiting the total width.</p>
-<p>All numbers in the dialog are in units of the current page of the document.</p>
-
-<h3>Message Sequence</h3>
-<p><i>Under development…</i></p>
-
-
</body>
</html>
Modified: trunk/doc/help/help.css
===================================================================
--- trunk/doc/help/help.css 2010-04-23 23:57:59 UTC (rev 723)
+++ trunk/doc/help/help.css 2010-04-25 14:42:25 UTC (rev 724)
@@ -25,4 +25,7 @@
code {
font-size: 1.2em;
}
+table {
+ font-size: 1em;
+}
Modified: trunk/doc/help/scstudio.hhc
===================================================================
--- trunk/doc/help/scstudio.hhc 2010-04-23 23:57:59 UTC (rev 723)
+++ trunk/doc/help/scstudio.hhc 2010-04-25 14:42:25 UTC (rev 724)
@@ -12,6 +12,20 @@
<param name="Name" value="Frontend">
<param name="Local" value="frontend.html">
</OBJECT>
+ <UL>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Shape selection">
+ <param name="Local" value="frontend\shape-selection.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Automatic drawing">
+ <param name="Local" value="frontend\automatic-drawing.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Keyboard accelerators">
+ <param name="Local" value="frontend\shortcuts.html">
+ </OBJECT>
+ </UL>
<LI> <OBJECT type="text/sitemap">
<param name="Name" value="Algorithms">
<param name="Local" value="algorithms.html">
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <xr...@us...> - 2010-05-17 16:24:16
|
Revision: 791
http://scstudio.svn.sourceforge.net/scstudio/?rev=791&view=rev
Author: xrehak
Date: 2010-05-17 16:24:07 +0000 (Mon, 17 May 2010)
Log Message:
-----------
Typos.
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/livelock/livelock.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/race/race.html
trunk/doc/help/realizability/realizability.html
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/acyclic/acyclic.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -8,10 +8,10 @@
</HEAD>
<BODY>
<H1>Acyclic property</H1>
-<P> Acyclic property ensures that there is no cyclic dependency among events in a MSC. Such an dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such MSC design can be seen on the following figure:</P>
+<P> Acyclic property ensures that there is no cyclic dependency among events in an MSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such MSC design can be seen in the following figure:</P>
<IMG SRC="pictures/cyclic_simple.png" BORDER="0" ALT="Cyclic MSC" TITLE="Cyclic MSC">
<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
-<P> Result of SCStudio on such design highlights the cyclic dependency:</P>
+<P> SCStudio highlights the cyclic dependency:</P>
<IMG SRC="pictures/cyclic_result.png" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
<P> A more tricky example of an acyclic design:</P>
<IMG SRC="pictures/acyclic.png" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/boundedness/boundedness.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded comuunication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
+<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
</BODY>
Modified: trunk/doc/help/livelock/livelock.html
===================================================================
--- trunk/doc/help/livelock/livelock.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/livelock/livelock.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -10,5 +10,5 @@
<H1>Livelock</H1>
<P>is a property of an HMSC. An HMSC contains a livelock if there exists a cycle of nodes from which no endnode is reachable. It is required that the cycle contains at least one reference node.</P>
-<P>SCStudio finds and displays all such cycles is a given HMSC.</P>
+<P>SCStudio finds and displays all such cycles in a given HMSC.</P>
</BODY>
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/localchoice/localchoice.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -28,7 +28,7 @@
<P>More formally, a branching node is called a non-local choice if one of the conditions is satisfied:</P>
<UL>
<LI> There exists a branch that is initiated by more than one instance.</LI>
-<LI> There exist two branches, such that each is initiated by different instance</LI>
+<LI> There exist two branches, such that each is initiated by different instance</LI>.
</UL>
<P>The result of the check on the previous example marks the non-local choice node by red:</P>
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/race/race.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -8,6 +8,6 @@
</HEAD>
<BODY>
<H1>Race Condition</H1>
-<P>occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with FIFO; race condition is only applicable for MSCs that satisfy FIFO.</P>
-<P>SCStudio currently finds all such pairs of events is a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
+<P>Race Condition occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with FIFO; race condition is only applicable for MSCs that satisfy FIFO.</P>
+<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
</BODY>
Modified: trunk/doc/help/realizability/realizability.html
===================================================================
--- trunk/doc/help/realizability/realizability.html 2010-05-17 10:25:19 UTC (rev 790)
+++ trunk/doc/help/realizability/realizability.html 2010-05-17 16:24:07 UTC (rev 791)
@@ -8,6 +8,6 @@
</HEAD>
<BODY>
<H1>Strong realizability</H1>
-<P>is a property of an HMSC. An HMSC is strongly realizable iff it is univerally bounded and local-choice.</P>
+<P>is a property of an HMSC. An HMSC is strongly realizable iff it is universally bounded and local-choice.</P>
</BODY>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <xp...@us...> - 2010-05-21 22:43:41
|
Revision: 801
http://scstudio.svn.sourceforge.net/scstudio/?rev=801&view=rev
Author: xpekarc
Date: 2010-05-21 22:43:35 +0000 (Fri, 21 May 2010)
Log Message:
-----------
adding help for beautify
Added Paths:
-----------
trunk/doc/help/beautify/
trunk/doc/help/beautify/beautify.html
trunk/doc/help/beautify/coregion1.PNG
trunk/doc/help/beautify/coregion2.PNG
trunk/doc/help/beautify/ordered.PNG
trunk/doc/help/beautify/unfifo2.PNG
trunk/doc/help/beautify/unordered.PNG
Added: trunk/doc/help/beautify/beautify.html
===================================================================
--- trunk/doc/help/beautify/beautify.html (rev 0)
+++ trunk/doc/help/beautify/beautify.html 2010-05-21 22:43:35 UTC (rev 801)
@@ -0,0 +1,35 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <TITLE>Beautify documentation</TITLE>
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<h2>Beautify</h2>
+<P>The main aim of this function is to redraw BMSC to be well-arranged. It is accessible via menu <code>Check →
+Drawing → Beautify</code>. </P>
+<P>It changes order of instances to minimize a number of
+messages going form right side to left side and crossing instances with messages. Instances are justified to top and have
+the same langth. For fifo and uncyclic BMSC it makes all messages
+horizontal and arranged over instances uniformly form top to down. </P>
+<P>Before:</P>
+<img src="unordered.png" alt="Unordered BMSC">
+<P>After:</P>
+<img src="ordered.png" alt="Ordered BMSC">
+
+<P>Un-fifo BMSC is redrawn to a form that no messages are going up.</P>
+<img src="unfifo2.png" alt="">
+
+<P> For coregions it changes the order of events
+to minimize number of crossing two messages. After redrawing messages are jointed with coregion in such way that they do
+not go across coregion body. <BR></P>
+
+
+
+<P>Before:</P>
+<img src="coregion1.png" alt="Crossing messages jointed with coregion">
+<P>After:</P>
+<img src="coregion2.png" alt="">
+
+</BODY>
+</HTML>
\ No newline at end of file
Added: trunk/doc/help/beautify/coregion1.PNG
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/coregion1.PNG
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/coregion2.PNG
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/coregion2.PNG
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/ordered.PNG
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/ordered.PNG
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/unfifo2.PNG
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/unfifo2.PNG
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/unordered.PNG
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/unordered.PNG
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <va...@us...> - 2010-05-22 20:32:25
|
Revision: 803
http://scstudio.svn.sourceforge.net/scstudio/?rev=803&view=rev
Author: vacek
Date: 2010-05-22 20:32:19 +0000 (Sat, 22 May 2010)
Log Message:
-----------
Help improvements
Modified Paths:
--------------
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/livelock/livelock.html
trunk/doc/help/race/race.html
trunk/doc/help/realizability/realizability.html
Added Paths:
-----------
trunk/doc/help/boundedness/unbounded.png
trunk/doc/help/deadlock/deadlock.png
trunk/doc/help/livelock/livelock.png
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-05-22 10:32:29 UTC (rev 802)
+++ trunk/doc/help/boundedness/boundedness.html 2010-05-22 20:32:19 UTC (rev 803)
@@ -11,4 +11,7 @@
<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
+
+<p>
+<img src="unbounded.png" alt="Unbounded HMSC">
</BODY>
Added: trunk/doc/help/boundedness/unbounded.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/boundedness/unbounded.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-05-22 10:32:29 UTC (rev 802)
+++ trunk/doc/help/deadlock/deadlock.html 2010-05-22 20:32:19 UTC (rev 803)
@@ -14,4 +14,7 @@
SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is available.
</P>
+<p>
+<img src="deadlock.png" alt="Typical deadlock">
+
</BODY>
Added: trunk/doc/help/deadlock/deadlock.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/deadlock/deadlock.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/livelock/livelock.html
===================================================================
--- trunk/doc/help/livelock/livelock.html 2010-05-22 10:32:29 UTC (rev 802)
+++ trunk/doc/help/livelock/livelock.html 2010-05-22 20:32:19 UTC (rev 803)
@@ -11,4 +11,6 @@
<P>is a property of an HMSC. An HMSC contains a livelock if there exists a cycle of nodes from which no endnode is reachable. It is required that the cycle contains at least one reference node.</P>
<P>SCStudio finds and displays all such cycles in a given HMSC.</P>
+
+<P><img src="livelock.png" alt="Typical livelock"></P>
</BODY>
Added: trunk/doc/help/livelock/livelock.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/livelock/livelock.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-05-22 10:32:29 UTC (rev 802)
+++ trunk/doc/help/race/race.html 2010-05-22 20:32:19 UTC (rev 803)
@@ -8,6 +8,6 @@
</HEAD>
<BODY>
<H1>Race Condition</H1>
-<P>Race Condition occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with FIFO; race condition is only applicable for MSCs that satisfy FIFO.</P>
+<P>Race Condition occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for MSCs that satisfy FIFO.</P>
<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
</BODY>
Modified: trunk/doc/help/realizability/realizability.html
===================================================================
--- trunk/doc/help/realizability/realizability.html 2010-05-22 10:32:29 UTC (rev 802)
+++ trunk/doc/help/realizability/realizability.html 2010-05-22 20:32:19 UTC (rev 803)
@@ -8,6 +8,6 @@
</HEAD>
<BODY>
<H1>Strong realizability</H1>
-<P>is a property of an HMSC. An HMSC is strongly realizable iff it is universally bounded and local-choice.</P>
+<P>is a property of an HMSC. An HMSC is strongly realizable iff it is <a href="../boundedness/boundedness.html">universally bounded</a> and <a href="../locaLchoice/localchoice.html">local-choice</a>.</P>
</BODY>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-05-23 15:30:42
|
Revision: 805
http://scstudio.svn.sourceforge.net/scstudio/?rev=805&view=rev
Author: lkorenciak
Date: 2010-05-23 15:30:36 +0000 (Sun, 23 May 2010)
Log Message:
-----------
added help files
Modified Paths:
--------------
trunk/doc/help/membership/membership.html
Added Paths:
-----------
trunk/doc/help/time_consistency/
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/membership/membership.html
===================================================================
--- trunk/doc/help/membership/membership.html 2010-05-22 20:53:18 UTC (rev 804)
+++ trunk/doc/help/membership/membership.html 2010-05-23 15:30:36 UTC (rev 805)
@@ -7,7 +7,7 @@
</HEAD>
<BODY LANG="en-US" DIR="LTR" STYLE="border: none; padding: 0in">
<h1>Membership</FONT></h1>
-<P >The problematic of
+<P >The problem of
membership is deciding whether given bMSC is contained in given HMSC.
It is possible to check both untimed and timed cases of bMSCs and
HMSCs.<BR></P>
Added: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html (rev 0)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-05-23 15:30:36 UTC (rev 805)
@@ -0,0 +1,28 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Time Consistency</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Time Consistency</H1>
+<P>Time consistency is problem of deciding whether introduced time constraints in MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
+<p> The motivation for time consitency is following. It can easily happen that user can sapecify too restrictive time constraint and cause that the set of executions which satisfy MSC is empty. The time consistency property checks such situations.
+<H2>Basic Message Sequence Chart</H2>
+<P>Time consistent property is violated for BMSC B when there is no time assignment for B.</P>
+<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
+<P>An example of time inconsistent BMSC is depicted on the next picture.</P>
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+
+<H2>High-level MSC</H2>
+
+<P>HMSC violates time consistent property if exists path from start node to end node for which there is no time assignment.</P>
+<P>An example of time inconsistent HMSC is depicted on the next picture.</P>
+<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+
+
+</BODY>
+</HTML>
Added: trunk/doc/help/time_syntax/time_syntax.html
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html (rev 0)
+++ trunk/doc/help/time_syntax/time_syntax.html 2010-05-23 15:30:36 UTC (rev 805)
@@ -0,0 +1,30 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Correct Time Constraint Syntax</TITLE>
+ <meta name="author" content="Lubos Korenciak">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Correct Time Constraint Syntax</H1>
+<P>The correct time constraint syntax algorithm is used for checking whether introduced time constraints are correct to use in SCStudio. The main motivation for such test is to rule out time constraints which are either not allowed by standard or ambiguous.
+</P>
+<P>The following conditions must hold for every time constraint to suffice correct time constraint algorithm:
+<ul>
+<li>if the constraint is in BMSC it has to restrict events which are visually ordered </li>
+<li>if the constraint is in HMSC and it restricts nodes A and B, every path going through A must go through B (and other way around) and it cannot go twice through A (B) without going through node B (A) in between.</li>
+</ul> </p>
+
+<P>An example of a time constraint can be seen on the next picture. Receive events of HTTP Response and HTTP request messages are not visually ordered. Thus the time constraint does not satisfy the Correct Time Constraint Syntax property. </P>
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a wrong time constraint" title="Example of a non-fifo design">
+
+<P>On the next picture we see that there exists path which goes twice through node Connection denied and thus the introduced time constraint also does not satisfy Correct Time Constraint Syntax property.</P>
+
+<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+
+<P>The last example depicts HMSC where exist path which goes through node A of but does not go through node B. Since there is introduced time constraint restricting these nodes it violates Correct Time Constraint Syntax property.</P>
+<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+
+</BODY>
+</HTML>
Added: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html (rev 0)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-05-23 15:30:36 UTC (rev 805)
@@ -0,0 +1,28 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Tighten Time</TITLE>
+ <meta name="author" content="Lubos Korenciak">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Tighten Time</H1>
+<P>The purpose of tighten time algorithm is to shorten interval sets of time constraints to minimal possible values. It deletes the values of time constraints which cannot be used due to other more restrictive time constraints.
+</P>
+<H3> Basic MSC</H3>
+<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
+<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
+
+<P>An example of a tighten time algorithm on BMSC:</P>
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+
+
+<H3> High-level MSC</H3>
+<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment for some path from the start node to the end node.</p>
+<P>An example of tighten time algorithm on HMSC:</P>
+
+<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+</BODY>
+</HTML>
Added: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html (rev 0)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-05-23 15:30:36 UTC (rev 805)
@@ -0,0 +1,24 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Time Race</TITLE>
+ <meta name="author" content="Lubos Korenciak">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Time Race</H1>
+
+<P> Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in inverse order.</P>
+<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a race between HTTP Request and HTTP Response receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+
+<P>BMSC B (or HMSC path p) contains time race if there are two visually ordered events in B (or p), but there exists time assignment which assigns visually preceding event larger time value than the value assigned to subsequent event.</P>
+<P>HMSC contains time race if there exists path which contains time race. </P>
+<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
+<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
+<P>The next example shows HMSC which contains race condition, but which is time race free.</P>
+<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+
+</BODY>
+</HTML>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-05-23 16:25:06
|
Revision: 807
http://scstudio.svn.sourceforge.net/scstudio/?rev=807&view=rev
Author: lkorenciak
Date: 2010-05-23 16:24:59 +0000 (Sun, 23 May 2010)
Log Message:
-----------
added new help files
Added Paths:
-----------
trunk/doc/help/time_consistency/pictures/
trunk/doc/help/time_consistency/pictures/cons1.jpg
trunk/doc/help/time_consistency/pictures/cons1.vsd
trunk/doc/help/time_consistency/pictures/cons2.jpg
trunk/doc/help/time_syntax/pictures/
trunk/doc/help/time_syntax/pictures/syntax1.jpg
trunk/doc/help/time_syntax/pictures/syntax1.vsd
trunk/doc/help/time_syntax/pictures/syntax2.jpg
trunk/doc/help/time_syntax/pictures/syntax3.jpg
trunk/doc/help/time_tighten/pictures/
trunk/doc/help/time_tighten/pictures/tighten1.vsd
trunk/doc/help/time_tighten/pictures/tighten1_1.jpg
trunk/doc/help/time_tighten/pictures/tighten1_2.jpg
trunk/doc/help/time_tighten/pictures/tighten1_3.jpg
trunk/doc/help/time_tighten/pictures/tighten1_5.jpg
trunk/doc/help/time_tighten/pictures/tighten1_6.jpg
trunk/doc/help/time_tighten/pictures/tighten1_7.jpg
trunk/doc/help/time_tighten/pictures/tighten2.vsd
trunk/doc/help/time_tighten/pictures/tighten2_1.jpg
trunk/doc/help/time_tighten/pictures/tighten2_2.jpg
trunk/doc/help/time_trace_race/pictures/
trunk/doc/help/time_trace_race/pictures/race1.vsd
trunk/doc/help/time_trace_race/pictures/race1_1.jpg
trunk/doc/help/time_trace_race/pictures/race1_2.jpg
trunk/doc/help/time_trace_race/pictures/race2_1.jpg
trunk/doc/help/time_trace_race/pictures/race2_2.jpg
trunk/doc/help/time_trace_race/pictures/race2_3.jpg
Added: trunk/doc/help/time_consistency/pictures/cons1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_consistency/pictures/cons1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_consistency/pictures/cons1.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_consistency/pictures/cons1.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_consistency/pictures/cons2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_consistency/pictures/cons2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax1.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax1.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax3.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax3.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_3.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_3.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_5.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_5.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_6.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_6.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_7.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_7.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten2.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten2.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten2_1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten2_1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten2_2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten2_2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race1.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race1.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race1_1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race1_1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race1_2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race1_2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_1.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_1.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_2.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_2.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_3.jpg
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_3.jpg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-05-23 19:43:20
|
Revision: 809
http://scstudio.svn.sourceforge.net/scstudio/?rev=809&view=rev
Author: lkorenciak
Date: 2010-05-23 19:43:14 +0000 (Sun, 23 May 2010)
Log Message:
-----------
added new files for help
Added Paths:
-----------
trunk/doc/help/time_consistency/pictures/cons1.png
trunk/doc/help/time_consistency/pictures/cons2.png
trunk/doc/help/time_syntax/pictures/syntax1.png
trunk/doc/help/time_syntax/pictures/syntax2.png
trunk/doc/help/time_syntax/pictures/syntax3.png
trunk/doc/help/time_tighten/pictures/tighten1_1.png
trunk/doc/help/time_tighten/pictures/tighten1_2.png
trunk/doc/help/time_tighten/pictures/tighten1_3.png
trunk/doc/help/time_tighten/pictures/tighten1_4.png
trunk/doc/help/time_tighten/pictures/tighten1_5.png
trunk/doc/help/time_tighten/pictures/tighten1_6.png
trunk/doc/help/time_tighten/pictures/tighten2_1.png
trunk/doc/help/time_tighten/pictures/tighten2_2.png
trunk/doc/help/time_trace_race/pictures/race1_1.png
trunk/doc/help/time_trace_race/pictures/race1_2.png
trunk/doc/help/time_trace_race/pictures/race2_1.png
trunk/doc/help/time_trace_race/pictures/race2_2.png
trunk/doc/help/time_trace_race/pictures/race2_3.png
Added: trunk/doc/help/time_consistency/pictures/cons1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_consistency/pictures/cons1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_consistency/pictures/cons2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_consistency/pictures/cons2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_syntax/pictures/syntax3.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_syntax/pictures/syntax3.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_3.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_3.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_4.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_4.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_5.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_5.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten1_6.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten1_6.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten2_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten2_1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_tighten/pictures/tighten2_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_tighten/pictures/tighten2_2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race1_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race1_1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race1_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race1_2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_1.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_2.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/time_trace_race/pictures/race2_3.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/time_trace_race/pictures/race2_3.png
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-05-23 20:46:14
|
Revision: 810
http://scstudio.svn.sourceforge.net/scstudio/?rev=810&view=rev
Author: lkorenciak
Date: 2010-05-23 20:46:08 +0000 (Sun, 23 May 2010)
Log Message:
-----------
added help sections for: Correct time constraint syntax, Time Consistency, Time Race and Tighten Time
Modified Paths:
--------------
trunk/doc/help/algorithms.html
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-05-23 19:43:14 UTC (rev 809)
+++ trunk/doc/help/algorithms.html 2010-05-23 20:46:08 UTC (rev 810)
@@ -7,14 +7,18 @@
The following verification algorithms are supported:
<ul>
<li><a href="acyclic/acyclic.html">Acyclic property</a></li>
+<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
+<li><a href="deadlock/deadlock.html">Deadlock</a></li>
<li><a href="fifo/fifo.html">FIFO property</a></li>
+<li><a href="livelock/livelock.html">Livelock</a></li>
+<li><a href="membership/membership.html">Membership</a></li>
<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
-<li><a href="membership/membership.html">Membership</a></li>
<li><a href="race/race.html">Race Condition</a></li>
-<li><a href="livelock/livelock.html">Livelock</a></li>
-<li><a href="deadlock/deadlock.html">Deadlock</a></li>
+<li><a href="realizability/realizability.html">Strong Realizablilty</a></li>
+<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
+<li><a href="time_trace_race/time_race.html">Time Race</a></li>
+<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
-<li><a href="realizability/realizability.html">Strong Realizablilty</a></li>
</ul>
</body>
</html>
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-05-23 19:43:14 UTC (rev 809)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-05-23 20:46:08 UTC (rev 810)
@@ -14,14 +14,13 @@
<P>Time consistent property is violated for BMSC B when there is no time assignment for B.</P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
<P>An example of time inconsistent BMSC is depicted on the next picture.</P>
-<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+<img src="pictures/cons1.png" border="0" alt="Time inconsistent BMSC" title="Time inconsistent BMSC">
<H2>High-level MSC</H2>
<P>HMSC violates time consistent property if exists path from start node to end node for which there is no time assignment.</P>
<P>An example of time inconsistent HMSC is depicted on the next picture.</P>
-<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/cons2.png" border="0" alt="Time inconsistent HMSC" title="Time inconsistent HMSC">
</BODY>
Modified: trunk/doc/help/time_syntax/time_syntax.html
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html 2010-05-23 19:43:14 UTC (rev 809)
+++ trunk/doc/help/time_syntax/time_syntax.html 2010-05-23 20:46:08 UTC (rev 810)
@@ -17,14 +17,13 @@
</ul> </p>
<P>An example of a time constraint can be seen on the next picture. Receive events of HTTP Response and HTTP request messages are not visually ordered. Thus the time constraint does not satisfy the Correct Time Constraint Syntax property. </P>
-<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a wrong time constraint" title="Example of a non-fifo design">
+<img src="pictures/syntax3.png" border="0" alt="Example of a wrong time constraint" title="Example of a wrong BMSC time constraint">
-<P>On the next picture we see that there exists path which goes twice through node Connection denied and thus the introduced time constraint also does not satisfy Correct Time Constraint Syntax property.</P>
+<P>On the next picture we see that there exist path which goes twice in a row through the node Connection denied and thus the introduced time constraint also does not satisfy correct time constraint syntax property.</P>
-<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<img src="pictures/syntax1.png" border="0" alt="Violation of constraint syntax" title="Violation of constraint syntax property">
<P>The last example depicts HMSC where exist path which goes through node A of but does not go through node B. Since there is introduced time constraint restricting these nodes it violates Correct Time Constraint Syntax property.</P>
-<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-
+<img src="pictures/syntax2.png" border="0" alt="Example of a wrong time constraint" title="Example of a wrong HMSC time constraint">
</BODY>
</HTML>
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-05-23 19:43:14 UTC (rev 809)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-05-23 20:46:08 UTC (rev 810)
@@ -14,15 +14,44 @@
<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
-<P>An example of a tighten time algorithm on BMSC:</P>
-<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+<P>An example of the tighten time algorithm on a BMSC:</P>
+<table><caption align="bottom"><i>Original BMSC</i></caption><tr><td>
+<img src="pictures/tighten2_1.png" border="0" alt="Original BMSC" title="Original BMSC">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Tightened BMSC</i></caption><tr><td>
+<img src="pictures/tighten2_2.png" border="0" alt="Tightened BMSC" title="Tightened BMSC">
+</tr></td></table>
+
<H3> High-level MSC</H3>
<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment for some path from the start node to the end node.</p>
-<P>An example of tighten time algorithm on HMSC:</P>
+<P>An example of the tighten time algorithm on a HMSC:</P>
-<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
+<table><caption align="bottom"><i>Original HMSC</i></caption><tr><td>
+<img src="pictures/tighten1_1.png" border="0" alt="Original HMSC" title="Original HMSC">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Original BMSC A</i></caption><tr><td>
+<img src="pictures/tighten1_2.png" border="0" alt="Original BMSC A" title="Original BMSC A">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Original HMSC B</i></caption><tr><td>
+<img src="pictures/tighten1_3.png" border="0" alt="Original HMSC B" title="Original BMSC B">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Tightened HMSC</i></caption><tr><td>
+<img src="pictures/tighten1_4.png" border="0" alt="Tightened HMSC" title="Tightened HMSC">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Tightened BMSC A</i></caption><tr><td>
+<img src="pictures/tighten1_5.png" border="0" alt="Tightened BMSC A" title="Tightened BMSC A">
+</tr></td></table>
+
+<table><caption align="bottom"><i>Tightened BMSC B</i></caption><tr><td>
+<img src="pictures/tighten1_6.png" border="0" alt="Tightened BMSC B" title="Tightened BMSC B">
+</tr></td></table>
+
</BODY>
</HTML>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-05-23 19:43:14 UTC (rev 809)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-05-23 20:46:08 UTC (rev 810)
@@ -10,15 +10,32 @@
<H1>Time Race</H1>
<P> Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in inverse order.</P>
-<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a race between HTTP Request and HTTP Response receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
-<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a time race between HTTP Request and HTTP Response receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
+<table><caption align="bottom"><i>BMSC with the time race</i></caption><tr><td>
+<img src="pictures/race1_1.png" border="0" alt="BMSC with the time race" title="BMSC with the time race">
+</tr></td></table>
+<table><caption align="bottom"><i>Time race free BMSC</i></caption><tr><td>
+<img src="pictures/race1_2.png" border="0" alt="Time race free BMSC" title="Time race free BMSC">
+</tr></td></table>
+
<P>BMSC B (or HMSC path p) contains time race if there are two visually ordered events in B (or p), but there exists time assignment which assigns visually preceding event larger time value than the value assigned to subsequent event.</P>
<P>HMSC contains time race if there exists path which contains time race. </P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
<P>The next example shows HMSC which contains race condition, but which is time race free.</P>
-<img src="pictures/simple_non_fifo.png" border="0" alt="Example of a non-fifo design" title="Example of a non-fifo design">
+<table><caption align="bottom"><i>BMSC B</i></caption><tr><td>
+<img src="pictures/race2_1.png" border="0" alt="Example of time race free HMSC" title="Example of time race free HMSC">
+</tr></td></table>
+
+<table><caption align="bottom"><i>BMSC A</i></caption><tr><td>
+<img src="pictures/race2_2.png" border="0" alt="BMSC A" title="BMSC A">
+</tr></td></table>
+
+<table><caption align="bottom"><i>BMSC B</i></caption><tr><td>
+<img src="pictures/race2_3.png" border="0" alt="BMSC B" title="BMSC B">
+</tr></td></table>
+
</BODY>
</HTML>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-05-26 22:02:56
|
Revision: 812
http://scstudio.svn.sourceforge.net/scstudio/?rev=812&view=rev
Author: lkorenciak
Date: 2010-05-26 22:02:50 +0000 (Wed, 26 May 2010)
Log Message:
-----------
fixed few mistakes in help, some statements were reformulated
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/membership/membership.html
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/acyclic/acyclic.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -13,6 +13,7 @@
<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
<P> SCStudio highlights the cyclic dependency:</P>
<IMG SRC="pictures/cyclic_result.png" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
-<P> A more tricky example of an acyclic design:</P>
+<P> A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the Instance p which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency.
+</P>
<IMG SRC="pictures/acyclic.png" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
</BODY>
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/deadlock/deadlock.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -1,20 +1,20 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Deadlock</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Deadlock</H1>
-<P>is a property of an HMSC node. An HMSC node is deadlocked if there is no reference node or end node reachable from the node, i.e. after the execution of the MSC referenced by a deadlocked node, there is no node to continue with.</P>
-
-<P>
-SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is available.
-</P>
-
-<p>
-<img src="deadlock.png" alt="Typical deadlock">
-
-</BODY>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Deadlock</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Deadlock</H1>
+<P>is a property of an HMSC node. An HMSC node is deadlocked if there is no reference node or end node reachable from the node, i.e. after the execution of the MSC referenced by a deadlocked node, there is no node to continue with.</P>
+
+<P>
+SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is available/suggested/given as example of the deadlock.
+</P>
+
+<p>
+<img src="deadlock.png" alt="Typical deadlock">
+
+</BODY>
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/fifo/fifo.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -8,10 +8,9 @@
</HEAD>
<BODY>
<H1>FIFO property</H1>
-<P>FIFO (First In, First Out) is a property of an MSC
-and an HMSC specification. The property ensures that it is possible
-to implement the desired behavior without deadlocks that would be
-caused by attributes of channels.</P>
+<P>FIFO (First In, First Out) is a property of an MSC. The property ensures that it is possible
+to implement the desired behavior without deadlocks, that would be
+caused by attributes/behavior of channels.</P>
<H2>Basic Message Sequence Chart</H2>
<H3>FIFO channel for every pair of instances </H3>
<P>FIFO property is violated when there are two
@@ -28,7 +27,7 @@
<P>A more formal definition follows:</P>
<P>BMSC is FIFO if for all receive events c, d and their matching send events
-a, b (a,c form one message and b,d form second message) it holds that
+a, b (a,c form the first message and b,d form the second message) it holds that
c < d => a < b, where < is the visual order and the two messages belong
to the same channel.</P>
<P>Tricky examples of FIFO MSCs:</P>
@@ -36,7 +35,7 @@
<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<P>An example of a non-FIFO design can be seen on the following figure:</P>
+<P>An example of a non-FIFO design can be seen on the following picture:</P>
<img src="pictures/nonfifo1.png" border="0" alt="non-FIFO MSC design" title="non-FIFO MSC design">
<H3>FIFO channel for every pair of instances and labels</H3>
@@ -51,8 +50,8 @@
<H3>One FIFO buffer for all processes</H3>
<P>TODO, wait until implementation is done</P>
<H2>High-level Message Sequence Chart</H2>
-<P>HMSC satisfies FIFO property for certain channel
-type, if every MSC in the HMSC specification satisfies FIFO property
+<P>HMSC satisfies FIFO property for a certain channel
+type, if every BMSC represented/specified by the HMSC satisfies FIFO property
for that channel type:</P>
</BODY>
</HTML>
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/localchoice/localchoice.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -10,15 +10,15 @@
<H1>Non-local choice</H1>
<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches MSC A or MSC B) are possible and the branches are initiated by different instances (MSC A is initiated by instance p, MSC B is initiated by instance q). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
<DIV class="gallery vary">
-<table><caption align="bottom">HMSC</caption><tr><td>
+<table><caption align="bottom"><i>HMSC</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal.png" BORDER="0" ALT="HMSC specification with a branching node" title="HMSC specification with a branching node">
</tr></td></table>
-<table><caption align="bottom">MSC A</caption><tr><td>
+<table><caption align="bottom"><i>MSC A</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal_MSCA.png" BORDER="0" ALT="MSC A" TITLE="MSC A">
</tr></td></table>
-<table><caption align="bottom">MSC B</caption><tr><td>
+<table><caption align="bottom"><i>MSC B</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal_MSCB.png" BORDER="0" ALT="MSC B" TITLE="MSC B">
</tr></td></table>
@@ -30,14 +30,14 @@
<LI> There exists a branch that is initiated by more than one instance.</LI>
<LI> There exist two branches, such that each is initiated by different instance</LI>.
</UL>
-<P>The result of the check on the previous example marks the non-local choice node by red:</P>
+<P>The result of the check on the previous example marks the non-local choice node with the red color:</P>
<DIV class="gallery vary">
-<table><caption align="bottom">Result of SCStudio</caption><tr><td>
+<table><caption align="bottom"><i>Result of SCStudio</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal_result.png" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio">
</tr></td></table>
<DIV class="gallery vary">
-<table><caption align="bottom">Implied behavior</caption><tr><td>
+<table><caption align="bottom"><i>Implied behavior</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal_implied.png" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior">
</tr></td></table>
</BODY>
Modified: trunk/doc/help/membership/membership.html
===================================================================
--- trunk/doc/help/membership/membership.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/membership/membership.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -8,14 +8,14 @@
<BODY LANG="en-US" DIR="LTR" STYLE="border: none; padding: 0in">
<h1>Membership</FONT></h1>
<P >The problem of
-membership is deciding whether given bMSC is contained in given HMSC.
-It is possible to check both untimed and timed cases of bMSCs and
+membership is deciding whether given BMSC is contained in given MSC.
+It is possible to check both untimed and timed cases of BMSCs and
HMSCs.<BR></P>
<P>Example 1:</P>
<DIV class="gallery vary">
-<table><caption align="bottom"><i>Input bMSC</i></caption><tr><td>
+<table><caption align="bottom"><i>Input BMSC</i></caption><tr><td>
<img src="memebership_2.png" border="0" alt="" title="Input bMSC">
</tr></td></table>
@@ -35,35 +35,35 @@
<P >In the figure above we
have specified input to the membership problem. Every path from
-initial node to terminal node in a HMSC represents a bMSC. There is
+initial node to terminal node in a HMSC represents a BMSC. There is
only one path in the <i>Input HMSC</i>. The bMSC specified by the path is
-formed from nodes (bMSCs) on the path by sequential composition
-(putting the bMSCs one after the other and gluing the matching
-process lines). It is easy to see that the <i>Input bMSC</i> is exactly the
+formed from nodes (BMSCs) on the path by sequential composition
+(putting the BMSCs one after the other and gluing the matching
+process lines). It is easy to see that the <i>Input BMSC</i> is exactly the
same bMSC represented by the only path in the <i>Input HMSC</i>. The result of
procedure solving membership problem should be every successful path
i.e. <i>Input HMSC</i>.</P>
<P >More formal
-specification of a procedure:</P>
+specification of the procedure:</P>
<P >Input:
</P>
<UL>
- <LI><P >bMSC with timing
+ <LI><P >BMSC with timing
assignment</P>
- <LI><P >HMSC with timers
- and time interval constraints (both HMSC constraints and bMSC
- constraints)</P>
+ <LI><P >MSC with timers
+ and time constraints (both HMSC constraints and BMSC
+ constraints may be present in an HMSC)</P>
</UL>
<P >Output: graph of nodes
and edges between initial and terminal vertex in the input HMSC
representing the possible paths in the HMSC. The paths, after
-sequential composition, form a set of bMSCs with time constraints.
-The input bMSC satisfies all the time constraints in every one of the
-bMSCs formed by paths from the initial to the terminal vertex.</P>
+sequential composition, form a set of BMSCs with time constraints.
+The input BMSC satisfies all the time constraints in every one of the
+BMSCs formed by paths from the start to the end node.</P>
<P >Example 2:</P>
<DIV class="gallery vary">
-<table><caption align="bottom"><i>Input bMSC</i></caption><tr><td>
+<table><caption align="bottom"><i>Input BMSC</i></caption><tr><td>
<img src="memebership_11.png" border="0" alt="" title="bMSC1">
</tr></td></table>
@@ -97,6 +97,6 @@
</div>
<br clear="all">
-<P >In the result there are only two paths through <i>Input HMSC</i>. This is because only these two paths form bMSCs, which are satisfied by <i>Input bMSC</i>. The path through <i>bMSC4</i> forms bMSC which is not satisfied by <i>Input bMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of cycle through <i>bMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input bMSC</i>.</P>
+<P >In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>bMSC4</i> forms BMSC which is not satisfied by the <i>Input bMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle through <i>bMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
</BODY>
</HTML>
\ No newline at end of file
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -8,12 +8,12 @@
</HEAD>
<BODY>
<H1>Time Consistency</H1>
-<P>Time consistency is problem of deciding whether introduced time constraints in MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
-<p> The motivation for time consitency is following. It can easily happen that user can sapecify too restrictive time constraint and cause that the set of executions which satisfy MSC is empty. The time consistency property checks such situations.
+<P>Time consistency is a problem of deciding whether introduced time constraints in a given MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
+<p> The motivation for time consitency is following. It can easily happen that user can specify too restrictive time constraint and cause that the set of executions/behaviors which satisfy MSC is empty. The time consistency property checks such situations.
<H2>Basic Message Sequence Chart</H2>
<P>Time consistent property is violated for BMSC B when there is no time assignment for B.</P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
-<P>An example of time inconsistent BMSC is depicted on the next picture.</P>
+<P>An example of a time consistent BMSC is depicted on the next picture.</P>
<img src="pictures/cons1.png" border="0" alt="Time inconsistent BMSC" title="Time inconsistent BMSC">
<H2>High-level MSC</H2>
Modified: trunk/doc/help/time_syntax/time_syntax.html
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/time_syntax/time_syntax.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -10,20 +10,20 @@
<H1>Correct Time Constraint Syntax</H1>
<P>The correct time constraint syntax algorithm is used for checking whether introduced time constraints are correct to use in SCStudio. The main motivation for such test is to rule out time constraints which are either not allowed by standard or ambiguous.
</P>
-<P>The following conditions must hold for every time constraint to suffice correct time constraint algorithm:
+<P>The following conditions must hold for every time constraint to suffice correct time constraint syntax algorithm:
<ul>
<li>if the constraint is in BMSC it has to restrict events which are visually ordered </li>
-<li>if the constraint is in HMSC and it restricts nodes A and B, every path going through A must go through B (and other way around) and it cannot go twice through A (B) without going through node B (A) in between.</li>
+<li>if the constraint is in HMSC and it restricts nodes A and B, every path going through A (resp. B) must go through B (resp. A) and it cannot go twice through A (resp. B) without going through node B (resp. A) in between.</li>
</ul> </p>
-<P>An example of a time constraint can be seen on the next picture. Receive events of HTTP Response and HTTP request messages are not visually ordered. Thus the time constraint does not satisfy the Correct Time Constraint Syntax property. </P>
+<P>An example of a time constraint can be seen on the next picture. Receive events of "HTTP Response" (??? or <I>HTTP Response</I>) and HTTP Request messages are not visually ordered. Thus the time constraint does not satisfy the correct time constraint syntax property. </P>
<img src="pictures/syntax3.png" border="0" alt="Example of a wrong time constraint" title="Example of a wrong BMSC time constraint">
-<P>On the next picture we see that there exist path which goes twice in a row through the node Connection denied and thus the introduced time constraint also does not satisfy correct time constraint syntax property.</P>
+<P>On the next picture we see that there exists path which goes twice in a row through the node Connection denied and thus the introduced time constraint also does not satisfy the correct time constraint syntax property.</P>
<img src="pictures/syntax1.png" border="0" alt="Violation of constraint syntax" title="Violation of constraint syntax property">
-<P>The last example depicts HMSC where exist path which goes through node A of but does not go through node B. Since there is introduced time constraint restricting these nodes it violates Correct Time Constraint Syntax property.</P>
+<P>The last example depicts a HMSC where exists path which goes through the node A of but does not go through the node B. Since there is introduced time constraint restricting these nodes, it violates the correct time constraint syntax property.</P>
<img src="pictures/syntax2.png" border="0" alt="Example of a wrong time constraint" title="Example of a wrong HMSC time constraint">
</BODY>
</HTML>
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Tighten Time</H1>
-<P>The purpose of tighten time algorithm is to shorten interval sets of time constraints to minimal possible values. It deletes the values of time constraints which cannot be used due to other more restrictive time constraints.
+<P>The purpose of tighten time algorithm is to shorten interval sets of time constraints to minimal possible values. It deletes every value of time constraints which cannot be used due to other more restrictive time constraints.
</P>
<H3> Basic MSC</H3>
<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-05-24 10:10:00 UTC (rev 811)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-05-26 22:02:50 UTC (rev 812)
@@ -10,7 +10,7 @@
<H1>Time Race</H1>
<P> Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in inverse order.</P>
-<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a time race between HTTP Request and HTTP Response receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
+<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a time race between <I>HTTP Request</I> and <I>HTTP Response</I> receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
<table><caption align="bottom"><i>BMSC with the time race</i></caption><tr><td>
<img src="pictures/race1_1.png" border="0" alt="BMSC with the time race" title="BMSC with the time race">
</tr></td></table>
@@ -19,9 +19,9 @@
<img src="pictures/race1_2.png" border="0" alt="Time race free BMSC" title="Time race free BMSC">
</tr></td></table>
-<P>BMSC B (or HMSC path p) contains time race if there are two visually ordered events in B (or p), but there exists time assignment which assigns visually preceding event larger time value than the value assigned to subsequent event.</P>
-<P>HMSC contains time race if there exists path which contains time race. </P>
-<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
+<P>BMSC B (resp. HMSC path p) contains time race if there are two visually ordered events in B (resp. p), but there exists time assignment which assigns the visually preceding event larger time value than the value assigned to the subsequent event.</P>
+<P>An HMSC contains time race if there exists path which contains time race. </P>
+<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by the assignment to these events must be included in the interval set of this constraint.</P>
<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
<P>The next example shows HMSC which contains race condition, but which is time race free.</P>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-06-09 22:45:29
|
Revision: 817
http://scstudio.svn.sourceforge.net/scstudio/?rev=817&view=rev
Author: lkorenciak
Date: 2010-06-09 22:45:23 +0000 (Wed, 09 Jun 2010)
Log Message:
-----------
added few descriptions of pictures in Help
Modified Paths:
--------------
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/livelock/livelock.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/membership/membership.html
trunk/doc/help/race/race.html
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/boundedness/boundedness.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -1,17 +1,17 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Universal Boundedness</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
-
-<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
-
-<p>
-<img src="unbounded.png" alt="Unbounded HMSC">
-</BODY>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Universal Boundedness</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Universal Boundedness</H1>
+<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
+
+<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
+<P>TODO add description of the picture here... </P>
+<p>
+<img src="unbounded.png" alt="Unbounded HMSC">
+</BODY>
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/deadlock/deadlock.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -11,9 +11,13 @@
<P>is a property of an HMSC node. An HMSC node is deadlocked if there is no reference node or end node reachable from the node, i.e. after the execution of the MSC referenced by a deadlocked node, there is no node to continue with.</P>
<P>
-SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is available/suggested/given as example of the deadlock.
+SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is given as example of the deadlock.
</P>
+<P>
+In the next picture the node B is clearly a deadlocked node. That is why it is highlited by SCStudio and given as an example/ to show the deadlock.
+</P>
+
<p>
<img src="deadlock.png" alt="Typical deadlock">
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/fifo/fifo.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -10,7 +10,20 @@
<H1>FIFO property</H1>
<P>FIFO (First In, First Out) is a property of an MSC. The property ensures that it is possible
to implement the desired behavior without deadlocks, that would be
-caused by attributes/behavior of channels.</P>
+caused by behavior of channels.</P>
+
+<P>
+There are several types of channels and several ways how they can be used im MSC. Some of the most useful are the following:
+<ul>
+<li> FIFO channel for every pair of instances </li>
+<li> FIFO channel for every pair of instances and labels </li>
+<li> One FIFO channel for every process </li>
+<li> One FIFO channel for all processes </li>
+</ul>
+
+The SCStudio currently supports the first two options. The extension for other options is planned.
+</P>
+
<H2>Basic Message Sequence Chart</H2>
<H3>FIFO channel for every pair of instances </H3>
<P>FIFO property is violated when there are two
@@ -30,12 +43,12 @@
a, b (a,c form the first message and b,d form the second message) it holds that
c < d => a < b, where < is the visual order and the two messages belong
to the same channel.</P>
-<P>Tricky examples of FIFO MSCs:</P>
+<P>Tricky examples of FIFO MSCs: On the next picture we can see tricky examples of FIFO BMSCs. They satisfy the FIFO property, because the receive events of both messages are in coregion. This means that the user has sapecified that the receive events can happen in arbitrary order. So that if we any order of these two events in the head of the channel queue, the system will certainly not reach deadlock.</P>
<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<P>An example of a non-FIFO design can be seen on the following picture:</P>
+<P>An example of a non-FIFO design can be seen on the following picture. This is because the Instance q can execute only the receive event of message <I>m1</I> first/before/and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and messege <I>m2</I> is behind it. </P>
<img src="pictures/nonfifo1.png" border="0" alt="non-FIFO MSC design" title="non-FIFO MSC design">
<H3>FIFO channel for every pair of instances and labels</H3>
@@ -45,13 +58,15 @@
<P>Messages <I>m2</I> and <I>m1</I> are not in the same channel, therefore they may arrive in
any order.</P>
+<!-- comment
<H3>One FIFO buffer for every process</H3>
<P>TODO, wait until implementation is done</P>
<H3>One FIFO buffer for all processes</H3>
<P>TODO, wait until implementation is done</P>
+-->
<H2>High-level Message Sequence Chart</H2>
<P>HMSC satisfies FIFO property for a certain channel
-type, if every BMSC represented/specified by the HMSC satisfies FIFO property
-for that channel type:</P>
+type, if every BMSC represented by the HMSC satisfies the FIFO property
+for that channel type.</P>
</BODY>
</HTML>
Modified: trunk/doc/help/livelock/livelock.html
===================================================================
--- trunk/doc/help/livelock/livelock.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/livelock/livelock.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -1,16 +1,16 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Livelock</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Livelock</H1>
-<P>is a property of an HMSC. An HMSC contains a livelock if there exists a cycle of nodes from which no endnode is reachable. It is required that the cycle contains at least one reference node.</P>
-
-<P>SCStudio finds and displays all such cycles in a given HMSC.</P>
-
-<P><img src="livelock.png" alt="Typical livelock"></P>
-</BODY>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Livelock</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Livelock</H1>
+<P>is a property of an HMSC. An HMSC contains a livelock if there exists a cycle of nodes from which no endnode is reachable. It is required that the cycle contains at least one reference node.</P>
+
+<P>SCStudio finds and displays all such cycles in a given HMSC.</P>
+<P> An example of livelock is depicted on the next picture. It clearly satisfies all conditions for livelock.</P>
+<P><img src="livelock.png" alt="Typical livelock"></P>
+</BODY>
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/localchoice/localchoice.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Non-local choice</H1>
-<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches MSC A or MSC B) are possible and the branches are initiated by different instances (MSC A is initiated by instance p, MSC B is initiated by instance q). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
+<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches MSC A or MSC B) are possible and the branches are initiated by different instances (MSC A is initiated by the Instance p, MSC B is initiated by the Instance q). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
<DIV class="gallery vary">
<table><caption align="bottom"><i>HMSC</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal.png" BORDER="0" ALT="HMSC specification with a branching node" title="HMSC specification with a branching node">
Modified: trunk/doc/help/membership/membership.html
===================================================================
--- trunk/doc/help/membership/membership.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/membership/membership.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -34,13 +34,13 @@
<br clear="all">
<P >In the figure above we
-have specified input to the membership problem. Every path from
-initial node to terminal node in a HMSC represents a BMSC. There is
-only one path in the <i>Input HMSC</i>. The bMSC specified by the path is
-formed from nodes (BMSCs) on the path by sequential composition
+have specified an input to the membership problem. Every path from the
+initial node to the terminal node in a HMSC represents a BMSC. There is
+only one path in the <i>Input HMSC</i>. The BMSC specified by the path is
+formed from nodes (BMSCs) on the path by the sequential composition
(putting the BMSCs one after the other and gluing the matching
process lines). It is easy to see that the <i>Input BMSC</i> is exactly the
-same bMSC represented by the only path in the <i>Input HMSC</i>. The result of
+same BMSC represented by the only path in the <i>Input HMSC</i>. The result of
procedure solving membership problem should be every successful path
i.e. <i>Input HMSC</i>.</P>
<P >More formal
@@ -48,7 +48,7 @@
<P >Input:
</P>
<UL>
- <LI><P >BMSC with timing
+ <LI><P >BMSC with the timing
assignment</P>
<LI><P >MSC with timers
and time constraints (both HMSC constraints and BMSC
@@ -59,7 +59,7 @@
representing the possible paths in the HMSC. The paths, after
sequential composition, form a set of BMSCs with time constraints.
The input BMSC satisfies all the time constraints in every one of the
-BMSCs formed by paths from the start to the end node.</P>
+BMSCs formed by paths from the start to the end node of the graph.</P>
<P >Example 2:</P>
<DIV class="gallery vary">
@@ -97,6 +97,6 @@
</div>
<br clear="all">
-<P >In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>bMSC4</i> forms BMSC which is not satisfied by the <i>Input bMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle through <i>bMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
+<P >In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>BMSC4</i> forms BMSC which is not satisfied by the <i>Input BMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle going through/containing <i>BMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
</BODY>
</HTML>
\ No newline at end of file
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/race/race.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -1,13 +1,15 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Race Condition</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Race Condition</H1>
-<P>Race Condition occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for MSCs that satisfy FIFO.</P>
-<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
-</BODY>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Race Condition</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Race Condition</H1>
+<P>Race Condition occurs in an MSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for MSCs that satisfy FIFO.</P>
+<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
+
+<P>On the next picture there is an example of an BMSC which contains race condition. The receive events of messages ... but it is possibele that...</P>
+</BODY>
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -9,7 +9,7 @@
<BODY>
<H1>Time Consistency</H1>
<P>Time consistency is a problem of deciding whether introduced time constraints in a given MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
-<p> The motivation for time consitency is following. It can easily happen that user can specify too restrictive time constraint and cause that the set of executions/behaviors which satisfy MSC is empty. The time consistency property checks such situations.
+<p> The motivation for time consitency is following. It can easily happen that user can specify too restrictive time constraints and cause that the set of behaviors which satisfy MSC is empty. The time consistency property checks such situations.
<H2>Basic Message Sequence Chart</H2>
<P>Time consistent property is violated for BMSC B when there is no time assignment for B.</P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
@@ -19,7 +19,7 @@
<H2>High-level MSC</H2>
<P>HMSC violates time consistent property if exists path from start node to end node for which there is no time assignment.</P>
-<P>An example of time inconsistent HMSC is depicted on the next picture.</P>
+<P>An example of time inconsistent HMSC is depicted on the next picture. The inconsistency follows from the fact that the two inner constraints are too short compared to the outer constraint. That is why it is not possible for the events in the HMSC to satisfy all constraints.</P>
<img src="pictures/cons2.png" border="0" alt="Time inconsistent HMSC" title="Time inconsistent HMSC">
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -14,7 +14,7 @@
<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
-<P>An example of the tighten time algorithm on a BMSC:</P>
+<P>An example of the tighten time algorithm on a BMSC TODO add comment why it is tightened this way:</P>
<table><caption align="bottom"><i>Original BMSC</i></caption><tr><td>
@@ -27,7 +27,7 @@
<H3> High-level MSC</H3>
<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment for some path from the start node to the end node.</p>
-<P>An example of the tighten time algorithm on a HMSC:</P>
+<P>An example of the tighten time algorithm on a HMSC: TODO add comment why it is tightened this way</P>
<table><caption align="bottom"><i>Original HMSC</i></caption><tr><td>
<img src="pictures/tighten1_1.png" border="0" alt="Original HMSC" title="Original HMSC">
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-06-09 17:11:08 UTC (rev 816)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-06-09 22:45:23 UTC (rev 817)
@@ -23,7 +23,7 @@
<P>An HMSC contains time race if there exists path which contains time race. </P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by the assignment to these events must be included in the interval set of this constraint.</P>
<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
-<P>The next example shows HMSC which contains race condition, but which is time race free.</P>
+<P>The next example shows HMSC which contains race condition (between <I>HTTP Request</I> and <I>HTTP Response</I> receive events), but which is time race free.</P>
<table><caption align="bottom"><i>BMSC B</i></caption><tr><td>
<img src="pictures/race2_1.png" border="0" alt="Example of time race free HMSC" title="Example of time race free HMSC">
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <lko...@us...> - 2010-06-17 03:06:37
|
Revision: 820
http://scstudio.svn.sourceforge.net/scstudio/?rev=820&view=rev
Author: lkorenciak
Date: 2010-06-17 03:06:31 +0000 (Thu, 17 Jun 2010)
Log Message:
-----------
added few descriptions of pictures in Help, mistakes fixed
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/membership/membership.html
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/acyclic/acyclic.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -10,10 +10,10 @@
<H1>Acyclic property</H1>
<P> Acyclic property ensures that there is no cyclic dependency among events in an MSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such MSC design can be seen in the following figure:</P>
<IMG SRC="pictures/cyclic_simple.png" BORDER="0" ALT="Cyclic MSC" TITLE="Cyclic MSC">
-<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
+<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be sent until message <I>m2</I> is received.</P>
<P> SCStudio highlights the cyclic dependency:</P>
<IMG SRC="pictures/cyclic_result.png" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
-<P> A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the Instance p which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency.
+<P> A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency.
</P>
<IMG SRC="pictures/acyclic.png" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
</BODY>
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/boundedness/boundedness.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -11,7 +11,7 @@
<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
-<P>TODO add description of the picture here... </P>
+<P>The HMSC on the following picture is unbounded. This is because there is no mechanism for keeping the buffer for messages between <I>X</I> and <I>Y</I> bounded. For any bound <I>B</I> of the buffer we can make an execution for which the buffer is not sufficiently large. This execution is for example the one which goes through cycle <I>B+1</I> times, the sending of message is very fast and the receiving is very slow. It is so slow, that in point of time when we have sent all messages we have not received any of them. Thus we have exceeded the bound <I>B</I> for this buffer.</P>
<p>
<img src="unbounded.png" alt="Unbounded HMSC">
</BODY>
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/deadlock/deadlock.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -11,11 +11,11 @@
<P>is a property of an HMSC node. An HMSC node is deadlocked if there is no reference node or end node reachable from the node, i.e. after the execution of the MSC referenced by a deadlocked node, there is no node to continue with.</P>
<P>
-SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is given as example of the deadlock.
+SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is given as an example of the deadlock.
</P>
<P>
-In the next picture the node B is clearly a deadlocked node. That is why it is highlited by SCStudio and given as an example/ to show the deadlock.
+On the next picture the node B is clearly a deadlocked node. That is why it is highlited by SCStudio and given as an example.
</P>
<p>
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/fifo/fifo.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -13,7 +13,7 @@
caused by behavior of channels.</P>
<P>
-There are several types of channels and several ways how they can be used im MSC. Some of the most useful are the following:
+There are several types of channels and several ways how they can be used in MSC. Some of the most useful are the following:
<ul>
<li> FIFO channel for every pair of instances </li>
<li> FIFO channel for every pair of instances and labels </li>
@@ -43,16 +43,16 @@
a, b (a,c form the first message and b,d form the second message) it holds that
c < d => a < b, where < is the visual order and the two messages belong
to the same channel.</P>
-<P>Tricky examples of FIFO MSCs: On the next picture we can see tricky examples of FIFO BMSCs. They satisfy the FIFO property, because the receive events of both messages are in coregion. This means that the user has sapecified that the receive events can happen in arbitrary order. So that if we any order of these two events in the head of the channel queue, the system will certainly not reach deadlock.</P>
+<P>On the next picture we can see tricky examples of FIFO BMSCs. They satisfy the FIFO property, because the receive events of both messages are in coregion. This means that the user has specified that the receive events can happen in an arbitrary order. So that if there is any order of these two events in the head of the channel queue, the system will certainly not reach deadlock.</P>
<img src="pictures/fifo1.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
<img src="pictures/fifo2.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-<P>An example of a non-FIFO design can be seen on the following picture. This is because the Instance q can execute only the receive event of message <I>m1</I> first/before/and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and messege <I>m2</I> is behind it. </P>
+<P>An example of a non-FIFO design can be seen on the following picture. This is because the <I>Instance q</I> can execute only the receive event of message <I>m1</I> and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and messege <I>m2</I> is behind it. </P>
<img src="pictures/nonfifo1.png" border="0" alt="non-FIFO MSC design" title="non-FIFO MSC design">
<H3>FIFO channel for every pair of instances and labels</H3>
-<P>In this case we can have more than one FIFO channel between two processes. For every label there is one channel. Everything what has satisfied FIFO property in the previous case, will satisfy also in this case. The difference can be seen on the following FIFO example:</P>
+<P>In this case we can have more than one FIFO channel between two processes. For every label there is one channel. Everything what has satisfied FIFO property in the previous case, will satisfy the property also in this case. The difference can be seen on the following FIFO example:</P>
<img src="pictures/label_channel_fifo.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/localchoice/localchoice.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Non-local choice</H1>
-<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches MSC A or MSC B) are possible and the branches are initiated by different instances (MSC A is initiated by the Instance p, MSC B is initiated by the Instance q). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
+<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches <I>MSC A</I> or <I>MSC B</I>) are possible and the branches are initiated by different instances (<I>MSC A</I> is initiated by the <I>Instance p</I>, <I>MSC B</I> is initiated by the <I>Instance q</I>). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
<DIV class="gallery vary">
<table><caption align="bottom"><i>HMSC</i></caption><tr><td>
<IMG SRC="pictures/simple_nonlocal.png" BORDER="0" ALT="HMSC specification with a branching node" title="HMSC specification with a branching node">
Modified: trunk/doc/help/membership/membership.html
===================================================================
--- trunk/doc/help/membership/membership.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/membership/membership.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -97,6 +97,6 @@
</div>
<br clear="all">
-<P >In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>BMSC4</i> forms BMSC which is not satisfied by the <i>Input BMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle going through/containing <i>BMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
+<P >In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>BMSC4</i> forms BMSC which is not satisfied by the <i>Input BMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle containing <i>BMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
</BODY>
</HTML>
\ No newline at end of file
Modified: trunk/doc/help/time_syntax/time_syntax.html
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/time_syntax/time_syntax.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Correct Time Constraint Syntax</H1>
-<P>The correct time constraint syntax algorithm is used for checking whether introduced time constraints are correct to use in SCStudio. The main motivation for such test is to rule out time constraints which are either not allowed by standard or ambiguous.
+<P>The correct time constraint syntax algorithm is used for checking whether introduced time constraints are correct to use in SCStudio. The main motivation for such test is to rule out time constraints which are either not allowed by the standard or ambiguous.
</P>
<P>The following conditions must hold for every time constraint to suffice correct time constraint syntax algorithm:
<ul>
@@ -16,10 +16,10 @@
<li>if the constraint is in HMSC and it restricts nodes A and B, every path going through A (resp. B) must go through B (resp. A) and it cannot go twice through A (resp. B) without going through node B (resp. A) in between.</li>
</ul> </p>
-<P>An example of a time constraint can be seen on the next picture. Receive events of "HTTP Response" (??? or <I>HTTP Response</I>) and HTTP Request messages are not visually ordered. Thus the time constraint does not satisfy the correct time constraint syntax property. </P>
+<P>An example of a time constraint can be seen on the next picture. Receive events of <I>HTTP Response</I> and <I>HTTP Request</I> messages are not visually ordered. Thus the time constraint does not satisfy the correct time constraint syntax property. </P>
<img src="pictures/syntax3.png" border="0" alt="Example of a wrong time constraint" title="Example of a wrong BMSC time constraint">
-<P>On the next picture we see that there exists path which goes twice in a row through the node Connection denied and thus the introduced time constraint also does not satisfy the correct time constraint syntax property.</P>
+<P>On the next picture we see that there exists path which goes twice in a row through the node <I>Connection denied</I> and thus the introduced time constraint also does not satisfy the correct time constraint syntax property.</P>
<img src="pictures/syntax1.png" border="0" alt="Violation of constraint syntax" title="Violation of constraint syntax property">
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -8,13 +8,13 @@
</HEAD>
<BODY>
<H1>Tighten Time</H1>
-<P>The purpose of tighten time algorithm is to shorten interval sets of time constraints to minimal possible values. It deletes every value of time constraints which cannot be used due to other more restrictive time constraints.
+<P>The purpose of the tighten time algorithm is to shorten interval sets of time constraints to minimal possible values. It deletes every value of time constraints which cannot be used due to other more restrictive time constraints.
</P>
<H3> Basic MSC</H3>
-<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
-<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
+<P>After the tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment.</p>
+<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by the assignment to these events must be included in the interval set of this constraint.</P>
-<P>An example of the tighten time algorithm on a BMSC TODO add comment why it is tightened this way:</P>
+<P>An example of the tighten time algorithm on a BMSC is shown on the next picture. The time constraint which contains value (0,10) has to be changed to [5,10) because the communication turnover takes at least 5 time units.</P>
<table><caption align="bottom"><i>Original BMSC</i></caption><tr><td>
@@ -26,8 +26,16 @@
</tr></td></table>
<H3> High-level MSC</H3>
-<P>After tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment for some path from the start node to the end node.</p>
-<P>An example of the tighten time algorithm on a HMSC: TODO add comment why it is tightened this way</P>
+<P>After the tighten time algorithm, every constraint contains only values in interval sets for which exists valid time assignment for some path from the start node to an end node.</p>
+<P>An example of the tighten time algorithm on a HMSC is shown on the next picture. The constraints change because of the following reasons:
+<ul>
+<li> the constraint on the node <I> B </I> changes because of the <i>Original BMSC B</i> </li>
+<li> the lower bound of the constraint between the nodes <I>A</I> and <I>B</I> changes to 8 because the lower bound of the first path is 9 and the lower bound of the second path is 8</li>
+<li> the <i>Original BMSC A</i> tightens to the <i>Tightened BMSC A</i> because of the both constraints on the nodes <I> A </I> (the upper bound is derived from the constraint containing [3,5] and the lower bound from the constraint containing [2,8]) </li>
+<li> the upper bound of the HMSC constraint originally containing [3,5] is tightened to 5 (not included) because the candidates for the upper bound is the lower value from upper bound 5 (from the original constraint) and the value derived from constraints containing, (8,10], (3,4] and [2,8]. We have to compute the upper bound candidate from the values of the time intervals. Since we can stay at least 3 (not included) time units in the first node <I> A </I> and at least 2 time units in the node <I>B</I> and we can stay at most 10 time units in the whole execution we get that we can stay at most 10 - 3 - 2 = 5 (not included) time units in second node <I> A </I>. Thus the original constraint (with the value [3,5]) will contain [3,5) after the execution of the tightening algorithm.</li>
+<li> the upper bound of the constraint containing originally [2,8] tightens to 4 (not included), bacause the possible upper bound for this constraint derived from the first path is 10 - 4 - 3 = 3 (not included) and from the second path it is 10 - 3 - 3 = 4 (not included). </li>
+</ul>
+</P>
<table><caption align="bottom"><i>Original HMSC</i></caption><tr><td>
<img src="pictures/tighten1_1.png" border="0" alt="Original HMSC" title="Original HMSC">
@@ -37,8 +45,8 @@
<img src="pictures/tighten1_2.png" border="0" alt="Original BMSC A" title="Original BMSC A">
</tr></td></table>
-<table><caption align="bottom"><i>Original HMSC B</i></caption><tr><td>
-<img src="pictures/tighten1_3.png" border="0" alt="Original HMSC B" title="Original BMSC B">
+<table><caption align="bottom"><i>Original BMSC B</i></caption><tr><td>
+<img src="pictures/tighten1_3.png" border="0" alt="Original BMSC B" title="Original BMSC B">
</tr></td></table>
<table><caption align="bottom"><i>Tightened HMSC</i></caption><tr><td>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-06-11 11:36:43 UTC (rev 819)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-06-17 03:06:31 UTC (rev 820)
@@ -10,7 +10,7 @@
<H1>Time Race</H1>
<P> Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in inverse order.</P>
-<P> The introduction of time constraints can eliminate some race conditions. For example consider next two pictures. In the first one there is a time race between <I>HTTP Request</I> and <I>HTTP Response</I> receive events. However on the second one the added time constraint caused that the BMSC is time race free. </P>
+<P> The introduction of time constraints can eliminate some race conditions. For example consider the next two pictures. On the first one there is a time race between <I>HTTP Request</I> and <I>HTTP Response</I> receive events. However on the second one the added time constraint caused that the BMSC is time race free (the receive event of <I>HTTP Request</I> surely happens after the <I>HTTP Response</I> receive event). </P>
<table><caption align="bottom"><i>BMSC with the time race</i></caption><tr><td>
<img src="pictures/race1_1.png" border="0" alt="BMSC with the time race" title="BMSC with the time race">
</tr></td></table>
@@ -23,7 +23,7 @@
<P>An HMSC contains time race if there exists path which contains time race. </P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by the assignment to these events must be included in the interval set of this constraint.</P>
<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
-<P>The next example shows HMSC which contains race condition (between <I>HTTP Request</I> and <I>HTTP Response</I> receive events), but which is time race free.</P>
+<P>The next example shows HMSC which contains race condition (between <I>HTTP Request</I> and <I>HTTP Response</I> receive events), but which is time race free. Due to time constraints the <I>HTTP Request</I>receive event happens allways before the <I>HTTP Response</I> receive event. </P>
<table><caption align="bottom"><i>BMSC B</i></caption><tr><td>
<img src="pictures/race2_1.png" border="0" alt="Example of time race free HMSC" title="Example of time race free HMSC">
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ag...@us...> - 2010-09-07 09:03:48
|
Revision: 877
http://scstudio.svn.sourceforge.net/scstudio/?rev=877&view=rev
Author: agmy
Date: 2010-09-07 09:03:38 +0000 (Tue, 07 Sep 2010)
Log Message:
-----------
wide help
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/acyclic/pictures/acyclic.png
trunk/doc/help/acyclic/pictures/cyclic_result.png
trunk/doc/help/acyclic/pictures/cyclic_simple.png
trunk/doc/help/algorithms.html
trunk/doc/help/beautify/beautify.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/fifo/pictures/fifo1.png
trunk/doc/help/fifo/pictures/fifo1.vsd
trunk/doc/help/fifo/pictures/fifo2.png
trunk/doc/help/fifo/pictures/label_channel_fifo.png
trunk/doc/help/fifo/pictures/nonfifo1.png
trunk/doc/help/fifo/pictures/simple_non_fifo.png
trunk/doc/help/frontend/shortcuts.html
trunk/doc/help/help.css
trunk/doc/help/livelock/livelock.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/localchoice/pictures/simple_nonlocal.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCA.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_implied.png
trunk/doc/help/localchoice/pictures/simple_nonlocal_result.png
trunk/doc/help/membership/membership.html
trunk/doc/help/race/race.html
trunk/doc/help/time_consistency/pictures/cons1.png
trunk/doc/help/time_consistency/pictures/cons2.png
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/pictures/syntax1.png
trunk/doc/help/time_syntax/pictures/syntax2.png
trunk/doc/help/time_syntax/pictures/syntax3.png
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/pictures/tighten1_1.png
trunk/doc/help/time_tighten/pictures/tighten1_2.png
trunk/doc/help/time_tighten/pictures/tighten1_3.png
trunk/doc/help/time_tighten/pictures/tighten1_4.png
trunk/doc/help/time_tighten/pictures/tighten1_5.png
trunk/doc/help/time_tighten/pictures/tighten1_6.png
trunk/doc/help/time_tighten/pictures/tighten2.vsd
trunk/doc/help/time_tighten/pictures/tighten2_1.png
trunk/doc/help/time_tighten/pictures/tighten2_2.png
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/pictures/race1_1.png
trunk/doc/help/time_trace_race/pictures/race1_2.png
trunk/doc/help/time_trace_race/pictures/race2_1.png
trunk/doc/help/time_trace_race/pictures/race2_2.png
trunk/doc/help/time_trace_race/pictures/race2_3.png
trunk/doc/help/time_trace_race/time_race.html
Added Paths:
-----------
trunk/doc/help/acyclic/acyclic.html~
trunk/doc/help/acyclic/pictures/acyclic_small.png
trunk/doc/help/acyclic/pictures/cyclic_result_small.png
trunk/doc/help/acyclic/pictures/cyclic_simple_small.png
trunk/doc/help/beautify/beautify.html~
trunk/doc/help/beautify/pictures/
trunk/doc/help/beautify/pictures/coregion1.png
trunk/doc/help/beautify/pictures/coregion1.vsd
trunk/doc/help/beautify/pictures/coregion1_small.png
trunk/doc/help/beautify/pictures/coregion2.png
trunk/doc/help/beautify/pictures/coregion2.vsd
trunk/doc/help/beautify/pictures/coregion2_small.png
trunk/doc/help/beautify/pictures/ordered.png
trunk/doc/help/beautify/pictures/ordered.vsd
trunk/doc/help/beautify/pictures/ordered_small.png
trunk/doc/help/beautify/pictures/unfifo2.png
trunk/doc/help/beautify/pictures/unfifo2.vsd
trunk/doc/help/beautify/pictures/unfifo2_small.png
trunk/doc/help/beautify/pictures/unordered.png
trunk/doc/help/beautify/pictures/unordered.vsd
trunk/doc/help/beautify/pictures/unordered_small.png
trunk/doc/help/boundedness/boundedness.html~
trunk/doc/help/boundedness/pictures/
trunk/doc/help/boundedness/pictures/unbounded.vsd
trunk/doc/help/boundedness/pictures/unbounded_hmsc.png
trunk/doc/help/boundedness/pictures/unbounded_msc.png
trunk/doc/help/boundedness/pictures/unbounded_small.png
trunk/doc/help/deadlock/deadlock.html~
trunk/doc/help/deadlock/pictures/
trunk/doc/help/deadlock/pictures/deadlock.png
trunk/doc/help/deadlock/pictures/deadlock.vsd
trunk/doc/help/deadlock/pictures/deadlock_small.png
trunk/doc/help/fifo/fifo.html~
trunk/doc/help/fifo/pictures/label_channel_fifo_small.png
trunk/doc/help/fifo/pictures/simple_chan_fifo.png
trunk/doc/help/fifo/pictures/small/
trunk/doc/help/fifo/pictures/small/fifo1_small.png
trunk/doc/help/fifo/pictures/small/fifo2_small.png
trunk/doc/help/fifo/pictures/small/nonfifo1_small.png
trunk/doc/help/fifo/pictures/small/simple_chan_fifo_small.png
trunk/doc/help/fifo/pictures/small/simple_non_fifo_small.png
trunk/doc/help/frontend/shortcuts.html~
trunk/doc/help/livelock/livelock.html~
trunk/doc/help/livelock/pictures/
trunk/doc/help/livelock/pictures/livelock.png
trunk/doc/help/livelock/pictures/livelock.vsd
trunk/doc/help/livelock/pictures/small/
trunk/doc/help/livelock/pictures/small/livelock_small.png
trunk/doc/help/localchoice/localchoice.html~
trunk/doc/help/localchoice/pictures/small/
trunk/doc/help/localchoice/pictures/small/simple_nonlocal_MSCA_small.png
trunk/doc/help/localchoice/pictures/small/simple_nonlocal_MSCB_small.png
trunk/doc/help/localchoice/pictures/small/simple_nonlocal_implied_small.png
trunk/doc/help/localchoice/pictures/small/simple_nonlocal_result_small.png
trunk/doc/help/localchoice/pictures/small/simple_nonlocal_small.png
trunk/doc/help/membership/membership.html~
trunk/doc/help/membership/pictures/
trunk/doc/help/membership/pictures/memebership_1.png
trunk/doc/help/membership/pictures/memebership_10.png
trunk/doc/help/membership/pictures/memebership_11.png
trunk/doc/help/membership/pictures/memebership_12.png
trunk/doc/help/membership/pictures/memebership_2.png
trunk/doc/help/membership/pictures/memebership_3.png
trunk/doc/help/membership/pictures/memebership_4.png
trunk/doc/help/membership/pictures/memebership_5.png
trunk/doc/help/membership/pictures/memebership_6.png
trunk/doc/help/membership/pictures/memebership_7.png
trunk/doc/help/membership/pictures/memebership_8.png
trunk/doc/help/membership/pictures/memebership_9.png
trunk/doc/help/membership/pictures/small/
trunk/doc/help/membership/pictures/small/memebership_10_small.png
trunk/doc/help/membership/pictures/small/memebership_11_small.png
trunk/doc/help/membership/pictures/small/memebership_12_small.png
trunk/doc/help/membership/pictures/small/memebership_1_small.png
trunk/doc/help/membership/pictures/small/memebership_2_small.png
trunk/doc/help/membership/pictures/small/memebership_3_small.png
trunk/doc/help/membership/pictures/small/memebership_4_small.png
trunk/doc/help/membership/pictures/small/memebership_5_small.png
trunk/doc/help/membership/pictures/small/memebership_6_small.png
trunk/doc/help/membership/pictures/small/memebership_7_small.png
trunk/doc/help/membership/pictures/small/memebership_8_small.png
trunk/doc/help/membership/pictures/small/memebership_9_small.png
trunk/doc/help/time_consistency/pictures/small/
trunk/doc/help/time_consistency/pictures/small/cons1_small.png
trunk/doc/help/time_consistency/pictures/small/cons2_small.png
trunk/doc/help/time_consistency/time_consistency.html~
trunk/doc/help/time_syntax/pictures/small/
trunk/doc/help/time_syntax/pictures/small/syntax1_small.png
trunk/doc/help/time_syntax/pictures/small/syntax2_small.png
trunk/doc/help/time_syntax/pictures/small/syntax3_small.png
trunk/doc/help/time_syntax/time_syntax.html~
trunk/doc/help/time_tighten/pictures/small/
trunk/doc/help/time_tighten/pictures/small/tighten1_1_small.png
trunk/doc/help/time_tighten/pictures/small/tighten1_2_small.png
trunk/doc/help/time_tighten/pictures/small/tighten1_3_small.png
trunk/doc/help/time_tighten/pictures/small/tighten1_4_small.png
trunk/doc/help/time_tighten/pictures/small/tighten1_5_small.png
trunk/doc/help/time_tighten/pictures/small/tighten1_6_small.png
trunk/doc/help/time_tighten/pictures/small/tighten2_1_small.png
trunk/doc/help/time_tighten/pictures/small/tighten2_2_small.png
trunk/doc/help/time_tighten/time_tighten.html~
trunk/doc/help/time_trace_race/pictures/small/
trunk/doc/help/time_trace_race/pictures/small/race1_1_small.png
trunk/doc/help/time_trace_race/pictures/small/race1_2_small.png
trunk/doc/help/time_trace_race/pictures/small/race2_1_small.png
trunk/doc/help/time_trace_race/pictures/small/race2_2_small.png
trunk/doc/help/time_trace_race/pictures/small/race2_3_small.png
trunk/doc/help/time_trace_race/time_race.html~
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-09-06 20:10:23 UTC (rev 876)
+++ trunk/doc/help/acyclic/acyclic.html 2010-09-07 09:03:38 UTC (rev 877)
@@ -8,12 +8,39 @@
</HEAD>
<BODY>
<H1>Acyclic property</H1>
-<P> Acyclic property ensures that there is no cyclic dependency among events in an MSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such MSC design can be seen in the following figure:</P>
-<IMG SRC="pictures/cyclic_simple.png" BORDER="0" ALT="Cyclic MSC" TITLE="Cyclic MSC">
-<P> Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be sent until message <I>m2</I> is received.</P>
-<P> SCStudio highlights the cyclic dependency:</P>
-<IMG SRC="pictures/cyclic_result.png" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result">
-<P> A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency.
-</P>
-<IMG SRC="pictures/acyclic.png" BORDER="0" ALT="Acyclic MSC" TITLE="Acyclic MSC">
+<P> ensures that there is no cyclic dependency among events in an BMSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such BMSC design can be seen in the following figure: </P>
+
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/cyclic_simple.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
+ <li>Cyclic design</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/cyclic_result.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
+ <li>Highlighted cyclic dependency</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+<p style="clear: both;">
+Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
+SCStudio highlights the cyclic dependency:
+
+A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency. </p>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/acyclic.png" width="250" BORDER="0" ALT="Acyclic BMSC" TITLE="Acyclic BMSC"></li>
+ <li>Acyclic design</li>
+ </ul>
+</li>
+</ul>
+</div>
+
</BODY>
Added: trunk/doc/help/acyclic/acyclic.html~
===================================================================
--- trunk/doc/help/acyclic/acyclic.html~ (rev 0)
+++ trunk/doc/help/acyclic/acyclic.html~ 2010-09-07 09:03:38 UTC (rev 877)
@@ -0,0 +1,46 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Acyclic property</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Acyclic property</H1>
+<P> ensures that there is no cyclic dependency among events in an BMSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such BMSC design can be seen in the following figure: </P>
+
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/cyclic_simple.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
+ <li>Cyclic design</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/cyclic_result.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
+ <li>Highlighted cyclic dependency</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+<p style="clear: both;">
+Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
+SCStudio highlights the cyclic dependency:
+
+A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency. </p>
+
+<div style="margin: 0 auto;">
+<ul><li>
+ <ul>
+ <li><IMG SRC="pictures/acyclic.png" width="250" BORDER="0" ALT="Acyclic BMSC" TITLE="Acyclic BMSC"></li>
+ <li>Acyclic design</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+</BODY>
Modified: trunk/doc/help/acyclic/pictures/acyclic.png
===================================================================
(Binary files differ)
Added: trunk/doc/help/acyclic/pictures/acyclic_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/acyclic/pictures/acyclic_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/acyclic/pictures/cyclic_result.png
===================================================================
(Binary files differ)
Added: trunk/doc/help/acyclic/pictures/cyclic_result_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/acyclic/pictures/cyclic_result_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/acyclic/pictures/cyclic_simple.png
===================================================================
(Binary files differ)
Added: trunk/doc/help/acyclic/pictures/cyclic_simple_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/acyclic/pictures/cyclic_simple_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-06 20:10:23 UTC (rev 876)
+++ trunk/doc/help/algorithms.html 2010-09-07 09:03:38 UTC (rev 877)
@@ -2,23 +2,44 @@
<head>
<link href="help.css" rel="stylesheet" type="text/css"/>
</head>
-<body>
+
<h1>Algorithms</h1>
-The following verification algorithms are supported:
+
+
+<h2>BMSC</h2>
+The following verification algorithms for BMSC are supported:
<ul>
<li><a href="acyclic/acyclic.html">Acyclic property</a></li>
+<li><a href="fifo/fifo.html">FIFO property</a></li>
+<li><a href="race/race.html">Race Condition</a></li>
<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
+<li>Unique instance names</li>
+</ul>
+
+<h2>HMSC</h2>
+The following verification algorithms for HMSC are supported:
+<ul>
+<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
<li><a href="deadlock/deadlock.html">Deadlock</a></li>
-<li><a href="fifo/fifo.html">FIFO property</a></li>
<li><a href="livelock/livelock.html">Livelock</a></li>
<li><a href="membership/membership.html">Membership</a></li>
<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
-<li><a href="race/race.html">Race Condition</a></li>
<li><a href="realizability/realizability.html">Strong Realizablilty</a></li>
+<li>Non-recursivity</li>
<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
<li><a href="time_trace_race/time_race.html">Time Race</a></li>
<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
-<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
+<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
</ul>
+
+<h2>Frontend</h2>
+<ul>
+<li><a href="beautify/beautify.html">Beautify</a></li>
+<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
+<li><a href="frontend/message-numbering.html">Message numbering</a></li>
+<li><a href="frontend/message-snapping.html">Message snapping</a></li>
+<li><a href="frontend/shape-selection.html">Shape selection</a></li>
+<li><a href="frontend/shortcuts.html">Shortcuts</a></li>
+</ul>
</body>
</html>
Modified: trunk/doc/help/beautify/beautify.html
===================================================================
--- trunk/doc/help/beautify/beautify.html 2010-09-06 20:10:23 UTC (rev 876)
+++ trunk/doc/help/beautify/beautify.html 2010-09-07 09:03:38 UTC (rev 877)
@@ -4,11 +4,12 @@
<TITLE>Beautify documentation</TITLE>
<LINK href="../help.css" rel="stylesheet" type="text/css"/>
</HEAD>
-<BODY>
+<div>
<h2>Beautify</h2>
<P>The main aim of this function is to redraw BMSC to be well-arranged.
It is accessible via menu <code>Check → Drawing → Beautify</code>.
</P>
+<h3> Example 1:</h3>
<P>It changes order of instances to minimize a number of messages
going from right side to left side and crossing instances with messages.
Instances are justified to top and have the same length.
@@ -16,24 +17,62 @@
<a href="../acyclic/acyclic.html">acyclic</a> BMSC it makes all messages
horizontal and arranged over instances uniformly from top to down.
</P>
-<P>Before:</P>
-<img src="unordered.png" alt="Unordered BMSC">
-<P>After:</P>
-<img src="ordered.png" alt="Ordered BMSC">
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/unordered.png" width="500" BORDER="0" ALT="Unordered BMSC"></li>
+ <li>Before beautify</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/ordered.png" align="middle" width="350" BORDER="0" ALT="Ordered BMSC"></li>
+ <li>After beautify</li>
+ </ul>
+</li>
+</ul>
+</div>
+<p style="clear: both;">
+
+<h3> Example 2:</h3>
<P>A <a href="../fifo/fifo.html">non-FIFO</a> BMSC is redrawn to
a form that no messages are going up.</P>
-<img src="unfifo2.png" alt="Ordered non-FIFO BMSC">
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/unfifo2.png" width="250" BORDER="0" ALT="Ordered non-FIFO BMSC"></li>
+ <li>Acyclic design</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+<p style="clear: both;">
+<h3> Example 3:</h3>
<P>For coregions it changes the order of events to minimize number
of crossing two messages. After redrawing, messages are jointed with
coregion in such way that they do not go across coregion body.
<BR></P>
-<P>Before:</P>
-<img src="coregion1.png" alt="Crossing messages jointed with coregion">
-<P>After:</P>
-<img src="coregion2.png" alt="">
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li>
+ <img src="pictures/coregion1.png" width="250" alt="Crossing messages jointed with coregion"></li>
+ <li>Before beautify</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li>
+ <img src="pictures/coregion2.png" width="250 "alt=""></li>
+ <li>After beautify</li>
+ </ul>
+</li>
+</ul>
+</div>
</BODY>
</HTML>
Added: trunk/doc/help/beautify/beautify.html~
===================================================================
--- trunk/doc/help/beautify/beautify.html~ (rev 0)
+++ trunk/doc/help/beautify/beautify.html~ 2010-09-07 09:03:38 UTC (rev 877)
@@ -0,0 +1,78 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <TITLE>Beautify documentation</TITLE>
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<div>
+<h2>Beautify</h2>
+<P>The main aim of this function is to redraw BMSC to be well-arranged.
+It is accessible via menu <code>Check → Drawing → Beautify</code>.
+</P>
+<h3> Example 1:</h3>
+<P>It changes order of instances to minimize a number of messages
+going from right side to left side and crossing instances with messages.
+Instances are justified to top and have the same length.
+For <a href="../fifo/fifo.html">FIFO</a> and
+<a href="../acyclic/acyclic.html">acyclic</a> BMSC it makes all messages
+horizontal and arranged over instances uniformly from top to down.
+</P>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/unordered.png" width="500" BORDER="0" ALT="Unordered BMSC"></li>
+ <li>Before beautify</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/ordered.png" align="middle" " width="350" BORDER="0" ALT="Ordered BMSC"></li>
+ <li>After beautify</li>
+ </ul>
+</li>
+</ul>
+</div>
+<p style="clear: both;">
+
+<h3> Example 2:</h3>
+<P>A <a href="../fifo/fifo.html">non-FIFO</a> BMSC is redrawn to
+a form that no messages are going up.</P>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/unfifo2.png" width="250" BORDER="0" ALT="Ordered non-FIFO BMSC"></li>
+ <li>Acyclic design</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+<p style="clear: both;">
+<h3> Example 3:</h3>
+<P>For coregions it changes the order of events to minimize number
+of crossing two messages. After redrawing, messages are jointed with
+coregion in such way that they do not go across coregion body.
+<BR></P>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li>
+ <img src="pictures/coregion1.png" width="250" alt="Crossing messages jointed with coregion"></li>
+ <li>Before beautify</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li>
+ <img src="pictures/coregion2.png" width="250 "alt=""></li>
+ <li>After beautify</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+</BODY>
+</HTML>
Property changes on: trunk/doc/help/beautify/beautify.html~
___________________________________________________________________
Added: svn:executable
+ *
Added: trunk/doc/help/beautify/pictures/coregion1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion1.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/coregion1.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion1.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/coregion1_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion1_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/coregion2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/coregion2.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion2.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/coregion2_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/coregion2_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/ordered.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/ordered.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/ordered.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/ordered.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/ordered_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/ordered_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unfifo2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unfifo2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unfifo2.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unfifo2.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unfifo2_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unfifo2_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unordered.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unordered.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unordered.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unordered.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/beautify/pictures/unordered_small.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/beautify/pictures/unordered_small.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-09-06 20:10:23 UTC (rev 876)
+++ trunk/doc/help/boundedness/boundedness.html 2010-09-07 09:03:38 UTC (rev 877)
@@ -8,10 +8,30 @@
</HEAD>
<BODY>
<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper limit on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
+<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper bound on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
-<P>When all the possible executions of an HMSC are finite, the HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
-<P>The HMSC on the following picture is unbounded. This is because there is no mechanism for keeping the buffer for messages between <I>X</I> and <I>Y</I> bounded. For any bound <I>B</I> of the buffer...
[truncated message content] |
|
From: <ag...@us...> - 2010-09-07 10:14:32
|
Revision: 878
http://scstudio.svn.sourceforge.net/scstudio/?rev=878&view=rev
Author: agmy
Date: 2010-09-07 10:14:23 +0000 (Tue, 07 Sep 2010)
Log Message:
-----------
help, remove ~files
Removed Paths:
-------------
trunk/doc/help/acyclic/acyclic.html~
trunk/doc/help/beautify/beautify.html~
trunk/doc/help/boundedness/boundedness.html~
trunk/doc/help/deadlock/deadlock.html~
trunk/doc/help/fifo/fifo.html~
trunk/doc/help/frontend/shortcuts.html~
trunk/doc/help/livelock/livelock.html~
trunk/doc/help/localchoice/localchoice.html~
trunk/doc/help/membership/membership.html~
trunk/doc/help/time_consistency/time_consistency.html~
trunk/doc/help/time_syntax/time_syntax.html~
trunk/doc/help/time_tighten/time_tighten.html~
trunk/doc/help/time_trace_race/time_race.html~
Deleted: trunk/doc/help/acyclic/acyclic.html~
===================================================================
--- trunk/doc/help/acyclic/acyclic.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/acyclic/acyclic.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,46 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Acyclic property</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Acyclic property</H1>
-<P> ensures that there is no cyclic dependency among events in an BMSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such BMSC design can be seen in the following figure: </P>
-
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/cyclic_simple.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li>Cyclic design</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/cyclic_result.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li>Highlighted cyclic dependency</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
-SCStudio highlights the cyclic dependency:
-
-A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency. </p>
-
-<div style="margin: 0 auto;">
-<ul><li>
- <ul>
- <li><IMG SRC="pictures/acyclic.png" width="250" BORDER="0" ALT="Acyclic BMSC" TITLE="Acyclic BMSC"></li>
- <li>Acyclic design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
Deleted: trunk/doc/help/beautify/beautify.html~
===================================================================
--- trunk/doc/help/beautify/beautify.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/beautify/beautify.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,78 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <TITLE>Beautify documentation</TITLE>
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<div>
-<h2>Beautify</h2>
-<P>The main aim of this function is to redraw BMSC to be well-arranged.
-It is accessible via menu <code>Check → Drawing → Beautify</code>.
-</P>
-<h3> Example 1:</h3>
-<P>It changes order of instances to minimize a number of messages
-going from right side to left side and crossing instances with messages.
-Instances are justified to top and have the same length.
-For <a href="../fifo/fifo.html">FIFO</a> and
-<a href="../acyclic/acyclic.html">acyclic</a> BMSC it makes all messages
-horizontal and arranged over instances uniformly from top to down.
-</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unordered.png" width="500" BORDER="0" ALT="Unordered BMSC"></li>
- <li>Before beautify</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/ordered.png" align="middle" " width="350" BORDER="0" ALT="Ordered BMSC"></li>
- <li>After beautify</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<h3> Example 2:</h3>
-<P>A <a href="../fifo/fifo.html">non-FIFO</a> BMSC is redrawn to
-a form that no messages are going up.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unfifo2.png" width="250" BORDER="0" ALT="Ordered non-FIFO BMSC"></li>
- <li>Acyclic design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-<h3> Example 3:</h3>
-<P>For coregions it changes the order of events to minimize number
-of crossing two messages. After redrawing, messages are jointed with
-coregion in such way that they do not go across coregion body.
-<BR></P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li>
- <img src="pictures/coregion1.png" width="250" alt="Crossing messages jointed with coregion"></li>
- <li>Before beautify</li>
- </ul></li>
-<li>
- <ul>
-
- <li>
- <img src="pictures/coregion2.png" width="250 "alt=""></li>
- <li>After beautify</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
-</HTML>
Deleted: trunk/doc/help/boundedness/boundedness.html~
===================================================================
--- trunk/doc/help/boundedness/boundedness.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/boundedness/boundedness.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,37 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Universal Boundedness</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper bound on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
-
-<P>When all the possible executions of an HMSC are finite, then HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
-<P>The HMSC on the following picture is unbounded. This is because there is no mechanism for keeping the buffer for messages between <I>X</I> and <I>Y</I> bounded. </P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unbounded_hmsc.png" width="250" BORDER="0" ALT="Unbounded HMSC" TITLE="Unbounded HMSC"></li>
- <li>Unbounded HMSC</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/unbounded_msc.png" width="250" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li>MSC A</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-
-<P>For any bound <I>B</I> of the buffer we can make an execution for which the buffer is not sufficiently large. This execution is for example the one which goes through cycle <I>B+1</I> times, the sending of message is very fast and the receiving is very slow. It is so slow, that in point of time when we have sent all messages we have not received any of them. Thus we have exceeded the bound <I>B</I> for this buffer.</P>
-<p>
-</BODY>
Deleted: trunk/doc/help/deadlock/deadlock.html~
===================================================================
--- trunk/doc/help/deadlock/deadlock.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/deadlock/deadlock.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,31 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Deadlock</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Deadlock</H1>
-<P>is a property of a HMSC node. A reachable node is deadlocked if there is no reference node reachable from the node, i.e. after executing the BMSC referenced by a deadlocked node, there is no node to continue with.</P>
-
-<P>
-SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is given as an example of the deadlock.
-</P>
-
-<P>
-On the next picture the node B is clearly a deadlocked node. That is why it is highlited by SCStudio and given as an example.
-</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/deadlock.png" width="250" BORDER="0" ALT="Typical deadlock" TITLE="Typical deadlock"></li>
- <li>Typical deadlock</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
Deleted: trunk/doc/help/fifo/fifo.html~
===================================================================
--- trunk/doc/help/fifo/fifo.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/fifo/fifo.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,107 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>FIFO</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>FIFO (First In, First Out) property</H1>
-<P>is a BMSC property. The property ensures that it is possible
-to implement the desired behavior without deadlocks, that would be
-caused by channel behavior.</P>
-
-<P>
-There are several types of channels and several ways how they can be used in BMSC. Some of the most useful are the following:
-<ul>
-<li> FIFO channel for every pair of instances </li>
-<li> FIFO channel for every pair of instances and labels </li>
-<li> One FIFO channel for every process </li>
-<li> One FIFO channel for all processes </li>
-</ul>
-
-The SCStudio currently supports the first two options. The extension for other options is planned.
-</P>
-
-<H2>Basic Message Sequence Chart</H2>
-<H3>FIFO channel for every pair of instances </H3>
-<P>FIFO property is violated when there are two
-messages, such that they share a common source and destination
-instance and the latter message may arrive before the first one.</p>
-<p> Imagine we have a system in an all-channel FIFO environment which behaves according to a BMSC specification. A process expects the messages to arrive in some order, according to specification, but the messages might have been sent in a different order. A deadlock is reached as there might be a different message in the head of the channel queue.
-</P>
-<P>An example of a non-FIFO design can be seen on the
-next picture. Message <I>m1</I> is sent before <I>m2</I>, but
-instance <I>q</I> receives message <I>m2</I> before <I>m1. </I>Because
-we are having a FIFO channel between instances <I>p</I> and <I>q</I>,
-this is not possible and leads to a deadlock.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/simple_non_fifo.png" width="250" BORDER="0" ALT="Example of a non-fifo design" TITLE="Example of a non-fifo design"></li>
- <li>Example of a non-FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<h4>Formal definition:</h4>
-<P>BMSC is FIFO if for all receive events <I>c</I>, <I>d</I> and their matching send events
-<I>a, b</I> (<<I>a,c</I>> forms the first message and <<I>b,d</I>> forms the second message) it holds that
-<I>c < d => a < b</I>, where < is the visual order and the two messages belong
-to the same channel.</P>
-<P>On the next picture we can see tricky examples of FIFO BMSCs. They satisfy the FIFO property, because the receive events of both messages are in coregion. This means that the user has specified that the receive events can happen in an arbitrary order. So that if there is any order of these two events in the head of the channel queue, the system will certainly not reach deadlock.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/fifo1.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li>Example of a FIFO design</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/fifo2.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li>Example of a different FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-<P>An example of a non-FIFO design can be seen on the following picture. This is because the <I>Instance q</I> can execute only the receive event of message <I>m1</I> and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and messege <I>m2</I> is behind it. </P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/nonfifo1.png" width="250" BORDER="0" ALT="non-fifo design" TITLE="non-fifo design"></li>
- <li>Example of a non-FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<H3>FIFO channel for every pair of instances and labels</H3>
-<P>In this case we can have more than one FIFO channel between two processes. For every label there is one channel. Everything what has satisfied FIFO property in the previous case, will satisfy the property also in this case. The difference can be seen on the following FIFO example:</P>
-
-<img src="pictures/label_channel_fifo.png" border="0" alt="FIFO MSC design" title="FIFO MSC design">
-
-<P>Messages <I>m2</I> and <I>m1</I> are not in the same channel, therefore they may arrive in
-any order.</P>
-<!-- comment
-<H3>One FIFO buffer for every process</H3>
-<P>TODO, wait until implementation is done</P>
-<H3>One FIFO buffer for all processes</H3>
-<P>TODO, wait until implementation is done</P>
--->
-<H2>High-level Message Sequence Chart</H2>
-<P>HMSC satisfies FIFO property for a certain channel
-type, if every BMSC represented by the HMSC satisfies the FIFO property
-for that channel type.</P>
-</BODY>
-</HTML>
Deleted: trunk/doc/help/frontend/shortcuts.html~
===================================================================
--- trunk/doc/help/frontend/shortcuts.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/frontend/shortcuts.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,21 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<title>SCStudio Visio addon keyboard accelerators</title>
-<link href="../help.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<h1>Visio addon keyboard accelerators</h1>
-<p>The following keyboard accelerators are defined by SCStudio Visio addon:</p>
-<table>
-<col width="100"> <col>
-<tr><td><code>Ctrl+Alt+I</code></td><td><a href="shape-selection.html">Select all instances</a></td></tr>
-<tr><td><code>Ctrl+Alt+M</code></td><td><a href="shape-selection.html">Select all message</a></td></tr>
-<tr><td><code>Ctrl+Alt+F</code></td><td><a href="automatic-drawing.html#add_instances">Add instances</a></td></tr>
-<tr><td><code>Ctrl+Alt+S</code></td><td><a href="automatic-drawing.html#message_sequence">Message sequence</a></td></tr>
-<tr><td><code>Ctrl+Alt+E</code></td><td><a href="message-numbering.html">Message Numbering</a></td></tr>
-<tr><td><code>Ctrl+Alt+D</code></td><td><a href="message-numbering.html">Delete message numbering</a></td></tr>
-</table>
-
-</body>
-</html>
Deleted: trunk/doc/help/livelock/livelock.html~
===================================================================
--- trunk/doc/help/livelock/livelock.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/livelock/livelock.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,25 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Livelock</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Livelock</H1>
-<P>is a property of an HMSC. An HMSC contains a livelock if there exists a cycle of nodes from which no endnode is reachable. It is required that the cycle contains at least one reference node.</P>
-
-<P>SCStudio finds and displays all such cycles in a given HMSC.</P>
-<P> An example of livelock is depicted on the next picture. It clearly satisfies all conditions for livelock.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/livelock.png" width="450" BORDER="0" ALT="Typical livelock" TITLE="Typical livelock"></li>
- <li>Typical livelock</li>
- </ul>
-</li>
-</ul>
-</div>
-</BODY>
Deleted: trunk/doc/help/localchoice/localchoice.html~
===================================================================
--- trunk/doc/help/localchoice/localchoice.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/localchoice/localchoice.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,72 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Non-local choice</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Non-local choice</H1>
-<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches <I>MSC A</I> or <I>MSC B</I>) are possible and the branches are initiated by different instances (<I>MSC A</I> is initiated by the <I>Instance p</I>, <I>MSC B</I> is initiated by the <I>Instance q</I>). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/simple_nonlocal.png" width="550" BORDER="0" ALT="HMSC specification with a branching node" TITLE="HMSC specification with a branching node"></li>
- <li>HMSC specification with a branching node</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/simple_nonlocal_MSCA.png" width="200" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li>MSC A</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/simple_nonlocal_MSCB.png" width="200" BORDER="0" ALT="MSC B" TITLE="MSC B"></li>
- <li>MSC B</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-More formally, a branching node is called a non-local choice if one of the conditions is satisfied:</P>
-<UL>
-<LI> There exists a branch that is initiated by more than one instance.</LI>
-<LI> There exist two branches, such that each is initiated by different instance</LI>.
-</UL>
-
-<P>The result of the check on the previous example marks the non-local choice node with the red color:</P>
-
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/simple_nonlocal_result.png" width="350" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio"></li>
- <li>Result of SCStudio</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/simple_nonlocal_implied.png" width="200" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior"></li>
- <li>Implied behavior</li>
- </ul>
-</li>
-</ul>
-</div>
-
-
-<DIV class="gallery vary">
-<table><caption align="bottom"><i>Result of SCStudio</i></caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_result.png" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio">
-</tr></td></table>
-<DIV class="gallery vary">
-<table><caption align="bottom"><i>Implied behavior</i></caption><tr><td>
-<IMG SRC="pictures/simple_nonlocal_implied.png" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior">
-</tr></td></table>
-</BODY>
Deleted: trunk/doc/help/membership/membership.html~
===================================================================
--- trunk/doc/help/membership/membership.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/membership/membership.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,135 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>membership documentation</TITLE>
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR" STYLE="border: none; padding: 0in">
-<h1>Membership</FONT></h1>
-<P >The problem of
-membership is deciding whether given BMSC is contained in a given HMSC.
-It is possible to check both untimed and timed cases of BMSCs and
-HMSCs.<BR></P>
-<h3>Example 1:</h3>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/memebership_4.png" width="250" BORDER="0" ALT="Input bMSC" TITLE="Input bMSC"></li>
- <li>Input BMSC</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_1.png" width="150" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_2.png" width="250" BORDER="0" ALT="bMSC01" TITLE="bMSC01"></li>
- <li>bMSC01</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_3.png" width="250" BORDER="0" ALT="bMSC02" TITLE="bMSC02"></li>
- <li>bMSC02</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-In the figure above we
-have specified an input to the membership problem. Every path from the
-initial node to the terminal node in a HMSC represents a BMSC. There is
-only one path in the <i>Input HMSC</i>. The BMSC specified by the path is
-formed from nodes (BMSCs) on the path by the sequential composition
-(putting the BMSCs one after the other and gluing the matching
-process lines). It is easy to see that the <i>Input BMSC</i> is exactly the
-same BMSC represented by the only path in the <i>Input HMSC</i>. The result of
-procedure solving membership problem should be every successful path
-i.e. <i>Input HMSC</i>.</P>
-<P >More formal
-specification of the procedure:</P>
-<P >Input:
-</P>
-<UL>
- <LI><P >BMSC with the timing
- assignment</P>
- <LI><P >MSC with timers
- and time constraints (both HMSC constraints and BMSC
- constraints may be present in an HMSC)</P>
-</UL>
-<P >Output: graph of nodes
-and edges between initial and terminal vertex in the input HMSC
-representing the possible paths in the HMSC. The paths, after
-sequential composition, form a set of BMSCs with time constraints.
-The input BMSC satisfies all the time constraints in every one of the
-BMSCs formed by paths from the start to the end node of the graph.</P>
-<h3>Example 2:</h3>
-
-<div style="margin: 0 auto;">
-<ul class="gallery">
-<li>
- <ul>
- <li><IMG SRC="pictures/memebership_11.png" width="250" BORDER="0" ALT="Input BMSC" TITLE="Input BMSC"></li>
- <li>Input BMSC</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_5.png" width="450" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_6.png" width="250" BORDER="0" ALT="bMSC1" TITLE="bMSC1"></li>
- <li>bMSC1</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_7.png" width="250" BORDER="0" ALT="bMSC2" TITLE="bMSC2"></li>
- <li>bMSC2</li>
- </ul>
-</li>
-<li>
- <ul>
- <li><IMG SRC="pictures/memebership_8.png" width="250" BORDER="0" ALT="bMSC3" TITLE="bMSC3"></li>
- <li>bMSC3</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_9.png" width="250" BORDER="0" ALT="bMSC4" TITLE="bMSC4"></li>
- <li>bMSC4</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_10.png" width="250" BORDER="0" ALT="bMSC5" TITLE="bMSC5"></li>
- <li>bMSC5</li>
- </ul>
-</li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/memebership_12.png" width="450" BORDER="0" ALT="Result HMSC" TITLE="Result HMSC"></li>
- <li>Result HMSC</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<P style="clear: both;">In the result there are only two paths through the <i>Input HMSC</i>. This is because only these two paths form BMSCs, which are satisfied by the <i>Input BMSC</i>. The path through <i>BMSC4</i> forms BMSC which is not satisfied by the <i>Input BMSC</i>. This is because the difference between send times of messages with caption <I>q</I> is 2, what is not included in time interval [8,9). Also there are only two possible iterations of the cycle containing <i>BMSC2</i>, because there are only two messages with caption <I>q</I> in the <i>Input BMSC</i>.</P>
-</BODY>
-</HTML>
Deleted: trunk/doc/help/time_consistency/time_consistency.html~
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/time_consistency/time_consistency.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,44 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Time Consistency</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Time Consistency</H1>
-<P>Time consistency is a problem of deciding whether introduced time constraints in a given MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
-<p> The motivation for time consitency is following. It can easily happen that user can specify too restrictive time constraints and cause that the set of behaviors is empty. The time consistency property checks such situations.
-<H2>Basic Message Sequence Chart</H2>
-<P>Time consistent property is violated for BMSC <I>B</I> when there is no valid time assignment for B.</P>
-<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event, such that it satisfies all constraints in a given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
-<P>An example of a time consistent BMSC is depicted on the next picture.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/cons1.png" width="250" BORDER="0" ALT="Time inconsistent BMSC" TITLE="Time inconsistent BMSC"></li>
- <li>Time inconsistent BMSC</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-<H2>High-level MSC</H2>
-
-<P>HMSC violates time consistent property if exists path from start node to end node for which there is no time assignment.</P>
-<P>An example of time inconsistent HMSC is depicted on the next picture. The inconsistency follows from the fact that the two inner constraints are too short compared to the outer constraint. That is why it is not possible for the events in the HMSC to satisfy all constraints.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/cons2.png" width="250" BORDER="0" ALT="Time inconsistent HMSC" TITLE="Time inconsistent HMSC"></li>
- <li>Time inconsistent HMSC</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
-</HTML>
Deleted: trunk/doc/help/time_syntax/time_syntax.html~
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html~ 2010-09-07 09:03:38 UTC (rev 877)
+++ trunk/doc/help/time_syntax/time_syntax.html~ 2010-09-07 10:14:23 UTC (rev 878)
@@ -1,61 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Correct Time Constraint Syntax</TITLE>
- <meta name="author" content="Lubos Korenciak">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Correct Time Constraint Syntax</H1>
-<P>The correct time constraint syntax algorithm is used for checking whether introduced time constraints are correct to use in SCStudio. The main motivation for such test is to rule out time constraints which are either not allowed by the standard or ambiguous.
-</P>
-<P>The following conditions must hold for every time constraint to suffice correct time constraint syntax algorithm:
-<ul>
-<li>if the constraint is in BMSC it has to restrict events which are visually ordered </li>
-<li>if the constraint is in HMSC and it restricts nodes A and B, every path going through A (resp. B) must go through B (resp. A) and it cannot go twice through A (resp. B) without going through node B (resp. A) in between.</li>
-</ul> </p>
-
-<P>An example of a time constraint can be seen on the next picture. Receive events of <I>HTTP Response</I> and send event <I>HTTP Request</I> messages are not visually ordered. Thus the time constraint does not satisfy the correct time constraint syntax property. </P>
-
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/syntax3.png" width="350" BORDER="0" ALT="Example of a wrong time constraint" TITLE="Example of a wrong time constraint"></li>
- <li>Example of a wrong time constraint</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-
-<P>On the next picture we see that there exists path which goes twice in a row through the node <I>Connection denied</I> and thus the introduced time constraint also does not satisfy the correct time constraint syntax property.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/syntax1.png" width="250" BORDER="0" ALT="Violation of constraint syntax" TITLE="Violation of constraint syntax"></li>
- <li>Violation of constraint syntax</li>
- </ul></li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-<P>The last example depicts a HMSC wher...
[truncated message content] |
|
From: <ag...@us...> - 2010-09-08 07:30:47
|
Revision: 885
http://scstudio.svn.sourceforge.net/scstudio/?rev=885&view=rev
Author: agmy
Date: 2010-09-08 07:30:40 +0000 (Wed, 08 Sep 2010)
Log Message:
-----------
help, added unique instacne, non-recursivity, improved race, fixed non local choice
Modified Paths:
--------------
trunk/doc/help/algorithms.html
trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCB.png
trunk/doc/help/race/race.html
Added Paths:
-----------
trunk/doc/help/race/pictures/
trunk/doc/help/race/pictures/easyrace_1.png
trunk/doc/help/race/pictures/easyrace_2.png
trunk/doc/help/race/pictures/easyrace_result.png
trunk/doc/help/race/pictures/trickyrace_1.png
trunk/doc/help/race/pictures/trickyrace_2.png
trunk/doc/help/race/pictures/trickyrace_3.png
trunk/doc/help/recursivity/
trunk/doc/help/recursivity/pictures/
trunk/doc/help/recursivity/pictures/recursivity.vsd
trunk/doc/help/recursivity/pictures/recursivity1.png
trunk/doc/help/recursivity/pictures/recursivity2.png
trunk/doc/help/recursivity/pictures/recursivity3.png
trunk/doc/help/recursivity/recursivity.html
trunk/doc/help/unique_instance/
trunk/doc/help/unique_instance/pictures/
trunk/doc/help/unique_instance/pictures/uniqueinstance.png
trunk/doc/help/unique_instance/pictures/uniqueinstance.vsd
trunk/doc/help/unique_instance/pictures/uniqueinstance2.png
trunk/doc/help/unique_instance/unique_instance.html
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-07 22:14:50 UTC (rev 884)
+++ trunk/doc/help/algorithms.html 2010-09-08 07:30:40 UTC (rev 885)
@@ -13,7 +13,7 @@
<li><a href="fifo/fifo.html">FIFO property</a></li>
<li><a href="race/race.html">Race Condition</a></li>
<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
-<li>Unique instance names</li>
+<li><a href="unique_instance/unique_instance.html">Unique instance names</a></li>
</ul>
<h2>HMSC</h2>
@@ -25,7 +25,7 @@
<li><a href="membership/membership.html">Membership</a></li>
<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
<li><a href="realizability/realizability.html">Strong Realizablilty</a></li>
-<li>Non-recursivity</li>
+<li><a href="recursivity/recursivity.html">Non-recursivity</li>
<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
<li><a href="time_trace_race/time_race.html">Time Race</a></li>
<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
Modified: trunk/doc/help/localchoice/pictures/simple_nonlocal_MSCB.png
===================================================================
(Binary files differ)
Added: trunk/doc/help/race/pictures/easyrace_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/easyrace_1.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/race/pictures/easyrace_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/easyrace_2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/race/pictures/easyrace_result.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/easyrace_result.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/race/pictures/trickyrace_1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/trickyrace_1.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/race/pictures/trickyrace_2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/trickyrace_2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/race/pictures/trickyrace_3.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/race/pictures/trickyrace_3.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-09-07 22:14:50 UTC (rev 884)
+++ trunk/doc/help/race/race.html 2010-09-08 07:30:40 UTC (rev 885)
@@ -9,7 +9,54 @@
<BODY>
<H1>Race Condition</H1>
<P>Race Condition occurs in an BMSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for MSCs that satisfy FIFO.</P>
-<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence.</P>
+<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. On the next picture there is an example of an BMSC which contains race condition:
-<P>On the next picture there is an example of an BMSC which contains race condition. The receive events of messages ... but it is possibele that...</P>
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/easyrace_1.png" width="300" BORDER="0" ALT="Input BMSC" TITLE="Input BMSC"></li>
+ <li>Input BMSC</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/easyrace_2.png" width="300" BORDER="0" ALT="Possible execution" TITLE="Possible execution"></li>
+ <li>Possible execution</li>
+ </ul>
+</li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/easyrace_result.png" width="300" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result"></li>
+ <li>SCStudio result</li>
+ </ul>
+</li>
+</ul>
+</div>
+<p style="clear: both;">
+The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence:</P>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/trickyrace_1.png" width="100" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
+ <li>Input HMSC with a race</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/trickyrace_2.png" width="300" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
+ <li>MSC A</li>
+ </ul>
+</li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/trickyrace_3.png" width="300" BORDER="0" ALT="MSC B" TITLE="MSC B"></li>
+ <li>MSC B</li>
+ </ul>
+</li>
+</ul>
+</div>
+
</BODY>
Added: trunk/doc/help/recursivity/pictures/recursivity.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/recursivity/pictures/recursivity.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/recursivity/pictures/recursivity1.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/recursivity/pictures/recursivity1.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/recursivity/pictures/recursivity2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/recursivity/pictures/recursivity2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/recursivity/pictures/recursivity3.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/recursivity/pictures/recursivity3.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/recursivity/recursivity.html
===================================================================
--- trunk/doc/help/recursivity/recursivity.html (rev 0)
+++ trunk/doc/help/recursivity/recursivity.html 2010-09-08 07:30:40 UTC (rev 885)
@@ -0,0 +1,39 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Acyclic property</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Non recursivity</H1>
+<P> ensures that no HMSC can reference itself (even indirectly). By this condition no infinite unfolding of HMSCs is allowed. Infinite behaviors should be achieved by using cycles, not by using recursion.</P>
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/recursivity1.png" width="150" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
+ <li>Input HMSC</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/recursivity2.png" width="150" BORDER="0" ALT="HMSC A violating non recursivity" TITLE="HMSC A violating non recursivity"></li>
+ <li>HMSC A violating non recursivity</li>
+ </ul>
+</li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/recursivity3.png" width="150" BORDER="0" ALT="Non recursive HMSC" TITLE="Non recursive HMSC"></li>
+ <li>Non recursive HMSC</li>
+ </ul>
+</li>
+
+</ul>
+</div>
+
+
+<p style="clear: both;">
+
+</BODY>
\ No newline at end of file
Property changes on: trunk/doc/help/recursivity/recursivity.html
___________________________________________________________________
Added: svn:executable
+ *
Added: trunk/doc/help/unique_instance/pictures/uniqueinstance.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/unique_instance/pictures/uniqueinstance.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/unique_instance/pictures/uniqueinstance.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/unique_instance/pictures/uniqueinstance.vsd
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/unique_instance/pictures/uniqueinstance2.png
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/unique_instance/pictures/uniqueinstance2.png
___________________________________________________________________
Added: svn:executable
+ *
Added: svn:mime-type
+ application/octet-stream
Added: trunk/doc/help/unique_instance/unique_instance.html
===================================================================
--- trunk/doc/help/unique_instance/unique_instance.html (rev 0)
+++ trunk/doc/help/unique_instance/unique_instance.html 2010-09-08 07:30:40 UTC (rev 885)
@@ -0,0 +1,31 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>Acyclic property</TITLE>
+ <meta name="author" content="Martin Chmelik">
+ <LINK href="../help.css" rel="stylesheet" type="text/css"/>
+</HEAD>
+<BODY>
+<H1>Unique instance names</H1>
+<P> ensures that there are no two instances with the same name within a BMSC.</P>
+
+<div style="margin: 0 auto;">
+<ul class="gallery"><li>
+ <ul>
+ <li><IMG SRC="pictures/uniqueinstance.png" width="350" BORDER="0" ALT="BMSC violating unique instance names" TITLE="BMSC violating unique instance names"></li>
+ <li>BMSC violating unique instance names</li>
+ </ul></li>
+<li>
+ <ul>
+
+ <li><IMG SRC="pictures/uniqueinstance2.png" width="350" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result"></li>
+ <li>SCStudio result</li>
+ </ul>
+</li>
+</ul>
+</div>
+
+<p style="clear: both;">
+
+</BODY>
\ No newline at end of file
Property changes on: trunk/doc/help/unique_instance/unique_instance.html
___________________________________________________________________
Added: svn:executable
+ *
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ag...@us...> - 2010-09-08 08:32:59
|
Revision: 887
http://scstudio.svn.sourceforge.net/scstudio/?rev=887&view=rev
Author: agmy
Date: 2010-09-08 08:32:49 +0000 (Wed, 08 Sep 2010)
Log Message:
-----------
help, improved picture spacing
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/algorithms.html
trunk/doc/help/beautify/beautify.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/help.css
trunk/doc/help/livelock/livelock.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/membership/membership.html
trunk/doc/help/race/race.html
trunk/doc/help/recursivity/recursivity.html
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
trunk/doc/help/unique_instance/unique_instance.html
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/acyclic/acyclic.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -15,13 +15,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/cyclic_simple.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li>Cyclic design</li>
+ <li class="caption">Cyclic design</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/cyclic_result.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li>Highlighted cyclic dependency</li>
+ <li class="caption">Highlighted cyclic dependency</li>
</ul>
</li>
</ul>
@@ -37,7 +37,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/acyclic.png" width="250" BORDER="0" ALT="Acyclic BMSC" TITLE="Acyclic BMSC"></li>
- <li>Acyclic design</li>
+ <li class="caption">Acyclic design</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/algorithms.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -5,20 +5,13 @@
<h1>Algorithms</h1>
-
-<h2>BMSC</h2>
-The following verification algorithms for BMSC are supported:
+The following verification algorithms are supported:
<ul>
<li><a href="acyclic/acyclic.html">Acyclic property</a></li>
<li><a href="fifo/fifo.html">FIFO property</a></li>
<li><a href="race/race.html">Race Condition</a></li>
<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
<li><a href="unique_instance/unique_instance.html">Unique instance names</a></li>
-</ul>
-
-<h2>HMSC</h2>
-The following verification algorithms for HMSC are supported:
-<ul>
<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
<li><a href="deadlock/deadlock.html">Deadlock</a></li>
<li><a href="livelock/livelock.html">Livelock</a></li>
@@ -32,7 +25,7 @@
<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
</ul>
-<h2>Frontend</h2>
+<h1>Frontend</h1>
<ul>
<li><a href="beautify/beautify.html">Beautify</a></li>
<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
Modified: trunk/doc/help/beautify/beautify.html
===================================================================
--- trunk/doc/help/beautify/beautify.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/beautify/beautify.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -22,13 +22,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/unordered.png" width="500" BORDER="0" ALT="Unordered BMSC"></li>
- <li>Before beautify</li>
+ <li class="caption">Before beautify</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/ordered.png" align="middle" width="350" BORDER="0" ALT="Ordered BMSC"></li>
- <li>After beautify</li>
+ <li class="caption">After beautify</li>
</ul>
</li>
</ul>
@@ -43,7 +43,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/unfifo2.png" width="250" BORDER="0" ALT="Ordered non-FIFO BMSC"></li>
- <li>Acyclic design</li>
+ <li class="caption">Acyclic design</li>
</ul>
</li>
</ul>
@@ -61,14 +61,14 @@
<ul>
<li>
<img src="pictures/coregion1.png" width="250" alt="Crossing messages jointed with coregion"></li>
- <li>Before beautify</li>
+ <li class="caption">Before beautify</li>
</ul></li>
<li>
<ul>
<li>
<img src="pictures/coregion2.png" width="250 "alt=""></li>
- <li>After beautify</li>
+ <li class="caption">After beautify</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/boundedness/boundedness.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -17,13 +17,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/unbounded_hmsc.png" width="200" BORDER="0" ALT="Unbounded HMSC" TITLE="Unbounded HMSC"></li>
- <li>Unbounded HMSC</li>
+ <li class="caption">Unbounded HMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/unbounded_msc.png" width="250" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li>MSC A</li>
+ <li class="caption">MSC A</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/deadlock/deadlock.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -22,7 +22,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/deadlock.png" width="350" BORDER="0" ALT="Typical deadlock" TITLE="Typical deadlock"></li>
- <li>Typical deadlock</li>
+ <li class="caption">Typical deadlock</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/fifo/fifo.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -41,7 +41,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/simple_non_fifo.png" width="250" BORDER="0" ALT="Example of a non-fifo design" TITLE="Example of a non-fifo design"></li>
- <li>Example of a non-FIFO design</li>
+ <li class="caption">Example of a non-FIFO design</li>
</ul>
</li>
</ul>
@@ -59,13 +59,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/fifo1.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li>Example of a FIFO design</li>
+ <li class="caption">Example of a FIFO design</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/fifo2.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li>Example of a different FIFO design</li>
+ <li class="caption">Example of a different FIFO design</li>
</ul>
</li>
</ul>
@@ -79,7 +79,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/nonfifo1.png" width="250" BORDER="0" ALT="non-fifo design" TITLE="non-fifo design"></li>
- <li>Example of a non-FIFO design</li>
+ <li class="caption">Example of a non-FIFO design</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/help.css
===================================================================
--- trunk/doc/help/help.css 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/help.css 2010-09-08 08:32:49 UTC (rev 887)
@@ -32,3 +32,7 @@
ul.gallery { clear: both; }
ul.gallery li { list-style-type: none; float: left; }
ul.gallery li ul li { float: none; text-align: center; font-size: 15px; }
+ul.gallery li ul li.caption { margin-top:10px; float: none; text-align: center; font-size: 15px; }
+
+
+ul.gallery ul { padding:20px; margin:20px; border:1px #B4B4B4 solid;}
Modified: trunk/doc/help/livelock/livelock.html
===================================================================
--- trunk/doc/help/livelock/livelock.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/livelock/livelock.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -17,7 +17,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/livelock.png" width="450" BORDER="0" ALT="Typical livelock" TITLE="Typical livelock"></li>
- <li>Typical livelock</li>
+ <li class="caption">Typical livelock</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/localchoice/localchoice.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -14,20 +14,20 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/simple_nonlocal.png" width="550" BORDER="0" ALT="HMSC specification with a branching node" TITLE="HMSC specification with a branching node"></li>
- <li>HMSC specification with a branching node</li>
+ <li class="caption">HMSC specification with a branching node</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/simple_nonlocal_MSCA.png" width="200" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li>MSC A</li>
+ <li class="caption">MSC A</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/simple_nonlocal_MSCB.png" width="200" BORDER="0" ALT="MSC B" TITLE="MSC B"></li>
- <li>MSC B</li>
+ <li class="caption">MSC B</li>
</ul>
</li>
</ul>
@@ -48,13 +48,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/simple_nonlocal_result.png" width="350" BORDER="0" ALT="Result of SCStudio" TITLE="Result of SCStudio"></li>
- <li>Result of SCStudio</li>
+ <li class="caption">Result of SCStudio</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/simple_nonlocal_implied.png" width="200" BORDER="0" ALT="Implied behavior" TITLE="Implied behavior"></li>
- <li>Implied behavior</li>
+ <li class="caption">Implied behavior</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/membership/membership.html
===================================================================
--- trunk/doc/help/membership/membership.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/membership/membership.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -17,27 +17,27 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/memebership_4.png" width="250" BORDER="0" ALT="Input bMSC" TITLE="Input bMSC"></li>
- <li>Input BMSC</li>
+ <li class="caption">Input BMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_1.png" width="150" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC</li>
+ <li class="caption">Input HMSC</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_2.png" width="250" BORDER="0" ALT="bMSC01" TITLE="bMSC01"></li>
- <li>bMSC01</li>
+ <li class="caption">bMSC01</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_3.png" width="250" BORDER="0" ALT="bMSC02" TITLE="bMSC02"></li>
- <li>bMSC02</li>
+ <li class="caption">bMSC02</li>
</ul>
</li>
</ul>
@@ -78,53 +78,53 @@
<li>
<ul>
<li><IMG SRC="pictures/memebership_11.png" width="250" BORDER="0" ALT="Input BMSC" TITLE="Input BMSC"></li>
- <li>Input BMSC</li>
+ <li class="caption">Input BMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_5.png" width="450" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC</li>
+ <li class="caption">Input HMSC</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_6.png" width="250" BORDER="0" ALT="bMSC1" TITLE="bMSC1"></li>
- <li>bMSC1</li>
+ <li class="caption">bMSC1</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_7.png" width="250" BORDER="0" ALT="bMSC2" TITLE="bMSC2"></li>
- <li>bMSC2</li>
+ <li class="caption">bMSC2</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_8.png" width="250" BORDER="0" ALT="bMSC3" TITLE="bMSC3"></li>
- <li>bMSC3</li>
+ <li class="caption">bMSC3</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_9.png" width="250" BORDER="0" ALT="bMSC4" TITLE="bMSC4"></li>
- <li>bMSC4</li>
+ <li class="caption">bMSC4</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_10.png" width="250" BORDER="0" ALT="bMSC5" TITLE="bMSC5"></li>
- <li>bMSC5</li>
+ <li class="caption">bMSC5</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/memebership_12.png" width="350" BORDER="0" ALT="Result HMSC" TITLE="Result HMSC"></li>
- <li>Result HMSC</li>
+ <li class="caption">Result HMSC</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/race/race.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -8,52 +8,54 @@
</HEAD>
<BODY>
<H1>Race Condition</H1>
-<P>Race Condition occurs in an BMSC if a pair of events is drawn in a particular order but the events may occur in the other order during an execution of the MSC. If the real implementation is based on the drawing, it may lead to a system failure. Please don't mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for MSCs that satisfy FIFO.</P>
-<P>SCStudio currently finds all such pairs of events in a given BMSC and also in BMSCs referenced by a HMSC. On the next picture there is an example of an BMSC which contains race condition:
+<P>
+Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in an inverse order.
+Race condition occurs in a BMSC whenever a pair of events is drawn in a particular order but there exists a execution with a different order. If the real implementation is based on the BMSC specification, it may lead to a system failure. Do not mix up race condition with <a href="../fifo/fifo.html">FIFO</a>; race condition is only applicable for BMSCs that satisfy FIFO.</P>
+<P>SCStudio finds all pairs of events in a given BMSC and also in BMSCs referenced by an HMSC. On the next picture there is an example of an BMSC which contains race condition:
<div style="margin: 0 auto;">
<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/easyrace_1.png" width="300" BORDER="0" ALT="Input BMSC" TITLE="Input BMSC"></li>
- <li>Input BMSC</li>
+ <ul >
+ <li><IMG SRC="pictures/easyrace_1.png" width="300" BORDER="0" ALT="Input BMSC" TITLE="Input BMSC"></li>
+ <li class="caption">Input BMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/easyrace_2.png" width="300" BORDER="0" ALT="Possible execution" TITLE="Possible execution"></li>
- <li>Possible execution</li>
+ <li class="caption">Possible execution</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/easyrace_result.png" width="300" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result"></li>
- <li>SCStudio result</li>
+ <li class="caption">SCStudio result</li>
</ul>
</li>
</ul>
</div>
<p style="clear: both;">
-The race condition may also occur between events from different BMSC. SCStudio is capable of finding one such occurence:</P>
+The race condition may also occur between events from different BMSC within an HMSC. HMSC contains race if there exists path which contains a race. SCStudio is capable of finding one such occurence:</P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/trickyrace_1.png" width="100" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC with a race</li>
+ <li class="caption">Input HMSC with a race</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/trickyrace_2.png" width="300" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li>MSC A</li>
+ <li class="caption">MSC A</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/trickyrace_3.png" width="300" BORDER="0" ALT="MSC B" TITLE="MSC B"></li>
- <li>MSC B</li>
+ <li class="caption">MSC B</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/recursivity/recursivity.html
===================================================================
--- trunk/doc/help/recursivity/recursivity.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/recursivity/recursivity.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -13,20 +13,20 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/recursivity1.png" width="150" BORDER="0" ALT="Input HMSC" TITLE="Input HMSC"></li>
- <li>Input HMSC</li>
+ <li class="caption">Input HMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/recursivity2.png" width="150" BORDER="0" ALT="HMSC A violating non recursivity" TITLE="HMSC A violating non recursivity"></li>
- <li>HMSC A violating non recursivity</li>
+ <li class="caption">HMSC A violating non recursivity</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/recursivity3.png" width="150" BORDER="0" ALT="Non recursive HMSC" TITLE="Non recursive HMSC"></li>
- <li>Non recursive HMSC</li>
+ <li class="caption">Non recursive HMSC</li>
</ul>
</li>
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -19,7 +19,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/cons1.png" width="350" BORDER="0" ALT="Time inconsistent BMSC" TITLE="Time inconsistent BMSC"></li>
- <li>Time inconsistent BMSC</li>
+ <li class="caption">Time inconsistent BMSC</li>
</ul>
</li>
</ul>
@@ -34,7 +34,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/cons2.png" width="250" BORDER="0" ALT="Time inconsistent HMSC" TITLE="Time inconsistent HMSC"></li>
- <li>Time inconsistent HMSC</li>
+ <li class="caption">Time inconsistent HMSC</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/time_syntax/time_syntax.html
===================================================================
--- trunk/doc/help/time_syntax/time_syntax.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/time_syntax/time_syntax.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -23,7 +23,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/syntax3.png" width="350" BORDER="0" ALT="Example of a wrong time constraint" TITLE="Example of a wrong time constraint"></li>
- <li>Example of a wrong time constraint</li>
+ <li class="caption">Example of a wrong time constraint</li>
</ul>
</li>
</ul>
@@ -37,7 +37,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/syntax1.png" width="200" BORDER="0" ALT="Violation of constraint syntax" TITLE="Violation of constraint syntax"></li>
- <li>Violation of constraint syntax</li>
+ <li class="caption">Violation of constraint syntax</li>
</ul></li>
</ul>
</div>
@@ -50,7 +50,7 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/syntax2.png" width="350" BORDER="0" ALT="Example of a wrong time constraint" TITLE="Example of a wrong time constraint"></li>
- <li>Example of a wrong time constraint</li>
+ <li class="caption">Example of a wrong time constraint</li>
</ul></li>
</ul>
</div>
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -21,13 +21,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/tighten2_1.png" width="350" BORDER="0" ALT="Original BMSC" TITLE="Original BMSC"></li>
- <li>Original BMSC</li>
+ <li class="caption">Original BMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/tighten2_2.png" width="350" BORDER="0" ALT="Tightened BMSC" TITLE="Tightened BMSC"></li>
- <li>Tightened BMSC</li>
+ <li class="caption">Tightened BMSC</li>
</ul>
</li>
</ul>
@@ -52,20 +52,20 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/tighten1_1.png" width="350" BORDER="0" ALT="Original HMSC" TITLE="Original HMSC"></li>
- <li>Original HMSC</li>
+ <li class="caption">Original HMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/tighten1_2.png" width="250" BORDER="0" ALT="Original BMSC A" TITLE="Original BMSC A"></li>
- <li>Original BMSC A</li>
+ <li class="caption">Original BMSC A</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/tighten1_3.png" width="250" BORDER="0" ALT="Original BMSC B" TITLE="Original BMSC B"></li>
- <li>Original BMSC B</li>
+ <li class="caption">Original BMSC B</li>
</ul>
</li>
@@ -79,20 +79,20 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/tighten1_4.png" width="350" BORDER="0" ALT="Tightened HMSC" TITLE="Tightened HMSC"></li>
- <li>Tightened HMSC</li>
+ <li class="caption">Tightened HMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/tighten1_5.png" width="250" BORDER="0" ALT="Tightened BMSC A" TITLE="Tightened BMSC A"></li>
- <li>Tightened BMSC A</li>
+ <li class="caption">Tightened BMSC A</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/tighten1_6.png" width="250" BORDER="0" ALT="Tightened BMSC B" TITLE="Tightened BMSC B"></li>
- <li>Tightened BMSC B</li>
+ <li class="caption">Tightened BMSC B</li>
</ul>
</li>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -9,21 +9,20 @@
<BODY>
<H1>Time Race</H1>
-<P> Informally, two events are in race if they are specified by user to perform in some order, but there is a possibility that they can perform in inverse order.</P>
-<P> The introduction of time constraints can eliminate some race conditions. For example consider the next two pictures. On the first one there is a time race between <I>HTTP Request</I> and <I>HTTP Response</I> receive events. However on the second one the added time constraint caused that the BMSC is time race free (the receive event of <I>HTTP Request</I> surely happens after the <I>HTTP Response</I> receive event). </P>
+<P> The introduction of time constraints can eliminate some <a href="../race/race.html">race conditions</a>. For example consider the next two pictures. On the first one there is a time race between <I>HTTP Request</I> and <I>HTTP Response</I> receive events. However on the second one the added time constraint caused that the BMSC is time race free (the receive event of <I>HTTP Request</I> surely happens after the <I>HTTP Response</I> receive event). </P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/race1_1.png" width="350" BORDER="0" ALT="BMSC with the time race" TITLE="BMSC with the time race"></li>
- <li>BMSC with the time race</li>
+ <li class="caption">BMSC with the time race</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/race1_2.png" width="350" BORDER="0" ALT="Time race free BMSC" TITLE="Time race free BMSC"></li>
- <li>Time race free BMSC</li>
+ <li class="caption">Time race free BMSC</li>
</ul>
</li>
</ul>
@@ -41,20 +40,20 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/race2_1.png" width="250" BORDER="0" ALT="Example of time race free HMSC" TITLE="Example of time race free HMSC"></li>
- <li>Example of time race free HMSC</li>
+ <li class="caption">Example of time race free HMSC</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/race2_2.png" width="300" BORDER="0" ALT="BMSC A" TITLE="BMSC A"></li>
- <li>BMSC A</li>
+ <li class="caption">BMSC A</li>
</ul>
</li>
<li>
<ul>
<li><IMG SRC="pictures/race2_3.png" width="300" BORDER="0" ALT="BMSC B" TITLE="BMSC B"></li>
- <li>BMSC B</li>
+ <li class="caption">BMSC B</li>
</ul>
</li>
</ul>
Modified: trunk/doc/help/unique_instance/unique_instance.html
===================================================================
--- trunk/doc/help/unique_instance/unique_instance.html 2010-09-08 07:48:34 UTC (rev 886)
+++ trunk/doc/help/unique_instance/unique_instance.html 2010-09-08 08:32:49 UTC (rev 887)
@@ -14,13 +14,13 @@
<ul class="gallery"><li>
<ul>
<li><IMG SRC="pictures/uniqueinstance.png" width="350" BORDER="0" ALT="BMSC violating unique instance names" TITLE="BMSC violating unique instance names"></li>
- <li>BMSC violating unique instance names</li>
+ <li class="caption">BMSC violating unique instance names</li>
</ul></li>
<li>
<ul>
<li><IMG SRC="pictures/uniqueinstance2.png" width="350" BORDER="0" ALT="SCStudio result" TITLE="SCStudio result"></li>
- <li>SCStudio result</li>
+ <li class="caption">SCStudio result</li>
</ul>
</li>
</ul>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ag...@us...> - 2010-09-10 13:07:33
|
Revision: 910
http://scstudio.svn.sourceforge.net/scstudio/?rev=910&view=rev
Author: agmy
Date: 2010-09-10 13:07:27 +0000 (Fri, 10 Sep 2010)
Log Message:
-----------
Help improvements
Modified Paths:
--------------
trunk/doc/help/algorithms.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/frontend/automatic-drawing.html
trunk/doc/help/frontend/message-snapping.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/race/race.html
trunk/doc/help/time_consistency/pictures/cons1.png
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/algorithms.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -8,31 +8,45 @@
The following verification algorithms are supported:
<ul>
<li><a href="acyclic/acyclic.html">Acyclic property</a></li>
-<li><a href="fifo/fifo.html">FIFO property</a></li>
-<li><a href="race/race.html">Race Condition</a></li>
-<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
-<li><a href="unique_instance/unique_instance.html">Unique instance names</a></li>
<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
<li><a href="deadlock/deadlock.html">Deadlock</a></li>
+<li><a href="fifo/fifo.html">FIFO</a></li>
<li><a href="livelock/livelock.html">Livelock</a></li>
+<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
<li><a href="membership/membership.html">Membership</a></li>
-<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
-<li><a href="realizability/realizability.html">Strong Realizablilty</a></li>
+<li><a href="race/race.html">Race Condition</a></li>
+<li><a href="realizability/realizability.html">Strong Realizability</a></li>
<li><a href="recursivity/recursivity.html">Non-recursivity</li>
<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
+<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
<li><a href="time_trace_race/time_race.html">Time Race</a></li>
+<li><a href="unique_instance/unique_instance.html">Unique instance names</a></li>
+</ul>
+
+<h1>Transformers</h1>
+<ul>
+<li><a href="beautify/beautify.html">Beautify</a></li>
<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
-<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
</ul>
<h1>Frontend</h1>
+
+<p>Currently, the SCStudio frontend is accessible as a Microsoft Visio addon.
+Thus, Microsoft Visio 2003 or 2007 must be installed prior to installing
+SCStudio.</p>
+<p>When an MSC document is opened, the Sequence Chart Studio toolbar and menu Check
+are available:</p>
+<img class="big" src="frontend/pictures/frontend.png" alt="SCStudio toolbar and menu in MS Visio">
+
+<p>SCStudio functions extending Visio are divided into the following categories:</p>
<ul>
-<li><a href="beautify/beautify.html">Beautify</a></li>
<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
<li><a href="frontend/message-numbering.html">Message numbering</a></li>
<li><a href="frontend/message-snapping.html">Message snapping</a></li>
<li><a href="frontend/shape-selection.html">Shape selection</a></li>
-<li><a href="frontend/shortcuts.html">Shortcuts</a></li>
</ul>
-</body>
+
+<p>Many SCStudio functions define their own keyboard accelerators.
+See the <a href="frontend/shortcuts.html">keyboard accelerators</a> section to
+list all of them.</p></body>
</html>
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/boundedness/boundedness.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper bound on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialogue is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
+<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper bound on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialog is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
<P>When all the possible executions of an HMSC are finite, then HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
<P>The HMSC on the following picture is unbounded. This is because there is no mechanism for keeping the buffer for messages between <I>X</I> and <I>Y</I> bounded. </P>
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/deadlock/deadlock.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -15,7 +15,7 @@
</P>
<P>
-On the next picture the node B is clearly a deadlocked node. That is why it is highlited by SCStudio and given as an example.
+On the next picture the node B is clearly a deadlocked node. That is why it is highlighted by SCStudio and given as an example.
</P>
<div style="margin: 0 auto;">
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/fifo/fifo.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -73,7 +73,7 @@
<p style="clear: both;">
-<P>An example of a non-FIFO design can be seen on the following picture. This is because the <I>Instance q</I> can execute only the receive event of message <I>m1</I> and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and messege <I>m2</I> is behind it. </P>
+<P>An example of a non-FIFO design can be seen on the following picture. This is because the <I>Instance q</I> can execute only the receive event of message <I>m1</I> and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and message <I>m2</I> is behind it. </P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
Modified: trunk/doc/help/frontend/automatic-drawing.html
===================================================================
--- trunk/doc/help/frontend/automatic-drawing.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/frontend/automatic-drawing.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -34,7 +34,7 @@
<h2 id="message_sequence">Message Sequence</h2>
<p>The Message Sequence function draws a sequence of messages among selected instances.
The basic usage is that when one instance sends a message, which is received and
-resent by several other instances and finally received by the last instance, as ilustrated
+resent by several other instances and finally received by the last instance, as illustrated
in the following picture.</p>
<img src="pictures/message_sequence.png" alt="Message Sequence example">
<p>The Message Sequence function is accessible via menu
Modified: trunk/doc/help/frontend/message-snapping.html
===================================================================
--- trunk/doc/help/frontend/message-snapping.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/frontend/message-snapping.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -23,7 +23,7 @@
<p>
When the message is already dropped on the page, user can still use snapping. As the message is moved, it automatically snaps to the nearest instance(s) (if exists). Since the message can be oblique, three types of snapping are provided:<br><br>
<code>straighten</code><br>
- - the message is straigten on the current location of the mouse cursor and snapped to instance(s).<br>
+ - the message is straighten on the current location of the mouse cursor and snapped to instance(s).<br>
<code>preserve vertical distance between send - receive</code><br>
- endpoint(s) of the message are horizontally stretched and snapped to the nearest instance(s).<br>
<code>preserve slope</code><br>
Modified: trunk/doc/help/localchoice/localchoice.html
===================================================================
--- trunk/doc/help/localchoice/localchoice.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/localchoice/localchoice.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -8,7 +8,7 @@
</HEAD>
<BODY>
<H1>Non-local choice</H1>
-<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches <I>MSC A</I> or <I>MSC B</I>) are possible and the branches are initiated by different instances (<I>MSC A</I> is initiated by the <I>Instance p</I>, <I>MSC B</I> is initiated by the <I>Instance q</I>). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a nonspecified implied behavior. </P>
+<P>is a property of an HMSC node, that has more than one successor, occurring when multiple different behaviors (branches <I>MSC A</I> or <I>MSC B</I>) are possible and the branches are initiated by different instances (<I>MSC A</I> is initiated by the <I>Instance p</I>, <I>MSC B</I> is initiated by the <I>Instance q</I>). Therefore the resulting behavior of the system may contain a combination of both branches, resulting in a non specified implied behavior. </P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
Modified: trunk/doc/help/race/race.html
===================================================================
--- trunk/doc/help/race/race.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/race/race.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -36,7 +36,7 @@
</ul>
</div>
<p style="clear: both;">
-The race condition may also occur between events from different BMSC within an HMSC. HMSC contains race if there exists path which contains a race. SCStudio is capable of finding one such occurence:</P>
+The race condition may also occur between events from different BMSC within an HMSC. HMSC contains race if there exists path which contains a race. SCStudio is capable of finding one such occurrence:</P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
Modified: trunk/doc/help/time_consistency/pictures/cons1.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -9,7 +9,7 @@
<BODY>
<H1>Time Consistency</H1>
<P>Time consistency is a problem of deciding whether introduced time constraints in a given MSC are in conflict. MSC is time consistent if it is without such conflicting time constraints.</P>
-<p> The motivation for time consitency is following. It can easily happen that user can specify too restrictive time constraints and cause that the set of behaviors is empty. The time consistency property checks such situations.
+<p> The motivation for time consistency is following. It can easily happen that user can specify too restrictive time constraints and cause that the set of behaviors is empty. The time consistency property checks such situations.
<H2>Basic Message Sequence Chart</H2>
<P>Time consistent property is violated for BMSC <I>B</I> when there is no valid time assignment for B.</P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event, such that it satisfies all constraints in a given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by assignment to these events must be included in the interval set of this constraint.</P>
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -43,7 +43,7 @@
<li> the lower bound of the constraint between the nodes <I>A</I> and <I>B</I> changes to 8 because the lower bound of the first path is 9 and the lower bound of the second path is 8</li>
<li> the <i>Original BMSC A</i> tightens to the <i>Tightened BMSC A</i> because of the both constraints on the nodes <I> A </I> (the upper bound is derived from the constraint containing [3,5] and the lower bound from the constraint containing [2,8]) </li>
<li> the upper bound of the HMSC constraint originally containing [3,5] is tightened to 5 (not included) because the candidates for the upper bound is the lower value from upper bound 5 (from the original constraint) and the value derived from constraints containing, (8,10], (3,4] and [2,8]. We have to compute the upper bound candidate from the values of the time intervals. Since we can stay at least 3 (not included) time units in the first node <I> A </I> and at least 2 time units in the node <I>B</I> and we can stay at most 10 time units in the whole execution we get that we can stay at most 10 - 3 - 2 = 5 (not included) time units in second node <I> A </I>. Thus the original constraint (with the value [3,5]) will contain [3,5) after the execution of the tightening algorithm.</li>
-<li> the upper bound of the constraint containing originally [2,8] tightens to 4 (not included), bacause the possible upper bound for this constraint derived from the first path is 10 - 4 - 3 = 3 (not included) and from the second path it is 10 - 3 - 3 = 4 (not included). </li>
+<li> the upper bound of the constraint containing originally [2,8] tightens to 4 (not included), because the possible upper bound for this constraint derived from the first path is 10 - 4 - 3 = 3 (not included) and from the second path it is 10 - 3 - 3 = 4 (not included). </li>
</ul>
</P>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-09-10 11:22:47 UTC (rev 909)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-09-10 13:07:27 UTC (rev 910)
@@ -33,8 +33,8 @@
<P>BMSC B (resp. HMSC path p) contains time race if there are two visually ordered events in B (resp. p), but there exists time assignment which assigns the visually preceding event larger time value than the value assigned to the subsequent event.</P>
<P>An HMSC contains time race if there exists path which contains time race. </P>
<P>The time assignment for BMSC (resp. HMSC path) is an assignment of time value to every event such that it satisfies all constraints in given BMSC (resp. HMSC path). I.e. for every constraint which restricts two events, the difference of values assigned by the assignment to these events must be included in the interval set of this constraint.</P>
-<P>Time Race algortihm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
-<P>The next example shows HMSC which contains race condition (between <I>HTTP Request</I> and <I>HTTP Response</I> receive events), but which is time race free. Due to time constraints the <I>HTTP Request</I>receive event happens allways before the <I>HTTP Response</I> receive event. </P>
+<P>Time Race algorithm checks the same as the <a href="../race/race.html">race checker</a>, but takes into account also time constraints.</P>
+<P>The next example shows HMSC which contains race condition (between <I>HTTP Request</I> and <I>HTTP Response</I> receive events), but which is time race free. Due to time constraints the <I>HTTP Request</I>receive event happens always before the <I>HTTP Response</I> receive event. </P>
<div style="margin: 0 auto;">
<ul class="gallery"><li>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ag...@us...> - 2010-09-13 13:36:39
|
Revision: 917
http://scstudio.svn.sourceforge.net/scstudio/?rev=917&view=rev
Author: agmy
Date: 2010-09-13 13:36:32 +0000 (Mon, 13 Sep 2010)
Log Message:
-----------
Added ignored constructions to help.
Modified Paths:
--------------
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
Modified: trunk/doc/help/time_consistency/time_consistency.html
===================================================================
--- trunk/doc/help/time_consistency/time_consistency.html 2010-09-13 13:19:34 UTC (rev 916)
+++ trunk/doc/help/time_consistency/time_consistency.html 2010-09-13 13:36:32 UTC (rev 917)
@@ -40,5 +40,13 @@
</ul>
</div>
+
+<p style="clear: both;">
+<H3>Current implementation:</H3>
+In the current implementation the following features are not supported and therefore ignored by the algorithm:
+<I> Ordering Line, Ordering Side-Side, Ordering Sides, Ordering Arrow. </I>
+
+
+
</BODY>
</HTML>
Modified: trunk/doc/help/time_tighten/time_tighten.html
===================================================================
--- trunk/doc/help/time_tighten/time_tighten.html 2010-09-13 13:19:34 UTC (rev 916)
+++ trunk/doc/help/time_tighten/time_tighten.html 2010-09-13 13:36:32 UTC (rev 917)
@@ -1,4 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
@@ -99,5 +100,11 @@
</ul>
</div>
+<p style="clear: both;">
+<H3>Current implementation:</H3>
+In the current implementation the following features are not supported and therefore ignored by the algorithm:
+<I> Ordering Line, Ordering Side-Side, Ordering Sides, Ordering Arrow. </I>
+
+
</BODY>
</HTML>
Modified: trunk/doc/help/time_trace_race/time_race.html
===================================================================
--- trunk/doc/help/time_trace_race/time_race.html 2010-09-13 13:19:34 UTC (rev 916)
+++ trunk/doc/help/time_trace_race/time_race.html 2010-09-13 13:36:32 UTC (rev 917)
@@ -61,5 +61,10 @@
<p style="clear: both;">
+<H3>Current implementation:</H3>
+In the current implementation the following features are not supported and therefore ignored by the algorithm:
+<I> Ordering Line, Ordering Side-Side, Ordering Sides, Ordering Arrow. </I>
+
+
</BODY>
</HTML>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <koc...@us...> - 2010-09-13 14:23:41
|
Revision: 919
http://scstudio.svn.sourceforge.net/scstudio/?rev=919&view=rev
Author: kocianon
Date: 2010-09-13 14:23:33 +0000 (Mon, 13 Sep 2010)
Log Message:
-----------
converted to xhtml, some redundant files deleted
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/beautify/beautify.html
trunk/doc/help/boundedness/boundedness.html
trunk/doc/help/deadlock/deadlock.html
trunk/doc/help/fifo/fifo.html
trunk/doc/help/help.css
trunk/doc/help/livelock/livelock.html
trunk/doc/help/localchoice/localchoice.html
trunk/doc/help/membership/membership.html
trunk/doc/help/race/race.html
trunk/doc/help/realizability/realizability.html
trunk/doc/help/recursivity/recursivity.html
trunk/doc/help/time_consistency/time_consistency.html
trunk/doc/help/time_syntax/time_syntax.html
trunk/doc/help/time_tighten/time_tighten.html
trunk/doc/help/time_trace_race/time_race.html
trunk/doc/help/unique_instance/unique_instance.html
Removed Paths:
-------------
trunk/doc/help/beautify/coregion1.png
trunk/doc/help/beautify/coregion2.png
trunk/doc/help/beautify/ordered.png
trunk/doc/help/beautify/unfifo2.png
trunk/doc/help/beautify/unordered.png
trunk/doc/help/boundedness/unbounded.png
trunk/doc/help/deadlock/deadlock.png
trunk/doc/help/livelock/livelock.png
trunk/doc/help/membership/memebership_1.png
trunk/doc/help/membership/memebership_10.png
trunk/doc/help/membership/memebership_11.png
trunk/doc/help/membership/memebership_12.png
trunk/doc/help/membership/memebership_2.png
trunk/doc/help/membership/memebership_3.png
trunk/doc/help/membership/memebership_4.png
trunk/doc/help/membership/memebership_5.png
trunk/doc/help/membership/memebership_6.png
trunk/doc/help/membership/memebership_7.png
trunk/doc/help/membership/memebership_8.png
trunk/doc/help/membership/memebership_9.png
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-09-13 13:40:13 UTC (rev 918)
+++ trunk/doc/help/acyclic/acyclic.html 2010-09-13 14:23:33 UTC (rev 919)
@@ -1,46 +1,71 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Acyclic property</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Acyclic property</H1>
-<P> ensures that there is no cyclic dependency among events in an BMSC. Such a dependency is erroneous, because it requires to wait with sending a message until it is received. An example of such BMSC design can be seen in the following figure: </P>
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/cyclic_simple.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li class="caption">Cyclic design</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/cyclic_result.png" width="250" BORDER="0" ALT="Cyclic BMSC" TITLE="Cyclic BMSC"></li>
- <li class="caption">Highlighted cyclic dependency</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-Sending message <I>m2</I> may not be done until message <I>m1</I> is received, but message <I>m1</I> may not be send until message <I>m2</I> is received.</P>
-SCStudio highlights the cyclic dependency:
-
-A more tricky example of an acyclic design is depicted on the following figure. There is a coregion box on the <I>Instance p</I> which contains send of the message <I>m2</I> and receive of the message <I>m1</I>. From the semantics of coregion it follows that <I>m1, m2</I> are unordered. Thus we can perform first <I>m1</I> and then <I> m2 </I> and there is no cyclic dependency. </p>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/acyclic.png" width="250" BORDER="0" ALT="Acyclic BMSC" TITLE="Acyclic BMSC"></li>
- <li class="caption">Acyclic design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>Acyclic property</title>
+ <meta name="author" content="Martin Chmelik" />
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>Acyclic property</h1>
+ <p>
+ ensures that there is no cyclic dependency among events in an BMSC. Such a
+ dependency is erroneous, because it requires to wait with sending a
+ message until it is received. An example of such BMSC design can be seen
+ in the following figure:
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/cyclic_simple.png" width="250"
+ alt="Cyclic BMSC" title="Cyclic BMSC" />
+ </li>
+ <li class="caption">
+ Cyclic design
+ </li>
+ </ul>
+ </li>
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/cyclic_result.png" width="250"
+ alt="Cyclic BMSC" title="Cyclic BMSC" />
+ </li>
+ <li class="caption">
+ Highlighted cyclic dependency
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ Sending message <i>m2</i> may not be done until message <i>m1</i>
+ is received, but message <i>m1</i> may not be send until message
+ <i>m2</i> is received.
+ </p>
+ SCStudio highlights the cyclic dependency: A more tricky example of an
+ acyclic design is depicted on the following figure. There is a coregion box
+ on the <i>Instance p</i> which contains send of the message <i>m2</i>
+ and receive of the message <i>m1</i>. From the semantics of
+ coregion it follows that <i>m1, m2</i> are unordered. Thus we can
+ perform first <i>m1</i> and then <i> m2 </i> and there is
+ no cyclic dependency.
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/acyclic.png" width="250"
+ alt="Acyclic BMSC" title="Acyclic BMSC" />
+ </li>
+ <li class="caption">
+ Acyclic design
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </body>
+</html>
Modified: trunk/doc/help/beautify/beautify.html
===================================================================
--- trunk/doc/help/beautify/beautify.html 2010-09-13 13:40:13 UTC (rev 918)
+++ trunk/doc/help/beautify/beautify.html 2010-09-13 14:23:33 UTC (rev 919)
@@ -1,78 +1,114 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <TITLE>Beautify documentation</TITLE>
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<div>
-<h2>Beautify</h2>
-<P>The main aim of this function is to redraw BMSC to be well-arranged.
-It is accessible via menu <code>Check → Drawing → Beautify</code>.
-</P>
-<h3> Example 1:</h3>
-<P>It changes order of instances to minimize a number of messages
-going from right side to left side and crossing instances with messages.
-Instances are justified to top and have the same length.
-For <a href="../fifo/fifo.html">FIFO</a> and
-<a href="../acyclic/acyclic.html">acyclic</a> BMSC it makes all messages
-horizontal and arranged over instances uniformly from top to down.
-</P>
+<?xml version="1.0" encoding="utf-8"?>
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unordered.png" width="500" BORDER="0" ALT="Unordered BMSC"></li>
- <li class="caption">Before beautify</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/ordered.png" align="middle" width="350" BORDER="0" ALT="Ordered BMSC"></li>
- <li class="caption">After beautify</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-<h3> Example 2:</h3>
-<P>A <a href="../fifo/fifo.html">non-FIFO</a> BMSC is redrawn to
-a form that no messages are going up.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unfifo2.png" width="250" BORDER="0" ALT="Ordered non-FIFO BMSC"></li>
- <li class="caption">Acyclic design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-<h3> Example 3:</h3>
-<P>For coregions it changes the order of events to minimize number
-of crossing two messages. After redrawing, messages are jointed with
-coregion in such way that they do not go across coregion body.
-<BR></P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li>
- <img src="pictures/coregion1.png" width="250" alt="Crossing messages jointed with coregion"></li>
- <li class="caption">Before beautify</li>
- </ul></li>
-<li>
- <ul>
-
- <li>
- <img src="pictures/coregion2.png" width="250 "alt=""></li>
- <li class="caption">After beautify</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
-</HTML>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Beautify documentation
+ </title>
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h2>
+ Beautify
+ </h2>
+ <p>
+ The main aim of this function is to redraw BMSC to be well-arranged. It
+ is accessible via menu <code>Check → Drawing → Beautify</code>.
+ </p>
+ <h3>
+ Example 1:
+ </h3>
+ <p>
+ It changes order of instances to minimize a number of messages going
+ from right side to left side and crossing instances with messages.
+ Instances are justified to top and have the same length. For <a
+ href="../fifo/fifo.html">FIFO</a> and <a
+ href="../acyclic/acyclic.html">acyclic</a> BMSC it makes all
+ messages horizontal and arranged over instances uniformly from top to
+ down.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/unordered.png" width="500" border="0"
+ alt="Unordered BMSC" />
+ </li>
+ <li class="caption">
+ Before beautify
+ </li>
+ </ul>
+ </li>
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/ordered.png" width="350"
+ border="0" alt="Ordered BMSC" />
+ </li>
+ <li class="caption">
+ After beautify
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ </p>
+ <h3>
+ Example 2:
+ </h3>
+ <p>
+ A <a href="../fifo/fifo.html">non-FIFO</a> BMSC is redrawn to a
+ form that no messages are going up.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/unfifo2.png" width="250"
+ alt="Ordered non-FIFO BMSC" />
+ </li>
+ <li class="caption">
+ Acyclic design
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ </p>
+ <h3>
+ Example 3:
+ </h3>
+ <p>
+ For coregions it changes the order of events to minimize number of
+ crossing two messages. After redrawing, messages are jointed with
+ coregion in such way that they do not go across coregion body.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/coregion1.png" width="250"
+ alt="Crossing messages jointed with coregion" />
+ </li>
+ <li class="caption">
+ Before beautify
+ </li>
+ </ul>
+ </li>
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/coregion2.png" width="250 " alt="" />
+ </li>
+ <li class="caption">
+ After beautify
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </body>
+</html>
Deleted: trunk/doc/help/beautify/coregion1.png
===================================================================
(Binary files differ)
Deleted: trunk/doc/help/beautify/coregion2.png
===================================================================
(Binary files differ)
Deleted: trunk/doc/help/beautify/ordered.png
===================================================================
(Binary files differ)
Deleted: trunk/doc/help/beautify/unfifo2.png
===================================================================
(Binary files differ)
Deleted: trunk/doc/help/beautify/unordered.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/boundedness/boundedness.html
===================================================================
--- trunk/doc/help/boundedness/boundedness.html 2010-09-13 13:40:13 UTC (rev 918)
+++ trunk/doc/help/boundedness/boundedness.html 2010-09-13 14:23:33 UTC (rev 919)
@@ -1,37 +1,72 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Universal Boundedness</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Universal Boundedness</H1>
-<P>is a property of an HMSC. An HMSC is universally bounded if there exists an upper bound on size of communication buffers of all involved processes. Informally, each instance waits for a response before sending the same message again. A dialog is an example of bounded communication. E-mail spam is an example of unbounded communication - actually, it is not rare that an input buffer (mailbox) gets full in this case. </P>
+<?xml version="1.0" encoding="utf-8"?>
-<P>When all the possible executions of an HMSC are finite, then HMSC is universally bounded. Therefore only HMSCs containing a cycle may be unbounded. Every cycle whose repetitive execution may lead to unbounded grow of an input buffer is found and displayed by SCStudio.</P>
-<P>The HMSC on the following picture is unbounded. This is because there is no mechanism for keeping the buffer for messages between <I>X</I> and <I>Y</I> bounded. </P>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/unbounded_hmsc.png" width="200" BORDER="0" ALT="Unbounded HMSC" TITLE="Unbounded HMSC"></li>
- <li class="caption">Unbounded HMSC</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/unbounded_msc.png" width="250" BORDER="0" ALT="MSC A" TITLE="MSC A"></li>
- <li class="caption">MSC A</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-
-<P>For any bound <I>B</I> of the buffer we can make an execution for which the buffer is not sufficiently large. This execution is for example the one which goes through cycle <I>B+1</I> times, the sending of message is very fast and the receiving is very slow. It is so slow, that in point of time when we have sent all messages we have not received any of them. Thus we have exceeded the bound <I>B</I> for this buffer.</P>
-<p>
-</BODY>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Universal Boundedness
+ </title>
+ <meta name="author" content="Martin Chmelik" />
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Universal Boundedness
+ </h1>
+ <p>
+ is a property of an HMSC. An HMSC is universally bounded if there exists
+ an upper bound on size of communication buffers of all involved processes.
+ Informally, each instance waits for a response before sending the same
+ message again. A dialog is an example of bounded communication. E-mail
+ spam is an example of unbounded communication - actually, it is not rare
+ that an input buffer (mailbox) gets full in this case.
+ </p>
+ <p>
+ When all the possible executions of an HMSC are finite, then HMSC is
+ universally bounded. Therefore only HMSCs containing a cycle may be
+ unbounded. Every cycle whose repetitive execution may lead to unbounded
+ grow of an input buffer is found and displayed by SCStudio.
+ </p>
+ <p>
+ The HMSC on the following picture is unbounded. This is because there is
+ no mechanism for keeping the buffer for messages between <i>X</i>
+ and <i>Y</i> bounded.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/unbounded_hmsc.png" width="200"
+ alt="Unbounded HMSC" title="Unbounded HMSC" />
+ </li>
+ <li class="caption">
+ Unbounded HMSC
+ </li>
+ </ul>
+ </li>
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/unbounded_msc.png" width="250"
+ alt="MSC A" title="MSC A" />
+ </li>
+ <li class="caption">
+ MSC A
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ For any bound <i>B</i> of the buffer we can make an execution for
+ which the buffer is not sufficiently large. This execution is for example
+ the one which goes through cycle <i>B+1</i> times, the sending of
+ message is very fast and the receiving is very slow. It is so slow, that
+ in point of time when we have sent all messages we have not received any
+ of them. Thus we have exceeded the bound <i>B</i> for this
+ buffer.
+ </p>
+ </body>
+</html>
Deleted: trunk/doc/help/boundedness/unbounded.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/deadlock/deadlock.html
===================================================================
--- trunk/doc/help/deadlock/deadlock.html 2010-09-13 13:40:13 UTC (rev 918)
+++ trunk/doc/help/deadlock/deadlock.html 2010-09-13 14:23:33 UTC (rev 919)
@@ -1,31 +1,47 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>Deadlock</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>Deadlock</H1>
-<P>is a property of a HMSC node. A reachable node is deadlocked if there is no reference node reachable from the node, i.e. after executing the BMSC referenced by a deadlocked node, there is no node to continue with.</P>
+<?xml version="1.0" encoding="utf-8"?>
-<P>
-SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked node a path from the start node to the node is given as an example of the deadlock.
-</P>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-<P>
-On the next picture the node B is clearly a deadlocked node. That is why it is highlighted by SCStudio and given as an example.
-</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/deadlock.png" width="350" BORDER="0" ALT="Typical deadlock" TITLE="Typical deadlock"></li>
- <li class="caption">Typical deadlock</li>
- </ul>
-</li>
-</ul>
-</div>
-
-</BODY>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Deadlock
+ </title>
+ <meta name="author" content="Martin Chmelik" />
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Deadlock
+ </h1>
+ <p>
+ is a property of a HMSC node. A reachable node is deadlocked if there is
+ no reference node reachable from the node, i.e. after executing the BMSC
+ referenced by a deadlocked node, there is no node to continue with.
+ </p>
+ <p>
+ SCStudio finds all deadlocked nodes in a given HMSC. For each deadlocked
+ node a path from the start node to the node is given as an example of the
+ deadlock.
+ </p>
+ <p>
+ On the next picture the node B is clearly a deadlocked node. That is why
+ it is highlighted by SCStudio and given as an example.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/deadlock.png" width="350"
+ alt="Typical deadlock" title="Typical deadlock" />
+ </li>
+ <li class="caption">
+ Typical deadlock
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </body>
+</html>
Deleted: trunk/doc/help/deadlock/deadlock.png
===================================================================
(Binary files differ)
Modified: trunk/doc/help/fifo/fifo.html
===================================================================
--- trunk/doc/help/fifo/fifo.html 2010-09-13 13:40:13 UTC (rev 918)
+++ trunk/doc/help/fifo/fifo.html 2010-09-13 14:23:33 UTC (rev 919)
@@ -1,116 +1,182 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>FIFO</TITLE>
- <meta name="author" content="Martin Chmelik">
- <LINK href="../help.css" rel="stylesheet" type="text/css"/>
-</HEAD>
-<BODY>
-<H1>FIFO (First In, First Out) property</H1>
-<P>is a BMSC property. The property ensures that it is possible
-to implement the desired behavior without deadlocks, that would be
-caused by channel behavior.</P>
+<?xml version="1.0" encoding="utf-8"?>
-<P>
-There are several types of channels and several ways how they can be used in BMSC. Some of the most useful are the following:
-<ul>
-<li> FIFO channel for every pair of instances </li>
-<li> FIFO channel for every pair of instances and labels </li>
-<li> One FIFO channel for every process </li>
-<li> One FIFO channel for all processes </li>
-</ul>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-The SCStudio currently supports the first two options. The extension for other options is planned.
-</P>
-
-<H2>Basic Message Sequence Chart</H2>
-<H3>FIFO channel for every pair of instances </H3>
-<P>FIFO property is violated when there are two
-messages, such that they share a common source and destination
-instance and the latter message may arrive before the first one.</p>
-<p> Imagine we have a system in an all-channel FIFO environment which behaves according to a BMSC specification. A process expects the messages to arrive in some order, according to specification, but the messages might have been sent in a different order. A deadlock is reached as there might be a different message in the head of the channel queue.
-</P>
-<P>An example of a non-FIFO design can be seen on the
-next picture. Message <I>m1</I> is sent before <I>m2</I>, but
-instance <I>q</I> receives message <I>m2</I> before <I>m1. </I>Because
-we are having a FIFO channel between instances <I>p</I> and <I>q</I>,
-this is not possible and leads to a deadlock.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/simple_non_fifo.png" width="250" BORDER="0" ALT="Example of a non-fifo design" TITLE="Example of a non-fifo design"></li>
- <li class="caption">Example of a non-FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<h4>Formal definition:</h4>
-<P>BMSC is FIFO if for all receive events <I>c</I>, <I>d</I> and their matching send events
-<I>a, b</I> (<<I>a,c</I>> forms the first message and <<I>b,d</I>> forms the second message) it holds that
-<I>c < d => a < b</I>, where < is the visual order and the two messages belong
-to the same channel.</P>
-<P>On the next picture we can see tricky examples of FIFO BMSCs. They satisfy the FIFO property, because the receive events of both messages are in coregion. This means that the user has specified that the receive events can happen in an arbitrary order. So that if there is any order of these two events in the head of the channel queue, the system will certainly not reach deadlock.</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/fifo1.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li class="caption">Example of a FIFO design</li>
- </ul></li>
-<li>
- <ul>
-
- <li><IMG SRC="pictures/fifo2.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
- <li class="caption">Example of a different FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-
-<p style="clear: both;">
-
-<P>An example of a non-FIFO design can be seen on the following picture. This is because the <I>Instance q</I> can execute only the receive event of message <I>m1</I> and then the receive event of the message <I>m2</I>. However it is possible (due to coregion), that the message <I>m2</I> is at head of the channel queue of Instance q and message <I>m2</I> is behind it. </P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/nonfifo1.png" width="250" BORDER="0" ALT="non-fifo design" TITLE="non-fifo design"></li>
- <li class="caption">Example of a non-FIFO design</li>
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<H3>FIFO channel for every pair of instances and labels</H3>
-<P>In this case we can have more than one FIFO channel between two processes. For every label there is one channel. Everything what has satisfied FIFO property in the previous case, will satisfy the property also in this case. The difference can be seen on the following FIFO example:</P>
-
-<div style="margin: 0 auto;">
-<ul class="gallery"><li>
- <ul>
- <li><IMG SRC="pictures/label_channel_fifo.png" width="250" BORDER="0" ALT="FIFO MSC design" TITLE="FIFO MSC design"></li>
-
- </ul>
-</li>
-</ul>
-</div>
-<p style="clear: both;">
-
-<P>Messages <I>m2</I> and <I>m1</I> are not in the same channel, therefore they may arrive in
-any order.</P>
-<!-- comment
-<H3>One FIFO buffer for every process</H3>
-<P>TODO, wait until implementation is done</P>
-<H3>One FIFO buffer for all processes</H3>
-<P>TODO, wait until implementation is done</P>
--->
-<H2>High-level Message Sequence Chart</H2>
-<P>HMSC satisfies FIFO property for a certain channel
-type, if every BMSC represented by the HMSC satisfies the FIFO property
-for that channel type.</P>
-</BODY>
-</HTML>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ FIFO
+ </title>
+ <meta name="author" content="Martin Chmelik" />
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ FIFO (First In, First Out) property
+ </h1>
+ <p>
+ is a BMSC property. The property ensures that it is possible to implement
+ the desired behavior without deadlocks, that would be caused by channel
+ behavior.
+ </p>
+ <p>
+ There are several types of channels and several ways how they can be used
+ in BMSC. Some of the most useful are the following:
+ </p>
+ <ul>
+ <li>
+ FIFO channel for every pair of instances
+ </li>
+ <li>
+ FIFO channel for every pair of instances and labels
+ </li>
+ <li>
+ One FIFO channel for every process
+ </li>
+ <li>
+ One FIFO channel for all processes
+ </li>
+ </ul>
+ The SCStudio currently supports the first two options. The extension for
+ other options is planned.
+ <h2>
+ Basic Message Sequence Chart
+ </h2>
+ <h3>
+ FIFO channel for every pair of instances
+ </h3>
+ <p>
+ FIFO property is violated when there are two messages, such that they
+ share a common source and destination instance and the latter message may
+ arrive before the first one.
+ </p>
+ <p>
+ Imagine we have a system in an all-channel FIFO environment which behaves
+ according to a BMSC specification. A process expects the messages to
+ arrive in some order, according to specification, but the messages might
+ have been sent in a different order. A deadlock is reached as there might
+ be a different message in the head of the channel queue.
+ </p>
+ <p>
+ An example of a non-FIFO design can be seen on the next picture. Message
+ <i>m1</i> is sent before <i>m2</i>, but instance <i>q</i>
+ receives message <i>m2</i> before <i>m1. </i>Because we
+ are having a FIFO channel between instances <i>p</i> and <i>q</i>,
+ this is not possible and leads to a deadlock.
+ </p>
+ <ul class="gallery">
+ <li>
+ <ul>
+ <li>
+ <img src="pictures/simple_non_fifo.png" width="250" border="0"
+ alt="Example of a non-fifo design"
+ title="Example of a non-fifo design" />
+ </li>
+ <li class="caption">
+ Example of a non-FIFO design
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ </p>
+ <h4>
+ Formal definition:
+ </h4>
+ <p>
+ BMSC is FIFO if for all receive events <i>c</i>, <i>d</i>
+ and their matching send events <i>a, b</i> (<<i>a,c</i>>
+ forms the first message and <<i>b,d</i>> forms the second
+ message) it holds that <i>c < d => a < b</i>, where < is
+ the visual order and the two messages belong to the same channel.
+ </p>
+ <p>
+ On the next picture we can see tricky examples of FIFO BMSCs. They satisfy
+ the FIFO property, because the receive events of both messages are in
+ coregion. This means that the user has specified that the receive events
+ can happen in an arbitrary order. So that if there is any order of these
+ two events in the head of the channel queue, the system will certainly not
+ reach deadlock.
+ </p>
+ <ul class="gallery">
+ <li>
...
[truncated message content] |
|
From: <got...@us...> - 2010-09-14 21:04:00
|
Revision: 925
http://scstudio.svn.sourceforge.net/scstudio/?rev=925&view=rev
Author: gotthardp
Date: 2010-09-14 21:03:53 +0000 (Tue, 14 Sep 2010)
Log Message:
-----------
Added template for membership help. Next step: write some text.
Modified Paths:
--------------
trunk/doc/help/algorithms.html
trunk/doc/help/frontend.html
trunk/doc/help/scstudio.hhc
trunk/doc/help/unique_instance/unique_instance.html
Added Paths:
-----------
trunk/doc/help/index.html
trunk/doc/help/montecarlo/
trunk/doc/help/montecarlo/montecarlo.html
trunk/doc/help/transformers.html
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-14 17:07:59 UTC (rev 924)
+++ trunk/doc/help/algorithms.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -3,7 +3,7 @@
<link href="help.css" rel="stylesheet" type="text/css"/>
</head>
-<h1>Algorithms</h1>
+<h1>Verification Algorithms</h1>
The following verification algorithms are supported:
<ul>
@@ -13,40 +13,14 @@
<li><a href="fifo/fifo.html">FIFO</a></li>
<li><a href="livelock/livelock.html">Livelock</a></li>
<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
-<li><a href="membership/membership.html">Membership</a></li>
<li><a href="race/race.html">Race Condition</a></li>
<li><a href="realizability/realizability.html">Strong Realizability</a></li>
<li><a href="recursivity/recursivity.html">Non-recursivity</li>
<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
<li><a href="time_trace_race/time_race.html">Time Race</a></li>
-<li><a href="unique_instance/unique_instance.html">Unique instance names</a></li>
+<li><a href="unique_instance/unique_instance.html">Unique Instance Names</a></li>
</ul>
-<h1>Transformers</h1>
-<ul>
-<li><a href="beautify/beautify.html">Beautify</a></li>
-<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
-</ul>
-
-<h1>Frontend</h1>
-
-<p>Currently, the SCStudio frontend is accessible as a Microsoft Visio addon.
-Thus, Microsoft Visio 2003 or 2007 must be installed prior to installing
-SCStudio.</p>
-<p>When an MSC document is opened, the Sequence Chart Studio toolbar and menu Check
-are available:</p>
-<img class="big" src="frontend/pictures/frontend.png" alt="SCStudio toolbar and menu in MS Visio">
-
-<p>SCStudio functions extending Visio are divided into the following categories:</p>
-<ul>
-<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
-<li><a href="frontend/message-numbering.html">Message numbering</a></li>
-<li><a href="frontend/message-snapping.html">Message snapping</a></li>
-<li><a href="frontend/shape-selection.html">Shape selection</a></li>
-</ul>
-
-<p>Many SCStudio functions define their own keyboard accelerators.
-See the <a href="frontend/shortcuts.html">keyboard accelerators</a> section to
-list all of them.</p></body>
+</body>
</html>
Modified: trunk/doc/help/frontend.html
===================================================================
--- trunk/doc/help/frontend.html 2010-09-14 17:07:59 UTC (rev 924)
+++ trunk/doc/help/frontend.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -15,10 +15,10 @@
<p>SCStudio functions extending Visio are divided into the following categories:</p>
<ul>
-<li><a href="frontend/shape-selection.html">Shape selection</a></li>
-<li><a href="frontend/automatic-drawing.html">Automatic drawing</a></li>
-<li><a href="frontend/message-numbering.html">Message numbering</a></li>
-<li><a href="frontend/message-snapping.html">Message snapping</a></li>
+<li><a href="frontend/shape-selection.html">Shape Selection</a></li>
+<li><a href="frontend/automatic-drawing.html">Automatic Drawing</a></li>
+<li><a href="frontend/message-numbering.html">Message Numbering</a></li>
+<li><a href="frontend/message-snapping.html">Message Snapping</a></li>
</ul>
<p>Many SCStudio functions define their own keyboard accelerators.
Added: trunk/doc/help/index.html
===================================================================
--- trunk/doc/help/index.html (rev 0)
+++ trunk/doc/help/index.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -0,0 +1,45 @@
+<html>
+<head>
+<link href="help.css" rel="stylesheet" type="text/css"/>
+</head>
+
+<h1>Sequence Chart Studio</h1>
+
+<ul>
+<li><a href="frontend.html">Microsoft Visio Front-end</a>
+ <ul>
+ <li><a href="frontend/shape-selection.html">Shape Selection</a></li>
+ <li><a href="frontend/automatic-drawing.html">Automatic Drawing</a></li>
+ <li><a href="frontend/message-numbering.html">Message Numbering</a></li>
+ <li><a href="frontend/message-snapping.html">Message Snapping</a></li>
+ <li><a href="frontend/shortcuts.html">Keyboard Accelerators</a></li>
+ </ul>
+</li>
+<li><a href="algorithms.html">Verification Algoritms</a>
+ <ul>
+ <li><a href="acyclic/acyclic.html">Acyclic property</a></li>
+ <li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
+ <li><a href="deadlock/deadlock.html">Deadlock</a></li>
+ <li><a href="fifo/fifo.html">FIFO</a></li>
+ <li><a href="livelock/livelock.html">Livelock</a></li>
+ <li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
+ <li><a href="race/race.html">Race Condition</a></li>
+ <li><a href="realizability/realizability.html">Strong Realizability</a></li>
+ <li><a href="recursivity/recursivity.html">Non-recursivity</li>
+ <li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
+ <li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
+ <li><a href="time_trace_race/time_race.html">Time Race</a></li>
+ <li><a href="unique_instance/unique_instance.html">Unique Instance Names</a></li>
+</ul>
+</li>
+<li><a href="membership/membership.html">Drawing Membership</a></li>
+<li><a href="montecarlo/montecarlo.html">Monte Carlo Simulation</a></li>
+<li><a href="transformers.html">Drawing Transformers</a></li>
+ <ul>
+ <li><a href="beautify/beautify.html">Beautify</a></li>
+ <li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
+ </ul>
+</ul>
+
+</body>
+</html>
Property changes on: trunk/doc/help/index.html
___________________________________________________________________
Added: svn:eol-style
+ native
Added: trunk/doc/help/montecarlo/montecarlo.html
===================================================================
--- trunk/doc/help/montecarlo/montecarlo.html (rev 0)
+++ trunk/doc/help/montecarlo/montecarlo.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Monte Carlo Simulation
+ </title>
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h2>
+ Monte Carlo Simulation
+ </h2>
+ <p>
+ Through the Monte Carlo Simulation you can estimate a value of time
+ measurements in your drawing. To receive simulation results you need
+ to start the Microsoft Excel.
+ </p>
+ </body>
+</html>
Property changes on: trunk/doc/help/montecarlo/montecarlo.html
___________________________________________________________________
Added: svn:eol-style
+ native
Modified: trunk/doc/help/scstudio.hhc
===================================================================
--- trunk/doc/help/scstudio.hhc 2010-09-14 17:07:59 UTC (rev 924)
+++ trunk/doc/help/scstudio.hhc 2010-09-14 21:03:53 UTC (rev 925)
@@ -14,11 +14,11 @@
</OBJECT>
<UL>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Shape selection">
+ <param name="Name" value="Shape Selection">
<param name="Local" value="frontend\shape-selection.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Automatic drawing">
+ <param name="Name" value="Automatic Drawing">
<param name="Local" value="frontend\automatic-drawing.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
@@ -30,7 +30,7 @@
<param name="Local" value="frontend\message-snapping.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Keyboard accelerators">
+ <param name="Name" value="Keyboard Accelerators">
<param name="Local" value="frontend\shortcuts.html">
</OBJECT>
</UL>
@@ -44,37 +44,74 @@
<param name="Local" value="acyclic\acyclic.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Universal Boundedness">
+ <param name="Local" value="boundedness\boundedness.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Deadlock Property">
+ <param name="Local" value="deadlock\deadlock.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
<param name="Name" value="FIFO property">
<param name="Local" value="fifo\fifo.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Livelock Property">
+ <param name="Local" value="livelock\livelock.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
<param name="Name" value="Nonlocal Choice">
<param name="Local" value="localchoice\localchoice.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Membership">
- <param name="Local" value="membership\membership.html">
- </OBJECT>
- <LI> <OBJECT type="text/sitemap">
<param name="Name" value="Race Condition">
<param name="Local" value="race\race.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Deadlock Property">
- <param name="Local" value="deadlock\deadlock.html">
+ <param name="Name" value="Strong Realizability">
+ <param name="Local" value="realizability\realizability.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Livelock Property">
- <param name="Local" value="livelock\livelock.html">
+ <param name="Name" value="Non-recursivity">
+ <param name="Local" value="recursivity/recursivity.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Universal Boundedness">
- <param name="Local" value="boundedness\boundedness.html">
+ <param name="Name" value="Time Consistency">
+ <param name="Local" value="time_consistency/time_consistency.html">
</OBJECT>
<LI> <OBJECT type="text/sitemap">
- <param name="Name" value="Strong Realizability">
- <param name="Local" value="realizability\realizability.html">
+ <param name="Name" value="Correct Time Constraint Syntax">
+ <param name="Local" value="time_syntax/time_syntax.html">
</OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Time Race">
+ <param name="Local" value="time_trace_race/time_race.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Unique Instance Names">
+ <param name="Local" value="unique_instance/unique_instance.html">
+ </OBJECT>
</UL>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Membership">
+ <param name="Local" value="membership\membership.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Monte Carlo Simulation">
+ <param name="Local" value="montecarlo\montecarlo.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Transformers">
+ </OBJECT>
+ <UL>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Beautify">
+ <param name="Local" value="beautify\beautify.html">
+ </OBJECT>
+ <LI> <OBJECT type="text/sitemap">
+ <param name="Name" value="Tighten Time">
+ <param name="Local" value="time_tighten\time_tighten.html">
+ </OBJECT>
+ </UL>
</UL>
</BODY></HTML>
Added: trunk/doc/help/transformers.html
===================================================================
--- trunk/doc/help/transformers.html (rev 0)
+++ trunk/doc/help/transformers.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -0,0 +1,13 @@
+<html>
+<head>
+<link href="help.css" rel="stylesheet" type="text/css"/>
+</head>
+
+<h1>Drawing Transformers</h1>
+<ul>
+<li><a href="beautify/beautify.html">Beautify</a></li>
+<li><a href="time_tighten/time_tighten.html">Tighten Time</a></li>
+</ul>
+
+</body>
+</html>
Property changes on: trunk/doc/help/transformers.html
___________________________________________________________________
Added: svn:eol-style
+ native
Modified: trunk/doc/help/unique_instance/unique_instance.html
===================================================================
--- trunk/doc/help/unique_instance/unique_instance.html 2010-09-14 17:07:59 UTC (rev 924)
+++ trunk/doc/help/unique_instance/unique_instance.html 2010-09-14 21:03:53 UTC (rev 925)
@@ -14,7 +14,7 @@
</head>
<body>
<h1>
- Unique instance names
+ Unique Instance Names
</h1>
<p>
ensures that there are no two instances with the same name within a BMSC.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <koc...@us...> - 2010-09-16 12:14:16
|
Revision: 938
http://scstudio.svn.sourceforge.net/scstudio/?rev=938&view=rev
Author: kocianon
Date: 2010-09-16 12:14:08 +0000 (Thu, 16 Sep 2010)
Log Message:
-----------
converting to xhtml, changing filenames to be parsable by python ElementTree xml parser
Modified Paths:
--------------
trunk/doc/help/algorithms.html
trunk/doc/help/beautify/beautify.html
trunk/doc/help/frontend/shortcuts.html
trunk/doc/help/frontend.html
trunk/doc/help/index.html
trunk/doc/help/transformers.html
Added Paths:
-----------
trunk/doc/help/frontend/automatic_drawing.html
trunk/doc/help/frontend/message_snapping.html
trunk/doc/help/frontend/shape_selection.html
Removed Paths:
-------------
trunk/doc/help/frontend/automatic-drawing.html
trunk/doc/help/frontend/message-numbering.html
trunk/doc/help/frontend/message-snapping.html
trunk/doc/help/frontend/shape-selection.html
Modified: trunk/doc/help/algorithms.html
===================================================================
--- trunk/doc/help/algorithms.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/algorithms.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -1,26 +1,110 @@
-<html>
-<head>
-<link href="help.css" rel="stylesheet" type="text/css"/>
-</head>
+<?xml version="1.0" encoding="utf-8"?>
-<h1>Verification Algorithms</h1>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
-The following verification algorithms are supported:
-<ul>
-<li><a href="acyclic/acyclic.html">Acyclic property</a></li>
-<li><a href="boundedness/boundedness.html">Universal Boundedness</a></li>
-<li><a href="deadlock/deadlock.html">Deadlock</a></li>
-<li><a href="fifo/fifo.html">FIFO</a></li>
-<li><a href="livelock/livelock.html">Livelock</a></li>
-<li><a href="localchoice/localchoice.html">Nonlocal Choice</a></li>
-<li><a href="race/race.html">Race Condition</a></li>
-<li><a href="realizability/realizability.html">Strong Realizability</a></li>
-<li><a href="recursivity/recursivity.html">Non-recursivity</li>
-<li><a href="time_consistency/time_consistency.html">Time Consistency</a></li>
-<li><a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a></li>
-<li><a href="time_trace_race/time_race.html">Time Race</a></li>
-<li><a href="unique_instance/unique_instance.html">Unique Instance Names</a></li>
-</ul>
-
-</body>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>all</title>
+ <link href="help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Algorithms
+ </h1>
+ The following verification algorithms are supported:
+ <ul>
+ <li>
+ <a href="acyclic/acyclic.html">Acyclic property</a>
+ </li>
+ <li>
+ <a href="boundedness/boundedness.html">Universal Boundedness</a>
+ </li>
+ <li>
+ <a href="deadlock/deadlock.html">Deadlock</a>
+ </li>
+ <li>
+ <a href="fifo/fifo.html">FIFO</a>
+ </li>
+ <li>
+ <a href="livelock/livelock.html">Livelock</a>
+ </li>
+ <li>
+ <a href="localchoice/localchoice.html">Nonlocal Choice</a>
+ </li>
+ <li>
+ <a href="membership/membership.html">Membership</a>
+ </li>
+ <li>
+ <a href="race/race.html">Race Condition</a>
+ </li>
+ <li>
+ <a href="realizability/realizability.html">Strong Realizability</a>
+ </li>
+ <li>
+ <a href="recursivity/recursivity.html">Non-recursivity</a>
+ </li>
+ <li>
+ <a href="time_consistency/time_consistency.html">Time Consistency</a>
+ </li>
+ <li>
+ <a href="time_syntax/time_syntax.html">Correct Time Constraint Syntax</a>
+ </li>
+ <li>
+ <a href="time_trace_race/time_race.html">Time Race</a>
+ </li>
+ <li>
+ <a href="unique_instance/unique_instance.html">Unique instance names</a>
+ </li>
+ </ul>
+ <h1>
+ Transformers
+ </h1>
+ <ul>
+ <li>
+ <a href="beautify/beautify.html">Beautify</a>
+ </li>
+ <li>
+ <a href="time_tighten/time_tighten.html">Tighten Time</a>
+ </li>
+ </ul>
+ <h1>
+ Frontend
+ </h1>
+ <p>
+ Currently, the SCStudio frontend is accessible as a Microsoft Visio addon.
+ Thus, Microsoft Visio 2003 or 2007 must be installed prior to installing
+ SCStudio.
+ </p>
+ <p>
+ When an MSC document is opened, the Sequence Chart Studio toolbar and menu
+ Check are available:
+ </p>
+ <img class="big" src="frontend/pictures/frontend.png"
+ alt="SCStudio toolbar and menu in MS Visio" />
+ <p>
+ SCStudio functions extending Visio are divided into the following
+ categories:
+ </p>
+ <ul>
+ <li>
+ <a href="frontend/automatic-drawing.html">Automatic drawing</a>
+ </li>
+ <li>
+ <a href="frontend/message-numbering.html">Message numbering</a>
+ </li>
+ <li>
+ <a href="frontend/message-snapping.html">Message snapping</a>
+ </li>
+ <li>
+ <a href="frontend/shape-selection.html">Shape selection</a>
+ </li>
+ </ul>
+ <p>
+ Many SCStudio functions define their own keyboard accelerators. See the <a
+ href="frontend/shortcuts.html">keyboard accelerators</a> section to
+ list all of them.
+ </p>
+ </body>
</html>
Modified: trunk/doc/help/beautify/beautify.html
===================================================================
--- trunk/doc/help/beautify/beautify.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/beautify/beautify.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -17,7 +17,7 @@
</h2>
<p>
The main aim of this function is to redraw BMSC to be well-arranged. It
- is accessible via menu <code>Check → Drawing → Beautify</code>.
+ is accessible via menu <code>Check -> Drawing -> Beautify</code>.
</p>
<h3>
Example 1:
Deleted: trunk/doc/help/frontend/automatic-drawing.html
===================================================================
--- trunk/doc/help/frontend/automatic-drawing.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/frontend/automatic-drawing.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -1,73 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<title>Automatic Drawing – SCStudio frontend</title>
-<link href="../help.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<h1>Automatic drawing</h1>
-<p>With all required shapes available in the BMSC and HMSC stencils, it is possible
-to draw virtually any MSC diagram. In practice, there are many stereotypes, however.
-SCStudio helps the user draw some frequently used patterns by several automatic
-drawing functions.</p>
-
-<h2 id="add_instances">Add Instances</h2>
-<p>The first of them is the <code>Add Instances</code> function accessible via menu
-<code>Check → Drawing → Add Instances</code>, or <code>Ctrl+Alt+F</code>
-keyboard shortcut. It is available in the context (right-click) menu of the document, too.
-The function draws a given number of instances on the active
-page of the document, with constant or dynamic space between each two of them.</p>
-<p>When invoked, the following dialog appears:</p>
-<img class="big" src="pictures/add_instances_options.png" alt="Add Instances options dialog">
-<p>The first two fields set the number of instances to be drawn and their length.
-Next two fields set the starting point from which to start drawing. If the cursor
-was in the document drawing area in the time of Add Instances invocation (that is,
-the keyboard shortcut or context-menu was used), the start position fields are
-filled with the cursor position, i.e. drawing will start from the point where
-the cursor was.</p>
-<p>In the Options panel, if the Total width switch is chosen, all the instances
-will be drawn in the place of a width given, so the gaps between instances will be
-calculated to fit this area. On the contrary, the Spacing switch sets constant gaps
-between the instances not limiting the total width.</p>
-<p>All numbers in the dialog are in units of the current page of the document.</p>
-
-<h2 id="message_sequence">Message Sequence</h2>
-<p>The Message Sequence function draws a sequence of messages among selected instances.
-The basic usage is that when one instance sends a message, which is received and
-resent by several other instances and finally received by the last instance, as illustrated
-in the following picture.</p>
-<img src="pictures/message_sequence.png" alt="Message Sequence example">
-<p>The Message Sequence function is accessible via menu
-<code>Check → Drawing → Message Sequence</code>, or <code>Ctrl+Alt+S</code>
-keyboard shortcut or <code>Message Sequence</code> context-menu on instances.
-As for other automatic drawing functions, an options dialog is opened after Message Sequence invocation:</p>
-<img class="big" src="pictures/message_sequence_options.png" alt="Message Sequence options dialog">
-<p>The first option in the dialog determines the direction of the sequence. For each direction, a separate
-message label may be specified in the Left and Right Message Captions input boxes. Uni- and bidirectional
-message sequences are supported.</p>
-<p>Starting Y-position determines the instances, among which the sequence is to be drawn.
-The initial set of instances is taken according to current selection:
- <ul>
- <li>if there are no instances selected, all instances on the page are taken;</li>
- <li>if there is exactly one instance selected, then SCStudio waits for another instance
- to be selected;</li>
- <li>otherwise, all selected instances are taken into account.</li>
- </ul>
-From all of these instances, the leftmost and the rightmost instances are recognized as the
-first and last instance in the message sequence. Between these two, all other instances crossing
-an imaginary horizontal line at height equal to Starting Y-position are qualified for the message sequence.
-(During the options dialog, these two instances are marked with red color.)</p>
-<p>The Starting Y-position has a default value of mouse position, so the most comfortable way of invoking
-Message Sequence is using the context-menu on the first instance at the point where the sequence should start,
-followed by selecting the last instance, to which the sequence shall come.</p>
-</p>
-<p>The next two input boxes, Vertical space between messages and Vertical space between left and right sequence
-define the vertical space between to subsequent messages on the same instance.</p>
-<p>The last options group determines treatment of coregions found in the way of the message sequence.
-Such a situation may be forbidden (by the first choice in the dialog) or ignored (the second choice –
-the incident messages are simply attached to the coregion without any order), or the messages passing
-through a coregion may be ordered by ordering line or side-side ordering.</p>
-
-
-</body>
-</html>
Copied: trunk/doc/help/frontend/automatic_drawing.html (from rev 918, trunk/doc/help/frontend/automatic-drawing.html)
===================================================================
--- trunk/doc/help/frontend/automatic_drawing.html (rev 0)
+++ trunk/doc/help/frontend/automatic_drawing.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Automatic Drawing - SCStudio frontend
+ </title>
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Automatic drawing
+ </h1>
+ <p>
+ With all required shapes available in the BMSC and HMSC stencils, it is
+ possible to draw virtually any MSC diagram. In practice, there are many
+ stereotypes, however. SCStudio helps the user draw some frequently used
+ patterns by several automatic drawing functions.
+ </p>
+ <h2 id="add_instances">
+ Add Instances
+ </h2>
+ <p>
+ The first of them is the <code>Add Instances</code> function
+ accessible via menu <code>Check → Drawing → Add Instances</code>,
+ or <code>Ctrl+Alt+F</code> keyboard shortcut. It is available in
+ the context (right-click) menu of the document, too. The function draws a
+ given number of instances on the active page of the document, with
+ constant or dynamic space between each two of them.
+ </p>
+ <p>
+ When invoked, the following dialog appears:
+ </p>
+ <img class="big" src="pictures/add_instances_options.png"
+ alt="Add Instances options dialog" />
+ <p>
+ The first two fields set the number of instances to be drawn and their
+ length. Next two fields set the starting point from which to start
+ drawing. If the cursor was in the document drawing area in the time of Add
+ Instances invocation (that is, the keyboard shortcut or context-menu was
+ used), the start position fields are filled with the cursor position, i.e.
+ drawing will start from the point where the cursor was.
+ </p>
+ <p>
+ In the Options panel, if the Total width switch is chosen, all the
+ instances will be drawn in the place of a width given, so the gaps between
+ instances will be calculated to fit this area. On the contrary, the
+ Spacing switch sets constant gaps between the instances not limiting the
+ total width.
+ </p>
+ <p>
+ All numbers in the dialog are in units of the current page of the
+ document.
+ </p>
+ <h2 id="message_sequence">
+ Message Sequence
+ </h2>
+ <p>
+ The Message Sequence function draws a sequence of messages among selected
+ instances. The basic usage is that when one instance sends a message,
+ which is received and resent by several other instances and finally
+ received by the last instance, as illustrated in the following picture.
+ </p>
+ <img src="pictures/message_sequence.png" alt="Message Sequence example" />
+ <p>
+ The Message Sequence function is accessible via menu <code>Check →
+ Drawing → Message Sequence</code>, or <code>Ctrl+Alt+S</code>
+ keyboard shortcut or <code>Message Sequence</code> context-menu
+ on instances. As for other automatic drawing functions, an options dialog
+ is opened after Message Sequence invocation:
+ </p>
+ <img class="big" src="pictures/message_sequence_options.png"
+ alt="Message Sequence options dialog" />
+ <p>
+ The first option in the dialog determines the direction of the sequence.
+ For each direction, a separate message label may be specified in the Left
+ and Right Message Captions input boxes. Uni- and bidirectional message
+ sequences are supported.
+ </p>
+ <p>
+ Starting Y-position determines the instances, among which the sequence is
+ to be drawn. The initial set of instances is taken according to current
+ selection:
+ </p>
+ <ul>
+ <li>
+ if there are no instances selected, all instances on the page are taken;
+ </li>
+ <li>
+ if there is exactly one instance selected, then SCStudio waits for
+ another instance to be selected;
+ </li>
+ <li>
+ otherwise, all selected instances are taken into account.
+ </li>
+ </ul>
+ From all of these instances, the leftmost and the rightmost instances are
+ recognized as the first and last instance in the message sequence. Between
+ these two, all other instances crossing an imaginary horizontal line at
+ height equal to Starting Y-position are qualified for the message sequence.
+ (During the options dialog, these two instances are marked with red color.)
+ <p>
+ The Starting Y-position has a default value of mouse position, so the most
+ comfortable way of invoking Message Sequence is using the context-menu on
+ the first instance at the point where the sequence should start, followed
+ by selecting the last instance, to which the sequence shall come.
+ </p>
+ <p>
+ The next two input boxes, Vertical space between messages and Vertical
+ space between left and right sequence define the vertical space between to
+ subsequent messages on the same instance.
+ </p>
+ <p>
+ The last options group determines treatment of coregions found in the way
+ of the message sequence. Such a situation may be forbidden (by the first
+ choice in the dialog) or ignored (the second choice - the incident
+ messages are simply attached to the coregion without any order), or the
+ messages passing through a coregion may be ordered by ordering line or
+ side-side ordering.
+ </p>
+ </body>
+</html>
Deleted: trunk/doc/help/frontend/message-numbering.html
===================================================================
--- trunk/doc/help/frontend/message-numbering.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/frontend/message-numbering.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -1,70 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<title>Message Numbering – SCStudio frontend</title>
-<link href="../help.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<h1>Message Numbering</h1>
-<p>Message numbering allows users to enumerate all types of message shapes (left, right, lost, found).<br>
-You can enumerate all messages on the active page (if no messages are selected) or the selection.<br>
-</p>
-
-<h2>Enable message numbering</h2>
-<p>By pressing Message numbering button <img src="pictures/icon_message_enumeration.png" alt="Message Numbering">, via menu <code>Check->Drawing->Message numbering->Message numbering</code> or by using hotkey <Code>Ctrl+Alt+E</Code> the dialog with options will be shown:</p>
-
-<p>
-<img src="pictures/message_numbering_options.png" alt="Message Numbering options dialog">
-</p>
-
-<p>You can choose:<br>
-- specific numbering type (numbers, letters, capital letters, romans)<br>
-- starting index (1-9999 for number, letters and capital letters and 1-3999 for romans)<br>
-- and additional string following the index such as ".", "-", … (max 4 chars). A space between the index and the message label is added automatically.<br>
-</p>
-
-<p>
-When the OK button is pressed, messages are numbered according to their positions on the page from left to right and then from top to bottom.<br>
-Already numbered messages will be overwritten by new numbering.
- </p>
-
-<h2>Disable message numbering</h2>
-<p>Numbering can be deleted by pressing Delete numbering button <img src="pictures/icon_message_enumeration_disable.png" alt="Disable message numbering"> on the toolbar, via menu <code>Check->Drawing->Message numbering->Delete numbering</code> or by using hotkey <Code>Ctrl+Alt+D.</Code></p>
-
-<p>
-Using <code>Delete numbering</code> on selection causes other messages indexes will be recomputed. <br>
-If no selection is used all numbering indexes will be deleted.
-</p>
-
-<h2>Numbering group selection</h2>
-<p>When a group of messages is numbered, user can select it by right-click on any of numbered messages from group and choose <code>Select numbering group</code> from context menu. Example is shown in the following picture:</p>
-
-<p>
-<img src="pictures/select_numbering_group.png" alt="Select numbering group">
-</p>
-
-<h2>Auto numbering</h2>
-<p>New messages can be automatically numbered after they are dropped on the page. Specific behavior can be set via menu <code>Check->Drawing->Settings</code>, tab Numbering. Following dialog will be shown:</p>
-
-<p>
-<img src="pictures/message_numbering_autoenum_options.png" alt="Auto numbering options">
-</p>
-
-<p>
-Options are:<br>
-</p>
-
-<p>
-<code>automatic numbering new messages</code><br>
- - sets whether auto numbering is enabled, otherwise all other options are disabled.<br><br>
-<code>as nearest message</code><br>
- - new messages will be numbered according to the group of the closest message on the active page. All message indexes in the current group will be recounted. If the closest message isn't numbered, new one won't be either. <br>
-<code>as nearest numbered message</code><br>
- - new messages will be numbered according to the closest <b>numbered</b> message on the active page. If there are no numbered messages on the active page you can choose between: <br><br>
- <code>don't number</code><br>
- - don't number new messages if there are no numbered messages on the page.<br>
- <code>use numbering style</code><br>
- - use specific numbering style if there are no numbered messages on the page.<br>
-</p>
-</body>
-</html>
\ No newline at end of file
Deleted: trunk/doc/help/frontend/message-snapping.html
===================================================================
--- trunk/doc/help/frontend/message-snapping.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/frontend/message-snapping.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -1,41 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<title>Message Snapping – SCStudio frontend</title>
-<link href="../help.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<h1>Message Snapping</h1>
-<p>When a message is dropped onto the drawing a user has to connect this message to the instances manually. If Message snapping is enabled then all new messages are automatically snapped to the nearest instances as soon as the user releases the mouse button. The nearest instances are taken from the mouse position.</p>
-
-<p>Snapping can be enabled via <code>Check -> Drawing -> Settings...</code>, tab Snap & Glue. Following dialog will be shown:</p>
-
-<p>
-<img src="pictures/message_snapping_options.png" alt="Message Snapping options dialog">
-</p>
-
-<p>
-Options are:<br>
-<code>Enable/disable message snapping</code><br>
- - sets whether message snapping is enabled, otherwise all other options are disabled.
-</p>
-
-<p>
-When the message is already dropped on the page, user can still use snapping. As the message is moved, it automatically snaps to the nearest instance(s) (if exists). Since the message can be oblique, three types of snapping are provided:<br><br>
-<code>straighten</code><br>
- - the message is straighten on the current location of the mouse cursor and snapped to instance(s).<br>
-<code>preserve vertical distance between send - receive</code><br>
- - endpoint(s) of the message are horizontally stretched and snapped to the nearest instance(s).<br>
-<code>preserve slope</code><br>
- - the message stays obliqued as it was. The endpoint(s) will be prolonged to the nearest instance(s).<br>
-</p>
-
-<h2>Multiple message snapping</h2>
-<i>Not implemented yet</i>
-
-<h2>Restrictions</h2>
-
-- Lost and Found messages are snapped only at one endpoint.<br>
-- Messages can be snapped only to the instances lines. Instance's head and end symbols are ignored.<br>
-
-
Copied: trunk/doc/help/frontend/message_snapping.html (from rev 918, trunk/doc/help/frontend/message-snapping.html)
===================================================================
--- trunk/doc/help/frontend/message_snapping.html (rev 0)
+++ trunk/doc/help/frontend/message_snapping.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Message Snapping - SCStudio frontend
+ </title>
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Message Snapping
+ </h1>
+ <p>
+ When a message is dropped onto the drawing a user has to connect this
+ message to the instances manually. If Message snapping is enabled then all
+ new messages are automatically snapped to the nearest instances as soon as
+ the user releases the mouse button. The nearest instances are taken from
+ the mouse position.
+ </p>
+ <p>
+ Snapping can be enabled via <code>Check -> Drawing -> Settings...</code>,
+ tab Snap & Glue. Following dialog will be shown:
+ </p>
+ <p>
+ <img src="pictures/message_snapping_options.png"
+ alt="Message Snapping options dialog" />
+ </p>
+ <p>
+ Options are:<br /> <code>Enable/disable message snapping</code><br />
+    - sets whether message snapping is enabled, otherwise all
+ other options are disabled.
+ </p>
+ <p>
+ When the message is already dropped on the page, user can still use
+ snapping. As the message is moved, it automatically snaps to the nearest
+ instance(s) (if exists). Since the message can be oblique, three types of
+ snapping are provided:<br /><br /> <code>straighten</code><br />
+   - the message is straighten on the current location of the
+ mouse cursor and snapped to instance(s).<br /> <code>preserve
+ vertical distance between send - receive</code><br />
+   - endpoint(s) of the message are horizontally stretched and snapped
+ to the nearest instance(s).<br /> <code>preserve slope</code><br />
+   - the message stays obliqued as it was. The endpoint(s) will
+ be prolonged to the nearest instance(s).<br />
+ </p>
+ <h2>
+ Multiple message snapping
+ </h2>
+ <i>Not implemented yet</i>
+ <h2>
+ Restrictions
+ </h2>
+ - Lost and Found messages are snapped only at one endpoint.<br /> -
+ Messages can be snapped only to the instances lines. Instance's head and end
+ symbols are ignored.<br />
+ </body>
+</html>
Deleted: trunk/doc/help/frontend/shape-selection.html
===================================================================
--- trunk/doc/help/frontend/shape-selection.html 2010-09-16 12:05:28 UTC (rev 937)
+++ trunk/doc/help/frontend/shape-selection.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -1,30 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<title>Shape Selection – SCStudio frontend</title>
-<link href="../help.css" rel="stylesheet" type="text/css">
-</head>
-<body>
-<h1>Shape Selection</h1>
-<p>On top of standard Visio functions for selecting shapes (such as <code>Ctrl+A</code>
-shortcut for selecting all shapes), SCStudio offers several useful selection functions.</p>
-<p>The first toolbar button
-<img src="pictures/icon_select_instances.png" alt="Select instances button">
-selects all instances in the current page of active document. The second button
-<img src="pictures/icon_select_messages.png" alt="Select messages button">
-selects all messages in the current page of active document. These functions are
-also available via menu
-<code>Check → Drawing → Select → All Instances</code>, or
-<code>All Messages</code>, respectively. Keyboard shortcuts are assigned to
-these functions, too: <code>Ctrl+Alt+I</code> for selecting all instances and
-<code>Ctrl+Alt+M</code> for selecting all messages.</p>
-<p>While holding <code>Ctrl</code> or <code>Shift</code>, the first two buttons
-alter their face and functionality, however:
-<img src="pictures/icon_select_add_instances.png" alt="Add instances to selection button">
-<img src="pictures/icon_select_add_messages.png" alt="Add messages to selection button">
-In that case, they <em>add</em> all
-instances (or messages) to the current selection instead of making a new
-selection.</p>
-
-</body>
-</html>
Copied: trunk/doc/help/frontend/shape_selection.html (from rev 918, trunk/doc/help/frontend/shape-selection.html)
===================================================================
--- trunk/doc/help/frontend/shape_selection.html (rev 0)
+++ trunk/doc/help/frontend/shape_selection.html 2010-09-16 12:14:08 UTC (rev 938)
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>
+ Shape Selection - SCStudio frontend
+ </title>
+ <link href="../help.css" rel="stylesheet" type="text/css" />
+ </head>
+ <body>
+ <h1>
+ Shape Selection
+ </h1>
+ <p>
+ On top of standard Visio functions for selecting shapes (such as <code>Ctrl+A</code>
+ shortcut for selecting all shapes), SCStudio offers several useful
+ selection functions.
+ </p>
+ <p>
+ The first toolbar button <img src="pictures/icon_select_instances.png"
+ alt="Select instances button" /> selects all instances in the current page
+ of active document. The second button <img
+ src="pictures/icon_select_messages.png" alt="Select messages button" />
+ selects all messages in the current page of active document. These
+ functions are also available via menu <code>Check → Drawing →
+ Select → All Instances</code>, or <code>All Messages</code>,
+ respectively. Keyboard shortcuts are assigned to these functions, too:
+ <code>Ctrl+Alt+I</code> for selecting all instances and <code>Ctrl+Alt+M</code>
+ for selecting all messages.
+ </p>
+ <p>
+ While holding <code>Ctrl</code> or <code>Shift</code>,
+ the first two buttons alter their face and functionality, however: <img
+ src="pictures/icon_select_add_instances.png"
+ alt="Add instances to selection button" /> <img
+ src="pictures/icon_select_add_messages.png"
+ alt="Add messages to selection button" /> In that case, they <em>add</em>
+ all ins...
[truncated message content] |
|
From: <xr...@us...> - 2011-12-22 23:24:24
|
Revision: 1246
http://scstudio.svn.sourceforge.net/scstudio/?rev=1246&view=rev
Author: xrehak
Date: 2011-12-22 23:24:18 +0000 (Thu, 22 Dec 2011)
Log Message:
-----------
"Rozcvicka" added into examples.
Added Paths:
-----------
trunk/doc/help/examples/
trunk/doc/help/examples/Client-Proxy-Server_Registration/
trunk/doc/help/examples/Client-Proxy-Server_Registration/Client-proxy-server_registration.vsd
Added: trunk/doc/help/examples/Client-Proxy-Server_Registration/Client-proxy-server_registration.vsd
===================================================================
(Binary files differ)
Property changes on: trunk/doc/help/examples/Client-Proxy-Server_Registration/Client-proxy-server_registration.vsd
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <koc...@us...> - 2010-09-17 21:09:14
|
Revision: 965
http://scstudio.svn.sourceforge.net/scstudio/?rev=965&view=rev
Author: kocianon
Date: 2010-09-17 21:09:07 +0000 (Fri, 17 Sep 2010)
Log Message:
-----------
adding menu to acyclic help for test up
Modified Paths:
--------------
trunk/doc/help/acyclic/acyclic.html
trunk/doc/help/help.css
trunk/doc/help/index.html
Modified: trunk/doc/help/acyclic/acyclic.html
===================================================================
--- trunk/doc/help/acyclic/acyclic.html 2010-09-17 19:22:16 UTC (rev 964)
+++ trunk/doc/help/acyclic/acyclic.html 2010-09-17 21:09:07 UTC (rev 965)
@@ -11,6 +11,105 @@
<link href="../help.css" rel="stylesheet" type="text/css" />
</head>
<body>
+ <div class="menu">
+ <h1>
+ Sequence Chart Studio
+ </h1>
+ <ul>
+ <li>
+ <a href="../frontend.html">Microsoft Visio Front-end</a>
+ <ul>
+ <li>
+ <a href="../frontend/shape_selection.html">Shape Selection</a>
+ </li>
+ <li>
+ <a href="../frontend/automatic_drawing.html">Automatic Drawing</a>
+ </li>
+ <li>
+ <a href="../frontend/message_numbering.html">Message Numbering</a>
+ </li>
+ <li>
+ <a href="../frontend/message_snapping.html">Message Snapping</a>
+ </li>
+ <li>
+ <a href="../frontend/shortcuts.html">Keyboard Accelerators</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="../algorithms.html">Verification Algoritms</a>
+ <ul>
+ <li>
+ <a href="../acyclic/acyclic.html">Acyclic property</a>
+ </li>
+ <li>
+ <a href="../boundedness/boundedness.html">Universal Boundedness</a>
+ </li>
+ <li>
+ <a href="../deadlock/deadlock.html">Deadlock</a>
+ </li>
+ <li>
+ <a href="../fifo/fifo.html">FIFO</a>
+ </li>
+ <li>
+ <a href="../livelock/livelock.html">Livelock</a>
+ </li>
+ <li>
+ <a href="../localchoice/localchoice.html">Nonlocal Choice</a>
+ </li>
+ <li>
+ <a href="../race/race.html">Race Condition</a>
+ </li>
+ <li>
+ <a href="../realizability/realizability.html">Strong Realizability</a>
+ </li>
+ <li>
+ <a href="../recursivity/recursivity.html">Non-recursivity</a>
+ </li>
+ <li>
+ <a href="../time_consistency/time_consistency.html">Time Consistency</a>
+ </li>
+ <li>
+ <a href="../time_syntax/time_syntax.html">Correct Time Constraint
+ Syntax</a>
+ </li>
+ <li>
+ <a href="../time_trace_race/time_race.html">Time Race</a>
+ </li>
+ <li>
+ <a href="../unique_instance/unique_instance.html">Unique Instance
+ Names</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="../membership/membership.html">Drawing Membership</a>
+ </li>
+ <li>
+ <a href="../montecarlo/montecarlo.html">Monte Carlo Simulation</a>
+ </li>
+ <li>
+ <a href="../transformers.html">Drawing Transformers</a>
+ </li>
+ <li>
+ <ul>
+ <li>
+ <a href="../beautify/beautify.html">Beautify</a>
+ </li>
+ <li>
+ <a href="../time_tighten/time_tighten.html">Tighten Time</a>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <div class="footer">
+ <p><a href="http://scstudio.sourceforge.net/" target="_blank">scstudio homepage</a></p>
+ <p><a href="http://sourceforge.net/projects/scstudio/" target="_blank">scstudio on sourceforge</a></p>
+ <p>The software is freely available under <a target="_blank" href="http://www.gnu.org/licenses/lgpl.html">LGPL</a>.</p>
+ <p>© 2010</p>
+ </div>
+ </div>
+ <div class="content">
<h1>Acyclic property</h1>
<p>
ensures that there is no cyclic dependency among events in an BMSC. Such a
@@ -67,5 +166,6 @@
</ul>
</li>
</ul>
+ </div>
</body>
</html>
Modified: trunk/doc/help/help.css
===================================================================
--- trunk/doc/help/help.css 2010-09-17 19:22:16 UTC (rev 964)
+++ trunk/doc/help/help.css 2010-09-17 21:09:07 UTC (rev 965)
@@ -1,7 +1,9 @@
-body {
+html,body {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 1.0em;
color: #000000;
+ width: 950px;
+ height: 100%;
}
p {
margin-top: 0em;
@@ -30,6 +32,17 @@
font-size: 1em;
}
+a {
+ color: #003366; font-weight: bold; text-decoration: none;
+}
+
+a:hover {
+ text-decoration: underline;
+}
+
+.menu ul { padding-left: 25px; }
+.menu ul ul { margin-bottom: 15px; }
+
ul.gallery { clear: both; }
ul.gallery li { list-style-type: none; float: left; }
ul.gallery li ul li { float: none; text-align: center; font-size: 15px; }
@@ -37,3 +50,8 @@
ul.gallery ul { padding:20px; margin:20px; border:1px #B4B4B4 solid;}
+
+.menu { float: left; width: 250px; border: 1px solid #b4b4b4; padding: 4px; position: relative; font-size: 12px; margin-right: 700px}
+.menu h1 { text-align: center; margin-bottom: 30px; }
+.footer {text-align: center; margin-top: 45px; font-size: 10px; line-height: 5px; }
+.content { float: right; position: absolute; margin-left: 300px; max-width: 800px; }
Modified: trunk/doc/help/index.html
===================================================================
--- trunk/doc/help/index.html 2010-09-17 19:22:16 UTC (rev 964)
+++ trunk/doc/help/index.html 2010-09-17 21:09:07 UTC (rev 965)
@@ -102,5 +102,11 @@
</ul>
</li>
</ul>
+ <div class="footer">
+ <p><a href="http://scstudio.sourceforge.net/" target="_blank">scstudio homepage</a></p>
+ <p><a href="http://sourceforge.net/projects/scstudio/" target="_blank">scstudio via sourceforge</a></p>
+ <p>The software is freely available under <a href="http://www.gnu.org/licenses/lgpl.html">LGPL</a>.</p>
+ <p>© 2010</p>
+ </div>
</body>
</html>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|