[savara-commits] savara SVN: r428 - in trunk/docs/gettingstartedguide/src/main/en-US: module and 1 other directory.
do-not-reply at jboss.org
do-not-reply at jboss.org
Fri Oct 1 06:02:07 EDT 2010
Author: objectiser
Date: 2010-10-01 06:02:06 -0400 (Fri, 01 Oct 2010)
New Revision: 428
Added:
trunk/docs/gettingstartedguide/src/main/en-US/images/ExpectedToFail.png
Modified:
trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml
Log:
Added validation aspects to the Testable Architecture Project section.
Added: trunk/docs/gettingstartedguide/src/main/en-US/images/ExpectedToFail.png
===================================================================
(Binary files differ)
Property changes on: trunk/docs/gettingstartedguide/src/main/en-US/images/ExpectedToFail.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml 2010-09-30 19:57:46 UTC (rev 427)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml 2010-10-01 10:02:06 UTC (rev 428)
@@ -4,34 +4,37 @@
<chapter id="tap">
<title>Testable Architecture Project</title>
- <para>
- The previous sections have discussed the various phases of the software development
- lifecycle, and the artifacts that can be created. They have also outlined some
- validation performed between the scenarios and choreography, when a specific link
- has been established from the scenario.
- </para>
-
- <para>
- However the aim of the "Testable Architecture" methodology is to provide validation
- between all artifacts, to ensure that artifacts defined at any particular phase
- can be shown to be valid against the artifacts in preceding phases.
- </para>
-
- <para>
- Therefore the concept of a "Testable Architecture Project" or TAP has been introduced.
- This is essentially a file that records information about the artifacts defined in
- each phase of the software development lifecycle, and the relationships between them.
- This file can then be validated to ensure that each artifact, and its dependencies,
- are valid in respect of each other.
- </para>
-
- <para>
- For example, the <filename>purchasing</filename> example contains a TAP file with
- the following contents:
- </para>
-
- <informalexample>
- <programlisting role="XML" ><![CDATA[
+ <section>
+ <title>Managing Dependencies</title>
+
+ <para>
+ The previous sections have discussed the various phases of the software development
+ lifecycle, and the artifacts that can be created. They have also outlined some
+ validation performed between the scenarios and choreography, when a specific link
+ has been established from the scenario.
+ </para>
+
+ <para>
+ However the aim of the "Testable Architecture" methodology is to provide validation
+ between all artifacts, to ensure that artifacts defined at any particular phase
+ can be shown to be valid against the artifacts in preceding phases.
+ </para>
+
+ <para>
+ Therefore the concept of a "Testable Architecture Project" or TAP has been introduced.
+ This is essentially a file that records information about the artifacts defined in
+ each phase of the software development lifecycle, and the relationships between them.
+ This file can then be validated to ensure that each artifact, and its dependencies,
+ are valid in respect of each other.
+ </para>
+
+ <para>
+ For example, the <filename>purchasing</filename> example contains a TAP file with
+ the following contents:
+ </para>
+
+ <informalexample>
+ <programlisting role="XML" ><![CDATA[
<project xmlns="http://www.savara.org/ta/project" xmlns:xsi="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.savara.org/ta/project tap.xsd"
name="Purchasing" version="1.0.0">
@@ -78,74 +81,149 @@
</resource>
</phase>
</project>
- ]]></programlisting>
- </informalexample>
-
- <para>
- The top level element is <emphasis>project</emphasis>, with the <emphasis>name</emphasis>
- and <emphasis>version</emphasis> attributes to define the details of the Testable Architecture
- Project.
- </para>
-
- <para>
- The project then contains <emphasis>phase</emphasis> elements, one for each stage of the
- software development lifecycle we are interested in. These elements are only used to
- segment the artifacts into the different phases, which can be useful for tasks such as
- project management or documentation generation.
- </para>
-
- <para>
- The phase element contains <emphasis>resource</emphasis> elements, one per artifact. A
- resource represents an artifact that is of interest in the Testable Architecture Project.
- </para>
-
- <para>
- The resource element contains one or more of the following elements:
- </para>
-
- <orderedlist>
- <listitem>
- uri
- <para>
- This element is used to define the location of a resource. A URI element is required for
- each environent in which the resource may be accessed, for example, within Eclipse and
- within an SOA Repository.
- </para>
- <para>
- The <emphasis>type</emphasis> attribute defines the type of locator, which will usually
- map onto the environment in which the resource exists. So in this case we are only
- defining URI elements associated with the Eclipse environment.
- </para>
- <para>
- The <emphasis>context</emphasis> attribute defines the local information that can be used
- in the particular environment, to determine where the resource is contained. For example,
- if the environment is Eclipse, the context would be the project name.
- </para>
- <para>
- The <emphasis>locator</emphasis> attribute is used to specify the specific location of
- the resource, within the particular specified context, in the environment type. For example,
- if the environment was Eclipse, then the locator would be the relative path of the resource
- within the project identified in the context attribute.
- </para>
- </listitem>
- <listitem>
- relationship
- <para>
- This element establishes a relationship from the containing resource, to another resource
- identifed by the <emphasis>ref</emphasis> attribute.
- </para>
- <para>
- The relationship element can optionally have additional information associated with it,
- to help clarify the nature of the relationship between the two resources.
- </para>
- <para>
- For example, in the TAP file illustrated above, the two BPEL resources (in the implementation
- phase) have a relationship to the choreography file - however the relationship needs to be
- more specific. We need to indicate what <emphasis>role</emphasis> within that choreography
- the BPEL processes are associated with. The <emphasis>link</emphasis> element enables
- the <emphasis>type</emphasis> to be defined, and a value to be specified in the
- <emphasis>to</emphasis> attribute.
- </para>
- </listitem>
- </orderedlist>
+ ]]></programlisting>
+ </informalexample>
+
+ <para>
+ The top level element is <emphasis>project</emphasis>, with the <emphasis>name</emphasis>
+ and <emphasis>version</emphasis> attributes to define the details of the Testable Architecture
+ Project.
+ </para>
+
+ <para>
+ The project then contains <emphasis>phase</emphasis> elements, one for each stage of the
+ software development lifecycle we are interested in. These elements are only used to
+ segment the artifacts into the different phases, which can be useful for tasks such as
+ project management or documentation generation.
+ </para>
+
+ <para>
+ The phase element contains <emphasis>resource</emphasis> elements, one per artifact. A
+ resource represents an artifact that is of interest in the Testable Architecture Project.
+ </para>
+
+ <para>
+ The resource element contains one or more of the following elements:
+ </para>
+
+ <orderedlist>
+ <listitem>
+ uri
+ <para>
+ This element is used to define the location of a resource. A URI element is required for
+ each environent in which the resource may be accessed, for example, within Eclipse and
+ within an SOA Repository.
+ </para>
+ <para>
+ The <emphasis>type</emphasis> attribute defines the type of locator, which will usually
+ map onto the environment in which the resource exists. So in this case we are only
+ defining URI elements associated with the Eclipse environment.
+ </para>
+ <para>
+ The <emphasis>context</emphasis> attribute defines the local information that can be used
+ in the particular environment, to determine where the resource is contained. For example,
+ if the environment is Eclipse, the context would be the project name.
+ </para>
+ <para>
+ The <emphasis>locator</emphasis> attribute is used to specify the specific location of
+ the resource, within the particular specified context, in the environment type. For example,
+ if the environment was Eclipse, then the locator would be the relative path of the resource
+ within the project identified in the context attribute.
+ </para>
+ </listitem>
+ <listitem>
+ relationship
+ <para>
+ This element establishes a relationship from the containing resource, to another resource
+ identifed by the <emphasis>ref</emphasis> attribute.
+ </para>
+ <para>
+ The relationship element can optionally have additional information associated with it,
+ to help clarify the nature of the relationship between the two resources.
+ </para>
+ <para>
+ For example, in the TAP file illustrated above, the two BPEL resources (in the implementation
+ phase) have a relationship to the choreography file - however the relationship needs to be
+ more specific. We need to indicate what <emphasis>role</emphasis> within that choreography
+ the BPEL processes are associated with. The <emphasis>link</emphasis> element enables
+ the <emphasis>type</emphasis> to be defined, and a value to be specified in the
+ <emphasis>to</emphasis> attribute.
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+
+ <section>
+ <title>Validating a Testable Architecture Project</title>
+
+ <para>
+ To trigger validation of a Testable Architecture Project (TAP), select the <filename>.tap</filename>
+ file and choose the <emphasis>Savara->Validate</emphasis> menu item. If any errors or warnings are
+ detected, they will be recorded as errors in the Problems or Markers view (depending on which
+ perspective is being used).
+ </para>
+
+ <para>
+ If you invoke the validation on the TAP file within the <emphasis>purchasing</emphasis> project,
+ you will find that it will create an error associated with the choreography file, indicating
+ that it does not meet the scenario "InvalidPurchase.scn". This is because this scenario has
+ specifically been created to demonstrate how an error is reported.
+ </para>
+
+ <para>
+ If the scenario is simulated against the choreography, using the green <emphasis>play</emphasis> button on the
+ toolbar, then it will be possible to see specifically where the scenario is not met by the
+ choreography.
+ </para>
+
+ <imageobject>
+ <imagedata fileref="en-US/images/InvalidPurchasePostTest.jpg" align="center" width="5in" />
+ </imageobject>
+
+ <para>
+ In this case, it is because the CreditAgency has returned a credit check failed message, but the
+ Store is still attempting to return a buy confirmed message.
+ </para>
+
+ <para>
+ Its possible that this scenario is valid, and therefore the choreography needs to be updated
+ to cater for this scenario. However in this case, we may just be wanting to represent a
+ <emphasis>negative</emphasis> use case, and therefore deliberately describe a situation we
+ do not want the choreography to handle. Therefore we need to configure the scenario to
+ indicate that the failure is expected.
+ </para>
+
+ <imageobject>
+ <imagedata fileref="en-US/images/ExpectedToFail.png" align="center" width="5in" />
+ </imageobject>
+
+ <para>
+ Simply select the 'send' node for the final interaction between the Store and Buyer, and
+ set the 'Expected to Fail' property to true. This will cause a red boundary to be displayed
+ around the node, indicating that it is expected to fail. Now when the scenario is simulated
+ or validated, if that node does not fail, that will be reported as an error. However if the
+ node does fail as expected, that will be treated as a valid case.
+ </para>
+
+ <para>
+ If the validation of the TAP file is performed again, the error associated with the
+ <filename>InvalidPurchase.scn</filename> should no disappear.
+ </para>
+
+ <para>
+ To experiment with other types of validation that are performed, open the <filename>PurchaseGoods.cdm</filename>
+ and go to the <emphasis>Base Types</emphasis> tab. Then open up the node for
+ <emphasis>Information Types</emphasis> and select the <emphasis>CreditCheckOk</emphasis>
+ entry. In the <emphasis>Properties</emphasis> view, change the <emphasis>element</emphasis>
+ attribute, e.g. appending an 'X' to the "ca:CreditCheckOk" value.
+ </para>
+
+ <para>
+ When the choreography has been saved, re-perform the validation on the TAP file. This
+ should now display 'Type Mismatch' errors against the previously generated BPEL
+ processes, and also flag errors associated with the scenarios.
+ </para>
+
+ </section>
+
</chapter>
More information about the savara-commits
mailing list