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.
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.
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.
For example, the purchasing example contains a TAP file with
the following contents:
<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">
<phase name="requirements">
<resource id="SuccessfulPurchase.scn">
<uri type="eclipse" context="purchasing" locator="/SuccessfulPurchase.scn" />
</resource>
<resource id="InvalidPurchase.scn">
<uri type="eclipse" context="purchasing" locator="/InvalidPurchase.scn" />
</resource>
</phase>
<phase name="architecture">
<resource id="PurchaseGoods.cdm">
<uri type="eclipse" context="purchasing" locator="/PurchaseGoods.cdm" />
<relationship type="depends" ref="SuccessfulPurchase.scn" />
<relationship type="depends" ref="InvalidPurchase.scn" />
</resource>
</phase>
<phase name="implementation">
<resource id="PurchaseGoodsProcess_Store.bpel">
<uri type="eclipse" context="PurchaseGoodsProcess-Store"
locator="/bpelContent/PurchaseGoodsProcess_Store.bpel" />
<relationship type="depends" ref="PurchaseGoods.cdm" >
<description>
Link from the BPEL process to the 'Store' participant
within the choreography
</description>
<link type="role" to="Store" />
</relationship>
</resource>
<resource id="PurchaseGoodsProcess_CreditAgency.bpel">
<uri type="eclipse" context="PurchaseGoodsProcess-CreditAgency"
locator="/bpelContent/PurchaseGoodsProcess_CreditAgency.bpel" />
<relationship type="depends" ref="PurchaseGoods.cdm" >
<description>
Link from the BPEL process to the 'CreditAgency' participant
within the choreography
</description>
<link type="role" to="CreditAgency" />
</relationship>
</resource>
</phase>
</project>
The top level element is project, with the name and version attributes to define the details of the Testable Architecture Project.
The project then contains phase 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.
The phase element contains resource elements, one per artifact. A resource represents an artifact that is of interest in the Testable Architecture Project.
The resource element contains one or more of the following elements:
-
uri
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.
The type 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.
The context 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.
The locator 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.
-
relationship
This element establishes a relationship from the containing resource, to another resource identifed by the ref attribute.
The relationship element can optionally have additional information associated with it, to help clarify the nature of the relationship between the two resources.
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 role within that choreography the BPEL processes are associated with. The link element enables the type to be defined, and a value to be specified in the to attribute.
To trigger validation of a Testable Architecture Project (TAP), select the .tap
file and choose the Savara->Validate 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).
If you invoke the validation on the TAP file within the purchasing 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.
If the scenario is simulated against the choreography, using the green play button on the toolbar, then it will be possible to see specifically where the scenario is not met by the choreography.
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.
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 negative 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.
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.
If the validation of the TAP file is performed again, the error associated with the
InvalidPurchase.scn should no disappear.
To experiment with other types of validation that are performed, open the PurchaseGoods.cdm
and go to the Base Types tab. Then open up the node for
Information Types and select the CreditCheckOk
entry. In the Properties view, change the element
attribute, e.g. appending an 'X' to the "ca:CreditCheckOk" value.
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.