Lifelines in TDL - Defined Gates, Interactions, Solutions and Decisions
Currently defined lifelines in TDL gate instances, interactions, problems faced in tool implementations, proposed solutions, and decisions made. Explore how gate instances and lifelines are represented, along with the challenges faced and innovative solutions proposed in TDL. Dive into the decision-making process for supporting multiple solutions and the rationale behind choosing specific approaches for better system specification practices.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Lifelines in TDL Gy rgy R thy L.M.Ericsson 1
Currently defined Lifelines: gate instances One component instance symbol contains ALL gates of that component 2
Problems Current tool prototype implementations faced some difficulties with this Difficult to map to UML More difficult to implement in other graphical frameworks The STF has looked at possible alternative solutions that will be shown on the next slides
Proposed solution 1 Lifelines: gate instances A component instance has as many symbols as many gates it has Introduced by the Reference Implementation Due lack of time 5
Problem in Solution 1 Is Action related also to OtherComp? No, only to ComponentOne, but may be misunderstood Similarly for Function call, Verdict assignment, Assertion, If a lifeline of a component is far from other lifelines of the same component, may be forgotten when an Action, etc. drawn G3 on picture To be able to handle component-related actions, etc., the lifelines of the same component instance shall be placed next to each other Added value: ???? 6
Proposed solution 2 Lifelines: component instances One lifeline represents ALL gate instances of that component UML-like This notation often used in interoperability test standards Consequence: gate names if required shall be given in interactions 7
MTS-TDL decisions requested- 1/3 Which solutions to be supported? Solution 1, solution 2, both or none? Ericsson s proposal: In addition to the current notation, add solution 2 to the standard - APPROVED (double check other notations) Reasons Solution 1: Could lead to readability problems; could lead to unambiguity in handling component data, timers etc. Solution 2: Solves the problem and in addition provides better support for interoperability test descriptions and typical system specification practices. It provides better support to incremental TD design 9
MTS-TDL decisions requested -2/3 Shall tools support all or just one way to be compliant with TDL? Ericsson s proposal: Taking into account the different use cases (UML mapping and incremental design), tools may be compliant by supporting only one of the notations - APPROVED (also applies to other cases with alternative notations - e.g. packages - double check and add constraints if applicable, refine conformance statement with different conditions and applicability) 10
MTS-TDL decisions requested -3/3 On a diagram only one version shall be used or allow mixed notation? Ericsson s proposal: Allow mixing current notation and solution 2 11
MTS-TDL decisions requested -3/3 On a diagram only one version shall be used or allow mixed notation? Ericsson s proposal: Allow mixing current notation and solution 2 Reason No harm, but provides better support to incremental TD design Only one notation per component (no mixing within a component instance) APPROVED 12
