1 / 47

Bridging the FST and MDE Divide

Bridging the FST and MDE Divide. Robert B. France Colorado State University. State of the practice. Building software pyramids. If software developers built pyramids …. “Model -Driven Engineering” (MDE) is concerned with ….

caspar
Télécharger la présentation

Bridging the FST and MDE Divide

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. Bridging the FST and MDE Divide Robert B. France Colorado State University

  2. State of the practice Building software pyramids

  3. If software developers built pyramids …

  4. “Model-Driven Engineering” (MDE) is concerned with … • reducing accidental complexities associated with bridging wide abstraction gaps • through use of technologies that support rigorous transformation of abstractions to software implementations MDE is concerned with developing software tools to support the work of software engineers

  5. What is a model? A (formal or informal) description of an aspect of a software-based system that may or may not exist. A model is created to serve one or more purposes.

  6. Modeling is purpose-driven • Modeling to explore problem or solution spaces • Models as sketches (informal) • Models as analyzable artifacts (formal) • Modeling to communicate aspects of problems or solutions • Models as documentation artifacts • Modeling implementations to generate code

  7. Modeling and software engineering • Modeling is an essential software engineering activity • Modeling examples • Creating descriptive development documents • Creating formal specifications • Creating source code • The question is not whether or not we should model software (we’ve been doing that for decades), but how can we better leverage models during development

  8. Does formal methods research subsume MDE research? • Not likely • MDE concerns go beyond describing and analyzing systems using a limited set of viewpoints • A key modeling concern: Finding the “right” abstractions - How does a modeler determine the adequacy of the abstractions used in their models? • It may be the case that abstractions that make verification easier are also good enough to support rigorous transformation to dependable code • MDE research can provide a context for FST research that emphasizes usability, i.e., research into (for example) • how formal modeling techniques can support agile development • analyzing incomplete models

  9. Early focus of MDE • Models as documentation/communication artifacts • Early work on CASE technologies laid the foundation • Verification opportunity: Checking consistency of representations • Models as artifacts for generating implementation and deployment artifacts • OMG’s work on UML and MDA • Separation of Platform Independent and Platform Specific abstractions • Software development viewed as a transformative process • Verification opportunities: Verifying correctness of transformations

  10. Evolution of MDE • Supporting domain-specific software development • Supporting exploratory development through compositional modeling • Making agile development rigorous • Breathing life into models • Models as analyzable artifacts • Foundation provided by work on formal specification techniques • Models as artifacts for managing and evolving runtime behavior • models@run.time

  11. Early attitudes towards UML formalization • Reliance on natural language descriptions to communicate semantics • From the early UML standard: “… the state of the practice in formal specifications does not yet address some of the more difficult language issues the UML introduces” • Prevailing perception: Developing mathematically defined semantics requires significant effort with little or no perceived gain

  12. pUML: An early initiative on UML formalization • The Precise UML (pUML) group • A collaborative group of researchers formed in 1998 • Core members: A. Evans, R. France, S. Kent, K. Lano, B. Rumpe • Why pUML? • Growing (mis)use of UML • Difficult to determine if understanding of UML concepts was real or apparent • Objectives of pUML initiative • Spur and encourage efforts to develop acceptable, usable formal UML semantics • Broaden awareness of benefits gained through formalization

  13. Defining Semantics “directly” • Operational semantics • Focus primarily on supporting behavioral analysis (e.g., Lilius & Paltor semantics for state machine models, Kermeta) • Supports animation, simulation of behavior • Denotational semantics • For example, using metamodels to describe syntactic/semantic domains and semantic mappings • Supports mathematical reasoning about modeled properties • Axiomatic semantics • Semantics expressed in terms of logical theories and axioms (e.g., Lano & Clarke axiomatic semantics for state machines) • Supports mathematical reasoning about modeled properties

  14. Defining semantics “indirectly” • Translational approaches: Transform UML models to analyzable models expressed in a formal language • Enables use of available analysis tools (e.g., model-checking tools) • Semantics embedded in translation rules

  15. UML Model Transformation-based approaches UML Metamodel Formal Language Metamodel conforms to feedback conforms to based on Formal Model Formalization feedback feedback • Rigorous Analysis • static analysis • dynamic analysis

  16. UML Model Using Base Semantic Models Base Operational Semantics bisimulation relation Operational Semantics semantic mapping semantic mapping verified using feedback Formal Model Formalization UML Model feedback feedback • Rigorous Analysis • static analysis • dynamic analysis

  17. Enhanced use of Base Semantic Models Base UML Semantic Model Conforms to Conforms to Conforms to Base UML timed Behavioral Semantic Model Base UML untimed Behavioral Semantic Model Base UML Structural Semantic Model Supports translation to static analysis tools, e.g., Alloy, Z Supports translation to timing analysis tools, Supports translation to behavioral analysis tools, e.g., Promela/SPIN

  18. Tooling • Need for both lightweight and heavyweight tool-supported analysis techniques • Structural analysis tools • USE, OCLE • Behavioral analysis tools • vUML, tools that model-check state machine and interaction models, Kermeta • SUDA: Scenario-based UML design analysis • Testing executable models: UMLAnT (a tool for animating and testing detailed UML design class models)

  19. The way ahead • Many opportunities for applying formal verification techniques in the MDE context • Supporting lightweight and heavyweight analysis of models (lower hanging fruit) • Supporting use of domain-specific languages • Verifying the correctness of model transformations • Runtime verification of model adaptations at runtime • Observation: Different analysis techniques target different properties. Need to support different types of semantic analyses • Promising approaches: FIACRE, the system model approach developed by the UML Semantic Project team • Generic Model of Computation (GeMOC) Initiative • Need to capture usable semantics in profiles • Promising approaches: work on encapsulating operational semantics in profiles by S. Gerard’s team at CEA

  20. Focus questions - 1 Can we raise the level of abstraction in design? Yes, but developers/students find modeling above the code level difficult Is MDE an “effective” way of gaining an audience for verification? Yes; there are many modeling problems that can benefit from work on formal verification How does modeling impact usable verification? Choice of abstractions can ease or complicate rigorous verification

  21. Focus questions - 2 How do verification tools make modeling more effective? Provides developers with feedback on the adequacy and fidelity of their models How can verification technology reshape the design modeling lifecycle? There will be some “reshaping”, but a more pertinent question is how to adapt verification technologies to better cope with incompleteness and highly-adapatable design processes

  22. Modeling aptitude • We need to understand why Johnny can’t model and Jane can • Hypothesis: A good modeler is a good programmer; a good programmer is not always a good modeler • Modeling requires programming and abstraction skills • Abstraction skills refine programming language skills • Programs produced by developers with good abstraction skills should be of significantly better quality

  23. …and that’s how one can effectively use bisimulation to … He lost me after he introduced himself …

  24. Supplemental Slides

  25. pUML perspective: Why formalize UML semantics? Identify completeness, consistency, ambiguity problemsin language definition Provide a basis for checking consistency across models consisting of heterogeneous views (i.e., views described using different notations) Support rigorous analysis of UML models Support rigorous manipulation of UML models Support development of “intelligent” model development tool environments

  26. pUML perspective: Defining semantics • Denotational view of semantics • Semantics of a language is defined by a formal mappingfrom well-defined elements in a syntactic domain to well-defined elements in a semantic domain • Provide support for using the UML as a formal modeling language • Supporting diagrammatic “proofs”

  27. Why is modeling difficult? Or why modeling seems to add accidental complexity • Lack of good tool support • Many existing modeling tools do introduce significant accidental complexity • Dissatisfaction with current technologies should not be used as the basis for dismissing MDE • Learning how to abstract is difficult • Current software development methods provide little or no abstraction guidelines

  28. Are you a good modeler? • How do you decompose a problem or solution? • Structure should provide significant insights or enable useful formal analysis • How do you determine what information should or should not be in a model and what level of abstraction is appropriate? • How do you determine if the abstractions you use are “fit-for-purpose”? • If you have answers that involve systematic application of abstraction principles write a paper for SoSyM!

  29. Early attempts at providing support for analyzing OO models • Methods integration • Transforming “informal” models to tool-supported formal specifications (e.g., Fusion-to-Z, UML-to-ASMs) • OO-extended formal specification languages • Extending non-OO formal specification languages with OO concepts (e.g., Z++, Object-Z, Maude) • Supplemental formal notation • Provide a formal language that modelers can use to formally describe properties (e.g., Syntropy) • Note: This is different than providing a semantics for a modeling language

  30. UML Structural Analysis Tools Analysis tools such as USE and OCLE can be used to statically analyze Class Models Given an object diagram, these tools can check whether it has structural properties specified in class models LIMITATION: Current tools restricted to analyzing static structural properties

  31. Static analysis of class models using USE/OCLE references class model with constraints analysis results Characterizes valid application states USE/OCLE instance diagram references Describes an application state 31

  32. Supporting lightweight analysis of behavior • Evaluate design model by checking whether scenarios describing legal and illegal behavior are allowed or disallowed in model • Verifier produces scenarios of illegal and legal behavior • Verifier uses the scenario-based analysis technique to evaluate design • Approach described in MODELS 2008 paper by L. Yu et al.

  33. Approach fromAccount:Account :BankUser :Controller transfer(…) toAccount :Account withdraw(…) deposit(…) application model Snapshot Model Characterizes valid snapshots and specifies class operations Characterizes valid sequences of snapshots USE/OCLE Scenario Object Model Describes a sequence of application states Describes scenario to be analyzed

  34. Snapshot Model

  35. Approach fromAccount:Account :BankUser :Controller transfer(…) toAccount :Account withdraw(…) deposit(…) application model Snapshot Model Characterizes valid snapshots and specifies class operations Characterizes valid sequences of snapshots USE/OCLE Scenario Object Model Describes a sequence of application states Describes scenario to be analyzed

  36. Scenarios • Created by a verifier • Reflects verifier’s understanding of the design • Described using annotated sequence diagrams • Java-like Action Language (JAL) used to describe operations invoked in scenario • Two types of scenarios • Good/legal scenario: describes a desirable behavior • Bad/illegal scenario: describes undesirable behavior

  37. Generating Snapshot Sequences 37 • JAL-annotated sequence models are interpreted using UMLAnT • Alternative: • Treat snapshot sequence generation as a constraint solving problem • JAL models converted to Alloy • The trace of object states produced is used to build the Scenario Object Model

  38. Example scenario 38 In an RBAC banking environment an administrator assigns the user Bob to two conflicting roles: the Accountant and Senior Cashier roles The above is a bad scenario

  39. 39

  40. Analyze behavioral properties Analyze scenarios using USE or OCLE against Snapshot model Snapshot invariants Scenario specific invariants 40

  41. Generating the Snapshot Model: A simple example 41 Generate Snapshot class diagram structure Generate Snapshot Model invariants from operation specifications

  42. Partial HRBAC application model 42

  43. 43

  44. Generating the Snapshot Model 44 Generate Snapshot Class Diagram Generate Snapshot Model invariants from operation specifications

  45. An operation specification //pre- and post- conditions of the Assign method contextUser::Assign(role:Role) pre: self.userRoles->forAll(r | r.name <> role.name) //role is not currently assigned to the user post: self.userRoles->exists(r | r.name = role.name) and self.userRoles@pre->forAll(r1 | self.userRoles->exists(r2 | r1.name = r2.name)) and (self.userRoles->size() = self.userRoles@pre->size() + 1) //role is assigned to user 45

  46. context User::Assign(role:Role) pre: self.userRoles->forAll(r | r.name <> role.name) //role is not currently assigned to the user post: self.userRoles->exists(r | r.name = role.name) and self.userRoles@pre->forAll(r1 | self.userRoles->exists(r2 | r1.name = r2.name)) and (self.userRoles->size() = self.userRoles@pre->size() + 1) //role is assigned to user 46 contextUser_Assign_Transition //From Assign() pre-condition before.users->includes(userPre) and before.roles->includes(rPre) and userPre.userRoles-> forAll(r | r.name <> rPre.name) and //From Assign() post-condition after.users->includes(userPost) and after.roles->includes(rPost) and userPost.userRoles-> exists(r | r.name = rPost.name) and userPre.userRoles-> forAll(r1|userPre.userRoles-> exists(r2 | r1.name = r2.name)) and userPost.assignedRoles->size() = userPre.userRoles->size() + 1 and after.users -> excluding(userPost) = before.users->excluding(userPre) and after.roles = before.roles and after.sessions = before.sessions and after.admin = before.admin

  47. Scenario Object Model Example 47

More Related