2. 11/15/10 State of the practiceState of the practice Building software pyramids 2

3. If software developers built pyramids … 11/15/103

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 4

5. 11/15/10 What is a model?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. 5

6. 11/15/10 Modeling is purpose-drivenModeling 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 6

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 11/15/107

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 11/15/108

9. Early focus of MDEEarly 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 9

10. Evolution of MDEEvolution 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/15/1010

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 11/15/1011

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 11/15/1012

13. Defining Semantics “directly”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 11/15/1013

14. Defining semantics “indirectly”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 11/15/1014

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

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

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

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) 11/15/1018

19. The way aheadThe 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 11/15/1019

20. Focus questions - 1Focus 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 11/15/1020

21. Focus questions - 2Focus 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 11/15/1021

22. 11/15/10 Modeling aptitudeModeling 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 22

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

24. Supplemental SlidesSupplemental Slides 11/15/1024

25. pUML perspective: Why formalize UML semantics?  Identify completeness, consistency, ambiguity problems in 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 11/15/1025

26. pUML perspective: Defining semantics  Denotational view of semantics  Semantics of a language is defined by a formal mapping from 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” 11/15/1026

27. 11/15/10 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 27

28. Are you a good modeler?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! 11/15/1028

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 11/15/1029

30. 30 UML Structural Analysis ToolsUML 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 11/15/10

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

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

33. 33 Approach application model Snapshot Model Characterizes valid snapshots and specifies class operations Characterizes valid sequences of snapshots Scenario Object Model Describes a sequence of application states :Bank U s e r :Contr o l l e r toAcco u n t :Accou n t transfer(…) withdraw(…) deposit(…) fromAccount:Ac count Describes scenario to be analyzed USE/OCL E 11/15/10

34. 34 Snapshot Model 11/15/10

35. 35 Approach application model Snapshot Model Characterizes valid snapshots and specifies class operations Characterizes valid sequences of snapshots Scenario Object Model Describes a sequence of application states :Bank U s e r :Contr o l l e r toAcco u n t :Accou n t transfer(…) withdraw(…) deposit(…) fromAccount:Ac count Describes scenario to be analyzed USE/OCL E 11/15/10

36. 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 11/15/10

37. Generating Snapshot SequencesGenerating Snapshot Sequences  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 37 11/15/1037

38. Example scenarioExample scenario  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 38 11/15/1038

39. 39 11/15/1039

40. 40 Analyze behavioral propertiesAnalyze behavioral properties  Analyze scenarios using USE or OCLE against  Snapshot model  Snapshot invariants  Scenario specific invariants 11/15/1040

41. Generating the Snapshot Model: A simple example 1.Generate Snapshot class diagram structure 2.Generate Snapshot Model invariants from operation specifications 41 11/15/1041

42. 42 Partial HRBAC application model 11/15/1042

43. 43 11/15/1043

44. Generating the Snapshot ModelGenerating the Snapshot Model 1.Generate Snapshot Class Diagram 2.Generate Snapshot Model invariants from operation specifications 44 11/15/1044

45. 45 An operation specificationAn operation specification // pre- and post- conditions of the Assign method 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 11/15/1045

46. context User_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 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 11/15/1046

47. Scenario Object Model Example 47 11/15/1047