1 / 14

GFT The Graphical Format of TTCN-3

GFT The Graphical Format of TTCN-3. Ina Schieferdecker. GFT v2. Presents TTCN-3 behavior only Gives local view on test components Based on MSC Uses additional symbols e.g. for ports, altsteps, component handling Defines a one-to-one mapping (up to graphical placement) between CN and GFT

vince
Download Presentation

GFT The Graphical Format of TTCN-3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GFTThe Graphical Format of TTCN-3 Ina Schieferdecker

  2. GFT v2 • Presents TTCN-3 behavior only • Gives local view on test components • Based on MSC • Uses additional symbols e.g. for ports, altsteps, component handling • Defines a one-to-one mapping (up to graphical placement) between CN and GFT • Aligned with TTCN-3 2nd edition

  3. Just a small example altstepGuestDefault() runs on GuestType altstep GuestDefault() runs on GuestType { // *** // *** Purpose: Default behaviour for // *** message based ports // *** [] P1.receive(charstring : ?) { P1.send(standardConversation); repeat; } [] any timer.timeout { setverdict(fail); } [] any port.receive { setverdict(inconc); } } // *** Purpose: Default behaviour for // *** message based ports CP self P1 GuestType pCPtype gPCOtype alt charstring ? standardConversation fail inconc

  4. GFT v2 Document • Main sections • Overview • GFT language concepts • Mapping between GFT and TTCN-3 Core Notation • Module structure • GFT symbols • GFT diagrams • Instances in GFT diagrams • Elements of GFT diagrams • Annex • Annex A (normative): GFT BNF • Annex B (normative): Reference Guide for GFT • Annex C (normative): Mapping Rules from GFT to TTCN-3 Core Notation • Annex D (normative): Mapping Rules from TTCN-3 Core Notationto GFT • Annex E (informative): Examples • Annex F (informative): GFT to MSC Mapping

  5. GFT at ETSI • The STF 187 Team • Paul Baker (Motorola) • Zhen Ru Dai (Uni Lübeck) • Jens Grabowski (Uni Lübeck) • Tamas Kasza (Ericsson) • Claude Martin (Actimage) • Johan Nordin (Telelogic) • Ekkart Rudolph (Uni Munich) • Ina Schieferdecker (FOKUS) • One CR, but can be rejected • Some editorial things

  6. GFT at ITU-T • Issues raised at the ITU-T meeting, March 2002 on Annex F: GFT to MSC mapping: TD0061, TD3043, TD0065 • Answers given to these documents in the resp. MTS#34 TDs • Problem: misconception of that annex at ITU-T • Some issues clarified to be wrong or non-issues • Still some open points • An agreement about the objectives of that annex is very likely • Proposal: • separate Annex F from GFT and make it a separate TR • Revision of this TR on a voluntary basis • Approve GFT (e.g. without Annex F)

  7. ITU View ETSI View GFT Annex C Annex D TTCN-3 Core MSC Part 4 MSC Semantics (?) Other parts of corresponding TTCN-3 modules TTCN-3 Engine Part 4 TTCN-3 Semantics

  8. GFT at OMG • UML Testing Profile RfP adopted in July 2001 • Initial submission submitted Apr., 1st 2002 by • Rational • Motorola • Softeam • Telelogic • Fraunhofer FOKUS • Ericsson • IBM • Uni Lübeck (officially a supporter) • Supporters • iLogix • 41 companies will vote

  9. GFT at OMG • Initial submission • Terminology • Test behavior • Test architecture • No test data • Presentation (and discussion) at Orlando meeting, June 2002 • Next meeting in Lübeck, May 2002 • Final submission delayed after UML 2.0, planned for January 2003

  10. GFT at OMG • Due to • Differences in syntax and semantics of ITU-T MSC and OMG Interaction Diagrams • Concept of using any behavioral diagram for test definition • Proposals from the software testing community • GFT cannot be taken as such (we have to „talk“ meta-model and UML syntax) • However, the UML testing profile will be semantically consistent (in terms of a mapping) with TTCN-3 • Additions • Logical partitions in the data part • Arbiters to separate behavior and verdict handling • Test architecture and initial test configuration • Implicit assumptions about e.g. verdict assignment and timer handling

  11. Test architecture Test component classes SUT classes

  12. Test Case Initial test configurations Test behavior

  13. Test behavior Test behavior reuse Implicit default timer Test behavior invocation Implicit verdict setting

  14. Test behavior Explicit verdict setting

More Related