ABSTRACT STATE MACHINE (ASM)

Submitted by: Mohit Munnangi Kishore Gatakala Surendra Koripella Satish Chandra Gupta Talluri

CONTENTS

Introduction Basic Concepts Requirements capture and specification of case 1 Requirements capture and specification of case 2 Extending domains Sequentialisation and iteration Conclusion

Introduction
ASM : a state machine operating on states which are arbitrary data structure. State Machine : a mathematical model of computation used to design both computer programs and sequential logic circuits. ASM method bridges the gap between the two ends of system development. the human understanding and formulation of real world problems. the deployment of their algorithmic solutions by code- executing machines on changing platforms.

Basic Concepts
The method mainly based on three basic concepts: 1. ASM ----- finite state machines to operate over arbitrary data structures 2. Ground Model ----- a rigorous form of blueprints 3. Refinement ----- most general scheme for stepwise instantiations of model abstractions to concrete system elements. Because of these three concepts ASM models can be analyzed easily using verification or validation

Requirements capture and specification of case1 and case2

Identifying the agents Identifying the states Identifying static and dynamic parts of the states Identifying the transitions Identifying the initial and final states Exceptions handling and robustness Identifying the desired properities

Extensions of ASM

Extending domains Sequentialisation and Iteration

Requirements capture and specification of case1

Identifying the agents

Q1. Who are the system agents and What are their relations? In particular, what is the relation between the system and its environment*?

R1 says the subject is to invoice orders.

Environment: The context in which an agent machine computes is represented by an external agent called environment.

Identifying the states

State: defined as an algebraic structure, where data come as abstract objects, i.e., as elements of sets. Q2: What are the system states? What are the domains of objects and what are the functions, predicates and relations defined on them? R1 set ORDERS R2 function orderState ----- invoiced or pending R3 referenced product (consists of two functions) R4 not injective and not constant R5 function stockQuantity

Identifying the static and dynamic parts of the states

Separation is concerned with information hiding, data abstraction, modularization and stepwise refinement. ASM method distinguishes basic and derived functions. Basic functions static and dynamic Q3. What are the static and the dynamic parts of states? Who can update dynamic functions? R6a ORDERS is static R2 & R5 orderstate is dynamic R3 & R6a static

Sample Code

Asm orderSystemCase1 signature: static abstract domain Orders enum domain OrderStatus = { INVOICED | PENDING } static abstract domain Products static domain Quantity subsetof Natural static referencedProduct: Orders->Products dynamiccontrolled orderstate:Orders->OrderStatus static orderQuantity:Orders->Quantity dynamic controlled stockQuantity:Product->Quantity

Identifying the transition

Basic ASMs are finite sets of so-called transition rules of the form: if Condition then Updates Q4. How and by which transitions (actions) do system evolve? Under which conditions (guards) do the state transitions of single agents happen and what is their effect on the state? What is supposed to happen if those conditions are not satisfied? Ans. By R2 and R5 there is only one transition to change the state of an order.

cont...
Q5. Could the system actions be parallelized anyhow? Namely, in the case of invoicing orders, can the system invoice several orders in one step? To speed up invoicing of orders, parallelism can be exploited in two directions. a.) A first strategy consists of selecting a given product and then simultaneously invoicing all the corresponding orders, if possible. b.) An alternative policy could be selecting, still non-deterministically, a set of orders to be invoiced in parallel.

Identifying the initial and final states

Q6. What is the initialization of the system and who provides it? Re there termination conditions and, if so, how are they determined? What is the relation between initialization/termination and input/output? Ans. No explicit initialization is specified, although one can assume that all the orders are initially pending. No termination condition is given either. We can assume that the system keeps to invoice orders as long as there are orders which can be invoiced.

Exception handling and robustness

Q7. Which forms of erroneous use are to be foreseen and which exception handling mechanisms should be installed to catch them? What are the desired robustness features? Ans. Since no exceptional computations are mentioned in the requirements and no inconsistent updates are allowed by the specification, we don not make use of the techniques supported by the ASM method to the error handling purpose.

