1 / 16

Lyra – Basic Concepts

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

aqua
Télécharger la présentation

Lyra – Basic Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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.

  2. Lyra – Basic Concepts • The Lyra methodology can be defined into 4 phases: • Service Specification • Service Decomposition • Service Distribution • 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

  3. 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…)

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

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

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

  7. Service Specification with Tau/Developer

  8. 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

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

  10. 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.

  11. Service Decomposition in Tau/Developer

  12. 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: • a separate, non-communicating SC located as such into a NW element • communicating SCs located into various NW elements -> inter-component interfaces opened up as PDU interfaces • 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.

  13. 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

  14. 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)

  15. sending_user_port Sending_ABP_implementation Sending RED Sending ABP lower_layer_port

  16. 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 www.nokia.com • The first publications on the subject of Lyra should appear still this year.

More Related