1 / 29

Applying ASD in Designing And Verifying: BeX Orchestration Controller

Applying ASD in Designing And Verifying: BeX Orchestration Controller. Harsh Beohar. Goal. To briefly describe ASD as a methodology. To describe the behavior of system under design in brief. To briefly describe the scenarios which are designed using ASD.

sokanon-brown
Télécharger la présentation

Applying ASD in Designing And Verifying: BeX Orchestration Controller

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. Applying ASD in Designing And Verifying: BeX Orchestration Controller Harsh Beohar

  2. Goal • To briefly describe ASD as a methodology. • To describe the behavior of system under design in brief. • To briefly describe the scenarios which are designed using ASD. • Problems encountered while using ASD.

  3. ASD Methodology[1]

  4. ASD Road Map

  5. Mealy Machine • Differences with Automaton: • A Mealy machine does not have final states • In Mealy machine each transition produces output based on current state and input. • This motivates us to model a reactive system through Mealy Machine. • To enable the use of predicates in transition of states, we need to add one more tuple in Mealy Machine. • M=(Q,Σ,Γ,P,δ,λ,qi) • Q : is a finite set of states. • Σ : is a finite set of stimulus S (finite input alphabet). • Γ : is a finite set of responses R (finite output alphabet). • P : is a set of unbounded predicates. • δ : Q × Σ→ Q (next state function). • λ : Q × Σ→Γ (output function). • qi : initial state

  6. Box structure development methodology (BSDM) • Operates by identifying and refining abstractions to develop a software system through 3 views[2]: • Black Box. • State Box. • Clear Box. • Black box is a state-free description of external view of system. • Let S & R denote the set of stimulus and response respectively of a system. Then the black box function BB of a system is • Defined as total function that maps stimulus history to responses.

  7. BSDM contd… • State Box is derived from black box and introduces internal state. • Let Q,S and R denote the set of states, stimuli and responses respectively. Then, the state box is given as • Clear box is an implementation of state box in any high level language, C++, Java etc.

  8. Sequence Based Specification • SBS[3] is a method for producing consistent, complete and traceably correct software specifications. • SBS is used to derive black box function. • Black box function and next state function (δ) from Mealy machine are used to derive state box functions. • In [3], Prowell and Poore presented the SBS method for systematically defining: • Consistency: Each stimulus history maps to only one response. • Completeness: A response is defined for every stimulus history. • Correctness: Requirements Traceability. • A sample sequence based specification OrchestrationController

  9. Verification = CSP + Model Checking • ASD uses CSP as a formal method to handle concurrency. • Model checking is performed by generating CSP, and using FDR2 to verify system properties. • Specification Implementation: means that every behavior of Implementation is also behavior of Specification. • In more detail, Let Ii and Iudenote the set of implemented and used interfaces of a component respectively. Let D denote the design of that component. Then, Verum check for • Also, they check for requirements by specifying requirements in CSP and then checking through the above refinements.

  10. Converting SBS into CSP using state box[4]

  11. ASD concepts:Durative and Non-durative actions Thus, durative and non-durative action can be seen as asynchronous and synchronous calls respectively.

  12. ASD concepts:Monitor Semantics

  13. ASD concepts: • Run to Completion semantics means : • Once a stimulus has fired, all corresponding responses will be processed completely in the specified order. AND • All state predicates are updated before the state transition is made. • Call-back Semantics: Callback events are decoupled via queue mechanism. This decoupling happens in thread context different from a calling thread, known as DPC server thread. • Synchronization semantics: • Get Client Mutex • Get Client DPCMutex • Call Processing • Release Client DPCMutex • Conditional Wait (DPC call-back) • Release Client Mutex

  14. A sample example for CB

  15. Events with parameters • Chan.Stim[i>>]: specifies that the parameter value ‘i’ will be captured on entry into a context variable associated with the name ‘i’. To be meaningful, ‘i’ should be an “in” parameter. • Chan.Stim[i<<]: to denote ‘i’ is an out parameter. • Chan.Rsp[i>>]: to denote ‘i’ is an in parameter. • Chan.Rsp[i<<]: to denote ‘i’ is an out parameter. • Chan.event[$x]: x is a literal (usually used for enumerated constant.) • Parameters are removed from event in generation of CSP scripts. • Callback Events should not have an out parameter.

  16. Introduction to BeX Controller • Workflow is based on the concept of centralized controller, named as Orchestration Controller. • Aim is to design this Orchestration Controller using ASD and provide it as a study model. • An orchestration scenario comprises a number of ordered stimuli to realise an overall system function that involves multiple units. • It is a logical flow of messages/stimuli between the Orchestration Controller and other units in the System.

  17. Some terminology • System: collection of software components one is interested in specifying. • Environment: all entities external to the system with which the system (when implemented) directly communicates. • Stimuli: Events (inputs, interrupts, invocations) in environment which can affect system behavior. • Responses: System behavior[s] which are observable in the environment. • These above definitions are very helpful to make a context diagram.

  18. System Boundary Orchestration Controller Preparation Controller Selection Controller FEClient X-Ray IP Service proxy Acquisition Service proxy Patient Admin Service proxy Current Context Diagram Implements BE-FE interface Patient Administration Offers X-Ray Specific Functionality For Displaying & Selecting Acquisition Parameters

  19. Scenarios Identified • Prepare-Unprepare : handled in Preparation Controller. • Select Acquisition Case : handled in Selection Controller. • Select Acquisition Protocol Step : handled in Selection Controller. • System Startup/Shutdown: handled in Orchestration Controller. • EPX Validation with User. • EPX Validation without User. • Select Examination.

  20. Prepare-Unprepare Scenario • The preparation of an image acquisition is initiated only by Front End (by pressing a foot pedal). Similarly, the un-preparation of an image acquisition is initiated by FE (by releasing a foot pedal). • The FE always start and stop acquisition by invoking a request (to Orchestration Controller) Prepare and Unprepare, respectively. • Orchestration Controller informs FE with Prepared if the services are prepared. Similarly for Unprepare. • If Orchestration Controller informs FE with PrepareFailed message then FE must sent an Unprepare message for before requesting for next prepare cycle.

  21. Prepare Scenario Orchestration Controller Preparation Controller Acquisition Service XRay IP Service FEClient IPreparationController. Prepare IPreparation ControllerINT. Prepare IPreparation ControllerINT. Prepare IFEClient AcquisitionCB.Prepare Note IPreparation ControllerINT. Acquisition Prepared Note IPreparation ControllerINT. XRayIPService Prepared IPreparation ControllerCB. Prepared IFEClient Acquisition.Prepared Note: The order in which the services return their result is not fixed, depends on how much time they need to process the prepare request.

  22. Decisions Made • Prepare-Unprepare Scenarios : • The orchestration-controller will send a Prepare command to the services for next run even though the after-run-data for current run has not yet been received. • The services will prepare and send Prepared/PrepareFailed to the orchestration controller. • The orchestration-controller will then wait for the after-run-data from the FE (with a time-out). • If AfterRunData is received, Orchestration will send prepared to FE upon receiving the AfterRunData and handle the AfterRunData asynchronously.

  23. Mealy Machine* For Preparation Controller *=Exact [Stimuli & Predicate]/Response can be found in excel sheet. Sorry for slight abuse of notation for the sake of simplicity in the figure.

  24. Mealy Machine for Orchestration Controller Dotted line represents flow due to failure.

  25. Further Work. • Represent the remaining scenarios as Sequence Based Specification (in Excel Sheet). • Model Check • Preparation Controller (Interface Model), • PAACSelector (Interface Model), and • Orchestration Controller (Design Model). • Does Individual components and components under parallel composition are deadlock free, live lock free? • Still to explore code-generation limitations and test case generation while using ASD.

  26. ASD Limitations. • Routing a message from any Service to the Orchestration Controller [w.r.t Context Diagram] becomes complex as compared to implementation in any high level language. • ASD assumes if processes are in different process boundaries then the channel which provides communication is ideal (it will never breakdown). • Unable to describe how to transform data, whether data is to be stored persistently. • A complete system is impossible to design and verify in ASD if foreign components are present. A foreign component is generally a handwritten component or a component whose implementation is generated by other tools. • Only suited to design systems having complex state behavior.

  27. Conclusions • Design can be rigorously verified against their requirements and interface specification. • ASD (in particular SBS method) helps in making design decisions. • Not for a complete system, but the test cases to ASD components can be generated. (by selecting an option “usage model” in the plug-in.) • Compared to conventional software development lifecycle, design errors can be found before implementation phase. • This methodology is understandable to all project stakeholders.

  28. References • [1] Guy Broadfoot and Philippa J. Hopcroft. An Analytical Software Design System. World Intellectual Property Organization, Nov 2005. • [2] Harlan D. Mills, Richard C. Linger, and Alan R. Hevner. Principles of Information Systems Analysis and Design. Academic Press Professional, CA, USA, 1986. • [3] S. J. Prowell and J. H. Poore. Foundations of Sequence-Based Software Specification. IEEE Trans. Of Soft. Eng., 2003 • [4] Guy Broadfoot and Philippa J. Hopcroft. Combining the Box Structured development method and CSP. In Proceedings of 19th IEEE International Conference on Automated Software Engineering, 2004.

More Related