Identifying the desired properties(validation/verification)

Validation: This can be done by simulation and testing Verification: This technique is used to prove ASM model properties from proof sketches over traditional or formalized mathematical proofs to tool supported interactive or automatic theorem proving or model checking. Q8. Is the system description complete and consistent? Ans. Completeness with respect to the requirements can be verified for example by checking that every requirement can be analysed and captured by our specification.

Cont...
Q9. What are the system assumptions and what are the desired system properties? What do the requirements say about the state of the system? Ans. No explicit assumptions or desired properties are given in the original specification. Through the requirements capture we have introduced several assumptions to fill missing information. Assumptions can be introduced by means of auxiliary aximos. State of every order is either pending or invoiced but never undefined.

Requirements capture and specification of case2

Specification for case-2

In this case we have to formulate the same as in case-1, some more changes are included in case-2. In this case we have to know what is system agents and system states. Agents does not specify dynamic manipulation of orders, stock and products, interact for shared data. And for this project we consider only one agent which performs all the requested actions. The main program executed by the agent will take care of the synchronization of actions to avoid inconsistencies.

SPECIIFICATIONS FOR CASE-2

System state introduce three monitored functions which are sequence of orders to add, orders to cancel and new quantities to add in stock. monitored neworders: seq(prod(products, quantity) monitored orderstocancel: seq(orders) monitored newitems: seq(prod(products, quantity) The value of these functions may be determined by the user, and by the system is considered system inputs. Coming to the domains and functions. These are classified as the set of orders is dynamic since new orders can be added and old orders can be deleted.

SPECIIFICATIONS FOR CASE-2

Some of the transitions system state evolve are a) Cancelation of orders b) Insertion of new orders c) Addition of quantities of products in the stock These operations are also driven my the monitored functions. Rule r_cancel orders = Forall $i in natural with $i < length (orderstocancel)do Orderstate(at(orderstocancel,$i)):=canceled. If the sequence is empty the action has no effect.

Extending Domains
To construct new elements and to add them to domains, ASMs introduces the extend notion: extend D with v do R(v) where D ---- name of the abstract type-domain v ---- logical variable R ---- transition rule executed after v is added to D In general R performs initialization over v.

Cont...
Q14. Could the domains be extended by adding new items? Namely, in the case of invoicing orders, can new orders be inserted? Ans. We answer this question by the following rule AddOrders which extends the domain Orders with new elements and sets all the functions on these locations: Rule r_AddOrders= For all $i in Natural with $i<length(newOrders)do let $p=first(at(newOrders,$i)), $q=second(at(newOrders,$i))in extend Orders with $order do par orderQuantity($order):=$q referencedProduct($order):=$p orderState($order):= PENDING

Sequentialisation and iteration

Basic ASMs lack support of practical composition and structuring principles. Turbo ASMs offer as building blocks sequential composition, iteration and parameterized sub-machines extending the macro notion with basic ASMs Sequential composition is denoted by two ASM rules by P seq Q Iterate R iterates the sequential execution of a rule R encapsulating compositions with a finite number of iterated steps into one step. Two natural stop situations such as when update set becomes empty and when it becomes inconsistent.

Cont...
Q15.How can location updates be sequentialized in order to avoid synchronous inconsistent updating? Ans. The rule Additems performs the entry of quantities in the stock by increasing the value of the function stockQuantity for the entered products. Since the monitored sequence newitems contain same product it could not be updated several times, the function stockQuantity cannot be updated in parallel for each product in the sequence, otherwise inconsistent updates may appear. The three new rules CancelOrders, AddOrders and ADDitems respectively can update the function OrderState for existing orders, the

Conclusion
We have showed how the ASM method makes it possible to capture informal requirements by constructing a consistent and unambiguous, simple and concise, abstract and complete ground model which can be understood and checked by both domain experts and system designers. During the formalization process we have shown how requirements often incomplete and assumptions must be stated in order to complete the specification