Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Meeting minutes for Hyades Execution Histories Model Subgroup Meeting on May 9, 2003


Houston, we have a problem!

Different from it's previous incarnation, EMF doesn't support enumeration hierarchies.  I've changed our design getting rid of the TPFReason moving its attributes to TPFVerdictReason and TPFInvocationReason.  This way we are able to codegen and to publish it this week.

We can review this later if there is any detail I have overlook.

Best regards,

Marcelo Paternostro
IBM Toronto Lab
Voice: 1-905-413-3942
Fax: 1-905-413-4920
internet: marcelop@xxxxxxxxxx



Ashish K Mathur/Raleigh/IBM@IBMUS
Sent by: hyades-dev-admin@xxxxxxxxxxx

05/12/2003 05:30 PM
Please respond to hyades-dev

       
        To:        hyades-dev@xxxxxxxxxxx
        cc:        
        Subject:        [hyades-dev] Meeting minutes for Hyades Execution Histories Model Subgroup Meeting on May 9, 2003

       




Attached (and as included text) are the meeting minutes for the Execution Histories Model Subgroup meeting from 09-May-2003. Also attached is the cat file for this section of the model. This is intended to be available in an up-coming drop of Hyades.



Regards,
ashish
------------------------------------------------------------------------
Ashish K. Mathur
Advisory Software Engineer
IBM - SWG - Rational Division
Phone: (919)845-3213      Fax: (919)845-3250
Email: akmathur@xxxxxxxxxx
 
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Execution Histories Model Subgroup, 9-May-2003

Attending
---------
Ashish Mathur                 - IBM Rational Raleigh
Gian Franco Bonini         - SAP
Marcelo Paternostro        - IBM Toronto
Kent Siefkes                 - IBM Rational Raleigh

Discussion
-------------------------
One of the goals at the end of this week was to finalize the execution
histories model and we agreed we have something decent at the end of this meeting.

Finalizing the model
-  Marcelo: Change the 'status' attribute in the TPFStatusEvent to 'verdict'.
   All agreed.
-  Ashish: Change the 'TPFStatusEvent' to 'TPFVerdictEvent'. All agreed.
-  Kent: Should be able to provide a reason when a verdict/invocation
   event is not successful. Agreed on the need to have an attribute to hold
   the reason for a failed verdict event or an invocation event.
        -  Introduced a 'reason' attribute to TPFVerdictEvent to allow
           the specification of a reason for the verdict. The possible values
           for the reason are listed in the TPFVerdictReason enumeration.
           Please refer to the model for details.
        -  When another TestCase is invoked, lot of things could go wrong.
           In some cases, the invoked TestCase may have its own execution
           history created while in other cases, the invocation may never
           have gotten to create one. In either case, a status of the
           invocation is needed, which would be separate from a verdict.
           Added attribute 'status' to the TPFInvocationEvent to indicate
           what happened when the TestCase was invoked. The status could
           be one of successful, unsuccessful or unattempted.
        -  Also, we need to be able to provide a reason for the failure,
           if available. The 'reason' attribute of the TPFInvocationEvent
           will provide such a reason. Possible reasons are listed in the
           TPFInvocationReason enumeration.
-  Kent: Should the Reasons be further specialized based on the
   verdict/status? Should we have TPFErrorReason, TPFFailureReason,
   TPFInconclusiveReason based on the verdict, extend TPFVerdictReason?
   And have TPFUnsuccessfulReason and TPFUnattemptedReason extend from
   TPFInvocationReason?
        - Agreed to not do that since it would lead to enough duplication
        and in the interest of keeping things simple. If there arises a
        strong reason in the future, this could be considered.
-  Marcelo: All attributes in the model have to be
        - public
        - lowercase (with subsequent words starting with capital letters)
        - of the 'String' data type
-  Gian Franco: Do we have to specify even attributes like 'timestamp'
   with a String data type when they are naturally either long or integer?
            -  Agreed to change 'timestamp' to 'Long' data type.
-  Marcelo: Past input was that a test suite is not associated with an
   execution history. Need to re-visit the association of execution
   histories with test suites since a test suite may have  complex behavior.
-  Marcelo: The reference within execution histories of testcases need
   to be a solid EMF design. Marcelo to take this up with the EMF team.
-  Marcelo: Creating an execution history should not make the TestCase
   'dirty' (modified with a need to save). Suggesting the relationship
   between Execution Result and TestCase to be either
        - Unidirectional (recommended)
        - Transient
        - based on a query mechanism
-  Agreed that we have a decent model for execution histories.

Action Items:
-----------------
1. Have the modified class diagram available - Ashish to send Marcelo
2. Publish the modified model and make it available in the next drop - Marcelo
3. Re-visit Execution Histories for Test Suites. - Ashish to add to agenda



#### common.cat has been removed from this note on May 12 2003 by Marcelo Paternostro
#### Hyades Execution Histories Subgroup Meeting Notes May 9, 2003.txt has been removed from this note on May 12 2003 by Marcelo Paternostro


Back to the top