Guys.
 
Here are a few questions I would like to raise before the meeting. Some of them may have come up before but I feel I need clarification regarding the proposed changes.
 
If I remember correctly the Instance classes (SUT, Arbiter, TestComponent) were introduced because we felt that we didn't have the authority to change the semantics of i.e. TestComponent which originates from U2TP. What has changed that removes these concerns ?
 
Here is one that I a not sure I understand: "CFGInstances are typed by a Deployable. As an example, the Instances of a Test Suite (A kind of Deployable) would be the instances present in an Interaction." When we are talking about instances here, we mean SUT, Arbiter, TestComponent ? What about TestCase ?
 
I have been wondering why we don't have a direct association between TestCase and TestComponent ? 
 
The compositionality of SUT and TestComponent has been removed. I don't know for the latter, but in the case of SUT I could imagine that it is desirable to model the nesting of SUTs explicitly and not via a typed CFGInstance and CFGDeployable.
 
If TestSuite extends CFGDeployable, shouldn't TestCase as well ?
 
The introduction of Test is convincing, so is the argument regarding the semantics of TestCase and TestSuite. I am bit puzzled by the mixing of conceptual and implementation entities though. I was under the impression that this is not desirable ? I need some clarification on this point. 
Furthermore, if we seem to be concerned about the semantics in this case then that puts an even bigger question mark behind me first question.
 
I am not quite sure about the following. In the previous version a TestCase owned a behaviour which was associated with an Arbiter. So in theory each TestCase in a TestSuite could have a different Arbiter associated with it. That was my assumption anyway.
In the current version a TestSuite owns ONE Arbiter, which thus must be shared by all TestCases in the TestSuite. I would think that this is not what we want ?
 
Are behaviourResource and behaviourLocation in CFGDeployable mandatory ?
 
I feel I know the answer to the following question, but I would like to have it confirmed anyway. Do any of the proposed changes force me to work with externally defined behaviours ?
 
    Stefan

 

-----Original Message-----
From: slucio [mailto:slucio@us.ibm.com]
Sent: 16 May 2003 23:35
To: hyades-dev
Subject: [hyades-dev] Test model updates

Following Joe's email... 

Here are the model updates that we've made with Marcello and Peter. 

1. Creation of the Instance and Deployable concepts 

See common/configuration/Main. CFGDeployable is a superclass of Arbiter, TestComponent, SUT, TestSuite. It maps to a Classifier/Class in the UML space or Java space. A Deployable owns CFGInstances (think class attributes). Those CFGInstances are typed by a Deployable. As an example, the Instances of a Test Suite (A kind of Deployable) would be the instances present in an Interaction. 

The introduction of these new concepts result in the following modifications: 
        - Removal of ArbiterInstance, SUTInstance, TestComponentInstance and DeployableInstance. We have one kind of instance a Depoyable being a superclass of the kinds of Instances that we had in the past. 
        - Removal of the two associations from SUT to SUT, and from Test Component to Test Component. This compositionnality is given by the fact that you can have a TestComponent owning Instances, which can be typed by a TestComponent. Same thing for an SUT. 
        - A lifeline is no longer related to DpeloyableInstance but Deployable 
        - Deployable owns the behaviorResource and behaviorLocation to identify where the behavior of this Deployable is defined (in place of DeployableInstance) 
        - An association from TestComponent to Behavior is removed. This association was created to be able to identify which TestComponent in the Interaction was representing "self" (The Test Suite classifier). This is no loner needed because a Lifeline is associated with a Deployable, and a TestSuite being a Deployable, "self" is a lifeline whose deployable is the TestSuite owning the TestCase the Interaction belongs to. 

2. Creation of a Test superclass for TestCase and TestSuite 
Both a  TestCase and TestSuite are associated with a TestObjective, an ExecutionResult, and a Behavior. Building them on a common interface simplifies the implementation. This doesn't change any of the semantic of the Test Profile because Test is an interface, not a comcept per se. 

3. Multiplicities 
Deployable 1 ------ 0..n Lifeline : A Deployable can be used for several lifelines 
Arbiter 1 ------ 0..1 TestSuite : One should be able to define an Arbiter independently from a TestSuite and reuse it in many suites 

All the modifications are visible in the following diagrams 
common/behavior/interactions/Messages 
common/configuration/Main 
common/testprofile/Main 

I've attached the plugin for your review. We'll meet on Monday at 9:00AM EST. 

Serge