Bridging the FST and MDE Divide

Robert B. FranceColorado State University

2 11/15/10

State of the practice

Building software pyramids

3

If software developers built pyramids …

11/15/10

4 11/15/10

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

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

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

11/15/10

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/10

9 11/15/10

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/15/10

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/10

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 formalization11/15/10

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

11/15/10

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

11/15/10

15

Transformation-based approaches

UML Model Formal ModelFormalization

Rigorous Analysis•static analysis•dynamic analysis

feedback

feedbackfeedback

UML Metamodel Formal Language Metamodel

based on conforms toconforms to

11/15/10

16

Using Base Semantic Models

Formal ModelFormalization

Rigorous Analysis•static analysis•dynamic analysis

feedback

feedbackfeedback

BaseOperationalSemantics Operational

Semantics

verified using semantic mappingsemantic mapping

UML ModelUML Model

bisimulation relation

11/15/10

17

Enhanced use of Base Semantic Models

Base UML SemanticModel

Base UML Structural Semantic Model

Base UML untimedBehavioralSemantic Model

Conforms toConforms to

Supports translation to static analysis tools, e.g., Alloy, Z

Supports translation to behavioral analysis tools, e.g., Promela/SPIN

Base UML timedBehavioralSemantic Model

Supports translation to timing analysis tools,

Conforms to

11/15/10

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/10

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

11/15/10

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

11/15/10

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

11/15/10

22 11/15/10

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

…and that’s how one can effectively use

bisimulation to …

He lost me after he introduced himself

…

11/15/1023

Supplemental 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/10

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/10

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

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!

11/15/10

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/10

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

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

references

USE/OCLE

11/15/10

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/10

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

:BankUser

:Controller

toAcc ount:Acco unt

transfer(…)

withdraw(…)deposit(…)

fromAccount:Account

Describes scenario to be analyzed

USE/OCLE

11/15/10

34

Snapshot Model

11/15/10

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

:BankUser

:Controller

toAcc ount:Acco unt

transfer(…)

withdraw(…)deposit(…)

fromAccount:Account

Describes scenario to be analyzed

USE/OCLE

11/15/10

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 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

3711/15/10

38

Example 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

3811/15/10

39 39

Bob:User

JAL_AssignRole

JAL_CreateRole

JAL_CreateUser

admin:Admin

CreateUser

Bob

CreateRole

accountant

CreateRole

cashier

CreateRole

seniorCashier

Assign(accountant)

Assign(seniorCashier)

JAL_CreateRole

Role role = Role._createRole();this.roles._add(role);return role;

JAL_CreateUser

User user = User._createUser();this.users._add(user);return user;

JAL_AssignRole

if (!this.userRoles._exists(role)) { this.userRoles._add(role);}

11/15/10

40 40

Analyze behavioral properties

Analyze scenarios using USE or OCLE against Snapshot model Snapshot invariants Scenario specific invariants

11/15/10

41

Generating the Snapshot Model: A simple example

1. Generate Snapshot class diagram structure

2. Generate Snapshot Model invariants from operation specifications

4111/15/10

42 42

Partial HRBAC application model

11/15/10

43 4311/15/10

44

Generating the Snapshot Model

1. Generate Snapshot Class Diagram

2. Generate Snapshot Model invariants from operation specifications

4411/15/10

45 45

An 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/10

46

context User_Assign_Transition//From Assign() pre-conditionbefore.users->includes(userPre) and

before.roles->includes(rPre) and userPre.userRoles->

forAll(r | r.name <> rPre.name) and//From Assign() post-conditionafter.users->includes(userPost) andafter.roles->includes(rPost) anduserPost.userRoles->exists(r | r.name = rPost.name) anduserPre.userRoles->forAll(r1|userPre.userRoles->exists(r2 | r1.name = r2.name)) and userPost.assignedRoles->size() =userPre.userRoles->size() + 1 andafter.users -> excluding(userPost) = before.users->excluding(userPre) andafter.roles = before.roles andafter.sessions = before.sessions andafter.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/10

47

Scenario Object Model Example

4711/15/10