Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004996

ETSI TTCN-3 Quality Checker

T3Q tool

public

17-03-2009 15:45

26-11-2009 14:10

Reporter

Philip Makedonski

Assigned To

Philip Makedonski

Priority

normal

Severity

major

Reproducibility

N/A

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

Release 0.1.0

Target Version

Fixed in Version

Summary

0004996: CR Ordering of Component Element Definitions

Description

This CR is related to quality check requirement: Variables should always be declared first in any TTCN-3 testcase, function or altstep definition. It consists of two parts:

1. Control Part and Component Type definitions shall be analyzed as well

2. There should be a way to define the expected ordering of the Component Element Definitions, since the desired ordering of the elements may vary in different projects, and generally variables may be regarded as less significant in Component Type definitions.

There have been no further comments concerning the other issues discussed below. Thus, until further notice only the above two changes will be considered for this CR.

Relevant correspondence exchange extract:

> > 1. In connection to quality check: Variables should always be declared
> > first in any TTCN-3 testcase, function or altstep definition.
> >
> > => What about component definitions and control part definitions?
> > (currently only test case function and altstep definitions are
> > analyzed) It seems logical to check at least component definitions as
> > well, although port definitions and timers may have a higher priority
> > in component definitions..
>
> Ok, add control part and component type definitions.
> In comptype, the default order should be: port, timer, constant and variable
>
> Is it possible to add a parameter that controls the order of definitions?

This is possible of course, it may however make configuration a little complicated. Such a CR needs to be more precise as well: is only one parameter to control the order of definitions within a component definition desired (shouldn't be all too complicated to implement or configure), or is one parameter per definition type (one for the order in function, one for altstep, test case and control part definitions) desired (too complicated to configure and difficult to implement). I suspect the former will be desired. On the other hand, we may simply require that variables are defined in the beginning of all definitions, except component type definitions, in which case variables shall be defined at the end of the definition (which will be not so flexible).

Issue History
Date Modified	Username	Field	Change
17-03-2009 15:45	Philip Makedonski	New Issue
17-03-2009 15:45	Philip Makedonski	Status	new => assigned
17-03-2009 15:45	Philip Makedonski	Assigned To	=> Philip Makedonski
26-11-2009 14:10	Philip Makedonski	Status	assigned => resolved
26-11-2009 14:10	Philip Makedonski	Resolution	open => fixed

Relationships