1 / 28

Harmony: An Approach and Tool for Combining Semi-formal and Formal Notations in Software Specification

Harmony: An Approach and Tool for Combining Semi-formal and Formal Notations in Software Specification. CS 791z Topics on Software Engineering Instructor’s Research April 19, 2004. Outline. Context A Procedural Frame The Harmony Tool Conclusions. Context: The Harmony Project.

waldo
Télécharger la présentation

Harmony: An Approach and Tool for Combining Semi-formal and Formal Notations in Software Specification

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. Harmony: An Approach and Tool for Combining Semi-formal and Formal Notations in Software Specification CS 791z Topics on Software Engineering Instructor’s Research April 19, 2004

  2. Outline • Context • A Procedural Frame • The Harmony Tool • Conclusions

  3. Context: The Harmony Project • Proposal of an approach for specifying time- constrained systems (TCS) based on the combined use of UML (graphical, semi-formal notation) and Z++ (formal notation) • Topic placed at the confluence of three paradigms: • object-orientation • formal specification • visual representation

  4. Context: Why Integrate? • Combine benefits • Graphical notations easy to use • Formal methods precise • Different aspects of the system need different ways of description • Provide choices

  5. Context: Research Space and Location

  6. Strategies for Integration • Integration of notations: • Semi-formal/Formal • Semi-formal/Semi-formal • Formal/Formal • Types of semi-formal/formal integrations: • Derivation or (simple) formalization • Complementary formalization • Tight integration, involving two-way translations

  7. Related Work • Similar approaches: • Jia’s AML • Noe and Hartrum’s extension of Rational Rose • France et al.’s blending of Octopus and Z • Headway System’s RoZeLink • Kim and Carrington’s UML/Object-Z combination • Our approach is distinct from all the above in at least one major aspect: variant of Z involved, provisions for dealing with RTS, tight integration of notations, or type of supporting environment

  8. Notations: UML • “Graphical language for visualizing, specifying, constructing, and documenting the artifacts of software-intensive systems” [G. Booch] • OMG standard notation for object modeling • Includes structural & behavioral model elements • Extension mechanisms: stereotypes, tagged values, constraints • Support for RTS: events, signals, active classes, finite-state machines, timing marks and expressions • However, for rigorous development supplementary formalization is necessary

  9. Notations: UML - Example of Class Diagram

  10. Notations: UML - Example of State Diagram

  11. Notations: Z++ • Created by Lano and Haughton • Essentially, extends Z with the class construct • Closer to implementation than other formal languages • Support for dealing with time in the HISTORY clause: Temporal Logic or Real-Time Logic (RTL) formulae

  12. Notations: Z++ Class ZPP_Class::= CLASS Identifier [TypeParams] [EXTENDS Ancestors] [TYPES TypeDefs] [FUNCTIONS AxiomaticDefs] [OWNS Locals] [RETURNS OpTypes] [OPERATIONS OpTypes] [INVARIANT Predicate] [ACTIONS Actions] [HISTORY History] END CLASS

  13. Translations UML/Z++: Overview • Formalization = UML to Z++ translation • Deformalization = Z++ to UML translation • Algorithms for automated translations have been proposed • Formalization of both structure and behavior • Rules and principles for translating class diagrams (algorithm AFCD) • Rules and principles for translating state diagrams (AFSD) • Principles for reverse translation (ADF)

  14. A Procedural Frame • Series of activities in which model artifacts are produced • Subset of UML used (“2+1 views”) • Artifacts: • UML elements: use case diagrams, scenarios, sequence diagrams, class diagrams, and class compounds • Z++ specifications: Z++ classes and statements • Activities organized in stages • ‘Regular’ and ‘irregular’ sequences of activities

  15. A Procedural Frame

  16. Regular Flow of Activities

  17. Irregular Flow of Activities

  18. The Harmony Tool: Characteristics • Sustains the development of combined UML/Z++ models • Operates on specification projects • Monolithic construction • Options for automated translations • Support for class compounds • Tandem mode of operation • Provisions for interfacing with external tools

  19. Harmony: The Browser

  20. Harmony: Project Pane

  21. Harmony: New Element Selector & Legend Pane

  22. Harmony: Toolboxes

  23. Harmony: Project Loaded

  24. Harmony: UML Space (Class Diagram)

  25. Harmony: Z++ Space (Class Spec)

  26. Harmony: Z++ Space (Timing Constraints)

  27. Conclusions: Summary • Pragmatic semi-formal/formal combination of notations • Formalization of UML constructs in Z++ • Rigorous treatment of TCS via RTL • Detailed design of the Harmony ISE • Lightweight, rapid modeling process

  28. Conclusions: Future Work (most on Andy ) • Enhancement of algorithms • Refinement of the tool’s functionality • Implementation of Harmony • Syntax checker for Z++ • More applications

More Related