Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design, testing and implementation phases of protocol design have been too independent of each other Moreover, the testing phase could not be started before the implementation was finished. SOLUTION: Let’s design a methodology, that does design, testing and verification in parallel! Sari Leppänen’s work centers on this idea. Method uses and combines theories of formal specification, verification and testing WHAT’S NEEDED? We need a good (verified) service specification of a protocol, which is recursively refined. Every refinement step must be proven to be sound. Design phase provides inputs to testing phase.

Lyra – Basic Concepts The Lyra methodology can be defined into 4 phases: 1.Service Specification 2.Service Decomposition 3.Service Distribution 4.Service Implementation Basically, three first steps correspond to the stages in protocol standardization However, Lyra methodology is general – I.e. it can be applied to the development of any service-oriented, communicating system. Design phases can be applied to the system architecture design as well as to the implementation of a protocol

Service Specification In the service specification phase, we model the service as a BLACK BOX We define the LOGICAL COMMUNICATION POINTS of the system (for provided services and used services) and specify the signalling in these in terms of STATEMACHINES. Basically, the service specification phase shows how the service interacts with its environment, i.e. describes the externally observable behaviour of the system. Service Specification model provides an executable model of the functional requirements set for the system Service Specification is canonical – i.e. every refinement step must produce the same external behaviour as Service Specification Formal verification used for validation (visual verification, model checking…)

Service Specification - Example data_ind(data) ABP sender_port receiver_port receiver ABP data_req(data) data_cnf sender ABP

Service Specification with Tau/Developer here, the state machine describes only the signalling on external interfaces. The state machine is non-deterministic and hierarchical

Service Specification with Tau/Developer this is an example of a hierarchical state with one named entry point and two named exit points.

Service Specification with Tau/Developer

Service Decomposition In the Service Decomposition phase, a black-box view of the service is broken down into glass-box view. Internal architecture of the system providing the service is defined The service is broken down into Service Components (SCs) which may communicate with each other. Service Specification process is executed for each new Service Component. The externally observable behaviour of the system stays exactly the same. Existing interfaces may be decomposed (i.e. refined) and new (system internal) interfaces between the SCs may be added to the model. Behavior for all new interfaces is defined. The principle of defining only the externally observable behavior of a Service Component together with recursive decomposition process produces stepwise refinement process Service Decomposition phase is recursive (producing a “decomposition tree”), and it may be necessary to do a few iterations until sufficient detail is reached. To prove the refinements, the externally observable behaviour of Service Components and their various parallel compositions are compared to the externally observable behaviour of the Service Component on higher abstraction level (and finally to the model produced in Service Specification phase). Equivalence/preorder relation, chosen semantics

Service Decomposition in Tau/Developer these are service components with an internal interface

Service Decomposition in Tau/Developer This picture describes the state machine for a single service component. It has six states, four of which are hierarchical.

Service Decomposition in Tau/Developer

Service Distribution In Service Distribution, the Service Components (SCs) from the previous phase are allocated to actual network elements. Typically, this step has to be made in close co-operation with the design engineers. Distribution cases: 1. a separate, non-communicating SC located as such into a NW element 2. communicating SCs located into various NW elements -> inter- component interfaces opened up as PDU interfaces 3. a single SC distributed over several NW elements -> peer statemachines for communicating peer entities and PDU interfaces between them defined Hierarchical statemachines used to differentiate various types of communication: PDUs and service primitives. The externally observable behaviour must stay constant in this phase as compared to the two previous ones.

Service Decomposition in Tau/Developer Here, each of the network elements contains just a single service component. The internal interface between the service components is opened up as a PDU interface

Service Implementation In Service Implementation phase, all the platform specific issues must be taken care of. We define e.g. timers and dynamic process management. Also, the encoding/decoding and routing issues must be resolved. All this is encapsulated by a separate entity, PEER PROXY or RED, which hides the implementation of virtual PDU communication from the computational entity (<-SC). Once this is done, C code may be generated for the application automatically. We use the models from Service Specification, Service Decomposition and Service Distribution phase to test the implementation Automatic test case generation from design models Exploration testing (or on-the-fly testing)

Sending RED Sending ABP sending_user_port lower_layer_port Sending_ABP_implementation

Conclusion Model Based testing with Lyra is a nice hybrid between testing and verification Lyra methodology is a systematic and ”down-to-earth” formal method – a quality which is extremely important in introducing formal methods to the industrial environment There have been successful case studies on Lyra done inside Nokia. White paper describing model-based design case according to (early) Lyra method in The first publications on the subject of Lyra should appear still this year.