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 Aligned with TTCN-3 2nd edition

Just a small example 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 self P1 CP GuestType gPCOtype pCPtype alt charstring ? standardConversation fail inconc

GFT v2 Document Main sections Annex 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

GFT at ETSI The STF 187 Team One CR, but can be rejected 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

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)

ITU View ETSI View GFT TTCN-3 Core Other parts of TTCN-3 Engine 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

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

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

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

Test architecture Test component classes SUT classes

Test Case Initial test configurations Test behavior

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

Test behavior Explicit verdict setting