1 / 79

(Meta)model s a nd t ransformation s ! thinking aids for the engineer - a case study

(Meta)model s a nd t ransformation s ! thinking aids for the engineer - a case study. András Pataricza Budapest University of Technology and Economics Department of Measurement and Information Systems pataric@mit.bme.hu. Abstract State Machines. References. Methodology. Guideline.

brynn-haney
Download Presentation

(Meta)model s a nd t ransformation s ! thinking aids for the engineer - a case study

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. (Meta)modelsand transformations !thinking aids for the engineer -a case study András Pataricza Budapest University of Technology and EconomicsDepartment of Measurement and Information Systems pataric@mit.bme.hu

  2. Abstract State Machines

  3. References

  4. Methodology

  5. Guideline

  6. Contents

  7. Formal semantics for UML diagrams UML 2.0 provides only a verbal semantics definition. How can a formal semantics derived from it ?

  8. Requirements for a specification language • Scope • Preciseness • Easy to understand • Programming language-like notations, auto-documentation • No enforced details • Hierarchical modeling, refinement • Transformability • Support of verification and validation • Support of implementation • Something in between or better SIMULTANEOUSLY mathematics and programming language

  9. ASM Basics • Signature (vocabulary)  • finite collection of function names. • Each function name f: • Arity, a non-negative integer. • Nullary:„constant” • Function names: • static or • dynamic. • Static constants • {undef , true, false}2every ASM signature .

  10. Function scheme f(a1 ... an) f(a’1...a’n) f(a”1...a”n) undef (x1,x2...xn)

  11. Constant Boolean algebra Restriction of the domains

  12. Function types

  13. Static function

  14. Function types

  15. State • A state A for a signature  • Superuniverse: a set |A|  ; • Interpretation fA of each function name f • if f is a constant fA2 |A| • if f is a n-ary function name: fA: |A|n£ |A|

  16. Update • Elementary update: a pair (l,v) • l is a location • v 2 |A| is the designated new value at l • Trivial update: v=A(l) • i.e. the new vaule is the same as the old one • U update set: • set of updates • U consistent update set: • No clashing updates: • 8 l, 8 v,w: if (l,v) 2 U and (l,w) 2 U then v=w

  17. Firing • Execution of upgrades • simultaneously from the (consistent) update set, • content of the locations not included: unaltered • Consistent update set U • Initial state: A • Firing: A) (A + U) • New state: (A + U) • Contents: (A + U)(l) = if (l,v) 2 U then v • elseA(l)

  18. ASM • Abstract State Machine M • signature  • initial states for  • rule declarations • main rule name of the machine • arity zero

  19. ASM machine

  20. Basic ASM constructs

  21. Formal semantics

  22. Run of an ASM • A finite or infinite sequence of states such • the initial state is A0 • either for all n 2N+ a consistent update results in a An!An+1 move • or there is no more consistent update set and Anis the final state

  23. Isomorphism

  24. Refinement and abstraction • Equivalence of states Correctness: each refined has an abstract counterpart Completeness: each abstract has a refined counterpart

  25. Example: Dataflow models A natural way for algorithm design

  26. Basic structure

  27. Definition of a dataflow node

  28. Definition of the FIFO

  29. Previous processed ASM program of the FIFO

  30. ASM program of a node Compile time

  31. Interpretation is defined by: number(headi) ¸ Xin,r(i) Interpreted DFN models: Coloured tokens Number of tokens – vector Comparison – by vector components Non-interpreted DFN: Simple tokens Numbers and comparison scalars ASM program of a node

  32. Uninterpreted ≥ ≥ Interpreted ≥ ≥ ≥ Abstraction - refinement • In order to show correctness: • Only to show, that • Total number of tokens is a homomorphism • Comparison as a relation is a homomorphism  

  33. Some conclusions on ASM programs • Non-procedural programs • Simultaneously executed blocksand not the order of instructions • Resemble to HDLs • Signals • Interaction of modules • Synchronization • Refinement/ abstraction: • correctness / completeness proven by the check of attributes of the elements

  34. UML activity diagrams Case study: how effective is ASM based modeling Done for UML 1.x by Börger et al. AUTOMATED DERIVATION OF ERROR PROPAGATION MODELS FROM UML MODELS?

  35. Activity diagram • Basically: a data flow network (DFN). • representation of data and control information. • directed graph • hierarchical compositionof activity nodes • activity • action • activity edges • colouredtoken flows • Partitions • Interruptible regions and exceptions

  36. Activity models • Coordination between the lower-level behaviors • event oriented , • terminationof an action producing output tokens, • events from the outsideenvironment generating tokens at interface nodes, • arrival of data or controlat an action component • Option: reentrant

  37. Nodes

  38. Activity levels in UML 2.0 Fork, join Object nodes Control sequencing No concurrency Structured hierarchies object flows, multicast, xform of tokens, edge weights Structured programming interruptible regions, exceptions

  39. Actions • Primitive functions: • user defined transformations on data • Invocations of behavior • other activities • other types of behavior • Invocation hierarchies invoking • other activities. • inter-behavior communication by signals (multicast / multireceive). • Read, write create and delete operations on • variables, • objects • links • Flow-of-control

  40. Example:variable actions

  41. Example: invocation actions

  42. Basic action node frame • ActionNode(n) = • FSM(n; action; next(n)) where • action = ifactive(n) andguardandcorrectMultiplicity(n) then • act • forallL2dynArgs(n) withguard(L) = truedoact(L)

  43. Control nodes

  44. Decision node • Selection from alternatives • node ( in; (condi) i · k ; (outi) i · k ) • ASM: • DecisionNode(n) = • FSM(n; test; next(n; min{i·k| condi})) • wheretest = ifactive(n) thenskip

  45. Object node • Intermediate buffer • objects and data between activityor action nodes. • Selection policies • Simplest case: multiset • CompleteActivities: • FIFO, LIFO, user defined- a behavior associatedto the object node); • Optional upper bound on the number of tokens in the node (capacity bounded Petri-nets) • Specification of the state of tokens required • A special case: DataStoreNode, • central buffernode for non-transient information.

  46. Short summary • UML diagrams can be captured by ASMs • A few of frames • Mapping of non-graphical constructs to ASMs • Guards • Additional user defined behavioral specification • Elementary proofs for standards compliance • 1 phrase ) 1 simple proof (trace) • Future: • MDA • Microsoft provides technology for .net

  47. Qualitative fault modeling A natural way for abstraction in diagnosis problems CAN WE DERIVE ERROR PROPAGATION MODELS IN AN AUTOMATED WAY FROM ASM MODELS?

More Related