Lyra%20

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 Lets design a methodology, that does
  design, testing and verification in parallel!
  Sari Leppänens work centers on this idea.
• Method uses and combines theories of formal
  specification, verification and testing
• WHATS 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
receiver
ABP
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 -gt inter-component interfaces opened up
  as PDU interfaces
• a single SC distributed over several NW elements
  -gt 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
  (lt-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.