1 / 16

Contractual Consistency Between BON Static and Dynamic Diagrams

Contractual Consistency Between BON Static and Dynamic Diagrams. Ali Taleghani July 30, 2004. Overview. Model-Driven Development & Models Contractual Consistency – The Problem Previous Work Current Work – Semantics of Dynamic Diagrams BON Development Tool – BDT

idalee
Télécharger la présentation

Contractual Consistency Between BON Static and Dynamic Diagrams

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. Contractual Consistency Between BON Static and Dynamic Diagrams Ali Taleghani July 30, 2004

  2. Overview • Model-Driven Development & Models • Contractual Consistency – The Problem • Previous Work • Current Work – Semantics of Dynamic Diagrams • BON Development Tool – BDT • Contribution and Future Work

  3. MDD & Models • Model-Driven Development proposes development based on models • Several views can be used to describe system • Models must be executable, and views consistent • Contributions • Automated consistency checking • Symbolic model execution

  4. Contractual Consistency – Example • SD contains contracts only – No implementation • Want to create account and withdraw $200 • make sets (balance = 0), but precondition of withdraw requires (balance >= 200)  Contract Violation

  5. Contractual Consistency • SD and DD are the two views involved • SD contains contracts only – no implementation • Contracts are pre, postconditions and class invariants • Views contractually consistent if messages in DD corresponding to routines in SD can be executed without contract violations

  6. Previous Work • Problem of consistency with contracts not extensively discussed –informal approaches only • [Paige 2002] first to formalize problem • Cites 4 criteria for checking consistency • Last criteria is contractual consistency • We add additional constraints for implementation

  7. Semantics of Dynamic Diagram • Message mi in DD is mapped to a feature ri in the target class in SD • Routine takes system from one system state constraint (SSCi) to the next (SSCi+1) • SSC represents a constraint on the attributes in the system • SSCi+1 constructed using SSCi and contracts of ri

  8. Current Contribution - 1 • Check Contractual Consistency using Symbolic Model Execution • Define Symbolic Execution Step as execution of one message in DD • successful iff • Precondition of routine is satisfied • SSC is not a contradiction

  9. Current Contribution - 2 • Views contractually consistent iff • No implementation provided • Require use of Theorem Prover • Use Simplify from ESC/Java • Automatic and Fast • Returns counter example

  10. BON Development Tool - BDT • Static Diagramming Tool • Construct Class diagrams • Include contracts

  11. BON Development Tool - BDT • Dynamic Diagramming Tool • Draw objects and messages • Assign messages to routines from SD

  12. BON Development Tool - BDT • Consistency Tool • Specify an initial state constraint • Contract violation results in counter example • User can use counter example to make changes to contracts, messages

  13. Comparison to Tool of [Gao2004] • Gao’s Tool • Test drivers and implementation required • Checks one or a few execution paths • Complete (for that execution) • BDT • Automatic and no implementation required • All execution paths starting in a state constraint are checked • Incomplete since working with a theorem prover

  14. Contribution • First contractual consistency tool without the need to specify implementation • Early symbolic execution of partial models • Can use dynamic (collaboration) diagrams • Use contracts only – higher level than MDD State Chart Action Languages • Tool is user friendly • Simplify works automatically under the hood • Simplify works quickly

  15. Future Work • Work out theory for sub-messages in DD • BDT • Add invariants and inheritance • Support quantifications • Combine BDT with EDT for complete code generation • Add support for program verification – using ERC

  16. Thank You

More Related