S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Feature Description and Feature Interaction Analysis with Use Case Maps and L OTOS Daniel Amyot et al. SITE, University of Ottawa, Canada FIW’00, Glasgow, May 19, 2000

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Collaborators n Leïla Charfi, University of Ottawa n Nicolas Gorse, University of Ottawa n Tom Gray, Mitel Corporation n Luigi Logrippo, University of Ottawa n Jacques Sincennes, University of Ottawa n Bernard Stépien, University of Ottawa n Tom Ware, Mitel Corporation S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Introduction n New methodology for feature design, specification and validation n Jointly by U. of Ottawa and Mitel Corp. n Application to new product –Enterprise private networks –Agent-based call model –Features: Outgoing Call Screening, Call Forward Always, Call Forward Busy, Call Hold, Recall, Call Pickup, Call Transfer

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Approach n Use Case Maps –Causal scenario notation –Description and documentation of requirements and high-level designs n L OTOS –Formal algebraic specification language –Powerful validation & verification tools and techniques, enabling FI detection n Both have an FI history, in isolation

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Related Work n Formal Methods –Precise, mathematical, but low penetration n Scenario-Driven Approaches –Higher level of acceptance, accessible to a broad range of readers; but integration of scenarios and V&V remains difficult n Some Well-Known Approaches –SDL and Message Sequence Charts –Unified Modeling Language

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Two Complementary Techniques n Use Case Maps –Visual and intuitive scenario notation –Capture, integrate, and help reasoning about functional requirements –FI avoidance n L OTOS –Formalization, abstract prototyping and validation –Automated FI detection

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA In This Presentation... n Use Case Maps Notation n System Architecture with Call Model UCMs n UCM-Based FI Avoidance n From UCMs to L OTOS n Validation and FI Detection with L OTOS n Traces, MSCs and Animations n Conclusions

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Use Case Maps Notation n Visualization of causal relationships between responsibilities allocated to abstract components AliceAgentAAgentBBob [busy] msg mb [idle] vrfy upd req ring Start PointResponsibilityEnd PointCondition Component

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Refining UCMs with Message Exchanges AliceAgentAAgentBBob req ring vrfy upd req ring vrfy upd BobAliceSwitch SN AliceAgentAAgentBBob AliceSwitchSNBob req msg1 ring vrfy upd req msg2 ring vrfy upd msg5 msg4 msg3

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Integrating UCM Scenarios UserOAgentOAgentTUserT req msg ring StubTStubO in2 out4 out3 vrfy upd [idle] [busy] mb mrb Terminating plug-in in1 out1 Originating plug-in OCS plug-in in1 out2 out1 chk [allowed] [denied] md OCSlist Plug-ins for StubO Plug-in for StubT Root Map

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA System Architecture n Agents types: –Device Agents (D AGENT or DEB) –Personal Agents (P AGENT or CEB) –Functional Agents (F AGENT or LEB) n Agents roles: –Originating, Terminating, 3rd party n Call objects instantiated dynamically

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Design of the Call Model UCMs n Created by industrial partners –1 senior designer and 2 junior designers n More than 100 UCMs –Basic call and 10 features –Structured with 60 stubs –7 levels deep –Many plug-ins reused –Recently added 3 features, low impact –Use of the UCM Navigator

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA FI Avoidance at UCM Level n Many FI solved at integration time n Before the generation of a prototype n Remaining FI mostly in dynamic stubs n Several problems detected by inspection –Non-determinism in selection policies –Erroneous UCMs –Ambiguous UCMs, lack of comments n New techniques (e.g. Namakura et al.)

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Towards L OTOS n ISO standard, process algebra n Powerful constructs –Composition: multiway rendezvous –Hiding –Abstract Data Types (ADT) –Flexible inter-process synchronization n Constructs similar to those of UCMs

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA From UCMs to L OTOS Start/end points Responsibilities Agents/components Stubs Plug-ins Inter-path causality Databases, conditions Visible gates Hidden gates Processes Processes (implement selection policies) Processes Hidden inter-process synchronization (msg) Abstract Data Types

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Validation n Scenarios derived from UCMs paths for: –Basic System Properties –Individual Features Properties –Feature Interaction n Scenarios simpler than specification –Few features considered at once –No component, close to requirements n Verdicts obtained with LOLA

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA FI Analysis Phase n FI team: 2 students n No major fault, but several problems detected n L OTOS specification: 2450 lines n 36 test scenarios: 1300 lines n Currently being extended in new phase n Other L OTOS -based techniques and tools to be used

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Feature Interaction “Suspiscion” n Derivation of properties of individual features n Analysis in Prolog to determine: –direct and transitive FI –non-determinisim –loops n Generation of FI prone scenarios and configurations

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Traces, MSCs and Animations n L OTOS traces are translated to MSCs by associating direction to gates and identifying sender and receiver entities n Translation of MSCs to L OTOS permits validation against external scenarios n A graphical animator displays a given trace as a structural diagram of the system, in a step-by-step fashion

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Conclusions n UCM-LOTOS approach for specification and validation of telecommunications systems seems feasible and effective n Encouraging results so far, more to come in the near future… n Technology transfer in progress

S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Use Case Maps Web Page Bon appétit!